Database-Design
EER 圖 - 既不分離也不完全重疊的子類
假設我們正在為一家公司的數據庫編寫一個增強的實體關係圖 (EERD)。這家公司提供兩種服務 A 和 B。如果這兩種服務不相交,那麼這可能看起來像:
在許多情況下,您可以向公司請求這兩種服務,在這種情況下,我們將使用“o”而不是“d”。
一個人不能自己請求服務 B。一個人可以根據需要隨時請求服務。但幾乎不可能有人每 10 年左右請求服務超過一次。
假設對於這家公司,您可以同時請求服務 A 和 B,或者隻請求服務A。在圖中簡潔地描述此約束的好方法是什麼?
假設:
- 服務可以是 A 類型或 B 類型。不能兩者兼有。
- 一個請求可以針對 A 類型的服務,也可以針對兩種服務(A 類型之一和 B 類型之一)。
- 一個客戶端可以有很多請求。
我認為一個乾淨的選擇是擁有一個
Service_Request
實體,它與名為的實體相關聯,例如,Client
和Service
. 它將有 2 個屬性,service_a
其中service_b
第二個是可選的。在 SQL 中:CREATE TABLE service_request ( service_request_id INT NOT NULL PRIMARY KEY, client_id INT NOT NULL -- who ordered it REFERENCES client (client_id), request_ordered_at TIMESTAMP NOT NULL, -- when it was ordered -- more details about the request -- (price, duration, etc.) service_a_id INT NOT NULL -- type A service REFERENCES service_a (service_id), -- (mandatory) service_b_id INT NULL -- type B service REFERENCES service_b (service_id) -- (optional) ) ;
設計的其餘部分、實體
Service
和兩個子類型 (Service_A
和Service_B
) 應保持原樣。