Inventé par Don Chamberlin et Ray Boyce chez IBM, le langage SQL (Structured Query Language) est le langage de programmation standard permettant d’interagir avec les systèmes de gestion de base de données relationnelle. Avec lui, l’administrateur de bases de données peut ajouter, mettre à jour ou supprimer facilement des lignes de données. Initialement connu sous le nom de SEQUEL, il a été abrégé en SQL en raison d’un problème de dépôt de marque. Les requêtes SQL permettent également aux utilisateurs de récupérer des données à partir de bases de données en utilisant seulement quelques lignes de code. Compte tenu de ce lien étroit, nous pouvons facilement comprendre pourquoi les bases de données relationnelles sont parfois également désignées par le terme « bases de données SQL ».  

En reprenant l’exemple ci-dessus, vous pourriez créer une requête pour trouver les 10 premières transactions d’une année spécifique par entreprise avec le code suivant :

SELECT COMPANY_NAME, SUM(TRANSACTION_AMOUNT)

FROM TRANSACTION_TABLE A

LEFT JOIN CUSTOMER_TABLE B

ON A.CUSTOMER_ID = B.CUSTOMER_ID

WHERE YEAR(DATE) = 2022

GROUP BY 1

ORDER BY 2 DESC

LIMIT 10

La possibilité de relier les données de cette manière réduit la redondance au sein de nos systèmes de données, permettant aux équipes chargées des données de maintenir une table principale pour les clients plutôt que de dupliquer ces informations en cas de nouvelle transaction. Si vous souhaitez en savoir plus, Don détaille l’histoire du langage SQL dans son article (lien externe à IBM).

Avant les bases de données relationnelles, les entreprises utilisaient un système de base de données hiérarchique dont les tables étaient structurées en arborescence. Ces premiers systèmes de gestion de base de données (SGBD) permettaient aux utilisateurs d’organiser de grandes quantités de données. Cependant, ils étaient complexes, souvent exclusifs à une application particulière, et limités dans les méthodes de découverte des données. Ces limitations ont finalement conduit Edgar F. Codd, chercheur chez IBM, à publier un article (lien externe à IBM) (PDF, 1,5 Mo) en 1970 intitulé « A Relational Model of Data for Large Shared Data Banks », théorisant le modèle de base de données relationnelle. Dans le modèle proposé, les informations pouvaient être récupérées sans connaissances informatiques spécialisées. Il proposait d’organiser les données en fonction de relations significatives sous forme de tuples, ou de paires attribut-valeur. Les ensembles de tuples étaient appelés relations, permettant en fin de compte la fusion des données entre les tables.

En 1973, le San Jose Research Laboratory, aujourd’hui connu sous le nom d’Almaden Research Center, lançait un programme intitulé System R (R pour relationnel) pour prouver cette théorie relationnelle avec ce qu’il appelait « une mise en œuvre de puissance industrielle ». Ce programme est finalement également devenu un terrain d’essai pour SQL, ce qui lui a permis d’être plus largement adopté dans un court laps de temps. Mais ne négligeons pas l’adoption de SQL par Oracle, qui lui a fait de la publicité auprès des administrateurs de bases de données.

En 1983, IBM lançait la famille de bases de données relationnelles DB2, ainsi nommée parce qu’il s’agissait de la deuxième famille de logiciels de gestion de bases de données d’IBM. Aujourd’hui, il s’agit de l’un des produits les plus populaires d’IBM, qui continue de traiter des milliards de transactions chaque jour sur l’infrastructure cloud et constitue la couche fondamentale des applications de machine learning.

Alors que les bases de données relationnelles structurent les données dans un format tabulaire, les bases de données non relationnelles n’ont pas un schéma de base de données aussi rigide. En fait, les bases de données non relationnelles organisent les données différemment en fonction du type de base de données. Quel que soit le type de base de données non relationnelle, elles visent toutes à résoudre les problèmes de flexibilité et d’évolutivité inhérents aux modèles relationnels non adaptés aux données non structurées, tels que le texte, la vidéo et les images. Ces types de bases de données sont les suivants :

• Magasin clé-valeur : Ce modèle de données sans schéma est organisé en dictionnaire de paires clé-valeur, où chaque élément possède une clé et une valeur. Les clés peuvent être similaires à celles des bases de données SQL, comme l’ID d’un panier d’achat, tandis que les valeurs sont des ensembles de données, par exemple chaque article du panier d’achat de l’utilisateur. Ce modèle est couramment utilisé pour mettre en cache et stocker les informations de session utilisateur, par exemple les paniers d’achat. Mais ce type de base de données n’est pas vraiment adapté à l’extraction de plusieurs enregistrements à la fois. Redis et Memcached sont des exemples de bases de données open source qui utilisent ce modèle de données.

• Magasin de documents : Comme leur nom l’indique, les bases de données orientées documents stockent les données sous forme de documents. Elles peuvent être utiles pour gérer des données semi-structurées, qui sont généralement stockées aux formats JSON, XML ou BSON. Cela permet de garder les données ensemble lorsqu’elles sont utilisées dans des applications, réduisant ainsi le nombre de translations nécessaires à leur utilisation. Les développeurs bénéficient également d’une plus grande flexibilité, car les schémas de données n’ont pas besoin de correspondre entre les documents (par exemple name et first_name). Cependant, cela peut être problématique pour les transactions complexes, et entraîner la corruption des données. Parmi les cas d’utilisation courants des bases de données orientées documents, citons les systèmes de gestion de contenu et les profils d’utilisateurs. MongoDB, le composant de base de données de la pile MEAN, est un exemple de base de données orientée documents.

• Magasin à colonnes larges : Ces bases de données stockent les informations dans des colonnes, ce qui permet aux utilisateurs d’accéder uniquement aux colonnes dont ils ont besoin sans allouer de mémoire supplémentaire à des données non pertinentes. Cette base de données tente de combler les lacunes des magasins clé-valeur et des magasins de documents, mais comme il peut s’agir d’un système plus complexe à gérer, elle n’est pas recommandée pour les équipes et les projets qui débutent. Apache HBase et Apache Cassandra sont des exemples de bases de données à colonnes larges open source. Apache HBase repose sur Hadoop Distributed Files System, qui permet de stocker des jeux de données épars, une solution couramment utilisée dans de nombreuses applications de big data. Apache Cassandra, quant à elle, a été conçue pour gérer de grandes quantités de données sur plusieurs serveurs et clusters répartis dans plusieurs centres de données. Elle est utilisée pour une variété de cas d'utilisation, comme les sites web des réseaux sociaux et l’analyse de données en temps réel.

• Magasin de graphes : Ce type de base de données héberge généralement les données d’un graphe de connaissances. Les éléments de données sont stockés sous forme de nœuds, d’arcs et de propriétés. N’importe quel objet, lieu ou personne peut être un nœud. Un arc définit la relation entre les noeuds. Les bases de données orientées graphes sont utilisées pour stocker et gérer un réseau de connexions entre les éléments du graphe. Neo4j (lien externe à IBM) est un service de base de données orientée graphes basé sur Java avec une édition communautaire open source où les utilisateurs peuvent acheter des licences pour la sauvegarde en ligne et des extensions haute disponibilité, ou une version sous licence préconfigurée avec sauvegarde et extensions incluses.

Les bases de données NoSQL privilégient également la disponibilité par rapport à la cohérence.

Lorsque les ordinateurs fonctionnent sur un réseau, ils doivent invariablement décider de donner la priorité à des résultats cohérents (où chaque réponse est toujours la même) ou à un temps de fonctionnement élevé, appelé « disponibilité ». C’est ce qu’on appelle le « théorème CAP » : cohérence, disponibilité ou tolérance au partitionnement. Les bases de données relationnelles garantissent que les informations sont toujours synchronisées et cohérentes. Certaines bases de données NoSQL, comme Redis, préfèrent toujours fournir une réponse. Cela signifie que les informations que vous recevez suite à une requête peuvent être incorrectes à quelques secondes près, voire à une demi-minute. Sur les réseaux sociaux, cela se traduit par l’affichage d’une ancienne photo de profil alors que la plus récente ne date que de quelques instants. Un délai d’attente dépassé ou une erreur sont d’autres possibilités. En revanche, pour les transactions bancaires et financières, une erreur et un nouvel envoi peuvent être préférables à l’obtention d’anciennes informations incorrectes.

Pour un aperçu complet des différences entre SQL et NoSQL, consultez la rubrique « Bases de données SQL et NoSQL : quelle est la différence ? »

Le principal avantage des bases de données relationnelles, c’est la possibilité d’obtenir des informations significatives en reliant les tables. La jonction de tables permet de comprendre les relations entre les données, c’est-à-dire les connexions entre les tables. SQL permet de compter, d’ajouter, de regrouper et de combiner des requêtes. SQL peut exécuter des fonctions mathématiques de base, des sous-totaux et des transformations logiques. Les analystes peuvent trier les résultats par date, par nom ou par colonne. Ces caractéristiques font de l’approche relationnelle l’outil de requête le plus populaire dans les entreprises d’aujourd’hui.

Les bases de données relationnelles présentent plusieurs avantages par rapport aux autres formats de base de données :

Facilité d'utilisation

En raison de la durée de vie des produits, il existe une plus grande communauté autour des bases de données relationnelles, ce qui perpétue partiellement son utilisation. SQL permet également de récupérer facilement des jeux de données à partir de plusieurs tables et d’effectuer des transformations simples telles que le filtrage et l’agrégation. L’utilisation d’index dans les bases de données relationnelles permet également de localiser rapidement ces informations sans avoir à effectuer de recherche dans chaque ligne de la table sélectionnée.

Alors que les bases de données relationnelles ont toujours été considérées comme une option de stockage de données plus rigide et moins flexible, les avancées des technologies et des options DBaaS changent cette perception. Même si le développement de schémas est plus coûteux que dans les bases de données NoSQL, les bases de données relationnelles deviennent plus flexibles avec la migration vers des environnements cloud.

Redondance réduite 

Les bases de données relationnelles peuvent éliminer la redondance de deux manières. Le modèle relationnel lui-même réduit la redondance des données via un processus connu sous le nom de normalisation. Comme indiqué précédemment, une table client ne devrait consigner que des enregistrements uniques d’informations client plutôt que de dupliquer ces informations pour plusieurs transactions.

Les procédures stockées contribuent également à réduire les tâches répétitives. Par exemple, si l’accès à la base de données est limité à certains rôles, fonctions ou équipes, les procédures stockées peuvent permettre de gérer les contrôles d’accès. Ces fonctions réutilisables libèrent les développeurs d’applications pour qu’ils puissent se consacrer à des tâches plus importantes.

Facilité de sauvegarde et de reprise après incident 

Les bases de données relationnelles sont transactionnelles : elles garantissent la cohérence de l’état de l’ensemble du système à tout moment. La plupart des bases de données relationnelles proposent des options d’exportation et d’importation simples d’utilisation, facilitant considérablement la sauvegarde et la restauration. Ces exportations peuvent être effectuées même lorsque la base de données est en cours d’exécution, ce qui facilite la restauration en cas d’arrêt anormal. Les bases de données relationnelles modernes basées sur le cloud peuvent effectuer une mise en miroir continue, ce qui permet de mesurer la perte de données lors de la restauration en quelques secondes ou moins. La plupart des services gérés dans le cloud vous permettent de créer des réplicas en lecture, comme dans IBM Cloud Databases for PostgreSQL. Ces réplicas en lecture vous permettent de stocker une copie en lecture seule de vos données dans un centre de données cloud. Les réplicas peuvent également être promus vers des instances de lecture/écriture pour la reprise après incident.