Zoom sur l’algorithme série temporelle

1 Présentation de l’algorithme de série temporelle

L’algorithme de série temporal a évolué de manière significative sous SQL Server 2008.

SQL Server 2005 utilise l’algorithme ARTXP de la recherché de Microsoft.

Cet algorithme est bien connu pour sa pertinence mais peut néanmoins avoir certaines instabilité sur des projection à long termes.

Pour cette raison SQL Server 2008 introduit en complément l’algorithme ARIMA. L’utilisateur doit-il faire un choix entre du long termes ou un algorithme précis sur des projections à court terme ?

Dans un soucis à la fois de pertinence et simplicité, SQL Server 2008 compose avec les deux algorithmes.

Afin de contrôler ce comportement, nous avons trois nouveaux paramètres qui sont:

- FORECAST_METHOD – contrôle quel algorithme est utilisé. La valeur “MIXED” est celle par défaut mais nous pouvons spécifier également ARIMA ou ARTXP.

- PREDICTION_SMOOTHING – contrôle le niveau de composition des deux algorithmes. Une valeur proche de 0favorise ARTXP tandis qu’une valeur proche de 1 favorise plus ARIMA.

- INSTABILITY_SENSITIVITY Si l’algorithme choisit est ARTXP, il est possible de définir des seuils pour lesquelles les données d’entrée de prédictions ne sont pas pris en compte.

1.1 Représentation de données de série temporel

Nous avons deux types de représentation de série temporel qui sont illustrés à travers les deux tableaux ci-dessous :

Représentation dénormalisée

Date	Vente Produit A	Vente Produit B	Vente Produit C
Janvier 2008	10	12	15
Février 2008	12	16	18
Mars 2008	10	12	15

Représentation normalisée

Date	Type produit	Vente
Janvier 2008	Produit A	12
Janvier 2008	Produit B	16
Janvier 2008	Produit C	12
Février 2008	Produit A	12
Février 2008	Produit B	16
Février 2008	Produit C	12

L’avantage de la représentation de type dénormalisé est la visualisation des données.

Cependant si nous souhaitons ajouter un grand nombre de série, il faut ajouter de même les colonnes associées ce qui devient difficilement gérable.

Concernant le modèle normalisé, il est plus souple pour rajouter des séries mais nous ne pouvons pas configurer des paramètres spécifiques pour les valeurs « normalisé ».

Le produit A aura le même paramètre que le produit B…

De plus le DMX utilisait pour faire de la prédiction est plus simple dans le cas de données dénormalisées.

1.2 Règles d’application de la série temporel

Par défaut les données sont censé être complète ; c'est-à-dire que pour chaque série les données doivent être complète.

Pour traiter ce genre de cas, il est nécessaire de définir une règle de substitution des valeurs nulles.

Le paramètre MISSING_VALUE_SUBSTITUTION offre une option pour remplacer les valeurs nulles.

Une deuxième règle pour utiliser l’algorithme de série temporel est de trier les données.

De plus il est intéressant de spécifier des réglages à l’algorithme afin d’augmenter la pertinence des résultats comme de spécifier que le temps est divisé par trimestre,…,

Lorsque nous avons plusieurs séries, SSAS essaye de trouver une relation entre ces dernières.

Nous pouvons contrôler ce comportement à l’aides des paramètres suivants :

- L’option PREDICT_ONLY indique que la donnée doit être prédite mais non corrélée avec les autres séries.

- L’option INPUT spécifie que les données servent en entrée mais ne doivent pas être prédite.

2 Création du modèle

2.1 Présentation

D’une manière générale, les structure de mining crées pour les séries temporels ne sont pas compatibles avec les autre modèles de mining.

L’une des différence de création d’une structure de mining à usage temporel est l’ajout d’un type KEY TIME comme le montre l’exemple ci-dessous.

CREATE MINING STRUCTURE [Wine Sales]

(

     [Month] DATE KEY TIME,

     [Fortified] DOUBLE CONTINUOUS,

     [Dry White] DOUBLE CONTINUOUS,

     [Sweet White] DOUBLE CONTINUOUS,

     [Red] DOUBLE CONTINUOUS,

     [Rose] DOUBLE CONTINUOUS,

     [Sparkling] DOUBLE CONTINUOUS,

     [Average Red] DOUBLE CONTINUOUS,

     [Average White] DOUBLE CONTINUOUS

)

2.2 Modèle de type « normalisé »

Dans un modèle de type « normalisé », la colonne de type séries est ajouté comme clé comme le montre l’exemple ci-dessous :

CREATE MINING STRUCTURE [Wine Sales Interleaved]

(

     [Month] DATE KEY TIME,

     [Series] TEXT KEY,

     [Category] TEXT DISCRETE,

     [Sales] DOUBLE CONTINUOUS

)

La création du modèle de mining dans ce type de modélisation, il faut ajouter un filtre sur les données de la structure pour préciser la série à analyser.

ALTER MINING STRUCTURE [Wine Sales Interleaved]

ADD MINING MODEL [Reds Interleaved]

(

    [Month],

     [Series],

     [Sales] PREDICT

) USING Microsoft_Time_Series

WITH DRILLTHROUGH,

     FILTER([Category] = 'Red')

2.3 Modèle de type « dénormalisé »

Dans le cas de modèle dénormalisé, la construction du modèle de mining est relativement simple puisque cela consiste à appliquer l’attribut PREDICT.

ALTER MINING STRUCTURE [Wine Sales]

ADD MINING MODEL [Reds]

(

    [Month],

     [Fortified] PREDICT,

     [Red] PREDICT,

     [Rose] PREDICT

) USING Microsoft_Time_Series

WITH DRILLTHROUGH

3 Traitement des modèles

3.1 Présentation

Le moyen le plus direct pour alimenter une structure est d’utiliser les instructions de type « INSERT INTO ».

Les données des séries ne doivent pas contenir des valeurs nulles.

Pour traiter ce cas, il faut utiliser le paramètre MISSING_DATA_SUBSTITUTION

3.2 Traitement d’un modèle dénormalisé

Ce cas est le plus simple car il correspond à un mapping 1 :1 entre une source tabulaire et la structure de data mining.

INSERT INTO MINING STRUCTURE [Wine Sales]

( [Month],

 [Fortified], [Red], [Rose], [Average Red],

 [Dry White], [Sweet White], [Sparkling], [Average White])

OPENQUERY ([MaDataSource],

  'SELECT

   Month,

   [Fortified], [Red], [Rose],

      ([Fortified] + [Red] + [Rose]) / 3,

   [Dry White], [Sweet White], [Sparkling],

      ([Dry White] + [Sweet White] + [Sparkling]) / 3

   FROM [Wine Sales]

   ORDER BY [Month]')

 

Nous utilisons la fonction OPENQUERY pour se connecter à la source relationnelle.

3.3 Traitement d’un modèle normalisé

Dans ce cas, il est nécessaire d’effectuer une transformation des données pour alimenter la structure de data mining.

INSERT INTO MINING STRUCTURE [Wine Sales Interleaved]

( [Month], [Series], [Category], [Sales] )

OPENQUERY ([MaDataSource],

  'SELECT * FROM

  (SELECT [Month],

          [Type],

          CASE [Type] WHEN ''Red'' THEN ''Red''

                      WHEN ''Rose'' THEN ''Red''

                      WHEN ''Fortified'' THEN ''Red''

                      ELSE ''White''

          END AS [Category],

         [Sales]

   FROM [Wine Sales2]

   UNION ALL

   SELECT [Month], ''Red Average'' AS [Type], ''Red'' AS [Category], SUM(Sales)/3 AS [Sales]

   FROM [Wine Sales2] t

   WHERE t.[Type] IN (''Red'', ''Fortified'', ''Rose'')

   GROUP BY [Month]

   UNION ALL

   SELECT [Month], ''White Average'' AS [Type], ''White'' AS [Category], SUM(Sales)/3 AS [Sales]

   FROM [Wine Sales2] t

   WHERE t.[Type] IN (''Dry White'', ''Sweet White'', ''Sparkling'')

   GROUP BY [Month]) t

   ORDER BY [Month], [Type] ')

4 Etablir une projection de données

4.1 Cas général

La projection de données s’effectue à l’aide de la fonction  PredictTimeSeries.

Le résultat de notre fonction nous donne deux colonnes qui sont TIME et [NomModel]

4.2 Scénarios de simulation

4.2.1 What-if ?

Que se passerait-il si le mois prochain vis-à-vis de mes ventes globales si j’augmente de 10% le produit A ?

Ce type de cas est géré par la fonction « PREDICTION JOIN ».

SELECT FLATTENED

     PredictTimeSeries([Red], 3, 12, EXTEND_MODEL_CASES)

FROM [Reds]

NATURAL PREDICTION JOIN

(SELECT 1 AS [Month], 4520 AS [Red]

 UNION SELECT 2 AS [Month], 4000 AS [Red]) as t

Dans l’exemple ci-dessus, nous souhaitons faire une projection sur l’année à venir en précisant les ventes pour les deux prochains mois.

Si nous souhaitons fournir les vente pour le premier et le troisième mois, il faut fournir la valeur « null » pour le second mois. (SELECT 2 AS [Month], NULL AS [Red])

4.2.2 Nombre de données en entreé faible

Si le nombre de données en entrée est faible pour évaluer une projection, il est possible d’utiliser la fonction REPLACE_MODEL_CASES pour se baser sur l’historique d’un autre produit.

Dans l’exemple ci-dessous nous utilisons un historique d’un autre produit pour faire une projection de deux ans sachant que nous avons uniquement 6 mois d’historique pour notre nouveau produit.

SELECT FLATTENED

     PredictTimeSeries([Average Red], 24, REPLACE_MODEL_CASES)

FROM [Average Sales]

PREDICTION JOIN

(SELECT 1 AS [ Month], 109 AS [New Varietal]

  UNION SELECT 2 AS [Month], 123 AS [New Varietal]

  UNION SELECT 3 AS [Month], 154 AS [New Varietal]

  UNION SELECT 4 AS [Month], 165 AS [New Varietal]

  UNION SELECT 5 AS [Month], 225 AS [New Varietal]

  UNION SELECT 6 AS [Month], 230 AS [New Varietal]

) AS t

ON [Average Sales].Month = t.Month AND

   [Average Sales].[Average Red] = t.[New Varietal]

  

5 Paramètres

5.1 Drill-Throught

La fonctionnalité de Drill-Throught permet de fournir les données qui ont permis d’établir la projection.

5.2 Paramètres clés

5.2.1 MISSING_VALUE_SUBSTITUTION

Il est obligatoire que les séries de données possèdent toute une valeur. Pourquoi ne pas positionner une valeur pour ce paramètre ?

En fait, la valeur fournie a un impact important sur la prédiction des données.

Nous pouvons spécifier au moteur SSAS quelle valeur prendre si une valeur nulle est rencontrée.

Nous avons le choix parmi ces valeurs :

- Previous,

- Mean,

- Number

Ci-dessous un exemple de paramètre sur un modèle de données

ALTER MINING STRUCTURE [Red With Filter]

ADD MINING MODEL [Reds Before 1990]

(

  Month,

  Red PREDICT

) USING Microsoft_Time_Series (MISSING_VALUE_SUBSTITUTION='Previous')

WITH DRILLTHROUGH,

   FILTER([Month Filter] < '1/1/1990')

5.2.2 PERIODICITY_HINT

PERIODICITY_HINT est le second parametre le plus important. Il faut toujours mettre la périodicité lorsque nous la connaissons.

Le format de la périodicité est du type n[,…] ce qui signifie que nous pouvons spécifier plusieurs période.

Par exemple une période pour des salaires mensuels peut être par trimestre ou par année. Dans ce cas, le format de la période serait 3,12.

5.2.3 HISTORIC_MODEL_COUNT et HISTORIC_MODEL_GAP

La validation de l’algorithme de série temporal s’effectue à l’aide des paramètres HISTORIC_MODEL_COUNT et HISTORIC_MODEL_GAP qui sont affectés à un modèle de data mining.

Le principe de ces paramètres est de créer des sous ensemble de modèle pour valider les données

A travers la copie d’écran ci-dessous, le premier modèle prend en entrée N -3 mois, prédit les 3 derniers et compare avec le réel

Le deuxième modèle prend en entrée les N - 6 mois, prédit les 6 suivant et compare avec le réel

Il faut avoir un niveau de profondeur de données suffisant

Le paramètre HISTORIC_MODEL_COUNT correspond au numéro du sous modèle et le paramètre HISTORIC_MODEL_GAP au nombre de pas de données à tronquer.

Le lien suivant décrit plus en détails la mise en place de ces deux paramètres :

https://www.sqlserverdatamining.com/ssdm/Home/TipsTricks/tabid/61/Default.aspx?id=26