数据仓库建模详解和建模技巧

合集下载

数仓建模方法

数仓建模方法

数仓建模方法数仓建模方法是数据仓库建设过程中的核心技术之一。

数仓建模方法是指根据业务需求,将数据仓库中的数据按照一定的规则、标准进行分类、整理和归类,然后建立数据仓库的存储结构,使得数据仓库能够满足不同层次用户的查询和分析需求,以及数据仓库性能和可维护性的要求。

常用的数仓建模方法有维度建模方法和实体关系建模方法。

下面将对这两种建模方法进行详细介绍。

1. 维度建模方法维度建模方法是将数据仓库中的数据按照维度和度量进行分类,并建立维度模型来存储数据。

维度指一些具有共同属性的数据对象,比如时间、地理位置、产品等,度量则是用来描述维度之间关系的数值或指标。

维度模型通常由一个中心事实表和多个维度表组成,中心事实表包含多个度量和与之相关的维度键,维度表则包含每个维度的属性和维度键。

维度建模方法具有以下优点:(1)易于理解和维护:维度建模方法采用直观的图形化表示方法,能够直观地反映业务性质和数据之间的关系,使得数据仓库使用更加直观和易于维护,同时也能够降低数据仓库的实施成本和风险。

(2)适应性强:维度建模方法能够很好地适应多种类型的业务需求,并且在模型设计过程中可以根据实际需求进行模型的调整和扩展。

(3)高性能:维度建模方法能够通过冗余数据的技术实现查询优化,提高查询效率和性能。

2. 实体关系建模方法实体关系建模方法是将数据仓库中的数据按照实体和关系进行分类,并建立实体关系模型来存储数据。

实体是业务领域中的某个具体事物,比如客户、订单、产品等,而实体之间的关系则代表了实体之间的业务关系。

实体关系模型通常由多个实体表和连接表组成,实体表包含每个实体的属性,连接表则用于描述实体之间的关系。

实体关系建模方法具有以下优点:(1)可扩展性强:实体关系建模方法能够很好地适应任何类型的业务需求,并且可以根据实际需求进行灵活的模型扩展和调整。

(2)模型具有普遍性:实体关系模型是基于实体和关系的统一建模方法,这种建模方式在软件工程领域得到广泛应用,在数据仓库建设中也具有普遍性。

数据仓库建模方法论

数据仓库建模方法论

数据仓库建模方法论数据仓库建模是指将数据仓库中的数据按照某种标准和规范进行组织和管理的过程。

数据仓库建模方法论包括了多种方法和技术,用于帮助用户理解和分析数据仓库中的数据,从而支持决策制定和业务分析。

一、维度建模方法维度建模方法是数据仓库建模的核心方法之一,它以维度为核心,将数据按照维度进行组织和管理,从而提供给用户灵活和高效的数据查询和分析能力。

1.1 星型模型星型模型是最常见和简单的维度建模方法,它将数据仓库中的事实表和多个维度表通过共享主键的方式进行关联。

事实表包含了衡量业务过程中的事件或指标,而维度表包含了用于描述和过滤事实记录的属性。

星型模型的结构清晰,易于理解和使用,适用于绝大部分的数据仓库场景。

1.2 雪花型模型雪花型模型是在星型模型的基础上进行扩展和优化的一种模型,它通过拆分维度表中的属性,将其拆分为多个维度表和子维度表,从而使得数据仓库更加灵活和高效。

雪花型模型适用于维度表中的属性比较复杂和层次结构比较多的情况。

1.3 天际线模型天际线模型是一种比较先进和复杂的维度建模方法,它通过将事实表和维度表按照一定的规则进行分组和划分,从而实现多个星型模型之间的关联。

天际线模型适用于数据仓库中包含多个相互关联的业务过程和多个不同的粒度的情况。

二、多维建模方法多维建模方法是在维度建模方法基础上进行进一步抽象和简化的一种方法,它通过创建多维数据立方体和维度层次结构来组织和管理数据。

2.1 数据立方体数据立方体是多维建模的核心概念,它将数据按照事实和维度进行组织和管理,从而提供给用户直观和高效的数据查询和分析能力。

数据立方体包含了多个维度和度量,用户可以通过选择和组合维度和度量进行数据分析和挖掘。

2.2 维度层次结构维度层次结构是多维建模的关键技术,它通过将维度进行分层和组织,从而实现维度之间的关联和上下级关系。

维度层次结构可以有效地减少数据的冗余和复杂性,提高数据仓库的查询和分析效率。

三、模式设计方法模式设计方法是在维度建模方法和多维建模方法的基础上进行进一步的抽象和规范的一种方法,它通过定义模式和规则来组织和管理数据仓库中的数据。

数据仓库的设计和构建

数据仓库的设计和构建

数据仓库的设计和构建数据仓库(Data Warehouse)是指将组织机构内部各种分散的、异构的数据整合起来,形成一个共享的、一致的、易于查询和分析的数据环境。

数据仓库的设计和构建是数据管理和分析的重要环节。

本文将结合实践经验,介绍数据仓库的设计与构建过程。

一、需求分析数据仓库的设计与构建首先需要进行需求分析。

在需求分析阶段,我们需要明确以下几个问题:1. 数据来源:确定数据仓库所需要的数据来源,包括内部系统和外部数据源。

2. 数据维度:确定数据仓库中需要关注的维度,如时间、地理位置、产品等。

3. 数据粒度:确定数据仓库中的数据粒度,即需要对数据进行何种程度的聚合。

4. 数据可用性:确定数据仓库中数据的更新频率和可用性要求。

5. 分析需求:明确数据仓库所需满足的分析需求,如报表查询、数据挖掘等。

二、数据模型设计在数据仓库设计过程中,数据模型的设计尤为重要。

常用的数据模型包括维度建模和星型模型。

维度建模是基于事实表和维度表构建的,通过定义事实和维度之间的关系,建立多维数据结构。

星型模型则将事实表和各个维度表之间的关系表示为星型结构,有助于提高查询效率。

根据具体需求和数据特点,选择合适的数据模型进行设计。

三、数据抽取与转换数据仓库的构建过程中,需要从各个数据源中抽取数据,并进行清洗和转换。

数据抽取常用的方法包括全量抽取和增量抽取。

全量抽取是指将数据源中的全部数据抽取到数据仓库中,适用于数据量较小或变动频率较低的情况。

增量抽取则是在全量抽取的基础上,只抽取发生变动的数据,提高了数据抽取的效率。

数据在抽取到数据仓库之前还需要进行清洗和转换。

清洗的目标是去除数据中的错误、冗余和不一致之处,保证数据的准确性和完整性。

转换的目标是将数据格式进行统一,并进行必要的计算和整合,以满足数据仓库的需求。

四、数据加载与存储数据加载是指将抽取、清洗和转换后的数据加载到数据仓库中的过程。

数据加载的方式可以分为批量加载和实时加载。

数据仓库建模

数据仓库建模

数据仓库建模数据仓库建模是指根据业务需求和数据分析目标,对数据仓库进行设计和构建的过程。

它包括数据仓库的架构设计、数据模型设计、ETL(提取、转换和加载)流程设计等方面。

以下是关于数据仓库建模的详细介绍。

1. 数据仓库架构设计:数据仓库架构设计是数据仓库建模的第一步,它确定了数据仓库的整体结构和组织方式。

常见的数据仓库架构包括星型模型、雪花模型和星座模型等。

在架构设计中,需要考虑数据仓库的数据来源、数据存储方式、数据访问方式等因素,以确保数据仓库的高效性和可扩展性。

2. 数据模型设计:数据模型设计是数据仓库建模的核心环节,它定义了数据仓库中的数据结构和关系。

常用的数据模型包括维度模型和事实模型。

维度模型主要用于描述业务维度和维度之间的关系,而事实模型主要用于描述业务事实和事实之间的关系。

在数据模型设计中,需要根据具体业务需求,确定维度和事实的属性,并建立它们之间的关联关系。

3. ETL流程设计:ETL流程设计是数据仓库建模的关键环节,它负责将源系统中的数据提取、转换和加载到数据仓库中。

ETL流程包括数据抽取、数据清洗、数据转换和数据加载等步骤。

在ETL流程设计中,需要考虑数据抽取的频率、数据清洗的规则、数据转换的逻辑和数据加载的方式等因素,以确保数据仓库中的数据质量和一致性。

4. 数据仓库建模工具:数据仓库建模通常使用一些专业的建模工具,如PowerDesigner、ERwin等。

这些工具提供了丰富的建模功能,可以帮助数据仓库建模人员快速设计和构建数据仓库。

在使用建模工具时,需要熟悉工具的操作流程和功能,以提高建模效率和质量。

5. 数据仓库建模的最佳实践:在进行数据仓库建模时,需要遵循一些最佳实践,以确保数据仓库的高效性和可维护性。

首先,需要与业务人员紧密合作,深入了解业务需求和数据分析目标,以确保数据仓库的建模结果能够准确满足业务需求。

其次,需要遵循一致性和标准化的建模规范,以确保数据仓库中的数据结构和关系的一致性和可理解性。

数据仓库设计与建模的流程详解(一)

数据仓库设计与建模的流程详解(一)

数据仓库设计与建模的流程详解在当今信息时代,数据已经成为企业决策和运营的重要依据。

而要有效地管理和利用这些海量的数据,数据仓库的设计和建模就显得尤为关键。

本文将详细介绍数据仓库设计与建模的流程,帮助读者全面了解这个重要的数据管理过程。

一、需求分析阶段数据仓库设计与建模的第一步是需求分析阶段。

在这个阶段,我们需要与企业的相关部门和人员进行沟通,了解他们的数据需求和业务需求。

通过与业务人员的讨论,我们可以确定数据仓库的目标和范围,明确需要收集和存储哪些数据。

此外,需求分析阶段还包括对数据仓库的查询和报表要求进行梳理和分析。

通过与用户的交流,我们可以了解到用户对数据访问的需求,包括哪些报表和查询是经常用到的,对数据的哪些指标比较感兴趣等,这些信息对于后续的数据仓库设计与建模具有指导意义。

二、数据源选择和数据采集阶段在需求分析阶段确定了数据仓库需要包含的数据之后,我们需要选择数据源并进行数据采集。

选择数据源是基于业务需求和数据的可用性进行的,一般包括企业内部的各个系统和外部的数据供应商等。

数据采集是指从数据源中提取数据并进行清洗和转换的过程。

数据采集需要根据具体的数据源和业务需求进行设计和开发相关的数据提取和转换程序,保证数据的完整性和准确性。

三、数据仓库建模阶段数据仓库建模是数据仓库设计与建模过程中最关键的一步。

在这个阶段,我们需要根据业务需求和数据源的特点来设计数据仓库的模型。

数据仓库建模包括维度设计和事实表设计。

维度设计是指对数据仓库中网板维度的设计,包括对维度的属性和关系的定义。

维度是描述业务中的一组属性的实体,如时间、地点、产品等。

通过对维度的定义和建模,可以为数据仓库提供丰富的维度分析能力。

事实表设计是指对数据仓库中事实表的设计。

事实表是用来记录业务中的度量指标的表,如销售额、库存量等。

事实表和维度表之间通过关联键进行关联,从而可以实现多维分析和多维查询等功能。

四、ETL开发和数据加载阶段在数据仓库建模完成之后,我们需要进行ETL(数据提取、转换和加载)开发和数据加载工作。

数据仓库范式建模步骤

数据仓库范式建模步骤

数据仓库范式建模步骤1.确定业务需求:首先需要明确数据仓库的目标和业务需求,了解业务流程和数据处理的要求。

与业务专家和决策者沟通,确保对业务需求的准确理解和全面把握。

2.数据准备:数据仓库建模需要使用到的数据通常来自于多个源系统,包括关系数据库、大数据平台、文件系统等。

需要对这些数据进行收集、清洗、整合和转换,以便于后续的分析和建模工作。

3.反范式化:在数据仓库建模中,通常会采用反范式化的处理方式,即将多个实体和关系整合到一个宽表中,以减少数据的冗余和规范化带来的性能问题。

反范式化需要综合考虑查询需求与数据冗余的权衡,保证数据的一致性和完整性。

4.确定实体和属性:根据业务需求,确定数据仓库中的实体和属性。

实体是指数据仓库中描述的具体事物,属性是实体的特征或描述。

通过对业务流程和数据需求的分析,确定需要建模的实体和对应的属性。

6.设计关系模式:根据上述实体和关系的定义,设计数据仓库中的关系模式。

关系模式是由表和字段组成的数据结构,用于存储具体的数据。

关系模式的设计需要根据实际业务需求和查询性能要求,考虑表的分解和数据的组织方式。

7.确定索引和分区:为了提高查询性能和数据访问效率,需要对关系模式中的字段进行索引和分区。

索引是对字段的检索结构,用于加快查询的速度,分区是将数据按照一定的规则进行划分,以便于并行处理和管理。

8.数据装载:在设计完关系模式后,需要将数据装入数据仓库中。

数据装载是将源系统中的数据抽取、清洗和转换后加载到数据仓库中的过程。

数据装载的过程需要考虑数据的一致性和完整性,以保证数据的质量和准确性。

9.数据验证和测试:在数据装载后,需要对数据进行验证和测试,以确保数据的准确性和一致性。

验证和测试的方式包括数据对比、查询分析和性能测试等,通过这些方式可以发现数据质量问题和性能瓶颈,并进行优化和修正。

10.数据维护和更新:数据仓库建模是一个持续的过程,随着业务需求的变化和数据的更新,需要对数据仓库进行维护和更新。

4种数据仓库建模方法

4种数据仓库建模方法

引言概述在数字化时代,数据成为企业运营和决策的重要驱动力。

为了更好地管理和利用企业数据,很多企业采用数据仓库来集成和存储数据。

数据仓库建模是数据仓库设计的核心环节,它决定了数据在仓库中的组织结构和查询方式。

本文将介绍四种常见的数据仓库建模方法,包括维度建模、实体关系模型、标准化模型以及主题建模。

维度建模维度建模是一种以事实表和维度表作为核心的建模方法。

事实表是存储数值型数据的表,维度表则存储描述性属性的表。

在维度建模中,事实表和维度表通过共享主键来建立关联。

小点详细阐述:1.事实表的设计:事实表应选择合适的粒度,并包含与业务流程相关的度量。

例如,销售事实表可以包含销售额、销售数量等度量。

2.维度表的设计:维度表应包含与业务流程相关的描述性属性,例如时间、产品、地理位置等。

维度应具有层次结构,以便支持多维分析。

3.关系型数据库实现:维度建模通常使用关系型数据库来实现,它通过表和关联键来表示维度和事实之间的关系。

实体关系模型实体关系模型是一种基于关系代数和数据库范式的建模方法。

它通过实体、属性和关系来描述数据的结构。

实体关系模型适用于较复杂的数据仓库场景,其中数据具有多层级和复杂的关系。

小点详细阐述:1.实体的建模:实体是数据仓库中的核心对象,它代表了业务流程中的实际对象。

实体的属性描述了实体的特征。

2.关系的建模:关系描述了实体间的关联和依赖关系。

在实体关系模型中,关系通过外键建立。

3.数据库范式:实体关系模型追求高度的数据规范化,以减少数据冗余和不一致性。

标准化模型标准化模型是一种以消除冗余数据为核心的建模方法。

在标准化模型中,数据被拆分为多个表,并通过关系建立关联。

小点详细阐述:1.数据拆分:标准化模型通过将数据拆分为多个表,将重复的数据存储在一个地方,并通过外键建立关联。

2.数据插入和查询:标准化模型在数据插入和查询时需要进行多表关联操作,对性能有一定影响。

3.适用场景:标准化模型适用于事务性场景,如订单管理、库存管理等。

数据仓库建模方法总结

数据仓库建模方法总结

数据仓库建模方法总结数据仓库建模是数据仓库构建过程中的重要环节,它决定了数据仓库的数据结构和查询性能。

本文将总结几种常见的数据仓库建模方法,包括维度建模、事实建模和标准化建模,并比较它们的优缺点。

1. 维度建模维度建模是一种常见的数据仓库建模方法,它基于维度表和事实表的概念。

维度表包含描述业务过程的属性,如时间、地点、产品等,而事实表包含与业务过程相关的度量。

维度表和事实表通过共同的键连接起来,形成星型或雪花型的模型。

优点:1) 简单直观:维度建模易于理解和使用,可以快速设计和构建数据仓库。

2) 查询性能高:维度建模的星型结构简化了查询的关联操作,提高了查询性能。

缺点:1) 一对一关系:维度表和事实表之间是一对多的关系,无法处理多对多的关系。

2) 数据冗余:维度表中的属性可能存在冗余,造成数据冗余和一致性问题。

2. 事实建模事实建模是基于主题的数据仓库建模方法,它以业务过程为核心构建事实表,包括维度键和度量。

事实表记录了业务过程发生的事实信息,维度键用于连接事实表和维度表,度量用于度量业务过程的指标。

优点:1) 灵活性高:事实建模能够适应复杂的业务逻辑和多对多的关系。

2) 数据粒度控制:事实表可以根据需要控制数据的粒度,提供灵活的查询和分析能力。

缺点:1) 设计复杂:事实建模的设计复杂度较高,需要考虑多对多的关系和度量的粒度控制。

2) 查询性能相对低:事实建模需要进行多表关联操作,查询性能相对较低。

3. 标准化建模标准化建模是一种将数据仓库模型与关系数据库模型类似的建模方法。

它将数据存储在标准化的表中,通过复杂的关联操作来查询和分析数据。

标准化建模与维度建模和事实建模相比,更适用于小型数据仓库和查询较少的情况。

优点:1) 数据一致性:标准化建模减少了数据冗余,提高了数据一致性。

2) 灵活可扩展:标准化建模可以适应不同的查询需求,支持灵活的查询和分析。

缺点:1) 查询复杂:标准化建模需要进行多表关联和聚合操作,查询复杂度较高。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

一、构建企业级数据仓库五步法
(一)、确定主题
即确定数据分析或前端展现的主题。

例如:我们希望分析某年某月某一地区的啤酒销售情况,这就是一个主题。

主题要体现出某一方面的各分析角度(维度)和统计数值型数据(量度)之间的关系,确定主题时要综合考虑。

我们可以形象的将一个主题想象为一颗星星:统计数值型数据(量度)存在于星星中间的事实表;分析角度(维度)是星星的各个角;我们将通过维度的组合,来考察量度。

那么,“某年某月某一地区的啤酒销售情况”这样一个主题,就要求我们通过时间和地区两个维度的组合,来考察销售情况这个量度。

从而,不同的主题来源于数据仓库中的不同子集,我们可以称之为数据集市。

数据集市体现了数据仓库某一方面的信息,多个数据集市构成了数据仓库。

(二)、确定量度
在确定了主题以后,我们将考虑要分析的技术指标,诸如年销售额之类。

它们一般为数值型数据。

我们或者将该数据汇总,或者将该数据取次数、独立次数或取最大最小值等,这样的数据称为量度。

量度是要统计的指标,必须事先选择恰当,基于不同的量度可以进行复杂关键性能指标(KPI)等的设计和计算。

(三)、确定事实数据粒度
在确定了量度之后,我们要考虑到该量度的汇总情况和不同维度下量度的聚合情况。

考虑到量度的聚合程度不同,我们将采用“最小粒度原则”,即将量度的粒度设置到最小。

例如:假设目前的数据最小记录到秒,即数据库中记录了每一秒的交易额。

那么,如果我们可以确认,在将来的分析需求中,时间只需要精确到天就可以的话,我们就可以在ETL处理过程中,按天来汇总数据,此时,数据仓库中量度的粒度就是“天”;反过来,如果我们不能确认将来的分析需求在时间上是否需要精确到秒,那么,我们就需要遵循“最小粒度原则”,在数据仓库的事实表中保留每一秒的数据,以便日后对“秒”进行分析。

在采用“最小粒度原则”的同时,我们不必担心海量数据所带来的汇总分析效率问题,因为在后续建立多维分析模型(CUBE)的时候,我们会对数据提前进行汇总,从而保障产生分析结果的效率。

关于建立多维分析模型(CUBE)的相关问题,我们将在下期栏目中予以阐述。

(四)、确定维度
维度是指分析的各个角度。

例如我们希望按照时间,或者按照地区,或者按照产品进行分析,那么这里的时间、地区、产品就是相应的维度。

基于不同的维度,我们可以看到各量度的汇总情况,也可以基于所有的维度进行交叉分析。

这里我们首先要确定维度的层次(Hierarchy)和级别(Level)(图四:pic4.bmp)。

如图所示,我们在时间维度上,按照“年 -季度-月”形成了一个层次,其中“年”、“季度”、“月”成为了这个层次的3个级别;同理,当我们建立产品维度时,我们可以将“产品大类-产品子类-产品”划为一个层次,其中包含“产品大类”、“产品子类”、“产品”三个级别。

那么,我们分析中所用到的这些维度,在数据仓库中的存在形式是怎样的呢?
我们可以将3个级别设置成一张数据表中的3个字段,比如时间维度;我们也可以使用三张表,分别保存产品大类、产品子类、产品三部分数据,比如产品维度.
另外,值得一提的是,我们在建立维度表时要充分使用代理键。

代理键是数值型的ID号码(例如图六中每张表的第一个字段),它唯一标识了每一维度成员。

更重要的是,在聚合时,数值型字段的匹配和比较,JOIN效率高,便于聚合。

同时,代理键对缓慢变化维度有着重要的意义,在原数据主键相同的情况下,它起到了对新数据与历史数据的标识作用。

在此,我们不妨谈一谈维度表随时间变化的问题,这是我们经常会遇到的情况,我们称其为缓慢变化维度。

比如我们增加了新的产品,或者产品的ID号码修改了,或者产品增加了一个新的属性,此时,维度表就会被修改或者增加新的记录行。

这样,我们在ETL的过程中,就要考虑到缓慢变化维度的处理。

对于缓慢变化维度,有三种情况:
1、缓慢变化维度第一种类型:
历史数据需要修改。

这种情况下,我们使用UPDATE方法来修改维度表中的数据。

例如:产品的ID号码为123,后来发现ID号码错了,需要改写成456,那么,我们就在ETL处理时,直接修改维度表中原来的ID号码为456。

2、缓慢变化维度第二种类型:
历史数据保留,新增数据也要保留。

这时,要将原数据更新,将新数据插入,我们使用UPDATE / INSERT。

比如:某一员工2005年在A
部门,2006年时他调到了B部门。

那么在统计2005年的数据时就应该将该员工定位到A部门;而在统计 2006年数据时就应该定位到B部门,然后再有新的数据插入时,将按照新部门(B部门)进行处理,这样我们的做法是将该维度成员列表加入标识列,将历史的数据标识为“过期”,将目前的数据标识为“当前的”。

另一种方法是将该维度打上时间戳,即将历史数据生效的时间段作为它的一个属性,在与原始表匹配生成事实表时将按照时间段进行关联,这种方法的好处是该维度成员生效时间明确。

3、缓慢变化维度第三种类型:
新增数据维度成员改变了属性。

例如:某一维度成员新加入了一列,该列在历史数据中不能基于它浏览,而在目前数据和将来数据中可以按照它浏览,那么此时我们需要改变维度表属性,即加入新的字段列。

那么,我们将使用存储过程或程序生成新的维度属性,在后续的数据中将基于新的属性进行查看。

(五)、创建事实表
在确定好事实数据和维度后,我们将考虑加载事实表。

在公司的大量数据堆积如山时,我们想看看里面究竟是什么,结果发现里面是一笔笔生产记录,一笔笔交易记录… 那么这些记录是我们将要建立的事实表的原始数据,即关于某一主题的事实记录表。

我们的做法是将原始表与维度表进行关联,生成事实表(图六:
pic6.bmp)。

注意在关联时有为空的数据时(数据源脏),需要使用外连接,连接后我们将各维度的代理键取出放于事实表中,事实表除了各维度代理键外,还有各量度数据,这将来自原始表,事实表中将存在维度代理键和各量度,而不应该存在描述性信息,即符合“瘦高原则”,即要求事实表数据条数尽量多(粒度最小),而描述性信息尽量少。

如果考虑到扩展,可以将事实表加一唯一标识列,以为了以后扩展将该事实作为雪花型维度,不过不需要时一般建议不用这样做。

事实数据表是数据仓库的核心,需要精心维护,在JOIN后将得到事实数据表,一般记录条数都比较大,我们需要为其设置复合主键和索引,以实现数据的完整性和基于数据仓库的查询性能优化。

事实数据表与维度表一起放于数据仓库中,如果前端需要连接数据仓库进行查询,我们还需要建立一些相关的中间汇总表或物化视图,以方便查询。

二、项目模型实践技巧
(一)、准备区的运用
在构建数据仓库时,如果数据源位于一台服务器上,数据仓库在另一台服务器端,考虑到数据源Server端访问频繁,并且数据量大,需要不断更新,所以可以建立准备区数据库(图八:pic8.bmp)。

先将数据抽取到准备区中,然后基于准备区中的数据进行处理,这样处理的好处是防止了在原 OLTP系统中频繁访问,进行数据运算或排序等操作。

例如我们可以按照天将数据抽取到准备区中,基于数据准备区,我们将进行数据的转换、整合、将不同数据源的数据进行一致性处理。

数据准备区中将存在原始抽取表、转换中间表和临时表以及ETL日志表等。

(二)、时间戳的运用
时间维度对于某一事实主题来说十分重要,因为不同的时间有不同的统计数据信息,那么按照时间记录的信息将发挥很重要的作用。

在ETL 中,时间戳有其特殊的作用,在上面提到的缓慢变化维度中,我们可以
使用时间戳标识维度成员;在记录数据库和数据仓库的操作时,我们也将使用时间戳标识信息。

例如:在进行数据抽取时,我们将按照时间戳对OLTP系统中的数据进行抽取,比如在午夜0:00取前一天的数据,我们将按照OLTP系统中的时间戳取 GETDATE到GETDATE减一天,这样得到前一天数据。

(三)、日志表的运用
在对数据进行处理时,难免会发生数据处理错误,产生出错信息,那么我们如何获得出错信息并及时修正呢? 方法是我们使用一张或多张Log日志表,将出错信息记录下来,在日志表中我们将记录每次抽取的条数、处理成功的条数、处理失败的条数、处理失败的数据、处理时间等等。

这样,当数据发生错误时,我们很容易发现问题所在,然后对出错的数据进行修正或重新处理。

(四)、使用调度
在对数据仓库进行增量更新时必须使用调度(图九:pic9.bmp),即对事实数据表进行增量更新处理。

在使用调度前要考虑到事实数据量,确定需要多长时间更新一次。

比如希望按天进行查看,那么我们最好按天进行抽取,如果数据量不大,可以按照月或半年对数据进行更新。

如果有缓慢变化维度情况,调度时需要考虑到维度表更新情况,在更新事实数据表之前要先更新维度表。

调度是数据仓库的关键环节,要考虑缜密。

在ETL的流程搭建好后,要定期对其运行,所以调度是执行ETL流程的关键步骤。

每一次调度除了写入 Log日志表的数据处理信息外,还要使用发送Email或报警服务等,这样也方便的技术人员对ETL流程的把握,增强了安全性和数据处理的准确性。

相关文档
最新文档