數據庫概述
一、背景
原本想直接進行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的恢復模塊（日志，進行修改）
- 系統故障（系統停止運轉）：使用檢查點法
- 介質故障（外存被破壞）：通過日志，重做業務
最后，願與諸君共進步。