Question

我的MySQL数据库包含一个表GreatPlaces。该表有100行，其中每行代表地球上不同的历史重要位置，如北京的紫禁城或埃及的金字塔。它具有以下属性：

ID - integer, primary key
NAME - varchar, candidate key
COUNTRY - varchar, containing duplicities
CONTINENT - varchar, containing duplicies
TYPE - varchar, containing duplicities
LONGITUDE - decimal, containing duplicities (some historical sites are in the same city)
LATITUDE - decimal, containing duplicities (same as for an attribute LONGITUDE)
STORY_PATH - varchar, candidate key, an URL link to the file system
DESCRIPTION_PATH - varchar, candidate key, an URL link to the file system
PICTURES_PATH - varchar, candidate key, an URL link to the file system
VIDEO_PATH - varchar, candidate key, an URL link to the file system

我的桌子是否正常化了？要实现1NF，所有字段必须是原子的。唯一的问题可能是属性NAME的值，例如＆＃39;胡夫金字塔和狮身人面像＆＃39;可以分解为一个字符串，但我想这应该没问题（？）。然后我读到如果在1NF中表是2NF，并且每个非素数属性都依赖于每个完整的主键。问题是我不知道如何找出哪个属性是非素数属性。我读了一个非素数属性是一个不能参与创建候选键的属性。但是在这里，在我的表中我看到每个属性都可以将候选键与ID一起制作，例如{ID，LATITUDE}可以制作候选键。

所以我的问题是，如果我的假设是正确的，我表中没有任何非素数属性。然后我假设数据库应该自动在2NF和3NF。这是正确的吗？

Answer 1

{ID，LATITUDE}的示例是superkey。也就是说，它满足密钥不包含重复项的要求，但是超级密钥包含的列数多于作为候选密钥最低限度的列。换句话说：任何候选键都是超级键的子集。所以是的，你的表有非素数列。

使用自动递增列不是使表格规范化的神奇方法。如果表具有依赖于非键列的列，则仍可以使表失败3NF。

例如，您的列COUNTRY和CONTINENT依赖于LONGITUDE / LATITUDE。你不能说给定的Lat / Long有时在爱尔兰，有时在泰国，这取决于给定行的NAME值。因此，您具有非关键属性，这些属性取决于候选键之外的其他内容。

重新评论

在归一化中，“A取决于B”或“B取决于B”意味着“如果我知道B的给定值，那么A只能有一个可能的值”。符号是B→A。

示例是（Lat，Long）→（Country，Continent）。如果你知道坐标，那么你就可以清楚地知道哪个国家了.I.e。坐标在功能上确定国家。

3NF的定义是B必须是整个候选键，A必须是非键属性。在该示例中，B是（Lat，Long），A是（Country，Continent）。所以A是非关键的，没关系，但是B不是候选键，这就是打破3NF的原因。

在这个例子中，为所有可能的Lat，Long组合设置查找表并将它们映射到各自的国家可能是不切实际的。严格来说，它不符合3NF，但在这种情况下，打破3NF是一个更有效的选择。

你必须要小心，因为有人可能会犯错：输入两行相同的Lat，Long对，但不小心将它与两个不同的国家联系起来。

我的桌子是否正常化了？

1 个答案: