问题标签 [database-normalization]

我目前在我的数据库中有多个表，它们包含相同的“基本字段”，例如：

但是我对该基本表有多个专业化，例如tv_series具有字段season, episode, airing, 而movies表具有release_date等budget。

现在起初这不是问题，但我想创建第二个表，linkgroups用这些专用表的外键调用。这意味着我必须以某种方式在其内部对其进行规范化。

我听说过解决这个问题的一种方法是使用key-value-pair-table 对其进行规范化，但我不喜欢这个想法，因为它是一种“数据库中的数据库”方案，我没有办法需要某些键/字段也不需要特殊类型，以后获取和排序数据将是一个巨大的痛苦。

所以我现在正在寻找一种在多个表之间“共享”主键甚至更好的方法：一种通过拥有一个通用表和多个专用表来规范化它的方法。

在关系数据库设计中，有一个数据库规范化或简称规范化的概念，即对列（属性）和表（关系）进行组织的过程，以减少数据冗余，提高数据完整性。（如维基百科上所写）。

由于大多数文章都有些技术性，因此更难理解，我要求有人根据关于 1NF、2NF、3NF 甚至 3.5NF（Boyce-Codd）含义的示例写一个更易于理解的解释。

是否有 3NF 或 4NF 但不在域键范式中的关系表的示例？

Is it possible to represent a composite key functional dependency of a non key column in fifth normal form?

I have three tables,

As I know, the 5th normal form needs the tables to be represented in its own small entity. So i guess the participation_type in events_users table cannot be called a 5th normal form?

Can anyone suggest me a better solution?

The problem is, I've been using the DataMapper library of CodeIgniter where each table need to exist independently, ie 5th normal form.

我需要用相关的employeeid 更新managerid 字段。

在为数据库（例如 MySQL）设计模式时，会出现是否完全规范化表的问题。

一方面连接（和外键约束等）非常慢，另一方面你会得到冗余数据和不一致的可能性。

“最后优化”是正确的方法吗？即创建一个按规范规范化的数据库，然后查看可以对哪些内容进行非规范化以实现最佳速度增益。

关于这种方法，我担心的是我会选择一个可能不够快的数据库设计——但在那个阶段重构模式（同时支持现有数据）将是非常痛苦的。这就是为什么我很想暂时忘记我学到的关于“正确”RDBMS 实践的一切，并尝试一次“平面表”方法。

该数据库将插入大量的事实是否会影响该决定？

要遵守第一范式，您必须避免的一件事是重复组。如代替：

您应该创建第二个电话号码表，然后在加入时您将获得：

有时，它有点模棱两可，很难判断一组列标题何时合格。例如，假设您目前在每个硬件上运行两个测试。您的第一个数据库设计产生了最横向的方法：

设计一

显然，这是一个重复组，可以更容易地表示为（在“Parts”和“Tests”之间的连接上）：

设计二

但是，您可以更加垂直：

设计 3

设计 3 有必要吗？你如何决定它的垂直度？设计 2 和 3 之间的优缺点是什么？似乎两者都可以使用 SQL 轻松选择或连接，具有设计 3 的优势，因为您可以轻松添加新的统计信息，而无需实际修改表结构。

但在有人说越垂直越好之前，有时它会更加模棱两可。像：

设计 4

可以改为：

设计5

虽然这两个属性都属于同一个域 (mA)，但它们代表了关于组件的非常不同的事物。在这种情况下，设计 4 是否更好，因为它不是严格意义上的重复组？我想我正在寻找一些标准来知道何时将其分解为更多表格，从而使其更加垂直。

总结一下这个长得可笑的问题，如果重复组是完全相同的域并且具有完全相同的含义，您是否应该只删除和规范化它们？. 如果是这样，那么实际上只有电话示例和设计 1 中的两个测试符合此标准。虽然看起来设计 3 和 5 可能有设计上的好处，尽管设计 3 的统计数据严格来说有不同的含义，AverageCurrent 和 BatteryCapacity 在设计 5 中肯定有不同的含义。

我一直想知道 Facebook 是如何设计朋友 <-> 用户关系的。

我认为用户表是这样的：

我用用户数据（我假设通过用户电子邮件连接的性别、年龄等）计算表格。

它如何将所有朋友与该用户联系起来？

像这样的东西？

可能不是。因为用户数量是未知的，并且会扩大。

数据库新手，所以不会对简单的问题感到不安。就我的谷歌搜索和收集的知识规范化而言，减少了数据冗余并提高了性能。但实际上，我不明白将主表划分为其他小表、应用它们之间的关系、使用所有可能的联合、子查询、连接等检索数据的确切原因，为什么我们不能拥有所有数据一个表并根据需要检索它们。我有点困惑。

有没有人知道我可以在哪里获得关于数据库表（关系）规范化的精致注释？