指南:
|
列名称 | 数据类型 |
---|---|
Customer_ID | 数字 |
Name | 变量字符 |
Street | 变量字符 |
City | 变量字符 |
State/Province | 字符(2) |
Zip/Postal Code | 变量字符 |
Country | 变量字符 |
Customer 表的表定义
由此起,我们创建一个类 Customer,其结构在下图中显示:
初始 Customer 类
在这个初始 Customer 类中,Customer 表中的每一列都有一个属性。每个属性都是公开可见的,因为可能会查询源表中的任一列。
请注意,属性左侧列出的“+”图标表示该属性是“公开”的;缺省情况下,从 RDBMS 表推导出的所有属性都应是公开的,因为 RDBMS 一般允许无限制地查询任一列。
从直接的表-类映射中生成的类通常将包含可以分为单独类的属性,尤其是在属性出现在多个转换类中的情况下。这些“重复的属性”可能是因为性能而对表反向规范化所生成的、或者可能是因为数据模型过度简化而生成的。在这些情况下,将相应的类分为两个或更多类,以代表这些表的规范化视图。
示例
定义上述 Customer 类之后,我们可以定义一个包含所有地址信息的 Address 类(假设我们的系统中还有其它事物具有地址),则生成以下类:
修订的 Customer 类以及抽取的 Address 类
这两个类之间所画的关联就是一个聚集,因为客户的地址可以视为客户的一部分。
对于表中的每个外键关系,在相关联的类之间创建一个关联,从类中除去映射到外键列的属性。如果该外键列初始情况下表示为一个属性,则从类中除去它。
示例
假设 Order 表的结构如下:
列名称 | 数据类型 |
---|---|
Number | 数字 |
Customer_ID | 变量字符 |
Order 表的结构
在上面列出的 Order 表中,Customer_ID 列是一个外键引用;此列包含与 Order 相关联的 Customer 的主键值。我们将在设计模型中表示这一情况,如下所示:
在设计模型中表现外键关系
外键表示为类 Order 和 Item 之间的关联。
RDBMS 数据模型使用连接表或关联表来表现多对多关系。 这些表使多对多关系可以使用一个中间表来表示,该表包含可连接在一起的两个不同表的主键。需要连接表的原因是因为一个外键引用仅可包含对单个外键值的引用;当一个单行可能与另一表中的许多其它行相关时,就需要一个连接表来与它们相关联。
示例
考虑 Product 的情况,Product 可由多个 Supplier 中的任一个提供,并且任一 Supplier 都可提供任意数量的 Product。Product 和 Supplier 表的结构定义如下:
|
|
Product 和 Supplier 表定义
为了将这两个表链接在一起以找出特定供应商提供的产品,我们需要一个 Product-Supplier 表,它在下表中定义。
Product-Supplier 表 | |
---|---|
列名称 | 数据类型 |
Product_ID | 数字 |
Supplier_ID | 数字 |
Product-Supplier 表定义
该连接表包含产品和供应商的主键,并将它们链接在一起。该表中的一行将表示一个特定供应商提供一项特定产品。所具有的 Supplier_ID 列与特定供应商标识匹配的所有行将提供该供应商提供的所有产品的列表。
在设计模型中,这种中间表是多余的,因为一个对象模型就可以直接表现多对多关联。Supplier 和 Product 类及其关系在下图中显示,还有 Address 类,后者是按照先前的讨论从 Supplier 中抽取的。
Product 和 Supplier 类表现
通常,您将会发现具有某种类似结构的表。在数据模型中,没有泛化关系的概念,所以无法表现出两个以上的表具有某种共同的结构。有时公共结构源自因为性能而进行的反向规范化,例如在上述情况下我们将“隐式”的 Address 表抽取到一个单独类中。 在其它情况下,多个表共享更基础的特征,我们可以将这些特征抽取到一个具有两个以上子类的泛化父类中。要发现泛化的机会,则在几个表(这些表与其说不同,不如说相似)中查找重复的列。
示例
考虑以下的表 SoftwareProduct 和 HardwareProduct,如下所示:
|
|
SoftwareProduct 和 HardwareProduct 表
请注意,以蓝色突出显示的列是完全相同的;这两个表所共享的定义大体相同,仅略有差别。我们表现这一点的方式是抽取一个公共的 Product 类,并以 SoftwareProduct 和 HardwareProduct 作为 Product 的子类,如下图所示:
SoftwareProduct 和 HardwareProduct 类,显示泛化为 Product 类
在下图中,所有类定义放在一起,显示了一个订单输入系统的合并类图(仅限于主要类)。
订单输入系统的合并类图
复制行为更困难,因为通常关系数据库不是面向对象的,并且似乎与对象模型中对类的操作没有任何相似之处。以下步骤可能有助于重新构建上述类的行为:
在设计模型中,根据表-类转换而创建的设计类应,(在需要时)基于应用程序的整体体系结构结构,组织为相应的设计包和/或设计子系统。关于应用程序体系结构的概述信息,请参阅概念:分层和概念:软件体系结构。
Rational Unified Process
|