Not Only Sql

I. Modèle relationnel : limitations :

1. Le modèle relationnel :
Créé par Edgar F. Codd en 1970, organise les données en tables (relations), basées sur la
théorie des ensembles et l’algèbre relationnelle. Garantissant une gestion efficace et
cohérente.

Il repose sur 4 notions clés :

 Relations : tables
 Attributs : colonnes
 Tuples : lignes
 Schéma relationnel : structure des tables

Il est à la base des SGBD comme MySQL, PostgreSQL, Oracle ou SQL Server.

2. SQL (Structured Query Language) :

Est un langage de requête standardisé pour interagir avec les bases de données relationnelles.

Les données sont représentées par des listes de n-uplets (lignes de table).

Il permet d’effectuer des opérations puissantes :

 Sélection : WHERE → filtre les lignes

 Projection : SELECT → choisit les colonnes
 Jointure : JOIN → combine plusieurs tables
 Union : UNION → fusionne deux résultats
 Intersection : (pas toujours en SQL standard, mais faisable)
 Différence : EXCEPT (ou MINUS selon le SGBD)

3. transactions ACID :

Transaction : Une suite d’opérations (lecture, écriture…) traitée comme une unité logique
indivisible.

Pour garantir la fiabilité, une transaction doit respecter les propriétés ACID :
  Atomicité (A) : Une transaction est indivisible : soit toutes ses opérations sont
exécutées, soit aucune. En cas d'échec (erreur, crash), un rollback annule toutes les
modifications.
 Cohérence (C) : Une transaction fait passer la base d'un état valide à un autre état
valide. Les contraintes d'intégrité (clés primaires, clés étrangères, règles métier) doivent
être respectées.
 Isolation (I) : Les transactions s'exécutent comme si elles étaient seules, même en
concurrence. Empêche les interférences (lectures sales, modifications perdues).
 Durabilité (D) : Une fois validée (commit), une transaction est définitive, même en cas
de crash système. Les modifications sont écrites sur un support persistant (disque,
journal de transactions).

Importance : Essentiel dans les domaines critiques comme les banques, e-commerce ou
systèmes médicaux. Pour assurer intégrité des donnes et cohérence.

4. Bases de Données Relationnelles : Caractéristiques :

📌 Modèle

 Basé sur le modèle Entité-Relation

 Simple à concevoir
 Universel et largement adopté

📌 Requêtes

 Langage SQL
 Très puissant pour manipuler les données

📌 Transactions

 Respect du modèle ACID : Atomicité, Cohérence, Isolation, Durabilité

📌 Utilisation / Disponibilité

 Massivement utilisé dans tous les domaines

 Nombreux moteurs disponibles (MySQL, PostgreSQL, Oracle…)
 Large gamme d’outils d’exploitation

Malgré ces avantages, ce modèle montre ses limites face à l’explosion des volumes de
données, souvent massives, variées et en évolution rapide.
 5. Scalabilité : Verticale VS Horizontale :

Scalabilité verticale : Ajouter plus de puissance à un seul serveur (CPU, RAM...).

 Simple à mettre en place

 Coût élevé, limites physiques vite atteintes
 Point de défaillance unique

Scalabilité horizontale : Ajouter plusieurs serveurs standards.

 Plus de capacité, tolérance aux pannes

 Complexe à gérer (architecture distribuée, stockage, synchronisation)

🔼 Montée verticale (scale-up) :

 Ajouter CPU/RAM/stockage à un seul serveur.

 ✅ Facile à mettre en œuvre.
 ❌ Coût élevé et non linéaire.
 ❌ Limite physique atteinte rapidement.
 ❌ Point de défaillance unique (SPOF).

🔁 Montée horizontale (scale-out) :

 Ajouter plusieurs serveurs pour répartir la charge.

 ❌ Complexe avec un SGBDR à cause :
o Des règles d’intégrité référentielles.
o De la cohérence forte des données.
 Nécessite des solutions spécifiques (sharding, réplication, proxy SQL…).
 6. Coût des transactions ACID (dans un SGBDR) :
Lecture :

 Éparpillée et coûteuse en IO :
o Ex. : lecture d’un panier avec N articles = 2 IO pour le panier + N+1 IO pour les
articles.
 Lecture complexe ➜ exécution non déterministe :
o Ex. : SELECT * FROM t WHERE id = ? → rapide
SELECT * FROM t WHERE date < (SELECT MAX(date)...) → difficile à
estimer.

Écriture :

 Lente car :
o Transactions nécessitent des IO synchrones pour garantir les propriétés ACID
(surtout Durability et Consistency).

7. Limites des SGBD relationnels classiques :

Limites des SGBD classiques (relationnels) :

 Pas adaptés aux très gros volumes et à la distribution des données (Google, Amazon,
etc.).
 Basés sur SQL et ACID → efficaces mais rigides.
 Difficiles à scaler horizontalement.
 Maintien de l’ACID coûteux en environnement distribué.
 Gèrent mal les données complexes et hétérogènes.

II. NO SQL :

1. NoSQL : Définition et intérêt :

NoSQL (Not Only SQL) désigne une famille de bases de données conçues pour gérer des
données non structurées, massives et distribuées, contrairement aux bases relationnelles
classiques (SQL).

2. Caractéristiques principales :

 Modèles de données variés : documents, clé-valeur, graphes, colonnes.

 Pas de schéma rigide : structure souple et évolutive.

 Scalabilité horizontale : distribution facile sur plusieurs serveurs.

 Haute performance : adapté aux applications modernes et temps réel.

3. Pourquoi utiliser NoSQL ?

 Pour gérer des volumes massifs, des formats hétérogènes (JSON, XML...) et des vites
écritures/lectures.

 Idéal pour le Big Data, les réseaux sociaux, l’IoT, les logs, etc.

 Complète les limites des bases relationnelles, notamment en termes de scalabilité et de

flexibilité.

4. Définition du Théorème CAP :

Le théorème CAP, formulé par Eric Brewer en 2000 et démontré formellement en 2002, est
un principe fondamental des systèmes de bases de données distribués. Il affirme qu’il est
impossible pour un système distribué de garantir simultanément les trois propriétés
suivantes :

 Cohérence (Consistency)

Tous les nœuds du système voient exactement la même donnée à un instant donné.
Ex. : Si un client écrit une nouvelle valeur, tous les autres clients lisent immédiatement cette
nouvelle valeur.

 Disponibilité (Availability)

Chaque requête reçoit une réponse (succès ou échec) dans un délai raisonnable, même en cas
de panne partielle.
Le système ne reste jamais silencieux.

 Tolérance au partitionnement (Partition Tolerance)

Le système continue à fonctionner correctement même si une partition réseau (coupure de

communication entre nœuds) survient.

On ne peut en avoir que deux sur trois dans un système distribué en cas de partition du réseau.

5. Les 3 combinaisons possibles :

CA (Cohérence + Disponibilité)

 Pas tolérant aux partitions

  Données cohérentes et accessibles tant que le réseau est sain
 Ex. : MySQL, PostgreSQL (non distribués)
 Si partition réseau : refus des requêtes pour garder la cohérence

CP (Cohérence + Partition Tolerance)

 Moins disponible (réponses bloquées en cas de partition)

 Données toujours cohérentes même en cas de panne
 Ex. : MongoDB (répliqué), Redis, HBase
 Écritures bloquées pour éviter les conflits

AP (Disponibilité + Partition Tolerance)

 Cohérence éventuelle (pas immédiate)

 Système toujours accessible même en cas de panne réseau
 Ex. : Cassandra, DynamoDB, CouchDB
 Des divergences temporaires peuvent apparaître (résolues ensuite)

6. Théorème CAP – Exemples simplifiés :

Illustration 1 : Lecture/écriture sur deux nœuds :

 Un utilisateur écrit sur un nœud, un autre lit sur un autre.

 Pour garantir la cohérence, il faut attendre la synchro → Disponibilité impactée.

Modèle Comportement
CA L’écriture échoue si perte réseau
CP Requête bloquée jusqu’à synchro
AP Écriture validée mais état incohérent

Illustration 2 : Deux bases en data-centers séparés :

 Une panne réseau coupe la synchro entre deux bases.

 Si on autorise les écritures : état incohérent
 Si on les bloque : disponibilité perdue

Exemple bancaire :

 Retrait à Casablanca → doit être visible à Tanger immédiatement.

 Choix :
o Cohérence (CP) = ❌ pas de dispo pendant la panne
o Disponibilité (AP) = ❗ risques d’erreurs de solde

7. SGBD NoSQL : Modèle Clé-Valeur :

Définition

 Structure simple : un tableau associatif (clé → valeur)

 Chaque donnée est identifiée uniquement par une clé unique
 Tri des clés souvent lexicographique
 Suivent généralement les propriétés CA du théorème CAP (cohérence + disponibilité)

Opérations CRUD

 create(clé, valeur) → ajoute un couple

 read(clé) → récupère la valeur associée
 update(clé, valeur) → modifie la valeur
 delete(clé) → supprime le couple

Cas d’utilisation

 Stockage simple et rapide :

o Sessions web
o Caches
o Logs
o Données de capteurs
o Paniers d’achat
o Profils utilisateurs
o Paramètres uniques (ex : couleur par défaut)

Exemples de SGBD Clé-Valeur

 Redis (VMWare)
 Amazon Dynamo / Riak (open source)
 Voldemort (LinkedIn)
 Oracle NoSQL Database

Types de données prises en charge

 Valeurs : String, Objet, BLOB, etc.

 Clés : peuvent référencer Hashes, Lists, Sets, Sorted Sets (ex : Redis)

8. SGBD NoSQL : Modèle Orienté Colonnes :

Définition

 Données stockées par colonnes plutôt que par lignes (comme dans les SGBDR).
 Évolution du modèle clé-valeur, où :
 o Colonne = (clé, valeur, horodatage)
o Super-colonne = groupe de colonnes
o Famille de colonnes = ensemble de colonnes/super-colonnes, organisées par
ligne (clé unique)

Colonnes dynamiques : une ligne peut avoir un nombre variable de colonnes (pas de NULL
inutiles).

Accès très rapide aux données ciblées d’une colonne → idéal pour les requêtes analytiques.

Opérations

 Requêtes dépendantes de l’organisation des colonnes

 Lecture/écriture efficaces si le modèle est bien structuré à l'avance

Cas d’utilisation

 OLAP, data mining, data warehouses

 Données semi-structurées ou massives
 Journalisation, génomique, analyse comportementale
 📌 Exemples réels :
o Netflix : logging & analyse client
o eBay : moteur de recherche optimisé
o Adobe : BI & analyse structurée
o Chaînes TV : votes spectateurs & audience

Exemples de logiciels

 BigTable (Google)
 HBase (Apache)
 Cassandra (Apache)
 SimpleDB (Amazon)

9. Les SGBD NoSql : Orientés Documents :

Définition

 Base = collection de documents

 Évolution du modèle clé-valeur → ici, la valeur est un document (JSON, XML,
YAML, BSON…)
 Chaque document = ensemble hiérarchique de paires (clé, valeur)
➤ Peut contenir des objets imbriqués, des listes, etc.

Sans schéma fixe : chaque document peut avoir une structure différente
Très flexible et facile à faire évoluer
Permet d'accéder rapidement à une structure complexe via une seule clé
Ce qui nécessiterait plusieurs jointures en base relationnelle

Opérations

 CRUD complet (create, read, update, delete)

 Accès via REST API (HTTP)
 Requêtage possible sur le contenu interne des documents (filtres, recherches,
agrégations…)

Cas d’utilisation

 CMS (gestion de contenu)

 Catalogues produits
 Web analytics
 Données semi-structurées
 Profils utilisateurs
 Stockage d’événements / logs
 Systèmes embarqués ou d'exploitation

Exemples de logiciels

 MongoDB
 CouchDB
 RavenDB
 Terrastore

8. Modèle Graphe :

Définition

 Données modélisées sous forme de graphe orienté :

o Nœuds = entités (ex. : personne, entreprise)
o Arcs (liens) = relations entre entités

Idéal pour les données très liées

Accès ultra rapide même avec un grand nombre de connexions (le coût d’un hop reste
constant)

🔹 Basé sur la théorie des graphes

🔹 Permet de gérer des relations complexes, dynamiques ou multiples

Opérations

 Langages spécialisés :
 o SPARQL (pour graphes RDF)
o APIs ou langages de requêtes spécifiques aux graphes (ex. : Cypher pour
Neo4J)

Cas d’utilisation

 Réseaux sociaux
 Recommandation (films, produits…)
 Web sémantique / Open data
 Internet des objets (IoT)
 Bioinformatique, sciences de la vie
 Transport / Routage / Livraison
 Systèmes financiers (risques, fraudes…)
 Données hiérarchiques (catalogues, généalogie…)

Exemples de logiciels

 Neo4J
 OrientDB
 Titan