Concepts et langages des

Bases de Données Relationnelles

• Plan
• Chapitre 1 Introduction générale
• Chapitre 2 Le modèle relationnel
• Chapitre 3 Présentation des données
• Chapitre 4 L’algèbre relationnelle
• Chapitre 5 Le langage SQL
 Introduction générale
• Qu’est-ce donc qu’une base de données ?
• Que peut-on attendre d’un système de gestion de bases de
données ?
• Que peut-on faire avec une base de données
Les limites à l’utilisation des fichiers

■ Redondance des données et incohérences

■ Isolation des données et accessibilité
■ Un accès aux données = un programme

■ Sécurité et protection des données

Les limites à l’utilisation des fichiers

■ Source des difficultés avec les fichiers

■ Le modèle des données est intégré dans les programmes
■ Absence de contrôle pour l’accès et la manipulation des
données
Notions de bases
Définition intuitive d’une BD (2)
■ Définition ; une base de données est un ensemble structuré de données (1) enregistrées sur
des supports accessibles par l’ordinateur (2) pour satisfaire simultanément plusieurs utilisateurs
(3) de manière sélective (4) en un temps opportun (5).

■ (1) : Organisation et description de données

■ (2) : Stockage sur disque
■ (3) : Partage des données
■ (4) : Confidentialité
■ (5) : Performance
SGBD (1)

Définition : Le logiciel qui permet d’interagir avec une BD est Système de Gestion
de Base de Données (SGBD)

SGB BD
D
SGBD (2)

Un SGBD est un intermédiaire entre les utilisateurs et les fichiers physiques

Un SGBD facilite
- la gestion de données, avec une représentation intuitive simple sous forme
de table par exemple
- la manipulation de données. On peut insérer, modifier les données et les
structures sans modifier les programmes qui manipulent la base de données

Base de données Programme

1
Fichier
1 SGBD Programme
Fichier
2
2
Fichier Programme
3 3
Objectifs des SGBD (1)
Faciliter la représentation et la description de données

■ Indépendance physique (1) : Plus besoin de travailler

directement sur les fichiers physiques (tels qu’ils sont
enregistrés sur disque). Un SGBD nous permet de décrire les
données et les liens entre elles d’une façon logique sans se
soucier du comment cela va se faire physiquement dans les
fichiers. On parle alors d’image logique de la base de données,
(ou aussi description logique ou conceptuelle ou encore de
schéma logique). Ce schéma est décrit dans un modèle de
données par exemple le modèles de tables, appelé le modèle
relationnel.
Image logique Image physique

Fichiers
physiques
Objectifs des SGBD (2)

■ Indépendance physique (2) : La manipulation des données doit être

faciliter en travaillant directement sur le schéma logique. On peut insérer,
supprimer, modifier des données directement sur l’image logique. Le
SGBD va s’occuper de faire le travail sur les fichiers physiques.
■ Indépendance logique : Un même ensemble de données peut être vu
différemment par des utilisateurs différents. Toutes ces visions
personnelles des données doivent être intégrés dans une vision globale.
■ Manipulations des données par des non informaticiens. Il faut pouvoir
accéder aux données sans savoir programmer ce qui signifie des
langages « quasi naturels ».
■ Efficacité des accès aux données : Ces langages doivent permettre
d’obtenir des réponses aux interrogations en un temps « raisonnable ». Il
doivent donc être optimisés et, entre autres, il faut un mécanisme
permettant de minimiser le nombre d’accès disques. Tout ceci, bien sur,
de façon complètement transparente pour l’utilisateur.
Objectifs des SGBD (3)
■ Administration centralisée des données : Des visions différentes des données (entre autres) se
résolvent plus facilement si les données sont administrées de façon centralisée.
■ Cohérence des données. Les données sont soumises à un certain nombre de contrainte
d’intégrité qui définissent un état cohérent de la base. Elles doivent pouvoir être exprimées
simplement et vérifiées automatiquement à chaque insertion, modification ou suppression de
données, par exemple :
■ l’âge d’une personne supérieur à zéro
■ Salaire supérieur à zéro
■ Etc
Dés que l’on essaie de saisir une valeur qui ne respecte pas cette contrainte, le SGBD le refuse.
Objectifs des SGBD (4)
■ Non redondance des données : Afin d’éviter les problèmes lors des mises à jour, chaque donnée
ne doit être présente qu’une seule fois dans la base.
■ Partageabilité des données : Il s’agit de permettre à plusieurs utilisateurs d’accéder aux mêmes
données au même moment. Si ce problème est simple à résoudre quand il s’agit uniquement
d’interrogations et quand on est dans un contexte mono-utilisateur, cela n’est plus le cas quand il
s’agit de modifications dans un contexte multi-utilisateurs. Il s’agit alors de pouvoir :
■ Permettre à deux (ou plus) utilisateurs de modifier la même donnée « em même temps »;
■ Assurer un résultat d’interrogation cohérent pour un utilisateur consultant une table pendant qu’un autre
la modifie.
Objectifs des SGBD (5)
■ Sécurité des données. Les données doivent pouvoir être protégées contre les accès non
autorisés. Pour cela, il faut pouvoir associer à chaque utilisateur des droits d’accès aux données.
■ Résistance aux pannes : Que se passe-t-il si une panne survient au milieu d’une modification, si
certains fichiers contenant les données deviennent illisibles? Les pannes, bien qu’étant assez
rares, se produisent quand même de temps en temps. Il faut pouvoir, lorsque l’une d’elles arrive,
récupérer une base dans un état « sain ». Ainsi, après une panne intervenant au milieu d’une
modification deux solutions sont possibles : soit récupérer les données dans l’état dans lequel
elles étaient avant la modification, soit terminer l’opération interrompue.
Trois Fonctions d’un SGBD
■ Description des données : codification structuration, grâce à un Langage
de Description de Données (LDD)

■ Manipulation et restitution des données (insertion, mise à jour,

interrogation)
■ Mise en œuvre à l’aide d’un Langage de Manipulation de Données (LMD)
■ S.Q.L. (Structures Query Langage) : Langage standard

■ Contrôle (partage, intégrité, confidentialité, sécurité)

Modèles de SGBD
■ Quelques modèles logiques :
■ Modèle hiérarchique
■ Modèle réseau
■ Modèle relationnel
■ Modèle objet
■ Quelques SGBD (relationnels du marché)
■ Micro : ACCESS, Paradox, Dbase, PostSQL, MySQL, …
■ Gros système : DB2, ORACLE, SYBASE, …
Conception des BD
 Architecture ANSI-SPARC

ES ES ES

CS

IS
 Modélisation des bases de données
Application 1 Application 2 Application 3 Application 4
Modèle Modèle Modèle Modèle
Externe Externe Externe Externe
Application 1
Conceptual
requirements
Application 2
Conceptual
requirements Modèle
Modèle
Application 3 Conceptu
Logique
Conceptual
requirements
el
Application 4
Conceptual
requirements Modèle
physique
⬥ Un modèle externe ou schéma externe représente la façon
dont un utilisateur final ou un programme d’application voit
la partie de la BD qui le concerne. Les modèles externes sont
aussi utilisés pour minimiser les manipulations incorrectes ou
non autorisées.
 Modèle conceptuel
Cahier des charges

Dictionnaire
des données

Modèle
Entité/associat Modélisation UML
ion Conceptuelle

Modèle conceptuel de
données
Diagramme de classes
 Modèle logique

⬥ Passage du modèle conceptuel de données vers le modèle relationnel

ou relationnel objet
■ Les deux règles: père - fils, père - père
⬥ Normalisation
■ 1FN, 2FN, 3FN, BCNF, 4 FN, 5 FN

■ Tables normalisées
 Conception physique

⬥ Le but : le traitement efficace des données (une BD est censée contenir

des milliers voire des millions d’enregistrements)

⬥ Optimiser les performances des services de base de données: demand speedy

access to data, no matter how complex the queries are

⬥ La conception physique nécessite des informations manipulées hors de la

modélisation conceptuelle et logique
Modèle relationnel ET
Normalisation
 Introduction

⬥ Proposé par E.F. Codd d’IBM en 1969, le modèle relationnel

a fait l’objet d’un grand nombre de travaux de recherche qui,
depuis le début des années 1980, ont débouché sur des
produits commerciaux ou libres :
DB2 d’IBM, Oracle, Sybase, Access ou SQL-Server de
Microsoft, PostgreSQL, MySQL
⬥ Le succès du modèle relationnel est dû à :
⬥ sa simplicité pour l’utilisateur : une BD est vue comme un
ensemble de tables,
⬥ ses fondements théoriques : l’algèbre relationnelle et la
logique des prédicats.
 Constitution d’une BD relationnelle

⬥ Une BD relationnelle est constituée par :

⬥ un ensemble de domaines,
⬥ un ensemble de relations,
⬥ un ensemble de contraintes d’intégrité.
 Domaines

⬥ On distingue :
1. les domaines prédéfinis :
⬥ l’ensemble des chaînes de caractères (texte),
⬥ l’ensemble des nombres entiers (entier),
⬥ l’ensemble des booléens :
⬥ booléen = {vrai, faux}
⬥ l’ensemble des dates
2. les domaines définis :

⬥ en extension, c.-à-d. en énumérant les valeurs :

⬥ ▪couleur = {"rouge", "vert", "bleu", "jaune"}

⬥ en intention, c.-à-d. en spécifiant la formule que doit vérifier chaque valeur :

⬥ ▪mois = {m| m entier ∧ 1 ≤ m ≤ 12}

 Relations

⬥ Une relation R est un sous-ensemble du produit cartésien de n

domaines D1, … , Dn :
⬥ R ∈ D1 x … x Dn
⬥ Une relation est définie par son nom, par son schéma et par
son extension.
 Schéma d’une relation

⬥ Le schéma d’une relation définit les domaines sur lesquels elle est
construite et donne un nom à ces domaines.
⬥ Nous noterons :
⬥ (A1: D1, …, An: Dn)
⬥ Les noms d'attributs d'un même schéma doivent être tous
différents

⬥ (nom: texte, âge: entier, marié: booléen)

⬥ Il est souvent pratique de noter à la fois le nom d’une relation
et son schéma. La notation R(A1: D1, …, An: Dn)
⬥ Lorsque l’indication des domaines n’est pas requise, un
schéma de relation pourra être noté :
⬥ R(A1, …, An)
 Extension d’une relation

⬥ L’extension d’une relation de schéma :

⬥ (A1: D1, …, An: Dn)
⬥ est un ensemble de nuplets notés :
⬥ soit (v1, … , vn) (dans l’ordre du schéma),
⬥ soit {A1 = v1, … , An = vn} (dans un ordre quelconque).
⬥ et tels que :
⬥ v1 ∈ D1, …, vn ∈ Dn
⬥ L’extension d’une relation est variable au cours de la vie
d’une BD.
⬥ Par exemple, une extension possible de la relation de schéma
:
⬥ (nom: texte, age: entier, marié: booléen)
⬥ est :
⬥ {("Dupont", 36, vrai), ("Durand", 22, faux)}
 vision d’une relation

⬥ Vision tabulaire:
⬥ Une relation : R(A1: D1, …, An: Dn)
peut être vue comme :
⬥ une table de nom R,
⬥ possédant n colonnes nommées A1, …, An
⬥ dont chaque ligne représente un n-uplet de l’extension de
cette relation.
⬥ Par exemple
⬥ personne
⬥ Nom âge marié
⬥ Dupont 36 Vrai
⬥ Durand 22 Faux
 Valeurs nulles

⬥ Il peut arriver que certaines informations soient inconnues ou non

pertinentes.
⬥ Par exemple, une conférence dont la date n’est pas encore fixée ou
bien le nombre de couleurs pour un écran noir et blanc.
Pour représenter une telle absence d’information on utilise une
valeur particulière
la valeur nulle que nous noterons _.
⬥ Par exemple, le triplet :
⬥ ("L'avenir des bases de données", "Paul Durand", _)
peut indiquer que la date de la conférence « L’avenir des bases
de données » donnée par Paul Durand, n’est pas encore connue.
 Constituants d’une relation

⬥ Nous appellerons constituant d’une relation un

sous-ensemble, éventuellement vide, des attributs de cette
relation.
Par exemple, l’ensemble d’attributs {nom, âge} est un
constituant de la relation personne
 Entités, associations et clés

⬥ Dans le modèle relationnel :

1. es entités sont identifiées au travers des clés primaires,
(Tables)
2. les associations sont décrites au moyen des clés étrangères
(Tables)
 Clés candidates et clé primaire (1)

⬥ Un constituant X est la clé candidate d’une relation R si :

⬥ pour chaque n-uplet de R, la valeur de X identifie de façon
unique ce n-uplet,
⬥ aucun attribut de X ne peut être supprimé sans détruire la
propriété précédente.
⬥ Une relation peut avoir une ou plusieurs clés candidates :
l’une est choisie comme clé primaire.
 Clés candidate et clé primaire (2)

⬥ Soit par exemple, la relation :

personne(nom, prénom, numss, pays)
⬥ où numss est le numéro de sécurité sociale.
⬥ Si une personne est identifiée :
⬥ soit par son nom et son prénom (et donc qu’elle ne l’est pas
par son nom seul ou son prénom seul),
⬥ soit par son numéro de sécurité sociale
⬥ les clés candidates de la relation personne sont :
{nom, prénom}
numss
⬥ numss pourra être choisi comme clé primaire.
Par convention, dans le schéma d’une relation, on souligne
les attributs de la clé primaire :
personne(nom, prénom, numss, pays)
 Clés étrangères (1)

⬥ Un constituant Y d’une relation R1 est une clé étrangère de

R1 s’il existe une relation R2 possédant une clé primaire X et
que Y a pour domaine l’ensemble des valeurs de X.
⬥ On dit que Y réfère la relation R2.
 Clés étrangères (2)

⬥ Soit par exemple les relations :

⬥ personne(nom, prénom, âge, Nationalité)
⬥ livre(cote, titre, nom_auteur, prénom_auteur)
⬥ Pour indiquer que l’auteur d’un livre est une personne de la BD,
on déclare que le constituant :
{nom_auteur, prénom_auteur}
⬥ est une clé étrangère de la relation livre qui réfère la relation Livre.
 Contraintes d’intégrité (1)

⬥ Les contraintes d’intégrité d’une BD relationnelle assurent la

cohérence de la BD et peuvent s’exprrimer par:
1. l’appartenance des valeurs d’attributs à des domaines,
2. la définition des clés,

3. la normalisation des relations,

4. un ensemble d’assertions,
5. des conditions associées aux opérations de mise à jour.
 Contraintes d’intégrité (2)

⬥ Concernant les clés, deux formes d’intégrité jouent un rôle

important :
1. L’intégrité d’entité qui est vérifiée si les valeurs des attributs de la
clé primaire ne sont pas nulles.
2. L’intégrité référentielle qui est vérifiée si chaque valeur d’une clé
étrangère Y :
⬥ soit existe comme valeur de la clé primaire d’un n-uplet de la
relation que Y réfère,
⬥ soit est nulle.