三级模式-两级映射(以选择题形式出现)
属于层次型的架构设计,增加系统的可维护性、应变性
物理数据库:一个文件
内模式:数据以什么格式进行存储,如何优化数据
关注:对数据的存放
概念模式:数据库中的表
外模式:数据库里面的视图
对数据有了更加灵活的处置方式
**
如果app是直接访问概念模式的,如果概念模式(基本表)改变了,那么应用程序也得跟着改变
安全问题:不能让应用访问整个属性列,比如属性列中存储着密码,这样不安全。创建一个个视图,视图包括除了密码其他的都有
**
**映射
外-概念:用户层
概念模式变了只需要改变外模式(视图)和概念模式之间的映射关系就可以了
概念-内:系统层
如果存储方式改变,只需改变内模式和概念模式之间的映射关系就可以了,概念模式不需要关注存储方式的改变
E-R模型
先画局部的图,在将各个部分集成起来,合成全局的E-R图
逐步集成:
优点:
简单,不容易出错
缺点:
费时
属性域冲突:
属性值冲突:同一个属性,有的取值表示内容不同,比如表1:男用"男"表示,表2:男用"1"表示
结构冲突:不同抽象级别:老师是一个表,也是另一个表的字段(列)
实体转换成关系模式
一对一的联系:
一个实体转换成两个关系模式,他们的联系放在任意一个关系模式里面
一对多的联系:
最少转换成两个关系模式
员工与部门之间的联系:
联系必须放在员工里面,比如把部门号放在员工里面
多对多的联系:
至少转换成三个关系模式
因为联系必须单独占一个关系模式,存储其他实体之间的联系,
再每个实体占一个关系模式
关系代数 (不做笔记)
规范化理论-函数依赖
规范化理论-价值与用途
设计领域没有绝对的标准,一项指标提的很高必然会使另一项指标下降,比如安全性与性能
规范化理论-键
求候选键
图示法求候选键
规范化理论-范式
随着范式登记的提升,规范化程度越高数据粒度越小,做到第三范式左右就差不多了。
第二三范式虽然解决了前面的一些问题,但是即使是在第三范式也可能出现数据冗余的情况
第一范式
第二范式
部分函数依赖带来的问题:数据冗余
数据冗余会造成更多的麻烦
第三范式
单主属性,不可能存在部分函数依赖
这里的传递依赖表现为,SNO可以唯一确定DNO,且DNO可以唯一确定LOCATION
这样出现了非主属性对关键码的部分依赖
BC范式
规范化理论-例题
不属于第三范式说明是第一范式或者第二范式
部分函数依赖必须建立在主键是组合属性的基础上
表4解决的问题是:职工号和部门号之间没有联系,要在职工号上加部门号(因为职工号和部门号是多对一的关系,所以在多的那一端加另一个表的主键)
不用再销售里加部门号,因为在表示已经建立了职工号和部门号之间的函数依赖