数据仓库模型
出自 MBA智库百科(https://wiki.mbalib.com/)
目录 |
数据仓库模型的概述[1]
数据仓库是一种近年来出现的、发展迅速的技术，它将企业内各种跨平台的数据经过集成，为企业决策者进行市场分析并做出决策提供了有效的途径。数据仓库的开发是由数据模型驱动的，数据仓库的创建过程中数据建模是最关键的技术环节，它直接决定数据仓库的成败。因此，要成功地创建一个数据仓库，必须有一个合理的数据模型。
数据模型是对现实事物的反映和抽象，它可以帮助我们更加清晰地了解客观世界。数据仓库建模在业务需求分析之后开始，是数据仓库构造的正式开始。在创建数据仓库的数据模型时应考虑：
（1）满足不同层次不同用户的信息需求。
（2）兼顾查询效率与数据粒度的需求。数据粒度与查询效率往往是相互矛盾的，细小的粒度保证了信息查询的灵活性，但降低了查询的效率。因此，建模要提供足够的数据粒度，并保证查询的效率。
（3）适应需求的变化。用户的信息需求随着市场的变化，建模要考虑支持需求的变化。
（4）避免业务运营系统的性能影响。由于数据仓库系统中数据增长迅速，运行占用大量资源，建模要考虑尽量减少业务运营系统的性能的影响。
（5）提供可扩展性。数据模型的可扩展性决定了数据仓库对新的需求的适应能力，建模既要考虑眼前的信息需求，也要考虑未来的需求。
合理而完备的数据模型是用户业务需求的体现，是数据仓库成败的技术因素。因此，数据模型的创建能直接反映出业务需求，对系统的物理实施起着指导性的作用，是数据仓库的核心问题。
数据仓库模型的主要内容[2]
数据仓库的实现策略有多种, 面向主题的自顶而下的设计方法, 其实面向主题就是面向对象。数据仓库包含的对象可以是:客户、产品、策略等多维概念。终端用户通过各种维度来获取商业数据, 其中时间是最基本、最关键的维度。数据仓库的数据建模分为3个层次: 高层建模、中间层建模、底层建模, 其设计方法同传统的数据库设计一样经历了概念模型设计、逻辑模型设计和物理模型设计3 个阶段, 对于面向主题的数据仓库, 数据建模的具体方法有多种, 这里介绍的是信息包图设计、星型图模型设计和物理数据模型设计：
; 1.高层建模方法——信息包图
高层建模(ERD,实体关系层),其特点是实体和关系,属概念模型设计阶段,也就是通常所说的需求分析,在与用户交流的过程中,确定数据仓库所需要访问的信息,这些信息包括当前、将来以及与历史相关的数据。在需求分析阶段确定操作数据、数据源以及一些附加数据,设计容易理解的数据模型,有效地完成查询和数据之间的映射。
由于数据仓库的多维性,利用传统的数据流程图进行需求分析己不能满足需要。超立方体(hypercube)用超出三维的表示来描述一个对象,显然具备多维特性,完全可以满足数据仓库的多维特性。利用自上而下方法设计一个超立方体的步骤为:(1)确定模型中需要抓住的商业过程,例如销售活动或销售过程;(2)确定需要捕获的值,例如销售数量或成本,这些信息通常是一些数值;(3)确定数据的粒度,亦即需要捕获的最低一级的详细信息。
由于超立方体在表现上缺乏直观性,尤其当维度超出三维后,数据的采集和表示都比较困难,因此我们可以采用一种称为信息包图的方法在平面上展开超立方体,即用二维表格反映多维特征。
信息包图提供了一个多维空间建立用户信息模型的方法,它提供了超立方体的可视化表示。
信息包图集中在用户对信息包的需要,它定义主题内容和主要性能测试指标之间的关系,其目标就是满足用户需要。信息包图拥有3个重要对象:指标、维度和类别,而类别是在一个维度内为了提供详细分类而定义的,利用信息包图设计概念模型需要确定如下这3大内容:确定指标。指标表明在维度空间上衡量商务信息的一种方法,是访问数据仓库的关键所在,是用户最关心的信息。成功的信息包可以保证用户从信息包中获取需要的各个性能指标参数。
确定维度。维度提供了用户访问数据仓库信息的途径,对应超立方体的每一面,位于信息包图的第一行的每一个栏目中。
确定类别。类别表示一个维度包含的详细信息,其中的成员是为了辨别和区分特定数据而设,一个维度内最底层的可用的分类又称为详细类别。
对于复杂的商业要求进行需求分析时,有时一张信息包图不能反映所有情况,可能需要设计不同的信息包图来满足全部需求,此时应该保证多个信息包图中出现的维度信息和类别信息完全一致。
- 2.中间层建模方法——星形图设计
高层数据模型建好后,下一步就是中间层建模(DIS,数据项集),对高层模型中标识的每个实体都要建一个中间层模型。数据仓库主要提供的是查询操作,而最便于执行查询操作的逻辑模型设计工具是星形图,因此可以利用星形图来设计数据仓库的逻辑模型。
星形图因其外观似五角星而得名,它支持以商务决策者的观点定义数据实体,满足面向主题数据仓库设计的需要,而信息包图又为星形图的设计提供了完备的概念基础。同信息包图中的3个对象对应,星形图拥有以下3个逻辑实体的定义。
定义指标实体。位于星形图中心的实体是指标实体,是用户最关心的基本实体和查询活动的中心,为用户的商务活动提供定量数据。使用每一个指标,同时确定是否存储经过计算的指标。
定义维度实体。位于星形图星角上的实体是维度实体,其作用是限制用户的查询结果,将数据过滤使得从指标实体查询返回较少的行,从而缩小访问范围。一个维度实体对应指标实体中多个指标。一个维度实体对应信息包图中的一个列。
定义详细类别实体。详细类别实体,对应现实世界的某一实体。一个维度内的每个单元就是一个类别,代表该维度内的一个单独层次,要求更加详细的信息才能满足用户的需要,与对应的事务数据库结构产生映射。
在星形图中,用户通过维度实体获得指标实体数据,其中指标实体与维度实体间的联系通过每个维度中的最低一层的详细类别实体连接。
当多个信息包图转换成星形图时,可能出现维度实体的交叉重叠,为了保证实体的一致性需要进行统一处理,确定它们是同一实体在不同层次上的数据反映,还是两个不同的实体。当多个维度实体相关并且存在共性时,可能需要将其合并为一个指标实体。
- 3.底层建模方法——星形图转换为物理数据模型
底层建模(物理层),从逻辑模型转向物理模型设计,完全遵循传统的数据库设计方法。一般来说,星形图中的指标实体和详细类别实体通常转变为一个具体的物理数据库表,而维度实体则作为查询参考、过滤和聚合数据使用,因此通常并不直接转变为物理数据库表。在物理模型设计阶段,需要确定以下内容:定义数据标准。规范化数据仓库中的各种数据。
定义实体和实体特征。完整定义实体所具有的一切属性,决定数据的粒度与分割,当然要加入与每个数据单元相关的时间元。
定义规模。确定数据容量和更新频率。
对于传统的OLTP系统,我们总是按照应用来建立它的模型,换言之,OLTP系统是面向应用的。而数据仓库则一般按照主题 (Subject)来建模,它是面向主题的。何谓应用?何谓主题?让我们来看一个简单的例子。在银行中,一般都有对私 (个人储蓄)、对公 (企业储蓄)、信用卡等多种业务系统,它们都是面向应用的,所支持的交易类型简单而且固定。由于实施的先后等原因,这些系统可能运行在不同的平台上,相互之间没有什么关系,各系统之间的数据存在冗余。比如每个系统中都会有客户的数据,当针对银行建立其数据仓库应用时,要把上述生产系统中的数据转换到数据仓库中来。从整个银行的角度来看,其数据模型不再面向个别应用,而是面向整个银行的主题,比如客户、产品、渠道等。因此,各个生产系统中与客户、产品、渠道等相关的信息将分别转换到数据仓库中相应的主题中,从而在整个银行的业务界面上提供一个一致的信息视图。
模型是对现实事物的反映和抽象，它可以帮助我们更加清晰的了解客观世界。数据仓库建模在业务需求分析之后开始，是数据仓库构造工作正式开始的第一步，正确而完备的数据模型是用户业务需求的体现，是数据仓库项目成功与否最重要的技术因素。
金融企业的信息系统具有业务复杂、机构复杂、系统庞大的特点，因此金融行业数据仓库建模必须注意以下几个方面，
——满足不同用户的需求
金融行业的业务流程十分复杂，数据仓库系统涉及的业务用户众多，在进行数据模型设计的时候必须兼顾不同业务产品、不同业务部门、不同层次、不同级别用户的信息需求。
数据仓库应该支持企业的各种业务，比如对财产保险行业应该考虑财产险、货物运输险、工程险、责任险等不同业务的特点；不同的业务部门对信息的需求各有不同，应考虑业务、市场、财务、管理等各个部门的需要；不同层次的组织所关心的信息不同，数据模型应支持地市公司、省公司和总公司的信息需求；金融企业是知识密集型的企业，知识密集型企业的显著特征是智能员工(Knowledge Worker)占企业员工的大多数，数据仓库必须支持所有相关智能型员工的信息需求，包括高层领导、基层领导和普通员工。
——兼顾效率与数据粒度的需要
数据粒度和查询效率从来都是矛盾的，细小的数据粒度可以保证信息访问的灵活性，但同时却降低了查询的效率并占用大量的存储空间，数据模型的设计必须在这矛盾的两者中取得平衡，优秀的数据模型设计既可以提供足够详细的数据支持又能够保证查询的效率。
——支持需求的变化
用户的信息需求随着市场的变化而变化，所以需求的变化只有在市场竞争停顿的时候才会停止，而且随着竞争的激化，需求变化会越来越频繁。数据模型的设计必须考虑如何适应和满足需求的变化。
——避免对业务运营系统造成影响
金融企业的数据仓库系统是一个每天都在长大的庞然大物，它的运行很容易占用很多的资源，比如网络资源、系统资源，在进行数据模型设计的时候也需要考虑如何减少对业务系统性能的影响。
——考虑未来的可扩展性
数据仓库系统是一个与企业同步发展的有机体，数据模型作为数据仓库的灵魂必须提供可扩展的能力，在进行数据模型设计时必须考虑未来的发展，更多的非核心业务数据如人事数据、市场数据、竞争对手数据等必须可以方便的加入到数据仓库，而不需要对数据仓库中原有的系统进行大规模的修改。
大规模的数据仓库系统特别是金融行业数据仓库的数据结构从技术角度划分应当包含三个部分，如下图所示，
- 1.分段存储区（Staging Area）
由于数据仓库中的数据结构和组织方式具有很大差异、所有原始业务系统的数据必须经过严格的抽取、映射和转换，数据的整合过程十分复杂，通常会耗费比较长的处理时间。如果从业务系统直接抽取数据到数据仓库，必定会占用许多业务系统的资源和时间，为了避免影响业务系统的运行，我们在数据模型的设计中引入分段存储区的概念。
分段存储区（Staging Area）是为了保证数据移动的顺利进行而开设的阶段性数据存储空间，它是业务系统原始数据进入数据仓库前的缓存区。需要进入数据仓库的各个业务系统的数据首先直接快速传输到分段存储区，再从分段存储区经过清洗、转换、映射等复杂的数据移动处理转移到目标数据仓库中。从业务系统到分段存储区的数据传输，应尽量避免进行复杂的数据处理，以保证数据的快速导入而尽量减小对业务系统造成的压力。分段存储区的数据有关系数据库和文件两种不同存储方式，分别对应于不同运营系统的数据源。数据成功导入数据仓库之后，应清空分段存储区中的数据。
在数据仓库系统的运行和使用过程中，分段存储区的作用主要体现在以下几个方面，
- 可以减少对业务系统资源的占用，避免复杂数据转换对业务系统的影响
- 分段存储区作为数据缓存区，可以在一定程度上屏蔽业务系统变化对数据移动整合系统的影响
- 如果在数据处理过程中发生系统故障，作为数据仓库系统的备份数据，可以直接从分段存储区进行数据仓库数据恢复，而不必要再从业务系统原始数据开始。
- 2.基础数据仓库（BaseLine）
基础数据仓库存储所有最详细的业务数据。该层数据直接来源于对分段存储区数据的清洗和加工，属于未经汇总的数据，但数据的组织方式可能已经完全不同于原始的业务系统。根据业务需求的不同，基础数据仓库的组织形式以三范式模型为主，在有的系统中也可能采用星型或雪花模型。
通常在金融企业的数据仓库系统中，基础数据仓库数据包括未经汇总的客户交易数据，用户资料数据、客户服务数据等，此外一些相关数据如网络利用，竞争对手，成本投资数据也包括在内。由于基础数据仓库数据是对原始业务数据的原形再现，所以数据量会非常庞大，根据不同业务的需要数据保留的时间在6个月到两年不等。
根据业务需求将数据仓库数据分类成几个不同的数据集市，每个数据集市完成不同的分析和查询需求，数据集市中的数据通常由基础数据仓库的详细数据聚合而来，根据数据聚合程度的不同包含轻度聚合、中度聚合和高度聚合三种不同的层次。汇总的方式将依据数据量的大小和使用频度综合考虑。
