数据库系统由什么组成;数据库是什么 收藏 0

数据库系统原理：数据库系统的组成

数据库系统是一个人机系统。学习数据库系统，要先学习数据库系统的组成。

一、数据库系统的组成

数据库系统一般由数据库、硬件、软件和人员组成。

（1）数据库：物理数据库，描述数据库。

物理数据库：应用数据的集合，是DB的主体。

描述数据库：关于各级数据结构的描述，由数据字典（DD）系统管理。

简单数据字典示例

如图所示的数据字典中记录了系统中所有数据项的信息，而数据项是数据库中最基本的单位。

除了物理数据库和描述数据库外，还有用于故障恢复的日志系统数据库、用于查询优化的索引以及一些统计数据库等。

（2）硬件

数据库系统中的硬件包括CPU、内存、外存、I/O设备、数据通道等设备。

（3）软件

数据库管理系统（DBMS）、操作系统（OS）、各种与数据库接口的高级语言及编译系统、应用开发工具、数据库应用系统等。

数据库应用系统是最外层的系统，与特定的应用有关；最内层的是操作系统，以来支持数据库以及其他的软件的运行；高级语言及编译系统、应用开发工具是用来是用来开发数据库系统的；数据库管理系统是整个数据库系统的核心。

（4）人员

数据库管理员（DBA），系统分析员，数据库设计人员，应用程序员，最终用户。

二、各类使用数据库系统人员的职责

（1）数据库管理员（DBA）（专门用来监督、管理、控制数据库系统运行的最重要人员）的职责为：

1.模式定义，决定数据库中信息内容和结构

2. 内模式定义，决定数据库的存储结构和存取策略

3.根据要求修改数据库的模式和内模式

4.对数据库访问的权限，定义数据的安全性

5.完整性约束条件的说明

6.监控数据库的使用和运行（处理出现的问题）

7.数据库的改进和重组重构（改进数据库设计 ）

（2）系统分析员的职责为：

负责应用系统的需求分析和规范说明，确定系统的硬件软件配置，参与数据库系统的概要设计。

（3）数据库设计人员的职责为：

负责数据库中数据的确定，各级模式的设计，参加用户需求调查和系统分析，进行数据库设计。

（4）应用程序员的职责为：

负责设计和编写应用系统的程序模块、调试和安装。

（5）用户

最终用户通过应用系统的用户接口使用数据库。常用的接口方式有浏览菜单驱动、表格操作、图形显示等，以简明直观的表示方式显示数据。

偶然用户：企业中高级管理人员，不常访问数据库，但访问时往往需要不同的数据库信息。

简单用户：多数用户是简单用户，工作是通过应用程序的友好界面查询和修改数据库中的数据。

复杂用户：工程师、科学家等人员，熟悉DBMS的各种功能，可直接用DML语言访问数据库，用API编写自己程序。

数据库系统不仅是一个计算机系统，也是一个人-机系统，人的作用尤为重要。

一文告诉你，什么是数据库系统

各位小伙伴们，最近忙于自己的事情，难得闲下心来想在这里记录些什么，在自己做网络知识相关笔记的时候，才想起自己的知识库里存有之前学习的数据库相关的知识，所幸的是自己的勤快做的笔记能够存留下来，于是自己想记录些数据库相关的知识，有意无意，或者面试准备，就可以随便瞄一眼，好了，话不多说，来正事儿，咱们先尝点甜头，回温回温下数据库这么回事儿。

数据库，从事it行业的人或者沾边的人一定不陌生。本质上来说，它是信息的统筹，人们的日常生活，身边事迹，所接触的都是可以被记录的，而且可以存储很长的时间，它的作用可想而知。如果，你是一名IT从业人员，对于数据库，更是敏感的，那么，接来我将会更新几期数据库相关知识。

姊妹篇系列

近期将会更新相关数据库方面的系列，主要围绕数据库相关的概述、数据库建模、关系模型和关系运算、数据库语言SQL、查询优化并发控制，数据库设计以及关系数据库设计理论等篇章。虽然下的都是基础功夫，但是掌握基础，学习其他东西往往能够事半功倍，切不可急功近利。如果你也有兴趣，或者建议，欢迎交流……

数据库的发展历程

1.早期的人工管理阶段：主要多运用于科学计算，一个程序只对应一组数据；只在使用的时把程序和对应的数据装入，完成计算了就会退出，没有长期保存的必要。也没有专门对数据管理的软件；数据只面向于应用的使用。

2.文件系统阶段：发展到这一阶段，数据可以保存在磁盘上，并支持长期保存，方便用户反复对文件进行查询、修改、插入和删除等功能；应用程序和数据逐渐开始独立，数据结构的概念也不一定反映在程序上。但是基本数据处于一个文件对应于一个程序；即使使用了相同的文件但还得建立各自的文件，不能对数据项之间进行共享；造成数据冗余大，空间浪费。

3.数据库系统阶段：目前这一阶段，很好的解决了以往的缺陷，有了结构化；可共享；且独立，分为三层：用户数据的逻辑结构、整体数据的逻辑结构和数据的物理结构；数据存储的粒度可以细化到一个数据项。

▲图/ 建立的思维导图

数据库的基本术语

对于数据、数据模型、数据库、数据库管理系统、数据库系统定义如下：

关系数据库系统：关系数据库，我相信你一定不陌生，在面对复杂的庞大的数据体系，它们之间的关联关系一定是环环相扣的。在术语上，我们所说的关系，其实就是一张表。表的各列以属性开始，属性是列的入口。

关系模型和关系数据库系统：数据以“关系”的形式，也就是二维表的形式来表示，其数据模型就是关系模型。以关系模型为基础的数据库系统也就是关系数据库系统，是当前的数据库系统主流。

数据库的体系结构

数据库的体系结构,分为三层模式结构和两层映像功能。其中，三层模式结构有：

1.外模式：外模式又称为用户模式，是数据库用户和数据库系统的接口，是数据库用户的视图。一个数据库有多个外模式。一个应用程序只能使用一个外模式，一个外模式可为多个应用程序所使用。

2.模式：细分为概念模式和逻辑模式，所有数据库的公共数据视图，是数据库中全部数据的落级结构和特征的描述。一个数据库只有一个模式。概念模式可用实体-联系模型来描述，逻辑模式以某种数据模型为基础，综合考虑所有用户的需求，并将其形成全局逻辑结构。

3.内模式：内模式又称为存储模式，是数据库物理结构和存储方式的描述，是数据在数据库内部的表示方式。一个数据库只有一个内模式，内部模式描述记录的存储方式、索引的组织方式、数据是否压缩、是否假面等。数据库模式是数据库的核心与关键，外模式通常是模式的子集。

两层映像功能：分为外模式/模式映像和模式/内模式映像，所谓映像就是一种对应规则，说明映像双方如何交换。

1.外模式/模式映像：通过外模式与模式之间映像把描述局部逻辑结构的外模式与描述全局逻辑结构的模式连起来。

2.模式/内模式映像：通过模式与内模式之间的映像把描述全局逻辑的模式与描述物理结构的内模式联系起来。

▲图/ 数据库结构的重要内部结构

DBMS的体系结构

DBMS的组成，分为查询，更新，模式更新。所谓的数据库模式，就是指数据的逻辑结构。模式更新一般也是由数据库管理员进行操作。

查询处理程序，一个重要的任务就是优化查询，给结果输出给出最优解。

事务，即是数据库的基本工作单元。事务具有ACID特性，即原子性、一致性、隔离性和持久性。事务的管理程序的作用就是保证多个事务并发执行。

作者：桑小榆呀链接：https://juejin.cn/post/7174767747581083685

数据库:什么是数据库, 数据库管理系统, 数据库系统, 数据库管理员?

数据库 : 数据库(DataBase 简称 DB)就是信息的集合或者说数据库是由数据库管理系统管理的数据的集合。

数据库管理系统 : 数据库管理系统(Database Management System 简称 DBMS)是一种操纵和管理数据库的大型软件，通常用于建立、使用和维护数据库。

数据库系统 : 数据库系统(Data Base System，简称 DBS)通常由软件、数据库和数据管理员(DBA)组成。

数据库管理员 : 数据库管理员(Database Administrator, 简称 DBA)负责全面管理和控制数据库系统。

数据库系统基本构成如下图所示：

元组 ： 元组（tuple）是关系数据库中的基本概念，关系是一张表，表中的每行（即数据库中的每条记录）就是一个元组，每列就是一个属性。 在二维表里，元组也称为行。

码 ：码就是能唯一标识实体的属性，对应表中的列。

候选码 ： 若关系中的某一属性或属性组的值能唯一的标识一个元组，而其任何、子集都不能再标识，则称该属性组为候选码。例如：在学生实体中，“学号”是能唯一的区分学生实体的，同时又假设“姓名”、“班级”的属性组合足以区分学生实体，那么{学号}和{姓名，班级}都是候选码。

主码 : 主码也叫主键。主码是从候选码中选出来的。 一个实体集中只能有一个主码，但可以有多个候选码。

外码 : 外码也叫外键。如果一个关系中的一个属性是另外一个关系中的主码则这个属性为外码。

主属性 ： 候选码中出现过的属性称为主属性。比如关系 工人（工号，身份证号，姓名，性别，部门）. 显然工号和身份证号都能够唯一标示这个关系，所以都是候选码。工号、身份证号这两个属性就是主属性。如果主码是一个属性组，那么属性组中的属性都是主属性。

非主属性： 不包含在任何一个候选码中的属性称为非主属性。比如在关系——学生（学号，姓名，年龄，性别，班级）中，主码是“学号”，那么其他的“姓名”、“年龄”、“性别”、“班级”就都可以称为非主属性。

主键(主码) ：主键用于唯一标识一个元组，不能有重复，不允许为空。一个表只能有一个主键。

外键(外码) ：外键用来和其他表建立联系用，外键是另一表的主键，外键是可以有重复的，可以是空值。一个表可以有多个外键。

对于外键和级联，阿里巴巴开发手册这样说到：

【强制】不得使用外键与级联，一切外键概念必须在应用层解决。

说明: 以学生和成绩的关系为例，学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群; 级联更新是强阻塞，存在数据库更新风暴的风 险; 外键影响数据库的插入速度

为什么不要用外键呢？大部分人可能会这样回答：

增加了复杂性： a. 每次做DELETE 或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦, 测试数据极为不方便; b. 外键的主从关系是定的，假如那天需求有变化，数据库中的这个字段根本不需要和其他表有关联的话就会增加很多麻烦。

增加了额外工作： 数据库需要增加维护外键的工作，比如当我们做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，保证数据的的一致性和正确性，这样会不得不消耗资源；（个人觉得这个不是不用外键的原因，因为即使你不使用外键，你在应用层面也还是要保证的。所以，我觉得这个影响可以忽略不计。）

对分库分表不友好 ：因为分库分表下外键是无法生效的。

我个人觉得上面这种回答不是特别的全面，只是说了外键存在的一个常见的问题。实际上，我们知道外键也是有很多好处的，比如：

1. 保证了数据库数据的一致性和完整性；
2. 级联操作方便，减轻了程序代码量；
3. ……

所以说，不要一股脑的就抛弃了外键这个概念，既然它存在就有它存在的道理，如果系统不涉及分库分表，并发量不是很高的情况还是可以考虑使用外键的。

我们做一个项目的时候一定要试着画 ER 图来捋清数据库设计，这个也是面试官问你项目的时候经常会被问道的。

E-R 图 也称实体-联系图(Entity Relationship Diagram)，提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。 它是描述现实世界关系概念模型的有效方法。 是表示概念关系模型的一种方式。

下图是一个学生选课的 ER 图，每个学生可以选若干门课程，同一门课程也可以被若干人选择，所以它们之间的关系是多对多（M: N）。另外，还有其他两种关系是：1 对 1（1:1）、1 对多（1: N）。

我们试着将上面的 ER 图转换成数据库实际的关系模型(实际设计中，我们通常会将任课教师也作为一个实体来处理)：

1NF(第一范式)

属性（对应于表中的字段）不能再被分割，也就是这个字段只能是一个值，不能再分为多个其他的字段了。1NF 是所有关系型数据库的最基本要求 ，也就是说关系型数据库中创建的表一定满足第一范式。

2NF(第二范式)

2NF 在 1NF 的基础之上，消除了非主属性对于码的部分函数依赖。如下图所示，展示了第一范式到第二范式的过渡。第二范式在第一范式的基础上增加了一个列，这个列称为主键，非主属性都依赖于主键。

一些重要的概念：

• 函数依赖（functional dependency） ：若在一张表中，在属性（或属性组）X 的值确定的情况下，必定能确定属性 Y 的值，那么就可以说 Y 函数依赖于 X，写作 X → Y。
• 部分函数依赖（partial functional dependency） ：如果 X→Y，并且存在 X 的一个真子集 X0，使得 X0→Y，则称 Y 对 X 部分函数依赖。比如学生基本信息表 R 中（学号，身份证号，姓名）当然学号属性取值是唯一的，在 R 关系中，（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；所以姓名部分函数依赖与（学号，身份证号）；
• 完全函数依赖(Full functional dependency) ：在一个关系中，若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。比如学生基本信息表 R（学号，班级，姓名）假设不同的班级学号有相同的，班级内学号不能相同，在 R 关系中，（学号，班级）->（姓名），但是（学号）->(姓名)不成立，（班级）->(姓名)不成立，所以姓名完全函数依赖与（学号，班级）；
• 传递函数依赖 ： 在关系模式 R(U)中，设 X，Y，Z 是 U 的不同的属性子集，如果 X 确定 Y、Y 确定 Z，且有 X 不包含 Y，Y 不确定 X，（X∪Y）∩Z=空集合，则称 Z 传递函数依赖(transitive functional dependency) 于 X。传递函数依赖会导致数据冗余和异常。传递函数依赖的 Y 和 Z 子集往往同属于某一个事物，因此可将其合并放到一个表中。比如在关系 R(学号 , 姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖。。

3NF(第三范式)

3NF 在 2NF 的基础之上，消除了非主属性对于码的传递函数依赖 。符合 3NF 要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。比如在关系 R(学号 , 姓名, 系名，系主任)中，学号 → 系名，系名 → 系主任，所以存在非主属性系主任对于学号的传递函数依赖，所以该表的设计，不符合 3NF 的要求。

总结

• 1NF：属性不可再分。
• 2NF：1NF 的基础之上，消除了非主属性对于码的部分函数依赖。
• 3NF：3NF 在 2NF 的基础之上，消除了非主属性对于码的传递函数依赖 。

我们可以把存储过程看成是一些 SQL 语句的集合，中间加了点逻辑控制语句。存储过程在业务比较复杂的时候是非常实用的，比如很多时候我们完成一个操作可能需要写一大串 SQL 语句，这时候我们就可以写有一个存储过程，这样也方便了我们下一次的调用。存储过程一旦调试完成通过后就能稳定运行，另外，使用存储过程比单纯 SQL 语句执行要快，因为存储过程是预编译过的。

存储过程在互联网公司应用不多，因为存储过程难以调试和扩展，而且没有移植性，还会消耗数据库资源。

阿里巴巴 Java 开发手册里要求禁止使用存储过程。

• drop(丢弃数据): drop table 表名 ，直接将表都删除掉，在删除表的时候使用。
• truncate (清空数据) : truncate table 表名 ，只删除表中的数据，再插入数据的时候自增长 id 又从 1 开始，在清空表中数据的时候使用。
• delete（删除数据） : delete from 表名 where 列名=值，删除某一列的数据，如果不加 where 子句和truncate table 表名作用类似。

truncate 和不带 where 子句的 delete、以及 drop 都会删除表内的数据，但是 truncate 和 delete 只删除数据不删除表的结构(定义)，执行 drop 语句，此表的结构也会删除，也就是执行 drop 之后对应的表不复存在。

truncate 和 drop 属于 DDL(数据定义语言)语句，操作立即生效，原数据不放到 rollback segment 中，不能回滚，操作不触发 trigger。而 delete 语句是 DML (数据库操作语言)语句，这个操作会放到 rollback segement 中，事务提交之后才生效。

DML 语句和 DDL 语句区别：

• DML 是数据库操作语言（Data Manipulation Language）的缩写，是指对数据库中表记录的操作，主要包括表记录的插入（insert）、更新（update）、删除（delete）和查询（select），是开发人员日常使用最频繁的操作。
• DDL （Data Definition Language）是数据定义语言的缩写，简单来说，就是对数据库内部的对象进行创建、删除、修改的操作语言。它和 DML 语言的最大区别是 DML 只是对表内部数据的操作，而不涉及到表的定义、结构的修改，更不会涉及到其他对象。DDL 语句更多的被数据库管理员（DBA）所使用，一般的开发人员很少使用。

一般来说:drop>truncate>delete（这个我没有设计测试过）。

1. 需求分析 : 分析用户的需求，包括数据、功能和性能需求。
2. 概念结构设计 : 主要采用 E-R 模型进行设计，包括画 E-R 图。
3. 逻辑结构设计 : 通过将 E-R 图转换成表，实现从 E-R 模型到关系模型的转换。
4. 物理结构设计 : 主要是为所设计的数据库选择合适的存储结构和存取路径。
5. 数据库实施 : 包括编程、测试和试运行
6. 数据库的运行和维护 : 系统的运行与数据库的日常维护。

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com