Discussion :

[Artemus24]

Salut à tous.

Le problème du blocage vers le site pourrait peut-être venir du nom même "looping".
Après une recherche, je le retrouve plusieurs fois associé à des sites consacré au sexe, comme dans "Vidéos Porno Looping".
Ou encore à des objets consacrés aussi au sexe.
Il me semble que le mot "looping" n'est pas très judicieux dans ce contexte, bien que sa première signification soit "boucle".

Après quelque rcherche, j'ai trouvé que "loop" pouvait signifier "stérilet".
Voire même --> "nested loop, subroutine : imbriqué, emboîté".
Je n'ai pas poursuivi car le sujet m'intéresse pas du tout.

D'ailleurs, je ne comprends pas trop l'association entre le "looping" signifiant "boucle" et la conceptualisation d'un modèle de données où a priori, il n'y a pas de boucle.

Il serait judicieux de revoir ce nom commercial dans un contexte plus informatique.

Bien que je ne sois pas un spécialiste de la modélisation, celle-ci ne se fait pas en seul jet.
Je veux dire que ce travail commence par la compréhension (ou la découverte) du sujet qui en toute logique, n'est pas nécessairement maitrisé par celui qui va concevoir cette modélisation.

Désolé de contredire Paprick, au démarrage du travail, un MCD n'est juste qu'une première ébauche.
Au fur et à mesure d'une meilleure compréhension, ce MCD va se compliquer, voire même se modifier afin de devenir le MCD définitif.
Encore que par définitif, j'entends la première version.

Je rejoins isabelle.letrong quand elle dit : "n'est en réalité pas plus à la portée d'un débutant que celle d'un MLD".

Par contre quand Paprick dit : "il permet une conception précise et une représentation fidèle de la façon dont le schéma relationnel sera structuré au niveau logique".
Je ne suis pas d'accord.
Un MCD n'est qu'une solution parmi tant d'autres de la résolution de la modélisation au niveau logique.
Maintenant dire qu'elle est la représentation "fidèle", là je pense que l'on met la charrue avant les bœufs.

Le MCD (modèle conceptuel des données) est la représentation d'une solution (en espérant qu'elle soit la meilleure) des relations entre les données.
Or quand on passe aux tables, nous rencontrons des problèmes pour adapter ce MCD à sa représentation physique.

Il se trouve qu'aujourd'hui, il existe des outils qui font tout, à savoir le MCD, le MLD, et la création de la base de données.
C'est bien, mais cela empêche de créer une règle au niveau MCD, si cette règle ne peut pas être implémenté dans la base de données.

Ce que je veux dire se résume à ceci :
a) la conception du MCD se fait dans une représentation graphique, où il y a des rectangles, des ovales et des flèches, comme dans le modèle entité relation.

b) que l'on attribue un sens à tous les symboles cabalistique qui vont apparaitre sur cette représentation graphique, souvent incompréhensible pour un débutant, ayant même un peu d'expérience.
Je veux dire : pourquoi tel choix a été fait plutôt qu'un autre ?

c) que le passage du modèle graphique, au modèle physique se fait par un dégradation de l'idéal recherché.
Du genre, comment créer une contrainte, si le SGBDR n'a pas implémenté un outil pouvant le réaliser.

d) la solution définitive sera obligatoirement une solution dégradée et non fidèle, si le SGBDR n'est pas en conformité avec tout ce qui se fait de mieux dans la repésentation physique des données par rapport à l'optimisation de cette modélisation.

C'est pourquoi (sauf si j'ai compris de travers), je rejoins isabelle.letrong quant elle dit :

En réalité, même s'il parait plus simple de dessiner des rectangles et des patates, la production d'un MCD correct n'est pas plus à la portée d'un béotien que la production directe d'un MLD normalisé ....

Je la rejoint sur ses propos :

Donc, de mon point de vue, rien de très choquant à partir bille en tête sur un MLD avec MySQL Workbench, et pourquoi pas, de réfléchir à coder le cœur pérenne de gestion de l'application sous la forme de routines stockées puisque l'outil le permet, mais ceci est une autre histoire…

Je mettrai quand même un bémol dans le cas où cette modélisation reste simple, genre tables et clef étrangères, voire des contraintes d'unicité.
Pour ce qui est des autres contraintes nécessitant sûrement plus de réflexions, un trigger, une procédure stockée sera une aide à leur réalisation, au cas où l'outil n'existe pas nativement dans le SGBDR.

Pour ma part, des outils qui font tout sans bien savoir comment cela se concrétise réellement et qui sont soi-disant des aides à la conception, peuvent porter préjudice à une bonne formation.
Il n'y a rien de mieux que le crayon, la gomme et la feuille de papier pour la modélisation.
Et de passer au modèle physique, en créant un script SQL que vous pourrez tester autant de fois que vous le désirer jusqu'à sa validation.

Le genre universitaire qui fait tout en un seul jet, désolé de le dire mais je n'aime pas.
Une modélisation, ça se réfléchit et il est très utile de revenir en arrière quand ça ne va pas.
Puis de tester et re-tester, jusqu'à deux choses :
--> c'est conforme à ce que l'on me demande fonctionnellement.
--> la performance pour l'accès aux données est acceptable.

Désolé de le dire paprick, mais vous êtes trop dans la théorie, même si vous maitrisez votre sujet.

@+

[Paprick]

Bonjour,

Il y a beaucoup de choses intéressantes dans ce dernier message .
Commençons par le début !

D'ailleurs, je ne comprends pas trop l'association entre le "looping" signifiant "boucle" et la conceptualisation d'un modèle de données où a priori, il n'y a pas de boucle.
Il serait judicieux de revoir ce nom commercial dans un contexte plus informatique.

Effectivement, "looping" signifie "boucle" (et je suis navré si ce terme est utilisé dans des contextes spécifiques que je n'ai jamais eu l'occasion d'explorer... ).
Allez, un peu d'histoire personnelle : il y a un quart de siècle, dans le cadre de ma HDR à l'Université (qui a remplacé la thèse d'Etat), j'ai créé un outil permettant de modéliser des objets spatio-temporel avec des réseaux de Petri à objets ; Looping signifiait alors : Language based on Object Oriented PetrI Nets Graphically extended. 20 ans plus tard, je reprenais les mêmes concepts pour bâtir cet outil de modélisation. Et au moment de me demander si ce nom était toujours judicieux, je me suis rappelé la façon dont j'enseigne les cardinalités à mes étudiants, et leur fameux placement "inversé" sur les pattes. J'utilise toujours la représentation suivante :

J'ai donc conserver ce nom , que je n'ai donc pas l'intention de changer, le nom n'ayant d'ailleurs rien de "commercial" puisque je rappelle que cet outil est et restera toujours gratuit et libre d'utilisation, et ne fera jamais l'objet de la moindre démarche commerciale : il était initialement destiné au monde universitaire, même si bon nombre d'autres organismes l'utilisent aujourd'hui.
Enfin, pour en terminer avec ce premier point, je pense que le blocage vient plus du ".exe" que du 'Looping" : c'est pourquoi, le site propose maintenant un téléchargement exclusivement en "Looping.zip".

Désolé de contredire Paprick, au démarrage du travail, un MCD n'est juste qu'une première ébauche.
Au fur et à mesure d'une meilleure compréhension, ce MCD va se compliquer, voire même se modifier afin de devenir le MCD définitif.
Encore que par définitif, j'entends la première version.

Cela ne me contredit aucunement ! Effectivement le MCD a cette faculté d'évoluer pour proposer des premières versions destinées à une bonne compréhension et à des échanges constructifs entre le concepteur et le futur utilisateur. D'ailleurs, personnellement, je distingue les MCD (dans lesquels je n'introduis même pas la notion d'identifiant) et les MCDi (destinés à l'informatisation).
Dans un premier temps, il serait effectivement délicat de parler à un béotien de CIF, de contraintes inter-associations, d'identification relative, ...

Je rejoins isabelle.letrong quand elle dit : "n'est en réalité pas plus à la portée d'un débutant que celle d'un MLD".
Par contre quand Paprick dit : "il permet une conception précise et une représentation fidèle de la façon dont le schéma relationnel sera structuré au niveau logique".
Je ne suis pas d'accord.
Un MCD n'est qu'une solution parmi tant d'autres de la résolution de la modélisation au niveau logique.
Maintenant dire qu'elle est la représentation "fidèle", là je pense que l'on met la charrue avant les bœufs.

Cette vision est très limitative, et n'est pas conforme à ce que peuvent proposer les outils d'aujourd'hui.
Le fait qu'un outil puisse proposer une représentation fidèle (la charrue) n'empêche pas d'avoir mis les bœufs avant.
Négliger le pouvoir d'expression des MCD sous prétexte qu'on traietra ça plus tard dans le MLD, est une façon de voir les choses... Je ne la partage pas, mais à chacun sa stratégie.

Le MCD (modèle conceptuel des données) est la représentation d'une solution (en espérant qu'elle soit la meilleure) des relations entre les données.
Or quand on passe aux tables, nous rencontrons des problèmes pour adapter ce MCD à sa représentation physique.
Il se trouve qu'aujourd'hui, il existe des outils qui font tout, à savoir le MCD, le MLD, et la création de la base de données.
C'est bien, mais cela empêche de créer une règle au niveau MCD, si cette règle ne peut pas être implémenté dans la base de données.

Encore une fois, les outils évoluent ; Looping permet, pour ceux qui le souhaitent, d'intégrer des règles de toute nature au niveau du MCD, et je pense que ce n'est pas le seul outil à le faire.
Le problème de votre vision des MCD conduit inévitablement à leur non-utilisation car, une fois le passage au MLD effectué avec les adaptations techniques qui vont avec, on ne revient que très rarement au niveau conceptuel quand le SI évolue... et je comprends alors que vous, et tant d'autres, modélisiez directement au niveau MLD.

Pour ma part, des outils qui font tout sans bien savoir comment cela se concrétise réellement et qui sont soi-disant des aides à la conception, peuvent porter préjudice à une bonne formation.
Il n'y a rien de mieux que le crayon, la gomme et la feuille de papier pour la modélisation.
Et de passer au modèle physique, en créant un script SQL que vous pourrez tester autant de fois que vous le désirer jusqu'à sa validation.

Ma foi, à vous écouter, à quoi bon proposer des outils ... C'est quand même étonnant de penser que, parce que l'on a un marteau plutôt qu'un bout de bois, on ne va pas réfléchir à comment enfoncer le clou...

Le genre universitaire qui fait tout en un seul jet, désolé de le dire mais je n'aime pas.
Une modélisation, ça se réfléchit et il est très utile de revenir en arrière quand ça ne va pas.
Puis de tester et re-tester, jusqu'à deux choses :
--> c'est conforme à ce que l'on me demande fonctionnellement.
--> la performance pour l'accès aux données est acceptable.

Il est bien connu que les universitaires ne réfléchissent pas, et apprennent à leurs étudiants à cliquer sur un bouton en espérant que le modèle se fasse tout seul.

Désolé de le dire paprick, mais vous êtes trop dans la théorie, même si vous maitrisez votre sujet.

Il ne faut pas être désolé... C'est moi qui le suis en constatant la piètre opinion que vous avez des universitaires, en les considérant comme des théoriciens éloignés de toute pratique. Pour ma part, j'ai travaillé dans l'industrie du logiciel pendant 15 ans avant d'intégrer le monde universitaire ; j'ai continué ensuite à conduire des centaines de projets opérationnels, et j'ai pu constater que, bien utilisée, la théorie a bien des vertus que la pratique aurait tort de mépriser, tout simplement parce que les deux sont bien souvent complémentaires.

[escartefigue]

Bonjour Artemus24

Il se trouve qu'aujourd'hui, il existe des outils qui font tout, à savoir le MCD, le MLD, et la création de la base de données.
C'est bien, mais cela empêche de créer une règle au niveau MCD, si cette règle ne peut pas être implémenté dans la base de données.

Pour les contraintes d'intégrité, rares sont les SGBD-R qui ne les mettent pas en œuvre à part le moteur MyIsam, plus guère utilisé, quoi d'autre ?
Fort heureusement du reste, l'intégrité des données c'est fondamental dans le système d'information.

Et si on raisonne ainsi, on peut également poubelliser le MLD, car lui aussi est déconnecté du choix du SGBD et donc de la faculté de mettre en œuvre ou pas les contraintes d'intégrité. Il faudrait donc attaquer directement la modélisation par le modèle Physique

Ce qui est important, ce n'est pas tant qu'une règle de gestion puisse ou non être mise en œuvre par le SGBD, mais surtout que cette règle soit identifiée, rédigée avec soin et validée par le métier, puis matérialisée pour que les développeurs en aient connaissance.
Et c'est la l'un des intérêts du MCD : décrire tous les objets de gestion et les règles qui gouvernent leurs interactions.
Si ensuite le SGBD ne permet pas d'appliquer directement les règles, il faudra développer des procédures, des triggers ou tout autre solution technique pour les vérifier, mais au moins, elles sont dans la documentation grâce au MCD.

Ce que je veux dire se résume à ceci :
a) la conception du MCD se fait dans une représentation graphique, où il y a des rectangles, des ovales et des flèches, comme dans le modèle entité relation.

b) que l'on attribue un sens à tous les symboles cabalistique qui vont apparaitre sur cette représentation graphique, souvent incompréhensible pour un débutant, ayant même un peu d'expérience.

Toute représentation symbolique requiert un apprentissage. Il en va de même pour les modèles de traitement ou les diagrammes de flux.
Je ne vois pas en quoi la symbolique du MLD serait plus ou moins accessible que celle du MCD.
Pour ma part, quand j'appréhende une nouvelle base de données dont j'ignore tout, mon premier reflexe est de réclamer le MCD .

[Artemus24]

Salut à tous.

Pas mal le coup de la boucle sur la cardinalité !
D'ailleurs, je n'ai pas compris pourquoi le mettre de ce coté. Bon, peut importe.

J'ai donc conserver ce nom , que je n'ai donc pas l'intention de changer,

Maintenant que tu as dévoilé son acronyme, je comprends mieux tout l'intérêt que tu y portes.

le nom n'ayant d'ailleurs rien de "commercial" puisque je rappelle que cet outil est et restera toujours gratuit et libre d'utilisation

Je ne trouve jamais mes mots. Quand tu parles de BIC, c'est un nom qui est diffusé et connu de tous.
Par commercial, j'entendais quelques choses comme de la diffusion et qui fait référence à quelque chose de bien précis.
Je ne sais pas si une "marque" est le bon mot.

Rien à voir avec une quelconque notion pécuniaire.

Enfin, pour en terminer avec ce premier point, je pense que le blocage vient plus du ".exe" que du 'Looping" : c'est pourquoi, le site propose maintenant un téléchargement exclusivement en "Looping.zip".

Le ".zip" est important car le fichier sera compressé et nécessitera moins de temps au chargement.

Ok, je comprends mieux le blocage rencontré dans l'entreprise de laurentSc.
Enfin, je devrais dire du beau gosse puisqu'il a mis sa photo.

Cela ne me contredit aucunement !

Pour moi, c'est avant tout (la modélisation) une construction de l'esprit qui se fait étape par étape.
D'où mon image d'une feuille de papier, d'un crayon de papier et d'une gomme.

L'évolution est importante et ce que je reproche, c'est de ne pas indiquer les problèmes rencontrés avec la réflexion derrière ainsi que là ou les solutions proposées.
On donne la solution sans dire pourquoi celle-ci plutôt que celle-là. Ca, c'est pas bien pour un béotien.

Cette vision est très limitative, et n'est pas conforme à ce que peuvent proposer les outils d'aujourd'hui.

Je ne parlais pas d'outils mais du raisonnement qui nous amène à la proposition de cette solution.
L'outil, c'est autre chose, puisqu'il est conçu pour répondre à un besoin final.

Négliger le pouvoir d'expression des MCD sous prétexte qu'on traitera ça plus tard dans le MLD, est une façon de voir les choses...

Je n'ai pas dit cela ou alors je ne comprends pas ta remarque.
Je dis que le MCD donne les solutions que l'on veut mettre en place et non la façon (MLD) de le faire.
J'aurai tendance à dire que le MCD est "théorie" (ce que l'on veut faire) et le MLD est "pratique" (comment le faire).

Il ne faut pas commencer par faire un MLD en premier puis l'adapter pour faire un MCD. J'espère que je suis un peu plus clair.
Ce n'est pas une erreur en soi tant que la mise en œuvre reste simple.
Mais au lieu de faire du bricolage, je préfère suivre une méthodologie, même si elle parait abscons au premier abord.

Encore une fois, les outils évoluent ;

Arrête de me parler de tes outils.

J'en suis encore à la feuille de papier, du crayon de papier et de la gomme.
Ou si tu préfères, de la réflexion, de la mise en œuvre de ce que je désire obtenir en tant que MCD.
Si tel outil ne me propose pas telle contrainte, ne trouves-tu pas cela rédhibitoire ? Moi, si.
Pourquoi ? Parce que l'outil sera aligné sur tel SGBDR.

Je précise que je fais la distinction entre le modèle sur papier (MCD) et la solution physique (MLD).

Le problème de votre vision des MCD conduit inévitablement à leur non-utilisation

Non, je ne fais pas ça. Quand j'ai fini de travailler sur mon MCD, je ne revient pas dessus.
Le MCD n'est pas un plan d'architecte, mais bien la représentation de ce que l'on désire faire.

une fois le passage au MLD effectué avec les adaptations techniques qui vont avec, on ne revient que très rarement au niveau conceptuel

Oui, tout à fait. Je tiens tout de même à préciser que l'on se trouve dans la même version de la modélisation.

Si dans le MCD, on dit que telle colonne doit se trouver dans telle table, c'est une vision fonctionnelle, et c'est très bien.
Par contre, après avoir fait le MLT (Le modèle logique de traitement) et que l'on constate pour des raisons de performances de déplacer cette colonne ailleurs, il est inutile de modifier le MCD.
On doit bien sûr modifier le MLD (le modèle logique des données) car nous avons dégradé notre modèle qui reste le MCD.
J'espère avoir été plus clair.

quand le SI évolue...

Ca, c'est un changement de version.

et je comprends alors que vous, et tant d'autres, modélisiez directement au niveau MLD.

Pas du tout, car un changement de version implique une autre façon de raisonner.
Il faut revoir le MCD, le MLD, ... ainsi que les performances, les traitements ...
Pour simplifier, une modification même basique engendre une nouvelle version et nécessite de tout reconsidérer.

Ma foi, à vous écouter, à quoi bon proposer des outils ...

L'outil, c'est la solution de facilité.

Il faut comprendre que l'outil n'envisage pas toutes les solutions que l'on peut mettre en œuvre, mais juste ceux de son concepteur.
Il existe des digressions (je pense aux performances) mais qui pour un architecte dans la modélisation trouvera cela pas conforme du tout.
Tant que cela répond au besoin de l'utilisateur et que ça fonctionne correctement, je ne vois pas pourquoi je devrais m'en passer.

Je suis bidouilleur dans l'âme, et pas du tout méthodique, enfin je veux surtout souligner que c'est surtout sur le tas que l'on apprend et pas dans les livres.

C'est quand même étonnant de penser que, parce que l'on a un marteau plutôt qu'un bout de bois, on ne va pas réfléchir à comment enfoncer le clou...

Et le marteau, tu le tiens par le manche ou pas le fer ? Et le clou, tu mets la tête ou la pointe sur la planche ?
Il ne faut pas croire que si c'est évident pour toi que cela l'est pour tout le monde, surtout en ce qui concerne la modélisation.
Rien ne vaut la pratique, même si l'on commet des erreurs, c'est là que l'on apprend !

Il est bien connu que les universitaires ne réfléchissent pas

Ce n'est pas du tout ce que je dis. Le problème est que vous réfléchissez et c'est bien.
Sauf que dans votre raisonnement, vous êtes au dixième étage, alors que les étudiants sont encore sur le seuil de l'entrée.

et apprennent à leurs étudiants à cliquer sur un bouton en espérant que le modèle se fasse tout seul.

C'est là où on ne se comprend pas.

Il faut faire les choses étape par étape et laisser les étudiants se tromper, même si cela vous choque.
En tant que professeur, vous devez accompagner vos étudiants pour les mener au dixième étage.
Et non, de demander à vos étudiants de vous rejoindre au dixième étage.
Oui, je sais, au bout de plusieurs années de pratique, c'est lassant de toujours répéter la même chose.

L'erreur que la plupart des professeurs font, est la passation du savoir.
Non, le savoir n'est rien si l'on ne comprend pas la démarche qui nous amène à ce savoir.
L'important est la pédagogie et surtout inculquer le raisonnement pour aboutir à ce savoir.
Le par-cœur n'est pas la bonne méthode !

C'est moi qui le suis en constatant la piètre opinion que vous avez des universitaires,

Je ne suis pas suffisamment patient pour être enseignant. Je préfère apprendre sur le tas car cela me correspond mieux.
Dans le monde du travail, on demande de trouver des solutions.
Or d'après mon expérience, les universitaires sont trop théorique pour les services (SSII).
Je viens de l'iut et d'une grande école où l'enseignement est plus tourné vers les entreprises.

Je dirais à chacun son métier et ce n'est pas un reproche, tout au contraire.

Et c'est la l'un des intérêts du MCD : décrire tous les objets de gestion et les règles qui gouvernent leurs interactions.

C'est exactement ce que je dis.

Si ensuite le SGBD ne permet pas d'appliquer directement les règles, il faudra développer des procédures, des triggers ou tout autre solution technique pour les vérifier, mais au moins, elles sont dans la documentation grâce au MCD.

Je suis encore d'accord avec toi.
Mais sous prétexte que telle règle ne puisse pas être faite dans le SGBD, ne pas l'introduire dans le MCD est une absurdité.

Je répète : l'important est le MCD. Le MLD, c'est autre chose. C'est juste une solution de la mise en œuvre du MCD.
Et si l'on change de version du SGBDR, on ne remet pas en cause le MCD, mais bien le MLD, puisque les règles qui manquaient avant, on enfin été introduite.

Toute représentation symbolique requiert un apprentissage.

Oui, mais l'apprentissage c'est du savoir et sa mise en œuvre est de l'expérience.
On a beau comprendre un symbole, il est difficile de l'appliquer correctement sans avoir pratiqué aupréalable.

Pour ma part, quand j'appréhende une nouvelle base de données dont j'ignore tout, mon premier reflexe est de réclamer le MCD .

J'ai le même réflexe que toi.

En me relisant, j'ai l'impression de ne pas avoir été suffisamment clair.

1) un MCD est autosuffisant pour concevoir une base de données.
Il n'est pas nécessaire d'avoir un outil pour le dessiner (disons oui car le graphisme en sera meilleur, mais c'est juste une question esthétique).

2) il n'existe pas une et une seule solution pour le MCD. Les symboles aussi évoluent dans le temps. De nouveaux apparaissent.
Mais selon la problématique (je prends cet exemple), une relation à trois pattes peut se traduire aussi par trois relation à deux pattes.
Quelle solution choisir ? Cela dépend du contexte.

[quote="Artemus24"]Maintenant dire qu'elle est la représentation "fidèle", là je pense que l'on met la charrue avant les bœufs.
3) rien à voir avec le MLD (la charrue) et le MCD (les bœufs).
Si j'ai tilté sur le mot fidèle, c'est juste sur sa mise en œuvre.
Il n'existe pas une règle toute faite dans le SGBDR qui permet d'associer le symbole à sa règle, voire de produire le MLD en un clic.
Tu reprends, Escartefigue, le fait qu'il est obligatoire de passer par un déclencheur ou une procédure stockée.
Cela nécessite de faire un développement et qui répondra au besoin fonctionnel. De ce fait, il n'y a rien de "fidèle" puisqu'il faut l'implémenter !

Donc croire que la règle existe car on propose tel symbole, c'est bien mettre la charrue avant les bœufs.
C'est sur ce point, je considère qu'il est impératif de connaitre, par l'expérience trois choses :

3-a) le MCD et la signification des symboles (c'est pas toujours évident pour un béotien).
3-b) le SGDBR et en particulier, tout ce qui peut se faire à la mise en œuvre du MCD, indépendamment de tel ou tel outil.
3-c) l'outil permettant le passage du MCD au MLD.

Autre point, l'outil doit être en adéquation avec la dernière version du SGBDR.

Il faudrait donc attaquer directement la modélisation par le modèle Physique

Cela dépend de la complexité de la modélisation.
Pour trois tables dont l'une est la mère (donc les deux autres filles), il y a juste à mettre en œuvre des clefs étrangères.

Mais en dehors de ce qui est évident, aujourd'hui, vu la complexité de nos bases de données, il faut impérativement un MCD.
Je rejoins Escartefigue sur le fait que l'on a seulement besoin d'un MCD pour appréhender une base de données.

@+

[Paprick]

Bonsoir,

Je ne vais pas répondre à tous les points, même si ça le mériterait . Voici cependant quelques remarques :

RIEN dans tout ce que nous avons dit n'exclut la phase de réflexion, construction, révision, ... nécessaire à toute conception, et surement pas le fait de réaliser un MCD capable de générer ensuite le MLD correspondant et de proposer le script SQL de construction des tables de la BD (même si nous savons tous que, derrière, le BDA devra entrer en action).

Le MCD n'est pas que "théorie" et il sait se montrer aussi "pratique" qu'un MLD. Je ne suis pas certain que tu mesures le pouvoir d'expression des MCD et, à ma connaissance (mais je suis prêt à apprendre), je ne vois pas de cas de MLD qui ne puisse avoir été généré par un MCD. Attention, je parle bien de MLD, pas de MPD avec tout le code SQL qui peut être développé à ce stade (il est d'ailleurs possible que tu fasses une petite confusion entre ce qui relève du MLD ou du MPD).
Je te propose donc un petit jeu : envoie-moi des MLD faits, par exemple avec Workbench (j'aime bien sa représentation "Crow's foot"), et je ferai les MCD correspondant capables de générer exactement les mêmes MLD : tu pourras ensuite juger quel est le plus lisible des deux, et le plus facile à appréhender.

Un outil de modélisation conceptuelle et logique ne doit pas dépendre d'un SGBD particulier : cette distinction se fait au niveau MPD. Le MLD (que certains appelle MLR) se contente de mettre en musique le MCD sous forme de schéma relationnel. Quand on passe à la phase BDA, là on cause physique, et donc MPD.

Si dans le MCD, on dit que telle colonne doit se trouver dans telle table, c'est une vision fonctionnelle, et c'est très bien.
Par contre, après avoir fait le MLT (Le modèle logique de traitement) et que l'on constate pour des raisons de performances de déplacer cette colonne ailleurs, il est inutile de modifier le MCD.
On doit bien sûr modifier le MLD (le modèle logique des données) car nous avons dégradé notre modèle qui reste le MCD.

Et c'est là qu'on perd le fil et que l'on perd de vue le MCD... et donc qu'on juge très vite inutile de commencer par ça... je sais, c'est mal, mais c'est pourtant comme ça que ça se passe dans l'immense majorité des cas.
Pour ma part, dans une telle situation, j'adapte mon MCD et je regénère le MLD.

Il faut comprendre que l'outil n'envisage pas toutes les solutions que l'on peut mettre en œuvre, mais juste ceux de son concepteur.
Il existe des digressions (je pense aux performances) mais qui pour un architecte dans la modélisation trouvera cela pas conforme du tout.
Tant que cela répond au besoin de l'utilisateur et que ça fonctionne correctement, je ne vois pas pourquoi je devrais m'en passer.
Je suis bidouilleur dans l'âme, et pas du tout méthodique, enfin je veux surtout souligner que c'est surtout sur le tas que l'on apprend et pas dans les livres.

Tout cela est évident, mais là encore, on est sur un débat MPD, pas MCD/MLD.

Et le marteau, tu le tiens par le manche ou pas le fer ? Et le clou, tu mets la tête ou la pointe sur la planche ?
Il ne faut pas croire que si c'est évident pour toi que cela l'est pour tout le monde, surtout en ce qui concerne la modélisation.
Rien ne vaut la pratique, même si l'on commet des erreurs, c'est là que l'on apprend !

Tenir le marteau par le manche, mettre le clou dans le bon sens, c'est tout le concept qui entoure l'enfonçage de clou .
Pourquoi veux-tu absolument que le niveau conceptuel ne soit pas capable d'exprimer ça ? Pourquoi faut-il absolument se taper sur les doigts pour apprendre ? Bien sûr que l'expérience est importante, que les erreurs permettent d'apprendre, mais ce n'est pas pour autant qu'une bonne conception, qui limite les accidents de marteau, n'est pas une bonne chose.

Ce n'est pas du tout ce que je dis. Le problème est que vous réfléchissez et c'est bien.
Sauf que dans votre raisonnement, vous êtes au dixième étage, alors que les étudiants sont encore sur le seuil de l'entrée.

Cette vision de l'enseignement est quelque peu vexante... C'est tout notre processus d'apprentissage que tu remets en cause, et visiblement en méconnaissance de cause.
Fais-moi passer en message privé ton adresse, et je t'enverrai le livre que je donne tous les ans à mes étudiants de 1ère année de DUT (bientôt BUT) en support de cours de modélisation, et tu me diras si l'on ne va pas les chercher au seuil de l'entrée pour les accompagner à la montée de chaque étage (sans forcément prétendre les amener de suite au dixième).

L'erreur que la plupart des professeurs font, est la passation du savoir.
Non, le savoir n'est rien si l'on ne comprend pas la démarche qui nous amène à ce savoir.
L'important est la pédagogie et surtout inculquer le raisonnement pour aboutir à ce savoir.
Le par-cœur n'est pas la bonne méthode !

Tu crois vraiment que les enseignants ne distinguent pas le savoir-faire du faire-savoir ? Qu'ils n'ont aucune méthode dans leur pédagogie ?
Mais que veux-tu qu'on leur dise d'apprendre par cœur en modélisation ? Il n'y a rien à savoir par cœur ! On leur apprend justement à raisonner... pour bien concevoir.

Je ne suis pas suffisamment patient pour être enseignant. Je préfère apprendre sur le tas car cela me correspond mieux.

Je te confirme qu'il faut être patient pour êtrre enseignant, et surtout comprendre que tes étudiants peuvent ne pas comprendre ce que tu expliques... et là, tu recommences avec d'autres mots, un autre chemin, encore et encore...

Dans le monde du travail, on demande de trouver des solutions.
Or d'après mon expérience, les universitaires sont trop théorique pour les services (SSII).
Je viens de l'iut et d'une grande école où l'enseignement est plus tourné vers les entreprises.

Je suis enseignant à l'IUT et aussi en Master : on s'adapte au public et, ne me crois pas si tu veux, mais on en connait un rayon en SSII (personnellement j'en ai créé une qui fonctionne depuis plus de 30 ans).
Et il faut arrêter d'opposer théorie et pratique : l'un est au service de l'autre... et vis-versa !

Je répète : l'important est le MCD. Le MLD, c'est autre chose. C'est juste une solution de la mise en œuvre du MCD.
Et si l'on change de version du SGBDR, on ne remet pas en cause le MCD, mais bien le MLD, puisque les règles qui manquaient avant, on enfin été introduite.

Je crois que tu ne places pas le MLD au bon niveau de raisonnement par rapport au MCD et au MPD... Je comprends mieux pourquoi on ne se comprend pas !

Il n'existe pas une règle toute faite dans le SGBDR qui permet d'associer le symbole à sa règle, voire de produire le MLD en un clic.
Tu reprends, Escartefigue, le fait qu'il est obligatoire de passer par un déclencheur ou une procédure stockée.
Cela nécessite de faire un développement et qui répondra au besoin fonctionnel. De ce fait, il n'y a rien de "fidèle" puisqu'il faut l'implémenter !

Je crois vraiment que tu ne places pas le MLD au bon niveau de raisonnement par rapport au MCD et au MPD... Je comprends encore mieux pourquoi on ne se comprend pas !

Autre point, l'outil doit être en adéquation avec la dernière version du SGBDR.

Euh... non... pas au niveau MCD-MLD ; on commence à s'intéresser à la version du SGBDR quand on passe au niveau physique.

Mais en dehors de ce qui est évident, aujourd'hui, vu la complexité de nos bases de données, il faut impérativement un MCD.

Allez, finissons sur ce point où nous sommes parfaitement d'accord !

[escartefigue]

Pour compléter les réponses de Paprick auxquelles je souscris sans la moindre réserve, j'ajoute que

Les contraintes de type "inclusion" sur asso ternaires (et plus) sont assez faciles à déduire du MLD, même si elles apparaissent moins clairement que dans le MCD : il faut analyser les colonnes participant à la PK des tables associatives pour trouver les manquants. Mais bon, ça reste faisable facilement.
Les contraintes de type "exclusion" ou "partition", elles, sont absolument impossibles à trouver dans le MLD, et pour cause : elle sont traduites soit par des trigger, soit par des udf associées à des contraintes check. Autant dire qu'à part consulter tout le catalogue d'objets, la tâche est rude !
Alors que ces mêmes contraintes sont visibles par un symbole dans le MCD.
Bref, on ne m'ôtera pas de l'idée que modéliser le "quoi" avant de modéliser le "comment" est la meilleure des démarches, et cela aussi bien avec du papier, un crayon et une gomme qu'avec un logiciel conçu pour

En tout cas ce fil de discussion m'aura appris l'origine du patronyme "Looping"

[Artemus24]

Salut à tous.

Je ne suis pas certain que tu mesures le pouvoir d'expression des MCD

Je ne comprends pas ce que tu essayes de me dire. Qu'est-ce que tu veux dire par "le pouvoir d'expression" ?

il est d'ailleurs possible que tu fasses une petite confusion entre ce qui relève du MLD ou du MPD

Tu as raison.

tu pourras ensuite juger quel est le plus lisible des deux, et le plus facile à appréhender.

Pas la peine de juger, j'ai déjà répondu à cette question. Le MCD est bien plus lisible parce qu'il est concis.

Un outil de modélisation conceptuelle et logique ne doit pas dépendre d'un SGBD particulier

Nous sommes d'accord.

Quand on passe à la phase BDA, là on cause physique, et donc MPD.

Je suis encore d'accord.

Je fais une distinction qui n'a peut-être pas lieu d'être.
Celui qui conçoit la modélisation conceptuelle des donnés (MCD) est un architecte (je ne trouve pas le mot exacte, peut-être le concepteur).
Il est comme l'analyste ou encore un architecte, c'est-à-dire celui qui va faire le plan de construction d'une maison.

Celui qui va réaliser l'ouvrage, à savoir la base de données physique qui est en général le DBA (data base administrator).
Il est comme le programmeur ou encore le maitre d'œuvre dans la construction.

Je fais cette distinction car ce sont des métiers différents à mes yeux et donc des compétences différentes.
Le DBA n'a rien à faire des choix du concepteur. Son travail est de concevoir le modèle physique des données.

Pour ma part, dans une telle situation, j'adapte mon MCD et je regénère le MLD.

C'est là que l'on ne se comprends.
Ce qui est du domaine physique appartient au DBA et ce qui est du domaine logique appartient à l'architecte.

Pourquoi veux tu absolument que le niveau conceptuel ne soit pas capable d'exprimer ça ?

Je pense que tu poses la mauvaise question.
Comment le DBA va créer le modèle physique si le symbole utilisé par l'architecte n'existe pas en tant qu'objet ?
Je pense que l'on s'écarte du sujet.

Bien sûr que l'expérience est importante, que les erreurs permettent d'apprendre

Oui, je suis d'accord.

mais ce n'est pas pour autant qu'une bonne conception, qui limite les accidents de marteau, n'est pas une bonne chose.

De quoi parles-tu ici ? Dans mes propos, je parlais d'apprentissage de l'étudiant.
J'ai l'impression que tu parles de la finalisation en entreprise d'une bonne conception.

La bonne conception ne s'acquiert que par la pratique.
Si la première fois, tu te tapes sur les doigts, le problème vient soit de toi, ou soit de celui qui t'a montré comment faire.
La deuxième fois, tu t'y prendra différemment, tu genres faire tenir le clou par quelqu'un d'autre.
Puis quand tu auras compris comment faire cela correctement, tu passes à l'étape suivante, la généralisation du plantage de clou.

Il ne s'agit pas de résoudre les problèmes en se procurant des bouts de sparadrap pour soigner tes doigts.
Il s'agit de trouver un autre moyen afin d'éviter de se taper sur les doigts. Par exemple utiliser un pistolet à clous.

Cette vision de l'enseignement est quelque peu vexante...

Je suis désolé si je vous ai vexé, mais c'est ce que j'ai connu aussi bien à l'IUT qu'en école d'ingénieur.
Cours d'amphithéâtre sans possibilité de communication, manque de pédagogie, travaux pratiques par toujours très clair ...

Fais-moi passer en message privé ton adresse, et je t'enverrai le livre que je donne tous les ans à mes étudiants de 1ère année de DUT

Je possède ton livre : "modélisation conceptuelle des données - une démarche pragmatique" (ISBN : 979-10-699-3087-2")

Tu crois vraiment que les enseignants ne distinguent pas le savoir-faire du faire-savoir ?

Je n'ai plus vingt ans. Quand j'allais en école d'ingénieur, l'internet n'existait pas, et j'ai commencé à connaitre les premiers PC (personnal computer) comme l'ITT 2020 qui était un copie belge de l'APPLE II+.
Nos travaux, à l'IUT, se faisant sur un IRIS 80 dans un centre de calculs ou un SOLAR-1640, et parfois en entreprise comme avc le PDP-11.
C'était presque le début de l'enseignement de l'informatique en IUT et tous les IUT de France n'avait pas un centre de calculs à leur disposition.
Le seul professeur (celui qui détient une chair de professorat était un professeur de physique-chimie reconverti.
Les autres étaient des maitres assistants dont certains étaient encore étudiant à l'université. En école d'ingénieur, c'était pas mieux. C'était au siècle dernier.

Qu'ils n'ont aucune méthode dans leur pédagogie ?

Depuis mon époque, il y a eu certainement beaucoup de progrès de fait.
En école d'ingénieur, en enseignait la méthode Warnier. Merise, c'est bien plus tard dans les années 1980.

Et il faut arrêter d'opposer théorie et pratique : l'un est au service de l'autre... et vis-versa !

La théorie, je m'en fout. Je recherche du concret, quelque chose qui fonctionne et produit des résultats immédiatement.
En entreprise, on n'a pas le temps de tergiverser. Nous sommes pris par le temps, et surtout les délais et les couts de mise en oeuvre.

Je crois que tu ne places pas le MLD au bon niveau de raisonnement par rapport au MCD et au MPD...

J'oppose le modèle logique (ou conceptuel) au modèle physique dans mon raisonnement. Je devrais plutôt parler de MCD et MPD.

Pour compléter les réponses de Paprick auxquelles je souscris sans la moindre réserve

Je dois avoir un problème de compréhension car dans ton avant dernier message, j'ai cru comprendre que tu avais la même approche que moi.
Je chipote, mais à mes yeux cela a de l'importance.
Je pense que cette différence d'approche résulte de la différence du parcours professionnel et de ma façon de raisonner.

Les contraintes de type "exclusion" ou "partition", elles, sont absolument impossibles à trouver dans le MLD

Tu fais bien de parler des tables partitionnées. Pour ma part, c'est plus du coté physique que le problème se traite.
Je ne sais même pas si cela a un sens dans le MCD.

Quand a certaines contraintes, si elles ont une raison fonctionnelle, elles doivent apparaitre dans le MCD.

elle sont traduites soit par des trigger, soit par des udf associées à des contraintes check.

Nous ne sommes plus du tout dans le modèle conceptuel mais bien dans le modèle physique.
Je suppose que c'est dans le modèle logique que l'on explique le savoir-faire, c'est-à-dire entre ce que l'on veut faire et comment le faire.

Bref, on ne m'ôtera pas de l'idée que modéliser le "quoi" avant de modéliser le "comment" est la meilleure des démarches

Si je rejoins l'idée exprimée par isabelle.letrong, c'est sur l'extrême simplification d'un modèle où l'on peut passer directement au physique
La plupart du temps, quand je donne un exemple, dans ce forum, de requêtes complexes à mettre en œuvre, je ne fais pas une conceptualisation des données.
Je passe au modèle physique en respectant le basique d'une bonne modélisation.

Si maintenant, l'utilisateur demande une conceptualisation des données, il se trompe de forum.
Je crois en fait, que le bémol que j'ai exprimé n'a pas bien été compris.

A part cela, oui, le MCD est la première démarche à entreprendre.

et cela aussi bien avec du papier, un crayon et une gomme qu'avec un logiciel conçu pour

Je suis allergique à l'outil, hormis pour l'aspect graphique qui est bien plus esthétique que des gribouillis sur une feuille de papier.

@+

[isabelle.letrong]

J'étais absente depuis 2 jours et je permets de reprendre cette discussion bien intéressante.

Sur le fond, je ne peux que souscrire à vos points de vues Paprick et escartefigue, c'est vrai le 'pouvoir d'expression d'un MCD', pour citer Paprick, est très puissant. Ainsi comme le précise judicieusement escartefigue :

../Les contraintes de type "exclusion" ou "partition", elles, sont absolument impossibles à trouver dans le MLD,/..

Oui, rien de plus lumineux qu'un simple 'X' ou 'T' sur in triangle d'héritage...

Mais ce qui me gène quelque peu, c'est le coté un peu approximatif des outils que nous évoquons au niveau du presse-bouton : si la transformation MCD vers MLD est certes automatique (le passage de l'un à l'autre est ainsi lumineusement simple dans Looping) il en va tout autrement lorsqu'il s'agit de générer du script SQL et donc un MPD : il faut reprendre ces scripts pour les rendre opérationnels et performants sur tel ou tel SGBD. Par exemple, sur Looping, concernant la définition d'un identifiant entier je n'ai pas trouvé le moyen de le définir comme non signé. Comme en général dans le SGBDR on utilise pour ces clés primaires des entiers auto-incrémentés dont la première valeur par défaut est 1, on se retrouve d'un coup privé de la moitié des clés...

Etre obligé de reprendre les scripts générés est pour moi une chose pénible qui pose question sur la synchronisation à terme d'un MCD et du MPD... Attaquer directement avec MySQL Workbench au niveau du MLD, même si cela comporte des inconvénient relativement 'à son pouvoir d'expression' me permet d'éviter cela tout en flattant mon coté "optimisation de l'effort".

Par ailleurs

escartefigue
Pour ma part, quand j'appréhende une nouvelle base de données dont j'ignore tout, mon premier reflexe est de réclamer le MCD

Moi aussi - lorsqu'il existe - mais un de mes premiers réflexes pour valider la solidité du MCD est de faire immédiatement un petit tour du coté du MPD et de vérifier, par exemple, le nombre de colonnes 'DEFAULT NULL' . C'est souvent édifiant pour valider la qualité du travail qui a été fait en amont ! L'existence d'un MCD n'est en aucun cas la garantie d'un système opérationnel bien conçu, surtout quand on peut lire de la part de Merisiens, sur le site même de developpez, ce type d'information (voir en particulier la 4ème possibilité, et même les 2ème et 3ème !): https://merise.developpez.com/faq/?p...CD-dans-le-MLD.

Bref je rêve aussi d'un outil complet, où on définit à un seul endroit dans le modèle données, règles et contraintes, sans avoir de retouches à faire lorsque l'on passe au développement. Pour l'instant, dans l'univers MySQL, je reste avec le crayon, le papier (allez un document numérique !) et MySQL Workbench....

[Paprick]

Bonjour,

Finalement, nous sommes d'accord sur l'essentiel, l'incompréhension venant essentiellement de ce que représente vraiment le MLD.
Il est clair que la finalisation du niveau physique (MPD) est l'affaire du DBA, et que bon nombre d'optimisations et autres programmations de contraintes se jouent à ce niveau.

En fait, le débat initial, suite au post de isabelle.letrong, était de modéliser d'entrée au niveau MLD (type Workbench) ou au niveau MCD (schéma E/A ou diagramme de classes UML : personnellement, je préfère les schéma E/A). Et c'est là que je pense que le MCD exprime bien mieux les contraintes que le MLD (cf. message d'escartefigue), ce dernier n'étant que la traduction relationnelle du modèle conceptuel, essentiellement par la mise en œuvre des clés étrangères. Ensuite, place au MPD et au DBA !

Je fais une distinction qui n'a peut-être pas lieu d'être.
Celui qui conçoit la modélisation conceptuelle des donnés (MCD) est un architecte (je ne trouve pas le mot exacte, peut-être le concepteur).
Il est comme l'analyste ou encore un architecte, c'est-à-dire celui qui va faire le plan de construction d'une maison.
Celui qui va réaliser l'ouvrage, à savoir la base de données physique qui est en général le DBA (data base administrator).
Il est comme le programmeur ou encore le maitre d'œuvre dans la construction.
Je fais cette distinction car ce sont des métiers différents à mes yeux et donc des compétences différentes.
Le DBA n'a rien à faire des choix du concepteur. Son travail est de concevoir le modèle physique des données.

On est bien d'accord. Mais crois-moi, les plans de l'architecte donnent de sacrées indications (et même une base préfabriquée ) pour la construction finale et optimale.

La bonne conception ne s'acquiert que par la pratique.

"aussi" mais pas "que".

Je possède ton livre : "modélisation conceptuelle des données - une démarche pragmatique" (ISBN : 979-10-699-3087-2")

Très bonne acquisition ! Je plaisante, mais dis-moi quand même si tu trouves que la démarche est du type "direct au dixième étage" ?

La théorie, je m'en fout. Je recherche du concret, quelque chose qui fonctionne et produit des résultats immédiatement.
En entreprise, on n'a pas le temps de tergiverser. Nous sommes pris par le temps, et surtout les délais et les couts de mise en oeuvre.

Je pense que chaque chose a sa place, et doit rester à sa place. Se "foutre" de la théorie et foncer tête baissée dans la pratique n'est peut-être pas la meilleure façon de produire de bons résultats immédiatement.
Parfois, le temps que l'on prend à tergiverser peut s'avérer être un investissement rentable.

A part cela, oui, le MCD est la première démarche à entreprendre.

Je suis allergique à l'outil, hormis pour l'aspect graphique qui est bien plus esthétique que des gribouillis sur une feuille de papier.

Hormis le côté esthétique (et aussi quand même, la possibilité de générer le MLD et une première base SQL), les outils sont intéressants pour l'évolution, le suivi et la modification des modèles.

[Paprick]

Bonjour Isabelle,

Bref je rêve aussi d'un outil complet, où on définit à un seul endroit dans le modèle données, règles et contraintes, sans avoir de retouches à faire lorsque l'on passe au développement.

Je suis entièrement d'accord !
Moi aussi, je rêve de cet outil complet dans lequel toutes les contraintes pourraient être décrites : c'est la seule façon de conserver la modélisation conceptuelle au cœur des projets ; en effet, si l'on est obligé d'adapter le MLD ou le MPD pour répondre à telle ou telle autre contrainte, le MCD sera très vite abandonné.
C'est pourquoi, j'essaie de développer Looping en ce sens. Et pour répondre aux problèmes que tu as soulevés, voici quelques éléments :

• Looping propose un certains nombre de types par défaut (les plus utilisés), mais tu as la possibilité de prédéfinir tes propres types dans le menu "Paramètres SQL".
• Les valeurs par défaut (NULL par exemple) peuvent être définies dans le cadre "Complément" des rubriques.
• Des règles contenant du code SQL peuvent être rajoutées de manière à compléter le script SQL ; et depuis la version 3.1, le code correspondant aux contraintes peut être saisi directement dans la définition de la contrainte.

Bref, l'idée est de faire en sorte de générer un code SQL complet directement issu du MCD.
S'il y a des choses qui ne peuvent pas être faites en ce sens, rendez-vous sur le forum Looping de Developpez.com pour faire avancer l'outil !

[escartefigue]

Moi aussi - lorsqu'il existe - mais un de mes premiers réflexes pour valider la solidité du MCD est de faire immédiatement un petit tour du coté du MPD et de vérifier, par exemple, le nombre de colonnes 'DEFAULT NULL' . C'est souvent édifiant pour valider la qualité du travail qui a été fait en amont ! .

Tout fait d'accord aussi
Le MCD pour avoir la vue d'ensemble, le plan macroscopique et le MPD pour appréhender les détails. L'un comme l'autre ont leur raison d'être et le passage de l'un à l'autre, même quand il est en grande partie automatisé, nécessite l'expertise du DBA.
Fort heureusement, notre intelligence (sans prétention aucune) reste utile dans ce monde envahi par les automates et les robots

J'ai vu des déploiements "en l'état" du script par défaut, c'est parfois cocasse.

[escartefigue]

Tu fais bien de parler des tables partitionnées. Pour ma part, c'est plus du coté physique que le problème se traite.
Je ne sais même pas si cela a un sens dans le MCD.

Je parlais de contrainte de partition, c'est à dire d'une règle de gestion définie par le métier (la MOA), sans aucun lien avec le partitionnement des tables qui est un mode d'implémentation technique en fonction du volume et des accès concurrents et dont le métier n'a pas connaissance .

Exemple de contrainte de partition : une personne est une personne physique ou une personne morale, pas les deux
Cette contrainte est notée XT dans le MCD et elle s'évapore dans le MLD.
On doit par contre la retrouver sous forme de triger ou d'UDF dans le catalogue relationnel de la base de données
Ce qui corrobore les propos d'Isabelle Letrong : bien que la contrainte apparaisse dans le MCD, il faut s'enquérir de sa traduction technique en allant vérifier ce qui se passe dans les objets installés. Le MCD n'est sur ce chapitre qu'une déclaration d'intention, mais ou moins l'information y est présente, contrairement au MLD.

[isabelle.letrong]

Paprick
Il est clair que la finalisation du niveau physique (MPD) est l'affaire du DBA, et que bon nombre d'optimisations et autres programmations de contraintes se jouent à ce niveau.

Sur cette question je trouve qu'il manque réellement un profil entre le concepteur modélisateur du MCD et le DBA : c'est l'architecte de données relationnelles.
En réalité :
- d'un coté le DBA ne remet jamais en cause, en proposant une solution, le schéma relationnel établi. il expliquera pourquoi une requête rame, en améliorera la performance via des biais techniques mais très rarement en reconcevant l'architecture des données car ce n'est pas son rôle
- de l'autre le concepteur du MCD se sera préoccupé de la normalisation relationnel mais, la plupart du temps, en ne dépassant pas le stade de la 3NF.

Tout cela conduit bien souvent à des déceptions, des erreurs car, par exemple, un viol de 4NF peut produire des résultats inattendus et farfelus !

Au bout du compte avant de confier le paquet à un DBA, et avant de rencontrer des problèmes, il y a lieu de passer le MCD (et son MLD déduit automatiquement) au shaker d'un architecte de données maitrisant les questions de normalisation et les conséquences de la dénormalisation (trop souvent invoquée en fausse barbe d'une optimisation des performances)

[Paprick]

Au bout du compte avant de confier le paquet à un DBA, et avant de rencontrer des problèmes, il y a lieu de passer le MCD (et son MLD déduit automatiquement) au shaker d'un architecte de données maitrisant les questions de normalisation et les conséquences de la dénormalisation (trop souvent invoquée en fausse barbe d'une optimisation des performances)

Tout à fait d'accord, l'idéal étant que le concepteur possède cette compétence normalisation... ce qui n'est pas forcément toujours le cas, et je pense d'ailleurs que c'est ce qui permet de distinguer les très bons concepteurs.

[Artemus24]

Salut à tous.

J'ai peu d'expérience en ce qui concerne la modélisation d'une base de données.
J'ai lu les livres de merise ainsi que ton livre Paprick.

dis-moi quand même si tu trouves que la démarche est du type "direct au dixième étage" ?

Un bon livre de vulgarisation pour aborder en tant que débutant le MCD.
Je n'ai pas appris grand chose car je connaissais déjà la symbolique et ce à quoi cela se rapporte.

Peut-être que je devrais m'intéressé plus à ce que fait fsmrel.

Se "foutre" de la théorie et foncer tête baissée dans la pratique n'est peut-être pas la meilleure façon de produire de bons résultats immédiatement.

Mauvaise interprétation. Je connais la théorie, suffisamment pour me débrouiller, mais ce n'est pas ce qui m'intéresse.
C'est le coté système, ou physique de la mise en place d'une base de données qui m'intéresse.

Parfois, le temps que l'on prend à tergiverser peut s'avérer être un investissement rentable.

Comme je reste à un niveau assez basique de la modélisation, cela ne m'apporte rien.

les outils sont intéressants pour l'évolution, le suivi et la modification des modèles.

Justement, cela ne m'intéresse pas de passer par un outil.
Je préfère le faire directement par des scripts sql. C'est le coté technique qui m'intéresse, la fonctionnelle bien moins.

A mon niveau, je fais le grand écart entre le MCD qui est la représentation de la futur base de données et le MPD, qui est la finalisation physique, en tant que DBA.
Au milieu, je ne vois pas trop l'intérêt de développer un niveau logique.
Il y a peut être de ma part une quelconque incompréhension car je suis plutôt technique (bidouiller afin d'optimiser) qu'architecte.
Ce n'est pas une question de connaissance, mais la modélisation ne m'intéresse pas trop.

Je pense que tu as dû comprendre, que le presse bouton ne m'intéresse pas.
Les seuls forums que je fréquente en ce qui concerne les bases de données sont ceux de mysql et firebird.
Pourquoi pas celui de Microsoft SQL Server ? Car je n'ai pas envie de me prendre la tête avec SQLPRO.

A bien vous comprendre tous, il me semble que vous dédaignez l'aspect physique des bases de données.
Pour vous, cela concerne le passage du conceptuel au physique, juste en faisant un clic dans l'outil.
Désolé de le dire, mais mettre en place un SGBDR et ses bases de données ne se fait pas en un clic.
Il y a l'aspect système, sécuritaire, performance, volumétrie, gestion des sauvegardes, reprise en cas de plantage, intégrité des données ... qui st du ressort du DBA.

Cette contrainte est notée XT dans le MCD et elle s'évapore dans le MLD.

XT avec X pour "ou exclusif" et T pour "total".
Un genre est soit masculin ou soit féminin.
C'est l'un ou l'autre mais pas les deux et il y a que ces deux possibilités.

Le MCD n'est sur ce chapitre qu'une déclaration d'intention, mais ou moins l'information y est présente, contrairement au MLD.

C'est pourquoi, j'aime bien l'aspect concis du MCD où tout est dit.

Dans l'ensemble des propos tenus, nous sommes d'accord.

@+

[Paprick]

Bonsoir,

Juste un petit mot pour corriger une partie de ton post :

XT avec X pour "ou exclusif" et T pour "total".
Un genre est soit masculin ou soit féminin.
C'est l'un ou l'autre mais pas les deux et il y a que ces deux possibilités.

Non, le X concerne l'eXclusion mutuelle qui, associée à la Totalité (T), donne une partition (XT) : par exemple, dans un héritage, chaque entité du sur-type est alors concernée par une et une seule entité d'un des sous-types.
Puisque tu as mon livre, tu peux trouver cette partie "contraintes inter-associations" à la page 222 et suivantes.

Peut-être que je devrais m'intéressé plus à ce que fait fsmrel.

Excellente idée ! fsmrel est aussi calé et rigoureux en conception et en modélisation, qu'il est expert dans un rôle de DBA.

[SQLpro]

Bonsoir,

Je ne vais pas répondre à tous les points, même si ça le mériterait . Voici cependant quelques remarques :

RIEN dans tout ce que nous avons dit n'exclut la phase de réflexion, construction, révision, ... nécessaire à toute conception, et surement pas le fait de réaliser un MCD capable de générer ensuite le MLD correspondant et de proposer le script SQL de construction des tables de la BD (même si nous savons tous que, derrière, le BDA devra entrer en action)....

Pour compléter ce que tu dis, dans les cours de modélisation que je donne, que ce soit en école d'ingé ou en formation pro, je présente le MCD comme étant le modèle sémantique (on explique les associations entre entités),le MLD comme le modèle technique (comment sont articulées les relations) avant le modèle physique (particularité de chaque SGBDR...).

Pour information voici la différence :


La le MPD ne permet pas de comprendre le "lien" entre les deux tables ! Ça peut être conduit, se fait écraser, vole...



La le MCD montre parfaitement la sémantique !

A +