Notez - uOttawa

CSI 2532
----------------------------------------Bases de Données I
Professeur: Iluju Kiringa
[email protected]
http://www.site.uottawa.ca/~kiringa
SITE 5072
1
Survol des SGBDs
Chapitre 1
2
Objectifs
 Survol
du cours
 Définition d’un SGBD
 Motivations pour l’utilisation d’un SGBD
 Modèles des données
 Requêtes et manipulation des données
 Accès simultané aux données
 Architecture d’un SGBD
 Personnel impliqué dans les SGBDs
3
Survol du Cours
Sujet
Référence

Survol des SGBDs et introduction
Conception: modèle ER
Modèle relationnel
Algèbre et calcul relationnels
Contraintes et requêtes SQL
Chapitre 1
Chapitre 2
Chapitre 3
Chapitre 4
Chapitre 5

Semaine de relâche

Examen de mi-session en classe
Formes normales
Application des bases de données
Applications Internet
Fichiers, disques et indexes
Indexes: arbres et hachage
Design physique










Chapitres 1--5
Chapitre 19
Chapitre 6
Chapitre 7
Chapitres 8-9
Chapitres 10-11
Chapitre 20
4
Survol du Cours (Suite)

Manuel (Achetez le!)
 Raghu Ramakrishnan and Johannes Gehrke, Database
Management Systems, 3e Edition, McGraw Hill, 2003

Autre référence:
 R. Elmasri et S.B. Navathe, Conception et Architecture des Bases
de Données, 4e Edition

Charge de travail et évaluation
Devoirs:
15%
Mi-session:
25% (en classe)
Projet:
20% (En groupe de 3)
Examen Final: 40% (Voir calendrier des examens en temps
opportun)
IL FAUT AVOIR AU MOINS 50% A L‘ENSEMBLE DES EXAMENS
(MI-SESSION + FINAL) ET ASSISTER A AU MOINS 80% DES
CLASSES POUR PASSER LE COURS





5
Définition d’un SGBD

Les organisations font face à de larges quantités de
données qui doivent être gérées efficacement.
 Bien d’ enterprises entreposent des GBs, voire des TBs de données
 Quelques applications scientifiques entreposent des PBs de données


Une base de données est une très large collection de
données intégrées.
Un système de gestion des bases de données (SGBD)
 est un ensemble de logiciels conçus pour stocker et gérer des
bases de données
 modèle le monde réel des organisations:
•
•
Entités (p.ex., étudiants, cours, corps professoral et salle de cours)
Relation (p.ex., Michel est enrôlé dans CSI2532; Iluju enseigne CSI2532; le cours
CSI2532 a lieu dans la salle SITE2050)
6
Motivations (1)

Les systèmes de gestion des fichiers ont des
défauts:
 Chaque application doit elle-même déplacer de
large quantités de données entre la mémoire
principale et la mémoire secondaire
 Chaque application doit avoir une méthode
d’identification de toutes les données pour le cas
où le mode d’adressage sous-jacent ne suffit pas
(p.ex., un adressage 32-bits ne permet pas
d’accéder directement à tous les enregistrements
des données dépassant plus de 4GB.)
7
Motivations (2)

Défauts des systèmes de gestion des fichiers (suite)
 Besoin d’un code spécial pour différentes requêtes.
 Besoin de protéger les données d’inconsistances
dues aux multiples usagers simultanés qui
changent ces données.
 Besoin d’assurer un sauvetage (« crash recovery »)
consistant.
 Besoin de fournir plus de sécurité et de contrôle de
l’accès que le mécanisme de mots de passe offert
par les systèmes d’exploitation.
8
Motivations (3)

Pourquoi utiliser un SGBD?
 Indépendance des données: une application ne voit
pas les détails de la représentation et du stockage
des données.
 accès efficient: utilisation de méthodes de stockage
et d’accès très sophistiquées et efficientes.
 Temps de développement d’applications réduit:
les fonctionnalités d’un SGBD n’ont pas besoin
d’être dédoublées.
9
Motivations (4)

Pourquoi utiliser un SGBD? (Suite)
 Intégrité et sécurité des données: application des
contraintes d’intégrité et un contrôle d’accès.
 Administration uniforme de données: des
utilisateurs expérimentés administrent les données
utilisées par des utilisateurs inexpérimentés.
 accès concurrent, sauvetage ( « crash recovery » -reprise des plantages): un utilisateur accède aux
données sans tenir compte des autres utilisateurs du
système.
10
Motivations (5)

Pourquoi étudier les SGBDs?
 Le volume des données et leur diversité s’accroît
énormément.
•
•
Bibliothèques digitales, système de vidéo interactif, projet
du génome humain, l’exploration de Mars …
... Les besoins pour des SGBDs explosent
 La gestion efficiente d’une masse si diverse de
données implique des travaux dans la plupart
des sujets de recherche en informatique.
•
Génie logiciel, langues, théorie, IA, multimédia, logique,
etc.
11
Modèles des Données (1)

Un modèle des données est une collection d’éléments
de haut niveau servant à décrire les données.
 Un schéma est une description d’une collection particulière
de données utilisant un modèle précis des données.
 Une instance d’un schéma est un ensemble de données
organisées selon un schéma donné.

Le modèle relationnel est le plus répandu.



Concept principal: Relation
Schéma relationnel: décrit le nom et les attributs de la
dite relation.
Instance relationnelle: une table ayant des lignes et des
colonnes.
12
Modèle des Données (2)

Niveaux d’abstraction
 Les schémas des données
sont décrits à 3 niveaux
d’abstractions: vues, schéma
conceptuel et schéma physique.
•
•
•
Les Vues (schémas externes)
décrivent comment les
utilisateurs voient les données.
Un schéma conceptuel définit la
structure logique.
Un schéma physique décrit les
fichiers et les index à utiliser.
vue 1
vue 2
vue 3
schéma conceptuel
schéma physique
 Les schémas sont définis en
utilisant un langage de
définition de données (DDL).
13
Modèle de Données: Exemple

Base de Données Universitaires
 schéma conceptuel:
•
Students(sid: string, name: string, login: string,
•
age: integer, gpa: real)
Courses(cid: string, cname: string, credits: integer)
Enrolled(sid: string, cid: string, grade: string)
•
 schéma physique:
•
•
Relations stockées comme fichiers non triés (versus triés).
Index sur la première colonne de Students et Courses;
index sur les deux premières colonnes de Enrolled, etc.
 schéma externe (Vue):
•
Course_info(cid: string, enrollment: integer)
14
Modèle des Données (3)

Indépendance des Données: conséquence de la
distinction des niveaux d’abstraction
 Les applications sont isolées de la manière dont les
données sont structurées et stockées.
 Chaque niveau d’abstraction est protégé des
changements dans la structure du niveau inférieur.
 Indépendance logique: protection des changements dans la
structure logique des données.
 Indépendance physique: protection des changements dans
la structure physique des données.
15
Requêtes et Manipulation des Données

Une requête est une question au sujet des données
stockées.






Quel est le nom du professeur qui enseigne CSI2532?
Quel est le nombre total d’étudiants enrollés dans CSI2532?
Quel est le pourcentage d’étudiants ayant eu un A+ dans
CSI2532?
Un langage de requêtes est un langage spécialisé dans
lequel des requêtes peuvent être formulées et posées sur
une base de données.
Les données sont modifiées /requises en utilisant un
langage de manipulation des données (DML). Ainsi un
langage de requêtes est un sous langage d’un DML.
Le modèle relationnel supporte 2 langages de requêtes:


Calcul relationnel: langage de requêtes basé sur la logique
Algèbre Relationnelle: basée sur un ensemble d’opérateurs pour la
manipulation des relations.
16
Accès Simultané aux Données




L’exécution simultanée des programmes d’utilisation
est essentiel pour une bonne performance des
SGBDs.
L’exécution simultanée se fait par entrelacement des
actions de différents utilisateurs.
L’entrelacement peut conduire à des inconsistances
(incohérences): p. ex. lors d’un retrait d’argent
effectué pendant que la balance du compte est
calculée.
Le SGBD garantit que des inconsistances n’arrivent
pas: un utilisateur peut utiliser le système comme s’il
s’agissait d’un système à usager unique.
17
Accès Simultané: Transaction


Une transaction est une séquence atomique d’actions
sur la base de données (reads/writes) correspondant
à l’exécution d’un programme de transaction.
Chaque transaction, exécutée complètement, doit
laisser la BD dans un état consistant si la BD était
consistante au début de la transaction.



Les utilisateurs peuvent spécifier de simples contraintes
d’intégrité sur les données et le SGBD les appliquera.
Au delà de cela, le SGBD ne comprend pas la sémantique
des données. (p. ex. il ne comprend pas comment
calculer la moyenne cumulée sur un compte d’étudiant).
D’où, l’utilisateur est en dernier ressort responsable du
maintien de la consistance des données!
18
Accès Simultané: Planification des Transactions

Un SGBD garantit que l’exécution de {T1, ... , Tn} est
équivalente à une exécution sérielle de T1, ..., Tn.



Avant de lire/écrire un objet, une transaction requiert un verrou sur
cet objet et attend que le verrou soit libre. Tous les verrous sont
relâchés à la fin de la transaction. (verrouillage 2PL strict.)
Idée: Si une action de Ti (soit writes X) affecte Tj (qui pourrait être
entrain d’exécuter un reads X), un parmi les deux, soit Ti, doit
obtenir un verrou sur X d’abord et l’autre,Tj, sera forcé d’attendre
jusqu’a ce que Ti finisse; ceci entraîne que les transactions seront
effectivement ordonnées.
Si p. ex. Tj a déjà un verrou sur Y et Ti requiert plutard un verrou
sur Y, il y a dans ce cas un interblockage (deadlock)! Ti ou Tj est
annullé et redémarré!
19
Accès Simultané aux Données: Atomicité


Un SGBD garantit l’atomicité (propriété du « tout ou rien »)
même en cas de crash (plantage) au milieu de la transaction.
Idée: garder un journal (log) de toutes les actions exécutées
par le SGBD lors de l’exécution d’un ensemble de
transactions:


Avant que un changement ne soit fait sur une BD, l’entrée
correspondante dans le log est forcément stockée à un endroit sûr
(protocole WAL); les systèmes d’exploitation n’offrent souvent à ce
sujet qu’un support inadéquat.)
Après un changement, les effets de la transaction partiellement
exécutée sont défaits en utilisant le log. (Grâce au WAL, si une entrée
dans le log n’était pas sauvée avant le crash, le changement associé à
cette entrée n’a donc pas été appliqué à la base de données!)
20
Accès Simultané aux Données: le Log

Les actions suivantes sont enregistrées dans le log:

Ti écrit un objet: la vielle et la nouvelle valeurs sont enregistrées.
• L’enregistrement du log doit aller sur le disque avant la page qui a
changé!




“commit”/”abort” (validation/abandon): un enregistrement indiquant
une telle action est inscrite dans le log.
Les enregistrements du log sont chaînés sur base des
numéros d’identification des transactions. De la sorte, il est
facile de défaire une transaction donnée.
Le log est souvent archivé sur un stockage “stable”.
Toute activité relative au log (ainsi que toute autre activité
relative au contrôle d’accès simultané telle que
verrouillage/déverrouillage, traitement des deadlocks, etc.)
est traité de manière transparente par le SGBD.
21
Personnes Impliquées dans les BDs




Utilisateur final: accède seulement à une interface du
SGBD
Vendeurs de SGBDs: IBM, Oracle, Microsoft, etc
Chercheurs et programmeurs: inventent de nouvelles
théories et algorithmes pour les SGBDs et en écrivent le
code
Programmeurs d’applications: écrivent des programmes
C/C++/Java/… qui interagissent avec les SGBDs


P.ex. Webmasters avancés, programmeurs d’applications
Administrateur de base de données (DBA)




Conçoit les schémas logiques /physiques
Traite les questions de sécurité et d’autorisation
Assure la disponibilité des données (« crash recovery »)
Adapte la base de données à l’évolution des besoins
22
Architecture d’un SGBD



Un SGBD typique a une
architecture à plusieurs
couches (“layers”).
Notez que les modules d’accès
simultanés et de crash
recovery ne sont pas montrés.
Ceci est un parmi plusieurs
choix possibles d’architectures,
chaque système ayant ses
propres particularités.
Ces couches
doivent considérer
L’accès simultané et
Le crash recovery
exécution et optimisation
Des requêtes
Operateurs relationels
accès aux fichiers
Gestion de tampons
Gestion d’espace disque
DB
23
Historique (1)
Début des années 60: GE conçoit le 1er SGBD à
caractère général et basé sur le modèle réseau
 Fin des années 60s: IBM développe IMS qui est
basé sur le modèle hiérarchique
 Début des années 70: E. Codd introduit le modèle
relationnel pour résoudre les problèmes relatifs
aux modèles précédents
 Fin des années 70 et début 80: travaux sur le
traitement des transactions par Jim Gray et P.
Bernstein

24
Historique (2)


Années 80: L’utilisation des BDs relationnelles devient
courante dans les grandes entreprises, arrivée de
plusieurs vendeurs de SGBDs, standardisation de SQL,
le langage de requêtes pour les BDs relationnelles, etc
Fin 80 et début 90s: modèles de données plus riches
(orienté-objet, object-relationnel, etc) et des langages de
requêtes plus expressifs (Datalog, relations nichées, etc)
sont introduits
25
Historique (3)


Fin 90: les grands vendeurs étendent les SGBD
relationnel avec de nouveaux types de données
(images, texte, contenu multimédia, etc) ainsi que
avec les requêtes basé sur ces nouveaux types
Pendant toute l’histoire du développement des BDs:
 Reconnaissance scientifique: Turing Awards aux
chercheurs en BDs C. Bachman, E. Codd, et J. Gray
 Naissance d’une large industrie de plusieurs
milliards de dollars
26
Résumé

Un SGBD est utilisé pour maintenir et poser des requêtes à
de larges collections de données.

Les bénéfices comprennent le recouvrement du crash,
l’accès simultané, développement rapide des applications,
intégrité des données et sécurité.

Les niveaux d’abstraction entraînent l’indépendance des
données.
27
Résumé (Suite)

Un SGBD a généralement une architecture à niveaux.

Les chercheurs en BDs, les programmeurs et les
administrateurs ont des jobs de grande responsabilité et
sont bien payés!

La recherche et le développement en SGBDs est un
domaine large et excitant au sein de l’informatique;
le Canada y joue un rôle clé (3 conférences VLDB !).

Les BDs sont une industrie générant plus de 15 milliards
de dollars annuellement!
28