数据仓库的模型设计
A. 数据建模方法论
数据仓库模型设计遵循“自顶向下、逐步求精”的设计原则。
模型设计分为三个阶段：
1，概念模型
对业务的范围和使用，从高度上进行抽象概括，也就是划分主题域。
一般划分为8个主题域：
客户、服务、服务使用、账务、结算、资源、客服、营销
为什么要划分主题域？
划分主题域，是根据业务的应用和需要来划分的，是用来达到数据与业务紧耦合的目的。
2，逻辑模型
对概念模型中的主题进行细化，定义实体与实体之间的关系，和实体的属性。
即定义具体表的作用，表与表的约束，表的字段。形成ER图。
这些实体的设计都是基于业务规则，可以说，这一阶段主要面对的是业务。也就是“业务驱动建模”
3，物理模型
依照逻辑模型，在数据库中进行建表、索引等。数据仓库，为了满足高性能的需求，可以增加冗余、隐藏表之间的约束等反第三范式操作。
这一阶段，主要针对的是数据库、硬件、性能。
范式：
第一范式：数据库表的字段都是单一属性，不可再分。
第二范式：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖。
（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况）。即要求所有属性都依赖于主键。
第三范式：数据库表中不存在非关键字段对任一候选关键字段的传递函数依赖。
范式是向下兼容的。
例如：
|
学生ID |
学生名称 |
学生部门 |
课程ID |
课程名称 |
成绩 |
|
60100 |
张三 |
教育学院，心理系，1班 |
English_1 |
英语1 |
80 |
1）违反第一范式。因为：学生部门可以分解为：学院，系，班级
2）违反第二范式。因为：关键字段是学生ID和课程ID, 但存在“课程ID”决定课程名称和课程学分。
3）违反第三范式。因为：关键字段是学生ID,但存在可能名称和学分依赖“课程ID”。
星型模型和雪花模型
首先，他们都是由一个事实表和一组维度表组成。
星型模型，也被称为维度建模。
区别在于：
星型模型：维度表直接跟事实表连接，图型像星星。
如区县和地市做为同一维度都在地市表中。
*维度预处理，维度会预先进行分类，排序等预处理。
雪花模型：一些维度表不是直接与事实表连接，而是通过维度表中转，图形像雪花。
例如：
图1：星型模型
图2 雪花模型
从性能来看，星型模型查询性能好。
为了提高性能，可以允许违反第三范式，适当的冗余、隐藏表之间的约束。
维度建模
将商业维度融合到数据模型中，由此得名维度建模。
或者说，为了分析方便（商业应用要求），将同一维度的不同层次的维度（如地市ID,区县ID）都融合到事实表中（如用户宽表）。
维度模型也是星型模型。
它 强调的是先对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表，如上面的用户统一视图。包含了20多个维度。这样可以组合各维度，形成灵活的报表查询。
B. 分层设计原则
电信行业的数据仓库都采用了分层设计原则。
总的来说，分三层：接口层、中间汇总层和应用层。
|
应用层 |
数据集市 |
地市数据集市、数据挖掘 |
|
应用层 |
KPI报表、cagnos、主题分析、指标库 |
|
|
中间层 |
深度汇总层 |
信息聚合：用户统一视图、3G用户统一视图、固话用户统一视图 |
|
业务拓展：用户行为、增值业务、集团业务、国际业务 |
||
|
轻度汇总层 |
清单汇总、用户属性聚合、费用汇总、集团客户汇总等 |
|
|
接口层 |
存储层 |
接口备份、增量转全量、减少I/O(分常用数据和历史数据) |
|
接口层 |
日接口、月接口、增量接口、全量接口 |
特别强调的是：
中间层是数据仓库最重要的一层。直接决定了数据仓库的性能。
一般的做法是：
1）数据汇总。将底层数据按维度进行小颗粒度汇总
2）信息聚合。将多张表的信息聚合在一个表中。这样的好处，是避免使用表关联，提高查询性能。
C. 主题域设计方法
如果说分层设计，是横向的设计原则，那么主题分域是纵向的处理方法。
具体做法就是从业务上，高度的抽象和归纳，将数据划分为不同的主题域。
分域后的好处：业务紧耦合、便于数据拓展、便于使用。
域是要具有明显的表命名规则，如：
用户信息域—— user
通信行为—— call
数据业务—— gprs
账务 —— bill
客户服务—— serv
xx经分系统的数据架构图：
