这次是找一个网页,写er图,然后根据er图设计模型,然后生成数据库表
 我找的是起点中文网,根据这个网站做了分析,画了e-r图.
 
 模型
 

1，数据库设计概述
 
1.1，数据库设计的基本概念
 
 
 
数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。
 
 
数据库设计的目标：是为用户和各种应用系统提供一个信息基础设施和高效率的运行环境 。
 
 
数据库设计的基本任务：是根据用户的信息需求、处理需求和数据库的支持环境(包括硬件、操作系统和DBMS)，设计出数据库模式(包括外模式、逻辑模式和内模式)及其典型的应用程序。
 
 
1.2，数据库设计的方法
 
 
 
直观设计法（手工试凑发）：数据库设计只是一种经验的反复实施，而不能称为是一门科学，缺乏科学分析理论基础和工程手段的支持，因为设计质量与设计人员的经验和水平有直接关系，所以设计质量很难保证。具有周期短、效率高、操作简便、易于实现等优点。主要是用于简单小型系统。 
 
 
规范设计法：将数据库设计分为若干阶段，明确规定各阶段的任务，采用“自顶向下、分层实现、逐步求精”的设计原则，结合数据库理论和软件工程设计方法，实现设计过程的每一细节，最终完成整个设计任务。（新奥尔良方法、基于E-R模型的数据库设计方法、基于3NF（第三范式）的设计方法、面向对象的数据库设计方法、统一建模语言（UML）方法）。
 
 
计算机辅助设计法：在数据库设计的某些过程中，利用计算机和一些辅助设计工具，模拟某一规范设计方法，并以人的知识或经验为主导，通过人机交互方式实现设计中的某些部分。 （Oracle 公司开发的 Designer、Sybase公司开发的 PowerDesigner）。
 
 
1.3，数据库设计的基本步骤
 
 
 
需求分析：通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求。
 
 
概念结构设计：通过对用户需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型。
 
 
逻辑结构设计：将概念结构转换为某个数据库管理系统所支持的数据模型，并对其进行优化。
 
 
物理结构设计：为逻辑数据结构选取一个最适合应用环境的物理结构,包括存储结构和存取方法。
 
 
数据库实施：根据逻辑设计和物理设计的结果构建数据库,编写与调试应用程序,组织数据入库并进行试运行。
 
 
数据库运行和维护：经过试运行后即可投入正式运行,在运行过程中必须不断对其进行评估、调整与修改。
 
 
★需求分析和概念设计独立于任何数据库管理系统 
 
 
★逻辑设计和物理设计与选用的数据库管理系统密切相关
 
 
 
设计阶段
 
 
设计描述
 
 
数据
 
 
处理
 
 
需求分析
 
 
数据字典、数据项、数据流、数据存储的描述
 
 
数据流图和判定树、数据字典中处理过程的描述
 
 
概念结构设计
 
 
概念模型(ER图)、数据字典
 
 
系统说明书 (系统要求、方案、概图、数据流图)
 
 
逻辑结构设计
 
 
某种数据模型(如关系)
 
 
系统结构图(模块结构)
 
 
物理设计
 
 
存储安排、方法选择、存取路径建立
 
 
模块设计
 
 
实施阶段
 
 
编写模式、装入数据、数据库试运行
 
 
程序编码、编译联结、测试
 
 
运行维护
 
 
性能监测、转储/恢复、数据库重组和重构
 
 
新旧系统转换、运行、维护
 
2，需求分析
 
2.1，需求分析及其任务
 
 
 
需求分析就是分析用户的需求：是设计数据库的起点，结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用。
 
 
需求分析的任务：由数据库设计人员和用户双方共同收集信息需求和处理需求；通过仔细分析；将这些需求按一定的规范要求以用户和设计人员都能理解接受的文档形式确定下来。
 
 
2.2，需求分析的方法
 
 
 
需求分析的三个步骤：
 
 
①需求调查: 收集需求信息, 调查清楚用户的实际要求, 与用户达成共识。
 
 
②分析、整理和表达这些需求信息，形成需求说明书（例如，包括DFD和DD等）。
 
 
③评审：由主管部门和专家评价、审批。
 
 
 
 
需求调查
 
 
需求调查的目的：主要是了解企业的组织机构设置, 各个组织机构的职能、工作目标、职责范围，主要业务活动及大致工作流程，获得各个组织机构的业务数据及其相互联系的信息，为分析整理工作做好前期基础工作。
 
 
需求调查的内容：①组织机构的情况:  组成, 职责, 作用, 现状, 问题，哪些业务适合计算机管理, 哪些不适合。②各个部门的业务活动现状(调查的重点):  输入和使用的数据, 加工处理方法, 数据的流程, 输出的数据及格式, 注意收集原始数据资料, 如台帐、单据、发票、收据、统计报表、文档、档案等。③外部要求：调查数据处理的响应时间、频度和如何发生的规则，以及经济效益的要求，安全性和完整性的要求。④协助用户明确对新系统的各种要求(调查的又一个重点): 信息要求, 处理要求, 安全性要求, 完整性要求, 未来规划中对数据的应用需求等。⑤确定新系统的边界: 哪些由计算机完成, 哪些由人工完成。
 
 
需求调查的步骤：①调查组织机构情况。②调查各部门的业务活动情况。③协助用户明确对新系统的各种要求，包括信息要求、处理要求、完全性与完整性要求。④确定新系统的边界。
 
 
需求调查的方式：①跟班作业：通过亲身参加业务工作了解业务活动的情况。②开调查会：通过与用户座谈来了解业务活动情况及用户需求。③请专人介绍。④询问：对某些调查中的问题，可以找专人询问。⑤设计调查表请用户填写：调查表设计合理，则很有效。⑥查阅记录：查阅与原系统有关的数据记录。
 
 
需求调查策略：
 
 
对高层负责人的调查: 一般采用个别交谈方式, 先给一份详细的调查提纲, 以便有所准备。
对中层管理人员的调查: 可采用开座谈会, 个别交谈, 发调查表, 查阅记录的调查方式。
对基层业务人员的调查: 主要采用发调查表, 个别交谈或跟班作业的调查方式。
 
 
 
分析整理
 
 
分析整理的工作：
 
 
①业务流程分析和表示
 
 
目的是获得业务流程及业务与数据联系的形式描述。
采用数据流层次结构分析法(SA法)。
分析结果以数据流图(DFD图)表示, 再辅以数据字典(DD)作补充描述。
 
②需求信息的补充描述
 
 
数据字典: 主要用于概念结构设计。
业务活动清单: 列出每一部门中最基本的工作任务。
其他需求清单: 如完整性、安全性、一致性要求。
 
③撰写需求分析说明书
 
 
分析整理的方法：结构化分析方法（SA方法）
 
 
SA方法从最上层的系统组织机构入手，采用自顶向下、逐层分解的方式分析系统。
 
 
SA步骤：a)先把任何一个系统都抽象为DFD图形式。b)然后从最上层的系统组织机构入手，采用自顶向下，逐步分解，逐步求精的方式分析系统，获得多层DFD图。
 
 
数据流图（DFD）
 
 
https://shao12138.blog.csdn.net/article/details/109103706#t2
 
 
数据字典（DD）
 
 
https://shao12138.blog.csdn.net/article/details/109103706#t4
 
 
3，概念结构设计
 
3.1，概念模型
 
 
 
概念结构设计：将需求分析得到的用户需求抽象为信息结构（即概念模型）的过程。
 
 
目前应用最普遍的是实体关系（E-R）模型，它将现实世界的信息结构统一用属性、实体以及它们之间的联系来描述。
 
 
3.2，E-R概念模型
 
https://shao12138.blog.csdn.net/article/details/103659528
 
3.3，概念结构设计
 
 
 
实体与属性的划分
 
 
为了简化E-R图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待。
 
 
两条准则：①作为属性，不能再具有需要描述的性质。属性必须是不可分的数据项，不能包含其他属性。②属性不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。
 
 
4，逻辑结构设计
 
4.1，逻辑结构设计概述
 
 
 
逻辑结构设计的任务：将概念结构转换成特定DBMS所支持的数据模型的过程。关系数据库逻辑设计的结果是一组关系模式的定义 。
 
 
逻辑结构设计的步骤：
 
 
①将概念结构转换为一般的关系、网状、层次模型； 
 
 
②将转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换；
 
 
③对数据模型进行优化。
 
 
 
 
关系数据库逻辑设计的步骤
 
 
①将概念模型(例如基本E-R图)转换为关系模式的集合 --- 得到关系数据库模式；
 
 
②运用关系数据理论对关系数据库模式进行规范化处理；
 
 
③对关系数据库模式进行评价；
 
 
④对关系数据库模式进行修正；
 
 
⑤设计关系子模式 --- 视图。
 
 
4.2，ER图向关系模型的转换
 
 
 
一个实体转换为一个关系模式
 
 
原则：关系的属性=实体型的属性；关系的码=实体型的码；关系模式的码(用下横线标出) = 实体型的码；
 
 
 
 
转换为：学生(学号，姓名，系别)
 
 
 
 
每个联系类型转换为独立的关系模式
 
 
原则：关系模式的属性 = 与该联系相连的各实体型的码+该联系自身的属性；关系模式的码(用下划线标出) = 各实体型的码；
 
 
①一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并
 
 
转换为一个独立的关系模式，原则：关系模式的属性 = 与该联系相连的各实体型的码  +  该联系自身的属性；关系模式的码(用下划线标出) = 各实体型的码；
 
 
与某一端实体对应的关系模式合并，原则：合并后关系的属性=加入对应关系的码和联系本身的属性；合并后关系的码不变；
 
 
 
 
②一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
 
 
转换为一个独立的关系模式，原则：关系模式的属性 = 与该联系相连的各实体型的码  +  该联系自身的属性；关系模式的码(用下划线标出) = n端实体的码；
 
 
与某一端实体对应的关系模式合并，原则：合并后关系的属性=在n端关系中加入1端关系的码和联系本身的属性；合并后关系的码不变；
 
 
 
 
③一个m:n联系必须转换为一个独立的关系模式
 
 
转换为一个独立的关系模式，原则：关系模式的属性 = 与该联系相连的各实体型的码  +  该联系自身的属性；关系模式的码(用下划线标出) =各实体码的组合；
 
 
 
 
④三个或三个以上实体间的一个多元联系转换为一个关系模式，原则：关系模式的属性 = 与该联系相连的各实体型的码  +  该联系自身的属性；关系模式的码(用下划线标出) =各实体码的组合；
 
 
⑤具有相同码的关系模式可合并
 
 
目的：减少系统中的关系个数
 
 
合并方法：
 
 
将其中一个关系模式的全部属性加入到另一个关系模式中
然后去掉其中的同义属性（可能同名也可能不同名）
 适当调整属性的次序
 
 
 
把每一个实体装换为一个关系
 
 
首先分析各实体的属性，从中确定其主键，然后分别用关系模式表示。
 
 
实体：学生	对应的关系：学生（学号，姓名，性别，年龄）
实体：课程	对应的关系：课程（课程号，课程名）
实体：教师	对应的关系：教师（教师号，姓名，性别，职称）
实体：系		对应的关系：系（系名，电话）
 
 
把每一个联系装换为关系模式
 
 
将4个联系转换为关系模式，其中2个多对多类型的联系转换为独立关系模式，2个一对多的联系也转换为独立的关系模式。
 
 
联系：属于	对应的关系：属于（教师号，系名）
联系：讲授	对应的关系：讲授（教师号，课程号）
联系：选修	对应的关系：选修（学号，课程号，成绩）
联系：拥有	对应的关系：拥有（学号，系名）
 
 
 
 
画出关系图
 
 
 
 
4.3，数据模型的优化
 
 
 
数据库逻辑设计的结果不是唯一的，得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。
 
 
★规范化过程可分为两个步骤：确定范式级别，实施规范化处理
 
 
①确定数据依赖：写出每个关系模式内部各属性之间的数据依赖；写出不同关系模式的属性(外码和主码)之间的数据依赖；
 
 
 
 
②对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。
 
 
③按照数据依赖的理论对关系模式进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。
 
 
④按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。（并不是规范化程度越高的关系就越优。当一个应用的查询中经常涉及到两个或多个关系模式的属性时，系统必须经常地进行连接运算，而连接运算的代价是相当高的，可以说关系模型低效的主要原因就是做连接运算引起的，因此在这种情况下，第二范式甚至第一范式也许是最好的。）
 
 
⑤对关系模式进行必要的分解，提高数据操作的效率和存储空间的利用率。常用的两种分解方法是水平分解和垂直分解。
 
 
水平分解：把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。
垂直分解：把关系模式R的属性分解为若干子集合，形成若干子关系模式。
 
4.4，设计用户子模式（外模式）
 
 
 
将概念模型转换为逻辑模型(数据库模式)后, 还应根据局部应用的需求, 结合具体DBMS的特点, 设计用户的外(子)模式 。利用RDBMS提供的视图(View)功能设计。
 
 
定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面：①使用更符合用户习惯的别名。②针对不同级别的用户定义不同的视图，以保证系统的安全性。③简化用户对系统的使用。
 
 
视图：https://shao12138.blog.csdn.net/article/details/109584275#t23
 
 
5，物理结构设计
 
 
 
数据库的物理结构：数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选定的数据库管理系统。
 
 
数据库的物理设计：为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。
 
 
数据库物理设计的步骤：①确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构;②对物理结构进行评价，评价的重点是时间和空间效率；若评价结果满足原设计要求，则可进入到物理实施阶段。否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。
 
 
5.1，数据库物理设计的内容和方法
 
 
 
准备工作：①要充分了解应用环境，详细分析要运行的事务。以获得选择物理数据库设计所需要的参数。分析数据库查询事务需要的信息、数据更新事务需要的信息、每个事务在各关系上运行的频率和性能要求等。②要充分了解所用的 DBMS的内部特征, 特别是系统提供的存取方法和存储结构。
 
 
内容：①为关系模式选择存取方法，即要确定选择哪些存取方法，建立哪些存取路径。②设计关系(表)、聚簇、索引、日志、备份等数据的物理存储结构。
 
 
5.2，关系模式存取方法选择
 
 
 
数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。
 
 
数据库关系系统：①B+树索引存取方法；②Hash索引存取方法；③聚簇存取方法；
 
 
 
 
B+树索引
 
 
选择索引存取方法 就是根据应用要求确定：对哪些属性列建立索引、对哪些属性列建立组合索引、对哪些索引要设计为唯一索引。
 
 
选贼索引存取方法的一般规则：
 
 
如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这组）属性上建立索引（或组合索引）
如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引
如果一个（或一组）属性经常在连接操作的连接条件中 出现，则考虑在这个（或这组）属性上建立索引
 
关系上定义的索引数过多会带来较多的额外开销，无论是维护还是查找
 
 
HASH存取方法
 
 
选择Hash存取方法的规则：如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中，而且满足下列两个条件之一
 
 
该关系的大小可预知，而且不变； 
该关系的大小动态改变，但所选用的数据库管理系统提供了动态Hash存取方法。
 
聚簇存取方法
 
 
为了提高某个属性（或属性组）的查询速度，把这个或这些属性（称为聚簇码）上具有相同值的元组集中存放在连续的物理块上，称为聚簇。该属性（或属性组）称为聚簇码。许多关系型数据库管理系统都提供了聚簇功能。
 
 
聚簇索引：建立聚簇索引后，基表中数据也需要按指定的聚簇属性值的升序或降序存放。也即聚簇索引的索引项顺序与表中元组的物理顺序一致。一个数据库可以建立多个聚簇，一个关系只能加入一个聚簇。
 
 
聚簇索引的适用条件：很少对基表进行增删操作；很少对其中的变长列进行修改操作；
 
 
聚簇索引的用图：
 
 
大大提高按聚簇属性进行查询的效率
节省存储空间：聚簇以后，聚簇码相同的元组集中在一起了，因而聚簇码值不必在每个元组中重复存储，只要在一组中存一次就行了。
 
聚簇索引的局限性：
 
 
聚簇只能提高某些特定应用的性能
建立与维护聚簇的开销相当大；对已有关系建立聚簇，将导致关系中元组的物理存储位置移动，并使此关系上原有的索引无效，必须重建。当一个元组的聚簇码改变时，该元组的存储位置也要做相应改变。
 
聚簇索引的适用范围：
 
 
既适用于单个关系独立聚簇，也适用于多个关系组合聚簇
当通过聚簇码进行访问或连接是该关系的主要应用，与聚簇码无关的其他访问很少或者是次要的时，可以使用聚簇。尤其当SQL语句中包含有与聚簇码有关的ORDER BY, GROUP BY, UNION, DISTINCT等子句或短语时，使用聚簇特别有利，可以省去或减化对结果集的排序操作
 
设计候选聚簇：①常在一起进行连接操作的关系可以建立组合聚簇；
 
 
②如果一个关系的一组属性经常出现在相等比较条件中，则该单个关系可建立聚簇；
 
 
③如果一个关系的一个（或一组）属性上的值重复率很高，则此单个关系可建立聚簇。
 
 
检查候选聚簇索引中的关系，取消不必要的关系
 
 
①从聚簇中删除经常进行全表扫描的关系
 
 
②从聚簇中删除更新操作远多于连接操作的关系
 
 
③从聚簇中删除重复出现的关系
 
 
5.3，确定数据库的存储结构
 
 
 
确定数据库物理结构主要指确定数据的存放位置和存储结构，包括：确定关系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等。
 
 
影响数据存放位置和存储结构的因素：硬件环境和应用需求；要综合考虑存取时间、存储空间利用率和维护代价（这三个方面常常是相互矛盾的。比如：消除一切冗余数据虽能够节约存储空间和减少维护代价，但往往会导致检索代价的增加。必须进行权衡，选择一个折中方案。）
 
 
 
 
确定数据的存放位置
 
 
原则：根据应用情况将易变部分与稳定部分分开存放，经常存取部分与存取频率较低部分分开存放。
 
 
①可以将日志文件与数据库对象（表、索引等）放在不同的磁盘以改进系统的性能。
 
 
②可以将比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效。
 
 
③数据库数据备份、日志文件备份等由于只在故障恢复时才使用，而且数据量很大，可以考虑存放在磁带上。
 
 
确定系统配置
 
 
①系统都为这些变量（同时使用数据库的用户数、同时打开的数据库对象数、内存分配参数、缓冲区分配参数（使用的缓冲区长度、个数）、存储分配参数 、物理块的大小、物理块装填因子、时间片大小、数据库的大小、锁的数目等）赋予了合理的缺省值。在进行物理设计时需要根据应用环境确定这些参数值，以使系统性能最优。
 
 
②在物理设计时对系统配置变量的调整只是初步的，要根据系统实际运行情况做进一步的调整，以切实改进系统性能。
 
 
5.4，评价物理结构
 
 
 
评价物理数据库的方法完全依赖于所选用的DBMS 。
 
 
评价内容：
 
 
对数据库物理设计过程中产生的多种方案进行细致的评价；
定量估算各种方案的存储空间、存取时间、维护代价；
对估算结果进行权衡、比较，从中选择一个较优的合理的方案作为数据库的物理结构。
 
6，数据库的实施和维护
 
6.1，数据的载入和应用程序的调试
 
 
 
数据库实施阶段主要工作：
 
 
①建立实际的数据库结构。用DDL定义数据库：定义基本表、索引、约束、视图等；
 
 
②装入数据，组织数据入库(又称数据库加载)，组织数据入库是数据库实施阶段最主要的工作。
 
 
数据装载方法：人工方法；计算机辅助方法
数据筛选、输入、转换(工具)、校验，确保正确
 
③编制和调试数据库应用程序。数据库应用程序的设计应该与数据库设计并行进行。数据库结构建立好后，就可以开始编制与调试数据库的应用程序。
 
 
6.2，数据库的试运行
 
 
 
数据库的试运行：应用程序调试完成，并且已有一小部分数据入库后，就可以开始对数据库系统进行联合调试，也称数据库的试运行。
 
 
主要工作包括：
 
 
①功能测试：实际运行应用程序，执行对数据库的各种操作，测试应用程序的各种功能。
 
 
②性能测试：测量系统的性能指标，分析是否符合设计目标。
 
 
★数据库性能指标的测量
 
 
①数据库物理设计阶段在评价数据库结构估算时间、空间指标时，作了许多简化和假设，忽略了许多次要因素，因此结果必然很粗糙。
 
 
②数据库试运行则是要实际测量系统的各种性能指标（不仅是时间、空间指标），如果结果不符合设计目标，则需要返回物理设计阶段，调整物理结构，修改参数；有时甚至需要返回逻辑设计阶段，调整逻辑结构。
 
 
★数据的分期入库
 
 
①重新设计物理结构甚至逻辑结构，会导致数据重新入库
 
 
②由于数据入库工作量实在太大，所以可以采用分期输入数据的方法
 
 
先输入小批量数据供先期联合调试使用
待试运行基本合格后再输入大批量数据
逐步增加数据量，逐步完成运行评价
 
★数据库的转储和恢复
 
 
①在数据库试运行阶段，系统还不稳定，硬、软件故障随时都可能发生
 
 
②系统的操作人员对新系统还不熟悉，误操作也不可避免
 
 
③因此必须做好数据库的转储和恢复工作，尽量减少对数据库的破坏
 
 
6.3，数据库的运行和维护
 
 
 
在数据库运行阶段，对数据库经常性的维护工作主要是由数据库管理员完成的，包括：
 
 
①数据库的转储和恢复
 
 
数据库管理员要针对不同的应用要求制定不同的转储计划，定期对数据库和日志文件进行备份。
一旦发生介质故障，即利用数据库备份及日志文件备份，尽快将数据库恢复到某种一致性状态
 
②数据库的安全性、完整性控制
 
 
初始定义
 
 
数据库管理员根据用户的实际需要授予不同的操作权限
根据应用环境定义不同的完整性约束条件
 
修改定义
 
 
当应用环境发生变化，对安全性的要求也会发生变化，数据库管理员需要根据实际情况修改原有的安全性控制
由于应用环境发生变化，数据库的完整性约束条件也会变化，也需要数据库管理员不断修正，以满足用户要求
 
③数据库性能的监督、分析和改进
 
 
在数据库运行过程中，数据库管理员必须监督系统运行，对监测数据进行分析，找出改进系统性能的方法。
 
 
利用监测工具获取系统运行过程中一系列性能参数的值
通过仔细分析这些数据，判断当前系统是否处于最佳运行状态
如果不是，则需要通过调整某些参数来进一步改进数据库性能
 
④数据库的重组织与重构造
 
 
数据库的重组织
 
 
为什么要重组织数据库   数据库运行一段时间后，由于记录的不断增、删、改，会使数据库的物理存储变坏，从而降低数据库存储空间的利用率和数据的存取效率，使数据库的性能下降。
重组织的形式：全部重组织和部分重组织，只对频繁增、删的表进行重组织
重组织的目标：提高系统性能
 
数据库的重构造
 
 
为什么要重构造数据库  数据库应用环境发生变化，会导致实体及实体间的联系也发生相应的变化，使原有的数据库设计不能很好地满足新的需求。
重构造的主要工作  根据新环境调整数据库的模式和内模式增加或删除某些数据项、改变数据项的类型、增加或删除某个表、改变数据库的容量、增加或删除某些索引。
重构造数据库的程度是有限的  若应用变化太大，已无法通过重构数据库来满足新的需求，或重构数据库的代价太大，  则表明现有数据库应用系统的生命周期已经结束，应该重新设计新的数据库应用系统了。

 
 

 
数据库系统设计概述
 

  
世界上只有两种开发人员，一种使用数据库系统的，一种开发数据库系统的。
 
 
数据是系统最重要的信息。大部分系统都是对数据的管理。应用系统通过数据模型来构建现实世界，通过算法操作对象或数据结构，来改变数据模型的状态。数据被组织在操作系统文件中，我们通过数据系统来组织，查询，搜索，处理数据。
 
本文将从数据库的发展、数据库的分类、常见数据库架构，数据库常见概念和技术等方面探讨这个我们接触最多的底层系统，并通过穿插不同数据库的实现原理，来了解数据库的具体实现。
 
本文分为五个大章节。探古溯源，从数据库的诞生，发展，现状和展望来了解数据库存在的意义，以及数据库设计的历史与现实原因。百家争鸣，本节从不同分类方式，讲解一些不同的数据库系统实现，有助于拓展我们的视野，在技术选型时可以作为参考(底层数据库系统的选型对整个系统的架构实在太重要了)。承上启下，本节是整篇文章的中间章节，前两章以兴趣点，纯理论展开，在本节中将对前两章做一个总结，有了前两章知识，我们已经可以去选择适合项目需求的数据库系统，对那些想更深入了解底层存储的同学也可以选择自己感兴趣的数据库类型和方案找到相应的实现，从而进入下一步学习。下面两章将讲解更多具体的技术点。知行合一，这一章节将讲解数据库的实现，分析一些数据库架构，分布式问题和解决方案，透析具体的数据库常见的技术点。
 
针对不同兴趣，大家可以按需取之，跳过不感兴趣的，看想关注的点。
 
一、探古溯源
 

  
疑今者察之古，不知来者视之往。——《管子》
 
 
数据库管理系统允许人员组织，存储和从计算机检索数据。在计算机的早期，使用“打孔卡”用于输入，输出和数据存储。打孔卡提供了一种快速的数据输入和检索方法。数据库在计算机的最新发展中起了非常重要的作用。第一批计算机程序是在 1950 年代初期开发的，几乎完全专注于编码语言和算法。当时，计算机基本上是大型计算器，数据（名称，电话号码）被认为是处理信息的残余物。当计算机开始商业化后，数据的重要性开始越来越被人重视。
 
 
 

  
题外话：穿越时间——笔者去了解一个东西，总喜欢追根溯源，从时间的起点，或从逻辑的深处开始探索。一个东西的逻辑原点往往是纯粹的简单的，之后随时间发展和广延的展开会逐渐复杂起来。所以从头开始了解一个东西，往往更容易理解。比如我们看一个系统的源码，可以从该系统的 1.0.0 版本开始，可以从这个系统最初想要解决的问题开始。
 
 
计算机数据库始于 1960 年代。此十年中，有两种流行的数据模型：称为 CODASYL 的网络模型和称为 IMS 的层次模型。SABER 系统被证明是商业上成功的一种数据库系统，该系统被 IBM 用来帮助美国航空管理其预订数据。
 
1970 年，大神 EF Codd 发表了一篇重要的论文：《????大型共享数据库的数据关系模型》，提出了使用关系数据库模型的建议，他的想法改变了人们对数据库的看法。在他的模型中，数据库的架构或逻辑组织与物理信息存储断开连接，这成为数据库系统的标准原理。之后 UBC 开发了 Ingres 和在 IBM 开发了 SystemR。Ingres 使用一种称为 QUEL 的查询语言，引导而诞生了 Ingres Corp，MS SQL Server，Sybase，PACE 和 Britton-Lee 之类的系统。另一方面，System R 使用 SEQUEL 查询语言，它有助于 SQL / DS，DB2，Allbase，Oracle 和 Non-Stop SQL 的开发。关系数据库管理系统（RDBMS）已经成为公认的术语。
 
1976 年 P. Chen 提出了一个新的数据库模型，称为 Entity-Relationship，即 ER。该模型使设计人员可以专注于数据应用程序，而不是逻辑表结构。1980 年结构化查询语言或 SQL 成为标准查询语言。
 
RDBM系统是存储和处理结构化数据的有效方法。然而，随着互联网的快速发展，“非结构化”数据（视频，照片，音乐等）变得更加普遍。非结构化数据既是非关系数据，又是无模式数据，而关系数据库管理系统根本就没有设计用于处理此类数据。21 世纪后，NoSql模型进入人们的视野，NoSql 的出现是对互联网以及对更快的速度和对非结构化数据的处理需求的一种回应。一般而言，由于 NoSQL 数据库的速度和灵活性，它们在某些用例中比关系数据库更可取的。NoSQL模型是非关系型的，并且采用“分布式”数据库系统。这个非关系系统速度很快，使用临时组织数据的方法，并且处理大量不同类型的数据。一般而言，NoSQL 相对于 RDBMS 系统有如下优势：
 
更高的可扩展性
分布式计算系统
低成本
灵活的架构
可以处理非结构化和半结构化数据
没有复杂的关系
 
在数据库的发展历程中，虽然只经历了短短半个世纪，却诞生了一批优秀的数据库系统，SystemR、Postgresql、Mysql、DB2、Oracle、MongoDB、HBase、Neo4j、Elasticsearch 等等，都在软件的发展中发挥了重要的。
 
 
 
二、百家争鸣
 

  
现在春天来了嘛，一百种花都让它开放，不要只让几种花开放，还有几种花不让它开放，这就叫百花齐放。—— 毛泽东
 
 
迄今为止，业界诞生的数据系统数不胜数。如果你打开????DB-Engines 网站，可以看到几百个功能定位不同的数据库系统。查看DB-Engines的分类排名，可以看出DB-Engines将如此众多的系统大致分为以下几类(????网址)：
 
 
 
Willian Blair 在《Database Software Market:The Long-Awaited Shake-up》一文中以以下维度为数据库系统做了一个细致的分类：关系型/非关系型、操作型/分析型。
 
 
 
上图中的纵轴分类为 Relational Database（关系型数据库，RDBMS）和 Nonrelational Database （非关系型数据库，NoSQL），横轴的分类为 Operational（操作型，即 OLTP）和 Analytical（分析型，即 OLAP）。
 
非关系型的分类是一个比较笼统的划分，主要是针对传统关系型来区分的，与传统关系型系统模型不一致的都划分到了非关系型中。
 
非关系型（NoSQL）可以再进一步划分：Key-Value 型、列存储型、文档型、图数据库等。
 
文档存储：MongoDB、Elasticsearch、Amazon DocumentDB、Azure Cosmos DB 等。
Key-Value 存储：Redis Labs、Oracle Berkeley DB、Amazon DynamoDB、Aerospike、LevelDB 等。
图数据库：Neo4j 等。
时序数据库：InfluxDB、Timescale 等。
WideCloumn：DataStax、Cassandra、Apache HBase 和 Bigtable 等。
 
 
 
关系模型
 
关系型模型是大多数开发人员接触最早，接触最多的数据库模型。它基于集合理论，是最经典的数据库模式。关系型数据库采用行和列的二维表来建模数据。它适合于提前知道数据模型，并且数据模型比较固定，发生变化比较小，对查询比较灵活的场景，你只需要将数据以行和列的方式存储，在查询的时候以不同的需要组合数据。关系型不适合数据层次较多，记录与记录之间关联较多的场景，这种场景往往造成查询复杂度上升，查询性能下降。
 
关系型数据库主要用于大多数商业数据处理，其大多数是事务处理（如 ERP 系统、银行交易、航空公司订票、销售系统、金融财务管理系统等）和批处理场景（如客户发票、工资单、报告等）。
 
20 世纪 70 年代至今，关系型数据库经久不衰，其简洁的数据模型和经典的 SQL 查询语句支撑了当前大部分互联网系统，在线论坛、社交网络、电子商务等等，各式各样的系统背后，都隐藏着一个强大的关系数据库。
 
关系型数据库用的比较多的除了 Oracle、Sql Server 等商业数据库外，就是 Mysql 了，另外本人比较喜欢和推崇是 Postgresql，被称为世界上功能最强大的开源数据库。
 
分析的世界
 
联机分析处理（Online analytical processing），简称OLAP，OLAP 是相对与传统的OLTP（联机事务处理，Online Transaction Processing）系统而言的，OLTP 是传统的关系型数据库的主要应用，侧重于基本的、日常的交互式的事务处理，例如银行交易。OLAP 是数据仓库系统的主要应用，支持复杂的分析操作，侧重分析决策支持，并且提供直观易懂的查询结果。OLAP 工具让用户能够从多个角度交互地分析多维数据。OLAP 由三个基本的分析操作组成：上卷（roll-up）、钻取（drill-down）、切片（slicing）和切块（dicing）。上卷涉及可以在一个或多个维度中累积和计算的数据的聚合。
 
OLAP 利于大数据量，数据更新少，经常使用大量数据做聚合统计的场景。OLTP 适合数据量小，频繁操作更新数据的场景。
 
OLAP 主要应用于商业智能、风控分析、智能报表等业务场景。
 
分析和事务是两个世界。在分析需求不大的时候，很多团队直接使用业务事务数据库做分析使用，这只能支持小数据量、分析需求变化不大，弱分析的场景。真正的数据分析场景，往往使用单独的数据仓库。在不影响业务库的情况下，实时或周期批量地从中提取数据，转换成对分析友好的数据模式，执行必要的清理和转换，然后加载到数据仓库中。将数据导入仓库的过程称为提取-转换-加载(Extract-Transform-Load, ETL)。
 
 
 
OLTP和OLAP没有明确的边界，它们的一些典型特性如下所示：
 

 
OLTP
OLAP

用户
操作人员,底层管理人员
决策人员,高级管理人员
功能
日常操作处理
分析决策
DB 设计
面向应用
面向主题
数据
当前的,新的,细节的,二维的,分立的
历史的,聚集的,多维集成的,统一的
存取
读写数十上百条数据
读百万级数据
读特征
基于键，返回少量数据
基于大量数据汇总
写特征
随机访问，低延迟
批量或数据流
DB 大小
100MB~~GB
100GB~~TB
时间要求
实时性
对时间的要求不严格
主要应用
数据库
数据仓库
 

 
业界有许多优秀的开源的 OLAP 系统，比如：
 
Druid：Metamarkets 公司开发的一个用于大数据实时处理的开源分布式系统。目前已经成为 Apache 的开源项目。????官网 ????了解
Kylin：Apache Kylin™ 是一个开源的、分布式的分析型数据仓库，提供 Hadoop/Spark 之上的 SQL 查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由 eBay 开发并贡献至开源社区。它能在亚秒内查询巨大的表。????官网
Presto：Presto 是一个对 PB 级数据运行交互式分析的开源分布式 SQL 查询引擎。????官网
ClickHouse：ClickHouse 是由号称“俄罗斯 Google”的 Yandex 开发的一个列存储的 OLAP 系统。????官网
 
列式存储
 
传统 OLTP 数据库通常采用行式存储。以下图为例，所有的列依次排列构成一行，以行为单位存储，再配合以 B+ 树或 SS-Table 作为索引，就能快速通过主键找到相应的行数据。
 
 
 
行存储适用于 OLTP 场景，OLTP 的大多数操作都是以实体(Entity)为单位，即对每条记录的增删改查，因此将一行数据在物理上放在相邻的位置更利于操作，也更利于特定的优化。
 
在 OLAP 场景中，极少单独操作单条记录的情况。OLAP 分析往往针对大量的数据集，在大量的数据集的基础上对特定的列做分组、过滤、聚合操作。因此在物理上将每列数据放在相邻的位置。
 
 
 
这样如果针对某一列做分析聚合，只需要找到相应列的文件，或数据块的位置，比如，要计算上图数据的平均 Age，只需要获取 Age 列的数据集即可。但是，面向行的存储引擎仍然需要将所有行从磁盘加载到内存中、解析它们，并过滤出不符合所需条件的行。这可能需要很长的时间。
 
基于列模式的存储，天然就会具备以下几个优点：
 
自动索引
因为基于列存储，所以每一列本身就相当于索引。所以在做一些需要索引的操作时，就不需要额外的数据结构来为此列创建合适的索引。
利于数据压缩
利于压缩有两个原因。一来你会发现大部分列数据基数其实是重复的，拿上面的数据来说，因为同一个 author 会发表多篇博客，所以 author 列出现的所有值的基数肯定是小于博客数量的，因此在 author 列的存储上其实是不需要存储博客数量这么大的数据量的；二来相同的列数据类型一致，这样利于数据结构填充的优化和压缩，而且对于数字列这种数据类型可以采取更多有利的算法去压缩存储。
 
列式存储的概念其实很早就有，只是应时代所需，列式存储在近几年才火热起来，一时涌现了很多优秀的列式存储数据库，甚至很多之前的行存储系统，也有了列式存储的能力。
 
Hbase：一个分布式的、面向列的开源数据库，该技术来源于 Fay Chang 所撰写的 Google 论文《Bigtable：一个结构化数据的[分布式存储系统]》。HBase 不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是 HBase 基于列的而不是基于行的模式。
Cassandra：它最初由 Facebook 开发，用于改善电子邮件系统的搜索性能的简单格式数据，集 Google BigTable 的数据模型与 Amazon Dynamo 的完全分布式架构于一身。Facebook 于 2008 将 Cassandra 开源，此后，由于 Cassandra 良好的可扩展性其被许多知名网站所采用，成为了一种流行的分布式结构化数据存储方案。
其中上一章节提到的很多 OLAP 数据库大多数是面向列式存储的。如 Druid、ClickHouse 等。
 
检索不再高深
 
曾几何时，全文检索是一个多么高深的技术，虽然如 Google 这样的全网搜索引擎背后的搜索算法和技术依然不是轻易就可以实现的。但现在大大小小的各种 App，网站的搜索功能的背后技术基本被一个强大的开源系统轻松就可以实现了。这个系统就是 Elasticsearch，一个基于 Lucence 的分布式实时全文检索数据库。
 
伦敦的公寓内，Shay Banon 正在忙着寻找工作，而他的妻子正在蓝带 (Le Cordon Bleu) 烹饪学校学习厨艺。在空闲时间，他开始编写搜索引擎来帮助妻子管理越来越丰富的菜谱。
 
他的首个迭代版本叫做 Compass。第二个迭代版本就是 Elasticsearch（基于 Apache Lucene 开发）。他将 Elasticsearch 作为开源产品发布给公众，并创建了 #elasticsearch IRC 通道，剩下来就是静待用户出现了。
 
公众反响十分强烈。用户自然而然地就喜欢上了这一软件。由于使用量急速攀升，此软件开始有了自己的社区，并引起了人们的高度关注，尤其引发了 Steven Schuurman、Uri Boness 和 Simon Willnauer 的浓厚兴趣。他们四人最终共同组建了一家搜索公司。
 
一个程序员为帮助妻子管理菜谱开发的搜索工具最终称为一个强大的全文检索数据库。看来，面向对象依然是程序员创作的强大灵感源泉之一。
 
 
 
将非结构化数据中的一部分信息提取出来，重新组织，使其变得有一定结构，然后对此有一定结构的数据进行搜索，从而达到搜索相对较快的目的。这部分从非结构化数据中提取出的然后重新组织的信息，称之索引。将这些索引与文档建立映射关联，通过索引检索出对应的文档数据，这种词汇到文档的映射被称之为倒排索引。先建立索引，再对索引进行搜索的过程就叫全文检索。
 
提到全文检索，不得不提到的一个技术就是 Lucene，Lucene 是 apache 下的一个开放源代码的全文检索引擎工具包。提供了完整的查询引擎和索引引擎，部分文本分析引擎。
 
Elastisearch 就是基于 Lucene 的一个分布式开源全文检索数据库。它提供了一个分布式多用户能力的全文搜索引擎，基于 RESTful web 接口。Elasticsearch 是用 Java 开发的，并作为 Apache 许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。许多系统的搜索功能背后，其实就是一个强大的 Elastisearch 服务，Elasticsearch 也常由于日志检索，数据分析场景。
 
K-V 缓存霸主
 
在整个计算机系统中磁盘和网络是最慢的部分，一个系统中最重要的东西就是数据，而目前系统中的数据最终都存储在磁盘上。因此当前磁盘缓慢的读写速度和人民对系统响应数据和系统高并发之间的矛盾，就是目前系统需要解决的主要矛盾。将透彻了，所有的系统优化都是在缓解这个矛盾。
 
为提供系统响应数据和并发能力，一个最常见的手段就是缓存。在计算机系统中，CPU，内存，磁盘，网络的访问效率差着不同的数量级，为缓解这种数量级带来的访问效率问题，最常见的手段就是缓存。CPU 和内存之间有缓存，称之为 CPU 高效缓冲；内存和磁盘之间也自带缓存。
 
 
 
在分布式系统中，数据库访问的压力，我们常常使用分布式缓存系统来解决。
 
Redis 是一个高性能的 key-value 数据库。它支持存储的 value 类型相对更多，包括 string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和 hash（哈希类型）。Redis 支持缓存过期时间，原子操作，数据持久化，支持集群模式。
 
K-V 缓存：将数据 K-V 化并缓存在 Redis 中，从而提高数据的访问效率，减小数据库的访问压力，这种常见的系统优化策略。
分布式锁：分布式锁，就是一个全局的临界资源，通过对这个临界资源的独占达到一种全局锁的功能，任何全局共享资源都可以实现分布式锁的功能，甚至 MySql，分布式文件系统。基于 Redis 的分布式锁，是常见的一种实现。
Pub\Sub：发布订阅的管道功能本不应该是一个分布式缓存系统的功能，但 Redis 实现了这一部分功能，在一些简单的发布订阅场景下也可以很好的工作。
布隆过滤器：通过一个 bit 的 0 或 1 来表示 key 是否存在，通过 bit 集合来表示一组数据，这就是简单的布隆过滤器的实现。相对与用类似 Hash 的方式来存储 key 映射 boolean 值的方式，布隆过滤器可以节省大量的空间。Redis 就有布隆过滤器的实现。布隆过滤器常用来对大量数据做 True Or Flase 的判断，比如缓存是否存在，比如大量用户是否有权限。
HyperLogLog：HyperLogLog 是用来快速计算基数的。基数，即不重复元素的个数(类似 SQL 的 count distinct)。
工具：介绍一些好用的 Java 技术栈的相关工具。????Jetcache，阿里开源的一个基于注解的缓存框架。????Redisson，一个强大的 Redis Java 客户端工具。
 
小而精
 
通常我们使用的数据库系统大多是 Client-Server 模式的，即数据库服务作为一个常驻进程运行在 Server 端，应用程序通过 TCP/IP 协议访问数据库系统。还有一种嵌入式的数据库，可以运行在本机中，这种数据库嵌入到应用程序中，随应用程序启动，数据存储在本地磁盘中。这种数据库是轻量的，一般占用内存少，代码精简。
 
????SQLite：遵守 ACID，实现了大多数 SQL 标准，支持 SQL 语法。支持 JDBC。
????H2：一个 Java 编写的关系型数据库，它可以被嵌入 Java 应用程序中使用，或者作为一个单独的数据库服务器运行。Spring Boot 内置的数据库。
Berkeley DB：一个高效的嵌入式数据库和键-值数据库编程库。
????LevelDB：是 Google 开源的持久化 KV 单机数据库，具有很高的随机写，顺序读/写性能，LevelDB 应用了 LSM(Log Structured Merge) 策略。另一个 Facebook 基于 levelDB 开发的 RocksDB，也是一个高性能的 key-value 型内嵌式存储引擎。LevelDB 或 RocksDB 常常被当作存储引擎使用。比如强大的时间序列数据库 Influxdb 早期底层存储引擎就是用于的 LevelDB；RocksDB 是流式计算框架 Flink 的 Checkpoint 的底层存储引擎；著名的分布式 Actor 框架 Akka 也使用 RocksDB 作为默认的 checkpint 存储。由于其强大的顺序读写能力，也常常用来做 WAL(write-ahead-log)日志存储引擎。
 
这些小而精的嵌入式数据库，除了用在一些小型设备上，如手机客户端等。也常常被用于很多自研数据库系统的存储引擎。这些自研的数据库系统，以上面那些嵌入式数据库作为存储引擎，在上面实现自己特有功能，从而实现一个特殊的数据库系统，比如扩展分布式功能，基于其现实一个分布式存储系统；比如基于 LevelDB 等实现磁盘队列，和分布式队列；比如基于其存储特殊的模型的数据，如时间序列数据库；比如基于其实现本地操作日志记录和重试提交，实现最终一致性的分布式事务解决方案。
 
三、承上启下
 
前几章我们已经了解了数据库系统的发展，也从不同角度了解了数据库系统的不同分类，并且了解到了许多不同功能场景的数据库系统。为我们如何选择数据库系统已经增添了一份基础知识。我们应该如何选择一个适合的存储方案呢？
 
原则
 
选择是基于需求确定的。所以必须明确需求场景，然后按需求场景选择适合的存储方案。
没有调查就没有发言权。方案调研就是一个调查过程，需要先了解不同数据库的基本特性，才能选择合适的存储方案。
 
基本场景
 
和前章数据库系统的分类很相似。其实上面数据库系统的分类一方面就是基于不同的使用场景才设计的，从而有不同实现的数据库系统，从而有针对不同场景的特殊优化，从而逐渐形成了不同场景的特殊模型。
 
事务性，如 Mysql 这些是最常见的事务性系统使用的存储方案，满足 ACID，使用简单。支持千万级别数据级别的读写。分析性，适合 BI，数据报表、数据监控等数据服务系统。文档型，适合高度可变的数据模型，当你事先不知道你的数据看起来究竟像什么样子，文档型是一个不错的选择，文档型也适合点查询多余集合查询的场景。图数据库，图数据库是一种很特殊的，新兴的数据库类型，它侧重于分析解释数据之间的相互关系而不是数据值本身，它适合推荐引擎、权限访问控制和地理数据等场景。时序性，时序性数据库在数据分析，时序数据展示，监控领域使用比较多，它适合对大量时间型数据查询、过滤、组合、聚合分析等。K-V 型，缓存和固定 View 模式的数据展示，K-V 型的需要按查询组合好存储起来，这样查询时按 key 获取即可。
 
读写
 
是否需要写事务
顺序读写还是随机读写
偏点查询还是大量数据集分析查询
数据结构变化大，还是查询结构变化大
 
数据量
 
数据量，需要考虑数据的数量，也需要考虑数据数量的增长速度，这样就需要考虑数据库的量级承载能力以及水平扩展能力。
 
数据用途
 
对临时数据和重要的业务数据的存储可以采用相对侧重点不一致的方案。对数据的一致性要求的强弱也会影响数据存储系统的选型。对数据事务的要求，对数据保存时间的选择也会不一样。
 
可靠性
 
数据的可靠性即保证数据的可用的能力，可靠性与成本一般是权衡的一体两面，需要对数据可用性的要求选用不同的存储架构。
 
可扩展性
 
可扩展性表现在数据使用的可扩展和系统本身的可扩展上。
 
可维护性
 
可运维性：方便运营团队来保持系统平稳运行。
简单性：简化系统复杂性，使新工程师能够轻松理解系统。
可演化性：后续工程师能够轻松地对系统进行改进，并根据需求变化将其适配到非典型场景，也称为可延伸性、易于修改性或可塑性。
 
学习和了解数据底层存储，除了可以搭建良好的存储架构是提供思路上的帮助，也可以让我们学习到很多平时纯业务开发接触不多的底层技术实现。对底层技术的了解和掌握，又可以反过来让我们更加了解我们的整个业务系统，对系统的合理性优化做出重要的选择。也可以帮助我们实现自己的系统。
 
开源数据库系统的良好的分布式架构，优秀的网络通信，性能强劲的内存和磁盘访问优化以及更多经典的数据接口和算法都是值得我们学习和借鉴的。
 
四、知行合一
 

  
知是行的主意，行是知的工夫；知是行之始，行是知之成。—— 王阳明
 
 
这一章节将简单讲解一些数据库系统的常见技术点。
 
系统架构
 
Master-Slave
 
Master-slave 架构可以说是最常用的数据存储架构，关系型数据库如：mysql，postgreSql，oracle，Nosql 诸如：MongoDb，消息队列如：Kafka，RabbitMQ 等都使用了这种架构。
 
 
 
在整个系统中，Master 承担写任务，Slave 通过复制 Master 的数据保证与 Master 数据的一致性。Master 和 Slave 都可以承担读任务。Master 架构解决了数据的高可用问题（Slave 存储了数据副本），也扩展了数据读并发能力（多 Slave 同时通过读请求）。
 
在 Master-Slave 架构中，单 Master 如果出现故障，就会导致这个数据库系统不可用，这时就可以采用 Master-Master 架构，系统中同时存在多个 Master 节点，但是，多个 Mater 节点并不同时提供写服务，同时只会存在一个可写的 Master，另一个 Master 作为备机存在，只有当其他 Master 不可用时才会被选举称为 Master 节点提供写服务，作为备机的 Master 是可以提供读服务的。这种架构的只解决了单 Master 节点的高可用问题，并没有解决单 Master 负载过大的问题，这里之所以只有一个 Master 提供写服务，是为了保证写数据的一致性问题。
 
数据一致性
 
我们将同一份数据在不同数据节点上的存储称之为副本。只要系统中数据存在多个副本，就会有数据一致性问题。如何保证数据多副本的一致性，一直以来都是分布式系统的最大挑战。多节点数据同步，一般采用复制方式，从节点复制主节点的数据，多节点之间相互复制等等，但无论采用哪种方式，都无法避免不一致的情况。
 
数据一致性可以分为最终一致性和强一致性。强一致性模型能够允许你的单服务程序移植到分布式节点集群上并且不会发生任何错误。强一致性往往通过牺牲系统可用性来达到，在写入数据时，如无法保证多副本一致，则失败。最终一致性模型中，当停止改变数值的一段不确定的时间后，所有的复制集将会最终保持一致。这表明，在这段时间之前，数据副本在某种情形下是不一致的，但数据最终会达到一致，最终一致性意味着“收敛”，即预期所有的副本最终会收敛到相同的值。
 
在数据收敛过程中，为保证最终数据的一致性性，还有许多问题需要解决。如系统间的时序问题，原子提交问题，共识问题。
 
CAP 理论
 
**定理：**一个分布式系统不可能同时满足 consistency、availability、partition tolerance 这三个基本需求，最多同时满足两个。
 
consistency 一致性：所有节点同一时刻看到相同数据
availability 可用性：节点失败不阻止影响正在运行的节点的工作
partition tolerance 分区容错：即使出现信息丢失或网络、节点失败，系统也能继续运行（通过复制）
 
 
 
这三种性质进行俩俩组合，可以得到下面三种情况：
 
CA：完全严格的仲裁协议，例如 2PC（两阶段提交协议，第一阶段投票，第二阶段事物提交）
CP：不完全（多数）仲裁协议，例如 Paxos、Raft
AP：使用冲突解决的协议，例如 Dynamo、Gossip
 
CA 和 CP 系统设计遵循的都是强一致性理论。不同的是 CA 系统不能容忍节点发生故障。CP 系统能够容忍 2f+1 个节点中有 f 个节点发生失败。
 
分区
 
 
 
上面说副本只能保证数据的可用性。为提高大量数据集的读写能力，我们可以将数据拆分成不同的分区分开处理，这种技术称之为分片。
 
分片，即将数据集分割成相互独立的小数据集，减少因数据集增长而带来对单个节点的压力。数据分片有以下好处：
 
提高性能：限制分区中数据量的大小，降低数据压力
提高可用性：数据之间相互独立，不同分区之间失败互不影响，允许失败节点的存在
 
分区自然也会带来一些问题，首先需要考虑的就是如何分区的问题。
 
基于关键字区间：将数据按关键字划分为不同区间，将相同区间的数据写入同一个节点。比如用户数据 id 分布在[1-1000000]之间，需将数据分布到 10 个节点上，可以将数据划分成十个区间：
**关键字哈希分区：**通过 Hash 算法计算分区号，将数据写入相应分区号的分区中。
 
数据分区带来的负载倾斜和热点问题：由于数据的不确定性，数据关键字计算出来的分区存储可能集中在某几个区间内，这样就可能导致某些节点数据明显多余其他节点，这种数据集中于某个节点的情况就是数据热点。由于数据热点的出现，整个系统的负载将倾斜到这些节点上，造成分区间的负载不均衡，这就是负载倾斜问题。
 
去中心化：Dynamo
 
Dynamo 是 Amazon 的一个分布式存储。Amazon 发表了一篇论文 ????Dynamo: Amazon’s Highly Available Key-value Store 讲解 Dynamo 架构，使得 Dynamo 称为许多数据存储系统借鉴的架构。
 
Dynamo 基于一些众所周知的技术实现了可扩展性和高可用性：
 
数据通过一致性哈希算法进行分区和复制（partitioned and replicated）
通过对象版本化（object versioning）实现一致性
副本之间的一致性由一种仲裁的技术（quorum-like technique）和一个去中心化的副本同步协议（replica synchroni protocol）来保证
基于 gossip 协议进行分布式故障检测和成员检测（membership）协议管理节点
 
Dynamo 是一个完全去中心化的系统。
 
 
 
向 Dynamo 添加或移除存储节点不需要人工 partition（调整哈希节点）或 redistribution（在节点之间重新平衡数据分布）
 
Dynamo 采用最终一致性方案。
 
生产级别的存储系统的架构是很复杂的。除了最终存储数据的组件之外，系统还要针对以下方面制定可扩展和健壮的解决方案：负载均衡、成员管理（membership）、故障检测、故障恢复、副本同步、过载处理（overload handling）、状态转移、并发和任务调度、请求 marshalling、请求路由（routing）、系统监控和告警，以及配置管理。
 
下表总结了 Dynamo 使用的这些技术及每项技术的好处。
 
 
 
Partition
 
技术：一致性哈希
好处：增量可扩展性
 
写高可用
 
技术：读时协调（解决冲突）的向量时钟（vector clocks with reconciliation during reads）
好处：version size 和更新频率（update rates）解耦
 
短时故障处理
 
技术：宽松的选举和 hinted handoff（移交给其他节点处理，附带提示信息）
好处：部分副本不可用时，仍然可以提供高可用性和持久性
 
持久（permanent）故障恢复
 
技术：基于 Merkle tree 的逆熵（anti-entropy）
好处：后台同步版本不一致的副本
 
成员管理和故障检测
 
技术：基于 Gossip 的成员管理协议和故障检测
好处：保持了架构的对称性，无需一个中心组件（centralized registry）来存储成员和节点状态等信息
 
分布式数据库 Cassandra 就是 Dynamo 的典型实现。
 
有主架构：Bigtable
 
Bigtable 是 google 开源的数据库系统。Bigtable 是典型的有主架构。
 
Bigtable 主要由三个组件构成：
 
一个客户端库，会链接到每个客户端
一个 master server
多个 tablet server
 
master 负责：
 
将 tablet 分配给 tablet server
检测 tablet server 的过期（expiration）及新加（addition）事件
平衡 tablet server 负载
垃圾回收（GC）
处理 schema 变动，例如 table 和 column family 的创建
 
BigTable 的 Master 只负责元数据的管理，Table Server 负载自身管理的 Table 的读写功能，客户端只想 Master 同步元数据，数据不经过 Master 节点，直接和 Table Server 通信。因此，BigTable 中 Master 节点的负载很低。
 
有主架构中，Master 承担的能力也会不一致，比如在下图架构中，Master 只承担 Coordinate 功能，管理元数据和 Node 节点，Client 获取 Mata Data，直接和相应的数据节点通信。
 
 
 
在下面架构中，Client 不直接和 Data Node 节点通信，而是和 Master 通信，Master 更加相关元数据将请求转发给对应的 Data Node：
 
 
 
Coordinate-Worker 架构是很多分布式数据库采用的架构，有兴趣的同学可以看看笔者之前讲解的 ????《Druid 的架构设计》
 
索引
 
数据库系统的索引，就是用来提高数据检索效率的。数据库系统的数据记录存储在磁盘中，如果没有索引，要从磁盘中检索相应的记录，就需要扫描所有的数据段，这种 O(N) 的访问效率和全磁盘的扫描自然不可能在真正的数据库系统中使用。为提高数据检索能力，数据库系统引入索引技术，为磁盘上的数据记录做一个索引结构，这些索引放在内存中，或按块存储在磁盘上（但只需要少数几次磁盘读取就可以读入内存中），这样检索一个数据先从内存索引中查找到对应的 Key 或磁盘位置，然后从磁盘中读取记录。
 
这里索引做了两个事情：
 
将大量磁盘检索变成内存检索
通过特定的数据结构可以提高内存检索的效率，改变 O(N) 这种低效率的检索
 
HASH 索引
 
 
 
HASH 即哈希表，类似 Java 的 HashMap 数据结构，Key-Value 格式。假设我们在内存内维护一个 HashMap Index，key 为数据的键，Value 是数据在磁盘的存储偏移量。
 
获取数据时，先从内存 Map 获取对应数据的磁盘 offset，然后读取磁盘的数据。
写数据时，先将数据追加写入磁盘，然后更新内存 HashMap Index。
 
Hash 索引听起来过于简单，但确实是一种可行的索引方法。Hash 索引简单高效，查询性能 O(1)，更新也高效，当时也有明显的缺点，比如：
 
需要将整个哈希表放入内存，这对于大数据量来说内存耗费将不可承受的。
只能进行精确查询。
不能实现范围查询。
 
B-Tree 索引
 
B-trees 索引始见于 1970 年，经受了长久的时间考验，时至今日，它仍然时几乎所有关系数据库中的标准索引实现，许多非关系型数据库也经常使用。
 
了解B-trees索引先从二叉搜索树开始。二叉搜索树是一种特殊的二叉树，它满足以下条件：
 
左子树小于父节点
右子树大于父节点
 
 
 
上图是一个搜索二叉树，如果我要查找 208 这个 key：
 
先从根节点开始，即 136。比较 208 > 136，下一步应该从根节点的右子树查找
398 > 208，继续搜索 398 的左子树
250 > 208，继续搜索 250 的左子树
200 < 208，继续搜索 200 的右子树。
200 的右子树并不存在，因此数据中没有 208，查找结束
 
让我们再查找 40：
 
从根节点 136 开始，136 > 40，继续搜索左子树
80 > 40，继续搜索左子树
40 = 40，节点存在，从节点中获取数据 id，然后可以更加数据 id 查找对应的数据
 
在索引结构中，树的每个Node包含一个 key 值，一个数据指针(或数据 id、磁盘 offset 等)
 
二叉搜索树的时间复杂度是 log(N)，这是一个不错的结果。
 
二叉搜索树依旧只能获取特定的值，如果我需要进行范围查找，即查找两个数之间的所有数据，就需要去遍历树中的每一个节点，去判断节点是否在此范围内，这种情况下，时间复杂度又下降到了 O(N)。因此我们需要改进上面的数据结构，现代大多数数据库都才有一种改进的二叉搜索树—— B+Tree。
 
 
 
B+Tree 在二叉搜索树的基础上添加如下特征：
 
仅仅在叶子节点存储索引信息(关联表数据的信息)
其余节点仅仅用于查找到最终的叶子节点(叶子节点包含了所有的 key)
 
在 B+Tree 中，每个 Key 会存在两个 Node，所有中间节点只用于辅助检索最终正确的叶子节点(叶子节点才包含关联数据的信息)。
 
让我们尝试从上面的 B+Tree 中搜索出[40, 100]之间的节点：
 
采用和二叉搜索树一样的方式，我们只需要搜索 40 这个节点(或搜索出最接近 40 的节点，当 40 的节点不存在时)
然后在叶子节点链表中往下追溯，知道超过 100
 
假设树中共有 N 个节点，追溯了 M 个叶子节点，那么可以得出，此次搜索的时间复杂度是：log(N) + M。相对于之前的 O(N) 的二叉搜索树有以下好处：
 
不需要读取整棵树，这样可以减少读取磁盘的次数(索引数据一般按页存储在磁盘上)
大多数情况下 M (约等于检索范围)会远小于整个数据量 N，因此这里的 O(M) 时间复杂度大多数情况下远小于 O(N)。
 
*任何事情都是双面的。*B+Tree 索引带来的检索优势，必然会有其他方面的损失。这主要体现在删除数据时。因为叶子节点类似于链表结构，删除一个节点需要从 header 开始遍历，时间复杂度是 O(N)。
 
B+Tree 索引具有比较好的检索性能，为了减少磁盘访问次数，大多数索引系统的 B+tree 都只有 3- 4 层，因此 B+Tree 索引能够承载的节点数是有限的。B+Tree 在更新节点是需要自排序和自平衡，这需要额外的性能消耗，B+Tree 的插入和删除时间复杂度是 O(log(N))。这就是为什么在使用数据库时不建议索引字段都添加索引，而是充分考虑具体情况，在需要的字段上添加索引，否则索引太多会影响表的insert\update\delete操作性能。
 
LSM
 
B+Tree 是基于页的索引引擎，B+Tree 的数据存储本身是无序的，其建立索引的思想是在内存中维护一个 key 与数据磁盘位置的对应关系，并保证这个内存数据结构有序。有一种基于文件的存储引擎，它将数据划分成文件段，并保证数据在磁盘文件段中有序，因此，这种存储引擎并不需要在内存中维护所有数据的顺序表，只需要在内存中维护一个稀疏的索引结构，每次从内存索引中搜索到的数据并不是具体到每条数据，而是一个文件段(或文件块)，然后将这些有序的数据读入内存，再按序获取具体的数据。（如何保证写入数据有序？）
 
LSM(Log-Structured Merge-Tree)，就是这样一种索引结构。LSM 的架构如所示：
 
 
 
SSTable： LSM 的磁盘文件，称作SSTable(Sorted String Table)。望文得意，LSM 存储在磁盘中的文件，数据也是按 Key 排序存储的，这样就可以解决上面讲到的数据量大了之后无法将数据全部索引到内存中的问题。如果磁盘文件也是有序的，那么内存索引可以采取”稀疏索引“（Sparse Index），可以每一段记录一个索引，将数据逻辑上分成多个block，稀疏索引只需要记录每个block的偏移量，每条数据通过遍历block实现。这样索引量将大大减小。
 
Memtable： LSM 的内存结构叫做Memtable。Memtable是一个有序结构，同样可以采用树结构，可以用跳表。LSM 写数据时，只需要写入内存中的Memtable，当Memtable到达一定量之后，会异步刷入磁盘，就是上面的SSTable。
 
Immutable Memtable： 在数据从内存Memtable刷入SSTable时，为避免读写锁导致的性能问题，LSM 会在内存中 copy 一份immutable Memtable表，顾名思义，这个数据结构不可改变，新写入的数据只会写入新的Memtable，immutable Memtable供刷盘线程读取，查询数据的请求也可以访问这个数据结构，这样如果数据在内存中，就不需要访问磁盘，可以提供数据查询的效率。
 
WAL： write ahead log，预写日志，关于 WAL，可以参考之前的文章????《你常听说的 WAL 到底是什么》。在 LSM 中，在数据刷入磁盘前，为防止异常导致数据丢失，LSM 会先将数据写入 WAL，然后写入 SSTable，系统重启时，LSM 会从 WAL 中回溯 SSTable，当写完一个 SSTable 时，LSM 会清理掉过期的 WAL 日志，防止 WAL 过量。
 
LSM 如何写入数据：
 
写入 WAL
写入 Memtable
Memtable 达到阈值时，复制 Imutable Memtable
异步刷入磁盘
 
LSM 如何删除数据： 为保证顺序写磁盘，LSM 不会去直接删除数据，而是通过写一条 delete 标识来表示数据被删除，数据只有在被 Compact 时才会被真正删除。
 
LSM 如何读取数据： LSM 读取数据将从memtable、imutable、sstable依次读取，直到读取到数据或读完所有层次的数据结构返回无数据。所以当数据不存在时，需要依次读取各层文件。LSM 可以通过引入布隆过滤器来先判断一个数据是否存在，避免无效的扫文件。
 
密集索引(dense index) 和 稀疏索引(spare index)：密集索引为每条数据对应一个索引记录，稀疏索引一般只索引数据块或文件，是跳跃式的。因此稀疏索引比密集索引更节省空间。
 
压缩
 
数据压缩对数据库系统中 I/O 性能的影响相当明显，它可以减少磁盘空间使用、降低带宽使用和提高吞吐量。数据库系统中的数据存储、索引存储、数据转换、数据备份和网络通信都会用到相应的压缩技术。当将数据库压缩引入实时数据库时。压缩算法必须提供高压缩比才能实现高数据存储，压缩算法必须足够快，才能在实时数据库中实现实时记录和查询功能。
 
压缩过程一般由两个独立的部分组成，建模和编码。建模定义输入流中不同符号的特征。模型存储有关符号在数据中出现的频率的信息，即符号概率。编码是压缩过程的第二部分，它根据模型提供的概率为不同符号创建一组代码，从而产生数据的压缩版本。将更频繁地出现的符号与较短的代码词和较长的稀有符号互换。数据的均匀性会影响大多数压缩算法的压缩比，但对压缩速度没有任何影响。因此，为了达到更好的压缩性能，压缩算法是专门为数据的每个部分设计的，因此不同的压缩算法对不同类型的，不同量级和不同组合的数据的压缩效果是不一致的。也因此大多数支持数据压缩的数据库系统都会提供多种不同的压缩算法让用户根据自身数据情况自由选择。
 
压缩算法可以分为以下两大类：
 
有损压缩：有损压缩会重构原始数据。所以读取的压缩后的数据是不完整的。这种压缩方式通常用在音频、视频等流文件的压缩中。
无损压缩：无损压缩不影响压缩数据的原始值。通常使用在文本，数字等数据的压缩中。
 
压缩应该考虑什么问题：
 
大小：压缩后的文件大小，即压缩比。当使用压缩时，本就是为了降低数据大小，所以压缩算法的压缩比是首要考虑的问题。
速度：压缩速度会影响数据的读写效率，这对实时系统来说尤为重要，速度和大小是 trade-off 的两面，必须充分考虑具体的使用场景。
**资源：**压缩节省了磁盘和宽带，但是会增加 CPU 和压缩时的内存使用。所以压缩时的资源耗损情况也需要考虑。
 
下面列举一些常见的压缩算法或方法(Gzip、Bzip2、LZMA、XZ、LZ4、LZO),并做相应的对比:
 
测试条件：
 
Intel Core i5 CPU 750 at 2.67GHz
8GB of DDR3 memory
tmpfs as ram disk
Linux kernel 3.3.2, gentoo amd64
CFLAGS: -pipe -O2 -g -floop-block -floop-interchange -fgraphite
bzip2-1.0.6-r3, xz-utils-5.0.3, gzip-1.4
 
文件压缩对比结果(原数据: 445M)：
 
 
 
压缩比对比：
 
 
 
压缩耗时对比：
 
各大数据库系统多多少少都会用到压缩技术来降低数据存储空间，来提高系统性能，以下列举一些数据库系统使用到的压缩技术：
 
Google 在 BigTable 和 MapReduce 中使用 Snappy 压缩数据和网络传输。
SQL Server 使用 XPRESS 算法压缩备份数据。
Oracle 使用自实现的 Oracle Advanced Compression 算法压缩数据。
MySQL 使用 LZ77 算法压缩 InnoDB 的表。
Kafka 同时支持 gzip 和 snappy 和 lz4 算法，并对默认的 lz4 做了特定的优化。
Druid 使用 lz4 压缩数据。
 
数值压缩：delta-of-delta
 
数值压缩经常用于压缩列式存储的数字列。前面我们讲到过，列式存储将每列的数据存储在相邻的位置。这样的存储结构利于压缩数据，下面我们讲一下在许多列式存储中使用的 Delta 数值压缩技术。
 
![delta of delta](https://magebyte.oss-cn-shenzhen.aliyuncs.com/databases/delta of delta.png)
 
如图所示，假设有 6 个原始数值（73、300、302、332、343、372）。在未压缩之前，每个数值占用 4 个字节，6 * 4 = 24 共占用 24 个字节。Delta 压缩算法不存储原始的数值，而是先确定一个数字（一般取第一个数值），后面的数值是相对于第一个数值的差值，如图第二行所示得到的数据集为（73、227、3、30、11、29）。因为最大的差值是 227，因此只需要一个 byte 就可以表示，因此之前需要使用 4 个字节存储的每个数值，现在只需要使用 1 个字节。为了保存对应的差值相关元描述信息，需要额外的 1 字节保存这些信息，上图还将数据分块存储，因此最终需要的字节数是 7 个。这样相对于原始的 24 字节节约了将近 3 倍的空间。
 
其实上图就是 Elasticsearch 底层使用 Lucence 的原理。
 
delta-of-delta 适用于数值类型数据的压缩，且对数据量大并且数据集中的数据压缩才有效果。如果数据集比较小，且比较稀疏，数据的最大差值已经和数据值可以表示的最大值相差不大，那么压缩的意思便存在。
 
读写
 
数据存储系统就是一个与磁盘和网络打交道的系统，所以数据存储系统在这方面的优化可谓精益求精，比如异步IO、缓冲批量读写、append写数据、按磁盘页读写数据，预读数据和磁盘内存映射技术等等。
 
异步
 
与异步 IO 对应的是同步 IO，即每进行一次 IO 操作，需要等待此次操作结束才能继续接下来的操作，这样在大量并发请求情况下，IO 的效率将会大大降低，磁盘 IO 和网络 IO 在并发量大的情况下采用异步 IO 可以明显提供效率。
 
Mysql 的 InnoDB 也采用 AIO 提高效率，InnoDB1.1.x 之前，AIO 的实现通过 InnoDB 存储引擎中的代码来模拟实现，从 InnoDB1.1.x 开始，提供了内核级别的 AIO 支持，称为 Native AIO。在 InnoDB 存储引擎中，read ahead 方式的读取都是通过 AIO 完成，脏页的刷新，即磁盘的写入操作则全部由 AIO 完成。
 
在 Kafka 中，Broker 的数据磁盘落地，都是采用的 Java NIO 的方式处理的，这是 Java 的异步 IO 的实现，Java NIO 可以提供数据写入的并发性能。
 
缓冲
 
缓冲技术是为了协调吞吐速度相差很大的设备之间数据传送而采用的技术。
 
 
 
在数据到达与离去速度不匹配的地方，就应该使用缓冲技术。缓冲技术好比是一个水库，如果上游来的水太多，下游来不及排走，水库就起到“缓冲”作用，先让水在水库中停一些时候，等下游能继续排水，再把水送往下游。
 
将缓冲和批量发送结合，可以提高数据在在网络和磁盘中的写入速率。在数据写入网络或磁盘时，先设置一个缓冲池，当数据达到一定的数量或缓冲时间超时时，在将数据批量发送出去，可以减少请求并发，也可以减少请求额外数据带来的带宽和磁盘消耗。
 
在 Mysql 中，Innodb 在多个地方使用缓冲来提升写入性能。比如插入缓冲，将多个插入请求合并到一个操作中，这样可以将之前的一些非顺序写入变成相对的顺序写入，以提高写入效率。另一方面也可以按磁盘物理页写入数据，这样充分利用了磁盘的写入特性。
 
在 Elastisearch 和 Kafka 的客户端中，都采用了缓冲批量写入的功能来减少写入并发情况。
 
磁盘
 
在磁盘的读写优化上，经常可以看到以下技术：
 
按磁盘页读写数据：磁盘读写的单位是页。为了减少读写数据时磁盘访问频率，数据库系统通常都按页读写数据。
预读数据：一些数据库系统认为用户访问了一部分数据，那么在它相邻的放的数据下次被访问的可能性也很大，所以会预先读取多个页的数据。
磁盘内存映射（MMP）：即盘扇区映射到进程的虚拟内存空间的过程。MMP 读写数据时跨过了页缓存，减少了数据的拷贝次数；实现了用户空间和内核空间的高效交互方式；可以缓解系统内存不足的压力。
 
参考：
 
《Designing Data-Intensive Applications》
《Database Software Market:The Long-Awaited Shake-up》
《Distributed systems for fun and profit》
《How does a relational database work》
《七周七数据库》
《Mysql 技术内幕——InnoDB 存储引擎》
《数据库系统概念》
《Dynamo: Amazon's Highly Available Key-value Store》
http://arthurchiao.art/blog/amazon-dynamo-zh/
https://zhuanlan.zhihu.com/p/35622907
https://baike.baidu.com/
https://hbase.apache.org/
https://zh.wikipedia.org/
https://clickhouse.tech/
https://druid.apache.org/
https://www.elastic.co/
 
精彩推荐
一百期Java面试题汇总SpringBoot内容聚合IntelliJ IDEA内容聚合Mybatis内容聚合

欢迎长按下图关注公众号后端技术精选

 

目录
 
数据库设计
 
1、数据库设计概述
 
 1）、数据库设计的特点
 
2）、 数据库设计方法
 
3）、 数据库设计的基本步骤 
 
4）、数据库设计过程中的各级模式
 
2、需求分析
 
1）、需求分析的任务
 
2）、需求分析的方法
 
3）、数据字典
 
3、概念结构设计
 
1）、概念模型
 
2）、E-R 模型
 
3）、概念结构设计
 

 
 
数据库设计
 
1、数据库设计概述
 
数据库设计 ，广义地讲：整个数据库应用系统的设计；狭义的说就是数据库本身的设计。设计一个好的数据库与设计一个好的数据库应用系统密不可分。
 
数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效率的运行环境。高效率的运行环境是指数据库数据的存取效率高 、数据库存储空间的利用率高 、数据库系统运行管理的效率高
 
数据库设计的一般定义：数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。 信息管理要求：在数据库中应该存储和管理哪些数据对象 ；数据操作要求：对数据对象需要进行哪些操作，如查询、增、删、改、统计等操作。
 
 1）、数据库设计的特点
 
1、数据库建设的基本规律
 
三分技术，七分管理，十二分基础数据 。技术：其次；管理 ：数据库建设项目管理，企业（即应用部门）的业务管理 ；基础数据： 数据的收集、整理、组织和不断更新。工作量大，繁琐，细致。对数据分析挖掘，改进业务管理。
 
2. 结构（数据）设计和行为（处理）设计相结合 
 
将数据库结构设计和数据处理设计密切结合。在早期的数据库应用系统开发过程中，常常把数据库设计和应用系统的设计分离开来，如图：
 
 
而传统的软件工程：重行为设计，忽视对应用中数据语义的分析和抽象。结构化设计和逐步求精的方法；早期的数据库设计：重结构设计，致力于数据模型和数据库建模方法研究，忽视了行为设计对结构设计的影响。
 
 
 
2）、 数据库设计方法
 
运用软件工程思想，按一定的设计规程用工程化方法设计数据库，其基本思想：过程迭代和逐步求精。迭代算法是用计算机解决问题的一种基本方法。它利用计算机运算速度快、适合做重复性操作的特点，让计算机对一组指令(或一定步骤)进行重复执行，在每次执行这组指令(或这些步骤)时，都从变量的原值推出它的一个新值。
 
经典方法：新奥尔良方法（比较著名）：将数据库设计分四个阶段：需求分析（分析用户要求）、概念设计（信息分析和定义）、逻辑设计（设计实现）和物理设计（物理数据库设计）；基于E-R模型的数据库设计方法（概念设计阶段广泛采用）；3NF（第三范式）的设计方法（逻辑阶段可采用的有效方法）；面向对象的数据库设计方法 ；统一建模语言（UML）方法；计算机辅助设计法（指在数据库设计的某些过程中模拟某一规范化设计的方法，并以人的知识或经验为主导，通过人机交互方式实现设计中的某些部分）；计算机辅助软件工程工具（如 SYSBASE公司的PowerDesigner、Rational公司的Rational Rose、Oracle公司的Design 2000）等。
 
 
 
3）、 数据库设计的基本步骤 
 
数据库设计分6个阶段：需求分析 、概念结构设计 、逻辑结构设计 、物理结构设计 、数据库实施 和 数据库运行和维护，如图所示：
 
 
在数据库设计过程中，需求分析和概念设计独立于任何数据库管理系统，逻辑设计和物理设计与选用的数据库管理系统密切相关。
 
数据库设计开始之前，首先必须选定参加设计的人员，包括系统分析人员、数据库设计人员、应用开发人员、数据库管理员和用户代表。系统分析人员和数据库设计人员是数据库设计的核心，自始至终参与数据库设计，其水平决定了数据库系统的质量。数据库管理员和用户代表主要参加需求分析与数据库的运行和维护（用户积极参与带来的好处：加速数据库设计，提高数据库设计的质量）。应用开发人员（包括程序员和操作员）在实施阶段参与进来，分别负责编制程序和准备软硬件环境。
 
需求分析阶段：准确了解与分析用户需求（包括数据与处理）。是整个设计过程的基础，是最困难、最耗费时间的一步。是否做得充分与准确，决定了构建数据库的速度和质量。概念结构设计阶段：是整个数据库设计的关键。通过对用户需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型。逻辑结构设计阶段：将概念结构转换为某个DBMS所支持的数据模型，并对其进行优化。物理结构设计阶段：为逻辑数据结构选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。数据库实施阶段：根据逻辑设计和物理设计的结果构建数据库，编写与调试应用程序，组织数据入库并进行试运行。数据库运行和维护阶段：经过试运行后即可投入正式运行，在运行过程中必须不断对其进行评估、调整与修改。
 
这个设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程。设计一个完善的数据库应用系统往往是上述6个阶段的不断反复。 把数据库的设计和对数据库中数据处理的设计紧密结合起来，将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计。
 
 
 
4）、数据库设计过程中的各级模式
 
和前面的一样，数据库设计的不同阶段形成数据库的各级模式，如下图：
 
 
需求分析阶段：综合各个用户的应用需求；数据库设计不同阶段形成的数据库各级模式；概念设计阶段：形成独立于机器特点，独立于各个数据库管理系统产品的概念模式（E-R图）；逻辑设计阶段：首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式，然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图（View），形成数据的外模式；物理设计阶段：根据数据库管理系统特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式。
 
 
 
2、需求分析
 
需求分析就是分析用户的需要与要求，需求分析是设计数据库的起点。需求分析的结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用。
 
1）、需求分析的任务
 
需求分析的任务通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库。
 
需求分析的重点是 “数据” 和 “处理” ，通过调查、收集与分析，获得用户对数据库的以下要求：信息要求：用户需要从数据库中获得信息的内容与性质，由用户的信息要求可以导出数据要求，即在数据库中需要存储哪些数据；处理要求：对处理功能的要求、对处理的响应时间的要求以及对处理方式的要求(批处理 / 联机处理)；安全性与完整性要求。
 
 
 
2）、需求分析的方法
 
调查清楚用户的实际需求并进行初步分析，与用户达成共识，然后进一步分析与表达这些需求。
 
需求调查的内容如下：1）、调查组织机构情况：组织部门的组成情况，各部门的职责等；2）、调查各部门的业务活动情况：各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么 等；3）、在熟悉业务活动的基础上，协助用户明确对新系统的各种要求：信息要求，处理要求，安全性与完整性要求 ；4）、确定新系统的边界：对前面调查的结果进行初步分析，确定哪些功能由计算机完成或将来准备让计算机完成，确定哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。
 
在调查过程中，可以根据不同的问题和条件使用不同的调查方法，常用的调查方法有：跟班作业：通过亲身参加业务工作了解业务活动的情况，能比较准确地理解用户的需求，但比较耗时；开调查会：通过与用户座谈来了解业务活动情况及用户需求；请专人介绍 ；询问：对某些调查中的问题，可以找专人询问；设计调查表请用户填写：如果调查表设计合理，则很有效，且易于为用户接受；查阅记录：查阅与原系统有关的数据记录 。
 
做需求调查时，往往需要同时采用多种方法，无论使用何种调查方法，都必须有用户的积极参与和配合。
 
调查了解用户需求后，还需要进一步分析和表达用户的需求。在众多分析方法中，结构化分析(SA) 方法是一种简单实用的方法。SA 方法从最上层的系统组织机构入手，采用自顶向下、逐层分解的方式分析系统：1、把任何一个系统都抽象为如图方式：
 
 
反映系统概貌，要反映更详细的内容，可将处理功能分解为若干子功能，每个子功能还可以继续分解，直到把系统工作过程表示清楚为止。2、 分解处理功能和数据，其中包括 1）、分解处理功能：将处理功能的具体内容分解为若干子功能，再将每个子功能继续分解，直到把系统的工作过程表达清楚为止；2）分解数据：在处理功能逐步分解的同时，其所用的数据也逐级分解，形成若干层次的数据流图。（数据流图表达了数据和处理过程的关系）；3）、表达方法：数据用数据字典来描述，主要描述数据在系统中流动和处理的工具，表达了数据与处理的关系；处理过程用判定表或判定树来描述（判定树本质上同判定表是一样的，当用户不易接受判定表这种描述方式时，可用判定树的形式，判定树是一种图形表示，更易被用户理解）。下面举的例子（左为判定表，右为判定树）：
 
        
 
接着便是 3、将分析结果再次提交给用户，征得用户的认可。
 
  
 
 
 
3）、数据字典
 
数据字典是关于数据库中数据描述的集合，即元数据，不是数据本身。数据字典在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善，是进行详细的数据收集和数据分析所获得的主要结果。
 
数据字典的内容包括：数据项、数据结构、数据流、数据存储及处理过程。数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构。数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。
 
1、数据项：
 
数据项是不可再分的数据单位。对数据项的描述通常包括以下内容：数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系｝，其中取值范围、与其他数据项的逻辑关系定义了数据的完整性约束条件，是设计数据检验功能的依据。 可以用关系规范化理论为指导，用数据依赖的概念分析和表示数据项之间的联系。
 
2、数据结构：
 
数据结构反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。对数据结构的描述通常包括一下内容：数据结构描述 ＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝ 
 
3、数据流：
 
数据流是数据结构在系统内传输的路径对数据流的描述通常包括以下内容：数据流描述＝｛数据流名，说明，数据流来源，数据流去向，组成:｛数据结构｝，平均流量，高峰期流量｝。其中数据流来源是说明该数据流来自哪个过程；数据流去向是说明该数据流将到哪个过程去；平均流量是指在单位时间（每天、每周、每月等）里的传输次数；高峰期流量则是指在高峰时期的数据流量。
 
4、数据存储：
 
数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。它可以是手工文档或手工凭单，也可以是计算机文档。对数据存储的描述通常包括以下内容：数据存储描述＝｛数据存储名，说明，编号，流入的数据流 ，流出的数据流 ，组成:｛数据结构｝，数据量，存取频度，存取方式｝。其中流入的数据流：指出数据来源；流出的数据流：指出数据去向；数据量：每次存取多少数据，每天（或每小时、每周等）存取几次等信息；存取频度：每小时、每天或每周存取次数及每次存取的数据量等信息；存取方法：批处理/联机处理；检索/更新；顺序检索/随机检索。 
 
5、处理过程：
 
处理过程的具体处理逻辑一般用判定表或判定树来描述。数据字典中只需要描述处理过程的说明性信息。通常包括以下内容：处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝，处理:｛简要说明｝｝。其中 简要说明 主要说明该处理过程的功能及处理要求；功能是指该处理过程用来做什么（而不是怎么做）；处理要求指处理频度要求（如单位时间里处理多少事务，多少数据量）；响应时间要求等。这些处理要求是后面物理设计的输入及性能评价的标准。
 
  
 
 
 
3、概念结构设计
 
1）、概念模型
 
将需求分析得到的用户需求抽象为信息结构  （即概念模型）的过程就是概念结构设计 。概念模型的特点：1）、能真实、充分地反映现实世界，是现实世界的一个真实模型。2）、易于理解，从而可以用它和不熟悉计算机的用户交换意见。3）、易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。4）、易于向关系、网状、层次等各种数据模型转换。 
 
概念模型是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。描述概念模型的有力工具是 E-R 模型。
 
 
 
2）、E-R 模型
 
前面已简单提到过 E-R 模型的一些概念，包括实体、属性、实体之间的联系等，初步了解了实体之间的联系。下面仍先对实体之间的联系作进一步介绍，然后讲解 E-R 图。
 
实体之间的联系：实体内部的联系通常是指组成实体的各属性之间的联系，实体之间的联系通常是指不同实体型的实体集之间的联系。 
 
1）、两个实体型之间的联系：一对一联系（1∶1）、一对多联系（1∶n）、多对多联系（m∶n）。2）、一般地，两个以上的实体型之间也存在着一对一、一对多、多对多联系。 例如：对于课程、教师与参考书3个实体型，如果一门课程可以有若干个教师讲授，使用若干本参考书，而每一个教师只讲授一门课程，每一本参考书只供一门课程使用，则课程与教师、参考书之间的联系是一对多的。3）、同一个实体集内的各实体之间也可以存在一对一、一对多、多对多的联系。 例如：职工实体型内部具有领导与被领导的联系，即某一职工（干部）“领导”若干名职工，而一个职工仅被另外一个职工直接领导，因此这是一对多的联系。
 
 
 
3）、概念结构设计
 
设计概念结构的四类方法：1）、自顶向下：首先定义全局概念结构的 框架，然后逐步细化。2）、自底向上：首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构。3）、逐步扩张：首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构。4）、混合策略：将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。
 
常用策略：自顶向下地进行需求分析，自底向上地设计概念结构。自底向上设计概念结构的步骤：第1步，抽象数据并设计局部视图；第2步，集成局部视图，得到全局概念结构。
 
1、实体与属性的划分
 
数据抽象的用途：对需求分析阶段收集到的数据进行分类、组织（聚集）、概括，形成实体、实体的属性（标识实体的码）、确定实体之间的联系类型(1:1，1:n，m:n) 。实体：现实世界中一组具有某些共同特性和行为的对象就可以抽象为一个实体。对象和实体之间是 “is member of” 的关系。例：在学校环境中，可把张三、李四等对象抽象为学生实体。属性：对象类型的组成成分可以抽象为实体的属性。组成成分与对象类型之间是 “is part of” 的关系。例：学号、姓名、专业、年级等可以抽象为学生实体的属性，其中学号为标识学生实体的码。
 
为了简化E-R图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待。 有以下两条准则：1）、作为属性，不能再具有需要描述的性质，属性必须是不可分的数据项，不能包含其他属性。2）、属性不能与其他实体具有联系，即 E-R 图中所表示的联系是实体之间的联系。符合上述两条特性的事物一般作为属性对待。
 
例：职工是一个实体，职工号、姓名、年龄是职工的属性。  职称如果没有与工资、福利挂钩，根据准则 1可以作为职工实体的属性。  如果不同的职称有不同的工资、住房标准和不同的附加福利，则职称作为一个实体更恰当。例：在医院中，一个病人只能住在一个病房，病房号可以作为病人实体的一个属性。如果病房还要与医生实体发生联系，即一个医生负责几个病房的病人的医疗工作，则根据准则2病房应作为一个实体。例：如果一种货物只存放在一个仓库，那么就可以把存放货物的仓库的仓库号作为描述货物存放地点的属性。如果一种货物可以存放在多个仓库中，或者仓库本身又用面积作为属性，或者仓库与职工发生管理上的联系，那么就应把仓库作为一个实体。
 
2、E-R 图的集成
 
在开发一个大型信息系统时，经常采用的方法是自顶向下进行需求分析，然后自底向上设计概念结构。即首先设计各个子系统的E-R图，然后把他们集成起来，得到全局的 E-R 图。
 
设计分 E-R 图的步骤：1）、以数据字典为出发点定义E-R图。每个局部应用都对应了一组数据流图，局部应用涉及的数据都已经收集在数据字典中了。数据字典中的“数据结构”、“数据流”和“数据存储”等已是若干属性的有意义的聚合。现在就是要将这些数据从数据字典中抽取出来，参照数据流图，标定局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型（1:1、1:n、m:n）。2）、按上面给出的准则进行必要的调整。
 
集成分两步走：第一步：合并，消除冲突，生成初步E-R图。各子系统的E-R图之间的冲突主要有三类：1）、属性冲突：属性域，取值单位；2）、命名冲突：同名异义、异名同义；3）、结构冲突：同一对象被当成实体还是属性，同一实体在不同子系统的属性个数或者属性顺序不同，实体间的联系不同。第二步：修改和重构，消除冗余，生成基本  E-R图。数据的冗余：可由基本数据导出的数据；实体间冗余的联系：可由其他联系导出的联系。需要注意：并不是所有的冗余数据和冗余联系都必须消除，有时为了效率，需要以冗余信息作为代价。在设计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。
 
消除冗余的方法：以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。利用规范化理论，函数依赖的概念提供了消除冗余联系的形式化工具。如果是为了提高效率，人为地保留了一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件。一种更好的方法是把冗余数据定义在视图中。