Trigger qui empêche l'insertion selon une condition

Version imprimable

16/10/2018, 10h32
CinePhil

Trigger qui empêche l'insertion selon une condition

Bonjour,

Soit les tables suivantes :
te_personne_prs (prs_id, prs_nom)
th_personne_physique_pph (pph_id_personne, pph_nom_usuel, pph_id_civilite)
th_personne_morale_pmr (pmr_id_personne, pmr_raison_sociale...)

Les tables th_* héritent de te_personne_prs.
Je crée des procédures pour enregistrer directement les personnes physiques et morales qui créent la te_personne_prs mère.
Je voudrais empêcher la création directe d'une te_personne_prs. J'ai pensé à un TRIGGER AFTER INSERT qui contrôlerait qu'il y a bien une th_personne_physique ou une th_personne_morale correspondante et qui, sinon, annulerait l'insertion.

1) D'après mes petites recherches, on ne peut pas faire de ROLLBACK dans un trigger chez MySQL. Comment faire alors pour annuler l'insertion ?
2) Est-ce que ce que je souhaite faire est possible ?
C'est à dire :
Procédure de création d'une personne physique (ou morale) :
-- start transaction
-- création d'une te_personne_prs
-- création de la personne physique (ou morale) en réutilisant l'id de la personne
-- si erreur sur une clé étrangère dans la personne physique (ou morale) ROLLBACK
-- sinon COMMIT

Et ma supposition dans la création du trigger AFTER INSERT sur te_personne_prs serait qu'il n'opère qu'après le COMMIT de la procédure de création d'une personne physique (ou morale). Est-ce bien comme ça que ça pourrait fonctionner ?

J'ai essayé avec un SIGNAL mais ça bloque toute insertion, même si je fournis de bonnes données à la procédure de création d'une personne physique :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
BEGIN
 IF (
     SELECT COUNT(*)
     FROM th_personne_physique_pph
     WHERE pph_id_personne = NEW.prs_id) = 0 
     AND 
     (
     SELECT COUNT(*)
     FROM th_personne_morale_pmr
     WHERE pmr_id_personne = NEW.prs_id
     ) = 0 THEN
     SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Annulation de l''insertion pour cause de non correspondance de personne physique ou morale';
     END IF;
END

Salut CinePhil.

Citation:

Envoyé par CinePhil

Je voudrais empêcher la création directe d'une te_personne_prs.

Si j'ai bien compris le problème, vous ne pouvez pas le faire. Pourquoi ? Parce que vous prenez le problème à l'envers.
Avant même de créer les personnes physiques et morales, vous devez en premier créer la personne (mère) servant par la suite à l'héritage des tables physiques et morales.

Si vous inversez l'ordre, un autre utilisateur peut très bien créer la personne (mère) dont vous aurez besoin et vous vous retrouverez bloqué par cette situation.

Citation:

Envoyé par CinePhil

J'ai pensé à un TRIGGER AFTER INSERT qui contrôlerait qu'il y a bien une th_personne_physique ou une th_personne_morale correspondante et qui, sinon, annulerait l'insertion.

Vous désirez défaire ce qui a été fait par un autre. C'est pas très logique comme façon de procéder.

Le mieux est de se réserver ce droit (par anticipation), quitte à le supprimer par la suite, si pour une raison ou une autre, vous devez annuler votre transaction.

Citation:

Envoyé par CinePhil

D'après mes petites recherches, on ne peut pas faire de ROLLBACK dans un trigger chez MySQL.

Le problème ne se situe pas là. Il y a un ordre à respecter dans la création de vos lignes.

C'est comme si vous désirez créer une ligne dans une table fille (donc une clef étrangère) avant même d'avoir la ligne de référence dans la table mère (son identifiant).

Citation:

Envoyé par CinePhil

Comment faire alors pour annuler l'insertion ?

Comme je l'ai dit précédemment, vous prenez le problème à l'envers.
La meilleure façon d'annuler une insertion est d'empêcher tout simplement l'insertion de se faire.

Citation:

Envoyé par CinePhil

Procédure de création d'une personne physique (ou morale) :
-- start transaction
-- création d'une te_personne_prs
-- création de la personne physique (ou morale) en réutilisant l'id de la personne
-- si erreur sur une clé étrangère dans la personne physique (ou morale) ROLLBACK
-- sinon COMMIT

Vous n'avez pas bien compris la notion de grappe de données.
En premier lieu, vous devez disposer de tous les éléments pour créer ce dont vous avez besoin.
A partir de ce moment, il est facile de respecter l'ordre de la création de toutes les lignes dans vos tables.

1) faire un start transaction.

2) créer la personne (mère).
(L'identifiant existe, sauf qu'au lieu d'être enregistré physiquement dans la table, il l'est dans le journal des transactions.
Si vous annulez cet identifiant, par un rollback, il ne sera plus jamais utilisé, car mysql l'aura incrémenté).

3) création de la personne physique
ou bien
4) création de la personne morale.

5) il ne peut pas y avoir d'erreur sur la clef étrangère. Pourquoi ?
A cause du fonctionnement de l'identifiant dans MySql.
Il y a une sérialisation de cet identifiant pour chaque utilisateur.
Autrement dit, deux utilisateurs qui font la même demande auront deux valeurs différentes, par exemple 25 pour l'un et 26 pour l'autre.

Citation:

Envoyé par CinePhil

Et ma supposition dans la création du trigger AFTER INSERT sur te_personne_prs serait qu'il n'opère qu'après le COMMIT de la procédure de création d'une personne physique (ou morale).

Il n'y a aucun besoin de déclencheur pour ce que vous désirez faire !

Je répète que l'identifiant que vous demandez est un numéro séquentiel technique que MySql va gérer pour vous.
Par exemple ceci "`id` integer unsigned not null auto_increment primay key,"

Citation:

Envoyé par CinePhil

Est-ce bien comme ça que ça pourrait fonctionner ?

Justement pas. Vous avez une mauvaise compréhension du fonctionnement de MySql, peut-être même des SGBDR en général.

Voici un exemple qui fonctionne correctement.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 -------------- START TRANSACTION -------------- -------------- DROP DATABASE IF EXISTS `base` -------------- -------------- CREATE DATABASE `base` DEFAULT CHARACTER SET `latin1` DEFAULT COLLATE `latin1_general_ci` -------------- -------------- COMMIT -------------- -------------- DROP TABLE IF EXISTS trav -------------- Note (Code 1051): Table 'base.trav' inconnue -------------- CREATE TABLE `trav` ( `id` integer unsigned not null auto_increment primary key, `type` varchar(255) not null, `nom` varchar(255) null, `prenom` varchar(255) null, `raison` varchar(255) null, `adresse` varchar(255) not null, `erreur` boolean not null ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED -------------- -------------- LOAD DATA INFILE 'E:/30.MySql/70.Procedure/Ex_22/fichier.txt' INTO TABLE `trav` CHARACTER SET latin1 FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' ESCAPED BY '\\' LINES TERMINATED BY '\r\n' IGNORE 0 LINES (@F1,@F2,@F3,@F4,@F5,@F6) SET `type` = trim(@F1), `nom` = trim(@F2), `prenom` = trim(@F3), `raison` = trim(@F4), `adresse` = trim(@F5), `erreur` = case trim(@F6) when 0 then false else true end -------------- -------------- select * from trav -------------- +----+----------+----------+---------+-------------------+---------------------------+--------+ | id | type | nom | prenom | raison | adresse | erreur | +----+----------+----------+---------+-------------------+---------------------------+--------+ | 1 | physique | dupontel | albert | | chez lui | 0 | | 2 | morale | | | les grands hommes | place des quinconces | 1 | | 3 | personne | martel | charles | | avenue de la république | 0 | | 4 | physique | dujardin | jean | | théatre de la michaudière | 0 | | 5 | morale | | | microsoft | Microsoft Redmond Campus | 0 | +----+----------+----------+---------+-------------------+---------------------------+--------+ -------------- DROP TABLE IF EXISTS `personne` -------------- Note (Code 1051): Table 'base.personne' inconnue -------------- CREATE TABLE `personne` ( `id` integer unsigned NOT NULL auto_increment primary key, `adresse` varchar(255) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED -------------- -------------- DROP TABLE IF EXISTS `physique` -------------- Note (Code 1051): Table 'base.physique' inconnue -------------- CREATE TABLE `physique` ( `id` integer unsigned NOT NULL auto_increment primary key, `nom` varchar(255) NOT NULL, `prenom` varchar(255) NOT NULL, `physique_clef` integer unsigned NOT NULL, CONSTRAINT `FK_PHYSIQUE` FOREIGN KEY (`physique_clef`) REFERENCES `personne` (`id`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED -------------- -------------- DROP TABLE IF EXISTS `morale` -------------- Note (Code 1051): Table 'base.morale' inconnue -------------- CREATE TABLE `morale` ( `id` integer unsigned NOT NULL auto_increment primary key, `raison` varchar(255) NOT NULL, `morale_clef` integer unsigned NOT NULL, CONSTRAINT `FK_MORALE` FOREIGN KEY (`morale_clef`) REFERENCES `personne` (`id`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED -------------- -------------- commit -------------- -------------- DROP PROCEDURE IF EXISTS `remplissage` -------------- Note (Code 1305): PROCEDURE base.remplissage does not exist -------------- CREATE PROCEDURE `remplissage` () BEGIN DECLARE _fin INTEGER DEFAULT 1; DECLARE _id INTEGER DEFAULT NULL; DECLARE _msg VARCHAR(255) DEFAULT NULL; DECLARE _rang integer DEFAULT NULL; DECLARE _type varchar(255) DEFAULT null; DECLARE _nom varchar(255) DEFAULT null; DECLARE _prenom varchar(255) DEFAULT null; DECLARE _raison varchar(255) DEFAULT null; DECLARE _adresse varchar(255) DEFAULT null; DECLARE _erreur varchar(255) DEFAULT null; DECLARE _tab CURSOR FOR SELECT `id`,`type`,`nom`,`prenom`,`raison`,`adresse`,`erreur` FROM `trav`; DECLARE CONTINUE HANDLER FOR NOT FOUND SET _fin = 0; OPEN _tab; FETCH _tab INTO _rang,_type,_nom,_prenom,_raison,_adresse,_erreur; WHILE (_fin) DO start transaction; BEGIN DECLARE abort CONDITION FOR SQLSTATE '01000'; DECLARE EXIT HANDLER FOR abort BEGIN ROLLBACK; RESIGNAL; SHOW WARNINGS; END; insert into `personne` (`adresse`) values (_adresse); SET _id = last_insert_id(); case _type when 'physique' then insert into `physique` (`nom`,`prenom`,`physique_clef`) values (_nom, _prenom, _id); when 'morale' then insert into `morale` (`raison`, `morale_clef`) values (_raison, _id); else begin set _msg = concat('Type de personne inconnue, Rang= ',_rang); signal abort set message_text=_msg, mysql_errno=1; end; end case; if _erreur is true then set _msg = concat('Erreur provoquée, Rang=',_rang); signal abort set message_text=_msg, mysql_errno=2; end if; commit; END; FETCH _tab INTO _rang,_type,_nom,_prenom,_raison,_adresse,_erreur; END WHILE; END -------------- -------------- COMMIT -------------- -------------- call `remplissage`() -------------- +---------+------+--------------------------+ | Level | Code | Message | +---------+------+--------------------------+ | Warning | 2 | Erreur provoquée, Rang=2 | +---------+------+--------------------------+ +---------+------+------------------------------------+ | Level | Code | Message | +---------+------+------------------------------------+ | Warning | 1 | Type de personne inconnue, Rang= 3 | +---------+------+------------------------------------+ -------------- select * from `personne` -------------- +----+---------------------------+ | id | adresse | +----+---------------------------+ | 1 | chez lui | | 4 | théatre de la michaudière | | 5 | Microsoft Redmond Campus | +----+---------------------------+ -------------- select * from `physique` -------------- +----+----------+--------+---------------+ | id | nom | prenom | physique_clef | +----+----------+--------+---------------+ | 1 | dupontel | albert | 1 | | 2 | dujardin | jean | 4 | +----+----------+--------+---------------+ -------------- select * from `morale` -------------- +----+-----------+-------------+ | id | raison | morale_clef | +----+-----------+-------------+ | 2 | microsoft | 5 | +----+-----------+-------------+ -------------- COMMIT -------------- Appuyez sur une touche pour continuer...
Je charge dans une table de travail, un fichier de type ".csv".

Dans cet exemple, je vais charger trois tables : "personne", "physique" et "morale" selon les colonnes respectives, à partir de la table travail.
Il y a deux erreurs possibles, soit selon le code erreur dans le fichier, soit le type "personne" qui n'existe pas dans le traitement (on attend soit "physique" ou soit "morale").

J'ai cherché à afficher un "warning" et je ne suis pas arrivé à le faire et je ne sais pas pourquoi les warnings ne s'affichent pas chez moi !
La solution que j'ai adopté est de faire à la place, un "select" (au lieu du resignal sur un warning) du message d'erreur que je désire afficher.

On remarque que dans la table "personne", il y a seulement trois lignes.
On retrouve bien la valeur du "id" dans la table "physique" (1 & 4) et dans la table "morale" (5).

EDIT: j'ai modifié le traitement afin que le "handler scope" soit dans un bloc au lieu d'être global à la procédure stockée.
Pour gérer correctement les anomalies, ceux-ci doivent être de types warnings.
Ce qui provoque, non pas la sortie de la procédure stockées, mais la sortie du bloc.
J'ai trouvé le moyen d'activer les warnings. Ce qui donne, pour chaque resignal, un message à l'affichage.

@+

18/10/2018, 09h37
CinePhil

Citation:

Si j'ai bien compris le problème, vous ne pouvez pas le faire. Pourquoi ? Parce que vous prenez le problème à l'envers.
Avant même de créer les personnes physiques et morales, vous devez en premier créer la personne (mère) servant par la suite à l'héritage des tables physiques et morales.

C'est ce qui est prévu par ma procédure de création d'une personne-physique (et plus tard par ma future procédure de création d'une personne morale).

Citation:

Si vous inversez l'ordre, un autre utilisateur peut très bien créer la personne (mère)

C'est justement ce que je souhaite empêcher.
Je souhaite que la procédure de création d'une personne physique (ou morale) soit le seul canal de création d'une personne (table mère te_personne_prs).

Citation:

5) il ne peut pas y avoir d'erreur sur la clef étrangère.

Il ne s'agit pas de la clé étrangère référençant la table mère te_personne_prs mais une autre clé étrangère :
- dans le cas de la personne physique, c'est l'identifiant référençant sa civilité (Monsieur, Madame, Professeur...) ;
- dans le cas de la personne morale, ça pourra être l'identifiant de son type (SARL, SA, Etablissement public, Association...).
Dans les deux cas, la valeur de cette clé étrangère sera fournie à la procédure par l'application et cette valeur peut potentiellement ne pas figurer dans la table référencée, ce qui déclenchera une erreur. Cette erreur est capturée par la procédure et redonnée à l'application pour être traitée en tant que message d'erreur clair envoyé à l'utilisateur.

Citation:

Il y a une sérialisation de cet identifiant pour chaque utilisateur.
Autrement dit, deux utilisateurs qui font la même demande auront deux valeurs différentes, par exemple 25 pour l'un et 26 pour l'autre.

Merci mais je connais le fonctionnement des clés auto-incrémentée ! :mrgreen:
18/10/2018, 10h38
escartefigue

Bonjour,

Pas besoin de trigger, il suffit de gérer les commit/rollback dans la procédure stockée qui fera l'ajout dans les différentes tables
18/10/2018, 10h42
CinePhil

@escartefigue, voir ma première discussion sur le sujet :calim2:
18/10/2018, 11h57
escartefigue

Effectivement je n'avais pas vu cet autre fil

Ma réponse est du même acabit : il ne faut pas "commiter" dans les procédures appelées, mais de remonter la transaction au niveau global pour exécuter le COMMIT/ROLLBACK sur l'ensemble.

Quant à la question sur les droits posée dans l'autre fil :

Citation:

Envoyé par CinePhil

Question :
Si je crée un user MySQL/MariaDB qui a le privilège d'exécution sur P2 mais pas sur P1, mon processus ci-dessus fonctionne t-il ?
Ceci me permettrait d'empêcher l'exécution directe de la procédure P1 et donc de sécuriser mes données en n'ayant pas des personnes physiques "fantômes" qui ne seraient ni des candidats, ni des utilisateurs, ni un autre type de personne physique prévu par la BDD (contrainte de totalité sur les héritages de th_personne_physique à respecter).
Cette question est davantage pour ma culture personnelle, dans un premier temps, parce que de toute façon, la base de données ne sera accessible par les utilisateurs que via l'application.

Là aussi, il faut que le COMMIT/ROLLBACK soit géré en dehors des procédures qui font les insertions. D'une façon générale la transaction est en amont de l'appel à ces procédures

User1 : start transaction ==> appel proc1 ==> appel proc2 ==> retour proc1 ==> retour transaction avec commit ou rollback
User2 : start transaction ==> appel proc2 ==> retour transaction avec commit ou rollback
19/10/2018, 03h15
Artemus24

Salut CinePhil.

Citation:

Envoyé par CinePhil

C'est justement ce que je souhaite empêcher.

Comment un autre utilisateur pourrait créer la personne (mère) avant vous ?
En gros, je comprends que vous-même et cet autre utilisateur auraient les mêmes informations à traiter.
Ceci est une gestion de l'attribution des dossiers aux utilisateurs et non un problème informatique.

Citation:

Envoyé par CinePhil

Je souhaite que la procédure de création d'une personne physique (ou morale) soit le seul canal de création d'une personne (table mère te_personne_prs).

Dans l'exemple que je vous ai donné, je suis le seul à traiter le fichier ".csv".
Comme le remplissage des tables se fait selon leur identifiant, il est vrai que si un autre utilisateur ou vous-même, traitez une seconde fois le même fichier, il y aura duplication de ces données dans la base.

Ce que je ne comprends pas trop, est l'unicité de la personne d'une part vis-à-vis de la personne physique ou morale que vous êtes en train de traiter et d'autre part vis-à-vis d'une autre personne physique ou morale qui aurait déjà été traité.
Si la cause est la duplication, dans ce cas, c'est à vous de rejeter le travail que vous êtes en train de faire. Pourquoi ? La personne est déjà présente dans la base.
Si la cause provient d'un conflit entre cet autre personne et celle dont vous traitez, je pense que le problème n'est pas informatique mais fonctionnelle.

La seule façon de rendre ce canal unique donc unicté de la personne (mère) au sein de votre base, je pense que vous devez utiliser la fonction de hashage.
La duplication n'est pas possible car la même personne aura nécessairement la même empreinte.

Ou plus simplement, faire de l'organisation en faisant en sorte que le dossier à traiter soit attribué à un seul gestionnaire.

Vous me demandez de répondre à une question, dont je ne comprends pas trop le sens de l'implication informatique qui en découle.

Citation:

Envoyé par CinePhil

Cette erreur est capturée par la procédure et redonnée à l'application pour être traitée en tant que message d'erreur clair envoyé à l'utilisateur.

Ce n'est pas nécessairement une erreur mais plutôt une absence d'information.
Et dans ce cas là, vous rejettez la totalité de la personne dans votre base.
N'est-ce pas là la cause de ce que vous nommez "le canal de création d'une personne" ?
Qu'est-ce qui empêche un autre utilisateur que vous de gérer cette personne ?

En fait, vous demandez l'attribution de cette personne (mère) à un gestionnaire (par exemple vous), alors que cette personne n'est identifiée nulle part dans votre base de données.
Selon moi, c'est plus un problème d'organisation de travail qu'un problème informatique.
Dès que la personne a été créé au sein de la base, il suffit d'attribuer un code gestionnaire, pour rendre ce "canal" unique.
Ainsi seul le gestionnaire que a les droits (par les view) pourra modifier ladite personne dans la base.

Pour reprendre votre problème, la création de la grappe de données, à savoir la personne (mère), la personne physique ou la personne morale qui est attachée à cette personne (mère) et toutes les dépendances, doivent se faire selon un traitement tout (commit) ou rien (rollback).
Sur ce point, je pense qu'Escartefigue, SQLPRO et moi-même sommes d'accord.

Parfois cette approche peut-être un peu trop compliquée à mettre en oeuvre car il manque toujours des informations pour finaliser la création, ce qui ferait que cette personne ne serait jamais validée dans la base de données.
Une possible solution serait d'avoir deux bases de données, l'une définitive et l'autre en cours de finalisation de la personne (mère) avec ses dépendances.
Quand elle est définitivement validées par un gestionnaire, alors là oui, vous pouvez basculer vers la base définitive.
Chaque partie qui est en cours de traitement aura pour identifiant, celui du gestionnaire et un numéro temporaire que l'on attribue à cette personne.
C'est durant le basculement vers la base définitive que vous devez attribuer un identifiant définitif.

Ce n'est pas un problème informatique, mais plutôt une organisation du travail autour de la finalisation par étape de cette personne.
Normalement vous devez avoir les spécificités fonctionnelles qui doivent vous expliquer comment faire.
Ce qui implique une modélisation de votre base de données.

@+
19/10/2018, 09h00
CinePhil

Citation:

Comment un autre utilisateur pourrait créer la personne (mère) avant vous ?
En gros, je comprends que vous-même et cet autre utilisateur auraient les mêmes informations à traiter.

Non, vous n'avez pas compris.

En gros, j'ai le MCD suivant :
th_personne_physique_pph -(1,1)----être----0,1- te_personne_prs
th_personne_morale_pmr -(1,1)----être----0,1--------------|

Il s'agit d'un héritage des personnes vers les personnes physiques ou morales avec, bien entendu, une contrainte de totalité : toutes les personnes doivent figurer dans les personnes physiques et/ou morales.
Je souhaite donc empêcher la création d'une personne directement pour respecter la contrainte de totalité. Je ne veux pas avoir une personne P qui ne soit ni dans la table des personnes physiques ni dans la table des personnes morales. Toute création de personne devra se faire via la création d'une personne physique ou via la procédure de création d'une personne morale.

Je cherche le moyen d'empêcher un banal INSERT INTO te_personne_prs qui serait lancé hors procédure.
19/10/2018, 18h32
Artemus24

Salut CinePhil.

J'ai bien compris que les tables physiques et morales héritent de la table personne.
Sauf que vous abordez des problèmes qui sont différents à chaque fois.

Citation:

Envoyé par CinePhil

Je cherche le moyen d'empêcher un banal INSERT INTO te_personne_prs qui serait lancé hors procédure.

Il y a deux solutions possibles pour restreindre les privilèges à une tables.

1) par les "view", où l'on est capable de restreindre plus finement aux colonnes et aux lignes.
2) par les "grant" en interdisant l'accès, pour tous, aux tables qui posent problèmes, sauf pour un unique utilisateur.

Dans les deux cas, il faudra gérer dans l'application l'identification de l'utilisateur.
Voire gérer deux applications, l'une ayant un compte d'accès pour tous les utilisateurs et interdisant les accès aux tables qui posent des problèmes.
L'autre application, aura un compte avec un accès privilégie sur vos trois tables.

Citation:

Envoyé par CinePhil

Je souhaite donc empêcher la création d'une personne directement pour respecter la contrainte de totalité.

MySql sait gérer une clef étrangère présente dans les tables physique et morale et qui pointe sur la table personne.
Ce que vous demander, c'est de gérer une clef étrangère présente dans la table personne et qui pointe vers les tables physique et morale.
Je sais que Microsoft SQL Server sait gérer cela, mais pas MySql.
Dans le second cas, il y aura un blocage dans la création des tables sous MySql.

Maintenant quel est l'intérêt de créer une contrainte double entre d'un part la table personne et d'autre part les tables physique et morale ?
MySql ne sait gérer au travers des clefs étrangères que les contraintes montantes.
C'est-à-dire qu'une ligne existe dans une table fille que si et seulement si la clef étrangère est présente dans la table mère.
Par contre, il n'y a pas de contrainte sur l'existence de la ligne dans la table mère.
Si celle-ci n'est pas présente dans une table fille, et bien MySql s'en fout.

Je parle bien de contrainte technique dans MySql.
Sinon, au moment des insertions dans les tables physique et morale, s'assurer qu'il n'existe pas de personne (mère) déjà présente.
C'est une contrainte fonctionnelle qui peut se traiter par un simple "select".
Sauf que pour réaliser cela, il faudrait un critère (autre que les clefs étrangères) qui devrait être présent aussi bien dans la table personne que dans les tables physique et morale.
Et que ce critère soit unique ! Une contrainte pas très utile, et redondante vis-à-vis de la clef étrangère.

Le plus simple est de confier ce travail à un seul utilisateur qui sera le seul à être habilité à le faire.
D'où la contrainte par "grant" sur les tables personne, physique et morale.

A part cela, je ne vois pas de solution simple à votre problème.

@+