问题标签 [fact-table]

我有以下表格：

员工：EmployeeId

AF_AdminFile : AF_AdminFileId,EmployeeId

AF_Language : LanguageId, LanguageLevelId,AdminFileId

语言 : LanguageId(int),ID(varchar)

（例如：对于法语 LanguageId=1，ID=fr）

语言等级 : LanguageLevelId,Label

我FactTable的如下：

如果我想重新组合LanguageId并LanguageLevelId在一维中调用Dim_LanguageSkill我的查询应该如下所示：

所以Dim_LanguageSkill结构将如下所示: Dim_LanguageSkill: Dim_LanguageSkillId, LanguageId,LanguageLevelId

问题是我找不到将新维度Dim_Language加入我的事实的方法FactTable，这将有一个新的结构：

我正在为我们公司开发一个 BI 系统，从头开始，目前，我正在设计一个数据仓库。我对此完全陌生，所以有很多我不太了解的东西，所以我需要听到更多关于这方面的见解。

我的问题是：

1) 在我们的源系统中，有名为“Booking”和“BookingAccess”的表。预订表保存预订的数据，例如入住时间和退房时间、预订日期、预订编号、预订总额。

而在 BookingAccess 中，它保存与预订相关的外键，例如 bookerID、customerID、processID、hotelID、paymentproviderID 和该预订的当前状态。Booking 和 BookingAccess 具有 1:1 的关系。

我们的源系统是关于检查这些预订的有效性，这些预订不是我们的。我们从其他来源收到这些预订信息，为他们外包上述流程。总金额只是我们需要验证的预订信息，它们不是我们业务的一部分。BookingAccess 表中保留的预订的当前状态是我们系统中该预订的当前状态，可以是“处理中”或“已完成”。

根据我从 Ralph Kimball 那里读到的内容，在这种情况下，“Booking”是维度表，而 BookingAccess 应该是事实。我觉得 BookingAccess 有点像[累积快照表]，我应该在其中跟踪预订“处理”和预订“完成”的时间。

我做对了吗？

2）在“Booking”表中，还有一个外键叫做“ImportID”。此键链接到名为“导入”的表。此“导入”表保存已导入我们系统的文件的历史记录（这些文件包含将写入“预订”表的预订），包括文件名、导入日期、导入的总预订......

从我的角度来看，这显然是一个事实表。

但问题是，“导入”表和“预订”表具有一对多的关系（“导入”表中的 1 个 ImportID 可以有 1、2 个或更多记录，它们在“预订”表中具有相同的 ImportID ）。这与事实表的想法相悖，事实表坚持事实和维度之间的关系必须是多对一的，事实总是在多方面。

那么我应该使用什么方法来解决这种情况呢？我正在考虑使用桥接表来解决这个问题。但我不知道这是否是一个好习惯，因为“导入”表中有很多记录，所以我必须创建一个大的桥表来涵盖所有这些。

3）我应该将包含关系和信息混合的表（来自源系统）与仅包含关系的事实表和仅包含信息的维度表分开吗？（例如，源系统中名为“客户”的表。该表包含客户名称、客户地址和客户类型 ID、客户父 ID 等内容。）

我问这个是因为我觉得如果我使用 BI 工具来分析事物（例如，分析 customertypeid = 1 的客户数量），如果没有涉及事实表，我觉得这有些奇怪。

或者我应该把它当作一个单纯的维度表并使用雪花模式？但这会导致我们的数据仓库中混合使用星型模式和雪花模式。这是正常的吗？我已经阅读了一些官方资料（很可能是 Oracle），指出应该尽量避免使用和混合雪花模式。但微软等一些消息人士称，这是非常正常的。甚至Advanture Work Data Warehouse 示例数据库也使用这种方法。

或者我应该对“客户”表中的每个关系进行反规范化吗？但我认为这不是一个好方法，因为它会使 Customer 包含很多列，并且很难跟踪“DIM_Customer”表中每一行的历史记录。例如，如果“客户”表的任何关系发生任何变化，则需要更新整个“DIM_Customer”表。

关于数据仓库，我还有很多问题。我几乎独自一人使用它，没有任何帮助或顾问。如果我犯了任何不便或错误，请原谅我。

我正在学习商业智能课程，我必须在大约 3 年内第一次处理星型模式，所以如果可能的话，我希望你能就我所做的事情提供反馈，看看我是否可以做些什么来改进我目前的设计。

所以这个例子说我们想要跟踪一些诊所的表现，以了解他们的运营情况，比如病人等待时间、成本、收入等。该公司有一个定义明确的关系数据库，如下所示：

我的开始架构如下：

我正在为我们的销售和营销部门开发数据集市，我遇到了建模挑战。我们的 ERP 以几种不同的方式存储定价数据：

1. 列出每个项目的定价
2. 产品线的定价折扣百分比，适用于客户组或特定客户
3. 商品的自定义价格，适用于客户组或特定客户

定价部门主要使用这些数据进行操作，而不是分析。例如，他们为客户生成报告（“我有哪些特殊定价/折扣 %s？”），并确定当他们采用新的定价策略时需要更改哪些项目/项目组。

定价变化在一定程度上定期发生在小范围内，通常是在逐个客户或逐个项目的基础上进行。除了客户级别的折扣外，很少有对清单定价和团体定价（折扣和单个项目）进行大规模调整。

我一直在创建一个或多个事实表来表示这个过程。不幸的是，没有预先存在的定价业务密钥。也没有具体的“交易日期”，因为 ERP 没有（准确地）维护定价何时更改的记录。本质上，“定价事件”将是以下各项的组合：

1. 生效日期
2. 结束日期
3. 项目或产品线
4. （标价不需要）客户或客户群
5. 价格金额或折扣百分比

单个事实表似乎有问题，因为我将不得不处理大量无效的维度和事实组合。首先，一条记录永远不会同时具有非 NULL 价格金额和非 NULL 折扣百分比；定价事件是非此即彼。其次，只有特定的维度组合对每个事实有效。例如，折扣百分比只会有一个产品线，而不是单个项目。

首先将定价建模为事实表是否有意义？如果是这样，我应该考虑多少张桌子？我的直觉是至少使用两个，一个用于百分比，一个用于价格金额，但这仍然会留下一个问题，即每条记录要么有一个有效的客户组，要么有一个有效的客户（或者都没有，对于标价），因为我们需要将客户特定的定价与客户可能拥有的任何团体定价分开。

AFAIK，最佳实践说您永远不应该更新事实表行，至少对于事务和定期快照粒度。在阅读Fact Table Surrogate Key时，发现了更新的概念：

某些用于更新事实行的 ETL 技术仅在将代理键分配给事实行时才可行。具体来说，将更新加载到事实行的一种技术是将要更新的行作为新行插入，然后作为单个事务的第二步删除原始行。从 ETL 的角度来看，这种技术的优点是提高了负载性能、提高了恢复能力和提高了审计能力。事实表行的代理键是必需的，因为在插入更新行和删除旧行之间，更新的事实行的旧版本和新版本通常会存在多个相同的主键。

Bob Becker 的意思是从事实表中更新/删除吗？这是一种常见的做法吗？

我是数据仓库概念的新手，对事实表有点困惑。我正在为大学系统设计一个数据仓库，并且有一个可以填充成绩单的事实表。我在事实表中有外键链接到维度 STUDENT、COURSE、DEGREE。至于事实表的度量/度量，我使用年级和学期作为时间单位。我的问题是，应该将指标（在这种情况下为等级）手动加载到事实表中，还是应该从源数据库中的某个表（如维度）加载到事实表中？先感谢您。

编辑：对不起，如果问题有点不清楚。基本上我要问的是任何事实表，是允许从源数据库中检索的事实表的度量，还是必须手动将其输入数据仓库。

我有 3 个大学源数据库，我从中将数据加载到我的数据仓库维度表中。由于所有 3 个来源都将在同一个维度表中，我如何知道哪些行来自哪所大学？例如; 如果我想在我的事实表 (fact_transcript) 中查询一个特定大学的学生的多个学期的成绩单，我将能够使用学生唯一的社会安全号码 (ssn) 进行区分，或者我可以将大学属性添加到事实表（但我认为这是不正确的）但对于我的课程表和其他人；如果所有 3 所大学的课程编号都相同（例如 1、2、3..），我将不知道哪些课程属于哪所大学，以便我可以正确地将学生和课程加载到事实表中。对于课程维度，我会有类似的东西：

名字可以相同也可以不同，我只是选择那些来告诉你我的意思。我是否会将 ID 转换为 uni1 的 1-1000，然后 uni2 的 1001-2000 等等，或者我是否会在每个课程名称之前附加一个缩写（对于其他维度也一样），例如；UNI1-课程名称，UNI2-课程名称？感谢您的任何帮助。

我有一个 OLAP 结构化的 sql server 数据库。我的事实表是销售。

我有 2 个维度和 1 个事实表。尺寸如下：

事实表：

请注意，促销维度没有自己的唯一标识符。我相信四元素元组是~复合主键。

首先，我想创建一个名为 的主键PromotionID，将其存储在这个维度中。接下来，我想遍历销售事实表中的每个观察结果，如果观察日期在促销维度中的范围StartDate->EndDate内，我想将外键属性分配为PromotionID. 最后，我想从 FKPromotionID不是的销售事实表中选择所有观察结果NULL。

两个问题：

1. 我如何实现这种影响？
2. 上述步骤是实现这一目标的最简单方法 - 还是有更简单的方法？

我试图了解事实表相对于维度表是如何形成的。

例如销售事实表 对于按年/月/周/日的产品销售查询，我是否为每种类型的期间创建一个维度：Dim_Year、Dim_Month、Dim_Week 和 Dim_Day，每个都有自己的键？或者是否可以对所有时期只使用一个维度：Dim_Date 并且只有一个日期键？

我感到困惑的另一个领域是为什么有些事实表不包含自己的 ID？例如，Sale 事实表没有 SaleID 包含在事实表中。

销售事实表教科书示例

问题：我正在与一家提供月度服务的 SaaS 公司合作。我们正在尝试创建一个数据模型来跟踪与客户相关的指标，例如计数、注册、取消和重新激活。我在网上进行了广泛的研究，但我发现最接近的是累积具有开始/结束日期的快照，这对于客户可以重新激活帐户的 SaaS 公司来说没有意义。

我最初的想法是为客户创建一个 Factless Fact 表，但是这个无事实表也将具有事件维度表的键，即 DimSignupType、DimCancellationType、DimReactivationType 等以及 isSignup、isCancellation 和 isReactivation 的布尔度量。我认为这是违反直觉的，因为无事实的事实表不应该有事实，但我需要跟踪这些事实并感觉多个事实表更糟，因为我必须在视图中将它们连接在一起。

有没有更好的方法来解决这个问题？

根据反馈编辑：这样做的主要目标是创建一个可维护的维度模型，同时也是我为其他维度表创建的视图，允许技术较少的用户使用 Tableau 等工具发现见解。归根结底，我需要提供一个包含多个度量和维度的大型平面视图，以便于分析发现。常见的问题可能是，“与上一个 mtd 相比，我们有多少次注册此客户类型的 MTD？”，“与上个月相比，本月由于未付款而取消的次数有多少”，“有多少次因未付款而重新激活我们这个月和上个月相比有没有？”等等。很多元数据来自维度表，我会根据键加入到无事实事实表中，但是它仍然需要关注注册，出于报告目的，将取消和重新激活作为事实进行跟踪。所以我不知道遵守传统标准的最佳建模方法。它几乎看起来像一个快照事实表，其中包含描述要聚合的事件的维度表的键。我只是不知道那会叫什么。

我觉得在数据管理和易用性方面最灵活的解决方案是一个以每日快照方式建模的无事实事实表，其中包含用于注册、取消和重新激活链接到类型的“事实”。