本节书摘来自华章出版社《数据库原理与应用（第3版）》一 书中的第1章，第1.2节，作者：何玉洁，更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.2　数据管理技术的发展

数据库技术是应数据管理任务的需要而产生和发展的。数据管理包括对数据进行分类、组织、编码、存储、检索和维护，是数据处理的核心，而数据处理则是对各种数据进行收集、存储、加工和传播等一系列活动的总和。
自计算机产生之后，人们就希望用它来帮助我们对数据进行存储和管理。最初对数据的管理是以文件方式进行的，也就是通过编写应用程序来实现对数据的存储和管理。后来，随着数据量越来越大，人们对数据的要求越来越多，希望达到的目的也越来越复杂，文件管理方式已经很难满足人们对数据的需求，由此产生了数据库技术，也就是用数据库来存储和管理数据。数据管理技术的发展因此也就经历了文件管理和数据库管理两个阶段。
本节介绍文件管理方式和数据库管理方式在数据管理上的主要差别。

1.2.1　文件管理

理解今日数据库特征的最好办法是了解在数据库技术产生之前，人们是如何通过文件的方式对数据进行管理的。
20世纪50年代后期到60年代中期，计算机的硬件方面已经有了磁盘等直接存取的存储设备，在软件方面，操作系统中已经有了专门的数据管理软件，一般称为文件管理系统。文件管理系统把数据组织成相互独立的数据文件，利用“按文件名访问，按记录进行存取”的管理技术，可以对文件中的数据进行修改、插入和删除等操作。
在出现程序设计语言之后，开发人员不但可以创建自己的文件并将数据保存在自己定义的文件中，而且还可以通过编写应用程序的方式来处理文件中的数据，即编写应用程序来定义文件的结构，实现对文件内容的插入、删除、修改和查询操作。当然，真正实现磁盘文件的物理存取操作的还是操作系统中的文件管理系统，应用程序只是告诉文件管理系统对哪个文件的哪些数据进行哪些操作。我们将由开发人员定义存储数据的文件及文件结构，并借助文件管理系统的功能编写访问这些文件的应用程序，以实现对用户数据的处理的方式称为文件管理。为叙述简单，在本章后面的讨论中将忽略文件管理系统，假定应用程序是直接对磁盘文件进行操作的。
如果用文件管理数据，用户必须编写应用程序来管理存储在文件中的数据，其操作模式如图1-2所示。
假设某学校要用文件的方式保存学生及其选课的数据，并在这些数据文件基础之上构建对学生进行管理的系统。此系统主要实现两部分功能：学生基本信息管理和学生选课情况管理。假设教务部门管理学生选课情况，各系部管理学生基本信息。学生基本信息管理中涉及学生的基本信息数据，假设这些数据保存在F1文件中；学生选课情况管理涉及学生的部分基本信息、课程基本信息和学生选课信息。假设用F2和F3文件分别保存课程基本信息和学生选课信息的数据。
设A1为实现“学生基本信息管理”功能的应用程序，A2为实现“学生选课管理”功能的应用程序。由于学生选课管理中要用到F1文件中的一些数据，为减少冗余，它将使用“学生基本信息管理”（即F1文件）中的数据，如图1-3所示（图中省略了操作系统部分）。

假设F1、F2和F3文件分别包含如下信息：
F1文件——学号、姓名、性别、出生日期、联系电话、所在系、专业、班号。
F2文件——课程号、课程名、授课学期、学分、课程性质。
F3文件——学号、姓名、所在系、专业、课程号、课程名、修课类型、修课时间、考试成绩。
我们将文件中所包含的每一个子项称为文件结构中的“字段”或“列”，将每一行数据称为一个“记录”。
“学生选课管理”的处理过程大致为：在学生选课管理中，若有学生选课，则先查F1文件，判断有无此学生；若有，则再访问F2文件，判断其所选的课程是否存在；若一切符合规则，就将学生选课信息写到F3文件中。
这看似很好，但仔细分析一下，就会发现直接用文件管理数据有如下缺点。
（1）编写应用程序不方便
应用程序编写者必须清楚地了解所用文件的逻辑及物理结构，如文件中包含多少个字段，每个字段的数据类型，采用何种逻辑结构和物理存储结构。操作系统只提供了打开、关闭、读、写等几个底层的文件操作命令，而对文件的查询、修改等处理都必须在应用程序中编程实现。这样就容易造成各应用程序在功能上的重复，比如图1-3中的“学生基本信息管理”和“学生选课管理”都要对F1文件进行操作，而共享这两个功能相同的操作却很难。
（2）数据冗余不可避免
由于A2应用程序需要在学生选课信息文件（F3文件）中包含学生的一些基本信息，比如学号、姓名、所在系、专业等，而这些信息同样包含在学生信息文件（F1文件）中，因此F3文件和F1文件中存在相同数据，从而造成数据的重复，称为数据冗余。
数据冗余所带来的问题不仅仅是存储空间的浪费（其实，随着计算机硬件技术的飞速发展，存储容量不断扩大，空间问题已经不是我们关注的主要问题），更为严重的是造成了数据的不一致（inconsistency）。例如，某个学生所学的专业发生了变化，我们一般只会想到在F1文件中进行修改，而往往忘记了在F3中应进行同样的修改。由此就造成了同一名学生在F1文件和F3文件中的“专业”不一样，也就是数据不一致。人们不能判定哪个数据是正确的，尤其是当系统中存在多处数据冗余时，更是如此。这样数据就失去了可信性。
文件本身并不具备维护数据一致性的功能，这些功能完全要由用户（应用程序开发者）负责维护。这在简单的系统中还可以勉强应付，但在复杂的系统中，若让应用程序开发者来保证数据的一致性，几乎是不可能的。
（3）应用程序依赖性
就文件管理而言，应用程序对数据的操作依赖于存储数据的文件结构。文件和记录的结构通常是应用程序代码的一部分，如C程序的struct。文件结构的每一次修改，比如添加字段、删除字段，甚至修改字段的长度（如电话号码从7位扩展到8位），都将导致应用程序的修改，因为在打开文件进行数据读取时，必须将文件记录中不同字段的值对应到应用程序的变量中。随着应用环境和需求的变化，修改文件的结构不可避免，这些都需要在应用程序中作相应的修改，而（频繁）修改应用程序是很麻烦的。人们首先要熟悉原有程序，修改后还需要对程序进行测试、安装等；甚至在只是修改了文件的存储位置或者文件名的情况下，也需要对应用程序进行修改，这显然会给程序维护人员带来很多麻烦。
所有这些都是由于应用程序对文件结构以及文件物理特性的过分依赖造成的，换句话说，用文件管理数据时，其数据独立性（data independence）很差。
（4）不支持对文件的并发访问
在现代计算机系统中，为了有效利用计算机资源，一般都允许同时运行多个应用程序（尤其是在多任务操作系统环境中）。文件最初是作为程序的附属数据出现的，它一般不支持多个应用程序同时对同一个文件进行访问。回忆一下，某个用户打开了一个Excel文件，当第二个用户在第一个用户未关闭此文件前打开此文件时，会得到什么信息呢？他只能以只读方式打开此文件，而不能在第一个用户打开的同时对此文件进行修改。再回忆一下，如果用某种程序设计语言编写一个对某文件内容进行修改的程序，其过程是先以写的方式打开文件，然后修改其内容，最后再关闭文件。在关闭文件之前，不管是在其他的程序中，还是在同一个程序中都不允许再次打开此文件，这就是文件管理方式不支持并发访问的含义所在。
对于以数据为中心的系统来说，必须要支持多个用户对数据的并发访问，否则就不会有我们现在这么多的火车或飞机的订票点，也不会有这么多的银行营业网点。
（5）数据间联系弱
当用文件管理数据时，文件与文件之间是彼此独立、毫不相干的，文件之间的联系必须通过编程来实现。比如上述的F1文件和F3文件，F3文件中的学号、姓名等学生的基本信息必须是F1文件中已经存在的（即选课的学生必须是已经存在的学生）；同样，F3文件中课程号等与课程有关的基本信息也必须存在于F2文件中（即学生选的课程也必须是已经存在的课程）。这些数据之间的联系是实际应用当中所要求的很自然的联系，但文件本身不具备自动实现这些联系的功能，我们必须通过编写应用程序，即手工地建立这些联系。这不但增加了编写代码的工作量和复杂度，而且当联系很复杂时，也难以保证其正确性。因此，用文件管理数据时很难反映现实世界事物间客观存在的联系。
（6）难以满足不同用户对数据的需求
不同的用户（数据使用者）关注的数据往往不同。例如对于学生基本信息，负责分配学生宿舍的部门可能只关心学生的学号、姓名、性别和班号，而教务部门可能关心的是学号、姓名、所在系和专业。
若多个不同用户希望看到的是不同的基本信息，就需要为每个用户单独建立一个文件，这势必造成更多的数据冗余。而我们希望的是，用户关心哪些信息就为他生成哪些信息，将用户不关心的数据屏蔽，使用户感觉不到其他信息的存在。
可能还会有一些用户，其所需要的信息来自于多个不同的文件，例如，假设各班班主任关心的是班号、学号、姓名、课程名、学分、考试成绩等。这些信息涉及了三个文件：从F1文件中得到“班号”，从F2文件中得到“学分”，从F3文件中得到“考试成绩”；而“学号”和“姓名”可以从F1文件或F3文件中得到，“课程名”可以从F2文件或F3文件中得到。在生成结果数据时，必须对从三个文件中读取的数据进行比较，然后组合成一行有意义的数据。比如，将从F1文件中读取的学号与从F3文件中读取的学号进行比较，学号相同时，才可以将F1文件中的“班号”与F3文件中的当前记录所对应的学号和姓名组合起来。之后，还需要将组合结果与F2文件中的内容进行比较，找出课程号相同的课程的学分，再与已有的结果组合起来。然后再从组合后的数据中提取出用户需要的信息。如果数据量很大，涉及的文件比较多时，我们可以想象这个过程有多复杂。因此，这种大容量复杂信息的查询，在按文件管理数据的方式中是很难处理的。
（7）无安全控制功能
在文件管理方式中，很难控制某个人对文件能够进行的操作，比如只允许某个人查询和修改数据，但不能删除数据，或者对文件中的某个或者某些字段不能修改等。而在实际应用中，数据的安全性是非常重要且不可忽视的。比如，在学生选课管理中，我们不允许学生修改其考试成绩；在银行系统中，更是不允许一般用户修改其存款数额。
随着人们对数据需求的增加，迫切需要对数据进行有效、科学、正确、方便的管理。针对文件管理方式的这些缺陷，人们逐步开发出了以统一管理和共享数据为主要特征的数据库管理系统。

1.2.2　数据库管理

自20世纪60年代末以来，计算机管理数据的规模越来越大，应用范围越来越广泛，数据量急剧增加，多种应用同时共享数据集合的要求也越来越强烈。
随着大容量磁盘的出现，硬件价格不断下降，软件价格不断上升，编制和维护系统软件和应用程序的成本相应地不断增加。在数据处理方式上，对联机实时处理的要求越来越多，同时开始提出和考虑分布式处理技术。在这种背景下，以文件方式管理数据已经不能满足应用的需求，于是出现了新的管理数据的技术——数据库技术，同时出现了统一管理数据的专门软件——数据库管理系统。
从1.2.1节的介绍我们可以看到，在数据库管理系统出现之前，人们对数据的操作是直接针对数据文件编写应用程序实现的，这种模式会产生很多问题。在有了数据库管理系统之后，人们对数据的操作全部是通过数据库管理系统实现的，而且应用程序的编写也不再直接针对存放数据的文件。有了数据库技术和数据库管理系统软件之后，人们对数据的操作模式发生了根本性的变化，如图1-4所示。
比较图1-2和图1-4，可以看到主要区别有两个：第一，是在操作系统和用户应用程序之间增加了一个系统软件——数据库管理系统，使得用户对数据的操作都是通过数据库管理系统实现的；第二，有了数据库管理系统之后，用户不再需要有数据文件的概念，即不再需要知道数据文件的逻辑和物理结构及物理存储位置，而只需要知道存放数据的场所——数据库即可。
从本质上讲，即使在有了数据库技术之后，数据最终还是以文件的形式存储在磁盘上，只是这时对物理数据文件的存取和管理是由数据库管理系统统一实现的，而不是由每个用户通过应用程序编程实现。数据库和数据文件既有区别又有联系，它们之间的关系类似于单位的名称和地址之间的关系。单位地址代表了单位的实际存在位置，单位名称是单位的逻辑代表。而且一个数据库可以包含多个数据文件，就像一个单位可以有多个不同的地址一样（我们现在的很多大学，都是一个学校有多个校址），每个数据文件存储数据库的部分数据。不管一个数据库包含多少个数据文件，对用户来说，他只针对数据库进行操作，而无需对数据文件进行操作。这种模式极大地简化了用户对数据的访问。
在有了数据库技术之后，用户只需要知道数据库的名字，就可以对数据库对应的数据文件中的数据进行操作。而将对数据库的操作转换为对物理数据文件的操作是由数据库管理系统自动实现的，用户不需要知道，也不需要干预。
对于1.2.1节中介绍的学生基本信息管理和学生选课管理两个子系统，如果使用数据库技术来管理，其实现方式如图1-5所示。

与文件管理相比，数据库管理具有以下优点。
（1）相互关联的数据集合
在数据库系统中，所有相关的数据都存储在一个称为数据库的环境中，它们作为一个整体定义。比如学生基本信息管理中的“学号”与学生选课管理中的“学号”，这两个学号之间是有关联关系的，即学生选课管理中的“学号”的取值范围在学生基本信息管理的“学号”取值范围内。在关系数据库中，数据之间的关联关系是通过定义外键实现的。
（2）较少的数据冗余
由于数据是统一管理的，因此可以从全局着眼，合理地组织数据。例如，将1.2.1节中文件F1、F2和F3的重复数据挑选出来，进行合理的管理，就可以形成如下所示的几部分信息。
学生基本信息：学号、姓名、性别、出生日期、联系电话、所在系、专业、班号。
课程基本信息：课程号、课程名、授课学期、学分、课程性质。
学生选课信息：学号、课程号、修课类型、修课时间、考试成绩。
在关系数据库中，可以将每一类信息存储在一个表中（关系数据库的概念将在第2章介绍），重复的信息只存储一份，当在学生选课管理中需要学生的姓名等其他信息时，根据学生选课管理中的学号，可以很容易地在学生基本信息中找到此学号对应的姓名等信息。因此，消除数据的重复存储不影响对信息的提取，同时还可以避免由于数据重复存储而造成的数据不一致问题。比如，当某个学生所学的专业发生变化时，只需在“学生基本信息”中进行修改即可。
同1.2.1节中的问题一样，当所需的信息来自不同地方，比如（班号，学号，姓名，课程名，学分，考试成绩），这些信息需要从3个地方（关系数据库为3张表）得到，这种情况下，也需要对信息进行适当的组合，即学生选课信息中的学号只能与学生基本信息中学号相同的信息组合在一起，同样，学生选课信息中的课程号也必须与课程基本信息中课程号相同的信息组合在一起。过去在文件管理方式中，这个工作是由开发者编程实现的，而现在有了数据库管理系统，这些烦琐的工作完全交给了数据库管理系统来完成。
因此，在数据库管理系统中，避免数据冗余不会增加开发者的负担。在关系数据库中，避免数据冗余是通过关系规范化理论实现的。
（3）程序与数据相互独立
在数据库中，数据所包含的所有数据项以及数据的存储格式都与数据存储在一起，它们通过DBMS而不是应用程序来操作和管理，应用程序不再需要处理文件和记录的格式。
程序与数据相互独立有两方面的含义。一方面是当数据的存储方式发生变化时（这里包括逻辑存储方式和物理存储方式），比如从链表结构改为散列表结构，或者是顺序和非顺序之间的转换，应用程序不必作任何修改。另一方面是当数据的逻辑结构发生变化时，比如增加或减少了一些数据项，如果应用程序与这些修改的数据项无关，则不用修改应用程序。这些变化都将由DBMS负责维护。大多数情况下，应用程序并不知道也不需要知道数据存储方式或数据项已经发生了变化。
在关系数据库中，数据库管理系统可以自动保证程序与数据相互独立。
（4）保证数据的安全和可靠
数据库技术能够保证数据库中的数据是安全和可靠的。它的安全控制机制可以有效地防止数据库中的数据被非法使用和非法修改；其完整的备份和恢复机制可以保证当数据遭到破坏时（由软件或硬件故障引起的）能够很快地将数据库恢复到正确的状态，并使数据不丢失或只有很少的丢失，从而保证系统能够连续、可靠地运行。保证数据的安全是通过数据库管理系统的安全控制机制实现的，保证数据的可靠是通过数据库管理系统的备份和恢复机制实现的。
（5）最大限度地保证数据的正确性
数据的正确性（也称为数据的完整性）是指存储到数据库中的数据必须符合现实世界的实际情况，比如人的性别只能是“男”和“女”，人的年龄应该在0～150岁之间（假设没有年龄超过150岁的人）。如果在性别中输入了其他值，或者将一个负数输入到年龄中，在现实世界中显然是不对的。数据的正确性是通过在数据库中建立约束来实现的。当建立好保证数据正确的约束之后，如果有不符合约束的数据存储到数据库中，数据库管理系统能主动拒绝这些数据。
（6）数据可以共享并能保证数据的一致性
数据库中的数据可以被多个用户共享，即允许多个用户同时操作相同的数据。当然，这个特点是针对支持多用户的大型数据库管理系统而言的，对于只支持单用户的小型数据库管理系统（比如Access），在任何时候最多只有一个用户访问数据库，因此不存在共享的问题。
多用户共享问题是数据库管理系统内部解决的问题，它对用户是不可见的。这就要求数据库能够对多个用户进行协调，保证多个用户之间对数据的操作不会产生矛盾和冲突，即在多个用户同时使用数据库时，能够保证数据的一致性和正确性。设想一下火车订票系统，如果多个订票点同时对某一天的同一列火车进行订票，那么必须保证不同订票点订出票的座位不能重复。
数据可共享并能保证共享数据的一致性是由数据库管理系统的并发控制机制实现的。
到今天，数据库技术已经发展成为一门比较成熟的技术，通过上述讨论，我们可以概括出数据库具备如下特征：数据库是相互关联的数据的集合，它用综合的方法组织数据，具有较小的数据冗余，可供多个用户共享，具有较高的数据独立性，具有安全控制机制，能够保证数据的安全、可靠，允许并发地使用数据库，能有效、及时地处理数据，并能保证数据的一致性和正确性。
需要强调的是，所有这些特征并不是数据库中的数据固有的，而是靠数据库管理系统提供和保证的。