Discussion :

[sourire05]

Salem tout le monde

voila mon problème , j'ai fait un schéma entité-association de mon base de donnée mais je pense qu'il y a un erreur dans mon diagramme , aidez moi svp





merci d'avance.

[yimson]

Bonjour,

A priori, il y a un problème car je retrouve plusieurs boucles dans ton modèle E-A. Bien vouloir revoir les règles de gestion.

[seabs]

Bonjour,

Pour traiter ta demande, il me semble que tu ne sois pas dans le bon forum. A mon avis, il vaut mieux poster ici.

http://www.developpez.net/forums/f62...sation/schema/

Sur ce forum, tu as les vrais spécialistes du MCD comme fsmrel et autres (que je salue au passage), ils vont te mettre sur la bonne voie et t'expliquer les erreurs à ne pas commettre.

J'ai survolé ton MCD. Effectivement, il est nécessaire de le revoir.

Bon courage

[fsmrel]

Bonjour à tous,


Je vais essayer de trouver un moment pour regarder tout ça, mais il y aura une remise à plat complète...

A plus tard,


François

[fsmrel]

Comme aurait pu dire Françoise Sagan, Bonjour Sourire,

Pour commencer, faut pas pleurer ^^

L’objet de votre modélisation a trait aux achats et ventes d’un seul et non pas de plusieurs pépiniéristes, en conséquence de quoi il est inutile de modéliser une entité-type PÉPINIÉRISTE. Pour la petite histoire, les théoriciens aiment bien donner un nom à l’objet unique de notre préoccupation et qui est au coeur de la modélisation, ils appellent cet objet « univers du discours » (ou plus simplement univers) et dans votre cas, il s’agit de l’activité d’une pépinière, on pourra donc appeler cet univers : PÉPINIÈRE. Ça peut vous faire de la peine, mais il en ressort que l’entité-type PÉPINIÉRISTE doit être retirée de votre MCD.

Par ailleurs, comme tous les énoncés qui ne sont pas accompagnés d’exemples, l’interprétation que nous en faisons n’est que rarement celle de celui qui l’a rédigé... Un énoncé de ce genre comporte en général des ambiguïtés, des flous, des manques, mais on fera avec.

Quoi qu’il en soit, je vous laisse réfléchir à cette ébauche provisoire, non dérivable en l’état (traitement des retoursà aménager) et que seabs se fera un plaisir de commenter (de façon positive j’espère)^^...



J’ai des remarques que j’ai commencé à rédiger et que je vous soumettrai. En attendant, bon courage !

[sourire05]

merci fsmrel c trés gentil , 10000000 merciiiiiiii

[sourire05]

Pour la requete 3, c'est juste ou nn !!!

Code :

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

1
2
3
4
5
6
7
select f.FournId , v.VégétaleId, v.VégétaleNom
from Végétale v , Fournisseur f ,Retour r,Achat ac
where v.VégétaleId =r.VégétaleId And
r.AchatId=ac.AchatId And 
ac.FournId=f.FournId;
Group by f.FournId,v.VégétaleId, v.VégétaleNom;

[fsmrel]

Bonjour Sourire,

Vous allez plus vite que la musqiue ! Où est votre MLD ? Quel est votre SGBD ?

Par ailleurs, je sui occupé jusqu'à ce soir, je ne pourrai pas répondre avant cette nuit...

En attendant, bon courage !

[sourire05]

voila le Schéma relationnel :
Lot ( LotId, # FournId, LotDate, LotMantant, LotQte).
Fournisseur (FournId, FourNom, fourVille, FourcCodePostal, FourPays).
Achat (AchatId, #FournId, #VégétaleId , #JardinId, AchatDate, AchatMantant, AchatQte).
Client (ClientId, ClientNom,ClientPrénom , date _nais).
Jardin (JardinId, #ClientId, JardinVille, JardinPays, JardinCodePostal ).
Végétale (VégétaleId, #EspèceId, VégétaleNom).
Espèce ( EspèceId , EspèceNom ).
Retour (RetourId ,#AchatId, #VégétaleId, RetourDate, RetourQte, RetourMotif).
Composer (#LotId, #VégétaleId ).
Accorder (#AchatId, #RetourId).
merci d’avance

[fsmrel]

Bonjour Sourire,


Vous voulez aller vite et on le comprend, néanmoins il faut d’abord s’assurer de la solidité des fondements de l’édifice, que l’énoncé qu'on a vous a fourni soit limpide ou flou...

Dans le MCD que je vous ai proposé la dernière fois, j’ai fait figurer une association COMPOSER (que je renomme en COMPOSITION dans le code SQL) : son rôle est de permettre de garantir les contraintes C1 et C2 suivantes :

(C1) L’achat effectué par un client doit concerner un végétal d’une espèce entrant dans la composition du lot fourni au pépiniériste par le fournisseur mentionné dans l’achat.

(C2) La date d’achat d’un végétal par un client ne doit pas être antérieure à la date à laquelle un fournisseur a fourni ce végétal au pépiniériste.

Partons de l’extrait suivant du MCD (dont sont absents JARDIN, etc., dont on n'a pas besoin pour le moment) :



MLD correspondant :



Code SQL :

Table FOURNISSEUR

Code SQL :

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

1
2
3
4
5
6
CREATE TABLE FOURNISSEUR
(
        FourId           CHAR(3)           NOT NULL
      , FourNom          VARCHAR(64)       NOT NULL
    , CONSTRAINT FOURNISSEUR_PK PRIMARY KEY (FourId)        
) ;

Table ESPECE

Code SQL :

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

1
2
3
4
5
6
CREATE TABLE ESPECE
(
        EspeceId         CHAR(3)           NOT NULL
      , EspeceNom        VARCHAR(64)       NOT NULL
    , CONSTRAINT ESPECE_PK PRIMARY KEY (EspeceId)        
) ;

Table VEGETAL

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE VEGETAL
(
        VegetalId         CHAR(3)           NOT NULL
      , EspeceId          CHAR(3)           NOT NULL
      , VegetalNom        VARCHAR(64)       NOT NULL
    , CONSTRAINT VEGETAL_PK PRIMARY KEY (VegetalId) 
    , CONSTRAINT VEGETAL_ESPECE_FK FOREIGN KEY (EspeceId) REFERENCES ESPECE
) ;

Table LOT

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
 CREATE TABLE LOT
(
        LotId            CHAR(3)           NOT NULL
      , FourId           CHAR(3)           NOT NULL
      , LotDate          DATE              NOT NULL
      , LotMontant       DECIMAL(10,2)     NOT NULL
      , LotQuantite      INT               NOT NULL
    , CONSTRAINT LOT_PK PRIMARY KEY (LotId)        
    , CONSTRAINT LOT_FOURNISSEUR_FK FOREIGN KEY (FourId) REFERENCES FOURNISSEUR
) ;

Table COMPOSITION (association COMPOSER du MCD)

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE COMPOSITION
(
        LotId            CHAR(3)           NOT NULL
      , VegetalId        CHAR(3)           NOT NULL
    , CONSTRAINT COMPOSITION_PK PRIMARY KEY (LotId, VegetalId)
    , CONSTRAINT COMPOSITION_LOT_FK FOREIGN KEY (LotId) REFERENCES LOT       
    , CONSTRAINT COMPOSITION_VEGETAL_FK FOREIGN KEY (VegetalId) REFERENCES VEGETAL
) ;

Table ACHAT

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE ACHAT
(
      , AchatId          CHAR(3)           NOT NULL
      , AchatDate        DATE              NOT NULL
      , AchatMontant     DECIMAL(10,2)     NOT NULL
      , AchatQte         INT               NOT NULL
      , VegetalId        CHAR(3)           NOT NULL
      , FourId           CHAR(3)           NOT NULL
    , CONSTRAINT ACHAT_PK PRIMARY KEY (AchatId)
    , CONSTRAINT ACHAT_VEGETAL_FK FOREIGN KEY (VegetalId) REFERENCES VEGETAL       
    , CONSTRAINT ACHAT_FOURNISSEUR_FK FOREIGN KEY (FourId) REFERENCES FOURNISSEUR       
) ;

Pour garantir les contraintes C1 et C2 lors des mises à jour de la table ACHAT, si votre SGBD ne propose pas l’instruction CREATE ASSERTION, vous pouvez mettre en œuvre un trigger.

Exemple avec MS SQL Server :

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
17
18
CREATE TRIGGER ACHAT_INSERT ON ACHAT INSTEAD OF INSERT, UPDATE
AS
  DECLARE @N AS INT ;
  SET @N = (SELECT COUNT(*)
            FROM   (SELECT  x.AchatId 
                    FROM   INSERTED AS x INNER JOIN VEGETAL AS y ON x.VegetalId = y.VegetalId 
                           INNER JOIN COMPOSITION AS z ON y.VegetalId = z.VegetalId 
                           INNER JOIN LOT AS t ON z.LotId  = t.LotId          
                           INNER JOIN FOURNISSEUR AS u ON x.FourId = u.FourId 
                                  AND (x.FourId <> t.FourId OR x.AchatDate < t.LotDate)) AS truc)
  IF @N > 0
    BEGIN
        RAISERROR ('Achat incompatible...',15,1) 
    END
  ELSE
    BEGIN
        INSERT INTO ACHAT SELECT * FROM INSERTED
    END

A suivre...

[fsmrel]

Variation...

Revenons sur la contrainte C1 :

(C1) L’achat effectué par un client doit concerner un végétal d’une espèce entrant dans la composition du lot fourni au pépiniériste par le fournisseur mentionné dans l’achat.

Dans le MCD précédent, l’association COMPOSER (renommée en COMPOSITION dans le code SQL) prévue pour C1, connecte LOT et VEGETAL, mais elle peut très bien connecter LOT et ESPECE, à vous de choisir. ^^

La variante MCD est la suivante :



MLD correspondant :




Le code SQL est identique au précédent, sauf évidemment pour la table COMPOSITION :

Table FOURNISSEUR

Code SQL :

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

1
2
3
4
5
6
CREATE TABLE FOURNISSEUR
(
        FourId           CHAR(3)           NOT NULL
      , FourNom          VARCHAR(64)       NOT NULL
    , CONSTRAINT FOURNISSEUR_PK PRIMARY KEY (FourId) 
) ;

Table ESPECE

Code SQL :

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

1
2
3
4
5
6
TABLE ESPECE
(
        EspeceId         CHAR(3)           NOT NULL
      , EspeceNom        VARCHAR(64)       NOT NULL
    , CONSTRAINT ESPECE_PK PRIMARY KEY (EspeceId)        
) ;

Table VEGETAL

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE VEGETAL
(
        VegetalId         CHAR(3)           NOT NULL
      , EspeceId          CHAR(3)           NOT NULL
      , VegetalNom        VARCHAR(64)       NOT NULL
    , CONSTRAINT VEGETAL_PK PRIMARY KEY (VegetalId) 
    , CONSTRAINT VEGETAL_ESPECE_FK FOREIGN KEY (EspeceId) REFERENCES ESPECE
) ;

Table LOT

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE LOT
(
        LotId            CHAR(3)           NOT NULL
      , FourId           CHAR(3)           NOT NULL
      , LotDate          DATE              NOT NULL
      , LotMontant       DECIMAL(10,2)     NOT NULL
      , LotQuantite      INT               NOT NULL
    , CONSTRAINT LOT_PK PRIMARY KEY (LotId)        
    , CONSTRAINT LOT_FOURNISSEUR_FK FOREIGN KEY (FourId) REFERENCES FOURNISSEUR
) ;

Table COMPOSITION

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE COMPOSITION   (association COMPOSER du MCD)
(
        LotId            CHAR(3)           NOT NULL
      , EspeceId         CHAR(3)           NOT NULL
    , CONSTRAINT COMPOSITION_PK PRIMARY KEY (LotId, EspeceId) 
    , CONSTRAINT COMPOSITION_LOT_FK FOREIGN KEY (LotId) REFERENCES LOT
    , CONSTRAINT COMPOSITION_ESPECE_FK FOREIGN KEY (EspeceId) REFERENCES ESPECE
) ;

Table ACHAT

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE ACHAT
(
      , AchatId          CHAR(3)           NOT NULL
      , AchatDate        DATE              NOT NULL
      , AchatMontant     DECIMAL(10,2)     NOT NULL
      , AchatQte         INT               NOT NULL           
      , VegetalId        CHAR(3)           NOT NULL
      , FourId           CHAR(3)           NOT NULL
    , CONSTRAINT ACHAT_PK PRIMARY KEY (AchatId)        
    , CONSTRAINT ACHAT_VEGETAL_FK FOREIGN KEY (VegetalId) REFERENCES VEGETAL
    , CONSTRAINT ACHAT_FOURNISSEUR_FK FOREIGN KEY (FourId) REFERENCES FOURNISSEUR
) ;

Le trigger prévu pour garantir la contrainte C1 évolue en conséquence :

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
17
18
19
CREATE TRIGGER ACHAT_INSERT ON ACHAT INSTEAD OF INSERT, UPDATE
AS
  DECLARE @N AS INT ;
  SET @N = (SELECT COUNT(*)
            FROM   (SELECT  x.AchatId 
                    FROM   INSERTED AS x INNER JOIN VEGETAL AS y ON x.VegetalId = y.VegetalId 
                                         INNER JOIN ESPECE AS e ON y.EspeceId = e.EspeceId 
                                         INNER JOIN COMPOSITION AS z ON z.EspeceId = e.EspeceId 
                                         INNER JOIN LOT AS t ON z.LotId  = t.LotId
                                         INNER JOIN FOURNISSEUR AS u ON x.FourId = u.FourId 
                                                AND (x.FourId <> t.FourId OR x.AchatDate < t.LotDate)) AS truc)
  IF @N > 0
    BEGIN
        RAISERROR ('Achat incompatible...',15,1) 
    END
  ELSE
    BEGIN
        INSERT INTO ACHAT SELECT * FROM INSERTED
    END

A suivre (ne me bombardez pas, je vais à mon rythme...) ^^

[aritas]

C'est pas un peu poussé la notion de trigger pour une débutante en modélisation ? Elle va se faire cramer si elle doit rendre ça

[fsmrel]

Bonne année Sourire,


Toujours à mon rythme...

Passons à une partie ne présentant pas de difficulté : enrichissons le MCD avec les entités-types CLIENT et JARDIN. Étant donné que les fournisseurs et les jardins partagent des propriétés communes : ville, code postal et pays, on peut factoriser ces propriétés dans une entité-type, appelons-la par exemple LOCALITE.

Cette partie du MCD devient la suivante :




MLD correspondant




La partie SQL est complétée ainsi :

TABLE LOCALITE

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE LOCALITE
(
        LocaliteId           CHAR(3)           NOT NULL
      , LocaliteNom          VARCHAR(64)       NOT NULL
      , LocaliteCodePostal   CHAR(5)           NOT NULL
      , LocalitePays         VARCHAR(64)       NOT NULL
    , CONSTRAINT LOCALITE_PK PRIMARY KEY (LocaliteId)
) ;

TABLE FOURNISSEUR

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE FOURNISSEUR
(
        FourId           CHAR(3)           NOT NULL
      , FourNom          VARCHAR(64)       NOT NULL
      , LocaliteId       CHAR(3)           NOT NULL
    , CONSTRAINT FOURNISSEUR_PK PRIMARY KEY (FourId)        
    , CONSTRAINT FOURNISSEUR_LOCALITE_FK FOREIGN KEY (LocaliteId) REFERENCES LOCALITE
) ;

TABLE CLIENT

Code SQL :

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

1
2
3
4
5
6
7
CREATE TABLE CLIENT
(
        ClientId         CHAR(4)           NOT NULL
      , CLientNom        VARCHAR(64)       NOT NULL
      , CLientPrenom     VARCHAR(64)       NOT NULL
    , CONSTRAINT CLIENT_PK PRIMARY KEY (ClientId)        
) ;

TABLE JARDIN

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE JARDIN
(
        JardinId         CHAR(3)           NOT NULL
      , ClientId         CHAR(4)           NOT NULL
      , LocaliteId       CHAR(3)           NOT NULL
    , CONSTRAINT JARDIN_PK PRIMARY KEY (JardinId)        
    , CONSTRAINT JARDIN_CLIENT_FK FOREIGN KEY (ClientId) REFERENCES CLIENT
    , CONSTRAINT JARDIN_LOCALITE_FK FOREIGN KEY (LocaliteId) REFERENCES LOCALITE
) ;

TABLE ACHAT

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
CREATE TABLE ACHAT
(
        AchatId          CHAR(3)           NOT NULL
      , FourId           CHAR(3)           NOT NULL
      , VegetalId        CHAR(3)           NOT NULL
      , JardinId         CHAR(3)           NOT NULL
      , AchatDate        DATE              NOT NULL
      , AchatMontant     DECIMAL(10,2)     NOT NULL
      , AchatQte         INT               NOT NULL
    , CONSTRAINT ACHAT_PK PRIMARY KEY (AchatId)        
    , CONSTRAINT ACHAT_FOURNISSEUR_FK FOREIGN KEY (FourId) REFERENCES FOURNISSEUR
    , CONSTRAINT ACHAT_VEGETAL_FK FOREIGN KEY (VegetalId) REFERENCES VEGETAL
    , CONSTRAINT ACHAT_JARDIN_FK FOREIGN KEY (JardinId) REFERENCES JARDIN
) ;

[fsmrel]

Attaquons la partie plus délicate, ayant trait aux retours de marchandises... Selon l’énoncé qui vous est proposé, un achat peut donc faire l’objet d’un retour.

Supposons que l’achat du client Volfoni porte sur douze pommiers de la variété « Malus domestica 'Transparente de Croncels' » et qu’à la réception, trois d’entre eux s’avèrent détériorés et, pourquoi pas ! deux autres non conformes (en fait de pommiers, il s’agirait de sapins...) Restons néanmoins dans un contexte homogène (je ne voudrais pas vous traumatiser), on va donc admettre que M. Volfoni n’aura reçu que des pommiers, dont trois inutilisables et qu’il ne manquera pas de retourner.

Du point de vue merisien, une modélisation des retours peut être la suivante :

Version Merise 1re génération :



Conceptuellement c’est valide. Mais il y a un problème lors du passage du MCD (schéma entité-association) au MLD (schéma relationnel), car les règles de transformation des associations sont traditionnellement trop simples et donnent lieu ici à un cycle (chose propre à semer la panique dans les bases de données) :



Non seulement l’entité-type RETOUR a son propre identifiant RetourId, alors que AchatId y est identifiant alternatif (et suffit en fait pour identifier RETOUR), mais en plus RetourId vient polluer ACHAT, alors que tous les achats ne font pas l’objet d’un retour (heureusement, sinon le pépiniériste pourrait mettre la clé sous la porte !)

Essayons d’améliorer en utilisant Merise 2e génération (utilisation de l’identification relative) :

a) Notation PowerAMC (cardinalité 1,1 mise entre parenthèses) :




b) Notation WinDesign :



Dans ces deux derniers cas, l’entité-type RETOUR hérite de l’identifiant d’ACHAT (AchatId), en lieu et place de RetourId, ce qui est préférable. Malheureusement, comme on le voit ci-dessous, le cycle est toujours présent (testé en tout cas avec PowerAMC), car la clé étrangère {AchatRetourId} appartenant à la table ACHAT fait référence à la clé primaire {AchatId} de la table RETOUR, donc transitivement ACHAT se fait référence (et on doit donc s’assurer que dans cette table, AchatId = AchatRetourId...) :




Pour éviter la génération dans la table ACHAT de la clé étrangère {AchatRetourId} parasite et propre à ficher la zoubia, utilisons une représentation entité-association selon PowerAMC :




La lettre D entre parenthèses signifie que RETOUR dépend d’ACHAT (et pas l’inverse) et qu’en conséquence il n’y aura pas de génération de cycle. Par ailleurs Le mickey « ⊳ » signifie que l’identifiant de RETOUR est hérité de celui d’ACHAT.

Dérivation en MLD :




Passons à la décision actée par le pépiniériste de remplacer les 3 pommiers litigieux de M. Volfoni.
Étant donné qu’entre le retour et l’accord de remplacement (si donc il se produit), il peut s’écouler un certain temps, on peut choisir de modéliser une entité-type ad-hoc, appelons-la ACCORD_REMPLACEMENT :





On identifie l’entité-type ACCORD_REMPLACEMENT relativement à l’entité-type RETOUR, et en rendant la 1re dépendante de la 2e (entité-type plus forte), ainsi on évite à nouveau un cycle.

Un accord de remplacement fait à son tour l’objet d’un nouvel achat, d’où la l’association entre les entités-types ACCORD_REMPLACEMENT et ACHAT, tout en évitant un cycle :




Dérivation en MLD (schéma relationnel) :




Pour y voir plus clair (mais si !), on a renommé l’attribut AchatId de la table RETOUR en AchatInitialId. Pour en revenir à l’achat initial de M. Volfoni, si l’identifiant AchatId de cet achat a pour valeur 123456 (table ACHAT), l’identifiant AchatInitialId de la table RETOUR y fera référence, donc avec la valeur 123456. Après l’accord de remplacement des 3 pommiers inutilisables, M. Volfoni aura droit à un achat gratuit, repéré dans la table ACHAT par un tuple de clé disons 314116, référencée par l’attribut AchatRemplacementId de la table ACCORD_REMPLACEMENT.

Reste le problème des végétaux choisis par M. Volfoni, car selon l’énoncé, les pommiers inutilisables peuvent être remplacés par des végétaux de la même espèce.

Je n’y connais rien en horticulture mais pour être essayer d’être pertinent, je fais référence à ce que proposent les excellentes Pépinières Rouxel, qui nous apprennent que le pommier « Malus domestica 'Transparente de Croncels' » est un cultivar (même chose pour le pommier « Malus domestica 'Golden Delicious' »), c'est-à-dire une variété végétale, de l’espèce « Malus Domestica » :






Clairement, ce que votre énoncé appelle « végétal » correspond donc au cultivar, en conséquence de quoi, puisqu’il y est écrit qu’« un végétal est d’une espèce donnée », vu la hiérarchie taxonomique ci-dessus, les « Malus domestica 'Transparente de Croncels' » achetés initialement par M. Volfoni peuvent être remplacés par des « Malus domestica 'Golden Delicious' ».

Comme par hasard, M. Volfoni demandera qu’on remplace les 3 pommiers « Malus domestica 'Transparente de Croncels' » défectueux par deux pommiers « Malus domestica 'Transparente de Croncels' » et un pommier « Malus domestica 'Golden Delicious' ».

Toutefois, ça paraît difficile, car votre énoncé comporte une sorte de contradiction : il précise en effet d’une part que des végétaux défectueux peuvent être remplacés par d’autres, de même espèce, ce dont on vient de traiter, mais il est aussi précisé que le remplacement ne pourra faire l’objet que d’un unique autre achat (gratuit), or un achat ne peut faire mention que d’un seul type de végétal, donc de pommier dans le cas de M. Volfoni...

A supposer qu’on veuille malgré tout remplacer les 3 pommiers « Malus domestica 'Transparente de Croncels' » par deux pommiers « Malus domestica 'Transparente de Croncels' » et un pommier « Malus domestica 'Golden Delicious' », alors il y faudra deux achats gratuits, un par type de végétal.


A vous de jouer.


N.B. Il y a certaines contraintes d’intégrité à garantir :

Dans le cas de la table ACCORD_REMPLACEMENT, on doit s’assurer que les attributs AchatInitialId et AchatRemplacementId ont des valeurs différentes, on doit aussi s’assurer que la date de retour (attribut RetourDate de la table RETOUR) ne soit pas antérieure à la date d’achat initial (attribut AchatDate de la table ACHAT, que la date d’accord (attribut DateAccord de la table ACCORD_REMPLACEMENT) ne soit pas antérieure à la date de retour, que la date de l’achat gratuit ne soit pas antérieure à la date de l’accord, j’en passe et des meilleures quant aux quentités, etc. ^^)