Le niveau logique - UML 2: Pour les bases de donnees - page 125

● Toutes les requêtes relatives aux coloris se programmeront par jointures rendues perfor-
mantes par la présence d'index et par le type de la clé étrangère (ici numérique).
D'accord, il s'agit de prévoir que chaque attribut soit atomique. Mais il ne faudrait pas
oublier que tout attribut d'une relation doit être évalué (donc pas de NULL ) ! (en sus du
fait que la relation doit impérativement avoir une clé).
Mais qu'est-ce que l'atomicité d'un attribut ? Une date est-elle atomique ? N'est-elle pas
elle-même composée d'une année, d'un mois et d'un jour ? Un numéro de Sécurité sociale
n'est, par nature, pas du tout atomique. Il incorpore plusieurs notions telles que le sexe,
l'année, le mois et la commune de naissance…
Pour autant, on peut inverser le problème. Demandez donc à un vendeur de listes si
l'adresse dont il a fourré tous les éléments (nom de voie, type de voie, numéro dans la
voie…) dans un seul et même attribut considère que cette information n'est pas atomique !
Bref, la notion d'atomicité est relative à la problématique du modèle analysé…
Pour autant, certaines informations sont composées de plusieurs éléments décompo-
sables, et peuvent bien entendu être considérées comme atomiques. C'est le cas par
exemple des périodes (un début + une in) et plus généralement des intervalles, mais aussi
des objets géographiques (points, lignes, polygones…). Il devient alors très complexe de
savoir ce que représentent certaines notions d'unicité dans ce genre de cas de igure. À
titre d'exemple, voici deux polygones identiques (SQL SIG) :
POLYGON ((3 7, 5 7, 5 2, 4 2, 3 7))
POLYGON ((4 2, 3 7, 5 7, 5 2, 4 2))
Et deux intervalles se chevauchant : [33..52] et [47..49[ .
Il ne semble pourtant pas évident de savoir ce qu'une contrainte d'unicité (clé de la rela-
tion par exemple) doit faire dans un tel cas de igure !
On dit bien qu'un attribut doit être atomique. Ce n'est pas pour autant que l'on devrait
cacher la non-atomicité par une fantaisie de modélisation… Je m'explique. On trouve
souvent dans les tables des attributs de même nom numéroté de 1 à…, par exemple
TELEPHONE1 , TELEPHONE2 , TELEPHONE3 … Et, pourquoi pas, 4, 5, voire 10 téléphones ?
Dans ce cas, c'est un tableau de téléphone que l'on devrait mettre. Or, un tableau n'est à
l'évidence pas atomique, donc il se doit d'être transformé en entité à part entière.
Plus vicieux sont les attributs similaires non numérotés. Par exemple : TELEPHONE_FIXE,
TELEPHONE_MOBILE, TELECOPIE, TELEPHONE_DOMICILE, TELEPHONE_TRAVAIL!
Là aussi, la transformation est indispensable : une entité TELEPHONE avec un typage
des téléphones sufit. Songez donc au jour où votre patron vous demandera de retrouver
le client dont le numéro de téléphone est 75 78 45 15 79… Si vous avez disséminé vos
numéros de téléphone à travers plusieurs colonnes, voire plusieurs tables, ne vous étonnez
pas que la requête soit un veau et que tous les index du monde n'y pourront rien en plus
de rendre les tables bovines…