数据架构 - 数据建模方法



数据建模数据架构的重要组成部分。这意味着要规划如何在系统中组织、存储和使用数据。本章介绍不同的数据建模方法,帮助您学习如何为您的组织创建有用的数据模型。

目录

本章将涵盖以下与数据建模相关的主题

什么是数据建模?

数据建模是数据库设计中一项重要的技术。它包括确定需要存储哪些数据,并将数据组织到表和列中,以显示不同数据片段之间的关系。这种结构可以应用于不同类型的数据库,包括关系型数据库和NoSQL数据库。

关系型建模

关系型建模Edgar F. Codd于1970年提出。它将数据组织成表(关系),每个表包含记录的行和属性的列。这种方法使用键来显示表之间的关系,有助于维护数据准确性并更容易检索信息。

关系型建模中的键

关系型建模中,键对于保持数据库的组织性和准确性非常重要。它们有助于唯一地标识每条记录,并显示不同表之间的连接方式。以下是一些关键类型。

  • 主键:这是表中每条记录的唯一标识符,例如学生表中的StudentID。
  • 外键:外键是一个表中的一列,它链接到另一个表中的主键,从而创建关系。例如,销售表中的ProductKey连接到产品表中的产品。
  • 自然键:一个已经存在的唯一字段,用作主键,例如社会安全号码(政府颁发的用于识别个人的号码)。

实体关系图

通常,您从实体关系(ER)图开始关系型建模。该图显示了数据库的不同部分(实体)以及它们是如何连接的(关系)。完成ER图后,您可以创建一个更详细的模型,其中包括数据库的实际表和列。

这就是创建ER图的方法。

ER Diagram

在上图的ER图中,我们表示学生课程实体。以下是我们所做的简要说明

  • 实体:该图包含两个主要实体:学生课程
  • 属性:该图列出了学生和课程实体的属性。学生实体具有以下属性:
    • StudentID(唯一标识符)
    • 姓名(组合:名,中间名,姓)
    • 电话号码(多值属性)
    课程实体包括:
    • Cou_ID(唯一标识符)
    • 名称(课程名称)
  • 弱实体:成绩是一个弱实体,它依赖于学生和课程实体。
  • 关系:注册关系连接学生和课程,这意味着一个学生可以注册多门课程。获得关系连接学生和成绩,表明一个学生可以获得多个成绩。
  • 关系中的关键属性
    • 注册关系可能包括注册日期和状态。
    • 获得关系可能包括成绩日期。
  • 组合和多值属性:学生实体的名称属性是组合属性,而电话号码是多值属性。

ER图组件

该图包含几个组件,显示实体如何相互关联。以下是创建ER图中使用的关键组件。

ER Diagram

用于数据完整性的规范化规则

创建ER图后,应用规范化。规范化是一个将复杂数据库分解成更简单表的过程。这有助于减少重复数据并提高信息的准确性。该过程包括几个步骤,称为范式

  • 第一范式 (1NF):此范式确保表被正确组织。它要求:
    • 表具有主键。
    • 每列只有一值。
    • 没有重复的列组。
  • 第二范式 (2NF):基于1NF,此范式确保:
    • 它满足1NF的所有条件。
    • 每个非键列仅依赖于主键。
  • 第三范式 (3NF):基于1NF,此范式确保:
    • 它满足1NF和2NF的所有条件。
    • 非键列必须直接连接到主键,而不是通过另一列。

使用历史表跟踪更改

关系型数据库中,跟踪随时间推移的更改非常重要。为此,我们使用历史表。这些表是原始表的副本,但它们具有额外的列来记录重要的细节,例如:

  • 时间戳:更改发生的时间。
  • 用户ID:更改发生的时间。
  • 之前/之后的值:更改之前的数值和更改后的新数值。

历史表对于审计、报告和数据恢复非常有帮助。它们为您提供了数据随时间推移如何变化的完整视图。

维度建模

维度建模始于1996年,目的是简化数据的分析和查询。它将数据分为两部分:事实(即数字或数据点)和维度(即提供上下文,如类别或日期)。当常规数据库变得缓慢或难以使用时,此方法很有用。它通常采用这些传统数据库中的数据来创建更有效的信息分析方式。

维度建模中的事实

在维度建模中,“事实”是衡量特定指标(如销售额或收入)的数值数据点。这些事实可以组合或汇总,例如查找平均值或总计,这使得更容易分析数据。这样,您可以快速从大型信息集中发现有用的见解。

维度建模中的维度

在维度建模中,“维度”有助于解释事实。它们描述有关数据的重要详细信息,例如时间、产品或客户信息。维度通常组织成层次结构,允许更深入的数据分析。事实表存储数值数据,而维度表则保留描述此数据的相关详细信息。

维度建模中的键

维度建模中,我们通常使用代理键作为主键而不是自然键。代理键是专门创建的人工值,用于唯一标识数据库中的记录,当自然键不可用或不合适时,它们很有用。

自然键可以提供有意义的信息,但它们也有一些缺点。

  • 它们可能更长更复杂。
  • 它们可能包含敏感信息,这可能会引发隐私问题。
  • 在组合来自不同系统的数据时,它们可能会导致重复或不一致。

跟踪维度建模中的更改

维度建模中,我们使用缓慢变化维度 (SCD) 来跟踪数据中的更改,这有助于管理数据随时间的变化方式。共有三种类型。

  • 类型1:此类型用新数据替换旧数据。它用于不需要保留旧信息的小型更改,例如更正电话号码。
  • 类型2:此类型保留数据的新旧版本。它用于跟踪随时间的变化,例如当客户搬到新地址时,确保我们拥有准确的历史信息。
  • 类型3:此类型为每次更改创建一个新记录,保留数据的完整历史记录。虽然它更复杂,但它允许我们保留所有更改的详细记录。

历史表与缓慢变化维度

历史表缓慢变化维度 (SCD) 都跟踪数据中的更改,但它们采用不同的方式。

  • 历史表:这些表保留每条记录的完整更改历史记录。它们跟踪记录随时间的每个版本,允许您查看对特定条目所做的所有更改。
  • 缓慢变化维度 (SCD):缓慢变化维度专注于管理维度表中的更改,维度表存储有关数据的详细信息。它们允许使用类型1、类型2和类型3等方法进行清晰且结构化的更新。SCD确保历史数据保持准确和可靠,从而更容易分析随时间的趋势。

历史表提供了每条记录所有更改的完整视图,而缓慢变化维度则侧重于维度数据随时间的变化方式。这样,我们可以确保历史信息准确且易于查找。

维度建模中的反规范化

反规范化意味着在维度建模中将数据复制到多个表中。这通过减少表数和所需的连接数来简化数据库,从而使查询运行速度更快,并帮助您更轻松地创建报表。

但是,保持此复制数据的一致性可能很困难。例如,如果类别名称更改,则必须在维度模型中的多个位置更新它。在关系模型中,您只需更新一次,这有助于防止错误。

比较维度模型和关系模型

在数据管理中,维度模型关系模型是两种不同的方法。维度模型旨在简化数据分析,而关系模型则专注于准确地组织数据。

  • 维度模型
    • 这些模型有利于分析数据和了解业务绩效。
    • 它们可以有效地处理许多表,从而加快查询速度并简化报告。
  • 关系模型
    • 如果数据以标准的表格形式(带有行和列)组织,则这些模型更容易设置。
    • 它们专注于保持数据的正确性和减少重复,但这可能会减慢分析速度。

维度建模使用不同的布局,例如星型和雪花型模式。星型模式有一个主表,周围环绕着其他表,使其清晰易懂。

维度模型更适合于分析数据,而关系模型提供了一种清晰的管理数据的方式。两者之间的选择取决于业务需求和数据的复杂程度。

数据建模中的通用数据模型

公共数据模型 (CDM) 是一种用于存储和组织数据,尤其是在数据仓库中的标准方法。它创建了一种清晰一致的表格数据表示方式,使不同的系统更容易理解和使用这些信息。

当从不同的来源(例如各种客户关系管理 (CRM) 系统)导入数据时,只使用一个系统的格式是不切实际的。每个系统可能具有不同的表结构和字段名称,这可能会导致混淆。相反,您应该创建一个新的公共数据模型 (CDM),将所有这些格式整合到一个清晰的结构中。此公共数据模型 (CDM) 将足够灵活,以满足您当前和未来的数据需求。许多云提供商提供易于定制的特定行业 CDM,帮助您节省时间并降低数据集成风险。

数据仓库建模

数据仓库建模是由 Daniel Linstedt 于 2000 年开发的一种组织数据的方法。它提供了一种灵活可靠的方式来管理历史数据,从而更容易跟踪随时间推移的变化。

数据仓库模型具有三个主要部分

  • 中心表 (Hubs): 这些表代表重要的业务概念,例如客户或产品,并具有唯一的 ID。
  • 链接表 (Links): 这些表显示中心表之间是如何关联的,使用连接到中心表 ID 的键。
  • 卫星表 (Satellites): 这些表保存有关中心表或链接表的额外详细信息,例如随时间的变化,并通过键连接。

数据仓库的缺点

虽然数据仓库建模提供了灵活性和清晰的历史数据管理方法,但它也面临一些挑战,这些挑战可能会影响其工作效率和设置难度。

  • 复杂性: 设置数据仓库建模可能很复杂,需要熟练的专业人员进行管理。
  • 数据重复: 存储详细数据可能会导致重复条目,从而增加存储成本。
  • 性能: 拥有许多表可能会降低数据检索速度,使查询变得更加复杂。
  • 缺乏标准化: 由于它是一种较新的方法,因此可能很难找到经验丰富的数据仓库建模工程师。

Kimball和Inmon数据仓库方法论

本节介绍构建数据仓库的两种主要方法:Inmon 方法Kimball 方法。每种方法都有其自身的优点和挑战,正确的选择取决于您组织的需求。

Inmon 的自顶向下方法

Inmon 方法从收集来自不同来源信息的中央数据仓库开始。之后,将为特定部门创建使用中央仓库数据的小型数据市场。这种结构化的方法通常受到注重数据质量的大型组织的青睐。

Inmon 方法中的流程

  • 数据暂存:首先,数据从不同的来源快速收集到临时表中,而无需任何更改。
  • 企业信息工厂 (CIF):接下来,数据在一个中心位置进行组织,作为组织的主要事实来源。
  • 从属数据市场:在设置CIF之后,将为不同的部门创建小型数据市场,使用中心数据作为其信息来源。

优点:这种方法有助于保持较高的数据质量,并且适用于具有复杂数据需求的大型组织。

挑战:它可能导致数据重复,从而增加存储成本并使维护更加困难。

Kimball 的自底向上方法

Kimball 方法首先将原始数据收集到称为暂存表的临时表中,而无需对其进行清理。此方法侧重于首先创建独立的数据市场,这些数据市场旨在满足不同业务领域的特定需求。然后将这些数据市场连接起来,以提供数据的完整视图。

Kimball 方法中的流程

  • 独立数据市场:每个数据市场都是为特定部门构建的,使用简单的模型来简化分析。
  • 集成:数据市场通过公共维度链接,确保所有领域保持一致。
  • 用于报告的立方体:数据可以组织成立方体,这使得可以从不同的角度查看数据变得容易。这有助于您快速找到重要的见解。

优点:这种方法鼓励用户参与,从而导致更好的数据管理。它还减少了重复存储相同数据的可能性。

挑战:如果管理不善,数据市场之间可能会存在差异,这可能会导致混淆和不准确的报告。

Inmon 和 Kimball 之间的区别

本节显示了InmonKimball 方法之间的主要区别,重点关注每种方法如何满足不同的需求。

  • 起点:Inmon 从创建收集来自不同来源数据的中央数据仓库开始。相比之下,Kimball 从一开始就专注于构建单独的数据市场,以满足不同部门的特定需求。
  • 结构:Inmon 强调物理中央数据仓库,它充当组织的单一事实来源。然而,Kimball 允许更大的灵活性,使组织无需严格的中央仓库即可创建数据市场。
  • 适应性:Inmon 和 Kimball 都可以适应现代数据实践,例如使用数据湖。这种灵活性有助于组织跟上不断变化的数据需求,并使管理各种数据来源变得更容易。

这些差异帮助组织选择最适合其数据管理需求和目标的方法。

混合模型

混合模型结合了KimballInmon 方法的部分内容。它首先从各种联机事务处理 (OLTP) 系统收集原始数据到临时保存表中,而无需对其进行清理。

然后,数据将移动到企业信息工厂 (CIF),在那里以详细格式存储。之后,数据将传输到独立的维度数据市场,这些数据市场可以根据每个部门的需求同时保存详细数据和汇总数据。

一些数据也可以放入立方体中进行报告。建议使用立方体,因为它们:

  • 充当清晰的界面。
  • 同时支持多个用户。
  • 提供汇总数据以提高速度。
  • 消除复杂的连接。
  • 包含层次结构和关键绩效指标 (KPI)。
  • 通过行级安全性确保数据隐私。
  • 允许进行高级时间计算以进行趋势分析。

提取、转换、加载 (ETL) 流程中使用数据库视图可以简化编码并改进查询。视图是基于 SQL 查询的虚拟表,有助于管理复杂性而无需存储额外数据。

镜像 OLTP 系统

混合模型涉及一个镜像联机事务处理 (OLTP) 系统,这是一个与原始系统一起运行的副本。此安排允许主 OLTP 专注于用户访问和维护,同时收集数据。它还可以简化提取、转换、加载 (ETL) 流程,并可以通过允许特定索引而不会影响原始系统来提高性能。

选择正确的数据模型

选择数据模型时,没有一刀切的方法。您的决策应考虑安全、数据大小和性能等因素。例如,添加星型模式可以提高查询性能。

关于Inmon和Kimball方法的常见误解

以下是关于InmonKimball 数据方法的一些常见误解

  • Kimball 纯粹是自底向上的:事实上,Kimball 将自顶向下的规划与自底向上的执行相结合,重点关注设计和实施。
  • Inmon 需要大量的预先设计:Inmon 支持逐步构建数据仓库的方法,而不是试图一次完成所有工作。
  • Inmon 不支持星型模式:实际上,Inmon 认识到星型模式数据市场对于用户更容易访问的好处。
  • 很少有公司使用 Inmon 的方法:调查显示,许多组织实际上更喜欢 Inmon 方法。
  • 这些方法是不兼容的:Kimball 和 Inmon 可以很好地协同工作,尤其是在混合模型中。

Kimball 方法包括项目规划和维护,而Inmon 则专注于数据仓库本身。当人们谈论 Kimball 时,他们通常指的是维度建模,其中包括一致维度和快照事实表等技术。

广告