很多系统设计师都认定软件开发与解决新问题没有什么关系。毕竟，把如今的软件系统所完成的功能和20年前作一下比较，所针对的问题本身基本上是相同的。会计、销售订单处理、定购单处理、航班管理，几乎任何其它软系统都遵循相同的基础业务规则。但是，新的软件工具、硬件平台以及互联方式允许设计师和程序员以完全不同的方式来解决相同的业务问题。
许多这样的业务问题使用了相同的核心软件架构。例如，很多业务系统需要处理包含相似但细节并不相同记录的交易。让我们来看看一个开支管理系统的例子。
一个开支管理系统的目标是，用户能够提交其业务活动的所有记录以便用来报销和分类。职员都希望自己为公司利益而付出的费用能够报销。而公司则希望确保支出的经费在公司内部账目上正确地登记。如果你看看一份商业开支表，把它的各个项目转变成数据库表看起来好像非常简单。但是如果你深究一下，问题就变得复杂多了。
复杂的地方在于个人支出项目的表示上。创建一个包含公司和个人支出报告的题头栏和特定细节栏都很简单。比如支出发生的时段和是否有预付款。所有项目行都有支出的日期和原因，但是共同点也到此为止。里程条目也许包含这样的项目，比如个人出发、到达、开始、结束的地点汽车里程表的读数。住宿费包含如税金、业务电话以及小费等的细节。国税局要求款待条目指明款待人以及他们和业务的关系。
关系数据库的支持者也许认为这个问题是小儿科，他们的解决方案里包括一套相关联的表。一个支出报告题头表会包括与报告有关的条目以形成整体。支出报告细节汇总表会包含所有支出报告行通用的条目，例如日期描述。每个细节汇总表还内含一个指向另一个包含此类记录细节的表的指针。
例如，里程表里的记录包含某个唯一标识，这个标识与其对应的记录的细节（比如（每）里程费用、出发、到达的地点以及汽车里程表读数）一起存储在细节汇总表里。款待细节表会包含国税局要求的条目并把其唯一标识存储在细节汇总表里。当队某个特定的支出报告列出清单时，程序员只需重复的从细节汇总表出发，连接到相应的支出细节表来取出所需的细节。
虽然这个问题能够使用关系数据库技术来解决，但是这种解决方案的结果是难以编码实现以及必须在程序员的干涉下才能扩充。说它难以编码实现是因为打印一份简单的支出报告却需要连接到各个外部表并对其进行管理。说需要程序员干涉才能扩充是因为每个新的细节类型都需要它自己的外部表，并且需要程序员重写支出报告的打印和数据存取机制以接纳新的细节类型。
