精华内容
下载资源
问答
  • 数据库设计第范式

    2016-11-04 10:57:40
    一、数据库设计范式及其意义和不足 数据库设计范式数据库设计所需要满足的规范,数据库的规范化是优化表的结构和优化把数据组织到表中的方式,这样使数据更明确,更简洁。实践中,通常把一个数据库分成两个或多...
    **第一范式:数据库表中的字段都是单一属性的,不可再分。
    第二范式:非主键信息不是由整个主键函数来决定时,即违法第二范式
              信用卡号,学籍号 主键---->卡现金
    第三范式:存在非主键属性  传递依赖 即违法第三范式
    StudentNo CardNo  UserID  职位
    021101    001     Operator 操作员**

    一、数据库设计范式及其意义和不足
    数据库的设计范式是数据库设计所需要满足的规范,数据库的规范化是优化表的结构和优化把数据组织到表中的方式,这样使数据更明确,更简洁。实践中,通常把一个数据库分成两个或多个表并定义表之间的关系以做到数据隔离,添加、删除和修改某个字段只需要在一个表中进行,接着可以通过定义的关系传递到数据库中剩余的表中(和分层思想的意义所在很相似)。这样我们可以消除很多错误或垃圾数据出现的机会并减轻更新信息所必要的工作量。

    目前,主要有六种范式:第一范式、第二范式、第三范式、BC范式、第四范式和第五范式。满足最低要求的叫第一范式,简称1NF。在第一范式基础上进一步满足一些要求的为第二范式,简称2NF。其余依此类推

    事物往往具有多面性,设计范式也会带来一定的麻烦:操作困难,因为需要联系多个表才能得到所需要数据,而且范式越高性能就会越差。所以使用多高的范式需要权衡利弊,一般在项目中,使用到第三范式也就足够了,性能好而且方便管理数据。

    二、下面我们来举例介绍一下数据库设计三范式
    说明:实例采用《学校机房收费系统》的“学生信息表”,“学生上下机记录表”的部分字段

    1、第一范式1NF
    定义:数据库表中的字段都是单一属性的,不可再分。
    简单的说,每一个属性都是原子项,不可分割。

    1NF是关系模式应具备的最起码的条件,如果数据库设计不能满足第一范式,就不称为关系型数据库。也就是说,只要是关系型数据库,就一定满足第一范式。

    我们先来看一张不符合1NF的表1-1
    CardNo StudentNo StudentName Sex Department CardCash UserID UserLevel Time
    001 021101 小明 男 教育学院,心理系,1班 100 Operator 操作员 2011/10/03,09:00

    之所以说这张表不符合1NF,是因为Department和Time字段可以再分,所以应该更改为表1-2:
    CardNo StudentNo StudentName Sex Academy Major class CardCash UserID UserLevel Date Time
    001 021101 小明 男 教育学院 心理系 1 100 Operator 操作员 2011/10/03 09:00

    2、第二范式2NF
    定义:数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖,即符合第二范式。

    《注:什么是函数依赖,详见百度百科(http://baike.baidu.com/view/40008.htm)。
    如果一个表中某一个字段A的值是由另外一个字段或一组字段B的值来确定的,就称为A函数依赖于B。》
    2NF可以减少插入异常,删除异常和修改异常。

    简单的说,一方面,第二范式肯定要满足第一范式,否则就没有必要谈第二范式。
    另一方面,当某张表中的非主键信息不是由整个主键函数来决定时,即存在依赖于该表中不是主键的部分或者依赖于主键一部分的部分时,通常会违反2NF。

    我们再来看上面的满足1NF的表1-2
    CardNo StudentNo StudentName Sex Academy Major class CardCash UserID UserLevel Date Time
    001 021101 小明 男 教育学院 心理系 1 100 Operator 操作员 2011/10/03 09:00

    我们看到,在这张表中,通过CardNo和StudentNo就可以确定StudentName,Sex,Academy,Major,class,CardCash,UserID,Date,Time。所以可以把CardNo和StudentNo的组合作为主键。
    但是,我们发现CardCash并不完全依赖于CardNo和StudentNo,仅仅通过CardNo就可以确定CardCash,因为一张卡,一定会有卡内金额。这就造成了部分依赖。出现这种情况,就不满足第二范式。
    修改为:

    我们再来看另一个例子,学生上下机记录表,会更明显些。表2-1
    CardNo StudentNo StudentName Sex Department Major class OnDate OnTime OffDate OffTime ConsumeTime ConsumeMoney
    001 0211 小明 男 教育学院 心理系 1 2011/10/14 09:00 2011/10/14 10:00 1 2

    我们看到,在这张表中,StudentName,Sex,Department,Major,class都是直接依赖于StudentNo,而不依赖与表中的其他字段,这样的设计也不符合2NF非主键信息不是由整个主键函数来决定时。

    我们可以把1-2和2-1优化为:
    3-1
    StudentNo CardNo UserID UserLevel Date Time
    021101 001 Operator 操作员 2011/10/03 09:00
    3-2
    CardNo CardCash
    001 98
    3-3
    CardNo OnDate OnTime OffDate OffTime ConsumeTime ConsumeMoney
    001 2011/10/14 09:00 2011/10/14 10:00 1 2
    3-4
    StudentNo StudentName Sex Academy Major class
    021101 小明 男 教育学院 心理系 1

    3、第三范式3NF
    定义:在第二范式的基础上,数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合3NF。

    我们来看上例中优化后的表3-1
    StudentNo CardNo UserID UserLevel Date Time
    021101 001 Operator 操作员 2011/10/03 09:00

    在表中,一个UserID能确定一个UserLevel。这样,UserID依赖于StudentNo和CardNo,而UserLevel又依赖于UserID,这就导致了传递依赖,3NF就是消除这种依赖。

    我们把3-1进行优化得到:
    4-1
    StudentNo CardNo UserID Date Time
    021101 001 Operator 2011/10/03 09:00
    4-2
    UserID UserLevel
    Operator 操作员

    我们看到,第三范式规则查找以消除没有直接依赖于第一范式和第二范式形成的表的主键的属性。我们为没有与表的主键关联的所有信息建立了一张新表。每张新表保存了来自源表的信息和它们所依赖的主键。

    三、总结
    数据库设计规范化能让我们更好地适应变化,使你能够改变业务规则、需求和数据而不需要重新构造整个系统

    展开全文
  • 一、数据库设计范式及其意义和不足 数据库设计范式数据库设计所需要满足的规范,数据库的规范化是优化表的结构和优化把数据组织到表中的方式,这样使数据更明确,更简洁。 实践中,通常把一个数据库分成两个...

    一、数据库设计范式及其意义和不足

    数据库的设计范式是数据库设计所需要满足的规范,数据库的规范化是优化表的结构和优化把数据组织到表中的方式,这样使数据更明确,更简洁。

    实践中,通常把一个数据库分成两个或多个表并定义表之间的关系以做到数据隔离,添加、删除和修改某个字段只需要在一个表中进行,接着可以通过定义的关系传递到数据库中剩余的表中(和分层思想的意义所在很相似)。

    这样我们可以消除很多错误或垃圾数据出现的机会并减轻更新信息所必要的工作量。

    目前,主要有六种范式:第一范式、第二范式、第三范式、BC范式、第四范式和第五范式。满足最低要求的叫第一范式,简称1NF。在第一范式基础上进一步满足一些要求的为第二范式,简称2NF。其余依此类推

    事物往往具有多面性,设计范式也会带来一定的麻烦:操作困难,因为需要联系多个表才能得到所需要数据,而且范式越高性能就会越差。所以使用多高的范式需要权衡利弊,一般在项目中,使用到第三范式也就足够了,性能好而且方便管理数据。

    二、下面我们来举例介绍一下数据库设计三范式

    说明:实例采用《学校机房收费系统》的“学生信息表”,“学生上下机记录表”的部分字段

    1、第一范式1NF

    定义:数据库表中的字段都是单一属性的,不可再分。

    简单的说,每一个属性都是原子项,不可分割。

    1NF是关系模式应具备的最起码的条件,如果数据库设计不能满足第一范式,就不称为关系型数据库。也就是说,只要是关系型数据库,就一定满足第一范式。

    我们先来看一张不符合1NF的表1-1
    这里写图片描述

    之所以说这张表不符合1NF,是因为Department和Time字段可以再分,所以应该更改为表1-2:

    这里写图片描述

    2、第二范式2NF

    定义:数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖,即符合第二范式。

    《注:什么是函数依赖,详见百度百科(http://baike.baidu.com/view/40008.htm)。

    如果一个表中某一个字段A的值是由另外一个字段或一组字段B的值来确定的,就称为A函数依赖于B。》

    2NF可以减少插入异常,删除异常和修改异常。

    简单的说,一方面,第二范式肯定要满足第一范式,否则就没有必要谈第二范式。

    另一方面,当某张表中的非主键信息不是由整个主键函数来决定时,即存在依赖于该表中不是主键的部分或者依赖于主键一部分的部分时,通常会违反2NF。

    我们再来看上面的满足1NF的表1-2

    这里写图片描述

    我们看到,在这张表中,通过CardNo和StudentNo就可以确定StudentName,Sex,Academy,Major,class,CardCash,UserID,Date,Time。所以可以把CardNo和StudentNo的组合作为主键。

    但是,我们发现CardCash并不完全依赖于CardNo和StudentNo,仅仅通过CardNo就可以确定CardCash,因为一张卡,一定会有卡内金额。这就造成了部分依赖。出现这种情况,就不满足第二范式。

    修改为:

    我们再来看另一个例子,学生上下机记录表,会更明显些。表2-1

    这里写图片描述

    我们看到,在这张表中,StudentName,Sex,Department,Major,class都是直接依赖于StudentNo,而不依赖与表中的其他字段,这样的设计也不符合2NF非主键信息不是由整个主键函数来决定时。

    我们可以把1-2和2-1优化为:

    这里写图片描述

    3-2

    这里写图片描述

    3-3

    这里写图片描述
    3-4

    这里写图片描述

    3、第三范式3NF

    定义:在第二范式的基础上,数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合3NF。

    我们来看上例中优化后的表3-1

    这里写图片描述
    在表中,一个UserID能确定一个UserLevel。这样,UserID依赖于StudentNo和CardNo,而UserLevel又依赖于UserID,这就导致了传递依赖,3NF就是消除这种依赖。

    我们把3-1进行优化得到:

    4-1

    这里写图片描述

    我们看到,第三范式规则查找以消除没有直接依赖于第一范式和第二范式形成的表的主键的属性。我们为没有与表的主键关联的所有信息建立了一张新表。每张新表保存了来自源表的信息和它们所依赖的主键。

    三、总结

    数据库设计规范化能让我们更好地适应变化,使你能够改变业务规则、需求和数据而不需要重新构造整个系统。

    展开全文
  • 目前,主要有六种范式:第一范式、第二范式、第三范式、BC范式第四范式和第五范式。满足最低要求的叫第一范式,简称1NF。在第一范式基础上进一步满足一些要求的为第二范式,简称2NF。其余依此类
            关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式。数据库的设计范式是数据库设计所需要满足的规范。只有理解数据库的设计范式,才能设计出高效率、优雅的数据库,否则可能会设计出错误的数据库.

    目前,主要有六种范式:第一范式、第二范式、第三范式、BC范式、第四范式和第五范式。满足最低要求的叫第一范式,简称1NF。在第一范式基础上进一步满足一些要求的为第二范式,简称2NF。其余依此类推。

    范式可以避免数据冗余,减少数据库的空间,减轻维护数据完整性的麻烦,但是操作困难,因为需要联系多个表才能得到所需要数据,而且范式越高性能就会越差。要权衡是否使用更高范式是比较麻烦的,一般在项目中,用得最多的也就是第三范式,我认为使用到第三范式也就足够了,性能好而且方便管理数据。

    函数依赖,如果一个表中某一个字段Y的值是由另外一个字段或一组字段X的值来确定的,就称为Y函数依赖于X。


    第一范式(1NF)
    定义:如果关系模式R的每个关系r的属性都是不可分的数据项,那么就称R是第一范式的模式。
    简单的说,每一个属性都是原子项,不可分割。
    1NF是关系模式应具备的最起码的条件,如果数据库设计不能满足第一范式,就不称为关系型数据库。关系数据库设计研究的关系规范化是在1NF之上进行的。

    例如(学生信息表):
    学生编号  姓名  性别  联系方式
    20080901  张三  男   email:zs@126.com,phone:88886666
    20080902  李四  女   email:ls@126.com,phone:66668888

    以上的表就不符合,第一范式:联系方式字段可以再分,所以变更为正确的是:

    学生编号  姓名  性别  电子邮件   电话
    20080901  张三  男   zs@126.com  88886666
    20080902  李四  女   ls@126.com  66668888

    第二范式(2NF)
    定义:如果关系模式R是1NF,且每个非主属性完全函数依赖于候选键,那么就称R是第二范式。
    简单的说,第二范式要满足以下的条件:首先要满足第一范式,其次每个非主属性要完全函数依赖与候选键,或者是主键。也就是说,每个非主属性是由整个主键函数决定的,而不能由主键的一部分来决定。

    例如(学生选课表):
    学生    课程   教师    教师职称  教材         教室  上课时间
    李四    Spring  张老师   java讲师  《Spring深入浅出》  301 08:00
    张三    Struts  杨老师   java讲师  《Struts in Action》 302 13:30

    这里通过(学生,课程)可以确定教师、教师职称,教材,教室和上课时间,所以可以把(学生,课程)作为主键。但是,教材并不完全依赖于(学生,课程),只拿出课程就可以确定教材,因为一个课程,一定指定了某个教材。这就叫不完全依赖,或者部分依赖。出现这种情况,就不满足第二范式。

    修改后,选课表:
    学生    课程   教师    教师职称  教室  上课时间
    李四    Spring  张老师   java讲师  301 08:00
    张三    Struts  杨老师   java讲师  302 13:30

    课程表:
    课程   教材        
    Spring  《Spring深入浅出》 
    Struts  《Struts in Action》

    所以,第二范式可以说是消除部分依赖。第二范式可以减少插入异常,删除异常和修改异常。

    第三范式(3NF)
    定义:如果关系模式R是2NF,且关系模式R(U,F)中的所有非主属性对任何候选关键字都不存在传递依赖,则称关系R是属于第三范式。 
    简单的说,第三范式要满足以下的条件:首先要满足第二范式,其次非主属性之间不存在函数依赖。由于满足了第二范式,表示每个非主属性都函数依赖于主键。如果非主属性之间存在了函数依赖,就会存在传递依赖,这样就不满足第三范式。

    上例中修改后的选课表中,一个教师能确定一个教师职称。这样,教师依赖于(学生,课程),而教师职称又依赖于教师,这叫传递依赖。第三范式就是要消除传递依赖。

    修改后,选课表:

    学生    课程   教师    教室  上课时间
    李四    Spring  张老师   301 08:00
    张三    Struts  杨老师   302 13:30

    教师表:
    教师    教师职称
    张老师   java讲师
    杨老师   java讲师

    这样,新教师的职称在没被选课的时候也有地方存了,没人选这个教师的课的时候教师的职称也不至于被删除,修改教师职称时只修改教师表就可以了。

    简单的说,
    第一范式就是原子性,字段不可再分割;
    第二范式就是完全依赖,没有部分依赖;
    第三范式就是没有传递依赖。

    展开全文
  • 目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、第四范式4NF)、第五范式(5NF)和第六范式(6NF)。满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多...
  • 数据库范式范式范式
    范式:英文名称是 Normal Form,它是英国人 E.F.Codd(关系数据库的老祖宗)在上个世纪70年代提出关系数据库模型后总结出来的,范式是关系数据库理论的基础,也是我们在设计数据库结构过程中所要遵循的规则和指导方法。目前有迹可寻的共有8种范式,依次是:1NF,2NF,3NF,BCNF,4NF,5NF,DKNF,6NF。通常所用到的只是前三个范式,即:第一范式(1NF),第二范式(2NF),第三范式(3NF)。下面就简单介绍下这三个范式。 
    ◆ 第一范式(1NF):强调的是列的原子性,即列不能够再分成其他几列。 
    考虑这样一个表:【联系人】(姓名,性别,电话) 
    如果在实际场景中,一个联系人有家庭电话和公司电话,那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列(电话)拆分,即:【联系人】(姓名,性别,家庭电话,公司电话)。1NF 很好辨别,但是 2NF 和 3NF 就容易搞混淆。 
    ◆ 第二范式(2NF):首先是 1NF,另外包含两部分内容,一是表必须有一个主键;二是没有包含在主键中的列必须完全依赖于主键,而不能只依赖于主键的一部分。 
    考虑一个订单明细表:【OrderDetail】(OrderID,ProductID,UnitPrice,Discount,Quantity,ProductName)。 
    因为我们知道在一个订单中可以订购多种产品,所以单单一个 OrderID 是不足以成为主键的,主键应该是(OrderID,ProductID)。显而易见 Discount(折扣),Quantity(数量)完全依赖(取决)于主键(OderID,ProductID),而 UnitPrice,ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。 
    可以把【OrderDetail】表拆分为【OrderDetail】(OrderID,ProductID,Discount,Quantity)和【Product】(ProductID,UnitPrice,ProductName)来消除原订单表中UnitPrice,ProductName多次重复的情况。 
    ◆ 第三范式(3NF):首先是 2NF,另外非主键列必须直接依赖于主键,不能存在传递依赖。即不能存在:非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。 
    考虑一个订单表【Order】(OrderID,OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity)主键是(OrderID)。 
    其中 OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity 等非主键列都完全依赖于主键(OrderID),所以符合 2NF。不过问题是 CustomerName,CustomerAddr,CustomerCity 直接依赖的是 CustomerID(非主键列),而不是直接依赖于主键,它是通过传递才依赖于主键,所以不符合 3NF。 
    通过拆分【Order】为【Order】(OrderID,OrderDate,CustomerID)和【Customer】(CustomerID,CustomerName,CustomerAddr,CustomerCity)从而达到 3NF。 
    第二范式(2NF)和第三范式(3NF)的概念很容易混淆,区分它们的关键点在于,2NF:非主键列是否完全依赖于主键,还是依赖于主键的一部分;3NF:非主键列是直接依赖于主键,还是直接依赖于非主键列。
    展开全文
  • 数据库|第一范式、第二范式、第三范式、BC范式第四范式简单理解 在设计数据库的时候,虽说将我们要的数据正确完整导入数据库是很关键的,但是对于数据库设计者来说,如何将大量数据合理有效正确地导入数据库中也...
  • 数据库设计范式第范式第范式描述和实例
  • 数据库设计三大范式

    2020-08-24 14:46:20
    数据库设计三大范式1.范式(确保每列保持原子性)2.范式(确保表中的每列都和主键相关)3.范式(确保每列都和主键列直接相关,而不是间接相关) 数据库设计三大范式 为了建立冗余较小、结构合理的数据库,...
  • 数据库设计之三范式

    2019-11-25 20:56:08
    数据库设计之三范式 设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的数据库数据冗余越小。 数据冗余是值数据之间的重复,也可以...
  • [数据库] 范式范式范式、BC范式

    万次阅读 多人点赞 2017-02-23 19:30:33
    数据描述术语对应表 关键码 完全依赖、部分依赖、传递依赖 范式范式范式
  • 数据库设计六大范式

    2019-05-18 11:48:57
    关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式。...目前,主要有六种范式:第一范式、第二范式、第三范式、BC范式(巴斯-科德范式、修正的第三范式)、第四范式和第五范式(完美范式)...
  • 数据库设计--范式

    2019-06-18 19:27:20
    目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。 目前来说满足三范式就很不错了 思考问题:如何更好的...
  • 数据库范式范式范式,BCNF范式四大范式的基本概念名词解释范式优化实例一个特别糟糕的关系模式范式第范式第范式BCNF范式 此文章用于本人期末复习,适合对数据库范式分析还有一点记忆的...
  • 数据库设计中的范式与反范式 设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些... 目前关系数据库有六种范式范式(1NF)、范式(2NF)、范式(3NF)、巴斯-科德范式(BCNF...
  • 设计与操作维护数据库时,最关键的问题就是要确保数据能够正确地分布到数据库的表中。使用正确的数据结构,不仅有助于对数据库进行相应的存取操作,还可以极大地简化应用程序中的其他内容(查询、窗体、报表、代码...
  • 星光不问赶路人,时光不...目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。满足最低要求的范式是第一范...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 51,082
精华内容 20,432
关键字:

数据库设计第四范式