IBM数据仓库需求建模方法及行业数据仓库模型
数据仓库设计与建模的星座模型与星型模型的设计方法(五)
数据仓库是一个集成的、主题导向的、变化历史的、用于支持决策的数据集合。
在数据仓库的设计与建模中，星座模型和星型模型是两种常用的设计方法。
本文将对这两种设计方法进行论述和比较，分析其适用场景和优缺点。
一、星座模型设计方法星座模型（Constellation Schema）是一种以事实表为核心，将维度表与事实表的关系以星座状布局的数据模型。
它采用了星型结构，将一个或多个维度表与一个事实表通过主键和外键进行关联。
1. 星座模型的组成星座模型由维度表和事实表组成。
维度表描述业务中的一些固定属性，如产品、时间、地理位置等。
维度表以唯一标识符作为主键，并包含衍生属性和关系属性。
事实表记录了业务的度量数据，如销售额、库存量等。
事实表中包含与维度表关联的外键列，用于实现维度和度量数据之间的关系。
2. 星座模型的优点星座模型具有以下几点优点：（1）简单清晰：维度表和事实表的结构清晰，容易理解和维护。
（2）查询性能高：星座模型具有较好的查询性能，特别是在大规模数据查询时表现出色。
（3）易于扩展：星座模型的扩展性较好，可以根据业务的变化进行维度表和事实表的迭代更新。
二、星型模型设计方法星型模型（Star Schema）是一种以事实表为核心，将维度表与事实表的关系以星形布局的数据模型。
它同样采用了星型的结构，但是与星座模型相比，更加简单和扁平化。
1. 星型模型的组成星型模型主要由一个事实表和多个维度表组成。
事实表记录了业务的度量数据，如销售额、库存量等。
维度表描述业务中的一些固定属性，如产品、时间、地理位置等。
维度表与事实表的关联通过事实表中的外键实现。
2. 星型模型的优点星型模型具有以下几点优点：（1）简单易懂：星型模型的结构简单，易于理解和维护。
（2）查询性能高：星型模型的查询性能较好，对于简单的查询需求，能够快速响应。
（3）数据冗余度低：星型模型中的维度表具有高度规范化，数据冗余度低。
三、星座模型与星型模型的比较星座模型和星型模型是数据仓库设计中常用的两种方法，它们在一些方面有相似之处，也有一些不同之处。
ODS数据建模
ODS数据建模知识:ODS数据建模知识:这是IBM的ODS解决方案中关于数据建模技术的论述，ODS文档很大，是叫做操作数据存储的一种解决数据满足较为实时需求的方案，有区于面向战略的数据仓库。
其中的数据建模部分的介绍如下：当业务企业型数据模型存在时，可从该模型导出ODS数据模型。
企业型数据模型描述了公司在收集信息方面所需要的所有数据。
ODS数据模型是企业数据模型的子集。
仅为ODS数据模型提取真正需要的那些部分。
提示：数据模型更多地从功能/部门级以上创建。
使用此方法，更难预见企业的所有要求。
即使在严格意义上某个商业单位并不是企业，它也可以由此获得实质性好处。
有两种不同的数据建模方法可以满足ODS的需要：实体关系模型(ERM)维度建模 (两种不同的数据建模方式)我们将介绍这两种方法，并针对何时使用它们提供一些建议。
3.3.1 ERM建模由于ERM可用于理解和简化商业领域和复杂系统环境中的模糊数据关系，因此它是一种抽取工具。
图3-11显示了一个简单的ERM（可惜不能插图，但er图对我们来讲耳熟能详了）。
ERM建模方法可使用以下两个基本概念产生特定兴趣领域的数据模型：实体实体之间的关系实体实体可定义为人、地点、事情，以及商业或组织的相关事件—例如“产品”，如图3-11所示。
实体代表一类对象，它们是现实世界中可以按属性和特征进行观察和分类的一些事物。
关系关系描述模型中各实体之间的结构性交互和关联。
它显示了实体间的相关性—例如，图3-11中，箭头从“产品”指向“订单”。
箭头每一端的数字定义了关系的基数，本例中为1对n（或1对多）。
大多数ODS实施3NF模型。
这类模型最初是为最小化数据冗余而设计的，因为该模型在值发生改变时，可使数据库中的更新数量达到最小。
此功能说明了它对OLTP数据库的价值以及现在更新ODS数据库时的价值。
3.3.2 维度建模维度建模是一种将数据模型概念化和形象化为一组可用一般商业概念描述的度量的技术。
数据仓库中的维度建模及数据挖掘方法研究
数据仓库中的维度建模及数据挖掘方法研究数据仓库是一个存储、管理以及分析大量数据的系统，它主要用于支持企业的决策制定过程。
数据仓库之所以能够支持复杂的决策制定过程，是因为它采用了维度建模的方法。
维度建模是一种特殊的建模方法，它能够清晰明确地描述一个业务过程，从而帮助业务分析师快速梳理和理解业务需求，为决策制定提供有效的支持。
维度建模的方法主要是通过维度和度量来描述业务过程，其中维度是业务过程的属性，度量是对这些属性进行度量的指标。
比如，某个零售公司希望了解其销售数据，可以采用时间、地点、商品、客户等维度来描述销售过程，而销售额、销售数量等度量则是这些维度数据的分析结果。
在维度建模的基础上，数据挖掘则是一个更深入的分析过程。
它不仅仅是对维度和度量进行分析，还需要探索这些数据之间的关系，找出潜在的模式和规律。
数据挖掘可以应用于许多领域，如金融、医疗、营销等，帮助企业识别新的机会和挑战，并制定相应的决策。
在实践中，我们可以采用OLAP(On-line Analytical Processing)工具和数据挖掘算法来分析数据仓库中的数据。
OLAP工具可以提供很多分析功能，如多维分析、数据切割、统计、图形分析等，帮助用户快速获取业务洞察。
数据挖掘算法则可以帮助用户发现有用的信息和模式，如关联规则挖掘、分类算法、聚类算法等。
值得一提的是，虽然维度建模和数据挖掘在不同层次的数据分析过程中具有不同的应用，但二者是互相关联、互相支持的。
事实上，维度建模提供了用于分析的维度和度量，而数据挖掘则需要这些维度和度量作为分析的对象。
因此，在实践中，我们需要在维度建模和数据挖掘之间建立良好的连接，将业务需求转化为有效的分析方法，并通过数据挖掘方法提取出有用的信息和模式。
总之，数据仓库中的维度建模和数据挖掘是数据分析的重要方法，它们帮助企业发掘潜在的商业机会，并优化决策制定过程。
在实践中，我们需要综合应用OLAP工具和数据挖掘算法，将业务需求转化为有效的分析方法，并从数据中挖掘出有用的信息和模式。
数据模型基本概念及建模方法论
崔大强 技术经理
NCR(中国)有限公司数据仓库事业部
内容安排
什么是数据模型 数据模型相关术语 数据模型方法论 建模注意事项
2
什么是数据模型？
以数学的方式对现实事物的一种抽象表达,„ 特征： 内容：描述了数据、及其之间的关系 形式：反映了数据的组织与管理形式
设计人员：业务人员、IT人员
设计目标
设计蓝图，指导整个数据仓库系统的建设 业务语言，业务人员与技术人员沟通的手段和方法 业务视图，独立于数据库技术实现
设计内容：实体、关系和属性 建模方法：3NF的设计方法 后续工作：物理数据模型的输入
7
物理数据模型
Physical Data Model（PDM）物理数据模型
解
决 方 案 集 成
使用工具：
ERWin
交付项目：
物理数据模型（PDM） 《物理数据模型说明书》 《数据库描述语言DDL》
33
物理数据模型命名规范
序号 主题
1 PARTY 2 OFFER
缩写
PAR OFR
中文
参与人 产品策划
3 FINANCE
4 LOCATION 5 ADVERTISEMENT 6 EVENT 7 NETWORK 8 REFERENCE CODE
31
Step 5: 确认模型 (2)
1. 通过回答以下问题，持续地对模型的范围进行验证: • • 这一模型组件的含义、与业务的关系是什么？ 这一模型组件驱动的业务需求是什么？
2. 对模型是否已经满足所有业务需求、业务问题及限制条件等，进行验证 3. 绝对不要考虑任何与物理实施相关的问题！ 4. 当所有回答业务需求所必须的数据已经齐备时，停止对模型进行优化
数据仓库设计步骤
数据仓库设计步骤数据仓库是一个用于集中存储、管理和分析大量数据的系统。
它的设计过程是一个复杂的任务，需要经历多个步骤。
下面是数据仓库设计的主要步骤：1.需求分析：首先，需要与业务用户和利益相关者合作，了解业务需求和目标。
这包括理解他们的数据分析需求、业务流程和决策支持要求。
这一步骤有助于确定数据仓库应该包含哪些数据和所需的数据分析功能。
2.数据源分析：在这一步骤中，需要识别和分析所有可用的数据源，包括内部和外部系统。
需要评估这些数据源的数据质量、结构和可用性，以确定应该选择哪些数据源。
3.数据抽取、转换和加载（ETL）：在这个步骤中，需要确定如何从不同的数据源中提取数据，并将其转换为适合数据仓库的格式。
这包括数据清洗、数据集成和数据转换等过程。
ETL过程还应该能够处理数据的增量更新和历史数据的保留。
4.数据模型设计：在这一步骤中，需要设计数据仓库的逻辑模型和物理模型。
逻辑模型通常使用维度建模技术，包括维度表和事实表来描述数据。
物理模型则定义了如何将逻辑模型映射到实际的存储结构，包括数据库表和索引设计等。
5.数据仓库架构设计：在这一步骤中，需要确定数据仓库的整体架构。
这包括确定数据仓库的结构、数据存储和访问机制。
需要考虑到数据仓库的可伸缩性、性能和可用性等方面。
6.数据仓库实施：在这个步骤中，需要根据设计的数据模型和架构来实施数据仓库。
这包括创建数据库表、索引、视图等。
还需要实施ETL过程和相关的数据访问工具。
7.数据质量管理：数据质量是数据仓库设计中一个重要的方面。
在这一步骤中，需要定义数据质量规则和度量，并实施数据质量管理的过程。
这包括数据清洗、数据验证和数据监控等活动。
8.元数据管理：在数据仓库中，元数据是描述数据的数据。
在这一步骤中，需要定义和管理元数据，以便用户能够理解数据的含义和含义。
这包括建立元数据仓库、元数据标准和元数据管理工具等。
9.安全和访问控制：在这一步骤中，需要制定数据仓库的安全策略和访问控制机制。
数据仓库设计与建模的星座模型与星型模型比较(五)
数据仓库设计与建模的星座模型与星型模型比较传统上，数据仓库的设计与建模是数据管理和分析的关键步骤。
为了使数据仓库能够更好地支持决策和分析需求，不同的模型方法被提出和实践。
其中，星座模型和星型模型是两种常用的数据仓库设计和建模方法。
本文将对这两种模型进行比较，并讨论它们在不同环境下的适用性和局限性。
一、星座模型星座模型，也称为雪花模型，是一种以事实表为中心，围绕其展开的多维模型。
在星座模型中，事实表是数据仓库的核心，用于存储事实事件的指标数据。
而维度表则是用来描述事实表中指标的上下文信息，如时间、地点、产品等。
星座模型的主要特点是简单直观，易于理解和使用。
星座模型的优点在于：1. 数据冗余度低：通过将共同属性的维度表分离，可以减少冗余数据的存储和管理。
2. 简单的查询：星座模型的结构简单，查询性能较高，适用于快速的多维分析。
3. 灵活性强：星座模型的扩展性好，能够根据需要灵活地添加或删除维度。
然而，星座模型也存在一些限制：1. 表关系复杂：由于星座模型采用了多个维度表与一个事实表的关系，处理表关系较为复杂，增加了数据仓库的维护难度。
2. 存储空间浪费：星座模型中可能存在重复存储的问题，因为相同属性的维度可以出现在多个维度表中。
二、星型模型相对于星座模型，星型模型更加简单和直观。
在星型模型中，每个维度都有一个独立的表，而事实表则连接所有维度表。
星型模型的特点是结构清晰，易于理解和管理。
星型模型的优点包括：1. 数据模型简单：由于每个维度都有一个独立的表，星型模型的结构更加清晰明了，便于理解和管理。
2. 使用方便：星型模型的查询和分析相对简单，易于使用和操作。
然而，星型模型也有其局限性：1. 数据冗余度高：由于每个维度表都存储了冗余的数据，导致存储空间的浪费。
2. 查询性能低：与星座模型相比，星型模型在多维查询和分析方面性能相对较低。
三、适用性和局限性无论是星座模型还是星型模型，都有各自的适用场景和局限性。
4种数据仓库建模方法
引言概述在数字化时代，数据成为企业运营和决策的重要驱动力。
为了更好地管理和利用企业数据，很多企业采用数据仓库来集成和存储数据。
数据仓库建模是数据仓库设计的核心环节，它决定了数据在仓库中的组织结构和查询方式。
本文将介绍四种常见的数据仓库建模方法，包括维度建模、实体关系模型、标准化模型以及主题建模。
维度建模维度建模是一种以事实表和维度表作为核心的建模方法。
事实表是存储数值型数据的表，维度表则存储描述性属性的表。
在维度建模中，事实表和维度表通过共享主键来建立关联。
小点详细阐述：1.事实表的设计：事实表应选择合适的粒度，并包含与业务流程相关的度量。
例如，销售事实表可以包含销售额、销售数量等度量。
2.维度表的设计：维度表应包含与业务流程相关的描述性属性，例如时间、产品、地理位置等。
维度应具有层次结构，以便支持多维分析。
3.关系型数据库实现：维度建模通常使用关系型数据库来实现，它通过表和关联键来表示维度和事实之间的关系。
实体关系模型实体关系模型是一种基于关系代数和数据库范式的建模方法。
它通过实体、属性和关系来描述数据的结构。
实体关系模型适用于较复杂的数据仓库场景，其中数据具有多层级和复杂的关系。
小点详细阐述：1.实体的建模：实体是数据仓库中的核心对象，它代表了业务流程中的实际对象。
实体的属性描述了实体的特征。
2.关系的建模：关系描述了实体间的关联和依赖关系。
在实体关系模型中，关系通过外键建立。
3.数据库范式：实体关系模型追求高度的数据规范化，以减少数据冗余和不一致性。
标准化模型标准化模型是一种以消除冗余数据为核心的建模方法。
在标准化模型中，数据被拆分为多个表，并通过关系建立关联。
小点详细阐述：1.数据拆分：标准化模型通过将数据拆分为多个表，将重复的数据存储在一个地方，并通过外键建立关联。
2.数据插入和查询：标准化模型在数据插入和查询时需要进行多表关联操作，对性能有一定影响。
3.适用场景：标准化模型适用于事务性场景，如订单管理、库存管理等。
数据仓库的数据模型
业务驱动任何需求均来源于业务,业务决定了需求,需求分析的正确与否是关系到项目成败的关键所在,从任何角度都可以说项目是由业务驱动的所以数据仓库项目也是由业务所驱动的.但是数据仓库不同于日常的信息系统开发,除了遵循其他系统开发的需求,分析,设计,测试等通常的软件声明周期之外;他还涉及到企业信息数据的集成,大容量数据的阶段处理和分层存储,数据仓库的模式选择等等,因此数据仓库的物理模型异常重要,这也是关系到数据仓库项目成败的关键.数据仓库的结构总的来说是采用了三级数据模型的方式:概念模型: 也就是业务模型,由企业决策者,商务领域知识专家和IT专家共同企业级地跨领域业务系统需求分析的结果.逻辑模型：用来构建数据仓库的数据库逻辑模型。
根据分析系统的实际需求决策构建数据库逻辑关系模型,定义数据库物体结构及其关系。
他关联着数据仓库的逻辑模型和物理模型这两头.物理模型：构建数据仓库的物理分布模型,主要包含数据仓库的软硬件配置,资源情况以及数据仓库模式。
如上图所示,在数据仓库项目中,物理模型设计和业务模型设计象两个轮子一样有力的支撑着数据仓库的实施,两者并行不悖,缺一不可.实际上,我有意的扩大了物理模型和业务模型的内涵和外延.在这里物理模型不仅仅是数据的存储,而且也包含了数据仓库项目实施的方法论,资源,以及软硬件选型等等;而业务模型不仅仅是主题模型的确立,也包含了企业的发展战略,行业模本等等.一个优秀的项目必定会兼顾业务需求和行业的标准两个方面,业务需求即包括用户提出的实际需求,也要客观分析它隐含的更深层次的需求,但是往往用户的需求是不明确的,需要加以提炼甚至在商务知识专家引导下加以引导升华,和用户一起进行需求分析工作;不能满足用户的需求,项目也就失去原本的意义了.物理模型就像大厦的基础架构,就是通用的业界标准,无论是一座摩天大厦也好,还是茅草房也好,在架构师的眼里,他只是一所建筑,地基->层层建筑->封顶,这样的工序一样也不能少,关系到住户的安全,房屋的建筑质量也必须得以保证,唯一的区别是建筑的材料,地基是采用钢筋水泥还是石头,墙壁采用木质还是钢筋水泥或是砖头;当然材料和建筑细节还是会有区别的,视用户给出的成本而定;还有不可忽视的一点是,数据仓库的数据从几百GB到几十TB不等,即使支撑这些数据的RDBMS无论有多么强大,仍不可避免的要考虑到数据库的物理设计.接下来,将详细阐述数据仓库概念模型(业务模型),逻辑模型,物理模型的意义.概念模型设计进行概念模型设计所要完成的工作是:界定系统边界确定主要的主题域及其内容确定主题域的关系概念模型设计是，在原有的业务数据库的基础上建立了一个较为稳固的概念模型。