Chương 6

Transcript Chương 6

   Cùng mô hình nghiệp vụ (business domain) có thể được mô hình hóa trong nhiều cách khác nhau. Cùng 1 sơ đồ ý niệm có thể ánh xạ thành lược đồ logical theo nhiều cách Cùng 1 lược đồ logical có thể được thực thi theo nhiều cách khác nhau.

 Lược đồ ý niệm với quan hệ 2 ngôi  Hai lược đồ có tương đương nhau không??

• Từ các quan hệ 1 ngôi trong sơ đồ 1 có thể dịch thành các quan hệ 2 ngôi trong sơ đồ 2 Patient smokes iff Patient indulges in Vice 'S' Patient drinks iff Patient indulges in Vice 'D' • Và ngược lại Patient indulges in Vice iff Patient smokes and Vice has ViceCode 'S' or Patient drinks and Vice has ViceCode 'D' 

Tương đương ngữ cảnh (contextual equivalence )

 Tương đương ngữ cảnh vì nó bổ sung ngữ cảnh có tính định nghĩa (definitional context) vào sơ đồ gốc, thừa nhận có "virtual object types" (e.g., Vice tồn tại ngầm định trong lược đồ 1)

  Việc săp xếp lại 1 lược đồ này cho giống với 1 lược đồ khác gọi là phép biến đổi lược đồ ý niệm. Có thể thực hiện nhiều phép biến đổi phức trong ORM mà không cần phải dùng đến các chú thích để hỗ trợ

  Giúp ta phân biệt được sự khác biệt giữa các chọn lựa thiết kế.

Nếu 2 lược đồ được xây dựng độc lập với nhau có thể tích hợp với nhau 1 phần hay hoàn toàn, chỉ cần giải quyết được sự khác nhau trong cách mà mỗi lược đồ dùng để mô hình miền nghiệp vụ.

 Nhờ phép biến đổi lược đồ ý niệm mà có thể thay đổi 1 lược đồ gốc thành 1 lược đồ khác có thể dễ dàng hơn cho việc thực thi. Quá trình biến đổi này được gọi là conceptual schema optimization.

 Từ 2 lược đồ ý niệm trong ví dụ 1, tạo các cấu trúc bảng (table scheme ) và bảng phân bố mẫu tương ứng như sau:

• • • Trong 1 số ứng dụng thì dùng dạng 1 (1 bảng) hiệu quả hơn, không cần phải thực thi phép join khi muốn hiển thị thông tin mọi bệnh nhân. Nhưng nếu các tật nghiện (vice) thường xuyên thay đổi thì giải pháp dùng 2 bảng lại hiệu quả hơn Nếu sau khi tối ưu hóa 1 lược đồ ý niệm khi ánh xạ sang bảng không hiệu quả thì có thể dùng phép denormalization.

• • • Chuyên biệt hóa và khái quát hóa Predicate tương tự như chuyên biệt hóa và khái quát hóa các loại đối tượng, nhưng không cần phải xác định mối liên kết subtype nào giữa các predicate Một predicate có thể được specialized nếu ràng buộc giá trị (value constraint) hay ràng buộc tần số (frequency constraint) là 1 số hữu hạn.

Trong ví dụ drinker-smoker, Vice có ràng buộc giá trị { 'S', 'D' }

• • Vì có chính xác 3 loại huy chương , quan hệ 3 ngôi (ternary) có thề được chuyên biệt hóa thành 3 quan hệ 2 ngôi, mỗi ngôi cho 1 loại huy chương. Khi loại đồi tượng MedalKind được sáp nhập (is absorbed) vào predicate 3 ngôi, nó chia thành( chuyên biệt hóa) thành 3 predicate 2 ngôi.  Phép biến đổi này được gọi là object type absorption.

 Phép biến đổi ngược lại khái quát hóa từ 3 quan hệ nhị phân thành 1 quan hệ tam phân bằng cách rút ra (extracting) loại đối tượng MedalKind  Phép biến đổi này được gọi là object type extraction.

 In general, when an n-valued object type is absorbed into a predicate, the n specialized predicates that result each have one less role than the original (since the object type has been absorbed).

 PSGI: “R có thể được chuyên biệt hóa thành S1 .. Sn bằng cách sáp nhập B”

 ◦ ◦ Các predicate R và S, theo thứ tự, có m + 1 roles và m roles, với m  1. Các loại đối tượng A1 .. Am và B không cần phân biệt. Loại giá trị của B có n giá trị b1 .... bn. Nếu m =1 biến đổi 1 quan hệ hai ngôi (binary) thành n quan hệ 1 ngôi (unary) Nếu m = 2, biến đổi 1 quan hệ 3 ngôi thành n quan hệ nhị phân.

 Phép biến đổi từ trái sang phải chuyên biệt hóa predicate R thành n predicate S1 .. Sn bằng cách sát nhập loại đối tượng B. Phép biến đổi ngược lại từ phải sang trái khái quát hóa các predicate ngắn hơn thành 1 predicate dài hơn bằng cách rút ra B.

• • PSG1 vẫn đúng ngay cả khi có các ràng buộc khác được thêm vào. Tuy nhiên khi bất kỳ 1 ràng buộc nào được bổ sung vào thì phải biến đổi thành 1 ràng buộc phụ tương đương trong lược đồ biến đổi tương ứng. Hệ quả: If a UC in R spans a combination of B's role and other roles, a UC spans the specialization of these other roles in S1 .. Sn; and conversely.

  Các UC trong lược đồ trái tương đương với các ràng buộc loại trừ (exclusion constraint ) trong lược đồ phải.

Exclusion constraint means that no row of values may appear in more than one of the Si fact tables

 UC bên lược đồ trái tương đương với ràng buộc loại trừ (exclusion constraint) bên lược đồ phải.

 If a UC spans all roles of R except for B's role, then S 1 , .. S n , are mutually exclusive; and conversely.

 If A i ’s role (or role disjunction) in R is mandatory, then the disjunction of its specialized roles is mandatory, and conversely (1  i  m).

Ràng buộc bắt buộc (mandatory constraint) trong sơ đồ (a) Ánh xạ thành 1 ràng buộc inclusive-or trong sơ đồ (b).

 If R is a ternary with a UC spanning just B's role and one other role, then adding a frequency constraint of n to this other role is equivalent to adding an equality constraint over the specialized versions of that role.

 If R is a ternary with a UC spanning just B's role and one other role, then adding a mandatory role constraint and frequency constraint of n (the number of possible values for B) to this other role is equivalent to making each specialized version of that role mandatory.

 UC ngoài trong (a) chỉ ra rằng mỗi xe có nhiều nhất một lái xe chính (main driver) và nhiều nhất 1 lái xe dự trữ (backup driver).

   Lược đồ (a) được ánh xạ thành (b) bằng cách sáp nhập loại đối tượng DriverStatus vào predicate “drives”, chuyên biệt hóa thành 2 predicate main driver và backup driver. Phép biến đổi ngược lại khái quát hóa các predicate driver chuyên biệt thành một predicate tổng quát bằng cách rút ra loại đối tượng DriverStatus.

Vì loại đối tượng này xuất hiện trong 1 loại quan hệ khác, không phù hợp với PSG 1.

  "LHS" viết tắt của "left-hand schema" “RHS” viết tắt của "right-hand schema".

 A, B và C tương ứng với Driver, DriverStatus, và Car; Ràng buộc ngang bằng được ngầm định bởi 2 ràng buộc role bắt buộc trên Driver.

  Có thể chuyên biệt hóa sơ đồ ???

Mặc dù không có loại đối tượng DriverStatus nhưng ràng buộc tần số (frequency constraint) cho thấy là each car has at most two drivers  cho phép chuyên biệt hóa thành 2 trường hợp

 Vì việc phân biệt ra 2 trường hợp này không có trong sơ đồ gốc nên phép biến đổi này không tương đương với lược đồ gốc

 Page 708

  ◦ ◦ ◦ ◦ Liên quan đến việc biến đổi 1 lược đồ ý niệm thành 1 lược đồ ý niệm khác mà có thể thực thi hiệu quả hơn. Bốn yếu tố cần xem xét khi tối ưu hóa lược đồ: Target system Query pattern Update pattern Clarity.

   Trước khi tối ưu hóa,lược đồ ý niệm toàn cục phải được hoàn tất và hợp lệ Bất kỳ chọn lựa ánh xạ nào cũng nên khai báo. ◦ ◦ Thủ tục bao gồm hai giai đoạn chính sau: Transform to reduce the number of mapped tables (steps 1 and 2) Transform to simplify individual tables (steps 3-5)

   Quy trình ánh xạ từ lược đồ ý niệm thành lược đồ quan hệ được gọi là

deconceptualization

Ngày nay các nhà thiết kế database thường tạo lược đồ ý niệm trước bằng ORM, ER, hay UML sau đó áp dụng thủ tục ánh xạ để tạo lược đồ quan hệ.

Trước đây khi thiết kế database, thường dùng kỹ thuật

normalization,

chỉnh lược đồ quan hệ. một số người hiện vẫn dùng kỹ thuật này chủ yếu để tinh

  Nếu lược đồ ý niệm là đúng, thì thiết kế bảng bằng Rmap luôn ở dạng chuẩn, vì vậy các nhà mô hình hóa ORM không cần phải dùng đến kỹ thuật chuẩn hóa. Tuy nhiên biết về normalization giúp hợp nhất được hướng thiết kế và tạo điếu kiện để làm việc với những người còn sử dụng phương pháp cũ normalization.

   Có hai kỹ thuật chuẩn hóa: ◦ ◦ Synthesis Decomposition ( hay còn gọi "analysis").

Mỗi kỹ thuật chỉ thực hiện trên các lược đồ quan hệ và tập các phụ thuộc hàm (functional dependencies - FD). Kết quả chuẩn hóa: tập các bảng ở dạng chuẩn (normal form)

   Một bảng không ở dạng chuẩn 1NF thì được gọi là "unnormalized" hay Non-First Normal Form (NFNF = NF 2 ). Một bảng ở dạng chuẩn cao hơn cũng có nghĩa là nó cũng ở các dạng chuẩn thấp hơn Ví dụ: một bảng ở dạng 3NF đương nhiên ở dạng chuẩn 1NF và 2NF

   Dạng chuẩn nào??

◦ Chuẩn NF 2 Repeat attribute : regNr, course, rating Repeat group: Result

 ◦ ◦ Dạng chuẩn nào??

Bảng (a): 2NF Bảng (b): 1NF

 Nếu dựa vào bảng (b), phát biểu các luật cơ bản (elementary facts), rồi xây dựng lược đồ ý niệm và dùng Rmap để có lược đồ quan hệ

 ◦ ◦ Dạng chuẩn nào??

Bảng (a): 3NF Bảng (b) : 2NF

 Lược đồ ý niệm cho hình (b) và lược đồ quan hệ đúng bằng kỹ thuật Rmap

  Một khóa được gọi là khóa sơ cấp nếu có một FD từ nó đến 1 số thuộc tính khác trong bảng. Một thuộc tính được gọi là thuộc tính khóa sơ cấp (elementary key attribute) nếu nó thuộc vào 1 trong các khóa sơ cấp.

  Có 2 khóa sơ cấp là cityNr và (cityName, stateCode) ◦ Bảng thuộc dạng chuẩn nào???

Elementary key normal form (EKNF)

 Một lược đồ bảng ở dạng EKNF nếu và chỉ nếu tất cả các FD của nó đểu bắt đầu từ cả khóa hay kết thúc ở các thuộc tính khóa cơ bản.

 ◦ Bảng ở dạng chuẩn nào? Chuẩn BCNF?

Dạng chuẩn EKNF

  Dùng Rmap để tạo lược đồ quan hệ đúng Bảng ở dạng chuẩn BCNF

 A table T in a database schema with FD set F is said to be in Boyce-Codd normal form (BCNF) when the following property holds. For any functional dependency X → A implied by F that lies in T, where A is a single attribute that is not in X, X must be a superkey for T. A database schema is in BCNF when all the tables it contains are in BCNF.

• Kh ả o sát 1 lư ợ c đ ồ quan h ệ đ ể qu ả n lý l ị ch làm vi ệ c c ủ a nhân viên. M ỗ i nhân viên (employee) làm vi ệ c 1 hay 2 ca (shift) m ỗ i ngày ở Trong m ỗ i ca, nhân viên s ẽ c ử a hàng. M đư ợ ỗ i ca 4 ti c phân làm vi ệ c ế ở ng. b ộ ph ậ n (station) nào đó trong c ử a hàng ( như qu ầ y thâu ngân, kho sách,…) . Ch m ỗ i b ộ ph ậ n trong su ố t ca làm vi ệ c. Lư ợ c đ ồ đư ợ c thi ế t k ế như sau: ỉ có duy nh ấ t 1 nhân viên cho quan h ệ

schedule (employee ID, date, shift, station, worked shift?)

• • • V ớ i quy t ắ c nghi ệ p v ụ (one person per station per shift), có hai khóa d ự tuy ể n cho lư ợ c đ ồ trên là: – – Các FD c ủ a lư ợ c đ ồ – : employee ID + date + shift - > station, worked shift? – employee ID + date + shift date + shift + station date + shift + station - > employee ID, worked shift? Lư ợ c đ ồ thu ộ c chu ẩ n BCNF??

  Kh ả o sát 1 lư ợ c đ ồ quan h ệ sau: movie info ( title , star , producer ) M ộ t phim có th có th ể ể có nhi ề u hơn 1 star, cũng có nhi ề u hơn 1 producer. Cùng 1 star có th ể đóng nhi ề u hơn 1 phim, 1 producer có th ể làm nhi ề u hơn 1 phim.

• • Khóa c ủ a lư ợ c đ ồ bao g ồ m t ấ t c ả các thu ộ c tính  không có thu ộ c tính không khóa  Lư ợ c đ ồ ở d ạ ng chu ẩ n BCNF Tuy nhiên lư (anomalies): – You cannot insert the stars of a movie without knowing at least one producer. – – – – ợ c đ ồ này có các b ấ t thư ờ ng You cannot insert the movie ‘s producer without knowing at least one star. If you delete the only producer from a movie, you lose information about its stars. If you delete the only star from a movie, you lose information about its producers. Each producer ’ s name is duplicated for every star in the movie. By the same token, each star ’ s name is duplicated for each movie producer.

 ◦ ◦ Có ít nh ấ t 2 entity không liên quan gì đ ế n nhau trong quan h ệ này: M ộ t th ự c th ể star c ủ a nó qu ả n lý m ố i quan h ệ M ộ t th ự c th ể qu ả n lý m ố i quan h ệ producers c ủ a nó.

gi ữ a phim và các gi ữ a phim và các  Gây ra b ấ t thư ờ ng

 Đ ị nh nghĩa: Quan h ệ ở d ạ ng chu ẩ n 4NF n ế u nó ơ d ạ ng chu ẩ n BCNF và không có ph ụ thu ộ c đa tr ị (multivalued dependency)

• • Ph ụ thu ộ c đa tr ị x ả y ra khi v ớ i m ỗ i giá tr ị c ủ a thu ộ c tính A, t ồ n t ạ i 1 t ậ p h ữ u h ạ n các giá tr ị c ủ a thu ộ c tính B có liên quan và 1 t ậ p h ữ u h ạ n các giá tr ị đ ế n giá tr ị c ủ a thu ộ c tính C cũng có liên quan c ủ a thu và C đ ộ c l ậ p nhau.

ộ c tính A đó. Thu ộ c tính B V ớ i m ỗ i tiêu đ ề phim (movie title) có 1 nhóm các di ễ n viên (stars) có liên quan đ ế n phim đó. Cũng v ớ i m ỗ i phim có 1 nhóm các đ ạ o di ễ n (producers) c ủ a phim đó. Các di ễ n viên và nhà s ả n xu ấ t phim đ ộ c l ậ p nhau.

   Ký hi ệ u:

title - >> star title - >> producer

Đ ọ c là “title multidetermines star and title multidetermines producer. ” FD là trư ờ ng h ợ p đ ặ c bi ệ t c ủ a ph ụ thu ộ c đa tr ị nhưng thu ộ c tính đư ợ c xác đ ị nh ch ỉ là 1 giá tr ị đơn hơn là 1 nhóm các giá tr ị .

• Đ ể lo ạ i b ỏ ph ụ thu ộ c đa tr ị và chu ẩ n hóa thành d ạ ng chu ẩ n 4NF: phân rã quan h ệ , đ ặ t m ỗ i ph ầ n c ủ a ph ụ thu ộ c vào 1 quan h ệ riêng: movie stars ( title , star ) movie producers ( title , producer )   Có th ể thêm hay xóa các di ễ n viên hay nhà s ả n xu ấ t 1 cách tùy ý mà không b ị ả nh hư ở ng l ẫ n nhau. Tên các di ễ n viên và nhà s ả n xu ấ t ch ỉ hi ệ n 1 l ầ n cho m ỗ i phim xu ấ t