数据库设计系列5---关系建模

标示了数据库系统的实体之后,下一步骤就是标示实体之间的关系,以及存在于关系之上的约束。这种约束的例子包括:一个分公司必须有多名会员,每个分公司都必须有员工,关系上的约束类型称为多样性。多样性的定义为:一个实体中可能和相关实体的一个存在关联的实体事件的数目。
       最常用的关系是度为 2 的二元关系,二元关系上的多样性约束一般分为一对一,一对多,多对多三种。使用以下的业务规则来考查这三种类型的关系,一名员工管理一个分公司,一个分公司有许多员工,演员出演某部影片。对于每个业务规则,我们说明在没有明确制定的情况下找到其中的多样性约束,并说明怎样在 ER 模型中表示他们。
1.       一对一关系是最常见的关系,比如一名员工管理一个分公司,但是并不是所有的员工都有分公司可以管理,如下图表示:
一个员工管理一个单位,找出多样性通常需要用样例数据检查特定事务规则的数据之间的关系,可以从填好的表格,报表甚至从与用户的讨论中得到样例数据。为了得出正确的结论,强调被检查和讨论的样例数据能够真实地代表所有数据是非常重要的。
       为了图形化表示 1:1 关系的,在关系的两端放上, 0..1 或者 1..1 表示他们之间的描述关系,为了表示一个员工管理 0 1 个公司,在 Branch 的一端放上 0..1 的字样,为了表示一个分公司必须由一个员工管理,在 Staff 的一端放上 1..1 ,在上图中左边的 表示 0..1 ,同时也表示是可选参与,即当 Staff 的一个实体确定时,他所管理的分公司可以有,或者没有。而在右边的 表示当一个 Branch 确定的时候,必须有一个 Staff 员工来进行管理,即参与。
2.一对多关系也比较常见,比如一个公司有多名员工的情况就属于一对多的关系。
为了表示 Branch Has Staff ,我们在实体 Staff 的一端标记 1..* ,表示一个公司 1 到多多名员工,而一个员工只属于一个分公司,在上图中, 表示 1..*, 如果知道多样性约束的最大值和最小值,则可以显示这些信息,例如一个分公司有 2-10 个员工,可以标记 2..20
1.       多对多约束,角色和拥有的权限之间的关系是一个典型的多对多关系,一个角色可以拥有多个权限,一个权限可以被分配到不同的角色中。使用 UML 图形的表示如下图所示:
为了图形化表示多对多的关系,在互相关联的实体分别标记 0..* ,如上图中的 所示,
1.       复杂关系的多样性约束。一般来说, n 元关系的多样性约束代表关系中其他 n-1 元关系固定的情况下某个实体潜在的实体事件的数目,
以上所描述的约束中,如果其他 n-1 元关系确定的情况下,某个实体的参与个数如果大于等一,则为强制参与,否则为可选参与,在一个关系中参与的实体的数目,成为关系的基数。
2.       关系中相关的性质称为关系上的属性,比如在课程和学生之间存在多对多的关系,在多对多的关系中存在分数这个属性,学生对应的某个课程有考试成绩。
ER 模型中的设计问题:
       ER 模型中可能存在如下的两种陷阱,扇形陷阱和深坑陷阱。
       扇形陷阱:从第三个实体与扇出的两个实体之间有 1..* 的关系,但是扇出的两个实体之间应该有直接关系以提供必要的关系,实际却没有,其形状如下图所示:
如一个工头负责多个工程,同时也管理多个民工,他们都是一对多的关系,民工和工程之间应该有直接的关系表明某个民工在某个工程上工作,但是却没有明确的说明。解决的办法是在工程和民工之间添加一个关系,表示民工在那个工地上工作。
深坑陷阱:一个模型,假设他们之间存在关系,但是这些实体之间不存在路径。深坑陷阱存在的地方是存在可选参与的关系组成了相关实体之间的路径,例如一个公司分配了若各个汽车,部分员工可以使用汽车,这样就有了如下的关系
由于并不是所有的员工都是用汽车,根据这个模型并不能看出来公司拥有多少员工,或者员工属于哪个公司。解决办法是在公司和员工之间添加一个关系,表明公司和员工之间的关系。
扇形陷阱和深坑陷阱之间的区别不是很好理解,在实际的设计中也很少出现此类陷阱。大致有个了解就可以了,不需要深究。

你可能感兴趣的:(数据库设计,休闲,ER模型,实体建模,关系建模)