© Éditions Eyrolles
193
chapitre n° 3
Le niveau physique : de SQL2 à SQL3
La cardinalité (multiplicité) minimale 1 d’une association plusieurs-à-plusieurs ne se traduit pas
au niveau physique.
Dans l’exemple, cette cardinalité indique que tous les codes des compagnies référencées dans
la table Compagnie doivent se trouver dans la table Affreter. Il n’est pas possible que cette
contrainte soit respectée au début du cycle de vie de la base (lors du premier affrètement par
exemple). En revanche, il sera possible de programmer, ultérieurement, que toute compagnie
est référencée par un affrètement.
Associations n-aires
Une association n-aire généralise une association plusieurs-à-plusieurs. La clé primaire de la
table réalisant l’association sera donc composée de n colonnes. Comme pour les associations
plusieurs-à-plusieurs, toute cardinalité minimale 1 de l’association ne se traduit pas au niveau
physique.
Les règles R1 et R3 sont appliquées à l’association 3-aire de l’exemple 3-11. On ne dérive pas
une relation de l’entité temporelle Jour (explication au chapitre 2). En conséquence, seuls
deux attributs de la table Affreter sont des clés étrangères (immat et comp). La différence
avec le schéma précédent réside dans le fait qu’un avion donné pour une compagnie donnée
peut être affrété à différentes dates.
Tableau 3.7 Association plusieurs-à-plusieurs
Schéma logique
Script SQL2
Compagnie[comp, nomcomp]
Affreter[immat#, comp#, dateaff]
Avion[immat, typav]
CREATE TABLE compagnie
(comp
VARCHAR(4), nomcomp VARCHAR(30),
CONSTRAINT pk_compagnie PRIMARY KEY(comp))
CREATE TABLE avion
(immat VARCHAR(6), typav VARCHAR(10),
CONSTRAINT pk_avion PRIMARY KEY(immat))
CREATE TABLE affreter
(immat VARCHAR(6),comp VARCHAR(4),dateaff DATE,
CONSTRAINT pk_affreter PRIMARY KEY (immat,comp),
CONSTRAINT fk_affreter_immat_avion
FOREIGN KEY(immat)REFERENCES avion(immat),
CONSTRAINT fk_affreter_comp_compagnie
FOREIGN KEY(comp) REFERENCES compagnie(comp))