3 Integration services
Grâce à integration services, il est possible de créer simplement un package de récupération des données, package qui, une fois installé sur le serveur SQL de production, se chargera de rapatrier le contenu des bases sources vers le Datamart et ce, selon la planification configurée lors de l'installation du package sur le serveur.
Avant de s'intéresser au fonctionnement d'Integration services, il est indispensable d'établir la modélisation du Datamart. Pour accroître les performances, le modèle relationnel est délaissé en Business Intelligence au profit du modèle dimensionnel ou multidimensionnel.
3.1 Modélisation dimensionnelle
Il est important de comprendre la structure des données en Business Intelligence avant de commencer à réaliser la modélisation dimensionnelle.
L'ensemble des données sera stocké dans le Datawarehouse. Celui-ci sera constitué de plusieurs Datamarts, chacun répondant à un besoin métier spécifique. Dans notre exemple, ce besoin est le suivant : avoir un accès simple aux différentes statistiques opérationnelles. Nous allons donc concevoir un Datamart répondant à ces contraintes. Il existe principalement deux types de modélisation : l'étoile et le flocon. Le flocon étant un dérivé de l'étoile avec une notion de hiérarchie supplémentaire, nous allons utiliser l'étoile.
Le principe est le suivant : chaque Datamart contient une table des faits et des tables de dimensions selon le schéma suivant :
La table de faits contient les ids des dimensions et les valeurs numériques non connus avant le dépannage. Ainsi, pour distinguer les dimensions de la table des faits, il faut retenir qu'une dimension ne peut être qu'un ensemble fini d'éléments connus avant que le fait ne se produise.
Ainsi, ici, adresse, motif, motinv, date, heure et CS sont connus avant qu’une intervention n'ait lieu. La date et l'heure sont la plupart du temps des dimensions. Selon le degré de précision nécessaire, il est suffisant, d'avoir une seule et unique table contenant à la fois la date et l'heure.
Néanmoins, dans le cadre de l'exemple, nous souhaitons avoir une précision à la seconde. Supposons que nous envisagions une période de 10 ans. Cela nécessiterait (60*60*24*365*10) = 315 360 000 enregistrements. En effet, dans une table de dimension, tous les cas doivent déjà être présents dans la table. Devant le nombre trop élevé d'enregistrements nécessaires dans le cadre de l'exemple, il est préférable de subdiviser heure et date, ce qui fait respectivement 86400 et 3650 enregistrements.
En résumé, en modélisation dimensionnelle, tous les paramètres pour lesquelles les valeurs sont connues deviennent des dimensions, les autres sont stockés dans la table des faits. Ici, on va obtenir une dimension CS, une dimension date, une dimension heure, une dimension motif, une dimension motinv et une dimension adresse. La seule inconnue est le numéro dans la rue.
ATTENTION : dans l'exemple, la table Adresse deviendra une dimension seulement dans la mesure où nous disposons de toutes les rues de Paris. Si cette valeur était une donnée récupérée au fur et à mesure des interventions, cette donnée aurait été stockée dans la table des faits.
NB : Dans le cas ou les dimensions peuvent subir de légères modifications, elles restent considérées comme des dimensions et integration services permettra de tenir compte des changements.
3.2 Démarrer avec integration services
Pour commencer un projet integration services, il faut lancer le logiciel SQL Server Business Intelligence Development Studio et choisir nouveau>projet>projet integration services.
Automatiquement, un package est crée, par défaut, il se nomme package.dtsx. A partir de la, deux solutions sont possibles :
- Utilisation d'un assistant import/export : l'utilitaire crée automatiquement les flux de données qui correspondent aux besoins.
- Création manuelle des flux de données.
- C'est cette dernière solution qui va être détaillée.
3.3 Création manuelle du package
Deux types de flux sont disponibles les flux de contrôles et les flux de données. Pour utiliser des flux de données, il faut placer un flux de contrôles de type « Tâche de flux de données ». De nombreux autres flux de contrôles existent, seulement trois seront utiles dans cet exemple : « Tâche de flux de données », « Tâche de traitement SQL Server Analysis Services » et « Tâche d'exécution de requêtes SQL ». Le principe reste valable pour les autres flux de contrôles, sachant qu'une documentation est disponible sur le site MSDN.
Pour créer une tâche de flux de contrôle, il suffit de faire un simple glissé-déposé avec celle-ci sur l'espace de travail.
IMPORTANT : Ne pas hésiter à subdiviser en nombreux flux de contrôles, en effet, il est possible de les désactiver indépendamment les uns des autres, ce qui permet, lors des tests de n'exécuter que la partie nécessaire.
Voici la structure en flux de contrôles de l'exemple :
La tâche d'exécution de requête SQL n’apparait pas ici, elle a été utilisée afin de créer un package de remise à zéro (suppression et création des tables avec leurs contraintes d’intégrité), package indépendant de celui-ci qui servira à la récupération quotidienne des données.
Le package va nécessiter des connexions vers les serveurs de données d’origine et de destination, il faut au préalable avoir crée des connections vers les bases de données sollicitées au niveau du gestionnaire de connexions (ne pas confondre avec les sources de données). Dans notre exemple, nous allons configurer deux types de connexions différents, l’une vers un serveur MySQL (Source) avec ODBC (Assurez vous d'avoir installé le pilote ODBC préalablement.), l'autre vers un serveur SQL Server 2005 (destination). Pour cela, il suffit de faire un clic droit sur l'espace du gestionnaire de connexions, de choisir "Nouvelle connexion..." et de choisir le type de connexion (ODBC ou OLE DB dans notre cas).
Nous avons ainsi deux connexions : une source qui s'appelle MySQL et une destination : StatOPE. StatOPE correspond au serveur SQL qui hébergera la solution de Business Intelligence.
3.4 Gestion des flux de données
Pour l'instant, aucune donnée n'a pour l'instant été récupérée depuis le serveur source MySQL.
Pour récupérer des données et les traiter, nous allons utiliser les « Tâches de flux de données » crées précédemment. Pour cela, il suffit, soit de cliquer sur l'onglet flux de données puis de choisir dans la liste déroulante sur quel flux nous souhaitons travailler, soit de double cliquer sur la « Tâche de flux de contrôle » correspondante.
De nombreux éléments peuvent être utilisés sur les flux de données :
De même que pour les flux de contrôles, toutes ces transformations de flux de données ne seront pas utiles dans cet exemple.
I) Mise en place de la source
Pour pouvoir récupérer les données depuis le serveur MySQL, étant donné que l'on ne peut pas utiliser une source OLE DB avec MySQL, il faut utiliser une source de type datareader.
Puis, il faut configurer MySQL comme source, et enfin, taper la requête SQL permettant de récupérer les données souhaitées (seules les requête reconnu par la version du serveur MySQL utilisé comme source seront reconnues).
NB : Pour les sources de type OLE DB, la manipulation sera similaire à la mise en place du destinataire du flux de données, étant donné que dans notre exemple, il s'agit d'un serveur SQL Server 2005. Inversement, en cas de destinataire de type MySQL, il conviendra d'utiliser un destinataire de type datareader.
NB : A noter que pour les sources de données de type OLE DB, il n'est pas indispensable de taper une requête SQL, il est possible de cocher les colonnes souhaitées.
II) Réalisation d'une jointure
Très utile dans le cadre de l'exemple, la jointure est assez simple à mettre en place.
Attention, il est indispensable de procéder à un tri sur le flux de données avant la jointure.
Celle-ci présente deux entrées. Les deux entrées doivent avoir au moins une clef en commun, trié dans le même ordre. Il en va de même lorsqu'il y a plusieurs clefs.
On obtient ainsi la jointure suivante :
III) Utilisation de Unir tout
Unir tout est un composant qui permet de réunir les informations de plusieurs flux de données. Ainsi, dans notre exemple, nous avons trois catégories d'adresse, l'adresse classique, l'adresse des établissements répertoriés qui possède en plus de l'adresse classique un numéro de site, et l'adresse des établissements signalés qui dispose là encore d'un numéro de site. Nous allons donc réunir les trois types d'adresses dans une seule et même table avec l'adresse classique plus le numéro de site (à NULL si adresse classique).
Il suffit de choisir les colonnes, en indiquant à gauche, les colonnes de la table finale et à droite les colonnes correspondantes dans les tables existantes.
IV) Dimension à variation lente
La dimension à variation lente est un composant indispensable dans notre exemple. Il s'agit du composant qui va prendre en compte les éventuelles modifications dans une table de dimension. Un assistant se lance lors de la configuration du composant.
ATTENTION : Pour la mise en place du composant, il est indispensable de posséder une clef d'entreprise dans la table de dimension. Cette clef, qui ne peut pas être un attribut auto-incrémenté, doit être unique. La clef d’entreprise correspond donc à un attribut ou a un ensemble d’attributs qui pourrai(en)t remplir le rôle de clef primaire.
Par la suite, il suffit de sélectionner la table finale et de spécifier les attributs qui sont des clefs d'entreprises.
Puis, concernant les autres attributs, il faut choisir de quel type d'attribut il s'agit. Trois possibilités sont offertes :
- Attribut fixe : les attributs ne peuvent pas être modifiés;
- Attribut Modifiable : les attributs peuvent être modifiés, les anciennes données sont perdues. (Cela peut être problématique vis à vis de la table des faits, car on peut se retrouver avec un attribut qui pointe sur un élément ayant été modifié);
- Attribut d'historique : les attributs doivent disposer d'une à deux colonnes en plus, et il possède ainsi une date de début et une date de fin, les attributs n'ayant pas de date de fin étant les attributs possédant les valeurs les plus récentes.
Il suffit alors de spécifier le nom des colonnes (de type datetime) qui contienne les informations de début et de fin.
Les modifications éventuelles des tables de types dimensions sont ainsi prise en compte. Dans l'exemple, nous avons choisi les attributs d'historiques. A la fin de l'assistant, tous les composants nécessaires sont automatiquement générés, depuis la gestion des modifications jusqu'à l'écriture dans la table. Ce qui nous donne, dans le cas des attributs de type historique :
Tous les éléments nécessaires aux traitements des adresses sont expliqués.
Le schéma de flux de données est le suivant :
La fin étant la même que le schéma de dimension à variation lente ci-dessus.
V) Destinataire de flux de données
De même que pour la source de flux de données, nous utilisons dans l'exemple principalement deux types : datareader ou OLE DB. Dans notre cas, c'est un serveur SQL qui est destinataire des données (99,9% des cas en Business Intelligence avec SQL Server 2005, la base étant stockée sur le serveur de BI), nous allons donc utiliser un composant OLE DB comme destinataire. Il suffit alors de sélectionner la connexion à utiliser, StatOPE dans notre cas, puis de choisir la table de destination.
Il ne reste plus qu'à vérifier le mappage des colonnes :
NB : Le composant vous propose de créer la table adéquate correspondant au flux d'entrée du composant, pour cela, il suffit de cliquer sur nouveau, au niveau du choix de la table.
3.5 Conclusion : Integration services
Les composants décrient ci-dessus permettent de traiter les cas des dimensions. Il y a encore de très nombreux autres traitement possible sur le flux de données, tel que le changement de type de données ou le composant script qui permet d'exécuter un script en Visual basic (utilisé dans la table de fait pour changer le format de date : AAAA-MM-DD en DD/MM/AAAA sans avoir recours à un format de type datetime). Voici ci dessous l'intégralité des trois flux de données du package.
Transfert des 6 dimensions :
Création de la table de faits
Le traitement avec Integration Services est terminé. On dispose maintenant d'un package de rapatriement des données.
ATTENTION : Lors de la création de vos projets IS, ne perdez jamais de vue qu'il s'agit d'un package qui sera exécuté régulièrement et automatiquement, dont le but est le rapatriement des données.
 Sommaire
Introduction
1. Business Intelligence et SQL Server 2005
2. Présentation du projet
2. Integration services
3. Analysis services
4. Reporting services
Annexe 1 - Gestion de la sécurité du site de reporting
Annexe 2 - Personnalisation du site de reporting
Conclusion
|
|
 |
 Pour afficher ou poster un commentaire, cliquez sur ce lien : Forum-Microsoft
|
|
Solution de Business Intelligence avec SQL Server 2005
