软件设计师笔记之数据库系统基础

关于数据库我对以下几个方面的知识点进行了梳理笔记。

（1）数据库模型（概念模式、外模式、内模式）

（2）数据模型，ER图，规范化

（3）数据操作

（4）数据库语言

（5）数据库管理系统的功能和特征

（6）数据库的控制功能

（7）数据仓库和分布式数据库基础知识

数据库系统的考点主要集中在：ER模型、关系代数、元组演算、规范化理论（键、范式、模式分解）、SQL 语言等。

---

目录

一、数据库模式及ER模型

1. 三级模式与两级映射

2. ER模型

3.关系运算

4.元祖运算

二、规范化理论

1. 规范化理论的作用

2．函数依赖

3．键

4. 范式

5. 关系模式分解

三、SQL语言

---

 

一、数据库模式及ER模型

数据库是长期存储在计算机内的、有组织的、可共享的数据集合，数据库系统是指在计算机信息系统中引入数据库后的系统，一般由数据库、数据库管理系统（DataBase Management System，DBMS）、应用系统、数据库管理员（DataBase Administrator ，DBA）和用户构成。数据库系统的结构可以有多种不同的层次或不同的角度，其中典型的是三级划分法，其中包括三级模式和两级映射。

数据库设计流程

---

1. 三级模式与两级映射

数据库系统由外模式、概念模式和内模式三级构成。其关系如图  “数据库三级模式两级映射示意图” 所示。

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

外模式也称为子模式或用户模式，它对应的是我们平时所用到的数据库视图。外模式用来描述用户（包括程序员和最终用户）看到或使用的那部分数据的逻辑结构，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。一个数据库可以有多个外模式，一个应用程序只能使用一个外模式。

概念模式也称为模式或逻辑模式，它对应我们平时所用到的数据表。概念模式是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图，用以描述现实世界中的实体及其性质与联系，定义记录、数据项、数据的完整性约束条件及记录之间的联系。概念模式通常还包含有访问控制、保密定义和完整性检查等方面的内容，以及概念/ 物理之间的映射。一个数据库只有一个概念模式。

内模式对应于物理级数据库，是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式。内模式不同于物理层，它假设外存是一个无限的线性地址空间。内模式定义的是存储记录的类型、存储域的表示和存储记录的物理顺序，以及索引和存储路径等数据的存储组织。一个数据库只有一个内模式。

在数据库系统的三级模式中，模式是数据库的中心与关键；内模式依赖于模式，独立于外模式和存储设备；外模式面向具体的应用，独立于内模式和存储设备；应用程序依赖于外模式，独立于模式和内模式。

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

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

概念模式与内模式之间的映射：用于维护数据库的物理独立性。也就是说当数据的物理存储改变时，应用程序不需要改变。

2. ER模型

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

学生-课程 ER模型

上图展示了一个简单的ER模型，我们通过该图进行ER模型的概念入门：

实体：客观存在并可相互区别的事物，可以是具体的人、事、物，也可以是抽象的概念或联

系。图 学生-课程 ER模型 中的“学生”与“课程”便是实体。

属性：实体所具有的某一特性称为属性，通常一个实体可以由多个属性来描述。图52中“学

生”实体旁边的“学号”、“姓名”、“班级号”便是属性。

联系：实体内部的联系通常是指组成实体的各属性间的关系。图 学生-课程 ER模型 中“选课”便是联系。

（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）个实体与之联系。一门课程同时有许多学生选修，而一个学生也可以选修多门课程。如 学生-课程 ER模型 图，该ER模型便属于m: n型。

（2）ER模型的集成

在数据库的概念设计过程中，由于系统都存在一定的复杂度，一次性设计全局ER图将存在较大风险，所以一般会先设计各子系统的局部ER图，然进行集成。

集成的方法：

多个局部E-R图一次集成；

（常用）逐步集成，用累加的方式一次集成两个局部E-R。

但由于各子系统应用所面临的问题不同，且通常是由不同的设计人员进行局部视图设计，这就导致各个局部ER图之间必定会存在许多不一致的问题，称之为冲突。因此，在合并ER图时，不能简单地将各个局部ER图画到一起，而是必须着力消除各个局部ER图中的不一致，以形成一个能为全系统中所有用户共同理解和接受的统一的概念模型。各局部ER图之间的冲突主要有三类，分别是属性冲突、命名冲突和结构冲突。

1）属性冲突。属性冲突包括属性域冲突和属性取值冲突。属性冲突理论上好解决，只要换成相同的属性就可以了，但实际上需要各部门协商，解决起来并不简单。

2）命名冲突。命名冲突包括同名异义和异名同义。处理命名冲突通常也像处理属性冲突一样，通过讨论和协商等行政手段加以解。

3）结构冲突。结构冲突包括同一对象在不同应用中具有不同的抽象，以及同一实体在不同局部ER图中所包含的属性个数和属性排列次序不完全相同。对于前者的解决办法是将属性变换为实体或实体变换为属性，使同一对象具有相同的抽象。对于后者的解决办法是使该实体的属性取各局部ER图中属性的并集，再适当调整属性的次序。

（3）ER模型转关系模式

ER图向关系模式的转换属于数据库的逻辑设计阶段的工作，该阶段需要将ER模型转换为某种DBMS能处理的关系模式，具体转换规则如下：

1）一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的主键就是关系的主键。

2）一个1: 1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的模式，则与该联系相连的各实体的主键和联系本身的属性均转换为关系的属性，每个实体的主键均是该关系的键属性；如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的主键和联系本身的属性。

3）一个1: n联系可以转换为一个独立的关系模式，也可以与任意n端对应的关系模