软考数据库&数据库建模复习指南

Posted 2021-12-05 小哈里

1、根据考纲

数据库知识
（1）数据库模型（概念模式、外模式、内模式）
（2）数据模型，ER图，规范化
（3）数据操作
（4）数据库语言
（5）数据库管理系统的功能和特征
（6）数据库的控制功能
（7）数据仓库和分布式数据库基础知识

数据库建模
（1）设计关系模式：掌握给定一个实际的应用问题如何设计E-R模型，如何将E-R模型转换成关
系模式，确定联系类型、主键、候选键、外键，判断关系模式规范化的程度。
（2）数据库语言（SQL）：掌握给定一个实际的应用问题如何用SQL进行数据定义（创建表、
视图）、完整性定义及权限定义。
（3）数据库访问：掌握常用数据库的访问方法。

考点主要集中在：E-R模型、关系代数、元组演算、规范化理论（键、范式、模式分解）、SQL语言等。
考点主要有：E-R模型、关系模式、主键、外键，偶尔出现SQL语言方面的试题。

2、数据库模式及ER模型

数据库是长期存储在计算机内的、有组织的、可共享的数据集合，数据库系统是指在计算机信息系统中引入数据库后的系统，一般由数据库、数据库管理系（DataBaseManagementSystem，DBMS）、应用系统、数据库管理员（DataBase Administrator，DBA）和用户构成。

数据库系统的结构可以有多种不同的层次 或不同的角度，其中典型的是三级划分法 ，其中包括三级模式和两级映射 。下面将就该主题，以及ER模型 展开论述.

从图5-1可以看出，整个数据库体系由数据库管理系统（DBMS）进行管理，其内容涉及底层的数据存储问题，顶层涉及与用户的交互，这种层次的划分，主要目标是使数据库体系内部耦合度更低，变得更为灵活。

• 外模式 也称为子模式或用户模式 ，它对应的是我们平时所用到的数据库视图 。外模式用来描述用户（包括程序员和最终用户）看到或使用的那部分数据的逻辑结构，是数据库用户的数据视图 ，是与某一应用有关的数据的逻辑表示。一个数据库可以有多个外模式，一个应用程序只能使用一个外模式 。
• 概念模式也称为模式或逻辑模式 ，它对应我们平时所用到的数据表 。概念模式是数据库中全体数据的逻辑结构和特征的描述 ，是所有用户的公共数据视图 ，用以描述现实世界中的实体及其性质与联系，定义记录、数据项、数据的完整性约束条件及记录之间的联系。概念模式通常还包含有访问控制、保密定义和完整性检查等方面的内容，以及概念/物理之间的映射。一个数据库只有一个概念模式 。
• 内模式 对应于物理级数据库 ，是数据物理结构和存储方式 的描述，是数据在数据库内部的表示方式。内模式不同于物理层，它假设外存是一个无限的线性地址空间。内模式定义的是存储记录的类型、存储域的表示和存储记录的物理顺序 ，以及索引和存储路径等数据的存储组织。一个数据库只有一个内模式。
• 在数据库系统的三级模式中，模式是数据库的中心与关键；
  内模式依赖于概念模式，独立于外模式和存储设备；
  外模式面向具体的应用，独立于内模式和存储设备；
  应用程序依赖于外模式，独立于模式和内模式。

从图5-1可以看出，三级模式实际对应着数据库系统中的三个层次，这三个层次划分出来以后，为了达到“一个层次的变化不对其它两个层产生影响”的效果，提出了两级映射 。两级映射分别是：外模式与概念模式之间的映射、概念模式与内模式之间的映射。

• 外模式与概念模式之间的映射 ：用于维护数据库的逻辑独立性 。也就是说，有了这个映射，使得数据的逻辑结构改变时，应用程序不需要改变，只需要改变映射中的对应关系即可达到目的。
• 概念模式与内模式之间的映射 ：用于维护数据库的物理独立性 。也就是说当数据的物理存储改变时，应用程序不需要改变。

ER模型：
数据库系统是对现实世界中数据的一种抽象，正如在“数据库系统功能和特性”知识点中所描述的，首先我们将通过概念模型将现实世界抽象成为信息世界，然后再抽象成为基本数据模型。而最常使用的概念模型就是E-R模型 ，本知识点则主要围绕着这个重要概念阐述。

图5-2 展示了一个简单的ER模型，我们通过该图进行ER模型的概念入门：
实体 ：客观存在并可相互区别的事物，可以是具体的人、事、物，也可以是抽象的概念或联系。图5-2中的**“学生”与“课程”** 便是实体。
属性 ：实体所具有的某一特性称为属性，通常一个实体可以由多个属性来描述。图5-2中“学生”实体旁边的**“学号”、“姓名”、“班级号”** 便是属性。
联系 ：实体内部的联系通常是指组成实体的各属性间的关系。图5-2中**“选课”便是联系** 。

（1）ER模型实体联系类型
一对一联系（1:1）：对于实体集A中的每一个实体，实体集B中至多有一个实体与之联系。例：一个班级只有一个班主任 ，一个班主任也只在一个班级中任职。
一对多联系（1:n）：对于实体集A中的每一个实体，实体集B中有n（n>0）个实体与之联系。反之，实体集B中的每一个实体，实体集A中至多只有一个实体与之联系。例：一个班级中有许多学生 ，而每个学生只在一个班级中学习。
多对多联系（m:n）：对于实体集A中的每一个实体，实体集B中有n（n>0）个实体与之联系。反之，实体集B中的每一个实体，实体集A中有m（m>0）个实体与之联系。一门课程同时有许多学生选修，而一个学生也可以选修多门课程 。如图5-2所示，该ER模型便属于m:n型。

（2）E-R模型的集成
在数据库的概念设计过程中，由于系统都存在一定的复杂度，一次性设计全局E-R图将存在较大风险，所以一般会先设计各子系统的局部E-R图 ，然进行集成。
但由于各子系统应用所面临的问题不同，且通常是由不同的设计人员进行局部视图设计，这就导致各个局部E-R图之间必定会存在许多不一致的问题，称之为冲突。因此，在合并E-R图时，不能简单地将各个局部E-R图画到一起，而是必须着力消除各个局部E-R图中的不一致，以形成一个能为全系统中所有用户共同理解和接受的统一的概念模型。

各局部E-R图之间的冲突主要有三类 ，分别是属性冲突、命名冲突和结构冲突。
1）属性冲突 。属性冲突包括属性域冲突和属性取值冲突 。属性冲突理论上好解决，只要换成相同的属性就可以了，但实际上需要各部门协商，解决起来并不简单。
2）命名冲突 。命名冲突包括同名异义和异名同义 。处理命名冲突通常也像处理属性冲突一样，通过讨论和协商等行政手段加以解。
3）结构冲突 。结构冲突包括同一对象在不同应用中具有不同的抽象 ，以及同一实体在不同局部E-R图中所包含的属性个数和属性排列次序不完全相同。对于前者的解决办法是将属性变换为实体或实体变换为属性，使同一对象具有相同的抽象。对于后者的解决办法是使该实体的属性取各局部E-R图中属性的并集，再适当调整属性的次序。

（3）E-R模型转关系模式
E-R图向关系模式的转换属于数据库的逻辑设计阶段 的工作，该阶段需要将E-R模型转换为某种DBMS能处理的关系模式 ，具体转换规则如下：
1）一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的主键就是关系的主键 。
2）一个1:1联系可以转换为一个独立的关系模式 ，也可以与任意一端对应的关系模式合并 。如果转换为一个独立的模式，则与该联系相连的各实体的主键和联系本身的属性均转换为关系的属性，每个实体的主键均是该关系的键属性；如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的主键和联系本身的属性。
3）一个1:n联系可以转换为一个独立的关系模式 ，也可以与任意n端对应的关系模式合并 。如果转换为一个独立的模式，则与该联系相连的各实体的主键和联系本身的属性均转换为关系的属性，而关系的主键为n端实体的主键；如果与n端实体对应的关系模式合并，则需要在该关系模式的属性中加入端关系模式的主键和联系本身的属性。
4）一个m:n联系转换为一个独立的关系模式，与该联系相连的各实体的主键以及联系本身的属性均转换为关系的属性，而关系的主键为各实体主键的组合。
5）三个以上实体间的一个多元联系可以转换为一个独立的关系模式，与该联系相连的各实体的主键和联系本身的属性均转换为关系的属性，而关系的主键为各实体主键的组合。
另外，还有三种情况是需要特别注意的：
1）多值属性的处理。如果E-R图中某实体具有一个多值属性，则应该进行优化，把该属性提升为一个实体，通常称为弱实体；或者在转化为关系模式时，将实体的主键与多值属性单独构成一个关系模式。
2）派生属性的处理。因为派生属性可由其他属性计算得到，因此，在转化成关系模式时，通常不转换派生属性。
3）在面向对象模型中，关系模式就对应类，关系模式的属性就对应类的属性。

3、数据操作

关系运算：关系代数的基本运算主要有并、交、差、笛卡尔积、选择、投影、连接和除法运算。
元组演算：在元组演算中，元组演算表达式简称为元组表达式，其一般形式为{t|P(t)}，其中，t是元组变量，表示一个元数固定的元组；P是公式，在数理逻辑中也称为谓词，也就是计算机语言中的条件表达式。{t|P(t)}表示满足公式P的所有元组t的集合。

规范化理论的作用：
不同的人对于相同的东西可以建立不同的模型，如何衡量模型建立的好坏？换而言之，按照什么原则建立模型？这个原则就是规范化理论 。
前面已经介绍了什么是规范化理论，那么在数据库设计中，规范化理论有什么作用，解决了什么问题呢？下面我们通过一个实例来分析这个问题。
设有一个关系模式R（SNAME，CNAME，TNAME TADDRESS），其属性分别表示学生姓名、选修的课程名、任课教师姓名和任课教师地址。仔细分析一下，就会发现这个模式存在下列存储异常的问题：
（1）数据冗余：如果某门课程有100个学生选修，那么在R的关系中就要出现100个元组 ，这门课程的任课教师姓名和地址也随之重复出现100次。
（2）修改异常：由于上述冗余问题，当需要修改这个教师的地址时，就要修改100个元组中的地址值，否则就会出现地址值不一致的现象。
（3）插入异常：如果不知道听课学生名单，这个教师的任课情况和家庭地址就无法进入数据库；否则就要在学生姓名处插入空值。
（4）删除异常：如果某门课程的任课教师要更改，那么原来任课教师的地址将随之丢失。因此，关系模式R虽然只有四个属性，但却是性能很差的模式。产生这些异常的原因与关系模式属性值之间的联系直接有关。在模式R中，学生与课程有直接联系，教师与课程有直接联系，而教师与学生无直接联系，这就产生了模式R的存储异常。如果将R分解成下列两个关系模式：R1（SNAME，CNAME）和R2（CNAME，TNAME，TADDRESS），则能消除上述的存储异常现象。

函数依赖：
函数依赖是数据库的一种约束，决定了关系模式属于哪种范式 。为了理解方面，下面我们先介绍函数依赖的有关概念。
设R(U)是属性U上的一个关系模式，X和Y是U的子集，r为R的任一关系，如果对于r中的任意两个元组u，v，只要有u[X]=v[X]，就有u[Y]=v[Y]，则称X函数决定Y，或称Y函数依赖于X，记为X→Y。
例如，记录职工信息的结构如下：
职工工号（EMP_NO）
职工姓名（EMP_NMAE）
所在部门（DEPT）。
我们说EMP_NO函数决定EMP_NMAE和DEPT，或者说EMP_NMAE，DEPT函数依赖于EMP_NO，记为：EMP_NO→EMP_NMAE，EMP_NO→DEPT

键：
超键：在关系模式中，能唯一标识元组 的属性集称为超键。
候选键：如果一个属性集能唯一标识元组 ，且又不含有多余属性。
主键：关系模式中用户正在使用的候选键称为主键。
外键：如果公共关键字在一个关系中是主关键字，那么这个公共关键字被称为另一个关系的外键。

例如，记录职工信息的结构如下：
职工工号（EMP_NO）
职工身份证号（EMP_CARDID）
职工姓名（EMP_NMAE）
职工性别（EMP_SEX）
所在部门编号（DEPT_NO）。
在此关系中：
（1）EMP_NO和EMP_NMAE的组合是超键。
理由：EMP_NO和EMP_NMAE的组合能唯一标识元组的属性。
补充说明：其实只需要EMP_NO就可以唯一标识元组的属性，所以EMP_NO是本关系的候选键，也可以是本关系的主键。
（2）EMP_NO 和EMP_CARDID是候选键。
补充说明：一个关系的候选键可以有多个。
（3）EMP_NO 或EMP_CARDID可选作本关系的主键。
补充说明：一个关系的候选键有多个，但主键只能有一个。通常在候选键中选一个作为主键。
（4）DEPT_NO为本关系相对于部门关系的外键。
理由：DEPT_NO在本关系中不是主键，而在部门关系中是主键，所以它是本关系的外键。
补充说明：外键的作用是进行连接操作。例如现在要查找某个职工所在的部门名称，我们就需要用到外键来与部门关系进行连接，连接之后可以得到职工所在部门的名称。

4．图示法求候选键
求关系模式的候选键是进行范式界定的基础 ，也是系统分析员应该掌握的基本技能。使用候选键的定义“如果一个属性集能唯一标识元组，且又不含有多余属性。”来求解一个简单关系模式的候选键尚能应对，但面对复杂一些的关系模式，这种方法就不管用了。在此，引入一种求候选键的快捷方法，即图示法。
使用图示法求候选键，主要有三个步骤：
（1）将关系的函数依赖关系，用“有向图”的方式表示。
（2）找出入度为0的属性，并以该属性集合为起点，尝试遍历有向图，若能正常遍历图中所有结点，则该属性集即为关系模式的候选键。
（3）若入度为0的属性集不能遍历图中所有结点，则需要尝试性的将一些中间结点（既有入度，也有出度的结点）并到入度为0的属性集中，直至该集合能遍历所有结点，集合为候选键。
例如，给定关系R(A1，A2，A3，A4)上的函数依赖集F={A1→A2，A3→A2，A2→A3，A2→A4}，现在要求R的候选关键字。
第一步，需要针对函数依赖集画出有向图，如图5-4所示。图5-4函数依赖集对应有向图
第二步，从该图中找出入度为0的结点，本图中入度为0的结点只有1个，即A1。通过尝试，可以发现从A1出发可以遍历有向图中的所有结点，所以本关系模式的候选键为A1。

5. 范式
   在数据库设计过程中，往往遇到数据冗余、修改异常、插入异常和删除异常等，为了设计一个好的数据库，人们定义了一些好的关系模式标准，称它们为规范的关系模式(简称范式，NF) 。目前共定义了多个范式，分别为1NF、2NF、3NF、BCNF、4NF和5NF 。但实际应用中，一般只要达到3NF。

• 如果有X→U在关系模式R(U)上成立，并且不存在X的任一真子集X′使X′→U成立，那么称X是R的一个候选键。也就是X值惟一决定关系中的元组。
  在R(U)中，如果X→Y，并且对于X的任何一个真子集X′，都有X′→Y不成立，则称Y对X完全函数依赖。若X→Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖（注意：此处的X是一个属性集）。
  例如，如图5-5所示：X1X2→Y，又有X1→Y，则Y部分函数依赖于X1X2。 图5-5部分函数依赖示意图
  在R(U)中，如果X→Y（Y不是X的真子集），且Y→X不成立，Y→Z，则称Z对X传递函数依赖，
  如图5-6所示。 图5-6传递函数依赖示意图
  有了上述的函数依赖概念之后，我们再介绍范式的概念。
• 第一范式（1NF）：在关系模式R中，当且仅当所有域只包含原子值，即每个分量都是不可再分的数据项，则称实体E是第一范式。本书中所引用的关系模式，一般都达到了第一范式的要求。
  例如，图5-7所示的教师职称情况关系表就不满足1NF。 图5-7教师职称情况关系表原因在于该关系模式中的“高级职称人数”不是一个原子属性，若将其拆分为“教授”和“副教授”两个属性，则满足1NF。满足1NF的关系模型会有许多重复值，并且增加了修改其数据时引起疏漏的可能性。为了消除这种数据冗余和避免更新数据的遗漏，我们需要更加规范的第二范式（2NF）。
• 第二范式（2NF）：当且仅当实体E是第一范式（1NF），且每一个非键属性完全依赖主键（没
  有不完全依赖）时，则称实体E是第二范式。非键属性完全依赖又称部分函数依赖。
  例如，有选课关系模式SC(Sno，Cno，Grade，Credit)，其中：(Sno，Cno)→Grade，Cno→Credit。
  由此可知SC的主键为：(Sno，Cno)。这样(Sno，Cno)→Credit就被称为Credit对主键(Sno，Cno)的部分函数依赖，即Credit属性只需要主键的一部分Cno即可确定。所以本关系模式不符合2NF，只是1NF。若要将该关系模式转化为2NF，可以将关系模式拆分为：SC1(Sno，Cno，Grade)和SC2(Cno，Credit)。
  拆分前的SC与拆分后的SC1与SC2如图5-8所示，从该分解可以发现Credit在SC中有大量数据重复，而分解之后，解决了该问题。
• 第三范式（3NF）：当且仅当实体E是第二范式（2NF），且E中没有非主属性传递依赖于码时，则称实体E是第三范式。
  例如，学生关系Sudent（Sno，Sname，Dno，Dname，Location）各属性分别代表学号，姓名，所在系，系名称，系地址。其数据如表所示，从关系模式中各属性之间的联系可以判断出本
  关系模式的函数依赖有：Sno→Sname，Sno→Dno，Sno→Dname，Sno→Location，Dno→Dname，Dno→Location。显然，Sno为主键。在函数依赖中有：Sno→Dno→Dname与Sno→Dno→Location。这便是传递函数依赖。由于Dname与Location为非主属性，同时传递依赖于码，所以本关系模式不满足3NF。若要满足3NF，需要将关系模式拆分为：Sudent（Sno，Sname，Dno）和Department（Dno，Dname，Location）。图5-9关系Student
  BCNF：如果关系模型R∈1NF，且R中每一个函数依赖关系中的决定因素都包含码，则R是满足BC范式的关系，记作R􀀀BCNF。
  按此定义，消除了任何属性对码的传递依赖与部分依赖即为BCNF。但要判断任何属性是否对码存在传递依赖并不是一件容易的事情。
  例如，有关系模式P(C，S，T，R)，根据语义有函数依赖F={C→T，ST→R，TR→C}，现在需要判断该关系模式是否满足BCNF。
  此时我们需要分析其是否存在传递依赖。根据之前的图示法求候选键的方法，我们可以先画出相应的函数依赖图。
  对该图进行分析，可以得知本关系模式的候选键有：（S，T）和（S，C），所以主属性为：S、T、C，非主属性为：R。但此时由于属性之间的联系错综复杂，所以要界定关系模式是否存在传递函数依赖并不容易。为了准确的界定某关系模式是否为BCNF，我们需要引入另外一些判别方法。
  由于有C→T，而C不包含候选键，所以本关系模式不满足BCNF。
  根据各范式的定义，各级范式这间存在如下关系：

关系模式分解:
如果某关系模式存在存储异常等问题 ，则可通过分解该关系模式 来解决问题。将一个关系模式分解成几个子关系模式，需要考虑的是该分解是否保持函数依赖 ，是否是无损联接 。

（1）无损连接分解
在理解无损连接分解前，我们需要明确一个概念：什么叫有损，什么又是无损？
答案很简单：有损——分解后不能还原；无损——分解后可以还原 。有了这个概念基础之后，理解无损连接分解就容易了。其定义如下：设R是一个关系模式，F是R上的一个函数依赖集。R分解成数据库模式δ={R1，…，RK}。如果对R中每个满足F的关系r 都有下式成立：则称分解δ相对于F是无损联接分解，否则称为损失联接分解。要根据上述定义来判断一个分解是否是无损联接，这是一件很困难的事情，所以常常有两种方法用来解决这个问题。

方法一：公式法。
优点：速度快。
缺点：只能应用于一分为二的情况 ，一个关系模式要分解为三个关系模式就用不上了。
判定定理：设ρ={R1，R2}是R的一个分解，F是R上的函数依赖集，那么分解ρ相对于F是无损联接分解的充要条件是(R1∩R2)→(R1-R2)或(R1∩R2)→(R2-R1)。要注意的是，这两个条件只要有任意一个条件成立就可以了。

方法二：表格法 。
优点：速度慢。
缺点：适用于所有形式的模式分解。
对于表格法，由于其方法复杂，所以在此用一个例题进行讲解。
例：设关系模式R(U, F），其中R上的属性集U={A, B, C, D, E}，R上的函数依赖集F=｛A→B,DE→B,CB→E，E→A，B→D｝。分别判断：p1=｛R1(AC),R2(ED),R3(AB)｝、p2=｛R1,(ABC),R2(ED),R3(ACE)｝是否为无损连接？
首先可以利用之前讲到的图示法求出本题的候选键，求得关系R有三个候选键：BC、EC，AC。接下来是判断模式分解过程中的无损连接的问题。这个问题相对来说比较复杂。需要列表来进行分析。
对p1=｛R1(AC),R2(ED),R3(AB)｝构造初始的判定表如表5-4所示。
表5-4模式分解p1初始判定表由于A→B，属性A的第1行和第3行相同，可以将第1行b12改为a2；又由于B→D，属性B的第1行和第3行相同，所以需要将属性D第1行b14和第3行b34，改为同一符号，即取行号值最小的b14。修改后的判定表如表5-5所示。
表5-5模式分解p1修改判定表
反复检查函数依赖集F，无法修改上表，所以是有损连接的。
对p2=｛R1,(ABC),R2(ED),R3(ACE)｝构造初始的判定表如表5-6 所示。
表5-6模式分解p2初始判定表
由于A→B，属性A的第1行和第3行相同，可以将第3行b32改为a2 ；E→A，属性E的第2行和第3行相同，可以将属性A第2行b21改为al ；AC→E，属性E的第2行和第3行相同，可以将属性E第1行b15改为a5 ；B→D，属性B的第1行和第3行相同，所以需要将属性D第1行b14和第3行b34，改为同一符号，即取行号值最小的b14。E→D，属性E的第1～3行相同，可以将属性D第1行b14和第3行b34改为a4。修改后的判定表如表5-7所示。表5-7模式分解p2修改判定表
由于上表第一行全为a，故分解无损。

（2）保持函数依赖分解
设数据库模式δ={R1，…，RK}是关系模式R的一个分解，F是R上的函数依赖集，δ中每个模式Ri上的函数依赖集是Fi。如果{F1，F2，…，Fk}与F是等价的（即相互逻辑蕴涵），则称分解δ保持函数依赖。如果分解不能保持函数依赖，则δ的实例上的值就可能有违反函数依赖的现象。

4、SQL语言

结构化查询语言SQL 是关系数据库的标准语言，它是集DDL（数据定义）、DML（数据操纵）和数据控制功能（授权、完整性规则和事务控制语句）于一体的数据库语言。

1．数据定义语言
SQL的DDL主要是包括SQL模式、基本表及视图的定义和撤销的操作。包括以下几种，如表5-8所示。
表5-8 数据定义语言

创建基本表的语法格式如下：
CREATE TABLE <表名>
(<列名><数据类型>[列级完整性约束条件]
[，<列名><数据类型>[列级完整性约束条件]]…
[，<表级完整性约束条件>]）；
修改基本表的语法格式如下：
ALTER TABLE <表名>
[ADD <新列名><数据类型>[列级完整性约束条件]]
[DROP <表级完整性约束条件>]
[MODIFY <列名><数据类型>]；

2．数据操纵语言
数据操纵语言可以分为数据查询和数据更新（插入、删除、更新）两大类操作。其中由SELECT语句实现的数据查询是核心操作，也是历年考试中最重要的考点。其语法如下：

SELECT [ALL|DISINCT] <目标列表达式>[，<目标列表达式>]…
FROM <表或视图名>[，<表或视图名>]…
[WHERE <条件表达式>]
[GROUP BY <列名1> [HAVING <条件表达式>]]
[ORDER BY <列名2> [ASC|DESC]]；

下面，我们将针对以下几个示例关系模式进行阐述。
student (Sno,Sname,Ssex,Sage,Sdept)：学生（学号，姓名，性别，年龄、所在系）
course (Cno,Cname,Cpno,Ccredit)：课程（课程号，课程名，基础课号，学分）
SC (Sno,Cno,Grade)：学生选修表（学号，课程号，成绩）单表查询：即只涉及一个表的查询（如表5-9所示）。表5-9 单表查询

除此之外，我们还可以对查询结果进行以下处理（如表5-10所示）。表5-10 对查询结果进行处理
联接查询：即同时涉及两个以上的表的查询。它是关系数据库中最主要的查询，它包括等值联接、自然联接、非等值联接、自身联接、外联接和复合条件联接查询等几大类，如表5-11所示。

表5-11 联接查询
从上表中，我们可以发现在SQL与关系代数表达式的转换中，有这样几个规律：SELECT后面的<列名>一般体现为投影运算；FROM后面列出了关系模式，WHERE子句的等值部分通常是转为“自然联接”、“笛卡尔积”等运算；而非等值比较则通常是转为“选择”运算。
集合查询SELECT语句的查询结果是元组（记录）的集合，所以多个SELCET语句的结果可以进行集合操作。SQL语言提供的集合操作有并操作UNION、交操作INTERSECT和差操作MINUS。数据更新操作（如表5-12所示）表5-12 数据更新操作

3．权限赋予
GRANT { ALL [PRIVILEGES] }
| 权限 [ ( 列名 [ ,…n ] ) ] [ ,…n ]
[ ON [ 类名 :: ] 安全对象 ] TO 安全主体 [ ,…n ]
[ WITH GRANT OPTION ] [ AS安全主体]

例如：
GRANT CREATE DATABASE, CREATE TABLE TO Mary, John
本语句的作用是给用户Mary和John 赋予创建数据库与创建表的权限。

5、数据库建模技术

1. 数据库设计的阶段划分
   前面的章节曾提到软件的开发分了多个阶段，而软件开发的本身包括了流程方面的设计与数据方面的设计。数据库设计正是数据层面的规划，所以数据库设计也有阶段的划分，它与软件开发的阶段是吻合的。数据库设计包括需求分析、概念结构设计、逻辑结构设计和数据库物理设计四阶段。如图12-1所示。
   这四个阶段的主要工作与产出物总结起来，如表12-1所示。

2. ER模型高级知识
   关于ER模型的相关内容，第5章已有相关说明，应对上午考试的相关问题那些知识已经足够用
   了，但下午案例分析题难度将超过该水平，因为会涉及ER模型的高级知识。ER模型的高级知识包
   括：弱实体、特殊化、概括、聚集，考试中要求掌握弱实体与特殊化。
   （1）弱实体
   弱实体是一类特殊的实体，这种实体需要依赖于另一个实体，若另一个实体不存在了，它也随之消失。相对而言，弱实体所依赖的那个实体称为强实体。
   例如：订单实体与订单明细之间便存在这样的关系，订单实体是强实体，而订单明细为弱实体，若订单实体不存在了，订单明细也就没有存在的必要性了。强实体与弱实体之间的关系表达，与常规的ER模型略有差异，如图12-2所示。
   图12-2弱实体示意图
   （2）特殊化
   在数据库的设计过程中，有时我们会发现，一个实体可以按照某些特征分为几个子实体，这其实是从普遍到特殊的一个过程，这被称为“特殊化”。仅从概念理解，会非常抽象，下面看一个例子。
   例如：学生这个实体，它就包含了多个子集：大专生、本科生、硕士生、博士生。这便是特殊
   化。其示意图如图12-3所示。