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ẢNG KÝ HIỆU CÁC CHỮ VIẾT TẮT 1 ANSI American National Standards Institute Viện Tiêu chuẩn Quốc gia Hoa Kỳ giúp của máy tính tính của máy tính Engineering Kỹ nghệ phần mềm với sự trợ giú

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

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

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

BẢNG KÝ HIỆU CÁC CHỮ VIẾT TẮT

1 ANSI American National Standards Institute Viện Tiêu chuẩn Quốc

gia Hoa Kỳ

giúp của máy tính

tính

của máy tính

Engineering

Kỹ nghệ phần mềm với sự trợ giúp của máy tính

Manufacturing

Chế tạo tích hợp với máy tính

đối tượng

đối tượng

hướng đối tượng

System

Hệ quản trị cơ sở dữ liệu với mô hình quan

hệ

DANH MỤC CÁC HÌNH VẼ

1 Hình 1.1 Minh họa đối tượng phức tạp DEPARTMENT như một đồ thị 12

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

10 Hình 2.2Tham 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

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

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ư O2 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

 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, O2, 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

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ư:

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ỳ ý

 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

( 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 {i1, i2,…,in}, 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 <a1:i1, a2:i2, an:in>, trong

đó mỗi aj là tên thuộc tính và ij là định danh Nếu c = list, giá trị v là danh sách có thứ

tự [i1, i2, …,in] đị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 đó

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

Ở đâ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 i1, i2, i3, chỉ định danh của đối tượng

o12 = (i12, tuple, <FNAME:i18, MINIT:i19,LNAME:i20, SSN:i21, …,

SALARY:i26, SUPERVISOR:i27, DEPT:i28>) Sáu đối tượng (o1 –o6) có giá trị nguyên tử Đối tượng o7 là đối tượng giá trị tập Đối tượng là o8 đố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 oi đượ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 oi 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 oi có giá trị nguyên tử, ta

vẽ một cung có hướng từ nút oi đế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:

Đối tƣợng o1 và o2 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 o4 và o5 Trạng thái của các đối tƣợng o1 và o3 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 o4 và o5 là đồng nhất, nhƣng trên thực tế o4 và o5 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:

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;

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

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;

define class Department

type tuple( dname: string;

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

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 o8; vì vậy, nếu o8 đượ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 *)

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

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

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í

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]

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

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

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.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à:

Đị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

đó 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);

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{

…

unsigned short year();

unsigned short month();

unsigned short day();

unsigned short hour();

unsigned short minute();

unsigned short second();

unsigned short millisecond();

…

Timestamp plus(in Interval some_Interval);

Timestamp minus(in Interval some_Interval);

boolean is_equal(in Timestamp other_Timestamp);

boolean is_greater(in Timestamp other_Timestamp);

};

Interface Interval : Object{

unsigned short day();

unsigned short hour();

unsigned short minute();

unsigned short second();

unsigned short millisecond();

…

Interval plus(in Interval some_Interval);

Interval minus(in Interval some_Interval);

Interval product(in long some_value);

Interval quotient(in long some_value);

boolean is_equal(in Interval other_Interval);

boolean is_greater(in Interval other_Interval);

};

Ví dụ 1.14 Định nghĩa giao diện cho đối tƣợng tập

Interface Collection : Object{

exception ElementNotFound{any element;};

unsigned long cardinality();

boolean is_empty();

…

boolean contains_element(in any element);

void insert_element(in any element);

void remove_element(in any element) raises(ElementNotFound); Iterator create_iterator(in boolean satble);

…

};

any get_element() raises(NoMoreElements);

void next_position() raises(NoMoreElements);

…

};

Interface Set : Collection{

Set creat_union(in Set other_set);

…

boolean is_subset_of(in Set other_set);

};

Interface Bag : Collection{

unsigned long occurrences(in any element);

Bag creat_union(in Bag other_bag);

…

};

Interface List : Collection{

exception Invalid_Index{unsigned long index};

void remove_element_at(in unsigned long position) raises(InvalidIndex); any retrieve_element_at(in unsigned long position) raises(InvalidIndex); void replace_element_at(in any element, in unsigned long position) raises(InvalidIndex);

void insert_element_after(in any element, in unsigned long position) raises(InvalidIndex);

List concat(in List other_list);

void append(in List other_list);

…

};

Interface Array : Collection{

exception Invalid_Index{unsigned long index;};

void remove_element_at(in unsigned long index) raises (InvalidIndex); any retrieve_element_at(in unsigned long index) raises (InvalidIndex); void replace_element_at(in unsigned long index) raises (InvalidIndex); void resize(in unsigned long new_size)

};

struct Association {any key; any value;};

Interface Dictionary : Collection{

exception KeyNotFound{any key;};

void bind(in any key, in any value);

void unbind(in any key) raises(KeyNotFound);

any lookup(in any key) raises (KeyNotFound);

boolean contains_key(in any key)

};

1.3.1.2 Giao diện xây dựng sẵn cho các đối tượng tập

Các đối tượng tập kế thừa giao diện Collection cơ bản như trong ví dụ 1.14 trình bày các phép toán cho tất cả đối tượng tập Đối tượng tập o có các phép toán sau:

 o.cardinality(): trả về số phần tử trong tập

 o.is_empty(): trả về true nếu o là tập rỗng, trường hợp khác trả về false

 o.insert_element(e): chèn hoặc xóa một phần tử e vào o

 o.remove_element(e): xóa một phần tử e trong tập o

 o.contains_element(e): trả về true nếu tập o có chứa phần tử e, trường hợp khác trả về false

 Lệnh i = o.create_iterator(): tạo một đối tượng bộ lặp i cho đối tượng tập o, có thể dùng i để duyệt qua các phần tử trong tập Giao diện của đối tượng iterator như trong Ví dụ 1.14

o i.reset(): chuyển bộ lặp đến phần tử đầu tiên trong tập hợp (với tập không sắp thứ tự, có thể là phần tử bất kỳ)

o i.next_position(): chuyển bộ lặp tới phần tử tiếp theo

o i.get_element(): lấy về phần tử hiện tại, là phần tử tại vị trí hiện tại của

bộ lặp (iterator)

Đối tượng tập được bổ sung là Set, List, Bag, Array, và Dictionary, các đối tượng này kế thừa các phép toán của giao diện Collection

Kiểu đối tượng Set<t> dùng tạo đối tượng mà giá trị của đối tượng o là tập các

phần tử có kiểu t Giao diện Set gồm các phép toán bổ sung:

 p = o.create_union(s) (Ví dụ 1.14 ): trả về đối tượng mới p của kiểu Set<t> là hợp của hai tập o và s

 create_intersection(s), create_difference(s)

 o.is_subset_of(s): trả về true nếu đối tượng tập o là tập con của đối tượng tập s, trường hợp khác trả về false

 is_proper_subset_of(s), is_superset_of(s), và is_proper_superset_of(s) không trình bày trong Ví dụ 1.14

Kiểu đối tượng Bag<t> cho phép sự trùng lặp các đối tượng trong tập và kế thừa

giao diện Collection Các phép toán là:

 create_union(b), create_intersection(b), và create_difference(b): trả về đối tượng mới của kiểu Bag<t> Ví dụ, p = o.create_union(b) trả về một đối tượng Bag p là hợp của o và b (giữ lại các phần tử trùng lặp)

 o.occurrences_of(e): trả về số phần tử trùng lặp e trong bag o

Kiểu đối tượng List<t> kế thừa các phép toán của Collection và được dùng để

tạo tập phần tử có thứ tự Giá trị của mỗi đối tượng o là danh sách có thứ tự các phần

tử có kiểu t Một số phép toán của kiểu List<t> trình bày như Ví dụ 1.14 Các phép toán là:

 Các phép toán thêm phần tử là: o.insert_element_first(e), o.insert_element_last(e),o.insert_element_after(e,i),

 Phép toán p = o.concat(l) tạo danh sách mới p là kết quả việc nối các danh sách

o và l (các phần tử trong danh sách o nối sau danh sách l)

Kiểu đối tượng Array<t> kế thừa các phép toán của Collection Kiểu này có số

phần tử cố định Các phép toán là:

 o.replace_element_at(i,e) thay thế phần tử tại vị trí i bởi phần tử e;

 e = o.remove_element_at(i), lấy về phần tử thứ i và thay thế nó bởi giá trị null;

 e = o.retrieve_element_at(i), lấy về phần tử đơn tại vị trí i trong mảng

Kiểu cuối cùng của đối tượng tập là kiểu Dictionary<k, v> Nó cho phép tạo một

tập các bộ <k, v>, trong đó giá trị k (khóa) là bắt buộc Nó cho phép lấy về cặp giá trị

cụ thể tương ứng với giá trị khóa (giống như chỉ số) Các phép toán là:

 o.bind(k,v): ràng buộc giá trị v với khóa k như là sự kết hợp <k,v> trong tập

 o.unbind(k): loại bỏ ràng buộc v với k

 o v = o.lookup(k): trả về giá trị v liên quan tới khóa k trong o

 o.contains_key(k): trả về true nếu khóa k tồn tại trong o, trường hợp khác trả về false

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

1.3.1.3 Các đối tượng người dùng định nghĩa

Trong ODL ta sử dụng từ khoá Class để tạo và cấu trúc đối tượng Bất kỳ đối tượng nào do người dùng tạo ra không thuộc đối tượng sưu tập mà được gọi là đối tượng nguyên tử Ví dụ, trong cơ sở dữ liệu UNIVERSITY (Hình 1.6, Ví dụ 1.17), người dùng có thể chỉ ra kiểu đối tượng (lớp) cho các đối tượng Student Hầu hết các đối tượng là đối tượng có cấu trúc Kiểu nguyên tử người dùng định nghĩa dựa trên ba thành phần: thuộc tính, mối quan hệ và phép toán

Ví dụ1.15 Các thuộc tính, các quan hệ, ứng xử trong định nghĩa lớp

Class Employee

( extent all_employees key ssn) {

attribute string name;

attribute string ssn;

attribute date birthdate;

attribute enum Gender {M,F} sex;

attribute short age;

realtionship Department works_for

inverse Department::has_emps;

void reassign_emp(in string new_dname) raises(dname_not_valid);

};

Class Department

( extent all_department key dname, dnumber) {

attribute string dname;

attribute short dnumber;

attribute struct Dep_Mgr {Employee manager, date startdate} mgr; attribute set<string>) locations;

attribute set <struct Projs {string projname, time weekly_hours}> projs; realtionship set <Employee> has_emps inverse Employee::work_for; void add_emp(in string new_ename) raises(ename_not_valid);

void change_manager(in string new_mgr_name; in date startdate)

};

Trong Ví dụ 1.15, tồn tại liên kết giữa Employee đến Department bằng liên kết works_for của Employee Hướng ngược lại, mỗi Department liên kết đến tập các Employees bằng liên kết has_emps của Department Từ khóa inverse chỉ ra thuộc tính

mô tả mối liên kết ngược Bằng cách chỉ ra mối liên kết ngược, hệ thống cơ sở dữ liệu

có thể duy trì tính toàn vẹn tham chiếu của quan hệ một cách tự động

1.3.1.4 Giao diện, lớp và kế thừa

Giao diện là một đặc tả hành vi trừu tượng của kiểu đối tượng, xác định định danh phép toán Mặc dù giao diện có thể có các đặc tính trạng thái (thuộc tính mô tả và liên kết) như một phần của nó, nhưng chúng không được kế thừa từ giao diện Giao

diện là noninstantiable, có nghĩa là không thể tạo đối tượng tương ứng với một định

nghĩa giao diện

Lớp là một đặc tả hành vi trừu tượng và trạng thái trừu tượng của kiểu đối tượng,

có nghĩa là có thể tạo ra đối tượng tương ứng theo định nghĩa lớp

Mối quan hệ kế thừa khác gọi là EXTENDS và chỉ định bằng từ khóa extends,

được dùng để kế thừa hoàn toàn các trạng thái và ứng xử trong các lớp Trong kế thừa EXTENDS, cả hai kiểu cha và kiểu con phải là các lớp Không cho phép đa kế thừa thông qua EXTENDS Tuy nhiên, cho phép đa kế thừa hành vi thông qua “:” Do đó, một giao diện có thể kế thừa hành vi từ một vài giao diện khác Một lớp có thể kế thừa hành vi từ các giao diện thông qua “:”, hơn nữa, có thể kế thừa hành vi và trạng thái của nhiều nhất là một lớp khác thông qua EXTENDS

1.3.1.5 Extents, khóa và đối tượng Factory

Trong mô hình đối tượng ODMG 2.0, có thể khai báo extent cho kiểu đối tượng

thông qua khai báo lớp extent là tên chứa tất cả đối tượng bền của lớp extent được coi như là tập đối tượng, chứa tất cả các đối tượng bền của lớp Trong Ví dụ 1.15, các lớp Employee và Department có các extent là all_employees và all_departments Điều này giống với việc tạo hai đối tượng có các kiểu là Set<Employee> và Set<Department>, và tạo bền bằng naming là all_employees và all_departments Extents cũng được sử dụng để thi hành mối quan hệ set/subset giữa extents của kiểu cha và kiểu con của nó Nếu hai lớp A và B có extents là all_A và all_B, và lớp B là kiểu con của lớp A (nghĩa là, lớp B EXTENDS lớp A), thì tập đối tượng trong all_B phải là tập con của các đối tượng trong all_A tại mọi thời điểm Ràng buộc này được thực thi tự động bởi hệ thống cơ sở dữ liệu

Một lớp với extent có một hoặc nhiều khóa Khóa là một hoặc nhiều tính chất (thuộc tính hoặc liên kết) mà giá trị xác định duy nhất đối tượng trong extent Như trong Ví dụ 1.15, lớp Employee có thuộc tính ssn là khóa (mỗi đối tượng Employee trong extent phải có một giá trị ssn duy nhất) Trong lớp Department có hai khóa khác nhau là dname và dnumber (mỗi Department phải có bộ dname và dnumber duy nhất) Với khóa phức hợp được tạo bởi một số thuộc tính, các thuộc tính đó được đặt trong dấu ngoặc đơn Ví dụ, nếu lớp Vehicle có extent là all_vehicles có khóa được tạo bởi hai thuộc tính state và license_number thì chúng được đặt trong dấu ngoặc đơn như (state, license_number) trong khai báo khóa

Đối tượng factory là đối tượng dùng để phát sinh hoặc tạo đối tượng cụ thể thông qua phép toán Giao diện ObjectFactory có một phép toán là new(), tạo đối tượng mới với một Object_Id Kế thừa giao diện này, người dùng tạo các giao diện factory cho mỗi kiểu đối tượng người dùng định nghĩa, và có thể thực thi phép toán new khác nhau cho mỗi kiểu đối tượng Ví dụ 1.16 trình bày giao diện DateFactory được thêm vào phép toán calendar_date tạo ra đối tượng mà giá trị là ngày tháng hiện tại

Ví dụ 1.16: Giao diện minh họa đối tượng factory và đối tượng Database

interface ObjectFactory {

Date calendar_date( in unsigned short year, in unsigned short month,

in unsigned short day) raises(lnvalidDate);

void bind(in any some_object, in string object_name);

Object unbind(in string name);

Object lookup(in string object_name) raises(ElementNotFound); };

1.3.2 Ngôn ngữ định nghĩa đối tượng (ODL)

ODL được dùng để tạo lược đồ cơ sở dữ liệu đối tượng ODL được thiết kế để hỗ trợ cấu trúc ngữ nghĩa của mô hình ODMG 2.0 và độc lập với ngôn ngữ lập trình Nó chủ yếu được dùng để tạo ra đối tượng, là lớp và giao diện ODL không phải là ngôn ngữ lập trình đầy đủ Người sử dụng có thể mô tả lược đồ cơ sở dữ liệu trong ODL độc lập với ngôn ngữ lập trình, sau đó sử dụng các ngôn ngữ cụ thể để kết hợp các xây dựng trong ODL chuyển vào ngôn ngữ lập trình như C++, Smalltalk, và Java

Ví dụ 1.17 mô tả cách chuyển đổi từ cơ sở dữ liệu UNIVERSITY Kiểu thực thể được chuyển thành lớp trong ODL, và kế thừa thực hiện bằng cách sử dụng

EXTENDS Tuy nhiên, không có cách trực tiếp thực hiện đa kế thừa Trong ví dụ 1.17,

các lớp Person, Faculty, Student, và GradStudent có các extents là persons, faculty, students, và grad_students Faculty và Student EXTENDS Person, GradStudent EXTENDS Student Do đó, tập của students (và tập của faculty) sẽ được ràng buộc như là tập con của tập persons tại mọi thời điểm Tương tự như vậy, tập grad_students

sẽ là tập con của students Đồng thời, các đối tượng Student Faculty sẽ kế thừa các tính chất (thuộc tính và liên kết) và các phép toán của Person, và đối tượng GradStudent sẽ kế thừa tính chất (thuộc tính và liên kết) và các phép toán của Student Các lớp Department, Course, Section, và CurrSection trong ví dụ 1.17 là chuyển đổi tương ứng từ các thực thể trong hình 1.6 Lớp Grade tương ứng với mối quan hệ M:N giữa Student và Section trong hình 1.6 Lý do nó được tạo ra như một lớp ngăn cách (không phải cặp liên kết ngược) là vì nó gồm thuộc tính liên kết grade Do đó,

mối quan hệ M:N được chuyển đổi thành lớp Grade, và hai liên kết 1:N, một giữa Student và Grade, một giữa Section và Grade Hai liên kết này được mô tả bằng các thuộc tính liên kết: completed_sections của Student; section và student của Grade; và students của Section Cuối cùng, lớp Degree dùng mô tả phức hợp, thuộc tính đa trị degrees của GradStudent

Hình 1.5 Ký hiệu đồ họa

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

Ví dụ 1.17 Thể hiện của lược đồ cơ sở dữ liệu đối tượng của hình 1.6

Class Person

( extent persons key snn) {

attribute struct Pname {string fname, string mname, string lname} name; attribute string ssn;

Giao diện (is-a) kế

registed_student

registed_in

advisor advises

has_faculty

works_in

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();

};

Class Faculty extends Person

( extent faculty ) {

attribute string rank;

attribute float salary;

attribute string office;

attribute string phone;

relationship Department works_in inverse Department::has_faculty; relationship set <GradStudent> advises inverse GradStudent::advisor; relationship set <GradStudent> on_committee_of

inverse GradStudent::advisor;

void give_raise(in float raise);

void promote(in string new_rank);

};

Class Grade

( extent grade ) {

attribute enum Grade Values{A,B,C,D,F,I,P} grade;

relationship Section section inverse Section::students;

relationship Student student inverse Student::completed_sections;

};

Class Student extends Person

( extent student ) {

attribute string class;

attribute Department minors_in;

relationship Department majors_in inverse Department::has_majors; relationship set <Grade> completed_sections inverse Grade::student; relationship set <CurrSection> registered_in

inverse CurrSection::registered_students;

void change_major(in string dname) raises(dname_not_valid);

float gpa();

void register(in short secno) raises (section_not_valid);

void assign_grade(in short secno; in GradeValue grade)

raises (section_not_valid, grade_not_valid);

};

Class Degree {

attribute string college;

attribute string degree;

attribute string year;

};

Class GradStudent extends Student

( extent grad_students ) {

attribute set<Degree> degrees;

relationship Faculty advisor inverse Faculty::advises;

relationship set <Faculty> committee inverse Faculty::on_committee_of; void assign_advisor(in string lname; in string fname) raises(faculty_not_valid); void assign_committee_member(in string lname; in string fname)

raises(faculty_not_valid);

};

Class Department

( extent Department key dname ) {

attribute string dname;

attribute string dphone;

attribute string doffice;

attribute string college;

attribute Faculty chair

relationship set <Faculty> has_faculty inverse Faculty::works_in;

relationship set <Student> has_majors inverse Student::majors_in;

relationship set <Course> offers inverse Course::offered_by;

};

Class Course

( extent course key cno ) {

attribute string cname;

attribute string dno;

attribute string description;

relationship set <Section> has_sections inverse Section::of_course;

relationship Department offered_by inverse Department::offers;

};

Class Section

( extent section ) {

attribute short secno;

attribute string year;

attribute enum Quarter{Fall, Winter, Spring, Summer} qtr;

relationship set <Grade> students inverse Grade::section;

relationship Course of_course inverse Course::has_sections;

};

Class CurrSection extends Section

noninstantiable, có nghĩa là không đối tƣợng nào đƣợc tạo ra trực tiếp dựa trên giao

diện này Tuy nhiên, các đối tƣợng có kiểu Rectangle, Triangle, Circle,… có thể tạo

ra, và các đối tƣợng này kế thừa tất cả các phép toán của giao diện GeometryObject Khi thừa kế giao diện, chỉ các phép toán đƣợc thừa kế, không thừa kế các tính chất (thuộc tính, liên kết) Do vậy, nếu cần thừa kế các tính chất trong lớp kế thừa, nó phải đƣợc viết lại trong định nghĩa lớp, nhƣ thuộc tính reference_point trong hình 1.7 Các phép toán đƣợc thừa kế có thể thực hiện khác nhau trong mỗi lớp Ví dụ, thực hiện phép toán tính diện tích và chu vi là khác nhau cho các đối tƣợng Rectangle, Triangle,

và Circle

Các lớp đƣợc phép đa kế thừa giao diện, cũng nhƣ đa kế thừa giao diện của giao diện Tuy nhiên, với kế thừa EXTENDS (class), đa kế thừa là không đƣợc phép Do

đó, lớp kế thừa thông qua EXTENDS nhiều nhất là một lớp

“:”

Ví dụ 1.18 Minh họa sự kế thừa thông qua “:”

Interface GeometryObject {

attribute enum Shape{Rectange, Triangle, Circle,…} shape;

attribute struct Point {short x, short y} reference_point;

float perimeter();

float area();

void translate(in short x_translation; in short y_translation);

void rotate(in float angle_of_rotation);

};

Class Rectang : GeometryObject

( extent rectangles) {

attribute struct Point {short x, short y} reference_point;

attribute short length;

attribute short height;

attribute float orientation_angle;

};

Class Triangle : GeometryObject

( extent triangles) {

attribute struct Point {short x, short y} reference_point;

attribute short side_1;

attribute short side_2;

attribute float side1_side2_angle;

attribute float side1_orientation_angle;

};

Class Circle : GeometryObject

( extent circles) {

attribute struct Point {short x, short y} reference_point;

attribute short radius;

};

1.3.3 Ngôn ngữ truy vấn đối tượng (OQL)

Ngôn ngữ truy vấn đối tượng (Object Query Language) là ngôn ngữ truy vấn được đề xuất cho mô hình hướng đối tượng ODMG Nó được thiết kế làm việc chặt chẽ với các ngôn ngữ lập trình như C++, SmallTalk, và Java Do đó, truy vấn OQL nhúng trong ngôn ngữ lập trình có thể trả về đối tượng phù hợp với hệ thống kiểu của ngôn ngữ lập trình đó Ngoài ra, thực hiện phép toán lớp trong lược đồ ODMG có mã được viết trong ngôn ngữ lập trình Cú pháp truy vấn của OQL tương tự cú pháp của SQL, bổ sung các khái niệm của ODMG như định danh, đối tượng phức tạp, phép toán, kế thừa, đa hình và liên kết [10]

Mục tiêu:

 Cho phép truy cập dễ dàng tới cơ sở dữ liệu hướng đối tượng, có thể tích hợp trong C++, Java, Smalltalk,…

 Cung cấp một truy cập phi thủ tục

 Cố gắng giữ lại một phần của ngôn ngữ SQL

 Phù hợp với chuẩn ODMG: cho phép truy vấn tới các tập và tạo ra kết quả là các litteral, đối tượng, tập

 Đảm bảo tính bao gói

Các ví dụ minh họa cho truy vấn OQL dựa trên lược đồ cơ sở dữ liệu UNIVERSITY trong hình 1.6 và ví dụ 1.17

1.3.3.1 Cấu trúc cơ bản, điểm vào cơ sở dữ liệu, và biến Iterator

Cú pháp cơ bản của OQL là select … from … where giống như SQL Ví dụ, đưa

ra các tên khoa trong college là “Engineering”

FROM d in departments

WHERE d.college = „Engineering‟;

Trong đó departments là tên bền

Các câu lệnh trên tương ứng với câu lệnh SQL:

SELECT name

FROM departments as d

WHERE college =„Engineering‟;

Điểm vào cơ sở dữ liệu là cần cho mỗi truy vấn Điểm vào cơ sở dữ liệu là tên

đối tượng bền Với nhiều truy vấn, điểm vào là tên extent của lớp Quan sát tên extent

trong hình 1.6, tên đối tượng departments là kiểu set<Department>; persons là kiểu set<Person>; faculty là kiểu set<Faculty>;

Trong truy vấn Q0 ta sử dụng tên extent là departments làm điểm vào cơ sở dữ liệu tham chiếu đến tập đối tượng bền Mỗi khi tham chiếu tới tập trong truy vấn OQL,

trong Q0 ta định nghĩa một biến bộ lặp (iterator) d để duyệt qua từng đối tượng từ tập

hợp Trong nhiều trường hợp, như trong Q0, truy vấn sẽ lựa chọn các đối tượng từ tập dựa trên điều kiện chỉ ra trong mệnh đề WHERE Trong Q0, chỉ các đối tượng bền d trong tập của departments thỏa mãn điều kiện d.college = „Engineering‟ được lựa chọn cho kết quả truy vấn Đối với mỗi đối tượng được chọn d, giá trị d.dname được lấy về trong kết quả truy vấn Do đó, kiểu kết quả lấy về về của Q0 là bag<string>, bởi vì với mỗi giá trị dname là một xâu (mặc dù trong thực tế kết quả là một tập vì dname là

thuộc tính khóa) Nói chung, kết quả của truy vấn có kiểu bag cho lệnh select … from

và có kiểu set cho lệnh select distinct… from như trong SQL (thêm từ khóa distinct

để loại trừ sự lặp lại)

1.3.3.2 Kết quả của một truy vấn và biểu thức đường dẫn

Kết quả của truy vấn có thể có kiểu bất kỳ trong mô hình đối tượng ODMG Một

truy vấn không nhất thiết phải có cấu trúc select… from …where…, trong trường hợp

đơn giản nhất, chính tên bền là một truy vấn, kết quả là một tham chiếu tới đối tượng bền đó Ví dụ, yêu cầu tìm kiếm

Kết quả là một tham chiếu đến đối tượng cụ thể kiểu Department

Với một điểm vào cơ sở dữ liệu, biểu thức đường dẫn được dùng để mô tả đường dẫn đến thuộc tính và các đối tượng liên quan Biểu thức đường dẫn bắt đầu bằng tên đối tượng bền hoặc biến iterator dùng để duyệt qua đối tượng trong tập Sau tên bền có thể không có hoặc có nhiều tên liên kết hoặc tên thuộc tính được ngăn cách bởi dấu chấm (.)

Giả sử có đối tượng o Khi đó:

 Nếu a là thuộc tính thì “o.a” là biểu thức đường dẫn để truy cập đến giá trị thuộc tính a của đối tượng o

 Nếu r là thuộc tính quan hệ thì biểu thức đường dẫn “o.r” thể hiện kết nối của mối quan hệ khi truy vấn Biểu thức o.r có thể trả về một đối tượng hoặc một tập các đối tượng tùy thuộc vào kiểu của quan hệ r

 Với f là một hàm thì biểu thức “o.f” trả về giá trị hàm f của đối tượng o

Ví dụ, trong cơ sở dữ liệu UNIVERSITY, các truy vấn sau là hợp lệ trong OQL: Q2: csdepartment.chair;

Q2a: csdepartment.chair.rank;

Q2b: csdepartment.has_faculty;

Đầu tiên Q2 trả về đối tượng có kiểu Faculty, bởi vì đó là kiểu của thuộc tính chair trong lớp Department Nó sẽ tham chiếu tới đối tượng Faculty liên quan tới đối tượng department có tên bền là csdepartment thông qua thuộc tính chair; có nghĩa là tham chiếu tới đối tượng Faculty là trưởng khoa Khoa học máy tính

Q2a cũng tương tự, trả về hạng của đối tượng Faculty (trưởng khoa Khoa học máy tính) mà không phải là tham chiếu tới đối tượng; vì vậy, kiểu trả về bởi Q2a là string, là kiểu dữ liệu của thuộc tính rank trong lớp Faculty

Biểu thức đường dẫn Q2 và Q2a trả về các giá trị đơn, bởi vì thuộc tính chair (của Department) và rank (của Faculty) đều là các giá trị đơn và áp dụng cho đối tượng đơn Biểu thức Q2b thì khác, nó trả về đối tượng có kiểu set<Fculty> khi áp dụng cho đối tượng đơn, bởi vì đó là kiểu quan hệ has_faculty của lớp Department Một tập trả

về gồm các tham chiếu tới tất cả các đối tượng Faculty có quan hệ với đối tượng department có tên bền là csdepartment thông qua quan hệ has_faculty; có nghĩa là tham chiếu tới tất cả đối tượng Faculty làm việc trong khoa Khoa học máy tính

Trở lại với việc xếp hạng các giảng viên khoa học máy tính Ta không thể viết: Q3‟: csdepartment.has_faculty.rank;

Nguyên nhân là không rõ ràng đối tượng trả về có thể có kiểu set<string> hoặc bag<string> (kiểu thứ 2 có nhiều khả năng hơn, nhiều giảng viên có thể cùng hạng) Đây là vấn đề nhập nhằng, OQL không cho phép biểu thức như Q3‟ Thay vào đó, phải sử dụng biến iterator duyệt qua tập, như trong Q3a hoặc Q3b dưới đây:

Q3a: select f.rank

tử của tập csdepartment.has_faculty có kiểu set<Faculty> chỉ gồm các giảng viên làm việc trong khoa Khoa học máy tính

degrees:(select struct (deg: d.degree,

yr: d.year, college: d.college)

from d in s.degrees) from s in csdepartment.chair.advises;

Truy vấn này đưa ra (lname, fname, degrees) của các sinh viên do trưởng khoa Khoa học máy tính hướng dẫn

Biến s duyệt qua tập các sinh viên được hướng dẫn trưởng khoa, và biến d duyệt qua degree của các sinh viên Kiểu của kết quả trả về của Q4 là một tập (mức 1) cấu trúc, trong đó mỗi cấu trúc có hai thành phần name và degrees Thành phần name có cấu trúc gồm last_name và first_name, mỗi thành phần có kiểu xâu ký tự Thành phần degrees được định nghĩa bởi một truy vấn nhúng và bản thân nó là một tập (mức 2) cấu trúc, gồm 3 thành phần là xâu ký tự: deg, yr, và college

1.3.3.4 Sắp xếp dữ liệu đưa ra

Chú ý rằng OQL là trực giao (orthogonal) đối với biểu thức đường dẫn Có nghĩa

là các thuộc tính, quan hệ, và tên phép toán (phương thức) có thể hoán đổi cho nhau trong biểu thức đường dẫn, miễn là kiểu hệ thống của OQL không bị ảnh hưởng Ví

dụ, có thể sử dụng truy vấn dưới đây lấy điểm trung bình của tất cả các sinh viên học ở khoa Khoa học máy tính, kết quả gồm first_name, last_name, gpa và được sắp xếp theo gpa

Q5a: select struct (last_name: s.name.lname, first_name:

s.name.fname, gpa: s.gpa)

from s in csdepartment.has_majors where s.class = „senior‟

order by gpa desc, last_name asc, first_name asc;

Đưa ra first_name, last_name, gpa của các sinh viên học ở khoa Khoa học máy tính, lớp senior gpa sắp xếp giảm dần, first_name, last_name sắp xếp tăng dần

Q5b: select struct (last_name: s.name.lname, first_name:

s.name.fname, gpa: s.gpa)

from s in students where s.majors_in.dname = „Computer Science‟ and

s.class = „senior‟

order by gpa desc, last_name asc, first_name asc;