数据库技术及应用第9章 数据库设计

9.1.1数据库设计在软件开发中的地位和作用数据库设计是信息系统设计中最为关键的一项任务。一个优秀的数据库设计无疑能够帮助程序员减少业务逻辑操作，减少出错的可能性，甚至有助于提高软件的性能；而一个糟糕的数据库设计会在需要添加功能的时候无从扩展，或是大量的冗余造成性能的瓶颈。

数据库设计的一般定义：数据库设计是针对一个特定的应用环境，构造优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。用户需求在设计过程中扮演一个中心角色，数据库设计必须与需求相对应，各种功能需求都要在数据库中予以体现。

9.1.2数据库设计的基本步骤依照规范设计的方法，考虑到数据库及其应用系统开发全过程，将数据库设计分为以下5个阶段：(1)需求收集与分析阶段需要就系统功能、数据需求、数据完整性和安全性等诸多方面与应用领域专家和用户展开多种方式的沟通，同时综合不同用户的应用需求。虽然存在图形方式的用户需求表示，但是在本章中仅限于采用文字方式描述。(2)概念结构设计阶段是将用户需求以概念模型的方式表达出来，独立于具体DBMS产品，用以和用户沟通并确认需求。检查概念模型，看该模型是不是包含了所有的数据；能不能满足对数据的各种操作（如查询和增删改等）。概念结构设计是整个数据库设计的关键。基于E-R图的实体-联系模型（E-R模型）是目前最为广泛使用的概念模型。

9.1.2数据库设计的基本步骤(3)逻辑结构设计阶段将概念模型转换成具体的数据库产品支持的逻辑模型（比如关系数据库模型），形成数据库的逻辑模式并对它进行优化。然后根据用户处理的要求、安全性的考虑，在全局逻辑结构的基础上再建立必要的视图，形成数据的外模式。(4)物理结构设计阶段为逻辑模型选取一个最合适应用环境的物理结构，包括物理存储安排和索引结构的选择等，形成数据库内模式。(5)实施、运行和维护阶段将组织数据入库，并进行试运行，之后可投入正式运行，在数据库系统运行过程中必须不断地对其进行评价、调整与修改。

9.1.2数据库设计的基本步骤应用要求应用2应用1应用1应用2应用3综合转换映像映像内模式外模式应用3

概念模式

逻辑模式数据库应用系统应用要求应用要求外模式外模式需求收集与分析概念结构设计逻辑结构设计物理结构设计实施运行维护

9.2.1实体与用户需求对现实世界做需求分析得到用户需求，将它抽象为信息世界即概念模型的过程就是概念结构设计。它是整个数据库设计的关键。PeterChen1976年提出的E-R模型是用E-R图来描述现实世界的概念模型，Chen氏模型中使用的图形符号见表9.1。本章中谈到的实体，没特别说明的话都是指实体型。实体可以是具体的人、事、物，例如学生、教师、课程等，也可以是抽象的概念或联系，如时间段、考试安排等。实体由实体名和属性名集合组成。在实际开发中，实体的属性集是由用户的实际需求决定的。学生(学号，姓名，性别，入学年月，出生日期，年龄，学生来源，籍贯，民族，宗教信仰，健康状况，户籍地址，居住地址，电话号码，学籍状态，特长)时间段(节次，开始时间，结束时间，适用部门)

9.2.2属性及其分类属性是实体所具有的某一特性，每个实体在每个属性上都有各自的属性值，属性值有可取值的范围，称为属性的域。依照具体信息系统中的不同需求，E-R图中的属性可以按照属性类型进行多种划分，下面分别介绍。(1)

简单属性：该属性是不能再进行分割的最小单位。如前面学生实体中的学号、性别、学生来源、年龄、籍贯等都是简单属性。用椭圆节点表示。(2)复合属性：可以再分割为更小部分的属性。复合属性可以是有层次结构的，此时用树状的简单属性图形符号来表示上下层次关系。那么复合属性到底在什么场合下使用呢？如果一个用户希望在一些场景中引用完整的属性，而在另外的场景中仅引用属性的一部分，这时候使用复合属性是一个好的选择。复合属性居住地址可以用树状层次化表示，如下图所示。

邮编区名街道路名门牌居住地址

9.2.2属性及其分类(3)单值属性：对一个特定实体，一个属性只有单独的一个值，如学号、姓名、籍贯等。(4)多值属性：对一个特定实体，一个属性可能对应一组值。用双线椭圆节点表示。(5)派生属性：由其它属性计算得出的属性，使用虚线椭圆节点表示。派生属性会造成数据冗余。(6)码属性：如果属性是实体型中用来唯一标识实体的属性称为码属性。码属性在属性名的下面划一条线表示。学生实体中学号是码属性。各种属性的学生实体E-R图表示年龄学号电话号码学生出生日期年龄居住地址宗教信仰学生来源电话号码学籍状态区名邮编街道路名门牌学号说明：由于属性较多，在此只标出几个需要特别关注的属性。

9.2.3联系及其分类在现实世界中，事物内部以及事物之间是有联系的，这些联系在信息世界中反映为实体内部的联系和实体之间的联系。实体内部的联系通常是指组成实体的各属性之间的联系；实体之间的联系通常是指不同实体集之间的联系。实体内部和实体之间联系类型的不同，将直接导致数据库不同的逻辑结构设计，最后影响到用户功能的实现。所以区分联系类型是一项非常重要的工作。1、两个实体型之间的联系（二元联系）(1)一对一联系（1:1）(2)一对多联系（1:n）(3)多对多联系（m:n）联系也是可以有属性的教师班级11负责员工房间1n负责职务教师mn任职开始时间任职结束时间任职

9.2.3联系及其分类2、两个以上实体型之间的联系（多元联系）3、单个实体型内部的联系4、两个实体型之间的多种联系5、参与约束班级教师pn课程m学期学年任课学生n管理1员工房间1n1n办公负责员工房间1n负责

9.2.4弱实体类型在现实世界中，有时某些实体对于另一些实体有很强的依赖关系，即一个实体的存在必须以另一实体的存在为前提，该实体主码的全部或者部分从依赖的实体获得。前者称为弱实体类型（简称弱实体），后者称为强实体类型或常规实体类型（简称强实体或实体）。弱实体类型一定需要关联到一个强实体类型，以便识别其身份，该强实体类型称为“标识实体类型”，使用的联系类型称为“标识联系类型”，以双框菱形图形符号来表示，弱实体类型是使用双线矩形符号来表示。弱实体必然是全部参与联系。如下图所示。学生

简历拥有起始日期所在学校终止日期学号1n

9.2.5扩展的E-R特性E-R模型的一个局限性在于它不能表达联系间的联系。比如首先教师入职时登记所擅长的课程信息，如下图所示。以后教学负责人只能选择该课程登记的擅长教师任教，这时任课联系就是建立在擅长联系和班级之间，而不再是教师、课程和班级三个实体上的多对多联系。对类似上述情况建模的最好方法是使用聚集。聚集是一种抽象，通过这种抽象，联系被看作是高层实体，从而和其它实体或者聚集的高层实体建立联系。如下图所示。把擅长聚集为高层实体与班级建立多对多联系，体现出班级只和某教师擅长的某门课建立任课联系。教师课程n擅长m教师课程nm擅长班级任课mn学期学年

9.2.6E-R图实例本节以基础教育学校背景为例，分析了实体、属性和联系的分类，现将上面的各E-R子图综合起来，以便对实体间关联关系有整体概念，如下图所示。该图中员工实体与教师实体的区别在后面设计实例9.6.5小节中有介绍，这里不做说明。教师qn课程房间职务简历拥有

任课负责2办公任职管理属于2属于1n1nnmn11n1n任职开始时间任职结束时间负责111111m学年学期员工班级学生

9.2.7概念结构设计的方法和步骤1、概念结构设计的方法(1)自顶向下：首先定义全局概念结构的框架，然后逐步细化。(2)自底向上：首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构。(3)逐步扩张：首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构。(4)混合策略：将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。其中经常采用的策略是自底向上方法，即自顶向下地进行需求分析，然后自底向上地设计概念结构。

9.2.7概念结构设计的方法和步骤2、概念结构设计的步骤自底向上设计概念结构分为两步。(1)抽象数据并设计局部视图。首先需要根据系统的具体情况，从某个层面为出发点，作为分E-R图的分割依据。然后逐一设计分E-R图，标定局部应用中的实体、属性、码和实体间的联系。(2)集成局部视图，得到全局概念结构。各个局部视图即分E-R图建立好后，还需要对它们进行合并，集成为一个整体的概念结构即总E-R图。

9.2.7概念结构设计的方法和步骤3、视图的集成

集成局部E-R图时需要合并、修改和重构两个步骤进行。(1)合并：各个局部应用所面向的问题不同，而且可能由不同的设计人员进行局部视图设计，导致各个分E-R图之间必定会存在许多不一致的地方。合并分E-R图的主要工作就是合理消除各分E-R图的冲突。①属性冲突属性域冲突，即属性值的类型、取值范围或取值集合不同属性取值单位冲突②命名冲突同名异义：不同意义的对象在不同的局部应用中具有相同的名字异名同义：同一意义的对象在不同的局部应用中具有不同的名字③结构冲突同一对象在不同应用中具有不同的抽象同一实体在不同局部视图中所包含的属性不完全相同或者属性的排列次序不完全相同

9.2.7概念结构设计的方法和步骤3、视图的集成(2)修改与重构：消除不必要的冗余（冗余数据或者冗余联系），设计生成基本E-R图。并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高某些应用的效率，不得不以冗余信息作为代价。设计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。最终，整体概念结构还应该提交给用户，征求用户和有关人员的意见，进行评审、修改和优化，才能作为最终的数据库概念结构，同时也是下一步数据库逻辑结构设计的依据。

9.3.1强实体的表示首先介绍E-R图到关系模式的转换原则，然后对转换后的逻辑结构进行优化设计，至少满足3NF的规范化形式，最后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图，形成数据库的外模式（用户子模式）。E-R图中的强实体转换成关系模式的规则为：(1)每个实体对应一个关系模式，实体的名称就是关系模式的名称。(2)实体的码属性就是关系模式的主码。(3)实体中的复合属性、多值属性和派生属性之外的属性，直接作为关系模式的属性。(4)对于复合属性，这种包含子属性违背了1NF要求每个属性都是不可分割的要求，因此需要将该复合属性的每个子属性变为关系模式中的一个属性，关系模式中不再保留原来的复合属性，以满足1NF要求的原子性。(5)对于多值属性，由于每个具体实体的属性值个数不同，为避免存储空间的浪费，一般来说要为该多值属性创建一个新的关系模式。此关系模式包含原实体主码的属性和该多值属性。

9.3.1强实体的表示(6)对于派生属性，它是由其他属性推导得出，存在对码的传递依赖，这是一种冗余，同时也违背了3NF的要求。但冗余数据并不总是不好的，是否保留派生属性要分析实际情况决定，不能一概而论。

学生实体的E-R图，转换关系模式的分析过程为：居住地址属性是复合属性，不再保留，换做区名、邮编、街道、路名门牌四个属性；派生属性年龄也不再保留；多值属性电话号码从学生实体中分离出来，单独成为关系模式电话号码。转换后的关系模式如下：学生(学号，出生日期，区名，邮编，街道，路名门牌，学籍状态，学生来源，宗教信仰)电话号码(学号，电话号码)学号是外码，参照学生的学号。每位学生有几个电话号码就对应几行数据，避免了存储空间的浪费。说明：学生实体属性较多，上图(图9.5)没有标出学生实体全部的属性，转换关系模式为保证清晰，只依照该图中标注的属性进行转换。学生出生日期年龄居住地址宗教信仰学生来源电话号码学籍状态区名邮编街道路名门牌学号

9.3.2联系的表示下面分别介绍各种类型的联系到关系模式的转换规则1、一对一联系可以把任一方的主码纳入另一方或者建立一个新的关系模式（包括双方的主码），根据双方实体完全参与约束还是部分参与约束，采取不同处理方式。上图转换关系模式如下：第一步实体的转换：教师(工号，姓名，性别，出生日期，民族，职称)

班级(班级号，班级名称，班级类型)

第二步联系的转换：班级(班级号，班级名称，班级类型，班主任工号)班主任工号作为班级的外码，必须非空(班级实体是完全参与约束)，参照教师的工号。教师实体是部分参与约束，班级实体是完全参与约束，因此若把班级的主码班级号加入到教师关系模式中，不是每个教师都担任班主任，且教师的数量远大于班级的数量，会占用更多的存储空间。因此将教师主码加入到班级关系模式中更为合适。教师班级11负责

9.3.2联系的表示2、一对多联系将“1”方的主码纳入“n”方实体对应的关系模式中，同时把联系的属性也纳入“n”方的关系中。上图转换关系模式如下：第一步实体的转换：员工(工号，姓名，性别，出生日期，民族，入校年月，工龄)房间(房间号，房间名称，使用类别，建筑面积)

第二步联系的转换：房间(房间号，房间名称，使用类别，建筑面积，工号)工号作为房间的外码，必须非空(房间实体是完全参与约束)，参照员工的工号。员工房间1n负责

9.3.2联系的表示3、多对多联系对联系单独建立一个关系模式，该关系模式包括两实体的码及联系的属性。上图转换关系模式如下：

第一步实体的转换：教师(工号，姓名，性别，民族，出生日期，职称)

职务(职务编号，职务名称，职务类别)

第二步联系的转换：任职(工号，职务编号，任职开始时间，职务结束时间)工号、职务编号作为任职的外码，分别参照教师的工号和职务的职务编号。这两个外码同时又是任职关系的主属性，不可为空。

职务教师mn任职开始时间任职结束时间任职

9.3.2联系的表示4、两个以上实体型之间的联系对联系单独建立一个关系模式，该关系模式包括各个实体的码及联系的属性。上图转换关系模式如下：

第一步实体的转换：教师(工号，姓名，性别，出生日期，民族，职称)

班级(班级号，班级名称，班级类型)

课程(课程号，课程名称，总学时，类别)

第二步联系的转换：任课(工号，班级号，课程号，学年，学期)工号、班级号、课程号作为任课的外码，分别参照教师、班级和课程中相应的属性列，外码同时也是任课的主属性，不可为空。班级教师pn课程m学期学年任课

9.3.2联系的表示5、单个实体型内部的联系对于一对一或一对多单个实体型内部联系的转换就是在这个实体对应的关系模式中多设一个属性，该属性与主码属性的类型、长度相同，并作为外码列指向实体本身。该属性的命名需与主码属性不同，表明其用意。外码的约束根据实际需求进行确定。上图转换关系模式如下：第一步实体的转换：学生(学号，出生日期，区名，邮编，街道，路名门牌，学籍状态，学生来源，宗教信仰)

第二步联系的转换：学生(学号，出生日期，区名，邮编，街道，路名门牌，学籍状态，学生来源，宗教信仰，班长学号)

班长学号作为学生的外码，参照自身的学号。根据实际情况一个班级可以暂时没有班长。所以允许为空。学生n管理1

9.3.3弱实体的表示弱实体如同强实体一样也是要转换成关系模式。只是弱实体一定拥有一个对应的标识实体类型(强实体类型)。将标识实体的主码加入到弱实体的关系模式中作为外码。弱实体的部分码加上外码，构成新关系模式的主码。上图转换关系模式如下：第一步实体的转换：学生(学号，出生日期，区名，邮编，街道，路名门牌，学籍状态，学生来源，宗教信仰)

简历(起始日期，终止日期，所在学校)

第二步联系的转换：简历(学号，起始日期，终止日期，所在学校)学号是简历的外码，参照学生的学号，弱实体对应的关系模式中外码同时也是主属性，不可取空。学生

简历拥有起始日期所在学校终止日期学号1n

9.3.4聚集的表示把聚集看作是一般实体一样对待，此时对聚集无需用单独的关系模式表示，直接将定义该聚集的联系看作高层实体即可。此前介绍的联系集上主码和外码的设置规则，也同样适用于与聚集相关联的联系集。上图转换关系模式如下：教师(工号，姓名，性别，出生日期，民族，职称)课程(课程号，课程名称，总学时，类别)擅长(工号，课程号)班级(班级号，班级名称，班级类型)任课(工号，课程号，班级号，学年，学期)教师课程nm擅长班级任课mn学期学年

9.3.5逻辑结构设计的步骤1.E-R图向关系模型的转换关系模型的逻辑结构是一组关系模式的集合。E-R图则是由实体、实体的属性和实体之间的联系三个要素组成。所以将E-R图转换为关系模型实际上就是将实体及其联系转换为关系模式，其转换原则上面几个小节已做介绍。2.数据模型的优化处理数据库逻辑结构设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还应该根据应用需要适当地修改、调整数据模型的逻辑结构，即做优化处理。通常以规范化理论为指导。规范化到什么程度，是否保留冗余，要根据具体应用系统而定，最后形成全局逻辑模型。3.设计外模式（用户子模式）根据局部应用需求，结合具体DBMS的特点，设计外模式（用户子模式）。定义数据库全局模式主要是从系统的时间效率、空间效率、易维护等角度出发。由于外模式与模式是相对独立的，因此在定义外模式时可以注重考虑用户的习惯与方便及安全性等多方面需求。

9.4E-R模型设计问题

1、E-R模型和规范化好的数据库设计者能够在建立E-R模型时靠直觉经验识别实体、属性和联系，直接得到规范化的关系模式或只需稍许修改即为规范化的关系模式，从而减少后期逻辑结构设计中规范化的工作。而E-R模型设计不好就会在转换后的逻辑结构中出现不合理的数据依赖，此时就要分析数据依赖关系进行规范化处理，避免冗余和异常。设计E-R模型的重要性也正体现在这里，它从一开始就潜移默化地引导着设计者走向规范化的数据库设计。例如：在建立E-R模型时，识别学生实体的属性时把班号和班主任老师作为刻画学生的属性，那么学生实体对应的关系模式为：学生(学号，姓名，性别，入学年月，…，班级号，班主任老师)这里存在“学号

班级号，班级号

班主任老师”这一传递依赖从而导致冗余的发生，根源在于E-R模型设计不好。

9.4E-R模型设计问题

2、用实体还是用属性作为实体要包含刻画它的属性信息，而属性不能再包含刻画它的属性信息，即若有属性还有刻画它的属性，则该属性作为实体来处理更为合适。例如，需求要求“每位员工只在一个办公室办公”，仅此要求的话就可以把办公室房间号作为员工的属性，描述员工的办公地点信息，即可满足需求。但若需求还要求记录房间的房间号、房间名称、使用类别、建筑面积等信息，并且学校每个房间都必须指定一个员工负责。这种需求下，房间不仅是房间号单个属性，还有刻画它的其他属性存在，因此必须作为实体，并且和员工实体建立关联。

9.4E-R模型设计问题

3、二元还是多元联系三元联系关联三个实体，当二元联系无法准确描述关联的语义时，就需要使用三元联系。请看下例，左图能反映出一个班级某门课程由某位教师担任教学工作，右图只能看出一个班级开设有什么课程，该班级有哪些教师任教，但无法知道某个班级某门课程到底是由哪位教师担任教学工作的。具体是采用二元还是多元要分析实际背景下的具体需求，采取不同的设计方案。这点将在后面9.6节需求实例中详细剖析。总之，E-R模型设计受具体需求制约，是一个“仁者见仁，智者见智”的工作。所以这里只能给出设计时常用的原则，具体背景下建立概念模型要因地制宜，灵活应对。班级教师pn课程m开设班级教师课程开设mn擅长mn任教mn

9.5物理结构设计数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于给定的计算机系统。为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构，将逻辑结构设计的结果映射到物理介质上，充分利用可用的硬件和软件功能，实现尽可能快的数据物理访问和维护的过程，就是数据库物理设计的主要任务。它和具体的DBMS产品、系统处理器、内存、存储介质等软硬件都有直接关系，涉及因素诸多。

9.5物理结构设计1、确定数据库的存储结构数据库中要存储的数据主要包括：关系表、数据字典、索引、日志和备份文件等。DBMS对不同数据的物理组织方式通常是不同的。1)确定数据的存放位置为提高系统性能，数据应该根据应用情况将易变部分与稳定部分、经常存取部分和存取频率较低部分分开存放。2)确定数据库存储结构要综合考虑存取时间、存储空间利用率和维护代价三个方面的因素。这三个方面常常是相互矛盾的。例如，消除一切冗余数据虽能够节约存储空间和减少维护代价，但往往会导致检索代价增加。此时必须权衡，选择一个折中方案。

9.5物理结构设计1、确定数据库的存储结构3)确定系统配置DBMS产品一般都提供一些存储分配的参数，比如同时使用数据库的用户数、同时打开的数据库对象数、缓冲区分配参数、时间片大小、数据库的大小、装填因子、锁的数目等，这些参数都影响存取时间和存储空间的分配，在物理设计时要根据应用环境确定这些参数值，使得系统性能最佳。物理设计时对系统配置变量的调整只是初步的，在系统运行时还要根据系统实际运行情况进一步调整，不断改进系统性能。

9.5物理结构设计2、关系模式存取方法的选择确定关系模式的存取方法即建立哪些存取路径。数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。DBMS一般提供多种存取方法，常用存取方法有索引方法，目前主要是B+树索引方法、聚簇方法和HASH方法。B+树索引方法是数据库中经典的存取方法，使用最普遍。创建索引的基本原则4.1.2小节已做介绍，这里不再展开。3、评价物理结构数据库物理设计过程中，需要从时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案。设计人员必须对这些方案进行细致的评价，从中选择一个较优方案作为数据库的物理结构。

9.5物理结构设计4、影响物理设计的因素1)应用处理要求如吞吐量、平均响应时间、系统负荷、事务类型及发生频率等。这些需求直接影响设计方案的选择，而且它们还会随应用环境的变化而变化。2)数据特征数据本身的特性对数据库物理设计也会有较大影响。如关系表中每个属性值的分布、记录的长度与个数等。3)运行环境数据库的物理设计与运行环境有关，在设计时要充分考虑DBMS、操作系统、网络、计算机硬件等运行环境的特征和限制。4)物理设计的调整数据库物理设计是基于数据库当前状况从许多可供选择的方案中选择一个合适的方法。但是随着时间的变化，数据库的状态和特性也会发生变化。因此需对物理设计不断调整，甚至有时需要重新设计。影响物理设计的因素是多方面的，具体设计时要根据软硬件环境，同时考虑应用需求，给出最优方案，并不断调整。

9.6.1系统概述本节以基础教育学校管理信息系统的三个子系统为例，依据用户的特定功能需求，给出概念结构设计和逻辑结构设计的分析过程。现有一个九年一贯制学校，以传统教学模式的自然班为单位组织教学，课表制定中涉及到学生、班级、教师、课程、教室等相关基础信息。本节以涉及到学生基础信息的学籍管理子系统、涉及到教职工和房间基础信息的行政管理子系统和教务中的课表制定子系统为例，分析数据库设计的全过程。通过建立信息系统动态维护基础信息的变更，使得教务制定课表时所需数据完全来自最新的基础信息。通过基础信息的控制确保课表信息的准确性，同时也避免了排课的随意性（本系统不涉及排课约束条件和算法）。

9.6.2学籍管理子系统的需求与概念设计在现实的基础教育信息世界里，学籍系统中需要记录中诸多信息。(1)学生常规信息：学号、姓名、性别、入学年月、年龄、出生日期、民族、身份证号、籍贯、健康状况、血型、居住地址、户口所在地、联系电话，来源学校。(2)和教委信息系统上传相接口，每位学生有全市的统一学籍号。属性识别：学籍号属性，格式按照市里统一规定：六位市区码-四位学校编码-一位学段代码-四位入学年份-四位年级内编码共19位。其中一位学段代码是小学1、初中2、高中3。(3)军烈子女予以特殊关爱。属性识别：是否军烈子女。(4)考虑学生的不同信仰的饮食和文化习俗。属性识别：宗教信仰。(5)区分学生户籍所在地正常入学、外省市转入、外区县转入、引进人才居住证借读、蓝印户口借读、港澳台侨借读、外籍借读等不同入学方式。属性识别：学生来源，属性可取值是以上所述。

9.6.2学籍管理子系统的需求与概念设计(6)记录学生正常就读、休学、退学、开除、转出、死亡等。属性识别：学籍状态，属性可取值是以上所述。(7)学生升学时不同户口有不同的政策处理，升学方式不同。属性识别：户口类别，属性值是本区、外区、外省、外籍、引进人才居住证、蓝印、港澳台等多种类别。(8)记录学生学籍变动(转入转出)信息，包括变动日期、变动原因、审批日期、审批文号、变动来源、变动去向。期初期末批量操作，平时偶尔操作。属性识别：已经不适合做学生实体的属性，增加依赖于学生实体的弱实体学籍变动，以上属性刻画该弱实体。考虑到学生可能在不同学期转入再转出，需要再加上学年、学期属性。(9)记录学生简历信息，包括起始日期、终止日期、所在学校名称、担任职务、证明人、备注。属性识别：已经不适合做学生实体的属性，增加依赖于学生实体的弱实体简历，以上属性刻画该弱实体。

9.6.2学籍管理子系统的需求与概念设计(10)记录班级信息，包括班级编号和班级名称。同一年级会设置不同的班级类型，开设不同的课程，甚至采取不同的考试试卷。一个行政班级至多50位学生，一个学生只属于一个行政班级。每个班级设置一位班长，管理本班学生。记录每位学生所在班的班长信息。属性识别：常规属性班级编号和班级名称。由于同一年级会设置不同的班级类型，需要加上属性班级类型予以区分不同类型班级，也可以更好地和其他子系统的功能相衔接。学生实体内部存在一对多的管理与被管理关系，班级与学生一对多联系。根据以上需求分析，学籍管理子系统概念设计如下图所示。学生拥有1属于n11n1n1n简历拥有2管理学籍变动班级

9.6.3行政管理子系统的需求与概念设计在现实的基础教育信息世界里，行政管理子系统非常庞大，这里只涉及和课表制定相关的员工和房间信息的管理。需求如下：(1)员工（教职工）常规信息：职工号、姓名、身份证号、性别、民族、年龄、工龄、出生日期、健康状况、婚姻状况、政治面貌、籍贯、居住住址、户口所在地、文化程度、联系电话，电子邮箱。属性识别：年龄可由出生日期得到，是派生属性；居住地址是复合属性，分为邮编、所在区和详细地址。联系电话在此是单值属性，每位员工只记录唯一联系电话。其它都是简单且单值属性.(2)考虑员工的不同信仰的饮食和文化习俗。属性识别：宗教信仰。(3)员工分为专职教师，行政两类。属性识别：编制类别。(4)记录员工年份相关信息：参加工作年月、来校年月。若是教师编制，还要记录其从教年份。工龄作为派生属性，可由参加工作年份与当前年份计算得出。(5)区分离职离岗人员和在职在岗人员。属性识别：员工状态。

9.6.3行政管理子系统的需求与概念设计(6)记录员工学历信息，包括学历、所学专业、入学年份、学制、毕业年月、毕业学校、学位，学位授予日期、学位授予单位。这时要增加依赖于员工实体的弱实体学历。属性识别：抽取相关属性，考虑到可能有国外学历，为今后便于查询，加属性学位属于国家。考虑到学历多样性(高校、夜大、函授、研修等)加属性学习形式。考虑到有在职学历进修的可能(脱产、半脱产和业余)，加属性学习方式。(7)记录员工专业技术职称信息，包括任职资格名称、评审单位、评定日期。

增加依赖于员工实体的弱实体专技职称，以上属性刻画该弱实体。(8)员工有行政职务信息，一位员工可以有多个职务，一个职务可以多位员工担任，记录任职开始时间，任职结束时间。行政职务有校长、副校长、书记、副书记、总务主任、工会主席、教导主任等。

识别出实体职务，属性有职务编号、职务名称。职务与员工实体多对多联系。

9.6.3行政管理子系统的需求与概念设计(9)记录学校所有房间信息。每个房间有唯一的责任人，负责管理该房间的安全等问题，责任人可以是教师可以是行政，即员工负责房间，同时记录每个房间的房间号、房间名称、建筑面积、容纳人数、设施情况等信息。每个房间有且仅有一个员工负责，一位员工可以负责多个房间。每位员工在一个办公室办公，一个办公室可以有一名或者多名员工办公。

识别出实体房间，属性有房间编号、房间名称、建筑面积，容纳人数，设施情况。房间与员工实体存在多对一的负责联系和一对多的办公联系。根据以上需求分析，行政管理子系统概念设计如下图所示。员工拥有1办公1nmn1n1n学历拥有2任职专技职称房间职务负责1n

9.6.4课表制定子系统的需求与概念设计在现实的基础教育信息世界里，教务管理子系统非常庞大，这里只考虑课表制定子系统的设计。1、课表制定子系统的用户需求一张以传统教学班为单位的课表包含的信息有学年、学期、上课周几、节次、任课老师、班级、课程名称、上课地点等信息。(1)课程记录其课程号、课程名称、课程类别和总学时。(2)学生记录其学号、学籍号、姓名、性别、入学年月、学籍状态。(3)教师记录其职工号、姓名、出生日期、性别、民族、健康状况、文化程度、联系电话，电子邮箱、从教年份、参加工作年月、来校年月、员工状态、当前专业技术职称信息。教师有多种业务职务，比如教研组长、年级组长、备课组长，一位教师可以有多个职务，一个职务可以在不同时期由不同教师担任，记录任职开始时间，任职结束时间。(4)班级：传统自然班。一个班级最多50位学生。每个班级有一位班主任老师负责。

9.6.4课表制定子系统的需求与概念设计(5)节次：该学校包括小学和初中两个学部，两学部学生第一节课开始时间、每节课课时长度和每天节次都不相同。(6)上课地点：不仅是该班教室、也可能是其它任何可以教学的场所，统称教室。(7)任课教师的选择制约规则与业务流程：新教师入职要登记擅长任教的课程(可以是一门或多门)，当然一门课程可以登记多位擅长教师。每学期由部门教学负责人安排各课程的任课教师：可以依据系统中记录的该课程擅长教师，从中做出选择，安排该教师对该课程的任教班级；也可以选择其他任何教师任教该课程。教务员制定课表：根据部门教学负责人的课程安排，为每门课程安排时间和地点。(8)课表系统需包括生成、查询、打印三大基本功能；功能面向相关教师、学生、教务及行政后勤维保岗位。

9.6.4课表制定子系统的需求与概念设计2、课表功能的概念设计1)实体的识别(1)该学校是包括小学、初中的九年一贯制学校，不同学部开始上课的时间不同，每节课长度不同，每天节次不同。因此节次有诸多刻画它的属性，本身已经不能再做属性，需要定义时间段实体，来区分不同学部的区别，也便于日后动态调整的可能。该实体可定义为：时间段(节次，开始时间，结束时间，适用部门)(2)上课地点不仅是该班教室、也可能是其他任何可作为教学地点的场所，统称教室。每个教室有教室号，教室名称，容纳人数，设施情况等信息。因此上课的教室不仅是教室号单一属性来描述，需要抽取教室实体，可定义为：教室(教室号，教室名称，容纳人数，设施情况)所以课表制定涉及时间段和教室两个实体及三个常规实体班级、教师和课程。

9.6.4课表制定子系统的需求与概念设计2、课表功能的概念设计2)联系的识别仔细研究上面课表制定子系统的需求，理解任课教师选择的制约规则和业务流程，得到实体间的联系。(1)新教师入职登记擅长课程，可以是一门或多门；

教师与课程存在多对多联系“擅长”，该联系不涉及其它实体。(2)部门教学负责人安排各课程的任课教师；可以依据系统中记录的该课程擅长教师，从中做出选择，安排该教师对该课程的任教班级；也可以选择其他任何教师。也就是说理论上全体教师都可以作为某班级该课程的任课教师，因此这时教师、班级、课程三个实体建立多对多的联系“任课”。而不是将联系“擅长”抽象为聚集，再和班级建立二元联系。(3)教务员根据部门教学负责人的课程安排进行课表制定；教务人员根据负责人安排好的教师班级课程对应信息，安排周几、节次和地点，其实是时间段、教室和联系“任课”的聚集三者间建立多对多的关联关系。根据上面分析，可以得知教师、课程和班级三个实体不再如前面图9.22所示表示为三实体间多对多联系或者三实体间两两联系，因为那样无法表达出这里的业务需求。

9.6.4课表制定子系统的需求与概念设计2、课表功能的概念设计2)联系的识别如左下图所示，建立教师实体与课程实体二者的多对多联系，此时与其它实体无关。体现了教师入职时登记擅长课程的要求。如中下图中教师、班级、课程三个实体建立多对多的联系“任课”。表明课程的任课教师可以选择所有教师而不局限于该课程登记的擅长教师，当然可以根据登记的擅长信息推荐该课程的教师。如果需求改为教学负责人只能选择该课程登记的擅长教师任教，则E-R建模如右下图所示。把擅长聚集为高层实体与班级建立多对多联系，体现出班级只和某教师擅长的某门课建立任课联系。教师课程n擅长m教师课程nm擅长班级任课mn学期学年mn教师课程nm擅长班级任课p学期学年

9.6.4课表制定子系统的需求与概念设计2、课表功能的概念设计(2)联系的识别下图将图9.25(b)中任课这个多对多联系聚集为高层实体与时间段、教室建立三实体间的多对多联系，体现出教务人员只能根据负责人安排好的教师班级课程对应信息，安排节次、周几和地点。至此准确建模反映出任课教师选择的制约规则与业务流程的用户需求。擅长教师课程nm班级任课mp教室时间段课表mnp学期学年n周几

9.6.4课表制定子系统的需求与概念设计2、课表功能的概念设计学校实际需求中往往不止是课表，每学期要安排校历信息，记录每个学期的工作开始日期、工作结束日期、学生开学日期和学生放假日期。根据校历信息安排每周教学和学生活动，排课、考试安排等功能也都和学期周密不可分。这时，不能单纯考虑排课的单一需求，统观全局，学年学期不再做属性，而是抽取为实体。学期(学年，学期，工作开始日期，工作结束日期，学生开学日期，学生放假日期)

9.6.4课表制定子系统的需求与概念设计2、课表功能的概念设计因此，将任课这个三实体联系改为教师、课程、班级和学期四实体间的多对多联系，同加上学生与班级的多对一联系和教师与职务的多对多联系，形成课表制定子系统的概念模型，如下图所示。负责班级教师11学期任课mp教室时间段课表mnpn周几课程q职务任职mn擅长mn学生n属于1

9.6.5子系统视图的集成合并三个子系统的分E-R图，得到整个系统的总E-R图。1、属性冲突两个子系统中职务实体的属性职务名称的属性值不同。行政管理子系统中职务实体的属性职务名称是行政职务，如校长、副校长、书记、副书记、总务主任、工会主席、教导主任等。而在教务的课表制定子系统中职务实体的属性职务名称是教师的业务职务，如教研组长、年级组长、备课组长。解决方法：两个子系统的职务实体合并，在职务实体中增加属性职务类别，以区分不同的分类方法，1表示行政职务，2表示业务职务。

9.6.5子系统视图的集成合并三个子系统的分E-R图，得到整个系统的总E-R图。2、结构冲突(1)同一对象在不同应用中具有不同的抽象。行政管理子系统中记录员工专业技术职称信息，包括任职资格名称、评审单位、评定日期，这里记录该员工历史职称信息详情。在教务的课表制定子系统中专业技术职称只作为属性，表明该教师当前职称信息，不关心历史职称信息详情。解决方法：把属性变换为实体，统一为专业技术职称实体，在该实体中加属性是否当前职称。

9.6.5子系统视图的集成合并三个子系统的分E-R图，得到整个系统的总E-R图。2、结构冲突(2)同一实体在不同E-R图中所包含的属性个数不同。教务的课表制定子系统中教师实体的属性只是行政管理子系统中员工属性的一部分，而且只关心教师的信息，与行政人员无关。教务的课表制定子系统中学生实体的属性只是学籍管理子系统中学生属性的一部分。解决方法：取并集，这里就是取行政管理子系统中员工的属性列表和学籍管理子系统中学生的属性列表。

9.6.5子系统视图的集成合并三个子系统的分E-R图，得到整个系统的总E-R图。2、结构冲突(3)其他冲突：教师与房间。行政管理子系统中记录所有房间的基本信息、办公信息和责任人信息。而在教务的课表制定子系统中仅关注其中可以进行教学的场所，即教室信息，当行政管理子系统中房间信息做出变更时，会影响教务的课表制定子系统。所以必须使二者实现同步变更。解决方法：属性取二者并集，并增加新属性房间使用类别，以区分可以教学的场所。1表示办公，2表示教室，3表示会议室，4表示报告厅，5表示校园网络机房。

9.6.5子系统视图的集成合并后的系统的总E-R图如图9.28所示。

1n学生拥有1属于1n1n1n1简历拥有2管理学籍变动员工拥有4办公1n1n学历拥有3任职专技职称/职务负责2负责111任课mp课表mnpnq擅长mn

班级是否当前职称职务类别使用类别1111nn任职mmnn教师学期课程房间时间段属于2说明：(1)由于实体属性众多，上图中只标出集成时增加的属性。(2)上面分析得出：课表制定子系统中教师实体集只是取行政管理子系统员工实体集的一部分，集成时取员工的属性列表。为了方便设计各子系统外模式，图9.28中仍然标出教师实体，但在后面设计全局逻辑模式时教师实体并不转换成关系模式。

9.6.6逻辑结构设计1、E-R图向关系模型的转换(1)学生实体：学生实体中年龄可由出生日期得到，是派生属性，转换时不作保留；居住地址是复合属性，代之以区名，邮编，街道，路名门牌；联系电话是多值属性转换成关系模式。其他属性如前面9.6.2节中分析所得。学生实体内部存在一对多联系，加班长学号属性。学生与班级多对一联系，在学生关系模式中加班级编号属性逻辑结构如表9.2所示。考虑到篇幅关系仅以学生基本信息表为例，给出详细的逻辑结构，其它只给出其关系模式中的属性列表，不再以表格形式列出详细设计信息。下划线表示主码，斜体字表示外码，不再加文字说明。

9.6.6逻辑结构设计1、E-R图向关系模型的转换(2)学生实体的弱实体和多值属性：弱实体转换时加上所依赖实体的主码：简历(学号，起始日期，终止日期，所在学校名称，担任职务，证明人，备注)

学籍变动(学号，学年，学期，变动日期，变动原因，审批日期，审批文号，变动来源，变动去向)学生实体的多值属性联系电话，转换成新的关系模式：学生联系电话(学号，电话号码)

9.6.6逻辑结构设计1、E-R图向关系模型的转换(3)员工实体：员工实体中工龄可由参加工作年月得到，是派生属性；年龄可由出生日期得到，是派生属性，转换时都不作保留；居住地址复合属性代之以邮编、所在区和详细地址；其他