bc范式

第一章-需求分析 数据库设计的概念 数据库的设计，就是根据业务系统的具体需求，结合我们所选用的DBMS，为这个业务系统构造出最有的数据存储模型。并建立好数据库中的表结构及表与表之间的关联关系的过程。使之能 有效 的对应系统中的数据进行存储，并可以 高效 的对已经存储的数据进行访问。 数据库设计的步骤 需求分析----->逻辑设计----->物理设计----->维护优化 数据库需求分析的作用点： 数据是什么 数据有哪些属性 数据和属性各自的特点有哪些 使用ER图对数据库进行逻辑建模 数据管理系统的选择，根据数据库自身的特点把逻辑设计转换为物理设计 后期维护 新的需求进行建表，建新表之前也要做好前三步，防止后期出现的问题 索引优化 大表拆分 需求分析 为什么要进行需求分析？ 为了设计最优化的数据库，便于后期的扩展和维护，数据越来越多，越来越大会浪费空间，越来越杂乱，是很难处理和维护的 了解系统中索要存储的数据 了解数据的存储特点，比如有的数据有时效性，有的没有，有时效性的可以采取定期清理 了解数据的生命周期， 要搞清楚的一些问题 实体及实体之间的关系（1对1,1对多，多对多） 实体所包含的属性有什么？属性有很多，哪些属性是可以标识出这个实体的 那些属性或属性的组合可以唯一标识一个实体 存储上有什么特性，增长量是什么样？ 实例分析 第二章-逻辑设计 逻辑设计要做什么

我在 很久之前的一篇文章 中介绍了数据库模型设计中的基本三范式，今天，我来说一说更高级的BC范式和第四范式。 回顾 我用大白话来回顾一下什么是三范式： 第一范式：每个表应该有唯一标识每一行的主键。 第二范式：在复合主键的情况下，非主键部分不应该依赖于部分主键。 第三范式：非主键之间不应该有依赖关系。 这是我们设计数据库的基本规则，但是只有这三个规则并不能完全解决数据的增删改的异常情况，下面就来看看BC范式的例子。 BC范式 BC范式（BCNF）是Boyce-Codd范式的缩写，其定义是：在关系模式中每一个决定因素都包含候选键，也就是说，只要属性或属性组A能够决定任何一个属性B，则A的子集中必须有候选键。BCNF范式排除了任何属性(不光是非主属性，2NF和3NF所限制的都是非主属性)对候选键的传递依赖与部分依赖。 比如我们有一个学生导师表，其中包含字段：学生ID，专业，导师，专业GPA，这其中学生ID和专业是联合主键。 StudentId Major Advisor MajGPA 1 人工智能 Edward 4.0 2 大数据 William 3.8 1 大数据 William 3.7 3 大数据 Joseph 4.0 这个表的设计满足三范式，有主键，不存在主键的部分依赖，不存在非主键的传递依赖。但是这里存在另一个依赖关系，“专业”函数依赖于“导师”

  范式是关系数据库理论的基础，在设计数据库结构过程中所要遵循的规则和指导方法。6种范式依次是：1NF，2NF，3NF，BCNF（巴斯-科德范式），4NF，5NF。这里介绍前三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。 ◆ 第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。   考虑这样一个表：【联系人】（姓名，性别，电话）。如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到 1NF。要符合 1NF 只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）。 ◆ 第二范式（2NF）：首先符合1NF，另外满足两部分要求：【1】表必须有一个主键；【2】没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。   考虑一个订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。因为在一个订单中可以订购多种产品，所以单单一个 OrderID 是不足以成为主键的，主键应该是（OrderID，ProductID）。显而易见 Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而 UnitPrice，ProductName 只依赖于

什么是数据库范式？ 关系数据库的设计规范。不同的规范要求被称为不同的范式，越高的范式数据库冗余越小。 作用？ 减少数据库中数据冗余的过程； 数据库范式 1、第一范式（1NF）： 在关系模式R中，当且仅当所有属性只包含原子值，即每个分量都是不可再分的数据项，则称R满足1NF。 例如表所示的教师职称情况关系就不满足1NF。原因在于，该关系模式中的“高级职称人数”不是一个原子属性，若将其拆分为“教授”和“副教授”两个属性，则就满足1NF。 系名称 高级职称人数 教授 副教授 计算机系 1 2 电子系 3 4 2、第二范式（2NF）： 满足1NF的关系模式会有许多重复值，修改数据可能引起疏漏。为了消除这种数据冗余和避免更新数据的遗漏，需要使用更加规范的2NF。当且仅当关系模式满足1NF，且每个非键属性（既不属于任何候选键的属性，也称为非主属性）完全依赖于候选键时，则称R满足2NF。 例如，有选课关系模式SC(Sno,Cno,Grade,Credit)，其中(Sno,Cno)->Grade,Cno->Credit。因此，SC的候选键为(Sno,Cno)。这样Cno->Credit就构成了Credit对候选键(Sno,Cno)的部分函数依赖。因此，SC不满足2NF。若要将SC转化为2NF，可以将它拆分为SC1(Sno,Cno,Grade)和SC2(Cno,Grade)。 3、第三范式（3NF）

简单的说， 第一范式就是原子性，字段不可再分割； 第二范式就是属性完全依赖于主键，没有部分依赖； 第三范式就是没有传递依赖，属性不依赖于其它非主属性。 (1) 第一范式（1NF） 1NF的定义为：符合1NF的关系中的每个属性都不可再分。 下表所示的情况，就不符合1NF的要求。 1NF是所有关系型数据库的最基本要求，也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。如下表所示： (2) 第二范式（2NF） 2NF的定义为：在1NF的基础之上，消除了非主属性对于码的部分函数依赖。 例如： 对于下仅仅符合1NF的下表 仍会存在一些问题： 数据冗余过大： 学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次 插入异常: 假如学校3月份新建了一个系，等到8月份才招生，那么无法将系名与系主任的数据单独地添加到数据表中去 删除异常: 假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了 修改异常: 假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据 改进后如下： (3) 第三范式（3NF） 3NF的定义为：在2NF的基础之上，消除了非主属性对于码的传递函数依赖。 仅仅符合2NF的要求，很多情况下还是不够的，原因在于仍然存在非主属性(系主任)对于码(学号)的传递函数依赖。改进后如下： 改进

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 数据库范式是数据库设计中必不可少的知识，没有对范式的理解，就无法设计出高效率、优雅的数据库。甚至设计出错误的数据库。而想要理解并掌握范式却并不是那 么容易。教科书中一般以关系代数的方法来解释数据库范式。这样做虽然能够十分准确的表达数据库范式，但比较抽象，不太直观，不便于理解，更难以记忆。 本文用较为直白的语言介绍范式，旨在便于理解和记忆，这样做可能会出现一些不精确的表述。但对于初学者应该是个不错的入门。我写下这些的目的主要是为了加强 记忆，其实我也比较菜，我希望当我对一些概念生疏的时候，回过头来看看自己写的笔记，可以快速地进入状态。如果你发现其中用错误，请指正。 下面开始进入正题： 一、基础概念 要理解范式，首先必须对知道什么是关系数据库，如果你不知道，我可以简单的不能再简单的说一下：关系数据库就是用二维表来保存数据。表和表之间可以……（省略10W字）。 然后你应该理解以下概念： 实体：现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”，它也可以是虚拟的，不如说“老师与学校的关系”。 属性：教科书上解释为：“实体所具有的某一特性”，由此可见，属性一开始是个逻辑概念，比如说，“性别”是“人”的一个属性。在关系数据库中

　　　当前我们使用的主流数据库是关系型数据库，所以我是记录在关系型数据库中对范式的一些理解和看法．数据库库范式分为六种（其实还有有一个ＢＣＮＦ），分别为从第一范式到第六范式．高级一层是建立在所有低层的基础上的，如第２范式是建立在第一范式的基础上的，依次类推．　下面分别举例讲解各种范式： １．第一范式（1NF）： 　　第一范式的核心描述为：数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值．该范式讲的是列的原子性．有两层意思：一层是说每一列只能存一个属性值（如果把２个属性值存在１列中）．第二层说的是在一张表中属性值不能重复．　在现代关系行数据库中，都是默认满足第一范式的，所以你想要写出不满足第一范式的结构来还是不可能的事情，所以第一范式就不再多说．如果想深入，可以研究下其他非关系型的数据库的情况． ２．第二范式(2NF) 　　第二范式的核心描述为：行有唯一的主键，非主键仅对主键依赖．　有２层意思，第一层，每一行都要有主键（单独信息或组合信息），这个容易理解．　第二层意思是非主键对主键依赖，如果是复合主键的情况，非主键属性不能依赖于部分主键属性．如　【产品，仓库号，数量，仓库地址，仓库管理员】，这里（产品＋仓库号）为复合主键，而仓库地址和仓库管理员依赖于仓库号，这就是上面描述的＇主键属性不能依赖于部分主键属性＇，因此这是违背第二范式的，符合范式的设计应该为：【产品，仓库号

范式的定义 关系型数据库中的关系是需要满足一定条件的，满足这些不同程度的规范化就叫做范式。 范式按照规范化程度从低到高排序为第一范式，第二范式，第三范式，BC范式，第四范式，第五范式。 前导知识 函数依赖 R(U)是属性集U的关系模型，X，Y是U的一个子集，对于R(U)中的任一个关系r，不可能存在两个元组在X上属性值相同，而在Y上属性值不同。则称X函数确定Y，或Y函数依赖X。 说人话：U是表(可能不止一个表，可以是有关系的多个表)的所有列，X，Y分别是这些属性列的一个子集，也就是若干个属性， 对于所有在X这些属性上的值一样的行，在Y上的属性上也必须一样 ，满足这样条件的这若干个属性 X和Y叫称其函数依赖。 X相同则Y必须相同，但 X不同Y可以相同，也可以不同 。 如果Y是X的子集，就叫 平凡的函数依赖 ，一般不考虑这种，因为就是废话，X整个都相同，子集肯定相同。 如果Y不是X的子集，叫做 非平凡的函数依赖 。 如果Y函数依赖X，那么X称为决定因素。 如果Y函数依赖X，但不依赖X的任何一个真子集，也就是X是极小的，那就称 Y完全函数依赖X ，否则称 Y部分函数依赖X 。 如果X决定Y，Y决定Z，且 Y不决定X ，那么称 Z对X传递函数依赖 。 码(键) U是属性全集，K是U的子集，若U完全函数依赖K，则称K为 候选码 ，候选码若有多个，任意选择一个都可作为 主码 ，若U部分函数依赖K