數據字典

時間 2019-11-20

標籤數據字典简体版

原文原文鏈接

1、數據字典的概念

　　數據字典是一種通用的程序設計方法。能夠認爲，不論什麼程序，都是爲了處理必定的主體，這裏的主體多是人員、商品（超子）、網頁、接口、數據庫表、甚至需求分析等等。當主體有不少的屬性，每種屬性有不少的取值，並且屬性的數量和屬性取值的數量是不斷變化的，特別是當這些數量的變化很快時，就應該考慮引入數據字典的設計方法。html

　　DD（Data dictionary,數據字典）: 是指以特定格式記錄下來的、對系統數據流程圖中各個基本要素（數據流、文件、加工等）的具體內容和特徵所作的完整的定義和說明。它是結構化系統分析的另外一重要工具，是對數據流程圖的重要補充和註釋。算法

　　數據字典最重要的做用是做爲分析階段的工具。任何字典最重要的用途都是供人查詢對不瞭解的條目的解釋，在結構化分析中，數據字典的做用是給數據流圖上每一個成分加以定義和說明。換句話說，數據流圖上全部的成分的定義和解釋的文字集合就是數據字典，並且在數據字典中創建的一組嚴密一致的定義頗有助於改進分析員和用戶的通訊。數據庫

2、數據字典的兩種形式

1）把主體的屬性代碼化放入獨立的表中，不是和主體放在一塊兒，主體中只保留屬性的代碼。這裏屬性的數量是不變的，而屬性取值的數量能夠是變化的。工具

2）用一個表來放結構相同的全部屬性信息，不一樣屬性的不一樣取值統一編碼，用「類型」來區別不一樣的屬性，主體中保留屬性代碼的列表。這樣主體所擁有的屬性數量就是可變的了。post

第二種數據字典比第一種更抽象，層級更高，也更具通常性、通用性。測試

2.1 第一類數據字典

這兩種形式的概括有些抽象，爲說明這兩種數據字典和它們的各類優勢，下面舉個簡單的例子來講明：ui

如今有個需求，要在程序中處理「職員」信息。這裏的主體就是「職員」，開始時「職員」有「國籍」、「證件」和「學歷」等屬性。編碼

好比，對於一個「職員信息」頁面上的「國籍」下拉列表，咱們能夠就用第一種的數據字典來存儲不一樣的國家。若是不採起這樣的方法，就須要手動的把全部可能的國家名稱敲到頁面上。這首先有個效率的問題，每一個須要用到國籍的地方都要敲一次，要敲多久？還有，若是有一天，像南斯拉夫，忽然國家換名了，是否是要全部涉及的頁面都要手動地改變呢？spa

又好比，若是有一天一個代碼的名稱須要換一個，是否是要到數據庫中把已經經存在的全部數據都更新一遍呢？如「證件」，如今叫「身份證」，有一天想改成叫「居民身份證」。原來若是沒有用數據字典，就意味着，要把「身份證」這幾個字存到《職員表》等信息表中：.net

《職員表》

姓名　　證件　　性別

張三　　身份證　男

李四身份證女

....

這樣，更名後就要手動改數據庫。但若是使用了數據字典，《職員表》裏面存的就是：

《職員表》

姓名　　證件　　性別

張三　　001 男

李四 001 女

....

另外增長了《證件表》：

《證件表》

證件id 證件名

001 身份證

002 暫住證

...

《證件表》就是第一種數據字典。要改變證件名稱時，只要把其中的「身份證」改爲「居民身份證」就行了，只需修改一次。並且，《職員表》不用作任何修改，頁面上若是用到「證件」，也不用作修改。

還有在程序中有時須要判斷業務邏輯時，用：「select * from 職員表 where 證件= ***」，原來***是「身份證」，使用數據字典後，就是001。證件更名後，就不用手動到程序裏去改，程序也就不用從新測試、發佈等等。

侷限性

但第一種數據字典也有侷限性。

使用第一種數據字典後，程序中除「職員」類外，還就須要有一個「國籍」類、一個「證件」類和一個「學歷」類，對應的數據庫中也須要增長一張「國籍」表、一張「證件」表和一張「學歷」表。「職員」類則須要包含一個對「國籍」類的引用、一個對「證件」類的引用和一個對「學歷」類的引用，對應的數據庫中「職員」表中也須要三個外鍵分別指向「國籍」表、「證件」表和「學歷」表。這樣的設計在相似「國籍」和「學歷」這樣的屬性比較少時是可行的，可是隨着系統複雜性的增長，系統中會出現大量結構相似的信息表和信息類，數量一直會增長到一個不可接受的地步。這裏的「職員」，已經有了國籍、證件和學歷三個屬性，但若是職員還要增長「職位」屬性，那麼必然要多出個「職位表」，若是還有其它...那即，當取得一條主體的徹底數據時，那將進行幾十個表的聯接（join）操做。

如何解決呢？...

2.2 第二類數據字典

經過分析上述問題，能夠發現的一個特徵是：這些信息類的內容都是須要動態維護的，可是所需的屬性是同樣的，對應的數據庫表中包含的字段也是同樣的。關鍵的字段就是兩個：「標識」和「名稱」。「標識」用於表示不變的主鍵，「名稱」用於表示程序界面上顯示的文字。

第二種數據字典就是爲了解決上述問題而設計的。

仍是以上面的例子爲例。在系統中去掉《國籍表》、《證件表》、《學歷表》….，引入《系統代碼分類表》和《系統代碼表》:

《系統代碼分類表》

分類標識分類名稱

Country 國籍

ID 證件

…

《系統代碼表》

標識分類內容

001 Contry 中國

002 Contry 美國

…..

501 ID 身份證

502 ID 暫住證

……

《系統代碼表》的「分類」字段都指向《系統代碼分類表》中的「分類標識」。這樣，在程序須要得到國籍信息時，只要經過「Country」這個標識去《系統代碼表》中檢索就能夠了。這樣的設計也便於創建一個單獨的程序模塊來維護全部的這些公共信息。

對於《職員表》，使用第一種數據字典時，其表結構是：

職員ID、姓名、國籍ID、證件ID、學歷ID…….

採用第二種數據字典後，其表結構是：

職員ID、姓名，另外增長《屬性表》，該表是《職員表》和《系統代碼表》的關係表，其表結構是：職員ID、屬性ID、系統代碼表_標識

如：

《職員表》

職員ID 姓名

1 張三

2 李四

…..

《屬性表》

職員ID 屬性ID 系統代碼表_標識

1 1 001 （表示張三是中國籍）

1 2 501 （表示張三的證件是身份證）

2 3 002 （表示李四是美國籍）

2 4 501 （表示李四的證件是身份證）

…..

能夠看出《職員表》的設計大爲簡化，系統也更加靈活了，徹底能夠適應主體屬性的大量變動了。程序的設計應用第二種數據字典時和數據庫表的方法同樣。

3、數據字典的通常設計

下面給出一個用數據庫實現的第二種數據字典表的設計。要注意這個設計不是惟一的，徹底能夠用XML、字符串等形式來設計數據字典。

數據字典表(Dictionary)：

字段名	類型	說明
編號	Char(16)	間斷增量(Not Null,PK)
分類名稱	Varchar(64)	用來進行過濾選取字典表相關域
內容	Varchar(255)
父級編號	Char(16)	取Dictionary的編號(FK)，用來進行等級設計。使之成爲樹型結構。