数据仓库中的维度设计与派生模式优化
1. 核心维度的晚发现问题
在数据仓库的维度设计中,有时会出现核心维度晚发现的情况。当主题领域在开发时缺乏企业级的整体规划,可能会在两个或多个维度投入生产后,才意识到它们共享一些核心属性。
例如,一家图书和杂志销售商在部门层面进行数据集市开发。负责处理图书订单的部门为订单开发了一个星型模式,包含一个名为“book”的维度;订阅部门也有自己的数据集市,包含一个名为“magazine”的维度。后来,财务部门希望添加一个用于盈利能力分析的数据集市,需要将按产品提供的成本数据与订单进行关联。这时就会发现,最初建模为单独维度表的“books”和“magazines”,实际上是一个核心产品维度的定制版本。
这种情况的困难在于,定制维度已经构建完成,它们的公共属性没有一致的名称或数据类型,也不共享一个公共的键域。事后构建核心维度需要对原始表进行一些结构调整、内容调整和键值重新分配。这反过来会对相关的事实表产生连锁反应,需要更新外键引用,现有的报告也需要重写 SQL。
2. 使用通用属性
2.1 通用属性的概念
维度设计可以通过使用通用列来容纳异构属性。对于给定的行,每列中存储的内容由其类型决定,可以使用辅助表将每列的用途映射到每种类型。
通用属性的使用旨在使用一组列来捕捉各种类型的多样性。在维度表中,描述核心属性的一组列会辅以一组多用途列,其用途会因类型而异。
2.2 示例:设施维度表
以处理位置数据为例,企业可能有多种类型的设施,如工厂、仓库、商店和办公室。每种设施都有名称、负责人标识以及一些特定类型的特征。下面是一个设施维度
超级会员免费看
订阅专栏 解锁全文
10

被折叠的 条评论
为什么被折叠?



