补充：对象-关系映射

《补充：对象-关系映射》由会员分享，可在线阅读，更多相关《补充：对象-关系映射（23页珍藏版）》请在金锄头文库上搜索。

1、对象 关系映射 Object-relational Mapping 主要内容 类之间关系简介 对象 -关系映射概述 映射实体类 映射关联 映射聚合 映射泛化 类之间关系简介 类之间的联系包括关联、聚合和泛化 关联 (associations) 关联是类之间的一种关系。 关联关系在所给的类之间提供了一个链接，需要彼此通信的对象可以使用这个链接。可能的话，对象间的消息总是应该沿着关联关系来发送的。 通常情况下，实体类（业务对象）上的关联是双向的。但有些类之间，如 GUI窗口、编辑逻辑或用户事件之间，单向关联已经足够。 Ordship关联允许一个 Order对象被装载（被链接）到多个Shipment

2、对象（由关联重数 n来指定）。 同样，一个 Shipment对象也可以装载（被链接）到多个Order对象 聚合（ aggregation）与复合（ composition） 聚合是代表组件集合的一个类（超集类）与代表这些组件的类（子集类）之间的整体与部分的关系。 一个超集类包含一个或多个子集类。这种包含属性可以是强包含关系（值包含），也可以是弱包含关系（引用聚集）。 在 UML中，将值聚合称为复合，用 实心钻石形 表示；将引用聚合简单称为聚合，用 空心钻石形 表示。 从系统建模的角度来看，聚合是一种带有附加语义的特殊关联。 复合关系，它表明任何 Book对象都是有 Chapter对象组成的，并

3、且任何 Chapter对象又是由 Section对象组成的。 一个 Chapter对象并不能独立存在，只能存在于 Book对象中。 标准的聚合关系。它表明， BeerBottle可以在其容器（ Crate对象）外存在。 聚合 复合 泛化（ generalization）与继承（ inheritance） 泛化是通用类（超类或父类）与专用类（子类或孩子）之间的一种关系。 子类是超类的一种。通过使用泛化，可不必再陈述已经定义的属性。 在超类中已经定义的属性和方法可以在子类中 复用 ，称子类继承了父类的属性和方法。 泛化有助于增加规格说明、类之间公共属性的利用及更好地确定变更的位置。 泛化关系用指向

4、其父类的空心三角来表示。 被继承的属性在子类中不明确显示出来 -泛化关系使继承在后台完成。 继承只用于类而非对象；只用于类型而非值。 Person类是超类。 Employee类是 Person类的子类，继承了 Person类的所有属性和方法，但 Employee对象无法访问 Person的私有成员。 对象 -关系映射概述 对象 关系映射是指从 UML类模型映射到 RDB模式的设计。 映射必须考虑 RDB模型的限制。 难点：将类图的描述性语义转换为逻辑模式设计中的过程性解决方案。即，类的某些内部描述性语义用关系模式无法表示。这些语义只能通过数据库程序从过程上进行解决，即存储过程。 从对象模型到

5、RDB模型的映射已经在 ER建模及扩展 ER建模中得到广泛的研究，所有主要问题均已解决。映射不只是简单地符合 RDB标准（ SQL92或 SQL:1999），而且还与目标RDBMS的实现相关。 映射实体类 (entity class) 实体类到关系表的映射必须满足表的第一范式，列必须是原子的。 由于 UML具有同样的限制，因此关系模型中的这个限制并不是问题。 UML的类属性是基于原子数据类型和一些固有的结构化数据类型定义的，原子数据类型取决于目标程序设计语言，类似的结构化数据类型已得到 RDBMS的支持。 存在问题： 如，“如果一个雇员有多个电话号码，在分析时应如何对它建模？是否真的需要一个独

6、立的电话号码类？”；“是否可以将雇员的姓名建模为一个属性，但可以通过内部结构识别出姓名是由姓、名和中间名组成？是否真的需要一个独立的雇员姓名类？” 示例： 关系管理 考虑下面对关系管理系统的需求。 系统支持与当前客户和潜在客户“保持联系”的功能，以便能够响应他们的需要，赢得关于组织提供的产品和服务的新合同。 系统存储组织及组织联系人的姓名、电话号码、邮件和快递地址。 系统允许你雇员对需要做的、与相关联系人有关的任务和事件制定计划。雇员可以为其他雇员或为他自己制定任务和事件的计划。 “任务”是为了实现某个结果而进行的一组事件。结果可以是将一个潜在客户转变成当前客户、组织一次产品运送或解决一个客户

7、的问题。典型的事件类型为打电话、访问、发传真、安排培训等。 附加信息如下： 如果我们与客户之间存在交付我们的产品和服务的合同，那么该客户就是当前客户。但合同的管理不在本系统范围内。 系统能根据邮寄和快递地址生成各种客户关系报表（如通过邮政编码找到所有客户）。 记录创建任务的日期和时间。期望从完成任务中得到的“钱数”也要存储下来。 雇员的事件要用类似于日历页面的形式显示在雇员的屏幕上（一天一页），每个事件的优先级（低、中或高）在屏幕上要可视化地区分开来。 不是所有事件都规定完成时间 -有些是不限时的（可以在被安排那天中的任意时间完成）。 事件的创建时间不能改变，但完成时间可以改变。 当事件完成了

8、，完成日期和时间要记录下来。 系统还要存储创建任务和事件的雇员的标识、被安排执行事件的雇员的标识（“负责雇员”）以及完成事件的雇员的标识。 图 1 关系管理系统的类规格说明 没有姓名的概念，不能从数据库中获得姓名。 该模型不允许一条联系信息包含多个phone、 fax或 email 将 Econtact和 EEemplyee类映射到 RDB设计，可以有多种可选的映射策略。图 2提供了一种解决方案，目标 RDBMS是 Oracle。 图 2 关系管理系统的实体类映射到 RDB设计 将 contact_name建模为原子数据类型。每个contact记录只允许一个fax和 email 允许任何数量的

9、 phone，表 ContactPhone用于此目的。 映射关联 关联到 RDB的映射涉及表间的 引用完整性 约束的使用。任何一对一或一对多的关联可以通过直接在一个表中插入一个外键以匹配另一个表的主键来实现。 对于一对一关联，外键可以加给任何一个表（根据关联使用的模式来决定）。 也可能要求将两个实体类组合为一个表（取决于所期望的范式级别）。 对于递归一对一关联和一对多关联，外键和主键都放在同一个表中。 每个多对多关联（不管是否递归）都需要一个交叉表。 示例： 关系管理 图 3表示了关系管理系统的关联规格说明，图 4是其中的一部分，需要将它映射为 RDB模型。 由于 UML的关联规格说明中没有多

10、对多的关联，该图的解决方案如图 5所示。 图 3 关系管理系统的关联规格说明 异或 Xor约束说明这样一种情形：任何一个实例的多个可能关联，在同一时刻只能有一个关联实例化。 异或约束用连接两个或多个关联的一条标注 Xor的虚线表示。 EEvent与 Eemployee之间存在的 3个关联，这些关联确定了哪个雇员创建了事件，指派哪个雇员负责完成它，哪个雇员将最终完成它。 根据 RDB原理，映射过程创建了许多新列作为主键，并保留图 2中的模型作为这个例子解决方案的一部分。 图 4 关系系统部分关联规格说明 图 5 关联映射到 RDB设计 映射聚合 除了以过程方式来实现的触发器或存储过程外， RDB

11、中不区分关联和聚合。 映射关联的主要原理也适用于映射聚合。只有当一个关联可以转换成多个组合关系时，才需要特殊处理聚合（作为一种特殊的关联形式）的语义。 在强聚合（复合）的情况下，应当尝试将子集和超集实体类组合成一个表，在一对一聚合中是可能的。对于一对多聚合，必须将子集类（在强聚合和弱聚合中）建模为独立的表（带有将其链接到自身表的外键）。 示例： 大学注册 考虑下面对大学注册系统的需求。 大学的每个学位都设置了多门必修课和多门选修课。 每门课都处于给定的级别并有学分值。 同一门课程可以是多个学位的组成部分。 每个学位都规定了完成学位所要求的最低总学分值。例如，包括必修课在内，BIT（信息技术学士

12、）需要 68学分。 学生可以对提供的课程进行组合，形成适合自己需要的学习计划，并且完成这些课程就能获得他们所注册的学位。 附加信息如下： 学生选课受时间表冲突以及当前所提供课程能接受的学生人数的限制。 学生提出的学习计划要输入到在线注册系统中。系统要检查学习计划的连贯性并报告其中存在的问题。这些问题需要在导师的帮助下解决，最终的学习计划需要经过系负责人的批准，然后转给注册人员。 学生的学习成绩接收到请求时应以可以查看，成绩应该包括学生在他所注册的（并且没有因为在学期开始的 3个星期内没交钱而退出）每门课中获得的等级信息。 每门课都有一位教师负责，但可以由另外的教师来上课。负责同一门课的教师每学

13、期可以不同，并且每学期也可以由不同的教师来教这门课。 EAcademicRecord对象物理地嵌入在一个 Estudent对象中，且包含属性courseCode。 属性 takesCrsoff独立于被嵌入的EAcademicRecord对象的信息。 每个 ECourseOffering对象只是逻辑地包含在一个 ECourse对象中， ECourseOffering还可以参与其他的聚合 /关联（如与 Estudent ） 复合关系 聚合关系 大学注册系统的聚合规格说明 大学注册系统中的聚合映射到 RDB设计 Student与 AcademicRecord的复合和 Course与 CourseOf

14、fering的弱聚合，二者都是一对多的聚合，所以都需要独立的“子集”表。 在 UML模型中，采用了从 AcademicRecord到 Course的间接导航链接。在 RDB设计中，可能需要建立表 AcademicRecord和 Course之间的直接引用完整性。因为 AcademicRecord有属性 course_code作为其部分主键，同样的属性也可以加给表到 Course作为外键。 映射泛化 可以用多种方式来实现泛化关系到 RDB的映射，但需要重视的是，用 RDB的数据结构来表示泛化时忽略了使泛化区别于其他关系的特性：继承、多态性、代码复用等。 泛化映射策略。 将每个类映射到一个表。 将整个类层次映射到一个“超类”表。 将每个具体类映射到一个表。 将每个没有连接的具体类映射到一个表。 策略一：将每个类映射到一个表 策略二：将类层次映射到一个表 策略三：映射每个具体类到一个表 策略四：映射每个没有连接的具体类到一个表