关系数据库

本节要点:

  • 关系数据结构

    • 关系
    • 关系模式
    • 关系数据库
  • 关系操作
  • 关系的完整性约束

关系数据库系统是支持关系模型的数据库系统,关系数据库应用数学方法来处理数据库中的数据。按照数据模型的3个要素,关系模型由关系数据结构、关系操作集合和关系完整性约束3个部分组成。

1          关系数据结构

1.1          关系

关系模型是建立在集合代数的基础上的,这里从集合论角度给出关系数据结构的形式化定义。

1)         域(Domain

域是一组具有相同数据类型的值的集合。例:整数、实数、介于某个取值范围的整数、指定长度的字符串集合、{‘男’,‘女’}、介于某个取值范围的日期等,都可以是域。

2)         笛卡尔积(Cartesian Product

给定一组域D1D2,…,Dn,这些域中可以有相同的域。D1D2Dn的笛卡尔积为:

D1×D2×…×Dn={(d1d2,…,dn)|di?Dii=1,2,…,n

元素中每一个元素(d1d2,…,dn)叫作一个n元组(n-tuple)或简称元组(tuple)。

笛卡尔积元素(d1d2,…,dn)中的每一个值di叫作一个分量

Dii=1,2,…,n)为有限集,其基数(Cardinal number)为mii=1,2,…,n),则D1×D2×…×Dn基数M为:

示例:给出三个域:

D1=SUPERVISOR ={ 张清玫,刘逸 }

D2=SPECIALITY={计算机专业,信息专业}

   D3=POSTGRADUATE={李勇,刘晨,王敏}

D1D2D3的笛卡尔积为:

D1×D2×D3 ={(张清玫,计算机专业,李勇),(张清玫,计算机专业,刘晨),(张清玫,计算机专业,王敏),(张清玫,信息专业,李勇),(张清玫,信息专业,刘晨),(张清玫,信息专业,王敏), (刘逸,计算机专业,李勇),(刘逸,计算机专业,刘晨),(刘逸,计算机专业,王敏),(刘逸,信息专业,李勇),(刘逸,信息专业,刘晨),(刘逸,信息专业,王敏)}

(张清玫,计算机专业,李勇)叫做一个元组;

张清玫叫做一个分量;

基数为2×2×3=12,即D1×D2×D3共有2×2×3=12个元组。基数可以理解为里面有多少个元素。

笛卡尔积可表示为一个二维表。表中的每行对应一个元组,表中的每列对应一个域。如D1×D2×D3的笛卡尔积:


SUPERVISOR


SPECIALITY


POSTGRADUATE


张清玫


计算机专业


李勇


张清玫


计算机专业


刘晨


张清玫


计算机专业


王敏


张清玫


信息专业


李勇


张清玫


信息专业


刘晨


张清玫


信息专业


王敏


刘逸


计算机专业


李勇


刘逸


计算机专业


刘晨


刘逸


计算机专业


王敏


刘逸


信息专业


李勇


刘逸


信息专业


刘晨


刘逸


信息专业


王敏

3)         关系(Relation

D1×D2×…×Dn的子集叫作在域D1D2,…,Dn上的关系,表示为RD1D2,…,Dn

R关系名

         n关系的目或度(Degree)

关系中的每个元素是关系中的元组,通常用t表示。

n=1时,称该关系为单元关系(Unary relation)。

n=2时,称该关系为二元关系(Binary relation)。

关系是笛卡尔积的有限子集,所以关系也是一个二维表,表的每行对应一个元组,表的每列对应一个域。关系中不同列可以对应相同的域,为了加以区分,必须对每列起一个名字,称为属性(Attribute)。n目关系必有n个属性。

若关系中的某一属性组的值能唯一地标识一个元组,则称该属性组为候选码(Candidate key)。

若一个关系由多个候选码,则选定其中一个为主码(Primary key)。

候选码的诸属性称为主属性(Prime attribute)。不包含在任何候选码中的属性称为非主属性(Non-prime attribute)或非码属性(Non-key attribute)。

在最简单的情况下,候选码只包含一个属性。在最极端的情况下,关系模式的所有属性组是这个关系模式的候选码,称为全码(All-key)。

一般来说D1×D2×…×Dn的笛卡尔积是没有实际语义的,只有她的某个子集才有实际含义。

基本关系应具有以下6条性质:

  • 列是同质的
  • 每个列对应一个属性名,属性名不重复,多个列可对应一个域
  • 列的顺序无所谓
  • 任意两个元组的候选码不能相同
  • 行的顺序无所谓
  • 分量必须是原子值(不能再有分量)

1.2          关系模式

在数据库中药区分型和值。关系数据库中,关系模式是型,关系是值。关系模式是对关系的描述。

关系的描述称为关系模式(Relation Schema)关系模式可以形式化地表示为:

RUD,dom,F

                   R     关系名

                   U     组成该关系的属性名集合

                   D     属性组U中属性所来自的域

dom   属性向域的映象集合

                   F     属性间的数据依赖关系集合

关系模式通常可以简记为R (U) 或 R (A1A2,…,An)

R   关系名

 A1A2,…,An      属性名

如:学生(学号,姓名,性别,年龄,班级)

 

1.3          关系数据库

在关系模型中,实体以及实体间的联系都是用关系来表示的。在一个给定的应用领域中,所有实体及实体之间联系的关系的集合构成一个关系数据库。

关系数据库也有型和值之分。关系数据库的型也称为关系数据库模式,是对关系数据库的描述。关系数据库的值是这些关系模式在某一时刻对应的关系的集合。

2          关系操作

关系模式由关系数据结构、关系操作集合和关系完整性约束三部分组成。下面关系操作的一些基本操作和分类。

关系模型给出了关系操作的能力的说明,但不对RDBMS语言给出具体的语法要求,也就是说不同的RDBMS可以定义和开发不同的语言来实现这些操作。

1)         基本的关系操作

关系模型中常用的关系操作包括查询(Query)操作和插入(insert)、删除(Delete)、修改(Update)操作两大部分。

关系的查询表达能力很强,是关系操作中最主要的部分。查询操作又可以分为:选择(Select)、投影(Project)、连接(Join)、除(Divide)、并(Union)、差(Except)、交(Intersection)、笛卡尔积等。

关系操作的特点是集合操作方式,即操作的对象和结果都是集合。

2)         关系的语言分类

  • l  关系代数语言 例如ISBL
  • l  关系演算语言
    • 元组关系演算语言 例如APLHA,QUEL
    • 域关系演算语言 例如QBE
  • l  具有关系代数和关系演算双重特点的语言 例如SQL

关系代数是用对关系的运算来表达查询要求的。关系演算是用谓词来表达查询要求的。关系演算又可按谓词变元的基本对象是元组变量还是域变量分为元组关系演算和域关系演算。SQL是介于关系代数和关系演算之间的结构化语言,SQL不仅具有丰富的查询功能,而且具有数据定义和数据控制功能,是集查询、DDL、DML和DCL于一体的关系数据语言,它充分体现了关系数据语言的特点和优点,是关系数据库的标准语言。

3          关系完整性约束

关系模型的完整性规则是对关系的某种约束条件,这些约束条件实际上是现实世界的要求,用来满足数据的正确性、有效性和相容性。关系模型中有三类完整性约束:实体完整性、参照完整性和用户定义的完整性。

1)         实体完整性(Entity Integrity)

若属性A是基本关系R的主码中的属性,则属性A不能取空值。空值就是“不知道”或“不存在”的值。空值一般用null表示,不同于0或空串

关系模型必须遵守实体完整性规则的原因:一个基本表通常对应现实世界的一个实体集。现实世界中的实体和实体间的联系都是可区分的,即它们具有某种唯一性标识。相应地,关系模型中以主码作为唯一性标识。主码中的属性即主属性不能取空值。

2)         参照完整性

在关系模型中实体及实体间的联系都是用关系来描述的,因此可能存在着关系与关系间的引用。

例1  学生实体、专业实体以及专业与学生间的一对多联系

学生(学号,姓名,性别,专业号,年龄)

    专业(专业号,专业名)

这两个关系之间存在着属性的引用,即学生关系引用了专业关系的主码“专业号”。显然,学生关系中的“专业号”值必须是确实存在的专业的专业号,即专业关系中有该专业的记录。也就是说,学生关系中的某个属性的取值需要参照专业关系的属性取值。

例2  学生、课程、学生与课程之间的多对多联系

学生(学号,姓名,性别,年龄,系)

课程(课程号,课程名,学分,先行课)

选修(学号,课程号,成绩)

这3个关系之间也存在着属性的引用,即选修关系引用了学生关系的主码“学号”和课程关系的主码“课程号”。

不仅两个或两个以上的关系间可以存在引用关系,同一关系内部属性间也可能存在引用关系。

例3 在学生(学号,姓名,性别,专业号,年龄,班长)关系中,“学号”属性是主码,“班长”属性表示该学生所在班级的班长的学号,它引用了本关系“学号”属性,即“班长”必须是确实存在的学生的学号。

这三个例子说明关系与关系之间存在着相互引用,相互约束的情况。

引用分析:

  • 引用发生在两个表之间或一个表内部
  • 分别称为被引用表和引用表
  • 被引用列和引用列是同质的(一般同名)
  • 被引用列是主码
  • 引用列称为外码

F是关系R的一个或一组属性,但不是关系R的码。如果F与关系S的主码Ks相对应,则称F是关系R外码,关系R为参照关系(Referencing Relation)关系,S为被参照关系(Referenced Relation)或目标关系(Target Relation)。

  • 关系RS不一定是不同的关系
  • 目标关系S的主码Ks 和参照关系的外码F必须定义在同一个(或一组)域上
  • 外码并不一定要与相应的主码同名,当外码与相应的主码属于不同关系时,往往取相同的名字,以便于识别

若属性(或属性组)F是关系R的外码它与关系S的主码Ks相对应(关系RS可是一个关系),则对于R中每个元组在F上的值必须为:

  • · 或者取空值(F的每个属性值均为空值)
  • · 或者等于S中某个元组的主码值。

例1:学生关系中每个元组的“专业号”属性只取下面两类值:

(1)空值,表示尚未给该学生分配专业

(2)非空值,这时该值必须是专业关系中某个元组的“专业号”值,表示该学生不可能分配到一个不存在的专业中

例2 :选修(学号,课程号,成绩)

“学号”和“课程号”是选修关系中的主属性,按照实体完整性和参照完整性规则,它们

只能取相应被参照关系中已经存在的主码值

例3 :学生(学号,姓名,性别,专业号,年龄,班长)

“班长”属性值可以取两类值:

(1)空值,表示该学生所在班级尚未选出班长,或该学生本人即是班长;

(2)非空值,这时该值必须是本关系中某个元组的学号值

3)         用户定义的完整性

用户定义的完整性是针对某一具体关系数据库的约束条件,反映某一具体应用所涉及的数据必须满足的语义要求。

例:课程(课程号,课程名,学分)

  • “课程名”属性必须取唯一值
  • 非主属性“课程名”也不能取空值
  • “学分”属性只能取值{1,2,3,4}

关系模型应提供定义和检验这类完整性的机制,以便用统一的系统的方法处理它们,而不要由应用程序承担这一功能。

时间: 2024-12-16 06:02:13

关系数据库的相关文章

关系数据库&&NoSQL数据库

在过去,我们只需要学习和使用一种数据库技术,就能做几乎所有的数据库应用开发.因为成熟稳定的关系数据库产品并不是很多,而供你选择的免费版本就更加少了,所以互联网领域基本上都选择了免费的MySQL数据库.在高速发展的WEB2.0时代,我们发现关系数据库在性能.扩展性.数据的快速备份和恢复.满足需求的易用性上并不总是能很好的满足我们的需要,我们越来越趋向于根据业务场景选择合适的数据库,以及进行多种数据库的融合运用. 当我们在讨论是否要使用NoSQL的时候,你还需要理解NoSQL也是分很多种类的,在No

MongoDB是一个介于关系数据库和非关系数据库之间的产品

MongoDB是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的.他支持的数据结构非常松散,是类似json的bjson格式,因此可以存储比较复杂的数据类型.Mongo最大的特点是他支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引.它的特点是高性能.易部署.易使用,存储数据非常方便. MongoDB[1]的主要目标是在键/值存储方式(提供了高性能和高度伸缩性)以及传统的R

关系数据库的几种设计范式介绍

关系数据库的几种设计范式介绍1.第一范式(1NF) 在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库. 所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性.如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系.在第一范式(1NF)中表的每一行只包含一个实例的信息.例如,对于图3-2 中的员工

关系数据库小小基础

什么是关系型数据库: 关系型数据库基于关系模型,关系模型是通过二维表保存实体和实体间的关系,所以关系型数据库存储的是由行和列组成的表,每张表可以看作一个实体集,实体之间是有关系的,多张表组成数据库 为什么需要关系模型: 以前数据的逻辑结构有,层次型.网状型,能很好地解决存储的问题,但层次型处理对象间的关系比较麻烦,网状型维护复杂,且查询时需指定类型和路径,所以出现了关系模型 关系型数据表示形式 一个文件在linux文件系统中的表现形式是这样的 表示层:文件形式 逻辑层:文件系统(作为一个中间的映

关系数据库范式粗略理解

粗略看了一下关系数据库范式介绍,简单记录一下自己的理解 第一范式:指属性达到原子性,即属性不可再进行分割了.例如一张person 表,其中有个字段是个人信息p_info,这个个人信息可再分割成姓名,性别,年龄三个字段.那么person这张表就没有达到第一范式,应把个人信息分解成姓名,性别,年龄之后才算达到第一范式. 第二范式:指在达到第一范式的基础上,非主属性完全函数依赖于主属性,就好比表中设了主键,主键之外的属性完全依赖于主属性.完全函数依赖指 x决定y,但是x的任意一个子集都不能决定y.即若

yii关系数据库多表查询

两个表的model继承自CActiveRecord class User extends CActiveRecord class Post extends CActiveRecord 很明显,User和Post是一对多的关系 在两个Model中覆盖relations方法 //class Post public function relations() { return array( 'author'=>array(self::BELONGS_TO, 'User', 'id') ); } // 格

如何将Bitcoin比特币区块链数据导入关系数据库

在接触了比特币和区块链后,我一直有一个想法,就是把所有比特币的区块链数据放入到关系数据库(比如SQL Server)中,然后当成一个数据仓库,做做比特币交易数据的各种分析.想法已经很久了,但是一直没有实施.最近正好有点时间,于是写了一个比特币区块链的导出导入程序. 之前我的一篇博客:在区块链上表白——使用C#将一句话放入比特币的区块链上  介绍了怎么发起一笔比特币的交易,今天我们仍然是使用C#+NBitcoin,读取比特币钱包Bitcoin Core下载到本地的全量区块链数据,并将这些数据写入数

NoSQL数据库探讨之一 - 为什么要用非关系数据库?

随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域,非关系数据库产品的发展非常迅速.而传统的关系数据库在应付 web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,例如: 1.High performance - 对数据库高并发读写的需求 web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以基本上无法使用动态页面静态化技术,因此数据库并发负载非常高,往 往要达到每秒上万次读写请求.

SQLite关系数据库

---------------------- 存储数据- SQLite关系数据库 ---------------------- SQLite 关系数据库 1.导入: 数据库-build phases -link binary with libraries -+libsqlite3.dylib 2.#import <sqlite3.h> 3.@interface ZYViewController () { sqlite3 *_db; } @end ------------------------