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

Question

我在研究标准格式时遇到了一个有趣的问题，但是我找不到任何答案，因为我看到的大多数示例都没有使用任何ID列，它们使用了典型的Supplier，Producer，Consumer模式。假设我有一个名为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，因为我可以将这些表重新连接到原始表中，而不会丢失任何数据，但这实际上是对的吗？这对我来说似乎很愚蠢，因为如果我想要有关客户的所有信息，则必须编写具有多个联接的查询，并且联接是昂贵的，从性能角度考虑。我已经正确分解了这张桌子吗？我觉得我可能错过了一些东西。

Answer 1

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

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

{ID} {→姓名，地址，图片}

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

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

规范化与性能无关，但是在刚刚描述的情况下，没有与规范化相关的原因来创建引用外键的新表。这样做似乎增加了数据库的逻辑复杂性，因为这可能意味着需要额外的联接。另一方面，如果其他表允许您在客户中没有对应行的情况下创建名称，地址和图片，从而消除了潜在的不希望有的插入异常，则这些表可能会很有用。