1 / 35

Chương 3: Thiết kế mô hình ý niệm bằng ORM

Chương 3: Thiết kế mô hình ý niệm bằng ORM. CSDP step 5: Add mandatory role constraints, and check for logical derivations. CSDP Step 5. CSDP step 5: Add mandatory role constraints, and check for logical derivations. Một số khái niệm.

damia
Download Presentation

Chương 3: Thiết kế mô hình ý niệm bằng ORM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Chương 3: Thiết kế mô hình ý niệm bằng ORM CSDP step 5: Add mandatory role constraints, and check for logical derivations

  2. CSDP Step 5 • CSDP step 5: Add mandatory role constraints, and check for logical derivations BM HTTT - Khoa CNTT - HUI

  3. Một số khái niệm • Type: là 1 tập hợp tất cả các điển hình (instances) có thể có của nó. • Hai loại type: object type và relationship type. • Với mỗi lược đồ, type luôn cố định và không thay đổi. • Tại mỗi thời điểm của DB và với 1 type T được cho thì pop(T) được gọi là phân bố của T (population of T) là tập hợp tất cả các điển hình của T tại thời điểm đó. • Khi DB rỗng thì mỗi type của DB = { } (ký hiệu rỗng) BM HTTT - Khoa CNTT - HUI

  4. Một số khái niệm • Phân bố của role r (population of role r), ký hiệu pop(r): mỗi role của 1 loại fact liên hệ với 1 cột trong bảng fact. • Các giá trị (value) được đưa vào cột sẽ tham chiếu đến các điển hình của object type giữ role đó. BM HTTT - Khoa CNTT - HUI

  5. Một số khái niệm • Với mỗi role r và tại 1 trạng thái nào đó của DB, pop(r)= tập hợp các đối tượng được tham chiếu đến trong cột ứng với r. • Các object được tham chiếu đều là entity không phải là value. BM HTTT - Khoa CNTT - HUI

  6. Ví dụ • Quan hệ tam phân F1 và các role r1, r2, r3 • Lúc đầu bảng phân bố rỗng pop(F1) = {}

  7. Ví dụ 1 • pop(rl) = {US, JP}, • pop(r2) = {G, S, B} • pop(r3) = {1 }. • Phân bố của role được dùng để xác định phân bố của object type. • Đối tương pop(Country) thay đổi từ { } thành {US, JP}, pop(CountryCode) từ { } thành {'US', 'JP' } BM HTTT - Khoa CNTT - HUI

  8. Các role trong reference type được gọi là referential roles. • Các role trong elementary fact type được gọi là "fact roles". • Mỗi loại entity trong 1 sơ đồ ý niệm hoàn chỉnh thường giữ ít nhất 1 referential role và ít nhất một fact role. BM HTTT - Khoa CNTT - HUI

  9. The population of an entity type equals the union of the population of its roles. Unless the entity type is independent, its population is the union of the populations of its fact roles. • Phân bố của một loại entity bằng với hợp (union) các phân bố các role của nó. • Nếu loại entity không phải là loại độc lập thì phân bố của nó là hợp các phân bố của fact role của nó. BM HTTT - Khoa CNTT - HUI

  10. Ví dụ 2 • Mỗi instance trong phân bố của thực thể sẽ đóng role rl, r2, hay cả hai. Vì vậy phân bố hiện hành của Country sẽ là tập hợp tất cả điển hình được tham chiếu đến hoặc cột r1 hoặc cột r2

  11. Ví dụ BM HTTT - Khoa CNTT - HUI

  12. Role bắt buộc và tùy ý(Mandatory and Optional Role) • Role được gọi là mandatory (hay còn được gọi là total role) nếu và chỉ nếu, đối với mọi trạng thái (state) của DB, role đều được dùng bởi mọi thành viên của phân bố. • Ngược lại thì được gọi là role tùy chọn BM HTTT - Khoa CNTT - HUI

  13. Ví dụ • Giả sử bảng phân bố mẫu là có nghĩa • Trong 4 role của hình trên role nào là bắt buộc, role nào là tùy chọn?? BM HTTT - Khoa CNTT - HUI

  14. Nếu lược đồ bao gồm tất cả các loại fact của miền nghiệp vụ thì bảng phân bố mẫu của nó có ý nghĩa  dễ dàng xác định được role bắt buộc. • Hầu như ta chỉ làm việc trên các lược đồ con, và phân bố mẫu ít khi có ý nghĩa, nên tham khảo ý kiến chuyên gia nghiệp vụ (domain expert ) để xác định thông tin nào cần phải ghi nhận cho tất cả điển hình của 1 loại đối tượng nào đó (ví dụ có cần phải lưu trữ lại tên của mọi bệnh nhân hay không?) BM HTTT - Khoa CNTT - HUI

  15. Ví dụ • Có 2 role liên quan đến thực thể Patient • pop(Patient) = {001,002, 003 }, trong đó role “having a name” được ghi nhận cho mọi bệnh nhân, role “having a phone number” thì chỉ có ở 1 số bệnh nhân. • Giả sử phân bố mẫu có nghĩa thì role “name” là bắt buộc, role “phone number” là tùy chọn. BM HTTT - Khoa CNTT - HUI

  16. Để chỉ ra role bắt buộc, thêm chấm “mandatory role” vào đường thẳng nối role với loại đối tượng. BM HTTT - Khoa CNTT - HUI

  17. Nếu thêm 1 điển hình bệnh nhân vào role bắt buộc Patient thì cũng phải đưa điển hình này vào phân bố của mỗi role bắt buộc khác của đối tượng patient.  Ràng buộc của role bắt buộc có thề ảnh hưởng bên ngoài vị từ của nó. Trong khi đó, UC chỉ ảnh hưởng nội bộ bên trong vị từ, không ảnh hưởng gì đến các vị từ bên ngoài khác. BM HTTT - Khoa CNTT - HUI

  18. Ký hiệu role bắt buộc trong lược đồ sẽ làm lược đồ thêm phức tạp, có thể bỏ qua những role bắt buộc trong thế giới thật nhưng không thật sự cần thiết trong mô hình (ý nghĩa nghiệp vụ) BM HTTT - Khoa CNTT - HUI

  19. Ví dụ • Hãy vẽ lược đồ ý niệm dựa vào các mẫu báo cáo của câu lạc bộ thể thao sau: BM HTTT - Khoa CNTT - HUI

  20. Ví dụ • Với các UC như sau: each member coaches at most one team, plays for at most one team, was born on at most one date, joined the club on at most one date, and each team has at most one coach and scored at most one total. BM HTTT - Khoa CNTT - HUI

  21. Ví dụ • Có 3 role bắt buộc: một trên Team và 2 trên Member. BM HTTT - Khoa CNTT - HUI

  22. Ví dụ • Có 1 role bắt buộc được khoanh tròn nối 2 role với nhau được gọi là disjunctive mandatory role ( hay inclusive-or constraint) dùng để chỉ “the disjunction of these two roles is mandatory for Member. That is, each member either coaches or plays (or both)” • Không có ràng buộc inclusive-or ngang qua các role "is coached by" và "includes" của thực thể Team để chỉ rắng có thề biết về 1 đội(team) mà không cần biết về coach và bất kỳ player nào của đội đó. BM HTTT - Khoa CNTT - HUI

  23. Inclusive-or constraint • The role disjunction is mandatory

  24. Ví dụ 2 • Total score = Test score + Exam score  Đây là 1 loại fact suy diễn (derived fact type), được ký hiệu dấu * nên kèm theo các ràng buộc BM HTTT - Khoa CNTT - HUI

  25. Ví dụ 2 BM HTTT - Khoa CNTT - HUI

  26. Các sơ đồ tham chiếu(Reference schemes) • Mỗi entity được xác định bằng cách liên hệ nó với 1 giá trị cụ thể nào đó. • Ví dụ một country có thể được tham chiếu bằng 1 code nào đó chẳng hạn Australia có thể được tham chiếu bởi mô tả "The Country that has CountryCode 'AU'“ • Ký hiệu cho sơ đồ tham chiếu: • Đặt sơ đồ tham chiếu trong ngoặc đơn Country(.code). • Hay dùng giá trị tường minh BM HTTT - Khoa CNTT - HUI

  27. Ví dụ 3 • Hãy tạo lược đồ ý niệm cho bảng báo cáo trên BM HTTT - Khoa CNTT - HUI

  28. Ví dụ: dùng sơ đồ tham chiếu theo cách 1 BM HTTT - Khoa CNTT - HUI

  29. Ví dụ: dùng sơ đồ tham chiếu theo cách 2 BM HTTT - Khoa CNTT - HUI

  30. Các loại sơ đồ tham chiếu • Sơ đồ tham chiếu đơn 1:1 (simple 1:1 reference scheme ): nếu chỉ dùng 1 giá trị để xác định • Ví dụ: City(Name) • Sơ đồ tham chiếu phức (compound reference scheme) nếu cần nhiều hơn 2 giá trị để xác định. BM HTTT - Khoa CNTT - HUI

  31. Ví dụ sơ đồ tham chiếu phức • Bên trong 1 folder nào đó để xác định file chỉ cần dùng tên cục bộ như "flag.vsd". • Nhưng nếu cùng tên file trong nhiều folder thì phải kết hợp cả tên folder và tên file cục bộ để chỉ file đang nói đến. BM HTTT - Khoa CNTT - HUI

  32. Ví dụ sơ đồ tham chiếu phức • Để chỉ File có sơ đồ tham chiếu phức, dùng ký hiệu thanh ngang được khoanh tròn BM HTTT - Khoa CNTT - HUI

  33. Case Study- A Compact Disc Retailer • Miền nghiệp vụ liên quan đến người bán lẻ đĩa CD. Anh ta sử dụng HTTT để giúp anh ta quản lý tiền bạc và kho, ngoài việc hỗ trợ 1 dịch vụ đặc biệt giúp khách hàng dò tìm thông tin về bài hát và nhạc sĩ. • Mỗi đĩa (disc) chứa nhiều mục(musical items) được gọi là "tracks". BM HTTT - Khoa CNTT - HUI

  34. BM HTTT - Khoa CNTT - HUI

  35. Each compact disc has a CD number as its preferred identifier. Although not shown • here, different discs may have the same name. Note that "CD" is used here in a genetic • sense, like a catalog stock item or car model. The retailer may have many copies of • CD 654321-2 in stock, but for our purposes these are all treated as the same CD. In • some applications (e.g., car sales) you do need to distinguish between different copies • of the same model, but for our application this is not a requirement. • An artist is a person or a group of persons. For a given CD, a main artist is listed if • and only if most of the tracks on the disc are by this artist (this constraint is enforced • by a data entry operator, not by the system). Assuming that each artist has an • identifying name, we use the fact type: C0mpactDisc(CDNr) has main- Artist(.name). If this • were not the case, we must replace Artist by ArtistName thus: C0mpactDisc(CDNr) has • ArtistName0. The record company that releases the disc must be recorded. BM HTTT - Khoa CNTT - HUI

More Related