oracle中dbms
To find the highest normal form of a relation, you have to first understand the basics of Functional dependency, Candidate keys, and Normal Forms.
 要查找关系的最高范式 ，您必须首先了解功能依赖项 ，候选键和范式的基础。 
In relation, a Functional Dependency P holds Q (P->Q) if two tuples having similar values of attributes for P also have similar values of attributes for Q i.e. P distinctively decides Q.
 相对地，如果具有相似属性值P的两个元组也具有相似属性值Q，即P独特地决定Q ，则功能相关性P保持Q(P-> Q) 。 
In a Database, Functional dependency performs assistance as a restriction between two sets of attributes. 
 在数据库中，功能依赖项作为辅助功能来限制两组属性。 
A Candidate Key in a relation is a minimal set of attributes of which can be used to identify a tuple distinctively. A candidate key is a column or set of columns in a table or relation that can distinctly identify any database collection of record without indicating towards any other data. Each table may contain one or more candidate keys, but one candidate key is distinct in each table or relation, and it is called the primary key. The primary key is the best among the candidate keys which is usually used for identification.
 关系中的候选关键字是属性的最小集合，可用于区别性地标识元组。 候选键是表或关系中的一列或一组列，它们可以清楚地标识记录的任何数据库集合，而无需指示其他任何数据。 每个表可以包含一个或多个候选键，但是一个候选键在每个表或关系中都不同，因此称为主键。 主密钥是通常用于标识的候选密钥中最好的。 
The process of Normalization is to minimize redundancy from a database table or relation or a set of relations. Insertion, Deletion and Updation anomalies may cause by redundancy. So, it aids to reduce the redundancy in relations.
 规范化的过程是最小化数据库表或关系或一组关系的冗余。 插入，删除和更新异常可能是由冗余引起的。 因此，它有助于减少关系中的冗余。 
Normal forms are used to eliminate or minimize redundancy in database tables or relations. These Normal Forms are:
 范式用于消除或最小化数据库表或关系中的冗余。 这些范式为： 
First Normal Form
 第一范式 
Second Normal Form
 第二范式 
Third Normal Form
 第三范式 
Boyce-Codd Normal Form (BCNF)
 博伊斯·科德范式(BCNF) 
Steps to follow to find the highest normal form of a relation
 查找关系的最高范式的步骤 
The first step is to find all feasible candidate keys of the relation and its attributes.
 第一步是找到该关系及其属性的所有可行候选键。 

The second step is to organize into two categories all the attributes of the relation:
 第二步是将关系的所有属性分为两类： 
Prime attributes
Non-prime attributes
Third and the last step is to examine to determine for 1st normal form and then 2nd and so on. If the process is unsuccessful in satisfying nth normal form condition, then the highest normal form will be n-1.
 第三步也是最后一步是检查确定第一个范式，然后确定第二个，依此类推。 如果该过程不能满足第n个范式条件，则最高范式将为n-1。 
 例子 (Examples)
Problem 1) Find the highest normal form of a relation R(P, Q, R, S, T) with Functional dependency set as (QR->S, PR->QT, Q->T).
 问题1)找到功能依赖项设置为(QR-> S，PR-> QT，Q-> T)的关系R(P，Q，R，S，T)的最高范式。 
Solution:
 解： 
Step 1:
 第1步： 
As the relation (PR)+ = (P, Q, R, S, T) is given, but not a single of its subset can determine all attributes of relation, So PR will be candidate key. P or R can’t be derived from any other attribute of the relation, so there will be only one candidate key (PR).
 由于给出了关系(PR)+ =(P，Q，R，S，T)，但没有一个子集可以确定关系的所有属性，因此PR将成为候选关键字。 P或R不能从关系的任何其他属性派生，因此将只有一个候选键(PR)。 
Step 2:
 第2步： 
The attributes which are part of candidate key (P, R) are Prime attributes. 
 属于候选键(P，R)的属性是素数属性。 
The others will be non-prime attributes (Q, R, S).
 其他将是非素数属性(Q，R，S)。 
Step 3:
 第三步： 
A Relational Database Management System does not enable multi-valued or composite attribute. So, the relation R(P, Q, R, S, T) is in 1st normal form.
 关系数据库管理系统不启用多值或复合属性。 因此，关系R(P，Q，R，S，T)为第一范式。 
Because QR->S is in 2nd normal form (QR is not a proper subset of candidate key PR) and PR->QT is in 2nd normal form (PR is candidate key) and Q->T is in 2nd normal form (Q is not a proper subset of candidate key PR).So, the relation is in 2nd normal form.
 因为QR-> S为第二范式(QR不是候选关键字PR的适当子集)，而PR-> QT为第二范式(PR为候选关键字)，而Q-> T为第二范式(Q不是候选密钥PR的适当子集)。因此，该关系为第二范式。 
Because in QR->S (neither QR is a super key nor S is a prime attribute) and in Q->T (neither Q is a super key nor T is a prime attribute) but to satisfy 3rd normal form, either LHS of a Functional Dependency should be super key or RHS should be prime attribute. So, the relation is not in 3rd normal form.
 因为在QR-> S中(QR既不是超键也不是S是素数属性)，而在Q-> T中(Q既不是超键也不是T是素数属性)但是要满足第三范式，所以LHS功能依赖关系应该是超级键，RHS应该是主要属性。 因此，该关系不是第三范式。 
So, the highest normal form of relation will be 2nd Normal form.
 因此，关系的最高范式将是第二范式。 
Problem 2) Find the highest normal form of a relation R (P, Q, R, S, T) with Functional Dependency set (Q->P, P->R, QR->S, PR->QT).
 问题2)找到具有功能相关性集(Q-> P，P-> R，QR-> S，PR-> QT)的关系R(P，Q，R，S，T)的最高范式。 
Solution:
 解： 
Step 1:
 第1步： 
As the relation (PR) + = (P, Q, R, S, T) is given, Q will be a candidate key. Q can be derived from PR using PR->Q (Decomposing PR->QT to PR->Q and PR->T). So PR will be super key but (R) + ={R} and (P) + = {P, R, Q, S, T}. So P (subset of PR) will be a candidate key. 
 由于关系(PR)+ =(P，Q，R，S，T)，Q将成为候选关键字。 可以使用PR-> Q(将PR-> QT分解为PR-> Q和PR-> T)从PR导出Q。 因此PR将是超级键，但(R)+ = {R}和(P)+ = {P，R，Q，S，T}。 因此，P(PR的子集)将成为候选关键字。 
So there will be two candidate keys {P, Q}.
 因此将有两个候选键{P，Q}。 
Step 2:
 第2步： 
The attributes which are part of candidate key (P, Q) are Prime attributes. 
 属于候选键(P，Q)的属性是素数属性。 
The others will be non-prime attributes (R, S, T).
 其他将是非素数属性(R，S，T)。 
Step 3:
 第三步： 
A Relational Database Management System does not enable multi-valued or composite attribute. So, the relation R (P, Q, R, S, T) is in 1st normal form.
 关系数据库管理系统不启用多值或复合属性。 因此，关系R(P，Q，R，S，T)处于第一范式。 
The relation is in 2nd normal form because Q->P is in 2nd normal form (Q is a super key) and P->R is in 2nd normal form (P is super key) and QR->S is in 2nd normal form (QR is a super key) and PR->QT is in 2nd normal form (PR is a super key).
 该关系为第二范式，因为Q-> P为第二范式(Q为超级键)，而P-> R为第二范式(P为超级键)，而QR-> S为第二范式。 (QR是超级键)，PR-> QT为第二范式(PR是超级键)。 
Because LHS of all Functional Dependencies are super keys, the relation is in 3rd normal form.
 因为所有功能依赖项的LHS都是超键，所以该关系为第三范式。 
The relation is in BCNF as all LHS of all Functional Dependencies are super keys. 
 该关系在BCNF中，因为所有功能依赖项的所有LHS都是超级键。 
So, the highest normal form is BCNF. 
 因此，最高范式是BCNF。 
Problem 3) Find the highest normal form of a relation R (P, Q, R, S, T) with Functional Dependency set (P->S, Q->P, QR->S, PR->QT).
 问题3)找到具有功能相关性集(P-> S，Q-> P，QR-> S，PR-> QT)的关系R(P，Q，R，S，T)的最高范式。 
Solution:
 解： 
Step 1: 
 第1步： 
As the relation (PR) + = (P, Q, R, S, T) is given, but not a single of its subset can determine all attributes of relation, so PR will be candidate key. P can be derived from Q, so we can replace P in PR by Q. So QR will also be a candidate key. 
 由于给出了关系(PR)+ =(P，Q，R，S，T)，但是没有一个子集可以确定关系的所有属性，因此PR将成为候选关键字。 P可以从Q派生，所以我们可以用Q代替PR中的P。因此QR也是候选关键字。 
So the two candidate keys will be (PR, QR).
 因此，两个候选键将是(PR，QR)。 
Step 2: 
 第2步： 
The attributes which are part of candidate key (P, Q, R) are Prime attributes.
 属于候选键(P，Q，R)的属性是素数属性。 
The others will be non-prime attributes (S, T).
 其他将是非素数属性(S，T)。 
Step 3: 
 第三步： 
A Relational Database Management System does not enable multi-valued or composite attribute. So, the relation R (P, Q, R, S, T) is in 1st normal form.
 关系数据库管理系统不启用多值或复合属性。 因此，关系R(P，Q，R，S，T)处于第一范式。 
Because P->S is partial dependency (P which is a subset of candidate key PR is determining non-prime attribute S), the relation is not in 2nd Normal form because the 2nd normal form does not enable partial dependency.
 因为P-> S是部分依赖关系(作为候选键PR的子集的P正在确定非主要属性S)，所以该关系不是第二范式，因为第二范式不允许部分依赖。 
So, the highest normal form will be 1st Normal Form.

 因此，最高范式将是第一范式。 
翻译自: https://www.includehelp.com/dbms/how-to-find-the-highest-normal-form-of-a-relation.aspx
oracle中dbms

文章目录
求关系模式最高达到第几范式的步骤
通俗理解1NF,2NF,3NF.
如何求关系模式的候选码
如何求闭包
函数依赖

求关系模式最高达到第几范式的步骤

根据给定的U和F,首先求它的候选码
根据候选码判断关系F中的函数关系是否满足第二范式,若不满足则为关系模式的规范化最高为第一范式
然后判断是否存在非主属性传递依赖,如果存在则不满足第二范式,如果不存在则关系模式的规范化最高为第三范式.

通俗理解1NF,2NF,3NF.


1NF的定义:
 一个关系模式R的所有属性都是不可分的基本数据项.

1NF容易理解就不多解释了,在这里举两道简单的题帮助理解.

规范化的关系模式中，所有属性都必须是( C)。

A.相互关联的

B.互不关联的

C.不可分解的

D长度可变的
关系数据库中的每个关系必须最低到达__第一范式__,且该范式中的每个属性都是__不可再分__的。



2NF的定义:
 在1NF的基础上,关系中每一个非主属性完全函数依赖于码. 
 所以满足第二范式则一定满足第一范式.
 对这个非主属性完全函数依赖于码不清楚可以看最后**函数依赖中的图**来理解.



3NF的定义:
 在满足2NF的基础上,满足每个非主属性既不部分依赖于码也不传递依赖于码.
满足3NF的同时一定满足2NF.



如何求关系模式的候选码

首先对于给定的R(U)和函数依赖集F,可以将它的属性化分为4类:
L类:仅出现在F的函数依赖左部的属性.
R类:仅出现在F的函数依赖右部的属性.
N类:在F的函数依赖左部和右部未出现的属性.
LR类:在F的函数依赖左部和右部均出现那的属性.

下图的题中:A->C

C->A

B->AC

D->AC

L:找出这些式子中只在箭头左边的

R:找出式子在只出现在箭头右边的

N:找出所有的R中既没有出现箭头在左边又没有出现在箭头右边的

LR:找出既出现在箭头左边又出现在箭头右边的

如下图所示.
那么求出这些L,R,N,LR类后我们根据三个定理来确定候选码的成员:

定理1:对于给定的关系模式R以及其函数依赖集F,若X(x∈R)是L类,则X必为R的任一候选码的成员.
定理2:对于给定的关系模式R以及其函数依赖集F,若X(x∈R)是R类,则X不在任何候选码中.
定理3:设有关系模式R以及函数依赖集F,如果X是R的N类属性,则X必包含在R的任一候选码中.
推论2:如果X是R的N类和L类组成的属性集,且X+包含了所有的属性,则X是R的唯一候选码.

简单的来说就是对于在 L和N类中的都是候选码的成员:



确定了候选码的成员后如何确定最后的候选码呢?我们看到上面有这个B+或者(BD)+这在求B的闭包,下面我们来了解以下如何求闭包吧.
如何求闭包
闭包就是由一个属性直接或间接推导出所有属性的集合.引用: http://blog.sina.com.cn/s/blog_7f6c91720101jkhm.html.了解了闭包的概念后我们要学会如何求闭包,

步骤如下:





当我们求出所由候选码成员的闭包后,我们根据上面的推论2,

推论2:如果X是R的N类和L类组成的属性集,且X+包含了所有的属性,则X是R的唯一候选码.

假设上图中BC为候选码的成员,求到的(BC)+的闭包为ABCE;

而U={A,B,C,D,E},并没有全部包含所有属性,所以它不是关系模式R的码.

F={A->E,AC->B,B->A,D->A,D->C}

下面我来求一下D的闭包(D)f+

根据D->A,D->c将A,C 目前(D)+=ACD;

(ACD)={A,C,D,AD,AC,CD}

A->E   AC->B   变成(D)f+=(ABCDE)
(D)f+包含了R中的所有属性,所以D为R的码.
函数依赖
求出码后我们就根据2NF,3NF中的函数依赖来判断关系模式的规范化最高为?

1.这个中AB为候选码,但是存在非主属性依赖于B,不满足所有非主属性完全依赖于码.
2.再看一道题



最后总结两个常考的知识点

在一个关系R中，若X→Y，并且X的任何真子集都不能函数决定Y，则称X→Y为___完全___函数依赖
若X→Y，并且X的一个真子集也能够函数决定Y，则称X→Y为___部分___函数依赖。
一个关系模式R中的候选码可能有多个.

一般的数据库设计都需要满足三范式，这是最基本的要求的，最高达到6NF，但是一般情况下3NF达到了就可以。

一：1NF一范式的理解：

        1NF是关系型数据库中的最基本要求，就是要求记录的属性是原子性，不可分，就是属性不能分，这是关系型数据库的基本要求，不满足这个就不能叫关系型数据库了

例如：

讲师      性别      班级    教室  代课时间   代课时间（开始，结束）

韩忠康  Male  php0331  102      30天      2013-03-31,2013-05-05

韩忠康  Male  php0228  106      30天      2013-02-28,2013-03-30

韩顺平  male  Php0228  106     15天      2013-03-31,2013-05-05

上面的代课时间字段设计就不满足原子性，因为它可以再分的，开始时间和结束时间，需要按照下面来设计拆分：

讲师      性别      班级    教室  代课时间        开始             结束

韩忠康  Male  php0331  102      30天      2013-03-31   2013-05-05

韩忠康  Male  php0228  106      30天      2013-02-28   2013-03-30

韩顺平  male  Php0228  106     15天       2013-03-31    2013-05-05

二：2NF二范式的理解

        2NF是不能有部分依赖，部分依赖的前提条件是有组合主键，就是每条记录是需要一个主键的，这个主键可以是一个单独的属性，但也可以是组合主键，就是由记录的多个属性来唯一确定一条记录，那么只要出现了组合主键就可以产生部分依赖，部分依赖是组合主键出现的前提下，剩余的属性，不完全依赖于组合主键，也是部分依赖组合主键，比如该表的N条记录中由组合主键中的一条或者几条就可以确定剩余属性的属性，那么就可以说产生部分依赖，而在实际开发中，一般不采用组合主键，而是自己增加一个字段id自增长，作为主键，这样的单属性主键是不会产生部分依赖的！

例如：

讲师      性别      班级    教室  代课时间        开始             结束

韩忠康  Male  php0331  102      30天      2013-03-31   2013-05-05

韩忠康  Male  php0228  106      30天      2013-02-28   2013-03-30

韩顺平  male  Php0228  106     15天       2013-03-31    2013-05-05

上面的设计可以用讲师，班级，两个字段作为组合主键，但是问题来了，那么后面的教室仅仅由班级字段(组合主键中的一条)就可以确定，即所谓教室部分依赖于组合主键，那么就不符合2NF。

应该按照下面就行设计：增加逻辑主键或拆分表

IDP   讲师   性别   班级   教室  代课时间 开始          结束

1     韩忠康 Male php0331 102 30天 2013-03-31 2013-05-05

2     韩忠康 Male php0228 106 30天 2013-02-28 2013-03-30

可以看到仅仅增加一个主键IDP就不存在部分依赖了，这是实际项目中开发中常用的手段！

三：3NF的理解

        不能出现传递依赖：就是主键，非主键1，非主键2三者之间不能出现传递依赖关系，如果出现由主键可以推出非主键1,然后由非主键1可以推出非主键2，那么主键与非主键2就产生了传递依赖关系，这就不满足三范式，通俗来讲，在一个表的，当然以一条记录为单位，主键和非主键之间可以产生父子关系，但是非主键之间是不能出现父子关系的！

        很多时候，我们为了满足第三范式往往会把一张表分成多张表。

四：反三范式

        没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，提高读性能，就必须降低范式标准，适当保留冗余数据。具体做法是： 在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，减少了查询时的关联，提高查询效率，因为在数据库的操作中查询的比例要远远大于DML的比例。但是反范式化一定要适度，并且在原本已满足三范式的基础上再做调整的。

        空间与时间的对抗

 

范式化设计优缺点

优点：

  可以尽量得减少数据冗余
	
  范式化的更新操作比反范式化更快
	
  范式化的表通常比反范式化的表更小
缺点：

   对于查询需要对多个表进行关联
	
   更难进行索引优化
反范式化设计优缺点

优点：

可以减少表的关联
	
可以更好的进行索引优化
缺点：

存在数据冗余及数据维护异常
	
对数据的修改需要更多的成本
 

 

参考：https://www.jianshu.com/p/588d09f85796

一般的数据库设计都需要满足三范式，这是最基本的要求的，最高达到6NF，但是一般情况下3NF达到了就可以
一：1NF一范式的理解：
1NF是关系型数据库中的最基本要求，就是要求记录的属性是原子性，不可分，就是属性不能分，这是关系型数据库的基本要求，不满足这个就不能叫关系型数据库了
例如：
讲师 性别 班级 教室 代课时间 代课时间(开始，结束)
韩忠康Malephp033110230天2013-03-31,2013-05-05
韩忠康Malephp022810630天2013-02-28,2013-03-30
韩顺平malePhp022810615天2013-03-31,2013-05-05
上面的代课时间字段设计就不满足原子性，因为它可以再分的，开始时间和结束时间，需要按照下面来设计拆分：
讲师 性别 班级 教室 代课时间 开始 结束
韩忠康Malephp033110230天2013-03-312013-05-05
韩忠康Malephp022810630天2013-02-282013-03-30
韩顺平malePhp022810615天2013-03-312013-04-20
上面的就满足了，但是有些时候也需要去违背这个1NF的设计：在用dede设计cms的时候后台的下载地址是将格式，名称，分辨率这些进行评级在一个属性里面，但是可以看作一个整体，因为这个属性即使分开，那么各个成员的关系不是平等的，但是代课时间是不一样的，比如分为开始时间和结束时间，两个成员的关系基本一样！所以也不矛盾！
二：2NF二范式的理解
2NF是不能有部分依赖，部分依赖的前提条件是有组合主键，就是每条记录是需要一个主键的，这个主键可以是一个单独的属性，但也可以是组合主键，就是由记录的多个属性来唯一确定一条记录，那么只要出现了组合主键就可以产生部分依赖，部分依赖是组合主键出现的前提下，剩余的属性，不完全依赖于组合主键，也是部分依赖组合主键，比如该表的N条记录中由组合主键中的一条或者几条就可以确定剩余属性的属性，那么就可以说产生部分依赖，而在实际开发中，一般不采用组合主键，而是自己增加一个字段id自增长，作为主键，这样的单属性主键是不会产生部分依赖的！
例如：
讲师P 性别 班级P         教室 代课时间 开始 结束
韩忠康Malephp033110230天2013-03-312013-05-05
韩忠康Malephp022810630天2013-02-282013-03-30
韩顺平malePhp022810615天2013-03-312013-04-20
上面的设计可以用讲师P，班级，两个字段作为组合主键，但是问题来了，那么后面的教室仅仅由班级字段(组合主键中的一条)就可以确定，即所谓教室部分依赖于组合主键，那么就不符合2NF
应该按照下面就行设计：
IDP 讲师 性别 班级 教室 代课时间 开始 结束
1韩忠康Malephp033110230天2013-03-312013-05-05
2韩忠康Malephp022810630天2013-02-282013-03-30
可以看到仅仅增加一个主键IDP就不存在部分依赖了，这是实际项目中开发中常用的手段！
三：3NF的理解：不能出现传递依赖：就是主键，非主键1，非主键2三者之间不能出现传递依赖关系，如果出现由主键可以推出非主键1,然后由非主键1可以推出非主键2，那么主键与非主键2就产生了传递依赖关系，这就不满足三范式，通俗来讲，在一个表的，当然以一条记录为单位，主键和非主键之间可以产生父子关系，但是非主键之间是不能出现父子关系的！
例如：
IDP 讲师 性别 班级 教室 代课时间 开始 结束
1韩忠康Malephp033110230天2013-03-312013-05-05
2韩忠康Malephp022810630天2013-02-282013-03-30
3韩顺平malephp022810615天2013-03-312013-04-20
上面的设计不满足3NF:
主键1--推出--->班级php0331，班级php0331-----推出---->教室102,这样给人的感觉，教室不是由主键IDP1直接推出的，好像由班级通过传递推出的；当然还存在
主键IDP---->讲师------>性别
这样的坏处就是会产生数据冗余，解决方案是把中间的代理抽出来作为另外一张表：
应该如下设计：
IDP 讲师 班级 代课时间 开始 结束
1韩忠康php033130天2013-03-312013-05-05|
2韩忠康php022830天2013-02-282013-03-30|
3韩顺平php022815天2013-03-312013-04-20|
--------------------------------------------------------
讲师 性别
韩忠康male
韩顺平male
-----------------
班级 教室
php0228 106
php0331 102
-------------
可以看到这样设计只需要用22个字段，而上面那种设计需要用24个字段，这样就节省了2个字段，如果数据是海量的那么节省的数据应该更加多
这样设计，其实为了避免非笛卡尔积数据的重复，当然，笛卡尔积的数据的重复是必须的！
那么数据库的设计可以先按照自己的想法设计一个"大表"出来,然后进行拆分成符合三范式的表，当然一般的规律的实体都单独作为一个表格
比如讲师实体，班级实体，代课关系实体，但是最大的问题是开始不知道哪些是实体，其实除了看得见的，其实说的清的可以描述的关系也可以作为一个实体
，这一点是容易被忽视的，但是随着经验的提升，慢慢会了解！