数据库设计与 ER 模型 - 数据库系统原理

标签：不同   业务   需求   可行性   数据模型   分析   原理   多对多   数据   

数据库系统生存周期

       数据库应用系统的开发是一项软件工程，一般具有信息的采集、组织、加工、抽取、综合、传播等功能，但又有自己的特点，所以称为 数据库工程。

       数据库应用系统从开始规划、设计、实现、维护到最后被新的系统取代而停止使用的整个周期，称为 数据库系统生存期。

       数据库系统生存期一般可划分成下面七个阶段：

       （1）规划：是数据库系统生存周期的第一步。在规划阶段需要做的工作是：通过了解用户的实际需求，明确该系统需要实现的目标和任务，确定数据库系统的总目标。

               规划阶段需要做的工作有：

                  a. 系统的调查。

                  b. 可行性分析。

                  c. 确定数据库系统的总目标，并对应用单位的工作流程进行优化和制定项目开发计划。

       （2）需求分析：准确了解、分析用户需求。

               需求分析阶段需要做的工作有：

                  a. 分析用户活动，产生业务流程图。

                  b. 确定系统范围，产生系统关联图。

                  c. 分析用户活动涉及的数据，产生数据流图。

                  d. 分析系统数据，产生数据字典。

       （3）概念设计：概念结构设计是数据库设计最重要的阶段，通过对用户需求进行综合，归纳和抽象，形成一个独立于具体 DBMS 的概念模型。

               概念设计的主要步骤分三步完成：

                  a. 进行数据抽象，设计局部概念模型。

                  b. 将局部概念模型综合成全局概念模型。

                  c. 评审。

       （4）逻辑设计：将概念结构设计转换为某个 DBMS 支持的数据模型。

       （5）物理设计：为逻辑结构模型选择一个合适于应用的物理结构。

       （6）数据库的实现：运用 DBMS 提供的数据库语言及宿主语言，根据逻辑设计和物理设计的结果建立数据库，开发应用程序，并试运行。

       （7）数据库运行和维护：在数据库系统运行过程中，搜集系统运行的数据来评价系统性能，进一步对系统进行调整和修改。

ER 模型的基本概念

• ER 模型

       ER 模型是人们认识客观世界的一种方法、工具。ER 模型的基本元素是实体、联系和属性。ER 模型就是利用实体及其之间的联系来描述事物，一个联系可能涉及多个实体，它所涉及的实体集个数称为该联系的元数，ER 模型中用联系类型的约束来限制参与联系的实体的数目。

       ER 模型的设计过程基本上是两大步：

1. 先设计实体类型。（此时不要涉及“联系”）
2. 再设计联系类型。（考虑实体间的联系）

       具体设计时，有时“实体”与“联系”两者之间的界限是模糊的。数据库设计者的任务就是要把现实世界中的数据以及数据间的联系抽象出来，用“实体”与“联系”来表示。

• 采用 ER 模型的数据库概念设计

       采用 ER 模型进行数据库概念设计分为三步进行：

       （1）设计局部 ER 模型。

               a. 确定局部结构范围。

               b. 定义实体。

               c. 定义联系。

               b. 属性分配。

       （2）设计全局 ER 模型。

               a. 确定公共实体类型。

               b. 局部 ER 模型的合并。

               c. 消除冲突。

       （3）全局 ER 模型的优化。

               a. 合并实体类型。

               b. 消除冗余属性。

               c. 消除冗余联系。

关系模型的基本概念

       用二维表格结构表示实体集，用关键码表示实体间联系的数据模型，称为 关系模型。

• 关系模型的基本术语

       基本术语有：字段（属性）、字段值（属性值）、记录（元组）、二维表格（元组集合、关系或实例），括号中的表述为关系模型中的术语。

       关系中属性的个数称为 元数，元组的个数称为 基数。

       键：由一个或几个属性组成。（注意，键不一定是唯一的一个属性）

       超键：在关系中能唯一标识元组的属性集。（注意，超键也是一个属性集，不一定只是一个属性）

       候选键：不含有多余属性的超键。

       主键：用户选作元组标识的一个候选键。

       外键：与某个关系的主键相应的属性在另一个关系中出现，此时，该主键就是另一关系的外键。如有两个关系 S 和 SC，其中 S# 是关系 S 的主键，S# 也在关系 SC 中出现，此时 S# 就是关系 SC 的外键。

• 关系模型的三类完整性规则

1. 实体完整性规则：要求关系中元组在组成主键的属性上不能有空值。
2. 参照完整性规则：要求不能引用不存在的实体。
3. 用户定义完整性规则：由具体应用环境决定，系统提供定义和检验这类完整性的机制。

ER 模型到关系模型的转换规则

       关系数据库的逻辑设计的结果是一组关系模式的定义，由于关系模型的固有优点，逻辑设计把概念设计的结果（即全局 ER 模型）转换成初始关系模式集，使设计过程形式化的进行，并且结果可以验证。

       ER 模型的主要成分是实体类型和联系类型，转换算法就是如何把实体类型、联系类型转换成关系模式。

       对于实体类型，可以这样转换：将每个实体类型转换成一个关系模式，实体的属性即为关系模式的属性，实体标识符即为关系模式的键。

       对于联系类型，要根据不同的情况做不同的处理。转换的规则是：

1. 如果实体间的联系是一对一的联系，将一个关系的键作为外键放在另一个关系中。
2. 如果实体间的联系是一对多的联系，则将“一”端的关系的键作为外键放在“多”端的关系中。
3. 如果实体间的联系是多对多的联系，则将联系类型也单独转换成一个关系，该关系称为交叉关系。这个关系的键由与联系相关联的实体的键组合而成，联系的属性成为这个交叉关系的属性。

ER 模型实例分析

       假设要建立一个企业数据库，该企业有多个下属单位，每一单位有多个职工，一个职工仅隶属于一个单位，且一个职工仅在一个工程中工作，但一个工程中有很多职工参加工作，有多个供应商为各个工程供应不同设备。（这种语句就是典型的三元联系类型 M：N：P）

       单位的属性有：单位名、电话。

       职工的属性有：职工号、姓名、性别。

       设备的属性有：设备号、设备名、产地。

       供应商属性有：姓名、电话。

       工程的属性有：工程名、地点。

       请完成如下处理：

1. 设计满足上述要求的 ER 图。
2. 将该 ER 图转换为等价的关系模式。
3. 根据你的理解，用下划线标明每个关系中的主键。

       （1）满足要求的 ER 图如下（实体属性用椭圆形画出，这里略…）：

       （2）转换后的关系模式和主键如下（红色表示有下划线的主键，紫色表示有波浪线的外键，破折号表示联合住建，第6小项就是联合主键又分别是其余3个关系的外键）：

1. 单位（单位名、电话）
2. 职工（职工号、姓名、性别、单位名、工程名）
3. 工程（工程名、地点）
4. 供应商（姓名、电话）
5. 设备（设备号、设备名、产地）
6. 供应关系（工程名-设备号-供应商姓名、数量）  注：此处的“数量”属性是根据题意推测出来的。

增强的 ER 模型

• 弱实体与强实体

       一个实体对于另一个实体（称为强实体）具有很强的依赖关系，而且该实体主键的一部分或全部从其强实体中获得。则称该实体为弱实体。用双线矩形框表示。

• 子类和超类的定义

       当较低层次上实体类型表达了与之联系的较高层上的实体类型的特殊情况时，就称较高层上实体类型为超类型，较低层上实体类型为子类型。子类继承超类的全部属性。

TEST

1. 为什么关系中的元组没有先后顺序？且不允许有重复元组？

（1）关系就是元组的集合，而集合不考虑元组的先后顺序问题。（2）关系中每个元组一定会有属性标识符用来区分每一个元组，属性值是不同的，所以不会出现完全一样的元组，从集合论的观点来看，也不会出现重复元素。

数据库设计与 ER 模型 - 数据库系统原理

标签：不同   业务   需求   可行性   数据模型   分析   原理   多对多   数据   

原文地址：http://www.cnblogs.com/SkySoot/p/6237210.html