Introduction: Bases de Données Introduction Et Objectifs

1.
Introduction
Bases de données • Les entreprises gèrent des volumes de données très grands
– Giga, Terra, Péta –octets
Introduction et – Numériques, Textuelles, Multi‐média (images, films,...)
• Il faut pouvoir facilement
Objectifs – 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 salaire, Votre note en BD
– Données composées ex: Votre CV, vos résultats de l'année
– Identifiant humain ex: NSS ou machine: P26215
• Qu'est‐ce qu'une BD ?
– Collection de données structurées reliées par des relations
– Interrogeable et modifiable par des langages de haut niveau
La hiérarchie des mémoires Un peu d'histoire
Capacité Mémoire
vs terciaire • Années 60:
Coût & • Un accès disque est environ – Récipients logique de données  fichiers sur dique
Vitesse 100,000 fois plus lent qu’un – Accès séquentiel puis sur clé
• Lire (Nomf, Article), Ecrire (Nomf, Article)
accès mémoire! • Lire (Nomf, Article, Clé), Ecrire (Nomf, article, Clé)
Mémoire
5-10 ms •  • Années 70:
secondaire – Avènement des Bases de Données Réseaux (BD)
– Eviter les accès disques
– Ensemble de fichiers reliés par des pointeurs
• grande mémoire principale
– Langage d'interrogation par navigation
80-200 ns Mémoire principale – Amortir les accès disques
(
(RAM) ) • Années 80:
• placement des données
– Avènement des Bases de Données Relationnelles (BDR)
– Minimiser le nombre d’accès disques
– Relations entre ensemble de données
3-10 ns Cache (SRAM) • méthodes d’accès
– Langage d'interrogation par assertion logique
2-5 ns Registres
3 4
1
Systèmes de fichiers Format des fichiers Caractéristiques
Plusieurs applications
Caractéristiques  plusieurs formats
Talla Dika  plusieurs langages
Turlututusqjsk
Symptomes : y Symptom: yyyy
Turlututu : sqj Analyses xxxx
Symptomes : y
Turlututu : sdd Turlututudhjsd
Analyses : xxx Analyses :xx
Comptabilité Chirurgie
Problèmes Problèmes
 Difficultés de gestion
Consultations Psychiatrie
Achu Dongo
Turlututu : sq
Symptomes : yy Symptomyyyy

Analyses : xxxx Analysesxxxx
Symptomes : yy Turlututudhjsd
5 6
Redondance (données) Caractéristiques Interrogations Caractéristiques

Plusieurs applications Plusieurs applications
 plusieurs formats  plusieurs formats
 plusieurs langages Dika  plusieurs langages
ComptaSoft
Dika Talla
ChiruSoft
Talla Turlututusqjsk Turlututusqjsk
Symptom: yyyy Symptomes : y Symptom: yyyy
Symptomes : y
Turlututu : sqj
Symptomes : y
Analyses xxxx
Redondance de données Turlututu : sqj
Symptomes : y
Turlututu : sdd
Analyses xxxx
Turlututudhjsd
Redondance de données
Turlututudhjsd
Turlututu : sdd Analyses :xx
Analyses :xx Analyses : xxx
Analyses : xxx
Pas de facilité d’interrogation
 Question développement
 Difficultés de gestion  Difficultés de gestion
 Incohérence des données  Incohérence des données
 Coûts élevés
ConsultSoft
PsychiaSoft
Achu Dongo
Achu Dongo Turlututu : sq
Symptomes : yy
Turlututu : sq
Symptomyyyy
Symptomes : yy
Analyses : xxxx
Symptomyyyy
Analysesxxxx
 Maintenance difficile
Analyses : xxxx Analysesxxxx
7 8
2
Pannes ??? Caractéristiques Partage de données Caractéristiques
Plusieurs applications Plusieurs applications
 plusieurs formats  plusieurs formats
Dika  plusieurs langages  plusieurs langages
ComptaSoft
Talla
ChiruSoft
Turlututusqjsk
Dika
ComptaSoft
Talla
ChiruSoft
Symptomes : y Symptom: yyyy
Turlututu : sqj
Symptomes : y
Turlututu : sdd
Analyses xxxx
Turlututudhjsd
Redondance de données Symptomes : y
Turlututu : sqj
Turlututusqjsk
Symptom: yyyy
Analyses xxxx
Redondance de données
Analyses : xxx Analyses :xx Symptomes : y
Pas de facilité d’interrogation Turlututu : sdd
Analyses : xxx
Turlututudhjsd
Analyses :xx Pas de facilité d’interrogation
 Question développement  Question développement
Redondance de code Redondance de code
 Difficultés de gestion  Difficultés de gestion
 Incohérence des données  Incohérence des données
 Coûts élevés  Coûts élevés
ConsultSoft
PsychiaSoft
ConsultSoft
Dongo Achu
PsychiaSoft
Achu Dongo
Turlututu : sq
Turlututu : sq
Symptomes : yy
Analyses : xxxx
Symptomyyyy
Analysesxxxx  Maintenance difficile Symptomes : yy
Analyses : xxxx Symptomyyyy
Analysesxxxx
Turlututudhjsd Symptomes : yy
 Gestion de pannes ???  Gestion de pannes ???

Symptomes : yy
Turlututudhjsd
 Partage des données ???

9 10
Confidentialité Caractéristiques
Plusieurs applications
 plusieurs formats
L’approche ‘‘Bases de données’’
 plusieurs langages
ComptaSoft
Talla Dika
ChiruSoft
Turlututusqjsk
Symptomes : y
Turlututu : sqj
Symptomes : y
Turlututu : sdd
Analyses : xxx
Symptom: yyyy
Analyses xxxx
Turlututudhjsd
Analyses :xx
Redondance de données • Modélisation des données
Pas de facilité d’interrogation
 Question développement
 Eliminer la redondance de données
Redondance de code  Centraliser et organiser correctement les données
 Plusieurs niveaux de modélisation
Problèmes  Outils de conception
 Difficultés de gestion
 Incohérence des données • Logiciel «Système de Gestion de Bases de Données»
 Coûts élevés
Factorisation des modules de contrôle des applications
PsychiaSoft
ConsultSoft
Achu Dongo
Turlututu : sq
Symptomes : yy Symptomyyyy
Analyses : xxxx
Symptomes : yy
Analysesxxxx
Turlututudhjsd  Gestion de pannes ??? ‐ Interrogation, cohérence, partage, gestion de pannes, etc…

 Partage des données ???
Administration facilitées des données
 Confidentialité ??? 11 12
3
Modélisation du réel Modélisation Relationnelle (1)
Champs, attributs,
Relation ou table
Réel colonnes
• Indépendant du
Modèle modèle de données
Id-D Nom Prénom
• Indépendant du
conceptuel SGBD Médecin effectue Visite 1 Talla Pierre
2 Bouba Paul
• Dépendant du 3 Kamga Jean
Codasyl Relationnel Objet XML …. …….. ……
• Indépendant du
logique SGBD
Modèle • Dépendant du
modèle de données
• Organisation physique des données
Tuples, lignes ou n‐
• Structures de stockage des données
Physique • Dépendant du SGBD • Structures accélératrices (index)
uplets
13 14
Modélisation Relationnelle (2) 2. Objectifs des SGBD
Docteurs Prescriptions
Id-D Nom Prénom Id-V Ligne Id-M Posologie I‐ Indépendance
1 Talla Pierre Physique
Visites 1 1 12 1 par jour
2 Bouba Paul 1 2 5 10 gouttes
Id-D Id-P Id-V Date Prix X ‐ Standards II‐ Indépendance
3 Kamga Jean 2 1 8 2 par jour Logique
1 2 1 15 juin 250
…. …….. …… 2 2 12 1 par jour
1 1 2 12 août 180 IX ‐ Gestion de la III – Langage de
2 2 3 13 juillet 350 2 3 3 2 gouttes confidentialité manipulation
2 3 4 1 mars 250 …. …. …. …………

VIII ‐ Concurrence BD IV ‐ Gestion des
d’accès vues
Patients
VII ‐ Gestion des V ‐ Optimisation des
Id-P Nom Prénom Ville Médicaments pannes questions
1 Abena Jacques Paris Id-M Nom Description
1 Aspegic 1000 …………………………….. VI ‐ Gestion de la
2 Niba Zoe Evry
cohérence
3 Kana John Paris 2 Fluisédal ……………………………..
4 Haman Paule Valenton 3 Mucomyst ……………………………..
…. ……. ……. ……. …. …….. ……………………………..
15 16
4
I ‐ Indépendance Physique II ‐ Indépendance Logique
• Indépendance des programmes d'applications Les applications peuvent définir des vues logiques de la BD
vis à vis du modèle physique : Gestion des médicaments Cabinet du Dr. Kamga
Nombre_Médicaments Prescription
– Possibilité de modifier les structures de stockage
Id -V Ligne Id -M Posologie
Id-M Nom Description Nombre Visites
1 1 12 1 par jour
Id -D Id - P Id -V Date Prix
1 2 5 10 gouttes
1 Aspegic 1000 …………………………….. 30 1 2 1 15 juin 250
…. …. …. …………
2 3 4 1 mars 250
(fichiers, index, chemins d'accès, …) sans modifier 2
3
Fluisédal
Mucomyst
……………………………..
……………………………..
20
230 Id - P
Patients
Nom Prénom
Id - M Nom
Médicament
Description
les programmes;
1 Abena Jacques
…. …….. …………………………….. ….. 2 Niba Zoe 1 Aspegic 1000 ……………………………..
…. ……. ……. 2 Fluisédal ……………………………..

3 Mucomyst ……………………………..
…. …….. ……………………………..
– 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. I d- D
1
2
3
….
D o cteu r
N om
D up o n t
D ur an d
M asse
… … ..
Prén om
Pierr e
Pau l
Jean
……
I d- D
1
1
2
2
V is ite s
Id -P
2
1
2
3
Id -V
1
2
3
4
D a te
1 5 juin
1 2 ao ût
1 3 juille t
1 m ar s
P rix
25 0
18 0
35 0
25 0
Id- V
….
1
1
2
2
2
P r es cr ip tio n
L ig n e
1
2
1
2
3
….
Id- M
12
5
8
12
3
….
Po so lo gie
1 p ar jo u r
1 0 g ou ttes
2 p ar jo u r
1 p ar jo u r
2 go u ttes
… …… …
P a tie n ts
17 Id -P
1
2
3
N om
Leb eau
Tro g er
Do e
Prén om
J acq ues
Zo e
Jo h n
Id- M
1
2
N om
M é d ica m e nt
As peg ic 1 0 0 0
F lu iséd al
D escrip tio n
… … … … … … … … … … … ..
… … … … … … … … … … … ..
18
4 P err y Pau le 3 M u com y st … … … … … … … … … … … ..
…. …… . … …. …. … … .. … … … … … … … … … … … ..
Avantages de l’indépendance logique III ‐ Manipulation aisée

• Possibilité pour chaque application d'ignorer les besoins • La manipulation se fait via un langage déclaratif
des autres (bien que partageant la même BD). – La question déclare l’objectif sans décrire la méthode
• Possibilité d'évolution de la base de données sans – Le langage suit une norme commune à tous les SGBD
réécriture des applications : – SQL : Structured Query Langage
– ajout de champs, ajout de relation, renommage de champs. • Sémantique
• Possibilité d'intégrer des applications existantes sans – Logique du 1er ordre ++
modifier les autres. • Syntaxe (aperçu !)
– SELECT <structure des résultats>
• Possibilité de limiter les conséquences du partage :
– FROM <relations>
Données confidentielles.
– WHERE <conditions>
19 20
5
IV – Des vues multiples des données V –Exécution et Optimisation
• Les vues permettent d’implémenter l’indépendance • Traduction automatique des questions déclaratives en
logique en permettant de créer des relations programmes procéduraux :
virtuelles  Utilisation de l’algèbre relationnelle
• Vue = Question stockée
• Optimisation automatique des questions
• Le SGBD stocke la définition et non le résultat
 Utilisation de l’aspect déclaratif de SQL
• Exemple :
 Gestion centralisée des chemins d'accès (index, hachages, …)
– la vue des patients parisiens
 Techniques d’optimisation poussées
– la vue des docteurs avec leurs patients
– La vue des services statistiques • Economie de l'astuce des programmeurs
– ...
– milliers d'heures d'écriture et de maintenance de logiciels.
21 22
VI ‐ Intégrité Logique Contraintes d’intégrité

• Objectif : Détecter les mises à jour erronées • Avantages :
– simplification du code des applications
• Contrôle sur les données élémentaires
– sécurité renforcée par l'automatisation
– Contrôle de types: ex: Nom alphabétique
– mise en commun des contraintes
– Contrôle de valeurs: ex: Salaire mensuel entre 5 et 50kf
• Contrôle sur les relations entre les données • Nécessite :
– Relations entre données élémentaires:
– un langage de définition de contraintes d'intégrité
• Prix de vente > Prix d'achat
– Relations entre objets: – la vérification automatique de ces contraintes
• Un électeur doit être inscrit sur une seule liste électorale
23 24
6
VII ‐ Intégrité Physique Transaction
• Motivations : Tolérance aux fautes
– Transaction Failure : Contraintes d'intégrité, Annulation
– System Failure : Panne de courant, Crash serveur ... Incohérence possible...
Etat cohérent Etat cohérent
– Media Failure : Perte du disque
– Communication Failure : Défaillance du réseau Begin Commit
• Objectifs : Transaction
– Assurer l'atomicité des transactions
– Garantir la durabilité des effets des transactions commises Begin
• Moyens : CEpargne = CEpargne - 3000
– Journalisation : Mémorisation des états successifs des
données CCourant = CCourant + 3000
– Mécanismes de reprise Commit T1
25 26
Atomicité et Durabilité VIII ‐ Partage des données
ATOMICITE DURABILITE
BD
Panne
Begin Begin
CEpargne = CEpargne - 3000 CEpargne = CEpargne - 3000
CCourant = CCourant + 3000 CCourant = CCourant + 3000
Commit T1 Commit T1
Crash disque
 Annuler le débit !!  S’assurer que le

• Accès concurrent aux mêmes données
virement a été fait !
27
Conflits d’accès !! 28
7
Isolation et Cohérence IX – Confidentialité
• Objectif : Protéger les données de la BD contre des
accès non autorisés
BD
• Deux niveaux :
– Connexion restreinte aux usagers répertoriés (mot de
passe)
– Privilèges d'accès aux objets de la base
• Le SGBD gère les accès concurrents
• Usagers : Usager ou groupe d’usagers
 Chacun à l’impression d’être seul (Isolation)
 Cohérence conservée (Pas de maj conflictuelles) • Objets : Relation, Vue, autres objets (procédures, etc.)
29 30
X ‐ Standardisation 3. Architecture des SGBD

 Les architectures physiques de SGBD sont très liées au mode de
• L’approche bases de données est basée sur plusieurs répartition.
standards — BD centralisée
– Langage SQL (SQL1, SQL2, SQL3) — BD client/serveur
– Communication SQL CLI (ODBC / JDBC) — BD client/multi-serveurs
– Transactions (X/Open DTP, OSI‐TP) — BD répartie
— BD hétérogène
• Force des standards — BD mobile
– Portabilité  Le challenge se déplace des Péta-bases aux Pico-bases.
– Interopérabilté — Péta-bases => parallélisme et grandes mémoires
– Applications multisources… — Pico-bases => faible empreinte et forte sécurité
31
8
Architecture centralisée Architecture client‐serveur
Clients intelligents
Terminaux passifs
Appli 1
Appli 2
Appli n réseau
réseau
serveur
Mainframe
Appli 1 Appli 2 Appli n
SGBD
SGBD
données code données
33
Architecture Client‐Multiserveurs Architecture répartie
Appli 1
Appli 1 Appli 2
SQL SQL Appli n
ODBC ODBC
SQL
SQL
SGBD 1 SGBD 2
SGBD 1 SGBD 2 code données code données
code données code données

35
9
Architecture mobile 4. Applications traditionnelles
des SGBD
Clients intelligents
mobiles
• OLTP (On Line Transaction Processing)
Données répliquées
Réseau sans fil
– Cible des SGBD depuis leur existence
et/ou personnelles
– Banques, réservation en ligne ...
– Très grand nombre de transactions en parallèle
serveur
– Transactions simples
SGBD • OLAP (On Line Analytical Processing)

– Entrepôts de données, DataCube, Data Mining …
code données
– Faible nombre de transactions
38
– Transactions très complexes
Evolution des BD
BD BD BD ‘light’ PicoDBMS
d’entreprise personnelles (PDA / Tél.) carte à puce
Capacité
Prix
Nombre
39
10
Modélisation E/R 1. Objectifs de la Modélisation
des Données • Permettre une meilleure compréhension
– Le monde réel est trop complexes
1. Objectifs et principes
2. Le modèle Entité‐Association (E/R) – Abstraction des aspects cruciaux du problème
3. Passage au relationnel – Omission des détails
4. Conclusion • Permettre une conception progressive
– Abstractions et raffinements successifs
– Possibilité de prototypage rapide
– Découpage en modules ou packages
– Génération des structures de données (et de traitements)
1 2
HT - 2011 HT - 2011
Élaborer un modèle conceptuel Dériver le schéma de la BD
• Isoler les concepts fondamentaux • Schéma
– Définition de tous les types de données de la base et de leurs liens
– Que vont représenter les données de la BD ? • Agrégation de données
– Découvrir les concepts élémentaires du monde réel – Type élémentaire (de base): Entier, Réel, String, ...
– Type complexe (composé): Collection de types élémentaires
– Décrire les concepts agrégés et les sous‐concepts • Tuple :
– Exemple: Type Personne (nom: String, Prenom: String, age: Réel)
• Faciliter la visualisation du système – Instance ou occurrence Personne("Dupont", "Jules", 20)
• Set :
– Diagrammes avec notations simple et précise – Exemple : Voitures {id:String}; Voitures {"75AB75", "1200VV94"}
– Compréhension visuelle et non seulement • Bag, List, ...
intellectuelle • Possibilité d'intégrer des relations entre données (liens)
– Exemple : Personne  Voitures; "Dupont"  "75AB75"
3 4
HT - 2011 HT - 2011
Page 1
Modélisation à plusieurs niveaux Générations de méthodes
• Méthodes d'analyse et de décomposition hiérarchiques
Réel – 1e génération basée sur des arbres fonctionnels
– Diviser pour régner (Problème ‐‐> Sous‐problème)
– Warnier, SADT, Jackson, De Marco
Indépendant du
• Méthodes d'analyse et de représentation systémiques
Indépendant du – 2e génération basée sur entité‐association
conceptuel SGBD Médecin effectue Visite – Séparation des données et traitements
Dépendant du
– Merise, Axial, SSADM
Codasyl Relationnel Objet XML
• Méthodes d'analyse et de conception orientées objets
Indépendant du – 3e génération basée sur les objets
logique SGBD
– Réconciliation données et traitements
Dépendant du  Organisation physique des données – Réutilisation de composants
 Structures de stockage des données
Dépendant du
Physique SGBD  Structures accélératrices (index)
5 6
HT - 2011 HT - 2011
2. Le Modèle Entité – Association (E/R
Objectifs des méthodes
Model)
• Réduire la distance sémantique entre le langage des utilisateurs et • Ensemble de concepts pour modéliser les données
le langage des concepteurs
– meilleure communication entre utilisateurs et concepteurs
d'une application (d'une entreprise)
– abstraction du réel perçu en termes compréhensibles et visibles • Ensemble de symboles graphiques associés
• Regrouper l'analyse des données et des traitements
– meilleure compréhension des choses
– plus grande cohérence entre l'aspect statique et l'aspect dynamique • Formalisé en 1976 par P. Chen
• Simplification des transformations entre niveau conceptuel et
niveau interne • Etendu vers E/R généralisé puis vers l'objet
– implémentation directe éventuelle du schéma conceptuel
– établissement possible de règles de transformations automatisées
7 8
HT - 2011 HT - 2011
Page 2
Exemple de modèle E/R Entité
N om Type N SS N om Prénom
C ouleur D ate
NP
• Un objet du monde réel qui peut être identifié et
PR O D U ITS
(0,N )
A C H ETE
(0,N )
C LIEN TS
que l'on souhaite représenter
(1,N )
– La classe d'entité correspond à une collection d'entités
Prix décrites par leur type commun (le format)
V EN D
R em ise – L'instance d'entité correspond à un élément particulier
(0,N ) de la classe d'entité (un objet)
FO U R N ISSEU R S – Attention: on dit entité pour les deux ! Comprendre
selon le contexte.
NF N om R égion
• Il existe généralement plusieurs entités dans une
classe
9 10
HT - 2011 HT - 2011
Représentation Exemple d'instance
• Rectangle avec attributs (UML)
Voiture
Nveh: 75AB75
Voitures Nom Type: Mégane

Nveh: Int Marque: Renault
Type: String Vitesse: 120
Marque: String Attribut : Type Voitures
Km : 54000
Vitesse: Int
Km : Int Nveh: Int
• Rectangle avec attributs accrochés (E/R) Type: String
Marque: String
Voiture

Vitesse: Int
Km : Int Nveh: 850VV94
Type: 407
Voitures Marque: Peugeot
Vitesse: 0
Km : 4000
Nveh Type Marque Vitesse Km
11 12
HT - 2011 HT - 2011
Page 3
Attribut Identifiant ou Clé
• Description des propriétés des entités • Un identifiant aussi appelé clé est un attribut qui permet de
• Toutes les instances d'une entité ont les mêmes attributs retrouver une instance d'entité unique à tout instant parmi celles
– Attribut simple: attribut ayant une valeur d'un type de base de la classe.
– Exemple: NVeh dans Voitures, NSS dans Personnes
– Attribut composé: attribut constitué d'un groupe d'attributs
– Attribut multi‐valué: attribut pouvant avoir plus d'une valeur • Un identifiant peut être constitué de plusieurs attributs (clé
composée)
• Avec le modèle E/R de base tout attribut est simple
– Exemple:
• Avec le modèle E/R étendu, les attributs peuvent etre • [N° , Rue, Ville] pour Maisons
complexes • [Nom, Prénom] pour Personnes
– Composés et multi‐valués
13 14
HT - 2011 HT - 2011
Association Association: quelques définitions
• Les entités sont reliées ensemble par des associations • Association (Association)
– Une relation entre des instances de deux (ou plus) classes
– Entre instances: par exemple 1 véhicule est associé à 1
personne • Lien (Link)
– Une instance d'association
– Entre classes: abstraction des associations entre instances
• Rôle (Role)
• Une association peut avoir des attributs (propriétés) – Une extrémité d'une association
• Elle peut relier plusieurs entités ensemble • Attribut de lien (Link attribute)
– Un attribut de l'association instancié pour chaque lien
• Il est possible de distinguer le rôle d'une entité (elle • Cardinalité (Multiplicity)
peut en avoir plusieurs) – Le nombre d'instance d'une entité pour chaque instance de l'autre
15 16
HT - 2011 HT - 2011
Page 4
Représentation Degré d'une association
UML E/R
M# Nom …
Personne Voiture
Personne Voiture
Possède Possède
Propriétaire Possédée Pièces I# Nom … Modèle
Propriétaire Possédée
Composant Composé
Date Ingénieur Suivi
Date Prix
Prix
Date Pièce
Composée_de Rôle
Buveurs Vins …
Buveurs Abus Vins P# Des. …
Abus
Abus Estbu • La plupart des associations sont de degré 2
Abus Estbu
Date Quantité
(binaires)
Date
Quantité
17 18
HT - 2011 HT - 2011
Cardinalité d'une association Cardinalités min et max
• 1:1 • Cardinalité maximum
Habite
– Indique le nombre maximum d'instances d'une classe
Personne Adresse
d'entité participant à une association
• 1:N
Personne Possède Voiture • Cardinalité minimum
– Indique le nombre minimum d'instances d'une classe
• N:M d'entité participant à une association
Vendeur Vend Produit
[1,N] [0,7]
Etudiant Passe Examen
19 20
HT - 2011 HT - 2011
Page 5
Cardinalités: notations UML Exemple
1 1 Possède
Voiture Personne
nv 1 0..* nss
* plusieurs (0 à N)
marque nom
0..1 type prenom
optionnel (0 ou 1) date
puissance datenais
prix
couleur
1..* obligatoire (1 ou plus)
0..*
ordonné (0 à N)
{ord}
3..5 limité (de 3 à 5)
21 22
HT - 2011 HT - 2011
Domaines La pratique de la conception
• Ensemble nommé de valeurs • Bien comprendre le problème à résoudre
– Un attribut peut prend valeur dans un domaine
• Essayer de conserver le modèle simple
– Généralisation des types élémentaires
• Exemples • Bien choisir les noms
– Liste de valeurs (1,2,3) • Ne pas cacher les associations sous forme d'attributs
– Type contraint (<0< int <100) – utiliser les associations
• Permettent de préciser les valeurs possibles des attributs • Faire revoir le modèle par d'autres
• Réduisent les ambiguïtés – définir en commun les objets de l’entreprise
• Documenter les significations et conventions
– élaborer le dictionnaire
23 24
HT - 2011 HT - 2011
Page 6
3. Passage au relationnel Traduction des associations
• Implémentations des entités et associations sous • Règle de base
– Une association est représentée par une table dont le schéma est le nom de
forme de tables l'association et la liste des clés des entités participantes suivie des attributs
de l'association
– mémorisent les états des entités et liens – Exemples :
• POSSEDE (N° Ss, N° Veh, Date , Prix )
– pas nécessaire d'avoir une BD E/R
• ABUS (Nv, Nb, Date, Quantité)
• Les attributs correspondent aux colonnes des • Amélioration possible
– Regrouper les associations 1 ‐‐> n avec la classe cible
tables – Exemple :
– nom attribut  nom colonne • VOITURE (N°VEH, MARQUE, TYPE, PUISSANCE, COULEUR)
• POSSEDE (N° SS, N° VEH, DATE , PRIX )
– Ensemble de valeurs  domaine • regroupés si toute voiture a un et un seul propriétaire
25 26
HT - 2011 HT - 2011
Exemple 6. Conclusion
• Intérêt de l’utilisation d’une méthode de conception
Buveurs Vins – proche du monde réel
nv
nb 1..* Boire *
Estbu
cru – démarche sémantique claire
nom Abus millésime
type degré – diagramme standards
Abus
Date • Passage au relationnel semi‐automatique
Quantité
À cause de la cardinalité min de 1. – outils du commerce utilisables (Objecteering, Rose, etc.)
– supporteront les extensions objet‐relationnel à venir
BUVEURS (NB REF ABUS.NB, NOM, TYPE) • Extensions à venir avec la conception objet
VINS (NV, CRU, MILLESIME, DEGRE)
ABUS(NB REF BUVEURS, NV REF VINS, DATE, QUANTITE)
À cause de l'association (obligatoire).

27 28
HT - 2011 HT - 2011
Page 7
1. CONCEPTS DESCRIPTIFS
• Ensemble de concepts pour formaliser la
LE MODELE RELATIONNEL description d'articles de fichiers plats
Inventé par T. Codd (IBM Recherche)
Publication ACM 1970
• Modèle standardisé mais extensible
1. Concepts pour la description – Introduction de types de données variés (SQL2)
2. Concepts pour la manipulation
3. Concepts additionnels – Introduction de la dynamique (produits, SQL3)
– Introduction des objets (SQL3)
Le Relationnel 1 Le Relationnel 2
Domaine Produit cartésien
• ENSEMBLE DE VALEURS • LE PRODUIT CARTESIEN D1x D2x ... x Dn
• Exemples: EST L'ENSEMBLE DES TUPLES (N‐UPLETS)
– ENTIER
– REEL <V1,V2,....Vn> TELS QUE Vi  Di
– CHAINES DE CARACTERES
– EUROS
• Exemple:
– SALAIRE = {4 000..100 000} – D1 = {Vert,Jaune,Rouge}
– COULEUR= {VERT, ROUGE, JAUNE} Vert Vrai
– D2 = {Vrai, Faux}
– POINT = {(X:REEL,Y:REEL)} Vert Faux
– TRIANGLE = {(P1:POINT,P2:POINT,P3:POINT)} Jaune Vrai
Jaune Faux
Rouge Vrai
Rouge Faux
Page 1
Relation Attribut
• SOUS‐ENSEMBLE DU PRODUIT CARTESIEN • VISION TABULAIRE DU RELATIONNEL
D'UNE LISTE DE DOMAINES – Une relation est une table à deux dimensions
– Une ligne est un tuple
– Un nom est associé à chaque colonne afin de la repérer
• Une relation est caractérisée par un nom indépendamment de son numéro d'ordre
• Exemple: CoulVins Coul Choix • ATTRIBUT

– D1 = COULEUR
Vert Faux – nom donné à une colonne d'une relation
Jaune Vrai
– prend ses valeurs dans un domaine
– D2 = BOOLEEN Rouge Vrai
Graphe d'une relation Exemple de relation
• Relation binaire R(A1,A2)
• Une relation n‐aire est une DOM(A1)
DOM(A2)
généralisation à n 1 VINS CRU MILL REGION COULEUR

a
dimensions 2
CHENAS 1983 BEAUJOLAIS ROUGE
DOM(A2) b TOKAY 1980 ALSACE BLANC
3 TAVEL 1986 RHONE ROSE
4 • c
CHABLIS 1986 BOURGOGNE BLANC
3 • 4 ST‐EMILION 1987 BORDELAIS ROUGE
2 •
1 • •
a b c DOM(A1)
Page 2
Clé Schéma
• GROUPE D'ATTRIBUTS MINIMUM QUI DETERMINE UN • NOM DE LA RELATION, LISTE DES ATTRIBUTS AVEC DOMAINES, ET
LISTE DES CLES D'UNE RELATION
TUPLE UNIQUE DANS UNE RELATION • Exemple:
• Exemples: – VINS(NV: Int, CRU:texte, MILL:entier, DEGRE: Réel, REGION:texte)
– Par convention, la clé primaire est soulignée
– {CRU,MILLESIME} DANS VINS ==> NV
• INTENTION ET EXTENSION
– NSS DANS PERSONNE – Un schéma de relation définit l'intention de la relation
– Une instance de table représente une extension de la relation
• CONTRAINTE D'ENTITE
• SCHEMA D'UNE BD RELATIONNELLE
– Toute relation doit posséder au moins une clé documentée – C'est l'ensemble des schémas des relations composantes
Clé Etrangère Exemple de Schéma
• GROUPE D'ATTRIBUTS DEVANT APPARAITRE COMME • EXEMPLE
CLE DANS UNE AUTRE RELATION BUVEURS (NB, NOM, PRENOM, TYPE)
• Les clés étrangères définissent les contraintes VINS (NV, CRU, MILL, DEGRE)
d'intégrité référentielles ABUS (NB, NV, DATE, QUANTITE)
– Lors d'une insertion, la valeur des attributs doit exister dans la
relation référencée
– Lors d'une suppression dans la relation référencée les tuples • CLES ETRANGERES
référençant doivent disparaître ABUS.NV REFERENCE VINS.NV
– Elles correspondent aux liens entité‐association obligatoires
ABUS.NB REFERENCE BUVEURS.NB
Page 3
Diagramme des Liens Concepts Descriptifs : Bilan
• RELATION ou TABLE
NB NOM PRENOM TYPE VINS
BUVEURS NV CRU MILL. DEGRE
• ATTRIBUT ou COLONNE
• DOMAINE ou TYPE Questions ?
• CLE
• CLE ETRANGERE
ABUS NB NV DATE QUANTITE
Synthèse : Create Table 2. CONCEPTS MANIPULATOIRES
• CREATION DES TABLES EN SQL • Un ensemble d'opérations formelles
– CREATE TABLE <relation name>
– (<attribute definition>+) – Algèbre relationnelle
– [{PRIMARY KEY | UNIQUE} (<attribute name>+)] • Ces opérations permettent d'exprimer toutes les
• avec :
– <attribute definition> ::= <attribute name> <data type>
requêtes sous forme d'expressions algébriques
– [NOT NULL [{UNIQUE | PRIMARY KEY}] ] • Elles sont la base du langage SQL
• Exemple :
– Paraphrasage en anglais des expressions relationnelles
– CREATE TABLE VINS
– ( NV INTEGER PRIMARY KEY – Origine SEQUEL
– CRU CHAR VARYING
– MILL INTEGER NOT NULL,
• Ces opérations se généralisent à l'objet
– DEGRE FIXED 5.2 ) – Algèbre d'objets complexes
Page 4
Opérations Ensemblistes Projection
• Opérations pour des relations de même schéma
– UNION notée 
• Elimination des VINS Cru Mill Région Qualité
– INTERSECTION notée 
– DIFFERENCE notée —
attributs non désirés et VOLNAY 1983 BOURGOGNE A
VOLNAY 1979 BOURGOGNE B
suppression des tuples CHENAS 1983 BEAUJOLAIS A
• Opérations binaires
en double JULIENAS 1986 BEAUJOLAIS C
– Relation X Relation ‐‐> Relation
• Extension • Relation ‐> Relation Cru,Région
– Union externe pour des relations de schémas différents
notée: (VINS) Cru Région
– Ramener au même schéma avec des valeurs nulles  A1,A2,...Ap (R) VOLNAY BOURGOGNE

CHENAS BEAUJOLAIS
JULIENAS BEAUJOLAIS
Restriction Exemple de Restriction
• Obtention des tuples de R satisfaisant un critère Q
• Relation ‐>Relation, notée Q(R) VINS Cru Mill Région Qualité
VOLNAY 1983 BOURGOGNE A
• Q est le critère de qualification de la forme : VOLNAY 1979 BOURGOGNE B
– Ai Valeur CHENAS 1983 BEAUJOLAIS A
–  { =, <, >=, >, <=, !=} JULIENAS 1986 BEAUJOLAIS C
MILL>1983
• Il est possible de réaliser des "ou" (union) et des "et"
(intersection) de critères simples
VINS Cru Mill Région Qualité
JULIENAS 1986 BEAUJOLAIS C
Page 5
Jointure Exemple de Jointure
• Composition des deux relations sur un domaine commun
• Relation X Relation ‐>Relation VINS Cru Mill Qualité
VOLNAY 1983 A
– notée
VOLNAY 1979 B
• Critère de jointure CHABLIS 1983 A
– Attributs de même nom égaux : JULIENAS 1986 C
• Attribut = Attribut LOCALISATION Cru Région QualMoy
• Jointure naturelle VOLNAY Bourgogne A

CHABLIS Bourgogne A
– Comparaison d'attributs :
CHABLIS Californie B
• Attribut1  Attribut2
• Théta‐jointure VINSREG Cru Mill Qualité Région QualMoy
VOLNAY 1983 A Bourgogne A
VOLNAY 1979 B Bourgogne A
CHABLIS 1983 A Bourgogne A
Le Relationnel 21 Le Relationnel CHABLIS 1983 A Californie B22
Complétude SQL
• L'algèbre relationnelle est complète • Une requête SQL est un paraphrasage d'une expression de
l'algèbre relationnelle en anglais
– Les cinq (sept) opérations de base permettent de formaliser
sous forme d'expressions toutes les questions que l'on peut • Requête élémentaire :
SELECT A1, A2, …Ap
poser avec la logique du premier ordre (sans fonction).
FROM R1, R2, …Rk
• Exemple : WHERE Q [{UNION |INTERSECT | EXCEPT } … ]
– Nom et prénom des buveurs de volnay 1988 ? • Sémantique du bloc select :
PROJECT (NOM, PRENOM, PROJECT A1,A2,…Ap (
RESTRICT Q (
RESTRICT(CRU="VOLNAY" et MILL =1988,
PRODUIT ( R1, R2, …, Rk) ) )
JOIN(VINS, ABUS, BUVEURS)))
Page 6
3. CONCEPTS ADDITIONNELS Fonction et Agrégat
• Ensemble de concepts pour : • FONCTION
– Etendre les fonctionnalités de manipulation – Fonction de calcul en ligne appliquée sur un ou plusieurs
attributs
– Décrire les règles d'évolution des données
– Exemple : DEGRE * QUANTITE / 100
– Supporter des objets complexes (SQL3)
• AGREGAT
• Introduits progressivement dans le modèle :
– Partitionnement horizontal d'une relation selon les valeurs
– Complique parfois le modèle d'un groupe d'attributs, suivi d'un regroupement par une
– Standardisés au niveau de SQL3 (1999) fonction de calcul en colonne (SUM, MIN, MAX, AVG, COUNT,
…)
– Des extensions multiples …
Exemples d'agrégats Vue
• Relation d'un schéma externe déduite des relations de la base
VINS CRU MILL DEGRE QUANTITE
par une question
CHABLIS 1977 10.9 100 • Exemple : GrosBuveurs
1987 11.9
CHABLIS 250
• CREATE VIEW GrosBuveurs AS
VOLNAY 1977 10.8 400
VOLNAY 1986 11.2 300
• SELECT NB, Nom, Prénom,
MEDOC 1985 11.2 200 • FROM Buveurs, Abus
• WHERE Buveurs.NB = Abus.NB and Abus.Quantité > 100
SELECT AVG(DEGRE) FROM
VINS; SELECT CRU, SUM(QUANTITE) • Calcul de la vue
FROM VINS
AVG DEGRE GROUP BY CRU; – Une vue est une fenêtre dynamique sur la BD et est recalculée à chaque
11.2 accès.
– Une vue peut être matérialisée (vue concrète).
SUM CRU QUANTITE
CHABLIS 350
VOLNAY 700
Le Relationnel MEDOC 200 27 Le Relationnel 28
Page 7
Déclencheur (Trigger) Déclencheur avec condition (Règle)
• Action base de données déclenchée suite à l'apparition d'un • Il est possible d'ajouter une condition afin de
événement particulier
déclencher l'action seulement quand la condition est
• Forme :
– {BEFORE | AFTER} <événement> THEN <action>
vérifiée
– Un événement peut être : – Une condition est une qualification portant sur la base.
• une opération sur une table (début ou fin)
• un événement externe (heure, appel,etc.)
• Exemples :
– Une action peut être : BEFORE UPDATE EMPLOYE
• une requête BD (mise à jour) IF SALAIRE > 100.000
• Une annulation (abort) de transaction
• l'appel à une procédure cataloguée
THEN ABORT TRANSACTION
4. CONCLUSION
• Un ensemble de concepts bien compris et bien
formalisés
• Un modèle unique, riche et standardisé
– intégration des BD actives
– intégration des BD objets
• Un formalisme qui s'étend plutôt bien
– algèbre d'objets
• Un langage associé défini à plusieurs niveaux
– SQL1, 2, 3
Le Relationnel 31
Page 8
1. Origines et Evolutions
• SQL est dérivé de l'algèbre relationnelle et de SEQUEL
• Il a été intégré à SQL/DS, DB2, puis ORACLE, INGRES, …
LE LANGAGE DE REQUETES SQL • Il existe trois versions normalisées, du simple au complexe
:
– SQL1 86 version minimale
– SQL1 89 addendum (intégrité)
Origines et Evolutions – SQL2 (92) langage complet à 3 niveaux
SQL1 86: la base • Une version 3 étendue (objets, règles) est la norme 99.
SQL1 89: l'intégrité • La plupart des systèmes supportent SQL2 complet
HT-2011 1 HT-2011 2
Opérations Organisation du Langage

• Opérations de base • SQL comprend quatre parties :
– SELECT, INSERT, UPDATE, DELETE • Le langage de définition de schéma (Tables, Vues, Droits)
• Opérations additionnelles • Le langage de manipulation (Sélection et mises à jour)
– définition et modification de schémas • La spécification de modules appelables (Procédures)
– définition de contraintes d'intégrité • L'intégration aux langages de programmation (Curseurs)
– définition de vues
– accord des autorisations
– gestion de transactions
HT-2011 3 HT-2011 4
Page 1
SQL1 ‐ 86 Base de Données
• LANGAGE DE DEFINITIONS DE DONNEES • Collection de tables et de vues dans un schéma
– CREATE TABLE
– CREATE VIEW
• LANGAGE DE MANIPULATION DE DONNEES VITICULTEURS (NVT, NOM, PRENOM, VILLE, REGION)
– SELECT OPEN VINS (NV, CRU, MILLESIME, DEGRE, NVT, PRIX)
– INSERT FETCH
BUVEURS (NB, NOM, PRENOM, VILLE)
– UPDATE CLOSE
– DELETE ABUS (NV, NB,DATE,QTE)
• LANGAGE DE CONTROLE DE DONNEES
– GRANT et REVOKE GROS_BUVEURS (NB, NOM, PRENOM)
– BEGIN et END TRANSACTION
– COMMIT et ROLLBACK
HT-2011 5 HT-2011 6
2. SELECT: Forme Générale Exemples de Questions (1)
– SELECT <liste de projection>
– FROM <liste de tables>
– [WHERE <critère de jointure> AND <critère de restriction>] • Q1: Crus des vins sans doubles.
– [GROUP BY <attributs de partitionnement>] – SELECT DISTINCT CRU
– [HAVING <citère de restriction>]
– FROM VINS
• Restriction :
– arithmétique (=, <, >,  ) • Q2: Noms des buveurs ayant bus des Beaujolais 97 ou 98
– textuelle (LIKE) – SELECT DISTINCT NOM
– sur intervalle (BETWEEN) – FROM BUVEURS B, VINS V, ABUS
– sur liste (IN) – WHERE B.NB = ABUS.NB
• Possibilité de blocs imbriqués par : – AND ABUS.NV = V.NV
 IN, EXISTS, NOT EXISTS, ALL, SOME, ANY
– AND CRU LIKE '%BEAUJOLAIS%'
– AND MILLESIME IN (1997, 1998)
HT-2011 7 HT-2011 8
Page 2
Exemples de Questions (2) Exemples de Questions (3)
• Q3 : Noms et prénoms des buveurs de vins dont le cru commence • Q5: Calculer le degré moyen pour chaque cru.
par B, de degré inconnu ou compris entre 11 et 13. – SELECT CRU, AVG(DEGRE)
– SELECT NOM, PRENOM – FROM VINS
– FROM BUVEURS B, VINS V, ABUS A
– GROUP BY CRU
– WHERE B.NB = A.NB AND A.NV = V.NV
– AND CRU LIKE "B%" • Q6 : Calculer le degré moyen et le degré minimum pour tous les
– AND (DEGRE BETWEEN 11 AND 13 OR DEGRE IS NULL) crus de 94 dont le degré minimum est supérieur à 12.
• Q4 : Noms des crus bus par au moins un buveurs. – SELECT CRU, AVG(DEGRE), MIN(DEGRE)
– SELECT DISTINCT CRU – FROM VINS
– FROM VINS V – WHERE MILLESIME = 1994
– WHERE EXISTS ( SELECT * – GROUP BY CRU
– FROM BUVEURS B, ABUS A – HAVING MIN(DEGRE) > 12
– WHERE B.NB = A.NB AND A.NV = V.NV )
HT-2011 9 HT-2011 10
Forme générale de la condition Requêtes imbriquées (1)
<search condition> ::= [NOT]
<nom_colonne>  constante  <nom_colonne>
<nom_colonne> LIKE <modèle_de_chaîne>  Q7: Donner les crus des vins qui n'ont jamais été
<nom_colonne> IN <liste_de_valeurs>
<nom_colonne>  (ALL ANY SOME) <liste_de_valeurs> commandés
EXISTS <liste_de_valeurs> SELECT CRU SELECT CRU
UNIQUE <liste_de_valeurs> FROM VINS V FROM VINS V
<tuple> MATCH [UNIQUE] <liste_de_tuples>
WHERE V.V# NOT IN (
<nom_colonne> BETWEEN constante AND constante WHERE V.V# <> ALL (
<search condition> AND  OR <search condition>
SELECT C.V# SELECT C.V#
avec FROM COMMANDES C )
FROM COMMANDES C )
::= < = >   
Remarque: <liste_de_valeurs> peut être dynamiquement déterminée par une requête
HT-2011 11 HT-2011 12
Page 3
Requêtes imbriquées (2) Requêtes imbriquées (3)
• Q8 : Donner le nom des buveurs qui n'ont pas bu tous les • Q9: Donner le numéro et le cru des vins
vins == A VERIFIER
commandés exactement une fois
SELECT NOM
FROM BUVEURS B
WHERE EXISTS ( SELECT V#, CRU
SELECT *
FROM VINS V FROM VINS
WHERE NOT EXISTS ( WHERE V# MATCH UNIQUE (
SELECT *
FROM COMMANDES C
SELECT V#
WHERE V.V# = C.V# FROM COMMANDES )
AND C.B# = B.B#) )
HT-2011 13 HT-2011 14
Utilisation de SQL
Requête Union
depuis un langage de prog.
• Q10 :Donner le numéro et le cru des vins commandés • Intégration de deux systèmes de types
plus de 100 fois ou bien jamais commandés – utilisation d'un pré‐compilateur et d'une librairie
( SELECT V.V#, V.CRU • Passage de l'ensembliste au tuple à tuple
– utilisation de curseurs et Fetch
FROM VINS V, COMMANDES C
• Exemple Program PL/1‐SQL
WHERE V.V# = C.V# – EXEC SQL BEGIN DECLARE SECTION ;
SELECT
GROUP BY V.V# – DCL VAR1 CHAR(20) ;
– DCL VAR2 INT ;
HAVING COUNT(C.C#) > 100 ) – EXEC SQL END DECLARE SECTION ;
– EXEC SQL DECLARE C1 CURSOR FOR
UNION – SELECT …FROM … WHERE … :VAR1
( SELECT V#, CRU – EXEC SQL OPEN C1 ;
– DO WHILE SQLCODE = 0
FROM VINS – BEGIN SGBD
– EXEC SQL FETCH C1 INTO :VAR2 Curseur
WHERE V# NOT IN (SELECT V# FROM COMMANDES) )
HT-2011 15 HT-2011 16
Page 4
3. Les Mises à Jour Commande INSERT
• INSERT • INSERT INTO <relation name>
[( attribute [,attribute] … )]
– Insertion de lignes dans une table {VALUES <value spec.> [, <value spec.>] …| <query spec.>}
– Via formulaire où via requêtes • Exemples
– INSERT INTO VINS (NV, CRU, MILLESIME)
• UPDATE – VALUES 112, "JULIENAS", NULL
– Modification de lignes dans une table
– INSERT INTO BUVEURS (NB,NOM,PRENOM)
• DELETE – SELECT NVT, NOM, PRENOM
– FROM VITICULTEURS
– Modification de lignes dans une table
– WHERE VILLE LIKE '%DIJON%'
HT-2011 17 HT-2011 18
Commande UPDATE Commande DELETE
UPDATE <relation name> • DELETE FROM <relation name>
SET <attribute = {value expression | NULL}
• [WHERE <search condition>]
[<attribute> = {value expression | NULL}] …
[WHERE <search condition>]
• EXEMPLE • EXEMPLE
– UPDATE ABUS – DELETE FROM ABUS
– SET QTE = QTE * 1.1
– WHERE ABUS.NV IN – WHERE NV IN
– SELECT NV – SELECT NV
– FROM VINS – FROM VINS
– WHERE CRU = 'VOLNAY' AND MILLESIME = 1990
– WHERE DEGRE IS NULL
HT-2011 19 HT-2011 20
Page 5
4. Contraintes d'intégrité SQL1 ‐ 89 : INTEGRITE
• Contraintes de domaine • VALEURS PAR DEFAUT
– CREATE TABLE VINS
– Valeurs possibles pour une colonne
– ( NV INT UNIQUE,
• Contraintes de clés primaires – CRU CHAR(10),
– Clé et unicité – ANNEE INT,
– DEGRE FIXED (5,2) ,
• Contraintes référentielles(clé étrangères) – NVT INT,
– Définition des liens inter‐tables – PRIX FIXED(7,2) DEFAULT 40 )
• CONTRAINTES DE DOMAINES
– SALAIRE INT CHECK BETWEEN 6000 AND 100000
HT-2011 21 HT-2011 22
SQL1 ‐ 89 :
SQL1 – 89 : Création de table
Contrainte référentielle
• Clé primaire et contrainte référentielle
– CREATE TABLE VINS CREATE TABLE <nom_table>
– ( NV INT PRIMARY KEY, (<def_colonne> *
– CRU CHAR(10), [<def_contrainte_table>*]) ;
– ANNEE INT, < def_colonne > ::=
<nom_colonne> < type  nom_domaine >
– DEGRE FIXED (5,2) ,
[CONSTRAINT nom_contrainte
– NVT INT REFERENCES VITICULTEURS, < NOT NULL  UNIQUE  PRIMARY KEY 
– PRIX DEFAULT 40 ) CHECK (condition) REFERENCES nom_table (liste_colonnes) > ]
• Référence en principe la clé primaire < def_contrainte_table > ::= CONSTRAINT nom_contrainte
< UNIQUE (liste_colonnes) PRIMARY KEY (liste_colonnes)
– celle de VITICULTEURS
CHECK (condition)
FOREIGN KEY (liste_colonnes) REFERENCES nom_table (liste_colonnes) >
23
[NOT] DEFERRABLE 24
HT-2011 HT-2011
Page 6
Autre création de tables 5. CONCLUSION
CREATE TABLE EXPEDITIONS • SQL1 est un standard minimum
( numExp INTEGER PRIMARY KEY
date_exp DATE, • Les versions étendues:
qte QUANTITE, – SQL2 = Complétude relationnelle
CONSTRAINT refCom FOREIGN KEY numExp – SQL3 = Support de l'objet
REFERENCES COMMANDES (numCom) DEFERRABLE
) ; • Sont aujourd'hui intégrées dans les grands SGBD
L'association d'un nom à une contrainte est optionnelle.
Ce nom peut être utilisé pour référencer la contrainte (ex: messages
d'erreurs).
HT-2011 25 HT-2011 26
LA NORMALISATION DE SQL POSITION DES VENDEURS
• Groupe de travail ANSI/X3/H2 et ISO/IEC JTC1/SC2 • Problèmes :
• Documents ISO :
– SQL1 ‐ 86 : Database Language SQL X3.135 ISO‐9075‐1987) – SQLCODE (0 ou <0 si erreur)
– SQL1 ‐ 89 : Database Language SQL with Integrity Enhancement X3.168 ISO‐9075‐ – Requêtes imbriquées SQL
1989
– SQL2 ‐ 92 : Database Language SQL2 X3.135 ISO‐9075‐1992 – Dynamique SQL (Prepare, VENDEUR.1
• Arguments pour : Execute)
– Réduction des coûts d'apprentissage
– Méta‐base normalisée
– Portabilité des applications SQL
SQL
– Longévité des applications – Modèles internes (Index, SQL
– Langage de communication inter‐systèmes Espaces,…) VENDEUR.2 STANDARD VENDEUR.3
• Arguments contre :
– Manque de rigueur théorique
– Affaiblit la créativité
HT-2011 27 HT-2011 28
Page 7
Architecture d'un SGBD
Analyse syntaxique
Analyse sémantique
Gestion des schémas
Fonctionnalités des SGBD Modification de requêtes

Contrôle d'intégrité
Contrôle d'autorisation
Ordonnancement
Optimisation
Élaboration d'un plan
Exécution du plan
Méthodes d'accès
Plan d'Accès Contrôle de concurrence
Atomicité des transactions
BD
2
1. Description des données Noyau de métabase
• SQL LDD • SCHEMAS (CATALOG, NOMB, Créateur,Caractère_Set, …)
– L'analyseur vérifie la correction des commandes • TABLES (CATALOG, NOMB, NOMR, Type, …)
– Il stocke le schéma dans la méta‐base (catalogue système) • DOMAINS (CATALOG, NOMB,NOMD, Type, Défaut,
– Celle‐ci est souvent une BD relationnelle Contrainte,..)
• Organisation de la méta‐base • COLUMNS (CATALOG, NOMB, NOMR, NOMA, Pos, Type,
– C'est un ensemble de tables décrivant les autres (et elle même) …)
– Bases, Tables, Attributs, Domaines, Clés, ... • TYPES (CATALOG, NOMB, NOM, MaxL, Precision, …)
– Vues, Contraintes, Index, ...
• CONSTRAINTS (CATALOG, NOMB, NOMC, TypeC, NomR,
• Commandes traitées …)
– Create Table, Alter Table, etc.
• USERS (NOM, …)
3 4
1
2. Manipulation des Données Exemple de question SQL (1)
• L'analyseur analyse la requête • Nom et description des médicaments de type
– Analyse syntaxique selon la grammaire SQL aspirine
– Analyse sémantique selon la métabase
– Traduction en arbre d'algèbre relationnel
• Syntaxe SQL (rappel) Select Nom, Description
– Select <Liste de champs ou de calculs à afficher>
– From <Liste de relations mises en jeu> From Médicaments
– Where <Liste de prédicats à satisfaire>
– Group By <Groupement éventuel sur un ou plusieurs champs>
Where Type = ‘Aspirine’
– Order By <Tri éventuel sur un ou plusieurs champs>
• Représenter les arbres algébriques des requêtes suivantes
5 6
Exemple de question SQL (2) Exemple de question SQL (3)
• Patients de Tiko ayant effectués une visite le 15 juin • Dépenses effectuées par patient trié par ordre
décroissant
Select Patients.Nom, Patients.Prénom
From Patients, Visites Select Patients.Id‐P, Patients.Nom, sum(Prix)
Where Patients.Id‐P = Visites.Id‐P From Patients, Visites
and Patients.Ville = ’Tiko’ Where Patients.Id‐P = Visites.Id‐P
and Visites.Date = ’15 juin’ GroupBy Patients.Id‐P, Patients.Nom
OrderBy sum(Prix) desc
7 8
2
3. Gestion des vues Gestion des vues
Le SGBD transforme la question sur les vues en
• Les vues permettent d’implémenter l’indépendance question sur les relations de base
logique en permettant de créer des objets virtuels Question Q
sur des vues
• Vue = Question SQL stockée
• Le SGBD stocke la définition et non le résultat
Gestionnaire
• Exemple : la vue des patients de Yaoundé de Vues
Create View Ongola as ( Définition des

Question Q’
sur les relations
vues
Select Nom, Prénom de base
From Patients
Where Patients.Ville = ’Yaoundé’ )
9 10
Syntaxe et Exemple Modification de questions
• CREATE VIEW <nom de table> • CREATE VIEW GROS‐ Résultat
[(<nom de colonne>+)] BUVEURS (NB, NOM, B.NOM = "MARTIN" Question
AS <spécification de question> PRENOM)
[WITH CHECK OPTION]
AS SELECT NB, NOM, Vue Vue
PRENOM
• La clause "WITH CHECK
B.NB, B.NOM, B.PRENOM
OPTION" demande la FROM BUVEURS B, ABUS A
vérification du critère lors des WHERE B.NB = A.NB
A.NB B.NB Définition de vue
insertions et mises à jour via la =
vue AND A.QTE > 100

A.QTE > 100 BUVEURS B
BOIRE A
12
3
4. Exécution et Optimisation Sélection
• Traduction automatique des questions déclaratives en
programmes procéduraux : Patients Patients
Id‐P Nom Prénom Ville
 Utilisation de l’algèbre relationnelle Id‐P Nom Prénom Ville
1 Kamga Jacques Buea 1 Kamga Jacques Buea
• Optimisation automatique des questions
 Utilisation de l’aspect déclaratif de SQL
2
3
4
Bouba
Enow
Nlend
Zoe
John
Paule
Obala
Buea
Loum
 2
3
4
Bouba
Enow
Nlend
Zoe
John
Paule
Obala
Buea
Loum
 Gestion centralisée des chemins d'accès (index, hachages, …)
 Techniques d’optimisation poussées
Patients de la ville de Buea
• Economie de l'astuce des programmeurs
– milliers d'heures d'écriture et de maintenance de logiciels.
13 14
Projection Jointure
Patients Visites
Id‐P Nom Prénom Ville Id‐D Id‐P Id‐V Date Prix
Patients Patients 1 Kamga Jacques Buea 1 2 1 15 juin 250

Id‐P Nom Prénom Ville Id‐P Nom Prénom Ville 2 Bouba Zoe Obala 1 1 2 12 août 180
1 Kamga Jacques Buea 1 Kamga Jacques Buea 3 Enow John Buea 2 2 3 13 350
juillet
2 Bouba Zoe Obala 2 Bouba Zoe Obala 4 Nlend Paule Loum
2 3 4 1 mars 250
3 Enow John Buea 3 Enow John Buea
4 Nlend Paule Loum 4 Nlend Paule Loum
Id‐P Nom Prénom Ville Id‐D Id‐P Id‐V Date Prix
1 Kamga Jacques Buea 1 1 2 12 août 180
2 Bouba Zoe Obala 1 2 1 15 juin 250
Nom et prénom des patients 2 Bouba Zoe Obala 2 2 3 13 juillet 350
3 Enow John Buea 2 3 4 1 mars 250
Patients et leurs visites
15 16
4
Exemple de plan d’exécution Plan d’exécution optimisé

Select Patients.Nom, Patients.Prénom  
From Patients, Visites

Where Patients.Id‐P = Visites.Id‐P
and Patients.Ville = ’Buea’
and Visites.Date = ’15 juin’
  
 
Patients Visites Patients Visites
Patients Visites
17 18
5. Intégrité Logique Contraintes d’intégrité
• Objectif : Détecter les mises à jour erronées • Avantages :
– simplification du code des applications
• Contrôle sur les données élémentaires
– Contrôle de types: ex: Nom alphabétique
– Contrôle de valeurs: ex: Salaire mensuel entre 5 et 50kf – mise en commun des contraintes
• Contrôle sur les relations entre les données
– Relations entre données élémentaires: • Nécessite :
• Prix de vente > Prix d'achat – un langage de définition de contraintes
– Relations entre objets: d'intégrité
• Un électeur doit être inscrit sur une seule liste électorale
– la vérification automatique de ces contraintes
19 20
5
Exemples de contrainte Techniques de contrôle
• Contraintes d’intégrité référentielles • domaine de valeurs
– vérification à la volée
Docteurs Prescriptions
• unicité de clé
Id-D Nom Prénom Id-V Lign Id- Posologie
– test de non existence dans l'index
1 Talla Pierre Visites e M • références inter‐tables
2 Eyoum Paul 1 1 12 1 par jour
Id-D Id-P Id-V Date Prix – insertion référençante : test d'existence dans l'index
3 Ngon Jean 1 2 5 10 gouttes
1 2 1 15 juin 250
2 1 8 2 par jour
– suppression référencée: test de non existence (index ?)
…. …….. …… 1 1 2 12 août 180
2 2 3 13 juillet 350
2 2 12 1 par jour • assertion logique (quantificateurs, agrégats)
2 3 3 2 gouttes – très complexe
2 3 4 1 mars 250
…. …. …. …………
– intérêt de gérer des agrégats pré‐calculés
21
6. Intégrité Physique Transaction
• Motivations : Tolérance aux fautes
– Transaction Failure : Contraintes d'intégrité, Annulation
Incohérence possible...
– System Failure : Panne de courant, Crash serveur ... Etat cohérent Etat cohérent
– Media Failure : Perte du disque
Begin Commit
– Communication Failure : Défaillance du réseau
Transaction
• Objectifs :
– Assurer l'atomicité des transactions Begin
– Garantir la durabilité des effets des transactions commises
CEpargne = CEpargne - 3000
• Moyens : CCourant = CCourant + 3000
– Journalisation : Mémorisation des états successifs des données
Commit T1
– Mécanismes de reprise
23 24
6
Atomicité et Durabilité 7. Partage des données
ATOMICITE DURABILITE
BD
Panne
Begin Begin
CEpargne = CEpargne - 3000 CEpargne = CEpargne - 3000
CCourant = CCourant + 3000 CCourant = CCourant + 3000
Commit T1 Commit T1
Crash disque
 Annuler le débit !!  S’assurer que le

• Accès concurrent aux mêmes données
virement a été fait !
25
Conflits d’accès !! 26
Partage des données 8. Confidentialité
• Objectif : Protéger les données de la BD contre des accès
non autorisés
BD
• Deux niveaux :
– Connexion restreinte aux usagers répertoriés (mot de passe)
– Privilèges d'accès aux objets de la base
• Technique de base • Usagers : Usager ou groupe d’usagers
– Le SGBD verrouille les données accédées pour l'utilisateur
– Il relâche les verrous en fin de transaction • Objets : Relation, Vue, autres objets (procédures, etc.)
– Distinction verrou en lecture et en écriture
– ‐ Compatibilité lecture‐lecture
27 28
7
Puissance des droits SGBD Commandes de SQL
Employés Public
Service des (intranet) (internet) • Attribuer autorisation
ressources – GRANT <DROITS> ON <RELATION>
humaines – TO (<SUJET>)
Id-E Nom Prénom Poste – [WITH GRANT OPTION]
1 Ricks Jim 5485 – <DROITS > ::= ALL | [<OPERATION>]…
2 Trock Jack 1254 Nombre Ngon – <OPERATION> ::= SELECT| INSERT| DELETE | UPDATE | ALTER
3 Lerich Zoe 5489 d’employés Salariale
4 Enow Joe 4049 4 890 • Retirer autorisations
– REVOKE <DROITS> ON <RELATION>
– FROM (<SUJET>)
• Remarque
Id-E Nom Prénom Poste Adresse Ville Salaire
– REVOKE DOIT RETIRER AUSSI LES DROITS TRANSMIS
1 Ricks Jim 5485 ………. Buea 230
2 Trock Jack 1254 ………. Versailles 120
3 Lerich Zoe 5489 ………. Chartres 380
29
4 Enow Joe 4049 ………. Buea 160
9. Principaux SGBD Principaux SGBD
• Les SGBD mettrent en œuvre des techniques • Les grands SGBD • Les SGBD personnels
similaires – Oracle – Borland Paradox
– IBM DB2 – Filemaker
• Aujourd’hui 3 leaders : – Microsoft SQL Server – Interbase
– Microsoft Access
– Oracle, IBM, Microsoft – Sybase SQL Server
– Microsoft FoxPro
– Ingres
• Développements vers le e‐business – Informix
– Site Web dynamiques • Les SGBD objets
– Objectivity
– Commerce électronique BtoC • Les open sources – Object Store
– Commerce électronique BtoB – MySQL – Versant
– PostgreSQL – O2
– Support des documents (XML) ...
31 32
8
Le marché des SGBD
• Parts de marché
Parts de marché en 2005
14
3 33 Oracle
IBM
Microsoft
17 Sybase
Autres
33
Source: Dataquest
9
1. Définition des contraintes
• Objectif :
– Détecter les mises à jour erronées et réagir soit en rejetant la
transaction, soit en compensant les erreurs.
Intégrité des données • Ceci suppose :
– un langage de définition de contraintes d'intégrité
– la vérification automatique de ces contraintes
Définition des contraintes • Avantages :
Vérification des contraintes – simplification du code des applications
Triggers – mise en commun et cohérence globale des contraintes
1 2
Typologie des contraintes
comportementales (1)
• CONTRAINTES STRUCTURELLES • Domaine de variation
– Contraintes de DOMAINE – Ex: le degré d'un vin ne peut être inférieur à 8
• ex: le cru d'un vin est de type chaîne de caractères • Contraintes multi‐attributs (horizontales)
– Contraintes d'ENTITE (unicité et non nullité) – Ex: le prix de vente d'un produit doit être supérieur à son coût de production
• toute relation doit posséder au moins une clé et cette clé ne peut pas prendre de
valeurs nulles • Dépendance fonctionnelle
– Contraintes REFERENTIELLE – Ex : CRU, ANNEE ‐‐‐‐‐‐‐> DEGRE dans la relation VINS
• ex: l'ensemble des valeurs de l'attribut ABUS.NV doit être inclus dans l'ensemble • Contraintes temporelles
des valeurs de l'attribut VINS.NV
– Ex : le degré d'un vin ne peut pas décroître
• CONTRAINTES COMPORTEMENTALES • Contraintes agrégatives (verticales)
– Contraintes générales liées à une application spécifique
– Ex : la somme des quantités bues d'un vin doit être inférieure a la quantité
• ex: la somme des quantités bues d'un vin doit être inférieure a la quantité produite de ce même vin
produite de ce même vin
3 4
1
Association des contraintes
comportementales (2)
• DEPENDANCE D'INCLUSION • Une contrainte d'intégrité peut être :
– Concept de généralisation
– {valeurs d'un {groupe d'attributs x}} inclus dans {valeurs d'un {groupe – Associée à un domaine
d'attributs y}} • Spécifiée au travers de la clause CREATE DOMAIN
• EXEMPLE : – Associée à une relation
– ENSEIGNANT.NOM inclus dans PERSONNE.NOM
• Spécifiée au travers de la clause CREATE TABLE
– ENSEIGNANT ‐‐‐‐g‐‐‐‐> PERSONNE
• La dépendance référentielle est un cas particulier de dépendance – Dissociées
d'inclusion • Spécifiée au travers de la clause CREATE ASSERTION
– {VALEURS DE X} inclus dans {VALEURS DE Y} et Y EST CLE
• EXEMPLE : ABUS.NV inclus dans VINS.NV
5 6
Contraintes associées aux domaines Contraintes associées
aux relations
CREATE TABLE <nom_table>
CREATE DOMAIN <nom> <type> [valeur] (<def_colonne> *
[CONSTRAINT nom_contrainte CHECK (condition) ] [<def_contrainte_table>*]) ;
< def_colonne > ::= <nom_colonne> < type  nom_domaine >
[CONSTRAINT nom_contrainte
Exemple: < NOT NULL  UNIQUE  PRIMARY KEY 
CHECK (condition) REFERENCES nom_table (liste_colonnes) > ]
CREATE DOMAIN couleur_vins CHAR(5) DEFAULT 'rouge' [NOT] DEFERRABLE
< def_contrainte_table > ::= CONSTRAINT nom_contrainte
CONSTRAINT couleurs_possibles CHECK
< UNIQUE (liste_colonnes) PRIMARY KEY (liste_colonnes)
(VALUE IN ('rouge', 'blanc', 'rosé')) CHECK (condition)
FOREIGN KEY (liste_colonnes) REFERENCES nom_table (liste_colonnes) >
[NOT] DEFERRABLE
7 8
2
Contraintes associées Contraintes référentielles
aux relations
CREATE TABLE VINS
( NV INTEGER PRIMARY KEY,
couleur COULEURS_VINS, FOREIGN KEY (liste_colonnes)
cru VARCHAR(20), REFERENCES nom_table (liste_colonnes)
millesime DATE, [ON DELETE {CASCADE  SET DEFAULT  SET NULL}]
degre CHECK (degre BETWEEN 8 AND 15) NOT DEFERRABLE, [ON UPDATE {CASCADE  SET DEFAULT  SET NULL}]
quantite INTEGER, [NOT] DEFERRABLE
• Les contraintes référentielles caractérisent toutes les associations
CONSTRAINT dependance_fonctionnelle • Problème des contraintes référentielles croisées ==> mode DEFERRABLE
CHECK (NOT EXISTS (SELECT * • En cas de violation de la contrainte, la mise à jour peut être rejetée ou bien
une action de correction est déclenchée ==>
FROM VINS
GROUP BY cru,millesime • ON DELETE spécifie l'action à effectuer en cas de suppression d'un
HAVING COUNT(degre) > 1) tuple référencé
NOT DEFERRABLE) ;
• ON UPDATE spécifie l'action à effectuer en cas de mise à jour de la clé
9 d'un tuple référencé 10
Contraintes référentielles: Contraintes dissociées
exemple
CREATE TABLE ABUS
( NB INTEGER NOT NULL,
NV INTEGER NOT NULL, CREATE ASSERTION nom_contrainte CHECK (condition)
date DATE,
qte QUANTITE,
UNIQUE (NB, NV, date)
Remarque: les contraintes dissociées peuvent être multi-tables
CONSTRAINT référence_buveurs
Exemple:
FOREIGN KEY NB
REFERENCES BUVEURS (NB) CREATE ASSERTION quantite_produite
ON DELETE CASCADE CHECK ( (SELECT SUM(quantite) FROM VINS) >
DEFERRABLE
( SELECT SUM(quantite) FROM ABUS) )
) ;
11 12
3
2. Vérification des contraintes (1) Vérification des contraintes (2)
• Méthode par détection d'incohérence • Méthode par prévention des incohérences
– toute mise à jour m est exécutée sur la base D; – une mise à jour m n'est exécutée que si l'état résultant de la
– l'état de la base D est changée en Dm ; base Dm est garanti être cohérent
– si Dm est détecté incohérent, on doit restituer l'état D . • notion de pre‐test
• Notion de post‐test: – A et A' sont des assertions
– A et A' sont des assertions – A' est un pré‐test pour A et m ssi
– A' est un post‐test pour A et m ssi
– {D / A => Dm / A} <=> D / A'
– { D / A => Dm / A} <=> Dm / A'
• problèmes:
• Difficultés :
– (i) Comment laisser passer les seules mises à jour permises ?
– (i) trouver un A' plus simple à vérifier que A
– (ii) défaire la transaction en cas d'incohérence. – (ii) Modifier la mise à jour en ajoutant condition : généralité ?
13 14
Vérification des contraintes (3) Vérification des contraintes (4)
• Exemple: SAL> SMIC
– UPDATE EMPLOYE TUPLES A
• Exemple de vérification – SET SAL=SAL*0.9 * NOTION DE PRE-TESTS DIFFERENTIELS INSERER
DANS R
= R+ {PRETEST+ }
préventive – WHERE NOM = 'RALEUR' MISES

A
?
COMMIT
JOUR
– PRE‐TEST A' = Update(A) • Devient: SUR R
TUPLES A
SUPPRIMER =R - {PRETEST- }
• L'algorithme ajoute – UPDATE EMPLOYE DE R
– SET SAL=SAL*0.9
conjonctivement EXEMPLE : ABUS REFERENCE VINS
– WHERE NOM = 'RALEUR' MEM. CACHE DISQUE
l'assertion A à la condition – AND SAL*0.9 > SMIC PRE-TEST+ (ABUS) : ABUS+.NV = VINS.NV
de la mise à jour. PRE-TEST- (ABUS) : RIEN
PRE-TEST+ (VINS) : RIEN
PRE-TEST- (VINS) : COUNT (ABUS.NV WHERE (ABUS.NV=VINS-.NV) = 0
TRES EFFICACE MAIS COMPLEXE A IMPLANTER

15 16
4
Exemples de tests différentiels 3. Déclencheurs (Triggers)
• Déclencheur :
– action ou ensemble d'actions déclenchée(s) automatiquement lorsqu'une
Type de contrainte Insertion Suppression Mise à jour condition se trouve satisfaite après l'apparition d'un événement
Clé primaire K de R Les clés de R+ sont Pas de vérification Les clés de R+ sont
uniquent et ne figurent
pas dans R.
uniquent et ne figurent • Un déclencheur est une règle ECA
pas dans R-R-.
Clé étrangère Les tuples de R+ R : Pas de vérification Les tuples de R+
– Evénement = mise à jour d'une relation
référence un tuple de S. S : Les clés K de S- ne référence un tuple de S.
A de R Ref K de S
figurent pas dans A de R
– Condition = optionnelle, équivaut à une clause <WHERE>
Domaine A de R Domaine A sur R+ Pas de vérification Domaine A sur R+ – Action = exécution de code spécifique (requête SQL de mise à
Non nullité Non nullité sur R+ Pas de vérification Non nullité sur R+ jour,exécution d'une procédure stockée, abandon d'une transaction,
Dépendance A de R+ = A de R Pas de vérification Pas de forme simplifiée
fonctionnelle A->B
implique B de R+ = B
...)
Contrainte temporelle
de R
Pas de vérification Pas de vérification Vérifier les tuples de R+
• De multiples usages sont possibles :
sur attribut par rapport à ceux de R- – contrôle de l'intégrité
– maintien de statistiques
– mise à jour de copies multiples, ...
17 18
Définition des triggers Exemples de trigger
CREATE TRIGGER degré_croissant
BEFORE UPDATE OF degre ON VINS
CREATE TRIGGER <nom-trigger> REFERENCING OLD AS old_vin NEW AS new_vin
<événement>
WHEN (new_vin.degre < old_vin.degre)
[<condition>]
<action *> ROLLBACK
FOR EACH ROW
<événement> ::=
BEFORE  AFTER CREATE TRIGGER référence_vins
{INSERT  DELETE  UPDATE [OF <liste_colonnes>]} BEFORE DELETE ON VINS
ON <nom_de_table> DELETE FROM ABUS
<condition> ::=
[REFERENCING OLD AS <nom_tuple> NEW AS <nom_tuple>] WHERE ABUS.NV = VINS.NV
WHEN <condition_SQL> FOR EACH ROW
<action> ::=
{requête_SQL [FOR EACH ROW]
exec_procédure COMMIT ROLLBACK}
19 20
5
4. Conclusion
• Le modèle relationnel offre
– des contraintes d'intégrités riches
– des mécanismes de vérification efficaces
– Des mécanismes événementiels puissants
• Problèmes difficiles :
– Contraintes avec agrégats
– Triggers récursifs
21
6
1. CONTROLE DES DROITS D'ACCES
• Objectif :
– protéger les données de la base contre des accès non autorisés
• Deux niveaux :
Contrôles d'accès aux données – connexion au serveur restreinte aux usagers répertoriés (mot de
passe)
– privilège d'accès aux objets de la base
• Granule d'objet :
– vue
Droits d'accès – relation
– procédure stockée
Vues – trigger
1 2
Hiérarchie des privilèges Définition des droits
Administrateur Système {users login, …} GRANT <droits> ON <objet>

TO <usagers>
[WITH GRANT OPTION]
Administrateur de la Base {connexion utilisateurs à BD, gestion des schémas}
<droits> ::= ALL | SELECT | DELETE |
INSERT [<attribut>]| UPDATE [<attribut>]|
REFERENCE [<attribut>]
Propriétaires d'Objets {créateurs d'objets, distribution des droits} <objet> ::= TABLE <relation> * | VIEW <vue> *
<usagers> : := PUBLIC| <username> *
Exemple:
Autres (PUBLIC) {droits obtenus par GRANT} GRANT SELECT , UPDATE (DEGRE) ON TABLE VINS
TO DUPONT
3 4
1
Règles d'octroi et de suppression des
Suppression des droits
droits
• On ne peut transmettre que • Ces règles garantissent la
les droits que l'on possède ou
qui nous ont été transmis cohérence des retraits
REVOKE <droits> ON <objet> avec “grant option” même en cas de graphe
FROM <usagers> • On ne peut supprimer que les d'octroi cycliques
droits que l'on a transmis
• La révocation des droits est
récursive
• Si un utilisateur U1 a reçu le U1
Exemple: droit D de la part de plusieurs Grant D on O to U2
REVOKE ALL ON TABLE VINS utilisateurs (U2, U3, ...), il ne
FROM DUPONT perd ce droit que si tous les U2
utilisateurs lui retirent Grant D on O to U2 Grant D on O to U3
U3
5 6
Autorisations sur une vue 2. LES VUES EXTERNES
• Une vue est une relation virtuelle définie à partir des • Le concept de vues répond aux besoins suivants :
relations de base par une expression SQL
– Adaptation aux applications
• Exemple :
CREATE VIEW GROS_BUVEURS (NB, NOM, QTE_BUE) – Intégration des applications existantes
AS SELECT B.NB, B. NOM, SUM(A.QTE) – Dynamique du schéma de la base
FROM BUVEURS B, ABUS A – Confidentialité et sécurité
WHERE B.NB = A.NB
GROUP BY NB
– Décentralisation de l'administration d'une BD
• AUTORISATIONS SUR LES VUES: – Hétérogénéité des modèles
– Permet un granule d'autorisation très fin – Transparence à la localisation (dans le cas de bases
– Cependant, les mises à jour au travers des vues sont limitées réparties)
7 8
2
Exemple (1) Exemple (2)
• Schéma conceptuel :
application 1 application 2
• VINS (NV, CRU, ANNEE, DEGRE, NVIT)
• VITICULTEURS (NVIT, NOM, PRENOM, VILLE)
PROD_VINS EXPEDITIONS • BUVEURS (NB, NOM, PRENOM, VILLE)
Schéma externe Schéma externe • COMMANDE (NB, NV, QTE, DATE)
• on peut définir de nombreuses applications particulières
qui n'utilisent qu'une partie des données du schéma.
VITICULTEURS
VINS COMMANDES BUVEURS
Schéma conceptuel
9 10
Exemple (3) Définition des vues

APPLICATION = INFLUENCE GEOGRAPHIQUE
SUR LA CONSOMMATION DE L'ANNEE 1996
• VUES = RESTRICTION-PROJECTION DES RELATIONS DE BASE CREATE VIEW <nom_vue> [(liste_attributs)]

BUVEURS-1 (NB, VILLE) AS <expression_de_sélection>
ACHETE-1 (NB, NV, QTE, DATE) // restreint aux dates de l'année 96 [WITH CHECK OPTION]
VINS-1 (NV, CRU)
• VUE = RESTRUCTURATION DU SCHEMA LOGIQUE • L'expression de sélection peut porter sur des tables de base
et/ou des vues
ACHAT-2 (NB, VILLE, CRU, QTE, DATE)
• Dans le cas de vues modifiables, la clause WITH CHECK
• VUE = RESTRUCTURATION et AGREGATION OPTION garantit que les tuples insérés (ou modifiés) dans la
vue vérifient bien le critère de la vue
CONSOMMATION-PAR-VILLE
CPV (VILLE, CRU, QTE)
11 12
3
Exemple de définition (1) Exemple de définition (2)
CREATE VIEW BUVEURS-1

AS SELECT NB, VILLE
CREATE VIEW CPV (VILLE, CRU, QTE)
FROM BUVEURS
AS SELECT B.VILLE, V.CRU, SUM (C.QTE)
CREATE VIEW ACHETE-1
AS SELECT NB, NV, QTE, DATE FROM BUVEURS B, COMMANDES C, VINS V
FROM COMMANDE
WHERE DATE BETWEEN '01.01.96' AND '31.12.96' WHERE B.NB = C.NB AND
C.NV = V.NV AND

CREATE VIEW ACHAT-2 (NB, VILLE, CRU, QTE, DATE)
AS SELECT B.NB, B.VILLE, V.CRU, C.QTE, C.DATE C.DATE BETWEEN '01.01.96' AND '31.12.96'
FROM BUVEURS B, VINS V, COMMANDES C
WHERE C.NB = B.NB AND GROUP BY B.VILLE, V.CRU
C.NV = V.NV AND
C.DATE BETWEEN '01.01.96' AND '31.12.96' 13 14
Déclaration et interrogation Interrogation des vues (1)
MODIFICATION DE QUESTION PAR RESTRUCTURATION SYNTAXIQUE

CREATE VIEW CPV
AS SELECT... SELECT ...
FROM CPV EXEMPLE :
(1) WHERE ...
SELECT CRU, QTE
(2)
Analyseur FROM CPV
SQL WHERE VILLE = "Douala"
(2) DEVIENT :
(1)
VUE SELECT V.CRU, SUM (C.QTE)
Gestionnaire (2) FROM BUVEURS B, COMMANDES C, VINS V
de vues (1) NOM DEF •••
WHERE B.NB = C.NB AND
Résultat (2) CPV Select...
Métabase C.NV = V.NV AND
C.DATE BETWEEN '01.01.96' AND '31.12.96' AND
Relations de base B.VILLE = 'Douala'
15 GROUP BY VILLE, CRU 16
4
Interrogation des vues (2) Les arbres sont mis bout à bout
BUVEURS COMMANDES VINS

MODIFICATION DE QUESTION PAR RESTRUCTURATION
D'ARBRES ALGEBRIQUES Date
Arbre algébrique de la vue CPV

Arbre algébrique de la requête

CPV
Date
Ville = Douala
Group By
Cru, Qte CPV
Résultat Ville = Douala
Cru, Qte
Group By
CPV Résultat
17 18
Puis l'arbre résultat est optimisé Mises à jour au travers des vues
• Les mises à jour au travers des vues sont rarement définies
– Ex: Comment reporter une mise à jour sur CPV dans les relations de base ?
Ville = Douala Date • Pour rendre le report de mises à jour possible, la définition de la

vue doit respecter certaines contraintes:
– la clause SELECT doit conserver les clés de toutes les relations de base
– la clause SELECT ne doit pas contenir de calcul d'agrégat
– la définition ne doit pas contenir de clause GROUP BY ni HAVING
Group By
• Dans SQL2, en plus des conditions précédentes, seules les vue
définies à partir d'une relation unique seront considérées comme
CPV
modifiables
Cru, Qte
Résultat
19 20
5
Vues concrètes 3. CONCLUSION
• Vue concrète : • Le modèle relationnel offre
– Vue dont on a demandé l'implantation dans la base de données
(virtuel ‐‐‐> réel) – des contraintes d'intégrités riches
• Intérêts : – des droits d'accès intégrés
– interrogations fréquentes, – un concept de vue très puissant
– systèmes répartis – des methodes d'interrogation simples et efficaces
• Problèmes :
– Maj des données de base à répercuter sur la vue
• Problèmes difficiles :
• L'objectif est d'éviter de réévaluer complètement la vue à – maj au travers des vues
chaque mise a jour – vues concrètes
21 22
6
Hachage et Indexation 1. Concepts de Base
• 1. Concepts de base • Le gestionnaire de fichiers est la couche interne
d'un SGBD, souvent intégrée au système
• 2. Organisations par hachage opératoire. ANALYSEUR
Analyse syntaxique
Analyse sémantique
Gestion des schémas
META-BASE Modification de requêtes

TRADUCTEUR
Contrôle d'intégrité
Contrôle d'autorisation
• 3. Organisations indexées Ordonnancement
OPTIMISEUR Optimisation
Gestionnaire Ellaboration d'un plan
de fichiers
Exécution du plan
EXECUTEUR Méthodes d'accès
Contrôle de concurrence
Atomicité des
transactions
BD
Structures des Disques Notion de fichier
• Notion 1: Volume • Notion 2: Fichier (File)
(Disk Pack) – Récipient d'information caractérisé par un nom, constituant
une mémoire secondaire idéale, permettant d'écrire des
– Unité de mémoire programmes d'application indépendants des mémoires
secondaire amovible.
(a) Side view
secondaires.
• Un fichier se caractérise plus particulièrement par :
– UN NOM
– UN CREATEUR
– UNE DATE DE CREATION
Innermost cylinder – UN OU PLUSIEURS TYPES D'ARTICLE
Outermost cylinder
– UN EMPLACEMENT EN MS
– UNE ORGANISATION
(b) Top view
Page 1
Quelques notions de base Adressage Relatif
• Notion 3: Article (Record) • Notion 7: Adresse relative (Relative address)
– Elément composant d'un fichier correspondant à l'unité de
traitement par les programmes d'application. – Numéro d'unité d'adressage dans un fichier (autrement
• Notion 4: Organisation de fichier (File organization) dit: déplacement par rapport au début du fichier).
– Nature des liaisons entre les articles contenus dans un
fichier.
• Notion 5: Méthode d'accès (Acces Method) | | | | | | | | | |
– Méthode d'exploitation du fichier utilisée par les
programmes d'application pour sélectionner des articles.
offset = adresse relative
• Notion 6: Clé d'article (Record Key)
– Identifiant d'un article permettant de sélectionner un
article unique dans un fichier.
Architecture d'un SGF Commandes de base
• mount(), unmout()
Séquentiel Haché Indexé 1 Indexé 2 METHODES – monte et démonte un système
} D'ACCES
• mkdir(), chdir(), rmdir()
– créer, changer de, détruire un répertoire
• open(nomf, file), close(nomf, file)
OUVRIR LIRE ECRIRE FERMER
ADRESSAGE } ANALYSEUR
– ouvrir et fermer un fichier
• lseek(file, offset)
MODULES – se positionner dans un fichier
ME 1 ME k
} D'E/S
• read(file, buf, count, offset)
– lecture d'octets sur un fichier
• write(file, buf, count, offset)
Disques
} Magnétiques
– écriture d'octets dans un fichier
Page 2
2. Organisations par Hachage Structure interne d'un paquet
Adresse premier octet
• Notion 8: Fichier haché statique (Static hashed Iga1
------------------
libre dans le paquet
Article a1
file) de longueur lga1
a1
– Fichier de taille fixe dans lequel les articles sont placés Iga2
-----------------
Article a2 L Octets
dans des paquets dont l'adresse est calculée à l'aide de longueur lga2 a2
d'une fonction de hachage fixe appliquée à la clé. Iga3
-----------------
Article a3
de longueur lga3 a3
Index optionnel
Vue d'un fichier haché statique Fonction de Hachage
• DIFFÉRENTS TYPES DE FONCTIONS :
– PLIAGE DE LA CLE
– CONVERSION
– MODULO P
Clé Fonction de – FONCTION PSEUDO‐ALEATOIRE MIXTE
hachage
• BUT :
– Obtenir une distribution uniforme pour éviter de saturer un
paquet
– Mauvaise fonction de hachage ==> Saturation locale et
………… perte de place
0 1 2 i
………
n
} Paquets • SOLUTION : AUTORISER LES DEBORDEMENTS
Page 3
Techniques de débordement Problème du hachage statique
• l'adressage ouvert • Nécessité de réorganisation
– place l'article qui devrait aller dans un paquet plein dans le – Un fichier ayant débordé ne garantie plus de bons temps
premier paquet suivant ayant de la place libre; il faut alors d'accès (2 accès disque en écriture, 1 en lecture)
mémoriser tous les paquets dans lequel un paquet plein a
débordé. – Le nombre de paquets primaires est fixe, ce qui peuT
entrainer un mauvais taux de remplissage
• le chaînage
– constitue un paquet logique par chaînage d'un paquet de
débordement à un paquet plein. • Solution idéale: réorganisation progressive
• le re‐hachage – Un fichier ayant débordé devrait rester analogue à un
– applique une deuxième fonction de hachage lorsqu'un fichier n'ayant pas débordé.
paquet est plein pour placer en débordement.
– Il serait souhaitable de changer la fonction d'adressage.
Techniques de hachage dynamique Hachage extensible
• (Q1) Le fichier est étendu dès qu'un paquet est plein; dans ce cas un
• Techniques permettant de faire grandir progressivement un fichier nouveau paquet est ajouté au fichier.
haché saturé en distribuant les articles dans de nouvelles régions • (Q2) Seul le paquet saturé est doublé lors d'une extension
allouées au fichier. – Il éclate selon le bit suivant du résultat de la fonction de hachage appliquée à
• LES QUESTIONS CLÉS : la clé h(K). Les articles ayant ce bit à 0 restent dans le paquet saturé, alors
que ceux ayant ce bit à 1 partent dans le nouveau paquet.
– (Q1) Quel est le critère retenu pour décider qu'un fichier haché est saturé ?
– (Q2) Quelle partie du fichier faut‐il doubler quand un fichier est saturé? • (Q3) Chaque entrée d’un répertoire donne l'adresse d'un paquet.
– (Q3) Comment retrouver les parties d'un fichier qui ont été doublées et – Les 2**(P‐Q) adresses correspondant à un paquet qui a éclaté Q fois sont
combien de fois ont elles été doublées? identiques et pointent sur ce paquet; ainsi, par l'indirection du répertoire, le
système retrouve les paquets.
– (Q4) Faut‐il conserver une méthode de débordement et si oui quelle
méthode? • (Q4) La gestion de débordement n'est pas nécessaire.
Page 4
Fichier haché extensible
Eclatement d'un paquet
H (KEY)
• L'entrée jumelle est forcée à l'adresse du nouveau
Paquets paquet créé si elle pointe sur le paquet éclaté,
XXXX XXX
sinon le répertoire est doublé.
000 a ------->
000
001 001 b------->
010 010 c1- - - - - - - >
011
011 d------->
100
101 100 a
110 101 b
111
110 c2
Répertoire
111 d
Définition du hachage extensible Hachage linéaire
• Notion 9: Hachage extensible (Extended hashing) • (Q1) Le fichier est étendu par paquet dès qu'un paquet est plein.
• (Q2) Le paquet doublé n'est pas celui qui est saturé, mais un paquet
– Méthode de hachage dynamique consistant à éclater pointé par un pointeur courant qui parcours le fichier
un paquet plein et à mémoriser l'adresse des paquets circulairement.
dans un répertoire accédé directement par les (M+P) • (Q3) Un niveau d'éclatement P du fichier est conservé dans le
premiers bits de la fonction de hachage où P est le descripteur du fichier afin de préciser la fonction de hachage.
nombre d'éclatements maximum subi par les paquets. – Pour un paquet situé avant le pointeur courant, (M+P+1) bits de la fonction
de hachage doivent être utilisés alors que seulement (M+P) sont à utiliser
pour adresser un paquet situé après le pointeur courant.
• (Q4) Une gestion de débordement est nécessaire puisqu'un paquet
plein n'est en général pas éclaté.
Page 5
Paquets d'un fichier haché linéaire Définition du hachage linéaire
• Notion 10: Hachage linéaire (Linear hashing)
H (KEY) XXXXX X X
----------- – Méthode de hachage dynamique nécessitant la gestion
de débordement et consistant à:
000 001 10 11 100 101
– (1) éclater le paquet pointé par un pointeur courant
quand un paquet est plein,
DEBORDEMENTS
– (2) mémoriser le niveau d'éclatement du fichier afin de
déterminer le nombre de bits de la fonction de
hachage à appliquer avant et après le pointeur courant.
Comparaison des hachages Exercice
Ecriture Lecture Débordement Répertoire
• Hachage multi‐atributs
– Numéro paquet = h1(A1) || h2(A2)||… hi(Ai) || …
• Statique 2+d 1+d oui non
• Calculer le nombre d’E/S nécessaires pour
• Extensible 2+r+e 1+r non oui – Ai = a
• Choisir la fonction de hachage optimale pour des
• Linéaire 2+d+e 1+d oui non
fréquences d’interrogation respectives de
Les taux d'occupation de place sont difficiles à comparer. – f1, f2, …fi,…
Le hachage linéaire peut être retardé (éclatement différé selon taux d'occupation).
Page 6
3. Organisations Indexées Exemple de fichier indexé
• OBJECTIFS :
– 1) Accès rapide a partir d'une clé Articles
index
– 2) Accès séquentiel trié ou non a5 a2 a57 a3 a1
• MOYENS : { a5 a2 a57 a3
////////////////////////////////////////////////
a10
0 4 7 12 18
– Utilisation de tables permettant la recherche de {
0 2 4 6 8 10 12 14 16 18 20 22 24
l'adresse de l'article a partir de la CLE Index
• Notion 11: Index (Index) Adresses relatives
– Table (ou plusieurs tables) permettant d'associer à une
clé d'article l'adresse relative de cet article.
Différents Types d'Indexes Exemple d'index non dense
• Un index contenant toutes les cles est dense 1-3-7 9 - 11 - 23 25 - 30 - 31
• Notion 12: Densité d'un index (Index key selectivity) Paquet 1 Paquet 2 Paquet 3
– Quotient du nombre de clés dans l'index sur le nombre
d'articles du fichier.
• Un index non dense est possible si le fichier est trie
– Il contient alors la plus grande clé de chaque bloc avec 7-
l'adresse relative du bloc. 23 -
• Il est possible de construire des indexes hiérarchisés 31 -
– Chaque index possède alors un index qui permet
d'accélérer la recherche.
– Il est ainsi possible de gérer efficacement de gros fichiers.
Page 7
Variantes de méthodes indexées
Exemple d'index hiérarchisé
• Notion 13: Index hiérarchisé (Multilevel index)
– Index à n niveaux, le niveau k étant un index trié divisé en FICHIER
paquets, possédant lui‐même un index de niveau k+1, la
Trié Non trié
clé de chaque entrée de ce dernier étant la plus grande
Niveau 3
du paquet. 21 30
Trié Possible IS3
I Dense
Niveau 2 N Non trié Possible
30
12 21
D VSAM ISAM
E Trié UFAS
Non dense
Niveau 1
X
Non trié
2 5 12 14 18 21 23 25 30
Arbre‐B Arbre‐B 2‐3
• Les arbres‐B (de Bayer) fournissent des outils de Tassement si
moins de 2 fils i r
Valeurs de séparation
base pour construire des indexes équilibrés.
• Notion 14: Arbre‐B (B‐tree)
Éclatement si
– Un arbre‐B d'ordre m est un arbre au sens de la théorie Plus de 3 fils
des graphes tel que: cf l o u
• 1) Toutes les feuilles sont au même niveau;
• 2) Tout nœud non feuille à un nombre NF de fils tel que
– m+1 <= NF < 2m+1 sauf la racine qui a un nombre NFR de fils tel que
0 <= NFR < 2m+1. a, b d,e g,h j,k m,n p,q s,t v,w y,z
Page 8
Structure d'un nœud d'un arbre‐B Exemple d'index en arbre‐B
P0 x1 a1 P1 x2 a2 P2 …… xi ai Pi …… xk ak P
11
• Pi: Pointeur interne permettant de représenter l'arbre; les feuilles
ne contiennent pas de pointeurs Pi;
• ai: Pointeur externe sur une page de données; 5 8 16 21
• xi: valeur de clé.
• (1) (x1, x2…xK) est une suite croissante de clés;
• (2) Toute clé y de K(P0) est inférieure à x1;
• (3) Toute clé y de K(P1) est comprise entre xi et xi+1; 1 2 3 4 6 7 9 10 12 13 14 15 17 18 19 20 22 23 24 26
• (4) Toute clé y de K(PK) est supérieure à xk.
(a)
Insertion de la clé 25 Hauteur d'un Arbre‐B
11
• Le nombre de niveaux d'un arbre‐B est déterminée par son degré et
le nombre de clés contenues.
16 21
• Ainsi, dans le pire des cas, si l'arbre est rempli au minimum, il
existe:
– une clé à la racine,
– deux branches en partent avec m clés,
12 13 14 15 17 18 19 20 22 23 24 25 26
– (m+1) branches en partent avec m clés.
• Pour un arbre de niveaux h, le nombre de clés est donc:
(b)
– N = 1 + 2 m (1+ (m+1) + (m+1)2 + … + (m+1)h‐2)
11
– soit, par réduction du développement limité:
– N = 1 + 2 ((m+1)h‐1‐1)
16 21 24 • D'où l'on déduit que pour stocker N clés, il faut:
– h = 1 + logm+1 ((N+1)/2) niveaux.
12 13 14 15 17 18 19 20 22 23 25 26
Page 9
Arbre‐B+ Exemple d'index en arbre‐B+
• Notion 15: Arbre B+ (B+ tree) 11
– Arbre‐B dans lequel on répète les clés des nœuds
– ascendants dans chaque nœud et on chaîne les nœuds
– feuilles pour permettre un accès rapide en séquentiel trié.
• Les arbres‐b+ sont utilises pour gérer des index 5 8 11 16 21 26
hiérarchisés :
– 1) en mettant toutes les clés des articles dans un arbre B+
et en pointant sur ces articles par des adresses relatives
==> INDEX NON PLACANT
– 2) en rangeant les articles au plus bas niveau de l'arbre B+ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 20 21 22 23 24 26
==> INDEX PLACANT
Avantages et Inconvénients Exercice
• Avantages des organisations indexées par arbre‐b (b+) : • Discuter de la possibilité de mettre plusieurs
– Régularité = pas de réorganisation du fichier nécessaires après de multiples
mises à jour. indexes à un fichier
– Lecture séquentielle rapide: possibilité de séquentiel physique et logique – plaçant
(trié)
– Accès rapide en 3 E/S au plus pour des fichiers de 1 M d'articles – non plaçant
• Inconvénients : • Avantages et inconvénient
– Les suppressions génèrent des trous difficiles à récupérer
– Dans le cas d'index non plaçant, la localité est mauvaise pour des accès
– coût de mise à jour
séquentiels ou sur clés secondaires, ce qui conduit à de nombreux – coût d’interrogation
déplacement de bras.
– Taille de l'index pouvant être importante.
Page 10
Algèbre Relationnelle :
1. RAPPELS
Implémentation
• Rappel de l'algèbre
• Structures d'indexation et placement Interface
Analyseur sémantique
• Algorithme de sélection
Optimiseur
• Algorithme de jointure
Moteur d’exécution
Opérations relationnelles
Méthodes d’accès aux données

Gestion de Gestion de Gestion des
Mémoire Verrous Journaux
Système opérationnel
1 2
Langages de requêtes Calcul Relationnel

• Deux langages de requêtes à fondements • Dérivé de la logique
mathématiques sont à la base de SQL : • Requêtes de la forme
– Calcul relationnel: – {X | Formule(X, Y) }
• Permet aux utilisateurs de décrire ce qu’ils veulent, – X est un vecteur de variables non quantifiées (x1, x2, …)
plutôt que la manière dont ce qu’ils veulent doit être – Y est un vecteur de variables quantifiées ((/) y1, y2, …)
calculé. (Non opérationnel, déclaratif.) – Chaque variable représente une colonne de table
– Algèbre relationnelle: • {(x1,x2) |  y1 (Vins(x1,x2,.,y1) AND y1 = 1999) }
• Plus opérationnelle, très utile pour représenter les
plans d’exécution.
3 4
Algèbre relationnelle Algèbre relationnelle
• Opérations de base: • Opérations additionnelles:
– Sélection (  ) – Jointure ( ||)
• Sélectionne un sous‐ensemble des lignes d’une relation. • Combinaison de produit cartésien et sélection sur colonne 
– Projection (  ) comparables (=, <, >, ...)
• Efface des colonnes d’une relation [et élimine les doubles]. – Intersection
– Produit Cartésien ( X ) • Constitue une relation R avec les tuples appartenant à la fois à R1
• Permet de combiner deux relations. et R2
– Différence ( ‐ ) • Chaque opération retournant une relation, les
• Elimine les tuples de R1 contenus dans R2
– Union ( )
opérations peuvent être composées!
• Constitue une relation R avec les tuples de R1 et ceux de R2 – L’algèbre est fermée.
5 6
Division 2.STRUCTURE PHYSIQUE DES TABLES
• C= A / B • Cas typique
– Index plaçant sur clé primaire
• C(X) est la division de A (X, Y) par B (Y) ssi C • Fichier type VSAM (B+ tree, trié sur clé primaire)
contient tous les tuples ( x ) tels que (y) B, – Valeur de clé  adresse tuple
• Plusieurs index non plaçants sur clé secondaire
( x, y ) A – Valeur de clé  liste d'adresses de tuples
• Variantes
S# P# P# S# – Hachage sur clé primaire
S1 P1 P1 S1 – Table partitionnée
Quels sont les fournisseurs de S1 P2 P2
C • Hachage sur clé secondaire, index par partition
toutes les pièces S2 P1
B – Placement multi‐attributs
S2 P3
A
7 8
Exemple Placement Multi‐dimensionnel
A2
• 1. Insertion
FICHIERS DE VINS
INDEX PRIMAIRE
(NV,CRU,QUALITE,DEGRE,MILLESIME) INDEX SECONDAIRE SUR CRU : – Eclatement progressif du fichier (a) Paquet B
SUR NV :
Beaujolais 1,5,18 selon les bits des fonctions de
1-@1 A1
hachage sur différents attributs
2-@2 1,Beaujolais, Excellente, 11,1987 Chenas 2,7,14 A2 Eclatement 1
…
Julienas 3,6,15,25
• 2. Recherche
2, Chenas,Mediocre,12,1990
25-@25
– Codage du critère par les fonctions (b)
B0 B1
3, Julienas, Mediocre,12,1990 de hachage
A1
5, Beaujolais, Bonne,10,1985 – Balayage de p << N régions A2 Eclatement 2
6, Julienas, Mediocre,12,1987
INDEX SECONDAIRE SUR DEGRE:
• Exemple B01
7, Chenas, Excellente,11,1989 (c)
10 5,14,18
– A1 = CRU Hachage selon 1e lettre B00
14, Chenas, Bonne,10,1994 A1
11 1,7,15
– A2 = DEGRE Hachage selon entier A2
15, Julienas, Excellente,11,1995 Eclatement 3
12 2,3,6,25
– CRU = CHABLIS ET DEGRE = 12
18, Beaujolais, Bonne,10,1988
–  Région B101 B010 B011
25 ,Julienas,Mediocre,12,1990 (d)
9 10 A1
Index Bitmap Exemple
• Cas des index peu • Index bitmap
discriminants – Table de bits telle que
• Exemple Ménagère Produit Coût P1 P2 P3 P4 P5
– Bit [i,j] = 1 si le ie tuple 1 P2 120 0 1 0 0 0
– 10**6 lignes de commandes référence la valeur
– 100 produits 2 P1 80 1 0 0 0 0
codée j 3 P3 150 0 0 1 0 0
– Index sur produit  10**4
adresses par entrées !! • Accélérateur d'accès 4 P2 120 0 1 0 0 0
• Index lourd à manipuler ! très utile et compacte 5 P4 70 0 0 0 1 0
pour attribut peu 6 P4 70 0 0 0 1 0
• Variante : Index bitmap
discriminant • Qui a acheté P2 ?
• Qui a acheté P2 ou P4 ?
• Qui a acheté P2 ou P4 et pas P3 ?
11 12
3. EXECUTION DES SELECTIONS Exemple d'automate
• CAS SANS INDEX • CheckS (Couleur = "ROUGE" ou "ROSE")
– Filtrage séquentiel de la relation
– Peut être réalisé par un automate matériel
Echec
• Algorithme Select (R, Q) :
Foreach page p de R do { R O
<> <>
Init U G
Read (p); <> <> S
Foreach tuple t de p
{ if CheckS (t, Q) then result = result  t ;} ; <>
<>
Echec
} E
E
Succès
13 14
Sélection via index Utilisation d'Index B‐tree

• Cas avec index • Intersection et union de listes d'adresses de tuples
– Accès aux tuples dont les identifiants sont retenus
– unidimensionnel (Isam, Arbre‐B) – Vérification du reste du critère
– multi‐dimensionnel (Grid file, Arbre de prédicat) • Exemple : Utilisation de tous les index
– (CRU = "CHABLIS") AND (MILL > 1999) AND (DEGRE = 12)
• Variante : Cas avec hachage
– L = C  (M1  M2  …  Mp)  D
– unidimensionnel – Accéder aux tuples de L
– multi‐dimensionnel (réduction du balayage) • Exemple : Choix du meilleur index
– Accès via l'index (CRU = "CHABLIS")
– Vérification du reste du critère sur les tuples
15 16
Utilisation d'index Bitmap 4. EXECUTION DES JOINTURES
• Détermination des adresses des tuples • Opération essentielle des SGBDR
candidats • De multiples algorithmes
• Possibilité de mixer avec des index B‐Tree – Sans index :
• réduire les balayages
• Très utile pour les agrégats • Optimiser les comparaisons
– Somme des coûts dépensés pour produit P2 • Créer dynamiquement des index ou tables de hachage
• Et le data mining … – Avec index
• Profiter au mieux des index
– Toujours : Réduire I/O et temps CPU
17 18
Jointure et opérateurs similaires Évaluations avec Mémoire
• Les mêmes types d’algorithmes peuvent êtres utilisés • On veut joindre les tables CLIent et COMmandes
pour les autres opérateurs binaires • |CLI| = Nbre de pages occupées par CLI
• Variations :
• ||CLI|| = Nbre de tuples dans CLI
– Nested Loop Join
– Block Nested Loop Join • |CLI| << |COM|
– Index Join • M = Nbre de pages mémoires disponibles
– Sort Merge Join – (quelques approximations pour simplifier les formules)
– Hash Join
• Coût = Nbre d’I/O
– Hybrid Hash Join
– (on ne distingue pas I/O séquentielle et aléatoire)
– Pipelined Hash Join
19 20
Jointure avec un index
Prise en compte de la mémoire
(Index Join)
• Cas avec 1 index sur R1 • Hypothèse : index sur la clé primaire de CLI
– L’index a n niveaux et tient sur p pages
Pour chaque page q de R2
• Principe : (équijoins)
Lire (q) – pour chaque commande, récupérer le n° de client,
Pour chaque tuple t de q parcourir l’index et retrouver le client
Accéder a R1 via index • Brut Force (ou M = 0)
– Coût = ||COM||  (n+1) + |COM|
Joindre si succès
• M = |CLI| + p
• Coût = |R2| + ||R2||*(n+1) avec n  2 – Coût = |COM| + p + |CLI|
• Intérêt de la technique ???
21 22
Jointure sans index
Jointure avec 2 index
(Nested Loop)
• Les indexes sont triés • Cas sans index  balayages multiples
– B‐Tree, B+ Tree • Par boucle imbriquée
– Les articles ne sont pas forcément triés
– Foreach page p de R1
• Fusion des index – Foreach page q de R2
– Couples (@t1, @t2) des tuples joignant
– Foreach tp de p
– Appelé index de jointure
– Foreach tq de q
– Trié sur @t1, @t2
– Accès aux tuples et concaténation – { if CheckS (t, Q) then result = result  (tp||tq) ;} ;
• Remarque : • Coût = page(R1) * page(R2) + page(R1)
– Possibilité de maintenir l'index de jointure
23 24
Tri‐Fusion
(Sort‐Merge Join)
• Principe : • Par tri‐fusion
– Pour chaque client, lire ttes les commandes et comparer – Trier (R1, AttJ)
• Brut Force : – Trier (R2, AttJ)
– coût = ||CLI||  |COM| + |CLI|
– Fusionner (R1, R2)
• M = 0 : aucune bufferisation
–  coût = |CLI|  |COM| + |CLI|
• M >= |CLI| : on cache CLI dans M • Coût = page(R1) LOG page(R1) +
–  coût = |CLI| + |COM| page(R2) LOG page(R2) +
• Entre les deux : on cache M pages de CLI page( R1) + page(R2)
–  coût = (|CLI|/M)  |COM| + |CLI| (B.N.L.)
25 26
Prise en compte de la mémoire Jointure par Hachage
• Principe : (équijoins) • On crée un fichier haché (ou indexé)
– Trier les deux relations sur l’attribut de jointure Hacher (R1) (plus petite relation)
– Parcourir simultanément les deux relations et joindre Pour chaque page p de R2
• Si M est trop petite  Trôp coûteux ! Lire (p)
• Si M >= sqr(|COM|)  coût = 3  (|CLI| + |COM|) Pour chaque tuple t de p
Accéder au fichier aléatoire
• Si une des relations est déjà triée (ex. CLI est placée
Ajouter la concaténation au résultat si succes
sur la clé primaire) on économise la phase de tri (ici 2
 |CLI|) • Coût = page(R1) + A page(R1) +
page(R2) + A page(R2)
27 28
Amélioration par
Tableaux de Bits
• Tableau de bits par • Hypothèse M >=|CLI|
hachage de R1 en
mémoire pour éliminer R2 --> g(B)
0
• Principe (équijoins) :
les accès sans chance 1 – Charger CLI et hacher la relation en mémoire en n
de jointure lors de la 0 paquets (n du même ordre que ||CLI||)
lecture de R2. 0
R1 --> g(A) 1 – Pour chaque tuple de COM, tester la table de
• Utilisation d'une 1 hachage
fonction g distribuant 0
sur un vecteur de bits . • Coût = |CLI| + |COM|
assez long … .
.
• Différence avec le Nested Loop ?
1
29 30
Jointure par Bi‐hachage Grace Hash Join
• Hachage des deux tables en paquets en mémoire (virtuelle) • Hypothèse : M >= sqr(|COM|)
par une même fonction h
• Jointure des paquets de même rang • Principe :
– Hacher sur le disque CLI et COM en N paquets. N
R2 --> h(B)
est calculé de façon à ce que |paquet| < M
– Joindre chaque paquet de CLI avec chaque
paquet de COM
R1 --> h(A) – coût = 3  (|CLI| + |COM|)
Jointure R1.A = R2.B 31 32

Hybrid Hash Join Mode pipeline ou bloquant
• Exemple M = |CLI|/n • Le pipeline sort un tuple résultat dès qu'il est calculé
• Principe : • Pas nécessaire d'attendre le dernier tuple résultat
– Hacher CLI en n paquets. Le paquet 1 est conservé en pour débloquer l'utilisateur
mémoire les paquets 2 à n sont réécris sur disque. • Plus efficace vu de l'utilisateur
– Hacher COM en n paquets. Le paquet 1 est testé
immédiatement en mémoire avec le paquet 1 de CLI. Les
• Opérateur bloquant
autres sont réécris sur disque – Tri
• Coût : (|CLI|+|COM|)  ( 1 + 2(n‐1)/n) • Opérateur non bloquant
• A.N. : n = 2  Coût = 2  (|CLI|+|COM|) – Sélection, hachage
33 34
Hachage et Pipeline HashJoin: Build‐Probe
probe
Test présence HashJoin
Probe is implemented by build S
dans table hachée
R S
Insertion en R
Table hachée
Build build
Test output
R h(R.a) R hash table R S
buffer
Scan2
S h(S.b)
COM probe
Scan1 Memory
CLI
COM
CLI
35 36
5. CONCLUSION
• Problème essentiel des SGBD
• De multiples algorithmes possibles
• Pas d'algorithme toujours meilleur !
• Nécessite d'un modèle de coût pour choisir le
meilleur algorithme
• Choix souvent fait à la compilation
37
Optimisation de Requêtes 1. ARCHITECTURE TYPE SGBD
SYNTAXE
ANALYSEUR SEMANTIQUE
• 1. Introduction SCHEMA
• 2. Arbres relationnels VUES
INTEGRITE
CONTROLE
AUTORISATIONS
• 3. Restructuration algébrique
• 4. Modèle de coût META-BASE OPTIMISEUR
ORDONNANCEMENT
ELABORATION
D'UN PLAN
• 5. Choix du meilleur plan
• 6. Conclusion EXECUTABLE EXECUTION
METHODES D'ACCES
HT-2011 HT-2011
2. ARBRES RELATIONNELS
ETAPES DE L'OPTIMISATION
 RESTRICTION PROJECTION TRI
• (1) Obtention d’une représentation canonique
V. CRU "BEAUJOLAIS"
• (2) Réécriture = transformation par : = V.NV, V.CRU V.CRU, V.MILL
– simplification 
JOINTURE V
V
DIFFERENCE
– ordonnancement des opérations élémentaires V
• (3) Planning = construction des plans d'exécution A. NV = V. NV
candidats A V
— AGREGAT
– choix des algorithmes pour chaque opérateur, B1 B2
– calcul du coût de chaque plan, PRODUIT CARTESIEN UNION
– choix du meilleur plan. COUNT(*),AVG(DEGRE)
• Etapes 1 et 2 : indépendantes des données V.CRU, V.MILL

• Etape 3 : dépendante des données A V
U
B1 B2
V
HT-2011 HT-2011
1
EXEMPLE D'ARBRE Arbre linéaire droit
RESULTAT SELECT V.CRU
• Coût d'exécution:
V.CRU FROM PRODUCTEURS P, VINS V,
– 10 millions de buveurs dont 1 m B.NOM, B.PRENOM PRODUIT R
à Paris
WHERE V.MILLESIME = 1976 AND
– 10 millions d'abus dont 10000 de V.MILLESIME = 1976
A.DATE > 01-01-90 V.DEGRE 14
Volnay AND P.REGION = « BORDELAIS » AND
– 1000 vins V.CRU = "VOLNAY" V.DEGRE  14 P.NP = R.NP
AND R.NV = V.NV.
A.NV V.NV P.REGION = « Bordelais »

– 10 m + 10m * 1m + 10 m * 1000 =
– + 10 m + 10000 + …
P.NP R.NP
– de l'ordre de 10 ** 13 B.NB =
A.NB VINS V =
– comparaisons de tuples !!! P
B.VILLE = "PARIS" ABUS A

R. NV = V. NV
BUVEURS B R V
HT-2011 HT-2011
Typologie des arbres Autre exemple
RECETTE SELECT P.NOM, SUM(L.PRIX * (1-
L.DISCOUNT))
P.NOM, RECETTE FROM CLIENTS C, COMMANDES O, LIGNES L,
FOURNISSEUR F, PAYS P, CONTINENTS T
P.NOM
WHERE C.NUMCLI = O.NUMCLI
C.NUMCLI = O.NUMCLI AND O.NUMCOM = L.NUMCO
O.NUMCOM = L.NUMCO AND L.NUMFOU = F.NUMFOU
L.NUMFOU = F.NUMFOU AND C.NUMPAYS = F.NUMPAYS
AND F.NUMPAYS = P.NUMPAYS
L
AND P.NUMCONT = T.NUMCONT
C.NUMPAYS = F.NUMPAYS
AND T.NOM = « EUROPE »
C
F.NUMPAYS = P.NUMPAYS AND O.DATE $D1
F AND O.DATE < $D1 + INTERVAL 1 YEAR
P.NUMCONT = T.NUMCONT GROUP BY P.NOM
$D1  O.DATE <$D1+1
ORDER BY RECETTE DESC ;
Arbre linéaire droit Arbre linéaire gauche Arbre ramifié P T.NOM = « EUROPE »
O
T
HT-2011 HT-2011
2
3. RESTRUCTURATION ALGEBRIQUE
Commutativité des Jointures
• Problème :
– suivant l'ordre des opérateurs algébriques dans un arbre, le
coût d'exécution est diffèrent
• Pourquoi?
– 1. le coût des opérateurs varient en fonction du volume des R S S R
données traitées
i.e., plus le nombre de tuple des relations traitées est
petit, plus les coûts cpu et d'E/S sont minimisés
– 2. certains opérateurs diminuent le volume des données
e.g., restriction et projection
HT-2011 HT-2011
Associativité des jointures Groupage des Restrictions
• Il existe N!/2 arbre de jointure de N relations.
• Parmi les jointures, certaines sont des produits Ai = a
cartésiens.
Ai = a
et
Aj = b
T R Aj = b
R S S T
HT-2011 HT-2011
3
Semi‐commutativité des Projections
Règles de Restructuration
• Il est possible de descendre les projections, mais • (1) Commutativité des jointures
les attributs utilisés dans la suite doivent être • (2) Associativité des jointures
conservés !!! • (3) Groupabilité des restrictions
A1, … Ap • (4) Semi‐commutativité des projections et restrictions
A1, … Ap
• (5) Semi‐commutativité des restrictions et jointures
Ai = a • (6) Semi‐distributivité des projections / jointures
Ai = a
• (7) Distributivité des restrictions / unions ou
Ai, différences
A1,… Ap
• (8) Distributivité des projections / unions
HT-2011 HT-2011
Heuristique d'Optimisation Exemple d'Arbre Optimisé
Résultat • Coût d'exécution:
• Appliquer d'abord les opérations réductrices
(restrictions et projections) en les groupant sur B.NOM, B.PRENOM
• 10 m + 1m * 100000 +
chaque relation. A.NV V.NV 1 m * 1000 + …
=
– 1. Dégrouper les restrictions (Règle 3')
– 2. Descendre les restrictions (Règles 4, 5 et 7) B.NOM, B.PRENOM,A.NV
• de l'ordre de 10 ** 11
– 3. Grouper les restrictions aux feuilles (Règle 3) B.NB
=
A.NB
V.NV
comparaisons de
– 4. Descendre les projections (Règles 4, 6 et 8) tuples !
B.NB, B.NOM, B.PRENOM A.NB, A.NV
V.CRU = "VOLNAY"
• L'ordre des unions, différences et jointures reste B.VILLE = "PARIS"
A.DATE > 01-01-83
inchangé !!! B A
V
HT-2011 HT-2011
4
Ordonnancement des Jointures 4. MODELE DE COUT
• HEURISTIQUES : • Facteur de sélectivité
– Proportion de tuples du produit cartésien des relations
– Choix des relations de taille minimum touchées qui satisfont une condition.
– Jointures pré‐calculés d ’abord (indexes) • Exemple:
– Semi‐jointures plus réductrices SELECT *
FROM R1, R2
• ORDONNANCEMENT DES AGREGATS ==> s =1
SELECT *
– Permutations difficiles
FROM R1
– Profiter des tris des jointures, dédoublement, etc.. WHERE A = valeur
– Gains importants pour MIN et MAX ==> s = 1/NDIST(A) avec un modèle uniforme
HT-2011 HT-2011
Sélectivité des Restrictions Sélectivité des Projections
• TAILLE ((R)) = s * TAILLE(R) avec: • TAILLE(x(R)) = p(x) * (1‐d) * TAILLE(R)
s (A = valeur) = 1 / NDIST(A)
s(A > valeur) = (max(A) ‐ valeur) / (max(A) ‐ min(A))
s(A < valeur) = (valeur ‐ min(A)) / (max(A) ‐ min(A)) – avec p(x) = Larg(x) / Larg(R)
s (A IN liste valeurs) = (1/NDIST(A)) * CARD(liste valeurs)
s(P et Q) = s(P) * s(Q) – d = probabilité de doubles
s(P ou Q) = s(P) + s(Q) ‐ s(P) * s(Q) – CARD(X) / CARD(DOM(X))**2
s( not P) = 1 ‐ s(P)
• Le coût dépend de l'algorithme (index, hachage ou balayage).
HT-2011 HT-2011
5
Sélectivité des Jointures Le calcul des tailles
• TAILE( R1 |><| R2) = p * TAILLE(R1) * TAILLE(R2) • Taille des tables de base dans le catalogue
– p dépend du type de jointure et de la corrélation des
colonnes : • Calcul des tailles à la compilation
• p = 0 si aucun tuple ne joint – application du coefficient de sélectivité
• p = 1 / MAX(NDIST(A),NDIST(B)) si distribution uniforme – hypothèse d ’uniformité
équiprobable des attributs A et B sur un même domaine
• p = 1 si produit cartésien • Possibilité d’histogrammes
– RunStat(<Table>, <attribut>)
• L'algorithme change radicalement les coûts – Stockage dans le catalogue de l’histogramme de
– linéaire si index, distribution de l ’attribut
– produit des tailles si boucles imbriquées.
– Utilisation par le modèle de coût
HT-2011 HT-2011
5. CHOIX DU MEILLEUR PLAN
Sélectivité minimum
Arbre d'opérations Schéma interne Rel = liste des relations à joindre ;
p = plus petite relation ;
Plans d'exécution
Tant que Rel non vide {
Générateur de
Bibliothèque de R = relation de selectivité minimum de Rel ;
Plans transformations p = join(R,p) ;
Stratégie de Heuristiques Relations = Relations ‐ R ; } ;
Recherche
de choix Return(p) ;
Modèle de coût
Plan d'exécution
Optimal
HT-2011 HT-2011
6
Programmation Dynamique Illustration DP
PlanOuverts = liste de tous les plans mono‐relation possible ;
Eliminer tous les plans équivalents excepté le moins coûteux ; ScanR1
Pour chaque PlanOuverts p {
Pour chaque opérateur n’appartenant pas au plan p { JoinS R3
JoinH R2
Etendre le plan en ajoutant cet opérateur ; JoinS R2 JoinH R3
Calculer le coût du nouveau plan ;
Insérer le nouveau plan dans la liste Nouveaux ; }
JoinH R3
Eliminer tous les plans équivalents excepté le moins coûteux ; JoinS R3 JoinH R2 JoinS R2
Transférer les plans Nouveaux dans PlanOuverts ; }
Retourner le plan optimal ;
HT-2011 HT-2011
Différentes Stratégies
Amélioration itérative
Function Iterative(Query)
p:= Parse(Query) ; // Set the initial plan
Stratégie
de recherche S := {} ; // S is the set of locally optimum plans
while not StopCond()
{ nmoves := 0;
while nmoves < MaxMoves(Query) and Transformable(p)
{ p' := Transform (p) ; // Apply a transformation rule
if Cost(p') < Cost(p) then
Enumérative Aléatoire
{ p ::= p';
nmoves ::= nmoves + 1;
}
Insert (S, p') ; // Maintain the set of interesting plans
p := Random(Parse(Query)); // Generate a new initial plan at random
}
Exhaustive Augmentation Amélioration Recuit Génétique }
itérative simulé
return Optimal(S) ; // Select best plan among all generated ones }
HT-2011 HT-2011
7
Illustration II 6. CONCLUSION
Parse(Query) Rand(Parse(Query)) Rand(Rand((Parse(Query)))
• Problème essentiel des SGBD
Profitable Profitable
Profitable
r'1 r"1
r1
• Nécessité d’un modèle de coût
Profitable
Profitable
r"2
• Approches par compilation dans un langage
r2 d’accès (opérateurs avec annotations)
SELECT
MINIMAL COST
PLAN
• Stratégies de choix aléatoires
HT-2011 HT-2011
8
1. Le transactionnel (OLTP)
• Opérations typiques
– mises à jour ponctuelles de lignes par des écrans
prédéfinis, souvent répétitives, sur les données les
GESTION DE TRANSACTIONS plus récentes
• Exemple
1. Objectifs et bases – Benchmark TPC‐A et TPC‐B : débit / crédit sur une
2. Journaux et reprise base de données bancaire
3. Scénarios de reprise – TPC‐A transactionnel et TPC‐B avec traitement par lot
4. Modèles étendus
– Mesure le nombre de transactions par seconde (tps)
5. Cas des systèmes répartis
et le coût par tps
HT-2011 HT-2011
La base TPC‐A/B La transaction Débit ‐ Crédit

1
• Begin‐Transaction
100000
– Update Account Set Balance = • 90 % doivent avoir un temps
Balance + Delta de réponse < 2 secondes
Agences
Comptes Where AccountId = Aid ;
• Chaque terminal génère
– Insert into History (Aid, Tid,
Bid, Delta, TimeStamp) une transaction toute les
– Update Teller Set Balance = 10s
Balance + Delta • Performance = Nb
Where TellerId = Tid ; transactions commises /
Caissiers Historique – Update Branch Set Balance = Ellapse time
Balance + Delta
Where TellerId = Tid ;
100
• End‐Transaction.
Taille pour 10 terminaux, avec règle d'échelle ( scaling rule)
HT-2011 HT-2011
Page 1
Cohabitation avec le décisionnel Les menaces
• Les transactions doivent souvent cohabiter • Problèmes de concurrence
– pertes d ’opérations
avec des requêtes décisionnelles, traitant un – introduction d ’incohérences
grand nombre de tuples en lecture – verrous mortels (deadlock)
• Exemple : • Panne de transaction
– erreur en cours d'exécution du programme applicatif
– Moyenne des avoir des comptes par agence – nécessité de défaire les mises à jour effectuées
– SELECT B.BranchId, AVG(C.Balance) • Panne système
FROM Branch B, Account C – reprise avec perte de la mémoire centrale
– toutes les transactions en cours doivent être défaites
WHERE B.BrachId = C.BranchId • Panne disque
GROUP BY B.BranchId ; – perte de données de la base
HT-2011 HT-2011
Propriétés des transactions Commit et Abort
• Atomicité • INTRODUCTION D’ACTIONS ATOMIQUES
– Unité de cohérence : toutes les mises à jour doivent – Commit (fin avec succes) et Abort (fin avec echec)
être effectuées ou aucune. – Ces actions s'effectuent en fin de transaction
• Cohérence
– La transaction doit faire passer la base de donnée d'un • COMMIT
état cohérent à un autre. – Validation de la transaction
• Isolation – Rend effectives toutes les mises à jour de la
– Les résultats d'une transaction ne sont visibles aux transaction
autres transactions qu'une fois la transaction validée.
• Durabilité • ABORT
– Les modifications d ’une transaction validée ne seront – Annulation de la transaction
jamais perdue
– Défait toutes les mises à jour de la transaction
HT-2011 HT-2011
Page 2
Schéma de transaction simple Effet logique
Mémoire de la
• Fin avec succès ou échec transaction
Update
Update
• Begin_Transaction
– update - Provoque l'intégration réelle des mises
à jour dans la base Abort
– update - Relâche les verrous Commit
– .....
Bases de données Poubelle
– Commit ou Abort- Provoque l'annulation des mises à jour
- Relâche les verrous
- Reprend la transaction
HT-2011 HT-2011
Interface applicative 2. Journaux et Sauvegarde
• API pour transaction simple • Journal des images avant
– Trid Begin (context*) – Journal contenant les débuts de transactions, les
– Commit () valeurs d'enregistrement avant mises à jour, les fins de
– Abort() transactions (commit ou abort)
• Possibilité de points de sauvegarde : – Il permet de défaire les mises à jour effectuées par
– Savepoint Save() une transaction
– Rollback (savepoint) // savepoint = 0 ==> Abort • Journal des images après
• Quelques interfaces supplémentaires – Journal contenant les débuts de transactions, les
– ChainWork (context*) //Commit + Begin valeurs d'enregistrement après mises à jour, les fins de
– Trid Mytrid() transactions (commit ou abort)
– Status(Trid) // Active, Aborting, Committing, Aborted, – Il permet de refaire les mises à jour effectuées par une
Committed transaction
HT-2011 HT-2011
Page 3
Journal des images avant Journal des images après
• Utilisé pour défaire les mises à jour : Undo • Utilisé pour refaire les mises à jour : Redo
2.Log 3.Log
Page lue Page modifiée Page lue Page modifiée
3.Update 2.Update
1.Read 4.Write
1.Read 4.Write
Base de données
Base de données
HT-2011 HT-2011
Gestion du journal Sauvegarde
• Journal avant et après sont unifiés • Sauvegarde périodique de la base
• Écrits dans un tampon en mémoire et vider sur – toutes les heures, jours, ...
disque en début de commit – Doit être effectuée en parallèle aux mises à jour
• Structure d'un enregistrement : • Un Point de Reprise (checkpoint) est écrit dans le
– N° transaction (Trid) journal pour le synchroniser par rapport à la
– Type enregistrement : sauvegarde
• {début, update, insert, commit, abort} – permet de situer les transactions effectuées après la
– TupleId sauvegarde
– [Attribut modifié, Ancienne valeur, Nouvelle valeur] ... • Pose d'un point de reprise :
• Problème de taille – écrire les buffers de journalisation (Log)
– on tourne sur N fichiers de taille fixe – écrire les buffers de pages (DB)
– possibilité d'utiliser un fichier haché sur Trid/Tid – écrire un record spécial "checkpoint" dans le journal
HT-2011 HT-2011
Page 4
3. Scénarios de Reprise Stratégie do‐undo
• Les mises à jour peuvent être effectuées • Mises à jour en place
directement dans la base (en place) – l'objet est modifié dans la base
– la base est mise à jour immédiatement, ou au • Utilisation des images avant
moins dès que possible pendant que la
– copie de l'objet avant mise à jour
transaction est active Update
– utilisée pour défaire en cas de panne
• Les mises à jour peuvent être effectuées en 2. LogPage
Mémoire Journal avant
mémoire et installées dans la base à la cache
3. WritePage
validation (commit) Undo
1. LirePage
– le journal est écrit avant d'écrire les mises à jour Base
HT-2011 HT-2011
Stratégie do‐redo Pages ombres
Table des Pages Ombres
• Mises à jour en différentiel
– l'objet est modifié en page différentielle (non en
place=ombre) Nom
Fichier
• Utilisation des images après Adresse
COMMIT
Table des
– copie de l'objet en journal après mise à jour (do)
Update
Pages
3. LogPage
– utilisée pour refaire en cas de panne (redo)
Mémoire Journal après Page Ombre Page Ombre
cache
2. WritePage
1. LirePage Redo
Ombre Nouvelle Table des Pages

Base
Nouvelles Pages
Commit
HT-2011 HT-2011
Page 5
La gestion des buffers Commits bloqués
• Bufferisation des journaux • AFIN D'EVITER 3 E/S POUR 1:
– on écrit le journal lorsqu'un buffer est plein – Le système reporte l'enregistrement des journaux au
commit
– ou lorsqu'une transaction commet
– Il force plusieurs transactions à commettre ensemble
• Bufferisation des bases – Il fait attendre les transactions au commit afin de
– on modifie la page en mémoire bloquer un buffer d'écriture dans le journal
– le vidage sur disque s'effectue en différé (processus
E/S) • RESULTAT
• Synchronisation journaux / base – La technique des "commits" bloques permet
d'améliorer les performances lors des pointes sans
– le journal doit toujours être écrit avant modification faire attendre trop sensiblement les transactions
de la base !
HT-2011 HT-2011
Reprise à froid 5. Modèles étendus
• En cas de perte d'une partie de la base, on • Applications longues composées de plusieurs
repart de la dernière sauvegarde transactions coopérantes
• Le système retrouve le checkpoint associé
• Il ré‐applique toutes les transactions • Seules les mises‐à‐jour sont journalisées
commises depuis ce point
– (for each committed Ti : redo (Ti)) • Si nécessité de défaire une suite de
transactions:
– contexte ad‐hoc dans une table temporaire
– nécessité d'exécuter des compensations
HT-2011 HT-2011
Page 6
Transactions Imbriquées
Points de Sauvegardes
Begin(T)
• OBJECTIFS
• Introduction de points de sauvegarde
– Obtenir un mécanisme de
intermédiaires reprise multi‐niveaux Begin(t'1) Begin(t1)
– (savepoint, commitpoint) – Permettre de reprendre des
parties logiques de
• Begin_Trans transactions Commit(t1)
– update – Faciliter l'exécution parallèle Commit(t'1) Commet t1
unité d'oeuvre
– update de sous‐transactions Begin(t2)
Begin(t21)
– savepoint Non perte du contexte • SCHEMA
– Reprises et abandons partiels
– update unité d'oeuvre
– Possibilité d'ordonner ou non
– update les sous‐transactions Commit(t21)
Abort(t2)
• Commit Commit(T) Annule t2 et t21
HT-2011 HT-2011
Sagas Activités : Propriétés Souhaitées
• Groupe de transactions avec transactions • contexte persistant
compensatrices
• rollforward, rollback avec compensations
• En cas de panne du groupe, on exécute les
compensations • flot de contrôle dépendant des succès et échecs
T1 T2 T3 ... Tn
– différencier les échecs systèmes des échecs de
programmes
• monitoring d'activités:
T1 T2 CT2 CT1
– état d'une activité, arrêt, ...
HT-2011 HT-2011
Page 7
Langage de Contrôle d'Activités 6. Transactions réparties
• Exemple: réservation de vacances • OBJECTIF
– T1 : réservation avion alternative : location voiture – Garantir que toutes les mises à jour d'une transaction sont exécutées
– T2 : réservation hôtel sur tous les sites ou qu'aucune ne l'est.
– T3 : location voiture • EXEMPLE
• Activité – Transfert de la somme X du compte A vers le compte B
– Ensemble d'exécution de transactions avec alternative – DEBUT
ou compensation • site 1: A = A ‐ X
• Langage de contrôle d'activités • site 2: B = B + X PANNE ‐‐> INCOHERENCE DONNEES
– Possibilité de transactions vitales (ex: réservation – FIN
hôtel)
• PROBLEME
– Langage du type :
• If abort, If commit, Run alternative, Run compensation, … – Le contrôle est réparti : chaque site peut décider de valider ou
d’annuler ...
HT-2011 HT-2011
Commit en 2 Phases Protocole C/S
• Principe • 1. PREPARER
– Diviser la commande COMMIT en deux phases – Le coordinateur demande aux autres sites s’ils sont prêts à commettre
– Phase 1 : leurs mises à jour.
• Préparer à écrire les résultats des mises à jour dans la BD • 2a. SUCCES : COMMETTRE
• Centralisation du contrôle – Tous les participants effectuent leur validation sur ordre du client.
– Phase 2 :
• 2b. ECHEC : ABORT
• Écrire ces résultats dans la BD
– Si un participant n’est pas prêt, le coordinateur demande à tout les
• Coordinateur : autres sites de défaire la transaction.
– Le composant système d'un site qui applique le protocole • REMARQUE
• Participant : – Le protocole nécessite la journalisation des mises à jour préparées et
– Le composant système d'un autre site qui participe dans l'exécution de des états des transactions dans un journal local à chaque participant.
la transaction
HT-2011 HT-2011
Page 8
Cas Favorable Cas Défavorable (1)
SITE COORDINATEUR SITE COORDINATEUR
SITE PARTICIPANT 1 SITE PARTICIPANT 2 SITE PARTICIPANT 1 SITE PARTICIPANT 2
PREPARE PREPARE PREPARE PREPARE
OK KO
OK OK
COMMIT COMMIT ABORT ABORT
ACK ACK ACK
ACK
HT-2011 HT-2011
Cas Défavorable (2) Commit distribué ou centralisé
• Validation à deux phases centralisée
SITE COORDINATEUR
SITE PARTICIPANT 1 SITE PARTICIPANT 2
Prepare OK Commit OK
PREPARE PREPARE
OK OK
COMMIT COMMIT
ACK
• Possibilité de diffuser la réponse au PREPARE
– chaque site peut décider localement dans un réseau sans perte
OK
Prepare
STATUS
COMMIT
ACK
HT-2011 HT-2011
Page 9
Transitions d'Etats Transactions bloquées
Initia
l • Que faire en cas de doute ?
CCommit/Prepare
– Demander l’état aux autres transactions : STATUS
Wait
• conservation des états nécessaires
VoteKO/GAbort VoteOK/GCommit
• message supplémentaire
Initial
Abort Commit – Forcer la transaction locale : ABORT
Prepare/VoteOK
• toute transaction annulée peut être ignorée
COORDINATEUR Ready
• cohérence garantie avec un réseau sans perte de message
GAbort/Ack GCommit/Ack
– Forcer la transaction locale : COMMIT
Abort Commit • toute transaction commise peut être ignorée
PARTICIPANT
• non garantie de cohérence avec le coordinateur
HT-2011 HT-2011
Commit en 3 Phases Protocole arborescent TP
Initial
• Inconvénient du commit à 2 CCommit/Prepare
• TP est le standard proposé par
Coordinateur global
phases Wait
l’ISO dans le cadre OSI
– en cas de time‐out en état VoteKO/GAbort VoteOK/PréCommit • Protocole arborescent
“Prêt”, le participant est – Tout participant peut déclancher
Abort PréCommit
bloqué une sous‐transaction
– le commit à 3 phases permet PréOK/GCommit Coordinateur local
Commit
– Un responsable de la validation est
d’éviter les blocages choisi
• Messages du commit à 3 Initial – Un coordinateur est responsable de Coordinateur localPoint de validation
(Noeud critique)
phases Prepare/VoteOK
ses participants pour la phase 1
– Prepare, • collecte les PREPARE
Ready
– Prepare to Commit, GAbort/Ack • demande la validation
PréCommit/PréOK
– Global‐Commit, – Le point de validation est
Abort PréCommit responsable de la phase 2
– Global‐Abort.
GCommit/Ack • envoie les COMMIT
Commit
HT-2011 HT-2011
Page 10
Moniteur transactionnel : Modèle
7. Moniteurs transactionnels
• Modèle DTP de l’X/OPEN
• Support de transactions ACID – Programme d’application AP AP
• Accès continu aux données – Gestionnaire de transactions TM
– Gestionnaire de communication
• Reprise rapide du système en cas de panne CRM
TX
• Sécurité d'accès – Gestionnaire de ressources RM TM
• Performances optimisées • Interfaces standards
– Partage de connexions – TX = interface du TM CRM
– Réutilisation de transactions – XA = interface du RM
TM
– intégration de TP
• Partage de charge
• Types de RM XA
– Distribution de transactions
– gestionnaire de fichiers
• Support de bases hétérogènes – SGBD
RM
• Respect des normes et standards – périphérique
HT-2011 HT-2011
Interface applicative TX Interface ressource XA
• tx_open • xa_open
– ordonne au TM d’initialiser la communication avec tous les RM dont – ouvre un contexte pour l’application.
les librairies d’accès ont été liées à l’application. • xa_start
• tx_begin – débute une transaction.
– ordonne au TM de demander aux RM de débuter une transaction. • xa_end
• tx_commit ou tx_rollback – indique au RM qu’il n’y aura plus de requêtes pour le compte de la
– ordonne au TM de coordonner soit la validation soit l’abandon de la transaction courante.
transaction sur tous les RM impliqués. • xa_prepare
• tx_set_transaction_timeout – lance l’étape de préparation du commit à deux phases.
– positionne un “ timeout ” sur les transactions • xa_commit
• tx_info – valide la transaction.
– permet d’obtenir des informations sur le statut de la transaction. • xa_rollback
– abandonne la transaction.
HT-2011 HT-2011
Page 11
Principaux moniteurs (1) Principaux moniteurs (2)
• Encina de Transarc • Tuxedo de USL
– issu de CMU (1992), racheté par IBM – éprouvé (depuis 1984), à la base de DTP
– supporte l’asynchronisme, les priorités et le routage
– construit sur DCE (OSF) pour la portabilité et la dépendant des données
sécurité – conformité DTP: Xa, Tx, XaTMI, CPI‐C, TxRPC
– transactions imbriquées • Top End de NCR
– conformité DTP : Xa, CPI‐C, TxRPC – produit stratégique d’AT&T
– respecte le modèle des composants DTP (AP, RM, TM,
• Open CICS de IBM CRM)
– construit sur Encina (et DCE) – haute disponibilité
– reprise de l’existant CICS (API et outils) – conformité DTP: Xa, Xa+, Xap‐Tp, Tx
– conformité DTP : Xa, CPI‐C • Autres : UTM de Siemens, Unikix
HT-2011 HT-2011
MTS de Microsoft 8. Conclusion
• Microsoft Transaction Server • Des techniques complexes
• Intégré à DCOM • Un problème bien maîtrisé dans les SGBDR
• Partage de grappes de NT (cluster) • La concurrence complique la gestion de
transactions
• Les disques sont supposés partagés
• Les transactions longues restent problématiques
• Allocation des ressources en pool aux requêtes : • Enjeu essentiel pour le commerce électronique
– pool de connexion aux ressources (SQL Server) – validation fiable
– pool de transactions (support) – reprise et copies
– pool de machines – partage de connections
• Ne suit pas les standards ! – partage de charge
HT-2011 HT-2011
Page 12
1. Objectifs
• Permettre l’exécution simultanée d’un grand
nombre de transactions
LA CONCURRENCE • Régler les conflits lecture / écriture
• Garder de très bonne performance
Objectifs • Eviter les blocages
Les bases
Le verrouillage deux phases
L’ordonnancement par estampilles
Les applications avancées
HT-2011 HT-2011
Les problèmes de concurrence 2. Les bases
• Perte d'opérations • Chaque transaction Ti est composée d’une séquence d’actions
– { T1 : Read A‐>a; T2 : Read A‐>b; T2 : b+1 ‐> b; T2 : Write <a11, a12, ..., a1ni>
b‐>A; T1: a*2 ‐>a; T1: Write a ‐> A } • Une exécution simultanée (Histoire) des transactions {T1, T2, ....
Tn} est une séquence d’actions
– H = < ai1j1, ai2j2 .... aikjk > telle que aij < aij+1 pour tout i et tout j et quel
• Introduction d'incohérence que soit aij de T1 ,... Tn, aij est dans H
– A = B { T1 : A*2‐>A; T2 : A+1‐>A; T2 : B+1 ‐> B; T1 : B*2 ‐ – C’est une séquence d’actions complète respectant l’ordre des actions des
> B } transactions
• Une exécution est sérielle si toutes les actions des transactions
ne sont pas entrelacées
• Non reproductibilité des lectures – elle est donc de la forme
– { T1 : Read A‐>a; T2 : Read A‐>b; T2 : b+1 ‐> b; T2 : Write – <Tp(1), Tp(2), ...Tp(n)> ou p est une permutation de 1, 2, ... n.
b‐>A; T1: Read A ‐> a }
HT-2011 HT-2011
Page 1
1
Sérialisabilité Graphe de précédence
• Exécution sérialisable • Précédences
– Une exécution est dite sérialisable si elle est – Techniques basées sur la seule sémantique des
équivalente à une exécution sérielle opérations de lecture / écriture
– Ti lit O avant Tj écrit => Ti précède Tj
• Plusieurs critères d’équivalence possibles – Ti écrit O avant Tj écrit => Ti précède Tj
– Equivalence de vue : tous les résultats visibles sont
identiques
– Equivalence du conflit : toutes les actions conflictuelles • Condition de sérialisabilité
sont effectuées dans le même ordre sur les objets de la – Le graphe de précédence doit rester sans circuit
base
HT-2011 HT-2011
Bilan Problèmatique
3. Le Verrouillage 2 phases
• La sérialisabilité est une • PRINCIPES
condition suffisante de – verrouillage des objets en lecture/écriture
correction
– opérations Lock(g,M) et Unlock(g)
– compatibilité:
L E
L V F
E F F
• Exercice
– Démontrer que les cas de perte – toute transaction attend la fin des transactions
d'opérations et d'incohérences incompatibles
sont non sérialisables
– garantie un graphe de précédence sans circuit
– les circuits sont transformés en verrous mortels
HT-2011 HT-2011
Page 2
2
Algorithmes Lock Algorithme Unlock
• Bool Function Lock(Transaction t, Objet O, Mode M){ • Procédure Unlock(Transaction t, Objet O){
Cverrou := 0 ;
Pour chaque transaction i  t ayant verrouillé l’objet O faire { t.verrou(O) := 0 ;
Cverrou := Cverrou U t.verrou(O) } ; // cumuler les verrous sur O Pour chaque transaction i dans la queue de O {
si Compatible (Mode, Cverrou) alors {
t.verrou(O) = t.verrou(O) U M; // marquer l’objet verrouillé si Lock(i, O,M) alors {
Lock := true ; } enlever (i,M) de la queue de O ;
sinon {
insérer (t, Mode) dans la queue de O ; // mise en attente de t débloquer i ; } ;
bloquer la transaction t ; }
Lock := false ; } ;
} }
HT-2011 HT-2011
Condition de corrections Problèmes du Verrouillage
• Transactions deux phases • Verrou mortel
– une transaction ne peut relâcher de verrous avant de – risques de circuit d'attentes entre transactions
les avoir tous acquis
T2
Nombre
T1
de verrous
temps T3

• Granularité des verrous
– page : en cas de petits objets, trop d'objets verrouillés
– objet : trop de verrous, gestion difficile
HT-2011 HT-2011
Page 3
3
Résolution du verrou mortel Améliorations du verrouillage
• Prévention • Relâchement des verrous en lecture après
– définir des critères de priorité de sorte à ce que le opération
problème ne se pose pas
– exemple : priorité aux transactions les plus anciennes – ‐ non garantie de la reproductibilité des lectures
– + verrous conservés moins longtemps
• Détection
– gérer le graphe des attentes • Accès à la version précédente lors d'une lecture
– lancer un algorithme de détection de circuits dès qu’une bloquante
transaction attend trop longtemps
– choisir une victime qui brise le circuit
– ‐ nécessité de conserver une version (journaux)
– + une lecture n'est jamais bloquante
HT-2011 HT-2011
Granularité Variable Verrouillage Altruiste
• Restitution des verrous sur les données qui ne
seront plus utilisées
• Plusieurs granules de verrouillage
sont définis, inclus l'un dans l'autre
– L'abandon d'une transaction provoque des cascades
base d'abandons
• Le verrouillage s'effectue en mode Table
– Nécessité d'introduire la portée d'une transaction
intention sur les granules Objets (transactions ouvertes)
cluster page
supérieurs et en mode effectif sur T1 T2
les granules choisis a
  T3
– les modes intentions sont compatibles Ligne
b
– les modes effectifs et intentions
c  
obéissent aux compatibilités
classiques
d

e 
Temps
HT-2011 HT-2011
Page 4
4
Bilan Verrouillage
Degré d'isolation en SQL2
• Approche pessimiste
• Définition de degrés d'isolation emboîtés – prévient les conflits
– Degré 0
– assez coûteuse
• garantit les non perte des mises à jour
• pose de verrous courts exclusifs lors des écritures – assez complexe
– Degré 1
• garantit la cohérence des mises à jour
• pose de verrous longs exclusifs en écriture • Approche retenue
– Degré 2 – dans tous les SGBD industriels
• garantit la cohérence des lectures individuelles
• pose de verrous courts partagés en lecture
• Difficile de faire mieux !
– Degré 3
• garantit la reproductibilité des lectures
• pose de verrous longs partagés en lecture
HT-2011 HT-2011
4. Ordonnancement par estampillage Algorithme d’ordonnancement
• Estampille (TimeStamp) associée à chaque transaction • Fonction READ (Transaction t, Objet O) {
– date de lancement si O.Writer  t alors {
– garantie d'ordre total (unicité) Read := Get(O) ; // effectuer la lecture
• Conservation des estampilles O.Reader := MAX (O.Reader,t) ; // mettre à jour dernier lecteur }
– dernier écrivain Writer sinon Abort(t); } .
– plus jeune lecteur Reader
• Fonction Write (Transaction t, Objet O, Contenu C){
• Contrôle d'ordonnancement
si O.Writer  t et O. Reader  t alors{
– en écriture: estampille écrivain > Writer et > Reader
Set(O,C) ; // effectuer l’écriture
– en lecture: estampille lecteur > Writer
O.Writer := t ; // mettre à jour dernier écrivain }
• Problèmes
sinon Abort(t); } .
– reprise de transaction en cas d'accès non sérialisé
– risque d'effet domino en cas de reprise de transaction
HT-2011 HT-2011
Page 5
5
Bilan Estampillage
La Certification Optimiste
• Approche optimiste
• Les contrôles s'effectuent seulement en fin de transaction – coût assez faible
– Phase d'accès: on garde les OID des objets lus/écrits – détecte et guérit les problèmes
– Phase de certification: on vérifie l'absence de conflits (L/E ou E/E même
objet) avec les transactions certifiée pendant la phase d'accès • Guérison difficile
– Phase d'écriture (commit) pour les transactions certifiées – catastrophique en cas de
nombreux conflits
• Avantages et inconvénients: – absorbe mal les pointes
– + test simple d'intersection d'ensembles d'OID en fin de transaction
– ‐ tendance à trop de reprises en cas de conflits fréquents (effondrement) • Sophistication
– ordonnancement multiversions
HT-2011 HT-2011
5. Techniques avancées Commutativité d'Opérations
• Possibilité de distinguer d'autres opérations que Lire/Ecrire
• Transactions longues – chaque objet possède sa liste d' opérations (méthodes)
– mise à jour d'objets complexes – les opérations commutatives n'entraînent pas de conflits
– sessions de conception – la commutativité peut dépendre du résultat
• Cas des ensembles
• Prise en compte de la sémantique des application
– opérations commutatives (e.g., ajouts d'informations) [Ins,ok] [Del,ok] [In, true] [In, False]
– essais concurrents
[Ins,ok] 1 0 0 0
[Del,ok] 0 1 0 1
• Travail coopératif
– modèles concurrents plutôt que séquentiels [In, true] 0 0 1 1
[In, False] 0 1 1 1
HT-2011 HT-2011
Page 6
6
Transactions Imbriquées
Contrôleur de Commutativité
• OBJECTIFS
Begin(T)
• Chaque objet possède un contrôle de concurrence défini au – Obtenir un mécanisme de Begin(t'1) Begin(t1)
niveau de la classe reprise multi‐niveaux
– laisse passer les opérations commutatives – Permettre de reprendre des
parties logiques de transactions
– bloque les opérations non commutatives (ordonnancement) Commit(t1)
– Faciliter l'exécution parallèle de Commit(t'1) Commet t1
sous‐transactions
Begin(t2)
• Le modèle est ouvert et nécessite • SCHEMA Begin(t21)
– soit des transactions de compensations – Reprises et abandons partiels
– soit la gestion de listes de transactions dépendantes – Possibilité d'ordonner ou non
les sous‐transactions Commit(t21)
Abort(t2)
• Un potentiel pour les SGBDO non encore implémenté (complexe) Commit(T) Annule t2 et t21
HT-2011 HT-2011
Verrouillage et Transactions Imbriquées Versions
BD PARTAGEE BD PERSONNELLE
• Chaque transaction peut acquérir ou relâcher des verrous
Objet
• Un verrou est accepté si l'objet est libre ou verrouillé par un Versionnable
V1
ancêtre CheckOut
Version
• Les verrous non relâchés sont rendus à la transaction mère Personnelle
• Problèmes de conflits entre sous‐transactions parallèles CheckIn
V2
– risque de verrous mortels V3
– l'ancêtre commun peut trancher CheckOut
• Gestion de journaux multiniveaux Version
Personnelle
– organisation sous forme de piles
V4 CheckIn
– nécessité de journaux multiples en cas de parallélisme
HT-2011 HT-2011
Page 7
7
CheckOut / CheckIn Fusion des Versions
• ChechOut
– extrait un objet de la BD afin d'en dériver une nouvelle • Maintient différentiel
version
– seuls les objets/pages modifiés sont maintenus
• CheckIn
– réinstalle une nouvelle version de l'objet dans la BD
Lecture Ecriture COut P COut E
• Pas d'objets communs modifiés
Lecture 1 0 1 0 – la fusion est une union des deltas
Ecriture 0 0 0 0
COut Partagée 1 0 1 0
• Des objets communs modifiés
COut Exclusif 0 0 0 0 – nécessité d'intervention manuelle (choix)
HT-2011 HT-2011
6. Conclusion
• Amélioration du verrouillage
– Transactions ouvertes
– Granularité variable
– Commutativité des opérations
– Transactions imbriquées
– Versions
• Amélioration des modèles transactionnels
– Transactions imbriquées
– Sagas, Activités, Versions
• Beaucoup d'idées, peu d' implémentations originales
– la plupart des systèmes utilise le verrouillage type SQL
HT-2011
Page 8
8
1. Objectifs de la Modélisation
Conception de BD relationnelle
• Meilleure compréhension du problème
– Abstraction des aspects cruciaux
1. Objectifs et principes – Omission des détails
2. Le modèle objet • Conception progressive
3. Passage au relationnel – Abstractions et raffinements successifs
– Prototypage rapide
4. Raffinement du schéma – Découpage en modules ou vues
5. Optimisation physique – Génération des structures de données et de traitements
• Visualisation du système
6. Conclusion – Diagrammes avec notation simple et précise
– Compréhension visuelle
HT-2011 HT-2011
Générations de méthodes Objectifs des méthodes objet
• 1. Méthodes d'analyse et de décomposition hiérarchiques • Réduire la distance sémantique entre le langage des utilisateurs et
– traitements ‐> sous‐traitements le langage des concepteurs
– Warnier, SADT, Jackson, De Marco – meilleure communication entre utilisateurs et concepteurs
• 2. Méthodes d'analyse et de représentation systémiques – abstraction du réel perçu en termes compréhensibles
– Séparation des données et des traitements • Regrouper l'analyse des données et des traitements
– Merise, Axial, SSADM – meilleure compréhension des choses
• 3. Méthodes d'analyse et de conception objet – plus grande cohérence entre les aspects statique et dynamique
– Réconciliation données et traitements • Simplification des transformations entre niveaux conceptuel et
– Réutilisation de composants interne
– implémentation directe du schéma conceptuel
– règles de transformations automatisées
HT-2011 HT-2011
Page 1
Principales méthodes objet Les cycles
• OOD (G. Booch) 1991 • Analyse (Analysis)
• OOA/OOD (T. Coad & E. Yourdon) 1991 – étude du problème utilisateur
• OMT (J. Rumbaugh et. al.) 1991 – génération de modèles de problèmes
• OOSE (I. Jacobson et al.) 1992
• Conception (Design)
• OOM (M. Bouzeghoub, A. Rochfeld) 1994
– raffinement de modèles de problèmes
• La notation UML (Booch, Jacobson, Rumbaugh) 1998
– Rational et OMG – génération de modèles d'implémentation (prototypes)
– une notation universelle • Implémentation (Implementation)
• RUP (Rationale Unified Process) – codage de modèles d'implémentation
– IEEE 1016 Document structure
– génération du code des programmes
HT-2011 HT-2011
2. Le modèle objet Diagrammes UML
• Objet • Définit le modèle objet à l’aide de 9 diagrammes:
– concept, abstraction ou entité clairement distinguable – Diagramme de cas d’utilisation
• Classe – Diagramme de classes
– description d'un groupe d'objet aux propriétés similaires – Diagramme d’objets
• Attribut – Diagramme d’états‐transition
– propriété nommée d'une classe représentée par une valeur dans chaque – Diagramme de séquence
instance
– Diagramme d’activité
• Opération – Diagramme de collaboration
– une fonction/transformation applicable aux objets d'une classe
– Diagramme de composants
• Méthode – Diagramme de déploiement
– une implémentation d'une opération pour une classe
• Intégrés dans la méthode progressive RUP
HT-2011 HT-2011
Page 2
Classes (UML) Association (relationship)
• Relation entre plusieurs classes
Voitures – caractérisée par un role (verbe), des cardinalités et
Nom Nveh: Int
Type: String
éventuellement des attributs
Marque: Constructeur
attributs
Vitesse: Int – représente des liens entre objets de ces classes
Km : Int
opérations – implémentée par une classe
Démarrer() • avec des opérations de navigation
Accélérer()
Rouler(km:Int)
Freiner() Personne Voiture
1
Possède *
Propriétaire Possédée
Date
Prix
HT-2011 HT-2011
Généralisation La pratique
• Association spécifiant une relation de classification • Bien comprendre globalement le problème à résoudre
– généralisation, e.g., Personne super‐classe de Emp • Essayer de conserver le modèle simple
– spécialisation, e.g., Emp sous‐classe of Personne • Bien choisir les noms
• Ne pas cacher les pointeurs sous forme d'attributs
Personne
– utiliser les associations
• Faire revoir le modèle par d'autres
– définir en commun les objets de l’entreprise
Emp Etudiant
• Documenter les significations et conventions
– élaborer le dictionnaire
Commerci Editeur Chercheur Stagiaire
al
HT-2011 HT-2011
Page 3
3. Passage au relationnel Réduction des généralisations
• Implémentations des attributs, généralisations, et • Aplatissage des hiérarchies
associations sous forme de tables – 1 table par classe avec jointures C
– mémorisent les états des objets – une seule table avec valeurs
nulles
– pas nécessaire d’avoir une BD objet – une table par feuille
• Réalisation de l ’héritage C1 C2
• Implémentation des méthodes sous forme de – statique :
procédures stockées • problème des valeurs nulles pour les C K
objets sans descendants
– état de l’objet passé en paramètre (clés) – dynamique : C1 K C1C
C C1 C2
– associées à une base de données • jointures sur clés, bien prévoir les C2 K C2 C
index!
– très important pour l’optimisation client‐serveur
(c)
(a) (b)
HT-2011 HT-2011
Implémentation d'association 4. Raffinement du schéma
• Par une table dont le schéma est le nom de l'association et la liste • Risques de mauvaise conception
des clés des classes participantes et des attributs de l'association – classe trop importante
• Exemple : – classe trop petite
– POSSEDE (N° SS, N° VEH, DATE , PRIX )
• Exemple :
• Amélioration possible
– Propriétaire‐de‐véhicule (n° ss, nom, prénom, n°
– Regrouper les associations 1 ‐‐> n avec la classe cible
veh, marque, type, puissance, couleur, date, prix)
• Exemple : • Propriétaire‐de‐véhicule = personne |x| possède |x| voiture
– VOITURE (N°VEH, MARQUE, TYPE, PUISSANCE, COULEUR)
– POSSEDE (N° SS, N° VEH, DATE , PRIX )
• Anomalies
– regroupés si toute voiture a un et un seul propriétaire – redondance de données, valeurs nulles
– perte de sémantique
HT-2011 HT-2011
Page 4
Dépendances Fonctionnelles Exemples
• Définition : • PERSONNE
– N° SS ‐‐> NOM ?
– Soient R(A1, A2 … An) un schéma de relation, X et Y
– NOM ‐‐> N° SS ?
des sous‐ensembles de A1, A2 …An;
• VOITURE
– On dit que X ‐‐> Y (X détermine Y ou Y dépend – (MARQUE, TYPE) ‐‐> PUISSANCE ?
fonctionnellement de X) ssi il existe une fonction qui a – MARQUE ‐‐> PUISSANCE ?
partir de toute valeur de X détermine une valeur – PUISSANCE ‐‐> TYPE ?
unique de Y • POSSEDE
• Formellement : – N° VEHP ‐‐> N° PROP ?
– ssi quel que soit l’instance r de R, pour tout tuple t1 et – N° PROP ‐‐> N° VEHP ?
t2 de r on a X(t1) = X(t2) ==> Y(t1) = Y(t2) – (N° VEHP, N° PROP) ‐‐> DATE ACHAT ?
HT-2011 HT-2011
Graphe de DF Notion formelle de Clé
– VOITURE (N°VEH, TYPE, COULEUR, MARQUE, • Définition :
PUISSANCE) – Un groupe d'attribut X est une clé de R (a1, a2 … an) ssi
• X ‐‐> A1 A2 … An
• il n'existe pas de sous‐ensemble Y de X tel que Y ‐‐> A1 A2 … An
• Plus simplement :
N° VEH – Une clé est un ensemble minimum d'attributs qui détermine tous les autres.
– Exemple : (n° veh) voiture ? (n° veh, type) voiture ?
COULEUR
• Non unicité :
TYPE MARQUE – Il peut y avoir plusieurs clés pour une relation (clés candidates)
– Une clé est choisie comme clé primaire
PUISSANCE
HT-2011 HT-2011
Page 5
Formes normales 1e Forme (1NF)
• Objectifs • Définition
– Définir des règles pour décomposer les relations tout – Une relation est en 1NF si tout attribut contient une
en préservant les DF et sans perdre d'informations, afin valeur atomique (unique)
de représenter des objets et associations du monde • Exemple
réel PERSONNE NOM PROFESSION
– Éviter les anomalies de mises a jour DUPONT Ingénieur, Professeur
• Éviter les réponses erronées MARTIN Géomètre
Une telle relation doit être décomposée en répétant les noms

pour chaque profession
HT-2011 HT-2011
2e Forme (2NF) Exemple 2NF
• Définition • Fournisseur (nom, adresse, article, prix)
– une relation est en 2NF ssi : – La clé est (nom, article)
• elle est en 1ère forme – Mais nom ‐‐> adresse : pas en 2NF!
• tout attribut non clé ne dépend pas d'une partie de clé
• Décomposition en 2NF
• Schéma – Fournisseur (nom, article, prix)
R K1 K2 X Y – Ad‐Fournisseur (nom, adresse)
Une telle relation doit être décomposée en

R1(K1,K2,X) et R2(K2,Y)
HT-2011 HT-2011
Page 6
3e Forme (3NF) Exemple 3NF
• Définition • Voiture (n° veh, marque, type, puissance, couleur)
– une relation est en 3NF ssi : – Type ‐‐> marque
• elle est en 2NF – Type ‐‐> puissance
• tout attribut n'appartenant pas a une clé ne dépend pas d'un – Pas en 3NF !
autre attribut non clé
• Schéma
R K X Y Z • Décomposition en 3NF
– Véhicule (n° veh, type, couleur)
– Modèle (type, marque, puissance)
Une telle relation doit être décomposée en
R1(K, X, Y) et R2(X,Z)
HT-2011 HT-2011
Propriété de la 3NF 5. Optimisation physique
• Toute relation R a une décomposition en relations R1, • On n'implémente pas forcément le schéma logique
R2 … Rn (ou plusieurs) en 3e forme normale telle que: – regroupement de relations interrogées ensemble parfois avantageux
– la dénormalisation évite des jointures coûteuses
1) pas de perte de dépendances
– nécessite de gérer la redondance en mise à jour
Les dépendances fonctionnelles des relations décomposées
permettent de générer celles de la relation initiale. • Choix du placement
– index primaire plaçant = clé primaire
2) pas de perte d'informations – hachage parfois avantageux (groupes de relations)
Les relations décomposées permettent à tout instant de • Choix des index
recomposer la relation initiale par jointures.
– contraintes référentielles
• Faiblesse: – attributs de sélections fréquentes
– Il existe des relations en 3NF avec des redondances … – index B‐tree ou bitmap
HT-2011 HT-2011
Page 7
Réglage des performances 6. Conclusion
• Intérêt de l’utilisation d’une méthode objet
• 1. Régler les requêtes en premier : – proche du monde réel
– vérifier les plans d'exécution générés
– démarche sémantique claire
– reformuler les requêtes sans changer le schéma
– diagramme UML standards
• 2. Régler les dimensions des tables par
partitionnement • Passage au relationnel automatique
• 3. Régler les index et l’organisation des relations – outils du commerce utilisables (Rationale Rose, etc.)
• 4. Considérer l'usage de données redondantes – supporteront les extensions objet‐relationnel à venir
• 5. Revoir les décisions de normalisation • Normalisation à l’exception
– utile quand sémantique confuse
• L'usage de vues permet de masquer ces • Optimisation et réglage
réorganisations – une étape essentielle et permanente
HT-2011 HT-2011
Page 8

Introduction: Bases de Données Introduction Et Objectifs

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Introduction: Bases de Données Introduction Et Objectifs

Transféré par

Droits d'auteur :

Formats disponibles

1.

Symptomes : yy Symptomyyyy

Symptomes : yy Turlututudhjsd

Redondance (données) Caractéristiques Interrogations Caractéristiques

 Gestion de pannes ???  Gestion de pannes ???

 Partage des données ???

Turlututudhjsd  Gestion de pannes ??? ‐ Interrogation, cohérence, partage, gestion de pannes, etc…

2 3 4 1 mars 250 …. …. …. …………

…. ……. ……. 2 Fluisédal ……………………………..

Avantages de l’indépendance logique III ‐ Manipulation aisée

VI ‐ Intégrité Logique Contraintes d’intégrité

Atomicité et Durabilité VIII ‐ Partage des données

 Annuler le débit !!  S’assurer que le

X ‐ Standardisation 3. Architecture des SGBD

– Applications multisources… — Pico-bases => faible empreinte et forte sécurité

données code données

SGBD 1 SGBD 2 code données code données

code données code données

SGBD • OLAP (On Line Analytical Processing)

Nveh Type Marque Vitesse Km

À cause de l'association (obligatoire).

• Exemple: CoulVins Coul Choix • ATTRIBUT

généralisation à n 1 VINS CRU MILL REGION COULEUR

– Ramener au même schéma avec des valeurs nulles  A1,A2,...Ap (R) VOLNAY BOURGOGNE

–  { =, <, >=, >, <=, !=} JULIENAS 1986 BEAUJOLAIS C

• Jointure naturelle VOLNAY Bourgogne A

Le Relationnel MEDOC 200 27 Le Relationnel 28

Opérations Organisation du Langage

Fonctionnalités des SGBD Modification de requêtes

Create View Ongola as ( Définition des

vue AND A.QTE > 100

 Annuler le débit !!  S’assurer que le

préventive – WHERE NOM = 'RALEUR' MISES

TRES EFFICACE MAIS COMPLEXE A IMPLANTER

Administrateur Système {users login, …} GRANT <droits> ON <objet>

VINS COMMANDES BUVEURS

Exemple (3) Définition des vues

• VUES = RESTRICTION-PROJECTION DES RELATIONS DE BASE CREATE VIEW <nom_vue> [(liste_attributs)]

CREATE VIEW BUVEURS-1

C.NV = V.NV AND

Déclaration et interrogation Interrogation des vues (1)

MODIFICATION DE QUESTION PAR RESTRUCTURATION SYNTAXIQUE

BUVEURS COMMANDES VINS

Arbre algébrique de la vue CPV

BUVEURS COMMANDES VINS

Cru, Qte CPV

Résultat Ville = Douala

Ville = Douala Date • Pour rendre le report de mises à jour possible, la définition de la

META-BASE Modification de requêtes

• Notion 11: Index (Index) Adresses relatives

Méthodes d’accès aux données

Langages de requêtes Calcul Relationnel

Sélection via index Utilisation d'Index B‐tree

Jointure R1.A = R2.B 31 32

• Etapes 1 et 2 : indépendantes des données V.CRU, V.MILL

A.NV V.NV P.REGION = « Bordelais »

B.VILLE = "PARIS" ABUS A

La base TPC‐A/B La transaction Débit ‐ Crédit

Ombre Nouvelle Table des Pages

SITE PARTICIPANT 1 SITE PARTICIPANT 2 SITE PARTICIPANT 1 SITE PARTICIPANT 2

PREPARE PREPARE PREPARE PREPARE

COMMIT COMMIT ABORT ABORT

ACK ACK ACK