Discussion :

[tweetysat]

Bonjour.

Je me posais une petite question.

Supposons que j'ai 2 fichier hfsql f1 et f2.
Dans l'analyse je crée une relation entre les 2.
Disons une relation 1,1 dans les 2 sens.

Dans mon application, si je commence par ajouter un enregistrement dans f1 : erreur d'intégrité. Normal pas d'enregistrement correspondant dans f2.
Et idem forcement avec l'inverse (ajout dans f2).

D'où ma question : comment il faut faire ? Ajouter un hignoreintégrité dans le hajoute. Dans ce cas ça marche mais à quoi bon alors d'ajouter des contraintes d'intégrité ?

Où alors je suis fatigué et je passe à côté d'une évidence

[klbsjpolp]

Bonjour,

Le moyen de le faire c'est effectivement en utilisant le hIgnoreIntégrité. C'est le même principe dans tous les langages.

Pour ne pas utiliser de contrainte je ne suis pas d'accord que c'est inutile. Tu mets des contraintes pour le cas ou tu oublie de valider et non pas pour le cas ou tu choisie explicitement de l'ignorer.

[Bowen]

Dans l'analyse je crée une relation entre les 2.
Disons une relation 1,1 dans les 2 sens.

Rappel Merise : Si tu as une relation 1 - 1 entre deux entités, ça se traduit par un passage à une seule table. Tu ne devrait donc pas avoir deux tables, mais une seule.
Si tu tiens à conserver deux tables, il faut placer les contraintes pour qu'elles ne soient pas bloquantes. En effet, il ne sert à rien de placer une contrainte que tu désactive systématiquement par code. Et ça pose également un problème, car tes données deviennent impossibles à modifier par le centre de contrôle HF.

En clair, regroupe tes deux fichiers, ou place une des contraintes à (0, 1)

[klbsjpolp]

Rappel Merise : Si tu as une relation 1 - 1 entre deux entités, ça se traduit par un passage à une seule table. Tu ne devrait donc pas avoir deux tables, mais une seule.

Je ne suis pas tout à fait d'accord, je ne connais pas Merise (ça n'a pas encore traverser l'Atlantique) mais quand on normalise un modèle entité-relation, il y a l'étape de dénormalisation qui permet de faire ce genre de chose pour optimiser les données (et non les relations).

Un exemple serait une table d'entité qui contient plusieurs types d'entité et donc chaque type nécessite des informations supplémentaire. La normalisation dit que l'on devrait ajouter 50 colonnes même si chaque type n'en utilise que 10. Le bon sens nous dit que ce n'est pas génial comme solution.

En effet, il ne sert à rien de placer une contrainte que tu désactive systématiquement par code.

Elle n'est pas désactivé systématiquement mais seulement lorsque la gestion est bien fait. C'est justement pour les cas où tu l'oublie et que ça plante. Tu ne veux pas d'enregistrements orphelins.

[Bowen]

Oui, en merise ça s'appelle spécialisation, et on se retrouve avec un (0-1/1-1).
J'en ai un exemple dans mon code par exemple :
Une table Tiers
Une table par spécialisation de Tiers : Client, Fournisseur, Transporteur, etc...
Les contraintes sont :

• Chaque tiers peut avoir une des spécialisations (0-1).
• Chaque Client a forcément un tiers (1 - 1).
• Chaque fournisseur a forcément un tiers (1 - 1).
• Chaque Transporteur a forcément un tiers (1 - 1).

Si je mettais une contrainte (1-1) entre Tiers et Client et entre Tiers et Fournisseur, je serais obligé de le désactiver systématiquement avant d'ajouter/modifier un Tiers.

[vmolines]

La solution à ce problème est d'utiliser la déférabilité de contrainte d'intégrité.

Oracle et Postgre (je ne connais que ces bases qui implémentent cette fonctionnalité de la norme) permettent de reporter la vérification d'une contrainte à la fin de la transaction et non à la fin de chaque ordre SQL.

[Bowen]

Effectivement, ça me parait la solution la plus propre, mais je ne crois pas qu'il soit possible de gérer ça en HF.

La solution de SQLPro me semble intéressante.
En un mot, elle consiste à ne pas installer la contrainte, et attaquer systématiquement l'ajout par une procédure stockée transactionnée.
Cette procédure assure l'insertion dans les deux tables en même temps.
Il est possible de créer ce genre de procédure dans HF/CS, mais pas d'y gérer une transaction si son appel est déjà dans une transaction. (pas de transactions imbriquées en HF/CS).

Maintenant, Il ne reste plus qu'à savoir si l'une de ces solutions convient à Tweetysat. Ou s'il a encore besoin de renseignements sur l'une d'elles.
Tweetysat c'est à toi de jouer...

[BiTonio]

Bonjour "petit haut-parleur aigu" (tweeter) ;=) I was just kidding, mate.

Comme le dit BOWEN, ton MLD nest pas bon, car en effet, une relation 1,1 entre deux tables n'a aucun fondement, sauf cas particulier. Je dis bien "sauf cas particulier". Combien de fois n'ai-je entendu: "Ma base n'avance pas","Je préfère utiliser O... plutôt que H.... car rien à voir, l'une marche le feu de Dieu, l'autre pas", etc.
Tout vient de la construction de la base: Le fameux MLD. Et, oui, Merise, est une des bonnes méthodes bien que non limitée à la construction de BdD...
Ceci étant, tu fais une contrainte croisée entre ces deux tables en appliquant le postulat "A doit exister pour créer B" ET "B doit exister pour créer A". Donc sauf à programmer une "levée du contrôle d'intégrité", tu es comme le serpent, tu te mords la queue...
Alors, pour résumer, soit tu poses des intégrités 0,1 soit tu revoies le MLD de ta base. D'ailleurs, petit conseil, si tu en es là avec ta base, je parie un foie de gnou contre un bout de fromage que ta conceptualisation de base est pour le moins "bancale"...

Sorry for that advice which is not a fair one, but merely a tip to remember.

PS: MLD=Modèle logique des données. Après le MCD=Modèle conceptuel des données, et juste avant le MPD=Modèle physique des données...
Arrivée d'air chaud (en Italien dans le texte).

[BiTonio]

Complément à mon message précédent:
Relation [1,1],[1,1] (eh oui, "l'aller" et "le retour", pour banaliser).

@+