Discussion :

[bomberwaterman]

Bonjour,

Je suis face à un problème bateau. Je fais un MLD pour une application que je développe, et je bute sur un sens de flèche.

Je fais ce MLD sur Visio.

J'ai deux tables avec les attributs suivant:

SITE
PK ; Id_Site
Type_Mobilite

MOBILITE
Id_Mobilite
Intitule

Cette base sert à stocker des informations techniques sur des sites de client.
En l'occurence, ici je veux joindre le type de mobilité qu'il ont au sein de leur entreprise (DECT, WIFI, DECT IP).

Deux options s'offrent à moi alors, selon l'aide de visio "Le parent constitue la table d'origine d'une relation.

L'enfant correspond à la table de réception qui adopte ou hérite les attributs de la table parent.".
Puis "vous devez d'abord coller le lien à la table parent, puis à la table enfant."

Sauf que je ne sais pas à partir de cette définition trouver quel est le parent de l'enfant.

Ce n'est pourtant pas la première fois que je modélise une base et moi j'aurais mis l'id de la mobilité dans ma table site. Ce qui me donne une flèche pointant vers ma table Mobilite. Mais selon ce que je lis partout ce serait l'inverse.

Qu'en pensez vous ?

Merci par avance,

Kévin

[bomberwaterman]

Ok, je pense que j'ai compris.

"Le parent constitue la table d'origine d'une relation.

L'enfant correspond à la table de réception qui adopte ou hérite les attributs de la table parent"

Cela signifie que ma table enfant c'est la table "SITE" qui va hérité des attributs de la classe "MOBILITE". Cela parait logique. Et visio me crée donc une flèche vers "MOBILITE" et crée une clé étrangère dans "SITE".

Cette flèche pour ceux que cela intéresse signifie que "MOBILITE" est en dépendance fonctionnelle de "SITE". On peut déduire une seule valeur de MOBILITE en se basant sur SITE mais on ne peut pas déduire d'id de SITE à partir de MOBILITE.

[Richard_35]

Bonjour,

Juste une question : un SITE peut-il avoir plusieurs Type_Mobilite ?
Autrement dit, par exemple, un site peut-il posséder les types de mobilités Wifi et DECT ?

[H A L I M]

Moi aussi j'ai du mal a joindre les relations avec les tables.

[CinePhil]

Il y a du mélange de notions !

Je fais un MLD

Il s'agit donc de la méthode Merise.
Le MLD est la deuxième étape du développement d'une BDD relationnelle, après le MCD.
=> Avez-vous commencé par faire un MCD ?

J'ai deux tables avec les attributs suivant:

SITE
PK ; Id_Site
Type_Mobilite

MOBILITE
Id_Mobilite
Intitule

Donc ces deux tables ne sont pas associées puisqu'il n'y a aucune clé étrangère dans ce schéma. C'est pour ça que vous demandez d'ailleurs de l'aide !

En l'occurence, ici je veux joindre le type de mobilité qu'il ont au sein de leur entreprise (DECT, WIFI, DECT IP).

Comme l'a demandé Richard_35, il faudrait connaître le détail de la règle de gestion.

un SITE peut-il avoir plusieurs Type_Mobilite ?

Deux options s'offrent à moi alors, selon l'aide de visio "Le parent constitue la table d'origine d'une relation.

L'enfant correspond à la table de réception qui adopte ou hérite les attributs de la table parent.".
Puis "vous devez d'abord coller le lien à la table parent, puis à la table enfant."

Le mélange commence ! "Parent" et "Enfant" sont des notions qu'on réserve plutôt à la modélisation d'un héritage de données.
Dans le cas que vous exposez, SITE n'est ni parent, ni enfant de MOBILITE et vice versa.

Ce n'est pourtant pas la première fois que je modélise une base et moi j'aurais mis l'id de la mobilité dans ma table site. Ce qui me donne une flèche pointant vers ma table Mobilite. Mais selon ce que je lis partout ce serait l'inverse.

Je n'ai jamais aimé le MLD à cause, justement, du sens de la flèche !
Pour m'en souvenir, je dis que A donne une clé étrangère à B.

Dans votre cas, si un site ne peut avoir qu'une seule mobilité, vous avez le MCD suivant :
SITE -1,1----avoir----0,n- MOBILITE

Ce qui donne le MLD suivant :
SITE <------------------------- MOBILITE

=> MOBILITE donne sa clé étrangère à SITE donc la flèche pointe vers SITE.

"Le parent constitue la table d'origine d'une relation.

L'enfant correspond à la table de réception qui adopte ou hérite les attributs de la table parent"

Voilà, dans votre doc, on parle d'héritage, ce qui n'est pas du tout le type de votre association.

Cela signifie que ma table enfant c'est la table "SITE" qui va hérité des attributs de la classe "MOBILITE".

Et maintenant, vous mélangez "table" et "classe" ; vous faîtes donc un voyage de la méthode Merise vers le langage UML !

Cela parait logique. Et visio me crée donc une flèche vers "MOBILITE" et crée une clé étrangère dans "SITE".

Sauf erreur de ma part, soit Visio ne vous fait pas faire réellement un MLD merisien, soit il a un formalisme différent de ce que j'ai vu par ailleurs (voir cet article, partie IV).

Cette flèche pour ceux que cela intéresse signifie que "MOBILITE" est en dépendance fonctionnelle de "SITE".

Ce qui est tout à fait faux !
Si je supprime un site, je ne vais pas supprimer une mobilité qui pourrait aussi s'appliquer à un autre site !

On peut déduire une seule valeur de MOBILITE en se basant sur SITE mais on ne peut pas déduire d'id de SITE à partir de MOBILITE.

Ça par contre, c'est vrai, à condition encore une fois que le MCD que j'ai donné plus haut soit vrai.

Repartez de la règle de gestion, déduisez le MCD puis le MLD.

[CinePhil]

Moi aussi j'ai du mal a joindre les relations avec les tables.

Proposez votre cas dans une nouvelle discussion si vous voulez qu'on vous aide !

[bomberwaterman]

Bonjour,

Merci de cette réponse ultra détaillée,

=> Avez-vous commencé par faire un MCD ?

Non, je me suis dit que je ferrais du 2 en 1, même si ca aurait été plus simple de commencer par un mcd.

En ce qui concerne la règle de gestion, elle pourrait s'énoncer comme ceci:
SITE-0,1-----possède-------0,n-MOBILITE
Ce qui se traduit par, un site peut avoir au plus 1 type de mobilité (cela répond à la question de richard) et un type de mobilité est associé à plusieurs Sites.

Cela se rapproche donc du cours avec les tables OUVRAGE et TYPE (cours fort bien écrit d'ailleurs) et nous aurions donc la clé étrangère dans la table SITE et la flèche pointant vers cette table.

Cependant VISIO fait l'inverse.

Je joins une capture de la base justement, mais il me semble pour le coup que visio fait l'inverse dans le sens des flèches. A confirmer.

[IMG][/IMG]

J'avais marqué le post comme résolu, mais merci de l'avoir déterrer, car j'ai fais des erreurs de compréhension.

Donc si on regarde ce MLD, on se rend compte que les flèches sont à l'inverse de ton exemple, mais que les clés étrangères sont biens stockées dans la table SITE. AU passage il manque fk1 car VISIO ne décrémente pas les fk supprimées....

[CinePhil]

SITE-0,1-----possède-------0,n-MOBILITE

Avec ce MCD, pour éviter de peupler la BDD du bonhomme NULL, tu dois créer une table associative, comme je l'explique dans mon blog.

Ton schéma Visio ressemble plus à un diagramme de classes UML qu'à un MLD merisien. Les cardinalités ont en fait la syntaxe des multiplicités UML. En plus, il n'y a qu'un jeu de multiplicités par association, ce qui fait qu'on ne lit pas complètement la nature de l'association. Bref, ce schéma à la mode Visio n'est pas pratique !

Utilise plutôt un logiciel de modélisation prévu pour faire des MCD, tel que Open Modelsphere, JMerise ou PowerAMC. Tu feras moins d'erreurs en passant par l'étape MCD qui est un schéma beaucoup plus clair pour modéliser les données et définir les associations entre elles.

Tu devrais externaliser la propriété Ville dans une entité type de référence, afin d'éviter d'avoir plusieurs fois la même ville avec des orthographes différentes.

Tu devrais nommer tes entités types au singulier.

[bomberwaterman]

Merci de cette réponse.

J'ai donc tout repris sur open modelsphere, après avoir essayé jmerise qui me paraissait un peu light.

Voici le résultat :
[IMG][/IMG]

C'est donc maintenant un MCD et non un MLD comme je faisais précédemment.

Jai un doute sur certaine cardinalité, notamment celle entre SITE et EQUIP_RESEAU. Un site possède à tous les coups les attributs de EQUIP_RESEAU (cardinalité 1-1) et l'ensemble des attributs de EQUIP_RESEAU peuvent être attribués à 0 ou plusieurs sites.

Raisonnement correct ?

En tout cas, cela m'a pris une heure pour faire ce MCD alors qu'avec VISIO bien plus de temps avec un résultat perfectible!

Merci de m'avoir aider!

[bomberwaterman]

Au passage j'en ai profité pour voir le résultat si je génère le MLD. Je ne m'attendais pas à ça.

Aucune clé étrangère de créer. C'est une erreur ?

[IMG][/IMG]

[CinePhil]

Jai un doute sur certaine cardinalité, notamment celle entre SITE et EQUIP_RESEAU. Un site possède à tous les coups les attributs de EQUIP_RESEAU (cardinalité 1-1) et l'ensemble des attributs de EQUIP_RESEAU peuvent être attribués à 0 ou plusieurs sites.

Ne connaissant pas très bien le domaine que tu modélises il est difficile de me prononcer.

Ce que tu as modélisé, c'est cette règle de gestion :
Un SITE possède un seul EQUIP_RESEAU et un EQUIP_RESEAU peut être possédé par plusieurs sites.
À toi de voir si elle est juste.

Idem pour EQUIP_ANALOGIQUE.
Au passage, nomme tes entités types au singulier. Tu vois que dans la règle de gestion, on décrit ce qui se passe pour 1 instance de chaque entité.
Le fait de mettre le nom de l'entité type au pluriel laisse à penser qu'il s'agirait plutôt d'un ensemble d'équipements analogiques qu'un site possèderait.

Au passage j'en ai profité pour voir le résultat si je génère le MLD. Je ne m'attendais pas à ça.

Aucune clé étrangère de créer. C'est une erreur ?

Ça fait un moment que je n'ai pas utilisé Open Modelsphere mais je me souviens que j'avais eu cette surprise également. De mémoire, il y a une option à cocher pour générer les clés étrangères.
De mémoire également, je crois que la table associative ne sera pas générée pour les cardinalités (0,1 - 0,n). Il faudra corriger le MLD à la main.

Mais ce que je viens de dire sont en plus des souvenir d'une version plus ancienne d'Open Modelsphere. Ça fait un bout de temps que je n'ai plus eu de MCD à réaliser avec un logiciel.

Bon courage !

[bomberwaterman]

Ok, parfait pour cette aide précieuse.

je verrais demain pour le MLD.

Sinon je ne vois pas où j'ai un attribut type au pluriel. Le nom de la table doit être au singulier ? C'est ca que vous voulez dire ?

[CinePhil]

Sinon je ne vois pas où j'ai un attribut type au pluriel. Le nom de la table doit être au singulier ? C'est ca que vous voulez dire ?

Je ne parle pas des attributs (propriétés en fait) mais des entités types du MCD qui deviendront effectivement des tables dans le MLD.

[fsmrel]

Bonsoir à vous deux, Kévin bomberwaterman et CinePhil,


Me permettrez-vous une digression ?

j'aurais mis l'id de la mobilité dans ma table site. Ce qui me donne une flèche pointant vers ma table Mobilite. Mais selon ce que je lis partout ce serait l'inverse.

La flèche peut aller dans un sens ou dans l’autre...

Historiquement parlant, disons que, depuis la fin des années soixante jusqu’au milieu des années quatre-vingts, on utilisait les diagrammes de BACHMAN, repris au début des années soixante-dix par CODASYL (Conference On Data Systems Languages) et les SGBD conformes à la norme établie par CODASYL étaient dits de type « en réseau » (Network DBMSs). Un AGL comme Power AMC ne les a pas oubliés et, in memoriam, permet d’orienter les flèches à la manière Bachman, c'est-à-dire du référencé vers le référençant (du parent vers l’enfant, par abus de langage) :




D’où par exemple le MLD :




Alors que depuis plus de 25 ans on a plutôt pris l’habitude d’utiliser la notation dite « relationnelle », SGBD/R oblige. Toujours avec Power AMC :




D’où le MLD :





Mais dans tous les cas, pour respecter la contrainte d’intégrité référentielle selon laquelle un site fait nécessairement référence à un type de mobilité, les SGBD relationnels demandent que l’on fasse figurer dans la table SITE l’attribut MobiliteId qui appartient à la clé primaire de MOBILITE, avec mise en œuvre d’une « clé » étrangère pour garantir l’intégrité. Ce principe de réplication d’attributs est au cœur du Modèle Relationnel de Données inventé en 1969 par Ted Codd, et lui confère son caractère associatif : on manipule uniquement par association des valeurs dans les colonnes (ce que l’opérateur relationnel JOIN illustre parfaitement).

Au contraire, selon un diagramme de Bachman conforme à la norme CODASYL, on fonctionne seulement par pointeurs et l’attribut MobiliteId n’est pas recopié dans SITE. Avec des SGBD du type en réseau comme IDS/2 ou IDMS, on se limite donc au diagramme :




On « navigue » entre MOBILITE et SITE en parcourant une chaînes de pointeurs (pointer chasing) formant ce qu’on appelle un set (nommé Composition dans l’exemple ci-dessus), lequel garantit notamment qu’un site ne peut faire référence qu’à un seul type de mobilité (équivalent de la cardinalité maximale 1).

Un des inconvénients majeurs de ce système est que, pour une occurrence de SITE, l’accès aux données de l’occurrence de MOBILITE correspondante et réciproquement n’est possible qu’en suivant les pointeurs (ce qui est pénible, anti-performant, on est au niveau du comment (on manipule des enregistrements, et les curseurs SQL sont dans cet esprit) au lieu du quoi (manipulation d’ensembles), et toutes ces sortes de choses, ce qui fait que les SGBD de type réseau ont été tout naturellement supplantés par les SGBD relationnels).

Fin de la digression à caractère historique...

[Richard_35]

Bonjour à tous,

@Bomberwaterman, je ne suis pas, non plus, un spécialiste de la chose mais, es-tu certain que :

1 SITE possède, forcément, 1 et 1 seul EQUIP_ANALOGIQUE (au singulier)

comme le montre ton schéma.

Cela voudrait dire qu'un site ne peut pas être "tout numérique", autrement dit, un site possède forcément, au moins 1 fax ou 1 equip_autre ou 1 borne_dect ou serveur_fax="oui" ou carte_analogique="oui" ("ou" non exclusif).

En effet, si tous les attributs de cette entité sont =0 et ="non", il n'y a aucun intérêt à saisir un enregistrement dans cette table, en final.

[CinePhil]

À Bomberwaterman de nous le dire mais j'ai compris ces entités types EQUIP_X comme des équipements ayant une capacité de branchements, pas comme un ensemble possédant un fax, une borne dec...

Par exemple, un site pourrait avoir un équipement analogique de marque Alcatel de référence 12345 et ayant la capacité de brancher 12 fax, 3 cartes dec... alors qu'un autre site aura un autre type d'équipement avec des caractéristiques différentes.

[Richard_35]

Non, non, Philippe, je ne pense pas.

D'ailleurs, avec ta remarque, et de par les attributs de EQUIP_ANALOGIQUE, nous devrions avoir :

SITE -0,1---[Posséder]---1,1- EQUIP_ANALOGIQUE

si je n'm'abuse. En effet :

• 0,1, compte tenu de ma remarque précédente (un site pourrait être "tout numérique") ;
• 1,1, car 0,n voudrait dire que l'on veut unifier un même ensemble {Nb_fax, Nb_equip_autre, Nb_borne_dect, Serveur_fax, Carte_analogique}. Autrement, dit si un site achète une autre borne DECT, il faudrait créer un autre groupe {Nb_fax, Nb_equip_autre, Nb_borne_dect, Serveur_fax, Carte_analogique}, ce qui me semble curieux...

A moins que je n'ai rien compris, ce qui, ma foi, est tout à fait possible.

[CinePhil]

Nous supputons en extrapolations sur un domaine dont nous ignorons à peu près tout (moi en tout cas) alors laissons Bomberwaterman répondre et réfléchir à ses règles de gestion en fonction des indications que nous lui avons données.

[bomberwaterman]

@fsmrel
VISIO semble adopter la même vision relationnelle que POWERAMC car le placement de la clé étrangère par rapport au sens de la flèche est le même.
Merci pour ce retour historique intéressant.

@Richard35

1 SITE possède, forcément, 1 et 1 seul EQUIP_ANALOGIQUE (au singulier)

comme le montre ton schéma.

Cela voudrait dire qu'un site ne peut pas être "tout numérique", autrement dit, un site possède forcément, au moins 1 fax ou 1 equip_autre ou 1 borne_dect ou serveur_fax="oui" ou carte_analogique="oui" ("ou" non exclusif).

En effet, si tous les attributs de cette entité sont =0 et ="non", il n'y a aucun intérêt à saisir un enregistrement dans cette table, en final.

Exact, ton raisonnement est correct et ma cardinalité fausse.
Un site peut ne pas avoir d'équipements analogiques et il vaudrait mieux donc avoir 0-1 d'un côté

1,1, car 0,n voudrait dire que l'on veut unifier un même ensemble

Pour cet autre côté, je ne suis pas sûr de comprendre.
Imaginons j'ai un site sur lequel se trouve 1 serveur de fax et 3 équipements analogiques de type autre. Ces propriétés peuvent être utilisées pour un autre site aux propriétés similaires.
J'aurais donc vu un 1-N, et non 0-N qui obligerait à prévoir tous les cas de figure possible et ils ne seraient pas tous utilisés.

Plus globalement, les cardinalités côté des tables (on parle d'entité pour un MCD je ne sais plus) EQUIP_RESEAU, LIENS, EQUIP_DATACENTER doivent avoir un 1-N, je ne crée pas la table avec des attributs dont les valeurs ne seront pas utilisées.

[bomberwaterman]

Au niveau des cardinalités, quand je fais un "check intégrité", il me dit que

est de type* * Le rôle navigable a une multiplicité maximale plus grande que l'autre rôle.
possède* * Le rôle navigable a une multiplicité maximale plus grande que l'autre rôle.
Possède* * Le rôle navigable a une multiplicité maximale plus grande que l'autre rôle.
Possède* * Le rôle navigable a une multiplicité maximale plus grande que l'autre rôle.
Association* * Le rôle navigable a une multiplicité maximale plus grande que l'autre rôle.

[IMG][/IMG]

Et c'est uniquement des relations 0-1 vers 0-N, que cela signifie t-il ?