點擊圖片看大圖，加載可能慢些，請您耐心等待....
關係DB（根）
關係數據庫是支持關係模型的數據庫系統。
關係的模型由關係數據的結構，關係操作集合和關係完整性約束的三部分組成。
爲什麼要有關係數據庫。（根）
我認爲這個分層的思想是一樣的道理，是從現實世界到計算機世界的一個過程，關係數據庫就是這個過程的產物，從現實世界到計算機世界是層層抽象的關係。
另一方面，我認爲是爲了提高效率。反證法，如果不使用關係數據庫會有哪些弊端。對於初次接觸數據庫的新手，嘗試維護和管理現實世界的信息孤島會遇到數據訪問的準確性。例如關係的規範化，我們從反面來考慮如果沒有關係的規範化就會出現數據的冗餘、刪除異常、更新異常等。
而關係數據庫在分析數據方面是很強大的，讓我們的數據變得更有意義，可以保證數據的準確性和完整性。
總之，我認爲關係數據庫的學習就是一種指導思想，再過度到sql 數據庫，它就像三層架構中的業務邏輯層吧。
咬文嚼字（枝葉）
1型（Relation Schema）
關係的性質包括以下幾點：
1）列是同質的，即每一列中的分量必須來自同一個域，必須是同類型的數據。
2）不同的列可以來自同一個域，每一列稱爲屬性，不同的屬性必須有不同的名字。
3）列的順序可以任意交換。
4）關係中元組的順序可以任意，在一個關係中可以任意的交換兩行的次序。
5）關係中不允許出現相同的元組。
6）關係中的每一個分量必須是不可再分的的數據項，或者說是所有屬性的值都是原子的，即是一個確定的值。
關係的型就是關係模式，一個關係模式形式是R(U,X,Y)
1.1數據結構
1.1.1 domain
domain域
1.1.2 CartesianProduct
笛卡爾積
1.1.3 Relation
關係
1.2關係的鍵
1.2.1 Candidatekey
能唯一標識關係元組的一個屬性或屬性集，成爲（candidate key）
也就是一個元組中不重複數據的列就可以作爲一個候選鍵。
1.2.2 Primarykey
主鍵，是從候選鍵中的任意的一個組合中選擇一組作爲主鍵。
1.2.3 Foreignkey(Referencing Relation)
外鍵，是一個表相對於另一個表來說的，一個表中的一個主鍵可能是另一個表中的外鍵，由此這兩個表的關係爲參照關係（Referenced Realtion）
1.2.4 PrimeAttribute
主屬性：第一次的關係DB，對於主屬性我的理解是錯誤的，理解主屬性是比主鍵更加抽象的一個層次級別，其實主屬性就是主鍵中的具體的一個列中的屬性，恰恰相反，是主鍵的一個具體。
而非碼主屬性：不包含任何候選鍵中的屬性成爲非碼屬性。
可以這樣的理解，皇帝的幾個兒子都可以被立爲太子，他們都是“候選鍵”，從中選擇任何一個作爲太子，選擇的這個就是“主鍵”，而主屬性就不是太子這個稱號了，而是太子的名字，而非碼屬性就是不是太子的具體的人名。（也許比喻不恰當，請見諒）
1.2.5 Non-PrimeAttirbute
不包含任何候選鍵的中的屬性稱爲非碼屬性。
2 值(型的實例化)
2.1一對1一對多多對多
Float
3 關係的操作
union
intersection
difference
以上三個要求進行運算的兩個關係是相容的
extended cartesian product
selection
projection
join
division（除法運算就是找到與R不同的，之後再去除相同的行，結果就是除法的結果）
4 關係理論
4.1 關係的完整性
entity integrity
referential integrity
user-defined Interity
4.2 關係數據庫爲什麼要規範化
用反證法，如果不規範化，把所有字段都全部放到一張表中的話，就會出現數據的冗餘度會非常的大，數據的刪除異常，插入異常，更新異常的出現。
4.2.1 函數依賴
4.3 規範化的目的和原則
目的: 一個關係只要其分量是不可分的數據項，就可稱爲它的規範化的關係，但是這只是最基本的規範化。規範化的目的是使其結構合理，消除存儲異常，使數據冗餘儘量減小，便於插入、刪除和更新。
原則：關係規範化的原則是“一事一地”原則，即一個關係只是描述一個實體或者實體間的關係。 若對於一對多的關係，就把它分離“分離”出來。
一個關係表示一個實體。
範式（Normal Forms）（First Second Third）
下一篇博文預告：關係數據庫標準語言SQL