Discussion :

[CinePhil]

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 ?

[CinePhil]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Artemus24]

Salut 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.

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.

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).

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.

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.

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,"

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

@+

[CinePhil]

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).

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).

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.

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 !

[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

[CinePhil]

@escartefigue, voir ma première discussion sur le sujet

[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 :

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

[Artemus24]

Salut 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.

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.

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.

@+

[CinePhil]

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.

[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.

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.

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.

@+