数据库概念数据建模与高级ER构造详解

### 数据库概念数据建模与高级ER构造详解 #### 1. 替代概念数据建模符号 在数据建模领域，除了常见的Chen方法，还有其他一些常用的概念数据建模符号。 - **“乌鸦脚”符号**：对于一对多和多对多关系，“乌鸦脚”符号在“多”的一侧使用特定标识。一些CASE工具，如KnowledgeWare的信息工程工作台（IEW）就采用了这种形式。在这种表示中，关系没有明确的构造，而是通过实体之间的连接线以及连接线上的关系名称来暗示。实体之间连接线上的最小连接性通过0（表示零）或垂直线（表示一）来指定。“交集实体”用于表示弱实体，特别是等同于多对多关系的实体。 - **IDEF1X符号**：由Robert G. Brown提出，从相关图示中可以明显看出它与Chen符号有相似之处。幸运的是，这些形式都相对容易学习和阅读，从图表中也能明显看出它们在基本ER概念上的等效性。然而，由于ER模型没有明确的标准，除了这里展示的三种类型，如今还使用着许多其他的构造。 #### 2. 高级ER构造 ##### 2.1 泛化：超类型和子类型 原始的ER模型长期以来有效地用于与最终用户交流基本数据和关系定义。但在引入泛化等数据库抽象概念之前，使用它来开发和集成不同最终用户视图的概念模型受到严重限制。 - **泛化关系**：泛化关系表明，具有某些共同属性的几种实体类型可以泛化为更高级别的实体类型，即通用或超类实体，通常称为超类型实体。在泛化层次结构中，较低级别的实体（子类型）可以是超类型实体的不相交或重叠子集。例如，实体“员工”是“经理”、“工程师”、“技术员”和“秘书”的高级抽象，这些都是“员工”的不相交类型。泛化抽象的ER模型构造是通过一个圆圈和从圆圈到子类型实体的连接线上的子集符号，将超类型实体与其子类型连接起来。圆圈中包含一个字母，用于指定不相交性约束。 - **特化**：特化是泛化的逆过程，它表示子类型对超类型进行专门化。一个实体在一个关系中可能是超类型实体，而在另一个关系中可能是子类型实体。当一个结构包含超类型/子类型关系的组合时，该结构称为超类型/子类型层次结构或泛化层次结构。泛化也可以用继承来描述，即超类型的所有属性会向下传播到较低类型的实体。泛化可能在一个通用实体（超类型实体）根据一个公共属性的不同值进行划分时发生。 - **约束分类**：泛化可以根据对子类型实体的两个重要约束进一步分类：不相交性和完整性。不相交性约束要求子类型实体相互排斥，用字母“d”写在泛化圆圈内表示；不重叠的子类型（即重叠的子类型）用字母“o”写在圆圈内表示。完整性约束要求子类型涵盖超类型的所有情况，子类型可以定义为对超类型的全部或部分覆盖。例如，在超类型“个人”和子类型“员工”和“客户”的泛化层次结构中，子类型可以描述为全部覆盖。用超类型实体和圆圈之间的双线表示这种约束。 ##### 2.2 聚合 聚合是超类型和子类型实体之间的一种抽象形式，与泛化抽象有显著不同。泛化通常用子类型和超类型之间的“是一个”关系来描述，例如“员工是一个个人”。而聚合是整体与其部分之间的关系，用“是一部分”关系来描述，例如“报告和原型软件包都是合同可交付成果的一部分”。在聚合的表示中，超类型实体通过一个圆圈与子类型实体连接，圆圈中显示字母“A”。但这里没有子集符号，因为“是一部分”关系不是子集关系，并且聚合中没有继承属性，每个实体都有自己独特的属性集。 ##### 2.3 三元关系 当二元关系不足以准确描述三个实体之间关联的语义时，就需要三元关系。三元关系比二元关系更复杂。三元关系的ER表示法是将三个实体连接到一个单一的关系菱形上，每个实体的连接性指定为“一”或“多”。在三元关系中，如果一个实体的一个实例只能与其他两个关联实体的一个实例相关联，则该实体被认为是“一”；如果一个实体的多个实例可以与其他两个关联实体的一个实例相关联，则该实体被认为是“多”。例如，在“管理”关系中，“工程师”和“项目”被认为是“多”，“经理”被认为是“一”，可以用以下断言表示： - 断言1：在一个经理的领导下，一名工程师可以参与多个项目。 - 断言2：在一个经理的指导下，一个项目可以有多名工程师。 - 断言3：一名工程师在一个项目上工作时，必须只有一个经理。 断言3也可以用函数依赖的简写形式表示