Base de données

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 :

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 :

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) :

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 :

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 :

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 :

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 :

  1. Débiter 1000€ du compte source

  2. Créditer 1000€ sur le compte destination
    Les problèmes de concurrence peuvent provoquer :

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) :

  1. Serializable : isolation maximale, performance minimale

  2. Repeatable Read : lectures cohérentes dans une transaction

  3. Read Committed : lecture des données committées uniquement

  4. 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 :

  1. FROM : identification et chargement des tables sources

  2. JOIN : création de tables temporaires par produit cartésien filtré

  3. WHERE : filtrage ligne par ligne des données

  4. GROUP BY : regroupement logique des données

  5. HAVING : filtrage des groupes après agrégation

  6. SELECT : sélection et calcul des colonnes finales

  7. UNION : combinaison de jeux de résultats

  8. 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 :

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 :

  1. Filtrage des données non pertinentes (WHERE)

  2. Regroupement sur un ensemble réduit

  3. 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 :

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 à :

  1. Enregistrer chaque événement sous forme brute

  2. Stocker sans transformation préalable

  3. 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 :

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 :

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 :

Chapitre 10 : Normalisation Théorique et Pratique

10.1 Objectifs Fondamentaux

La normalisation vise à :

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 :

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 :

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.

11-06 après-midi Formation : Architecture et Administration des Bases de Données - Théorie et Pratique

Architecture et Administration des Bases de Données : Théorie et Pratique

Introduction : L'écosystème des systèmes d'information modernes

Dans le paysage complexe des technologies de l'information contemporaines, la gestion des bases de données constitue un pilier fondamental de toute infrastructure informatique. Contrairement à une vision simpliste qui imaginerait une organisation reposant sur une unique base de données monolithique, la réalité moderne révèle un écosystème sophistiqué et distribué, où chaque composant répond à des besoins spécifiques et complémentaires. Cette complexité n'est pas accidentelle : elle résulte d'une évolution naturelle vers la spécialisation et l'optimisation. À mesure que les organisations croissent et que leurs besoins se diversifient, l'architecture des données se structure selon une logique de distribution fonctionnelle qui permet d'optimiser les performances, la maintenance et la sécurité.

L'architecture distribuée : une nécessité fonctionnelle

Au cœur de toute organisation moderne, qu'il s'agisse d'une institution financière ou d'une entreprise industrielle, on retrouve des systèmes centraux qui constituent l'épine dorsale informationnelle. Dans le secteur bancaire, le core banking centralise l'ensemble des opérations fondamentales : gestion des comptes clients, traitement des transactions, administration des produits financiers et respect des contraintes réglementaires. Pour les entreprises classiques, l'ERP (Enterprise Resource Planning) - qu'il s'agisse de solutions comme SAP ou de développements propriétaires - intègre comptabilité, gestion des stocks, ressources humaines et l'ensemble des processus métier critiques. Ces systèmes centraux s'appuient généralement sur de volumineuses bases de données relationnelles capables de traiter des téraoctets d'informations avec des exigences de cohérence, de disponibilité et de performance extrêmement élevées. Cependant, ils ne fonctionnent jamais de manière isolée. En parallèle, une multitude de bases de données spécialisées coexistent dans l'écosystème informatique : systèmes de gestion de contenu (CMS) pour les sites web d'entreprise, applications métier spécifiques comme les CRM ou les outils de reporting, bases de données analytiques dédiées au business intelligence, systèmes de cache pour l'optimisation des performances, et bien d'autres encore. Cette architecture distribuée présente des avantages considérables : spécialisation fonctionnelle permettant d'optimiser chaque composant pour son usage spécifique, isolation des risques évitant qu'un problème sur un système affecte l'ensemble, facilité de maintenance et d'évolution, et possibilité de faire appel à des technologies différentes selon les besoins.

Le métier de Database Administrator : évolution et responsabilités

Transformation du rôle du DBA

Le métier de Database Administrator (DBA) a connu une évolution remarquable au cours des dernières décennies. Autrefois poste dédié à temps plein dans les grandes organisations, avec des spécialistes exclusivement focalisés sur la gestion des bases de données, il tend aujourd'hui à devenir une compétence transversale que les professionnels IT doivent maîtriser en complément d'autres responsabilités. Cette transformation s'explique par plusieurs facteurs convergents : l'automatisation croissante des tâches d'administration grâce aux outils modernes, la démocratisation des systèmes de gestion de bases de données avec des interfaces plus accessibles, et surtout la nécessité d'une approche DevOps qui intègre développement, administration système et gestion des données dans une vision cohérente. Le DBA moderne doit naviguer entre plusieurs domaines d'expertise : une compréhension fine de l'infrastructure (hardware, réseau, stockage), une collaboration étroite avec les équipes de développement pour l'optimisation applicative, et une connaissance approfondie des enjeux métier pour une modélisation optimale des données.

Responsabilités techniques fondamentales

Installation et configuration : approches multiples

Le DBA maîtrise plusieurs méthodologies d'installation selon les contextes et les contraintes. L'installation native suit la documentation officielle du SGBD et offre un contrôle maximal sur la configuration, mais nécessite une expertise technique approfondie. L'installation par gestionnaires de paquets (APT, YUM, ou autres) simplifie le processus et assure une meilleure intégration avec l'écosystème système, au prix d'une certaine standardisation. La containerisation via Docker permet un déploiement rapide avec des configurations pré-établies et une isolation des environnements. Cependant, il convient de noter un point d'attention critique concernant la containerisation des bases de données. Bien que cette approche facilite grandement le déploiement et le test, elle présente des défis spécifiques dans les environnements de production, notamment dans les plateformes d'orchestration comme Kubernetes ou Docker Swarm. Les problématiques de stockage persistant et les questions de performance dues aux couches d'abstraction supplémentaires rendent souvent préférable un déploiement sur infrastructure dédiée pour les systèmes critiques.

Sécurité et gestion des accès : responsabilités critiques

Le DBA détient des privilèges administrateur complets sur les systèmes de bases de données, ce qui implique des responsabilités particulièrement lourdes. Il doit mettre en place une gestion granulaire des droits d'accès par utilisateur et par objet, assumant une responsabilité de confidentialité absolue sur les données sensibles. Dans le contexte réglementaire actuel, notamment avec l'entrée en vigueur du RGPD, le DBA peut endosser le rôle de Data Protection Officer ou du moins jouer un rôle central dans la conformité réglementaire. Il doit implémenter les politiques de sécurité incluant chiffrement, audit et traçabilité, tout en maintenant l'équilibre délicat entre sécurité et performance.

Haute disponibilité : enjeux critiques

La garantie de disponibilité constitue l'un des défis majeurs du métier de DBA, particulièrement dans les environnements industriels critiques. L'exemple souvent cité de l'aciérie illustre parfaitement ces enjeux : lorsqu'une poche de métal en fusion est en cours de traitement, un arrêt de la base de données contrôlant le processus peut avoir des conséquences dramatiques, allant de la perte économique massive aux risques pour la sécurité des personnes. Cette criticité impose la mise en place de systèmes résilients avec des mécanismes sophistiqués : sauvegardes à chaud permettant la sauvegarde sans interruption de service, réplication en temps réel pour assurer la redondance, plans de reprise d'activité (PRA) et de continuité d'activité (PCA) testés régulièrement, et monitoring proactif pour la détection précoce des incidents. Dans de tels contextes, les DBA sont souvent soumis à des astreintes 24h/7j.

Optimisation et tuning : l'art de la performance

L'optimisation constitue l'aspect le plus technique et le plus gratifiant du métier de DBA. Elle englobe plusieurs dimensions complémentaires : l'optimisation des requêtes par l'analyse des plans d'exécution et l'indexation intelligente, le tuning infrastructure incluant la configuration des I/O, de la mémoire et des processeurs, la gestion sophistiquée du stockage avec l'optimisation des systèmes RAID et SAN, et la conception d'architectures haute performance utilisant clustering et partitioning. Cette expertise technique place le DBA au cœur de la performance globale du système d'information, avec un impact direct sur l'expérience utilisateur et l'efficacité opérationnelle de l'organisation.

Architecture interne des bases de données : le modèle Oracle

Séparation logique et physique : un principe fondamental

Pour comprendre les mécanismes internes des bases de données modernes, le modèle architectural d'Oracle offre un exemple particulièrement éclairant de la séparation entre abstraction logique et réalité physique. Cette séparation constitue l'un des piliers conceptuels qui permettent aux SGBD d'offrir flexibilité et performance.

Structure logique hiérarchique

La structure logique s'organise selon une hiérarchie claire et cohérente : Au niveau le plus élevé, la base de données représente l'entité logique globale, regroupant l'ensemble des informations d'une application ou d'une organisation. Cette base se subdivise en tablespaces, espaces de stockage logiques qui regroupent des objets selon leur fonction ou leur criticité. Chaque tablespace contient des segments, représentations logiques d'objets spécifiques comme les tables ou les index. Ces segments sont eux-mêmes composés d'extents, ensembles contigus de blocs alloués dynamiquement selon les besoins. Enfin, au niveau le plus fin, les data blocks constituent la plus petite unité de stockage logique, généralement de quelques kilo-octets. Cette organisation hiérarchique permet une gestion granulaire et optimisée des ressources, où chaque niveau peut être configuré et optimisé indépendamment selon les besoins spécifiques.

Structure physique correspondante

La structure physique mappe cette organisation logique sur les supports de stockage réels. Les datafiles constituent les fichiers physiques stockés sur le système de fichiers ou directement sur les dispositifs de stockage. Le mapping entre tablespaces logiques et datafiles physiques offre une flexibilité considérable pour l'optimisation des performances et la gestion de l'espace. Pour les environnements à très hautes exigences de performance, Oracle propose également l'accès aux raw devices, permettant un accès direct aux blocs physiques sans passer par le système de fichiers. Cette approche, bien que complexe à gérer, peut apporter des gains de performance significatifs dans des contextes spécifiques.

Stratégies d'optimisation avancées

Séparation fonctionnelle des données

L'architecture en tablespaces permet une optimisation fine en fonction des caractéristiques d'usage des données. Un tablespace Index peut être configuré sur des supports rapides comme les SSD pour optimiser les accès aux index, tandis que le tablespace Data contenant les données principales peut résider sur un stockage standard offrant un bon compromis performance/coût. Pour les données historiques peu consultées, un tablespace Archive peut utiliser un stockage lent mais très capacitif.

Stratégie Hot/Warm/Cold

Cette approche classifie les données selon leur fréquence d'accès et adapte la stratégie de stockage en conséquence. Les données Hot, fréquemment accédées, bénéficient d'un stockage haute performance. Les données Warm, occasionnellement utilisées, sont placées sur un stockage standard. Les données Cold, rarement consultées mais devant rester accessibles, sont archivées sur un stockage économique haute capacité.

Raw Devices : optimisation extrême

Pour les environnements à exigences de performance exceptionnelles, l'utilisation de raw devices permet d'éliminer les couches d'abstraction du système de fichiers et d'accéder directement aux blocs physiques. Cette approche trouve sa justification dans des contextes très spécifiques : trading haute fréquence où quelques millisecondes déterminent la rentabilité, calcul scientifique intensif traitant des téraoctets de données (CERN, simulations climatiques), ou ERP critiques gérant des processus industriels continus. Les gains de performance peuvent être spectaculaires, mais la complexité de gestion s'accroît considérablement, nécessitant une expertise très pointue.

Gestion des transactions et garantie de cohérence

Architecture des logs de transaction : universalité du concept

Tous les SGBD modernes implémentent un système de journalisation sophistiqué pour garantir la cohérence des données, bien que les terminologies varient selon les éditeurs. PostgreSQL utilise le WAL (Write Ahead Log), MySQL s'appuie sur le Binary Log (bin log), Oracle maintient des Transaction Logs et Redo Logs, tandis que SQL Server gère ses propres Transaction Logs.

Mécanisme de fonctionnement

Le principe de fonctionnement repose sur l'écriture préalable : toute modification est d'abord écrite dans le journal avant d'être appliquée aux données. L'écriture différée permet ensuite d'écrire les données en mémoire puis sur disque de manière asynchrone, optimisant ainsi les performances. En cas d'incident, le processus de recovery utilise le journal pour reconstruire un état cohérent. Cette architecture garantit les propriétés ACID (Atomicité, Cohérence, Isolation, Durabilité) fondamentales aux bases de données transactionnelles, permettant de maintenir l'intégrité des données même en cas de panne système.

Processus de récupération

En cas de panne système, le processus de recovery suit une séquence précise et rigoureuse. L'analyse du log identifie d'abord les transactions incomplètes et détermine l'état de chaque transaction au moment de la panne. La phase de Redo rejoue ensuite les transactions validées mais non encore écrites sur disque, garantissant que toutes les modifications confirmées sont bien persistées. La phase d'Undo annule les transactions non validées, restaurant la cohérence. Enfin, une vérification de cohérence contrôle l'intégrité globale des données.

Applications avancées : réplication et architectures modernes

Le journal de transaction trouve des applications particulièrement élégantes dans la réplication entre serveurs. Dans une architecture Master-Slave, le serveur maître n'envoie que son journal de transaction, que le serveur esclave applique à son propre datafile. Cette approche est infiniment plus efficace que la réplication complète des fichiers, car seules les modifications effectives sont transmises, les opérations de lecture et les transactions échouées n'étant pas incluses. Cette séparation entre données et journal ouvre également la voie à des architectures avancées comme CQRS (Command Query Responsibility Segregation), où les opérations de lecture et d'écriture sont physiquement séparées pour optimiser les performances.

Configuration et optimisation des SGBD

Paramètres réseau et connectivité

Configuration de l'adresse de liaison

Le paramètre bind address détermine les interfaces réseau sur lesquelles le SGBD accepte les connexions. Une configuration sur localhost limite l'accès à la machine locale, offrant une sécurité maximale mais une flexibilité réduite. Une configuration sur 0.0.0.0 permet l'accès depuis n'importe quelle adresse IP, offrant une flexibilité maximale mais nécessitant une vigilance sécuritaire accrue. Le choix dépend fondamentalement de l'architecture : développement local versus accès multi-machines.

Dimensionnement des connexions : coordination critique

La configuration du nombre maximum de connexions nécessite une coordination étroite entre administrateurs de bases de données et équipes applicatives. Les problématiques courantes incluent le sous-dimensionnement applicatif (application configurée pour 10 connexions maximum, base acceptant 200 connexions) créant un goulot d'étranglement au niveau applicatif, ou le sous-dimensionnement base (application configurée pour 2000 connexions, base limitée à 200) provoquant des erreurs de connexion. Les bonnes pratiques recommandent d'inclure les connexions de service (backup, maintenance) dans le dimensionnement, de surveiller les métriques de pool de connexions, et d'ajuster dynamiquement selon la charge observée.

Optimisation mémoire : shared buffers et stratégies de cache

Les shared buffers constituent le cache principal du SGBD, où les blocs de données fréquemment accédés restent en mémoire pour réduire drastiquement les accès disque. L'amélioration des performances est directement proportionnelle à la taille du cache, dans la limite des ressources disponibles. La configuration peut adopter une approche de pool unique pour la simplicité de gestion avec allocation globale, ou de pools multiples permettant une optimisation fine par type d'opération.

Espaces de travail pour jointures et stratégies d'optimisation

La mémoire de travail dédiée aux jointures influence directement les stratégies d'optimisation choisies par le SGBD. Deux approches principales existent : Les Nested Loops (boucles imbriquées) suivent une logique simple de double boucle, avec une complexité O(n×m), une faible consommation mémoire, mais des performances dégradées sur gros volumes. Les Hash Join créent des tables de hachage en mémoire, permettent une parallélisation sur plusieurs cœurs, offrent des performances supérieures mais avec une consommation mémoire importante. L'optimiseur choisit automatiquement la stratégie en fonction des ressources disponibles et des caractéristiques des données.

Optimisation des requêtes : l'art de la performance

L'optimiseur automatique : intelligence du SGBD

L'optimiseur de requêtes constitue le cerveau du SGBD, responsable de transformer une requête SQL en plan d'exécution optimal. Ses critères d'optimisation incluent la taille des tables impliquées, les statistiques de distribution des données, les index disponibles, et les ressources système disponibles.

Intervention manuelle : hints et optimisation ciblée

Lorsque l'optimiseur automatique produit des plans sous-optimaux, les hints permettent d'orienter ses décisions. Ces indications peuvent porter sur l'ordre de traitement des tables, la sélection d'index spécifiques, ou le choix de stratégie de jointure. Le processus d'optimisation suit généralement ces étapes : analyse du plan d'exécution initial, identification des goulots d'étranglement, application de hints ciblés, et comparaison des métriques de performance.

Outils d'analyse avancés

Les SGBD modernes intègrent des advisors automatiques qui détectent proactivement les requêtes problématiques, proposent des suggestions d'optimisation chiffrées, et offrent des interfaces graphiques pour l'aide à la décision. Cette sophistication justifie économiquement l'investissement dans des solutions commerciales pour les charges complexes impliquant des requêtes de 60-80 lignes sur des centaines de tables.

Gestion des utilisateurs et contrôle d'accès

Architecture hiérarchique des permissions

Fondements conceptuels

La gestion des droits dans les systèmes de bases de données s'organise selon une hiérarchie logique qui répond à des impératifs pratiques de simplification administrative. Au niveau le plus basique, les droits unitaires constituent les autorisations élémentaires d'effectuer une action spécifique sur un objet particulier. Bien que cette granularité fine offre un contrôle précis, elle devient rapidement ingérable dans des environnements complexes. Les rôles regroupent des ensembles cohérents de droits selon une logique fonctionnelle ou métier. Un rôle "bibliothécaire" pourrait inclure des droits en lecture sur toutes les tables de livres, des droits en écriture sur la table des emprunts, et des droits spécifiques sur la gestion des adhérents. Les groupes d'utilisateurs permettent une gestion collective, où les rôles peuvent être assignés à des groupes, bénéficiant automatiquement à tous leurs membres.

Implémentation technique

La syntaxe SQL standardisée suit des principes similaires dans tous les SGBD. La création d'entités utilise les commandes CREATE USER et CREATE ROLE. L'attribution des droits s'effectue avec la commande GRANT qui associe systématiquement privilège, objet et bénéficiaire. La fonctionnalité WITH GRANT OPTION permet la délégation de l'attribution des droits, particulièrement utile pour la gestion décentralisée. La commande REVOKE permet l'annulation des privilèges précédemment accordés.

Intégration avec les systèmes d'authentification d'entreprise

Modes d'authentification multiples

Les bases de données d'entreprise supportent généralement plusieurs modes d'authentification. L'authentification native utilise les mécanismes propres au SGBD, offrant un contrôle total mais nécessitant une administration dédiée. L'intégration Active Directory permet de centraliser la gestion des identités, avec les comptes définis dans AD et l'authentification déléguée au contrôleur de domaine. L'authentification intégrée Windows/Kerberos représente le niveau d'intégration le plus poussé, offrant une expérience Single Sign-On transparente mais avec des défis techniques importants concernant la propagation des tokens et la gestion des erreurs.

Considérations économiques : impact des licences

Les modèles de licencing influencent significativement les choix d'architecture. Le licencing par utilisateur nommé impose un coût pour chaque utilisateur accédant à la base, tandis que le licencing par cœur de processeur facture selon la puissance du serveur, indépendamment du nombre d'utilisateurs. Face aux coûts élevés des licences propriétaires, les entreprises adoptent souvent des stratégies de comptes de service applicatifs, où une application utilise un compte unique et gère elle-même les autorisations par utilisateur, réduisant drastiquement le nombre de licences nécessaires.

Stratégies de sauvegarde et de restauration

Principe du moindre privilège : prévention fondamentale

Le principe du moindre privilège constitue un pilier fondamental de la sécurité informatique. Il stipule qu'un utilisateur ne doit disposer que des privilèges strictement nécessaires à l'accomplissement de ses fonctions légitimes. Dans le contexte des bases de données, cela signifie éviter de se connecter systématiquement avec des comptes administrateurs pour des tâches courantes. L'exemple classique d'une commande Linux illustre l'importance de ce principe : la différence entre rm -rf toto/* et rm -rf toto/ * (un simple espace) peut avoir des conséquences dramatiques si exécutée avec des privilèges root. Les statistiques montrent que près de la moitié des incidents en production résultent de commandes exécutées avec des privilèges excessifs.

Types de sauvegarde selon la disponibilité

Sauvegarde à froid vs. sauvegarde à chaud

La sauvegarde à froid nécessite l'arrêt complet du système, garantissant une cohérence parfaite mais avec une interruption de service. Elle convient aux entreprises disposant de fenêtres de maintenance régulières. La sauvegarde à chaud maintient la disponibilité du service mais introduit un risque de perte de données ou d'incohérence. Pour les grandes plateformes comme Netflix, la sauvegarde est un processus continu créant un cycle perpétuel de protection des données.

Stratégies techniques pour la sauvegarde à chaud

Le snapshot capture l'état des données à un instant T, offrant une cohérence parfaite si la capture s'effectue entre deux transactions. La sauvegarde par réplication utilise une architecture maître-esclave où la réplication est interrompue sur l'esclave pour effectuer la sauvegarde, puis reprend pour rattraper les modifications manquantes.

Approches de sauvegarde : logique vs. physique

Sauvegarde logique (dump)

La sauvegarde logique exporte les données sous forme de requêtes SQL reconstituables. Elle offre une flexibilité maximale, une lisibilité du format, une portabilité entre versions et plateformes, et une granularité permettant la restauration sélective. Cependant, elle présente des limitations en termes de performance et de volumétrie.

Sauvegarde physique

La sauvegarde physique implique la copie directe des fichiers de données et des journaux de transactions. Elle nécessite un mode backup pour garantir la cohérence, figeant les datafiles en lecture seule pendant la copie et appliquant ensuite les logs pour la mise à jour.

Sauvegarde par snapshot

Le snapshot utilise les capacités de l'infrastructure sous-jacente pour créer une image instantanée au niveau du système de fichiers. Cette approche offre un impact minimal sur la base en fonctionnement, une rapidité de création quasi-instantanée, et pas d'interruption de service.

Stratégies de sauvegarde selon le contenu

Types de sauvegarde

La sauvegarde complète capture l'intégralité des données, constituant la référence pour toute stratégie. La sauvegarde différentielle capture tous les changements depuis la dernière sauvegarde complète, facilitant la restauration mais avec une taille croissante. La sauvegarde incrémentale capture uniquement les changements depuis la dernière sauvegarde, réduisant la taille mais complexifiant la restauration.

Point-in-Time Recovery (PITR)

Le PITR permet de restaurer une base de données à un moment précis en combinant une sauvegarde physique et l'application des journaux de transactions jusqu'au moment souhaité. Cette technique s'avère particulièrement utile pour les investigations forensiques et la récupération après incidents.

Métriques et objectifs

Indicateurs de performance

Le RPO (Recovery Point Objective) définit la perte de données maximale acceptable, influençant directement la fréquence des sauvegardes. Le RTO (Recovery Time Objective) spécifie le temps maximal acceptable pour restaurer le service, déterminant le choix de la stratégie de restauration.

Politiques de rétention

La politique de rétention définit la durée de conservation des sauvegardes et doit prendre en compte les besoins métier, les contraintes légales (RGPD, enquêtes fiscales), et les coûts de stockage. Elle nécessite une collaboration étroite entre équipes techniques et métier.

Optimisation des données historisées : le processus de freeze

Principe fondamental

L'optimisation des données historisées représente un enjeu crucial dans la gestion moderne des bases de données. Le processus de freeze (gel) constitue une technique d'optimisation particulièrement efficace pour traiter les données anciennes qui ne subissent plus de modifications.

Mécanisme de transformation

Le freeze repose sur la transformation de données mutables en données immuables. Lorsque des données atteignent un certain âge ou que leur période de modification active se termine, elles sont marquées comme étant en lecture seule. Cette transformation entraîne plusieurs optimisations automatiques : élimination des logs de transaction puisqu'aucune modification future n'est attendue, optimisation du cache avec mise en cache agressive des données immuables, et restructuration physique pour optimiser les accès en lecture.

Applications pratiques et bénéfices

Dans le secteur bancaire, les transactions de plus d'un exercice fiscal peuvent être gelées, permettant une consultation rapide de l'historique sans impacter les performances des opérations courantes. Les logs d'activité système, une fois consolidés, bénéficient grandement de cette optimisation. Cette technique s'inscrit dans une approche de séparation des charges OLTP et OLAP, où les données gelées se rapprochent naturellement du modèle OLAP optimisé pour l'analyse et la consultation.

Évolutions et perspectives

Impact du cloud et de l'intelligence artificielle

Les environnements cloud modernes permettent d'optimiser cette approche en déplaçant automatiquement les données gelées vers des supports de stockage moins coûteux mais toujours accessibles. L'intelligence artificielle peut aider à déterminer automatiquement le moment optimal pour geler des données, en analysant les patterns d'accès et les contraintes métier.

Défis et limitations

La gestion de la transition entre états mutable et gelé doit être soigneusement orchestrée. Il faut prévoir des procédures pour les cas exceptionnels où des données gelées doivent être modifiées, impliquant généralement un "dégel" temporaire contrôlé. L'état des données doit être tracé et auditable, particulièrement dans des contextes réglementés.

Schéma récapitulatif

 

Concepts architecturaux principaux

Architecture des systèmes d'information :

Rôles et responsabilités

Database Administrator (DBA) :

Stratégies de sauvegarde et performance

Types de sauvegarde :

Technologies et optimisation

Gestion transactionnelle :

Mots-clés essentiels

DBA, ERP, Core Banking, Tablespace, Datafiles, Raw devices, WAL, RGPD, Hot/Warm/Cold storage, ACID, Recovery, High Availability, Shared Buffers, Connection Pool, Nested Loops, Hash Join, Hints, Optimiseur, Rollback, Commit, RBAC, Information Schema, PITR, RPO, RTO, Freeze, OLTP/OLAP, Snapshot, Réplication, `Principe du moindre privilège

21-05 cours : Chapitre 5 : Optimisation, Maintenance et Architectures Avancées des Bases de Données

Introduction : Au-delà de l'Écriture des Requêtes

Après avoir maîtrisé la syntaxe du langage SQL, la modélisation des données (MCD, MLD, MPD) et les principes fondamentaux des systèmes de gestion de bases de données (SGBD), une nouvelle étape cruciale se présente pour tout professionnel des données : l'optimisation des performances. Une requête fonctionnelle n'est pas nécessairement une requête performante. Dans des environnements de production, où les volumes de données peuvent atteindre des milliards d'enregistrements, une requête mal optimisée peut saturer les ressources du serveur (CPU, RAM, I/O disque) et dégrader l'expérience utilisateur. Ce chapitre couvre un large spectre de l'ingénierie des bases de données, des mécanismes internes d'optimisation des SGBD relationnels à la maintenance proactive, en passant par les architectures distribuées des systèmes NoSQL. Nous explorerons comment analyser et améliorer les performances des requêtes, comment maintenir une base de données saine et réactive, et comment concevoir des systèmes capables de gérer des volumes de données massifs tout en garantissant haute disponibilité et scalabilité.

Partie I : Optimisation des Requêtes dans les SGBD Relationnels

1. Le Cœur de la Performance : L'Optimiseur de Requêtes

Lorsqu'un SGBD reçoit une requête SQL, il ne l'exécute pas aveuglément. Entre la réception de la chaîne de caractères SELECT ... et l'affichage du résultat, un composant logiciel sophistiqué entre en jeu : l'optimiseur de requêtes (Query Optimizer). Son rôle est d'analyser la requête et de déterminer le "chemin" le plus efficace pour accéder aux données et les traiter. Ce chemin est appelé plan d'exécution (execution plan).

1.1. Le Processus d'Exécution d'une Requête

  1. Analyse Syntaxique (Parsing) : Le moteur vérifie que la syntaxe de la requête est correcte.
  2. Analyse Sémantique : Il vérifie que les tables et colonnes existent et que l'utilisateur a les droits nécessaires.
  3. Génération du Plan d'Exécution : C'est ici qu'intervient l'optimiseur. Pour une même requête, il existe de multiples manières de l'exécuter (ordre des jointures, utilisation d'index, etc.). L'optimiseur évalue plusieurs stratégies possibles, estime leur "coût" et choisit celle qu'il juge la plus rapide.
  4. Exécution : Le moteur exécute la requête en suivant pas à pas le plan d'exécution choisi.

1.2. Les Critères de Décision de l'Optimiseur

L'optimiseur base ses décisions sur une multitude de facteurs pour estimer le coût de chaque plan. Ce coût est une métrique abstraite représentant principalement le temps et les ressources (surtout les I/O disque).

2. Dévoiler la Stratégie : La Commande EXPLAIN

La commande EXPLAIN est l'outil de diagnostic indispensable pour visualiser le plan d'exécution choisi par l'optimiseur. En préfixant une requête par EXPLAIN, on demande au SGBD non pas de l'exécuter, mais de nous retourner sa stratégie.

2.1. EXPLAIN vs EXPLAIN ANALYZE : Théorie vs Pratique

2.2. Anatomie d'un Plan d'Exécution : Opérations Clés

L'analyse d'un plan passe par la compréhension de ses opérations.

3. L'Art de l'Indexation : Le Levier Principal de l'Optimisation

Un index est une structure de données séparée, conçue pour accélérer la recherche de lignes. Il contient les valeurs d'une ou plusieurs colonnes et un pointeur vers l'emplacement physique de la ligne. Avantages : Accélération massive des lectures (SELECT). Inconvénients : Ralentissement des écritures (INSERT, UPDATE, DELETE) car l'index doit aussi être mis à jour, et consommation d'espace disque.

3.1. Quelles Colonnes Indexer ?

3.2. Les Différents Types d'Index

Partie II : Maintenance et Gestion de la Concurrence

Une base de données est un système vivant qui nécessite un entretien régulier pour maintenir ses performances.

1. Maintenance Proactive : Statistiques et Fragmentation

1.1. Mise à Jour des Statistiques

Comme vu précédemment, l'optimiseur s'appuie sur les statistiques. Après des modifications massives de données (INSERT, DELETE), ces statistiques deviennent obsolètes, conduisant l'optimiseur à choisir de mauvais plans d'exécution.

1.2. Gestion de la Fragmentation (VACUUM)

Les opérations DELETE et UPDATE créent des "trous" dans les fichiers de données, un phénomène appelé fragmentation. Cela ralentit les lectures, qui doivent effectuer des sauts sur le disque (I/O aléatoires) au lieu d'une lecture séquentielle efficace.

2. Manipulation des Données et Gestion de la Concurrence

2.1. Commandes UPDATE et DELETE

Ces commandes modifient ou suppriment des lignes. Leur puissance réside dans la clause WHERE, qui cible les lignes à affecter. L'omission de la clause WHERE est catastrophique, car l'opération s'appliquera à toute la table.

2.2. Transactions et Propriétés ACID

Une transaction est un bloc d'opérations traité de manière atomique. Elle garantit les propriétés ACID :

2.3. Verrouillage (Locking) et Interblocages (Deadlocks)

Pour garantir l'isolation, les SGBD utilisent des verrous (locks). Une transaction qui modifie une ligne pose un verrou exclusif, empêchant les autres de la lire ou de la modifier.

3. Logique Applicative dans la Base de Données

Les SGBD permettent d'embarquer du code via des langages procéduraux (PL/SQL pour Oracle, T-SQL pour SQL Server, PL/pgSQL pour PostgreSQL).

Partie III : Architectures NoSQL pour la Haute Disponibilité et la Scalabilité

L'ère du Big Data a popularisé les bases de données NoSQL, conçues nativement pour la distribution et la scalabilité horizontale. La question centrale devient : "Comment architecturer mon cluster pour que les données soient fiables, accessibles et performantes ?"

1. Le Cadre Théorique : Le Théorème CAP

Le théorème CAP stipule qu'un système distribué ne peut garantir simultanément que deux des trois propriétés suivantes :

  1. Cohérence (Consistency - C) : Tous les nœuds voient la même donnée au même moment.
  2. Disponibilité (Availability - A) : Chaque requête reçoit une réponse.
  3. Tolérance à la Partition (Partition Tolerance - P) : Le système fonctionne malgré les pannes réseau. La tolérance à la partition (P) étant une nécessité, le choix se fait entre C et A. La plupart des systèmes NoSQL sont des systèmes AP, privilégiant la disponibilité et adoptant un modèle de cohérence éventuelle (Eventual Consistency).

2. La Réplication : Garantir la Haute Disponibilité

La réplication consiste à copier les données sur plusieurs serveurs (nœuds). Un ensemble de serveurs contenant les mêmes copies est un Replica Set.

3. Le Sharding : Assurer la Scalabilité Horizontale

Le sharding (ou partitionnement horizontal) consiste à répartir les données sur plusieurs serveurs (ou shards). Chaque shard ne stocke qu'un sous-ensemble des données.

4. Modélisation en NoSQL Orienté Document

Dans une base comme MongoDB, la modélisation tourne autour de deux stratégies :

Schéma Récapitulatif

21-05 Cours: Modélisation NoSQL et Sécurité des Systèmes d’Information — schémas, index, chiffrement, audit, monitoring

Modélisation NoSQL et Sécurité des Systèmes d’Information: schémas, accès, chiffrement, audit et monitoring

Introduction générale: une approche intégrée, du modèle de données à la sécurité opérationnelle

La réussite d’un projet data moderne repose sur deux piliers complémentaires: une modélisation NoSQL adaptée aux usages réels et une sécurité “en couches” couvrant l’accès, le chiffrement, l’audit et le monitoring. Contrairement à la normalisation relationnelle “standardisée”, la modélisation NoSQL (documents, colonnes, clé/valeur) se décide au regard des patrons d’accès, de la volumétrie et des contraintes du moteur choisi (MongoDB, Elasticsearch, DynamoDB, etc.). En parallèle, la sécurité n’est jamais une mesure unique: elle s’organise comme un oignon, par couches successives (réseau, transport, authentification, autorisation, données, opérations). Ce chapitre adopte un ton didactique et pragmatique: il développe les choix de schéma (embedding vs références), les limites physiques (taille des documents, I/O), la gestion des binaires, l’indexation et la performance; puis relie ces décisions au chiffrement (en transit et au repos), aux contrôles d’accès (moindre privilège), à l’audit et au monitoring, jusqu’aux sauvegardes testées et à la posture professionnelle.

Partie I — Modélisation NoSQL: principes, choix et bonnes pratiques

1. Pourquoi “ça dépend” en NoSQL

En NoSQL, le “bon” modèle est celui qui justifie ses compromis au regard:

2. Schéma-less, mais pas sans discipline

Schema-less n’est pas l’absence totale de structure: c’est la capacité à accepter des documents hétérogènes. Exemple: une spec “couleur” en string, une “taille” en entier/float, ou l’absence de certaines clés d’un produit à l’autre. Cette flexibilité:

3. Embedding vs Références: la décision structurante

Deux approches physiques:

4. Cardinalité, attributs multi-valués et index

5. La taille contre le nombre: mesurez en octets et en I/O

“Beaucoup” ne signifie pas “mille éléments”—ce qui importe, c’est la taille totale et l’empreinte I/O:

6. Données binaires: éviter l’inline

Stocker des binaires en base JSON via base64 gonfle la taille et dégrade les performances.

7. Indexation et performance: filtrer ≠ charger

8. Étude de cas: Produits, Specs, Avis

9. Impact du moteur choisi: MongoDB vs Elasticsearch

10. Exemples de designs

11. Analogies et cas applicatifs

12. Erreurs fréquentes à éviter

Partie II — Sécurité des systèmes d’information et des bases: principes, couches et pratiques

1. Défense en profondeur et moindre privilège

La sécurité est une chaîne; elle cède au maillon le plus faible. Approche par couches:

2. Contrôles d’accès: rôles, permissions, soft delete

3. Authentification et hygiène

4. Contrôle d’accès réseau

5. Journalisation et audit

Objectifs: forensique, conformité, accounting.

6. Chiffrement: en transit et au repos

7. Sauvegardes, transactions et reprise

8. Décommissionnement des supports

Partie III — Sécurité des applications web: injections SQL, XSS, validation et WAF

1. Injections SQL: nature et prévention

Définition: injection lorsque des données utilisateur deviennent du code SQL et modifient la requête.

2. Validation des entrées et échappement des sorties

3. WAF et détection

Partie IV — Monitoring, opérations et posture de conseil

1. Logging et transactions: éviter le piège du rollback des logs

2. Observabilité: métriques, traces et alertes

3. Accès et réseau: segmentation, bastion, certificats

4. Sauvegardes et restaurations: vérité opérationnelle

5. Scénarios d’attaque et erreurs systémiques

6. Posture de conseil et responsabilité

Interdisciplinarité et liens utiles

Exemples pratiques intégrés

Cas 1: E-commerce avec filtrage massif de specs et avis nombreux

Cas 2: Binaires (PDF de factures)

Cas 3: Petites listes fortement liées (adresses client)

Cas 4: Web App et SQLi/XSS

Pistes méthodologiques: concevoir, tester, ajuster

  1. Modèle conceptuel: entités/relations (produits, specs, avis, clients).
  2. Patrons d’accès et SLA: requêtes fréquentes, volumes, filtres/tri/pagination.
  3. Modèle physique et index:
    • Embedding vs référenciation par cardinalité et volumétrie.
    • Dimensionner la taille des documents; planifier index et partitions.
    • Prévoir pipelines (ETL, caches, search), résilience et resynchronisation.
  4. Sécurité et opérations:
    • Rôles et moindres privilèges; TLS/mTLS; audit externe; sauvegardes testées.
    • Observabilité: métriques, logs, traces; alertes actionnables.
  5. Itérations: mesurer, profiler, corriger (coût des requêtes, taille des payloads, plans d’exécution).

Points clés et mots-clés (mini-listes contextualisées)

Schéma riassuntivo: concepts principaux et mots-clés

Concepts principaux: