【學習筆記】

一丶概念結構設計
1.首先就是需要了解概念模型分為以下四個特點：
(1)能真實充分地反映現實世界
(2) 易於理解
(3)易於更改
(4)易於向關係、網狀、層次等各種資料模型轉換
2. 接下來就是重點來理解一下E-R模型
E-R模型分為一下三種概念：
（1）兩個實體型之間的聯絡（又可分為一對一聯絡、一對多聯絡、多對多聯絡）
（2）其中就可以拿多個老師與多個學生的例子來進行說明
（3）兩個以上的實體型聯絡（分類同以上相同）
單個實體型內的聯絡
重點就是其中的E-R圖需要了解繪畫的過程和使用一些框架的特定場合。
實體型------------矩形
橢圓形------------屬性
菱形--------------聯絡


3.E-R圖的繪畫由思維導圖和書上的聯絡展示，書上體現為超市進貨等一系列之間的聯絡，


不同之間的都有多種關係，，供應商，專案，零件分別為實體型，貳供應，倉庫為他們之間的聯絡，最後一些供應量，庫存量則視為是屬性！

再詳細瞭解各種框的使用方法才能更好的進行E-R圖的繪製

【思維導圖】

第七章    資料庫設計與E-R模型。

當inst -dept的模式被合併到實體集instructor時，即新增到instructor關係中。

實體關係設計問題

實體集和關係集的概念並不精確，並且可以通過多種不同的方式定義一組實體和它們之間的關係。在本節中，我們將研究E-R資料庫模式設計中的基本問題。第7.10節詳細介紹了設計過程。

7.7.1實體集與屬性的使用。

考慮使用附加phone number的實體設定instructor (圖7.17a)。可以很容易地認為，手機本身就是一個實體，它擁有phone number 和 location;該地點可能是phone所在的辦公室或住宅，手機(手機)可能代表“移動”。“如果我們採用這個觀點，我們就不會將hone number

新增到instructor。”相反,我們建立:

•一個帶有phone number和location屬性的phone實體。

•設定一種inst phone關係，表示instructor和他們的phone之間的聯絡。

此選項如圖7.17b所示。

那麼，instructor的這兩種定義有什麼區別呢?把phones當作一個屬性phone -number，意味著instructor們每個人都有一個phone -number。把phones當作實體電話來處理，可以讓教師有幾個phone -number (包括零)與他們聯絡。

但是，我們可以很容易地將phone -number定義為一個多值屬性，允許每個instructor

使用多個phones。

主要的區別是，把phones當作一個實體更好地模擬一種情況，一個人可能想要保留phones的額外資訊，比如它的位置，或者它的型別(手機，IP電話，或者普通的舊手機)，或者所有的人共享phones。因此，將phones作為一個實體來處理，比將其作為一個屬性來處理更普遍，並且在一般性可能有用的情況下是適當的。

相比之下，處理屬性名（of an instructor)是不合適的。作為一個整體;很難說名字本身就是一個實體(與電話相比)。因此，將名稱作為講師實體集的屬性是合適的。

因此產生了兩個自然的問題:什麼是屬性，什麼是屬性構成的一個實體集呢?不幸的是，沒有簡單的答案。區別在於建模的實際企業的結構，以及與該屬性相關的語義。

一個常見的錯誤是使用實體集的主鍵作為另一個實體集的屬性，而不是使用關係。例如，即使每個instructor只建議一個student，但將學生的ID建模為instructor的屬性是不正確的。relationship advisor是表示student和instructor之間的連線的正確方法，因為它使他們的連線顯式，而不是通過屬性隱式的。

人們有時會犯的另一個相關錯誤是將相關實體集的主鍵屬性指定為關係集的屬性。例如，ID (student的主鍵屬性)和ID(instructor的主鍵)不應該作為關係顧問的屬性出現。這是不應該做的，因為主鍵屬性已經隱含在關係中。

7.7.2 Use ofEntity Sets versus Relationship Sets

    在圖7.15中，我們使用了“take relationship set”來模擬一個學生學習(section of a)課程的情況。另一種選擇是想象每個學生都有一個課程註冊記錄。

然後，我們有一個實體集來表示課程註冊記錄。我們稱這個實體為集合註冊。每個註冊實體都與一個學生和一個部分相關，因此我們有兩個關係集，一個將courseregistration記錄與學生聯絡起來，另一個將課程註冊記錄與部分聯絡起來。在圖7.18中，實體集的部分和學生由圖7.15所示，由一個實體集和兩個關係集取代的關係集:

• 註冊，代表課程註冊記錄的實體集。

• 第二部分，註冊與課程的關係設定。

• student  reg, 與註冊和學生相關的關係。

注意，我們使用雙行表示註冊實體的完全參與。

圖7.15和圖7.18的方法都準確地代表了大學的資訊，但是使用的方式更緊湊，可能更可取。然而，如果登記官辦公室將其他資訊與法庭登記記錄聯絡在一起，最好把它作為一個實體。

確定是否使用實體集或關係集的一個可能的指導原則是，指定一種關係集來描述實體之間發生的操作。這種方法還可以用於判斷某些屬性是否可以更恰當地表示為關係。

7.7.3對n-ary關係集。

資料庫中的關係通常是二進位制的。一些看似非二進位制的關係實際上可以用幾個二進位制關係來表示。例如，一個人可以建立一個三元關係的父母，把一個孩子和他/她的父母聯絡起來。然而，這種關係也可以由兩種二元關係來表示，即父母，將一個孩子與他/她的母親和父親分開。使用這兩種關係，母親和父親為我們提供了孩子母親的記錄，即使我們不知道父親的身份;如果使用三元關係父，則需要一個空值。在這種情況下，使用二進位制關係集更好。

事實上，總是可以用一些不同的二進位制關係集來替換一個非二進位制    (n-ary, for n > 2)關係。為簡單起見，考慮抽象三元關係集R，關聯實體集A、B和c。我們用實體集E替換關係集R，並建立3個關係集，如圖7.19所示:

• RA，關於E和A。

• RB,關於E和B。

• RC, 關於E和C。

 

如果關係集R具有任何屬性，則將這些屬性分配給實體集E;此外，為E建立了一個特殊的標識屬性(因為必須能夠根據其屬性值來區分實體中不同的實體)。對於關係集R中的每一段關係(ai, bi, ci)，我們在實體集合中建立一個新的實體ei，然後，在這三個新的關係集合中，我們插入一段關係如下:

• (ei , ai) in RA.

• (ei , bi) in RB.

• (ei , ci) in RC.

我們可以用簡單的方式將這個過程概括為n-ary關係集。因此，從概念上講，我們可以將E-R模型限制為只包含二進位制關係集。然而，這種限制並不總是可取的。

•為表示關係集建立的實體集可能需要建立一個標識屬性。該屬性與所需的額外關係集一起增加了設計的複雜性，(如我們將看到inSection 7.6)的總體儲存需求。

• n-ary關係集更清楚地顯示了幾個實體參與一段關係。

•可能沒有辦法將三元關係的約束轉化為對二元關係的約束。例如，考慮一個約束，該約束說R是多對一，從a, B到C;也就是說，Aand B中的每一對實體都與最多一個C實體關聯。這個約束不能通過使用關係集RA、RB和RC的基數約束來表示。

 

請考慮在7.2.2節中設定的關係集proj指南，相關的指導老師、學生和專案。我們不能直接將proj指南劃分為教師和專案之間的二元關係，以及教師和學生之間的二元關係。如果我們這樣做,

通過建立如上所述的新實體集，可以將關係集proj指南拆分為二進位制關係。然而，做索道不是很自然的事。

7.7.4 位置的關係屬性

關係的基數比可以影響關係屬性的位置。因此,一對一或一對多關係集的屬性可以被關聯到一個參與的實體集,而不是關係。例如,我們指定顧問是一對多的關係,一個老師可能建議幾個學生,但可以建議每個學生只有一個老師。在這種情況下，屬性日期，它指定當教師成為學生的顧問時，可以與之關聯。學生實體設定，如圖7.20所示。(為了保持圖的簡單性，只顯示了兩個實體集的一些屬性。)因為每個學生實體參與導師的關係最多一個例項,使這個屬性指定具有相同含義aswould放置日期與顧問關係確定。一對多關係的屬性集只能重新定位,以實體集“許多”的關係。對於一對一的關係集，另一方面，關係屬性可以與任何一個參與實體關聯。

在這種情況下，將描述性的屬性放置在關係或實體屬性中的設計決策應該反映出被建模企業的特徵。設計者可以選擇保留日期作為顧問的一個屬性，明確表示日期指的是諮詢關係，而不是學生的大學地位的其他方面(例如，接受大學的日期)。

他選擇的屬性位置對於多對多關係集更加明確。再回到我們的例子之中，讓我們指定一個可能更現實的情況，老師是多對多關係的集合，這是表示老師可以指導一個或多個學生，一個學生可以被一個或多個老師指導。如果我們要表達某個特定的老師成為某一特定學生的老師的日期，那麼日期必須是老師的一個屬性關係集，而不是一個參與其中的任何東西。例如，如果日期是學生的一個屬性，我們就不能確定哪位老師在特定的日期成為了他的指導老師。當一個屬性由參與實體集的組合而不是單獨的實體來決定時，該屬性必須與多對多關係集關聯。同樣，為了保持圖的簡單，只顯示了兩個實體集的一些屬性。