这篇文章只是自己对数据库中的知识的一个索引可能不适合广大网友阅读
数据库概述
基本概述
①数据也就是数字化之后的信息。
②数据库是一个数据的集合，其中包括数据与是数据之间的联系。
③数据库管理系统，则用来管理数据。
④数据库系统则是一整套的东西包括，数据库，数据库管理程序（和其开发工具），所服务的应用程序，数据库管理员。
⑤一般情况下称数据库系统为数据库。
发展阶段
主要分为：
①人工管理阶段，这个时候的数据不会长期存在计算机中，用完就删除，一个程序对应着一个数据集数据不共享冗余度高。
②文件系统阶段，这时文件系统出现数据能够长期的保存在外存上，实现了数据和程序的分离，数据能够共享但是数据之间的联系是比较弱的。
③数据库阶段，数据结构化，冗余度低，联系强。
④也就是现在流行的这些分布式数据库和图数据库ORM框架等等。
三级模式两级映像
当然无论如何数据库中的数据是存储在硬盘上的，再加上文件系统的出现从逻辑上来看数据库中的数据最终还是保存在了文件系统上。比如说.sql文件。
数据库为了保障数据的灵活使用与独立性所采用的机制叫做三级模式，两级印象。如下图所示：
此处有图
模式
外模式：也就是应用层面的模式，对于不同的用户会有不同的外模式。举个例子就是普通用户不能够观看影片但是VIP就可以。但是这个影片是确实存在于数据库中的。还比如淘宝的推荐系统对于每用户所看到的数据是不同的。外模式是模式的子集。一个应用程序只能够使用一个外模式，但是一个外模式可以服务于多个应用。
模式：是对一个数据库全体数据在逻辑层面上的描述，同时一个数据库只能够有一个模式。同一个模式有多个外模式，我们看到的数据库的表，和查询结果事实上也是外模式。它综合的考虑了所有用户的需求逻辑化的结合成一个有机的整体。
内模式：反映了在物理上实际存储方式。是以B树还是以Hash表来存储，数据有没有被压缩，等等。
映像
外模式/模式映像：它定义了模式和外模式之间的映射关系。
模式/内模式映像：它定义了模式和内模式之间的映像。
数据库的体系结构
敲黑板，这一段对于数据库的认识来说比较重要。
此处有图
SQL支持三级模式两级映像，如下图所示。用户在最上面的一层使用SQL，视图属于外模式，基本表是模式，存储文件是内模式。
①其中与模式对应的概念是基本表，在数据库中一个关系就对应着一个基本表。
②外模式由视图构成，而视图是由其它的视图或者基本表构成。所以视图并不是真实存在的基本表而是一个虚表。
③存储文件的逻辑结构组成了关系数据库的内模式，对于用户来说是透明的。顺便基本表与存储文件是多对多的。
④用户可以使用SQL来操作视图。注意了用户操作的是视图！也就是说我们平常查到的数据库的消息是一种视图它是一种虚表。
数据库中的关系代数
在数据库中可以通过关系代数来表达查询需求，而关系代数是一种抽象的查询语言。
并、差、交、笛卡尔积、选择、投影、连接、除
其中并、差、交与集合的操作一样这里就不在多说了。选择是指选择一行，投影是指选择一列。这里说一下笛卡尔积、连接、除。
①笛卡尔积
笛卡尔积就是所有情况的组合，如下图所示：
此处有图
②连接
一般的连接遵循的是一定的比较关系，比如说大于小于，当普通连接遵循的关系为等于的时候连接的关系也就成为了等值连接，当等值连接去掉等值的属性的时候也就成为了自然连接。
此处有图
③除
除是比较复杂的一个运算。
首先说一个概念就是像，要发生除的运算就会有两个集合，如果大的集合中的一个子元素所对应的属性能够包含小的集合中的全部元素（也就是交集）那么这个交集就是像。而像所对应的元素就应该进入除的集合。
此处有图
数据库设计
数据库设计和软件设计有相似之处，下面简单介绍一下新奥尔良的步骤。
需求分析
概念结构设计
逻辑结构设计
物理结构设计
数据库实施
运维
这里详细介绍一下需求分析，概念结构的设计，逻辑结构的设计中的核心方法。
需求分析
需求分析的工作就是要找到数据的基本流动情况，使用的基本工具就是数据流图和数据字典。
数据流图
①数据流图是由实体、操作、和数据存储组成。
②它根据数据颗粒度的不同进行逐级细化，直到基本的增删改查。
此处有图
数据字典
是由数据项、数据流、数据结构数据存储所组成。
此处有图
概念结构设计
主要工作描述数据实体之间的对应关系。可以自顶向下、自底向上、逐步扩张来描述这个关系。可以构建实体关系图（ER图），整个ER图中实体的关系又可以分为1:1、1:n、 n:m。
此处有图
逻辑结构的设计
这个阶段主要的工作就是将ER图转化为实际的表，当然在构造表的过程中会出现函数的依赖关系，这将会导致数据冗余，插入和删除的异常。为此又提出了规范化数据库设计的范式。
函数依赖
完全依赖
X-->Y 而且X的真子集推导不出Y则Y完全依赖于X。
部分依赖
X的真子集能够推出Y则Y部分依赖于X。（这里我们可以看出部分依赖的讨论的决定因素是复合的属性）
传递依赖
X-->Y 但是 Y推导不出X，同时Y-->Z这时我们就说Z就传递依赖于X。
范式
说白了范式的由高到低就是一个解耦的过程，由于过分依赖的存在就会导致一些不合理的牵连的关系。从而造成插入，删除异常，数据冗余等问题。
第一范式
一个表含有部分依赖，传递依赖函数关系。
第二范式
一个表含有传递依赖函数关系。
第三范式
对于非主属性来说没有传递依赖与部分依赖关系。但是不能保证主属性之间的依赖。
BC范式
第三范式只是消除了主属性对码的依赖而没有消除主属性对码的依赖，对于所有的属性（包括主属性和非主属性），来说都没有部分依赖和传递依赖。
这里就有一个例子就是，如果在学生成绩管理相关的表中有如下的模型：
(SNo, CNo)-->SName
(SName, CNo)-->SNo
假设SName唯一，也就出现了主码对候选码的部分依赖，也就出现了一种情况，当学生的姓名需要修改时，所有他选课所对应的名称都得修改。