Discussion :

[scarface71]

sltt ! je voudrais savoir si c'est possible d'avoir une Relation binaire (1,1)-(1,1) ou si c'est bien une erreur de conception.

ex : chaque exercice porte sur 1 seul theme unique

EXERCICE 1,1 ----- porte ------1,1 THÈME


C'est correct ca ? ou y a-t-il une autre facon de faire ?

[Richard_35]

Bonjour Scarface71,

Je te suggère de jeter un coup d'oeil sur ce billet de CinePhil qui balaye toutes les cardinalités possibles entre deux entités.

Pour répondre, précisément, à ta question, les cardinalités 1,1-1,1 sont une erreur de conception.

Néanmoins, il faut tempérer le terme "erreur de conception" si une base de données est déjà en place avec une application qui l'exploite : parfois, dans la "vraie vie", il est nécessaire de créer ce genre de "verrue" pour éviter de mettre le bazar dans l'application existante, si cette modification génère de lourdes opérations.

Dans ton exemple, la règle de gestion sous-jacente à ton mini-MCD est la suivante :

1 exercice porte, forcément, sur 1 et 1 seul thème ;
1 thème comporte, forcément, 1 et 1 seul exercice.

deux questions se posent :

1. la règle de gestion sous-jacente à ton mini-MCD est-elle correcte ?
2. si oui, ton mini-MCD est-il une erreur de conception ?

1. la règle de gestion sous-jacente à ton mini-MCD est-elle correcte ?
Personnellement, je pense que cette règle de gestion est incorrecte. Elle devrait être la suivante :

1 exercice porte, forcément, sur 1 et 1 seul thème ;
1 thème peut comporter 1 ou plusieurs exercices.

donnant :

Thème -0,n---[Comporte]---1,1- Exercice

donnant :

Theme(IdTheme, Nom, ...)
Exercice(IdExercice, #IdTheme, ...)

2. si oui, ton mini-MCD est-il une erreur de conception ?
Compte tenu des remarques initiales :

• soit l'application est en cours de conception : dans ce cas, oui, il s'agit d'une erreur de conception ;
• soit l'application tourne déjà : dans ce cas, non, il ne s'agit pas, à proprement parler, d'une erreur de conception. Peut-être que les modifications sont tellement lourdes qu'une "verrue" est nécessaire.

En l'occurrence, le lien entre un exercice et un thème semble couler de source dès la conception : il est donc peu probable que l'application tourne déjà sans lien entre un exercice et un thème.

Le verdict est donc, de mon point de vue: il s'agit d'une erreur de conception.

[scarface71]

Merci pour le site ! Il va beaucoup m'aider!

D'après ce que j'ai compris, la règle de gestion que j'ai énoncé est incorrecte.
Mais, cette règle provient d'un sujet de TD de ma prof et pas de moi.

Comment répondre à ce petit problème ?
Je ne me vois pas lui dire que sa règle n'est pas correcte.

[Richard_35]

Je ne me vois pas lui dire que sa règle n'est pas correcte.

==> : toute discussion est impossible ?...

Comment répondre à ce petit problème ?

==> je te suggère de te faire confirmer la règle de gestion sous-jacente au MCD :

EXERCICE 1,1 ----- porte ------1,1 THÈME

qui est :

1 exercice porte, forcément, sur 1 et 1 seul thème ;
1 thème comporte, forcément, 1 et 1 seul exercice.

donnant :

Exercice(IdExercice, EnoncéExercice, {autres attributs de l'exercice}, NomDuThème, {autres attributs du thème})

[fsmrel]

Bonsoir,

les cardinalités 1,1-1,1 sont une erreur de conception.

Depuis quand ? Quelles preuves apportez-vous ?

S’il en est ainsi, les concepts de bijection et d’isomorphisme sont aussi des erreurs et il faut les éliminer.

[Richard_35]

Bonjour Fsmrel,

les cardinalités 1,1-1,1 sont une erreur de conception.

Depuis quand ? Quelles preuves apportez-vous ?

Le verdict est donc, de mon point de vue: il s'agit d'une erreur de conception.

S’il en est ainsi, les concepts de bijection et d’isomorphisme sont aussi des erreurs et il faut les éliminer.

==> il s'agit juste d'un point de vue de "non-merisien-de-naissance" ...!... sans connaissance de la théorie complète (et c'est un manque). C'est pour cela que j'ai pris la peine de développer un peu (comme je l'ai senti).

[CinePhil]

Richard, puisque tu donnes un lien vers mon billet de blog, tu aurais pu y (re)lire ceci :

Cas 06) A -1,1—-associer—-1,1- B
Lorsque les deux couples de cardinalités sont à 1,1, on doit se demander si on peut fusionner les deux entités. Si elles représentent des choses sémantiquement différentes ou si on les conserve pour une raison technique (ajout de table à une BDD existante, amélioration des performances par séparation de données importantes en volume mais rarement lues…), on a le choix de la table qui accueillera la clé étrangère.

Je n'y dis pas que c'est une erreur de conception mais c'est une indication d'une possible erreur de conception qui demande de vérifier "si on peut fusionner les deux entités".

D'après ce que j'ai compris, la règle de gestion que j'ai énoncé est incorrecte.
Mais, cette règle provient d'un sujet de TD de ma prof et pas de moi.

Ce que tu as donné n'est pas une règle de gestion mais une association schématisée comme dans un MCD.

Une règle de gestion est une phrase décrivant ce qu'il se passe pour chaque entité associée vis à vis de l'autre.

Ton association représente la règle de gestion suivante :
"Un exercice porte sur un seul thème et un thème est porté par un seul exercice."

Elle peut être vraie dans le cadre d'un devoir qui comporterait plusieurs exercices, chacun sur un thème différent mais si l'objet du modèle de données est l'ensemble des devoirs au cours de l'année, il est peu probable que chaque thème ne fasse l'objet que d'un seul exercice.

En fait, tu as énoncé un morceau de règle de gestion :

ex : chaque exercice porte sur 1 seul theme unique

Il manque la contraposée pour pouvoir établir les cardinalités côté thème de l'association :
exercice -1,1----porter----x,y- thème

En l'état, tu ne peux pas déterminer les cardinalités x et y. Soit le reste de l'énoncé comporte une phrase permettant de déduire sans ambigüité x et y, soit il te laisse une certaine liberté et il serait plus logique que ces cardinalités soient 0,n ou 1,n.

[fsmrel]

Bonsoir,


On est d’accord, au niveau conceptuel on modélise la finalité, sans tenir compte des contraintes technologiques et bassement matérielles qui peuvent apparaître au niveau du SGBD, donc on ne fusionne pas les entités-types.

Je reprends l’exemple que j’utilise à l’occasion, celui des factures et des livraisons des produits facturés. Au niveau du MCD, la représentation est la suivante :

[FACTURE]----1,1----(R)----1,1----[LIVRAISON]

C'est-à-dire qu'une facture fait l'objet d'une et une seule facture et réciproquement.

On a établi une bijection entre les deux entités-types (donc un cycle, même si ça ne saute pas aux yeux, mais au niveau conceptuel, il n’y a aucun problème).

Grimpons au niveau relationnel. Du point de vue de la théorie relationnelle, on écrit :

Relvar (variable relationnelle) FACTURE :

Code D :

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

1
2
3
4
5
6
7
8
9
10
11
12
VAR FACTURE BASE RELATION 
{
        FactureId        FactureId
      , FactureDate      DATE
      , FactureHorsTaxe  Montant
      , FactureTVA       Montant
      , LivraisonId      LivraisonId
      , ...
}
KEY {FactureId}
KEY {LivraisonId}
;

Relvar LIVRAISON :

Code D :

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

1
2
3
4
5
6
7
8
9
10
11
12
VAR LIVRAISON BASE RELATION 
{
        LivraisonId        LivraisonId
      , LivraisonDate      DATE
      , LivraisonAdresse   CHAR
      , LivraisonContact   CHAR
      , FactureId          FactureId
      , ...
}
KEY {LivraisonId}
KEY {FactureId}
 ;

Inutile de mettre en œuvre des clés étrangères :

Code D :

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

1
2
3
4
5
6
7
VAR FACTURE BASE RELATION
    ...
    FOREIGN KEY {LivraisonId} REFERENCES LIVRAISON ;

VAR LIVRAISON BASE RELATION
    ...
    FOREIGN KEY {FactureId} REFERENCES FACTURE ;

En effet, ces clés étrangères n’empêcheront pas que l’on puisse violer les contraintes d’intégrité référentielle. Exemple :

Code :

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

1
2
3
4
5
6
7
FACTURE                                   LIVRAISON
+------------+--------------+             +--------------+------------+
| FactureId  |  LivraisonId |             | LivraisonId  |  FactureId |
|------------+--------------|             |--------------+------------|
|       123  |          314 |             |         314  |        456 |
|       456  |          271 |             |         271  |        123 |
+------------+--------------+             +--------------+------------+

Pour garantir l'intégrité, il faut et il suffit de mettre en œuvre la contrainte suivante :

Code D :

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

1
2
CONSTRAINT FACTURE_LIVRAISON_CHK01
    FACTURE {FactureId, LivraisonId} = LIVRAISON {FactureId, LivraisonId} ;

Ce qui se lit : La projection de FACTURE sur les attributs FactureId et LivraisonId doit être égale à la projection de LIVRAISON sur ces mêmes attributs.


Quand il s’agit d’effectuer les ajouts, on procède par affectation multiple :

Code D :

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
INSERT FACTURE RELATION {TUPLE {FactureId          FactureId(123),
                                FactureDate        '2012_09_26',
                                FactureHorsTaxe    1000,
                                FactureTVA         50,
                                LivraisonId        LivraisonId(314),
                                ... 
                               }
                        } ,
INSERT LIVRAISON RELATION {TUPLE {FactureId         FactureId(123),
                                  LivraisonDate     '2012_09_28',
                                  LivraisonAdresse  '12 rue de la dalle en pente',
                                  LivraisonContact  'Zorbec Legras',
                                  LivraisonId        LivraisonId(314),
                                  ... 
                                 }
                        } ;

Les deux inserts font partie de la même instruction, ils y sont simplement séparés par une virgule. La fin de l’instruction est marquée par un point-virgule. Les contraintes d’intégrité ne sont vérifiées qu’à des frontières de points-virgules : en l’occurrence tout se passera donc bien.


Cas de SQL

Descendons au niveau des SGBD SQL : ceux-ci ne permettent pas l’affectation multiple (espérons que cela viendra, on peut rêver...), on s’en sort en appliquant les opérations de mise à jour à une vue de jointure, d’où le plus souvent la nécessité d’utiliser aussi un trigger associé à cette vue.

Exemple (je n’ai pas repris tous les attributs secondaires, mais cela ne change rien à la donne) :

Tables de base :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE FACTURE (
   FactureId            INT                  NOT NULL,
   FactureDate          CHAR(10)             NOT NULL,
   LivraisonId          INT                  NOT NULL,
CONSTRAINT FACTURE_PK PRIMARY KEY (FactureId),
CONSTRAINT FACTURE_AK UNIQUE (LivraisonId)) ;
 
CREATE TABLE LIVRAISON (
   LivraisonId          INT                  NOT NULL,
   FactureId            INT                  NOT NULL,
   LivraisonAdresse     VARCHAR(64)          NOT NULL,
   CONSTRAINT LIVRAISON_PK PRIMARY KEY (LivraisonId),
   CONSTRAINT LIVRAISON_AK UNIQUE (FactureId)) ;

Vue de jointure :

Code SQL :

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

1
2
3
4
CREATE VIEW FACTURE_LIVRAISON (FactureId, LivraisonId, FactureDate, LivraisonAdresse)
AS 
    SELECT x.FactureId, x.LivraisonId, x.FactureDate, y.LivraisonAdresse
    FROM   FACTURE AS x JOIN LIVRAISON AS y ON x.FactureId = y.FactureId ;

Trigger pour insert (SQL Server) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TRIGGER FACTURE_LIVRAISON_INSERT_TR ON FACTURE_LIVRAISON INSTEAD OF INSERT AS
 
INSERT INTO FACTURE (FactureId, LivraisonId, FactureDate)
       SELECT FactureId, LivraisonId, FactureDate
       FROM   INSERTED ;
 
INSERT INTO LIVRAISON (FactureId, LivraisonId, LivraisonAdresse)
       SELECT FactureId, LivraisonId, LivraisonAdresse
       FROM   INSERTED ;

Un bout de jeu d’essai :

Code SQL :

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

1
2
3
4
5
INSERT INTO FACTURE_LIVRAISON (FactureId, LivraisonId, FactureDate, LivraisonAdresse) VALUES (1, 1, '2012-11-04', 'Toulouse') ;
INSERT INTO FACTURE_LIVRAISON (FactureId, LivraisonId, FactureDate, LivraisonAdresse) VALUES (2, 2, '2012-11-04', 'Rennes') ; 
 
SELECT '' AS 'FACTURE', * FROM FACTURE ;
SELECT '' AS 'LIVRAISON', * FROM LIVRAISON ;

[Richard_35]

Bonjour à tous,

Philippe, rassures-toi, j'ai bien tout lu (y compris le passage que tu mentionnes), c'est pour cela que je me permets de recommander ton billet à tour de bras... ... !

Fsmrel, encore une démonstration brillante... ... ! Juste une remarque : en termes conceptuels (je ne sais pas comment dire autrement), il me semble que FACTURE et LIVRAISON sont plus éloignées l'une de l'autre, que EXERCICE et THEME, surtout si l'application n'existe pas encore et que nous sommes certains que 1 exercice porte sur 1 et 1 seul thème et que 1 thème ne comporte qu'1 et 1 seul exercice.

Scarface71, je pense que tu disposes, maintenant, de différentes réponses argumentées en fonction des sensibilités et expériences de chacun. Ces réponses t'aideront, sans aucun doute, dans ton étude.

[scarface71]

Merci beaucoup de vos réponses ! Ca m'a beaucoup m'aider!!
A la prochaine !!