UML 2 pour les bases de données
70
© Éditions Eyrolles
Serveur. L’attribut dateCx qui dépend simultanément des deux classes doit rester dans la
classe-association Connecter. L’association peut désormais se lire ainsi : à un serveur et à
un segment donnés est associée une date de connexion.
Contre-exemple
Supposons, à partir de la figure 1-68, que l’attribut a représente l’immatriculation d’un avion,
b le code de la compagnie propriétaire et c le type de l’avion. Le diagramme ne serait pas en
deuxième forme normale car seule l’immatriculation d’un avion suffit à déterminer son type.
Il faudrait déplacer l’attribut c dans la classe de a pour satisfaire à cette normalisation.
En revanche, si l’attribut c représente la date d’un vol, alors la modélisation exprime le fait
qu’on puisse gérer les dates de derniers affrètements de chaque avion par toute compagnie.
Troisième forme normale
Troisième forme normale
Chaque attribut doit dépendre d’un identifiant dans le cas d’une classe, ou de plusieurs identifiants
dans le cas d’une classe-association et non d’un autre attribut voisin, lui-même dépendant d’un
ou de plusieurs identifiants.
Bien qu’il existe parfois une volonté de dénormalisation (on se contente de la deuxième forme
normale) à ce niveau pour optimiser les accès en diminuant les jointures dans les requêtes
SQL, il est fortement conseillé de rendre, dans un premier temps, vos diagrammes de classes
en troisième forme normale.
Rapport avec les dépendances fonctionnelles
Un diagramme est en troisième forme normale si chaque attribut de classe est en dépendance
fonctionnelle directe avec l’identifiant de sa classe.
Dans l’exemple 1-70, il existe un graphe transitif de dépendance qu’il convient de rompre (ici,
la dépendance entre a et c est déduite par transitivité des deux autres). Le fait de supprimer
Figure 1-70 Passage en troisième forme normale
a
b
c
0..*
ou
1..*
1
ou
0 1
a
b
c
3
e forme normale
70
© Éditions Eyrolles
Serveur. L’attribut dateCx qui dépend simultanément des deux classes doit rester dans la
classe-association Connecter. L’association peut désormais se lire ainsi : à un serveur et à
un segment donnés est associée une date de connexion.
Contre-exemple
Supposons, à partir de la figure 1-68, que l’attribut a représente l’immatriculation d’un avion,
b le code de la compagnie propriétaire et c le type de l’avion. Le diagramme ne serait pas en
deuxième forme normale car seule l’immatriculation d’un avion suffit à déterminer son type.
Il faudrait déplacer l’attribut c dans la classe de a pour satisfaire à cette normalisation.
En revanche, si l’attribut c représente la date d’un vol, alors la modélisation exprime le fait
qu’on puisse gérer les dates de derniers affrètements de chaque avion par toute compagnie.
Troisième forme normale
Troisième forme normale
Chaque attribut doit dépendre d’un identifiant dans le cas d’une classe, ou de plusieurs identifiants
dans le cas d’une classe-association et non d’un autre attribut voisin, lui-même dépendant d’un
ou de plusieurs identifiants.
Bien qu’il existe parfois une volonté de dénormalisation (on se contente de la deuxième forme
normale) à ce niveau pour optimiser les accès en diminuant les jointures dans les requêtes
SQL, il est fortement conseillé de rendre, dans un premier temps, vos diagrammes de classes
en troisième forme normale.
Rapport avec les dépendances fonctionnelles
Un diagramme est en troisième forme normale si chaque attribut de classe est en dépendance
fonctionnelle directe avec l’identifiant de sa classe.
Dans l’exemple 1-70, il existe un graphe transitif de dépendance qu’il convient de rompre (ici,
la dépendance entre a et c est déduite par transitivité des deux autres). Le fait de supprimer
Figure 1-70 Passage en troisième forme normale
a
b
c
0..*
ou
1..*
1
ou
0 1
a
b
c
3
e forme normale