面向对象设计背后的数据库设计（摘自"The Object Primer"）

1. 把对象映射到关系数据库

首先，类的属性将会映射成关系数据库中的0列或多列（最好使用相似的命名规范）。

对象的有些属性本身就是对象，它真实地反映了两个类之间的关联。

并非所有的属性都是持久的，有一些被用来进行临时计算。

2. 影子信息

影子信息（shadow information）是除了普通领域数据之外，对象需要维护的任何用于将它们自己持久化的数据。

一般如主键信息，特别是没有业务含义的代理主键。并发控制标记、时间戳、增量计数器。

3. 映射继承结构

将继承映射进关系数据库中，有3种主要的方法：

1. 把整个类层次映射到单张表中。
2. 把每个具体类映射成自己的表。
3. 把每个类映射成自己的表。

3种技术的对比

技术	优点	缺点
单表	方法简单 容易增加新的类：仅需要对额外的数据增加新列 通过简单改变行的类型来支持对象多态 数据访问是快速的，因为数据在一张表中 特殊报表是非常容易的，因为所有的数据都可以在一张表中找到	类层次的耦合增加了，因为所有的类都直接耦合到同一张表中。类中的变化可以影响表，这样就影响了层次结构中的其他的类以及他们的相关映射 数据库中潜在的空间资源的浪费，因为许多行将会是空行 当类型之间有严重的重叠式，表明类型变得复杂 对于大型层次结构，表增长得很快
每个具体类一张表	访问单张表中的数据时好的性能 生成特殊报表简单，因为一个类的所有数据都仅存处在一张表中	对类的修改需要我们修改他的表，及其任何子类的表。 无论何时对象改变了他的角色，就需要把数据拷贝到相应的表中。 支持多行信息，还要维护数据完整性，这很困难。
每个类一张表	映射简单，因为他是一对一的 容易支持对象多态，因为我们只在每种类型相应的表中有记录 修改父类和增加新子类非常容易，我们仅需要修改/增加一张表 数据大小的增长与对象数目的增长成正比	数据库中有多张表，每个类一张表（加上维护他们之间关系的表） 潜在的要花更多的阅读和读取数据的时间，因为我们需要访问多张表 特殊报表是困难的，除非我们增加视图来仿真待处理的表

4. 映射关系

对象模式中的关系是通过对象引用和操作的组合来实现的。而在RDB中，他们通过外键来维护。

映射关系的方式依赖于他的多重性：

1. 一对一关系

如果每个类都有一张表对应，那么这两张表之一需要实现一个外键。

第二种策略是简单的在单张表中存储两个类的数据。

2. 一对多关系

它的实现方式是在关系中多的那方面使用Hashset等集合，在一的这方面使用对象引用。

在数据库中，他是在关系中多的一方通过外键来实现。

3. 多对多关系

两个类之间的多对多的关系被映射成数据库内的关联表。

4. 迭代关系

也称为自反关系，它是指关系的两侧都是相同的实体。

我们可以使用非迭代关系相同的方式来映射它们。

功能驱动与用例驱动（关于用例、用户故事和特征的解释）

软件开发过程中，描述并分析需求会同时采用不同的角度和方式。例如功能分析和场景分析。

其中功能分析是指描述系统所应该具有的功能。场景分析是指在特定场景中用户的操作步骤以及系统给出的相应的反应。

功能分析文档所列出的清单一般会叫做“软件需求”或者“系统特征”。

场景分析文档所列出的内容一般就是“用例文档”

由此可见，RUP中所使用的用例驱动开发，XP中所使用的用户故事驱动开发以及特征驱动开发，表面上看起来是以其分割粒度的不同进行排列下来的。其实我们可以看出，用户故事和特征都是从功能分析的角度对系统的需求进行的描述。其与RUP所说的用例驱动完全使用了不同的分析方法。

这样我们就可以更好的理解XX驱动开发之间的区别在那里。

下面是功能驱动与用例驱动之间的对比表格：

功能驱动	用例驱动
当你有许多未密切相关的不同功能时，工作会进行得比较好。 让你可以较快想客户展示可运作的程序代码 是非常功能性驱动的。采用此方式，你不会忘记任何功能。 对具有许多未连接功能性片段的系统，进行的特别好。	当你的应用程序有许多流程与场景，而不是个别的功能性片段时，进行得比较好。 让你在每个开发阶段可以向客户展示较大的功能性片段。 是非常以用户为中心的。采用此方式，你将为用户使用此系统的所有方式编写程序代码。 对交易式系统（系统以冗长、复杂的流程定义而成），进行的特别好。

在实际需求分析的过程中，两种分析方式相辅相成，都有其独到的贡献，最好能够结合使用。

我理解，互联网类型的项目更适合功能驱动开发，而企业业务系统类型的项目更适合用例驱动的开发。