IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Entité Date unique ? [MLD]


Sujet :

Schéma

  1. #21
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 002
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir xeron,


    Citation Envoyé par xeron33 Voir le message
    C'est ce qu'il se passe...
    A quelle question cette réponse correspond-elle ? En effet, elle est précédée du gros paquet que constitue mon précédent message, lui-même truffé de certaines de vos réponses. Il serait préférable que vous utilisiez une balise QUOTE pour chaque point auquel vous apportez une réponse.

    Pour ne pas embrouiller les choses, restons-en pour le moment au cas général.

    Jusqu’ici, il apparaissait que, dans le cas général, une rotation était un ensemble d’armoires, auquel on affectait un seul opérateur à une date donnée :

    Règle RG1 : A une date donnée, un seul opérateur est affecté à une rotation donnée.

    Pour continuer sur l’exemple que j’ai déjà présenté :

    Le 12 mai 2015, c’est Raoul et personne d’autre qui est affecté à la rotation r1. Par conséquent, ce jour là, Fernand ne pourra pas être affecté à la rotation r1.

    Et vous confirmez : « Oui, cette règle est valide ».

    Passons au cas particuliers, je vous cite :

    « Certains opérateurs peuvent être affectés à une Rotation R1 par exemple et une partie de la Rotation R2 (R2 étant partagé par Raoul, Fernand et David); à ce moment là pour être exact il faudrait pouvoir affecter Raoul à une armoire de R2, Fernand à une armoire de R2,David à une armoire de R2. »

    Quand vous dites que certains opérateurs peuvent être affectés à la rotation r1, cela sous entend que ça n’est pas le même jour, sinon il y a contradiction avec la règle RG1.

    Maintenant, que Raoul, Fernand et David se répartissent les armoires pour la rotation r2, pas de problème.

    Questions :

    Q1 : Confirmez-vous que dans le cas général, un jour donné Raoul n’est affecté qu’à une seule rotation ?

    Q2 : Si la réponse à Q1 est positive, confirmez-vous qu’un jour donné, en plus de sa rotation normale, Raoul peut aussi être (exceptionnellement) affecté à une autre rotation ?

    Q3 : Dans le cas exceptionnel, si Raoul, Fernand et David se répartissent les armoires de la rotation r2, peuvent-ils individuellement prendre en charge plus d’une armoire de cette rotation ?

    Q4 : Si Raoul, Fernand et David se répartissent les armoires de la rotation r2, est-ce juste pour la journée ? Est-ce permanent (provisoire qui dure) ?



    Citation Envoyé par xeron33 Voir le message
    On a actuellement :
    type_Rotation (1,n) (Possede) (1,1) type_Armoire
    Jusqu’ici on avait des rotations, et voilà qu’apparaît un concept nouveau celui de « type de rotation ». Il faudrait que vous justifiez et précisiez ce distinguo.

    Question Q5 : si en plus des rotations, apparaissent les types de rotations, les affectations des opérateurs à des rotations sont-elles à remplacer par des affectations à des types de rotations ?



    Citation Envoyé par xeron33 Voir le message
    je rajoute ceci :
    type_Rotation (0,1) (Rajoute) (0,n) type_Armoire
    Quelle règle de gestion des données mettez-vous en face ? Je ne vois pas en quoi ça résout le cas particulier de la rotation partagée r2.
    (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.

  2. #22
    Membre actif
    Profil pro
    Inscrit en
    Février 2007
    Messages
    758
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2007
    Messages : 758
    Points : 208
    Points
    208
    Par défaut
    Bonsoir fsmrel,
    Je vais utiliser les fameuses Quotes que je n'utilisais pas jusqu'ici en espérant être plus clair...



    Citation Envoyé par fsmrel
    A quelle question cette réponse correspond-elle ? En effet, elle est précédée du gros paquet que constitue mon précédent message, lui-même truffé de certaines de vos réponses. Il serait préférable que vous utilisiez une balise QUOTE pour chaque point auquel vous apportez une réponse.
    Citation Envoyé par fsmrel
    Mais si l'on vous suit, Raoul ne pourra être affecté qu’un seul jour à la rotation r1... A partir du lendemain, il faudra affecter quelqu’un d’autre à cette rotation, est-ce bien raisonnable ?
    Et ma réponse était :C'est ce qu'il se passe...

    Pour ne pas embrouiller les choses, restons-en pour le moment au cas général.

    Jusqu’ici, il apparaissait que, dans le cas général, une rotation était un ensemble d’armoires, auquel on affectait un seul opérateur à une date donnée :

    Règle RG1 : A une date donnée, un seul opérateur est affecté à une rotation donnée.

    Pour continuer sur l’exemple que j’ai déjà présenté :

    Le 12 mai 2015, c’est Raoul et personne d’autre qui est affecté à la rotation r1. Par conséquent, ce jour là, Fernand ne pourra pas être affecté à la rotation r1.

    Et vous confirmez : « Oui, cette règle est valide ».

    Passons au cas particuliers, je vous cite :

    « Certains opérateurs peuvent être affectés à une Rotation R1 par exemple et une partie de la Rotation R2 (R2 étant partagé par Raoul, Fernand et David); à ce moment là pour être exact il faudrait pouvoir affecter Raoul à une armoire de R2, Fernand à une armoire de R2,David à une armoire de R2. »

    Quand vous dites que certains opérateurs peuvent être affectés à la rotation r1, cela sous entend que ça n’est pas le même jour, sinon il y a contradiction avec la règle RG1.
    LA règle générale est la suivante : un opérateur est affecté à une Rotation et une seule par jour : c'est à dire : Raoul est affecté à R1, David à R2 etc... et le lendemain les affectations changent on peut avoir Raoul à R3, David à R5

    Maintenant, que Raoul, Fernand et David se répartissent les armoires pour la rotation r2, pas de problème.

    Questions :

    Q1 : Confirmez-vous que dans le cas général, un jour donné Raoul n’est affecté qu’à une seule rotation ?
    Oui

    Q2 : Si la réponse à Q1 est positive, confirmez-vous qu’un jour donné, en plus de sa rotation normale, Raoul peut aussi être (exceptionnellement) affecté à une autre rotation ?
    Il y a deux cas de figures soit Raoul peut dans des cas exceptionnels être affecté à une Rotation supplémentaire, soit partager avec un autre opérateur une Rotation supplémentaire comme je vous ai dis dans mon dernier message :" (R2 étant partagé par Raoul, Fernand et David); à ce moment là pour être exact il faudrait pouvoir affecter Raoul à une armoire de R2, Fernand à une armoire de R2,David à une armoire de R2. »

    Q3 : Dans le cas exceptionnel, si Raoul, Fernand et David se répartissent les armoires de la rotation r2, peuvent-ils individuellement prendre en charge plus d’une armoire de cette rotation ?
    Non

    Q4 : Si Raoul, Fernand et David se répartissent les armoires de la rotation r2, est-ce juste pour la journée ? Est-ce permanent (provisoire qui dure) ?
    C'est juste de façon exceptionnelle juste pour la journée
    ********************************************************************************************
    Citation Envoyé par xeron33
    On a actuellement :
    type_Rotation (1,n) (Possede) (1,1) type_Armoire

    Jusqu’ici on avait des rotations, et voilà qu’apparaît un concept nouveau celui de « type de rotation ». Il faudrait que vous justifiez et précisiez ce distinguo.

    Question Q5 : si en plus des rotations, apparaissent les types de rotations, les affectations des opérateurs à des rotations sont-elles à remplacer par des affectations à des types de rotations ?
    C'est la faute à CinePhil

    Citation Envoyé par CinePhil
    Au passage, nommez vos entités types
    Citation Envoyé par xeron33
    je rajoute ceci :
    type_Rotation (0,1) (Rajoute) (0,n) type_Armoire

    Quelle règle de gestion des données mettez-vous en face ? Je ne vois pas en quoi ça résout le cas particulier de la rotation partagée r2.
    A mon sens cette deuxième association entre les entités Rotation et Armoire permet de rajouter de façon exceptionnelle une ou plusieurs armoires à une rotation, en rajoutant le champ Code_Armoire_Plus dans la table Rotation


    CREATE TABLE ROTATION
    (
    RotationId INT NOT NULL,
    RotationNom VARCHAR(64) NOT NULL,
    Code_Armoire_Plus Int Null,
    CONSTRAINT ROTATION_PK PRIMARY KEY (RotationId),
    Constraint ROTATION_FK FOREIGN KEY (Code_Armoire_Plus)
    REFERENCES ARMOIRES (ArmoireId)

    ) ;


    Merci à vous, j'espère avoir été plus clair
    J'attends vos remarques
    A+

  3. #23
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 002
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir xeron,



    Citation Envoyé par xeron33 Voir le message

    Citation Envoyé par fsmrel Voir le message
    Mais si l'on vous suit, Raoul ne pourra être affecté qu’un seul jour à la rotation r1... A partir du lendemain, il faudra affecter quelqu’un d’autre à cette rotation, est-ce bien raisonnable ?
    Et ma réponse était : C'est ce qu'il se passe...
    Soit... Admettons maintenant que Raoul soit affecté à la rotation r1 le 11 mai 2015. Si malgré tout il doit à nouveau être affecté à r1 le 12 mai 2015, on peut supposer que, dans la table JONCTION2 (que j’ai renommée ci-dessous en AFFECTATION), le triplet (Raoul, r1, 2015-05-11) sera remplacé au moment opportun par le triplet (Raoul, r1, 2015-05-12). Autre façon de voir les choses : le triplet n’est pas remplacé, auquel cas on pourra interpréter le triplet (Raoul, r1, 2015-05-11) comme suit : Raoul est affecté à la rotation r1 depuis le 11 mai 2015. A vous de voir quel scénario est pertinent.

    Quoi qu’il en soit, en ce qui concerne les affectations normales, le diagramme pourrait être le suivant :





    Sans oublier ce qui n’apparaît pas ici, mais devra être présent dans le CREATE TABLE AFFECTATION, sous forme de clé alternative (contrainte UNIQUE) :

    — Dans le cas normal, à une date donnée, un opérateur n’est affectée qu’à une rotation ;

    — Dans le cas normal, à une date donnée, à une rotation n’est affecté qu’un opérateur.



    Citation Envoyé par xeron33 Voir le message
    A mon sens cette deuxième association entre les entités Rotation et Armoire permet de rajouter de façon exceptionnelle une ou plusieurs armoires à une rotation, en rajoutant le champ Code_Armoire_Plus dans la table Rotation.

    CREATE TABLE ROTATION
    (
    RotationId INT NOT NULL,
    RotationNom VARCHAR(64) NOT NULL,
    Code_Armoire_Plus Int Null,
    CONSTRAINT ROTATION_PK PRIMARY KEY (RotationId),
    Constraint ROTATION_FK FOREIGN KEY (Code_Armoire_Plus)
    REFERENCES ARMOIRES (ArmoireId)
    ) ;
    L’énoncé et l’instruction CREATE TABLE sont contradictoires. Selon l’énoncé, il s’agit de pouvoir ajouter plusieurs armoires à une rotation, tandis que selon l’instruction, on ne peut ajouter qu’une seule armoire.

    Supposons que ce soit l’énoncé qui soit juste. Supposons encore que, dans le cas général, les armoires a21, a22 fassent partie de la rotation r2. Supposons qu’exceptionnellement, le 15 mai 2015, l’armoires a21 soit rattachée à la rotation r1 et l’armoire a22 à la rotation r3. Le diagramme (MySQL Workbench) pourrait devenir le suivant :




    Normalement, les clés de la table RATTACHEMENT_EXCEPTIONNEL sont les suivantes :

    K1 = {ArmoireId, RattachementDate}

    K2 = {RotationId, RattachementDate}

    Elles découlent des contraintes suivantes :

    A une date donnée, une armoire peut être exceptionnellement rattachée à une et une seule rotation qui n’est pas sa rotation normale.

    A une date donnée, à une rotation donnée peut être exceptionnellement rattachée une et une seule armoire qui normalement ne lui appartient pas.


    Par exemple, l’armoire a21 fait normalement partie de la rotation r2, mais peut être exceptionnellement rattachée à la rotation r1 le 11 mai 2015. Comme c’est Raoul qui ce jour là s’occupe de la rotation r1, ça sera automatiquement lui qui s’occupera de cette armoire. Aucun autre rattachement exceptionnel d’armoire ne pourra être fait pour r1 ce jour-là.

    De même, l’armoire a22 fait elle aussi normalement partie de la rotation r2, mais peut être exceptionnellement rattachée à la rotation r3 le 11 mai 2015. Comme c’est Fernand qui ce jour là s’occupe de la rotation r3, ça sera automatiquement lui qui s’occupera de cette armoire. Aucun autre rattachement exceptionnel d’armoire ne pourra être fait pour r3 ce jour-là.


    Avec ACCESS



    Script SQL

    
    -- -----------------------------------------------------
    -- Table ROTATION
    -- -----------------------------------------------------
    CREATE TABLE ROTATION 
    (
            RotationId                 INT                   NOT NULL,
            RotationNom                VARCHAR(64)           NOT NULL,
          CONSTRAINT ROTATION_PK PRIMARY KEY (RotationId)
     ) ;
    
    -- -----------------------------------------------------
    -- Table OPERATEUR
    -- -----------------------------------------------------
    CREATE TABLE OPERATEUR 
    (
            OperateurId                INT                   NOT NULL,
            OperateurCode              VARCHAR(5)            NOT NULL,
            OperateurNom               VARCHAR(64)           NOT NULL,
            OperateurPrenom            VARCHAR(64)           NOT NULL,
          CONSTRAINT OPERATEUR_PK PRIMARY KEY (OperateurId),
          CONSTRAINT OPERATEUR_AK UNIQUE (OperateurCode)
    ) ;
    
    -- -----------------------------------------------------
    -- Table AFFECTATION
    -- -----------------------------------------------------
    CREATE TABLE AFFECTATION 
    (
            RotationId                 INT                   NOT NULL,
            OperateurId                INT                   NOT NULL,
            AffectationtDate           DATE                  NOT NULL,
          CONSTRAINT AFFECTATION_PK PRIMARY KEY (RotationId, OperateurId),
          CONSTRAINT AFFECTATION_AK1 UNIQUE (RotationId, AffectationtDate),	  
          CONSTRAINT AFFECTATION_AK2 UNIQUE (OperateurId, AffectationtDate),		  
      CONSTRAINT AFFECTATION_ROTATION_FK FOREIGN KEY (RotationId) REFERENCES ROTATION (RotationId),
      CONSTRAINT AFFECTATION_OPERATEUR_FK FOREIGN KEY (OperateurId) REFERENCES OPERATEUR (OperateurId)
    ) ;
    
    -- -----------------------------------------------------
    -- Table ARMOIRE
    -- -----------------------------------------------------
    CREATE TABLE ARMOIRE 
    (
            ArmoireId                  INT                   NOT NULL,
            ArmoireCode                CHAR(4)               NOT NULL,
            ArmoireNom                 VARCHAR(64)           NOT NULL,
            RotationId                 INT                   NOT NULL,
          CONSTRAINT ARMOIRE_PK PRIMARY KEY (ArmoireId),
          CONSTRAINT ARMOIRE_AK UNIQUE (ArmoireCode),	  
          CONSTRAINT ARMOIRE_ROTATION_FK FOREIGN KEY (RotationId) REFERENCES ROTATION (RotationId)
    ) ;
    
    -- -----------------------------------------------------
    -- Table RANGEMENT
    -- -----------------------------------------------------
    CREATE TABLE RANGEMENT 
    (
            ArmoireId                  INT                   NOT NULL,
            RangementDate              DATE                  NOT NULL,
          CONSTRAINT RANGEMENT_PK PRIMARY KEY (ArmoireId, RangementDate),
          CONSTRAINT RANGEMENT_ARMOIRE_FK FOREIGN KEY (ArmoireId) REFERENCES ARMOIRE (ArmoireId)
    ) ;
    
    -- -----------------------------------------------------
    -- Table DOSSIER
    -- -----------------------------------------------------
    CREATE TABLE DOSSIER 
    (
            ArmoireId                  INT                   NOT NULL,
            RangementDate              DATE                  NOT NULL,
            NbDossiersRecus            INT                   NOT NULL,
            NbDossiersRenvoyes         INT                   NOT NULL,
          CONSTRAINT DOSSIER_PK PRIMARY KEY (ArmoireId, RangementDate),
          CONSTRAINT DOSSIER_RANGEMENT_FK FOREIGN KEY (ArmoireId, RangementDate) REFERENCES RANGEMENT (ArmoireId, RangementDate)
    ) ;
    
    -- -----------------------------------------------------
    -- Table RATTACHEMENT_EXCEPTIONNEL
    -- -----------------------------------------------------
    CREATE TABLE RATTACHEMENT_EXCEPTIONNEL 
    (
            ArmoireId                  INT                   NOT NULL,
            RattachemenDate            DATE                  NOT NULL,
            RotationId                 INT                   NOT NULL,
          CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_PK PRIMARY KEY (ArmoireId, RattachemenDate),
          CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_AK UNIQUE (RotationId, RattachemenDate),	  
      CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_ARMOIRE_FK FOREIGN KEY (ArmoireId) REFERENCES ARMOIRE (ArmoireId),
      CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_ROTATION_FK FOREIGN KEY (RotationId) REFERENCES ROTATION (RotationId)
    )  ;
    
    
    Commence-t-on à se rapprocher de ce qu'attend l'utilisateur ?
    (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.

  4. #24
    Membre actif
    Profil pro
    Inscrit en
    Février 2007
    Messages
    758
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2007
    Messages : 758
    Points : 208
    Points
    208
    Par défaut
    Citation Envoyé par fsmrel
    Soit... Admettons maintenant que Raoul soit affecté à la rotation r1 le 11 mai 2015. Si malgré tout il doit à nouveau être affecté à r1 le 12 mai 2015, on peut supposer que, dans la table JONCTION2 (que j’ai renommée ci-dessous en AFFECTATION), le triplet (Raoul, r1, 2015-05-11) sera remplacé au moment opportun par le triplet (Raoul, r1, 2015-05-12). Autre façon de voir les choses : le triplet n’est pas remplacé, auquel cas on pourra interpréter le triplet (Raoul, r1, 2015-05-11) comme suit : Raoul est affecté à la rotation r1 depuis le 11 mai 2015. A vous de voir quel scénario est pertinent.

    Quoi qu’il en soit, en ce qui concerne les affectations normales, le diagramme pourrait être le suivant :





    Sans oublier ce qui n’apparaît pas ici, mais devra être présent dans le CREATE TABLE AFFECTATION, sous forme de clé alternative (contrainte UNIQUE) :

    — Dans le cas normal, à une date donnée, un opérateur n’est affectée qu’à une rotation ;

    — Dans le cas normal, à une date donnée, à une rotation n’est affecté qu’un opérateur.

    Pour les contraintes je suis d'accord :
    CONSTRAINT AFFECTATION_AK1 UNIQUE (RotationId, AffectationtDate),
    CONSTRAINT AFFECTATION_AK2 UNIQUE (OperateurId, AffectationtDate),

    Par contre je ne comprends pas l'interet de la table Rangement(Armoireid,RangementDate) pourquoi ne pas laisser la table Réception_Retour telle quel :

    RECEPTION_RETOUR {Code_Armoire, DateJour, Nbre_Dossiers_reçus, Nbre_Dossiers_renvoyes}
    PRIMARY KEY {Code_Armoire, DateJour}
    FOREIGN KEY {Code_Armoire} REFERENCES ARMOIRE ;








    Citation Envoyé par fsmrel
    Citation Envoyé par xeron33
    A mon sens cette deuxième association entre les entités Rotation et Armoire permet de rajouter de façon exceptionnelle une ou plusieurs armoires à une rotation, en rajoutant le champ Code_Armoire_Plus dans la table Rotation.

    CREATE TABLE ROTATION
    (
    RotationId INT NOT NULL,
    RotationNom VARCHAR(64) NOT NULL,
    Code_Armoire_Plus Int Null,
    CONSTRAINT ROTATION_PK PRIMARY KEY (RotationId),
    Constraint ROTATION_FK FOREIGN KEY (Code_Armoire_Plus)
    REFERENCES ARMOIRES (ArmoireId)
    ) ;
    L’énoncé et l’instruction CREATE TABLE sont contradictoires. Selon l’énoncé, il s’agit de pouvoir ajouter plusieurs armoires à une rotation, tandis que selon l’instruction, on ne peut ajouter qu’une seule armoire.
    Pouvez vous me dire pourquoi ?
    Citation Envoyé par fsmrel
    Supposons que ce soit l’énoncé qui soit juste. Supposons encore que, dans le cas général, les armoires a21, a22 fassent partie de la rotation r2. Supposons qu’exceptionnellement, le 15 mai 2015, l’armoires a21 soit rattachée à la rotation r1 et l’armoire a22 à la rotation r3. Le diagramme (MySQL Workbench) pourrait devenir le suivant :




    Normalement, les clés de la table RATTACHEMENT_EXCEPTIONNEL sont les suivantes :

    K1 = {ArmoireId, RattachementDate}

    K2 = {RotationId, RattachementDate}

    Elles découlent des contraintes suivantes :

    A une date donnée, une armoire peut être exceptionnellement rattachée à une et une seule rotation qui n’est pas sa rotation normale.

    A une date donnée, à une rotation donnée peut être exceptionnellement rattachée une et une seule armoire qui normalement ne lui appartient pas.


    Par exemple, l’armoire a21 fait normalement partie de la rotation r2, mais peut être exceptionnellement rattachée à la rotation r1 le 11 mai 2015. Comme c’est Raoul qui ce jour là s’occupe de la rotation r1, ça sera automatiquement lui qui s’occupera de cette armoire. Aucun autre rattachement exceptionnel d’armoire ne pourra être fait pour r1 ce jour-là.

    De même, l’armoire a22 fait elle aussi normalement partie de la rotation r2, mais peut être exceptionnellement rattachée à la rotation r3 le 11 mai 2015. Comme c’est Fernand qui ce jour là s’occupe de la rotation r3, ça sera automatiquement lui qui s’occupera de cette armoire. Aucun autre rattachement exceptionnel d’armoire ne pourra être fait pour r3 ce jour-là.

    CREATE TABLE RATTACHEMENT_EXCEPTIONNEL
    (
    ArmoireId INT NOT NULL,
    RattachemenDate DATE NOT NULL,
    RotationId INT NOT NULL,
    CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_PK PRIMARY KEY (ArmoireId, RattachemenDate),
    CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_AK UNIQUE (RotationId, RattachemenDate),
    CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_ARMOIRE_FK FOREIGN KEY (ArmoireId) REFERENCES ARMOIRE (ArmoireId),
    CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_ROTATION_FK FOREIGN KEY (RotationId) REFERENCES ROTATION (RotationId)
    ) ;

    Je suis d'accord avec mais pouvez vous m'éclairer sur le point suivant : dans votre code SQL vous créer la contrainte :
    CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_AK UNIQUE (RotationId, RattachemenDate), pour K2 = {RotationId, RattachementDate} (si j'ai bien tout compris...) pourquoi pas de contrainte unique sur ArmoireID (K1 = {ArmoireId, RattachementDate}) ?

    Avec ACCESS



    Script SQL

    
    -- -----------------------------------------------------
    -- Table ROTATION
    -- -----------------------------------------------------
    CREATE TABLE ROTATION 
    (
            RotationId                 INT                   NOT NULL,
            RotationNom                VARCHAR(64)           NOT NULL,
          CONSTRAINT ROTATION_PK PRIMARY KEY (RotationId)
     ) ;
    
    -- -----------------------------------------------------
    -- Table OPERATEUR
    -- -----------------------------------------------------
    CREATE TABLE OPERATEUR 
    (
            OperateurId                INT                   NOT NULL,
            OperateurCode              VARCHAR(5)            NOT NULL,
            OperateurNom               VARCHAR(64)           NOT NULL,
            OperateurPrenom            VARCHAR(64)           NOT NULL,
          CONSTRAINT OPERATEUR_PK PRIMARY KEY (OperateurId),
          CONSTRAINT OPERATEUR_AK UNIQUE (OperateurCode)
    ) ;
    
    -- -----------------------------------------------------
    -- Table AFFECTATION
    -- -----------------------------------------------------
    CREATE TABLE AFFECTATION 
    (
            RotationId                 INT                   NOT NULL,
            OperateurId                INT                   NOT NULL,
            AffectationtDate           DATE                  NOT NULL,
          CONSTRAINT AFFECTATION_PK PRIMARY KEY (RotationId, OperateurId),
          CONSTRAINT AFFECTATION_AK1 UNIQUE (RotationId, AffectationtDate),	  
          CONSTRAINT AFFECTATION_AK2 UNIQUE (OperateurId, AffectationtDate),		  
      CONSTRAINT AFFECTATION_ROTATION_FK FOREIGN KEY (RotationId) REFERENCES ROTATION (RotationId),
      CONSTRAINT AFFECTATION_OPERATEUR_FK FOREIGN KEY (OperateurId) REFERENCES OPERATEUR (OperateurId)
    ) ;
    
    -- -----------------------------------------------------
    -- Table ARMOIRE
    -- -----------------------------------------------------
    CREATE TABLE ARMOIRE 
    (
            ArmoireId                  INT                   NOT NULL,
            ArmoireCode                CHAR(4)               NOT NULL,
            ArmoireNom                 VARCHAR(64)           NOT NULL,
            RotationId                 INT                   NOT NULL,
          CONSTRAINT ARMOIRE_PK PRIMARY KEY (ArmoireId),
          CONSTRAINT ARMOIRE_AK UNIQUE (ArmoireCode),	  
          CONSTRAINT ARMOIRE_ROTATION_FK FOREIGN KEY (RotationId) REFERENCES ROTATION (RotationId)
    ) ;
    
    -- -----------------------------------------------------
    -- Table RANGEMENT
    -- -----------------------------------------------------
    CREATE TABLE RANGEMENT 
    (
            ArmoireId                  INT                   NOT NULL,
            RangementDate              DATE                  NOT NULL,
          CONSTRAINT RANGEMENT_PK PRIMARY KEY (ArmoireId, RangementDate),
          CONSTRAINT RANGEMENT_ARMOIRE_FK FOREIGN KEY (ArmoireId) REFERENCES ARMOIRE (ArmoireId)
    ) ;
    
    -- -----------------------------------------------------
    -- Table DOSSIER
    -- -----------------------------------------------------
    CREATE TABLE DOSSIER 
    (
            ArmoireId                  INT                   NOT NULL,
            RangementDate              DATE                  NOT NULL,
            NbDossiersRecus            INT                   NOT NULL,
            NbDossiersRenvoyes         INT                   NOT NULL,
          CONSTRAINT DOSSIER_PK PRIMARY KEY (ArmoireId, RangementDate),
          CONSTRAINT DOSSIER_RANGEMENT_FK FOREIGN KEY (ArmoireId, RangementDate) REFERENCES RANGEMENT (ArmoireId, RangementDate)
    ) ;
    
    -- -----------------------------------------------------
    -- Table RATTACHEMENT_EXCEPTIONNEL
    -- -----------------------------------------------------
    CREATE TABLE RATTACHEMENT_EXCEPTIONNEL 
    (
            ArmoireId                  INT                   NOT NULL,
            RattachemenDate            DATE                  NOT NULL,
            RotationId                 INT                   NOT NULL,
          CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_PK PRIMARY KEY (ArmoireId, RattachemenDate),
          CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_AK UNIQUE (RotationId, RattachemenDate),	  
      CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_ARMOIRE_FK FOREIGN KEY (ArmoireId) REFERENCES ARMOIRE (ArmoireId),
      CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_ROTATION_FK FOREIGN KEY (RotationId) REFERENCES ROTATION (RotationId)
    )  ;
    
    
    Citation Envoyé par fsmrel
    Commence-t-on à se rapprocher de ce qu'attend l'utilisateur ?
    Oui ça correspond bien je pense au besoin, merci .
    J'attends vos lumières sur les points que je vous ai signalés cela me permet d'avancer.
    Bonne soirée
    A+


  5. #25
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 002
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir xeron,


    Citation Envoyé par xeron33 Voir le message
    Par contre je ne comprends pas l'intérêt de la table Rangement(Armoireid, RangementDate) pourquoi ne pas laisser la table Réception_Retour telle quelle.
    Il s’agit de partie droite du modèle, partie sur laquelle je ne suis plus penché depuis la proposition que j’avais faite du diagramme ci-dessous, où la table AFFECTATION (alias RANGEMENT ou Réception_Retour) avait un fondement, du fait de l’association avec la table OPERATEUR :




    Mais puisque l’association avec la table OPERATEUR a maintenant disparu, il est évident que la table RANGEMENT est absorbée par la table DOSSIER :




    Votre CREATE TABLE est donc correct.




    Citation Envoyé par xeron33 Voir le message
    Citation Envoyé par fsmrel Voir le message
    L’énoncé et l’instruction CREATE TABLE sont contradictoires. Selon l’énoncé, il s’agit de pouvoir ajouter plusieurs armoires à une rotation, tandis que selon l’instruction, on ne peut ajouter qu’une seule armoire.
    Pouvez vous me dire pourquoi ?
    Tout comme l'eut fait le Sâr Rabindranath Duval, je peux le dire... Étant donné que la clé primaire de la table ROTATION est le singleton {RotationId}, il y a automatiquement une contrainte d’unicité (une dépendance fonctionnelle) qui veut que pour une rotation donnée, par exemple r1, la colonne Code_Armoire_Plus ne peut prendre qu’une valeur, par exemple a21, ce qui est bien en contradiction avec ce que vous aviez écrit :

    « A mon sens cette deuxième association entre les entités Rotation et Armoire permet de rajouter de façon exceptionnelle une ou plusieurs armoires à une rotation, en rajoutant le champ Code_Armoire_Plus dans la table Rotation. »

    => Il serait bon que vous revoyiez la définition la clé candidate (la clé primaire n’en est qu’un cas particulier). K1 et K2 sont des clés candidates, l’une a été élue Miss Clé primaire (clause PRIMARY KEY en SQL) et l’autre s’est contentée d’être clé alternative (clause UNIQUE en SQL).




    Citation Envoyé par xeron33 Voir le message
    pourquoi pas de contrainte unique sur ArmoireID (K1 = {ArmoireId, RattachementDate}) ?
    Pour la simple et bonne raison que la contrainte d’unicité existe déjà, en effet {ArmoireId, RattachementDate} est clé primaire de la table.
    (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.

  6. #26
    Membre actif
    Profil pro
    Inscrit en
    Février 2007
    Messages
    758
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2007
    Messages : 758
    Points : 208
    Points
    208
    Par défaut
    Citation Envoyé par fsmrel
    Tout comme l'eut fait le Sâr Rabindranath Duval, je peux le dire... Étant donné que la clé primaire de la table ROTATION est le singleton {RotationId}, il y a automatiquement une contrainte d’unicité (une dépendance fonctionnelle) qui veut que pour une rotation donnée, par exemple r1, la colonne Code_Armoire_Plus ne peut prendre qu’une valeur, par exemple a21, ce qui est bien en contradiction avec ce que vous aviez écrit :

    « A mon sens cette deuxième association entre les entités Rotation et Armoire permet de rajouter de façon exceptionnelle une ou plusieurs armoires à une rotation, en rajoutant le champ Code_Armoire_Plus dans la table Rotation. »

    => Il serait bon que vous revoyiez la définition la clé candidate (la clé primaire n’en est qu’un cas particulier). K1 et K2 sont des clés candidates, l’une a été élue Miss Clé primaire (clause PRIMARY KEY en SQL) et l’autre s’est contentée d’être clé alternative (clause UNIQUE en SQL).
    En effet j'ai revu mon MCD le voici modifié (sur la partie rajout exceptionnel d'armoires) :

    Rotation (0,n) (rajoute,date) (0,n) Armoire

    Et là où moi je pêche c'est au niveau de la traduction en MLD car je pensais que deux entités reliés par une association dont les deux cardinalités maximales sont de type n se traduisais par une table supplémentaire (parfois appelée table de jonction) dont la clé primaire est composée de deux clés étrangères qui référencent les deux tables en association
    C'est on va dire ce que vous avez fait en partie mais vous avez rajoutez des contraintes :

    CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_PK PRIMARY KEY (ArmoireId, RattachemenDate),
    CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_AK UNIQUE (RotationId, RattachemenDate),

    que moi je n'aurai pas rajouté.
    Peut on se passer des ces deux contraintes ou pas ou autrement est ce raisonnable de créer une base faite comme j'aurais procédé ou pas ?


    Rotation(idRotation,NomRotation....);
    Armoire(CodeArmoire,Nom.....,#IdRotation);
    Rajout ou Jonction3(#idRotation,#CodeArmoire,Date);

    -- Table ROTATION
    -- -----------------------------------------------------
    CREATE TABLE ROTATION
    (
    RotationId INT NOT NULL,
    RotationNom VARCHAR(64) NOT NULL,
    CONSTRAINT ROTATION_PK PRIMARY KEY (RotationId)
    ) ;
    -- -----------------------------------------------------
    -- Table ARMOIRE
    -- -----------------------------------------------------
    CREATE TABLE ARMOIRE
    (
    ArmoireId INT NOT NULL,
    ArmoireCode CHAR(4) NOT NULL,
    ArmoireNom VARCHAR(64) NOT NULL,
    RotationId INT NOT NULL,
    CONSTRAINT ARMOIRE_PK PRIMARY KEY (ArmoireId),
    CONSTRAINT ARMOIRE_AK UNIQUE (ArmoireCode),
    CONSTRAINT ARMOIRE_ROTATION_FK FOREIGN KEY (RotationId) REFERENCES ROTATION (RotationId)
    ) ;
    -- -----------------------------------------------------
    -- Table RATTACHEMENT_EXCEPTIONNEL
    -- -----------------------------------------------------
    CREATE TABLE RATTACHEMENT_EXCEPTIONNEL
    (
    ArmoireId INT NOT NULL,
    RattachemenDate DATE NOT NULL,
    RotationId INT NOT NULL,
    CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_PK PRIMARY KEY (ArmoireId, RattachemenDate),
    CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_AK UNIQUE (RotationId, RattachemenDate),
    CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_ARMOIRE_FK FOREIGN KEY (ArmoireId) REFERENCES ARMOIRE (ArmoireId),
    CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_ROTATION_FK FOREIGN KEY (RotationId) REFERENCES ROTATION (RotationId)
    ) ;




    Citation Envoyé par fsmrel
    Pour la simple et bonne raison que la contrainte d’unicité existe déjà, en effet {ArmoireId, RattachementDate} est clé primaire de la table.
    Ok Merci
    MErci pour votre aide, si vous pouviez donc revenir sur ma demande au niveau du MCD / MLD au niveau des rajouts exeptionnels me dire surtout ce que vous pensez de mon analyse à ce niveau et de la traduction en MLD
    Bonne soirée à vous
    A+

  7. #27
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 002
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir xeron,


    Citation Envoyé par xeron33 Voir le message
    J'ai revu mon MCD le voici modifié (sur la partie rajout exceptionnel d'armoires) :

    Rotation (0,n) (rajoute, date) (0,n) Armoire
    Comme vous venez de le faire, vous présentez parfois des éléments de représentation conceptuelle, mais je n’ai pas encore vu de MCD de votre part : un MCD est quand même la représentation graphique de l’ensemble des données que vous modélisez, dans le cadre de la méthode Merise, comme le fait par exemple Nickook avec sa cave à vins, pour prendre un exemple récent. Cette cave à vins est un univers du discours, tout comme la gestion des armoires en est un autre.

    Un MCD est composé de rectangles symbolisant les entités-types et d’ovales symbolisant les associations (ou relations) de pattes d’associations, etc.

    Les diagrammes MySQL Workbench ou ACCESS que j’ai fourni de mon côté relèvent plutôt du MLD.



    Citation Envoyé par xeron33 Voir le message
    Et là où moi je pêche c'est au niveau de la traduction en MLD car je pensais que deux entités reliés par une association dont les deux cardinalités maximales sont de type n se traduisait par une table supplémentaire (parfois appelée table de jonction) dont la clé primaire est composée de deux clés étrangères qui référencent les deux tables en association.
    Supposons que la règle de gestion, censée avoir donné lieu à l’association permettant de représenter conceptuellement des rattachements exceptionnels, soit la suivante :

    (RGx) A une date donnée, à une rotation peuvent exceptionnellement être rattachées des armoires appartenant normalement à d’autres rotations.

    Je suppose que si vous aviez utilisé une représentation graphique, elle aurait été celle-ci :




    Et lors du passage du MCD au MLD, du fait des cardinalités maximales N, la transformation donnerait lieu au diagramme (MySQL Workbench) :




    Mais tout cela n’est pas très satisfaisant.

    Tout d’abord, la clé (primaire) de la table RATTACHEMENT_EXCEPTIONNEL est la paire {RotationId, ArmoireId} c'est-à-dire que, pour une rotation (disons r1) et une armoire (disons a21) données, on n’a droit qu’à une seule date de rattachement exceptionnel : souvenez-vous qu’une clé primaire est d’abord une contrainte d’unicité. Supposons par exemple que le 4 mai 2015, l’armoire a21 a été rattachée à la rotation r1. Si le 15 mai 2015 on veut à nouveau rattacher exceptionnellement a21 à r1, il faudra remplacer à cette occasion la valeur '2015-05-04' (attribut RattachementDate) par la valeur '2015-05-15' : si par la suite on veut savoir s’il s’est passé quelque chose le 4 mai pour l’armoire a21 en relation avec la rotation r1, la réponse sera négative et ça n'est pas satisfaisant.

    En outre, je rappelle ce que j’avais écrit :

    Citation Envoyé par fsmrel Voir le message
    Normalement, les clés de la table RATTACHEMENT_EXCEPTIONNEL sont les suivantes :

    K1 = {ArmoireId, RattachementDate}

    K2 = {RotationId, RattachementDate}

    Elles découlent des contraintes suivantes :

    A une date donnée, une armoire peut être exceptionnellement rattachée à une et une seule rotation qui n’est pas sa rotation normale.

    A une date donnée, à une rotation donnée peut être exceptionnellement rattachée une et une seule armoire qui normalement ne lui appartient pas.


    Du fait du changement que vous avez opéré, en remplaçant la représentation

    Citation Envoyé par xeron33 Voir le message
    type_Rotation (0,1) (Rajoute) (0,n) type_Armoire

    Par celle-ci :

    Citation Envoyé par xeron33 Voir le message
    Rotation (0,n) (rajoute, date) (0,n) Armoire

    Alors, si vous voulez signifier qu’à la date d1 on peut rattacher exceptionnellement plus d’une armoire à la rotation r1, la contrainte K2 saute, soit.

    Mais on ne peut pas faire l’économie de la contrainte K1, car si elle disparaît, alors le même jour on pourra rattacher une armoire donnée à plusieurs rotations.

    Si vous convenez qu’à une date donnée une armoire ne peut être exceptionnellement rattachée qu’à une seule rotation, et si par ailleurs vous voulez conserver la trace des affectations exceptionnelles, alors la partie concernée du MCD devient la suivante, où la flèche rouge symbolise ce qu’on appelle une CIF (contrainte d’intégrité fonctionnelle), qui se lit « A une date donnée, une armoire est rattachable de façon exceptionnelle à une rotation et une seule » :




    Lors du passage au MLD, on demande à l’AGL (sous réserve qu’il sache ce qu’est une CIF...) de produire ceci (il n’y a pas de table DATE, car elle n’est d’aucune utilité) :




    Équivalent MySQL Workbench :




    Script SQL correspondant, où la contrainte K1 fait l’objet de la clé primaire de la table RATTACHEMENT_EXCEPTIONNEL :

    
    -- -----------------------------------------------------
    -- Table ROTATION
    -- -----------------------------------------------------
    CREATE TABLE ROTATION 
    (
            RotationId                 INT                   NOT NULL,
            RotationNom                VARCHAR(64)           NOT NULL,
          CONSTRAINT ROTATION_PK PRIMARY KEY (RotationId)
     ) ;
    
    -- -----------------------------------------------------
    -- Table ARMOIRE
    -- -----------------------------------------------------
    CREATE TABLE ARMOIRE 
    (
            ArmoireId                  INT                   NOT NULL,
            ArmoireCode                CHAR(4)               NOT NULL,
            ArmoireNom                 VARCHAR(64)           NOT NULL,
            RotationId                 INT                   NOT NULL,
          CONSTRAINT ARMOIRE_PK PRIMARY KEY (ArmoireId),
          CONSTRAINT ARMOIRE_AK UNIQUE (ArmoireCode),	  
          CONSTRAINT ARMOIRE_ROTATION_FK FOREIGN KEY (RotationId) REFERENCES ROTATION (RotationId)
    ) ;
    
    -- -----------------------------------------------------
    -- Table RATTACHEMENT_EXCEPTIONNEL
    -- -----------------------------------------------------
    CREATE TABLE RATTACHEMENT_EXCEPTIONNEL 
    (
            ArmoireId                  INT                   NOT NULL,
            RattachemenDate            DATE                  NOT NULL,
            RotationId                 INT                   NOT NULL,
          CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_PK PRIMARY KEY (ArmoireId, RattachemenDate),
          CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_ARMOIRE_FK FOREIGN KEY (ArmoireId) REFERENCES ARMOIRE (ArmoireId),
          CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_ROTATION_FK FOREIGN KEY (RotationId) REFERENCES ROTATION (RotationId)
    )  ;
    
    
    (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.

  8. #28
    Membre actif
    Profil pro
    Inscrit en
    Février 2007
    Messages
    758
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2007
    Messages : 758
    Points : 208
    Points
    208
    Par défaut
    Citation Envoyé par fsmrel
    Supposons que la règle de gestion, censée avoir donné lieu à l’association permettant de représenter conceptuellement des rattachements exceptionnels, soit la suivante :

    (RGx) A une date donnée, à une rotation peuvent être exceptionnellement rattachées des armoires qui, dans le cas normal, sont rattachées à une autre rotation.

    Je suppose que si vous aviez utilisé une représentation graphique, elle aurait été celle-ci :




    Et lors du passage du MCD au MLD, du fait des cardinalités maximales N, la transformation donnerait lieu au diagramme (MySQL Workbench) :




    Mais tout cela n’est pas très satisfaisant.

    Tout d’abord, la clé (primaire) de la table RATTACHEMENT_EXCEPTIONNEL est la paire {RotationId, ArmoireId} c'est-à-dire que, pour une rotation (disons r1) et une armoire (disons a21) données, on n’a droit qu’à une seule date de rattachement exceptionnel : souvenez-vous qu’une clé primaire est d’abord une contrainte d’unicité. Supposons par exemple que le 4 mai 2015, l’armoire a21 a été rattachée à la rotation r1. Si le 15 mai 2015 on veut à nouveau rattacher exceptionnellement a21 à r1, il faudra remplacer à cette occasion la valeur '2015-05-04' (attribut RattachementDate) par la valeur '2015-05-15' : si par la suite on veut savoir s’il s’est passé quelque chose le 4 mai pour l’armoire a21 en relation avec la rotation r1, la réponse sera négative et ça n'est pas satisfaisant.

    En outre, je rappelle ce que j’avais écrit :



    Du fait du changement que vous avez opéré, en remplaçant la représentation


    Par celle-ci :


    Alors, si vous voulez signifier qu’à la date d1 on peut rattacher exceptionnellement plus d’une armoire à la rotation r1, la contrainte K2 saute, soit.

    Mais on ne peut pas faire l’économie de la contrainte K1, car si elle disparaît, alors le même jour on pourra rattacher une armoire donnée à plusieurs rotations.
    OK
    Citation Envoyé par fsmrel
    Si vous convenez qu’à une date donnée une armoire ne peut être exceptionnellement rattachée qu’à une seule rotation, et si par ailleurs vous voulez conserver la trace des affectations exceptionnelles, alors la partie concernée du MCD devient la suivante, où la flèche rouge symbolise ce qu’on appelle une CIF (contrainte d’intégrité fonctionnelle), qui se lit « A une date donnée, une armoire est rattachée de façon exceptionnelle à une seule rotation » :


    Par contre là " A une date donnée, une armoire est rattachée de façon exceptionnelle à une seule rotation » je verrai plutôt :
    "A une date donnée, une armoire ou plusieurs (0,n) est rattachée de façon exceptionnelle à une seule rotation » :
    D'autre part que veut dire <pi> et <ai> ? MErci

    Citation Envoyé par fsmrel
    Lors du passage au MLD, on demande à l’AGL (sous réserve qu’il sache ce qu’est une CIF...) de produire ceci (il n’y a pas de table DATE, car elle n’est d’aucune utilité) :
    Vous me l'avez déjà expliqué mais j'ai pas tout à fait compris comment décidez vous de ne pas créer de table Date, dans quel cas ? Merci
    Citation Envoyé par fsmrel


    Que veut dire <ak> ? clé alternative ? MErci

    Citation Envoyé par fsmrel
    Équivalent MySQL Workbench :




    Script SQL correspondant, où la contrainte K1 fait l’objet de la clé primaire de la table RATTACHEMENT_EXCEPTIONNEL :

    [pre]

    -- -----------------------------------------------------
    -- Table ROTATION
    -- -----------------------------------------------------
    CREATE TABLE ROTATION
    (
    RotationId INT NOT NULL,
    RotationNom VARCHAR(64) NOT NULL,
    CONSTRAINT ROTATION_PK PRIMARY KEY (RotationId)
    ) ;

    -- -----------------------------------------------------
    -- Table ARMOIRE
    -- -----------------------------------------------------
    CREATE TABLE ARMOIRE
    (
    ArmoireId INT NOT NULL,
    ArmoireCode CHAR(4) NOT NULL,
    ArmoireNom VARCHAR(64) NOT NULL,
    RotationId INT NOT NULL,
    CONSTRAINT ARMOIRE_PK PRIMARY KEY (ArmoireId),
    CONSTRAINT ARMOIRE_AK UNIQUE (ArmoireCode),
    CONSTRAINT ARMOIRE_ROTATION_FK FOREIGN KEY (RotationId) REFERENCES ROTATION (RotationId)
    ) ;

    -- -----------------------------------------------------
    -- Table RATTACHEMENT_EXCEPTIONNEL
    -- -----------------------------------------------------
    CREATE TABLE RATTACHEMENT_EXCEPTIONNEL
    (
    ArmoireId INT NOT NULL,
    RattachemenDate DATE NOT NULL,
    RotationId INT NOT NULL,
    CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_PK PRIMARY KEY (ArmoireId, RattachemenDate),
    CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_ARMOIRE_FK FOREIGN KEY (ArmoireId) REFERENCES ARMOIRE (ArmoireId),
    CONSTRAINT RATTACHEMENT_EXCEPTIONNEL_ROTATION_FK FOREIGN KEY (RotationId) REFERENCES ROTATION (RotationId)
    );
    OK
    Grâce à vos infos j'avance bien, merci de répondre aux divers points que je vous ai notifié.
    Merci encore vraiment super ce que vous faites !
    A+

  9. #29
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 002
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir xeron,



    Citation Envoyé par xeron33 Voir le message
    Citation Envoyé par fsmrel Voir le message
    Si vous convenez qu’à une date donnée une armoire ne peut être exceptionnellement rattachée qu’à une seule rotation, et si par ailleurs vous voulez conserver la trace des affectations exceptionnelles, alors la partie concernée du MCD devient la suivante, où la flèche rouge symbolise ce qu’on appelle une CIF (contrainte d’intégrité fonctionnelle), qui se lit « A une date donnée, une armoire est rattachée à une seule rotation » :


    Par contre là " A une date donnée, une armoire est rattachée de façon exceptionnelle à une seule rotation » je verrai plutôt :
    "A une date donnée, une armoire ou plusieurs (0,n) est rattachée de façon exceptionnelle à une seule rotation »
    Ce que j’ai énoncé concerne une contrainte, exprimable en Merise sous la forme d’une CIF, et son objet (en l’occurrence nécessaire et suffisant) est seulement d’expliquer le rôle de la flèche rouge dans le cadre du formalisme Merise (il y a du reste d’autres représentations possibles, voyez dans la FAQ Merise, l’exemple des candidats qui passent des examens).

    Quant aux règles de gestion des données, elles doivent bien sûr avoir été formulées en amont. Par exemple, pour reprendre la règle RGx :

    A une date donnée, à une rotation peuvent exceptionnellement être rattachées des armoires appartenant normalement à d’autres rotations.



    Citation Envoyé par xeron33 Voir le message
    D'autre part que veut dire <pi> et <ai> ?
    « pi » est l’abréviation de « primary identifier » et « ai » celle de « alternate identifier ». Le concept d’identifiant est propre à Merise. Dans son article considéré comme fondateur de l’approche Entité-Relation, Peter Chen a utilisé pour sa part le concept de clé primaire (primary key), qu’il avait repiqué chez Ted Codd. J’ai utilisé PowerAMC pour la représentation graphique que j’ai proposée (à la flèche rouge près, que j’ai ajoutée à l’aide de Paint, car PowerAMC ne sait pas ce qu’est une CIF). Pour mémoire, cet AGL a été créé à la fin des années quatre-vingts, sous le nom d’AMC*Designor, par la société française SDP, basée à Suresnes. AMC*Designor était bien sûr orienté Merise d’où l’utilisation du terme « identifiant » plutôt que celui de « clé ». Quand PowerSoft racheta l’AGL, celui-ci conserva son nom et son orientation Merise, d’où la préservation du terme « identifiant », qui perdure encore aujourd’hui, malgré les aléas des rachats suivants par Sybase, SAP et du changement du nom de l’AGL...



    Citation Envoyé par xeron33 Voir le message
    Que veut dire <ak> ? clé alternative ?
    Oui. « ak » est l’abréviation de « alternate key », par opposition à « pk » (primary key »). Je rappelle que les qualificatifs primary et alternate sont en fait inutiles et ont disparu de la théorie relationnelle, qui n’utilise plus que le terme « key » (voire « candidate key », in memoriam). La primauté des clés primaires est d’ordre purement psychologique, disons qu’elles sont « plus égales que les autres »...



    Citation Envoyé par xeron33 Voir le message
    Vous me l'avez déjà expliqué mais j'ai pas tout à fait compris comment décidez vous de ne pas créer de table Date, dans quel cas ?
    Revenons sur la contrainte :

    (Cx) A une date donnée, une armoire est rattachable de façon exceptionnelle à une rotation et une seule.

    Il faut se souvenir qu’en Merise pur, au niveau MCD, si les pattes d’une association sont toutes porteuses d’une cardinalité maximale N, alors l’identifiant de cette association est conceptuellement composé de l’ensemble des identifiants des entités-types qui sont connectées. Étant donné que la date participe à l’identification de l’association RATTACHEMENT_EXCEPTIONNEL, pour y parvenir on est donc contraint et forcé de mettre en œuvre une entité-type DATE dont par ailleurs on n’a aucune utilité. Je me suis plié à la règle, j’ai mis en œuvre une entité-type DATE pour un motif technique, purement merisien. Mais cette fois-ci, l’association RATTACHEMENT_EXCEPTIONNEL a une patte supplémentaire, elle était binaire quand on branchait seulement les entités-types ROTATION et ARMOIRE, et la voilà devenue ternaire. Par conséquent, son identifiant est désormais composé des identifiants des 3 entités-types ROTATION, ARMOIRE et DATE, mais il y a un hic, car à cause de la contrainte Cx, l’identifiant de ROTATION ne doit pas participer à l’identification de RATTACHEMENT_EXCEPTIONNEL... Situation kafkaïenne classique, qui a conduit les pères de Merise à inventer le concept de CIF, dès les débuts officiels de Merise, en 1978, et la flèche rouge vient de là, signifiant la réduction de l’identifiant de l’association à la paire qui va bien, suite à l’exclusion de celui de ROTATION.


    Depuis le passage de Merise en Merise/2 (fin des années quatre-vingts), on peut procéder autrement, au moyen de l’identification relative, en transformant RATTACHEMENT_EXCEPTIONNEL en entité-type, que l’on identifie relativement à ARMOIRE, ce qui, dans le cas de PowerAMC, est symbolisé par la mise entre parenthèses de la cardinalité 1,1 côté ARMOIRE :




    Lors de la dérivation du MCD en MLD, la clé de la table RATTACHEMENT_EXCEPTIONNEL sera bien la paire {ArmoireId, RattachementDate}.

    Cette fois-ci, la date a retrouvé son rôle naturel d’attribut, adieu l’entité-type DATE (et la table qui en dérivée), boulet pesant et inutile. Quand vous aurez comme moi débarrassé (à la nausée !) telle et telle bases de données de centaines de clés étrangères automatiquement générées par l’AGL (sans oublier les index !), vous comprendrez encore mieux. En plus, ces clés étrangères font que, lorsqu’elle existe, la table DATE doit finalement comporter une ligne par jour, par année, quand à l’opposé, au vu du diagramme ci-dessus, il suffit de déclarer l’attribut Rattachement Date comme étant du type Date, le SGBD se chargeant du contrôle de type et du reste.



    Avec DB-MAIN de Jean-Luc Hainaut (professeur à l’Université de Namur), on résout d’une autre manière l’éviction de ROTATION dans la participation à l’identifiant de RATTACHEMENT_EXCEPTIONNEL, en effet on peut y fournir directement la liste des participants, à savoir ARMOIRE et DATE :



    C’est quand même plus simple et plus souple qu'avec la version merisienne pur jus (et en prime, DB-MAIN est gratuit)...
    (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.

  10. #30
    Membre actif
    Profil pro
    Inscrit en
    Février 2007
    Messages
    758
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2007
    Messages : 758
    Points : 208
    Points
    208
    Par défaut
    Citation Envoyé par fsmrel
    Ce que j’ai énoncé concerne une contrainte, exprimable en Merise sous la forme d’une CIF, et son objet (en l’occurrence nécessaire et suffisant) est seulement d’expliquer le rôle de la flèche rouge dans le cadre du formalisme Merise (il y a du reste d’autres représentations possibles, voyez dans la FAQ Merise, l’exemple des candidats qui passent des examens).

    Quant aux règles de gestion des données, elles doivent bien sûr avoir été formulées en amont. Par exemple, pour reprendre la règle RGx :

    A une date donnée, à une rotation peuvent exceptionnellement être rattachées des armoires appartenant normalement à d’autres rotations.
    D'accord donc si j'ai bien compris :
    - d'abord les règles de gestion(cardinalités)
    - puis lister les contraintes
    - et si l'on a une contrainte unique la déclarer en CIF (flèche rouge pointant vers l'entité cible ici donc Rotation), il est vrai que la contrainte est liée à une seule Rotation.
    Pouvez vous me dire si j'ai tout bien compris ?
    Citation Envoyé par fsmrel
    Étant donné que la date participe à l’identification de l’association RATTACHEMENT_EXCEPTIONNEL, pour y parvenir on est donc contraint et forcé de mettre en œuvre une entité-type DATE
    Pourquoi ?C'est des contraintes dues à Merise ? On ne pouvait pas faire autrement ?
    Citation Envoyé par fsmrel
    mais il y a un hic, car à cause de la contrainte Cx, l’identifiant de ROTATION ne doit pas participer à l’identification de RATTACHEMENT_EXCEPTIONNEL...
    Si j'ai bien compris à cause de la contrainte unique sur la Rotation ?


    Citation Envoyé par fsmrel

    Que signifie RER et REA ?

    MErci à vous de m'éclairer sur ces divers points
    A+

  11. #31
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 002
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir xeron,


    Citation Envoyé par xeron33 Voir le message
    D'accord donc si j'ai bien compris :
    - d'abord les règles de gestion(cardinalités)
    - puis lister les contraintes
    Disons que les règles de gestion des données décrivent et expliquent le QUOI, par exemple ce qu’est une rotation, une armoire, un opérateur, etc., comme le fait votre dictionnaire, Larousse ou Petit Robert. Si de mon côté je vous demande votre avis sur cette représentation :

    [ PERSONNE ]---0,N---------( R ) --------0,N----[ TITRE ]

    Inévitablement, vous poserez la question : Mais qu’est-ce qu’un titre ? Est-ce un titre de bouquin ? d’émission à la télé ? Ne serait-ce pas plutôt un titre boursier, financier ? Un titre de civilité ? De noblesse ? Une mesure de dosage chimique ? Un titre de transport ? La description d’une donnée doit permettre aux interlocuteurs de bien comprendre ce dont on parle, il ne doit subsister aucune ambiguïté...

    Les relations entre les objets méritent évidemment d’être décrites et expliquées soigneusement, d’où l’importance des cardinalités que vous évoquez, mais bien sûr, celles-ci ne constituent pas à elles seules les règles de gestion des données. En tout cas, ces cardinalités permettent déjà de mettre en évidence certaines contraintes. Ainsi, la représentation ci-dessous comporte de facto la contrainte d’unicité selon laquelle une armoire ne peut appartenir qu’à une seule rotation :

    [ ROTATION ]----1,N--------(Comporter)--------1,1----[ ARMOIRE ]

    En ce qui concerne les contraintes, plutôt que de les décrire à part, intégrons-les aux règles de gestion proprement dites, car on reste dans le QUOI et il est préférable de regrouper ce qui concerne les relations entre objets.

    Ainsi, regroupons dans un paquet les relations normales entre les rotations et les armoires avec les relations exceptionnelles, avec les contraintes qu’on a vues (faisant l’objet de CIF dans le MCD), y-compris ce qui est sous-entendu pour un humain, mais ne l’est pas pour une machine (règle RGz), et comme dit JPhi33, « ça va mieux en le disant » :

    (RGx) Une rotation est composée d’au moins une armoire et une armoire appartient à au moins et au plus une rotation ;

    (RGy) A titre exceptionnel, une rotation peut être complétée un jour donné par des armoires d’autres rotations et une telle armoire être affectée exceptionnellement ce jour-là à cette rotation, et elle seule ;

    (RGz) La rotation à laquelle une armoire peut être rattachée exceptionnellement ne peut pas être en même temps sa rotation normale.

    La langue française a beau être réputée pour sa précision, il n’en demeure pas moins que la narration faite au travers de ces trois règles peut encore susciter des interrogations pour celui qui les lit et ne connaît pas le sujet, d’où l’importance non seulement de produire un MCD sous forme graphique, au moyen d’un AGL comme PowerAMC, DB-MAIN, Open ModelSphere, etc., mais aussi d’illustrer par des exemples.

    Quand je parle de susciter des interrogations, je veux dire que je peux être encore sur ma faim : par exemple, le jour <j1>, la rotation <r1> peut exceptionnellement être affectée d’armoires qui ne lui appartiennent pas, mais ces armoires doivent-elles faire partie d’une seule rotation, disons <r2>, ou bien ces armoires peuvent elles appartenir à différentes rotations ? Rédiger des règles de gestion claires, précises, exhaustives et non contradictoires est un exercice très difficile (dans le même sens, bien des articles de la Loi en France sont fumeux, incomplets et contradictoires, tant mieux pour ces hommes de l’art que sont les avocats...)

    N.B. La règle RGz fait partie des règles, ou plutôt des contraintes dites d’exclusion et, avec les SGBD SQL habituels, doit faire l’objet d’un trigger.



    Citation Envoyé par xeron33 Voir le message
    et si l'on a une contrainte unique la déclarer en CIF (flèche rouge pointant vers l'entité cible ici donc Rotation), il est vrai que la contrainte est liée à une seule Rotation.
    Pouvez vous me dire si j'ai tout bien compris ?
    Une CIF fait l’objet d’une représentation graphique particulière. Cela dit, vu ce que j’ai écrit ci-dessus, on en fait une règle de gestion, par exemple (n’oubliez pas de prendre en compte la date !) :

    (RGc) A une date donnée, une armoire peut être rattachée exceptionnellement à au plus une rotation (sous-entendu qui n’est pas la sienne).

    Cette règle est une partie de la règle RGy qui l’absorbe donc pour éviter la redondance.



    Citation Envoyé par xeron33 Voir le message
    Pourquoi ?C'est des contraintes dues à Merise ? On ne pouvait pas faire autrement ?
    Je vous l’ai expliqué, il s’agit effectivement du moyen en Merise de mettre en évidence la CIF : selon laquelle pour une paire {Armoire, Date}, il y a une seule rotation.


    J’ai aussi écrit qu’on pouvait procéder autrement :

    Depuis le passage de Merise en Merise/2 (fin des années quatre-vingts), on peut procéder autrement, au moyen de l’identification relative, en transformant RATTACHEMENT_EXCEPTIONNEL en entité-type, que l’on identifie relativement à ARMOIRE, ce qui, dans le cas de PowerAMC, est symbolisé par la mise entre parenthèses de la cardinalité 1,1 côté ARMOIRE :



    Que signifie RER et REA ?
    Il s’agit seulement de noms abrégés :

    RER est l’abréviation de la concaténation des termes Rattachement Exceptionnel et Rotation ;

    REA est l’abréviation de la concaténation des termes Rattachement Exceptionnel et Armoire.

    Si vous préférez les remplacer par des verbes, pas de problème (faites seulement ! comme on dit à Genève )
    (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.

  12. #32
    Membre actif
    Profil pro
    Inscrit en
    Février 2007
    Messages
    758
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2007
    Messages : 758
    Points : 208
    Points
    208
    Par défaut Fin du sujet et remerciements
    Merci beaucoup pour votre travail d'explication, je vais mettre tout ça en œuvre sur Access, on aura peut l'occasion de se "recroiser".
    A+

  13. #33
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 002
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    D'accord xeron,

    Si problème il y a un jour, pas de problème, vous connaissez la maison
    (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.

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 2 PremièrePremière 12

Discussions similaires

  1. [MySQL] Tri sur champ au format date - uniquement mois/année
    Par skippy86 dans le forum PHP & Base de données
    Réponses: 5
    Dernier message: 04/01/2007, 11h27
  2. Sélection sur DATE unique
    Par nerick dans le forum Langage SQL
    Réponses: 3
    Dernier message: 03/01/2006, 15h28
  3. mettre une entité date ou pas??
    Par faayy dans le forum Décisions SGBD
    Réponses: 2
    Dernier message: 12/04/2005, 09h00
  4. mettre une entité date ou pas et surtout comment!!!
    Par faayy dans le forum Langage SQL
    Réponses: 12
    Dernier message: 12/04/2005, 08h54
  5. [MCD]Faut-il une Entité Date ?
    Par Francis dans le forum Schéma
    Réponses: 2
    Dernier message: 17/01/2005, 18h48

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo