关于数据仓库的数据模型的研究

业务驱动

任何需求均来源于业务 , 业务决定了需求 , 需求分析的正确与否是关系到项目成败的关键所在 , 从任何角度都可以说项目是由业务驱动的所以数据仓库项目也是由业务所驱动的 。

但是数据仓库不同于日常的信息系统开发 , 除了遵循其他系统开发的需求 , 分析 , 设计 , 测试等通常的软件声明周期之外 ; 他还涉及到企业信息数据的集成 , 大容量 数据的阶段处理和分层存储 , 数据仓库的模式选择等等 , 因此数据仓库的物理模型异常重要 , 这也是关系到数据仓库项目成败的关键 .

数据仓库的结构总的来说是采用了三级数据模型的方式 :

概念模型 : 也就是业务模型 , 由企业决策者 , 商务领域知识专家和 IT 专家共同企业级地跨领域业务系统需求分析的结果 .

逻辑模型：用来构建数据仓库的数据库逻辑模型。根据分析系统的实际需求决策构建数据库逻辑关系模型 , 定义数据库物体结构及其关系。他关联着数据仓库的逻辑模型和物理模型这两头 .

物理模型：构建数据仓库的物理分布模型 , 主要包含数据仓库的软硬件配置 , 资源情况以及数据仓库模式。

 

如上图所示 , 在数据仓库项目中 , 物理模型设计和业务模型设计象两个轮子一样有力的支撑着数据仓库的实施 , 两者并行不悖 , 缺一不可 . 实际上 , 我有意的扩大了 物理模型和业务模型的内涵和外延 . 在这里物理模型不仅仅是数据的存储 , 而且也包含了数据仓库项目实施的方法论 , 资源 , 以及软硬件选型等等 ; 而业务模型不仅 仅是主题模型的确立 , 也包含了企业的发展战略 , 行业模本等等 .

一个优秀的项目必定会兼顾业务需求和行业的标准两个方面 , 业务需求即包括用户提出的实际需求 , 也要客观分析它隐含的更深层次的需求 , 但是往往用户的需求是 不明确的 , 需要加以提炼甚至在商务知识专家引导下加以引导升华 , 和用户一起进行需求分析工作 ; 不能满足用户的需求 , 项目也就失去原本的意义了 .

物理模型就像大厦的基础架构 , 就是通用的业界标准 , 无论是一座摩天大厦也好 , 还是茅草房也好 , 在架构师的眼里 , 他只是一所建筑 , 地基 -> 层层建筑 -> 封顶 , 这样的工序一样也不能少 , 关系到住户的安全 , 房屋的建筑质量也必须得以保证 , 唯一的区别是建筑的材料 , 地基是采用钢筋水泥还是石头 , 墙壁 采用木质还是钢筋水泥或是砖头 ; 当然材料和建筑细节还是会有区别的 , 视用户给出的成本而定 ; 还有不可忽视的一点是 , 数据仓库的数据从几百 GB 到几十 TB 不 等 , 即使支撑这些数据的 RDBMS 无论有多么强大 , 仍不可避免的要考虑到数据库的物理设计 .