《eer图.pptVIP

第3章 数据库设计 DB应用 DB应用定义：一个特定的数据库，加上实现此数据库查询/更新的相关程序。 概念设计是成功设计DB应用的一个环节。 实体-关系模型(Entity-Relation model)，简称ER模型，是一种非常流行的概念数据模型。 EER是基于ER的扩展模型(Enhanced ER model) ER/EER已被广泛应用于DB概念设计。它们均以图形化方式描述和捕获用户需求。 基于ER/EER进行概念设计的输出为一组ER/EER图。 基于概念模型的设计，最终都必须变换/转换到可在DB中实现的逻辑数据模型。 借助RDB设计有关规范理论,不仅可对转换后的逻辑数据模式进行规范，而且可对ER/EER图进行求精。 DB设计的主要阶段与过程 DB设计的基本步骤（1） 1. 需求分析 2. 概念DB设计 利用需求分析获得的信息，建立DB数据的一个抽象描述。 这一步通常利用ER/EER模型，或其它高级数据概念模型（如UML类图），来实现。 3. 逻辑DB设计 转换DB概念设计模式到指定DBMS逻辑模式。 由于需求信息本身带有很大主观性，故基于需求信息构造的ER/EER图只能提供数据的一个近似描述。 4. 模式细化 5. 物理DB设计 6. 安全设计 DB设计的基本步骤（2） 1. 需求分析 2. 概念DB设计 3. 逻辑DB设计 4. 模式细化 分析关系数据库模式的关系集，检查潜在问题并进行优化。与需求分析和概念设计的主观性特点不同，细化可得到强有力的规范理论支持。 5. 物理DB设计 考虑应用必须支持的一些典型预期负荷,并以此为基础进一步求精DB设计，确保它能满足预期的性能要求。 这个步骤可能包括为一些表建立索引，或指定聚集存储方式等。 6. 安全设计 3.1 ER数据模型 ER模型简介 1. 构成ER模型的基本概念 实体与属性 实体类型、实体集与键 实体类型：定义了具有相同属性的实体模式结构，由名和属性来描述。 实体集：具有相同实体类型的所有实体集合。 实体类型描述了相同结构实体集的模式或内涵； 实体集则描述了实体类型的外延。 ER图中不区分实体类型和实体集（被视为同义词）。 关系、关系类型和关系集 ER模型的其它概念 ER图设计举例（1） ER图设计举例 （2） ER模型的其它概念 关系属性 关系集也可以有自己的描述属性，用来刻画关系集本身的性质，而不是某个参与实体集的性质。 关系约束 指与关系集相关的约束，通过约束表达可限制参与关系各实体的可能组合。 主要类型：基数词约束、键约束和参与约束。 弱实体集 指只能附属其它实体集而存在的实体集。 在ER图中表达关系基数词和参与约束 弱实体集的几种ER建模方法（图3.5) 3.2 EER数据模型 EER核心概念（1） 类 指实体的集合或实体集，这包括可对DB应用域实体分组的任何EER模式构造，如实体类(型)、子类、超类和类别。 EER中，任何类都允许参与一个关系。 子类、超类 子类S是一个类，子类中的实体必然是其超类C中实体的一个子集，即有关系：S?C 成立 超类/子类关系也称为ISA关系，记做C/S。 子类实体除了可以从超类实体中继承所有的属性外，还可以有自己专有的属性和关系。 EER核心概念（2） 特化 特化Z＝{S1,S2,…,Sn}是具有相同超类G的一个子类集合，每个G/Si是一个超类/子类关系。G被称为泛化实体类型。 用“特化”指代由特化过程所获得的--特化子集。 特化的种类（约束） 完全特化与部分特化； 不相交特化与重叠特化。 两类约束相互独立，可以组合出四种约束。 泛化 是特化的逆过程，允许我们忽略多个实体集之间的性质差异，找出它们的共同点－－抽象出超类。 特化及其约束的EER表示 EER核心概念（3） 类别(category) 类别有时也被称为union子类。 类别T是一个类，它是n个判定超类D1,D2,…,Dn（n1）并集的一个子集。 其形式表示为：T?(D1?D2?…?Dn) union子类的约束 完全约束：子类包含了其所有超类并集中的所有成员； 部分约束：子类只包含并集的一个子集。 UNION子类及其约束的EER表示（图3.8 ） 基本ER模型与UML类图的特性对比 Company DB模式的EER表示 Company DB模式的UML表示 3.3 逻辑数据库设计:映射ER/EER模式到关系模式 3.3 映射ER/EER模式到关系模式 ER/EER模型适合于初始阶段、抽象层次较高的DB概念设计。 给定一个概念设计模式(ER/EER图)，现已有一套标准方法可将它们映射到关系DB模式，但这种转换还只是近似的。 DB模式：{一组表}+ {约束集} 基于SQL-92，我们尚无法捕获隐含在ER/EER设计中的所有约束。 本节我们将介绍从ER