【DBMS 数据库管理系统】多维数据模型 ( 星型模式 | 雪片模型 | 事实群模型 | 度量 | 分布型 | 代数型 | 整体型 )

简介: 【DBMS 数据库管理系统】多维数据模型 ( 星型模式 | 雪片模型 | 事实群模型 | 度量 | 分布型 | 代数型 | 整体型 )

文章目录

一、星型模式

二、星型模式 缺点

三、雪片模型

四、星型模型 雪片模型 折衷方案

五、事实群模型 ( 仅做了解 )

六、度量





一、星型模式


星型模式 是 多维数据模型 的表现形式 ;



星型模式 展示 : 中间有一个表 , 称为 事实表 , 周围有很多小表 , 这些表称为 维表 ;



以 “商品” 表为例 :


事实表 : 描述商品的 时间 , 位置 , 供应商 , 零售价 , 商品颜色 等信息 ;

维表 : 时间 对应的维表 包含 年 , 月 , 日 , 时 , 分 , 秒 等字段 ; 位置 维表有 国家 , 省份 , 地区 , 城市 , 街道 等字段信息 , 供应商 维表 有 公司名称 , 法人 , 税号 , 公司注册地点 等字段信息 ;

事实表中的 度量 : 上述 零售价 , 商品颜色 没有与维表关联 , 是度量 ;





二、星型模式 缺点


星型模式 缺点 :




1 . 星型模式 不支持 维 的层结构 ;


单一维表 : 每个 维 只有一个维表 , 所有的 维层属性 都放在一个表中 , 没有进行规范化 ;

单一维表 示例 : 以上述 “商品” 事实表的 时间 对应的维表 为例 , 将 年 , 月 , 日 , 时 , 分 , 秒 等字段放在同一个 维表 中 , 时间维 可以变成 多个维表 , 如只包含 年月日的维表 , 只包含 年 月 的维表 等 ;


2 . 数据冗余 :


数据冗余 : 每个 维表 都要表示所有的层 , 每个层有自己的属性 , 有很多数据冗余 ;

数据冗余 示例 : 上述 时间维表 中每个商品 , 都要存储完整的 年 , 月 , 日 , 时 , 分 , 秒 数据 , 实际上商品的 年 , 月 , 等数据 , 很多商品都是相同的 , 只记录一次即可 , 不同所有的商品都记录年月 信息 , 因此产生了大量的冗余数据 ;


3 . 不同维层属性名相同查询问题 :


不同维层 , 有相同的属性 , 只能使用 换名 方式进行查询 ;

不同维层 相同属性示例 : 如 商店 事实表中 , 城市 , 省份 , 国家 , 每个层级都有一个经理 Manager , 当 查询 Manager 属性时 , 直接将 城市经理 , 省份经理 , 国家经理 , 都查询出来了 , 无法查询单独一个级别的经理信息 ;





三、雪片模型


对于 维层次 复杂的维


为了 避免 冗余数据占用过多空间

为了 支持 不同维层 相同属性 查询

使用多个维表 描述复杂的维 , 这样在 星型模型 的 星的角上 , 出现了分支 , 类似于雪花形状 , 因此这种变种的 星型模型 称为 “雪片模型” ;



雪片模型示例 : 以 “商品” 表为例


事实表 : 描述商品的 时间 , 位置 , 供应商 , 零售价 , 商品颜色 等信息 ;

第一层维表 : 时间 对应的维表 包含 日 , 时 , 分 , 秒 等字段 ; 位置 维表有 城市 , 街道 等字段信息 , 供应商 维表 有 公司名称 , 法人 , 税号 , 公司注册地点 等字段信息 ;

第二层维表 : 时间表的第一层维表的 日 , 又使用 第二层维表表示 , 该维表中有 年 , 月 , 日 , 三个维度的信息 ; 地区表 的第一层维表的 城市 , 使用第二层维表 表示 , 该第二层维表有 国家 , 省份 , 城市 , 三个维度的信息表示 ;

事实表中的 度量 : 上述 零售价 , 商品颜色 没有与维表关联 , 是度量 ;

雪片模型 优缺点 :


雪片模型优点 : 雪片模型的维表是规范化的维表 , 雪片模型维表 易于维护 , 节省存储空间 ;

雪片模型缺点 : 雪片模型 查询时 , 需要 进行较多的连接操作 , 影响系统性能 ;


雪片模型 更好的 体现了 维层结构 ,


对于专业的数据库 建模 设计人员 , 更容易理解 , 分析 ;

- 对于 普通用户 来说 , 比较复杂 ;





四、星型模型 雪片模型 折衷方案


推荐采用一种 星型模型 和 雪片模型 折衷方案 , 将 星型模式 与 雪片模式 结合使用 ;


大维表节省空间 : 针对 大维表 , 规范化 , 节省存储空间 ;


小维表效率优先 : 对于 小维表 , 采用不规范化的形式 , 避免因为查询时 , 过多的表连接 , 引起性能降低 ;






五、事实群模型 ( 仅做了解 )


该模型 比 星型模式 , 雪片模型 更复杂 , 上述两个模型 , 只有一个事实表 , 但是 在事实群模型中 , 有多个事实表 , 两个事实表 , 可能公用一些维表 ;






六、度量


数据方体 中的度量 , 可以分为三种不同的类型 :


分布型

代数型

整体型


分布型 度量 :


特点 : 可以累加 ;

示例 : 求和 , 计数 , 求最小值 , 求最大值 ;


代数型 度量 :


特点 : 无法累计 ; 但是可以转换成 分布式 度量 ;

示例 : 求平均值 , 无法累加 , 但是可以转成 先求和 , 然后再计算平均值 的 分布性 度量 ;


整体型 度量 :


特点 : 必须有所有的值才能计算 , 无法累加 ;

示例 : 求中间值 , 求前 K KK 个最大值 , 排名 , 必须统计完整数据 , 才能计算出来 ;


目录
相关文章
|
30天前
|
SQL 存储 关系型数据库
数据储存数据库管理系统(DBMS)
【10月更文挑战第11天】
85 3
|
2月前
|
前端开发 IDE 数据库连接
ThinkPHP6 模型层的模型属性,表映射关系,以及如何在控制层中使用模型层和模型层中的简单CRUD
本文详细介绍了ThinkPHP6中模型层的使用,包括模型属性设置、表映射关系、以及如何在控制层中使用模型层进行CRUD操作。
ThinkPHP6 模型层的模型属性,表映射关系,以及如何在控制层中使用模型层和模型层中的简单CRUD
|
3月前
|
资源调度 关系型数据库 MySQL
【Flink on YARN + CDC 3.0】神操作!看完这篇教程,你也能成为数据流处理高手!从零开始,一步步教会你在Flink on YARN模式下如何配置Debezium CDC 3.0,让你的数据库变更数据瞬间飞起来!
【8月更文挑战第15天】随着Apache Flink的普及,企业广泛采用Flink on YARN部署流处理应用,高效利用集群资源。变更数据捕获(CDC)工具在现代数据栈中至关重要,能实时捕捉数据库变化并转发给下游系统处理。本文以Flink on YARN为例,介绍如何在Debezium CDC 3.0中配置MySQL连接器,实现数据流处理。首先确保YARN上已部署Flink集群,接着安装Debezium MySQL连接器并配置Kafka Connect。最后,创建Flink任务消费变更事件并提交任务到Flink集群。通过这些步骤,可以构建出从数据库变更到实时处理的无缝数据管道。
291 2
|
3月前
|
存储 SQL 算法
【OceanBase】惊天大反转!启动时真的会占用95%磁盘空间?别怕!揭秘真相+实用调整技巧,手把手教你如何优雅地管理磁盘空间,让你的数据库从此告别“吃土”模式!
【8月更文挑战第15天】OceanBase是一款高性能分布式数据库,启动时并不会默认占用95%磁盘空间,这是一种误解。其设计注重资源管理,可根据业务需求动态调整空间使用。通过设置`max_disk_usage`等参数、优化表设计、定期清理数据及启用压缩等功能,可有效控制磁盘占用,确保高效利用存储资源。
79 1
|
2月前
|
前端开发 数据库 开发者
数据模型(数据库表设计)生成代码
BizWorks ToolKit 插件集成 Mybatis-Plus 代码生成工具,支持从数据库表批量生成代码,简化开发流程。本文详细介绍配置方法及项目示例,包括配置文件格式、生成选项及具体操作步骤,帮助开发者快速实现代码同步更新。配置文件 `.mp.yaml` 支持自定义输出目录、生成组件等,适用于多种项目结构。
47 0
|
3月前
|
SQL 数据库 Java
Hibernate 日志记录竟藏着这些秘密?快来一探究竟,解锁调试与监控最佳实践
【8月更文挑战第31天】在软件开发中,日志记录对调试和监控至关重要。使用持久化框架 Hibernate 时,合理配置日志可帮助理解其内部机制并优化性能。首先,需选择合适的日志框架,如 Log4j 或 Logback,并配置日志级别;理解 Hibernate 的多级日志,如 DEBUG 和 ERROR,以适应不同开发阶段需求;利用 Hibernate 统计功能监测数据库交互情况;记录自定义日志以跟踪业务逻辑;定期审查和清理日志避免占用过多磁盘空间。综上,有效日志记录能显著提升 Hibernate 应用的性能和稳定性。
50 0
|
3月前
|
存储 SQL NoSQL
详解数据库管理系统(DBMS)
【8月更文挑战第31天】
393 0
|
3月前
|
SQL 存储 NoSQL
从SQL到NoSQL:理解不同数据库类型的选择与应用——深入比较数据模型、扩展性、查询语言、一致性和适用场景,为数据存储提供全面决策指南
【8月更文挑战第31天】在信息技术飞速发展的今天,数据库的选择至关重要。传统的SQL数据库因其稳定的事务性和强大的查询能力被广泛应用,而NoSQL数据库则凭借其灵活性和水平扩展性受到关注。本文对比了两种数据库类型的特点,帮助开发者根据应用场景做出合理选择。SQL数据库遵循关系模型,适合处理结构化数据和复杂查询;NoSQL数据库支持多种数据模型,适用于非结构化或半结构化数据。SQL数据库在一致性方面表现优异,但扩展性较差;NoSQL数据库则设计之初便考虑了水平扩展性。SQL使用成熟的SQL语言,NoSQL的查询语言更为灵活。
76 0
|
3月前
|
API 数据库 开发者
【独家揭秘】Django ORM高手秘籍:如何玩转数据模型与数据库交互的艺术?
【8月更文挑战第31天】本文通过具体示例详细介绍了Django ORM的使用方法,包括数据模型设计与数据库操作的最佳实践。从创建应用和定义模型开始,逐步演示了查询、创建、更新和删除数据的全过程,并展示了关联查询与过滤的技巧,帮助开发者更高效地利用Django ORM构建和维护Web应用。通过这些基础概念和实践技巧,读者可以更好地掌握Django ORM,提升开发效率。
39 0
|
3月前
|
SQL API 数据库
揭秘Ruby数据库交互的黑科技!ActiveRecord模式:为何它让数据库操作如此“随心所欲”?
【8月更文挑战第31天】在Ruby编程中,与数据库交互至关重要。ActiveRecord作为Ruby on Rails框架的核心组件,凭借其简洁高效的特点,成为处理数据库操作的首选。本文深入探讨ActiveRecord模式,介绍其如何简化数据库交互,并通过示例代码展示具体应用。ActiveRecord是一种ORM框架,将数据库表映射为Ruby类,使开发者能通过操作对象间接管理数据库记录。其核心特性包括模型定义、关联管理、数据验证、事务处理及强大的查询接口。通过示例代码,展示了如何定义模型、创建记录、查询记录及处理关联,突显了ActiveRecord在简化数据库操作方面的优势。
65 0