数据库规范化第一范式混淆 - 什么时候应该分离表答案

【问题标题】：database normalization first normal form confusion - when should separating tables out数据库规范化第一范式混淆 - 什么时候应该分离表
【发布时间】：2015-04-26 10:45:57
【问题描述】：

请从学术观点而非实际工程观点考虑。这仅是关于 1NF 和 1NF。

考虑到下面的非规范化形式，主键是 {trainingDateTime,employeeNumber}，你如何使它成为第一范式？

如果我们将课程表、讲师表和员工表分开为单独的表，它将自动变为 3NF。

如果我分成不同的行，它会是这样的：

但这里的问题很明显——主键不再有效。

现在将主键更改为 {trainingDateTime, employeeNumber, employeeSkill} 似乎不是一个明智的解决方案。

【问题讨论】：

同意。这就是你需要使用 2NF 和 3NF 的地方。
为什么你希望你的表只标准化为 1NF？
这更像是一个学术演示，展示了每个范式是如何派生的。在实践中，我无法想象有人会从一个完整的非规范化形式开始。
你可以，对于一个完全不了解规范化的新手来说，他可以从一个完全非规范化的模式开始。但是随着您的练习越来越多，您的默认架构通常会标准化为 3NF

标签： database normalization

【解决方案1】：

为了使其满足 1NF，您需要为个人教学技能设置单独的行。但是您应该确保通过拆分表也满足更高的范式。因此，对于同一员工，一排应该具有高级 PHP 的教学技能，第二排是高级 Java 的教学技能，第三排是高级 SQL 的教学技能，依此类推。

【讨论】：

但是主键呢？您想将主键从 {trainingDateTime, employeeNumber} 更改为 {trainingDateTime, employeeNumber, employeeSkill}？
是的。但更好的解决方案是让您的架构与更高的范式兼容。
你是说在这个例子中，唯一的方法是直接标准化为更高的形式吗？可以一步一步来吗？
当您将表标准化为 1NF 时，您会注意到它不再满足 2NF。那是你意识到你需要标准化为 2NF 的时候。如果在这样做之后，您可以看到它不满足 3NF，则将其归一化为 3NF。这就是它的工作原理
是的，同意。它没有帮助。但是首先对表进行规范化是没有意义的。

【解决方案2】：

连同您的其他问题 database normalization - merge/combine tables 看来你正在寻找一个你没有问过的问题的答案。

关于您的评论“在实践中，我无法想象有人会从完整的非规范化形式开始。”我认为您的问题更多，为什么我们需要这些规范化规则的制定方式才能有效地进行规范化。类似的东西。我想你真正的动机/问题在这里起了作用。

规范化通常被视为一个过程或方法。这并没有什么坏处。然而，这些规范化规则的制定也允许使用清单。因此，您可以根据规范化规则仔细检查任意大小的任意表集，并确认或拒绝规范化合规性。因此，即使您可以找到数千个示例，其中任何规范化规则从第一个自然模式版本中确认规范化合规性，您也可以找到数千个其他示例，这些示例将无法在这些相同规则上进行规范化合规性。

事实上，试图将多个以某种方式耦合的信息挤入历史增长的跨多张工作表的 MS Excel 表格集合中，通常是与任何一组规范化规则发生冲突的非凡来源。（例如，呈现商业案例并将其与规划方面和资源规划联系起来）...

【讨论】：