280
Chapitre 11 • Production du schéma de la base de données
données. En outre, lors de l’insertion d’une ligne dans une table, le SGBD va
d’abord vérifier que la valeur de chaque identifiant n’y est pas déjà présente. En
l’absence d’un index sur les identifiants, cette vérification nécessiterait une lecture
séquentielle de toutes les lignes de la table, dont le temps d’exécution serait prohibitif.
Le schéma de la figure 11.10 a été obtenu à partir du schéma précédent (11.9,
bas), auquel les index suggérés ci-dessus ont été ajoutés, ainsi que deux espaces de
stockage que nous mentionnerons sans justification. Le lecteur attentif remarquera
que certaines clés étrangères ne font pas l’objet d’un index. Sous certaines conditions, dont la discussion dépasserait l’objectif de cet ouvrage, un index I2 dont les
colonnes apparaissent en première position dans un autre index I1 peut être
supprimé. Le SGBD est en effet capable d’utiliser l’index I1 lorsque la requête
exigerait d’utiliser l’index I2.
Rappelons encore que la connaissance des index, des espaces de stockage et
autres structures physiques est inutile, voire nuisible, pour rédiger des requêtes en
SQL. C’est le rôle de l’optimiseur, composant essentiel du SGBD, que de traduire
les requêtes en accès aux données sur le disque de manière à exploiter au mieux ces
constructions.
11.9 TRADUCTION DES STRUCTURES EN SQL
La traduction de structures de tables en SQL est immédiate. Elle obéit aux règles
énoncées dans la section 4.2, qui ne seront pas reprises ici, mais que nous illustrerons par un exemple concret, celui de l’expression du schéma de tables de la figure
11.10. Seuls deux index ont été traduits, à titre d’illustration.
Figure 11.10 - Le schéma relationnel a été enrichi pas l’adjonction d’index et
d’espaces de stockage
VEHICULE
NUMVEH
MARQUE
MODELE
ANNEE
CYLINDREE
SIGNATAIRE
NUMCTR
NUMCLIENT
id: NUMVEH
acc
id': SIGNATAIRE
NUMCTR
ref acc
ref: NUMCLIENT
acc
IMPLICATION
NUMACC
NUMVEH
id: NUMACC
NUMVEH
acc
ref: NUMVEH
acc
ref: NUMACC
CONTRAT
SIGNATAIRE
NUMCTR
TYPE
DATESIGN
id: SIGNATAIRE
NUMCTR
acc
ref: SIGNATAIRE
CLIENT
NUMCLIENT
NOM
ADRESSE
id: NUMCLIENT
acc
ACCIDENT
NUMACC
DATEACC
MONTANT[0-1]
id: NUMACC
acc
SP_VEHICULE
VEHICULE
IMPLICATION
ACCIDENT
SP_CLIENT
CONTRAT
CLIENT
Chapitre 11 • Production du schéma de la base de données
données. En outre, lors de l’insertion d’une ligne dans une table, le SGBD va
d’abord vérifier que la valeur de chaque identifiant n’y est pas déjà présente. En
l’absence d’un index sur les identifiants, cette vérification nécessiterait une lecture
séquentielle de toutes les lignes de la table, dont le temps d’exécution serait prohibitif.
Le schéma de la figure 11.10 a été obtenu à partir du schéma précédent (11.9,
bas), auquel les index suggérés ci-dessus ont été ajoutés, ainsi que deux espaces de
stockage que nous mentionnerons sans justification. Le lecteur attentif remarquera
que certaines clés étrangères ne font pas l’objet d’un index. Sous certaines conditions, dont la discussion dépasserait l’objectif de cet ouvrage, un index I2 dont les
colonnes apparaissent en première position dans un autre index I1 peut être
supprimé. Le SGBD est en effet capable d’utiliser l’index I1 lorsque la requête
exigerait d’utiliser l’index I2.
Rappelons encore que la connaissance des index, des espaces de stockage et
autres structures physiques est inutile, voire nuisible, pour rédiger des requêtes en
SQL. C’est le rôle de l’optimiseur, composant essentiel du SGBD, que de traduire
les requêtes en accès aux données sur le disque de manière à exploiter au mieux ces
constructions.
11.9 TRADUCTION DES STRUCTURES EN SQL
La traduction de structures de tables en SQL est immédiate. Elle obéit aux règles
énoncées dans la section 4.2, qui ne seront pas reprises ici, mais que nous illustrerons par un exemple concret, celui de l’expression du schéma de tables de la figure
11.10. Seuls deux index ont été traduits, à titre d’illustration.
Figure 11.10 - Le schéma relationnel a été enrichi pas l’adjonction d’index et
d’espaces de stockage
VEHICULE
NUMVEH
MARQUE
MODELE
ANNEE
CYLINDREE
SIGNATAIRE
NUMCTR
NUMCLIENT
id: NUMVEH
acc
id': SIGNATAIRE
NUMCTR
ref acc
ref: NUMCLIENT
acc
IMPLICATION
NUMACC
NUMVEH
id: NUMACC
NUMVEH
acc
ref: NUMVEH
acc
ref: NUMACC
CONTRAT
SIGNATAIRE
NUMCTR
TYPE
DATESIGN
id: SIGNATAIRE
NUMCTR
acc
ref: SIGNATAIRE
CLIENT
NUMCLIENT
NOM
ADRESSE
id: NUMCLIENT
acc
ACCIDENT
NUMACC
DATEACC
MONTANT[0-1]
id: NUMACC
acc
SP_VEHICULE
VEHICULE
IMPLICATION
ACCIDENT
SP_CLIENT
CONTRAT
CLIENT