第二章 数据库的概念结构设计.docx
《第二章 数据库的概念结构设计.docx》由会员分享，可在线阅读，更多相关《第二章 数据库的概念结构设计.docx（25页珍藏版）》请在冰点文库上搜索。
第二章数据库的概念结构设计
第二章数据库的概念结构设计
将需求分析得到的用户需求抽象为信息结构（即概念模型）的过程就是概念结构设计。
它是整个数据库设计的关键步骤。
本章主要介绍以下内容：
•数据模型。
•概念模型。
•概念结构设计的方法与步骤。
第一节数据模型
一、数据
数据是数据库中存储的基本对象，也是数据模型的基本元素。
1．数据
在数据库中描述事物的符号记录称为数据，是存储的基本对象。
计算机是人们解决问题的辅助工具，而解决问题的前提是对问题存在条件及环境参数的正确描述，在现实世界中人们可以直接用自然语言来描述世界，为了把这些描述传达给计算机，就要将其抽象为机器世界所能识别的形式。
例如，我们在现实世界中用以下语言来描述一块主板：
编号为0001的产品为“技嘉主板”，其型号为GA-8IPE1000-G，前端总线800MHz。
如果将其转换为机器世界中数据的一种形式则为：
0001，技嘉主板，GA-8IPE1000-G，800MHz。
因此从现实世界中的数据到机器世界中的符号记录形式的数据，还需要一定的转换工作。
2．数据描述
在数据库设计的不同阶段都需要对数据进行不同程度的描述。
在从现实世界到计算机世界的转换过程中，经历了概念层描述、逻辑层描述及存储介质层描述三个阶段。
在数据库的概念设计中，数据描述体现为“实体”、“实体集”、“属性”等形式，用来描述数据库的概念层次；在数据库的逻辑设计中，数据描述体现为“字段”、“记录”、“文件”、“关键码”等形式，用来描述数据库的逻辑层次；在数据库的具体物理实现中，数据描述体现为“位”、“字节”、“字”、“块”、“桶”、“卷”等形式，用来描述数据库的物理存储介质层次。
二、数据模型
模型是对现实世界中的事物、对象、过程等客观系统中感兴趣的内容的模拟和抽象表达。
如一座大楼模型、一架飞机模型就是对实际大楼、飞机的模拟和抽象表达，人们从模型可以联想到现实生活中的事物。
数据模型也是一种模型，它是对现实世界数据特征的抽象。
数据模型一般应满足三个要求：
一是能比较真实地模拟现实世界；二是容易被人们理解；三是便于在计算机上实现。
一种数据模型能同时满足这三方面的要求在目前是比较困难的，所以在数据库系统中可以针对不同的使用对象和应用目的采用不同的数据模型。
不同的数据模型实际上是提供给我们模型化数据和信息的工具。
根据模型应用的不同目的，可以将这些模型划分为两大类：
概念层数据模型与组织层数据模型。
三、信息的三个世界
各种机器上实现的DBMS软件都是基于某种数据模型的。
需要以某种数据模型为基础来开发建设的，因此需要把现实世界中的具体事物抽象、组织为与各种DBMS相对应的数据模型，这是两个世界间的转换，即从现实世界到机器世界。
但是这种转换在实际操作起来，不是能够直接执行的，还需要一个中间过程，这个中间过程就是信息世界（如图2-1所示）。
通常人们首先将现实世界中的客观对象抽象为某种信息结构，这种信息结构可以不依赖于具体的计算机系统，也不与具体的DBMS相关，因为它不是具体的数据模型，而是概念级模型，也就是我们前面所说的概念层数据模型，一般简称为概念模型；然后再把概念模型转换到计算机上具体的DBMS支持的数据模型，这就是组织层数据模型，一般简称为数据模型。
图2-1信息的三个世界
在这三个世界间的两种转换过程就是数据库设计中的两个设计阶段，从现实世界抽象到信息世界的过程是概念结构设计阶段，这就是本章要介绍的内容。
从信息世界抽象到机器世界的过程是数据库的逻辑结构设计，其任务就是把概念结构设计阶段设计好的概念模型转换为与选用的DBMS所支持的数据模型相符合的逻辑结构。
为一个给定的逻辑数据模型选取一个适合应用要求的物理结构的过程是数据库的物理设计。
数据库的逻辑结构设计与物理设计将在第三章介绍。
第二节概念模型
概念模型是现实世界到机器世界的一个中间层次，是现实世界的第一个层次抽象，是用户与设计人员之间进行交流的语言。
在进行数据库设计时，如果将现实世界中的客观对象直接转换为机器世界中的对象，注意力往往被转移到更多的细节限制方面，就会感到非常不方便，而且也不能集中在最重要的信息的组织结构和处理模式上。
因此，通常是将现实世界中的客观对象首先抽象为不依赖任何具体机器的信息结构，这种信息结构就是概念模型。
在进行数据库设计时，概念设计是非常重要的一步，通常对概念模型有以下要求：
（1）真实、充分地反映现实世界中事物和事物之间的联系，有丰富的语言表达能力，能表达用户的各种需求，包括描述现实世界中各种对象及其复杂的联系、用户对数据对象的处理要求的手段。
（2）简明易懂，能够为非计算机专业的人员所接受。
（3）容易向数据模型转换。
易于从概念模式导出与数据库管理系统有关的逻辑模式。
（4）易于修改。
当应用环境或应用要求改变时，容易对概念模型修改和补充。
一、基本概念
在概念模型中涉及的主要概念有：
（1）实体（Entity）：
客观存在并可相互区别的事物称为实体。
实体可以是具体的人、事、物，例如一名学生，一门课程等；也可以是抽象的概念或联系，例如一次选课，一场竞赛等。
（2）属性（Attribute）：
每个实体都有自己的一组特征或性质，这种用来描述实体的特征或性质称为实体的属性。
例如，学生实体具有学号、姓名、性别等属性。
不同实体的属性是不同的。
实体属性的某一组特定的取值（称为属性值）确定了一个特定的实体。
例如，学号是0611001、姓名是王冬、性别是女等等，这些属性值综合起来就确定了“王冬”这名同学。
属性的可能取值范围称为属性域，也称为属性的值域。
例如，学号的域为8位整数，姓名的域为字符串集合，性别的域为（男，女）。
实体的属性值是数据库中存储的主要数据。
根据属性的类别可将属性分为基本属性和复合属性。
基本属性（也称为原子属性）是不可再分割的属性。
例如，性别就是基本属性，因为它不可以再进一步划分为其它子属性。
而某些属性可以划分为多个具有独立意义的子属性，这些可再分解为其它属性的属性就是复合属性（也称为非原子属性）。
例如，地址属性可以划分为邮政编码、省名、市名、区名和街道5个子属性，街道可以进一步划分为街道名和门牌号码两个子属性。
因此，地址属性与街道都是复合属性。
根据属性的取值可将属性分为单值属性和多值属性。
同一个实体只能取一个值的属性称为单值属性。
多数属性都是单值属性。
例如，同一个人只能具有一个出生日期，所以人的生日属性是一个单值属性。
同一实体可以取多个值的属性称为多值属性。
例如，一个人的学位是一个多值属性，因为有的人具有一个学位，有的人具有多个学位；再如零件的价格也是多值属性，因为一种零件可能有代销价格、批发价格和零售价格等多种销售价格。
（3）码（Key）：
唯一标识实体的属性集称为码。
例如学号是学生实体的码。
码也称为关键字或简称为键。
（4）实体型（EntityType）：
具有相同属性的实体必然具有共同的特征和性质。
用实体名及其属性名集合来抽象和刻画同类实体，称为实体型。
例如学生（学号，姓名，性别）就是一个实体型。
（5）实体集（EntitySet）：
性质相同的同类实体的集合，称为实体集。
例如全体学生就是一个实体集。
由于实体、实体型、实体集的区分在转换成数据模型时才考虑，因此在本章后面的叙述中，在不引起混淆的情况下，将三者统称为实体。
二、实体间的联系
现实世界中，事物内部以及事物之间不是孤立的，是有联系的，这些联系反映在信息世界中表现为实体内部的联系和实体之间的联系。
我们这里主要讨论实体之间的联系。
例如“职工在某部门工作”是实体“职工”和“部门”之间的联系，“学生在某教室听某老师讲的课程”是“学生”、“教室”、“老师”和“课程”等四个实体之间有联系。
1．联系的度
联系的度是指参与联系的实体类型数目。
一度联系称为单向联系，也称递归联系，指一个实体集内部实体之间的联系（如图2-2（c））。
二度联系称为两向联系，即两个不同实体集实体之间的联系（如图2-2（b））。
三度联系称为三向联系，即三个不同实体集实体之间的联系（如图2-2（a））。
虽然也存在三度以上的联系，但较少见，在现实信息需求中，两向联系是最常见的联系，下面讲的联系如无特殊情况都是指这种联系。
图2-2联系的度的示例
2．联系的连通词
联系的联通词（Connectivity），指的是联系涉及到的实体集之间实体对应的方式。
例如一个实体集中的某一个实体与另外一个实体集中的一个还是多个实体有联系。
两向联系的连通词有三种：
一对一；一对多；和多对多。
（1）一对一联系。
如果实体集A中的每一个实体在实体集B中至多有一个实体与之联系，反之亦然，则称实体集A与实体集B具有一对一联系，记为1:
1。
例如，一个学院有一个院长，而一个院长也只能管理这一个学院，学院和院长之间建立起“领导”联系，因此这个联系是一个“一对一”的联系（如图2-3（a））。
（2）一对多联系。
如果实体集A中的每一个实体在实体集B中有n（n≥0）个实体与之联系，而实体集B中的每一个实体在实体集A中至多有一个实体与之联系，则称实体集A与实体集B具有一对多联系，记为1:
n。
例如，一个学院有多名教师，而一个教师只能隶属于某一个特定的学院，则学院与教师之间建立起的这种“所属”联系就是一个“一对多”的联系（如图2-3（b））。
（3）多对多联系。
如果实体集A中的每一个实体在实体集B中有n（n≥0）个实体与之联系，而实体集B中的每一个实体在实体集A中有m（m≥0）个实体与之联系，则称实体集A与实体集B具有多对多联系，记为m:
n。
例如，一名教师可以讲授多门课程，同时，一门课程也可以由多名教师讲授，因此课程和教师之间的这种“讲授”联系就是“多对多”的联系（如图2-3（c））。
图2-3联系的示例
3．联系的基数
在“一对一”、“一对多”和“多对多”的联系中，把两个实体集中有联系的实体的联系数量分成两种类型：
“唯一”和“不唯一”。
但现实中有时需要更精确的描述，例如：
学校规定除毕业班外，对于全校公选课，学生每学期至少选修1门课程，最多选修5门课程；每门课程最少要有15个人选，最多不能超过150人。
对于这种情况，首先确定学生的基数是（1，5），课程的基数是（15，150）。
这种有联系的实体数目的最小值（min）和最大值（max）称为这个联系的基数，用（min，max）形式表示。
第三节概念结构设计的方法与步骤
数据库的概念结构设计是通过对现实世界中信息实体的收集、分类、聚集和概括等处理，建立数据库概念结构（也称为概念模型）的过程。
一、概念结构设计的方法与步骤概述
1．概念结构设计的方法
概念数据库设计的方法主要有两种：
一种是集中式设计方法，另一种是视图综合设计方法。
（1）集中式设计方法。
集中式设计方法首先合并在需求分析阶段得到的各种应用的需求；其次在此基础上设计一个概念数据库模式，满足所有应用的要求。
一般数据库设计都具有多种应用，在这种情况下，需求合并是一项相当复杂和耗费时间的任务。
集中式方法要求所有概念数据库设计工作都必须由具有较高水平的数据库设计者完成。
（2）视图综合设计方法。
视图综合设计方法由一个视图设计阶段和一个视图合并阶段组成，不要求应用需求的合并。
在视图设计阶段，设计者根据每个应用的需求，独立地为每个用户和应用设计一个概念数据库模式，这里每个应用的概念数据库模式都称为视图。
视图设计阶段完成后，进入到视图合并阶段，在此阶段设计者把所有视图有机地合并成一个统一的概念数据库模式，这个最终的概念数据库模式支持所有的应用。
这两种方法的不同之处在于应用需求合成的阶段与方式的不同。
在集中式设计方法中，需求合成由数据库设计者在概念模式设计之前人工地完成，也就是在分析应用需求的同时进行需求合成，数据库设计者必须处理各种应用需求之间的差异和矛盾，这是一项艰巨任务，而且容易出错。
由于这种困难性，视图综合设计方法已经成为目前的重要概念设计方法。
在视图综合设计方法中，用户或应用程序员可以根据自己的需求设计自己的局部视图。
然后，数据库设计者把这些视图合成为一个全局概念数据库模式。
而且当应用很多时，视图合成可以借助于辅助设计工具和设计方法的帮助。
2．概念结构设计的步骤
概念结构的设计策略主要有自顶向下、自底向上、自内向外和混合策略四种。
自顶向下就是先从整体给出概念结构的总体框架再逐步细化；自底向上就是先给出局部概念结构再进行全局集成；自内向外就是先给出核心部分的概念结构再逐步扩充；混合策略是自顶向下方法与自底向上方法的结合。
这些方法中最常用的是自底向上方法，下面就介绍基于自底向上方法的概念设计的步骤。
（1）设计局部概念模式。
先从局部用户需求出发，为每个用户建立一个相应的局部概念结构。
在此过程需要对需求分析的结果进行细化、补充和修改，例如数据项的拆分，数据定义的修改等。
设计概念结构时，常用的数据抽象方法是“聚集”和“概括”。
聚集是将若干对象和它们之间的联系组合成一个新的对象。
概括是将一组具有某些共同特性的对象合并成更高一层意义上的对象。
（2）综合局部概念模式成全局概念模式。
这一步骤主要是综合各局部概念结构，得到反映所有用户需求的全局概念结构。
在这一过程中，主要处理各局部模式对各种对象定义的不一致等各种冲突问题，同时还要注意解决各局部结构合并时可能产生的冗余问题等，必要时还需要对信息需求再调整、分析与重定义。
（3）评审。
最后一步是把全局结构提交评审。
评审分为用户评审与开发人员评审两部分。
用户评审的重点是确认全局概念模式是否准确完整地反映了用户的信息需求，是否符合现实世界事物属性间的固有联系；开发人员评审则侧重于确认全局结构是否完整，各种成分划分是否合理，是否存在不一致性，以及各种文档是否齐全等。
在数据库的建设过程中，从现实需求到实现应用程序的转换过程是以数据为驱动的。
从定义需求开始，收集与业务对象及其相关对象需要包括的数据，然后设计数据库以支持业务，设计初始过程，最后实现需求。
这种数据驱动的方法相对于传统的过程驱动方法更具有灵活性，在设计出包含与业务相关的所有数据的数据库之后，可以轻易的添加进一步的过程，为后期新的及附加的处理要求做好了准备。
二、采用E-R模型方法的概念结构设计
数据库概念结构设计的核心内容是概念模型的表示方法。
概念模型的表示方法有很多，其中最常用的是由PeterChen于1976年在题为“实体联系模型：
将来的数据视图”论文中提出的实体-联系方法，简称E-R模型。
该方法用E-R图来表示概念模型。
由于E-R模型经过多次扩展和修改，出现了许多变种，其表达的方法没有统一的标准。
但是，绝大多数E-R模型的基本构件相同，只是表示的具体方法有所差别。
本书中的符号采用较为常用和流行的表示方法。
1．E-R模型的基本元素
E-R模型的基本元素包括实体、联系和属性，图2-4显示了它们的图形符号。
图2-4E-R模型基本元素的图形符号
（1）实体：
在E-R图中用矩形表示，并将对实体的命名写于矩形中。
（2）属性：
在E-R图中用椭圆表示（对于多值属性用双椭圆表示），并将对属性的命名写于其中。
（3）联系：
用来标识实体之间的关系，在E-R图中用菱形表示，联系的名称置于菱形内。
需要说明的是，除了实体具有若干个属性外，有的联系也具有属性。
在E-R图中，除了上述三种基本的图形之外，还有将属性与相应的实体或联系连接起来以及将有关实体连接起来的无向边。
另外，在连接两个实体之间的无向边旁还要标注上联系的类型（1:
1，1:
n或m:
n）。
例如图2-5为表示部门和部门主任之间联系的E-R图。
图2-5部门和部门主任之间联系的E-R图
在E-R图中，加下划线的属性（或属性组）表示实体的码，如图2-5中，部门编号是部门实体的码，人员编号是部门主任实体的码。
例2.1现有图书管理的信息如下：
图书信息包括：
书号、书名、作者、出版社、所属类别、单价。
出版社信息包括：
社号、社名、地址、电话。
读者信息包括：
借书证号、姓名、性别、所属院系。
一个出版社可以出版多种书籍，但每本书只能在一个出版社出版，出版应有出版日期和责任编辑。
一个读者可以借阅多本图书，一本图书可以有多个人借阅。
借阅信息包括：
借书日期、还书日期。
根据以上信息，要求完成以下任务：
（1）确定实体及其包含属性，以及各实体的码。
（2）确定各实体之间的联系，并设计图书管理情况的E-R图。
解：
（1）本例包括图书、出版社、读者三个实体，其中图书实体包含书号、书名、作者、出版社、所属类别、单价6个属性，其中书号为码；出版社实体包含社号、社名、地址、电话4个属性，其中社号为码；读者实体包含借书证号、姓名、性别、所属院系4个属性，其中借书证号为码。
（2）出版社与图书两个实体之间为1:
n联系，联系名为出版，该联系含有出版日期和责任编辑两个属性；读者与图书两个实体之间为m:
n联系，联系名为借阅，该联系含有借书日期、还书日期2个属性。
图书管理情况的E-R图如图2-6所示。
图2-6图书管理情况的E-R图
2．E-R模型的一些变换操作
用E-R模型方法进行数据库概念设计时，有时需要对E-R模型作一些变换操作。
（1）引入弱实体。
所谓弱实体，是指一个实体对于另一个（些）实体具有很强的依赖联系，而且该实体码的部分或全部从其父实体中获得。
在E-R模型中，弱实体用双线矩形框表示，与弱实体直接相关的联系用双线菱形框表示（如图2-7所示）。
在图2-7中，“教师简历”实体与“教师”实体具有很强的依赖联系，“教师简历”实体是依赖于“教师”实体而存在的，而且教师简历的码从教师中获得。
因此“教师简历”是“弱实体”。
图2-7“弱实体”示例
（2）多值属性的变换。
对于多值属性，如果在数据库的实施过程中不作任何处理，将会产生大量冗余数据，而且使用时有可能造成数据的不一致。
因此要对多值属性进行变换。
主要有两种变换方法，第一种变换方法是对多值属性进行分解，即把原来的多值属性分解成几个新的属性，并在原E-R图中用分解后的新属性替代原多值属性。
例如，对于“教师”实体，除了“姓名”、“性别”、“年龄”等单值属性外，还有多值属性“毕业院校”（如图2-8所示），变换时可将“毕业院校”分解为“本科毕业院校”、“硕士毕业院校”、“博士毕业院校”3个单值属性，变换后的E-R图如图2-9所示。
图2-8多值属性示例
图2-9多值属性的变换—分解示例
如果一个多值属性的值较多，在分解变换时可能会增加数据库的冗余量。
针对这种情况还可以采用另外一种方法进行变换：
增加一个弱实体，原多值属性的名变为弱实体名，其多个值转变为该弱实体的多个属性，增加的弱实体依赖于原实体而存在，并增加一个联系（如图2-10中的“教育经历”），且弱实体与原实体之间是1：
1联系。
变换后的E-R图如图2-10所示。
图2-10多值属性的变换—增加弱实体示例
（3）复合属性的变换。
对于复合属性可以用层次结构来表示。
例如“地址”作为公司实体的一个属性，它可以进一步分为多层子属性（如图2-11所示）。
复合属性不仅准确模拟现实世界的复合层次信息结构，而且当用户既需要把复合属性作为一个整体使用也需要单独使用各子属性时，属性的复合结构不仅十分必要，而且十分重要。
图2-11复合属性的变换示例
（4）分解变换。
如果实体的属性较多，可以对实体进行分解。
例如，对于雇员实体，拥有编号、姓名、性别、生日、部门号、职务、工资、奖金等属性（其E-R图如图2-12所示）。
可以把雇员的信息分解为两部分，一部分属于雇员的基本信息，一部分归为变动信息。
为了区别这两部分信息，此时会衍生出一个新的实体，并且新增加一个联系，分解后的E-R图如图2-13所示。
图2-12雇员实体E-R图
图2-13雇员实体分解后E-R图
3．用E-R模型方法进行数据库概念设计
利用E-R模型对数据库进行概念设计，可以分成三步进行：
第一步设计局部E-R模型，即逐一设计分E-R图，第二步把各局部E-R模型综合成一个全局E-R模型，第三步对全局E-R模型进行优化，得到最终的E-R模型，即概念模型。
（1）设计局部E-R模型。
局部概念模型设计可以以用户完成为主，也可以以数据库设计者完成为主。
如果是以用户为主，则局部结构的范围划分就可以依据用户进行自然划分，也就是以企业各个组织结构来划分，因为不同组织结构的用户对信息内容和处理的要求会有较大的不同，各部分用户信息需求的反应就是局部概念E-R模型。
如果以数据库设计者为主，则可以按照数据库提供的服务来划分局部结构的范围，每一类应用可以对应一类局部E-R模型。
确定了局部结构范围之后要定义实体和联系。
实体定义的任务就是从信息需求和局部范围定义出发，确定每一个实体类型的属性和码，确定用于刻画实体之间的联系。
局部实体的码必须唯一的确定其他属性，局部实体之间的联系要准确地描述局部应用领域中各对象之间的关系。
实体与联系确定下来后，局部结构中的其他语义信息大部分可用属性描述。
确定属性时要遵循两条原则：
第一，属性必须是不可分的，不能包含其他属性；第二，虽然实体间可以有联系，但是属性与其他实体不能具有联系。
下面举一个设计局部E-R模型的例子。
例2.2设有如下运动队和运动会两个方面的实体集：
运动队方面：
运动队：
队编号、队名、教练名
运动员：
姓名、性别、项目
其中，一个运动队有多个运动员，一个运动员仅属于一个运动队，一个队一般有一个教练。
运动会方面：
运动员：
编号、姓名、性别
项目：
项目名、比赛场地
其中，一个项目可由多个运动员参加，一个运动员可参加多个项目，一个项目在一个比赛场地进行。
要求：
分别设计运动队和运动会两个局部E-R图
解：
运动队局部E-R图如图2-14所示，运动会局部E-R图如图2-15所示。
图2-14运动队局部E-R图
图2-15运动会局部E-R图
（2）集成全局E-R模型。
全局概念结构不仅要支持所有局部E-R模型，而且必须合理地表示一个完整、一致的数据库概念结构。
经过了第一个步骤，虽然所有局部E-R模型都已设计好，但是因为局部概念模式是由不同的设计者独立设计的，而且不同的局部概念模式的应用也不同，所以局部E-R模型之间可能存在很多冲突和重复，主要有属性冲突、结构冲突、命名冲突和约束冲突。
集成全局E-R模型的第一步就是要修改局部E-R模型，解决这些冲突。
•属性冲突。
属性冲突又包括属性域冲突和属性取值单位冲突。
属性域冲突主要指属性值的类型、取值范围或取值集合不同。
例如学号有的定义为字符型，有的定义为整型。
属性取值单位冲突主要指相同属性的度量单位不一致。
例如重量有的用公斤为单位，有的用克为单位。
•命名冲突。
主要指属性名，实体名，联系名之间的冲突。
主要有两类：
同名异义，即不同意义的对象具有相同的名字；异名同义，即同一意义的对象具有不同的名字。
如例2.2中两个局部E-R图中对项目名这一相同对象具有不同的属性名。
解决以上两种冲突比较容易，只要通过讨论，协商一致即可。
•结构冲突。
结构冲突又包括两种情况：
一种是指同一对象在不同应用中具有不同的抽象，即不同的概念表示结构。
如在一个概念模式中被表示为实体，而在另一个模式中被表示为属性。
在例2.2中，项目在运动队概念模式中被表示为属性，而在运动会概念模式中被表示为实体。
解决这种冲突的方法通常是把属性变换为实体或把实体转换为属性，如何转换要具体问题具体分析。
另一种结构冲突是指同一实体在不同的局部E-R图中所包含的属性个数和属性的排列次序不完全相同。
如在例2.2中，运动员实体在运动队局部E-R图中所包含的属性个数与运动会局部E-R图中所包含的属性个数不同。
解决这种冲突的方法是让该实体的属性为各局部E-R图中的属性的并集。
•约束冲突。
主要指实体之间的联系在不同的局部E-R图中呈现不同的类型。
如在某一应用中被定
升级会员 