电子科大数据库第四章:数据库设计与实现

第四章 数据库设计与实现

4.1 数据库设计概述

4.1.1 数据库设计方案

在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

1、概念数据模型(CDM)

一种面向用户的系统数据模型,用来描述现实世界的系统概念化数据结构

2、逻辑数据模型(LDM)

在概念模型的基础上,从系统设计的角度描述系统的数据对象组成及关联结构,考虑这些数据对象符合数据库的逻辑表示

3、物理数据模型(PDM)

在逻辑数据模型基础上,针对具体的DBMS所设计的数据模型。
在这里插入图片描述

4.1.2 数据库设计过程与策略

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

4.2 E-R模型

E-R模型(实体-联系模型):一种描述现实世界概念数据模型,逻辑数据模型的有效方法。

4.2.1 模型基本元素

实体 属性 标识符 联系
标识符可以是一个或多个属性
在这里插入图片描述

在这里插入图片描述

4.2.2 实体-联系类型

1、二元实体联系类型
  1. 1:1 1:N N:M
  2. 最小基数,最大基数
  3. 可选 强制
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
2、鸟足版本

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

3.实体继承联系
  1. 父实体:具有公共属性的实体
  2. 子实体:与父实体具有相似的属性,同时也具有特殊性的实体
  3. 互斥性继承
  4. 非互斥型继承
  5. 完整性继承
  6. 非完整性继承
    在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

4.2.3 强弱实体

  1. 强弱实体是相对的
  2. 强实体
  3. 弱实体
  4. id依赖型:强的标识符作为弱的标识符
  5. 非id依赖型:有自己的标识符
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

4.3 数据库建模设计

4.3.1 概念数据模型设计:E-R

在这里插入图片描述

4.3.2 数据库模型的转换

在这里插入图片描述

CDM/LDM到PDM的转换------>E-R模型到关系模型的转换

原理:

  1. 实体—>表:属性名,数据类型,键,not null/null
  2. 属性—>列
  3. 实体标识符—>外键或主键
  4. 实体之间的联系—>关系表之间的参照完整性约束
1、实体转换成表:添加数据类型,键,not null/null

在这里插入图片描述

2、强弱实体转换
  1. id依赖型:强实体的主键用来做弱实体的主键和外键
  2. 非id依赖型:强实体的主键做弱实体的外键
    在这里插入图片描述

在这里插入图片描述

3、实体联系转换参照完整性约束
(1)1:1------> 主键可以相互做外键

在这里插入图片描述
在这里插入图片描述

(2)1:N ---->1的主键放到N里做外键

在这里插入图片描述

(3)M:N 添加一个新的关联表,把两者的主键放到这个新的表里做外键和主键

在这里插入图片描述

4、实体继承联系参照完整性约束

父的主键放到子的里面做主键和外键
在这里插入图片描述

5、实体递归联系转换参照完整性约束
(1) 1:N 实体递归联系:标识符再写一个换个名字,作为外键

在这里插入图片描述

(2) M:N 实体递归联系:增加一个关联表,标识符和标识符的改写作为主键和外键

在这里插入图片描述

4.4 数据库规范化设计

4.4.1 非规范化关系表的问题

为什么要规范化数据库处理?

  1. 减少数据库中冗余数据,尽量使用同一数据在数据库中仅保留一份,有效降低维护数据一致性的工作量
  2. 设计和里的表间依赖关系和约束关系,便于实现数据完整性和一致性
  3. 设计合理的数据库结构,便于系统对数据高效访问处理

4.4.2 函数依赖理论

1、函数依赖:

数据依赖的一种,反应属性或属性组之间相互依存,相互制约的关系,即反应现实世界的数据约束关系
定义的符号

  1. R:一个关系的模式
  2. U={A1,A2…An} :R的所有属性的集合
  3. F:R中函数依赖的集合
  4. r:R所取的值
  5. t[x]:元组t在属性X上的取值
    函数依赖的定义:
    一个关系模式 R(U),X,Y是属性U的子集,t,s是关系R中任意两个元组,如果t[X]=s[X],则t[Y],s[Y],。就说Y函数依赖于X,或X函数决定Y。
    也就是Y的属性由属性X决定
    如:学生表中:专业,宿舍位置, 这两个属性,就是专业决定宿舍位置
2、部分函数依赖:

如:成绩表中:主键是学号和科目,还有属性 教课的老师。科目决定教课的老师。所以是部分函数依赖。

在这里插入图片描述

3、属性传递依赖

学生表中: 学号决定专业,专业决定宿舍位置,所以学号决定宿舍位置,所以是传递依赖
在这里插入图片描述

4、多值依赖

在这里插入图片描述

4.4.3 规范化设计范式

1、范式

关系规范化:把一个有访问异常的关系分解成结构良好的关系的过程,使得这些关系有最小的冗余或没有冗余。
**规范化范式:**关系表符合特定规范化程度的模式

  1. 第一范式(1NF):属性不可再分

  2. 第二范式(2NF):1NF的基础上,消除了属性部分依赖。
    在这里插入图片描述

  3. 第三范式(3NF):第二范式的基础上,切断了属性传递函数依赖
    [图片]

  4. BCNF(巴斯-科德范式):所有函数依赖的决定因子都是候选键
    [图片]

  5. 第四范式(4NF):满足BCNF,并且消除了多值依赖
    [图片]

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值