實戰資料庫設計
本書以ER模型設計為主
CH2 資料庫設計概論
P.37
我們把資料庫設計的具體化表示，稱為資料模型。若是以方法論的話，可分為三種作法，分別為ORM模型、ER模型、UML模型。
圖2-6: 資料模型的三種方法論
P.37
ORM(Object Role Modeling, 物件角色模型)
P.38
ER模型(Entity Relationship Model, 實體關係模型)
P.39
UML模型(Unified Modeling Language, 統一塑模語言)
P.40
因為在ER模型中，是看不到資料型別以及條件限制的，必須進一步記錄相關資料表的名稱定義，以及資料行的屬性設定，這部分在系統分析課程中，稱為資料字典(Data Dictionary, DD)。
P.41
複雜資料庫設計會影響效能
兼顧使用者需求與系統效能
P.42
所以，在設計資料庫時，只要記得"資料庫只是存放資料的地方"，避免資料重複存放是為了事後的維護，但應用程式方便撰寫與顧客的需求同等重要，至於實務中孰輕孰重，就留待你設計時自行判斷。
針對所設計的資料庫進行正規化(Normalization)的檢查，目的是希望透過檢查的方式，避免有隱藏的實體沒有被發現，進而衍生可能的資料重複問題。
反正規化(Denormalize)
CH3 使用者需求蒐集
P.48
應用程式開發步驟:
01.進行訪談
02.蒐集顧客需求
03.可行性分析
04.選擇開發技術
05.資料庫設計
06.流程圖與資料字典
07.資料流程圖
08.建置資料庫
09.應用程式實作
10.測試系統
11.驗收系統
12.新需求提出
P.50
進行可行性分析:
需求大致上可分為技術可行性、功能可行性、經濟可行性、法律可行性。
Bear: 在進行可行性分析時，除了判別各種可行性之外，還要進行替代方案的評估。
P.52
資料流程圖(Data Flow Diagram, DFD)
P.55
資料庫的設計步驟
蒐集使用者需求->建立概念模型->建立邏輯資料庫->建立實體資料庫
P.60
區分商業邏輯規則或資料庫設計
在列出精煉的需求後，必須再加以區分，那些是屬於商業邏輯規則，那些則是屬於資料庫設計的範圍。由於資料庫只能儲存資料，一些需要計算或是需要公式才能得出的結果，都必須分類到商業邏輯規則之中。被歸類到商業邏輯規則的需求，不一定會有資料儲存在資料庫端，也許是前端程式抓資料庫的資料，計算好公式(公式寫在應用程式端)，再將結果呈現給使用者。
Bear: Bear這裡的看法和作者不同，Bear覺得公式在實作上應以DB function方式提供外界使用，這樣一來，當規則異動時，在介面沒被異動的大前提下，任何使用此DB function仍然可以正常的運作，完全不必理會運算公式的改變，因為他們是取得結果，不問過程，進而達到封裝運作邏輯的效果。公式寫在前端會造成維護時若公式異動則前端程式要重編譯的維護成本浪費。
CH4 尋找資料庫的實體與屬性
P.71
邏輯資料庫設計一直存在兩種方法論：第一種是將需求轉變成候選實體(Entity)，另一種作法則是將需求轉變成候選屬性(Attribute)，再將候選屬性分群，並將分群的名稱取名為實體。
圖4-2: 先找出候選實體或候選屬性的優、缺點
P.74
何謂"屬性"？屬性是用來描述實體的基本單位，也是被實體所包含的。一個屬性勢必只有一個值，當屬性可能會有多個值所組成時，表示該屬性也可以有多個屬性描述，此時的屬性就會自動昇級成實體。
P.75
圖4-5: 實體與屬性可互換
(實體和屬性的觀念簡易記法)
....[to be continue]....
CH5 實體的關聯與條件附加關係
CH6 資料庫的邏輯設計--實體關聯的正規化
CH7 事後的檢討與修正
CH8 ER-Diagram的製作
