数据库基础

目录

基本知识与关系模型

基础概念

从用户角度来看数据库管理系统的功能

从系统实现角度看数据库管理系统的功能

数据库语言

数据库系统的标准结构

三级模式:

两个印象:

两个独立性:

数据模型

三大经典数据模型

其他数据模型

数据库系统的演变与发展

关系模型与关系数据库语言的关系

关系模式与关系

关系的特性

关系代数基本运算

关系代数的扩展操作

关系代数的基本书写思路

集合操作思维训练注意点

书写关系代数的基本思路

复杂扩展操作

关系演算的重难点

数据库语言--SQL

补充知识点

在SQL—92标准中定义的数据类型

其他:

SQL语言概述

主要构成

利用SQL语言建立数据库

典型DBMS交互环境简介-SQL Server

基本操作

创立Database

创立Table

向表中追加元组

检索语句Select(结构形式一致但功能多样化的检索语句)

结果唯一性问题

结果排序问题

模糊查询问题

多表联合查询

重名处理

增删改操作

撤销与修改

指定与关闭命令

复杂查询与视图

子查询

结果计算与聚集计算

分组查询与分组过滤

关系代数操作

空值的处理

连接(内连接,外连接)

视图

SQL数据库结构

定义视图

使用视图

SQL视图更新

撤销视图

SQL-SELECT小结

SQL语言与数据库完整性和安全性

数据库完整性的概念及分类

静态完整性

动态完整性

数据库安全性的概念及分类

数据建模与数据库设计

数据建模

E-R模型

1.基本概念

2.表示方法

数据库设计中的抽象

1.信息

2.型与值

3.数据模型

4.数据模型与概念模型

5.建模的不同层次

数据库设计过程

1.概述

2.概念数据库设计的可能冲突

3.从概念模式向关系模式转换:

4.基本转换规则

5.不正确设计数据库引发的问题

规范形式

主要概念

总结:

数据库管理系统实现技术


基本知识与关系模型

参考资料 关系运算:【数据库系统】关系代数之基本运算、附加运算、扩展操作_Lord_Bao的博客-CSDN博客

基础概念

数据: 描述事物的符号

数据库: 电子化信息的集合(相互之间有关联关系的表的集合

数据库管理系统(DBMS): 是管理数据库的一种系统软件,有数据定义功能(DDL);数据组织、存储和管理;数据操纵功能(DML);数据库的事务管理和运行管理;数据库的建立和维护功能;其他功能

数据库系统(DBS)(工作环境): 由数据库,数据库管理系统,数据库应用,数据库管理员和计算机基本系统五大部分构成

数据的结构:模式 对数据库中数据所进行的一种结构性的描述 所观察到数据的结构信息 展现的数据:视图/数据 某一种表现形式下表现出来的数据库中的数据 模式是视图的抽象层次,视图是模式的具现化

数据独立性是指应用程序和数据结构之间相互独立, 互不影响 不会因为系统数据存储结构与数据逻辑结构的变化而影响应用程序

关系是一个由行与列组成的、能够表达数据及数据之间联系的二维表

关系是由三个部分组成的: 基本结构:描述DB各种数据的基本结构形式 基本操作:描述Table和Table之间所可能发生的各种操作(关系运算) 完整性约束:描述这些操作缩影遵循的约束条件(完整性约束)

候选码:关系中的一个属性组,其值能唯一标识一个元组,若从该属性组中去掉任何一个属性,它就不具有这一性质了,这样的属性组称作候选码 补充:候选键可由其值能唯一标识该关系中任何元组的一个或多个属性组成 主码:当有多个候选码时,可以选定一个作为主码

主属性:包含在任何一个候选码中的属性 非主属性:除主属性以外的其他属性 特殊:全码:所有属性构成候选码

外码(外键):关系R中的一个属性组,它不是R的候选码,但它与另外一个关系S的候选码相对应,那么这个属性组是R的外码(外键) 其他关系的候选键,可以是R中的主属性或非主属性 非该关系的主键,但是是另外一个关系的主键

表有三个部分组成:表,标题、列名与列值、行/记录

实体完整性 关系的主码中的属性值不能为空值 实体能够区分并唯一标识元组

空值:值不知道、不确定、不存在的值 数据库中如果有了空值,会影响许多方面,如:聚集函数运算的正确性,不能参与算数,比较或者逻辑运算等 (在sql标准和许多六星的DBMS中,空值用一种特殊的符号null来标记,使用特殊的空值检测函数来获得某列的值是否为空值)

用户自定义完整性 用户针对具体的数据库应用所定义的完整性约束条件

参照完整性规则 表的外键必须是另一个表主键的有效值,或者是空值

实体完整性和参照完整性一般由DBMS系统自动支持

实现不同关系之间的联系是通过外键

关系代数运算的基本操作:集合操作和纯关系操作

并相容性 参与运算的两个关系及其相关属性之间有一定的对应性、可比性或意义关联性 定义:关系R和关系S存在相容性,当且仅当: 关系R和关系S的属性数目必须相同 对于任意i,关系R的第i个属性的域必须和关系S的第i个属性的域相同 注:某些关系代数操作,如并、差、交等,需满足“并相容性”

内连接 指连接结果仅包含符合连接条件的行,参与连接的两个表都应该符合连接条件

从用户角度来看数据库管理系统的功能

1.数据库定义:定义数据库中表的名称以及标题等 2.数据库操纵:向数据库的表中增加、删除、更新数据以及对数据进行查询,检索,统计等 3.数据库控制:控制数据库中数据的使用——哪些用户可以使用,哪些不可以 4.数据库维护:转出、回复、重组、性能检测、分析等(数据库维护的使用程序,一般都是由数据库管理员来使用和掌握的

从系统实现角度看数据库管理系统的功能

语言编译器 查询优化与查询实现 数据存取与索引 通信控制 事物管理 故障恢复 安全性控制 完整性控制 数据字典管理 应用程序接口 数据库数据装载、重组等 数据库性能分析

数据库语言

数据定义语言DDL:定义数据格式 数据操纵语言DML:对数据进行操作 数据控制语言DCL:对数据进行控制 数据库各种操作的执行:定义、控制和维护

数据库语言和高级语言的差别:一条数据库语言相当于高级语言的一个或者多个循环程序 数据库语言可以嵌入到任意一种高级语言中使用

数据库系统的标准结构

--三级模式,两层映像,两个独立性

三级模式:

子模式(外模式、局部模式、用户模式),概念模式(全局模式、模式、逻辑模式),存储模式(内模式、物理模式)

用户级对应外模式,概念级对应概念模式,物理级对应内模式

两个印象:

外模式映射为概念模式(E-C Mapping) 概念模式映射为内模式(C-I Mapping)

两个独立性:

逻辑数据独立性:外模式/概念模式映像 当概念模式变化时,可以不改变外部模式(只需改变E-C Mapping),从而不改变应用程序

物理数据独立性:概念模式/内模式映像 当内部模式变化时,可以不改变概念模式(只需改变C-I Mapping),从而不改变外部模式

数据模型

规定模式统一描述方式的模型(数据模型是对模式本身的抽象,模式是对数据本身结构形式的抽象 包括:数据结构、操作和约束

三大经典数据模型

关系模型:表的形式组织数据 层次模型:树的形式组织数据 网状模型:图的形式组织数据

其他数据模型

面向对象模型 XML模型 NoSQL模型

数据库系统的演变与发展

第一代数据库系统:基于网状模型或层次模型的数据库系统 第二代数据库系统:基于关系模型的数据库系统 第三代数据库系统:对象关系数据库,面向对象数据库 第四代数据库系统:多数据库开放式互连

数据库系统与文件系统的主要差别在: 数据的组织是否依赖于具体的应用程序 数据存取是否可以记录或记录的集合为单位进行操作 不同文件之间以及不同记录之间是否有联系

关系数据库系统对层次/网状数据库系统的重大改进是: 消除了由用户建立指针的弊端 将逐一记录的操作改进为支持记录集合的操作 数据检索操作不依赖于路径信息或过程信息,即非过程化的操作

面向对象数据库系统对关系数据库系统的重大改进是: 允许复杂的数据类型存在 允许复杂的数据类型存在 既支持记录集合的操作,又支持面向对象的操作

关系模型与关系数据库语言的关系

关系运算:关系代数和关系演算 关系演算:元组演算和域演算 关系代数示例:基于集合的运算

基于关系代数设计的数据库语言:用计算机可试别的符号象征关系代数的运算符号 元组演算示例:基于逻辑的运算 基于元组演算设计的数据库语言:用计算机可识别的符号表征元组演算的运算符号 域演算示例:基于示例的运算 基于域演算设计的数据库语言示例:QBE

关系模式与关系

同一关系模式下,可能有很多的关系 关系模式是关系的结构,关系是关系模式在某一时刻的数据 关系模式是稳定的,关系是某一时刻的值,是随时间可能变化的

关系的特性

列是同质:每一列中的分量来之同一域,是同一类型的属性 不同的列可来自同一个域,称其中的每一列为一个属性,不同的属性要给不同的属性名称 列位置互换性 行位置互换性 上述两种互换性说明表中行的顺序、列的顺序均可以任意交换 理论上,关系的任意两个元组不能完全相同 元组相同是指两个元组的每个分量都相同 属性不可再分特性(关系第一范式) 区分哪一列是靠列名 区分哪一行是靠某一或某几列的值

关系代数基本运算

img

并(∩) 讲两个关系的元组合并成一个元组,在合并时去掉重复的元组 由或者出现再关系R中,或者出现在S中的元组构成

差 R-S:由出现在关系R中但不出现在关系S中的元组构成 注:R-S和S-R是不同的

广义笛卡尔积 RxS:由关系R中的元组与关系S的元组进行所有可能的拼接(或串接)构成 注:当一个检索设计到多个表时,便需要将这些表串接或者拼接起来,然后才能检索,这时,就要使用广义笛卡尔积运算 这是后面学习各种连接运算的基础

选择 由给定的关系R中选择出满足给定条件的元组构成 注:选择操作从给定的关系中选出满足条件的行 条件的书写很重要,尤其时当不同运算符在一起时,要注意运算符的优先次序

投影(∏) 关系R中选出属性包含在A中的列构成 注:投影操作从给定关系中选出某些列组成新的关系,而选择操作时从给定关系中选出某些行组成新的关系 投影运算可以对原关系的列再投影后重新排列。 用户额可以根据需要通过投影、选择操作查询他所关心的数据信息

关系代数的扩展操作

交(∪) 由同时出现在关系R和关系S中的元组构成 注:叫运算可以通过查运算来实现

连接 θ-连接 由R中属性A与S中属性B之间满足θ条件的元组构成 可以理解成带选择功能的笛卡尔积 注:实际应用中,θ-连接操作经常与投影、选择操作一起使用 特别注意:虽然在讲解θ-连接操作的时候使用笛卡尔积然后再进行选择来得到θ-连接结果,但主要是方便大家理解,当引入连接操作后,DBMS可以直接进行连接操作而不必先形成笛卡尔积 等值连接 由关系R和关系S的笛卡尔积中选取R中属性A和S中属性B上值相等的元组所构成 注:等值连接是θ-连接的一种特殊情况 广义积的元组组合并不是都有意义的,另外广义积的元组组合数目也非常庞大,因此采用θ-连接/等值连接可大幅度降低中间结果的保存量,提高速度 自然连接 关系R和关系S 的笛卡尔积中选取相同属性组B上值相等的元组所构成 注:自然连接是一种特殊的等值连接 要求关系R和关系S必须有相同的属性组B R,S属性相同,值必须相等才能连接 要在结果中去掉重复的属性列(因为结果中R.B1始终是等于S.B1,所以可以只保留一列即可

关系R与关系S只有一个公共属性,T1是R与S做θ连接的结果,T2是R与S自然连接的结果是T1的属性个数大于T2的属性个数

关系代数的基本书写思路

选出将用到的关系/表 做“积”运算(可用连接运算替换) 做选择运算保留所需的行/元组 做投影运算保留所需的列/属性

集合操作思维训练注意点

注意连接和积的差别 注意其中可能会写错(语法看起来正确,但是语义错误) 特别注意语义

书写关系代数的基本思路

检索是否涉及多个表,如果不涉及,则可直接采用并、差、交、选择与投影,只要足以条件数写正确与否即可 如果涉及多个表,那么检查 能否使用自然连接,将多个表连接起来(多数情况是这样的) 如果不能,能否使用等值或不等值连接(θ-连接) 如果还是不能,则使用广义笛卡尔积,注意相关条件的书写 连接完后,可以继续使用选择、投影等运算,即所谓数据库的“选投联”操作

复杂扩展操作

除 给定关系R为n度关系,关系S为m度关系。如果可以进行关系R与关系S的除运算,当且仅当:S属性集是R属性集的真子集,即m<n 关系R和关系S的出运算结果也是一个关系,分为两部分来定义 先定义R/S结果的属性应有哪些 再定义R/S的元组怎样形成

外连接 两个关系R和S进行连接时,如果关系R(或S)中的元组在S(或R)中找不到相匹配的元组,则为了避免该元组信息丢失,从而将该元组与S(或R)中假定存在的全为空值的元组形成连接,放置在结果关系中,这种连接称之为外连接

关系演算的重难点

关系元组演算公式的递归定义;关系与演算公式的递归定义 关系元组演算公式:与, 或, 非, 存在量词, 全称量词 用关系元组演算公式表达查询的思维训练 用QBE语言表达查询的思维训练 关系元组演算、域演算和关系代数在表达查询方面的思维差异

数据库语言--SQL

补充知识点

在SQL—92标准中定义的数据类型

char(n):固定长度的字符串 verchar(n):可变长字符串 int:整数//有时不同系统也写作intger numeric(p, q):固定精度数字,小数点左边p位,右边p-q位 real:浮点精度数字//有时不同系统也写作float(n),小数点后保留n位 data:日期 time:时间 ...... 和高级语言的数据类型总体上而言是一致的,但也有一些差异

其他:

1.SQL-DML既能单一记录操作,也能对记录集合进行批量更新操作 SQL-DML的更新操作需要利用前面介绍的子查询的概念,以便处理“一些”,“某些”等。

SQL语言概述

主要构成

DDL语句引导词(数据定义语言): Create(建立),Drop(撤销) 模式的定义和删除,包括定义Database,Table, View,Index,完整性约束条件等,也包括定义对象(RowType行列表,Type列对象)

DML语句引导词(数据操纵语言):Insert,Delete,Updata,Select 各种方式的更新与检索操作,如直接输入记录,从其他Table(由SubQuery建立)输入 各种复杂关系的检索,如连接查找,模糊查找,分组查找,嵌套查找等 各种聚集操作,求平均,求和等,分组聚集,分组过滤等

DCL语句引导词(数据控制语言):Grant,Revoke 安全性控制:授权和撤销授权

交互式SQL->嵌入式SQL->动态SQL等

利用SQL语言建立数据库

包括两件事:定义数据库和表(使用DDL),向表中追加元组(使用DML)

DDL():通常由DBA来使用,也有经DBA授权后由应用程序员来使用 创立数据库(DB)Create Database 创建DB中的Table(定义关系模式) 定义Table及其各个属性的约束条件(定义完整性约束) 定义View(定义外模式及E-C映像) 定义Index、Tablespace等(定义物理存储参数) 上述各种定义的撤销与修正

典型DBMS交互环境简介-SQL Server

SQL Server的数据库

文件:.mdf, .ndf, .ldf 主数据库文件(.mdf):存储数据库的启动信息和部分或者全部数据,一个数据库可以有多个数据库文件,但主数据库文件只有一个 辅助数据文件(.ndf):用于放置主数据库文件中所定义数据库的其他数据,可有多个,在数据庞大时,可以帮助存储数据 日志文件(.ldf):每个数据库至少有一个事务日志文件

页面:是SQL Server存储的最小单位,一页为8K或者8192字节

空间:是8个连续的页面,级64K数据,是分配数据表存储空间的一种单位

基本操作

备份数据库

完全数据库备份:完全备份数据文件和日志文件 差异备份(增量备份):对最近一次数据库备份以来发生的数据变化进行备份,这 要在完全备份的基础上进行,特点是速度快 事务日志备份:对数据库发生的事物进行备份,包括从上次进行事物日志备份、差 异备份和数据库完全备份之后,所有已经完成的事物。能尽可能的恢复最新的数 据库记录,特点是所需磁盘空间小、时间少 数据库文件和文件组备份:用在数据库相当大的情况下

基本操作

创立Database

数据库可以是若干具有相互关联关系的Table/Relation的集合 数据库可以看作是一个集中存放若干Table的大型文件 简单语法形式: create database 数据库名;

创立Table

简单语法形式: Create table 表名(列名 数据类型 [Primary key | Unique] [not null] [, 列名 数据类型列名 数据类型[Not null], ...]); 注:[] 表示其扩起的内容可以忽略, |表示其隔开的两项可取其一 Primary key :主键约束,每个表只能创建一个主键约束 Unique:唯一性约束(候选键),可以有多个唯一性约束 Not null:非空约束,是指该列不允许有空值出现,如选择了Not null表明该列不允许有空列出现 语法中的数据类型在SQL标准中有定义

向表中追加元组

简单语法形式: insert into 表名 [ ( 列名 [ , 列名 ] ... ) ] values(值 [ , 值 ] , ... ) values后面值的排列,必须与into子句后面的列名排列一致 若表名后的所有列名省略,则values后的值的排列,必须与该表中存储的列名排列一致

检索语句Select(结构形式一致但功能多样化的检索语句)

简单语法形式: Select 列名 [ [, 列名] ...] From 表名 [Where 检索条件]; 从表名所给的表中,查询出满足检索条件的元组,并按照给定的列名及顺序进行投影显示 Select语句中的select..., from..., where..., 等被称为子句,在以上基本形式基础上会增加许多构成要素,也会增加许多新的子句,满足不同的需求 检索条件的书写:逻辑运算符用and,or, not来表示,同时注意运算服的优先次序和括弧的使用,书写要点是注意对自然语言检索条件的正确理解

结果唯一性问题

在Table中要求无重复元组是通过定义Primary key或者Unique来保证的;而在检索结果中要求无重复元组,是通过DISTINCY保留字的使用来实现的

结果排序问题

DBMS可以对检索结果进行排序,可以升序排列,也可以降序排列 简单语法形式: order by 列名[asc | desc] 检索结果按照指定列名进行排序,若后跟asc或省略则为升序,若后跟desc则为降序

模糊查询问题

简单语法形式: 列名 [not] like "字符串" 找出匹配给定字符串的字符串,其中给定字符串中可以出现%,_ 等匹配符 匹配规则: % 匹配零个或者多个字符 _ 匹配任意单个字符 \ 转义字符,用于去掉一些特殊字符的特定含义,使其被作为普通字符看待,如用"%"去匹配字符%,用 \ _ (中间其实是没有空格的)去匹配字符_

多表联合查询

简单语法形式: Select 列名 [ [, 列名] ...] From 表名1, 表名2, ... Where 检索条件; 检索条件中要包含连接条件,通过不同的连接条件可以实现等值连接,不等值连接等

重名处理

简单语法形式: Select 列名 [ [, 列名] ...] From 表名1 as 表别名1,表名2 as 表别名2 ... Where 检索条件; as可以省略 当定义了别名后,在检索条件中可以使用别名来限定属性 (有时表名很长时,为书写条件简便,也定义表别名来简化书写)

增删改操作

元组新增Insert: 新增一个或一些元组到数据库的Table中 单一元组新增命令形式:插入一条指定元组值的元组 insert into 表名 [ ( 列名 [ , 列名 ] ... ) ] values (值 [ , 值 ] , ... ); 批数据新增命令形式:插入子查询结果中的若干条元组,待插入的元组由子查询给出 insert into 表名 [ ( 列名 [ , 列名 ] ... ) ] 子查询; 注:当新增元组时,DBMS会检查用户定义的完整性约束条件等,如果不符合完整性约束条件,则将不会执行新增动作

元组更新Update: 对某些元组中的某些属性进行重新设定 Update 表名 Set 列名 = 表达式|(子查询) [ [ , 列名 = 表达式 | ( 子查询 ) ] ... ] [where 条件表达式]; (如果where条件省略就更新所有的元组。条件控制的删除语句此处略)

元组删除Delete:删除某些元组 Delete From 表名[where 条件表达式]; (如果where条件省略就删除所有的元组。条件控制的删除语句此处略)

撤销与修改

修正数据库:主要是修正表的定义

修正基本表: alter table tablename [add {colname datatype, ...}] 增加新列 [drop {完整性约束}] 删除完整性约束 [modify {colname datatype, ...}] 修改列定义

撤销基本表: drop table 表名 注:delete语句只是删除表中的元组,而撤销基本表drop table的操作时撤销包含表格式、表中所有元组、由该表导出的视图等相关的所有内容,所以使用的时候要特别注意

撤销数据库: drop database 数据库名;

指定与关闭命令

指定当前数据库: use 数据库名;

关闭当前数据库: close 数据库名;

复杂查询与视图

子查询

子查询:出现在where子句中的select语句被称为子查询,子查询返回了一个集合,可以通过与这个集合的比较来确定另一个查询集合 三种类型的子查询:(NOT)IN-子查询 θ Some与θ All子查询 Exists子查询

为什么需要子查询?

1.集合成员资格:某一元素是否是某一个集合的成员 2.集合之间的比较:某一个集合是否包含另一个集合等 3.集合计数的测试:测试集合是否为空 2.测试集合是否存在重复元组

(NOT)IN-子查询

(NOT)IN谓词子查询 基本语法:表达式[not] in(子查询) 语法中:表达式的最简单形式 判断某一表达式的值是否在子查询的结果中

带有子查询的select语句区分为内层和外层

非相关子查询:内层查询独立进行,没有设计任何外层查询相关信息的子查询

相关子查询:内层查询需要依靠外层查询的某些参量作为限定条件才能进行的子查询 外层向内层传递的参量需要使用外层的表名或者表别名来限定

注:相关子查询只能由外层向内层传递参数(变量的作用域原则)

θ Some与θ All子查询

θ Some/θ All子查询 基本语法:表达式 θ some(子查询) 表达式 θ all (子查询) 语法中:θ是比较运算符(>, <, >=, <=, =, <>) 将表达式的值与子查询的结果进行比较(some的话只要由一个满足即为真,all的话要全部满足才为真)

补充:为什么不用θ any:因为语义的模糊性被some替代以求更加明晰

等价性变换需要注意 这两种表达方式的含义是相同的 表达式 = some(子查询) 表达式 in (子查询) 这两种表达方式含义是不同的 表达式 <> some(子查询) 表达式 not in (子查询) 等价:表达式 <> all(子查询)

(NOT) EXISTS子查询

基本语法:[not] exists(子查询) 语义:子查询结果中有无元组存在

结果计算与聚集计算

结果计算

Selsct-From-Where语句中,Select子句后面不仅可以是列名,还可以是一些计算表达式或者聚集函数,表名在投影的同时直接进行一些运算

基本语法:Selsct 列名 | expr | sgfunc(列名) [[,列名 | expr | sgfunc(列名)]] From 表名1[, 表名2......] [Where 检索条件] expr可以是常量、列名、或由常量、列名、特殊函数及算术运算符构成的算数运算式。特殊函数的使用需要结合各自DBMS的说明书 agfunc()是一些聚集函数

聚集函数

SQL提供了五个作用在简单列值集合上的内置聚集函数agfunc,分别是: COUNT(求个数) SUM(求和) AVG(求平均) MAX(求最大) MIN(求最小) SQL聚集函数的参数类型,结果类型与作用如下:

分组查询与分组过滤

分组查询

分组:SQL可以将检索到的元组按照某一条件惊醒分类,具有相同条件值得元组划分到一个组或者一个集合中,同时处理多个组或者集合的聚集运算

分组的基本语法:Selsct 列名 | expr | sgfunc(列名) [[,列名 | expr | sgfunc(列名)]] From 表名1[, 表名2......] [Where 检索条件] [Group by 分组条件] 分组条件可以是:列名1,列名2......

补充:聚集函数是不允许用于where子句中的,where子句是对每一个元组进行条件过滤而不是对集合进行条件过滤 分组查询仍然需要注意语义问题

分组过滤

若要对集合(即分组)进行条件过滤,即满足条件的集合、分组留下,不满足条件的集合、分组剔除 Having子句(分组过滤子句)需要有Group by子句支持,换句话说,没有Group by 子句,便不能有Having子句 基本语法:Selsct 列名 | expr | sgfunc(列名) [[,列名 | expr | sgfunc(列名)]] From 表名1[, 表名2......] [Where 检索条件] [Group by 分组条件 [Having 分组过滤条件]]

HAVING子句和WHERE子句表达条件的区别

HAVING子句:每一分组检查满足与否的条件要用Having子句表达 注:不是每一行都检查,所以使用Having子句一定要有Group by子句 WHERE子句:每一行都要检查满足与否的条件要用WHERE子句表达

关系代数操作

有些DBMS并不支持这些运算,使用的时候要注意

交 UNION 并 INTERSECT 差 EXCEPT

基本语法形式 子查询 {Union {ALL} | Intersect{ALL} | Except{ALL} 子查询} 通常情况下自动删除重复元组(不带all) 要保留重复元组(带all)

空值的处理

空值检测

is [not] null 测试指定列的值是否为空值(注意:空值是不能进行运算的,所以这个条件不能写成 = null)

现行DBMS的空值处理小结

1.除了is [not] null以外,空值不满足任何查找条件 2.如果null参与算术运算,则该算术表达式的值为null 3.如果null参与比较运算,则结果可以视为false(sql-92中可以看成unknown) 4.如果null参与聚集运算,则除了count(*)以外其他聚集函数都忽略null

连接(内连接,外连接)

关系代数运算中,有连接运算,又分为θ连接和外连接 select 列名[[, 列名]...] from 表名1,表名2 where 检索条件

sql的高级语法中引入了内连接与外连接运算,具体形式表现为: select 列名[[, 列名]...] from 表名1 [ NATURAL ] [[INNER | {LEFT | RIGHT | FULL} {OUTER}] JOIN 表名2 {ON 连接条件| Using (Colname {, Colname ...})} [where 检索条件]...; (这个连接由两部分构成:连接类型和连接条件) inner join:关系代数中的θ连接 left outer join, right outer join, full outer join:关系代数中的外连接运算 natural:出现在结果关系中的两个连接关系的元组在公共属性上取值相同,且公共属性只出现一次 on <连接条件>:出现在结果关系中的两个连接关系的元组取值满足连接条件,且公共睡醒出现两次 Using (Colname {, Colname ...}):(Colname {, Colname ...})是两个连接关系的公共属性的子集,元组在(Colname {, Colname ...})上取值相等,且(Colname {, Colname ...})只出现一次、

视图

相关:三级模式两层映像结构(基本表) 对应外模式的数据称为视图,视图不仅包含外模式,而且包含其E-C映像

SQL数据库结构

1.基本表是实际存储于存储文件中的表,基本表中的数据是需要存储的 2.视图在SQL中只存储其由基本表导出视图所需要的公式,即由基本表产生视图的映像信息,其数据并不存储,而是在运行过程中动态产生与维护的 3.对视图数据的更改最终要反映在对基本表的更改上 4.视图需要“先定义,后使用”

定义视图

create view view_name [(列名[, 列名]...)] as 子查询[with check option] 如果视图的属性名缺省,则默认为子查询结果中的属性名,也可以是显式指明其所拥有的列名 with check option指明当对视图进行insert,update,delete时,要检查进行insert,update,delete的元组是否满足视图定义中子查询定义的条件表达式

使用视图

定义好的视图,可以像table一样,在sql各种语句中使用(有事可以方便用户进行检索操作)

SQL视图更新

因为视图不保存数据,对视图的更新最终要反映到对基本表的更新上,而有时,视图定义的映射不是可逆的

sql视图更新的可执行性

如果视图的select目标列中包含聚集函数,则不能更新 如果视图的select子句使用了unique或者distinct,则不能更新 如果视图中包括了group by子句,则不能更新 如果视图中包括经算术表达式计算出来的列,则不能更新 如果视图是由单个表的列构成,但并没有包括主键,则不能更新 对于由单一table自己构成的视图(如果视图是从单个基本表使用选择、投影操作导出的)并且包含了基本表的主键,则可以更新

撤销视图

已经定义好的视图也可以撤销 Drop View view_name 同时:不仅仅只是视图可以撤销,基本表、数据库等都可以撤销

SQL-SELECT小结

SQL语言与数据库完整性和安全性

数据库完整性的概念及分类

数据库完整性:DBMS应该保证的DB的一种特征,在任何情况下的正确性,有效性和一致性 广义完整性:语义完整性,并发空值,安全控制,DB故障修复等 狭义完整性:专指语义完整性,DBMS通常由专门的完整性管理机制与程序来处理语义完整性问题

关系模型中有完整性要求: 1.实体完整性 2.参照完整性 3.用户自定义完整性

为什么会引发数据库完整性的问题: 不正当的数据库操作(输入错误,操作失误,程序处理失误等)

数据库完整性管理的作用: 1.防止和避免数据库中不合理数据的出现 2.DBMS应该京可能的自动防止DB中语义不合理现象

DBMS怎样自动保证完整性: 1.DBMS允许用户定义一些完整性约束规则(用SQL-DDL来定义) 2.当有DB更新操作时,DBMS自动按照完整性约束条件进行检查,以确保更新操作符合语义完整性

按照约束对象分类: 1.域完整性约束条件(对给定列上所要更新的某一候选值是否可以接受进行约束条件判断,这是孤立进行的) 2.关系完整性约束条件(施加于关系/表上,对给定表上索要更新的某一候选元组是否可以接受进行约束条件判断,或是对一个关系中的若干元组和另一个关系中的若干元组间的联系是否可以接受进行约束条件判断)

按照约束来源分类: 1.结构约束:来自于模型的约束(例如函数依赖约束,主键约束(实体完整性),外键约束(参照完整性)),只关心数字相等与否,是否允许空值等 2.内容约束:来自于用户的约束(如用户自定义完整性),关心元组或属性的取值范围

按照约束状态分类: 1.静态约束:要求DB在任意时候均应满足的约束 2.动态约束:要求DB从一个状态变成另一个状态时应该满足的约束

静态完整性

重点与难点: 数据库完整性的概念,完整性规则,静态约束,动态约束(触发器) 数据库安全性的概念,安全性访问规则,权利与授权

SQL支持如下几种约束

1.静态约束 列完整性-域完整性约束 表完整性-关系完整性约束 2.动态约束 触发器

SQL实现约束的方法——Create Table

Create Table有三种功能:定义关系模式、定义完整性约束(和定义物理存储特性) 定义完整性约束条件: 1.列完整性 2.表完整性 create table tablename ((colname datatype [default {default_constant | NULL} ] [col_constr {col_constr... } ] |, table_constr ) {colname datatype [default {default_constant | NULL} ] [col_constr {col_constr... } ] |, table_constr } );

col_constr:列约束(只能引用在单一列上,其后面的约束如unique,primary key及search_cond只能是单一列唯一,单一列为主键、和单一列相关) 一种域约束类型,对单一列的值进行约束 { not null | //列值非空 [constraint constraintname] //为约束命名,便于以后 {unique //列值是唯一 |primary key //列为主键 |check (search_cond) //列值满足条件,条件只能使用列当前值 |references tablename [(colname)] [on delete{cascade |set null}]}} //引用另一表tablename的列colname的值,如有on delete cascade或者on delete set null语句,则删除被引用表的某列值v时,要将本表该列值为v的记录删除或者列值更新为null,缺省则无操作

col_constr:列约束(只能引用在单一列上,其后面的约束如unique,primary key及search_cond只能是单一列唯一,单一列为主键、和单一列相关) 一种域约束类型,对单一列的值进行约束 { not null | //列值非空 [constraint constraintname] //为约束命名,便于以后撤销 {unique //列值是唯一 |primary key //列为主键 |check (search_cond) //列值满足条件,条件只能使用列当前值 |references tablename [(colname)] [on delete{cascade |set null}]}} //引用另一表tablename的列colname的值,如有on delete cascade或者on delete set null语句,则删除被引用表的某列值v时,要将本表该列值为v的记录删除或者列值更新为null,缺省则无操作

table_constr:表约束(是应用在关系上,即对关系的多列或者元组进行约束,列约束是其特例) 一种关系约束类型,对多列或者元组的值进行约束 {constraint constraintname] //为约束命名,便于以后撤销 {unique (colname {, colname...}) //几列值组合在一起是唯一 |primary key (colname {, colname...}) //几列联合为主键 |check (search_condtion) //元组多列值共同满足条件 //条件中只能使用同一元组的不同列当前值 |foreign key (colname {, colname...}) references tablename [(colname {, colname...})] [on delete cascade ]} //引用另一表tablename的若干列的值作为外键 //check中的条件可以是select-from-where中任何where后的语句,包含子查询

撤销或者追加约束 create table中定义的表约束或者列约束可以在以后根据需要进行撤销或者追加(语句为alter table(不同系统可能存在差异)) slter table tblname [add (colname datatype [default {default_const|null}] [col_constr{col_constr...}] |, table_constr} {, colname...})] [drop {column columnname | {columnname {, columnname ...}}}] [modlfy (columnname data_type [default {default_const | NULL}] [[not] NULL] {, columnname...})] [add constraint constr_name] [drop constraint constr_name] [drop primary key]

断言ASSERTION 一个断言就是一个谓词表达式,它表达了希望数据库总能满足的条件 表约束和列约束就是一些特殊的断言 SQL还提供了复杂条件表达的断言,其语法形式为: create assertion < assertion_name > check < predicate > 当一个断言创建后,系统将检测其有效性,并在每一次更新中测是更新是否违反该断言 注意:断言测试增加了数据库维护的负担,要小心使用复杂的断言

动态完整性

触发器trigger create table中的表约束和列约束基本上都是静态的约束(也基本上都是对单一列或者单一元组的约束(尽管有参照完整性 )),为实现动态约束以及多个元组之间的完整性约束,就需要触发器trigger trigger是一种过程完整性约束(相比之下create table中定义的都是非过程性约束),是一段程序,该程序可以在特定的时刻被自动触发执行,比如在一次更新操作之前执行,或在更新操作之后执行 create trigger trigger_name before | after {insert | delete | update [of colname{, colname...}]} on tablename [referencing corr_name_def{, corr_name_def}] [for each row | for each statement] //对更新操作的每一条结果(前者),或者整个更新操作完成(后者) [when (search_condition)] //检查条件,如果满足则执行下述程序 { statement //单行程序直接书写,多行程序要用下行方式 | begin atomic statement; {statement;...} end} 触发器的意义:当某一时间发生时,对该时间产生的结果(或是每一元组,或是整个操作的所有元组),检查条件search_condition,如果满足条件,则执行后面的程序段,条件或程序段中引用的变量可用corr_name_def来限定 事件:defore|after {insert | delete | update...} 1.当一个时间(insert,delete,或者update)发生之前before或者发生之后after触发 2.操作发生,执行触发器操作需处理两组值:更新前的值和更新后的值,这两个值由corr_name_def的使用来区分 corr_name_def的定义: { old [row] [as] old_row_corr_name //更新前的旧的元组别名为 | new[row] [as] new_row_corr_name //更新后的新的元组别名为 | old table [as] old_table_corr_name //更新前的旧的table别名为 | newtable [as] new_table_corr_name //更新后的新的table别名为 } //corr_name_def将在检测条件或者后面的动作程序段中被引用处理

数据库安全性的概念及分类

数据库安全性

数据库安全性是指DBMS应该保证的数据库的一种特性(机制或者手段):免受非法,非授权用户的使用、泄露、更改或破坏 数据库系统DBS的安全级别:物理控制、网络控制、操作系统控制、DBMS控制

DBMS的安全机制

1.自主安全机制:存取控制(通过权限在用户之间的传递,是用户自主管理数据库安全性) 2.强制安全性机制 通过对数据和用户强制分类,使得不同类别用户能够访问不同类别的数据 3.推断控制机制 防止通过历史信息,推断出不该被其知道的信息 防止通过公开信息(通常是一些聚集信息)推断出私密信息(个体信息),通常在一些由个体数据构成的公共数据库中此类问题尤为重要 4.数据加密存储机制 通过加密、解密保护数据,密钥,加密/解密方法与传输

数据库自主安全性机制

通常情况下,自主安全性是通过授权机制来实现的 用户在使用数据库前必须由DBA处获得一个账户,并由DBA授予该账户一定的权限,该账户的用户依据其所拥有的权限对数据库进行操作;同时,该账户用户也可将其所拥有的权力转授给其他的用户,由此实现权限在用户之间的传播和控制 授权者:决定用户权力的人 授权:授予用户访问的权力

DBMS怎样实现自主安全性

1.DBMS允许用户定义一些安全性控制规则(用SQL-DCL来定义) 2.当有DB访问操作时,DBMS自动按照安全性控制规则进行检查,检查通过则允许访问,不通过则不允许访问

DBMS将权力和用户(账户)结合在一起,形成一个访问规则表,依据该规则表可以实现对数据库的安全性控制 AccessRule ::= (S(请求主体(用户)), O(访问对象), T(访问权力), P(谓词)) AccessRule通常存放在数据字典(系统目录)中,构成了所有用户对DB的访问权力 用户多时,可以按照用户组建立访问规则 访问对象可大可小:属性/字段,记录/元组,关系,数据库 权力:包括创建、增、删、改、查等 谓词:拥有权利需满足的条件

两种控制: 1.按名控制安全性:存储矩阵 2.按内容控制安全性:视图

视图时安全性控制的重要手段 通过视图可以限制用户对关系中某些数据项的存取 通过视图可以将数据访问对象与谓词结合起来,限制用户对关系中某些元组的存取 用户定义视图后,视图便称为一新的数据对象,参与到存储矩阵与能力表中进行描述

授权命令 grant {all privileges | privileges {,privileges ...}} on [table] tablename | viewname to {public | user-id {, user-id...}} [with grant option] user-id:某一个用户账户 public:允许所有有效用户使用授予的权利 privileges :是权利(select | insert | update | delete | all privileges) with grant option:允许被授者传播这些权力 收回授权命令 revoke {all priv | priv {,priv ...}} on tablename | viewname from {public | user {, user...}}

安全性控制的其他简介

强制安全性机制 强制安全性通过对数据对象进行安全性分级 绝密,机密,可信,无分类 同时对用也进行上述的安全性分级 从而强制实现不同急别用户访问不同急别数据的一种一种机制

访问规则: 用户S,不能读取数据对象O,除非level(S) >= level(O) 用户S,不能写数据对象,除非level(S) <= level(O)

强制安全性机制的实现 DBMS引入强制安全性机制,可以通过扩展关系模式来实现 1.关系模式:R(A1: D1, A2:D2,..., An:Dn) 2.对属性和元组引入安全性分级特性或者称分类特性 R(A1:D1,C1,S2:D2,C2...An:Dn,Cn,TC) 其中C1,C2...Cn分别为属性D1,D2...Dn为安全分类特性;TC为元组的分类特性 强制安全性机制使得关系形成多级关系(不同级别用户所能看到的关系的子集),也出现多重实例、多级关系完整性等许多新的问题或者新的处理技巧,在使用中需注意仔细研究

数据建模与数据库设计

数据建模

为什么要数据建模和数据库设计? E-R模型--数据建模之基本思想 E-R模型--表达方法之chen方法 E-R模型--表达方法之Crow's foot方法 数据建模之案例详解 数据库设计中的抽象

重难点: 1.基本思想 2.掌握Crow's foot方法

数据建模是抽象,抽象是理解-区分-命名-表达

E-R模型

1.基本概念

基本观点:世界是由一组称作实体的基本对象和这些对象之间的联系构成的

1.实体:客观存在并可相互区分的事物 实体由类(实体,实体的型)和个体(实体的实例,实体的值)的概念 2.属性:实体所具有的某一方面特征 属性还有很多类型,要注意区分 单一属性和复合属性 单值属性和多值属性:每个实例的该属性值是一个还是多个 可控制属性和非空值属性 导出属性:由其他属性计算而得 3.关键字/码:实体中能够用其值唯一区分开每一实例的属性或属性组合 4.联系:指一个实体的实例和其他实体实例之间所可能发生的联系 有一元联系、二元联系和多元联系 实体是相对恒定的,但是联系是多样化的 实体之间的联系有很多种类 二元联系:一对一、一对多和多对多联系 4.1.度/元:参与发生联系的实体的数目 4.2.角色(作用):实体在联系中的作用 当同一实体的不同实例参与一个联系时,为区别各实例参与联系的方式,需要显式指明其角色 4.3.联系的基数:实体实例之间的联系的数量、即一个实体的实例通过一个联系能与另一实体中相关联的实例的数目 通常以实体参与联系的最小基数和最大基数来标记 完全参与联系:该端实例至少有一个参与到联系中 部分参与联系:该端实例可以不参与联系

2.表示方法

2.1.Chen方法

实体:矩形框 属性:椭圆 多值属性:双线椭圆 导出属性:虚线椭圆 关键字/码:下划线 连接实体和属性:直线 联系:菱形框 连接实体和联系:直线 连接联系和属性:直线 复合关键字:标有相同数字 多组关键字:标有不同数字 1:1联系:箭头直线,由联系指向实体 1:m联系:指向1端为箭头直线,指向多端为无箭头直线 m:n联系:无箭头直线 完全参与联系:双直线 部分参与联系:单直线

注意: 1.联系也需要命名和表达 2.实体之间可能有多种含义的联系 3.每个实体至少要给出关键字 4.联系也可能需要属性来刻画 5.联系和实体间连线不是随意化的,其代表实体的关键字要作为联系的属性

2.2.Crow's Foot方法

实体:矩形框,实体的名称写在横线上面 属性:实体框横线的下面 关键字/码:属性下加下划线 联系:菱形框(也可以省略菱形框直接以联系名来代替)

注意: 1.一种图形代表着一类业务规则 2.不是在画图,而是在表达业务规则

2.3.IDEF1X方法(工程化方法)

数据库设计中的抽象

1.信息

信息时现实世界中事物在人们头脑中的一种反映 信息可以准确的反映显示世界中的事物(描述) 也可以通过现实进行抽象,形成信息(抽象)

注意: 1.数据库设计往往因为忽视了信息(之间联系)的细致分析而造成设计事物 2.设计库设计能力的高低往往体现在信息(及其联系)的正确分析上,体现在理解现实世界能力的高低 3.抽象可能经过很多层次

2.型与值

基本的抽象:型与值的抽象

3.数据模型

不同范围对的人对现实世界中事物的描述和抽象可能是不同的

现实的抽象与描述需要遵循同一的数据模型:统一的概念与统一的表达方法 数据模型是一组相互关联且已严格定义的概念集合,是用于刻画或者描述现实世界、信息世界或计算机世界的模型

4.数据模型与概念模型

数据模型:表达计算机世界的模型 概念数据模型(概念模型):表达信息世界的模型

5.建模的不同层次

模型与元模型,模型(型)与实例(值)

问题: 1.Chen方法的最大缺陷 2.Crow's Foot的优点 3.为什么说抽象是理解-区分-命名-表达 4.E-R模型要找什么样的实体与联系,有哪些类型的联系 5.绘制Crow's Foot形式的E-R图的要点是什么

数据库设计过程

1.概述

1.需求分析 收集需求和理解需求 提交物:需求分析报告 形成数据库设计的“源”清单和“属性”清单以及相关的详细描述,尤其是注意业务规则与属性处理规则 2.概念数据库设计 建立概念模型 提交物:概念数据库设计报告 用唯一的表达方法,如E-R模型/IDER1X模型给出描述;不仅绘制出来,而且绘制正确 3.逻辑数据库设计 建立逻辑模型 提交物:逻辑数据库设计报告 用关系模型、网状模型或者层次模型规定的模式描述方法来进行描述 4.物理数据库设计:建立物理模型 结合指定DBMS物理数据库管理方法,给出概念 提交物:物理数据库设计报告 理解Oracle、Sybase或其他DBMS的物理数据库管理方式,这是数据库管理员(DBA)的基本责任

2.概念数据库设计的可能冲突

1.属性冲突 属性域的冲突:属性的类型、取值范围不同 属性取值单位冲突 2.结构冲突 同一对象在不同应用中的抽象不同 同一实体在不同E-R图中属性组成不同 实体之间的联系在不同E-R图中呈现不同的类型 3.命名冲突 同名异义:不同意义的对象具有相同的名字 异名同义:同一意义的对象具有不同的名字

全局E-R模式优化 1.合并实体类型 2.消除冗杂属性 3.消除冗杂联系

3.从概念模式向关系模式转换:

1.E-R图的实体转换为关系 2.E-R图的属性转换为关系的属性 3.E-R图的关键字转换为关系的关键字

4.基本转换规则

基本转换规则:复合属性的转换 将每个分量属性作为复合属性所在实体的属性,或者将复合属性本身作为所在实体的属性

基本转换规则:多值属性的转换 将多值属性与所在实体的关键字一起组成一个新的关系

基本转换规则:联系的转换 一对一联系: 若联系双方均部分参与(0..1),则将联系定义为一个新的关系,属性为参与双方的关键字属性 若联系一方全部参与(1..1),则将联系另一方的关键字作为全部参与一方关系的属性 一对多联系: 将单方参与实体的关键字作为多方参与实体对应关系的属性 多对多联系: 将联系定义为新的关系,属性为参与双方实体的关键字

基本转换规则:弱实体的转换 所对应关系的关键字由弱实体本身的区分属性再加上所依赖的强实体的关键字构成 补:弱实体集(从属实体)与强实体集(独立实体)之间的联系已经在弱实体集所对应的关系中表示出来了

基本转换规则:泛化与具体化实体的转换 高层实体(泛化实体)和低层实体(具体化实体)分别转为不同的关系 底层实体所对应的关系包括高层实体的关键字

基本转换规则:泛化与具体化实体的转换 如果泛化实体实例是具体化实体实例的全部,即一个高层实体实例至少属于一个低层实体,则可以不为高层实体建立关系,低层实体所对应的关系包括上层实体的所有属性

基本转换规则:多元联系的转换 多元联系可以通过继承参与联系的各个实体的关键字而形成新的关系 这些继承过来的关键字可作为新关系的关键字 也可以新增一个区分属性作为关键字 注意这两种转换的差异 多元联系更需注意分析参与联系的实体的最大基数和最小基数 多元联系可以转换为多个二元联系进行处理

基本转换关系:只需关注实体转换为关系,而联系则无需关注

5.不正确设计数据库引发的问题

冗杂:数据库中存在大量冗杂 分为非受控冗杂和受控冗杂

不正确设计数据库可能会引发: 1.插入异常 2.删除异常

规范的数据库设计: 1.数据依赖理论 2.关系范式理论 3.模式分解理论

问题: 1.是否允许参与联系的多实体中有一个或多个实体不参与 2.概念数据库设计究竟要做什么事 3.逻辑数据库设计究竟要做什么事

规范形式

如何避免数据库的一致性问题--数据库的模范性设计

主要概念

关系的第一范式(1NF):第一范式要求关系中不能有复合属性,多值属性及其组合 将非1NF转换成1NF,引入新的数据模型处理:Object-Orientend Data Model

关系的第二范式(2NF): 第二范式消除了非主属性对候选键的部份依赖

关系的第三范式(3NF): 第三范式消除了非主属性对候选键的传递依赖

关系的BCNF:

有传递依赖的或者说不满足3NF的,也一定不满足BCNF

多值依赖: 多值依赖的特性

关于多值依赖的公理: 推论:

第四范式: 第四范式消除了非主属性对后仙剑以外属性的多值依赖 如果有多值依赖,则一定依赖于候选键 定理:

弱第四范式(W4NF):

总结:

数据库管理系统实现技术

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值