四级数据库_05_逻辑设计

第五章 关系数据库逻辑设计

四级数据库 返回到 『四级数据库』

5.1 概述

5.2 基本概念

5.2.1 关系模型

  • 关系模型采用一个二维表格在计算机中组织、存储、处理和管理数据。
    • 关系名(数据库名):由字母数字组成;
    • 属性名;
    • 关系模式 和 关系:描述模式描述关系的静态结构,由模式名、关系模式所包含的属性及属性值所满足的条件组成模式定义。
    • 元组:描述关系中的
    • 域:它定义关系的每个属性取值的类型;
    • 主码:能够惟一标识关系中每一个元组的属性或属性组;

    • 关系的数学定义:关系模式是建立在集合集论的基础上的,用数学的概念定义关系有;

      • 定义一:域是值的集合,同一个域中的值具有相同的数据类型
      • 定义二:笛卡尔积的定义(相当于一张二维表)
      • 定义三:关系的定义(笛卡尔积的子集(二维表),域的顺序不能改)

      • 当关系引用了属性名后, 关系具有以下属性:

[1] 不能有重复的元组

[2] 元组上下无序

[3] 按属性名引用时, 属性左右无序

[4] 所有属性值都是原子项(不可再分);


  • 总结:

  • 关系是一张二维表,
  • 表中的一行被称为一个元组;
  • 一列称为属性,由一组域值组成。
  • 关系是元组的集合,关系中的每个元组在数学上, 被定义为:
  • 这个关系所涉及的全部域值中  笛卡儿积 的一个元素。

5.2.2 关系数据库

  • 关系数据库是按照二维表组织和存储的相互关联的  关系的集合,关系数据库模式  是   关系模式的集合;

5.2.3 关系的完整性

  • 关系的完整性(完整性约束):是对关系的某种约束规则  和  关系满足的定义。通常这组约束规则用来限定检查数据库所含实例的合法性正确性
  • 完整性约束分静态动态两种,静态完整性(相当于逻辑的,真理的)约束是基于关系模式的,主要有主码、外码约束和约束组成;
  • 动态完整性约束(基于现实)是基于企业的业务规则的。

  • 静态完整性约束规则:

    • 主码约束:主码必须满足:
      • 惟一性:在一个关系中不存在两个元组,它们具有相同的主码值;
      • 最小性:不存在从组成主码的属性集中  去掉一个属性,还仍能保持数据的惟一性;

候选码:符合主码条件,但没有被选为主码。

  • 外码约束:(外码的定义:有两个关系User和School,School_ID是User的属性组,非码;是School的码,则称School_ID是User得外码)外码为空或码的值(否者查找失败)
  • 用户定义的完整性:(例如: 性别只为男和女)

5.3 关系数据库设计理论

5.3.1 问题的提出

究竟一个关系数据库包含哪些属性是合理的,如何评价一个关系模式设计的优劣?(插入、更新、删除异常)


补充(关系代数)

  • 传统的集合运算。(并、交、差、笛卡尔积);
  • 专门的关系运算。(选择、投影、连接、自然连接、除法)

5.3.2 函数依赖

函数依理论利用一个关系中属性之间的依赖关系评价和优化  关系模式,以保证存储到数据库中的关系具有较好特性;

  • 函数依赖  详细定义:
    • 设R(U)为一关系模式,X和Y  为属性全集U的子集;
    • 若对于R(U)的任意一个可能的关系r,r中  不可能存在  两个元组  在X上的属性值相等,而在Y上的属性值不等,则称“X函数决定Y”或“Y函数依赖于X”,并记作XY
    • 其中X称为决定因素,因为根据函数依赖定义,给定一个X,就能惟一决定一个Y。
    • (说人话就是:只要X上的属性值相等,则Y上的属性只就相等
    • 这里讨论的函数关系与数学上的不同,是不能计算的,是一个关系中属性之间存在的依赖关系
    • 它是一种语义范畴的概念,只能根据两个属性之间的语义来确定一个函数依赖是否存在。

  • 函数依赖  分类:

  • 完全(f)与部分函数(p)依赖:
    • 在关系模式R(U)中,如果XàY成立,并且对X的任何真子集X’都不能函数决定Y,则称Y对X是完全函数依赖,被记作X—f—àY
    • 若XàY,但Y不完全函数依赖于X,则称Y对X是部分函数依赖,记作X–pàY
    • (即至少存在一个真子集X’函数决定Y);

  • 传递函数依赖:

在关系R(U)模式中,如果X决定Y,(Y不属于X,Y也不决定X),但Y是能决定Z的,则我们称Z对X传递函数依赖


  • 平凡非平凡 函数依赖:

    • 若X决定Y,但Y本身就是属于X的,则称XàY平凡函数依赖,否则称非平凡函数依赖
    • 即平凡函数依赖,仅当其右边的属性集是左边属性集的子集时成立;(全属于)
    • 非平凡函数依赖,仅当其右边的属性集至少有一个属性不属于左边的集合时成立;(部分)
    • 完全非平凡函数依赖:仅当其右边的属性集  中的 属性  都不在左边的集合时成立;(都不属于)
  • 码:

    • 在关系模式R(U)中,K为R的属性属性组,若K完全函数决定A2….An,则K为关系模式R的候选码(应理解为一个属性组),包含在候选码中的属性称为主属性,否则为非主属性

    • 若一个关系的候选码不止一个,则选定其中一个作为关系R的主码

    • 关系的码属性  除了  必须完全函数决定关系的所有其他属性外,还必须满足最小化规则
    • 即在关系模式R(U)中,不存在一个K的真子集能够函数决定R的其他属性。

  • 函数依赖的推理规则:(Armstrong公理及推论)什么鬼???

    • 自反律:若Y(包含于)X(包含于)U,则 X à 成立;
    • 增广律:若XàY,且Z(包含于)U,则 XZ à YZ 成立;
    • 传递律:若XàY,YàZ,则XàZ成立;

推论

  • 合并规则:若XàY,XàZ成立,则XàYZ
  • 分解规则:若XàY和Z(包含于)Y成立,则XàZ也成立;
  • 伪传递规则:若XàY,YWàZ,则XWàZ成立;

  • 属性集闭包:

    • 设F是属性集U上的函数依赖集,X为U的一个子集,那么对于F,属性集X关于F的闭包(用X+表示)为:X+={A|XàA}(最大的Y的集合)
    • 属性集闭包的定义可知,若想判断函数依赖XàY是否成立,只要计算X关于函数依赖集F的闭包,若Y是X闭包中的一个元素则XàY成立;

  • 确定关系的码:

    • 利用迭代算法计算X+,步骤如下:
      • 选X作为闭包X+的初值X(0);
      • 由X(i)计算X(i+1)时,它是由X(0)并上 属性集合A所组成,
      • 其中A满足下列条件:
      • Y(包含于)X(i),且F中存在 函数依赖YàZ,而A(包含于)Z。
      • 因为U是有穷的,所以会得到X(i)=X(i+1),此时X(i)为所求的X+。

5.3.3 规范化设计方法

  • 第一范式:
    • 定义:设关系模式R(F,U),如果R的每一个属性都是不可分的数据项,则此关系模式为第一范式;
    • 一个给定关系和第一范式(1NF)的区别:
      • 一个关系中的数据按照行和列的形式组织,每个元组具有相同数目的属性个数,且每一个元组的属性值具有统一的数据类型和长度;元组或属性的排列与顺序无关,每个元组必须通过一个属性或属性组惟一识别;
      • 第一范式实际上对关系增加了一个约束,即关系中元组的每个属性都只取一个值
      • 第一范式是对关系模式的基本要求,不满足第一范式的数据库就不是关系数据库。

    • 第二范式:

      • 定义:若关系模式R(F,U)是1NF,且每个非主属性完全函数依赖于,则称R为第二范式,即在2NF中不存在非主属性部分依赖
      • 仅满足第一范式关系会存在种种问题,要消除必须用更高级的范式标准来设计,称为标准化;
      • 具体做法是将大的关系分解成多个小的关系,使分解后的关系满足更高级范式的要求。
      • 第二范式实际上对关系增加了一个约束,就是关系中的每一个属性必须完全依赖于主码(造成分表),即在第一范式的基础上,消除非主属性主码部分函数依赖可达到2NF;

    • 第三范式:

      • 定义:若关系R(U,F)为第一范式,且不存在非主属性主码传递函数依赖,则称R为第三范式;
      • 第三范式是在第二范式的基础上对关系又增加了一个约束,
      • 那就是关系中的每一个非主属性必须只依赖于主码
      • 即2NF的基础上,消除非主属性对主码的传递函数依赖可达到3NF。

    • 改进的第三范式(BCNF):

      • 定义:如果关系模式R是1NF,且每个属性既不存在部分函数依赖也不存在传递函数依赖候选码,则称R是改进的第三范式(BCNF)。

    • 多值依赖与4NF:喵喵喵???

      • 多值依赖:表示关系中  属性(如A、B、C)之间的依赖,对于A的每个值,都存在一个B或C的值的集合,而且B和C的值相互独立,记为:AààB、AààC
      • 第四范式:如果关系模式R属于1NF,对于R的每个非平凡的多值依赖XàY(Y不属于X),X含有候选码,则R是第四范式。
      • 即是从BCNF范式中消除主码内的独立依赖集(非平凡多值依赖)可达4NF;

    • 连接依赖与5NF: 喵喵喵???

      • 连接依赖:设关系模式R,R的属性子集为R1、R2、R3、R4、R5、R6、R7….,当且仅当  R的每个合法值等于R1、R2、R3、R4、R5、R6、R7…的投影连接时,称R满足连接依赖;
      • 第五范式:设R是一个满足5NF的关系模式,当且仅当R的每一个非平凡连接依赖都被R的候选码所蕴含,即从4NF中消除非候选码所蕴含的连接依赖为5NF;

    • 总结:

      • 范式表达了关系模式满足的条件,也是衡量关系模式设计优劣的标准;
      • 利用范式进行规范化设计的目的是消除数据冗余,避免出现异常,使结构更合理;
      • 规范化设计的基本过程是对关系进行的分解,消除属性间不合理的数据依赖,用一组等价的子关系代替原有的关系;
      • 数据库规范化的程序越高,其关系表就越多,从而增加了表之间连接运算的代价,影响了数据库的执行速度和性能。
      • 所以通常关系模式规范化工作仅做到3NF,这样既使关系中不合理的属性基本消除,规范化程度也不太高,保证数据库有较好的性能。

5.4 数据库模式设计

5.4.1 初始关系模式的设计

  • 把ER图转换成关系模式
    • 把ER模型中的每个实体集转换成一个同名的关系,实体集的属性就是关系的属性,实体集的就是关系的
    • 把ER模型中的每个联系转换成一个关系,与该联系相连的各实体集的以及联系的属性转换成为关系的属性
      • 若联系为1:1,则每个实体集的均是该关系的候选码
      • 若联系为1:n,则关系的码为n端实体集的
      • 若联系为m:n,则关系的码为各实体集的组合;
    • 合并具有相同码的关系
  • 检查确认对象:检查转换后的每个关系名属性名是否符合数据库设计关于统一命名的约定;

5.4.2 优化关系模式

  • 模式分解原则:
    • 分解具有无损连接性:分解后的关系能够恢复成原来的关系;
    • 分解保持函数依赖
      • 无损连接保持函数依赖是用于衡量一个模式分解是否导致原有模式中部分信息丢失的两个标准;
      • 当一个关系被分解后会出现几种结果,既有无损连接,又能保持函数依赖是较理想的分解结果,意味着在分解的过程中没有丢失原有模式的任何信息;
      • 一般情况下,分解到3NF就足够了,但在3NF关系下,仍存在一定程度上的更新异常不一致的隐患,但与数据库性能比较起来是可以忽略的,因为在数据库设计过程中通过增加一些数据约束,就可以解决3NF引起的数据问题了。
    • 优化属性:确定各字段的类型和长度;
    • 确认模式满足需要:

5.4.3 数据完整性设计

  • 指  定义数据库中  存储的数据值满足的约束条件,通过存储的数据值的约束维护关系的完整性。
  • 数据值满足条件分为:
    • 域约束:限制指定列的取值及范围;
    • 主码约束:定义每个关系的主码值不空,且惟一;
    • 引用完整性约束:定义不同模式的  属性间  满足的条件,及一个关系模式中  属性间  可能满足的条件;

5.4.4 安全模式和外模式的设计

  • 根据选定的DBMS支持的安全控制特征来确定;

根据不同用户对数据库存取特点定义相关的外模式