目录
1.需求调研
(1)作为维度建模人员要与数据需求发起方、所涉及的源系统业务方进行需求评审,一般通过访谈或者联合会议的方式进行。
(2)将访谈和会议的结果记录并进行汇总。最终形成的需求文档要以业务过程为中心。对每个过程,要描述为什么业务用户期望分析过程指标度量,他们需要得到何种能力,当前他们所受到的限制,可能存在的好处或影响是什么。处理每个过程的可行性评价也是非常重要的内容。
(3)在需要文档中要体现需求的优先级,一般优先级根据两方面进行衡量:业务的潜在影响和价值;可行性
(4)根据需求文档中涉及的业务,确定业务过程,并形成企业的总线矩阵
2.数据探查
(1)源系统的存储类型
(2)数据量大小,每日新增大小
(3)是否有物理删除
(4)是否有增量时间戳
(5)列属性检查
(6)结构性检查
(7)业务规则检查
3.高层模型设计
高层模型设计是总线架构获取的图形化模型,并确定设计范围和所设计的事实表以及相关的维度表的粒度,声明粒度即在这一步完成。
高层图图形化地表示了业务过程的维度和事实表,如下图所示。
粒度描述需要建模人员考虑满足业务需求需要什么样的数据以及现有的物理数据源可以提供什么样的数据,气泡图必须根据物理数据设计。总线矩阵的一行可能会用多个气泡图表示,每个气泡图对应于具有特定粒度的特定事实表。
大多数主要的维度在确定了事实表可以自然而然的获得。清楚地事实表粒度声明的重要影响是可以精确的以图示化的方法表示有关的维度。
4.开发详细的维度模型
有了高层模型,就要设计维度和度量,维度和度量清单不仅仅是业务用户所关心,还要从业务过程触发,自上而下的设计所设计的维度和度量。防止业务用户的需求变化带来的冲击。
在高层气泡图设计完成后,就要开始关注细节了。最有效的方法先开始设计维度表,然后考虑设计事实表。在开始细节设计过程中要已经具备明确的维度表。日期维度一般作为首选开始,这样能够及早的理解建模过程,确保建模工作更早的获取成功。
维度建模确定每个维度内有趣且有用的属性,并确定每个事实表应该具有的适当的度量。要不断获取源、定义以及如何获得这些属性和度量的基本业务规则。在详细设计过程中持续不断的加深对源系统和系统化数据概要的分析,这将更有助于建模人员更好的理解其拥有的源数据实际情况。
在详细设计之前,为数据仓库系统指定规范,主要包含源系统、主题、业务术语、报表、物理设计命名、调度任务、文档方面的规范。
4.1 确定维度及其属性
再详细设计阶段,将定义关键的一致性维度(当不同的维度表的属性具有相同的列名和领域内容时,称维度表具有一致性)。数据建模人员要获取组织一致认同的表和属性命名、描述和定义的关键资源。
4.2 确定事实
声明粒度是对事实表度量的讨论成果,因为事实表都必须与粒度保持一致。
4.3确定缓慢变化维度技术
针对维度表的每个属性,需要定义在源系统数据发生变化时会对维度表产生何种影响,并针对该影响选择合适的处理SCD(缓慢变化维度)方案
4.4 建立详细的表设计文档
详细设计文档包括从源系统到维度模型的每个数据层的物理映射文件
详细建模阶段的关键交付品是设计工作单。应该为每个维度表和事实表建立不同的工作单。支持信息至少应该包括属性/事实的名称、描述、示例值、每个维度属性的缓慢变化维度类型标识。此外,详细的事实表设计应该确认每个外键关系、适当的退化维度,以及表明每个事实是可加、半可加还是不可加的相关规则。
4.5 对模型出现的问题进行追踪
在设计过程中发现的所有问题、定义、转换规则和数据质量挑战必须记录到问题追踪日志中,并跟踪解决相关问题。
4.6 维护并更新总线矩阵
在详细的建模过程中,通常对建模的业务过程会有新的发现。常见的情况是,这些新发现可能会引入新的事实表以支持业务过程,可能会出现新的维度,也可能需要重新规划或合并维度。在整个设计过程中,必须保持对总线矩阵的更新,因为详细的总线矩阵是关键的交流和规划工具。
5.审查验证模型
详细设计文档出来后,要和业务用户和团队成员进行评审,记录下来评审过程中的问题,形成问题清单
6.完成设计文档
在模型稳定后,应该对模型涉及过程中的工作文件进行编制,形成设计文档。该文档包括:
(1)项目的简短描述;
(2)高级的数据模型图;
(3)详细的针对每个事实和维度表的维度设计工作单;
(4)开放的问题
版权归原作者 清清清清风 所有, 如有侵权,请联系我们删除。