A propos, quelles sont les enjeux du reporting ?

Mettre en forme des données afin de mieux les comprendre et les analyser est un besoin grandissant des entreprises. Dans un premier temps, ce besoin s’est traduit par la conception de rapports dit opérationnels, dont l’objectif était de leur permettre de vérifier le bon fonctionnement de leur activité.

Les enjeux de rentabilité (réduction du TCO, optimisation de la production et des marges…) et de compétitivité devenant de plus en plus importants pour les entreprises, conjugués à l’augmentation exponentielle des volumes de données à analyser et une complexité croissante du SI de l’entreprise a peu à peu fait émerger un nouveau besoin : celui de pouvoir analyser rapidement d’importantes quantités de données et suivre efficacement l’évolution des principaux indicateurs de performance et d’alerte de l’entreprise. Ce fut l’essor de la Business Intelligence (ou Informatique décisionnelle), le reporting analytique était né.

Par ailleurs, la polyvalence pour un outil de reporting est également de mise car il devient aujourd’hui nécessaire de pouvoir consommer de nouvelles sources de données (ex. Feeds Internet, données hébergées dans le Cloud…) ou encore de restituer des données de type complexes (données géospatiales par exemple). Enfin, de nombreuses entreprises ont investi ces dernières années dans la mise en place de portails d’entreprise basés sur SharePoint Server, et souhaitent pouvoir publier et accéder à leurs rapports directement depuis ce portail.

Microsoft a fait son entré dans le marché du Reporting en 2004 en livrant une première version de Reporting Services incluse dans le Service Pack 2 de SQL Server 2000. Les fonctionnalités de reporting opérationnel du produit se sont progressivement enrichies au fil des versions afin de répondre aux besoins croissants de reporting analytique des entreprises, parfois en intégrant des solutions complémentaires acquises auprès d’éditeurs tiers (en particulier la bibliothèque de composants graphiques « Dundas » ou encore la solution de collaboration « 90 Degree »).

La Figure 1 illustre les évolutions successives de Reporting Services depuis son introduction sur le marché en 2004 :

Figure 1

Au mois de mai dernier, Microsoft a mis sur le marché la dernière mouture de son outil Reporting Services qui fait partie intégrante de la suite SQL Server 2008 R2 (qui comprend également, en complément du moteur relationnel de bases de données éponyme, l’ETL Integration Services et le moteur OLAP Analysis Services). Avec cette version de Reporting Services, Microsoft répond parfaitement aux nouveaux besoins de reporting analytique, et pose les bases du reporting self-service et collaboratif. Voyons comment, et passons en revue les principales fonctionnalités de cette nouvelle version…

De nouveaux connecteurs de sources de données

Reporting Services 2008 R2 suit les tendances du marché et propose des nouveaux connecteurs d’accès aux données pour simplifier la création de rapports.

Avec la version 2008, nous avions déjà un connecteur SAP NetWeaver BI couplé à un assistant de création de requête en mode graphique comme le montre la Figure 2 :

Figure 2

La version 2008 R2 nous offre en plus des connecteurs pour les listes Sharepoint, pour l’édition Parallel Data Warehouse (PDW) de SQL Server et pour SQL Azure (la version Cloud de SQL Server). Le tableau ci-dessous liste les connecteurs disponibles dans les versions 2008 et 2008 R2 de SQL Server :

Bien qu’elle n’apparaisse pas explicitement dans la liste des sources de données ci-dessus, il est également possible d’utiliser SQL Server PowerPivot pour SharePoint comme source de données d’un rapport sous Reporting Services 2008 R2 : il suffit pour cela de sélectionner la source de données Analysis Services puis de fournir l’URL de la feuille PowerPivot que vous souhaitez utiliser comme source de données.

De nouvelles représentations graphiques pour une meilleure lisibilité des données

La version 2008 nous avait déjà bien gâtés avec l’ajout de toute une série de graphes comme « l’entonnoir ». La version 2008 R2 apporte également son lot de nouveautés avec les graphes de type Sparklines, Barres de données et Indicateurs (cf. Figure 3 ci-dessous), qui permettent d’améliorer la compréhension des données métier :

Figure 3

·       Les graphes de type Sparkline affichent dans une cellule une représentation linéaire d’une série de chiffres, ce qui permet d’observer en un clin d’œil son évolution dans le temps ;

·       Les graphes de type Barres de données (Data Bars) affichent dans une même cellule un chiffre et une barre d’histogramme horizontale, afin de mettre en relief les pics de valeurs pour la colonne contenant cette représentation ;

·       Enfin, les graphes de type Indicateurs permettent d’illustrer l’évolution des KPI (indicateurs clés de performance) de l’entreprise.

Ces nouveaux graphes rendent les tableaux de bord de plus en plus riches car ils mettent en relief les données de l’entreprise, et seront très utiles pour la réalisation de rapports de type Dashboards (Tableaux de bords) ou Scorecards (Tableaux de scoring).

Reporting Services 2008 R2 introduit également la possibilité de représenter les données sur fond de cartes géographiques. Ce type de représentation peut être utilisé pour combiner des données géospatiales avec des données analytiques afin de pouvoir les analyser de manière intuitive. Il est ainsi possible de représenter les données analytiques sous forme de code de couleurs, des bulles de tailles proportionnelles aux données placées à des points précis sur la carte ou encore des figures géométriques de couleurs, tailles et formes variables. Il est également possible de représenter des routes sous forme de lignes de couleurs et d’épaisseurs variables (par exemple des routes de livraison ou des routes aériennes).

La Figure 4 ci-dessous illustre par exemple les ventes mondiales d’une société par localisation géographique :

Figure 4

Une intégration native avec le service de cartographie en ligne BingMaps est également de la partie, qui permet de disposer d’un fond cartographique pour l’ensemble de la planète :

Figure 5

Quelques fonds de cartes sont livrés avec Reporting Services 2008 R2, mais il est également possible d’utiliser d’autres fonds de cartes au format ESRI (Environmental Systems Research Institute, Inc.) développés par des éditeurs tiers. De nombreux fichiers au format ESRI sont disponibles gratuitement sur le Web, à partir desquels vous pouvez créer vos propres cartes.

Outre les cartes géographiques, il existe également des plans d’étages ou de bâtiments, et il est virtuellement possible de concevoir soi-même n’importe quel type de carte avec Microsoft Office Visio 2010.

Les cartes contiennent différents niveaux, implémentés sous forme de calques (cf. Figure 6) :

o   Les points (utilisés pour représenter les Villes ou les Clients par exemple)

• Les lignes (utilisées pour illustrer les Routes)
• Les polygones (utilisés pour représenter les Etats ou les Pays)
• Les fonds cartographiques (basés sur BingMaps)

Figure 6

Une intégration renforcée avec Microsoft Office Sharepoint 2010

Une fois les rapports développés, comment pouvons-nous les partager ?

Les rapports sont accessibles soit à travers le site d’administration et de consultation Report Manager, soit en les intégrant à une application Web, soit en intégrant l’instance Reporting Services à un portail Microsoft Office Sharepoint. La dernière version de Reporting Services met l’accent sur cette intégration, notamment avec la version 2010 de Sharepoint.

En intégrant Reporting Services à Sharepoint, il n’est pas nécessaire de créer une application spécifique pour diffuser le contenu des rapports. De plus, Sharepoint gère les rapports comme n’importe quel autre type de document, ce qui permet notamment de bénéficier de la gestion des versions et de s’appuyer sur les principes de check-in / check-out pour la publication des nouvelles versions d’un rapport. SharePoint constitue alors un point centralisé d’accès aux rapports, dans la sécurité d’accès (authentification et habilitations) peut être gérée à son niveau.

La configuration de cette intégration a été simplifiée en réunissant l’ensemble des paramètres à préciser sur une seule page (contre trois dans SharePoint 2007) comme le montre la Figure 7 

Figure 7

En termes d’administration, l’utilitaire en ligne de commande RS.EXE permet à présent de piloter une instance Reporting Services intégré à Sharepoint. Il devient ainsi aisé de déployer toute une série de rapports en ligne de commande sur une instance intégrée à SharePoint avec cet outil.

Au chapitre des performances, les appels entre les services Sharepoint et Reporting Services ont été optimisés. SharePoint devient donc un support de taille pour Reporting Services !

Notons également que le moteur de rapport présent dans Reporting Services est également utilisé dans d’autres produits comme Visual Studio, SQL Server Management Studio pour obtenir des métriques sur les bases de données,…

Une productivité accrue dans la conception des rapports.

L’une des évolutions majeures de la version 2008 R2 de Reporting Services est certainement la notion de librairie de composants réutilisables entre rapports.

Le principe est de créer un premier rapport, puis de définir les éléments à publier dans la librairie. Les éléments publiables peuvent être des datasets (requête sur une source de données), des images, des graphes, des gauges, des cartes, des tables, des matrices, des rectangles, des listes et des paramètres.

La Figure 8 montre les étapes de publications des composants d’un rapport :

Figure 8

Cette fonctionnalité permet non seulement de gagner en productivité mais également d’offrir plus d’autonomie aux populations fonctionnelles lors de la conception de rapports surtout avec l’outil « Report Builder  3.0 ».

En effet, avec la notion de composant de type DataSet, les populations fonctionnelles vont pouvoir porter leur attention principalement sur la mise en page du rapport. En cas de mise à jour des composants de la librairie, il est possible d’appliquer cette dernière sur l’ensemble des rapports impactés (notion d’héritage).

La version 3.0 de Report Builder a également subit des évolutions intéressantes, en particulier le mode serveur : ce mode propose de créer un cache par utilisateur des données liées au rapport, ce qui permet d’optimiser la création des rapports.

En conclusion…

Avec Reporting Services 2008 R2, Microsoft démocratise encore un peu plus les usages en matière de Reporting dans l’entreprise, en plaçant entre les mains des utilisateurs finaux un outil à la fois puissant, polyvalent et simple d’emploi, qui leur permet de concevoir et partager aisément des rapports correspondant précisément à leurs besoins.

Ceci permet de réduire considérablement la durée du cycle de vie pour la conception de nouveaux rapports (donc leurs coûts de production) en déchargeant les équipes informatiques de cette tâche, qui peuvent alors se concentrer sur la préparation et la mise à disposition des données.

De son côté, l’utilisateur final se met à son propre service en devenant capable de concevoir lui-même les rapports dont il a besoin : voici venue l’ère du reporting « Self-Service »…

Pour aller plus loin

Intégration de Reporting Services avec Sharepoint :

https://msdn.microsoft.com/en-us/library/bb326213(SQL.105).aspx

Téléchargement de l’outil Report Builder 3.0 :

https://www.microsoft.com/downloads/en/details.aspx?FamilyID=d3173a87-7c0d-40cc-a408-3d1a43ae4e33&displaylang=en

Présentation par Robert Bruckner de la cartographie avec Reporting Services :

https://blogs.msdn.com/b/robertbruckner/archive/2009/08/11/rs-maps-with-spatial-data-and-bing-maps.aspx

Créer ses propres fonds de cartes pour Reporting Services avec Visiso :

https://blog.oraylis.de/2010/07/creating-your-own-ssrs-map-using-visio/

Où trouver des fichiers ESRI de cartes pour SSRS 2008 R2 :

• https://biogeo.berkeley.edu/gadm/
• https://www.maproom.psu.edu/dcw/
• https://www.sharpgis.net/page/SQL-Server-2008-Spatial-Tools.aspx
• https://sqlspatialtools.codeplex.com/
• https://www.census.gov/geo/www/tiger/
• https://data.gov
• https://dcrp.ced.berkeley.edu/
• https://blogs.msdn.com/edkatibah

L’objectif est de pouvoir traduire les données d’affichage à travers des rapports Reporting Services qui ont référence une source de données de type Analysis Services.

Analysis Services fournit une traduction des méta-données en fonction du thread client.

Comme le montre les copie d’écran ci-dessous, SQL Server Management Studio permet de tester la traduction des méta-données définie lors de la conception du cube.

Afin de traduire les membres en plus les méta-données, il est nécessaire de faire pointer la propriété « caption » sur une colonne correspondant à « la locale » comme le montre la copie d’écran ci-dessous.

Choix de la collation

SQL Server fournit des collations aussi bien pour la partie SQL Server qu’Analysis Services.

Cette propriété spécifie les règles de tri et de comparaison des chaînes de données de caractères, selon les normes des différentes langues et options régionales. Par exemple, dans une clause ORDER BY, un francophone s'attend à voir la chaîne de caractères « Chypre » apparaître avant « Cologne » par ordre croissant. Toutefois, un hispanophone natif du Mexique s'attendra à voir les mots commençant par « Ch » apparaître à la fin de la liste des mots commençant par « C ».

Lorsqu'un classement est spécifié pour des données de caractères non-Unicode, par exemple des données de type char, varchar, et text, une page de codes particulière est associée à ce classement.

Cette configuration est importante surtout pour le « process » des dimensions

Le type unicode est conseillé sauf si nous sommes surs que les données insérées n’utiliseront pas de caractères spéciaux.

Préconisation pour le moteur Analysis Services :

Lorsqu’Analysis Services traitera la dimension, l’ordre de la collation définie au niveau de la colonne sera utilisé.

Pour les attributs traduits, il faudra spécifier la propriété Collation dans l’onglet traduction.

Traductions des membres

Afin de pouvoir profiter de la gestion multilingue d’Analysis Services, il est nécessaire de passer la local du client à travers la chaine de connexion comme le montre la copie d’écran ci-dessous.

En personnalisant la chaîne de connexion avec la local du poste utilisateur, les membres des attributs sont automatiquement traduits dans la langue définie à travers le poste client.

Si la langue du client n’est pas reconnue, les membres affichés sont ceux par défaut.

Des rapports en fonction de paramètres comme par exemple une devise peuvent avoir une représentation différente. Deux méthodes s’offrent à nous pour répondre à ce besoin :

1.      La première consiste à fournir la logique de formatage au niveau de Reporting Services,

2.      La deuxième consiste à utiliser les propriétés des cellules Analysis Services

Utilisation d’un paramètre qui pilote le formatage d’un rapport Reporting Services

Les cellules d’un rapport possèdent une propriété « Format » qui peut être évaluée à l’aide d’une expression. Comme le montre la copie d’écran ci-dessous, cette expression peut être construite à l’aide d’un paramètre.

Le résultat de cette méthode est représenté à travers la copie d’écran ci-dessus.

Avantages et inconvénients de cette méthode :

Cette méthode permet de fournir à l’utilisateur le choix de son format d’affichage.

En revanche les règles d’affichage sont portées par le rapport et donc non transportable sur un autre outil de restitution comme Excel.

Formatage à l’aide des propriétés du cube

Etape 1

La première étape consiste à définir les règles de formatage au sein du cube.

La copie d’écran illustre un formatage différent de la mesure Amount en fonction des valeurs des membres de la dimension « Accounts »

Etape 2

Par la suite, la requête MDX associée au DataSet doit contenir la propriété FORMATTED_VALUE qui permet d’extraire les informations de formatage définie au sein du cube.

Etape 3

La propriété de formatage est utilisée au sein du rapport à l’aide de l’expression suivante

=Fields!MyValue.FormattedValue

La figue ci-dessous montre bien que les règles de formatage sont différentes en fonction des membres affichés.

Avantages et inconvénients de cette méthode :

Cette méthode permet de centraliser les règles de formatage et donc de les partager avec plusieurs outils clients.

De plus, la navigation au sein des rapports est simplifiée car il n’y a pas besoin de rajouter un paramètre d’affichage.

En revanche l’utilisateur ne contrôle plus le formatage.

Nous préconisons cette solution.

La gestion de conversion des devises est un besoin récurrent dans l’analyse de données.

Plusieurs approches permettent de traiter ce besoin au niveau d’Analysis Services.

Hypothèses

-        Nous présenterons dans cet article le fait d’entrer des données dans la table de fait dans plusieurs devises et de pouvoir convertir les données dans plusieurs devises.

-        Nous utiliserons une table de conversion qui sera basé sur une devise pivot qui est l’Euro dans notre cas. L’avantage d’utiliser une table de conversion est de pouvoir convertir les données après le processus de chargement des données et également de modifier les valeurs des taux de conversion.

-        Une vue « ViewFactInternetSales » s’appuiera sur la table de faits « FactInternetSales » et la table de conversion pour convertir l’ensemble des données dans la devise cible qui est l’Euro. Le groupe de mesure du cube sera construit à partir de cette vue.

-        De plus, nous construisons une vue « ViewFactCurrentRate » qui enregistre les taux de conversion de l’Euro, notre devise cible vers les autres devises avec la mesure « EndOfDayRate ». Cette devise est liée à la dimension temps. De plus cette vue ventile le dernier taux de conversion sur les périodes antérieures avec la mesure « LastEndofDayRate »

Le schéma ci-dessous illustre la modélisation des tables et vues mise en relation.

Modélisation du cube

Les propriétés suivantes ont été définies pour la dimension devise « DimCurrency » :

-        Le type de la dimension est « Currency »,

-        La propriété « IsAggregatable » de l’attribut Currency est à « false »,

-        Le membre par défaut est « Euro » de tel sorte que si nous naviguons dans le cube sans positionner sur la dimension « DimCurrency », les données sont automatiquement filtrées par ce membre.

Création d’une mesure qui s’adapte à la devise sélectionné

En utilisant la propriété « MeasureExpression », nous définissons la mesure en devise locale, la mesure en Euro multiplié par le taux de conversion qui permet d’obtenir les autres devises.

Comme le montre la copie d’écran ci-dessous, le taux de conversion « End of Day Rate » est une mesure semi-additive.

La relation entre la dimension devise et FactInternetSales se fait par le biais d’une relation « many to many »

Enfin la dernière étape consiste à utiliser la propriété « Direct Slice » sur le membre de la devise pivot, qui est l’Euro dans notre cas. Cette propriété permet d’éviter d’appliquer la conversion lorsque la devise affichée est Euro.

C'est un besoin fréquemment soulevé.

Deux solutions simples peuvent être mise ne place :

·        La première consiste à appeler l'utilitaire DTEXEC depuis une procédure stockée qui exécute la commande XP_cmdShell. Pour exécuter cette commande, il est nécessaire de l'activer à travers la procédure stockée système sp_configure. Il faut valider que la procédure " XP_cmdShell" puisse être activée au sein de l’environnement de production. Le lien suivant https://msdn.microsoft.com/fr-fr/library/ms162810(SQL.90).aspx illustre un appel de SSIS avec cette méthode.

·        La deuxième consiste à encapsuler l'appel du package à travers un job, lui-même invoqué à travers la procédure sp_startjob. Cette méthode ne permet pas le passage de paramètre.

La première méthode est plus souple surtout pour le passage de paramètre d’exécution du package.

Contraintes

Cependant, pour invoquer SSIS, il faut que SQL Server et SSIS soit sur la même machine. En effet il n’est pas possible de manière simple d’invoquer un process SSIS distant depuis SQL Server.

Nous présenterons donc dans ce cas, l’invocation de SSIS à l’aide de la procédure XP_cmdShell

Fonctionnement de la commande XP_CmdShell

Afin d’activer cette commande, il est nécessaire deNous présenterons donc dans ce cas, l’invocation de SSIS à l’aide de la procédure XP_cmdShell

Etape 1 : Activation de la commande XP_cmdShell

EXEC sp_configure 'show advanced options', 1

GO

RECONFIGURE

GO

EXEC sp_configure 'xp_cmdshell', 1

GO

RECONFIGURE

GO

Par défaut, pour exécuter la commande XP_CmdShell, il faut être sysadmin sur le serveur SQL Server.

Cependant donner des droits sysadmin à un compte applicatif n’est pas une bonne pratique en termes de configuration de sécurité.

Afin d’éviter d’utiliser ce scénario, un compte de proxy dédié à la commande XP_CmdShell peut être crée. Ce compte correspond à un utilisateur de domaine ou local à la machine.

Par la suite, l’invocation de XP_CmdShell sera réalisée avec le contexte d’exécution

La figure ci-dessous illustre ce mécanisme :

Dans un second temps, il est important d’affecter les bons droits au compte de proxy par rapport aux actions réalisées au niveau du package SSIS (droit en base de données, sur le système de fichiers,…)

Etape 2 : Création d’un compte de proxy

La commande suivante permet d’enregistrer un compte de proxy :

execute sp_xp_cmdshell_proxy_account 'MyDomain\ProxyAccount' , 'Mypassword1'

Il faut bien entendu que le Windows « MyDomain\ProxyAccount » soit crée sur la machine auparavant.

Etape 3 : Affectation des droits d’exécution de la procédure xp_cmdshell

L’utilisateur (Login SQL) doit être enregistré dans la base master. Par la suite, il est possible de donner des droits sur la procédure stockée xp_cmdshell à notre utilisateur applicatif.

Ci-dessous un exemple de script qui autorise l’utilisateur applicatif à exécuter la procédure xp_cmdshell

use master

GRANT EXECUTE on xp_cmdshell to MyApplicationUser

Etape 3 : Execution du package

L’utilisateur applicatif peut par la suite exécuter le package SSIS à l’aide de l’instruction SQL suivante :

DECLARE @returncode int

EXEC @returncode = xp_cmdshell 'dtexec /f "C:\ ProxyAccountTest\ProxyAccountTest\Package.dtsx"'

GO

Le proActive caching répond à un besoin d’avoir du temps réel sur le rafraichissement des données d’un cube.

Fonctionnement du ProActive Caching

La figure ci-dessous décrit l’enchainement des étapes du proActive Caching

1.      La première étape est une interrogation d’une application cliente du serveur Analysis Services sous forme de requête MDX

2.      Le serveur Analysis Services interroge son cache pour obtenir les informations

3.      Une modification est effectuée sur la source de données relationnelle et notifie Analysis Services.

4.       En retour Analysis Services envoie deux messages au serveur relationnelle dans un intervalle de temps définit pour évaluer si la base est toujours en cours de modification. L’idée est d’éviter de minimiser la construction de cache, surtout sur des traitements en lot.

5.      Analysis Services commence à construire un nouveau cache pour remplacer le cache « périmé ».

6.      Pendant la reconstruction, les requêtes des clients sont traitées avec le mode ROLAP

7.      Une fois que le nouveau cache est construit, ce dernier est activé et l’ancien est supprimé.

Si pendant la phase de reconstruction, l’accès aux données en mode ROLAP s’avère trop long, il est possible d’utiliser le paramètre spécial -1 de telle sorte à continuer à utiliser l’ancien cache jusqu’à que le nouveau soit prêt.

Mise en place du ProActive caching

Le proactive caching peut être configuré pour les dimensions et les partitions.

1.      La première étape est de se positionner au niveau de la partition, puis de cliquer sur storage Setting

2.      Par la suite cocher l’option Enable Proactive caching

Présentation des options du proactive caching

Ce tableau montre qu’il y a un compromis à évaluer entre les temps de réponse des utilisateurs versus la dernière version des données.

Si les performances sont primordiales, il faut forcer Analysis Services à ne pas basculer en mode ROLAP ; pour cela, utiliser les options identiques à la copie d’écran ci-dessus.

Notification de modification de la source relationnelle

Trois options s’offrent à nous afin qu’Analysis Services soit notifié des modifications.

Ces options sont décrites à travers la copie d’écran ci-dessous

               La première option s’appuie sur le mécanisme de trace de SQL Server et ne peut être utilisé uniquement si la source de données est SQL Server. Avec cette option la partition de donnée est traitée en mode complet. Le mode « ajout » n’est pas supporté.

               La deuxième option est d’envoyer au serveur Analysis Services une commande XMLA

L’inconvénient typique de cette méthode est lorsque le serveur Analysis Services est éteint. L’application cliente doit donc pouvoir conserver sous forme de liste d’attente les messages de modification.

La troisième option est d’interroger la base de données à un intervalle de temps régulier.

Cette méthode est valable à condition que la table suivie possède une colonne qui identifie les modifications comme une date par exemple

Par default, Analysis Services interroge la base de données toutes les 10 secondes

Recommandations générales

Tous les objets qui ont les mêmes paramètres de proActive caching sont regroupés dans un même lot de traitement. Dans un lot, les dimensions sont toujours traitées en premier et les partitions dans un second temps.

Il est donc une bonne pratique de

1. spécifier des paramètres identiques aux objets dépendants,

2. Activer l’option « enable incremental update » afin d’enrichir le cache avec juste les nouvelles données,

3. Minimiser le nombre d’objets sur lesquelles le proActiveCaching est activé sachant que cette fonctionnalité est consommateur de ressource

4. Partitionner les données et activer cette fonctionnalité uniquement sur la partition de données active ]]> https://docs.microsoft.com/archive/blogs/lbanon/bonnes-pratiques-sur-la-dimension-temps Sat, 09 Jan 2010 09:10:15 GMT https://blogs.msdn.microsoft.com/lbanon/2010/01/09/bonnes-pratiques-sur-la-dimension-temps/  

J’ai publié récemment un post qui décrit la création d’une dimension temps.

Je vous propose de passer à présent en revue quelques bonnes pratiques de la dimension temps.

Il est important d’avoir des dimensions temps complètes, même si il n’y a pas de mesures pour ces valeurs de dates.

En effet, certaines fonctions MDX comme la fonction ParallelPeriod() retourne des positions relatives.

Ainsi si on souhaite comparer des valeurs au niveau mois par rapport à l’année N-1, si l’année n’est pas complète les calculs risquent d’être faux.

Ainsi dans l’exemple ci-dessous, la position 1 pour le niveau mois dans l’année 2001 est le mois de juillet, tandis que c’est bien le mois de janvier pour l’année 2002.

Il est une bonne pratique de créer une table pour une dimension temps.

Ainsi, il est possible d’enrichir cette dernière avec des données spécifiques au contexte de l’entité.

Cette démarche permet de répondre aux questions suivantes :

- Est-ce un jour de congés spécifique à l’entreprise ?,

- Sommes-nous en saison-hors saison ?

Si l’application doit restituer des données à un niveau plus fin que le jour, il est pertinent d’avoir deux dimensions, une au niveau du jour et une au niveau des horaires.

Par exemple, si nous traçons temps avec une hiérarchie utilisateur suivante

Year à Quarter à Month à Week à Day à Hour à Minute.

Pour cinq ans d’historique, nous aurions 2675,795 membres.

Il est préférable de créer deux dimensions avec les hiérarchies suivantes :

Time: Year à Quarter à Month à Week à Day

Time of Day: Period à Hour à Minute
(Les valeurs prises pour la période peuevent être Hors heure de travail, matin, après-midi,…)

Décrivons le code qui permet de créer et d’alimenter une table de dimension au niveau horaire, DimTime

drop table DimTime

GO

create table DimTime

([TimeKey] [int] identity NOT NULL,

[HourNumber] [tinyint] NOT NULL,

[MinNumber] [tinyint] NOT NULL,

[SecondNumber] [tinyint] NOT NULL,

[Periode] nvarchar(255) NULL,

CONSTRAINT [PK_DimTime_TimeKey] PRIMARY KEY CLUSTERED

(

[TimeKey] ASC

))

GO

create procedure FillDimTime

as

--truncate table dbo.DimTime

set nocount on

declare @Hour int;

declare @Min int;

declare @sec int;

declare @MaxHour int;

declare @MaxMin int;

declare @Maxsec int;

set @Hour = 0;

set @Min = 0;

set @sec = 0;

set @MaxHour = 23;

set @MaxMin = 59;

set @Maxsec = 59;

while @Hour <= @MaxHour --boucle sur les Heures

begin

while @Min <= @MaxMin --boucle sur les min

begin

While @sec <= @Maxsec --boucle sur les secondes

begin

insert into DimTime (HourNumber, MinNumber, SecondNumber) values (@Hour,@Min,@sec);

set @sec = @sec + 1;

end

set @Min = @Min + 1;

set @sec = 0

--insert into DimTime (HourNumber, MinNumber, SecondNumber) values (@Hour,@Min,@sec);

end

set @Hour = @Hour + 1;

set @sec = 0

set @Min = 0

--insert into DimTime (HourNumber, MinNumber, SecondNumber) values (@Hour,@Min,@sec);

end

update DimTime

set Periode = 'AM'

where HourNumber between 0 and 11

update DimTime

set Periode = 'PM'

where HourNumber between 12 and 23

GO

Et voila le résultat

]]> https://docs.microsoft.com/archive/blogs/lbanon/sql-server-analysis-services-2008-quoi-de-neuf-dans-la-boite Sat, 09 Jan 2010 08:32:00 GMT https://blogs.msdn.microsoft.com/lbanon/2010/01/09/sql-server-analysis-services-2008-quoi-de-neuf-dans-la-boite/

Je voulais publier cette article un peu plus tôt,…; il vaut mieux tard que jamais:

Un peu d’historique …

Microsoft est entrée dans le marché du décisionnel avec la version 7 de SQL Server, il y a déjà près de 11 ans. A cette époque, seul des structures de taille importante pouvaient investir dans ce type de technologie. Depuis, le  décisionnel se démocratise dû à des coûts attractifs et des connaissances de mieux en mieux maîtrisées.

SQL Server 2005 est incontestablement un serveur d’analyse d’une grande richesse avec une nouvelle architecture basée sur l’UDM, Unified Dimensional Model, qui intègre à la fois un modèle relationnel et un modèle agrégé.

Cette richesse n’a pas toujours été facile à digérer et les bonnes pratiques laissaient de temps en temps de coté avec des performances pas toujours au rendez-vous. Suite à ce constat, SQL Server Analysis Services 2008 proposent de nouveaux outils afin de guider le concepteur dans la modélisation, la création d’agrégats et la supervision du serveur.

Présentons les nouveautés de ce serveur en matière de conception et exploitation.

Vers une meilleure modélisation

Avant de rentrer dans le cœur du sujet, représentons les concepts et les bonnes pratiques de modélisation des liens entre attributs.

Les relations d’attributs

Tous les attributs sont liés directement ou indirectement à l’attribut clé. En créant des hiérarchies, il est facile de créer des relations redondantes.

Ainsi la relation Customer à City n’est pas redondante, ce qui n’est pas le cas pour la relation suivante Customer à Country qui peut être obtenu indirectement.

Cette redondance a bien sur un impact sur le stockage de la base de données.

De plus les attributs possèdent un type qui peut  être qualifiés de rigide ou de flexible.

Une relation entre attribut est dite rigide si elle n’évolue pas dans le temps comme par exemple, le sexe d’une personne.

Lorsque les types de relation sont flexibles, les agrégats sont automatiquement supprimés lors du traitement de la dimension et doivent être reconstruit à l’aide de l’instruction « process index » contrairement aux relations rigides. Par défaut, le type de relation est flexible.

Ce point est important à prendre en compte lorsque la fenêtre pour traiter le cube est limitée.

Les hiérarchies naturelles

A partir de lien d’attributs, il est possible de définir des hiérarchies naturelles et non naturelles.

Une hiérarchie est dite naturelle lorsqu’une unicité est définie pour chaque parent de la hiérarchie.

Ainsi la hiérarchie Country-State-City-Customer est naturelle tandis que Age-Gender-Customer ne l’est pas. En effet, si nous remontons la hiérarchie, à partir d’un sexe donné, il n’est pas possible de définir le parent ; le seul moyen est de naviguer par l’attribut clé.

D’un point de vue performance, une hiérarchie naturelle est matérialisée alors qu’une hiérarchie non naturelle est calculée à la volée.

Sous SQL Server 2005, il était facile de créer une hiérarchie non naturelle car l’option de la dimension KeyDuplicate était à IgnoreError.

Comment implémenter les bonnes pratiques ?

Le nouvel outil BID 2008, Business Inelligence Developpment, propose une nouvelle interface simplifié afin de guider l’utilisateur dans l’implémentation des bonnes pratiques de conception.

Nous avons vu qu’il est important d’utiliser avec précaution des hiérarchies non naturelles et d’éviter de créer des attributs redondants, ce qui auraient des impacts négatifs sur les performances.

Afin d’avoir une synthèse des relations entre les attributs, BID propose un nouvel onglet, l’attribute relationShip designer.

Ainsi, sous la figure ci-dessous nous pouvons aisément voir à l’aide du message d’avertissement qu’il y a une redondance entre les relations MonthsàCalendar QuarteràCalendar Semester et Monthsà Calendar Semester.

Cette version apporte donc un ensemble de règles de validation de bonnes pratiques. L’utilisateur est donc guidé, ce qui continue à démocratiser la Business Intelligence.

Il est d’ailleurs possible d’accéder et de modifier ces règles de validation et en particuliers de les activer ou désactiver soit au niveau du projet ou alors au niveau d’un élément plus fin comme la dimension.

Vers une meilleure maitrise des outils d’administrations

Les agrégats

Analysis services 2008 permet aux administrateurs et personnes en charge de la maintenance des cubes, de générer des sous totaux et de les stocker dans un environnement OLAP.

Une requête MDX générée par un client (type Excel) peut ramener un grand nombre de données à des granularités différentes. Générer des agrégats pré-calculés et pré-stockés permet d’assurer un temps de récolte des données beaucoup plus rapide.

Lorsqu’une requête demande des données à un niveau autre que le niveau le plus fin, le moteur procède, en temps réel, à l’agrégation des données jusqu’à obtenir le niveau de granularité désiré.

Ces données sont tout d’abord lues dans la partition puis agrégées par le moteur. La génération d’agrégats stockés permet de s’affranchir de cette phase d’agrégation en temps réel en stockant les valeurs pré-calculées dans un fichier d’agrégats.

Stocker des agrégats dans une base multidimensionnelle est une façon efficace d’améliorer sensiblement les performances en termes de temps de réponse.

Ces agrégats vont être stockés dans des fichiers, il est donc intéressant de se fixer un ratio Taille sur disque Agrégats / taille sur disque Données.

La taille occupée sur disque est un facteur très important dans le dimensionnement de l’architecture disque. Prenons l’exemple de 4 dimensions composées d’une hiérarchie, chacune d’entre elle comporte 5 niveaux. Si l’on souhaite générer des agrégats pour l’ensemble des croisements alors il faut considérer 5x5x5x5 – 1 = 624 agrégats. La taille sur disque sera alors exponentielle, il s’agira donc de se poser les questions suivantes :

-        Quels niveaux doivent être ou non agrégés ?

-        Peut-on générer des sous ensembles d’agrégats, fils d’ensembles déjà existants ?

-        Quels sont les avantages et inconvénients sur l’utilisation de données agrégées ?

-        Quelle taille disque doit-on considérer pour nos agrégats ?

-        Quel pourcentage d’optimisation est-on en droit d’attendre de ces optimisations ?

Dès lors en version 2005 il est possible via le profiler de capturer les vecteurs d’agrégats correspondants aux différentes requêtes évaluées par le serveur.

Les évènements « QuerySubcube » du profiler nous renvoient des messages de type :

1000000000,00000000000000000000000000000000000000,00000000000,00000000000,101000000101000011,0000000000,0000000000,00000000000

Chaque SubCube correspond au résultat d’une requête et la colonne « duration » du profiler nous permet de voir le temps d’exécution de la requête ou subcube considéré.

Le résultat est une vision binaire de l’exécution, chacun des 1, 0 correspond à l’attribut d’une dimension. Un 1 correspond à une occurrence, un 0 à la position All de l’attribut considéré.

Le décryptage du vecteur d’agrégats est alors possible via un outil « Agregation Manager » dans SQL Server 2005 permettant ainsi de visionner le croisement et créer un agrégat sur celui-ci.

Décodage d’un vecteur d’agrégats

Dans Analysis Services 2008 cette notion d’agrégats a été ajoutée à l’outil de développement BIDS. Un nouvel onglet dans l’affichage du cube permet la mise en place fine d’agrégats.

Les DMVs (Dynamic Management Views) dans Analysis Services 2008

Une des évolutions majeures d’ Analysis Services 2008 est les DMVs mises à disposition pour assurer l’administration de la solution.

Les DMVs permettent maintenant de répondre aux questions suivantes :

-        Trouver et arrêter une requête en cours

-        Avoir des informations sur l’utilisation d’une requête, qui quand …

-        Avoir des informations sur l’état du serveur …

Le concept reste le même que sur les DMVs SQL Server. Les demandes et résultats sont visibles sur simple requête.

Syntax: Select * from $system.”NameOfTheDiscover”

Les principales DMVs :

Le script suivant permet l’intégration des DMVs à Windows Server 2008 via PowerShell.

Ce script permet l’exécution d’une DMV sur un serveur Analysis Services local ou distant.

##############################################################################

##

##   Return the results of a SSAS 2008 DMV

##

##    ## Retrieve data (from the local SSAS server. default instance)

##    -Sql "SELECT * FROM $SYSTEM.Discover_Connections"

##

##    ## Retrieve data (from a remote server, default instance)

##    -Sql "SELECT * FROM $SYSTEM.Discover_Connections" -server "WIN2K8"

##

##    ## Retrieve data (from a remote named instance)

##    -Sql "SELECT * FROM $SYSTEM.Discover_Connections" -server "WIN2K8\SALES"

##

##############################################################################

param(

    [string] $server = "(local)",

    [string] $sqlCommand = $(throw "Please specify a query."),

    [string] $provider = "msolap"

  )

##write-Output "sqlCommand: $sqlCommand" ## debug

## Prepare the connection string based on information provided

$connectionString = "Provider=$provider; " +

                    "Data Source=$server; "

## Connect to the data source and open

$connection = New-Object System.Data.OleDb.OleDbConnection $connectionString

$command = New-Object System.Data.OleDb.OleDbCommand $sqlCommand, $connection

$connection.Open()

## Fetch the results, and close the connection

$adapter = New-Object System.Data.OleDb.OleDbDataAdapter $command

$dataset = New-Object System.Data.DataSet

[void] $adapter.Fill($dataSet)

$connection.Close()

## Return all of the rows from their query

$dataSet.Tables[0]

Les sauvegardes

20% des cubes ont aujourd’hui une taille supérieure à 50Go. Le backup de ces solutions est une étape critique dans l’exploitation et l’administration de toute solution multidimensionnelle.

Il s’agit alors de trouver le meilleur moyen pour effectuer un backup d’une solution OLAP dans les meilleures conditions avec les meilleures performances possibles.

Analysis Services 2005 dispose d’un système de backup qui fonctionne pour la plupart des cubes en dessous de 20GB. Les performances sont alors dégradées sur des cubes à très forte volumétrie. La solution palliative reste la copie de fichier.

Analysis Services 2008 dispose d’un système de backup complètement revu qui permet de garantir un haut niveau de performance sur des cubes de tous types et toutes tailles. La courbe de backup reste linéaire sur la volumétrie alors que celle issue d’Analysis Services 2005 devenait exponentielle.

Cette avancée permet de garantir des temps de backups constants sur des volumétries qui souvent évoluent de façon significatives dans le temps.

En conclusion…

L’arrivée de SQL Server 2008 apporte des avancées considérables en termes de souplesse de développement, tuning de la solution et supervision des cubes Analysis Services.

Le développeur est aujourd’hui capable, via l’interface de développement, de maitriser toutes les parties d’une solution Analysis Services 2008.

L’administrateur dispose aujourd’hui de réels moyens de supervision et d’administration de la solution OLAP pouvant ainsi assurer un suivi et une qualité de service optimale.

Un besoin récurrent est de définir une table de dimension temps et de l'alimenter.

Mise en place :

Le script ci-dessous crée une structure simplifiée de la table « DimDate » issue de la base d'exemple AdventureWorksDW.

En effet, par simplicité, seule les informations de langue anglaise sont enregistrées dans cette table.

L'alimentation de la table est réalisé à l'aide d'une procédure stockée qui prend en paramètre les deux bornes des dates.

IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[DimDate]') AND type in (N'U'))

DROP TABLE [dbo].[DimDate]

GO

CREATE TABLE [dbo].[DimDate](

    [DateKey] [int] identity NOT NULL,

    [FullDateAlternateKey] [date] NOT NULL,

    [DayNumberOfWeek] [tinyint] NOT NULL,

    [EnglishDayNameOfWeek] [nvarchar](10) NOT NULL,

    [DayNumberOfMonth] [tinyint] NOT NULL,

    [DayNumberOfYear] [smallint] NOT NULL,

    [WeekNumberOfYear] [tinyint] NOT NULL,

    [EnglishMonthName] [nvarchar](10) NOT NULL,

    [MonthNumberOfYear] [tinyint] NOT NULL,

    [CalendarQuarter] [tinyint] NOT NULL,

    [CalendarYear] [smallint] NOT NULL,

    [CalendarSemester] [tinyint] NOT NULL,

CONSTRAINT [PK_DimDate_DateKey] PRIMARY KEY CLUSTERED

(

    [DateKey] ASC

))

GO

IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[FillDimDate]') AND type in (N'P', N'PC'))

DROP PROCEDURE [dbo].[FillDimDate]

GO

Create Procedure FillDimDate

    @starting_dt datetime

    ,@ending_dt datetime

as

set datefirst 1

declare @cntr_day datetime,@diff int,@cntr int;

SET @cntr = 0

select @diff = datediff(dd,@starting_dt,@ending_dt)

while @cntr <= @diff

begin

    select @cntr_day = dateadd(dd,@cntr,@starting_dt)

    insert into [DimDate]

    (FullDateAlternateKey,

    DayNumberOfWeek ,

    EnglishDayNameOfWeek,

    DayNumberOfMonth,

    DayNumberOfYear,

    WeekNumberOfYear,

    EnglishMonthName,

    MonthNumberOfYear,

    CalendarQuarter,

    CalendarYear,

    CalendarSemester)

    select

    @cntr_day

    ,datepart(dw,@cntr_day)

    ,case datepart(dw,@cntr_day)

    when 1 then 'Monday'

    when 2 then 'Tuesday'

    when 3 then 'Wednesday'

    when 4 then 'Thursday'

    when 5 then 'Friday'

    when 6 then 'Saturday'

    when 7 then 'Sunday'

    end

    ,datepart(day,@cntr_day)

    ,datepart(dy,@cntr_day)

    ,datepart(wk,@cntr_day)

    ,case datepart(mm,@cntr_day)

    when 1 then 'January'

    when 2 then 'February'

    when 3 then 'March'

    when 4 then 'April'

    when 5 then 'May'

    when 6 then 'June'

    when 7 then 'July'

    when 8 then 'August'

    when 9 then 'September'

    when 10 then 'October'

    when 11 then 'November'

    when 12 then 'December'

    end

    ,datepart(mm,@cntr_day)

    ,datepart(qq,@cntr_day)

    ,datepart(yy,@cntr_day)

    ,case (datepart(mm,getdate()))

    when 1 then 1

    when 2 then 1

    when 3 then 1

    when 4 then 1

    when 5 then 1

    when 6 then 1

    else 2

    end

    set @cntr = @cntr + 1

end

GO

EXECUTE FillDimDate @starting_dt ='2006-01-01',@ending_dt = '2009-12-31'

GO

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

Représentation normalisée

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