【数据库】初识数据库

1.简介

数据库，简而言之可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。

所谓“数据库”是以一定方式储存在一起、能予多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

2.数据库管理系统

主条目：数据库管理系统

数据库管理系统（英语：Database Management System，简称DBMS）是为管理数据库而设计的电脑软件系统，一般具有存储、截取、安全保障、备份等基础功能。数据库管理系统可以依据它所支持的数据库模型来作分类，例如关系式、XML；或依据所支持的计算机类型来作分类，例如服务器群集、移动电话；或依据所用查询语言来作分类，例如SQL、XQuery；或依据性能冲量重点来作分类，例如最大规模、最高运行速度；亦或其他的分类方式。不论使用哪种分类方式，一些DBMS能够跨类别，例如，同时支持多种查询语言。

3.类型

• 对象型

• 层次型《轻量级》

• 网状型

• 关系型

3.1.关系数据库(SQL)

• MySQL

• • MariaDB（MySQL的代替品，英文维基百科从MySQL转向MariaDB）

  • Percona Server（MySQL的代替品·）

• PostgreSQL

• Microsoft Access

• Microsoft SQL Server

• Google Fusion Tables

• FileMaker

• Oracle数据库

• Sybase

• dBASE

• Clipper

• FoxPro

3.2.非关系型数据库（NoSQL）

主条目：NoSQL

• BigTable（Google）

• Cassandra

• MongoDB

• CouchDB

键值（key-value）数据库

• Apache Cassandra（为Facebook所使用）：高度可扩展

• Dynamo

• LevelDB（Google）

• Kafka

• Redis

3.3.数据库模型

• 对象模型

• 层次模型（轻量级数据访问协议）xml

• 网状模型（大型数据储存）

网状数据库是采用网状原理和方法，以网状数据模型为基础建立的数据库。一般是指由网状数据库管理系统产生的网状数据库系统。网状数据模型是以记录类型为结点的网络结构，即一个结点可以有一个或多个下级结点，也可以有一个或多个上级结点，两个结点之间甚至可以有多种联系，例如“教师”与“课程”两个记录类型，可以有“任课”和“辅导”两种联系，称之为复合链。两个记录类型之间的值可以是多对多的联系，例如一门课程被多个学生修读，一个学生选修多门课程。

3.3.1.关系模型

关系型数据库，是指采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，以便于用户理解，关系型数据库这一系列的行和列被称为表，一组表组成了数据库。用户通过查询来检索数据库中的数据，而查询是一个用于限定数据库中某些区域的执行代码。关系模型可以简单理解为二维表格模型，而一个关系型数据库就是由二维表及其之间的关系组成的一个数据组织。

3.3.2.设计原则

在进行关系型数据库的设计过程中，要遵循以下几个原则，借此可以提高数据库的存储效率、数据完整性和可扩展性。

1 .命名规范化

在概念模型设计中，对于出现的实体、属性及相关表的结构要统一。例如在数据库设计中，指定学生Student，专指本科生，相关的属性有：学号、姓名、性别、出生年月等，及每个属性的类型、长度、取值范围等都要进行确定，这样就能保证在命名时不会出现同名异义或异名同义、属性特征及结构冲突等问题。

2 .数据的一致性和完整性

在关系型数据库中可以采用域完整性、实体完整性和参照完整性等约束条件来满足其数据的一致性和完整性，用check、default、null、主键和外键约束来实现。

3.数据冗余

数据库中的数据应尽可能地减少冗余，这就意味着重复数据应该减少到最少。例如：若一个部门职员的电话存储在不同的表中，假设该职员的电话号码发生变化时，冗余数据的存在就要求对多个表进行更新操作，若某个表不幸被忽略了，那么就会造成数据不一致的情况。所以在数据库设计中一定要尽可能存在少地冗余。

4.范式理论

在关系数据库设计时，一般是通过设计满足某一范式来获得一个好的数据库模式，通常认为3NF在性能、扩展性和数据完整性方面达到了最好的平衡，因此,一般数据库设计要求达到3NF，消除数据依赖中不合理的部分，最终实现使一个关系仅描述一个实体或者实体间一种联系的目的。

5.性能

3.4.数据库范式

第一范式

一范式就是属性不可分割。属性是什么？就是表中的字段。 不可分割的意思就按字面理解就是最小单位，不能再分成更小单位了。 这个字段只能是一个值，不能被拆分成多个字段，否则的话，它就是可分割的，就不符合第一范式。 不过能不能分割并没有绝对的答案，看需求，也就是看你的设计目标而定。 举例： 学生信息组成学生信息表，有姓名、年龄、性别、学号等信息组成。 姓名不可拆分吧？所以可以作为该表的一个字段。 但我要说这个表要在国外使用呢？人家姓和名要分开，都有特别的意义，所以姓名字段是可拆分的，分为姓字段和名字段。

<!--简单来说，一范式是关系数据库的基础，但字段是否真的不可拆分，根据你的设计目标而定。-->

第二范式

二范式就是要有主键，要求其他字段都依赖于全部主键。 为什么要有主键？没有主键就没有唯一性，没有唯一性在集合中就定位不到这行记录，所以要主键。 其他字段为什么要依赖于主键？因为不依赖于主键，就找不到他们。更重要的是，其他字段组成的这行记录和主键表示的是同一个东西，而主键是唯一的，它们只需要依赖于主键，也就成了唯一的。 如果有同学不理解依赖这个词，可以勉强用“相关”这个词代替，也就是说其他字段必须和它们的主键相关。因为不相关的东西不应该放在一行记录里。 举例： 学生信息组成学生表，姓名可以做主键么？ 不能！因为同名的话，就不唯一了，所以需要学号这样的唯一编码才行。 那么其他字段依赖于主键是什么意思？

<!--就是“张三”同学的年龄和性别等字段，不能存储别人的年龄性别，必须是他自己的，因为张三的学号信息就决定了，这行记录归张三所有，不能给无关人员使用。-->

第三范式

三范式就是要消除传递依赖，方便理解，可以看做是“消除冗余”。 消除冗余应该比较好理解一些，就是各种信息只在一个地方存储，不出现在多张表中。 比如说大学分了很多系（中文系、英语系、计算机系……），这个系别管理表信息有以下字段组成： 系编号，系主任，系简介，系架构。 那么再回到学生信息表，张三同学的年龄、性别、学号都有了，我能不能把他的系编号，系主任、系简介也一起存着？ 如果你问三范式，当然不行，因为三范式不同意。 因为系编号，系主任、系简介已经存在系别管理表中，你再存入学生信息表，就是冗余了。 三范式中说的传递依赖，就出现了。 这个时候学生信息表中，系主任信息是不是依赖于系编号了？而这个表的主键可是学号啊！ 所以按照三范式，处理这个问题的时候，学生表就只能增加一个系编号字段。 <!--这样既能根据系编号找到系别信息，又避免了冗余存储的问题。-->