一、数据字典
二、数据库定义的相关的字典表
一、数据字典
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