关系型数据库的本质是什么，mongodb为什么不是关系型数据库

关系型数据库的本质是基于关系模型，使用二维表格来存储和管理数据，通过建立表与表之间的关系来进行数据查询和操作。mongodb不是关系型数据库的原因：它不同于传统的关系型数据库，其本质是对象型数据库。

一、关系型数据库的本质是什么，mongodb不是关系型数据库的原因

关系型数据库的本质是“relation”。这里中文翻译成“关系”有点笼统，因为还有一个词叫“relationship”也被说成“关系”。“relation”是个数学概念，定义如下：给定n个集合S1、S2、 S3、 …、 Sn, R是一个n元数组(n-tuples)，它的名列前茅个元素取自集合S1，第二个元素取自集合S2，以此类推。我们将R称之为基于该n 个集合的一个Relation，Sj为R的第j个域(Domain)。

这个定义有点抽象，举个例子：有这样一个“relation”，它由以下集合组成：学号，姓名，性别，班级。每个集合都是一个给定的有限集合，比如学号的范围定义为10000~99999，姓名也是个有限集合，性别就是男和女，班级也是个有限的集合。从这些有限的集合中各取一个值，组成一个元组“tuple”。理论上这些元组也是一个有限集合，称之为“关系”，即“relation”。而我们更习惯称之为“表”，即”table”。此外，这种建模思想能促进重用，例如“性别”这个值域也可用在“教师”这个表里。这点在建立大型信息系统是极有价值的。

不能将MongoDB叫做关系型数据库是因为它一开始的设计理念是“对象”，而不是“关系”。不管在工程上你怎么用它，它只能被唤做对象或者文档型数据库。关系型数据库在诞生之时，主要解决的问题之一是消除访问路径依赖。当你用MongoDB的时候，你可以根据一个对象的任意属性去访问相应的对象实体。但如果两个不同类型的对象存在某种关系(relationship) ，你想通过对象A的某个属性访问到对象B的某个属性会比较困难。你必须在A中保存B的一些关联信息，然后自己在应用层面去实现类似SQL JOIN的关联访问。这就是说你的应用程序可能存在只能通过A去访问B的限制。也许在开始的时候，这样的限制无所谓。

二、关系型数据库概述

1、简介

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

2、特点

存储方式：传统的关系型数据库采用表格的储存方式，数据以行和列的方式进行存储，要读取和查询都十分方便。
存储结构：关系型数据库按照结构化的方法存储数据，每个数据表都必须对各个字段定义好，再根据表的结构存入数据，这样做的好处就是由于数据的形式和内容在存入数据之前就已经定义好了，所以整个数据表的可靠性和稳定性都比较高，但带来的问题就是一旦存入数据后，如果需要修改数据表的结构就会十分困难。
存储规范：关系型数据库为了避免重复、规范化数据以及充分利用好存储空间，把数据按照最小关系表的形式进行存储，这样数据管理的就可以变得很清晰、一目了然，当然这主要是一张数据表的情况。如果是多张表情况就不一样了，由于数据涉及到多张数据表，数据表之间存在着复杂的关系，随着数据表数量的增加，数据管理会越来越复杂。
扩展方式：由于关系型数据库将数据存储在数据表中，数据操作的瓶颈出现在多张数据表的操作中，而且数据表越多这个问题越严重，如果要缓解这个问题，只能提高处理能力，也就是选择速度更快性能更高的计算机，这样的方法虽然可以一定的拓展空间，但这样的拓展空间一定有非常有限的，也就是关系型数据库只具备纵向扩展能力。
查询方式：关系型数据库采用结构化查询语言（即SQL）来对数据库进行查询，SQL早已获得了各个数据库厂商的支持，成为数据库行业的标准，它能够支持数据库的CRUD（增加，查询，更新，删除）操作，具有非常强大的功能，SQL可以采用类似索引的方法来加快查询操作。
规范化：在数据库的设计开发过程中开发人员通常会面对同时需要对一个或者多个数据实体进行操作，这样在关系型数据库中，一个数据实体一般首先要分割成多个部分，然后再对分割的部分进行规范化，规范化以后再分别存入到多张关系型数据表中，这是一个复杂的过程。
事务性：关系型数据库强调ACID规则（原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）），可以满足对事务性要求较高或者需要进行复杂数据查询的数据操作，而且可以充分满足数据库操作的高性能和操作稳定性的要求。并且关系型数据库十分强调数据的强一致性，对于事务的操作有很好的支持。
读写性能：关系型数据库十分强调数据的一致性，并为此降低读写性能付出了巨大的代价，虽然关系型数据库存储数据和处理数据的可靠性很不错，但一旦面对海量数据的处理的时候效率就会变得很差，特别是遇到高并发读写的时候性能就会下降的非常厉害。
授权方式：关系型数据库常见的有 Oracle，SQLServer，DB2，Mysql，除了Mysql大多数的关系型数据库如果要使用都需要支付一笔价格高昂的费用，即使是免费的Mysql性能也受到了诸多的限制。

3、设计步骤

关系型数据库设计的过程可大体分为四个时期。

用户需求分析时期，主要是了解和分析用户对数据的功能需求和应用需求，是整个设计过程的基础，事关整个数据库应用系统设计的成败。
数据库设计时期，主要是将用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的数据模型，可用实体—联系模型来表示，然后将其转换为已选好的关系型数据库管理系统RDBMS所支持的一组关系模式并为其选取一个适合应用环境的物理结构，包括存储结构和存取方法。
数据库实现时期，包括数据库结构创建阶段和应用行为设计与实现阶段，是根据数据库的物理模型创建数据库、创建表、创建索引、创建聚簇等。
数据库运行与维护阶时期，最后一个阶段则是数据库应用系统经过试运行后即可投入正式运行。

4、设计原则

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

命名规范化：在概念模型设计中，对于出现的实体、属性及相关表的结构要统一。例如在数据库设计中，指定学生Sstudent，专指本科生，相关的属性有：学号、姓名、性别、出生年月等，及每个属性的类型、长度、取值范围等都要进行确定，这样就能保证在命名时不会出现同名异义或异名同义、属性特征及结构冲突等问题。
数据的一致性和完整性：在关系型数据库中可以采用域完整性、实体完整性和参照完整性等约束条件来满足其数据的一致性和完整性，用check、default、null、主键和外键约束来实现。
数据冗余：数据库中的数据应尽可能地减少冗余，这就意味着重复数据应该减少到最少。例如：若一个部门职员的电话存储在不同的表中，假设该职员的电话号码发生变化时，冗余数据的存在就要求对多个表进行更新操作，若某个表不幸被忽略了，那么就会造成数据不一致的情况。所以在数据库设计中一定要尽可能存在少地冗余。
范式理论：在关系数据库设计时，一般是通过设计满足某一范式来获得一个好的数据库模式，通常认为3NF在性能、扩展性和数据完整性方面达到了较好的平衡，因此,一般数据库设计要求达到3NF，消除数据依赖中不合理的部分，最终实现使一个关系仅描述一个实体或者实体间一种联系的目的。