二 数据库结构不完整

    在非线编辑系统中，数据库显然是整个系统的核心。它就像一本账本，记录了所有设备的使用情况、历史记录、用户信息、系统状态……任何操作都离不开数据库应用。

    现在的非线编基本上都在网络环境中工作，很少会有电视台只采用单机工作的模式。“网络”就意味着多个用户同时对某一共享资源同时进行使用或修改。多个用户同时对同一数据库进行读写工作，当系统的同步措施和安全机制出现问题时，就会产生数据不一致性错误。

    就以我台目前使用的某厂商的产品举例来说，在实际使用过程中，数据库数据经常会出现不一致性错误。为了便于管理，系统设计者要对节目素材的数据量进行统计，这包括总量和每个用户的数据量，统计的结果会记录在数据库相应的数据表中。当各个用户在自己的空间大小范围内上载素材时，系统允许上载；一旦某个用户所用的数据空间超出了预先分配给他的空间总量，系统便拒绝任何上载操作。但是实际应用中发现，经常发生用户实际所用数据空间早已经大大超出了预定值，然而数据库中却记录了错误的信息，该用户仍然可以上载数据；或是出现相反的情况，用户已经自己删除了所有数据，系统仍然拒绝该用户上载，原因是 “空间已满”。

    数据库，顾名思义，是存放数据的仓库。只不过这个仓库是在计算机存储设备上，而前数据是按一定的格式存放的。人们收集并抽取一个应用所需的大量数据之后，应将其保存起来以供下一步加工处理，进一步抽取有用的信息。它是长期储存在计算机内的、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型组织、描述和储存，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享。

    数据的处理是指对各种数据进行收集、存储、加工和传播的一系列活动的总合。数据管理则是指对数据进行分类、组织、编码、存储、检索和维护，它使数据处理的中心问题。

    目前非线编辑系统数据库中采用的多是关系模型，关系模型的完整性规则是对关系的约束条件。只有符合这种完整性规则的数据库才能说它的结构是比较安全的。关系模型中可以有三类完整性约束：实体完整性、参照完整性和用户定义完整性。其中实体完整性和参照完整性是关系模型必须满足的完整性约束条件，被称作是关系的两个不变性。

    简单解释即是：

    * 实体完整性：数据表的主键（primary key）不为空；

    * 参照完整性：外键（foreign key）应取主键的值或空值；

    * 用户定义完整性：系统应对数据库中的值的范围进行校验。

    为了减少数据库中的数据冗余，设计数据库时应规范化。规范化的直接目的就是为了减少插入异常和删除异常（这些异常导致数据库在使用中出现各种错误）。通常按属性间依赖情况来区分关系规范化的程度为第一范式、第二范式、第三范式和第四范式等。

    数据依赖是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系。最主要的是函数依赖（Functional Dependency）和多值依赖（Multi-valued Dependency，简称MVD）。

    关系数据库中的关系是要满足一定要求的，满足不同程度要求的为不同范式。满足最低要求的叫第一范式，简称1NF。

    从范式来讲，主要是E.F.Codd做的工作，1971年~1972年他系统地提出了1NF，2NF，3NF的概念，讨论了规范化的问题。1974年，Codd和Boyce又共同提出了一个新范式，即BCNF。1976年Fagin又提出了4NF。后来又有人提出了5NF。

    建立一个结构合理的数据库是第一部，接下来很重要的工作就是合理安排对数据库的操作程序。当系统运行时出现错误需要恢复数据时，又引出一个新的问题，即数据库恢复技术。

    尽管数据库系统中采取了各种保护措施来防止数据库的安全性和完整性被破坏，保证并发事务的正确执行，但是计算机系统中硬件的故障、软件的错误、操作员的失误以及恶意的破坏仍是不可避免的，这些故障轻则造成运行事务非正常中断，影响数据库中的数据的正确性，重则破坏数据库，使数据库中全部或部分数据丢失，因此数据库管理系统必须具有把数据库从错误状态恢复到某一已知的正确状态（亦称为一致状态或完整状态）的功能，这就是数据库的恢复。

    恢复子系统是数据库管理系统的一个重要组成部分，而且还相当庞大，常常占整个系统代码的百分之十以上。数据库系统所采用的恢复技术是否行之有效，不仅对系统的可靠程度起着决定性作用，而且对系统的运行效率也有很大影响，是衡量系统性能高低的重要指标。

    那么是什么引起故障呢？总结有几类：事务内部的故障，一般指事务没有达到预期的终点，在正常终止前被中断；系统故障，例如系统错误、停电等引起的错误；介质故障，如硬盘损坏；计算机病毒。

    恢复机制涉及的两个关键问题是：如何建立冗余数据；如何利用这些冗余数据实施数据库恢复。

    建立冗余数据最常用的技术是数据传储和登录日志文件。数据传储即管理员定期对数据库进行备份；日志文件是用来记录事务对数据库的更新操作的文件。不同数据库系统采用的日志文件格式并不完全一样。

    为保证数据库是可恢复的，登记日志文件时必须遵循两条原则：

    * 登记的次序严格按并发事务执行的时间次序；

    * 必须先写日志文件，后写数据库。

    当出现错误后，系统的恢复步骤是：

    * 反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作；

    * 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写入数据库。这样，如果记录中是插入操作，则相当于做删除操作（因此时“更新前的值”为空）；若记录中是删除操作，则做插入操作；若是修改操作，则相当于用修改前值代替修改后值；

    * 继续发向扫描日志文件，查找该事务的其他更新操作，并作同样处理；

    * 如此处理下去，直至读到此事务的开始标记，事务故障恢复完成。

    为了尽量减少错误的发生，要在系统设计时做好同步机制、并发控制机制。数据库是一个共享资源，可以供多个用户使用。当多个用户并发地存取数据库时就会产生多个事务同时存取统一数据的情况。若对并发操作不加控制就可能会存取和储存不正确的数据，破坏数据库的一致性。

    并发操作带来的数据不一致性包括三类：丢失修改（Lost Update）、不可重复读(Non-Repeatable Read)和读“脏”数据(Dirty Read)。这三类数据不一致性的主要原因是并发操作破坏了事务的隔离性。并发控制就是要用正确的方式调度并发操作，是一个用户事务的执行不是其他事务的干扰，从而避免造成数据的不一致性。

    目前国内市场上众多厂商推出的非线编辑系统在数据库设计上并没有一个统一的标准，即便是同一厂商不同时期推出的产品也没有一个统一标准。同一品牌的新系统对交早版本的数据库也完全不兼容，甚至所用的数据库系统开发工具都不一样，所以在每个版本中都会对数据库结构重新进行调整。

    当然，结构的调整并不是随意的，这种调整是对整个系统的不断优化。但是由于缺乏统一的设计思想，不同时期开发人员的变动也很大，所以数据库结构不断无序地被改变，设计随意性较大，总会出现这样那样的不尽如人意的地方，甚至是BUG。

    某个具体系统的开发过程中，厂商往往是针对大客户的需求来进行开发。最终用户过多地参与，在这期间他们出于各种需要，往往在开发的过程中临时提出新的修改方案。（殊不知数据库结构的任意调整是数据库设计中的大忌，一般来说数据库结构一旦确定就不能再更改，要么就重做。）但出于工期、资金等因素的考虑，很多设计者又不愿意重做，就只能在原有基础上多次修改。于是本来就不那么严谨的结构变得千疮百孔，补丁叠着补丁，试想如此的结构怎能保证不出问题。

    另一方面，很多厂商开发的产品完成度不佳。什么意思呢？对于一个成熟的产品，不单要求整个系统有完整的结构，而且要求这个系统在安装、调试、运行以及修复等方面能做到自动化设置，并且结构严谨。

    目前各个厂商所开发的产品在安装过程中不能做到无人值守，往往需要开发人员作现场调试，才能安装使用。

    安装后又要作大量专业化设置，如修改注册表、建立数据源、作磁盘映射、设置数据库路径、安装补丁等等。其实这些工作本应由安装程序自动完成，可是由于产品开发时所遗留各种问题，且整个系统不完备，造成很多收尾工作无法完成。

    很多产品没有自动检测功能，当系统出现错误时，无法自动检测出故障原因，系统很难及时恢复。如果由于软件问题出了错误，用户很难及时纠正，这时必须由系统开发人员对问题进行分析。

    由于系统不完整，并使得系统整体的稳定性比较差，经常会因为一个小问题而引起系统崩溃。例如，很多厂商对开发的产品都作了硬件冗余，即对重要部件作热备份，来提高系统稳定性和安全性。但是由于系统健壮性不够，冗余本身也增加了安全隐患。例如某些产品对主域服务器作双机备份，可是这两个服务器却不能相互协调工作，或者说系统不能自动做出正确的判断，偶尔以错误顺序开启服务器时，系统就会出现“无法确认主域服务器”的错误。

    当然，很多设计者会说本来就告诉你不能以错误顺序开机，出现这种错误属操作不当。这绝对是一种推卸责任的说辞，一个完备的系统本来就应当对错误操作进行提示或修正。实际的应用环境其实是很复杂的，或者说是很苛刻的，成熟的系统必须能经得起各种严酷环境的考验，乃至人为的一些不当操作。很多软件产品在出厂前都需要经历各种严格的测试，不断提高系统对苛刻环境适应性，保证系统正常运转。以用户“操作不当”为说辞，是不能接受的。