12.企业应用架构模式 --- 对象－关系结构模式

1.标识域
	为了在内存对象和数据库行之间维护标识而在对象内保存的一个数据库标识域。
	关系数据库通过使用键尤其是主键来区分数据行。然而，内存对象不需要这样一个键，因为对象系统能够保证正确的身份确认(在C++中是直接用原始内存的位置)。在数据库中读取
  数据非常方便，但是为了顺序写回这些数据，需要把数据库和内存对象系统联系在一起。
  	本质上，标识域是非常简单的。你要做的所有工作只是将关系数据库表的主键存储在对象的域中。

  	1.工作机制
  		1.选择你的键
  			第一个问题就是在数据库中应该选择什么样的键。首要问题是究竟使用有意义的键还是无意义的键。有意义的键类似于用来鉴别个人身份的社会保险号(SSN)。无意义的键
  		  本质上是数据库构造的一个并不打算供人使用的随机数。
  		    下一个问题是简单键和组合键。一个简单键只使用一个数据库域；一个组合键则使用多个数据库域。使用组合键的好处在于：当一个表与另外一个表上下文相关的时候它经常
  		  更易于使用。
  		    你必须选择键的类型。对键所进行的最常见操作是相等性检查,所以通常需要选择一个能快速进行相等操作的类型。另外一个重要的操作是得到下一个键。因此长整数型通常是
  		  最好的选择。
  		    键可以在表中唯一，也可以在数据库中唯一。

  		2.对象内标识域的表示
  			形式上最简单的标识域是与数据库中的键匹配的域。
  			组合键的问题就要多一点。处理这种类型的最好办法是建立一个键类。一个普通的键类可以存储对应于组合键元素的一个序列。键对象的关键行为是相等判断。

  		3.取得新键
  			创建一个对象需要一个键。有三种选择：数据库自动生成，使用GUID或者自己创建一个。
  			最通用的自动生成方法是声明一个自动生成域，无论什么时候插入一行数据，这个域都会递增到一个新值。这种策略的问题在于难以确定为键生成的是什么值。还有一种办法就是
  		  用数据库计数器。
  		  	GUID(全局唯一标识符)是指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。通常平台会提供生成GUID的API。生成算法是，用到了以太网卡的地址，
  		  纳秒级时间，芯片ID码和许多可能的数字。这样得到的结果数字完全唯一，因此是安全的键，GUID的唯一缺陷在于生成的结果串会比较大。
  		  	最后一个选项是自己来产生键值。对小系统的一个简单例子就是用sql的max函数来进行表扫描，最大值加1。可惜这样做会锁表。更好的办法是使用独立的键表。典型的键表有2列：
  		  列名和下一个有效值。

    2.使用时机
    	在内存对象与数据库行之间存在映射关系的时候使用标识域。这通常是在使用领域模型或者行数据入口的情况下。如果使用事务脚本，表模块或者表数据入口，就不需要这种映射。

2.外键映射
	把对象间的关联映射到表间的外键引用。对象可以通过对象引用来互相直接访问。

	1.运行机制
		显然这个问题的关键就是标识域。每一个对象都包含来自相应数据库表的数据库键。如果两个对象用一个关联关系联系起来，则这种关联关系可以由数据库中的一个外键来取代。

	2.使用时机
		外键映射适用于类间几乎所有的关联。最常见的不适用情况是多对多关联。外键是单值的，第一范式意味着不能在一个单值域内保存多个外键。在这种情况下，需要使用关联表映射。

3.关联表映射
	把关联表保存为一个表，带有指向(由关联所连接的)表的外键。
	通过使用集合作为值域，对象可以很容易的处理多值域。关系数据库没有这种特性，它受到约束，必须只是单值域。当你映射一个一对多关联时，可以使用外键映射来处理这个问题，
  实际上是为关联关系的单值端使用一个外键。但是，一个多对多的关联关系就不能这么做，因为这种关系，已经没有单值端可以保持外键了。
  	解决办法是一个很经典的方案：创建一个额外的表来记录这种关系。然后使用关联表映射来把多值域映射到这个链接表中。

  	1.运行机制
  		关联表映射的基本思想是使用一个链接表来保存这种关联关系。这个表仅仅含有2个互相关联的外键id，对于每一对相关联的对象，它都有一个数据行与之对应。关联表没有相对应
  	  的内存对象。因此，它也没有id。它的主键就是互相关联的链表表的主键的组合。简而言之，需从链接表中加载数据就需要两次查询。

  	2.使用时机
  		关联表映射的标准情况就是一个多对多的关联关系。

4.依赖映射
	让一个类为部分类执行数据库映射。
	有些对象很自然的在其他对象的上下文中出现。无论什么时候一张潜在的唱片被加载或者被保存的时候，这张唱片上的曲目都有可能被加载或被保存。如果它们没有被数据库
  中的任何其他表所引用，那么就可以通过让唱片映射器来为曲目执行相关映射来简化映射过程。我们把这种映射看作是依赖映射。

  	1.运行机制
  		以来映射的基本思想是在数据库持久化时，数据库中的某个类(依赖着)依赖于其他类(所有者)。每个依赖者有且只有一个所有者。

5.嵌入值
	把一个对象映射成另一个对象表的若干字段。
	嵌入值把一个对象的值映射成该对象的所有者记录中的字段。

	1.运行机制
		这种机制很简单。当所有者对象被加载或者保存时，依赖者对象也同时被保存或者加载。依赖者类将没有自己的持久方法，因为所有的持久工作都由所有者完成。可以把
	  嵌入值看成是依赖映射的一种特殊情况。

6.序列化LOB
	通过将多个对象序列化到一个大对象(LOB)中来保存一个对象图，并存储在一个数据库字段中。
	对象模型经常包含一些小对象组成的复杂图。这些结构中的很多信息并不是存在对象中，而是存在它们之间的链接关系中。把这些全部放进关系数据库中不是一件很容易的事。基本的
  方案非常简单---一个带有上级外键的组织结构表，但是这个方案进行处理时需要许多连接。

  	1.运行机制
  		有2种方法进行序列化：二进制形式(blob)或者文本字符形式(clob)。blob往往是最容易创建的，因为多数平台都包含了自动序列化对象图的能力。保存图是很容易的事情，仅仅需要
  	  在一个缓冲区中应用序列化，然后把这个缓存区保存到相应的域中。
  	  	blob的好处在于易于编程，并且使用最小的空间。缺点就是数据库必须支持二进制数据类型，而且没有对象就不能重新构造对象图，因此偶然查看这个字段是很难理解其含义的。最严重的
  	  问题可能是版本问题。如果改变了部门类，可能就无法读出它以前的序列化部门，因为数据可以在数据库中保持相当长的一段时间。
  	    另外一个选择就是clob。在这种情况下，把部门图序列化到一个文本字符串中，让它带有你所需要的信息。文本字符串可以很容易就被查看数据行的人看懂，对偶然查看数据库是有帮助的。
  	  然后使用文本的方法会比较占用空间，并且需要为使用的文本格式创建自己ID解析器。clob还可能要比二进制序列化慢。
  	    clob的许多缺点都可以使用xml克服。xml解析器随处可见，所以不需要自己写。并且xml是一种广泛的使用标准，所以当某些工具可以用来进一步操作时，你可以充分利用这些工具。xml
  	  不能解决的问题是空间问题。实际上它使空间问题更加严重，因为它是一种非常冗长的格式。解决这个问题的办法之一是使用压缩的xml格式作为blob，当然这样会失去可读性。

  	2.使用时机
  		序列化的lob还是用的比较少。xml使它更有吸引力，因为它遵从一种易于实现的文本化形式。它最大的缺点是不能使用sql查询得到它的结构。sql扩展能在一个字段中访问xml数据，但是
  	  它们仍然是不相同。

7.单表继承
	将类的继承层次表示为一个单表，表中的各列代表不同类中的所有域。
	关系数据库并不支持继承，因此在把对象映射到数据库的时候必须考虑如何用关系数据库来表现继承结构。当映射到关系数据库的时候，我们要努力减少连接操作的数量，在多个表中处理继承结构
  时连接操作的数量会迅速上升。单表继承把一个继承结构中所有的类的所有域都映射到一个单表中。

  	1.运行机制
  		在这个继承方案中，我们使用一个表包含某个继承层次中所有类的所有数据。每个类负责把与之相关的数据保存在表的一行中。数据库中其他不相关的列留空。最基本的映射行为遵循继承
  	  映射器的通用模式。
  	  	在往内存加载一个对象的时候，必须知道实例化哪个类来创建这个对象。为此，数据表中有一个域用来指示应该使用哪个类。

8.类表继承
	用每个类对应一个表来表示类的继承层次。
	对象 --- 关系不匹配的一个显而易见的事实是关系数据库不支持继承。我们想要让数据库结构能很清楚的映射到对象，并且允许在继承结构的任何地方建立链接。类表继承通过给继承结构中的
  每一个类使用一个数据库表来支持这一点。
  
9.具体表继承
	用每一个具体类对应一个表来表示类的继承层次。

10.继承映射器
	用来组织可以处理继承层次的数据库映射器的一种结构。