Discussion :

[orwen]

bonjour, j'espère que le problème que je vous pose n'a pas été traité dans une précédente discussion.

je dois traiter des incidents intervenant sur un réseau de transport (problématique peu souriante...).
ces incidents peuvent être de 3 sortes: trouble, vandalisme et agression.

un trouble:
- 5 sortes possibles

un acte de vandalisme:
- intervient dans trois types de lieux possibles
- provoqué par 2 moyens possibles

une agression:
- intervient dans 8 ciconstances possibles
- caractérisée par 5 actes possibles

A ces catégories et sous catégories, je dois associer une date, une heure, une commune.

mon problème:
j'ai structuré ma base de manière hiérarchique (selon le même schéma que mon explication):
Trouble( code-incident, code_trouble)
type de trouble (code_trouble, désignation)

Vandalisme (code-incident, code_lieux,code_moyen)
type de lieux de vandalisme( code_lieux, désignation)
type de moyen de vandalisme (code_moyen, désignation)

agression (code-incident, code_circonstance, code_acte)
circonstance (code_circonstance, désignation)
acte (code_acte,désigantion)

Incident (code-incident, date, heure, commune)

pour créer une occurrence d'incident, je remplis d'abord la table incident, puis la table correspondant au type d'incident.
Mais rien n'empêche de rentrer le même code-incident dans deux tables type d'incident différentes (trouble et agression par exemple)

existe-t-il un moyen d'empêcher cette réplication de clé primaire, sachant qu'un incident ne peut pas être de plusieurs type en même temps (on retient le type le plus grave)? J'essaye depuis quelques jours déjà de tourner et retourner le problème et je continue à me demander si la solution réside dans la création d'un autre MCD, dans les options de validité associé au champ code-incident, ou dans la forme de la clé primaire code-incident.

Merci par avance pour l'aide que vous pourrez m'apporter.

[marot_r]

C'est un problème classique. J'ai une application où j'ai 4 type de factures possible qui m'a posé le même problème.

J'avais étudié 2 façons:

Table Entete :
Contient les champs qui sont communs à tous les types d'incident (ex : la date)
(Cette table te permet l'unicité)

Table Detail Agression
ClefEntete
Detail specifique de agression

Table Detail Trouble
ClefEntete
Detail specifique de trouble

Table Detail Vandalisme
ClefEntete
Detail specifique de vandalisme

Personnelement j'ai trouvé cette structure trop pénible à gérer et j'en suis venu à la structure qui correspondrait dans ton cas. Une seule table qui gére tous les incidents.

Table Incident
Clef
Champs communs (ex : date)
ClefTypeEvenement
Details Trouble
Details Vandalisme
Details Agression

En faisant un écran de saisie par type j'affiche les champs dont j'ai besoin. Les autres resteront vides.

A+

[orwen]

merci marot_r pour la rapidité de ta réponse.

Si j'ai bien compris il n'existerait plus qu'une seule table dont certains champs resteraient vides en fonctions du type d'incident. Pour faciliter les choses, tu me conseilles de créer un formulaire qui me permettrait, selon le type d'incident, de ne remplir que les "détails" relatifs à ce type d'incident?

Sans l'avoir essayé, il est vrai que cela semble pouvoir arranger grandement les choses. En même temps, c'est une approche qui est déja possibe avec la structure que j'ai actuellement et cela ne me semble pas très "académique" au regard de la méthode merise.

Je retiens ta proposition, je vais la tester, mais je reste ouvert à d'autres suggestions.

[marot_r]

merci marot_r pour la rapidité de ta réponse.

Si j'ai bien compris il n'existerait plus qu'une seule table dont certains champs resteraient vides en fonctions du type d'incident. Pour faciliter les choses, tu me conseilles de créer un formulaire qui me permettrait, selon le type d'incident, de ne remplir que les "détails" relatifs à ce type d'agression?

Sans l'avoir essayé, il est vrai que cela semble pouvoir arranger grandement les choses. En même temps, c'est une approche qui est déja possibe avec la structure que j'ai actuellement et cela ne me semble pas très "académique" au regard de la méthode merise.

Tu as parfaitement raison, ce n'est PAS DU TOUT académique mais c'est vraiment plus pratique. Il y a toujours un écart entre le modèle concpetuel et le modèle physique et c'est là que tu apportes une valeur ajoutée, quand tu sais quand il faut enfreindre les lois :-) mais surtout car tu sais que tu transgresse une loi et tu sais pourquoi.

L'idéal dans ce cas serait d'avoir une base objet, tu aurais des classes Agression, trouble et vandalisme qui hériterait d'une super-classe événement.

En même temps, c'est une approche qui est déja possibe avec la structure que j'ai actuellement

Tu as raison pour les écrans de saisie mais ta structure actuelle ne te permets pas d'assurer l'unicité tandis que la nouvelle le permet et c'est ton but initial.

A+

[orwen]

Ce qui ne cesse de m'étonner, c'est que les renseignements spécifiques aux types d'incidents, se retrouvent tous regroupés au sein de la même table.

Par exemple, j'ai simplifié la table agression puisqu'elle contient d'autres champs que ceux que j'ai cités. il faudrait donc que je les mette aussi dans ma table incident?

Je me débat peut être face à l'inéluctable; c'est juste que je vais avoir du mal à expliquer un choix qui semble aller contre la "logique établie".

edit:
n'est il pas possible de:
* garder la structure actuelle et de rajouter un champ type_incident dans la table incident (valeurs possibles troubles, vandalisme ou agression)
* renseigner la condition valide si sur la clé primaire des différentes tables par [incident].[type_incident] = valeur correspondante à la table dans laquelle on veut creer un evenement incident

En plus, cela me permettrait de créer un formulaire avec un affichage conditionnel en fonction du type d'incident

En tout cas merci encore. Je vais attendre encore un peu pour d'autres propositions et dans le cas ou il n'y en aurait pas je marquerai le sujet comme résolu...

[marot_r]

Par exemple, j'ai simplifié la table agression puisqu'elle contient d'autres champs que ceux que j'ai cités. il faudrait donc que je les mette aussi dans ma table incident?

Oui, si tu adoptes ma logique.

A+

[orwen]

ça frise l'hérésie...

[marot_r]

ça frise l'hérésie...

Je suis quelqu'un de pragmatique si une solution dogmatique me faits faire 10 fois le travail d'une solution hérétique, alors je choisi l'hérésie, surtout que cette hérésie a des conséquences minimes sur le modèle qui reste très propre conceptuellement parlant.

A+

[vodiem]

salut tous le monde,

moi j'adore l'hérésie: du moment que ca marche.
c'est souvent le plus efficace et rapide.

l'origine de ton pb viens du fait qu'il te manque un champ "type d'incident" dans ta table incident.

Incident (code-incident, type-incident, date, heure, commune)

mais cela peut rendre (éventuellement, cela dépend de tes exigences) le traitement du code-indicent plus compliqué.

puisque l'énumération est exhaustive je te conseil:
Incident (code-indident, codeAgression, codeTrouble, codeVandalisme, date, heure, commune)
comme ca, il n'y a pas de jalou, chacun à sa propre énumération et tu peux à partir d'une requete les avoirs facilement tous ou un seul type.

[orwen]

merci pour votre aide. pour information, je teste actuellement la structure plus complexe que j'avais au départ avec, pour l'alimenter, un formulaire basé sur une requête portant sur toute les tables (j'aime bien cette méthode, ça m'évite de créer des sous formulaires)

Grâce à l'ajout du champ type incident, j'ai ajouté une clause de validité.
Mon formulaire comporte désormais une liste déroulante avec les trois types possibles d'incidents
Les listes déroulantes correspondantes aux informations relatives aux types d'incidents comporte désormais une fonction
Valide si: Vraifaux(formulaire!Type_incident="XXX","vrai";"faux")=vrai
qui me permet de rentrer les informations relatives au bon type d'incident et d'interdire les autres.

le problème désormais c'est qu'une fois rentrée la modification des information relatives aux incidents est impossible. si je choisit trouble comme type d'incident que je rentre les informations puis que je change le type d'incident ça plante (en effaçant les renseignements par la même occasion)

la structure de la base proposée semble donc toute indiquée. Je poursuis les tests...