《數據庫設計入門經典》讀書筆記——第一章：數據庫建模的過去與如今

《數據庫設計入門經典》，如今學習的是這本書，雖然之前就看過相似的書，可能因爲以前經驗不足，書中說的某些東西只消化了一部分，如今重溫一邊好懂多了。因此說讀第一遍讀不懂沒關係，過個一年半載的再來讀，仍是會讀不懂的，哈哈。

就是這本了。

第一章 數據庫建模的過去與如今

數據庫模型和數據庫之間有什麼區別？

數據庫將服務於某類型的應用程序。不一樣類型的數據庫模型支持不一樣類型的應用程序。

聯機事務處理（Online Transaction Processing，OLTP）數據庫一般是專門的、高併發性的（可共享的）體系結構，它須要快速訪問很是少許的數據。

文件系統

層次結構數據庫模型

網絡數據庫模型

關係數據庫模型

對象數據庫模型：相比於關係數據庫模型，對象數據庫模型能夠解決一些更加難以理解的複雜問題，好比消除了類型和多對多關係替換表的需求。對象數據庫模型的另外一個優勢是管理和迎合很是複雜的應用程序和數據庫模型的內在能力。這是由於對象方法學的基本原則：很是複雜的元素能夠分解爲最基本的部分，容許對這些基本部分進行顯式訪問和執行這些基本部分。在書中介紹關係型數據庫模型時討論對象數據庫模型很是重要，由於許多現代的應用程序都是使用以對象方法學爲基礎的SDK（例如java）編寫的。對象編程應用程序和關係數據之間一個最重要的關鍵點是：兩種結構化類型（對象和關係）之間的映射過程的性能。

在檢索多個數據項的時候，對象數據庫模型的執行性能比較差。另外一個方面，關係型數據最適合檢索數據組，但也能夠有效地訪問惟一的數據項。

 

數據庫的類型：

事務的：對數據庫進行少許改動（小型事務）

決策支持系統（Decision support system，DSS）：數據倉庫數據庫通常不靈活，由於它們可能極其龐大

混合的：對中小型公司是更爲合適的選擇，由於僅僅有一個而不是兩個數據庫，更少的機器，更少的軟件許可，更少的人

 

對於數據庫模型，必須在構建以前設計它，而後開始用數據填充它，而且將它關聯到應用程序。

 

數據庫的設計很是重要，由於根據數據庫模型設計編寫的全部應用程序都是徹底與底層數據庫的結構相關的。若是必須在後面的階段中修改數據庫模型，則可能必須修改基於該數據庫模型構造的全部內容，也可能須要徹底重寫。

 

具備良好結構的數據庫目標——具備良好結構的數據庫模型是簡單的、易於閱讀的、而且易於理解的數據庫模型。

數據完整性——完整性是數據庫模型中的一組規則，用於確保數據庫中的數據不會丟失。

支持有計劃的查詢以及ad-hoc或無計劃的查詢——ad-hoc查詢越少，固然越好。在某些環境中（例如在很是高併發性的OLTP數據庫中）可能必須徹底禁止ad-hoc查詢，或者轉移到更適當的數據倉庫平臺。

 

還有一些小的要點：

ad-hoc查詢可能形成嚴重的性能問題。須要毫秒響應時間的面向客戶的應用程序不會與ad-hoc查詢很好的相處。

支持業務目標——高度規範化的表結構不必定直接表明業務結構，非規範化的、數據倉庫的、事實-緯度的結構可能更適合於操做性業務。

爲任何須須的修改操做提供適當的性能

數據庫模型中的每一個表應該更適合表明某個題目或主題——不要過多地設計數據庫模型，不要建立太多的表。OLTP數據庫可能由於更多的細節和更多的表而變得龐大；將數據分到太多的表中，數據倉庫可能崩潰。

將來增加必須老是要認真考慮的事項——一些數據庫可能以沒法估量的速度增加。

 

數據庫設計的方法

如何着手設計數據庫模型？

需求分析——收集以下相關信息：數據的性質、必需的特性和任何特別的需求，例如指望的輸出響應。

概念設計——開始使用圖形工具繪製漂亮的圖形：實體關係圖（ERD）。這個步驟包括建立表、表中字段以及表之間的關係。這個步驟也包括了規範化。

邏輯設計——建立數據庫語言命令以生成表定義。

物理設計——調整數據庫語言命令以針對表的底層物理屬性修改數據庫模型。

調整階段——這個步驟包括了多項，例如適當地創建索引、進一步的規範化、甚至是反規範化、安全特性、以及前面步驟中沒有包括的其餘內容。

這些單獨的步驟是可互換的、可重複的、迭代的、而且是真正可以作任何事情的。

應該堅持的惟一通用事實是：在構建元數據表建立代碼以前應該很好地繪製ERD並構建表，而且在實際實現以前應進行可視的設計。