背景知识
向顾客提供大量产品的国内和国际零售商都面临着共同的挑战：确保其众多的商店具有适当的产品库存级别。确定适当的库存级别问题需要在以下两种竞争成本间进行权衡。
|
1. |
高级别库存的存储成本。这些成本指零售商为安全的实际空间、额外的供应商购买以及在所有零售商店中与维持高级别产品库存相关的分配所支付的代价。 |
|
2. |
丧失销售的成本。如果顾客进入商店，想要购买某种特定的产品，但由于该产品已脱销而无法供货，就形成了这些成本。 |
面对这种进退两难的情况，零售商通常有两种选择。零售商可以保持高库存，而承担高库存成本；或者保持低库存成本，而承担在顾客需要购买时由于没有产品而丧失销售机会的风险。权衡这些竞争成本的最佳方式是构建预测模型来确保每个连锁商店都具有适当的库存级别。
过去零售商依靠供应链软件、内部分析软件甚至直觉来预测库存需求。随着竞争压力的一天天增大，很多零售商（从主要财务主管到库存管理员）都开始致力于找到一些更准确的方法来预测其连锁商店应保有的库存。预测分析是一种解决方案。它能够准确预测哪些商店位置应该保持哪些产品。
本文介绍如何使用 Microsoft(R) SQL Server(TM) 2005 中的 Analysis Services 以及 SQL Server 数据仓库，采用数据挖掘技术为产品存储决策提供准确及时的信息。此处介绍的方法用于在商店/产品级别上提供脱销预测。对于某种特定产品，SQL Server 2005 Analysis Services 用于构建数据挖掘模型，该模型为每个连锁商店提供脱销预测。此方法使零售商能够有效地权衡与存储产品库存相关的竞争成本。
关于 Project REAL
Project REAL 致力于找出创建基于 SQL Server 2005 的商业智能 (BI) 应用程序的最佳方法。在 Project REAL 中，我们通过创建基于真实客户方案的引用实现来进行。这意味着将客户数据引入内部，并使用这些数据来解决各个客户在部署过程中将会面临的相同问题。这些问题包括：
| ? |
架构设计 - 关系架构和 Analysis Services 中使用的架构。 |
| ? |
数据提取、转换和加载 (ETL) 过程的实现。 |
| ? |
客户前端系统的设计与部署，以便进行报告和交互式分析。 |
| ? |
生产系统的规模大小调整。 |
| ? |
对运行中的系统的管理与维护，包括对数据的增量式更新。 |
通过分析真实的部署情况，我们可以全面了解如何使用 SQL Server BI 工具实现 BI 系统。我们的目标是致力于解决可能希望分析大型数据集的公司在其实际部署中遇到的所有问题。
数据仓库说明
在 Project REAL 中，构建的数据仓库用于为在全国拥有数百家商店的零售商的数百万种产品汇总销售数据。用于构建脱销预测模型的相关数据集有：
| ? |
以商店级别、产品（项）级别、天级别合计的销售量事实数据。具体地说，是为已经销售的每种产品、零售商的每个连锁商店存储每日销售量。 |
| ? |
以商店级别、产品（项）级别、天级别合计的库存事实数据。具体地说，这是每种产品、每天、零售商的每个连锁商店的产品在库存中的天数。 |
| ? |
由产品名、说明、零售价和产品类别层次结构组成的产品（项）信息。 |
| ? |
由商店说明、商店分类（例如，指定是大型商店还是小型商店的指标）、商店分区、商店区域、商店地区、城市、邮政编码、省/自治区、货架空间线性尺寸和其他商店信息组成的商店信息。 |
| ? |
日期信息（日期维度），它将事实数据级日期标识符映射到相应的财务周、财务月、财务季、财务年和其他日期信息。 |
具有一个清晰、最新的数据仓库可以为所有商业智能应用程序利用此有用的信息资产提供可靠的基础。在此特殊的构建脱销模型的任务中，数据仓库简化了构建数据集模型的过程。
数据挖掘方法和构建数据集模型
根据在 Project REAL 中将数据挖掘技术应用于不同零售销售量预测和构建脱销模型问题所获得的经验，我们提出了通过两个阶段来构建模型，这一过程提高了准确预测的可能性。
构建模型过程的第 I 阶段是基于合计销售量模式对零售商的连锁商店进行分类。构建了质量商店分类模型后，在构造模型过程的第 II 阶段，这些分类用于使商店/产品级别上的脱销预测更加准确。通过使用 SQL Server 2005 Analysis Services 中的数据挖掘技术可以高效并有效解决这两个阶段。
本部分提供了整个脱销预测过程的详细信息，该过程从用于构建数据集模型的过程说明开始。然后对评估使用 SQL Server 2005 Analysis Services 构建的数据挖掘模型的方法进行了讨论。
构建脱销预测模型的过程
构建脱销模型分为两个阶段。
第 I 阶段是将具有相似合计销售量模式的连锁商店进行分类。对具有相似合计销售量模式的商店进行分类的过程称为“商店分类”。通过使用 SQL Server 2005 Analysis Services 中附带的 Microsoft 分类算法完成商店分类，从而将具有相似合计销售量模式的商店进行分类。将 Microsoft 分类算法应用于由合计销售量模式组成的数据集时，该 Microsoft 分类算法尝试通过以下方式对商店进行分类：属于同一分类的商店比属于不同分类的商店更加相似。构建数据集模型基于从数据仓库派生的合计销售量数据。因此，用于对商店进行分类的“相似性”测度是按照此合计销售量数据计算而来的。
然后，我们使用第 I 阶段生成的分类模型在第 II 阶段构建更准确的脱销预测模型。这允许预测算法（例如 Microsoft 决策树或 Microsoft 神经网络）使用分类结果来提高预测准确性。实质上，要优化特定商店 s 的特定产品 p 的预测，在确定商店 s 的 p 是否脱销时，SQL Server 2005 中的预测算法可能使用相似商店 s 中同一产品 p 的销售量事实数据，这样可以提高预测的准确性第 I 阶段：商店分类
注意，商店分类的目标是获得具有相似销售量模式的商店组，着重于产品 p 所属的类别 c(p) 中产品的销售量。
第 I 阶段首先构建将用于商店分类的数据集。为了将对活动零售销售量和库存数据仓库的计算影响降低到最低程度，我们建议您创建独立的 SQL 数据库来存储数据集，这些数据集用于使用 SQL Server 2005 Analysis Services 构建模型。
商店分类数据集构建
用于商店分类的数据集由 2004 年 1 月到 2004 年 12 月这段时间内的商店级合计销售量组成。该数据集由具有关键字 StoreID 的单个表组成。StoreID 是整数，用于唯一标识每个连锁商店。
由于商店分类任务的目标是根据合计销售量模式的相似性将商店进行分类，因此我们与零售商合作以便标识对此练习有用的一组合计销售量属性。用于构建模型的这组属性的类型和信息内容通常会影响生成的输出模型。标识用于构建模型的一组属性时，我们发现与对基本业务过程有深刻理解的利益关系人合作会有好处。另外，根据在直接零售过程中已经完成的工作，我们能够建议可能有用的属性。对于每个商店，基于数据仓库中的事实数据对属性进行合计。这些销售级合计如下。有关所有用于商店分类问题的商店级属性的详细说明，请参见附录 A。
SQL 计算这些商店级属性和合计值，并存储于单独的、不规范的表中。注意，此表仅用于通过 SQL Server 2005 中的数据挖掘组件构建模型。如果某个组织想更新运行中的商店分类模型，我们建议您自动化此不规范的表的构建来准备数据。另外，可以定义视图（而不是表），从而从规范的事实数据和维度数据创建不规范的结果集。
该表的每行都由唯一的整数 StoreID 进行索引，并且对以前列表中的每个属性/合计都对应地包含一列，这些属性/合计在附录 A 中有详细介绍。对于商店分类练习和构建脱销模型，考虑至少开业一年的商店。对于此特定零售商，这将为 794 个商店。因此，用于商店分类的单个 SQL Server 2005 关系表由 846 行和 100 列（1 列为 StoreID，其他 99 列用于存储在以前的属性值列表中定义的属性值）组成。
商店分类挖掘模型构建
构建源关系表后，我们通过 Microsoft Visual Studio(R) 2005 来继续构建商店分类挖掘模型。首先，在 Visual Studio 2005 中创建 Analysis Services 项目，然后创建连接到包含商店分类数据集的 SQL Server 实例的 Data Source 对象。还必须创建数据源视图。此数据源视图仅选择包含商店级属性和合计属性的单个表。参见图 1。
添加数据源视图后，将为商店分类练习创建新的挖掘结构和挖掘模型。挖掘结构定义将用于构建商店分类模型的列结构。除了 Cat Fraction Sales 和 Cat Total Sales Qty 属性以外，选择其他所有属性作为 Input 属性。选择 Cat Fraction Sales 和 Cat Total Sales Qty 属性作为 Predict（Input 和 Predictable）属性。参见图 2。
图 2：商店分类挖掘结构
与 Microsoft 分类算法相关联的 CLUSTER_COUNT 参数指定最大分类数，以便在源数据中搜索。在默认情况下，值为 10。为了生成能够充分捕获商店属性和合计销售量/库存值中的相关关系的不同分类，根据经验和对分类模型（发现有 5 个分类）质量的估计，CLUSTER_COUNT 的值被更改为 5。通常，分析软件需要更改 CLUSTER_COUNT 参数以获得所需结果。在此应用程序中，我们发现当 CLUSTER_COUNT = 5 时，找到不同的商店分类（分类基于合计销售中的相似性）。另外，证据表明使用 MINIMUM_SUPPORT = 50 时将在此应用程序中获得更高质量的分类模型。这表示 Microsoft 分类算法仅标识其中具有 50 或更多事例（此应用程序中为商店）的分类。同样，分析软件也要更改 MINIMUM_SUPPORT 以获得所需的分类质量。参见图 3。
图 3：Microsoft 分类算法参数
为 Microsoft 分类算法设置参数后，将处理挖掘结构，从而在 SQL Server 2005 Analysis Services 中创建和填充挖掘模型对象。
商店分类模型评估
构建商店分类模型后，使用 Microsoft SQL Server 2005 Analysis Server Cluster Browser 对这些模型进行评估以确定类别销售量模式是否确实区分了这些分类。
有关 SQL Server 2005 Analysis Services 找到的商店分类的摘要，请参见图 4。趋向于由 Total Sales、Category Sales Quantity、Category Weekly Sales、Category Weekly On-Hand 和 On-Order 值区别商店分类。图 4 为每个分类显示了属于特定分类的商店的示例城市/省值（图 4 中左边的列）和每个分类的区分因子（图 4 中右边的列）。
图 4：Chapter Book 类别的商店分类
注意，可以通过使用 SQL Server 2005 Analysis Services Cluster Model Viewer（参见图 5）中的 Discrimination（区分）选项卡来确定区分特征（属性/值）对。
图 5：分类模型区分视图
第 II 阶段：构建脱销预测模型
既然已经构建了商店分类模型（这些模型将具有相似类别销售量模式的商店进行分类），接下来我们将着重于预测特定的书在未来一周和未来两周是否脱销的问题。在构建挖掘模型进行脱销预测之前，我们先为关注的每个产品（书）构建模型数据集。
构建脱销预测模型数据集
用于脱销预测模型任务的数据集需要考虑所有零售连锁商店的特定书的每周销售数据。根据经验和可用的历史数据量，我们开发了“滑动窗口”策略来创建用于构建预测模型的数据集。当数据是时间数据（例如，对未来进行预测时）并且可预测数量类型为离散类型（例如布尔脱销指标或销售箱）时，滑动窗口策略通常为良好的数据准备策略。如果具有足够的时间数据，并且可预测数量原本就为数字数量，时间系列构建模型可能为首选策略。
通过研究数据并着重于问题的环境，我们进行了以下观察。在每周内，特定书以及特定商店的历史销售和库存数据生成了 52 条记录（一年的所有数据）。通常，单个商店和单个产品很少发生脱销事件。为了获得准确的预测模型，练习数据需要包含足够数量的脱销事件和库存事件来标识区分这两者的趋势。通过考虑整个连锁商店的特定产品 p，以下数据准备策略用于获得足够数量的脱销事件和库存事件。我们包括商店分类标签（从商店分类模型派生而来），以便使构建预测模型算法可以标识不同商店分类之间可能不同的脱销行为的趋势。
特定产品（书）p 的脱销预测模型数据集构建
为了更加客观地评估使用 SQL Server 2005 Analysis Services 构建的模型的预测准确性，通常会抽取一部分数据（称为“测试集”）。数据集的其余部分称为“练习数据集”。数据挖掘模型是使用练习数据集构建的。然后，将从模型中产生的预测与测试集上产生的实际值进行比较。
对于此应用程序中的练习数据集中的数据，我们使用与 2004 年 1 月 1 日到 2004 年 11 月 30 日之间的周相对应的数据集中的所有记录。对于测试集，我们使用数据与 2004 年 12 月 1 日到 2004 年 12 月 31 日之间的周相对应的数据集中的所有记录。
与特定产品（书）p 相对应的练习数据集由 10,635 行组成。（注意，对于 2004 年 1 月 1 日到 2004 年 11 月 30 日之间的周，每个商店/周对都对应一行。）除了商店/周标识符（键）列以外，练习数据集还包括 38 列。数据集中也包括其他列（如 Store_ID 和 Week_ID），但是它们不用于构建模型。
与特定产品（书）p 相对应的测试数据集由 2,442 行组成。注意，对于 2004 年 12 月 1 日到 2004 年 12 月 31 日之间的周，每个商店/周对都对应一行。）在测试数据集中，除了唯一的商店/周对标识符（键）列以外还包括 38 列。
脱销挖掘模型构建
构建源关系表之后，通过 Visual Studio 2005 来构建预测数据挖掘模型。为此，将创建第一个 Analysis Service 项目和数据源，该项目和数据源为考虑中的产品（书）指定 SQL Server 实例（该实例用于存储练习表和测试表）。已创建选择所需表的数据源视图。参见图 6。
图 6：脱销预测模型数据源视图
添加数据源视图之后，将为构建脱销预测模型练习创建新的挖掘结构。将 Current Weekly Sales、Historic Weekly Sales、On-Hand 和 On-Order 属性指定为输入属性。将布尔脱销标志和每周销售箱属性（OneWeekOOSBoolean、TwoWeekOOSBoolean、OneWeekSalesBin、TwoWeekSalesBin）指定为可预测 (Predict Only) 属性。
构建 Microsoft 决策树和 Microsoft 神经网络模型以确定哪个算法生成最准确的模型（通过将预测与测试集上产生的实际值进行比较来测度）。构建初始挖掘结构和挖掘模型后（指定输入和可预测属性），分析软件可以轻松地添加其他挖掘模型。（可以使用“添加挖掘模型”功能尝试不同的算法。）注意，在图 7 中，Input 表明该属性值将被用作预测模型的输入。PredictOnly 表明这些值应当由数据挖掘模型预测。Key 表明该列唯一标识感兴趣的情况。分析软件也可以将属性类型设置为 Predict。此属性类型表明属性同时可用于输入属性和可预测属性。（当它用于预测其他属性值时，应考虑为 Input 属性。）
图 7：具有 Microsoft 决策树和神经网络挖掘模型的脱销挖掘结构
我们发现更改 COMPLEXITY_PENALTY 和 MINIMUM_SUPPORT 的默认值后，使用 Microsoft 决策树算法可以获得非常准确的预测模型。我们使用 COMPLEXITY_PENALTY = 0.10。这可能导致较大（较详细）的决策树。较大、较详细的决策树能够更加准确地对练习数据构建模型，甚至某种程度上可以对练习数据中的“干扰”构建模型。这种情况称为“臃肿”，通常导致对提取的数据集或测试数据集的较差预测。另外，较大、较详细的决策树可能需要稍多的计算来进行预测。MINIMUM_SUPPORT 的值也被降低到 5 – 这也可能导致较大的决策树。图 9 显示了这些变化。
图 8：Microsoft 决策树算法参数
构建预测模型结果
以经验为依据的结果
如上所述，挖掘模型的预测准确性通过在测试集（与 2004 年 12 月 1 日到 2004 年 12 月 31 日之间的周相对应的数据）上检查它们来评估。
通过使用 SQL Server 2005 Analysis Services 中的提升图功能来评估挖掘模型。提升图通过指定数据集提供特定数据挖掘模型的预测性能的整体图。在这种情况下，我们为此评估使用测试数据集。提升图将挖掘模型的预测性能与理想模型和随机模型的预测性能进行比较。图 9 显示了书 Captain Underpants 的布尔两周脱销预测的提升图。任务是预测任意零售连锁商店中的书是否将在未来两周内脱销。注意，此模型的整体预测准确性与理想模型非常接近。
图 9：两周布尔脱销预测的提升图
图 10 汇总了当书在未来两周确实脱销时，商店/周组合的预测性能。
图 10：累积图 – 当产品在未来两周脱销时，在识别商店/周组合过程中的性能。
图 11 显示了预测两周脱销布尔值的 Microsoft 决策树算法的图形说明。
图 11：Captain Underpants 的两周 OOS 决策树
图 12 汇总了此任务中所考虑的全部五种产品（书）的预测准确性。平均来说，SQL Server 2005 Analysis Services 获得的数据挖掘模型可以预测在未来一周内一本书是否将脱销，准确性为 98.52%。平均来说，预测该书是否将在未来两周内脱销的准确性为 86.45%。当预测实际销售箱值时，预测准确性会上升。
图 12：五种产品（书）的脱销预测准确性
详细内容见：https://www.microsoft.com/china/technet/prodtechnol/sql/2005/ipmvssas.mspx
