数据库设计过程(续2)

角色(联系集可以定义在一个实体集上)

• 参加联系的实体集不必是互不相同的标记 “manager” 和 “worker” 称为角色; 他们指明了employee 实体是如何通过 works-for 联系集相关的.
• 角色在 E-R 图中通过对连接菱形与矩形的直线做标记来表示.
• 角色标记是可选的, 用于明确联系的语义

基数约束

在联系集与实体集之间用有向直线(®)表示“一”，无向直线(—)表示“多”.

一对一联系
例如:从customer到loan的一对一联系:

• 通过联系borrower 一个客户最多只能与一笔贷款相关联
• 通过联系borrower 一笔贷款最多只能与一个客户相关联

一对多联系(包括0)
通过从customer到loan的一对多联系borrower，一笔贷款最多只能与一个客户相关联, 但一个客户可与多笔(包括 0)贷款相关联

多对多联系(包括0)

• 一个客户可与多笔(包括 0)贷款相关联
• 一笔贷款可与多个客户(包括 0)相关联

实体集参加联系集的方式

• 完全参加 (用双线表示): 实体集中的每个实体都至少参加联系集中的一个联系
  E.g.  loan 参加 borrower 是完全的
  通过borrower，每笔 loan 至少与一个 customer 关联
• 部分参加: 某些实体可能未参加联系集中的任何联系
  E.g.  customer 参加 borrower 是部分的

基数限制表示法(基数限制也能表达参加约束)

(min,max):表示实体集A的一个实体最少min次最多max次参与到联系中。
Min =0 部分参与, 表示可以不参与;  Min >= 1 完全参与；表示必须参与至少一次。
(customer)max = 1; (loan)max = 1  A一对一B
(customer)max = *; (loan)max = 1  A一对多B

键

• 实体集的超键是指其值能唯一确定实体的一个或多个属性的集合.
• 实体集的候选键是指具有极小性的超键
• • Customer-id 是 customer 的候选键
  • account-number 是 account 的候选键
• 可能存在多个候选键, 选择其中之一作为主键.

具有三元联系的E-R 图

 

三元联系的基数约束
三元以上的联系最多只允许出现一个箭头
E.g. 从works-on 到 job 的箭头表示每个雇员在每个分行最多只承担一项工作.
若有多个箭头, 其意义有两种定义方式  

•  A, B 和 C 之间的三元联系R 带有指向 B 和 C 的箭头可以意味着
• •  每个A 实体与唯一的B 和 C 实体相关联，或
  •  每个实体对 (A, B) 与唯一的 C 实体相关联, 并且每个实体对 (A,C) 与唯一的 B 实体相关联上面这两种定义方式在不同的系统中都被使用
•  为避免混淆我们禁止多于一个箭头的情况

弱实体集

• 不具有主键的实体集称为弱实体集.
• 弱实体集的存在依赖于它的标识实体集的存在
• • 弱实体集通过一个从标识实体集到弱实体集的完全的、一对多的联系集来与它的标识实体集相关联
  • 标识联系用双菱形表示
• 弱实体集的辨别属性（或称部分键）是指在一个弱实体集内区分所有实体的属性集合.
• 弱实体集的主键由它所依赖的强实体集的主键加上它的辨别属性组成.

比如家属实体集依赖于职员实体集存在。

• 弱实体集用双矩形表示.
• 用下划虚线表示弱实体集的辨别属性.
• payment-number –  payment 实体集的辨别属性
• payment 的主键 – (loan-number, payment-number)
• 注意: 强实体集的主键并不显式地存于弱实体集中, 而是隐含地通过标识联系起作用.
• 如果 loan-number 显式存在, payment 就成了强实体, 则payment 与 loan 之间的联系变得冗余。因为payment 与 loan共有的属性loan-number 定义了一个隐含的联系。

特化/演绎

• 自顶向下设计过程中, 确定实体集中的一个具有特殊性质的子集.
• 这些子集成为低层实体集, 它们具有特殊的属性或者参加特殊的联系.
• 用带有ISA 标记的三角形表示 (E.g. customer “is a” person).
• 属性继承 – 低层实体集继承它连接的高层实体集的所有属性及参加的联系.

泛化/归纳

• 自底向上设计过程 – 将若干共享相同特性的实体集组合成一个高层实体集.
• 特化与泛化简单互逆; 他们在 E-R 图中以相同方式表示.

 

特化与泛化

一个实体集根据不同特性可以有多个特化实体集. 
E.g. 除了officer vs. secretary vs. teller 之外, 还有 permanent-employee vs. temporary-employee

每个雇员是

• permanent-employee 或 temporary-employee 之一的成员
• 也是 officer, secretary 或 teller 之一的成员

ISA 联系也称为超类- 子类联系

对特化/泛化的设计约束

关于哪些实体可以是给定低层实体集的成员的约束.

•  –通过条件定义;E.g. 超过65岁的客户是 senior-citizen 实体集的成员; senior-citizen ISA  person.
•  –用户定义
  

关于实体在单个泛化中是否可以属于多于一个低层实体集的约束.

•  –不相交
• •  一个实体只能属于一个低层实体集
  •  在 E-R 图中ISA三角形旁边加注disjoint
• –重叠
• •  一个实体可以属于多个低层实体集

 完备性约束 – 说明高层实体集中的实体是否必须至少属于一个低层实体集.

•  完全的: 是
•  partial: 否

 

构建概念模型E_R模型：

• 标识实体；
  
• 标识联系；
  
• 标识实体和联系的有关属性；
  
• 确定属性域；
  
• 确定候选键和主键属性；
  
• 特化和泛化实体；
  
• 删除和关系模型不相容的属性；
  
• 检查模型是否支持用户事务。

E-R 设计决策

• 用属性还是实体集来表示对象
• 一个现实世界概念最好表示为实体集还是联系集
• 用三元联系还是一对二元联系
• 用强实体集还是弱实体集
• 特化/泛化的使用 – 有助于设计的模块性
• 聚集的使用 – 将聚集实体集视为单个单元, 从而不必关心其内部结构的细节

银行数据库示例

• 银行系统数据要求银行由支行组成。每个支行在特定的城市，具有唯一的名称。银行可以查看支行的资产。
• 银行客户通过他们的编号区分，银行存储了每个客户的名字、居住的城市和街道。客户有自己的账户，可以贷款。一个客户可能和特定的职员相关联，他充当客户的贷款员或个人银行顾问。
• 银行提供两种账户：储蓄账户和支票账户。账户可以对应多个客户，一个客户也可拥有多个账户。每个账户被赋予唯一的账号。银行保存了每个账户的余额，以及账户的拥有者访问账户的最近日期。另外，每个储蓄账户有一个利率，每个支票账户的透支信息也被记录下来。银行为客户提供贷款。某次贷款在特定的银行发生，贷款可以为一个人或多个人合贷。每笔贷款由唯一的贷款号确定。每个贷款，银行保存了贷款数量和贷款还款的记录。虽然贷款还款号不能唯一地确定是所有银行贷款中的哪一笔还款，但可以确定指定的某次贷款中的还款记录，每笔还款都有日期和金额。
• 银行职员通过职员编号值区别。银行管理部门保存每位职员的名字和电话，银行职员家属的名字以及雇员经理的职员编号，银行还存储了职员的雇佣日期。

 

视图综合概念数据库设计过程

1 设计局部E_R模式
  确定局部结构范围；
  定义实体，产生局部实体；
  联系定义，确定局部实体间的联系及其结构约束；
  深入分析，确定子类、超类等联系；2 合成，设计全局E_R模式
  （1）确定局部E_R模式间公共实体类型；
  （2）局部E_R模式合并，合并对应部分，保留特殊部分，删除冗余部分：
    两两合并；
    先合并有联系的；
    从公共实体类型出发，最后再加入独立的局部结构；
3 消除冲突
 （1）属性冲突：类型、取值范围、单位等的冲突；
 （2）约束/结构冲突：属性、实体抽象不同，实体键、联系关系等冲突；
 （3）命名冲突：有异名同意义，同名异意等；

4 优化 准确、全面反映用户功能需求； 实体类型个数尽可能少； 属性尽可能少； 实体类型间联系无冗余；

（1）实体类型合并，例如1：1联系的两个实体可以考虑合并；

（2）冗余属性消除。综合成全局模式后，可能产生全局范围内的冗余属性，比如有些数据可以由其他数据推出；

（3）冗余联系消除。