Problèmes de modélisation : rôles

Bonjour mes amis,

Aujourd’hui je voudrais parler de la notion très importante pour la modélisation des bases de données – rôle.

Cette notion apparaît pour la première fois quand nous mettons en œuvre des liens entre les tables de la base de données.

Dans cet exemple, la table TIERS joue deux rôles en relation avec la table FACTURE – le rôle d’un client facturé (contrainte de clé étrangère « t_cli ») et le rôle d’un vendeur-émetteur de la facture (contrainte de clé étrangère « t_vend »). Clairement, les deux tiers référencés ne sont pas les mêmes, mais ils sont dans la même table.

Autrement, si demain quelqu’un nous demande l’information concernant les tiers utilisés dans la facture, nous devrons demander, de quel tiers il s’agira : du client, de l’émetteur de facture, des deux en même temps.

C’est clair, n’est ce pas ?

#1

Si c’est aussi clair, pourquoi ce n’est pas évident aux éditeurs des systèmes analytiques (SAP, IBM, Microstrategy, Microsoft, Qlik et certains autres) ?

Dans ces systèmes il n’y a aucune mécanique de gestion de rôles (corrigez-moi si j’ai zappé un bouton). Si vos tiers jouent plusieurs rôles, vous devrez dupliquer le modèle de « tiers » pour faire l’outil croire qu’il y a bien deux objets différents… Et si pour un modèle en étoile (i.e. la table tiers n’a pas de clés étrangères), cela n’est pas si grave, pour un modèle en flocon, vous serez obligés de dupliquer toutes tables dans l’hiérarchie.

La situation est encore plus compliquée dans le cas de la dimension « temps » (la solution classique des problèmes qui ne doivent pas exister). Si votre table de faits a plusieurs dates, vous êtes obligés de créer autant de « alias » pour cette table, que vous avez de rôles.

Conclusion : la notion de rôles est souvent négligée, et pourtant il y en existent des belles solutions…

#2

Dans certaines situations, les rôles peuvent changer votre vision du modèle de données. Nous en avons déjà parlé dans notre article Un problème de RDM (gestion de la nomenclature), mais si vous permettez, je fais un petit rappel.

Certaines tables (surtout de nomenclature) jouent constamment des rôles très différents. Par exemple, un pays peut être utilisé pour représenter à la fois la localisation actuelle (adresse) et le lieu dans le passé (pays de naissance).

Essayez de modéliser l’information concernant le pays de naissance de Ferdinand Porsche né en République d’Autriche allemande. Autriche ? Allemagne ? Il était né dans une petite ville qui se trouve actuellement sur le territoire de la République Tchèque, qui elle-même, n’existait pas jusqu’à 1993, et avant 1993 c’était la Tchécoslovaquie…

Ok, mon exemple est couvert de poussière, mais pensez aux gens qui ont été nés avant 1991 en URSS (pas forcément sur la territoire de la Russie). Je suppose qu’ils doivent galérer pour expliquer aux bureaucrates français, pourquoi ils ne sont pas russes.

Conclusion : une fois il y a un objet avec plusieurs rôles, il faut se poser la question si, en réalité, il s’agit du même objet ou les granularités sont finalement différentes.

#3

J’espère que vous êtes d’accord avec moi : la gestion des rôles est très importante pour la modélisation des bases de données (qu’on parle de BI, MDM, Data Hubs ou des systèmes transactionnels).

Posez-vous la question : « quand pour la dernière fois j’ai vu un modèle de données avec les rôles bien définis? » Je ne parle pas de noms de clés étrangères – la même table peut jouer le même rôle sur plusieurs contraintes de clés étrangères.

Moi, je ne me souviens pas d’un seul exemple (en forme de schéma ou en forme de la spécification fonctionnelle). Docteur, c’est grave ?

Pire encore, tous les outils de gestion de dictionnaires de données que j’ai vu jusqu’à aujourd’hui, ne prévoient pas de fonctionnalités pour spécifier explicitement quels rôles tel ou tel « objet » peut jouer. Cette notion semble passer sous tous les radars.

Je voudrais bien savoir ce que vous en pensez dans les commentaires sur LinkedIn.

Bonne santé à vous et à vos SI.

Why was the database administrator always feeling lonely?
Because he had no relationships!