ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
VŨ ĐỨC HUY
NGHIÊN CỨU CƠ SỞ DỮ LIỆU HƯỚNG ĐỐI TƯỢNG VÀ ÁP
DỤNG VÀO BÀI TOÁN CỤ THỂ VỚI HỆ QUẢN TRỊ DB4O LUẬN VĂN THẠC SĨ Hà Nội – 2011
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
DANH MỤC CÁC HÌNH VẼ 4
MỞ ĐẦU 5
Chƣơng 1 CƠ SỞ DỮ LIỆU VÀ HỆ QUẢN TRỊ CƠ SỞ DỮ LIỆU HƢỚNG ĐỐI
TƢỢNG 6
1.1.Cơ sở dữ liệu hƣớng đối tƣợng 6
1.1.1. Mô hình hƣớng đối tƣợng 6
1.1.2. Các hệ quản trị cơ sở dữ liệu hƣớng đối tƣợng 7
1.2. Các khái niệm trong cơ sở dữ liệu hƣớng đối tƣợng 8
1.2.1. Hƣớng đối tƣợng 8
1.2.2. Đối tƣợng và lớp 8
1.2.3. Cấu trúc đối tƣợng và kiến tạo kiểu 9
1.2.4 Bao gói và che giấu thông tin 14
1.2.5. Phân cấp kiểu và kế thừa 16
1.2.6. Đối tƣợng phức tạp 18
1.2.7. Đa hình, đa kế thừa, kế thừa chọn lọc 19
1.2.8. Phiên bản và cấu hình 21
1.3. Chuẩn ODMG 21
1.3.1. Mô hình hƣớng đối tƣợng của ODMG 21
1.3.2. Ngôn ngữ định nghĩa đối tƣợng (ODL) 30
1.3.3. Ngôn ngữ truy vấn đối tƣợng (OQL) 35
1.3.4. Thiết kế cơ sở dữ liệu hƣớng đối tƣợng 43
1.4. Kết luận 46
Chƣơng 2 HỆ QUẢN TRỊ CƠ SỞ DỮ LIỆU HƢỚNG ĐỐI TƢỢNG DB4O 47
2.1. Giới thiệu 47
2.2. Hệ quản trị cơ sở dữ liệu hƣớng đối tƣợng db4o 47
2.2.1. Tổng quan về db4o 47
2.2.2. Khai thác db4o 49
2.2.3. Công cụ quản lý đối tƣợng 52
2.2.4. Các hệ thống truy vấn 55
2.2.5. Các đối tƣợng có cấu trúc 59
3.4. Biểu đồ lớp 86
3.5. Một số giao diện của chƣơng trình 86
3.6. Kết luận 90
KẾT LUẬN 91
TÀI LIỆU THAM KHẢO 92 3
BẢNG KÝ HIỆU CÁC CHỮ VIẾT TẮT
STT
Từ viết tắt
Tiếng Anh
Tiếng Việt
1
ANSI
American National Standards Institute
Viện Tiêu chuẩn Quốc
gia Hoa Kỳ
2
CAD
Computer - Aided Design
Thiết kế với sự trợ
giúp của máy tính
3
CAI
Computer – Aided Introduce
Giới thiệu nhờ máy
tính
4
liệu
10
ISO
International Organization for
Standardization
Tổ chức tiêu chuẩn
hóa quốc tế
11
ODL
Object Define Language
Ngôn ngữ định nghĩa
đối tƣợng
12
ODMG
Object Data Management Group
Nhóm quản lý dữ liệu
đối tƣợng
13
OIF
Object Interchange Format
14
OML
Object Manipulation Language
15
OMT
Object Modeling Techniques
Công nghệ mô hình
đối tƣợng
4
DANH MỤC CÁC HÌNH VẼ
STT
Hình vẽ
Trang
1
Hình 1.1 Minh họa đối tƣợng phức tạp DEPARTMENT nhƣ một đồ thị
12
2
Hình 1.2 Kế thừa đơn
18
3
Hình 1.3 Kế thừa bội hay đa kế thừa
18
4
Hình 1.4 Phân cấp kế thừa giao diện xây dựng sẵn của mô hình đối tƣợng
27
5
Hình 1.5 Ký hiệu đồ họa
31
6
Hình 1.6 Ví dụ về một phần lƣợc đồ ODL của cơ sở dữ liệu một trƣờng
đại học
31
7
Hình 1.7 Kế thừa thông qua “:”
34
8
Hình 1.8 Một phần của lƣợc đồ EER
55
19
Hình 2.9 Đồ thị truy vấn đơn giản
57
20
Hình 2.10 Đồ thị truy vấn có điều kiện
58
21
Hình 2.11 Minh họa truy vấn SODA
62
22
Hình 3.1 Biểu đồ Use Case
81
23
Hình 3.2 Biểu đồ lớp của hệ thống
86
24
Hình 3.3 Giao diện chính của chƣơng trình
86
25
Hình 3.4 Giao diện đăng nhập
87
26
Hình 3.5 Giao diện cập nhật thông tin lớp học
87
27
Hình 3.6 Giao diện cập nhật thông tin sinh viên
87
28
Hình 3.7 Giao diện cập nhật môn học
đƣợc thƣơng mại hóa.
Tuy nhiên, các hệ quản trị cơ sở dữ liệu quan hệ không phù hợp cho các ứng
dụng có các cấu trúc dữ liệu phức tạp, các đối tƣợng không có cấu trúc, ví dụ nhƣ
CAD/CAM, các hệ thống thông tin địa lý, các cơ sở dữ liệu đa phƣơng tiện, các hình
ảnh, âm thanh,… Các hệ quản trị cơ sở dữ liệu không cho phép ngƣời dùng mở rộng
các kiểu hệ thống, thêm các kiểu dữ liệu mới.
Bên cạnh đó, việc sử dụng ngôn ngữ lập trình hƣớng đối tƣợng để thao tác các cơ
sở dữ liệu quan hệ có những bất cập. Các hệ quản trị cơ sở dữ liệu quan hệ không hỗ
trợ các khái niệm trong ngôn ngữ lập trình hƣớng đối tƣợng. Cho nên chúng ta cần
phải ánh xạ qua lại giữa ngôn ngữ lập trình hƣớng đối tƣợng với cơ sở dữ liệu quan hệ.
Với mong muốn kiểm soát đƣợc các dữ liệu phức tạp cũng nhƣ mở rộng đƣợc hệ
thống trong những ứng dụng đa dạng hơn, mô hình hƣớng đối tƣợng đã ra đời và đƣợc
áp dụng vào các ngôn ngữ lập trình, các giao diện ngƣời dùng, các kỹ thuật thiết kế,
các hệ điều hành, cấu trúc phần cứng và các hệ CSDL. Các ứng dụng “thế hệ tiếp theo
này” gồm thiết kế phần mềm có máy tính hỗ trợ (CASE), sản xuất tích hợp qua máy
tính (CIM), và các ứng dụng khác,…
Cho đến nay chƣa có một chuẩn chính thức và chƣa đƣợc chấp nhận bởi các tổ
chức ISO, ANSI, nhƣng đã có nhiều hệ thƣơng mại theo mô hình quản trị cơ sở dữ liệu
hƣớng đối tƣợng (OODBMS) đƣợc tung ra thị trƣờng nhƣ DB4O, OBJECTSTORE,…
Do đó, có thể nói rằng mô hình OODBMS đã xuất hiện nhƣ một giải pháp nhằm giải
quyết sự phức tạp trong việc mô hình hoá thế giới thực ngày càng tổng quát hơn.
Phạm vi của luận văn này tập trung nghiên cứu những vấn đề sau:
Một số vấn đề cơ bản về cơ sở dữ liệu hƣớng đối tƣợng
Hệ quản trị cơ sở dữ liệu hƣớng đối tƣợng DB4O
Xây dựng ứng dụng mô phỏng việc sử dụng cơ sở dữ liệu hƣớng đối
tƣợng với hệ quản trị DB4O.
Luận văn đƣợc chia thành 3 chƣơng.
Chƣơng 1 trình bày khái quát các vấn cơ bản liên quan đến cơ sở dữ liệu hƣớng
đối tƣợng và hệ quản trị cơ sở dữ liệu hƣớng đối tƣợng.
Chƣơng 2 giới thiệu cách làm việc với hệ quản trị cơ sở dữ liệu hƣớng đối tƣợng
hình dữ liệu hƣớng đối tƣợng và ngôn ngữ truy vấn OQL do tổ chức ODMG đã đƣợc
các nhà tin học quan tâm một cách thực sự. Vấn đề này đƣợc đề cập đến thông qua
việc giới thiệu “mô hình hạt nhân” của mô hình dữ liệu hƣớng đối tƣợng, ở đó một số
các quy ƣớc tối thiểu về mô hình hƣớng đối tƣợng đƣợc bàn đến.
Mô hình hạt nhân đủ mạnh để thoả mãn nhiều đòi hỏi của các ứng dụng mới, hơn
nữa còn đƣợc dùng làm cơ sở cho việc phân tích những khác biệt chính giữa mô hình
dữ liệu hƣớng đối tƣợng với các mô hình dữ liệu truyền thống khác nhƣ mô hình quan
hệ chẳng hạn.
Mô hình hạt nhân dựa trên các khái niệm cơ bản sau [3]:
Mỗi thực thể của thế giới thực đƣợc mô hình hoá bởi một đối tượng. Mỗi đối
tƣợng đƣợc xác định với một tên duy nhất đƣợc gọi là định danh đối tƣợng
Mỗi đối tƣợng có một tập các thuộc tính và phƣơng thức. Giá trị của mỗi thuộc
tính có thể là một đối tƣợng hay một tập đối tƣợng. Đặc trƣng này cho phép các
đối tƣợng phức tạp đƣợc định nghĩa nhƣ sự kết nhập của các đối tƣợng khác.
Tập các thuộc tính của một đối tƣợng và tập các phƣơng thức biểu diễn theo
thức tự cấu trúc và hành vi của đối tƣợng. 7
Các giá trị thuộc tính biểu diễn trạng thái của đối tƣợng. Trạng thái của đối
tƣợng đƣợc truy cập hay sửa đổi bằng việc gửi các thông báo tới đối tƣợng để
viện dẫn các phƣơng pháp tƣơng ứng.
Các đối tƣợng có cùng cấu trúc và hành vi đƣợc nhóm lại thành một lớp. Một
lớp biểu diễn một hình mẫu cho một tập các đối tƣợng đồng dạng. Mỗi đối
tƣợng là thể hiện của một lớp nào đó.
Một lớp có thể đƣợc định nghĩa nhƣ một chuyên biệt hoá của một hay nhiều
lớp. Một lớp đƣợc định nghĩa nhƣ vậy gọi là một lớp con và kế thừa các thuộc
tính và phƣơng thức thuộc lớp trên của nó.
Nhƣ chúng ta đã biết, các cơ sở dữ liệu quan hệ đã và đang đƣợc sử dụng rất hiệu
quả trong nhiều bài toán ứng dụng. Cơ sở dữ liệu hƣớng đối tƣợng cần phải nghiên
tƣợng và nhiều tính chất khác. 8
Các hệ quản trị cơ sở dữ liệu hƣớng đối tƣợng cũng có các yếu điểm sau [5]:
Thiếu cơ sở lý thuyết và chuẩn hoá
Chƣa có cơ chế đủ mạnh để bảo vệ cơ sở dữ liệu
Không có khả năng mở rộng logic
Chƣa hỗ trợ các siêu (meta) ứng dụng
Hệ quản trị cơ sở dữ liệu hƣớng đối tƣợng là thích hợp hơn đối với những ứng
dụng mới nhƣ:
Những ứng dụng thiết kế công nghệ
Các ứng dụng đa phƣơng tiện
Các cơ sở tri thức
Những ứng dụng đòi hỏi xử lý phân tán và tƣơng tranh.
Các phần mềm nhúng
1.2. Các khái niệm trong cơ sở dữ liệu hướng đối tượng
1.2.1. Hƣớng đối tƣợng
Thuật ngữ hƣớng đối tƣợng (object-oriented) còn đƣợc viết tắt là OO hoặc O-O
có nguồn gốc từ các ngôn ngữ lập trình hƣớng đối tƣợng (OO hoặc OOPL). Ngày nay,
khái niệm hƣớng đối tƣợng đƣợc áp dùng trong các lĩnh vực nhƣ cơ sở dữ liệu, kỹ
nghệ phần mềm, cơ sở tri thức, trí tuệ nhân tạo và hệ thống máy tính nói chung [10].
Hệ thống hƣớng đối tƣợng quan tâm tới một số vấn đề sau:
Đối tƣợng và cấu trúc của đối tƣợng
Tính duy nhất và tính bền vững của đối tƣợng
Các đối tƣợng phức tạp
Các phép toán áp dụng trên đối tƣợng
Phân cấp, kế thừa và tính đa hình
Bao gói và che dấu thông tin
Phân chia phiên bản đối tƣợng
struct
Pname {
string
fname,
string
mname,
string
lname}name;
attribute string ssn;
attribute date birddate;
attribute enum Gender{M, F} sex;
attribute struct Address {short no, string street, short aptno, string city,
string state, short zip} address;
short age();
};
1.2.3. Cấu trúc đối tƣợng và kiến tạo kiểu
1.2.3.1. Cấu trúc đối tượng
Trong cơ sở dữ liệu hƣớng đối tƣợng, trạng thái (giá trị hiện tại) của một đối
tƣợng phức tạp có thể đƣợc xây dựng từ các đối tƣợng khác (hoặc các giá trị khác)
bằng cách sử dụng một số kiến tạo kiểu (atom, tuple, set, list, bag, và array). Có thể
xem đối tƣợng là bộ ba (i, c, v), trong đó i là định danh của đối tƣợng (OID), c là bộ
kiến tạo hay tạo lập kiểu (chỉ ra cách đối tƣợng đƣợc xây dựng), và v là trạng thái của
đối tƣợng (hoặc giá trị hiện tại) [10].
Trạng thái v của đối tƣợng (i, c, v) đƣợc xác định dựa trên c. Nếu c = atom, trạng
thái (giá trị) của v là giá trị nguyên tử mà miền giá trị đƣợc hỗ trợ bởi hệ thống. Nếu c
= set, trạng thái v là tập định danh đối tƣợng {i
1
, i
2
khác. Trạng thái của đối tƣợng không phải kiểu atom sẽ tham chiếu đến các đối tƣợng
khác dựa vào định danh của đối tƣợng đó. 10
Các kiểu set, list, array và bag là kiểu sƣu tập (collection hoặc kiểu bulk). Kiểu
tuple là kiểu cấu trúc.
Ví dụ 1.3 : Một đối tƣợng phức tạp
Giả sử cho các đối tƣợng từ mô hình cơ sở dữ liệu quan hệ nhƣ sau:
Employee
FNAME
MINIT
LNAME
SN
BDATE
ADDRESS
SEX
SALARY
SUPERSSN
DNO
Hồng
B
Nguyễn
Thị
123456789
01/9/1965
Hà Nội
M
30000
987654321
20/1/1941
Lạng Sơn
F
43000
888665555
4
Cúc
K
Hoàng
Thu
666884444
15/9/1962
Huế
M
38000
333445555
5
Nam
A
Trần
Văn
453453453
31/7/1972
Đà Nẵng
F
25000
333445555
Hà Nội
4
Huế
5
Đà Nẵng
5
Đà Lạt
Department
DNAME
DNUMBER
MGRSSN
MGRSTARTDATE
Nghiên cứu
5
333445555
22/5/1988
Hành chính
4
987654321
01/01/1985
Quản trị
1
888665555
333445555
3
10.0
Project
PNAME
PNUMBER
PLOCATION
DNUM
X
1
Đà Nẵng
5
Y
2
Đà Lạt
5
Z
3
Đà Nẵng
5
Tin học
10
Huế
4
, i
2
, i
3
, chỉ định danh của đối
tƣợng.
o
1
= (i
1
, atom, „Hà Nội‟)
o
2
= (i
2
, atom, „Đà Nẵng‟)
o
3
= (i
3
, atom, „Đà Lạt‟)
o
4
= (i
4
, atom, 5)
o
5
= (i
5
EMPLOYEES:i
10
, PROJECT:i
11
>)
o
9
= (i
9
, tuple, <MANAGER:i
12
, MANAGER_START_DATE:i
6
>)
o
10
= (i
10
, set, {i
12
, i
13
, i
14
})
o
11
= (i
10
, set, {i
–
o
6
) có giá trị nguyên tử. Đối tƣợng o
7
là đối tƣợng giá trị tập.
Đối tƣợng là o
8
đối tƣợng giá trị tuple
Một đối tƣợng có thể coi nhƣ là cấu trúc đồ thị, đƣợc xây dựng bằng đệ quy áp
dụng bộ tạo kiểu. Đồ thị mô tả đối tƣợng o
i
đƣợc xây dựng bằng cách: đầu tiên tạo một
nút cho bản thân đối tƣợng o
i
. Nhãn của nút này là OID và bộ tạo kiểu c. Ta cũng có
thể tạo nút cho mỗi giá trị nguyên tử cơ bản. Nếu đối tƣợng o
i
có giá trị nguyên tử, ta
vẽ một cung có hƣớng từ nút o
i
đến nút có giá trị cơ bản. Nếu giá trị đối tƣợng là có
cấu trúc, ta vẽ cung có hƣớng từ nút đối tƣợng đến nút giá trị cấu trúc. Hình 1.1 mô tả
đồ thị cho đối tƣợng Department.
Có hai kiểu định nghĩa để so sánh trạng thái bằng nhau của hai đối tƣợng:
Hai đối tƣợng đƣợc gọi là có trạng thái đồng nhất nếu đồ thị mô tả trạng thái
của chúng là giống nhau về chi tiết, bao gồm cả các OID tại mỗi mức.
Hai đối tƣợng có trạng thái bằng nhau nếu cấu trúc đồ thị là giống nhau, và tất
cả các giá trị nguyên tử tƣơng ứng trong đồ thị phải nhƣ nhau. Tuy nhiên, một
o
3
= (i
3
, tuple, <a
1
:i
4
, a
2
:i
6
>)
o
4
= (i
4
, atom, 10)
o
5
= (i
5
, atom, 10)
o
6
= (i
6
, atom, 20)
set
Hình 1.1 Minh họa đối tƣợng phức tạp Department nhƣ một đồ thị
Nghiên cứu
Hà Nội
Đà Nẵng
Đà Lạt
22/5/1988 13
1.2.3.2. Kiến tạo kiểu
Ngôn ngữ định nghĩa đối tƣợng (ODL) kết hợp các kiểu đã đƣợc xây dựng sẵn để
định nghĩa kiểu đối tƣợng cho ứng dụng cơ sở dữ liệu cụ thể. Kiến tạo kiểu đƣợc dùng
để định nghĩa cấu trúc dữ liệu cho một lƣợc đồ cơ sở dữ liệu hƣớng đối tƣợng. Ví dụ
1.5 dƣới đây đƣa ra cách khai báo kiểu Employee và Department tƣơng ứng với thể
hiện trong Hình 1.1. Ta dùng các từ khóa tuple, set và list cho các kiến tạo kiểu, và các
kiểu dữ liệu chuẩn (integer, string, float,…) cho kiểu nguyên tử.
Ví dụ 1.5 Mô tả kiểu đối tƣợng Employee, Date, Department sử dụng kiến tạo kiểu
define type Employee:
tuple ( fname: string;
minit: char;
lname: string;
ssn: string;
birthdate: Date;
address: string;
sex: char;
salary: float;
supervisor: Employee;
Ví dụ 1.6: Thêm các phép toán vào định nghĩa của Employee và Department trong ví
dụ 1.5.
define class Employee
type tuple( fname: string;
minit: char;
Iname: string;
ssn: string;
birthdate: Date;
address: string;
sex: char;
salary: float;
supervisor: Employee;
dept: Department;);
operations age: integer;
create_emp: Employee;
destroy_emp: boolean;
end Employee;
define class Department
type tuple( dname: string;
dnumber: integer;
mgr: tuple (manager: Employee; startdate: Date; );
locations: set(string);
employees: set(Employee);
projects: set(Project););
operations no_oCemps: integer;
create_dept: Department;
destroy-dept: boolean;
assign_emp(e: Employee): boolean;
(* thêm một employee vào department *)
remove_emp(e: Employee): boolean;
operations add_dept(d: Department): boolean;
(* thêm một phòng ban vào đối tƣợng DepartmentSet *)
remove_dept(d: Department): boolean;
(* xóa một phòng ban ra khỏi đối tƣợng DepartmentSet *)
Create_dept_set: DepartmentSet;
Destroy_dept_set: boolean;
end DepartmentSet;
…
persistent name AllDepartments: DepartmentSet;
(' AllDepartments đối tƣợng tên bền vững của kiểu DepartmentSet *)
…
d:= create_dept;
(* tạo đối tƣợng Department mới trong biến d *)
…
b:= AllDepartments.add_dept(d);
(* tạo bền d bằng cách thêm nó vào tập bền vững AllDepartments *)
…
Đầu tiên tạo ra đối tƣợng tên N có trạng thái là set hoặc list của lớp C. Ta tạo các
đối tƣợng của C bằng cách thêm chúng vào tập hoặc danh sách, đã tạo reachable cho
chúng từ N. Do đó, N định nghĩa tập bền vững (persistent collection) đối tƣợng của
lớp C. Ví dụ, ta định nghĩa lớp DepartmentSet (Ví dụ 1.7) với các đối tƣợng có kiểu 16
set(Department). Giả sử rằng một đối tƣợng kiểu DepartmentSet đƣợc tạo ra, và nó có
tên AllDepartments và đƣợc tạo bền nhƣ minh họa trong Ví dụ 1.7. Bất kỳ đối tƣợng
Department nào đƣợc thêm vào tập AllDepartments bằng cách sử dụng phép toán
add_dept đều trở nên bền vì nó đƣợc reachable từ AllDepartments. Đối tƣợng
AllDepartments thƣờng đƣợc gọi là extent của lớp Department, nó sẽ quản lý tất cả
các đối tƣợng bền có kiểu Department.
các hàm của kiểu định nghĩa trƣớc đó – gọi là kiểu cha (supertype).
Ví dụ 1.9: Định nghĩa hai kiểu mới EMPLOYEE và STUDENT nhƣ sau:
EMPLOYEE: Name, Address, Birthdate, Age, SSN, Salary, HireDate, Seniority
STUDENT: Name, Address, Birthdate, Age, SSN, Major, GPA 17
Cả hai kiểu STUDENT và EMPLOYEE có tất cả các hàm đƣợc định nghĩa trong
PERSON và bổ sung thêm các hàm khác của riêng chúng, ta có thể khai báo chúng là
kiểu con của PERSON. Mỗi kiểu đó sẽ thừa kế các hàm đã định nghĩa trƣớc của
PERSON nhƣ Name, Address, Birthdate, Age, và SSN. Đối với kiểu STUDENT, chỉ
phải định nghĩa hàm mới (cục bộ) Major và GPA vì không đƣợc thừa kế. Major định
nghĩa nhƣ thuộc tính lƣu trữ, GPA định nghĩa nhƣ một phƣơng thức để tính toán điểm
trung bình của sinh viên bằng cách truy cập giá trị Grade (không trình bày ở đây) chứa
trong mỗi STUDENT là các thuộc tính riêng. Với EMPLOYEE, các hàm Salary và
HireDate là các thuộc tính lƣu trữ, Seniority là phƣơng thức tính toán Seniority từ giá
trị của HireDate.
Ta có thể khai báo EMPLOYEE và STUDENT nhƣ sau:
EMPLOYEE subtype-of PERSON: Salary, HireDate, Seniority
STUDENT subtype-of PERSON: Major, GPA
Do vậy, có thể tạo ra phân cấp kiểu (type hierarchy) để hiển thị mối quan hệ
cha/con của tất cả các kiểu khai báo trong hệ thống.
Ví dụ 1.10: Mô tả đối tƣợng hình học
GEOMETRY_OBJECT: Shape, Area, ReferencePoint
Với kiểu GEOMETRY_OBJECT, Shape là thuộc tính (nó có thể là kiểu liệt kê
gồm „triangle‟, „rectangle‟, „circle‟,…), và Area là một phƣơng thức áp dụng để tính
toán diện tích. Giả sử, định nghĩa kiểu con nhƣ sau:
RECTANGLE subtype-of GEOMETRY_OBJECT: Width, Height
TRIANGLE subtype-of GEOMETRY_OBJECT: Side1, Side2, Angle
CIRCLE subtype-of GEOMETRY_OBJECT: Radius
Hình 1.2 Kế thừa đơn
Kế thừa bội: Lớp con kế thừa nhiều lớp cha Hình 1.3 Kế thừa bội hay đa kế thừa
1.2.6. Đối tƣợng phức tạp
Đối tƣợng phức tạp có hai loại:
Đối tƣợng không có cấu trúc thƣờng là kiểu dữ liệu đòi hỏi lƣợng lớn không
gian lữu trữ nhƣ: âm thanh, đồ hoạ, đa phƣơng tiện
Đối tƣợng có cấu trúc đƣợc tạo bởi các thành phần và đƣợc định nghĩa bằng
cách áp dụng các kiểu có sẵn tại các cấp.
1.2.6.1. Đối tượng phức tạp không có cấu trúc và mở rộng kiểu
Với các đối tƣợng không có cấu trúc, DBMS không hiểu cấu trúc của chúng, chỉ
sử dụng ứng dụng biểu thị ý nghĩa của chúng. Ví dụ, ứng dụng có chức năng hiển thị
một hình ảnh hoặc tìm kiếm từ khóa chứa trong chuỗi lớn ký tự. DBMS có thể dùng
kỹ thuật buffering và caching để lấy về từng phần của đối tƣợng trƣớc khi ứng dụng
cần truy cập chúng.
Phần mềm DBMS không có khả năng xử lý trực tiếp các điều kiện lựa chọn và
các hoạt động khác dựa vào giá trị của đối tƣợng, trừ khi ứng dụng cung cấp mã cho
việc so sánh các hoạt động cần thiết cho sự lựa chọn. Trong OODBMS, điều này có
thể đƣợc thực hiện bằng cách định nghĩa một kiểu dữ liệu trừu tƣợng cho các đối
tƣợng chƣa biết và cung cấp cách thức cho việc chọn, so sánh và hiển thị đối tƣợng. Ví
Person
một thuộc tính (MANAGER) tham chiếu tới một đối tƣợng employee có cấu trúc
tuple. Với tập LOCATIONS, ta có một tập với các thuộc tính cơ bản. Nhƣng với hai
thuộc tính EMPLOYEES và PROJECTS, ta có các tập đối tƣợng có cấu trúc tuple.
Trong nhiều trƣờng hợp, đối tƣợng phức tạp đƣợc lƣu trữ trên các trang đĩa (disk
page) theo khuôn dạng nào đó. Khi các trang đĩa gồm các đối tƣợng đƣợc tải vào bộ
nhớ, OODBMS phải xây dựng đối tƣợng có cấu trúc phức tạp đó từ thông tin từ các
trang đĩa, khi đó có thể phải tham chiếu tới các trang đĩa khác để lấy dữ liệu về. Cách
này đƣợc hiểu nhƣ sự lắp ráp đối tƣợng
1.2.7. Đa hình, đa kế thừa, kế thừa chọn lọc
1.2.7.1. Đa hình
Cơ chế đa hình của phép toán, còn gọi là cơ chế nạp chồng toán tử. Khái niệm
này cho phép tên phép toán giống nhau nhƣng có thể có nhiều cách khác nhau để thực
hiện phép toán tùy thuộc vào kiểu đối tƣợng áp dụng cho phép toán. Trong một số
ngôn ngữ, toán tử “+” có một số ý nghĩa khác nhau khi áp dụng cho các kiểu toán
hạng (đối tƣợng) khác nhau. Nếu toán hạng của “+” là số nguyên, khi đó thực hiện
phép cộng số nguyên. Nếu toán hạng của “+” là kiểu dấu chấm động, khi đó thực hiện
phép cộng số thực. Nếu toán hạng của “+” có kiểu tập hợp, khi đó thực hiện hợp hai
tập hợp. Trình biên dịch xác định phép toán nào sẽ đƣợc thi hành dựa trên kiểu của các
toán hạng [10]. 20
Trong cơ sở dữ liệu hƣớng đối tƣợng, tình huống tƣơng tự có thể xảy ra. Ví dụ, ta
dùng GEOMETRY_OBJECT trong Ví dụ 1.7 để minh họa. Giả sử, khai báo
GEOMETRY_OBJECT và kiểu con của nó nhƣ sau:
GEOMETRY_OBJECT: Shape, Area, ReferencePoint
RECTANGLE
subtype-of
GEOMETRY_OBJECT (Shape=„rectangle‟):Width, Height
TRIANGLE
Nguyên tắc chung là một hàm đƣợc kế thừa từ một số kiểu cha chung (common
supertype), sau đó nó chỉ đƣợc kế thừa một lần. Trong trƣờng hợp này, không có sự
nhập nhằng; vấn đề chỉ xảy ra nếu các hàm là khác nhau trong hai kiểu cha.
Có một số giải pháp cho cho vấn đề nhập nhằng trong đa kế thừa. Một giải pháp
là phải có hệ thống kiểm tra sự nhập nhằng khi kiểu con đƣợc tạo ra, và cho phép
ngƣời dùng chọn các hàm đƣợc phép kế thừa tại thời điểm đó. Giải pháp khác là dùng 21
một số mặc định của hệ thống. Giải pháp thứ ba là không cho phép đa kế thừa nếu xảy
ra nhập nhằng về tên, thay vì bắt buộc ngƣời dùng phải đổi tên các hàm trong các kiểu
cha.
Kế thừa lựa chọn
Kế thừa lựa chọn (Selective inheritance ) xảy ra khi kiểu con chỉ kế thừa một vài
hàm của kiểu cha. Trong trƣờng hợp này, một mệnh đề EXCEPT đƣợc dùng để liệt kê
các hàm trong kiểu cha không đƣợc thừa kế bởi kiểu con.
1.2.8. Phiên bản và cấu hình
Nhiều ứng dụng cơ sở dữ liệu dùng hệ thống hƣớng đối tƣợng đòi hỏi sự tồn tại
một số phiên bản của đối tƣợng. Do vậy, một OODBMS nên có cơ chế lƣu trữ và quản
lý nhiều phiên bản của cùng một đối tƣợng. Nó cho phép ứng dụng duy trì nhiều phiên
bản của đối tƣợng và đƣa ra phiên bản hiệu quả nhất khi cần.
1.3. Chuẩn ODMG
1.3.1. Mô hình hƣớng đối tƣợng của ODMG
Nhƣ đã biết, chƣa có một định nghĩa tiêu chuẩn thống nhất cho các mô hình đối
tƣợng. Các ngôn ngữ lập trình hƣớng đối tƣợng và các hệ cơ sở dữ liệu hƣớng đối
tƣợng hỗ trợ nhiều mô hình đối tƣợng khác nhau.
Để giải quyết vấn đề này, ODMG (Object Database Management Group – Nhóm
quản trị cơ sở dữ liệu đối tƣợng), một tổ chức mà các thành viên là các nhà sản xuất
của nhiều hệ quản trị cơ sở dữ liệu hƣớng đối tƣợng thƣơng mại khác nhau đã đề xuất
một cơ sở dữ liệu tiêu chuẩn. Mục tiêu của ODMG là thống nhất mô hình đối tƣợng
Kiểu sƣu tập (collection)
o Set<t>: Không có thứ tự, không lặp, không cố định số phần tử
o Bag<t>: Không có thứ tự, có thể lặp, không cố định số phần tử
o List<t>: Có thứ tự, có lặp, không cố định số phần tử
o Array<t>: Có thứ tự, có lặp, cố định số phần tử tối đa
o Dictionary<t,v>: Mỗi phần tử là một cặp (khóa, giá trị), trong đó không
kể thứ tự của những khóa. Những giá trị trong các cặp có thể trùng nhau.
Kiểu cấu trúc (Struct)
o Date: Thể hiện thời gian một ngày
o Interval: Thể hiện một khoảng thời gian
o Time: Biểu thị thời báo của thế giới, lƣu trữ Greenwich Mean Time (GMT).
Múi giờ (Time zone) để chỉ thời gian đƣợc thêm vào hay trừ đi giờ địa
phƣơng so với thời gian Greenwich, England.
o Timestamp: Bao gồm Date và Time.
Literal
Literal là một giá trị có cấu trúc đơn giản hoặc phức tạp, không có định danh. Có
3 loại của literal: nguyên tử (atomic), sƣu tập (collection), có cấu trúc (structured).
Literal nguyên tử tƣơng ứng với giá trị của loại dữ liệu cơ bản đƣợc xác định
trƣớc gồm: số nguyên ngắn, số nguyên dài, số nguyên không dấu, số thực đơn, số thực
kép, logic, ký tự, xâu ký tự và kiểu liệt kê.
Literal có cấu trúc gồm một số thành phần, mỗi thành phần có thể lƣu trữ một giá
trị literal hoặc đối tƣợng. Ngoài kiểu có cấu trúc do ngƣời dùng định nghĩa còn có các
kiểu đƣợc hỗ trợ gồm: date, interval, time, timestamp.
Literal sƣu tập chỉ giá trị là một tập các đối tƣợng hay giá trị nhƣng bản thân nó
không có định danh. Tập trong mô hình đối tƣợng là Set<t>, Bag<t>, List<t>, và
Array<t>, trong đó t kiểu của đối tƣợng hay giá trị trong tập. Kiểu tập khác là
Dictionary<k,v>, trong đó k là khóa kết hợp với giá trị v, đƣợc dùng để tạo chỉ mục
trên bộ giá trị .
Ví dụ 1.12 Định nghĩa giao diện của mô hình đối tƣợng trong ODMG. Giao diện cơ sở
Object đƣợc thừa kế bởi tất cả các đối tƣợng:
};
Interface Time : Object{
…
unsigned short hour();
unsigned short minute();
unsigned short second();
unsigned short millisecond();
…
boolean is_equal(in Time other_Time);
boolean is_greater(in Time other_Time);
…
Time add_interval(in Interval some_Interval);
Time subtract_interval(in Interval some_Interval);
Interval subtract_time(in Time other_Time);
};
Interface Timestamp : Object{
Copyright: Tài liệu đại học ©