范式建模维度建模比较.docVIP

范式建模维度建模 一、 范式建模 这样的设计方式是在关系型数据库中常用的， Inmon 的范式建模法的最大 优点就是从关系型数据库的角度出发，结合了业务系统的数据模型，能够比 较方便的实现数据仓库的建模。 1.1 范式化模型设计需满足下面三大范式： 1.1.1 第一范式（ 1NF）: 原子性 字段不可再分 , 否则就不是关系数据 库; 1.1.2 第二范式（ 2NF）: 唯一性 一个表只说明一个事物 ; 1.1.3 第三范式（ 3NF）: 每列都与主键有直接关系，不存在传递依赖 ; 1.2 特点： 同一份数据只存放在一个地方，因此只能从一个地方获取，没有数 据冗余，保证了数据一致性； 解耦（系统级与业务级），方便维护； 设计思路自上而下，适合上游基础数据存储，同一份数据只存储一 份，没有数据冗余，方便解耦，易维护，缺点是开发周期一般比较 长，维护成本高； 二、维度建模 维度建模是一种将数据结构化的逻辑设计方法，它将客观世界划分为度量 和上下文。 度量是常常是以数值形式出现， 事实周围有上下文包围着， 这种上下 文被直观地分成独立的逻辑块， 称之为维度。 维度建模是面向分析， 为了提高查 询性能可以增加数据冗余，反规范化的设计技术。 2.1 特点： 模型结构简单，星型模型为主 开发周期短，能够快速迭代 维护成本较高 维度建模是面向分析， 为了提高查询性能可以增加数据冗余， 反规范化的设计技 术 设计思路是自下而上， 适合下游应用数据存储， 适合统计多层次维度的汇总， 开 发周期短，缺点是维护成本高 2.2维度建模的常见模式 2.2.1 星形模式 星形模式 (Star Schema) 是最常用的维度建模方式， 下图展示了使用星形模式 进行维度建模的关系结构： 维度 C维度 B FK FK 维度 D FK FK维度 A 事实表 FK FK 维度 E ? ?. 可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点： a.维表只和事实表关联，维表之间没有关联； b. 每个维表的主码为单列，且该主码放置在事实表中，作为两边连 接的外码； c. 以事实表为核心，维表围绕核心呈星形分布； 2.2.2 雪花模式 雪花模式 (Snowflake Schema) 是对星形模式的扩展，每个维表可继续向外连接 多个子维表。下图为使用雪花模式进行维度建模的关系结构： 维度表 B1 FK 维度表 C维度表 B FK FK FK 维度表 B2 维度表 D FK维度表 A FK 事实表 维度表 A1 FK FK 维度表 E ? ?. 星形模式中的维表相对雪花模式来说要大， 而且不满足规范化设计。 雪花模型相 当于将星形模式的大维表拆分成小维表， 满足了规范化设计。 然而这种模式在实 际应用中很少见， 因为这样做会导致开发难度增大， 而数据冗余问题在数据仓库 里并不严重。 2.3 维度建模的设计方法 根据根据业务 确定事实表粒 有了业务过程 选择适用于业 过程的优先级 度，最好是原子 和粒度， 就要选 务过程的事实。 选定业务过程。 级粒度。 择相关的维度。 2.4 维度建模设计流程图 2.5 高层模型设计 日期 订单杂项 订单 产品 客户 2.6 识别维度和度量 有了高层模型，就要设计维度和度量， 维度和度量清单不仅仅是业务用户所关心， 还要从业务过程出发， 自上而下的设计所涉及的维度和度量。 防止业务用户的需 求变化带来的冲击。 2.7 确定命名规范 在详细设计之前， 为DW/BI 系统制定规范， 主要包含源系统、 主题、业务术语、 报表，物理设计命名、调度任务、文档方面的规范 2.8 编写详细设计映射文档 详细设计文档包括从源系统到维度模型的每个数据层的物理映射文档。 2.9. 审查和验证模型 详细设计文档出来后，要和业务用户和团队成员进行评审，记录下来评 审过程中的问题，形成问题清单。 .完成设计文档 最后确定设计文档，进行下一步的 ETL 开发。 参考资料 数据仓库工具箱：维度建模的完全指南（第二版）》 三、优缺点比较 范式建模优点 范式建模缺点 从 关系型数据库的角度出发，结合 由于建模方法限定在关系型数据库 了业务系统的数据模型，能够比较 之上，在某些时候反而限制了整个 方便的实现数据仓库的建模 数据仓库模型的灵活性，性能等， 特别是考虑到数据仓库的底层数据 向数据集市的数据进行汇总时，需 要进行一定的变通才能满足相应的 需求 没有数据冗余， 保证了数据一致性， 缺点是开发周期一般比较长 方便维护 , 方便解耦 维度建模优点 维度建模缺点 维度建模非常直观，紧紧围绕着业 需要进行大量的数据预处理，因此 务模型，可以直观的反映出业务模 会导致大量的数据处理工作 型中的业务问题 开发周期短，能够快速迭代 当业务发生变化，需要重新进