数据库范式

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

什么是范式：简言之就是，数据库设计对数据的存储性能，还有开发人员对数据的操作都有莫大的关系。所以建立科学的，规范的的数据库是需要满足一些规范的来优化数据数据存储方式。在关系型数据库中这些规范就可以称为范式。 三大范式的定义： 第一范式：每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。 第二范式：满足第一范式条件，而且每个非关键字属性都由整个关键字决定（而不是由关键字的一部分来决定）。 第三范式：符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述（即一个非关键字属性值不依赖于另一个非关键字属性值）。 以下仅供参考！ 第一范式：当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。 第一范式是最基本的范式。如果数据库表中的 所有字段值都是不可分解的原子值 ，就说明该数据库满足第一范式。 第一范式的合理遵循需要根据系统给的实际需求来确定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成为一个数据库表的字段就行，但是如果系统经常访问“地址”属性中的“城市”部分，那么一定要把“地址”这个属性重新拆分为省份、城市、详细地址等多个部分来进行存储，这样对地址中某一个部分操作的时候将非常方便，这样设计才算满足数据库的第一范式。如下图。 第二范式

第一范式 　　定义表：属性分割 第二范式 　　分表：各自依赖自己主键 第三范式 　　关联：主键关联 数据库中的范式有第一范式(1NF),第二范式(2NF),第三范式(3NF),巴斯-科德范式(BCNF),第四范式(4NF),第五范式(5NF)(又称完美范式) 第一范式----数据库中的表(所有字段值)都是不可分割的原子数据项。 第二范式----数据库表中的每一列都和主键相关，而不能只和主键的某一部分相关。也就是说 一个表中只能只能包含一个，不能把多种数据保存在同一个表中。 第三范式----数据库表中每一列数据都和主键直接相关，不能间接相关。 降低数据的冗余度。。。。。。 转自---- Ruthless 数据库设计三大范式 为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。 在实际开发中最为常见的设计范式有三个： 1 ．第一范式(确保每列保持原子性) 第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。 第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市

数据库设计的三大范式 为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就叫做范式。 范式就是符合某一种设计要求的总结，要想设计一个结构合理的关系型数据库，必须满足一定的范式。 在实际开发中最常见的设计范式有三个： 1、第一范式*（确保每列保持原子性） 第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库满足第一范式。 第一范式的合理遵循需要根据系统给的实际需求来确定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成为一个数据库表的字段就行，但是如果系统经常访问“地址”属性中的“城市”部分，那么一定要把“地址”这个属性重新拆分为省份、城市、详细地址等多个部分来进行存储，这样对地址中某一个部分操作的时候将非常方便，这样设计才算满足数据库的第一范式。如下图。 上图所示的用户信息遵循第一范式的要求，这样对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。 2、第二范式（避免数据的重复，意思就是一张表只描述一件事情,一张表中不能同时出现订单信息与产品信息） 第二范式在第一范式的基础上更进一层，第二范式需要确保数据库表中每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中

明天数据库考试。。。看到了一篇写的极好的关于三大范式理解的文章，现收藏于下 为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。 在实际开发中最为常见的设计范式有三个： 1 ．第一范式(确保每列保持原子性) 第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。 第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。 上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。 2 ．第二范式(确保表中的每列都和主键相关) 第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据

参考 详解数据库的第一范式、第二范式、第三范式、BCNF范式 数据库规范化/范式所解决的问题 数据冗余（信息重复，会造成储存空间的浪费及一些其他问题） 插入异常（如果有限制，导致插入数据时，必须没必要的列也要有值，这种列甚至此时就是没有数据） 删除异常（在某些情况下,当删除一行时,可能会丢失有用的信息，因为这些相对独立的信息没有单独存储到一个表中） 更新异常（冗余信息不仅浪费空间,还会增加更新的难度，想要修改一个信息，结果由于数据冗余，导致需要更新多条记录） 基本概念 首先说明 键字=码字，所以 主键=主码，候选键=候选码...此外也有叫做主关键字，候选关键字的也是一个意思。 主键/码/候选键/候选码 小技巧：假如A是码，那么所有包含了A的属性组，如（A，B）、（A，C）、（A，B，C）等等，都不是码了（因为作为码的要求里有一个“完全函数依赖”） 主属性 非主属性：包含在任何一个码中的属性成为主属性。除了主属性以外的就是非主属性。 超键 能够唯一标识一条记录的属性或属性集。 全码 All-key关系模型的所有属性组组成该 关系模式的 候选码，称为全码。即所有属性当作一个码。若关系中只有一个候选码,且这个候选码中包含全部属性,则该候选码为全码。 函数依赖 部分依赖 传递依赖 范式 最常用的是第一、第二、第三范式。BCNF范式有时要考虑？ 第一范式

我在 很久之前的一篇文章 中介绍了数据库模型设计中的基本三范式，今天，我来说一说更高级的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 这个表的设计满足三范式，有主键，不存在主键的部分依赖，不存在非主键的传递依赖。但是这里存在另一个依赖关系，“专业”函数依赖于“导师”

1.范式说明 1.1 第一范式（1NF）无重复的列 　　所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能同时有多个值， 即实体中的某个属性不能有多个值或者不能有重复的属性 。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。 　　在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 在当前的任何关系数据库管理系统（DBMS）中，不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。 举例1： 比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。 UserInfo(ID,Name,Age,LinkTel,Province,City,Address)

0.参考文献： http://www.cnblogs.com/xwdreamer/archive/2012/05/17/2506039.html 1.范式说明 1.1 第一范式（1NF）无重复的列 　　所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能同时有多个值， 即实体中的某个属性不能有多个值或者不能有重复的属性 。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。 　　在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 在当前的任何关系数据库管理系统（DBMS）中，不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。 举例1： 一张学生表Student(stuNo,stuName,age,age,sex)是不符合第一范式的，因为有重复列age属性。去除重复列age以后的Student(stuNo,stuName,age,sex)是符合第一范式的。 1.2 第二范式（2NF）属性完全依赖于主键 [ 消除部分子函数依赖 ] 　　第二范式

  范式是关系数据库理论的基础，在设计数据库结构过程中所要遵循的规则和指导方法。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 只依赖于