Discussion :

[salutagama]

Bonjour,
j'aimerai bien comprendre la différence entre MCD, MLD et MPD.
Ce que ça change entre eux 3 aux niveau des cardinalités, des relations entre les tables etc.
Merci d'avance.

[Mat.M]

Bonjour,
j'aimerai bien comprendre la différence entre MCD, MLD et MPD.

pour commencer quel est l'intérêt de faire un modèle conceptuel de données ? Je vous laisse réfléchir là-dessus.
Pour vous mettre sur la voie on peut faire l'analogie avec la construction d'une maison ou d'un bâtiment.

[SQLpro]

Extrait de mon prochain livre sur le langage SQL chapitre 2 :
"
2.4 – les différents modèles
La modélisation d’un problème c'est à dire le passage du monde réel à sa représentation informatique, se définie en plusieurs étapes pour parvenir à son intégration dans un SGBD et permettre la manipulation des données par le langage SQL.

Classiquement, le processus de modélisation des données passe par quatre phases : la réalisation d'un modèle conceptuel (en quelque sorte une étude technique détaillée de l’organisation des données au sein de la base) suivi de sa traduction en un modèle logique (le schéma mathématique de relations), puis de son portage dans un SGBDR donné sous le forme d’un modèle physique (une adaptation au logiciel de bases de données ciblé) et enfin complété par un modèle externe (présentation des données) facilitant aux utilisateurs finaux, la compréhension des données et leur manipulation.

L’ordre naturel des phases est le suivant :
1. modélisation conceptuelle (MCD);
2. modélisation logique (MLD);
3. modélisation physique (MPD);
4. modélisation externe (MED).
Chacune des phases peut enrichir le modèle avec un niveau de détail que ne permet pas le précédent.

A +

[escartefigue]

Bonjour,

Le MCD (Modèle Conceptuel des Données) c'est le quoi.
Il s'établit à partir des règles de gestion fournies par le métier.
Les types d'entités (rectangles) correspondent aux objets de gestion (les clients, les commandes, les articles, les entrepôts)...
Les associations (ovales) correspondent aux interactions entre objets de gestion.
Dans un MCD, il n'y a pas de table, pas plus que de colonnes ni d'index, bref, aucun objet SQL puisqu'on en est au stade conceptuel.

Le MLD (Modèle Logique des Données) est un modèle tabulaire.
À ce stade les types d'entités et certaines associations deviennent des tables, les identifiants deviennent des clefs primaires et des clefs étrangères, les attributs deviennent des colonnes.

Et le MPD (Modèle Physique des Données), c'est un MLD décliné en fonction du choix du SGBD et de sa version, chaque SGBD ayant ses particularités.

[SQLpro]

Bonjour,

Le MCD (Modèle Conceptuel des Données) c'est le quoi.
Il s'établit à partir des règles de gestion fournies par le métier.
Les types d'entités (rectangles) correspondent aux objets de gestion (les clients, les commandes, les articles, les entrepôts)...
Les associations (ovales) correspondent aux interactions entre objets de gestion.
Dans un MCD, il n'y a pas de table, pas plus que de colonnes ni d'index, bref, aucun objet SQL puisqu'on en est au stade conceptuel.

Le MLD (Modèle Logique des Données) est un modèle tabulaire.
....

Non, relationnelle le tabulaire c'est le MPD !

A +

[escartefigue]

Ce n'est pas parce que le MLD ne propose pas les ordres CREATE TABLE (et pour cause, la syntaxe diffère selon le choix du SGBD et sa version, ce que seul le MPD gère), que les tables n'y sont pas présentes. Un MLD ce sont bel et bien des tables avec des clefs primaires et des clefs étrangères.
Par contre, seul le MPD associe le DDL qui permet de créer physiquement les objets.
En résumé MLD et MPD sont tous deux des modèles tabulaires, par opposition au MCD.

[SQLpro]

Non désolé ce ne sont pas des tables à ce stade et bien des relations... Des tables tu pourrait préciser des index, le mode de stockage, etc...

A +

[escartefigue]

Les index ne sont créés qu'au stade du MPD, parce que la syntaxe du DDL change selon le choix du SGBD.

Voici quelques références parmi tant d'autres qui confirment que le MLD est bel et bien un modèle tabulaire

https://louisvandevelde.be/index.php?dos=my&fic=meris

Niveau logique (MLD)
Les entités mises en relation deviennent des tables.

http://www.colar.net/as/cours/analyse/mld.html

2. Du M.C.D. au M.L.D.
Règle 1: Toute entité se transforme en fichier (ou table logique).

https://web.maths.unsw.edu.au/~lafay...merise/mld.htm

Chaque classe d'entité du modèle conceptuel devient une table dans le modèle logique

https://www.dynamic-mess.com/develop...ssiner-sa-bdd/

Etape 2 : Le MLD : le modèle logique de données
Explication rapide : il s'agit de convertir notre MCD en un ensemble compréhensible pour un SGBD. Les entités sont remplacées par des des éléments de bases de données : les tables.

Wikipédia, qui n'est certes pas exempt de tout défaut, mais qui le confirme aussi
https://fr.wikipedia.org/wiki/Merise...s_donn%C3%A9es

La transcription d'un MCD en modèle logique des données ou encore appelé schéma relationnel s'effectue selon quelques règles simples qui consistent d'abord à transformer toute entité en table, avec l'identifiant comme clé primaire

Ou encore cette réponse de Fsmrel qu'on ne saurait soupçonner de manquer de rigueur en ce qui concerne la modélisation des données

L’étape MLD (Modèle Logique de Données) se situe chronologiquement juste après l’étape MCD et revient à présenter les objets du MCD sous une forme compréhensible par un SGBD. Pour faire court, dans un contexte SGBD relationnel, les objets représentés sont désormais des tables (disons SQL) et les liens qui les unissent.

En d'autres termes, il ne faut pas confondre l'objet "table" du modèle relationnel (c'est à dire la relation) présent dès le MLD, et l'objet SQL "table" qui lui n'est créé qu'au stade MPD. Mais la table SQL est bien le reflet de la table relationnelle du MLD, adaptée au dialecte du SGBD sous-jacent.

[SQLpro]

Je ne suis toujours pas d'accord. L'ellipse que fait fsmrel est tangente...

Je viens de regarder les ouvrages originaux (en papier) de dominique Nancy qui a oeuvré avec Tardieu sur Merise et c'est bien de relations qu'il parle, même si il parle d'une présentation tabulaire...
Même chose avec Chris Date dans son ouvrage Apress "The Relational Datase Dictionnary" dans deux entrées il fait bien la distinction entre le modèle purement logique : des relations dépourvues de la moindre considérations physique (pas de type,, de stockage, d'index... mais des attributs des contraintes et des domaines) et une implémentation physique, quelle qu'elle soit, par exemple des tables ou autre objet...

D'ailleurs s tu utilise Power AMC / Power Designer, il fait bien la différence entre les deux types de modèles...

A +

[escartefigue]

Philip Bernstein écrit dans son algorithme de synthèse concernant la 3e forme normale :

2. THE RELATIONAL MODEL
2.1 Relations
In Codd’s relational database model, mathematical relations over a set of domains
are used to describe connections among data items [7]. However, not all relations
serve equally well in describing these connections [S], To judge the efficacy of various
classes of relations, we begin by reviewing the terminology associated with the relational model.
Conceptually, a relation is a table in which each column corresponds to a distinct
attribute and each row to a distinct entity (or tuple) .

Se qui se traduit par

[...] Conceptuellement, une relation est une table

Et Edgar Frank Codd écrit dans son Relational Model for database management

1.5 • Tables versus Relations
Actually, the terms "relation" and "table" are not synonymous. As discussed
earlier, the concept of a relation found in mathematics and in the relational
model is that of a special kind of set. The relations of the relational model,
although they may be conceived as tables, are then special kinds of tables.
In this book they are called R-tables, although the term "relation" is still
used from time to time to emphasize the underlying concept of mathematical
sets, to refer to the model, or to refer to languages developed as part of
implementations of the model.

Ce qui se traduit par

1.5 • Tables versus relations
[...] Les relations du modèle relationnel, bien qu'elles puissent être conçues comme des tables, sont alors des types particuliers de tables.
Dans ce livre, elles sont appelées tables R, bien que le terme «*relation*» soit encore utilisé de temps en temps pour souligner le concept sous-jacent des ensembles mathématiques, pour faire référence au modèle ou pour faire référence aux langages développés dans le cadre des implémentations de la modèle.

Comme quoi

[fsmrel]

Salve omnes,

escartefigue a écrit (post #6)

Un MLD ce sont bel et bien des tables avec des clefs primaires et des clefs étrangères.

Fred, en réponse tu écris dans le post #7 :

Non désolé ce ne sont pas des tables à ce stade et bien des relations...

Il est plus que temps d’éviter de confondre relvar (variable relationnelle) et relation !

Dans l’ouvrage (dont tu fais mention dans le post #9) The New Relational Database Dictionary, Chris Date précise bien qu’une relation est une valeur, à savoir une valeur prise par une relvar.

Donc pour toi, un MLD se situe au niveau des valeurs !

Dans le même ouvrage, Date définit ainsi le terme Table :

SQL analog of either a relation or a relvar, as the context demands.

A mon sens, le MLD décrit l’en-tête de chaque relvar (ou table) de l’univers du discours et les associations entre les relvars (ou tables).

Si un objet du MLD décrit une structure logique, c’est certainement celle d’une relvar, mais aussi celle d’une table, car au niveau logique cette structure répond à la définition de l’en-tête (heading) : ensemble d’attributs, dans lequel chaque attribut est une paire de la forme <A,T>, où A est un nom d’attribut et T le type de l’attribut A, et ceci vaut aussi bien pour les relvars que pour les relations (cf. dans l’ouvrage de Date, la rubrique Heading)

J’ai déterré des diagrammes que j’avais réalisés en 2009, où je modélisais avec PowerAMC le fameux trio S, P, SP que l’on retrouve dans tous les bouquins de Chris Date, donc bien connu des lecteurs (En passant, je signale que Date dit bien qu’il n’a pas la paternité du trio, mais qu’il l’a emprunté à Ted Codd (Reddemus Codde quid est Coddi).

Variantes du MLD du trio :

PowerAMC


Looping


Looping (textuel)

Je viens de regarder les ouvrages originaux (en papier) de dominique Nancy qui a oeuvré avec Tardieu sur Merise et c'est bien de relations qu'il parle, même si il parle d'une présentation tabulaire...

On ne sait pas de quel ouvrage tu parles en l’occurrence. En tout cas tu peux aussi consulter l’ouvrage en ligne, notamment le chapitre 13 qui concerne le MLD (et reprend exactement la version papier (Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001)) : Modélisation logique des données.

Dans l’ouvrage dont je fais mention, selon Dominique Nanci (et pas Nancy !), le MLD est la transformation du MOD (en fait du MCD), adapté au SGBD (voire au système de gestion de fichiers) !

Dans ce chapitre 13, j’ai cherché le mot « tabulaire » et ne l’y ai point trouvé.

Nanci y écrit (paragraphe Modèle logique de données relationnel) :

« Le modèle relationnel présente deux aspects fondamentaux : une algèbre permettant de manipuler des tables ou relations »

=> Pour Nanci, tables et relations sont synonymes. A cet égard, je rappelle une fois de plus qu’une relation est une valeur, dotée d’une en-tête et d’un corps. C’est la relvar (variable relationnelle) qui prend des valeurs qui sont des relations.

A juste titre, Nanci préfère parler de tables, pour éviter les erreurs d’interprétation :

« Notons que le concept de relation utilisé ici n'a pas la même signification que celui utilisé dans le formalisme entité-relation. Aussi préférerons-nous appeler ce concept table. »

Etc.

Bref, quand escartefigue écrit qu’ « un MLD ce sont bel et bien des tables », on ne peut que lui donner raison !

[Paprick]

Bonjour,

En complément, voici le MLD version "Crow's foot" de Looping qui se rapproche très fortement de la représentation PowerAMC :

Concernant le reste de votre débat, j'avoue avoir une approche bien plus basique, en considérant simplement que le MLD est là pour définir le schéma relationnel de la BD avec l'ensemble de ses tables.
Je situe la partie physique plutôt à partir du DDL.
C'est certes simpliste, mais compréhensible par tous .

[SQLpro]

... Bref, quand escartefigue écrit qu’ « un MLD ce sont bel et bien des tables », on ne peut que lui donner raison !

Donc toute table est une relation.... ! Evidemment non car une table peut ne pas avoir de clé....

C'est pour cela que je donne toujours comme conseil nécessaire et obligatoire de ne pas confondre table ou relation, ou bien de préciser que :
UNE TABLE EST RELATIONNELLE si et seulement si :
1) elle possède une clé
2) toutes ses valeurs sont atomiques
3) il n'y a pas de NULL

A +

[fsmrel]

Bonjour Paprick,

Pardonne-moi d’avoir oublié de montrer le MLD "Crow's foot", qui est évidemment plus riche que celui que j’ai présenté.

Pour le reste, la discussion est plutôt byzantine, mais il s’est agi pour moi de défendre la position du Capitaine, face aux approximations expéditives du champion de SQL server. Castigam ridendo mores!

Keep up the good work!

[fsmrel]

Ave,

Un MLD ce sont bel et bien des tables avec des clefs primaires et des clefs étrangères.

Donc toute table est une relation.... ! Evidemment non car une table peut ne pas avoir de clé....

Que le Sorry Query Language (aka Askew Wall) permette qu’une table soit un sac est une chose, mais il n’en va pas de même pour le MLD : toute table y est obligatoirement munie de sa clé primaire, sinon le MLD est réputé invalide. Tous les Nanci, Tabourier, Tardieu, Rochfeld, et autres champions de Merise sont d’accord là-dessus et disent bien que chaque identifiant dans un MCD donne lieu impérativement à une clé primaire dans le MLD qui en est issu. Je répète : toute table dans un MLD possède une clé primaire, sinon le MLD n’est pas valide, il est bon pour la poubelle, ça n’est pas un MLD.

Les AGL sérieux tels que PowerAMC, DB-MAIN, Looping, invalident effectivement les MLD sans clés primaires correctes, c’est-à-dire ne garantissant pas l’unicité des lignes pour chaque table.

Ainsi, escartefigue est toujours dans les clous.

UNE TABLE EST RELATIONNELLE si et seulement si :
1) elle possède une clé
2) toutes ses valeurs sont atomiques
3) il n'y a pas de NULL

C’est quoi « atomique » pour toi ? Descendre au niveau du quark ? Appuie-toi au moins sur ce qu’a écrit Ted Codd, à la page 6 de The Relational Model for Database Management: Version 2. (Reading, Mass.: Addison-Wesley, 1990).

Quoi qu’il en soit, ta définition pourrait être complétée par celle de Chris Date, qui écrit à la page 69 de son ouvrage Database Design and Relational Theory Normal Forms and All That Jazz :

« What does it mean for a table to be a direct and faithful representation of a relvar? The answer to this question involves five basic requirements, all of which are immediate consequences of the fact that the value of a relvar at any time is (of course) always a relation specifically:

1. The table never contains any duplicate rows.
2. There’s no left to right ordering to the columns.
3. There’s no top to bottom ordering of the rows.
4. All columns are regular columns.
5. Every row and column intersection always contains exactly one value of the applicable type, and nothing else. »

Le point 1 sous-entend bien sûr la déclaration d’une clé primaire.
Le point 4 sous-entend qu’il n’y a pas de colonnes cachées (row id, object id, timestamps...).
Le point 5 sous-entend que NULL est interdit. (C’est là où certains MLD peuvent être pris en défaut, mais certainement pas les miens...).

P.S. Ça fait trente ans que la relation est définie comme étant une valeur de relvar (variable relationnelle). Essaie d’en tenir compte. Je te renvoie au chapitre 8 de Relational DATABASE, Writings 1991-1994 de C.J. Date.