資料庫概述
一、背景
原本想直接進行Mysq的總結，然後簡單整理後，發現還是需要進行一個上層抽象概述的。
資料庫概述，不僅僅針對Mysql，而是面向所有資料庫的一種概述性論述。
廣義的資料庫包括sqlLite、SqlServer、Oracle，甚至Redis、HDFS等。
原本想好好打磨打磨，但是由於最近組織關係調整，暫時無心整理這個。所以，先放出來啦。對部分細節感興趣的小夥伴，可以私聊或者艾特我。
二、架構
資料庫有多種劃分方式，其中最出名的，也是大家接觸最多的，是ANSI/ SPARC 資料庫系統研究組 在1975年提出的三層劃分法。又被成為 ANSI-SPARC Architecture。
自我拆解&彙總
1.模式
上述結構圖，將資料庫拆分為三層。而這三層分別對應者不同的模式、檢視（我更喜歡稱之為視角）、資料庫級別。
模式和資料庫級別，談論起來比較偏向概念，這裡不再深入。這裡結合實際，談談檢視。
a.內部檢視
這個內部，是針對系統而言的。
內部檢視，主要是針對系統內部，關注點在於物理檔案。不過，在實際落地時，DBMS往往關注點在邏輯層面的系統檔案。其更多是通過系統API，對系統抽象出的檔案資源進行操作。
b.DBA檢視
DBA檢視，很明顯是針對各位資料庫的DBA們。關注點在資料庫的基礎表。
這裡的基礎表，是指我們在履行DBA職責時（實際開發時，開發者往往會作為DBA建立新表等）建立的Table。
這裡談一下我的認識，分散式資料庫（如分庫分表）下的物理表，也歸屬於基礎表。但分散式資料庫下的邏輯表，並不歸屬於基礎表。原因，後面談。
c.使用者檢視
使用者檢視，則是針對後端應用。關注點在於檢視View。
如果嚴格按照規範來說，現在絕大多數情況下，我們們都是沒有這一層的。就拿Mysql來說，大部分開發都是直連資料庫基本表，而不會建立一個聚合的檢視View，來進行訪問&連線。之所以拋棄檢視View，原因就類似於網路OSI架構，落地後成為TCP五層架構（層次架構的優缺點）。
而在分散式資料庫情況下，我認為其邏輯表，完全可以等同於規範中的使用者檢視層。因為核心是一致的，都是基於基礎表的虛表，可以有效隨著業務需求進行變化。當然，比起規範中的使用者檢視，還是缺少資料聚合的能力、許可權控制等能力，但這個其實是可以擴充套件&實現。
2.對映
多個層次的結構，帶來視角的不同。而視角的不同，則意味著不同層次對同一事物的觀察角度不同。
那麼在不同層次間，則需要一個轉化與對映。
舉個例子，外模式（使用者檢視）的使用者資訊檢視View，是概念模式（DBA檢視）的使用者基礎表&地址基礎表聚合而來。而概念模式（DBA檢視）的使用者基礎表&地址基礎表聚合，在內模式（內部檢視）其實是兩個不同的檔案（邏輯/物理）。雖然在不同模式中，這是三個不同的東西。但究其本質，三者是同一個東西。
a.概念模式-內模式
概念模式-內模式對映，主要是針對內部檢視-DBA檢視。關注點在於基本表與系統檔案的對映。
舉個例子，在Mysql中，這個對映則是由各大儲存引擎負責，如InnoDB、MyIsam等。
這個部分，也決定了具體DBMS的效能。具體實現，我會在後續的InnoDB引擎部分，進行具體的闡述。
b.外模式-概念模式
外模式-概念模式，主要是針對使用者檢視-DBA檢視。關注點在於檢視View與基本表的對映。
舉個例子，Mysql中的檢視View。但實際情況下，大家都是對mysql的基礎表進行操作的。
而分散式資料庫中，尤其是Proxy型別中，個人理解這個對映就是後端應用與Mysql中間的DB-Proxy。如Mycat、TDDL等。
至於類似shardingJDBC這樣的分散式資料庫實現，個人接觸不多，所以對它的定位思考還不夠，這裡就不誤導大家了。
3.小結
上述例子，大多是基於Mysql的。既然Redis、HDFS也歸屬於廣義的資料庫。那麼，Redis、HDFS應當也是符合上述定義的。
這裡以Redis為例，Redis同樣有著分片等叢集方式，以及實際記憶體檔案，這就有了三層模式與兩層對映的基礎。前者是外模式-概念模式的對映，後者是概念模式-內模式的對映。當然這裡可能沒有DBA，但也有著Redis對應的運維管理人員，這個角色常常有開發者擔任。
資料庫概述，在概念上，是位於Mysql、SqlLite、Redis、HDFS上的一個抽象定義。這個抽象定義，使得我們有效把握這些資料庫實現的表現骨架。其一方面可以幫助我們更好地把握現有資料庫實現，另一方面可以幫助我們更好認識這些資料庫實現的差異與方向。
前者比較好理解，這裡就後者舉個例子。我們可以通過知識遷移，思考Mycat這樣的db-proxy的方向。比如是否可以新增資料聚合、許可權等能力。另外，mysql的物化檢視，是否可以借鑑到Mycat上。Redis是否可以構建類似Mycat這樣的proxy，怎麼構建。
這樣一說，頓時感覺這樣更高一層的抽象概念實在有點厲害。畢竟“降維打擊”可是更高抽象的重要作用。而最為重要的是，這樣的認識是一種更高層次的認識。更高層次的認識，往往更接近底層，更加純粹，也更加穩定。
當然，光有抽象理論，那也是無法帶來直接價值的。所以需要我們從理論中，來到實踐，最後再走回理論。從而避免泛泛而談。
三、資料模型
1.基礎（結構）資料模型
a.概述
DBMS的分類方式有很多種，而其中最重要的是資料模型。目前主流採用的資料模型，依舊是關係型資料模型。不過近些年，大量NoSql的出現，也使得鍵值型資料模型、物件導向型資料模型更多市場應用。
分類：
- 層次型資料模型
- 關係型資料模型
- 網狀資料模型
- 鍵值型資料模型
- 物件導向型資料模型
- 等等
基本資料模型是按照計算機系統的觀點來對資料和資訊建模，主要用於 DBMS 的實現。
基本資料模型是資料庫系統的核心和基礎。基本資料模型通常由資料結構、資料操作和完整
PS：有關不同資料模型的簡介，可見系統架構師教程（第四版）-3.2.2資料模型。
b.組成
基礎資料模型的組成：
- 資料結構
- 資料操作
- 完整性約束
部分組成。其中資料結構是對系統靜態特性的描述，資料操作是對系統動態特性的
描述，完整性約束是一組完整性規則的集合。
這裡簡單舉例，解釋一下完整性約束。如關係型DBMS的主鍵非空要求，就是完整性約束規則之一。文章後續，會有更為完善的闡述。
2.概念資料模型
a.概述
概念資料模型是按照使用者的觀點來對資料和資訊建模，主要用於資料庫設計。概念模型
主要用實體聯絡方法（Entity Relationship Approach）表示，所以也稱ER模型。
實體-關係模型（ER模型）：Entity-Relation模型
b.ER圖
ER圖由屬性、實體、聯絡組成。
屬性是實體具備的特性，如姓名、聯絡電話等。
實體是概念上可以區分的事物，如部門、公司、商品等。
聯絡是實體間的關聯關係，如屬於（集合間關係）、下單（業務關係）等。
c.模型轉換
雖然ER模型，很好地刻畫了系統持久化資料的實體（包含核心屬性）&聯絡，但經常是無法直接通過ER圖進行資料庫表設計的。
舉個例子，
轉換方式
- 屬性：轉換時，每個屬性就是一個欄位
- 實體：每個實體都單獨轉換為一個關係模式
- 聯絡
- 1:1聯絡：與任意端實體，進行合併
- 1:n聯絡
- 可轉單獨的關係模式
- 可與N端實體合併（N端實體新增聯絡的主鍵）
- m:n聯絡：必須轉換為單獨的關係模式
轉換流程
- 消除冗餘
關係模式
關係模型用表格結構表達實體集，用外來鍵表示實體間的聯絡。其優點有：
1）建立在嚴格的數學概念基礎上
2）概念（關係）單一，結構簡單、清晰，使用者易懂易用
3）存取路徑對使用者透明，從而資料獨立性、安全性好，簡化資料庫開發工作。
PS：注意ER模型的轉換 -> 進行關係模式的推導
3.構建過程
- 需求分析
- 抽象資料
- 設計區域性E-R模型
- 合併區域性模型，消除衝突
- 重構優化，消除冗餘
- 邏輯設計
其中，2～5稱為概念結構設計
整合方法：
- 多個區域性E-R圖一次集
- 用累加的方式一次整合兩個區域性E-R
整合產生的衝突，以及解決辦法：
- 屬性衝突：包括屬性域衝突和屬性取值衝突
- 命名衝突：包括同名異義和異名同義
- 結構衝突：包括同一物件在不同應用中具有不同的抽象，以及同一實體在不同區域性E-R圖中所包含的屬性簽名（屬性個數&排序）不完全相同
四、關係代數
關係代數，分為並、交、差、笛卡爾積、投影、選擇、連線、除八種。
詳見關係代數運算，這裡不再贅述。
五、規範化理論
1.價值
非規範化可能導致的問題：
- 資料冗餘
- 更新異常
- 插入異常
- 刪除異常
2.函式依賴
關係模式：R(A, B, C)
a.部分（函式）依賴
A -> C，AB -> C
C可以有AB推導，也可以由AB的子集A推導，這就表示存在部分依賴。
如果先弄清楚，最好是參照《架構師教程》進行畫圖。
這裡，為了表達的簡潔，我直接使用推導，而不是依賴關係的表達。
b.傳遞（函式）依賴
A -> B，B -> C
A可以推匯出B，B可以推匯出C，也就意味著A可以推匯出C。這就表示存在傳遞依賴。
3.鍵
關鍵鍵 -> 超鍵 -> 候選鍵 -> 主鍵 -> 外來鍵
4.正規化
a.第一正規化
第一正規化（1NF）是指資料庫表的每一列(即每個屬性)都是不可分割的基本資料項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。簡而言之，第一正規化就是無重複的列。
一個關係模式R的所有屬性都是不可分的基本資料項。
b.第二正規化
第二正規化（2NF）是在第一正規化（1NF）的基礎上建立起來的，即滿足第二正規化（2NF）必須先滿足第一正規化（1NF）。第二正規化（2NF）要求資料庫表中的每個例項或行必須可以被唯一地區分。
滿足第一正規化，然後消除部分依賴。
c.第三正規化
滿足第三正規化（3NF）必須先滿足第二正規化（2NF）。在滿足第二正規化的基礎上，切不存在傳遞函式依賴，那麼就是第三正規化。
滿足第二正規化，消除傳遞依賴。
d.BC正規化
BCNF 在第三正規化的基礎上，資料庫表中如果不存在任何欄位對任一候選關鍵欄位的傳遞函式依賴則符合第三正規化。
（1）所有非主屬性對每一個碼都是完全函式依賴；
（2）所有的主屬性對於每一個不包含它的碼，也是完全函式依賴；
（3）沒有任何屬性完全函式依賴於非碼的任意一個組合。
e.反規範化
雖然違反正規化，但是可以帶來效能等優勢
- 增加派生性冗餘列：生日 -> 年齡
- 增加冗餘列：學號 -> 姓名
- 重新組表
- 分割表：邏輯表下的物理表是按照欄位進行分割的
f.無損分解
為了進行冗餘的消除等，我們常常需要對關係模式進行分解。
而如果分解過程中，不存在依賴關係對丟失，則稱為無損分解。
PS：簡單說，分解後對關係模式，可以倒推回原有的關係模式。
六、併發控制
1.基本概念
（圖：）
2.存在的問題
- 更新丟失
- 不可重複度
- 幻讀（讀”髒“資料）
3.封鎖協議
- 一級封鎖協議
- 二級封鎖協議
- 三級封鎖協議
- 二段鎖協議
共享鎖（讀鎖-S鎖）
排他鎖（寫鎖-X鎖）
七、應用
1.常見DBMS
mysql
2.非常規DBMS
Redis
3.分散式資料庫
（圖：）
分佈透明性
- 分片透明性
- 位置透明性
- 區域性資料模型透明性
分散式DBMS-組成
- LDBMS
- GDBMS
- 全域性資料字典
- 通訊管理（CM）
資料庫分割槽（分庫&分表）
4.大資料
b.聯邦資料庫
支援異構資料的聯合
c.資料倉儲
d.資料探勘
5.Nosql、記憶體資料庫、圖資料庫、物件資料庫等
八、完整性約束
1.設計完整性約束
- 實體完整性約束（主鍵的唯一性&非空性）
- 參照完整性約束（外來鍵：要能查到）
- 自定義完整性約束性（自定義年齡：0-150）
2.安全完整性約束
- 使用者標識&鑑定
- 存取控制
- 密碼儲存&傳輸
- 檢視的保護
- 審計：日誌&分析
3.資料備份
分類：
- 冷&熱
- 冷備份
- 熱備份
- 備份資料
- 完全備份
- 差量備份
- 增量備份
- 餘量備份
- 日誌檔案（機制：先寫日誌，再運算元據庫）
常見備份規劃
如一週：全、增、增、差、增、差、增
4.資料庫故障&恢復
可以預先避免，也可以通過冗餘等方式避免單點問題。
- 事務本身的可預期故障（本身邏輯）：rollback
- 事務本身的不可預期故障（違反儲存保護）：DBMS的恢復模組（日誌，進行修改）
- 系統故障（系統停止運轉）：使用檢查點法
- 介質故障（外存被破壞）：通過日誌，重做業務
最後，願與諸君共進步。