一.数据字典以及使用场景:
<User表>
User表,User主体有很多属性,比如证件(身份证、居住证、港澳通行证...)地区(河北、河南、北京...)等,然后表建好了,数据也填进去了,项目代码也敲几万行。但是有一天,客户说这个“身份证”表述不够官方,要改成“居民身份证”比较好,所以作为这个项目开发人员,你要把代码里和数据库中所有的“身份证”改成“居民身份证”,这工作量估计很让人抓狂。
但是如果采用下边的建表方式,是不是就不会出现这种问题呢,将证件新建一个属性表,将属性值和主体分离,主体表只保存属性的的代码。这就是一种数据字典。
<user表> <证件表>
现在,大家应该对数据字典概念有个基本的理解了,数据字典(Data dictionary)是一种用户可以访问的记录数据库和应用程序元数据的目录。主动数据字典是指在对数据库或应用程序结构进行修改时,其内容可以由数据库管理系统自动更新的数据字典。被动数据字典是指修改时必须手工更新其内容的数据字典。
二.数据字典的两种形式
- 第一种:《主体表》里包含主体和属性代码,《属性表》里包含属性代码和属性Value,不同属性分别建表。
- 第二种:《主体表》里仅包含主体,《系统代码分类表》里存储属性标识和属性名称,《系统代码表》里包含所有属性代码、属性标识和属性Value,《属性表》是《主体》和《系统代码表》的关系表,包含属性id,主体id,属性代码。
举例:
第一种字典设计:
<User表> <证件表> <身份表>
第二种字典设计:
<User表> <系统代码分类表> <系统代码表> <属性表>
两种设计方式分析:
1.第一种设计方式:由于属性id是存储在主体表里的,属性的数量是不变的,而属性取值的数量可以是变化的。但是如果该主体的属性非常多的话,就需要建很多的属性表,在开发中还要设计很多属性类,那当想要取得一条主体的完全数据时,那将进行几十个表的联接(join)操作。性能耗损严重。当属性的数量不多时,用第一种数据字典即可。
2.第二种设计方式:由于这种设计方式属性和主题表是分开的,所以属性的数量是可变的,而属性取值的数量可以是变化的。引入《系统代码分类表》和《系统代码表》,也解决了第一种设计方式的局限性。
三.数据字典的优缺点
优点:
一、在一定程度上,通过系统维护人员即可改变系统的行为(功能),不需要开发人员的介入。使得系统的变化更快,能及时响应客户和市场的需求。
二、提高了系统的灵活性、通用性,减少了主体和属性的耦合度
三、简化了主体类的业务逻辑
四、能减少对系统程序的改动,使数据库、程序和页面更稳定。特别是数据量大的时候,能大幅减少开发工作量
五、使数据库表结构和程序结构条理上更清楚,更容易理解,在可开发性、可扩展性、可维护性、系统强壮性上都有优势。
缺点:
一、数据字典是通用的设计,在系统效率上会低一些。
二、程序算法相对复杂一些。
三、对于开发人员,需要具备一定抽象思维能力,所以对开发人员的要求较高。