语言 Chinese, Simplified

SEO Title

维度建模

Daniel Linstedt，Michael Olschimke，《用数据保险库2.0构建可扩展数据仓库》，2016年

摘要

数据保险库建模不能替代维度建模，维度建模是定义数据集市（用于向最终用户显示数据的层）的行业标准。因为这本书的目的是涵盖端到端构建数据仓库的整个过程，所以它也涵盖了维度建模。本章的第一部分主要介绍维度建模中的基本实体——事实实体和维度实体。事实实体存储业务流程的度量、度量或事实。维度实体包含事实的描述性属性。它将讨论各种维度类型，例如缓慢更改维度以及如何从维度模型查询数据。本章的第二部分将解释如何处理多个星型模式，特别是使用一致的维度。最后一部分重点介绍了维度设计技术，并将雪花模式和星型模式作为雪花模式的特例进行了介绍。

数据仓库建模简介

W、 H.Inmon，Daniel Linstedt，《数据架构：数据科学家入门》，2015年

数据仓库建模的基本规则

必须遵循数据保管库建模中的一些基本规则，否则模型本身不再符合数据保管库模型的条件。这些规则全部记录在课堂环境中。但是，有些规则如下：

业务密钥由粒度和语义分开。这意味着关键客户公司和客户个人必须存在或记录在两个独立的中心结构中。
跨越两个或多个业务键的关系、事件和交叉点被放置到链接结构中。
链接结构没有开始日期或结束日期；它们只是数据到达仓库时关系的表达式。
卫星按数据类型、分类和变化率分开。数据类型通常是单一源系统。

原始数据保险库建模不允许也不提供诸如一致性之类的概念或概念，也不处理超类型。这些职责属于业务保险库模型（用作信息传递层的另一种形式的数据保险库建模）。

数据保险库2.0建模

Daniel Linstedt，Michael Olschimke，《用数据保险库2.0构建可扩展数据仓库》，2016年

摘要

本章介绍数据仓库建模中使用的实体，包括集线器、链路和卫星。它显示了如何在源代码提取中标识业务密钥，并使用链接实体将它们链接到数据保管库中的其他业务密钥。本章还展示了如何识别源提取中的附加属性，以及如何将它们建模为卫星实体。关于卫星的讨论包括需要根据不同方面对卫星进行拆分，例如按数据的分类或类型、按变化率或按源系统进行拆分。对于每个实体，列出并详细说明了在对数据保险库建模时应添加的这些实体的公共属性。这包括建议使用哈希键、时间戳和记录源标识符。

加载数据存储库

Daniel Linstedt，Michael Olschimke，《用数据保险库2.0构建可扩展数据仓库》，2016年

12.2.2基于历史的参考表

基于历史的参考表实际上由两个表组成（有关其定义的详细信息，请参阅第6章“高级数据保管库建模”）。第一个表与无历史记录引用表具有相同的结构，并提供代码列表和列表中代码的一些非历史化属性（可选）。加载过程与上一节中描述的相同。

12.2.2.1 T-SQL示例

第二个表是挂在参考表上的卫星。以下语句在引用表上创建附属表：

此附属项使用代码引用其父表，而不是哈希键。这是因为父引用表中没有哈希键，因为引用表的目的是提高数据的可读性。由于不使用散列键，因此将聚集索引用作主键以提高读取期间的性能。此附属程序使用哈希差异列来改进插入新记录时的列比较。

许多附属列已经在父引用表中。但是，这个例子展示了除了为业务用户提供的不带历史记录的简单引用表之外，如何跟踪对源系统数据的更改。在其他情况下，只有父引用表中未使用的属性才会添加到历史化附属表中。最好的方法留给数据仓库团队。

为了将附属表加载到引用表上，可以使用以下语句：

加载维度信息集市

Daniel Linstedt，Michael Olschimke，《用数据保险库2.0构建可扩展数据仓库》，2016年

14.4实现时间维度

第14.2节和第14.3节中的示例演示了如何使用hub表和从属卫星或PIT表和从属卫星之间的连接来提供类型2维度。所有这些连接都基于加载日期，以在从属卫星中查找给定快照日期的当前记录。之所以使用加载日期，是因为它提供了有关数据历史记录中记录的技术有效性的信息：从技术角度来看，在给定时间点上哪个数据是最新的。

但是，在某些情况下，业务用户不希望从技术角度分析数据。相反，他们对基于业务定义的生效日期的时间透视图感兴趣。这些生效日期有多种方式，例如有效起始日期和有效截止日期以及成员资格开始日期和成员资格结束日期。第5章“中间数据保险库建模”展示了如何将这些有效日期存储在有效性卫星中，这些卫星将添加到集线器和链接中，以指示集线器中的业务密钥是否在源系统中删除或已无效，以及数据保险库2.0链接中业务密钥之间关系的有效性。这些卫星还确保以可审计的方式跟踪对这些有效日期的更改。

为了创建反映时间透视图的2类维度，可以使用PIT表的特殊形式。下表实现了这种临时PIT：

注意，标准坑和临时坑之间的结构没有区别。但是，在加载临时PIT表时，不是基于加载日期预连接数据，而是使用有效日期或任何其他描述性日期：

连接条件基于来自卫星的当前活动记录（如加载结束日期为空所示），以及来自描述卫星（不是有效性卫星）的有效开始日期和有效结束日期之间的PIT的快照日期。但是，如果原始数据中的生效日期发生更改，则需要更新PIT，以便从PIT中删除过去的记录或记录，并且上面的语句插入业务请求的当前视图。从性能的角度来看，更新表将是昂贵的。相反，将加载日期添加到临时PIT表并在其上进行分区，并在成功加载当前分区时删除旧分区。这样，时间PIT表就变成了连接的滚动历史。

为了将数据呈现给业务用户，可以使用第14.3.3节中的类似视图：

两个视图之间的唯一区别是事实表的主要来源，事实表是上面的临时PIT表，而不是标准PIT表。除此之外，视图定义与以前完全相同。因此，对于直接访问数据保险库2.0模型的超级用户来说，这也很容易使用，因为他们只需要更改PIT源，以便访问数据的时间视图，而不是技术历史化视图。

此语句使用与标准数据保险库卫星相同的加载方法，如第12.1.4节所述。左外部连接基于卫星的父键，由参考代码和加载日期组成。此语句中的列比较基于哈希差异以提高加载性能。必须为暂存区域中的每个加载日期执行该语句，用变量替换所示SQL语句中的硬编码加载日期。

该卫星还要求在之后结束日期，类似于第12.1.5节中描述的过程。

Data Vault 2.0简介

W、 H.Inmon。。。Mary Levins，数据架构（第二版），2019年

技术观点

数据仓库建模是针对逻辑企业数据仓库的一种基于第三范式和维度建模的混合建模方法。数据保险库模型构建为一个可应用于大数据、结构化和非结构化数据集的基本、增量和模块化模型。

DV2建模的重点是提供灵活的、可伸缩的模式，这些模式协同工作，按业务密钥为企业数据仓库集成原始数据。DV2建模包括一些小的更改，以确保建模范式可以在大数据、非结构化数据、多结构数据和NoSQL的结构中工作。

Data Vault Modeling 2.0将序列号更改为哈希键。哈希键提供稳定性、并行加载方法和记录的父键值的解耦计算。对于在内部散列业务密钥值的引擎，有一种替代方法，即使用真实的业务密钥，而不使用序列或散列代理项。每种技术的优缺点将在本章的“数据仓库建模”一节中详细介绍。

数据仓库建模简介

W、 H.Inmon。。。Mary Levins，数据架构（第二版），2019年

数据保险库模型的基本规则是什么？

必须遵循数据保管库建模中的一些基本规则，否则模型本身不再符合数据保管库模型的条件。这些规则全部记录在课堂环境中。但是，有些规则如下：

业务密钥由粒度和语义分开。这意味着客户公司和客户个人必须存在或记录在两个独立的中心结构中。
跨越两个或多个业务键的关系、事件和交叉点被放置到链接结构中。
链接结构没有开始日期或结束日期；它们只是数据到达仓库时关系的表达式。
卫星按数据类型/分类和变化率分开。数据类型通常是单一源系统。

原始数据保险库建模不允许也不提供一致性等概念或概念，也不处理超级类型。这些概念位于业务保险库模型（用作信息传递层的另一种形式的数据保险库建模）中。

数据仓库简介

W、 H.Inmon，Daniel Linstedt，《数据架构：数据科学家入门》，2015年

数据保险库1.0

Data Vault 1.0高度关注datavault建模组件（稍后将介绍）。数据保险库1.0模型将代理项序列键附加为其对每个实体类型的主键选择。不幸的是，代理序列显示出以下问题：

引入对ETL/ELT加载范式的依赖性
包含上限/上限；达到上限时可能导致问题
是毫无意义的数字（对企业来说毫无意义）
在加载大数据集时导致性能问题（由于依赖关系）
减少加载进程的并行性（同样由于依赖关系）
不能用作数据放置的MPP分区键，这样做可能会导致MPP平台中的热点
在恢复加载期间无法可靠地重建或重新分配（重新附加到其旧值）

Data Vault 1.0不能满足大数据、非结构化数据、半结构化数据或非常大的关系数据集的需要。

数据仓库简介

Daniel Linstedt，Michael Olschimke，《用数据保险库2.0构建可扩展数据仓库》，2016年

1.3 Data Vault 2.0简介

数据仓库实际上代表了一个商业智能系统。数据仓库系统的真正名称是：通用基础仓库体系结构。该系统包括许多与设计、实现和管理数据仓库业务相关的方面。对Data Vault 1.0的一些历史研究表明，datavault1.0高度关注数据仓库建模，即致力于构建原始企业数据仓库的物理和逻辑数据模型。另一方面，Data Vault 2.0已经扩展，它包含了许多成功实现数据仓库和商业智能所必需的组件。这些组件包括：

Data Vault 2.0建模—更改模型以提高性能和可扩展性
Data Vault 2.0方法论——遵循Scrum和敏捷最佳实践
数据保险库2.0体系结构-包括NoSQL系统和大数据系统
Data Vault 2.0实现——基于模式、自动化、生成CMMI级别5

这些组件中的每一个在企业数据仓库项目的总体成功中都扮演着关键的角色。这些组成部分结合了业界已知和经过时间检验的最佳实践，从CMMI（能力成熟度模型集成），到六西格玛、TQM（全面质量管理）和PMP（项目管理专业人员）。Data Vault 2.0建模现在包括一些更改，这些更改允许模型与NoSQL和大数据系统无缝交互（或实时交互）。Data Vault 2.0方法集中于2到3周的sprint周期，对可重复的数据仓库任务进行了调整和优化。Data Vault 2.0体系结构包括NoSQL、实时feed和用于非结构化数据处理和大数据集成的大数据系统。Data Vault 2.0的实现侧重于自动化和生成模式，以节省时间、减少错误并提高数据仓库团队的生产率。

数据保险库2.0方法

Daniel Linstedt，Michael Olschimke，《用数据保险库2.0构建可扩展数据仓库》，2016年

3.2.3平行小组

定义角色和职责有助于将更多的团队成员和整个团队添加到项目中，从而扩大项目规模。每个团队在小范围的交付上操作，不依赖于其他团队。所有的工作都是并行完成的，几乎不需要同步。他们使用本章中定义的相同模板，并生成遵循相同准则的文档。在实现和交付业务需求时，并行工作的团队使用链接实体同步其数据模型，这将在第5章“中间数据存储库建模”中讨论。

对于现有的数据保管库团队，新的团队成员不需要具备很多先前的知识或数据保管库技能。为了向正在运行的项目中添加新的人力资源，除了解开发环境和开发规则外（按任务），还需要以下技能：

从源到阶段加载：新的团队成员需要知道如何创建新的阶段表并从源表加载数据。在最好的情况下，这只需要一个CREATE表和一个INSERT INTO…SELECT FROM构造。
阶段到集线器和链接加载：再次，非常相似和简单。它只需要一个SELECT DISTINCT，一些过滤只处理不存在的记录，并插入到语句中以加载集线器和链接。
阶段到附属加载：仅使用SQL语句时，仅使用SELECT DISTINCT、行比较和INSERT来存储实际数据。

此列表应清楚地表明，在已有数据保险库专家的项目中添加其他资源不需要具备大量的数据保险库技能。经验丰富的开发人员和建模人员可以指导新的团队成员完成这些任务。注意，这些技能适用于不使用ETL工具的团队。除了这些技能之外，所选ETL工具（如Microsoft SQL Server集成服务）还需要知识。第12章“加载数据保管库”说明了如何使用Microsoft SQL Server将数据实际加载到数据保管库中。

除了业务需求的并行实现外，还有其他团队专注于项目中的不同活动，如需求收集、数据挖掘、托管自助服务BI等。这些活动也与实现并行运行。

原文：https://www.sciencedirect.com/topics/computer-science/data-vault-modeli…