对于所有版本化数据，必须遵循的设计模式是主数据-小版本设计模式。

主数据-小版本模式

此模式通常会建立两个相互协作的对象。如果其中一个对象不存在，则另一个对象不应存在，并且肯定无效。以下基本抽象位于根部：

主接口与迭代接口一起提供即插即用组件的抽象。目的是，在业务模型中，对象将通过继承主接口来断言其为主对象。在执行此断言后，可通过版本控制服务的 API 来管理业务对象。为了对其实例进行迭代，业务对象必须断言自身为一种主对象。

迭代接口与主接口一起提供了即插即用组件的抽象。目的是，在业务模型中，对象将通过继承迭代接口来断言其为小版本 (实例)。在执行此断言后，只要业务对象具有主对象，即可通过版本控制服务的 API 进行增量替换、回滚和汇总。业务对象必须断言自身为一种迭代对象，以便对其进行增量更改。

下一级别的主数据-小版本对定义了抽象实体，这些抽象实体从一般 [虚拟] 企业的角度开始将所有适用的功能融合在一起 (即断言)。下面的级别开始变得更加具体，其中 EnterpriseItemMaster 是具体的，而 EnterpriseItem 则不是具体的。在此级别上，主数据和小版本之间的关联将以精确命名的角色覆盖。但是，应该注意的是，主数据中小版本的基数可以专门化以进一步受到约束。此外，此关联再次将自身指定为外键，并且可以从小版本自动导航主数据。因此，从数据库中获取小版本时，其主数据也会通过一个数据库视图在一条 SQL 语句中获取。

请注意，对于这种与外键的关联，此级别的小版本不必是具体的，并且具体类上的自动导航可以将另一侧作为抽象类。

在最底层，存在 EnterpriseItem 的所有具体专门化产品。所有这些专门化产品都继承了 EnterpriseItem 的外键自动导航关联。因此，每个专门化产品都使用特定的数据库视图生成，从而为 EnterpriseItem1、EnterpriseItem2 和 EnterpriseItem3 生成了三个数据库视图。