Systèmes de gestion de bases de données relationnelles

8.3 Systèmes de gestion de bases de données relationnelles

Objectifs d'apprentissage

À la fin de cette section, vous serez capable de :

Discuter du modèle relationnel
Décrire les aspects théoriques et pratiques du langage de requête structuré (SQL)
Expliquer comment créer une conception logique de base de données relationnelle
Démontrer comment créer une conception physique de base de données relationnelle
Discuter des interfaces de programmation d'applications et des techniques utilisées pour programmer des applications de bases de données relationnelles
Identifier les différents composants d'un système de gestion de bases de données relationnelles

Un système de gestion de bases de données relationnelles (SGBDR) est un type de SGBD qui stocke des éléments de données connexes dans une structure de table basée sur des lignes. Une transaction SGBDR est une unité de travail logique unique qui accède et modifie éventuellement le contenu d'une base de données à l'aide d'opérations de lecture et d'écriture. Plusieurs commandes SQL peuvent être exécutées dans le cadre d'une seule transaction SGBDR en tant qu'unité de travail logique unique. Par exemple, un étudiant peut s'inscrire à plusieurs cours à l'aide du système d'inscription d'une université. Pour maintenir la cohérence dans un SGBDR, les transactions satisfont à des propriétés connues sous le nom d'atomicité, cohérence, isolation et durabilité (ACID). Ces propriétés sont nécessaires pour maintenir la cohérence des données (data consistency), l'intégrité et la fiabilité lors de l'exécution de transactions via un SGBDR. L'atomicité garantit que plusieurs commandes SQL faisant partie de la même transaction sont exécutées de manière atomique (c'est-à-dire comme une unité). Dans l'exemple mentionné précédemment, une fois la transaction d'inscription terminée, l'étudiant sera inscrit à l'ensemble des trois cours. Si cela n'est pas possible parce que l'un des cours est complet, la transaction ne se terminera pas avec succès. La cohérence garantit que seules des données valides sont écrites dans la base de données. Dans l'exemple d'inscription d'étudiant, cela signifie simplement que les informations d'inscription stockées dans la base de données seront cohérentes avec la transaction d'inscription qui a été effectuée. L'isolation garantit que plusieurs utilisateurs accédant au SGBDR simultanément ne seront pas affectés par les transactions effectuées par d'autres. Dans l'exemple d'inscription aux cours, plusieurs étudiants peuvent s'inscrire simultanément sans qu'aucun d'entre eux ne remarque d'effets secondaires résultant de l'accès concurrentiel au SGBDR par plusieurs étudiants. Enfin, la durabilité garantit qu'une fois les informations stockées dans la base de données, elles y resteront de manière permanente. Dans l'exemple d'inscription aux cours, si un étudiant s'inscrit avec succès, les informations d'inscription ne changeront pas à moins qu'il ne décide de revenir en arrière et d'effectuer une autre transaction de suppression/ajout. Bien que les propriétés de transaction ACID garantissent que les données stockées sont fiables et exactes, elles ont également un coût. Par exemple, garantir une isolation complète dans un SGBDR nécessite un temps de traitement supplémentaire considérable.

En raison de l'utilisation de schémas logiques de base de données qui contraignent la structure de table basée sur des lignes et exigent que chaque champ respecte des contraintes de type spécifiques, les SGBDR ne sont pas efficaces pour stocker des données non structurées ou des données semi-structurées (semistructured data). Le schéma rigide rend également les SGBDR plus coûteux à configurer, à maintenir et à faire évoluer. Les SGBDR exigent des utilisateurs qu'ils aient des cas d'utilisation spécifiques à l'avance, et toute modification du schéma est généralement difficile et prend du temps. De plus, les SGBDR traditionnels ont été conçus pour fonctionner sur un seul nœud informatique, ce qui signifie que leur vitesse est considérablement plus lente lors du traitement de grands volumes de données. Le partitionnement (sharding) des SGBDR est une méthode de partitionnement qui divise la base de données en composants plus petits, ce qui accélère le processus de gestion, mais son utilisation tout en maintenant la conformité ACID est difficile.

Modèle relationnel

Le modèle relationnel de données est basé sur le concept de relation. Une relation (relation) est un concept mathématique basé sur les idées d'ensembles. Le modèle a été proposé pour la première fois par Dr. Edgar F. Codd d'IBM Research en 1970. Une relation contient généralement un ensemble de lignes. Les éléments de données de chaque ligne représentent certains faits qui correspondent à une entité ou une relation du monde réel. Dans le modèle formel, les lignes sont appelées n-uplets, chaque colonne a un en-tête de colonne qui indique la signification des éléments de données de cette colonne, et l'en-tête de colonne est appelé nom d'attribut ou simplement attribut (attribute). Plusieurs attributs peuvent être sélectionnés pour former des super-clés qui identifient de manière unique les n-uplets individuels. Les super-clés minimales sont appelées clés candidates. Les clés candidates sont considérées comme minimales car elles ne doivent inclure qu'un nombre minimum d'attributs pour identifier de manière unique les n-uplets individuels. Par exemple, une base de données de voitures peut utiliser le numéro d'identification du véhicule (VIN) et les attributs de marque du véhicule comme clé candidate. Une autre clé candidate possible pourrait être obtenue en utilisant la plaque d'immatriculation et l'état du véhicule. L'une ou l'autre des clés candidates peut être sélectionnée comme clé primaire (primary key), ce qui fournit ensuite un identifiant unique pour chaque enregistrement de table (Tableau 8.2). Une contrainte sur la clé primaire est appelée contrainte de clé (key constraint) et fournit une valeur unique, attribue une valeur par défaut à une colonne si aucune n'est spécifiée, et vérifie les conditions prédéfinies avant d'insérer les données.

Numéro_d'immatriculation	Numéro_de_série_du_moteur	Marque	Modèle	Année
Texas ABC-739	A69352	Ford	Mustang	02
Florida TVP-347	B43696	Oldsmobile	Cutlass	05
New York MPO-22	X83554	Oldsmobile	Delta	01
California 432-TFY	C43742	Mercedes	190-D	99
California RSK-629	Y82935	Toyota	Camry	04
Texas RPN-624	U028365	Jaguar	XJS	04

Tableau 8.2 Exemple de clé primaire dans une table de voitures pour un SGBDR La clé primaire dans une table est généralement soulignée.

Langage de requête structuré

Le langage déclaratif utilisé pour gérer et interroger les données structurées (structured data) dans un SGBDR est appelé Structured Query Language (SQL). SQL implémente les quatre sous-langages mentionnés précédemment : DDL, DML, DQL et DCL. SQL est basé sur l'algèbre relationnelle avec de nombreuses extensions. SQL prend en charge les clés primaires, les clés étrangères, l'insertion de données, la suppression de données, la mise à jour de données, l'indexation, la récupération, la concurrence et la sécurité. SQL se concentre sur l'efficacité en plus de spécifier les données nécessaires. Les principales commandes en SQL sont CREATE TABLE, qui est utilisée pour créer une nouvelle table dans une base de données, comme par exemple :

CREATE TABLE Student (
    ID int,
    LastName varchar(255),
    ZipCode int
);

qui créera une table nommée Student avec trois colonnes : ID, LastName et ZipCode. DROP TABLE est utilisée pour supprimer une table existante dans une base de données, et ALTER TABLE, qui est utilisée pour ajouter, supprimer ou modifier des colonnes dans une table existante. Les schémas SQL contiennent des tables (c'est-à-dire des relations), et le catalogue du SGBDR stocke ces schémas. Les contraintes SQL sont utilisées pour spécifier des règles pour les données d'une table afin d'assurer l'exactitude et la fiabilité de ces données. Il existe des fonctionnalités supplémentaires de SQL telles que les déclencheurs (triggers), les vues, les requêtes imbriquées/récursives, les privilèges et les métadonnées (metadata).

Algèbre relationnelle

Le cadre théorique pour l'interrogation de bases de données relationnelles qui utilise des opérateurs unaires et binaires sur des relations pour manipuler et récupérer des n-uplets est appelé algèbre relationnelle (relational algebra). L'ensemble suivant d'opérations d'algèbre relationnelle est un ensemble complet : Sélection, Projection, Union, Renommage, Différence et Produit cartésien. C'est un ensemble complet car toute opération d'algèbre relationnelle peut être exprimée comme une séquence d'opérations de cet ensemble.

Les opérateurs d'algèbre relationnelle incluent les opérateurs d'ensemble et les opérateurs relationnels. Les opérateurs d'ensemble incluent Union, Intersection, Différence et Produit, qui sont tous des opérateurs binaires car ils utilisent deux relations comme opérandes et produisent une nouvelle relation en résultat. Dans certains cas, les relations opérandes doivent être compatibles en union, ce qui implique qu'elles ont le même nombre de types d'attributs définis sur les mêmes domaines. Dans ce qui suit, nous représentons une relation par R et sa cardinalité ou nombre de n-uplets par |R|.

Opérateur Union

L'opérateur Union appliqué à deux relations P et Q compatibles en union donne une nouvelle relation $R = P \cap Q$ telle que :

$R = {t | t \in P O R t \in Q}$ avec $\max (|P|, |Q|) \leq |R| \leq |P| + |Q|$

La relation résultante R est constituée des n-uplets qui appartiennent soit à P, soit à Q, soit aux deux. Les n-uplets en double sont éliminés.

Opérateur Intersection

L'opérateur Intersection appliqué à deux relations P et Q compatibles en union donne une nouvelle relation $R = P \cap Q$ telle que :

$R = {t | t \in P A N D t \in Q}$ avec $0 \leq |R| \leq min (|P|, |Q|)$

La relation résultante R est constituée des n-uplets qui appartiennent à la fois à P et à Q.

Opérateur Différence

L'opérateur Différence appliqué à deux relations P et Q compatibles en union donne une nouvelle relation $R = P - Q$ telle que :

$R = {t | t \in P A N D t \notin Q}$ avec $0 \leq |R| \leq |P|$

La relation résultante R est constituée des n-uplets qui appartiennent à P mais pas à Q. Notez que lors de l'utilisation de l'opérateur Différence, l'ordre des opérandes est important car il s'agit d'une opération non commutative.

Opérateur Produit

L'opérateur Produit (également connu sous le nom de produit cartésien, produit croisé ou opérateur de jointure croisée) renvoie le produit cartésien de deux relations. Considérons les deux relations suivantes : une relation fournisseur P et une relation produit Q. Le produit cartésien des deux relations est constitué de toutes les combinaisons possibles de n-uplets de P et Q. La relation résultante $R = P \times Q$ est constituée d'un ensemble de n-uplets $r = pq$ tels que :

$R = {r = p q | p \in P A N D q \in Q}$ avec $|R| = |P| \times |Q|$

Les opérateurs relationnels sont Sélection, Projection, Renommage, Jointure et Division. Les opérateurs Sélection, Projection et Renommage sont des opérateurs unaires car ils n'utilisent qu'un seul opérande. Les opérateurs Jointure et Division sont des opérateurs binaires car ils utilisent deux opérandes.

Opérateur Sélection

L'opérateur Sélection est utilisé pour renvoyer un sous-ensemble de n-uplets d'une relation basé sur une condition de sélection. Cette dernière peut consister en des prédicats combinés à l'aide d'opérateurs booléens (et, ou, non). Chaque prédicat consiste en une comparaison entre les valeurs de deux types d'attributs compatibles avec le domaine, ou entre un type d'attribut et une valeur constante du domaine du type d'attribut.

Le résultat de l'application d'un opérateur Sélection avec une condition de sélection S sur une relation P peut être représenté comme suit :

$R = σ_{S} (P)$ avec l'opérateur Sélection $σ$

Opérateur Projection

L'opérateur Projection est utilisé pour projeter une relation sur une liste de types d'attributs. Le résultat de l'application d'un opérateur Projection avec une liste L sur une relation P peut être représenté comme suit :

$R = π_{L} (P)$ avec l'opérateur Projection $π$

Notez que l'application d'un opérateur Projection à une relation entraîne un sous-ensemble vertical de la relation avec $|R| \leq |P|$ car les n-uplets en double seront éliminés.

Opérateur Renommage

L'opérateur Renommage est utilisé pour renommer un type d'attribut d'une relation (au cas où, par exemple, des conflits de noms pourraient survenir). Le résultat de l'application d'un opérateur Renommage sur une relation P pour renommer le type d'attribut B en A peut être représenté comme suit :

$R = ρ_{A|B} (P)$ avec l'opérateur Renommage ρ

Opérateur Jointure

L'opérateur Jointure permet de combiner les n-uplets de deux relations basées sur des conditions spécifiques, également appelées conditions de jointure. Le résultat d'une jointure est l'effet combiné d'un produit cartésien (×) et d'une sélection. Le résultat de l'application d'un opérateur Jointure à deux relations P et Q avec la condition de jointure j peut être représenté comme suit :

$R = P ⋈_{j} Q$ avec l'opérateur Jointure ⋈ et la condition de jointure j.

La relation résultante R est constituée d'un ensemble de combinaisons de n-uplets pq tels qu'un n-uplet combiné r ∈ R est caractérisé par :

$R = {r = p q | p \in P A N D q \in Q A N D j}$ avec $|R| \leq |P| \times |Q|$

Opérateur Division

L'opérateur Division est un opérateur binaire qui divise une relation P par une relation Q avec $Q \subseteq P$ . Le résultat d'un opérateur Division peut être représenté comme suit :

$R = P \div Q$ avec l'opérateur Division ÷

La relation résultante R inclut tous les n-uplets qui appartiennent à P combinés avec chaque n-uplet de Q. Notez que l'opérateur Division n'est pas directement implémenté en SQL.

Les opérateurs Sélection (σ), Projection (π), Différence (–), Produit (×) et Union (∪) sont souvent appelés les cinq opérateurs primitifs car tous les autres opérateurs d'algèbre relationnelle peuvent en être dérivés (opérateurs dérivés).

SQL permet également les fonctions d'agrégation et les opérations de regroupement. Pour les opérations de jointure, il existe de nombreuses options, telles que les suivantes :

Une jointure thêta (theta join) permet de fusionner deux tables basées sur une condition thêta ; thêta (θ) fait référence à l'opérateur de comparaison dans la condition de jointure. Selon thêta, ces jointures peuvent être distinguées : jointure supérieure à, jointure inférieure à, jointure supérieure ou égale à, jointure inférieure ou égale à, et une équi-jointure (si un égal se produit). Une équi-jointure (equi-join) combine des tables basées sur des valeurs correspondantes dans des colonnes spécifiées ; elle est équivalente à une jointure thêta, thêta étant l'opérateur de comparaison d'égalité dans la condition de jointure.
Une jointure naturelle (natural join) crée une jointure implicite basée sur les colonnes communes de deux tables ; c'est une variante de l'équi-jointure dans laquelle l'un des types d'attributs de jointure partagés est supprimé du résultat.
Une jointure interne (inner join) représente l'intersection de deux tables ; toutes les jointures discutées jusqu'à présent sont des jointures internes car elles n'incluent pas de n-uplets sans valeurs de jointure correspondantes dans le résultat.
Une jointure externe (outer join) représente l'union de deux tables ; l'opérateur de jointure externe inclura également les n-uplets sans valeurs de jointure correspondantes dans le résultat.

Une distinction peut être faite entre une jointure externe gauche, une jointure externe droite et une jointure externe complète. Une jointure externe gauche inclut tous les n-uplets de la relation gauche (P) dans le résultat, soit appariés à un n-uplet correspondant de la relation droite (Q) basé sur la condition de jointure, soit augmentés de valeurs nulles si aucune correspondance avec un n-uplet de Q ne peut être établie. Une jointure externe gauche peut être représentée par $R = P ⋈_{j} Q$ . Une jointure externe droite inclut tous les n-uplets de la relation droite (Q) dans le résultat, soit appariés à un n-uplet correspondant de la relation gauche (P) basé sur la condition de jointure, soit augmentés de valeurs nulles si aucune correspondance avec un n-uplet de P ne peut être établie. Une jointure externe droite peut être représentée par $R = P ⋈_{j} Q$ . Une jointure externe complète inclut tous les n-uplets de P et Q dans le résultat, soit appariés à leurs homologues selon la condition de jointure, soit augmentés de valeurs nulles si aucune correspondance ne peut être trouvée. Une jointure externe complète peut être représentée par $R = P ⋈_{j} Q$ .

Un exemple de représentation de structure de données pour l'expression d'algèbre relationnelle est un arbre de requêtes (query tree).

Calcul relationnel de n-uplets et calcul relationnel de domaines

Dans une base de données relationnelle, un n-uplet (tuple) est une ligne avec une collection de valeurs séparées par une virgule et enfermées entre parenthèses. Un exemple de n-uplet en Python représente l'employé Smith, son numéro de téléphone, son âge et son code postal.

tuple = {'Smith', 8882355151, 50, 48505}

Les données à l'intérieur d'un n-uplet peuvent être de n'importe quel type, comme un entier, une chaîne de caractères, une valeur flottante ou un type de n-uplet.

Le calcul relationnel de n-uplets utilise des variables de n-uplets comme éléments constitutifs clés. Une variable de n-uplet fait référence à un n-uplet d'une relation correspondante (également appelée relation de portée). Une expression de calcul relationnel de n-uplets spécifie une relation de portée pour chaque variable de n-uplet, une condition pour sélectionner (des combinaisons de) n-uplets, et une liste de types d'attributs à partir desquels les valeurs doivent être récupérées. En conséquence, une expression de calcul relationnel de n-uplets se présente comme suit :

{t(A_i) | Cond(t)}

où t représente la variable de n-uplet, A_i le type d'attribut dont la valeur doit être récupérée, et Cond(t) la relation de portée et les conditions supplémentaires pour sélectionner les n-uplets pertinents. Considérons l'exemple suivant :

{t.StudentID, t.StudentName | Student(t) AND t.StudentProgram = 3}

Une condition est spécifiée à l'aide d'une formule (de calcul) bien formée (wff), qui peut consister en divers atomes de calcul de prédicats combinés à l'aide d'opérateurs booléens (et, ou, non). Le résultat de l'application d'une formule à un n-uplet d'une relation de portée peut être vrai, faux ou inconnu. Si le résultat est vrai, le n-uplet sera sélectionné dans le résultat. Le calcul relationnel inclut également des quantificateurs tels que le quantificateur existentiel (∃ ou EXISTS) et le quantificateur universel (∀ ou FOR ALL). Une formule avec un quantificateur existentiel (∃) est évaluée à vrai si au moins un n-uplet la satisfait. Une formule avec un quantificateur universel (∀) est évaluée à vrai si chaque n-uplet de la relation de portée satisfait les conditions énoncées.

Au lieu de variables de n-uplets, le calcul relationnel de domaines définit des variables de domaines qui s'étendent sur des valeurs uniques de domaines de types d'attributs. Une expression de calcul de domaines pour une relation de degré n se présente comme suit :

₁, v₂, …v_n, | COND(v₁, v₂, …v_n) }{v1, v2, …vn, | COND(v1, v2, …vn) }

où v₁, v₂, …v_n représentent les variables de domaines qui s'étendent sur les domaines des types d'attributs, et COND représente les conditions supplémentaires.

La requête de calcul relationnel de n-uplets précédente sélectionnant l'ID d'étudiant et le nom d'étudiant de tous les étudiants qui étudient dans le programme numéro 3 se présenterait maintenant comme suit :

{ab| ∃(e) (Student(abcde) AND e = 3)}

Dans ce cas, nous avons défini cinq variables de domaine : a pour le domaine de StudentID, b pour le domaine de StudentName, c pour le domaine de StudentAddress, d pour le domaine de StudentCity, et e pour le domaine de StudentProgram. La condition e = 3 est une condition de sélection.

Le quantificateur existentiel (∃ ou EXISTS) et le quantificateur universel (∀ ou FOR ALL) sont également pris en charge dans le calcul relationnel de domaines.

Langage d'interrogation par l'exemple (QBE)

Le langage de base de données (database language) relationnel basé sur le calcul relationnel de domaines est appelé interrogation par l'exemple (QBE) (query-by-example (QBE)). Les requêtes QBE sont exprimées via un langage de requête graphique, utilisant des tables visuelles où l'utilisateur entre des commandes, des éléments d'exemple et des conditions. Un analyseur syntaxique convertit les requêtes graphiques QBE en instructions exprimées dans un langage de manipulation de base de données, tel que SQL.

Conception logique

Le processus de conception logique (logical design) implique la conception d'une base de données basée sur un modèle de données (data model) spécifique mais indépendant des détails physiques. La conception logique pour un SGBDR inclut des spécifications pour les tables, les relations et les contraintes. La conception logique est réalisée en quatre étapes : mapper le modèle conceptuel aux composants du modèle logique, valider le modèle logique à l'aide de la normalisation, valider les contraintes du modèle logique et valider le modèle logique par rapport aux exigences de l'utilisateur.

Pour déterminer la qualité de la conception du schéma de relation, nous suivons les directives de conception informelles pour les schémas relationnels et utilisons des mesures de qualité simples telles que s'assurer que la sémantique des attributs est claire, réduire les informations redondantes et réduire les valeurs nulles. Les valeurs nulles entraînent un travail redondant, ce qui gaspille de l'espace de stockage et augmente la difficulté d'effectuer des opérations.

Lien avec le quotidien

SGBDR

Les avions doivent être conçus et testés pour la sécurité. Les ailes d'avion sont des éléments complexes qui comprennent un grand nombre de pièces, se présentent sous diverses formes (par exemple, ailes rectangulaires pour petits avions, ailes elliptiques, ailes effilées et ailes trapézoïdales), et nécessitent la collaboration de plusieurs concepteurs pour leur conception. Les ailes d'avion sont généralement conçues à l'aide de systèmes logiciels de conception assistée par ordinateur (CAO) qui utilisent des systèmes de gestion des données (data management) pour stocker et récupérer les données.

Un SGBDR est-il la meilleure solution pour stocker et récupérer ce type d'éléments ? Pourquoi ou pourquoi pas ? Existe-t-il d'autres moyens, meilleurs, de suivre le développement, la conception et les tests de pièces mécaniques cruciales pour la sécurité des passagers ?

Contraintes du modèle relationnel

Les contraintes qui garantissent l'exactitude de la base de données sont appelées contraintes du modèle relationnel dans les SGBD. Les différents types de contraintes sont les contraintes de domaine, d'unicité, de clé et d'intégrité d'entité. La contrainte de domaine (domain constraint) définit le domaine des valeurs pour un attribut. La contrainte d'unicité (uniqueness constraint) spécifie que tous les n-uplets doivent être uniques. La contrainte de clé (key constraint) spécifie que toutes les valeurs de la clé primaire doivent être uniques. La contrainte d'intégrité d'entité (entity integrity constraint) spécifie qu'aucune clé primaire ne contient de valeur nulle. De plus, la dépendance fonctionnelle (FD) (functional dependency (FD)) est une contrainte qui spécifie la relation entre deux ensembles d'attributs et fournit un outil formel pour l'analyse des schémas relationnels. Les DF permettent la détection et la description des règles métier en termes précis. Les DF peuvent être utilisées pour aider à normaliser les schémas relationnels. Une dépendance multivaluée (MVD) (multivalued dependency (MVD)) se produit lorsque deux attributs d'une table sont indépendants l'un de l'autre mais dépendent tous deux d'un troisième attribut. Les MVD sont nécessaires pour atteindre des formes de normalisation plus élevées (par exemple, 4NF). Le processus de normalisation peut être automatisé à l'aide d'algorithmes capables de convertir une relation donnée en ensembles de relations dans une forme normale donnée.

Normalisation

Le processus de structuration d'une base de données relationnelle pour réduire la redondance des données (data redundancy) et améliorer l'intégrité des données est appelé normalisation de base de données (database normalization). Une forme normale s'applique à une table/relation, pas à la base de données. Les principaux types de normalisation sont

première forme normale (1NF),
deuxième forme normale (2NF),
troisième forme normale (3NF),
forme normale de Boyce-Codd (BCNF), et
quatrième forme normale (4NF).

Il existe des formes normales supplémentaires, qui sont plus complexes. Chaque cellule en 1NF doit contenir une seule valeur (atomique) et chaque colonne doit être nommée de manière unique. Le modèle relationnel exige que les tables soient en forme 1NF ; les tables en 2NF doivent être en 1NF et ne pas avoir de dépendance partielle. Les tables en 3NF doivent être en 2NF et n'avoir aucune dépendance fonctionnelle transitive. BCNF est une version supérieure de la 3NF et est utilisée pour traiter les anomalies. Les tables en 4NF doivent être en BCNF/3NF et n'avoir pas de MVD. L'exemple suivant convertit une table en 1NF, 2NF, puis 3NF. Le Tableau 8.3 contient les données originales, qui sont ensuite converties en 1NF (Tableau 8.4), 2NF (Tableau 8.5), et 3NF (Tableau 8.6, Tableau 8.7, et Tableau 8.8). Il est supposé ici que le Nom du Client est un attribut composite qui contient le Prénom et le Nom de famille et doit donc être décomposé en ses attributs composants pour être stocké dans une table relationnelle qui satisfait la 1NF.

Nom du client	Article 1	Article 2
Shirl Adam	Milk	Bread
Jeff Mark	Juice	Water
Rana Park	Bread	Milk

Tableau 8.3 Table de données

Prénom	Nom de famille	Article 1	Article 2
Shirl	Adam	Milk	Bread
Jeff	Mark	Juice	Water
Rana	Park	Bread	Milk

Tableau 8.4 Table convertie en 1NF

Prénom	Nom de famille	Article
Shirl	Adam	Milk
Shirl	Adam	Bread
Jeff	Mark	Juice
Jeff	Mark	Water
Rana	Park	Bread
Rana	Park	Milk

Tableau 8.5 Table convertie en 2NF

ID Client	Prénom	Nom de famille
1	Shirl	Adam
2	Jeff	Mark
3	Rana	Park

Tableau 8.6 Table convertie en 3NF : Client

ID Article	Article
1	Milk
2	Bread
3	Juice
4	Water

Tableau 8.7 Table convertie en 3NF : Article

ID Client	ID Article
1	1
1	2
2	3
2	4

Tableau 8.8 Table convertie en 3NF : Table relationnelle

Conception de bases de données relationnelles

La modélisation des données en un ensemble de tables avec des lignes et des colonnes est appelée conception de base de données relationnelle (RDD) (relational database design (RDD)). Chaque ligne représente un enregistrement, et chaque colonne représente un attribut. La RDD comprend cinq phases :

Phase d'analyse des exigences pour évaluer les besoins informationnels d'une organisation.
Phase de conception logique pour créer un modèle conceptuel (entité-relation [ER]) basé sur la phase 1. L'ER décrit des attributs interdépendants dans un domaine de connaissance spécifique.
Phase de conception physique pour maximiser l'efficacité de la base de données (Unified Modeling Language [UML]). UML aide les développeurs à visualiser les relations entre les différentes pièces.
Phase d'implémentation pour convertir les tables développées dans le diagramme ER en SQL.
Phase de surveillance et de maintenance pour s'assurer que le SGBDR fonctionne correctement.

Lien avec les carrières

SGBDR et secteur bancaire

Les SGBDR sont idéaux dans les applications bancaires pour suivre et stocker les numéros de compte, les commandes et les paiements. La plupart des banques utilisent des applications Oracle en raison de la puissante intégration de la technologie et des applications métier. Oracle inclut des fonctionnalités intégrées conçues spécifiquement pour les banques, telles que la plateforme bancaire Oracle, qui est le choix principal pour les banques cherchant à modifier leurs systèmes centraux pour une banque de détail centrée sur le client.

Mappage d'un modèle EER conceptuel à un modèle relationnel

Après avoir conçu le diagramme ER, nous devons le convertir en modèles relationnels qui peuvent être directement implémentés par n'importe quel SGBDR. La modélisation ER aide à créer un modèle conceptuel qui repose sur les entités et leurs interrelations. Le degré d'une relation établit le nombre d'entités qu'elle interrelie. Par conséquent, les relations peuvent être unaires, binaires, ternaires et plus généralement n-aires.

Les ratios de cardinalité sont utilisés pour spécifier le nombre de n-uplets interreliés dans le cadre d'une relation binaire (binary) (c'est-à-dire 1-1, 1-N, N-1, M-N).

Les attributs multivalués sont autorisés dans les modèles ER. Ils sont utilisés pour représenter un attribut qui contient une liste de valeurs. Par exemple, une entité voiture peut avoir un attribut couleur qui est multivalué et inclure une liste de toutes les couleurs de voiture.

Dans la modélisation ER, une entité faible (weak entity) est un type d'entité qui ne peut pas être identifié de manière unique sur la base de ses seuls attributs et doit s'appuyer sur une entité forte pour fournir le contexte nécessaire à l'identification. Par exemple, un employé d'une entreprise peut avoir des personnes à charge pour les besoins de l'assurance maladie. Dans ce cas, une entité dépendante est une entité faible et l'ID de l'employé, qui est l'entité forte, doit être utilisé pour identifier pleinement une personne à charge.

Les étapes suivantes doivent être suivies pour mapper un modèle EER à un modèle relationnel :

Mappage des types d'entités régulières. Créez une table qui inclut tous ses attributs simples et sélectionnez l'un des attributs clés comme clé primaire. Si la clé choisie provient d'un attribut composite dans le modèle EER, l'ensemble correspondant d'attributs simples formera ensemble la clé primaire.
Mappage des types d'entités faibles. Pour chaque entité faible, créez une table qui inclut tous ses attributs simples, et incluez les attributs qui composent la clé de l'entité forte associée. La clé primaire dans ce cas est la combinaison de la clé primaire de l'entité forte associée et de la clé partielle de l'entité faible, le cas échéant.
Mappage des types de relations binaires 1:1. Une solution consiste à créer une relation pour chaque entité participante, à choisir une clé primaire dans l'une des deux relations, et à créer une clé étrangère référençant la clé primaire dans la seconde relation. Dans certains cas, il est plus approprié de fusionner les deux relations (des entités participantes) en une seule, ou de créer une référence croisée (c'est-à-dire une relation de relation) entre les deux relations.
Mappage des types de relations binaires 1:N. Créez une relation pour chaque entité participante. La clé primaire du côté "un" de la relation est ajoutée au côté "plusieurs" comme clé étrangère. Une approche alternative consiste à utiliser une relation de relation, mais cela est rarement fait.
Mappage des types de relations binaires M:N. Créez une relation pour chaque entité participante. Créez également une relation de relation et incluez comme attributs de clés étrangères les clés primaires des relations qui représentent les types d'entités participantes. Leur combinaison formera la clé primaire de la relation de relation.
Mappage des attributs multivalués. Pour chaque attribut multivalué, créez une nouvelle relation qui inclut un attribut correspondant à l'attribut multivalué (dans le type d'entité original) et incluez comme clé étrangère la clé primaire de la relation qui représente l'entité qui inclut l'attribut multivalué. La clé primaire dans la nouvelle relation créée est la combinaison de l'attribut qui correspond à l'attribut multivalué (dans le type d'entité original) et de la clé étrangère.
Mappage des types de relations n-aires. Créez des relations de relation pour chaque relation n-aire et incluez comme attributs de clés étrangères les clés primaires des relations qui représentent les types d'entités participantes.
Mappage de la spécialisation ou de la généralisation. Convertissez chaque spécialisation avec m sous-classes {S₁, S₂, . . . , S_m} et une super-classe généralisée C, où les attributs de C sont {k, a₁, . . . a_n} et k est la clé (primaire), en schémas relationnels en utilisant l'une des quatre options suivantes : Option 8A : Relations multiples - Super-classe et sous-classes ; Option 8B : Relations multiples - Relations de sous-classes uniquement ; Option 8C : Relation unique avec un attribut de type ; Option 8D : Relation unique avec plusieurs attributs de type.
Mappage des types d'union. Pour le mappage d'une catégorie dont la super-classe définissante a des clés différentes, il est d'usage de spécifier un nouvel attribut de clé, appelé clé de substitution, lors de la création d'une relation correspondant à la catégorie.

Conception physique

L'attribution de concepts logiques à des constructions physiques est appelée conception physique de base de données (physical database design). L'entrée de l'étape de conception physique est une représentation logique du système. C'est une responsabilité conjointe du concepteur de bases de données (database designer) et de l'administrateur de base de données (DBA). La principale responsabilité de la conception physique est d'optimiser les performances tout en garantissant l'intégrité des données. Les principaux problèmes abordés dans la conception physique sont les supports de stockage, les structures de fichiers et les index. La base de données est stockée sur un disque à l'aide d'un système de fichiers "standard", et non d'un système "adapté" à la base de données. La base de données fonctionne sur un système d'exploitation généraliste non modifié.

Stockage sur disque et structures de fichiers de base

Les tables de base de données sont stockées dans le stockage sur disque (disk storage) — qui est le dispositif de mémoire qui stocke les données — tels que les disques durs, la mémoire flash, les disques magnétiques, les disques optiques et les bandes, comme le montre la Figure 8.9. Les enregistrements dans les tables peuvent être de longueur fixe, ce qui signifie que les enregistrements ont exactement la même longueur, ou de longueur variable, ce qui signifie que les enregistrements diffèrent par leur longueur. Tous les enregistrements sont classés en blocs, et la longueur de l'enregistrement peut dépasser la taille d'un bloc, ce qui est appelé un enregistrement étendu (spanned record). Supposons que chaque relation est stockée comme un fichier et que chaque n-uplet est un enregistrement dans le fichier. Les fichiers peuvent être ordonnés (c'est-à-dire que les enregistrements sont séquencés sur un certain champ) ou non ordonnés (c'est-à-dire que les enregistrements ne sont pas dans un ordre particulier). Le temps d'accès moyen à un enregistrement est le temps moyen nécessaire à un système pour accéder à l'enregistrement. Une grappe redondante de disques indépendants (RAID) (redundant array of inexpensive disks (RAID)) stocke les informations sur une grappe de disques durs à faible coût.

Diagramme en triangle. Stockage primaire de haut en bas : registres CPU, caches, stockage central. Une limite d'E/S sépare le milieu. Stockage secondaire dans la moitié inférieure : HDD, SSD et bande, supports optiques.

Figure 8.9 Cette hiérarchie de stockage inclut le stockage primaire et secondaire. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Organisation physique des fichiers et indexation

L'organisation des fichiers et l'indexation sont utilisées pour minimiser le nombre d'accès aux blocs pour les requêtes fréquentes. Il existe de nombreux types d'organisation de fichiers, les plus populaires étant l'organisation séquentielle, relative et indexée. Dans une organisation séquentielle de fichiers (sequential file organization), les enregistrements sont organisés dans l'ordre où ils sont stockés et tout nouvel enregistrement est ajouté à la fin. Dans une organisation relative (relative organization), chaque enregistrement se voit attribuer une clé numérique pour réorganiser l'ordre des enregistrements à tout moment. Similaire à l'organisation relative, l'organisation indexée (indexed organization) utilise une clé, mais la clé est unique et fixe. De plus, il existe de nombreux autres types d'organisation de fichiers tels que l'organisation de fichiers par tas (heap), par hachage (hash), B+ et grappe (cluster). Un tas (heap) dans l'organisation de fichiers fait référence à une collection non ordonnée d'enregistrements où les nouveaux enregistrements sont placés là où il y a de l'espace libre, et aucun ordre particulier n'est imposé. La Figure 8.10 montre un exemple d'organisation de fichier par tas.

Illustration représentant les enregistrements à gauche et les blocs de données en mémoire à droite (Blocs 1-4). Un nouvel enregistrement est montré en cours d'insertion dans un bloc de données en mémoire.

Figure 8.10 Cet exemple d'organisation de fichier par tas montre comment insérer un nouvel enregistrement (enregistrement 4) dans les blocs de données en mémoire. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Organisation physique de la base de données

Un espace de table (tablespace) est l'endroit où les tables sont stockées physiquement en mémoire (c'est-à-dire le conteneur physique des objets de base de données). L'utilisation des espaces de table a un impact sur la conception physique de la base de données concernant le parallélisme intra-requête, où différents sous-ensembles de données peuvent être recherchés en parallèle pour une requête complexe, et le parallélisme inter-requêtes (c'est-à-dire de nombreuses requêtes simples exécutées en parallèle).

Concepts d'exécution de requêtes

Le traitement de la requête comprend cinq étapes :

analyse syntaxique : vérification de la syntaxe de la requête, des privilèges de l'utilisateur, des noms de tables et d'attributs
traduction (translation) : traduction d'un langage de haut niveau vers le langage machine
optimiseur (optimizer) : sélection du meilleur plan à exécuter
exécution (execution) : exécution du plan sélectionné
évaluation (evaluation) : renvoi du résultat de la requête

L'optimiseur de requêtes détermine la stratégie la moins coûteuse pour l'exécution des requêtes en utilisant les représentations internes d'une requête (c'est-à-dire l'arbre de requêtes et le graphe de requêtes). La technique mathématique pour traiter rapidement la requête est appelée optimisation heuristique (heuristics optimization). La principale heuristique consiste à appliquer d'abord les opérations qui réduisent la taille des résultats intermédiaires.

Conception physique et réglage de la base de données

Supposons que vous recherchiez un enregistrement spécifique dans une énorme base de données et que l'enregistrement que vous recherchez se trouve à la fin. Pour récupérer cet enregistrement, le système se déplace séquentiellement enregistrement par enregistrement et prend beaucoup de temps à traiter. Suivons cet exercice SQL en utilisant le Tableau 8.9.

Employé
Numéro	Prénom	Nom	Pays
1	Sam	Smith	USA
2	Adam	Bell	UK
3	Matt	John	USA
4	John	Zack	USA
5	Andy	Dave	UK

Tableau 8.9 Table Employé

Nous recherchons « Andy » à l'aide de l'instruction SQL suivante :

SELECT * FROM employee WHERE Fname = 'Andy';

La recherche d'Andy prend cinq comparaisons car Andy se trouve à la fin de la table. Cependant, si nous trions les données par ordre alphabétique (Tableau 8.10), la recherche d'un nom est plus rapide (deux comparaisons).

Employé_tri
Prénom	Nom	Index
Adam	Bell	2
Andy	Dave	5
John	Zack	4
Matt	John	3
Sam	Smith	1

Tableau 8.10 Table de tri des employés

Un index contient le champ trié et pointe de chaque enregistrement vers l'enregistrement correspondant où les données sont stockées (Figure 8.11).

Les tables Employee_sort et Employee sont visibles avec des flèches reliant la colonne Index de la table Employee_sort au numéro dans la table Employee.

Figure 8.11 L'utilisation de l'indexation peut améliorer les performances des requêtes. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

L'indexation contribue à améliorer les performances du processus de requête. La création d'un index en SQL permet de récupérer les données de la base de données plus rapidement. Voici les syntaxes SQL pour créer un index et créer un index unique. Notez qu'un index UNIQUE (UNIQUE) fait référence à un index où toutes les lignes de l'index doivent être uniques. C'est-à-dire qu'une ligne ne peut pas avoir des valeurs non nulles identiques pour toutes les colonnes de cet index qu'une autre ligne.

CREATE INDEX index_name ON table_name (column1, ...);
CREATE UNIQUE INDEX index_name ON table_name (column1, ...);

De plus, vous pouvez supprimer l'index à tout moment en utilisant l'instruction drop :

DROP INDEX index_name ON table_name;

Une clé est nécessaire pour indexer un attribut ; cependant, un index peut être construit avec un ou plusieurs attributs. Si une table nécessite plus d'un index, nous devons décider quel attribut nous regroupons. Dans les cas généraux, l'indexation est implémentée à l'aide d'arbre binaire (binary tree), d'arbre B (B-tree), ou d'arbre B+ (B+ tree). En pratique, les arbres B+ sont plus couramment utilisés dans les systèmes de bases de données. Un arbre binaire est un arbre dans lequel chaque nœud a jusqu'à deux enfants. Un arbre B généralise l'arbre binaire avec plus de deux enfants et peut avoir un seul enfant. Un arbre B+ est un arbre avec un grand nombre d'enfants par nœud, mais dans certains cas, il est plus efficace d'utiliser l'indexation par hachage (par exemple, les conditions d'égalité). La base de données normalisée est la base de données qui élimine la redondance des données (data redundancy) pour améliorer l'intégrité des données dans la table. La dénormalisation est une stratégie visant à augmenter les performances d'une base de données normalisée. Elle ajoute des données redondantes telles que des attributs supplémentaires, ajoute de nouvelles tables ou crée des instances. L'objectif principal est de réduire le temps d'exécution des requêtes en rendant les données plus accessibles.

Questions de réflexion

Le modèle relationnel et les constructeurs

Le modèle relationnel utilise deux types de constructeurs. L'un est « agrégat de », qui permet la création de tables en agrégeant diverses colonnes contenant des données de différents types. L'autre est « ensemble de », qui permet de regrouper plusieurs enregistrements au sein d'une table.

Y a-t-il une limitation à cette approche ?

API et techniques de programmation des SGBDR

Une architecture de base de données (database architecture) est une représentation de la conception qui aide à concevoir, développer, implémenter et maintenir le SGBD. Cette section couvre les architectures SGBDR, les API de bases de données, la persistance d'objet (object persistence) et les mappages objet-relationnel (ORM), ainsi que des exemples d'applications SGBDR.

Architectures des SGBDR

Une architecture de système de gestion de bases de données relationnelles (SGBDR) est catégorisée comme une architecture de système centralisé et une architecture de système à plusieurs niveaux. Dans une architecture de système centralisé, les responsabilités du SGBD sont gérées par une entité centralisée — la base de données sur mainframe, qui est devenue rare, coûteuse et difficile à maintenir. Les architectures de systèmes à plusieurs niveaux visent à découpler la configuration centralisée en combinant les capacités de calcul des ordinateurs centraux puissants avec la flexibilité des ordinateurs personnels (PC).

Il existe plusieurs variantes de l'architecture de système à plusieurs niveaux, telles que l'architecture à deux niveaux ou l'architecture client-serveur. La variante client lourd (fat client variant) est celle où la logique de présentation et la logique d'application sont gérées par le client et est courante dans les cas où il est logique de coupler le flux de travail d'une application avec son apparence ; dans ce cas, le SGBD s'exécute désormais entièrement sur le serveur de base de données. Une variante client léger (thin client variant) est celle où seule la logique de présentation est gérée par le client et où les applications et les commandes de base de données sont exécutées sur le serveur ; elle est courante lorsque la logique d'application et la logique de base de données sont étroitement couplées ou similaires. L'architecture à trois niveaux découple la logique d'application du SGBD et la place dans une couche séparée (c'est-à-dire le serveur d'applications). Remarque : le serveur d'applications ou le serveur de base de données peut être constitué de plusieurs machines physiques distribuées.

API de bases de données

Dans une architecture de système SGBD à plusieurs niveaux, les applications clientes peuvent interroger les serveurs de bases de données et recevoir des résultats. Il est possible d'utiliser des SGBD intégrés (par exemple, SQLite) ou d'accéder à des serveurs SGBD autonomes (par exemple, Postgres). Les applications clientes qui souhaitent utiliser les services fournis par un SGBD utilisent une API spécifique fournie par le SGBD. Cette API de base de données expose une interface par laquelle les applications clientes peuvent accéder et interroger un SGBD. Le serveur de base de données reçoit les appels effectués par les clients et exécute les opérations pertinentes avant de renvoyer les résultats. Dans de nombreux cas, les interfaces client et serveur sont implémentées pour fonctionner sur un réseau informatique à l'aide de sockets réseau. L'objectif principal d'une API de base de données est d'exposer une interface par laquelle d'autres parties peuvent utiliser les services fournis par le SGBD. La plupart des fournisseurs de SGBD proposent une API propriétaire, spécifique au SGBD (l'inconvénient est que les applications clientes doivent connaître le SGBD qui sera utilisé côté serveur). Alternativement, des API universelles génériques, indépendantes des fournisseurs, ont été proposées, et elles permettent de porter facilement des applications vers plusieurs SGBD.

Les API peuvent être embarquées ou de niveau appel. Une API embarquée intègre des instructions SQL dans le langage de programmation hôte, ce qui signifie que les instructions SQL font partie du code source. (Avant que le programme ne soit compilé, un précompilateur SQL analyse les instructions liées à SQL et les remplace par des instructions de code source natives du langage de programmation hôte utilisé. Le code source converti est ensuite envoyé au compilateur réel.) Les API de niveau appel (SQL/CLI) fonctionnent en transmettant des instructions SQL au SGBD au moyen d'appels directs à une série de procédures, fonctions ou méthodes telles que fournies par l'API pour effectuer les actions nécessaires (par exemple, ODBC/JDBC).

Persistance d'objet et mappages objet-relationnel (ORM)

Les technologies d'API telles que JDBC et ADO.NET représentent les entités liées aux bases de données (par exemple, tables, enregistrements) de manière orientée objet (OO). Alors que les entités de domaine simples telles que Livre et Auteur sont représentées comme des objets utilisant les capacités de représentation et la syntaxe d'un langage de programmation, la persistance d'objet garantit que les données d'objet correspondantes sont persistées en arrière-plan vers une base de données ou une autre source de données. Les technologies de requête intégrées au langage appliquent des idées similaires, tandis que les API de persistance d'objet vont plus loin car elles décrivent également le domaine métier complet (c'est-à-dire la définition des entités de données) au sein du langage hôte. Elles permettent une interrogation efficace des objets ; de telles entités sont fréquemment mappées à un modèle de base de données relationnelle à l'aide d'un mappeur objet-relationnel (ORM). Il n'est pas strictement nécessaire d'utiliser un ORM pour activer la persistance d'objet, bien que la plupart des API couplent étroitement les deux concepts.

Exemples d'applications SGBDR

Sur le Web, il existe deux types d'appels : asynchrones et synchrones. Dans l'appel asynchrone (asynchronous call), le client envoie une requête sans attendre de réponse. Dans l'appel synchrone (synchronous call), le client envoie une requête et attend une réponse du service. Les appels API et HTTP sont des exemples d'appels synchrones. Un exemple de base de données entièrement gérée sur le Web est les services de données NoSQL d'Oracle.

Fonctionnalités des SGBDR

Les SGBDR incluent de multiples fonctionnalités telles que la gestion des transactions, le contrôle de concurrence, la distribution des données, la gestion des transactions distribuées, le traitement distribué et parallèle, la récupération et la sécurité.

Gestion des transactions

La plupart des systèmes de bases de données sont multi-utilisateurs. Bien que la gestion des transactions permette un accès concurrentiel aux mêmes données par plusieurs utilisateurs, elle peut induire différents types d'anomalies. En conséquence, des erreurs peuvent survenir dans le SGBD ou son environnement. Les SGBDR doivent s'assurer que les transactions prennent en charge les propriétés ACID (atomicité, cohérence, isolation, durabilité) comme expliqué dans les paragraphes suivants.

Une transaction (transaction) est un ensemble d'opérations de base de données induites par un seul utilisateur ou une application qui doit être considéré comme une unité de travail indivisible (par exemple, un transfert entre deux comptes bancaires du même client). Une transaction réussit ou échoue dans son intégralité.

Une transaction fait passer la base de données d'un état cohérent à un autre état cohérent. Le gestionnaire de transactions supervise l'exécution des transactions de base de données. Une transaction de base de données (database transaction) est une séquence d'opérations de lecture/écriture considérée comme une unité atomique. Le gestionnaire de transactions crée un calendrier avec des opérations de lecture/écriture entrelacées, garantit les propriétés ACID, et peut COMMIT une transaction en cas d'exécution réussie ou ROLLBACK une transaction en cas d'exécution infructueuse. La délimitation des transactions au sein du cycle de vie des transactions est appelée gestion des transactions (transaction management). Divers composants sont impliqués dans la gestion des transactions (c'est-à-dire l'ordonnanceur, le gestionnaire de récupération, le gestionnaire de données stockées et le gestionnaire de tampons), et les SGBDR utilisent un fichier journal pour enregistrer l'état actuel de la transaction (active, validée ou annulée) et faciliter la mise en œuvre de points de contrôle à des fins de restauration.

Contrôle de concurrence

La coordination des transactions qui s'exécutent simultanément sur les mêmes données afin qu'elles ne provoquent pas d'incohérences en raison d'interférences mutuelles est appelée contrôle de concurrence (concurrency control). Un gestionnaire de verrous assure le contrôle de concurrence, ce qui garantit l'intégrité des données à tout moment. Les deux types de verrous sont les verrous de lecture et les verrous d'écriture. Le gestionnaire de verrous est responsable de l'attribution, de la libération et de l'enregistrement des verrous dans le catalogue. Le gestionnaire de verrous utilise un protocole de verrouillage qui décrit les règles de verrouillage, et une table de verrous qui contient les informations de verrouillage. Des problèmes de concurrence surviennent lorsque plusieurs transactions s'exécutent simultanément sans contrôle.

Distribution des données

Le processus de stockage des données sur plusieurs sites pour améliorer la disponibilité des données et les performances de récupération est appelé réplication de données (data replication). Plusieurs bases de données situées sur différents sites peuvent avoir besoin d'être synchronisées en temps réel pour garantir la cohérence et des performances optimales (par exemple, la fragmentation). Il existe différents types de fragmentation :

fragmentation verticale (vertical fragmentation) : consiste en un sous-ensemble de colonnes de données ; la vue globale peut être récupérée avec une requête JOIN ; utile si seuls certains attributs d'un n-uplet sont pertinents pour un nœud
fragmentation horizontale (partitionnement) (horizontal fragmentation (sharding)) : le fragment est constitué de lignes qui satisfont un prédicat de requête ; la vue globale peut être récupérée avec une requête UNION ; courant dans les bases de données NoSQL
fragmentation mixte (mixed fragmentation) : combine la fragmentation horizontale et verticale ; la vue globale peut être récupérée avec une requête JOIN + UNION

Gestion des transactions distribuées

Une transaction distribuée (distributed transaction) est un ensemble d'opérations exécutées sur plusieurs systèmes de bases de données. La gestion des transactions distribuées coordonne les ressources entre plusieurs bases de données. Le gestionnaire de transactions décide de valider ou d'annuler une transaction à l'aide d'une validation en deux phases (2PC) (two-phase commit (2PC)). Les étapes du 2PC sont décrites dans la Figure 8.12.

Système : 1. Requête de transaction distribuée. Base de données A, 2. Requête de préparation à la validation, Base de données B, 3. Réponse de préparation à la validation, Base de données A, 4. Requête de validation. Base de données B, 5. Réponse de validation, Base de données A, 6. Réponse de transaction distribuée, Système.

Figure 8.12 Le protocole de validation en deux phases illustre les six étapes nécessaires pour une transaction distribuée. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Le serveur de gestion des transactions gère les transactions en modes faiblement couplé et fortement couplé. En mode faiblement couplé, les différents serveurs de bases de données coordonnent les transactions sans partager de ressources ; en mode fortement couplé, les ressources sont partagées.

Traitement parallèle et distribué

De nombreuses bases de données, y compris NoSQL, utilisent le traitement parallèle (parallel processing), une technique dans laquelle plusieurs processeurs travaillent simultanément sur différentes tâches ou différentes parties d'une tâche pour permettre le traitement concurrent de grandes quantités de données. Les systèmes de bases de données distribuées distribuent les données et la fonctionnalité de récupération des données sur plusieurs sources de données ou emplacements. Figure 8.13 montre différentes architectures de bases de données distribuées. Dans l'architecture à mémoire partagée, plusieurs processeurs interconnectés qui exécutent le logiciel SGBD partagent le même stockage central et le stockage secondaire. Avec l'architecture à disque partagé, chaque processeur a son stockage central mais partage le stockage secondaire avec d'autres processeurs en utilisant un serveur de stockage en réseau (NAS) (Network Attached Storage (NAS)) ou un réseau de stockage (SAN) (Storage Area Network (SAN)). Dans l'architecture sans partage, chaque processeur a son stockage central et ses unités de disque dur, et le partage des données se fait par la communication des processeurs entre eux sur le réseau.

Illustration du traitement parallèle des tâches de différentes architectures de données distribuées – Architecture à mémoire partagée, architecture à disque partagé et architecture sans partage.

Figure 8.13 Les différentes architectures distribuées sont l'architecture à mémoire partagée, l'architecture à disque partagé et l'architecture sans partage. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

L'extensibilité (Scalability) est la mesure de la capacité d'un système à faire évoluer (augmenter ou diminuer) les performances et/ou les coûts en réponse à tout changement de système. L'extensibilité (Scalability) peut être obtenue par l'extensibilité verticale, où la capacité de chaque nœud peut être augmentée, et l'extensibilité horizontale, où plus de nœuds peuvent être ajoutés. Les bases de données parallèles se concentrent sur la distribution des données pour les performances et le parallélisme intra-requête versus inter-requête. Les bases de données fédérées utilisent des nœuds dans une architecture sans partage, chacun exécutant une instance SGBD indépendante avec une fragmentation horizontale des données.

Dans le traitement des requêtes distribuées, l'optimiseur ne doit pas seulement considérer les éléments d'un environnement autonome, mais aussi les propriétés des fragments respectifs, les coûts de communication et l'emplacement des données dans le réseau. Les métadonnées (Metadata) peuvent également être distribuées, à la fois globalement (sur tous les nœuds) et localement (au sein d'un seul nœud). L'optimisation des requêtes est nécessaire.

Récupération

L'activité consistant à remettre la base de données dans un état cohérent sans aucune perte de données en cas de défaillance ou de survenue d'un problème est appelée reprise de base de données (database recovery). Une défaillance du système se produit lorsqu'un système tombe en panne au milieu d'une transaction, et une défaillance du support se produit lorsqu'un fichier de base de données ou le périphérique stockant le fichier de base de données cesse de fonctionner. Il existe de nombreuses techniques de récupération telles que la mise en miroir en ajoutant deux copies complètes de la base de données, les journaux de transactions en enregistrant les changements des transitions, la pagination fantôme en divisant la base de données en pages, et les sauvegardes. Les sauvegardes sont la méthode la plus utilisée pour la récupération et incluent la sauvegarde immédiate et la sauvegarde d'archivage. Une sauvegarde immédiate (immediate backup) stocke les copies sur des disques, et une sauvegarde d'archivage (archival backup) stocke les données sur différents serveurs/sites.

Sécurité

L'utilisation d'un ensemble de contrôles pour sécuriser les données, garantissant un niveau élevé de confidentialité, est considérée comme la sécurité des bases de données (database security). Les problèmes de sécurité auxquels une base de données est confrontée incluent les erreurs humaines telles que le partage de mots de passe et les mots de passe faibles ; l'injection SQL, qui implique l'utilisation de chaînes d'attaque SQL dans les requêtes de base de données ; les attaques par débordement, qui écrivent une grande quantité de données dans un bloc de mémoire de longueur fixe, provoquant un débordement ; les attaques par déni de service (DoS) (Denial of Service Attacks (DoS)) qui utilisent un grand nombre de requêtes pour faire planter le serveur ; et les attaques internes et externes (Figure 8.14).

Illustration : Un attaquant se connecte à un site web (via un serveur API web) avec une requête SQL malveillante. Les données sont renvoyées via le serveur API web à l'attaquant, ainsi que les données de tous les enseignants.

Figure 8.14 L'injection SQL donne aux attaquants accès à des données client confidentielles telles que les données des enseignants. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Pour sécuriser la base de données, il existe de nombreuses méthodes telles que le contrôle d'accès discrétionnaire, qui peut accorder ou refuser l'accès à un objet en utilisant un ensemble de politiques ; le contrôle d'accès obligatoire, qui restreint la capacité d'accorder ou de refuser l'accès aux objets de ressources ; la sécurité statistique des bases de données, qui se concentre sur la protection des valeurs statistiques stockées dans la base de données ; le chiffrement, qui convertit les données en code secret pour en masquer le vrai sens ; et l'infrastructure à clé publique, qui est un ensemble de rôles et de politiques nécessaires pour gérer la base de données.

Lien vers l'apprentissage

Il existe de nombreux endroits sur Internet où vous pouvez en apprendre davantage sur la programmation et les bases de données. Par exemple, si vous souhaitez créer votre propre site web, vous devrez connaître le langage de requête structuré (SQL), qui est un langage standard pour accéder et manipuler les bases de données. Visitez une introduction au SQL pour vous aider à mieux comprendre SQL, ce que SQL peut faire et comment utiliser SQL lors de la création d'un site web.