 Mastère BI

©NESRINE ELLEUCH ISET Radès

A.U.2023/2024
Bienvenue au Base de Données
Distribuées
ISET Radès 2023/2024
3H/Semaine COURS INTEGRE (7 semaines)

Chapitre I 2
 Bonjour!
Nesrine ELLEUCH JALLOULI
Ingénieur Réseaux (INSAT), Mastère GDL (ENSI)
Enseignante ISET Radès, ISET Nabeul Depuis 2009 (Module
Data Warhouse)
Certifiée IBM COGNOS Reporting 10.
Accompagnement de sociétés dans la mise en place de
solutions BI.
Formatrice en Digital Marketing.
Coordinatrice Orange Tech Club ISET Nabeul (Avril 2016-
Septembre 2018).
Certifiée Google Analytics & Inbound Marketing
Passionnée par le BI et le
[Link]
[Link]
marketing digital
 Introduction au domaine

BD de données

BD Avancées

ACID, BASE & CAP

Revoir les principes avancés de BD

Revoir les principes de transaction & concurrence

L’optimisation des requêtes

Les mécanismes de distribution des bases de

données
Aperçu de contenu

1 Transaction & Concurrence

2 Introduction aux bases de données
réparties
3 Conception de Bases de données réparties
 Vos Attentes
Présentez vous?
Quelle est votre spécialisation?
Quelle est votre expérience en Bases de
données?
L’une des principales attentes du cours:

“Une question pour laquelle

je voudrais une réponse…”
“J’aimerais en savoir
davantage au sujet de …”
“Mon principal intérêt est…”
•Ressources:
•Principles of Distributed Database Systems, Fourth Edition; M. Tamer Özsu & Patrick Valduriez.
Springer
ISBN 978-3-030-26252-5. 2020.
•[Link]
•Complément: Base de données avancées
•Ensemble de cours proposés par l’INRIA pour introduire les mécanismes de transaction, d’index et
d’optimisation de requêtes.
•[Link]
• Projet
• Exposé (plus exemple) sur la distribution, réplications, et le traitement des requêtes (et transactions)
réparties dans les SGBD Relationnels, NoSql Ou NewSql (au hasard)
•[Link]
• Examen

8
 [Link]
Ces transparents sont tirés du cours
[Link]/producteurs/inria/cours_en_ligne/bases_de_donnees_r
elationnelles
 Module 1

Histoire des SGBD

• Un peu d’histoire
 • 1950 Développement du modèle hiérarchique
(IMS)
•1970 Apparition du modèle relationnel (Edgar
F. T. Codd)
•1980’s Domination du modèle relationnel
•2000’s Émergence du terme NoSQL
•2011 Émergence du NewSQL

NoSQL vs SQL Historique et évolution Sébastien

Combéfis
 • 1950 Développement du modèle hiérarchique
(IMS)
•1970 Apparition du modèle relationnel (Edgar
F. T. Codd)
•1980’s Domination du modèle relationnel
•2000’s Émergence du terme NoSQL
•2011 Émergence du NewSQL

NoSQL vs SQL Historique et évolution Sébastien

Combéfis
 15

 Faire des jointures entre les tables de la base de données

 Faire des requêtes complexes avec un langage de haut niveau
sans se préoccuper des couches basses
 Gérer l'intégrité des données de manière infaillible: Gérer être
capable de garantir le contenu de la base de données, quelles
que soient les mises à jour effectuées sur les données, ainsi
que sa pérennité.

Source
OpenClassroom: Maitrisez le théorème de CAP
 • Stockage efficace de données de manière persistante
• Plus de flexibilité que le stockage dans des fichiers
•Accès concurrent aux données, en lecture et/ou écriture
•Utilisation de transactions pour contrôler l’accès aux
données
•Intégration et collaboration d’applications en entreprise
•Réalisé avec une intégration par base de données partagée
Modèle relationnel basé sur un modèle standard

NoSQL vs SQL Historique et évolution Sébastien

Combéfis
 • Les bases de données relationnelles sont puissantes et
stables...
•Pas prêtes de disparaitre à court et moyen terme ...mais elles
ne sont plus suffisantes
•Lourdeur inutile pour le stockage de certains types de
données
•Systèmes hybrides combinant plusieurs technologies De
manière concurrente, coopérative, répartie, redondante...

NoSQL vs SQL Historique et évolution Sébastien

Combéfis
NoSQL vs SQL Historique et évolution Sébastien
Combéfis
 • Conversion de l’information de la représentation naturelle en tables
•Reconstruction de l’information depuis les tables
•Nécessité de modéliser les données (sémantique) avant stockage
• Schéma rigide forçant données d’une colonnes avec le même type
• Difficilement mis à l’échelle (scaling)
•Difficulté de faire des jointures entre différents systèmes
•Plusieurs dialectes existants du SQL (portabilité)
•Certaines règles business difficilement exprimable en SQL
• Recherche approximative et de type fuzzy difficile
• Pas de stockage et validation efficace de documents complexes

NoSQL vs SQL Historique et évolution Sébastien

Combéfis
 • Division d’un système IT en deux parties Une partie
plutôt transactionnelle et une plus analytique

NoSQL vs SQL Historique et évolution Sébastien

Combéfis
 • Online Transactional Processing (OLTP)
•Utilisation purement transactionnelle des données (gestion)
•Online Analytical Processing (OLAP)
•Tableau de bord, analyse historique et prédictive
(statistique)
•Limitation du modèle relationnel pour OLAP
•Agrégats, optimisation de requête, indexation... pas
suffisants

NoSQL vs SQL Historique et évolution Sébastien

Combéfis
 • 1950 Développement du modèle hiérarchique
(IMS)
•1970 Apparition du modèle relationnel (Edgar
F. T. Codd)
•1980’s Domination du modèle relationnel
•2000’s Émergence du terme NoSQL
•2011 Émergence du NewSQL

NoSQL vs SQL Historique et évolution Sébastien

Combéfis
 •Johan Oskarsson au Hadoop summit
• Choix d’un nom court, mémorable, peu de résultat Google
• #NoSQL “open-source, distributed, nonrelational databases”
•Plusieurs caractéristiques communes de ces bases de données
• N’utilisent pas le modèle relationnel, ni SQL
• Open source
• Conçues pour être exécutées sur de large clusters
• Basées sur les besoins des propriétés web du 21e siècle Pas de
schéma, ajout de champs sans contrôle

NoSQL vs SQL Historique et évolution Sébastien

Combéfis
NoSQL vs SQL Historique et évolution Sébastien
Combéfis
 •Hausse de la productivité lors du développement
•Gain de temps mapping de la base de données vers la
mémoire Moins de code à écrire, débugguer et faire évoluer
•Quantité de données à grande échelle Stockage rapide de
grandes quantités de données
•Base de données répartie sur des clusters

NoSQL vs SQL Historique et évolution Sébastien

Combéfis
 • 1950 Développement du modèle hiérarchique
(IMS)
•1970 Apparition du modèle relationnel (Edgar
F. T. Codd)
•1980’s Domination du modèle relationnel
•2000’s Émergence du terme NoSQL
•2011 Émergence du NewSQL

NoSQL vs SQL Historique et évolution Sébastien

Combéfis
 •La définition faite par le « 451 group’s » :
•« Un SGBD qui offre l'évolutivité et la flexibilité promise par
NoSQL, tout en conservant le support pour les requêtes SQL
et les propriétés ACID »

NoSQL vs SQL Historique et évolution Sébastien

Combéfis
 •Nouvelle tendance pour combiner la force du SQL et NoSQL
•Garanties du relationnel avec la souplesse du NoSQL
•Souvent appelé “SQL on Steroids” par la communauté
•Basé sur le modèle relationnel et le langage SQL
•Mise à l’échelle, flexibilité et haute performance du NoSQL
•Propriétés ACID respectées avec horizontal scaling

NoSQL vs SQL Historique et évolution Sébastien

Combéfis
NoSQL vs SQL Historique et évolution Sébastien
Combéfis
• ACID VS BASE VS CAP
 31

 ACID pour les transactions (séquences d'opérations/requêtes) :

 Atomicité : Une transaction s’effectue entièrement ou pas du
tout
 Cohérence : Le contenu d’une base doit être cohérent au début
et à la fin d’une transaction
 Isolation : Les modifications d’une transaction ne sont
visibles/modifiables que quand celle-ci a été validée
 Durabilité : Une fois la transaction validée, l’état de la base est
permanent (non affecté par les pannes ou autre)

Source
OpenClassroom: Maitrisez le théorème de CAP
 32

 Ces propriétés ne sont pas applicables dans un contexte distribué tel que le
NoSQL.
◦ En effet, prenons l'exemple d'une transaction de cinq opérations (lecture/écriture) : cela
implique une synchronisation entre cinq serveurs pour garantir l'atomicité, la cohérence et
l'isolation. Au final, cela se traduit par des latences dans les transactions (en cours et en
concurrence). Ce qui n'est pas tolérable lorsque justement on veut éviter ces latences en
distribuant les calculs.
 Le problème s'aggrave encore lorsque l'on distribue les données car il va falloir
répliquer chaque donnée. Pourquoi ? Tout simplement parce que si un serveur
tombe en panne, il faut pouvoir garantir de retrouver toutes les données
présentes sur ce serveur, donc on fait de la réplication. Mais cela veut dire
également qu'il va falloir synchroniser toutes mises à jour avec tous les
réplicas de la donnée !

Source
OpenClassroom: Maitrisez le théorème de CAP
 33

 Les propriétés BASE ont été proposées pour caractériser les

bases NoSQL :
 Basically Available : quelle que soit la charge de la base de
données (données/requêtes), le système garantie un taux de
disponibilité de la donnée
 Soft-state : La base peut changer lors des mises à jour ou lors
d'ajout/suppression de serveurs. La base NoSQL n'a pas à être
cohérente à tout instant
 Eventually consistent : À terme, la base atteindra un état
cohérent
Source
OpenClassroom: Maitrisez le théorème de CAP
 34

 Ainsi, une base NoSQL relâche certaines contraintes, telles que

la synchronisation des réplicas, pour favoriser l'efficacité. Le
parallèle ACID / BASE repris du domaine de la chimie permet
d'appuyer là où ça fait mal : la concurrence. L'enfer des
transactions gérées par les bases de données relationnelles est
transformé en paradis pour le temps de réponse en relâchant
cette contrainte impossible à maintenir.

Source
OpenClassroom: Maitrisez le théorème de CAP
 35

 Théorème de Brewer dit "théorème de CAP« , proposé en

2000, reposant sur 3 propriétés fondamentales pour
caractériser les bases de données (relationnelles, NoSQL et
autres) :
 Consistency (Cohérence) : Une donnée n'a qu'un seul état
visible quel que soit le nombre de réplicas
 Availability (Disponibilité) : Tant que le système tourne
(distribué ou non), la donnée doit être disponible
 Partition Tolerance (Distribution) : Quel que soit le nombre de
serveurs, toute requête doit fournir un résultat correct

Source
OpenClassroom: Maitrisez le théorème de CAP
 36

 Dans toute base de données, vous ne pouvez respecter au plus

que 2 propriétés parmi la cohérence, la disponibilité et
la distribution: CA - AP - CP.

Source
OpenClassroom: Maitrisez le théorème de CAP
 37

Source
OpenClassroom: Maitrisez le théorème de CAP
• Evolutivité/ Scalability
 L'évolutivité est la capacité d'un système à fournir de meilleures performances
lorsque la taille du système est augmentée avec plus de ressources.
 Les deux mesures de performance les plus importantes sont le débit et le
temps de réponse.
◦ Le débit: le nombre d'opérations par unité de temps qu'un système peut effectuer. Dans le cas
d'une base de données, les mesures typiques du débit sont les transactions/seconde, les
insertions/seconde, les requêtes/seconde. Le débit dépends de la charge de travail, du système
logiciel et matériel sous-jacent particuliers.
◦ Le temps de réponse: le temps écoulé entre la soumission d'une opération et la réception de la
réponse. Il est important de définir dans quelles conditions le temps de réponse est mesuré: état
stable, types de transactions, etc.

39
 Evolutivité [Özsu & Valduriez 2020]: la capacité à fournir un débit plus important
lorsque nous utilisons plus de ressources.
 Cela dépend du système soit centralisé ou distribué.
 L'évolutivité peut être classée entre verticale et horizontale.
 Dans un système centralisé, nous pouvons ajouter plus de CPU, plus de mémoire,
plus de périphériques de stockage pour augmenter les ressources de calcul. On dit
qu'une base de données évolue verticalement lorsqu'elle est capable de fournir un
débit plus important avec un ordinateur plus grand en termes de CPU, de mémoire
et de dispositifs d'E/S.
 Dans le cas d’une base de données distribuée fonctionnant sur un ensemble
d'ordinateurs reliés par un réseau, c'est-à-dire sur un cluster d'ordinateurs, nous
parlons d'évolutivité horizontale. Une base de données évolue horizontalement
lorsque l'ajout de nœuds supplémentaires au cluster permet d'augmenter le débit
(voir la figure 2, chaque colonne représente un cluster, chaque case étant un
serveur au sein du cluster). 40
41
• Transactions & Accès
Concurrent
 43

 En BD 2 problèmes :
◦ De multiples utilisateurs doivent pouvoir accéder à la base de donnée en même
temps àproblème d’accès concurrents
◦ De nombreuses et diverses pannes peuvent apparaître. Il ne faut pourtant pas
perdre les données…,

La Gestion de transactions répond à ces problèmes

Source
[Link] Chapitre I
 44

Transactions bancaires
• Alice souhaite verser à Bob 100 euros.
• Le SGBD doit effectuer 2 opérations sur la table
COMPTE :
– Retirer 100 euros au compte d’Alice
– Ajouter 100 euros au compte de Bob
COMPTE

Source
[Link] Chapitre I
 45

Source
[Link] Chapitre I
 46

 Les deux opérations (ou aucune) doivent être validées pour

maintenir la cohérence des données : c’est l’atomicité !
 COMMIT : permet de valider tous les changements
 ROLLBACK : permet d’annuler tous les Changements
 On appelle transaction un ensemble séquentiel d’opérations
permettant de passer d’un état cohérent à un autre.

Source
[Link] Chapitre I
 47

 Une transaction est une suite d'opérations interrogeant et/ou

modifiant la BD, pour laquelle l'ensemble des opérations doit
être soit validé, soit annulé.
 Toute la transaction est réalisée ou rien ne l’est
◦ Validation : toute la transaction est prise en compte
◦ Avortement ou annulation : la transaction n’a aucun effet
 Sous oracle
 – Début d’une transaction : ordre SQL ou fin de la précédente
 – Fin d’une transaction : validation(Commit) ou annulation
(Rollback)
Chapitre I
 48

Transaction: Définition

 L'exécution d’une transaction provoque le passage d'un état

 cohérent de la BD à un nouvel état cohérent
 • Une transaction est constituée de trois primitives
Ouverture d’une transaction Begin
transaction Travail sur les données
Travail sur les données
clôture avec confirmation à COMMIT
clôture avec annulation à ROLLBACK

temps
 49

 Atomicité
 Soit toutes les modifications effectuées par une transaction
sont enregistrées dans la BD, soit aucune ne l’est.
 Cohérence
 Une transaction fait passer une BD d’un état cohérent à un
autre état cohérent. Un état cohérent est un état dans lequel
les contraintes d’intégrité sont vérifiées.
 Isolation
 Une transaction se déroule sans être perturbée par les
transactions concurrentes : tout se passe comme si elle se
déroulait seule.
 50

 Durabilité
 Une fois qu’une transaction a été confirmée le SGBD garantit
qu’aucune modification qu’elle a effectuée ne sera perdue
même en cas : interruption, pannes du système
d’exploitation, « crash » de disque, etc.

Source
[Link]
 51

 Concurrence
 Nombreuses transactions en parallèle
 Besoin pour le SGBD d’être capable de les gérer. Eviter :
◦ – Pertes d’opérations / introduction d’incohérences
◦ – Observation d’incohérences: Lectures non reproductibles / lectures fantômes
 Des problèmes similaires apparaissent dans le cas des
pannes.

Source
[Link]
 52

 Problématique
 Une base de données n’est pas interrogée et modifiée par un
seul utilisateur.
 Des problèmes d’incohérences peuvent apparaître lorsque
plusieurs utilisateurs effectuent des opérations conflictuelles,
ce qui peut être dû à un défaut d’isolation.
 Quels sont ces incohérences ?
 Quelles sont ces opérations ?
 Comment éviter de se placer dans des situations d’opérations
conflictuelles ?
Source
[Link]
 53

 Problématique
 Des problèmes peuvent survenir lors de l’accès (lecture /
écriture) concurrent sur des opérations successives

 On aimerait que les opérations puissent se dérouler en

isolation
 Dans la suite : déterminer les opérations potentiellement
conflictuelles entre deux transactions

Source
[Link]
 54

 Problématique
 1 table : EMP (NE, Nom, Sal)
 3 nuplets :

Source
[Link]
 55

 Problématique
 1 table : EMP (NE, Nom, Sal) NE
0
NOM
Charlie
SAL
2000

3 nuplets :
1 Diana 2100
 2 Eric 1600

 … et deux utilisateurs :
 Alice et Bob

Source
[Link]
 56

 SELECT [Link] NE NOM SAL

0 Charlie 2000
FROM EMP E 1 Diana 2100

WHERE [Link] = « Charlie » 2 Eric 1600

“2000”

PAS DE PROBLEME
SI A ET B LISENT DES
 SELECT [Link]
N-UPLETS DISTINCTS
FROM EMP E
WHERE [Link] = « Diana »
Source “2100”
[Link]
 57

 SELECT [Link] NE NOM SAL

0 Charlie 2000
FROM EMP E 1 Diana 2100

WHERE [Link] = « Charlie » 2 Eric 1600

 “2000”

PAS DE PROBLEME
SI A ET B LISENT LE
 SELECT [Link]
MEME
FROM EMP E
WHERE [Link] = « Charlie » N-UPLET
Source “2000”
[Link]
 58

 UPDATE EMP SET SAL = 2050 NE

NE NOM
NOM SAL
SAL
0
0 Charlie
Charlie 2050
2000
WHERE NOM = « Charlie » 1
1 Diana
Diana 2100
2100

 1 Nuplet modifé 2
2 Eric
Eric 1600
1600

PAS DE PROBLEME
 SELECT [Link] SI A MODIFIE UN N-
FROM EMP E
UPLET
WHERE [Link] = « Diana »
“2100” QUE B NE LIT PAS
Source PAR LA SUITE
[Link]
 59

 UPDATE EMP SET SAL = 2050 NE

NE NOM
NOM SAL
SAL
0
0 Charlie
Charlie 2050
2000
WHERE NOM = « Charlie » 1
1 Diana
Diana 2100
2100

 1 Nuplet modifé 2
2 Eric
Eric 1600
1600

L’ORDRE EST
 SELECT [Link] IMPORTANT
FROM EMP E
SI A MODIFIE UN N-
WHERE [Link]
= « Charlie » UPLET
Source “2050” Nouvelle valeurQUE B A LU OU VA LIRE
[Link]
 60

NE
NE NOM
NOM SAL
SAL
0
0 Charlie
Charlie 2000
2050
1
1 Diana
Diana 2100
2100
SELECT [Link] FROM EMP E 2
2 Eric
Eric 1600
1600

WHERE [Link] = « Charlie

»
2000
UPDATE EMP SET SAL =
2050
WHERE NOM = « Charlie »
SELECT [Link] FROM EMP E
B LIT DEUX FOIS LA MEME
WHERE [Link] = « Charlie
» VALEUR ET OBTIENT DES
2050 RESULTATS DIFFERENTS !
CETTE ANOMALIE EST DITE
LECTURE NON REPRODUCTIBLE.
Source
[Link]
 61

 Un nuplet peut être produit par la requête (explicite).

 Un nuplet peut être utilisé pour produire le résultat de la
requête (implicite) e.g. requêtes d’agrégats.
 Une modification de l’un des nuplets utilisé pour calculer la
requête causera donc un problème.

Source
[Link]
 62

NE
NE NOM
NOM SAL
SAL
0
0 Charlie
Charlie 2000
2050
1
1 Diana
Diana 2100
2100
2
2 Eric
Eric 1600
1600
3 Flore 2300

SELECT AVG([Link])
FROM EMP E INSERT INTO EMP VALUES
1900 (3, « Flore», 2300)
SELECT AVG([Link])
B EXECUTE DEUX FOIS LA MEME
FROM EMP E
REQUETE ET OBTIENT DES
2000
RESULTATS DIFFERENTS !
CETTE ANOMALIE EST DITE
LECTURE FANTOME.
Source
[Link]
 63

 UPDATE EMP SET SAL = 2050 NE NOM SAL

0 Charlie 2000
WHERE NOM = « Charlie » 1 Diana 2100

 1 Nuplet modifé 2 Eric 1600

NE NOM SAL
0 Charlie 3000
1 Diana 2100
2 Eric 1600

UPDATE EMP
SET SAL = 3000 SI A MODIFIE UN N-UPLET
WHERE NOM = « Charlie » PUIS B LE MODIFIE AUSSI
 3000” ALORS A PERD
Source  1 Nuplet modifé SA MODIFICATION EN COURS
DE TRANSACTION
[Link]
 64

 Sérialisabilité
 Une transaction = une séquence d’opérations.
 Transactions sérielles = exécuter toute la transaction T1 puis
T2 etc…
= pas de problème !
 La sérialisabilité permet de répondre au problème de
l’isolation dans le cas de transactions qui s’enchevètrent
 Il faut permettre :
 La meilleure fluidité possible
 La meilleure performance possible
Source  D’éviter les blocages
[Link]
 65

 Plusieurs problèmes peuvent apparaitre

 Lecture non reproductible
 Lecture fantôme

 Les SGBDR peuvent proposer plusieurs mécanismes aux développeurs pour

assurer le niveau de contrôle souhaité

 Exécuter les transactions avec possibilité de Lecture non reproductible

 Exécuter les transactions avec possibilité de Lecture fantôme
 Exécuter les transactions sérialisable: c’est le niveau le plsu important de contrôle.
 Chaque transaction s’exécute comme si elle était seule (pas de concurrence) ,
mais qui bloque le plus de ressources systèmes.

Source
[Link]