272
Chapitre 11 • Production du schéma de la base de données
facultatives. Dans ce cas cependant, il faut imposer une contrainte supplémentaire,
selon laquelle tous les composants de la clé étrangère sont simultanément null ou
simultanément non null. Il s’agit d’une contrainte de coexistence (notée coex, et
illustrée à la figure 9.26). La figure 11.3 propose un exemple de ces deux situations.
Figure 11.3 - Traduction sous forme d’une clé étrangère multi-composant
Les identifiants hybrides
Une question importante se pose ensuite : qu’en est-il des identifiants hybrides,
qui comprennent un ou plusieurs types d’entités associés, lorsqu’on représente les
types d’associations ? Considérons par exemple le schéma de la figure 9.22, dont un
fragment est repris dans la figure 11.4. Dans ce schéma, le type d’entités DEPARTEMENT possède un identifiant hybride constitué de DIRECTION (via de) et NomDépart. La représentation du type d’associations de, qui entraîne l’ajout d’une colonne
NOMDIR à la table DEPARTEMENT, doit conserver cet identifiant hybride, mais en
l’adaptant à la structure de colonnes. Cette adaptation est obtenue par remplacement
du composant DIRECTION par l’attribut NOMDIR de la clé étrangère qui vient d’être
ajoutée. Dans notre cas, l’identifiant de la table DEPARTEMENT est constitué des
colonnes NOMDIR et NOMDEPART.
Techniquement, le choix des noms des composants de la clé étrangère est indifférent, pourvu qu’ils soient distincts de ceux des autres colonnes de la table. On choisira cependant des noms qui évoquent explicitement le type d’entités référencé ou
son rôle dans le type d’associations ou le nom de son identifiant primaire.
⇒
0-1
0-N
affecté
1-1
0-N
dépend
EMPLOYE
NumEmp
Localisation
id: NumEmp
SERVICE
NomDép
NomServ
Responsable
id: NomDép
NomServ
SERVICE
NomDép
NomServ
Responsable
id: NomDép
NomServ
EMPLOYE
NumEmp
Localisation
DEP_NomDép
DEP_NomServ
AFF_NomDép[0-1]
AFF_NomServ[0-1]
id: NumEmp
ref: DEP_NomDép
DEP_NomServ
ref: AFF_NomDép
AFF_NomServ
coex
Chapitre 11 • Production du schéma de la base de données
facultatives. Dans ce cas cependant, il faut imposer une contrainte supplémentaire,
selon laquelle tous les composants de la clé étrangère sont simultanément null ou
simultanément non null. Il s’agit d’une contrainte de coexistence (notée coex, et
illustrée à la figure 9.26). La figure 11.3 propose un exemple de ces deux situations.
Figure 11.3 - Traduction sous forme d’une clé étrangère multi-composant
Les identifiants hybrides
Une question importante se pose ensuite : qu’en est-il des identifiants hybrides,
qui comprennent un ou plusieurs types d’entités associés, lorsqu’on représente les
types d’associations ? Considérons par exemple le schéma de la figure 9.22, dont un
fragment est repris dans la figure 11.4. Dans ce schéma, le type d’entités DEPARTEMENT possède un identifiant hybride constitué de DIRECTION (via de) et NomDépart. La représentation du type d’associations de, qui entraîne l’ajout d’une colonne
NOMDIR à la table DEPARTEMENT, doit conserver cet identifiant hybride, mais en
l’adaptant à la structure de colonnes. Cette adaptation est obtenue par remplacement
du composant DIRECTION par l’attribut NOMDIR de la clé étrangère qui vient d’être
ajoutée. Dans notre cas, l’identifiant de la table DEPARTEMENT est constitué des
colonnes NOMDIR et NOMDEPART.
Techniquement, le choix des noms des composants de la clé étrangère est indifférent, pourvu qu’ils soient distincts de ceux des autres colonnes de la table. On choisira cependant des noms qui évoquent explicitement le type d’entités référencé ou
son rôle dans le type d’associations ou le nom de son identifiant primaire.
⇒
0-1
0-N
affecté
1-1
0-N
dépend
EMPLOYE
NumEmp
Localisation
id: NumEmp
SERVICE
NomDép
NomServ
Responsable
id: NomDép
NomServ
SERVICE
NomDép
NomServ
Responsable
id: NomDép
NomServ
EMPLOYE
NumEmp
Localisation
DEP_NomDép
DEP_NomServ
AFF_NomDép[0-1]
AFF_NomServ[0-1]
id: NumEmp
ref: DEP_NomDép
DEP_NomServ
ref: AFF_NomDép
AFF_NomServ
coex