规范化:部分依赖&传递依赖属性冲突

Question

当我练习规范化时，我遇到了这样的问题：

将以下内容规范化

AB (a，b，c，d，e，f，g)

B-> c，e

C-> e，g

A->d

其中a，b是复合主键。

我看到它已经在1NF中了；当我试图将它规范化为2NF时，我看到e部分依赖于b；同时它是传递依赖于c，所以我感到困惑；如何继续？

什么是真实的例子，显示这个碰撞的情况？

Answer 1

我很难澄清正常的形式，但在现实世界中，它通常是这样工作的：(在这个例子中，目的是联系管理)。

1. 每个表都有一个主键字段。我叫它pk (主键)。注意:尽量避免使用多列来创建pk。为什么？因为如果列数据改变(而且它会)，您的pk必须被解构-这不是一个好主意，因为这将颠覆您的数据库！pk是每一行中数据的id (所有意图和目的)。

。

重要：大多数数据库允许为字段指定增量值。您可以在pk字段/列中这样做，这意味着每当您添加新记录(如果您愿意的话，行)时，它将向最后一个pk值添加1。大多数数据库还允许您将一个字段设置为主键(因此我将该字段命名为"pk")，这意味着数据库将不允许该列中的任何重复值，这是非常重要的。

1. 的每一列都是原子的，这意味着它不能进一步细分，例如，一个地址可以细分为:街道、城市、州和拉链，所以您不会创建这样的表：

人民

pk _。

您可以创建这样的表：(但请继续阅读)

People
--------------------
pk | first name | last name | street | city | state | zip

注意:假设你在寻找一个人的名字。那么，一旦您有了那个人，pk (id字段)允许您识别该行上的任何其他数据，以及任何相关的数据(请继续阅读)。这就是pk存在的主要原因。

1. 问自己是否有不止一个？

问:这个人是否有一个以上的名字？从法律上讲，答案是否定的，但他们可能有一个昵称！会不会有一个以上的名字？可能不是或极不可能。你想要储存尼克的名字吗？如果是，请将尼克名添加到您的表中。

People
--------------------
pk | first name | nick name | last name | street | city | state | zip

问:此人是否有一个以上的地址？是!家庭地址、工作地址、邮件地址、PO框等。这就是关系数据库管理系统(关系数据库管理系统)中关系发挥作用的地方。你需要两张桌子:一张是给人的，一张是地址的。

表1：

People
--------------------
pk | first name | nick name | last name 
10 | William    | Bill      | Smith

表2：

Addresses
--------------------
pk | fk | street               | city  | state | zip   | identifier
1  | 10 | 3110 Franklin Street | Ogden | UT    | 84041 | Home
2  | 10 | 2100 Washington blvd | Ogden | UT    | 84104 | Work

我称之为父-子关系(在SQL中，这是一对多的关系)。在这种情况下，子地址是父母的地址。一个人到多个地址。

注意:每一行都有一个唯一的pk (主键)，每个pk代表该行的数据。

fk =外键外键与People表1中的主键具有相同的值，这就是如何将地址链接到People表1中的人。

假设你意识到每个人都需要一个电话号码。

问:每个人可以有一个以上的电话号码吗？是!那么这需要另一张桌子。

现在你的数据库是这样的：

表1：

People
--------------------
pk | first name | nick name | last name 
10 | William    | Bill      | Smith

表2：

Addresses
-------------------
pk | fk | street          | city  | state | zip   | identifier
1  | 10 | 3110 Franklin   | Ogden | UT    | 84041 | Home
2  | 10 | 2100 Washington | Ogden | UT    | 84104 | Work

表3：

Phones
-------------------------
pk | fk | phone_number | identifier
1  | 10 | 801-555-1212 | Home
2  | 10 | 801-555-1213 | Work

这是数据库专业人士在现实世界中所做的事情，但我看到一些大公司多次违反这些规则。

我见过数以百计的数据库，很少遵循正常的形式或现实。所以，我会说，“是的！绝对理解DB范式，但是在现实世界中使用它们是符合现实的。它被称为关系数据(基)是有原因的。”

除此之外，有时你需要一段多到多的关系，如果有人要求的话，我很乐意给出图表。