db2 dbms_DBMS中的标准化– 1NF，2NF，3NF和BCNF

db2 dbms

Here you will learn about normalization in dbms with examples.

在这里，您将通过示例了解dbms中的规范化。

What is Normalization in Database?

什么是数据库规范化？

Most of the projects and websites contain lot of information. They store the data in tables. Since lot of data therefire database contains so many tables. In order to retrieve some information we must go through number of tables which leads to complex quires.

大多数项目和网站都包含很多信息。 他们将数据存储在表中。 由于有大量数据，因此firefire数据库包含许多表。 为了检索某些信息，我们必须遍历许多表格，这会导致复杂的查询。

We may think that the solution to avoid these complex quires is instead of number of tables store all information in one big table and retrieve required information from it. It works fine but in this case table will contain redundant information. And also arises other anomalies. They cause problems when inserting new data, updating and deleting. i.e if we try to delete some field in database due to mixing all data along with this data, some other data may lost. Same problem when updating, other fields also may update since all are in same table. And inserting data may give, so much of redundant data.

我们可能认为避免这些复杂需求的解决方案是将表中的所有信息存储在一个大表中并从中检索所需的信息，而不是表的数量。 它工作正常，但在这种情况下，表将包含冗余信息。 并且还会出现其他异常情况。 它们在插入新数据，更新和删除时会引起问题。 即，如果由于混合所有数据和数据而试图删除数据库中的某些字段，则可能会丢失其他一些数据。 更新时存在相同的问题，其他字段也可能更新，因为它们都在同一表中。 插入数据可能会产生大量冗余数据。

To avoid these problems of inserting, deleting and updating data, divide the tables as small as possible. The ideal size of the table is two attributes. To make this way we should follow some rules for dividing tables. First test each table whether it’s design is good or not. If not good go for division (split the table). This process of splitting tables is called Normalization.

为避免这些插入，删除和更新数据的问题，请对表进行尽可能小的划分。 该表的理想大小是两个属性。 为此，我们应该遵循一些划分表的规则。 首先测试每个表的设计是否良好。 如果不好，请进行分割(拆分表格)。 拆分表的过程称为标准化。

So, Normalization means split the tables into small tables which will contain less number of attributes in such a way that table design must not contain any problem of inserting, deleting, updating anomalies and guarantees no redundancy.

因此，规范化意味着将表拆分为小表，这些小表将包含较少数量的属性，以使表设计必须不包含任何插入，删除，更新异常的问题，并且不保证冗余。

Image Source

图片来源

To do normalization we use concept of “Functional dependency” and “Candidate keys”. Using these concepts we check whether table design is good or not, if not good we go from Normalization (splitting the table).

为了进行标准化，我们使用“功能依赖”和“候选键”的概念。 使用这些概念，我们检查表设计是否良好，如果不好，我们从归一化(拆分表)中进行。

Prerequisite

先决条件

For better understanding of this concept you should know about:

为了更好地理解这个概念，您应该了解以下内容：

• What is functional dependency
  什么是功能依赖
• How to find candidate keys
  如何找到候选键
• How to find closure
  如何找到封口
• Basic knowledge about all keys
  有关所有按键的基本知识

Without these also you can understand what is 1NF, 2NF, 3NF, BCNF. But to work with more complex problems you should know those concepts.

没有这些，您也可以了解什么是1NF，2NF，3NF，BCNF。 但是，要处理更复杂的问题，您应该了解这些概念。

Our final aim is that, after normalization, whatever the functional dependency (FD) applicable on table (let FD is x -> y), the left hand side is always must be a key (here x). This final form is called BCNF

我们的最终目标是，在归一化之后，无论适用于表的功能依赖关系(FD)是什么(让FD为x-> y)，左手边始终必须是键(此处为x)。 这种最终形式称为BCNF

BCNF guarantees zero (0) % redundancy.

BCNF保证零(0)％冗余。

To go to BCNF first we have to check whether the table is in 1NF, 2NF, 3NF and then BCNF.

要首先进入BCNF，我们必须检查表格是否位于1NF，2NF，3NF，然后是BCNF。

Note: Any Normal form aim is that to reduce redundancy and to avoid anomalies.

注意：任何正常形式的目的都是为了减少冗余并避免异常。

DBMS中的规范化 (Normalization in DBMS)

第一范式(1NF) (First Normal Form (1NF))

First Normal Form says that table is flat i.e in table there must no multi-valued and no composite attributes.

第一范式表示表是平面的，即在表中必须没有多值且没有复合属性。

Example:

例：

ID	Name	Course
1	Neeraj	C1
2	Pankaj	C1, C2
3	Pawan	C3

ID	名称	课程
1个	内拉杰	C1
2	潘卡伊	C1，C2
3	帕万	C3

In above case Pankaj has two courses C1 and C2, so Course is multi valued. Hence it is not in 1NF.

在上述情况下，Pankaj有两个路线C1和C2，因此路线是多值的。 因此，它不在1NF中。

Below table in is in 1NF.

下表中的是1NF。

ID	Name	Course
1	Neeraj	C1
2	Pankaj	C1
2	Pankaj	C2
3	Pawan	C3

ID	名称	课程
1个	内拉杰	C1
2	潘卡伊	C1
2	潘卡伊	C2
3	帕万	C3

We need not worry about this, because while converting ER model (diagram) to relational model (table), we follow rules that they guarantees all attributes free from multi-valued and composite.

我们不必为此担心，因为在将ER模型(关系图)转换为关系模型(表)时，我们遵循的规则是保证所有属性不受多值和复合影响。

So any relational table by default is in 1NF.

因此，默认情况下任何关系表都在1NF中。

第二范式( 2NF) (Second Normal Form (2NF))

Second Normal Form says that, if candidate key containing more than one attribute then any part of that key (called partial key) should not determine anything.

第二范式表示，如果候选键包含多个属性，则该键的任何部分(称为部分键)都不应确定任何内容。

Example:

例：

RollNum	StuName	CorNum	CorName	Result
1	Neeraj	3	DBMS	A
2	Venkat	2	OS	C
3	Phani	1	FLAT	B

RollNum	姓名	CorNum	冠名	结果
1个	内拉杰	3	数据库管理系统	一个
2	文卡特	2	操作系统	C
3	法尼	1个	平面	乙

Functional dependencies are:

功能依赖性为：

1. The attribute student name functionally depends on roll number. So RollNum -> StuName

   学生属性名称在功能上取决于卷号。 所以RollNum- > StuName

2. The attribute course name functionally depends on course number. So CorNum –> CorName

   属性课程名称在功能上取决于课程编号。 因此， CorNum – > CorName

3. The attribute Result depends on Roll number and Course number. So RollNum, CorNum -> Result

   属性Result取决于卷号和课程号。 所以RollNum，CorNum-> 结果

We can find that RollNum, CorNum  combine form as candidate key.

我们可以发现RollNum，CorNum将表单作为候选键。

Here we can see that a part of candidate keys are deriving other things which we called partial dependency. FD1 and FD2 are partial dependencies.

在这里我们可以看到一部分候选键正在派生其他东西，我们称之为部分依赖。 FD1和FD2是部分依赖项。

So this table is not in 2NF. To convert into 2NF find the closure where problem occurred and split the table with that result.

因此该表不在2NF中。 要转换为2NF，请找到发生问题的闭包，并使用该结果拆分表。

RollNum⁺ = { StuName } ;;;  CorNum⁺ = { CorName } ;;;

RollNum ⁺ = {StuName} ;;; CorNum ⁺ = {CorName} ;;;

These two should be separate tables and generally with candidate key other table formed.

这两个表应该是分开的表，并且通常与其他表组成候选键。

Resultant tables which are in 2NF:

2NF中的结果表：

Table 1:

表格1：

RollNum	StuName
1	Neeraj
2	Venkat
3	Phani

RollNum	姓名
1个	内拉杰
2	文卡特
3	法尼

Table 2:

表2：

CorNum	CorName
3	DBMS
2	OS
1	FLAT

CorNum	冠名
3	数据库管理系统
2	操作系统
1个	平面

Table 3:

表3：

RoNum	CorNum	Result
1	3	A
2	2	C
3	1	B

朗姆	CorNum	结果
1个	3	一个
2	2	C
3	1个	乙

For table 1 candidate key is RollNum, for table 2 candidate key is CorNum since these tables has a single prime attribute we can say these two are in 2NF. Coming to the third table candidate key is RollNum and CotNum combine. But on this table there is only one functional dependency is existing. So this is also in 2NF.

对于表1，候选键为RollNum，对于表2，候选键为CorNum，因为这些表具有单个素数属性，我们可以说这两个在2NF中。 第三张候选表的关键字是RollNum和CotNum组合。 但是在此表上，仅存在一个功能依赖项。 因此在2NF中也是如此。

i.e. 2NF is based on Full Functional Dependency. No partial keys are allowed. So in 2NF we checked for partial dependency and eliminated.

即2NF基于完全功能依赖。 不允许使用部分密钥。 因此，在2NF中，我们检查了部分依赖性并消除了。

Important Note: Whenever you find a part of key on left hand side of FD, don’t confirm that it is partial dependency. Check right side also if right hand side is non-prime attribute then only it is partial dependency. If right hand side also prime attribute it is not a partial dependency.

重要说明：每当在FD左侧找到键的一部分时，请勿确认它是部分依赖项。 如果右侧不是非质数属性，也检查右侧，则仅是部分依赖性。 如果右侧也是主要属性，则它不是部分依赖性。

第三范式(3NF) (Third Normal Form (3NF))

Third normal form says that there is no “Transitive Dependency”.

第三范式表示不存在“传递依赖性”。

We know the rule of transitivity that, If A -> B and B -> C then A -> C. We can find the transitive dependency FD’s in such a way that, “Non-prime attribute derive something”. If any FD is like this we can say that it has Transitive dependency and we need to eliminate it to make it into 3NF.

我们知道传递性规则，即如果A-> B和B-> C然后A->C。我们可以通过以下方式找到传递依赖项FD，即“ 非素数属性派生某物” 。 如果有任何这样的FD，我们可以说它具有传递依赖性，我们需要消除它以使其成为3NF。

We can check 3NF in other way also, formal definition of 3NF is:

我们也可以用其他方式检查3NF，3NF的正式定义是：

Definition: A relational schema (table) is in 3NF if and only if every non trivial FD X -> Y

定义：当且仅当每个不重要的FD X-> Y时，关系模式(表)才是3NF

Either X is a super key or Y is a prime attribute (it is part of some candidate key). If this definition follows there is no chance of transitive dependency.

X是超键，或者Y是素数属性(它是某些候选键的一部分)。 如果遵循此定义，则没有传递依赖的机会。

Example:

例：

Student Table

学生桌

StuID	StuName	RollNum	ClassCode	ClassName
1	Mishra	12	CS1	Lect.Hall
2	Amit	14	CS2	Lab
3	Jack	16	CS3	Theorey

学生证	姓名	RollNum	班级代码	班级名称
1个	米斯拉	12	CS1	礼堂
2	阿米特	14	CS2	实验室
3	插口	16	CS3	理论

Functional dependencies:

功能依赖性：

1. StuID -> StuName, StuName, RollNum, ClassCode
   StuID-> StuName，StuName，RollNum，ClassCode
2. ClassCode -> ClassName
   ClassCode-> ClassName

Here StudID is candidate key which can able to derive everything. So one and only prime attribute is StuID only. But we can see that 2^nd FD i.e ClassCode -> ClassName in this ClassCode is a non-prime attribute which is deriving something. So this is not in 3NF.

在这里，StudID是可以导出所有内容的候选键。 因此，唯一的主要属性仅是StuID。 但是我们可以看到^第二个 FD，即该ClassCode中的ClassCode-> ClassName是非素属性，它派生了一些东西。 因此，这不在3NF中。

To convert into 3NF find the closure where problem occurred to split the table.

要转换为3NF，请在发生问题的地方关闭表格以关闭表格。

ClassCode⁺ = { ClassName };

ClassCode ⁺ = {ClassName};

Resultant tables after splitting are

拆分后的结果表是

Student Table

学生桌

StuID	StuName	RollNum	ClassCode
1	Mishra	12	CS1
2	Amit	14	CS2
3	Jack	16	CS3

学生证	姓名	RollNum	班级代码
1个	米斯拉	12	CS1
2	阿米特	14	CS2
3	插口	16	CS3

In this table StuID is candidate key and only one Functional dependency existing which is StuID -> StuName, RollNum, ClassCode. So there is no problem this is in 3NF.

在此表中，StuID是候选键，并且仅存在一个功能依赖项，即StuID-> StuName，RollNum，ClassCode。 因此这在3NF中没有问题。

Class Table

类表

ClassCode	ClassName
CS1	Lect.Hall
CS2	Lab
CS3	Theorey

班级代码	班级名称
CS1	礼堂
CS2	实验室
CS3	理论

In this table ClassCode is candidate key and only one functional dependency existing which is ClassCode -> ClassName. So this table is also in 3NF

在此表中，ClassCode是候选键，并且仅存在一个功能依赖项，即ClassCode-> ClassName。 所以这个表也是3NF

博伊斯·科德范式(BCNF) (Boyce Codd Normal Form (BCNF))

To make sure zero % redundancy two scientists Boyce and Codd invented this BCNF. In BCNF result each FD determinants (left hand side attribute) must be a key.

为了确保零冗余，两位科学家Boyce和Codd发明了这种BCNF。 在BCNF结果中，每个FD决定因素(左侧属性)都必须是键。

Definition: A relational schema R is in BCNF if whenever a non-trivial FD X -> Y , X should be a super key.

定义：如果每当非平凡FD X-> Y时，X应该是超级键，则关系模式R在BCNF中。

Example:

例：

IpAdd	PortNum	ProcessReq
10.4.9.34	80	Register Application form
10.11.4.99	110	Gmail message request
10.1.11.111	25	Remote User request

ip地址	PortNum	流程要求
10.4.9.34	80	注册申请表
10.11.4.99	110	Gmail邮件请求
10.1.11.111	25	远程用户请求

Functional dependencies exist on this table are:

该表上存在的功能依赖项是：

1. IpAdd, PortNum -> ProcessReq
   IpAdd，PortNum-> ProcessReq
2. ProcReq -> PortNum
   ProcReq-​​> PortNum

Applying normalization means converting into BCNF. For that we first check 1NF, 2NF, 3NF.

应用规范化意味着转换为BCNF。 为此，我们首先检查1NF，2NF，3NF。

By default every relational schema is in 1NF.

默认情况下，每个关系模式都在1NF中。

Before proceeding to next normal forms, we should find candidate keys. If we find candidate keys we get { IpAdd, PortNum } and { IpAdd, ProcessReq } are candidate keys. So prime attributes (part of candidate keys) are IpAdd, PortNum, ProcessReq. As per formal definition of 3NF, if right hand side has prime attribute, it is enough to say that it is in 3NF. Since all attributes are prime attributes we can say that table is in 3NF also. If already in 3NF, no need to check 2NF. So up to 1NF, 2NF, 3NF all are fine.

在继续下一个普通形式之前，我们应该找到候选密钥。 如果找到候选密钥， 则将获得{IpAdd，PortNum}和{IpAdd，ProcessReq}是候选密钥。 因此，主要属性(候选密钥的一部分)是IpAdd，PortNum，ProcessReq。 根据3NF的正式定义，如果右侧具有主要属性，则可以说它在3NF中。 由于所有属性都是主要属性，因此可以说该表也位于3NF中。 如果已经在3NF中，则无需检查2NF。 所以最多1NF，2NF，3NF都可以。

Now check for BCNF. According to the definition of BCNF left hand side should be key. So FD IpAdd, PortNum -> PorcessReq . Therefore AB is a key there is no problem.

现在检查BCNF。 根据BCNF的定义，左侧应该是关键。 所以FD IpAdd，PortNum-> PorcessReq。 因此AB是关键，没有问题。

Other FD PorcessReq -> PortNum, here this FD not deriving all attributes, since it’s not deriving everything ProcessReq is not a key. We can say that it is not in BCNF.  To make it into BCNF,

其他FD PorcessReq-> PortNum，此处此FD不能派生所有属性​​，因为它不能派生所有内容，而ProcessReq不是关键。 我们可以说它不在BCNF中。 要使其成为BCNF，

ProcessReq⁺ = { ProcessReq, PortNum } is a separate table.

ProcessReq ⁺ = {ProcessReq，PortNum}是一个单独的表。

PortNum	ProcessReq
80	Register Application form
110	Gmail message request
25	Remote User request

PortNum	流程要求
80	注册申请表
110	Gmail邮件请求
25	远程用户请求

And { IpAdd, ProcReq} is other table.

而{IpAdd，ProcReq}是另一个表。

IpAdd	ProcessReq
10.4.9.34	Register Application form
10.11.4.99	Gmail message request
10.1.11.111	Remote User request

ip地址	流程要求
10.4.9.34	注册申请表
10.11.4.99	Gmail邮件请求
10.1.11.111	远程用户请求

On table PortNum, ProcessReq, Functional Dependency is ProcReq -> PortNum, here ProcessReq is key, so satisfies BCNF. And on table IpAdd, ProcessReq, { IpAdd, ProcessReq } itself a key, so it also is in BCNF. But here we lost FD, { IpAddr, PortNum } -> ProcReq so called this is a not functional dependency preserving result even it is in BCNF.

在表PortNum上，ProcessReq，功能依赖性为ProcReq-​​> PortNum，此处的ProcessReq为键，因此满足BCNF。 在表IpAdd，ProcessReq，{IpAdd，ProcessReq}本身上是键，因此它也在BCNF中。 但是在这里我们丢失了FD，{IpAddr，PortNum}-> ProcReq，所谓的这是一个不具有功能依赖性的结果，即使在BCNF中也是如此。

Finally this BCNF guarantees that there is no redundancy and no problem of anomalies of inserting, updating and deleting.

最后，此BCNF保证没有冗余，也不会出现插入，更新和删除异常的问题。

Comment below if you have queries or found any information incorrect in above tutorial for normalization in dbms.

如果您有疑问或在上述教程中对dbms中的规范化有任何不正确的信息，请在下面评论。

翻译自: https://www.thecrazyprogrammer.com/2017/06/normalization-in-dbms.html

db2 dbms