Database Reference
In-Depth Information
Autrement dit, ces attributs doivent être placés dans des entités secondaires associées à
l'entité primaire que constitue la personne. On aura donc trois entités supplémentaires :
l'une pour les téléphones, l'autre pour les adresses et la troisième pour les e-mails. Notez
que cette conception induit de multiples avantages parmi lesquels chaque personne peut
avoir un nombre indéterminé de téléphones (ixe, fax ou GSM…), plusieurs adresses et
une multiplicité d'e-mails, ce qui est courant !
Le fait de mettre tous les attributs de contacts dans une seule et même entité « personne
physique » contribue à créer des tables obèses dont les performances seront catastro-
phiques lors de la montée en charge de la base.
À lire sur le sujet : http://blog.developpez.com/sqlpro/p10070/langage-sql-norme/base-
de-donnees-et-performances-petites/.
Quelques conseils
Ain de rendre optimal un schéma conceptuel (minimiser les modiications à opérer avant de
créer des tables et index), quelques principes doivent être adoptés.
Décomposez si nécessaire
Décomposez tout attribut dont la structure est complexe en autant d'attributs que nécessaire.
Chacun de ces attributs devra être indécomposable (atomique). L'exemple le plus marquant est
l'adresse normée dont chaque champ possède une sémantique propre.
Figure 1-60
. Adresse postale
Ainsi, préférez l'utilisation de la classe
Adresse
à l'attribut de même nom. D'une part, cette
classe pourra être connectée à différentes autres classes (
Client
,
Fournisseur
,
Succur-
salle
, etc.). D'autre part, il sera possible d'indexer différentes colonnes pour faciliter des
recherches dans la base de données (sur le code postal, le nom d'une rue, etc.).
