Bases de données relationnelles et normalisation :
de la première à la sixième forme normale

Par référence aux RVA (cf. paragraphe 2.6), la commande représente une propriété multivaluée du client, la ligne de commande représente à son tour une propriété multivaluée de la commande, l'engagement sur ligne de commande une propriété multivaluée de la ligne de commande, etc. Dans le diagramme ci-dessus, on a déplié les RVA et utilisé l'identification relative (cf. note qui suit), source de redondances au sein des clés.

(N.B. Dans le diagramme, les clés primaires sont soulignées, les clés étrangères sont en italiques, sachant que les attributs appartenant à une clé primaire peuvent aussi appartenir à une clé étrangère ; les principales clés alternatives — celles qui sont connues de l'utilisateur — sont soulignées en traits discontinus).

Note concernant l'identification relative

Revenons sur l'exemple précédent. Utiliser l'identification relative revient à considérer (au niveau logique) que la clé d'une table — par exemple Commande — est composée des attributs composant la clé de la table dont elle est une propriété multivaluée (Commande est une propriété multivaluée de Client et conceptuellement parlant, il s'agit d'une entité-type faible), plus un attribut permettant de distinguer chaque commande d'un client donné. Selon l'usage, cet attribut supplémentaire est de type Entier et numérote chaque commande relativement à un client. Exemple (clés soulignées) :

Client {CliId,   CliNom,          CliSiret, ...}
             1       Dubicobit       12345678900001
             2       Frichmoutz     31415926500009
            ...           ...                      ...

Commande {CliId,  CdeId,   CdeNo,   CdeDate, ...}
                     1         1       123456   15/02/2009
                     1         2       234567   01/04/2009
                     1         3       234575   02/04/2009
                     2         1       123023   20/01/2009
                     2         2       230239   17/03/2009
                     2         3       256789   06/01/2010
                    ...        ...          ...            ...

Du point de vue de l'utilisateur, le client Dubicobit a passé les commandes 123456, 234567 et 234575. Du point de vue du système, les commandes <1, 1>, <1, 2> et <1, 3> sont celles du client 1, tandis que les commandes <2, 1>, <2, 2> et <2, 3> sont celles du client 2.

Par contraste, utiliser l'identification absolue pour la table Commande (qui conceptuellement parlant n'est plus une entité-type faible) consiste à changer la composition de la clé, en remplaçant le couple {CliId, CdeId} par un singleton {CdeId} :

Commande {CliId,  CdeId,   CdeNo,   CdeDate, ...}
                     1         1       123456   15/02/2009
                     1         2       234567   01/04/2009
                     1         3       234575   02/04/2009
                     2         4       123023   20/01/2009
                     2         5       230239   17/03/2009
                     2         6       256789   06/01/2010
                    ...        ...          ...            ...

L'intérêt de l'identification relative ne saute pas aux yeux, et l'on pourrait légitimement douter de sa pertinence, donc préférer ne pas la mettre en œuvre. Que l'identification soit absolue ou relative, les tables Commande, LigneCde, Engagement et Livraison respectent la cinquième forme normale, mais l'identification relative est cause de redondance au sein des clés, ce qui n'a pas lieu quand on utilise l'identification absolue. Toutefois, cette redondance est parfaitement contrôlée par le système grâce aux contraintes d'intégrité référentielle déclarées. Par ailleurs, d'aucuns objectent que cette redondance est nécessairement consommatrice de ressources (mémoire, disque...), tandis que l'utilisation de l'identification absolue entraînerait une consommation minimale. On peut montrer qu'il n'en est rien (cf. Annexe F.1) et que la durée de certains traitements — batchs lourds notamment — peut être réduite de façon très sensible, voire déterminante si l'on passe à l'identification relative (cf. Annexe F.2).

Conséquence de l'identification relative sur l'organisation des requêtes SQL

Supposons que l'on ait besoin de savoir quels camions sont concernés par les livraisons chez le client Gillou (Siret = 12345678900001). Si on utilise l'identification absolue, on devra coder une requête SQL faisant intervenir toutes les tables intermédiaires, à savoir Commande, LigneCde, Engagement et Livraison :

Requête 1 (identification absolue)
 

(Incidemment, comme on s'intéresse en particulier au client Gillou, l'opération est performante, mais si l'on effectue des traitements de type batch, sans que les clés étrangères fassent l'objet d'index clusters (cf. Annexes F.2 et F.3), la dégradation des performances peut poser de très gros problèmes pour la Production informatique.)

Dans le cas de l'identification relative, on pourrait aussi écrire une requête analogue :

Requête 2 (identification relative)
 

Mais on peut alléger la requête ainsi :

Requête 3 (identification relative, variante)

Et plus important, on améliorera plus que substantiellement la performance en prenant un raccourci façon couloir spatio-temporel, en codant encore plus simplement :

Requête 4 (identification relative, 2e variante)

Dans ce genre d'exercice et dans un contexte batch ou de requêtes lourdes, l'identification absolue ne pourra évidemment pas rivaliser en performances et fera que l'on aura l'impression de faire du surplace (cf. Annexe F.3)...

« [...] La DF de REGLEMENT vers FACTURE a pour cardinalités maximales 1 dans chaque sens. Il est indispensable de procéder à une optimisation [...]. L'optimisation présente se traduira par l'introduction dans FACTURE de la clé étrangère #Reglement, afin de faciliter la communication entre FACTURE et REGLEMENT. »