1 概述
關注我不迷路，天天分享一點點，天天進步一點點~算法
1.1 數據的組織形式
曾經的軟件工程書中將軟件等價於代碼加上數據。因而可知代碼和數據是構成軟件的要素。我想用「靜若處子，動若脫兔」來形容數據和代碼會比較形象：數據是記錄對象某時刻點的靜態快照，例如一張表單；而實現業務的代碼即是看不見的一隻手，操做並改變着數據。sql
數據按存儲形式可分爲：文件型，如XML、JSON、Cookie等；數據庫型，如SQL Server、Oracle、Sqlite等；內存型，如Session會話。數據庫
按組織形式可分爲：層次模型，採用樹形結構表示數據與數據間的聯繫，一個節點表明一條記錄，根節點之外的其餘節點有且僅有一個雙親節點；網狀模型，採用網狀結構表示數據與數據間的聯繫，容許一個以上的節點無雙親，一個節點能夠有多個雙親；關係模型，用表結構表達實體集以及實體集之間的聯繫。關係模型與前二者最大的差異是用主碼代替指針導航數據。編程
不難看出不管數據如何組織，不一樣的數據模型都關注兩點：數據以及數據間的聯繫。數據庫設計
1.2 分析案例
爲有效保護耕地，成都市國土資源局決定創建成都市耕地保護基礎數據庫，創建農戶、耕地檔案以增強耕地與補貼基金髮放管理。編程語言
需管理數據有農業家庭戶、家庭戶成員、耕地三類信息。農業家庭戶信息包含戶號、戶類型、戶主姓名、戶主身份證號、戶所屬行政區劃（即權屬代碼）。家庭戶成員信息包括姓名、身份證號、性別、出生日期、年齡、是否爲土地義務人。耕地信息包括地塊編號（權屬代碼加4位自編碼組成）、耕地類型、圖幅編號、圖斑編號、合同面積、實測面積、直補面積、登記年份。編碼
每戶家庭包含一位或多位家庭成員，某位家庭成員僅屬於一戶家庭。每戶家庭擁有一塊或多塊耕地，某塊耕地屬於一戶或多戶家庭。翻譯
2 數據庫設計
2.1 設計內容
數據庫設計屬於系統整體設計和詳細設計中的一項。設計
結合需求調研中用戶提出的數據需求加以分析，在整體設計階段的核心是造成概念模型，主要包括：現有數據梳理與分析、數據庫邏輯結構、命名規則、E-R圖。在詳細設計階段是對整體設計的具體細化，主要包括：數據庫物理結構與存儲方案、表描述和表的屬性清單等。3d
2.2 步驟
在PowerDesigner中提供了多條設計路線、模型的相互轉換（如圖 2‑1所示）供設計人員自由發揮。常見的流程大概有以下兩種：
圖 2‑1 CDM、PDM、OOM的關係
l 設計CDM，再轉換爲PDM，最終生成OOM。
l 設計CDM，轉換爲PDM、OOM，再分別細化。
本文采用第一種流程進行數據庫設計實踐。
3 概念數據模型設計
3.1 找到實體
首先將用戶需求中描述的業務領域內的名詞找出來，若是系統中須要存儲它們的信息或狀態，可能就是咱們要找的業務實體對象。
根據1.2節描述，大體能肯定系統至少有農業家庭戶、家庭戶成員、耕地三個實體。
表 3‑1 系統包含的實體
| 實體名 | 含義 |
|---|---|
| 農業家庭戶（Family） | 存放農業家庭戶信息 用於以戶爲單位查詢戶成員和耕地 |
| 家庭戶成員（Members） | 存放家庭戶成員信息 |
| 耕地（Land） | 存放耕地地塊信息 |
3.2 理清聯繫
找到實體後，根據需求描述和業務理解，將實體之間的聯繫用菱形表示，菱形框內寫明聯繫名，並用無向邊將有關實體鏈接起來，同時在無向邊旁標上聯繫的類型「一對一（1，1）、一對多（1，n）、多對多（m，n）」。
圖 3‑1 實體間聯繫
3.3 造成E-R圖
繪出了實體和聯繫就搭好了E-R圖的骨架，下面將系統中關注實體的屬性追加到各實體上。由於E-R圖是概念設計階段的產物，因此我們無需過多關注數據庫和編程實現的細節因素，以避免丟失了重點。
例如屬性中是否須要實體序號（即Id），複合屬性（如地塊編號）的拆分，派生屬性的處理（如出生日期和性別可由身份證號得出，年齡可由出生日期得出），聽從範式等等均可以放在詳細設計階段。
概念設計階段要作的就是找到系統主要核心實體及其相互聯繫，並原本來本的將實體在系統中須要用到的屬性標示出來。
圖 3‑2 耕地保護系統E-R圖
3.4 E-R圖轉換爲CDM
概念設計階段，E-R圖更多的做爲一張重要的「草圖」。概念設計中須要E-R圖，但常採用概念數據模型來代替。我想多是由於後者徹底繼承了E-R圖全部的要素和精髓，並且能更簡潔的描述屬性、在詳細設計和數據庫生成中沿用上階段成果。
綜上所述，概念設計時可採用E-R圖的思惟方式直接繪製概念數據模型。E-R圖和CDM有關概念對應關係以下：
表 3‑2 E-R圖和CDM有關概念對應關係
| E-R****圖 | 概念數據模型（CDM**）** |
|---|---|
| 實體 | 實體（Entity） |
| 聯繫 | 聯繫（Relationship） |
| 屬性 | 屬性（Attributes） |
| -- | 關聯（Association） |
| 特殊化 | 繼承（Inheriance） |
| -- | 依賴（Link/Extended Dependency） |
設計CDM時，須要注意它與E-R圖在細節上的一些不一樣。其一，屬性都有數據類型、長度、是否非空（Mandatory）設置；其二，實體最好都有主鍵（Primary Indentifier），不然轉換爲PDM時沒法自動建立參照關係（外鍵）；其三，「一對多」聯繫中可能存在的依賴聯繫（標定聯繫）。
爲屬性設置了數據類型，將能惟一標示實體的屬性設爲主鍵，最終造成CDM以下。戶號、地塊編號分別做爲農業家庭戶、耕地實體的主鍵。雖身份證號碼可惟一辨識家庭成員，但考慮可能存在錄入錯誤需更改，便單首創建了自增編號做爲主鍵。
圖 3‑3 耕地保護系統CDM
4 物理數據模型轉換
4.1 CDM生成PDM
當選定了數據庫時，可將已有CDM轉換爲與數據庫對應的PDM，繼而還可由PDM生成SQL腳原本創建數據庫存儲結構。
在詳細設計階段，需結合系統功能實現方式來考慮數據存儲，數據庫設計的重心轉向數據模型的物理實現。如輔助支撐表的創建、派生屬性的處理、索引的創建等等。
打開CDM模型，選擇ToolsàGenerate Physical Data Model命令，選擇目標DBMS點擊肯定便可生成PDM。轉換中其對應關係以下：
表 4‑1 CDM與PDM中對象對應關係
| CDM****中對象 | PDM****中對象 |
|---|---|
| 實體（Entity） | 表（Table） |
| 聯繫（Relationship） | 參照關係、外鍵（Reference） |
| 屬性（Attributes） | 列（Column） |
| 主標示符（Primary Identifier） | 主鍵（Primary Key） |
生成PDM以下圖，因爲農業家庭戶與耕地是「多對多」關係，因此係統自動生成一張新表來記錄該關係。而農業家庭戶與家庭成員是「一對多」關係，系統自動在家庭成員表中追加戶號外鍵。
圖 4‑1 耕地保護系統PDM(1)
4.2 具體問題具體分析
1)冗餘字段的取捨
農業家庭戶表的字段設置雖然符合系統呈現數據的須要，但若是戶主發生變動，咱們須要變動家庭成員表中新戶主爲土地義務人，同時修改農業家庭戶表的戶主信息。若是農業家庭戶表中去掉戶主姓名、身份證號字段，則按戶查詢時需經過戶號關聯家庭成員表，且是土地義務人的記錄中提取戶主姓名、身份證號。
考慮系統查詢操做爲主，編輯戶主信息操做頻率很低，農業家庭戶表保留了戶主姓名、身份證號字段。
2)派生屬性（傳遞依賴）的處理
在家庭成員表中，性別、出生日期字段依賴身份證號碼字段，年齡字段部分依賴於出生日期字段。是否去掉性別、出生日期、年齡字段，在系統代碼實現中提供算法實時提取性別、出生日期和年齡？
稍做分析可知：性別和出生日期是不隨時間改變的，在錄入時就從身份證號碼中提取出來，既是身份證號碼格式檢查的必然須要，也提升了系統讀取記錄時的效率。年齡是今時與出生日期間的差值，隨時間而不一樣，顯示時實時計算最合理，因此刪除年齡字段。
3)複合屬性的處理
在耕地表中，主鍵地塊編號由權屬編碼和4位自編碼組成。權屬編碼即行政區劃代碼，由區縣、鄉鎮、村居委會、組構成18位代碼。各組內從0001開始編4位順序碼，二者組合保證了地塊號惟一。
系統中需實現按權屬編碼的分類彙總，如按組、按村居委會等等。經過地塊編號字段的字符串前綴匹配運行便可實現（如LIKE ‘510108%’），即再也不單獨添加權屬編碼字段。
4)輔助支撐表的創建
從前文中能夠看出耕地、農業家庭戶均按權屬編碼分層管理，但現數據庫設計中卻未考慮權屬編碼的存放。在系統中它常以樹狀結構呈現、遞歸方式讀取記錄，因此在權屬代碼表中需設立父節點序號等字段。
除此以外，戶類型、耕地類型、性別字段值爲了物理存儲方便，均採用一位數字表示。但在系統中呈現時須要翻譯成對應的中文含義，如男女、家庭戶、集體戶等。因爲性別、戶類型枚舉項固定不變，能夠考慮硬編碼到代碼中做爲枚舉類型（Enum Type）；耕地類型枚舉項可能存在變更，能夠數據庫中建表或在XML文件中管理。
5)其餘
若是某家庭戶所擁有地塊減小，則需在戶與耕地關係表中刪除對應記錄。爲了保證操做可逆，系統經常設立Status字段做爲邏輯刪除標示。
圖 4‑2 耕地保護系統PDM(2)
4.3 生成SQL建庫腳本
打開PDM模型，選擇DatabaseàGenerate Database命令，可生成SQL腳本或直接鏈接DBMS建庫。
5 面向對象模型生成
面向對象模型（OOM）是與編程語言密切相關的UML描述模型。它可由CDM、PDM生成類圖，再由OOM生成目標語言代碼。
該部份內容不在數據庫設計討論範疇，在此再也不贅述。
6 小結
6.1 CDM、PDM、類圖有關概念對應關係
表 6‑1 CDM、PDM、類圖有關概念對應關係
| CDM****中對象 | PDM****中對象 | 類圖中對象 |
|---|---|---|
| 實體（Entity） | 表（Table） | 類 |
| 聯繫（Relationship） | 外鍵（Reference） | 類類型字段（變量） |
| 屬性（Attributes） | 列（Column） | 字段（變量） |
| 主標示符（Primary Identifier） | 主鍵（Primary Key） | 字段（變量） |
| 關聯（Association） | 外鍵、關聯表 | 類類型字段（變量） |
| 繼承（Inheriance） | -- | 繼承 |
方法、接口、多態描述了對象的行爲，是系統運行的規則；屬性描述了對象某時點的狀態，是靜態的快照。因爲內存有限、系統也不可能永不中止，因此將對象的狀態值放在數據庫中存儲，系統運行須要時再映射還原成對象。
6.2 生成數據庫設計文檔
PowerDesigner提供了根據CDM、PDM等模型生成數據庫設計文檔的功能，減小了文檔編寫的工做量，生成文檔內容主要包括模型圖、全部列表項等等。選擇ReportàGenerate Report命令，可經過嚮導或已有模板生成文檔。
6.3 聽從範式
數據庫設計是否須要嚴格聽從範式，須要達到第幾範式？這個問題一直困擾着我。最終我獲得的答案是合適就好，我的認爲第三範式能夠做爲數據庫設計的通常參照標準。
7 參考文獻
看了這麼多，休息一會吧。我這裏整理了sql的幾版zl,come on!!!
[1] 陳平、褚華，軟件設計師教程，第2版，清華大學出版社
[2] 趙韶平、徐茂生等，PowerDesigner系統分析與建模，第2版，清華大學出版社
[3]圖中年齡屬性用虛線邊框，只爲突出它是非必須的屬性。後文詳論。
[4]特殊的實體，標示系統某事件引發的實體間聯繫。如家訪對於教師和學生、租借對於顧客、商店和影片。
[5] 對象變量，如object、用戶自定義class。兩個類的聯繫在Hibernate中由對應的hbm.xml定義。
[6]包含值類型（int、float、char、enum、struct等）、引用類型（string）。