关系型数据库基础知识

看这篇文章之前建议大家可以看看数据库系统这篇文章,因为我们数据库不仅仅是关系型数据库,希望大家看数据库系统这篇文章后,可以知道关系型这个概念处于一个什么位置。数据库系统
至于我写这篇关系型数据库基础知识的文章,主要是为了关系型数据库设计这篇文章做铺垫。希望大家看完关系型数据库后,有兴趣可以了解一下关系型数据库的设计,设计出一个关系数据库。关系数据库设计步骤

在这里插入图片描述

数据库的设计

多表之间的关系

  • 一对一
    例如:身份证和人
    实现关系:在任意的一方添加唯一(unique)外键,指向另外一方的主键,一般情况下把一对一合成一张表。

  • 一对多,多对一
    例如:部门和员工
    实现关系:在多的一方建立外键,指向一那方的主键,建立两张表的关系。

  • 多对多
    例如:学生和课程表
    实现关系:完成多对多需要中间表,中间表最少包含两个字段,这两个字段作为中间表的外键分别指向两张表的主键,中间表的一对数据称为联合主键。两个数据在一起是惟一的。
    在这里插入图片描述

  • 案例练习
    旅游网站里面假设三张表,一张是线路的分类(例如:西安、北京…),一张是旅游线路表(例如:西安城墙、西安兵马俑,北京故宫,北京长城、、、),第三张表是用户表(用户名,用户id,用户收藏的旅游线路)。
    下来我们分析这三个实体对应关系:

数据库完整性

  • 数据库完整性指数据的相融性和数据的正确性。

正确性:正确性是指数据符合现实世界的语义,反映了当前的实际状况。
例如:学生的学号必须唯一,性别只能是男或者女,
相容性:是指数据库中同一对象在不同的关系表中的数据是符合逻辑的。
例如:学生所选择的课程必须是学校已经开设的课程,学生所在院系必须是学校已经成立的院系。

  • 为了维护数据库完整性,DBMS必须要:(三个组成部分)

提供定义完整性约束条件的机制
提供完整性检查的方法
违约处理

  • 提供定义完整性约束条件的机制

完整性约束条件也称为完整性规则,是数据库中的数据,必须满则的语义约束条件。
sql使用一系列概念来描述完整性,包括关系模型的实体完整性,用户定义完整性,参照完整性。
这些完整性一般有sql的数据定义语言来实现,它们作为数据库模式的一部分存入数据字典中。

  • 提供完整性检查机制

数据库系统检查数据库是否满足数据库完整性条件约束条件的的机制称为完整性检查
一般在insert,update,delete之后检查,也可也会在事务提交之后进行检查。

  • 违约处理

数据库当发现违背完整性约束的条件,就采取一定的操作。
1:拒绝操作:拒绝执行
2:级联操作:系统先执行其他操作,去除约束条件。级联操作主要针对外检表进行的一种违约处理方式,不指定情况下系统默认的违约处理方式是拒绝,级联操作需要我们我们去指定操作。

  • 数据库系统DBMS是怎样自动保证完整性
    DBMS允许用户定义一些完整性约束
    当有DB更新操作,DBMS自动按照完整性约束进行检查,以确保更新操作符合语义完整性。
    在这里插入图片描述
  • 为什么引发数据库完整性问题
    在这里插入图片描述
    针对上面为什么引发数据库完整性问题,我们有下面对于关系模型的三大要求实体完整性、参照完整性、用户自定义完整性。其实前两个也是用户定义的。我们定义一些规则去规范我们表。

三类完整性

  • 引入
    对于数据库我们将完整性分为两大类,广义完整性、狭义完整性;而狭义完整性特指语义完整性。
    在关系模型中我们对完整性三大要求:实体完整性、参照完整性、用户自定义完整性。

为了讲清楚完整性概念我们引入一些概念来帮助理解。例如完整性约束规则。然后基于完整性约束规则,我们将完整性有进行了分类。例如我们按约束对象进行分类,将完整性分为域完整性约束和关系完整性约束;我们按状态进行分类,分为静态完整性约束和动态完整性约束。当然这些都是概念,最后我们讲sql语句中完整性怎样体现的。
说到这里我们可能有些懵,大家可以查看这篇文章我的思维导图,看一些我刚才举例的名词处于一个什么位置。其实我们主要讲就是关系模型中对完整性三大要求,后面哪些完整性约束之类,只是为了让大家更好理解。下面我会慢慢给大家讲解。

  • 完整性约束规则
    在这里插入图片描述
    完整性约束规则为我们制定了一个规则,对O对象;在A条件下触发;DBMS检查P条件;当P条件不满足R响应。具体我们应用到完整性中大家就会理解。我们运用完整性约束条件来规定我们具体运用中怎样去约束。

  • 完整性三个要求和完整性约束的关系。
    我们对于关系数据结构完整性有三个要求。但是这三个要求前两个实体完整性和参照完整性如果单独说是完全可以说清的,实体完整性就数据库中任何一个实体都要有其唯一的标识,运用到sql语句中,我们就是给一个表的一列定为主码;而参照完整性就是一个表中一列和另一个表中一列关联;对于用户自定义完整性就有好几种情况,非空,唯一,检查约束;很多书中将三个要求分开进行讲解举例,MOOC中看了哈工大老师的课,他通过完整性约束规则这个东西将三个要求可以讲通,可以理解为完整性约束规则是公式,可以用这个公式去解释三个要求。下面通过完整性约束条件分类,给大家彻底讲一下。

  • 数据库完整性约束条件分类

  1. 如果按照约束对象进行分类,可以分为域完整性约束条件和关系完整性约束条件。
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    上面我们看到按照完整性约束条件,我们进行了分类,但是分类只是分类,这些对视概念。关键我们怎样将完整性运用到sql语言中。下面我们要讲就是sql语言所支持的完整性约束条件,及其具体实现。

sql语言实现数据库的静态约束和动态约束

在这里插入图片描述

sql实现静态约束

在这里插入图片描述

  • 列&表
    我们看到完整性约束条件中,约束对象O是列或者表。列我们自然不必说,就是一列;表我们可以理解成多列,这里多列意味着约束对象涉及到多列,例如参照完整性,一个表中一列依赖于其它表中一列,那么就涉及到两列,那么就是表。

这里我们就可以引出完整性三个要求啦。

  • 实体完整性
    在现实世界中任何一个实体都有都有区别于其他实体的特征,在数据库中任何一个实体都要有其唯一的标识,这是实体完整性的概念。
    那我们为了具体标识,那么我们创造列约束。
    sql语言中CREATE TABLE 中用 PRIMARY KEY 来定义,就是定义猪吗来实现实体完整性,约束一列。
  • 参照完整性
    参照完整性因为牵扯到多列,那么定义为表级约束。
    若属性(或属性组)F是基本关系的外码它与基本关系的主码K相对应,则对于R中每个元祖在F上的值必须为
    1:为空
    2:或者等于S中某个元祖的主码值。
  • DBMS怎样进行实体完整性检查和违约处理

插入一个数据或者对主码进行更新DBMS要进行实体完整性规则进行检查
在这里插入图片描述
检查主码值是否唯一在关系型数据库建立索引B+树索引,检查。

  • 参照完整性

若属性(或属性组)F是基本关系的外码它与基本关系的主码K相对应,则对于R中每个元祖在F上的值必须为
1:为空
2:或者等于S中某个元祖的主码值。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

  • 用户自定义完整性
    在这里插入图片描述
    用户自定义完整性我们列值非空和列值唯一那么就是列级约束。
    另外一个就是布尔表达式check
    在这里插入图片描述
  • 断言实现约束
    在这里插入图片描述
    在这里插入图片描述

sql实现动态约束

动态约束我们利用触发器
在这里插入图片描述

函数依赖

在这里插入图片描述
在这里插入图片描述
违背函数依赖,所以下表是错误的表。
在这里插入图片描述

  • 函数依赖概念:
  1. 函数依赖不是指关系模式R的某个或某些关系实例满足的约束条件,而是指R的所有关
    系实例均要满足的约束条件。
  2. 函数依赖是语义范畴的概念。关系数据库中讨论函数或函数依赖注重的是语义上的关
    系。
    比如:省=f(城市)
    如果“城市”是自变量X,则“省”是因变量或函数值Y。并且把X函数决定Y,或
    Y函数依赖于X表示为:X→Y
  3. 数据库设计者可以对现实世界作强制的规定。例如规定不允许同名人出现,函数依赖
    “姓名→年龄”成立。所插入的元组必须满足规定的函数依赖,若发现有同名人存在,
    则拒绝装入该元组。
  • 函数依赖与属性关系
    • 设R(U)是属性集U上的关系模式,X,Y是U的子集:
    ✓如果X和Y之间是1:1关系(一对一关系)则存在函数依赖X→Y和
    Y→X ,如学号和身份证号之间就是1:1关系,学号->身份证号,身份证
    号->学号。
    ✓如果X和Y之间是m:1关系(多对一关系),则存在函数依赖X→Y ,
    如学号和班级号之间就是m:1关系,学号->班级号。
    ✓如果X和Y之间是m:n关系(多对多关系),如学号和课程号之间就是
    m:n关系,则X 和Y之间不存在函数依赖。

  • 平凡函数依赖和非平凡函数依赖
    在这里插入图片描述

  • 部分函数依赖与完全函数依赖
    在这里插入图片描述

  • 传递函数依赖
    在这里插入图片描述

  • 候选码、超码
    设K为R< U , F >的属性或属性组,若K→ U,则称K为R的超码。如果若K U(即不存在K的真子集Y,使得Y→U成立),则K是R的一个候选码。
    在这里插入图片描述
  • 主码
    主码:若R(U , F)有多个候选码,则可以从中选定一个作为R的主码(primary key)。
    在这里插入图片描述
  • 主属性、非主属性
    主属性:包含在任意一个候选码中的属性,称作主属性。
    非主属性:不包含在任何一个候选码中的属性,称作非主属性。
    在这里插入图片描述
  • 全码
    在这里插入图片描述
  • 外码
    关系模式 R 中属性或属性组 X 并非 R 的码,但 X 是另一个关系模式的码,则称 X 是 R 的外部码(Foreign key)也称外码
    • 主码和外部码一起提供了一个表示关系间联系的手段 。
    在这里插入图片描述

范式(规范化)

  • 范式是符合某一级别的关系模式的集合。
    ✓不同级别的范式要求各不相同
    ✓范式可以作为衡量一个关系模式好坏的标准
  • 关系数据库中的关系必须要满足一定的要求
    ✓若关系模式R满足范式 x NF,记R x NF
    在这里插入图片描述

第一范式

如果一个关系模式R的所有属性都是不可分的基本数据项,则称关系R为第一范式的关系模式(First Normal Form),简称关系R属于一范式,记为:R∈1NF。

  1. 第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。(由关系属性的原子性得出)。
  2. 但是满足第一范式的关系模式并不一定是一个好的关系模式。仍然存在数据冗余度大 、插入异常 、修改和删除异常。
    在这里插入图片描述

第二范式

若关系模式R∈1NF,并且每一个非主属性都完全函数依赖于R的任何一个候选码,则R∈2NF。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

第三范式

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

BC范式

学到这里我们知道前三个范式,都是消除非主属性对吗的部分函数依赖(二范式),消除非主属性对码的传递函数依赖(三范式)。前面三个范式都对于非主属性依赖的消除。
BC范式是对三范式的改进,消除主属性的部分函数依赖和传递函数依赖。
在这里插入图片描述
在这里插入图片描述

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

范式总结

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
下接
数据设计步骤

  • 0
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值