数据仓库设计

Posted 2023-03-29

【中文标题】数据仓库设计

【英文标题】：Datawarehouse design

【发布时间】：2021-12-08 10:30:23

【问题描述】：

我将设计一个数据仓库（虽然这不是一个简单的过程）。我想知道整个 ETL 过程，数据仓库中的数据将如何提取/转换到数据集市？ Datawarehouse vs Datamart 中是否有任何模型设计？通常也是starschema或雪花？所以我们应该像下面这样放置表格

在数据仓库中 昏暗表A 昏暗表B 事实表A 事实表B

在 Datamart A 中 dim_tableA（来自数据仓库的完整副本） fact_tableA（来自数据仓库的完整副本）

在数据集市 B dim_tableB（来自数据仓库的完整副本） fact_tableB（来自数据仓库的完整副本）

它是一个真实的例子，可以展示数据仓库和数据集市之间的模型差异吗？

【问题讨论】：

从我的角度来看，数据集市是完整数据仓库中表的子集。无需复制任何内容，只需使用您的报告工具引用表格即可。

同意，数据集市是数据仓库的逻辑子集。我建议您的起点应该是阅读 Ralph Kimball 关于维度建模、实现数据仓库等的各种书籍

如果你说数据集市是仓库中某些数据的逻辑子集，我真的怀疑它的性能。如果你说逻辑的话，假设你在数据仓库之上为数据集市构建维度建模的表视图，这样，来自业务用户的每个查询，基本上都是直接查询数据仓库，但只是通过视图。

数据仓库，在这个上下文中，意味着一个维度模型。数据集市只是这些事实和维度表的子集 - 不需要额外的建模或视图

【参考方案1】：

我赞同 Nick 的回应，并以更技术性的方式遵循 Kimball 方法：

In my opinion and my experience. At high level ,we have data marts like Service Analytics , Financial Analytics , Sales Analytics , Marketing Analytics ,Customer Analytics etc. These were grouped as below
Subject Areas -> Logical grouping(Star Modelling) ->Data Marts -> Dimension &Fact (As per Kimball’s)
Example:
AP Real Time ->Supplier, Supplier Transaction’s , GL Data -> Financial Analytics + Customer Analytics->Physical Tables

【参考方案2】：

数据集市包含收集的汇总数据存储库，用于分析组织内的特定部门或单位，例如销售部门。 ... 数据仓库是一个大型集中式数据存储库，其中包含来自组织内许多来源的信息。

根据他们的需求，公司可以为不同的部门使用多个数据集市，并选择通过合并不同的集市以在以后构建单个数据仓库来整合数据集市。这种方法称为 Kimball 尺寸设计方法。另一种称为 Inmon 方法的方法是首先设计一个数据仓库，然后根据需要为特定服务创建多个数据集市。

一个例子：在数据仓库中，电子邮件点击是根据点击日期记录的，电子邮件地址只是点击参数之一。对于 CRM 专家，电子邮件地址（或任何其他客户标识符）将是切入点：在每个联系人的对面、点击频率、最后一次点击的日期等。

Datamart 是使数据适应用户的棱镜。在这方面，其成功的关键在很大程度上取决于数据的组织方式。用户越容易理解，结果就越好。这就是为什么每个字段的标题及其计算方法必须尽可能贴近行业用途。