星型架构设计/最佳实践

Question

我正在使用一个有4个数据库的系统：

• 帐户（存储银行帐户，交易等）
• 客户（客户相关信息）
• 信用（从第三方系统获得费率）
• 质量（进一步内部计算）

我想创建4个事实表，每个数据库有一个事实表...例如，我将有一个Account Fact表，其中ClientAccount，Transaction，Provider作为其维度表。我将为其他数据库提供3个类似的事实表。

我的问题是：在该数据库中包含每个相应的事实表是否有意义？即在帐户数据库中创建会计事实和维度表？或者为我们所有的星型模式创建一个新数据库更好，并在自己的数据库中包含所有维度和事实表？

Answer 1

在不了解系统的情况下，我建议这些是维度表而不是事实表。 维度表表示可用于构造事实的实体或对象。账户和客户似乎非常适合这种情况。我不确定信用和质量是什么，但它们也可能是维度。

您的事实表应该代表类似交易的记录。这可能是销售，交易，电话或数据仓库报告的任何内容。然后，此事实表将具有每个维度表的外键。

关于单个或多个数据库：我建议将其存储在单个数据库中。使用这种方式更容易，在查询数据时不必担心数据库链接。用于填充这些事实和维度表的ETL过程可以从这四个数据库中提取数据并将其加载到一个数据库中，然后您可以在一个数据库中构建多维数据集。

Answer 2

除非您的数据量非常小，否则您的数据仓库应位于与交易数据不同的数据库中。 DW具有不同的使用模式（OLTP与OLAP），并且通常具有不同的维护窗口。

我建议在一个专用的DW数据库中创建所有Dims和Facts。我无法想到将它们分开的任何好处，它会因为没有额外的数据库来管理/保护/审计/文档而减少您的DBA开销。

对于Dimensions vs Facts，来自OLTP Account表的数据将用于创建Dim和Fact。 DimAccount至少是一个简并维度，只包含帐号。您必须检查您的数据，以确定是否有任何其他记录是具体的帐户的通用属性。 FactAccount将包含对其他维度的引用（DimAccountType，DimCustomer，DimLocation等）

将维度视为查找表/下拉列表中的值，这些值存在于任何事件发生之前。例如，银行可以提供“检查”和“检查”。储蓄账户，即使他们还没有任何账户。

事实记录了一个事件。创建帐户时，事实记录将引用描述事件的所有维度，并记录与事件关联的可测量值（如果有）。