基于数据仓库模型的运营分析系统
进入21世纪，信息科技迅猛发展，市场瞬息万变，企业要想在激烈的市场竞争中立于不败之地，就需要对客户和市场的信息做出快速、及时的搜集与响应，同时对自身的运营状况也要做出全面的预测与分析。企业要想通过信息化的手段，按照自身的需求以全方位、精确的粒度来分析自身生产、经营的情况，使用数据仓库是一个行之有效的方法。
数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision
Making Support)。
面向主题：操作型数据库的数据组织是面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织的。
集成：数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
相对稳定：数据仓库所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。
反映历史变化：数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。
1、系统软件平台及构造
（1） 软件平台 软件主要包括前台展现页面、WEB应用程序服务器、后台数据库系统。其中前台展现页面是基于B/S架构的JSP页面；WEB应用服务器使用IBM公司的WebSpere Application
Server；后台数据库使用Oracle 10g。
一、数据仓库设计（20分）
假设一高校的教务管理系统包括成绩录入、成绩统计报表、成绩管理三个模块，能满足数据信息化管理、数据查询和简单的统计功能，随着学生数量的增加和课程数量的增加，以及教学管理要求的提高，原来的OLTP系统已不能满足工作需要。原有OLTP系统中表如下：
成绩表（学生号，课程号，成绩）；学生表（学号，姓名，性别，出生日期，籍贯，职务，班级号）；班级表（班级号，班级名，系号）；系表（系号，系名称，学院号）；学院（学院号，学院名称）；课程表（课程号，课程名称，课程性质，学期号）；学期表（学期号，学年名，学期名）；教师表（教师号，教师姓名，性别，职称，出生日期，籍贯）；教师授课表（教师号，课程号，上课教室号）；教室表（教室号，教室地址，管理员），
如果要为学生成绩分析建立一数据仓库，
(1)请问什么是数据仓库？（5分）
数据仓库是面向主题的、集成的、稳定的和随时间变化的数据集合（4分），用以支持管理决策（1分）。
(2)设计此数据仓库的星型模型。（15分）
班级号
班级名 学生号
姓名
性别
出生日期
籍贯
职务 学生号
班级号
系号
学院号
课程号
学期号
教师号
教室号
成绩 教师号
教师姓名
性别
职称
出生日期
籍贯 学期号
学年名
学期名
课程号
课程名称
课程性质 教室号
教室地址
管理员
系号
系名称 学院号
学院名称
数据仓库逻辑建模
数据仓库模型的特点
对于传统的OLTP系统,我们总是按照应用来建立它的模型,换言之,OLTP系统是面向应用的。而数据仓库则一般按照主题 (Subject)来建模,它是面向主题的。何谓应用?何谓主题?让我们来看一个简单的例子。
在银行中,一般都有对私 (个人储蓄)、对公 (企业储蓄)、信用卡等多种业务系统,它们都是面向应用的,所支持的交易类型简单而且固定。由于实施的先后等原因,这些系统可能运行在不同的平台上,相互之间没有什么关系,各系统之间的数据存在冗余。比如每个系统中都会有客户的数据,当针对银行建立其数据仓库应用时,要把上述生产系统中的数据转换到数据仓库中来。从整个银行的角度来看,其数据模型不再面向个别应用,而是面向整个银行的主题,比如客户、产品、渠道等。因此,各个生产系统中与客户、产品、渠道等相关的信息将分别转换到数据仓库中相应的主题中,从而在整个银行的业务界面上提供一个一致的信息视图。
数据仓库的建模方法
逻辑建模是数据仓库实施中的重要一环,因为它能直接反映出业务部门的需求,同时对系统的物理实施有着重要的指导作用。目前较常用的两种建模方法是所谓的第三范式 (3NF,即 Third Normal Form)和星型模式 (Star-Schema),我们将重点讨论两种方法的特点和它们在数据仓库系统中的适用场合。
什么是第三范式
范式是数据库逻辑模型设计的基本理论,一个关系模型可以从第一范式到第五范式进行无损分解,这个过程也称为规范化 (Normalize)。在数据仓库的模型设计中目前一般采用第三范式,它有非常严格的数学定义。如果从其表达的含义来看,一个符合第三范式的关系必须具有以下三个条件:
1. 每个属性的值唯一,不具有多义性;
2. 每个非主属性必须完全依赖于整个主键,而非主键的一部分;
3. 每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去。
以后，我们将考虑要分析的技术指标，诸如年销售额之类。它们一般为数值型数据。我们或者将该数据汇总，或者将该数据取次数、独立次数或取最大最小值等，这样的数据称为量度。
量度是要统计的指标，必须事先选择恰当，基于不同的量度可以进行复杂关键性能指标(KPI)等的设计和计算。
(三)、确定事实数据粒度
在确定了量度之后，我们要考虑到该量度的汇总情况和不同维度下量度的聚合情况。考虑到量度的聚合程度不同，我们将采用“最小粒度原则”，即将量度的粒度设置到最小。
例如：假设目前的数据最小记录到秒，即数据库中记录了每一秒的交易额。那么，如果我们可以确认，在将来的分析需求中，时间只需要精确到天就可以的话，我们就可以在ETL处理过程中，按天来汇总数据，此时，数据仓库中量度的粒度就是“天”;反过来，如果我们不能确认将来的分析需求在时间上是否需要精确到秒，那么，我们就需要遵循“最小粒度原则”，在数据仓库的事实表中保留每一秒的数据，以便日后对“秒”进行分析。
在采用“最小粒度原则”的同时，我们不必担心海量数据所带来的汇总分析效率问题，因为在后续建立多维分析模型(CUBE)的时候，我们会对数据提前进行汇总，从而保障产生分析结果的效率。关于建立多维分析模型(CUBE)的相关问题，我们将在下期栏目中予以阐述。 (四)、确定维度
维度是指分析的各个角度。例如我们希望按照时间，或者按照地区，或者按照产品进行分析，那么这里的时间、地区、产品就是相应的维度。基于不同的维度，我们可以看到各量度的汇总情况，也可以基于所有的维度进行交叉分析。
这里我们首先要确定维度的层次(Hierarchy)和级别(Level)(图四：pic4.bmp)。如图所示，我们在时间维度上，按照“年 -季度-月”形成了一个层次，其中“年”、“季度”、“月”成为了这个层次的3个级别;同理，当我们建立产品维度时，我们可以将“产品大类-产品子类-产品”划为一个层次，其中包含“产品大类”、“产品子类”、“产品”三个级别。
