本文主要是介绍【大数据】数据仓库的定义、数据模型及其建设与设计，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
1. 数据仓库
1.1 定义
数据仓库不是数据的简单堆积，而是从大量的事务型数据库中抽取数据，并将其清理、转换为新的存储格式,即为决策目标把数据聚合在一种特殊的格式中。公认的数据仓库之父 W.H. Inmon 将其定义为：“数据仓库是支持管理决策过程的、面向主题的、集成的、随时间而变的、持久的数据集合”。
1.2 体系结构
数据仓库的体系结构如下图：
数据源： 是数据仓库系统的基础，是整个系统的数据源泉。通常包括企业内部信息和企业外部信息。内部信息包括存放于关系型数据库RDBMS中的各种业务处理数据和各类文档数据。外部信息包括各类法律法规、市场信息和竞争对手的信息等等；目前，数据仓库的数据源主要是内部信息，也就是来源于各个信息系统下的关系型数据库。
数据的存储与管理： 是整个数据仓库的核心。数据仓库的真正关键是数据的存储和管理。针对现有各业务系统的数据，进行抽取、清理，并有效继承，按照主题进行组织。装载入数据仓库。数据仓库按照数据的覆盖范围可以分为企业级数据仓库和部门级数据仓库（通常称为数据集市）。
OLAP服务器： 对分析需要的数据进行有效集成，按多维模型予以组织，以便进行多角度、多层次的分析，并发现趋势。其具体实现可以分为：
- ROLAP：基本数据和聚合数据均存放在RDBMS之中；
- MOLAP：基本数据和聚合数据均放在多维数据库中；
- HOLAP：基本数据存放于RDBMS中，聚合数据存放在多维数据库中。
前端工具： 主要包括各种报表工具、查询工具、数据分析工具、数据挖掘工具以及各种基于数据仓库或数据集市的应用开发工具。其中，数据分析工具主要针对OLAP服务器，报表工具、数据挖掘工具主要针对数据仓库。
2. 数据仓库的数据模型
概念数据模型： 也就是业务模型，由企业决策者，商务领域知识专家和IT专家共同企业级地跨领域业务系统需求分析的结果。
逻辑数据模型： 用来构建数据仓库的数据库逻辑模型。根据分析系统的实际需求决策构建数据库逻辑关系模型，定义数据库屋物体结构及其关系。它关联着数据仓库的逻辑模型和物理模型这两头。
物理逻辑模型： 构建数据仓库的物理分布模型，主要包含数据仓库的软硬件配置，资源情况以及数据仓库模式。
3. 数据仓库的数据模型建设
数据仓库的数据模型建设，分为3个层次：
- 高层建模（高阶模型、实体关系图）
- 中间层建模（数据项集、逻辑模型）
- 底层建模（物理模型）
3.1 高层建模
高层建模也被称为高阶建模。高阶建模要确定业务方为，明确主题。用专业术语“集成范围”用来定义数据模型的边界，集成范围确定了哪些实体属于模型设计范围之内，哪些不属于。范围的确定由模型设计者、管理人员、模型使用者等多个干系人共同确定。
3.2 中间层数据模型
中间层数据模型又称为逻辑数据模型。如果说高层模型设计是确定主题的话，那么中间层模型就是确定每个主题下的实体、属性和关系。
详细逻辑模型设计是模型设计中最最最主要的部分，实施过程比较冗长和反复。
- 首先，是系统级分析，需要收集源系统资料，对源系统做调研，通过分析了解业务流程。
- 其次，是样本数据分析，根据业务系统提供的源表数据字典建表并导入样本数据之后，对数据做分析，验证业务规则，检查数据质量，确定代码范围。
- 再次，是表级分析，通过表级分析来了解各个实体表的含义和作用，然后对实体做主题分类，对表做取舍时应当充分考虑 数据标准的信息项以及业务需求，再确定保留实体之间的关系。
- 最后，时字段级分析，字段级分析需要连接保留表的每个字段的含义，对字段进行取舍，整理出代码的取值。
做完逻辑数据模型设计应当输出“表级和字段级分析整理_XXX系统”、“代码表整理_XXX系统”、“问题追踪记录”。
3.3 物理数据模型
与逻辑数据模型相对应的就是物理数据模型。物理数据模型是基于逻辑数据模型，针对系统性能和应用需求而设计的适当的非范式化的模型设计。物理数据模型和逻辑数据模型的主题一致、结构一致、实体一致、主要字段一致。物理数据模型设计考虑的更多的是数据处理性能和物理特性，比如落地实体表的类型，每张表数据加载的时间效率，数据的保备份和备份策略、数据的质量等。
4. 数据仓库的设计
4.1 概念模型的设计
进行概念模型设计需要完成：
- 界定系统边界
- 确定主要的主题域及其内容
- 确定主题域的关系
概念模型设计是在原有的业务数据库的基础上建立了一个较为稳固的概念模型。因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等，然后再来考虑应当如何建立数据仓库系统的概念模型。一方面，通过原有的数据库的设计文档以及在数据字典中的数据库关系模式，可以对企业现有的数据库中的内容有一个完整而清晰的认识；另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。
1、界定系统的边界
数据仓库是面向决策分析的数据库,我们无法在数据仓库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了设计人员的面前:
- 要做的决策类型有哪些?
- 决策者感兴趣的是什么问题?
- 这些问题的需要什么样的信息?
- 要得到这些信息需要包含原有数据库系统的哪些部分的数据?
这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。因而，从某种意义上讲，界定系统边界的工作也可以看作是数据仓库系统设计的需求分析,因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。
2、确定主要的主题
在这一步中，要确定所包含的主题域，然后对每个主题域的内容进行较明确数据仓库建模技术在 XX 行业中的应用的描述，描述的内容包括:
- 主题域的公共码键:
- 主题域之间的联系;
- 充分代表主题的属性组。
概念模型的构建通常是企业的shakeholder,商务领域知识专家和 IT专家共同企业级地跨领域业务系统需求分析的结果。
通常企业决策者有自己的发展战略和规划,他们会定期阅读由各部门经理上报的分析报告，他们也知道大致了解自己企业信息系统的功能，但是未必清楚自己的每一个业务系统的每一个功能和每一部分数据，毕竟决策者不是信息专家，他们更关心的企业的经营业绩，资产负债，盈亏受益等等核心指标。
各个部门经理往往很了解自己部门的信息系统,在信息系统规划时优先考虑的是自己的利益，因此每个部门往往都在独立的构建自己的信息系统，无法或者不可能从企业总体角度和其他业务系统接轨，如ERP系统，MIS系统，CRM系统等等,这就造成了企业在发展企业信息系统时的不平衡,导致了所谓的孤岛效应他们会阅读下属提供的分析报告，然后进行归纳整理，形成部门报表进行上报但是最终结果却是每个部门都在上报白己的经营业绩,却始终缺乏一个一致的统一的数字。
4.2 逻辑模型设计
逻辑建模是数据仓库实施中的重要一环,因为它能直接反映出业务部门的需求，同时对系统的物理实施有着重要的指导作用。通过实体和关系勾勒出真个企业的数据蓝图。
在这一步里进行的工作主要有：
- 分析丰富主题域，确定当前要装载的主题
- 确定粒度层次划分
- 确定数据分割策略
- 关系模式定义
- 记录系统定义
逻辑模型设计的成果是，对每个当前要装载的主题的逻辑实现进行定义，并将相关内容记录在数据仓库的元数据中，包括:
- 适当的粒度划分
- 合理的数据分割策略
- 适当的表划分
- 定义合适的数据来源等
1、分析主题域
在概念模型设计中，我们确定了几个基本的主题域，但是，数据仓库的设计方法是一个逐步求精的过程，在进行设计时，一般是一次一个主题或一次若干个主题地逐步完成的。所以，我们必须对概念模型设计步骤中确定的几个基本主题域进行分析，一并选择首先要实施的主题域。选择第一个主题域所要考虑的是它要足够大，以便使得该主题域能建设成为一个可应用的系统;它还要足够小，以便于开发和较快地实施。如果所选择的主题域很大并且很复杂，我们甚至可以针对它的一个有意义的子集来进行开发。在每一次的反馈过程中，都要进行主题域的分析。具体的实施细节需要和 AAA业务部门和信息中心沟通。
2、粒度层次划分
数据仓库逻辑设计中要解决的一个重要问题是决定数据仓库的粒度划分层次,粒度层次划分适当与否直接影响到数据仓库中的数据量和所适合的查询类型由于主题数据库响应企业级业务0LTP需求，所以必须保存最细类度数据，同时根据业务部门的查询需求考虑确定多重粒度来提高复杂查询速度。
3、确定数据分割策略
在这一步里，要选择适当的数据分割的标准，一般要考虑以下几方面因素:数据量(而非记录行数)、数据分析处理的实际情况、简单易行以及粒度划分策略等。数据量的大小是决定是否进行数据分割和如何分割的主要因素：数据分析处理的要求是选择数据分割标准的一个主要依据,因为数据分割是跟数据分析处理的对象紧密联系的;我们还要考虑到所选择的数据分割标准应是自然的、易于实施的：同时也要考虑数据分割的标准与粒度划分层次是适应的。
4、关系模式定义
数据仓库的每个主题都是由多个表来实现的,这些表之间依靠主题的公共码键联系在一起，形成一个完整的主题。在概念模型设计时，我们就确定了数据仓库的基本主题，并对每个主题的公共码键、基本内容等做了描述在这一步里，我们将要对选定的当前实施的主题进行模式划分，形成多个表，并确定各个表的关系模式。
4.3 物理模型设计
这一步所做的工作是根据信息系统的容量，复杂度，项目资源以及数据仓库项目自身的软件生命周期确定数据仓库系统的软硬件配置,数据仓库分层设计模式，数据的存储结构，确定索引策略，确定数据存放位置，确定存储分配等等这部分应该是由项目经理和数据仓库架构师共同实施的。
确定数据仓库实现的物理模型，要求设计人员必须做到以下几方面：
1、确定项目资源
根据预算和业务需求，并参考以往的数据仓库项目经验，对该项目的成本周期和资源进行估算。
关于项目周期的估算，主要基于ETL函数功能点以及加权后的复杂度进行估算，因为ETL过程占据了整个数据仓库项目的70%；ETL过程主要是基于源<=>目的的原则进行处理的，而不同的功能点具有不同的复杂度，通过以往项目经验和专家评估，然后再根据软件生命周期的划分，可以有效的得知项目的整体周期。
关于人员的估算,主要取决于人员的工作经验，素养，对新技术的掌握能力，还要考虑到人员流动等方面的人员备份
协作，每一个IT企业都应该具备一个丰富的技能和人力资源库，当项目资源遇到瓶颈的时候，就可以考虑需求协作。
2、确定软硬件配置
数据仓库项目与其他业务系统不同，尤其需要对数据容量进行估算，这是因为数据仓库是历史的稳定的基于主题的集成的等等特性所决定的,他是对以往历史数据的集成，如果项目初期不加以考虑，很快就会造成灾难性的后果。
关系数据库的性能息息相关，如何在0racle,SQLServer,DB,Sybase甚至MySQL 之间寻找平衡，既要考虑实际的预算，也要视实际的需求而定。
关于硬件的配置，既需要发挥软件的功能，满足实际的处理要求，也要为将来的系统扩展保留一定的空间。数据仓库的容量估算应该是可预见的，首先确定核心明细数据的存储年限，相关表的平均字段长度值每年的记录数(每年预计的增长)，然后再加上 20%的冗余，以及磁盘预留的20%的冗余，我们不难得到数据仓的预计容量。
数据仓库的处理能力和容量息息相关。
3、数据仓库存储设计
数据仓库一般采用分层设计，即0DS层，数据仓库层，数据仓库聚合层数据集市等等;数据仓库的分层是灵活的,没有固定的模式,一切视实际情况而定。ODS层存放从原系统采集来的原始交易数据，只保存一定期限内的数据，同时ODS支持部分近实时性报表的展示。
数据仓库层保存经过清洗，转换和重新组织的历史业务数据，数据将保留较
长时间(5~10 年不等)，满足系统最细粒度的查询需要。数据仓库聚合层面向KPI指标计算和分析，支持汇总层面交易级的指标查提高汇总级的 KPI 数据展示速度和数据保存时间。保存较长的历史数据。询，数据集市是对于部门或者某一类特定分析主题需要,从企业级数据仓库单独获取的一个数据的逻辑或者物理的子集。
4、数据仓库模式
数据抽取策略： 制定系统的主题数据库ETL抽取方案来满足主题数据库的业务处理，数据仓库系统分析及决策支持分析的需要，同时必须保证不能影响业务系统的性能。
数据转换策略： 数据转换是指对从业务系统中抽取的源数据根据主题数据库系统模型的要求，进行数据的转换、清洗、拆分等处理，保证来自不同系统、不同格式的数据的一致性和完整性，并按要求装入主题数据库。
数据加载策略: 从业务系统中抽取、转换后的数据加载到主题数据库系统中。数据质量的检查
星型模型： 数据通常采用星型模型存储。星型模型由维表与事实表构成，一般并非业务系统中的规范化的范式结构。在核心层中，针对即定的主题，通常会建立若干星型模型。
这篇关于【大数据】数据仓库的定义、数据模型及其建设与设计的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
