Modèle hiérarchique

Un modèle hiérarchique (hierarchical model) est un modèle dans lequel les données sont stockées sous forme d'enregistrements et organisées en une structure arborescente. La structure est parent-enfant et chaque parent peut se connecter à un ou plusieurs nœuds enfants, comme le montre la Figure 8.15. Par exemple, IBM IMS est un système logiciel de gestion de base de données hiérarchique pour l'OLTP.

Figure 8.15 Un modèle hiérarchique montre un parent racine connecté à trois nœuds enfants. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Un modèle hiérarchique présente de nombreuses limitations, telles que la complexité de la navigation dans le système, l'exigence que les données soient stockées de manière répétitive en raison d'une structure arborescente avec un niveau élevé de redondance, et son besoin de recherche séquentielle.

Principes de la persistance d'objet

Lorsqu'un objet n'est pas supprimé tant qu'un besoin n'apparaît pas de le retirer de la mémoire, la persistance d'objet (object persistence) se manifeste. En d'autres termes, l'objet transitoire n'est nécessaire que pendant l'exécution du programme et peut être supprimé lorsque le programme se termine. Les stratégies de persistance incluent la persistance par classe, la persistance par création, la persistance par marquage, la persistance par héritage et la persistance par atteignabilité.

Dans l'orthogonalité de la persistance (persistence orthogonality), l'environnement ne nécessite aucune action d'un programme pour récupérer ou enregistrer son état. Dans l'indépendance de la persistance (persistence independence), un objet est indépendant de la manière dont un programme le manipule. Il existe de nombreux types d'orthogonalité. Par exemple, tous les objets peuvent être rendus persistants indépendamment de leur type ou de leur taille, et ils peuvent atteindre une persistance transitive (se réfère à la persistance par atteignabilité). Les langages de programmation persistants étendent un langage OO avec un ensemble de bibliothèques de classes pour la persistance d'objet. La sérialisation traduit l'état d'un objet dans un format qui peut être stocké (par exemple, dans un fichier) et reconstruit ultérieurement.

SGBDOO et BDO

Les SGBDOO sont apparus vers 1985 et ont été créés comme des extensions des langages de programmation OO. Les programmeurs orientés objet stockent les produits développés sous forme d'objets et modifient les objets existants pour créer de nouveaux objets au sein du SGBDOO. Les SGBDOO stockent les objets persistants de manière transparente, prennent en charge l'orthogonalité de la persistance et garantissent les propriétés ACID. Les SGBDOO présentent de nombreuses limitations telles que l'absence d'un modèle de données universel, le manque d'expérience par rapport aux SGBDR, le manque de support et la complexité. L'Object Data Management Group (ODMG) a été créé en 1991 et est basé sur la norme Object Management Group (OMG) ; son idée principale est de créer un ensemble de spécifications pour développer des applications pour une base de données objet. Il y a eu cinq révisions de l'ODMG et la dernière version est l'ODMG 3.0. La plupart des applications de base de données (database application) grand public sont construites à l'aide d'un langage de programmation OO en combinaison avec un SGBDR plutôt que d'utiliser un mappage objet-relationnel (ORM).

Limitations du modèle relationnel

Le modèle relationnel a une structure plate, et des jointures coûteuses sont nécessaires pour défragmenter les données avant qu'elles ne puissent être utilisées avec succès, ce qui augmente la complexité des objets en raison de la normalisation. La spécialisation, la catégorisation et l'agrégation ne peuvent pas être directement prises en charge. Un constructeur de n-uplets ne peut être utilisé que sur des valeurs atomiques tandis qu'un constructeur d'ensembles ne peut être utilisé que sur des n-uplets ; cependant, les deux constructeurs ne sont pas orthogonaux, ne peuvent pas modéliser le comportement ni stocker des fonctions, et tous deux offrent un faible support pour le multimédia.

Extensions RDBMS actives

Un déclencheur (trigger) est une instruction composée d'instructions déclaratives et/ou procédurales et est stockée dans le catalogue du SGBDR. Les déclencheurs peuvent également référencer des types d'attributs (attribute) dans d'autres tables. Les déclencheurs sont exécutés automatiquement lorsqu'un événement déclencheur se produit, tel que toute modification dans la base de données. Les déclencheurs sont similaires aux procédures stockées dans la base de données mais diffèrent en ce qu'ils doivent être invoqués explicitement. Les déclencheurs sont faciles à coder, sont utiles dans le processus de validation, permettent d'appeler d'autres procédures à partir du déclencheur et permettent la récursivité.

Extensions RDBMS objet-relationnelles

Les SGBD objet-relationnels (SGBDOR) conservent la relation comme bloc de construction fondamental et SQL comme DDL/DML de base, mais ils utilisent les extensions OO suivantes : types définis par l'utilisateur (UDT), fonctions définies par l'utilisateur (UDF), héritage, comportement, polymorphisme, types de collection, objets volumineux (LOB) et requêtes SQL récursives.

Différences entre les données XML et relationnelles

Alors que les données XML sont hiérarchiques, les données relationnelles sont représentées dans un modèle de relations. Les données XML sont auto-descriptives, mais les données relationnelles ne le sont pas. Les données XML ont un ordre inhérent, mais les données relationnelles n'en ont pas. Les SGBDR ne prennent en charge que les types de données atomiques tels que les entiers, les chaînes de caractères et les dates. Les DTD XML ne prennent pas en charge les types de données atomiques. Les schémas XML prennent en charge les types atomiques et agrégés (types agrégés modélisés dans les bases de données objet-relationnelles à l'aide de types définis par l'utilisateur). Les données XML sont semi-structurées (peuvent inclure certaines anomalies, et une modification de DTD ou XSD nécessite la régénération des tables). Par exemple, supposons qu'une application bancaire doive transférer de l'argent d'un compte à un autre. La transaction (transaction) peut impliquer plusieurs étapes, telles que la déduction du montant du compte de l'expéditeur et son ajout au compte du destinataire. Si l'une de ces étapes échoue, l'ensemble de la transaction doit être annulé pour garantir que la base de données reste cohérente. L'atomicité garantit que la transaction se termine avec succès et que toutes les modifications sont validées, ou qu'elle échoue et qu'aucune des modifications n'est validée, laissant la base de données dans un état cohérent.

Mappages entre les données XML et objet-relationnelles

Une ontologie (ontology) est une donnée sémantique utilisée pour décrire les entités du monde réel et la relation entre les entités à l'aide du langage OWL (Web Ontology Language) (Figure 8.16). Pour convertir et mapper les données XML dans des bases de données relationnelles, nous pouvons utiliser le mappage basé sur des tables, qui copie les données d'une source externe telle que XML dans la table sélectionnée. Un schéma de base de données est la structure d'une base de données qui définit comment les données sont organisées au sein d'une base de données. Le mappage insensible au schéma stocke à la fois les données de classe et d'instance OWL dans une seule table, ce qui permet de parser et de charger facilement les fichiers dans la base de données. Le mappage sensible au schéma mappe le schéma OWL dans les tables correspondantes, puis charge les données d'instance dans les tables sélectionnées.

Figure 8.16 Le profil de service indique ce que fait le service, la base du service indique comment y accéder, et le modèle de service indique comment il fonctionne. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Magasins clé-valeur

Un magasin clé-valeur (key-value store) est une base de données simple qui utilise un tableau associatif tel que Redis, DynamoDB et Cosmos DB. Il ne stocke que des paires clé-valeur, fournit des fonctionnalités de base pour récupérer la valeur associée à une clé connue et fonctionne mieux avec un schéma de base de données simple.

Magasins de n-uplets et de documents

Une base de données magasin de n-uplets et de documents (tuple and document store) stocke les données au format XML ou JSON avec le nom du document comme clé et le contenu du document comme valeur.

Figure 8.17 Le même code écrit en (a) XML et (b) JSON montre les différences entre les formats. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Les documents peuvent contenir de nombreux types de valeurs différents et peuvent être imbriqués, ce qui les rend particulièrement adaptés à la gestion de données semi-structurées dans des systèmes distribués. Par exemple, MongoDB et Couchbase sont des bases de données orientées document qui stockent les données dans des documents flexibles et sans schéma, ce qui permet un degré élevé de flexibilité dans la manière dont les données sont stockées et interrogées. Cependant, MongoDB utilise un modèle de document flexible qui permet des structures imbriquées complexes et des données hiérarchiques, tandis que Couchbase utilise un modèle de données clé-valeur avec des documents JSON. Cela rend MongoDB plus adapté aux structures de données complexes et Couchbase plus adapté aux structures de données plus simples.

Bases de données orientées colonne

Une base de données orientée colonne (column-oriented database) stocke les données dans des familles de colonnes ou des tables et est conçue pour gérer des pétaoctets de données dans un système distribué massif (par exemple, Cassandra et Hbase). Cassandra et HBase utilisent toutes deux un modèle de données de famille de colonnes pour stocker et gérer les données et sont toutes deux des bases de données NoSQL conçues pour gérer de grands volumes de données. Cependant, Cassandra utilise un modèle de données de stockage de lignes partitionnées, tandis que HBase utilise un modèle de données orienté colonne. Cela signifie que Cassandra est optimisée pour les lectures et écritures à grande vitesse de lignes individuelles, tandis que HBase est optimisée pour la numérisation de grandes tables de données.

Bases de données orientées graphe

Une base de données orientée graphe (graph-based database) représente les données comme un réseau de nœuds ou d'objets liés pour faciliter les visualisations de données et l'analyse de graphes. Le graphe peut représenter n'importe quelle relation telle que 1:1, 1:N et N:M. Il est utile pour analyser les relations entre des points de données hétérogènes, comme dans la prévention de la fraude ou le graphe d'amis de Facebook.

Autres bases de données NoSQL

Il existe de nombreuses bases de données NoSQL telles que les bases de données XML, les bases de données OO, les systèmes de bases de données pour traiter les séries temporelles et les événements en continu, et les systèmes de bases de données pour stocker et interroger les données géospatiales (les données spatiales désignent les données associées à un emplacement ou une zone géographique spécifique. Les données spatiales peuvent être gérées et analysées à l'aide d'un système d'information géographique). Il existe également des systèmes de bases de données tels que BayesDB. BayesDB est une plateforme de programmation probabiliste basée sur une approche bayésienne de la modélisation des relations de données. La structure de BayesDB peut être décomposée en plusieurs composants clés, y compris des tables de données et des modèles qui permettent aux utilisateurs d'interroger l'implication probable de leurs données.

Gestion des transactions et concurrence dans les bases de données NoSQL

Avec l'augmentation de la quantité de données, le nombre de transactions parallèles a augmenté. Dans ce cas, la capacité peut être augmentée en étendant les capacités du système (mise à l'échelle verticale) ou en organisant plusieurs serveurs dans une grappe (cluster) (mise à l'échelle horizontale). Les bases de données NoSQL distribuent les données sur une grappe de nœuds de base de données pour des raisons de performance et de disponibilité.

Dans de nombreuses implémentations NoSQL (par exemple, Cassandra (Cassandra), BigTable (BigTable) de Google, DynamoDB (DynamoDB) d'Amazon), tous les nœuds implémentent la même fonctionnalité et sont capables de jouer le rôle de coordinateur de requêtes à l'aide d'un protocole d'adhésion. Le protocole d'adhésion vérifie la disponibilité de chaque nœud, ce qui facilite l'application d'index entre eux mais ne garantit pas que chaque nœud est conscient de chaque autre nœud à tout moment. Le hachage est le processus de transformation d'une clé en une autre valeur pour implémenter une table de hachage. Le hachage cohérent évite de mapper chaque clé à un nouveau nœud au cas où des nœuds seraient ajoutés ou supprimés. Le hachage cohérent utilise un opérateur modulo (%) pour distribuer les clés sur les serveurs. La syntaxe est (H(clé) = clé % N) où N est le nombre de serveurs. La cohérence éventuelle signifie que les données et leurs répliques deviennent cohérentes à un certain moment après chaque transaction. Les bases de données NoSQL sont classées comme ayant une cohérence éventuelle car elle garantit des informations à jour ; par conséquent, de nombreuses bases de données NoSQL garantissent une cohérence dite éventuelle basée sur le théorème CAP. Le théorème CAP (CAP theorem) stipule qu'un système informatique distribué ne peut pas atteindre simultanément les trois propriétés suivantes : cohérence (tous les nœuds voient les mêmes données en même temps), disponibilité (garantit que chaque requête reçoit une réponse, indiquant un résultat de succès ou d'échec) et tolérance aux partitions (le système continue de fonctionner même si des nœuds tombent en panne ou sont ajoutés).

Langages de requête et API pour les bases de données NoSQL

Le traitement d'un XML au sein d'une application de base de données (database application) nécessite l'analyse syntaxique (parsing) du document, puis le traitement du code à l'aide d'une API telle que le Document Object Model (API DOM). L'API DOM est une API basée sur un arbre (c'est-à-dire que la représentation en mémoire est un arbre). La Figure 8.18 montre un exemple de code XML et l'arbre DOM correspondant.

Figure 8.18 Cette figure visualise l'API DOM basée sur un arbre : (a) montre le code XML d'entrée, (b) met en évidence la représentation arborescente en mémoire, et (c) démontre l'arbre DOM correspondant. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Les bases de données NoSQL utilisent des filtres pour appliquer la requête simple ; c'est-à-dire qu'elles utilisent des variables dans la requête qui sont remplies sur le serveur. De plus, la plupart des bases de données NoSQL prennent en charge les requêtes complexes à l'aide de l'agrégation avec MapReduce. MapReduce (MapReduce) est un cadriciel logiciel à code source ouvert utilisé pour appliquer des requêtes complexes. Il implémente une fonction de mappage, qui est la conversion d'un ensemble de données en un n-uplet (tuple), et une fonction de réduction, qui réduit le mappage en un ensemble plus petit.

Données infonuagiques en tant que service (DaaS)

Le DaaS est une stratégie de gestion de données qui inclut de nombreuses technologies telles que les solutions de cycle de vie de l'information, la modélisation de données, la réplication et la gestion de contenu. Le DaaS est à la demande et basé sur un abonnement, ce qui signifie que le client ne paie que pour les services dont il a besoin. Les fonctionnalités du DaaS sont la qualité des données, le stockage, la gestion, la sécurisation et l'analyse des données. L'un des principaux avantages des systèmes de bases de données basés sur l'infonuage est leur capacité à être "élastiques" et à fournir des ressources de calcul et de stockage à la demande. Cela signifie qu'à mesure que la taille d'un ensemble de données augmente ou diminue, ou que plus ou moins d'utilisateurs accèdent à la base de données, le système peut rapidement augmenter ou réduire ses ressources pour répondre à la demande.

SGBD blockchain

La technologie qui enregistre les transitions de manière sécurisée est appelée blockchain. Elle attire l'attention du monde entier en raison de son utilisation des cryptomonnaies telles que Bitcoin. Dans le domaine de la santé, la technologie blockchain peut être utilisée pour créer un système sécurisé et transparent de gestion des données de santé. Cela peut aider à améliorer la confidentialité des patients, à réduire la fraude et à améliorer l'efficacité des systèmes de santé. Un SGBD blockchain (blockchain DBMS) est une base de données qui stocke les données sous forme de structure de blocs, et chaque bloc est connecté à d'autres blocs en offrant une sécurité cryptographique et une immuabilité.