数据库基础知识

实体（集）---属性---联系：在E/R关系图中，实体（集）用矩形来表示；属性用椭圆来表示；联系用菱形来表示。实体和实体之间的关系可以是多对一（E—>F）、一对一（E<—>F）或者多对多（E—F）的关系，在这里一个箭头表示的是“最多一个”的意思。

关系模型的基础：关系模型提供了一种使用称之为关系的二维表来描述数据的方法。
关系：是一个组织数据的二维表，关系名即这个表的表名称；
属性：位于关系最上的一行是属性，即描述关系每一列的是属性；
模式：关系名及其属性集合的组合称之为这个关系的模式；
数据库模式：一项关系模型设计包括一个或多个关系模式，这个关系模式的集合叫做关系数据库模式，简称为数据库模式
元组：关系中除含有属性名所在行以为的其他行称做元组，每个元组均有一个分量对应于关系的每个属性。
域：关系模式要求元组的每个分量具有原子性，即它必须属于某种元素类型。与关系每个属性相关联的是一个域，即一个特殊的元素类型，关系中的任一元组的分量必须属于对应列的域
关系的等价描述：关系是元组的集合，而不是元组的列表。因此关系中元组出现的顺序不是实质问题，比如一个关系的三个元组有六种可能的排列，但是表示的是同一个关系。
关系实例：关系不是静态的，而是会随时间改变的，比如人们会根据需要在关系中插入或者删除元组；关系模式也并不是静态的，虽然它并不经常改变，比如人们会根据需要在现有的关系上添加或者删除属性。一个给定关系中元组的集合叫做关系的实例，通常的数据库系统只维护关系的一个版本，即关系的当前元组集合，这个关系实例叫做当前实例。

从E/R图到关系的设计：分别是E/R实体集到关系的转换和E/R联系到关系的转化。
一般是会从需求画出E/R图，之后根据E/R图把它转换为关系的二维表并用SQL实现，这些实现好的二维关系表构成数据库模式，进而构建数据库。

函数依赖的定义（FD）：如果关系（R）的两个元组在属性A1，A2，……An上一致，那么他们在其他分量B上的值也必定相同。写做：A1，A2，……An--->B。
平凡的函数依赖：仅当右边的属性集合是左边集合的子集；
非平凡的函数依赖：仅当其其右边的属性集中至少有一个属性不属于左边的集合；
完全非平凡的函数依赖：仅当其右边集合中的属性均不（都不）在左边的集合中。
注意：人们总是可以从右边出去那些在左边出现的属性。
函数依赖的规则：分解规则：A1，A2，…An--->Bi（i=1,2,3，…，m）替换FD：A1，A2，…An--->B1，B2…Bm
组合规则：A1，A2，…An--->B1，B2…Bm替换FD：A1，A2，…An--->B1，B2…Bm
注意：分解规则只能在FD的右边使用，而不能在左边使用。

关系表中的键：超键、候选键、主键、外键。
超键：它是“键的超集”的简写，因此每个键都是超键，然而某些超键不是（最小）键。每个超键都满足键的第一个条件：它函数决定了关系中所有的其他属性；但是超键不满足键的第二个条件：最小化。
候选码（码）：关系中的一个属性（组），它函数决定了关系中所有的其他属性，即这个属性（组）能唯一标识一个元组，并且已经最小化，即这个元组的任何一个真子集都不能函数决定关系R的其他属性；则这个属性（组）是关系R的键，即候选码。
主键（码）：有时一个关系可能有多个键（候选码），通常就要指定其中一个为主键。
外键（码）：如果一组公共关键字，在一个关系中是主键，那么这个公共关键字被称为另外一个关系的外键。即关系R中的一个属性组，它不是R的候选码（键），但它与另一个关系S的候选码相对应，则称之为这个属性组为关系S相对于关系R的外键（外码）。

数据库范式：关系数据库中关系必须满足一定的要求，这个要求就是范式。
最重要的好处：1、减少数据冗余，这个是最主要的好处，其他好处都是由此附带而来的；2、消除异常，包括插入异常、更新异常、删除异常；3、让数据组织更加和谐。
注意：数据库范式是把双刃剑。范式是为了消除重复数据减少冗余数据，从而让数据库内的数据更好的组织，让磁盘空间得到有效利用的一种标准化标准，满足高级等级的范式的先决条件是满足低等级范式。
第一范式（1NF）：关系模式R中的所有属性都是不可分的基本数据项，即每一个属性不可再分。不符合第一范式的数据库就不是关系数据库。
第二范式（2NF）：属于第一范式，并且每一个非主属性都完全函数依赖于R的码（候选键），即消除非主属性对码（候选键）的部分函数依赖。简单的说，是表中的属性必须完全依赖于候选键（码）的全部属性，而不是部分候选键（码）。所以如果只有码（候选键）只有一个属性并满足1NF，那它一定是2NF。这样做的目的是进一步减少插入异常和更新异常。
第三范式（3NF）：属于第二范式，并且任何属性（组）不依赖于非主属性（组）；即消除传递依赖，使得任何属性（组）只依赖于码（候选键）。
BC规范（BCNF）：属于3NF，并且主属性不依赖于主属性。有多种等价表达方式：每个非平凡依赖的左边必须包含键码。BC范式既检查非主属性，又检查主属性，当只检查非主属性时，就变成了3NF。可以这么说：如果一个关系到达了3NF，并且它只有一个候选键（码），或者它的每个候选码都是单属性，则该关系自然达到BC范式。
注意：一个数据库设计符合3NF或BCNF就可以了，在BC范式之上还有第四范式和第五范式。数据库范式进行分解的过程中我们会发现，应用的范式等级越高则表越多。表多则会带来如下问题：查询时多表连接增加了查询的复杂度，降低了查询性能。现在的磁盘空间成本已经很低，所以范式应用并不是等级越高越好，要视情况而定。

数据库事务：
事务的完整性（Atomic、Consistent、Isolated、Durable）通过这四个属性来衡量一个事务的质量。违反事务完整性的问题有三类：脏读(dirty read)、不可重复读(nonrepeatable read)、幻影行(phantom rows)：
原子性：事务作为一个工作单元，事务处理完成则所有的工作要么在数据库中保存下来，要么完全回滚，不保留。
一致性：事务完成或撤消后，数据都应该处于一致的状态。
隔离性：多个事务同时运行时，之间应该不相互干扰，要防止一个事务处理其他事务也要同时修改的数据，以及不合理和不完整的数据存取。
永久性：事务提交以后，所有的工作就被永久地保存下来。

SQL事务的隔离级别：全局的global、会话级别的session的事务隔离级别设置。
SQL标准定义了4类隔离级别：Read Uncommitted、Read Committed、Repeatable Read（MVCC）、Serializable。
SQL事务的三种类型：自动提交事务、显示事务、隐式事务。

数据完整性约束：实体完整性、域完整性、参照完整性、用户自定义完整性。
实体完整性：规定表的每一行在表中是唯一的实体。
域完整性：表中的列必须满足某种特定的数据类型约束。
参照完整性：两个表的主键和外键数据应保持一致，保持表之间数据一致性，防止数据丢失或无意义的数据扩散。
用户自定义完整性：根据应用环境，用户需要添加一些特殊的约束条件，以反映某一具体应用满足的语义要求。
完整性约束的类型：与表有关的约束、域约束和断言。
一般的用户自定义约束：not null、unique、primary key、foreign key、cascade、desc、default约束、check约束、触发器。
数据库还有：存储过程、函数。

数据库用户权限控制：grant、rewoke。