数据库(1)---数据库需求与ER建模

【声明】本文章来自穆晨 - 博客园，记录于此方便后期的学习和查阅

一、前言

在数据库建设过程中，哪一步最重要？绝大多数资料会告诉你，是需求分析阶段。这一步的好坏甚至直接决定数据库项目的成败。

需求分析阶段，也被称为ER建模(entity-relationship modeling)阶段，也常被称为需求可视化、概念建模等。这一阶段数据库系统开发人员将协同需求方以ER图的方式对业务需求进行可视化展现。

本文将详细介绍(陈氏)ER符号体系，并在其中穿插一些具体的实例进行讲解。

二、基本概念

1. 实体(entity)

实体表示客观世界中的众多概念，比如：人，地点，事件等。

每个实体本身包含多个实体成员，比如实体人可能包含张三、李四、王五等。

在ER图中，实体通常用矩形表示，如下所示：

2. 属性(attribute)

每个实体都有属性，用椭圆表示属性，描述实体各个特征。 比如顾客的特征可能有顾客标识符，顾客姓名，顾客性别，顾客年龄等，如下图所示：

此外，每个实体至少要有一个唯一属性，用下划线标记，如上图中的id字段。

3. 联系(relation)

实体与实体之间通常具有某种关联，在ER图中用菱形表示。比如某职员向某主管汇报，如下图所示：

细心的读者想必发现了，实体间连线的两端，写有一些符号。这些符号被称为基数约束(cardinality constraint)，用来表示实体可以有多少实例与另一实体的实例存在联系，共有四种形态。

形态一：表示一个实体A对应多个实体B，即强制多个对应。 形态二：表示一个实体A对应0个或多个实体B，即可选多个对应。 形态三：表示一个实体A对应一个实体B，即强制单个对应。 形态四，表示一个实体A对应0个或1个实体B，即可选单个对应。 联系是双向的，所以在实际ER建模中，常见的版本如图，表示：实体A对应0个或1个实体B；实体B对应一个或多个实体A。

三、建模规则

1. 复合属性(composite attribute)

部分属性具有复合的特点，比如地址属性，可能包含了省份，城市，街道等子属性。

ER图上这类属性的属性名，应当用圆括号括起来，然后扩展为多个子属性。可参考下面这个商店实体定义：

2. 多值属性(multivalued attribute)

部分属性具有多值的特点，比如一个职工可能有多个电话号码。

ER图上这类属性用双层椭圆标识，可参考下面这个职工实体定义：

3. 派生属性(derives attribute)

部分属性可从其他属性或者其他数据派生出来，这类属性在ER图上用虚线椭圆标识。

可参考下面这个士多店实体定义，其中的YearsInBusiness属性表示店铺开张了多少年，这个属性可以结合当前日期与OpeningDate属性算到，因此用虚线椭圆标识。

4. 可选属性(optional attribute)

部分属性可能没有取值，比如说职工奖金。ER图上这类属性通过在属性名后面添加(0)标识，可参考下面这个职工实体定义：

5. 联系的进一步描述

• 可以在联系中表明联系中的最大最小基数。如下例子，每个学生具体对应到了2-6间教室；同时每间教室对应到了5-40名学生。
• 可以在联系中说明联系中的角色，这在一元联系中尤为常见，如下例子中，每个人只能送给其他人一份礼物，但可以收到0或多份礼物。

6. 关联实体(associated entity)

关联实体是描述 M : N 联系的另一种方式，用一个内部有菱形的矩形表示。它没有唯一属性，也没有部分唯一属性，通常来说没有任何属性。主要用于多元联系的场景。如下两个图是等价的：

7. 弱实体(week entity)

通常来说，实体至少要有一个唯一属性。因为这样才能精确定位到需要处理的记录。但在ER建模这一层，也并非总是如此。

举例来说，假如现在需要为某个连锁酒店管理系统进行ER建模。该公司在全国各地都开有酒店。现在需要记录各地酒店的房间使用情况。

可以将房间的使用情况，作为酒店管理系统建模的一个多值复合属性，如下图所示：

这样做并没有不对，但是却没有体现出各RoomID在各Building内的唯一性。同时，很多时候需要将房间实体化后，与其他实体相联系。比如每个房间对应的清洁工。

引入弱实体机制后，便可顺利解决这两个问题。如下图所示：

需要注意：1）弱实体的“主码”称为部分码，码名下方用虚线标记；2）弱实体必须至少有一个属主实体，它们之间的联系需用双框菱形标识；3）弱实体部分码同其属主实体候选码的组合，可以唯一定位到任何一个弱实体记录。

四、高级话题

1. 相同实体之间具有多个 M:N 关系

为学生选课系统进行ER建模，得到如下结果。如果需求中要求一个同学一门课只能选一次，这样的设计没问题。如果需求中说明，一个同学可以选一门课几次(可能是挂了好几次)，那这样的设计就有问题了。 正确的做法之一：使用有两个属主实体的弱实体，如下图所示： 另一个正确的做法：为每次预定生成一个唯一的id，如下图所示：

2. 三元(或更多)关系

在ER图中，联系一般是将两个实体关联起来，或者自己关联自己。但也有时候，需要同时将多个实体联系起来。这怎么办呢？要知道表示联系的菱形有且只有两个接口。

可以使用关联实体。如下ER图，使用了关联实体描述了某工厂的供货商，生产产品，零件三方联系： 如果需要给关联增加某些属性，比如说供货商每次提供的货物量，上述ER图就不能用了。因为它没办法区分同一家供应商为同一产品提供等数量的同一零件的不同实例了。解决办法：把关联实体改成一般的实体，并增设一个唯一标识符：

五、其它说明

1. 本文实体名全大写，属性和关系名则用首字母大写的驼峰法，同时尽量保证所有命名都全局唯一；

2. 用户的更多个性需求应当以注释，标签等方式一并标记在ER图中；

3. 建模工具可以使用PowerDesigner、Workbench等。为您推荐一款轻量级的在线数据库建模工具。

4. 需求分析、ER建模是贯穿整个数据库生命周期的工作。这部分工作要求开发人员和业务方，数据库的使用者，公司领导等方面协同好需求，并将需求以ER图的模式可视化展现出来。

5. 只有绘制好ER图之后，才能顺利进入到接下来的关系表设计阶段。