[筆記]數據庫系統設計之命名與主鍵選擇

   1.C.J.Date關於分佈式數據庫的12條告誡

• 本地站點的獨立性。每一個本地站點都有一個獨立自主的集中式DBMS，每一個站點都必須保證安全性，併發控制，備份和恢復

• 中心站點。在網絡中的站點都與中心站點或其它站點無關，全部站點具備一樣的功能

• 故障獨立性。節點發生故障不會影響到系統，即一個節點發生故障，系統也能繼續運行

• 位置透明。用戶檢索數據時，不須要知道數據的位置

• 分割透明。數據分割對用戶透明，用戶僅能看到一個邏輯數據庫，用戶檢索數據分割時，不須要知道數據庫分割的名字

• 複製透明。用戶僅看到一個邏輯的數據庫，DBMS透明的選擇數據庫分割，對於用戶來講，DBMS透明的管理因此分割

• 分佈式查詢。查詢可能在不一樣的的DB站中運行，DBMS透明的實行查詢優化

• 分佈式事務管理。一個事務可能在不一樣的站點更新數據，DBMS透明的實行事務管理

• 硬件獨立性。系統必須能夠在任何硬件平臺運行

• 操做系統獨立性。系統必須能夠在任何操做系統平臺上運行

• 網絡獨立性。系統必須能夠在任何網絡平臺上運行

• 數據庫獨立性。系統必須支持任何廠商的產品數據庫

   

   2.數據庫設計策略

     數據庫設計的兩個經典方法是：自頂向下設計，自底向上設計。

     自頂向下設計：先識別數據集，而後對集合定義數據元素，這個過程將經歷實體識別到實體的屬性定義。

     自下向上設計：先定義數據元素項，而後將其組合成數據集，這個過程經歷屬性定義到組合成實體。

    這兩種方式是相互補充的，根據業務場景和開發經驗來作出選擇，一般少許實體，屬性，關聯關係的數據庫時能夠將關注點放在自底向上的方法。若是數據庫更爲複雜，則考慮使用自定向上的方法。

    依我的經歷，卻是不多使用自底向上的方法，不過當數據集較爲龐大的時候或多或少用到該方法的思想，好比先抽取一些屬性，初步組合成一些實體供後續分析使用。

    3.關於數據庫中的命名

    可能較爲嚴格的命名約定會讓人頭疼，甚至爲了一個表或者屬性的名稱簡明思議絞盡腦汁，可是正真作到這樣的約束帶來的好處會讓人成爲命名約定的忠實粉絲。

• 使用描述性的詞語來命名錶，屬性名，管理關係等

• 複合實體命名一般能夠描述所表示的關係

• 避免數據庫系統的關鍵詞做爲命名名稱

• 全部的命名規則作到統一

   4.主碼（數據庫表主鍵）的選擇原則

   

主碼特徵	描述
惟一性	惟一的識別一個實體實例（數據庫表的一條記錄），值不能爲空
非智能（不含具體語義）	無實際語義（如學生學號），含有語義的屬性更適合描述實體特徵
不隨時間變化	好比姓名，婚姻情況，地址，手機號碼等均可能變化，應該選擇永久不變的
最好單屬性	非必須，但最好，單屬性能夠簡化外鍵的實現和應用程序編碼
最好是數值類型	數值類型便於管理，方便數據庫實現計數，自增等功能
安全編碼	不能存在安全風險，如×××號碼做爲住碼則有可能被碰撞檢測到數據