2.1 系统需求分析

管理信息系统需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。系统需求分析的内容复杂，方法和工具也有多种，其中数据流图（Data Flow Diagram，DFD）是数据库系统最重要的需求分析工具之一，它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。基本图形元素简述如下。

→：数据流。表示数据在系统内传播的路径，由于数据流是流动中的数据，所以必须有流向。
□：外部实体。代表系统之外的实体，可以是人、物或其他软件系统。
○：数据处理。表示对数据的加工，是对数据进行处理的单元，它接收一定的数据输入，对其进行处理，并产生输出。
〓：数据存储。表示信息的静态存储，可以代表文件、文件的一部分或数据库的元素等。

数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典（Data Dictionary， DD）来描述。数据字典是关于数据的信息集合，也就是对数据流图中包含的所有元素的定义的集合，它是关于数据定义的描述，即元数据，而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分。
这里需要注意的是需求分析工具之一的数据字典与DBMS自动创建的数据字典的异同，它们均是对数据定义的描述，但前者是需求分析阶段的元数据描述，后者是DBMS对元数据的自动存储与维护，是DBMS的一个服务功能。

案例1-2-1 教务管理系统需求分析
对某学校教务管理部门进行调研，首先了解该部门的组织结构和工作岗位，然后了解各部门要处理的数据和业务流程，仔细分析所有的数据项，得到需求分析的结果简述如下。

（1）组织结构。组织结构是用户业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围具有很好的帮助。学校教务管理部门组织结构如图2-3所示。

（2）数据业务流程。对教务管理部门各科室进行数据传递和加工的调研，得到数据流图（DFD）如图2-4所示。

（3）系统功能需求。对教务管理部门各科室进行数据处理调研，得到功能需求如下。
学生管理功能：用于插入、更新和删除学生学籍信息，查询和分类统计学生信息。
课程管理功能：用于插入、更新和删除各专业课程信息，查询和分类统计课程信息。
成绩管理功能：用于插入、更新和删除学生选课以及所选课程考试成绩信息，查询和分类统计学生选课以及考试成绩信息。
授课管理功能：用于插入、更新和删除教师授课以及对所授课程的教学评价信息，查询和分类统计教师授课以及对所授课程的教学评价信息。
教材管理功能：用于插入、更新和删除相关课程的教材信息，查询和分类统计教材信息。

对于以上功能需求按照自顶向下逐步求精的方法进行模块划分，按照用户的需求和习惯，应用C#、Java等程序设计语言和数据库接口技术ADO.NET、JDBC或ODBC等实现各功能模块的界面设计与数据访问，其内容超出本书的范畴，将不做专门的介绍。

（4）数据字典（DD）。对学校教务管理部门各科室的数据进行分析，得到数据项简述如下。
学生信息：学号、姓名、性别、出生日期、专业、入学录取分数等。
课程信息：课程号、课程名、学分、课程类型、课程性质等
教师信息：职工号、姓名、性别、出生日期、职称、学历、学位、所属系部等
教材信息：教材号、教材名、出版社、价格、订书数量、发放数量等。
学生选课信息：学号、课程号、成绩等。
教师授课信息：职工号、课程号、专业、班级、授课任务、评价等。
课程选用教材信息：课程号、教材号、数量、班级等。

案例2-2-1 图书管理系统需求分析
对某图书馆进行调研，首先了解该部门的组织结构和工作岗位，然后了解各部门要处理的数据和业务流程，仔细分析所有的数据项，为了学习方便将需求分析的结果简化如下。

（1）组织结构。图书管理部门设有办理读者借书证的岗位、图书分类入库管理岗位和读者借书还书管理岗位，组织结构如图2-5所示。

（2）数据业务流程。对图书管理各岗位进行数据调研，收集要处理的原始数据和统计报表，得到数据流图（DFD），如图2-6所示。

（3）系统功能需求。对图书管理各岗位进行数据处理调研，得到功能需求如下。
读者管理功能：用于插入、更新和删除读者信息，查询和分类统计读者信息。
图书管理功能：用于插入、更新和删除图书信息，查询和分类统计图书信息。
借书还书管理功能：用于插入、更新和删除读者借书、还书信息，查询和分类统计读者借书、还书信息。
同教务管理系统，对于以上功能需求通过应用编程实现，本书将不做专门的介绍。

（4）数据字典（DD）。对图书管理各管理岗位的数据进行分析，得到数据项简述如下。
① 有关读者的数据信息。
读者信息：读者编号、姓名、类型编号、已借数量、地址、电话、E-mail等。
读者类型信息：类型编号、类型名称、限借数量、限借天数、逾期罚款、丢失罚款等。
罚款信息：读者编号、罚款编号、罚款原因、罚款金额、罚款日期等。
② 有关图书的数据信息。
图书信息：图书编号、书名、作者名、出版社编号、出版日期、定价、是否借出、内容简介等。
出版社信息：出版社编号、出版社名称、出版社地址、联系电话、E-mail、联系人等。
图书修复信息：修复编号、图书编号、损坏程度、损坏原因、修复内容、修复日期、修复费用等。
③ 有关读者借阅图书的数据信息。
借阅信息：读者编号、图书编号、借期、还期等。

2.2 数据库概念设计

数据库概念设计的目标是将系统需求分析得到的用户需求抽象为数据库的概念结构，即概念模型。

2.2.1 概念模型的基本要素

1．实体（Entity，E）
（1）实体集：具有相同属性或特征的客观现实和抽象事物的集合，在不会混淆的情况下一般简称为实体。
例如：学生、课程、教材、教师等。
（2）实体实例：客观存在并且可以相互区别的事物和活动的抽象，是实体集中的一个具体例子。
例如：学生“赵成刚”，课程“面向过程程序设计”，教材“网络技术”，教师“王芳”等。
（3）实体型：对同类实体的共有特征的抽象定义。
例如：“学生”实体型（学号，姓名，性别，…），“课程”实体型（课程号，课程名，学分，…）。
（4）实体值：符合实体型定义的每个具体实体实例。
例如：“学生”实体值（2011216001，赵成刚，男），“课程”实体值（16020010，面向过程程序设计，5）。

2．联系（Relationship，R）
（1）联系集：实体之间相互关系的集合，在不会混淆的情况下一般简称为联系。
例如：联系集“选课”是实体“学生”中的每位学生与实体“课程”中各门课程的相互关系。
（2）联系实例：客观存在并且可以相互区别的实体之间的关系，是联系集中的一个具体例子。
例如：实体“学生”中的学生“赵成刚”选择了实体“课程”中的课程“面向过程程序设计”。
（3）联系型：对同类联系共有特征的抽象定义。
例如：“选课”联系型（学号，课程号，成绩）。
（4）联系值：符合联系型定义的每个具体联系实例。
例如：“选课”联系值（2011216001，16020010，96）。

3．属性（Attribute，A）
（1）属性：描述实体和联系的特征。
例如：实体“学生”中的学号、姓名、性别等，联系“选课”中的学号、课程号、成绩等。
（2）属性值：属性的具体取值。
例如：实体“学生”中某位学生的学号、姓名的值分别为2011216001、赵成刚。

4．候选键（Candidate key，CK）
能够唯一标识实体集或者联系集中每个实例的属性或属性组合被称为候选键，可以有多个。
例如：实体“学生”中的学号、身份证号、姓名（如果无重名）均为实体“学生”的候选键。

5．主键（Primary Key，PK） 能够唯一标识实体集或者联系中每个实例的属性或属性组合，可在多个候选键中选择，主键只能有一个。主键中的属性称为主属性，其他属性称为非主属性。
例如：实体“学生”的主键为“学号”，实体“课程”的主键为“课程号”，联系“选课”的主键为“学号+课程号”。
能作为实体的主键通常有以下几种类型。

（1）自然键：一些原本就可以唯一标识实例的属性，可直接选择作为主键。
例如：学号、员工编号、社会保险号、驾照号码、发票号、订单号、产品号等。
（2）智能键：用几部分信息构造起来的属性，属性内部包含多种信息，帮助人们识别真实世界的某些事物。
例如：身份证号用于唯一标识公民，某公民的身份证号为23000019990101671*。

前6位：地址代码。230000代表黑龙江。
中间8位：代表出生日期。19990101代表1999年1月1日出生。
第15位和第16位：顺序码。67为证件顺序。
第17位：性别码：如果是奇数就是男，如果是偶数就是女。此处1代表男。
最后一位：数字是验证码，是通过计算前面的数字得到的一个值，是用来验证前面身份证号码正确与否的验证码，此处无法举出具体实例，故而用*代替。
例如：图书馆某图书的编号为978-7-115-19345-2TP311.138/269。

● 前段978-7-115-19345-2为图书的ISBN（国际标准书号）。
第一组：数字为978或979，表示是图书。
第二组：国家、语言或区位代码。7表示是中国。 第三组：出版社号。115表示是人民邮电出版社。 第四组：书序号，19345表示本部书在该出版社出版的图书中的序号。 第五组：校验码，只有一位，为0到9其中的一个。此处校验码为2。 ● 中段TP311.138为图书的分类号。 第一组：图书大类号。TP表示是自动化技术、计算机技术大类。 第二组：图书小类号。311表示是程序设计、软件工程，138表示数据库系统。 ● 后段269为书次号。 表示在图书馆中此书排列在此类图书的第几本。 考虑到图书的这种编号过于长，一般图书馆将ISBN独立设置为图书的非主键属性，仅用图书分类号和书次号构成图书的唯一索取号。例如：图书编号（索取号）TP311.138/269。图书管理员根据此索取号给此书进行排架，并在借书、还书的过程中据此可以方便地找到这本书的位置。 6．外键（Foreign key，FK） 一个或一组属性，其中包含另一个实体的主键，用于实现实体之间的联系与参照完整性。 例如：联系“课程选用教材”中的外键“课程号”和“教材号”，它们分别是实体“课程”和“教材”中的主键，联系“课程选用教材”通过这两个外键可以关联到实体“课程”和实体“教材”中的相应实例，得到某课程和所选教材的具体信息。 例如：联系“选课”中的外键“学号”和“课程号”，它们分别是实体“学生”和“课程”中的主键，联系“选课”通过这两个外键可以关联到实体“学生”和实体“课程”中的相应实例，得到此学生和所选课程的具体信息。 7．联系基本分类 实体间存在的联系有以下3种基本类型。 （1）一对一联系（1∶1）：如果对于实体集A中的每一个实体，实体集B中至多有一个（也可以没有）实体与之联系，反之亦然，则称实体集A与实体集B具有一对一联系，记为1∶1。 【例2-1】 在学校里，假设一门课程只使用一本教材，反之一本教材仅供一门课程使用，则课程和教材的联系是一对一联系，记为1∶1，如图2-7（a）所示。 （2）一对多联系（1∶n）：如果对于实体集A中的每个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中至多只有一个实体与之联系，则称实体集A与实体集B具有一对多联系，记为1∶n。 【例2-2】 一个班级中有若干学生，一名学生只属于一个班级，则班级和学生的联系是一对多联系，记为1∶n，如图2-7（b）所示。 （3）多对多联系（m∶n）：如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中也有m个实体（m≥0）与之联系，则称实体集A与实体集B具有多对多联系，记为m∶n。 【例2-3】 一门课程同时有若干个学生选修，而一个学生可以同时选修多门课程，则课程和学生实体之间具有多对多联系，记为m∶n，如图2-7（c）所示。

2.2.2 概念设计的一般步骤

数据库的概念设计需要设计者有很丰富的行业管理经验和较高水平的数据库管理技术，本节仅对其设计步骤进行简单的介绍，以使读者对数据库概念设计有一个了解，为后续数据库的逻辑设计、物理设计和应用程序设计打下较好的基础。

1．初始化工程
这个阶段的任务从目的描述和范围描述开始，确定建模目标，开发建模计划，组织建模队伍，收集源材料，制定约束和规范。其中收集源材料是这个阶段的重点。通过调查和观察结果，由业务流程、原有系统的输入输出、各种报表、收集的原始数据形成基本数据资料表。

2．定义实体
实体集合的成员都有一个共同的特征和属性集，可以从收集的源材料—基本数据资料表中直接或间接标识出大部分实体。根据源材料名字表中表示物的术语及具有“代码”结尾的术语，如客户代码、代理商代码、产品代码等将其名词部分代表的实体标识出来，如客户、代理商、产品等，从而初步找出潜在的实体，形成初步实体表。

3．定义联系
根据实际的业务需求、规则和实际情况确定连接联系、联系名和说明，确定联系类型。即在前述三种联系（1∶1，1∶n，m∶n）的基础上，进一步确定是标识联系、非标识联系（强制的或可选的）还是分类联系。如果子实体的每个实例都需要通过和父实体的联系来标识，则为标识联系，否则为非标识联系。在非标识联系中，如果每个子实体的实例都与而且只与一个父实体的一个实例关联，则为强制的，否则为非强制的。如果父实体与子实体代表的是同一个现实对象，那么它们为分类联系。以上联系类型读者会觉得难以理解，我们将通过对本章2.4节IDEF1X建模语言的学习和应用加以认识，暂可不必纠结于此。

4．定义主键
为实体标识候选键属性，以便唯一识别每个实体，再从候选键中确定主键。为了确定主键和联系的有效性，通过非空规则和非多值规则来保证，即一个实体的一个属性不能是空值，也不能在同一个时刻有一个以上的值。

5．定义属性
从源数据表中抽取说明性的名词开发出属性表，确定属性的所有者。定义非主键属性，检查属性的非空及非多值规则。此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主键属性必须依赖于整个主键且仅仅是依赖于主键。以此得到至少符合关系理论的第三范式。有关规范化的设计也可以在后续逻辑设计中进行，本书也将在第3章数据库逻辑设计方法中进行简单介绍，此处不再赘述。

6．定义其他对象和规则
定义属性的数据类型、长度、精度、非空、默认值和约束规则等。定义触发器、存储过程、视图、角色、同义词和序列等对象信息，可在后续逻辑设计、物理设计和程序设计中逐步完成。

2.3 ER方法概念设计

概念模型是对信息世界的建模，所以概念模型应能够方便、准确地表示出信息世界的常用概念。概念模型的表示方法很多，其中最为著名且常用的是P.P.S.Chen于1976年提出的实体-联系方法（Entity-Relationship Approach )，简称ER方法，是描述现实世界概念结构模型的有效方法。

2.3.1 概念模型的ER表示方法

ER方法用ER图（Entity-Relationship Diagram）表示实体、属性和实体间的联系，基本构件如下。
（1）实体（Entity，E）：用矩形表示，矩形框内写明实体名称。
（2）属性（Attribute，A）：用椭圆形表示，椭圆框内写明属性名称，用无向边将其与相应的实体连接起来。
（3）联系（Relationship，R）：用菱形表示，菱形框内写明联系名称，用无向边将其与相应的实体连接起来，并在无向边旁用数字或字母标明联系的类型。
【例2-4】 在例2-1、例2-2和例2-3中的实体“教材”、“课程”、“班级”、“学生”分别用矩形表示，而课程与教材1∶1的“选用”联系、班级与学生1∶n的“属于”联系、学生与课程之间m∶n的“选课”联系则用菱形表示，分别如图2-8中的（a）、（b）、（c）所示。
【例2-5】 实体本身也有内在的联系，如实体“职工”内部有领导和被领导的联系，即某职工为部门领导，领导若干职工，而一名职工仅被另外一名职工（领导）直接领导。ER图如图2-9所示。

2.3.2 概念模型的ER设计过程

1．设计出局部ER图
局部ER图设计从系统需求分析数据流图和需求文档出发确定实体和属性，并根据数据流图中表示的对数据的处理确定实体之间的联系。

2．合并为综合ER图
局部ER图设计完成之后，将所有的局部ER图综合成全局概念结构。综合ER图不仅要支持所有的局部ER模式，而且必须合理地表示一个完善、一致的数据概念结构。一般同一个实体只出现一次，可进行两两合并，消除合并带来的一些属性、命名和结构冲突，逐步产生综合ER图。
3．优化成基本ER图 综合ER图是在对现实世界进行调查研究之后综合出来的全局和整体概念模型，但并不一定是最优的。需要经过仔细分析找出潜在的数据冗余，再根据应用需求确定是否消除冗余的属性或者冗余的联系。
【例2-6】 商品进销存管理系统数据库的概念设计。
根据系统需求分析可以得到实体“订单”，属性有订单号（主键）、物料号、数量、价格、订货时间等。其局部ER图如图2-10所示。
根据系统需求分析还可以得到实体“供应商”，属性有供应商号（主键）、供应商名、地址、电话、账号等。其局部ER图如图2-11所示。

根据系统需求分析，得到订单与供货商的联系“订货”。假定一个供应商可以有多个订单，而一个订单只能有一个供应商，供应商和订单之间具有一对多的联系。其综合ER图如图2-12所示。

以上综合ER图比较简单，不需要进行进一步优化。

2.3.3 使用Visio建立ER概念模型

ER图的绘制可以采用多种绘图软件工具，也可以使用一些专门的数据库设计工具。其中Microsoft Office Visio是一个多功能的绘图工具，包含数据库设计工具，可以使用其中的“数据库模型图”工具建立数据库的概念模型，但此概念模型有自己独立的风格，支持IDEF1X建模方法，却没有ER图的特定形状。
本小节以教务管理系统ER概念模型的建立为例，简单介绍使用Visio一般绘图工具建立ER图的方法，2.4节中将介绍使用Visio专门的“数据库模型图”工具建立IDEF1X概念模型的方法。
（1）启动Microsoft Office Visio，选择“基本流程图”模板或者选择主菜单“文件”→“新建”/“形状”→“流程图”→“基本流程图”，如图2-13所示。

（2）将【形状】窗口下“基本流程图形状”中单击选择流程（矩形）、判定（菱形）、终结符（椭圆）、置线（无向边），拖动到绘图页上即可方便地表示实体、关系、属性；还可以使用复制、粘贴的功能绘制相同的形状，选择主菜单“形状”→“对齐形状”/“分布形状”进行形状的布局，如图2-14所示。

（3）单击或双击绘图页上的图形即可在其中输入文字，选择【常用】工具栏中的“A（文本工具）”可在绘图页上输入文字，选择主菜单或快捷菜单“格式”→“文本”/“线条”/“填充”等进行形状和文字字体的格式化，如图2-15所示。

案例1-2-2 教务管理数据库概念设计

根据系统需求分析，采用ER方法定义实体、属性、主键和联系等。为了方便学习，对系统需求分析的数据字典进行了简化，仅选取信息的主要数据项。教务管理系统中存在实体“学生”，主键为学号；还存在实体“课程”，主键为课程号。实体“学生”与“课程”之间通过联系“选课”建立关联，并派生出新的属性“成绩”。了解到一门课程有若干名学生选修，而一名学生可以选修多门课程，课程和学生之间具有多对多联系。学生选修课程局部ER图如图2-16所示。
根据系统需求分析，还可以得到实体“教师”，主键为职工号，与实体“课程”之间通过联系“授课”建立关联，并派生出新的属性“评价”。了解到一门课程可以有若干名教师讲授，每一名教师可以讲授多门课程，教师和课程之间具有多对多联系。教师授课局部ER图如图2-17所示。

根据系统需求分析，还可以得到实体“教材”，主键为教材号，与实体“课程”之间通过联系“选用”建立关联，并派生出新的属性“数量”。了解到一门课程选用一种教材，一种教材被一门课程选用，教材和课程之间具有一对一联系。综合课程选用教材、学生选修课程和教师讲授课程的局部ER图，构成教务管理系统ER图，如图2-18所示。为了简单起见，图中学生、课程和教师实体只保留其主键属性。

2.4 IDEF1X方法概念设计

IDEF是ICAM DEFinition method的缩写，是20世纪80年代初美国空军在ICAM（Integrated Computer Aided Manufacturing）工程结构化分析和设计方法基础上发展的一套系统分析和设计标准。
IDEF1X是IDEF系列方法中IDEF1的扩展版本，是在P.P.S(Peter)Chen的实体联系模型化概念与P.P.(Ted) Codd的关系理论的基础上发展起来的，是用于描述系统信息及其联系的概念建模语言标准。 在IDEF1X方法中，虽然某些概念与ER方法非常类似，但IDEF1X方法具有功能更完善的语法、更强大的图形表达能力、规范的开发过程、标准的文件格式和大量的软件建模工具支持，应用更加广泛。下面简单介绍IDEF1X基本要素的语法和语义。

2.4.1 实体（Entity，E）

在IDEF1X标准中，根据一个实体是否依赖于另一个实体，可分为独立实体和从属实体两类。又根据一个实体与另一个实体的关联情况，又可分为父实体和子实体两种。

1．独立实体
不依赖于其他实体和联系就可以独立存在的实体称为独立实体。该实体的主键属性组中没有来自其他实体的主键，用方角矩形表示，也常被称为强实体或拥有者实体，如图2-19（a）所示。

2．从属实体
依赖于其他实体和联系才能够存在的实体称为从属实体。该实体的主键属性组中包含来自其他实体的主键，用圆角矩形表示，也常被称为弱实体或依赖实体，如图2-19（b）所示。

3．父实体（Parent Entity）
父实体的实例可以被关联到其他实体（子实体）0个、1个或多个实例上，如图2-20（a）所示。

4．子实体（Child Entity）
子实体的实例可以被确定地关联到其他实体（父实体）的1个实例上，特殊情况下可以是0个实例。该子实体中的主键含有父实体的主键属性，为父实体的从属实体，如图2-20（b）所示。
【例2-7】 在图书管理系统中，对于实体“读者”，主键“读者编号”可以唯一识别每一个读者，不依赖于任何实体的主键，是一个独立实体，如图2-20（a）所示。
对于实体“罚款”，考虑一位读者可能有几次因为延期还书、丢失图书、损坏图书的罚款，那么“罚款”的主键可以设为“读者编号+罚款编号”，因为实体“罚款”的主键中包含了实体“读者”的主键“读者编号”，所以实体“罚款”是从属实体，如图2-20（b）所示。
对于实体“读者”与实体“罚款”存在一对零或多的联系，所以实体“读者”为父实体，实体“罚款”为子实体，如图2-20所示。

2.4.2 属性（Attribute，A）

实体的属性用方框中的属性名称来表示，其中作为主键的属性放在横穿实体矩形中的一条直线之上，作为外键的属性可在其后加“FK”进行指明，如图2-21所示。

2.4.3 联系（Relationship，R）

实体之间的联系可以分为确定联系和不确定联系。根据联系的类型不同，实体之间的联系用连接方框之间不同的连线或矩形框（多对多的联系）来表示。

---

说明
以上所述“联系”和ER模型中的“联系”，在有关数据库技术的英文著作里均为“Relationship”，但翻译成中文，常有联系和关系两种表达。例如：实体联系模型或者实体关系模型，意思均是相同的，为了避免与后续关系模型中的关系（Relation）混淆，本书将“Relationship”统一翻译为“联系”。

---

1．确定联系（Specific connection relationship） 确定联系，又分为连接联系和分类联系，是一种1/0：n（n≥0）的联系类型。
（1）连接联系。它是父（Parent）实体和子（Child）实体之间的联系，也称父子联系（Parent-Child Relationship），联系用一条连线表示，连线的子实体端带有一个实心圆。连接联系又分为标识联系、非标识联系（强制/非强制）等。
① 标识联系：父实体与子实体之间的联系为“一对零或多”，即子实体的每个实例必须与一个父实体的实例关联。将父实体的主键迁移到子实体中作为主键属性共同标识子实体的实例，并成为子实体的外键（FK），联系用实线表示，子实体为从属实体（圆角矩形），如图2-22所示。

从图中可以看出，在标识联系中的子实体即前面所述的从属实体，用圆角矩形表示，而相对应的父实体即前面所述的独立实体，用方角矩形表示。
前述例2-7中父实体“读者”和子实体“罚款”之间的联系为“一对零或多”的标识联系。将父实体“读者”的主键“读者编号”迁移到子实体“罚款”中作为其外键（FK），并与子实体的“罚款编号”联合构成子实体的主键，共同标识子实体的每个实例，联系用实线表示，如图2-20所示。
② 非标识联系（强制）：父实体与子实体之间的联系同上也是“一对零或多”，但是父实体的主键不迁移到子实体的主键上，而是迁移到子实体作为非主属性，并成为子实体的外键（FK），联系用虚线表示，子实体为独立实体（方角矩形），如图2-23所示。
【例2-8】 在图书管理系统中，父实体“读者类型”和子实体“读者”之间存在“一对零或多”的非标识联系（强制），即子实体“读者”中的每个实例的“类型编号”的值必须与父实体“读者类型”中的一个且只与一个“类型编号”值相关联。
将父实体“读者类型”的主键“类型编号”迁移到子实体“读者”中作为普通属性，并成为其外键（FK），联系用虚线表示，如图2-24所示。

③ 非标识联系（非强制）：父实体与子实体之间的联系为“零或一对零或多”，即子实体的每个实例不是必须与一个父实体关联。同上，父实体的主键不迁移到子实体的主键上，而是迁移到子实体作为非主属性，并成为子实体的外键（FK），联系用虚线表示，子实体为独立实体（方角矩形），连线的父实体端用空心钻石来表示，如图2-25所示。 【例2-9】 在图书管理系统中，父实体“出版社”和子实体“图书”之间存在着“零或一对零或多”的非标识联系（非强制），在子实体“图书”中可能存在非正式出版社出版的图书，外键“出版社编号”的值允许为NULL（空值），不与父实体“出版社”相关联。
将父实体“出版社”的主键“出版社编号”迁移到子实体“图书”中作为普通属性，并成为其外键（FK），允许空值（0），联系用虚线表示，连线父实体端用空心钻石来表示，如图2-26所示。

此外，连接类型还有“一对一”、“一对零或一”、递归等联系类型，可以将其看做1/0∶n（n≥0）联系的特例，本文不再赘述。

（2）分类联系。IDEF1X建模方法引入了分类联系，表示实体间的一种分层结构。一个实体（一般实体）表示这些事物的全集，其他几个实体（分类实体）则为其子集，是一种“一对一或零”的联系类型，一般实体经过鉴别器对一个属性值进行判断（类似于多路开关）与相应子实体关联，之间用连线表示，线的两端没有实心圆。分类实体用圆角矩形表示，从属于一般实体，如图2-27所示。
分类联系又分为完全分类联系和不完全分类联系。
① 完全分类联系：一般实体与分类实体之间的联系为“一对一”，即在一般实体中的每个实例恰好与一个且仅为一个分类实体的实例相联系，鉴别器用一个圆圈下面两条线表示，如图2-27（a）所示。
② 不完全分类联系：一般实体与分类实体之间的联系为“一对零或一”，即在一般实体中可以存在某个实例与哪个分类实体的实例都不相联系，鉴别器用一个圆圈下面一条线表示，如图2-27（b）所示。

【例2-10】 在图书管理系统中，假设图书有中文和外文两大类，在一般实体“图书”中设置一个鉴别器属性“图书类型”，当“图书类型”属性值为“中文”时，这个实例被放入分类实体“中文图书”中，当“图书类型”属性值为“外文”时，这个实例被放入分类实体“外文图书”中，如图2-28所示。

2．不确定联系（Non-Specific connection relationship） 不确定联系是一种m∶n（m≥0，n≥0）的联系类型，两个实体之间相互存在着一对多的联系，联系用一条连线表示，连线的两端带有一个实心圆，如图2-29所示。 建立不确定联系的模型存在着一个严重问题，实体与实体多对多的联系本身还有一些信息无法表示。所以该不确定联系常被建模如图2-30所示，这里中间的实体被称为关联实体或解决实体。

【例2-11】 在图书管理系统中，实体“读者”与实体“图书”存在着“多对多”的联系，一位读者可以借阅多本书，一本书也可以被多位读者借阅（不同的时期），在读者借阅图书的关联中派生了属性“借期”和“还期”等信息。
在实体“读者”和实体“图书”中间增加一个关联实体“借阅”，将父实体“读者”的主键“读者编号”和另一个父实体“图书”的主键“图书编号”迁移过来，与借书时间“借期”一起联合构成“关联实体”的主键，并分别成为关联实体的外键（FK），如图2-31所示。

以上简单介绍了IDEF1X建立概念模型的方法，有很多的数据库建模工具都支持IDEF1X方法，如CA公司的ERWin、Sybase公司的PowerDesigner以及微软公司的Office Visio等。这些工具都能建立完整的IDEF1X概念模型并支持将其转换为物理数据库的结构。下面仅介绍如何使用微软公司的Visio建立数据库概念模型。

2.4.4 使用Visio建立IDEF1X概念模型

Microsoft Office Visio “数据库模型图”设计工具中的“实体关系”形状可以用来建立IDEF1X概念模型。我们通过图书管理系统这个实例来说明采用Visio进行IDEF1X建模的方法和步骤。

---

说明 在Visio中所说的“关系”与本章所说的“联系”意思相同。

---

（1）启动Microsoft Office Visio，选择“数据库模型图”模板或者选择主菜单“文件”→“新建”→“软件和数据库”→“数据库模型图”，如图2-32所示。 （2）选择主菜单“数据库”→“选项”→“文档”，在弹出的【数据库文档选项】对话框中选择IDEF1X符号集，如图2-33所示。

（3）建立实体“读者”等模型。将【形状】窗口下“实体关系”中的“实体”拖动到绘图页上，在绘图页下方的数据库属性窗格中选择“类别”→“定义”，输入实体的名称，如图2-34所示；选择“类别”→“列”，输入实体的属性和设置PK（主键），如图2-35所示。

用同样的方法建立其他实体模型。

（4）为父实体“图书”和子实体“图书修复”建立“1到0或多”的标识联系。将【形状】窗口下“实体关系”中的“关系”拖动到绘图页上，拖动“关系”的两端使之连接的实体边框变红，单击“关系”形状，在绘图页下方的数据库属性窗格中选择“类别”→“杂项”，选择关系类型“标识”建立标识联系（本例），选择“不标识”建立非标识联系，选择关系基数“1到0或多”（本例）/1到1或多/1到0或1/1到1/1到最小值至最大值，如图2-36所示。

注意：IDEF1X模型能自动实现键的迁移，关键字“图书编号”从父实体“图书”到子实体的迁移是自动的。

（5）用类似的方法为父实体“读者类型”和子实体“读者”建立“1到0或多”的非标识联系（强制），如图2-37所示。

（6）用类似的方法为父实体“出版社”和子实体“图书”建立“0或1到0或多”的非标识联系（非强制），将实体“图书”中的出版社编号设置为非必需的（允许空0），如图2-38所示。

（7）为实体“读者”和实体“图书”建立多对多的不确定联系。首先建立一个关联实体“借阅”，为此实体设置属性，如图2-39所示。
其次建立父实体“读者”和关联实体“借阅”的“1到0或多”的标识联系，最后建立父实体“图书”和关联实体“借阅”之间的“1到0或多”的标识联系，如图2-40所示。

除此之外，使用Visio建立IDEF1X概念模型还可以定义实体各属性的数据类型、非空（必需的）、索引、触发器和检查等信息，定义联系的参照动作。应用主菜单“工具”→“加载项”→“其他Visio方案”→“导出到数据库”，即可将Visio绘图页上形状中的数据导出到与ODBC兼容的数据库表中，实现数据库的物理设计。相反也可以通过主菜单“数据库”→“反向工程”，从现有数据库中提取数据库架构，建立数据模型。

案例2-2-2 图书管理数据库概念设计

根据图书管理系统的需求分析，得到以下实体以及它们之间的联系类型。
（1）实体：读者、读者类型、罚款、图书、图书修复、出版社以及它们的属性（略）。
（2）确定联系—标识联系：读者与罚款（1到0或多）、图书与图书修复（1到0或多）。
（3）确定联系—非标识联系（强制）：读者类型与读者（1到0或多）。
（4）确定联系—非标识联系（非强制）：出版社与图书（0或1到0或多）。
（5）不确定联系：读者与图书（多对多）。
以上实体及实体之间联系的IDEF1X表示方法和Visio建模工具在2.4节中均分别进行了介绍，此处不再赘述。图书管理系统数据库的IDEF1X概念模型如图2-41所示。

Visio的“数据库模型图”工具还支持其他有关实体属性的数据类型、长度、精度、非空、缺省值、约束规则等的定义，有关实体的触发器、存储过程、视图、角色、同义词等的建立，这些内容将在后续数据库逻辑设计和SQL Server数据库物理设计以及应用编程中逐步介绍。
本章两个案例的概念设计均比较简单，目的是使读者对概念设计的方法有一个初步的了解。在实际数据库的开发过程中，概念设计是非常复杂的，概念设计的方法和概念模型的建模语言也有许多种类和内容，希望通过本章的学习和不断地实践，掌握适合自己的建模方法和工具。