轻松理解的三种范例

轻松理解的三种范例

一种正常形式的1NF

1. 表的每一行都是不可分割的基本数据项. 同一列中不能有多个值，即实体中的属性不能有多个值或重复的属性. 如果存在重复的属性，则可能需要定义一个新实体. 新实体由重复的属性组成. 新实体和原始实体是一对多的关系.

2. 表的每一行都包含有关实例的信息.

2.2. 第二范式2NF

1. 表中的每个实例或行必须唯一. 为了区分，通常需要在表中添加一列以存储每个实例的唯一标识符（即主键）.

2. 实体的属性完全取决于primary关键字. 所谓完全依赖意味着没有一个仅依赖于主键一部分的属性. 如果存在，则应将此属性和主键的这一部分分开以形成一个新实体. 新实体和原始实体之间存在一对多关系. 为了实现区分，通常需要在表中添加一列以存储每个实例的唯一标识符. 简而言之，第二种形式是非主要属性不部分依赖于主要关键字.

2.3. 第三范式3NF

表不包含其他表中已经包含的非主键信息. 例如，有一个部门信息表，其中每个部门都有诸如部门号DEPT_ID，部门名称，部门资料等信息. 然后，在员工信息表中列出的部门编号DEPT_ID之后，将没有关于该部门的其他信息，否则将导致数据冗余.

第一范式（1NF）: 在关系模式R中的每个特定关系r中，如果每个属性值都是不可分割的最小数据单位，则R称为第一范式关系. 示例: 例如员工编号，姓名，电话号码以构成表格（一个人可能有办公室电话和家庭电话号码）成为1NF的方法有以下三种:

一种是重复存储员工编号和姓名. 这样，关键字只能是电话号码.

第二，员工号码是一个关键字，电话号码分为两个属性: 单元电话和住宅电话

第三个是员工编号作为关键字，但是强制每个记录只能有一个电话号码.

以上三种方法中，第一种方法是最不可取的. 后两种情况要根据实际情况选择.

第二范式（2NF）: 如果关系模式R（U，F）中的所有非主要属性都完全依赖于任何一个候选关键字，则关系R属于第二范式.

示例: 课程选择关系SCI（SNO，CNO，GRADE，CREDIT），其中SNO是学生编号，CNO是课程编号，GRADEGE是年级，CREDIT是学分. 根据以上条件，关键词为组合关键词（SNO，CNO）

在应用程序中使用上述关系模式存在以下问题:

a. 数据冗余，假设40名学生选择同一门课程，则学分将重复40次.

b. 异常更新. 如果调整了课程学分，则应更新相应的元组CREDIT值. 同一门课程可能会有不同的学分.

c. 插入异常. 例如，如果您计划开设一门新课程，因为没有人选择，并且没有学生编号的关键字，那么您只能等待某人选择课程以保存课程和学分.

d. 异常删除. 如果学生已完成课程，请从当前中删除选修记录. 一些课程的新生还没有选修课程，因此这些课程和学分记录无法保存.

原因: 非关键字属性CREDIT仅取决于CNO函数，这意味着CREDIT的一部分取决于组合关键字（SNO，CNO），而不完全取决于它.

解决方案: 分为两个关系模式SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）. 新的关系包括两个关系模型，它们通过SC1中的外来关键字CNO连接，然后在需要恢复原始关系时自然地连接起来

第三范式（3NF）: 如果关系模式R（U，F）中的所有非主要属性对任何候选关键字都不具有传递信任，则关系R属于第三范式.

示例: 如果是S1（SNO，SNAME，DNO，DNAME，LOCATION），则每个属性代表学生编号，

名称，部门，部门名称，部门地址.

关键字SNO确定每个属性. 由于它是单个关键字，因此不存在部分依赖性问题，因此必须为2NF. 但是在这种关系中必须有很多冗余. 与学生有关的几个属性DNO，DNAME，LOCATION将被重复存储，插入，删除和修改，也会产生与上述示例类似的情况.

原因: 关系中存在传递依赖. 那就是SNO-> DNO. 但是，由于DNO-> SNO不存在，DNO-> LOCATION不存在，因此SNO对LOCATION函数的关键决定是通过传递依赖SNO-> LOCATION来实现的. 换句话说，SNO不会直接确定非主要属性LOCATION.

解决目的: 每个关系模型中都不能留下传递依赖.

解决方案: 分为两个关系S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）

注意: 关系S中没有外关键字DNO. 否则，两个关系之间的关系将丢失.

BCNF: 如果关系模式R（U，F）的所有属性（包括主要和非主要属性）未传递任何依赖于R的候选关键字，则关系R属于BCNF. 或关系模型R. 如果每个行列式都包含一个关键字（而不是包含在关键字中），则为RCNF的关系模型.

示例: 备件管理关系模型WPE（WNO，PNO，ENO，QNT）分别列出了仓库编号，备件编号，员工编号和数量. 有以下条件

a. 仓库中有多个员工.

b. 一位员工只能在一个仓库里工作.

c. 每个仓库中的一种附件都由专人处理，但一个人可以管理多种附件.

d. 相同型号的配件可以放在多个仓库中.

分析: 不能从上面确定PNO，QNT由属性（WNO，PNO）的组合确定，存在功能依赖性（WNO，PNO）-> ENO. 因为每个仓库中的一种附件由一个人负责，并且一个人可以管理多种附件，所以只有组合属性（WNO，PNO）才能确定负责人，所以有（WNO，PNO）-> ENO . 由于一名员工仅在一个仓库中工作，因此存在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

摘要:

目标: 标准化的目的是使结构更合理，消除存储异常，并使数据冗余度尽可能小，以便于插入，删除和更新

原理: 遵循“一物一地”的简化概念，即关系模型描述了一个实体或实体之间的关系. 规范的本质是概念的简化.

方法: 将关系模式投影分解为两个或多个关系模式.

要求: 分解后的关系模式集应与原始关系模式“等效”，也就是说，可以通过自然连接恢复原始关系而不会丢失任何信息，并保持属性之间的合理关系.

注意: 关系模式的分解可以获得不同的关系模式的集合，这意味着分解方法不是唯一的. 必须在分解后的可以表示原始中的所有信息的前提下实现最小冗余的要求. 基本目标是节省存储空间，避免数据不一致，提高关系的操作效率并满足应用程序需求. 实际上，并不一定要求所有模型都能够实现BCNF. 有时故意保留一些冗余对于数据查询可能更为方便. 对于更新频率低且查询频率极高的系统而言，尤其如此.

在关系中，除了功能依赖项之外，还有多值依赖项和连接依赖项. 因此，提出了更高的归一化要求，例如第四范式和第五范式. 在这里，我稍后再讨论.

亲爱的朋友们，您阅读本书后会怎么想，实际上，考虑到许多网民在建立的过程中，任何有关基础理论的书都会谈论这些内容. 我正在寻找要复制和复制的书. 如有任何疑问，请不要问我. 我将找到一本有关关系理论的书来阅读. 这可能对您有很大帮助. 谈论以上是基本理论. 请考虑一下. 在进行设计时，您是否考虑过遵循上述范例？如果设计做得不好，您是否考虑过？与上述相比，违反了多少范式？

我所看到的设计，很少有人能很好地满足上述几种范例. 一般而言，每个人都可以遵循第一个范式，很少有人完全遵守第二和第三个范式. 人们必须是设计的大师. BCNF范例具有较少的机会，它将破坏完整性. 设计时无法考虑. 当然，ORACLE可以通过触发器解决其缺点. 将来在一起设计时，我们也希望您遵循上述范例.

那些书籍引入的范例确实很模糊. 我将在这里给出一个流行的描述:

1NF: 表中的列是不可分割的（即列的原子性）

2NF: 表中的行可以唯一标识（即表中的行不能重复）

3NF: 一个表中的列不依赖于另一个表中的非主键列，或者不受欢迎！太冷了！ ！

一个例子: 有一个部门表，我们称它为tbl_department，它有很多列（dept_id（pk），dept_name，dept_memo ...）. 有一个雇员表，我们称其为tbl_employee，在此表中是dept_id（fk）列，描述有关部门的信息. 如果tbl_employee需要满足3NF，则除了tbl_employee中的dept_id列外，没有其他与部门信息相关的列！

一般的设计可以满足3NF！ （我个人认为我应该尽可能满足3NF，一个家庭的话^ _ ^）

BCNF: BCNF通常被认为是第三范式修订版，它比3NF更远！

4NF:

5NF: 尽可能将一个表拆分为多个小块，以排除该表中的所有冗余数据

=============================

解释一个规范化/范例的例子吗？

例如，为解释示例问题: 有属性SNO（学生编号），SNAM（学生姓名），DON（部门）MAN（部门负责人），关系R的主键是SNO，则R是1NF \ 2NF \ 3NF？

答案是2NF

学生编号是主要属性，名称可以直接由学生编号确定，学生编号可以确定学生所在的部门，部门负责人不是由主要属性学生编号确定，而是用部门名称来表示，这样的问题就在部门负责人之间，在这种关系中，学生人数和部门负责人不是直接确定的，而是间接确定的. 这被称为非主要属性，具有传递函数依赖性在主要属性上，因此它是2范式，在一个关系中说了1或2个范式，这稍微好一点，您可以根据主代码或间接代码确定非主要属性，因此是第二个范式.

只要知道名字，就可以找到部门和班主任，因此名字不仅与学生人数有关.

这不是第三种正常形式. 您可以通过仔细研究第三范式的定义来弄清楚

实际上，这种现象称为冗余，它属于双工冗余，因为班主任甚至与部门都有关系.

只要知道名字，就可以找到部门和班主任，因此名字不仅与学生人数有关.

这不是第三种正常形式. 您可以通过仔细研究第三范式的定义来弄清楚

实际上，这种现象称为冗余，它属于双工冗余，因为班主任甚至与部门都有关系.

============================

的规范化，如何理解1 \ 2 \ 3范式？

所谓的1NF，2NF，3NF，让我举个例子，让我理解...

1NF: 该字段是原子字段，无法划分；

例如，如果原产地是“湖北武汉”，则它违反了原子性，因为湖北武汉可以更具体地分为“湖北”和“武汉”

2NF: 组合关键字表，组合关键字中没有用于确定其他非键字段情况的字段（即，不能有两个组合键构成一个主键）

3NF: 在2NF的基础上，如果数据表中不存在依赖于任何候选字段的传递函数的非关键字段，则它符合第三范式（即，违反了数据冗余性）

帐户ID卡号码名称密码

1001 410101001李玫100001

ID号和名称共同决定密码，名称取决于ID号，这违反了第三种正常格式

典型的网络结构不仅仅是MVC结构，即视图层模型层控制层. 视图层负责显示页面，这是我们通常在Internet上看到的页面. 控制层负责逻辑控制，即控制我们单击链接. 或者单击按钮后，在页面上执行什么操作以及如何跳转；业务层是您要执行的操作，例如添加，删除，修改和查询数据. 这些操作全部由业务层执行. 良好的网络结构的常规业务层分为业务层，VO层和数据持久层. 业务层负责完成逻辑操作，VO层负责存储数据对象，而数据持久层则负责操作. 因此，页面的数据必须经过视图层->控制层->模型层-> VO层->数据持久层->，这样的过程，数据是逐层传递的，不应该操作跨层.

PS: 我说的是一种典型的网站结构. 实际上，任何层都可以对进行操作，但是不建议这样做，因为这会使层次结构变得模糊，并且不容易模糊和操作

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-246884-1.html