数据字典的作用以及数据库表定义相关的字典表sysobjects和syscolumns

一、数据字典

二、数据库定义的相关的字典表

一、数据字典

1、什么是数据字典： 数据字典是描述数据的信息集合，是对系统中使用的 所有数据元素的定义的集合。其分为主动式数据字典和被动式，主动式值的是在对数据库或应用程序结构进行修改时，其内容可以有DBMS自动更新的数据字典。被动数据字典是指修改时必须手动更新其内容的数据字典。

2、什么时候使用数据字典: 一般是在主题有很多的属性，每种属性有很多的取值，而且属性的数量和属性取值的数量是不断变化的，特别是当这些数量的变化很快的时候，基于应该考虑引入数据字典。

3、数据字典的两种形式： a、把主体的属性代码放入独立的表中，不是和主体放在一起，主体中只保留属性的代码（相当于一个编号）。这里属性的数量应该是基本不变的，但是属性的取值的数量是可以变化的。
例如，考虑这样的情况： 有一个职员表：

职员表

姓名	证件	性别
张三	身份证	男
李四	身份证	女

《职员表》中属性的数量基本是不会改变的，但是在证件这一栏中取值可能是经常变化的，例如如果之后证件一栏要将身份证全部改为居民身份证，那么应该如何解决呢？是将数据库中的所有有身份证的表都更新一遍嘛？显然不行，这时候使用数据字典，将属性写成一个表，主体中只有属性的代码。所以将数据库改为：

职员表

姓名	证件	性别
张三	001	男
李四	001	女

新增加了证件表：

证件表

001	身份证
002	暂住证

这样的话，如果要改身份证的名称，那么直接在证件表中进行相应的修改就可以了。
缺点：使用这种数据字典，程序中除了“职员”类外，还可能需要“国籍”类（比如一个国家的名称改了），和一个学历类，那么对应的数据库要添加国籍表、学历表等等，那么职员表中就需要三个外键分贝指向这三个表，当属性的数量较少的时候可能是可行的，但是随着协同复杂性的增加，系统中会出现大量结构类似的信息表和信息类，数量就会增加到不可接受，并且如果要取得一个主体的一条完全实例的时候， 就要进行几十个表的联结(join)操作。
b、用一个表来放结构相同的所有属性信息，不同属性的不同取值统一编码，用"类型”来区别不同的属性，主体中保留属性代码的列表，这样主体所拥有的属性数量就是可变的。
第二种数据字典比第一种更抽象，层级更高，也更具有一般性、通用性。
可以认为，第二种方法就是将所有的表都进行合并，得到一个单一的表，从而减少了表之间的互联。在第一种方法的基础上使用第二种方法，首先要去掉国籍表、证件表和学历表，引入《系统代码分类表》和《系统代码表》
例子：

系统代码分类表：关键字段是“标识”和“名称"，“标识”也就是不变的主键，“名称”标识程序界面上现实的文字

分类标识	分类名称
Country	国籍
ID	证件

系统代码表：

标识	分类	内容
001	Country	中国
002	Country	美国
……	……	……
501	ID	身份证
502	ID	暂住证

那么这个时候职员表就变成了：

职员表

职员ID	姓名
1	张三
2	李四

除了这些表之外，还需要一张 属性表，用来表示职员表和系统代码表之间的关系：

属性表

属性ID	职员ID	系统代码表_标识
1	1	001
2	1	501
3	2	002
4	2	501

由此看出这种方法的数据字典可以避免当主体的属性大量变化的时候导致很多表的级联。

数据字典的优点:
提高了系统的灵活性、通用性、减少了主体和属性的耦合度；使得数据库表结构和程序结构条理上更清楚，更容易理解，在可开发项、可扩展性、可维护性上有很大的作用。总之对于上述主体属性的大量修改的时候，数据库还是很有优势的。

数据字典的缺点： 从上面的过程中可以看出，数据字典的效率应该不是很高。

二、数据库定义的相关的数据字典:

sysobject和syscolum：
sysobject:系统对象表，保存当前数据库的对象，如约束、默认值、日志、规则、存储过程等。
syscolumn:当前数据库的所有字段都保留在里面。（ 数据库中的字段就是指表的一列）
具体这些表中都存了什么，看参考 博客。
至于这个两个表，应该是视图，起码在sql sever上是视图，因为其是在master库中的系统视图中。

参考博文： https://blog.csdn.net/qq_37023388/article/details/79061881M