数据库系统概论（王珊，萨师煊版）范式之前要点
第一章要点——数据库系统第二章要点——关系数据库第三章要点——SQL:对模式和外模式的DDL,DQL,DML第四章要点——SQL:DCL之数据库安全性第五章要点——SQL:DCL之数据库完整性第六章要点——设计开发：关系数据理论（仅范式部分）思维导图——暂无，回头补声明一下：本文章所有的图都是实在是不想写了，要么MOOC截的，要么百度随便找的图，找我就删~
第一章要点——数据库系统
分辨一个概念：数据库系统（DBS），常简称数据库（但是与DB不同），由DB,DBMS(及其应用开发工具),DBA和应用程序组成的存储、管理、处理和维护数据data的系统。
1.数据库系统核心与基础——数据模型
- 图画的比较丑emmm。
举“栗”理解——表示方法，例：
概念模型—E-R图（E-R模型）…;逻辑模型—层次模型、网状··、关系··、面向对象数据··、对象关系数据··、半结构化数据··，… ;物理模型—系统、磁盘内部存取方式… ;
2.关系模型的数据结构与术语（其实属于1.，单独拎出来讲一下）
关系模型的数据结构，都懂哈，一张规范化的二维表。
优点：概念单一，数学概念严格，对用户透明。缺点：查询效率比格式化差。
3.数据库系统的结构——三级模式结构两级映像功能
理解：
模式—逻辑级视图（基本表）;外模式—用户级视图（视图）;内模式—数据库内部组织方式（理解成存储策略或者存储文件） ;映像—对应关系 ;SQL下（对应第三章内容）
第二章要点——关系数据库
关系有三种类型：基本表，查询表，视图表（虚表）。
关系操作有关系代数和关系演算。
关系数据语言：关系代数语言（ISBL…）;关系演算语言（元组ALPHA…，域QBE…）;两重特点都有的SQL…
【这一部分内容在第6章还有介绍】
1.关系的完整性
实体 完整性
参照 完整性
用户定义 的 完整性
（我之所以打上空格是为方便理解，理解为完整性针对于实体，针对于参照关系，针对于用户做的定义的三种情况）。
一句话概括：
实体完整性
针对主码，唯一性标识（默认unique），非空（默认not null）。参照完整性
针对外码，可以为null表示未分配，非空值时必须是原表（即被参照表S）主码KS有的数据，不可以创造一个对应主码KS中没有的值。用户定义的完整性
用户自己加的条件不可违约，比如not null ，unique，值域。
2.关系代数
要不直接看离散吧…（上考场前看一眼效果更佳）
第三章要点——SQL:对模式和外模式的DDL,DQL,DML
1.SQL介绍
特点：综合统一，高度非过程化（透明），面向集合，独立又嵌入，多种使用方式，简洁易学。功能及其动词：概念：支持SQL的数据库管理系统同样支持关系数据库三级模式结构，如图3。
以下2,3,4在模式,索引在内模式，视图在外模式：
2.数据定义DDL
模式
在CREATE SCHEMA中可以接受CREATE TABLE,CREATE VIEW和GRANT子句。
即CREATE SCHEMA <模式名> AUTHORIZATION <用户名>[<表定义子句>|<视图定义子句>|<授权定义子句>]
定义: CREATE SCHEMA 模式名 AUTHORIZATION 用户名删除: DROP SCHEMA 模式名 CASCADE/RESTRICT(级联/限制)
基本表
定义: CREATE TABLE 表名 (
列名 数据类型 列级完整性约束条件， …（多个）…，表级完整性约束条件)；删除: DROP TABLE 表名 CASCADE/RESTRICT(级联/限制)修改:ALTER TABLE 表名
[ADD [COLUMN] 新列名 数据类型 完整性约束]
[ADD 表级完整性约束]
[DROP [COLUMN] 列名 CASCADE/RESTRICT]
[DROP CONSTRAINT 完整性约束 CASCADE/RESTRICT]
[ALTER COLUMN 列名 数据类型]数据类型:自己找一下哈，网上的图太糊啦，等有空再改改。
索引（其实属于内模式的范畴）
相当于建了一个指针，查询更快。
定义: CREATE （UNIQUE/CLUSTER）INDEX 索引名删除: DROP INDEX 索引名修改:ALTER INDEX 旧索引名 RENAME TO 新索引名
数据字典
一组系统表，记录了数据库中所有的定义信息，包括关系模式定义，视图定义，索引定义，完整性约束定义，各类用户对数据库的操作权限，统计信息等。执行数据定义就是在更新数据字典，是查询优化和查询处理的重要依据
3.数据查询DQL
SELECT [ALL|DISTINCT] <目标列表达式>[,<目标列表达式>]…
FROM <表名或视图名>[,<表名或视图名> ]…| (SELECT语句)
[AS]<别名>
[ WHERE <条件表达式> ]
[ GROUPBY <列名1> [ HAVING <条件表达式> ]]
[ ORDER BY <列名2> [ ASC|DESC] ];
这部分内容太多啦，有下面几种情况，看看例子就好。
单表，连接，嵌套，集合，基于派生表
格式总结
目标列表达式格式
(1）*
(2) <表名>.*
(3) COUNT([DISTINCT|ALL]* )
(4) [<表名>.]<属性列名表达式>[,<表名>.]<属性列名表达式>…
其中<属性列名表达式>可以是由属性列、作用于属性列的
聚集函数和常量的任意算术运算(+，-，*，1)组成的运算公式
4.数据更新DML
增
INSERT
INTO <表名> [(<属性列1>[,<属性列2 >…)]
VALUES (<常量1> [,<常量2>]… );
删
DELETE FROM
<表名>
[WHERE <条件>];
改
UPDATE <表名>
SET <列名>=<表达式>[,<列名>=<表达式>]…
[WHERE <条件>];
5.空值的处理
判断 IS NULL 或者 IS NOT NULL
约束：完整性约束条件。主码和not null的属性不能为null。
运算：真值表
6.视图：对外模式DDL,DQL,DML.
DDL：
CREATE VIEW
<视图名> [(<列名> [,<列名>…)]
AS <子查询>
[WITH CHECK OPTION];
DROP VIEW <视图名>[CASCADE];
DQL：视图消解。查询select发现from某视图后，找到视图的定义（又包含select）转化为一个新的select对基本表的查询，然后去查基本表。
DML：有些视图不能更新，通常只要认为仅行列子集视图可更新，不建议通过视图更新。
第四章要点——SQL:DCL之数据库安全性
(先只整理一部分)
1.自主存取控制——授权的授予与收回
用户可以自主地决定将数据的存取权限授予何人，决定是否也将授权的权限授予给别人，称这样的存取控制为自主存取控制。
权限：数据库对象与操作类型
GRANT（不可循环授权）
格式
GRANT 权限 …
ON 对象类型 对象名 …
TO 用户/角色 …
REVOKE
格式
REVOKE 权限 …
ON 对象类型 对象名 …
FROM 用户/角色 …CASCADE/RESTRICT
用户user权限：DBA>RESOURCE>CONNECT
CREATE USER usename WITH [DBA/RESOURCE/CONNECT] (非sql标准)
角色role:定义某一组权限为一个role以便授予权限
2.强制存取控制
主体：实际用户，代表用户的各进程。敏感度标记：许可证级别。
客体：文件，基本表，索引，视图等。敏感度标记：密级（TS>=S>=C>=P）。
第五章要点——SQL:DCL之数据库完整性
1.实体完整性
实体完整性针对增改主码为Null或不唯一。
定义
在create table 时，PRIMARY KEY ( K ),
检查时机（检查方法）：增，改后
实体完整性检查方法，全表扫描，DBMS自动建立unique索引
违约处理：全拒绝
2.参数完整性
参照完整性针对增删改后外码没有原表(被参照表)的依靠（在原表中不存在该码值）
（方便记忆，原表(为主码的那个)就是被参照表，现表(为外码的)为参照表，别搞混)
定义
在create table 时，FOREIGN KEY ( F ) REFERENCES 被参照表S(KS),
检查时机
参照完整性的检查就是检查（参照表插入元组，修改外码；被参照表删除元组，修改主码）四种情况。
违约处理
参照完整性违约处理方式默认全拒绝
或需在create table 时标出——
被参照表中修删时：参照表on delete(update) cascade（级联删除/更新）;
参照表修增时：参照表on delete no action (set null);on update cascade（拒绝，设空，级联更新）
注意，↑设空值的方法可能符合参照完整性但违反实体完整性。
3.用户定义的完整性
用户完整性定义：
在create table 时，针对某具体应用的语义要求，
在属性(列)上，列值not Null，unique， check() 的要求（列级约束）
在元组(行)上（不同属性间相互有关联有约束），使用check() 定义约束条件（表级约束）对值域约束。
check举例（是否满足某一表达式）：CHECK (SSEX IN (‘男’，‘女’))表示性别只允许为男或女检查时机：插、修 属性值约束方法：拒绝
4.完整性约束命名
命名完整性约束条件为了删除约束条件时好删除。完整性约束命名子句
CONSTRAINT 完整性约束条件名 完整性约束条件定义时写到create table中，修改时在alter table中改。
用alter table 中ADD,DROP对约束条件增删改（修改是先删再增）
5.断言
断言创建后，任何对断言中所涉及的关系的操作都会触发关系数据库管理系统对断言的检查，任何使断言不为真的操作都会被拒绝执行。只有真假两种返回值。
创建断言
CREATE ASSERTION 断言名 CHECK子句
删除断言
DROP ASSERTION 断言名
6.触发器
事件-条件-动作规则（由事件驱动）。只有表的拥有者可以在表上创建触发器。触发器只能定义在基本表上，触发器名和表名必须在同一模式下。执行失败则不发生变化。
CREATE TRIGGER 触发器名
BEFORE/AFTER 触发事件 ON 表名//在事件的前还是后/
REFERENCING NEW/OLD ROW/TABLE AS 变量//引用的变量是新的还是老的/
FOR EACH ROW/STATEMENT//行级/语句级/
[WHEN 触发条件] 触发动作体
使用两个例题就懂了。
事件后触发，语句级触发器，未使用WHEN触发条件，直接就激活。其中值得注意的是DELTA是一个关系名，模式与Student相同，包含的元组是INSERT语句增加的元组。
事件前触发，行级触发器，触发动作体为一个PL/SQL过程块。
第六章要点——设计开发：关系数据理论（仅范式部分）
1.函数依赖
感觉一下就行。
2.第一范式1NF
1NF要求不可表中有表，属性不可再分。
3.第二范式2NF
2NF要求非主属性对码是完全函数依赖。
（我们可以肤浅的认为，一个关系模式就是一个表（一个基本表表示的关系比如SC(Sno，Cno)就是一个关系模式）），实例就是表某一时刻的状态。
4.第三范式3NF
3NF要求传递依赖也拆分(投影分解法)
(不讨论平凡的函数依赖也就是要求Y不包含Z)
5.BCNF
BCNF(修正3)要求每一个决定因素都包含码：所有非主属性对每一个码都是完全函数依赖，所有主属性对每一个不包含它的码也是完全函数依赖，没有任何属性完全依赖于非码的任何一组属性。（BCNF在函数依赖的范畴内已实现模式的彻底分解，已高度规范化）
思维导图——暂无，回头补
先来不及整理了，回头再画。
如果觉得《数据库系统概论（王珊 萨师煊版）范式之前要点一览（简略）》对你有帮助，请点赞、收藏，并留下你的观点哦！
