Dans l'article précédent, j'ai parlé des bases de DATA VAULT, décrit les principaux éléments de DATA VAULT et leur objectif. Cela ne peut pas être considéré comme épuisé le sujet de DATA VAULT ; il est nécessaire de parler des prochaines étapes de l'évolution de DATA VAULT.
Et dans cet article je me concentrerai sur le développement de DATA VAULT et le passage à BUSINESS DATA VAULT ou simplement BUSINESS VAULT.
Raisons de l’apparition de BUSINESS DATA VAULT
Il convient de noter que DATA VAULT, tout en présentant certains atouts, n’est pas sans inconvénients. L'un de ces inconvénients est la difficulté d'écrire des requêtes analytiques. Les requêtes comportent un nombre important de JOIN, le code est long et fastidieux. De plus, les données entrant dans DATA VAULT ne subissent aucune transformation, donc, d'un point de vue commercial, DATA VAULT dans sa forme pure n'a aucune valeur absolue.
C'est pour éliminer ces lacunes que la méthodologie DATA VAULT a été élargie avec des éléments tels que :
- Tableaux PIT (point dans le temps) ;
- tables PONT;
- DÉRIVÉES PRÉDÉFINIES.
Examinons de plus près le but de ces éléments.
Tableaux PIT
En règle générale, une entité commerciale (HUB) peut contenir des données avec des taux de mise à jour différents. Par exemple, si nous parlons de données caractérisant une personne, nous pouvons dire que les informations sur un numéro de téléphone, une adresse ou un e-mail ont un taux de mise à jour plus élevé que, par exemple, nom complet, détails du passeport, état civil ou sexe.
Par conséquent, lors de la détermination des satellites, vous devez garder à l’esprit leur fréquence de mise à jour. Pourquoi c'est important?
Si vous stockez des attributs avec des taux de mise à jour différents dans la même table, vous devrez ajouter une ligne au tableau à chaque fois que l'attribut le plus fréquemment modifié est mis à jour. Le résultat est une augmentation de l'espace disque et une augmentation du temps d'exécution des requêtes.
Maintenant que nous avons divisé les satellites par fréquence de mise à jour et que nous pouvons y charger des données indépendamment, nous devons nous assurer que nous pouvons recevoir des données à jour. Mieux, sans utiliser de JOIN inutiles.
Laissez-moi vous expliquer, par exemple, vous devez obtenir des informations actuelles (selon la date de la dernière mise à jour) à partir de satellites qui ont des taux de mise à jour différents. Pour ce faire, vous devrez non seulement faire un JOIN, mais aussi créer plusieurs requêtes imbriquées (pour chaque satellite contenant des informations) avec la sélection de la date maximale de mise à jour MAX (Update Date). A chaque nouveau JOIN, ce code s'agrandit et devient très vite difficile à comprendre.
La table PIT est conçue pour simplifier ces requêtes ; les tables PIT sont remplies simultanément avec l'écriture de nouvelles données dans le DATA VAULT. Tableau PIT :
Ainsi, nous disposons d'informations sur la pertinence des données pour tous les satellites à chaque instant. En utilisant les JOINs à la table PIT, nous pouvons éliminer complètement les requêtes imbriquées, naturellement à condition que le PIT soit rempli chaque jour et sans lacunes. Même s'il y a des lacunes dans le PIT, vous ne pouvez obtenir les dernières données qu'en utilisant une seule requête imbriquée vers le PIT lui-même. Une requête imbriquée sera traitée plus rapidement que les requêtes imbriquées sur chaque satellite.
PONT
Les tables BRIDGE sont également utilisées pour simplifier les requêtes analytiques. Cependant, ce qui diffère du PIT, c'est un moyen de simplifier et d'accélérer les requêtes entre les différents hubs, liaisons et leurs satellites.
Le tableau contient toutes les clés nécessaires pour tous les satellites, qui sont souvent utilisées dans les requêtes. De plus, si nécessaire, les clés métier hachées peuvent être complétées par des clés sous forme de texte si les noms des clés sont nécessaires à l'analyse.
Le fait est que sans utiliser BRIDGE, dans le processus de réception de données situées dans des satellites appartenant à différents hubs, il faudra faire un JOIN non seulement des satellites eux-mêmes, mais aussi des liaisons reliant les hubs.
La présence ou l'absence de BRIDGE est déterminée par la configuration du stockage et la nécessité d'optimiser la vitesse d'exécution des requêtes. Il est difficile de trouver un exemple universel de BRIGE.
DÉRIVÉES PRÉDÉFINIES
Un autre type d'objet qui nous rapproche du BUSINESS DATA VAULT sont les tableaux contenant des indicateurs pré-calculés. De tels tableaux sont très importants pour les entreprises : ils contiennent des informations agrégées selon des règles données et les rendent relativement faciles d'accès.
Sur le plan architectural, les DÉRIVATIONS PRÉDÉFINIES ne sont rien de plus qu'un autre satellite d'un certain hub. Comme un satellite ordinaire, il contient une clé commerciale et la date de création de l'enregistrement dans le satellite. Mais c’est là que s’arrêtent les similitudes. La composition ultérieure des attributs d'un tel satellite « spécialisé » est déterminée par les utilisateurs professionnels sur la base des indicateurs pré-calculés les plus populaires.
Par exemple, un hub contenant des informations sur un employé peut inclure un satellite avec des indicateurs tels que :
- Salaire minimum;
- Salaire maximum ;
- Salaire moyen;
- Total cumulé des salaires accumulés, etc.
Il est logique d'inclure des DÉRIVATIONS PRÉDÉFINIES dans la table PIT du même hub, vous pourrez alors facilement obtenir des tranches de données pour un employé à une date spécifiquement sélectionnée.
CONCLUSIONS
Comme le montre la pratique, l'utilisation de DATA VAULT par les utilisateurs professionnels est quelque peu difficile pour plusieurs raisons :
- Le code de requête est complexe et fastidieux ;
- L'abondance des JOIN affecte les performances des requêtes ;
- L'écriture de requêtes analytiques nécessite une connaissance exceptionnelle de la conception du stockage.
Pour simplifier l'accès aux données, DATA VAULT est étendu avec des objets supplémentaires :
- Tableaux PIT (point dans le temps) ;
- tables PONT;
- DÉRIVÉES PRÉDÉFINIES.
Suivant J'ai l'intention de raconter, à mon avis, la chose la plus intéressante pour ceux qui travaillent avec BI. Je présenterai des façons de créer des tables de faits et des tables de dimensions basées sur DATA VAULT.
Les matériaux de l'article sont basés sur :
- Sur Kenta Graziano, qui, en plus d'une description détaillée, contient des schémas modèles ;
- Livre : « Créer un entrepôt de données évolutif avec DATA VAULT 2.0 » ;
- Статья .
Source: habr.com