认识达内从这里开始

我们在前几期的文章中给大家简单介绍了数据仓库的一些基础知识与应用分析等内容，而本文我们就继续来学习一下，数据仓库开发流程步骤分享。

数据仓库的开发流程和数据库的比较相似，因此本文仅就其中区别进行分析。

数据仓库需求

需求搜集是所有环节中重要的一步，吃透了用户需求，往往就成功了大半。这些需求将指导后面如需求建模、实现、以及前端应用程序开发等。通常来说，需求都会通过ER图来表示(参考数据库需求与ER建模)，并和各业务方讨论搜集得到，终整理成文档。

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

数据仓库建模

也就是逻辑模型建模，可参考二篇：数据库关系建模

ER建模环节完成后，需求就被描述成了ER图。之后，便可根据这个ER图设计相应的关系表了。

但从ER图到具体关系表的建立还需要经过两个步骤：1.逻辑模型设计2.物理模型设计。其中前者将ER图映射为逻辑意义上的关系表，后者则映射为物理意义上的关系表。

逻辑意义上的关系表可以理解为单纯意义上的关系表，它不涉及到表中字段数据类型，索引信息，触发器等等细节信息。

概念模型VS逻辑模型

我们先可以认为【概念模型建模和ER建模，需求可视化】表达的是一个意思。在这个环节中，数据开发人员绘制ER图，并和项目各方人员协同需求，达成一致。由于这部分的工作涉及到的人员开发能力比较薄弱，甚至不懂开发，因此ER图必须清晰明了，不能涉及到过多的技术细节，比如：要给多对多联系/多值属性等多建一张表，要设置外码，各种复合主码等，它们应当对非开发人员透明。而且ER图中每个属性只会出现一次，减少了蕴含的信息量，是更好的交流和文档化工具。在ER图绘制完毕之后，才开始将它映射为关系表。这个映射的过程，就叫做逻辑模型建模或者关系建模。

还有，ER模型所蕴含的信息，也没有全部被逻辑模型包含。比如联系的自定义基数约束，比如实体的复合属性，派生属性，用户的自定义约束等等。因此ER模型在整个开发流程(如物理模型建模，甚至前端开发)中是都会用到的，不能认为ER模型转换到逻辑模型后就可以扔一边了。

逻辑模型VS物理模型

逻辑模型设计好后，就可以开始着手数据仓库的物理实现了，他也被称为物理模型建模，这个阶段不但需要参照逻辑模型，还应当参照ER图。

数据仓库实现

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

开发前端应用程序

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

ETL工程

较之数据库系统开发流程，数据仓库开发只多出ETL工程部分。然而这一部分极有可能是整个数据仓库开发流程中为耗时耗资源的一个环节。因为该环节要整理各大业务系统中杂乱无章的数据并协调元数据上的差别，所以工作量很大。在很多公司都专门设有ETL工程师这样的岗位，大的公司甚至专门聘请ETL。

数据仓库部署

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

数据仓库使用

这一步没啥多讲的，就再讲一个有关的故事吧。同样是在A公司，有一次某政企私有云项目完成后，我们有人被派去给他们培训如何使用。结果去的人回来后说政企意见很大，认为让他们学习SQL以外的东西都不行。拒绝用Python写UDF，更拒绝MR编程接口，只要SQL和图形界面操作方式。一开始我对政企的这种行为有点看不起，但后来我想，就是因为有这群挑剔的用户，才使得A公司云产品的易用性如此强大，从而占领国内云计算的大部分市场。用户的需求才是技术的试金石。

数据库管理和维护

严格来讲，这部分不算开发流程，属于数据库系统开发完成后的工作。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。