Discussion :

[SGBDdebutantAAA]

Bonjour,

Je suis étudiant et je dois créer un mcd puis mld puis toutes les étapes avant le déploiement d'une base de données.
J'ai fait un MCD, j'espère réussi en 3FN, avec donc pour chaque table une clé primaire, et selon les associations une clé étrangère. Or il semble que looping crée automatiquement les clés étrangères quand on passe de MCD à MLD, pareil pour les tables de liaisons. Cependant je n'arrive pas à comprendre quelles sont les conditions pour la création automatique de clé étrangère selon quelles cardinalités. Dois-je, dans le MCD, ne jamais créer de clé étrangère ni de table de liaison car Looping le fait automatiquement lors de la conversion en MLD ? Des explications sur les flèches entre les tables dans le MLD seraient elles aussi le bienvenue.
Je mets en PJ mon MCD puis MLD.

Merci beaucoup à ceux qui pourront m'aider.

[gabi7756]

Un bon exemple des différences MCD => MLD


Pas de table de liaison
Pas de FK
J'en oublie peut être

[SGBDdebutantAAA]

C'est très clair, merci.
J'aimerai cependant quand même comprendre le sens des flèches du MLD. Dans l'image que vous avez envoyé, la flèche part du 0,n vers le 1, or sur mon mld il semblerait qu'elles partent toutes du 1 ou 0,1 ou 0 vers le x,n.

[fsmrel]

Bonjour,

J'ai fait un MCD, j'espère réussi en 3FN, avec donc pour chaque table une clé primaire, et selon les associations une clé étrangère

Les concepts de table, clé primaire, clé étrangère sont du niveau logique (MLD et SQL) mais pas du niveau conceptuel (MCD).

Dans un MCD, on crée des entités-types (classes d’entités), avec un identifiant par entité-type et des associations entre entités-types. Dans la production du LDD SQL (langage de description de données) Looping traduit chaque entité-type en table et les associations en clés étrangères ou en tables (munies de clés étrangères) selon les cardinalités portées par les pattes d’association. Les identifiants sont traduits par Looping en clés primaires.

Ainsi, dans votre entité-type "personnel", l’attribut (rubrique) id_agence doit être supprimé, ainsi que dans les entités-types "capteur" et "rapport". Looping fera le travail pour les tables inférées de ces entités-types. De même, supprimez l’attribut id_capteur dans les entités-types "mesure" et "agence". Supprimez l’attribut id_gaz dans l’ entité-type "capteur".

Les flèches dans le MLD expriment le sens des références des tables référençantes vers les tables référencées, donc les clés étrangères du LDD : une clé étrangère fait référence à une clé primaire (contrainte d'intégrité référentielle).

[fsmrel]

L’attribut num_capteur devrait disparaître de l’entité-type "agence", sinon on doit comprendre qu’une agence a un seul capteur. Selon votre MCD, une agence fait l’objet d’un seul relevé (attribut ref_releve) : c’est ce qui est attendu ?

[fsmrel]

Au sujet des cardinalités :  

La patte d’association connectant l’entité-type "rapport" et l’association "ecrit" est porteuse d’une cardinalité 1,n, ce qui signifie qu’un rapport donné peut être rédigé par plus d’une personne. Normal ? De même, un rapport peut être reçu par plus d’une agence. Normal ?

[SGBDdebutantAAA]

Tout d'abord merci pour vos réponses concernant la clarification de la différence MCD MLD.

J'ai apporté les corrections dont vous avez parlé ainsi que certaines autres, j'ai décalé ref_releve qui aurait dû se trouver dans mesure (erreur d'inattention, merci de l'avoir signalé), et effectivement un rapport peut avoir plusieurs auteurs, et je viens de corriger le fait qu'un rapport ne puisse être reçu que par une agence. Maintenant que je comprends bien l'influence des cardinalités sur la création du MLD, je pourrais plus facilement corriger les éventuelles erreurs restantes de toute façon.

Je souhaiterai enfin, pour mieux comprendre le MLD, bien que cela ne soit pas forcément directement utile, comprendre comment un type de cardinalité influence le sens de la flèche. Si quelqu'un lit ce message et possède une ressource là-dessus, je suis preneur.

[fsmrel]

Dans le MLD ci-dessous une flèche a pour source la table "personnel" et pour cible la table "agence". Cela signifie que l’attribut (clé étrangère) agence_id de la table "personnel" fait référence à l’attribut agence_id (clé primaire) de la table "agence" : chaque clé étrangère implique une clé primaire, c’est-à-dire qu’une personne donnée ne peut exister dans la base de données qu’à la condition d’être employée par une agence donnée.
De même, l’attribut agence_id de la table "rapport" fait référence à l’attribut agence_id de la table "agence" : "rapport" implique "agence", un rapport donné ne peut exister dans la base de données qu’à la condition d’être reçu par une agence donnée.  

Concernant la table "ecrit", une 1re contrainte veut que l’attribut personnel_id (clé étrangère) de la table "ecrit" fasse référence à l’attribut personnel_id (clé primaire) de la table "personnel". Une 2e contrainte veut que l’attribut rapport_id (clé étrangère) de la table "ecrit" fasse référence à l’attribut rapport_id (clé primaire) de la table "rapport".

Toutes ces contraintes symbolisées par les flèches sont garantes de l’intégrité (référentielle) de la base de données. Sans elles, on aurait facilement des personnes non employées, des rapports jamais reçus, des écrits orphelins...

[Paprick]

Bonsoir,
Petit complément d'information : en cliquant une nouvelle fois sur le bouton "MLD", une autre représentation du MLD ("Crow's foot") est proposée par Looping.
Cette représentation "Crow's foot", très utilisée outre-Atlantique" (mais pas que), donne plus de précisions quand aux cardinalités qui régissent les liens entre tables.

[escartefigue]

Bonjour,


Dans l'entité-type [AGENCE] on trouve à la fois la ville et la région sous forme de libellés.
Il y a donc un risque de graphies différentes pour une même ville ou une même région, ce qui ne facilitera pas les recherches éventuelles (ie : 'boulogne billancourt', 'boulogne-billancourt', 'boulogne b.' etc.)
Il y a aussi un risque d'associer à tort des villes et des régions.
Il serait donc préférable de modéliser ainsi :

[AGENCE] 1,1 --- (situer) --- 0,n [VILLE] 1,1 --- (localiser) --- 0,n [REGION]


Et dans [PERSONNEL] on trouve une adresse postale.
Outre le fait que l'adresse postale est normée (5 ou 6 lignes de 38 caractères selon qu'il s'agit d'une adresse française ou étrangère), il faut que le code postal soit cohérent avec l'adresse.
Voyez dans ce fil de discussion comment modéliser les adresses

Attention aussi à la définition des attributs, ici toutes les colonnes de type caractère sont du varchar(50), dans la vraie vie, il faudra adapter la longueur au besoin effectif et privilégier du char fixe si la longueur maximale est réduite.
Par exemple, 50 caractères pour un n° de téléphone, c'est beaucoup trop, mais pour une adresse courriel, c'est très insuffisant


EDIT : dans la mesure du possible, il est préférable d'agencer les symboles du MCD de sorte à éviter les croisements des "pattes" des associations. Ça facilite la lecture