数据库第四章——设计数据库

概述

方案

• 应用架构:单用户结构、集中式结构、客户/服务器结构和分布式结构。
• 结构模型(重点)
  • 概念数据模型(CDM):面向用户的系统数据模型,描述现实世界
  • 逻辑数据模型(LDM):概念模型基础上,从系统设计角度描述系统 的数据对象组成及其关联结构
  • 物理数据模型(PDM):针对具体DBMS设计
• 应用访问方式
  • 直接本地接口连接访问
  • 基于标准接口连接访问
  • 基于数据访问层框架连接访问

开发过程

• 数据需求分析阶段
  • 从现实业务获取数据表单、报表、查询、业务规则、数据更新的说明
  • 分析系统的数据特征、数据类型、数据取值约束
  • 描述系统的数据关系、数据处理要求
  • 建立系统的数据字典
• 数据库设计阶段
  • 数据库模型结构设计(概念数据模型、逻辑数据模型、物理数据模型)
  • 数据库索引、视图、查询设计
  • 数据库表约束设计
  • 数据库触发器、存储过程设计
• 数据库实现阶段
  • 数据库创建
  • 数据模型物理实现
• 数据库测试阶段
  • 数据库数据.上线
  • 数据库系统测试

设计策略

• 自底向上设计
• 自顶向下设计
• 自内向外设计
• 混合策略设计

E-R模型方法

实体-联系模型,是设计概念数据模型、逻辑数据模型的有效方法

基本元素

• 实体：矩形框表示
  • 实例：实体的具体化（类比：java中类——实例）
• 属性
• 标识符：标识不同实体的属性，用下划线表示（类似主键，但是标识符是逻辑概念，主键是物理概念）
• 联系：实体之间的联系
  • 联系度数：关联的实体数目（自联系的联系度数为1）

类型

二元实体联系类型：

• 一对一
• 一对多
• 多对多

基数：一个给定实体有多少实例与另一实体实例存在的数量对应关系

强制和可选：反应实体参与关系的必要性

利用鸟足图表示上述关系

符号说明

继承联系

• 互斥性继承联系：不能同时属于多个子实体
• 非互斥性继承联系：可以是多个子实体
  
• 完整继承联系：父实体必然属于子实体中的某一个
• 非完整继承联系
  

强弱实体联系

• 弱实体：对于另外实体有依赖关系，即一个实体的存在必须以两一个实体的存在为前提
  • 标识符依赖弱实体：弱实体的标识符中含有依赖实体的标识符
  • 非标识符依赖弱实体：有自己的标识符
• 强实体：被依赖的实体
  

成绩表是标识符依赖弱实体,自动获取学生和课程的标识符

数据库建模设计

概念数据模型设计是通过对现实世界中数据实体进行抽取、分类、聚集和概括等处理，建立反映系统业务数据组成结构的过程。

设计步骤

• 业务数据分析，抽取数据实体
• 定义实体属性及其标识
• 建立实体联系，构建局部E-R模型图
• 分类、聚集和概括各个部分E-R模型图
• 完善全局E-R模型图，建立系统业务数据组成结构

数据库结构模型转换

概念数据模型	逻辑数据模型	关系数据库的物理数据模型
实体	实体	表
属性	属性	列
标识符	标识符(主键/外键)	键
联系	联系	参照完整性约束

E-R模型到关系模型转换原理

• 将每一个实体转换成一个关系表，实体属性转换为关系表的列，实体标识符转换为关系表的主键或外键
• 将实体之间的联系转化为关系表之间的参照完整性约束。

弱实体转换关系表

• 非标识符依赖弱实体:原标识符作为主键,依赖对象的标识符作为外键
• 标识符依赖弱实体:依赖对象的标识符作为主键和外键,原标识符作为主键,构成复合键

实体关系转换参照完整性

• 1:1 : 选一个实体(1)的主标识符作为另一个实体(1)的表的外键
• 1:N : 父实体(1)关系表的主键作为子实体(N)关系表的外键
• M:N : 构建中间表(标识符依赖弱实体),分别以两个实体关系表的主键作为主键和外键

继承联系

父表的主键放置在子表中,既作主键也做外键

递归联系

• 1:N 标识符转换为主键,也转化为外键
  
• M:N: 增加一个关联表

设计规范

目标

• 减少数据库中的冗余数据，尽量使同一数据在数据库中仅保存一份，有效降低维护数据一致性的工作量。
• 设计合理的表间依赖关系和约束关系，便于实现数据完整性和一致性。
• 设计合理的数据库结构，便于系统对数据高效访问处理。

非规范化关系表的数据操作问题

增删改数据造成数据异常

原因:

• 同一关系中存在多个主题信息
• 关系表中存储冗余数据

引入理论——函数依赖

定义:设有一关系模式$R(U)$，$U$ 为关系$R$的属性集合，$X$和$Y$为属性$U$的子集。设$t$，$s$是关系R中的任意两个元组，如果$t[X]=s[X]$，$t[Y]=s[Y]$。那么称Y函数依赖于X，表示为$X\to Y$。

简单点说:某个属性集决定另一个属性集时，称另一属性集依赖于该属性集

函数依赖的左部称为决定因子，右部称为依赖函数。决定因子和依赖函数都是属性的集合。

● 如果X和Y之间是1：1关系（一对一关系），如学校和校长之间就是1:1关系，则存在函数依赖X → Y和Y →X。
● 如果X和Y之间是1：n关系（一对多关系），如年龄和姓名之间就是1:n关系，则存在函数依赖Y → X。
●如果X和Y之间是m：n关系（多对多关系），如学生和课程之间就是m:n关系，则X和Y之间不存在函数依赖

说明:函数依赖反映属性或属性组之间相互依存、互相制约的关系，即关系表中属性之间的依赖关系。

类型

• 完全函数依赖：关系R中，X、Y是属性集，X决定Y的值(X→Y)，且任何一个X(子)都没办法决定Y的值

• 部分函数依赖：关系R中，X、Y是属性集，X决定Y的值(X→Y)，且X其中一个子集满足X(子)决定Y的值
• 属性传递依赖：关系R中，X、Y、Z是属性集，X决定Y的值(X→Y),Y不决定X，Y决定Z的值(Y→Z)，则有X决定Z(X→Z) 称Z传递函数依赖于X
• 多值函数依赖：关系R中，X，Y，Z是属性集，Z=U-X-Y，存在（x，y1，z1）和（x，y2，z2），也存在（x，y1，z2）和（x，y2，z1）

关系规范化范式

关系规范化:把一个有访问异常的关系分解成结构良好的关系，使得这些关系有最小的冗余或没有冗余
规范化范式(Normal Form， NF) :关系表符合特定规范化程度的模式

• 第一范式: 关系表属性不可再分(原子性)——同一列不能有多个值
• 第二范式: 满足第一范式且消除了部分函数依赖——属性完全依赖主键,主键唯一确定
• 第三范式: 满足第二范式且切断了传递函数依赖
• 巴斯-科德范式(BCNF):所有函数依赖的决定因子都是候选键
• 第四范式:满足巴斯-科德范式且消除多值函数依赖——多对多关系

规范化程度越高,冗余数据越少,但是分解出来的表越多,效率降低

逆规范化处理

降低规范化范式约束，适当增加数据冗余度，以增加数据访问性能

基本方法：

• 增加冗余列或派生列
• 多个关系表合并为一个关系表

数据库性能优化

• 分布式数据库
• 分区
• 逆规范化