Discussion :

[CinePhil]

J'ai un gros doute.
Le sens de la flèche du MLD n'est pas le même selon les articles que j'ai pu lire ici ou là ou dans mes cours CNAM.

D'après mon dernier cours CNAM, la flèche est du côté de la table qui reçoit la clé étrangère, ce qui me semble logique puisqu'en quelque sorte on lit que l'entité A donne sa clé primaire à l'entité B : A--->B

Mais j'ai vu l'inverse, notamment dans le logiciel AnalyseSI qui génère automatiquement un MLD à partir d'un MCD. Qui a raison ?

[TheLeadingEdge]

Bonjour,

On va de la FK vers la PK. La flêche indique le sens de navigation qui permet de retrouver les données. C'est AnalyseSI qui a raison.

PS : Le bon forum pour poser ta question est Schéma Modélisation Relationnelle (Dépendances Fonctionnelles, Formes Normales, Entité-relation, MCD, MPD ...)

[fsmrel]

Bonjour,

D'après mon dernier cours CNAM, la flèche est du côté de la table qui reçoit la clé étrangère, ce qui me semble logique puisqu'en quelque sorte on lit que l'entité A donne sa clé primaire à l'entité B : A--->B

Cette représentation graphique est celle que l'on utilise pour les diagrammes de Bachman et qui a prévalu jusqu'au milieu des années quatre-vingts.

En fait, il n'y a pas de notation graphique particulière concernant les liens entre tables. Si vous préférez inverser le sens des flèches, ça n'est pas un problème. Pour ma part, j'utilise plus volontiers une 3e possibilité, graphiquement moins pauvre que les deux premières (comme disait ma grand-mère, c'est toujours ça de pris...) : la notation conceptuelle IEF (Information Engineering Facility). Outil utilisé : Power AMC.

Voyez la discussion Quelle est la différence entre MCD et MLD, plus particulièrement le message #4 :

http://www.developpez.net/forums/m2171452-4/

[CinePhil]

Je me suis habitué au schéma E/R fourni par MySQL Workbench et qui correspond à peu près à votre formalisme préféré.

Ceci ne me dispense pas de commencer toujours par un MCD Merise qui traduit schématiquement les phrases des contraintes exprimées sans se préoccuper encore des clés étrangères, des types et autres caractéristiques propres aux SGBD.

Merci en tout cas pour vos articles complets et très explicatifs, même si j'ai toujours du mal avec les dépendances fonctionnelles et autre algèbre relationnelle.

[fsmrel]

Ceci ne me dispense pas de commencer toujours par un MCD Merise qui traduit schématiquement les phrases des contraintes exprimées sans se préoccuper encore des clés étrangères, des types et autres caractéristiques propres aux SGBD.

La représentation d’un MCD représente évidemment cette étape en amont qui est essentielle dans la réalisation d’un projet. Le MLD n’en est que la traduction au niveau de la base de données.

Ainsi, les clés étrangères de la base de données liant les tables d’une base de données relationnelle ne sont jamais que la traduction mécanique des liens statiques (anatomiques comme disait Codd) qui unissent les entités-types du MCD. Mais cela ne dispense pas de réfléchir en amont au métabolisme des entités-types : comment réagissent les entités liées, recevant les stimuli d’une entité que l’on cherche à supprimer ? Il est dommage d’attendre de coder un RESTRICT ou un CASCADE pour s’en préoccuper.

Quant aux types (ou domaines, dans le langage de Codd), il est bon de s’y intéresser au plus tôt, car leur dimension sémantique est fondamentale et il ne faut pas attendre d’être au niveau logique pour s’y intéresser : une date de facture et la date de naissance d’un employé sont-elles comparables ? Certes, d’un point de vue basique, on peut dire que leur type ancêtre est le type DATE, mais la réflexion doit-elle s’arrêter là ? L’identifiant d’un produit et l’identifiant d’un client ont peut-être pour ancêtre commun le type INTEGER, mais sont-ils comparables ? Peut-on leur appliquer les opérations arithmétiques qui valent pour les entiers ? Typer une donnée permet de pénétrer plus en avant dans la signification de ce que l’on manipule.
J’aime bien ce qu’écrivait Codd en 1990, au sujet des types, qu’il appelait domaines (cf. The Relational Model for Database Management: Version 2, page 45) :

Domains are the glue that holds a relational database together.