将典型实体关系 OLTP 数据库模型中的数据加载到 Kimball 星型模式数据仓库/集市模型中时采用了哪些常见设计方法?
- 您是否使用暂存区执行转换然后装入仓库?
- 如何在仓库和 OLTP 数据库之间链接数据?
- 您在哪里/如何管理转换过程 - 在数据库中作为 sprocs、dts/ssis 包或来自应用程序代码的 SQL?
将典型实体关系 OLTP 数据库模型中的数据加载到 Kimball 星型模式数据仓库/集市模型中时采用了哪些常见设计方法?
就个人而言,我倾向于按以下方式工作:
这对我来说效果很好,尽管我承认我没有做过很多这样的项目,也没有做过任何真正的大项目。
我同意高度评价的答案,但我想我会添加以下内容:
* 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 代码中进行转换是最好的。当您这样做时,这是拥有暂存区域的另一个原因,因为您可以在不同表之间的源查询中进行更多连接。
我目前正在开发一个中小型数据仓库。我们采用了 Kimball 提出的一些概念,即带有事实和维度表的星型方案。我们对其进行结构化,以便事实仅连接到维度(不是事实到事实或维度到维度 - 但这是我们的选择,并不是说它应该这样做),所以我们将所有维度连接展平到事实表。
我们使用 SSIS 将数据从生产数据库 -> 源数据库 -> 暂存数据库 -> 报告数据库(我们可能使用更少的数据库,但这就是它的方式)。
SSIS 非常好,因为它可以让您非常合乎逻辑地构建数据流。我们使用 SSIS 组件和存储过程的组合,其中 SSIS 的一个很好的特性是能够提供 SQL 命令作为源/目标数据流之间的转换。这意味着如果我们愿意,我们可以在每一行上调用存储的过程,这很有用(虽然有点慢)。
我们还使用了名为更改数据捕获 (CDC) 的新 SQL Server 2008 功能,它允许您审核表上的所有更改(您可以指定要查看这些表中的哪些列),因此我们在生产数据库告诉我们发生了什么变化,这样我们就可以将这些记录移动到源数据库进行处理。
John Saunders 的过程解释很好。
如果您正在寻找在 SQL Server 中实现数据仓库项目,您将在优秀的文本“ Microsoft 数据仓库工具包”中找到交付整个项目所需的所有信息。
有趣的是,其中一位作者是 Ralph Kimball :-)
您可能想看看Data Vault Modeling。它声称解决了一些孤立的问题,例如更改属性。