fact table根本没有钥匙吗？ 要么 如果可以的话，这是一个好的设计吗？如果事实表没有任何维度，那么它在何种基础上进行分析？
如果事实表只有主键/ s且没有外键/ s？
，该怎么办？答案 0 :(得分：2)
不恰当地说，外键将您链接到将您的事实表分成类别和子类别的表。
所以如果事实表是
create table stores (id, kindOfStore, sales)
然后kindOfStore将是你的维度 - 如果就是这样，那么你可以争辩说，kindOfStore的一个单独的表是矫枉过正的（除了空间浪费说类型的商店=“食物”而不是“Kind_id = 8”）。如果您有子类别，则链接到像
这样的diminsion表是有意义的create table kindOfStore (id, Variety, Specialization, Subspecialization)
在事实表中存储Variety，Specialization和Subspecialization将是空间效率低下的空间。
生成的模式是星型模式，并且数据仓库已经过优化以处理这些模式，尽管更新更快的数据仓库引擎似乎非常快，甚至非星型模式也非常快。
与OLTP数据库相比，Datawarehouses将事实表非规范化（使用更少的表），但这绝不意味着您应该争取单个表解决方案。
答案 1 :(得分：2)
维度建模旨在允许事实上有额外的细节，描述可以“汇总”并聚合成有意义的摘要信息的属性。它是数据仓库（主要是READ环境）的一个特征，但它也可以在OLTP中占据一席之地，根据主要事实建立真实的交易数据（想想针对银行账户的交易，可能是金融交易，票据和客户墓碑修订 - 所有这些都有一个回到银行账户实体的公共链接。）
在这些细节中，优势通常是时间和地点尺寸。
如果你的事实在时间或空间上不存在，那么可以想象的是，在没有这些维度的条目的情况下存在（虽然我不能在我的生活中找出事实就是这样）。
如果进一步，其他维度很小并且包含（意味着没有其他事实共享它们），您可以将它们作为ENUM滚动到原始事实表中。
最终结果将是一个事实表，其中多个小维度表示为ENUMS。
但对于一些非常奇怪的数据来说，这将是一个非常奇怪的案例......
答案 2 :(得分：0)
在一个好的设计中，每个表都有一个主键。
使用外键取决于您尝试约束表值的方式/方式。如果您想要更具体的答案，请提供有关您情况的更具体信息
答案 3 :(得分：0)
我记得的情况是，当您使用包含用于维度列表目的的属性的表时，该工具需要设置/标记/标识表或别名作为事实表。
想象一下销售数据库，机会表包含很长的属性列表，对吧？您的客户说“我想获得所有机会名称，ID和被分配为实体所有者的人员列表”......然后您可以创建别名或同义词，或者在逻辑设计中映射相同的表格。
退化维度可能是另一种情况......所以......虽然表格是真实的事实表格，但提供的功能几乎相同，不是吗？