数据库设计步骤与案例(by microsoft /github tutor repository)/数据库基本概念(主键/外键/主属性/码/关系/关系型/关系模式/依赖)/3NF

文章目录

• ​​数据库基础(reference links)​​

• ​​参考教材​​

• ​​关系型/关系值(与关系,笛卡尔积之间的联系)的例子​​
• ​​码/主键/外键/主属性​​
• ​​依赖​​

• ​​overview​​
• ​​依赖函数集实例​​

• ​​记号说明(notation)​​

• ​​函数依赖​​
• ​​完全依赖​​
• ​​部分依赖​​

• ​​示例​​

• ​​传递依赖​​

• ​​个人认为​​

• ​​overview for normal form​​
• ​​1NF​​

• ​​1NF 分解案例​​

• ​​2NF​​

• ​​2NF分解案例​​

• ​​3NF​​

• ​​3NF分解案例​​

数据库基础(reference links)

​​microsoft learn​​​​tutor from github repository​​

参考教材

关系型/关系值(与关系,笛卡尔积之间的联系)的例子

码/主键/外键/主属性

码与键指的是相同的东西

这两个概念基于关系(模式)的概念

• 主键：对于一个关系的多个候选键(如果有多个的话)，在实际应用时，选中使用的候选键就是主键。
• 主属性:所有候选键的属性称为主属性。

• 不包含在任何候选键中的属性称为非主属性。

• 外键：已知 X是关系R2 的主键，A是关系R1 的属性（或者属性组），但不是R1 的主键，如果A与 X相对应，则称 A是关系R1 的外键。
  *(或者说:​​​关系模式 R​​​中属性或属性组 X 并非 R 的码 ，但 X 是​​另一个关系模式R_​​的码，则称 X 是 R的外部码 (foreign key), 也称外码 )

依赖

overview

依赖是属性(或属性与主键属性集)之间的一种关系描述:

依赖函数集实例

记号说明(notation)

这里的箭头表示"决定之意":
​​​x->y​​:x决定y(y(默认函数)依赖于x)

函数依赖

对于元组t1,t2:
对于函数而言,不同的函数值y必定对应于不同的自变量x(由函数的性质可知(一对一或多对一映射都是允许的(特别是非单调函数更是这样),一对多是不允许的)(从不等的角度定义函数依赖或许更突出这些)
反之则不一定(不同的自变量中可能对应于相等的函数值,例如二次函数多对一映射是允许的)

完全依赖

部分依赖

可以理解为这是一种带有冗余的依赖(仅在主键由多列属性构成时存在的依赖类型)

示例

传递依赖

个人认为

部份依赖与完全依赖是一对相对概念(对立关系)
传递依赖确保(s->y->z)中y->z依赖是完全依赖(但是S->y仍然可能是部分依赖)
总的来说,传递依赖不排斥部分依赖(当主键是个多属性构成的属性集,且该表不满足2NF的时候经常会有依赖同时满足两者)

overview for normal form

• 数据库表的规范化是将属性划分到合适的表(避免所设计的表出现冗余等不良的设计)
• 三种范式的规定都以属性和主键之间的关系入手
• 总的来说,某个属性该不该留在某个表中的判断依据就是,该属性和主键(属性集)的依赖关系是否足够紧密
• 范式分解的时候,一般都要确定出主键

1NF

First normal form states that at every row and column intersection(交集) in the table there, exists a single value, and never a list of values.

For example, you cannot have a field named Price in which you place more than one Price. If you think of each intersection of rows and columns as a cell, each cell can hold only one value.

1NF 分解案例

做拆分处理使之满足1NF

• 学生表

• 联系方式表

2NF

Second normal form requires that each non-key column be fully dependent on the entire primary key, not on just part of the key. This rule applies when you have a primary key that consists of more than one column.

For example, suppose you have a table containing the following columns, where Order ID and Product ID form the primary key:

• Order ID (primary key)
• Product ID (primary key)
• Product Name

This design violates second normal form, because Product Name is dependent on Product ID, but not on Order ID, so it is not dependent on the entire primary key. You must remove Product Name from the table. It belongs in a different table (Products).

• 要求每个非键列完全依赖于整个主键，而不只是主键的一部分。(容许传递依赖,而不容许部分依赖)
• 当主键由多个列组成时，此规则适用。
• 例如，假设有一个表包含以下列，其中订单
  ID 和产品 ID 构成主键：
• 订单 (ID)
• 产品 ID (主密钥)
• 产品名称
• 此设计违反了2NF，因为产品名称依赖于产品 ID，但不依赖于订单 ID，因此不依赖于整个主键。 (如果某个属性依赖于整个主键,那么我们认为该属性与该表(的主键)的联系是紧密的.
• 必须从表中删除产品名称。 它(产品名)属于"产品" (表) 。
• 
  

2NF分解案例

3NF

Third normal form requires that not only every non-key column be dependent(依赖) on the entire primary key, but that non-key columns be independent(独立) of each other.

Another way of saying this is that each non-key column must be dependent on the primary key and nothing but the primary key. For example, suppose you have a table containing the following columns:

• ProductID (primary key)
• Name
• SRP
• Discount

Assume that Discount depends on the suggested retail price (SRP). This table violates third normal form because a non-key column, Discount, depends on another non-key column, SRP. Column independence means that you should be able to change any non-key column without affecting any other column. If you change a value in the SRP field, the Discount would change accordingly, thus violating that rule. In this case Discount should be moved to another table that is keyed on SRP.

• 3NF不仅要求每个非键列都依赖于整个主键，而且非键列彼此独立。(不允许传递依赖(当然,也不允许部分依赖,这是基于2NF的))
  另一种表示方式是，每个非键列都必须依赖于主键，而主键则只依赖于主键。 例如，假设有一个包含以下列的表：

• ProductID (主键)
• Name
• SRP
• Discount

• 假设折扣取决于 SRP (零售价建议suggested Retail Price ) 。 此表违反了3NF，因为非键列 Discount 依赖于另一个非键列 SRP。 列独立性意味着应该能够更改任何非键列，而不会影响任何其他列。 如果更改 SRP 字段中的值，折扣将相应地更改，从而违反该规则。 在这种情况下，折扣应移到在 SRP 上键化的另一个表。

3NF分解案例

这个例子在分解为3NF时,其中一个表保留另一个表的主键(作为外键)