问题标签 [star-schema]

嗨，我正在做一个关于数据仓库的项目，但我不确定我是否正确地为我的数据仓库建模。我的数据仓库不在业务流程中，因此我找到的信息很少。

基本上我有很多库文件，每个库文件包含许多单元信息，每个单元包含许多引脚信息，每个引脚包含时序和功率信息。不同的库文件基本上包含相同数量的单元和引脚结构，只是时序/功率信息不同

库 -> 单元 -> 引脚 -> 时序/电源

我很想知道电池属性-时间/功率，以便稍后进行比较。

我是否应该在雪花模式中按仓库建模，其中我的事实表仅包含库维度和日期维度的外键。然后库维度又分为cell维度，cell维度又分为pin维度，pin维度又分为时序维度和功率维度

或者在我的事实表包含库、单元格、引脚、时间、功率和日期维度的外键的星型模式中？

我担心的是我的数据非常大，因为我有大约 200 个库文件，每个库文件包含大约 20k 单元，每个单元包含几个引脚，每个引脚包含一些时序和功率信息。因此总尺寸很大，即 200 x 20,000 x 4 x 4

每当有新版本的库文件发布时，我都会不断地输入这个庞大的数据集

可以给我建议哪个更好吗？dfdf

编辑：

层次结构如上所示。不同的库将包含相同的单元、引脚和条件，只有时序和电源模板不同。

假设我的事实粒度将是特定单元格的时间和功率值，
因此我的维度将具有库、单元格、引脚、条件、risingTimingTemplate、fallTimingTemplate、risePOwerTemplate 和 fallPowerTemplate，所有链接到事实表是否正确？

我有一个星型模式仓库（MS SQL Server，通过带有 OLAP 的 MS Report Builder 访问），它有很多微小的维度——我的意思是维度是由两列（Id 和 Description）构建的，其中有数百个从 Fact 链接表。

这提供了在没有实际计数的情况下显示所有项目的选项。非规范化表的描述是事实的一部分，因为这将提供更好的能力来通过 SQL 和 OLAP 方法查询数据。

这种包含许多一级维度的结构是否正常且良好的做法？老实说，唯一一次我希望显示空白是针对诸如时间或日期维度之类的东西，但是由于这些可以从数据中强制为您提供图表和表格中的空白，因此它似乎并没有那么重要.

关于这种结构是好是坏的任何看法——我想尝试改变它，但如果我与最佳实践脱节，我会很乐意改变我的心态。

结构示例（这只是一个事实表的一部分）

事实表 - （属性）

维度表 -

所以换个说法 - 维度真的应该是事实的单独表格，还是将描述作为事实的一部分更好？我希望报告快速而简单，并且在字段中没有值的情况下删除记录最少。

我有两个维度表和一个事实表，如下所示：

查询以获取结果：

上面查询的结果是 1,3,4

但我期待 1,2,4

我怎样才能达到预期的结果或我的概念是错误的？

我有一个维度模型，其中包含一个按日期进行范围分区的大型事实表（数百万行）和未分区的较小维度表。我遇到了物化视图，它经常在这些场景中用于提高查询性能。

现在，我想知道以下两种方式中哪种方式更好利用这些物化视图来获取聚合报告。

A. 通过将整个事实表与所需的每个维度表连接起来，创建一个。

这似乎是使用它们的最基本方式。但这似乎相当有限，我需要为我想要创建的每个查询变体创建一个新的物化视图。

B. 在事实表的聚合上创建它，并在执行维度连接时利用查询重写。

并在案例 A 中执行上述连接，这将使用此聚合的物化视图进行连接，而不是整个事实表。

谁能告诉我什么时候会使用每个案例？

我在这里遇到了以前从未遇到过的情况。

我有同一个 ERP 系统的多个实例，因卫星区域设置而异。每个语言环境都分配有自己的 ID。

在每个卫星位置内，数据库模式与其他模式、相同的表、相同的值相同。

当组合来自这些语言环境中的两个或更多的表时，比如说部分，它们的自然操作键将是相同的，但附加的属性数据可能不同。由于我需要能够链接到一个部件，基于它来自哪个卫星区域设置，我想我需要一个复合键 - 部件 ID 和卫星 ID。

现在这对于这个单一维度来说是可以的，但是，这个卫星 ID 在许多其他维度的其他地方以相同的方式使用。它也是许多事实表的主要切片器。

我应该如何对待这个属性？把它放在它自己的维度里，雪花呢？或者将值推入每个维度（重复），然后让事实表将唯一的 FK 保存到卫星维度？

我有一个与维度键结构有关的问题。我正在构建经典的 Star Schema。因此，我通过使用序列来创建维度键，以便我的维度表中的每个条目都有自己的唯一键。到目前为止，一切都很好。现在我看到了一个由 oracle Warehousebuilder 创建的项目的关键结构。该软件在维度层次结构的每个级别上除了维度键之外还定义了专用键。这看起来像以下示例：

这真的有必要吗？如果不是，这种方法的好处或思路是什么？

我是 BI 世界的新手，我有很多问题。我必须做一个 BI 家庭作业项目，所以我决定使用：

• MYSQL（数据库）
• Pentaho 水壶 (ETL)
• Pentaho 模式工作台（星型模式）
• QlikView（报告）

我有一个维度表，它是SUPERMARKET从模式工作台和 MySQL 数据库之间的连接中编辑的：

• 桌子SUPERMARKET (id_supermarket, name_supermarket, number_of_boxes, active (YES or NOT), date_of_update)
• 该SUPERMARKET表SALES通过外键直接附加到 Fact 表。

所以我的问题是如何在 SUPERMARKET 维度中建立层次结构和级别？

我所知道的是，维度表的所有成员之间都必须有时间维度之间的关系（年包含季度，季度包含月，月包含周，周包含日）。

我还有一个问题：Pentaho 工作台将星型模式导出为 XML 文件，那么如何在 Pentaho Kettle 中调用或使用此模式进行 ETL？

我正在根据客户状态在 oracle 中构建一个简单的事实表，其中客户的状态为“活动”和“丢失”，以及他们以该状态开始的日期和结束的日期。

样本 3 行将是；

在这里，cust 1 处于活动状态，然后丢失。当帐户状态为当前状态（截至今天）时，结束日期列是 31/12/9999。Cust 2 从今天开始有效

我的问题是，我怎样才能把它带入事实表？

事实表：

并对其进行测试；

我似乎无法让 oracle 识别 9999 年任何帮助表示赞赏

考虑一个众筹系统，世界上任何人都可以投资一个项目。

我有规范化的数据库设计，现在我正在尝试创建一个数据仓库（OLAP）。

我想出了以下几点：

这已被非规范化，我选择 Investment 作为事实表，因为我认为以下示例可能是有用的业务需求：

• 按项目类型查看投资
• 按时间段进行的投资，即每周进行的投资总额等。

阅读了一些资料（数据仓库工具包：Ralph Kimball）后，我觉得我的模式不太正确。这本书说要声明谷物（在我的情况下是每个Investment），然后在声明的谷物的上下文中添加事实。

我列出的一些事实似乎与实际情况不符：TotalNumberOfInvestors、TotalAmountInvestedInProject、PercentOfProjectTarget。

但我觉得这些可能很有用，因为您可以看到这些金额在投资时是多少。

这些事实看起来合适吗？最后，TotalNumberOfInvestors事实是否隐含地参考了 Investor 维度？

我一直在 Stack Overflow 和 Google 上进行一些搜索，但还没有找到我的问题的答案，所以我们开始吧：

自从我完成一个“从头开始”的数据仓库项目以来已经有一分钟了，所以我正在整理我过去的一些知识，但我正在为我的一个数据加载场景提供解决方案。

我正在创建一个事实表（factOrderLines），其中当然包含许多维度。我想链接到 factOrderLines 的维度之一是 dimItem。问题在于，根据项目的供应商和供应商部件号、制造商和制造商部件号或来自称为 ManagedItems (MngItemID) 的项目子集的标识符，项目是唯一的。

来源例如：

问题是当我从源表连接到 dimItem 表以填充 factOrderLines 表时，我有三个查找方案。这导致数字膨胀，性能变得可怕。

对于这种情况，是否有比我开始实施的更有效/更好的方法？

编辑：完整的 INSERT 查询（为了更好地理解）