笔试题:数据库 (2)

1. 数据库的常见范式

目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,还又称完美范式)。

在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF),其余范式以次类推。一般说来,数据库只需满足第三范式(3NF)就行了。

第一范式(1NF)—— 每一列原子不可分

在关系模型中,数据库表的每一列都是不可分割的原子数据项而不能是集合,数组,记录等非原子数据项。

某个属性有多个值时,必须拆分为不同的属性。

有些关系模型中突破了1NF的限制,这种称为非1NF的关系模型。例如:Oracle表存放字符类型的列

因此,是否必须满足1NF的最低要求,主要依赖于所使用的关系模型。

第二范式(2NF)—— 消除部分函数依赖

在第一范式(1NF)的基础上建立起来的,要求数据库表中的每个实例或行必须可以被唯一地区分,实体的属性完全依赖于主关键字,不能存在部分依赖(仅依赖主关键字一部分的属性)。

如果不符合2NF,这个选课关系表会存在如下问题:

(1) 数据冗余:同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。

(2) 更新异常:若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。

(3) 插入异常:假设要开设一门新的课程,暂时还没有人选修。这样,由于还没有"学号"关键字,课程名称和学分也无法记录入数据库。

(4) 删除异常:假设一批学生已经完成课程选修,这些选修记录就应该从数据库表中删除。但是,与此同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。

缺点

假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分),关键字为组合关键字(学号, 课程名称),因为存在如下决定关系:
(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
这个数据库表不满足第二范式,因为存在如下决定关系:
(学号,课程名称) → (成绩)
(课程名称) → (学分)
(学号) → (姓名, 年龄)
即存在组合关键字中的字段决定非关键字的情况。

第三范式(3NF)—— 消除传递依赖(非主属性对主属性的)

在第一范式(2NF)的基础上建立起来的,要求一个数据库表中不包含已在其它表中已包含的非主关键字信息,即属性不依赖于其它非主属性

例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。

巴斯-科德范式(BCNF)—— 消除传递依赖(所有属性对主属性的)

修正的第三范式。即当2NF(第二范式)消除了非主属性对键的传递函数依赖,则称为3NF。对3NF关系进行投影,将消除原关系中主属性对键的部分与传递依赖,得到一组BCNF关系。

例如,假设仓库管理关系表为UserWarehouse(仓库ID,存储物品ID,管理员ID,数量),且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品,则这个数据库表中存在如下决定关系:

(仓库ID,存储物品ID)->(管理员ID,数量)

(管理员ID,存储物品ID)->(仓库ID,数量)

所以,(仓库ID,存储物品ID)和(管理员ID,存储物品ID)都是UserWarehouse的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:

(仓库ID)->(管理员ID)

(管理员ID)->(仓库ID)

即存在关键字段决定关键字段的情况,所以其不符合Boyce-Codd范式。为了符合Boyce-Codd范式,应当把仓库管理关系表分解为两个关系表:仓库管理表UserWarehouse(仓库ID,管理员ID)和仓库表Warehouse(仓库ID,存储物品ID,数量)。
第四范式(4NF)—— 消除传递依赖(非平凡且非函数依赖的多值依赖)

关系模式R<U,F>∈1NF,如果对于R的每个非平凡多值依赖X→→Y(Y  X),X都含有候选码,则R∈4NF。
(X→Y)
如果R ∈ 4NF, 则R ∈ BCNF
第五范式(5NF)——关系模式R中的每一个连接依赖均由R的候选码所隐含

完美范式。

2. 常见关系型和非关系型数据库

常用的关系数据库有Oracle,SqlServer,MySql,SyBase,Informix等。

常用的非关系数据库: NoSQL,泛指非关系型的数据库。

关系模型中常用的概念:

关系:可以理解为一张二维表,每个关系都具有一个关系名,就是通常说的表名

元组:可以理解为二维表中的一行,在数据库中经常被称为记录

属性:可以理解为二维表中的一列,在数据库中经常被称为字段

域:属性的取值范围,也就是数据库中某一列的取值限制

关键字:一组可以唯一标识元组的属性,数据库中常称为主键,由一个或多个列组成

关系模式:指对关系的描述。其格式为:关系名(属性1,属性2, ... ... ,属性N),在数据库中成为表结构

关系型数据库的优点:

容易理解:二维表结构是非常贴近逻辑世界的一个概念,关系模型相对网状、层次等其他模型来说更容易理解

使用方便:通用的SQL语言使得操作关系型数据库非常方便

易于维护:丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率

关系型数据库瓶颈:

高并发读写需求:硬盘I/O是一个很大的瓶颈

海量数据的高效率读写:在一张包含海量数据的表中查询,效率是非常低的

高扩展性和可用性:在基于web的结构当中,数据库是最难进行横向扩展的,当一个应用系统的用户量和访问量与日俱增的时候,数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说,对数据库系统进行升级和扩展是非常痛苦的事情,往往需要停机维护和数据迁移。

对网站来说,关系型数据库的很多特性不再需要了:事务一致性、读写实时性、复杂SQL

关系型数据库在对事物一致性的维护中有很大的开销,而现在很多web2.0系统对事物的读写一致性都不高

对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出这条数据的,但是对于很多web应用来说,并不要求这么高的实时性.

复杂SQL,特别是多表关联查询不再需要

NoSQL(NoSQL = Not Only SQL ),意即“不仅仅是SQL”,是一项全新的数据库革命性运动。NoSQL数据库的四大分类。

键值(Key-Value)存储数据库:会使用到一个哈希表。

列存储数据库:这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在,但是它们的特点是指向了多个列。

文档型数据库:文档型数据库的灵感是来自于Lotus Notes办公软件的,而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档,半结构化的文档以特定的格式存储,比如JSON。文档型数据库可 以看作是键值数据库的升级版,允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如:CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB,已经开源。

图形(Graph)数据库:图形结构的数据库同其他行列以及刚性结构的SQL数据库不同,它是使用灵活的图形模型,并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL),因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。[2]  如:Neo4J, InfoGrid, Infinite Graph.

因此,我们总结NoSQL数据库在以下的这几种情况下比较适用:1、数据模型比较简单;2、需要灵活性更强的IT系统;3、对数据库性能要求较高;4、不需要高度的数据一致性;5、对于给定key,比较容易映射复杂值的环境。

(简单映射复杂,灵活IT系统,性能要求高一致性要求低)

分类 Examples举例 典型应用场景 数据模型 优点 缺点
键值(key-value)[3]  Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB 内容缓存,主要用于处理大量数据的高访问负载,也用于一些日志系统等等。[3]  Key 指向 Value 的键值对,通常用hash table来实现[3]  查找速度快 数据无结构化,通常只被当作字符串或者二进制数据[3] 
列存储数据库[3]  Cassandra, HBase, Riak 分布式的文件系统 以列簇式存储,将同一列数据存在一起 查找速度快,可扩展性强,更容易进行分布式扩展 功能相对局限
文档型数据库[3]  CouchDB, MongoDb Web应用(与Key-Value类似,Value是结构化的,不同的是数据库能够了解Value的内容) Key-Value对应的键值对,Value为结构化数据 数据结构要求不严格,表结构可变,不需要像关系型数据库一样需要预先定义表结构 查询性能不高,而且缺乏统一的查询语法。
图形(Graph)数据库[3]  Neo4J, InfoGrid, Infinite Graph 社交网络,推荐系统等。专注于构建关系图谱 图结构 利用图结构相关算法。比如最短路径寻址,N度关系查找等 很多时候需要对整个图做计算才能得出需要的信息,而且这种结构不太好做分布式的集群方案。[3] 

3. 常用数据库引擎

要利用一种开发工具访问一种数据库,就必须通过一种中介程序,这种开发工具与数据库之间的中介程序就叫数据库引擎。

(1) Mysql数据库引擎

MYSQL支持三个引擎:ISAM、MYISAM和HEAP。另外两种类型INNODB和BERKLEY(BDB),也常常可以使用。

ISAM

在设计之时就考虑到数据库被查询的次数要远大于更新的次数。因此,ISAM执行读取操作的速度很快,而且不占用大量的内存和存储资源。

ISAM的两个主要不足之处在于,它不支持事务处理,也不能够容错:如果你的硬盘崩溃了,那么数据文件就无法恢复了。必须经常备份你所有的实时数据。

MYISAM

MYISAM是MYSQL的ISAM扩展格式和缺省的数据库引擎。除了提供ISAM里所没有的索引和字段管理的大量功能,MYISAM还使用一种表格锁定的机制,来优化多个并发的读写操作。

代价是你需要经常运行OPTIMIZE TABLE命令,来恢复被更新机制所浪费的空间

MYISAM还有一些有用的扩展,例如用来修复数据库文件的MYISAMCHK工具和用来恢复浪费空间的MYISAMPACK工具。

MYISAM强调了快速读取操作,这可能就是为什么MYSQL受到了WEB开发如此青睐的主要原因:在WEB开发中你所进行的大量数据操作都是读取操作。所以,大多数虚拟主机提供商和INTERNET平台提供商只允许使用MYISAM格式。

INNODB

包括了对事务处理和外来键的支持,这两点都是前两个引擎所没有的。

(2) Microsoft JET

Access和Visual Basic所提供的内嵌数据库功能的核心元素。JET是一种全能关系数据库引擎,可用来处理多数中小型数据库。(上课常用的)

(3) ODBC

Open DataBase Connectivity(ODBC,开放数据库互连),本质上是一组数据库访问API。(PHP里见过)

它提供一种标准的数据库访问方法以访问不同平台的数据库。一个ODBC应用程序既可以访问在本地PC机上的数据库,也可以访问多种异构平台上的数据库,例如SQL Server、Oracle或者DB2。

4. 事务的隔离级别

(1) 未提交读(read uncommitted):会出现脏读、不可重复读和幻读。脏读的设计只是为了提供非阻塞读,但是对于oracle来说,默认就提供非阻塞读,即查询不会受到任何增删改操作的影像,因为oracle提供了undo来存放更新前的数据。

(2) 提交读(read committed):会出现不可重复读和幻读。oracle的默认事务隔离级别。

(3) 重复读(repeatable read):会出现幻读。

(4) 串行化(serializable):隔离级别最高,不允许出现脏读、不可重复读和幻读。即一个事务执行结束了另一个事务才能执行。当然并发性也就最差

除了这四种,oracle还提供read only隔离级别,即只支持读,在该级别中,该事务只能看到事务开始那一刻提交的修改。

脏读、不可重复读、幻读含义

脏读:一个事务可以读另一个事务未提交的数据。

不可重复读:在一个事务中不同时间段查询出现不同的结果,可能被更新可能被删除。

幻读:在一个事务中不同时间段查询,记录数不同。与不可重复读的区别是:在幻读中,已经读取的数据不会改变,只是与以前相比,会有更多的数据满足查询条件。

5. 数据库的索引

6. 数据库的优化方式

索引优化

分库分表分区

选择适当的字段类型

读写分离使负载均衡



发布了397 篇原创文章 · 获赞 541 · 访问量 255万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览