维度建模实践一例 (一) 维度还是事实

本文涉及的产品
大数据开发治理平台DataWorks,资源组抵扣包 750CU*H
简介: 成本和单价是产品的维度还是事实表中的事实?来看看我对这个问题的思考与分享吧。

1. 问题概述

最近在做工业项目模型设计评审的时候,遇到了一个设计问题,有点纠结和其他同事交换了意见,思考了过后,也想跟大家分享一下。

问题:“成本”和“单价”是一个销售实体的事实,还是产品维度的属性?

关于这个问题,最开始是在讨论成本计算的时候发现的。与教科书中零售场景不一样的是,工业上某个产品的成本是要计算出来的。而《维度建模权威指南》书中的成本是事实表的一个事实。如下图所示:

image.png

在另外一个例子中,单价、成本都是销售实体中的事实,如下图所示:

image.png

事实部分翻译如下:

Sales Quantity -- 销售数量

Regular Unit Price  -- 常规单价

Discount Unit Price -- 折扣单价

Net Unit Price -- 净单价

Extended Discount Dollar Amount  -- (扩展-总)折扣金额

Extended Sales Dollar Amount -- (扩展-总)销售金额

Extended Cost Dollar Amount -- (扩展-总)成本金额

Extended Gross Dollar Amount -- (扩展-总)毛利润金额

如上图所示,一般我们零售场景中商品的单价是相对固定的,零售商会有一些折扣(线上商家的折扣应该会更复杂),所以,单价、成本是固定的利润是与订单相关的。我们可以从上述事实表中获得一些事实:

① 销售数量、销售金额、成本金额、毛利润金额都是可加事实

② 单价是一个不可加事实

在零售的销售分析场景,单价与成本是作为销售实体的事实。而在我现在遇到的场景,我们遇到的第一个场景是分析产品的成本与价格。

2. 成本与单价的本质

抛开分析场景,我思考了成本和单价的本质,在销售这个事实中单价和成本本质上是产品的属性零售的场景中,销售的单价是商品的单价,销售的成本是是商品的成本。所以,单价和成本就是商品的属性。

但是为什么我在《维度建模权威指南》的书中看到的产品维度都没有这两个属性呢?我还特地去搜了一下内网的dataworks数据地图上的产品、商品的维度表,发现确实有很多维度表都没有单价和成本两个属性,但是也有一些商品维度表是有这两个属性的。

为什么自己会觉得这两个表中的事实并不是销售这个事实表中的事实呢?思考过后我终于意识到,我忽略了分析的需求。缺乏业务认知的我意识不到商品的成本和单价的变动,我错误的忽略了这两个事实的分析需求。但是作为商品生产和经销商,价格和成本的变动是时时刻刻的。所以,就有分析单价和成本这两个事实的需求。

这就是为什么大部分场景,商品维度表中都没有单价和成本。因为这两个事实要么在“销售事实表”中,要么在其他“商品分析事实表”中。而这些事实表中的商品的维度就不会有单价和成本了。

2. 事实表的设计

通过上面的思考,我意识到了一个问题:商品的单价、成本本身就是一个事实只是成本是通过一系列的复杂计算获得的一个事实,其本身是根据原材料的成本、制造成本、运输成本等多种因素计算而来。而且价格本身又与成本有一定的强关联性。

我们通过在销售这个业务过程中去分析单价和成本这两个事实,说明销售这个业务过程中分析人员会关注客单的商品和成本。而且,在销售这个业务过程对单价和成本的分析主要是关乎销售这个过程,这个业务过程可能是一个企业业务分析中最核心和关键的事实。

我们其实可以根据对产品本身的分析需求构建一个商品定价业务过程的事实表,这个业务过程比商品销售更简单。而且对于我参与的这个项目来的客户来说,这是一家第一产业工业企业,其生产规模非常大。订单中商品的种类相对零售这种销售场景,其实是非常少且相对固定的,其成本和单价是每天进行一次计算和定价。

所以,我在思考过后,建议还是保留一个商品定价的事实,这是销售事实前的业务过程。在商品定价事实中有商品的成本计算相关的事实、单价等。另外在销售事实中,仍然会保留成本和单价这两个事实。对这个设计的解释,我认为销售业务过程中的单价和成本本身就是销售业务过程中的事实,但是追求其来源是产品定价中的事实。

3. 总结

谈及整个过程,我认为最核心的是找到我们的业务需求是什么。例如这个项目的场景中,对商品的成本和定价的分析本身是与企业生产资料相关的。而在这个企业的销售场景,在这里去分析产品的成本和定价其实是有点多余的,销售业务过程核心分析的还是销售本身。因为本身对一个产品品种不多,每天一个成本和定价的情况,

我在最开始之所以被困扰,就是我忽略了分析的本质,错误的看待产品的定价这个事实,选择性的视而不见。但是当我思考过后,重新看待分析的需求,我就不再有这个疑问。

通过这件事,我认为在做模型设计的时候,一定要尽可能的去参考一些前人对这些模型的设计。因为我们在初步进入一个行业的时候,对这些新行业的业务的理解都是有欠缺的,都是逐步去学习理解的。参考这些成熟模型,就会让你有了一个参照物,避免走入误区。再就是一定不要放弃思考,如果我一开始就以书中的参考模型为原型去设计,或者就是把成本和单价放到产品维度中,我就不会对这个设计有更深的理解。

最后感谢与我一起讨论这个问题的本质的同事们!谢谢大家!

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
一站式大数据开发治理平台DataWorks初级课程
DataWorks 从 2009 年开始,十ー年里一直支持阿里巴巴集团内部数据中台的建设,2019 年双 11 稳定支撑每日千万级的任务调度。每天阿里巴巴内部有数万名数据和算法工程师正在使用DataWorks,承了阿里巴巴 99%的据业务构建。本课程主要介绍了阿里巴巴大数据技术发展历程与 DataWorks 几大模块的基本能力。 产品官网 https://www.aliyun.com/product/bigdata/ide 大数据&AI体验馆 https://workbench.data.aliyun.com/experience.htm#/ 帮助文档https://help.aliyun.com/zh/dataworks 课程目标  通过讲师的详细讲解与实际演示,学员可以一边学习一边进行实际操作,可以深入了解DataWorks各大模块的使用方式和具体功能,让学员对DataWorks数据集成、开发、分析、运维、安全、治理等方面有深刻的了解,加深对阿里云大数据产品体系的理解与认识。 适合人群  企业数据仓库开发人员  大数据平台开发人员  数据分析师  大数据运维人员  对于大数据平台、数据中台产品感兴趣的开发者
目录
相关文章
|
分布式计算 调度 Spark
|
SQL 分布式计算 数据挖掘
Hive SQL初级练习(30题)
Hive SQL初级练习(30题)
|
7月前
|
Kubernetes Java 微服务
微服务上下线动态感知实现的技术解析
随着微服务架构的广泛应用,服务的动态管理和监控变得尤为重要。在微服务架构中,服务的上下线是一个常见的操作,如何实时感知这些变化,确保系统的稳定性和可靠性,成为了一个关键技术挑战。本文将深入探讨微服务上下线动态感知的实现方式,从技术基础、场景案例、解决思路和底层原理等多个维度进行阐述,并分别使用Java和Python进行演示介绍。
185 4
|
Java 应用服务中间件 Apache
Apache Maven项目的搭建与部署
Apache Maven项目的搭建与部署
474 0
|
11月前
|
存储 搜索推荐 算法
Java中的文本搜索与全文检索引擎
Java中的文本搜索与全文检索引擎
|
12月前
|
前端开发 JavaScript 应用服务中间件
经验大分享:nginx从仅支持80到支持80和443
经验大分享:nginx从仅支持80到支持80和443
483 0
|
存储 安全 关系型数据库
MySQL中使用percona-xtrabackup工具 三种备份及恢复 (超详细教程)
MySQL中使用percona-xtrabackup工具 三种备份及恢复 (超详细教程)
772 1
|
11月前
|
数据采集 人工智能 监控
阿里云百炼模型训练实战流程:从入门到实战应用
【7月更文第2天】阿里云百炼是AI大模型开发平台,提供一站式服务,涵盖模型训练到部署。用户从注册登录、创建应用开始,选择模型框架,配置资源。接着,进行数据准备、预处理,上传至阿里云OSS。模型训练涉及设置参数、启动训练及调优。训练后,模型导出并部署为API,集成到应用中。平台提供监控工具确保服务性能。通过百炼,开发者能高效地进行大模型实战,开启AI创新。
3303 2
|
Cloud Native Devops 持续交付
什么是云原生,原生开发和混合开发又是什么
什么是云原生,原生开发和混合开发又是什么
969 3
|
存储 SQL 分布式计算
Maxcompute拉链表应用(一)在数据开发中使用拉链表
最新在项目中进行存储优化的一个事情,于是就又把拉链表抬出来了。
7464 1

热门文章

最新文章