从类模型映射到关系模型

根据领域模型分析数据模型Mapping from the Class Model to the Relational Model 从类模型映射到关系模型Having described the two domains of interest and the notation to be used, we can now turn our attention as to how to map or translate from one domain to the other. The strategy and sequence presented below is meant to be suggestive rather than proscriptive - adapt the steps and procedures to your personal requirements and environment.在需要对两个领域建模时，现在我们可以关注如何从一个领域映射或转换映射到另一个领域。

以下的策略和方法，就是要启发，而不是强制的步骤和程序应用到您的个人需求和环境。

1. Model ClassesFirstly we will assume we are engineering a new relational database schema from a class model we have created. This is obviously the easiest direction as the models remain under our control and we can optimise the relational data model to the class model. In the real world it may be that you need to layer a class model on top of a legacy data model - a more difficult situation and one that presents its own challenges. For the current discussion will focus on the first situation. At a minimum, your class model should capture associations, inheritance and aggregation between elements.1. 类建模首先，我们将假设从已创建的类模型生成一个新的关系数据库模型。

这显然是最容易的，可控制的，可以通过关系数据库模型反向优化类模型。

在现实世界中可能你需要将类模型作为数据模型的上层，这是更困难的情况，也对自己提出了一个挑战。

对于目前的讨论将集中在第一种情况。

至少，你的类模型应捕元素之间的联系、继承和聚集关系。

2. Identify persistent objectsHaving built our class model we need to separate it into those elements that require persistence and those that do not. For example, if we have designed our application using the Model-View-Controller design pattern, then only classes in the model section would require persistent state.2. 确认持久对象已建成的类模型，我们需要区分这些元素，那些需要持久化和那些不是。

例如，如果我们设计我们的应用程序使用Model - View- Controller设计模式，那么只有MODEL模型部分需要持久化状态。

3. Assume each persistent class maps to one relational tableA fairly big assumption, but one that works in most cases (leaving the inheritance issue aside for the moment). In the simplest model a class from the logical model maps to a relational table, either in whole or in part. The logical extension of this is that a single object (or instance of a class) maps to a single table row.3. 假设一个持久化类映射一个关系表大多数情况下，这都是一个合理的假设，除去继承问题以外（暂且不考虑）。

在最简单的模型中，逻辑模型中的一个类映射一个关系表的全部或一部分。

这种逻辑的延伸是一个单一的对象（或类的实例）映射关系表中的一行数据。

4. Select an inheritance strategy.Inheritance is perhaps the most problematic relationship and logical construct from the object-oriented model that requires translating into the relational model. The relational space is essentially flat, every entity being complete in its self, while the object model is often quite deep with a well-developed class hierarchy. The deep class model may have many layers of inherited attributes and behaviour, resulting in a final, fully featured object at run-time. There are three basic ways to handle the translation of inheritance to a relational model:4. 选择一个继承策略从面向对象模型转化成关系模型的过程中，继承可能是最有问题的关系和逻辑结构。

关系空间本质上是平面结构，每一个实体自我实现，而对象模型通常为多层次扩展的类结构。

多层级类模型可能有多层次继承的属性和行为，最终结果，运行时功能齐全的对象。

有三种基本方式对继承关系转换成关系模型：a.Each class hierarchy has a single corresponding table that contains all the inherited attributes for allelements - this table is therefore the union of every class in the hierarchy. For example, Person, Parent, Child and Grandchild may all form a single class hierarchy, and elements from each will appear in the same relational table;类层次结构有只有一个相应的表，包含所有元素的所有继承的属性。

因此这个表是类层次结构中所有类的联合。

例如，人，父母，子女和孙子都可能形成一个单一的类层次结构，单所有元素将出现在同一个关系表中;b.Each class in the hierarchy has a corresponding table of only the attributes accessible by that class(including inherited attributes). For example, if Child is inherited from Person only, then the table will contain elements of Person and Child only;层次结构中每个类都有一个相应的表。

表中包含类所要访问的所有属性（包括继承的属性）。

例如，如果孩子继承人，则该表将包含个人与儿童所有的元素;c.Each generation in the class hierarchy has a table containing only that generation's actual attributes. Forexample, Child will map to a single table with Child attributes only在类结构中，每一层有一个表，包含这一层的实际属性。

例如，Child将映射大偶一个简单表，只包含汉字的属性。

There are cases to be made for each approach, but I would suggest the simplest, easiest to maintain and less error prone is the third option. The first option provides the best performance at run-time and the second is a compromise between the first and last. The first option flattens the hierarchy and locates all attributes in one table - convenient for updates and retrievals of any class in the hierarchy, but difficult to authenticate and maintain. Business rules associated with a row are hard to implement, as each row may be instantiated as any object in the hierarchy. The dependencies between columns can become quite complicated. In addition, an update to any class in the hierarchy will potentially impact every other class in the hierarchy, as columns are added, deleted or modified from the table.以上的方法都有成功的案例，但我认为最简单，最容易维护和减少出错是第三个选择。