第 6 章 数据库系统

三级模式-两级映射（以选择题形式出现）

属于层次型的架构设计，增加系统的可维护性、应变性

物理数据库：一个文件

内模式：数据以什么格式进行存储，如何优化数据

        关注：对数据的存放

概念模式：数据库中的表

外模式：数据库里面的视图

        对数据有了更加灵活的处置方式

**

如果app是直接访问概念模式的，如果概念模式（基本表）改变了，那么应用程序也得跟着改变

安全问题：不能让应用访问整个属性列，比如属性列中存储着密码，这样不安全。创建一个个视图，视图包括除了密码其他的都有

**

 

 

**映射

外-概念：用户层

概念模式变了只需要改变外模式（视图）和概念模式之间的映射关系就可以了

 

概念-内：系统层

    如果存储方式改变，只需改变内模式和概念模式之间的映射关系就可以了，概念模式不需要关注存储方式的改变

 

 

E-R模型

先画局部的图，在将各个部分集成起来，合成全局的E-R图

 

 

逐步集成：

        优点：

            简单，不容易出错

        缺点：

            费时

属性域冲突：

属性值冲突：同一个属性，有的取值表示内容不同，比如表1：男用"男"表示，表2：男用"1"表示

结构冲突：不同抽象级别：老师是一个表，也是另一个表的字段（列）

 

 

实体转换成关系模式

一对一的联系：

一个实体转换成两个关系模式，他们的联系放在任意一个关系模式里面

一对多的联系：

最少转换成两个关系模式

 

员工与部门之间的联系：

    联系必须放在员工里面，比如把部门号放在员工里面

多对多的联系：

至少转换成三个关系模式

因为联系必须单独占一个关系模式，存储其他实体之间的联系，

再每个实体占一个关系模式

关系代数 （不做笔记）

 

 

规范化理论-函数依赖

 

 

 

 

 

规范化理论-价值与用途

设计领域没有绝对的标准，一项指标提的很高必然会使另一项指标下降，比如安全性与性能

规范化理论-键

求候选键

图示法求候选键

 

 

规范化理论-范式

随着范式登记的提升，规范化程度越高数据粒度越小，做到第三范式左右就差不多了。

第二三范式虽然解决了前面的一些问题，但是即使是在第三范式也可能出现数据冗余的情况

第一范式

第二范式

部分函数依赖带来的问题：数据冗余

数据冗余会造成更多的麻烦

 

第三范式

单主属性，不可能存在部分函数依赖

这里的传递依赖表现为，SNO可以唯一确定DNO，且DNO可以唯一确定LOCATION

这样出现了非主属性对关键码的部分依赖

BC范式

 

 

 

规范化理论-例题

不属于第三范式说明是第一范式或者第二范式

部分函数依赖必须建立在主键是组合属性的基础上

表4解决的问题是：职工号和部门号之间没有联系，要在职工号上加部门号（因为职工号和部门号是多对一的关系，所以在多的那一端加另一个表的主键）

不用再销售里加部门号，因为在表示已经建立了职工号和部门号之间的函数依赖