问题标签 [star-schema]

我正在做一个使用 pentaho 的 BI 项目。

我的 DW 将被建模为星型模式。我知道，对于分析部分，我们需要从这个星型模式（关系 DW）开始，并将多维数据集设计为模式工作台。至此，分析工具可以做多维请求

对于报告部分，它是否也需要了解多维数据集，或者我可以在星型关系 DW 上进行正常请求吗？

这是好事还是坏事？

谢谢你的帮助

我正在使用星型模式建模构建 DW。我会将它用于 pentaho 的 BI 项目。我当然会有一个时间维度表。我将以不同的粒度（日、周、月、年，也许其他）分析我的事实表

我应该在我的维度表中为每个粒度放置一个属性（所以我有一天属性、一个月属性、一年属性......）还是应该只写日期然后用这个日期计算所有内容（获取日期的月份，日期的年份...）？

非常感谢您的帮助

我是数据仓库的新手，我有一个带有合同事实表的星型模式。它包含基本的合同信息，如开始日期、结束日期、金额……等。

我必须将这些事实与客户维度联系起来。每个合同最多有 4 个客户。所以我认为我有两个选择，或者我将 4 个客户扁平化为一排，例如：

我听到的另一个选择是在事实和客户维度之间创建一个桥接表。从而使模型复杂化。

你觉得我应该怎么做 ？每种解决方案的优点/缺点是什么，是否有更好的解决方案？

处理维度表中缺失值的最佳方法是什么？

在文本列的情况下，很容易写“NA: Missing”，但是对于保留特定值很重要的数字列应该怎么做。注意：我不想要使用带状值的解决方案（例如，“0-50”、“50-100”、“NA：缺失”的文本列）。

例如，客户维度可能有出生年份。错过出生年份应该如何处理？让它为空？添加任意数字作为占位符，例如 1900？

有时，可能很难找到占位符编号。例如，如果迄今为止的销售额为非负数，但可以为零，我不想将“0”作为 null 的占位符。我可以使用负值，例如“-1”，但这会破坏使用总和的查询。

在大数据的数据库设计中使用星型模式有什么缺点？

事实表的大尺寸是个问题吗？或者我们可以认为磁盘空间便宜，事实表的大尺寸根本不是问题？

背景：我有一个基于星型模式结构（即事实和维度表）的数据集市。

我已经掌握了确定任何维度组合（包括日期范围、界面和区域）的用户登录次数的正常计数的艺术。

问题：当我试图确定唯一登录的数量时，我遇到了困难，因为例如，任何一组天的唯一登录数不是该组中每一天的唯一登录数的总和。

我可怕的解决方案：除了将每个登录信息存储在带有时间戳和用户 ID 的表中之外，我完全没有想法。

我正在尝试使用 BI 工具对未根据工具期望的星型模式模型设计的数据库进行数据分析。有没有办法将现有的数据库或至少一部分将一些表转换为星型模式模型？

OLAP 数据库由非规范化形式的数据组成。这意味着数据冗余，这种数据冗余有助于通过更少的连接来检索数据，从而促进更快的检索。

但是 OLAP 数据库的流行设计是事实维模型。事实表将存储基于事实的数字条目（销售额等），而维度表将存储与事实相关的“描述性属性”，即进行销售的客户的详细信息。

我的问题是，在这种设计中，它似乎根本没有非规范化，因为所有维度表都具有对事实表的外键引用。它与 OLTP 设计有何不同？

我对事实表和维度表有点困惑，我无法清除我的疑问。事情是我必须设计一个模式，其中有一个关键字 table 。并且对应于每个关键字，我们有一个日期表和站点表（该关键字是为哪个站点生成的）。现在要处理这种情况，我对将哪个表分配为事实表以及将哪个表分配为维度表感到非常困惑。关键字表包含 key_id 和关键字名称。日期表包含月、年和周。站点表包含关键字所属站点的名称。请建议我这个架构的架构。

在源关系数据库中，有一个名为 CompanySurety 的表，其中 INT IDENTITY PK SuretyId 具有指向父 SuretyId 行的自引用 ExtendsSuretyId FK 列。

将这些数据引入星型模式模型，我设计了 CompanySurety 事实表（到目前为止）如下：

问题是，我如何以适当的维度方式对这种父子关系进行建模（实际上，如何在维度模型中对任何父子层次结构进行建模）？

我考虑过复制所有维度和事实列来表示父事实（因为目前，层次结构只有一层深）。但这对我来说似乎是错误的。