星型模式设计/最佳实践
Star Schema Design / best practice
我正在使用一个有 4 个数据库的系统：
- 账户（存储银行账户、交易等）
- 客户（客户相关信息）
- 信用（从第 3 方系统获取费率）
- 质量（进一步内部计算）
我想为每个数据库创建 4 个事实 table，一个事实 table...例如，我将有一个 Account Fact table，其中包含 ClientAccount、Transaction、提供商作为其维度 table。我将为其他数据库提供 3 个类似的事实表。
我的问题是：将每个相应的事实 table 包含在该数据库中是否有意义？即在帐户数据库中创建会计事实和维度 tables？还是为我们所有的星型模式创建一个新数据库，并将所有维度和事实 table 包含在他们自己的数据库中更好？
在不太了解系统的情况下，我建议这些是 维度 table 而不是事实 table。
维度 table 表示可用于构造事实的实体或对象。帐户和客户似乎很适合这个。我不确定信用和质量是什么，但它们也可能是维度。
您的事实 table 应该代表类似交易的记录。这可能是销售、交易、phone 电话，或者您的数据仓库正在报告的任何内容。这个事实 table 将有每个维度 table 的外键。
关于单个或多个数据库：我建议将其存储在单个数据库中。这样使用起来更容易，而且您在查询数据时不必担心数据库链接。用于填充这些事实和维度 table 的 ETL 过程可以从这四个数据库中提取数据并将其加载到一个数据库中，然后您可以从那里在单个数据库中构建多维数据集。
除非您的数据量很小，否则您的数据仓库应该与交易数据存放在一个单独的数据库中。 DW 具有不同的使用模式（OLTP 与 OLAP）并且通常会有不同的维护 window.
我建议在一个专用的 DW 数据库中创建所有的 Dims 和 Facts。我想不出将它们分开有什么好处，而且由于没有额外的数据库 manage/secure/audit/document.
，它会减少你的 DBA 开销
至于维度与事实，来自 OLTP 帐户 table 的数据将用于创建维度和事实。 DimAccount 至少是一个仅包含帐号的退化维度。您必须检查您的数据以确定是否有任何其他记录是特定帐户的通用属性。 FactAccount 将包含对其他维度（DimAccountType、DimCustomer、DimLocation 等）的引用
将维度视为查找 tables/dropdown 列表中的值，这些值在任何事件发生之前就存在。例如，银行可以提供支票和储蓄账户，即使他们还没有任何账户。
事实记录了一个事件。创建帐户时，事实记录将引用描述事件的所有维度，并记录与事件关联的可衡量值（如果有）。
我正在使用一个有 4 个数据库的系统：
- 账户（存储银行账户、交易等）
- 客户（客户相关信息）
- 信用（从第 3 方系统获取费率）
- 质量（进一步内部计算）
我想为每个数据库创建 4 个事实 table，一个事实 table...例如，我将有一个 Account Fact table，其中包含 ClientAccount、Transaction、提供商作为其维度 table。我将为其他数据库提供 3 个类似的事实表。
我的问题是：将每个相应的事实 table 包含在该数据库中是否有意义？即在帐户数据库中创建会计事实和维度 tables？还是为我们所有的星型模式创建一个新数据库，并将所有维度和事实 table 包含在他们自己的数据库中更好？
在不太了解系统的情况下，我建议这些是 维度 table 而不是事实 table。 维度 table 表示可用于构造事实的实体或对象。帐户和客户似乎很适合这个。我不确定信用和质量是什么，但它们也可能是维度。
您的事实 table 应该代表类似交易的记录。这可能是销售、交易、phone 电话，或者您的数据仓库正在报告的任何内容。这个事实 table 将有每个维度 table 的外键。
关于单个或多个数据库：我建议将其存储在单个数据库中。这样使用起来更容易，而且您在查询数据时不必担心数据库链接。用于填充这些事实和维度 table 的 ETL 过程可以从这四个数据库中提取数据并将其加载到一个数据库中，然后您可以从那里在单个数据库中构建多维数据集。
除非您的数据量很小，否则您的数据仓库应该与交易数据存放在一个单独的数据库中。 DW 具有不同的使用模式（OLTP 与 OLAP）并且通常会有不同的维护 window.
我建议在一个专用的 DW 数据库中创建所有的 Dims 和 Facts。我想不出将它们分开有什么好处，而且由于没有额外的数据库 manage/secure/audit/document.
，它会减少你的 DBA 开销至于维度与事实，来自 OLTP 帐户 table 的数据将用于创建维度和事实。 DimAccount 至少是一个仅包含帐号的退化维度。您必须检查您的数据以确定是否有任何其他记录是特定帐户的通用属性。 FactAccount 将包含对其他维度（DimAccountType、DimCustomer、DimLocation 等）的引用
将维度视为查找 tables/dropdown 列表中的值，这些值在任何事件发生之前就存在。例如，银行可以提供支票和储蓄账户，即使他们还没有任何账户。
事实记录了一个事件。创建帐户时，事实记录将引用描述事件的所有维度，并记录与事件关联的可衡量值（如果有）。