数据库重构在软件开发中的应用范文

本站小编为你精心准备了数据库重构在软件开发中的应用参考范文，愿这些范文能点燃您思维的火花，激发您的写作灵感。欢迎深入阅读并收藏。

1数据库重构条件

数据库重构不仅适用于新数据库开发，也适用于正在进行维护和修改的现有数据仓库。在数据库重构过程中要高度结构化和安全化，确保被其支持的应用程序正常运行。出现如下情形时数据库必须重构。

（1）有太多的行和列数据库中的表展现了其在性能方面存在的问题，通常数据库包含一些含有10多亿行的表，像这种情形可能更适用于分段数据库或系统记录资料库。

（2）出现多功能表和多用途列用于数据语义的列在很多情况下取决于上下文是否需要重构。例如，使用一个数据列存储用户生日还是雇员日期，取决于记录指代的是一个用户还是一个雇员。表缺乏内聚力，其中的一列不能完全明确用途，试图存放来自多个不同实体的数据，这种情况下需对列进行处理。（3）存在冗余信息重复数据展现了数据不一致的可能性，例如，在多个源数据系统中客户信息是重复的，解决数据重复是数据库的功能之一。

（4）存在复杂的ETL现象当ETL包中存在太多流动路径和复杂的变换节点时，故障排除和维护就变得困难。围绕这些多用途的ETL对象，编写测试用例会很困难，因此，建立简单、单一用途的ETL对象集合并使用序对象链接它们是非常可取得。

（5）存在大型SQL模块当一个SQL脚本或者预存程序视图完成太多内容时，它经常会是一个很大的、包含多个SQL语句的脚本。这样的脚本存在着代码重复的风险，所以应该分解为一小组独立的、高内聚低耦合的模块。

（6）存在不符合的维度有两个或两个以上维度，并包含重叠数据的多维度数据模型会引起数据重复和不一致性，必须创造单一的、多功能的维度来避免这个问题。

（7）滥用物化视图有索引的视图或物化的视图是现代关系型数据库管理系统的一个很强大的功能。明智地使用，它们可以是数据存取和基表物理实现之间的一个有效缓冲区。然而，滥用物化视图会严重地混淆数据库设计。

（8）物化视图利用不够如果数据库仅仅依赖访问基表，那么就存在脆弱性的风险。也就是说，这些基表物理实现的轻微变化，会对这些基表的不同访问器产生意想不到的效应。物化视图的选择需要在查询性能、视图维修成本和基表灵活性之间取得适当的平衡。

（9）过度依赖文档数据库中的表、列、脚本、预存程序、ETL模块和其他组件，如果在没有所附文件的情况下难以理解，那么表明它们可能需要重构。和软件一样，数据库中的组件需要自我记录和自我解释。干净的设计可以减少对文档的需求。

2如何重构

（1）验证重构是否适当首先应思考如下问题：①这个重构有意义吗？②现在所做的修改真的需要吗，是否可向后推迟？③修改后在哪些方面得到优化？

（2）选择适当的重构一旦确定要进行重构，一定要选择一个适当的重构。有时候需要评估对重构可能产生影响的数据模型等其他领域。例如，某一个项目团队可能希望引入列在财务表中添加结余，但是没有意识到客户表中已经存在表示结余的列，在这种情况下，移动列将是一个最合适的重构。

（3）弃用原有的架构当用一个产出的数据仓库重构一个数据模型时，可能需要建立一个过渡或折旧时期，确保所有BI应用能够正常地工作。在此期间，原始架构和重构架构并行运行。一个BI应用使用原始架构或新架构，但不是两个都使用。两个架构的数据必须同步，以确保BI应用无论使用哪个架构都能正常工作。在折旧期，BI应用被修改，并从过时的架构移动到新的架构。最后，过时的架构下线，开始最终测试，确保没有数据损坏。折旧的过程需要尽可能自动化，以确保重构期间无缝转变。

（4）在之前、之中、之后测试安全更改数据模型的唯一方法是有一个健康的在任何时候均可运行和重复运行的测试组，并与更改紧密相连。在开始更改之前，要确保所有测试全部通过，并评估测试组的完整性，增加任何希望拥有的测试用例。测试BI应用数据架构的所有方式。此外，要创建一个测试组来验证数据迁移策略。测试所有BI应用，确保它们在数据或者行为中不发生更改。最为重要的是，为新引入的架构更改增加新的测试，删除过时或无关的测试。测试自动化是在整个数据库重构过程中唯一可行的测试或复验方法。

（5）修改数据库架构可使用小的、高度凝聚的、脚本化的变化来实现已经计划了的重构。使用测试驱动数据库开发方法进行很小的测试，建立一个可以持续使用的回归测试组。编写完新代码并通过新测试，检查这些更改已经在版本控制系统中。

（6）迁移源数据许多重构需要把数据从旧架构迁移到新架构中，尤其当重构是一个产出的数据仓库时。移动数据重构是专门针对此项而进行的设计。但有时候，如何提高数据质量是重构的一个目标，可进行一个或多个数据质量重构，例如，采用标准版本或者引入通用格式这样的重构。数据迁移也应该编写脚本，但其需要经过测试，以证明支持数据迁移。

（7）重构外部访问程序通常这涉及让BI应用适应新架构，但也有可能涉及修改访问数据仓库的自定义程序。修改这些外部程序需要遵循规范的重构步骤。

（8）运行所有测试所有测试都必须在重构前进行，所有在重构过程中添加的新测试也需要在完成重构之后全部通过。理想情况下，让所有测试自动化进行，并且在重构期间重复第运行它们。

（9）控制版本确保向版本控制系统提交所有修改过的文件和新文件，包括任何新部署或修改过的脚本或ETL对象、测试数据、生成代码、测试用例、文档和模型。

（10）宣布重构向数据仓库和商业智能团队中的每个人宣传重构。除了直接访问数据仓库内部架构的所有团体之外，确保所有人都正确地使用新架构。

3结论

对数据库进行重构时，最重要的是持续确保完备数据建模原则所提供的架构和这种自适应方法提供的灵活性之间的平衡。如果健全的前期设计使用不足且过渡依赖重构，那么就可能会导致不必要的返工。相反地，适当的返工会得到更好、更合适的数据库设计选择。

作者：张如云 单位：徐州机电工程高等职业学校