综述
产品定义为已经、正在或者将要被销售的货物或者服务
本文适用于类似零售商等产品来源于多个供应商的复杂场景。
如果是自产自销的工厂一类，可以适当裁剪模型。
而如果是平台商，则需要将该模型增加商户列进行隔离各商户的信息
原文见：数据建模2-产品
逻辑模型
在实际业务场景中，我们的数据模型需要描述产品的
产品定义
-
产品定义唯一标记了一种商品，一般来说，不同种类的商品都会有其对应的标准，有的是国标，有的是行业通用标准，比如书籍的ISBN号等。但是我们在内部管理的时候，由于我们很少会只有一类商品在售卖，因此我们往往会将其转化为内部的统一编号，比如SKUID
每个产品都有其对应的供应商，但是这并不是一对一的，很多时候我们会同时在多个供应商手上进行采购产品并混合在一起售卖
产品属性
-
存储产品的各种信息
产品定价
-
在现代企业管理中，一个产品的定价往往不是单一的，在不同的地区、不同的客户、不同的组织下面我们往往会维护着不同的定价策略，因此我们很多时候会对同一个商品有着好几套定价方案。
产品定价往往是一个复杂的过程，需要
产品类别
-
与一般印象不同，产品分类并不是一个简单的对商品做一个类型归属，与之相反它是一个比较复杂的学问。一般公司对于产品都会有多种分类方式存在，适用于不同的业务场景，比如前台类目用于给客户分类查找产品，管理类目用于给采购或者销售进行绩效激励等等。
更进一步，有时候我们的类目会映射到人或者组织，这是因为选品或者按品类运营的业务同学需要用他们来计算绩效或者用以做运营抓手
因此，我们的产品类别数据模型必须足够灵活，支持多种类别共存，同时支持灵活调整产品的分类。
产品间关系
-
产品之间存在两大类关系
组套产品：譬如我们在京东购买的散装的牙刷+牙膏，但是其实有时候他们和单独的牙膏牙刷是共享库存，也就是说1个牙刷+一个牙膏=牙刷牙膏套装*1，一旦购买套装，牙刷和牙膏还有套装的库存都会同时减一
原材料：
产品的变化
-
事务（采购等）
记录采购、报损等等对商品操作的具体事务明细信息。
库存
库存管理是产品供应链管理的核心之一，在业务上我们需要根据库存变化制定相应的采购计划、根据产品的保质期制定淘汰库存，优化产品在仓储甚至供应链中的库存情况等等。
为此，我们的数据模型应当能准确反应各个仓储甚至供应链中的库存的情况以及保留下来库存的所有变动记录
订单
产品就是为了销售而生，因此必须要能够保留下销售中订单的各种信息。这一部分将在后续章节中讲
关系型数据库模型
根据上文，在业务系统中，我们会按照三范式设计关系型数据库的物理模型如下：
产品信息
-
产品表
主键为产品ID
存储最基本的属性信息
产品基础属性表
主键为产品ID+属性ID
存储各种属性，拆解出来是由于产品的属性往往为不定项，兼容较为复杂的场景。如果我们的产品较为标准化，也可都合并为一行甚至取消该表，将属性放置到产品表内
价格
-
产品价格表
有两种设计模式
一种是一张当前价格表+价格变更流水表
优点是使用方便，价格表作为高查询低写入的代表，我们往往需要表获得较高的查询性能，这种设计方式索引建立后基本无需更改且索引效率较高
缺点是如果需要使用历史价格的时候较为复杂，因此可以引入第二种方案
另一种是一张一张价格变更明细表，通过有效时间来获取某个时间段内的价格
优点是结构清晰
缺点是使用不太方便且性能不太行，产品ID+时间的索引性能不如直接产品ID
产品类别
-
产品类别表
主键是产品ID+产品类别ID+产品类别类型ID
用于标记产品归属的类别
产品类别关系表
主键是产品类别甲ID+产品类别乙ID
用于标记产品类别间的关系，比如层级，当然如果产品间关系很简单，比如是树状层级，可以直接去掉这个表，将其放到产品类别表内
类别表
主键是产品类别ID+产品类别类型ID
记录类别的基础信息，特别是归属组织和负责人
库存：设计思路类似价格表。
-
库存表
主键是产品+仓库+库位
库存流水表
主键是库存流水ID
采购等事务（采购、报损等等）
-
产品采购单表
主键是采购单ID
记录采购单的各种信息
订单
-
订单表
订单表将在后面作为一个单独章节讲述，本章不再展开
离线数据仓库模型
与人员和组织部分类似，对于产品主题来说，数仓需要反应的是：
产品的信息和属性，以及它们的变化过程
产品与产品、产品与人和组织的关系
在维度建模的思想下：
产品表
-
核心表，存储产品当前的各种属性
主键为快照日期+产品ID
全量快照表，作为维表供其他表关联
产品价格表
-
存储产品在不同地区或者不同客户中的价格，以及记录价格变动记录
有两种设计思路
一是如下图所示，按照天或者小时粒度，保留价格表的全量快照
主键为产品ID+组织ID/地区ID+日期
优势在于使用方便
劣势在于会丢失部分价格变动信息
一是类似拉链表的方式，通过开始时间结束时间保留每次价格的变动记录
主键为产品ID+组织ID/地区ID+开始时间+结束时间
优势在于可以保留最细粒度的价格变更记录
劣势在于使用起来较为复杂
产品类别表
-
存储产品的各种类别和关系
有两种设计思路
如果类别间关系是较为简单的树状层级，可以如下图所示，将所有层级作为字段摊开在表内
主键为产品ID+产品类别ID+快照日期
如果类别间关系是多对多（一般不会，因为层级除了用于分类外，一般也用于体现产品负责人对产品的管理情况，此时也一般会按照树状结构进行管理）
类别表：主键为产品ID+产品类别ID+快照日期
类别关系表：主键为产品类别甲ID+产品类别乙ID+快照日期
库存部分：
-
库存快照表
存储每天产品的库存情况
主键为产品ID+产品类别ID+快照日期
库存流水表
存储每次库存变动的记录，一旦遇到历史库存记录不正确，可以通过库存流水表还原出每天的库存快照
主键为流水ID
事务表
-
采购单表
存储采购单的具体信息
主键为采购流水ID
报损单表等，结构类似，不再赘述
订单表
-
订单表将在后面作为一个单独章节讲述，本章不再展开
基于数据使用的应用层设计
产品主题在业务中属于非常基础的信息，往往会作为维表用于关联出维度信息供下游表统计使用。有意思的在于由于它过于基础，如果将所有属性冗余到下游表内，可能导致变更成本极高，因此进行字段冗余的时候需要有所取舍。
同时，我们也会对产品进行一些常用的分析，用于得到公司的产品的各种信息汇总和变化。
而且，我们也会对产品打上大量的标签，给下游系统使用
对于不同的数据使用方，会有着不同的诉求，我们可以提供的支持产品也往往不同
管理层
对于管理层来说：
除了第一章里面描述的支持各种下钻和推送的产品各种指标的管理报表外
还需要有一个清晰、更新及时、包括所有历史的产品和类别全貌信息，作为管理抓手，用于绩效、管报等各种场景
基于以上的诉求，我们可以提供的是
一个具有交互能力且直观清晰的管理报表，包含管理层关心的所有指标，并有合理的分类
支持产品和类别动态更新的能力
运营&业务
在产品领域中，运营和业务同学往往聚焦在
使用明细数据去排查问题，比如缺货原因等
根据产品情况的分析报表，制定运营策略。比如部分产品的销量、异动、库存情况。
选品、缺货归因
供应链优化
基于以上的诉求，我们可以提供的是
基于维度建模的明细大宽表，产品的库存、流水变动、采购等信息
各种时间粒度的产品分析报表
-
提供各类维度：组织、城市、区域，产品ID，产品类型等等
具体的专题产品，如
-
选品
缺货分析等等
数据科学家/BI
在产品这个领域中，商分
基于汇总或者明细报表进行写SQL或者EXCEL分析业务现状，进行未来预测，提供分析报告
根据业务和基础数据，制定指标口径，选择能够真实反映业务的指标
设计产品标签，如爆品等等
基于以上的诉求，我们可以提供的是
基于维度建模的明细大宽表
各种时间粒度的商品分析报表
-
提供各类维度：组织、城市、区域，商品ID等等
标签系统，类似用户画像，用于
-
主键是快照日期+产品ID
结构
见前一章节
算法
算法在产品领域内可以做的事情较多
供应链和库存的优化
基于历史的商品销量预测
缺货原因分析预警等等
基于以上的诉求，我们可以提供的是
标签系统，类似用户画像
-
结构和设计见上文
小结
产品涉及范围较广，核心是产品的基础信息、分类、定价和数量变化。因此建立模型的关键是体现现状和变化。而使用数据的时候产品的表往往作为维度表，用作分析的各种维度。