查看原文
其他

如何进行数据仓库的数据模型的设计?

ruby ruby的数据漫谈
2024-09-27
摘要:数据仓库的数据模型设计是建立在数据仓库概念之上的,其目的是为了支持数据的分析和决策制定。数据仓库的数据模型通常与传统的关系数据库模型有所不同,因为数据仓库需要适应大量数据的存储和查询需求。而在大数据平台中进行数据开发,数据模型设计是非常常见的事项,也是数据架构师必须掌握的技能,本文从数据模型的设计重要性和原则、方法、步骤,已经不同模型的应用场景角度出发,介绍如何进行数据仓库的数据模型设计。‍


  • 数据模型的设计重要性和原则
  • 数据模型的设计的方法和步骤‍‍‍‍‍‍‍
  • 不同数据模型类型的应用场景‍‍‍‍‍‍‍



01

数据模型设计的重要性和原则‍‍‍‍‍


数据仓库的数据模型设计的重要性‍‍‍‍‍‍‍‍‍

数据模型是数据仓库建设中的关键组成部分,它定义了数据仓库中数据的结构、关系和属性。数据模型的设计对数据仓库的功能和性能有深远影响,能够有效支持数据分析、报告和决策。

首先,数据模型通过数据建模技术将业务需求转化为概念模型、物理模型或逻辑模型,来定义数据仓库的数据结构。这样,数据仓库中的数据可以以有组织、易于理解和管理的方式存在,提高了数据的可用性和可维护性。

其次,数据模型帮助确保数据仓库数据的一致性和准确性。通过应用规范和约束,数据模型可以定义属性的数据类型、唯一性约束、关系约束等,从而避免数据冗余和不一致性,提高了数据的可靠性。

此外,数据模型还支持数据仓库的查询和分析功能。通过合理的数据模型设计,可以提高数据仓库的查询性能和分析效率。通过定义物理索引、分区策略、聚集表等,数据模型可以优化数据仓库的查询和分析过程,提升用户体验和工作效率。

最后,数据模型提供了数据仓库的扩展和演化能力。良好的数据模型设计可以降低维护成本,并为数据仓库的未来演进提供支持。随着业务需求变化和数据规模增长,数据模型可以灵活地调整和扩展,适应新的数据源和数据结构。

总而言之,数据模型在数据仓库建设中的作用至关重要。它定义了数据仓库的结构,确保数据的一致性和准确性,支持查询和分析,同时也提供了扩展和演化的能力。合理应用数据模型可以建设高效、可靠且可维护的数据仓库,为企业决策提供有力的支持。


数据仓库的数据模型设计的基本原则

  1. 面向主题、基于事实和维度:设计时应将数据组织成逻辑上相关的数据块(称为"主题"),并基于事实和维度进行组织,以便于业务用户能够轻松地访问和分析。
  2. 数据分层、标准化和统一:通过数据分层、标准化和统一,可以确保数据的一致性和完整性,同时提高数据的可访问性和灵活性。
  3. 维度建模、可扩展性、可理解性和性能优化:维度建模是数据仓库领域的一种常见方法,它以分析决策的需求出发构建模型,重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能。
  4. 使用星型架构或雪花型架构:根据业务需求选择合适的架构类型,星型模型以一个事实表为中心,周围围绕着多个维度表;而雪花型模型则是在星型模型的基础上对维度进行进一步的拆分。
  5. 遵循3NF原则:在设计数据仓库时,通常会用到3NF(第三范式)来确保数据的一致性和完整性。
3NF(第三范式)是数据库设计中的一种范式,用于规范化数据模型,确保数据的一致性和完整性。它是关系型数据库中的最常用的范式之一。
3NF要求一个关系模式中的每个非主属性(即非关键属性)不能传递依赖于其他非主属性。换句话说,3NF要求一个关系模式中的每个非主属性只能依赖于关键属性,而不能依赖于其他非主属性。
举个简单的例子来解释3NF。假设我们有一个关系模式(表)叫做“顾客订单”,其中包含以下属性:顾客ID、顾客姓名、订单号、订单日期、订单金额。按照3NF规则,该关系模式需要进行规范化,分成两个关系模式:一个是“顾客”,包含属性顾客ID和顾客姓名;另一个是“订单”,包含属性订单号、订单日期、订单金额和顾客ID。这样就将非主属性(订单日期、订单金额)从顾客关系模式中移出来,使得数据更加一致和完整。
3NF的使用有助于减少数据冗余、提高数据的一致性和准确性,使得数据在多个表之间更好地关联和连接。在数据仓库中使用3NF有助于建立更灵活和可扩展的数据模型,支持复杂的查询和分析操作。
分层设计的原则:‍‍
  1. 开放性:分层设计应符合开放性的原则,使得系统易于扩展和集成

  2. 简洁性:分层设计应简洁明了,使得系统易于维护和管理。

  3. 分离性:分层设计应将不同的功能模块分离,降低系统各模块之间的耦合度。

  4. 复用性:考虑模块的复用性,提高系统开发效率。

  5. 单一责任原则:每个层次应该只承担一个责任,避免一个层次承担多个责任。

  6. 高内聚低耦合原则:确保数据仓库分层设计的正确性和可靠性。

其中,高内聚(high cohesion)意味着在一个模块内部的组件和操作之间具有紧密的关联和相似的功能。换句话说,高内聚要求模块内部的组件相互联系紧密、目标一致,从而实现高效的合作。在数据仓库模型设计中,高内聚意味着在一个数据模型或组件内部的数据元素和操作之间具有紧密的关联和一致的目标。
低耦合(low coupling)意味着模块之间的依赖关系和相互影响尽可能的小。低耦合的设计使得每个模块都能够独立地进行修改和演化,不会对其他模块造成过多的影响。在数据仓库模型设计中,低耦合意味着不同的数据模型或组件之间的依赖关系要尽可能的减少,每个模块都应该独立、可扩展和可维护。

综上所述,数据仓库的数据模型设计对于确保数据的准确性、一致性和完整性,以及提高查询性能和数据分析的效率具有重要意义。通过遵循上述设计原则,可以构建出高效、可靠的数据管理系统,为企业提供有力的支持。




02

数据模型的设计的方法和步骤


数据仓库的数据模型设计的方法和步骤‍‍


数据仓库的数据模型设计方法和步骤可以参考以下几个方面:
1、确定业务需求:深入了解业务需求和数据分析目标,明确本次设计的数据模型所属的主题域。不同的主题域意味着后期模型设计存储以及表的名称和规范等不同。
2、收集数据源:收集与业务需求相关的源数据,包括来自各种数据系统和数据库的结构化和非结构化数据字典等信息。
3、理解数据:对收集到的数据进行深入分析,了解数据的结构、属性、关系和业务含义。
4、设计维度模型:基于业务需求和数据分析目标,设计维度模型。维度模型通常使用星型模型或雪花模型。在设计维度模型时,需要确定事实表和维度表,并设计它们之间的关系。
5、确定事实表和度量指标:确定需要存储的事实数据,包括哪些度量指标需要被计算和汇总。
6、设计维度表:设计维度表,包括维度表的属性和层次结构。维度表描述了业务过程的维度信息,如时间、地理位置、产品、客户等。
7、设计事实表:设计事实表,包括事实表的主键和外键,以及与度量指标相关的列。
8、设计聚合表:根据业务需求,设计合适的聚合表用于提高查询性能和优化数据仓库的存储空间。
9、确定ETL过程:设计ETL(抽取、转换和加载)过程,将源数据转换为目标数据模型所需的格式,包括数据清洗、整合和转换。
10、数据模型验证和优化:对设计好的数据模型进行评估和验证,确保模型符合需求,并与相关的报表和分析流程相匹配。同时,可以对数据模型进行性能优化,如索引优化、查询优化等。
以上是数据仓库的数据模型设计方法和步骤的一般参考,具体的方法和步骤可能因项目需求和技术限制而有所不同。在实际设计过程中,还需要根据具体情况进行合理的调整和优化。


数据仓库的数据模型设计的星型模型设计实例

在本案例中,数据模型将围绕销售、顾客和商品等维度以及订单事实表展开,其中包括以下维度:

顾客维度

顾客维度包括顾客的基本信息以及与顾客相关的其他业务数据。为便于使用和管理,我们将顾客维度分为以下几个部分:
- 个人信息:客户姓名、性别、年龄、地址、电话、邮箱等基本信息。
- 会员等级:客户的会员等级,包括普通会员、银卡会员、金卡会员、白金会员等。
- 购买偏好:客户的购买偏好,包括喜欢的品牌、类别、颜色、价格等。

商品维度

商品维度包括商品的基本信息以及与商品相关的其他业务数据。为便于使用和管理,我们将商品维度分为以下几个部分:

- 商品基本属性:包括商品名称、品牌、产地、规格、材质、包装、上市时间等。

- 商品类别:商品所属的类别,包括化妆品、美妆工具、个人护理用品等分类。

- 销售属性:商品的销售属性,包括销售的数量、销售的金额、售价等。

时间维度

时间维度主要用于支持时间序列数据的查询和分析。在本案例中,时间维度将按天、月、年等粒度进行划分,包括以下时间属性:

- 年:包括年份。

- 季节:按季节划分,包括春季、夏季、秋季、冬季。

- 月:根据月份进行划分。

- 日:根据日期进行划分。

地域维度

地域维度用于支持不同地区、城市或省份的业务数据查询和分析。在本案例中,地域维度将包括以下几个属性:

- 地区:按地区进行划分,包括华东、华南、华北、西北等。

- 省份:根据省份进行划分。

- 城市:根据城市进行划分。


如果是星型模型,则订单事实表和维度表的关系如下图所示:


其中,顾客维度表中包含个人信息、会员等级、购买偏好等三个维度的信息,其它维度也一样,包含各子维度的信息,通过主键和事实表的外键进行关联,进行分析。


而如果是雪花模型,如下所示:


雪花模型则是维度表会细化成更加详细的维度。



03

不同数据模型类型的应用场景‍‍‍



数据仓库不同模型类型的应用场景‍‍‍‍‍‍‍‍‍


星型模型、雪花模型和宽表模型都是常见的数据仓库模型设计方法,它们在不同的场景下有不同的适用性和设计特点。
1、星型模型:
    • 特点:星型模型以一个中心的事实表(Fact Table)为核心,周围是多个维度表(Dimension Table)。事实表包含了业务过程中需要跟踪的事实数据,而维度表包含了描述事实的属性信息。
    • 应用场景:适用于简单的分析和报表需求,事实表与维度表之间的关联简单明确,易于理解和查询。
    • 优点:简单、直观,易于建模和维护,查询性能较高。
    • 缺点:不适合复杂的多层次分析和查询需求,数据冗余较大。
    2、雪花模型:
    • 特点:雪花模型在星型模型的基础上,将维度表进一步细化为多个层级的关联表,形成层级嵌套的结构。
    • 应用场景:适用于具有复杂分析需求的场景,可以支持多级别的数据分析和查询。
    • 优点:适合复杂的多层次数据分析和查询,可以更加灵活地对数据进行切片和钻取。
    • 缺点:模型设计复杂,需要更多的存储空间,查询性能相对较低。
    3、宽表模型:
    • 特点:宽表模型是将所有需要分析的属性都包含在一个大表中,而不使用维度表。每个属性都作为一个列存放在表中,事实数据与属性一起存储。
    • 应用场景:适用于具有复杂的属性分析需求的场景,能够快速满足多维分析的需求。
    • 优点:模型简化,查询速度快,适合灵活的多维分析需求。
    • 缺点:数据冗余较大,存储空间开销较大。



      ‍‍

    选择模型的依据包括但不限于需求复杂度、数据量、查询性能要求、维护成本等因素。在实际应用中,可以根据具体场景的需求,综合考虑模型的设计特点和约束条件选择合适的模型。而模型最终是在数据库或者存储中实现,而他们采用的数据存储也不同。‍‍


    星型模型和雪花模型通常采用关系型数据库(如MySQL、Oracle、SQL Server)和OLAP数据库(Doris、WinQSPL)进行存储。OLAP数据库更为常见,关系型数据库在数据量大可能性能达不到。OLAP数据库是针对分析型工作负载进行优化的数据库,它能够提供快速的多维数据查询和聚合计算能力。OLAP数据库通常支持数据立方体(Cube)和多维模型,并且具备高性能的数据压缩和查询优化技术,适合处理星型模型和雪花模型中复杂的查询和分析需求。


    宽表模型可以采用多种存储类型,根据实际情况而定。常见的存储类型包括:

    1、列存储数据库:列存储数据库将数据按列进行存储和压缩,能够提供高性能的多维分析和查询能力。常见的列存储数据库包括Greenplum、Vertica和ClickHouse等。

    2、分布式存储系统:分布式存储系统(如Hadoop、Spark)可以分布式地存储和处理大规模数据。可以使用Hadoop的HDFS存储数据,结合Spark进行数据处理和分析。

    3、NoSQL数据库:一些NoSQL数据库(如MongoDB、Cassandra)也可以用于宽表模型的存储。这些数据库具备高度可扩展性和灵活性,能够满足大数据存储和查询的需求。


    选择存储类型时,需要根据实际需求和系统架构,综合考虑数据规模、查询性能、数据处理能力和成本等因素进行选择。



    欢迎加入【数据行业交流群】社群,长按以下二维码加入专业微信群,商务合作加微信备注商务合作,AIGC应用开发交流入群备注AIGC应用




    往期数据平台历史热门文章:

    基于DataOps的数据开发治理:实现数据流程的自动化和规范化

    数据平台:湖仓一体、流批一体、存算分离的核心问题及原因解析

    数据治理体系该怎么建设?

    实时数仓&流批一体技术发展趋势

    数据仓库、数据中台、大数据平台的关系?

    数字化转型如何促进业务的发展

    数据中台中的核心概念解析

    数据治理中的数据标准的作用?

    全面数字化转型:打造全新营销模式

    一图展示数据中台的数据流图

    揭秘数据治理系统的数据流程图

    往期AIGC历史热门文章:

    AIGC系列之一-一文理解什么是Embedding嵌入技术

    十大AIGC文生视频产品介绍

    九大最热门的开源AI Agent框架

    AutoGen零代码构建⾃⼰的智能助理


    继续滑动看下一个
    ruby的数据漫谈
    向上滑动看下一个

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存