👺 👨🏽‍💼 🛄 Le développement de DATA VAULT et la transition vers BUSINESS DATA VAULT 🗻 🕴🏽 💔

Dans un article précédent, j'ai parlé des bases de DATA VAULT, décrit les éléments de base de DATA VAULT et leur objectif. Cela ne peut pas être considéré comme le sujet de DATA VAULT épuisé, il faut parler des prochaines étapes de l'évolution de DATA VAULT.

Et dans cet article je vais me concentrer sur le développement de DATA VAULT et la transition vers BUSINESS DATA VAULT ou simplement BUSINESS VAULT.

Raisons de l'apparition de BUSINESS DATA VAULT

Il convient de noter que DATA VAULT ayant certaines forces n'est pas sans inconvénients. L'un de ces inconvénients est la difficulté d'écrire des requêtes analytiques. Les demandes ont un nombre important de JOIN, le code est long et lourd. De plus, les données tombant dans le DATA VAULT ne sont soumises à aucune conversion, donc, du point de vue de l'entreprise, le DATA VAULT dans sa forme pure n'a pas de valeur inconditionnelle.

Pour éliminer ces lacunes, la méthodologie DATA VAULT a été étendue par des éléments tels que:

Tableaux PIT (ponctuels);
Tables BRIDGE;
DÉRIVATIONS PRÉDÉFINIES.

Examinons de plus près le but de ces éléments.

Tables de fosse

En règle générale, un objet métier (HUB) peut inclure 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, détails du passeport, état matrimonial ou sexe.

Par conséquent, lors de la détermination des satellites, il convient de garder à l'esprit la fréquence de leurs mises à jour. Pourquoi c'est important?

Si vous stockez des attributs avec des taux de rafraîchissement différents dans une table, vous devrez ajouter une ligne à la table chaque fois que vous mettez à jour l'attribut le plus fréquemment modifié. En conséquence, une augmentation de l'espace disque, une augmentation du temps d'exécution des requêtes.

Maintenant que nous avons divisé les satellites en fonction de la fréquence de mise à jour et que nous pouvons les télécharger indépendamment, il devrait être possible d'obtenir des données pertinentes. Mieux sans utiliser de JOIN inutiles.

Je vais expliquer, par exemple, qu'il est nécessaire d'obtenir des informations à jour (à la date de la dernière mise à jour) auprès de satellites ayant des fréquences de mise à jour différentes. Pour ce faire, vous devez non seulement faire un JOIN, mais également créer plusieurs sous-requêtes (pour chaque satellite contenant des informations) avec un choix de la date de mise à jour maximale MAX (Update Date). Avec chaque nouveau JOIN, un tel code se développe et devient très rapidement difficile à comprendre.

La table PIT est conçue pour simplifier ces requêtes; les tables PIT sont remplies en même temps que les nouvelles données sont écrites dans DATA VAULT. Table PIT:

Ainsi, nous avons des informations sur la pertinence des données sur tous les satellites à chaque instant. En utilisant JOINs pour la table PIT, nous pouvons complètement exclure les requêtes imbriquées, naturellement à condition que le PIT soit rempli tous les jours et sans lacunes. Même s'il y a des lacunes dans le PIT, les données réelles ne peuvent être obtenues qu'en utilisant une sous-demande au PIT lui-même. Une sous-requête fonctionnera plus rapidement que les sous-requêtes pour chaque satellite.

PONT

Les tables BRIDGE sont également utilisées pour simplifier les requêtes analytiques. Cependant, la différence avec PIT est un moyen de simplifier et d'accélérer les demandes entre différents hubs, liaisons et leurs satellites.

Le tableau contient toutes les clés nécessaires pour tous les satellites qui sont souvent utilisés dans les requêtes. En outre, si nécessaire, les clés professionnelles hachées peuvent être complétées par des clés sous forme de texte si des noms de clés sont nécessaires pour l'analyse.

Le fait est que sans utiliser BRIDGE, dans le processus d'obtention de données localisées dans des satellites appartenant à différents hubs, il sera nécessaire de produire des JOIN non seulement des satellites eux-mêmes, mais aussi des liaisons de hubs de connexion.

La présence ou l'absence de BRIDGE est déterminée par la configuration de stockage, la nécessité d'optimiser la vitesse d'exécution des requêtes. Il est difficile de trouver un exemple universel de BRIGE.

DÉRIVATIONS PRÉDÉFINIES

Un autre type d'objets qui nous rapproche de BUSINESS DATA VAULT sont les tableaux contenant des indicateurs pré-calculés. Ces tableaux sont vraiment importants pour les entreprises; ils contiennent des informations agrégées selon les règles données et facilitent relativement l'accès.

D'un point de vue architectural, les DÉRIVATIONS PRÉDÉFINIES ne sont rien d'autre qu'un simple satellite d'un certain hub. Comme un satellite ordinaire, il contient une clé commerciale et la date à laquelle l'enregistrement a été formé dans le satellite. Sur ce point, cependant, les similitudes s'arrêtent. La composition supplémentaire 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 DERIVATIONS PREDEFINIES dans la table PIT du même hub, vous pouvez alors facilement obtenir des tranches de données sur les employés pour une date spécifique.

RÉSULTATS

Comme le montre la pratique, l'utilisation de DATA VAULT par les utilisateurs professionnels est quelque peu difficile pour plusieurs raisons:

Le code de demande est complexe et lourd;
L'abondance de JOIN affecte les performances des requêtes;
La rédaction de requêtes analytiques nécessite une connaissance exceptionnelle de la structure du référentiel.

Pour simplifier l'accès aux données, DATA VAULT s'étend avec des objets supplémentaires:

Tableaux PIT (ponctuels);
Tables BRIDGE;
DÉRIVATIONS PRÉDÉFINIES.

Dans le prochain article, je prévois de dire, à mon avis, la chose la plus intéressante pour ceux qui travaillent avec BI. Je présenterai des façons de créer des tableaux - faits et tableaux - mesures basées sur DATA VAULT.

Les matériaux de l'article sont basés:

Sur la publication de Kent Graziano, qui en plus d'une description détaillée contient des diagrammes du modèle;
Livre: «Construire un entrepôt de données évolutif avec DATA VAULT 2.0»;
Article sur les principes fondamentaux de Data Vault .

Le développement de DATA VAULT et la transition vers BUSINESS DATA VAULT

Raisons de l'apparition de BUSINESS DATA VAULT

Tables de fosse

PONT

DÉRIVATIONS PRÉDÉFINIES

RÉSULTATS

More articles: