Discussion :

[gouzou38]

Bonjour,

Développant actuellement une application de suivi d'exploitation sous Webdev en hyperfileSQL, je rencontre actuellement un souci dans la mise en oeuvre d'une contrainte d'intégrité.
L'application permet d'effectuer des contrôles (suivis) selon plusieurs périodes: au quotidien, hebdomadaire et mensuel.

La structure du fichier HF central est le suivant:
Controle (IDControle, Datecontrole, #IDPeriode, #IDApplication, statut, #IDAnomalie, #DatecontroleIDApplicationIDPeriode)

A l'ajout s'il s'agit d'un contrôle au quotidien l'intégrité est automatiquement respectée car vérifiée à l'aide de la clé composée.
A l'inverse s'il s'agit d'un contrôle de type mensuel ou hebdo, l'intégrité référentielle n'est à l'heure actuelle pas respectée.

Pour cette raison, je pensais faire un trigger à l'insert qui appellerait une procédure paramétrée chargée de comparer les données dans la base et de faire l'insertion, si le résultat est cohérent.

Mais ce qui me pose problème, c'est que je ne sais pas si cela est faisable. Je n'ai pas trouvé d'exemples parlant, et de plus, la documentation, si je l'ai bien comprise, énonce que les procédures de triggers ne peuvent contenir de paramètres.

Pouvez-vous me venir en aide sur ce problème, en m'indiquant si ce que je souhaite faire reste possible ou pas et comment parvenir, sinon, à faire respecter l'intégrité référentielle?

Vous remerciant par avance.
Bien Cordialement.

[vmolines]

Qu'entendez vous par intégrité référentielle ? J'ai l'impression que vous voulez parler de contrainte d'unicité. Plus précisément vous ne souhaitez pas avoir de doublon de contrôle pour une même période et une même application. Et ce quelle que soit la périodicité.

Votre problème vient d'une mauvaise modélisation si j’interprète bien le peu d'informations que vous donnez par rapport à la problématique que vous avez.

Je modéliserais ainsi :

PERIODE = {IDPERIODE, DATEDEBUT, DATEFIN)
CONTROLE = {#IDAPPLICATION, #IDPERIODE, DATECONTROLE, STATUT, #IDAnomalie}

PK soulignées
FK préfixées par #
Indexes sur les colonnes en gras

Sous cette forme, les périodes peuvent être quotidiennes, hebdo, mensuelles (ou autre d'ailleurs) et le contrôle d'unicité des contrôles est réalisé par la PK elle même.

C'est une suggestion simpliste pour traiter le problème, il faut l'adapter à votre besoin.

[gouzou38]

Bonjour,

Je vous remercie pour votre réponse. Effectivement, il s'agit bien d'une contrainte d'unicité. Pardon pour cet abus de langage..

J'ai par le passé testé la solution que vous me proposez ici. Aussi juste soit-elle, elle me pose également souci.

L'application ne contient pas de période par date, mais par nom.
On a ainsi PERIODE(IDPeriode, NomPeriode).

EXEMPLE:

1-Matin
2- Après-midi
3- Mensuel
4- Hebdo

Or, si dans la situation actuelle, je mets une clé composée à CONTROLE, cela posera problème pour des suivis quotidiens.

Supposons que je contrôle l'application n°8 ce matin On aura comme identifiant 81. Si demain matin, je reviens et recontrôle l'application 8, j'aurai de nouveau 81, et cela ne passera pas.

Ajouter des rubriques /champs supplémentaires à ma table période obligera l'utilisateur à saisir une nouvelle période avant chaque suivi qu'il souhaite effectuer de nouveaux contrôles. Cela serait contraignant pour l'utilisateur.

Cordialement.

[vmolines]

Je pensais que la que PERIODE servait la problématique des contrôles quotidiens, hebdos, mensuels, mais en fait il peut aussi s'agir d'un découpage plus fin que la journée.

La solution marche parfaitement pour peu que DATEDEBUT et DATEFIN soient de type "dateheure". Ceci dit, vous avez bien compris, cette solution impose la création des périodes. Mais qui dit que l'utilisateur qui effectuera la saisie du contrôle devra saisir les périodes ? Il est parfaitement possible et conseillé, si on utilise un tel modèle, de pré insérer les données de périodes. Car je suppose qu'elles sont connues d'avance. Ensuite, avec une simple saisie de la date actuelle (ou l'interrogation de la date système), vous pouvez proposer à l'utilisateur les périodes concernées.

Il n'y aura pas de doublon sur deux contrôles effectués un matin car chaque "matin" figurera en tant que période différente. Exemple :

Ce matin : "2011-08-31 08:00" -> "2011-08-31 12:00"
Demain matin : "2011-09-01 08:00" -> "2011-09-01 12:00"

Cependant, je ne dis pas que cette solution est la mieux adaptée à votre besoin. Il y a d'autres manières de modéliser mais il faudrait aller dans le détail.

L'utilisation de telles tables que j'appellerais "calendrier" est malheureusement sous utilisé car il est à tort mal perçu.

[vmolines]

L'application ne contient pas de période par date, mais par nom.
On a ainsi PERIDODE(IDPeriode, NomApplication).

Je rebondis sur ce point qui me parait étrange.

On associe à une période un nom d'application ?! Pourtant vous spécifiez initialement un #IDAPPLICATION dans la table CONTROLE. Hors si référence vers la table APPLICATION il y a, table APPLICATION il y a. Et je trouverai étrange que le nom de l'application n'y figure pas mais figure plutôt dans la table PERIODE.

Bref, ça sent toujours le raté de modélisation.

[gouzou38]

Merci pour votre réponse.
Pour répondre à votre dernière remarque, il s'agit d'une erreur d'inattention. Je voulais écrire PERIODE (IDPeriode, NomPeriode) bien évidemment.
NomApplication apparait dans la table Application reliée elle, à la table Controle. D'où le IDApplication dans la table Controle.

Je vous remercie aussi pour votre explication suite à mes précisions. Je prends note, je vais voir ce que je peux faire, mais cela me parait un peu compliqué à mettre en oeuvre.

Cordialement.