Modelagem de previsão de estoque com o Microsoft SQL Server 2005 Analysis Services

Artigo
03/27/2009

Por Apollo Data Technologies

Artigo técnico sobre o SQL Server
Publicado em: Setembro de 2005
Aplica-se a: SQL Server 2005

Resumo: Este documento descreve uma abordagem para a criação de modelos de previsão de indisponibilidade de estoque de varejo usando o SQL Server 2005 Analysis Services. Quando aplicados aos dados do Project REAL, esses modelos produzem previsões muito precisas. O varejista cujos dados tenham sido usados no Project REAL poderia aumentar potencialmente as vendas em milhões de dólares por ano se esses modelos de previsão fossem implantados na empresa.

Nesta página

Informações básicas
Sobre o Project REAL
Descrição do armazém de dados
Metodologia de mineração de dados e construção de conjunto de dados de modelagem
Resultados de modelagens de previsão
Automação das previsões de estoque
Conclusão
Apêndice A: Atributos de agrupamento de lojas
Apêndice B: Consulta DMX de indisponibilidade de estoque

Informações básicas

Varejistas nacionais e internacionais que oferecem um grande número de produtos aos clientes enfrentam o desafio comum de garantir níveis adequados de estoque de produto disponível em centenas ou milhares de lojas. O problema de determinar os níveis de estoque adequados equilibra os seguintes custos concorrentes.

O custo de armazenar altos níveis de estoque. Esses custos se referem ao preço que é pago pelo varejista para garantir o espaço físico, para compras de fornecedor extra e para a distribuição associada à manutenção de altos níveis de estoque de produto em todas as lojas de varejo.
O custo das vendas perdidas. Esses custos são incorridos quando um cliente vai a uma loja e deseja comprar um determinado produto, mas não consegue porque o produto está fora de estoque.

Normalmente tem havido duas alternativas para o varejista diante desse dilema. O varejista pode manter estoques elevados e incorrer num alto custo de estoque ou então manter o custo de estoque baixo e correr o risco de perder oportunidades de venda porque um produto está indisponível no momento da compra desejada. A forma ideal de combater esses custos concorrentes é utilizar modelos de previsão para garantir que cada loja da cadeia tem os níveis de estoque corretos.

Os varejistas historicamente têm confiado numa combinação de software de cadeia de fornecimento, analistas internos e intuição para prever as necessidades de estoque. Com a pressão de margem cada vez maior, muitos varejistas do chefe do financeiro ao gerente de estoque se concentraram em descobrir métodos mais precisos para prever o estoque em toda a cadeia. A análise de previsão é a solução. Ela fornece a capacidade de prever com precisão os produtos certos para os locais de lojas certos.

Este documento descreve o uso do Analysis Services no Microsoft® SQL Server™ 2005, junto com um armazém de dados do SQL Server para empregar a tecnologia de mineração de dados para fornecer informações atualizadas e precisas das decisões de estoque de produto. A metodologia apresentada aqui foi criada para fornecer previsões de indisponibilidade de estoque no nível da loja/produto. Para um determinado produto, o SQL Server 2005 Analysis Services é usado para criar um modelo de mineração de dados que faz as previsões de indisponibilidade de estoque para cada loja da cadeia. Essa abordagem possibilita ao varejista equilibrar com eficácia os custos concorrentes associados à estocagem de produtos.

Sobre o Project REAL

O Project REAL é uma iniciativa para descobrir as melhores práticas para criar aplicativos de inteligência dos negócios (BI, business intelligence) que se baseiem no SQL Server 2005. No Project REAL estamos fazendo isso criando implementações de referência com base em situações de cliente reais. Isso significa que os dados de clientes são trazidos internamente e usados para superar os mesmos problemas que os clientes enfrentam durante a implantação. Esses problemas incluem:

O design de esquemas, tanto os esquemas relacionais quanto os usados no Analysis Services.
A implementação de processos de ETL (extração, transformação e carregamento) de dados.
O design e a implantação de sistemas de front-end de clientes, para a geração de relatórios e análise interativa.
O dimensionamento de sistemas para produção.
O gerenciamento e a manutenção dos sistemas em uma base contínua, incluindo atualizações incrementais dos dados.

Ao trabalharmos com situações de implantação reais, obtemos uma compreensão completa de como implementar um sistema de BI usando as ferramentas de BI do SQL Server. Nosso objetivo é tentar abordar toda a gama de problemas que uma empresa que deseja analisar conjuntos potencialmente grandes de dados enfrenta durante uma implantação de verdade.

Esse documento resume o trabalho de mineração de dados que foi realizado pelo Project REAL até hoje. Vários documentos descrevem o trabalho realizado e as lições aprendidas em outras áreas. Para saber as informações mais recentes, visite o site do Project REAL (https://www.microsoft.com/sql/bi/ProjectREAL/).

Descrição do armazém de dados

No Project REAL, um armazém de dados foi construído para resumir os dados de vendas de milhões de produtos para um varejista com várias centenas de lojas em todo o país. Os conjuntos de dados relevantes usados para os modelos de previsão de indisponibilidade de estoque são:

Dados de fatos de vendas que são agregados na loja, produto (item), nível do dia. Especificamente, as vendas do dia são armazenadas para cada produto vendido, em cada loja da cadeia do varejista.
Dados de fatos de estoque que são agregados na loja, produto (item), nível do dia. Especificamente, esse é o número de dias que o produto ficou em estoque, para cada produto, em cada dia, em cada loja da cadeia do varejista.
As informações de produto (item) consistem em nome do produto, descrição, preço de varejo e hierarquia da categoria do produto.
As informações da loja consistem em descrição da loja, classificação da loja (por exemplo, um indicador que especifica se a loja é grande ou pequena), divisão da loja, região da loja, distrito da loja, cidade, CEP, estado, pés lineares de espaço em prateleiras e outras informações da loja.
Informações de data (uma dimensão de data) que mapeia identificadores de data no nível do fato para semanas, meses, trimestres, anos fiscais apropriados e outras informações de datas.

Ter um armazém de dados limpo e atualizado fornece uma base sólida para todos os aplicativos de inteligência de negócios utilizarem esse ativo de informações valioso. Nessa tarefa particular de modelagem de indisponibilidade de estoque, o armazém de dados permitiu a construção fácil de conjuntos de dados de modelagem.

Metodologia de mineração de dados e construção de conjunto de dados de modelagem

Baseado na experiência que obtivemos da aplicação da tecnologia de mineração de dados a várias previsões de vendas no varejo e problemas de modelagem de indisponibilidade de estoque durante o Project REAL, desenvolvemos um processo de modelagem em duas fases que aumenta a probabilidade de previsões precisas.

A Fase I do processo de modelagem consiste no agrupamento de lojas da cadeia de varejo de acordo com padrões de vendas agregadas. Depois que os modelos de agrupamentos de loja de qualidade forem construídos, esses agrupamentos serão usados para fazer previsões de indisponibilidade de estoque mais precisas no nível da loja/produto durante a Fase II do processo de modelagem. Ambas as fases são abordadas de forma eficiente e eficaz usando a tecnologia de mineração de dados no SQL Server 2005 Analysis Services.

Esta seção fornece detalhes do processo de previsão de indisponibilidade de estoque geral começando com a descrição do processo utilizado para criar os conjuntos de dados de modelagem. Ela é seguida por uma discussão de metodologias para avaliar os modelos de mineração de dados que são construídos usando o SQL Server 2005 Analysis Services.

Processo de modelagem de previsão de indisponibilidade de estoque

O problema de modelagem de indisponibilidade de estoque é abordado em duas fases.

A Fase I consiste em agrupar as lojas que têm padrões de vendas agregadas similares em toda a cadeia. O processo de agrupar lojas que têm padrões de vendas agregadas similares chama-se agrupamento de lojas. O agrupamento de lojas é atingido usando o algoritmo do Microsoft Clustering lançado no SQL Server 2005 Analysis Services para agrupar lojas que tenham padrões de vendas agregadas similares. Quando aplicado aos conjuntos de dados que consistem em padrões de vendas agregadas, o algoritmo do Microsoft Clustering tenta reunir lojas em agrupamentos de uma forma que lojas que pertençam ao mesmo agrupamento sejam mais similares umas às outras do que as que pertençam a agrupamentos diferentes. O conjunto de dados de modelagem é baseado em dados de vendas agregadas que derivam do armazém de dados. Assim, a medida da "similaridade" que é usada para agrupar lojas é calculada com esses dados de vendas agregadas.

Em seguida, usamos os modelos de grupos que foram produzidos na Fase I para criar modelos de previsão de indisponibilidade de estoque mais precisos na Fase II. Isso permite que os algoritmos de previsão (como Microsoft Decision Trees ou Microsoft Neural Networks) utilizem os resultados do agrupamento para aumentar a precisão da previsão. Essencialmente, para otimizar as previsões de um determinado produto p em uma determinada loja s, os algoritmos de previsão no SQL Server 2005 podem usar o fato de que as vendas do mesmo produto p em uma loja similar s podem aumentar a precisão da previsão quando determinam se p ficará ou não fora de estoque numa loja s.

Etapas de nível superior para a construção de modelos de previsão de indisponibilidade de estoque para o produto p

O processo em duas fases para a construção de modelos de previsão ótimos usando o SQL Server 2005 Analysis Services consiste nas etapas de nível superior a seguir. Os detalhes sobre essas etapas são fornecidos nas próximas seções.

Use a hierarquia do produto na porção das informações do produto (dimensão) do armazém de dados para determinar a categoria de produto c(p) para o produto p. Presumimos que produtos dentro da mesma categoria tenham padrões de vendas agregadas similares em toda a cadeia de lojas. Assim, a hierarquia do produto é usada para identificar o conjunto de produtos similares c(p) para um determinado produto p. Como alternativa, uma abordagem com o grupo de produto poderia ser usada para definir um grupo de produtos orientado por dados similar a p agrupando produtos com base em suas vendas em toda a cadeia de lojas.
Prepare o conjunto de dados de modelagem de Dagrupamento para o agrupamento de lojas para capturar as propriedades e vendas no nível da loja para a categoria c(p) como determinado na etapa 1.
Aplique o algoritmo do Microsoft Clustering ao conjunto de dados Dagrupamento para obterk agrupamentos (grupos) dessas lojas que sejam similares em todas as propriedades e vendas no nível da loja para a categoria c(p).
Para cada agrupamento l = 1,…,k obtido na etapa 3:
1. Considere S(l) o conjunto de lojas que pertencem ao agrupamento l. Lembre-se de que essas lojas têm vendas agregadas no nível da categoria similares, para a categoria c(p).
2. Crie um conjunto de dados DOOS(p,S(l)) que consista no histórico de vendas semanais, nas vendas semanais atuais agregadas e nas mudanças das vendas semanais agregadas, para cada loja s em S(l). Além disso, inclua indicadores booleanos que informem se o produto p estará em estoque ou fora de estoque dentro de uma ou duas semanas.
3. Aplique os algoritmos de modelagem de previsão do SQL Server 2005 Analysis Services (como Microsoft Decision Trees ou Microsoft Neural Networks) ao conjunto de dados DOOS(p,S(l)). Use as vendas agregadas do histórico semanal e da semana atual como atributos de entrada e os indicadores booleanos de uma ou duas semanas de indisponibilidade de estoque como atributos de saída ou apenas de previsão. Isso instrui o SQL Server 2005 Analysis Services a gerar um modelo que toma como entrada as vendas semanais atuais e do histórico semanal, junto com mudanças nas vendas semanais e, em seguida, faz uma previsão dos indicadores booleanos que informam se um produto ficará ou não fora de estoque dentro de uma ou duas semanas.

As preparações de dados e as etapas de modelagem são descritas em mais detalhes nas próximas duas seções.

No contexto do Project REAL, o varejista é a Barnes & Noble. O Project REAL (uma sigla de Reference implementation, End-to-end, At scale e Lots of users) é um esforço de cooperação entre a Microsoft Corporation, Apollo Data Technologies e outros parceiros de tecnologia de elite, entre eles UNISYS, EMC2, ProClarity, Panorama, Scalability Experts e Intellinet com o objetivo de criar uma implementação referenciável de um sistema de BI.

Usando os dados de empreendimento autênticos fornecidos pela Barnes & Noble, os colaboradores do Project REAL foram capazes de descobrir as melhores práticas para criar aplicativos de BI baseados no Microsoft SQL Server 2005. Esse sistema completo funciona por toda a gama de desafios operacionais do cliente analisando grandes conjuntos de dados de uma forma abrangente.

O foco eram os cinco produtos seguintes (livros), todos eles dentro da mesma categoria (Chapter Books).

Captain Underpants & The Invasion of the Incredibly Naughty Cafeteria Ladies from Outer Space (Captain Underpants Series)
Junie B Jones Is a Graduation Girl
Dinosaurs: A Nonfiction Companion to Dinosaurs Before Dark (Magic Tree House Research Guide Series #1)
City in the Clouds (Secrets of Droon Series #4)
Twisters and Other Terrible Storms (Magic Tree House Research Guide Series)

Fase I: Agrupamento de lojas

Lembre-se que o objetivo do agrupamento de lojas é obter grupos de lojas que tenham padrões de vendas similares, concentrados nas vendas dos produtos da categoria à qual o produto p pertence c(p).

A Fase I começa com a construção do conjunto de dados que será usado para o agrupamento de lojas. Para minimizar o impacto computacional nas vendas de varejo e no armazém de dados de estoque, recomendamos a criação de um banco de dados SQL separado para armazenar os conjuntos de dados usados para modelagem com o SQL Server 2005 Analysis Services.

Construção de conjunto de dados de agrupamento de lojas

O conjunto de dados usados para o agrupamento de lojas consiste nas vendas agregadas no nível da loja durante o período de Janeiro de 2004–Dezembro de 2004. O conjunto de dados consiste em uma única tabela com a chave StoreID. StoreID é um inteiro que identifica de forma única cada loja da cadeia.

Uma vez que o objetivo da tarefa de agrupamento de lojas é agrupar lojas com base na similaridade de padrões de vendas agregadas, trabalhamos com o varejista para identificar um conjunto de atributos de vendas agregadas que seriam úteis para esse exercício. O tipo e o conteúdo das informações do conjunto de atributos que são usados para modelagem afetam geralmente os modelos de saída que são produzidos. Quando montamos o conjunto de atributos a serem usados para modelagem, achamos benéfico trabalhar com acionistas que tenham uma compreensão sólida dos processos de negócios subjacentes. Além disso, com base no trabalho que fizemos no vertical do varejo, podemos recomendar atributos que podem se revelar úteis. Para cada loja, os atributos foram agregados com os dados dos fatos no armazém de dados. Esses totais no nível das vendas são conforme o seguinte. Para uma descrição detalhada de todos os atributos no nível da loja usados para o problema do agrupamento de lojas, veja o Apêndice A.

Os atributos derivados de categorias específicas para a categoria a que o produto (livro) p pertence (referido como c(p) na seção anterior). Eles são:
- Category Average Weekly Modeled: Estima o número de livros que se espera sejam vendidos na categoria, por semana em uma determinada loja.
- Category Average Weekly On Hand: Valores de média semanal disponível (em estoque) da categoria na loja determinada.
- Category Average Weekly On Order: Média do número de livros encomendados por semana, para a categoria na loja determinada.
- Category Fraction Holiday Sales: Fração de vendas de natal totais de livros na categoria c(p) na loja determinada. Observe que as vendas de natal são aquelas que ocorrem entre 15 de novembro de 2004 e o final de dezembro de 2004.
- Category Fraction Sales: Fração de vendas totais de livros fora do período de natal na categoria c(p) na loja determinada. Observe que as vendas fora do período de natal ocorrem entre 1º de janeiro de 2004 e 14 de novembro de 2004.
- Category Holiday Discount Amount: Quantia total de descontos em livros na categoria c(p) durante o período de natal, na loja determinada.
- Category Holiday Markdown Amount: Quantia total de redução de preços em livros na categoria c(p) durante o período de natal, na loja determinada.
- Category Holiday Member Discount Amount: Desconto total do membro concedido para livros na categoria c(p) durante o período de natal, na loja determinada.
- Category Holiday Sales Amount: Total de vendas de livros na categoria c(p) durante o período de natal, na loja determinada.
- Category Holiday Sales Quantity: Quantidade total de livros na categoria c(p) vendidos durante o período de natal, na loja determinada.
- Category Total Discount Amount: Quantia total de descontos em livros na categoria c(p) fora do período de natal, na loja determinada.
- Category Total Markdown Amount: Quantia total de redução de preços em livros na categoria c(p) fora do período de natal, na loja determinada.
- Category Total Member Discount Amount: Desconto total do membro concedido para livros na categoria c(p) fora do período de natal, na loja determinada.
- Category Total Sales Amount: Total de vendas de livros na categoria c(p) fora do período de natal, na loja determinada.
- Category Total Sales Quantity: Quantidade total de livros na categoria c(p) vendidos fora do período de natal, na loja determinada.
Para cada uma das categorias seguintes, a fração de vendas de natal totais da categoria foi computada (por exemplo, Cat Frac Holiday Sales no Apêndice A). Além disso, a fração de vendas totais fora do período de natal da categoria foi computada (por exemplo, o atributo do Cat Frac Sales no Apêndice A). Com base no feedback do varejista, as categorias consideradas para capturar as vendas gerais de nível superior foram: Beginning Reader, BG Bestseller, BGCKBKS Under 15, BG Reference, Blank Books, Board Block Touch, Chapter Books, Christian Insp, Cooking, Current Affairs, Family Child Care, Fantasy, Fiction, Fiction PB Young Readers, Hist Biog, Humor, Juv Activity, Juv Christmas, Juv Series HC, Juv Series PB, Juv Work Books, Literature, Magazines, Management, Manga Japanese, Mystery, New Age, Newspapers, Pict Sty Bks, Pop Rock, Romance, Science Fiction, Self Improvement, Single Cards, Spinner, Techno Thriller Espionage e Teen Fiction.
Foram incluídos também os totais no nível de loja seguintes.
- Total Holiday Sales: Total de vendas de todos os livros da loja durante o período de natal.
- Total Sales: Total de vendas de todos os livros da loja fora do período de natal.
- Total Weekly Average Modeled: Estimativa de média semanal do número total de livros vendidos na loja.
- Total Weekly Average On Hand: Média semanal do total de livros disponíveis em determinada loja.
- Total Weekly Average On Order: Média semanal do total de livros encomendados em determinada loja.
As seguintes propriedades da loja foram também incluídas no conjunto de dados de agrupamento de lojas: Cidade, Pés lineares (o número de pés lineares de espaço em prateleira na loja), Pés quadrados (da loja) e Estado.

Essas propriedades e valores agregados no nível da loja foram computados através de SQL e armazenados em uma única tabela desnormalizada. Observe que essa tabela é utilizada apenas para modelagem através dos componentes de mineração de dados no SQL Server 2005. Se uma organização quiser atualizar os modelos de agrupamentos de loja de uma forma contínua, recomendamos automatizar a construção dessa tabela desnormalizada como uma etapa de preparação de dados. Como alternativa, uma exibição poderia ser definida em vez de uma tabela, criando assim um conjunto resultante desnormalizado de dados de dimensão e fatos normalizados.

Cada linha da tabela é indexada por um único inteiro StoreID e contém uma coluna para cada propriedade/total relacionado na lista anterior e descrito em detalhes no Apêndice A. Tanto para o exercício de agrupamento de lojas e modelagem de indisponibilidade de estoque, foram consideradas lojas abertas há pelo menos um ano. Isso resultou em 794 lojas desse varejista em particular. Daí a tabela relacional única do SQL Server 2005 que foi usada para o agrupamento de lojas que consistiu em 846 linhas e 100 colunas (1 coluna para cada StoreID e 99 colunas para armazenar os valores de atributos como definidos na lista anterior de valores de atributos).

Construção de modelos de mineração de agrupamento de lojas

Depois que a tabela relacional de origem é construída, prosseguimos até a etapa da construção do modelo de mineração de agrupamento de lojas com o Microsoft Visual Studio® 2005. Ela se inicia com a criação de um projeto do Analysis Services no Visual Studio 2005, e a criação de um objeto de fonte de dados que se conecta à instância do SQL Server que contém o conjunto de dados de agrupamento de lojas. Uma exibição da fonte de dados também precisa ser criada. Essa exibição da fonte de dados seleciona apenas a tabela única que contenha as propriedades e atributos agregados no nível da loja. Consulte a Figura 1.

Figura 1: Exibição de fonte de dados de agrupamento de lojas

Depois que a exibição da fonte de dados é incluída, um novo modelo e estrutura de mineração para o exercício de agrupamento de lojas são criados. A estrutura de mineração define a estrutura de colunas que será usada para construir o modelo de agrupamento de lojas. Todos os atributos são selecionados como atributos de entrada exceto os atributos Cat Fraction Sales e Cat Total Sales Qty. Esses são selecionados como Predict (de entrada e previsíveis). Consulte a Figura 2.

Figura 2: Estrutura de mineração de agrupamento de lojas

O parâmetro CLUSTER_COUNT associado ao algoritmo do Microsoft Clustering especifica o número máximo de agrupamentos a pesquisar nos dados de origem. Por padrão, o valor é 10. Com o objetivo de produzir agrupamentos distintos que capturem suficientemente as correlações nas propriedades da loja e nos valores de vendas/estoque agregados, o valor de CLUSTER_COUNT foi alterado para 5 com base na experiência e avaliação da qualidade do(s) modelo(s) de agrupamento encontrados em 5 agrupamentos. Geralmente, os analistas precisarão alterar o parâmetro CLUSTER_COUNT para obter os resultados desejados. Neste aplicativo, descobrimos que agrupamentos de lojas distintos (com respeito à similaridade nas vendas agregadas) foram encontrados quando usamos CLUSTER_COUNT = 5. Além disso, as evidências sugerem que modelos de agrupamentos de melhor qualidade são obtidos nessa aplicação quando usado MINIMUM_SUPPORT = 50. Isso instrui o algoritmo do Microsoft Clustering a identificar somente aqueles agrupamentos que contêm 50 ou mais casos (lojas nesse aplicativo). De forma similar, MINIMUM_SUPPORT seria também alterado por uma analista para obter a qualidade de agrupamento desejada. Consulte a Figura 3.

Figura 3: Parâmetros do algoritmo do Microsoft Clustering

Depois de definir os parâmetros do algoritmo do Microsoft Clustering, a estrutura de mineração é processada, assim criando e preenchendo o objeto do modelo de mineração do SQL Server 2005 Analysis Services.

Avaliação do modelo de agrupamento de lojas

Depois que os modelos de agrupamento de lojas foram construídos, eles são avaliados usando o Microsoft SQL Server 2005 Analysis Server Cluster Browser para determinar se os agrupamentos realmente são distinguidos por padrões de vendas de categoria.

Para ver um resumo dos agrupamentos de loja encontrados pelo SQL Server 2005 Analysis Services, consulte a Figura 4. Os agrupamentos de loja tendem a ser discriminados por valores de Vendas totais, Quantidades de vendas da categoria, Vendas semanais da categoria, Disponibilidade semanal da categoria e Sob encomenda. A Figure 4 mostra, para cada agrupamento, os valores da cidade/estado de exemplo para as lojas que pertencem a um determinado agrupamento (coluna esquerda na Figura 4) e os fatores de discriminação para cada agrupamento (coluna direita na Figura 4).

Figura 4: Agrupamentos de lojas para a categoria Chapter Book

Observe que os pares de características de discriminação (atributo/valor) podem ser determinados usando a guia Discrimination no SQL Server 2005 Analysis Services Cluster Model Viewer (consulte a Figura 5).

Figura 5: Exibição da discriminação do modelo de agrupamento

Fase II: Modelagem de previsão de indisponibilidade de estoque

Agora que os modelos de agrupamentos de loja que agrupam lojas que têm padrões de vendas de categoria similares foram construídos, nos concentraremos no problema de prever se um determinado livro ficará fora de estoque dentro de uma semana e dentro de duas semanas. Antes de construir os modelos de mineração para fazer as previsões de indisponibilidade de estoque, construímos os conjuntos de dados de modelagem de cada produto (livro) considerado.

Construção de conjunto de dados de modelagem de previsão de indisponibilidade de estoque

Os conjuntos de dados usados para a tarefa de modelo de previsão de indisponibilidade de estoque leva em consideração as vendas semanais de um determinado livro em todas as lojas da cadeia de varejo. Com base na experiência e na quantidade de dados históricos disponíveis, desenvolvemos uma estratégia de janela deslizante para criar o conjunto de dados usado para a modelagem de previsão. A estratégia de janela deslizante geralmente é uma estratégia de preparação de dados adequados quando os dados têm uma natureza temporal (por exemplo, quando são feitas previsões para o futuro) e o tipo de quantidade previsível é discreta (como indicadores booleanos de indisponibilidade de estoque ou caixas de vendas). Se houver dados temporais suficientes e a quantidade previsível for inerentemente numérica, a modelagem de série temporal pode ser uma estratégia mais adequada.

Aos explorar os dados e nos concentrarmos no contexto do problema, fizemos as seguintes observações. Num período semanal, o histórico de venda e os dados de estoque de um determinado livro e determinada loja produziu 52 registros (um ano de registros de dados). Geralmente, há poucos eventos de indisponibilidade de estoque que ocorram em uma única loja e em um só produto. Para obter modelos de previsão precisos, os dados de treinamento precisam incluir um número suficiente de eventos de indisponibilidade de estoque e eventos de disponibilidade de estoque para identificar tendências que diferenciam os dois. A estratégia de preparação de dados seguinte pretendia alcançar um número suficiente de eventos de indisponibilidade de estoque e eventos de disponibilidade de estoque considerando um determinado produto em toda a cadeia de lojas. Incluímos a etiqueta do agrupamento de lojas (derivado do modelo de agrupamento de lojas) para permitir que os algoritmos de modelagem de previsão identifiquem tendências no comportamento da indisponibilidade de estoque que talvez possam ser diferentes entre os diferentes agrupamentos de lojas.

Construção de conjunto de dados de modelagem de previsão de indisponibilidade de estoque de um determinado produto (livro) p

Para cada loja s na cadeia de varejo:

Para cada semana entre 1º de janeiro de 2004 e 31 de Dezembro de 2004:

Um identicador de loja/semana único é gerado. Ele será a chave para o conjunto de dados de modelagem de indisponibilidade de estoque.
A etiqueta de agrupamento de lojas a que a loja s pertence, conforme determinado pelo(s) modelo(s) de agrupamento de lojas descrito(s) na Fase I: Agrupamento de lojas.
As vendas de produto (livro) p na loja s na semana atual (CurrentWeekSales).
A quantidade disponível do produto (livro) p na loja s na semana atual (CurrentWeekOnHand).
A quantidade encomendada do produto (livro) p na loja s na semana atual (CurrentWeekOnOrder).
As vendas do produto (livro) p na loja s na semana seguinte à semana atual (OneWeekAheadSales).
As vendas do produto (livro) p na loja s na segunda semana posterior à semana atual (TwoWeeksAheadSales).
As vendas do produto (livro) p na loja s na semana anterior à semana atual (OneWeekBackSales).
As vendas do produto (livro) p na loja s duas semanas antes da semana atual (TwoWeeksBackSales).
As vendas do produto (livro) p na loja s três semanas antes da semana atual (ThreeWeeksBackSales).
As vendas do produto (livro) p na loja s quatro semanas antes da semana atual (FourWeeksBackSales).
As vendas do produto (livro) p na loja s cinco semanas antes da semana atual (FiveWeeksBackSales).
A quantidade disponível do produto (livro) p na loja s na semana seguinte à semana atual (OneWeekAheadOnHand).
A quantidade disponível do produto (livro) p na loja s na segunda semana seguinte à semana atual (TwoWeekAheadOnHand).
A quantidade disponível do produto (livro) p na loja s na semana anterior à semana atual (OneWeekBackOnHand).
A quantidade disponível do produto (livro) p na loja s duas semanas antes da semana atual (TwoWeeksBackOnHand).
A quantidade disponível do produto (livro) p na loja s três semanas antes da semana atual (ThreeWeeksBackOnHand).
A quantidade disponível do produto (livro) p na loja s quatro semanas antes da semana atual (FourWeeksBackOnHand).
A quantidade disponível do produto (livro) p na loja s cinco semanas antes da semana atual (FiveWeeksBackOnHand).
A quantidade encomendada do produto (livro) p na loja s na semana anterior à semana atual (OneWeekBackOnOrder).
A quantidade encomendada do produto (livro) p na loja s duas semanas antes da semana atual (TwoWeeksBackOnOrder).
A quantidade encomendada do produto (livro) p na loja s três semanas antes da semana atual (ThreeWeeksBackOnOrder).
A quantidade encomendada do produto (livro) p na loja s quatro semanas antes da semana atual (FourWeeksBackOnOrder).
A quantidade encomendada do produto (livro) p na loja s cinco semanas antes da semana atual (FiveWeeksBackOnOrder).
A caixa de vendas do produto (livro) p na loja s na semana seguinte à semana atual (OneWeekSalesBin). As caixas de vendas usadas nesse exercício são:
1. Nenhuma
2. 1 a 2
3. 3 ou mais
A caixa de vendas do produto (livro) p na loja s na segunda semana seguinte à semana atual (TwoWeekSalesBin). As caixas de vendas usadas nesse exercício são:
1. Nenhuma
2. 1 a 2
3. 3 ou mais
Um indicador booleano sinaliza se o produto (livro) p ficará ou não fora de estoque dentro de uma semana (OneWeekOOSBoolean).
Um indicador booleano sinaliza se o produto (livro) p ficará ou não fora de estoque dentro de duas semanas (TwoWeekOOSBoolean).
As mudanças nas vendas do produto (livro) p na loja s entre a semana atual e a semana anterior (FirstWeekSalesChange).
As mudanças nas vendas do produto (livro) p na loja s entre a semana anterior e duas semanas atrás (SecondWeekSalesChange).
As mudanças nas vendas do produto (livro) p na loja s entre duas semanas atrás e três semanas atrás (ThirdWeekSalesChange).
As mudanças nas vendas do produto (livro) p na loja s entre três semanas atrás e quatro semanas atrás (FourthWeekSalesChange).
As mudanças nas vendas do produto (livro) p na loja s entre quatro semanas atrás e cinco semanas atrás (FifthWeekSalesChange).

Essa é uma longa lista de atributos. Em situações de mineração de dados normais, é comum ter centenas e até milhares ou mais atributos descrevendo a entidade a ser modelada. Os algoritmos de mineração de dados tentarão identificar as correlações pertinentes para fazer previsões precisas. Uma vez que as correlações pertinentes não são conhecidas a priori, é comum incluir todos os atributos possíveis no conjunto de dados de treinamento. Por exemplo, na previsão do indicador booleano que sinaliza a indisponibilidade de estoque em duas semanas, os seguintes atributos foram úteis (consulte a Figura 13).

Current Week On Hand
Four Weeks Back On Hand
One Week Back Sales
Current Week Sales
Cluster Label (do modelo de agrupamento de lojas)
Four Weeks Back Sales
Four Weeks Back On Hand
Four Weeks Back Sales

Mas, antes da modelagem, foi impossível saber se esses atributos seriam relevantes.

Observe que há uma linha nessa tabela de treinamento para cada par de loja/semana. Observe também que os atributos FirstWeekSalesChange, SecondWeekSalesChange, …, FifthWeekSalesChange ajudam a aproximar o primeiro derivativo (mudança) em vendas semanais durante a semana. Geralmente, esses tipos de atributos podem ser muito úteis para aumentar a precisão de previsão de um modelo.

Para avaliar de forma mais objetiva a precisão de previsão dos modelos construídos usando o Server 2005 Analysis Services, é uma prática comum oferecer um subconjunto de dados e chamá-lo conjunto de teste. O restante do conjunto de dados é chamado conjunto de dados de treinamento. Os modelos de mineração de dados são construídos usando o conjunto de dados de treinamento. As previsões do modelo são então comparadas com os valores reais durante o conjunto de teste.

Para os dados do conjunto de teste de treinamento desse aplicativo, usamos todos os registros do conjunto de dados que correspondam às semanas entre 1º de janeiro de 2004 e 30 de novembro de 2004. Para o conjunto de teste, usamos todos os registros do conjunto de dados que correspondem às semanas entre 1º dezembro de 2004 e 31 de dezembro de 2004.

O conjunto de dados de treinamento correspondente a um produto determinado (livro) p consistiu em 10.635 linhas. (Observe que há uma linha para cada par de loja/semana durante as semanas entre 1º de janeiro de 2004 e 30 de novembro de 2004.) Além da coluna do identificador (chave) de loja/semana, o conjunto de dados de treinamento consiste em 38 colunas. Outras colunas (como Store_ID e Week_ID) também são incluídas no conjunto de dados, mas não são usadas para modelagem.

O conjunto de dados de teste correspondente a um produto determinado (livro) p consistiu em 2.442 linhas. (Observe que há uma linha para cada par de loja/semana durante as semanas entre 1º de dezembro de 2004 e 31 de dezembro de 2004.) Houve também 38 colunas além do identificador (chave) único de loja/semana no conjunto de dados de teste.

Construção do modelo de mineração de indisponibilidade de estoque

Depois que as tabelas relacionais de origem foram construídas, os modelos de mineração de dados de previsão foram construídos com o Visual Studio 2005. Para conseguir isso, primeiro são criados um projeto do Analysis Service e uma fonte de dados que especifiquem a instância do SQL Server que armazena o treinamento e as tabelas de teste dos produtos (livros) considerados. Uma exibição da fonte de dados que seleciona as tabelas de interesse é criada. Consulte a Figura 6.

Figura 6: Exibição de fonte de dados de modelo de previsão de indisponibilidade de estoque

Depois que a exibição de fonte de dados é adicionada, uma nova estrutura de mineração é criada para o exercício de modelagem de previsão de indisponibilidade de estoque. As vendas semanais atuais, o histórico de vendas semanais, os atributos disponível e encomendado são especificados como dados de entrada. Os indicadores booleanos de indisponibilidade de estoque e os atributos semanais de caixa de vendas (OneWeekOOSBoolean, TwoWeekOOSBoolean, OneWeekSalesBin, TwoWeekSalesBin) são especificados como atributos previsíveis (Predict Only).

Os modelos do Microsoft Decision Trees e do Microsoft Neural Network são construídos para determinar quais algoritmos produzem os modelos mais precisos (como medido pelas previsões comparativas que os valores reais por todo o conjunto de teste). Depois que uma estrutura de mineração inicial e o modelo de mineração é construído (especificando os atributos previsíveis e de entrada), o analista pode acrescentar facilmente outros modelos de mineração. (Você pode tentar algoritmos diferentes usando o recurso Add Mining Model.) Observe que na Figura 7, Input indica que o valor de atributo será usado como entrada num modelo de previsão. PredictOnly indica que esses valores deveriam ser previstos pelo modelo de mineração de dados. Key indica a coluna que identifica de forma única os casos de interesse. O analista pode também definir um atributo para ser do tipo Predict. Esse tipo de atributo indica que o atributo é usado tanto como um atributo previsível e de entrada. (Ele é considerado um atributo de entrada quando é usado para prever o valor de outro atributo.)

Figura 7: Estrutura de mineração de indisponibilidade de estoque com os modelos do Microsoft Decision Trees e do Neural Network

Descobrimos que modelos de previsão altamente precisos foram obtidos usando o algoritmo do Microsoft Decision Trees quando alteramos os valores padrão de COMPLEXITY_PENALTY e MINIMUM_SUPPORT. Usamos COMPLEXITY_PENALTY = 0.10. Isso pode resultar em uma maior (mais detalhada) árvore de decisão. Uma árvore de decisão maior, mais detalhada, pode modelar de forma mais precisa os dados de treinamento, chegando ao ponto de modelar "ruído" nos dados de treinamento. Essa situação é chamada overfitting e geralmente resulta em previsões ruins em um conjunto de dados de teste ou de hold-out. Além disso, uma árvore de decisão maior, mais detalhada, pode exigir um pouco mais de computação para fazer previsões. O valor de MINIMUM_SUPPORT foi também baixado para 5 – o que pode também resultar em uma árvore de decisão maior. A Figura 9 mostra essas mudanças.

Figura 8: Parâmetros do algoritmo do Microsoft Decision Trees

Resultados de modelagens de previsão

Resultados empíricos

Como mencionado anteriormente, a precisão da previsão dos modelos de mineração foi avaliada pelo exame deles no conjunto de testes (dados correspondentes às semanas entre 1º de dezembro de 2004 e 31 de dezembro de 2004).

Avaliamos o modelo de mineração usando o recurso lift chart no SQL Server 2005 Analysis Services. O lift chart fornece uma imagem geral do desempenho da previsão de um modelo de mineração de dados determinado, durante um conjunto de dados especificado. Nesse caso, usamos o conjunto de dados de teste para essa avaliação. O lift chart compara o desempenho de previsão do modelo de mineração com um modelo ideal e um modelo aleatório. A Figura 9 mostra o lift chart das previsões booleanas de indisponibilidade de estoque para duas semanas do livro Captain Underpants. A tarefa é prever o valor verdadeiro/falso conforme o livro esteja em estoque ou fora de estoque dentro de duas semanas em qualquer loja da cadeia varejista. Observe que a precisão da previsão geral desse modelo é próxima ao modelo ideal.

Figura 9: Lift chart para duas semanas de previsões boolenas de indisponibilidade de estoque

A Figura 10 resume o desempenho de previsão para as combinações de loja/semana quando o livro esteve realmente fora de estoque dentro de duas semanas.

Figura 10: Quadro de ganhos cumulativos – O desempenho ao reconhecer as combinações de loja/semana quando o produto esteve fora de estoque dentro duas semanas

A Figura 11 mostra a representação gráfica do algoritmo do Microsoft Decision Trees prevendo os valores booleanos da indisponibilidade de estoque para duas semanas.

Figura 11: Árvore de decisão OOS de duas semanas para Captain Underpants

A Figura 12 resume a precisão de previsão para todos os cinco produtos (livros) que foram considerados nessa tarefa. Em média, os modelos de mineração de dados obtidos pelo SQL Server 2005 Analysis Services podem prever se um livro ficará ou não fora de estoque dentro de uma semana com uma precisão de 98,52%. As previsões de indisponibilidade de estoque dentro de duas semanas têm previsão, em média, de 86,45%. As precisões de previsão aumentam quando são previstos os valores de caixa de vendas reais.

Figura 12: Precisões de previsão de indisponibilidade de estoque para cinco produtos (livros)

Oportunidade de vendas

As estimativas conservadoras com base nos modelos de previsão indicam que as oportunidades de venda perdida resultaram entre US$ 3.405,48 e US$ 6,810.95 para um ou dois exemplares de livro respectivamente. Essas oportunidades de venda não teriam sido perdidas se os modelos tivessem sido implantados no início do ano. Consulte a Figura 13.

Figura 13: Oportunidade de vendas

O método de calculo das oportunidades de vendas perdidas de cada item foi computado multiplicando-se o número total de semanas de indisponibilidade de estoque da loja pelo valor previsto booleano para as duas semanas. Isso geraria as novas ocorrências de semanas de OOS de loja se os modelos tivessem sido implantados. Multiplicar os valores previstos de OOS pela porcentagem de vendas de livros real do ano pelo respectivo preço de venda no varejo gera o total de oportunidade de vendas.

Fórmula de oportunidade de vendas

(# of total OOS weeks for all stores) x (2-week Boolean predicted accuracy)X (% of actual sales across all stores) x (retail price)= Yearly increase in sales opportunity using Apollo OOS predictions

Se você extrapolar esses números para o total de linhas de varejo, a oportunidade de vendas se torna extremamente atraente. Nela existe o potencial para aumentar as vendas em milhões de dólares se os modelos de previsão de estoque forem implementados.

Automação das previsões de estoque

O recurso de mineração de dados foram incluídos no SQL Server 2005 Integration Services. Assim, o Integration Services pode ser usado para automatizar o processo de fazer previsões semanais ou mensais de indisponibilidade de estoque. Essas previsões fornecem ao varejista os relatórios atualizados sobre as combinações de loja/produto prováveis de experimentar uma situação de indisponibilidade de estoque.

A Apollo Data Technologies recomenda automatizar não apenas o processo de obter previsões de indisponibilidade de estoque de uma forma regular, mas também automatizar o processo de avaliação do desempenho dos modelos de previsão. A última tarefa pode então ser usada para determinar se a precisão de previsão dos modelos de mineração de dados treinados caiu abaixo do nível aceitável. Se os modelos treinados de previsão de indisponibilidade de estoque caem abaixo de uma precisão de previsão prescrita, é provável que as tendências e os padrões extraídos pelos modelos de mineração de dados de SQL Server 2005 tenham mudado. Nesse caso, novos modelos necessitarão ser construídos e ajustados.

Automação de previsões de indisponibilidade de estoque

Os modelos de previsão de indisponibilidade de estoque permitem que o varejista tenha mais controle sobre as situações de indisponibilidade de estoque possíveis dentro de uma e duas semanas. A estrutura comum para a implantação de uma tecnologia de previsão de indisponibilidade de estoque exige a atualização de previsões de indisponibilidade de estoque de forma recorrente semanal ou mensal.

O processo de produzir as combinações de produto/loja que possam provavelmente experimentar uma situação de indisponibilidade de estoque pode ser implementado pelo uso do SQL Server 2005 Integration Services. Isso pode ser feito inplementando e agendando o seguinte fluxo de trabalho.

Produzindo combinações de loja/produto fora de estoque prováveis
Para cada produto p de interesse:

Determine a categoria c(p) à qual o produto p pertence consultando as informações de dimensão do Produto no armazém de dados.
Determine o nome do modelo de agrupamento de lojas que agrupa as lojas de varejo por vendas de categoria c(p). Isso pode ser feito usando uma consulta a uma tabela de observação.
Se o produto p não tiver sido considerado antes, crie um novo conjunto de dados de modelagem de previsão do produto p conforme descrito na construção do conjunto de dados de modelagem de previsão de indisponibilidade de estoque. Se o produto p já houver sido considerado antes, anexe linhas ao conjunto de dados de modelagem de previsão do produto p. As novas linhas correspondem às novas combinações de loja/semana.
Determine o nome dos modelos de previsão de indisponibilidade de estoque do SQL Server 2005 Analysis Services p. Isso pode ser feito com uma consulta a uma tabela de observação.
Usando uma tarefa do SQL Server Integration Services Prediction Join, execute a junção de previsão para obter e registrar as previsões de indisponibilidade de estoque em uma tabela relacional ou um cubo OLAP. Para obter detalhes sobre a junção de previsão DMX usada para obter previsões de indisponibilidade de estoque, consulte o Apêndice B.

Automatização da precisão de previsão

É importante medir o desempenho dos modelos de previsão de indisponibilidade de estoque ao longo do tempo para garantir que as informações que são usadas para oferecer suporte às decisões de estocagem de varejo estão tão atualizadas e precisas quanto possível. Para fazê-lo, nós implementaríamos um sistema que correlaciona os níveis de estoque reais com aqueles previstos pelos modelos. Se os valores previstos tendem a estar de acordo com os níveis reais, um nível de confiança nos modelos de previsão é obtido.

Novamente, o processo de medição do acordo entre os níveis de venda previstos e valores reais pode ser feito usando o SQL Server 2005 Integration Services. Isso é conseguido comparando os valores de caixas de vendas previstos para as combinações de produto/loja/semana (que são registrados em uma tabela quando se obtém as previsões de indisponibilidades de estoque conforme discutido na Automação das previsões de disponibilidade de estoque) com os níveis de vendas reais quando foram relatados e atualizados no armazém de dados.

Ao agregar o número de vezes que as previsões concordam com os valores de venda reais (caixas de venda), o varejista obtém uma noção da precisão dos modelos de previsão. Se a precisão cai abaixo de um determinado limite, os modelos de previsão de indisponibilidade de estoque e possivelmente os modelos de agrupamento de loja precisam ser reconstruídos e ajustados novamente. A causa das previsões incorretas pode estar relacionada às tendências de vendas recentes em alteração que não tenham sido captadas pelos modelos construídos no passado recente.

Conclusão

Este documento descreve uma abordagem para a criação de modelos de previsão de indisponibilidade de estoque de varejo usando o SQL Server 2005 Analysis Services. Quando aplicados aos dados do Project Real, os modelos produzem previsões muito precisas para o subconjunto de itens considerado. Se os modelos fossem implantados durante um ano inteiro, estimativas conservadoras sugerem que o varejista ganharia milhares de dólares evitando as perdas de oportunidades de venda. Se você extrapolar esses números para toda a linha de produto de varejo, as oportunidades de venda se tornam extremamente atraentes com potencial de aumentar as vendas em milhões de dólares. Este documento também fornece recomendações para automação e implementação de avaliações de precisão e previsão de modelo em um aplicativo de linha de negócios usando o SQL Server 2005 Integration Services.

Para obter mais informações:

https://www.microsoft.com/sql/

Este documento o ajudou? Envie-nos seus comentários. Em uma escala de 1 (fraco) a 5 (excelente), como você classificaria este documento?

Apêndice A: Atributos de agrupamento de lojas

Esta tabela lista os atributos de nível de loja derivados do armazém de dados do Project REAL.

Tabela 1: Atributos de agrupamento de lojas

Nome do atributo
Beg Reader PB Cat Frac Holiday Sales
Beg Reader PB Cat Frac Sales
BG Bestseller510 Cat Frac Holiday Sales
BG Bestseller510 Cat Frac Sales
BGCKBKS Under15 Cat Frac Holiday Sales
BGCKBKS Under15 Cat Frac Sales
BG Reference Cat Frac Holiday Sales
BG Reference Cat Frac Sales
Blank Books Cat Frac Holiday Sales
Blank Books Cat Frac Sales
Board Block Touch Cat Frac Holiday Sales
Board Block Touch Cat Frac Sales
Cat Avg Weekly Modeled
Cat Avg Weekly On Hand
Cat Avg Weekly On Hand
Cat Fraction Holiday Sales
Cat Fraction Sales
Cat Holiday Disc Amt
Cat Holiday Markdown Amt
Cat Holiday Member Disc Amt
Cat Holiday Sales Amt
Cat Holiday Sales Qty
Cat Total Disc Amt
Cat Total Markdown Amt
Cat Total Member Disc Amt
Cat Total Sales Amt
Cat Total Sales Qty
Chapter Books Cat Frac Holiday Sales
Chapter Books Cat Frac Sales
Christian Insp Cat Frac Holiday Sales
Christian Insp Cat Frac Sales
Cidade
Cooking Cat Frac Holiday Sales
Cooking Cat Frac Sales
Current Affairs Cat Frac Holiday Sales
Current Affairs Cat Frac Sales
Family Child Care Cat Frac Holiday Sales
Family Child Care Cat Frac Sales
Fantasy Cat Frac Holiday Sales
Cooking Cat Frac Sales
Fiction Cat Frac Holiday Sales
Fiction Cat Frac Sales
Fiction Literary Cat Frac Holiday Sales
Fiction Literary Cat Frac Sales
Fiction PB Young Readers Cat Frac Holiday Sales
Fiction PB Young Readers Cat Frac Sales
Hist Biog Cat Frac Holiday Sales
Hist Biog Cat Frac Sales
Humor Cat Frac Holiday Sales
Humor Cat Frac Sales
Juv Activity Cat Frac Holiday Sales
Juv Activity Cat Frac Sales
Juv Christmas Cat Frac Holiday Sales
Juv Christmas Cat Frac Sales
Juv Series HC Cat Frac Holiday Sales
Juv Series HC Cat Frac Sales
Juv Series PB Cat Frac Holiday Sales
Juv Series HC Cat Frac Sales
Juv Work Books Cat Frac Holiday Sales
Juv Work Books Cat Frac Sales
Pés lineares
Literature Cat Frac Holiday Sales
Literature Cat Frac Sales
Magazines Cat Frac Holiday Sales
Magazines Cat Frac Sales
Management Cat Frac Holiday Sales
Management Cat Frac Sales
Manga Japanese Comics Cat Frac Holiday Sales
Manga Japanese Comics Cat Frac Sales
Mystery Cat Frac Sales
New Age Cat Frac Holiday Sales
New Age Cat Frac Sales
Newspapers Cat Frac Holiday Sales
Newspapers Cat Frac Sales
Pict Sty Bks HC Cat Frac Holiday Sales
Pict Sty Bks HC Cat Frac Sales
Pict Sty Bks HC Cat Frac Holiday Sales
Pict Sty Bks HC Cat Frac Sales
Pop Rock Cat Frac Holiday Sales
Pop Rock Cat Frac Sales
Romance Cat Frac Holiday Sales
Romance Cat Frac Sales
Science Fiction Cat Frac Holiday Sales
Science Fiction Cat Frac Sales
Self Improvement Cat Frac Holiday Sales
Self Improvement Cat Frac Sales
Single Cards Cat Frac Holiday Sales
Single Cards Cat Frac Sales
Spinner Cat Frac Holiday Sales
Spinner Cat Frac Sales
Pés quadrados
Estado
Techno Thriller Espionage Cat Frac Holiday Sales
Techno Thriller Espionage Cat Frac Sales
Teen Fiction Cat Frac Holiday Sales
Teen Fiction Cat Frac Sales
Total de vendas de natal
Vendas totais
Média modelada do total semanal
Média do total semanal disponível
Média do total semanal encomendado

Apêndice B: Consulta DMX de indisponibilidade de estoque

Eis a seguir a consulta DMX usada para obter as previsões de indisponibilidade de estoque.

SELECT
  t.[Unique_Store_Week_ID],
  [CBCaptainUnderpantsDT].[One Week OOS Boolean],
  PredictProbability([CBCaptainUnderpantsDT].[One Week OOS Boolean]),
  [CBCaptainUnderpantsDT].[One Week Sales Bin],
  PredictProbability([CBCaptainUnderpantsDT].[One Week Sales Bin]),
  [CBCaptainUnderpantsDT].[Two Week OOS Boolean],
  PredictProbability([CBCaptainUnderpantsDT].[Two Week OOS Boolean]),
  [CBCaptainUnderpantsDT].[Two Week Sales Bin],
  PredictProbability([CBCaptainUnderpantsDT].[Two Week Sales Bin])
From
  [CBCaptainUnderpantsDT]
PREDICTION JOIN
  OPENQUERY([ApolloDWSDM],
    'SELECT
      [Unique_Store_Week_ID],
      [ChapterBooksCluster],
      [CurrentWeekSales],
      [CurrentWeekOnHand],
      [CurrentWeekOnOrder],
      [OneWeekBackSales],
      [TwoWeeksBackSales],
      [ThreeWeeksBackSales],
      [FourWeeksBackSales],
      [FiveWeeksBackSales],
      [OneWeekBackOnHand],
      [TwoWeeksBackOnHand],
      [ThreeWeeksBackOnHand],
      [FourWeeksBackOnHand],
      [FiveWeeksBackOnHand],
      [OneWeekBackOnOrder],
      [TwoWeeksBackOnOrder],
      [ThreeWeeksBackOnOrder],
      [FourWeeksBackOnOrder],
      [FiveWeeksBackOnOrder],
      [OneWeekSalesBin],
      [OneWeekOOSBoolean],
      [TwoWeekSalesBin],
      [TwoWeekOOSBoolean],
      [FirstWeekSalesChange],
      [SecondWeekSalesChange],
      [ThirdWeekSalesChange],
      [FourthWeekSalesChange],
      [FifthWeekSalesChange]
    FROM
      [dbo].[CB_CaptainUnderpants_Testing2]
    ') AS t
ON
  [CBCaptainUnderpantsDT].[Chapter Books Cluster] = t.[ChapterBooksCluster] AND
  [CBCaptainUnderpantsDT].[Current Week Sales] = t.[CurrentWeekSales] AND
  [CBCaptainUnderpantsDT].[Current Week On Hand] = t.[CurrentWeekOnHand] AND
  [CBCaptainUnderpantsDT].[Current Week On Order] = t.[CurrentWeekOnOrder] AND
  [CBCaptainUnderpantsDT].[One Week Back Sales] = t.[OneWeekBackSales] AND
  [CBCaptainUnderpantsDT].[Two Weeks Back Sales] = t.[TwoWeeksBackSales] AND
  [CBCaptainUnderpantsDT].[Three Weeks Back Sales] = t.[ThreeWeeksBackSales] AND
  [CBCaptainUnderpantsDT].[Four Weeks Back Sales] = t.[FourWeeksBackSales] AND
  [CBCaptainUnderpantsDT].[Five Weeks Back Sales] = t.[FiveWeeksBackSales] AND
  [CBCaptainUnderpantsDT].[One Week Back On Hand] = t.[OneWeekBackOnHand] AND
  [CBCaptainUnderpantsDT].[Two Weeks Back On Hand] = t.[TwoWeeksBackOnHand] AND
  [CBCaptainUnderpantsDT].[Three Weeks Back On Hand] = t.[ThreeWeeksBackOnHand] AND
  [CBCaptainUnderpantsDT].[Four Weeks Back On Hand] = t.[FourWeeksBackOnHand] AND
  [CBCaptainUnderpantsDT].[Five Weeks Back On Hand] = t.[FiveWeeksBackOnHand] AND
  [CBCaptainUnderpantsDT].[One Week Back On Order] = t.[OneWeekBackOnOrder] AND
  [CBCaptainUnderpantsDT].[Two Weeks Back On Order] = t.[TwoWeeksBackOnOrder] AND
  [CBCaptainUnderpantsDT].[Three Weeks Back On Order] = t.[ThreeWeeksBackOnOrder] AND
  [CBCaptainUnderpantsDT].[Four Weeks Back On Order] = t.[FourWeeksBackOnOrder] AND
  [CBCaptainUnderpantsDT].[Five Weeks Back On Order] = t.[FiveWeeksBackOnOrder] AND
  [CBCaptainUnderpantsDT].[One Week Sales Bin] = t.[OneWeekSalesBin] AND
  [CBCaptainUnderpantsDT].[One Week OOS Boolean] = t.[OneWeekOOSBoolean] AND
  [CBCaptainUnderpantsDT].[Two Week Sales Bin] = t.[TwoWeekSalesBin] AND
  [CBCaptainUnderpantsDT].[Two Week OOS Boolean] = t.[TwoWeekOOSBoolean] AND
  [CBCaptainUnderpantsDT].[First Week Sales Change] = t.[FirstWeekSalesChange] AND
  [CBCaptainUnderpantsDT].[Second Week Sales Change] = t.[SecondWeekSalesChange] AND
  [CBCaptainUnderpantsDT].[Third Week Sales Change] = t.[ThirdWeekSalesChange] AND
  [CBCaptainUnderpantsDT].[Fourth Week Sales Change] = t.[FourthWeekSalesChange] AND
  [CBCaptainUnderpantsDT].[Fifth Week Sales Change] = t.[FifthWeekSalesChange]

Download

Modelagem de previsão de estoque com o Microsoft SQL Server 2005 Analysis Services
672 kb
Arquivo do Microsoft Word