一、基础的概念
什么是数据库?
数据库(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模型的优化
优化原则
合并实体类型
消除冗余属性
消除冗余联系