430 likes | 700 Vues
17 数据库设计 ① 郑捷. 数据库 原理 与应用. 关系数据理论. 问题的提出 规范化 公理系统 模式的分解. 数据库原理与应用. 郑捷 lzj@fjnu.edu.cn www.lzj.name. 2. 数据依赖. 一个关系内部属性与属性之间的一种约束关系 现实世界属性间相互联系的抽象 数据内在的性质,语义的体现. 数据库原理与应用. 郑捷 lzj@fjnu.edu.cn www.lzj.name. 3. 规范化. 规范化理论正是用来改造关系模式,通过分解关系模式来消除其中不合适的数据依赖,以解决插入异常、删除异常、更新异常和数据冗余问题.
E N D
17 数据库设计 ① 郑捷 数据库原理与应用
关系数据理论 问题的提出 规范化 公理系统 模式的分解 数据库原理与应用 郑捷 lzj@fjnu.edu.cn www.lzj.name 2
数据依赖 一个关系内部属性与属性之间的一种约束关系 现实世界属性间相互联系的抽象 数据内在的性质,语义的体现 数据库原理与应用 郑捷 lzj@fjnu.edu.cn www.lzj.name 3
规范化 规范化理论正是用来改造关系模式,通过分解关系模式来消除其中不合适的数据依赖,以解决插入异常、删除异常、更新异常和数据冗余问题 数据库原理与应用 郑捷 lzj@fjnu.edu.cn www.lzj.name 4
范式 范式(Normal Formal)是符合某一种级别的关系模式的集合 关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式 范式的种类 1NF, 2NF, 3NF, BCNF, 4NF, 5NF 数据库原理与应用 郑捷 lzj@fjnu.edu.cn www.lzj.name 5
第二范式 2NF 定义:若R∈1NF,且每个非主属性完全函数依赖于码,则R∈2NF 即:在1NF基础上消除部分依赖,得到2NF 消除方式:;利用投影分解,将一个关系分解成若干个关系
第三范式 3NF 定义:关系模式R<U, F>中不存在这样的码X,属性组Y和非主属性Z(Z不包含于Y),使得X→Y, Y→Z成立,Y\→X,则称R∈3NF 即:在2NF基础上消除了对码的传递依赖 但是,多组候选码的情况除外 消除方式:还是通过投影分解关系
BC范式 BCNF 定义:关系模式R<U, F>∈1NF。若X→Y且Y不包含于X时,X必含有码,则R∈BCNF 即:每一个决定因素都包含码的1NF属于BCNF 可以证明,BCNF比3NF更严格
模式分解的彻底程度 当一个模式已经满足BCNF时,在函数依赖的范围内已经实现了彻底的分离 彻底消除了插入和删除的异常 但是除了函数依赖,还有一些其他形式的依赖
多值依赖 MVD 定义:R(U)是属性集U上的一个关系模式,X、Y、Z是U的子集,并且Z=U-X-Y。关系模式R中多值依赖X→→Y成立,当且仅当对R的任意关系r,给定的一对(x, z),有一组的Y的值,这组值仅仅决定于x而与z无关 在R(U)的任一关系r中,若存在元组t、s,使得t[X]=s[X],那么就必然存在元组w、v∈r,使得w[X]=v[X]=t[X],而w[Y]=t[Y],w[Z]=s[Z],v[Y]=s[Y],v[Z]=t[Z],则Y多值依赖于X,记为X→→Y。这里X、Y是U的子集,Z=U-X-Y。 若X→→Y,而Z=空集,则成为平凡的多值依赖
多值依赖的特点 对称性 传递性 函数依赖可以看作多值依赖的特殊情况 X→→Y,X→→ZX→→YZ X→→Y,X→→ZX→→Y∩Z X→→Y,X→→ZX→→Y-Z,X→→Z-Y
第四范式 4NF 定义:关系模式R<U, F>∈1NF,如果对于R的每个非平方多值依赖X→→Y(Y不包含于X),X都含有码,则R∈4NF 4NF限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖 4NF允许的非平凡的多值依赖实际上是函数依赖 如果一个关系模式是4NF,则必定是BCNF 用分解模式的方式消除非平凡的多值依赖
规范化小结 规范化的基本思想是逐步消除数据依赖中的不合适的部分 基本手段就是分解关系
数据库设计 • 概述 • 需求分析 • 概念结构设计 • 逻辑结构设计 • 数据库的物理设计 • 数据库的实施和维护
概述 • 通常,使用数据库的各类信息系统都统称为数据库应用系统 • 广义的数据库设计,是数据库及其应用系统的设计,即设计整个的数据库应用系统 • 狭义的数据库设计是设计数据库本身,即设计各级模式并建立数据库
数据库设计的定义和目标 • 数据库设计是指对于给定的一个应用环境,构造(设计)优化的数据库逻辑模式和物理结构,并据此建立数据库及其应用系统,使之能够有效地存储和管理数据,满足各种用户的应用需求,包括信息管理要求和数据操作要求 • 数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效率的运行环境
数据库设计的特点 • 三分技术、七分管理、十二分基础数据 • 结构(数据)设计和行为(处理)设计相结合
数据库设计的方法 • 新奥尔良方法 • 第三范式设计方法 • 面向对象设计方法
数据库设计的基本步骤 • 需求分析 • 概念结构设计 • 逻辑结构设计 • 数据库的物理设计 • 数据库的实施和维护
需求分析 • 任务 • 方法 • 数据字典
需求分析的任务 • 调查、了解、明确、功能 • 数据和处理 • 信息要求、处理要求、安全性和完整性要求
需求分析的方法 • 调查机构 • 调查业务活动 • 明确用户需求 • 确定系统边界 • 各种调查方法
数据字典 • 数据字典是系统中各类数据描述的集合 • 包括 • 数据项 • 数据结构 • 数据流 • 数据存储 • 处理过程
补充问题 • 收集、预期将来可能发生的扩充和变化 • 强调用户的参与
概念结构 • 能真实、充分地反映现实世界 • 易于理解 • 易于更改 • 易于转换
常用方法与步骤 • 自顶向下 • 自底向上 • 逐步扩张 • 混合策略
数据抽象 • 分类 classification • 聚集 aggregation • 概括 generalization
概念结构设计步骤 • 选择局部应用 • 逐一设计分E-R图 • 视图集成
实体和属性 • 实体和属性没有截然划分的界限 • 作为“属性”,不能再有需要描述的性质,属性必须是不可分的数据项,不能包含其他属性 • 属性不能和其他实体有联系
视图的集成 • 各子系统的E-R图设计好后,需要将所有的分图综合成总的E-R图 • 可以一次性集成,也可以先部分集成,然后逐步合并 • 不论哪种方式,都要经过以下两个阶段 • 合并 • 修改和重构 • 要解决分图之间的冲突
可能发生的冲突 • 属性冲突 • 域冲突 • 取值单位冲突 • 命名冲突 • 同名异义 • 一义多名 • 结构冲突
消除不必要的冗余 • 冗余的数据:可以由其他基本数据导出的数据 • 冗余的联系:可以有其他联系导出的联系 • 并非所有的冗余都需要消除,要根据实际情况来决定。即以空间换时间
函数依赖 • 还可以使用规范化的方式进行消除 • 根据函数依赖为主进行
函数依赖法分析 • 列举全部可能的名词 • 消去具体名词,保留概念名词 • 消去同义词、解决同名不同义的冲突 • 找出依赖关系,完全直接依赖 • 添加必要的编号属性 • 以依赖关系建立表
逻辑结构设计 • 逻辑结构是与所采用的DBMS相符合的结构 • 基本上都是先选定DBMS才设计数据库的
E-R图向关系模式的转换 • 一个实体型转换为一个关系模式 • 实体的属性就是关系的属性 • 实体的码就是关系的码 • 实体之间的联系根据情况进行不同转换 • 1:1 • 1:n • m:n • 多元联系 • 相同码的实体
数据模型的优化 • 通过依赖进行 • 考虑部分的冗余 • 进行必要的水平和垂直分解
设计用户子模式 • 即用户看到的外模式 • 视图的设计 • 让用户更方便地使用 • 让用户更安全地使用
数据库物理设计 • 数据库在物理设备上的存储结构和存取方法 • 依赖于选定的DBMS • 基本上目前的DBMS都有很强大的自动优化功能,能够为数据选择一个它认为最合适的物理模型 • 但是我们可以手工指定各种参数,对物理模型进行细节上的控制 • 另外:有可能需要手工进行数据管理
关系模式的存取办法 • 索引存取 • 聚簇存取 • 哈希存取
数据库的实施和维护 • 实施 • 数据的载入 • 程序的编码和调试 • 维护 • 数据库的备份和还原 • 安全性、完整性控制 • 性能的监督、分析和改进 • 重组织和重构造
数据库设计 • 概述 • 需求分析 • 概念结构设计 • 逻辑结构设计 • 数据库的物理设计 • 数据库的实施和维护