zoukankan      html  css  js  c++  java
  • 数据库复习之规范化理论

    声明:本文为作者复习数据库课程时简单记录的笔记,如有错误之处,敬请指出,谢谢。

    6.1问题的提出

    1.一个关系模式是一个五元组,形如R(U,D,DOM,F)。其中D、DOM与模式设计关系不大,可以看作三元组R<U,F>。

    • 关系名R是符号化的元组定义;
    • U为一组属性;
    • D为属性组U中的属性所来自的域;
    • DOM为属性到域的映射;
    • F为属性组U上的一组数据依赖

    2.数据依赖:一个关系内部属性与属性之间的一种约束关系。最重要的是函数依赖(FD)多值依赖(MVD),还有一个叫连接依赖

    3.分析关系模式常见问题:

    • 数据冗余:重复出现,浪费空间。(尽可能少)
    • 更新异常:更新代价(最好没有)
    • 插入异常:插入部分信息时无法插入(最好没有)
    • 删除异常:可能删除了其他想要的数据(最好没有)

    6.2规范化

    1.函数依赖:(概念省略,X、Y是属性组U的子集)X函数确定Y或Y函数依赖于X,记作X→Y。例如:系号→系名,学号→姓名。

      (1)函数依赖不是指关系模式R中的某些关系满足的约束条件,而是指R上的一切关系都要满足的约束条件。函数依赖关系的存在与时间无关,而只与数据之间的语义规定有关。 函数依赖的存在与时间无关,只与数据之间的语义定义有关。

      (2)函数依赖的基本性质:扩张性,投影性,合并性,分解性,

    2.非平凡的函数依赖X→Y:X→Y,但Y不包含于X。默认我么讨论的都是非平凡的函数依赖。

    3.平凡的函数依赖X→Y:X→Y,但Y包含于X。必然成立(好像是废话)。

    4.若X→Y,则称X为这个函数依赖的决定属性组,也称决定因素,Y为依赖因素


    5.完全函数依赖:在R(U)中,如果X → Y,并且对于X的任何一个真子集X’,都有X’ /→ Y,则称Y对X完全函数依赖。记作X F→ Y。

      推论:单一决定因素一定是完全函数依赖。

      例:(学号,课程号)→成绩

    6.部分函数依赖:在R(U)中,如果X→Y,且Y不完全函数依赖于X,则称Y对X部分函数依赖。记作X P→ Y。

      例:(学号,课程号)→课程名  (因为课程号→课程名,而课程号是(学号,课程号)的真子集)

    7.传递函数依赖:在R(U)中,如果X→Y(Y不包含于X),Y /→ X,Y→Z(Z不包含于Y),则称Z对X传递函数依赖。记为X 传递(t)→ Z。

      注:条件中要有Y /→ X,是因为如果Y→ X,则Y←→ X,则X直接→ Z,属于直接函数依赖,而非间接。

      例:系号→系名,系名→系主任名。


    8.候选码:设K为R<U,F>中的属性或属性组合,若K F→ U,则称K为R的候选码(候选键)。(即U完全依赖于K)。

    9.超码:若U部分依赖于K,即K P→ U,则称K为超码(超键)。候选码是最小的超码

    10.候选码可能多于一个,可选其中一个作为主码。包含在任何一个候选码中的属性称为主属性;不包含在任何一个候选码中的属性称为非主属性(非码属性)。最简单的情况,单个属性是码(主码或候选码);最极端的情况,整个属性组U是码,称为全码。(主码and候选码都简称码)

    11.关系模式R中的属性或属性组X不是R的码,但X是另一个关系模式的码,则称X为R的外部码(外码)


    12.第一范式(1NF):每一个分量必须是不可分的数据项(关系中每个属性都是不可再分的简单项)。

    13.第二范式(2NF):若R满足第一范式,且每一个非主属性完全函数依赖于任何一个候选码。

      推论:候选码为单属性或者全码,则属于2NF。

      特点:不存在非主属性对候选码的部分函数依赖

      1NF→2NF:消除非主属性对候选码的部分函数依赖,把部分函数依赖投影出来单独成表。(一事一表)

    14.第三范式(3NF):若R满足第二范式,且它的每一个非主属性都不传递依赖于任何候选码。

      定义:关系模式R<U,F>属于第一范式,若R中不存在这样的码X,属性组Y及非主属性Z(Y不包含于Z)是的X→Y,Y→Z成立,Y/→X,则称R属于3NF。

      定义理解:3NF的定义由1NF推过来的,不太好理解,判定的话用上上行2NF推导过来的就可以了,这个定义同时也可以证明,若R属于3NF,则R必属于2NF。

      特点:每一个非主属性对候选码没有部分函数依赖,也没有传递函数依赖。

      缺点:3NF只限制了非主属性对键的依赖关系,而没有限制主属性对键的依赖。

      2NF→3NF:消除非主属性对键的传递函数依赖,把传递依赖投影出来单独成表。(一事一表)

    15.BCNF:关系模式R<U,F>中,每一个决定因素都包含R的一个码(候选键),则R属于BCNF。

      定义:关系模式R<U,F>属于第一范式,若X→Y(Y不包含于X)时X必含有码,则R属于BCNF。

      特点:排除任何属性对候选码的传递函数依赖和部分函数依赖。在函数依赖范畴内实现彻底分离,消除插入和删除异常。

      3NF→BCNF:消除原关系中主属性对键的部分函数依赖和传递函数依赖。

      推论:如果R属于BCNF,则

    • R中所有非主属性对每一个码都是完全函数依赖;
    • R中所有主属性对每一个不包含它的码,都是完全函数依赖;
    • R中没有任何属性完全函数依赖于非码的任何一组属性。
      定理:如果R属于BCNF,则R属于3NF一定成立。反之不一定成立,因为3NF的不彻底性(可能存在主属性对码的部分依赖和传递依赖)。
      例:(S,J)→T,(S,T)→J,T→J。候选码为(S,J)、(S,T),T是决定因素,但T不包含码。
    16.第四范式4NF:限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。(不要求)
    17.一个低一级范式的关系模式可以通过模式分解转换为若干个高一级范式的关系模式集合,这个过程叫做规范化
      总结:在实际应用中,最有价值的是3NF和BCNF,在进行关系模式的设计时,通常分解到3NF就可以了。

    作者: AlvinZH

    出处: http://www.cnblogs.com/AlvinZH/

    本人Github:https://github.com/Pacsiy/JobDu

    本文版权归作者AlvinZH和博客园所有,欢迎转载和商用,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

  • 相关阅读:
    postgresql 高可用 etcd + patroni 之八 haproxy + keepalived
    postgresql 高可用 etcd + patroni 之七 haproxy
    postgresql 索引之 gin
    postgresql 索引之 btree
    postgresql 物理备份 barman 之 rsync/ssh backup
    postgresql 物理备份 barman 之 streaming backup
    postgresql 物理备份 barman 之 安装
    postgresql 的 .pgpass密码文件的使用
    postgresql 的 pg_hba.conf 的行记录顺序
    ubuntu 16.04 进入单用户模式
  • 原文地址:https://www.cnblogs.com/AlvinZH/p/6856298.html
Copyright © 2011-2022 走看看