Discussion :

[patmaba]

Bonjour,


Ne sachant pas quel préfixe utilisé pour ce post, je ne l'ai pas spécifié.


Un projet dans lequel je travaille souhaite modéliser une db existante sous forme de meta-data.

D’un point de vue modélisation de données, quel est l’intérêt de modéliser un système de données sur des métas-data pour définir la structure d’une table de ces colonnes et de ces valeurs.

En simplifiant le modèle de méta-data, le système simplifié ressemble à quelque chose comme ceci :

MetaTable( mt_id, nom_table )
MetaCols( mc_id, nom_cols, mdata_type, mlenght, mdecimal, mt_id )
MetaValues( mv_id, mc_id, value)

Exemple :
une table classique
Voiture( id, nom, vitesse_max, nbr_place )

sera modélisée dans le système de métadonnées comme ceci:

MetaTable : (1,’voiture’)

MetaCols :
(1,’id’,’number’,10,0, 1)
(2,’nom’,’varchar2’,100,0, 1)
(3,’vitesse_max’,’number’,3,0, 1)
(4,’nbr_place’,’number’,1,0, 1)


MetaValues
( 1,1,’1’)
( 2,2, ‘Porshe GT’)
( 3,3, ‘250’)
( 4,4, ‘2’)

( 5,1, ’2’)
( 6,2, ‘C4 Picasso’)
( 7,3, ‘160’)
( 8,4, ‘7’)

( 9, 1, ’3’)
( 10,2, ‘C4 Picasso’)
( 11,3, ‘160’)
( 12,4, ‘7’)


Quel sont les avantages/défaut de ce système ?

Cordialement.

[CinePhil]

Ça autorise une grande souplesse quant à la structure des données et du type d'infos qu'on stocke puisque c'est extensible à l'infini à partir d'une structure simple mais c'est la porte ouverte à l'incohérence des données, à l'absence d'intégrité référentielles... et c'est plus compliqué d'aller chercher les données que l'on souhaite obtenir.

Le cas intelligent que j'ai vu de méta-données, c'était pour gérer finement des droits d'accès à des données importées et revêtant certains degrés de confidentialité.

Là où ça peut aussi être intéressant, c'est pour stocker des paramètres en nombre et de types variables selon ce à quoi ils se rapportent. Par exemple, les vêtements ont des tailles et des couleurs alors que des voitures ont une puissance, un carburant...

Mais pour une base de données simple couvrant un domaine précis, je ne vois pas l'intérêt d'une telle structure.

Voir l'article de SQLPro sur la modélisation par méta-données.

Pour quelle raison "le projet" veut modéliser par méta-données ?

[montesq]

On en parle indirectement dans ce fil: http://www.developpez.net/forums/d97...tte-structure/

Les avantages:
tu peux ainsi obtenir une base de données "dynamiques" sans modifier le schéma de ta base de données. Ainsi, on peut très bien au niveau applicatif ajouter une "méta-table" ou une "méta-colonne" sans modifier le schéma.

Les inconvénients:
- performances: pour insérer/modifier une ligne dans 1 table contenant 15 colonnes, tu auras besoin de faire 15 insert/update avec une "méta-base" quand 1 seule suffirait avec une base traditionnelle.
Idem pour faire un select: il faudra faire un certain nombre de jointures...

[patmaba]

L'argument du technicien c'est d'être réactif pour modifier le schéma de la base de données afin d'éviter tout le processus d'alter de table à travers les différents environnement de validation avant la mise en production.

Le chef de projet à valider ce choix. Le consultant externe qui a proposé cette modélisation arrive à argumenter du tac au tac.

Il souhaite convertir les données existantes vers se schéma en ne tenant pas compte des processus existant basé sur une modélisation traditionnelle.

Selon lui.

Le processus ce fait en plusieurs étapes
1) définir le modèle méta data
2) convertir les anciennes données dans ce méta data.
3) supprimer les anciennes tables
4) créer des vues avec le même nom que les anciennes tables
5) avec option ajouté du code trigger pour gerer les insert/update/delete sur ces vues
6) compilé l'ensemble

donc l'argument de choix c'est d'être réactif pour l'ajout de nouveau champs dans l'applic.

J'ai beaucoup de mal à accepter ce changement radical de modélisation uniquement avec l'argument : être réactif à tout changement sans déployer les scripts dans l’environnement de production .

[patmaba]

J'ai trouvé sur ce site c'est l'utilisation des metadata est soi-disant superbe solution cf : http://sqlpro.developpez.com/cours/m...n/metadonnees/

Je reste perplexe.

[patmaba]

Merci pour vos réponses.

Avez-vous d'autres remarques ? Ou des liens sur d'autres site traitant ce type de systèmes ?

merci

[CinePhil]

L'argument du technicien c'est d'être réactif pour modifier le schéma de la base de données afin d'éviter tout le processus d'alter de table à travers les différents environnement de validation avant la mise en production.

Un technicien qui décide de la conception d'une BDD ? Hum...
Je trouve le reste de l'argument très faible ! Ça semble vouloir dire que les besoins ne sont pas définis assez clairement.
Dans le monde des qualiticiens, on dit qu'une erreur en conception coûte 10 fois plus cher qu'une erreur en production. À méditer...

Le chef de projet à valider ce choix. Le consultant externe qui a proposé cette modélisation arrive à argumenter du tac au tac.

Il souhaite convertir les données existantes vers se schéma en ne tenant pas compte des processus existant basé sur une modélisation traditionnelle.

En plus s'il existe déjà un modèle à peu près correct de données existantes, pourquoi vouloir réinventer la roue alors qu'il suffit peut-être d'améliorer le modèle existant ?

Selon lui.

Le processus ce fait en plusieurs étapes
1) définir le modèle méta data
2) convertir les anciennes données dans ce méta data.
3) supprimer les anciennes tables
4) créer des vues avec le même nom que les anciennes tables
5) avec option ajouté du code trigger pour gerer les insert/update/delete sur ces vues
6) compilé l'ensemble

Ça c'est le processus pour faire ce qu'il vous conseille ! Se rappeler que les conseilleurs ne sont jamais les payeurs ! Et il paraît que les triggers sont très coûteux en traitements ; alors s'il y a beaucoup d'opérations de modification des données, ça risque de plomber les performances. De plus, un trigger, c'est un programme, donc un risque de bug quelque part, surtout si c'est pour remplacer les processus internes au SGBD qui garantissent l'intégrité des données.

donc l'argument de choix c'est d'être réactif pour l'ajout de nouveau champs dans l'applic.

Est-ce que la nature du périmètre des données à modéliser justifie des modifications régulières du modèle ?

Il y a des modèles normalisés qui permettent de la souplesse en ne modifiant pas les tables existantes mais, parfois, en en ajoutant de nouvelles.

Si tu nous dis de quoi il s'agit, nous pourrons peut-être t'aider à argumenter dans un sens ou à accepter la solution préconisée si elle s'avère la plus raisonnable.

J'ai beaucoup de mal à accepter ce changement radical de modélisation uniquement avec l'argument : être réactif à tout changement sans déployer les scripts dans l’environnement de production .

Ne me dis pas que tes supérieurs envisagent de faire des modifications d'appli à chaud sur l'environnement de production quand même !

Je viens de relire l'article de SQLPro... La question est : "Puisque ça semble si génial, pourquoi toutes les BDD ne sont-elles pas développées de la sorte ?"

[patmaba]

C'est un système d'inventaire technique couvrant des sites ou zone de traitement subdivisé en sous-zone.

Chaque sous-zone est constitué d’élément ou composant.

L'inventaire structure clairement pour chaque type d’élément une description détaillée.

Les données existantes sont là depuis des dizaines d'années. Elles sont stables.

En plus s'il existe déjà un modèle à peu près correct de données existantes, pourquoi vouloir réinventer la roue alors qu'il suffit peut-être d'améliorer le modèle existant ?

C'est ce que je leur ai dit. Ils ne veulent rien entendre.

Est-ce que la nature du périmètre des données à modéliser justifie des modifications régulières du modèle ?

Ce seront surtout de nouveau champs à ajouter au sein de tables existantes et des processus d'extractions de données structurée provenant de notre base qui seront envoyées pour un autre système.

[CinePhil]

Ce seront surtout de nouveau champs à ajouter au sein de tables existantes et des processus d'extractions de données structurée provenant de notre base qui seront envoyées pour un autre système.

Est-ce que ces colonnes (et pas champs !) seront renseignées pour toutes les lignes de ces tables ?

Parce qu'il peut être préférable de créer de nouvelles tables qui ne contiendront que les lignes pour lesquelles ces colonnes contiendront une valeur. Avec une vue, on retrouve la structure complète.

Par exemple, puisqu'il s'agit d'inventaire technique, si une nouvelle machine nécessite des gammes de réglages que n'ont pas les machines existant jusqu'à présent, on crée la structure nécessaire à la nouvelle machine séparément et on fait un héritage vers la machine générale sans réglage :
Machine_avec_réglage -(1,1)----Etre----0,1- Machine

Sans connaître le structure des données existantes et le besoin concret, difficile d'en dire plus. Mais si les données existent, sont stables et bien modélisées, ça me semble être un gros boulot d'exploser le schéma existant plutôt que de l'étendre pour les nouveaux besoins qui ne doivent quand même pas être fondamentalement pas si différents.

Bon courage !

[montesq]

Mais si les données existent, sont stables et bien modélisées, ça me semble être un gros boulot d'exploser le schéma existant plutôt que de l'étendre pour les nouveaux besoins qui ne doivent quand même pas être fondamentalement pas si différents.

+1
Sinon, il faudrait peut-être voir aussi comment faire cohabiter les 2 modèles?
Garder l'existant pour les besoins "standards" et rajouter la possibilité d'ajouter des champs en dynamique pour les nouveaux besoins.
Ce qui n'aura pas le mérite de simplifier la situation au niveau des dév à effectuer (au contraire) mais qui permet de travailler sur une base saine...

Le problème avec l'adoption de la méta-base c'est que cela implique de faire une migration de ta base de données actuelle. Or comme toute migration, il y a un risque non négligeable d'anomalie. Et le problème avec les migrations c'est que, plus tu détectes tard l'anomalie, plus tu risques de t'arracher les cheveux pour corriger les données qui ont été migrées car entre temps de nouvelles données ont été intégrées!

Par ailleurs, je ne suis pas expert en BDD, mais en utilisant la solution des méta données, on perd la notion de clé étrangère, ce qui peut être gênant lors d'accès concurrents sur les mêmes données. Voir http://sqlpro.developpez.com/article/fk-sql-vs-appli/

[patmaba]

merci pour tout ces éléments de réponse.

[fsmrel]

Vite fait sur le gaz...

En simplifiant le modèle de méta-data, le système simplifié ressemble à quelque chose comme ceci :

MetaTable( mt_id, nom_table )
MetaCols( mc_id, nom_cols, mdata_type, mlenght, mdecimal, mt_id )
MetaValues( mv_id, mc_id, value)

Ne pas oublier la définition des clés primaires et alternatives dans MetaTable et la programmation de leur contrôle...
Il ne faudra pas oublier non plus de mettre en oeuvre les incontournables métatables telles que :

• MetaForeignKeys (structure des clés étrangères),
• MetaReferentialConstraints (structure des relations entre clés étrangères et clés primaires/alternatives),
• MetaChecks (pour contrôler les contraintes définies pour les tables),
• MetaVues (pour pouvoir contrôler la partie texte des vues) à moins que votre spécialiste ne dise que les vues sont inutiles,
• MetaIndex et MetaIndexKeys (sinon bonjour les requêtes qui durent trois jours...),
• MetaTableSpaces (pour savoir où loger physiquement les tables, ça intéresse bigrement la Production informatique et les DBA),
• MetaStats (sinon ciao les Explain PLAN...),
• Et les métatables pour gérer les droits, etc. etc., etc.

Bref, cela revient à construire un catalogue (métabase) qui doit offrir au moins ce qu’offre le catalogue relationnel de votre SGBD (ou de son successeur le jour où vous en changerez). Et comme les catalogues des SGBD s’enrichissent, vous serez amené à suivre le mouvement et peut-être devoir définir une métamétabase, voire une métamétamétabase...

Le farfelu auquel vous avez affaire ignore qu’un iceberg a une partie immergée, autrement dit il y a un travail colossal en perspective pour réinventer ce que votre SGBD propose déjà.

Vouloir tout faire passer en métatables relève de l’inconscience, voire de la folie furieuse (ou d'intérêts inavouables).

L'argument du technicien c'est d'être réactif pour modifier le schéma de la base de données afin d'éviter tout le processus d'alter de table à travers les différents environnement de validation avant la mise en production.

Il faudra de toute façon vérifier que les métatables sont en phase dans les différents environnements.

Côté réactivité, que vous mettiez parcimonieusement en œuvre quelques métatables hors du cœur de votre système, pourquoi pas, le temps de satisfaire les utilisateurs en temps réel. Ensuite, vous prenez le temps de faire vos ALTER TABLE en toute sérénité.

Le consultant externe qui a proposé cette modélisation arrive à argumenter du tac au tac.
Selon lui le processus ce fait en plusieurs étapes

Il doit quantifier en jours/hommes et s’engager pour chaque étape (prévoyez en ce sens les clauses de pénalités financières).
Du reste il manque des étapes, par exemple :

• Vérifier que l'usine à gaz fonctionne sans erreur (tests exhaustifs à prévoir),
• S’assurer que les performances des programmes/requêtes (temps de réponse des transactions inférieurs à la seconde avec tant d'utilisateurs simultanément connectés, durée des batchs) sont au rendez-vous avec des volumétries réelles (et là on risque d’avoir des surprises si les volumétries sont importantes, devoir écrire un optimiseur), gare aux pénalités !

Que propose l'hurluberlu (ou le génial fou furieux, comme on veut) quant à la maintenance de «sa» métabase ?

[patmaba]

merci pour ce feedback.