数据库中的数据表-a表数据更新到b表

一、DBS系统组成

一、DB的概念及特点：

2、DBS的特点及组成：

3. 数据库管理系统的功能：

4. DBA的职责

2. DB的三级模式和关系数据模型示例

三、SQL语言面向集成运行模式的特点。 高度非程序化两种使用方式，语法结构统一。 语言简洁易学易用。 四、视图的定义

视图是从一个或多个关系（基表或现有视图）派生的关系。 它是数据库系统的一个重要机制。

5、视图和基本表的区别和关系视图是虚拟表，一般不创建索引。 SQL一般不提供修改视图定义的语句。 视图中数据的更新是有限的。 6.数据模型三要素 数据结构 数据操作完整性约束 7.事务 8.三种并发操作 丢失更新：写-写冲突，加排他锁 X 读“脏”数据：写-读冲突，加共享锁S 不可重复读：读写冲突 九、数据库系统的基本特征总体数据结构化数据共享程度高数据独立程度高数据控制能力强。 十、数据库数据的基本特点 可共享 数据独立 数据冗余小，易于扩展统一管理和控制。 11. 自然连接和等价连接的区别 自然连接要求等分量必须有共同的属性； 等效连接不需要它。 自然连接要求从结果中删除任何重复的属性名称； 等值连接没有。 十二、SQL语言分类 DDL数据定义语言：负责创建、修改、删除表、索引和视图等对象，由动词create、alter、drop组成。 DML数据操作语言：负责数据库中数据的插入、修改、查询和删除，由动词insert、update、select、delete组成。 DCL数据控制语言：用于授予和撤销用户对数据的操作权限，由动词grant和revoke组成。 13． SQL 数据类型 14. 数据完整性约束 15. 集合函数 16. 特殊运算符

\begin{array}{|c|c|} \hline \text{运算符号} & \text{含义}\\ \hline in, not\ in & 检查属性值是否为一组值中的一个\\ \ hline between...and...,not\between...and... & 检查属性值是否属于某个范围\\ \hline is\ null, is\ not\ null & 检查属性值是否为空\\ \hline like ,不像&字符串匹配，"\%"表示任意长度的字符串（可以是0,0），"\_"表示单个字符\\ \hline \end{array}\\

十七、查询方式

1.群组查询

2.排序查询

3.多关系连接查询

cross connection：交叉连接，两张表之间没有连接

select [distinct/all] <目标列清单>
from <关系名[别名]清单>

2.内连接：Inner join，两个表之间具有共同属性的属性。

select [distinct/all] <目标清单>
from <关系名1> inner join <关系名2>
on <连接条件>

3.外连接：outer join

4.自连接：self join

4.嵌套查询

18.select语句的set操作 19.view操作

1.定义视图

create view <视图名>

as <子查询>
[with check option]

2.删除视图

drop view

20.引用完整性约束的实现策略 限制策略：无动作 级联策略：级联空策略 21.完整性约束 实体完整性：通过初级代码定义完成引用完整性：外部代码约束引用和引用 完整性约束 用户自定义完整性：基于检查约束关于属性和元组 22、触发器的基本概念 23、访问控制 24、规范化

1.非规范化数据的问题

2.规范化数据的好处

找出所有没有选修1号课程的学生姓名；
select sname
from student
where sno not in --“ not in ”等同于“ <> all ”
(select sno
from grade
where cno='1')

找出选修了全部课程的学生姓名。
--（提示：可找出这样的学生，没有一门课程是他不选修的。）
Select sname from student
Where not exists ( select cno from course
Except
Select cno from grade where grade.sno=student.sno )

数据库范式 1NF 2NF 3NF BCNF（示例）

一个设计范式（paradigm，database design paradigm，数据库设计范式）是符合一定层次的关系模式的集合。 构建数据库必须遵循一定的规则。 在关系数据库中，这个规则就是范式。 关系数据库中的关系必须满足一定的要求，即满足不同的范式。 目前关系型数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF） ). 满足最低要求的范式是第一范式（1NF）。 在第一范式的基础上进一步满足更多要求的第二范式（2NF）称为第二范式（2NF），其余范式类推。 一般来说，数据库只需要满足第三范式（3NF）即可。 下面我们举例介绍第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。

在创建数据库的过程中，归一化就是将其转化为表的过程，可以使从数据库中得到的结果更加具体。 这可能会复制数据库中的数据，从而导致创建冗余表。 规范化是在识别数据库中的数据元素和关系，并在每个表中定义所需的表和项目之后的一个细化过程。

这是规范化的示例：

Customer    ; Item purchased ; Purchase price 
Thomas      ; Shirt          ; $40 

Maria Tennis; shoes          ; $35 
Evelyn      ; Shirt          ; $40 
Pajaro      ; Trousers       ; $25

如果上表是用来保存商品价格的，而你要删除其中一个客户，那么你必须同时删除一个价格。 归一化就是为了解决这个问题。 您可以将此表转换为两张表，一张用于存储有关每个客户及其购买的物品的信息，另一张用于存储有关每种产品及其价格的信息。 从一个表中添加或删除不会影响另一个。

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

1. 第一范式（1NF）

在任何关系数据库中，第一范式（1NF）是关系模式的基本要求，不满足第一范式（1NF）的数据库不是关系数据库。

所谓第一范式（1NF）是指数据库表的每一列都是一个不可分割的基础数据项，同一列中不能有多个值，即一个实体中的一个属性不能有多个值或重复属性。 如果有重复的属性，可能需要定义一个新的实体。 新实体由重复的属性组成。 新实体与原始实体之间存在一对多关系。 第一范式 (1NF) 表的每一行仅包含一个实例的信息。 例如图3-2的员工信息表，员工信息不能一列显示，也不能一列显示两列或多列； 员工信息表的每一行只代表一个员工的信息，一个员工的信息在表中只出现一次。 简而言之，第一范式是没有重复的列。

2. 第二范式（2NF）

第二范式（2NF）是在第一范式（1NF）的基础上建立的，即要满足第二范式（2NF）必须先满足第一范式（1NF）。 第二范式 (2NF) 要求数据库表中的每个实例或行必须是唯一可区分的。 为了实现区分，通常需要在表中增加一列来存储每个实例的唯一标识。 如图3-2所示，在员工信息表中增加员工ID（emp_id）列，因为每个员工的员工ID都是唯一的，所以可以唯一区分每个员工。 这种唯一的属性列称为主键或主键、主键。

第二范式（2NF）要求实体的属性完全依赖于主键。 所谓完全依赖，就是不能有一个属性只依赖于主关键字的一部分。 如果存在，那么这个属性应该和主关键字的这部分分开，形成一个新的实体。 新实体和原实体是一对多的关系。 为了实现区分，通常需要在表中增加一列来存储每个实例的唯一标识。 简而言之，第二范式是非主属性不部分依赖于主键。

3. 第三范式（3NF）

要满足第三范式（3NF），必须首先满足第二范式（2NF）。 简而言之，第三范式（3NF）要求数据库表中不包含其他表中已包含的非主键信息。 例如，有一个部门信息表，其中每个部门都有部门编号（dept_id）、部门名称、部门简介等信息。 那么，在图3-2的员工信息表中列出了部门编号后，就不能在员工信息表中添加部门名称、部门简介等部门相关信息了。 如果没有部门信息表，也应该按照第三范式（3NF）构造，否则会出现大量的数据冗余。 简而言之，第三范式是属性不依赖于其他非主属性。

数据库设计三大范式应用实例分析

数据库的设计范式是数据库设计需要满足的规范。 满足这些规范的数据库结构简洁明了。 同时，insert、delete、update操作也不会出现异常。 反而是乱七八糟，不仅给数据库程序员带来麻烦，而且看起来可恶，还可能存储大量不必要的冗余信息。

设计范式难懂吗？ 不行，大学课本给了我们一堆数学公式，我们当然看不懂，也记不住。 我们中的许多人根本不按照范式设计数据库。

从本质上讲，设计范式可以用非常生动和简洁的文字清楚地表达出来。 本文将以通俗易懂的方式对范式进行讲解，并以作者设计的一个简单的论坛数据库为例，讲解如何将这些范式应用到实际项目中。

范式描述

第一范式（1NF）：数据库表中的字段都是单一的属性，不能进一步划分。 这个单一属性由基本类型组成，包括整型、实型、字符型、逻辑型、日期型等。

例如，以下数据库表是第一范式：

字段1  字段2  字段3  字段4 

而这样的数据库表不符合第一范式：

字段1  字段2  字段3  字段4 
　　  　 字段3.1  字段3.2  　　 

显然，在目前的任何关系数据库管理系统（DBMS）中数据库中的数据表，傻子不可能做出不符合第一范式的数据库，因为这些DBMS不允许你将数据库表的一列一分为二或更多列。 因此，你不可能在现有的DBMS中设计出不符合第一范式的数据库。

第二范式（2NF）：非关键字段对数据库表中任一候选关键字段不存在部分函数依赖（部分函数依赖是指组合键中的某些字段决定非关键字段的情况），即也就是说，所有非关键字段都完全依赖于任何一组候选关键字。

假设选课关系表为SelectCourse(学号、姓名、年龄、课程名称、成绩、学分)，关键字为组合关键字(学号、课程名称)，因为有如下确定关系：

(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)

这个数据库表不满足第二范式，因为有如下判断关系：

(课程名称) → (学分)
(学号) → (姓名, 年龄)

即存在组合键中字段决定非键的情况。

由于不符合2NF，所以这个选课关系表会存在以下问题：

(1)数据冗余：如果同一门课程有n名学生选修，则“学分”会重复n-1次； 如果同一个学生上过m门课，名字和年龄会重复m-1次。

(2)更新异常：如果某门课程的学分有调整，则必须更新数据表中所有行的“学分”值，否则同一门课程的学分会不同。

(3)插入异常：假设要开设一门新课程，但还没有人上过。 这样，由于没有“学号”关键字，就无法将课程名称和学分记录到数据库中。

(4)删除异常：假设一组学生完成了选修课，这些选修记录应该从数据库表中删除。 但与此同时，课程名称和学分信息也被删除。 显然，这也会导致插入异常。

将选课关系表SelectCourse改成如下三张表：

学生：Student(学号, 姓名, 年龄)；
课程：Course(课程名称, 学分)；
选课关系：SelectCourse(学号, 课程名称, 成绩)。

这样的数据库表符合第二范式，消除了数据冗余、更新异常、插入异常、删除异常。

另外，所有的单键数据库表都符合第二范式，因为不能存在复合键。

第三范式（3NF）：在第二范式的基础上，如果数据表中任意一个候选关键字段不存在非关键字段的传递函数依赖，则符合第三范式。 所谓传递函数依赖，是指如果存在“A→B→C”的判定关系，则C的传递函数依赖于A。因此，满足第三范式的数据库表不应该有如下依赖关系：

关键字段 → 非关键字段x → 非关键字段y

假设学生关系表为Student(学号、姓名、年龄、学院、学院所在地、学院电话)，关键字为单个关键字“学号”，因为有如下确定关系：

(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)

该数据库符合2NF，但不符合3NF，因为有如下判断关系：

(学号) → (所在学院) → (学院地点, 学院电话)

即非关键字段“College Location”和“College Phone”对关键字段“Student Number”存在传递函数依赖。

还有数据冗余、更新异常、插入异常、删除异常，读者可以自行分析。

将学生关系表分为以下两张表：

学生：(学号, 姓名, 年龄, 所在学院)；
学院：(学院, 地点, 电话)。

这样的数据库表符合第三范式，消除了数据冗余、更新异常、插入异常、删除异常。

Boise-Codd Normal Form (BCNF)：在第三范式的基础上，如果数据库表中任意字段对任意候选键字段不存在传递函数依赖，则符合第三范式。

假设仓库管理关系表为StorehouseManage(仓库ID,入库物品ID,管理员ID,数量)，有一个管理员只在一个仓库工作； 一个仓库可以存储多个项目。 该数据库表中存在如下判定关系：

(仓库ID, 存储物品ID) → (管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)

因此，（仓库ID，存储项ID）和（管理员ID，存储项ID）是StorehouseManage的候选关键字，表中唯一的非关键字段是数量，符合第三范式。 但是，由于存在以下决定关系：

(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)

即存在key域决定key域的情况，所以不符合BCNF范式。 它将有以下异常：

(1)删除异常：清空仓库时，删除所有“入库物品ID”和“数量”信息，同时删除“仓库ID”和“管理员ID”信息。

(2) 插入异常：当仓库没有存放任何物品时，不能为仓库分配管理员。

(3) 更新异常：如果仓库换了管理员，则必须修改表中所有行的管理员ID。

将仓库管理关系表分解为两个关系表：

仓库管理：StorehouseManage(仓库ID, 管理员ID)；
仓库：Storehouse(仓库ID, 存储物品ID, 数量)。

这样的数据库表符合BCNF范式，消除了删除异常、插入异常、更新异常。

范式应用

让我们逐步获取论坛数据库，其中包含以下信息：

（1） 用户：用户名，email，主页，电话，联系地址
（2） 帖子：发帖标题，发帖内容，回复标题，回复内容

我们第一次将数据库设计为仅存在表：

用户名  email  主页  电话  联系地址  发帖标题  发帖内容  回复标题  回复内容 

此数据库表符合第一范式，但没有一组候选键可以确定数据库表的整行，唯一的关键字段用户名不能完全确定整个元组。 我们需要添加“Post ID”和“Reply ID”字段，即修改表为：

用户名  email  主页  电话  联系地址  发帖ID  发帖标题  发帖内容  回复ID  回复标题  回复内容 

这样数据表中的关键字（用户名、帖子ID、回复ID）就可以确定整行：

(用户名,发帖ID,回复ID) → (email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容)

但是数据库中的数据表，这样的设计并不符合第二范式，因为有如下确定关系：

(用户名) → (email,主页,电话,联系地址)
(发帖ID) → (发帖标题,发帖内容)
(回复ID) → (回复标题,回复内容)

即非关键字段的某些功能依赖于候选关键字段。 显然，这种设计会导致大量的数据冗余和操作异常。

我们将数据库表分解为（下划线的关键字）：

（1） 用户信息：用户名，email，主页，电话，联系地址
（2） 帖子信息：发帖ID，标题，内容
（3） 回复信息：回复ID，标题，内容
（4） 发贴：用户名，发帖ID
（5） 回复：发帖ID，回复ID

这样的设计满足了1st、2nd、3rd范式和BCNF范式的要求，但是这样的设计是最好的吗？

不确定。 通过观察可以看出，第4项“帖子”中的“用户名”和“帖子ID”是1:N的关系，所以我们可以将“帖子”合并到第2项的“帖子信息”中； item 5 reply这个item中的post ID和reply ID也是1:N的关系，所以我们可以把reply合并到第三个item的reply message中。 这样可以在一定程度上减少数据冗余。 新设计是：

（1） 用户信息：用户名，email，主页，电话，联系地址
（2） 帖子信息：用户名，发帖ID，标题，内容
（3） 回复信息：发帖ID，回复ID，标题，内容

数据库表1显然满足所有范式的要求；

数据库表2中，非关键字段“Title”和“Content”对关键字段“Post ID”存在部分功能依赖，不符合第二范式要求，但这种设计将不会导致数据冗余和异常运行；

数据库表3中，非关键字段“title”和“content”对关键字段“reply ID”也存在部分函数依赖，不符合第二范式要求，但与数据库表类似2、这种设计也不会造成数据冗余和异常运行。

由此可见，没有必要强行满足范式的要求。 对于1:N的关系，当1的边合并到N的边时，N的边不再满足第二范式，但是这样设计更好！

对于M:N关系，不能将M的一侧或N的一侧合并到另一侧，既不符合范式要求，也会导致操作异常和数据冗余。

对于1:1的关系，我们可以将左边的1或者右边的1合并到另一边。 设计不符合范式要求，但不会造成运行异常和数据冗余。

综上所述

满足范式要求的数据库设计，结构清晰，同时可以避免数据冗余和异常操作。 这并不是说不符合范式要求的设计就一定是错误的。 在数据库表中1:1或1:N关系的特殊情况下，合并造成的不符合范式要求是合理的。

当我们设计数据库时，我们必须始终考虑范式的要求。

参考：