Le modèle de bases de données re­la­tion­nelles

Aujourd’hui encore, la gestion élec­tro­nique des données est dominée par le modèle de la base de données re­la­tion­nelle. Les systèmes de gestion de bases de données re­la­tion­nelles (SGBDR) les plus cou­ram­ment utilisés sont classés par ordre al­pha­bé­tique :

• Db2 : Db2 est l’un des SGBD re­la­tion­nelles pro­prié­taire d’IBM dis­po­nible aux uti­li­sa­teurs sous licence com­mer­ciale.
• Microsoft SQL Server : le système de gestion de base de données de Microsoft en langage SQL est dis­po­nible sous une licence par uti­li­sa­teur payante.
•  MySQL : MySQL est le SGBDR open source le plus utilisé dans le monde. Depuis son ac­qui­si­tion par Oracle, MySQL est com­mer­cia­lisé sous une double licence. La com­mu­nauté des dé­ve­lop­peurs d’origine poursuit le projet sous le nom de MariaDB.
• Post­greSQL : avec Post­greSQL, les uti­li­sa­teurs peuvent accéder gra­tui­te­ment à un système de gestion de base de données re­la­tion­nel-objet (SGBDRO). Le dé­ve­lop­pe­ment ultérieur est effectué par une com­mu­nauté open source.
• Oracle Database : le système de gestion de base de données re­la­tion­nelle de la société du même nom Oracle est com­mer­cia­lisé sous licence pro­prié­taire contre ré­mu­né­ra­tion.
• SQLite : SQLite est une bi­blio­thèque ap­par­te­nant au domaine public contenant un système de gestion de bases de données re­la­tion­nelles.

Les in­for­ma­tions de tous les systèmes men­tion­nés ci-dessus sont or­ga­ni­sées dans des tables re­la­tion­nelles. Mais de quoi s’agit-il ? Nous vous pré­sen­te­rons les principes de base de la con­cep­tion des bases de données re­la­tion­nelles ainsi que des exemples de bases de données. Enfin, nous iden­ti­fie­rons les dif­fé­rences de ce type de base données avec les autres modèles existants.

Le concept central du schéma re­la­tion­nel de la base de données est la relation. C’est le ma­thé­ma­ti­cien et théo­ri­cien bri­tan­nique, Edgar F. Codd qui inventa les modèles re­la­tion­nels. Selon lui, une relation re­pré­sente un ensemble d’entités ayant les mêmes pro­prié­tés. Chaque relation est cons­ti­tuée d’une série d’en­re­gis­tre­ments de données (appelés tuples) dont les valeurs sont affectées à certains attributs.

Les attributs qu’une relation contient et le type de données auquel cor­res­pon­dent les valeurs affectées aux attributs sont définis à l’aide d’un schéma de relations selon la syntaxe suivante :

R = (A₁ : Typ₁, A₂ : Typ₂ , … , A_n : Typ_n)

Le schéma de relation (R) comprend les attributs A1 à An. Un type de données (Type1, Type2, etc.) est affecté à chaque attribut. Ceci peut être illustré par un exemple concret.

Le schéma suivant définit les attributs de la relation « employé » :

L’exemple suivant montre à quoi peut res­sem­bler une table de base de données pour la table des employés ré­per­to­rié ci-dessus.

La table d’exemple est utilisée pour en­re­gis­trer les données du personnel et se compose de quatre en­re­gis­tre­ments de données. Chaque en­re­gis­tre­ment de données contient des in­for­ma­tions sur un seul salarié.

La base de données d’un système de bases de données re­la­tion­nelles constitue la base de données tabulaire. Leur structure de données est définie par le système de gestion de la base de données, qui est également res­pon­sable de la gestion des accès en lecture et en écriture. Les uti­li­sa­teurs in­te­ra­gis­sent avec le système de gestion de base de données en utilisant un langage de base de données. Chaque système de gestion de bases de données re­la­tion­nelles supporte au moins un langage formel qui peut être utilisé pour effectuer les opé­ra­tions de base de données suivantes :

• Définir la structure de données : lors de la dé­fi­ni­tion des données, une des­crip­tion de la structure des données est stockée dans le dic­tion­naire de données du système de base de données à l’aide de mé­ta­don­nées. Par exemple, si un uti­li­sa­teur crée une nouvelle table, un schéma de relation cor­res­pon­dant est en­re­gis­tré dans le dic­tion­naire de données. Le vo­ca­bu­laire d’un langage de base de données utilisé pour définir les données est appelé langage de dé­fi­ni­tion des données (DDL).
• Définir les au­to­ri­sa­tions : chaque langage de base de données fournit une syntaxe qui permet d’attribuer ou de révoquer des au­to­ri­sa­tions. C’est ce qu’on appelle le langage de contrôle de données (LCD), un vo­ca­bu­laire partiel du langage de la base de données.
• Définir les con­di­tions d’intégrité : les con­di­tions d’intégrité sont des con­di­tions requises pour l’état d’une base de données. Lorsque des con­di­tions d’intégrité sont définies, la base de données s’assure qu’elles sont res­pec­tées en tout temps. On parle d’une condition constante. Une condition de base de l’intégrité dans les systèmes de bases de données re­la­tion­nelles, par exemple, est que chaque ensemble de données (tuple) puisse être identifié de façon unique.
• Définir les tran­sac­tions : si une base de données est trans­fé­rée d’un état cohérent à un autre, il s’agit d’une tran­sac­tion. Les tran­sac­tions con­tien­nent un certain nombre d’états fi­nan­ciers et doivent toujours être com­plé­tées. Si une tran­sac­tion est in­ter­rom­pue, la base de données est réi­ni­tia­li­sée à son état initial (rollback). Chaque tran­sac­tion commence par l’ins­truc­tion de connexion à la base de données. Celles-ci sont suivies de commandes qui dé­clenchent l’opération des données et d’une étape de test (commit) qui assure l’intégrité de la base de données. Les opé­ra­tions qui mettent en danger l’intégrité ne sont pas commises (écrites de façon per­ma­nente dans la base de données). Enfin, la connexion à la base de données est fermée. Le vo­ca­bu­laire sous-jacent du langage de base de données est appelé langage de ma­ni­pu­la­tion de données (LMD).
• Définir les vues : une vue est une vue virtuelle des données sé­lec­tion­nées. Dans le cas d’une vue, le système de gestion de base de données crée une table virtuelle (relation logique) basée sur des tables physiques. Les uti­li­sa­teurs peuvent appliquer les mêmes opé­ra­tions de base de données à ces vues qu’aux tables physiques. Il existe dif­fé­rents types de vues en fonction de la fonction de la vue de données. Les vues qui filtrent certaines lignes (vue de sélection) ou colonnes (vue de pro­jec­tion) d’une table sé­lec­tion­née et les vues qui relient dif­fé­rentes tables entre elles (vue composée) sont communes.

L'in­ter­face standard pour les opé­ra­tions de base de données énumérées ci-dessus dans le modèle de bases de données re­la­tion­nelles est SQL (Struc­tu­red Query Language), un langage de base de données basé sur l'algèbre re­la­tion­nelle.

Les opé­ra­tions de base de données telles que l’in­ter­ro­ga­tion, la création, la mise à jour ou la sup­pres­sion de données sont ef­fec­tuées à l’aide d’ins­truc­tions SQL : une com­bi­nai­son de commandes SQL sé­lec­tion­nées. Celles-ci sont sé­man­ti­que­ment basées sur la langue anglaise et sont donc largement ex­pli­cites. La table suivante contient les termes clés du modèle de données re­la­tion­nelles et leurs équi­va­lents dans la ter­mi­no­lo­gie SQL.

Une simple requête de données sé­lec­tion­nées peut être im­plé­men­tée avec SQL selon le schéma suivant, par exemple :

Tout d’abord, nous utilisons la commande SELECT pour demander au SGBDR de récupérer les données. Nous dé­fi­nis­sons ensuite les données que nous voulons in­ter­ro­ger en spé­ci­fiant la table et la colonne souhaitée. De plus, avec WHERE, nous intégrons une condition dans l’ins­truc­tion SQL. Nous ne voulons pas récupérer toutes les valeurs d’attribut stockées dans la colonne, seulement la valeur d’un en­re­gis­tre­ment par­ti­cu­lier.

En relation avec notre exemple de table « employés », une telle ins­truc­tion SQL pourrait res­sem­bler à ceci :

L’ins­truc­tion SQL demande au SGBD re­la­tion­nelle de récupérer une valeur de la colonne numéro de sécurité sociale de la table employé. Comme condition, nous avons défini que la valeur doit être tirée de l’ensemble de données pour lequel la valeur d’attribut de la colonne e_id cor­res­pond à la valeur 3.

En con­sé­quence, la base de données nous fournit le numéro de sécurité sociale d’Hélène Petit, l’employée avec l’ID 3 : 25 091225 M 463.

Lorsqu’ils tra­vail­lent avec des bases de données re­la­tion­nelles, les uti­li­sa­teurs ont rarement à traiter avec des tables in­di­vi­duelles. En règle générale, on utilise des struc­tures dans les­quelles les données sont triées en fonction de leur sig­ni­fi­ca­tion et stockées dans des tables séparées. Ce concept est associé à la nécessité de relier les tables de données, par exemple lorsque l’on interroge des données stockées dans dif­fé­rentes tables.

En principe, toutes les in­for­ma­tions d’une base de données re­la­tion­nelle peuvent également être stockées dans une table globale complète. Cela aurait l’avantage d’éviter la nécessité de lier les tables de la base de données, ainsi que la syntaxe complexe associée aux requêtes sur plusieurs tables. C’est cependant ce qui fait la force de la base de données et son modèle re­la­tion­nel. La division de l’in­for­ma­tion en plusieurs tables sert à réduire les entrées doubles (appelées anomalies) et s’appelle la nor­ma­li­sa­tion. Le degré de nor­ma­li­sa­tion peut être déterminé sur la base de formes normales pré­dé­fi­nies. Les formes normales courantes pour les tables de bases de données re­la­tion­nelles sont :

1. La première forme normale (1NF)
2. La seconde forme normale (2NF)
3. La troisième forme normale (3NF)
4. La forme normale de Boyce Codd (BCNF)
5. La quatrième forme normale (4NF)
6. La cinquième forme normale (5NF)

Les con­di­tions préa­lables s’ap­pli­quant aux for­mu­laires normaux énumérés et la façon de trans­fé­rer une base de données d’un for­mu­laire normal à un autre est l’objet de notre Article de base sur la nor­ma­li­sa­tion.

Les relations entre les tables de base de données séparées sont appelées Re­la­tion­ships dans le schéma re­la­tion­nel des bases de données et sont créées à l’aide de clés. Les touches relient les tables et sont la base pour in­ter­ro­ger ou modifier les données de dif­fé­rentes tables avec une seule et même ins­truc­tion.

Les tables de base de données telles que la table d'exemple « employés » per­met­tent dif­fé­rentes approches pour in­ter­ro­ger des valeurs in­di­vi­duelles ou des en­re­gis­tre­ments de données complets. L'accent est mis sur lesdites clés. Dans le modèle des bases de données re­la­tion­nelles, une clé est un ensemble d'at­tri­buts qui peuvent être utilisés pour iden­ti­fier de façon unique un ensemble de données.

Par rapport à l’exemple de table ci-dessus, la clé suivante permet l’iden­ti­fi­ca­tion unique d’un tuple :

serait donc ap­pro­priée pour iden­ti­fier l’en­re­gis­tre­ment des données de l’employée Hélène Petit sans con­tra­dic­tion. Ce type de clé est connu sous le nom de super-clé. Toutefois, les super-clés n’ont que peu d’im­por­tance dans la pratique. L’une des raisons en est que les super-clés con­tien­nent souvent plus d’attributs qu’il n’est né­ces­saire pour l’iden­ti­fi­ca­tion. En d’autres termes, les super-clés ne sont pas minimales.

Dans les bases de données re­la­tion­nelles, on travaille donc avec le plus petit sous-ensemble possible d’une super-clef ima­gi­nable, ce qu’on appelle les clés can­di­dates. Une table peut très bien contenir plusieurs clés can­di­dates avec les­quelles les en­re­gis­tre­ments de données peuvent être iden­ti­fiés de façon unique.

L’exemple de requête de la section pré­cé­dente a déjà montré que les en­re­gis­tre­ments de données de la table « employés » peuvent être iden­ti­fiés sans con­tra­dic­tion par le simple numéro d’iden­ti­fi­ca­tion de l’employé. Le numéro de sécurité sociale est une autre clé candidate dans la table de l’exemple. Une clé {nom, prénom} ne serait pas une bonne clé candidate, puisque cette com­bi­nai­son d’attributs ne peut pas être attribuée de façon unique à un employé : plusieurs employées sous le nom d’Hélène Petit peuvent être salariées dans une même en­tre­prise. L’iden­ti­fi­ca­tion au moyen d’une telle clé ne serait donc pas sans ambiguïté. Toutefois, deux employés ne peuvent pas partager le même numéro d’iden­ti­fi­ca­tion d’employé ou numéro de sécurité sociale.

Les clés can­di­dates suivantes peuvent donc être dé­ter­mi­nées de cette manière dans l’exemple de table ci-dessus :

Les tables de base de données re­la­tion­nelles sont gé­né­ra­le­ment struc­tu­rées de telle sorte que l’une des clés can­di­dates possibles spécifie la séquence des en­re­gis­tre­ments de données. Cette clé candidate s’appelle la clé primaire. En pratique, les clés primaires sont gé­né­ra­le­ment des ID con­sé­cu­tifs. Avec le e_id, notre table d’exemple a aussi un tel ID.

Parce que les clés iden­ti­fient de façon unique les en­re­gis­tre­ments dans les tables de bases de données re­la­tion­nelles, elles sont idéales pour corréler dif­fé­rentes tables dans une base de données. Pour ce faire, vous incluez la clé primaire d’une table comme clé étrangère dans l’autre table.

La table suivante contient des données qu’une en­tre­prise peut avoir en­re­gis­trées sur son propre parc de véhicules. La clé primaire de la table « véhicules » est un v_id con­sé­cu­tif.

Table : véhicules

Pour savoir quels employés utilisent quelle voiture de la société, vous devez lier la table « voitures » à la table « employés » par exemple, en intégrant la clé primaire de la table véhicule (v_id) comme clé étrangère dans la table des employés.

Table : employés

La table des employés montre main­te­nant que le salarié Jacques Dupond utilise une voiture de fonction avec le v_id 3. L’employée Lisa Lefevre conduit un véhicule avec le v_id 2, Jean Martin et Hélène Petit se partagent le véhicule avec le v_id 1.

Si vous voulez dé­ter­mi­ner quel employé aura quelle voiture de fonction la prochaine fois, vous devrez in­ter­ro­ger à la fois la table « employés » et la table « véhicules ». Comme les deux tables sont liées par des clés étran­gères, cela ne peut se faire qu’avec une seule requête. Les opé­ra­tions de base de données qui im­pli­quent plusieurs tables sont im­plé­men­tées dans le modèle de base de données re­la­tion­nelle en utilisant un JOIN.

Un JOIN (jointure en français) est une opération de base de données qui permet à plusieurs tables de base de données d’être in­ter­ro­gées si­mul­ta­né­ment. Les données des tables sé­lec­tion­nées sont combinées dans un jeu de résultats et filtrées en fonction des con­di­tions définies par l’uti­li­sa­teur.

Les bases ma­thé­ma­tiques de SQL JOINs sont deux opé­ra­tions d’algèbre re­la­tion­nelle : produit cartésien et sélection. Les uti­li­sa­teurs dé­ter­mi­nent quelles données des tables in­ter­ro­gées sont incluses dans le jeu de résultats en sé­lec­tion­nant le mot clé JOIN et en utilisant une condition de sélection.

Les types de JOIN les plus im­por­tants sont les suivants :

• INNER JOIN
• OUTER JOIN
• SELF JOIN

In­dé­pen­dam­ment de cela, il convient de dis­tin­guer les EQUI JOINs (équi­join­tures) et les NON EQUI JOINs (théta jointures).

Les bases de données re­la­tion­nelles basées sur SQL doivent être dif­fé­ren­ciées des concepts qui rompent avec la structure rigide des tables et utilisent des approches al­ter­na­tives pour la struc­tu­ra­tion des données. Parmi les concepts les plus im­por­tants de ce type, on retrouve les bases de données orientées objet et les systèmes orientés documents.

A la fin des années 1980, un nouveau modèle de base de données, la base de données orientée objet, est apparu sur le marché. Il reprend les concepts de pro­gram­ma­tion orientée objet et permet le stockage des données sous forme d’objets. Cependant, cette approche n’a guère pu s’affirmer jusqu’à ce jour. Au lieu de cela, les concepts orientés objet ont été in­cor­po­rés dans le dé­ve­lop­pe­ment de systèmes de bases de données re­la­tion­nelles. Il en résulte des produits avec des ex­ten­sions re­la­tion­nel-objet qui per­met­tent le stockage de types de données abs­traites dans le modèle de bases de données re­la­tion­nelles.

A l’ère du Web 2.0, et avec le chan­ge­ment d’uti­li­sa­tion d’Internet, le modèle re­la­tion­nel des bases de données a été fortement remis en question au tournant du mil­lé­naire. Dans le cadre du mouvement NoSQL (abré­via­tion de Not Only SQL), des modèles al­ter­na­tifs tels que des bases de données orientées documents ont été dé­ve­lop­pés. L’objectif de ce mouvement était de dé­ve­lop­per de puissants concepts de bases de données pour les ap­pli­ca­tions gour­mandes en données.

Les bases de données orientées objet et les bases de données orientées documents se dis­tin­guent du schéma re­la­tion­nel des bases de données surtout par la manière dont les données sont stockées ainsi que par leur ac­ces­si­bi­lité.

Le modèle de base de données orientée objet permet le stockage des données sous forme d’objets. La mo­du­la­tion des objets est analogue à la pro­gram­ma­tion orientée objet. Un objet définit une entité et contient :

• • Les pro­prié­tés (attributs) requises pour décrire l’entité,
  • les ré­fé­rences (relations) à d’autres objets,
  • les fonctions qui per­met­tent d’accéder aux données stockées (méthodes).

Un objet est donc un groupe de données dans lequel l’interface est également définie pour accéder à ces données. Les objets ap­par­tien­nent aux types de données abs­traites.

Le système de gestion de bases de données orienté objet (SGBDO) attribue au­to­ma­ti­que­ment un ID à chaque objet. Ceci permet d’iden­ti­fier l’objet de manière unique d’y accéder à l’aide de méthodes. Cet ID d’objet est sans état, c’est-à-dire découplé des valeurs de l’objet. Il est ainsi possible de donner deux ID dif­fé­rents à deux objets avec les mêmes données (c’est-à-dire avec le même état). Ceci distingue clai­re­ment le modèle de base de données orienté objet du modèle re­la­tion­nel, dans lequel chaque tuple peut être identifié par ses données (par exemple par une clé primaire).

Une autre ca­rac­té­ris­tique du modèle de base de données orientée objet est l’en­cap­su­la­tion de données. Les données en­re­gis­trées ne sont ac­ces­sibles que par les méthodes définies pré­cé­dem­ment. Les données en­cap­su­lées dans l’objet sont ainsi protégées contre les mo­di­fi­ca­tions via des in­ter­faces in­dé­fi­nies.

Les struc­tures des bases de données sont définies dans le modèle de base de données orientée objet à l’aide d’un système de clas­si­fi­ca­tion hié­rar­chique. Dans la pro­gram­ma­tion orientée objet, une classe est un ensemble d’objets ayant les mêmes ca­rac­té­ris­tiques. Chaque classe d’objets repose sur une dé­fi­ni­tion de classe. Ce schéma spécifie les attributs et les méthodes de tous les objets de la classe et détermine ainsi la façon dont ils sont créés et modifiés.

Les uti­li­sa­teurs in­te­ra­gis­sent avec la base de données orientée objet à l’aide d’un langage de requêtes de type SQL pour les bases de données orientée objets : l’Object Query Language (OQL). Le résultat d’une requête OQL n’est pas, comme pour SQL, un jeu de résultats, mais une liste d’objets qui cor­res­pon­dent aux con­di­tions de l’ins­truc­tion OQL.

Les im­plé­men­ta­tions connues du modèle de base de données orientée objet sont Realm, ZODB et Perst.

Les bases de données orientées objet ont été dé­ve­lop­pées pour résoudre un problème de dé­ve­lop­pe­ment d’ap­pli­ca­tions connu sous le nom d’Object-re­la­tio­nal impedance mismatch.

Si des objets d’un langage de pro­gram­ma­tion orienté objet (par exemple C#, C++ ou Java) doivent être stockés dans une base de données re­la­tion­nelle, des in­com­pa­ti­bi­li­tés se pro­dui­sent iné­vi­ta­ble­ment. Elles sont dues à des dif­fé­rences fon­da­men­tales entre les deux pa­ra­digmes de pro­gram­ma­tion.

• • Les bases de données re­la­tion­nelles ne sup­por­tent pas les concepts orientés objet tels que les classes et l’héritage.
  • L’iden­ti­fi­ca­tion de l’objet sans état ne peut pas être réalisée dans le modèle de base de données re­la­tion­nelle.
  • Le mécanisme de pro­tec­tion de l’en­cap­su­la­tion des données n’est pas dis­po­nible dans le modèle de bases de données re­la­tion­nelles.

Une approche pour éviter les problèmes d’in­com­pa­ti­bi­lité men­tion­nés ci-dessus consiste à renoncer aux bases de données re­la­tion­nelles et à utiliser une base de données objet dans le cadre d’une pro­gram­ma­tion ap­pli­ca­tive orientée objet. Cependant, cela présente iné­vi­ta­ble­ment l’in­con­vé­nient que les données en­cap­su­lées dans des objets ne sont pas dis­po­nibles in­dé­pen­dam­ment de l’ap­pli­ca­tion associée. En outre, les bases de bases de donnée objet ne sont pas très répandues. La plupart des outils et in­ter­faces d’analyse de données sont encore conçus pour les bases de données re­la­tion­nelles et ne prennent pas en charge le modèle de données orientées objet.

Cependant, les dé­ve­lop­peurs d’ap­pli­ca­tions qui ne sou­hai­tent pas se passer des avantages du stockage de données re­la­tion­nelles peuvent compenser les in­com­pa­ti­bi­li­tés en utilisant des mappeurs objet/re­la­tion­nel. Les fonc­tion­na­li­tés de mapping objet-re­la­tion­nel (ORM) sont im­plé­men­tées via des bi­blio­thèques. Elles créent une couche d’abs­trac­tion entre l’ap­pli­ca­tion orientée objet et les données stockées dans les tables.

De nombreux fa­bri­cants de systèmes de bases de données re­la­tion­nelles équipent également leurs produits de fonctions qui com­pen­sent les in­com­pa­ti­bi­li­tés avec la pro­gram­ma­tion orientée objet. Les systèmes de base de données de ce type sont appelés « objet-re­la­tion­nel ».

Les bases de données orientées objet trans­fè­rent les principes de base de l’orien­ta­tion objet aux tech­no­lo­gies de base de données et sont donc par­ti­cu­liè­re­ment adaptées à la pro­gram­ma­tion ap­pli­ca­tive orientée objet. Toutefois, les systèmes de bases de données cor­res­pon­dants sont rares et certains d’entre eux ne sont pas encore prêts pour le marché.

Un système de base de données re­la­tion­nel-objet est un système de bases de données re­la­tion­nelles qui a été étendu par des concepts d’orien­ta­tion objet. Les principes éprouvés du modèle de bases de données re­la­tion­nelles doivent donc être étendus aux types de données abs­traites tels que les objets.

Afin de permettre la gestion des types de données abs­traites, les bases de données re­la­tion­nel-objet étendent le modèle de base de données re­la­tion­nelles en :

• • Types de données complexes et définies par l’uti­li­sa­teur,
  • cons­truc­teurs,
  • fonctions et méthodes.

Alors que les bases de données re­la­tion­nelles sont es­sen­tiel­le­ment limitées aux types de données al­pha­nu­mé­riques, les types de données définis par l’uti­li­sa­teur peuvent également être utilisés pour gérer des fichiers mul­ti­mé­dias complexes. Les cons­truc­teurs vous per­met­tent de dériver de nouveaux types de données à partir des types de base existants. Comme le langage de base de données SQL ne permet pas de créer des fonctions, les systèmes de base de données re­la­tion­nel-objet doivent fournir des ex­ten­sions pour définir les fonctions d’accès et de trai­te­ment pour les types de données complexes.

Depuis le début des années 2000, des ex­ten­sions re­la­tion­nel-objet telles que les types struc­tu­rés ont été incluses dans les nouvelles versions de la norme SQL. Toutefois, tous les SGBD ne les prennent pas en charge. Les systèmes de base de données bien connus qui four­nis­sent les ex­ten­sions cor­res­pon­dantes sont IBM Db2, Oracle Database et Microsoft SQL Server.

Alors que le stockage des données dans des bases de données re­la­tion­nelles s’effectue dans des tables de base de données, le modèle de bases de données orientées document est basé sur une base de données hé­té­ro­gène de documents in­di­vi­duels. Il peut s’agir de documents struc­tu­rés tels que des fichiers JSON, YAML ou XML ainsi que des fichiers non struc­tu­rés tels que des Binary Large Object (BLOBs) qui sont des fichiers image, vidéo ou audio.

Si des documents struc­tu­rés sont dis­po­nibles, les données sont en­re­gis­trées sous forme de com­bi­nai­sons clé/valeur. Une valeur concrète est attribuée à chaque clé. Dans ce contexte, le terme clé est utilisé comme synonyme du terme attribut et n’a rien à voir avec les clés du système de base de données re­la­tion­nelles. Les valeurs peuvent être n’importe quelle in­for­ma­tion. Les listes et les tables avec des données im­bri­quées sont également des valeurs possibles.

Par exemple, un document au format JSON (Notation des objets Ja­vaS­cript) qui est utilisé pour stocker les données des employés peut res­sem­bler à ceci :

Plusieurs documents peuvent être regroupés pour former des col­lec­tions de documents. Le document de l’employé affiché peut, par exemple, être « employé » avec d’autres parties de la col­lec­tion.

Les requêtes sont réalisées à l’aide de fonctions, par exemple via Ja­vaS­cript. Même les systèmes de gestion de base de données qui fonc­tion­nent orientés document at­tri­buent un iden­ti­fiant unique à chaque document. Cependant, con­trai­re­ment au modèle de bases de données re­la­tion­nelles, il n’existe pas de schéma de base de données qui couvre l’ensemble de la base de données. Les documents d’une base de données basée sur des documents n’ont pas besoin d’être conformes à une forme normale, et il n’existe pas non plus de ca­rac­té­ris­tiques struc­tu­relles pré­dé­fi­nies qui doivent s’appliquer à tous les documents. En principe, chaque document peut avoir une structure dif­fé­rente. Toutefois, dans le contexte du dé­ve­lop­pe­ment d’ap­pli­ca­tions, il est conseillé de créer des documents dans un schéma cor­res­pon­dant à l’ap­pli­ca­tion afin de créer la condition préalable aux requêtes ciblées.

Les relations telles que la liaison de tables de base de données dans le modèle de base de données re­la­tion­nelle ne peuvent pas être im­plé­men­tées avec des bases de données orientées document. Bien qu’il soit possible de saisir ma­nuel­le­ment l’ID d’un document comme référence dans un autre document, les systèmes de gestion de base de données orientée document n’offrent pas de JOINs. Vous devrez donc pro­gram­mer vous-même les options de requête cor­res­pon­dantes.

Les systèmes de bases de données orientées documents sont par­ti­cu­liè­re­ment adaptés au trai­te­ment de grandes quantités de données à structure hé­té­ro­gène et à faible mise en réseau. Ce modèle de stockage de données est donc par­ti­cu­liè­re­ment utile pour les données de grandes taille.

Les systèmes de bases de données re­la­tion­nelles ga­ran­tis­sent que les con­di­tions spé­ci­fiées dans les dé­fi­ni­tions des tables sont remplies à tout moment. Ceci conduit à des vitesses d’écriture re­la­ti­ve­ment lentes lors du trai­te­ment de grandes quantités de données. Les systèmes de bases de données NoSQL n’ont pas d’exigences aussi strictes en matière de cohérence des données et sont donc adaptés aux grandes ar­chi­tec­tures dans les­quelles de nom­breuses instances de bases de données sont ex­ploi­tées en parallèle.

Les ap­pli­ca­tions Web utilisent également de plus en plus de bases de données orientées documents. Si, toutefois, un ré­seau­tage solide est né­ces­saire, le stockage de données do­cu­men­taires est associé à un effort accru. Dans ce cas, les uti­li­sa­teurs devraient mieux utiliser les systèmes de bases de données re­la­tion­nelles.

BaseX, CouchDB, eXist, MongoDB et RavenDB sont des exemples de bases de données orientées documents.

Les bases de données re­la­tion­nelles ne se sont pas imposées sans raison comme une norme de facto dans le trai­te­ment élec­tro­nique des données. Les points suivants s’ap­pli­quent au modèle de bases de données re­la­tion­nelles.

• • Modèle de données simple : les bases de données re­la­tion­nelles sont basées sur un modèle de données re­la­ti­ve­ment facile à mettre en œuvre et à gérer. De nom­breuses in­for­ma­tions, telles que les données clients, les listes de commandes ou les mou­ve­ments de compte que les en­tre­prises sou­hai­tent stocker pendant une longue période peuvent idéa­le­ment être mappées avec la structure de table sur laquelle le modèle de bases de données re­la­tion­nelles est basé.
  • Faible re­don­dance des données : le modèle re­la­tion­nel des bases de données fournit des règles pré­ci­sé­ment définies pour éviter la re­don­dance avec les dif­fé­rentes formes normales. Si les spé­ci­fi­ca­tions de nor­ma­li­sa­tion sont ap­pli­quées de manière cohérente, les systèmes de bases de données re­la­tion­nelles per­met­tent un stockage des données pra­ti­que­ment sans re­don­dance. Cela facilite la gestion et l’entretien des stocks de données, puisque les mo­di­fi­ca­tions ne doivent être ef­fec­tuées qu’à un seul endroit.
  • Cohérence élevée des données : les bases de données re­la­tion­nelles nor­ma­li­sées per­met­tent un stockage cohérent des données et con­tri­buent ainsi à la cohérence des données. Les systèmes de bases de données re­la­tion­nelles offrent également des fonctions per­met­tant de définir et de vérifier au­to­ma­ti­que­ment les con­di­tions d’intégrité. Les tran­sac­tions qui mettent en danger la cohérence des données sont exclues.
  • Trai­te­ment des données quan­ti­ta­tives : le système de bases de données re­la­tion­nelles est basé sur un trai­te­ment des données quan­ti­ta­tives dans lequel chaque entité est dé­com­po­sée en valeurs atomiques. Cela permet de lier dif­fé­rentes entités via le contenu ainsi que des requêtes de base de données complexes telles que les JOINs.
  • Langage de requête uniforme : pour les requêtes de bases de données re­la­tion­nelles, le langage de base de données SQL stan­dar­disé par un comité de ISO et IEC a été établi. Le but de cette stan­dar­di­sa­tion est que les ap­pli­ca­tions puissent être dé­ve­lop­pées et exécutées en grande partie in­dé­pen­dam­ment du système de gestion de base de données sous-jacent. Cependant, le support SQL varie encore con­si­dé­ra­ble­ment d’un SGBD à l’autre.

Selon le scénario dans lequel les systèmes de bases de données re­la­tion­nelles sont utilisés, des avantages tels que le modèle de données simple basé sur des tables et la division des données en plusieurs tables liées peuvent également être in­ter­pré­tés comme des in­con­vé­nients. En outre, les ca­rac­té­ris­tiques centrales du modèle des bases de données re­la­tion­nelles sont dif­fi­ciles à concilier avec les exigences modernes de pro­gram­ma­tion des ap­pli­ca­tions (telles que l’orien­ta­tion objet, le mul­ti­mé­dia et les données de grande taille).

• Affichage tabulaire des données : tous les types de données ne peuvent pas être com­pres­sés dans un schéma rigide de tables bi­di­men­sion­nelles liées (ina­dé­qua­tion d’impédance). Les types de données abs­traites et les données non struc­tu­rées qui se pro­dui­sent dans le cadre d’ap­pli­ca­tions mul­ti­mé­dia et de grandes solutions de données ne fonc­tion­nent pas avec le modèle des bases de données re­la­tion­nelles.

• Pas de schéma de base de données hié­rar­chique : con­trai­re­ment aux bases de données orientées objet, les bases de données re­la­tion­nelles n’offrent pas la pos­si­bi­lité d’im­plé­men­ter des schémas de base de données avec des classes hié­rar­chi­que­ment struc­tu­rées. Des concepts tels que les entités su­bor­don­nées qui héritent de pro­prié­tés d’entités su­pé­rieures ne peuvent pas être im­plé­men­tés avec elles. Par exemple, vous ne pouvez pas créer de sous-tuples avec eux. Tous les tuples d’une base de données re­la­tion­nelle se trouvent au même niveau hié­rar­chique.
• Seg­men­ta­tion des données : le principe de base des systèmes de bases de données re­la­tion­nelles, qui consiste à diviser l’in­for­ma­tion en tables séparées (nor­ma­li­sa­tion), conduit iné­vi­ta­ble­ment à une seg­men­ta­tion des données. Tout ce qui est connexes n’est pas né­ces­sai­re­ment stocké ensemble. Cette con­cep­tion de base de données entraîne des requêtes complexes sur plusieurs tables au niveau de l’ap­pli­ca­tion. Le nombre plus élevé de segments in­ter­ro­gés qui en résulte a gé­né­ra­le­ment un impact négatif sur la per­for­mance.
• Per­for­mances in­fé­rieures à celles des bases de données NoSQL : le modèle de bases de données re­la­tion­nelles impose des exigences élevées en matière de cohérence des données, ce qui est pré­ju­di­ciable à la vitesse d’écriture des tran­sac­tions.

Le schéma re­la­tion­nel des bases de données est clair, ma­thé­ma­ti­que­ment solide et a fait ses preuves dans la pratique depuis plus de 40 ans. Pourtant, le stockage des données dans des tables struc­tu­rées ne répond pas à toutes les exigences des tech­no­lo­gies modernes de l’in­for­ma­tion.

L’ad­mi­nis­tra­tion de grandes quantités de données dans le cadre de grandes analyses de données et le stockage de types de données abstraits poussent surtout les systèmes re­la­tion­nels clas­siques à leurs limites. C’est là que les systèmes spé­cia­li­sés tels que les bases de données orientées objet ou les concepts dé­ve­lop­pés dans le cadre du mouvement NoSQL marquent des points. Cependant, le modèle de bases de données re­la­tion­nelles ne peut pas être com­plè­te­ment amorti. Les bases de données re­la­tion­nelles offrent de nombreux avantages, en par­ti­cu­lier dans les domaines d’activité où le trai­te­ment des données de tran­sac­tion est au premier plan.

Les données relatives aux campagnes clients ou aux mesures de marketing peuvent idéa­le­ment être stockées dans des systèmes ta­bu­laires. Les uti­li­sa­teurs bé­né­fi­cient également d’une syntaxe qui permet des requêtes complexes malgré sa sim­pli­cité.