数据库设计系列9--将ER模型映射为表
生活随笔
收集整理的這篇文章主要介紹了
数据库设计系列9--将ER模型映射为表
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
在前面的步驟中,我們創建了數據庫的ER模型,ER模型屬于概念級別的模型,需要映射為表才能被計算機存儲。本章節的目標就是從ER模型中創建表,并檢查這些表的結構。這組表應該代表邏輯數據庫模型中的實體,關系,屬性和約束。然后檢查每個表的結構,確保建表過程中沒有產生錯誤。如果表中有錯誤,則表明在建表的過程中或在ER模型中仍有發現的錯誤。將ER模型映射為表的過程如下所述的步驟: 1.? 創建表。創建表的目標是從從ER模型映射表集合,在這步中,為ER模型創建表來表達實體,關系,屬性和約束,每個標的結構來源于ER所描述的信息,這些信息包括ER圖,數據字典和任何其他相關的文檔。我們使用關系數據庫定義語言DBDL來描述每個表的組成,首先確定表的名字,在后面跟著該表的簡單屬性的名字,并將這些屬性的名字括在括號中,然后標示該表的主鍵以及任何備用鍵和外鍵,對于每個外鍵,還要給出包含被引用主鍵的表。在創建的過程中,需要注意以下的事項: a)?? 如何表達實體,對于模型中的每個實體,創建一個包含實體的所有簡單屬性的表。例如對于復合屬性Address,應該包含它的簡單屬性Street,state,zipcode,如果有可能,標示每個表中的主鍵的列。 ??? ?如何表達關系,一個實體與另一個實體間的關系由主鍵/外鍵機制表達,為了決定將外鍵屬性放在哪里,首先必須標示關系中包含父實體和子實體。不同類型的關系和多值屬性主要有: ?????????????????????? i.? 一對多的二元關系,對每個一對多的二元關系,關系一端的實體被設計為父實體,多端的實體被設計為字實體。為了描述這種關系,父實體主鍵的拷貝被放在字實體的表中。在一對多關系中有一個或者多個屬性的情況下,這些屬性也隨著主鍵加到子表中。 ???????????????????? ii.一對多遞歸關系,一對多遞歸關系和一對多的二元關系很相似,只不過父實體和子實體都是同一個表。 ??????????????????? iii.? 一對一二元關系。一對一的二元關系的表稍微有些復雜。因為不能使用元組的數目來表示一個關系中的父實體和子實體。而是需要使用參與過程來決定把實體結合為一個表來表示關系。考慮如下的參與約束。 1.? 1:1關系的兩邊都是強制參與,在這種情況下,應該將兩個實體合為一個表。并選擇初始實體中的一個主鍵作為新表的主鍵。其他的鍵作為備用鍵。 2.1:1關系的一邊是強制參與,在這種情況下可以使用參與約束來標示1:1關系的父實體和子實體,關系中強制參與的實體被設計為子實體,可選參與的實體被設計為父實體。 3.? 1:1關系的兩邊均為可選參與。這種情況下父實體和子實體之間的設計是任意的。除非你可以得到關于關系的更多信息來幫助你判斷使用那個設計。 b)一對一遞歸關系。對于一對一遞歸關系,應該遵循上面所描述的對1:1關系的參與規則。但是在這種情況下,父實體和子實體是相同的,對于兩邊有強制參與的1:1遞歸關系,應該用主鍵的兩個拷貝,來把這個遞歸關系,描述為一個表,同前面一樣,主鍵的一個拷貝代表外鍵,并且應該將他重命名來表示他代表的關系。 c)?多對多的二元關系,對于每個多對多的二元關系,創建一個表達關系的表,這個表包含關系的任何屬性,我們將參與關系的實體的主鍵屬性拷貝到新表中,使之為外鍵,一個外鍵或全部外鍵將組成新表的主鍵,可能結合此關系的一些屬性。 d)復雜關系類型,有多于兩個參與實體的關系是復雜關系,為每個復雜關系創建一個表達關系的表,將參與復雜關系的這些實體的主鍵復制到新表中,并作為外鍵,此表還包含與關系相關的全部屬性,一個或多個外鍵將組成新表的主鍵,還可以加上關系中的一些其他屬性。 e)?多值屬性,對于每個與實體有關的多值屬性,應該遵守上述1:*關系中所描述的規則,在一端的實體被指定為父實體,在多端的多值屬性被指定為子實體,創建一個新的表包含這些多值屬性,并將父實體的主鍵拷貝過來作為外鍵,除非多值屬性自己本身是父實體的備用鍵,否則,新表的主鍵由多值屬性和父實體的原始主鍵組成。 2.? 用規范化的方法檢查表的結構。這個步驟地目標是檢查和使用規范化標準,使每個表的結構正確。用規范化的方法檢查表可以避免不必要的數據重復。應該確保前面所建立的表至少是第三范式的,如果所標示的表不是第三范式的,可能表明ER模型的某部分是錯誤的。或者由模型創建表的時候產生了錯誤。 3.? 檢查表是否支持用戶事務。這個步驟的目標是取保所產生的表支持用戶所需要的事務。檢查表是否支持事務的一種方法是檢查是否支持事務的數據需求。以確保數據在一個或多個表中存在。同時,如果事務所需要的數據在多個表中,則應該檢查這些表是否能夠通過主鍵外鍵連接起來。 4.? 檢查業務規則。目標是檢查邏輯數據庫設計中表達的業務規則。業務規則適用于防止數據不完整,不準確或者不一致的約束,盡管DBMS在完整性方面的控制可能存在也可能不存在,但這不是問題所在,在這個階段,你只關心高級設計,即確定需要什么樣的數據完整性約束,而不管怎么樣去實現,標示完整性約束之后,就可以得到一個完整而準確的描述視圖的局部邏輯數據模型。如果必要的話,可以從邏輯數據模型產生物理數據庫設計,在為用戶構建系統的原形時,需要考慮如下的一個常見的完整性約束: ?????????????????????? i.需要的數據,即某些列的數據是必須要填寫的。 ???????????????????? ii.列的值域約束,每個列都有一個值域, ??????????????????? iii.實體完整性,實體的主鍵不能為空。 ?????????????????? iv.?多樣性,多樣性表達了數據庫中數據間的關系的約束。比如班級必須有學生,而且必須有班主任, ???????????????????? v.參照完整性。外鍵包含的與父表象匹配的主鍵值。關于主鍵需要注意以下兩點:1。主鍵允許為空嗎?2.如何保證參照的完整性,當向字表中插入數據,刪除數據,更新子表記錄外鍵,向父表中插入數據,從父表刪除數據時,應該進行哪些約束,如No Action,Cascade,set Null,set Defaule,No Check 5.? 與用戶討論邏輯數據庫設計。目標是為了確保局部邏輯數據模型與描述模型的文檔確實表達了用戶視圖。此視圖的邏輯數據庫設計應該已經設計完全,并且全部存檔,但在完成這個步驟之前,應該與用戶一起研究這個設計。
轉載于:https://blog.51cto.com/tianli/58491
與50位技術專家面對面20年技術見證,附贈技術全景圖總結
以上是生活随笔為你收集整理的数据库设计系列9--将ER模型映射为表的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 【原创】修改C#_WinForm设计中两
- 下一篇: 关于ssh 配置文件的参数说明