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ị DB40
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.77 MB, 94 trang )
ĐẠ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Ệ
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
Ngành: Công nghệ thông tin
Chuyên ngành: Hệ thống thông tin
Mã số: 60 48 05
LUẬN VĂN THẠC SĨ
NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS Đoàn Văn Ban
Hà Nội – 2011
1
MỤC LỤC
BẢNG KÝ HIỆU CÁC CHỮ VIẾT TẮT 3
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
2.2.6. Tập hợp và mảng 64
2.2.7. Kế thừa 69
2.2.8. Các giao tác 73
2.2.9. Làm việc trong chế độ Client/Server 74
2.3. Kết luận 79
2
Chƣơng 3 BÀI TOÁN QUẢN LÝ SINH VIÊN KHOA CÔNG NGHỆ THÔNG TIN
TRƢỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI 80
3.1. Phát biểu bài toán 80
3.2. Chú giải 80
3.2.1. Lớp học 80
3.2.2. Sinh viên 80
3.2.3. Giáo viên 80
3.2.4. Môn học 80
3.2.5. Điểm 80
3.2.6. Hạnh kiểm 80
3.3. Mô hình USE CASE 81
3.3.1. Biểu đồ chính của Use case 81
3.3.2. Quản trị ngƣời dùng 81
3.3.3. Cập nhật Môn học 81
3.3.4. Cập nhật Lớp học 82
3.3.5. Cập nhật Sinh viên 83
3.3.6. Cập nhật Điểm 83
3.3.7. Cập nhật Hạnh kiểm 84
3.3.8. Tìm kiếm Sinh viên 84
3.3.9. Tìm kiếm Điểm 85
3.3.10. Tìm kiếm Hạnh kiểm 85
3.3.11. Tìm kiếm Môn học 85
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
CAM
Computer – Aided Manufacturing
Chế tạo với sự trợ giúp
của máy tính
5
CAP
Computer – Aided Publishing
Xuất bản nhờ máy tính
6
CASE
Computer – Aided Software
Engineering
Kỹ nghệ phần mềm
với sự trợ giúp của
máy tính
7
CIM
Computer – Intergrated
Manufacturing
Chế tạo tích hợp với
máy tính
8
DDL
Data Definition Language
Ngôn ngữ định nghĩa
dữ liệu
9
DML
Data Manipulation Language
Ngôn ngữ thao tác dữ
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
16
OODB
Object Oriented DataBase
Cơ sở dữ liệu hƣớng
đối tƣợng
17
OODBMS
Object Oriented DataBase
Managerment System
Hệ quản trị cơ sở dữ
liệu với mô hình
hƣớng đối tƣợng
18
OOPL
Object Oriented Program Language
Ngôn ngữ lập trình
hƣớng đối tƣợng
19
RDMMS
Relational DataBase Managerment
System
Hệ quản trị cơ sở dữ
liệu với mô hình quan
hệ
20
SODA
Simple Object Database Access
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
44
9
Hình 2.1 Cấu trúc thƣ mục của DB4O
47
10
Hình 2.2 Tham chiếu đến file Db4objects.Db4o.dll trong đề án
48
11
Hình 2.3 Chƣơng trình quản lý đối tƣợng của cơ sở dữ liệu db4o
48
12
Hình 2.4 Menu của chƣơng trình quản lý đối tƣợng của cơ sở dữ liệu db4o
52
13
Hình 2.5 Giao diện chƣơng trình quản lý đối tƣợng của cơ sở dữ liệu db4o
53
14
Hình 2.6 Giao diện Cửa sổ Db4o Browser dùng để quản lý đối tƣợng
53
15
Hình 2.7 Giao diện hiển thị tất cả các đối tƣợng trong một lớp
54
16
Hình 2.8 a Giao diện thực hiện truy vấn sử dụng Query Builder
54
17
Hình 2.8 b Giao diện thực hiện truy vấn sử dụng Attribute List
54
18
Hình 2.8 c Giao diện cho phép chọn truy vấn
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
88
29
Hình 3.8 Giao diện cập nhật giáo viên
88
30
Hình 3.9 Giao diện cập nhật hạnh kiểm
88
31
Hình 3.10 Giao diện cập nhật điểm
89
32
Hình 3.11 Giao diện tìm kiếm môn học
89
33
Hình 3.12 Giao diện tìm kiếm sinh viên
89
34
Hình 3.13 Giao diện tìm kiếm hạnh kiểm
90
35
Hình 3.14 Giao diện tìm kiếm điểm
90
5
MỞ ĐẦU
Hệ quản trị cơ sở dữ liệu với mô hình quan hệ (RDBMS – Relation DataBase
Management System) đã có nhiều đóng góp đáng kể trong việc quản lý các hệ thông
tin. Chúng đƣợc nghiên cứu, ứng dụng, phát triển rộng rãi và có nhiều sản phẩm đã
đƣợ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
DB4O.
Chƣơng 3 xây dựng chƣơng trình quản lý sinh viên sử dụng cơ sở dữ liệu hƣớng
đối tƣợng với hệ quản trị DB4O.
6
Chƣơng 1
CƠ SỞ DỮ LIỆU VÀ HỆ QUẢN TRỊ CƠ SỞ DỮ LIỆU
HƢỚNG ĐỐI TƢỢNG
1.1.Cơ sở dữ liệu hướng đối tượng
1.1.1. Mô hình hƣớng đối tƣợng
Một cơ sở dữ liệu hƣớng đối tƣợng đƣợc xem nhƣ là một kho bền vững các đối
tƣợng đƣợc tạo ra bởi ngôn ngữ lập trình hƣớng đối tƣợng. Với một ngôn ngữ lập
trình bất kỳ, các đối tƣợng sẽ ngừng tồn tại (kết thúc) khi chƣơng trình ứng dụng kết
thúc, nhƣng trong cơ sở dữ liệu hƣớng đối tƣợng, các đối tƣợng đƣợc duy trì ở bên
ngoài phạm vi thực hiện của chƣơng trình. Hệ quản trị cơ sở dữ liệu hƣớng đối tƣợng
(OODBMS) quản lý dữ liệu, mã chƣơng trình và các cấu trúc kết hợp nhằm thiết lập
một cơ sở dữ liệu hƣớng đối tƣợng. Khác với các hệ quản trị cơ sở dữ liệu quan hệ, các
hệ quản trị cơ sở dữ liệu hƣớng đối tƣợng khác nhau rất nhiều về cú pháp và các khả
năng ứng dụng. Tổ chức chuẩn hoá việc quản lý dữ liệu đối tƣợng ODMG (Object
Data Management Group) cố gắng tìm cách giải quyết sự khác biệt đó bằng cách thống
nhất đƣa ra những kỹ thuật mô hình hóa đối tƣợng OMT (Object Modeling
Techniques) hay ngôn ngữ mô hình hoá thống nhất UML [2].
Mặc dù cho đến nay mô hình dữ liệu hƣớng đối tƣợng chƣa có một chuẩn đƣợc
chấp nhận chính thức bởi các tổ chức ANSI hay ISO nhƣ đối với mô hình quan hệ,
nhƣng trong suốt những năm qua một số hệ cơ sở dữ liệu hƣớng đối tƣợng nhƣ O
2
hay
ObjectStore đã xâm nhập vào thị trƣờng Mỹ một cách chính thức nhờ khả năng mạnh
mẽ của việc mô hình hoá thế giới thực. Bên cạnh đó, các đề xuất về một chuẩn cho mô
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
cứu và ứng dụng bởi ƣu, nhƣợc điểm sau:
Hỗ trợ các kiểu dữ liệu đƣợc định nghĩa bởi ngƣời sử dụng
Cung cấp một mẫu hình phát triển cơ sở dữ liệu cho cả phân tích, thiết kế và cài
đặt ứng dụng, không phải chuyển từ mẫu hình này sang mẫu hình khác nhƣ
trong quá trình phát triển phần mềm
Cải tiến đáng kể về chất lƣợng dữ liệu. Ta có thể đƣa ra nhiều ràng buộc vào
cấu trúc dữ liệu. Mô hình còn cho phép thể hiện cả những ràng buộc không cấu
trúc để chƣơng trình phải thoả mãn khi nó thực hiện trong cơ sở dữ liệu. Một cơ
sở dữ liệu hƣớng đối tƣợng có thể dẫn về một cơ sở dữ liệu quan hệ đƣợc chuẩn
hoá
Tốc độ phát triển phần mềm nhanh hơn. Cấu trúc cơ sở dữ liệu nhất quán và rõ
ràng giúp cho lập trình ứng dụng trở nên đơn giản và nhanh hơn
Tích hợp dễ dàng.
1.1.2. Các hệ quản trị cơ sở dữ liệu hƣớng đối tƣợng
Các hệ quản trị cơ sở dữ liệu hƣớng đối tƣợng có thể đƣợc định nghĩa là hệ quản
trị cơ sở dữ liệu trực tiếp hỗ trợ một mô hình dựa trên kiểu hƣớng đối tƣợng. Nó phải
cung cấp việc lƣu trữ bền cho các đối tƣợng và những mô tả của chúng. Hệ cũng phải
cung cấp một ngôn ngữ cho việc định nghĩa lƣợc đồ và cho việc thao tác các đối tƣợng
và lƣợc đồ của chúng. Ngoài ra, nó thƣờng có một ngôn ngữ hỏi và những cơ chế cơ
sở dữ liệu cần thiết cho việc tối ƣu hoá truy cập nhƣ lập chỉ mục và dồn cụm, các cơ
chế điều khiển tƣơng tranh và trao quyền đối với truy cập nhiều ngƣời dùng, cơ chế
khôi phục khi có sự cố [3].
Một số hệ quản trị cơ sở dữ liệu hƣớng đối tƣợng phổ biến trên thị trƣờng nhƣ
ObjectStore, GemStore, Objectivity, O
2
, Jasmine, Versant, Db4o và POET.
Hệ quản trị cơ sở dữ liệu hƣớng đối tƣợng hỗ trợ rất nhiều kiểu dữ liệu phong
phú và thông thƣờng là kết hợp chặt chẽ với ít nhất một ngôn ngữ lập trình. Các hệ
quản trị cơ sở dữ liệu hƣớng đối tƣợng thực hiện nhanh hơn những ứng dụng điều
khiển từ các đối tƣợng tham chiếu đến đối tƣợng, hỗ trợ kế thừa, quản lý định danh đối
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
1.2.2. Đối tƣợng và lớp
1.2.2.1. Đối tượng
Đối tƣợng là mô hình hoá thực thể trong thế giới thực, bao gồm: định danh, thuộc
tính và các thao tác (phép toán).
Định danh đối tượng (OID)
Định danh của đối tƣợng do hệ thống cấp, là bất biến, chỉ mất đi khi đối tƣợng đó
bị huỷ. Giá trị định danh của đối tƣợng không trực quan với ngƣời sử dụng, nó đƣợc
sử dụng nội bộ trong hệ thống để phân biệt các đối tƣợng, tạo và quản lý đối tƣợng
tham chiếu. Mỗi đối tƣợng có một định danh duy nhất và đƣợc gán tại thời điểm tạo
đối tƣợng.
Thuộc tính
Thuộc tính mô tả trạng thái của đối tƣợng, cho phép các thuộc tính phức tạp, có cấu
trúc tuỳ ý.
9
Thuộc tính đặc trƣng: Gồm các thuộc tính đơn, phức hợp (có tính chất tập hợp).
Thuộc tính liên kết: Định danh của đối tƣợng tham chiếu.
Các thao tác
Các thao tác mô tả hành vi (ứng xử) của đối tƣợng, gồm giao diện và phƣơng
thức.
Ví dụ 1.1: Minh họa đối tƣợng Nguoi với các thuộc tính và phƣơng thức
Nguoi P1{Ho: Le, Ten: Hien, Tuoi: 22, Dichuyen: XM, Sinh(), Gia(), Lai
xe(), Chet()}
1.2.2.2. Lớp
Lớp là tập các đối tƣợng có cùng tính chất và ứng xử.
Ví dụ 1.2: Minh họa lớp Person
Class Person
( extent persons key snn) {
attribute
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
,…,i
n
}, là định danh của tập đối
tƣợng có cùng kiểu. Nếu c = tuple, trạng thái v là bộ có dạng <a
1
:i
1
, a
2
:i
2
, a
n
:i
n
>, trong
đó mỗi a
j
là tên thuộc tính và i
j
là định danh. Nếu c = list, giá trị v là danh sách có thứ
tự [i
1
, i
2
, …,i
n
] định danh đối tƣợng cùng kiểu. Với c = array, trạng thái của đối tƣợng
là mảng (một chiều) định danh đối tƣợng.
Mô hình đối tƣợng cho phép lồng nhau của các kiểu set, list, tuple và các kiểu
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
333445555
5
Lan
T
Phạm
Thị
333445555
08/12/1955
Hà Nam
M
40000
888665555
5
Hùng
J
Nguyễn
Văn
999887777
19/1/1968
Bắc Giang
F
25000
987654321
4
Huệ
S
Trần Thị
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
5
Mai
V
Nguyễn
Tuyết
987987987
29/3/1969
Đà Lạt
M
25000
987654321
4
Đào
E
Trần Thị
888665555
10/11/1937
Hải Phòng
M
55000
null
1
Dept
DNUMBER
DLOCATION
1
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
19/6/1981
Works_On
ESSN
PNO
HOURS
123456789
1
32.5
123456789
2
7.5
666884444
3
40.0
453453453
1
20.0
453453453
2
20.0
333445555
2
10.0
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
Dependent
ESSN
DEPENDENT_NAME
SEX
BDATE
RELATIONSHIP
333445555
Hồng
F
05/4/1986
Con gái
333445555
Hùng
M
25/10/1983
Con trai
333445555
Lan
F
03/5/1958
Vợ
11
Ở đây, đối tƣợng đƣợc định nghĩa là bộ ba (định danh, kiến tạo kiểu, trạng thái) và
các bộ tạo kiểu sẵn có là atom, set, và tuple. Ta dùng i
1
, 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
, atom, „Nghiên cứu‟)
o
6
= (i
6
, atom, „22/5/1998‟)
o
7
= (i
7
, set, {i
1
, i
2
, i
3
})
o
8
= (i
8
, tuple, <DNAME:i
5
, DNUMBER:i
4
, MGR:i
9
, LOCALTION:i
7
,
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
15
, i
16
, i
17
})
o
12
= (i
12
, tuple, <FNAME:i
18
, MINIT:i
19
,
LNAME:i
20
, SSN:i
21
, …,
SALARY:i
26
, SUPERVISOR:i
27
, DEPT:i
28
>)
Sáu đối tƣợng (o
1
–
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
số nút bên trong tƣơng ứng trong hai đồ thị có thể là đối tƣợng với OID khác
nhau.
Ví dụ 1.4 Minh họa sự khác nhau giữa hai định nghĩa về so sánh bằng trạng thái đối
tƣợng:
o
1
= (i
1
, tuple, <a
1
:i
4
, a
2
:i
6
>)
o
2
= (i
2
, tuple, <a
1
:i
5
, a
2
:i
6
>)
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)
12
Đối tƣợng o
1
và o
2
có trạng thái bằng nhau, trạng thái tại mức nguyên tử là giống
nhau, nhƣng giá trị trỏ tới là các đối tƣợng khác biệt o
4
và o
5
. Trạng thái của các đối
tƣợng o
1
và o
3
là đồng nhất, mặc dù bản thân đối tƣợng có OID khác nhau. Tuy trạng
thái của o
4
và o
5
là đồng nhất, nhƣng trên thực tế o
4
và o
5
là bằng nhau chứ không
đồng nhất, bởi vì chúng có OID khác nhau.
Các ký hiệu dùng trong đồ thị nhƣ sau:
object
tuple
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;
dept: Department; );
define type Date
tuple ( year: interger;
month: interger;
day: interger; );
define type Department
tuple ( dname: string;
dnumber: integer;
mgr: tuple ( manager:Employee; startdate: Date; );
locations: set(string)
employees: set(Employee);
projects: set(Project); );
Thuộc tính dept của Employee hoặc projects của Department là thuộc tính tham
chiếu đến đối tƣợng khác, mô tả mối quan hệ giữa các kiểu đối tƣợng. Ví dụ, thuộc
tính dept của Employee có kiểu Department, và từ đó đƣợc dùng tham chiếu tới đối
tƣợng Department cụ thể (nơi Employee làm việc). Giá trị của thuộc tính đó sẽ nhƣ là
OID cho đối tƣợng Department cụ thể. Ta sử dụng liên kết hai ngôi (binary
relationship) có liên kết một hƣớng hoặc cả liên kết ngƣợc (inverse reference) để biểu
diễn. Ví dụ, các thuộc tính employees của Department có giá trị là tập các tham chiếu
(tập các OID) đến các đối tƣợng kiểu Employee, là các nhân viên làm việc trong
phòng ban đó. Liên kết ngƣợc là thuộc tính dept của Employee.
14
1.2.4 Bao gói và che giấu thông tin
Khái niệm bao gói liên quan đến khái niệm kiểu dữ liệu trừu tƣợng và che giấu
thông tin trong ngôn ngữ lập trình và cơ sở dữ liệu đối tƣợng. Ý tƣởng chính là định
nghĩa hành vi của kiểu đối tƣợng dựa trên các phép toán có thể áp dụng từ bên ngoài
cho đối tƣợng có kiểu đó. Cấu trúc bên trong của đối tƣợng đƣợc che dấu, và đối tƣợng
chỉ truy cập đƣợc thông qua các phép toán đƣợc định nghĩa trƣớc.
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;
(* loại bỏ một employee từ department *)
end Department;
Phƣơng thức cho mỗi phép toán phải đƣợc định nghĩa bằng cách sử dụng ngôn
ngữ lập trình.
15
Phép toán, thuộc tính thƣờng áp dụng cho đối tƣợng bằng cách sử dụng dấu chấm
„.‟. Ví dụ, nếu d tham chiếu tới đối tƣợng department, ta có thể yêu cầu phép toán
no_of_emps bằng cách viết d.no_of_emps.
Một OODBMS thƣờng kết hợp chặt chẽ với ngôn ngữ lập trình hƣớng đối tƣợng
(OOPL). Một đối tƣợng thƣờng đƣợc tạo ra bởi việc thi hành phép toán tạo đối tƣợng.
Đối tƣợng tạm thời tồn tại trong khi thực hiện chƣơng trình và bị loại bỏ khi chƣơng
trình kết thúc. Đối tƣợng bền vững đƣợc lƣu trữ trong cơ sở dữ liệu và tồn tại sau khi
chƣơng trình kết thúc. Cơ chế điển hình tạo đối tƣợng bền vững là đặt tên (naming) và
khả năng tiếp cận (reachability).
Cơ chế đặt tên cung cấp cho đối tƣợng tên bền vững duy nhất, từ đó nó có thể
đƣợc lấy về bởi chƣơng trình hoặc chƣơng trình khác. Tên đối tƣợng bền vững có
đƣợc thông qua khai báo cụ thể hoặc thao tác trong chƣơng trình nhƣ ví dụ 1.7. Tên
bền vững đƣợc dùng nhƣ điểm vào cơ sở dữ liệu (entry points) để từ đó ngƣời dùng và
ứng dụng có thể bắt đầu truy cập vào cơ sở dữ liệu.
Ví dụ, tất cả đối tƣợng trong hình 1.1 là dẫn đến đƣợc từ đối tƣợng o
8
; vì vậy,
nếu o
8
đƣợc tạo bền thì tất cả các đối tƣợng khác trong cũng trở nên bền vững.
Ví dụ 1.7: Tạo đối tƣợng bền vững bằng naming và reachability
defineclass DepartmentSet:
type set(Department);
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.
Sự khác biệt giữa mô hình cơ sở dữ liệu truyền thống và cơ sở dữ liệu hƣớng đối
tƣợng là khía cạnh này. Trong mô hình cơ sở dữ liệu truyền thống, nhƣ mô hình quan
hệ, tất cả các đối tƣợng đều đƣợc coi là bền vững. Do đó, khi kiểu thực thể hay lớp
nhƣ Employee đƣợc định nghĩa trong mô hình EER, nó mô tả cho cả hai loại: khai
báo kiểu cho Employee và tập bền tất cả đối tƣợng Employee. Với cách tiếp cận
hƣớng đối tƣợng, khai báo lớp Employee chỉ là xác định kiểu và các phép toán của đối
tƣợng lớp đó. Ngƣời dùng phải định nghĩa đối tƣợng bền kiểu set(Employee) hoặc
list(Employee) mà giá trị là tập các tham chiếu tới tất cả đối tƣợng bền Employee nếu
muốn.
1.2.5. Phân cấp kiểu và kế thừa
Trong hầu hết các ứng dụng cơ sở dữ liệu, có rất nhiều đối tƣợng có cùng kiểu
hoặc lớp. Do đó, cơ sở dữ liệu hƣớng đối tƣợng phải cung cấp khả năng phân lớp đối
tƣợng dựa trên kiểu của chúng. Một yêu cầu đƣợc đặt ra là hệ thống phải cho phép
định nghĩa kiểu mới dựa trên các kiểu có sẵn, dẫn tới kế thừa kiểu (hoặc lớp) [10].
Một kiểu đƣợc định nghĩa bằng việc gán cho nó một tên, sau đó định nghĩa số
thuộc tính và phép toán (phƣơng thức) cho kiểu đó. Các thuộc tính và phƣơng thức có
thể đƣợc gọi chung là hàm, thuộc tính đƣợc coi là hàm không có đối số. Tên hàm dùng
để tham chiếu tới giá trị của thuộc tính hoặc giá trị kết quả của phép toán (phƣơng
thức). Ở đây, ta dùng thuật ngữ hàm, để chỉ cả hai thuộc tính và phép toán của kiểu đối
tƣợng.
Một cách đơn giản nhất để định nghĩa kiểu bằng cách tạo một tên kiểu, sau đó
liệt kê các tên hàm:
TYPE_NAME: function, function, . . . , function
Ví dụ 1.8: Định nghĩa kiểu PERSON
PERSON: Name, Address, Birthdate, Age, SSN
Trong kiểu PERSON, Name, Address, SSN, và Birthdate dùng nhƣ các thuộc
tính, hàm Age có dùng nhƣ phƣơng thức để tính toán tuổi từ giá trị của thuộc tính
Birthdate và giá trị ngày tháng hiện tại.
Khái niệm kiểu con (subtype) là cần thiết khi ngƣời dùng phải tạo ra kiểu mới
tƣơng tự nhƣng không giống với kiểu đã định nghĩa. Sau đó, kiểu con kế thừa toàn bộ
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
Phép toán Area có thể đƣợc thực hiện theo nhiều cách khác nhau đối với mỗi
kiểu con, phụ thuộc vào vùng tính toán là hình chữ nhật, hình tam giác và hình tròn.
Thuộc tính ReferencePoint có ý nghĩa khác nhau đối với mỗi kiểu con. Nó có thể là
tâm của các đối tƣợng RECTANGLE và CIRCLE, nhƣng lại là trọng tâm
TRIANGLE. Một số hệ thống cơ sở dữ liệu hƣớng đối tƣợng cho phép đặt lại tên
(renaming) của hàm đƣợc kế thừa trong kiểu con khác để chặt chẽ hơn về mặt ý nghĩa.
Một cách để khai báo ba kiểu con là chỉ ra giá trị của thuộc tính Shape nhƣ điều kiện
bắt buộc cho mỗi kiểu con:
RECTANGLE subtype-of GEOMETRY_OBJECT (Shape=„rectangle‟):
Width, Height
TRIANGLE subtype-of GEOMETRY_OBJECT (Shape=„triangle‟): Side1,
Side2, Angle
CIRCLE subtype-of GEOMETRY_OBJECT (Shape=„circle‟): Radius
Chỉ các đối tƣợng GEOMETRY_OBJECT có Shape=„rectangle‟ là của kiểu con
RECTANGLE, tƣơng tự nhƣ vậy với hai kiểu con còn lại. Trong trƣờng hợp này, tất
cả các hàm của kiểu cha GEOMETRY_OBJECT đƣợc kế thừa bởi mỗi kiểu con trong
18
ba kiểu đó, nhƣng giá trị của thuộc tính Shape bị giới hạn bởi giá trị nhập vào cho mỗi
kiểu con.
Có hai loại kế thừa:
Kế thừa đơn: Lớp con kế thừa một lớp cha
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
Employee
Student
SalePerson
Developer
Person
Employee
Student
PartTimeStudent
19
dụ, xét đối tƣợng là hình ảnh hai chiều. Giả sử rằng ứng dụng cần lựa chọn tập mẫu
nào đó từ tập đối tƣợng. Trong trƣờng hợp này, ngƣời dùng phải cung cấp chƣơng
trình nhận dạng mẫu nhƣ là phƣơng thức của đối tƣợng ảnh đó. Sau đó, OODBMS lấy
về một đối tƣợng từ cơ sở dữ liệu và chạy phƣơng thức nhận dạng mẫu trên nó để xác
định đối tƣợng có chứa các mẫu yêu cầu hay không.
Một OODBMS cho phép ngƣời dùng tạo mới kiểu, và các kiểu đó bao gồm cấu
trúc và các phép toán, ta có thể xem OODBMS có hệ thống kiểu mở rộng (extensible
type system). Sau đó, ứng dụng có thể dùng hoặc sửa đổi các kiểu bằng cách tạo ra các
kiểu con của các kiểu đƣợc cung cấp trong thƣ viện. Tuy nhiên, bản thân DBMS phải
cung cấp khả năng lƣu trữ và phục hồi các đối tƣợng đó một cách hiệu quả.
1.2.6.2. Đối tượng phức tạp có cấu trúc
Đối tƣợng phức tạp có cấu trúc đƣợc định nghĩa bằng cách áp dụng lặp đi lặp lại
các kiểu đƣợc cung cấp bởi OODBMS. Ví dụ, xem lại đối tƣợng DEPARTMENT
trong hình 1.1, ở mức đầu tiên, đối tƣợng có cấu trúc tuple với 6 thuộc tính: DNAME,
DNUMBER, MGR, LOCATIONS, EMPLOYEES, và PROJECTS. Tuy nhiên, chỉ hai
thuộc tính DNAME và DNUMBER có giá trị cơ bản; 4 thuộc tính khác có giá trị phức
tạp và qua đó xây dựng mức thứ hai của đối tƣợng cấu trúc phức tạp. MGR có cấu trúc
tuple, LOCATIONS, EMPLOYEES, PROJECTS có cấu trúc set. Ở mức thứ 3, với
mỗi giá trị tuple MGR ta có một thuộc tính cơ bản (MANAGERSTARTDATE) và
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
subtype-of
GEOMETRY_OBJECT (Shape=„triangle‟): Side1, Side2, Angle
CIRCLE subtype-of GEOMETRY_OBJECT (Shape=„circle‟): Radius
Ở đây, hàm Area() đƣợc khai báo cho mọi đối tƣợng có kiểu
GEOMETRY_OBJECT. Tuy nhiên, việc thực hiện phƣơng thức Area() có thể khác
nhau với mỗi kiểu con của GEOMETRY_OBJECT. Để có thể thực hiện chung cho các
tính toán diện tích của GEOMETRY_OBJECT một cách tổng quát (ví dụ, viết một
thuật toán chung để tính toán diện tích cho đa giác), và sau đó viết lại thuật toán để
tính toán các vùng của kiểu cụ thể của đối tƣợng hình học nhƣ hình tròn, hình chữ
nhật, tam giác,… Trong trƣờng hợp này, hàm Area() đƣợc nạp chồng bằng phƣơng
pháp khác. OODBMS bây giờ phải lựa chọn phƣơng pháp thích hợp cho hàm Area
dựa trên kiểu của đối tƣợng hình học mà nó áp dụng.
Ví dụ 1.11: Việc tính lƣơng cho ngƣời làm việc ở các lĩnh vực khác nhau trong cùng
một cơ quan.
NHANVIEN: có hàm Lƣơng = 730 * Hệ số
GIAOVIEN: có hàm Lƣơng = Lƣơng + giảng dạy xa
CB HANH CHINH: có hàm Lƣơng = Lƣơng + tiền quản lý
1.2.7.2. Đa kế thừa và kế thừa lựa chọn
Đa kế thừa
Đa kế thừa trong phân cấp kiểu xảy ra khi một kiểu con T là kiểu con của hai
(hay nhiều) kiểu, do đó kế thừa các hàm (thuộc tính và phƣơng thức) của cả hai (hay
nhiều) kiểu cha (supertype). Ví dụ, ta tạo kiểu ENGINEERING_MANAGER là kiểu
con của hai kiểu MANAGER và ENGINEER. Điều này dẫn tới việc tạo kiểu mạng
(lattice) chứ không phải kiểu phân cấp. Một vấn đề xảy ra với đa kế thừa là các kiểu
cha mà kiểu con kế thừa có thể có các hàm khác nhau nhƣng giống tên nhau tạo nên sự
nhập nhằng. Ví dụ, cả hai MANAGER và ENGINEER đều có hàm Salary. Nếu hàm
Salary thực hiện bởi các phƣơng thức khác nhau trong trong các kiểu cha MANAGER
và ENGINEER, khi đó tồn tại nhập nhằng khi kiểu con
ENGINEERING_MANAGER kế thừa. Có thể cả hai ENGINEER và MANAGER kế
thừa Salary từ cùng một kiểu cha (chẳng hạn EMPLOYEE) mức cao hơn trong mạng.
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
hạt nhân của nhiều hệ quản trị cơ sở dữ liệu khác nhau.
Chuẩn ODMG – 93 đƣợc công bố năm 1993 và đƣợc chỉnh sửa thành phiên bản
1.1 năm 1994. Phiên bản 2.0 (1997) của chuẩn định nghĩa một mô hình đối tƣợng dựa
trên mô hình đối tƣợng hạt nhân, đƣợc đề xuất bởi nhóm quản trị đối tƣợng (OMG –
Object Management Group). Phiên bản mới nhất là 3.0 (1999) nâng cao khả năng kết
nối với Java [13].
Những thành phần cơ bản của ODMG 3.0 là:
Mô hình hƣớng đối tƣợng
Ngôn ngữ đặc tả đối tƣợng
Ngôn ngữ truy vấn đối tƣợng
Ngôn ngữ kết hợp C
++
, Smalltalk, Java
1.3.1.1. Đối tượng và literal
Đối tượng
Một đối tƣợng đƣợc mô tả bởi 4 đặc điểm: định danh, tên, thời gian sống, cấu
trúc.
Định danh của đối tƣợng là bắt buộc và duy nhất.
Ngoài định danh, các đối tƣợng có thể có tên trong cơ sở dữ liệu dùng để tham
chiếu đến đối tƣợng trong chƣơng trình và hệ thống có thể xác định đối tƣợng bằng tên
22
đó. Một số đối tƣợng kiểu nhƣ extents sẽ có tên duy nhất. Các tên này sử dụng nhƣ các
điểm vào cơ sở dữ liệu.
Thời gian sống chỉ ra đối tƣợng là bền hay tạm thời.
Cấu trúc của đối tƣợng xác định cách đối tƣợng đƣợc xây dựng bằng cách sử
dụng các bộ tạo kiểu.
Kiểu của đối tƣợng gồm:
Kiểu nguyên tử (atom): integer, real, boolean, string
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 Object{
…
Boolean same_as(in Object other_object);
23
Object copy();
void delete();
};
Các phép toán của Object:
same_as(in Object other_object): so sánh với các đối tƣợng khác để nhận dạng.
o.same_as(p)
Kết quả trả về là true nếu định danh của p giống của o, ngƣợc lại trả về false.
copy(): tạo ra bản sao mới của đối tƣợng. Ta viết:
p = o.copy()
delete(): xoá đối tƣợng
Có thể lựa sử dụng ký hiệu mũi tên (->) để thay thế cho dấu chấm (.). Ví dụ, o-
>same_as(p) hoặc o->copy().
Ví dụ 1.13 Một số giao diện chuẩn của literals cấu trúc
Interface Date : Object{enum Weekday{Sunday, Monday, Tuesday,
Wednesday, Thursday, Friday, Saturday}
enum Month{January, February, March, April, May, June, July, August,
September, October, November, December }
unsigned short year();
unsigned short month();
unsigned short day();
…
boolean is_equal(in Date other_Date);
boolean is_greater(in Date other_Date);
…
};
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{
