数据库系统原理

 

一、基础的概念

什么是数据库？

数据库(Database)是按照数据结构来组织、存储和管理数据的仓库

每个数据库都有一个多个不同的API用于创建、访问、管理、搜索和复制所保存的数据

我们也可以将数据存储在文件中，但是在文件中读取数据速度相对较慢

所以，现在我们使用关系型数据库管理系统(RDBMS)来存储和管理的大数据量。所谓的关系型数据库，是建立在关系模型基础上的数据库，借助于集合代数等数学概念和方法来处理数据库中的数据

RDBMS即关系数据库管理系统(Relational Database Management System)的特点:

1.数据以表格的形式出现

2.每行为各种记录名称

3.每列为记录名称所对应的数据域

4.许多的行和列组成的一张表单

5.若干的表单组成的database

数据模型

由数据结构、数据操作和完整性三个要素组成

数据库系统

数据库系统包含所有与数据库相关的内容，包括数据库、数据库管理系统、应用程序以及数据管理员和用户，还包括相关的硬件和软件

RDBMS术语

数据库:数据库是一些关联表的集合。

数据表:表是数据的矩阵。在一个数据库中的表看起来像一个简单的电子表格

列:一列(数据元素)包含了相同的数据,例如邮政编码的数据。

行:一行(=元组，或记录)是一组相关的数据，例如一条用户订阅的数据，

冗余:存储两倍数据，冗余降低了性能，但提高了数据的安全性。

主键:主键是唯一的。一个表中只能包含一个主键。你可以使用主键来查询数据

外键:外键用于关联两个表

复合键:复合键(组合键)将多个列作为索引键,一般用于复合索引。

索引:使用索引可快速访问数据库表中的特定信息。索引是对数据库表中一列或多列的值进行排序的一种结构，类似于书籍的目录。

参照完整性:参照的完整性的要求关系中不允许引用不存在的实体。与实体完整性是关系模型必须满足的完整性约束条件，目的是保证数据的一致性

二、事务

概念

        事务指的是满足ACID特性的一系列操作，在数据库中，可以通过Commit提交一个事务，也可以使用Rollback进行回滚

四大特性

1.原子性(Atomicity)

事务被视为不可分割的最小单元，要么全部提交成功，要么全部失败回滚

2.一致性(Consistency)

事务执行前后都保持一致性。在一致性状态下，所有事务对一个数据的读取结果都是相同的

3.隔离性(Isolation)

一个事务所做的修改在最终提交以前，对其他事物是不可见的

4.持久性(Durability)

一旦事务提交，则其所做的修改将永远保持到数据库中。即数据库系统崩溃，事务执行的结果也不能丢失。可以通过数据库备份和恢复保证持久性

三、数据库设计的三大范式

1、第一范式(确保每列保持原子性)

第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。

第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式。

上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。

 

2、第二范式(确保表中的每列都和主键相关)

第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键。

订单信息表

这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。

而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。

这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。

 

3、第三范式(确保每列都和主键列直接相关,而不是间接相关)

第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。

 

四、隔离级别

1、未提交读

事务中的修改，即使没有提交，对其他事务也是可见的。

2、提交读

一个事务只能读取已经提交的事务所做的修改。换句话说，一个事务所做的修改在提交之前对其他事务是不可见的。

3、可重复读

保证在同一个事务中多次读取的数据的结果是一样的的

4、可串行读

强制事务串行执行

四个隔离级别的对比

隔离级别	脏读	不可重复读	幻影读
未提交读	YES	YES	YES
提交读	NO	YES	YES
可重复读	NO	NO	YES
可串行读	NO	NO	NO

五、关系数据库建模

ER图

Entity-Relationship,有三个组成部分：实体、属性、联系

实体

        实体(Entity)是指数据对象，指应用中可以区别的客观存在的事物。

        实体集(Entity Set)是指同一类实体构成的集合

        实体的三种关系

         联系包含一对一，一对多，多对对三种

属性

        实体的某一特性称为属性(Attribute)

        在一个实体中，能够唯一标识实体的属性或属性集称为"实体标识符"

        一个实体只有一个标识符，某一候选标识符的概念。实体标识符有时也称为实体的主键

        实体若干属性和一组特定值。确定了一个特定的实体

联系

        联系表示一个或多个实体之间的关联关系

        联系集是指同一类构成的集合

        将联系、联系集等统称为联系

1、设计局部ER模型的步骤

        确定局部结构范围

                范围的划分要自然，易于管理；界面要清晰；大小要适度

        确定实体

               采用人们习惯划分；避免冗余；依据用户的需求

        确定属性

                属性一个是不可再分解的语义单位

                实体与属性之间的关系只能是1:n

                不同的实体类型的属性之间应无直接关联关系

        确定实体间的联系

                确定联系，联系类型，防止冗余

两条准则

        属性不能再具有需要描述的性质

        属性不能与其他实体具有联系 

设计全局ER模型

将局部ER模型综合成单一的全局概念结构的步骤：

确定公共实体类型

        根据实体类型名和键来认定公共实体类型

合并局部ER模型

        首先进行两两并合，先合并那些现实世界中有联系的局部结构

        合并从公共类型开始，最后再加入独立的局部结构

消除冲突

        属性冲突(属性域冲突)；结构冲突；命名冲突

全局ER模型的优化

        优化原则

                合并实体类型

                消除冗余属性

                消除冗余联系     

MySQL 教程 | 菜鸟教程