这是我一直在努力解决的一个思想问题。我对事实表中维度值的重复组合的概念有一种发自内心的反感。我已经阅读了很多关于当事实表中的维度组合没有形成唯一键时存在问题的信息。但是，我想了解可能出现的分析失败的确切类型。
请注意，我将事先规定，假设的丑陋事实表具有相同粒度的数据。 假设所有销售都是唯一报告的，但销售时间的最细粒度是一天。显然会有事务共享相同的维度值组合。因此，这种方法不会按照良好实践通常规定的方式汇总每天的交易。
我认为使用标准聚合的简单 DW 查询仍然是正确的。“简单”是指查询中只引用了一个事实表。在聚合/分析度量的通常形式中，我认为查询会产生正确的结果。
尝试通过组合所有维度来选择唯一的事实行会产生一种失败情况。我相信这些类型的查询实际上是未知的；我认为它们没什么用，除非用户想要真正深入到所有维度的最精细级别。我的想法正确吗？
我能看到的唯一可预测和常见的失败案例来自跨事实查询。在这里，额外的基数可能会乘以任何事实表中使用的任何度量。
对于我的学生（以及我的公司工作），我经常被问到“如果我不遵守这条规则会发生什么坏事？” 现在我担心我没有所有的答案。
预先感谢您的想法和答案。
data-warehouse database-design facttable dimensional-modeling
在我们的数据提要中，我们有一堆 XML 文件以及大量平面文件要放入 Oracle11g 数据库中。我们将 XML 扁平化为分隔文件，并使用 SQLLoader 加载整个文件集。
我想尝试通过 TABLE ORGANIZED EXTERNALLY 进行概念验证加载，但我需要向 DBA 提出一个令人信服的案例，即它不会对服务器做一些邪恶的事情。我拥有的唯一合理的测试文件是 400-600 MB，在生产中我们会添加一些数 GB 的文件。
有什么风险，我应该如何处理它们，有什么想法吗？
更新：感谢所有有用的评论，伙计们。更多的讨论产生了“我们不能给你在数据库服务器上的 shell 访问来加载文件，我们不能通过 NFS 挂载远程文件”——这些基本上是安全问题。我们处理 PII，因此 DBA 很敏感。此外，有些人担心谁提供存储。
关于为什么 1) 外部表比 sqlloader 好得多或 2) 为什么外部表的测试平台风险低的任何进一步建议的“灌篮高手”论点？
再次感谢，
安德鲁·沃尔夫