判斷關係所屬正規化時，需要先找到候選關鍵字：沒有在fd右邊出現的屬性必定是候選關鍵字的一部分，如果找不到，則進行列舉，尋找閉包
沒有非主屬性，一定是第三正規化
用於表達資料庫的設計的方式包括：e-r圖、uml、odl
相似抽象物件的集合為實體集
實體集與屬性相關聯，屬於實體的特性
兩個或多個實體集之間存在聯絡
e-r圖用於表示實體集、屬性和聯絡。在圖中，使用矩形來表示實體，橢圓表示屬性，菱形表示聯絡。使用邊來連線實體與屬性/實體和聯絡
e-r圖示例如圖1所示：
圖1圖中共有stars、movies和studios三個實體，每個實體都有各自的屬性，而stars與movies之間具有聯絡stars-in，studios與movies之間具有聯絡owns
一對一關係（one-one）：如果e到f和f到e都是多對一關係，則r是一對一關係
多對多關係（many-many）：如果e到f和f到e都不是多對一關係，則r是多對多關係
e-r圖中，箭頭表示「最多乙個」（多對一），例如圖2表示的是一對一關係：
圖2圖3則表示了每個star和movie的簽約只能屬於乙個studio：
圖3在實體集和聯絡的連線上進行標記，為聯絡的職能（roles）
例如，在圖4中，movies實體集中的實體movie可以是另乙個實體movie的續集，也可以是另乙個實體movie的前作：
圖4有時候，屬性會不在實體集上，而是在實體集間聯絡上，這樣的屬性的值函式依賴於與此聯絡相關聯的實體集。然而，實際上，把屬性連在聯絡上並不是必須的，可以通過新增乙個實體集來避免這一點。
如圖5所示，左圖的聯絡contracts上的「薪水」屬性，可以轉換為右圖中的salaries實體集，並使其帶有salary屬性：
連線實體集（connecting entity set）：實體被看做是多路聯絡的聯絡集的元組
例如對圖5的e-r圖進行修改得到的圖6就是二路聯絡：
圖6實體集的子類與實體集連線時，使用isa關係標記：
子類可以有自己特有的屬性
實體集及其屬性應反應出現實
避免在將e-r圖轉換成乙個關係時，出現事實的重複
避免更新異常
避免在設計中加入比必要元素更多的元素，從而避免程式變得更複雜，更浪費空間以及更容易犯錯
每個實體集都必須有乙個鍵，鍵在e-r圖中使用下劃線表示，如圖7：
圖7用圓箭頭表示乙個聯絡是否被期望在乙個或多個方向上支援引用完整性，在圖8中，movies中的每乙個movie都必須存在於studios中，同樣地，每乙個president也必須存在於studios中：
圖8在e-r圖的邊上新增約束，表明限制了乙個實體與其他實體相連線的數量，圖9表示，乙個movie最多不能與超過10個stars進行關聯：
圖9如果乙個實體集的部分或全部的鍵由另乙個實體集構成，那麼這個實體集稱作弱實體集
弱實體集使用雙邊矩形表示，而相應的支援聯絡則使用雙邊菱形表示：
支援聯絡：e是弱實體集，從e到其他實體集的多對一聯絡連線的鍵屬性，這些多對一聯絡稱為e的支援聯絡(supporting relationships)，從e到達的實體集稱為支援實體集（supporting entity set)
將實體集轉換為關係，其屬性就是實體集的屬性
用關係替換聯絡，其屬性為與聯絡相關的實體集的鍵，以及聯絡本身的屬性
如果有乙個聯絡r，使得e和f滿足多對一關係，則聯絡r中的f的鍵可以被e的鍵函式決定。因此，在此時，可以將e和r結合為乙個關係，它包含e的所有屬性，f的鍵，以及r的全部屬性
如果在e-r圖**現了弱實體集，則弱實體集w的關係必須不僅包括w本身的屬性，還要包括支援實體集的鍵
同時，對於所有弱實體集w出現的聯絡，必將自己的所有鍵屬性作為w的鍵（包括其他屬性集給w的鍵）
支援w的支援聯絡r，不需要轉換為關係
綜上所述，弱依賴集w的關係包括：
1、w的所有屬性
2、w的支援聯絡的所有屬性
3、對於每個與w有關的支援聯絡e的所有鍵屬性
每個實體集建立乙個關係。如果實體集**是層次中的根，則為了能夠區別元組表示的實體，關係e要包含根的鍵屬性和e本身屬性。並且，如果e和其他實體集有聯絡，就使用這些鍵屬性識別與此聯絡對應的關係中的e實體。
列舉層次中所有可能的子樹。為每乙個子樹構造乙個可以描述該子樹中實體的關係。這個關係模式含有子樹中所有實體集的所有屬性。
如果允許元組中有null (就像sql中的空值）的話，就可以對乙個實體集層次只建立乙個關係。這個關係包含了層次中所有實體集的所有屬性。乙個實體就表現為關係中的乙個元組。元組中的null表示該實體沒定義的屬性。
uml與e-r的對應關係：
umle-r模型
類實體集
關聯二路聯絡
關聯類聯絡上的屬性
子類isa
聚集多對一關係
組合帶有引用完整性的多對一關係
uml類（pk為主鍵）、關聯與約束：
自關聯、關聯類：
子類、聚集（空心菱形）、組合（實心菱形）：
圖中crews是弱實體集，使用pk方框作為乙個支援組合的錨。其含義是在組合另外一端的支援類的鍵屬性是弱類鍵的一部分，連同弱類的任一屬性被標記為「pk」
uml類圖與e-r圖能夠一一對應，注意符號的表達
從uml轉為關係時，類和關聯各自轉換為關係
基於文字
使用物件導向的術語，來確定資料庫的結構
資料庫系統 學習記錄10
在記錄排好序時，可以在記錄上建立稠密索引 鍵的順序與檔案中的排序順序一致，圖1為稠密索引的舉例 圖1 稠密索引 當索引檔案中指向記錄本身的指標長度遠小於記錄本身長度，以至於可以存入到記憶體時，優勢就會非常明顯 每次查詢只需要使用一次i o操作 使用稠密索引時，無需將索引放入記憶體即可知道檔案是否存在...
資料庫系統 學習資料 更新
首先要提一點，平時我們總愛把資料庫管理系統 dbms 簡稱為資料庫系統，注意兩者是不同的。mysql sql server oracle等這些全是資料庫管理系統，是乙個軟體而已。學習乙個新東西，最好最快的方式就是看到它，去操作它，有了乙個認識後，再進一步深入研究它，介於此，我推薦一下自己的學習方式。...
資料庫系統 學習記錄15 課程完結
事務t的時間戳 ts t 事務t將自己開始的訊息發給排程器的時刻 使用系統clock或維護乙個計數器，都可以對時間戳的生成進行實現 對於每乙個資料庫元素x，都有兩條相關的時間戳以及乙個額外的位 1 rt x 最近一次有事務對x進行讀取的時間戳 2 wt x 最近一次有事務對x進行寫入的時間戳 3 c...