这个模型基本解决问题，可以方便定义层次，以及反映了三个不同的维数元素，也反映了企业部门单元和维数元素的关系，但是很快可以看到，在这里，维数被局限在三个：也就是说，如果维数需要改变，
那么整个模型都需要更改，那是我们不希望看到的。因此稍作改进之后，得到以下一个模型：
在这个模型里，增加维数变得容易了，而且，用关键字映射（keyed mapping）以及数量上的约束来保证Enterprise Segment 在每个维数上仅对应一个Dimension Element。
每一个层次都需要一个顶层元素，可以定义为“all”，或者“空（nil）”。
如果考虑到维数级别（Level），可以修改上面的模型如下：
在这里，可以定义每一个维数元素的级别，而级别由这个元素在维数层次中的位置决定的，例如，在维数层次中，元素新汉普的上级是东北地区，再上级是美国，往上是all，所以它的级别为3，得到维数级别在list 中对应的结果是地区（Area）。
1.1.1 定义维数（Defining the Dimensions）
要得到比较合理的Enterprise Segment（企业部门单元）定义，维数（Dimension）的定义也是很重要的一个环节。最简单的方法是遵循某种显而易见的组织结构，但是不同的分析会有不同的侧重点，所以这样也并不是每次都可行。
一个更好的办法是观察层次最底层的部分，然后看在那里的是怎么分类的，例如在ACM 的例子里，可以看到重点是咖啡机的出售和出租，因此可以得到咖啡机类别，出售出租地区和销售目标行业这三个维数，用一个名词焦点事件（focal event）来表示这种分类的依据。
分类可能会很复杂而出现交叉，但是，在现实的情况中，很少出现维数（Dimension）会大于6 的情况，导致实际分析中可能需要对上一节的模型稍作修改：尽量考虑一下有没有这样的必要。
维数（Dimension）通常不必细分到最末端的一层，例如在ACM 的例子里不值得，或者甚至可能一直往下分析到每个销售人员的销售范围甚至细到每个具体的顾客，这样的层次对理解整个系统结构是有帮助的，由于复杂度以及具体细节暂时不进行深入讨论。
维数可以由系统分析人员显式定义；否则，就得由企业数据库决定，如果是这样，每个维数就得定义一个builder 操作从数据库查询所要的数据，这也允许系统随着时间的推进增加维数的节点（add nodes to the dimension over time）。
1.1.2 维数和企业部门单元的属性（Properties）
对于维数（Dimension）而言，一条非常重要的规则是维数层次中，上面级别的测量可以由底下级别的测量得到，例如我们想得到东北地区的销售收入，就可以累计东北地区下属地区所有的销售收入。每一个维数都必须支持这一规则，具体运算通常是累加，但也有例外（参见本文第2.5 节）。
维数的定义经常跟企业结构有关，不过还有一个非常重要的通用维数是时间（time），也满足上一规则。
企业部门单元（Enterprise Segment）还有一个有趣的属性，那就是：它们是概念存在的，就像许多基础的数据类型一样，哪怕它们并没有创建成为软件对象。我们仍然把它当作非基础数据类型，创建时是一种查找/创建形式，即首先查看要求的实例是否存在，如存在，返回它作为结果，如不存在，创建它。
1.2 测量协议（Mesurement Protocol）
在企业金融分析中要用到许许多多的测量（measurements）,这些测量不是用手工输入的，它们通常来自数据库，或者从其他的measurements 计算而来，也就是说，获得这些测量的途径很重要，下面的模型给出了关于测量协议（Mesurement Protocol）的一个大体框架，跟第三章中的模型很类似：
在在上述模型中，给出了两种测量协议：Source Measurement Protocol 和Calculated Measurement Protocol，
其中Source Measurement Protocol 指的是从企业数据库查询，一般来说一个对象知道去哪里取数据，哪怕实际的代码可能在另外的层次中（用户应该决定）。而Calculated Measurement Protocol 代表测量由系统中已有的测量对象计算而来。
需要指出的是，在这个模型中，一种类型（Phenomenon Type）可能对应几种测量协议，例如，同一个Phenomenon Type 可能同时拥有源/计算协议。一般来说应该由用户确定到底采用哪个具体的协议，但也可以从 Phenomenon Type 到Measurement Protocol 形成一个映射表，并从前到后表明各个Measurement Protocol 的优先级，以供系统选用。
还有要注意的是Calculated Measurement，连接到它的源（Sources）测量对象，这是基于计算结果的通用原则：当结果作为对象时，它应该知道哪种计算方式给出结果（协议），还有对这个协议的输入（Sources）。
