数据仓库建模

问题描述

假设我有 6 个数据库，多个行业，大部分架构相似。

目前我们有数十个 excel 文件连接到每个数据库并查询实时数据（工作订单、发票等）。

据我所知。创建一个单独的 DW 数据库将有利于性能，而且在重新建模时，将消除我们 QA 人员目前所需的复杂连接。

我是否有一个非规范化的表，称为“WorkOrder”，它也是跨 5-6 个系统的所有工作订单的合并，这是否合理？当它们重叠时，我将如何处理每个工单的主键？我假设每个列都有一个不同的列，有一个唯一的前缀来指定源数据库？

工单表应该只包含公共字段，还是所有字段都更有意义，将原始数据中不存在的那些字段清空？

毫无疑问，从 QA 的角度来看，这个非规范化表会更容易查询。但似乎与我读到的有关 DW 明星或雪花建模与事实等的内容相矛盾？！？

很可能我也没有掌握数据仓库的基础知识:)

解决方法

确定您需要一个数据仓库后，您需要做出的第一个决定是您将使用哪种类型的设计/数据库。有很多选项（Kimball、Inmon、Data Vault、NoSQL、Graph 等），但绝大多数数据仓库都遵循维度建模的基本 Kimball 方法论，例如事实和维度。

如果您要构建 Kimball 风格的数据仓库（或遵循任何其他方法），那么我的第一个建议是聘请有经验的人来领导这项工作。在设计 DW 时很容易犯错误，但一旦人们使用它、针对它构建了报告等，就很难纠正它们。

如果您不打算雇用知道自己在做什么的人，那么下一个最佳选择是参加课程和/或阅读有关该主题的书籍。对于 Kimball 来说，确实有两本书需要阅读：

1. The Data Warehouse Lifecycle Toolkit ：这将向您介绍所有涉及的组件以及要遵循的步骤，以提供强大的数据仓库
2. The Data Warehouse Toolkit ：这是设计维度模型的步骤

一旦您阅读并理解了这两本书，您将能够更好地理解术语并针对您不理解的方法论的任何部分（或您的具体情况）提出具体、有针对性的问题。

这绝对不是批评，但从您的问题中可以很明显地看出您（还）不具备设计和构建数据仓库的知识或经验 - 而且您不会能够通过在此（或任何其他）论坛上提问来获得经验。