第四章数据库的设计实现

4.1 数据库设计概述

任何信息系统都离不开数据库的应用。

有效地分析数据对象组成及其关系，即建立系统数据架构。

系统数据架构

系统数据架构可由概念数据模型、逻辑数据模型和物理数据模型组成。

1.概念数据模型（Conceptual Data Mode,CDM）

是一种将业务系统的内在数据关系映射到信息系统数据实体联系的顶层抽象，同时也是数据库设计人员与用户之间进行交流的数据模型载体。

要求：概念数据模型必须是用户与数据库设计人员都能理解的数据模型，并作为用户与数据库设计者之间的联系纽带。
在概念数据模型中，系统数据被抽象为“实体”，并以模型图形式反映业务领域的数据对象及其关系。

该模型图仅仅反映数据对象的联系，而不定义这些数据对象在数据库系统中如何表示。

2.逻辑数据模型

概念数据模型在系统设计角度的延伸

对象依然体现为“实体”和“联系”等形式，但考虑逻辑表示。

3.物理数据模型

即具体设计实现

考虑实体如何转换为数据库表

各层次

无论是哪个数据模型，它们都应满足数据库设计模型的3个基本原则：①真实
地模拟现实世界的数据关系；②数据模型形式容易被用户理解；③数据模型便于在计算机上实现。

单一层次的数据模型难以同时满足这3个方面要求。因此，在数据库设计中，我们需要分层次进行建模设计。

4.1.2数据库设计过程与策略

1.数据库设计过程

2.数据库设计策略

数据库设计是为适应组织机构的信息数据处理需求和支持组织机构的业务数据管理而设计数据库方案及其数据模
型的过程。数据库设计的目的是为数据库应用系统的实现提供设计蓝图。通常可采取如下数据库设计策略。

（1）自底向上策略

设计人员首先具体分析各业务数据需求，并抽象各业务的数据实体及其关系，然后设计各个业务的数据模型。在
设计过程中，设计人员要不断地概括、分类与规范数据模型，并建立反映整个组织的全局数据模型。自底向上数据库
设计策略比较适合于组织机构规模较小、业务数据关系较简单的数据库设计，而不太适合于具有大量业务机构、业务
数据关系错综复杂的数据库设计。

（2）自顶向下策略

设计人员首先从组织机构全局角度，规划设计组织机构顶层的数据模型，然后分别对各部门所涉及的业务数据进
行实体联系建模。

自顶向下数据库设计策略适合于组织机构规模较大、业务数据关系错综复杂的数据库建模设计，但该设计策略的实施有较大挑战性，系统设计人员在项目初始阶段从
全局规划设计数据模型是有难度的。

（3）由内至外策略

设计人员首先确定组织机构的核心业务，对核心业务数据进行建模设计，然后逐步扩展到其他外围业务的数据模
型设计。

是自底向上策略的特例，它首先确定关键业务的数据模型，然后向外扩展考虑相关业务的数据模型。

（4）混合设计策略

混合设计策略即融合以上设计策略对系统数据库进行建模设计，同时应用多种设计策略进行系统数据建模，可避
免单一设计策略导致的数据库建模设计局限。

例如，在针对大型组织机构的复杂数据建模设计中，首先可采用自顶向下策略分割业务数据范围，每个业务建立一个数据模型，然后在每个业务数据模型设计中采用自底向上策略，最后解决各业务数据模型之间的实体冲突、实体共享、实体冗余等问题。

4.1.3 数据库建模设计工具

1.PowerDesigner建模工具

PowerDsigner下载

可以构建系统数据流程图、概念数据模型、逻辑数据模型、物理数据模型，并可将设计模型转化为各类典型的DBMS数据库对象，创建SQL脚本程序，还可为数据仓库设计结构模型，也能对团队设计模型进行版本控制。

2.ERwin建模工具

ERwin是数据库设计工具，同时也是一个功能强大的数据库开发工具，能为所有主流的数据库自动生成数据库表、
视图、存储过程和触发器等对象创建代码。ERwin同样可支持以数据为中心的应用开发。

4.2 E-R模型

E-R模型是“实体-联系模型（Entity-Relationship Model）”的简称。

它是用于构建描述现实世界的概念数据模型、逻辑数据模型

在系统E-R模型设计中，其有各种模型图像，本书采用Crow Feet表示法给出E-R模型元素符号。

模型基本元素

E-R 内含3种基本元素：实体、属性、联系

1.实体

实体（Entity）是对现实世界中描述事物数据对象的抽象概念。

实体可以是人，如“客户”“读者”“经理”等；也可以是物品，如“图书”“商品”“设备”等；凡是包含数据特征的对象均可被定义为实体。

表示方法

在E-R模型图中，实体符号通常使用两层矩形方框表示，并在顶层方框内注明实体的名称。

建议实体名在概念模型设计阶段使用中文表示，而在物理模型设计阶段转换成英文名形式，这样既便于设计人员与用户进行建模交流，也便于编程人员对设计模型进行开发实现。

2.属性

就是描述实体的一组数据特征，这些描述实体的数据特征。

例如，“客户”实体具有客户编号、客户姓名、性别、手机等属性。

表示方法

在E-R模型实体符号的两栏矩形框中，上栏区域显示实体名称，下栏区域显示实体属性。

标识符与复合标识符

标识符：在实体中，能够唯一标识不同实体实例的属性或属性集被称为标识符。用下划线标出。

复合标识符：如果实体中找不到任何单个属性可以做标识符，就必须选取多个属性的组合作为标识符，此时该标识符被称为复合标识符。【构成该复合标识符的所有属性都需加上下划线】

3.实体间的联系

带有形似鸟脚的连线符号表示实体之间的联系，并在线上标记名称以表示联系的行为语义，一般用动词来命名关系，如“管理”“查看”“订购”等。

元

实体之间关联的数目被称为元。

实体自己与自己之间的联系被称为一元联系，也被称为递归联系
- 例如，“员工”实体之间存在上下级管理关系
两个实体之间的联系被称为二元联系。

实体联系类型

实体联系类型指实体之间不同联系的形式。

在E-R模型中，实体联系可以分类为：多重性、参与性、继承性

1.多重性分类

实体联系多重性指一个实体实例与另一个关联实体实例的数目对应关系。

例如，二元实体联系类型按照多重性可以分为如下3种联系。

（1）一对一联系 1:1

例如，一个学生只能办理一个学生证，而一个学生证也只能对应于一个学生

（2）一对多联系 1:N

例如，一个班级有多名班级干部，而一个班级干部只能隶属于一个班级

（3）多对多联系 M:N

例如，一名教师可以讲授多门课程，一门课程也可以由多名教师讲授

2.参与性分类

可选的联系
强制的联系

实体联系的基数范围可用[min,max]形式。如果最小基数为0，则表示联系中的实体参与是可选的。如果最小基数为1，则表示联系中的实体参与是强制性的。

例如，学校规定每个人必修课必须修1到3门；每门课程最少要有10个人选，最多不能超过120人。

则在“学生”“课程”实体的联系约束，“学生”实体的基数范围是[10,120],“课程”实体的基数范围是[1,3]。

3.继承性分类

继承联系用于表示实体之间的相似性关系。区分两个实体：

一端是具有公共属性的实体，被称为父实体；
另一端是与父实体具有相似属性，被称为子实体。

强弱实体

强实体
弱实体

一个实体的存在必须以另一个实体的存在为前提，前者就被称为弱实体，而被依赖的实体被称为强实体。

【例】在“学生”“学校”实体联系中，“学生”实体必须依赖于“学校”实体而存在。

因此，在该实体联系中，“学生”为弱实体，“学校”为强实体

一个实体既可能是弱实体，又可能是强实体

【例】“学生”实体必须依赖于“学校”实体而存在，其中“学生”实体为弱实体；不过“成绩表”实体作为弱实体又依赖于“学生”实体，这时“学生”又为强实体

标识符依赖实体

标识符（ID）依赖弱实体
非标识符依赖弱实体
根据弱实体在语义上对强实体依赖程度的不同，

符号不同

对标识符（ID）依赖弱实体的联系连线图形符号，在弱实体一侧有一个三角形的符号，如图4-14所示。
对非标识符（ID）依赖弱实体的联系连线图形符号，在弱实体一侧仅为基本鸟足符号，如图4-15所示。

1.标识符（ID）依赖弱实体

如果弱实体的标识符含有所依赖实体的标识符，则该弱实体被称为标识符（ID）依赖弱实体。

在图4-14中，“成绩表”实体是弱实体。同时，“成绩表”实体的标识符分别取决于“学生”“课程”实体的标识符

2.非标识符（ID）依赖弱实体

例如，在图4-15所示的“客户”“订单”“商品”实体联系中，“订单”实体在语义上依赖于“客户”“商品”实体而存在。但“订单”有自己的标识符，也就是自己的订单编号

4.2.5 图书馆业务系统E-R模型图

4.3数据库建模设计

由4.1节可知，数据库设计分为概念设计、逻辑设计和物理设计3个阶段，

设计人员在各个阶段分别进行概念数据模型设计、逻辑数据模型设计和物理数据模型设计。

概念数据模型设计（CDM）

采用E-R模型描述系统的数据对象组成结构

1.抽取与标识实体

【例】针对一个图书销售管理系统数据需求，我们可以抽取出“图书”“商店”“销售”“折扣”“作者”“出版社”实体

2.分析与标识实体联系

【例】分析各种实体之间的联系，给出该联系的名称

3.定义实体属性与标识符

给出属性名称、给出标识符、取值约束等说明；

【可选项：定义属性值域，以限定属性的取值范围、属性是否允许空值、属性的默认值、属性值检查规则等。】

4.检查与完善概念数据模型

一个较大规模系统或复杂系统的概念数据模型设计不可能一步完成，需要不断完善

【例】对图书销售管理系统E-R模型，我们增加“库存”实体，并与“图书”“商店”实体建立联系。又增加“图书类别”实体，并将它与“图书”实体建立联系。

逻辑数据模型设计（LDM）

是概念数据模型在系统设计角度的延伸，它使系统的E-R模型图体现数据库模型的针对性【规范化】

逻辑数据模型与概念数据模型的主要区别如下。

（1）逻辑数据模型比概念数据模型对信息系统数据结构的描述更具体，不但有业务实体，也有新增的、便于信息化处理的数据实体。

（2）逻辑数据模型将概念数据模型的多对多实体联系转化为易于关系数据库实现的一对多实体联系。

（3）逻辑数据模型将概念数据模型中的标识符依赖实体进一步细化，并区分主键标识符和外键标识符，以便于数据模型规范化处理。

1.CDM/LDM转换

【例】图书销售管理系统概念数据模型转换为逻辑数据模型

属性定义加强，如在每个实体中分别标识主键标识符及外键标识符。
将CDM中存在的实体间多对多联系，转换为通过关联实体与原实体之间的一对多联系
- （如“编著”实体）在（“作者”“图书”）之间，直接转换为一对多

2.规范化与完善逻辑数据模型设计

使达到3NF范式，即实体中非键属性仅依赖于主键属性。

【例】通过分析图4-21所示的图书销售管理系统逻辑数据模型

1、“作者”实体不符合关系数据库设计规范的3NF范式，其中的“省”“城市”属性存在传递依赖。
2、新引入的关联实体“编著”的名称不太确切，其属性仅仅只有所依赖实体的标识符，缺少自身属性。

完善设计

1、增加“地区表”实体，并将它与“作者”实体建立联系，同时删除“作者”实体中的“省”“城市”属性，从而在“作者”关系表中可通过地区编码方式实现一致的地区名称输入。
2、修订关联实体“编著”名称为“编著排名”，并增加“排位顺序”属性，从而使该实体数据具有实际意义。

物理数据模型设计

不再使用E-R图来描述数据模型结构，而需要考虑将实体如何转换为数据库表

设计步骤

（1）将E-R模型图中每一个实体对应转换成一个关系表，实体属性转换为对应表的列，实体标识符转换为对应表的主键。

（2）将实体联系转换为关系表之间的主、外键关系，并定义表之间的参照完整性约束。

（3）完善系统的关系模型图，并在模型中扩展定义视图、索引、存储过程及触发器等数据库对象。

1.实体到关系表的转换

首先为每个实体定义一个关系表，其表名与实体名相同；

属性----表中的列
标识符----表中的键
主键标识符----主键
外键----外键
代理键设置【可选】
- 当关系表中的候选键都不适合当主键时（例如，候选键的数据类型为复杂数据或者候选键由多个属性组成），就可以使用代理键作为主键。
列特性设置【可选】
- 我们在将实体的属性转换为关系表的列时，必须为每个列定义特性，包括数据类型、空值状态、默认值及取值约束。【需要注意的是，只有设置了not null标注，才可以设置默认值】

【例】

2.弱实体到关系表的转换

前面描述的实体转换为关系表的方式适用于E-R模型的所有实体类型，但弱实体转换关系表还需要特别的处理。

当弱实体为非标识符依赖于一个强实体时，我们应在弱实体转换的关系表中加入强实体标识符作为外键列；
而当实体为标识符依赖于一个强实体时，我们不但应在弱实体转换的关系表中加入强实体标识符作为外键列，同时也作为该表的主键列。

【例：非标识符依赖的转换】图中的“销售订单”实体在逻辑上依赖于“销售员”实体。它们之间的实体联系为一对多。

“销售订单”实体是非标识符依赖弱实体，因为它有自己独立的标识符“订单编号”。

【例：标识符依赖的转换】标识符依赖的强实体标识符不但在“订单明细”关系表中作为主键，同时也作为外键，并与订单明细实体的标识符“订单明细编号”共同构成复合主键

3.实体联系的转换

（1）1:1实体联系的转换

实体分别转换为关系表，将其中一个表的主键放入另一个表中作为外键。

【例4-11】在图4-28所示的E-R模型中，“学生”实体与“助研金发放账号”实体存在1:1实体联系。

这里有两种方法，如图a、图b所示

（2）1:N实体联系的转换【最常见】

实体分别转换为关系表，并将1端关系表的主键放入N端关系表中作为外键。

【例】在图4-30所示的E-R模型中，“班级”实体与“学生”实体存在1:N实体联系。

转换后，将一个“班级”关系表的主键放入“学生”关系表中作为外键，如图4-31所示。

（3）M:N实体联系的转换

M:N实体联系不能像表示1:1和1:N实体联系那样直接转换关系表。
除了关联的实体均转换为对应的关系表外，我们还增加一个关系表，作为关联表与实体的关系表建立参照约束。
将任意一个实体关系表的主键放置到另一个实体关系表中作为外键，均是不正确的。

【例4-13】“课程”实体与“学生”实体存在M:N联系。

增加一个关联表，并命名为联系名
新增的关联表共有两个列，分别来自“学生”表的主键和“课程”表的主键。这两个列构成关联表的复合主键，同时它们也是外键。
在使用关联表时，我们还必须对该表的属性列进行完善，不能只有已知的两个主键对吧，如增加“成绩”列。

（4）实体继承联系的转换

实体继承联系用来描述实体之间的相似性关系。

当E-R模型转换到关系模型时，父表属性应放到子表中作为外键。

【例】在图4-34所示的E-R模型中，“本科生”“研究生”实体与“学生”实体存在分类继承联系。

方法1：

只把父表的主键加入子表中作主键、外键。“研究生”“本科生”它们公共的属性放置在“学生”关系表内。
这种转换方案可以减少表之间的冗余数据，但进行学生信息查询时，需关联父表和子表才能完成。

方法2：

父表的主键放入子表中既作为主键又作为外键，并把父表中所有能容添加到子表中。
这种方案存在表间数据冗余，但针对本科生或研究生的信息查询只需要在子表中完成，效率较高。

（5）实体递归联系的转换

递归联系是同一类实体之间所发生的联系。
在表中加入另一个外键属性参照本表主键属性。
当将M:N的实体递归联系转换为关系模型时，我们需要增加关联表来参照约束原实体关系表。

情况1:N

【例】在图4-37所示的E-R模型中，“顾客”实体为递归实体，该递归实体之间为1:N实体联系。

该E-R模型描述了“顾客”实体之间存在的1:N递归联系，即每个顾客都可以推荐N个新客户，每个客户只能被一个人推荐
对仅有的这个实体转换为关系表，并在该关系表中增加一个外键，其值参照约束于主键。

情况M:N

【例】在图4-39所示的E-R模型中，“医生”实体为递归实体，该递归实体之间为M:N实体联系。

医生相互治疗
对医生实体转化为关系表，并由联系派生出“治疗”表
递归关系两端是同一张表，因此我们将医生表的主键加入派生表两次，以构成复合主键【列名要唯一】

一个E-R模型转换到关系模型的整体系统物理数据模型设计。

4.4 数据库规范化设计

数据库规范化设计是在数据库中采用合理的数据结构组织与存储数据、减少数据冗余、实现数据完整性与一致性的设计活动。

数据冗余

指一组数据重复出现在数据库的多个表中。

意味着会占用更多的存储空间，同时也带来保持数据一致性的维护成本。

规范化数据库设计为数据库系统带来如下好处。

（1）冗余数据被减少

（2）设计合理的表间依赖关系和约束关系，便于实现数据完整性和一致性。

（3）设计合理的数据库结构，便于系统对数据库的高性能访问处理。

数据库规范化技术的本质是分析数据属性之间的依赖关系，使用一定的范式规则确定数据属性的组合，从而实现尽力减少冗余数据、实现数据完整性与一致性的数据库设计目标。

非规范化关系表的问题

为了说明数据库规范化设计的必要性，这里将分析一个非规范化关系表在进行数据访问操作中存在的各类问题。

【例】要对机构人员信息管理，设计了一个“雇员”关系表在对“雇员”关系表的数据进行插入、删除、修改时，有可能出现如下问题。

在关系数据库设计中，要想避免以上数据库操作问题，就必须消除关系表中存在的多个主题数据及冗余数据，同时还需要确保数据一致性、数据完整性，这就是数据库规范化设计需要解决的基本问题。

1.插入数据异常

信息必须输入正确，否则就会导致与已有部门信息不一致问题。

例如，新入职的雇员“李青”被分配到“产品部”。当在“雇员”关系表中插入雇员“李青”的信息时，必须正确输入所属部门“产品部”、部门地址“D 区1栋”。所属部门填错了

Insert Into Employee Values(‘E0015’,‘李青’,‘工程师’，8500,‘产品部’,‘E区3栋’)；

此外，还可能出现另一种插入数据异常：【有部门了但还没有编号】

当公司增加一个部门（如售后部），其部门信息需要插入到“雇员”关系表进行存储，但此时由于该部门还没有雇员，“雇员编码”作为主键，其值不允许为空，因此，无法将带有空值的雇员数据及新增部门数据在关系表中插入。

2.删除数据异常

例如，从表中，删除雇员编号为“E0005”的元组数据后，“质检部”信息就再也没有了

3.修改数据异常

例如，在“雇员”关系表中，修改“财务部”地址为新地址“A幢201”。必须对关系表所有元组进行修改为“A幢201”。

结论:不规范的关系表可能存在数据冗余，引出数据访问操作异常现象，难以使数据库保持数据的一致性

函数依赖理论

平凡函数依赖
部分函数依赖
传递函数依赖
多值依赖

函数依赖是关系中一个属性或属性集与另外一个属性或属性集之间的依赖，亦即属性或属性集之间的约束。在关系数据库规范化设计中，我们用函数依赖理论来描述一个关系表中属性（列）之间在语义上的联系。

规范化设计范式

关系规范化是一种基于函数依赖理论

将一个有异常数据操作的关系分解成更小的、结构良好的关系，使该关系有最小的冗余或没有冗余。

规范化范式（Normal Forma,NF）是关系表符合特定规范化程度的模式。

规范化范式的种类与函数依赖有着直接的联系。

在关系中存在函数依赖时就有可能存在数据冗余，引出数据操作异常现象。

关系数据库的规范化有6种范式：

【在数据库应用中，一般只需满足第三范式（3NF）或巴斯-科德范式（BCNF）就足够】

第一范式（1NF）【最低要求】
第二范式（2NF）
第三范式（3NF）
巴斯-科德范式（BCNF）
第四范式（4NF）
第五范式（5NF）

1.第一范式

若不是第一范式：在关系数据库中，第一范式（1NF）是对关系表的基本要求，不满足第一范式的二维表不是关系。
第一范式是什么：关系表的属性列不能重复，并且每个属性列都是不可分割的基本数据项。
怎样解决：对关系进行分解处理，直到分解后的每个关系都满足规范化为止。

【例】学生关系表中的“联系方式”不明确，用户可以填写电话数据，也可以填写邮箱数据，即该属性列可以再细分“电话”“电子邮件”等。

必须对“联系方式”属性列进行拆分处理。

2.第二范式

如果关系满足第一范式，并消除了关系中的属性部分函数依赖，该关系满足第二范式。
第二范式规则要求关系表中所有数据都要和该关系表的主键有完全函数依赖。
怎样判断：如果一个关系中某些属性数据只和主键的一部分存在依赖关系，该关系就不符合第二范式。
怎样解决：必须为那些部分依赖表主键的属性创建单独的关系表。

【例】在上一个图所示的“学生”关系表中，其主键为复合键(学号，课程号)，考察非键属性与主键的依赖关系。

主键（学号，课程号），但是（学号）→系名，（学号）→住址，（学号）→电话，（学号）→电子邮件，

存在部分函数依赖，就是有一些属性只依赖于复合键中的一个键，（复合键里的另一个键：你都全包了我来做啥？）

3.第三范式

第三范式（3NF）要求关系先满足2NF范式，并且所有非主键属性均不存在传递函数依赖。

【例】学生表Student(学号，姓名, 年龄，性别，系别，系办地址、系办电话)，关键字为单一关键字"学号"

存在如下决定关系：

（学号）→ (姓名, 年龄，性别，学院，学院地址、学院电话)

但是还存在下面的决定关系

(学号) → (所在学院)→(学院地点, 学院电话)

所以存在传递函数依赖【它也会存在数据冗余、更新异常、插入异常和删除异常的情况。】

(学号) → (学院地点, 学院电话)

解决办法：根据第三范式把学生关系表分为如下两个表就可以满足第三范式了：

学生：(学号, 姓名, 年龄, 性别，学院)；

学院：(学院, 学院地址、学院电话)。

4.巴斯-科德范式【BCNF范式】

一个关系即使满足第三范式，也仍然有可能存在一些会引起数据冗余的属性依赖。因此，需要进一步将关系规范化提升到更高程度的范式，即巴斯-科德（Boyce-Codd）范式

该范式是在3NF范式基础上，要求关系中所有函数依赖的决定因子必须是候选键。

【例】在图4-45所示的“学生”“系信息”“课程成绩”关系表中，所有属性之间的函数依赖决定因子均是该关系的主键，因此，它们均满足BCNF范式。

逆规范化处理

数据库规范化可以最大限度地减少数据冗余，并确保数据完整性与一致性，但规范化也会因多表关联查询导致数据库的性能降低

因此，在数据库规范化设计时要平衡两者的关系。即允许数据库有一定的数据冗余性，即逆规范化处理。

逆规范化处理的基本方法：

（1）增加冗余列或派生列

（2）多个关系表合并为一个关系表

逆规范化处理的问题

（1）存在冗余数据

（2）降低数据库完整性

（3）降低数据库更新操作的性能

数据库设计原则

（1）第三范式或BCNF范式就足以达到规范化设计需求。

（2）不要把数据库的规范化设计与逆规范化设计对立起来

（3）对联机分析处理类型数据库应用，采用低程度规范化的星形模式或雪花模式设计数据库，采用较高程度的规范化设计数据库。

4.5 数据库设计模型的SQL实现

完成数据库设计方案后，我们就可以在选定的DBMS中实现数据库及其对象。

具体到关系型DBMS，需要创建数据库、数据库表、索引、视图、存储过程、触发器等对象。

确定数据库设计的实现方式

在DBMS中实现数据库的方式有如下两种。

1.GUI方式创建数据库，直观。当需要创建的数据库对象很多时，很耗时，其效率低

2.执行SQL脚本程序创建数据库，高效、快速。

posted @ 2022-04-18 20:33 Dinesaw 阅读(692) 评论(0) 编辑收藏举报

刷新页面返回顶部

Dinesaw

第四章 数据库的设计实现