Làm thế nào tôi nên mô hình hóa một mối quan hệ hoặc / hoặc?

Giả sử tôi có một thực thể có tên Phần mềm và hai loại phụ FreeSoftware và NonFreeSoftware. Thực thể NonFreeSoftware có các thuộc tính như ngày mua, nhà cung cấp, v.v. Thực thể FreeSoftware có các thuộc tính như giấy phép, url mã nguồn, v.v.

Vậy nếu tôi muốn mô hình hóa một thực thể khác, OperationsSystem, tôi nên làm thế nào? Có mối quan hệ "là" với Phần mềm nhưng có mối quan hệ "hoặc / hoặc" với FreeSoftware và NonFreeSoftware.

Tôi nghĩ rằng tôi đang thiếu một cái gì đó theo cách tôi đang phân tích thứ bậc này.

database-design subtypes

— jl6
nguồn

Xem lại câu trả lời này . Nó bao gồm các chi tiết thực hiện mô hình hóa loại mối quan hệ này.

— Nick Chammas

Câu trả lời:

Cách để quản lý điều này là các loại phụ của bạn phải được xác định bởi siêu loại (tức là PK của loại phụ cũng là một FK từ loại phụ sang loại siêu.)

Thách thức là hiểu được một cái gì đó có thực sự loại trừ lẫn nhau hay không. Các thuộc tính của loại phụ chỉ nên áp dụng cho các loại phụ đó, nhưng cũng có thể một số loại phụ là loại trừ lẫn nhau và một số loại không.

Nếu bạn có một số loại phụ loại trừ lẫn nhau, thì bạn có thể sử dụng thuộc tính phân vùng trên siêu loại để chỉ ra loại phụ nào (hai hoặc nhiều) loại phụ áp dụng lẫn nhau. Thuộc tính phân vùng này có thể được sử dụng với các ràng buộc hoặc kích hoạt để thực thi tính độc quyền lẫn nhau.

Nếu bạn có các loại phụ không loại trừ lẫn nhau, thì chúng có thể tồn tại mà không cần sử dụng bất kỳ thuộc tính phân vùng nào.

Xem xét mô hình dữ liệu này:

ERD

Bạn có ba loại siêu, nhưng loại FREE_SOFTWAREvà NON-FREE_SOFTWAREloại trừ lẫn nhau, dựa trên SOFTWARE.free_not_freethuộc tính phân vùng cờ. Bất kỳ phần mềm nhất định nào cũng có khả năng là một OPERATING_SYSTEM, bất kể nó có miễn phí hay không.

— Joel Brown
nguồn

Hơi OT: bạn đã sử dụng gì để tạo sơ đồ ER này?

— Daniel Serodio

@DanielSerodio - Tôi đã sử dụng Visio với các hình dạng thông minh do tôi tự xây dựng dựa trên ký hiệu ERD của James Martin. Các hình dạng sử dụng kết cấu đường tùy chỉnh để tạo cho chúng một diện mạo không chính thức, điều mà tôi thấy hữu ích trong việc nhắc nhở mọi người khi sơ đồ là một "bản phác thảo" hoặc thiết kế phác thảo.

— Joel Brown

@JoelBrown Bạn có sẵn sàng chia sẻ giấy nến của mình không? Đây là những hình dạng thực sự đẹp

— imoatama

@imoatama - Đã được một thời gian, nhưng cuối cùng tôi cũng có ý định đăng stprint ở đây: moosewarevisioerd.codeplex.com Lưu ý như trong mô tả rằng hình dạng thông minh của stprint được xây dựng cho phiên bản cũ của Visio và một số hành vi của hình dạng kết nối mối quan hệ có thể là một chút flakey. Một ngày nào đó tôi sẽ đi xung quanh để sửa lỗi này.

— Joel Brown

Tại sao OperationsSystem là một thực thể hoàn toàn mới? Nó phải thuộc Phần mềm một, vì đó là những gì nó là. Và một HĐH (nếu nguồn đóng) sẽ có ngày mua, nhà cung cấp, v.v. Và HĐH nguồn mở sẽ có giấy phép, URL mã nguồn, v.v.

Tôi muốn giới thiệu một mối quan hệ với một SoftwareTypehoặc một cái gì đó dọc theo những dòng đó. Đó là khi bạn có thể / nên chỉ định xem Phần mềm là HĐH hay ứng dụng hay bất kỳ loại phần mềm nào khác mà bạn hỗ trợ.

— Thomas Stringer
nguồn

Tôi muốn OperationsSystem là một thực thể riêng biệt vì nó là một chuyên ngành của Phần mềm. Nó có thể có các thuộc tính mà không Phần mềm nào khác sẽ có (như loại nhân, cờ RTOS hoặc không, cờ nhiều người dùng, v.v.).

— jl6

@ jl6 Tôi vẫn xin khác ở đây. Mỗi phần mềm (có thể là HĐH hay không) sẽ có các thuộc tính cụ thể. Những người có thể được lưu trữ ở nơi khác. Bạn đang giảm thiểu khả năng mở rộng bằng cách tách rời HĐH.

— Thomas Stringer

Nếu tôi hiểu chính xác, bạn đang đề xuất một thực thể Phần mềm và thực thể SoftwareType. Có phải bạn đang nói Free, NonFree và OperationsSystem chỉ là các phiên bản khác nhau của SoftwareType? Tôi chắc chắn bạn đã đúng, nhưng sau đó bạn lưu trữ các thuộc tính khác nhau của các loại khác nhau ở đâu?

— jl6