数据仓库模型的设计
数据仓库多维数据模型的设计
1、数据仓库基本概念1.1、主题（Subject）主题就是指我们所要分析的具体方面。
例如：某年某月某地区某机型某款App的安装情况。
主题有两个元素：一是各个分析角度（维度），如时间位置；二是要分析的具体量度，该量度一般通过数值体现，如App安装量。
1.2、维（Dimension）维是用于从不同角度描述事物特征的，一般维都会有多层（Level：级别），每个Level 都会包含一些共有的或特有的属性（Attribute），可以用下图来展示下维的结构和组成：以时间维为例，时间维一般会包含年、季、月、日这几个Level，每个Level一般都会有ID、NAME、DESCRIPTION这几个公共属性，这几个公共属性不仅适用于时间维，也同样表现在其它各种不同类型的维。
1.3、分层（Hierarchy）OLAP需要基于有层级的自上而下的钻取，或者自下而上地聚合。
所以我们一般会在维的基础上再次进行分层，维、分层、层级的关系如下图：每一级之间可能是附属关系（如市属于省、省属于国家），也可能是顺序关系（如天周年），如下图所示：1.4、量度量度就是我们要分析的具体的技术指标，诸如年销售额之类。
它们一般为数值型数据。
我们或者将该数据汇总，或者将该数据取次数、独立次数或取最大最小值等，这样的数据称为量度。
1.5、粒度数据的细分层度，例如按天分按小时分。
1.6、事实表和维表事实表是用来记录分析的内容的全量信息的，包含了每个事件的具体要素，以及具体发生的事情。
事实表中存储数字型ID以及度量信息。
维表则是对事实表中事件的要素的描述信息，就是你观察该事务的角度，是从哪个角度去观察这个内容的。
事实表和维表通过ID相关联，如图所示：1.7、星形/雪花形/事实星座这三者就是数据仓库多维数据模型建模的模式上图所示就是一个标准的星形模型。
雪花形就是在维度下面又细分出维度，这样切分是为了使表结构更加规范化。
雪花模式可以减少冗余，但是减少的那点空间和事实表的容量相比实在是微不足道，而且多个表联结操作会降低性能，所以一般不用雪花模式设计数据仓库。
数据仓库中的多维数据模型设计与实现教程
数据仓库中的多维数据模型设计与实现教程在数据仓库中，多维数据模型设计与实现是一项关键任务。
它不仅可以帮助企业组织和分析庞大的数据量，还能提供决策支持和洞察力。
本文将介绍数据仓库中多维数据模型的概念、设计原则以及实现方法，帮助读者全面了解和掌握这一重要主题。
一、多维数据模型的概念多维数据模型是基于数据的特征和关联性来组织数据的一种模型。
它通过将数据按照不同的业务维度进行分组和分类，将数据以多维方式呈现，从而提供了更加直观和灵活的数据分析能力。
多维数据模型主要由维度、度量和层次结构组成。
1. 维度：维度是描述业务问题的属性，它可以是时间、地理位置、产品、客户等。
维度用来描述数据的特征，例如销售额可以按照时间、地理位置和产品维度进行分析。
2. 度量：度量是可以进行数值计算和分析的数据，例如销售额、利润、数量等。
度量用来描述数据的量度，便于进行各种统计分析。
3. 层次结构：层次结构是维度之间的关系，它描述了维度之间的层次结构和上下级关系。
例如时间维度可以由年、月、日等层次结构组成。
二、多维数据模型的设计原则在设计多维数据模型时，需要遵循一些原则，以确保模型的合理性和有效性。
1. 简单性：多维数据模型应该尽可能简单，避免过于复杂的维度和层次结构。
简单的模型易于理解和维护，提高数据分析效率。
2. 一致性：多维数据模型中的维度和度量应该保持一致性，避免冗余和重复。
一致的模型有助于提高查询效率和数据一致性。
3. 可扩展性：多维数据模型应该具有良好的扩展性，能够容纳未来的需求变化和数据增长。
设计时需要考虑到未来可能发生的维度扩展和度量变化。
4. 性能优化：多维数据模型的设计也要考虑到查询性能的优化。
根据实际需求和查询模式，合理设计维度的层次结构、聚集表和索引等，以提高查询效率。
三、多维数据模型的实现方法在实现多维数据模型时，需要选择合适的工具和技术来支持模型的构建和数据的加载。
1. 数据抽取和转换：多维数据模型的实现通常需要进行数据抽取和转换，将源系统的数据转化为可用于多维模型的格式。
数据仓库模型的设计
数据仓库模型的设计数据仓库模型的设计大体上可以分为以下三个层面的设计151:.概念模型设计;.逻辑模型设计;.物理模型设计;下面就从这三个层面分别介绍数据仓库模型的设计。
2.5.1概念模型设计进行概念模型设计所要完成的工作是:<1>界定系统边界<2>确定主要的主题域及其内容概念模型设计的成果是，在原有的数据库的基础上建立了一个较为稳固的概念模型。
因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等，然后再来考虑应当如何建立数据仓库系统的概念模型。
一方面，通过原有的数据库的设计文档以及在数据字典中的数据库关系模式，可以对企业现有的数据库中的内容有一个完整而清晰的认识;另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。
概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。
1.界定系统的边界数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了设计人员的面前:. 要做的决策类型有哪些?. 决策者感兴趣的是什么问题?. 这些问题需要什么样的信息?. 要得到这些信息需要包含原有数据库系统的哪些部分的数据?这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。
因而，从某种意义上讲，界定系统边界的工作也可以看作是数据仓库系统设计的需求分析，因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。
2，确定主要的主题域在这一步中，要确定系统所包含的主题域，然后对每个主题域的内容进行较明确数据仓库建模技术在电信行业中的应用的描述，描述的内容包括:. 主题域的公共码键;. 主题域之间的联系:. 充分代表主题的属性组。
数据仓库的数据模型设计和数据库系统的数据模型设计有什么不同
数据仓库的数据模型设计和数据库系统的数据模型设计
有什么不同
1.目的和应用：
数据仓库的数据模型设计主要用于支持分析和决策支持系统。
它的目标是将来自多个操作性数据库的数据集成在一个统一的存储中，以便于查询和分析。
数据库系统的数据模型设计主要用于支持业务应用系统的操作和事务处理。
2.数据结构：
3.数据粒度：
4.数据复杂性：
5.数据访问模式：
数据仓库的数据模型设计支持复杂的查询操作，如多维分析和数据挖掘等。
因此，数据仓库的数据模型设计通常需要进行优化，以提高查询性能和响应时间。
数据库系统的数据模型设计则更注重事务处理和并发控制等方面的性能优化。
总结起来，数据仓库的数据模型设计和数据库系统的数据模型设计主要在目的、数据结构、数据粒度、数据复杂性和数据访问模式等方面有所不同。
数据仓库的数据模型设计更注重于支持分析和决策支持系统，采用星型或雪花型的数据结构，关注大量和高层次的数据，需要复杂的数据转换和清洗过程，并进行查询性能优化。
数据库系统的数据模型设计更注重于支持业务应用系统的操作和事务处理，采用关系模型的结构，关注细节
和实时的操作数据，不需要涉及复杂的数据处理过程，并进行事务和并发性能的优化。
数据仓库建模
数据仓库建模数据仓库建模是指根据业务需求和数据分析目标，对数据仓库进行设计和构建的过程。
它包括数据仓库的架构设计、数据模型设计、ETL（提取、转换和加载）流程设计等方面。
以下是关于数据仓库建模的详细介绍。
1. 数据仓库架构设计：数据仓库架构设计是数据仓库建模的第一步，它确定了数据仓库的整体结构和组织方式。
常见的数据仓库架构包括星型模型、雪花模型和星座模型等。
在架构设计中，需要考虑数据仓库的数据来源、数据存储方式、数据访问方式等因素，以确保数据仓库的高效性和可扩展性。
2. 数据模型设计：数据模型设计是数据仓库建模的核心环节，它定义了数据仓库中的数据结构和关系。
常用的数据模型包括维度模型和事实模型。
维度模型主要用于描述业务维度和维度之间的关系，而事实模型主要用于描述业务事实和事实之间的关系。
在数据模型设计中，需要根据具体业务需求，确定维度和事实的属性，并建立它们之间的关联关系。
3. ETL流程设计：ETL流程设计是数据仓库建模的关键环节，它负责将源系统中的数据提取、转换和加载到数据仓库中。
ETL流程包括数据抽取、数据清洗、数据转换和数据加载等步骤。
在ETL流程设计中，需要考虑数据抽取的频率、数据清洗的规则、数据转换的逻辑和数据加载的方式等因素，以确保数据仓库中的数据质量和一致性。
4. 数据仓库建模工具：数据仓库建模通常使用一些专业的建模工具，如PowerDesigner、ERwin等。
这些工具提供了丰富的建模功能，可以帮助数据仓库建模人员快速设计和构建数据仓库。
在使用建模工具时，需要熟悉工具的操作流程和功能，以提高建模效率和质量。
5. 数据仓库建模的最佳实践：在进行数据仓库建模时，需要遵循一些最佳实践，以确保数据仓库的高效性和可维护性。
首先，需要与业务人员紧密合作，深入了解业务需求和数据分析目标，以确保数据仓库的建模结果能够准确满足业务需求。
其次，需要遵循一致性和标准化的建模规范，以确保数据仓库中的数据结构和关系的一致性和可理解性。
数据仓库设计与建模的流程与方法
数据仓库设计与建模的流程与方法数据仓库是一个用于集中存储、管理和分析企业中各类数据的系统。
它旨在帮助企业更好地理解和利用自己的数据资源，支持决策和战略制定。
数据仓库的设计与建模是数据仓库开发的关键步骤之一。
本文将介绍数据仓库设计与建模的流程与方法。
数据仓库设计与建模流程数据仓库设计与建模是一个迭代的过程，包括以下主要步骤：1.需求收集和分析在数据仓库设计与建模之前，首先需要与业务用户和决策者进行充分的沟通和需求收集。
了解用户的需求和业务流程对于数据仓库的设计和建模至关重要。
通过与用户的交流，收集到的需求可以被细化和明确以指导后续的工作。
2.数据源选择和数据抽取确定需要从哪些数据源抽取数据，并选择合适的数据抽取工具或技术。
根据需求收集和分析的结果，进行数据抽取和转换，将源系统的数据导入到数据仓库中。
这个步骤是数据仓库设计与建模中的重要部分，关系到数据质量和数据一致性。
3.物理数据模型设计在物理数据模型设计阶段，将逻辑数据模型转化为物理数据模型。
物理数据模型设计包括确定表、字段、索引、分区等物理数据库对象的详细定义。
需要考虑到性能和存储方面的因素，并根据数据仓库的查询需求进行优化设计。
4.维度建模维度建模是数据仓库设计与建模的核心技术之一。
它通过标识和定义业务过程中的关键业务概念，如事实表、维度表和维度属性，来描述业务应用中的事实和维度关系。
维度建模的目标是提供用户友好的数据表示，支持灵活且高效的数据查询和分析。
5.粒度定义和聚合设计决定数据仓库的数据粒度是数据仓库设计与建模的一个重要决策。
粗粒度数据更适合用于高层次的分析和决策，而细粒度数据则支持更详细的数据分析。
聚合设计是为了提高数据仓库的性能和查询响应时间而进行的，它通过预计算和存储汇总数据来减少复杂查询的计算量。
6.元数据管理元数据是指描述数据的数据，是数据仓库设计与建模过程中不可忽视的一部分。
元数据管理包括收集、维护和管理数据仓库中的元数据信息，为数据仓库开发、运维和使用提供支持。
EDW_(DM数据仓库数据建模)模型设计
大客户分析管理系统
企
运营报表 仪表盘
业
信
息 门 户 数据挖 掘引擎 数据挖 掘应用
保险数据模型
数据集市
元数据库
为什么需要企业模型？
数据集市之间数据一致性
包含全部历史的核心数据
一致的事实表和维度
EDW 数据模型在项目实施中的作用
DWM 数据仓库模型
业务量分析 数据集市
车险承保分析 通用承保分析
核心业务 财务系统 再保险系统 人意险系统 精算系统 aCRM 数据集市 客户关系 管理OCRM ALM 客户讯息 ECIF 财务分析 数据集市 外部数据 财务分析 应用 ALM应用 业务持续性 分析数据集市 风险管理 应用
监管报表
管理报表
“数据和信息集成平台” “统一的分析平台” “唯一的信息出口”
带anchor的实体
带status表的实体（Commercial agreement、Group agreement、Individual agreement、 Claim folder、Elementary claim） 不带status表的实体
除表的主键、type id、Partition key、Status、Status date、Status reason、 Valid from date、Valid to date、 Effective from date、Effective to date、 Population timestamp之外的所有字段 除表的主键、 type id、 Partition key、 Valid from date、Valid to date、Effective from date、Effective to date、 Population timestamp之外的所有字段
4种数据仓库建模方法
引言概述在数字化时代，数据成为企业运营和决策的重要驱动力。
为了更好地管理和利用企业数据，很多企业采用数据仓库来集成和存储数据。
数据仓库建模是数据仓库设计的核心环节，它决定了数据在仓库中的组织结构和查询方式。
本文将介绍四种常见的数据仓库建模方法，包括维度建模、实体关系模型、标准化模型以及主题建模。
维度建模维度建模是一种以事实表和维度表作为核心的建模方法。
事实表是存储数值型数据的表，维度表则存储描述性属性的表。
在维度建模中，事实表和维度表通过共享主键来建立关联。
小点详细阐述：1.事实表的设计：事实表应选择合适的粒度，并包含与业务流程相关的度量。
例如，销售事实表可以包含销售额、销售数量等度量。
2.维度表的设计：维度表应包含与业务流程相关的描述性属性，例如时间、产品、地理位置等。
维度应具有层次结构，以便支持多维分析。
3.关系型数据库实现：维度建模通常使用关系型数据库来实现，它通过表和关联键来表示维度和事实之间的关系。
实体关系模型实体关系模型是一种基于关系代数和数据库范式的建模方法。
它通过实体、属性和关系来描述数据的结构。
实体关系模型适用于较复杂的数据仓库场景，其中数据具有多层级和复杂的关系。
小点详细阐述：1.实体的建模：实体是数据仓库中的核心对象，它代表了业务流程中的实际对象。
实体的属性描述了实体的特征。
2.关系的建模：关系描述了实体间的关联和依赖关系。
在实体关系模型中，关系通过外键建立。
3.数据库范式：实体关系模型追求高度的数据规范化，以减少数据冗余和不一致性。
标准化模型标准化模型是一种以消除冗余数据为核心的建模方法。
在标准化模型中，数据被拆分为多个表，并通过关系建立关联。
小点详细阐述：1.数据拆分：标准化模型通过将数据拆分为多个表，将重复的数据存储在一个地方，并通过外键建立关联。
2.数据插入和查询：标准化模型在数据插入和查询时需要进行多表关联操作，对性能有一定影响。
3.适用场景：标准化模型适用于事务性场景，如订单管理、库存管理等。
数据库设计时如何合理规划数据模型
数据库设计时如何合理规划数据模型在当今数字化的时代，数据库成为了各类应用系统的核心组成部分。
一个良好的数据库设计不仅能够提高数据的存储和检索效率，还能确保数据的完整性、一致性和安全性。
而在数据库设计中，合理规划数据模型是至关重要的一步。
首先，我们要明确业务需求。
这就好比在建造房屋之前，需要清楚知道房屋的用途、居住人数以及功能要求等。
在数据库设计中，我们需要与业务部门深入沟通，了解他们的业务流程、数据操作方式以及对数据的使用需求。
例如，一个电商平台需要存储商品信息、用户信息、订单信息等，而一个医院管理系统则需要存储患者信息、病历信息、医疗设备信息等。
只有明确了这些业务需求，我们才能为后续的数据模型规划提供准确的方向。
接下来，进行概念模型设计。
概念模型是对现实世界的抽象描述，它不涉及具体的数据库实现技术，而是专注于描述实体、属性以及它们之间的关系。
以一个学校管理系统为例，实体可以是学生、教师、课程、班级等，属性则是每个实体所具有的特征，如学生的姓名、年龄、学号等。
关系则包括学生与课程的选课关系、教师与班级的授课关系等。
通过绘制 ER 图（实体关系图）等工具，可以清晰地展现概念模型。
在完成概念模型设计后，就可以进入逻辑模型设计阶段。
逻辑模型是概念模型在具体数据库管理系统中的实现，常见的逻辑模型有关系模型、层次模型和网状模型等，目前关系模型应用最为广泛。
在关系模型中，我们将概念模型中的实体转化为表，属性转化为列，关系则通过外键来实现。
例如，在上述学校管理系统中，学生表可能包含学号、姓名、年龄等列，课程表可能包含课程号、课程名、学分等列，而选课表则通过学生的学号和课程的课程号作为外键来建立学生与课程之间的选课关系。
在设计数据表时，需要合理确定字段的数据类型。
数据类型的选择不仅影响数据的存储效率，还可能影响数据的查询和更新性能。
例如，对于整数类型，如果存储的值范围较小，可以选择 tinyint 或 smallint 类型，而如果值范围较大，则需要选择 int 或 bigint 类型。
数据仓库中的维度建模与星型模型设计
数据仓库中的维度建模与星型模型设计一、维度建模概述维度建模是数据仓库中用于设计和组织数据的一种方法，通过将数据按照业务维度进行组织，可以更好地支持分析和报告需求。
在维度建模中，数据被组织成事实表和维度表，事实表包含度量数据，维度表包含描述数据。
1.事实表事实表是数据仓库中的核心表，包含了业务度量的数据，例如销售额、数量等。
事实表通常与一个或多个维度表关联，以提供上下文和细节信息。
2.维度表维度表包含了描述性数据，用来描述事实表中的度量数据。
维度表通常包含了一些维度属性，例如时间、产品、地点等，这些属性用来对度量数据进行细分和分析。
二、星型模型星型模型是一种常用的维度建模方法，它将事实表置于中心，周围围绕着多个维度表，形成一个星型的结构。
星型模型的设计简单直观，易于理解和查询，适用于大多数数据仓库场景。
1.优点星型模型的设计简单明了，易于维护和扩展。
由于事实表与维度表之间的关联简单明确，查询性能较高。
同时，星型模型也更符合人类的直觉思维，易于业务用户理解和应用。
2.缺点星型模型存在一些缺点，例如维度表冗余数据多、扩展性差等。
此外，星型模型可能无法满足复杂的分析需求，对于一些复杂的数据关系可能不够灵活。
三、星型模型设计步骤设计一个星型模型需要经过一系列步骤，包括需求收集、概念设计、逻辑设计、物理设计等。
每个步骤都需要注意一些关键要点，以确保设计出满足业务需求的数据仓库模型。
1.需求收集在设计星型模型之前，首先需要与业务用户沟通，了解业务需求和数据分析目的。
根据需求收集到的信息，确定需要设计的事实表和维度表。
2.概念设计在概念设计阶段，需要定义事实表和维度表之间的关系，确定维度键和外键。
还需要考虑数据粒度、度量数据和维度属性等内容。
3.逻辑设计在逻辑设计阶段，需要对模型进行细化，定义表的结构、字段和关系。
需要考虑到数据的规范化和冗余，以确保数据的一致性和完整性。
4.物理设计在物理设计阶段，需要根据具体的数据仓库平台和技术选型，将逻辑设计转换为物理模型。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2.5数据仓库模型的设计数据仓库模型的设计大体上可以分为以下三个层面的设计151:.概念模型设计;.逻辑模型设计;.物理模型设计;下面就从这三个层面分别介绍数据仓库模型的设计。
2.5.1概念模型设计进行概念模型设计所要完成的工作是:<1>界定系统边界<2>确定主要的主题域及其内容概念模型设计的成果是，在原有的数据库的基础上建立了一个较为稳固的概念模型。
因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等，然后再来考虑应当如何建立数据仓库系统的概念模型。
一方面，通过原有的数据库的设计文档以及在数据字典中的数据库关系模式，可以对企业现有的数据库中的内容有一个完整而清晰的认识;另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。
概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。
1.界定系统的边界数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了设计人员的面前:. 要做的决策类型有哪些?. 决策者感兴趣的是什么问题?. 这些问题需要什么样的信息?. 要得到这些信息需要包含原有数据库系统的哪些部分的数据?这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。
因而，从某种意义上讲，界定系统边界的工作也可以看作是数据仓库系统设计的需求分析，因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。
2，确定主要的主题域在这一步中，要确定系统所包含的主题域，然后对每个主题域的内容进行较明确数据仓库建模技术在电信行业中的应用的描述，描述的内容包括:. 主题域的公共码键;. 主题域之间的联系:. 充分代表主题的属性组。
2.5.2逻辑模型设计逻辑建模是数据仓库实施中的重要一环，因为它能直接反映出业务部门的需求，同时对系统的物理实施有着重要的指导作用。
在这一步里进行的工作主要有:. 分析主题域，确定当前要装载的主题;. 确定粒度层次划分;. 确定数据分割策略;. 关系模式定义;. 记录系统定义逻辑模型设计的成果是，对每个当前要装载的主题的逻辑实现进行定义，并将相关内容记录在数据仓库的元数据中，包括:. 适当的粒度划分;. 合理的数据分割策略;. 适当的表划分;. 定义合适的数据来源等。
I.分析主题域在概念模型设计中，我们确定了几个基本的主题域，但是，数据仓库的设计方法是一个逐步求精的过程，在进行设计时，一般是一次一个主题或一次若干个主题地逐步完成的。
所以，我们必须对概念模型设计步骤中确定的几个基本主题域进行分析，一并选择首先要实施的主题域。
选择第一个主题域所要考虑的是它要足够大，以便使得该主题域能建设成为一个可应用的系统;它还要足够小，以便于开发和较快地实施。
如果所选择的主题域很大并且很复杂，我们甚至可以针对它的一个有意义的子集来进行开发。
在每一次的反馈过程中，都要进行主题域的分析。
z.粒度层次划分数据仓库逻辑设计中要解决的一个重要问题是决定数据仓库的粒度划分层次，粒度层次划分适当与否直接影响到数据仓库中的数据量和所适合的查询类型。
确定数据仓库的粒度划分，可以使用在粒度划分一节中介绍的方法，通过估算数据行数和所需的DASD数，来确定是采用单一粒度还是多重粒度，以及粒度划分的层次。
3.确定数据分割策略在这一步里，要选择适当的数据分割的标准，一般要考虑以下几方面因素:数据量〔而非记录行数)、数据分析处理的实际情况、简单易行以及粒度划分策略等。
数据量的大小是决定是否进行数据分割和如何分割的主要因素;数据分析处理的要求是选择数据分割标准的一个主要依据，因为数据分割是跟数据分析处理的对象紧密联系的;我们还要考虑到所选择的数据分割标准应是自然的、易于实施的:同时也要考虑数据分割的标准与粒度划分层次是适应的。
4.关系模式定义数据仓库的每个主题都是由多个表来实现的，这些表之间依靠主题的公共码键联系在一起，形成一个完整的主题。
在概念模型设计时，我们就确定了数据仓库的基本主题，并对每个主题的公共码键、基本内容等做了描述在这一步里，我们将要对选定_的当前实施的主题进行模式划分，形成多个表，并确定各个表的关系模式。
用关系型数据库来实现数据仓库信息模型时，目前较常用的两种建模方法是所谓的第三范式(3NF,即Third Normal Form)和星型模式Star-Schem司，我们将重点讨论两种方法的特点和它们在数据仓库系统中的适用场合。
4.1什么是第三范式范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程也称为规范化(Normalize)。
在数据仓库的模型设计中目前一般采用第三范式，它有非常严格的数学定义。
如果从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件:1.每个属性的值唯一，不具有多义性;2.每个非主属性必须完全依赖于整个主键，而非主键的一部分;3.每个非主属性不能依赖于其他关系中的属性，团为这样的话，这种属性应该归到其他关系中去。
我们可以看到，第三范式的定义基本上是围绕主键与非主属性之间的关系而作出的。
如果只满足第一个条件，则称为第一范式;如果满足前面两个条件，则称为第二范式，依此类推。
因此，各级范式是向下兼容的。
4.2什么是星型模式星型模式是一种多维的数据关系，它由一个事实表(Fact Table)和一组维表(Dimension Table)组成。
每个维表都有一个维作为主键，所有这些维则组合成事实表的主键，换言之，事实表主键的每个元素都是维表的外键。
事实表的非主属性称为事实(Fact)，它们一般都是数值或其他可以进行计算的数据;而维大都是文字、时间等类型的数据。
与星型模式类似还有一种业界提的比较多的设计方式是雪花模式，它也是一种在关系数据库中实现多维数据关系的方式，与星型模式相区别的是它的维表结构与星型模式不同。
星型模式中同一维度的不同层次位于一张维表中，维表由唯一主键和事实表关连;雪花模式中同一维度中的不同层次位于不同的层次表中，最低层次表与事实表关连，各个层次再分别和比自己高一级的层次表关连。
因为星型模式查询效率要比雪花模式高的多，所以比较多的是采用星型模式设计多维数据关系。
4. 3第三范式和星型模式在数据仓库中的应用大多数人在设计中央数据仓库的逻辑模型时，都按照第三范式来设计;而在进行物理实施时，则由于数据库引擎的限制，不得不对逻辑模型进行不规范处理(De-Normalize)，以提高系统的响应速度，这当然是以增加系统的复杂度、维护工作量、磁盘使用比率(指原始数据与磁盘大小的比率)并降低系统执行动态查询能力为代价的。
根据数据仓库的测试标准TPC-D规范，在数据仓库系统中，对数据库引擎最大的挑战主要是这样几种操作:多表连接、表的累计、数据排序、大量数据的扫描。
下面列出了一些DBMS在实际系统中针对这些困难所采用的折衷处理办法:1、如何避免多表连接:在设计模型时对表进行合并，即所谓的预连接(Pre-Join)。
当数据规模小时，也可以采用星型模式，这样能提高系统速度，但增加了数据冗余量。
2、如何避免表的累计:在模型中增加有关小计数据(Summarized Data)的项。
这样也增加了数据冗余，而且如果某项问题不在预建的累计项内，需临时调整。
3、如何避免数据排序:对数据事先排序。
但随着数据仓库系统的运行，不断有新的数据加入，数据库管理员的工作将大大增加。
大量的时间将用于对系统的整理，系统的可用性随之降低。
4、如何避免大表扫描:通过使用大量的索引，可以避免对大量数据进行扫描。
但这也将增加系统的复杂程度，降低系统进行动态查询的能力。
这些措施大都属于不规范处理。
根据上面的讨论，当把规范的系统逻辑模型进行物理实施时，由于数据库引擎的限制，常常需要进行不规范处理。
举例来说，当系统数据量很小，比如只有几个GB时，进行多表连接之类复杂查询的响应时间是可以忍受的。
但是设想一下加果数据量扩展到很大，到几百GB，甚至上TB,一个表中的记录往往有几百万、几千万，甚至更多，这时进行多表连接这样的复杂查询，响应时间长得不可忍受。
这时就有必要把几个表合并，尽量减少表的连接操作。
当然，不规范处理的程度取决于数据库引擎的并行处理能力。
数据仓库建设者在选择数据库引擎时，除了参考一些相关的基准测试结果外，最好是能根据自己的实际情况设计测试方案，从几个数据库系统中选择最适合自己企业决策要求的一种。
不规范化处理虽然是提高系统性能的一种有效手段，但是由于中央数据仓库的数据模型反映了整个企业的业务运行规律，在这里进行不规范处理容易影响整个系统，不利于今后的扩展。
而且不规范处理产生的数据冗余将使整个系统的数据量迅速增加，这将增加DBA的工作量和系统投资。
因此，当系统性能下降而进行不规范处理时，比较好的办法是选择问题较集中的部门数据集市实施这种措施。
这样既能有效地改善系统性能汉不至于影响整个系统。
在国外一些成功的大型企业级数据仓库案例中，基本上都是采用这种方法。
那么，在中央数据仓库中是否可以采用星型模式来进行模型设计呢?我们知道，星型模式中有一个事实表和一组维表，我们可以把事实看成是各个维交叉点上的值。
例如，一个汽车厂在研究其销售情况时可以考察汽车的型号、颜色、代理商等多种因素，这些因素就是维，而销售量就是事实。
这种多维模型能迅速给出基于各个维的报表，这些维必须事先确定。
星型模式之所以速度快，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。
在上面的例子中，就是按照汽车的型号、颜色、代理商进行预先的销售量统计。
因此，在星型模式设计的数据仓库中，作报表的速度虽然很快，但由于存在大量的预处理，其建模过程相对来说就比较慢。
当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。
由于事实表的主键由所有维表的主键组成，这种维的变动将是非常复杂、非常耗时的。
星型模式另一个显著的缺点是数据的冗余量很大。
综合这些讨论，不难得出结论，星型模式比较适合于预先定义好的问题加需要产生大量报表的场合;而不适合于动态查询多、系统可扩展能力要求高或者数据量很大的场合。
因此，星型模式在一些要求大量报表的部门数据集市中有较多的应用。
4. 4两种模式的比较上面讨论了数据仓库逻辑模型设计中常用的两种方法.在数据仓库的应用环境中，主要有两种负载:一种是回答重复性的问题;另一种是回答交互性的问题。
动态查询具有较明显的交互性特征，即在一个问题答案的基础上进行进一步的探索，这种交互过程常称为数据挖掘(Data Mining)或者知识探索(Knowledge Discovery)。