数据库(5)---数据库系统的实现

【声明】本文章来自穆晨 - 博客园，记录于此方便后期的学习和查阅

一、前言

虽说数据库系统的具体实现因业务环境，RDBMS等因素而异，但总体开发流程，以及开发过程中所涉及到的一些问题，也具有不少统一的套路、标准。

本文主要讨论数据库系统实现过程中的重点环节、基本开发流程、数据库管理以及数据质量工程等话题。

二、参照完整性约束对更新删除操作的影响

在第3篇中已经讨论过，关系设计的目的就是为了减少冗余，消除更新异常。但当时也留下一个问题：外码冗余时，该如何解决呢？

关系数据库理论将外码冗余的问题交给了RDBMS，让它来解决涉及外码的更新异常。如下存在外码的关系中： 关系EMPLOYEE中的Dept属性是一个外码，它对应DEPARTMENT关系的主码。如果对该属性进行更新或者删除，那么这个外码就找不到它对应的主码，两个关系的联系就被破坏了。针对这个问题，RDBMS的解决方案有四个，下面以删除异常为例进行说明：

• 限制删除：指如果某记录主码被另一个记录外码对应，则该记录不允许被删除。如上面示例DEPARTMENT关系中的记录在删除的时候有可能被RDBMS禁止。

• 级联删除：指如果某个记录的主码被另一个记录的外码对应，那么这两个记录将一起被删除。

• 设置为空：指如果某个记录的主码被另一个记录的外码对应，那么在删除这个记录后，另外那个记录的外码字段设置为空。

• 设置默认值：同“设置为空”，不过是将设置为空改为设置成一个默认值。

更新情况和删除一样，要注意的是所有处理都发生在对外码映射中的非外码关系进行操作时发生。这些处理主要是对外码关系进行附加操作，如级联删除，置空，置默认值，或者报错。

三、索引机制

索引(index)机制的本质是一种检索加速机制，本文将从索引的逻辑意义上对它进行解析，至于其在各RDBMS里的物理实现细节则不做介绍。如下客户关系表中： 由于CustID是按顺序排列的，如果要检索某CustID值对应的记录，可使用多种查找算法提高检索效率，如二分查找等。但关系中某一列排好序以后，其他列必然是乱序的，那如何解决？在RDBMS中，这种情况可以通过新建一个只包含两列的附加表来实现：

索引表中，其中一列为索引字段，另一列则包含一个指针指向原纪录。这样在对索引列进行查询的时候，RDBMS会先对索引表进行操作，完了再映射到原表并返回结果。

从本质上来说，这是一种牺牲空间换取时间的办法，索引建立不单耗费存储资源，而且会降低更新、删除等操作的效率。因此不是说建的索引越多就越好，具体建立何种索引，建立多少索引，则要取决于计算资源，RDBMS，业务场景等因素。

四、触发器机制

触发器是一种规则，当关系中删除、插入、修改一条记录的时候执行。它的应用场景很多，如：每次向关系表中插入记录后，更新记录总数，如果超过了n，则不再插入数据。几乎所有RDBMS都提供了该功能。

触发器的代码，不是标准SQL代码，不必细究。触发器实现代码的语法规则取决于RDBMS，需要时再有针对性的参考手册即可。

五、数据库系统开发流程

数据库系统(database system)：指让用户和数据库信息之间进行有效交互的计算机系统。其典型的框架如下图所示：

数据库系统的三大主要部分：数据库、数据库管理软件(RDBMS)、前端应用程序(Web/APP等)。

数据库是数据库系统的核心，负责存放所有数据。而数据库对外的所有交互，均通过RDBMS来进行。一般用户通过前端应用程序使用RDBMS，而比较专业的用户也可直接使用RDBMS操纵数据库。

举例来说，某人通过APP订购商品，那么这个APP就是前端应用程序，而当她有一个具体行为，比如付款的时候，前段应用程序就会和RDBMS通信，让RDBMS完成扣款，并返回操作执行结果。

数据库系统的开发流程，总体可以划分为以下几个步骤：

1. 数据库需求

需求搜集是所有环节中最重要的一步。通常，都会通过ER图进行表示，并和各业务方讨论搜集得到，最终整理成文档。这些需求将指导后面的工作，如：需求建模、数据库实现、以及前端应用程序开发等。

特别强调，数据库系统开发需求阶段，其过程是循环迭代式的，一开始的需求集并不大，但随着项目的进展，需求会越来越多。但不论是以上哪个阶段发生了需求变动，整个流程都需要重新走一遍，决不允许隐式变更需求。

2. 数据库建模

数据库建模阶段，即逻辑模型建模，在本系列文章的第2篇已详细讲解，这里不再赘述。

3. 数据库实现

这一步的本质就是在空的RDBMS里实现2中创建的关系模型，一般通过使用SQL或者RDBMS提供的前端工具实现。

4. 开发前端应用程序

前端应用开发，在需求搜集好之后就开始进行了，主要有网站、APP等前端形式，由于前端程序的实际实现涉及到和数据库之间交互，因此这一步的最终完成在数据库建模之后。

5. 数据库部署

这一步就是部署数据库系统的软硬件环境。还包含将初始数据填入数据库中。对于云数据仓库，这一步就叫"数据上云"。

6. 数据库使用

7. 数据库管理和维护

严格来讲，这部分不算开发流程，属于数据库系统开发完成后的工作。接下来本文将围绕这个话题进行讲解。

六、数据库系统管理

数据库系统发行后，控制权便从数据库设计、实现、部署的团队，移交给了数据库管理员(database administrator, DBA)，并由他们来对系统进行管理。

数据库管理涵盖了确保一个已经部署的数据库系统正确运行的各种行为。主要包含以下范畴：

这部分工作的涉及面相当广而深，应由专业的DBA团队去完成。本文主要针对人群是数据科学家，因此仅对这些工作做一个简明的介绍。

1. 数据库系统监测与维护

DBA需要监测数据库系统的运行情况，并针对发现的问题进行维护。比如发现存储资源不够用了，则要分配给数据库系统更多存储空间等。

DBA需要掌握数据库中各关系的具体使用情况，从而进行优化。比如某两个表被很多用户频繁使用，并只用来重复创建相同的报表。这时候DBA就可以考虑建议数据库开发团队反规范化设计的将这两个表合并到一起。

2. 数据库安全保障

安全保障工作，是数据库系统管理工作中的首要任务，该任务需要DBA对数据的存取过程严加控制，包括：数据库访问人员的账户认证、权限划分、敏感数据的加密等。

3. 数据库备份与恢复

数据库的数据，是存放在计算机的物理磁盘里，而计算机对数据的处理过程，都是先把数据从硬盘转移到内存，处理完后再存放回去。

如果数据在内存中进行处理，还没有将数据转移回磁盘的时候，数据库挂了的话就将导致数据丢失。因此RDBMS采用恢复日志(recovery log)机制，先记录更新操作要做的事情，比如那个数据被更新，更新前后的值，更新请求的用户等，然后再做具体的更新操作。在更新日志中可以设置"检查点"，之后DBA可使用它进行周期性副本备份。失效事件发生之后，DBA可以利用"检查点"进行系统恢复：回滚(Roll Back)至指定检查点状态。

对于那种彻底性毁坏的情况，比如发生火灾、地震等，可在多个不同物理站点上保留完全镜像备份(complete mirrored backup)。这些副本需持续更新保证与数据库系统一致。

4. 数据库性能优化

性能优化包括：设置索引、逆规范化、SQL优化等，通常用QPS(query per second)等指标来衡量数据库系统的优化效果。

这部分工作内容很多也比较杂，主要通过DBA管理RDBMS的查询优化器来完成。但对于数据库的开发员和使用者来说，也多多少少要知道一点，比如写Hive语句时，需要灵活设置分区，避免数据倾斜等。

5. 数据库标准制定

这部分工作包括数据库中字段命名规范、SQL编码规范的制定等。除了这些开发标准，还有使用标准，比如使用数据库的人需要遵守哪些有益于数据库系统健康的行为规范等。

七、数据质量体系

数据库系统，以及数据仓库系统，都需要始终重视数据质量问题。一句话概括：数据质量就是衡量数据能否真实、及时反映客观世界的指标。

具体来说，数据质量包含以下几大指标：

1. 准确性

准确性要求数据能够正确描述客观世界。比如某用户姓名拼音mu chen，错误的录入成了muc hen，就应该弹出警告语。

2. 唯一性

唯一性要求数据不能被重复录入，或者不能有两个几乎相同的关系。比如张三李四在不同业务环境下分别建立了近乎相同的关系，这时应将这两个关系合并。

3. 完整性

完整性要求进行数据搜集时，需求数据的被描述程度要高。比如一个用户的购买记录中，必然要有支付金额这个属性。

4. 一致性

一致性要求不同关系、或者同一关系不同字段的数据意义不发生冲突。比如某关系中昨天存货量字段+当天进货量字段-当天销售量字段等于当天存货量，否则就可能是数据质量有问题。

5. 及时性

及时性要求数据库系统中的数据"保鲜"。比如当天的购买记录当天就要入库。

6. 统一性

统一性要求数据格式统一。比如nike这个品牌，不能有的字段描述为"耐克"，而有的字段又是"奈克"。

数据质量和数据具体意义有很大相关性，因此无法单凭数据库理论来保证。且由于具体业务及真实世界的复杂性，数据质量问题必然会存在，不可能完全预防得了。因此很多RDBMS或第三方公司都提供了数据质量工程服务/软件，用来识别和校正数据库系统中的各种数据质量问题。