谁知道数据库的几大范式

类别：计算机/网络>>程序问题描述：最好用简单的语言分析：第一范式（1NF）：在每一个给定的关系r关系模型R中，如果每个属性值不可整除，那么它就是最小单位的数据。
,R被认为是第一自然形式的关系。
例如：如果一个表由员工编号、姓名和电话号码组成（一个人可能有一个办公室电话号码和一个家庭电话号码），则在1NF中可以通过三种方式进行统一：一是重复存储员工编号和姓名。
在这种情况下，关键字只能是电话号码。
其次，员工号码是一个关键字，电话号码分为两个属性：工作电话号码和住宅电话号码。
第三，员工号码是一个关键字，但要求每条记录只能有一个电话号码。
以上三种方法中，第一种方法最不可取，后两种根据实际情况选择。
第二范式（2NF）：如果关系图R（U，F）中的所有非规范特征完全依赖于任何候选关键字，则称关系R属于第二范式。
示例：SCI选课关系（SNO、CNO、GRADE、CREDIT）其中SNO为学号，CNO为课程号，GRADEGE为年级，CREDIT为学分。
基于以上条件，关键词为组合关键词（SNO、CNO）。
在应用程序中使用上述关系模型会导致以下问题：数据重复假设40名学生选修同一门课程，则学分将重复40次。
为了。
异常更新如果某门课程的学分被修改，相应课程的学分值也会更新，同一门课程的学分可能会有所不同。
C.插入一个例外。
例如，如果您打算开设一门新课程，因为没有人选修，并且没有学号关键字，您可以将课程和学分存入某人选修。
D.删除例外如果学生已毕业，则从当前数据库中删除可选记录。
如果新生尚未修读某些课程，则无法保存课程记录和学分。
原因：非关键字属性CREDIT在功能上仅依赖于CNO，即CREDIT部分依赖于组合关键字（SNO、CNO），但不完全依赖。
解决方案：拆分为两种关系模式SC1（SNO、CNO、GRADE）和C2（CNO、CREDIT）。
包括新关系两个关系图，在SC1中通过外来关键字CNO连接，根据需要自然连接，并恢复原始关系（3NF）：如果关系图R(U,F)所有非键属性对任何候选属性都没有传递依赖关键字，则称关系R属于第三范式。
例如：每个S1属性（SNO、SNA​​ME、DNO、DNAME、LOCATION）分别代表学号、姓名、部门、​​部门名称和部门名称。
SNO关键字标识每个属性。
既然是单个关键字，就不存在部分依赖的问题，所以应该是2NF。
但这种关系必然包含大量的重复。
许多与请求者位置相关的DNO、DNAME和LOCATION属性将被重复存储、插入、删除和修改，并且会出现与上例类似的情况。
原因：关系中存在传递依赖。
这是SNO->DNO。
然而，DNO->SNO并不存在，DNO->LOCATION，所以关键是SNO对LOCATION函数的决策是通过传递依赖SNO->LOCATION来实现的。
换句话说，SNOLOCATION并不直接指定非键属性。
解决方案：每个关系模型中都不能留下传递依赖。
解决方案：划分为两个关系S(SNO,SNAME,DNO)，D(DNO,DNAME,LOCATION)。
注意：关系S不能没有外关键字DNO。
否则，两种关系之间的联系就会丢失。
BCNF：如果关系模式R（U，F）的所有属性（包括本质属性和非本质属性）都没有通过任何依赖于R的候选关键字，则称关系R属于BCNF。
或者关系模式R，如果每个选择器包含一个关键字（而不是被关键字包含），则为RCNF的关系模式。
示例：WPE零件管理关系模型（WNO、PNO、ENO、QNT）分别表示仓库号、零件号、员工号和数量。
适用以下条件：一个仓库有多名员工。
B-该员工只在一个仓库工作。
C.每个仓库有专人负责一种类型的附件，但一个人可以管理多种附件。
D.同一型号的配件可以放置在多个仓库中。
分析：QNT不能从上面的PNO确定，它是由组合属性（WNO，PNO）确定的，并且存在函数依赖（WNO，PNO）->ENO。
因为每个仓库中的一类分机都有专门的人负责，而一个人可以管理很多分机，所以有一组属性（WNO，PNO）来决定谁负责，有（WNO，PNO）->埃诺。
由于该员工只在一个仓库工作，因此存在ENO->WNO。
因为每个仓库只有一种配件专人负责，且该员工只在一个仓库工作，有（ENO，PNO）->QNT。
找到候选关键词，因为(WNO,PNO)->QNT，(WNO,PNO)->ENO，所以(WNO,PNO)可以识别整个组，是候选关键词。
根据ENO->WNO，(ENO，PNO)->QNT，(ENO，PNO)也可以识别整个组，是另一个候选关键字。
属性ENO、WNO和PNO都是主要属性，只有一个非主要属性QNT。
它在功能上完全依赖于任何候选关键字并且是直接依赖的，因此关系模式是3NF。
关键特征分析。
因为ENO->WNO，关键属性ENO是WNO的定义因素，但它本身并不是关键字，而只是组合关键字的一部分。
这就导致关键属性WNO对另一个候选关键字(ENO,PNO)有部分依赖，因为(ENO,PNO)->ENO但反之则不然，而P->WNO，所以(ENO,PNO)->WNO它也是一种传染性的依赖。
虽然非本质属性对候选关键词不存在传递依赖，但本质属性对候选关键词存在传递依赖，也会产生问题。
例如，一名新员工被分配到仓库工作，但暂时处于培训阶段，并不独立负责管理某些辅助设备。
它无法包含在关系中，因为缺少部分PNO密钥。
此外，如果某人更改为负责安全而不管分机如何，则删除分机时该员工也将被删除。
解决方案：分解为EP管理（ENO，PNO，QNT），关键字为（ENO，PNO）EW作业（ENO，WNO），其关键字为ENO缺点：分解后函数依赖关系保留较差。
在这个例子中，由于分解，函数依赖（WNO，PNO）->ENO丢失了，从而破坏了原来的语义。
这并不意味着每个仓库中的每个组件都有专人负责。
该组件可以由两个或更多人同时管理。
因此，分解的关系模式减少了一些集成约束。
将关系划分为多个关系才能使分析有意义，最低要求是分析后不丢失原始信息。
这些信息不仅包括数据本身，还包括函数依赖关系所表示的数据之间的相互约束。
分解的目标是实现更高水平的规范化，但分解过程中必须考虑两个问题：无损通信和函数依赖关系的保存。
有时，如果没有联系，往往不可能取得联系损失同时完全保留功能依赖性。
应根据需要进行权衡。
1NF到BCNF的四种范式有如下关系：BCNF包含3NF，2NF包含1NF

数据库三大范式

第一范式第一范式（1NF）要求数据表的每一列作为基本数据项都是不可分割的，同一列中的值不能相乘。
如果一列有多个值，则可以将该列拆分为一个实体。
在任何关系数据库中，第一范式（1NF）是所需的关系模型。
不满足第一范式（1NF）的数据库不是关系数据库。
例如（学生信息表）：学号姓名性别联系方式20080901张三男邮箱：zs@126.com，电话：8888666620080902李四女邮箱：ls@126.com，电话：66668888以上表格不成立，先范式：系统字段页面可以细分，所以正确的是：学号姓名类型电话邮箱20080901张三楠zs@126.com8888666620080902李斯努ls@126.com66668888第二范式首先满足第二范式（2NF）第一个必须满足。
正常形式（1NF）。
第二范式要求实体中每一行的所有非主属性完全依赖于主键；完全依赖：一个主键可以由多个属性组成。
绝对依赖要求不允许主属性不依赖于主键中的任何属性。
如果存在依赖于主键中的一组属性的非主属性，则必须为这组部分依赖的属性创建一个新实体，并在旧的关联实体中使用外键。
与新的存在有关，而新的存在必须与旧的自我相关。
例如（学生课程阅读安排）：学生课程教师名称教材课堂课堂上课时间李四Spring老师张Java讲师《用简单语言讲解Spring》30108:00张三Struts杨老师Java讲师《StrutsinAction》30213:30这里可以确定过去的（学生、课程）教师、教师职称、教材、教室和上课时间，所以（学生、课程）可以用作主键。
然而，教材并不完全依赖于（研究、课程）。
这称为不完全依赖或部分依赖。
发生这种情况时，不会填写第二范式。
修改后，课程安排：课程老师教师职称上课时间李四Spring张老师Java读本30108:00张三Struts杨老师Java读本30213:30课程安排：课程教材Spring《深入浅出的Spring《Struts》StrutsinAction》之三为了满足第三范式，首先要满足第二范式。
第三范式要求一个实体中的属性不能是其他实体中的非素数属性。
因为这将是无稽之谈。
即：一个属性不依赖于其他非主属性。
如果一个实体包含其他实体的非主属性，则可以使用外键引用这两个实体，而不是将另一个表的非主属性直接写入当前表。
在上例列表中的课程混合内容中，教师可以确定教师的职称。
这样就依赖于教师（学生、课程），教师的职称依赖于教师。
第三种范式是消除临时客户端。
修改后，课程阅读表：学生课程教师课堂上课时间李四真张老师30108:00张三Struts杨老师30213:30教师表：教师教师职称张老师Java讲师杨老师Java讲师老师所以职称新老师选择类型的时候还有一个地方可以保存。
如果没有人选择该教师类型，则该教师的职称不会从教师列表中删除。
简单来说，原子性是第一范式，字段不能再划分；----------------版权声明：本文为CSDN原创文章博主“susuxuezhang”并遵循版权CC4.0BY-SA转载协议。
原文链接：.net/susuxuezhang/article/details/88972339