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ère des 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éels de 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 temporaires en 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énormalisation consiste à 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.