0

我有 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 的值，例如“胡夫金字塔和狮身人面像”可以分解为字符串，但我想这应该没问题（？）。然后我读到如果表在 1NF 中，则表在 2NF 中，并且每个非主属性都依赖于每个完整的主键。问题是我不知道如何找出哪个属性是非主属性。我读到非主属性是不能参与创建候选键的属性。但是在这里，在我的表中，我看到每个属性都可以与 ID 一起生成候选键，例如 {ID, LATITUDE} 可以生成候选键。

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

4

1 回答 1

1

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

使用自动递增列并不是使表标准化的神奇方法。如果表中的列依赖于非键列，您仍然可以拥有未通过 3NF 的表。

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

重新评论

在规范化中，“A 取决于 B”或“B 在功能上确定 A”的意思是“如果我知道 B 的给定值，那么 A 只能有一个可能的值”。符号是 B → A。

示例是 (Lat, Long) → (Country, Continent)。如果您知道坐标，那么您就可以明确地知道在哪个国家。即坐标在功能上确定了国家。

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

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

您只需要小心，因为有人可能会犯错误：输入两行具有相同的经纬度对，但不小心将其与两个不同的国家/地区相关联。

于 2013-05-17T21:41:16.027 回答