将OLTP关系数据库转换为数据仓库模型

Question

将数据从典型的实体关系OLTP数据库模型加载到Kimball星型模式数据仓库/市场模型中时采用了哪些常见的设计方法？

• 您是否使用暂存区域执行转换然后加载到仓库？
• 如何在仓库和OLTP数据库之间链接数据？
• 在哪里/如何管理转换过程 - 在数据库中作为sprocs，dts / ssis包或应用程序代码中的SQL？

Answer 1

就个人而言，我的工作方式如下：

1. 首先设计数据仓库。特别是，设计作为DW的一部分所需的表，忽略任何临时表。
2. 使用SSIS设计ETL，但有时使用SSIS在相关数据库中调用存储过程。
3. 如果需要任何临时表作为ETL的一部分，那很好，但同时要确保它们得到清理。仅在作为单个ETL步骤系列的一部分使用的临时表应在这些步骤完成后被截断，无论是否成功。
4. 我有SSIS包引用OLTP数据库，至少要将数据提取到临时表中。根据具体情况，他们可以将OLTP表直接处理到数据仓库中。所有这些查询都是使用（NOLOCK）执行的。
5. 文件，文件，文件。明确每个包使用的输入以及输出的位置。确保记录选择输入的标准（自上次成功以来最近24小时？新身份值？所有行？）

这对我来说效果很好，不过我承认我没有完成很多这些项目，也没有做过任何大项目。

Answer 2

我目前正在开发一个中小型数据软件公司。我们采用了Kimball提出的一些概念，即具有事实和维度表的星型方案。我们构造它以便事实只与维度相关联（不是事实或维度维度 - 但这是我们的选择，而不是说应该这样做），所以我们将所有维度连接展平到事实表。

我们使用SSIS从生产数据库移动数据 - ＆gt; source DB - ＆gt; staging DB - ＆gt;报告数据库（我们可能已经使用了更少的数据库，但这就是它的下降方式）。

SSIS非常好，因为它可以让您非常合理地构建数据流。我们使用SSIS组件和存储过程的组合，其中SSIS的一个很好的特性是能够提供SQL命令作为源/目标数据流之间的转换。这意味着如果需要，我们可以在每一行调用存储过程，这可能很有用（虽然有点慢）。

我们还使用了一个名为更改数据捕获（CDC）的新SQL Server 2008功能，它允许您审核表上的所有更改（您可以指定要在这些表中查看哪些列），因此我们使用在生产数据库上告诉我们已经改变了什么，这样我们就可以将这些记录移动到源DB进行处理。

Answer 3

我同意高度评价的答案，但我认为我会添加以下内容：

* Do you use a staging area to perform the transformation and then

     

加载到仓库？

这取决于转换的类型是否需要升级。分段提供了将ETL分解为更易于管理的块的好处，但还提供了一个工作区域，允许对数据进行操作而不会影响仓库。它可以帮助（至少）在暂存区域中进行一些维度查找，该临时区域存储来自OLTP系统的密钥和最新的昏暗记录的密钥，以在加载事实记录时用作查找。 转换发生在ETL过程本身，但它可能需要或可能不需要一些阶段来帮助它。

* How do you link data between the warehouse and the OLTP database?

将业务键（或实际主键，如果可用）加载到数据仓库中作为对OLTP系统的引用非常有用。此外，DW过程中的审核应通过记录加载过程的加载过程来记录每个数据位的谱系。

* Where/How do you manage the transformation process - in the

     

数据库为sprocs，dts / ssis包，   或来自应用程序代码的SQL？

这通常是在SSIS包中，但通常在源查询中进行转换更为高效。不幸的是，这使得源查询很难理解并因此维护，因此如果性能不是问题，那么转换SSIS代码是最好的。执行此操作时，这是具有暂存区域的另一个原因，因为您可以在不同表之间的源查询中进行更多连接。

Answer 4

John Saunders的流程解释很好。

如果您希望在SQL Server中实现Datawarehouse项目，您将在优秀的文本“The Microsoft Data Warehouse Toolkit”中找到交付整个项目所需的所有信息。

很有趣，其中一位作者是Ralph Kimball： - ）

Answer 5

您可能需要查看Data Vault Modeling。它声称解决了一些孤独的术语问题，比如改变属性。