Bonjour,
Je suis entrain de faire un MCD pour ma base de données. Ma question est si les boucles fermées sont authorisées dans le MCD?
Merci de votre aide.
Bonjour,
Je suis entrain de faire un MCD pour ma base de données. Ma question est si les boucles fermées sont authorisées dans le MCD?
Merci de votre aide.
Formellement ça n'est pas interdit (cas notamment de l'auto-référence), mais si on peut procéder autrement c'est nettement préférable. Cela dit, montrez un exemple (un dessin vaut mieux qu’un long discours) de ce qui vous préoccupe, pour que l'on puisse répondre de façon plus précise.
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Bonjour,
J'ai un cas similaire à skatah, à savoir une relation fermée sur une table (voir pièce jointe) : une table Projet, le projet A peut être lié à plusieurs autres projets ou pas (relation 0-n).
Est-ce que ce cas de figure est correct (je n'ai pas souvenir de ce type de situation en Merise) et se traduit bien en SQL ?
Bonjour,
Etant donné que des projets ont tout à fait le droit d’être liés à d’autres projets, votre MCD est correct, mais il serait bon de le compléter en précisant le rôle que joue la patte droite de l'association-type et celui que joue la patte gauche.
En revanche, votre MLD comporte une erreur : vous avez deux attributs portant le même nom (id_projet). En outre, l’attribut type_de_relation devrait apparaître dans l’association-type figurant dans le MCD et ne devrait pas figurer dans la clé de la table, sauf justification explicite.
Voici un autre exemple d’association-type réflexive, que j’ai déjà proposé à leDelb, dans un contexte ACCESS :
Des pièces entrent dans la composition d’autres pièces et des pièces sont composées de pièces.
Table des Pièces :
Table des composants et des composés :
Le MCD correspondant est celui-ci :
Et le MLD :
En SQL :
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 Create Table PIECE ( PieceId Char(10) Not null, PieceNom Varchar(48) Not null, Constraint PIECE_PK Primary Key (PieceId) ) ; Create Table COMPOSITION ( ComposantId Char(10) Not null, ComposeId Char(10) Not null, Quantite Int Not null, Constraint Composition_PK Primary Key (ComposantId, ComposeId), Constraint Composition_Composant Foreign Key (ComposantId) References PIECE (PieceId), Constraint COMPOSITION_Composé Foreign Key (ComposeId) References PIECE (PieceId) ) ;
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
C'est une modélisation tout à fait valide.
Il manque cependant une règle de gestion pour expliquer la 2e cardinalité 0-n.
On représente souvent les projets de manière hiérarchique et donc avec une patte en 0-1.
La règle de gestion usuelle est : un projet a au maximum un projet parent.
Votre modèle correspond au cas des références entre projets :
- Un projet peut référencer plusieurs projets
- Un projet peut être référencé par plusieurs projets
Il va même plus loin puisque la relation comporte aussi un attribut identifiant supplémentaire.
C'est le cas courant des partenaires :
Un partenaire peut avoir plusieurs rôles différents (client, fournisseur, contact, prospect, etc.) pour un autre partenaire (ou lui-même).
Dans l'absolu, vous avez ici une relation ternaire.
Fais mourir ton ennemi de plaisir ! Si tu le rates, il mourra d'ennui...
__________________
Pensez à cliquer sur
Merci à vous deux pour ces réponses.
pfortin > j'ai utilisé ici le terme de "projet" pour l'exemple, l'objet réellement concerné étant plus abscon. Il s'agit en effet d'une nomenclature non-hiérarchique telle que vous l'entendez, un projet peut être référencé par aucun ou plusieurs projets et il peut lui même en référer aucun ou plusieurs.
Dans le cas de la relation ternaire, cela équivaudrait à sortir le type de relation dans une table distincte ainsi que les projets mis en relation (voir ternaire.png), quels serait les avantages par rapport à la référence circulaire qui me semble plus simple de prime abord ?
fsmrel > merci de l'exemple, je vois mieux comment ça se goupille. Mon hésitation venait du fait que le logiciel de modélisation que j'emploie (AnalyseSI) ne gère pas ce type de cas. Par curiosité, les schémas MCD/MLD et le code SQL ont-ils été généré via un logiciel, si oui lequel ?
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
JRM__,
Votre ternaire n’est pas correcte :
En effet votre association-type En relation avec est la rencontre des entités-types Projet, Relation et Projets en relation et a donc pour identifiant le triplet constitué par les identifiants des trois entités-types (dont vous n’avez fourni qu’un seul d’entre eux). A supposer que la ternaire soit pertinente, pour reprendre votre 1er MCD, il aurait fallu utiliser une représentation s'inspirant de la suivante :
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Merci de cette correction, la modélisation ternaire de cette relation apporte-t-elle un avantage par rapport à la boucle fermée seule*? Le seul que je discerne pour le moment est qu'une seule occurrence de chaque type_de_relation sera nécessaire, mais c'est vite contre-balancé par le référentiel qui sera intégré à chaque enregistrement de la table. COMPOSITION... ce qui reviendrait in fine à la même chose que le premier MCD.
Reprenons l’association-type binaire COMPOSITION :
Et la valeur de la table correspondante :
Les deux premières lignes expriment le fait qu’une aile est notamment composée d’un aileron et de cinq longerons.
De la même façon, on apprend qu’une charnière peut entrer dans la composition de deux ailerons et de trois trains.
Mais dans tous les cas, la paire <aile, aileron> n’existera qu’une seule fois dans la table, même chose pour les autres paires, parce que la paire {ComposantId, ComposeId} est clé de la table COMPOSITION et donc contrainte par la règle d’unicité des clés qui veut qu’une valeur de clé y soit unique.
Maintenant, selon le diagramme conceptuel qui suit, l’association-type devenant ternaire, ce n’est plus la paire {ComposantId, ComposeId} qui est astreinte à satisfaire à la règle d’unicité des clés, mais le triplet {ComposantId, ComposeId, Type_De_Relation}.
Ainsi, contrairement à ce qui se passe avec l’association-type binaire, on pourrait associer plusieurs fois une aile et un aileron :
<aile, aileron, type1>
<aile, aileron, type2>
etc.
En 1re lecture : ????
En 2e lecture : !!!!
En 3e lecture : ????
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Concernant cette différence de clés primaires, n'obtiendrait-on pas quelque chose de similaire avec
sur le 1er MCD ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part Constraint Composition_PK PRIMARY KEY (ComposantId, ComposeId, Type_De_Relation)
Et encore merci pour ces éclaircissements
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager