标签：数据字典 思维 char order 优势 表设计 系统表 应用 能力
数据字典
自身理解:
应用程序往往对某一主体进行操作,主体属性名称,属性值的个数以及属性值往往都是多变的,而程序中执行sql语句检索需要多变的属性,传统数据表设计时,属性名称成为了硬编码,不仅程序代码中需要改变,而且数据库中多行记录中该值都需要改变-->此时属性值名与程序代码之间的耦合度增加了
?解决?属性名使用代码001标识,耦合度降低了
此时,就需要另一张表来记录属性名称与对应代码(也就相当于一对多关系时一方表,而多方只引用一方的标志列id),一方就相当于一个数据字典-->属性值的字典,而属性个数,属性名称并没有做到"灵活",且一定程度上仍然耦合度高-->主体表属性名称与个数为定数,项目需要改动时仍然需要硬编码改变
?解决?设立系统代码分类表(收集属性名称)/系统代码表(收集系统代码分类对应的 属性值)
主体表简化,而在系统代码表中引用系统代码分类标识与主体标识
此时,系统代码表中属性名变化时可自由在系统代码分类表中进行变动一次,系统表中引用的标识可不变
?
所以,此时数据库引用关系中的耦合度也大大降低
数据字典是一种通用的程序设计方法。可以认为，不论什么程序，都是为了处理一定的主体，这里的主体可能是人员、商品（超子）、网页、接口、数据库表、甚至需求分析等等。当主体有很多的属性，每种属性有很多的取值，而且属性的数量和属性取值的数量是不断变化的，特别是当这些数量的变化很快时，就应该考虑引入数据字典的设计方法。
一， 把主体的属性代码化放入独立的表中，不是和主体放在一起，主体中只保留属性的代码。这里属性的数量是不变的，而属性取值的数量可以是变化的。
二， 用一个表来放结构相同的所有属性信息，不同属性的不同取值统一编码，用“类型”来区别不同的属性，主体中保留属性代码的列表。这样主体所拥有的属性数量就是可变的了。
第二种数据字典比第一种更抽象，层级更高，也更具一般性、通用性。
这两种形式的归纳有些抽象，为说明这两种数据字典和它们的各种优点，下面举个简单的例子来说明：
现在有个需求，要在程序中处理“职员”信息。这里的主体就是“职员”，开始时“职员”有“国籍”、“证件”和“学历”等属性。
比如，对于一个“职员信息”页面上的“国籍”下拉列表，我们可以就用第一种的数据字典来存储不同的国家。如果不采取这样的方法，就需要手动的把所有可能的国家名称敲到页面上。这首先有个效率的问题，每个需要用到国籍的地方都要敲一次，要敲多久？还有，如果有一天，像南斯拉夫，突然国家换名了，是不是要所有涉及的页面都要手动地改变呢？
又比如，如果有一天一个代码的名称需要换一个，是不是要到数据库中把已经经存在的所有数据都更新一遍呢？如“证件”，现在叫“身份证”，有一天想改为叫“居民身份证”。原来如果没有用数据字典，就意味着，要把“身份证”这几个字存到《职员表》等信息表中：
《职员表》
姓名 证件 性别
张三 身份证 男
李四 身份证 女
....
这样，改名后就要手动改数据库。但如果使用了数据字典，《职员表》里面存的就是：
《职员表》
姓名 证件 性别
张三 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)：
|
字段名 |
类型 |
说明 |
|
编号 |
Char(16) |
间断增量(Not Null,PK) |
|
分类名称 |
Varchar(64) |
用来进行过滤选取字典表相关域 |
|
内容 |
Varchar(255) |
|
|
父级编号 |
Char(16) |
取Dictionary的编号(FK)，用来进行等级设计。使之成为树型结构。 |
标签：数据字典 思维 char order 优势 表设计 系统表 应用 能力
原文地址：https://www.cnblogs.com/autism-dong/p/12302996.html
