【数据库系统】文件处理系统的弊端

Uma ·

更新时间:2024-11-14

· 695 次阅读

总结

传统文件系统比之数据库系统，有如下七种弊端，要好好理解：

Data redundancy and inconsistency Difficulty in accessing data Data isolation Integrity problems Atomicity of updates Concurrent access by multiple users Security problems Data redundancy and inconsistency 数据的冗余和不一致

由于程序和文件是在很长一段时间内由不同程序员创建的，不同文件可能有不同的结构，不同程序可能由不同程序设计语言写成。相同的信息就可能存储在不同的位置，这种重复存储是一种冗余。

数据的冗余带来的不良反应很多，比较典型的是存储开销和访问开销增大。
更讨厌的是，冗余的数据如若不能被一致地成功更新，带来的可能是数据的不一致，即数据的副本不一致。

在这里插入图片描述

对数据不一致的说明

数据不一致性，是指各类数据的矛盾性、不相容性，主要原因有三：

数据冗余，并发控制不当各种故障、错误

这里我们不提后两种，简单说说数据的冗余为何会使得数据不一致，其实例子是很多的。

还记得开发者为何被建议使用定义好的常量而不是直接使用数值吗？
其实某一个常量值为1，你直接使用1，而很多处使用到。一旦这个1要改成2，你开始翻天覆地的找这个值，遇到一个改一个，最终漏了一两个也不是不可能，然后就出了Bug……

再说一个，假设我们的PC中有很多带有某朋友电话号码的信息表，我们遇到使用的时候就可以直接查看。这种信息被存储在很多很多文件里，大量冗余。有一天，朋友要换号，就需要改这些信息（假设有改的必要），改着改着你要是都改了也就算了，你要是有一天真想不起来，翻来翻去突然发现不一致，你困惑不困惑？

例子不一定很好，但数据的大量冗余确实可能会带来很讨厌的结果，数据的不一致性更令人反感。

Difficulty in accessing data 数据访问困难

假设大学的某个办事人员需要找出居住在某个特定邮编地区的所有学生的姓名，于是他要求数据处理部门生成这样的列表。由于原始系统的设计者并未预料到会有这样的需求，因此没有现成的程序去满足这个需求。但是，系统中却有一个产生所有学生列表的应用程序。这时该办事人员有两种选择：一种是取得所有学生的列表并从中手工提取所需信息，另一种是要求处理部门让某个程序员去编写相应的应用程序。这两种方案显然都不太令人满意。假设编写了相应的应用程序，几天以后这个办事人员可能又需要将该列表减少到只列出至少选修60学时的那些学生。可以预见，产生这样一个列表的程序又不存在，这个职员就再次面临前面那两种都不尽如人意的选择。

这里需要指出的是，传统的文件处理环境不支持以一种方便而高效的方式去获取所需数据。我们需要开发通用的、能对变化的需求做出更快反应的数据检索系统。

在这里插入图片描述

Data isolation 数据孤立

由于数据分散在不同文件中，这些文件又可能具有不同的格式，因此编写新的应用程序来检索适当的数据是很困难的。

在这里插入图片描述

Integrity problems 完整性问题

数据库中所存储数据的值必须满足某些特定的一致性约束。
假设大学为每个系维护一个账户，并且记录各个账户的余额。我们还假设大学要求每个系的账户余额永远不能低于0。开发者通过在各种不同的应用程序中加入适当的代码；来强制系统中的这些约束。然而，当新的约束加入时，很难通过修改程序来体现这种新的约束。尤其是当约束涉及不同文件中的多个数据时，问题就变得更加复杂了。

Atomicity of updates 原子性问题

如同别的设备一样，计算机也会发生故障，比如数据丢失、断电、卡死等等。一旦故障发生，数据就应该被恢复到故障以前一致的状态，对于许多应用来说，这样的保证是至关重要的。

比如A账户向B账户转账1000元，A先扣款，如果此时出现系统故障（别说不可能发生），从A账户划走1000元，但B账户还没收到这1000元数据就丢失了，此时就造成了数据状态不一致（这也是我们说的数据不一致的一种可能）。

我们要想保证这种转账收付款的数据一致性，就可以强制这两个操作要么都发生，要么都不发生。成功则完成，不成功则回滚。也就是说，A付款和B收款被紧紧地“绑定”在了一起，成为了“一个整体”，要么都发生，要么都不发生。由于化学反应中原子是不可分的最小单位，这种特性被称为原子性 ~~（来由是自己猜的）~~ 。传统文件系统中想要保持这种原子性是很难做到的，但数据库的“事务”，支持了ACID（原子性、一致性、隔离性、持久性）。

在这里插入图片描述