数据粒度的设计

计算机领域中粒度指系统内存扩展增量的最小值.

粒度问题是设计数据仓库的一个最重要方面。粒度是指数据仓库的数据单位中保存数据的细化或综合程度的级别。细化程度越高,粒度级就越小;相反,细化程度越低,粒度级就越大。数据的粒度一直是一个设计问题。

在早期建立的操作型系统中,粒度是用于访问授权的。当详细的数据被更新时,几乎总是把它存放在最低粒度级上。但在数据仓库环境中,对粒度不作假设。

在数据仓库环境中粒度之所以是主要的设计问题,是因为它深深地影响存放在数据仓库中的数据量的大小,同时影响数据仓库所能回答的查询类型。在数据仓库中的数据量大小与查询的详细程度之间要作出权衡。

================================================================================================================

从时间的角度讲:简单说粒度就是事实表里测量值的测量‘频率’。比如说,销售库里的销售额,可以是一 天一个值,也可以是一个月一个值,甚至一年一个值,这就是相对于时间维度表的力度;可以是一个商品一个值,也可以是一类商品一个值,这就是相对于商品的粒度。

粒度就是同一维度下,数据的粗细程度;
考虑到时间维度在数据仓库中相对比较特殊,另外举个例子。

以“组织结构”为例,比如我们的一个层级结构式:总公司,分公司,部门,科室。
这就是不同的粒度级别。

实际应用中,比如有人问,你的某个报表粒度是怎样的。
我们可以说,组织结构我们的报表呈现是到分公司级别的,但是我们的数据粒度是到科室的(也就是你的事实表中,层级聚合到科室级别)。

所以我们就也能支持到之上的“粗”粒度,如总公司,分公司,及部门

如果我们的数据粒度是到分公司的,那明显我们的报表就不能支持下级粒度的数据展现。
也就是说,粒度不够“细”。

当然,粒度的也不是越细越好,要综合分析。
比如如果我们这一层级的需求,都是针对于分公司级别的,不需要往其下级部门的深化。那么粒度就到分公司即可。
毕竟粒度越细,事实表的数据量也会越大。

总结一下:

可以将数据看成是有粘性的沙粒,粒度小的沙粒比较细,粒度大的沙粒是由粒度小的沙粒粘起来的,即粒度高的数据是由粒度低的数据综合起来的.在数据仓库环境
中,粒度是一个重要的设计问题,他影响到数据仓库的数据量和系统能回答的查询类型,粒度越小,细节程度越高,能回答查询就越多,但是存储的东西也就越多.

时间: 2024-10-05 14:37:15

数据粒度的设计的相关文章

数据仓库中数据粒度

粒度问题是设计数据仓库的一个最重要方面.粒度是指数据仓库的数据单位中保存数据的细化或综合程度的级别.细化程度越高,粒度级就越小:相反,细化程度越低,粒度级就越大.确定粒度是数据仓库开发者需要面对的一个重要的设计问题.如果数据仓库的粒度确定合理,设计和实现中的其余方面就可以非常顺畅地进行:反之,如果粒度确定的不合理就会是其他所有方面都很难进行.粒度对于数据仓库体系结构设计人员来说,非常重要,因为粒度会影响到那些依赖于从中获取数据的数据仓库的所有环境. 粒度的主要问题是使其处于一个合适的级别,粒度的

大数据平台架构设计探究

本文首发于 vivo互联网技术 微信公众号? 链接:https://mp.weixin.qq.com/s/npRRRDqNUHNjbybliFxOxA 作者:刘延江 近年来,随着IT技术与大数据.机器学习.算法方向的不断发展,越来越多的企业都意识到了数据存在的价值,将数据作为自身宝贵的资产进行管理,利用大数据和机器学习能力去挖掘.识别.利用数据资产.如果缺乏有效的数据整体架构设计或者部分能力缺失,会导致业务层难以直接利用大数据大数据,大数据和业务产生了巨大的鸿沟,这道鸿沟的出现导致企业在使用大数

***社交网站的用户关系数据是怎么设计的,比如关注数,黑名单数,粉丝数等等

Q: 我见过一种设计,在数据库里面有一张用户关系表,表结构如下 CREATE TABLE relation (relation_id private key AUTO_INCREMENT,//关系idrelation_fans text,//粉丝数据relation_black text,//黑名单数据relation_action text//关注数据);这样的设计有什么用意,如果要取得用户的关系数据 怎么取得? A: text类型?是存些什么东西呢?很好奇.另外 private key 是笔

从节能角度看数据中心软硬件设计(一)

从节能角度看数据中心软硬件设计(一) -PMC公司资深顾问.前Facebook存储架构设计师. OCP创始人之一Per Brasher于CCCC演讲实录- 此次演讲流程如下.首先讨论关注数据中心效率的原因及其提升效率的原始动力所在.第二步讨论影响效率的主要构成部件,这些部件对效率的贡献大概有多少,以及怎样对每个部件的效率进行优化和提高.第三个方面是展望如何进一步降低TCO成本,其中将涉及更先进的数据保护机制.接着会对存储的各种新模式进行一定展望,最后做一个总结. 下表总结了OCP的设计理念,其中

多终端数据同步机制设计(二)

多终端数据同步机制设计(二) Intro 如果您没有看上一篇文章,建议您先移步到这里查看第一部分 上一次主要解决了基本的数据增量同步的问题,但仍然存在一些问题. 可能存在的主要问题: 大数据量传输时,数据在传输过程出现部分丢失,数据不完整 超大数据量需要同步,导致响应时间过长而导致连接超时 针对以上可能出现的这两个问题,需要对数据进行校验并且数据量超过一定量时进行分批量传输, 本文将着手解决 数据校验 和 数据分批次传输 这两个问题. 同步流程概览 结合之前的同步流程,加上数据校验和分批次传输数

数据类的设计

**info.h #pragma once _MB_DATABASE_BEGIN class MB_DATABASE_EXT CBeamSection:public CSection { public: CBeamSection(); CBeamSection(const CBeamSection* pBeamSection); virtual ~CBeamSection(void); virtual CSection* Clone() const { return new CBeamSecti

多终端数据同步机制设计

多终端数据同步机制设计(一) Intro 因为项目需要,需要设计一个多终端数据同步的机制, 需要满足以下条件: 1. 多个终端数据操作及同步 2. 每次同步的时候只拉取需要同步的数据,且数据不能存在丢失 3. 尽可能少的调用服务器端接口 同步流程 整体同步流程 我想仿照Git数据同步的方式来进行数据同步,于是放着Git同步的流程来进行设计,首先每次提交会有一个版本号,另外每次提交之前应尽可能先从服务器端拉取数据, 保证客户端的数据是最新的情况下再进行提交本地的修改.按照Git的方式来进行数据同步

大众点评数据交换工具Wormhole设计与实现

1.1.1 数据交换工具Wormhole设计与实现 1.1.1.1 Wormhole整体设计 Wormhole是框架加插件的设计,各模块的设计思路: 1)  框架分为读管理器.双端缓冲队列和写管理器.读写管理器分别持有读写线程池,双端缓冲队列负责读写线程的数据交换. 2)  每种数据存储的插件分为或读写两种类型,每种类型又具体分为读或写.预和后处理.分片三种类型的插件.用不同接口来标识每种插件.扩展一种数据存储类型的方式是实现这些插件. 3)  插件的类型信息存在任务的配置文件中,以便解耦合,任

一种面向电信行业基站数据的数据采集系统的设计与实现

一种面向电信行业基站数据的数据采集系统的设计与实现 1,项目简介 本论文来源于上海电信应急指挥平台.上海电信应急指挥平台主要是采集上海所有基站的一些与应急相关的实时数据,将这些数据做统计分析工作之后,在web浏览器上展示出来,便于电信上级的部门做决策.由于本人主要负责数据采集模块的架构.设计和开发工作.对这个领域有点体会,本篇文章主要总结这个领域的一些实践工作. 由于在数据采集的领域主要以使用WebService的方式(Apache CXF)和使用ftp两种方式来采集电信的基站数据,本篇文章就以