问题标签 [data-warehouse]

我需要一个模板来记录 SSAS 多维数据集。

立方体信息

• 单一数据源
• 一个主要的事实表
• 五个直接维度
• 两个多对多维度
• 48 个分区，48 个聚合

谁能指点我为 SSAS 多维数据集设计模板？

我有一个带有常用事实和维度表的 SQL Server 2005 数据集市星型模式。这是通过基于 SSIS 的 ETL 包部署和填充的。到目前为止一切都很好。

客户刚刚向我提出了一个新要求。从来没有，我听到你说！这个要求意味着我需要在数据集市中添加一个新的维度表来衡量传入事实的新方面，这些方面恰好是财务方面的。

为了能够通过这个新维度“切片”事实，我需要在链接到新维度的事实表中添加一个新的外键列。

我不清楚最好的方法来做到这一点。我应该如何处理已经捕获的数据？只需使新列可以为空并接受旧事实将具有 NULL 吗？实际上，当我打字时，我突然意识到我也可以更新旧事实。或者也许我应该创建一个单独的（子？）事实表，它只包含一个指向每个新（父）事实的链接和一个指向新维度的链接。

我无法找到有关此类更改的最佳实践的任何信息。

任何帮助将非常感激。

顺便一提。尚未使用任何分析服务。

谢谢，马丁

我们的产品同时对大约 350 名候选人进行测试。在测试结束时，每个候选人的结果都会被转移到一个充满索引的数据仓库中。对于每个测试，有大约 400 条记录要输入到数据仓库中。所以 400 x 350 是很多记录。如果数据仓库中的记录不多，一切顺利。但是如果数据仓库中已经有很多记录，那么很多插入都会失败......

有没有办法让索引只在一天结束时重建，或者这不是真正的问题吗？或者你会如何解决这个问题？

我想开发一个通用映射来处理 PowerCenter 中的数据库错误。谁能给我这种映射的任何例子？

您还可以向我推荐一些有关 PowerCenter 示例映射的资源吗？

伙计们，

我们正在构建一个 ETL 流程，以在 64 位操作系统上使用 SQL Server 2005 SSIS 加载中型维度数据仓库。我们计划使用 SSIS 的 Checksum 包来管理 SCD（缓慢变化的维度）。

尽管我们正在使用 SSIS Checksum 包进行概念验证，但我在实际生产场景中使用它并不舒服。我听说它不适合 64 位操作系统。此外，由于它不是开箱即用的 SSIS 产品，因此安装该软件包会很麻烦。

你们怎么看？我应该使用老式的 T-SQL 校验和还是试试那个包？有没有人在大容量 ETL 过程中使用它的经验？

生成可用于 SQL Server Reporting Services 报告以显示以下内容的数据集的最直接方法是什么：

这是我正在尝试做的一个非常非常简化的示例（例如，真实场景涉及将“其他所有人”分成三个分类行），但它说明了显示每个类别的汇总数据的主要目标与其他人进行比较的个人（排他性的）。伪代码就好了。我对 SQL 代码的第一次尝试很快就变得很纠结，我知道一定有更直接的方法。

任何提示表示赞赏。

我们正在考虑建立一个数据仓库系统来加载我们的网络服务器生成的网络访问日志。这个想法是实时加载数据。

我们希望向用户展示数据的折线图，并让用户能够使用维度进行深入挖掘。

问题是如何平衡和设计系统，以便；

(1) 数据可以实时获取并呈现给用户（<2秒），

(2) 数据可以按小时和每天汇总，并且

(2) 大量数据仍然可以存储在仓库中，并且

我们当前的数据速率大约为每秒约 10 次访问，这为我们每天提供约 800k 行。我对 MySQL 和简单星型模式的简单测试表明，当我们有超过 800 万行时，我的查询开始花费超过 2 秒的时间。

是否有可能从像这样的“简单”数据仓库中获得实时查询性能，并且仍然可以存储大量数据（能够永远不会丢弃任何数据会很好）

有没有办法将数据聚合到更高分辨率的表格中？

我有一种感觉，这并不是一个真正的新问题（虽然我已经用谷歌搜索了很多）。也许有人可以给这样的数据仓库解决方案加分吗？想到的一个是Splunk。

可能是我抓得太多了。

更新

我的架构看起来像这样；

• 方面：

  • 客户端（IP 地址）
  • 服务器
  • 网址

• 事实；

  • 时间戳（以秒为单位）
  • 传输的字节数

我的自定义 Web 服务器以挂钟时间戳（会话开始）和会话持续的墙壁点击秒数的形式报告会话信息。

我想以一种允许我查询特定实体在特定时间的会话数的方式将此信息存储在数据仓库（MySQL + 启动模式）中。一个要求是我们必须能够提取将馈送到图表的时间序列数据。

除了为会话的每一秒插入一行之外，还有其他存储数据的方法吗？

这里有一点背景：

我或多或少知道什么是数据仓库。我已经阅读了几十本关于数据仓库的指南，我玩过 SSAS，我知道星型模式、维度表和事实表是什么，我知道 ETL 是什么以及如何去做。 这不是“如何”问题或教程请求。

我的问题是，我读过的所有关于数据仓库的材料似乎都掩盖了构建数据仓库的基本原理。它们都是比喻性的，或者在某些情况下是从字面上开始的“所以你决定建立一个数据仓库...... ”除了我还没有做出那个决定。

所以我希望 SO 成员可以指出或帮助提出某种半客观的测试。我可以适应特定系统并最终得到“是的，我们需要一个数据仓库”或“不，今天的回报太小”的东西。我认为我应该能够回答的具体问题是：

1. 在什么时候构建数据仓库是一个值得考虑的选择？换句话说，我应该注意哪些迹象、指标或其他标准可能表明标准事务环境不再足够？

2. 完整数据仓库的替代方案是什么？事务数据库中的非规范化和沼泽标准复制的“报告服务器”是我想到的两个；在投身 DW 之前，我还有什么需要探索的吗？

3. 为什么数据仓库比上述替代方案更好？如果答案是“取决于”，那么它取决于什么？

4. 什么时候不应该尝试构建数据仓库？无论上下文如何，我都对任何被宣布为“最佳实践”的东西持怀疑态度。当然，在某些情况下，DW 是错误的选择——它们是什么？

5. 有没有我可以看的通过引入数据仓库来改进系统的实际示例？可以端到端地向我解释，他们需要仓库进行什么样的决策或分析，他们如何决定在其中放置什么，以及仓库最终如何适应更大的环境？我不想要一个人为的“让我们从 AdventureWorks 数据库中制作一个立方体”——实现与我无关，我对所涉及的规范和设计以及整体思考过程感兴趣。

我一般尽量不问多方，但我认为这些都是密切相关的。我愿意接受至少解决前 4 个问题的任何答案，尽管最后一个问题确实有助于在我的脑海中明确这一点。如果有人已经写过这方面的链接，那么链接很好，只要它们相当简洁和具体（链接到 Ralph Kimball 的主页 = 没有帮助）。

希望我已经把问题说清楚了——提前感谢您的回答！

我的老板发现了一本提到数据仓库的新杂志。因此，我正在寻找关于数据仓库的好的教程或书籍。我也会接受关于如何阻止我的老板阅读的建议。