【數據字典】數據字典是什麼（轉）

數據字典

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

數據字典有兩種形式
一，      把主體的屬性代碼化放入獨立的表中，不是和主體放在一塊兒，主體中只保留屬性的代碼。這裏屬性的數量是不變的，而屬性取值的數量能夠是變化的。

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

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

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

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

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

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

《職員表》

姓名　　證件　　性別

張三　　身份證　男

李四        身份證   女

....

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

《職員表》

姓名　　證件　　性別

張三　　001           男

李四       001           女

....

另外增長了《證件表》：

《證件表》

證件id  證件名

001      身份證

002      暫住證

...

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

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

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

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

如何解決呢？

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

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

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

《系統代碼分類表》

分類標識           分類名稱

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  （表示張三是中國籍）

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

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

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

…..

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

數據字典的優勢
一，      在必定程度上，經過系統維護人員便可改變系統的行爲（功能），不須要開發人員的介入。使得系統的變化更快，能及時響應客戶和市場的需求。

二，      提升了系統的靈活性、通用性，減小了主體和屬性的耦合度

三，      簡化了主體類的業務邏輯

四，      能減小對系統程序的改動，使數據庫、程序和頁面更穩定。特別是數據量大的時候，能大幅減小開發工做量

五，      使數據庫表結構和程序結構條理上更清楚，更容易理解，在可開發性、可擴展性、可維護性、系統強壯性上都有優點。

 

數據字典的缺點
1，         數據字典是通用的設計，在系統效率上會低一些。

2，         程序算法相對複雜一些。

3，         對於開發人員，須要具有必定抽象思惟能力，因此對開發人員的要求較高。

 

因此，當屬性的數量很少時，用第一種數據字典便可。對於大型的，未定型的系統，能夠採用第二種數據字典來設計。至於具體的系統裏怎麼設計，仍是要在看實際狀況來找尋通用性和效率兩者間的平衡。不管怎麼作，關係理論和範式還是基礎。

 

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

數據字典表(Dictionary)：

 

原文：https://blog.csdn.net/qq_39530754/article/details/85130249