zoukankan      html  css  js  c++  java
  • SQL三大范式举例

     第一范式(1NF)
    数据库表中的任何字段都是单一属性的,不可再分
    create table aa(id int,NameAge varchar(100))
    insert into aa values(1,''名字-女'')
    错误:没有达到第一范式
    create table aa(id int,name varcahr(10),age char(2))
    insert into aa values(1,''名字'',''女'')
    正确:达到第一范式


    第二范式(2NF)
    数据库表中非关键字段对任一候选关键字段都不存在部分函数依赖。
    (当一个表是复合主键时,非主键的字段不依赖于部分主键(即必须依赖于全部的主键字段))
    create table sci(
       sno varchar(10),cno varchar(10),grade Integer,credit Integer,
    primary key sno,cno
    )
    课程(cno)1---1学分(credit)
    学生(sno)n---n课程(cno)
    学生+课程--->分数(grade)
    sci
    sno cno grade credit
    1    1   60     80
    2    1    90     80
    3    1    70     80
      学分cno大量重复存储,数据冗余。若要某课程学分,则要大量重复操作。如要加新课程,由于sno和cno共同做为主键,则在加入新课程时,必须有人选该课。如某学生某课程结业,则该学生其它课程信息也同时被删除了。总之,这种设计不太好吧,非关键字属性credit仅函数依赖于cno,也就是credit部分依赖组合关键字(sno,cno)而不是完全依赖。
      解决方法:分成两个关系模式 sc1(sno,cno,grade),c2(cno,credit)。新关系包括两个关系模式,它们之间通过sc1中的外关键字cno相联系,需要时再进行自然联接,恢复了原来的关系。


    第三范式(3NF)
    关系模式R(U,F)中的所有非主属性对任何候选关键字都不存在传递依赖
    例----S1(SNO,SNAME,DNO,   DNAME, LOCATION)
              学号 姓名   所在系 系名称 系地址
      关键字SNO决定各个属性。由于是单个关键字,没有部分依赖的问题,肯定是2NF。但这关系肯定有大量的冗余,有关学生所在的几个属性DNO,DNAME,LOCATION将重复存储,插入,删除和修改时也将产生类似以上例的情况。
      原因:关系中存在传递依赖造成的。即SNO 1->1 DNO。 而DNO 1->n SNO却不存在,而DNO -> LOCATION存在, 因此关键辽 SNO 对 LOCATION 函数决定是通过传递依赖 SNO -> LOCATION 实现的。也就是说,SNO不直接决定非主属性LOCATION。
      解决方法:分为两个关系 S(SNO,SNAME,DNO),D(DNO,DNAME,LOCATION) 注意:关系S中不能没有外关键字DNO。否则两个关系之间失去联系。

  • 相关阅读:
    区块链技术赋能证券业 多家券商业务率先“上链”
    分布式金融的基础设施:如何驱动主流采用?
    回顾|2019年中国金融科技行业研究报告
    智能投顾行业深度报告:技术为镐,蓝海掘金
    毕马威举办2019中国领先金融科技企业50颁奖典礼
    智能投顾监管半年考:牌照合规 接受度仍待考验
    PostgreSQL串行化隔离级别(SSI)的能力与实现
    邹传伟:对人民银行DC/EP的初步分析
    央行辟谣未发行“DC/EP”和“DCEP” 法定数字货币仍在测试阶段
    php进程daemon化的正确做法
  • 原文地址:https://www.cnblogs.com/snailjn/p/2883060.html
Copyright © 2011-2022 走看看