数据库系统概念读书笔记（前三章）

一. 引言

数据库管理系统：有一个互相关联的数据的集合和一组用以访问这些数据的程序组成，这个数据集合就叫做数据库。上来就先写上一个概念，作为这本书的主线。

1.数据库的出现的必要性和对数据库的要求

尽管文件系统可以解决不少问题，但是下面的问题是文件系统所无法解决的，如果给文件系统加上这些特性，那么文件系统也就成为了一个数据库（有点裸设备的味道）。

1. 数据的冗余和不一致：重复数据多，而且对于分布式，有可能出现数据无法同步的问题。
2. 数据访问困难。
3. 数据孤立：说的是因为数据存储没有采取同样的格式，使得使用统一的接口访问数据变得不可能。
4. 完整性问题：说的是实现数据约束比较困难，书中给的例子是比如说给某一个账户定一个最低存款额度。
5. 原子性问题：说的就是事务处理了，如何保证一个操作的完整性。例如银行转账。
6. 并发访问：这也是事务处理的一部分，数据库需要应对同时异地对同一个数据操作的可能。
7. 安全性问题：主要是数据库访问权限问题。

数据库的概念分层

1. 物理层：定义数据的存储格式。能够涉及者一层的人是数据库软件开发者。
2. 逻辑层：定义数据以及数据之间的关系。能够涉及这一层的人是数据库的设计者。
3. 视图层：定义最终展现在客户面前的数据的格式。涉及这一层的是数据库客户端的开发者，以及最终的用户。

这三层从上到下层层透明。用户不关心数据库结构，数据库设计开发者不关心存储结构。

2.数据模型

1. 实体————联系模型
2. 关系模型

这两个模型看起来很像，事实上是，首先用实体--联系模型做最初的定义，然后转化成关系模型。关系模型是目前使用最广泛的数据库模型。

3.数据库语言

数据库语言通常由两个部分组成，(1)DDL——数据定义语言。（2）DML——数据操纵语言。最常用的数据库语言就是SQL。

应用程序体系结构

有了数据库，如何高效安全的访问就成了问题，这需要开发人员作出客户端软件。而开发这种软件通常遵循的模式有两种。

1. 两层模式 就是通常的数据库-客户端模式。这种模式的优点是高效，缺点是安全性，并发性和可分布性不好。比较适用于小型的数据库软件开发。
2. 三层模式：就是 数据库——服务器——应用程序三层模式。这种模式的一个经典实例就是JSP/Servlet —— EJB —— DataBase 模型。这种模型的好处是，容易移植和维护，客户端不用关心后台的数据库，数据库不用关心外面的客户端，一些都由中间的服务器层来搞定。缺点就是效率不高。无法针对某种应用进行比较有针对性的优化和设计。

二. 实体关系模型

1.几个基本概念

实体-联系(E-R)模型是基于如下的一种认识：世界由一组实体和实体之间的相互联系组成。E-R模型是一种语义模型， 前面也提到过，这种模型经常作为关系数据库模型的基础。 很多数据库设计工具也都使用了E-R模型的概念。

下面是几个核心概念

1. 实体集：具有相同类型及共享相同性质的实体集合。而相应的实体集中每一个元素就是实体。这个概念对应到面向对象中就是class-object概念， 而我们野可以想象，实体集还会有继承的概念（虽然我暂时还无法想象在数据库中如何实现实体集的继承）。
2. 属性，值和域：实体是通过一组属性来表示的，属性就是每个成员所具有的描述性性质，而每个实体的所有属性都有一个值， 每一个属性的取值范围就称作该属性的域。
3. 联系集：联系是指实体之间的相互关联，而同类型的关系组成的集合就是关系集。在通常的数据库系统中，联系可以表现为两种，一种是联系表，而另一种就可能是一个简单的sql语句。

2.约束

有了实体集合，有了联系集合，自然而然的就产生出来约束，约束描述的是实体集和实体集之间的关系，而这种关系就具现为一个联系集。 我们要讨论的是映射基数和参与约束这两类最重要的约束。

2.1.映射基数

映射基数是指一个实体集和另一个实体集之间的实体对应关系。有如下的四种

1. 一对一
2. 多对一
3. 一对多
4. 多对多

具体的解释可以看书，映射基数在描述二元联系集的时候，特别有用。

2.2.参与约束

参与约束只是讲实体集和联系集的关系，实体集E中的任意一个实体e如果都参与到了联系集R中，那么就说E对R是完全参与的；相对来说就有部分参与。

3.码

码是在实体集中唯一表示某一个实体的属性集合，按照超码中包含的属性数量分可以分为“超码”，“候选码”，“主码”三种。

1. 超码：在实体集中任何可以唯一标识实体的属性集合都叫做超码，所以，根据这个定义，任何超码的超集也都是超码。
2. 候选码：任意真子集都不能成为超码的超码叫做候选码。
3. 主码：数据库设计者选中的候选码。

候选码应该选择那些从不或者极少变化的属性。

4.设计问题

4.1.用实体集还是用属性

书中给的例子是很明显的，employee-name本身不能作为一个实体，尽管employee-name可能会有first-name，会有 middle-name 和last-name，但是把它们做成employee 的属性更加的合理。而把telephone做成一个实体就很有道理了，因为我们可以存储telephone的额外信息。而有两种错误一定要注意一下。

1. 不要用实体集的主码作为另一个实体集的属性。
2. 不要将有关系的实体集的主码属性作为联系集的属性。（这句话不明白）

4.2.用实体集还是联系集

1. 原则：当描述发生在实体之间的行为时采用联系集。

4.3.二元联系集与n元联系集

1. n元关系可以分解成二元关系，但是会出现关系描述不准确的情况。

5.弱实体集和其他的扩展特性

如果一个实体集的属性可能不足以形成主码，这样的实体集就成为弱实体集。反之就叫做强实体集。而作为设计的目标之一，一个弱实体集必须要依赖 于一个强实体集，标识性联系是从弱实体集到标识实体集的多对一的联系，并且弱实体集全部参与联系。

另外，我们还有一些关于实体的特性，比如继承，说的是实体集之间的继承关系，但是这样的关系只是在设计的时候适用，在真正建立 table的时候，会造成一些实现上的困难。还有聚集，这是非常有用的，说明了联系集和其他集的联系集，具体的例子参考书，就是employee， branch，job和manager之间的关系（论述非常的经典）。

6.E-R模式像Table转化

6.1.强实体集

强实体集被对应成数据库里面的一张表，有多少个属性就有多少列。并且主码做主键

6.2.弱实体集

弱实体集也被对应成一张表，这张表一定要包含所依赖的强实体集的主码。

6.3.联系集

联系集被翻译成一张表，整个表里面要包含所有参与联系的实体的主码。并且附加描述性属性。

1. 1对1：任意一方的主码都可以拿来作为主码。
2. 1对n：多方主码成为联系集的主码，单方主码作为属性。
3. n对n：把双方的主码的组合作为主码。

6.4.复合属性

性为每一个子属性创建一个单独的属性。

6.5.多值属性

必须为多值属性创建一个表。

6.6.一般化（父子集成的关系）

通常都为子实体集合创建一个单独的表，如果还有实体属于父实体集合，那么也要为父实体创建表

 

三. 关系模型

 

 关系模型是E-R模型之后的又一大模型，而该模型也是现在的数据库中运用最广泛的模型，ORACLE，DB2都是基于关系数据库模型的。而且为关 系模型制定查询语言也是非常直截了当的事情（不知道又没有谁想想过E-R模型里面的查询语句应该是什么样子的），关系模型甚至还给出了一个让E-R模型平 滑转换到关系模型的方法。这样，关系模型就几乎成了E-R模型的一个完整替代品。本章讨论的就是这么三个问题-----关系模型的概念，关系查询语言，E -R模型转换为关系模型。

1.关系模型的基本概念

1. 关系：一系列值之间的联系就叫做关系。
2. 关系集合：一系列相同关系组成的集合就叫做关系集合。
3. 关系数据库：由一组关系集合（表）组成的集合。
4. 关系查询语言：操作关系获取信息的语言，例如SQL，就是其中一种实现。

 而在数学的角度，关系可以被理解成一系列域上的笛卡尔子集（不知道这个是什么的朋友还是好好看看数学吧。），当然这种理解在研究纯理论的时候比较重要。

2.E-R模型和关系模型的关系

因为E-R模型的设计比较直观，而可惜的是直接支持E-R模型的商业数据库确实少只有少，更多的是支持关系模型的。所以提供一个比较完善的E-R模型和关系模型转换方法是比较重要的。这里强调的是E-R模型中的主码怎么转换到关系模型中。

1. 强实体集：实体集的主码成为关系的主码。
2. 弱实体集：依赖的强实体集和弱实体集的分辨符的组合成为关系的主码。
3. 联系集：按照对应情况
   1. 1-1：参与联系的任意一方的主码成为关系的主码。
   2. 1-N：参与联系的多方主码成为关系的主码。
   3. N-N：参与联系的各方的主码的组合成为关系的主码。
4. 多值属性：多值属性的主码可以用采用该属性的实体集的主码和属性值组成的码作为关系的主码。

从E-R模式中导出的一个关系模式r1可能在他的属性中包括另一个模式r2的主码。那么这个属性叫做r1参照r2的外码（foreign-key），注意，模式图里面是没有foreign-key的。

3.关系代数

可以算作关系模式核心中的核心，都比较简单，这里来一个索引式的纪录。

1. 基本运算

    关系模型是E-R模型之后的又一大模型，而该模型也是现在的数据库中运用最广泛的模型，ORACLE，DB2都是基于关系数据库模型的。而且为关 系模型制定查询语言也是非常直截了当的事情（不知道又没有谁想想过E-R模型里面的查询语句应该是什么样子的），关系模型甚至还给出了一个让E-R模型平 滑转换到关系模型的方法。这样，关系模型就几乎成了E-R模型的一个完整替代品。本章讨论的就是这么三个问题-----关系模型的概念，关系查询语言，E -R模型转换为关系模型。

   1.关系模型的基本概念

2. 关系：一系列值之间的联系就叫做关系。
3. 关系集合：一系列相同关系组成的集合就叫做关系集合。
4. 关系数据库：由一组关系集合（表）组成的集合。
5. 关系查询语言：操作关系获取信息的语言，例如SQL，就是其中一种实现。

 而在数学的角度，关系可以被理解成一系列域上的笛卡尔子集（不知道这个是什么的朋友还是好好看看数学吧。），当然这种理解在研究纯理论的时候比较重要。

2.E-R模型和关系模型的关系

因为E-R模型的设计比较直观，而可惜的是直接支持E-R模型的商业数据库确实少只有少，更多的是支持关系模型的。所以提供一个比较完善的E-R模型和关系模型转换方法是比较重要的。这里强调的是E-R模型中的主码怎么转换到关系模型中。

1. 强实体集：实体集的主码成为关系的主码。
2. 弱实体集：依赖的强实体集和弱实体集的分辨符的组合成为关系的主码。
3. 联系集：按照对应情况
   1. 1-1：参与联系的任意一方的主码成为关系的主码。
   2. 1-N：参与联系的多方主码成为关系的主码。
   3. N-N：参与联系的各方的主码的组合成为关系的主码。
4. 多值属性：多值属性的主码可以用采用该属性的实体集的主码和属性值组成的码作为关系的主码。

从E-R模式中导出的一个关系模式r1可能在他的属性中包括另一个模式r2的主码。那么这个属性叫做r1参照r2的外码（foreign-key），注意，模式图里面是没有foreign-key的。

3.关系代数

可以算作关系模式核心中的核心，都比较简单，这里来一个索引式的纪录。

1. 基本运算
   1. 选择运算
   2. 投影运算
   3. 并运算
   4. 集合差运算
   5. 迪卡儿集运算
   6. 更名运算
2. 附加运算
   1. 集合交
   2. 自然连接
   3. 除运算
3. 扩展的关系代数运算
   1. 广义投影
   2. 聚集函数（avg，min，max，sun，group by ，etc）
   3. 外连接（左外连接，右外连接，全外连接）

4.数据库的修改

1. 删除
2. 插入
3. 更新

5.视图

目前所给的例子，都是在逻辑层（参考第一章）上进行的操作，而有的时候，我们需要做出来一个虚拟的表给用户看，除安全性考虑（视图是只读的）之外，更加考虑到用户的直觉问题（让他看到更合理的数据）。

关于视图，其实很简单，就是一个查询语句而已，使用它的时候需要注意如下几点：

1. 视图的更新通常是在显示的时刻（这非常像写时复制技术）
2. 视图是只读的（因为通过视图更新是非常混乱的事情）
3. 视图有可能被数据库缓存，所以对于查询量高的查询，尽量用试图吧。
4. 视图是可以被展开的，也就是说，可以用视图来定义视图（这个功能很cool吧），但是不可以递归定义。

这一章作为语法的介绍来讲是非常容易的，但是里面涉及的查询是非常灵活的，需要反复的演练才可以。

1.  
   1. 选择运算
   2. 投影运算
   3. 并运算
   4. 集合差运算
   5. 迪卡儿集运算
   6. 更名运算
2. 附加运算
   1. 集合交
   2. 自然连接
   3. 除运算
3. 扩展的关系代数运算
   1. 广义投影
   2. 聚集函数（avg，min，max，sun，group by ，etc）
   3. 外连接（左外连接，右外连接，全外连接）

4.数据库的修改

1. 删除
2. 插入
3. 更新

5.视图

目前所给的例子，都是在逻辑层（参考第一章）上进行的操作，而有的时候，我们需要做出来一个虚拟的表给用户看，除安全性考虑（视图是只读的）之外，更加考虑到用户的直觉问题（让他看到更合理的数据）。

关于视图，其实很简单，就是一个查询语句而已，使用它的时候需要注意如下几点：

1. 视图的更新通常是在显示的时刻（这非常像写时复制技术）
2. 视图是只读的（因为通过视图更新是非常混乱的事情）
3. 视图有可能被数据库缓存，所以对于查询量高的查询，尽量用试图吧。
4. 视图是可以被展开的，也就是说，可以用视图来定义视图（这个功能很cool吧），但是不可以递归定义。

这一章作为语法的介绍来讲是非常容易的，但是里面涉及的查询是非常灵活的，需要反复的演练才可以。