版权声明:版权归作者所有,转发请标明 https://blog.csdn.net/weixin_40087851/article/details/81983494
视图
隐藏特定的数据
- 例如职员查看教师表时,不应看到工资。
虚关系:不需要预先存储执行结果。
- 执行select * from s where 会计算出查询结果并存储下来。
- 当底层元组改变,存储的结果将与现结果不匹配。
当定义一个视图时,数据库系统存储视图的定义本身,而非存储执行结果
- 但需要注意:用于定义视图的关系被修改,视图将过期。
定义视图
create view faculty(ID,name,dept_name) as
select ID,name,dept_name
from instructor2;
两个关系创建视图,存在插入问题
- 向视图中插入一条元组
- 关系表1插入一条元组
- 关系表2插入一条元组
- 向视图中插入一条元组
with check option
- 视图定义的末尾包含with check option子句来定义视图。
- 解决问题:如果向视图中插入一条不满足视图的where子句条件的元组,数据库系统将拒绝插入操作。
select *
from instructor2
where dept_name='math' with check option;
事务
查询和更新语句的序列组合
commit work:提交当前事务
rollback work:回滚当前事务(事务执行过程中出错)
一个事务在完成所有步骤后提交,不能完成所有动作时回滚
默认情况下每个sql语句自成一个事务,执行完提交
实例
授权
SQL标准包括select、insert、update和delete权限。
授予权限
grant 权限 on 关系名 to 用户;
grant select on department to Amit,Satoshi;
- 回收权限
revoke 权限 on 关系名 from 用户;
revoke select on department from Amit,Satoshi;
索引
- 加了主键的表:聚集索引
create index 索引名 on 关系名(属性);
create index studentID_index on student(ID);
内部使用平衡树,数据库查询数据的速度增快,写入数据(增、删)的速度下降,保持平衡树的平衡状态。
- B树、B+树
- B树每个磁盘块不仅存储主键,还存储主键之外的数据。
- B+树非叶子结点的每个磁盘块仅存储主键
- B+树的磁盘读写的代价更低。B+树内部结点没有指向关键字具体信息的指针,内部结点相对于B树更小。
- B+树查询更加稳定。非终端结点不存储数据信息,仅是叶子结点中关键字的索引,每一个关键字和其数据的查询均是从根到叶子的路径,查询长度相同,效率相当。
- 参考:https://blog.csdn.net/qq_26768741/article/details/53164202
- 参考:https://blog.csdn.net/zwz2011303359/article/details/63262541
- B树、B+树
聚集索引
- 包含记录的文件按照某个搜索码指定的顺序排序。
非聚集索引
- 搜索码指定的顺序与文件中记录的物理排序不同的索引。
稠密索引
- 文件中的每一个搜索码值都有一个索引项。
稀疏索引
- 只为搜索码的某些值建立索引。
只有索引是聚集索引时才能使用稀疏索引。
索引项:由一个搜索码值和指向具有该搜索码值的一条或多条记录的指针构成。
稠密索引比稀疏索引更快的定位一条记录。
稀疏索引占空间较小,插入和删除时所需的维护开销小。
范式
第一范式:所有域都是原子的。
第二范式:完全依赖
- AB是主键 AB->C , A->C(部分依赖)
第三范式:不存在传递依赖
- A->B , B->C(传递依赖)
BCNF范式:一般不要求。
数据库设计阶段
概念设计阶段:实体—联系模型
逻辑设计阶段:关系数据模型
物理设计阶段:文件组织格式和索引结构选择
事务
另一篇博文有介绍:https://blog.csdn.net/weixin_40087851/article/details/81878307