1. 程式人生 > >資料庫系統實現學習筆記二(資料庫關係建模)--by穆晨

資料庫系統實現學習筆記二(資料庫關係建模)--by穆晨

前言

        ER建模環節完成後,需求就被描述成了ER圖。之後,便可根據這個ER圖設計相應的關係表了。

        但從ER圖到具體關係表的建立還需要經過兩個步驟:

  1. 邏輯模型設計:將ER圖對映為邏輯意義上的關係表,不涉及到表中欄位資料型別,索引資訊,觸發器等細節資訊。
  2. 物理模型設計:將ER圖對映為物理意義上的關係表

        本文將詳細介紹ER模型到邏輯關係表的對映是如何完成的。


 

基本概念

        1. 關係(relation)

        關係就是在資料庫中存在的,包含行和列的一張表。也常被稱為關係表,或者表。注意只有在確保不會引起混亂的時候使用最後一種稱呼,因為關係表和一般意義上的表有很大區別。

        2. 列(column)

        列就是字面意義上表的列。但是它也有時被稱作屬性,或者域。

        3. 行(row)

        行就是字面意義上表的行。但是它也有時被稱作元組,或者記錄。

        4. 關係表 VS 一般的表

        關係表有以下幾個基本約束:

                a. 一個列只能有一個名稱,列的名稱不能相同。

                b. 不能出現完全一樣的行,即重複資料。

                c. 表中每個值都必須為單值。

                d. 同一列中的所有值都必須屬於同一個域。

                e. 行/列順序無關

        5. 主碼(primary key)

        每個關係必須要有一個主碼(即主鍵,可含多列),用來唯一標識表中各行記錄。

        6. 實體完整性約束(entity integrity constraint)

        指所有主碼資料必須非空。

        6. 外碼(foreign key)

        外碼(外來鍵)是某關係中的一列,而這一列恰恰又是另一個關係的主碼。

        7. 參照完整性約束(reference integrity constraints)

        外碼取值要麼為空,要麼為其參照關係中的主碼取值。


 

ER模型到關係表的對映

        1. 將常規實體對映為關係

        對常規實體來說,每個常規屬性對應到關係表中的一列,而某單值且唯一的列則對映為主碼,標記下劃線。

        如下實體:

        將對映為關係:


 

        2. 將具有複合屬性的實體對映為關係

        這類對映中,複合屬性的各子屬性會對映到的新的關係中,但是複合屬性名本身不會。

        如下實體:

        將對映為關係:

        雖然關係中沒有出現符合屬性名了,但資料庫上層的前端應用可能會利用到複合屬性名。也就是ER圖在各個階段都有可能用到,不是說對映為關係後就沒啥事了。


 

        3. 將具有唯一複合屬性的實體對映為關係

        這類對映中,將會形成一個複合主碼,其成員為複合屬性的各子屬性。

        如下實體:

        將對映為關係:


 

        4. 將具有可選屬性的實體對映為關係

        這類對映中,需要將可選屬性對應的列標記一個(O)。

        如下實體:

        將對映為關係:


 

        5. 一對多(1:M)聯絡的對映

        這類對映的規則為:在由1:M聯絡中屬於M側的實體所對映得到的關係中設定一個外碼,這個外碼對應於由1側的實體對映得到的關係中的主碼。

        如下ER模型:

 

        將對映為關係:

        注意,外碼命名不一定要和它對應的主碼一致,應根據實際情況決定。


 

        6. 多對多(M:N)聯絡對映

        這類對映的規則為:除了具有多對多聯絡的兩個實體之外,聯絡本身也需要對映為關係。聯絡對應的關係中將有兩個外碼,分別對應兩個實體的主碼,同時這兩個外碼構成新關係的主碼。

        比如下面這個ER模型:

        將對映為關係:


 

        7. 一對一(1:1)聯絡的對映

        這類對映和1:M的很相似。原則上外來鍵設在任何一個實體的關係中都OK,但如果一對一聯絡中的基數約束是強制單個和可選單個這種型別,則最好將外來鍵設定在可選多的一側。因為這樣可以保證關係中不會出現太多空值。

        比如下面這個ER模型:

        將對映為關係:


 

        8. 將具有若干候選碼的實體對映為關係

        這類對映中,主碼依然標記劃線,而非主碼唯一屬性則標記(U)。

        如下實體:

        將對映為關係:


 

        9. 將具有多值屬性的實體對映為關係

        這類對映中,需要為多值屬性建立一個新的關係。新的關係中包含一個外碼,對應到主實體的主碼。同時屬性值和外碼構成新的關係的複合主碼。

        如下實體:

        將對映為關係:


 

        10. 將具有派生屬性的實體對映為關係

        派生屬性不需要做什麼特別處理,那是前端的事情,哈哈。


 

        11. 一對多(1:M)一元聯絡的對映

        這類對映的規則為:實體對映得到的關係中包含一個外碼,對應到關係自身的主碼。

        如下ER模型:

        將對映為關係:

        需要注意的是,該對映中外來鍵名和主鍵名是不同的,以區分它和主碼。事實上關係中也不允許出現名稱相同的兩列。


 

        12. 多對多(M:N)一元聯絡的對映

        這類對映的規則為:除了實體本身需要對映為關係之外,多對多聯絡需要對映為另一個關係。新的關係中將有兩個外碼,它們均對應到實體主碼。且這兩個外碼又組合為新關係的複合主碼。

        如下ER模型:

        將對映為關係:

        這裡同樣要注意外來鍵名要避免和主鍵名重複。


 

        13. 一對一(1:1)一元聯絡的對映

        和上面第11條講的一對多的一元聯絡對映規則完全相同,此處不再舉例說明。


 

        14. 將弱實體對映為關係

        弱實體對映和常規一對多聯絡對映一樣需要在弱實體(M側實體)中建立一個對應到屬主實體(1側實體)的外碼。然而區別是弱實體中的主碼是弱實體自身的部分碼+外碼構成的複合主碼,而後者的主碼僅是M側實體自己的主碼。

        如下ER模型:

        將對映為關係:

        當然,如果聯絡是一對一,則弱實體的主碼就是那個對應到其屬主實體的外碼而沒有部分碼了。

        如下ER模型:

        將對映為關係:


 

        15. 將關聯實體對映為關係

        關聯實體本身就是聯絡,因此它的對映規則和聯絡是一樣的。聯絡的對映在前文已經完成講解,此處不再累述了。


 

        16. 三元聯絡的對映

        這類對映和多對多聯絡的對映比較相似。如下ER模型:

        可對映為:

        這裡提示下,三元聯絡的情況,聯絡肯定是多對多對多的。因為如果這三元中有一個為一,那麼三元聯絡就應轉成兩個二元的一對多聯絡。

 


概念模型 VS 邏輯模型

        概念模型和邏輯模型的區別:

        首先概念模型建模和ER建模,需求視覺化表達的是一個意思。

  資料開發人員繪製ER圖,並和專案各方人員協同需求,達成一致。由於這部分的工作涉及到的人員開發能力比較薄弱,甚至不懂開發,因此ER圖必須清晰明瞭,不能涉及到過多的技術細節。在ER圖繪製完畢之後,才開始將它對映為關係表。這個對映的過程,就叫做邏輯模型建模或者關係建模。

        有人會說,ER圖不是可以直接對映到關係嗎,而且已經有了相應的對映工具了,為什麼還要繪製ER圖多此一舉呢?針對這個問題前文已經回答了。ER圖是拿出去和別人談需求的,要求各方人員都能看得懂。而關係表設計到了過多實現細節,比如:要給多對多聯絡/多值屬性等多建一張表,要設定外碼,各種複合主碼等。這些東西不應該在談需求的時候出現,它們應當對非開發人員透明。而且ER圖中每個屬性只會出現一次,減少了蘊含的資訊量,是更好的交流和文件化工具。

        還有,ER模型所蘊含的資訊,也沒有全部被邏輯模型包含。比如聯絡的自定義基數約束,比如實體的複合屬性,派生屬性,使用者的自定義約束等等。因此ER模型在整個開發流程(如物理模型建模,甚至前端開發中是都會用到的,不能認為ER模型轉換到邏輯模型後就可以扔一邊了。