"Oh, nous verrons cela dans l'outil" est le refrain que nous entendons parfois des équipes de conception. A la place, à chaque fois que c'est possible, nous suggérons d'investir les efforts pour construire une information descriptive plus flexible et plus riche directement dans les schémas dimensionnels plutôt que de nous appuyer sur les fonctionnalités de l'outil de métadonnées.
Les outils de business intelligence d'aujourd'hui fournissent des métadonnées solides pour supporter un grand nombre de fonctionnalités, comme la substitution de libellés, les calculs prédéfinis, et la navigation agrégée. Cela est utile pour vos utilisateurs. Mais, nous avons besoin d'être judicieux dans l'utilisation des fonctionnalités que ces outils fournissent. Trop souvent les équipes de conceptions prennent des raccourcis et comptent sur les métadonnées des outils d'accès aux données pour résoudre les problèmes qui seraient mieux traités dans nos modèles dimensionnels. Au final, les règles métiers sont intégrées dans les métadonnées de l'outils plutôt que dans nos schémas. Nous avons également vu des équipes utiliser les métadonnées des outils pour fournir le code des vues et des descriptions des indicateurs afin de conserver leur schéma plus petit.
le gros inconvénient de ces raccourcis est la dépendance aux métadonnées des outils des utilisateurs pour appliquer les règles métiers. Si nous comptons sur les métadonnées des outils pour mettre en oeuvre les règles métiers, chaque utilisateur devra accéder aux données via l'outil pour garantir l'exactitude des données. les utilisateurs qui veulent ou ont besoin d'utiliser d'autres méthodes d'accès sont obligés de recréer les règles métiers présentent dans les métadonnées de l'outil pour s'assurer du bon résultat.
En tant que développeurs d'entrepôts de données, nous avons besoin de nous protéger contre les situations où les utilisateurs peuvent voir différents résultats en fonction de l'outil qu'ils utilisent. Indépendamment de la manière dont les utilisateurs ont accès aux données de l'entrepôt, ils devraient avoir la même qualité et cohérence dans les données.
Vous pensez peut être "bien, alors nous forcerons tous les utilisateurs à accéder à l'entrepôt de données via notre outils". Cependant, cette approche échouera inévitablement. Il existe une certain nombres de raisons pour qu'un utilisateur ait besoin d'accéder aux données par d'autres moyens, évitant ainsi l'outil officiel, et par conséquent les règles métiers présentes dans les métadonnées. Ces scénarios peuvent ne pas exister dans votre organisation au moment où vous développez votre schéma, mais rassurez-vous, l'un d'entre eux apparaîtra:
- un informaticien peut choisir d'utiliser du SQL directement sur l'entrepôt de données pour résoudre une requête complexe ou un audit des données
- votre organisation peut développer des applications analytiques basées sur des requêtes SQL spécifiques accédant directement à l'entrepôt de données
- les outils statistiques et/ou de data-mining peuvent accéder directement à l'entrepôt de données
- un utilisateur peut avoir accès directement à l'entrepôt de données via des outils comme MS Access
- il y a peut être besoin de compléter l'entrepôt de données avec des cubes multidimensionnels dessinés directement à partir de l'entrepôt de données
- votre organisation peut choisir d'autres outils, ne remplaçant pas encore l'outil courant.
Rien de tout cela ne doit être interprété comme un argument contre l'utilisation les capacités de votre outil d'accès aux données. Au contraire, la clé est qu'en cas de doute ou confronté à un choix, nous préférons le choix de conception qui place une fonctionnalité au plus près possible des données pour s'assurer que la fonctionnalité est disponible à un public aussi large que possible.
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #44: Don't be overly reliant on your data access tool's metadata", publié le 14 mars 2003.
Aucun commentaire:
Enregistrer un commentaire