Cours de bases de données et SGBD

Support de cours bases de données et SGBD, tutoriel & guide de travaux pratiques base de données en pdf.

Le modèle Entité/Association

Ce chapitre présente le modèle Entité/Association(E/A) qui est utilisé à peu près universellement pour la conception de bases de données(relationnelles principalement). La conception d’un schéma correct est essentielle pour le développement d’une application viable. Dans la mesure où la base de données est le fondement de tout le système, une erreur pendant sa conception est difficilement récupérable par la suite. Le modèle E/A a pour caractéristiques d’être simple et suffisamment puissant pour représenter des structures relationnelles. Surtout, il repose sur une représentation graphique qui facilite considérablement sa compréhension.
Le modèle E/A souffre également de nombreuses insuffisances : la principale est de ne proposer que des structures. Il n’existe pas d’opération permettant de manipuler les données,et pas (ou peu) de moyen d’exprimer des contraintes. Un autre inconvénient du modèle E/A est de mener à certaines ambiguïtés pour des schémas complexes.
La présentation qui suit est délibérément sur l’utilité du modèle E/A dans le cadre de la conception d’une base de données.Ajoutons qu’il ne s’agit pas de concevoir un schéma E/A (voir un cours sur les systèmes d’information), mais d’être capable de le comprendre et de l’interpréter. Dans tout ce chapitre nous prenons l’exemple d’une base de données décrivant des films, avec leur metteur en scène et leurs acteurs, ainsi que les cinémas où passent ces films. Nous supposerons également que cette base de données est accessible sur le Web et que des internautes peuvent noter les films qu’ils ont vus.

Principes généraux

La méthode permet de distinguer les entités qui constituent la base de données,et les associations entre ces entités.Ces concepts permettent de donner une structure à la base, ce qui s’avère indispensable. Nous commençons par montrer les problèmes qui surviennent si on traite une base relationnelle comme un simple fichier texte, sans se soucier de lui donner une structure correcte.
Bons et mauvais schémas
Considérons une table Film Simple stockant des films avec quelques informations de base, dont le metteur en scène. Voici une représentation de cette table.
Même pour une information aussi simple, il est facile d’énumérer tout un ensemble de problèmes potentiels. Tous ou presque découlent d’un grave défaut de la table ci-dessus : il est possible de représenter la même information plusieurs fois.
Anomalies lors d’une insertion
Rien n’empêche de représenter plusieurs fois le même film. Pire : il est possible d’insérer plusieurs fois le film Vertigo en le décrivant à chaque fois de manière différente,par exemple en lui attribuant une fois comme réalisateur Alfred Hitchcock, puis une autre fois John Woo, etc.
Une bonne question consiste d’ailleurs à se demander ce qui distingue deux films l’un de l’autre, et à quel moment on peut dire que la même information a été répétée Peut.-il y avoir deux films différents avec le même titre par exemple ? Si la réponse est non, alors on devrait pouvoir assurer qu’il n’y a pas deux lignes dans la table avec la même valeur pour l’attribut titre. Si la réponse est oui, il reste à déterminer quel est l’ensemble des attributs qui permet de caractériser de manière unique un film.
Anomalies lors d’une modification
La redondance d’information entraîne également des anomalies de mise à jour. Supposons que l’on modifie l’année de naissance de Hitchcock pour la ligne Vertigo et pas pour la ligne Psychose. On se retrouve alors avec des informations incohérentes.
Les mêmes questions que précédemment se posent d’ailleurs. Jusqu’à quel point peut-on dire qu’il n’y a qu’un seul réalisateur nommé Hitchcock, et qu’il ne doit donc y avoir qu’une seule année de naissance pour un réalisateur de ce nom ?
Anomalies lors d’une destruction
On ne peut pas supprimer un film sans supprimer du même coup son metteur en scène. Si on souhaite, par exemple, ne plus voir le film Titanic figurer dans la base de données,on va effacer du même coup les informations sur James Cameron.
La bonne méthode
Une bonne méthode évitant les anomalies ci-dessus consiste à ;
1. être capable de représenter individuellement les films et les réalisateurs,de manière à ce qu’une action sur l’un n’entraîne pas systématiquement une action sur l’autre ;
2. définir une méthode d’identification d’un film ou d’un réalisateur, qui permette d’assurer que la
même information est représentée une seule fois ;
3. préserver le lien entre les films et les réalisateurs,mais sans introduire de redondance.
Commençons par les deux premières étapes.On va d’abord distinguer la table des films et la table des réalisateurs.Ensuite on décide que deux films ne peuvent avoir le même titre, mais que deux réalisateurs peuvent avoir le même nom. Afin d’avoir un moyen d’identifier les réalisateurs,on va leur attribuer un numéro,désigné par id. On obtient le résultat suivant, les identifiants (ou clés) étant en gras.
Premier progrès: il n’y a maintenant plus de redondance dans la base de données.Le réalisateur Hitchcock, par exemple, n’apparaît plus qu’une seule fois, ce qui élimine les anomalies de mise à jour évoquées précédemment.
Il reste à représenter le lien entre les films et les metteurs en scène, sans introduire de redondance. Maintenant que nous avons défini les identifiants, il existe un moyen simple pour indiquer quel est le metteur en scène qui a réalisé un film : associer l’identifiant du metteur en scène au film. On ajoute un attribut idMES dans la table Film, et on obtient la représentation suivante.
Cette représentation est correcte. La redondance est réduite au minimum puisque seule la clé identifiant un metteur en scène a été déplacée dans une autre table (on parle de clé étrangère). On peut vérifier que toutes les anomalies que nous avons citée sont disparu.
Anomalie d’insertion. Maintenant que l’on sait quelles sont les caractéristiques qui identifient un film, il est possible de déterminer au moment d’une insertion si elle va introduire ou non une redondance. Si c’est le cas on doit interdire cette insertion.
Anomalie de mise à jour. Il n’y a plus de redondance, donc toute mise à jour affecte l’unique instance de la donnée à modifier .
Anomalie de destruction. On peut détruire un film sans affecter les informations sur le réalisateur.
Ce gain dans la qualité du schéma n’a pas pour contrepartie une perte d’information. Il est en effet facile de voir que l’information initiale (autrement dit, avant décomposition)peut être reconstituée intégralement. En prenant un film, on obtient l’identité de son metteur en scène,et cette identité permet de trouver l’unique ligne dans la table des réalisateurs qui contient toutes les informations sur ce metteur en scène.Ce processus de reconstruction de l’information, dispersée dans plusieurs tables, peut s’exprimer avec SQL.
La modélisation avec un graphique Entité/Association offre une méthode simple pour arriver au résultat ci-dessus, et ce même dans des cas beaucoup plus complexes.
Le modèle E/A : Présentation informelle
Un schéma E/A décrit l’application visée,c’est-à-dire une abstraction d’un domaine d’étude,pertinente relativement aux objectifs visés. Rappelons qu’une abstraction consiste à choisir certains aspects de la réalité perçue (et donc à éliminer les autres). Cette sélection se fait en fonction de certains besoins qui doivent être précisément définis.
Par exemple, pour notre base de données Films, on n’a pas besoin de stocker dans la base de données l’intégralité des informations relatives à un internaute, ou à un film. Seules comptent celles qui sont importantes pour l’application. Voici le schéma décrivant ce te base de données Films (figure 3.1). Sans entrer dans les détails pour l’instant, on distingue
1. des entités, représentées par des rectangles, ici Film, Artiste, Internaute et Pays ;
2. des associations entre entités représentées par des liens entre ces rectangles. Ici on a représenté par exemple le fait qu’un artiste joue dans des films, qu’un internaute note des films, etc.
Chaque entité est caractérisée par un ensemble d’attributs, parmi lesquels un ou plusieurs forment l’identifiant unique (en gras). Comme nous l’avons exposé précédemment,il est essentiel de dire ce qui caractérise de manière unique une entité,de manière à éviter la redondance d’information.

1 Introduction 
2 Présentation générale 
2.1 Données, Bases de données et SGBD
2.2 Que doit-on savoir pour utiliser un SGBD?
2.2.1 Définition du schéma de données
2.2.2 Les opérations sur les données
2.2.3 Optimisation
2.2.4 Concurrence d’accès
2.3 Le plan du cours
I Modèles et langages 
3 Le modèle Entité/Association 
3.1 Principes généraux
3.2 Le modèle E/A : Présentation informelle
3.3 Le modèle
3.4 Avantage et inconvénients du modèle E/A
3.5 Exercices
4 Le modèle relationnel 
4.1 Définition d’un schéma relationnel
4.2 Passage d’un schéma E/A à un schéma relationnel
4.3 Le langage de définition de données SQL2
4.4 Exercices
4 TABLE DES MATIÈRES
5 L’algèbre relationnelle 
5.1 Les opérateurs de l’algèbre relationnelle
5.2 Expression de requêtes avec l’algèbre
5.3 Exercices
6 Le langage SQL 
6.1 Requêtes simples SQL
6.1.1 Sélections simples
6.1.2 La clause WHERE
6.1.3 Valeurs nulles
6.2 Requêtes sur plusieurs tables
6.2.1 Jointures
6.2.2 Union, intersection et différence
6.3 Requêtes imbriquées
6.4 Agrégration
6.5 Mises-à-jour
6.6 Exercices
7 Schémas relationnels 
7.1 Schémas
7.1.1 Définition d‘un schéma
7.1.2 Utilisateurs
7.2 Contraintes et assertions
7.3 Vues
7.3.1 Création et interrogation d’une vue
7.3.2 Mise à jour d’une vue
7.4 Triggers
7.5 Exercices
8 Programmation avec SQL 
8.1 Interfaçage avec le langage C
8.2 L’interface Java/JDBC
II Aspects systèmes 
9 Techniques de stockage 
9.1 Stockage de données
9.2 Fichiers
9.2.1 Enregistrements
9.2.2 Blocs
9.2.3 Organisation d’un fichier
9.3 Oracle
10 Indexation 
10.1 Indexation de fichiers
10.2 L’arbre-B
10.3 Hachage
10.3.1 Principes de base
10.3.2 Hachage extensible
10.4 Les index bitmap
10.5 Indexation dans Oracle
11 Évaluation de requêtes 
11.1 Introduction
11.2 Evaluation d’une requête
11.3 Compilation d’une requête et optimisation
12 Introduction à la concurrence d’accès 
12.1 Préliminaires
12.2 Contrôle de concurrence
12.2.1 Verrouillage à deux phases
12.2.2 Contrôle par estampillage
12.3 Gestion des transactions en SQL
12.4 Exercices
13 Travaux pratiques 
13.1 Environnement
13.2 Requêtes SQL
13.2.1 Sélections simples
13.2.2 Jointures
13.2.3 Négation
13.2.4 Fonctions de groupe
13.3 Concurrence d’accès
13.4 Normalisation d’un schéma relationnel
13.5  Optimisation

………