Bases de données : pourquoi en avez-vous besoin et quels sont leurs types ?

Une base de données recueille des données et les relie à une unité logique. Les dif­fé­rentes unités de données sont dotées de méta-des­crip­tions et des in­for­ma­tions né­ces­saires à leur trai­te­ment. Les bases de données sont ex­trê­me­ment utiles pour gérer les bases de données et faciliter la recherche d’in­for­ma­tions spé­ci­fiques. De plus, des droits peuvent être définis dans de nom­breuses bases de données qui dé­ter­mi­nent quelles personnes ou quels pro­grammes sont autorisés à accéder à quelles données. Il s’agit également de présenter les contenus de manière claire et orientée vers la demande.

Les systèmes de base de données diffèrent les uns des autres sur le plan con­cep­tuel et pré­sen­tent donc des forces et des fai­blesses in­di­vi­duelles. Cependant, ils sont tous sub­di­vi­sés en base de données et en système de gestion de base de données. La "base de données" désigne l’ensemble des données à commander (également appelée "système"). Le système de gestion de la base de données est res­pon­sable de l’ad­mi­nis­tra­tion et détermine la structure, l’ordre, les droits d’accès, les dé­pen­dances, etc. Il utilise souvent un langage de base de données spé­cia­le­ment défini et un modèle de base de données approprié qui définit l’ar­chi­tec­ture du système de base de données.

Beaucoup de ces systèmes ne peuvent être lus que par des ap­pli­ca­tions de base de données spé­ci­fiques et définies avec précision. De nos jours, il y a souvent confusion lorsqu’un programme de base de données est sim­ple­ment appelé "base de données" sans autres spé­ci­fi­ca­tions. Le terme est aussi souvent utilisé pour désigner de simples col­lec­tions de fichiers. Tech­ni­que­ment, cependant, un dossier sur un or­di­na­teur qui contient de nombreux fichiers, par exemple, n’est pas encore une base de données.

Pour rendre le trai­te­ment élec­tro­nique des données struc­tu­rel­le­ment efficace, le concept de base de données élec­tro­nique comme couche lo­gi­cielle séparée entre le système d’ex­ploi­ta­tion et le programme d’ap­pli­ca­tion a été développé dans les années 1960. C’était le résultat d’une ex­pé­rience pratique : tra­vail­ler ma­nuel­le­ment avec des dossiers in­di­vi­duels, su­per­vi­ser et accorder des droits d’accès s’est avéré tout sim­ple­ment trop difficile et le trai­te­ment élec­tro­nique des données a été développé pour rendre la tâche plus facile. L’idée du système de base de données élec­tro­nique était l’une des in­no­va­tions les plus im­por­tantes dans le dé­ve­lop­pe­ment de l’or­di­na­teur.

Tout d’abord, des modèles de réseaux et de bases de données hié­rar­chiques ont été élaborés. Cependant, celles-ci se sont ra­pi­de­ment révélées trop simples et tech­ni­que­ment limitées. IBM a réalisé une percée majeure dans les années 1970 avec le dé­ve­lop­pe­ment du modèle de base de données re­la­tion­nelle beaucoup plus puissant, qui s’est ra­pi­de­ment répandu dans la vie pro­fes­sion­nelle. Les produits les plus réussis de cette époque étaient le langage de base de données SQL d’Oracle et les produits suc­ces­seurs d’IBM, SQL/DS et DB2.

Jusqu’aux années 2000, des fa­bri­cants renommés ont dominé le marché des logiciels de base de données jusqu’à ce que plusieurs projets open source apportent une bouffée d’air frais. Les systèmes librement ac­ces­sibles les plus po­pu­laires sont MySQL et Post­greSQL. La tendance vers les systèmes NoSQL, qui a débuté en 2001, s’inscrit dans la tradition des systèmes de bases de données re­la­tion­nelles lancés par les fa­bri­cants.

Aujourd’hui, il est im­pos­sible d’imaginer de nombreux domaines d’ap­pli­ca­tion sans systèmes de bases de données. Tous les logiciels d’en­tre­prise sont basés sur de puis­santes bases de données qui four­nis­sent aux ad­mi­nis­tra­teurs système des options et des outils complets. En outre, la sécurité des données est devenue un sujet de plus en plus important dans les systèmes de bases de données. Enfin, les mots de passe, les ren­seig­ne­ments per­son­nels et même les devises élec­tro­niques sont stockés et cryptés dans des bases de données élec­tro­niques.

Le système financier moderne, par exemple, peut être imaginé comme un réseau de bases de données. La plupart des sommes d’argent existent sous forme d’unités d’in­for­ma­tion élec­tro­nique - la pro­tec­tion de ces in­for­ma­tions à l’aide de bases de données sé­cu­ri­sées est une tâche es­sen­tielle pour les ins­ti­tu­tions fi­nan­cières. C’est notamment pour cette raison que les bases de données élec­tro­niques sont ex­trê­me­ment im­por­tantes pour la ci­vi­li­sa­tion moderne.

Un terme largement utilisé pour décrire les fonctions et les exigences des tran­sac­tions dans un système de gestion de base de données est ACID, un acronyme pour atomicité, cohérence, isolement et du­ra­bi­lité. Les termes partiels d’ACID couvrent les exigences les plus im­por­tantes pour un SGBD :

• L’atomicité ou l’isolement est la propriété "tout ou rien" du SGBD où seules les requêtes valides sont ef­fec­tuées dans l’ordre correct et où la tran­sac­tion entière est exécutée cor­rec­te­ment.
• L’uni­for­mité exige que les tran­sac­tions réussies laissent une base de données stable, ce qui exige un examen constant de toutes les tran­sac­tions.
• L’isolement est l’exigence selon laquelle les tran­sac­tions ne doivent pas "s’entraver", ce qui est gé­né­ra­le­ment le cas avec les fonctions de ver­rouil­lage.
• La du­ra­bi­lité signifie que toutes les données sont stockées en per­ma­nence dans le SGBD, même après qu’une tran­sac­tion réussie soit effectuée. Ceci s’applique également aux erreurs système ou aux dé­fail­lances du SGBD. Les journaux de tran­sac­tions, par exemple, qui en­re­gistrent tous les processus dans le SGBD, sont es­sen­tiels à la du­ra­bi­lité.

Ce qui suit est une sub­di­vi­sion sup­plé­men­taire des fonctions et des exigences qu’un système de gestion de base de données pourrait avoir, au-delà du modèle ACID.

Vous pouvez dif­fé­ren­cier les modèles de base de données cou­ram­ment utilisés selon d’autres critères que le simple dé­ve­lop­pe­ment technique de la trans­mis­sion élec­tro­nique des données. L’accent a été mis sur l’ef­fi­ca­cité et la con­vi­via­lité, mais aussi sur la course tech­no­lo­gique de fa­bri­cants renommés.

Les bases de données hié­rar­chiques ont des dé­pen­dances très claires. Cela signifie que chaque en­re­gis­tre­ment de données a exac­te­ment un pré­dé­ces­seur (relations parents-enfants, PCR) sauf la racine de la base de données. Ceci conduit à l’ar­bo­res­cence illustrée ci-dessus. Bien que chaque "enfant" ne puisse avoir qu’un "parent", chaque "parent" peut avoir un nombre quel­conque d’"enfants". En raison de l’ordre hié­rar­chique strict, les couches qui ne sont pas di­rec­te­ment ad­ja­centes ne peuvent pas interagir les unes avec les autres. De plus, il n’est pas facile d’établir un lien entre deux arbres dif­fé­rents. Les struc­tures hié­rar­chiques des bases de données sont donc ex­trê­me­ment rigides, quoique très claires.

Les ensembles de données qui ont des "enfants" sont appelés "en­re­gis­tre­ments". Les en­re­gis­tre­ments sans "enfants" sont appelés "feuilles" parce qu’ils con­tien­nent gé­né­ra­le­ment les documents dans une base de données hié­rar­chique. Les dossiers sont ha­bi­tuel­le­ment utilisés pour organiser les feuilles. Chaque requête dans une base de données hié­rar­chique accède à une feuille à partir de la racine à travers les en­re­gis­tre­ments.

L’ensemble de données au milieu du graphique peut théo­ri­que­ment être atteint par cinq autres ensembles. En même temps, l’accès à l’ensemble de données du milieu permet d’accéder à cinq ensembles de données sup­plé­men­taires. Les dé­pen­dances peuvent également être définies dans le modèle de base de données réseau : L’en­re­gis­tre­ment le plus haut n’a pas de lien direct avec celui de l’extrême droite, il doit donc passer par celui du milieu (qui peut alors autoriser ou refuser l’accès). Pour ce faire, l’uti­li­sa­teur peut accéder di­rec­te­ment à l’en­re­gis­tre­ment de données dans le coin supérieur gauche. Les ensembles de données peuvent être ajoutés et supprimés de manière fluide dans le modèle de réseau sans in­ter­fé­rer de manière sig­ni­fi­ca­tive avec la structure globale.

Aujourd’hui, le modèle de base de données en réseau est prin­ci­pa­le­ment utilisé sur les main­frames. Dans d’autres domaines, soit le modèle hié­rar­chique (en par­ti­cu­lier pour les clients d’IBM) continue d’inspirer confiance, à moins que la tran­si­tion vers un modèle re­la­tion­nel plus souple et plus facile à utiliser n’ait été effectuée. Les modèles de base de données réseau bien connus sont l’UDS de Siemens et le DMS de Sperry Univac. Au fil des années, les deux sociétés ont également développé des hybrides in­té­res­sants entre le modèle réseau et le modèle re­la­tion­nel sans réaliser une véritable percée. Cependant, les résultats de ce test peuvent encore être tracés dans Siemens SQL aujourd’hui. La base de données graphique, dont la structure rappelle celle d’un réseau, constitue un per­fec­tion­ne­ment moderne du modèle de réseau.

Le modèle de base de données re­la­tion­nelle fonc­tionne avec des tables in­di­vi­duelles qui dé­fi­nis­sent la lo­ca­li­sa­tion et les liens entre les in­for­ma­tions. Ces in­for­ma­tions forment un ensemble de données (dans le diagramme d’une ligne ou d’un "tuple"). Les in­for­ma­tions in­di­vi­duelles sont col­lec­tées sous forme d’attributs (dans les gra­phiques A1 à An) dans les colonnes. La relation totale ("relation" est souvent utilisée comme synonyme du terme "table") est dérivée d’attributs connexes. La clé primaire, qui est gé­né­ra­le­ment définie comme le premier attribut (A1) et ne doit jamais changer, est élé­men­taire pour l’iden­ti­fi­ca­tion unique d’un en­re­gis­tre­ment de données. En d’autres termes, cette clé primaire (aussi appelée "ID") définit la position exacte de l’ensemble de données suivant avec tous les attributs.

Dans le modèle de base de données orienté objet, les données, ses fonctions et ses méthodes sont stockées dans un objet. Les objets sont gé­né­ra­le­ment des objets à terme avec des attributs associés qui décrivent l’objet plus en détail. L’accès à ces objets est défini dans le système de gestion de base de données d’objets à l’aide des "méthodes" qui sont en­re­gis­trées avec les données de l’objet.

Les objets peuvent être complexes et se composer d’un nombre illimité de types de données. En outre, les objets sont uniques dans le système de base de données et sont iden­ti­fiés par le numéro d’iden­ti­fi­ca­tion unique (ID d’objet, OID). Comme vous pouvez le voir dans le diagramme, les objets in­di­vi­duels sont regroupés en classes d’objets, ce qui se traduit par une hié­rar­chie de classes. Bien qu’il semble y avoir une si­mi­li­tude avec le modèle de base de données hié­rar­chique, l’approche orientée objet est décisive ici et il n’y a pas de relations parent-enfant fixes. Néanmoins, la méthode d’accès peut être spécifiée par la classe d’objets.

Les bases de données d’objets offrent des avantages pour les problèmes complexes avec des pro­fon­deurs d’objets cor­res­pon­dantes. La base de données d’objets fonc­tionne de manière largement in­dé­pen­dante, sans trop d’in­ter­ven­tion dans la nor­ma­li­sa­tion et le ré­fé­ren­ce­ment d’ID, et permet par la suite l’ali­men­ta­tion re­la­ti­ve­ment simple et fluide d’objets nouveaux et complexes. Cependant, les requêtes simples sont beaucoup plus rapides dans un système de base de données re­la­tion­nelle, par exemple. Comme les systèmes de base de données orientés objet ne sont pas très po­pu­laires, cela conduit à une com­pa­ti­bi­lité in­suf­fi­sante avec de nom­breuses ap­pli­ca­tions de base de données courantes.

Dans ce modèle, les documents cons­ti­tuent l’unité de base pour le stockage des données. Ils struc­tu­rent les données et ne doivent pas être confondus avec des documents comme ceux utilisés dans les pro­grammes d’édition de texte. Les données sont stockées par paires clé/valeur et se composent d’une "clé" et d’une "valeur". Étant donné que la structure et le nombre de ces paires ne sont pas fixes, les documents in­di­vi­duels d’une base de données orientée document peuvent avoir un aspect très différent. Chaque document est une unité autonome. Les relations entre les documents ne sont pas faciles à établir, mais ne sont pas non plus né­ces­saires dans ce modèle.

Dans le modèle re­la­tion­nel (illustré dans le graphique avec les tableaux), dif­fé­rentes relations sont reliées entre elles pour lire un ensemble de données commun. Dans le modèle de document, un seul document suffit pour stocker toutes les in­for­ma­tions. Le schéma est librement sé­lec­tion­nable : le modèle de base de données orientée document est con­cep­tuel­le­ment exempt de schéma, à condition que le langage de base de données utilisé reste le même.

Une idée élé­men­taire pour les bases de données de documents est que les données associées sont toujours stockées ensemble en un seul endroit (dans le document). Alors que les bases de données re­la­tion­nelles affichent et sortent gé­né­ra­le­ment des in­for­ma­tions liées en reliant plusieurs tables, la requête spé­ci­fique d’un document dans le modèle basé sur les documents est suf­fi­sante. Ceci réduit le nombre d’opé­ra­tions né­ces­saires dans la base de données.

Les systèmes de bases de données do­cu­men­taires sont par­ti­cu­liè­re­ment in­té­res­sants pour les ap­pli­ca­tions Web, car ils per­met­tent d’alimenter des for­mu­laires HTML complets. En par­ti­cu­lier au cours du dé­ve­lop­pe­ment du web 2.0, les bases de données do­cu­men­taires sont devenues de plus en plus po­pu­laires. Cependant, il existe des dif­fé­rences con­si­dé­rables entre les dif­fé­rents systèmes de base de données orientés documents, de la syntaxe à la structure interne. Ainsi, toutes les bases de données de documents ne sont pas adaptées à tous les domaines d’ap­pli­ca­tion. C’est pré­ci­sé­ment à cause de ces dif­fé­rentes ité­ra­tions qu’il existe aujourd’hui des systèmes de base de données orientés documents bien connus : Lotus Notes, Amazon SimpleDB, Mongo DB, CouchDB, ThruDB, Orient DB, et bien plus encore.