Microsoft的Demand planning Tables文档先描述一组继承自Supply Chain Management的层级：Site是父，每个Site可以有一个或多个Warehouse。它紧接着说明，所述版本的transformations只支持单层关系，因此Site Location表及其数据不能用于转换；但Site ID仍可从Warehouse Location表取得。表在资料模型中存在，与转换可以直接使用它，在同一段里就被分开了。[1]
Warehouse Location并非仅将站点表换一个名字。文档说，原Supply Chain Management中的Location表在Demand planning中改名为Warehouse Location，并增加Operation Site ID与Site Location ID两个本地列。这些列让资料能够基于仓库或站点标识展开；它又明确说，将仓库位置标识应用于历史需求，可以推导站点标识。站点信息仍被保留，但它所依附的表与取得路径已经需要具体说明。[1]
这项例子与后面的关系定义相接。文档说，一项relationship连接两张表，让存于不同表里的相关信息彼此匹配；只有来自相关表的列，才可在transformations中选择。因此，列属于哪张表、两表之间是否有关系，以及转换允许跨越多深的关系，构成不同条件。单独列出所有表名，尚未说明某一列是否处在该次转换可选的范围内。[1]
关系当前还有方向，必须保留from table和to table。原文说from一侧常是Historical Demand这样的交易资料表。它不是让阅读者从站点与仓库的父子名称，便自行补出任意方向都能追踪的规则；组织上的层级描述与转换所沿的表关系，必须连同各自的方向和单层限制理解，不能因都叫父子关系就自动视为同一条路径。[1]
关系的数量类型又单独列出多对一和多对多。对于多对多，文档说系统显示第一个匹配记录。这句话没有把多个匹配结果承诺为一组完整汇总，也没有说所有匹配列会依次合并进输出。关系能够表达多个候选，与当前文字说明实际呈现哪个匹配，是两个需要同时留下的条件；它们不会因为表已成功关联而自然合并。[1]
要把表转换为时间序列，来源还列出至少三列：DateTime类型的时间戳、Decimal或Integer类型的度量，以及String类型的维度。表的Key则另指一个或多个列的组合值，用于唯一识别每行。前三类列说明时间序列需要哪些信息角色，Key说明行的识别条件；即使同一份表同时满足两者，也不能只用“有三个字段”代替完整的字段类型与行身份说明。[1]
Historical Demand本身以订单形式保存历史需求，每单有buyer和seller，兼顾外部销售与公司间交易，内部订单的二者也可以相同。Order Type再把需求来源分为Sales、Transfer和Production。这个对象为前述from方向提供了具体背景：关系可能从一份带来源与参与方的需求记录出发，去匹配另一表的资料，而不是把所有表仅当作可以任意互换的地点清单。[1]
本文限于该页2024年2月21日更新的公开模型说明，保留“所述版本”的限制，不执行关系设置、导入删除或权限操作，也不推荐需求预测与供货策略。更新日不是已证首次发布日期。[1]
资料来源：
[1] [View and customize tables for holding imported data - Supply Chain Management | Dynamics 365 | Microsoft Learn](https://learn.microsoft.com/en-us/dynamics365/supply-chain/demand-planning/tables)
信息来源
本文基于上述公开资料整理，未使用来源页面的图片、视频或嵌入媒体。