数据库基础知识

来源:互联网 发布:济南网络电视台直播 编辑:程序博客网 时间:2024/05/21 19:25
实体(集)---属性---联系:在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。