Discussion :

[xeron33]

Bonsoir à tous,
J'ai un petit problème d'analyse sur une petite base dont voiçi un extrait :
Operateur(id_Operateur,Nom,Prenom);
Rotation(id_Rotation,Nom_Rotation);
Jonction2(#id_Operateur,#id_Rotation,Date);
Armoire(Code_Armoire,Localisation,Lettre_jour,#id_Rotation(non vide));
Receptions_Retours(#Code_Armoire,Nbre_Dossiers_reçus,Nbre_Dossiers_renvoyes,Date);

Le problème est que la date de la table Jonction2 est la même (date du jour) que la date de la table Receptions_Retours comment éviter une telle redondance ? En utilisant une seule entité Date ? Comment la positionner ?
Si quelqu'un a une réponse merci de me répondre
A +

[jourzebest]

Bonjour,

L'id de ta table Receptions_Retours c'est quoi ?

Si la redondance des dates te gènes tu peux les sortir dans une table date.

[fsmrel]

Bonjour,

J'ai un petit problème d'analyse

Avant que l’on essaie de traiter de votre problème, il est nécessaire qu’on dispose de l’ensemble des règles de gestion des données.

En effet, si l’on essaie d’interpréter votre représentation (qui ne précise même pas les clés des tables), on est incapable d’inférer ces règles.

Par exemple, vous fournissez le schéma de table suivant :

Jonction2 (#id_Operateur, #id_Rotation, Date)

Parmi les interprétations possibles, on a celles-ci :

(RG1) L’opérateur o1 peut effectuer la rotation r1, à différentes dates, d1,d2, ... ;

(RG2) L’opérateur o1 peut effectuer la rotation r1, mais à une seule date (disons d1) ;

(RG3) A la date d1, l’opérateur o1 peut n’effectuer qu’une rotation (disons r1) ;

(RG4) A la date d1, la rotation r1 ne peut être effectuée que par un seul opérateur (disons o1) ;

Etc.

Même chose concernant les autres schémas : veuillez préciser les règles qui s’appliquent.

Le problème est que la date de la table Jonction2 est la même (date du jour) que la date de la table Receptions_Retours.

Vous mettez en évidence une contrainte, mais fort ambiguë elle aussi dan son interprétation...

Informellement, voulez-vous signifier qu’un mouvement m1 (synonyme de réception/retour) :

(1) Concerne une seule armoire a1, à lieu à une date donnée d1 ;

(2) Que ceci a pour conséquence qu’à cette date d1, un opérateur o1 devra effectuer une rotation r1 (mais quel est le but de la manoeuvre ? Sa cause ?)

Bref, du point de vue sémantique, tout cela est bien confus.

[xeron33]

Bonjour,

L'id de ta table Receptions_Retours c'est quoi ?

Si la redondance des dates te gènes tu peux les sortir dans une table date.

Merci pour ton aide, l'ID de la table Reception est #Code_Armoire clé étrangère vers la table Armoire, ok pour la mettre dans une table date mais comment l'implenter ?

[xeron33]

Bonjour,



Avant que l’on essaie de traiter de votre problème, il est nécessaire qu’on dispose de l’ensemble des règles de gestion des données.

En effet, si l’on essaie d’interpréter votre représentation (qui ne précise même pas les clés des tables), on est incapable d’inférer ces règles.

Par exemple, vous fournissez le schéma de table suivant :

Jonction2 (#id_Operateur, #id_Rotation, Date)

Parmi les interprétations possibles, on a celles-ci :

(RG1) L’opérateur o1 peut effectuer la rotation r1, à différentes dates, d1,d2, ... ;

(RG2) L’opérateur o1 peut effectuer la rotation r1, mais à une seule date (disons d1) ;

(RG3) A la date d1, l’opérateur o1 peut n’effectuer qu’une rotation (disons r1) ;

(RG4) A la date d1, la rotation r1 ne peut être effectuée que par un seul opérateur (disons o1) ;

Etc.

Même chose concernant les autres schémas : veuillez préciser les règles qui s’appliquent.





Vous mettez en évidence une contrainte, mais fort ambiguë elle aussi dan son interprétation...

Informellement, voulez-vous signifier qu’un mouvement m1 (synonyme de réception/retour) :

(1) Concerne une seule armoire a1, à lieu à une date donnée d1 ;

(2) Que ceci a pour conséquence qu’à cette date d1, un opérateur o1 devra effectuer une rotation r1 (mais quel est le but de la manoeuvre ? Sa cause ?)

Bref, du point de vue sémantique, tout cela est bien confus.

"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Bonjour et merci pour votre réponse je vais vous fournir le MCD que j'ai élaboré pour ces tables, par contre si si, je vous avais fourni les clés des tables :
(en gras et italique maintenant plus clair) .
Operateur(id_Operateur,Nom,Prenom);
Rotation(id_Rotation,Nom_Rotation);
Jonction2(#id_Operateur,#id_Rotation,Date);
Armoire(Code_Armoire,Localisation,Lettre_jour,#id_Rotation(non vide));
Receptions_Retours(#Code_Armoire,Nbre_Dossiers_reçus,Nbre_Dossiers_renvoyes,Date);

Donc voiçi le MCD :

Operateur (0,n) (Effectue) (0,n) Rotation
Rotation (1,n) (Possede) (1,1) Armoire (0,n) (contient) (1,1) Receptions_Retours

Dites moi si c'est plus clair
MErci encore

[fsmrel]

Bonsoir xeron,



Il y aune contradiction entre votre représentation conceptuelle et votre représentation relationnelle.

En effet, selon votre représentation conceptuelle, une armoire peut contenir plusieurs réceptions-retours, alors que selon votre représentation relationnelle, une armoire ne peut en contenir qu’une seule : en effet, {#Code_Armoire} étant clé de la table Receptions_Retours, on ne peut pas trouver dans cette table plus d’une fois la même valeur pour la colonne #Code_Armoire.

A supposer que la version conceptuelle soit la bonne, la version relationnelle doit être aménagée, en sorte qu’une armoire puisse contenir plusieurs réceptions-retours.


Question 1 : Pour quelle raison la date figurant dans jonction2 doit être égale à la date figurant dans réceptions-retours ? Est-ce parce que les N réceptions-retours à une date donnée et pour une armoire donnée doivent faire l’objet d’une trace dans jonction2 ? Est-ce pour une autre raison ?

Question 2 : Qu’est-ce qu’une rotation ? Par référence à votre représentation conceptuelle, qu’entendez vous de façon précise par « une rotation possède N armoires » ?

[xeron33]

Bonsoir xeron,



Il y aune contradiction entre votre représentation conceptuelle et votre représentation relationnelle.

En effet, selon votre représentation conceptuelle, une armoire peut contenir plusieurs réceptions-retours, alors que selon votre représentation relationnelle, une armoire ne peut en contenir qu’une seule : en effet, {#Code_Armoire} étant clé de la table Receptions_Retours, on ne peut pas trouver dans cette table plus d’une fois la même valeur pour la colonne #Code_Armoire.

A supposer que la version conceptuelle soit la bonne, la version relationnelle doit être aménagée, en sorte qu’une armoire puisse contenir plusieurs réceptions-retours.


Question 1 : Pour quelle raison la date figurant dans jonction2 doit être égale à la date figurant dans réceptions-retours ? Est-ce parce que les N réceptions-retours à une date donnée et pour une armoire donnée doivent faire l’objet d’une trace dans jonction2 ? Est-ce pour une autre raison ?

Question 2 : Qu’est-ce qu’une rotation ? Par référence à votre représentation conceptuelle, qu’entendez vous de façon précise par « une rotation possède N armoires » ?

**********************************************************************************************************
Bonsoir et merci pour le suivi,
Pour répondre à votre question quant à la contradiction entre le MCD et le MLD je dois vous préciser que l'entité Receptions_Retours est formulé de la façon suivante :
Receptions_Retours(Nbre_Dossiers_Recus,Nbre_Dossiers_Renvoyes,Nbre_Integrations_Recues,Nbre_Intégrations_Renvoyees) sans clé et comme nous avons :
Armoire (0,n) (contient) (1,1) Receptions_Retours
et comme nous avons :
Armoire(Code_Armoire,Localisation,Lettre_jour,#id_Rotation(non vide));
c'est le coté (1,1) qui récupère #Code_Armoire comme clé étrangère non vide que j'avais oublié de préciser
Maintenant le fait de créer une entité sans clé est il correct ? dites moi
Pour vous expliquer le but de l'entité Receptions_Retours c'est simplement pouvoir rentrer chaque jour le nombre de dossiers reçus et le nombre de dossiers renvoyés par armoire, j'ai créé une cardinalité (1,1) coté Receptions_Retours car il y a tous les jours une "existence" et une seule réceptions_retours même si le nbre de dossiers recus ou renvoyés est égal à zéro.
Question 1 : Il y a une date dans jonction2 pour savoir à quelle date tel opérateur a effectué telle rotation, oui date identique dans réception_retours.
Est-ce parce que les N réceptions-retours à une date donnée et pour une armoire donnée doivent faire l’objet d’une trace dans jonction2 ? Est-ce pour une autre raison ?
Non les receptions_retours sont "contenues" dans l'Entité Armoire.
Question 2 : Qu’est-ce qu’une rotation ? Par référence à votre représentation conceptuelle, qu’entendez vous de façon précise par « une rotation possède N armoires » ? Une rotation est une charge de travail pour un opérateur, c à d qu'une rotation possède N Armoires à vider par l'opérateur et celui çi doit comptabiliser le nbre de dossiers reçus et renvoyés(non conformes).
MErci encore j'attends vos remarque
A +

[CinePhil]

Pour vous expliquer le but de l'entité Receptions_Retours c'est simplement pouvoir rentrer chaque jour le nombre de dossiers reçus et le nombre de dossiers renvoyés par armoire, j'ai créé une cardinalité (1,1) coté Receptions_Retours car il y a tous les jours une "existence" et une seule réceptions_retours même si le nbre de dossiers recus ou renvoyés est égal à zéro.

Donc la date doit participer à la clé de l'entité type Receptions_retours.

Au passage, nommez vos entités types et, par la suite, vos tables au singulier.

Pour répondre à votre question d'origine d'une manière générale, vous n'aurez besoin d'une entité-type date que si vous devez gérer un calendrier. Par exemple, si vous voulez savoir à quelles dates aucune intégration n'a eu lieu pour l'armoire 12, vous êtes bien obligé d'avoir toutes les dates possibles quelque part. Si par contre vous ne ferez aucune interrogation sur toutes les dates possibles, l'entité-type date est inutile. Les dates ne seront que des propriétés banales dans vos entités-types qui engendreront des colonnes de type DATE ou DATETIME dans vos tables.

[fsmrel]

Bonsoir,

Créer une entité sans clé est il correct ?

En aucune façon. Même l’ensemble vide Ø a une identité. Il est probable que seul le néant (concept terrifiant) n’est pas identifiable...

A la limite, si on n’a pas d’identifiant naturel pour une entité, du point de vue de la théorie relationnelle, la clé d’une relation (table SQL pour faire court) est implicitement définie par l’ensemble des noms des attributs de cette relation. En SQL on devra explicitement définir cette clé, car ce langage n’est pas conforme à la théorie relationnelle et si on définit rien, alors une table SQL est en réalité un sac, c'est-à-dire n’importe quoi (au néant près...)

le but de l'entité Receptions_Retours c'est simplement pouvoir rentrer chaque jour le nombre de dossiers reçus et le nombre de dossiers renvoyés par armoire, j'ai créé une cardinalité (1,1) coté Receptions_Retours car il y a tous les jours une "existence" et une seule réceptions_retours même si le nbre de dossiers reçus ou renvoyés est égal à zéro.

Si la règle est la suivante :

Si à la date <d1>, pour une armoire <a1> il n’y a qu’une réception/retour, alors comme dit CinePhil, la structure de RECEPTION_RETOUR est la suivante, où {Code_Armoire, DateJour} est clé primaire de la table et {Code_Armoire} clé étrangère :

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

Une rotation est une charge de travail pour un opérateur, c à d qu'une rotation possède N Armoires à vider par l'opérateur et celui-ci doit comptabiliser le nbre de dossiers reçus et renvoyés

J’ai du mal à interpréter ceci : « une rotation possède N armoires à vider ». En effet, je sais vider une armoire, mais de là à me prendre pour une rotation...

Merci de donner des exemples concrets.

Vider une armoire et effectuer une rotation sont-ils synonymes ? Sinon, à part vider une armoire, quels sont les types possibles de rotation ?

Pour le moment j’en suis à ce genre d’exemple : à la date <d1>, l’opérateur Raoul doit vider (concrètement, physiquement) les armoires <a1>, <a>, etc., c'est-à-dire les débarrasser de leur contenu, tout en comptabilisant ce qu’il y a observé : dossiers reçus et/ou renvoyés.

Pour que nous comprenions mieux, merci de fournir des exemples de charges de travail faisant intervenir Raoul et Fernand (et des rotations...)

Êtes-vous d’accord avec les scénarios suivants :

(SC1) Comptabiliser le nombre de dossiers reçus et renvoyés A la date <d1>, pour une armoire <a1> signifie que l’opérateur <p1> , disons Raoul, met à jour ces quantités (table concernée : RECEPTION_RETOUR, attributs Nbre_Dossiers_reçus, Nbre_Dossiers_renvoyes).

(SC2) A la date <d1>, pour une armoire <a1> il n’y a qu’une réception/retour <r1> et il n’y a qu’un seul opérateur <p1>, disons Raoul pour s’en charger (effectuer une rotation) : à la date <d1>, Fernand ne peut en aucune façon être concerné lui aussi par <r1>.


Est-ce que le même jour, Fernand et Raoul peuvent intervenir sur l’armoire <a1> ? Seulement l’un des deux ?

Si le traitement effectué par l’opérateur <p1> pour la réception/retour <r1> est d’un certain type, quels sont les types de traitement possibles ?

Concernant la table ARMOIRE, à quoi correspond l’attribut Lettre_jour, quelle est sa finalité ?


Au stade où j’en suis (provisoire !), du point de vue relationnel j’en suis à ceci, où je considère que seul un opérateur intervient sur un événement (réception/retour du jour) :

OPERATEUR {id_Operateur, Nom, Prenom}
    PRIMARY KEY { id_Operateur} ;

ARMOIRE {Code_Armoire, Localisation, Lettre_jour}
    PRIMARY KEY {Code_Armoire} ;

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

Pour le moment, la table ROTATION est absente, sa pertinence et sa place dans le modèle ne sont pas clairement démontrées.

[xeron33]

Donc la date doit participer à la clé de l'entité type Receptions_retours.

Au passage, nommez vos entités types et, par la suite, vos tables au singulier.

Pour répondre à votre question d'origine d'une manière générale, vous n'aurez besoin d'une entité-type date que si vous devez gérer un calendrier. Par exemple, si vous voulez savoir à quelles dates aucune intégration n'a eu lieu pour l'armoire 12, vous êtes bien obligé d'avoir toutes les dates possibles quelque part. Si par contre vous ne ferez aucune interrogation sur toutes les dates possibles, l'entité-type date est inutile. Les dates ne seront que des propriétés banales dans vos entités-types qui engendreront des colonnes de type DATE ou DATETIME dans vos tables.

**************************************************************************************************
Merci pour votre aide,
Je vais préciser ma demande.
En fait ma question est de savoir comment éviter une redondance avec le champ date qui se trouve dans la table Jonction2 et la table Receptions_Retours ?Même date puisque date du jour. A savoir que oui j'aurai besoin de savoir le nombre de réintégrations reçues pour l'armoire 12 à telle date.
Comment implémenter dans mon cas une entité date (date du jour) ?
MErci de me tenir au courant
A +

[fsmrel]

Bonsoir,

j'aurai besoin de savoir le nombre de réintégrations reçues pour l'armoire 12 à telle date.

A partir du script de tables que j’ai fourni :

    SELECT Nbre_Dossiers_reçus, Nbre_Dossiers_renvoyes
    FROM   RECEPTION_RETOUR
    WHERE  Code_Armoire = 12 AND DateJour = '2015_05_05' ;
 

En fait ma question est de savoir comment éviter une redondance avec le champ date qui se trouve dans la table Jonction2 et la table Receptions_Retours ?

J’avais bien compris votre question, mais ma réponse est la suivante : qu’est-ce qui prouve que l’existence de la table jonction2 a effectivement un sens ? Si oui, qu’est-ce qui prouve que cette table doive être dotée d’un attribut de type date ? Pour le moment, comme je l’ai dit, en l’absence de réponse aux questions que j’ai posées dans mon message précédent, l’attribut DateJour de la table RECEPTION_RETOUR devrait suffire pour les besoins. Qui a traité l'armoire 12 le 5 mai 2015 ? Si un seul opérateur peut le faire :

    SELECT id_Operateur
    FROM   RECEPTION_RETOUR
    WHERE  Code_Armoire = 12 AND DateJour = '2015_05_05' ;
 

Sauf preuve du contraire, exit la redondance.

Comment implémenter dans mon cas une entité date (date du jour) ?

Comme vous l’a expliqué CinePhil, une table Date n’a pas de sens sauf, à la limite, quand on fabrique un calendrier (et encore). Date n’est qu’un type, muni des opérateurs et fonctions permettant au besoin d’effectuer des calculs. Si on « implémente » une entité-type DATE, pourquoi ne pas vouloir aussi implémenter une entité-type INTEGER, une entité-type VARCHAR, j’en passe et des meilleures ?

[xeron33]

Si la règle est la suivante :

Si à la date <d1>, pour une armoire <a1> il n’y a qu’une réception/retour, alors comme dit CinePhil, la structure de RECEPTION_RETOUR est la suivante, où {Code_Armoire, DateJour} est clé primaire de la table et {Code_Armoire} clé étrangère :

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

Dans ce cas là la clé primaire Code_Armoire et étrangère auront la même valeur . Quel est l'intérêt, ne peut on pas écrire ça ?


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







J’ai du mal à interpréter ceci : « une rotation possède N armoires à vider ». En effet, je sais vider une armoire, mais de là à me prendre pour une rotation...

Merci de donner des exemples concrets.
Exemple la Rotation R1 demande à l'opérateur Raoul de vider les armoires 1,3 et 6. Quand je dis Rotation c'est un terme utilisé pour définir les armoires à vider par l'opérateur Raoul ce jour.
Pour la Rotation R2 ===>>> Armoire 5,9,15 etc...

Vider une armoire et effectuer une rotation sont-ils synonymes ? Sinon, à part vider une armoire, quels sont les types possibles de rotation ?
Non vider une armoire c'est prendre les dossiers à ranger dans les stocks ou les renvoyer à l'expéditeur (non conformes). Une Rotation c'est un ensemble d'armoires à vider .

Pour le moment j’en suis à ce genre d’exemple : à la date <d1>, l’opérateur Raoul doit vider (concrètement, physiquement) les armoires <a1>, <a>, etc., c'est-à-dire les débarrasser de leur contenu, tout en comptabilisant ce qu’il y a observé : dossiers reçus et/ou renvoyés.
oui c'est ça exactement

Pour que nous comprenions mieux, merci de fournir des exemples de charges de travail faisant intervenir Raoul et Fernand (et des rotations...)
Comme je l'ai dit plus haut Raoul est ce jour affecté à la Rotation R1 et doit donc vider les armoires 1,3 et 6. Fernand est affecté ce jour à la Rotation R2 et doit donc vider les armoires 5,9 et 15.

Êtes-vous d’accord avec les scénarios suivants :

(SC1) Comptabiliser le nombre de dossiers reçus et renvoyés A la date <d1>, pour une armoire <a1> signifie que l’opérateur <p1> , disons Raoul, met à jour ces quantités (table concernée : RECEPTION_RETOUR, attributs Nbre_Dossiers_reçus, Nbre_Dossiers_renvoyes).
oui

(SC2) A la date <d1>, pour une armoire <a1> il n’y a qu’une réception/retour <r1> et il n’y a qu’un seul opérateur <p1>, disons Raoul pour s’en charger (effectuer une rotation) : à la date <d1>, Fernand ne peut en aucune façon être concerné lui aussi par <r1>.

oui

Est-ce que le même jour, Fernand et Raoul peuvent intervenir sur l’armoire <a1> ? Seulement l’un des deux ?

Non Fernand et Raoul ne peuvent pas intervenir sur l'armoire <a1> sauf cas trés particulier pas traité encore ici . Oui seulement l'un des deux.

Si le traitement effectué par l’opérateur <p1> pour la réception/retour <r1> est d’un certain type, quels sont les types de traitement possibles ?
aucun autre pour l'instant à ce stade de l'étude

Concernant la table ARMOIRE, à quoi correspond l’attribut Lettre_jour, quelle est sa finalité ?
La lettre jour est prévu pour différencier l'armoire du lundi ou du mardi par exemple on reçoit l'armoire T01A on sait que c'est un lundi, l'armoire T01B l'armoire du mardi etc...


Au stade où j’en suis (provisoire !), du point de vue relationnel j’en suis à ceci, où je considère que seul un opérateur intervient sur un événement (réception/retour du jour) :

OPERATEUR {id_Operateur, Nom, Prenom}
    PRIMARY KEY { id_Operateur} ;

ARMOIRE {Code_Armoire, Localisation, Lettre_jour}
    PRIMARY KEY {Code_Armoire} ;

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

Pour le moment, la table ROTATION est absente, sa pertinence et sa place dans le modèle ne sont pas clairement démontrées.[/QUOTE]

J'espère vous avoir convaincu ou en tout cas bien expliqué l'utilité de la table ROTATION :
type Rotation (1,n) (Possede) (1,1) type Armoire

MErci bcp pour votre aide.
J'attends vos retours
Bonne soirée
A+

[fsmrel]

Bonsoir,


Désolé, une coquille s’est glissée dans mon message #9 d’hier. Dans la déclaration de la table RECEPTION_RETOUR, DateEvenement est à remplacer par DateJour.

Le script suivant :

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

Devient donc :

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

Si à la date <d1>, pour une armoire <a1> il n’y a qu’une réception/retour, alors comme dit CinePhil, la structure de RECEPTION_RETOUR est la suivante, où {Code_Armoire, DateJour} est clé primaire de la table et {Code_Armoire} clé étrangère :

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

Dans ce cas là la clé primaire Code_Armoire et étrangère auront la même valeur . Quel est l'intérêt, ne peut on pas écrire ça ?

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

Je rappelle que, suite à une coquille, j’ai remplacé DateEvenement par DateJour. Prenons maintenant le cas des armoires a1, a2, a3. Selon le script que je propose, les tables ARMOIRE et RECEPTION_RETOUR ressemblent à quelque chose comme ceci :

Table ARMOIRE, ayant pour clé primaire {Code_Armoire} :

Code_Armoire    Localisation    ...
a1              l1
a2              l2
a3              l3

Table RECEPTION_RETOUR, ayant pour clé primaire {Code_Armoire, DateJour}

Code_Armoire    DateJour    Nbre_Dossiers_reçus    Nbre_Dossiers_renvoyes
a1                d1           xa11                      ya11
a1                d2           xa12                      ya12
a1                d3           xa13                      ya13
a2                d1           xa21                      ya21
a2                d2           xa22                      ya22
a2                d3           xa23                      ya23
a3                d1           xa31                      ya31
a3                d2           xa32                      ya32
a3                d3           xa33                      ya33

La table RECEPTION_RETOUR est munie d’une clé étrangère {Code_Armoire} référençant la clé primaire {Code_Armoire} de la table ARMOIRE : dans ces conditions, un dossier ne peut pas être « orphelin » d’armoire. Au niveau conceptuel, ARMOIRE est une entité-type « forte » tandis que RECEPTION_RETOUR est une entité-type « faible », identifiée relativement à ARMOIRE : si je flanque une armoire à l’eau, les dossiers partiront avec l’armoire...

Maintenant, si je fais comme vous :

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

Puisque {DateJour} est clé primaire, les doublons sur la date sont interdits. Si on a engrangé les lignes suivantes pour la table RECEPTION_RETOUR :

Code_Armoire    DateJour    Nbre_Dossiers_reçus    Nbre_Dossiers_renvoyes
a1                d1           xa11                      ya11
a1                d2           xa12                      ya12
a1                d3           xa13                      ya13

Alors les dossiers des autres armoires ne pourront pas être ajoutés pour les dates d1, d2, d3 !


Allons-y maintenant pour modéliser. Le mieux est d’utiliser un outil ad-hoc, par exemple MySQL Workbench.

Commençons par les rotations et les armoires (à l’occasion, j’utilise des noms de tables et de colonnes qui ne sont pas forcément les vôtres, mais peu importe...) :




La colonne RotationId appartenant à l’en-tête de la table ARMOIRE est accompagné d’un losange rougeâtre, signifiant que {RotationId} est cl étrangère.

J’ai ajouté manuellement la clé bleue, signifiant que la colonne ArmoireCode fait l’objet d’une clé alternative. Il est plus que très fortement recommandé qu’une clé primaire ne soit pas porteuse d’une information maîtrisée par l’utilisateur (pour plus d’explications, cherchez dans les forums les mots clés « Tabourier », « jumeaux », j’en parle assez souvent...)


Ensuite on traite de l’affectation des opérateurs. Inutile d’établir un lien direct entre les tables OPERATEUR et ROTATION (votre table jonction2), car connaissant les armoires que Raoul doit traiter à telle date, comme on sait quelles sont les rotations auxquelles appartiennent ces armoires, on connaît donc les rotations auxquelles Raoul est affecté (à date) :





La clé rouge signifie qu’AFFECTATION est identifiée relativement à ARMOIRE. AFFECTATION a pour clé primaire la paire {ArmoireId, AffectationDate}, ce qui traduit la règle de gestion : A une date donnée, il n’y a qu’un opérateur (disons Raoul) pour s’occuper d’une armoire donnée.


Prise en compte du traitement des dossiers : un dossier se trouve dans une armoire à laquelle est affecté un opérateur et il est traité par cet opérateur, à la date d’affectation de l’opérateur à l’armoire : DOSSIER hérite de la clé d’affectation. Ici on représente les choses sous la forme d’une injection entre AFFECTATION et DOSSIER :






Mais vous pouvez préférer une bijection, auquel cas AFFECTATION absorbe DOSSIER :



Un exemple de script SQL (scénario injection) :

-- -----------------------------------------------------
-- 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 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 
(
  ArmoireId              INT           NOT NULL,
  AffectationDate        DATE          NOT NULL,
  OperateurId            INT           NOT NULL,
  CONSTRAINT AFFECTATION_PK PRIMARY KEY (ArmoireId, AffectationDate),
  CONSTRAINT AFFECTATION_OPERATEUR_FK FOREIGN KEY (OperateurId)
    REFERENCES OPERATEUR (OperateurId),
  CONSTRAINT AFFECTATION_ARMOIRE_FK FOREIGN KEY (ArmoireId)
    REFERENCES ARMOIRE (ArmoireId)
) ;

-- -----------------------------------------------------
-- Table DOSSIER
-- -----------------------------------------------------
CREATE TABLE DOSSIER 
(
  ArmoireId              INT           NOT NULL,
  DossierDate            DATE          NOT NULL,
  NbDossiersRecus        INT           NOT NULL,
  NbDossiersRenvoyes     INT           NOT NULL,
  CONSTRAINT DOSSIER_PK PRIMARY KEY (ArmoireId, DossierDate),
  CONSTRAINT DOSSIER_AFFECTATION_FK FOREIGN KEY (ArmoireId, DossierDate)
    REFERENCES AFFECTATION (ArmoireId, AffectationDate)
) ;

Question : une armoire appartient-elle toujours à la même rotation ? Peut-elle en changer ?

[fsmrel]

Bonjour,


Suite à la création des tables, voici un début de jeu d’essai :

INSERT INTO ROTATION (RotationId, RotationNom) VALUES (1, 'r1') ;
INSERT INTO ROTATION (RotationId, RotationNom) VALUES (2, 'r2') ;
INSERT INTO ROTATION (RotationId, RotationNom) VALUES (3, 'r3') ;

INSERT INTO ARMOIRE (RotationId, ArmoireId, ArmoireCode, ArmoireNom) VALUES (1, 1, 'a1', 'armoire 1') ;
INSERT INTO ARMOIRE (RotationId, ArmoireId, ArmoireCode, ArmoireNom) VALUES (3, 2, 'a2', 'armoire 2') ;
INSERT INTO ARMOIRE (RotationId, ArmoireId, ArmoireCode, ArmoireNom) VALUES (1, 3, 'a3', 'armoire 3') ;
INSERT INTO ARMOIRE (RotationId, ArmoireId, ArmoireCode, ArmoireNom) VALUES (3, 4, 'a4', 'armoire 4') ;
INSERT INTO ARMOIRE (RotationId, ArmoireId, ArmoireCode, ArmoireNom) VALUES (2, 5, 'a5', 'armoire 5') ;
INSERT INTO ARMOIRE (RotationId, ArmoireId, ArmoireCode, ArmoireNom) VALUES (1, 6, 'a6', 'armoire 6') ;
INSERT INTO ARMOIRE (RotationId, ArmoireId, ArmoireCode, ArmoireNom) VALUES (3, 7, 'a7', 'armoire 7') ;
INSERT INTO ARMOIRE (RotationId, ArmoireId, ArmoireCode, ArmoireNom) VALUES (3, 8, 'a8', 'armoire 8') ;
INSERT INTO ARMOIRE (RotationId, ArmoireId, ArmoireCode, ArmoireNom) VALUES (2, 9, 'a9', 'armoire 9') ;
INSERT INTO ARMOIRE (RotationId, ArmoireId, ArmoireCode, ArmoireNom) VALUES (2, 15, 'a15', 'armoire 15') ;

INSERT INTO OPERATEUR (OperateurId, OperateurCode, OperateurNom, OperateurPrenom) VALUES (1, 'p01', 'Naudin', 'Fernand') ; 
INSERT INTO OPERATEUR (OperateurId, OperateurCode, OperateurNom, OperateurPrenom) VALUES (2, 'p02', 'Volfoni', 'Raoul') ;
INSERT INTO OPERATEUR (OperateurId, OperateurCode, OperateurNom, OperateurPrenom) VALUES (3, 'p03', 'Volfoni', 'Paul') ;
INSERT INTO OPERATEUR (OperateurId, OperateurCode, OperateurNom, OperateurPrenom) VALUES (4, 'p04', 'Folace', 'Francis') ;
INSERT INTO OPERATEUR (OperateurId, OperateurCode, OperateurNom, OperateurPrenom) VALUES (5, 'p05', 'Delafoy', 'Antoine') ;

INSERT INTO AFFECTATION (ArmoireId, AffectationDate, OperateurId) VALUES (1, '2015-05-05', 2) ;
INSERT INTO AFFECTATION (ArmoireId, AffectationDate, OperateurId) VALUES (3, '2015-05-05', 2) ;
INSERT INTO AFFECTATION (ArmoireId, AffectationDate, OperateurId) VALUES (6, '2015-05-05', 2) ;
INSERT INTO AFFECTATION (ArmoireId, AffectationDate, OperateurId) VALUES (5, '2015-05-05', 1) ;
INSERT INTO AFFECTATION (ArmoireId, AffectationDate, OperateurId) VALUES (9, '2015-05-05', 1) ;
INSERT INTO AFFECTATION (ArmoireId, AffectationDate, OperateurId) VALUES (15, '2015-05-05', 1) ;
INSERT INTO AFFECTATION (ArmoireId, AffectationDate, OperateurId) VALUES (1, '2015-05-06', 2) ;
INSERT INTO AFFECTATION (ArmoireId, AffectationDate, OperateurId) VALUES (2, '2015-05-06', 2) ;
INSERT INTO AFFECTATION (ArmoireId, AffectationDate, OperateurId) VALUES (3, '2015-05-06', 4) ;
INSERT INTO AFFECTATION (ArmoireId, AffectationDate, OperateurId) VALUES (6, '2015-05-06', 2) ;
INSERT INTO AFFECTATION (ArmoireId, AffectationDate, OperateurId) VALUES (5, '2015-05-06', 3) ;
INSERT INTO AFFECTATION (ArmoireId, AffectationDate, OperateurId) VALUES (9, '2015-05-06', 3) ;
INSERT INTO AFFECTATION (ArmoireId, AffectationDate, OperateurId) VALUES (15, '2015-05-06', 1) ;


INSERT INTO DOSSIER (ArmoireId, DossierDate, NbDossiersRecus, NbDossiersRenvoyes) VALUES (1, '2015-05-05', 10, 0) ;
INSERT INTO DOSSIER (ArmoireId, DossierDate, NbDossiersRecus, NbDossiersRenvoyes) VALUES (3, '2015-05-05', 30, 3) ;
INSERT INTO DOSSIER (ArmoireId, DossierDate, NbDossiersRecus, NbDossiersRenvoyes) VALUES (6, '2015-05-05', 5, 5) ;
INSERT INTO DOSSIER (ArmoireId, DossierDate, NbDossiersRecus, NbDossiersRenvoyes) VALUES (5, '2015-05-05', 7, 1) ;
INSERT INTO DOSSIER (ArmoireId, DossierDate, NbDossiersRecus, NbDossiersRenvoyes) VALUES (9, '2015-05-05', 3, 8) ;
INSERT INTO DOSSIER (ArmoireId, DossierDate, NbDossiersRecus, NbDossiersRenvoyes) VALUES (15, '2015-05-05', 9, 0) ;
INSERT INTO DOSSIER (ArmoireId, DossierDate, NbDossiersRecus, NbDossiersRenvoyes) VALUES (1, '2015-05-06', 14, 2) ;
INSERT INTO DOSSIER (ArmoireId, DossierDate, NbDossiersRecus, NbDossiersRenvoyes) VALUES (2, '2015-05-06', 4, 0) ;
INSERT INTO DOSSIER (ArmoireId, DossierDate, NbDossiersRecus, NbDossiersRenvoyes) VALUES (3, '2015-05-06', 0, 0) ;
INSERT INTO DOSSIER (ArmoireId, DossierDate, NbDossiersRecus, NbDossiersRenvoyes) VALUES (6, '2015-05-06', 7, 7) ;
INSERT INTO DOSSIER (ArmoireId, DossierDate, NbDossiersRecus, NbDossiersRenvoyes) VALUES (5, '2015-05-06', 4, 2) ;
INSERT INTO DOSSIER (ArmoireId, DossierDate, NbDossiersRecus, NbDossiersRenvoyes) VALUES (9, '2015-05-06', 3, 3) ;
INSERT INTO DOSSIER (ArmoireId, DossierDate, NbDossiersRecus, NbDossiersRenvoyes) VALUES (15, '2015-05-06', 1, 0) ;

Table JONCTION2 : on la fournit sous la forme d’une table virtuelle (vue) :

CREATE VIEW JONCTION2 (RotationNom, AffectationDate, OperateurPrenom, OperateurNom) AS
    SELECT DISTINCT RotationNom, AffectationDate, OperateurPrenom, OperateurNom 
    FROM   ROTATION AS x JOIN ARMOIRE AS y ON x.RotationId = y.RotationId
                         JOIN AFFECTATION AS z ON y.ArmoireId = z.ArmoireId 
                         JOIN OPERATEUR AS t ON z.OperateurId = t.OperateurId ;

Consultation de la table virtuelle JONCTION2 :

SELECT RotationNom, AffectationDate, OperateurPrenom, OperateurNom  
FROM   JONCTION2
ORDER BY AffectationDate, RotationNom, OperateurNom, OperateurPrenom ;

Au résultat :

RotationNom    AffectationDate     OperateurPrenom    OperateurNom 
r1             2015-05-05          Raoul              Volfoni 
r2             2015-05-05          Fernand            Naudin 
r1             2015-05-06          Francis            Folace 
r1             2015-05-06          Raoul              Volfoni 
r2             2015-05-06          Fernand            Naudin 
r2             2015-05-06          Paul               Volfoni  
r3             2015-05-06          Raoul              Volfoni 

Les rotations du 2015-05-05

SELECT DISTINCT RotationNom, OperateurPrenom, OperateurNom  
FROM   JONCTION2
WHERE  AffectationDate = '2015-05-05'
ORDER BY RotationNom, OperateurNom, OperateurPrenom ;

=>

RotationNom    OperateurPrenom     OperateurNom
r1             Raoul               Volfoni
r2             Fernand             Naudin

Etc.

[xeron33]

Bonsoir,



A partir du script de tables que j’ai fourni :

    SELECT Nbre_Dossiers_reçus, Nbre_Dossiers_renvoyes
    FROM   RECEPTION_RETOUR
    WHERE  Code_Armoire = 12 AND DateJour = '2015_05_05' ;
 

Bonsoir,
Pour ça Ok avec vous








J’avais bien compris votre question, mais ma réponse est la suivante : qu’est-ce qui prouve que l’existence de la table jonction2 a effectivement un sens ? Si oui, qu’est-ce qui prouve que cette table doive être dotée d’un attribut de type date ? Pour le moment, comme je l’ai dit, en l’absence de réponse aux questions que j’ai posées dans mon message précédent, l’attribut DateJour de la table RECEPTION_RETOUR devrait suffire pour les besoins. Qui a traité l'armoire 12 le 5 mai 2015 ? Si un seul opérateur peut le faire :

    SELECT id_Operateur
    FROM   RECEPTION_RETOUR
    WHERE  Code_Armoire = 12 AND DateJour = '2015_05_05' ;
 

Par contre pour ça non car je n'ai pas dans ma table Receptions_Retours le champ id_Operateur qui se trouve lui dans la table Operateur


Sauf preuve du contraire, exit la redondance.




Comme vous l’a expliqué CinePhil, une table Date n’a pas de sens sauf, à la limite, quand on fabrique un calendrier (et encore). Date n’est qu’un type, muni des opérateurs et fonctions permettant au besoin d’effectuer des calculs. Si on « implémente » une entité-type DATE, pourquoi ne pas vouloir aussi implémenter une entité-type INTEGER, une entité-type VARCHAR, j’en passe et des meilleures ?

[xeron33]

Bonsoir,


Désolé, une coquille s’est glissée dans mon message #9 d’hier. Dans la déclaration de la table RECEPTION_RETOUR, DateEvenement est à remplacer par DateJour.

Le script suivant :

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

Devient donc :

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

Je rappelle que, suite à une coquille, j’ai remplacé DateEvenement par DateJour. Prenons maintenant le cas des armoires a1, a2, a3. Selon le script que je propose, les tables ARMOIRE et RECEPTION_RETOUR ressemblent à quelque chose comme ceci :

Table ARMOIRE, ayant pour clé primaire {Code_Armoire} :

Code_Armoire    Localisation    ...
a1              l1
a2              l2
a3              l3

Table RECEPTION_RETOUR, ayant pour clé primaire {Code_Armoire, DateJour}

Code_Armoire    DateJour    Nbre_Dossiers_reçus    Nbre_Dossiers_renvoyes
a1                d1           xa11                      ya11
a1                d2           xa12                      ya12
a1                d3           xa13                      ya13
a2                d1           xa21                      ya21
a2                d2           xa22                      ya22
a2                d3           xa23                      ya23
a3                d1           xa31                      ya31
a3                d2           xa32                      ya32
a3                d3           xa33                      ya33

La table RECEPTION_RETOUR est munie d’une clé étrangère {Code_Armoire} référençant la clé primaire {Code_Armoire} de la table ARMOIRE : dans ces conditions, un dossier ne peut pas être « orphelin » d’armoire. Au niveau conceptuel, ARMOIRE est une entité-type « forte » tandis que RECEPTION_RETOUR est une entité-type « faible », identifiée relativement à ARMOIRE : si je flanque une armoire à l’eau, les dossiers partiront avec l’armoire...

Maintenant, si je fais comme vous :

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

Puisque {DateJour} est clé primaire, les doublons sur la date sont interdits. Si on a engrangé les lignes suivantes pour la table RECEPTION_RETOUR :

Code_Armoire    DateJour    Nbre_Dossiers_reçus    Nbre_Dossiers_renvoyes
a1                d1           xa11                      ya11
a1                d2           xa12                      ya12
a1                d3           xa13                      ya13

Alors les dossiers des autres armoires ne pourront pas être ajoutés pour les dates d1, d2, d3 !

]Bonsoir d'accord avec vous


Allons-y maintenant pour modéliser. Le mieux est d’utiliser un outil ad-hoc, par exemple MySQL Workbench.

Commençons par les rotations et les armoires (à l’occasion, j’utilise des noms de tables et de colonnes qui ne sont pas forcément les vôtres, mais peu importe...) :




La colonne RotationId appartenant à l’en-tête de la table ARMOIRE est accompagné d’un losange rougeâtre, signifiant que {RotationId} est cl étrangère.

J’ai ajouté manuellement la clé bleue, signifiant que la colonne ArmoireCode fait l’objet d’une clé alternative. Il est plus que très fortement recommandé qu’une clé primaire ne soit pas porteuse d’une information maîtrisée par l’utilisateur (pour plus d’explications, cherchez dans les forums les mots clés « Tabourier », « jumeaux », j’en parle assez souvent...)


Ensuite on traite de l’affectation des opérateurs. Inutile d’établir un lien direct entre les tables OPERATEUR et ROTATION (votre table jonction2), car connaissant les armoires que Raoul doit traiter à telle date, comme on sait quelles sont les rotations auxquelles appartiennent ces armoires, on connaît donc les rotations auxquelles Raoul est affecté (à date) :

en effet d'accord avec vous






[/pre]


Question : une armoire appartient-elle toujours à la même rotation ? Peut-elle en changer ?

Non elle peut changer
MErci encore A+

[fsmrel]

Bonsoir,


Les scénarios que je vous ai proposés vous conviennent-ils ?


Rappel :


Scénario 1






Scénario 2





Et le code SQL correspondant ? La vue jonction2 ?

[xeron33]

Bonsoir,


Les scénarios que je vous ai proposés vous conviennent-ils ?


Rappel :


Scénario 1






Scénario 2





Et le code SQL correspondant ? La vue jonction2 ?

****************************************************************************************
bonsoir et vraiment merci ...
Je préfère le Scénario 1 qui correspond plus à mon idée de départ (entité pour les réceptions_livraisons).
Par contre après réflexion, je pense que le fait de supprimer la table jonction2 et d'utiliser une table virtuelle en effet ça marche mais au niveau du besoin ça ne correspond pas, en effet on parle plus d'affectation d'un opérateur à une rotation, donc je pense que la saisie directe d'un opérateur et son affectation(rotation) correspond plus à la réalité et sera plus rapide aussi je pense. Tout le reste de votre code SQL me convient.
Juste une précision sur le "Tabourier" :

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)
) ;
1) La base se trouvera sur Access 2010, peut ont créer ce genre de clé sur Access 2010 ?
2) Les valeurs des clés ArmoireID et ArmoireCode sont identiques ?

Merci et à à +

[fsmrel]

Bonsoir xeron,

Les valeurs des clés ArmoireID et ArmoireCode sont identiques ?

Certes non, sinon un seul attribut suffirait... L’attribut ArmoireCode correspond au code d’armoire connu de l’utilisateur, donc a priori significatif (du genre "T01"), tandis qu’il ne connaît pas l’attribut ArmoireId, qui doit rester non modifiable, afin d’assurer la stabilité des liens entre les tables, donc celle de la base de données (ArmoireId peut être par exemple un auto-incrément).

La base se trouvera sur Access 2010, peut ont créer ce genre de clé sur Access 2010 ?

Oui !

Pour ma part je procède ainsi (je suis en version manifestement non française...) :

Je crée une nouvelle requête (onglet « CREATE » > « Query Design ») :






Je ferme la fenêtre « Show Table » qui s’est ouverte et clique sur l’icône SQL :





Puis je copie dans la zone de texte le code du CREATE TABLE ARMOIRE :





Je ferme tout ça, je nomme la requête (par exemple ARMOIRE_CREATE_TABLE) et c’est parti pour l’exécuter...

utiliser une table virtuelle en effet ça marche mais au niveau du besoin ça ne correspond pas, en effet on parle plus d'affectation d'un opérateur à une rotation

Normalement, avec un trigger, on pourrait effectuer des inserts dans Jonction2, mais avec ACCESS il y a des bugs (au moins avec la version que j’utilise, ACCESS 2013), ça été monté de façon bridée et stupide par MS et la crise de nerfs n’est pas loin...

Autrement dit, si vous préférez une table à une vue, allons-y, créons cette table.

Un scénario :

Si à la date d1 Raoul est affecté à la rotation r1, il s’occupera de l’ensemble des armoires de cette rotation et par voie de conséquence de tous les dossiers qui dans ces armoires sont datés à d1. Cela suppose qu’à d1 seul Raoul est affecté à la rotation r1, Fernand ne pourra être affecté qu’à une autre rotation. Cette règle est-elle valide ? Sinon quelle est la règle exacte ? (En effet, il faudrait répartir les tâches par sous-ensembles d'armoires...)


Question subsidiaire :

— A la date d1, Raoul peut-il être concerné par plus d’une rotation ?


En fait, je cherche à dresser l’inventaire précis des clés candidates de la table Jonction2. Au départ, vous aviez prévu :

Jonction2(#id_Operateur,#id_Rotation ,Date);

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 ?

[xeron33]

Bonsoir xeron,




Certes non, sinon un seul attribut suffirait... L’attribut ArmoireCode correspond au code d’armoire connu de l’utilisateur, donc a priori significatif (du genre "T01"), tandis qu’il ne connaît pas l’attribut ArmoireId, qui doit rester non modifiable, afin d’assurer la stabilité des liens entre les tables, donc celle de la base de données (ArmoireId peut être par exemple un auto-incrément).




Oui !

Pour ma part je procède ainsi (je suis en version manifestement non française...) :

Je crée une nouvelle requête (onglet « CREATE » > « Query Design ») :






Je ferme la fenêtre « Show Table » qui s’est ouverte et clique sur l’icône SQL :





Puis je copie dans la zone de texte le code du CREATE TABLE ARMOIRE :





Je ferme tout ça, je nomme la requête (par exemple ARMOIRE_CREATE_TABLE) et c’est parti pour l’exécuter...





Normalement, avec un trigger, on pourrait effectuer des inserts dans Jonction2, mais avec ACCESS il y a des bugs (au moins avec la version que j’utilise, ACCESS 2013), ça été monté de façon bridée et stupide par MS et la crise de nerfs n’est pas loin...

Autrement dit, si vous préférez une table à une vue, allons-y, créons cette table.

Un scénario :

Si à la date d1 Raoul est affecté à la rotation r1, il s’occupera de l’ensemble des armoires de cette rotation et par voie de conséquence de tous les dossiers qui dans ces armoires sont datés à d1. Cela suppose qu’à d1 seul Raoul est affecté à la rotation r1, Fernand ne pourra être affecté qu’à une autre rotation. Cette règle est-elle valide ? Sinon quelle est la règle exacte ? (En effet, il faudrait répartir les tâches par sous-ensembles d'armoires...)

Oui cette règle est valide, sauf cas exceptionnels ou parfois 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.


Question subsidiaire :

— A la date d1, Raoul peut-il être concerné par plus d’une rotation ?
sauf cas exceptionnels ou parfois 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

Pour ce cas particulier j'ai pensé à faire évoluer le MCD comme ceci :
On a actuellement :
type_Rotation (1,n) (Possede) (1,1) type_Armoire
je rajoute ceci :
type_Rotation (0,1) (Rajoute) (0,n) type_Armoire

avec modif de 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)
) ;


Question subsidiaire :

— A la date d1, Raoul peut-il être concerné par plus d’une rotation ?
Vu plus haut




En fait, je cherche à dresser l’inventaire précis des clés candidates de la table Jonction2. Au départ, vous aviez prévu :



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 ?

C'est ce qu'il se passe...

Merci à vous dites moi ce que vous pensez de l'évolution du Modèle
A +