白话数据库三级模式，数据库设计基础知识

都知道数据库系统的三级模式结构是指外模式，模式，内模式。

那么到底应该如何理解这三个模式呢？

其实最简单直白的理解方式就是按不同使用者的视觉角度来划分。

我们先将用使用者分为三类：数据库使用者，数据库创建及管理者，系统程序员

其中数据库使用者包括应用该数据库开发软件的开发人员以及该数据库支持的应用软件的用户。

首先从数据库使用者角度来看数据库。

对于应用该数据库开发软件的开发人员，在开发软件的时候，不需要了解整个数据库的设计及全部关系。开发人员只需要了解他所负责模块应用到的那部分数据库。所以数据库管理员会根据需要只给开发人员开发部分表或者说视图。

对于该数据库所支持应用软件的用户，因为应用软件权限的设计，用户只会在应用软件上看到数据库所映射到应用软件上的部分数据。

所以说从数据库的使用者来说，他所看到和使用的数据库只是整个数据库的局部，也就是部分视图。

这就是外模式。

再从数据库的创建及管理者（数据库管理员）的角度来看数据库。

数据库管理员需要借助某一个数据库管理系统来创建、管理及维护数据库。在这个过程中，他会根据E-R图设计表结构及关联，并根据该E-R图的设计在数据库管理系统中创建数据库、表等各种操作，还会进行后期的数据库管理维护及优化。

在数据库管理员的工作中，他会在数据库管理系统中看到所有的数据信息。这个数据系统是数据库管理系统按照逻辑结构展现给他的数据展示形式。

这就是模式。

最后再从系统程序员的角度来看数据库。

系统程序员不是数据库的应用者，所以他不会用到数据库编程，也不会看到数据库中的数据在某个具体应用软件上的展现形式。

他也不需要管理数据库，所以他不会看到数据库中的数据在数据库管理系统中是如何展示的。

但是他会对底层操作系统进行操作。在他的角度来看，数据库中所存放的数据不是一个个表的形式，而是以各种不同文件的形式存放在操作系统的某个相应的位置。甚至于我们所看到的某个表中的数据会分存到多个不同的文件中。

这就是内模式。

到这就算是把数据库三个模式讲完了。

从上面我们也可以更清晰地明白，数据库三级模式中只有内模式是真是存在的。数据库中的数据就是以各种文件的形式存放在操作系统某个相应的位置。

其他数据库管理员以及使用者看到的只是以某种形式展示的全部或部分数据。

基本概念

数据库系统DBS:是一个采用了数据库技术，有组织地、动态地存储大量相关数据， 方便多用户访问的计算机系统。其由下面四个部分组成：

数据库（统一管理、长期存储在计算机内的，有组织的相关数据的集合）

硬件（构成计算机系统包括存储数据所需的外部设备）

软件（操作系统、数据库管理系统及应用程序）

人员（系统分析和数据库设计人员、应用程序员、最终用户、数据库管理员口BA)。

数据库管理系统DBMS的功能 实现对共享数据有效的组织、管理和存取。

包括数据定义、数据库操作、数据库运行管理、数据的存储管理、数据库的建立和维等。

三级模式-两级映射

内模式：管理如何存储物理的数据，对应具体物理存储文件。

模式：又称为概念模式，就是我们通常 使用的基本表，根据应用、需求将物理 数据划分成一张张表。

外模式：对应数据库中的视图这个级别 表进行一定的处理后再提供给用户使用

外模式一模式映像：是表和视图之间的 映射，存在于概念级和外部级之间，若 表中数据发生了修改，只需要修改此映 射，而无需修改应用程序。

模式一内模式映像：是表和数据的物理 存储之间的映射，存在于概念级和内部级之间，若修改了数据存储方式，只需 要修改此映射，而不需要去修改应用程序。

数据库设计

需求分析：即分析数据存储的要求，产出物有数据流图、数据字典、需求说明书。

概念结构设计：就是设计E-R图，也即实体-属性图，与物理实现无关，说明有哪些实体，实体有哪些属性。

逻辑结构设计：将E-R图，转换成关系模式，也即转换成实际的表和表中的列属性，这里要考虑很多规范化的东西。

物理设计：根据生成的表等概念，生成物理数据库。

E-R模型

数据模型三要素：数据结构（所研究的对象类型的集合）、数据操作（对数据库中各种对象的 实例允许执行的操作的集合)、数据的约束条件（一组完整性规则的集合）。

E-模型：即实体-联系模型，使用椭圆表示属性（一般没有）、长方形表示实体、菱形表示联 系，联系两端要标注联系类型。

联系类型：一对一1：1、一对多1：N、多对多M:N。

属性分类：简单属性和复合属性（属性是否可以分割）、单值属性和多值属性（属性有多个取 值)、NULL属性（无意义）、派生属性（可由其他属性生成）。

关系模型

关系模型也即数据库中常用的表，包括实体的属性，标识出实体的主键和外键.

模型转换

E-R图转换为关系模型：每个实体都对应一个关系模式；联系分为三种：

1:1联系中，联系可以放到任意的两端实体中，作为一个属性（要保证1：1的两端关联）；

1:N的联系中，联系可以单独作为一个关系模式，也可以在端中加入1端实体的主键：

M:N的联系中，联系必须作为一个单独的关系模式，其主键是M和N端的联合主键。

关系代数运算

并：结果是两张表中所有记录数合并，相同记录只显示一次。

交：结果是两张表中相同的记录。

差：S1-S2,结果是S1表中有而S2表中没有的那些记录。

笛卡尔积：S1X S2,产生的结果包括S1和S2的所有属性列，并且S1中每条记录依次和S2中所有 记录组合成一条记录，最终属性列为S1+S2属性列，记录数为S1X S2记录数。

投影：实际是按条件选择某关系模式中的某列，列也可以用数字表示。 Π

选择：实际是按条件选择某关系模式中的某条记录。δ

自然连接的结果显示全部的属性列，但是相同属性列只显示一次，显示两个关系模式中属性和同且值相同的记录。

函数依赖

给定一个X,能唯一确定一个Y,就称X确定Y,或者说Y依赖于X,例如Y=X* X函数。

函数依赖又可扩展以下两种规则：

部分函数依赖：A可确定C,(A,B)也可确定C,(A,B)中的一部分（即A)可以确定C, 称为部分函数依赖。

传递函数依赖：当A和B不等价时，A可确定B,B可确定C,则A可确定C,是传递函数 依赖；若A和B等价，则不存在传递，直接就可确定C。

键与约束

超键：能唯一标识此表的属性的组合。

候选键：超键中去掉冗余的属性，剩余的属性就是候选键。

主键：任选一个候选键，即可作为主键。

外键：其他表中的主键。

主属性：候选键内的属性为主属性，其他属性为非主属性。

实体完整性约束：即主键约束，主键值不能为空，也不能重复。

参照完整性约束：即外键约束，外键必须是其他表中已经存在的主键的值，或者为空。

用户自定义完整性约束：自定义表达式约束，如设定年龄属性的值必须在0到150之间。

范式

第一范式1F:所有属性都不可以再分割为两个或多个分量。

第二范式2NF:当且仅当R是1NF,且每一个非主属性完全依赖主键（不存在部分依赖）时，R 就是2NF。比较典型的例子就是候选键是单属性，单属性是不可能存在部分函数依赖的。

第三范式3NF:当且仅当R是2NF,且R中没有非主属性传递依赖于候选键时，R就是3NF(此时， 也不会存在部分依赖)。一般解决方法是拆分传递依赖的非主属性为一个新的关系模式。本质 就是主键要直接决定所有非主属性，不能通过非主属性间接决定。

模式分解

范式之间的转换一般都是通过拆分属性，即模式分解，将具有部分函数依赖和传递依赖的属性 分离出来，来达到一步步优化，一般分为以下两种：

保持函数依赖分解

对于关系模式R,有依赖集F,若对R进行分解，分解出来的多个关系模式，保持原来的依赖集 不变，则为保持函数依赖的分解。另外，注意要消除掉冗余依赖（如传递依赖）。

无损分解：

分解后的关系模式能够还原出原关系模式，就是无损分解，不能还原就是有损。

当分解为两个关系模式，除了表格法以外，还可以通过以下定理判断是否无损分解：

定理：如果R的分解为p={R1,R2},F为R所满足的函数依赖集合，分解p具有无损连接性的充分 必要条件是R1 ∩ R2->(R1-R2)或者R1 ∩ R2->(R2-R1)

事务管理

事务提交commit,事务回滚rollback。

事务：由一系列操作组成，这些操作，要么全做，要么全不做，拥有四种特性，详解如 下：

(操作)原子性：要么全做，要么全不做。

(数据)一致性：事务发生后数据是一致的，例如银行转账，不会存在A账户转出，但是 B账户没收到的情况。

(执行)隔离性：任一事务的更新操作直到其成功提交的整个过程对其他事务都是不可 见的，不同事务之间是隔离的，互不干涉。

(改变)持续性：事务操作的结果是持续性的。

并发控制

事务是并发控制的前提条件，并发控制就是控制不同的事务并发执行，提高系统效 率，但是并发控制中存在下面三个问题：

丢失更新：事务1对数据A进行了修改并写回，事务2也对A进行了修改并写回，此时 事务2写回的数据会覆盖事务1写回的数据，就丢失了事务1对A的更新。即对数据A 的更新会被覆盖。

不可重复读：事务2读A,而后事务1对数据A进行了修改并写回，此时若事务2再读A, 发现数据不对。即一个事务重复读A两次，会发现数据A有误。

读脏数据：事务1对数据A进行了修改后，事务2读数据A,而后事务1回滚，数据A恢 复了原来的值，那么事务2对数据A做的事是无效的，读到了脏数据。

上文就是小编为大家整理的白话数据库三级模式，数据库设计基础知识。