1.3 数据管理技术的发展

数据库技术是应数据管理任务的需要而产生和发展的。数据管理是指对数据进行分类、组织、编码、存储、检索和维护，它是数据处理的核心，而数据处理则是指对各种数据的收集、存储、加工和传播等一系列活动的总和。

自计算机产生之后，人们就希望用它来帮助我们对数据进行存储和管理。最初对数据的管理是以文件方式进行的，也就是用户通过编写应用程序来实现对数据的存储和管理。后来，随着数据量越来越大，人们对数据的要求越来越多，希望达到的目的也越来越复杂，文件管理方式已经很难满足人们对数据的需求，由此产生了数据库技术，也就是用数据库来存储和管理数据。数据管理技术的发展因此也就经历了文件管理和数据库管理两个阶段。

本节将介绍文件管理和数据库管理在管理数据上的主要差别。

1.3.1 文件管理

理解今日数据库特征的最好办法是了解在数据库技术产生之前，人们是如何通过文件的方式对数据进行管理的。

20世纪50年代后期到60年代中期，计算机的硬件方面已经有了磁盘等直接存取的存储设备，软件方面，操作系统中已经有了专门的数据管理软件，一般称为文件管理系统。文件管理系统把数据组织成相互独立的数据文件，利用“按文件名访问，按记录进行存取”的管理技术，可以对文件中的数据进行修改、插入和删除等操作。

在出现程序设计语言之后，开发人员不但可以创建自己的文件并将数据保存在自己定义的文件中，而且还可以编写应用程序来处理文件中的数据，即编写应用程序来定义文件的结构，实现对文件内容的插入、删除、修改和查询操作。当然，真正实现磁盘文件的物理存取操作的还是操作系统中的文件管理系统，应用程序只是告诉文件管理系统对哪个文件的哪些数据进行哪些操作。我们将由开发人员定义存储数据的文件及文件结构，并借助文件管理系统的功能编写访问这些文件的应用程序，以实现对用户数据的处理的方式称为文件管理。在本章后面的讨论中，为描述简单，我们将忽略操作系统中的文件管理系统，假定应用程序直接对磁盘文件进行操作。

用户通过编写应用程序来管理存储在自定义文件中的数据的操作模式如图1-2所示。

假设某学校要用文件的方式保存学生及其选课的数据，并针对这些数据文件构建对学生及选课情况进行管理的系统。此系统主要实现两部分功能：学生基本信息管理和学生选课情况管理。假设教务部门管理学生选课情况，各系管理自己的学生基本信息。学生基本信息管理只涉及学生的基本信息数据，假设这些数据保存在F1文件中；学生选课情况管理涉及学生的部分基本信息、课程基本信息和学生选课信息，假设文件F2和F3分别保存课程基本信息和学生选课信息的数据。

设A1为实现“学生基本信息管理”功能的应用程序，A2为实现“学生选课管理”功能的应用程序。图1-3所示为用文件存储并管理数据的实现示例（图中省略了操作系统部分）。

假设文件F1、F2和F3分别包含以下信息。

F1文件：学号、姓名、性别、出生日期、联系电话、所在系、专业、班号。

F2文件：课程号、课程名、授课学期、学分、课程性质。

F3文件：学号、姓名、所在系、专业、课程号、课程名、修课类型、修课时间、考试成绩。

我们将文件中所包含的每一个子项称为文件结构中的“字段”或“列”，将每一行数据称为一个“记录”。

“学生选课管理”的处理过程大致为：在学生选课管理中，若有学生选课，则先查F1文件，判断有无此学生；若有，则再访问F2文件，判断其所选的课程是否存在；若一切符合规则，就将学生选课信息写到F3文件中。

这看似很好，但仔细分析一下，就会发现用文件方式管理数据有以下缺点。

① 编写应用程序不方便。应用程序编写者必须清楚地了解所用文件的逻辑及物理结构，如文件中包含多少个字段，每个字段的数据类型，采用何种逻辑结构和物理存储结构。操作系统只提供了打开、关闭、读、写等几个底层的文件操作命令，而对文件的查询、修改等操作，都必须在应用程序中编程实现。这样就容易造成各应用程序在功能上的重复，如图1-3所示的“学生基本信息管理”和“学生选课管理”都要对F1文件进行操作，而共享这两个功能相同的操作却很难。

② 数据冗余不可避免。由于A2应用程序需要在学生选课信息文件（F3文件）中包含学生的一些基本信息，如学号、姓名、所在系、专业等，而这些信息同样包含在学生信息文件（F1文件）中，因此，F3文件和F1文件中存在重复数据，从而造成数据的重复，称为数据冗余。

数据冗余带来的问题不仅仅是存储空间的浪费（其实，随着计算机硬件技术的飞速发展，存储容量不断扩大，空间问题已经不是我们关注的主要问题），更为严重的是造成了数据的不一致（inconsistency）。例如，某个学生所学的专业发生了变化，我们一般只会想到在F1文件中进行修改，而往往忘记了在F3文件中应做同样的修改。由此就造成了同一名学生在F1文件和F3文件中的“专业”不一样，也就是数据不一致。当发生数据不一致时，人们不能判定哪个数据是正确的，尤其是当系统中存在多处数据冗余时，更是如此。这样，数据就失去了其可信性。

文件本身并不具备维护数据一致性的功能，这些功能完全要由用户（应用程序开发者）负责维护。这在简单的系统中还可以勉强应对，但在复杂的系统中，若让应用程序开发者来保证数据的一致性，几乎是不可能的。

③ 应用程序依赖性。就文件管理而言，应用程序对数据的操作依赖于存储数据的文件的结构。定义文件和记录的结构通常是应用程序代码的一部分，如C程序的struct。文件结构的每一次修改，如添加字段、删除字段，甚至修改字段的长度（如电话号码从7位扩到8位），都将导致应用程序的修改，因为在打开文件进行数据读取时，必须将文件记录中不同字段的值对应到应用程序的变量中。随着应用环境和需求的变化，修改文件的结构不可避免，这些都需要在应用程序中做相应的修改，而（频繁）修改应用程序是很麻烦的。人们首先要熟悉原有程序，修改后还需要对程序进行测试、安装等；甚至修改了文件的存储位置或者文件名，也需要对应用程序进行修改，这显然给程序的维护带来很多麻烦。

所有这些都是由于应用程序对文件的结构以及文件的物理特性过分依赖造成的，换句话说，用文件管理数据时，其数据独立性（data independence）很差。

④ 不支持对文件的并发访问。在现代计算机系统中，为了有效利用计算机资源，一般都允许同时运行多个应用程序（尤其是在现在的多任务操作系统环境中）。文件最初是作为程序的附属数据出现的，它一般不支持多个应用程序同时对同一个文件进行访问。回忆一下，某个用户打开了一个Word文件，当第二个用户在第一个用户未关闭此文件前打开此文件时，会得到什么信息呢？他只能以只读方式打开此文件，而不能在第一个用户打开的同时对此文件进行修改。再回忆一下，如果用某种程序设计语言编写一个对某文件中内容进行修改的程序，其过程是先以写的方式打开文件，然后修改其内容，最后再关闭文件。在关闭文件之前，不管是在其他的程序中，还是在同一个程序中，都不允许再次打开此文件，这就是文件管理方式不支持并发访问的含义。

对于以数据为中心的系统来说，必须支持多个用户对数据的并发访问，否则就不会有这么多的火车或飞机的订票点，也不会有这么多的银行营业网点。

⑤ 数据间联系弱。当用文件管理数据时，文件与文件之间是彼此独立、毫不相干的，文件之间的联系必须通过程序来实现。例如，对上述的F1文件和F3文件，F3文件中的学号、姓名等学生的基本信息必须是F1文件中已经存在的（即选课的学生必须是已经存在的学生）；同样，F3文件中的课程号等与课程有关的基本信息也必须存在于F2文件中（即学生选的课程也必须是已经存在的课程）。这些数据之间的联系是实际应用当中所要求的很自然的联系，但文件本身不具备自动实现这些联系的功能，我们必须通过编写应用程序，即手工地建立这些联系。这不但增加了编写代码的工作量和复杂度，而且当联系很复杂时，也难以保证其正确性。因此，用文件管理数据时很难反映现实世界事物间客观存在的联系。

⑥ 难以满足不同用户对数据的需求。不同的用户（数据使用者）关注的数据往往不同。例如，对于学生基本信息，负责分配学生宿舍的部门可能只关心学生的学号、姓名、性别和班号，而教务部门可能关心的是学号、姓名、所在系和专业。

若多个不同用户希望看到的是学生的不同基本信息，那么就需要为每个用户建立一个文件，这势必造成很多的数据冗余。我们希望的是，用户关心哪些信息就为他生成哪些信息，将用户不关心的数据屏蔽，使用户感觉不到其他信息的存在。

可能还会有一些用户，其需要的信息来自于多个不同的文件。例如，假设各班班主任关心的是：班号、学号、姓名、课程名、学分、考试成绩等。这些信息涉及了3个文件：从F1文件中得到“班号”，从F2文件中得到“学分”，从F3文件中得到“考试成绩”；而“学号”“姓名”可以从F1文件或F3文件中得到，“课程名”可以从F2文件或F3文件中得到。在生成结果数据时，必须对从3个文件中读取的数据进行比较，然后组合成一行有意义的数据。例如，将从F1文件中读取的学号与从F3文件中读取的学号进行比较，学号相同时，才可以将F1文件中的“班号”与F3文件中的当前记录所对应的学号和姓名组合起来，之后，还需要将组合结果与F2文件中的内容进行比较，找出课程号相同的课程的学分，再与已有的结果组合起来。然后再从组合后的数据中提取出用户需要的信息。如果数据量很大，涉及的文件比较多时，这个过程非常复杂。因此，这种复杂信息的查询，在按文件管理数据的方式中是很难处理的。

⑦ 无安全控制功能。在文件管理方式中，很难控制某个人对文件能够进行的操作，如只允许某个人查询和修改数据，但不能删除数据，或者对文件中的某个或者某些字段不能修改等。而在实际应用中，数据的安全性是非常重要且不可忽视的。例如，在学生选课管理中，我们不允许学生修改其考试成绩，但允许他们查询自己的考试成绩。在银行系统中，更是不允许一般用户修改其存款数额。

人们对数据需求的增加，迫切需要对数据进行有效、科学、正确、方便的管理。针对文件管理方式的这些缺陷，人们逐步开发出了以统一管理和共享数据为主要特征的数据库管理系统。

1.3.2 数据库管理

20世纪60年代后期以来，计算机管理数据的规模越来越大，应用范围越来越广泛，数据量急剧增加，同时多种应用同时共享数据集合的要求也越来越强烈。

随着大容量磁盘的出现，硬件价格的不断下降，软件价格的不断上升，编制和维护系统软件和应用程序的成本相应地不断增加。在数据处理方式上，对联机实时处理的需求越来越多，同时开始提出和考虑分布式处理技术。在这种背景下，以文件方式管理数据已经不能满足应用的需求，于是出现了新的管理数据的技术——数据库技术，同时出现了统一管理数据的专门软件——数据库管理系统。

从1.3.1小节的介绍可以看到，在数据库管理系统出现前，人们对数据的操作是通过直接针对数据文件编写应用程序实现的，这种模式会产生很多问题。有了数据库管理系统后，人们对数据的操作全部是通过数据库管理系统实现的，而且应用程序的编写也不再直接针对存放数据的文件。有了数据库技术和数据库管理系统后，人们对数据的操作模式发生了根本的变化，如图1-4所示。

比较图1-2和图1-4，可以看到主要区别有两个：第一个是在操作系统和用户应用程序之间增加了一个系统软件——数据库管理系统，使得用户对数据的操作都是通过数据库管理系统实现的；第二个是有了数据库管理系统后，用户不再需要有数据文件的概念，即不再需要知道数据文件的逻辑和物理结构及物理存储位置，只需知道存放数据的场所——数据库即可。

本质上讲，即使在有了数据库技术后，数据最终还是以文件的形式存储在磁盘上的（这点我们将在本书附录A中的“创建数据库”部分可以体会到），只是这时对物理数据文件的存取和管理是由数据库管理系统统一实现的，而不再是每个用户通过编写应用程序实现。数据库和数据文件既有区别，又有联系，它们之间的关系类似于单位的名称和地址之间的关系。单位地址代表了单位的实际存在位置，单位名称是单位的逻辑代表。而且，一个数据库可以包含多个数据文件，就像一个单位可以有多个不同的地址一样（就像我们现在的很多大学，都是一个学校有多个校址），每个数据文件存储数据库的部分数据。不管一个数据库包含多少个数据文件，对用户来说，他只针对数据库进行操作，无需对数据文件进行操作。这种模式极大地简化了用户对数据的访问。

有了数据库技术后，用户只需要知道存放所需数据的数据库名，就可以对数据库对应的数据文件中的数据进行操作。将对数据库的操作转换为对物理数据文件的操作是由数据库管理系统自动实现的，用户不需要知道，也不需要干预。

对于1.3.1小节中列举的学生基本信息管理和学生选课管理两个子系统，如果使用数据库技术来实现，其实现方式如图1-5所示。

与用文件管理数据相比，用数据库技术管理数据具有以下特点。

① 相互关联的数据集合。在用数据库技术管理数据时，所有相关的数据都被存储在一个数据库中，它们作为一个整体定义，因此可以很方便地表达数据之间的关联关系。例如，学生基本信息中的“学号”与学生选课管理中的“学号”，这两个学号之间是有关联关系的，即学生选课中的“学号”的取值范围在学生基本信息的“学号”取值范围内。在关系数据库中，数据之间的关联关系是通过参照完整性实现的。

② 较少的数据冗余。由于数据被统一管理，因此可以从全局着眼，对数据进行最合理的组织。例如，将1.3.1小节中文件F1、F2和F3的重复数据挑选出来，进行合理的管理，这样就可以形成以下所示的几部分信息。

学生基本信息：学号、姓名、性别、出生日期、联系电话、所在系、专业、班号。

课程基本信息：课程号、课程名、授课学期、学分、课程性质。

学生选课信息：学号、课程号、修课类型、修课时间、考试成绩。

在关系数据库中，可以将每一类信息存储在一个表中（关系数据库的概念将在后边介绍），重复的信息只存储一份，当在学生选课中需要学生的姓名等其他信息时，根据学生选课中的学号，可以很容易地在学生基本信息中找到此学号对应的姓名等信息。因此，消除数据的重复存储不影响对信息的提取，同时还可以避免由于数据重复存储而造成的数据不一致问题。例如，当某个学生所学的专业发生变化时，在“学生基本信息”一个地方进行修改即可。

同1.3.1小节中的问题一样，当所需的信息来自不同地方，如（班号，学号，姓名，课程名，学分，考试成绩）信息，这些信息需要从三个地方（关系数据库为三张表）得到，这种情况下，也需要对信息进行适当的组合，即学生选课中的学号只能与学生基本信息中学号相同的信息组合在一起。同样，学生选课中的课程号也必须与课程基本信息中课程号相同的信息组合在一起。过去在文件管理方式中，这个工作是由开发者编程实现的，而现在有了数据库管理系统，这些烦琐的工作完全交给了数据库管理系统来完成。

因此，在用数据库技术管理数据的系统中，避免数据冗余不会增加开发者的负担。在关系数据库中，避免数据冗余是通过关系规范化理论实现的。

③ 程序与数据相互独立。在数据库中，组成数据的数据项以及数据的存储格式等信息都与数据存储在一起，它们通过DBMS，而不是应用程序来操作和管理，应用程序不再需要处理文件和记录的格式。

程序与数据相互独立有两方面的含义。一方面是当数据的存储方式发生变化时（这里包括逻辑存储方式和物理存储方式），如从链表结构改为散列结构，或者是顺序存储和非顺序存储之间的转换，应用程序不必作任何修改。另一方面是当数据所包含的数据项发生变化时，如增加或减少了一些数据项，如果应用程序与这些修改的数据项无关，则不用修改应用程序。这些变化都将由DBMS负责维护。大多数情况下，应用程序并不知道，也不需要知道数据存储方式或数据项已经发生了变化。

在关系数据库中，数据库管理系统通过将数据划分为三个层次来自动保证程序与数据相互独立。第2章将详细介绍数据的三个层次，也称为三级模式结构。

④ 保证数据安全、可靠。数据库技术能够保证数据库中的数据是安全的和可靠的。它的安全控制机制可以有效地防止数据库中的数据被非法使用和非法修改；其完整的备份和恢复机制可以保证当数据遭到破坏时（由软件或硬件故障引起的）能够很快地将数据库恢复到正确的状态，并使数据不丢失或丢失很少，从而保证系统能够连续、可靠地运行。保证数据的安全是通过数据库管理系统的安全控制机制实现的，保证数据的可靠是通过数据库管理系统的备份和恢复机制实现的。

⑤ 最大限度地保证数据的正确性。数据的正确性也称为数据的完整性，它是指存储到数据库中的数据必须符合现实世界的实际情况，如人的性别只能是“男”和“女”，人的年龄应该在0～150（假设没有年龄超过150岁的人）。如果在性别中输入了其他值，或者将一个负数输入年龄中，在现实世界中显然是不对的。数据的正确性是通过在数据库中建立完整性约束来实现的。当建立好保证数据正确的约束后，如果有不符合约束的数据要存储到数据库中，数据库管理系统能主动拒绝这些数据。

⑥ 数据可以共享并能保证数据的一致性。数据库中的数据可以被多个用户共享，即允许多个用户同时操作相同的数据。当然，这个特点是针对支持多用户的大型数据库管理系统而言的，对于只支持单用户的小型数据库管理系统（如Access），任何时候最多只允许一个用户访问数据库，因此不存在共享的问题。

多用户共享问题是数据库管理系统内部解决的问题，它对用户是不可见的。这就要求数据库管理系统能够对多个用户进行协调，保证多个用户之间对相同数据的操作不会产生矛盾和冲突，即在多个用户同时操作相同数据时，能够保证数据的一致性和正确性。设想一下火车订票系统，如果多个订票点同时对某一天的同一车次火车进行订票，那么必须保证不同订票点订出票的座位不能重复。

数据可共享并能保证共享数据的一致性是由数据库管理系统的并发控制机制实现的。

目前，数据库技术已经发展成为一门比较成熟的技术。通过上述讨论，可以概括出数据库具备如下特征：

数据库是相互关联的数据的集合，它用综合的方法组织数据，具有较小的数据冗余，可供多个用户共享，具有较高的数据独立性，具有安全控制机制，能够保证数据安全、可靠，允许并发地使用数据库，能有效、及时地处理数据，并能保证数据的一致性和正确性。

需要强调的是，所有这些特征并不是数据库中的数据固有的，而是靠数据库管理系统提供和保证的。