所以, 我在这里玩一点话。我当然不主张在数据存储库中锁定任何人或任何东西。在设计和交付新的数据存储库时, 我想分享如何锁定成功。此帖子旨在专门帮助您的开发团队。
我们大多数人都受到变革的挑战。而开发者也没什么不同。他们通常非常舒适的一套设计方法和工具, 过去所学到的, 它经常框架他们的观点, 如何解决未来。将旧方法的舒适性与当今业务需求的紧张时间和压力结合起来, 很少会导致我们花了很久去探索新的选择。因此, 对于团队来说, 通过过时的、限制的数据基础架构的方法来权衡是很容易的。
在过去十年中, 随着数据存储库方法和数据仓库自动化 (DWA) 的演进, 我们所学到的是数据仓库开发过程中的某些区域已经中断。在早期的2000s 中, Dan Linstedt 和数据存储库模型的其他贡献者认识到, 传统数据模型无法满足服务于现代数据集中业务的数据仓库的质量和敏捷目标。
数据存储库是从一些非常仔细定义的基元 (如集线器、链接和附属表) 构造的, 必须以特定的方式来定义和填充, 以便按预期工作。如果开发人员使用旧的方法, 或者更糟的是自己组成新的, 灾难将会随之而来。
在数据存储库2.0 中, Linstedt 提供了一种方法, 用于在数据模型的设计和填充它的函数的开发中驱动最佳实践。方法论是伟大的: 我依靠一个奇妙的方法, 手动提高我的电脑屏幕到理想的高度, 因为我写这篇文章。但是, 在开发团队中, 此类行为将导致不一致的开发方法, 导致将来的维护延迟, 因为其他开发人员难以理解不同的编码方式, 最终导致您的技术损失。组织当你最聪明的开发者死于一个反常的编码事故。
更新后的数据电子仓库通过对数据存储库组件的模板进行编码, 并在自动化、元数据驱动的设计和开发环境中使用人口过程和开发方法的最佳做法来解决这些问题。从 IT 和业务人员之间的初始设计协作开始, 设计选项在元数据中进行编码, 以自动生成负责定义数据存储库表的代码和脚本, 并使用正确的数据填充它们, 确保设计一致性和完整性, 并编码符合单一的一套标准。可追溯性得到执行, 维护得到缓解。此外, 当您的开发人员工作时, 所有文件都自动记录下来–很少有人享受或有时间完成任务。
在数据存储库中锁定是为了保持一致性, 确保完整的文档, 并在设计和开发中自动生成最佳实践模型和代码资产。数据仓库自动化是合乎逻辑的基础, 而改变是困难的, 开发团队将从开放到不同的方式中受益匪浅。