☰
数据库系统概论绪论:分清数据、数据库、DBMS与DBS,理解数据管理演进
2026/10/2 4:55:35 网站建设 项目流程

简介:数据库系统概论是计算机专业的核心基础课程,这份课件即江胜老师所授第一章绪论的完整PPT,适合高校相关专业学生课前预习、课后复习及备考使用。章节系统讲解了数据、数据库、数据库管理系统与数据库系统四个层次概念,涵盖数据模型、数据库系统结构、访问过程与系统特点等核心内容,并以货物进出库为例帮助理解数据库技术在实际管理场景中的具体应用,同时梳理了人工管理、文件系统、数据库系统三个阶段的数据管理技术演进。课件依据萨师煊、王珊经典教材体系编排,并推荐Ullman等拓展阅读书目,可作为课程学习的有效补充。资源共1个文件,为PPT格式,压缩包约559KB,文件体量紧凑,方便快速下载浏览。已有244人学习使用,适合用作第一章知识点梳理与复习提纲。

1. 数据库系统概论第一章绪论:一份帮你打通概念关的课堂课件

很多学校把数据库系统概论排在大二下或大三上,第一节课老师用两三个学时把绪论过完,学生普遍的感受是:定义都记住了,但“数据库到底比 Excel 强在哪”说不清楚。江胜老师的这份 PPT,是对应萨师煊、王珊《数据库系统概论》第四版第一章的课堂课件,它解决的是一个非常具体的问题:让零基础的学生在第一次课就把数据、数据库、DBMS、DBS 这四个被混着用的名词彻底分清楚,并理解数据库技术为什么能在文件系统之后成为主流。适合三类人:正在跟着教材上课的学生、给这门课备课的青年教师、想系统补数据库理论的自学者。这份 PDF 文字量不算大,概念密度却很高,配合教材 1.1 到 1.6 节阅读,能把绪论这一章吃透。

2. 先把四个名词钉死:数据、数据库、DBMS 与 DBS 的边界在哪

2.1 数据不等于数字:那条教员记录是最好的教材

PPT 里有一行非常经典的示例数据:(0005794, 601, 周济, 1, 1946.08.26, 01)。表面看是一串数字和文字的混合,但对应到现实世界,它是校办公室的一份教员档案:0005794 是工号,601 是部门编号,周济是姓名,1 是性别编码,1946.08.26 是出生日期,01 是民族编码。

教材在这里想强调的是:数据(Data)是对现实世界中客观事物的符号表示,可以是数值数据,也可以是非数值数据,比如声音、图像、结构化的记录。计算机里能输入、能处理的符号序列都算数据。但关键的一句在后头——数据与其语义不可分。单独看“0005794”没有任何意义,只有放到“工号”这个属性下它才具备身份。我给学生讲这里时会做一个现场演示:把这条记录打乱顺序,变成 (601, 周济, 0005794, 01, 1946.08.26, 1),数据一个没少,但对应关系全乱了,数据库里绝不能出现这种“语义错位”。所以学这一小节的重点不是背定义,而是建立“数据背后永远挂着一个现实世界含义”的意识。

提示:后续学 E-R 模型时,实体、属性、联系本质上就是从“符号”倒推“语义”的过程,这块地基打不牢,第三章画图会翻车。

2.2 数据库:比“仓库”多出来的四个限定词

教材给数据库(Database)的定义是“长期储存在计算机内的、有组织的、可共享的数据集合”。很多人只记住了“数据集合”,把“仓库”当比喻,却忽略了三个限定词各有分量。

长期储存在计算机内,强调的是“持久化”,数据不是程序运行完就消失的临时变量,而是要落盘、能跨会话读取。有组织,指的是数据按一定的数据模型组织、描述和存储,不是把 Excel 表堆进一个文件夹就叫数据库;同一份数据要能被不同应用以不同视角读取,背后得有统一的组织和约束。可共享,意味着数据面向多用户、多应用,而不是某个程序的私有财产。

定义之后教材还列了一串特性:较小的冗余度、具有一定结构、较高的数据独立性、可共享、易扩展、安全性。我一般会让学生把“较小的冗余度”和“可共享”放在一起理解——正因为共享了,同一数据不需要在每个应用里各存一份,冗余自然降下来;而“易扩展”指的是数据库结构能平滑地增加数据类型和应用,不至于牵一发动全身。这些特性不是背的,是后续每章都会反复回来兑现的验收标准。

2.3 DBMS:夹在操作系统和业务之间的那个“系统软件”

数据库管理系统(DBMS)是一个系统软件,位于用户与操作系统之间,作用是科学地组织和存储数据、高效地获取和维护数据。它是数据库系统的核心组件,也是很多人最容易跟“数据库”本身搞混的角色。

PPT 把 DBMS 的功能归纳成四块:数据定义功能对应 DDL,典型语句是 CREATE;数据操纵功能对应 DML,典型语句是 SELECT、INSERT、UPDATE、DELETE;数据控制功能对应 DCL,典型语句是 GRANT、REVOKE;再加上数据库的建立和维护功能与运行管理。这四块在绪论里只列名称,到第三章学 SQL 时会逐一展开。

现代语境下,MySQL、PostgreSQL、SQL Server 都是 DBMS 的产品实例。我常用一句大白话区分:数据库是“装数据的仓库”,DBMS 是“管理仓库的软件系统”,你装了 MySQL,得到的不是一个数据库,而是一套能创建数据库、读写数据、控制权限的软件环境。

2.4 DBS:把六类角色凑齐才算一个完整的系统

数据库系统(DBS)是计算机系统引入数据库后的整体系统。PPT 的图 1-1 画得很清楚,DBS 的组成包括:操作系统、DBMS(及开发工具)、数据库、应用系统、数据库管理员(DBA)、用户。

DBA(数据库管理员)这个角色值得单独强调。在 MySQL 单机开发场景里,开发者往往兼任 DBA,导致很多人忽略数据库系统里还有专人负责数据内容与结构设计、存储结构与访问策略、安全性完整性约束、日常监控与恢复。在实际企业环境中,DBA 是数据库系统的专职“运维大脑”,第七、八章讲的恢复与并发控制,最终都要落到 DBA 的日常动作上。

用户也不是铁板一块:应用程序员写应用系统与数据库交互,最终用户只操作界面不接触 SQL。理解 DBS 的组成边界,对后面学数据库设计、数据库安全都很有帮助,因为很多权限问题的根源就是“角色没分清”。

概念定义一句话理解
Data现实世界客观事物的符号表示符号本身,如数字、文字、图像
Database长期、有组织、可共享的数据集合装数据的“仓库”
DBMS位于用户与操作系统之间的系统软件管仓库的软件
DBS引入数据库后的整个计算机系统数据库 + 软件 + 硬件 + 人

3. 数据管理的三阶段演进:从人工管理到数据库系统的关键拐点

3.1 人工管理阶段:没有操作系统,数据用完就走

50 年代中期以前,计算机主要用于科学计算,数据量小、结构简单,典型任务是高阶方程、曲线拟合。当时的外存是磁带、卡片、纸带,没有磁盘这种直接存取设备,数据处理方式是批处理,谈不上实时交互。

更要命的是,那个年代没有操作系统,也没有任何数据管理软件。用户用机器指令编码,通过纸带机输入程序和数据,程序运行完,用户取走纸带和运算结果,再让下一个人上机。PPT 里总结的四个特点,放到今天看全是“缺陷”:数据不保存(用完就撤走)、应用程序完全负责数据管理(存储结构、存取方法、输入输出全靠程序自己管)、数据完全面向特定应用(不同程序之间的数据冗余巨大)、程序与数据没有独立性(存储结构一改,程序中存取数据的子程序就得跟着改)。

但评价一个历史阶段要放在当时的硬件条件下看。没有磁盘,数据就没法长期低成本保存;没有操作系统,硬件资源只能由用户自己管理。人工管理的“落后”,是硬件受限下的必然。学这段的意义在于建立一条演进逻辑:数据管理方式的每一次变化,都是被“存储硬件 + 软件能力 + 应用需求”三个因素推着走的。

3.2 文件系统阶段:解决了“保存”,但没解决“共享与冗余”

50 年代后期到 60 年代中期,计算机从科学计算扩展到管理领域,外存出现了磁盘、磁鼓等直接存取设备(DASD),不需要顺序存取,直接通过地址访问记录。与此同时,出现了专门管理数据的软件——文件系统,它负责文件存储空间管理、目录管理、文件读写管理、文件保护,并向用户提供操作接口。

文件系统阶段的技术功劳值得肯定:数据可以长期保存在磁盘上,用户能按文件名访问,不用再自己在脑内编排物理块位置。但两个致命问题没有解决。

第一个是共享性差。文件仍然面向特定应用,一个文件对应一个或几个程序,不同文件之间缺乏联系。举个例子:人事部门有 employee 文件,财务部门有 salary 文件,员工的部门信息两边各存一份,员工调岗时只更新了人事文件,财务文件里的老部门没同步,月底工资条上的部门就错了。这就是典型的数据冗余带来的数据不一致。

第二个是独立性差。文件的逻辑结构和物理结构一旦改变,使用该文件的应用程序就要跟着改。用户存取数据的子程序与文件结构绑定得过于紧密,程序和数据做不到“各自安好”。所以文件系统阶段的核心矛盾可以概括为:有数据管理软件了,但数据依然是“面向应用”而不是“面向系统”的。

3.3 数据库系统阶段:结构化、高共享、高独立性

60 年代后期开始,数据库管理系统正式登场。这一阶段的管理方式与文件系统的本质区别,教材画的是数据结构化——数据不再是面向单个应用,而是面向整个系统,以数据模型为核心组织所有数据。

具体特点教材讲得比较明确:整体数据的结构化,数据不仅描述事物本身,还描述事物之间的联系,这是数据库系统与文件系统的根本区别;共享性高、冗余度低,一个数据可供多个应用使用,冗余被压缩到极小;数据独立性高,物理存储结构变了,应用程序不用改,逻辑结构调整时应用程序也尽量不用动;DBMS 统一管理,安全性控制、完整性控制、并发控制、数据库恢复四件事全部由 DBMS 承担。

我给学生讲这里时特别强调“物理独立性和逻辑独立性”这对概念。物理独立性指内模式的存储结构变化(换存储引擎、调整磁盘布局)不影响模式和外模式;逻辑独立性指模式(整体逻辑结构)变化时,外模式和应用程序不受影响。这两个独立性是后面第四章“数据库系统结构”的理论支柱,也是考试常客。

3.4 三阶段对比表与两个判断标准

学到这,很多学生容易把三个阶段的特点背混。我建议做一张对比表,把关键维度列出来对照记忆:

维度人工管理阶段文件系统阶段数据库系统阶段
时间50 年代中期以前50 年代后期至 60 年代中期60 年代后期开始
硬件背景磁带、卡片、纸带磁盘、磁鼓等直接存取设备大规模存储设备成熟
数据保存数据不保存,用完撤走数据可长期保存数据长期、有组织保存
数据共享完全无共享共享性差,文件间冗余大共享性高、冗余度低
独立性程序与数据无独立性逻辑结构与物理结构变化影响程序物理独立性与逻辑独立性
管理软件无,应用程序自管文件系统DBMS

记忆时抓两个判断标准就够了:第一,有没有专门的数据管理软件(文件系统、DBMS);第二,数据与程序之间是否真正独立。文件系统阶段有了软件但独立性不够,数据库系统阶段把独立性和共享性同时做到位。这两个标准能应对大多数“区别是什么”的问法。

提示:PPT 里提到“外存有了磁盘、磁鼓等直接存取设备——DASD”,这是文件系统阶段能出现的关键硬件前提。没有随机访问能力,数据就只能顺序读,那“按文件名查记录”就无从谈起。

4. 数据库系统结构:三级模式、六大组成与一次查询的完整路径

4.1 三级模式与两层映象:数据库结构层的“标准答案”

第一章里最容易考、也最容易让学生晕的,就是数据库系统的三级模式结构。外模式(用户模式)对应单个用户或应用看到的数据视图,是用户与数据库的接口;模式(概念模式)描述数据库中全体数据的逻辑结构和特征,是数据库整体逻辑视图;内模式(存储模式)描述数据在存储介质上的物理存储结构与存取方式。

两层映象是连接的桥梁:外模式/模式映象把用户视图映射到全局逻辑模式,模式/内模式映象把全局逻辑结构映射到物理存储结构。这两个映象的价值直接落到两个独立性上——模式/内模式映象保证了物理独立性,外模式/模式映象保证了逻辑独立性。换句话说,DBA 调整了存储结构,只要改映象定义,应用不用动;整体逻辑结构调整时,用户视图也能保持不变。

我讲这部分时常用一个比喻:模式是“全公司的规章制度”,外模式是“某个岗位只看得到的那几页制度”,内模式是“文件柜里文件实际怎么摞”。制度换了个文件柜(内模式变),岗位看见的几页纸内容不变(物理独立性);规章制度大改版但某个岗位的职责描述没变(逻辑独立性)。这个比喻基本能让学生一遍过关。

4.2 数据库系统六大组成:数据库、软件、硬件和人都缺一不可

数据库系统的组成清单,教材和 PPT 讲得很整齐:硬件平台及数据库、操作系统、DBMS(及开发工具)、数据库、应用系统、数据库管理员和用户。这里最容易漏的是“人”这个部分。

DBA 的职责在绪论里就要建立起来:决定数据库中的数据内容与结构;决定数据库的存储结构和存取策略;定义数据的安全性要求和完整性约束条件;监控数据库的使用和运行,处理故障恢复。这些职责对应的正是后面第七章恢复技术、第八章并发控制和安全性完整性章节的内容,现在先挂个钩,后面学到时不至于觉得突兀。

用户侧分两类:应用程序员负责编写应用系统,通过 DML 语句访问数据库;最终用户通过应用系统提供的界面操作数据,不直接面对 SQL。很多初学者误以为自己用 Navicat 连了数据库就是“用户”了,准确说是通过客户端工具与 DBMS 交互的最终用户或开发人员,分类本身不重要,重要的是理解应用系统、DBMS、数据库三层之间是调用与被调用的关系。

4.3 一次查询的完整路径:从 SQL 到磁盘再回来

PPT 里 1.5 节“数据库访问过程”是所有初学者的第一个完整链路。用户在应用系统里发起一条查询,这条 SQL 会经历这样的旅程:

应用系统把用户输入的 SQL 语句发送给 DBMS;DBMS 先做语法分析和词法分析,检查语句是否符合 SQL 规范;接着做合法性检查,确认访问权限(这就是 DCL 相关授权在起作用);然后 DBMS 的优化器把 SQL 转换成内部执行计划,决定走哪个索引、用什么连接方式;执行计划按内模式的定义定位到存储层具体的数据块,从磁盘读出数据;最后按外模式的定义把存储格式转换成用户视图的结构,返回给应用系统。

对应到现代 MySQL,这条路径就是:客户端连接器 → SQL 层(解析、优化、执行计划生成) → 存储引擎 InnoDB(按主键或二级索引定位记录) → 磁盘页 → 返回结果集。绪论课虽然不会讲这么细,但把“数据不是直接从硬盘搬到屏幕”这个意识建立起来,后面学索引和查询优化会轻快很多。

提示:很多学生第一次接触“数据库访问过程”,以为重点是记住步骤。实际上重点是理解“用户请求”和“物理存储”之间隔了 DBMS 这层屏蔽,这正是数据独立性的运行机制所在。

5. 用这份 PPT 自学和备课的常见坑:五个容易理解偏的点

5.1 坑一:把“数据”和“信息”混着用

现象:复习时直接说“数据库存的是信息”,考概念题时把信息的定义答成数据的定义,丢分丢得莫名其妙。

原因:日常生活中“数据”和“信息”经常互相替换,但数据库课程里两者有严格边界。数据是现实世界客观事物的符号表示,是原始的符号序列;信息是数据经过加工、解释后对人类决策有意义的语义内容。

解决:回到 PPT 里那条教员记录。“0005794, 601, 周济, 1, 1946.08.26, 01”是数据;把它解读成“工号为 0005794 的周济老师,1946 年 8 月 26 日出生,汉族,在 601 部门工作”后获得的内容才是信息。做定义题时严格按教材原文写,别自由发挥。

5.2 坑二:数据库、DBMS、DBS 三个名词没有分层

现象:说“我电脑上装了 MySQL,所以我拥有了一个数据库系统”,老师追问“你到底是装了数据库还是装了数据库管理系统”时卡壳。

原因:PPT 里 DBS 的组成包含操作系统、DBMS、数据库、应用系统、DBA、用户,但初学者只盯住最显眼的两个组件,把“装 MySQL”等同于“有数据库系统”。

解决:DBS 是整机概念(硬件+软件+数据+人),DBMS 是其中的软件核心,数据库是 DBMS 管理的具体数据对象。做连线题时,先画 DBS 的组成框图,再把每个框填上实例,就永远不会乱。

5.3 坑三:背熟三阶段特点,却答不出“文件系统为什么不够用”

现象:简答题能默写三个阶段的全部特点,但换个问法“文件系统阶段与数据库系统阶段最本质的区别是什么”就卡壳,只能重复背过的原话。

原因:背了结论没记逻辑——文件系统阶段数据面向单个应用、文件之间无联系,导致数据冗余大、不一致风险高;而数据库系统阶段数据面向整个系统、具有整体结构化,这是质的区别。

解决:用具体场景砸实。“人事部门和财务部门各有一份员工文件,部门信息在两个文件里重复存储,员工调岗时只改了一边,两边的数据就对不上了。” 数据库系统阶段的“整体结构化、共享、低冗余”就是解决这个痛点来的,把场景记住,比背十个特点都管用。

5.4 坑四:看到 SQL Server 2000、Delphi 就觉得课件过时,不想学

现象:学生翻到 PPT 里的 Development 部分写着 SQL Server 2000、Delphi、PowerBuilder,觉得这是一套老古董课件,跟现在用 MySQL 和 PostgreSQL 的场景完全脱节,于是弃坑。

原因:这份课件配套的是萨师煊、王珊第四版教材,开发环境的例子停留在 2000 年代。但 DDL/DML/DCL 的分类、数据管理三阶段、三级模式与两层映象这些核心概念,二十年来没有任何过时。工具版本会迭代,概念骨架不会。

解决:把工具名当历史背景忽略掉,只抽概念框架。用自己本机的 MySQL 或 PostgreSQL 去验证同样的功能,你会发现 CREATE 还是 DDL、SELECT 还是 DML、GRANT 还是 DCL,概念照样成立。顺便说一句,如果你手头用的是数据库系统概论第六版或《数据库系统概念》第七版(黑皮书),第一章讲的也是同一套骨架,只是叙述顺序和例子略有差异。

5.5 坑五:跳过“数据与语义不可分”,后面学 E-R 模型时吃亏

现象:学完绪论,觉得“语义”两个字不重要,考试也不直接考。结果到了第五章学 E-R 模型、设计表结构时,才发现自己对“属性如何对应现实世界的含义”理解不到位,画出来的图跟自己想要的业务对不上。

原因:绪论里的每一句话都有后续章节接应,“数据与其语义不可分”是整个数据库设计的哲学起点。第一次学最容易把它当作一句抽象口号一眼带过,没有落到具体例子上。

解决:从绪论开始就建立一个习惯——看到任何一条记录,先问三个问题:这个字段在现实世界对应什么?这个字段是唯一的吗?这个字段能拆得更细吗?把这个习惯带进上机和课程设计,到第五章设计数据库时,你会发现别人在纠结怎么画图,你已经知道每个属性该放在哪个实体上。

6. 把绪论变成动手实验:用 MySQL 反推一遍数据管理概念

绪论全是概念,最容易变成“听完就忘”。我的血泪经验是:光靠背定义撑不到期末,必须把 PPT 里的抽象名词映射到真实操作上。具体做法是用 MySQL 把第一章涉及的 DDL、DML、DCL 三件事各跑一遍,同时体验数据库的结构化存储。

-- 对应 PPT 1.1.1:CREATE 演示 DBMS 的数据定义功能(DDL) CREATE DATABASE school; USE school; CREATE TABLE employee ( emp_id CHAR(7) COMMENT '工号', dept_id CHAR(3) COMMENT '部门编号', name VARCHAR(20) COMMENT '姓名', gender TINYINT COMMENT '性别编码,1-男 2-女', birth_date DATE COMMENT '出生日期', ethnicity CHAR(2) COMMENT '民族编码' ); -- 用 PPT 里的原始记录:0005794, 601, 周济, 1, 1946.08.26, 01 INSERT INTO employee VALUES ('0005794', '601', '周济', 1, '1946-08-26', '01'); -- 数据操纵功能(DML):查询、修改 SELECT * FROM employee WHERE name = '周济'; UPDATE employee SET dept_id = '602' WHERE emp_id = '0005794'; -- 数据控制功能(DCL):授权(注意 MySQL 8.0 起必须先用 CREATE USER 建用户) CREATE USER 'analyst'@'localhost' IDENTIFIED BY 'passwd'; GRANT SELECT ON school.employee TO 'analyst'@'localhost'; -- 外模式的直观体现:视图只暴露必要字段 CREATE VIEW emp_basic AS SELECT emp_id, name, dept_id FROM employee;

这段代码的逻辑和参数可以拆开看:

DDL 对应的是 PPT 里 DBMS 的“数据定义功能”——CREATE DATABASE 和 CREATE TABLE 改变的是结构本身,不是数据内容。建表时 emp_id 用 CHAR(7) 而不是整数,因为我查过工号含前导零,用 INT 会被截断成 5794;birth_date 用 DATE 而不是 VARCHAR,是为了后续能做日期范围查询。这个字段类型的选择过程,其实就是“有组织地存储数据”的实践形态。

DML 对应 PPT 里的 SELECT、INSERT、UPDATE,它们操作的是表中的数据记录。值得注意的是 INSERT 语句里的顺序必须和 CREATE TABLE 的列顺序保持一致,否则要显式写列名,这是初学者最常见的小翻车。

DCL 对应权限控制。在 MySQL 8.0 之前,可以直接用 GRANT 建用户并授权,但 8.0 之后必须先 CREATE USER 再 GRANT,直接跑老写法会报错。这个细节正好呼应了第 5 章“工具会变、概念不变”的观点——GRANT 的概念没变,语法细节变了。

视图是理解外模式的最好道具。用户访问 emp_basic 只能看到工号、姓名、部门三个字段,底层 employee 表即使加了新列,视图输出也不受影响,这就是逻辑独立性的雏形。等学到第三章 SQL 语言时,视图语句会反复出现,现在先建立一个直观印象。

从那以后,我每次带学生过绪论,都会要求他们先打开 MySQL 建一张表、插两条记录、跑一次 GRANT,再把 PPT 里的四个名词写在纸面上做连线。概念是抽象的,但一旦在终端里跑通过一遍,数据、数据库、DBMS、DBS 这四个词就有了实体感。希望这份笔记帮到你。

本文还有配套的精品资源,点击获取

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询