Exercices

Exercice 3.1 On vous donne un schéma E/A (figure 3.14) représentant des visites dans un centre médical.

Répondez aux questions suivantes en fonction des caractéristiques de ce schéma (autrement dit, indiquez si la situation décrite est représentable, indépendamment de sa vraissemblance).

1. Un patient peut-il effectuer plusieurs visites ?

2. Un médecin peut-il recevoir plusieurs patients dans la même consultation ? 3. Peut-on prescrire plusieurs médicaments dans une même consultation ? 4. Deux médecins différents peuvent-ils prescrire le même médicament ?

Exercice 3.2 Le second schéma (figure 3.15) représente des rencontres dans un tournoi de tennis.

1. Peut-on jouer des matchs de double ?

nbPrises Médicament Assiste Donne Médecin Patient noSS matricule code no libellé nom 0..* 0..* 0..* 0..* 1..1 1..1 Consultation nom date FIG. 3.14 – Centre médical no noCarte id 0..* 0..* 0..* 2..2 Joue Gagne 1..1 1..1 Terrain surface Joueur nom Match

horaire _{Se joue sur}

FIG. 3.15 – Tournoi de tennis

3. Peut-il y avoir deux matchs sur le même terrain à la même heure ? 4. Connaissant un joueur, peut-on savoir sur quels terrains il a joué ?

Exercice 3.3 Voici le schéma E/A (figure 3.16) du système d’information (très simplifié) d’un quotidien.

1. Un article peut-il être rédigé par plusieurs journalistes ? 2. Un article peut-il être publié plusieurs fois ?

3. Peut-il y avoir plusieurs articles sur le même sujet dans le même numéro ? 4. Connaissant une article, est-ce que je connais le journal oû il est paru ?

Exercice 3.4 Voici (figure 3.17) le début d’un schéma E/A pour la gestion d’une médiathèque. La spécifi-

cation des besoins est la suivante : un disque est constitué d’un ensemble de plages. Chaque plage contient un oeuvre et une seule, mais une oeuvre peut s’étendre sur plusieurs plages (Par exemple une symphonie en 4 mouvements). De plus, pour chaque plage, on connaît les interprêtes.

1. Complétez le modèle de la figure 3.17, en ajoutant les cardinalités.

2. On suppose que chaque interprète utilise un instrument (voix, piano, guitare, etc) et un seul sur une plage. Où placer l’attribut Instrument dans le modèle précédent ?

3. Transformez l’association  Joue dans la figure 3.17 en entité. Donnez le nouveau modèle, sans

oublier les cardinalités.

4. Introduisez maintenant les entités Auteur (d’une oeuvre) et Editeur d’un disque dans le schéma. Un disque n’a qu’un éditeur, mais une oeuvre peut avoir plusieurs auteurs.

Journaliste id interviewe id Sujet id nom nom dateNaiss Numéro no 0..n 0..n rédige 1..1 0..n no date tirage 0..n a travaillé pour 0..n 1..1 0..n paraît dans 0..n 1..1 Personnalité Journal Article libelle adresse contenu nom prénom nation.

FIG. 3.16 – Système d’information d’un quotidien

titre producteur id année id prénom joue sur no dateEnreg Disque année Oeuvre titre Plage Interprète nom durée

FIG. 3.17 – Contenu d’un disque

Exercice 3.5 La figure 3.18 montre la modélisation de séances de cours sous forme d’une association

ternaire. Noter que l’horaire fait partie de la clé (on aurait pu le représenter comme une entité supplémen- taire).

La notion de  cours regroupe les notions de cours magistral, enseignement dirigé et travaux pra-

tiques, pour une UV donnée. Par exemple l’UV “Base de données” comprend un cours, un ED et un TP. 1. Donner une représentation, sous forme de graphe ou de tableau, de l’instance de l’association cor-

respondant aux enseignements (cours, EDs, TPs) de l’UV “Base de données”.

2. Comment exprimer les contraintes suivantes : (i) un professeur ne donne pas deux cours en même temps, (ii) Pour une salle, un cours, un horaire, il y a un seul professeur.

3. Transformer l’association en entité, selon la règle vue en cours.

Exercice 3.6 Voici quelques tableaux (figure 3.19, 3.20, 3.21) représentant des associations entre entités.

Pour chacun,

1. Donner une représentation sous forme de graphe.

2. Donner le schéma E/A avec les cardinalités correspondant aux exemples donnés.

#ID #ID #ID COURS SALLE PROFESSEUR Libelle Niveau No Emplacement Nom Grade Seance #date-heure FIG. 3.18 – Séances de cours SOCIETE DIRECTEUR Tresys Charlus Fungus Morel Demona Saint-Loup Faribole Charlus FIG. 3.19 – Association SOCIETE/DIRECTEUR ORDINATEUR UTILISATEUR PC124 Charlus MAC04 Morel MAC03 Saint-Loup PC02 Morel MAC03 Charlus FIG. 3.20 – Association ORDINATEUR/UTILISATEUR ORDINATEUR DISQUES PC124 dsk09 MAC04 dsk08 MAC04 dsk05 PC124 dsk11 PC02 dsk04

Chapitre 4

Le modèle relationnel

Sommaire

4.1 Définition d’un schéma relationnel . . . . 35 4.2 Passage d’un schéma E/A à un schéma relationnel . . . . 37 4.2.1 Règles générales . . . 38 4.2.2 Retour sur le choix des identifiants . . . 43 4.2.3 Dénormalisation du modèle logique . . . 43 4.3 Le langage de définition de données SQL2 . . . . 45 4.3.1 Types SQL . . . 45 4.3.2 Création des tables . . . 46 4.3.3 Contraintes . . . 47 4.3.4 Modification du schéma . . . 50 4.4 Exercices . . . . 52

Un modèle de données définit un mode de représentation de l’information selon trois composantes : 1. Des structures de données.

2. Des contraintes qui permettent de spécifier les règles que doit respecter une base de données. 3. Des opérations pour manipuler les données, en interrogation et en mise à jour.

Les deux premières composantes relèvent du Langage de Définition de Données (DDL) dans un SGBD. Le DDL est utilisé pour décrire le schéma d’une base de données. La troisième composante (opérations) est la base du Langage de Manipulation de Données (DML) dont le représentant le plus célèbre est SQL.

Dans le contexte des bases de données, la principale qualité d’un modèle de données est d’être indépen- dant de la représentation physique. Cette indépendance permet de séparer totalement les tâches respectives des administrateurs de la base, chargés de l’optimisation de ses performances, et des développeurs d’ap- plication ou utilisateurs finaux qui n’ont pas à se soucier de la manière dont le système satisfait leurs demandes.

Le modèle relationnel, venant après les modèles hiérarchique et réseau, offre une totale indépendance entre les représentations logique et physique. Ce chapitre présente la partie du modèle relative à la définition et à la création des tables, ce qui constitue l’essentiel du schéma.

4.1

Définition d’un schéma relationnel

Un des grands avantages du modèle relationnel est sa très grande simplicité. Il n’existe en effet qu’une seule structure, la relation. Une relation peut simplement être représentée sous forme de table, comme sur la figure 4.1. Une relation a donc un nom (Film) et se compose d’un ensemble de colonnes désignées par

titre année genre

Alien 1979 Science-Fiction

Vertigo 1958 Suspense

Volte-face 1997 Thriller Pulp Fiction 1995 Policier

FIG. 4.1 – Une relation

un nom d’attribut. Dans chaque colonne on trouve des valeurs d’un certain domaine (chaînes de caractères, nombres). Enfin on constate que chaque ligne (ou tuple) correspond à une entité (ici des films).

Un schéma relationnel est constitué d’un ensemble de schémas de relations qui décrivent, à l’aide des élements présentés informellement ci-dessus (domaines, attributs, noms de relation) le contenu d’une relation. Le schéma de la relation de la figure 4.1 est donc :

Film (titre: string, année: number, genre : string)

Il existe un langage de définition pour créer une relation dans un SGBDR (voir section 4.3), mais nous nous contenterons pour l’instant de la description ci-dessus. Voici maintenant quelques précisions sur la terminologie introduite ci-dessus.

Domaines

Un domaine de valeurs est un ensemble d’instances d’un type élémentaire. Exemple : les entiers, les réels, les chaînes de caractères, etc. La notion de ’type élémentaire’ s’oppose à celle de type structuré : il est interdit en relationnel de manipuler des valeurs instances de graphes, de listes, d’enregistrements, etc. En d’autres termes le système de types est figé et fourni par le système.

Attributs

Les attributs nomment les colonnes d’une relation. Il servent à la fois à indiquer le contenu de cette colonne, et à la référencer quand on effectue des opérations. Un attribut est toujours associé à un domaine. Le nom d’un attribut peut apparaître dans plusieurs schémas de relations.

Schéma de relation

Un schéma de relation est simplement un nom suivi de la liste des attributs, chaque attribut étant associé à son domaine. La syntaxe est donc :

U

0 V+WX) / YWZ !#"$"#"$) /%[WZ%\

où les +1 sont les noms d’attributs et les Z1 les domaines. L’arité d’une relation est le nombre de ses attributs.

On peut trouver dans un schéma de relation plusieurs fois le même domaine, mais une seule fois un nom d’attribut. Le domaine peut être omis en phase de définition.

Instance d’une relation

Une instance d’une relation

U

, ou simplement relation se définit mathématiquement comme un sous- ensemble fini du produit cartésien des domaines des attributs de

U

. Rappelons que le produit cartésien X]^"$"#"4XZ% entre des domainesX$"#"$"C)Z% est l’ensemble de tous les tuples`_7#"#"$"#)_!%\ où_!1a^b1. Un des fondements du modèle relationnel est la théorie des ensembles et la notion de relation dans le modèle correspond strictement au concept mathématique dans cette théorie.

Une relation se représente sous forme de table, et on emploie le plus souvent ces deux termes comme des synonymes.

La définition d’une relation comme un ensemble (au sens mathématique) a quelques conséquences importantes :

1. l’ordre des lignes n’a pas d’importance car il n’y a pas d’ordre dans un ensemble ;

2. on ne peut pas trouver deux fois la même ligne car il n’y a pas de doublons dans un ensemble ; 3. il n’y a pas de case vide dans la table, donc toutes les valeurs de tous les attributs sont toujours

connues ;

Dans la pratique les choses sont un peu différentes : nous y reviendrons.

Clé d’une relation

La clé d’une relation est le plus petit sous-ensemble des attributs qui permet d’identifier chaque ligne de manière unique. Comme on a vu que deux lignes sont toujours différentes, l’ensemble de tous les attributs est lui-même une clé mais on peut pratiquement toujours trouver un sous-ensemble qui satisfait la condition. Pour distinguer la clé, nous mettrons le (ou les) attribut(s) en gras.

Film (titre, année, genre)

Le choix de la clé est très important pour la qualité du schéma. Choisir d’identifier un film par son titre comme nous l’avons envisagé dans l’exemple précédent n’est pas un très bon choix : nous y reviendrons.

Tuples

Un tuple est une liste de; valeurs `_7$"#"$"#2_!%\ où chaque valeur_!1 est la valeur d’un attribut +1 de domaineZ1 :_!1cZ1. Exemple :

(’Cyrano’, 1992, ’Rappeneau’)

Un tuple est donc simplement une ligne dans la représentation d’une relation sous forme de table. En théorie, on connaît les valeurs de tous les attributs du tuple.

Base de données

Une (instance de) base de données est un ensemble fini (d’instances) de relations. Le schéma de la base est l’ensemble des schémas des relations de cette base.

La création d’un schéma de base de données est simple une fois que l’on a déterminé toutes les relations qui constituent la base. En revanche le choix de ces relations est un problème difficile car il détermine en grande partie les caractéristiques, qualités de la base : performances, exactitude, exhaustivité, disponibilité des informations, etc. Un des aspects importants de la théorie des bases de données relationnelles consiste précisément à définir ce qu’est un bon schéma et propose des outils formels pour y parvenir.

En pratique, on procède d’une manière moins rigoureuse mais plus accessible, en concevant le schéma à l’aide d’un modèle de données conceptuel, puis en transcrivant le shéma conceptuel obtenu en schéma relationnel. La technique la plus répandue consiste à partir d’un schéma Entité/Association. La section suivante donne les règles du processus de transformation, en s’appuyant sur l’exemple de la figure 4.2.