轉換ER圖向關係模型

我知道如何將實體集，關係等，轉換成關係模型，但讓我感到奇怪的是，我們應該做些什麼時，給出一個完整的圖？我們如何轉換它？我們是否爲每個關係和每個實體集創建一個單獨的表？例如，如果我們給出下面的ER圖：轉換ER圖向關係模型

enter image description here

我對這個解決方案是這樣的：

//this part includes the purchaser relationship and policies entity set 

CREATE TABLE Policies (
    policyid INTEGER, 
    cost REAL, 
    ssn CHAR(11) NOT NULL, 
    PRIMARY KEY (policyid). 
    FOREIGN KEY (ssn) REFERENCES Employees, 
    ON DELETE CASCADE) 


//this part includes the dependents weak entity set and beneficiary relationship 

CREATE TABLE Dependents (
    pname CHAR(20), 
    age INTEGER, 
    policyid INTEGER, 
    PRIMARY KEY (pname, policyid). 
    FOREIGN KEY (policyid) REFERENCES Policies, 
    ON DELETE CASCADE) 


//This part includes Employees entity set 

CREATE TABLE Employees(
    ssn Char(11), 
    name char (20), 
    lot INTEGER, 
    PRIMARY KEY (ssn))

我的問題是：

1)Is my conversion true? 
2)What are the steps for converting a complete diagram into relational model. 
Here are the steps that i follow, is it true? 
    -I first look whether there are any weak entities or key constraints. If there 
    are one of them, then i create a single table for this entity set and the related   
    relationship. (Dependents with beneficiary, and policies with purchaser in my case) 
    -I create a separate table for the entity sets, which do not have any participation 
    or key constraints. (Employees in my case) 
    -If there are relationships with no constraints, I create separate table for them. 
    -So, in conclusion, every relationship and entity set in the diagram are included 
    in a table.

如果我步驟是不正確的或有缺少的東西，請你能寫出轉換的步驟？另外，如果只有關係的參與約束，但沒有關鍵約束，我們該怎麼辦？我們是否再次爲相關的實體集和關係創建單個表？

我感謝所有幫助，我是新來的數據庫，並努力學習這種轉換。

謝謝

來源

2013-04-08 yrazlik

不要讓SSN成爲員工的主鍵！他們重新使用〜死後6個月。他們也可以在特定的情況下（例如獲得公民權）改變某個特定的人。 – 2013-04-08 22:33:40

@PieterGeerkens，但爲什麼？在ER圖中，ssn被認爲是員工的關鍵？ – yrazlik 2013-04-08 22:36:07

另外，認識到物理模型中的主鍵約束不是概念設計中主鍵約束的精確實現。PM中的PK是（a）更新記錄的物理表示的手段;和（b）相關表格有效地驗證物理記錄的存在並附於其上的句柄。作爲物理模型的一個主要目標是效率，使得PM中的PM短是一個重要的設計標準;它在概念設計中是無關緊要的。 – 2013-04-08 22:42:24

嗨@bigO我認爲這是肯定地說，您的轉換是真實的，並且已經採取的步驟是正確的。然而從實施的角度來看，可能還有改進的餘地。你已經實現的是比物理模型更多的邏輯模型

通常的做法是將一個代理實例標識符添加到物理表中，這是大多數持久性引擎的一般要求，正如@Pieter指出的那樣Geerkens，艾滋病數據庫效率。實例ID（例如EmployeeId（INT）的值將由數據庫在插入時自動生成。這也有助於@Pieter Geerkens與SSN指出的問題。將Id添加爲所有表格的第一列，我遵循表格名稱的約定。將當前的主鍵轉換爲輔助鍵（自然鍵）。

添加IDS則使我們有必要實行DependentPolicy交集表

DependentPolicyId, (PK) 
PolicyId, 
DependentId

那麼你可能需要考慮，什麼是從屬表的自然鍵。

我注意到你有年齡屬性，你應該考慮這個年齡在創建策略的時間或相關的實際年齡，我應該使用出生日期，這種情況下，無論是。

你可以考慮其他的裝飾件的創建和修改日期。

我也普遍青睞使用單數的表，即員工不是僱員。

歡迎數據建模和設計的世界。

來源

2013-04-20 23:09:41 MikeAinOz

轉換ER圖向關係模型

回答

相關問題