Introduction

 Les organisations gèrent des volumes de données très grands

 Giga, Tera, Peta –octets
 Numériques, Textuelles, Multimédia (images, vidéos,...)
 Il faut pouvoir facilement
 Archiver les données sur mémoires secondaires permanente
 Retrouver les données pertinentes à un traitement
 Mettre à jour les données variant dans le temps
 Les données sont structurées et identifiées
 Données élémentaires ex: Votre nom, Votre note en BD
 Données composées ex: Votre CV, vos résultats de l'année
 Identifiant humain ex: numéro d’étudiant, numéro d’immatriculation de
véhicule
 Qu'est-ce qu'une base de données ?
 Collection de données structurées
 Interrogeable et modifiable par des langages de haut niveau (proches du langage
naturel)
 Partagée par plusieurs applications/utilisateurs

2
Historique
Années 60:
Fichiers séquentiels
Accès séquentiel aux données puis sur clé.
Années 70:
Bases de données hiérarchiques puis réseaux
Données stockées dans des fichiers et reliées par des pointeurs.
Interrogation par navigation
Années 80:
Bases de données relationnelles
Relation entre ensembles de données
Interrogation par un langage proche du langage naturel
Années 90 et 2000:
Bases de données objets, XML …

3
Gestion des données (1)
La gestion de données par l’utilisation de fichiers
présente de nombreux inconvénients:
1. Absence de standardisation
plusieurs formats de stockage, plusieurs langages
2. Redondance des données (duplication)
Problèmes de mise à jour, incohérence des données
3. Interrogation par langage de programmation
Difficulté de maintenance
Coût élevé

4
Gestion des données (2)
4. Pannes (arrêt brutal, panne de disque …)
pas de solution standardisée
5. Partage de données
pas de solution standardisée
6. Confidentialité
Pas de solution standardisée

Pas de solution standardisée => une solution doit être

conçue et implémentée pour chaque application.

5
L’approche "bases de données"
Modélisation des données
 Éliminer la redondance de données
 Centraliser et organiser correctement les données
 Plusieurs niveaux de modélisation
 Outils de conception

Logiciel de Système de Gestion de Bases de Données (SGBD)

 Factorisation des modules de contrôle des applications:
interrogation, pannes, confidentialité, partage …
 Administration facilitée des données

6
Objectifs des SGBD
1. Indépendance physique des données
2. Indépendance logique des données
3. Langage simple
4. Gestion des vues
5. Optimisation des questions
6. Gestion de la cohérence
7. Gestion des pannes
8. Concurrence d’accès
9. Gestion de la confidentialité
10. Standards
7
SGBD relationnels (SGBDR)
Logiciels commerciaux/payants:
 Oracle (plus de 60% du marché mondial des SGBDR)
 Microsoft SQL server
 IBM DB2
 Sybase Anywhere
 …

Logiciels libres/gratuits:
 MySQL
 PostrgreSQL
 mSQL
 …

8
Objectifs des SGBD
1. Indépendance physique des données
2. Indépendance logique des données
3. Manipulation simple
4. Gestion des vues
5. Optimisation des questions
6. Gestion de la cohérence
7. Gestion des pannes
8. Concurrence d’accès
9. Gestion de la confidentialité
10. Standards
9
 Architecture à 3 niveaux
Vue 1 Vue 2 Vue 3 Schémas externes
(vues)

Schéma conceptuel

Schéma interne (stockage)

10
Indépendance Physique
 Indépendance des programmes
d'applications vis à vis du modèle
physique :
 Possibilité de modifier les structures de
stockage (fichiers, index, chemins d'accès, …)
sans modifier les programmes;
 Ecriture des applications par des non-
spécialistes des fichiers et des structures de
stockage;
 Meilleure portabilité des applications et
indépendance vis à vis du matériel.
11
Indépendance logique
 Les applications peuvent définir des vues logiques de la
BD
 Possibilité pour chaque application d'ignorer les besoins
des autres (bien que partageant la même BD).
 Possibilité d'évolution de la base de données sans
réécriture des applications :
 ajout de champs, ajout de relation, re-nommage de champs.

 Possibilité d'intégrer des applications existantes sans

modifier les autres.
 Possibilité de limiter les conséquences du partage :
Données confidentielles.
12
Langage simple
 La manipulation se fait via un langage déclaratif
 La question déclare l’objectif sans décrire la méthode
 Le langage suit une norme commune à tous les
SGBD
 SQL : Structured Query Langage

 Sémantique
 Logique du 1er ordre
 Syntaxe (aperçu !)
SELECT <structure des résultats>
FROM <relations>
WHERE <conditions>
13
Des vues multiples des données
 Les vues permettent d’implémenter l’indépendance logique
en permettant de créer des relations virtuelles
 Vue = Question stockée
 Le SGBD stocke la définition et non le résultat
 Exemple :
 la vue des patients sétifiens
 la vue des projets de chaque service (chaque employer ne peut
voir que les projets de son service)
 La vue des services statistiques
 ...

14
 Exécution et Optimisation
 Traduction automatique des questions déclaratives en
programmes procéduraux :
 Utilisation de l’algèbre relationnelle

 Optimisation automatique des questions

 Utilisation de l’aspect déclaratif de SQL
 Gestion centralisée des chemins d'accès (index, hachages,
…)
 Techniques d’optimisation poussées

 Economie de l'astuce des programmeurs

 milliers d'heures d'écriture et de maintenance de logiciels.

15
Intégrité Logique
 Objectif : Détecter les mises à jour erronées

 Contrôle sur les données élémentaires

 Contrôle de types: ex: Nom alphabétique
 Contrôle de valeurs: ex: Salaire mensuel entre 15000 et
500000

 Contrôle sur les relations entre les données

 Relations entre données élémentaires:
 Prix de vente > Prix d'achat
 Relations entre objets:
 Un employer ne doit être rattaché qu'à un seul service.

16
Contraintes d’intégrité
 Avantages :
 simplification du code des applications
 sécurité renforcée par l'automatisation
 mise en commun des contraintes

 Nécessite :
 un langage de définition de contraintes d'intégrité
 la vérification automatique de ces contraintes

17
 Intégrité Physique
 Motivations : Tolérance aux fautes
 Transaction Failure : Contraintes d'intégrité, Annulation
 System Failure : Panne de courant, Crash serveur ...
 Media Failure : Perte du disque
 Communication Failure : Défaillance du réseau

 Objectifs :
 Assurer l'atomicité des transactions
 Garantir la durabilité des effets des transactions commises

 Moyens :
 Journalisation : Mémorisation des états successifs des
données
 Mécanismes de reprise

18
Transaction
Incohérence possible...
Etat cohérent Etat cohérent

Begin Commit
Transaction

Begin
Compte1 = Compte1 - 3000
Compte2 = Compte2 + 3000
Commit T1
19
 Atomicité et Durabilité
ATOMICITE Panne
DURABILITE

Begin Begin
Compte1 = Compte1 - 3000 Compte1 = Compte1 - 3000
Compte2 = Compte2 + 3000 Compte2 = Compte2 + 3000
Commit T1 Commit T1 Crash disque

 Restaurer les
 Annuler le débit !!
données telles qu'elles
étaient avant la
transaction 20
 Partage des données

BD

• Accès concurrent aux mêmes données

Conflits d’accès !!
21
 Isolation et Cohérence

BD

• Le SGBD gère les accès concurrents

 Chacun à l’impression d’être seul (Isolation)
 Cohérence conservée (Pas de mises à jour
conflictuelles)
22
Confidentialité
 Objectif : Protéger les données de la BD contre
des accès non autorisés
 Deux niveaux :
 Connexion restreinte aux utilisateurs répertoriés (mot
de passe)
 Privilèges d'accès aux objets de la base

 Objets : Relation, Vue, autres objets (procédures, etc.)

23
Standardisation
 L’approche bases de données est basée sur plusieurs
standards
 Langage SQL (SQL1, SQL2, SQL3)
 Communication SQL CLI (ODBC / JDBC)
 Transactions (X/Open DTP, OSI-TP)

 Force des standards

 Portabilité
 Interopérabilté
 Applications multisources…

24
 Architecture des SGBD
 Les architectures physiques de SGBD sont très liées au mode
de répartition.
— BD centralisée
— BD client/serveur
— BD client/multi-serveurs
— BD répartie
— BD hétérogène
— BD mobile
 Le challenge se déplace des Péta-bases aux Pico-bases.
— Péta-bases => parallélisme et grandes mémoires
— Pico-bases => faible empreinte et forte sécurité

25
Applications traditionnelles des SGBD
 OLTP (On Line Transaction Processing)
 Cible des SGBD depuis leur existence
 Banques, réservation en ligne ...
 Très grand nombre de transactions en parallèle
 Transactions simples

 OLAP (On Line Analytical Processing)

 Entrepôts de données, DataCube, Data Mining …
 Analyse des données, extraction de connaissances,
prévisions …
 Faible nombre de transactions
 Transactions très complexes

26
Langage simple
Langage de manipulation de données (Data manipulation
Language DML):
 Ajouter des données
 Modifier des données
 Supprimer des données
 Interroger les données
Langage de définition de données (Data Definition Language
DDL):
 Créer un schéma
 Modifier un schéma
 Supprimer un schéma
27
Gestion des vues
Les vues permettent de définir le schéma externe propre
à chaque utilisateur/catégorie d’utilisateurs.

Elles permettent également de définir une politique de

confidentialité des données en permettant ou non
l’accès aux utilisateurs/catégories d’utilisateurs à des
objets de la base de données.

28
Optimisation des questions
Le SGBD doit mettre en place au niveau du schéma
interne des structures accélératrices et méthodes de
stockage de manière à rendre plus rapide la réponse
aux questions des utilisateurs.

Différents types d’index et d’algorithme de hachage et

techniques de clustering (regroupement de données)
permettent d’accélérer les temps de réponse.

29
Gestion de la cohérence
Le SGBD doit garantir la cohérence des données par
rapport aux contraintes d’intégrité définies au niveau
du schéma relationnel.
Exemple:
Le salaire d’un employé ne doit mas être inférieur à celui
de son supérieur direct.
Un client ne peut passer de nouvelles commandes s’il n’a
pas payer toutes ses factures des commandes
précédentes.

30
Gestion des pannes
Le SGBD doit garantir la reprise sur panne sans perte de
données en cas d’arrêt brutal du serveur (coupure de
courant…) ainsi qu’en cas de panne matérielle (CPU,
RAM, disque).

Une technique de redondance doit être utilisée pour

restaurer la base de données si une panne de disque
rend la récupération des données sur ce dernier
impossible.

31
Concurrence d’accès
Le SGBD doit permettre à plusieurs utilisateurs de
manipuler la base de données en même temps sans
générer de conflits d'accès.

Cela ne doit pas conduire à la perte de mises à jour.

32
Gestion de la confidentialité
Chaque utilisateur/catégorie d’utilisateurs dispose de
droits d’accès définis par l’administrateur de la base de
données. L’ensemble de ces droits d’accès constituent
la politique de confidentialité de la base de données.

Le SGBD doit garantir que cette politique de de

confidentialité soit respectée.

33
Bibliographie
 G. Gardarin, Bases de Données – objet/relationnel, Eyrolles, 1999.

 R. Ramakrishnan et J. Gehrke, Database Management Systems,

Second Edition, McGraw-Hill, 2000.

 T. Connoly, C. Begg et A. Strachan, Database Systems Apractical

Approach to Design, Implementation and Management, 1998.

 A. Silberschatz, H.F. Korth et S. Sudarshan, Database System

Concepts, McGraw-Hill, 1996.

 J.D. Ullman et J. Widom, A first Course in Database Systems,

Prentice Hall, 1997.

34