数据仓库生命周期管理（四）

[wawaren]

原则III：管理主数据
主数据是指那些关于产品、客户、组织、地理等方面的数据。任何可以被引用的数据都是主数据。一个数据被引用的频率越高，那么对其进行管理的重要性也就越高。良好管理下的主数据可以为度量业务表现提供一个一致的环境。由于相同的产品，在不同的地区，可能属于不同种类的产品。因此如果对于主数据的管理不善的话，那么将会很难获得关于业务运行情况的清晰视图。
在大型的组织中，使用业务系统对主数据进行管理往往是不够的，因为在业务系统中，很少会保存有所有的主数据（例如所有的产品）。
理想情况下，整个业务中的主数据都应该是一致和准确的，其中包括了供应商、客户和其他一些相关部分。但是在实际中，大部分组织都还在努力的达成主数据的一致性。
因此，在一个适应性的数据仓库中，一个重要的组成部分就是有效的管理主数据。在其中，必须认识到目前的数据并不一定是组织良好的，或者非常容易获得的。我们需要提供一个对主数据进行持续管理的工具，使得数据的相关业务人员可以通过工具改善、丰富和发布主数据。如果没有组织良好的主数据，数据仓库可能会产生有疑问的结果，从而会大大降低结果的有用程度。
管理良好的主数据除了可以为交易数据提供一个可靠的周境之外，还能够提高所有系统中数据的质量。通过鼓励让数据拥有者更加专注于本地的编码格式，主数据管理可以提高一致性，从而降低操作中的错误，例如将货物发送到错误的地方等。

原则IV：现实世界业务建模
业务模型是数据仓库设计所依据的业务需求的模型。业务模型对于现实世界的描述越准确，那么需要的变化也就越少，随之创建的数据仓库需要的变化也就越少。从而数据仓库对于业务需求的吻合程度也就越高。
在计划阶段，花费多一些时间设计一个准确的业务模型，最终会在实施和运行阶段得到回报。修改一个业务模型可以只需要几分钟的讨论，但是修改一个数据库以及与之相关的所有代码却可能需要花费上几千小时的人工。
从一个简单的层面来说，通过根据每个对象的自然特征来建立现实世界业务模型可以达到更高的精确性，而不是根据对象的用途或者角色（在适应性数据仓库中可以其他的目的添加第二种分类）。通过这种方法可以延长模型的耐久性，因为事物很少改变其自然特征，与之形成对照的是他们的使用方法可能经常会发生变化。
从概念上来说，“客户“和“供应商“都是“组织“的一个子集。如果在你的业务模型中包含了“客户“和“供应商“，而不是“组织“，那么这个模型很容易发生变化。例如，某个供应商同时又成为了客户，这样就会导致同一个组织出现在业务模型的两个不同区域。当数据仓库中存在这种情况的时候，就会很难获得一个对于外部世界的准确描述和产生准确的报表。在客户关系管理中有这么一个词汇“单一的客户视图“，根据这里的概念，如果将其表述为“单一的组织视图“、“单一的人员视图“可能会更好。
当我们创建一个准确的现实世界业务模型的时候，我们需要确保每一个实体都可以在不参考其他信息的前提，被识别为该类别的一个成员。如果你需要看一下清单才能确定某个实体为“客户“，这就暗示了“客户“并不是一个自然的概念，而更可能是一个角色。你应该将其建模为“组织“。再看一个例子，考虑Marilyn Monroe。在一个现实世界模型中，她应该是一个“人员“。可能你知道她是一个演员，但那只是她在生命中某个时间段所扮演的角色。总可能会有一段时间她不再是演员，但她永远都是一个人。
对于业务模型中的每一个实体类型，我们都需要提醒自己：我是否准确的鉴别出并且根据事物的自然特征进行了命名，还是仅仅根据其当前的某个角色进行命名？对于每一个属性，你都需要提醒自己“这是否是事物天然所具有的？”
当某个业务实体被赋予新的用途或者角色的时候，经常会产生新的业务需求。例如一个当前向你提供货物的组织开始向你购买一些东西的时候，其就成为了一个客户。同样的，当您将销售的范围从企业扩展到个人消费者的时候，在您的“客户“就会出现一部分是企业，一部分是个人，还有一些是自己的雇员。某些适用于个人的属性，如性别，并不适用于企业，整个客户表的结构忽然就变得很复杂了。
如果数据仓库是围绕实体的角色来设计的话，那么就会增加变化的层次，可能会经常碰到需要对业务模型和数据仓库进行重构。另一方面，如果数据仓库的设计是根据实体的自然特征来设计的话，将会降低变化的频率，因为任何组织（个人，等等）不管扮演什么角色，其依然还是一个组织。现实世界建模减少了数据仓库中结构化调整的次数。

原则V：时间变量/企业记忆
企业设计的数据仓库往往要运行一个相当长的时间段。在这段时间内，现实世界的对象可能会发生好几次变化。除非将这些历史捕获下来，否则数据仓库就无法这些对象过去的信息，从而导致很难甚至不可能比较业务在时间上的变化情况。
时间变量就是用于记录一条记录在哪些时间内有效的方法。
在某些情况下，时间变量本身就是业务流程所需要数据的一个重要部分（例如，将销售人员卖出“工业产品“的5%作为佣金返回给他们。佣金的计算是应该根据买卖时候产品的类别，而不是佣金支付时候产品的类别）。另外还存在一些长期运行的过程，在其中也可能会发生一些变化—例如，在一个为期六个星期的旅途中，一艘船只的拥有者和保险人往往会发生不止一次的变化。


上图显示了一个业务场景—在有和没有时间变量情况下，一个产品的重新分类。
在没有时间变量的情况下，产品B只会有一个单一的种类，虽然在4月4日之后，它的类别从Confection类别改变到了Snack Food类别。当发生重新分类之后，产品B和之前类别之间的关系都丢失了，因此无法针对类别进行任何有意义的历史分析。之前在类别层面上计算好的汇总信息当种类发生改变之后，必须重新进行计算。
当带有了时间变量之后，产品B就拥有了两个种类：当时间=一月一日的时候是蜜饯类别，而当日期是3月4日的时候类别是快餐食品。现在我们就可以计算任何时候蜜饯类别产品的真实销售情况了。
那么为什么不把时间变量应用到所有事物上呢？在一个理想的环境下，这样做的确是有好处的，但是实际上由于某些原因造成我们很少这么做。将时间变量应用到关系或者属性的时候存在大量复杂的技术问题。那些最需要时间变量的是决定某种结构的关系，例如企业的组织结构，产品的分类层次等。因此数据仓库开发人员通常只会有选择性的使用时间变化，而不是大量的使用。
当有选择性的使用时间变量的时候，第一个也是最明显的选择是在交易数据，主数据和元数据。交易数据是关于活动在某个地点某个时间发生的数据，例如一个销售活动，一个订单，一次付款。主数据是一些通常的关于业务的共享数据，例如产品、客户、组织等等。元数据是定义或者描述其他数据的数据，例如净利润的定义等。
由于交易数据不会发生变化，因此交易中没有时间变量也不会损失什么任何东西。
主数据一直会发生变化，数据仓库会根据主数据对交易进行分析。为了准确而全面的满足现在和将来潜在的需求，数据仓库必须在主数据上使用时间变量。更准确地说，主数据之间的关系是最值得使用时间变量的地方。这些关系记录了用于对交易记录进行上卷分析的信息。
最后是关于元数据的内容。元数据记录了数据的含义，因此元数据上的时间变量记录了这些含义是如何发生变化的。记录数据仓库中定义发生变化的历史拥有巨大的好处—这样就可以跟踪数据仓库自身变化的历史—但是在实践中却很少见到，因为数据仓库的元数据往往和数据库结构混合在一起。
目前常用的数据库关系系统中都没有提供察看历史元数据的功能。如果元数据本身使用数据进行存储的话，那么就可以在其上使用时间变量。