【问题标题】:Star Schema Design / best practice星型架构设计/最佳实践
【发布时间】:2018-03-08 09:44:58
【问题描述】:
我正在使用具有 4 个数据库的系统:
- 账户(存储银行账户、交易等)
- 客户(客户相关信息)
- 信用(从第 3 方系统获取费率)
- 质量(进一步内部计算)
我想创建 4 个事实表,每个数据库一个事实表...例如,我将有一个 Account Fact 表,其中 ClientAccount、Transaction、Provider 作为其维度表。我将为其他数据库提供 3 个类似的事实表。
我的问题是:在该数据库中包含每个相应的事实表是否有意义?即在帐户数据库中创建会计事实和维度表?还是为我们所有的星型模式创建一个新数据库,并将所有维度表和事实表包含在它们自己的数据库中更好?
【问题讨论】:
标签:
sql
sql-server
star-schema
fact-table
【解决方案1】:
在不太了解系统的情况下,我建议这些是维度表而不是事实表。
维度表表示可用于构造事实的实体或对象。帐户和客户似乎很适合这个。我不确定信用和质量是什么,但它们也可能是维度。
您的事实表应该代表类似事务的记录。这可能是销售、交易、电话或您的数据仓库报告的任何内容。然后,该事实表将具有每个维度表的外键。
关于单个或多个数据库:我建议将其存储在单个数据库中。这种方式使用起来更容易,而且在查询数据时不必担心数据库链接。您用于填充这些事实和维度表的 ETL 过程可以从这四个数据库中提取数据并将其加载到一个数据库中,然后您可以从那里在单个数据库中构建多维数据集。
【解决方案2】:
除非您的数据量非常小,否则您的数据仓库应该与事务数据分开存放在一个单独的数据库中。 DW 具有不同的使用模式(OLTP 与 OLAP),并且通常具有不同的维护窗口。
我建议在一个专用的 DW 数据库中创建所有 Dims 和 Facts。我想不出将它们分开有什么好处,而且它可以通过没有额外的数据库来管理/保护/审计/文档来减少您的 DBA 开销。
对于Dimensions vs Facts,OLTP Account 表中的数据将用于创建Dim 和Fact。 DimAccount 至少是一个只包含帐号的退化维度。您必须检查您的数据以确定是否有任何其他记录是专门针对该帐户的通用属性。 FactAccount 将包含对其他维度(DimAccountType、DimCustomer、DimLocation 等)的引用
将维度视为查找表/下拉列表中的值,这些值在任何事件发生之前就存在。例如,银行可以提供支票和储蓄账户,即使他们还没有任何账户。
事实记录事件。创建帐户后,事实记录将引用描述事件的所有维度,并记录与事件相关的可测量值(如果有)。