Bases de Données Relationnelles/Non Relationnelles

M. BOUMEDIENE

Institut National des Télécommunications et des Technologies

de l’Information et de la Communication
e-mail: mboumediene[at][Link]

1/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Plan

1 Base de Données Relationnelles

2 Nouveaux Besoins

3 NOSQL

4 En quoi NOSQL est différent du modèle relationnel ?

2/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Plan

1 Base de Données Relationnelles

2 Nouveaux Besoins

3 NOSQL

4 En quoi NOSQL est différent du modèle relationnel ?

3/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

C’est quoi un système de base de données ?

Un système de base de données :

4/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

C’est quoi un système de base de données ?

Un système de base de données :
est nécessaire pour la gestion
enregistrer, rechercher et mettre à jour les données
prise en charge des transactions : exécuter une séquence d’opération sans interruption
(atomique)
interfaces pour les langages de programmation/applications

4/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

C’est quoi un système de base de données ?

Un système de base de données :
est nécessaire pour la gestion
données massives
structurés : modèle de données relationnel avec un schéma fixe (tables)
semi-structurées : arbre (XML) ou graphe
non structurées : documents texte

4/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

C’est quoi un système de base de données ?

Un système de base de données :

est nécessaire pour la gestion
données massives
doit être efficace
enregistrement/récupération de données rapide (écriture/lecture)

4/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

C’est quoi un système de base de données ?

Un système de base de données :

est nécessaire pour la gestion
données massives
doit être efficace
persistant
les données persistent sur le disque (support de sauvegarde) après une opération d’écriture
données disponibles pendant une longue période

4/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

C’est quoi un système de base de données ?

Un système de base de données :
est nécessaire pour la gestion
données massives
doit être efficace
persistant
fiabilité
données non erronées (maintien l’intégrité)
sauvegarde distribuée (redondance physique)
sauvegarde/restauration automatique des données

4/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

C’est quoi un système de base de données ?

Un système de base de données :
est nécessaire pour la gestion
données massives
doit être efficace
persistant
fiabilité
consistance
pas de données incorrectes ou contradictoires
vérifie automatiquement la contrainte de consistance (dépendance des données: contrainte
de clé étrangère)
mettre à jour automatiquement les copies distribuées dans le cas de système distribué

4/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

C’est quoi un système de base de données ?

Un système de base de données :

est nécessaire pour la gestion
données massives
doit être efficace
persistant
fiabilité
consistance
non redondant
ne pas enregistrer les informations dupliquées (pas de redondance logique)
pas de données erronées

4/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

C’est quoi un système de base de données ?

Un système de base de données :

est nécessaire pour la gestion
données massives
doit être efficace
persistant
fiabilité
consistance
non redondant
multi-utilisateurs
accès concurrents (simultanés) des utilisateurs (applications)
contrôler les accès afin d’assurer la confidentialité des données (vues)

4/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Conception d’une base de données

Quelle donnée est importante pour les utilisateurs/applications

Comment enregistrer les données importantes dans la base ?

5/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Conception d’une base de données

Quelle donnée est importante pour les utilisateurs/applications

Comment enregistrer les données importantes dans la base ?
Critères de conception
exhaustive (complète) : garantit que tous les aspects sont couverts
fiable : garantit que seules les informations correctes sont enregistrées
minimal : seules les informations nécessaires sont enregistrées et pas de redondance
lisible : pas d’encodages complexes et le concept est explicite ce qui facilite son utilisation
modifiable : facile à adapter pour des changements futures
modularité : données sont divisées en sous-ensembles ce qui forment des entités logiquement
cohérentes afin de simplifier la gestion.

5/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Modèle entité-association
Représentation graphique d’une base de données
Entités et relations (avec des complexités 1:1, 1:n, n:m)
Attributs : valeur simple, valeur composée
Attributs clés

6/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Systèmes de Gestion de Base de Données Relationnelles (SGBDR)

Succès depuis les années 1980

Plusieurs systèmes avec beaucoup de fonctionnalités
Solutions commerciales
Oracle (propriétaire également de MySQL)
IBM (DB2)
Microsoft (Access/SQLServer)
Sybase

7/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Systèmes de Gestion de Base de Données Relationnelles (SGBDR)

Succès depuis les années 1980

Plusieurs systèmes avec beaucoup de fonctionnalités
Solutions commerciales
Oracle (propriétaire également de MySQL)
IBM (DB2)
Microsoft (Access/SQLServer)
Sybase
Solutions open source
Postgres
MariaDB

7/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Systèmes de Gestion de Base de Données Relationnelles (SGBDR)

Succès depuis les années 1980

Plusieurs systèmes avec beaucoup de fonctionnalités
Solutions commerciales
Oracle (propriétaire également de MySQL)
IBM (DB2)
Microsoft (Access/SQLServer)
Sybase
Solutions open source
Postgres
MariaDB
Langage SQL (Structured Query Language) qui est le standard pour communiquer avec les SGBDR
Quelques outils graphiques pour concevoir et interroger les bases de données relationnelles

7/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Base de Données Relationnelle

Modèle de données relationnel
Une base de données est organisée sous la forme d’une ou plusieurs tables (relation symbol)
L’en-tête détermine les noms de colonnes (noms d’attributs) et leur domaine de définition
Une table contient une collection de lignes
Ces lignes représentent les données (tuples)
Une ligne est elle-même une suite de valeurs, chacune d’un type déterminé. Par exemple
(BookID, ReaderID) : entier, ReturnDate : date
une ligne regroupe des informations concernant un objet, un individu, un événement ⇒ un
concept du monde réel, une entité

8/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Base de Données Relationnelle

Modèle de données relationnel
Une base de données est organisée sous la forme d’une ou plusieurs tables (relation symbol)
L’en-tête détermine les noms de colonnes (noms d’attributs) et leur domaine de définition
Une table contient une collection de lignes
Ces lignes représentent les données (tuples)
Une ligne est elle-même une suite de valeurs, chacune d’un type déterminé. Par exemple
(BookID, ReaderID) : entier, ReturnDate : date
une ligne regroupe des informations concernant un objet, un individu, un événement ⇒ un
concept du monde réel, une entité

8/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Schéma de base de données

Schéma relationnel
Symbole de relation R
Ensemble d’attributs A1 , . . . , An
Ensemble de dépendances locales ΣR
R = ({A1 , . . . , An }, ΣR )

9/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Schéma de base de données

Schéma relationnel
Symbole de relation R
Ensemble d’attributs A1 , . . . , An
Ensemble de dépendances locales ΣR
R = ({A1 , . . . , An }, ΣR )
Schéma de base de données
Symbole de base de données D
Ensemble de schémas de relation R1 , . . . , Rm
Ensemble de dépendances globales Σ
D = ({R1 , . . . , Rm }, Σ)

9/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Schéma de base de données

Schéma relationnel
Symbole de relation R
Ensemble d’attributs A1 , . . . , An
Ensemble de dépendances locales ΣR
R = ({A1 , . . . , An }, ΣR )
Schéma de base de données
Symbole de base de données D
Ensemble de schémas de relation R1 , . . . , Rm
Ensemble de dépendances globales Σ
D = ({R1 , . . . , Rm }, Σ)
Exemple
Schéma de relation 1 : Book = ({BookID, Title}, ΣBook )
Schéma de relation 2 : BookLending = ({BookID, ReaderID, ReturnDate}, ΣBookLending )
Schéma de relation 3 : Reader = ({ReaderID, Name}, ΣReader )
Schéma de base de données : Library = ({Book, BookLending, Reader }, Σ)
9/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles
 Base de Données Relationnelles

Exemple de base de données : Library

10/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Dépendances ΣR et Σ
Dépendances nous aident à spécifier quelles données peuvent être correctement enregistrées dans le
système de base de données
Dépendances locales ΣR se réfèrent à une seule table
Exemple : dépendances fonctionnelles comme les dépendances des clés (identifiants)
BookID −→ Title

11/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Dépendances ΣR et Σ
Dépendances nous aident à spécifier quelles données peuvent être correctement enregistrées dans le
système de base de données
Dépendances locales ΣR se réfèrent à une seule table
Exemple : dépendances fonctionnelles comme les dépendances des clés (identifiants)
BookID −→ Title

Dépendances globales Σ entre les tables

Exemple : dépendance d’inclusion, le cas des clés étrangère
[Link] ⊆ [Link]
[Link] ⊆ Reader .ReaderID

11/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Exemple de base de données : Library

[Link] ⊆ [Link]
[Link] ⊆ Reader .ReaderID

12/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Transformation du modèle entité-association

Comment définir un schéma de base de données à partir d’un diagramme entité-association ?
Nom de l’entité −→ symbole de relation
Exemple : l’entité Book −→ symbole de relation Book

13/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Transformation du modèle entité-association

Comment définir un schéma de base de données à partir d’un diagramme entité-association ?
Nom de l’entité −→ symbole de relation
Exemple : l’entité Book −→ symbole de relation Book
Attributs d’entité −→ attributs de la relation
Exemple : les attributs BookID et title
Remarque : le modèle relationnel n’accepte pas les attributs composés ni les attributs
multivalués
Nouveau schéma de relation pour chaque attribut multivalués + une clé étrangère pour la
relier au schéma origine
Exemple d’attribut multivalué: Authors
BookAuthors({BookID, Author }, {BookID, Author } −→ {BookID, Author })
et la clé étrangère [Link] ⊆ [Link]
Attribut composé, par exemple "Publisher" sera enregistré comme une valeur singulière (city
and name)

13/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Transformation du modèle entité-association

Comment définir un schéma de base de données à partir d’un diagramme entité-association ?
Nom de l’entité −→ symbole de relation
Exemple : l’entité Book −→ symbole de relation Book
Attributs d’entité −→ attributs de la relation
Exemple : les attributs BookID et title
Remarque : le modèle relationnel n’accepte pas les attributs composés ni les attributs
multivalués
Nouveau schéma de relation pour chaque attribut multivalués + une clé étrangère pour la
relier au schéma origine
Exemple d’attribut multivalué: Authors
BookAuthors({BookID, Author }, {BookID, Author } −→ {BookID, Author })
et la clé étrangère [Link] ⊆ [Link]
Attribut composé, par exemple "Publisher" sera enregistré comme une valeur singulière (city
and name)
Relations dans le modèle entité-association ⇒ symboles de relation tout en ajoutant les dépendances
d’inclusion appropriées
13/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles
 Base de Données Relationnelles

Normalisation
La conception de base de données peut être problématique : table avec trop d’attributs, table contenant
des informations erronées, des données dupliquées

14/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Normalisation
La conception de base de données peut être problématique : table avec trop d’attributs, table contenant
des informations erronées, des données dupliquées
Problèmes lors de l’insertion, la suppression ou la mise à jour
Anomalie d’insertion : besoin de toutes les valeurs d’attributs avant l’insertion d’une ligne ou
tuple (dés fois certaines valeurs sont inconnues à ce moment)
Anomalie de suppression : lors de la suppression d’une ligne, certaines information seront
perdues alors qu’elles sont toujours utiles à la base
Anomalie de mise à jour : lorsqu’il y a redondance des données, la mise à jour des
informations (attributs) touchera plusieurs lignes et dés fois plusieurs tables

14/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Normalisation
La conception de base de données peut être problématique : table avec trop d’attributs, table contenant
des informations erronées, des données dupliquées
Problèmes lors de l’insertion, la suppression ou la mise à jour
Anomalie d’insertion : besoin de toutes les valeurs d’attributs avant l’insertion d’une ligne ou
tuple (dés fois certaines valeurs sont inconnues à ce moment)
Anomalie de suppression : lors de la suppression d’une ligne, certaines information seront
perdues alors qu’elles sont toujours utiles à la base
Anomalie de mise à jour : lorsqu’il y a redondance des données, la mise à jour des
informations (attributs) touchera plusieurs lignes et dés fois plusieurs tables
Normalisation assure une bonne répartition des attributs entre les tables
Normalisation nous aide à réduire les anomalies
Normalisation est souvent guidée par les dépendances fonctionnelles
quels attributs déterminent les valeurs d’autres attributs ?

14/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Formes Normales

Première Forme Normale (1FN)

Chaque attribut de la relation contient une valeur atomique
pas de d’attribut multivalué ni composé

15/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Formes Normales

Première Forme Normale (1FN)

Chaque attribut de la relation contient une valeur atomique
pas de d’attribut multivalué ni composé
Deuxième Forme Normale (2FN)
Chaque attribut non clé ne dépend pas d’une partie de la clé mais de toute la clé
Exemple : Pilot({PilotId, Name, Licence, Date}, {PilotID, Licence, Date} −→ {Name})
Pilot n’est pas 2FN
Pilot({PilotId, Name}, {PilotID} −→ {Name})
PilotLicence({PilotId, Licence, Date}, {PilotID, Licence, Date} −→ {PilotID, Licence, Date})

15/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Formes Normales

Première Forme Normale (1FN)

Chaque attribut de la relation contient une valeur atomique
pas de d’attribut multivalué ni composé
Deuxième Forme Normale (2FN)
Chaque attribut non clé ne dépend pas d’une partie de la clé mais de toute la clé
Exemple : Pilot({PilotId, Name, Licence, Date}, {PilotID, Licence, Date} −→ {Name})
Pilot n’est pas 2FN
Pilot({PilotId, Name}, {PilotID} −→ {Name})
PilotLicence({PilotId, Licence, Date}, {PilotID, Licence, Date} −→ {PilotID, Licence, Date})
Troisième Forme Normale (3FN)
tout attribut n’appartenant pas à une clé ne dépend pas d’un autre attribut non clé

15/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Exemple de normalisation
Avant la normalisation

Après normalisation

16/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Requête Relationnelle

Après l’enregistrement des données dans la base, comment les récupérer ?

Spécifier des conditions pour sélectionner les tuples pertinents
Combiner des valeurs à partir de plusieurs tables
Restreindre la sélection à un sous-ensemble d’attributs
Langages de requêtes pour récupérer les données à partir de la base
Calcul relationnel
Algèbre relationnel
SQL (Structured Query Language)

17/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Requête Relationnelle
Exemple de requête sur la relation BookLending

Langage naturel : "trouver les livres prétés et qui doivent être retournés avant le 29-10-2016"
Calcul Relationnel : formule logique avec les variables x , y , z
Q(x , y , z) = {(x , y , z)|BookLending(x , y , z) ∧ z < 29 − 10 − 2016}
Algèbre relationnel : soit l’opérateur de sélection σ
σReturnDate<29−10−2016 (BookLending)
Structured Query Language (SQL) :
SELECT BookID, ReaderID, ReturnDate FROM BookLending WHERE ReturnDate < 29-10-2016

18/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Opérateurs d’algèbre relationnel

Projection π (restriction sur un ensemble d’attributs)
ID des lecteurs (readers) ayant actuellement un empreint : πReaderID (BookLending)

19/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Opérateurs d’algèbre relationnel

Projection π (restriction sur un ensemble d’attributs)
ID des lecteurs (readers) ayant actuellement un empreint : πReaderID (BookLending)
Sélection σ (avec une condition)
Les livres qui doivent être retournés avant 29-10-2016 : σReturnDate<29−10−2016 (BookLending)

19/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Opérateurs d’algèbre relationnel

Projection π (restriction sur un ensemble d’attributs)
ID des lecteurs (readers) ayant actuellement un empreint : πReaderID (BookLending)
Sélection σ (avec une condition)
Les livres qui doivent être retournés avant 29-10-2016 : σReturnDate<29−10−2016 (BookLending)
Renommage ρ (nouveau nom pour l’attribut)
Renommer ReturnDate à DueDate : ρDueDate←−ReturnDate (BookLending)

19/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Opérateurs d’algèbre relationnel

Projection π (restriction sur un ensemble d’attributs)
ID des lecteurs (readers) ayant actuellement un empreint : πReaderID (BookLending)
Sélection σ (avec une condition)
Les livres qui doivent être retournés avant 29-10-2016 : σReturnDate<29−10−2016 (BookLending)
Renommage ρ (nouveau nom pour l’attribut)
Renommer ReturnDate à DueDate : ρDueDate←−ReturnDate (BookLending)
Union ∪, Différence −, Intersection ∩
Seulement entre tables ayant un schéma identique

19/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Opérateurs d’algèbre relationnel

Projection π (restriction sur un ensemble d’attributs)
ID des lecteurs (readers) ayant actuellement un empreint : πReaderID (BookLending)
Sélection σ (avec une condition)
Les livres qui doivent être retournés avant 29-10-2016 : σReturnDate<29−10−2016 (BookLending)
Renommage ρ (nouveau nom pour l’attribut)
Renommer ReturnDate à DueDate : ρDueDate←−ReturnDate (BookLending)
Union ∪, Différence −, Intersection ∩
Seulement entre tables ayant un schéma identique
Jointure Naturelle ./ (combine deux tables avec des attributs ayant le même nom)

Toute information sur les livres empruntés : Book ./ BookLending

Résultat sera une table avec les attributs BookId, Title, ReaderID, ReturnDate
Plus d’autres opérateurs avancés de jointure

19/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Arbre/Plan d’exécution
Opérateurs algébriques peuvent être représentés à l’aide d’une structure d’arbre
Illustrer l’ordre des évaluations
Ce qui est très utile lors de l’optimisation (résultat intermédiaire réduit avec peu de tuples et
d’attributs)
Exemple : sélectionner les noms des lecteurs qui doivent retourner un livre avant 29-10-2016
πName (σReturnDate<29−10−2016 )(Reader ./ BookLending)

20/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

SQL

21/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Transactions et gestion de la concurrence

Problèmes lors des opérations sur une base de données :

Intégrité logique des données : les valeurs enregistrées sont elles correctes ?
Intégrité physique des données et restauration : comment les données peuvent être restaurées
après un crach système ?
Multi-utilisateurs : comment gérer les accès concurrents et éliminer les interférences ?

22/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Transactions et gestion de la concurrence

Problèmes lors des opérations sur une base de données :

Intégrité logique des données : les valeurs enregistrées sont elles correctes ?
Intégrité physique des données et restauration : comment les données peuvent être restaurées
après un crach système ?
Multi-utilisateurs : comment gérer les accès concurrents et éliminer les interférences ?
Transaction est une séquence d’opérations de lecture et écriture sur la base de données
doit être traitée en entier et sans interruption
change l’état consistant de la base de données vers un nouveau état consistant

22/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Transactions et gestion de la concurrence

Problèmes lors des opérations sur une base de données :

Intégrité logique des données : les valeurs enregistrées sont elles correctes ?
Intégrité physique des données et restauration : comment les données peuvent être restaurées
après un crach système ?
Multi-utilisateurs : comment gérer les accès concurrents et éliminer les interférences ?
Transaction est une séquence d’opérations de lecture et écriture sur la base de données
doit être traitée en entier et sans interruption
change l’état consistant de la base de données vers un nouveau état consistant
Exemple d’un transfert bancaire : transférer un montant x à partir du compte K1 vers le compte K2 :
T : Read(K1 )Write(K 1 − x )Read(K2 )Write(K 2 + x )

22/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Propriétés ACID

Une transaction est une unité d’action qui doit respecter quatre critères, résumés par l’acronyme ACID

23/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Propriétés ACID

Une transaction est une unité d’action qui doit respecter quatre critères, résumés par l’acronyme ACID
Atomique : Une transaction représente une unité de travail qui est validée intégralement ou totalement
annulée.
C’est tout ou rien

23/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Propriétés ACID

Une transaction est une unité d’action qui doit respecter quatre critères, résumés par l’acronyme ACID
Atomique : Une transaction représente une unité de travail qui est validée intégralement ou totalement
annulée.
C’est tout ou rien
Cohérente : La transaction doit maintenir le système en cohérence par rapport à ses règles fonctionnelles.
Durant l’exécution de la transaction, le système peut être temporairement incohérent, mais lorsque la
transaction se termine, il doit être cohérent, soit dans un nouvel état si la transaction est validée, soit dans
l’état cohérent antérieur si la transaction est annulée.

23/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Propriétés ACID

Une transaction est une unité d’action qui doit respecter quatre critères, résumés par l’acronyme ACID
Atomique : Une transaction représente une unité de travail qui est validée intégralement ou totalement
annulée.
C’est tout ou rien
Cohérente : La transaction doit maintenir le système en cohérence par rapport à ses règles fonctionnelles.
Durant l’exécution de la transaction, le système peut être temporairement incohérent, mais lorsque la
transaction se termine, il doit être cohérent, soit dans un nouvel état si la transaction est validée, soit dans
l’état cohérent antérieur si la transaction est annulée.
Isolée : Comme la transaction met temporairement les données qu’elle manipule dans un état incohérent,
elle isole ces données des autres transactions de façon à ce qu’elles ne puissent pas lire des données en
cours de modification.

23/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Propriétés ACID

Une transaction est une unité d’action qui doit respecter quatre critères, résumés par l’acronyme ACID
Atomique : Une transaction représente une unité de travail qui est validée intégralement ou totalement
annulée.
C’est tout ou rien
Cohérente : La transaction doit maintenir le système en cohérence par rapport à ses règles fonctionnelles.
Durant l’exécution de la transaction, le système peut être temporairement incohérent, mais lorsque la
transaction se termine, il doit être cohérent, soit dans un nouvel état si la transaction est validée, soit dans
l’état cohérent antérieur si la transaction est annulée.
Isolée : Comme la transaction met temporairement les données qu’elle manipule dans un état incohérent,
elle isole ces données des autres transactions de façon à ce qu’elles ne puissent pas lire des données en
cours de modification.
Durable : Lorsque la transaction est validée, le nouvel état est durablement inscrit dans le système.
Cohérence peut aussi se dire consistance et qui est une notion très importante pour les bases de données
relationnelles

23/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Base de Données Relationnelles

Problèmes du modèle relationnel

Surcharge sémantique
Modèle relationnel représente les entités et les associations par des relations
Il est impossible de différencier les entités des associations à partir des schémas relationnels

Book = ({BookID, Title}, ΣBook )

BookLending = ({BookID, ReaderId, ReturnDate}, ΣBookLending )
Reader = ({ReaderID, Name}, ΣReader )
Schéma de base de données : Library = ({Book, BookLending, Reader }, Σ)
24/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles
 Base de Données Relationnelles

Problèmes du modèle relationnel

Structure de données homogène
Modèle relationnel admet l’homogénéité horizontale et verticale
Horizontale : tous les tuples possèdent les mêmes attributs
Verticale : les valeurs d’une colonne appartiennent au même domaine (même type)
Uniquement les valeurs atomique sont enregistrées dans les cellules des tables

Book = ({BookID, Title}, ΣBook )

BookLending = ({BookID, ReaderId, ReturnDate}, ΣBookLending )
Reader = ({ReaderID, Name}, ΣReader )
Schéma de base de données : Library = ({Book, BookLending, Reader }, Σ)
25/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles
 Nouveaux Besoins

Plan

1 Base de Données Relationnelles

2 Nouveaux Besoins

3 NOSQL

4 En quoi NOSQL est différent du modèle relationnel ?

26/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 Nouveaux Besoins

Nouveaux Besoins

Les données sont organisées à l’aide de structures complexes (exemple : les réseaux sociaux)
Les donnes changent fréquemment (mise à jour fréquente) ⇒ Variabilité
écriture1lecture1écriture2écriture3écriture4écriture5lecture2écriture6
Les données sont distribuées sur un nombre important de serveurs (exemple : cloud) ⇒ Scalabilité
Traitement de quantité importante de données ⇒ Volume
NOSQL ré-invente le modèle de données non-relationnelles pour les nouvelles applications et sur des
architectures matérielless modernes

27/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 NOSQL

Plan

1 Base de Données Relationnelles

2 Nouveaux Besoins

3 NOSQL

4 En quoi NOSQL est différent du modèle relationnel ?

28/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 NOSQL

Base de données NOSQL

NOSQL (Not Only SQL) concerne les systèmes de base de données qui :
se base sur un modèle de données non-relationnelles (différent du concept des tables relationnelles)
supporte des paradigmes d’accès ou des langages de requêtes différent de SQL (mais peut supporter aussi
SQL)
accepte l’évolution des schéma de données ou supporte les données peu ou pas du tout structurées
supporte la distribution de données sur un réseau de serveurs
ne respecte pas les propriétés ACID

29/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Plan

1 Base de Données Relationnelles

2 Nouveaux Besoins

3 NOSQL

4 En quoi NOSQL est différent du modèle relationnel ?

30/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Principes du relationnel vis-a-vis du NOSQL

Modèle relationnel
Les données sont représentées par un modèle mathématique dans le système informatique
Les tables de base de données relationnelles
Il y a une séparation totale entre l’organisation logique des données et l’implémentation physique du
moteur SGBD
Les données sont très structurées
⇒ les attributs sont fortement typés
⇒ on modélise la réalité pour la faire entrer dans ce modèle relativement contraignant
Avantage ⇒ appliquer des opérations algébriques et logiques sur les données
Inconvénient ⇒ forcer les données plus complexes à satisfaire une structure prédéfinie
Not Only SQL
NOSQL se base sur des expérimentations pratiques pour répondre à des besoins concrets
⇒ approche d’ingénierie

31/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Structure de données
Modèle relationnel
Structuration forte des données

32/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Structure de données
Modèle relationnel
Structuration forte des données
Représentation tabulaire : une suite de lignes et de colonnes
Sur la première ligne, on trouve les noms des colonnes
Une donnée atomique est stockée dans une cellule
Pour la retrouver, il suffit d’indiquer l’identifiant de la ligne et le nom de la colonne

32/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Structure de données
Modèle relationnel
Structuration forte des données
Représentation tabulaire : une suite de lignes et de colonnes
Sur la première ligne, on trouve les noms des colonnes
Une donnée atomique est stockée dans une cellule
Pour la retrouver, il suffit d’indiquer l’identifiant de la ligne et le nom de la colonne
NOSQL
Paires clé/valeur : l’accès à la donnée s’effectue exclusivement par sa clé

32/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Structure de données
Modèle relationnel
Structuration forte des données
Représentation tabulaire : une suite de lignes et de colonnes
Sur la première ligne, on trouve les noms des colonnes
Une donnée atomique est stockée dans une cellule
Pour la retrouver, il suffit d’indiquer l’identifiant de la ligne et le nom de la colonne
NOSQL
Paires clé/valeur : l’accès à la donnée s’effectue exclusivement par sa clé
⇒ point d’entrée unique ce qui améliore les performances
⇒ peut-import le type de donnée mais la donnée est atomique
⇒ les fonctionnalités sont basiques et donc facile à implémenter

32/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Structure de données
Modèle relationnel
Structuration forte des données
Représentation tabulaire : une suite de lignes et de colonnes
Sur la première ligne, on trouve les noms des colonnes
Une donnée atomique est stockée dans une cellule
Pour la retrouver, il suffit d’indiquer l’identifiant de la ligne et le nom de la colonne
NOSQL
Paires clé/valeur : l’accès à la donnée s’effectue exclusivement par sa clé
Orienté documents : toujours sur le principe clé/valeur mais les données stockées peuvent être plus
complexes communément appelé document

32/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Structure de données
Modèle relationnel
Structuration forte des données
Représentation tabulaire : une suite de lignes et de colonnes
Sur la première ligne, on trouve les noms des colonnes
Une donnée atomique est stockée dans une cellule
Pour la retrouver, il suffit d’indiquer l’identifiant de la ligne et le nom de la colonne
NOSQL
Paires clé/valeur : l’accès à la donnée s’effectue exclusivement par sa clé
Orienté documents : toujours sur le principe clé/valeur mais les données stockées peuvent être plus
complexes communément appelé document
⇒ un document comporte des types de données simples, mais aussi des listes et des paires clé/valeur
⇒ ce qui conduit à une forme hiérarchique
⇒ les données peuvent être structurées ou semi-structurées
⇒ les données sont stockées sous le format JSON

32/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Structure de données
Modèle relationnel
Structuration forte des données
Représentation tabulaire : une suite de lignes et de colonnes
Sur la première ligne, on trouve les noms des colonnes
Une donnée atomique est stockée dans une cellule
Pour la retrouver, il suffit d’indiquer l’identifiant de la ligne et le nom de la colonne
NOSQL
Paires clé/valeur : l’accès à la donnée s’effectue exclusivement par sa clé
Orienté documents : toujours sur le principe clé/valeur mais les données stockées peuvent être plus
complexes communément appelé document
Orienté colonnes : est la deuxième forme évoluée du modèle clé/valeur et similaire au modèle relationnel

32/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Structure de données
Modèle relationnel
Structuration forte des données
Représentation tabulaire : une suite de lignes et de colonnes
Sur la première ligne, on trouve les noms des colonnes
Une donnée atomique est stockée dans une cellule
Pour la retrouver, il suffit d’indiquer l’identifiant de la ligne et le nom de la colonne
NOSQL
Paires clé/valeur : l’accès à la donnée s’effectue exclusivement par sa clé
Orienté documents : toujours sur le principe clé/valeur mais les données stockées peuvent être plus
complexes communément appelé document
Orienté colonnes : est la deuxième forme évoluée du modèle clé/valeur et similaire au modèle relationnel
⇒ basé sur un schéma flexible (colonne non typées)
⇒ le nombre de colonnes varie pour chaque enregistrement
⇒ permet de gérer l’absence de certaines colonnes entre les différents enregistrement de la table

32/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Structure de données
Modèle relationnel
Structuration forte des données
Représentation tabulaire : une suite de lignes et de colonnes
Sur la première ligne, on trouve les noms des colonnes
Une donnée atomique est stockée dans une cellule
Pour la retrouver, il suffit d’indiquer l’identifiant de la ligne et le nom de la colonne
NOSQL
Paires clé/valeur : l’accès à la donnée s’effectue exclusivement par sa clé
Orienté documents : toujours sur le principe clé/valeur mais les données stockées peuvent être plus
complexes communément appelé document
Orienté colonnes : est la deuxième forme évoluée du modèle clé/valeur et similaire au modèle relationnel
Orienté graphes : est fondé sur la théorie des graphes

32/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Structure de données
Modèle relationnel
Structuration forte des données
Représentation tabulaire : une suite de lignes et de colonnes
Sur la première ligne, on trouve les noms des colonnes
Une donnée atomique est stockée dans une cellule
Pour la retrouver, il suffit d’indiquer l’identifiant de la ligne et le nom de la colonne
NOSQL
Paires clé/valeur : l’accès à la donnée s’effectue exclusivement par sa clé
Orienté documents : toujours sur le principe clé/valeur mais les données stockées peuvent être plus
complexes communément appelé document
Orienté colonnes : est la deuxième forme évoluée du modèle clé/valeur et similaire au modèle relationnel
Orienté graphes : est fondé sur la théorie des graphes
⇒ ce modèle repose sur trois notions : nœud, relation, et propriétés
⇒ les relations relient les nœuds et possèdent éventuellement des propriétés

32/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Agrégat et centralité de la donnée

Agrégat est une collection d’objets liés par une entité racine, nommée la racine de l’agrégat
Un agrégat n’est référencé que par sa racine

33/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Agrégat et centralité de la donnée

Agrégat est une collection d’objets liés par une entité racine, nommée la racine de l’agrégat
Un agrégat n’est référencé que par sa racine
NOSQL
Une base de données orientée documents stocke des données sous forme d’agrégats
Une clé unique identifie un document JSON qui contient un bloc d’information
Après le document est extrait du moteur pour pouvoir le manipuler
Ensuite, il est stocké dans sa totalité

33/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Agrégat et centralité de la donnée

Agrégat est une collection d’objets liés par une entité racine, nommée la racine de l’agrégat
Un agrégat n’est référencé que par sa racine
NOSQL
Une base de données orientée documents stocke des données sous forme d’agrégats
Une clé unique identifie un document JSON qui contient un bloc d’information
Après le document est extrait du moteur pour pouvoir le manipuler
Ensuite, il est stocké dans sa totalité
L’agrégat est stocké dans la structure de la base de données (document)
⇒ pas évident de satisfaire les besoins de plusieurs applications

33/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Agrégat et centralité de la donnée

Agrégat est une collection d’objets liés par une entité racine, nommée la racine de l’agrégat
Un agrégat n’est référencé que par sa racine
NOSQL
Une base de données orientée documents stocke des données sous forme d’agrégats
Une clé unique identifie un document JSON qui contient un bloc d’information
Après le document est extrait du moteur pour pouvoir le manipuler
Ensuite, il est stocké dans sa totalité
L’agrégat est stocké dans la structure de la base de données (document)
⇒ pas évident de satisfaire les besoins de plusieurs applications
Modèle relationnel
La structure des tables est à plat ⇒ pas de notion d’agrégat

33/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Agrégat et centralité de la donnée

Agrégat est une collection d’objets liés par une entité racine, nommée la racine de l’agrégat
Un agrégat n’est référencé que par sa racine
NOSQL
Une base de données orientée documents stocke des données sous forme d’agrégats
Une clé unique identifie un document JSON qui contient un bloc d’information
Après le document est extrait du moteur pour pouvoir le manipuler
Ensuite, il est stocké dans sa totalité
L’agrégat est stocké dans la structure de la base de données (document)
⇒ pas évident de satisfaire les besoins de plusieurs applications
Modèle relationnel
La structure des tables est à plat ⇒ pas de notion d’agrégat
L’agrégat est crée dynamiquement par l’exécution de requêtes de jointures sur les tables
Ce qui permet de répondre aux besoins de plusieurs applications à la fois
⇒ pour chaque application, on construit l’agrégat nécessaire

33/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Agrégat et centralité de la donnée

Agrégat est une collection d’objets liés par une entité racine, nommée la racine de l’agrégat
Un agrégat n’est référencé que par sa racine
NOSQL
Une base de données orientée documents stocke des données sous forme d’agrégats
Une clé unique identifie un document JSON qui contient un bloc d’information
Après le document est extrait du moteur pour pouvoir le manipuler
Ensuite, il est stocké dans sa totalité
L’agrégat est stocké dans la structure de la base de données (document)
⇒ pas évident de satisfaire les besoins de plusieurs applications
Modèle relationnel
La structure des tables est à plat ⇒ pas de notion d’agrégat
L’agrégat est crée dynamiquement par l’exécution de requêtes de jointures sur les tables
Ce qui permet de répondre aux besoins de plusieurs applications à la fois
⇒ pour chaque application, on construit l’agrégat nécessaire
⇒ centralité de la donnée (converger plusieurs applications vers un seul point)
33/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles
 En quoi NOSQL est différent du modèle relationnel ?

Modélisation et partitionnement des données

Créer le modèle d’une base de données relationnelle est la première étape du développement
Modéliser les données sous forme de tables reliées entre elles par des relations sur des clés
⇒ la qualité du système dépend de la modélisation

34/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Modélisation et partitionnement des données

Créer le modèle d’une base de données relationnelle est la première étape du développement
Modéliser les données sous forme de tables reliées entre elles par des relations sur des clés
⇒ la qualité du système dépend de la modélisation
Le modèle relationnel est relativement rigide par rapport au NOSQL
⇒ ajouter une colonne à une table n’est pas très difficile et l’impact sur l’application client est quasi-null

34/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Modélisation et partitionnement des données

Créer le modèle d’une base de données relationnelle est la première étape du développement
Modéliser les données sous forme de tables reliées entre elles par des relations sur des clés
⇒ la qualité du système dépend de la modélisation
Le modèle relationnel est relativement rigide par rapport au NOSQL
⇒ ajouter une colonne à une table n’est pas très difficile et l’impact sur l’application client est quasi-null
La modification d’un modèle relationnel est coûteuse, mais changer des données stockées dans une base
NoSQL ne l’est pas forcément moins

34/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Modélisation et partitionnement des données

Créer le modèle d’une base de données relationnelle est la première étape du développement
Modéliser les données sous forme de tables reliées entre elles par des relations sur des clés
⇒ la qualité du système dépend de la modélisation
Le modèle relationnel est relativement rigide par rapport au NOSQL
⇒ ajouter une colonne à une table n’est pas très difficile et l’impact sur l’application client est quasi-null
La modification d’un modèle relationnel est coûteuse, mais changer des données stockées dans une base
NoSQL ne l’est pas forcément moins
La plupart des moteurs de bases de données NoSQL appliquent un modèle sans schéma (schema-less)
⇒ le schéma des données n’a pas vraiment besoin d’être fixé à l’avance.

34/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Modélisation et partitionnement des données

Créer le modèle d’une base de données relationnelle est la première étape du développement
Modéliser les données sous forme de tables reliées entre elles par des relations sur des clés
⇒ la qualité du système dépend de la modélisation
Le modèle relationnel est relativement rigide par rapport au NOSQL
⇒ ajouter une colonne à une table n’est pas très difficile et l’impact sur l’application client est quasi-null
La modification d’un modèle relationnel est coûteuse, mais changer des données stockées dans une base
NoSQL ne l’est pas forcément moins
La plupart des moteurs de bases de données NoSQL appliquent un modèle sans schéma (schema-less)
⇒ le schéma des données n’a pas vraiment besoin d’être fixé à l’avance.
Partitionner une base relationnelle est très difficile si les tables sont reliées entre elles
⇒ par exemple tables clients, commandes, et produits
Il est plus simple de distribuer des données non liées ⇒ NOSQL

34/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Langage SQL

SQL est un langage d’extraction de données conçu pour le modèle relationnel

SQL n’est pas le modèle relationnel
Le paradigme NOSQL ne s’oppose pas au langage SQL
Pourquoi alors dans le monde NOSQL on s’éloigne du langage SQL ?
L’écriture d’une requête SQL demande plus de réflexion que de la programmation
Défaut d’impédance objet-relationnel
Le défaut d’impédance est la résistance qu’on rencontre lors du passage du relationnel à l’objet
Les technologies NOSQL évoluent rapidement et notamment au niveau du langage de requête
⇒ Cassandra Query Language (CQL) qui a une syntaxe similaire à celle de SQL

35/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

NULL

Un moteur relationnel doit indiquer l’absence de valeur d’une cellule

36/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

NULL

Un moteur relationnel doit indiquer l’absence de valeur d’une cellule

Ceci est réalisé grâce au marqueur NULL qui signifie valeur inconnue

36/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

NULL

Un moteur relationnel doit indiquer l’absence de valeur d’une cellule

Ceci est réalisé grâce au marqueur NULL qui signifie valeur inconnue
Ce marqueur NULL coûte un petit peu en stockage
⇒ laisser une chaîne vide n’indique pas une absence de valeur
⇒ d’où l’importance de NULL

36/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

NULL

Un moteur relationnel doit indiquer l’absence de valeur d’une cellule

Ceci est réalisé grâce au marqueur NULL qui signifie valeur inconnue
Ce marqueur NULL coûte un petit peu en stockage
⇒ laisser une chaîne vide n’indique pas une absence de valeur
⇒ d’où l’importance de NULL
Sa gestion est compliquée dans le langage SQL
⇒ NULL n’est pas une valeur et donc ne peut pas être comparé (clause WHERE)
⇒ il impose une gestion logique à trois états : vrai, faux, et inconnu

36/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

NULL

Un moteur relationnel doit indiquer l’absence de valeur d’une cellule

Ceci est réalisé grâce au marqueur NULL qui signifie valeur inconnue
Ce marqueur NULL coûte un petit peu en stockage
⇒ laisser une chaîne vide n’indique pas une absence de valeur
⇒ d’où l’importance de NULL
Sa gestion est compliquée dans le langage SQL
⇒ NULL n’est pas une valeur et donc ne peut pas être comparé (clause WHERE)
⇒ il impose une gestion logique à trois états : vrai, faux, et inconnu
Les moteurs NOSQL apportent de la souplesse
⇒ il n’est pas nécessaire d’ajouter un attribut pour dire qu’il est inconnu

36/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

NULL

Un moteur relationnel doit indiquer l’absence de valeur d’une cellule

Ceci est réalisé grâce au marqueur NULL qui signifie valeur inconnue
Ce marqueur NULL coûte un petit peu en stockage
⇒ laisser une chaîne vide n’indique pas une absence de valeur
⇒ d’où l’importance de NULL
Sa gestion est compliquée dans le langage SQL
⇒ NULL n’est pas une valeur et donc ne peut pas être comparé (clause WHERE)
⇒ il impose une gestion logique à trois états : vrai, faux, et inconnu
Les moteurs NOSQL apportent de la souplesse
⇒ il n’est pas nécessaire d’ajouter un attribut pour dire qu’il est inconnu
L’absence de relation entre les tables entraîne en général beaucoup de redondance de données et donc,
NULL ou pas NULL, les moteurs NoSQL occupent beaucoup plus d’espace de stockage qu’un SGBDR au
modèle correctement normalisé.
⇒ Il s’agit donc plus d’un gain en clarté pour la programmation qu’en stockage

36/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Théorème CAP (Eric Brewer 2000)

Dans un système distribué, répartir le calcul n’est particulièrement difficile à mettre en œuvre
Ce qui est difficile, c’est la distribution des données

37/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Théorème CAP (Eric Brewer 2000)

Dans un système distribué, répartir le calcul n’est particulièrement difficile à mettre en œuvre
Ce qui est difficile, c’est la distribution des données
Il est impossible pour une base de données distribuée de garantir ces trois contraintes suivantes :
Le système répond de façon performante en plus d’être tolérant aux pannes
Rien ne garantit la consistance des données entre les nœuds
⇒ C’est-à-dire qu’une lecture faite après une écriture doit renvoyer la donnée précédemment
écrite

37/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Théorème CAP (Eric Brewer 2000)

Dans un système distribué, répartir le calcul n’est particulièrement difficile à mettre en œuvre
Ce qui est difficile, c’est la distribution des données
Il est impossible pour une base de données distribuée de garantir ces trois contraintes suivantes :
Le système répond de façon performante en plus d’être tolérant aux pannes
Rien ne garantit la consistance des données entre les nœuds
⇒ C’est-à-dire qu’une lecture faite après une écriture doit renvoyer la donnée précédemment
écrite
Availability (disponibilité) : toute requête reçoit une réponse même si elle n’est pas à jour
(cohérente ou consistante)

37/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Théorème CAP (Eric Brewer 2000)

Dans un système distribué, répartir le calcul n’est particulièrement difficile à mettre en œuvre
Ce qui est difficile, c’est la distribution des données
Il est impossible pour une base de données distribuée de garantir ces trois contraintes suivantes :
Le système répond de façon performante en plus d’être tolérant aux pannes
Rien ne garantit la consistance des données entre les nœuds
⇒ C’est-à-dire qu’une lecture faite après une écriture doit renvoyer la donnée précédemment
écrite
Availability (disponibilité) : toute requête reçoit une réponse même si elle n’est pas à jour
(cohérente ou consistante)
Partition tolerance (tolérance au partitionnement) : le système doit répondre aux requêtes
dans toutes circonstances
⇒ le système distribué doit pouvoir survivre aux difficultés réseaux
⇒ perte de communication entre les partitions

37/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Théorème CAP (Eric Brewer 2000)

Quand on parle de NOSQL ⇒ tolérance au partitionnement

Le système répond de façon performante en plus d’être tolérant aux pannes réseaux (perte de paquets,
latence, perte de connexion, etc.)
Rien ne garantit la consistance des données entre les nœuds
38/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles
 En quoi NOSQL est différent du modèle relationnel ?

Théorème CAP (Eric Brewer 2000)

Quand on parle de NOSQL ⇒ tolérance au partitionnement

Les données sont consistantes entre tous les nœuds et le système est tolérant au partitionnement (latence,
problème de communication, etc.)
Rien ne garantit sa disponibilité
39/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles
 En quoi NOSQL est différent du modèle relationnel ?

Théorème CAP (Eric Brewer 2000)

Les données sont consistantes entre tous les nœuds et disponibles

Si un problème de réseau apparait alors on est obligé d’abandonner la consistance ou bien la disponibilité
Si la base de données n’est pas distribuée alors on aura un système CA (SGBDR)

40/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Propriétés BASE

Les bases de données NOSQL ne répondent pas aux propriétés ACID mais aux propriétés BASE

Basically Available (disponibilité basique) : même en cas de désynchronisation ou de panne

d’un des nœuds du cluster, le système reste disponible.
Soft-state (cohérence légère) : L’état du système peut se changer lors des mises à jour, la
base n’est pas forcement cohérente.
Eventually consistent (cohérence finale) : la cohérence des données n’est pas assurée
immédiatement, mais elle arrivera avec le temps.

41/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Propriétés BASE

Les bases de données NOSQL ne répondent pas aux propriétés ACID mais aux propriétés BASE

Basically Available (disponibilité basique) : même en cas de désynchronisation ou de panne

d’un des nœuds du cluster, le système reste disponible.
Soft-state (cohérence légère) : L’état du système peut se changer lors des mises à jour, la
base n’est pas forcement cohérente.
Eventually consistent (cohérence finale) : la cohérence des données n’est pas assurée
immédiatement, mais elle arrivera avec le temps.
ACID garantit la cohérence (consistance) des données à tout instant
BASE garantit la cohérence (consistance) des données dans le temps
C’est-à-dire qu’une base de données deviendra consistance après un certain moment, le temps que
l’information se propage entre les différents nœuds

41/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles

 En quoi NOSQL est différent du modèle relationnel ?

Merci pour votre attention! Des Questions?

42/42 Mohammed Boumediene - INTTIC Bases de Données Non Relationnelles