《數據庫設計入門經典》，現在學習的是這本書，雖然以前就看過類似的書，可能由於之前經驗不足，書中說的某些東西只消化了一部分，現在重溫一邊好懂多了。所以說讀第一遍讀不懂不要緊，過個一年半載的再來讀，還是會讀不懂的，哈哈。

就是這本了。

第一章 數據庫建模的過去與現在

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

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

聯機事務處理（Online Transaction Processing，OLTP）數據庫通常是專門的、高並發性的（可共享的）體系結構，它需要快速訪問非常少量的數據。

文件系統

層次結構數據庫模型

網絡數據庫模型

關系數據庫模型

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

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

數據庫的類型：

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

決策支持系統（Decision support system，DSS）：數據倉庫數據庫一般不靈活，因為它們可能極其龐大

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

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

數據庫的設計非常重要，因為根據數據庫模型設計編寫的所有應用程序都是完全與底層數據庫的結構相關的。如果必須在後面的階段中修改數據庫模型，則可能必須修改基於該數據庫模型構造的所有內容，也可能需要完全重寫。

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

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

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

還有一些小的要點：

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

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

為任何必須的修改操作提供適當的性能

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

未來增長必須總是要認真考慮的事項——一些數據庫可能以無法估量的速度增長。

數據庫設計的方法

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

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

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

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

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

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

這些單獨的步驟是可互換的、可重復的、叠代的、並且是真正能夠做任何事情的。

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

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