一、数据库设计方案
1. 数据库应用架构设计：单用户、集中、CS、分布
2. 数据库结构设计：概念、逻辑、物理
3. 数据库应用访问设计：访问
数据库结构设计模型
概念数据模型：概念，不考虑实时细节
逻辑数据模型 ：逻辑表示
物理数据模型：具体实现
数据库建模设计过程
1)数据需求分析阶段
2)数据库设计阶段
3)数据库实现阶段
4)数据库测试阶段
2.设计策略
自顶向下分析需求和自底向上设计概念结构：需求分析为自顶向下，概念结构为自底向上
概念模型（CDM）：数据结构、数据操作和完整性约束
实体联系模型（ERM）：甲方用户要求
概念模型的用途
对概念模型的基本要求
ER模型和基本概念：现实对象：
实体(Entity)
属性（Attribute）
域(Domain)：取值范围
键：唯一的识别属性
实体型（Entity Type）：实体名 属性
实体集（Entity Set）：实体集合
实体、属性和标识符的表达：唯一的标识
主流数据库建模工具Power Designer
Power Designer可建立的数据模型
Power Designer各个数据模型之间的关系
使用PowerDesigner工具进行数据库建模
(1) 创建工程
(2) 创建数据库模型
(3) 创建实体（或实体型）
(3) 给实体命名
(3) 给实体添加属性
(3) 属性添加完成
PowerDesigner创建实体
ER模型及基本概念
联系（Relationship）
实体间联系的类型
1.一对一联系（one-to-one，1:1）
2. 一对多联系（one-to-many，1:N）
3. 多对多联系（many-to-many，M:N）
(4) 添加联系
(4) 修改联系类型
弱实体(Weak Entities):没有键的实体
识别实体型与识别联系：弱实体通过关系结合实体识别
ER模型描述概念分层
注意：调整布局的逻辑清晰美观
三、E-R 模型的设计实例
第1步 设计局部 E-R 模型
2、组合局部 E-R 模型为全局 E-R 模型
3、消除冗余，优化全局 E-R 模型
改进后 E-R 模型
通过PowerDesigner将概念模型转化为逻辑模型
检查模型的正确性
通过PowerDesigner转化的逻辑模型
通过PowerDesigner转化物理模型
由物理模型生成SQL语句如下，可以copy到文本编辑器
为什么要对关系模式进行优化？
如何对关系模式进行优化？
一、实例-假设有如下表
上述教师学生模式可能存在的问题
解决方案：
分析为何存在这些问题
三、规范化的几个概念
1、属性的几个概念
（1）简单属性和复合属性:可不可以再分
（2）单值属性和多值属性
（3）基本属性和导出属性
（4）属性之间的联系
2、键的几个概念
3、函数依赖：就是函数的映射关系
函数依赖等价定义
函数依赖定义：
函数依赖关心的问题：
（1）平凡函数依赖和非平凡函数依赖：X->Y，Y是X子集，平凡依赖
（2）完全函数依赖和部分函数依赖：X->Y，X子集->Y，Y部分依赖
（3）传递函数依赖和非传递函数依赖：X->Y，Y->Z，Y-x->X，X传递决定Z
Armlabel公理系统：函数映射系统
Armlabel公理包含如下三条推理规则：
多值依赖：X可以决定一组Y的值
多值依赖的另一等价定义：
多值依赖的性质：
多值依赖与函数依赖的区别
三、关系模式规范化理论
1、第一范式（1NF）：关系表R不存在复合属性及多值属性
2、第二范式（2NF）：所有非主属性都完全依赖于任一候选键，候选键->非主属性，候选键子集-x->非主属性
INF转化为2NF
3、第三范式（3NF）
如何将1NF转化3NF
4、改进的3NF（BCNF）
BCNF范式示例
BCNF范式的规范化
5、第四范式（4NF）
4NF范式的规范化
四、规范化程度
规范化的过程
规范化与操作效率
规范化过程：
三、反规范化处理
反规范化处理的主要手段有如下2种：
但反规范化的使用也会带来以下问题：
一、数据库设计方案
数据库设计是数据库应用系统开发的重要内容。在实现数据库之前，必须有明确的设计方案。
1. 数据库应用架构设计：单用户、集中、CS、分布
在不同应用需求场景中，数据库的应用架构方式是不同的。
数据库应用架构可分为。
2. 数据库结构设计：概念、逻辑、物理
数据库结构设计一般分为，设计模型分别为。
3. 数据库应用访问方式设计：访问方式
数据库应用对数据库访问可以有多种方式，如。
数据库结构设计模型
概念数据模型：概念，不考虑实时细节
（Concept Data Model，CDM）是一种面向用户的系统数据模型，它用来描述现实世界的系统概念化数据结构。
使数据库设计人员在系统设计的初始阶段，摆脱计算机系统及DBMS的具体技术问题，集中精力分析业务数据以及数据之间
的联系等，描述系统的数据对象及其组成关系。
逻辑数据模型 ：逻辑表示
(Logic Data Model，LDM)是在概念数据模型基础上，从描述，并考虑这些数据对象符合数据库对象的逻辑表示。
物理数据模型：具体实现
（Physical Data Model，PDM）是在逻辑数据模型基础上，针对具体DBMS所设计的数据模型。
它用于描述系统数据模型在具体DBMS中的数据对象组织、存储方式、索引方式、访问路径等实现信息。
数据库建模设计过程
1）数据需求分析阶段
- 从现实业务获取数据表单、报表、查询、业务规则、数据
- 更新的说明
- 分析系统的数据特征、数据类型、数据取值约束
- 描述系统的数据关系、数据处理要求
- 建立系统的数据字典
2）数据库设计阶段
- 数据库模型结构设计（概念数据模型、逻辑数据模型、物理数据模型）
- 数据库索引、视图、查询设计
- 数据库表约束设计
- 数据库触发器、存储过程设计
3）数据库实现阶段
- 数据库创建
- 数据模型物理实现
4）数据库测试阶段
- 数据库数据上线
- 数据库系统测试
2.设计策略
- 自底向上设计
- 自顶向下设计
- 自内向外设计
- 混合策略设计
自顶向下分析需求与自底向上设计概念结构：需求分析是自顶向下，概念结构是自底向上
概念模型（CDM）：
CDM是一组严格定义的模型元素的集合，
这些模型元素精确地描述了系统的静态特性、动态特性以及完整性约束条件等，
其中包括了三部分。
① 数据结构表达为实体和属性;
② 数据操作表达为实体中的记录的插入、删除、修改、查询等操作;
③ 完整性约束表达为数据的自身完整性约束（如数据类型、检查、规则等）和数据间的完整性约束（如外键、联系、继承联系等）;
实体联系模型（ERM）：甲方用户要求
概念模型的用途
① 概念模型用于信息世界的建模
② 是现实世界到机器世界的一个中间层次
③ 是数据库设计的有力工具
④ 数据库设计人员和用户之间进行交流的语言
对概念模型的基本要求
① 较强的语义表达能力
② 能够方便、直接地表达应用中的各种语义知识
③ 简单、清晰、易于用户理解
ER模型及基本概念：现实对象
实体(Entity)
概念：一个现实世界中有别于其它对象的对象。
注意：可以是具体的、也可以是抽象的。
示例：某某学生、某某老师、某门课程
属性（Attribute）
概念：实体的特征或性质，即实体用若干属性来描述。
示例： 学生的学号、姓名、生日、年龄、性别、住址等；
课程的课程号、课程名、学时、学分、开课学院等。
分类(按结构)：简单属性(不可再分)复合属性和子属性。
示例：复合—姓名(现用名、曾用名、英文名)；住址(省、
市、区、街道、门牌号、邮政编码)。
域(Domain)：取值范围
概念：属性的取值范围。
按域的取值分：单值、多值、导出和空值(NULL)等属性。
示例：
① 单值属性—性别（每个实体只有唯一确定的值）
② 多值属性—学位值(学士、硕士、博士)；
③ 导出属性—年龄（是出生日期计算出年龄）。
键：唯一标识属性
用于唯一标识集合中的每个实体的一组属性。
示例：学生的学号；课程的课程号；选课的学号及课程号
键的分类(按属性个数)：简单键、复合键。
① 由单个属性构成的键，称为简单键
② 由两个或两个以上属性构成的键，称为复合键
候选键(Candidate Key)：有多种选择作为键的属性或属性集，且属性集的任何属性都不可缺少，如缺少任意属性，就不能成为键。
主键(Primary Key)：当存在多个候选键时，需选定一个作为实体的主键。是描述实体的唯一标识。示例：学生的身份证号、学号等。
实体型（Entity Type）：实体名+属性
概念：用集合来抽象和刻画同类实体称为实体型
示例：学生（学号、姓名、生日、年龄、性别、住址）
实体集（Entity Set）：实体集合
概念：同一类型实体的集合称为实体集
示例：一个学校所有学生构成的集合，称为学生实体集
注意：在不影响理解的情况下，可以将实体、实体型、实体集都简称为实体
实体、属性及标识符的表达：唯一标识
实体类型中的每个实体包含唯一标识它的一个或一组属性，
这些属性称为实体类型的标识符（Identifier），
如“学号”是学生实体类型的标识符，“学号”、“课程号” 共同组成“成绩”实体类型的标识符。
有些实体类型可以有几组属性充当标识符，选定其中一组属性作为实体类型的主标识符，其他的作为次标识符。
主流数据库建模工具Power Designer
Power Designer是一种面向软件开发生命周期的建模工具，它提供软件需求模型、业务流程模型、数据库模型、面向对象模型、自定义模型的开发支持。
Power Designer的数据建模工具特点：
• 功能强大的软件开发生命周期建模工具
• 支 持 目 前 主 流 的 数 据 库 管 理 系 统 （ 如 Oracle 、 SYBASE 、SQL Server、DB2、MySQL、PostgreSQL等）
• 支持目前多种客户端开发工具
• 满足大、中、小型数据库建模设计
Power Designer可建立的数据模型
| 概念数据模型 Conceptual Data Model (CDM) |
从用户角度所建模的系统数据对象及其关系，它帮助用户分析信息系统的数据结构关系 |
| 逻辑数据模型 Logic Data Mode (LDM) |
从系统分析员角度所建模的系统数据对象逻辑结构关系，它帮助开发人员分析信息系统的逻辑数据结构。 |
| 物理数据模型 Physical Data Model (PDM) |
从系统设计人员角度所建模的系统数据物理存储及结构关系，它针对设计者具体定义信息系统的数据库表结构。 |
Power Designer各个数据模型之间的关系
使用PowerDesigner工具进行数据库建模
(1) 创建工程
(2) 创建数据库模型
(3) 创建实体（或实体型）
(3) 给实体命名
(3) 给实体添加属性
(3) 属性添加完成
PowerDesigner创建实体
ER模型及基本概念
联系（Relationship）
概念：反映为。
- 实体内部的联系通常是指组成实体的各属性之间的联系
- 实体之间的联系通常是指不同实体集之间的联系
示例：选课是学生与课程之间的联系。
联系的属性：联系也可有描述属性，记录联系的信息而非实体的信息。
示例：选课的成绩和修课学期；零售的商品数量。
联系的识别：联系由参与的实体唯一确定。
示例：选课(学号、课程号)
两个实体之间可能有多个不同的联系；
一个联系所关联的是同一个实体集中的两个实体
实体间联系的类型
1.一对一联系（one-to-one，1:1）
定义:设联系R关联实体A和B。如果对应A中的每个实体，B中有且仅有一个实体与之关联,则称R是一对 一联系 ，
简记作1 :1联系。
示例：一个班级只有一位班主任,一个班主任只做一个班班主任
2. 一对多联系（one-to-many，1:N）
定义:如果对应A中的每个实体，B中有n个实体(n≥0)与之关联，则称R是一对多联系型，简记作1 :N联系
示例：一个班级中有若干名学生，每个学生只在一个班级学习
3. 多对多联系（many-to-many，M:N）
定义:如果对应A中的每个实体，B中有n个实体(n≥0)与之关联，如果对应B中的每个实体，A中有m个实体(m≥0)与之关联，则称R是多对多联系，简记作M:N联系
示例：一门课程同时有若干个学生选修,一个学生可以同时选修多门课程
(4) 添加联系
(4) 修改联系类型
弱实体(Weak Entities):没有键的实体
前面所讲的实体总存在键。但实际情况中，并不总是如此。
概念：不存在键的实体，称为弱实体。
不同弱实体的属性值可能完全相同，因此，难以区别。
为此，弱实体型需要与一般的实体相关联。
识别实体型与识别联系：弱实体通过关系结合实体识别
假如联系R关联弱实体A和一般实体B，
A的弱实体可以通过与实体B相结合来加以区别，
则B称为弱实体A的识别实体，R称为弱实体A的识别联系。
示例：弱实体和识别联系用粗线条
弱实体(Weak Entities)
① 识别实体与弱实体，该联系即为该弱实体的
② 弱实体型必须识别联系。
③ 部分键（Partial Key）：弱实体的某些属性与识别实体的键共同区分弱实体。这些弱实体属性称为弱实体的部分键。
ER模型描述概念分层
在某些应用中，需要将实体集划分为若干子类，分类后形成层次关系，（Super class），。
示例：研究生和本科生都是学生的子类。
表示：研究生ISA（is a）学生、本科生ISA学生。ISA为这种类层次的联系。
子类属性：除可。
注意：有时还可按其他标准分类，可根据管理的需要来定。
示例：员工分资深员工（Senior Employee）与非资深（Junior）员工。
注意：调整布局的逻辑清晰美观
三、E-R 模型的设计实例
设计一个企业职工管理数据库，主要功能有：
人事管理（人事部门）
工资管理（财务部门）
项目管理（科研部门）
第1步 设计局部 E-R 模型
（1）确定局部范围
可以按部门划分。
（2）确定实体集
人事部门：职工、部门、职务
财务部门：职工、工资
科研部门：职工、项目
（3）确定实体集的属性
人事部门：职工（职工号、姓名、性别、出生日期、工资）
部门（部门号、部门名称、部门电话、负责人）
职务（职务编码、职务名称、职务津贴）
财务部门：职工（职工号、姓名、性别、出生日期、职务）
工资（工资号、基本工资、津贴、保险、实发工资）
科研部门：职工（职工号、姓名、性别、出生日期、职务）
项目（项目号、名称、起始日期、鉴定日期）
（4）确定联系集
人事部门：职工与部门的联系（分工）
职工与职务的联系（担任）
财务部门：职工与工资的联系（领取）
科研部门：职工与项目的联系（参与）
（5）确定联系集的属性
人事部门： 职工与职务的联系有一个属性（任职时间）。
（6）画出各局部的 E-R 模型
人事管理的局部 E-R 模型
人事部门：职工（职工编号、姓名、性别、出生日期、工资）
部门（部门号、部门名称、部门电话、负责人）
职务（职务编码、职务名称、职务津贴）
工资管理的局部 E-R 模型
财务部门：职工（职工号、姓名、性别、出生日期、职务）
工资（工资号、基本工资、津贴、保险、实发工资）
项目管理的局部 E-R 模型
科研部门：职工（职工号、姓名、性别、出生日期、职务）
项目（项目号、名称、起始日期、鉴定日期）
2、组合局部 E-R 模型为全局 E-R 模型
消除各局部E-R模型之间的冲突
① 命名冲突: 包括同名异义或异名同义等。
② 属性冲突: 包括属性的数据类型、取值范围等。
③ 结构冲突
例如：在工资管理中，工资是实体，而在人事管理中，工资却是属性，合并前应去掉该属性。
在人事管理中，职务是实体，而在工资和项目管理中，职务却是属性，合并前应去掉该属性。
确定公共实体
如：职工实体。
有两个重复的属性，
该去掉哪一个？
局部 E-R模型以公共实体为中心，两两合并。
3、消除冗余，优化全局 E-R 模型
（1）实体和联系尽量减少
1 : 1 联系的或具有相同键的两个实体集根据实际情况可以合并。如 职工和工资。
（2）属性尽量减少
去除冗余的属性。
如 工资和职务两个实体都有津贴属性；
工资实体的实发工资属性可以由其他属性计算出来；
（3）实体间的联系没有冗余
改进后 E-R 模型
通过PowerDesigner将概念模型转化为逻辑模型
检查模型的正确性
通过PowerDesigner转化的逻辑模型
通过PowerDesigner转化物理模型
由物理模型生成SQL语句如下，可以copy到文本编辑器
为什么要对关系模式进行优化？
如何对关系模式进行优化？
一、实例-假设有如下表
教师学生关系模式
| Course |
|||||||
假设数据语义: （1）教师可以在不同学期上同一门课程；
（2） 一个教师可为多位学生上课，而一个学生可选多门课程；
（3）同一门课，一个学生在某学期只能选一个教师。
根据上述语义（Tid,Course,Sid,Semester）作为该模式的主键
假设教师、学生、课程信息没有在其它表中存储
上述教师学生模式可能存在的问题
(1) 插入异常(Insert Anomaly)
如果教师新来工作，由于还没排课，学生为空，由于，导致而不能插入教师信息
(2) 删除异常(Delete Anomaly)
① 删除时删掉了其他信息；
② 删除一个元组却删除了多个元组。
(3) 冗余(Redundancy)
表现： ① 某种信息在关系中存储多次；
(4) 更新异常(Update Anomaly)
表现：① 更新一条记录却要求更新多个记录。
解决方案：
除了1:1联系的实体可以包含在一个表中，其它实体应或联系单独建立关系表中。
将上表中的两个实体及联系分解，形成三张关系表
分析为何存在这些问题
数据语义在关系模式中的体现
具体表现：在关系模式的属性间的依赖关系，此即。
数据依赖（Data Dependency）：指通过关系模式。
数据依赖分类
数据依赖决定因素：由现实系统中属性间相互联系的语义决定。
异常现象产生的根源：关系模式中。
根源的体现及解决：一般来讲，。
。如果将各种数据集中于一个模式中，一般都会造成异常。
解决异常的方法，是利用规范化理论，对关系模式进行相应的分解，以消除这些异常。
规范化就是。
规范化的目的是：
优化关系模式，提高数据管理的效率。
三、规范化的几个概念
1、属性的几个概念
（1）简单属性和复合属性:可不可以再分
关系模型只支持简单属性。
（2）单值属性和多值属性
关系模型只支持单值属性。
（3）基本属性和导出属性
如出生日期和年龄；
基本工资、津贴、保险和实发工资，等等。
（4）属性之间的联系
① 1:1
② 1:n
③ m:n
如 学号和联系电话。
如 班号和学号。
如 学号和课程号。
2、键的几个概念
① 单键:由组成的键称为单键。
② 多键:由关系表中的组成的键称为多键。
③ 全键:由关系表中的组成的键称为全键。
3、函数依赖：就是函数的映射关系
函数依赖是属性之间的约束关系。
定义：设X、Y是关系表R的属性（组），
如果对于R的所有元组都有：X的每一具体值都只有一个Y的值与之对应，则称X函数决定Y，或Y函数依赖于X，记作XY。
换句话说，如果知道了X的值，就可以在表中确定与之对应的Y的值（只有一个）。
函数依赖等价定义
假设R是一关系模式，U是R的属性集合，X、Y⊆U，r是R的一个关系实例，元组t∈R。则用t[X]表示元组t在属性集合X上的值。XY表示X和Y的并集。
函数依赖定义：
设R是一个关系模式，U是R的属性集合，X和Y是U的子集。对于R的任意实例r，r中任意两个元组t1和t2，如果t1[X]=t2[X] 则t1[Y]=t2[Y]，那么称X函数地确定Y，或Y函数地依赖于X，记作：X→Y，X称为决定子(Determinant)。
函数依赖关心的问题：
是一个或一组属性的值决定其他属性的值。