SAS® Data Integration Studio est une interface cliente Java de la plateforme décisionnelle SAS. Elle fait partie des packages « SAS Data Integration Server » et « SAS Enterprise Data Integration Server ».
SAS Data Integration Server comprend notamment SAS/Base, SAS/CONNECT, SAS Data Integration Studio.
SAS Enterprise Data Integration Server comprend notamment SAS/Base, SAS/CONNECT, SAS/SHARE, 2 SAS/Access au choix, SAS Data Integration Studio, SAS Data Quality Server et LSF.
LSF est un Ordonnanceur permettant, comme son nom l’indique, d’ordonnancer des flux de processus.
SAS Data Integration Studio permet de créer des flux de processus, qui une fois créer, vont être déployés pour l’ordonnancement.
Copie d’écran du “Flow Manager” de LSF
Copie d’écran du « Calendar Editor » de LSF
A propos de SAS® Data Integration Studio, notons que l’outil :
• Support des développements concurrents de développeur ETL, gestion des versions via le
« Check-Out/Check-In ». Dans un projet ETL, l’administrateur de la plateforme décisionnelle crée un référentiel de métadonnée dit « référentiel projet » pour chaque développeur ETL.
Ceux-ci peuvent alors être extraits (Check-out) du référentiel principal, dans leur référentiel
permet donc à plusieurs développeurs ETL de travailler sans conflit sur un même projet et la gestion des versions.
• Permet un développement administré et donc sécurisé, ce qui est nécessaire pour la gestion du changement.
• Permet d’accéder à l’ensemble des systèmes de gestion de bases de données du marché, via les différents SAS/ACCESS to ... (SAS/ACCESS to Oracle, SAS/ACCESS to DB2, SAS/ACCESS to Terradata, etc.)
• Permet l’intégration avec plusieurs ERP du marché comme par exemple SAP. Le terme intégration prend ici toute sa valeur, on n’extrait pas seulement de la donnée, on accède à la métadonnée de l’application de l’entreprise, ce qui permet une véritable communication bidirectionnelle. Mais surtout, le fait d’accéder à la structure globale de l’application opérationnelle, permet dans le cas de solution métier, un raccourcissement considérable du temps de mise ne place du projet. Cela fonctionne particulièrement bien avec SAP qui à la réputation d’être très bien structuré (et structurant). Un « SAS/Adapter to . » permet l’intégration avec les différents grands progiciels du marché.
• Support les modèles de donnée du standard CWM. Common Warehouse Model, selon le site web www.cwm.org, CWM est une norme pour les outils décisionnels permettant de transférer des fichiers de métadonnées entre différentes applications décisionnelles de différents éditeurs de logiciel. Par exemple, intégrer une l’application de reporting Business Object® à la plateforme SAS®.
• Il est possible d’ajouter des plug-in java pour compléter l’ensemble des fonctionnalités, de créer rapidement ses propres outils ETL.
• Permet la construction de Cube (vous devez avoir une licence pour le package « SAS®
Intelligence Storage » ou SAS OLAP Serveur)
La planification du Data Warehouse est une phase cruciale qui nécessite donc une certaine rigueur.
Pour le bon déroulement de celle-ci, je vous propose la liste suivante de point important qui est la concaténation de différents éléments récupérés à droite - à gauche. Ce n’est pas une méthodologie à proprement parler, car l’objectif ici est plus d’avoir une tête bien faite que bien pleine. C'est-à-dire que je préfère que vous sentiez la philosophie du décisionnelle plus que de vous donner une méthodologie à appliquer bêtement. De plus il n’y a pas de méthodologie parfaite si l’on n’a pas saisi la philosophie du problème pour pouvoir l’adapter. Enfin, les deux livres Entrepôts de données. Guide pratique de modélisation dimensionnelle, 2ème édition, et Le Data Warehouse : Guide de conduite de projet de Ralph Kimball, aux éditions Eyrolles ; sont toujours d’actualité et couvrent remarquablement bien ces deux thèmes.
1. Définition des besoins :
a. Création de la liste des questions métiers auxquelles devra répondre le projet décisionnel. Pour élaborer cet inventaire, la maitrise d’ouvrage doit interroger les différents utilisateurs potentiels pour récolter leur besoin. Pour chaque indicateur, il est très important d’avoir une définition précise de sa formule (règle de calcul), une description de son interprétation et de son utilité. Si vous demandez à quelques personnes autour de vous, la définition du turnover en ressources humaines, presque tous pensent la connaître, ou tout du moins ont une idée sur le sujet, mais l’on arrive très vite à soulever des différences. Parle-t-on du turnover volontaire ou bien du taux de renouvellement global ? Quel sont les contrats pris en compte ? CDD, CDI ? En effet, ce turnover peut être le nombre de salarier en CDI démissionnant, divisé par le nombre moyen de salarier total dans l’entreprise, sur l’année. Ce peut aussi être le nombre de fin de contrat (fins de CDD, démissions, départs à la retraite, licenciements, etc.) sur le nombre de salarié total en début d’année. Suivant les éléments au numérateur et au dénominateur de ce rapport, les résultats et les interprétations peuvent facilement varier. Mais le plus important est peut être de définir l’utilité de chaque indicateur et donc les moyens d’action potentiels à mettre en œuvre pour corriger le tir si cet indicateur tourne au vinaigre.
b. Définition de l’ensemble des dimensions qui devront être prise en compte afin de répondre aux questions précédemment listées. Est-ce que le chiffre d’affaire doit être analysé par produits, par clients, par région, par période de temps. En posant ces questions : quels indicateurs, suivant quels axes ; les différents schémas en étoile ou cubes multidimensionnels se dessinent progressivement.
c. Définition de qui utilisera ces informations et quand elles seront utilisées, afin de définir le nombre de requêtes simultanées.
d. Définition de la fréquence de mise à jour des informations, en pseudo-temps réel, tous les jours, toutes les semaines, tous les mois, tous les trimestres, toutes les années.
e. Définition de la durée de vie des données dans le Data Warehouse, notamment les données de détail ne doivent pas nécessairement rester à vitam et ternam dans le Data Warehouse.
f. Définir les indicateurs clés et leur ordre de priorité pour les mettre en place. Lors de la collecte des indicateurs souhaités, on obtient facilement une liste très longue. La construction d’un Data Warehouse se déroule de manière itérative et incrémentale.
L’idée est de sélectionner les indicateurs à implémenter en priorité. Il y a souvent des
« pépites », des indicateurs où la maîtrise d’ouvrage se doute fortement que leur implémentation n’est pas très compliquer et peut rapporter beaucoup. C’est pépites permettront de rapidement justifier de la valeur ajouté d’un Data Warehouse.
2. Faire l’inventaire des données nécessaires à la construction du Data Warehouse.
a. Lister l’ensemble des systèmes et des bases de données, auxquelles il sera nécessaire de se connecter pour l’étape d’extraction. Récupérer le format de stockage, le format des tables et des colonnes des bases de données amont.
b. Localiser l’ensemble des informations qui seront nécessaires à la population du Data Warehouse. Récupérer les noms des responsables et des administrateurs pouvant
de stockage, pour l’ensemble des requêtes qui interrogeront le Data Warehouse. En fonction du nombre de requêtes simultanées, du temps de réponse souhaité, la forme logique de stockage pourra ainsi être définit. Est-ce qu’un schéma en étoile et plus ou moins approprié par rapport à un cube multidimensionnel de type R-OLAP, M-OLAP ou bien H-OLAP. Est-ce qu’un accès direct au DDS est suffisant.
4. Prendre en compte la possibilité d’étendre le Data Warehouse à d’autres problématiques.
a. Estimation du besoin de hardware et de software pour l’achat de ces derniers.
b. Prendre notamment en compte le stockage, les serveurs de traitement et de sauvegardes (Comme un système opérationnel dont le fonctionnement est vital pour l’organisation, un système décisionnel doit généralement avoir un système de secours)
5. Planification des flux de mise à jour.
a. Définition de la fréquence de mise à jour des données.
b. Planification des flux de processus d’extraction, de transformation de nettoyage et de validation de l’information
6. Définition des processus de nettoyage et de validation de l’information
a. Définition des processus d’extraction et de transformation qui chargeront le Data Warehouse
b. Définition des processus qui génèreront de manière automatique des rapports.
c. Définition des règles d’administrations
d. Définition de qui pourra voir quelles informations e. Définition des droits des développeurs
7. Installation et test de la plateforme décisionnelle. Il faut noter que jusqu’à ce point, rien n’a été fait sur machine ; seul la documentation technique a été écrite.
8. Développement et test des systèmes de sauvegarde et des copies de secours. C’est un phénomène nouveau, jusqu’alors, les systèmes décisionnels n’étaient pas encore considérés comme vitaux. Dorénavant, de plus en plus en plus de systèmes décisionnels bénéficient d’un système de secours. Il faut donc tester la récupération du système dès le départ ; avant de le mettre en place.
9. Création des processus ETL défini précédemment. C’est ce que nous allons faire maintenant.
10. Exécution d’une première passe pour chaque processus pour vérifier les temps de réponse, la qualité des données, etc.
11. Ordonnancement des processus. Définition des conditions d’exécution automatique des processus. Tous les jours, toutes les semaines, tous les mois etc.
12. Suivie et maintenance du Data Warehouse.