我正在开发项目，从头开始实施更小的数据集市（可能是30个表）。现在，对这个市场有深入了解的同事将要做另一个项目，让我独自一人参与这个项目（得到他的一些支持）。
我只是认为我生成了数据库图表，因此当我修改ETL并进行一些连接时我不需要任何额外的帮助。但是，令我惊讶的是，这个职业的新手......
我生成了图表，没有星型或雪花式架构，只有没有主键和外键的普通表。所以我的工作是试着想象这些表是如何相关的，如果它是真的那么请查阅它，然后重新制作我的脚本等等。烦人的。
当我问为什么会这样（没有表之间的关系）时，我得到了这个答案：“这是因为性能。”
通常像这样解决它吗？如果不是，如何解决它与关系和仍然良好的表现？
答案 0 :(得分：6)
外键是用于确保数据库中数据一致性的约束 - 它们的目的不是记录数据库的结构，而是通过控制允许对数据库进行哪些更改来强制执行数据一致性规则。
在数据完整性是关键的实时数据库中，这一切都很好，但在数据集市中，没有必要强制执行这些规则 - 我们知道数据是一致的，因为它是实时数据库的副本/提取，其中这些规则< strong> 强制执行。
外键也有一些缺点：
简而言之，它们会降低性能并且没有真正的好处，所以为什么要这么麻烦？只需确保在其他地方正确记录您的数据集市。
您可能对以下问题感兴趣：
答案 1 :(得分：0)
贾斯汀为DWH的设计提供了一个很好的答案。
您仍然可以通过检查已在这些表上设置的索引来派生表之间的关系 - 唯一索引通常会指示该表上的主键，而foriegn键通常需要非唯一（即重复索引。
此外，如果DWH是一个Kimball星型模式样式数据库，那么应该明白哪些表是维度，哪些表是事实表 - 前者通常会使用单个键字段进行有意义的描述而不使用数值度量，而后者通常会包含多个关键字段（每个维度一个）和具有很少长字符字段的数字度量（通常没有）。
在真正的星型模式中，维度表不会直接相互链接，只会链接到事实表（但是，您可能有雪花模式）。您通常应该能够根据维度表上的关键字段的名称来确定哪些维度链接到事实表上的哪些键。
然而，最重要的是：构建数据仓库时，文档不是可选步骤。询问开发人员文档的位置;如果它不存在，那么开发者应该负责提供它。