【系統分析師之路】第十五章 數據庫系統（視頻筆記）
數據庫模式（★★★★）
ER模型（★）
關係代數（★★★）
元祖演算（★）
規範化理論（★★★★★）
併發控制（★）
數據庫完整性約束（★★）
分佈式數據庫（★★★）
數據倉庫與數據挖掘（★★★）
- 數據庫系統概論
- 數據庫模式（★★★★）
數據庫結構是一種典型的分層架構。ODBC，JDBC數據庫中間件：不需要改應用程序。
數據庫的視圖和基本表之間基本表與存儲文件之間分別通過建立外模式到模式，模式到內模式之間的映像，保證數據的邏輯獨立性和物理獨立性。
| 三個層次 | 外模式 | 對應視圖 |
| 概念模式 | 數據庫中的關係表 | |
| 內模式 | 涉及存儲結構，有索引和文件 | |
| 兩層映像 | 概念模式-內模式 | 存儲結構變化，不用修改應用程序 |
| 外模式-概念模式 | 關係表變化，不用修改應用程序 | |
| 兩個獨立性 | 邏輯獨立性 | 數據庫的視圖和基本表之間 |
| 物理獨立性 | 基本表與存儲文件之間 |
數據庫設計：
| 數據庫設計 | 需求分析 | 數據字典，數據流圖，需求說明書 |
| 概念結構設計 | ER模型 | |
| 邏輯結構設計 | 依據轉換規則和規範化理論，它的產出物是關係模式 | |
| 物理設計 | 結合數據庫管理系統，硬件和OS特徵 |
確定系統邊界應在數據庫設計的需求分析階段進行，關係規範化是在數據庫設計的邏輯設計階段進行。
在數據庫邏輯結構的設計中，將ER模型轉換爲關係模型應遵循相關原則。
數據庫概念設計是需要畫ER圖，一般先畫局部的ER圖，再畫總體的ER圖。中間會涉及到合併取消衝突。
設有員工實體Employee（職工號，姓名，性別，年齡，通信地址，家庭成員）其中通信地址記錄了：郵編，省，市，街道信息家庭成員記錄了職工的親屬的姓名，職工實體中的通信地址是一個（複合）屬性；爲了將數據庫模式設計的更合理一些，對於家庭成員屬性（應該將職工的親屬的姓名加上職工號設計成爲一個獨立的實體）
- ER模型（★）
軟件工程出發的話，ER圖來自於需求分析，從數據庫設計角度出發的話，ER圖的建立來自於概念結構設計這個層級。
ER圖集成的方法：
1.多個ER圖一次集成
2.逐步集成，用累加的方式一次集成兩個局部的ER圖。
集成產生衝突及解決方法：
| 屬性衝突 | 包括熟悉域衝突和屬性取值衝突。比如有些ER圖對男女用01存儲，有些用字符串漢字存儲。 |
| 命名衝突 | 包括同名異義和異名同義。 |
| 結構衝突 | 包括同一對象在不同應用中具有不同的抽象，同一實體在不同局部ER圖中所包含的屬性個數和屬性排列次序不完全相同 |
| 比如老師在某些結構中是一張表，在某些結構中是一個字段。 |
ER模型： 學生表（學號，姓名，性別，年齡） 課程（課程號，課程名，任課教師） 選課（學號，課程號，成績）
對於三個不同實體集和它們之間的多對多聯繫，最少可以轉換爲4個關係模式。
多對多必須單獨轉關係模式。1對1和1對多可以不單獨轉關係模式。 一個實體必須轉成一個關係模式。
ER圖中包括三個要素：實體（用矩形框表示，框內標註實體名稱）；屬性（用橢圓形表示，並用連線與實體連接起來）；實體之間的聯繫（用菱形框表示，框內標註聯繫名稱，並用連線將菱形框分別與有關實體相連，並在連線上註明聯繫類型）。
- 關係代數（★★★）
| 並 | S1∪S2 | 合併兩個關係模式並去重複列。 |
| 交 | S1∩S2 | 取S1和S2兩個關係模式都有的部分。 |
| 差 | S1⁻S2 | 在S1中但不在S2中。也就是在S1中去掉S1和S2公共部分。 |
| 笛卡爾積 | S1×S2 | 屬性列個數是S1+S2。記錄的條數是S1記錄條數*S2記錄條數。非常相似於動態規劃中的窮舉法。 |
| 投影 | π3,1(S1) | 是做列的投影。選取關係模式中某些需要的列。它是一種垂直操作。 |
| 選擇 | δ1=4(R) | 是針對行。篩選符合條件的記錄。比如選擇1=4代表的意思是選出第一列和第四列數據相同的內容來。 |
| 自然連接 | R⋈S | 首先找出S1和S2的公共字段，然後根據相同字段做等值連接，同時去掉重複的列。一般用在多表查詢的時候 |
若對關係R(A,B,C,D)和S(C,D,E)進行π1,2,3,4,7(δ3=5^4=6(R×S))運算，則該關係代數表達式與R⋈S是等價的。 在做連接時需要先選擇再投影。
- 規範化理論（★★★★★）
| 函數依賴 | 指定X，一定有唯一的Y與之對應。比如學號可以唯一確定姓名，姓名不可以唯一確定學號 |
| 部分函數依賴 | 某一屬性依賴主鍵中一部分的時候就是部分函數依賴。 |
| 傳遞函數依賴 | A確定B，B確定C，從而A可以確定C。就像學號可以確定系號，系號又可以確定系名，於是學號可以確定系名。 |
| 超鍵 | 唯一標識元祖。它的要求比候選鍵和主鍵更寬鬆。 |
| 候選鍵 | 在超鍵基礎上消除冗餘屬性。比如學號和姓名的組合鍵可以唯一標識元祖，但它有冗餘屬性所以不是候選鍵而是超鍵。 |
| 在有向圖中，從入度爲零的節點出發可以遍歷到所有的結點的話，那麼我們就說這個入度爲零的結點是候選鍵。 | |
| 主鍵 | 學號和身份證號都是候選鍵，任選其一就是主鍵，而學號加身份證號作主鍵是不合適的。 |
| 國家總統候選人有多個，但最後的總統只可能有一個。 | |
| 外鍵 | 是其他關係的主鍵。關係表需要通過連接去判斷，所以外鍵是必須要有的。 |
| 第一範式 | 只包含原子值。屬性都是不可再分的數據項。比如把高級名稱拆分爲教授和副教授就是第一範式的應用。 |
| 第二範式 | 在第一範式的基礎上，每一個非主屬性完全依賴於主鍵。消除非主屬性對候選鍵的部分依賴。 |
| 存在部分依賴會有數據冗餘的問題，還有插入和刪除異常的問題。 | |
| 第三範式 | 消除非主屬性對候選鍵的傳遞依賴 |
| BC範式 | 消除主屬性對候選鍵的部分和傳遞依賴 |
| 每個屬性都不部分依賴於候選鍵也不傳遞依賴於候選鍵，那麼稱R是BC範式 | |
|
R屬於BCNF當且僅當其F中每個依賴的決定因素必定包含R的某個候選碼。 |
|
| 派生屬性 | 單價和數量可以確定總價，這個就是派生屬性的應用。還有出生年月和年齡之間就有派生關係。 |
| 多值屬性 | 一張關係表中家庭成員有多個，它就是多值屬性。 |
規範化理論：求候選鍵：
1.將關係模式的函數依賴關係用“有向圖”的方式表示。
2.找入度爲0的屬性，並以該屬性集合爲起點，嘗試遍歷有向圖，若能正常遍歷圖中所有結點，則該屬性集即爲關係模式的候選鍵。
3.若入度爲0的屬性集不能遍歷圖中所有結點，則需要嘗試性的將一些中間結點（既有入度也有出度的結點）併入入度爲0的屬性集中，直至該集合能遍歷所有結點，集合爲候選鍵。
非規範化的關係模式，可能存在的問題包括：數據冗餘，更新異常，插入異常，刪除異常。
| SNO | SName | DNO | DNAME | LOCATION |
| S01 | 張三 | D01 | 計算機系 | 1號樓 |
| S02 | 李四 | D01 | 計算機系 | 1號樓 |
| S03 | 王五 | D01 | 計算機系 | 1號樓 |
| S04 | 趙六 | D02 | 信息系 | 2號樓 |
※1：這裏的計算機系和幾號樓就有傳遞依賴關係。計算機系一定在一號樓，而信息系一定在二號樓。所以上表並不符合第三範式。
| 貨物類型 | 貨物ID | 貨物名稱 | 注意事項 |
| 瓷碗 | 1 | 白色瓷碗 | 易碎品 |
| 瓷碗 | 2 | 青花瓷碗 | 易碎品 |
| 瓷碗 | 3 | 雕花瓷碗 | 易碎品 |
| 三合板 | 1 | 普通三合板 | 易燃物品，注意防火 |
在該表中主鍵爲（貨物類型，貨物ID），但是注意事項”這一列，僅依賴於一個主鍵中”貨物類型“這一個屬性。第二範式要求每個非主屬性完全依賴於主鍵，而不是僅依賴於其中一部分屬性。所以它不符合第二範式。
BC範式：
例如關係模式STJ（學生，老師，課程）每一個老師只教一門課程，每門課程有若干老師，某一學生選定某門課，就對應一個固定老師。（學生，課程）--》老師；老師--》課程
保持函數依賴的分解：
設數據庫模式p={R1，R2，…Rk}是關係模式R的一個分解，F是R上的函數依賴集，P中每個模式Ri上的FD集是Fi。如果{F1，F2…Fk }與F是等價的，也就是相互邏輯蘊含，那麼稱分解P保持FD。
無損分解：
有關係模式：成績（學號，姓名，課程號，課程名，分數）
函數依賴：學號->姓名，課程號->課程名，(學號, 課程號) ->分數
若將其分解爲：
成績（學號, 課程號, 分數）
學生（學號, 姓名）
課程（課程號, 課程名）
上面的分解就是無損分解。
能夠還原的分解叫做無損分解，同理不能還原的分解叫做有損分解。
無損連接分解：指將一個關係模式分解成若干個關係模式後，通過自然連接和投影等運算仍能還原到原來的關係模式。
ST確定J，而不是T確定J的話，那麼它就滿足BC範式。 單屬性的表一般會帶來有損。
設關係模式R（U，F），其中R上的屬性集U={A，B，C，D，E}，R上的函數依賴集F={A->B,DE->B,CB->E,E->A,B->D}。（CE）爲關係R的候選關鍵字，分解（R1（ABC），R2（DE），R3（ACE））是無損連接，並保持函數依賴。
A B C D E ABC - - - OK（B->D） OK（BC->E） DE OK(E->A) OK(DE->B) × - - ACE - OK(A->B) - OK(A->B->D) - 答：C入度爲0，所以C一定是候選關鍵字。進而BC能夠到E，E能夠到A，A能夠到B，B能夠到D。所以候選鍵BC是成立的。而E可以到AB也可以到D，所以CE也可以構成候選關鍵字。同理CA也是候選關鍵字。
因爲BC和CE都是候選關鍵字，所以ABC和ACE都可以反推回關係模式R。他們兩個是無損的。但是ABC和ACE唯獨缺少了D，而DE剛好補全了這個空缺，而且E能夠推出A和B，通過E可以和ACE這個進行連接。
- 數據倉庫與數據挖掘（★★★）
| OLTP：聯機事務處理過程 | OLAP：聯機處理分析過程 | |
| 用戶 | 操作人員，低層管理人員 | 決策人員，高級管理人員 |
| 功能 | 日常操作處理 | 分析決策 |
| DB設計 | 面向應用 | 面向主題 |
| 數據 | 當前的，最新的細節的，二維的分立的 | 歷史的聚集的，多維集成的，統一的 |
| 存取 | 讀寫數十條數據 | 讀上百條記錄 |
| 工作單位 | 簡單的事務 | 複雜的查詢 |
| 用戶數 | 上千個 | 上百個 |
| DB大小 | 100MB-GB | 100GB-TB |
- 分佈式數據庫（★★★）
大量的數據在網絡上傳輸是不合適的，在此背景下才需要有分佈式數據庫。
由一組數據組成的，這組數據分佈在計算機網絡的不同計算機上，網絡中的每個節點具有獨立處理的能力（成爲場地自治），它可以執行局部應用，同時每個節點也能通過網絡通信子系統執行全局應用，這就是分佈式數據庫的概念。
分佈式數據庫 物理上面是隔離的，邏輯層面上是一個完整的整體的數據庫。 數據都存在局部的數據庫中，通過分佈模式，整合在一起。
水平分片：一張用戶表的數據可能一部分放在北京一部分放在上海。
垂直分片：有些字段放在北京中心，有些字段放在上海。
位置透明性：數據存在哪裏用戶是管不到的。
分片透明性：有沒有分片用戶是感受不到的。
物理分區主要考慮性能效率的問題，而對數據表進行拆分。比如論壇中的帖子按年限進行分別存儲。
- 數據庫完整性約束（★★）
完整性約束一共分爲三種：實體完整性約束，參照完整性約束，用戶自定義完整性約束。實體完整性約束的是主鍵，約束它不能爲空，不能重複；參照完整性是用來約束外鍵的，填入的數據必須是另一個表中的主鍵的內容；比如年齡大於0小於200，就是用戶定義完整性約束。當實體完整性，參照完整性，用戶自定義完整性解決不了的問題，可以使用觸發器來解決。
| 實體完整性 | 約束主鍵 | 關係中的每一個元組對應一個實體。在關係中用主關鍵字來唯一標識一個實體，實體具有獨立性。 |
| 參照完整性 | 約束外鍵 | 用於約定兩個關係之間的聯繫 |
| 用戶定義完整性 | 限定取值區間 | 約束是用戶定義某個具體數據庫所涉及的數據必須滿足的約束條件，是由具體應用環境來決定的。 |
| 觸發器 | 腳本編程 | 用於加強數據的完整性約束和業務規則等。它也是保證數據完整性的一種方法。 |
- 併發控制（★）
| 原子性 | atomicity | 事務要麼全做，要麼全都不做。 |
| 一致性 | Consistency | 使數據庫從一個一致性狀態變到另外一個一致性的狀態。 |
| 隔離性 | Isolation | 一個事務的執行不能被其他事務干擾 |
| 持續性 | durablilty | 一個事務一旦提交，它對數據庫的改變必須是永久的，即便是系統出現了故障 |
DBMS運行的基本工作單位就是事務。事務是用戶定義的一個數據庫操作序列。這些序列要麼全做要麼全部不做，是一個不可分割的工作單位。事務通常以BEGIN TRANSACTION語句開始，以ROLLBACK(事務回滾)或者COMMIT(事務提交)語句結束。事務有以下四個屬性：
| X封鎖 | 寫鎖 | 排他鎖 | 事務T對數據A加上X鎖時,只允許事務T讀取和修改數據A |
| S封鎖 | 讀鎖 | 共享鎖 | 事務T對數據A加上S鎖時,其他事務只能再對數據A加S鎖,而不能加X鎖,直到T釋放A上的S鎖 |
併發產生的問題：丟失更新，讀髒數據，不可重複度。丟失更新：兩個出票點出了同一張票。
| 丟失更新 | 兩個事務T1和T2同時讀入同一數據並修改，T2提交的結果將破壞T1的結果。T1的修改被丟失。 | 對T1加X鎖（寫鎖），那麼T2只能在T1解鎖後讀。 |
| 讀贓數據 | T1修改了某一個數據，T2讀取了同一個數據，T1由於某種原因被撤銷，則T2讀到的數據就是贓數據。 | 修改時加排他鎖，直到事務提交後才釋放，讀取時加共享鎖，讀取完釋放T1讀取數據時加上共享鎖後，不允許任何事物操作該數據，只能讀取 |
| 不可重複讀 | T1讀取某一數據，T2讀取某一數據，並進行修改，T1爲了對讀取值進行校對再讀取時，得到不同結果 | T1加X鎖（讀鎖）後，T2對同一數據加X鎖（寫鎖），這樣T1的鎖解開後，纔可以調用T2。 |
| ①丟失更新 | ②讀髒數據 | ③不可重複讀 | |||
| T1 | T2 | T1 | T2 | T1 | T2 |
| 讀A=10（①加X鎖） | 讀A=20（①加S鎖） | 讀A=20（①加S鎖） | |||
| 讀A=10（③X鎖解除後調用） | A=A+50（②解S鎖） | 讀B=30 | 讀A=20（③加X鎖，S鎖解除才後可加） | ||
| A=A-5寫回 | 寫A=70（③S→X） | 求和AB=50 | A=A+50 | ||
| （②解X鎖） | A=A-8寫回 | （④X→S） | 讀A=70（⑤加S鎖） | 寫A=70 | |
| （⑥S→X） | 讀A=70 | ||||
| ROLLBACK-A(20) | 讀B=30 | ||||
| （⑦解X鎖） | 求和AB=100 | ||||
| 驗算不對（②解鎖） | |||||
| 封鎖協議 | 解釋 | 作用 |
| 一級封鎖協議 | 事務T1在修改A之前必須先對其加X鎖，直到事務結束才釋放 | 可防止丟失修改 |
| 二級封鎖協議 | 在一級封鎖協議加上事務T1在讀取數據A之前先對其加S鎖，讀完後即可釋放S鎖 | 可防止丟失修改 |
| 可防止讀髒數據 | ||
| 三級封鎖協議 | 在一級封鎖協議加上事務T1在讀取數據R之前先對其加S鎖，直到事務結束時才釋放。 | 可防止丟失修改 |
| 可防止讀髒數據 | ||
| 防止數據重複讀 | ||
| 兩段鎖協議 | 可串行化的，可能發生死鎖。 | - |
讀鎖上面加寫鎖是加不上去的。 外鍵允許爲空。 能不用鎖就不用鎖，能用讀鎖就儘量不要用寫鎖。鎖的機制類似於操作系統中的PV操作。
- 大數據
| 比較難度 | 傳統數據 | 大數據 |
| 數據量 | GB或TB | PB級或以上 |
| 數據分析需求 | 現有數據的分析和檢測 | 深度分析（關聯分析，迴歸分析） |
| 硬件平臺 | 高端服務器 | 集羣平臺 |
大數據的關鍵特徵就是由量變引起的質變。警察破案的時候往往也是用大數據。像做數據分析來推測嫌疑犯是否是左撇子等，從而縮小嫌疑人的範圍。
大數據處理系統應該具有的重要特徵：
高度可擴展性
高性能
高度容錯
支持異構環境
較短的分析延遲
易用且開放的接口
較低成本
向下兼容性
- 內存數據庫
內存數據庫拋棄了磁盤數據管理的傳統方式，基於全部數據都在內存中重新設計了體系結構，並且在數據緩存，快速算法，並行操作方面也進行了相應的改進，所以數據處理速度比傳統的數據庫的處理速度要快很多，一般都在十倍以上。內存數據庫的最大特點是其“主拷貝”或“工作版本”常駐內存，即活動事務只與實時內存數據庫的內存拷貝打交道。
常見的內存數據庫有：Redis，eXtremeDB，TT，FastDB，SQLite，Microsoft SQL Server Compact，MySQL的MEMORY存儲引擎等。
內存數據庫和NoSQL有重疊的部分。雖然它叫內存數據庫，但它也會定期寫數據到硬盤的。
- NoSQL
隨着互聯網web2.0網站的興起，傳統的關係數據庫在應付web2.0網站，特別是超大規模和高併發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，而非關係型的數據庫則由於其本身的特點得到了非常迅速的發展。NoSQL數據庫的產生就是爲了解決大規模數據集合多重數據種類帶來的挑戰，尤其是大數據應用難題。
SQL+NoSQL=MoreSQL/NewSQL；Redis和MongoDB就支持NoSQL。
關係型數據庫是一種二維表的結構，如果無法用表的形式組織起來的數據，比如文檔類型數據就不適合用關係數據庫。
| 關係數據庫模式 | NoSQL模式 | |
| 併發支持 | 支持併發，但效率低 | 併發性能高 |
| 存儲與查詢 | 關係表方式存儲，SQL查詢 | 海量數據存儲，查詢效率高 |
| 擴展方式 | 向上擴展 | 向外擴展 |
| 索引方式 | B樹，哈希等 | 鍵值索引 |
| 應用領域 | 通用領域 | 特定應用領域 |
向外擴展就是增加機器來跑應用的意思，而向上擴展指的就是升級機器配置。
適用場景和缺點不足：
| NoSQL適用的場景 | NoSQL的缺點不足 | |
| 1 | 數據模型比較簡單 | 成熟度不夠，大量關鍵特徵有待實現 |
| 2 | 需要靈活性更強的IT系統 | 開源數據庫產品的支持力度有限 |
| 3 | 對數據庫性能要求較高 | 數據挖掘與商務智能支持不足， |
| 4 | 不需要高度的數據一致性 | 現有的產品無法直接使用NoSQL |
| 5 | 對於給定key，比較容易映射覆雜值的環境 | 擅長NoSQL的專家較少，大部分都處於學習階段 |
- 數據庫安全
| 措施 | 說明 |
| 用戶標識和鑑定 | 最外層的密碼保護措施，可以使用用戶賬戶，口令及隨機數檢驗等方式。 |
| 存取控制 | 對用戶進行授權，包括操作類型（如查找，插入，刪除，修改）和數據對象（主要是數據範圍）的權限。 |
| 密碼存儲和傳輸 | 對遠程終端信息用密碼傳輸。 |
| 視圖的保護 | 對視圖進行授權 |
| 審計 | 使用一個專用文件或數據庫，自動將用戶對數據庫的所有操作記錄下來 |
- 數據備份
| 備份方式 | 特點 | 優點 | 缺點 |
| 冷備份（靜態備份） | 是將數據庫正常關閉，在停止狀態下將數據庫文件全部備份下來 | 非常快速的備份方法（只需備份文件）；容易歸檔（簡單複製即可），容易恢復到某個時間點上（只需將文件再複製回去），能與歸檔方法相結合，做數據庫“最佳狀態”的恢復，低度維護，高度安全。 | 單獨使用時，只能提供到某一時間點上的恢復；在實施備份的全過程中，數據庫必須要作備份而不能做其他工作，若磁盤空間有限只能複製到磁盤等其他外部存儲設備上，速度會很慢；不能按表或按用戶恢復。 |
| 熱備份（動態備份） | 利用備份軟件，在數據庫正常運行的狀態下，將數據庫中的數據文件備份出來。 | 可在表空間或數據庫文件級備份，備份的時間短，備份時數據庫仍可使用；可達到秒級恢復，可對幾乎所有數據庫實體做恢復，恢復是快速的 | 不能出錯，否則後果嚴重，若熱備份不成功所得結果不可用於時間點的恢復；因難於維護，所有要特別小心，不允許以失敗告終。 |
日誌文件：事務日誌是針對數據庫改變所作的記錄，它可以記錄針對數據庫的任何操作，並將記錄結果保存在獨立的文件中。日誌文件是數據庫備份的重要依據。
數據庫恢復：把數據庫從錯誤狀態恢復到某一個已知的正確狀態的功能，數據恢復的基本原理就是冗餘。建立冗餘的方法有數據備份和登錄日誌文件等。
一般的應用系統也會有數據備份的問題而不僅僅是數據庫。
| 完全備份 | 備份所有數據 |
| 差量備份 | 僅僅備份上一次完全備份之後變化的數據 |
| 增量備份 | 備份上一次備份之後變化的數據 |
增量備份在備份的時候比較容易，但是在恢復的時候比較麻煩，因爲它是針對上次備份而做的備份。差量備份數據針對上一次完全備份的變化而做的備份，這樣不用一個個的去恢復，所以恢復時比較方便且效率高。 不管是哪種備份，都需要使用日誌文件的配合。需要先寫日誌再做數據庫的更新。
數據庫如何恢復：差量備份點+日誌重做，使它恢復到出錯前的狀態。
- 數據庫故障與恢復
| 故障關係 | 故障原因 | 解決方法 |
| 事務本身的可預期故障 | 本身邏輯 | 在程序中預先設置Rollback語句。 |
| 事務本身的不可預期故障 | 算術溢出，違反存儲保護 | 由DBMS的恢復子系統通過日誌，撤銷事務對數據庫的修改，回退到事務初始狀態。 |
| 系統故障 | 系統停止運轉 | 通常使用檢查點法。 |
| 介質故障 | 外存被破壞 | 一般使用日誌重做業務。 |
- 反規範化
由於規範化會使表不斷的拆分，從而導致數據表過多，這樣雖然減少了數據冗餘，提高了增，刪，改的速度，但會增加查詢的工作量。系統需要進行多次連接，才能進行查詢操作，使得系統效率大大下降。反規範化說白了就是以空間換時間。
反規範化的技術手段：增加派生性冗餘列，增加冗餘列，重新組表，分割表。打個比方，出生年月和年齡就是派生性冗餘列。而冗餘列是指某個表中既有學號又有姓名，這樣就不用再連接後進行查詢了。
- 聯邦數據庫
是一個彼此協作卻又相互獨立的成員數據庫的集合，它將成員數據庫系統按不同程序進行集成，對該系統整體提供控制和協同操作的軟件叫做聯邦數據庫管理系統。聯邦數據庫系統只是有公共的接口。聯邦數據庫也是一種中間件的架構。
聯邦數據庫不同於分佈式數據庫，分佈式數據庫在邏輯層看起來是一個數據庫。數據庫聯邦個人理解更加接近於數據集成，集成各個異構的數據庫
- 數據庫優化
索引是一個雙刃劍，它提高了查詢速度的同時，也增加了插入刪除的時間。Select*就會帶來效率上的降低。
數據庫連接池：把對數據庫的連接放入到一個池中，這樣就可以避免頻繁創建和銷燬連接。
分佈式數據庫的優化：還要考慮通信代價的問題。
某公司部門（部門號，部門名，負責人，電話），商品（商品號，商品名，單價，庫存量）和職工（職工號，姓名，住址）三個實體之間的關係如表1-3所示。假設每個部門有一位負責人和一部電話，但有若干名員工；每種商品只能由一個部門負責銷售。部門關係不屬於第三範式的原因是（只消除了非主屬性對碼的部分函數依賴而未消除傳遞函數依賴）。如果用戶要求得到表4所示的結果，需要（修改表3的結構，在表3中增加一個部門號），並增加關係模式（銷售（職工號，商品號，日期，數量））。
部門號 部門名 負責人 電話 001 家電部 E002 1001 002 百貨部 E026 1002 003 食品部 E030 1003
商品號 商品名稱 單價 庫存量 30023 微機 4800 27 30024 打印機 1650 7 30101 毛巾 10 106
職工號 姓名 住址 E001
王軍 南京路 E002 李曉斌 淮海路 E003 楊燁 江西路 E004 田波 西藏路 E005 劉麗華 淮海路
職工號 姓名 部門名 月銷售額 E001
王軍 家電部 528900 E002 李曉斌 家電部 368000 E003 楊燁 百貨部 12500 E005 劉麗華 百貨部 82500 答：