电信数据仓库设计ppt课件.pptVIP

陕西电信综合数据仓库平台总体设计方案 议程 概述 功能架构 数据架构 ETL架构 集成架构 安全架构 平台架构 实施方法论 总体架构 整体目标 打破信息孤岛，实现数据共享，构建企业数据全集 综合统计分析平台的数据支撑，建立从数据转换为价值的体系，让数据发挥出企业核心资源的效用，实现数据的增值，彻底改善IT对于业务的支撑能力，尤其是对分析决策的支持能力 提供统一的数据支撑和标准规范的对外接口 统一数据管理，保证数据准确和可追踪管理，支持内控，构建企业统一的数据管理平台 系统定位 建设范围 数据范围：企业级数据整合和组织，以支撑综合统计分析平台中各主题分析、分析查询、报表统计等和其它系统的数据需求。 功能范围：数据组织管理、ETL管理、元数据管理、数据质量管理、数据整合等。 与综合统计分析平台-分工界面 议程 概述 功能架构 数据架构 ETL架构 集成架构 安全架构 平台架构 实施方法论 功能架构 逻辑架构 数据获取 数据整合 数据提供 议程 概述 功能架构 数据架构 ETL架构 集成架构 安全架构 平台架构 实施方法论 数据分层设计 业务需求的满足从上到下是分析逐步深入、数据需求细化的过程 数据处理的过程从下到上是粒度加粗、更加面向应用的过程 数据分层是根据数据处理、需求满足过程的特点，并考虑系统效率、数据稳定性而设计的。 临时区 以表的形式存放生产系统传送过来的数据 生产系统包括：统一客户资料、综合受理、计费帐务、综合结算、10000号、财务、IN等 用于进行数据整合的过程处理和异常处理 原则： 采用同生产系统相同的表结构 去掉与分析无关的属性字段 增加时间属性字段 细节数据层的主题域 ER概念模型总图 细节数据层建模 第三范式（ER图） 第三范式要求 1、每个属性的值唯一，不具有多义性； 2、每个非主属性必须完全依赖于整个主键，而非主键的一部分； 3、每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。 不满足第三范式的举例 class(class_id, class_name, teacher_id, teacher_name) 规范化后 class(class_id, class_name, teacher_id) teacher(teacher_id, teacher_name) 总结 确定主键和非主键属性的关系 关注逻辑层面上的实体和关系，不考虑可用性问题 需物化为表后，方可在DW创建、使用 反正则化处理 处理方法 增加冗余列 避免查询时进行表连接操作 增加派生列 避免查询时连接和使用聚合函数 重新组表 提高性能和效率 处理策略 对订单，增加“市场活动ID” 对产品实例，增加“订单ID” 对话单、帐单，除原有的“产品实例ID”，增加“客户ID” 对话单，增加“帐务周期ID、时段ID、开始时间”等 对客户/用户/帐户，分为当前信息表和历史信息表 对话单、帐单，采用按“业务＋本地网”分表的方式 对客户，分为“社会属性ID、自然属性ID、消费属性ID” 其它 汇总数据层 存放数据 资料汇总、清单汇总、关联汇总、宽表等 用途 提高性能，防止大量的细节数据访问 数据沉淀，粒度较粗的数据可以保存更长时间 承上启下，连接数据驱动的3NF细节数据和需求驱动的Star-Schema数据 原则 将客户基础资料变更的时间粒度增粗 对清单/帐单类数据在客户/用户/帐户级别上汇总 对经常使用的关联操作，提前进行关联汇总，以表的形式存放 单条记录包括用户基本信息、产品选择和使用量、费用信息，方便业务人员使用 应用集市层 以多维模型、宽表、3NF等方式存放高度汇总数据 直接支持前端分析应用 应用集市设立的原则： 按相同处理功能：如KPI集市、报表集市等 按业务分析主题：如市场竞争集市、市场营销集市等 按特定分析目的：如数据挖掘集市、收入保障集市等 其它 雪花模式 是对星型模式的扩展（维度） 日期、地区等多层次的维度均可类似扩展 星型模式 一种多维的数据关系，由一个事实表和一组维表组成。 每个维表表达一个维度，所有维度字段组成事实表的复合主键。 事实表的非主属性称为事实，都是汇总出来的数值型数据。维大都是文字、时间等类型的数据 平衡星型和雪花的方法 对仅牵涉到简单的单层维度的事实表，采用星型模式 对牵涉到多层维度但纬度深度仅在一个方向增加的事实表，采用星型模式；在纬度深度超过3层的情况下，采用雪花模式 对牵涉到多层维度且纬度深度在多个方向增加的事实表，采用星型和雪花混合模式 应用集市层建模 议程 概述 功能架构 数据架构 ETL架构 集成架构 安全架构 平台架构 实施方法论 ETL架构与流程 根据业务和数据情况，采用不同的数据整合路线 DFD顶层图 数据抽取策略 数据清理过程 数据