Modification du schéma

La création d’un schéma n’est qu’une première étape dans la vie d’une base de données. On est toujours amené par la suite à créer de nouvelles tables, à ajouter des attributs ou à en modifier la définition. La forme générale de la commande permettant de modifier une table est :

ALTER TABLE nomTable ACTION description

oùACTION peut être principalementADD,MODIFY,DROPouRENAME, etdescriptionest la com- mande de modification associée àACTION. La modification d’une table peut poser des problèmes si elle est incompatible avec le contenu existant. Par exemple passer un attribut àNOT NULLimplique que cet attribut a déjà des valeurs pour toutes les lignes de la table.

Modification des attributs

Voici quelques exemples d’ajout et de modification d’attributs. On peut ajouter un attributregionà la table Internaute avec la commande :

ALTER TABLE Internaute ADD region VARCHAR(10);

S’il existe déjà des données dans la table, la valeur sera àNULLou à la valeur par défaut. La taille de regionétant certainement insuffisante, on peut l’agrandir avecMODIFY, et la déclarerNOT NULLpar la même occasion :

ALTER TABLE Internaute MODIFY region VARCHAR(30) NOT NULL;

Il est également possible de diminuer la taille d’une colonne, avec le risque d’une perte d’information pour les données existantes. On peut même changer son type, pour passer par exemple deVARCHARà INTEGER, avec un résultat imprévisible.

L’optionALTER TABLEpermet d’ajouter une valeur par défaut.

ALTER TABLE Internaute ALTER region SET DEFAULT ’PACA’; Enfin on peut détruire un attribut avecDROP.

ALTER TABLE Internaute DROP region;

Création d’index

Pour compléter le schéma d’une table, on peut définir des index. Un index offre un chemin d’accès aux lignes d’une table qui est considérablement plus rapide que le balayage de cette table – du moins quand le nombre de lignes est très élevé. Les SGBDL créent systématiquement un index sur la clé primaire de chaque table. Il y a deux raisons à cela ;

1. l’index permet de vérifier rapidement, au moment d’une insertion, que la clé n’existe pas déjà ; 2. beaucoup de requêtes SQL, notamment celles qui impliquent plusieurs tables (jointures), se basent

sur les clés des tables pour reconstruire les liens. L’index peut alors être utilisé pour améliorer les temps de réponse.

Un index est également créé pour chaque clauseUNIQUEutilisée dans la création de la table. On peut de plus créer d’autres index, sur un ou plusieurs attributs, si l’application utilise des critères de recherche autres que les clés primaire ou secondaires.

La commande pour créer un index est la suivante :

CREATE [UNIQUE] INDEX nomIndex ON nomTable (attribut1 [, ...])

La clauseUNIQUEindique qu’on ne peut pas trouver deux fois la même clé. La commande ci-dessous crée un index de nom idxNom sur les attributsnometprenomde la table Artiste. Cet index a donc une fonction équivalente à la clauseUNIQUEdéjà utilisée dans la création de la table.

CREATE UNIQUE INDEX idxNom ON Artiste (nom, prenom); On peut créer un index, cette fois non unique, sur l’attributgenrede la table Film.

CREATE INDEX idxGenre ON Film (genre);

Cet index permettra d’exécuter très rapidement des requêtes SQL ayant comme critère de recherche le genre d’un film.

SELECT * FROM Film

WHERE genre = ’Western’

Cela dit il ne faut pas créer des index à tort et à travers, car ils ont un impact négatif sur les commandes d’insertion et de destruction. À chaque fois, il faut en effet mettre à jour tous les index portant sur la table, ce qui représente un coût certain.

4.4

Exercices

Exercice 4.1 La relation de la figure 4.4 est-elle conforme à la définition ? Si non, citez les anomalies.

titre année metteurEnScène acteur

‘Cyrano’ 1992 ’Rappeneau’ ’Depardieu’, ’Perez’ ‘Les oiseaux’ 1963 ’Hitchcock’ ’Taylor’

’Titanic’ ’Cameron’ ’DiCaprio’

’Les oiseaux’ 1963 ’Hitchcock’ ’Taylor’

FIG. 4.4 – Une relation

Exercice 4.2 Donnez le schéma relationnel de la base de données  Centre médical décrite par un

schéma E/A dans le précédent TD. Pour chaque table, il faut indiquer précisément, à l’aide de la syn- taxe vue en cours :

– La clé primaire. – Les clés étrangères.

Exercice 4.3 Même exercice que précédemment, pour l’application “Discothèque”.

Exercice 4.4 Même exercice, portant sur les schémasSOCIETE, DIRECTEUR,ORDINATEUR, UTILISATEUR,

ORDINATEUR, DISQUE DURque vous avez étudiés dans la séance consacrée au schéma E/A.

Cette fois, il est demandé de spécifier, pour chaque clé étrangère, la stratégie en cas de mise-à-jour ou de destruction de la ligne référencée (clausesON UPDATEetON DELETEvues en cours).

Exercice 4.5 Même exercice, pour le schéma “Cours”. Donner les spécifications complètes (clés primaires

et étrangères,NOT NULL, clausesUNIQUE, etc).

Exercice 4.6 Des éditeurs se réunissent pour créer une Base de Données sur leurs publications scienti-

fiques. Dans de telles publications, plusieurs auteurs se regroupent pour écrire un livre en se répartissant les chapitres à rédiger. Après discussion, voici le schéma obtenu :

1. Livre (titreLivre, année, éditeur, chiffreAffaire) 2. Chapitre (titreLivre, titreChapitre, nbPages) 3. Auteur (nom, prénom, annéeNaissance)

4. Redaction (nomAuteur, titreLivre, titreChapitre)

Les clés primaires sont en gras, mais les clés étrangères ne sont pas signalées. 1. Donnez le schéma Entité/Association correspondant au schéma relationnel.

2. Donnez les ordresCREATE TABLEpour le schéma, en spécifiant soigneusement clés primaires et étrangères avec la syntaxe SQL2. Le type des données est secondaire: choisissez ce qui vous semble logique.

Exercice 4.7 On trouve dans un SGBD relationnel les relations ci-dessous. Les clés primaires sont en gras,

les clés étrangères ne sont pas signalées.

– Immeuble (nom, adresse, nbEtages, annéeConstruction, nomGérant) – Appart (nomImm, noApp, type, superficie, étage)

– Personne (nom, prenom, age, codeProfession)

– Occupant (nomImm, noApp, nomOccupant, annéeArrivée) – Propriété (nomImm, nomPropriétaire, quotePart)

– TypeAppart (code, libellé) – Profession (code, libellé)

Chapitre 5

L’algèbre relationnelle

Sommaire

5.1 Les opérateurs de l’algèbre relationnelle . . . . 56