一、引言
1、如何用实体-联系模型，即ER模型进行数据库的概念结构设计？主要包括概念结构设计的步骤与方法
2、E-R模型用E-R图来描述概念模型中的实体、属性、实体间的联系等概念。
（1）在E-R模型中，实体用矩形来表示，实体的属性用椭圆表示并用无向边将其与相应的实体连接起来
（2）联系用菱形表示并用无向边分别与有关实体连接起来同时在无向边上标上联系的类型，是1:1、1:n还是m:n
（3）在实体集A与子集实体集B之间，可存在ISA联系，用指向超类的三角形表示，实体B可通过ISA联系，继承实体A中的所有属性和与A相关的联系，同时拥有自己特有的属性
（4）依赖于常规实体的弱实体，用双线矩形框表示，与常规实体之间存在着一种依赖联系，用双线菱形框表示
在这些基本要素的基础上，可构造具体的应用系统中实体及其联系的完整E-R图来实现数据库的概念结构设计 。
二、概念结构设计步骤
（一）基于E-R模型进行数据库概念结构设计，一般遵循如下步骤
1、从需求分析的结果文档中，抽取实体与实体的属性并绘制实体的E-R图
2、确定实体之间的联系，以及发生联系后产生的属性特征，绘制联系的E-R图
3、组合实体与联系的E-R图，构造应用系统的完整E-R图
（二）其中抽取实体是概念结构设计的重点 ，下面以一个学校的小型的教学信息管理系统（案例系统）为例，按设计步骤进行应用系统的数据库概念结构设计
学校教学信息管理系统功能
- 经需求分析已知，系统的功能是要管理学校所有的专业系的信息，包括系所管辖的班级和教研室的信息
- 每个班级的学生信息及选课信息
- 每个教研室的教师信息及教师授课信息
- 学生成绩信息
系统要能对要能对管理的数据进行合理地组织、存储，能实现数据的及时更新，并能对数据进行如下这类复杂的查询操作
1、基于需求分析的描述，及系统对数据的处理需求，可确定需在系统中进行管理的实体应包括班级、教研室、学生、教师和课程及描述实体的必要特征属性，如班级实体的班级号、所在系、专业、人数，教研室实体的教研室名称、所在系、室主任、人数等
而对于专业系这个所涉及的对象，需要考虑的是，将其单独抽象为一个实体，还是抽象为班级或教研室的属性，一般的原则是
- 如果系统需要进一步描述该对象的特性，并需处理该对象与其他实体间的联系，则将该对象抽象为实体
- 如果该对象只是用来描述另一个实体的，则将该对象抽象为属性
所以从需求分析的结果来看，并不需要对专业系进行操作，这里我们就把专业系只作为班级和教研室的属性，当然，更不能将学校作为自身系统的实体。
2、绘制好实体及其属性的E-R图，下面来确定实体间的联系
需求分析的结果为：
- 每个班由同一专业系中同一专业的多名学生组成
- 每个教研室由承担几门共同课程的多名教师组成
- 每个班级选修本专业开设的若干门课程，一个班级选修的某门课程只能由同一个教师来讲授
- 相同的课程可由不同的教师讲授
- 一个教师可为同一个班级讲授不同的课程，或为不同的班级讲授相同的课程，或为不同的班级讲授相同的课程
- 班级选修的某门课程只能在一个年度的一个学期内实施完成
- 每个学生选修每门课程要有相应的成绩
设计思考2：多个实体间的联系设计为二元联系还是多元联系？
- 一般根据需求中多个实体间联系的语义描述，以及所涉及的实体，来确定是构造二元联系还是多元联系
- 若用户只考虑两两实体间的联系，可采用多个二元联系来实现
在此处，因应用要进行一些类似查询2018年度给多个班级讲授同一门课程的教师编号和所讲授的课程号这类数据操作， 所以这里我们构造实体班级、课程和教师之间的一个三元联系，可命名该联系为班级选课。而三个实体间发生联系会产生上课年度、上课学期和教室等属性。
设计思考3：而这里需要考虑的是，对于上课学期，应是班级选课联系的属性还是课程的属性？
- 因实体的属性是实体的内在特征
- 而联系上的属性描述因发生联系而需要记录存储的信息，其值会随着联系的产生而出现，也会随着联系的消失而消失
因此要根据学校的具体情况，课程是否固定在某个学期进行实施的，若不是这样的，则不能将上课学期作为课程的属性，只能作为班级选课联系的属性。这里，我们将上课学期和上课年度一起作为班级选课联系的属性，不考虑其他与教学信息管理无关的属性
此外，要管理学生的课程成绩，所以学生实体和课程实体之间存在选课成绩联系，该联系上有成绩属性。
3、至此，我们可以将前两步所得到的实体与联系的E-R图进行组合，构造出该教学信息管理系统的完整E-R图
若系统中还要管理研究生及其指导教师的信息，则需在构造好的E-R图中增加两个实体类型 ：导师实体和研究生实体
导师实体具有所在学科、导师类别等属性，与教师实体间存在着ISA联系。研究生实体具有所在学科、研究方向等属性，与学生实体间存在着ISA联系，与导师实体存在指导联系。
至此，完成该学校的教学信息管理系统的数据库的概念结构设计。
若该教学信息管理系统不仅要管理教学信息，还要管理所辖人员的档案信息，则需对学生实体和教师实体增加属性，比如增加具有依赖关系的弱实体等。将学生的家庭成员单独构成一个弱实体，来记录学生的家庭成员的姓名、与学生的关系、身份证号、职业、住址等信息。
对于一个学校的综合信息管理系统，可能包含多个业务功能总系统，那么如何设计面向整个应用领域的全局数据库的概念结构呢？
三、概念结构设计方法
（一）自顶向下
自顶向下是首先设计全局概念结构框架，再逐步细化逐步的概念结构，最后生成完整的概念结构
（二）自底向上
自底向上是先设计各局部概念结构，然后通过集成得到完整的全局概念结构
（三）由内向外
由内向外是首先设计最重要的核心功能子系统概念结构，然后逐步向外扩充，生成其他功能系统的概念结构，直至完成全局概念结构。比如前面我们不断增加需求的学校信息管理系统的设计
（四）混合设计
而混合策略则采用自顶向下和自底向上相结合的方法，用自顶向下的方法设计一个全局概念结构框架，再用自底向上方法，集成生成个局部概念结构
（五）常用的自底向上的概念结构设计又可分为两步
1、首先划分数据库局部结构，比如可按照应用系统的业务功能来划分，为各应用的子系统设计各自的概念结构，即局部E-R模型。
例如对于一个学校信息管理系统，有教务、科研、财务等业务功能，各功能子系统对信息内容和处理的要求不同，根据需求分析的结果，按照前面的概念结构设计步骤，为它们设计各自的局部E-R模型。
2、在局部E-R模型均设计完成后，第二步就是进行E-R模型的集成，对局部E-R模型的集成是通过相同实体进行叠加的方式完成的，在集成过程中，要注意解决冲突和冗余这两类问题
（1）若已对应用系统进行了全面的需求分析，并用数据字典对系统中所涉及的各类数据对象已进行了统一描述。在此基础上，从需求分析的结果经过数据抽象得到的各局部E-R模型之间的冲突应主要包括三种结构冲突 ：
- 同一对象在不同应用中被抽象的结果不同， 在有的E-R模型中被抽象为属性，在有的E-R模型中被抽象为实体。比如前面提到的专业系，可能在另一个局部E-R模型中就被抽象为实体
- 同一实体在不同的E-R模型中所包含的属性不同
因不同子系统关注的对象的特征不同 ，全局数据库应为各类应用提供数据的共享，所以对于第一类结构冲突应统一抽象为实体，对第二类结构冲突，应把所有属性合并起来
- 第三种结构冲突是在不同的E-R模型中，两个实体间的联系名称或其属性不同，或其联系的类型不同。
因两个实体间可以有多种联系，所以要判断这是两个实体间不同的联系还是同一联系的不同称谓，若是后者，应对联系名称和类型进行统一，类型由1向多统一，相关的属性也要进行名称统一或合并
（2）消除冲突后，集成得到的初步的全局E-R模型还可能存在着冗余的属性或联系
- 也就是通过其他属性的值可以推导出其值的属性
- 和通过其他实体间的联系可以推导出来的两个实体间的联系
需要去除
比如我们前面设计的学校信息管理系统，各局部E-R模型集成后，可能还存在着教研室实体和课程实体的任课单位联系，而该联系可体现在教研室实体和教师实体以及教师实体与课程实体之间的联系中，是冗余的联系，可去除
四、小结
1、数据库概念结构设计将系统要管理的对象进行了抽象，采用概念模型，精确表达数据对象的特征以及对象之间的联系
2、是数据库逻辑结构设计的基础，是数据库设计的关键步骤