Discussion :

[kesamba]

Bonjour,

cette discussion est la suite de celle ci http://www.developpez.net/forums/d12...aisie-donnees/ que j'ai déjà marquée comme résolue

il ya le probleme suivant qui se pose:

j'ai une table ticket (IDTicket,#IdEtudiant,.... )

qui est en relation avec la table Etudiant(IdEtudiant, Nom, ...)

et les trois autres tables suivantes

Imprimante(IdImprimante, Nom, ...) ;
Ecran(IdEcran, Nom, ...) ;
Ordinateur(IdOrdinateur, Nom, ...) ;




je n'arrive pas à bien concevoir ma table ticket.

voici ce que j'avais comme table ticket avant le changement.


Ticket (IDTicket,#IdEtudiant,#IdMateriel_Info,#IdSurveillant,... )


quand un appareil tombe en panne, l'étudiant qui l'utilise doit établir un ticket pour tenir le surveillant au courant.

la clé #IdMateriel_Info devrait permettre de savoir de quel materiel il s'agit.

je vais le résumé comme ca:

1 étudiant peut établir n ticket(s) ou pas du tout ;
1 ticket peut être établi par n étudiant(s) ou par aucun d'eux;
jusque là tout marche bien.

voici où le probleme se pose:
je dois remplacer dans la table Ticket la clé étrangere par #IdMateriel_Info par #IdImprimante, #IdEcran, #IdOrdinateur

et j'arrive pas.

besoin d'aide

Merci.

[Richard_35]

Bonjour Kesamba,

je dois remplacer dans la table Ticket la clé étrangere par #IdMateriel_Info par #IdImprimante, #IdEcran, #IdOrdinateur

==> tu devrais pouvoir résoudre cette problématique via la technique de l'héritage.

Mais, d'abord, es-tu certain que

1 ticket peut être établi par n étudiant(s) ou par aucun d'eux;

?
==> à mon avis, 1 ticket ne peut être établi que par 1 étudiant et, forcément, par 1 étudiant. Autrement dit, plusieurs étudiants ne vont pas créer un même ticket. Non ?

[kesamba]

Tu as raison. 1 ticket ne peut être établi que par 1 étudiant. Je me suis mal exprimé.

peux tu me donner un exemple de cette technique ou un lien exemple qui me l'explique d'une facon pas très compliquée? car dit on l'exemple vaut mieux que la lecon

[Richard_35]

Il faut passer par une table "mère" :

Materiel(IdMateriel, [informations communes à tous les matériels])

les tables qui héritent deviennent :

Imprimante(IdMateriel, [informations propres aux imprimantes])
Ecran(IdMateriel, [informations propres aux écrans])
Ordinateur(IdMateriel, [informations propres aux ordinateurs])
==> il faut vérifier que IdMateriel n'est distribué qu'une seule fois.

ce qui donne :

Ticket(IDTicket,#IdEtudiant,#IdMateriel,#IdSurveillant,... )

[kesamba]

Bonjour Richard_35,

Je te remercie vivement pour l’exemple.
Mais je suis un peu confuse. Par rapport à ces trois tables



Imprimante(IdMateriel, [informations propres aux imprimantes])
Ecran(IdMateriel, [informations propres aux écrans])
Ordinateur(IdMateriel, [informations propres aux ordinateurs])


Que deviennent les clés primaires

IdImprimante, IdEcran, IdOrdinateur voire la dernière discussion

Les trois tables étaient définies comme suit :


Imprimante(IdImprimante, Nom, ...) ;
Ecran(IdEcran, Nom, ...) ;
Ordinateur(IdOrdinateur, Nom, ...) ;

Et j’avais des tables dites "associatives"

Etudiant_Imprimante(#IdEtudiant, #IdImprimante, ...) ;
Etudiant_Ecran(#IdEtudiant, #IdEcran, ...) ;
Etudiant_Ordinateur(#IdEtudiant, #IdOrdinateur, ...).

Est-ce que je dois aussi modifier tables "associatives" ?

[Richard_35]

Bonjour Kesamba,

Que deviennent les clés primaires IdImprimante, IdEcran, IdOrdinateur (voir la dernière discussion) ?
Les trois tables étaient définies comme suit :
Imprimante(IdImprimante, Nom, ...) ;
Ecran(IdEcran, Nom, ...) ;
Ordinateur(IdOrdinateur, Nom, ...) ;

==> dans ta précédente discussion, il me semble que tu n'avais pas évoqué la notion de ticket qui concerne un matériel, quel qu'il soit. Donc, effectivement, il faut remplacer IdImprimante, IdEcran, IdOrdinateur par IdMateriel.

Et j’avais des tables dites "associatives"
Etudiant_Imprimante(#IdEtudiant, #IdImprimante, ...) ;
Etudiant_Ecran(#IdEtudiant, #IdEcran, ...) ;
Etudiant_Ordinateur(#IdEtudiant, #IdOrdinateur, ...).
Est-ce que je dois aussi modifier tables "associatives" ?

==> eh bien, cela dépend...

Si les couples Etudiant_Imprimante, Etudiant_Ecran et Etudiant_Ordinateur possèdent des attributs différents, alors il faut garder :

Etudiant_Imprimante(#IdEtudiant, #IdImprimante, [informations propres au couple Etudiant/Imprimante]) ;
Etudiant_Ecran(#IdEtudiant, #IdEcran, [informations propres au couple Etudiant/Ecran]) ;
Etudiant_Ordinateur(#IdEtudiant, #IdOrdinateur, [informations propres au couple Etudiant/Ordinateur]).

Si les couples Etudiant_Imprimante, Etudiant_Ecran et Etudiant_Ordinateur possèdent les mêmes attributs, alors il faut :

Etudiant_Materiel(#IdEtudiant, #IdMateriel, [informations liées au couple Etudiant/Materiel]).

[kesamba]

Dans ma précédente discussion, je ne savais pas encore qu’il fallait établir les tickets pour le matériel en panne.

on va dire que pour mon problème, il faut considérer deux cas de figure.

Le premier cas c’est si les couples Etudiant_Imprimante, Etudiant_Ecran et Etudiant_Ordinateur possèdent les mêmes attributs

Alors on aura besoin de deux tables intermédiaires:
Materiel(IdMateriel, [informations communes à tous les matériels]) et

Etudiant_Materiel(#IdEtudiant, #IdMateriel, [informations liées au couple Etudiant/Materiel]). Là c’est clair.


C’est le deuxième cas qui me fait défaut. Le cas où les couples Etudiant_Imprimante, Etudiant_Ecran et Etudiant_Ordinateur possèdent des attributs différents alors


Les Tables sont définies comme ci dessous

Etudiant(IdEtudiant, Nom, ...) ;
Imprimante(IdImprimante, Nom, ...) ;
Ecran(IdEcran, Nom, ...) ;
Ordinateur(IdOrdinateur, Nom, ...) ;


Et les tables associatives aussi sans clé étrangère #IdMateriel. Puisqu’on n’aura pas besoin de la table Materiel(IdMateriel,…)


Etudiant_Imprimante(#IdEtudiant, #IdImprimante, [informations propres au couple Etudiant/Imprimante]) ;
Etudiant_Ecran(#IdEtudiant, #IdEcran, [informations propres au couple Etudiant/Ecran]) ;
Etudiant_Ordinateur (#IdEtudiant, #IdOrdinateur, [informations propres au couple Etudiant/Ordinateur]).

Question:
1- Comme se fera alors la relation entre par exemple Etudiant_Imprimante et Ticket
Puisque dans la table Ticket il n’y a pas de #IdImprimante et dans la table Etudiant_Imprimante il n’ ya pas de # IDTicket qui les lient d’une façon ou d’une autre

2- Et la table Ticket comment va-t-on la définir dans ce cas ?

Merci

[Richard_35]

Dans ma précédente discussion, je ne savais pas encore qu’il fallait établir les tickets pour le matériel en panne.

==> fais attention : en découvrant ce qu'il faut faire au fur et à mesure de la modélisation, tu risques de découvrir des contraintes qui remettront en cause ton analyse précédente... Il faut donc analyser l'ensemble du projet et définir des règles de gestion précises avant de passer à la structure des tables.

1- Comme se fera alors la relation entre par exemple Etudiant_Imprimante et Ticket
Puisque dans la table Ticket il n’y a pas de #IdImprimante et dans la table Etudiant_Imprimante il n’ ya pas de # IDTicket qui les lient d’une façon ou d’une autre

==> pas de relation entre Etudiant_Imprimante et Ticket. Ticket pointera vers Etudiant et vers Imprimante, Etudiant_Imprimante ne servirait que pour déterminer si le couple Etudiant/Imprimante est valide au moment de la création du ticket.

2- Et la table Ticket comment va-t-on la définir dans ce cas ?

==> cela pourrait être :

Ticket(IDTicket, #IdEtudiant, #IdSurveillant,... ) ;
Ticket_Imprimante(IDTicket, #IdImprimante, ... ) ;
Ticket_Ecran(IDTicket, #IdEcran, ... ) ;
Ticket_Ordinateur(IDTicket, #IdOrdinateur, ... ).

propre, mais un peu lourd... car s'il y a d'autre matériel, il faut ajouter une table...
Sinon :

Ticket(IDTicket, #IdEtudiant, #Materiel, TypeMateriel (I/E/O), #IdSurveillant,... )

moins propre, mais plus simple... s'il y a d'autre matériel, il faut ajouter une valeur de flag.

Le mieux, comme indiqué précédemment, est de savoir exactement ce qu'il faut faire.