Bonjour,

j'aimerai qu'on m'aide à me rafraichir les esprits.

Est-ce que c'est un schéma :

- Modèle Conceptuel des Données (MCD)

- Le Modèle Logique de Données (MLD) (en représentation UML : Entity-Relation)

- Le Modèle Physique de Données (MPD)

Si tout ceci est OK. Est-ce que ceci est bien le MLD du MCD ?

Ou je me plante complétement ... Mais alors le MLD du MCD il doit ressembler à quoi ?

Je galère un peu à faire la différence entre chaque : MCD, MLD, MPD ... Et le diagramme d'Entité-Relation de UML, il correspond au MLD ? Non ?

Le seul que je pense avoir vraiment compris, c'est le MPD. Lui il permet de savoir dans quel ordre il faut créer les tables ... Pour le reste c'est assez flou.

Merci d'avance pour votre éclairage

-
Edité par Pitchounvivi 30 août 2020 à 22:11:43

Bonjour,

Le premier schéma est un MCD : il représente les entités et les relations avec les cardinalités entre elles.

Le deuxième, le troisième et le quatrième sont des MLD : il représente des tables avec leurs contraintes (clés, index). Le MLD est théorique, il représente la base de données "brute" sans les ajustements et réglages propres au contexte du projet.

Le MPD représente la base de données telle qu'elle est mise en production, avec tous les réglages et ajustements mis en oeuvre (triggers, procédures, paramétrages spécifiques, etc.). Je n'en ai jamais fait (ni vu d'ailleurs) ...

-
Edité par Benzouye 31 août 2020 à 9:54:02

Bonjour,

Tout d'abord merci pour ta réponse.

Donc si j'ai bien compris pour le MPD, est plutôt représenté avec une requête SQL qui indique comment doivent être "montés" les tables, pour la mise en production.

Je viens de faire un petit exercice pour voir si j'arrivais à mettre le MCD en MLD. J'obtiens ça :

Cela te semble-t-il correcte ou j'ai mal interprété le MCD ?

Si c'est ok, j'essaierai de faire une belle requête SQL pour tenter le MPD.

Normalement quand c'est ok, c'est que cette fois j'ai compris.

Je fais actuellement quelques révisions, mais j'ai beaucoup de mal avec toutes les représentations théoriques et j'ai beau avoir fait quelques recherches je ne trouve rien qui soit clair au point de me dire là ok, j'ai compris.

J'ai le même problème avec d'autres représentations UML : je n'arrive pas à savoir où je dois arrêter la schématisation.

Aurais-tu un site ou des sites clairs sur ces différents schémas ?

Encore merci

-
Edité par Pitchounvivi 31 août 2020 à 16:06:01

Oui, cela me paraît correct. Attention toutefois, dans la table OT, il y a une clé étrangère composée FOREIGN KEY ( auto_id, ordi_id ) REFERENCE automates_ordinateurs ( auto_id, ordi_id ). C'est peut-être ce que tu as fait, mais c'est impossible à voir ici

Pitchounvivi a écrit:

pour le MPD, est plutôt représenté avec une requête SQL qui indique comment doivent être "montés" les tables, pour la mise en production

Plus que les tables, c'est aussi tous les index, clés, contraintes, triggers, procédures, etc. difficilement représentables autrement qu'avec un script SQL en effet ...

Re,

oui, c'est ce que je voulais faire.

D'ailleurs petite question, ne serait-il pas plus intéressant d'avoir dans la table automate_ordinateur un id qui regrouperait les deux clé étrangère auto_id et ordi_id ?

Ce serait plus simple d'avoir une clé étrangère "simple" qui vienne de automate_ordinateur ...

Non ?

Est-ce cela garder une table ouverte ?

-
Edité par Pitchounvivi 31 août 2020 à 16:29:35

Ce sont deux façons de voir, il n'y pas une bonne et une mauvaise.

Si tu veux mettre un id dans la table automate_ordinateur, il faut également rajouter également une contrainte UNIQUE( auto_id, ordi_id ) dans cette table, pour empêcher de créer plusieurs fois le même couple automate/ordinateur. Cela fait deux index à placer au lieu d'un ...

Ok, ce n'est pas considéré comme une mauvaise pratique si je n'en mets pas.

Comme j'ai dis précédemment, je relis mes cours histoire de me refaire une petite remise à niveau.

Dans mon cours, le prof insiste sur le fait de garder les tables ouvertures et le plus facilement maintenable possible.

Mais si je comprends bien il n'est pas indispensable d'avoir 1 id dans une table de liaison. Du moment que les 2 FK soient liées. Il suffit de répéter cet ensemble partout où on en a besoin.

Justement je vois que tu parles des index. j'étais entrain de regarder la requête SQL.

J'ai regardé https://sql.sh/cours/index

Si je comprends bien l'index dit le fk bla_bla correspond à PK bla_bla de la table XYZ.

C'est donc toujours lié à la clé primaire, mais que dans le cas où il y a des clés complexes.

-
Edité par Pitchounvivi 31 août 2020 à 17:29:16

Pitchounvivi a écrit:

il n'est pas indispensable d'avoir 1 id dans une table de liaison. Du moment que les 2 FK soient liées. Il suffit de répéter cet ensemble partout où on en a besoin

Si tu crées un id c'est que ce n'est pas une relation mais une entité à part entière qui a besoin d'un identifiant unique.

Il faut donc se poser la question au moment du MCD : entité ou relation ?

Ici, nous sommes bien dans le cadre d'une relation, et comme tu as besoin de cette relation au niveau de l'OT, tu mets en place ce que l'on appelle un identifiant relatif.

Si besoin d'approfondir, je te laisse (re)lire le document "Conception BDD" (cf. ma signature), §5.2 notamment.

-
Edité par Benzouye 31 août 2020 à 17:50:57