【数据字典】数据字典是什么（转）

数据字典

数据字典是一种通用的程序设计方法。能够认为，不论什么程序，都是为了处理必定的主体，这里的主体多是人员、商品（超子）、网页、接口、数据库表、甚至需求分析等等。当主体有不少的属性，每种属性有不少的取值，并且属性的数量和属性取值的数量是不断变化的，特别是当这些数量的变化很快时，就应该考虑引入数据字典的设计方法。

数据字典有两种形式
一，      把主体的属性代码化放入独立的表中，不是和主体放在一块儿，主体中只保留属性的代码。这里属性的数量是不变的，而属性取值的数量能够是变化的。

二，      用一个表来放结构相同的全部属性信息，不一样属性的不一样取值统一编码，用“类型”来区别不一样的属性，主体中保留属性代码的列表。这样主体所拥有的属性数量就是可变的了。

第二种数据字典比第一种更抽象，层级更高，也更具通常性、通用性。

这两种形式的概括有些抽象，为说明这两种数据字典和它们的各类优势，下面举个简单的例子来讲明：

如今有个需求，要在程序中处理“职员”信息。这里的主体就是“职员”，开始时“职员”有“国籍”、“证件”和“学历”等属性。

好比，对于一个“职员信息”页面上的“国籍”下拉列表，咱们能够就用第一种的数据字典来存储不一样的国家。若是不采起这样的方法，就须要手动的把全部可能的国家名称敲到页面上。这首先有个效率的问题，每一个须要用到国籍的地方都要敲一次，要敲多久？还有，若是有一天，像南斯拉夫，忽然国家换名了，是否是要全部涉及的页面都要手动地改变呢？

又好比，若是有一天一个代码的名称须要换一个，是否是要到数据库中把已经经存在的全部数据都更新一遍呢？如“证件”，如今叫“身份证”，有一天想改成叫“居民身份证”。原来若是没有用数据字典，就意味着，要把“身份证”这几个字存到《职员表》等信息表中：

《职员表》

姓名　　证件　　性别

张三　　身份证　男

李四        身份证   女

....

这样，更名后就要手动改数据库。但若是使用了数据字典，《职员表》里面存的就是：

《职员表》

姓名　　证件　　性别

张三　　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