|
|
|
|
移动端

1.2.2 基于文件方法的局限性

《数据库系统:设计、实现与原理(基础篇)(原书第6版)》第1章数据库简介,本章将首先介绍数据库系统。本节为大家介绍基于文件方法的局限性。

作者:宁洪/贾丽丽/张元昭 译来源:机械工业出版社|2017-09-27 14:55

有奖调研 | 1TB硬盘等你拿 AI+区块链的发展趋势及应用调研


1.2.2 基于文件方法的局限性

上述对传统基于文件的系统的简介足以用来讨论这种方法的局限性。表1-1列出了五个方面的问题。

数据被分离和孤立

当数据被孤立在分离的文件中时,访问这些数据变得更加困难。例如,如果想建立一个满足客户要求的所有连体房的列表,那么首先不得不创建一个临时文件,列出所有需要连体房这种户型的客户。然后查阅PropertyForRent文件,查找房产类型为连体房并且租金少于客户最高租金的那些项目。对于文件系统来说,这个过程是非常困难的。应用程序开发者必须保持两个文件访问过程的同步性,以确保提取的数据是正确的。如果需要来自于多于两个文件中的数据,难度还会增加。

数据存在冗余

由于不同部门的各自为战,基于文件的系统导致了失控的数据冗余,必需的冗余除外。例如在图1-5中,可以清楚地看到,在销售部门和合同部门存在房产和客户详细信息的冗余。由于下述原因,失控的数据冗余不受欢迎:

冗余是一种浪费。它需要花费更多的时间和资金录入一次以上数据。

冗余占用更多的存储空间,同时增加与之相关的费用。在许多情况下,数据的冗余可以通过共享数据文件来解决。

也许最重要的是,冗余可能导致数据完整性遭到破坏。换句话说,这些数据可能将不再一致了。例如,让我们考虑一下前面所讨论过的工资发放部门和人事部门之间的数据冗余。如果一个员工搬了住处,只将地址的改变告知人事部门,而没有通知工资发放部门,那么这个员工的工资清单将会被寄到错误的地方。当一个员工升职,工资也随着改变时,如果此时这个变化只通知了人事部门,而没有在工资发放部门登记,情况将会变得更严重。这时,员工将会收到错误的工资。当检测到这种错误时,想要解决这个问题通常要花费很大的努力和很多的时间。这两个例子中介绍的数据不一致性都是由于数据的冗余产生的。因为没有方法可以使人事部门自动更新工资发放部门的数据,这种数据的不一致性是可以预见的。即使工资发放部门知道了这个数据的变化,输入数据时也可能出错。

数据存在依赖性

前面已经提到过,数据文件的物理结构和存储方式是由应用程序定义的。这就意味着,改变已经存在的结构十分困难。比如,欲将PropertyForRent文件中的address数据项从40个字符长增加为41。看似一个很简单的变化,却需要创建一个专门的程序(这个程序可能只运行一次,然后就丢弃),将PropertyForRent文件转换成一种新的格式。这个程序必须:

打开原始的PropertyForRent文件供读取。

打开一个具有新结构的临时文件。

从原始文件中读取一个记录,修改数据,使之与新的格式相符,并将它写入临时文件中。对原始文件中的所有记录重复上述工作。

删除原始的PropertyForRent文件。

将临时文件更名为PropertyForRent。

另外,所有访问PropertyForRent文件的应用程序必须进行修改,以便与新的文件结构相符。可能会有多个程序访问PropertyForRent文件。程序员需要找到所有受到影响的程序,一一修改它们,然后重新进行测试。注意,这其中有的程序可能从未用到修改的address数据项,而仅仅是使用了PropertyForRent文件。很明显,这是一件很浪费时间并且极易出错的工作。基于文件系统的这个特性就是所谓的程序-数据依赖性。

文件格式不相容

因为文件的结构是嵌入到应用程序中的,因此这个结构取决于应用程序使用的语言。例如,用COBOL语言编写的程序所形成的文件结构与用C语言编写的程序所形成的文件结构是不同的。这种文件的直接不相容性使它们很难联合运行。

例如,设想一下合同部门想要找出所有的业主姓名和地址。然而遗憾的是,合同部门没有保留业主的详细信息,只有销售部门保留这些信息。然而合同部门拥有房产编号(propertyNo),可以用这个编号找到销售部门的PropertyForRent文件中相对应的房产编号。这个文件中还有业主编号(ownerNo),可以再利用这个编号找到PrivateOwner文件中业主的详细信息。假设合同部门的程序是用COBOL语言编写的,而销售部门的程序是用C语言编写的。那么,为了使两个PropertyForRent文件中的propertyNo相匹配,就要求应用开发人员专门编写一个软件,将这些文件转换成公共的格式以完成上述处理过程。同样,这件工作也是相当耗时且昂贵的。

查询一成不变/应用程序需不断翻新

从终端用户的观点看,基于文件的系统比手工系统有了很大的进步。很自然,用户又提出新的需求或者要求修改原有查询。然而,基于文件的系统是完全依赖应用开发人员的,由应用开发人员编程实现所有要求的查询和报表。这将会产生两种结果。在一些单位中,查询或报表的类型是固定的。没有办法满足那些未列入计划的查询(即突发奇想的查询),无论是查询数据本身还是查询哪类数据可用。

而在另一些单位中,不断翻新文件和应用程序。最后发展到数据处理部门不堪重负,仅用现有的资源已不能完成所有的工作。这样会给数据处理部门的员工增加很大的压力,结果导致程序不能或者不能高效地满足用户要求,还将导致文档不全、维护困难等。通常情况下,下列某类功能不得不被舍弃:

不能提供安全性和完整性保护。

当硬件或软件故障发生时,不能恢复或者恢复受限。

在某一时刻只允许一位用户对文件进行访问,不支持同一个部门的员工对文件的共享访问。

上述任何一种情况都是不可接受的,因此我们需要另外一种数据管理的解决方法。

喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书频道活动讨论群:365934973

【责任编辑:book TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

C#和.NET核心技术

本书重点讲解如何用实用的代码来解决具体的实际问题。本书的内容覆盖面很广,从新的C#范型到Web服务,从反射到安全等都有涉及。系统地介绍...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊