数据仓库设计理论
数据仓库设计理论
一、数据仓库基本概念
1.1、数据仓库介绍
数据仓库是一个用于集成、存储和分析大量结构化和非结构化数据的中心化数据存储系统。它旨在支持企业的决策制定和业务分析活动。
1.2、基本特征
- 主题导向：数据仓库围绕特定的主题或业务领域进行建模和组织，例如销售、客户、供应链等。这种主题导向的设计使得数据仓库更加聚焦和专注，便于用户进行特定领域的查询和分析。
- 集成性：数据仓库整合来自多个数据源的数据，包括企业内部的各种操作数据库、事务系统以及外部的第三方数据供应商等。这一步是数据仓库建设中关键且复杂的一步，因为要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不一致，等等。
- 历史数据存储：数据仓库通常存储历史数据，包括过去的业务交易记录、事件数据等。这使得用户可以进行时间趋势分析、历史数据比较和预测分析等，帮助企业理解和解释业务的演变和趋势。
- 可扩展性：数据仓库需要能够支持大规模数据存储和高性能的查询和分析操作。它需要具备可扩展性，能够处理不断增长的数据量和用户访问量，并保持良好的性能和响应时间。
- 决策支持：数据仓库旨在支持企业的决策制定和业务分析活动。它提供了强大的查询和分析工具，使用户能够快速访问和分析数据，获取有关业务趋势、关键指标、决策支持等方面的信息。
- 数据安全和权限控制：数据仓库涉及大量敏感的企业数据，因此数据安全和权限控制是非常重要的。数据仓库需要采取适当的安全措施，包括数据加密、用户身份验证、访问控制等，以保护数据的机密性和完整性。
这些基本特征使得数据仓库成为企业管理和决策制定的重要工具。它提供了全面、一致和高质量的数据，帮助企业用户从大量的数据中提取有价值的信息，做出准确、及时的决策，并促进企业的业务发展和竞争优势。
1.3、数据仓库核心架构
1.4、设计步骤（重要）
数据仓库设计涉及四个关键步骤：数据分层、数据建模、表设计、数据治理。
- 数据分层：将数据仓库系统划分为多个层级，常见的分层包括原始数据层(ODS)，数据仓库层(DW)，数据应用层(ADS)等。分层的目的是将数据处理和集成任务划分为不同阶段，提高数据管理和维护效率。
- 数据建模：将业务需求转化为可操作的数据模型。常见的建模方法有范式建模和维度建模。范式建模消除冗余和重复数据，以多个表组织数据；维度建模以事实表和维度表为核心，定义维度和度量，支持灵活查询和分析。
- 表设计：根据需求和数据量选择全量表、增量表、流水表、拉链表等类型，考虑存储和查询效率、灵活性和可扩展性。
- 数据治理：数据治理也是数据仓库设计中的一个关键方面，它涉及规定和管理数据的标准、血缘关系和规则，以确保数据的质量、一致性和可靠性。数据治理还包括数据安全和合规性，以确保数据在存储和处理过程中得到保护。
这四个步骤相互依赖，通过分层划分任务；数据建模定义数据结构和语义；表设计实现具体表结构；数据治理确保数据的质量、安全性和合规性；综合执行这些步骤，可以建立一个高效、可靠且适合业务需求的数据仓库。
二、数据仓库分层理论
2.1、数据仓库分层介绍
数据仓库之所以要进行分层，是为了提高数据管理和处理的效率，以及支持灵活的数据分析和查询。以下是分层的主要目的和好处：
- 数据管理和维护：分层可以将数据仓库系统划分为多个层级，每个层级负责不同的任务和数据处理过程。这样可以简化数据管理和维护的复杂性，使数据流程更加清晰和可控，每个层级可以专注于特定的数据处理操作。
- 数据质量控制：通过分层，可以在每个阶段对数据质量进行验证和控制，错误或低质量的数据可以在早期被发现和处理，避免对后续分析和决策的影响。
- 灵活的数据分析：通过分层，数据仓库可以支持不同层级和粒度的数据分析。较低层级的数据可以用于更细粒度的操作和分析，较高层级的数据可以用于更高层次的汇总和报表。分层的设计使得数据仓库具有灵活性和可扩展性，能够满足不同层次和角度的数据需求。
2.2、分层设计架构
2.3、各层功能介绍
- ODS（操作数据存储层）：ODS层是数据仓库中的第一层，用于存储操作系统的源数据或事务级数据。它主要用于数据抽取、存储和数据质量验证，保留了数据的原始形态。ODS层中的数据通常以近实时或实时的方式进行抽取，并进行简单的数据清洗和转换，以便后续处理使用。
- DWD（数据明细化层-事实 ）：DWD层是数据仓库中的核心层，用于存储经过清洗、整合和转换后的明细数据。在DWD层中，数据被重新结构化，使其适合进行复杂的分析和查询操作。DWD层通常包含多个事实明细表，每个表代表一个业务事实，例如订单、用户、产品等。它是数据仓库的基础，支持各种维度的分析和报表需求。
- DIM（维度层）：DIM层是数据仓库中的维度数据存储层，用于存储描述业务对象的维度表。维度表包含与业务相关的属性和维度信息，如时间、地区、产品、用户等。维度表的作用是提供多维度的分析能力，将事实数据与维度数据进行关联和筛选，支持多角度的数据分析和查询操作。
- DWS（汇总数据层）：DWS层是数据仓库中的汇总层，用于存储经过聚合和汇总后的数据。在DWS层中，数据被按照不同的维度进行汇总和聚合，以提供更高层次的数据分析和报表需求。DWS层的设计可以根据业务需求进行灵活的聚合和汇总策略，以提高查询性能和响应速度。
- ADS（数据应用层）：ADS层是数据仓库中的应用数据存储层，用于存储针对特定应用需求的数据。在ADS层中，数据被进一步加工和优化，以适应特定的应用场景，如数据挖掘、机器学习、报表生成等。ADS层的设计可以根据具体应用需求进行灵活的数据模型设计和数据处理操作。
三、数据建模理论（DWD、DIM）
2.1、数据建模介绍
数据建模是指在设计和构建数据仓库或数据库系统时，对数据进行结构化和组织的过程。它是将现实世界中的业务需求和数据之间建立关联的方法和技术; 数据建模的目标是创建一个合理的数据模型，以便能够有效地存储、管理和使用数据。通过数据建模，可以定义数据的结构、关系和约束，从而使数据能够按照特定的业务需求进行查询、分析和操作。
数据仓库的建模方法有很多种，每一种建模方法代表一个观点，代表了一种归纳、概括世界的一种方法。常见的有：范式建模法、维度建模法、实体建模法等，每种方法从本质上将是从不同的角度看待业务中的问题。
数据建模理论主要针对数据仓库中的DWD、DIM层
2.2、范式建模（关系型数据库）
范式建模法是一种常用的数据建模方法，旨在通过规范化数据结构，减少数据冗余和数据异常，提高数据的一致性和灵活性。它基于关系数据库理论和范式概念，通过将数据分解为多个表并建立关系来达到优化数据存储和操作的目的。
范式建模法主要包括以下几个范式：
- 第一范式（1NF）：确保每个数据字段的原子性，即每个字段都不可再分。在1NF中，每个表的每个列都包含原子值，不允许多值属性或重复的属性。
- 第二范式（2NF）：在1NF的基础上，消除非主属性对候选键的部分函数依赖。简单来说，2NF要求将非主键属性与主键完全依赖，不能依赖于部分主键。
- 第三范式（3NF）：在2NF的基础上，消除非主属性对候选键的传递依赖。3NF要求非主键属性之间不存在传递依赖关系，即一个非主键属性不能依赖于另一个非主键属性。
如下图：
在关系型数据库的模型设计中，一般采用第三范式
2.3、维度建模法（数据仓库）
维度建模法是一种常用的数据建模方法，特别适用于数据仓库和商业智能领域。它通过将数据组织成维度表和事实表的结构，以实现对业务过程的分析和报告。维度建模法注重对业务过程的理解和建模，以及对数据的分层和聚焦，使得数据仓库更易于使用和理解。
在维度建模法中，有两个核心概念：维度和事实。
- 维度（Dimensions）：维度是描述业务过程的特征或属性的数据元素。它们提供了用于分析和过滤数据的上下文信息。常见的维度包括时间、地理位置、产品、客户、销售渠道等。维度通常作为维度表的基础，每个维度表对应一个特定的业务维度。
- 事实（Facts）：事实是与业务过程相关的可度量的数据，即衡量业务过程中发生事件的数量或金额。事实表是存储事实数据的主要表，每个事实表通常包含多个度量（Measure）列，用于记录具体的业务指标，如销售额、销售数量、利润等。事实表通常与多个维度表进行关联，形成维度模型。
维度建模法的特点和优势包括：
- 简单直观：维度建模法以业务过程为中心，使数据模型更加直观和易于理解，便于业务用户参与数据分析和报表设计。
- 灵活可扩展：维度建模法支持灵活的数据分析和报表需求，可以方便地添加新的维度或度量，适应业务的变化和扩展。
- 查询性能优化：维度建模法通过合理的表设计和关联关系，优化了查询性能，使得数据检索和报表生成更高效。
- 可重用性和共享性：维度建模法中的维度表和事实表是可重用和共享的，可以为不同的报表和分析需求提供数据支持，避免了重复开发和数据冗余。
如下图：
在数据仓库的模型设计中，一般采用维度建模
三、维度建模三种模式
3.1、星型模式（常用）
星型模型是一种常用的维度建模方法，用于设计数据仓库和商业智能系统中的数据模型。它得名于其图形表示形式，其中一个中心事实表与多个维度表以星状结构连接在一起；在星型模型中，中心事实表包含与业务过程相关的度量数据，如销售额、销售数量、利润等。维度表则包含与业务过程相关的描述性属性，如时间、地理位置、产品、客户等。
星型模型的主要特点和组成部分包括：
- 中心事实表（Fact Table）：中心事实表是星型模型的核心，存储与业务过程相关的度量数据。它通常包含一个或多个度量列，用于记录业务指标的数值。每一行表示一个业务事件或事实，例如一次销售交易。
- 维度表（Dimension Tables）：维度表是星型模型的周围，存储与业务过程相关的描述性属性。每个维度表对应一个特定的业务维度，如时间维度、产品维度、客户维度等。维度表包含多个属性列，用于描述维度的不同特征。
- 主键-外键关联：在星型模型中，维度表与中心事实表之间建立主键-外键关联关系。维度表的主键列作为外键出现在中心事实表中，用于连接维度和事实数据。这种关联关系使得可以通过维度属性进行数据的聚合和筛选。
星型模型的优点包括：
- 简单直观：星型模型的结构清晰，易于理解和使用，使得数据模型更加直观和易于维护。
- 灵活可扩展：星型模型支持灵活的数据分析和报表需求，可以方便地添加新的维度或度量，适应业务的变化和扩展。
- 查询性能优化：通过合理的表设计和关联关系，星型模型优化了查询性能，使得数据检索和报表生成更高效。
- 易于数据共享：星型模型中的维度表是可重用和共享的，可以为不同的报表和分析需求提供数据支持，避免了重复开发和数据冗余。
如下图：
星型模型是一种常用的维度建模方法，通过中心事实表和维度表的组合，实现对业务过程的数据分析和报表展示。它具有简单、灵活和高性能的特点，适用于大多数数据仓库和商业智能项目。
3.2、雪花模式（较少）
雪花模型是一种在维度建模中常用的数据模型，它是在星型模型基础上的一种扩展和改进。与星型模型类似，雪花模型也由中心事实表和多个维度表组成，但在维度表的组织方式上有所不同；在雪花模型中，维度表被进一步规范化，即将维度表中的某些属性细分为更小的维度表，形成多层维度表的结构。这样的规范化使得模型呈现出类似雪花的形状，因而得名为雪花模型。
雪花模型的主要特点和组成部分包括：
- 中心事实表（Fact Table）：中心事实表是雪花模型的核心，存储与业务过程相关的度量数据。它与星型模型中的中心事实表类似，记录业务指标的数值。
- 规范化的维度表（Dimension Tables）：在雪花模型中，维度表被规范化为多个层级的维度表。每个维度表代表一个特定的业务维度，如时间维度、产品维度、客户维度等。规范化的维度表通过主键-外键关系连接起来，形成多层级的维度结构。
- 层级维度表（Hierarchical Dimension Tables）：在雪花模型中，规范化的维度表可以进一步划分为多个层级维度表。每个层级维度表代表维度的不同层级，例如时间维度可以包括日期维度、月份维度、年份维度等。这样的层级结构可以更好地支持多层级的数据分析和报表需求。
- 主键-外键关联：与星型模型类似，雪花模型中的维度表之间通过主键-外键关联建立关系。维度表的规范化和层级化使得关联关系更加复杂，需要在查询时进行多次表连接。
雪花模型的优点包括：
- 更高的数据规范性：通过规范化和层级化的维度表，雪花模型提供了更高的数据规范性，使数据模型更加精细和准确。
- 支持多层级分析：由于层级维度表的存在，雪花模型可以更好地支持多层级的数据分析和报表需求，如从日期到月份再到年份的数据分析。
- 更好的数据冗余控制：通过规范化维度表，雪花模型可以减少数据冗余，提高数据存储效率和一致性。
然而，雪花模型也存在一些缺点，包括：
- 查询性能较低：由于需要进行多次表连接操作，查询性能相对较低，特别是在多层级的数据分析中。
- 复杂的模型设计和维护：雪花模型的规范化和层级化增加了模型的复杂性，对模型的设计和维护要求更高。
如下图：
雪花模型是一种相对于星型模型更规范化和层级化的数据模型，在某些场景下能提供更准确和详细的数据分析和报表需求支持，但需要权衡查询性能和模型的复杂性。在实际应用中，选择适合业务需求和数据特点的模型是很重要的。
3.3、星座模型（常用）
"星座模型"通常是指多个星型模型之间的关联和集成，以构建更复杂的数据仓库结构。星座模型是一种用于解决大规模数据仓库中数据集成和查询性能问题的方法。
在星座模型中，多个星型模型通过共享维度表进行关联。这些维度表包含了共同的维度属性，例如时间、地点、产品等。通过在不同的星型模型之间共享维度表，可以实现跨模型的数据集成和查询。
星座模型的主要目的是提高数据仓库的灵活性和性能。通过将数据仓库划分为多个独立的星型模型，并通过共享维度表进行关联，可以减少数据冗余并提高查询性能。此外，星座模型还提供了更高级别的数据聚合和分析功能。
如下图：
五、建模及汇总层设计步骤（重要）
5.1、基本流程
5.2、数据调研
数据调研是指对源系统和相关数据进行深入调查和分析，以了解数据的结构、内容、质量等方面的情况。这包括与业务用户、数据所有者和数据负责人的沟通，收集数据需求和了解数据源系统的运作方式。数据调研的目的是为了获取对数据的全面了解，为后续的数据建模和设计提供基础。
数据调研的主要步骤包括：
- 了解业务需求：与业务用户和利益相关者沟通，了解他们的需求、业务流程和分析目标。这有助于明确数据仓库的目标和重点，以及需要收集的数据内容。
- 收集源数据：与源系统的数据所有者或相关人员合作，收集源数据的相关文档、数据库模式、数据字典等信息。这些信息可以帮助了解源数据的结构、字段含义、数据类型和数据质量等方面的情况。
- 理解业务含义：通过与业务用户和数据所有者的交流，深入了解数据的业务含义、数据流程和数据关系。这有助于理解数据的上下文和业务规则，从而更好地设计数据模型和定义维度和度量。
- 制定数据转换和清洗策略：根据数据调研的结果，制定数据转换、清洗和集成的策略。这包括确定数据转换规则、处理缺失值、处理数据不一致性等方面的措施，以确保数据仓库中的数据质量和一致性。
5.3、明确数据域
在数据仓库设计中，"数据域"指的是在业务领域或组织内特定的数据集合或数据范围。它代表了数据仓库所关注的业务或功能范围；数据域可以是一个业务过程、一个功能模块、一个部门或一个特定的业务领域。
假设我们正在设计一个零售业务的数据仓库。我们首先进行数据调研来了解业务需求和数据来源。在这个过程中，我们可能会与销售团队、采购团队、库存管理团队以及财务团队等业务部门进行会议和访谈，了解他们的数据需求和业务流程。
在分析业务流程后，我们可能识别出以下几个重要的数据主题或数据域：
- 销售数据域：包括销售订单、销售额、销售渠道等与销售业务相关的数据。
- 采购数据域：包括采购订单、供应商信息、采购成本等与采购业务相关的数据。
- 库存数据域：包括库存数量、库存变动、库存预警等与库存管理业务相关的数据。
- 客户数据域：包括客户信息、客户分类、客户行为等与客户管理业务相关的数据。
- 财务数据域：包括收入、支出、利润、成本等与财务管理业务相关的数据。
5.4、构建业务总线矩阵（重要）
5.4.1、业务总线矩阵介绍
这一步尤为重要，业务总线矩阵中包含维度模型所需的所有事实（业务过程）以及维度，以及各业务过程与各维度的关系。矩阵的行是一个个业务过程，矩阵的列是一个个的维度，行列的交点表示业务过程与维度的关系。
如下图：
5.4.2、构建业务总线矩阵步骤
5.4.3、步骤介绍
- 选择业务过程：根据数据域确定数据模型的焦点范围，选择具体的业务过程。例如在交易域中可以确定：订单过程、支付过程、退款过程。
- 声明粒度：确定数据模型中的粒度，即确定数据模型中每个事实记录所代表的业务事件的级别和详细程度，注意在同一事实表中，必须具有相同的粒度，同一事实表中不要混用多种不同的粒度，不同的粒度数据要建立不同的事实表。
- 确认维度：确定数据模型中的维度，即描述业务过程的属性或特征。维度通常是描述业务上下文的属性，例如时间、地点、产品、客户等。维度为事实提供了上下文和分析维度。在确认维度时，需要考虑维度的层次结构和关系。
- 确认事实度量值：确定数据模型中的事实，即业务过程中可以量化和衡量的指标或度量。事实通常是与业务过程相关的数值数据，例如销售额、数量、成本、利润等。事实是数据模型中的关键指标，用于支持业务分析和决策。
5.5、维度模型设计（DWD、DIM）
上一步业务总线构建成功后，一个业务过程即对应一张事实表，一个维度即对应一张维度表。
5.6、明确统计指标（为DWS层做准备）
5.6.1、统计指标介绍
上述维度设计完毕后，开始考虑明确统计指标；明确统计指标是指对于业务需求和分析目的，明确定义需要进行统计和度量的指标或度量值。这些统计指标用于衡量和量化业务活动、绩效、趋势等关键方面，以支持数据分析和决策。
5.6.2、统计指标分类
- 原子指标：原子指标基于某一业务过程的度量值，是业务定义中不可再拆解的指标，原子指标的核心功能就是对指标的聚合逻辑进行了定义，例如订单总额就是一个典型的原子指标，其中的业务过程为用户下单、度量值为订单金额，聚合逻辑为sum()求和。需要注意的是原子指标只是用来辅助定义指标一个概念，通常不会对应有实际统计需求与之对应。
- 派生指标：派生指标基于原子指标，其与原子指标的关系如下图所示:
- 衍生指标: 衍生指标是在一个或多个派生指标的基础上，通过各种逻辑运算复合而成的。例如比率、比例等类型的指标。衍生指标也会对应实际的统计需求
5.7、汇总模型设计（DWS[重要]）
5.7.1、汇总表设计原则
根据应用层展示的维度字段进行设计，汇总表一般是按天分区的增量表，BI数据展示只需获取当天分区内数据即可
5.7.2、示例
例1：页面展示(维度是省会)
汇总层：交易域省份粒度订单金额汇总表
| 省份ID | ISO-3166-2编码 | 省份名称 | 当天订单金额 | 7天订单金额 | 30天订单金额 | 年度订单金额 |
|---|---|---|---|---|---|---|
| 1 | CN-HLJ | 黑龙江 | 5000 | 35000 | 100000 | 500000 |
| 2 | CN-LN | 辽宁 | 3000 | 25000 | 80000 | 400000 |
| 3 | CN-SD | 山东 | 4500 | 30000 | 90000 | 450000 |
| 4 | CN-SX | 山西 | 2000 | 18000 | 60000 | 300000 |
| … | … | … | … | … | … | … |
例1中由于展示字段是省份故汇总层应以省份为核心字段，且汇总当天、7天、30天、年度订单金额供应用展示
例2：页面展示(维度是日期)
汇总层：
交易域当天粒度订单金额汇总表
| ID | 日期时间 | 订单金额 |
|---|---|---|
| 001 | 2023-07-19 00:00 | $50 |
| 002 | 2023-07-19 01:00 | $25 |
| 003 | 2023-07-19 02:00 | $40 |
| 004 | 2023-07-19 03:00 | $60 |
| 005 | 2023-07-19 04:00 | $30 |
| 006 | 2023-07-19 05:00 | $70 |
| 007 | 2023-07-19 06:00 | $90 |
| 008 | 2023-07-19 07:00 | $120 |
| 009 | 2023-07-19 08:00 | $80 |
| 010 | 2023-07-19 09:00 | $45 |
交易域7天粒度订单金额汇总表
| ID | 日期 | 订单金额 |
|---|---|---|
| 001 | 2023-07-13 | $200 |
| 002 | 2023-07-14 | $350 |
| 003 | 2023-07-15 | $180 |
| 004 | 2023-07-16 | $420 |
| 005 | 2023-07-17 | $300 |
| 006 | 2023-07-18 | $270 |
| 007 | 2023-07-19 | $320 |
总结：汇总表设计原则是根据应用层展示的维度字段进行设计，汇总表一般是按天分区的增量表，BI数据展示只需获取当天分区内数据即可
六、数据仓库表设计理论
看：数据仓库表设计理论
七、数据治理理论
看：数据治理设计理论
八、数据仓库发展史
看：数据仓库发展历史