Discussion :

[ClayStone]

Bonjour,

Je dispose d’une base de donnée comportant deux groupes de tables distincts (en fait, il s’agissait historiquement de deux bases indépendantes association et bibliographie)
Le premier groupe de tables (association) assure la gestion interne d’une association, et contient une table t_membre (id_membre, nom, prenom, etc1.).
Le second groupe de tables (bibliographie) gère une bibliographie et contient une table t_auteur (id_auteur, nom, prenom, etc2.)
Les auteurs peuvent être, ou non, membres de l’association, mais ce n’est renseigné nulle part dans ce groupe de table.

Aujourd’hui, il nous devient nécessaire de pouvoir accéder aux informations contenues dans le groupe de tables association depuis le groupe bibliographie et vice versa.
Par exemple,
- accéder aux informations internes à l’association (cotisation, adresses...) d’un auteur (si il est membre) à partir d’une recherche de ce qu’il a écrit,
ou inversement,
- accéder aux publications d’un membre à partir d’une recherche dans les infos présentes coté association.

L’idée serait de
- créer une liaison/relation entre les deux groupes de tables via ces deux tables t_membre et t_auteur
- éviter les redondances et les aberrations : actuellement, l’identité d’un membre auteur est renseignée sous deux id différentes dans chacune des deux tables (id_membre et id_auteur)

Une solution envisagée serait de créer une table de relation t_individu entre t_membre et t_auteur, après avoir supprimé de la table t_auteur toutes les lignes dont l’auteur est aussi membre de l’association. Cette table serait alimentée à chaque nouvelle saisie d’un auteur, qu’il soit membre ou non.

t_individu
id_individu (pk, auto incrementée)
id_membre (fk t-membre, NULL si is_membre est FALSE)
id_auteur (fk t_auteur, NULL si is_membre est TRUE)
is_membre (booléen)


Cette solution est-elle optimale ?
Y-a-t-il mieux à faire ? (passer par CREATE VIEW par exemple ?)

Merci d’alimenter ma réflexion !

P.s.
Je travaille avec MariaDB / mysql php
Pour des raisons sur lesquelles je ne m’entendrai pas, il n’est pas question de toucher à la table t_membre
Hormis les informations des deux tables d’identité t_membre et t_auteur, aucune information issue des deux groupes de tables n’est redondante.
Ma connaissance en matière de base de donnée est empirique et ma méthodologie est issue de celle du bon professeur "Al. Harasch"

[escartefigue]

Bonjour,

La description est succincte, mais quoi qu'il en soit, je préfère une solution consistant à identifier les vrais doublons fonctionnels (en rapprochant les membres et les auteurs)
Ensuite, créez une table "individu" pour les attributs communs aux membres et aux auteurs, puis, si nécessaire, un sous-type "auteur" et/ou un sous-type "membre" pour les attributs spécifiques

Une difficulté est d'identifier les vrais doublons fonctionnels, le trio nom/prénom/date de naissance n'est pas suffisamment fiable et des valeurs légèrement différentes sur ces critères peuvent parfois porter sur un même individu (ex : erreur d'orthographe, trait d'union...)

[ClayStone]

Merci Escartefigue,

La description est succincte

En effet. Pour l'être un peu moins, voici un shéma très simplifié de la base actuelle :

Une difficulté est d'identifier les vrais doublons fonctionnels

Je pars de l'hypothèse que c'est fait et que les auteurs qui sont membres ont été supprimés de la table t_auteur, qui s’appellera désormais t_non_membre.

créez une table "individu" pour les attributs communs aux membres et aux auteurs

Je ne suis pas sûr d'avoir le bon vocabulaire...
A priori, le seul attribut commun (ici) serait avoir rédigé un article.
Est-ce que quelque chose comme ça pourrait fonctionner ? Et si oui, est-ce qu'il existe un moyen pour forcer id_membre ou (exclusif) id_non_membre à être null (selon si il s'agit d'un membre ou d'un non-membre) dans t_individu pour gérer le cas où id_membre et id_non_membre auraient la même valeur?

Sinon, pourrais-je envisager ça (et is_membre est-il utile, toujours pour distinguer un membre d'un non-membre qui auraient un id de même valeur) ?

[escartefigue]

Votre modèle logique implique les règles de gestion suivantes :

R001a : un même membre peut avoir plusieurs fonctions
R001b : une même fonction peut être attribuée à plusieurs membres

R002a : un même auteur peut écrire plusieurs articles
R002b : un même article peut avoir plusieurs auteurs

R003a : un article ne fait l'objet que d'une seule édition (voire aucune édition, non décelable sur votre schéma)
R003b : une édition peut concerner un à plusieurs articles

est-ce correct ? sinon le MLD est à revoir

À préciser :
- les fonctions exercées par un membre sont elles immuables ou variables dans le temps ?
- un membre peut il n'avoir aucune fonction (comme dans le MCD proposé ci-dessous) ou obligatoirement au moins une ?


Par ailleurs, vu que t_membre comporte les attributs nom, prenom et matricule et que t_auteur comporte les attributs nom, prenom et remarque, alors nom et prenom sont des attributs communs aux deux tables.
C'est ici que la modélisation par héritage peut être utilisée

Voici un exemple de modèle

Au niveau conceptuel (réalisé avec Looping)

Pièce jointe 581848

Si un individu peut être à la fois membre et auteur, alors la contrainte n'est pas de type XT mais de type T (à adapter selon votre cas)

Ce qui donne le script suivant :

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
CREATE TABLE IN_individu(
   IN_ident COUNTER,
   IN_nom VARCHAR(50) NOT NULL,
   IN_prenom VARCHAR(50) NOT NULL,
   PRIMARY KEY(IN_ident)
);

CREATE TABLE AU_auteur(
   IN_ident INT,
   AU_remarque VARCHAR(255),
   PRIMARY KEY(IN_ident),
   FOREIGN KEY(IN_ident) REFERENCES IN_individu(IN_ident)
);

CREATE TABLE MB_membre(
   IN_ident INT,
   MB_matricule DECIMAL(7,0) NOT NULL,
   PRIMARY KEY(IN_ident),
   UNIQUE(MB_matricule),
   FOREIGN KEY(IN_ident) REFERENCES IN_individu(IN_ident)
);

CREATE TABLE FO_fonction(
   FO_ident COUNTER,
   FO_code CHAR(4) NOT NULL,
   FO_libelle VARCHAR(128) NOT NULL,
   PRIMARY KEY(FO_ident)
);

CREATE TABLE exercer(
   IN_ident INT,
   FO_ident INT,
   PRIMARY KEY(IN_ident, FO_ident),
   FOREIGN KEY(IN_ident) REFERENCES MB_membre(IN_ident),
   FOREIGN KEY(FO_ident) REFERENCES FO_fonction(FO_ident)
);

[ClayStone]

Merci, Je n'en attendais pas tant !
Les règles de gestion sont correctes, et un article doit faire l'objet d'une édition et une seule.

- les fonctions exercées par un membre sont elles immuables ou variables dans le temps

variables

- un membre peut il n'avoir aucune fonction

oui

Ceci dit, je n'avais pas dû être très clair dans mon premier post, il n'est pas envisagé (pour ne pas dire inenvisageable) de modifier la table t_membre, tant en structure qu'en données.

Je comprends mieux l'expression "attributs communs" et hélas, malgré les attributs nom et prenom communs aux deux tables membre et non-membre, il me faut garder ces deux tables distinctes.

Une précision, il s'agit d'une association familiale, et la base contient la généalogie.
La partie association comprend la gestion des membres de l'association ET la gestion de la base généalogique. Cette partie est déjà créée, elle est en service, et elle fonctionne correctement. Il est interdit d'y toucher

On peut en revanche modifier la partie bibliographie si besoin est.

Je commence à comprendre que ma question se heurte aux bonnes pratiques.

Si la théorie s'y oppose, le terrain impose que l'insertion de personnes externes à la famille (pour la bibliographie par exemple) dans la base ne se fasse que par une nouvelle table.
D'où mon insistance à avoir une table des non-membres. (peut-etre sur le modèle d'une base commerciale contenant une table client et une table fournisseur, où un fournisseur ne serait jamais client et un client jamais fournisseur, mais où clients et fournisseurs pourraient être chacun invités à un un même evenement...?)
[AJOUT]Du coup :

Si un individu peut être à la fois membre et auteur

avec mes deux tables t_membre et t_non_membre et la table de relation t_article_auteur:
- un membre peut être un auteur d'un article
- un non membre peut être un auteur d'un article
- un membre ne peut pas être un non-membre (et vice versa)
[/AJOUT]

D'où aussi ma difficulté à créer une (ma première option) ou deux (ma deuxième option) tables intermédiaires de relation:
Attribuer 1 ou plusieurs auteurs (membre ou non-membre) à un article
Attribuer 1 ou plusieurs articles à un auteur (membre ou non-membre)

L'une ou l'autre de mes suggestions précédentes peuvent-elles faire l'objet d'un "bricolage" qui fonctionnerait, même sans être orthodoxe ?

[ClayStone]

Bonsoir,
Après un peu de lecture, j'ai commis ceci :

Règles de gestion :

Contenu
un contenu est défini par

• un seul titre obligatoire
• un seul sous-titre optionnel
• une seule remarque optionnelle
• une seule édition optionnelle (obligatoire si type*: revue complete, article ou livre)
• un seul format obligatoire

• un contenu doit correspondre à un ou plusieurs types
• un contenu doit avoir été créé par un ou plusieurs auteurs (individu, anonyme ou inconnu possible)
• un contenu peut mentionner une ou plusieurs personnalités (individu)
• un contenu peut appartenir à un ou plusieurs propriétaires (individu)
• un contenu doit aborder un ou plusieurs thèmes

Edition
une édition est définie par

• une date (de parution, de création) optionnelle (obligatoire si type livre, revue complète, article de revue, archive administrative)
• un numero de parution optionnelle (obligatoire si type revue complète, article de revue)
• un numéro de page optionnel (obligatoire si article de revue)

Une édition doit porter sur un ou plusieurs contenus

Format
un format est défini par

• un libellé obligatoire (image .jpg .png..., texte .pdf .doc, feuille de calcul .xls)

un format peut être attribué un ou à plusieurs contenus (un format peut être «*orphelin*» le temps qu’un contenu compatible soit entré dans la table contenu)

Type
Un type est défini par

• un libellé obligatoire (portrait, paysage, archive administrative, revue, article, livre)

un type doit correspondre à un ou plusieurs contenus

Thème
un theme est définit par

• un libellé de theme général
• un code de theme général
• un libelle de theme détaillé
• un code de theme détaillé

Un thème peut être abordé par un ou plusieurs contenus (un theme peut être «*orphelin*» le temps qu’un contenu compatible soit entré dans la table contenu)

Individu

• un individu doit être apparenté ou non apparenté
• un individu peut avoir créé un ou plusieurs contenus
• un individu peut être le propriétaire d’un ou plusiers contenus
• un individu peut être mentionné dans un ou plusieurs contenus

Individu interne
un individu interne est défini par

• un seul patronyme obligatoire
• un seul prenom obligatoire
• un seul matricule obligatoire
• une ou plusieurs adresses optionnelle
• une date de naissance obligatoire
• une date de décès optionnelle
• etc.

Individu externe
un individu externe est défini par

• un seul patronyme obligatoire
• un seul prenom obligatoire
• une seule remarque optionnelle

Et le MCD :


Qu'en pensez vous ? Merci !

[Paprick]

Bonjour,

Sans rentrer pour le moment sur le fond de la modélisation de votre système d'information, il convient de préciser quelque chose d'essentiel au niveau du MCD.
Vous faites apparaitre les clés étrangères (du moins certaines) dans le MCD : à ce stade de la modélisation, non seulement ce n'est pas utile, mais c'est strictement interdit. En effet, les associations avec leurs cardinalités décrivent parfaitement les dépendances fonctionnelles et, lors de la génération du MLD et du schéma relationnel correspondant, les clés étrangères seront automatiquement rajoutées par la logiciel.
Par ailleurs, certaines rubriques, comme id_adresse ou id_cotis, ne font référence à rien...
La bonne nouvelle est que l'écriture de votre MCD montre votre volonté d'être bien organisé : il faut donc maintenant bétonner ce MCD en respectant les règles de modélisation.
On pourra ensuite revenir sur le fond.

Bonne continuation !

[ClayStone]

Merci Paprick,
J'ai tenté de prendre en compte vos observations et j'en suis là :

J'ai légèrement modifié les règles concernant les individus :
Individu

• un individu doit être apparenté ou (XOR) non apparenté
• un individu peut avoir créé un ou plusieurs contenus
• un individu peut être le propriétaire d’un ou plusieurs contenus
• un individu peut être mentionné dans un ou plusieurs contenus

Individu interne (apparenté)
un individu interne est défini par

• un seul patronyme obligatoire
• un seul prenom obligatoire
• un seul matricule obligatoire
• une date de naissance obligatoire
• une date de décès optionnelle

Individu externe
un individu externe est défini par

• un seul patronyme obligatoire
• un seul prenom obligatoire
• une seule remarque optionnelle

Et le MCD :

[Paprick]

Bonjour,

C'est mieux !
Quelques remarques complémentaires :

• id_edition et id_format ne doivent pas apparaitre dans CONTENU.
• Réserver la notation "id_xxx" aux identifiants : éviter par exemple id_th_gen et id_th_det dans THEME.
• Traiter les liens entre INDIVIDU, INDIVIDU_INT et INDIVIDU_EXT avec l'héritage tel que décrit dans le post ci-dessus de Escartefigue, sachant également que le nom et le prénom sont communs aux 2 classes filles (à mettre donc de préférence dans la classe mère).

Bonne journée.

[ClayStone]

Merci, et pas seulement pour les encouragements
Avec l’héritage par partition conseillé (deux fois, il doit bien y avoir une raison !), j’arrive à ça :

Mais au niveau script (à moins que je n’aie manqué quelque chose), la structure de la table INDIVIDU_INT générée est affectée d’une clé externe supplémentaire par rapport à la table de généalogie-association existante (en plus de la perte des attributs nom et prénom).

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE INDIVIDU_INT(
   id_indiv_int INT,
   matricule VARCHAR(50) NOT NULL,
   date_naissance DATE NOT NULL,
   date_deces DATE,
   id_individu INT NOT NULL,
   PRIMARY KEY(id_indiv_int),
   UNIQUE(id_individu),
   FOREIGN KEY(id_individu) REFERENCES INDIVIDU(id_individu)
);

Or cela m’est matériellement impossible : si j’ai presque toute latitude côté bibliographie, je n’ai pas la main sur cette table INDIVIDU_INT.
Aucune modification effectuée du côté bibliographie ne doit avoir d’incidence sur les tables existantes côté généalogie. Ça n’est pas idéal pour établir une liaison entre les deux anciennes bases, j’en conviens

Puis-je aborder cette difficulté avec une nouvelle entité et cette nouvelle règle ?
un individu présent dans la généalogie peut être référencé une fois au plus dans la bibliographie

Code :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE INDIVIDU_GENEAL(
   id_indiv_geneal INT,
   nom VARCHAR(50) NOT NULL,
   prenom VARCHAR(50) NOT NULL,
   matricule VARCHAR(50) NOT NULL,
   date_naissance DATE NOT NULL,
   date_deces DATE,
   PRIMARY KEY(id_indiv_geneal)
);

La structure de la table existante est conservée, pas de modification au-delà de la limite généalogie / bibliographie

Mais est-ce correct ?

Merci encore pour la suite de vos conseils !

[Paprick]

Bonjour,

Je comprends la contrainte et, effectivement, le premier modèle poserait un problème de rajout d'une clé étrangère dans la table externe...
Votre solution est correcte : on pourra juste regretter que le nom et le prénom vont être redondant... d'ailleurs, n'est-ce pas suffisant de les mettre unique dans INDIVIDU_EXT (vu que INDIVIDU_INT est forcément associé à un INDIVIDU_GENERAL) ?

Et pour rendre votre MCD encore plus adapté à votre situation, vous pouvez déclarer dans Looping que la table INDIVIDU_GENERAL est externe au modèle ; pour cela, donnez-lui un nom logique (en dessous du nom de base) : une case à cocher vous permettra alors de déclarer la table externe avec la représentation en pointillés qui va avec .

[ClayStone]

Bonsoir,
Pour confirmation,
Quelque chose comme ça ?


Quant à la propriété UNIQUE, je n'y suis pas familier,
Cela conviendrait ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE INDIVIDU_EXT(
   id_indiv_ext INT,
   nom VARCHAR(50) NOT NULL,
   prenom VARCHAR(50) NOT NULL,
   rq_ext VARCHAR(50),
   id_individu INT NOT NULL,
   PRIMARY KEY(id_indiv_ext),
   UNIQUE(id_individu),
   UNIQUE(nom),
   UNIQUE(prenom),
   UNIQUE(rq_ext),
   FOREIGN KEY(id_individu) REFERENCES INDIVIDU(id_individu)
);

Les pointillés qui vont bien... ne m'appelez pas Mr Jourdain

[Paprick]

Bonsoir,
Ca se précise .
Concernant l'héritage, en affectant un identifiant aux classes filles, vous avez pris l'option (sans le savoir !) de la généralisation ; or, je verrais plutôt une spécialisation, c'est à dire que les classes filles récupèrent la clé de la classe mère : pour cela, il suffit de ne pas mettre d'identifiant dans les classes filles : Looping se charge du reste. Vous pourrez aussi, si vous le souhaitez, suffixer le nom de la clé étrangère avec "int" et "ext" en utilisant le rôle dans la patte de l'héritage (côté fille).
Concernant l'usage de la contrainte UNIQUE, je ne crois que cela corresponde à ce que vous souhaitez... en effet, en l'état, deux individus ne peuvent pas, par exemple, avoir le même prénom...

[ClayStone]

Création automatique de la clé primaire : Looping est magique !

Je cale sur la définition de la contrainte UNIQUE.
Ce dont j'ai besoin, c'est d'un "triplet" (nom, prenom, rq_ext) unique dans INDIVIDU_EXT (rq_ext pouvant être NULL)
Ça se traduirait par ça ?

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE INDIVIDU_EXT(
   id_individu_ext INT,
   nom VARCHAR(50) NOT NULL,
   prenom VARCHAR(50) NOT NULL,
   rq_ext VARCHAR(50),
   PRIMARY KEY(id_individu_ext),
   UNIQUE (nom, prenom, rq_ext),
   FOREIGN KEY(id_individu_ext) REFERENCES INDIVIDU(id_individu)
);

Si oui, y-a-t-il une astuce pour définir cette contrainte dans Looping ?

[Paprick]

Oui, Looping a prévu ça !
Lorsque vous cochez la case "UNIQUE", une zone "Index" apparait : il suffit de donner le même nom d'index aux 3 rubriques, et le tour est joué !

[fsmrel]

Bonsoir,

Oui, Looping a prévu ça !

Bien vu Paprick, merci du tuyau.

__

ClayStone,

Concernant l’entité-type INDIVIDU_GENE, pas de problème, le singleton {matricule} peut être déclaré comme identifiant alternatif (clause UNIQUE) sans avoir à utiliser la zone "index".

[ClayStone]

Bonjour,

Oui, Looping a prévu ça !

Remerciez-le de ma part quand vous le croiserez

@fsmrel
Merci de m'y avoir fait pensé : matricule étant unique sans la table INDIVIDU_GENEAL, je ne m'y était pas attardé dans INDIVIDU_GENE.

J'en suis là :

et la table INDIVIDU_GENE :

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE INDIVIDU_GENE(
   id_individu_gene INT,
   matricule VARCHAR(50) NOT NULL,
   id_geneal INT NOT NULL,
   PRIMARY KEY(id_individu_gene),
   UNIQUE(id_geneal),
   UNIQUE(matricule),
   FOREIGN KEY(id_individu_gene) REFERENCES INDIVIDU(id_individu),
   FOREIGN KEY(id_geneal) REFERENCES individual(id_geneal)
);

Étant donné que l'association "Etre référencé" génère dans INDIVIDU_GENE la clé étrangère id_geneal provenant de INDIVIDU_GENEAL puis-je

• me passer de matricule dans INDIVIDU_GENE ?
• me contenter de id_geneal comme identifiant alternatif dans INDIVIDU_GENE ?

Code :

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

1
2
3
4
5
6
7
8
CREATE TABLE INDIVIDU_GENE(
   id_individu_gene INT,
   id_geneal INT NOT NULL,
   PRIMARY KEY(id_individu_gene),
   UNIQUE(id_geneal),
   FOREIGN KEY(id_individu_gene) REFERENCES INDIVIDU(id_individu),
   FOREIGN KEY(id_geneal) REFERENCES individual(id_geneal)
);

Suis-je prêt à passer à l'aspect logique ?
Les scripts générés par Looping sont-ils utilisables tels quels avec mysql ?

[fsmrel]

Bonjour,

Les scripts générés par Looping sont-ils utilisables tels quels avec mysql ?

A l’occasion d’autre discussions, J’ai soumis pas mal de scripts à MySQL, et je ne me souviens pas avoir rencontré de problème, sauf dans des cas rares et particuliers (mais contournables) de surclés, dus à la méconnaissance des parents de MySQL quant à la théorie relationnelle.

Lancez vos scripts. Si problème, tenez-nous au courant, on vous aidera à résoudre ça.

[fsmrel]

Mon doigt a appuyé par mégarde sur "Envoyer la réponse". Suite :

Étant donné que l'association "Etre référencé" génère dans INDIVIDU_GENE la clé étrangère id_geneal provenant de INDIVIDU_GENEAL puis-je

• me passer de matricule dans INDIVIDU_GENE ?
• me contenter de id_geneal comme identifiant alternatif dans INDIVIDU_GENE ?

Au stade SQL vous pouvez vous passer de l’attribut matricule dans INDIVIDU_GENE, car par jointure des tables INDIVIDU_GENEAL et NDIVIDU_GENE sur l’attribut id_geneal, vous pourrez toujours récupérer les matricules. Créer une vue (jointure des 2 tables) à cette occasion serait une bonne chose...

[fsmrel]

Un bout de jeu d’essai (MySQL 5.7).
Notez que la table INDIVIDU_GENE (base de données temp) fait référence à la table individual (base de données claystone) de la façon suivante :

FOREIGN KEY(id_geneal) REFERENCES claystone.individual(id_geneal)

Jeu d’essai :

create database if not exists temp ;

use temp ;

drop table if exists INDIVIDU_GENE ;

create database if not exists claystone ;

use claystone ;

drop table if exists individual ;

CREATE TABLE individual(
   id_geneal INT,
   matricule varchar(8)  not null,
   CONSTRAINT INDIVIDUAL_PK PRIMARY KEY(id_geneal),
   CONSTRAINT INDIVIDUAL_AK UNIQUE(matricule)
);

insert into individual (id_geneal, matricule)
values
    (1, 'mat 01')
  , (2, 'mat 02')
  , (3, 'mat 03')
;

select * from individual ;

use temp ;

drop table if exists INDIVIDU_EXT ;
drop table if exists INDIVIDU_GENE ;
drop table if exists INDIVIDU ;


CREATE TABLE INDIVIDU(
   id_Individu INT,
   truc_individu varchar(20),
   CONSTRAINT INDIVIDU_PK PRIMARY KEY(id_Individu)
);

insert into INDIVIDU (id_Individu, truc_individu)
values
    (1, 'truc 1')
  , (2, 'truc 2')
  , (3, 'truc 3')
;
select * from INDIVIDU ;


CREATE TABLE INDIVIDU_GENE(
   id_Individu_gene INT,
   id_geneal INT NOT NULL,
   PRIMARY KEY(id_individu_gene),
   UNIQUE(id_geneal),
   FOREIGN KEY(id_individu_gene) REFERENCES INDIVIDU(id_Individu),
   FOREIGN KEY(id_geneal) REFERENCES claystone.individual(id_geneal)
);

insert into INDIVIDU_GENE (id_individu_gene, id_geneal)
values
    (1, 1)
  , (2, 2)
  , (3, 3)
;
select * from INDIVIDU_GENE ;

CREATE TABLE INDIVIDU_EXT(
   id_Individu INT,
   nom VARCHAR(50) NOT NULL,
   prenom VARCHAR(50) NOT NULL,
   rqExt VARCHAR(50) NOT NULL,
   PRIMARY KEY(id_Individu),
   UNIQUE(nom, prenom, rqExt),
   FOREIGN KEY(id_Individu) REFERENCES INDIVIDU(id_Individu)
);

insert into INDIVIDU_EXT (id_Individu, nom, prenom, rqExt)
values
    (1, 'volfoni', 'raoul', 'rq1')
  , (2, 'volfoni', 'paul', 'rq2')
  , (3, 'volfoni', 'paul', 'rq2bis')  
;
select * from INDIVIDU_EXT ;