11-06 matin Cours : Bases de Données - Conception, Modélisation et Technologies Modernes

Bases de Données : Conception, Modélisation et Technologies Modernes

Introduction : L'Évolution des Systèmes de Gestion de Données

Les bases de données constituent l'épine dorsale des systèmes d'information modernes, servant de fondement à pratiquement toutes les applications informatiques contemporaines. L'évolution technologique récente a considérablement élargi le spectre des solutions disponibles, allant des bases de données relationnelles traditionnelles aux systèmes NoSQL spécialisés, en passant par les architectures distribuées à grande échelle.
Cette diversification répond à des besoins croissants de scalabilité, de flexibilité et de performance dans un contexte où les volumes de données atteignent des proportions sans précédent. Comprendre ces technologies, leurs forces et leurs limitations devient essentiel pour tout professionnel de l'informatique moderne.

Chapitre 1 : Types de Données et Optimisation

1.1 Fondements de l'Encodage des Données

L'encodage des données représente le processus critique de conversion d'informations compréhensibles par l'humain vers un format manipulable par les systèmes informatiques. Cette transformation doit prendre en compte non seulement la partie entièredes valeurs numériques, mais également leur partie fractionnaire, particulièrement cruciale dans certains domaines d'application.
Domaines critiques pour la précision :

Applications financières: où chaque décimale peut représenter des montants considérables
Calculs scientifiques: nécessitant une précision maximale pour éviter les erreurs de propagation
Applications temps réel: où la vitesse de traitement est critique mais ne doit pas compromettre l'exactitude

1.2 Stratégies d'Optimisation des Types Numériques

Le dimensionnement approprié des types de données constitue un enjeu majeur d'optimisation. Le principe fondamental consiste à adapter la taille du type aux besoins réelsde l'application, évitant ainsi le gaspillage de ressources.
Tailles standard et leurs plages :

8 bits: 0 à 255 (unsigned) ou -128 à 127 (signed)
16 bits: 0 à 65 535 (unsigned) ou -32 768 à 32 767 (signed)
32 bits: 0 à 4 294 967 295 (unsigned)
64 bits: plage considérablement élargie pour les très grandes valeurs
Cas d'application concret : Base Interpol
Un exemple emblématique illustre ces enjeux : le développement d'une base de données pour Interpol destinée à stocker les passeports volés, plaques d'immatriculation et personnes recherchées. Cette base devait être répliquée sur des postes portables déployés dans les forces de police mondiales, avec des contraintes particulières :
Fonctionnement hors ligne: autonomie complète nécessaire
Synchronisation limitée: mise à jour quotidienne ou hebdomadaire
Connexions dégradées: débit faible, taux de perte de paquets élevé
Intégrité critique: gestion des checksums et retry
Dans ce contexte, chaque octet économisé réduisait le temps de transfert, améliorait la fiabilité de synchronisation et diminuait les coûts de communication satellitaire.

1.3 Types de Données Textuelles : CHAR versus VARCHAR

La gestion des chaînes de caractères implique un choix stratégique entre deux approches fondamentalement différentes :
Type CHAR (taille fixe) :

Réserve toujours le même espace disque
Performance prévisible grâce à l'accès direct par offset
Risque de gaspillage si la chaîne est plus courte que l'espace alloué
Type VARCHAR (taille variable) :
Adapte l'espace à la longueur réelle du contenu
Optimise l'utilisation de l'espace disque
Nécessite un overhead de gestion pour stocker la longueur réelle
Stratégies de choix :
Utiliser CHAR lorsque :
Les données ont toujours la même longueur (codes pays, identifiants fixes)
Les performances d'accès sont prioritaires
Le volume de données est relativement faible
Utiliser VARCHAR lorsque :
Les données ont des longueurs très variables
L'économie d'espace est prioritaire
Le volume total est important (contexte Big Data)

Chapitre 2 : Systèmes de Clés et Relations

2.1 Concept Fondamental des Clés

Une clé en base de données fonctionne conceptuellement comme une clé physique : elle permet d'accéder de manière unique à une ressource spécifique. Dans le contexte des bases de données, elle garantit l'identification univoque d'un enregistrement parmi potentiellement des millions d'autres.

2.2 Clés Primaires : Identification et Évolution

La clé primaire constitue l'identifiant unique de chaque enregistrement dans une table, devant respecter deux contraintes fondamentales :

Unicité : aucune duplication possible
Non-nullité : toujours présente et définie
Types de clés primaires :
Clés naturelles : basées sur les attributs métier existants (numéro de sécurité sociale, email unique)
Clés artificielles (surrogate keys) : identifiants techniques générés spécifiquement pour l'identification, offrant l'avantage d'être indépendants des données métier mais impliquant des données supplémentaires sans valeur métier directe.

2.3 Évolution vers les Systèmes Distribués

L'approche traditionnelle d'auto-incrémentation (ID : 1, 2, 3, 4..) présente des limitations majeures dans les systèmes distribués :

Problèmes de scalabilité sur systèmes distribués
Conflits de synchronisation entre serveurs multiples
Goulots d'étranglement dans les architectures parallèles
Solutions modernes :
UUID (Universally Unique Identifier) : identifiants de 128 bits garantissant l'unicité globale
GUID (Globally Unique Identifier) : basés sur des algorithmes cryptographiques et temporels
Stratégies de partitionnement : nombres pairs/impairs par serveur, préfixes géographiques
Ces approches éliminent les collisions et permettent une génération locale sur chaque nœud sans synchronisation.

2.4 Clés Étrangères et Intégrité Référentielle

Les clés étrangères établissent les liens entre tables, formant l'architecture relationnelle. Contrairement aux clés primaires, elles peuvent apparaître plusieurs fois dans une table et référencent obligatoirement la clé primaire d'une autre table.
Problématique des clés métier :
Les clés métier possèdent souvent une signification fonctionnelle qui peut évoluer. Par exemple, dans un système RH :

Matricules commençant par 8 : cadres
Matricules commençant par 2 : ETAM (Employés, Techniciens et Agents de Maîtrise)
Matricules commençant par 1 : externes
Le problème majeur réside dans leur mutabilité : lorsqu'un employé change de statut, son matricule doit évoluer, nécessitant des modifications complexes dans toutes les tables liées.
Solution : clés de substitution
Les clés techniques résolvent cette problématique en étant :
Artificielles sans signification métier
Immuables une fois attribuées
Compatibles avec l'existence simultanée de clés secondaires uniques pour les besoins métier

2.5 Contraintes d'Intégrité Référentielle

La déclaration explicite des contraintes lors de la création des tables est essentielle. SQL propose plusieurs options via la clause ON DELETE :
RESTRICT (comportement par défaut) : empêche la suppression tant qu'une référence existe
SET NULL : remplace automatiquement la référence par NULL lors de la suppression
CASCADE : supprime automatiquement tous les enregistrements référençant l'élément supprimé
Ces contraintes offrent une protection automatique par le SGBD et constituent une documentation vivante des relations entre entités.

Chapitre 3 : Transactions et Propriétés ACID

3.1 Contexte Historique et Enjeux

Les systèmes de gestion de bases de données relationnelles ont émergé dans le secteur bancaire, où la gestion simultanée de milliers de transferts d'argent nécessitait des garanties de cohérence absolues. Cette origine explique l'importance accordée aux propriétés transactionnelles.
Exemple illustratif : transfert bancaire
Un transfert de 1000€ implique :

Débiter 1000€ du compte source
Créditer 1000€ sur le compte destination
Les problèmes de concurrence peuvent provoquer :

Panne système : argent disparu ou dupliqué si interruption entre les deux opérations
Accès concurrent : lecture simultanée du même solde par deux transactions, causant des pertes

3.2 Propriétés ACID Détaillées

A - Atomicité

Principe "tout ou rien": une transaction est indivisible. Soit toutes les opérations réussissent, soit aucune n'est appliquée. En cas d'échec partiel, le système effectue un rollback automatique.

C - Cohérence

La base doit respecter toutes les règles de cohérence définies avant et après chaque transaction. En environnement distribué, cette propriété devient particulièrement complexe car elle doit considérer l'ensemble du système, non chaque nœud isolément.
Problématique distribuée : Si deux serveurs (Paris et Lyon) tentent simultanément de débiter 10 000€ d'un compte contenant exactement cette somme, chaque serveur peut valider individuellement l'opération, résultant en un solde final de -10 000€.

I - Isolation

Les transactions concurrentes ne doivent pas interférer entre elles. Cette propriété présente un dilemme entre performance et exactitude, résolu par différents niveaux d'isolation :
Niveaux d'isolation (du plus strict au plus permissif) :

Serializable : isolation maximale, performance minimale
Repeatable Read : lectures cohérentes dans une transaction
Read Committed : lecture des données committées uniquement
Read Uncommitted : performance maximale, risques de dirty reads

D - Durabilité

Une fois validée (commit), une transaction doit persister même en cas de panne système ultérieure. Cette propriété nécessite une écriture physique sur disque, pas seulement en cache.
Défis techniques : Les multiples couches de cache (OS, contrôleur RAID, virtualisation) peuvent compromettre la durabilité si une coupure survient avant l'écriture physique effective.

3.3 Stratégies de Verrouillage

Pessimistic Locking : verrouillage préventif des ressources, correspondant au niveau Serializable
Optimistic Locking : pari sur l'absence de conflits avec détection a posteriori. Problématique dans les applications à fort trafic où les collisions deviennent fréquentes.

Chapitre 4 : Fonctionnement du Moteur et Optimisation des Requêtes

4.1 Architecture Physique et Logique

Une base de données constitue fondamentalement un espace de stockage sur disque contenant des milliards d'octets organisés en bits. Le SGBD agit comme intermédiaire intelligent entre l'utilisateur et ces données brutes, gérant le chargement depuis le stockage permanent vers la mémoire vive selon les besoins.
Cette opération de chargement détermine les performances de toute requête, le moteur utilisant des pointeurs pour naviguer dans les structures et ne chargeant initialement que les métadonnées nécessaires.

4.2 Ordre d'Exécution Logique des Requêtes

Contrairement à l'intuition naturelle, l'ordre d'exécution ne suit pas l'ordre syntaxique. La séquence logique est :

FROM : identification et chargement des tables sources
JOIN : création de tables temporaires par produit cartésien filtré
WHERE : filtrage ligne par ligne des données
GROUP BY : regroupement logique des données
HAVING : filtrage des groupes après agrégation
SELECT : sélection et calcul des colonnes finales
UNION : combinaison de jeux de résultats
ORDER BY : tri final

4.3 Mécanismes des Jointures

Les jointures créent des tables temporairesen mémoire via un produit cartésien conceptuel entre les tables impliquées. Le moteur optimise ce processus en :

Choisissant intelligemment la table de base
Appliquant les critères de jointure pour éliminer les combinaisons non pertinentes
Utilisant les index disponibles pour accélérer les opérations
La taille de ces tables temporaires impacte directement les performances, particulièrement dans le contexte Big Data où joindre des tables de millions de lignes peut générer des structures de plusieurs gigaoctets.

4.4 Optimisations et Recommandations

Méthodologie de construction : commencer par FROM et identifier toutes les sources de données, puis progresser selon l'ordre logique d'exécution.
Optimisation mémoire : l'ajout de RAM peut diviser les temps d'exécution par 10 en permettant l'utilisation de stratégies de jointure en mémoire plutôt que sur disque.
Standards de portabilité : SQL est normalisé depuis ANSI SQL 92 (1992), couvrant environ 80% des besoins courants. Les extensions spécifiques (fonctions spatiales, analytiques) varient selon les SGBD mais suivent une logique similaire.

Chapitre 5 : SQL Avancé et Agrégations

5.1 La Clause HAVING : Filtrage Post-Agrégation

La clause HAVING constitue l'un des mécanismes les plus puissants pour le filtrage de données après agrégation. Sa distinction temporelle avec WHERE est cruciale : WHERE filtre avant agrégation, HAVING filtre après.
Exemple pratique d'analyse salariale :

SELECT annee_embauche, 
MAX(salaire) as salairemax,
   AVG(salaire) as salairemoyen
FROM employes
GROUP BY annee_embauche
HAVING MAX(salaire) > 2 * AVG(salaire);

Cette requête identifie les années présentant des disparités salariales importantes, révélant des politiques de rémunération potentiellement déséquilibrées.
Règle fondamentale : HAVING ne peut exister sans GROUP BY, cette interdépendance reflétant la logique de traitement séquentiel des données.

5.2 Ordre Logique et Optimisation Conceptuelle

L'approche séquentielle optimise naturellement les performances :

Filtrage des données non pertinentes (WHERE)
Regroupement sur un ensemble réduit
Calculs uniquement sur les données finales
Cette méthode évite des calculs coûteux (prix TTC = prix × quantité × TVA) sur des lignes destinées à être supprimées.

5.3 Opérations d'Union et Tri Global

UNION vs UNION ALL :

UNION : élimine automatiquement les doublons
UNION ALL : conserve toutes les lignes, plus performant
L'ORDER BY s'applique au résultat consolidé après toutes les unions, nécessitant des parenthèses explicites pour trier avant fusion.

Chapitre 6 : Introduction au NoSQL

6.1 Philosophie et Définition

NoSQL signifie "Not Only SQL" et non "No SQL", reflétant une approche complémentaire plutôt qu'antagoniste. Cette nuance traduit une philosophie d'ouverture reconnaissant que d'autres approches peuvent être plus adaptées dans certains contextes.

6.2 Motivations et Avantages

Scalabilité horizontale : contrairement à l'approche verticale (ajout de puissance), l'approche horizontale permet d'ajouter de nouveaux nœuds pour absorber la charge croissante, crucial dans le contexte Big Data.
Relaxation des contraintes ACID : échange d'une partie des garanties contre des performances accrues lorsque les exigences fonctionnelles le permettent.
Flexibilité schématique : évolution dynamique des structures, adaptation rapide aux changements de besoins, contrairement à la rigidité relationnelle.

6.3 Modèles de Données et Applications

Document (MongoDB, Elasticsearch) : stockage de documents structurés, optimal pour les catalogues hétérogènes
Clé-valeur (Redis, DynamoDB) : dictionnaire géant optimisé pour la performance, idéal pour les caches et sessions
Colonnes (Cassandra, HBase) : optimisation pour l'analytique avec stockage columnar permettant des compressions efficaces
Graphes (Neo4j, ArangoDB) : gestion des relations complexes, excellent pour les réseaux sociaux et recommandations
Time Series (InfluxDB, Prometheus) : optimisation temporelle avec architecture immutable "Write-Once, Read-Many"

Chapitre 7 : NoSQL Spécialisé et Théorème CAP

7.1 Problématiques des Schémas Variables

Les systèmes NoSQL permettent une flexibilité schématique remarquable. Un document JSON peut contenir des attributs absents dans d'autres documents de la même collection, avantage crucial pour les marketplaces hétérogènes où chaque catégorie possède des caractéristiques spécifiques.
Exemple e-commerce : un produit livre aura {titre, auteur, ISBN, pages} tandis qu'un vêtement aura {nom, couleur, taille, matière}. En relationnel, cela nécessiterait une table avec tous les champs possibles, générant majoritairement des valeurs NULL.

7.2 Architecture des Data Lakes

L'approche Data Lake consiste à :

Enregistrer chaque événement sous forme brute
Stocker sans transformation préalable
Traiter a posteriori selon les besoins analytiques

Cette philosophie s'intègre parfaitement avec les capacités NoSQL de gestion de données semi-structurées.

7.3 Théorème CAP : Compromis Fondamentaux

Le théorème CAP établit qu'un système distribué ne peut garantir simultanément :
C (Consistency) : tous les nœuds voient les mêmes données simultanément
A (Availability) : le système répond toujours aux requêtes
P (Partition Tolerance) : fonctionnement malgré les pannes réseau
Trois combinaisons possibles :
CP : sacrifice de la disponibilité pour maintenir cohérence (bases relationnelles distribuées)
AP : acceptation d'inconsistance temporaire pour rester opérationnel (réseaux sociaux)
CA : fonctionnement parfait sans pannes réseau (bases traditionnelles mono-site)

7.4 Eventual Consistency

L'eventual consistency représente le compromis pragmatique des systèmes AP : toutes les écritures seront propagées et la convergence surviendra "éventuellement", sans garantie de délai précis.
Illustration : publication Facebook immédiatement sauvegardée (availability) mais propagation progressive vers les timelines (eventual consistency).

Chapitre 8 : Choix Technologique et Architectures Hybrides

8.1 Critères de Décision

Le choix entre SQL et NoSQL dépend fondamentalement du pattern d'accès aux données :
Favoriser SQL :

Requêtes imprévisibles
Jointures complexes fréquentes
Propriétés ACID critiques
Données fortement structurées
Favoriser NoSQL :
Patterns d'accès prévisibles
Volume nécessitant scalabilité horizontale
Performance prioritaire sur consistance immédiate
Données semi-structurées ou variables

8.2 Cas d'Usage Sectoriels

Système de réservation (aviation) : base relationnelle pour propriétés transactionnelles critiques, cohérence forte, relations complexes
Catalogue e-commerce : architecture hybride avec MongoDB pour le catalogue (attributs variables) et PostgreSQL pour les transactions
Application IoT : base Time Series (InfluxDB) pour volume d'écriture élevé, données horodatées, agrégations temporelles

8.3 Architectures Polyglotte

Dans la pratique, les grandes applications utilisent plusieurs types de bases simultanément :

Base relationnelle : données de référence, transactions financières
Base documentaire : catalogue produits, contenu utilisateur
Cache clé-valeur : sessions, données temporaires
Base time series : métriques, logs, monitoring
Cette approche nécessite des pipelines ETL pour synchroniser les données entre systèmes, maintenir la cohérence globale, mais ajoute une complexité administrative et opérationnelle considérable.

Chapitre 9 : Modélisation et Conception

9.1 Universalité de la Modélisation

La modélisation constitue une étape fondamentale indépendamment du type de base choisi. Même les bases NoSQL nécessitent des décisions cruciales : pour Elasticsearch, définir un champ "titre" implique des choix de tokenisation, indexation, recherche et sémantique impactant directement performances et pertinence.

9.2 Niveaux d'Abstraction

Niveau conceptuel (QUOI) : concepts métiers et relations, indépendance technologique totale, langage accessible aux non-techniques
Niveau logique (COMMENT) : traduction en structures de données, indépendant de l'implémentation spécifique
Niveau physique (AVEC QUOI) : spécifications techniques liées au SGBD choisi

9.3 Transformation et Règles

Règles fondamentales :

Entité → Table
Association 1..N → Clé étrangère côté N
Association N..N → Table de jointure
Optimisations 1..1 pour performance
La compréhension des mécanismes de stockage (chargement par blocs de 32-64 Ko) guide les décisions de modélisation, justifiant l'externalisation des données volumineuses.

Chapitre 10 : Normalisation Théorique et Pratique

10.1 Objectifs Fondamentaux

La normalisation vise à :

Éliminer la redondance : éviter la duplication d'informations
Prévenir les anomalies : insertion, suppression, mise à jour
Optimiser la structure : maintenir la cohérence et l'intégrité

10.2 Formes Normales Essentielles

Première Forme Normale (1NF) : atomicité du contenu, exclusion des listes de valeurs dans une colonne
Deuxième Forme Normale (2NF) : dépendance fonctionnelle complète de la clé primaire, particulièrement importante pour les clés composites
Troisième Forme Normale (3NF) : élimination des dépendances transitives, toutes les informations concernent directement l'entité identifiée par la clé primaire

10.3 Formes Normales Avancées (4NF et 5NF)

Quatrième Forme Normale (4NF): S'applique aux dépendances multi-valuées, suggérant de séparer les attributs non-clés qui dépendent de plusieurs autres attributs non-clés (ex: listes de compétences et de langues d'un employé). Son application stricte peut complexifier l'usage par la multiplication des tables et jointures.
Cinquième Forme Normale (5NF): Concerne les dépendances de jointures, visant à optimiser la reconstruction des données via des jointures. Elle est considérée comme très théorique et rarement appliquée en pratique.
Pertinence pratique: Ces formes avancées sont peu utilisées explicitement dans la modélisation quotidienne, les professionnels visant intuitivement la 3NF et n'envisageant la dénormalisation que de manière stratégique.

10.4 Dénormalisation Stratégique

La dénormalisationconsiste à introduire volontairement de la redondance pour optimiser les performances. Justifiée dans les contextes :

Big Data et analytique : tables de faits pré-jointes
Données principalement en lecture : optimisation des requêtes fréquentes
Performance critique : réduction des jointures nécessaires
Cette approche nécessite d'accepter consciemment la redondance, complexité de mise à jour et risques d'incohérence en échange des bénéfices escomptés.

10.5 Réalité Professionnelle

Dans la pratique, l'application des formes normales est souvent intuitive, guidée par les bonnes pratiques de programmation orientée objet. La référence explicite à la théorie reste rare, l'accent étant mis sur le pragmatisme et les résultats business.

Schéma Récapitulatif

Concepts Principaux

Types de Données et Optimisation :

Dimensionnement selon besoins réels
CHAR (fixe) vs VARCHAR (variable)
Impact performance/stockage
Système de Clés :
Clé primaire : identification unique
Clés artificielles : indépendance métier
UUID/GUID : solutions distribuées
Intégrité référentielle : contraintes ON DELETE
Transactions et ACID :
Atomicité : tout ou rien
Cohérence : respect des règles
Isolation : niveaux et compromis performance
Durabilité : persistance garantie
SQL et Moteur :
Ordre logique : FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → UNION → ORDER BY
Optimisation : tables temporaires, jointures
HAVING : filtrage post-agrégation
NoSQL et Alternatives :
Définition : "Not Only SQL"
Types : Document, Clé-valeur, Colonnes, Graphes, Time Series
Théorème CAP : Consistency, Availability, Partition Tolerance
Eventual consistency vs cohérence forte
Modélisation :
Niveaux : Conceptuel, Logique, Physique
Règles de transformation
Normalisation vs Dénormalisation

Mots-Clés Essentiels

Technique : ACID, UUID, Sharding, Réplication, Index, Jointures, Produit cartésien, Table temporaire, ETL
Conceptuel : Entité, Association, Cardinalité, Clé primaire/étrangère, Atomicité, Cohérence, Isolation, Durabilité
Architectures : Scalabilité horizontale/verticale, Architecture polyglotte, Data Lake, Eventual consistency, CAP, NoSQL, Time Series
Modélisation : Normalisation, Dénormalisation, Forme normale, Redondance, Anomalie, Dépendance fonctionnelle, Clé de substitution

Cette synthèse constitue un fondement solide pour comprendre l'évolution des technologies de bases de données et maîtriser les choix architecturaux adaptés aux contextes applicatifs modernes. La compréhension de ces concepts permet de naviguer efficacement entre solutions relationnelles traditionnelles et alternatives NoSQL, en fonction des contraintes spécifiques de chaque projet.