database - 主键和约束

Question

在我（当然）从 OLTP 数据库构建的全新数据仓库中，我删除了所有 IDENTITY 列并将它们更改为 INT 列。

关于以下方面的最佳实践是什么，特别是因为仓库是非规范化的：

1. 主键
   -> 这现在可能是一个复合键，因为几个表已经放在一起
   -> 我需要遵循 OLTP 的键结构吗？
   
   
2. 约束
   -> 有一些约束（非空），位列的默认值（0）
   

Answer 1

对于您的主键，请考虑使用代理键或备用键；您需要适应缓慢变化的维度，例如，如果您要报告过去 5 年中每个已婚/未婚销售人员的平均销售额，您需要记录某人未婚 2 年的事实，然后最后 3 个结婚。这意味着您的数据仓库将有两个维度表行用于同一个人。遵循 OLTP 结构将很难:)

约束不是问题。DW 已针对读取进行了大规模优化（假设您作为批处理填充），并且约束并没有真正考虑到读取操作。您通常可以绕过 DW 填充作业的任何约束问题，并在必要时在报告工具中处理空值等。更重要的是确保默认值适合您的概念数据模型，并且不要在 DW 客户端工具中引入问题。

Answer 2

对于维度表：

• 保留代理自动增量（身份）PK，日期维度除外（见下文）。
• 确保您有一个备用“自然键”以允许缓慢变化的尺寸（类型 2）。
• 维度表中不允许有空值，用详细的“n/a，未输入，未知..”替换它们
• 如果可能，将布尔标志 (1/0) 更改为详细的“是，否”，以使其对报告/业务用户友好。
• 摆脱计算字段并用值替换它们，或者至少保留计算字段 - 取决于 db.
• 如果可以，请实施星型模式，以空间换取速度。雪花只在你必须的时候。
• 检查您的查询，如果WHERE子句中有函数，请在维度表中添加一列并预先计算值。
• 如果 PK 看起来像 20090619，则很容易对日期维度进行分区。
• 摆脱检查约束和默认值，将其移至ETL 过程的一致性阶段。检查和默认设置会减慢加载速度，一旦完成加载，它们就不起作用了。

对于事实表：

• 考虑使用代理自动增量（身份）PK 以允许轻松分区，如果使用复合 PK，您可以改为使用复合唯一非集群。

• 将外键脚本放在安全的地方，在加载事实表之前删除键是一种常见的做法，以加快加载速度。有些人使用“仅逻辑”的外键运行 DW，他们在加载后使用“查找孤儿”查询。

ETL

• 通过所有阶段设计您的 ECCD (ETL) 流程：提取、清洁、符合、交付。
• 如果可能，在每个阶段之后保留中间结果（文件）以用于审计和调试目的。
• 记录 ETL，如果使用脚本，请使用版本控制，以便您可以将脚本版本与存档（中间）文件匹配。
• 有数据谱系图，Excel聊胜于无。也保留版本。

Answer 3

我会说 2.: 位列 -> 作为 bool cols 工作 -> 只允许 1/0 (true/false) -> 约束 ok