avril
2012
Un article de SQLpro
A partir de la question saugrenue d’un internaute « Ou se trouvent les design pattern pour modéliser les données d’une personne ? » j’ai eu envie de montrer ce que pouvait être un modèle de données pour modéliser une personne.
A priori ce modèle MERISE peut paraître complexe, mais :
- On peut le simplifier en ne retenant pas certaines fonctionnalités
- On utilisera des vues afin de simplifier le travail du développeur
1 – MCD PERSONNE
Voici le MCD qui concerne la Personne et qui se découpe en trois parties : la personne physique (être humain), la personne morale (entreprise) et la partie « générique » des personnes, c’est à dire les données communes aux personnes physiques ou morales.
Il n’est pas habituel de faire figurer dans le MCD les colonnes calculées. Néanmoins nous avons jugé plus intéressant de les faire figurer à ce niveau afin que l’utilisateur puisse les prendre en considération dès à présent. Pour ce faire, nous les avons notés avec le mot CALC dans le nom de l’attribut.
Pour une image plus grande, cliquez ici.
NOTA : le MCD a été édité sous Power AMC en notation MERISE et peut aboutir à la génération d’une base de données de n’importe quel SGBDR comme DB2, INFORMIX, InterBase, Access, SQL Server, MySQL, PostGreSQL, Oracle, Sybase, Teradata… entre autres !
A ce stade il nous faut commenter la manière de modéliser…
1 – les entités figurant en jaune sont des entités de référence. Elles ont toutes une forme similaire, c’est à dire composées des mêmes attributs (domaines compris). Leur nom commence systématiquement par T_R_… (R pour Référence).
2 – les entités figurant en vert sont des entités informationnelles, c’est à dire celles qui contiendront les données fonctionnelles de l’application. Leur nom commence systématiquement par T_E_… (E pour Entité).
3 – les entités figurant en rose fuchsia sont des entités de données externes. Elle doivent contenir des données venant de sources externes non directement controlables (dans notre cas liste des pays de l’INSEE, liste des codes postaux…). Leur nom commence systématiquement par T_X_… (X pour Externe).
4 – les associations en rose fuchsia sont des associations de cardinalité 1:1 (un à un).
5 – les associations en mauve sont des associations de cardinalité 1:n (un à plusieurs).
6 – les associations en bleu ciel sont des associations de cardinalité n à m (plusieurs à plusieurs) qui se traduiront en tables de jointure
NOTEZ que les noms des tables sont suffixées par un trigramme (trois lettres) destiné à simplifier leur dénomination et qui doit être unique au sein du modèle. D’autre part les attributs des entités comme des associations reprennent en préfixe le trigramme de l’entité ou de l’association auquel ils appartiennent. Tout ceci étant conforme à la norme expliquée ici http://sqlpro.developpez.com/cours/standards/ et détaillée ici http://www.sqlspot.com/Norme-de-developpement.html
Les entités de référence sont structurées de la manière suivante (XXX représente le trigramme) :
XXX_ID : la clef auto-incrémentée
XXX_CODE : un code synthétique et unique (contrainte d’unicité à prévoir)
XXX_LIBELLE : un libellé explicite
XXX_BASE : un booléen qui indique si la données est propre à la base (et donc non modifiable ni supprimable) ou bien spécifique à l’utilisateur (donc modifiable et supprimable)
XXX_ORDRE : un entier positif permettant de forcer un ordre particulier
1.1 – Explication du modèle
L’entité T_E_PERSONNE_PRS ne contient qu’une clef de type auto incrémentée. Elle sert de racine à l’héritage exclusif entre les personnes physiques et morales. Bien qu’elle apparaisse quasiment vide, elle est en fait nécessaire pour « raccrocher » les entités de contact que sont les téléphones (fixe, fax ou mobile), les mails et les adresses.
L’entité T_E_PERSONNE_MORALE_PMR contient tous les éléments spécifiques d’une personne morale comme sa raison sociale, son enseigne, et ses codes SIREN, établissement (en fait la partie SIRET distinct du SIREN) et NAF. En sus cette entité est liée à l’entité de référence T_R_FORME_JURIDIQUE_FDJ qui permet de préciser la nature de la personne morale (SA, SARL, SAS, EURL, Nom propre, Collectivité Locale, Association…)
L’entité T_E_PERSONNE_PHYSIQUE_PPQ concentre les données de la personne physique et en particulier son nom de naissance (un abus de langage serait de nommer cet attribut nom de jeune fille, car depuis plusieurs années, un homme peut prendre le nom de sa femme au moment du mariage). Le découpage de la date de naissance en trois rubrique peut paraître curieux, mais il existe encore de nombreuses personne de part le monde pour lesquels la date de naissance est incertaine (souvent juste l’année, parfois, l’année et le mois) naissant dans des pays ou l’état civil n’est pas aussi moderne que celui des pays civilisés (au_ vrai sens du terme pour une fois !). Enfin un attribut permet de renseigner le lieu de naissance qui peut être une ville, un lieudit, une région, un état… et pour compléter cette information, un lien d’association a été fait avec l’entité externe des pays (la structure de cette entité étant dépendante de celle de l’INSEE).
Enfin, cette entité est liée à l’entité de référence des sexes et celle des civilités. On me demande toujours pourquoi faire une table des sexe supposée ne contenir que deux lignes… Et je répond toujours : une base de données doit contenir toutes les données sous forme explicite. Comment alors faire figurer les mots « Homme » et « Femme » sans cela ? Directement dans l’entité des personnes physiques ? Mais alors ce sont des milliers d’octets en pure perte !
On peut être stupéfait de ne pas voir figurer de prénom dans l’entité des personnes. Mais on doit considérer qu’une personne possède généralement plusieurs prénoms, l’un étant le prénom usuel. De plus certains prénoms peuvent être composés. C’est la raison pour laquelle on a préféré faire figurer l’ensemble des prénoms d’une personne dans une entité de nom T_E_PRENOMMEE_PNM liée aux entités contenant la personne et tous les prénoms. Dans cette entité, figurent différents attributs qui ont les rôles suivants :
- PNM_USUEL : booléen. Si oui, alors le prénom est usuel
- PNM_ORDRE : entier positif. Spécifie l’ordre d’état civil des prénoms
- PNM_COMPOSE : booléen. Si oui, alors le prénom qui suit est lié au précédent (Jean-Marc par exemple).
Nous donnerons plus loin un petit exemple de contenu de cette entité lors de la visite du modèle physique.
L’entité T_E_TELEPHONE_TEL ne contient que les numéros de téléphone, mais elle est associé à une entité de référence des types de téléphone afin de préciser s’il s’agit d’une téléphone fixe, un fax ou un mobile. Notez l’attribut TEL_CAL_NUM_INVERSE qui reprend le numéro de téléphone, mais en le nettoyant des caractères parasites et en l’inversant et ce afin de faciliter les recherches.
L’entité T_E_MAIL_EML contient uniquement la partie « nom d’utilisateur » d’un mail (c’est à dire la partie devant l’arobase), sans le DNS qui lui, figure dans l’entité des DNS (sans l’arobase) T_E_DNS. Bien entendu, une vue permettra de reconstituer le mail tel qu’on a l’habitude de le présenter.
Téléphones et mails (et nous le verrons aussi les adresses) peuvent être localisés, c’est à dire correspondre à une situation particulière, telle que domicile, bureau, résidence secondaire… pour une personne physique, ou bien à un service, tel que facturation, comptabilité, administration, ventes, direction… pour une personne morale. C’est pour cela que ces entités sont liées à l’entité de référence T_R_LOCALISATION_LCL.
De même, un téléphone fixe ou un fax peut correspondre à une adresse et c’est le sens donné par l’association « situé à ». Bien entendu cela ne peut s’appliquer à un mobile ni à un mail par définition.
Enfin, une personne peut avoir plusieurs mails, fax, téléphones fixe, mais il est éventuellement souhaitable qu’on sache parmi tous ces fax quel est celui utilisable de préférence ou à défaut. C’est le sens donné par les trois associations « défaut » s’appliquant au téléphone fixe au fax et au mail, mais pas au mobile !
NOTA : pour gérer les particularités de situation des téléphones fixes mais pas des mobiles, il faudra procéder par contraintes.
1.2 – Contraintes :
Les principales contraintes de domaine sont les suivantes :
Booléens :
Les booléens XXX_BASE des tables de référence, comme ceux de l’association prénommée (PPN_USUEL et PPN_COMPOSE) doivent avoir comme valeur par défaut FAUX.
Pour les tables de référence :
XXX_ORDRE : positif. Ceci se fait par exemple à l’aide de la contrainte de validation :
CHECK (VALUE > 0)
Pour la personne morale :
PMR_SIREN et PMR_ETS sont composés de caractères numériques. Ceci se fait par exemple à l’aide de la contrainte de validation :
CHECK (VALUE = CAST(VALUES AS DECIMAL(n, 0))
n valant 9 pour un SIREN et 5 pour un ETS.
Le code NAF doit être composé de 4 chiffres + une lettre. La contrainte de validation est alors la suivante :
CHECK ( CAST(SUBSTRING(VALUE FROM 1 FOR 4) AS SMALLINT) = SUBSTRING(VALUE FROM 1 FOR 4)
AND SUBSTRING(VALUE FROM 5 FOR 1) COLLATE French_CS_AS BETWEEN 'A' AND 'Z')
Pour la personne physique :
On vérifiera que les noms (naissance et marital) ainsi que le lieu soient composés de lettres (y compris accentuées) et en majuscules avec les éventuels caractères blanc, tiret et apostrophe, mais ne figrant ni au début ni en fin de chaine. Ceci peut être fait à l’aide une UDF (par exemple F_RESCRIT décrite ici) associée à la contrainte de validation suivante :
CHECK (VALUE = F_RESCRIT(VALUE,
'-'' àáâãäæçèéêëìíîïñòóôõöœùúûüýœabcçdefghijklmnopqrstuvwxyzÀÁÂÃÄÆÇÈÉÊËÌÍÎÏÑÒÓÔÕÖÙÚÛÜÝŒABCDEFGHIJKLMNOPQRSTUVWXYZ',
'-'' ÀÁÂÃÄÆÇÈÉÊËÌÍÎÏÑÒÓÔÕÖŒÙÚÛÜÝŒABCCDEFGHIJKLMNOPQRSTUVWXYZÀÁÂÃÄÆÇÈÉÊËÌÍÎÏÑÒÓÔÕÖÙÚÛÜÝŒABCDEFGHIJKLMNOPQRSTUVWXYZ',
'- '''))
Les attributs PPQ_NAISSANCE_… doivent être aussi validés comme suit :
CHECK (PPQ_AN BETWEEN 1880 AND EXTRACT(YEAR FROM CURRENT_DATE)))
CHECK (PPQ_MOIS BETWEEN 1 AND 12)
CHECK (PPQ_JOUR BETWEEN 1 AND 31)
Mais nous verrons un peu plus loin, à la rubrique contrainte de table, que ceci ne suffit pas à garantir des saisies erronées…
Pour les téléphones :
L’attribut TEL_NUM ne doit être composé que de nombres mais on peut admettre les caractères point, tiret ou blanc afin de faciliter la lecture. Dans ce cas on validera avec la fonction F_RESCRIT de la manière suivante :
CHECK (VALUE = F_RESCRIT(VALUE,
'-. 0123456789',
'-. 0123456789',
'- .'))
L’attribut TEL_CALC_NUM_INVERSE ne doit être composé que de nombres. On pourra le valider à l’aide de la contrainte de validation suivante :
CHECK (VALUES = CAST(VALUE AS DECIMAL(20,0))
Les principales contraintes de table sont les suivantes :
Pour toutes les tables de référence : l’attribut XXX_CODE doit être unique.
Pour la table des personne morales, le code SIRET doit être unique :
UNIQUE (PMR_SIREN, PMR_ETS)
Pour les dates de naissance : plusieurs cas doivent être envisagés :
1) année seule
2) année + mois
3) année + mois + jour correspondant à une date valide
Toutes les autres combinaisons doivent être exclues
CHECK (CASE
WHEN PPQ_NAISSANCE_AN IS NOT NULL AND PPQ_NAISSANCE_MOIS IS NULL AND PPQ_NAISSANCE_JOUR IS NULL THEN 1
WHEN PPQ_NAISSANCE_AN IS NOT NULL AND PPQ_NAISSANCE_MOIS IS NOT NULL THEN 1
WHEN PPQ_NAISSANCE_AN IS NOT NULL AND PPQ_NAISSANCE_MOIS IS NOT NULL AND PPQ_NAISSANCE_JOUR IS NOT NULL
AND CAST(CAST(PPQ_NAISSANCE_AN AS VARCHAR(4)) || '- '
|| CAST(CAST(PPQ_NAISSANCE_MOIS AS VARCHAR(2)) || '- '
|| CAST(CAST(PPQ_NAISSANCE_JOUR AS VARCHAR(2)) AS DATE) BETWEEN '1880-01-01' AND CURENT_DATE) THEN 1
END) = 1 )
Les principales assertions sont les suivantes :
Gestion de l’héritage exclusif : une personne morale ne pet être une personne physique…
Se traduit par :
CHECK (NOT EXISTS(SELECT *
FROM T_E_PERSONNE_PHYSIQUE_PPQ AS P
INNER JOIN T_E_PERSONNE_MORALE_PMR AS M
ON P.PRS_ID = M.PRS_ID)
Gestion des informations spécifiques aux téléphones non mobiles :
Il ne faut pas de localisation par adresse pour un mobile :
CHECK (NOT EXISTS(SELECT *
FROM T_E_TELEPHONE_TEL AS T
INNER JOIN T_R_TELEPHONE_TYPE_TPT AS P
ON T.TPT_ID = P.TPT_ID
WHERE ADR_ID IS NOT NULL
AND TPT_CODE = 'MOBILE')
1.3 – Supplément :
On pourrait rajouter à ce modèle un lien entre personne morale et personne physique car une personne morale doit toujours être représentée par une personne physique. Ce « lien » pourrait être le suivant :
Pour une image plus grande, cliquez ici
Une personne ne saurait être suffisamment détaillée sans ses adresses. Le prochain article sur la modélisation des personnes portera sur la modélisation des adresses relatives aux personnes…
--------
Frédéric Brouard, SQLpro - ARCHITECTE DE DONNÉES, http://sqlpro.developpez.com/
Expert bases de données relationnelles et langage SQL. MVP Microsoft SQL Server
www.sqlspot.com : modélisation, conseil, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
Bonjour,
J’essaie d’appliquer votre norme à savoir
o E pour entité,
o R pour référence,
o S pour système,
o X pour référence externe,
o H pour héritée,
o G pour générique,
o A pour administrative,
o H pour historique ;
Toutefois je dois admettre que je ne comprends pas le principe des tables de références,
Par exemple pour la table T_R_SEXE_SEX
SEX_ID >>OK
SEX_CODE >>??
SEX_LIBELLE >>HOMME FEMME OK
SEX_BASE >>??
SEX_ORDRE >> ??
De plus quel peux être la différence entre une table système et table administrative ?
Étant plutôt convaincu part votre façon de faire, j’essaie de comprendre au mieux.
Merci beaucoup
Le code est la clef sémantique qui doit être IMMUABLE. par opposition au libellé qui lui peut être corrigé.
Exemple, sur la table de référence des sexes, le code peut être « M » pour le libellé « Mec » et « F » pour le libellé « Meuf »…. jusqu’au jour ou votre patron trouvera que « Mec » et « Meuf », c’est pas joli et vous demandera de rectifier en « Homme » et « Femme »; Vous ne pouvez donc pas vous baser sur ces valeurs là pour construire des requêtes placées dans le code de votre application.
Par exemple une requête pour savoir quel est le déficit de femmes employé dans l’entreprise par rapport aux hommes, et qui utiliserait explicitement le libellé et non le code, ne marcherais donc plus…
Quant à utiliser la clef, ce n’est pas possible, car
1) elle n’est pas connue préalablement (auto incrément)
2) sa valeur peut changer si l’on vide puis rempli à nouveau la table
En conclusion, la clef ne sert qu’aux jointures….
Table système => ne sert qu’à la cuisine interne de la base, par exemple table des tables, table des vues…
Table administrative => ne sert pas au fonctionnel, mais à l’administration de l’application, par exemple table des utilisateurs, table de « hit » des pages d’un site web…
Petit oublie,
une boolean, ne serait-elle pas moins couteuse en ressource, qu’une clé etrangère de la table TR_SEXE_SEX dans la table T_E_PERSONNE_PHYSIQUE_PRO
En coût de stockage oui il y a bénéfice. En coût de restitution, il vous faudra un jour ou l’autre un libellé ! Et là le coût de restitution à placer 654231102301 les mêmes deux libellés risque d’être plus cher que le stockage de smallint ou tinyint !
D’ailleurs le 0 et le 1 c’est qui ? La, femme ? L’homme ??? Si vous n’exprimez pas l’information quelque part votre modèle est faux…
Et qui vous dit qu’il ne faudra pas y mettre les transsexuels ou les personnes asexuées (nées sans sexe ?) ??????? À lire : http://fr.wikipedia.org/wiki/Syndrome_de_Klinefelter
N’oubliez jamais qu’une base de données c’est de la sémantique, donc des mots !
Moi je ne trouve pas pourquoi il doit y voir les tables sexe, civilité. il faut simplifier les choses. le sexe ily en a que deux , connus par tous ! civilité aussi
Parce que vous n’avez pas compris les principes de base de la modélisation des données :
au niveau du modèle conceptuel, les règles de base sont très simple :
1) PAS DE « NULL »
2) PAS DE REDONDANCE
3) LA MISE À JOUR D’UNE INFORMATION NE DOIT PAS IMPACTER PLUS D’UNE LIGNE
Auquel on peut rajouter l’élément suivant : pour des raisons de performance, il faut minimiser le volume des données.
En utilisant une table de référence, tout ceci est respecter. En ne l’utilisant pas ces 3 règles sont violées.
1) si vous ne savez pas le sexe ou la civilité, vous n’aurez donc pas de correspondance entre la table mère et la table fille. L’id (CVT_ID ou SEX_ID) sera bien null, mais ce n’est pas une valeur sémantique… On évite donc de stocker une valeur sémantique NULLe
2) en mettant directement le sexe ou la civilité de manière explicite dans la table vous avez de la redondance. Or la redondance entraîne deux problématiques :
a) la volumétrie des données. ‘Homme’, ‘Femme’, ‘Monsieur’, ‘Madame’… coutent beaucoup plus cher en stockage et en traitement (collations…) qu’un simple entier, et dans le cas de telle table on peut mettre un entier d’un octet comme clef….
b) la redondance entraîne fatalement un jour ou l’autre des divergences de valeurs. Tel utilisateur va saisir ‘Monsieur’, tel autre ‘Mr.’, un dernier ‘M.’… sans compter les fautes d’orthographe liée à la saisie! Vos base est donc pourrie par des données divergentes et vos requêtes vont devenir de plus en plus couteuses… Par exemple si on vous demande de vérifier la correspondance entre civilité et sexe, dans le cas d’une recherche d’erreur dans votre base, il va falloir faire un traitement manuel :
– lancer la requête : SELECT DISTINCT CIVILITE FROM MA_TABLE
– analyser les résultats et faire correspondre chaque occurrence du résultat à un sexe
– lancer la requête : SELECT DISTINCT SEXE FROM MA_TABLE
– analyser les résultats et faire correspondre chaque occurrence du résultat à un sexe
— lancer une requête finale de croisement des résultats.
Alors qu’avec des tables de référence externalisée, la requêtes est immédiate :
FROM PERSONNE
WHERE CASE WHEN CVT_ID = 1 AND SEX_ID 1 THEN 1 -- cas de Monsieur, sexe homme
WHEN CVT_ID = 2 AND SEX_ID 2 THEN 1 -- cas de Madame, sexe femme
WHEN CVT_ID = 3 AND SEX_ID 3 THEN 1 -- cas de Mademoiselle, sexe femme
ELSE 0
END = 1
3) Ceux qui ont mis des milliers de fois ‘Mademoiselle’ directement dans la table des personnes, ont dû modifier des milliers de lignes dans leur table, lorsque l’administration a imposé que l’on utilise plus le terme ‘Mademoiselle’ mais ‘Madame’. Ceci à deux impact négatifs :
a) cela bloque la table des personnes le temps de cette modification (plus personne ne peut ni lire, ni écrire dans cette table), alors qu’avec une table externe une seule ligne est changée et la table des personnes n’est jamais bloquée
b) si comme il est probable, la redondance a généré de multiple forme de ‘Mademoiselle’ : ‘Melle’, ‘Melle.’, ‘Mlle’, ‘Mlle.’… la requête sera d’un coût énorme et donc lente, du fait de l’impossibilité d’utiliser un index.
Bref, vous êtes perdant sur tous les tableaux !
A +
Bonjour
Si on y ajoute les tiers, normalement on peut pas savoir au départ s’il s’agit d’une personne physique ou morale ???
PierrePM13 (à propos des couleurs des associations et entités) : non, rien n’est prévu dans aucun système de notation. C’est à vous de mettre en place votre propre modèle de couleurs.
Concernant le terme « email » employé trop génériquement à mon goût en français, j’utilise les termes suivants :
– adrel = adresse électronique (toto@domaine.net)
– courriel = courrier électronique = le courrier envoyé par voie électronique d’une manière générale (Ai-je reçu du courriel depuis hier ?)
– mel = message électronique (Envoie-moi un mel à cette adrel : toto@domaine.net.)
Bonjour,
Dans l’exemple ci dessus vous dites :
1 – les entités figurant en jaune sont des entités de référence. Elles ont toutes une forme similaire, c’est à dire composées des mêmes attributs (domaines compris). Leur nom commence systématiquement par T_R_… (R pour Référence).
2 – les entités figurant en vert sont des entités informationnelles, c’est à dire celles qui contiendront les données fonctionnelles de l’application. Leur nom commence systématiquement par T_E_… (E pour Entité).
3 – les entités figurant en rose fuchsia sont des entités de données externes. Elle doivent contenir des données venant de sources externes non directement controlables (dans notre cas liste des pays de l’INSEE, liste des codes postaux…). Leur nom commence systématiquement par T_X_… (X pour Externe).
Est ce que c’est une norme Merise? Si oui, quelles sont les couleurs associées aux entités système (S), héritée (H), générique (G), administrative (A), historique (H)?
Pourriez vous détailler ce que représentent les entités ci-dessus?
Cordialement.
benwit : bonnes remarques sur la sémantique. Et la table contenant les courriers électroniques pourra s’appeler par exemple MAIL_MESSAGE, EMAIL_POST… ou courriel !!!
zinzineti : je n’ai pas dit qu’il était complet. D’ailleurs la partie adresse n’y figure pas complétement (ce sera pour plus tard…).
1) Le statut social n’y figure pas (ce n’était pas dans le cahier des charges). En revanche dans une autres partie du modèle, nous avons mis l’entourage de la personne (parentèle et amis)…
Pour cette fonction une entité de référence des statuts sociaux et une entité d’usage du statut avec des dates de début en fin (non obligatoire) me parait suffisant.
2) même remarque : pas dans le cahier des charges. Une simple date de décès dans la personne physique suffit.
3) même remarque : pas dans le cahier des charges. Une simple date de cloture dans la personne morale suffit.
2+3) même remarque : pas dans le cahier des charges. Une simple date de fin dans la personne générique suffit !
Est ce que ce modèle permet de savoir :
1.) le statut social d’une personne physique de sexe masculin ?
C’est à dire si une personne physique de sexe masculin est :
– Célibataire ?
– Pacsée ?
– Mariée ?
– Divorcé ?
– Veuf ?
2.) si une personne physique est encore en vie ou pas(c’est à dire morte) ?
3.) si une personne morale est toujours en activité ou a déjà mis la clé sous le paillasson ?
A+
A propos des abus de langage.
Les anglophones font la différence entre le mail (leur courrier postal) et l’email (le courrier électronique).
Comme chez nous, il n’y a pas de risque de confusion, on vois trop fréquemment le terme de mail utilisé pour désigné le courrier électronique.
Entre français, pas de problème mais un anglais pourra être surpris si vous lui dite je t’envoi un mail.
Il est donc préférable d’utiliser le terme d’email pour désigner un courrier électronique (les canadiens préférons probablement courriel)
Remarquez :
On parle de téléphone à la place de numéro de téléphone
On parle de courrier électronique (email) à la place d’adresse de courrier électronique (email address)
On fait déjà suffisamment des raccourcis de langage (et ça se comprend) alors ce n’est peut être pas la peine de les multiplier.
Loin de moi l’idée de jouer les tatillons, mais quand on modélise, on se rend compte qu’il est important d’utiliser les termes les plus appropriés.
Imaginez que vous créez une table email pour stocker des adresses de courrier électronique, comment allez vous appelez la table qui contiendra les courriers électroniques si le besoin s’en fait sentir ?