Database Reference
In-Depth Information
Figure 1-61
. Modélisation d'une adresse
Pour compléter cette modélisation, il faudrait connecter la classe
Ville
à la classe
Adresse
.
Tous les attributs d'une entité doivent être atomiques
Cette règle doit être appréciée à sa juste valeur… Elle est en effet relative à l'univers que
l'on modélise. Par exemple, la modélisation d'un simple numéro de Sécurité sociale sera
différente si vous l'avez à titre informatif (par exemple, dans le cadre de la gestion des
ressources humaines) ou à titre fonctionnel (par exemple, dans le domaine de la santé). À
titre informatif, un seul attribut de type chaîne de caractères de longueur 13 sufit. À titre
fonctionnel, il est important de découper ce numéro en autant de parties :
• le sexe sur un caractère ;
• l'année de naissance sur deux caractères ;
• le mois de naissance sur deux caractères ;
• le code Insee de la commune de naissance sur cinq caractères (et non le département
puis la commune comme on le croit trop souvent) ;
• le rang de naissance sur trois caractères.
En effet, il est possible que l'on vous demande un jour d'extraire toutes les femmes de la
tranche 45 à 60 ans nées en région parisienne, pour une étude sur le cancer du sein…
Un autre exemple nous est donné par les e-mails. On a tendance à oublier qu'un e-mail
est composé de deux parties : partie locale (en général, un nom de personne ou de service)
et un DNS (Domain Name Server ou nom de domaine) le tout accolé avec le caractère
@ (arobase) entre les deux. Il sera donc intéressant de décomposer les e-mails en deux
entités liées comme suit :
•
MAIL_USER
(
MLU_ID
entier auto,
MLU_LIBELLE
A256), l'identiiant étant
MLU_ID
;
•
MAIL_DNS
(MLD_ID entier auto,
MLD_LIBELLE
A256), l'identiiant étant
MLD_ID
.
Avec la cardinalité n:1 entre
MAIL_USER
et
MAIL_DNS
, la volumétrie est réduite : on évite
ainsi la redondance des wanadoo.fr, free.fr, etc., on contrôle mieux la saisie, et l'indexa-
tion est facilitée. Bref, de nombreux bénéices pour les performances.
