数据库——数据字典是什么？

一.数据字典以及使用场景：

<User表>

User表，User主体有很多属性，比如证件（身份证、居住证、港澳通行证...）地区（河北、河南、北京...）等，然后表建好了，数据也填进去了，项目代码也敲几万行。但是有一天，客户说这个“身份证”表述不够官方，要改成“居民身份证”比较好，所以作为这个项目开发人员，你要把代码里和数据库中所有的“身份证”改成“居民身份证”，这工作量估计很让人抓狂。

但是如果采用下边的建表方式，是不是就不会出现这种问题呢，将证件新建一个属性表，将属性值和主体分离，主体表只保存属性的的代码。这就是一种数据字典。

<user表> <证件表>

现在，大家应该对数据字典概念有个基本的理解了，数据字典（Data dictionary）是一种用户可以访问的记录数据库和应用程序元数据的目录。主动数据字典是指在对数据库或应用程序结构进行修改时，其内容可以由数据库管理系统自动更新的数据字典。被动数据字典是指修改时必须手工更新其内容的数据字典。

二.数据字典的两种形式

第一种：《主体表》里包含主体和属性代码，《属性表》里包含属性代码和属性Value,不同属性分别建表。
第二种：《主体表》里仅包含主体，《系统代码分类表》里存储属性标识和属性名称，《系统代码表》里包含所有属性代码、属性标识和属性Value，《属性表》是《主体》和《系统代码表》的关系表，包含属性id，主体id,属性代码。

举例：

第一种字典设计：

<User表> <证件表> <身份表>

第二种字典设计：

<User表> <系统代码分类表> <系统代码表> <属性表>

两种设计方式分析：

1.第一种设计方式：由于属性id是存储在主体表里的，属性的数量是不变的，而属性取值的数量可以是变化的。但是如果该主体的属性非常多的话，就需要建很多的属性表，在开发中还要设计很多属性类，那当想要取得一条主体的完全数据时，那将进行几十个表的联接（join）操作。性能耗损严重。当属性的数量不多时，用第一种数据字典即可。

2.第二种设计方式：由于这种设计方式属性和主题表是分开的，所以属性的数量是可变的，而属性取值的数量可以是变化的。引入《系统代码分类表》和《系统代码表》，也解决了第一种设计方式的局限性。

三.数据字典的优缺点

优点：

一、在一定程度上，通过系统维护人员即可改变系统的行为（功能），不需要开发人员的介入。使得系统的变化更快，能及时响应客户和市场的需求。

二、提高了系统的灵活性、通用性，减少了主体和属性的耦合度

三、简化了主体类的业务逻辑

四、能减少对系统程序的改动，使数据库、程序和页面更稳定。特别是数据量大的时候，能大幅减少开发工作量

五、使数据库表结构和程序结构条理上更清楚，更容易理解，在可开发性、可扩展性、可维护性、系统强壮性上都有优势。

缺点：

一、数据字典是通用的设计，在系统效率上会低一些。

二、程序算法相对复杂一些。

三、对于开发人员，需要具备一定抽象思维能力，所以对开发人员的要求较高。