精华内容
下载资源
问答
  • 数据库三大范式
    2021-03-11 21:26:04

    数据的概念

    对象object,也称为实体型。在现实世界中具有相同性质、遵循相同规则的一类事物的抽象称为对象。对象是实体集数据化的结果,比如学生、老师、课程等是对象。

    实例instance 是指对象中的每一个具体的事物,例如学生张三、李四。

    属性attribute 是实体的某一方面特征的抽象表示,例如学生的姓名、性别、班级、年龄等。

    主码primary key 能够唯一标识一个实体。

    次码secondary key 指实体中不能唯一标识实体的属性。

    域domain 指属性的取值范围,比如性别中的男、女。

    完整性 指存储在数据库中的所有数据值均正确的状态。如果数据库中存储有不正确的数据值,则该数据库称为已丧失数据完整性。

    什么是范式

    目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。而通常我们用的最多的就是第一范式(1NF)、第二范式(2NF)、第三范式(3NF)。

    当一个关系中的所有分类都是不可再分的数据项时,该关系是规范化的。不可再分的数据项,即不存在组合数据项和多项数据项。一个低一级的关系模式,通过模式分解可以转换为若干高一级范式的关系模式的集合,这个过程就叫规范化。二维数据表可以分为5级范式为1NF、2NF、3NF、4NF、5NF。第一范式满足最低的要求条件,第五范式满足最高要求的条件。

    第一范式(1NF):要求数据库表的每一列都是不可分割的原子数据项。

    **概念:**所谓第一范式(1NF)是指在关系模型中,对于添加的一个规范要求,所有的域都应该是原子性的,即数据库表的每一列都是不可分割的原子数据项,而不能是集合,数组,记录等非原子数据项。即实体中的某个属性有多个值时,必须拆分为不同的属性。在符合第一范式(1NF)表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之,第一范式就是无重复的域。
    **说明:**在任何一个关系数据库中,第一范式(1NF)是对关系模式的设计基本要求,一般设计中都必须满足第一范式(1NF)。不过有些关系模型中突破了1NF的限制,这种称为非1NF的关系模型。换句话说,是否必须满足1NF的最低要求,主要依赖于所使用的关系模型。

    例1:

    不符合第一范式

    学号姓名性别学校信息
    20210101张幼仪学士,大一
    20210102徐志摩硕士,研一
    20210103陆小曼博士,博一
    20210104林徽因博士,博二
    20210105梁思成硕士,研二
    20210106金岳霖硕士,研三

    符合第一范式

    在上面的表中,“学校信息”列不满足原子性的要求,故不满足第一范式,调整如下

    学号姓名性别学历年级
    20210101张幼仪学士大一
    20210102徐志摩硕士研一
    20210103陆小曼博士博一
    20210104林徽因博士博二
    20210105梁思成硕士研二
    20210106金岳霖硕士研三

    例2:

    不符合第一范式

    学号姓名性别学历年级电话
    20210101张幼仪学士大一15234940672,15536895536
    20210102徐志摩硕士研一15234940672,15536895536

    符合第一范式

    学号姓名性别学历年级电话
    20210101张幼仪学士大一15234940672
    20210101张幼仪学士大一15536895536
    20210102徐志摩硕士研一15234940672
    20210102徐志摩硕士研一15536895536

    可见,调整后的每一列都是不可再分的,因此满足第一范式(1NF)。

    第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性,本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分,那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储,这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式,如下表所示。

    学号姓名性别学历年级电话省份城市详细地址
    20210101张幼仪学士大一15234940672北京海淀区XXX小区
    20210101张幼仪学士大一15536895536山西太原市YYY小区
    20210102徐志摩硕士研一15234940672北京朝阳区YYY小区
    20210102徐志摩硕士研一15536895536北京西城区YYY小区

    上表所示的用户信息遵循了第一范式的要求,这样在对用户使用城市进行分类的时候就非常方便,也提高了数据库的性能。

    第二范式(2NF):确保表中的每列都和主键相关

    **概念:**第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组,作为实体的唯一标识。例如在员工表中的身份证号码即可实现每个一员工的区分,该身份证号码即为候选键,任何一个候选键都可以被选作主键。在找不到候选键时,可额外增加属性以实现区分,如果在员工关系中,没有对其身份证号进行存储,而姓名可能会在数据库运行的某个时间重复,无法区分出实体时,设计辟如ID等不重复的编号以实现区分,被添加的编号或ID选作主键。(该主键的添加是在ER设计时添加,不是建库时随意添加)

    第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。简而言之,第二范式就是在第一范式的基础上属性完全依赖于主键。(第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言)。也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。)

    比如要设计一个订单信息表,因为订单中可能会有多种商品,所以要将订单编号和商品编号作为数据库表的联合主键,如下表所示。

    订单信息表

    订单编号商品编号商品名称数量单位价格客户所属单位联系方式
    10011卡车1¥2,222徐志摩用友123456789
    1001220¥595徐志摩用友123456789
    10023汽车2¥25,154李四某某254689336

    这样就产生一个问题:这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关,而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。

    而如果把这个订单信息表进行拆分,把商品信息分离到另一个表中,把订单项目表也分离到另一个表中,就非常完美了。如下所示。

    订单信息表

    订单编号客户所属单位联系方式
    1001徐志摩用友123456789
    1001徐志摩用友123456789
    1002李四某某254689336

    订单项目表

    订单编号商品编号数量
    100111
    1001220
    100232

    商品信息表

    商品编号商品名称单位价格
    1卡车¥2,222
    2¥595
    3汽车¥25,154

    这样设计,在很大程度上减小了数据库的冗余。如果要获取订单的商品信息,使用商品编号到商品信息表中查询即可。 说的通俗一点,就是能做为维度表的,要拆分出来作为维度表,比如常见的部门,人员,组织,物料,供应商等等。

    第三范式(3NF):确保每列都和主键列直接相关,而不是间接相关

    **概念:**在2NF基础上,任何非主属性不依赖于其它非主属性(在2NF基础上消除传递依赖)
    第三范式(3NF)是第二范式(2NF)的一个子集,即满足第三范式(3NF)必须满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性,也就是在满足2NF的基础上,任何非主属性不得传递依赖于主属性。

    第三范式需要确保数据表中的每一列数据都和主键直接相关,而不能间接相关。即属性不依赖于其它非主属性,属性直接依赖于主键。数据不能存在传递关系,即每个属性都跟主键有直接关系而不是间接关系。像:a–>b–>c 属性之间含有这样的关系,是不符合第三范式的。

    Student 表

    学号姓名性别年龄所在院校院校地址院校电话
    20210101张幼仪23清华北京123123132
    20210102陆小曼25清华北京123123132
    20210103徐志摩24复旦上海231354564
    20210104梁思成24复旦上海231354564

    这样一个表结构,就存在上述关系。 学号–> 所在院校 --> (院校地址,院校电话)

    这样的表结构,我们应该拆开来

    1、学生信息表

    学号姓名性别年龄
    20210101张幼仪23
    20210102陆小曼25
    20210103徐志摩24
    20210104梁思成24

    2、院校信息表

    所在院校院校地址院校电话
    清华北京123123132
    复旦上海231354564

    总结:三大范式只是一般设计数据库的基本理念,可以建立冗余较小、结构合理的数据库。如果有特殊情况,当然要特殊对待,数据库设计最重要的是看需求跟性能,需求>性能>表结构。所以不能一味的去追求范式建立数据库。

    更多相关内容
  • 三范式确保主键列之间没有传递函数依赖关系,也就是消除传递依赖。 本文将基于三范式原则,结合具体的实例做简要分析,难度系数:基础。 2 第一范式 2.1 例子引入 根据如下场景设计出两种数据表,请分析两种数据...
  •  数据库设计三大范式(重点):  第一范式(1NF):数据表中的每一列(每个字段)必须是不可拆分的小单元,也是确保每一列的原子性;  例如:userInfo:山东省烟台市 131777368781 userAds:山东0省烟台市 ...
  • 数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,...第三范式:在第二范式的基础上,数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式
  • 在实际开发中最为常见的设计范式个: 1.第一范式(确保每列保持原子性) 第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值,就说明该数据库表满足了第一范式。 第一范式的合理遵循需要...
  • 1.第一范式:数据库的字段是单一属性,不可再...第三范式:任何非关键字段不能传递依赖任一侯选关键字  非关键字字段必须直接依赖任一侯选关键字  非关键字段C不能依赖非侯选关键字B,因为样会形成传递依赖:侯选关
  • 三大范式

    千次阅读 2021-02-26 09:11:21
    三范式:消除传递依赖,要求一张表中的每一列都和主键是直接依赖的,不是间接依赖 举例分析: 第一范式:要求一张表中的数据每一列都是不可分割的原子项数据 例如下面的这张表就是不符合第一范式的,因为家庭...

    三大范式

    概念解释: 三大范式其实就是数据库建表的规范。

    第一范式:要求一张表中的数据每一列都是不可分割的原子项数据
    第二范式:消除部分依赖,要求一张表中的每一列都完全依赖于主键(针对于组合主键),也就是不会出现某一列只和部分主键相关
    第三范式:消除传递依赖,要求一张表中的每一列都和主键是直接依赖的,不是间接依赖

    举例分析:


    第一范式:要求一张表中的数据每一列都是不可分割的原子项数据
    例如下面的这张表就是不符合第一范式的,因为家庭信息和学校信息中的数据都不是原子项数据。

    在这里插入图片描述

    修改之后:此时所有的数据就是原子项数据

    在这里插入图片描述


    第二范式:消除部分依赖


    例如下图:这是订单表,由于同一订单中会出现不同的产品,所以将订单号与产品号作为组合主键,但是我们可以看到其中的产品数量,产品折扣和产品价格与主键中的订单号,产品号都有关,而订单时间与订单金额只与订单号有关,这就导致了部分依赖。

    在这里插入图片描述

    修改之后:为了消除部分依赖,所以应该分表!

    在这里插入图片描述


    第三范式:消除传递依赖


    举例:下表中的所有属性的确都完全依赖于学号,但是实际上班主任性别与班主任年龄确是直接依赖于班主任姓名的,而不是直接依赖于学号,这样就导致了传递依赖!

    在这里插入图片描述

    修改之后:此时就不会产生传递依赖的问题了!

    在这里插入图片描述

     

    展开全文
  • Mysql的三大范式

    2020-12-14 11:39:08
    三范式(3NF):在2NF基础上,任何非主属性不依赖于其它非主属性(在2NF基础上消除传递依赖) 几个概念: 函数依赖:A–>B,如果通过A属性(属性组)的值,可以确定唯一B属性的值。则称B依赖于A 例如:学号–>姓名。 ...
  • 数据库设计三大范式

    2017-10-13 17:04:54
    介绍数据库设计基本的三大范式,简练透彻的立即数据库设计的范式
  • Mysql数据库设计 数据库三大范式

    千次阅读 2022-03-12 13:38:57
    目前数据库有六种范式:第一范式、第二范式、第三范式、巴斯-科德范式、第四范式、第五范式(又称完美范式)。 第一范式:列不可再分,具有原子性,即数据库表的每一列都是不可分割的原子数据项,不能是集合、数组等...

    目录

    数据库范式

    表与表的关系

    表字段的设置

    数据库表设计规范

    创建表结构示例

    左连接 右连接 内连接

    DELETE TRUNCATE和DROP

    数据库的优化

    数据库表结构设计工具


    数据库范式

    设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。目前数据库有六种范式:第一范式、第二范式、第三范式、巴斯-科德范式、第四范式、第五范式(又称完美范式)。

     第一范式:列不可再分,具有原子性,即数据库表的每一列都是不可分割的原子数据项,不能是集合、数组等非原子数据项。

     第二范式:在满足第一范式的前提下,每一列都依赖于主键,表中的每一个字段都依赖于主键。

     第三范式:在满足第二范式的前提下,每一列都直接依赖于主键,而不能通过其他列来间接的依赖主键。 三大范式只是一般设计数据库的基本理念,可以建立冗余较小、结构合理的数据库。如果有特殊情况,当然要特殊对待,数据库设计最重要的是看需求跟性能,需求>性能>表结构。所以不能一味的去追求范式建立数据库。

    表与表的关系

     一对一

     一对多

     多对多

    表字段的设置

    字段类型相关表字段是用来存储数据内容大小的,其大小的设置跟存储到磁盘分配的磁盘块多少有直接关系。

    换算单位:1KB=1024B,1B=8bit(位);
    数据存储是以二进制存储的,一个子节占8位,
    例:十进制数 9大小占一个子节,用二进制表示为:0000 1001。
    查看数据库表结构文件存放地址执行:show global variables like "%datadir%"。

     char(n) :固定长度类型,char(10),当你输入"abc"三个字符的时候,它们占的空间还是10个字节,其他7个是空字节。其优点是存取数据效率高,缺点是占用空间大,以空间换时间,适用场景:存储密码的md5值,固定长度的,使用char非常合适。

     varchar(n) :可变长度,存储的值是每个值占用的字节再加上一个用来记录其长度的字节的长度。从空间上考虑varcahr比较合适;从效率上考虑char比较合适。

     float(m,d):单精度浮点数, m显示长度,d表示小数点位数,占用空间4个字节。例如:float(4,2) 表示的范围是-99.99~99.99。

     decimal(m,d):m显示长度,d表示小数点位数。例如:decimal(5,2) 表示范围:-999.99 ~ 999.99。往数据库字段类型为float(10.8)、decimal(10,8)分别插入数据10.12345678,10.12345678,然后执行select * from 表,会发现float类型的字段显示数据为10.12345695,而decimal字段显示的数据为10.12345678,float单精度小数位数小于decimal,decimal如果不指定精度,默认为(10,0)。

     double:浮点类型有两种,分别是单精度浮点数(float)和双精度浮点数(double),定点类型只有一种,就是decimal,可以存储16位的十进制数,占空间8字节

    数据库表设计规范

    1.推荐utf-8字符集。

    2.固定字符串的列尽可能多用定长char,少用varchar。

    3.所有的InnoDB表都设计一个无业务用途的自增列做主键。

    4.字段长度满足需求前提下,尽可能选择长度小的。

    5.字段属性尽量都加NOT NULL约束(空的字段不能走索引,查询速度慢)对于某些文本字段,例如“省份”或者“性别”我们可以将他们定义为ENUM类型

    6.尽可能不使用TEXT/BLOB类型,确实需要的话,建议拆分到子表中,不要和主表放在一起,避免SELECT的时候读性能太差。

    7.读取数据时,只选取所需要的列,不要每次都SELECT * 尤其是读到一些TEXT/BLOB类型,确实需要的话,建议拆分到子表中,不要和主表放在一起,避免SELECT的时候读性能太差

    8.对一个VARCHAR(N)列创建索引时,通常取其50%(甚至更小)左右长度创建前缀索引就足以满足80%以上的查询需求了,没必要创建整列的全长度索引。

    9.多用复合索引,少用多个独立索引。

    创建表结构示例

    创建表:
        CREATE TABLE `user` (
          `id` INT AUTO_INCREMENT,
          `name` VARCHAR (20),
          PRIMARY KEY (`id`)
        );
    UPDATE:
      UPDATE 表名称 SET 列名称 = 新值 WHERE 列名称 = 某值
    INSERT: 
      INSERT INTO 表名称 VALUES (值1, 值2,....)
      INSERT INTO table_name (列1, 列2,...) VALUES (值1, 值2,....)
    DELETE:
      DELETE FROM 表名称 WHERE 列名称 = 值
    修改表结构:
        ALTER TABLE table_name add column_name datatype
        ALTER TABLE table_name drop COLUMN column_name
        ALTER TABLE table_name modify COLUMN column_name datatype
    

    左连接 右连接 内连接

      INNER JOIN(内连接,或等值连接):取得两个表中存在连接匹配关系的记录。

      select * from A inner join B on A.name = B.name;
    

      LEFT JOIN(左连接):取得左表(table1)完全记录,即是右表(table2)并无对应匹配记录。

      select * from A left join B on A.name = B.name;
      select * from A left join B on A.name=B.name where A.id is null or B.id is null;
    

      RIGHT JOIN(右连接):与LEFT JOIN 相反,取得右表(table2)完全记录,即是左表(table1)并无匹配对应记录。drop、truncate和delete的区别

    DELETE TRUNCATE和DROP

     DELETE 对数据一行一行的删除,将每行的删除操作记录在日志中保存,以便进行回滚操作。

     TRUNCATE 一次性地从表中删除所有的数据不记录操作日志,数据不能恢复,删除的过程中不会激活与表有关的删除触发器。执行速度快。

     DROP 语句将表所占用的空间全释放掉。TRUNCATE和DELETE只删除数据, DROP则删除整个表(结构和数据)。

    数据库的优化

    硬件层

    1.CPU(运算):48核CPU。
    2.内存:96G-256G,跑3-4个实例。
    3.disk(磁盘IO):机械盘:选SAS,数量越多越好。性能:SSD(高并发)>SAS(普通业务线上)>SATA(线下)
    选SSD:使用SSD或者PCIe SSD设备,可提升上千倍的IOPS效率。随机IO:SAS单盘能力300IOPS 
    SSD随机IO:单盘能力可达35000IOPS Flashcache HBA卡 
    4.raid磁盘阵列:4快盘:RAID0>RAID1(推荐)>RAID5(少用)>RAID1。主库选择raid10,
    从库可选raid5/raid0/raid10,从库配置等于或大于主库
    5.网卡:使用多块网卡bond,以及buffer,tcp优化。千兆网卡及千兆、万兆交换机
    数据库属于IO密集型服务,硬件尽量不要使用虚拟化
    

    操作系统层面优化

    1.选择x86_64系统,推荐使用CentOS6.8 linux,关闭NUMA特性
    2.将操作系统和数据分开(逻辑上和物理上)
    3.避免使用Swap交换分区
    4.避免使用软件磁盘阵列
    5.避免使用LVM逻辑卷
    6.删除服务器上未使用的安装包和守护进程
    

    网络优化

    #优化系统套接字缓冲区
    #Increase TCP max buffer size
    net.core.rmem_max=16777216 #最大socket读buffer
    net.core.wmem_max=16777216 #最大socket写buffer
    net.core.wmem_default = 8388608 #该文件指定了接收套接字缓冲区大小的缺省值(以字节为单位)
    net.core.rmem_default = 8388608
    #优化TCP接收/发送缓冲区
    
    # Increase Linux autotuning TCPbuffer limits
    net.ipv4.tcp_rmem=4096 87380 16777216
    net.ipv4.tcp_wmem=4096 65536 16777216
    net.ipv4.tcp_mem = 94500000 915000000927000000
    #优化网络设备接收队列
    net.core.netdev_max_backlog=3000
    

    数据库层面优化

     my.cnf参数优化 此优化主要针对innodb引擎,default-storage-engine=Innodb,

    innodb_buffer_pool_size:指定用于索引的缓冲区大小
    innodb_file_per_table = 1:使用独立表空间
    innodb_data_file_path = ibdata1:1G:autoextend,不要使用默认的10%
    innodb_log_file_size=256M,设置innodb_log_files_in_group=2,基本可满足90%以上的场景;
    innodb_log_file_size
    long_query_time = 1记录那些执行较慢的SQL,用于后续的分析排查;
    max_connection(最大连接数)max_connection_error(最大错误数,建议设置为10万以上,而open_files_limit、innodb_open_files、table_open_cache、table_definition_cache这几个参             数则可设为约10倍于max_connection的大小;)不要设置太大,会将数据库撑爆 
    tmp_table_size = 64M :设置内存临时表最大值。如果超过该值,则会将临时表写入磁盘,其范围1KB到4GB。
    max_heap_table_size = 64M:独立的内存表所允许的最大容量。
    table_cache = 614:给经常访问的表分配的内存,物理内存越大,设置就越大。调大这个值,一般情况下可以降低磁盘IO,但相应的会占用更多的内存,这里设置为614。
    

    sql语句的优化

    索引的优化: DBA参与,抓出慢SQL,减少上线后的慢SQL数据,

    配置my.cnf long_query_time = 2 log-slow-queries=/data/3306/slow-log.log log_queries_not_using_indexs 按天轮询:slow-log.log

    慢查询的日志分析工具——mysqlsla或pt-query-digest(推荐) pt-quey-diges,mysqldumpslow,mysqlsla,myprofi,mysql-explain-slow-log,mysqllogfileter 3)

    每天晚上0点定时分析慢查询,发到核心开发,DBA分析,及高级运维,CTO的邮箱里 DBA分析给出优化建议-->核心开发确认更新-->DBA线上操作处理

    定期使用pt-duplicate-key-checker检查并删除重复的索引

    定期使用pt-index-usage工具检查并删除使用频率很低的索引

    使用pt-online-schema-change来完成大表的ONLINE DDL需求

    有时候MySQL会使用错误的索引,对于这种情况使用USE INDEX

    使用explain及set profile优化SQL语句

    数据库表结构设计工具

    展开全文
  • 单纯通过概念原理性的描述来了解三范式可能会一头雾水,像我在一开始接触到数据库三范式的时候也是分不清第二范式和第三范式的关系,后来记住了概念一段时间不使用就描述不清楚了,今天有人问起,于是我想出了一个...

    目录

    第一范式(1NF):

     第二范式(2NF)

    第三范式(3NF)

    复合主键

    联合主键


    数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。

    单纯通过概念原理性的描述来了解三大范式可能会一头雾水,像我在一开始接触到数据库三范式的时候也是分不清第二范式和第三范式的关系,后来记住了概念一段时间不使用就描述不清楚了,今天有人问起,于是我想出了一个例子来具体说下数据库三大范式。

    如下表,是不符合数据库三大范式的,下面通过数据库三大范式依次对数据表进行改造:

    字段解释:

    student_id

    学号
    student_name学生姓名
    course课程
    score得分
    class班级
    headteacher班主任

    第一范式(1NF):

    每一列属性都是不可再分的属性值,是原子化、不可再分解的,1NF就是确保每一列的原子性。因此,两列的属性相近或相似或一样(描述的主体是同一个对象的多个属性),尽量合并属性一样的列,确保不产生冗余数据。

    很明显,表中的course列,包含两个属性:课程编号和课程名称,不符合数据库的第一范式,即不符合原子性,所以要将这一列拆分成两列:

    这样,这张表就符合数据库的第一范式了。

     第二范式(2NF)

    2NF是在1NF的基础上建立起来的,即满足2NF必须先满足1NF。2NF要求所有属性要完全依赖于主键,是对记录的唯一性约束,要求记录有唯一标识,即实体的唯一性;为实现区分通常需要为表设置一个或多个属性值,即主键,多个属性值就是联合主键以存储各个实例的惟一标识。这个唯一属性列被称为主键。

    可以看到,student_id、course_id作为复合主键,要保证其他非主键元素要依赖主键元素,也就是说所有的列都要同时依赖于student_id、course_id这两个属性。但是在表中,student_name,class,headteacher只依赖于student_id,course_name只依赖于course_id,所以这两个_name属性就不符合2NF,要将这些依赖关系独立成表:

    学生信息表:

    课程信息表:

    学生得分表:

    第三范式(3NF)

    属性不依赖于其它非主属性    属性直接依赖于主键,3NF是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没有冗余。数据不能存在传递关系,即每个属性都跟主键有直接关系而不是间接关系。像:a-->b-->c  属性之间含有这样的关系,是不符合第三范式的。

    我们注意到,在按照2NF设计的学生信息表中,headteacher属性值依赖于class属性值,也就是属性依赖于非主属性值:

    学生表:

     按照3NF改进:

    学生表:

    班级表:

    再比如Student表(学号,姓名,年龄,性别,所在院校,院校地址,院校电话),就存在上述关系。 学号--> 所在院校 --> (院校地址,院校电话),按照3NF改进:学生表(学号,姓名,年龄,性别,所在院校)院校表(所在院校,院校地址,院校电话)。

    范式化设计反范式化设计
    优点可以尽量减少数据冗余,使得更新快,体积小。可以减少表的关联,可以更好得进行索引优化
    缺点对于查询需要多个表进行关联,减少写得效率增加读得效率,更难进行索引优化数据冗余以及数据异常,数据得修改需要更多的成本。

    总结:三大范式只是一般设计数据库的基本理念,可以建立冗余较小、结构合理的数据库。如果有特殊情况,当然要特殊对待,数据库设计最重要的是看需求跟性能,需求>性能>表结构。所以不能一味的去追求范式建立数据库。

    复合主键

    指表的主键含有一个以上的字段组成,不使用无业务含义的自增id作为主键。比如name和id字段组合起来就是表的复合主键 ,它的出现是因为你的name字段可能会出现重名,所以要加上ID字段这样就可以保证你记录的唯一性 ,一般情况下,主键的字段长度和字段数目要越少越好 。
    关于“主键是唯一的索引”
    这句话是有局限性的,当我们在表中创建了一个ID字段,自增,并设为主键,因为ID自动增长保证了唯一性,所以这种情况下符合“主键是唯一的索引”。此时,在当前表中再创建一个字段name,类型为varchar,也设置为主键,你会发现,在表的多行中你是可以填写相同的name值的,这岂不是有违“主键是唯一的索引”这句话么,所以“主键是唯一的索引”是有歧义的。实际上应该是“当表中只有一个主键时,它是唯一的索引。当表中有多个主键时,称为复合主键,复合主键联合保证唯一索引”。


    既然自增长ID已经可以作为唯一标识的主键,为什么还需要复合主键呢。因为并不是所有的表都要有ID这个字段,比如,我们建一个学生表,没有唯一能标识学生的ID,这种情况下学生的名字、年龄、班级都可能重复,无法使用单个字段来唯一标识,这时可以将多个字段设置为主键,形成复合主键,这多个字段联合标识唯一性,其中,某几个主键字段值出现重复是没有问题的,只要不是有多条记录的所有主键值完全一样,就不算重复。

    联合主键

    联合主键指的是多张表的主键结合在一张中间表中,方便连查多张表的信息,为了查询两个表之间的元素,我们创建一个中间表,然后就可以通过中间表进行连表查询操作,其中中间表的id即为联合主键。联合主键是用2个字段(或者多个字段,后面具体都是用2个字段组合)来确定一条记录,说明这2个字段都不是唯一的,2个字段可以分别重复,这么设置可以很直观地看到某个重复字段的记录条数。
    比如主键A跟主键B组成联合主键,主键A跟主键B的数据可以相同也可以分别重复,联合就在于主键A跟主键B形成的联合主键是唯一的。比如主键A数据是1,主键B数据也是1,联合主键其实是11,这个11是唯一值,绝对不充许再出现11这个唯一值。(这就是多对多关系)


    总结: 复合主键就是含有一个以上的字段组成,如ID+name,ID+phone等,而联合主键要同时是两个表(或多个表)的主键组合起来的。
     

    展开全文
  • mysql三大范式

    2022-04-10 22:21:38
    #第一范式: # 保存原子性 第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值,就说明该数据库表满足了第一范式。 #第二范式: ...# 完全依赖于主键,消除部分依赖 ...#第三范式:..
  • 深入理解数据库设计的三范式,对于设计“健壮的数据库“十分有必要。数据库三范式是设计数据库 时参考的准则,接下来我们一一进行介绍:一、数据库第一范式:数据库表的每一列都是不可分割的基本数据项,同一列中不...
  • 数据库--三大范式--介绍/使用/实例

    多人点赞 2021-11-09 20:29:32
    本文用示例来介绍数据库的三大范式
  • 数据库三大范式详解

    2013-09-11 19:41:25
    目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、第四范式(4NF)、第五范式(5NF)和第六范式(6NF)。满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多...
  • 数据库三大范式通俗理解

    千次阅读 多人点赞 2021-03-15 16:29:32
    官方的解释就不放了,想看的可以去百度!...第二范式就是要求表中要有主键,表中其他其他字段都依赖于主键,因此第二范式只要记住主键约束就好了。 比如说有一个表是学生表,学生表中有一个值唯一的字段学号,那.
  • 深入理解关系型数据库三大范式,它又成为一个能和面试官扯上一会的知识!
  • 范式是符合某一种级别的关系模式的集合。关系数据库中的关系必须满足一定的要求,满足不同程度要求的为不同范式。...通俗地理解范式,对于数据库设计大有好处。在数据库设计中,为了更好地应用...
  • 范式简述 问题 : 为什么需要数据规范化? 不合规范的表设计会导致的问题: 1、信息重复 2、更新异常 ...三范式 ...第三范式(3NF) ...前提:满足第一范式和第二范式,...第三范式要求:确保数据表中的每一列数据都...
  • SQL三大范式

    2021-11-29 18:02:57
    sql的语句很简单,但是一些数据处理的逻辑却有点绕,并且sql还有8种范式,对数据库的建表也有很的要求,今天就简单说一说三大范式,这三大范式已经够用了。其余范式自行了解就可。 三大范式 1.第一范式(1NF) ...
  • mysql的三大范式

    2022-03-21 16:49:33
    mysql的三大范式实例
  • 三大范式的通俗解释

    千次阅读 2021-05-20 16:45:25
    其中最常使用的是第一范式(1NF)、第二范式(2NF)、第三范式(3NF),也就是所谓的三范式 第一范式 第一范式(1NF):要求数据库表的每一列都是不可分割的原子数据项。 1NF是对属性的**原子性**,要求属性具有...
  • sql三大范式理解

    千次阅读 2021-11-29 18:30:44
    目前关系数据库有六种范式: 1. 第一范式(1NF)(针对具体某一列)2....所谓第三范式,是指每一个非主属性既不部分依赖于也不传递依赖于关键字,也就是在第二范式的基础上消除传递依赖(A>B>C)。 4、BCNF巴.
  • 数据库三大范式是什么

    千次阅读 2022-02-11 10:00:29
    三范式:在第二范式的基础上,非主键列只依赖于主键,不依赖于其他非主键。 在设计数据库结构的时候,要尽量遵守三范式,如果不遵守,必须有足够的理由。比如性能。事实上我们经常会为了性能而妥协数据库的设计。 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 115,387
精华内容 46,154
关键字:

三大范式

友情链接: Debug.zip