【数据库原理】概念结构、逻辑结构设计案例

概念结构设计宏观步骤.

依据案例的数据流图DFD以及数据字典DD:

  • 建立局部E-R模型
  • 合并优化多个局部E-R模型
  • 得到全局E-R模型

局部E-R模型设计.

以学校中的教师任课以及学生选课关系为例,分析其中所涉及的数据结构以及多个数据结构间的联系,可以得到如下所示的实体间的语义约定:

  • 一名学生可以选修多门课程,一门课程也可以被多名学生选修,所以课程实体与学生实体之间的选课关系是一个1:n的联系;
  • 一个系别可以拥有多名学生,而一个学生只能属于一个系别,所以学生实体和系别实体之间的属于关系是一个n:1的联系;
  • 一个系别可以开设多门课程,而一门课程只能由一个系别开设,所以系别实体和课程实体之间的开设关系是一个1:n的联系;
  • 一名教师可以教授多门课程,一门课程也可以由多名教师合作教授,所以课程实体与教师实体之间的任课关系是一个m:n的联系;
  • 一个系别可以聘请多名教师,而一个教师却只能被一个系别所聘请,所以系别实体和教师实体之间的聘请关系是一个1:n的联系;

将上述合乎常理的语义约定中,涉及的数据结构转化为E-R图中的实体,涉及的联系转化为E-R图中的联系,得到的部分E-R图如下所示:
在这里插入图片描述
在这里插入图片描述

E-R图冲突.

1.属性冲突.

  • 值域冲突】属性的类型、取值范围或取值集合不同,以学号为例,可以将其定义为数值型,也可以将其定义为字符型;再比如年龄,既可以用出生年月暗示,也可以之间使用数值表示的年龄;
  • 取值单位冲突】例如学生体重,可使用Kg为单位衡量,又可以使用g为单位衡量。

属性冲突属于用户业务上的约定,与用户进行协商后具体解决即可,例如统一学生的学号为字符型,因为可能包括A、B、C,体重统一用T为单位衡量,因为学生不愿意看到自己的体重是一个大数值。

2.命名冲突.

有关命名的冲突可能发生在实体名、属性名和联系名之间,最为常见的属性名之间的冲突,大多表现为同名异义或异名同义的语义歧义问题,也不知道语文是怎么学的。

  • 同名异义】源于中华文化的博大精深,例如“单位”这个属性,在某些情况下代表一个人工作的组织;另外的应用环境中又表示衡量物体某种属性的基准;
  • 异名同义】再一次源于中华文化的博大精深,比如说我的手机号码是12345678999,它可以被称为“联系方式”,也可以被称为“手机号码”,还能被称为“取件凭证”。

命名冲突和属性冲突类似,需要与用户协商后具体解决。

3.结构冲突.

  • 同一个对象在不同的应用中有不同的抽象,可能既是实体又是属性,例如系别作为一个表示学校中某个专业的实体,也可以是学生实体的属性之一。
    这类冲突在解决时需要统一对于对象的抽象,或将实体转换为属性,或将属性转换为实体。
  • 同一个实体在不同应用场景下的组成属性不同。
    解决方法是统一属性集为各个局部E-R图中属性集的并集。
  • 同一个联系在不同的应用场景下呈现不同的类型,可能在一个局部E-R图中是1:n的联系,在另外的E-R图中是1:1的联系。
    解决这类冲突时需要根据语义对联系进行调整。

合并局部E-R模型.

首先我们发现,学生选课局部E-R图和教师任课局部E-R图中存在实体的【异名同义】现象,前者的【】实体和后者的【单位】实体实际上代表的都是学院中的某个专业,并且这两个实体还存在属性组成的冲突,其中的属性【名称】和【单位名】还属于属性的异名同义,需要进行统一以及对属性集的求并操作。
再观察发现两个局部图中的【课程】实体存在结构冲突,它们的属性集不一致,需要进行求并操作。
解决上述的冲突之后,得到的初步E-R图如下所示:
在这里插入图片描述

E-R图冗余.

冗余分为数据冗余和实体联系冗余。

  • 数据冗余】可以由基本数据导出的数据,例如学生选修各门课程的单项成绩以及平均成绩,后者就是可以由前者导出的冗余数据。
  • 联系冗余】可以由其他联系导出的联系,例如支付宝提供共享单车、共享单车方便人类以及支付宝服务人类,第三个联系就是可以由前两个联系导出的冗余联系。不是打广告,就是想不出好的例子了。

消除冗余的方法基于分析得出,这就是前面数据库规范化理论的意义所在了。

优化初步E-R图.

上面给出的初步E-R图中存在着冗余数据和冗余联系,例如教师号这一属性,在教师实体中出现了一次,而在课程实体中又出现了一次(仔细思考发现课程实体,和教师号并没什么必然联系,每一年不同的老师教同一门课程,每一个老师也教着不同的课程);学生的平均成绩属性可以由选修关系的成绩属性经过处理得出。【教师教授课程】以及【教师属于系别】两个联系能够推导出【系别开设课程】这一联系,所以第三者属于冗余的联系。
经过优化之后,得到的基本E-R图如下所示,至此可以开始逻辑结构的设计。
在这里插入图片描述

关系模式转换.

前面的得到了教务管理系统的基本E-R图,后续进行关系数据库逻辑设计就是要得到一组关系模式的集合,所以将E-R图转换为关系模型就是将实体、属性以及联系转换成关系模式。转换时的原则如下所示:

  • 实体-关系模式】实体的属性就是关系的属性,实体的主码就是关系的主码。
  • 联系-关系模式】关系的属性是该联系本身的属性以及联系涉及到的那些实体的主码,关系的主码需要根据联系的类型来确定:
    1:1关系的主码可以是涉及到实体中任意一个的主码;
    1:n关系的主码是n那端实体的主码;
    m:n关系的主码是每个实体主码的组合。
  • 特殊情况】三个及以上的实体组成的多元联系,转换的具体方法是将所有实体的主码组合,成为多元关系模式的主码,多元关系模式的属性集即为所有实体的主码集合并上关系本身的属性集合。

在这里插入图片描述
回顾前面得到的基本E-R图,我们对于其中的实体进行转化:

  • 学生(学号、姓名、性别、年龄)
  • 课程(课程号、课程名)
  • 系(系编号、系名、电话)
  • 教师(教师号、姓名、性别、职称)

后续对于其中的联系进行转化:

  • 选修(学号、课程号、成绩)
  • 讲授(教师号、课程号)
  • 属于(教师号、系编号)
  • 拥有(学号、系编号)

上述关系模式的转化是基于全局E-R模型得到的,因此上述关系模型满足3NF,后续如果有更严格的要求,可以继续向BCNF以及4NF规范化。

合并关系模式.

上面依据全局E-R图转化得到的关系模式集合中,存在一些能够合并的关系模式。原则是合并那些具有相同主码的关系模式,例如【学生】与【拥有】、【教师】与【属于】,合并之后的关系模式如下所示:

  • 学生(学号、姓名、性别、年龄、系编号)
  • 教师(教师号、姓名、性别、职称、系编号)

最后整个教务管理系统的关系模式集合如下:

  • 教师(教师号、姓名、性别、职称、系编号)
  • 学生(学号、姓名、性别、年龄、系编号)
  • 课程(课程号、课程名)
  • 系(系编号、系名、电话)
  • 选修(学号、课程号、成绩)
  • 讲授(教师号、课程号)

Some Examples.

E1.

一个图书管理系统中有如下信息。
图书:书号、书名、数量、位置
借书人:借书证号、姓名、单位
出版社:出版社名、邮编、地址、电话、E-mail
其中约定:
任何人可以借多种书,任何一种书可以被多个人借,借书和还书时,要登记相应的借书日期和还书日期;一个出版社可以出版多种书籍,同一本书仅为一个出版社所出版,出版社名具有唯一性。
根据以上情况,完成如下设计。
(1)设计该系统的E-R图。
(2)将E-R图转换为关系模式。
(3)指出转换后的每个关系模式的主码。

解题思路

  • 首先画出代表每一个实体的E-R表示,实体用矩形表示,属性用椭圆表示。
  • 然后根据题中的语义约定,画出联系的E-R表示,任何人可以借多种书,任何一种书可以被多个人借,所以涉及到图书和借书人实体的借阅联系是一个n:m的联系,并且根据语义约定,它拥有自己的属性借书日期和还书日期。出版社和图书之间的出版联系是1:n的联系,并且不具有属性。

所以得到的E-R图如下所示:
在这里插入图片描述
根据得到的E-R进行关系模式的构造。

  • 首先是三个实体对应的关系模式:
    图书(书号、书名、数量、位置)
    出版社(出版社名、邮编、电话、地址、E-Mail)
    借书人(借书证号、姓名、单位)
  • 而后是联系对应的关系模式:
    借阅(借书证号、书号、借书日期、还书日期)
    出版(书号、出版社名)

具体的转换规则,见【关系模式转换】,后续对于得到的关系模式集合进行合并优化,发现【图书】与【出版】两个关系模式存在相同的主码,所以进行合并,最终得到的关系模式集合如下所示:

  • 图书(书号、书名、数量、位置、出版社名)
  • 出版社(出版社名、邮编、电话、地址、E-Mail)
  • 借书人(借书证号、姓名、单位)
  • 借阅(借书证号、书号、借书日期、还书日期)

E2.

排课是教学环节中的重要过程,该过程包括以下实体。
课程实体:course(cid,cname,chour,ctype)。其中,cid唯一标识每一个课程,cname为课程名,chour为课程学时,ctype为课程类别(0表示选修课,1表示必修课)。
教室实体:classroom(crid,crname,crbuilding)。其中,crid用于标识每一个教室,crbuilding为教室的楼宇,crname为教室的名称。
教师实体:teacher(tid,tname)。其中,tid唯一标识每一名教师,tname为教师姓名。
各实体的关系是:每一个教师可以教授多门课程,一门课程可以被多个教师教授,一个教室可以承载多门课程,一个课程可以被安排在多个教室中。当课程安排在指定教室的时候,需指明安排的日期(cdata)以及当天的第几节课程(carrange)。
请根据上述需求,回答以下问题。
(1)设计该系统的E-R图。
(2)将E-R图转换成关系模式,并指出主码。
(3)根据关系模式,使用SQL创建课程实体,要求SQL语句中包含主码约束和非空约束,各属性的类型及长度自选。

题解
在这里插入图片描述

  • 关系模式
    course(cid,cname,chour,ctype)
    classroom(crid,crname,crbuilding)
    teacher(tid,tname)
    teach(tid,cid)
    arrangement(cid,crid,cdate,carrage)
  • 创建课程实体
CREATE TABLE course
(cid	CHAR(8) PRIMARY KEY,
cname	VARCHAR(20) NOT NULL,
chour	INT NOT NULL,
ctype	INT NOT NULL)

E3.

图书管理系统是一类常见的信息管理系统。分析图书管理系统后,初步获得的实体信息如下。
图书:book(bookid,bookname,num)。其中,bookid用于标识每一本图书,bookname为图书名称,num为图书数量。
借阅用户:bookuser(tid,username,age)。其中,tid用于标识每一个借书用户,username为借书用户姓名,age为借书用户年龄。
图书实体与借阅用户实体间的关系是:借阅用户可以借阅多本图书,同时,一本图书可以被多个借阅用户借阅。借阅过程产生借书日期(borrow_time)和还书日期(return_time)等属性。
请根据上述需求,回答以下问题。
(1)设计该系统的E-R图。
(2)将E-R图转换成关系模式,并指出主码。
(3)根据关系模式,使用SQL创建借书用户实体,要求SQL语句中包含主码约束和非空约束。

题解
在这里插入图片描述

  • 关系模式
    book(bookid,bookname,num)
    bookuser(tid,username,age)
    borrow(bookid,tid,borrow_time,return_time)
  • 创建用户实体
CREATE TABLE bookuser
(
	tid CHAR(8) PRIMARY KEY,
	username VARCHAR(20) NOT NULL,
	age INT
)

猜你喜欢

转载自blog.csdn.net/weixin_44246009/article/details/108423701
今日推荐