Concept d'entrepôt de données. Concevoir une structure d'entrepôt de données relationnelles

08.04.2019

Lire aussi :

Bonpoс 19 Alliages à base d'aluminium et de magnésium. Propriétés et applications.
Pression hydrostatique absolue et ses propriétés
Aldéhydes, séries homologues, structure, groupe fonctionnel. Propriétés chimiques des aldéhydes. Préparation d'aldéhydes en médecine.
Ammoniac (ordre d'utilisation, propriétés, tableau clinique des dommages causés aux personnes et aux animaux de ferme, premiers secours, protection).
Analyse de l'environnement extérieur et de son influence sur l'évolution des décisions de gestion. Propriétés de l'environnement extérieur.
L'analyse de l'utilisation du bénéfice net est réalisée selon la méthode d'analyse verticale et horizontale, pour laquelle les indicateurs sont regroupés dans un tableau similaire au tableau 20.
Analyse des risques, niveau de risque, évaluation des risques sur la base des données disponibles.
Signal analytique. Propriétés des signaux conjugués de Hilbert.

Entrepôt de données (DW)– une collection de données historiques spécifiques à un domaine, intégrées, immuables, organisées à des fins d’aide à la décision.

Le concept d'entrepôt de données repose sur l'idée de séparer les données utilisées pour le traitement opérationnel et pour la résolution de problèmes d'analyse. Cette séparation permet d'optimiser à la fois les structures de données de stockage opérationnel (bases de données en ligne, fichiers, feuilles de calcul, etc.) pour effectuer les opérations de saisie, de modification, de suppression et de recherche, et les structures de données utilisées pour l'analyse (pour exécuter des requêtes analytiques).

Dans DSS (Decision Support System), ces deux types de données sont appelés respectivement sources de données opérationnelles (ODS) et entrepôt de données.

Marché de données (VD)– il s’agit d’une version simplifiée de l’entrepôt de données, contenant uniquement des données combinées thématiquement.

Propriétés de stockage des données :

Orientation sujet (C'est la différence fondamentale entre un entrepôt de données et un OID. Différents OID peuvent contenir des données décrivant le même domaine de différents points de vue (par exemple, du point de vue de la comptabilité, de la comptabilité d'entrepôt, du service de planification, etc.) .). La décision prise sur la base d'un seul point de vue peut être inefficace, voire incorrecte. Les bases de données permettent d'intégrer des informations qui reflètent différents points de vue sur un même sujet.)

Intégration (OID, en règle générale, sont développés à des moments différents par plusieurs équipes avec leurs propres outils. Cela conduit au fait que les données reflétant le même objet du monde réel dans différents systèmes le décrivent différemment. Intégration obligatoire des données dans l'entrepôt de données permet de résoudre ce problème en regroupant les données dans un format unique.)

Prise en charge de la chronologie (les données de l'OID sont nécessaires pour y effectuer des opérations à l'instant présent. Par conséquent, elles peuvent ne pas avoir de référence temporelle. Pour l'analyse des données, il est souvent important de pouvoir suivre la chronologie des changements dans les indicateurs. du domaine. Par conséquent, toutes les données stockées dans l’entrepôt de données doivent correspondre à des intervalles de temps successifs.)

Immuabilité (les exigences relatives à l'OID imposent des restrictions sur la durée de stockage des données. Les données qui ne sont pas nécessaires au traitement opérationnel sont, en règle générale, supprimées de l'OID pour réduire les ressources occupées. Pour l'analyse, au contraire, les données sont requises pendant la période de temps la plus longue possible. Par conséquent, contrairement à l'OID, les données de l'entrepôt de données ne sont lues qu'après le chargement, ce qui permet d'augmenter considérablement la vitesse d'accès aux données, à la fois en raison de la redondance possible des informations stockées et en éliminant les opérations de modification. .)

On peut distinguer ce qui suit Architectures DSS en utilisant la HD :

1) DSS avec HD physique (classique). Un tel modèle conduit inévitablement à une duplication d’informations dans l’OID et dans l’entrepôt de données. Cependant, la redondance des données stockées dans le DSS ne dépasse pas 1 %.

Cela peut s'expliquer par les raisons suivantes :

Lors du chargement des informations de l'OID dans l'entrepôt de données, les données sont filtrées. Beaucoup d'entre eux ne rentrent pas dans l'entrepôt de données car ils n'ont aucun sens du point de vue de leur utilisation dans les procédures d'analyse.

Les informations contenues dans l'OID sont, en règle générale, de nature opérationnelle et les données, ayant perdu leur pertinence, sont supprimées. L’entrepôt de données, au contraire, stocke des informations historiques. De ce point de vue, la duplication du contenu de l'entrepôt de données avec les données OID s'avère très insignifiante. L'entrepôt de données stocke des informations généralisées qui ne sont pas contenues dans l'OID.

Lors du chargement dans l'entrepôt de données, les données sont effacées (les informations inutiles sont supprimées) et après ce traitement, elles occupent un volume beaucoup plus petit.

2) DSS avec stockage virtuel. La redondance dans cette version du DSS est réduite à zéro. Dans ce cas, contrairement à l’entrepôt de données (physique) classique, les données de l’OID ne sont pas copiées dans un seul stockage. Ils sont extraits, convertis et intégrés directement lors de l'exécution de requêtes analytiques dans la RAM de l'ordinateur. En fait, ces demandes sont directement adressées à l'OID. Les principaux avantages du stockage virtuel sont : la minimisation de la quantité de mémoire occupée par les informations sur le support ; travailler avec des données actuelles et détaillées.

Inconvénients de cette approche :

Le temps de traitement des requêtes vers un stockage virtuel dépasse largement les indicateurs correspondants pour le stockage physique.

Une vue intégrée du stockage virtuel n'est possible que si la condition de disponibilité constante de tous les OID est remplie. Ainsi, l'indisponibilité temporaire d'au moins une des sources peut entraîner soit un échec de la requête analytique, soit des résultats erronés.

Exécuter des requêtes analytiques complexes sur des OID nécessite des ressources informatiques importantes.

Différents OID peuvent prendre en charge différents formats de données et codages. Souvent, il peut y avoir plusieurs réponses possibles à une même question. Cela peut être dû à :

– non synchronisation des instants de mise à jour des données dans différents OID ;

– des différences dans la description d'objets et d'événements identiques dans le domaine ;

– des erreurs lors de la saisie ;

– perte de fragments d'archives, etc.

Dans ce cas, l'objectif - la formation d'une vue unique et cohérente de l'objet de contrôle - peut ne pas être atteint.

3) DSS avec VD. Les avantages de cette approche sont :

Concevoir un VD pour répondre à une gamme spécifique de questions ;

Mise en œuvre rapide d’avions autonomes et obtention d’avantages ;

Simplifier les procédures de remplissage des VD et augmenter leur productivité en prenant en compte les besoins d'un certain nombre d'utilisateurs.

Les inconvénients des véhicules aériens autonomes sont :

Stockage répété des données dans différents entrepôts de données, ce qui entraîne une augmentation des coûts de stockage et des problèmes potentiels liés à la nécessité de maintenir la cohérence des données ;

Manque de consolidation des données au niveau du domaine et, par conséquent, manque d’image unifiée.

4) DSS avec HD et VD. Récemment, l'idée de combiner HD et VD dans un seul système est devenue de plus en plus populaire. Dans ce cas, le DW est utilisé comme seule source de données intégrées pour tous les VD.

L'entrepôt de données est une source d'informations centralisée unique pour l'ensemble du domaine, et les domaines de données sont des sous-ensembles de données du référentiel, organisés pour présenter des informations sur les sections thématiques d'un domaine donné.

Les utilisateurs finaux ont la possibilité d'accéder aux données détaillées de l'entrepôt s'il n'y a pas suffisamment de données dans la vitrine, ainsi que d'obtenir une image d'informations plus complète.

Les avantages de cette approche sont :

Facilité de création et de remplissage des entrepôts de données, puisque le remplissage provient d'une source unique, standardisée et fiable de données nettoyées - de l'entrepôt de données ;

Facilité d'extension du DSS en ajoutant de nouveaux identifiants ;

Réduire la charge sur l'unité de stockage principale.

Les inconvénients comprennent :

Redondance (les données sont stockées à la fois dans l'entrepôt de données et dans l'entrepôt de données) ;

Coûts supplémentaires pour le développement de DSS avec HD et VD.

Selon la définition d'E. Inmon, un entrepôt de données est un ensemble de données spécifiques à un domaine, intégrées, immuables et historiquement maintenues, organisées à des fins d'aide à la décision.

Il existe deux types de stockage de données : virtuel et physique. Dans les systèmes qui implémentent le concept de stockage virtuel, les requêtes analytiques sont traitées
directement à l’OID, et les résultats obtenus sont intégrés à l’opération
RAM de l'ordinateur. Dans le cas d'un stockage physique, les données sont transférées
sont transférés de différents OID dans un référentiel unique auquel les analyses sont adressées
Requêtes techniques. Une version allégée de l'entrepôt de données est l'entrepôt de données, qui contient uniquement des données combinées thématiquement. Le volume du VD est nettement inférieur à celui du CD et sa mise en œuvre ne nécessite pas de dépenses importantes. Le VD peut être mis en œuvre indépendamment ou en combinaison avec le HD.

L'entrepôt de données comprend : des métadonnées, des données détaillées, agrégées et archivées. Les données circulant dans l'entrepôt de données forment des flux d'informations : flux d'entrée, de généralisation, d'inversion, de sortie et de métadonnées.

Les données détaillées sont divisées en deux classes : les dimensions et les faits. Les dimensions sont des ensembles de données nécessaires pour décrire des événements. Les faits sont des données qui reflètent l'essence d'un événement.

Données agrégées sont obtenus à partir de données détaillées en les additionnant dans toutes les dimensions. Pour accéder rapidement aux données agrégées les plus fréquemment demandées, celles-ci doivent être stockées dans l'entrepôt de données plutôt que calculées lors de l'exécution des requêtes.

Métadonnées nécessaire à l'utilisateur pour obtenir des informations sur les données stockées dans l'entrepôt de données. Selon les principes de Zachman, les métadonnées doivent décrire les objets de domaine représentés dans l'entrepôt de données, les utilisateurs travaillant avec les données, les emplacements de stockage des données, les actions sur les données, le temps de traitement des données et les raisons des modifications des données.

L'idée générale derrière les entrepôts de données est de séparer les bases de données OLTP des bases de données analytiques, puis de les concevoir en conséquence. Le concept de stockage de données est discuté d'une manière ou d'une autre par les spécialistes du domaine des systèmes d'information depuis assez longtemps. Les premiers articles consacrés spécifiquement à la MH sont parus en 1988, leurs auteurs étaient B. Devlin et P. Murphy. En 1992, W. Inmon a décrit ce concept en détail dans sa monographie « Building the Data Warehouse », deuxième édition - QED Publishing Group, 1996.

Le concept d'entrepôt de données repose sur l'idée de séparer les données utilisées pour le traitement opérationnel et pour la résolution de problèmes d'analyse. Cela permet d'utiliser des structures de données qui répondent aux exigences de stockage pour une utilisation dans les systèmes OLTP et les systèmes d'analyse. Cette séparation permet d'optimiser à la fois les structures de données de stockage opérationnel (bases de données en ligne, fichiers, feuilles de calcul, etc.) pour effectuer les opérations de saisie, de modification, de suppression et de recherche, et les structures de données utilisées pour l'analyse (pour exécuter des requêtes analytiques). Dans le DSS, ces deux types de données sont appelés respectivement sources de données opérationnelles(OID) et stockage de données. Dans son ouvrage, Inmon a donné la définition suivante du CD.

Stockage des données- un ensemble de données historiques spécifiques à un domaine, intégrées, immuables, organisées à des fins d'aide à la décision.

Ci-dessous, nous donnons une description générale des principales propriétés de HD

Orientation du sujet. C'est la différence fondamentale entre HD et OID.
Différents OID peuvent contenir des données décrivant le même domaine de différents points de vue (par exemple, du point de vue de la comptabilité, de la comptabilité d'entrepôt, du service de planification, etc.). Une décision prise sur la base d’un seul point de vue peut être inefficace, voire incorrecte. Les entrepôts de données vous permettent d'intégrer des informations qui reflètent différents points de vue sur un même domaine. L'orientation sujet vous permet également de stocker dans l'entrepôt de données uniquement les données nécessaires à leur analyse (par exemple, pour l'analyse, il ne sert à rien de stocker des informations sur le nombre de documents de vente et d'achat, tandis que leur contenu - quantité, prix de biens vendus - sont nécessaires). Cela réduit considérablement les coûts des supports de stockage et augmente la sécurité de l'accès aux données.

Intégration. En règle générale, les OID sont développés à des moments différents par plusieurs équipes avec leurs propres outils. Cela conduit au fait que les données reflétant le même objet du monde réel dans différents systèmes le décrivent différemment. L'intégration obligatoire des données dans un entrepôt de données nous permet de résoudre ce problème en mettant les données dans un format unifié.

Prise en charge de la chronologie. Les données de l'OID sont nécessaires pour y effectuer des opérations à l'heure actuelle. Ils ne sont donc peut-être pas limités dans le temps. Pour l’analyse des données, il est souvent important de pouvoir suivre la chronologie des changements dans les indicateurs du domaine. Par conséquent, toutes les données stockées dans l’entrepôt de données doivent correspondre à des intervalles de temps consécutifs.

Immutabilité. Les exigences relatives aux OID imposent des restrictions sur la durée pendant laquelle ils stockent les données. Les données qui ne sont pas nécessaires au traitement opérationnel sont, en règle générale, supprimées de l'OID afin de réduire les ressources consommées. L’analyse, au contraire, nécessite des données sur une période aussi longue que possible. Ainsi, contrairement à l’OID, les données de l’entrepôt de données ne sont lues qu’après chargement. Cela permet d'augmenter considérablement la vitesse d'accès aux données, à la fois grâce à l'éventuelle redondance des informations stockées et en éliminant les opérations de modification.

Lors de la mise en œuvre du concept de stockage de données dans un DSS, les données de différents OID sont copiées dans un seul stockage. Les données collectées sont regroupées dans un format unique, coordonnées et résumées. Les demandes analytiques sont adressées au datawarehouse

Un tel modèle conduit inévitablement à une duplication d’informations dans l’OID et dans l’entrepôt de données.

Lors du chargement dans l'entrepôt de données, les données sont effacées (les informations inutiles sont supprimées) et après ce traitement, elles occupent un volume beaucoup plus petit.

La redondance des informations peut être réduite à zéro à l'aide d'un entrepôt de données virtuel. Dans ce cas, contrairement à un entrepôt de données (physique) classique, les données de l'OID ne sont pas copiées dans un seul stockage. Ils sont extraits, convertis et intégrés directement lors de l'exécution de requêtes analytiques dans la RAM de l'ordinateur. Les principaux avantages du stockage virtuel sont : - la minimisation de la quantité de mémoire occupée par les informations sur le support de stockage et le travail avec des données actuelles et détaillées. Cependant, cette approche présente de nombreux inconvénients. Le temps de traitement des requêtes vers un stockage virtuel dépasse largement les indicateurs correspondants pour le stockage physique. De plus, les structures des bases de données opérationnelles, conçues pour une mise à jour intensive d'enregistrements uniques, sont hautement normalisées. Pour effectuer une requête analytique, un grand nombre de tables doivent être jointes, ce qui entraîne également une diminution des performances.

Exécuter des requêtes analytiques complexes sur des OID nécessite des ressources informatiques importantes. Cela conduit à une diminution des performances des systèmes OLTP, ce qui est inacceptable, car le temps d'exécution des opérations dans de tels systèmes est souvent très critique.

Différents OID peuvent prendre en charge différents formats de données et codages. Souvent, il peut y avoir plusieurs réponses possibles à une même question. Cela peut être dû à la non-synchronisation des moments de mise à jour des données dans différents OID, à des différences dans la description d'objets et d'événements identiques du domaine, à des erreurs de saisie, à la perte de fragments d'archives, etc. Dans ce cas, l'objectif - la formation de une vue unique et cohérente de l'objet de contrôle - peut ne pas être obtenue.

Le principal inconvénient du stockage virtuel est l’impossibilité pratique d’obtenir des données sur une longue période. En l'absence de stockage physique, seules les données qui se trouvent dans l'OID au moment de la demande sont disponibles. L'objectif principal des systèmes OLTP est le traitement rapide des données actuelles, ils ne se concentrent donc pas sur le stockage des données sur une longue période. Lorsque les données deviennent obsolètes, elles sont téléchargées dans les archives et supprimées de la base de données opérationnelle.

Malgré les avantages du stockage physique par rapport au stockage virtuel, il faut reconnaître que sa mise en œuvre est un processus plutôt laborieux. Examinons les principaux problèmes liés à la création d'un entrepôt de données :

La nécessité d'intégrer des données provenant de sources hétérogènes dans un environnement distribué ;

La nécessité d'un stockage et d'un traitement efficaces de très grands volumes d'informations ;

Le besoin de répertoires de métadonnées à plusieurs niveaux ;

Exigences accrues en matière de sécurité des données.
Examinons ces problèmes plus en détail.

À ce jour, de nombreuses organisations ont accumulé des quantités importantes de données, sur la base desquelles il est possible de résoudre divers problèmes d'analyse et de gestion. Les problèmes de stockage et de traitement des informations analytiques deviennent de plus en plus pertinents et attirent l'attention des spécialistes et des entreprises travaillant dans le domaine des technologies de l'information, ce qui a conduit à la formation d'un marché à part entière pour les technologies d'analyse commerciale.

Idéalement, le travail des analystes et des gestionnaires à différents niveaux devrait être organisé de manière à ce qu'ils puissent avoir accès à toutes les informations qui les intéressent et utiliser des moyens pratiques et simples pour présenter et travailler avec ces informations. Les technologies de l'information, réunies sous le nom général d'entrepôts de données et d'analyse commerciale, visent à atteindre ces objectifs.

Telle que définie par Gartner, la business intelligence (BI, Business Intelligence) est une catégorie d'applications et de technologies permettant de collecter, stocker, analyser et publier des données, permettant aux utilisateurs de l'entreprise de prendre de meilleures décisions. Dans la terminologie russe, ces systèmes sont également appelés systèmes d'aide à la décision (DSS).

La collecte et le stockage d'informations, ainsi que la résolution des problèmes de requêtes de recherche d'informations, sont mis en œuvre efficacement à l'aide de systèmes de gestion de bases de données (SGBD). Implémentation des sous-systèmes OLTP (Online Transaction Processing) traitement des transactions données. Les systèmes OLTP eux-mêmes ne sont pas adaptés à une analyse complète des informations en raison des exigences contradictoires des systèmes OLTP et DSS.

Pour fournir les informations nécessaires à la prise de décision, il est généralement nécessaire de collecter des données auprès de plusieurs bases de données transactionnelles structure et contenu différents. Le principal problème ici réside dans l’incohérence et la nature contradictoire de ces bases de données sources ainsi que dans l’absence d’une vision logique unique des données de l’entreprise.

Par conséquent, pour combiner OLTP et DSS dans un seul système afin de mettre en œuvre un sous-système de stockage, le concept d'entrepôts de données (DW) est utilisé. Le concept d'entrepôt de données repose sur l'idée de séparer les données utilisées pour le traitement opérationnel et pour résoudre des problèmes d'analyse, ce qui permet d'optimiser les structures de stockage. La base de données vous permet d'intégrer dans une seule base de données des données détaillées préalablement séparées contenues dans des archives historiques accumulées dans les systèmes OLTP traditionnels provenant de sources externes, en effectuant leur coordination préliminaire et, éventuellement, leur agrégation.

Le sous-système d'analyse peut être construit sur la base de :

sous-systèmes d'analyse de recherche d'informations basés sur des SGBD relationnels et des requêtes statiques utilisant le langage SQL ;
sous-systèmes d’analyse opérationnelle. Pour mettre en œuvre de tels sous-systèmes, la technologie de traitement des données analytiques opérationnelles OLAP est utilisée, en utilisant le concept de représentation de données multidimensionnelles ;
des sous-systèmes d’analyse intelligents qui mettent en œuvre des méthodes et des algorithmes de Data Mining.

Concept d'entrepôt de données

La technologie des entrepôts de données est destinée au stockage et à l'analyse de grands volumes de données dans le but d'en découvrir davantage les modèles cachés et, avec la technologie de Data Mining, est incluse dans le concept d'« analyse prédictive ». Le Data Mining, quant à lui, étudie le processus de recherche de nouvelles connaissances valides et potentiellement utiles dans les bases de données.

La base de données est un ensemble de données historiques spécifiques à un domaine, intégrées et rarement modifiées, organisées à des fins d'aide à la décision. L'orientation sujet signifie que les entrepôts de données intègrent des informations qui reflètent différents points de vue sur le domaine. L'intégration suppose que les données stockées dans l'entrepôt de données soient regroupées dans un format unique. La prise en charge chronologique signifie que toutes les données de l'entrepôt de données correspondent à des intervalles de temps consécutifs.

En plus de la capacité de travailler avec une source unique d'informations, les gestionnaires et les analystes doivent disposer d'outils pratiques pour la visualisation, l'agrégation des données, la recherche de tendances et les prévisions. Malgré la variété des activités analytiques, il est possible d'identifier des technologies standards d'analyse de données, chacune correspondant à un ensemble spécifique d'outils. Associés à l'entrepôt de données, ces outils fournissent une solution complète pour automatiser les activités analytiques et créer des système d'information et d'analyse.

Stockage de données physiques et virtuelles

Lors du chargement de données d'un système OLTP dans un entrepôt de données, une duplication des données se produit. Cependant, lors de ce téléchargement, les données sont filtrées car elles ne sont pas toutes pertinentes pour les procédures d'analyse. L'entrepôt de données stocke des informations généralisées qui ne sont pas disponibles dans le système OLTP.

La redondance des informations peut être réduite à zéro grâce à un entrepôt de données virtuel. Dans un tel système, les données du système OLTP ne sont pas copiées dans un seul stockage. Ils sont extraits, transformés et intégrés directement dans des requêtes analytiques en temps réel. En fait, ces requêtes sont directement transmises au système OLTP.

Avantages du stockage virtuel :

minimiser la quantité de données stockées ;
travailler avec des données actuelles et à jour.

Inconvénients du stockage virtuel :

temps de traitement des demandes plus élevé par rapport au stockage physique ;
la nécessité d'une disponibilité constante de toutes les sources OLTP ;
performances réduites des systèmes OLTP ;
Les systèmes OLTP ne sont pas axés sur le stockage des données sur une longue période ; si nécessaire, les données sont téléchargées dans des archives, il n'est donc pas toujours physiquement possible d'obtenir un ensemble complet de données dans un entrepôt de données.

Notez que l’entreposage de données est une technologie en évolution. Comme pour toute technologie en évolution, une certaine prudence s’impose lors de l’évaluation des actions des fournisseurs de logiciels de stockage de données alors qu’ils tentent de se positionner parmi leurs concurrents. Par exemple, les discussions sur les tailles HD : à partir de quelle taille entrepôt de données Cela peut-il être considéré comme une installation de stockage ? Avec 50 Go ? Notez que dans certains domaines de recherche, la taille du réseau analysé peut être très petite. Il n'y a tout simplement aucune donnée. Mais l’analyse d’un tel tableau est possible.

Examinons les principaux éléments du concept d'entreposage de données.

Extraire des données des systèmes d'exploitation

L'élément principal du concept d'entreposage de données est que l'accès le plus efficace aux données stockées à des fins d'analyse ne peut être fourni que s'il est séparé du système opérationnel (transactionnel), c'est-à-dire les données du système d'exploitation doivent être transférées vers un système de stockage de données. Cette approche est de nature historique. En raison des limitations du matériel et de la technologie, afin de maintenir les performances d'un système transactionnel, les données étaient archivées sur une bande magnétique ou sur un support extérieur à un tel système. Le problème de leur accès nécessitait certaines solutions technologiques.

Il convient de noter qu'avec le développement du concept, la position de séparation des données à analyser des données dans un système OLTP a peu changé. Il est devenu plus formel et enrichi grâce à l’utilisation d’outils d’analyse de données multidimensionnelles. Actuellement, un entrepôt de données peut être construit sur un système OLTP existant, ou par-dessus, ou en tant qu'objet indépendant. Ceci doit être décidé par le chef de projet informatique dans le cadre du choix de l'architecture de stockage des données.

La nécessité d'intégrer les données de plusieurs systèmes OLTP

Systèmes de stockage de données sont particulièrement utiles lorsque les données peuvent être récupérées à partir de plusieurs systèmes OLTP. Lorsque les données doivent être collectées à partir de plusieurs applications métier, il est naturel de supposer que cela doit être effectué dans un emplacement différent de celui où se trouvent les applications sources. Même avant la création d’entrepôts de données structurés, les analystes combinaient dans de nombreux cas les données extraites de différents systèmes dans une seule feuille de calcul ou base de données. Un entrepôt de données peut très efficacement rassembler des données provenant d'applications spécifiques, telles que les ventes, le marketing, la finance, la production, en tenant compte de leur accumulation, c'est-à-dire enregistrer des séries chronologiques d'indicateurs commerciaux clés - ce que l'on appelle les données historiques.

Notez que l’une des propriétés des données collectées à partir de diverses applications et utilisées par les analystes est la possibilité d’interroger ces données de manière croisée. Dans de nombreux entrepôts de données, l'attribut temps est un critère naturel pour filtrer les données. Les analystes s'intéressent au comportement des séries chronologiques de données caractérisant les processus métiers.

L'objectif de beaucoup systèmes de stockage de données est un aperçu des activités année par année. Par exemple, vous pouvez comparer les ventes du premier trimestre de cette année avec les ventes du premier trimestre des années précédentes. Le temps passé en HD est un attribut fondamental requêtes croisées. Par exemple, un analyste peut essayer d'estimer l'impact d'une nouvelle campagne marketing lancée pendant certaines périodes en examinant les ventes au cours de ces mêmes périodes. La capacité d'établir et de comprendre les corrélations entre les activités des différents départements d'une organisation est souvent citée comme l'un des arguments les plus importants en faveur des avantages de systèmes de stockage de données.

Système de stockage de données Non seulement il peut fonctionner comme une plate-forme efficace pour consolider les données provenant de diverses sources, mais il peut également collecter plusieurs versions de données à partir d'une seule application. Par exemple, si une organisation passe à un nouveau logiciel, l'entrepôt de données conservera les données nécessaires du système précédent. À cet égard système de stockage de données peut servir de moyen d'intégration des données héritées, en maintenant la continuité de l'analyse lors du changement de plate-forme logicielle et matérielle du système OLTP.

Différences entre le traitement transactionnel et analytique

L'une des raisons les plus importantes de séparer les données d'analyse des données OLTP était l'impact potentiel sur les performances des requêtes lors de l'exécution des processus d'analyse de données. Des performances élevées et un temps de réponse court sont des paramètres critiques des systèmes OLTP. La perte de performances et la surcharge associées au traitement des requêtes prédéfinies sont généralement faciles à estimer. D'un autre côté, les requêtes d'analyse de données dans un entrepôt de données sont difficiles à prévoir et, par conséquent, il est difficile d'estimer le temps d'exécution des requêtes pour elles.

Les systèmes OLTP sont conçus pour exécuter de manière optimale des requêtes prédéfinies en temps quasi réel. Pour de tels systèmes, il est généralement possible de déterminer la répartition de la charge dans le temps, de déterminer l'heure des charges de pointe, d'évaluer les requêtes critiques et de leur appliquer des procédures d'optimisation prises en charge par les SGBD modernes. Il est également relativement facile de déterminer le temps de réponse maximum autorisé pour une requête particulière dans le système. Le coût du temps de réponse d'une telle requête peut être estimé sur la base du rapport coût d'exécution des opérations d'E/S / coût du trafic réseau. Par exemple, pour un système de traitement des commandes, vous pouvez définir le nombre de gestionnaires de commandes actifs et le nombre moyen de commandes pendant chaque heure de fonctionnement.

Bien que de nombreuses requêtes et rapports dans système de stockage de données sont prédéterminés, il est quasiment impossible de prédire avec précision le comportement des indicateurs système (temps de réponse, trafic réseau, etc.) lors de leur exécution. Le processus de recherche de données dans un entrepôt de données se déroule souvent de manière imprévisible. Les dirigeants de tous rangs savent poser des questions inattendues. Au cours du processus d'analyse, des requêtes ad hoc peuvent survenir en raison de résultats inattendus ou du manque de compréhension de l'utilisateur final du modèle de données utilisé. En outre, de nombreux processus d'analyse ont tendance à prendre en compte de nombreux aspects des activités d'une organisation, tandis que les systèmes OLTP sont bien segmentés par activité. L'utilisateur peut avoir besoin d'informations plus détaillées que celles stockées dans les tableaux récapitulatifs.

Cela pourrait entraîner la jointure de deux ou plusieurs tables volumineuses, ce qui entraînerait la création d'une table temporaire égale au nombre de lignes de chaque table et dégraderait considérablement les performances du système.

Les données dans les systèmes d'entrepôt de données restent inchangées système de stockage de données Une autre propriété clé des données dans est que les données de l'entrepôt de données restent inchangées. Cela signifie qu’une fois les données placées dans l’entrepôt de données, elles ne peuvent plus être modifiées. Par exemple, le statut de la commande ne change pas, la taille de la commande ne change pas, etc. Cette caractéristique de l'entrepôt de données est d'une grande importance pour la sélection des types de données lors de leur placement dans l'entrepôt de données, ainsi que pour le choix du moment où les données doivent être saisies dans l’entrepôt de données. La dernière propriété s'appelle.

granularité des données

Un autre bon exemple serait de placer un instantané de données en constante évolution à certains moments dans un entrepôt de données. Le module de contrôle des stocks d'un système OLTP peut modifier l'inventaire dans presque toutes les transactions ; Il est impossible de saisir toutes ces modifications dans l'entrepôt de données. Vous pouvez déterminer qu'un tel instantané de l'état des stocks doit être saisi dans l'entrepôt de données chaque semaine ou quotidiennement, comme cela sera accepté pour l'analyse dans une organisation particulière. Les données d’un tel instantané sont bien entendu immuables.

Une fois les données saisies dans l’entrepôt de données, une modification est possible dans des cas extrêmement rares. Il est très difficile (bien qu'il existe de telles tentatives) de conserver des données dynamiques dans un entrepôt de données. Tâche de synchronisation les données changent fréquemment dans les systèmes OLTP et sont encore loin d'être une solution acceptable. Il convient également de mentionner ici que le placement de données évoluant de manière dynamique dans un entrepôt de données fait actuellement l'objet de recherches intensives. Par exemple, développer des procédures pour prendre en charge des tables de mesure à évolution lente dans un entrepôt de données est une tâche qui a déjà trouvé sa solution au niveau logiciel des fabricants de solutions de stockage de données.

Les données d'un entrepôt de données sont stockées beaucoup plus longtemps que dans les systèmes OLTP

Les données de la plupart des systèmes OLTP sont archivées dès qu'elles deviennent inactives. Par exemple, une commande peut devenir inactive une fois terminée ; un compte bancaire peut devenir inactif après sa fermeture. La principale raison de l'archivage des données inactives est la performance du système OLTP (pourquoi stocker les données si elles ne sont pas accessibles). De grands volumes de ces données peuvent dégrader considérablement les performances des requêtes, en supposant que seules les données actives sont traitées. Pour traiter ces données, le SGBD propose diverses procédures permettant de diviser les tables de base en sections. En revanche, les entrepôts de données étant notamment destinés à être une archive de données OLTP, les données qu'ils contiennent sont stockées pendant une très longue période.

En fait, le projet systèmes de stockage de données peut commencer sans aucun plan spécifique d’archivage des données de l’entrepôt de données. Le coût de maintenance des données après leur chargement dans le stockage est faible. Les coûts les plus élevés lors de la création d'une installation de stockage incombent transformation des données(transfert de données) et leur nettoyage (nettoyage des données). La conservation des données pendant cinq ans ou plus est typique systèmes de stockage de données. Ainsi, en début de période, vous n'avez pas à consacrer beaucoup de temps aux procédures d'archivage des données d'un entrepôt de données aux étapes de leur création et de leur exploitation. Surtout compte tenu de la baisse des prix du matériel informatique.

En d’autres termes, séparer les données des systèmes OLTP des données des systèmes d’analyse est le concept fondamental de l’entreposage de données. De nos jours, il est impossible de faire des affaires sans prendre des décisions éclairées. De telles décisions peuvent être fondées sur une analyse complète des résultats des processus commerciaux de l’organisation et des activités de l’organisation sur le marché des biens et services. Le temps de prise de décision dans les conditions modernes et les flux d'informations est réduit. Rôle de création et d'accompagnement systèmes d'analyse de données basés sur les nouvelles technologies de l'information se multiplient. La HD est l'un des principaux maillons de l'application de ces technologies.

Les raisons suivantes pour séparer les données peuvent être identifiées : systèmes de stockage de données Et systèmes de traitement de données opérationnels(Fig. 1.5).

Différences dans les exigences cibles pour les systèmes OLTP.
La nécessité de collecter des données dans l'entrepôt de données à partir de diverses sources d'informations, c'est-à-dire si les données sont générées dans le système OLTP lui-même, alors pour systèmes de stockage de données dans la plupart des cas, les données sont générées en externe.
Les données entrant dans l'entrepôt de données restent inchangées dans la plupart des cas.
Les données de l'entrepôt de données sont stockées pendant une longue période.

Riz. 1.5.

Transformation logique des données des systèmes OLTP et modélisation des données

Les données d'un entrepôt de données sont transformées logiquement lorsqu'elles y sont transférées depuis un système OLTP ou une autre source externe. Les problèmes associés à la transformation logique des données lors de leur transfert vers un entrepôt de données peuvent nécessiter une analyse et des efforts importants de la part des concepteurs. Architecture systèmes de stockage de données et les modèles HD sont d'une grande importance pour la réussite de tels projets. Nous aborderons ci-dessous certains concepts fondamentaux de la théorie des bases de données relationnelles qui sont totalement inapplicables à systèmes de stockage de données. Même si la plupart des entrepôts de données sont déployés sur des bases de données relationnelles, certains principes de base des bases de données relationnelles sont délibérément violés lors de la création du modèle logique et physique de l'entrepôt de données.

Le modèle de données d'un entrepôt de données détermine sa structure logique et physique. Contrairement aux données simplement archivées, dans ce cas, il est impossible de se passer de procédures de modélisation détaillées. Une telle modélisation dès les premières étapes d'un projet de système d'entreposage est nécessaire pour créer un système efficace qui couvre les données de tous les processus et procédures métiers de l'organisation.

Le processus de modélisation des données doit structurer les données de l'entrepôt de données sous une forme indépendante du modèle de données relationnel du système qui fournit ces données. Comme nous le verrons ci-dessous, le modèle d'entrepôt de données sera probablement moins normalisé que le modèle du système OLTP - la source de données.

Dans les systèmes OLTP, les données de différents sous-systèmes peuvent se chevaucher de manière significative. Par exemple, les informations sur le développement de produits sont utilisées sous diverses formes dans de nombreux sous-systèmes d'un système OLTP. Système de stockage de données devrait combiner toutes ces données dans un seul système. Certains attributs d'objet essentiels pour un système OLTP seront inutiles pour un entrepôt de données. De nouveaux attributs peuvent apparaître à mesure que l'entité de l'entrepôt de données modifie sa qualité. La principale exigence est que toutes les données de l'entrepôt de données doivent participer au processus d'analyse.

Le modèle de données DW doit être étendu et structuré de manière à pouvoir ajouter des données provenant de diverses applications. Dans la plupart des cas, un projet d'entrepôt de données ne peut pas inclure les données de toutes les applications métier possibles d'une organisation. En règle générale, le volume de données dans un entrepôt de données augmente selon le principe incrémental : les données sont extraites des systèmes OLTP et ajoutées à l'entrepôt de données dans certaines parties. Ils commencent par stocker des données particulièrement significatives, puis augmentent systématiquement leur volume selon les besoins.

Le modèle d'entrepôt de données s'adapte à la structure de l'entreprise

Le prochain point important est que le modèle d'entrepôt de données logique est personnalisé en fonction de la structure de l'entreprise (axée sur le domaine) et non en fonction de l'agrégation de modèles logiques d'applications spécifiques. Les entités (objets) prises en charge dans l'entrepôt de données sont similaires aux entités commerciales (objets) - telles que les clients, les produits (produits), les commandes et les distributeurs. Au sein des divisions spécifiques d'une organisation, il peut exister une vision très étroite des entités commerciales de l'organisation, telles que les clients. Ainsi, l’équipe de gestion des prêts d’une banque ne peut connaître un client que dans le contexte d’un ou plusieurs prêts accordés. Une autre division de la même banque peut connaître le même client dans le contexte compte de dépôt. La présentation des données clients dans l'entrepôt de données est bien supérieure à la présentation similaire d'une division bancaire spécifique. Le client au HD représente le client de la banque dans toutes ses relations avec la banque.

Du point de vue de la théorie relationnelle, l'ensemble de base des dépendances fonctionnelles prises en charge dans la base de données change.

type de processus métier spécifique. Ainsi, dans un sous-système d'approvisionnement automatisé, la structure des données peut être dictée par la nature des procédures commerciales d'approvisionnement dans un secteur de marché donné ;
influence du modèle des systèmes d’exploitation. Par exemple, l'application source peut être assez ancienne et prendre en compte l'évolution du modèle de données en modifiant la structure de la base de données de l'application. Beaucoup de ces changements peuvent être mal documentés ;
limitations de la plate-forme logicielle et matérielle. La structure logique des données peut ne pas prendre en charge certaines relations logiques entre les données ou peut présenter des limitations dues aux limitations de la plate-forme logicielle et matérielle.

Le modèle DW n'est pas associé aux limitations des modèles de données sources. Pour cela, un modèle doit être développé qui reflète la structure des activités de l'organisation, et non la structure du processus commercial. Tel modèle étendu les données doivent être compréhensibles à la fois par les analystes et les gestionnaires. Ainsi, le concepteur d'entrepôt de données doit configurer les objets de stockage de données en fonction de la structure commerciale de l'organisation, en tenant compte de ses processus métier et de ses procédures métier.

Transformation des informations décrivant l'état des objets dans un système OLTP

Le prochain point important est qu'avant de placer les données dans l'entrepôt de données, elles doivent être converties. La plupart des données provenant d'un système OLTP ou d'une autre source externe ne peuvent pas être prises en charge dans l'entrepôt de données. De nombreux attributs d'objet dans un système OLTP sont très dynamiques et en constante évolution. Beaucoup de ces attributs ne sont pas chargés dans l'entrepôt de données, tandis que d'autres attributs sont statiques dans le temps et sont chargés dans l'entrepôt de données. L'entrepôt de données ne doit contenir aucune information sur des objets dynamiques et constamment en état de modification.

Pour comprendre ce que signifie perdre des informations décrivant l'état actuel d'un article, prenons l'exemple d'un système de gestion des commandes qui suit l'état des stocks au fur et à mesure qu'une commande est exécutée. Tout d'abord, regardons l'entité « Commande » dans un système OLTP. Une commande peut passer par de nombreux statuts ou états différents avant d'être finalisée et d'atteindre statut terminé. Le statut de la commande peut indiquer qu'elle est prête à être exécutée, que la commande est en cours d'exécution, renvoyée pour révision, prête à être expédiée, etc. Une commande spécifique peut passer par de nombreux états, qui sont reflétés dans le statut de la commande et déterminés par les processus métier qui lui ont été appliqués. Il est quasiment impossible de transférer tous les attributs d'un tel objet vers l'entrepôt de données. Système de stockage de données ne devrait probablement contenir qu'un seul instantané final d'un objet tel qu'une commande.

Ainsi, l'objet « Commande » doit être converti pour être placé dans l'entrepôt de données. Ensuite, l'entrepôt de données peut collecter des informations sur de nombreux objets du type « commande » et créer l'objet final de l'entrepôt de données – « Commande ». Regardons un exemple plus complexe transformation des données lors de la gestion de l'inventaire des produits dans un système OLTP. Le stock peut changer à chaque transaction. La quantité d'un produit spécifique dans l'entrepôt peut être réduite par une transaction du sous-système de traitement des commandes ou augmentée à la réception du produit acheté. Si un système de traitement des commandes traite des dizaines de milliers de transactions par jour, il est probable que le niveau de stock réel dans la base de données aura de nombreux états et sera capturé dans de nombreux instantanés au cours de cette journée. Il est impossible de capturer tous ces changements constants dans la base de données et de les transférer vers l'entrepôt de données. Afficher un tel comportement d'un objet dans le système - la source de données est toujours l'un des problèmes non résolus dans systèmes de stockage de données

. Il existe plusieurs approches pour résoudre ce problème. Par exemple, vous pouvez enregistrer périodiquement des instantanés des niveaux de stock dans l'entrepôt de données.

Cette approche peut être appliquée à une très grande partie des données des systèmes OLTP. À son tour, une telle décision entraînera un certain nombre de tâches liées au choix de la période, du volume de données collectées, etc. Ainsi, la plupart des données sur l'état des objets dans le système OLTP ne peuvent pas être directement transférées vers l'entrepôt de données. Ils doivent être convertis au niveau logique.

Dénormalisation du modèle de données Le point suivant dans la conception d'entrepôts de données relationnels est de décider dans quelle mesure il est important de respecter les principes de la théorie relationnelle dans l'entrepôt de données, à savoir : permettre la dénormalisation du modèle, notamment pour augmenter les performances des requêtes. Avant d'aborder la dénormalisation du modèle de données dans le contexte de l'entreposage de données, rappelons brièvement les principaux points de la théorie des bases de données relationnelles et. E.F. Codd a développé la théorie des bases de données relationnelles à la fin des années 1960 alors qu'il travaillait au IBM Research Center. Aujourd’hui, les plateformes de bases de données les plus populaires suivent entièrement ce modèle. Un modèle de base de données relationnelle est une collection de tables bidimensionnelles composées de lignes et de colonnes. Dans la terminologie des modèles relationnels, ces tables, lignes et colonnes sont respectivement appelées relations ou entités, tuples, attributs et domaines.

Le modèle identifie les clés uniques (Clés) pour toutes les tables et décrit les relations entre les tables via des valeurs d'attribut (clés).

La normalisation est le processus de modélisation d'une base de données relationnelle dans laquelle les relations ou les tables sont décomposées jusqu'à ce que tous les attributs d'une relation soient complètement déterminés par sa clé primaire. La plupart des concepteurs tentent d'obtenir une troisième forme normale (3NF) sur toutes les relations avant qu'elles ne soient dénormalisées pour une raison ou une autre. Les trois étapes séquentielles de la normalisation des bases de données relationnelles sont brièvement décrites ci-dessous.
Première forme normale 1NF (1NF). Une relation est dite sous sa première forme normale si elle décrit une seule entité et ne contient pas de tableaux ou de groupes répétitifs de valeurs comme attributs. Par exemple, une table de commandes qui inclut des éléments de commande ne sera pas dans sa première forme normale car elle contient des attributs en double pour chaque élément de commande. Deuxième forme normale 2NF (2NF). Ils disent que la relation est en deuxième forme normale , s'il est sous sa première forme normale et que tous les attributs non clés dépendent entièrement fonctionnellement de.
clé primaire de la relation Troisième forme normale 3NF (3NF). Ils disent que la relation est en troisième forme normale 2NF (2NF). Ils disent que la relation est en, si c'est dans

et ses attributs non clés sont complètement indépendants les uns des autres.

Une autre raison de dénormaliser le modèle de stockage des données est, tout comme pour les systèmes d'exploitation, la performance et la simplicité. Chaque requête dans une base de données relationnelle a son propre rapport coût/performance. Le coût d'exécution des requêtes est très élevé dans un entrepôt de données en raison de la quantité de données traitées dans la requête (et des jointures inter-tables dont le nombre augmente proportionnellement à la dimension du modèle). Joindre trois petites tables dans un système OLTP peut avoir un coût de requête acceptable, mais système de stockage de données Cette connexion peut prendre beaucoup de temps.

Relations statiques dans les données historiques

La dénormalisation est un processus important dans la modélisation des entrepôts de données : les relations entre les attributs ne changent pas pour les données historiques. Par exemple, dans les systèmes OLTP, un produit peut faire partie d'un autre produit du groupe « A » ce mois-ci et d'un produit du groupe « B » le mois prochain. Dans un modèle de données normalisé, pour afficher ce fait, il faut inclure l'attribut « groupe de produits » dans la relation « produit » (entité), mais pas dans la relation « commande » (entité), qui génère les commandes pour ce produit. . Seul l'identifiant du produit est repris dans l'entité "commande". La théorie relationnelle nécessiterait une jointure entre les tables Commande et Produit pour définir le groupe de produits et d'autres attributs de ce produit.

Ce fait (dépendance fonctionnelle) n'a pas d'importance pour l'entrepôt de données, puisque les données stockées concernent des commandes déjà exécutées, c'est-à-dire l'appartenance du produit au groupe est déjà fixée (en fait, la dépendance fonctionnelle spécifiée n'est pas prise en charge). Même si un article appartenait à différents groupes à des moments différents, la relation entre le groupe d'articles et l'article de chaque commande individuelle est statique. Il ne s’agit donc pas d’une dénormalisation du stockage des données. Dans ce cas, la dépendance fonctionnelle du système OLTP n'est pas utilisée dans l'entrepôt de données. Comme autre exemple, prenons le prix d’un produit. Les prix dans le système OLTP peuvent changer constamment. Certaines modifications de ces prix peuvent être transférées à l'entrepôt de données, sous forme d'instantanés périodiques du tableau « Prix du produit ». Dans le HD, l'historique de la liste de prix des produits est enregistré et est déjà lié aux commandes, c'est-à-dire Il n'est pas nécessaire de déterminer dynamiquement la liste de prix lors du traitement d'une commande car elle a déjà été appliquée à la commande enregistrée. Dans les bases de données relationnelles, il est plus facile de maintenir des relations dynamiques entre les entités commerciales, tandis que la base de données contient des relations entre entités de domaine

Le concept de transformation logique des données d'application source évoqué ci-dessus nécessite un certain effort de mise en œuvre et est très utile lors du développement d'un entrepôt de données.

Transformation physique des données d'application source

Un point important dans lors de la gestion de l'inventaire des produits dans un système OLTP. Le stock peut changer à chaque transaction. La quantité d'un produit spécifique dans l'entrepôt peut être réduite par une transaction du sous-système de traitement des commandes ou augmentée à la réception du produit acheté. Si un système de traitement des commandes traite des dizaines de milliers de transactions par jour, il est probable que le niveau de stock réel dans la base de données aura de nombreux états et sera capturé dans de nombreux instantanés au cours de cette journée. Il est impossible de capturer tous ces changements constants dans la base de données et de les transférer vers l'entrepôt de données. Afficher un tel comportement d'un objet dans le système - la source de données est toujours l'un des problèmes non résolus dans est la transformation physique des données. Ces procédures dans l'entreposage de données sont connues sous le nom de processus de nettoyage des données, de transfert de données ou de purge des données. Le processus de nettoyage des données est le plus intensif et le plus long de tout projet d'entrepôt de données. La transformation physique implique l'utilisation de termes de domaine de données standard et de normes de données. Au cours du processus de transformation physique, les données sont localisées dans un fichier intermédiaire avant d'être saisies dans l'entrepôt de données. Lorsque les données sont collectées à partir de nombreuses applications, leur intégrité peut être vérifiée lors du processus de génération des données transformées avant leur chargement dans l'entrepôt de données.

Termes et noms attributs d'entité, utilisés dans les systèmes OLTP, lors du processus de conversion des données pour un entrepôt de données, sont convertis en termes universels et standard acceptés pour un domaine d'activité donné. Les applications peuvent utiliser des abréviations ou des termes difficiles à comprendre pour de nombreuses raisons différentes. La plate-forme matérielle et logicielle peut limiter la longueur et le format des noms, et les applications métier peuvent utiliser des termes communs dans tous les domaines. Dans un entrepôt de données, il est nécessaire d'utiliser des termes métier standard compréhensibles par eux-mêmes pour la plupart des utilisateurs.

L'identifiant du client (acheteur) dans un système OLTP peut être appelé « Purchase », « purchase_id » ou « purchase_no ». En outre, différentes applications de tels systèmes peuvent utiliser des noms (synonymes) différents pour faire référence au même attribut d'entité. Le concepteur DW choisit un terme commercial standard simple tel que « ID client ». Alors les noms attributs d'entité des systèmes d'alimentation doivent être unifiés pour une utilisation en HD.

Différents sous-systèmes des systèmes OLTP et sources de données externes peuvent utiliser différentes définitions de domaines d'attributs sur le physique. niveau de présentation des données. Ainsi, un attribut du type « identifiant de produit » dans un système a une longueur de 12 caractères et dans un autre de 18 caractères. D'un autre côté, certains systèmes existants peuvent avoir des restrictions sur la définition de la longueur des noms d'attributs et un ensemble médiocre de types pour définir les domaines, tandis que d'autres peuvent ne pas avoir de telles restrictions et peuvent fournir une large sélection de types d'attributs.

Lors de la définition des attributs dans un modèle d'entrepôt de données physique, il est nécessaire d'utiliser des longueurs et des types de données lors de la définition du domaine d'attributs qui permettraient de prendre en compte à la fois les exigences du domaine et les capacités des systèmes de source de données. La définition des normes de domaine pour un entrepôt de données est l'une des tâches importantes des concepteurs d'entrepôts de données. Les règles de conversion des domaines attributaires des systèmes de sources de données en domaines attributaires DW doivent être enregistrées dans les métadonnées DW.

Tous les attributs de l'entrepôt de données doivent utiliser systématiquement des valeurs prédéfinies. Différentes applications peuvent avoir des conventions différentes pour les valeurs d'attribut prédéfinies. Ces valeurs prédéfinies incluent des valeurs par défaut, des valeurs qui remplacent les valeurs nulles, etc. Par exemple, le sexe dans différents systèmes peut avoir des valeurs différentes : dans certains, ce sont les valeurs symboliques « M » et « F », dans d'autres il s'agit des valeurs numériques 0 et 1. Un exemple plus gênant est celui où une seule valeur de données est utilisée à plusieurs fins dans une application, par ex. l'attribut représente en fait plusieurs significations. Par exemple, lorsque dans l'attribut « type de méthode de mesure », les deux premiers chiffres indiquent la méthode de mesure, et les deux seconds indiquent la méthode de contrôle physique de la mesure. Ces valeurs différentes doivent être converties en la valeur prédéfinie acceptée dans l'entrepôt de données avant d'être chargées dans l'entrepôt de données.

Dans certains systèmes de sources de données, des valeurs peuvent manquer (le problème des valeurs manquantes, "données manquantes") ou leur transformation ne peut pas être effectuée ("données corrompues" - données pour lesquelles la transformation ne peut pas être effectuée). Il est important que pendant le processus de transformation, ces données prennent des valeurs dans l'entrepôt de données qui permettraient aux utilisateurs de les interpréter correctement. Certains attributs peuvent simplement se voir attribuer une valeur par défaut raisonnable en cas de valeurs manquantes ou de conflits de conversion, et d'autres attributs peuvent se voir attribuer des valeurs à partir des valeurs d'autres attributs. Par exemple, supposons que dans l'entité « Commande », la valeur de l'attribut d'unité de produit soit manquante. Cette valeur peut être obtenue à partir de l'attribut correspondant de l'entité Item de ce système source. Certains attributs n'ont pas de valeurs par défaut appropriées lorsque leurs valeurs sont manquantes.

Pour ces valeurs manquantes, l'entrepôt de données doit également définir une valeur par défaut, par exemple une valeur nulle.

Selon Forrester Research, la plupart des grandes entreprises sont confrontées au problème suivant : elles accumulent une énorme quantité d’informations qui ne sont jamais utilisées. Presque toutes les organisations exploitent en réalité une variété de systèmes transactionnels axés sur le traitement des données opérationnelles (chacun pour une classe spécifique de tâches) et réapprovisionnant continuellement de nombreuses bases de données. En outre, les entreprises possèdent souvent d'énormes quantités d'informations stockées dans ce qu'on appelle. systèmes existants. Toutes ces données sont distribuées sur des réseaux d'ordinateurs personnels et stockées sur des ordinateurs centraux, des postes de travail et des serveurs. Ainsi, l’information existe, mais elle est dispersée, incohérente, non structurée, souvent redondante et pas toujours fiable. Par conséquent, dans la plupart des organisations, ces données ne peuvent toujours pas être utilisées pour prendre des décisions commerciales critiques. Le concept de Data Warehouse vise à résoudre cette contradiction.

Bill Inmon, à l'origine du concept, dans son article classique « What are Data Warehouses » (D2K Incorporated, 1996) définit les entrepôts de données comme « des ensembles de données orientés domaine, intégrés, immuables et historiquement maintenus, organisés dans le but de soutenir la gestion ». .» Il considère les référentiels comme « la seule et unique source de vérité », le « centre de l'univers » des systèmes d'aide à la décision (DSS). « À partir des entrepôts de données, écrit-il, les informations circulent vers différents services, filtrées conformément aux paramètres DSS spécifiés. Ces bases de données de prise de décision individuelle sont appelées data marts.

Le concept d'entrepôts de données repose sur l'idée de combiner des données d'entreprise dispersées dans des systèmes de traitement de données opérationnels, des archives historiques et d'autres sources externes. Ces sources peuvent contenir des données qui ne sont pas utilisées directement dans l'ODS, mais qui sont vitales pour le DSS : cadre législatif (y compris prévisions fiscales), plans de développement industriel, données statistiques, ouvrages de référence électroniques. Comme le montre la pratique, une décision prise sur la base uniquement de données internes s'avère le plus souvent incorrecte.

Le concept d'entrepôt de données a pour objectif de clarifier les différences dans les caractéristiques des données dans les systèmes opérationnels et analytiques, de déterminer les exigences relatives aux données placées dans l'entrepôt, de déterminer les principes généraux et les étapes de sa construction, les principales sources de données , pour fournir des recommandations pour résoudre les problèmes potentiels qui surviennent lors de leur déchargement et de leur nettoyage, de leur approbation, de leur transport et de leur chargement dans la base de données de stockage cible.

Comparaison des caractéristiques des données dans les systèmes d'information axés sur le traitement des données opérationnelles et analytiques

Caractéristiques	Fonctionnement	Analytique
Taux de rafraîchissement	Haute fréquence, petites portions	Basse fréquence, grandes portions
Sources de données	Principalement interne	Principalement externe
Volumes de données stockées	Des centaines de mégaoctets, des gigaoctets	Gigaoctets et téraoctets
L’ère des données	En cours (pour une durée de plusieurs mois à un an)	Actuel et historique (sur une période de plusieurs années, décennies)
But	Enregistrement, recherche en ligne et transformation des données	Stockage de données historiques détaillées et agrégées, traitement analytique, prévision et modélisation

Exigences de base pour les données dans un entrepôt de données

Orientation du sujet	Toutes les données sur un certain sujet (objet métier) sont collectées (généralement à partir de nombreuses sources différentes), nettoyées, coordonnées, complétées, agrégées et présentées sous une forme unique, pratique pour une utilisation dans l'analyse commerciale.
Intégration	Toutes les données sur les différents objets métier sont mutuellement cohérentes et stockées dans un seul stockage d'entreprise.
Immutabilité	Les données originales (historiques), après avoir été convenues, vérifiées et saisies dans le stockage de l'entreprise, restent inchangées et sont utilisées exclusivement en mode lecture.
Prise en charge de la chronologie	Les données sont structurées chronologiquement et reflètent l'historique sur une période de temps suffisante pour effectuer des tâches d'analyse commerciale et de prévision.

Le sujet du concept d'entrepôt de données n'est pas l'analyse des données, mais les données elles-mêmes, c'est-à-dire le concept de préparation pour une analyse plus approfondie. Dans le même temps, le concept d’entrepôt de données ne définit pas seulement une vue logique unique des données d’entreprise, mais la mise en œuvre d’une seule source de données intégrée.

Modèles d'analyse de données

Malgré le fait que le concept d'entreposage de données formulé par B. Inmon met l'accent sur les données elles-mêmes et identifie leurs propriétés, caractéristiques et relations les plus courantes, il est clair que ces données doivent être utilisées dans le processus de prise de décisions commerciales. niveaux, jusqu'aux entreprises et interentreprises. À ce jour, deux principaux modèles d'analyse de données ont émergé historiquement, sur lesquels sont basés les DSS analytiques existants :

1. Analyse statique (DSS). Le concept même de DSS (Decision Support Systems) se traduit en fait par DSS. Jusqu’à récemment, c’était le seul concept analytique. Le résultat du travail de tels systèmes était des rapports de plusieurs pages strictement réglementés, dont la génération nécessitait de longues requêtes traitant d'énormes quantités de données. De telles demandes peuvent prendre plusieurs heures, parfois des dizaines d'heures, voire des jours.

2. Analyse des données en ligne (OLAP). L'auteur du concept OLAP (On-Line Analytical Processing) est le Dr E. Codd, qui a formulé en 1993 12 exigences de base pour les outils de mise en œuvre OLAP. La différence fondamentale entre ce modèle et le DSS statique traditionnel réside dans la représentation conceptuelle des données sous la forme d'un cube multidimensionnel. Parallèlement, E. Codd a montré les limites potentielles de l’approche relationnelle dans les systèmes axés sur l’analyse des données. Le but de la création de ce concept était la possibilité fondamentale de fournir à l'utilisateur final les moyens de générer, traiter et exécuter des requêtes analytiques ad hoc avec un temps de réponse système minimal. La nécessité de l'émergence de ce nouveau concept était prédéterminée par le fait que souvent, après avoir reçu un rapport standard utilisant les outils DSS, l'analyste se posait une nouvelle question ou se rendait compte que la question elle-même était mal formulée. En conséquence, il a de nouveau dû attendre longtemps pour recevoir le résultat suivant afin de pouvoir éventuellement revenir à la prochaine itération de ce processus.

Comparaison des caractéristiques d'analyse statique et dynamique

Caractéristiques	Analyse statique	Analyse dynamique
Types de questions	Combien? Comment? Quand?	Pourquoi? Que se passera-t-il si... ?
Temps de réponse	Non réglementé
Opérations typiques	Rapport réglementé, schéma	Séquence de rapports interactifs, de diagrammes, de formulaires d'écran. Changement dynamique des niveaux d'agrégation et des tranches de données.
Niveau d'exigences analytiques
Type de formulaires d'écran	Principalement prédéterminé, réglementé	Défini par l'utilisateur
Niveau d'agrégation des données	Détaillé et résumé	Principalement totale
L’ère des données	Historique et actuel	Historique, actuel et projeté
Types de demandes	Surtout prévisible	Imprévisible, au cas par cas
But	Traitement analytique réglementé	Analyse, modélisation et prévision multifonctionnelles

Aujourd'hui, la direction OLAP est peut-être la plus prometteuse pour résoudre les problèmes de gestion analytique. Grâce aux outils du service OLAP Report spécialement créé, les 12 exigences initialement formulées par le Dr Codd ont été partiellement révisées et considérablement complétées par des capacités de base et spéciales, telles que la sélection et le traitement des données manquantes, etc. Le concept OLAP est toujours la présentation multidimensionnelle des données au niveau conceptuel.

Marts de données

Selon la définition classique, un data mart est un sous-ensemble d'un entrepôt de données qui reflète les spécificités d'un service (objet métier) et offre des performances accrues. Ainsi, la vitrine est le maillon sur lequel s’appuie un système analytique spécifique pour résoudre son ensemble de problèmes. Néanmoins, il est possible qu'un certain domaine d'activité d'une entreprise ne soit pratiquement pas corrélé avec d'autres, et il est possible de construire un magasin de données correspondant de manière autonome, sans référence à un stockage d'entreprise. Ensuite, la vitrine sera réapprovisionnée avec des données directement provenant des systèmes opérationnels de traitement des transactions. De tels datamarts sont dits indépendants, contrairement aux datamarts classiques qui dépendent de l'entrepôt de données et sont réapprovisionnés à partir de celui-ci.

Dans certains cas, il peut être judicieux de déployer un datamart au lieu d’un entrepôt entièrement constitué. Les data marts sont moins exigeants, moins chers et plus faciles à construire, et sont basés sur des serveurs moins coûteux plutôt que sur des systèmes multiprocesseurs. Avec cette approche, il n'est pas nécessaire d'impliquer l'ensemble du système d'information de l'entreprise et de maintenir des procédures complexes pour mettre à jour de manière synchrone le datamart lors de la mise à jour du stockage. Dans le même temps, il est nécessaire de comprendre qu'avec cette approche, les data marts peuvent se multiplier en complexes entiers de bases de données d'informations indépendantes, et naturellement la tâche de gérer les stratégies individuelles de recherche, de maintenance et de récupération sera fixée. D’un autre côté, la création d’un entrepôt d’entreprise unique basé sur plusieurs datamarts indépendants est bien plus rentable que de s’appuyer sur des données dispersées dans les systèmes de traitement des transactions.

Alors, qu’est-ce qui a du sens : un référentiel unique, des data marts autonomes, un référentiel avec des marts dépendants ou d’autres options ? Il n’existe pas de réponse universelle à la question de la nécessité d’utiliser l’une ou l’autre option. Dans chaque cas, l'option optimale est déterminée par les exigences de l'entreprise, l'intensité de la demande, l'architecture du réseau, la vitesse de réponse requise et d'autres conditions.

Technologie de mise en œuvre d'entrepôts de données

Lors de la création d’un entrepôt de données, il est naturel de suivre une approche de conception incrémentale. Bien qu'aucune description du processus de création d'un entrepôt de données sous la forme d'une séquence de phases ne puisse couvrir tous les aspects des commentaires des utilisateurs potentiels, des gestionnaires et des analystes, certaines étapes de base s'appliquent au processus d'architecture d'entreprise :

1. Déterminez les besoins des utilisateurs finaux et créez un modèle de questions commerciales auxquelles il faut répondre.

2. Identifiez les données provenant de sources d'entreprise et externes qui alimenteront l'entrepôt de données ou le data mart.

3. Analysez les sources de données et modélisez les fonctions et les processus couverts par ces sources. La maîtrise des règles de fonctionnement d'une entreprise est l'une des conditions les plus importantes pour construire des entrepôts de données ou des data marts, puisque c'est sur cette base que s'établit le niveau de détail des éléments de l'entrepôt de données.

4. Définir les procédures de transformation, de nettoyage et d'intégration logique des données sources avant de les placer dans un entrepôt ou un data mart, ainsi que réglementer la mise en œuvre de ces procédures qui mettent à jour l'entrepôt de données.

5. Création de métadonnées décrivant les sources et méthodes de transformation des données et la logique de l'entrepôt de données. Le référentiel de métadonnées doit inclure des définitions de données, des règles métier et une logique détaillée pour modéliser le développement de systèmes d'analyse.

6. Formation des tableaux physiques de l'entrepôt de données et son remplissage. Ce processus peut nécessiter plusieurs itérations pour tenir compte d'une éventuelle refonte des structures de données lors de l'analyse du schéma de données de l'entrepôt.

7. Construction d'un référentiel de datamarts, qui comprendra des sous-ensembles de données de l'entrepôt et des données pré-agrégées. Certaines métadonnées décriront comment les données brutes de l'entrepôt sont transformées, agrégées et mises en cache dans des data marts.

8. Installation d'outils OLAP, de systèmes d'application, de serveurs Web et de tous les outils et programmes serveur nécessaires pour l'accès aux données, l'analyse et la création de rapports.

9. Installation sur les postes de travail des utilisateurs finaux de logiciels clients (client « lourd ») ou de navigateurs prenant en charge les formats de données standards et les applets Java, ainsi que des extensions de plug-in nécessaires (client « léger ») pour l'accès des utilisateurs aux données.

Une fois le processus de création de l’entrepôt de données terminé, il peut sembler que tout est déjà fait. En fait, la constitution d'un entrepôt est un processus qui comprend également les phases nécessaires de supervision et de maintenance continues de l'entrepôt de données. Une surveillance correcte implique non seulement de maintenir l'exactitude des données, mais également de garantir leur confidentialité, en particulier si l'accès aux données stockées se fait via le Web. « Parce que l'entrepôt de données contient certaines des plus grandes valeurs d'une entreprise », déclare R. Tenler, président d'Information Advantage, « les données doivent être sécurisées. Mais pour réaliser la valeur potentielle d’un entrepôt de données, une organisation devra le commercialiser auprès d’acheteurs potentiels.

Maintenir un entrepôt de données en bon état sur une longue période est une autre tâche essentielle. Ce facteur devient particulièrement important lorsque le nombre d'utilisateurs accédant au système commence à augmenter. Cependant, même si le processus de conception d'un entrepôt de données par les services d'information implique généralement une réconciliation minutieuse des données, avec le temps, l'attention des gens diminue généralement et l'entrepôt de données peut se transformer en une décharge. Pour éviter que cela ne se produise, il est nécessaire de nommer des personnes responsables du maintien de la qualité des données, qui vérifieront en permanence les informations provenant des systèmes de traitement des transactions avec les données de l'entrepôt ou de la vitrine.

En conclusion, le processus de conception d’un entrepôt de données utilisé pour fournir les informations nécessaires au processus décisionnel d’entreprise et inter-entreprises est essentiel à la vie de l’entreprise. Au stade de sa mise en œuvre, il est nécessaire de prêter attention non seulement à la résolution des problèmes techniques, mais également aux problèmes liés au facteur humain. Il ne faut pas non plus oublier la nécessité d'évaluer en permanence la faisabilité des efforts déployés. En plus d'une bonne chaîne de gestion de projet, il est nécessaire de prendre en compte à chaque étape à la fois les besoins des utilisateurs et la présence d'aspects politiques qui peuvent ralentir le projet. Avec une approche compétente pour résoudre ce problème, un entrepôt de données peut bientôt faire partie d'un système d'entreprise commerciale en offrant à certains utilisateurs tiers, moyennant des frais, la possibilité d'utiliser les données d'un certain sous-ensemble de l'entrepôt. Cette approche permettra non seulement de récupérer le travail de création d'un entrepôt de données, mais fournira également un nouveau canal de revenus.