TỔNG QUAN VỀ MÔ HÌNH CƠ SỞ DỮ LIỆU MỨC KHÁI NIỆM VÀ ONTOLOGY
Giới thiệu các mô hình cơ sở dữ liệu mức khái niệm
Mô hình ER được đề xuất bởi P.Chen [1] vào năm 1976, đây là mô hình ở mức khái niệm, mô tả chi tiết một cách logic về tổ chức dữ liệu của một hệ thống thông tin Mô hình ER còn được xem là một trong những mô hình dữ liệu ngữ nghĩa, trên đó có thể xác định được các thực thể của một hệ thống thông tin và ngữ nghĩa của mô hình được thể hiện thông qua mối quan hệ giữa các thực thể
Thực thể là một đối tượng tồn tại mà ta có thông tin về nó và phân biệt được với các đối tượng khác Mỗi tập thực thể có một tập các thuộc tính mà thế giới thực yêu cầu lưu trữ và quản lý Thông tin về mỗi thể hiện trong tập thực thể được xác định bởi một bộ các giá trị của các thuộc tính trong tập thực thể đó Một thuộc tính hay một tập các thuộc tính mà các giá trị của nó là xác định duy nhất một thể hiện trong tập thực thể được gọi là khóa [2]
Tập thực thể yếu là một khái niệm về tập thực thể mà sự tồn tại của nó phụ thuộc vào sự tồn tại của một hay nhiều tập thực thể khác Tập thực thể mà nó phụ thuộc vào gọi là tập thực thể chủ Tập thực thể yếu có tất cả các đặc điểm của một tập thực thể, tuy nhiên khóa của tập thực thể yếu được gọi là khóa bộ phận mà để định danh được thực thể của tập thực thể yếu cần kết hợp khóa bộ phận và khóa của tập thực thể chủ
Thuộc tính là đặc tính của một thể hiện hay một mối quan hệ trên ER Thuộc tính gồm: Thuộc tính đơn là thuộc tính không thể phân nhỏ được; Thuộc tính phức hợp là thuộc tính có thể phân thành nhiều thuộc tính thành phần; Thuộc tính đơn trị là thuộc tính chỉ có tối đa một giá trị cho một thể hiện của tập thực thể; Thuộc tính đa trị là thuộc tính có thể có nhiều giá trị cho một thể hiện của tập thực thể Thuộc tính khóa được sử dụng để xác định duy nhất một thực thể, đảm bảo thỏa điều kiện là một thuộc tính đơn, có thể chỉ có một giá trị, không thể null và phải khác biệt về giá trị
1.1.1.3 Mối quan hệ Để diễn tả số lần tham gia tối thiểu và tối đa của một thực thể vào một mối quan hệ người ta dùng bản số Bản số giúp xác định loại của mối quan hệ là 1:1, 1:N, N:1 hay N:N, tức là để xác định mỗi thể hiện của tập thực thể này có liên hệ với tối đa là bao nhiêu thể hiện của tập thực thể kia thông qua mối quan hệ
Mối quan hệ diễn tả sự liên quan giữa một hay nhiều thực thể với nhau và có thể được mô tả thông qua ngữ nghĩa thế giới thực Giữa các tập thực thể có thể có nhiều mối quan hệ và số lượng các tập thực thể tham gia vào mối quan hệ được gọi là bậc/ngôi của mối quan hệ Một mối quan hệ R có n tập thực thể tham gia E 1,E 2,
…, E n Khi đó, thể hiện của mối quan hệ R này là một tập con của tích Descartes E 1
E 2 … E n Để diễn tả số lần tham gia tối thiểu và tối đa của một thực thể vào một mối quan hệ người ta dùng bản số Bản số giúp xác định loại của mối quan hệ là 1-1, 1-N, N-1 hay N-N, tức là để xác định mỗi thể hiện của tập thực thể này có liên hệ với tối đa là bao nhiêu thể hiện của tập thực thể kia thông qua mối quan hệ
Các loại mối quan hệ bao gồm:
- Mối quan hệ nhị nguyên: Khi hai đối tượng có quan hệ với nhau thì gọi là một mối quan hệ nhị nguyên Một mối quan hệ nhị nguyên có sự tham gia của hai tập thực thể, E i và E j , từ cùng một lớp hoặc từ hai lớp khác nhau, tham gia vào một mối quan hệ R Trong OWL2, mối quan hệ nhị nguyên được mô tả bằng cặp các đối tượng, O i và O j (tương ứng từ lớp C i và C j ), từ cùng một lớp hoặc từ hai lớp khác nhau Mối quan hệ nhị nguyên có hai ràng buộc bản số có dạng (x, y), trong đó x là ràng buộc tham gia tối thiểu, và y là ràng buộc tham gia tối đa Trong đó, x là 0 hoặc 1, và y là
- Mối quan hệ đa nguyên: Là mối quan hệ giữa 3 tập thực thể trở lên
- Mối quan hệ Is-a: mỗi lớp con được đặc trưng bằng cách thiết lập giá trị của một trong các thuộc tính của nó
- Mối quan hệ phản xạ (recursive relationship): là mối quan hệ giữa các thực thể trên cùng một tập thực thể Vì vậy, một thực thể có thể đóng nhiều vai trò trong một mối quan hệ phản xạ [2]
- Mối quan hệ định danh là mối quan hệ giữa tập thực thể yếu và tập thực thể chủ
1.1.2 Mô hình ER mở rộng
Mô hình ER chỉ dừng lại ở việc mô tả các tập thực thể, các mối quan hệ, các thuộc tính, khóa, và các ràng buộc cấu trúc Nó chỉ có thể mô hình hóa được các ứng dụng CSDL truyền thống Tuy nhiên, có nhiều ứng dụng phức tạp đòi hỏi các khái niệm bổ sung nếu muốn mô hình hóa chúng một cách chính xác hơn Vấn đề đặt ra là phải xây dựng một mô hình đáp ứng các yêu cầu trên Do mô hình ER mở rộng chưa có một chuẩn thống nhất nên có nhiều tác giả đã nghiên cứu đến vấn đề này và đưa ra nhiều mô hình khác nhau như: EER, ECR, ERC, ERC+, ORAC (gọi chung là mô hình EER)
Mô hình EER bao gồm tất cả các khái niệm trong mô hình ER Thêm vào đó, bổ sung thêm các khái niệm về lớp cha, lớp con và các khái niệm liên quan đến tổng quát hoá và chuyên biệt hoá
1.1.2.1 Lớp cha, lớp con và sự kế thừa
Mô hình EER gồm khái niệm của một kiểu con hoặc lớp con của một tập thực thể Lớp cha là lớp thực thể tổng quát trong mối quan hệ Is-a, liên quan với một hoặc nhiều lớp con Lớp con là sự phân nhóm (chuyên biệt hóa) từ một lớp cha [2]
Hình 1.1 Biểu diễn lớp cha và lớp con trong mô hình EER
Trong nhiều trường hợp, một tập thực thể có nhiều nhóm con hoặc kiểu con của các thực thể có ý nghĩa và cần được trình bày rõ ràng vì tầm quan trọng của chúng đối với ứng dụng cơ sở dữ liệu Ví dụ một tổ chức có hai loại nhân viên: Nhân viên
10 làm theo giờ: Hoten, CMND, Ngaysinh, Diachi, Bacluong; Nhân viên hưởng lương tháng: Hoten, CMND, Ngaysinh, Diachi, Luong Ta định nghĩa kiểu cha EMPLOYEE và hai kiểu con SALARIED_EMPLOYEE và HOURLY_EMPLOYEE [2]
Sự kế thừa thuộc tính: Là tính chất mà các lớp con kế thừa mọi thuộc tính của lớp cha, đồng thời nó còn kế thừa tất cả các mối quan hệ mà lớp cha tham gia
1.1.2.2 Chuyên biệt hóa và tổng quát hóa a Chuyên biệt hóa
Giới thiệu về Web ngữ nghĩa và Ontology
Hiện nay, các trang web đã trở nên phổ biến nhằm cung cấp thông tin và trình diễn các tài liệu siêu văn bản Đầu tiên, các trang web là những trang HTML tĩnh, tiếp sau đó, web đã tạo một bước ngoặc lớn với các trang HTML động Tuy nhiên, với một lượng lớn các tài nguyên thông tin được cung cấp trên Web, làm cho người dùng khó có thể tìm kiếm chính xác tài nguyên thông tin Vì vậy, Web ngữ nghĩa được ra đời nhằm cho phép định nghĩa và liên kết dữ liệu một cách có ngữ nghĩa hơn, giúp cho máy tính có thể hiểu và hỗ trợ con người xử lý tự động khai thác được thông tin trên Web một cách hiệu quả Để thông tin được xác định ý nghĩa tốt hơn trong web ngữ nghĩa, ontology giúp đặc tả hình thức các loại thực thể trong thế giới thực và chúng liên hệ với nhau như thế nào Vì thế, một ontology cung cấp các mô tả cho các thành phần sau: Các thể hiện; Các lớp trong một lĩnh vực xác định; Các thuộc tính của các lớp; Các quan hệ giữa các lớp
Thể hiện (hay cá thể) là một thành phần cơ bản và mang tính nền tảng của một ontology Các cá thể trong một ontology có thể bao gồm các đối tượng cụ thể như con người, động vật, xe cộ cũng như các cá thể trừu tượng khác như các từ hay con số Tập tất cả các cá thể trong một lớp được gọi là phần mở rộng của lớp đó
Lớp là các nhóm, bộ hoặc tập hợp các đối tượng Chúng có thể chứa các cá thể, các lớp con, hay có thể là một lớp tổng quát (chứa tất cả mọi thứ) Các đối tượng cụ thể thuộc về một lớp được gọi là thể hiện của lớp đó Ví dụ, lớp Vehicle là lớp của tất cả các loại xe, hay các đối tượng có thể được mô tả bởi các tiêu chuẩn để được xem
Các đối tượng trong ontology có thể được mô tả thông qua việc khai báo các thuộc tính của chúng Mỗi một thuộc tính đều có tên và giá trị của thuộc tính đó Các thuộc tính được sử dụng để lưu trữ các thông tin mà đối tượng có Ví dụ, đối tượng
StaffMember bao gồm các thuộc tính như: name, birthday, address, phone Tương tự như lớp, sự phân cấp cũng có thể thực hiện được đối với thuộc tính
Quan hệ giữa các đối tượng trong một ontology cho biết các đối tượng liên hệ với nhau như thế nào trong một ngữ cảnh cụ thể Ví dụ, khái niệm Lecturer và khái niệm AcademicStaff có thể được liên hệ bởi quan hệ "lớp con" Phát biểu đầy đủ của sự kiện như sau : Lớp Lecturer được định nghĩa là lớp con của lớp AcademicStaff
Ngoài ra, ontology còn chứa thêm một số dạng quan hệ khác
Các quan hệ trong ontology có thể được tổ chức dưới dạng phân cấp (các quan hệ lớp con), nó có thể được định nghĩa trước trong các ngôn ngữ của ontology hoặc do người dùng định nghĩa (thông qua các thuộc tính)
Ontology là việc biểu diễn tri thức mang tính hình thức bằng việc thiết lập các khái niệm trong một lĩnh vực nào đó và các mối quan hệ giữa các khái niệm đó Nó được sử dụng để suy luận về các đặc tính hoặc để mô tả lĩnh vực nào đó Các ontology thường được mã hóa bằng ngôn ngữ ontology Ngôn ngữ ontology là ngôn ngữ hình thức cho phép mã hóa tri thức về một lĩnh vực cụ thể và thường cũng bao gồm các luật suy diễn hỗ trợ cho việc xử lý các tri thức đó
RDF được phát triển bởi W3C, là ngôn ngữ mô tả các thông tin về các tài nguyên trên Web RDF sử dụng các URI để định danh các tài nguyên và các thuô ̣c tính để mô tả các tài nguyên này Các thành phần cơ bản trong RDF bao gồm: tài nguyên (resource), thuộc tính (property) và phát biểu (statement) Mô hình dữ liệu của RDF bao gồm ba đối tượng: tài nguyên, thuộc tính, giá trị Tài nguyên là tất cả những gì được mô tả bằng RDF Nó có thể là một cuốn sách, một chiếc xe Các tài nguyên được định danh bởi URI Thuộc tính là đặc tính hoặc quan hệ dùng để mô tả tính chất
19 của tài nguyên và có giá trị được gán cho một thuộc tính của một tài nguyên cụ thể
Mô hình RDF mô tả các tài nguyên thông qua các phát biểu, mỗi phát biểu được biểu diễn theo cấu trúc bộ ba gọi là Triple, gồm các thành phần: Chủ thể (Subject): Địa chỉ hay vị trí tài nguyên muốn mô tả, được xác định bởi URI Vị từ (Predicate): Xác định tính chất của tài nguyên Đối tượng (Object): Nội dung gán cho thuộc tính, có thể là một tài nguyên hoặc giá trị literal
Ngôn ngữ lược đồ RDFS được phát triển ở tầng trên của RDF, cho nên bản thân nó cũng chính là RDF RDFS được mở rộng từ RDF và bổ sung thêm các tập từ vựng để hỗ trợ cho việc xây dựng các ontology được dễ dàng Ngôn ngữ RDF chỉ giúp cho thông tin được thể hiện ở dạng bộ ba theo đúng mô hình RDF, nhưng thông tin vẫn chưa thể hiện gì về mặt ngữ nghĩa của mô ̣t lĩnh vực chuyên biệt nào Vì thế, xây dựng RDFS là điều cần thiết để hình thành nên ngữ nghĩa của dữ liê ̣u trong miền ứng du ̣ng cụ thể Nói cách khác, RDFS cho phép người sử du ̣ng đi ̣nh nghĩa các tài nguyên với các lớp, các thuô ̣c tính, các giá tri ̣ và mô tả mối quan hê ̣ giữa các tài nguyên đó
OWL là ngôn ngữ Ontology được sử dụng khá rộng rãi Nó ra đời sau RDFS nên kế thừa được những lợi thế của ngôn ngữ này, đồng thời bổ sung thêm nhiều thành tố giúp khắc phục được những hạn chế của RDFS OWL giúp tăng thêm yếu tố logic cho thông tin, đồng thời có các ràng buộc giá trị cũng như các ràng buộc bản số giúp biểu diễn tốt thế giới thực
Trong OWL, ta có thể định nghĩa các phần giao, phần hợp, phần rời nhau và phần bù của các lớp Bên cạnh đó, OWL còn phân biệt hai loại thuộc tính: thuộc tính kiểu dữ liệu và thuộc tính đối tượng Ngoài ra, một thuộc tính còn có thể có tính bắc cầu, tính đối xứng, có thuộc tính đảo ngược… Chính vì thế, so với RDF và RDFS, OWL giàu ngữ nghĩa hơn và cho phép mô tả các lớp, các thuộc tính, các quan hệ giữa các lớp theo cách mà máy tính có thể hiểu được các nội dung của Web tốt hơn
1.2.7.1 Các ngôn ngữ con của OWL
W3C đã phân chia OWL thành 3 ngôn ngữ con với các mức độ biểu cảm khác nhau: OWL Lite, OWL DL (Description Logic) và OWL Full
OWL Lite là ngôn ngữ cơ bản nhất, hỗ trợ sự phân lớp và các ràng buộc đơn giản Ngoài ra, nó còn cung cấp khả năng xây dựng phân cấp lớp con và tính chất tuỳ chọn của thuộc tính, tức là ràng buộc về bản số có thể là 0 hoặc 1
OWL DL bổ sung thêm một số tính năng so với OWL Lite, tương ứng với khả năng biểu cảm của lôgic mô tả OWL DL hỗ trợ tất cả các cấu trúc ngôn ngữ của OWL, nhưng chúng chỉ có thể được sử dụng với một số ràng buộc Các ràng buộc này nhằm bảo đảm tính toàn vẹn và khả năng suy luận
OWL Full hỗ trợ toàn bộ các tính năng của OWL và cho phép kết hợp tùy ý với các cấu trúc của RDF hay RDFS, có thể xem đây là một mở rộng của RDF Nó cung cấp khả năng biểu cảm tối đa và sự tự do trong việc sử dụng cú pháp của RDF Tuy nhiên, khả năng tính toán các suy luận là không được bảo đảm
Tổng quan về các nghiên cứu chuyển đổi các mô hình
1.3.1 Các kết quả đề xuất chuyển đổi mô hình thực thể - mối quan hệ sang OWL Đã có nhiều nghiên cứu đề xuất việc chuyển đổi giữa mô hình cơ sở dữ liệu quan hệ mức khái niệm và ontology Trong đó, bài toán chuyển đổi mô hình thực thể
- mối quan hệ (mô hình ER) và OWL đã được nhiều tác giả công Tuy nhiên các công trình này vẫn chưa đề xuất đầy đủ các trường hợp của mô hình ER và EER khi chuyển đổi sang ontology, tiêu biểu như sau:
Với mục tiêu để nắm bắt đầy đủ ngữ nghĩa thể hiện của mô hình EER khi chuyển sang ontology, thay vì phải chuyển đổi mô hình ER qua bước trung gian là mô hình quan hệ sẽ mất ngữ nghĩa, R Upadhyaya và P S Kumar [6] đã tiếp cận mô hình ER bằng cách tập trung vào việc biểu diễn tập thực thể, thuộc tính và các ràng buộc cấu trúc, các ràng buộc bản số, từ đó đề xuất các quy tắc chuyển đổi mô hình EER sang OWL Công trình này đề xuất các quy tắc ánh xạ các thành phần của mô hình ER như thực thể, thuộc tính, mối quan hệ, đồng thời đã đề cập đến việc ánh xạ một số trường hợp trong mô hình EER như quan hệ tổng quát hóa/chuyên biệt hóa, quan hệ đa kế
28 thừa Công trình [6] cho rằng chuyển đổi thuộc tính phức hợp sẽ tạo thành một lớp mới làm tăng thêm thuộc tính đối tượng giữa lớp của tập thực thể và lớp mới của thuộc tính phức hợp, và ràng buộc bản số giữa các lớp Công trình này cũng chưa đề cập đến thuộc tính đa trị Ngoài việc thiếu nhiều trường hợp của mô hình ER, trong công trình này cho rằng, không có sự khác biệt giữa việc chuyển đổi các tập thực thể mạnh và tập thực thể yếu, ngoại trừ thuộc tính tương ứng với khóa chính của tập thực thể mạnh có hạn chế bản số thiết lập là 1 trong mô tả của tập thực thể yếu
Khắc phục một số vấn đề của công trình [6], M Fahad [7] đã đề xuất phương pháp thiết kế các OWL từ mô hình ER bằng tập các quy tắc chuyển đổi các thành phần của một mô hình ER (các tập thực thể, các thuộc tính, và các mối quan hệ giữa các tập thực thể) thành các thành phần tương ứng trên OWL Công trình này đã giới thiệu bổ sung quy tắc chuyển đổi mối quan hệ Is-A, quan hệ phản xạ, tuy nhiên chưa phân loại các mối quan hệ phản xạ Một trong những hạn chế của công trình này là chuyển đổi thuộc tính khóa thành thuộc tính kiểu dữ liệu và thiết lập tính chất hàm
"function" và "inverse-functional", nhưng thuộc tính kiểu dữ liệu không thể thiết lập tính chất inverse-function Và tương tự, công trình này vẫn còn thiếu nhiều trường hợp khi chuyển đổi mô hình EER
Myroshnichenko và cộng sự [8] đã trình bày giải pháp ánh xạ tự động mô hình
ER thành ngữ nghĩa tương đương trên OWL Lite Ontology Công trình này đã đề xuất các trường hợp chuyển đổi cho mô hình ER, trong đó đã đề xuất chuyển đổi thuộc tính phức hợp thành một lớp mới và bổ sung thuộc tính đối tượng tương tự như công trình [6] Công trình này đã đề xuất chuyển đổi thuộc tính khóa đơn trị và thuộc tính khóa phức hợp, tuy nhiên trên thực tế không có thuộc tính khóa phức hợp Công trình này cũng chưa nghiên cứu chuyển đổi trên mô hình EER
Ashok và cộng sự [9] đã đề xuất cách tiếp cận ánh xạ tự động mô hình ER thành OWL-S Do OWL-S là khung khái niệm để mô tả các dịch vụ web ngữ nghĩa và cũng là ngôn ngữ làm phong phú các mô tả dịch vụ Web với thông tin ngữ nghĩa từ các OWL Nhóm tác giả chỉ mới trình bày sơ lược cách ánh xạ các thành phần của mô hình ER sang OWL
Pasapitch Chujai [10] đã đề xuất một cách tiếp cận để xây dựng các OWL sử dụng Protégé từ một cơ sở dữ liệu quan hệ được thiết kế trên một mô hình ER cho trước Cũng như các công trình trước đó, công trình này chưa đề xuất đầy đủ chuyển đổi các trường hợp của mô hình ER và mô hình EER
Qua các nghiên cứu trước đây, luận án thấy rằng có một số vấn đề như sau: khi chuyển đổi thuộc tính khóa, các nghiên cứu [6] [7] [10] đề xuất chuyển thành thuộc tính kiểu dữ liệu và thiết lập tính chất hàm “functional”và tính chất hàm nghịch đảo
“inverse-functional”, nhưng nghiên cứu [8] lại đề xuất chỉ thiết lập tính chất hàm Các nghiên cứu [6] [7] [8] [10] đề xuất chuyển đổi thuộc tính đơn trị trong mô hình
ER thành thuộc tính kiểu dữ liệu trong OWL, nhưng chưa đề cập đến trường hợp khi thuộc tính đơn trị đó có thể nhận giá trị null Hay như các nghiên cứu đề xuất chuyển đổi thuộc tính khóa thành thuộc tính kiểu dữ liệu của lớp tương ứng, trong đó công trình [8] đã đề xuất chuyển đổi thuộc tính khóa phức hợp, tuy nhiên trên thực tế không có thuộc tính khóa phức hợp
Công trình [6] [8] cho rằng thuộc tính phức hợp được xem như là một khái niệm (tập thực thể), các thuộc tính thành phần của nó được coi là thuộc tính có liên quan với khái niệm đó Nhóm tác giả [6] [8] đề xuất chuyển đổi thuộc tính phức hợp thành một lớp và khai báo thuộc tính đối tượng giữa lớp của thuộc tính phức hợp và lớp của thực thể cha Tuy nhiên, theo [7], có hai cách để chuyển đổi thuộc tính phức hợp thành thuộc tính kiểu dữ liệu trong OWL Một là ánh xạ các thuộc tính thành phần của thuộc tính phức hợp thành thuộc tính dữ liệu của lớp tương ứng OWL, và bỏ qua thuộc tính phức hợp của chính nó Cách thứ hai là chuyển đổi thuộc tính phức hợp thành thuộc tính dữ liệu và sau đó ánh xạ các thuộc tính thành phần đơn trị của nó thành thuộc tính con của thuộc tính dữ liệu tương ứng Tác giả [7] cho rằng sử dụng cách thứ nhất không bảo toàn các mô hình khái niệm của thuộc tính phức hợp, và khi thực hiện chuyển đổi ngược từ ontology thành ER sẽ mất thuộc tính phức hợp Trong các nghiên cứu trước đây đều cho rằng chuyển đổi mối quan hệ phản xạ sang OWL thực hiện tương tự như việc chuyển đổi mối quan hệ nhị nguyên Công trình [7] có đề xuất chuyển đổi mối quan hệ phản xạ thành một thuộc tính đối tượng với miền và phạm vi là lớp biểu diễn tập thực thể có mối quan hệ phản xạ đó Tuy
30 nhiên, tác giả chưa phân loại mối quan hệ phản xạ, vì thế việc chuyển đổi chưa phản ảnh đúng ngữ nghĩa của mối quan hệ
Bên cạnh đó, còn có nhiều trường hợp của mô hình ER và EER chưa được nhắc đến, như tập thực thể yếu và mối quan hệ định danh, thuộc tính đa trị phức hợp lồng nhau, các trường hợp của mối quan hệ phản xạ, yếu tố thời gian trên mô hình ER Về nguyên tắc, khi thực hiện việc cài đặt một chương trình chuyển đổi, nếu chúng ta không xét đầy đủ các trường hợp có thể xảy ra bên trong một mô hình đầu vào, thì không thể xác định được mô hình đầu ra Vì vậy, bài toán đặt ra cần phải xây dựng các quy tắc bổ sung để chuyển đổi cho các trường hợp còn thiếu để hoàn thiện bộ quy tắc chuyển đổi
1.3.2 Các kết quả đề xuất chuyển đổi biểu đồ lớp UML sang OWL
Trước đây, biểu đồ lớp UML được sử dụng để mô hình hóa các hệ thống thông tin bằng tập các lớp, các thuộc tính và các phép toán Ưu điểm của thiết kế hệ thống bằng UML là khả năng mô tả và phản ảnh tốt thế giới thực của các hệ thống thông tin Do xu hướng hiện nay cần sử dụng lại các dữ liệu từ các hệ thống thông tin cũ là rất có lợi cho việc triển khai tri thức ngữ nghĩa, vì thế việc nâng cấp và chuyển đổi các biểu đồ lớp UML sang ontology nhằm sử dụng lại các hệ thống cũ, giúp giảm chi phí là thực sự cần thiết Đã có nhiều công trình nghiên cứu về việc chuyển đổi từ biểu đồ lớp UML sang OWL
Dragan Gašević và nhóm tác giả [11] [12] trình bày phương pháp chuyển đổi OWL từ biểu đồ lớp UML Giải pháp trên kiến trúc MDA để triển khai ontology và các hồ sơ ontology UML (OUP) Phương pháp của tác giả chuyển đổi một ontology từ định nghĩa OUP của nó (tức là XML Metadata Interchange - XMI) thành mô tả OWL Nhóm tác giả sử dụng công cụ Poseidon để chuyển đổi UML thành tài liệu XMI, và qua quá trình xử lý XSLT sẽ có kết quả là tài liệu OWL Trong đề xuất này, nhóm tác giả chưa đề cập các quy tắc chuyển đổi rõ ràng cho các trường hợp
Tổng kết chương 1
Việc chuyển đổi trực tiếp giữa mô hình cơ sở dữ liệu mức khái niệm ban đầu và OWL tương đương không chỉ đơn giản là cố gắng ánh xạ mô hình cơ sở dữ liệu mức khái niệm ban đầu, mà còn giúp bảo toàn tất cả các ràng buộc ngữ nghĩa liên quan trong mô hình cơ sở dữ liệu mức khái niệm ban đầu Để làm được điều đó, cần nghiên cứu các đặc trưng của các mô hình cơ sở dữ liệu mức khái niệm và OWL Chương này đã tiếp cận các công trình liên quan và các đối tượng cho việc chuyển đổi giữa mô hình cơ sở dữ liệu mức khái niệm và OWL Nhiều công trình đã chứng minh tính hiệu quả và đã ứng dụng trong thực tế Bên cạnh đó, việc chuyển đổi giữa mô hình cơ sở dữ liệu mức khái niệm ban đầu và OWL nhằm sử dụng lại các hệ thống cũ, giúp giảm chi phí là thực sự cần thiết
Trong chương đã trình bày lý thuyết về các mô hình cơ sở dữ liệu mức khái niệm ban đầu, web ngữ nghĩa và OWL… để làm tiền đề xây dựng phương pháp chuyển đổi giữa mô hình cơ sở dữ liệu mức khái niệm và OWL ở những chương tiếp theo Chương này đã phác thảo cách tiếp cận của luận án, giới thiệu tổng quan những kết quả của các tác giả để chuyển đổi giữa mô hình cơ sở dữ liệu mức khái niệm và OWL cũng như thách thức đặt ra cho cách tiếp cận này Các chương tiếp theo sẽ trình bày các kết quả nghiên cứu của luận án về các nội dung này
CHUYỂN ĐỔI MÔ HÌNH THỰC THỂ - MỐI QUAN HỆ SANG
Giới thiệu
Luận án xây dựng phương pháp chuyển đổi mô hình mức khái niệm sang OWL theo mô hình tổng quát như Hình 2.1 Việc chuyển đổi mô hình mức khái niệm sang OWL gồm hai giai đoạn: tiền xử lý và chuyển đổi Giai đoạn tiền xử lý là bước chuyển đổi mô hình CSDL mức khái niệm thành tài liệu XML/XMI Giai đoạn này sử dụng kết quả từ các nghiên cứu trước đây đã đề xuất Theo đó, giai đoạn chuyển đổi sẽ áp
38 dụng các thuật toán chuyển đổi để chuyển tài liệu XML/XMI thành OWL ontology Kết quả cuối cùng là các lớp, các thuộc tính được biểu diễn trong OWL
Mô hình CSDL mức khái niệm XMI document OWL ontology
Các thuật toán chuyển đổi
Hình 2.1 Kiến trúc các bước chuyển đổi từ mô hình CSDL mức khái niệm sang OWL
Nhằm chi tiết hóa các kết quả đầu ra của thuật toán chuyển đổi, cũng như xác định rõ ngữ nghĩa mối quan hệ giữa các lớp trong OWL kết quả thu được, Luận án hình thức hoá thuật toán chuyển đổi này thông qua một số định nghĩa, ký hiệu quy ước được mô hình hóa bằng các ký hiệu mô tả như [28] và các thuật toán tựa Pascal Thuật toán chuyển đổi từ mô hình Thực thể - Mối quan hệ (ER) sang OWL được mô tả như sau:
Thuật toán 2.1 Chuyển đổi mô hình Thực thể - mối quan hệ (ER) sang OWL Input: Mô hình Thực thể - mối quan hệ
Kết quả của thuật toán 2.1 là OWL ontology, đây là kết quả chuyển đổi của các thành phần của mô hình EER như tập thực thể, thuộc tính và các mối quan hệ tương ứng Trong nội dung tiếp theo của chương này, luận án sẽ trình bày các nghiên cứu trước đây liên quan đến việc chuyển đổi các thành phần của mô hình EER sang OWL.
Các nghiên cứu trước đây
Dựa vào các công trình nghiên cứu liên quan đến việc xây dựng phương pháp chuyển đổi các thành phần của mô hình EER sang OWL (tập thực thể, thuộc tính, mối quan hệ), luận án đã hình thức hóa các kết quả thành các quy tắc chuyển đổi
2.2.1 Chuyển đổi tập thực thể
Lớp trong OWL định nghĩa một nhóm các cá thể có chung một số thuộc tính, tương tự như tập thực thể trong mô hình ER Trong OWL, hai cấu trúc khác nhau được sử dụng để định nghĩa một lớp Cấu trúc được sử dụng để định nghĩa lớp là owl:class, cấu trúc thứ hai được sử dụng để xác định một lớp con là rdf:subClassOf
Hai khái niệm này được ánh xạ cho nhau trong quy tắc chuyển đổi sau:
Rules EER1 Tập thực thể E của mô hình ER được chuyển đổi thành lớp C(E) trong OWL [10]
Ví dụ 2.1 Trong Hình 2.7, tập thực thể Employee được chuyển đổi thành lớp
Employee tương ứng trong OWL
2.2.2 Chuyển đổi mối quan hệ kế thừa (Is-A)
Trong quan hệ kế thừa của mô hình EER, mỗi lớp con được đặc trưng bằng cách thiết lập giá trị của một trong các thuộc tính của nó Trong OWL, ràng buộc tương ứng với mối quan hệ kế thừa là ràng buộc lớp con, vì vậy sẽ chuyển một mối quan hệ kế thừa trong mô hình EER thành một ràng buộc lớp con trong OWL
Rules EER2 Tập thực thể sub_E kế thừa từ tập thực thể E chuyển đổi thành lớp
C(sub_E) là lớp con của lớp C(E) [7]
Ví dụ 2.2 Ở Hình 2.2, thực thể Manager được chuyển đổi thành lớp con Manager
Hình 2.2 Chuyển đổi tập thực thể con trong mối quan hệ kế thừa
2.2.2.1 Chuyển đổi ràng buộc phân ly trong cấu trúc chuyên biệt hóa/tổng quát hóa
Trong mô hình EER, một lớp có thể có nhiều phân lớp phân ly Trong khi đó, trong OWL không có ràng buộc nào có ý nghĩa tương đương với ràng buộc phân lớp phân ly như trong mô hình EER Để biểu diễn ràng buộc này, các đề xuất dùng các
40 ràng buộc không giao giữa các lớp tương ứng bằng cấu trúc owl:disjointWith hoặc cấu trúc owl:complementOf , như vậy tương ứng với ngữ nghĩa của ràng buộc phân ly trong mô hình EER [24]
Rules EER3 Lớp E của mô hình EER với các lớp con sub_E 1,…, sub_E n có ràng buộc phân ly Khi đó, chuyển đổi mỗi lớp con sub_E i (i=1 n) thành các lớp con
C(sub_E i ), đồng thời thiết lập ràng buộc phân ly với các lớp con khác cùng kế thừa vào lớp C(E) bằng cách sử dụng cấu trúc owl:disjointWith hoặc owl:complementOf
Hình 2.3 Chuyển đổi ràng buộc phân ly trong cấu trúc chuyên biệt hóa/tổng quát hóa
Ví dụ 2.3 Tập thực thể EMPLOYEE có hai lớp phân ly là ENGINEER và SECRETARY được chuyển đổi thành hai lớp ENGINEER và SECRETARY và sử sụng cấu trúc owl:disjointWith như Hình 2.4
SECRETARY subClas sOf subClas sOf disjointWith
Hình 2.4 Chuyển đổi tập thực thể con trong ràng buộc phân ly trong cấu trúc Chuyên biệt hóa/Tổng quát hóa
2.2.2.2 Chuyển đổi ràng buộc chồng lấp trong cấu trúc Chuyên biệt hóa/Tổng quát hóa
Trong OWL, cấu trúc owl:unionOf mô tả một lớp có chứa các thể hiện có thể xuất hiện trong ít nhất một trong các phần lớp con [24] Vì vậy cấu trúc owl:unionOf chuyển thành ràng buộc chồng lấp trong mô hình EER Ở đây, ràng buộc lớp con đã được thêm vào trong Rules EER3 nên chỉ cần thêm các ràng buộc hợp Chuyển đổi ràng buộc chồng lấp trong cấu trúc tổng quát hóa/tổng quát hóa thực hiện như sau:
Rules EER4 Tập thực thể E của mô hình EER có các lớp con sub_E 1 ,…, sub_E n có ràng buộc chồng lấp Khi đó, chuyển đổi tập thực thể chồng lấp E với các lớp con sub_E i thành lớp C(E) và các lớp con C(sub_E i ), đồng thời thực thể có phân lớp chồng lấp này ràng buộc hợp gồm các lớp tương ứng với các tập thực thể cùng kế thừa vào một phân lớp chồng lấp đó bằng cách sử dụng cấu trúc owl:unionOf [6]
Hình 2.5 Chuyển đổi tập thực thể con trong ràng buộc chồng lấp trong cấu trúc Chuyên biệt hóa/Tổng quát hóa
Ví dụ 2.4 Xét tập thực thể PERSON có hai phân lớp chuyên biệt là STUDENT và
ALUMNUS, khi chuyển đổi thành OWL phải bổ sung ràng buộc hợp cho hai lớp STUDENT và ALUMNUS như Hình 2.5
ALUMNUS subClas sOf sub Clas sOf unionOf
Hình 2.6 Ví dụ chuyển đổi ràng buộc chồng lấp trong cấu trúc Chuyên biệt hóa/Tổng quát hóa
Từ các quy tắc trên, thuật toán chuyển đổi tập thực thể như sau:
Thuật toán 2.2 Chuyển đổi tập thực thể
Input: Các tập thực thể trong mô hình ER
2 For (mỗi tập thực thể E i trong ER) do
3 If (tập thực thể E i có tập thực thể con) then
5 If (E i là tập thực thể cha của mối quan hệ kế thừa) then
6 Áp dụng Rules EER2: Chuyển đổi tập thực thể con trong mối quan hệ kế thừa
7 If (E i là tập thực thể cha của ràng buộc chồng lấp trong cấu trúc
Chuyên biệt hóa/Tổng quát hóa) then
8 Áp dụng Rules EER4: Chuyển đổi tập thực thể con trong ràng buộc chồng lấp trong cấu trúc Chuyên biệt hóa/Tổng quát hóa
9 If (E i là tập thực thể cha của ràng buộc phân ly trong cấu trúc
Chuyên biệt hóa/Tổng quát hóa) then
10 Áp dụng Rules EER3: Chuyển đổi tập thực thể con trong ràng buộc phân ly trong cấu trúc Chuyên biệt hóa/Tổng quát hóa
12 Else Áp dụng Rules EER1;
14 End Độ phức tạp của Thuật toán 2.2 là O(n), với n là số tập thực thể của mô hình
Trong mô hình ER, tập thực thể có nhiều loại thuộc tính như thuộc tính đơn; thuộc tính khóa, thuộc tính phức hợp, thuộc tính đa trị, vì vậy đòi hỏi những cách riêng để chuyển đổi Thuật toán chuyển đổi thuộc tính attE của tập thực thể E được xét như sau:
2.2.3.1 Chuyển đổi thuộc tính đơn
Trong OWL, thuộc tính kiểu dữ liệu là kiểu dữ liệu đơn, vì thế chúng tương đương với thuộc tính đơn trị trong mô hình ER Theo mặc định, OWL cho phép các thuộc tính có nhiều giá trị Do đó, một thuộc tính đơn trị sẽ phải được mô tả bởi một thuộc tính kiểu dữ liệu có tính chất hàm Thiết lập tính chất hàm trong OWL đảm bảo rằng các giá trị của domain và range có một mối quan hệ 1-1
Bản số ràng buộc trong OWL thiết lập hạn chế về số lượng các giá trị một thuộc tính có thể nhận được Ràng buộc bản số mô tả một lớp của tất cả các cá thể mà có đúng N giá trị khác biệt ngữ nghĩa cho các thuộc tính có liên quan, trong đó N là giá trị của ràng buộc bản số [29] Vì vậy kế thừa từ các đề xuất trước, Luận án phát biểu quy tắc chuyển đổi thuộc tính đơn trị như sau:
Rules EER5 Thuộc tính đơn trị attE của tập thực thể E được chuyển đổi thành thuộc tính dữ liệu DP(attE) có phạm vi là kiểu dữ liệu tương ứng trong OWL và có miền là lớp C(E), đồng thời thiết lập tính chất hàm [8] [10] Nếu thuộc tính DP(attE) không cho phép nhận dữ liệu null thì thiết lập ràng buộc số lượng cực tiểu của thuộc tính DP(attE) là 1 Để biểu diễn thuộc tính khóa chính mà không nhận giá trị null thì minQualifiedCardinality của thuộc tính là 1 và maxQualifiedCardinality là 1, có nghĩa là cardinality là 1, tức là đảm bảo rằng thuộc tính xuất hiện một lần trong các mô tả khái niệm của lớp đó Đồng thời phải đảm bảo rằng tất cả các giá trị thuộc tính kiểu dữ liệu là khác nhau bằng cách sử dụng các cấu trúc OWL, owl:allDifferent và owl:distinctMembers
Rules EER6 Thuộc tính khóa keyE của tập thực thể E chuyển đổi thành thuộc tính dữ liệu DP(keyE), có phạm vi là kiểu dữ liệu tương ứng trong OWL và miền là lớp C(E), thiết lập tính chất hàm và tính chất hàm nghịch đảo, có bản số là 1 [10]
Các quy tắc chuyển đổi bổ sung
Qua các nghiên cứu trước đây, luận án thấy rằng còn có nhiều trường hợp chuyển đổi của mô hình ER và EER chưa được nhắc đến, như tập thực thể yếu và mối quan hệ định danh, thuộc tính đa trị phức hợp lồng nhau, mối quan hệ phản xạ, yếu tố thời gian trên mô hình ER Về nguyên tắc, khi thực hiện việc cài đặt một chương trình chuyển đổi, nếu chúng ta không xét đầy đủ các trường hợp có thể xảy ra bên trong một mô hình đầu vào, thì không thể xác định được mô hình đầu ra Trên cơ sở các nghiên cứu đã có, luận án đề xuất một số quy tắc chuyển đổi bổ sung từ mô hình ER và EER sang OWL nhằm có thể thiết kế ontology theo mục đích trên trong mọi trường hợp
2.3.1 Chuyển đổi thực thể yếu và mối quan hệ định danh
Công trình [6] cho rằng không có sự khác nhau khi chuyển đổi tập thực thể mạnh và thực thể yếu, ngoại trừ việc bổ sung vào lớp biểu diễn tập thực thể yếu thuộc
50 tính dữ liệu biểu diễn khóa chính của tập thực thể chủ Cách làm này không đảm bảo được ngữ nghĩa khi thực hiện việc chuyển đổi Để khắc phục vấn đề này, luận án đề xuất bổ sung thêm cặp thuộc tính đối tượng ngược nhau để biểu diễn mối quan hệ định danh Cụ thể, quy tắc chuyển đổi được phát biểu như sau:
Rules EER12 Xét mối quan hệ định danh R giữa tập thực thể yếu W và tập thực thể chủ E Giả sử W có khoá bộ phận là keyW và khoá chính của E là keyE Quy tắc chuyển đổi được thực hiện như sau:
- Bổ sung lớp định danh là C(W), mỗi thuộc tính attW của tập thực thể yếu W chuyển đổi thành thuộc tính dữ liệu DP(attW) tương ứng của lớp C(W);
- Bổ sung thêm hai thuộc tính đối tượng ngược nhau E_R (có miền là C(E) và phạm vi là C(W)) và W_R (có miền là C(W) và phạm vi là C(E)) thể hiện quan hệ giữa lớp C(E) và lớp C(W); thiết lập tính chất hàm và ràng buộc cực tiểu là 1 cho thuộc tính đối tượng W_R;
- Thiết lập ràng buộc số lượng cực tiểu/cực đại tương ứng vào thuộc tính đối tượng E_R;
- Khóa của lớp C(W) bao gồm các thuộc tính dữ liệu DP(keyW) và DP(keyE)
Dependent_Dep_of inverseOf domain range domain range
Hình 2.12 Chuyển đổi tập thực thể yếu và mối quan hệ định danh
Ví dụ 2.10 Xét ví dụ ở Hình 2.12, thực thể yếu Dependent và mối quan hệ định danh
Dep_of được biểu diễn trong Protégé như sau: thực thể yếu Dependent chuyển đổi
51 thành lớp Dependent, mối quan hệ định danh Dep_of được chuyển đổi thành cặp thuộc tính đối tượng ngược nhau là Employee_Dependent và Dependent_Employee Các thuộc tính DependentName và Relationship của thực thể yếu được chuyển thành các thuộc tính dữ liệu của lớp Dependent
2.3.2 Chuyển đổi thuộc tính đa trị phức hợp lồng nhau
Mô hình EER hỗ trợ việc sử dụng các thuộc tính đa trị (mục 2.2.3.2) và các thuộc tính phức hợp (mục 2.2.3.3), nhưng nếu các thuộc tính đa trị và thuộc tính phức hợp này lồng nhau như trong Hình 2.13 thì các quy tắc đã xét là chưa đáp ứng được việc chuyển đổi cho trường hợp này Ví dụ, một nhân viên có thể biết nhiều ngoại ngữ khác nhau, tương ứng với các chứng chỉ với các mức độ khác nhau Giả sử nhân viên A biết 3 ngoại ngữ tiếng Anh chứng chỉ IELTS đạt 5.5 điểm, tiếng Pháp mức độ DELF B1 (Junior, Tous Publics) và tiếng Nga mức độ TRKI-1 Vấn đề đặt ra là làm thế nào để có thể biểu diễn được các thuộc tính đa trị và phức hợp lồng nhau trong OWL?
Mọi thuộc tính đa trị và phức hợp đều có khóa bộ phận, chẳng hạn như trong ví dụ Hình 2.13 thì language là khóa bộ phận của thuộc tính trình độ ngoại ngữ foreign_language_proficiency, thuộc tính kind là khóa bộ phận của thuộc tính certificate empID full_name foreign_language_proficiency certificate kind score language Employee
Hình 2.13 Ví dụ thuộc tính đa trị phức hợp lồng nhau
Một thuộc tính đa trị của một tập thực thể có thể biểu diễn bởi mối quan hệ định danh giữa một tập thực thể yếu và tập thực thể chủ của nó, vì vậy có thể chuyển đổi
52 mỗi thuộc tính đa trị và phức hợp có khóa bộ phận thành một mối quan hệ định danh trong mô hình ER Kế thừa quy tắc chuyển đổi tập thực thể yếu và mối quan hệ định danh, quy tắc chuyển đổi thuộc tính đa trị và phức hợp lồng nhau phát biểu như sau:
Rules EER13 Xét tập thực thể E (hoặc thuộc tính đa trị và phức hợp E) có thuộc tính attE là thuộc tính đa trị và phức hợp, trong đó thuộc tính phức hợp attE có tập các thuộc tính thành phần là sub_attE và khoá bộ phận là K_attE Thuộc tính đa trị attE được ánh xạ thành mối quan hệ định danh S_attE giữa tập thực thể chủ E và tập thực thể yếu W_attE Trong đó, tập thực thể yếu W_attE có tập thuộc tính là sub_attE và khoá bộ phận là K_attE
- Bổ sung lớp định danh C(W_attE), các thuộc tính sub_attE của thuộc tính đa trị và phức hợp attE chuyển thành các thuộc tính dữ liệu DP(sub_attE) của lớp C(W_attE);
- Bổ sung thêm hai thuộc tính đối tượng ngược nhau E_W_attE và W_attE_E thể hiện quan hệ giữa lớp C(E) và lớp C(W_attE) có định danh, miền, phạm vi như Bảng 2.1; Thiết lập tính chất hàm và ràng buộc cực tiểu là 1 vào thuộc tính đối tượng
- Tùy thuộc vào bản số thứ hai của mối quan hệ định danh, thêm ràng buộc số lượng cực tiểu/cực đại tương ứng vào thuộc tính đối tượng E_W_attE (thuộc tính vừa thêm có miền là lớp tương ứng với tập thực thể có cặp bản số đó);
- Khóa của lớp C(W_attE) được tạo bằng cách kết hợp khóa bộ phận K_attE với khóa KE của lớp C(E)
Bảng 2.1 Cặp thuộc tính thêm vào khi chuyển đổi thuộc tính đa trị phức hợp lồng nhau Định danh Miền Phạm vi
Ta thấy rằng các thuộc tính phức hợp có cấu trúc lồng nhau trong một tập thực thể được tổ chức theo một cấu trúc phân cấp biểu diễn bởi một cây tổng quát Do đó, chuyển đổi các thuộc tính đa trị trong cấu trúc cây này thành sang OWL được thực
53 hiện theo thứ tự trên các nút (biểu diễn các thuộc tính đa trị) có mức (level) từ nhỏ đến lớn
Restriction subClas sOf onP roperty cardinality
Foreign_language_profi ciency_Certificate
Certificate_foreign_la nguage_proficiency invers e
Employee_foreign_lan guage_proficiency
ObjectProperty foreign_language_prof iciency_Employee domain domain range range domain domain range range invers e onP roperty subClas sOf
Chuyển đổi mô hình TimeER sang OWL
Giá trị của một cơ sở dữ liệu không phải là độ lớn của dữ liệu mà chính là số lượng thông tin có thể thu được từ nó Vì vậy, thông tin của quá khứ hay hiện tại đều quan trọng như nhau Cơ sở dữ liệu có yếu tố thời gian đã được nghiên cứu với mục đích là lưu trữ thông tin của dữ liệu tại các thời điểm khác nhau
Trong nhiều ứng dụng, thông tin về quá khứ và tương lai cũng quan trọng như thông tin về hiện tại Cơ sở dữ liệu có yếu tố thời gian là mở rộng của CSDL truyền thống bằng cách cho phép lưu trữ và truy nhập các thông tin về thời gian Trên thực tế, phần lớn các ứng dụng CSDL đều liên quan đến dữ liệu có yếu tố thời gian như: quản lý nhân sự - tiền lương, tài chính, y tế, lập thời gian biểu…
Khi quản lý dữ liệu thời gian, cần quản lý thời gian mà sự kiện đúng trong thực tế, thiết lập bởi trình ứng dụng và có thể thay đổi, gọi là Thời gian hợp lệ Loại thời gian thứ hai cần quản lý thời gian khi sự kiện được lưu trong CSDL, được thiết lập bởi hệ thống và không thể thay đổi, gọi là Thời gian giao tác Một vài ứng dụng cần quản lý cả hai loại thời gian nói trên và gọi là Thời gian theo hai loại thời gian Trong trường hợp này CSDL có yếu tố thời gian được gọi là CSDL theo hai loại thời gian (Bitemporal)
Mô hình TimeER [32] là một trong những mô hình mức khái niệm có yếu tố thời gian đang được sử dụng phổ biến hiện nay Một số yếu tố thời gian gồm: Thời gian sống (LifeSpan, ký hiệu là: LS): là thời gian mà một thực thể tồn tại trong thực tế Thời gian hợp lệ (Valid Time, ký hiệu là: VT): là thời gian mà một sự kiện được xem là đúng trong thực tế Thời gian giao tác (Transaction Time, ký hiệu là: TT): là thời gian mà một thực thể/sự kiện là hiện thời trong CSDL Việc kết hợp cả thời gian sống và thời gian giao tác được ký hiệu là LT; còn việc kết hợp cả thời gian hợp lệ và thời gian giao tác ký hiệu là BT (BiTemporal)
Trong mô hình TimeER, các thực thể chỉ có thể hỗ trợ thời gian sống (LS), hoặc thời gian giao tác (TT), hoặc cả hai loại thời gian này (LT) Thuộc tính hỗ trợ thời gian hợp lệ (VT), hoặc thời gian giao tác (TT) hoặc cả hai loại thời gian này (BT) Ngoài ra, do mối quan hệ có thể xem là kiểu thực thể hoặc một thuộc tính, nhờ vậy người thiết kế có thể xác định các yếu tố thời gian hỗ trợ cho mối quan hệ đó nếu cần
Location VT marriedTo wife (1,1) husband (1,1)
TaxJointlyWith guards guard (0,1) isGuardedBy (0,1) year
Manages Rank position App_date
Hình 2.21 Ví dụ mô hình TimeER
Mô hình TimeER là một mô hình ER mở rộng, vì thế các thành phần trong mô hình được chuyển đổi tương tự như các quy tắc chuyển đổi ở trên Ontology cần được cung cấp bộ từ vựng để diễn đạt các sự kiện về mối quan hệ trong khoảng thời gian, cùng với thông tin về thời lượng Chuyển đổi mô hình TimeER sang OWL được thực hiện theo ba bước:
- Các thành phần không có yếu tố thời gian trên mô hình TimeER (kể cả tập thực thể có yếu tố thời gian) được chuyển sang OWL như ở mục 2.2và 2.3
- Tạo OWL biểu diễn các yếu tố thời gian để biểu diễn được dữ liệu và các ràng buộc của các yếu tố thời gian của mô hình TimeER trên OWL
- Chuyển đổi các thành phần có yếu tố thời gian mô hình TimeER sang OWL
2.4.1 Tạo ontology ban đầu biểu diễn yếu tố thời gian
OWL không có thành phần nào tương đương ngữ nghĩa với các thành phần có yếu tố thời gian như trong mô hình TimeER Để hỗ trợ cho việc biểu diễn các thành phần có yếu tố thời gian trong OWL, luận án đề xuất bổ sung lớp InstantDateTime và các thuộc tính đối tượng thể hiện mối quan hệ giữa lớp owl:Thing với lớp
InstantDateTime Lớp InstantDateTime này được tạo với mục đích thể hiện cho một mốc thời gian Trong lớp này, tạo thuộc tính dữ liệu hasDateTime có tính chất hàm và ràng buộc số lượng cực tiểu là 1 Thuộc tính này là thuộc tính khóa của lớp
InstantDateTime, có phạm vi là xsd:dateTime
Functional DatatypeProperty hasDateTime domain type xsd:dateTime range subClassOf
Restriction onProperty onProperty onProperty onProperty onProperty onProperty range range range range range range domain domain domain domain domain domain minCardinality subClassOf
Hình 2.22 Ontology biểu diễn yếu tố thời gian Đồng thời, tạo sáu thuộc tính đối tượng có tính chất hàm và ràng buộc số lượng tối thiểu là 1: hasVTs, hasVTe, hasLSs, hasLSe, hasTTs, hasTTe để biểu diễn các quan hệ giữa lớp owl:Thing với lớp InstantDateTime Sáu thuộc tính đối tượng này đều có phạm vi là lớp InstantDateTime và có miền là lớp owl:Thing
2.4.2 Chuyển đổi tập thực thể có yếu tố thời gian Để biểu diễn yếu tố thời gian của tập thực thể trong mô hình TimeER, có thể sử dụng một lớp, cặp thuộc tính đối tượng ngược nhau và một số thuộc tính bổ sung
Quy tắc TimeER1 Xét tập thực thể E có yếu tố thời gian XX (XX có thể là LS, LT, TT) Khi đó:
- Bổ sung lớp có định danh C(E_XX) để biểu diễn yếu tố thời gian của tập thực thể E;
- Bổ sung hai thuộc tính đối tượng ngược nhau: E_has_XX có miền là lớp C(E) và phạm vi là lớp C(E_XX), và XX_of_E có miền là lớp C(E_XX) và phạm vi là lớp
C(E), trong đó XX_of_E có tính chất hàm và có ràng buộc số lượng cực tiểu là 1
- Tập thuộc tính khóa của lớp C(E_XX) gồm thuộc tính XX_of_E và một số thuộc tính thể hiện ràng buộc thời gian tùy thuộc vào loại yếu tố thời gian XX như Bảng 2.2
Bảng 2.2 Các thuộc tính khóa tương ứng với yếu tố thời gian
Yếu tố thời gian Thuộc tính khóa
Ví dụ 2.15 Hình 2.23 minh họa cho Quy tắc TimeER1, lớp Employee_LT được tạo mới và cặp thuộc tính đối tượng ngược nhau để mô tả cho mối quan hệ giữa hai lớp Trong đó, thuộc tính đối tượng LT_of_Employee được thiết lập bản số là 1 để đảm bảo rằng một cá thể trong lớp Employee có quan hệ với một cá thể trong lớp Employee_LT Tập thuộc tính khóa gồm các thuộc tính LT_of_Employee và hasLSs, hasLSe, hasTTs
Functional ObjectProperty domain domain range range
Restriction sub Clas sOf cardinality 1
Hình 2.23 Chuyển đổi yếu tố thời gian của tập thực thể
Yếu tố thời gian LT của tập thực thể Employee được chuyển đổi thành lớp Employee_LT, với tập thuộc tính khóa gồm hasTTs, hasLSs, hasLSe Đồng thời hai
66 thuộc tính đối tượng Employee_has_LT và LT_of_Employee được tạo ra để biểu diễn cho mối quan hệ giữa hai lớp
2.4.3 Chuyển đổi thuộc tính có yếu tố thời gian
Kết quả thực nghiệm
Để đánh giá hiệu quả của phương pháp chuyển đổi, Luận án đánh giá các quy tắc chuyển đổi được đề xuất bằng cách áp dụng chuyển đổi trên hai mô hình mẫu sang OWL, so sánh kết quả chuyển đổi của Luận án đề xuất với các phương pháp liên quan Hai mô hình cơ sở dữ liệu mẫu là mô hình thư mục trích dẫn [33] và mô hình Elmasri [2]
Bảng 2.3 Các cơ sở dữ liệu được thực nghiệm trong luận án
Mô hình thư mục trích dẫn [33] Mô hình Elmasri [2]
Thực thể yếu và mối quan hệ định danh
Thuộc tính đa trị phức hợp lồng nhau
Mối quan hệ nhị nguyên không có thuộc tính
Mối quan hệ nhị nguyên có thuộc tính
13 Mối quan hệ phản xạ 1 1 1 3 3 3
Mối quan hệ đa nguyên
Mối quan hệ kế thừa
Yếu tố thời gian của tập thực thể
Thuộc tính có yếu tố thời gian của tập thực thể
Mối quan hệ có yếu tố thời gian
Thuộc tính có yếu tố thời gian của mối quan hệ
Luận án áp dụng các quy tắc chuyển đổi của các đề xuất trước đây có liên quan nhất, như Sujatha R Upadhyaya [6], M Fahad [7], Igor Myroshnichenko [8], Pasapitch Chujai [10] và phương pháp của Luận án đề xuất Với mỗi mô hình ER cho trước, luận án thực hiện chuyển đổi sang OWL và đánh giá hiệu suất dựa trên từng phương pháp chuyển đổi đã đề xuất Luận án tính độ chính xác [34] sau khi chuyển đổi theo công thức = 𝐶
𝐴+𝐶, trong đó, A là tập các phần tử có trong mô hình ER, C là các phần tử OWL được chuyển đổi sau khi áp dụng các quy tắc chuyển đổi đã đề xuất
Hình 2.27 So sánh hiệu suất chuyển đổi giữa các phương pháp trên mô hình thư mục trích dẫn
Hình 2.28 So sánh hiệu suất chuyển đổi giữa các phương pháp trên mô hình Elmasri
Bảng 2.3 đánh giá và so sánh kết quả chuyển đổi của 5 phương pháp đã xây dựng tương ứng với hai mô hình thư mục trích dẫn [33] và mô hình Elmasri [2] Với mô hình thư mục trích dẫn [33], các phương pháp đề xuất [6], [7], [8], [10] đều chuyển đổi hầu hết các trường hợp, bởi vì mô hình này không chứa các thành phần được chỉ ra trong Mục 2.3 Nhưng với mô hình Elmasri [2] với nhiều trường hợp tổng quát hơn thì các phương pháp [6], [7], [8], [10] không chuyển đổi được Với các quy tắc chuyển
Pasapitch Chujai Tiếp cận của chúng tôi
Pasapitch Chujai Tiếp cận của chúng tôi
74 đổi của luận án đề xuất, các trường hợp của mô hình [2] đều được chuyển đổi sang ontology
Kết quả thực nghiệm cho thấy các phương pháp chuyển đổi đã đề xuất đều chuyển đổi các đối tượng cơ bản của mô hình như tập thực thể, thuộc tính, mối quan hệ nhị nguyên, trong đó phương pháp chuyển đổi của Luận án đề xuất đầy đủ nhất Với số liệu so sánh ở Hình 2.28, mô hình EER có nhiều trường hợp như yếu tố thời gian, quan hệ tổng quát hóa/chuyên biệt hóa… đã cho thấy kết quả chuyển đổi của phương pháp mà Luận án đề xuất là đầy đủ hơn so với các kết quả của các đề xuất liên quan trước đây Từ kết quả thực nghiệm của 4 phương pháp chuyển đổi đã minh chứng tính đầy đủ hơn của phương pháp đề xuất đối với bài toán chuyển đổi mô hình
ER mở rộng sang OWL
Location VT marriedTo husband (1,1) wife (1,1)
TaxJointlyWith ta xp ay er sW ith (0 ,1 ) ta xp ay er sW ith (0 ,1 ) guards guard (0,1) isGuardedBy (0,1) year
Manages Rank position App_date
(1, N) foreign_language_proficiency language certificate kind score
Hình 2.29 Mô hình EER của Elmasri
Dependent_Employee inverseOf domain range domain range cardinality
Functional DatatypeProperty domain domain range range
Department_RespFor domain domain range range
BelongTo domain domain range range
Reflexive ObjectProperty taxpayersWith range domain
Reflexive Asymmetric ObjectProperty wife range range domain domain inverse onProperty onProperty
Guards_guard inverse domain domain range range
Guards_isGuardBy inverse domain domain range range
Functional ObjectProperty range range domain domain inverse
Functional ObjectProperty inverse domain range range
Manages_Project domain domain range range inverse inverse domain domain range range position
Foreign_language_profi ciency_certificate
Functional ObjectProperty certificate_foreign_lan guage_proficiency inverse
Employee_foreign_lan guage_proficiency
ObjectProperty foreign_language_prof iciency_Employee inverse domain domain range range domain domain range range
Employee_has_LT LT_of_Employee
ObjectProperty domain domain range range
Salary_has_BT domain range range domain
Department_has_TT range range domain domain
Location_VT VT_of_Location
Location_has_VT range range domain domain subClassOf onProperty
Location domain inverse inverse inverse inverse
Hình 2.30 Mô hình OWL chuyển đổi từ Hình 2.29
Hình 2.31 Giao diện ứng dụng chuyển đổi mô hình Elmasri sang OWL ontology
Tổng kết chương 2
Chương này đã trình bày phương pháp chuyển đổi mô hình ER và EER sang OWL Các quy tắc chuyển đổi tập thực thể mạnh, thực thể yếu; các quy tắc chuyển đổi thuộc tính như thuộc tính đơn, thuộc tính đa trị, thuộc tính phức hợp, thuộc tính khóa, thuộc tính đa trị phức hợp lồng nhau; các quy tắc chuyển đổi mối quan hệ như quan hệ nhị nguyên, quan hệ phản xạ, quan hệ đa nguyên Trong đó, liên quan đến mối quan hệ phản xạ, luận án đã phân loại để xác định các trường hợp chuyển đổi thích hợp đối với mỗi phân loại này Trên cơ sở các quy tắc chuyển đổi đó, luận án cũng đã đề xuất phương pháp chuyển đổi mô hình TimeER, là một mô hình ER mở rộng có yếu tố thời gian, sang OWL Phương pháp được thực hiện qua ba bước: Đầu tiên, chuyển các thành phần không có yếu tố thời gian (kể cả tập thực thực thể có yếu tố thời gian) sang OWL Tiếp theo, khởi tạo OWL thể hiện yếu tố thời gian và chuyển đổi các thành phần có yếu tố thời gian sang OWL
Kết quả về chuyển đổi mô hình ER và EER sang OWL được báo cáo tại Hội nghị Recent Developments in Intelligent Information and Database Systems – ACIIDS
(2016) [CT1], và trình bày trong tạp chí Tạp chí Khoa học và Công nghệ, Đại học Khoa học Huế (2017) [CT3] và tạp chí Tin học và Điều khiển học (2018) [CT4]
Bên cạnh việc thiết kế bằng mô hình ER hoặc mô hình EER, các hệ thống còn được mô hình hóa bằng biểu đồ lớp UML để mô tả và phản ảnh tốt thế giới thực của các hệ thống thông tin Trên cơ sở phương pháp chuyển đổi mô hình ER và EER sang OWL, trong Chương tiếp theo sẽ trình bày phương pháp chuyển đổi biểu đồ lớp UML sang OWL
CHUYỂN ĐỔI BIỂU ĐỒ LỚP UML SANG OWL
Các nghiên cứu trước đây
Biểu đồ lớp UML và OWL đều biểu diễn các thực thể, thuộc tính và các mối quan hệ của chúng, sau khi xác định các thành phần tương ứng giữa biểu đồ lớp UML và OWL Luận án đã hình thức hóa các kết quả nghiên cứu trước đây thành các quy tắc chuyển đổi các thành phần trên biểu đồ lớp UML thành các thành phần tương ứng trong OWL
Name: Name_dom Emp_ID
Hình 3.1 Ví dụ biểu đồ lớp UML
Biểu đồ lớp UML và OWL2 đều có khái niệm lớp Lớp trong UML là cấu trúc tổng quát hơn, chứa một tập hợp các thể hiện [18] Lớp trong OWL2 là một tập rỗng hoặc có nhiều thể hiện và không xác định thao tác trên các thể hiện đó Do OWL không thể biểu diễn lớp trừu tượng, vì vậy việc chuyển đổi lớp trừu tượng không thể thực hiện Quy tắc chuyển đổi lớp thực hiện như sau:
Quy tắc UML1 Với mỗi lớp UML U được chuyển đổi thành lớp C(U) tương ứng trong OWL, thiết lập tính chất DisjointClasses cho mỗi cặp lớp nếu chúng không phải là quan hệ tổng quát hóa [19]
Ví dụ 3.1 Trong Hình 3.2, lớp đối tượng Employee được chuyển thành lớp Employee trong OWL
Ta có thuật toán chuyển đổi lớp như sau:
Thuật toán 3.1 Chuyển đổi lớp trong biểu đồ lớp UML
Input: Tập các lớp U trong biểu đồ lớp UML
2 For mỗi lớp U i trong tập các lớp của biểu đồ lớp UML
3 Áp dụng quy tắc UML1: chuyển đổi lớp;
Thuộc tính trong UML có thể có nhiều mức độ phạm vi truy xuất khác nhau, mô tả thuộc tính đó có thể được truy xuất từ các lớp khác Với OWL, thuộc tính dữ liệu không hỗ trợ phạm vi truy xuất, vì vậy luận án chỉ chuyển đổi thuộc tính trong UML sang OWL tùy thuộc vào kiểu của thuộc tính trên mức độ tổng quát
3.1.2.1 Chuyển đổi thuộc tính có kiểu dữ liệu nguyên thủy
Với kiểu của thuộc tính là kiểu dữ liệu nguyên thủy, các thuộc tính sẽ được chuyển đổi thành thuộc tính dữ liệu trong OWL Nếu kiểu của thuộc tính là lớp, thuộc tính đó được chuyển đổi thành thuộc tính đối tượng Tác giả [22] có đề xuất chuyển đổi thuộc tính khóa của lớp nhưng trong thực tế vẫn có trường hợp lớp không có thuộc tính khóa, mà chỉ có ràng buộc OCL là “unique” (duy nhất) cho thuộc tính mà thôi
Quy tắc UML2 Chuyển đổi thuộc tính attU của lớp đối tượng U có kiểu dữ liệu nguyên thủy trong UML thành thuộc tính kiểu dữ liệu DP(attU) tương ứng trong lớp C(U) Thuộc tính kiểu dữ liệu DP(attU) có phạm vi là kiểu dữ liệu tương ứng trong
OWL, và miền là lớp C(U), đồng thời thiết lập tính chất hàm [21] [20] Nếu thuộc tính attU có ràng buộc OCL là duy nhất (unique) thì bổ sung thuộc tính khóa DP(attU) cho lớp C(U), thiết lập tính chất hàm và bản số là 1
Ví dụ 3.2 Áp dụng quy tắc UML2, thuộc tính Sex, Birthday và Salary được chuyển đổi thành thuộc tính kiểu dữ liệu tương ứng, thuộc tính như trong Hình 3.2
Restriction subClas sOf onP roperty
Hình 3.2 Ví dụ chuyển đổi thuộc tính và thuộc tính có cấu trúc của lớp đối tượng
3.1.2.2 Chuyển đổi thuộc tính có kiểu dữ liệu liệt kê Để biểu diễn kiểu dữ liệu liệt kê trong OWL, có hai cách để thực hiện Cách thứ nhất là khai báo thuộc tính với phạm vi là danh sách các giá trị liệt kê với cú pháp
DataOneOf Cách thứ hai là khai báo mới một kiểu dữ liệu liệt kê trong OWL với cú pháp DataOneOf, và thuộc tính kiểu dữ liệu có phạm vi là kiểu dữ liệu liệt kê vừa khai báo ở trên
Trong trường hợp này, luận án nhận thấy rằng sử dụng cách thứ hai là chính xác hơn Lý do kiểu dữ liệu liệt kê là kiểu dữ liệu do người dùng tự định nghĩa, vì thế khai báo kiểu dữ liệu trong OWL là chính xác Ngoài ra, nếu sử dụng theo cách thứ nhất, giả sử rằng có một thuộc tính nào khác cùng sử dụng các giá trị của kiểu dữ liệu liệt kê đó thì phải khai báo lại Nhưng nếu áp dụng cách thứ hai sẽ không cần phải khai báo, mà có thể sử dụng chung kiểu dữ liệu liệt kê
Quy tắc UML3 Khai báo kiểu dữ liệu liệt kê attU_enum với cú pháp DataOneOf
Chuyển đổi thuộc tính attU của lớp U có kiểu dữ liệu liệt kê trong UML thành thuộc tính đối tượng DP(attU) tương ứng trong lớp C(U), có miền là lớp C(U) và phạm vi là kiểu dữ liệu liệt kê attU_enum [22]
Sunday Monday Tuesday Wednesday
Thursday
Friday Saturday
Hình 3.3 Ví dụ chuyển đổi kiểu dữ liệu liệt kê
Ví dụ 3.3 Trong thực tế, các ngày trong tuần thường được sử dụng rất nhiều, vì thế cần tạo kiểu dữ liệu liệt kê mới là DaysOftheWeek để mô tả cho kiểu dữ liệu trong OWL như Hình 3.3
3.1.2.3 Chuyển đổi thuộc tính có kiểu dữ liệu là lớp
Quy tắc UML4 Chuyển đổi thuộc tính attU của lớp đối tượng U có kiểu dữ liệu là lớp F trong UML thành thuộc tính đối tượng attU tương ứng trong lớp C(U), có miền là lớp C(U) và phạm vi là lớp C(F) tương ứng [22]
Ví dụ 3.4 Ở ví dụ Hình 3.2, thuộc tính att2 được chuyển đổi thành thuộc tính đối tượng att2 với miền là lớp Class1 và phạm vi là lớp Class2
3.1.3 Chuyển đổi quan hệ giữa các lớp
Trong UML có các loại quan hệ khác nhau là quan hệ kết hợp, quan hệ kết tập, quan hệ kế thừa và quan hệ phụ thuộc
Quan hệ kết hợp trong UML có thể là một chiều hoặc là vô hướng Vì vậy một quan hệ kết hợp có thể được chuyển đổi thành thuộc tính đối tượng trong OWL Đối với quan kệ kết hợp hai chiều sẽ được chuyển đổi thành hai thuộc tính đối tượng cho mỗi hướng Để đảm bảo rằng cả hai thuộc tính đối tượng này là một phần của quan hệ kết hợp, vì vậy cần thiết lập tính chất ngược nhau cho hai thuộc tính đối tượng [22]
Quy tắc UML5 Xét mối quan hệ kết hợp R giữa hai lớp đối tượng A và B:
- Bổ sung hai thuộc tính đối tượng ngược nhau biểu diễn mối quan hệ giữa hai lớp C(A) và C(B): A_R_B và B_R_A
- Ràng buộc bản số trên các lớp đối tượng UML sẽ được hoán đổi vị trí giữa hai lớp khi chuyển đổi sang OWL Với mỗi giá trị lượng số (min, max), nếu min khác 0 hoặc max khác N trên mối quan hệ R thì bổ sung ràng buộc số lượng cực tiểu/cực đại vào thuộc tính đối tượng tương ứng [22]
Ví dụ 3.5 Trong Hình 3.4, lớp CLASS1 có quan hệ assoc với lớp CLASS2 khi chuyển sang OWL sẽ tạo thành cặp thuộc tính đối tượng ngược nhau
Các quy tắc chuyển đổi bổ sung
Qua các đề xuất chuyển đổi của các nghiên cứu đã công bố, luận án thấy rằng còn nhiều trường hợp của biểu đồ lớp UML chưa được đề xuất Trên cơ sở các nghiên cứu đã có, luận án đề xuất các quy tắc chuyển đổi bổ sung cho các trường hợp này nhằm hoàn thiện bộ quy tắc chuyển đổi biểu đồ lớp UML sang ontology
3.2.1 Chuyển đổi thuộc tính có cấu trúc
Trong trường hợp các thuộc tính có cấu trúc phức tạp hoặc có các thuộc tính liên hệ với nhau và có ngữ nghĩa cụ thể trong thế giới thực thì cần tách thành một lớp độc lập với nhau Tuy nhiên trong thực tế, vẫn có một số trường hợp thuộc tính có cấu trúc vẫn cần giữ cấu trúc phức tạp để biểu diễn đúng ngữ nghĩa của thế giới thực
Tác giả [22] đề xuất chuyển thuộc tính có cấu trúc thành lớp mới và liên kết bằng thuộc tính đối tượng Tuy nhiên, thuộc tính kiểu dữ liệu trong OWL có hỗ trợ cấu trúc phân cấp, vì thế việc chuyển đổi thuộc tính có cấu trúc thành các thuộc tính con sẽ biểu diễn đúng ngữ cảnh hơn, đồng thời không tạo lớp mới cũng như thuộc tính đối tượng
Quy tắc UML10 Thuộc tính có cấu trúc attU của lớp U với tập các thuộc tính thành phần là sub_attU được chuyển đổi thành thuộc tính kiểu dữ liệu DP(attU) của lớp C(U) Các thuộc tính thành phần sub_attU được chuyển đổi thành các thuộc tính kiểu dữ liệu
DP(sub_attU) và là thuộc tính con của thuộc tính kiểu dữ liệu DP(attU), có tính chất hàm, miền là thuộc tính dữ liệu DP(attU) và phạm vi là kiểu dữ liệu tương ứng trong OWL
Ví dụ 3.11 Thuộc tính có cấu trúc Name ở Hình 3.2 được chuyển đổi thành thuộc tính kiểu dữ liệu Name và các thuộc tính thành phần chính là các thuộc tính con của thuộc tính Name
3.2.2 Chuyển đổi quan hệ kết hợp phản xạ
Một quan hệ kết hợp phản xạ là một quan hệ kết hợp đến chính nó Quan hệ kết hợp ở đây vẫn thể hiện một sự liên quan ngữ nghĩa, nhưng các đối tượng được nối kết đều thuộc chung một lớp Lúc này, một tập hợp các thể hiện có thể đảm nhận một vai trò duy nhất hoặc hai vai trò khác nhau trong cùng mối quan hệ Tác giả [22] đã đề xuất quy tắc chuyển đổi quan hệ kết hợp đệ quy, tuy nhiên chưa phân loại mối quan hệ kết hợp phản xạ, vì vậy việc chuyển đổi chưa phản ảnh đúng bản chất của mối quan hệ này Việc kiểm tra các vai trò cho phép phân loại tất cả các quan hệ kết hợp phản xạ đó thành là quan hệ kết hợp phản xạ đối xứng hoặc bất đối xứng Một quan hệ kết hợp phản xạ được gọi là có tính chất đối xứng khi tất cả các thể hiện tham gia vào quan hệ có một vai trò duy nhất và có cùng ngữ nghĩa Theo đó, nếu R là quan hệ có tính chất đối xứng thì role 1role 2, với role 1 và role 2 là tên của hai vai trò của quan hệ phản xạ R Ngược lại, nếu R không có tính chất đối xứng, thì gọi quan hệ kết hợp phản xạ là bất đối xứng
Quy tắc UML11 Xét quan hệ kết hợp phản xạ đối xứng của lớp đối tượng A với vai trò là role, quy tắc chuyển đổi như sau:
- Bổ sung thuộc tính đối tượng có định danh là tên vai trò role trong mối quan hệ, có miền và phạm vi là lớp C(A), thiết lập tính chất đối xứng với cú pháp ReflexiveProperty cho thuộc tính đối tượng trên;
- Nếu lượng số (multiplicity) quan hệ đệ quy là 1-1, thêm ràng buộc số lượng cực đại bằng 1;
- Với ràng buộc lượng số nhỏ nhất lần lượt là ‘1-1’ thì thêm ràng buộc số lượng cực tiểu bằng 1 lên thuộc tính đối tượng được thêm vào
Ví dụ 3.12 Áp dụng quy tắc chuyển đổi mối quan hệ kết hợp phản xạ đối xứng
TaxJointlyWith của lớp Person thành thuộc tính đối tượng TaxJointlyWith với miền và phạm vi là lớp Person như Hình 3.9
Restriction subClas sOf onP roperty
Hình 3.9 Ví dụ chuyển đổi mối quan hệ phản xạ đối xứng
Quy tắc UML12 Xét quan hệ kết hợp phản xạ bất đối xứng của lớp đối tượng A với tên hai vai trò là role 1 và role 2:
- Bổ sung cặp thuộc tính đối tượng ngược nhau có định danh lần lượt là tên của hai vai trò role 1 và role 2 trong quan hệ, có miền và phạm vi là lớp C(E);
- Ràng buộc lượng số (multiplicity) trên lớp đối tượng UML sẽ được hoán đổi vị trí giữa hai vai trò khi chuyển đổi sang OWL Với mỗi vai trò có lượng số min/max khác
0 và khác N, bổ sung ràng buộc số lượng cực tiểu/cực đại tương ứng vào thuộc tính đối tượng ứng với vai trò đó
ObjectProperty supervisor range range domain domain invers e onP roperty
Hình 3.10 Ví dụ chuyển đổi mối quan hệ đệ quy bất đối xứng
Ví dụ 3.13 Với mối quan hệ bất đối xứng có hai vai trò supervisor và supervisee của lớp Employee, do ngữ nghĩa của hai vai trò này là khác nhau, vì thế để bảo toàn ngữ nghĩa khi chuyển đổi, áp dụng quy tắc chuyển đổi mối quan hệ đệ quy bất đối xứng sẽ có hai thuộc tính đối tượng supervisor và supervisee, miền và phạm vi chính là lớp Employee Do bản số của supervisee là * và supervisor là 1-1, vì thế khi chuyển qua
OWL sẽ hoán đổi vị trí của hai bản số, vì thế với thuộc tính đối tượng supervisee sẽ thiết lập maxQualifiedCardinality là 1, kết quả như Hình 3.10
3.2.3 Chuyển đổi quan hệ kết tập chia sẻ
Quan hệ kết tập chia sẻ (Shared Aggregation) là quan hệ mà phía bộ phận có thể tham gia nhiều vào phía tổng thể, ngược lại với quan hệ kết tập thông thường là một đối tượng của một lớp bộ phận không được thuộc nhiều hơn một lớp tổng thể
Ví dụ lớp LOCATION có thể có nhiều dự án và mỗi dự án của lớp PROJECT chỉ có thể có một địa điểm Trong quan hệ này, chỉ có thể loại bỏ, hay thành lập mới một dự án (phía tổng thể) nhưng không nhất thiết phải loại bỏ hay thêm mới những địa điểm (phía bộ phận)
Với tính chất đó, ta nhận thấy rằng:
- Quan hệ kết tập là sự kết hợp giữa các lớp không đối xứng, vì thế khi chuyển đổi phải thiết lập tính chất không đối xứng với cú pháp ASymmetricProperty
- Quan hệ kết tập không có tính chất phản xạ, tức là một lớp không quan hệ kết tập với chính nó, vì thế khi chuyển đổi phải thiết lập tính chất không phản xạ với cú pháp
IrReflexiveProperty Cú pháp này ngăn các cá thể liên quan với chính nó bằng thuộc tính đối tượng mà biểu diễn cho quan hệ kết tập
Quy tắc UML13 Xét lớp tổng thể A quan hệ kết tập với lớp bộ phận F, ta có quy tắc chuyển đổi như sau:
- Bổ sung thêm hai thuộc tính đối tượng ngược nhau thể hiện quan hệ giữa lớp
C(A) và lớp C(F): A_F có miền là lớp C(A), phạm vi là lớp C(F); F_A có miền là lớp C(F), phạm vi là lớp C(A);
Kết quả thực nghiệm
Luận án đánh giá các quy tắc chuyển đổi được đề xuất bằng cách áp dụng chuyển đổi trên hai biểu đồ lớp UML mẫu sang OWL để xác định các kết quả phù hợp thực sự và so sánh kết quả của Luận án với các phương pháp liên quan Hai biểu đồ lớp mẫu là biểu đồ lớp UML Purchase Order Application [35] và Elmasri [2]
Biểu đồ lớp Purchase Order Application [35] có 9 lớp với 32 thuộc tính Lớp bộ phận OrderLineItem có mối quan hệ kết tập với lớp tổng thể PurchaseOrder Lớp OrderLineItem có mối quan hệ với lớp Products Quan hệ kết hợp giữa lớp Products và lớp Store có lớp kết hợp Stock Lớp bộ phận Customer là lớp tổng quát hóa/chuyên biệt hóa của hai lớp Person và Company, đồng thời có quan hệ kết tập chia sẻ với lớp tổng thể Customer_Association
Bảng 3.1 Các cơ sở dữ liệu được thực nghiệm trong luận án
2 Thuộc tính có kiểu dữ liệu nguyên thủy 32 18
3 Thuộc tính có kiểu dữ liệu liệt kê
4 Thuộc tính có kiểu dữ liệu là lớp
5 Thuộc tính có cấu trúc 1
7 Quan hệ kết hợp có lớp kết hợp 1 2
8 Quan hệ kết hợp đệ quy đối xứng
9 Quan hệ kết hợp đệ quy bất đối xứng 1
10 Quan hệ kết tập thông thường 1
11 Quan hệ kết tập chia sẻ 1 2
12 Quan hệ kết hợp có yếu tố hạn định 1
14 Quan hệ tổng quát hóa/ chuyên biệt hóa 1
Biểu đồ lớp Elmasri [2] có 10 lớp và 18 thuộc tính Lớp Employee là lớp tổng quát hóa/chuyên biệt hóa của ba lớp Secretary, Technical và Engineer Lớp Employee có bốn mối quan hệ với các lớp: mối quan hệ kết hợp với lớp Department và có lớp kết hợp Manages; mối quan hệ kết hợp đệ quy bất đối xứng với chính nó; mối quan hệ kết tập với lớp Dependent có yếu tố hạn định Dependent_name; mối quan hệ kết hợp với lớp Project có lớp kết hợp Worrk_on Lớp Location có mối quan hệ kết tập chia sẻ với hai lớp Department và Project Ba lớp bộ phận Secretary, Technical, Engineer có quan hệ tổng quát hóa/chuyên biệt hóa với lớp Employee Lớp Department có quan hệ kết hợp với lớp Project
Hình 3.13 So sánh hiệu suất chuyển đổi trên biểu đồ lớp UML Purchase Order Application
Sara Brocman Gherabi Iman Jessper Oussama Tiếp cận của chúng tôi
Hình 3.14 So sánh hiệu suất chuyển đổi trên biểu đồ lớp UML Elmasri
Hình 3.15 Kết quả chuyển đổi trên OntoGraf
Khi thực nghiệm biểu đồ lớp Purchase Order Application [35] với các quy tắc chuyển đổi của các tác giả như S.Brockmans [13], Noreddine Gherabi [16], Imnas Zarembo [18], Jesper Zedlitz [19] [20] [21], Oussama [22] Luận án tính độ chính xác
[34] sau khi chuyển đổi theo công thức = 𝐶
𝐴+𝐶, trong đó, A là tập các phần tử có trong biểu đồ lớp UML, C là các phần tử OWL được chuyển đổi sau khi áp dụng các quy tắc chuyển đổi đã đề xuất
Số liệu so sánh từ Hình 3.13 và Hình 3.14 cho thấy phương pháp chuyển đổi của các đề xuất là chưa đầy đủ, nhưng trong đó phương pháp của Luận án đề xuất là cao hơn so với các phương pháp khác Với số liệu so sánh ở Hình 3.14, biểu đồ mẫu [2] có bổ sung nhiều trường hợp như thuộc tính có cấu trúc, quan hệ kết hợp có lớp kết hợp, quan
Sara Brocman Gherabi Iman Jessper Oussama Tiếp cận của chúng tôi
99 hệ kết hợp có yếu tố hạn định… đã cho thấy kết quả chuyển đổi của phương pháp mà Luận án đề xuất là đầy đủ hơn so với các kết quả của các đề xuất liên quan trước đây Để thử nghiệm các quy tắc đề xuất, Luận án thực nghiệm chuyển đổi biểu đồ lớp UML như ở Hình 3.1 Để kiểm tra OWL kết quả, Luận án thử nghiệm trên phần mềm Protégé và kết quả hiển thị trong OntoGraf như ở Hình 3.15 và kết quả OWL chuyển đổi được mô tả như Hình 3.16 domain domain range range onP roperty invers e
Restriction subClas sOf onP roperty
DatatypeProperty domain domain range range
Manages domain domain range range
1 onP roperty subClas sOf onP roperty
Restriction subClas sOf Max cardinality
ObjectProperty supervisor range range domain domain invers e onP roperty
DepartmentRespForProject disjointWith subClas sOf subClas sOf subClas sOf
DatatypeProperty onP ro perty subClas sOf
DependentOf Employee invers e domain domain range range
LOCATION domain domain range range
WORKON domain domain range range
1 onP roperty subClas sOf onP roperty
Functional DatatypeProperty invers e invers e disjointWith
Location_Project domain range domain range invers eOf onP roperty subClas sOf
Location_Project domain range domain range invers eOf onP roperty
Hình 3.16 Mô hình OWL chuyển đổi từ Hình 3.1
Hình 3.17 Một phần kết quả OWL2 chuyển đổi từ biểu đồ lớp ở Hình 3.1
Tổng kết Chương 3
Mặc dù có một số điểm không tương đồng giữa biểu đồ lớp UML và OWL ontology, chương này đã trình bày tập các quy tắc chuyển đổi các thành phần của biểu đồ lớp UML như lớp, thuộc tính, các mối quan hệ sang OWL ontology để mô tả ngữ nghĩa của biểu đồ lớp UML Kế thừa các nghiên cứu trước đây, Luận án đã phân tích và
101 xây dựng bổ sung các quy tắc chuyển đổi cho các trường hợp như chuyển đổi thuộc tính có cấu trúc, quan hệ kết hợp có lớp kết hợp, quan hệ kết hợp có yếu tố hạn định Tính hiệu quả của phương pháp đề xuất bởi luận án được thể hiện rõ qua các kết quả thực nghiệm được trình bày ở cuối chương
Kết quả các đề xuất đã được báo cáo tại Hội nghị Khoa học quốc gia lần thứ IX về
"Nghiên cứu cơ bản và ứng dụng Công nghệ thông tin" FAIR'10 Đà Nẵng, 2017 [CT2] và đăng tải trên tạp chí Journal of Information and Telecommunication (2020) [CT7] Chương 2 và Chương 3 đã trình bày phương pháp chuyển đổi từ mô hình cơ sở dữ liệu mức khái niệm sang OWL Tuy nhiên, để hiểu được dữ liệu OWL ontology cũng như có cái nhìn tổng quan của OWL ontology là điều khó khăn, trong khi đó mô hình mức khái niệm là tường minh cho người thiết kế Vì vậy cần trích xuất OWL ontology thành mô hình cơ sở dữ liệu mức khái niệm để mô hình hóa các đối tượng trong thế giới thực Chương tiếp theo sẽ trình bày phương pháp trích xuất một mô hình cơ sở dữ liệu mức khái niệm từ OWL ontology
TRÍCH XUẤT MÔ HÌNH CƠ SỞ DỮ LIỆU MỨC KHÁI NIỆM TỪ
Trích xuất mô hình EER từ OWL
4.1.1 Các quy tắc trích xuất đã đề xuất
Công trình nghiên cứu của các tác giả trước đây trong việc ánh xạ các thành phần của OWL sang mô hình ER được tổng hợp như sau:
4.1.1.1 Trích xuất tập thực thể
Khi xét đến Rules EER1, để thực hiện chuyển đổi một tập thực thể trong mô hình
ER thành một lớp trong OWL, cho thấy rằng khái niệm lớp trong OWL tương đương
103 với tập thực thể trong mô hình ER Vì vậy quy tắc trích xuất tập thực thể như là một ánh xạ ngược của quy tắc này, và được phát biểu như sau:
Quy tắc OWL1 Lớp C trong OWL được khai báo bằng cú pháp owl:class hoặc rdfs:subClassOf được chuyển đổi thành tập thực thể E(C) trong mô hình ER [24]
Ví dụ 4.1 Xét ví dụ mã nguồn biểu diễn lớp trong OWL:
Hình 4.1 Trích xuất thuộc tính đơn trị
Ta thấy rằng lớp Employee được khai báo với cú pháp owl:Class được trích xuất thành tập thực thể cùng tên như ở Hình 4.1
Trong OWL, thuộc tính kiểu dữ liệu mô tả các đối tượng cá thể của một lớp và cung cấp các dữ kiện cụ thể về các đối tượng cá thể trong một lớp Thuộc tính kiểu dữ liệu liên kết các đối tượng cá thể với các giá trị kiểu dữ liệu Với mô hình ER, thực thể được mô tả bởi các thuộc tính
4.1.1.2.1 Trích xuất thuộc tính đơn trị
Trong OWL, thuộc tính kiểu dữ liệu thường liên kết các cá thể với các giá trị dữ liệu và có đặc tính “đa trị”, nên để một thuộc tính kiểu dữ liệu nhận một giá trị duy nhất, thì thuộc tính đó được thiết lập tính chất hàm FunctionalDataProperty Thuộc tính kiểu dữ liệu là kiểu dữ liệu đơn, vì thế chúng tương đương với thuộc tính đơn trong mô hình
ER, điều này tương ứng ngữ nghĩa với thuộc tính đơn trị của mô hình ER Vì vậy ta có quy tắc trích xuất thuộc tính đơn trị như sau:
Quy tắc OWL2 Thuộc tính kiểu dữ liệu dpC có tính chất hàm FunctionalProperty, có miền là lớp C và phạm vi là kiểu dữ liệu nguyên thủy trong OWL được ánh xạ thành thuộc tính đơn trị A(dpC) của thực thể E(C), có kiểu dữ liệu tương ứng trong mô hình
Ví dụ 4.2 Xét ví dụ mã nguồn biểu diễn thuộc tính trong OWL:
Như ở Ví dụ 4.2, thuộc tính kiểu dữ liệu Birthday được biểu diễn có tính chất hàm
FunctionalProperty, có miền là lớp Employee và kiểu dữ liệu là kiểu ngày dateTime, vì thế được trích xuất thành thuộc tính Birthday của lớp Employee như Hình 4.1
4.1.1.2.2 Trích xuất thuộc tính khóa
Trong OWL1, không có có khái niệm khoá chính cũng như hỗ trợ khai báo khóa, nhưng trong OWL2, một tập hợp các thuộc tính (dữ liệu hoặc đối tượng) có thể được gán như là khóa bằng cách sử dụng cú pháp owl:hasKey Điều này tương đương với ngữ nghĩa của khoá trong mô hình ER vì thuộc tính khoá phải là thuộc tính đơn, chỉ nhận một giá trị duy nhất, không nhận giá trị null nên quy tắc trích xuất thuộc tính khóa như sau:
Quy tắc OWL3 Thuộc tính kiểu dữ liệu keyC có miền là C và phạm vi là kiểu dữ liệu nguyên thủy trong OWL2 được khai báo bằng cú pháp owl:hasKey được trích xuất thành thuộc tính khoá A(keyC) của tập thực thể E(C) [24]
Ví dụ 4.3 Xét ví dụ mã nguồn biểu diễn thuộc tính khóa trong OWL2:
1
Lớp Employee có khai báo owl:hasKey là thuộc tính EmpID, bên cạnh đó thuộc tính kiểu dữ liệu EmpID có miền là lớp Employee và phạm vi là kiểu dữ liệu Interger, ràng buộc minQualifiedCardinality và maxQualifiedCardinality thiết lập là 1, vì thế được trích xuất thành thuộc tính khóa EmpID của tập thực thể Employee như Hình 4.1
4.1.1.2.3 Trích xuất thuộc tính đa trị
Như đã đề cập ở trên, OWL mặc định cho phép các thuộc tính kiểu dữ liệu đa trị có nhiều giá trị, hoặc sẽ được xác định thuộc tính kiểu dữ liệu bằng hạn chế bản số lớn hơn 1 Nếu khai báo cardinality hoặc minQualifiedCardinality lớn hơn 1 cho thuộc tính
105 của một lớp, thì bất kỳ thể hiện của lớp có thể liên quan đến nhiều cá thể của thuộc tính đó Vì thế có ngữ nghĩa tương đương với thuộc tính đa trị trong mô hình ER
Quy tắc OWL4 Thuộc tính kiểu dữ liệu dpC có khai báo cardinality hoặc minQualifiedCardinality lớn hơn 1, có miền là lớp C và kiểu dữ liệu nguyên thủy trong
OWL được chuyển đổi thành thuộc tính đa trị A(dpC) của tập thực thể E(C), có kiểu dữ liệu tương ứng trong mô hình ER [24]
Ví dụ 4.4 Xét ví dụ mã nguồn biểu diễn thuộc tính kiểu dữ liệu Location:
Hình 4.2 Trích xuất thuộc tính đa trị Location
Thuộc tính kiểu dữ liệu Location có miền là lớp Department và phạm vi là kiểu chuỗi String, tuy nhiên thuộc tính này không thiết lập ràng buộc hạn chế và cũng không thiết lập tính chất hàm, vì vậy trích xuất thành thuộc tính đa trị của lớp Department như Hình 4.2
4.1.1.3 Trích xuất mối quan hệ
Một mối quan hệ có thể kết nối hai hoặc nhiều tập thực thể với nhau Trong OWL, thuộc tính đối tượng được sử dụng để biểu diễn mối quan hệ nhị nguyên giữa hai lớp, giúp liên kết các cá thể của hai lớp này với nhau Điều này tương tự như mối quan hệ trong mô hình ER kết nối ngữ nghĩa giữa các tập thực thể
Ví dụ 4.5 Xét ví dụ cặp thuộc tính đối tượng giữa hai lớp Department và Project
Như Ví dụ 4.5 mô tả cặp thuộc tính đối tượng giữa hai lớp Department và Project, thuộc tính đối tượng Department_ Project có miền là lớp Department và phạm vi là lớp
Project Miền của thuộc tính đối tượng ngược Project _Department là lớp Project và phạm vi là lớp Department
Từ các mối quan hệ trong OWL, vậy làm thế nào để xác định mối quan hệ kết hợp là 1-1, 1-N hay N-N giữa hai lớp trong OWL? Điều này sẽ được xác định bởi ràng buộc min/max của cặp thuộc tính đối tượng
Ví dụ 4.6 Xét ví dụ cặp thuộc tính đối tượng biểu diễn mối quan hệ 1-1
1
1
1
1
Ở Ví dụ 4.6, thuộc tính đối tượng Department_Project có minQualifiedCardinality và maxQualifiedCardinality là 1 tương ứng với lớp Department minQualifiedCardinality bằng 1 có nghĩa là thuộc tính đối tượng đó phải có giá trị cho tất cả các thể hiện của lớp này Tuy nhiên trong một số trường hợp OWL không khai báo ràng buộc bản số, thì có nghĩa là bản số của quan hệ là 0-N Vì thế ta có quy tắc trích xuất như sau:
Trích xuất biểu đồ lớp UML từ OWL
Vấn đề trích xuất một biểu đồ lớp UML từ OWL cho trước được xem là việc xác định một ánh xạ ngược của ánh xạ chuyển đổi từ biểu đồ lớp UML sang OWL mà Luận án đã trình bày trong Chương 2 và Chương 3 Như đã đề cập ở mục 1.3.2, nhiều tác giả đã phân tích sự tương đồng giữa biểu đồ lớp UML với OWL tại các nghiên cứu [37]
[38] [19] [13] [21] [39] [40] [41] [22] Luận án kế thừa những phân tích đó để thực hiện trích xuất cấu trúc OWL sang biểu đồ lớp UML Luận án phân tích trên cả hai cấu trúc OWL1 và OWL2 để tổng quát hóa các quy tắc chuyển đổi
Trong OWL, có hai cấu trúc khác nhau có thể được sử dụng để định nghĩa một lớp Cấu trúc đầu tiên được sử dụng để định nghĩa một lớp là owl:class Cấu trúc thứ hai được dùng để định nghĩa một lớp (hoặc lớp con) là rdfs:subClassOf Vì thế có thể chuyển đổi thành lớp Employee trong biểu đồ lớp UML
Quy tắc OWL11 Lớp hoặc lớp con C khai báo bằng cú pháp owl:class hoặc rdfs:subClassOf được chuyển đổi thành lớp U(C) trong biểu đồ lớp UML
Thuộc tính trong UML có thể có nhiều mức độ phạm vi sử dụng khác nhau, mô tả thuộc tính đó có thể được truy xuất từ các lớp khác Với OWL, thuộc tính dữ liệu không hỗ trợ phạm vi truy xuất, vì vậy, chuyển đổi thuộc tính trong OWL sang UML có phạm vi sử dụng mặc định là Private OWL không có kiểu dữ liệu định nghĩa trước, cũng không cung cấp cách thức định nghĩa đặc biệt, do đó OWL cho phép việc sử dụng các kiểu dữ liệu của biểu đồ XML và rdf literals Ví dụ sau cho thấy một thuộc tính kiểu dữ liệu sử dụng rdf literal
Do thuộc tính kiểu dữ liệu là kiểu dữ liệu đơn, vì vậy tương ứng với thuộc tính trong biểu đồ lớp UML Luận án phát biểu quy tắc trích xuất thuộc tính như sau:
Quy tắc OWL12 Thuộc tính kiểu dữ liệu dpC có miền là lớp C và kiểu dữ liệu nguyên thủy trong OWL2 được chuyển đổi thành thuộc tính U(dpC) của lớp U(C), có kiểu dữ liệu tương ứng trong UML
4.2.2.1 Trích xuất thuộc tính khóa
Trong OWL1, không có khái niệm về khóa, nhưng trong OWL2, một tập hợp các thuộc tính có thể được gán là khóa bằng cách sử dụng cú pháp owl:hasKey
Ví dụ 4.11 Ví dụ một thuộc tính khóa được mô tả trong OWL2 như sau:
1
Quy tắc trích xuất thuộc tính khóa như sau:
Quy tắc OWL13 Thuộc tính kiểu dữ liệu đơn keyC có miền là C và phạm vi là kiểu dữ liệu nguyên thủy trong OWL được khai báo bằng cú pháp owl:hasKey, thì chuyển đổi thành thuộc tính U(keyC) của lớp U(C), có ràng buộc OCL là duy nhất (unique) và thiết lập kiểu dữ liệu tương ứng trong UML
4.2.2.2 Trích xuất thuộc tính có cấu trúc
Trong OWL, một thuộc tính kiểu dữ liệu có thể có các thuộc tính con được biểu diễn bằng cú pháp rdfs:subPropertyOf, các thuộc tính con này đóng vai trò như các thuộc tính thành phần của một thuộc tính có cấu trúc Vì vậy luận án phát biểu quy tắc chuyển đổi như sau:
Quy tắc OWL14 Trong OWL, thuộc tính kiểu dữ liệu sub_dpC được khai báo bằng cú pháp