问题标签 [dimensional-modeling]

关系数据库的关系和星图中表示的维度之间有什么区别？

作为任务的一部分，我有一个关系数据仓库设计，其中大多数表已使用多对多、一对一、一对多关系模式进行规范化（我认为这是正确的术语？如果我是，请纠正我错误的）。下一步是绘制一个可以在数据挖掘环境中使用的星图，我猜这意味着一个从不同维度绘制的事实表......

我在这里有点困惑，因为 1. 我能想到的任何数据分析都可以从关系数据库中获取，那么重构它的意义何在？2.如果您要从中提取数据的某些表包含外键，您如何将其拆分为维度。

例如：我有这些关系：

我想知道课程成绩与模块成绩的关系。使用关系数据库，我将查询以将包含学生信息的表与模块成绩表连接起来。维度和报告的等价物是什么？特别是当我在成绩关系中使用多个列作为我的主键时..

我正在构建一个分析应用程序，我们在其中跟踪公司营销活动的转化。转换是如果他们去超市购买产品。如果公司是 Heinz，他们可能会针对不同的产品投放广告系列，因此广告系列可能是：

• 焗豆
• 蕃茄汤
• 番茄酱

这些是在线广告系列，因此它们可以有不同的媒介，例如：

• 网站
• 脸书专页
• Flash 横幅广告
• 移动应用广告

如果有人购买产品，它是通过超市购买的，例如：

• 沃尔玛
• 阿斯达
• 西夫韦
• 克罗格

我们正在跟踪所有这些的转化。分析应用程序需要显示以上任意组合的转化数据。因此，例如，我可能需要显示转​​换...

• 烤豆。
• 来自 Facebook 页面的烤豆。
• 适用于超市沃尔玛，但适用于所有广告系列和媒体。
• 适用于从 Facebook 页面制作的沃尔玛，但适用于所有广告系列。
• 用于通过 Flash 横幅广告制作的番茄酱和用于 Safeway。

为了加快分析速度，我们避免处理原始数据（数百万条记录），而是存储每天存储的数据的聚合版本。所以对于 9 月 12 日，我可以存储我们有 12 次烘焙豆转化，6 次转化（所有产品）是通过网站进行的，沃尔玛有 8 次转化，这些可以放在 3 个单独的表中（称为广告系列，媒体和超市）。但是，如果我需要知道通过 Facebook 页面和沃尔玛进行的番茄酱的转换，那么存储在单独的表格中显然是行不通的。

我正在努力想出一个可以支持上述内容的数据模型。我正在使用标准的关系数据库（MySQL）。也许有更好的策略来处理这个问题。

我必须跟踪我的业务流程的状态以进行分析。我看到一个帖子提到我们可以根据时间/交易类型/服务中心保持交易事实表中的状态，我们可以使用累积事实表来研究流程滞后，我想知道是否很少有交易有多个状态我应该在一天内将所有状态存储在事务事实表中吗？在这里，我假设我的 ETL 在工作日结束时完成。

其次，我是否应该将我所有的关键维度键保留在事务事实表中。这种情况下的键是 Transaction Type、Department id、Service_type、Service_id、Submission Channel 还是应该将它们划分为多个事实表？

第三，如果我需要报告哪个部门正在满足其 SLA，那么最好的方法是什么，计算并跟踪事务事实表中的 SLA 范围内和非 SLA 范围内，或者我应该在运行时计算这个值？

提前感谢您的帮助和帮助。

我正在尝试确定为维度模型建模员工流动场景的最佳方法。我不确定是否最好将 Termination_Count 和 Headcount 包含在同一度量中。

我目前有一个包含 termed 和 headcount 的人数衡量标准：

因此，如果每个员工在当月处于活动状态或在当月被终止，将为他们创建一行。

其他人如何处理员工流失问题。

我正在构建一个应用程序，我将在其中存储与产品、位置和时间维度相对应的一些事实。例如，特定产品 P1 在特定月份 T1 在商店 S1 销售了 10 件。所有维度都将具有层次结构的级别 - 例如 -时间维度的年/月/周/日。每个级别的成员（不确定成员是否是正确的词）在它们之间也将具有层次结构 - 例如 - 2014/Sep/1st Week/3rd Sep，当然这个层次结构与相应级别之间的层次结构相匹配。其他维度的情况类似。通过表示分层数据的选项，实现此结构本身有点困难并且选择应该由插入/更新/删除与选择的数据的频率和数量决定。我可以做一些研究并为我的案例选择最优化的解决方案。

然而，我目前面临的真正困难是对事实数据所在的替代空间进行建模。参考我上面引用的示例，假设 P1 是层次结构Category/Subcategory/Article中的产品维度级别“Article”的成员，而 S1 是层次结构Country/City/Store中的商店维度级别“Store”的成员. 现在假设商店 S1 在 T1 月不保留商品 P1，我们使用标志 IS_ACTIVE 表示此决定。也就是说，IS_ACTIVE=N 是一个事实，它的上下文是 {P1,S1,T1}。还要注意 IS_ACTIVE 是属性，N 是它的值。然而这个上下文 {P1,S1,T1} 本身是元上下文 {Article, Store, Month} 的一个实例。而且我还需要将这个元上下文存储在应用程序中。原因是应用程序中可能有一个地方我可能需要获取与元上下文 {Article, Store, Month} 对应的其他可能属性的列表（例如，REBATE_OFFERED_PERCENT）。

我已经为这一切找到了一个规范化的关系模式设计，但它太复杂了，在我看来不会是高性能的。我正在寻找一种替代解决方案，例如 NoSQL 数据库，它可以满足我的需求，因为这里涉及到一些层次结构。或者，我的问题域是否更适合关系模式设计？

这似乎是一个应该出现在多个域中的标准问题，但我找不到任何关于此的文章。另外，抽象数学中是否有与这个问题相关的分支？是否有描述此类问题的标准术语？在实施解决方案之前，我愿意阅读一些理论。

将日期时间分为两个维度是否是最佳实践：日期和 UTC 时间，尤其是在表格模型的上下文中？谷歌没有提供太多信息。

谢谢。

在尝试使用 Talend 构建数据仓库应用程序时，我们面临以下情况。

我们有两个表格看起来像

表主

事件表

master 和 events 表之间存在一对多的关系。因为，鉴于事件名称的数量有限，我建议我们将此结构非规范化为看起来像

THEDATE_ID列引用时间维度表中的条目。

第一个问题：这是个好主意吗？该方案的其他替代方案是什么？

第二个问题：如何使用 Talend Open Studio 实现这一点？我想出了一种方法，将每个事件名称的数据与 cust_idtMap一起使用组件移动到它自己的临时表中，然后使用另一个将它们链接在一起tMap。在 talend 中还有其他方法可以做到这一点吗？

我正在就使用自由文本字段对某些数据进行建模的最佳方法提出一些建议。以下是简化的，但通常我有一个 FactIncident 表，然后是一个称为 DimPropertyType 的维度。实际上有 3 个字段定义了称为 Type1、Type2 和 Type3 的属性类型，每个字段都包含可能的 20 个值之一。最初我想做的只是让 DimPropertype 具有以下字段：

属性类型键

类型1

类型2

类型3

然而，查看每组属性类型选项的数据时，有一个名为“Other”的选项，然后还有一组称为 Type1OtherText、Type2OtherText 和 Type3OtherText 的附加字段。我查看了数据，其中每个字段中的大约 80% 已使用相应的自由文本集设置为“其他”。与业务分析师交谈时，他们进行了一些使用这些字段作为约束的搜索，因此他们需要在某个地方。

有没有人对处理这种情况的最佳方法有任何建议？查看数据，这个问题发生在许多不同的维度上，所以我将不得不多次处理这个问题。

谢谢。

我正在构建一个多维数据仓库，并学习如何从仓库中的源系统对各种业务流程进行建模。

我目前正在将数据仓库中源系统中的“投标”（工作投标）建模为包含以下信息的事实表：

• 投标金额
• 预计收入
• 销售人员
• 投标状态（有效、待定、拒绝等）
• 等等

问题是投标（或我试图建模的大多数其他过程）可以经历各种状态并在源系统中的任何给定时刻更新其信息。根据 Ralph Kimball 的说法，事实表只有在被认为是“累积快照”时才应该更新，而且我确信并非所有这些过程都会被以下定义视为“累积快照”。

根据 Kimball 小组的建议，这些类型的流程应该如何在数据仓库中建模？此外，哪种类型的事实表适用于投标（鉴于我上面概述的事实）？

摘自http://www.kimballgroup.com/2008/11/fact-tables/

交易粒度对应于在单个瞬间进行的测量。杂货店哔哔声是一种交易谷物。测量的事实仅对那个瞬间和那个事件有效。下一个测量事件可能会晚一毫秒或下个月发生，或者永远不会发生。因此，事务粒度事实表是不可预测的稀疏或密集。我们不能保证所有可能的外键都会被表示。事务粒度事实表可能非常庞大，其中最大的包含数十亿条记录。

周期性快照粒度对应于预定义的时间跨度，通常是财务报告期。图 1 显示了每月帐户定期快照。测量的事实总结了时间跨度期间或结束时的活动。定期快照粒度提供了强有力的保证，即使没有活动，所有报告实体（例如图 1 中的银行账户）都将出现在每个快照中。周期性快照是可预见的密集的，应用程序可以依赖始终存在的键组合。定期快照事实表也会变大。一家拥有 2000 万个账户和 10 年历史的银行在每月账户定期快照中将有 24 亿条记录！

累积快照事实表对应于具有明确定义的开始和结束的可预测过程。订单处理、索赔处理、服务呼叫解决和大学录取是典型的候选人。例如，用于订单处理的累积快照的粒度通常是订单上的行项目。请注意，在图 1 中，有多个日期表示订单经历的标准场景。随着流程从头到尾逐步进行，累积的快照记录会被重新访问和覆盖。由于这种覆盖策略，累积快照事实表通常比其他两种类型小得多。

我有一个事实表，它在其行中存储多个日期字段。我想保持设计的灵活性，并将所有这些字段与时间维度联系起来。然而，问题是我的报告最终在他们的查询中有太多的连接（每个日期字段一个）。我该如何缓解这个问题？

我有一个存储时间维度参考（快速搜索）和日期字段（高效检索）的想法。这样做可能会出现什么问题？

概括这个想法，我们是否应该对事实表中的其他字段也这样做？

表结构

链接到日期维度时建议的更改

但是，这会在创建捕获所有这些日期的报告时产生与日期维度表的连接过多的问题。我提出了两者的混合，我存储这些字段的日期和 ID。