问题标签 [star-schema-datawarehouse]

我对事实值有很大的困惑，它是通过 ETL 机制直接从 OLTP 派生到事实表中，然后我们需要执行聚合函数来通过抛出查询来总结它吗？或者它只是我们从呈现到星型模式中的维度表而不是直接从 OLTP 中获得的汇总值？

请参阅附件中的两个示例以获取更多详细信息。

在鲜明的 schema1 图像中，https: //i.stack.imgur.com/Ibbg7.png 事实表显示两个事实或度量为“dollars_sold”和“unit_sold”这是从哪里来的？& 它没有被汇总，但是通过应用聚合函数汇总日期可以获得该事实表。

在鲜明的 schema2 图像中，事实表显示一个事实或衡量为总销售额，但在这里我知道它来自 customer-trans-dia，它也是汇总数据。

那么请告诉我这两个例子中哪一个是正确的？

提前致谢。

我正在为在线业务构建星型模式。关键流程之一是电子邮件通讯注册。

但是分析取决于两个过程，我无法弄清楚如何以最佳方式对其进行建模。

以下是该过程的工作原理：

• 人访问网站
• 人员填写网络表格并在我们的 CRM 中记录为联系人
• 人收到一个链接，要求他确认这是否真的是他的电子邮件
• 人单击链接并被视为已确认
• 人现在可以接收来自我们的电子邮件

注册和确认过程发生在不同的时间。大多数人在同一天点击确认链接，但我们会在注册后的几天内发送两封后续电子邮件，因此有些人可能会在几天后确认他们的电子邮件。

最重要的是，一个人可以在网站上注册多次。我们的大多数注册用户都是交换电子邮件地址以换取某种资源（如电子书）的人。

只要此人的电子邮件未在我们的系统中标记为已确认，我们就会要求此人在每次注册时进行确认。

由于我们有多个报价，因此一个人请求电子书 A、电子书 B 和电子书 C 并仅在多次注册后才确认的情况并不少见。

在事实表中，未确认的电子邮件的每个注册都标记为 ConfirmationRequested -> True。

如果此人单击任何确认请求电子邮件的确认链接，则应将其视为已确认每个注册。

我想如何分析数据

• 看看我们有多少注册
• 查看有多少注册是重新注册，有多少是 CRM 中的新联系人（新电子邮件地址）
• 查看有多少新联系人确认了他们的电子邮件地址（并成为正式订阅者）
• 查看有多少重新注册被要求确认他们的电子邮件以及有多少人这样做了
• 分析人们确认他们的电子邮件地址需要多长时间
• 分析确认率
• 按确认状态过滤联系人并分析已确认或未确认的人的共同点

我并不真正关心与注册隔离的确认。

出于我的目的，我希望有一个 ConfirmationStatus 维度，即...

• 如果此人在注册后 7 天内确认，则为“已确认”
• 如果此人尚未确认，但自注册后尚未过去 7 天，则为“待处理”
• 如果此人在 7 天内未确认，则为“未确认”（即使此人稍后确实确认）

除此之外，我通常会在周一查看这份报告，以分析前一周并将其与其他周进行比较。（我已经在一个平面表中有这个报告的工作版本，但我正在尝试学习如何构建正确的星型模式。）

这有一个额外的挑战，例如，周日注册的联系人只有不到一天的时间来确认，并且会降低确认率，如果与所有联系人都有完整 7 天的前一周相比，最近一周看起来很糟糕。确认。

因此，我计算了所有周的“注册周内确认”确认计数和比率，以允许苹果与苹果之间的比较。

这个怎么建模...

我考虑了以下选项...

选项 #1：单独的事实表 由于这些是在不同时间发生的单独过程，我了解到我应该创建单独的事实表，然后跨公共维度进行钻取。

我可以计算从注册表中请求确认的注册，然后通过联系人和日期维度计算注册后一周内的确认。

但这不允许我按确认状态过滤注册。

这就是为什么我正在考虑...

选项 2：结合注册和确认的事实表

我在想这样的事情：

事实上，我需要 ConfirmationDate 来计算报告时的“周内确认”度量（我正在使用 powerbi，这很容易）。我当然也可以创建一个维度“ConfirmedWIthinWeek”，然后根据它进行过滤，但它不会那么灵活......如果我稍后决定每天或每月查看数据怎么办？

另一个问题是它需要在过去 7 天的每个增量负载上重新处理和更新事实表。

我知道维度可以，但事实表也可以吗？

所以我的问题是

• 选项＃2是一个好的解决方案还是有更好的方法来做到这一点？
• 可以更新事实表还是不鼓励这样做？

总的来说，我的问题是：我错过了什么？

这似乎是一件很平常的事情。一个明显的例子是一个订单星，它具有 AmountOrdered、AmountPaid、AmountRefunded 的事实表列以及“Order Status”、“Paid Status”和“Refunded Status”等维度。

但是我的搜索都没有找到这个常见问题的答案。当然必须有一个问题的术语和解决方案的模式名称，以便我可以了解更多信息？

我尝试从这里创建一个雪花模式：

我试图做到这一点，所以请帮助我开发我的雪花模式并告诉我这有什么问题以及如何使它变得更好......

上表有呼叫中心员工班次/目标详情

• 操作员ID，
• User_Name 作为操作员名称，
• Team_Id,
• 操作员所属的团队名称，
• FTE = 员工一周工作的天数。（例如：FTE = 0.8 = 6.4 小时）

每行可能会或可能不会每周更改。

我觉得这是一个缓慢变化的维度，但我也有一种奇怪的感觉，这可能是一个事实表。

我有 2 个 .BAK 文件，我想从中创建一个小型 DW，我在新数据库中构建它，包括星型模式。

我试图恢复 MSSM 中的 2 个 bak 文件，然后它创建了两个数据库。

如果我做得对，或者下一步是什么，我很困惑？

我正在尝试在星型模式模型中创建数据仓库的架构......任何想法都会受到赞赏。

知道我应该做什么来创建星型模式吗？有一天，我应该有一个与 DimProjects 的链接表去事实表。项目时间呢？什么是正确的方法或者我需要其他表来链接？员工可以从事多个项目，项目需要工时......等。

建模的最佳方法是什么？

到目前为止，我有桌子：

[代码]

[/代码]

我有一个小星型模式，表示 Jira 中问题的时间条目。我有一个 IssueAttributes 类型的 2 维表，然后是一个 TimeEntry 事实表。

维度表的简化视图：

事实表的简化视图：

当我插入事实表时，我使用的是IssueKey维度表中的当前值，这似乎是正确的方法。但是，如果我想获取时间条目的 SUM 并将它们分组IssueName，则会导致 2 行，因为名称在第一行和第二行之间发生了变化。我的印象是最好保持简单的连接并使用键，但在这种情况下，您似乎需要先连接到 Dimension 上的维度IssueKey，然后再将其连接到 and 上的IssueNumber维度IsCurrent = 1为了获取当前版本数据的属性。我这样做没有问题，但我也理解在 DW 中连接应该很简单，因此最终用户不必考虑这些连接是如何工作的，这似乎与这种理解相矛盾。我是否正确地考虑了这一点？您不应该返回并更新事实表中的 FK，对吗？我是否需要一个一致的维度或其他东西来保持某些属性随着时间的推移保持一致？

我目前的方法是将体操放在一个视图中，这样最终用户就可以引用该视图，而不必考虑所有的连接。我在想这个错误的方式吗？

从成本、时间和处理的角度来看，哪个最好使用。这里 etl_batch_date 是表的分区列。

1.Query - 此查询在运行时将处理 607.7 kb 表大小：9.77 MB

2. 查询 - 此查询在运行时将处理 427.6 kb 表大小：9.77MB

   SELECT count(*) from demo WHERE etlatchid = '20200003094244327'

另外，当您编写第二个查询时，它是否会从每个分区中读取数据？

您的宝贵意见将不胜感激。

在设计星型模式时，我很难知道何时使用桥接表。假设如果我要查找的属性在多对多关系实体中是否安全，那么我将不得不使用桥接表？

例如，如果我们要测量事实：学生总数与“年份”维度，并给出以下结构：

学生 (1–M) 注册 注册 (M-1) 课程

并且属性“年”在供品之下。

我可以直接从产品创建维度表，还是必须先使用桥接表“注册”？

我一直在为分析需求开发数据仓库。由于我是一个新学习者，我首先开始在我自己的制造相关表格的工作领域工作，并为这些表格制作报告。我一直在关注 Kimball 的设计，因此逐步添加新流程。现在，我想开始处理库存或采购交易。

我很想知道，对于一个好的数据仓库设计，推荐的流程流程是什么，例如，我应该首先处理所有其他流程的采购交易还是库存交易等等。截至目前，我想考虑将它用于制造组织。是否有任何地方记录了这种做法。

预先感谢您的帮助。