Les systèmes d’entrepôts de données d’entreprise (EDW) visent à fournir une véritable Business Intelligence (BI) pour l’entreprise axée sur les données. Les entreprises doivent se pencher sur les paramètres critiques ancrés dans ces données vitales et dynamiques. L’un des principaux objectifs de ces systèmes d’entrepôt de données d’entreprise est de fournir un processus d’intégration des données essentiel qui, à terme, prend en charge une variété d’exigences de reporting. Leur construction implique d’importants efforts de conception, de développement, d’administration et d’exploitation. Lorsque les systèmes, les structures ou les règles de l’entreprise en amont changent, ne parviennent pas à fournir des données cohérentes ou nécessitent de nouvelles solutions d’intégration de systèmes, les exigences minimales de réingénierie nous placent devant le problème n°1 : la seule constante est le changement ; alors, dans quelle mesure une solution EDW/BI peut-elle s’adapter ?
« Ce n’est pas la plus forte des espèces qui survit, ni la plus intelligente. C’est celle qui s’adapte le mieux au changement. » Charles Darwin
La consommation et l’analyse des données d’entreprise par diverses communautés d’utilisateurs sont devenues une réalité critique pour maintenir un avantage concurrentiel pourtant les réalités technologiques d’aujourd’hui nécessitent souvent des utilisateurs finaux hautement qualifiés. La capture, le traitement, la transformation, le nettoyage et l’établissement de rapports sur ces données peuvent être compréhensibles, mais dans la plupart des cas, le simple volume de données peut être écrasant ; Ouaip, problème #2 : Really Big Data ; souvent caractérisé comme : Volume, Vélocité, Variété, Véracité, Visualisation, &Valeur !
Créer des systèmes EDW/BI efficaces et efficients, simplifiés pour l’utilisation et le reporting de ces données, devient rapidement une épreuve technique intimidante et souvent difficile, même pour les équipes d’ingénieurs vétérans. Plusieurs technologies intégrées sont nécessaires, depuis les systèmes de bases de données, les outils de traitement de données (ETL) comme Talend, les différents langages de programmation, les logiciels d’administration, de reporting et de graphiques interactifs jusqu’aux réseaux haute performance et aux ordinateurs puissants disposant de très grandes capacités de stockage. La conception, la création, la livraison et le support de systèmes EDW/BI robustes et sans effort pour une utilisation simplifiée et intelligente sont, vous l’avez deviné ; le problème n°3 : la complexité !
Souvent, nous voyons des solutions complètes et élégantes livrées à l’utilisateur métier qui ne comprend pas les véritables besoins de l’entreprise. On nous dit que c’est juste comme ça en raison des exigences techniques (limitations ; clin d’œil, clin d’œil) et/ou des paramètres de conception (manque de fonctionnalités ; nudge, nudge). D’où le problème n° 4 : le domaine de l’entreprise ; adapter les données aux besoins de l’entreprise, et non l’inverse !
De plus, à mesure que les systèmes en amont changent (et ils changeront), que la technologie EDW/BI avance (et elle doit le faire), que les complexités dynamiques impliquées prévalent (implacablement), de temps en temps, de nouvelles sources de données doivent être ajoutées au mélange. Celles-ci sont généralement imprévues et non planifiées. L’impact de l’intégration peut être énorme, nécessitant souvent une régénération complète des données agrégées ; d’où le problème n° 5 : La flexibilité ; ou le manque de flexibilité!
Alors, comment résoudre ces problèmes ? Eh bien …
Bill Inmon largement considéré comme le père de l’entreposage de données, définit un entrepôt de données comme suit :
« Une collection de données orientée sujet, non volatile, variant dans le temps, en soutien aux décisions de la direction »
(http://en.wikipedia.org/wiki/Bill_Inmon)
Ralph Kimball (http://en.wikipedia.org/wiki/Ralph_Kimball), un architecte pionnier de l’entreposage de données, a développé la méthodologie de « modélisation dimensionnelle » maintenant considérée comme la norme de facto dans le domaine de l’aide à la décision. Le modèle dimensionnel (appelé « schéma en étoile ») est différent de la méthodologie de « modélisation normalisée » d’Inman (parfois appelée « schéma en flocon de neige »). Dans le schéma en étoile de Kimball, les données transactionnelles sont partitionnées en « faits » agrégés avec des « dimensions » référentielles entourant et fournissant des descripteurs qui définissent les faits. Le modèle normalisé (3NF ou « troisième forme normale ») stocke les données dans des « tables » liées entre elles, conformément aux règles de conception des bases de données relationnelles établies par E. F. Codd et Raymond F. Boyce au début des années 1970, qui éliminent la redondance des données. Favorisant un débat vigoureux entre les architectes EDW/BI pour savoir quelle méthodologie est la meilleure, les deux présentent des faiblesses lorsqu’il s’agit de faire face aux changements inévitables des systèmes alimentant l’entrepôt de données et de nettoyer les données pour se conformer aux exigences strictes de la méthodologie.
En outre, le cube OLAP (pour « online analytical processing ») est une structure de données qui permet une analyse rapide des données à partir de plusieurs perspectives. La structure du cube est créée à partir d’un schéma Star ou Snowflake stocké sous forme de métadonnées à partir desquelles on peut visualiser ou « pivoter » les données de différentes manières. En général, les cubes ont une dimension temporelle qui permet une représentation historique des données. La création de cubes OLAP peut être très coûteuse et crée souvent une quantité importante de données qui sont peu ou pas utiles. La règle 80/20 semble dans de nombreux cas se vérifier (où seulement 20% des données du cube OLAP s’avèrent utiles) ce qui pose la question : Construit sur une architecture traditionnelle, un cube OLAP offre-t-il vraiment un retour sur investissement suffisant ? Souvent, la réponse est un NON retentissant ! Les systèmes EDW/BI durables doivent apporter une réelle valeur ajoutée.
Découvrez comment Talend a aidé Tipico à transformer des océans de données en business intelligence de pointe.
Une approche fraîche
Le Data Vault est une méthodologie de modélisation de données hybride fournissant une représentation des données historiques à partir de sources multiples, conçue pour être résiliente aux changements environnementaux. Conçue à l’origine en 1990 et publiée en 2000 en tant que méthodologie de modélisation du domaine public, Dan Linstedt, son créateur, décrit une base de données Data Vault résultante comme:
« Un ensemble de tables normalisées, orientées vers le détail, le suivi historique et liées de manière unique, qui prennent en charge un ou plusieurs domaines fonctionnels de l’entreprise. Il s’agit d’une approche hybride englobant le meilleur de la race entre 3NF et les schémas en étoile. La conception est flexible, évolutive, cohérente et adaptable aux besoins de l’entreprise. »
(http://en.wikipedia.org/wiki/Data_Vault_Modeling)
Focalisé sur le processus métier, le Data Vault en tant qu’architecture d’intégration de données, dispose de normes robustes et de méthodes de définition qui unissent les informations afin de leur donner du sens. Le modèle Data Vault est composé de trois types de tables de base:
HUB (bleu) : contenant une liste de clés métier uniques ayant sa propre clé de substitution. Les métadonnées décrivant l’origine de la clé métier, ou la « source » de l’enregistrement, sont également stockées pour suivre où et quand les données ont été créées.
LNK (rouge) : établissant des relations entre les clés métier (généralement des hubs, mais les liens peuvent être liés à d’autres liens) ; décrivant essentiellement une relation many-to-many. Les liens sont souvent utilisés pour traiter les changements de granularité des données réduisant l’impact de l’ajout d’une nouvelle clé métier à un Hub lié.
SAT (jaune) : détenir des attributs descriptifs qui peuvent changer dans le temps (similaire à une dimension Kimball de type II à évolution lente). Alors que les Hubs et les Liens forment la structure du modèle de données, les Satellites contiennent des attributs temporels et descriptifs, y compris des métadonnées les reliant à leurs tables de Hub ou de Liens parents. Les attributs de métadonnées au sein d’une table Satellite contenant une date à laquelle l’enregistrement est devenu valide et une date à laquelle il a expiré fournissent de puissantes capacités historiques permettant des requêtes qui peuvent remonter dans le temps.
L’approche Data Vault présente plusieurs avantages clés :
– Simplifie le processus d’ingestion de données
– Supprime l’exigence de nettoyage d’un schéma en étoile
– Fournit instantanément une auditabilité pour HIPPA et d’autres réglementations
– Met l’accent sur le vrai problème au lieu de programmer autour
– Permet facilement l’ajout de nouvelles sources de données sans perturbation du schéma existant
En termes simples, le Data Vault est à la fois une technique de modélisation des données et une méthodologie qui s’adapte aux données historiques, à l’audit et au suivi des données.
« Le Data Vault est le choix optimal pour modéliser l’EDW dans le cadre DW 2.0 »
Bill Inmon
Adaptable
Par la séparation des clés métier (car elles sont généralement statiques) et des associations entre elles de leurs attributs descriptifs, un Data Vault affronte le problème du changement dans l’environnement. En utilisant ces clés comme colonne vertébrale structurelle d’un entrepôt de données, toutes les données connexes peuvent être organisées autour d’elles. Ces Hubs (clés métier), Links (associations) et SAT (attributs descriptifs) prennent en charge une structure de données hautement adaptable tout en maintenant un haut degré d’intégrité des données. Dan Linstedt établit souvent une corrélation entre le coffre-fort de données et une vue simpliste du cerveau, où les neurones sont associés aux Hubs et aux Satellites et où les dendrites sont des Liens (vecteurs d’information). Certains Liens sont comme des synapses (vecteurs en sens inverse). Ils peuvent être créés ou supprimés à la volée au fur et à mesure que les relations commerciales évoluent en transformant automatiquement le modèle de données selon les besoins, sans impact sur les structures de données existantes. Problème n°1 résolu!
Big Data
Data Vault v2.0 est arrivé sur la scène en 2013 et incorpore une intégration transparente des technologies Big Data ainsi que des mises en œuvre de méthodologie, d’architecture et de meilleures pratiques. Grâce à cette adoption, de très grandes quantités de données peuvent facilement être incorporées dans un Data Vault conçu pour stocker en utilisant des produits comme Hadoop, Infobright, MongoDB et de nombreuses autres options NoSQL. En éliminant les exigences de nettoyage d’un schéma en étoile, le coffre-fort de données excelle dans le traitement d’énormes ensembles de données en réduisant les temps d’ingestion et en permettant des insertions parallèles qui tirent parti de la puissance des systèmes de Big Data. Problème #2 résolu!
Simplification
Créer un modèle Data Vault efficace et efficient peut être fait rapidement une fois que vous comprenez les bases des 3 types de table : Hub, Satellite, et Lien ! Identifier les clés métier en premier et définir les Hubs est toujours le meilleur endroit pour commencer. Ensuite, les Hub-Satellites représentent les colonnes de la table source qui peuvent changer, et enfin les Liens relient le tout. N’oubliez pas qu’il est également possible d’avoir des tables Link-Satellite. Une fois que vous avez compris ces concepts, c’est facile. Une fois que vous avez terminé votre modèle de coffre-fort de données, la prochaine chose à faire est de construire le processus d’intégration de données ETL pour le remplir. Bien qu’un modèle de Data Vault ne soit pas limité aux solutions EDW/BI, un processus d’intégration de données est généralement nécessaire à chaque fois que vous avez besoin de transférer des données d’une source de données vers une cible. La mission de Talend est de connecter l’entreprise orientée données.
Avec sa suite de logiciels d’intégration, Talend simplifie le processus de développement, réduit la courbe d’apprentissage et diminue le coût total de possession avec une plateforme ETL unifiée, ouverte et prévisible. Technologie ETL éprouvée, Talend peut certainement être utilisé pour alimenter et maintenir un système EDW/BI robuste construit sur un modèle de données Data Vault. Problème n°3 résolu!
Votre entreprise
Le Data Vault définit essentiellement l’ontologie d’une entreprise en ce qu’il décrit le domaine métier et les relations au sein de celui-ci. Le traitement des règles métier doit se faire avant de peupler un schéma en étoile. Avec un coffre-fort de données, vous pouvez les pousser en aval, après l’ingestion EDW. Une autre philosophie de Data Vault est que toutes les données sont pertinentes, même si elles sont erronées. Dan Linstedt suggère que les données erronées sont un problème d’entreprise, et non un problème technique. Je suis d’accord ! Un EDW n’est vraiment pas le bon endroit pour réparer (nettoyer) des données erronées. Le principe simple de Data Vault est d’ingérer 100 % des données sources, 100 % du temps, qu’elles soient bonnes, mauvaises ou laides. Dans le monde d’aujourd’hui, l’auditabilité et la traçabilité de toutes les données de l’entrepôt de données sont devenues une exigence standard. Ce modèle de données est conçu spécifiquement pour répondre aux besoins des systèmes EDW/BI d’aujourd’hui. Problème n°4 résolu!
« Comprendre la voûte de données, c’est comprendre l’entreprise »
(http://danlinstedt.com)
Flexible
La méthodologie de la voûte de données est basée sur les meilleures pratiques SEI/CMMI de niveau 5 et comprend plusieurs de ses composants en les combinant avec les meilleures pratiques de Six Sigma, TQM et SDLC (Agile). Les projets Data Vault ont des cycles de publication courts et contrôlés et peuvent consister en une publication de production toutes les 2 ou 3 semaines adoptant automatiquement les projets répétables, cohérents et mesurables attendus au niveau 5 du CMMI. Lorsque de nouvelles sources de données doivent être ajoutées, des clés métier similaires sont probables, de nouveaux Hubs-Satellites-Liens peuvent être ajoutés et ensuite reliés aux structures existantes de Data Vault sans aucune modification du modèle de données existant. Problème n°5 résolu !
Conclusion
En conclusion, la modélisation et la méthodologie Data Vault traitent les éléments des problèmes que nous avons identifiés ci-dessus :
– Elle s’adapte à un environnement d’affaires changeant
– Elle supporte de très grands ensembles de données
– Elle simplifie les complexités de conception EDW/BI
– Elle augmente la facilité d’utilisation par les utilisateurs d’affaires parce que. il est modélisé d’après le domaine métier
– Il permet d’ajouter de nouvelles sources de données sans impacter la conception existante
Cette avancée technologique s’avère déjà très efficace et efficiente. Facile à concevoir, à construire, à alimenter et à modifier, le Data Vault est un vainqueur incontestable. Très cool ! En voulez-vous un ?
Visitez http://learndatavault.com ou http://www.keyldv.com/lms pour en savoir beaucoup plus sur la modélisation et la méthodologie de Data Vault.
Pendant que vous y êtes, téléchargez une version d’évaluation gratuite de Talend Cloud Integration Platform pour savoir ce que vos données peuvent vraiment faire.