问题标签 [data-warehouse]

事实表可以完全没有键吗？或者如果可以，这是一个好的设计吗？如果事实表没有任何维度，那么分析它的依据是什么？

如果事实表只有主键而没有外键怎么办？

在任何情况下，我可以在事实表中拥有文本字段，例如描述？

我目前有一个会议事件的事实表（粒度：每次会议的行），其中包含日期、客户、位置等多个维度。我需要将会议主题放在事实表中。这可以吗，即使它不是衡量标准（我还没有看到任何这样的例子）。无法将其移动到单独的维度，因为它的大小（行数）始终与事实相同。

过去的经验有什么想法或建议吗？

谢谢

我注意到多维数据集中使用的事实表实际上是视图。事实上，它们是事实表的模板（我在脚本中注意到“where 1=2”用于事实视图）。

因此，如果使用模板，视图中不会有任何数据（而且我不知道是否可以在视图中插入，因为我在视图中没有插入权限）。

所以，我的问题是：我是否错过了立方体中的某些东西来查看？因为立方体是由一位非常有经验的开发人员设计的，而我只是一名 QA。立方体设计窗格清楚地显示它正在使用模板（如 DSV 设计器中每个矩形对象的黄色标题中所示。它是否可以引用到任何其他表/视图，而不是标题中显示的内容？

我正在创建一个包含债券和贷款等金融证券数据的 DW。这些证券与付款时间表相关联。例如，债券可以按季度支付，而抵押贷款通常按月支付（有时每两周支付一次）。付款时间表是在交易证券时创建的，并且在大多数情况下将保持不变。但是，设计需要适应那些确实发生变化的情况。

我目前正在尝试对这些数据进行建模，但很难提出可行的设计。最常查询的字段之一是“下一个付款日期”。用户通常想知道证券下次何时付款。因此，我想让他们尽可能轻松地获得每种证券的下一个付款日期和金额。

此外，用户经常运行历史查询，在这种情况下，他们希望下一个付款日期和金额为特定时间点。例如，他们可能希望回顾 1/31/09 并查询下一个付款日期（对于抵押贷款，通常是 2009 年 2 月）。他们想要查询证券的整个付款时间表也很常见，该时间表可能包含 360 条记录（30 年抵押贷款 x 12 次付款/年）。

由于下一个付款日期和金额将每月甚至每两周更改一次，因此这些字段似乎不太适合缓慢变化的维度。使用事实表可能更有意义，但我不确定如何对其建模。任何想法将不胜感激。

我有兴趣了解有关数据仓库的更多信息。我看到了诸如“维度”、“雪花模式”和“星型模式”之类的术语。从哪里开始学习这些东西？有好书或网络资源吗？

ETL 也在这个领域对吗？

我不确定“元数据管理”是正确的术语....

基本上，我有一个客户要求就他们拥有的数据仓库项目提供有关“元数据管理”工具的建议。我猜这个术语与创建数据字典之类的东西有关，但我在这方面的经验相对较少，并且从无知的角度提出问题。

我被告知（但没有亲眼目睹）客户目前正在使用 Excel 作为他们当前的“元数据管理”工具，但想要一些更强大的东西。

如果有人能对这个术语以及可能的一些开源解决方案有所了解，我将不胜感激。

我打算建议一个像 MoinMoin 这样的免费 wiki，以便他们可以创建一个术语“网络”，但我不确定这是否是正确的路径。

我在使用源事务表中的标识列或日期时间列从事务系统加载数据仓库时实现了增量检测。当下次需要提取数据时，将上次提取的最大日期时间值用于提取查询的过滤器中，以识别新的或更改的记录。这已经足够好了，除非在同一毫秒内有多个事务。

但是现在我们有了 SQL Server 2008 的变更数据捕获 (CDC)，它提供了一个名为 LSN（日志序列号）的新东西，它是长度为 10 的二进制文件。现在我很困惑。应存储哪些数据以用于窗口化，LSN 或日期时间。当然 LSN 消除了在大型事务表中存储额外日期时间值的需要，但这有什么缺点吗？我应该使用哪一个？我觉得，将 LSN 映射到日期时间然后存储日期时间不是一种可靠的方法。你有什么意见？

PS：致非商业智能专业人士，对不起。

我有一个有 17 个键的事实表。通常我一直将主键指定为我所有的维度键。MS SQL server 2008 在主键或唯一约束中限制为 16 列。有解决办法吗？

在数据仓库中，在事实表上创建聚集索引是否有缺点？（大多数时候，它将在日期时间列上）

你会回答“默认情况下......”是或否？

如果我不应该默认创建聚集索引，那为什么呢？（我知道聚集索引的优点，但有什么缺点？）

参考

http://blogs.sqlserver.org.au/blogs/greg_linwood/archive/2006/09/11/365.aspx

我在 OLTP 中有下表查找表

当这进入我的 OLAP 时，我将结构更改如下：

我的问题是关于 TransactionStateId 列。随着时间的推移，我的 OLAP 中可能有重复的 TransactionStateId 值，但是结合 StartDateTime 和 EndDateTime，它们将是唯一的。

我已经看到了 Type-2 维度的示例，其中添加了 OriginalTransactionStateId 并将传入的 TransactionStateId 映射到它，加上一个新的 TransactionStateId IDENTITY 字段成为 PK 并用于连接。

我应该选择 bachellorete #2 还是 bachellorete #3？