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 différentes unités de données sont dotées de méta-descriptions et des informations nécessaires à leur traitement. Les bases de données sont extrêmement utiles pour gérer les bases de données et faciliter la recherche d’informations spécifiques. De plus, des droits peuvent être définis dans de nombreuses bases de données qui déterminent quelles personnes ou quels programmes 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 conceptuel et présentent donc des forces et des faiblesses individuelles. Cependant, ils sont tous subdivisé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 responsable de l’administration et détermine la structure, l’ordre, les droits d’accès, les dépendances, etc. Il utilise souvent un langage de base de données spécialement défini et un modèle de base de données approprié qui définit l’architecture du système de base de données.

Beaucoup de ces systèmes ne peuvent être lus que par des applications de base de données spécifiques et définies avec précision. De nos jours, il y a souvent confusion lorsqu’un programme de base de données est simplement appelé "base de données" sans autres spécifications. Le terme est aussi souvent utilisé pour désigner de simples collections de fichiers. Techniquement, cependant, un dossier sur un ordinateur qui contient de nombreux fichiers, par exemple, n’est pas encore une base de données.

Pour rendre le traitement électronique des données structurellement efficace, le concept de base de données électronique comme couche logicielle séparée entre le système d’exploitation et le programme d’application a été développé dans les années 1960. C’était le résultat d’une expérience pratique : travailler manuellement avec des dossiers individuels, superviser et accorder des droits d’accès s’est avéré tout simplement trop difficile et le traitement électronique 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 électronique était l’une des innovations les plus importantes dans le développement de l’ordinateur.

Tout d’abord, des modèles de réseaux et de bases de données hiérarchiques ont été élaborés. Cependant, celles-ci se sont rapidement révélées trop simples et techniquement limitées. IBM a réalisé une percée majeure dans les années 1970 avec le développement du modèle de base de données relationnelle beaucoup plus puissant, qui s’est rapidement répandu dans la vie professionnelle. Les produits les plus réussis de cette époque étaient le langage de base de données SQL d’Oracle et les produits successeurs d’IBM, SQL/DS et DB2.

Jusqu’aux années 2000, des fabricants 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 accessibles les plus populaires sont MySQL et PostgreSQL. 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 relationnelles lancés par les fabricants.

Aujourd’hui, il est impossible d’imaginer de nombreux domaines d’application sans systèmes de bases de données. Tous les logiciels d’entreprise sont basés sur de puissantes bases de données qui fournissent aux administrateurs 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 renseignements personnels et même les devises électroniques sont stockés et cryptés dans des bases de données électroniques.

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’information électronique - la protection de ces informations à l’aide de bases de données sécurisées est une tâche essentielle pour les institutions financières. C’est notamment pour cette raison que les bases de données électroniques sont extrêmement importantes pour la civilisation moderne.

Un terme largement utilisé pour décrire les fonctions et les exigences des transactions dans un système de gestion de base de données est ACID, un acronyme pour atomicité, cohérence, isolement et durabilité. Les termes partiels d’ACID couvrent les exigences les plus importantes pour un SGBD :

• L’atomicité ou l’isolement est la propriété "tout ou rien" du SGBD où seules les requêtes valides sont effectuées dans l’ordre correct et où la transaction entière est exécutée correctement.
• L’uniformité exige que les transactions réussies laissent une base de données stable, ce qui exige un examen constant de toutes les transactions.
• L’isolement est l’exigence selon laquelle les transactions ne doivent pas "s’entraver", ce qui est généralement le cas avec les fonctions de verrouillage.
• La durabilité signifie que toutes les données sont stockées en permanence dans le SGBD, même après qu’une transaction réussie soit effectuée. Ceci s’applique également aux erreurs système ou aux défaillances du SGBD. Les journaux de transactions, par exemple, qui enregistrent tous les processus dans le SGBD, sont essentiels à la durabilité.

Ce qui suit est une subdivision supplémentaire 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 différencier les modèles de base de données couramment utilisés selon d’autres critères que le simple développement technique de la transmission électronique des données. L’accent a été mis sur l’efficacité et la convivialité, mais aussi sur la course technologique de fabricants renommés.

Les bases de données hiérarchiques ont des dépendances très claires. Cela signifie que chaque enregistrement de données a exactement un prédécesseur (relations parents-enfants, PCR) sauf la racine de la base de données. Ceci conduit à l’arborescence illustrée ci-dessus. Bien que chaque "enfant" ne puisse avoir qu’un "parent", chaque "parent" peut avoir un nombre quelconque d’"enfants". En raison de l’ordre hiérarchique strict, les couches qui ne sont pas directement adjacentes ne peuvent pas interagir les unes avec les autres. De plus, il n’est pas facile d’établir un lien entre deux arbres différents. Les structures hiérarchiques des bases de données sont donc extrêmement rigides, quoique très claires.

Les ensembles de données qui ont des "enfants" sont appelés "enregistrements". Les enregistrements sans "enfants" sont appelés "feuilles" parce qu’ils contiennent généralement les documents dans une base de données hiérarchique. Les dossiers sont habituellement utilisés pour organiser les feuilles. Chaque requête dans une base de données hiérarchique accède à une feuille à partir de la racine à travers les enregistrements.

L’ensemble de données au milieu du graphique peut théoriquement ê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 supplémentaires. Les dépendances peuvent également être définies dans le modèle de base de données réseau : L’enregistrement 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’utilisateur peut accéder directement à l’enregistrement 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 interférer de manière significative avec la structure globale.

Aujourd’hui, le modèle de base de données en réseau est principalement utilisé sur les mainframes. Dans d’autres domaines, soit le modèle hiérarchique (en particulier pour les clients d’IBM) continue d’inspirer confiance, à moins que la transition vers un modèle relationnel 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 intéressants entre le modèle réseau et le modèle relationnel 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 perfectionnement moderne du modèle de réseau.

Le modèle de base de données relationnelle fonctionne avec des tables individuelles qui définissent la localisation et les liens entre les informations. Ces informations forment un ensemble de données (dans le diagramme d’une ligne ou d’un "tuple"). Les informations individuelles sont collectées sous forme d’attributs (dans les graphiques 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éralement définie comme le premier attribut (A1) et ne doit jamais changer, est élémentaire pour l’identification unique d’un enregistrement 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éralement 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 enregistré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 identifiés par le numéro d’identification unique (ID d’objet, OID). Comme vous pouvez le voir dans le diagramme, les objets individuels sont regroupés en classes d’objets, ce qui se traduit par une hiérarchie de classes. Bien qu’il semble y avoir une similitude avec le modèle de base de données hiérarchique, 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 profondeurs d’objets correspondantes. La base de données d’objets fonctionne de manière largement indépendante, sans trop d’intervention dans la normalisation et le référencement d’ID, et permet par la suite l’alimentation relativement 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 relationnelle, par exemple. Comme les systèmes de base de données orientés objet ne sont pas très populaires, cela conduit à une compatibilité insuffisante avec de nombreuses applications de base de données courantes.

Dans ce modèle, les documents constituent l’unité de base pour le stockage des données. Ils structurent les données et ne doivent pas être confondus avec des documents comme ceux utilisés dans les programmes 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 individuels 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écessaires dans ce modèle.

Dans le modèle relationnel (illustré dans le graphique avec les tableaux), diffé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 informations. Le schéma est librement sélectionnable : le modèle de base de données orientée document est conceptuellement exempt de schéma, à condition que le langage de base de données utilisé reste le même.

Une idée élémentaire 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 relationnelles affichent et sortent généralement des informations liées en reliant plusieurs tables, la requête spécifique d’un document dans le modèle basé sur les documents est suffisante. Ceci réduit le nombre d’opérations nécessaires dans la base de données.

Les systèmes de bases de données documentaires sont particulièrement intéressants pour les applications Web, car ils permettent d’alimenter des formulaires HTML complets. En particulier au cours du développement du web 2.0, les bases de données documentaires sont devenues de plus en plus populaires. Cependant, il existe des différences considérables entre les diffé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’application. C’est précisément à cause de ces différentes itérations 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.