Discussion :

[laurentSc]

Bonsoir,

je suis en train de découvrir ce qu'est un MCD. Comme outil, j'ai à ma disposition MySQL Workbench. J'ai donc commencé à lire l'article de fmsrel : Modéliser les données avec MySQL Workbench. Je me jette à l'eau. Pour commencer simple, j'ai 2 tables (country et user). J'avais fait une conception tabulaire avant d'attaquer le MCD) :

Code sql :

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

1
2
3
4
5
6
7
CREATE TABLE `country` (
  `country_key` smallint NOT NULL AUTO_INCREMENT,
  `country` varchar(30) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT '',
  `region` varchar(30) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT '',
  PRIMARY KEY (`country_key`),
  UNIQUE KEY `uk_country` (`country`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TABLE `user` (
  `user_key` smallint NOT NULL AUTO_INCREMENT,
  `sesa` int DEFAULT NULL,
  `lastname` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
  `firstname` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
  `email` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
  `company` varchar(50) COLLATE utf8_bin DEFAULT NULL,
  `buunitname` varchar(50) COLLATE utf8_bin DEFAULT NULL,
  `location` varchar(50) COLLATE utf8_bin DEFAULT NULL,
  `manager_key` smallint DEFAULT NULL,
  PRIMARY KEY (`user_key`),
  UNIQUE KEY `email_UNIQUE` (`email`),
  UNIQUE KEY `sesa_UNIQUE` (`sesa`),
  KEY `FK_USER` (`manager_key`),
  CONSTRAINT `FK_USER` FOREIGN KEY (`manager_key`) REFERENCES `user` (`user_key`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

Une des colonnes de la table user est location. Cette location (le site du user) se trouve dans un pays (et un seul). Je pense qu'il y a donc une relation relative 1-1 entre les 2 tables. Je l'ai représentée ainsi :
Cette modélisation est-elle correcte et si oui, peut-on générer la représentation tabulaire (MLD) ?

[Paprick]

Bonsoir,

Comme indiqué dans précédents posts concernant votre projet, MySQL Workbench permet la réalisation de MLD, et non pas de MCD. Et, même si tout le monde ne semble pas être d'accord sur ce point, il n'est pas idéal de concevoir un modèle en passant outre la phase de conception.
Le MLD que vous avez réalisé, et le code SQL correspondant, ne représente pas correctement le lien entre USER et COUNTRY : c'est en fait une association 1,1---(asso)---0,n qu'il faudrait modéliser. Cela ferait ainsi apparaître une clé étrangère (FK) dans la table USER qui ferait référence à la table COUNTRY, ce qui n'est pas le cas de votre modèle.
Par ailleurs, même si ce n'est pas évident au vu de votre MLD Workbench, il semble qu'il existe une association réflexive au sein de USER pour définir qui manage qui...
Bref, votre petit exemple montre à quel point il serait vraiment utile de passer par la case MCD, avant de se jeter sur le MLD.
D'après votre code SQL, voici ce que serait le MCD correspondant :

Il me semble que qu'avec ce type de MCD, les choses apparaissent plus clairement.
El le MLD correspondant (ainsi que le code SQL) généré par ce MCD est équivalent à ce qui pourrait être saisi directement dans Workbench :

Bonne continuation !

[laurentSc]

Merci infiniment pour votre réponse, que je découvre par hasard, car même si abonné à cette discussion, j'ai pas reçu de mail...

En tant que newbie de la modélisation des bdd, je vais poser des questions naïves.
Donc, OK, Workbench ne permet pas de faire un MCD. Malheureusement, pas possible d'installer Looping sur mon PC de boulot, donc je continue avec Workbench .
Tout d'abord, dans Workbench , je n'avais jamais créé de diagramme comme celui du post #1. Vous dites que c'est un MLD ? Je vois bien la différence avec votre diagramme dans le post #2 (probablement créé avec Looping).

Bref, votre petit exemple montre à quel point il serait vraiment utile de passer par la case MCD, avant de se jeter sur le MLD.

OK, mais avec Workbench , est-ce possible ? (je n'ai qu'une très petite partie de l'article de fsmrel)

Le MLD que vous avez réalisé, et le code SQL correspondant, ne représente pas correctement le lien entre USER et COUNTRY : c'est en fait une association 1,1---(asso)---0,n

relation associative. Je vous comprends clairement mais je ne connaissais même pas ce concept d'association...

Le livre de votre signature : https://www.pumbo.fr/boutique/livre/...lle-de-donnees me semble très utile pour dégrossir ma connaissance. Je crois que je vais l'acheter...

EDIT : J'ai pas trainé :

Merci pour votre commande chez Pumbo.fr!

EDIT2 : j'imagine une autre approche :
1- je lis le bouquin
2- après sa lecture, Looping devrait me paraître intuitif (ce n'était pas le cas quand je l'ai installé sur mon PC perso)
3- je fais le MCD de mon projet sur mon PC perso avec Looping puis le MLD et quand le bdd sera designée, je transfère le code SQL de sa création sur mon PC boulot et je la crée dans Workbench.
4- je ferai toutes les mises à jour, d'abord avec mon PC perso.

Selon vous, est-ce jouable ?

[Paprick]

Bonjour,

OK, mais avec Workbench , est-ce possible ? (je n'ai qu'une très petite partie de l'article de fsmrel)

Workbench ne traite pas le niveau conceptuel et démarre directement au niveau logique avec la définition des tables. Certains vous diront que c'est suffisant, mais ce n'est certainement pas la meilleure façon de démarrer une conception.

EDIT2 : j'imagine une autre approche :
1- je lis le bouquin
2- après sa lecture, Looping devrait me paraître intuitif (ce n'était pas le cas quand je l'ai installé sur mon PC perso)
3- je fais le MCD de mon projet sur mon PC perso avec Looping puis le MLD et quand le bdd sera designée, je transfère le code SQL de sa création sur mon PC boulot et je la crée dans Workbench.
4- je ferai toutes les mises à jour, d'abord avec mon PC perso.
Selon vous, est-ce jouable ?

Compte-tenu de vos débuts en modélisation, cela me parait effectivement une bonne approche : il faut bien comprendfre que Looping est très intuitif quand on connait les bases de le modélisation... sinon c'est difficile d'appréhender correctement un modèle.
Par ailleurs, par apport à votre PC boulot, regardez si le firewall ne peut pas se paramétrer pour vous autoriser l'accès à https://looping-mcd.fr : cela réglerait votre problème de fonctionnement du logiciel.

[laurentSc]

Par ailleurs, par apport à votre PC boulot, regardez si le firewall ne peut pas se paramétrer pour vous autoriser l'accès à https://looping-mcd.fr : cela réglerait votre problème de fonctionnement du logiciel.

Je verrai ça avec le support info de ma boîte lundi 11 (n'étant pas chez moi toute la semaine prochaine). Si pas possible, de toutes façons, il me reste la méthode exposée dans l'EDIT 2 du post #3...

[fsmrel]

Bonsoir,

Une des colonnes de la table user est location. Cette location (le site du user) se trouve dans un pays (et un seul). Je pense qu'il y a donc une relation relative 1-1 entre les 2 tables.

Le site se trouve dans un pays et un seul, d’accord. Mais pour le reste voyons votre diagramme :

Au vu des cardinalités, vous avez mis en oeuvre une bijection entre COUNTRY et USER, en conséquence de quoi chaque pays héberge au moins et au plus un site. Concernant les associations de cette nature, voyez le paragraphe 6 « Associations de un à un » de mon article. Si un pays peut héberger plus d’un site, c’est le paragraphe 5 « Associations de un à plusieurs » qui est à voir.

MySQL Workbench permet la réalisation de MLD, et non pas de MCD.

Certes. Comme je l’ai écrit dans l’avant-propos de mon article :

“Du point de vue de l'abstraction, MySQL Workbench propose un diagramme EERD (Extended (ou Enhanced) Entity-Relationship Diagram) qui se situe un cran en dessous d'un MCD merisien ou d'un diagramme de classes UML — il se situe au niveau MLD (modèle logique des données) de Merise.”

Je rappelle à cette occasion que MCD et MLD sont des notions franco-françaises, ayant des similitudes avec leurs cousines anglo-saxonnes. Ainsi, un MCD et un diagramme E/R de Chen, ERD (Entity-Relationship Diagram) sont voisins (voir page 23 de l’article de Chen, The Entity-Relationship Model-Toward a Unified View of Data).


Le MLD merisien diffère du modèle de données de MySQL Workbench, à considérer donc comme EERD.

Les différents mickeys colorés donnent des indications : clé jaune pour un attribut participant à la clé primaire, losange rougeâtre pour un attribut non NULL participant à une clé étrangère, losange blanchâtre pour un attribut participant à une clé étrangère et NULL, losange bleu pour un attribut lambda (ou clé alternative) non NULL (blanchâtre si NULL). Daltoniens passez votre chemin…

Il est quand même bon de noter que les cardinalités sont représentées !

Pour en savoir plus sur l’existence de clés alternatives et index, c’est plutôt rustique, mais on fait avec… :

A cette occasion, concernant Looping, notons que les MCD ci-dessous (et les différentes versions de cardinalités, x,y-z,1) produisent le même MLD.

MLD commun :

Pour la petite histoire, je renvoie au post dans lequel j’évoque en fait l’étonnement des ingénieurs de l’entreprise canadienne proposant Silverrun. Bien que le contexte soit francophone, nos cousins d’outre-Atlantique étaient calés sur le niveau MLD et découvrirent que les merisiens modélisaient des MCD (Open ModelSphere, descendant de Silverrun s’y est mis…).


laurentSc, en plus de la lecture de l’ouvrage de Paprick, plongez-vous aussi dans celui de D. Nanci (RIP) et B Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), c’est l’ouvrage de référence. Les chapitres à étudier sont le chapitre 7 (« Modélisation conceptuelle des données ») et en complément le chapitre 13 (« Modélisation logique des données »).

je fais le MCD de mon projet sur mon PC perso avec Looping puis le MLD et quand le bdd sera designée, je transfère le code SQL de sa création sur mon PC boulot et je la crée dans Workbench.

Si vous devez vous plier à cette contrainte (ce qui n’est pas à souhaiter…), vous pourrez exécuter le code SQL avec votre SGBD (la fenêtre Propriétés de Looping vous offre un choix d’une dizaine de SGBD). Si vous voulez créer un diagramme MySQL Workbench, vous pouvez en passer par la rétro-conception qui permet de créer un digramme à partir du code SQL (cf. paragraphe 9 de mon article).

[Paprick]

Bonsoir,

A cette occasion, concernant Looping, notons que les MCD ci-dessous (et les différentes versions de cardinalités, x,y-z,1) produisent le même MLD.

Pas tout à fait François ! Tu noteras qu'avec la cardinalité 0,1 la clé étrangère est en gras, signe d'unicité, différence que tu peux également constatée dans le script SQL.

[fsmrel]

Tu noteras qu'avec la cardinalité 0,1 la clé étrangère est en gras

Ach ! Sans être daltonien, il y a que je n’ai plus mes yeux de 20 ans…

[laurentSc]

Bonsoir,

mon silence prolongé n'était pas du à mon désintéressement pour ce sujet ; il était du à mon absence toute cette semaine...

Merci beaucoup fsmrel pour votre réponse très complète au post #6.
Voici la démarche que j'envisage :

1- lecture du bouquin de Paprick (il est arrivé pendant mon absence et je l'ai commencée)

2- Etude de votre réponse fsmrel et lecture des chapitres mentionnés de votre article.

3- Probablement, essai de création d'un MCD avec Looping.

4- Essai d'exécuter Looping sur mon PC professionnel (j'appelle demain matin le support info de ma boîte)

Si je fais tout ça, c'est déjà beaucoup. On verra pour aller plus loin. Merci aussi pour le lien Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001) . Plutôt que de lire un fichier pdf de 538 pages, je pense acheter une version papier. J'ai trouvé ce lien : https://www.amazon.fr/Inge%CC%81nier.../dp/2736122097. 8 livres d'occasion pour 0,50€ pièce, ça ira mais ils annoncent 891 pages. La seule différence, c'est que c'est la 3e édition et le pdf la 4e. D'après vous, est-ce que ça reste valable ?

[laurentSc]

4- Essai d'exécuter Looping sur mon PC professionnel (j'appelle demain matin le support info de ma boîte)

C'est bon. Et j'ai pas compris grâce à quoi, car "logiciel non Schneider, donc on y connait rien". Et ils n'ont pas touché au firewall...

J'ai commencé la lecture de votre bouquin Paprick . J'ai pas été loin (je suis pas rapide), mais déjà en difficulté. En effet, ça commence par examiner les flux d'information (chapitre 2=Modèle organisationnel de flux) mais dans mon cas, je ne vois aucun flux. Si je reprends l'exemple simpliste que j'avais donné au post #1 et dont vous avez proposé un MCD au post #2 , il n'y a pas de flux, vu qu'il y a un seul acteur (selon votre terminologie). (mon cas complet est plus complexe, mais je ne vois pas non plus de flux). Il est où le schmilblick ?

[Paprick]

Bonjour,

C'est bon. Et j'ai pas compris grâce à quoi, car "logiciel non Schneider, donc on y connait rien". Et ils n'ont pas touché au firewall...

Parfait ! Ca aurait été bien de comprendre pourquoi, mais bon, l'essentiel est que ça tourne !

J'ai commencé la lecture de votre bouquin Paprick . J'ai pas été loin (je suis pas rapide), mais déjà en difficulté. En effet, ça commence par examiner les flux d'information (chapitre 2=Modèle organisationnel de flux) mais dans mon cas, je ne vois aucun flux. Si je reprends l'exemple simpliste que j'avais donné au post #1 et dont vous avez proposé un MCD au post #2 , il n'y a pas de flux, vu qu'il y a un seul acteur (selon votre terminologie). (mon cas complet est plus complexe, mais je ne vois pas non plus de flux). Il est où le schmilblick ?

L'analyse des flux est une approche permettant de déterminer les informations à recenser dans le SI afin de définir le dictionnaire des données. Dans le cas où vous connaissez les données, en particulier quand elles sont déterminées par un seul acteur, pas besoin de modèle de flux : vous pouvez passer directement aux chapitres suivants.
A partir du dictionnaire des données, déterminez les classes d'entités et établissez les règles de gestion (cardinalités entre les classes), et votre MCD commencera à prendre forme.

[fsmrel]

Bonsoir,

La seule différence, c'est que c'est la 3e édition et le pdf la 4e. D'après vous, est-ce que ça reste valable ?

J’ai les deux éditions, mais ça fait belle lurette que je n’utilise plus que la 4e édition, car plus facile à manipuler, même si maintenant, ma vue oblige, je reconnais que la taille de la police de caractères plus importante avec la 3e édition me faciliterait la lecture. En tout cas, les chapitres qui nous intéressent (modélisation des données) n’ont probablement pas bougé.

Cela dit, le PDF de la 4e édition me permet une lecture sans problème à l’écran. De votre côté, l’essentiel étant d’avoir l’ouvrage sous la main, peu importe l’édition, la 3e reste valable.

[laurentSc]

A partir du dictionnaire des données, déterminez les classes d'entités et établissez les règles de gestion (cardinalités entre les classes), et votre MCD commencera à prendre forme.

N'y connaissant rien, je me suis demandé ce que c'étaient les classes d'entités. J'ai consulté la table des matières du livre (pas fait avant) et j'ai vu que cette notion était abordée aux chapitres 5 et 6. J'en suis qu'au chapitre 3 mais je saurai bientôt ce que c'est !

Même si je connais les données (ayant déjà créé un premier jeux de tables), je me pose une question : la colonne user_key de la table user est-elle une donnée ?

[Paprick]

Même si je connais les données (ayant déjà créé un premier jeux de tables), je me pose une question : la colonne user_key de la table user est-elle une donnée ?

C'est une question un peu piège : très souvent les identifiants tel que user_key ou Id_User ne sont pas des données du SI, mais sont rajoutés pour des raisons techniques liées au côté relationnel des bases de données. Au niveau de ces clés, beaucoup de spécialistes BD privilégient d'ailleurs, pour des raisons de performance et de stabilité dans le temps, des rubriques de type entier auto-incrémenté, qui ne sont donc pas des rubriques naturelles (sans signification pour le SI).
Mais ça, vous l'aborderez à partir du chapitre 9 : pour le moment concentrez vous sur la modélisation conceptuelle sans contrainte technique.

[laurentSc]

Merci pour la réponse.

pour le moment concentrez vous sur la modélisation conceptuelle sans contrainte technique.

OK, mais, même si je me doutais que cette grandeur avait plus une raison d'existence technique que structurelle, je n'en étais pas sûr.

Pour aller au plus simple, pour définir les données du SI, je compte partir des colonnes des tables que j'ai déjà créées. Ainsi pour la table user, je pense retenir les données : sesa (le matricule de l'employé), lastname, firstname, email, company, buunitname (le nom de sa business unit), et location (le lieu de son site). Est-ce correct ?

Pour rappel, la structure de la table user :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TABLE `user` (
  `user_key` smallint NOT NULL AUTO_INCREMENT,
  `sesa` int DEFAULT NULL,
  `lastname` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
  `firstname` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
  `email` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
  `company` varchar(50) COLLATE utf8_bin DEFAULT NULL,
  `buunitname` varchar(50) COLLATE utf8_bin DEFAULT NULL,
  `location` varchar(50) COLLATE utf8_bin DEFAULT NULL,
  `manager_key` smallint DEFAULT NULL,
  PRIMARY KEY (`user_key`),
  UNIQUE KEY `email_UNIQUE` (`email`),
  UNIQUE KEY `sesa_UNIQUE` (`sesa`),
  KEY `FK_USER` (`manager_key`),
  CONSTRAINT `FK_USER` FOREIGN KEY (`manager_key`) REFERENCES `user` (`user_key`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

[Paprick]

Pour aller au plus simple, pour définir les données du SI, je compte partir des colonnes des tables que j'ai déjà créées. Ainsi pour la table user, je pense retenir les données : sesa (le matricule de l'employé), lastname, firstname, email, company, buunitname (le nom de sa business unit), et location (le lieu de son site). Est-ce correct ?

Pas de problème jusque là.

[laurentSc]

J'ajouterais ayant fini la lecture du chapitre 3 que les 7 données listées au post #15 sont toutes des données primaires : aucune donnée calculable ni paramètre. Il faut que je prolonge l'exercice pour les autres tables (en tout, y en a 8, en éliminant une table de correspondance et 2 tables "techniques" (structure identique à 2 autres tables et utilisées quand je voulais pas mettre à jour les tables "principales")).
D'ailleurs, je me demande si ces tables "techniques" doivent apparaître dans le MCD. En fait, j'ai un traitement d'écriture en BDD mais si en amont, une erreur a été détectée, j'écris dans les tables "techniques" au lieu des tables "principales". En ai-je dit assez pour que vous formuliez un avis ?

Suite demain...

[laurentSc]

J'ai repris l'élaboration du dictionnaire des données.

Bien que n'ayant que commencé la lecture du chapitre 5, je crois avoir compris ce qu'est une classe d'entités (à l'aide du premier graphique du chapitre (qui ne sont pas numérotés )).

Donc, je continue de définir ma liste de données à partir des tables de bdd que j'avais créées.

J'en suis arrivé à une table qui me pose question :

Code sql :

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

1
2
3
4
5
6
7
8
CREATE TABLE `customer` (
  `customer_SESA` int NOT NULL AUTO_INCREMENT,
  `country_key` smallint DEFAULT NULL,
  `organization` varchar(50) COLLATE utf8_bin DEFAULT NULL,
  UNIQUE KEY `customer_login_id_UNIQUE` (`customer_SESA`),
  KEY `FK_COUNTRY3` (`country_key`),
  CONSTRAINT `FK_COUNTRY3` FOREIGN KEY (`country_key`) REFERENCES `country` (`country_key`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=544343 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

Comme on peut le constater, une des colonnes de cette table (country_key) est une clé étrangère sur une autre table (country). Il me paraît évident que country_key n'est pas une donnée. Par contre, il faut bien une donnée (une rubrique) pour la classe d'entités customer (je garde les noms que j'avais donnés aux tables). Quid de country_customer ?

[fsmrel]

Bonjour,

il faut bien une donnée (une rubrique) pour la classe d'entités customer

customer_SESA est bien une rubrique. Sa particularité sera de jouer le rôle d’identifiant de la classe d’entités customer. Arrivé au stade SQL, customer_SESA est une colonne de la table customer ; du point de vue de la théorie relationnelle (qui satisfait à la théorie des ensembles), l’élément customer_SESA appartient au sous-ensemble {customer_SESA}, clé candidate de la table (en l’occurrence clé primaire). Notez l’emploi que je fais des accolades "{" et "}", puisqu’une clé candidate est un ensemble.

Au stade SQL, country_customer est une colonne de la table customer, engendrée par Looping à partir de l’association qui selon le MCD connecte les classes country et customer. Bien entendu, toujours au stade SQL, country_customer est élément du sous-ensemble FK_COUNTRY3, clé étrangère référençant la clé candidate {country_key} de la table country.

[laurentSc]

Merci pour la réponse.
J'avoue que vu ma encore faible connaissance, j'ai du mal à suivre ; par exemple, j'ai déjà vu le terme "clé candidate", mais je ne sais pas encore ce que c'est...

Et vous ne répondez pas à ma question :

Quid de country_customer ?