首页 理论教育数据库技术与应用教程-文件管理方式

数据库技术与应用教程-文件管理方式

【摘要】:由开发人员定义存储数据的文件及文件结构,借助文件管理系统的功能编写访问这些文件的应用程序,以实现对用户数据的处理方式称为文件管理,在本章后面的讨论中将忽略文件管理系统,假定应用程序是直接对磁盘文件进行操作的。图1—1文件管理的操作模式假设某学校要用文件的方式保存学生及其选课的数据,并在这些数据文件基础之上构建对学生进行管理的系统。图1—2文件管理实现示例假设文件F1、F2和F3分别包含如下信息。

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

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

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

如果用文件管理数据,用户必须编写应用程序来管理存储在文件中的数据,其操作模式如图1-1所示。

图1—1 文件管理的操作模式

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

设A1为实现“学生基本信息管理”功能的应用程序,A2为实现“学生选课管理”功能的应用程序。由于学生选课管理中要用到F1文件中的一些数据,为减少冗余,它将使用“学生基本信息管理”(即F1文件)中的数据,如图1-2所示(图中省略了操作系统部分)。

图1—2 文件管理实现示例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(7)无安全控制功能。在文件管理方式中,很难控制某个人对文件容许的操作,比如只允许某个人查询和修改数据,但不能删除数据,或者对文件中的某个或者某些字段不能修改等。而在实际应用中,数据的安全性是非常重要且不可忽视的。比如,在学生选课管理中,我们不允许学生修改其考试成绩。在银行系统中,更是不允许一般用户修改其存款数额。针对文件管理方式的这些缺陷,人们逐步开发出了以统一管理和共享数据为主要特征的数据库管理系统。