第一篇：数据库需求与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”。

扩展概念

        使用前面介绍的这些概念，已经能完成基础ER建模了。然而，为了更为细致的刻画出用户需求，又有了下面这些建模规则。

        1. 复合属性(composite attribute)

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

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

        2. 多值属性(multivalued attribute)

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

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

        3. 派生属性(derives attribute)

        部分属性可从其余属性或者其余数据(如当前日期)派生出来，这类属性在ER图上用虚线椭圆标识。

        可参考下面这个士多店实体定义：

        上图中士多店的YearsInBusiness属性表示店铺开张了多少年，这个属性能够结合当前日期与OpeningDate属性算到，所以用虚线椭圆标识。

        4. 可选属性(optional attribute)

        部分属性可能有也可能没有取值，好比说职工奖金。

        ER图上这类属性经过在属性名后面添加(0)标识，可参考下面这个职工实体定义：

        5. 联系的进一步描述

        a. 能够在联系中代表联系中的最大最小基数，以下图所示：

        在上面这个例子中，每一个学生具体对应到了2-6间教室；同时每间教室对应到了5-40名学生。

        b. 也能够在联系中说明联系中的角色。这在一元联系中尤其常见，以下图所示：

        每一个人只能送给其余人一份礼物，但能够收到0或多份礼物。

        6. 关联实体(associated entity)

        关联实体示用于描述M：N联系的一个替代方式，用一个内部有菱形的矩形表示，它没有惟一属性也没有部分惟一属性，且一般来讲没有任何属性。

        以下两个图能够说是等价的：

        关联实体基本都是在多元联系的场景下用到，后面的高级话题部分会讲。

        7. 弱实体(week entity)

        一般来讲，实体至少要有一个惟一属性。由于这样才能精肯定位到须要处理的记录。但在ER建模这一层，也并不是老是如此。

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

        能够将房间使用相关信息做为酒店的建模一个多值复合属性，以下图所示：

        这样作算是对的，可是并无体现出部分码地位，也就是说各RoomID在各Building的惟一性。同时，不少时候须要将房间实体化与其余实体相联系。好比每一个房间对应的清洁工。

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

        两个地方要注意一下，一是弱实体的“主码”称为部分码，码名下方用虚线标记；

        再一个就是弱实体必须至少有一个属主实体，它们之间的联系需用双框菱形标识。弱实体部分码同其属主实体候选码的组合能够惟必定位到任何一个弱实体记录。

高级话题

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

        某人为一个学生选课系统进行ER建模，获得以下结果：

        假如需求中有说明：一个同窗一门课只能选一次，那这样的设计没问题。但是若是需求中说明，一个同窗能够选一门课几回(多是挂了好几回)，这样的设计就有问题了。

        对此，正确的作法之一是使用有两个属主实体的弱实体：

        或者为每次预约生成一个惟一的id，以下图所示：

        2. 三元(或更多)关系

        在ER图中，联系通常是将两个实体关联起来，又或者本身关联本身。可是也有些时候，需求方须要同时将多个实体联系起来。这怎么办呢？要知道表示联系的菱形有且只有两个接口。

        答曰：使用关联实体。下面这个ER图中，使用了关联实体描述了某工厂的供货商，生产产品，零件三方联系：

        但若是如今需求又变动了，须要给关联增长某些属性，好比说供货商每次提供的货物量，这个ER图就不能用了。

        由于这样就没办法区分同一家供应商为同一产品提供等数量的同一零件的不一样实例了。解决的办法是把关联实体改为通常的实体，并增设一个惟一标识符：

其余说明

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

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

        3. 建模工具可以使用PowerDesigner，Workbench等。不过笔者在这里推荐一款轻量级的在线数据库建模工具，网址是https://erdplus.com/#；

小结

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

        只有绘制好ER图以后，才能顺利进入到接下来的关系表设计阶段。这也是下篇要讲解的内容。