问题标签 [dimensional-modeling]

Star-Schema 设计对数据仓库来说是必不可少的吗？或者你能用另一种设计模式做数据仓库吗？

我正在开发一个报告系统，该系统允许用户任意查询一组事实表，并限制每个事实表的多个维度表。我编写了一个查询构建器类，它根据约束参数自动组装所有正确的连接和子查询，并且一切都按设计工作。

但是，我有一种感觉，我没有生成最有效的查询。在一组具有几百万条记录的表上，这些查询大约需要 10 秒才能运行，我希望将它们降低到不到一秒的范围内。我有一种感觉，如果我可以摆脱子查询，结果会更有效率。

我不会向您展示我的实际架构（这要复杂得多），而是向您展示一个类似的示例，该示例说明了这一点，而无需解释我的整个应用程序和数据模型。

想象一下，我有一个音乐会信息数据库，其中包含艺术家和场地。用户可以任意标记艺术家和场地。所以架构看起来像这样：

很简单。

现在假设我想查询数据库中今天一个月内发生的所有音乐会，所有带有“techno”和“长号”标签的艺术家，在带有“cheap-beer”和“great-mosh-pits”标签的音乐会上表演.

我能想出的最佳查询如下所示：

该查询有效，但我真的不喜欢拥有这些多个子查询。如果我可以完全使用 JOIN 逻辑来完成相同的逻辑，我感觉性能会大大提高。

在一个完美的世界里，我会使用一个真正的 OLAP 服务器。但是我的客户将部署到 MySQL 或 MSSQL 或 Postgres，我不能保证兼容的 OLAP 引擎将可用。所以我坚持使用带有星型模式的普通 RDBMS。

不要太在意这个例子的细节（我的真实应用程序与音乐无关，但它有多个事实表，与我在这里展示的那些有类似的关系）。在这个模型中，'artist_tag' 和 'venue_tag' 表用作事实表，而其他一切都是维度。

重要的是要注意，在这个例子中，如果我只允许用户限制单个艺术家标签或场地标签值，那么查询编写起来要简单得多。只有当我允许查询包含 AND 逻辑时，它才会变得非常棘手，需要多个不同的标签。

所以，我的问题是：您所知道的针对多个事实表编写有效查询的最佳技术是什么？

我是星型模式建模的新手，刚阅读过Data Warehouse Toolkit。

我有一个业务流程，让客户和非客户与我们的一些员工进行电话会议。

我的事实表，称之为“观众”，将包含一个参加者连接到呼叫的时间，以及这个人连接到呼叫的成本。颗粒是“单独连接到电话会议”。

我是否应该以这种方式使用符合标准的客户维度并创建非客户维度（对于尚未成为客户的调用者）（省略不属于此问题的维度）：

或者以这种方式具有与符合标准的客户维度相关的不符合标准的出席维度是否可以/更好：

或者是否有更好/标准的机制来模拟这样的业务流程？

编辑：

如果使用上面的模型 2，但是在客户维度表和参与维度之上创建一个视图以使其看起来只是一个维度，那又如何呢？

这是下面达米尔答案的可接受替代方案吗？

I have designed a fact table that stores the facts for a specific date dimension and an action type such as create, update or cancelled. The facts can be create and cancelled only once, but update many times.

This will allow me to get a count for all the updates done, all the new ones created for a period and specify a specific region through the location dimension.

Now in addition I also have 2 counts for each fact, i.e. Number of People, Number of Buildings. There is no relation between these. And I would like to query on how many of the facts having a specific count, such as how many have 10 building, how many have 9 etc.

What would be the best table design for these. Basically I see the following options, but am open to hear better solutions.

1. add the counts as reference info in the fact table as people_count and building_count

2. add a dimension for each of these that stores the valid options, i.e. people dimension that stores a key and a count and building dimension that stores a key and a count. The main fact will have a people_key and a building_key

3. add one dimension for the count these is used for both people and building counts, i.e. count dimension that stores a key and a generic count. The main fact will have a people_count_key and a building_count_key

所以我的数据仓库中有两个维度：

我要确保的是两个维度中的 machine_type 字段具有相同的数据。我应该在两者之间创建第三个维度来雪花，还是有其他选择？

我的团队正准备开始在我们的项目中使用 SQL Server 分析服务，但我们都没有丰富的经验。我们可以观看哪些好的截屏视频来帮助我们入门？

有一个项目从特定系统以 XML 文件的形式收集数据（这些以 Web 请求的形式出现），将其转换为实体模型，并将其填充到数据库中以进行报告。

该项目使用以下软件（与此问题相关）：

• C# 4.0 / .Net 4
• NHibernate 3.0（NuGet 中的最新版本）
• Fluent NHibernate（与 NH 3 一起使用的一种）

假设我有一个这样的实体（简化）：

这就是这样映射的：

（Id来自Entity基类）

由于处理此类事情的人可能已经阅读了代码，因此我正在尝试在这里进行一些维度建模。我是这个主题的新手，很可能做错了（tm），但我希望至少能从这种方式中获得一些好处；每个事件都引用一个 DateDimension 对象，如下所示：

DateDimension 表已填充 - 我的系统从未真正在此处创建任何记录。这些是在实际使用之前生成的——系统中每个相关日期都有一行。这是我系统的功能之一。它承诺每个可能的日期都会有一行。如果缺少一个，那将是一场灾难性的失败。

为什么这样做，你可能会问，如果你是维度建模的新手，就像我在两天前写这篇文章时那样。

好吧，每个日期我都会有很多事件记录。因此，DateDimension 表将比 Incident 表小很多，并且允许我使用 NHibernate LINQ 来完成原本会很困难的事情。例如这样的：

给我一个小组列表，告诉我这些事件是如何在工作日中划分的。当然，这里可以添加许多不同的维度，让我可以围绕一组不同的参数旋转报告并创建有趣的报告。

然而，有一个小烦恼，在这里我们终于到达了真正的问题。

DateDimension 有一个主键，它基本上是它以特定格式表示的日期。2011 年 4 月 30 日，它看起来像这样：

20110430

这是通过在 NHibernate 中使用自定义 IIdentifierGenerator 来完成的。由于我们每个日期只有一条记录，因此在我看来，这是一种相当干净的方法。

此外，这将是一种让新事件实体知道对其相关 DateDimension 的引用的外键的快速方法。一些工厂会知道我们从 Incident.RegisterTime DateTime 中提取此密钥，然后将其填充到 DateDimension_id 列中。

但是，这是我似乎无法找到的方法。Incident.DateDimension 理所当然地需要实体引用。这意味着我必须从数据库中加载它（对吗？）。在某些导入场景中，这可能太慢了，我需要在尽可能短的时间内将大量事件实体插入数据库。

当然，对于这个特定的示例，我可以通过在每次插入实体时执行一些自定义 SQL 来执行此操作，并允许 NULL 引用。这并不理想，但它可以工作。

但是，有没有办法直接指定 DateDimension 引用的外键，而不是使用对真实存储引用对象的引用来设置它？

那肯定会让我摆脱一个巨大的头痛！

提前感谢您的任何见解！

我正在阅读 Ralph Kimball 关于数据仓库和维度建模的书。我正在阅读其中一个案例研究，它是关于订单系统的维度建模，其中要求捕获从订单到履行再到发货的订单生命周期。

所以，我在想，也许他们会建议在一个交易维度上设置多行交易类型为 FK 的行。然而，本书建议改为创建“角色扮演”维度——创建多个日期维度表（一个用于订单日期，一个用于履行，一个用于发货）。然后，它们中的每一个都将在事实表中具有一个外键，因此事实表将具有三列来关联它。

这样的限制不是吗？每笔交易不是一个更好的选择吗？

是否有可能有一个父级并不总是有子级的属性层次结构？如果是这样，这在 SQL Server Analysis Services 中是如何实现的？

考虑以下 SQL：

在这里，我给聚合事实赋予了与细化的、未聚合的事实相同的名称。这被认为是一个好主意还是一个坏主意？

优点：聚合数据项在所有方面都保存其维度，是与详细数据项“相同类型”的数据项。

缺点：由于维度的不同，它仍然不是同一类型的数据项，在将其与其他数据项组合时应注意 - 因此最好将其称为 fact_agg 之类的来区分。