Discussion :

[Lisingi]

Bonjour quelqu'un peut m'aider à transformer ce modèle MCD en MLD ?

[fsmrel]

Bonsoir Lisingi,

Reprenez votre MCD avec Looping, gracieusement proposé par le professeur Patrick Bergougnoux (merci Paprick !)

Et explorez le forum Looping,

[Paprick]

Bonsoir,

Bonjour quelqu'un peut m'aider à transformer ce modèle MCD en MLD ?

Je ne vois aucun MCD dans votre message...

[escartefigue]

Looping, comme indiqué par Fsmrel, fera le travail d'un simple clic.

Mais, s'il s'agit d'apprendre la logique de transformation du MCD en MLD et donc faire le travail manuellement, nous pourrons vous aider sous réserve que votre MCD soit publié...

[laurentSc]

Bonjour,

avant de connaître Looping, je faisais tout manuellement (même pas de MLD, directement création des tables SQL), mais Looping est un vrai plaisir....

[Lisingi]

Je essayé le logiciel Looping mais je ne comprends pas comment ça marche. Est-ce qu'il y a un tutoriel sur ça ou une chaîne youtube qui explique ça ? Aider moi svp

[laurentSc]

Je t'invite à adopter la même démarche que moi (fin mai, je ne savais même pas ce qu'était un MCD...). Achète le bouquin de Paprick (Patrick Bergougnoux) : https://merise.developpez.com/livres. C'est un investissement rentable...

[pier.antoine]

Et puis lire les tuto de Developpez.com, aller sur le forum...

Bref, concevoir une (bonne) base de données, ça s'apprend, ça demande du travail...

Bon courage

Pierre

[Cincinnatus]

Bonjour,

Pour apprendre, un cours peut être utile. En plus de ceux de développez, il y a entre autres celui-ci ou celui-là. (pdfs)

[escartefigue]

@Cincinnatus : le premier document est intéressant, quoique pas exempt d'approximations, mais le deuxième n'est surtout pas à recommander, il est même à jeter aux orties !

Dans le premier, on peut noter les points suivants :

• tous les types d'entité ne deviennent pas des tables : les entité-type fictives dont le cas d'espèce est l'entité-type date qui devient rarement une table.
• les règles applicables en cas de cardinalité minimale de zéro, peuvent conduire ou non à la création de tables associatives selon le choix du concepteur et des règles internes à l'entreprise
• parler de "champ" d'une table est un abus de langage, une table ne comporte pas de champ, mais des colonnes
• c'est dommage que le document ne dise rien concernant la traduction des contraintes

Dans le deuxième :

• définir le MCD sans mentionner qu'il doit être le reflet exact des règles de gestion est un oubli regrettable
• définir le MLD en indiquant qu'il "permet dʼimplémenter la base de données dans un SGBD donné" est une assertion erronée.
  Le MLD ne tient absolument pas compte du choix du SGBD, c'est le MPD qui est la déclinaison du MLD pour un SGBD donné, nuance
• utiliser le nom du département comme identifiant (et donc comme clef primaire) et stocker une valeur calculée comme l'âge sont deux hérésies
• stocker l'adresse dans une seule colonne est toujours une erreur et la stocker au niveau employé en est également souvent une
• page 7, à propos des identifiants composés, il est vraiment stupide d'utiliser un identifiant relatif en mettant le n°d'ordre avant le n° de projet.
  La bonne façon de propager l'identification relative (puisque c'est ce dont il s'agit ici) dans le MLD, c'est de construire une clef ayant dans cet ordre, le numéro de projet puis le numéro d'ordre

Je ne suis pas allé plus loin que la page 7 du document 2 tellement il y a de fautes jusque là, j'imagine que la suite est du même tonneau

[fsmrel]

Bonsoir,  

Complètement d’accord avec Escartefigue. Que d’approximations dans les articles cités par Cincinnatus !

Par exemple, chez M. Chochois :

« Une table contiendra donc un ensemble d’enregistrements »

Barbarisme dans le contexte du modèle relationnel de données et du langage SQL (voyez la norme de ce langage, dont relève le terme « table »). Une table ne contient que des lignes. Les enregistrements appartiennent pour leur part à des fichiers, les quels sont ici hors sujet. (voyez la norme de ce langage, don relève le terme « table »). Une table ne contient que des lignes. Les enregistrements appartiennent pour leur part à des fichiers, les quels sont ici hors sujet.

«Une colonne correspond à un champ.»

Même punition, même motif.

«La valeur prise par un champ pour un enregistrement donné est située à l’intersection ligne-colonne correspondant à enregistrement-champ. »

Ça en devient pénible, voire scabreux.

«Dans la plupart des SGBDR (Système de Gestion de Base de Données Relationnelle), le fait de définir une clé primaire donne lieu automatiquement à la création d’un index. »

Préciser qu’on en est alors au stade MPD (en effet, le concept d’index n’existe pas plus dans la norme SQL que dans un MLD).

« Une association de type 1:N (c’est à dire qui a les cardinalités maximales positionnées à « 1 » d’une côté (sic) de l’association et à « n » de l’autre côté) se traduit par la création d’une clé étrangère dans la relation correspondante (resic) à l’entité côté « 1 ». Cette clé étrangère référence la clé primaire de la relation correspondant à l’autre entité. »

Plaît-il ? Demander à l’auteur de remplacer 1,N par 1,1. Par ailleurs, il omet de dire qu’une association 0,1 – 1,1 (injection) subit le même régime, bien qu’il évoque cette situation plus loin (page 5).


Cas de la règle numéro 3

L’auteur écrit en fait qu’il n’existe pas de produit qui ne fasse l’objet d’au moins une commande : c’est évidemment tout à fait contestable.

«Si fonctionnellement, le marin est le plus important… MARIN(numMarin , nomMarin , numVoilier , nomVoilier) Clé primaire : numMarin »

D’après ce qui est codé, du point de vue tabulaire, un marin peut être associé à plusieurs voiliers ! numVoilier doit a minima être clé alternative de la table MARIN (pour un voilier il y a au moins et au plus un marin).

Dans la bijection qui est utilisée (1,1 de chaque côté de l’association), l’intégrité est sans coup férir prise en défaut au niveau tabulaire, voyez l’exemple ici.


Dans son exemple 3 (page 6), l’auteur oublie de traiter du marqueur NULL (l’ennemi des bases de données relationnelles).

Par ailleurs, il n’a pas conscience que la clé qu’il prétend « primaire » de la table ANIMER est en réalité une surclé réductible (donc non candidate donc non primaire), et qu’au fond il a traité de 0,1—0,1 exactement comme de 0,N—0,N.

Page 7 :

Les termes « table mère » et « table fille » ne sont pas pertinents : un adhérent peut être un enseignant mais vu du modèle, certainement pas « être sa mère » (confusion des verbes être et avoir).

[escartefigue]

Par curiosité, je suis allé voir un peu plus bas dans le document n°2.
En page 31, on y trouve ceci

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
-- Table CLIENT (cli_num, cli_nom, cli_age, cli_adresse, cli_type, cli_ca, cli_tremise) ;
CREATE TABLE Client
(cli_num CHAR(8) NOT NULL,
cli_nom CHAR(25) NOT NULL,
cli_age INTEGER NOT NULL,
cli_adresse VARCHAR(80),
cli_type VARCHAR(16),
cli_ca INTEGER,
cli_tremise INTEGER NOT NULL,
PRIMARY KEY (cli_num)) ;
-- Suppression d'un enregistrement dans la table client :
DELETE FROM client WHERE (cli_nom = 'Tranvouez');

Au niveau du create table, on trouve

• une PK de type char, type plus encombrant que l'integer, dont le contenu est potentiellement sémantique et donc instable, et qui est sensible à la collation.
  Bref, un très mauvais choix
• une colonne "âge", sans doute l'auteur a-t-il prévu d'en mettre à jour quotidiennement la valeur, puisque bien évidemment elle peut changer à tout moment
  Tout concepteur de SGBD, même débutant, sait qu'on ne stocke pas l'âge, mais la date de naissance !
• une adresse sur une seule ligne de 80, alors que la norme postale est de 6 à 7 lignes de 38 caractères
• d'une typologie de type varchar, sans contrainte check et donc susceptible de varier d'un client à l'autre (ex : "grand compte" / "Gd cpte"...)
  Une FK permettant de faire le lien avec une table des typologies est une autre solution

Ensuite, l'ordre DELETE ne garantit en rien la suppression d'un et un seul client, puisqu'il n'y a pas de contrainte UNIQUE sur le nom du client !

En page 29, on trouve ceci :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
CREATE TABLE Ligne_cmd
(lcd_art CHAR(8) NOT NULL,
lcd_cmd INTEGER NOT NULL,
lcd_qte INTEGER NOT NULL,
lcd_liv INTEGER,
lcd_pu INTEGER NOT NULL,
FOREIGN KEY (lcd_cmd) REFERENCES Commande,
FOREIGN KEY (lcd_art) REFERENCES Article,
PRIMARY KEY (lcd_cmd, lcd_art)) ; <- Clé primaire composée

C'est à dire

• une contrainte FK invalide, puisque on ne précise pas à quelle colonne de la table client on fait référence.
• une PK qui inclut l'identifiant article, sorte de mélange de commande et de ligne de commande...

C'est très grave de proposer un support de ce niveau de la part d'un enseignant !

[fsmrel]

Ave Capitaine,

Je suis d’accord, le support de cours en question laisse pour le moins à désirer...

Cela dit, tu écris :

« une colonne "âge", sans doute l'auteur a-t-il prévu d'en mettre à jour quotidiennement la valeur, puisque bien évidemment elle peut changer à tout moment »

Va savoir ! peut-être s’agit-il de la gestion des clients d’une entreprise de pompes funèbres, auquel cas l’âge du client au moment de son décès peut être pertinent (on évite d’avoir à gérer les dates de naissance et de décès pour calculer l'âge) 


Tu écris aussi :

« une contrainte FK invalide, puisque on ne précise pas à quelle colonne de la table client on fait référence. »

Devant les tribunaux SQL, la cause de l’auteur est défendable car légale : selon la norme SQL on n’est pas obligé de déclarer les colonnes référencées par une FK : par défaut ce sont les colonnes de la clé primaire de la table référencée. Cf. par exemple, Peter Gulutzan (SQL-99 Complete, Really, chapitre 20).

Tu écris aussi :

« une PK qui inclut l'identifiant article, sorte de mélange de commande et de ligne de commande... »

Il s’agit en fait d’une paire {commande, article}, ce qui n’est pas peccamineux.

[escartefigue]

Bonjour François,

Heureux de te voir de retour et toujours bon pied, bon oeil

« une colonne "âge", sans doute l'auteur a-t-il prévu d'en mettre à jour quotidiennement la valeur, puisque bien évidemment elle peut changer à tout moment »

Va savoir ! peut-être s’agit-il de la gestion des clients d’une entreprise de pompes funèbres, auquel cas l’âge du client au moment de son décès peut être pertinent (on évite d’avoir à gérer les dates de naissance et de décès pour calculer l'âge) 

Dans les faits, je ne serai pas surpris qu'une entreprise de pompes funèbres ait besoin de connaître la date de décès.
Mais vu qu'il s'agit d'un support de cours, le cas le plus général aurait du être proposé, quitte à exposer pour l'anecdote ce cas particulier.

« une contrainte FK invalide, puisque on ne précise pas à quelle colonne de la table client on fait référence. »

Devant les tribunaux SQL, la cause de l’auteur est défendable car légale : selon la norme SQL on n’est pas obligé de déclarer les colonnes référencées par une FK : par défaut ce sont les colonnes de la clé primaire de la table référencée.

Sans doute, mais cette syntaxe ne sera pas acceptée par tous les SGBD.
Là encore, dans un support de cours, il convient de présenter en premier le cas général puis dans un deuxième temps les cas particuliers.

« une PK qui inclut l'identifiant article, sorte de mélange de commande et de ligne de commande... »

Il s’agit en fait d’une paire {commande, article}, ce qui n’est pas peccamineux.

Mea culpa, aveuglé par mon courroux à l'encontre de l'auteur, j'ai lu un peu trop vite et cru qu'il s'agissait du DDL de la table COMMANDE.
Mais il s'agit de la table LIGNE DE COMMANDE.