Comprendre les bases de données relationnelles

Introduction

Les systèmes de gestion des bases de données (SGDB ou DBMS en anglais) sont des programmes informatiques qui permettent aux utilisateurs d’interagir avec une base de données. Un SGDB permet aux utilisateurs de contrôler l’accès à une base de données, d’écrire des données, d’exécuter des requêtes et d’effectuer toute autre tâche liée à la gestion de base de données.

Pour effectuer l’une de ces tâches, cependant, le SGDB doit avoir une sorte de modèle sous-jacent qui définit la manière dont les données sont organisées. Le modèle relationnel est une approche d’organisation des données qui ont trouvé un large usage dans le logiciel de base de données depuis sa conception initiale à la fin des années 1960, à tel point que, à partir de ce texte, quatre des cinq SGDB les plus populaires sont relationnels.

Cet article conceptuel décrit l’historique du modèle relationnel, la manière dont les bases de données relationnelles organisent les données, et leur utilisation aujourd’hui.

Histoire du modèle relationnel

Les bases de données sont des groupes d’informations ou de données modélisés de manière logique**. Toute collecte de données est une base de données, quel que soit la manière dont elle est stockée ou l’endroit où elle est stockée. Même un classeur de fichiers contenant des informations sur les salaires est une base de données, tout comme une pile de formulaires de patients d’un hôpital ou la collecte d’informations sur les clients d’une entreprise répartis dans plusieurs endroits. Avant que le stockage et la gestion des données à l’aide d’ordinateurs ne soit une pratique courante, les bases de données physiques comme celles-ci étaient les seules dont disposaient les organisations gouvernementales et commerciales qui avaient besoin de stocker des informations.

Vers le milieu du XXe siècle, les développements en informatique ont conduit à la mise au point de machines plus puissantes, ainsi qu’à une plus grande capacité de stockage local et externe. Ces progrès ont conduit les informaticiens à commencer à reconnaître le potentiel de ces machines pour stocker et gérer des quantités de données toujours plus importantes.

Cependant, il n’existait pas de théories sur la manière dont les ordinateurs pouvaient organiser les données de manière logique et significative. C’est une chose de stocker des données non triées sur une machine, mais il est beaucoup plus compliqué de concevoir des systèmes qui vous permettent d’ajouter, récupérer, trier et gérer ces données d’une manière cohérente et pratique. La nécessité d’un cadre logique pour stocker et organiser les données a conduit à un certain nombre de propositions d’utilisation des ordinateurs pour la gestion des données.

L’un des premiers modèles de base de données était le modèle hiérarchique, dans lequel les données sont organisées dans une structure arborescente ressemblant semblables aux systèmes de fichiers modernes. L’exemple suivant montre à quoi pourrait ressembler la disposition d’une partie d’une base de données hiérarchique utilisée pour classer les animaux : :

Le modèle hiérarchique a été largement appliqué dans les systèmes de gestion de base de données, mais il s’est également avéré peu flexible. Dans ce modèle, même si les enregistrements individuels peuvent avoir plusieurs enregistrements “enfant”, chaque enregistrement ne peut avoir qu’un seul “parent” dans la hiérarchie. Pour cette raison, ces bases de données hiérarchiques antérieures se limitaient à représenter uniquement des relations "“un à un” et “un à plusieurs” Cette absence de relations “de plusieurs à plusieurs”  pourrait entraîner des problèmes lorsque vous travaillez avec des points de données que vous souhaitez associer à plus d’un parent.

À la fin des années 1960, Edgar F. Codd, un informaticien chez IBM, a mis au point le modèle relationnel de gestion de base de données. Le modèle relationnel de Codd a permis à des enregistrements individuels d’être associés à plus d’une table, permettant ainsi des relations “de plusieurs à plusieurs” entre les points de données en plus des relations “d’un à plusieurs”.  Cela a permis une plus grande flexibilité que d’autres modèles existants en ce qui concerne la conception des structures de base de données, ce qui signifie que les systèmes de gestion de bases de données relationnelles (SGBDR) pouvaient répondre à un éventail beaucoup plus large de besoins commerciaux.

Codd a proposé un langage pour gérer les données relationnelles, connu sous le nom d’Alpha, qui a influencé le développement de langages de base de données ultérieurs. Deux des collègues de Codd chez IBM, Donald Chamberlin et Raymond Boyce, ont créé un tel langage inspirée d’Alpha. Ils ont appelé leur langue SEQUEL, anagramme de   S tructured  E nglish  Que ry  L anguage, mais en raison d’une marque existante ils ont raccourci le nom de leur langage à SQL (appelé de manière plus formelle Structured Query Language).

En raison de contraintes matérielles, les premières bases de données relationnelles étaient excessivement lentes, et il a fallu un certain temps avant que la technologie ne se généralise. Mais au milieu des années 1980, le modèle relationnel de Codd a été mis en œuvre dans un certain nombre de produits de gestion de base de données commerciales d’IBM et de ses concurrents. Ces entreprises ont également suivi l’initiative d’IBM en développant et en mettant en œuvre leurs propres dialectes de SQL. En 1987, l’American National Standards Institute et l’International Organization for Standardization avaient tous deux ratifié et publié des normes pour SQL, consolidant ainsi son statut de langage accepté pour la gestion des SGBDR.

L’utilisation du modèle relationnel dans plusieurs industries a conduit à sa reconnaissance en tant que modèle standard de gestion des données. Même avec l’essor de différentes bases de données NoSQL ces dernières années, les bases de données relationnelles restent les outils dominants pour le stockage et l’organisation des données.

Comment les bases de données relationnelles organisent les données

Maintenant que vous avez une compréhension générale de l’histoire du modèle relationnel, examinons de plus près la manière dont le modèle organise les données.

Les éléments les plus fondamentaux du modèle relationnel sont les relations que les utilisateurs et les SGBDR modernes reconnaissent comme tableaux. Une relation est un ensemble de tuples, ou de lignes dans une table, avec chaque tuple partageant un ensemble d’attributs, ou colonnes :

Une colonne est la plus petite structure organisationnelle d’une base de données relationnelle, et représente les différentes facettes qui définissent les enregistrements de la table. D’où leur nom plus formel, les attributs. Vous pouvez penser à chaque tuple comme une instance unique de n’importe quel type de personnes, objets, événements ou associations que la table contient. Ces instances peuvent être des éléments comme les employés d’une entreprise, les ventes d’une entreprise en ligne ou les résultats de test en laboratoire. Par exemple, dans une table contenant les enregistrements des enseignants d’une école, les tuples peuvent avoir des attributs comme name, subjects, start_date, etc.

Lorsque vous créez des colonnes, vous spécifiez un type de données qui dicte le type d’entrées autorisées dans cette colonne. Les SGBDR mettent souvent en œuvre leurs propres types de données uniques, qui peuvent ne pas être directement interchangeables avec des types de données similaires dans d’autres systèmes. Les types de données les plus courants comprennent les dates, les chaînes de caractères, les entiers et les Booléens.

Dans le modèle relationnel, chaque table contient au moins une colonne qui peut être utilisée pour identifier de manière unique chaque ligne, appelée clé primaire. C’est important, car cela signifie que les utilisateurs n’ont pas à savoir où leurs données sont physiquement stockées sur une machine, au lieu de cela, leur SGBD peut suivre chaque enregistrement et les renvoyer sur une base ad hoc. Cela signifie que les enregistrements n’ont pas d’ordre logique défini, et que les utilisateurs ont la possibilité de renvoyer leurs données dans n’importe quel ordre ou par les filtres qu’ils souhaitent.

Si vous souhaitez associer deux tables l’une à l’autre, vous pouvez le faire avec une clé étrangère. Une clé étrangère est essentiellement une copie de la clé primaire d’une table (la table “parent”) insérée dans une colonne d’une autre table (l’“enfant”). L’exemple suivant met en évidence la relation entre deux tableaux, l’un utilisé pour enregistrer les informations relatives aux employés d’une entreprise et l’autre utilisée pour suivre les ventes de l’entreprise. Dans cet exemple, la clé principale du tableau EMPLOYEES est utilisée comme clé étrangère du tableau SALES :

Si vous essayez d’ajouter un enregistrement au tableau enfant et que la valeur saisie dans la colonne de clé étrangère n’existe pas dans la clé primaire du tableau parent, l’instruction d’insertion sera invalide. Cela aide à maintenir l’intégrité au niveau des relations, car les lignes des deux tableaux seront toujours correctement reliées.

Les éléments structurels du modèle relationnel aident à conserver les données stockées de manière organisée, mais la conservation des données n’est utile que si vous pouvez les récupérer. Pour récupérer des informations d’un SGBDR, vous pouvez émettre une query ou une requête structurée d’un ensemble d’informations. Comme mentionné précédemment, la plupart des bases de données relationnelles utilisent SQL pour gérer et interroger les données. SQL vous permet de filtrer et de manipuler les résultats de requête avec une variété de clauses, de prédicats et d’expressions, vous donnant un contrôle précis sur les données qui apparaîtront dans l’ensemble de résultats.

Avantages et limitations des bases de données relationnelles

En tenant compte de la structure organisationnelle sous-jacente des bases de données relationnelles, examinons quelques-uns de leurs avantages et de leurs inconvénients.

Aujourd’hui, tant SQL que les bases de données qui l’implémentent s’écartent du modèle relationnel de Codd de plusieurs façons. Par exemple, le modèle de Codd dicte que chaque ligne d’une table doit être unique tandis que, pour des raisons pratiques, la plupart des bases de données relationnelles modernes permettent de dupliquer les lignes. Certaines personnes ne considèrent pas les bases de données SQL comme de véritables bases de données relationnelles si elles ne respectent pas chacune des spécifications du modèle relationnel de Codd. En termes pratiques, cependant, tout SGBD qui utilise SQL et qui adhère au moins en partie au modèle relationnel est susceptible d’être appelé un système de gestion de base de données relationnelles.

Bien que les bases de données relationnelles aient rapidement gagné en popularité, certaines des lacunes du modèle relationnel ont commencé à apparaître lorsque les données prenaient de la valeur et que les entreprises ont commencé à en stocker davantage. La scalabilité horizontale, ou scaling out, est la pratique qui consiste à ajouter plus de machines à une pile existante afin de répartir la charge et de permettre un traffic plus important et un traitement plus rapide. Cette opération est souvent opposée à la mise à la scalabilité verticale qui implique la mise à niveau du matériel d’un serveur existant, généralement en ajoutant plus de RAM ou de CPU.

La raison pour laquelle il est difficile de faire évoluer une base de données relationnelle horizontalement est liée au fait que le modèle relationnel est conçu pour assurer la cohérence, ce qui signifie que les clients qui interrogent la même base de données récupèrent toujours les mêmes données. Si vous devez faire évoluer une base de données relationnelle horizontalement sur plusieurs machines, il devient difficile d’en garantir la cohérence car les clients peuvent parfois écrire des données sur un nœud, sans le faire sur les autres. Il y aurait probablement un délai entre l’écriture initiale et le moment où les autres nœuds sont mis à jour pour refléter les changements, ce qui entraînerait des incohérences entre eux.

Une autre limitation présentée par les SGDBR est que le modèle relationnel a été conçu pour gérer des données structurées, ou des données qui s’alignent avec un type de données prédéfini ou qui sont au moins organisées d’une manière prédéterminée, ce qui les rend facilement triables et consultables. Toutefois, avec le développement de l’informatique personnelle et l’essor d’Internet au début des années 1990, les données non structurées — telles que les messages électroniques, les photos, les vidéos, etc. — sont devenues plus fréquentes.

Rien de cela ne veut dire que les bases de données relationnelles ne sont pas utiles. Au contraire, le modèle relationnel est toujours le cadre dominant de la gestion des données après plus de 40 ans. Leur prévalence et leur longévité signifient que les bases de données relationnelles sont une technologie mature, qui est en soi l’un de leurs avantages majeurs. Il existe de nombreuses applications conçues pour fonctionner avec le modèle relationnel, ainsi que de nombreux administrateurs de base de données de carrière qui sont des experts en matière de bases de données relationnelles. Il existe également un large éventail de ressources disponibles sur papier et en ligne pour ceux qui souhaitent se lancer dans les bases de données relationnelles.

Un autre avantage des bases de données relationnelles est que presque tous les SGBDR prennent en charge les transactions. Une transaction consiste en une ou plusieurs des instructions SQL individuelles exécutées en séquence comme une seule unité de travail. Les transactions présentent une approche de type tout-ou rien, ce qui signifie que chaque instruction SQL de la transaction doit être valide ; sinon, la transaction entière échouera. Ceci est très utile pour garantir l’intégrité des données lors de modifications de plusieurs lignes ou tableaux.

Enfin, les bases de données relationnelles sont extrêmement flexibles. Elles ont été utilisées pour construire une grande variété d’applications différentes, et continuent de fonctionner efficacement même avec de très grandes quantités de données. SQL est également extrêmement puissant, vous permettant d’ajouter et de modifier des données au vol, ainsi que de modifier la structure des schémas et des tableaux de base de données sans incidence sur les données existantes.

Conclusion

Grâce à leur flexibilité et à leur conception pour l’intégrité des données, les bases de données relationnelles sont toujours le principal moyen de gérer et de stocker les données plus de cinquante ans après leur conception. Même avec l’essor de diverses bases de données NoSQL ces dernières années, la compréhension du modèle relationnel et de la manière de travailler avec les SGBDR sont la clé pour tous ceux qui veulent construire des applications qui exploitent la puissance des données.

Pour en savoir plus sur quelques SGBDR open source populaires, nous vous encourageons à consulter notre comparaison de différentes bases de données SQL relationnelles open-source. Si vous souhaitez en savoir plus sur les bases de données en général, nous vous encourageons à consulter notre bibliothèque complète de contenus liés aux bases de données.