数据库建模

的联系组成 元素
实体（Entity） 客观存在并可相互区别的事件或物体 对应于ODL中的对象 实体集（Entity Set） 同类（具有相同类型、相同性质）实体的集合 对应于ODL中的类 用矩形表示
实体联系图（E/R）
元素
属性（Attribute） 实体所具有的某一特性 用与实体集相连的椭圆表示 联系（Relationship） 实体集之间的关联 可涉及多个实体集 可表示双向的联系 用与相应的实体集相连的菱形表示
反向联系 ODL要求显式表示存在的反向联系
Interface Movie { //Movie Class 的ODL说明 attribute string title; attribute integer year; attribute integer length; attribute enum Film { color, blackAndWhite } filmType; relationship Set < Star > stars inverse Star :: starredIn; //Star与Movie的联 系 };
…… N relationship Set <Star> stars inverse Star :: staredIn; relationship Studio ownedBy N inverse Studio :: owns; }; Interface Star{ …… N relationship Set <Moive> staredIn inverse Moive :: stars; }; Interface Studio{ …… 1 relationship Set <Moive> owns inverse Moive :: ownedBy; };
Stars
Contracts
Movies
Studios
一个制片公司与一位特定的影星签约来演一部特定的电影
联系中的角色
实体集在联系中的作用
参与联系的实体集互异 只标注联系名 同一实体集在一个联系中多次出现 标注联系名及角色名
Original
Stars
Movies
Sequel-of
候选码 其任意真子集都不为超码的超码 一个类（或实体集）中可能有多个候选码
主码 从候选码中选取的一个，一个类（实体集）中只有 一个主码 E / R图中只能表示主码：主码属性名加上下划线
单值约束 要求某个角色的值是唯一的，如键码 当一个属性为单值时 可以要求该属性值存在（not null） 可以允许该属性值任选（null） 构成键码的属性，必须有值存在（not null）
数据库的设计步骤
OODBMS ODL 想法 需求 关系 RDBMS
E/R
ODL
对象定义语言
Object Definition Language 以面向对象的观点、方法，说明数据库的概 念结构 可方便地直接转换成 OODBMS 的说明 经过努力，可以转换成 RDBMS 的说明

面向对象的设计
子类继承其超类的所有特性 属性 联系
Interface Cartoon : Movie { relationship set < Star > voices; }
ODL中的多重继承
类的层次 一个类可以有多个超类
Interface MurderMystery : Movie{ attribute string weapon; }
Interface Cartoon-MurderMystery : Cartoon,MurderMystery {}
E/R中的子类
Isa
E/R中的继承
对约束的建模
建模包含对现实世界的对象及联系的描述，也
包含对它们的一些约束
键码
单值约束 参照完整性约束 域的约束 一般约束
对象某方面的特征，属性就是数据 只由基本数据类型构成 属性的类型，不能是类、也不能从类中构造
Interface Movie { //Movie Class 的ODL说明
attribute string title; attribute integer year; attribute integer length; attribute enum Film { color, blackAndWhite } filmType; };
Interface Star { attribute string name; attribute Struct Addr { string street,string city } address; };
记录结构类型
联系
对象的引用 对象的关联 对象集合的引用（1:N）
Relationship Set < Star > stars; 单一对象集合的引用（1:1） Relationship Star starOf;
键码 在类的范围内唯一标识一个对象（或者在实体集的 范围内唯一标识一个实体）的属性或属性集 一个类中的两个对象（或一个实体集中的两个实体） 在构成键码的属性集上取值不能相同 ODL中键码的表示 interface Movie ( key (title,year) ) { …… }
超码 一个或多个属性的集合，能在一个实体集中唯一地 标识一个实体 一个类（或实体集）中可能有多个超码
联系集的取舍（二元联系）
1:1联系：将一端的主码作为另一端的属性 1:N联系：将一端的主码作为 N 端的属性 N:M联系：必须保留联系集
联系集的键码（二元联系）
1:1联系：任意一端的主码
1:N联系：N端的主码
N:M联系：参加联系的所有实体集的主码
ODL、E/R建模 关心：存什么数据、关系如何 不关心：用什么数学模型、DBMS产品
ODL中的类型 基本类型
原子类型 接口类型
结构类型，可由以下类型组合而成 集合
无重复，次序无关
包
可重复，次序无关
列表
可重复，次序相关
数组 结构
实体联系图（E/R）
用图形的方法，描述实体及实体间的联系 世界由一组称作实体的基本对象及这些对象间
对象标识 — OID
对象与对象的区别
类
具有相同特性的对象归为一类 对象的归并必须有意义 属于同一类的对象其特性必须相同
面向对象的设计
对象的三个特性
属性：特性 联系：引用 方法：函数
接口说明
interface < 名字 > { < 特性表 > }
属性
参照完整性约束 要求由某个对象引用的值在数据库中确实存
在 参照与被参照、引用与被引用 参照完整性约束的操作（各产品不同）
禁止删除被引用的对象 级联删除 / 修改
E/R图中参照完整性的表示
Movies
Owns
Studios
弱实体集
弱实体集的属性不足以形成主码 有主码的实体集称为强实体集 弱实体集只有作为一对多联系的一部分（多）
需求收集和分析
设计概念结构 存什么 关系（联系）如何 ODL或E/R图，是各种数据模型的共同基础 设计逻辑结构
设计物理结构
物理实现
数据库的设计步骤
需求收集和分析
设计概念结构 设计逻辑结构 用什么数据模型 数据库的模式（database schema） 用户子模式
设计物理结构
物理实现
数据库的设计步骤
需求收集和分析
设计概念结构 设计逻辑结构
设计物理结构
数据怎么存 根据DBMS产品、环境特点
物理实现
数据库的设计步骤
需求收集和分析
设计概念结构 设计逻辑结构
设计物理结构
物理实现 运行DDL 装入测试数据 应用程序
Movies
Sequel Studio of star
Contracts
Studios Producing studio
联系中的属性
联系中可以包含属性 由联系而产生的属性
可为由联系产生的属性建立实体集
salary
Stars
Contracts
Movies
Studios
将多向联系转换成二元联系
数据库建模
Database Modeling
重庆
数据库的设计步骤
需求收集和分析
设计概念结构 设计逻辑结构
设计物理结构
物理实现
数据库的设计步骤
需求收集和分析
用户关心什么 用户要什么结果
设计概念结构
设计逻辑结构 设计物理结构 物理实现
数据库的设计步骤
新增连接实体集
引入连接实体集至原实体集的多对一的联系
设计原则
真实性
设计应当忠于规范
存什么
避免冗余
任何事物只表达一次
பைடு நூலகம்
避免引入过多的元素 选择合适的元素类型
属性？ 类/实体集？
联系集？
子类
特殊化与概括 子类与超类 属性的继承
ODL中的子类
透过E/R图，便于与用户交流
title
year
name
address
Movies
Stars-in
Stars
lenght
filmType
E/R联系的多重性
N与1的表示
Movies
Stars-in
Stars
Studios
Runs
Presidents
Movies
Owns
Studios
联系的多向性
E/R图能方便地描述两个以上实体集间的联系
联系的多重性
N:N
在联系中，每个C都和D的集合有关，而在反向联 系中，每个D都和C的集合有关
N:1
在联系中，每个C都和唯一的D有关，而在反向联 系中，每个D都和C的集合有关
1:1
在联系中，每个C都和唯一的D有关，而在反向联 系中，每个D都和唯一的C有关
Interface Moive{
才有意义 弱实体集与其拥有者之间的联系是标识性联系
number Crews Unit-of name Studios addr
关于联系集
联系集的成份
参加联系的实体集的主码 联系集的属性
联系中属性的决策(二元联系)
1:1 联系集的属性：放到任意一端 1:N 联系集的属性：放到 N 端 N:M联系集的属性：只能留在联系集中