5.4 Extraction de données de plusieurs tables (jointure)
97
© Dunod – La photocopie non autorisée est un délit.
Ce responsable étant lui-même une personne peut donc aussi avoir un responsable 24 ,
et ainsi de suite. Cette table est déclarée comme suit :
create table PERSONNE ( NPERS
char (4) not null,
NOM
char(25) not null,
RESPONSABLE char (4),
primary key (NPERS),
foreign key (RESPONSABLE)
references PERSONNE)
La figure 5.3 représente un exemple de contenu de la table PERSONNE. On y lit
notamment que les personnes p1 et p2 n’ont pas de responsable, que le responsable
de p3 et p4 est p1, et que p4 est responsable de p5 et p6, qui elle-même est responsable de p7. On dessinera les relations définies dans la table afin de maîtriser ces
concepts.
Cette table permet, par exemple, de répondre à la question suivante : donner, pour
chaque personne (S, pour subordonné) ayant un responsable (R), le numéro et le
nom de celui-ci. Il vient :
select S.NPERS, R.NPERS, R.NOM
from
PERSONNE S, PERSONNE R
where S.RESPONSABLE = R.NPERS
Figure 5.3 - Un exemple de contenu de la table PERSONNE 25
24. On considère souvent implicitement que le domaine d’application décrit par une structure
cyclique est soumis à des conditions sur le graphe des objets et de leurs inter-relations. Dans cet
exemple, on admettra qu’une personne ne peut être son propre responsable, ni directement ni
indirectement. En d’autres termes, si on représente la relation a-pour-responsable (correspondant à la clé étrangère RESPONSABLE) par un arc orienté d’une personne vers son responsable,
ce graphe ne peut présenter de circuits. En fait, cette contrainte ne peut être exprimée en SQL, ni
être vérifiée par le SGBD. Si des données définissant un tel circuit venaient à être introduites,
certains programmes d’application pourraient présenter un comportement anormal (bouclage
infini).
25. Dans un but de lisibilité, les valeurs ont été représentées par "- -".
97
© Dunod – La photocopie non autorisée est un délit.
Ce responsable étant lui-même une personne peut donc aussi avoir un responsable 24 ,
et ainsi de suite. Cette table est déclarée comme suit :
create table PERSONNE ( NPERS
char (4) not null,
NOM
char(25) not null,
RESPONSABLE char (4),
primary key (NPERS),
foreign key (RESPONSABLE)
references PERSONNE)
La figure 5.3 représente un exemple de contenu de la table PERSONNE. On y lit
notamment que les personnes p1 et p2 n’ont pas de responsable, que le responsable
de p3 et p4 est p1, et que p4 est responsable de p5 et p6, qui elle-même est responsable de p7. On dessinera les relations définies dans la table afin de maîtriser ces
concepts.
Cette table permet, par exemple, de répondre à la question suivante : donner, pour
chaque personne (S, pour subordonné) ayant un responsable (R), le numéro et le
nom de celui-ci. Il vient :
select S.NPERS, R.NPERS, R.NOM
from
PERSONNE S, PERSONNE R
where S.RESPONSABLE = R.NPERS
Figure 5.3 - Un exemple de contenu de la table PERSONNE 25
24. On considère souvent implicitement que le domaine d’application décrit par une structure
cyclique est soumis à des conditions sur le graphe des objets et de leurs inter-relations. Dans cet
exemple, on admettra qu’une personne ne peut être son propre responsable, ni directement ni
indirectement. En d’autres termes, si on représente la relation a-pour-responsable (correspondant à la clé étrangère RESPONSABLE) par un arc orienté d’une personne vers son responsable,
ce graphe ne peut présenter de circuits. En fait, cette contrainte ne peut être exprimée en SQL, ni
être vérifiée par le SGBD. Si des données définissant un tel circuit venaient à être introduites,
certains programmes d’application pourraient présenter un comportement anormal (bouclage
infini).
25. Dans un but de lisibilité, les valeurs