问题标签 [star-schema]

星型模式由维度表和事实表组成。

事实表包含每个维度的外键，除此之外，它还包含“度量”。这项措施究竟包括什么？

是存储了一些聚合函数的答案吗？

我有星型模式模型，其中服务器表包含有关服务器名称的信息。信息表包含我想要的特定服务器的信息。并且实际数据表包含有关哪个服务器包含哪些信息的信息。

现在我遇到的问题是 - 我正在尝试使用 JDBC将数据插入到数据表中。但我不确定如何在星型模式模型中将数据添加到实际数据表中。我应该每次都连接到数据库并为每个信息插入它，还是有任何直接的方法可以通过只与数据库通信一次来做到这一点。这是我获取每个服务器的所有信息的代码。IndexData 是我在 Oracle 数据库中插入值的类。

在阅读星型模式设计时，我看到许多人对不同类型的维度表使用不同的名称。

请列出每种类型的名称和简短描述。如果有任何列表还有一个别名。

我正在使用星型模式创建数据仓库。我成功地构建了所有维度表，但我有点卡在事实表上。我需要将销售表作为事实表。它有 SalesKey、OrderKey、ProductKey 等......每个订单都是一次销售，因此每个订单都有一个唯一的 SalesKey，但是每次销售将有多个产品。

最好的办法是建造这张桌子？

我应该创造这样的东西吗

星型模式的正确维度是否也具有外键和主键关系？它在概念上是否正确，请帮助我在 Dateware 实现中遇到的困惑。如果是，那么在什么情况下，不，谢谢

我正在设计一个电影租赁数据仓库

我希望事实表包含电影租赁/退货，但我很困惑。

电影可以在任何商店退还，所以我需要证明这一点。

我有这些维度：时间、客户信息、电影信息和商店

如果它们是单独的记录，我看不到我会在哪里显示它是出租还是退货？

我有什么选择来设计星型模式来显示这些信息我不知道把它放在哪里，我的头快要爆炸了。

我是数据仓库设计的初学者。我有一些理论，但最近遇到了一个 OLAP 多维数据集设计的实际问题。我使用星型模式。
假设我有 2 个维度表和 1 个事实表：

维度地名录：
维度
_id国家名称
省份名称
地区名称

维度设备：
dimension_id
device_category
device_subcategory

事实表：
gazetteer_id
device_dimension_id
hazard_id（测量列）
area_m2（测量列）

一个“业务对象”（实际上是一个雷区）可以有多个设备，位于一个位置（地名词典）并占据 X 平方米。
因此，为了了解存在哪些设备类别，我为每个处于危险中的设备创建了一个事实，如下所示：

我将度量“危害数”定义为 hazard_id 的不同计数。
我还将“占用的总面积”度量定义为 area_m2 的总和。
现在我可以使用维度地名词典和设备，并知道给定维度成员有多少危险。
但问题是 area_m2：因为它被定义为一个总和，它给出的值是实际面积的 n 倍，其中 n 是危险对象的第 th 个设备数。例如，上面的数据将给出 18000 平方米。
你将如何解决这个问题？

我正在使用 Pentaho 堆栈。

提前致谢

我需要为现有的 SQL Server 数据库构建一个数据仓库。我已经设计了星型模式维度和事实表。我的问题是：

SQL Server 2008 Enterprise 中是否有工具可以帮助我将数据从事务数据库转换到新的数据仓库数据库？我正在寻找一种工具来帮助我清理数据并填充仓库表。我以前在使用 Oracle 数据库的学术环境中做过这个。在这种情况下，我必须使用 SQL “手动”完成所有操作。

对于我正在开发的星型模式，我在决定特定维度中应该包含哪些内容以及事实表中应该包含哪些内容时遇到了一些麻烦。

例如，假设该项目正在为一家物业管理公司跟踪房屋。各种日期、承租人、合同等维度都相当简单。对于房子，无论数据位于何处，我们都希望跟踪当前所有者、当前租户、当前租赁合同，以及邻域、地址、当前租金价格、当前市场价值等信息. 请注意，所有者、租户和合同本身就是维度（邻居和地址也可能是维度，但我不太关心这些）。

许多关于房屋的数据将用于过滤查询，或用于多维数据集的行和列标题。其中一些仅作为辅助信息需要，逐个查看，而不是汇总。

鉴于数据，以及我需要用它做什么，我有（至少）三个选择：

• DimHouse：房子表是一个维度，有很多属性，在事实表中可能看起来更好，但是由于它们是用于浏览和过滤的，所以它们需要在这里。当前租户等属性将需要雪花/支腿。
• FactHouse：拥有与其他事实表连接的房屋信息的累积快照，可能使用修剪过的 DimHouse 作为桥梁。这对我来说似乎很奇怪，但它把看似事实的东西放在了事实表中。
  • 将当前所有者、当前承租人等放入相关事实表中，然后将这些事实作为所有者/承租人/等保持最新。改变（也很奇怪，但会让我们保持在星型模式的土地上）。

所以我一直在走维度路线。它让我有些心痛，但它达到了目标。我只想知道是否有更好的方法来组织数据。我不介意冗余（例如具有相似数据的事实表和维度表）或雪花，如果它们有意义并且是做事的最佳方式（对于“最佳”值）。

考虑以下形式的事实表：

Fact1在每个维度上都有一个列索引。Dim1假定为时间维度，粒度细至小时范围（例如，2011 年 3 月 12 日下午 2 点到 6 点之间）。在 Dim1中包含Dim2和Dim3覆盖列是否有用？或者同样在其中任何一个上？

更一般地说，将其他维度表 FK 列作为给定维度的索引上的覆盖列包含在内是否有用？

注意：对于事实表，我们假设不需要唯一标识给定的事实。因此，缺少主键或代理键。(Dim1, Dim2, Dim3) 始终是唯一的元组来保证唯一性。