高质量数据库建模系列课程<5> PPT & 讲义 - 关系

浏览: 3038

广告:

欢迎参加我的课程:高质量数据库建模



高质量数据建模基础课程 - 5-2.jpg

大家好, 上一节课我们介绍了什么属性以及属性的域,那么这一节课我们讲什么是关系.

关系是用于表示实体和实体之间的联系, 通常在需求的描述中呢, 用动词表示.比如我这里给的例子,老师和课程的关系,老师是一种实体,课程也是一种实体,而老师 教 课程,这个 教 就体现了老师和课程之间的关系。我们前面介绍过,在概念模型层级,是存在1对多,0对多,1对1,多对多这几种情况,而在逻辑模型以及物理模型层级,要消除多对多的情况。

高质量数据建模基础课程 - 5-3.jpg



那么这里我们还是用问问题的方式,逐步厘清数据之间的关系。首先当出现两种实体的时候,需要确定这两种实体之间的关系,那么我们总回提出至少如下四个问题:

第一,一个老师是不是可以教多门课程?

第二,一门课程是不是可以由多个老师来教?

 

第三,是不是每个老师 一定 要教课?

第四,是不是每个课程 一定 要由老师教?


高质量数据建模基础课程 - 5-4.jpg

那么我们逐个去回答这个问题,这四个问题的答案找到了,模型的关系也就确定了。

首先,第一个问题:一个老师可以教多门课吗?

这个呢,实际来讲呢,是和具体的应用场景有关系的。比如在比较正规高中,一个老师教多门课就非常少见,比如物理老师就不会去教化学。而在大学呢,一个老师教多门课是非常正常的,比如计算机系那么多门课,不可能一门课就配一个老师,而且很多专业课都是相通的。我读大学的时候,我们的汇编语言,计算机网络都是一个老师讲的。数据结构,C语言也是一个老师。所以我们要根据需求来定模型的关系。

那么这里我们以大学为例,一位老师是可以教多门课程的。

 

然后,第二个问题,一门课程可不可以由多名老师来教?这个问题更简单一点,一般一个专业有很多班级,一个老师也教不过来,所以一门课程是可以由多名老师来教的。那么,这两个问题用来确定什么的啊?是用来确定两个实体 老师 和 课程之间基数,也叫cardinality。通过这个例子,我们可以看到,老师和课程之间是多对多的关系。


高质量数据建模基础课程 - 5-5.jpg


然后我们接着看后面两个问题,

第三个问题,是不是每位老师一定 要教课啊?

答案是不一定,比如管教务管后勤的老师,比如管实验室的老师,他们就不用教课。

第四个问题,是不是每门课程都一定得由老师来教啊?

还是那句话,这个实际上来讲,还是和需求有关,对于大学而言呢,这个答案是一定 得由老师来教。对于高中就不一样了,比如自习课,不需要老师。

那么这两个问题是用来干嘛的啊?这个是用来确定关系是强制的还是可选的。


根据上面四个问题的答案,我们知道了,课程和 老师 之间的关系,那么在Data Model里面怎么体现呢? 这里我们一起画一个简单的Data Model的图。

首先我们打开PowerDesigner,先建一个概念模型,因为我们是第五课,所以起个名字叫Lesson5。我们先建一个实体,教师,起个名字叫Teacher,然后建第二个实体,课程,起个名字叫Course。前面我们说了哈,这两个实体之间的关系是多对多,那么建一个关系。

关系的配置如图所示:


Clipboard Image.png

Panel显示的画面如下

Clipboard Image.png


可以在Tools->Model Option里修改Model的Notation,去改变实体关系图显示的风格。

Clipboard Image.png

比如我们比较常用的,Entity/Relationship, 显示如下:

Clipboard Image.png

注意如下:

Clipboard Image.png

分别表示 强制 和 可选。而如下的如鸡爪的图例表示是 “多”的意思。

Clipboard Image.png

点击Tools->Generate Logical Model,自动生成逻辑模型,由于逻辑模型会消除M:N的关系,因此会自动建表,如下

Clipboard Image.png

通常我们把这种表称为Assoication Table。

除了1:N,M:N的关系,还有一种0:1或者1:1的关系,称为Inhenritance,或者Generation。

Clipboard Image.png

X:表示Teacher和Worker是互斥的。X下面的小矩形表示Teacher和Worker的合集就是Employee的全集。

这两项配置需要右键点击Inheritance的线

Clipboard Image.png

选择Properties,如下图所示:

Clipboard Image.png

Mutually exclusive children: 表示互斥

Complete: 表示子集的合集即是全集。

选择Children,可以看到Employee的两个子集

Clipboard Image.png

当再Generation Tab页中,只选择“Generate Children”,则在将逻辑模型自动生成物理模型时,会自动创建两个表Teacher和Worker,也就是只创建两个Child表

Clipboard Image.png

Clipboard Image.png

如果选择Parent和Children,如下图,会创建三张表

Clipboard Image.png

Clipboard Image.png

如果只选择Parent,如下图,则只会创建一张表

Clipboard Image.png


Clipboard Image.png

在真实的应用中,各位同学可以根据项目实际情况来进行设计。

今天的课就这么多,下次我们讲键。

推荐 4
本文由 BAO胖子 创作,采用 知识共享署名-相同方式共享 3.0 中国大陆许可协议 进行许可。
转载、引用前需联系作者,并署名作者且注明文章出处。
本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责。本站是一个个人学习交流的平台,并不用于任何商业目的,如果有任何问题,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

7 个评论

抢个先,每周都期待着笔记的更新,老大辛苦了。
我懒,要不然还能更的快点
不懒不是胖子,作为胖子党,我能理解
我改过自新......
别人追剧,我追春宇老师的视频课程!能上升到理论层面讲解,这得需要看多少书,接手多少项目才能讲出来!~~

期待后面更精彩的课程,准备本周将这10个课时看完。

喜欢的多给好评吧,激励老师多讲干货!~
关于超类和子类,有个问题百思不得其解的是Generate Parent,Generate Children, Generate Parent & Generate Children 三种方式各适合什么场景,各有何优缺点呢?
这个要看你对两张表的操作,以及是不是要追求产品化之类的一些细节原因,很难一概而论。比如,假设你的组织面对很多party, 包括企业自身,自己的合作伙伴,供应商,客户,还有竞争对手,政府部门,但有的时候他们可能归属于同一个组织,比如IBM和SAP在软件产品上是竞争对手,但IBM在服务领域还经常去提供SAP的ERP解决方案,在这又是合作伙伴。而对于party所对应的比如工商管理号,地址,电话等等通用性较强的东西,就可以放到一个主表中,而对于竞争领域等等又可以创建单独的competitor表,之类的。好处很显然可以减少冗余,缺点是也会带来模型的复杂以及未来SQL的复杂,等等。真的是具体问题具体分析,总体思路还是要看数据怎么用。

要回复文章请先登录注册