时间戳

首页 > 解决方案 > 5NF 如何与具有 ID 列的原始表一起使用

database - 5NF 如何与具有 ID 列的原始表一起使用

问题描述

我在研究范式时遇到了一个有趣的问题，但我在任何地方都找不到答案，因为我见过的大多数示例都没有使用任何 Id 列，它们使用典型的供应商、生产者、消费者模式。假设我有一个名为 customer 的表，其架构如下：

Customer(ID: int [PK], Name: varchar(100), Address: varchar(100), Picture: varchar(100));

如果我要将这个表格形式规范化为 5NF，我认为它看起来像这样：

CustomerName(Id:int [PK], Name: varchar(100)); 

CustomerAddress(Id:int [PK], Address: varchar(100)); 

CustomerPicture(Id:int [PK], Address: varchar(100));

现在这确实满足 5NF，因为我可以将这些表加入到原始表中而不会丢失任何数据，但这真的正确吗？这对我来说似乎很愚蠢，因为如果我想要有关客户的所有信息，我将不得不编写一个具有多个连接的查询，而且连接成本高昂，性能明智。我是否正确分解了这张表？我觉得我可能错过了什么。

标签： databasedatabase-designdatabase-normalization

解决方案

您没有提到任何功能或连接依赖项，因此不可能从您的示例中得出关于 5NF 的任何结论。此外，您的伪代码建议一个表，其中除 id 之外的所有列都可以为空，但 5NF 处理只允许值而不是空值的关系。

假设您有一个关系变量 Customer，其属性为：id、name、address、picture。给定以下功能依赖性：

{id}→{姓名、地址、图片}

如果 Customer 满足的唯一连接依赖项是上述 FD 所暗示的那些，那么我们可以得出结论，id 是 Customer 的唯一候选键，并且 Customer 满足 5NF，因为它的所有 JD 都由键隐含。

我认为您建议用数字代替姓名、地址和图片，并使这些属性成为外键。如果在您进行此类更改后相同的依赖项适用于客户，那么该更改对客户是否满足 5NF 完全没有影响。规范化与数据类型（数字或字符串）无关，也不会因属性是否为外键而改变。

规范化与性能无关，但在刚才描述的情况下，没有与规范化相关的理由来创建引用外键的新表。这样做似乎会增加数据库的逻辑复杂性，因为这可能意味着需要额外的连接。另一方面，如果附加表通过让您创建名称、地址和图片而无需在客户中对应的行来消除潜在的不良插入异常，它们可能会很有用——假设这在某些给定情况下是有意义的。

推荐阅读