Une base de données relationnelle organise les données en lignes et en colonnes, qui forment collectivement une table. Les données sont généralement structurées en plusieurs tables, qui peuvent être reliées entre elles par une clé primaire ou une clé externe. Ces identifiants uniques mettent en évidence les différentes relations qui existent entre les tables, et ces relations sont généralement illustrées par différents types de modèles de données. Les analystes utilisent des requêtes SQL pour combiner différents points de données et résumer les performances de l'entreprise, afin d'obtenir des renseignements, d'optimiser les flux de travail et d'identifier de nouvelles opportunités.

Par exemple, imaginez que votre entreprise gère une table de base de données contenant des informations sur les clients, qui contient des données sur l'entreprise au niveau d'un compte. Il peut également y avoir une table différente, qui décrit toutes les transactions individuelles qui se rapportent à ce compte. Ensemble, ces tables peuvent fournir des informations sur les différents secteurs qui achètent un produit logiciel spécifique.

Les colonnes (ou zones) de la table client peuvent être ID client, Nom de la société, Adresse de la société, Secteur d'activité etc. Les colonnes d'une table de transaction peuvent être Date de la transaction, ID client, Montant de la transaction, Mode de paiement, etc. Les tables peuvent être reliées entre elles à l'aide de la zone commune ID client.  Vous pouvez donc interroger la table pour produire des rapports utiles, tels que des rapports sur les ventes par secteur ou entreprise, qui peuvent fournir des informations pour les messages aux clients potentiels.

De plus, les bases de données relationnelles sont généralement associées à des bases de données transactionnelles, qui exécutent des commandes ou des transactions collectivement. Un virement bancaire est un bon exemple pour illustrer cela. Un montant défini est retiré d'un compte, puis déposé sur un autre compte. Le montant total est retiré et déposé, et cette transaction ne peut pas avoir lieu de manière partielle. Les transactions ont des propriétés spécifiques. Représentées par l'acronyme ACID, les propriétés sont définies comme suit :

• Atomicité : Toutes les modifications apportées aux données sont effectuées comme s'il s'agissait d'une opération unique. Autrement dit, toutes les modifications sont effectuées, ou bien aucune.

• Cohérence : Les données restent dans un état cohérent de bout en bout, ce qui renforce leur intégrité.

• Isolement : L'état intermédiaire d'une transaction n'est pas visible pour les autres transactions et par conséquent, les transactions qui s'exécutent simultanément apparaissent comme étant sérialisées.

• Durabilité : Lorsqu'une transaction aboutit, les modifications apportées aux données persistent et ne sont pas annulées, même en cas de défaillance du système.

Ces propriétés permettent un traitement fiable des transactions.

Base de données relationnelle et SGBDR

Alors qu'une base de données relationnelle organise les données sur la base d'un modèle de données relationnel, un système de gestion de base de données relationnelle (SGBDR) est une référence plus spécifique au logiciel de base de données sous-jacent qui permet aux utilisateurs de la maintenir. Ces programmes permettent aux utilisateurs de créer, mettre à jour, insérer ou supprimer des données dans le système et fournissent les éléments suivants :

• Structure de données

• Accès multi-utilisateur

• Contrôle des privilèges

• Accès réseau

MySQL, PostgreSQL et IBM Db2, par exemple, sont des systèmes SGBDR populaires. De plus, un système de base de données relationnelle diffère d'un système de gestion de base de données (SGBD) de base en ce qu'il stocke les données dans des tables, tandis qu'un SGBD stocke les informations sous forme de fichiers.

Inventé par Don Chamberlin et Ray Boyce chez IBM, le langage SQL (Structured Query Language) est le langage de programmation standard qui permet d'interagir avec les systèmes de gestion de bases de données relationnelles. Il permet aux administrateurs de base de données d'ajouter, de mettre à jour ou de supprimer facilement des lignes de données. Initialement appelé SEQUEL, son nom a été remplacé par SQL en raison d'un problème de marque déposée. Les requêtes SQL permettent également aux utilisateurs d'extraire des données de bases de données en seulement quelques lignes de code. Compte tenu de cette relation, il est facile de comprendre pourquoi les bases de données relationnelles sont parfois appelées « bases de données SQL ».  

En utilisant l'exemple ci-dessus, vous pouvez construire une requête pour trouver les 10 meilleures transactions par entreprise pour une année donnée 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 des données de cette manière nous aide à réduire la redondance au sein de nos systèmes de données, ce qui permet aux équipes de données de maintenir une table principale pour les clients au lieu de dupliquer ces informations en cas de futures transactions. Pour en savoir plus, Don détaille davantage l'historique de SQL dans son article ici (lien externe à IBM).

Avant les bases de données relationnelles, les entreprises utilisaient un système de base de données hiérarchique avec une structure en arborescence pour les tables de données. Ces premiers systèmes de gestion de bases de données (SGBD) permettaient aux utilisateurs d'organiser de grandes quantités de données. Cependant, ils étaient complexes, souvent réservés à une application particulière et limités dans la manière dont ils pouvaient découvrir les données. Ces limitations ont finalement conduit le chercheur d'IBM, Edgar F. Codd, à publier un article (lien externe à IBM - PDF de 1,5 Mo) en 1970, intitulé « A Relational Model of Data for Large Shared Data Banks », qui a permis de définir le modèle de base de données relationnelle. Dans ce modèle, des informations pouvaient être extraites sans connaissances informatiques particulières. 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, ce qui a finalement permis la fusion de données entre les tables.

En 1973, le laboratoire de recherche de San Jose, maintenant connu sous le nom de centre de recherche Almaden, a lancé un programme appelé System R (R pour relationnel) pour prouver cette théorie relationnelle avec ce qu'il appelait « une mise en œuvre de niveau industriel ». Il est finalement également devenu un terrain d'essai pour SQL, ce qui lui a permis d'être plus largement adopté en peu de temps. Cependant, l'adoption de SQL par Oracle n'a pas nui à sa popularité auprès des administrateurs de bases de données.

En 1983, IBM a introduit 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, c'est l'un des produits les plus performants d'IBM, qui continue à gérer des milliards de transactions chaque jour sur l'infrastructure cloud et définit la couche fondamentale pour les applications d'apprentissage automatique.

Pour en savoir plus sur l'historique d'IBM, cliquez ici.

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 effet, 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, qui ne sont pas idéaux pour les formats de données non structurés, comme les textes, les vidéos et les images. Ces types de bases de données incluent les éléments suivants :

• Bases de données de type clé-valeur : Ce modèle de données sans schéma est organisé en un dictionnaire de paires clé-valeur, dans lequel chaque élément possède une clé et une valeur. La clé pourrait être quelque chose de similaire à ce que l'on trouve dans une base de données SQL, comme l'identifiant d'un panier d'achat, tandis que la valeur est un tableau de données, comme chaque article individuel du panier d'achat de cet utilisateur. Elle est généralement utilisée pour la mise en cache et le stockage des informations de session utilisateur, comme les paniers d'achat. Cependant, ce n'est pas idéal lorsque vous devez extraire plusieurs enregistrements à la fois. Redis et Memcached sont des exemples de bases de données open source avec ce modèle de données.

• Bases de données orientées documents : Comme leur nom l'indique, ces bases de données stockent les données sous forme de documents. Elles peuvent être utiles pour gérer des données semi-structurées, et les données sont généralement stockées au format JSON, XML ou BSON. Cela permet de conserver les données ensemble lorsqu'elles sont utilisées dans des applications, ce qui réduit la quantité de traduction nécessaire pour utiliser les données. Les développeurs gagnent également en flexibilité car les schémas de données ne doivent pas nécessairement correspondre d'un document à l'autre (par exemple, nom ou prénom). Cependant, cela peut être problématique pour les transactions complexes et entraîner une altération des données. Les cas d'utilisation les plus courants des bases de données de documents incluent les systèmes de gestion de contenu et les profils utilisateur. MongoDB, le composant de base de données de la pile MEAN, est un exemple de base de données orientée documents.

• Bases de données orientées colonnes : Ces bases de données stockent les informations en colonnes, ce qui permet aux utilisateurs d'accéder uniquement aux colonnes spécifiques dont ils ont besoin sans allouer de mémoire supplémentaire à des données non pertinentes. Ces bases de données tentent de résoudre les lacunes des bases de données de type clé-valeur et des bases de données orientées documents, mais comme il peut s'agir d'un système plus complexe à gérer, il n'est pas recommandé de l'utiliser pour les équipes et les projets plus récents. Apache HBase et Apache Cassandra sont des exemples de bases de données open source orientées colonnes. Apache HBase est construit sur Hadoop Distributed Files System, qui fournit un moyen de stocker des ensembles de données éparses et est couramment utilisé dans de nombreuses applications de big data. Apache Cassandra, quant à lui, a été conçu pour gérer de grandes quantités de données sur plusieurs serveurs et des clusters qui s'étendent sur plusieurs centres de données. Il a été utilisé pour divers cas d'utilisation, tels que les sites Web de réseaux sociaux et l'analyse de données en temps réel.

• Bases de données orientées 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'arêtes et de propriétés. Tout objet, lieu ou personne peut être un nœud. Une arête définit la relation entre les nœuds. Les bases de données orientées graphe sont utilisées pour stocker et gérer un réseau de connexions entre les éléments d'un graphe. Neo4j (lien externe à IBM) est un service de base de données orientée graphe basé sur Java avec une édition communautaire open source dans laquelle les utilisateurs peuvent acheter des licences pour la sauvegarde en ligne et les extensions de haute disponibilité, ou une version sous licence pré-conditionnée avec copie de sauvegarde et extensions incluses.

Les bases de données NoSQL donnent également la priorité à la disponibilité plutôt qu'à la cohérence.

Lorsque des ordinateurs fonctionnent en réseau, ils doivent invariablement décider s'ils doivent donner la priorité à des résultats cohérents (dans lesquels chaque réponse est toujours la même) ou à un temps de fonctionnement élevé, appelé « disponibilité ». C'est ce qu'on appelle la théorie CAP (Consistency, Availability, or Partition Tolerance). 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 fournir toujours une réponse. Cela signifie que les informations que vous recevez suite à une requête peuvent être incorrectes de quelques secondes, voire d'une demi-minute. Sur les sites de médias sociaux, vous verrez par exemple une ancienne photo de profil alors que la plus récente a été mise à jour quelques instants auparavant. Il peut aussi se produire un délai d'attente ou une erreur. En revanche, dans les transactions bancaires et financières, une erreur et une nouvelle soumission peuvent être préférables à des informations anciennes et incorrectes.

Pour un récapitulatif complet des différences entre SQL et NoSQL, voir « Différence entre les bases de données SQL et NoSQL ».

Le principal avantage d'une base de données relationnelle est qu'elle permet de créer des informations significatives en reliant les tables. La liaison des tables vous permet de comprendre les relations entre les données, ou la façon dont les tables sont connectées. Le langage SQL permet de compter, d'ajouter, de grouper et de combiner des requêtes. SQL peut exécuter des fonctions mathématiques et de sous-total de base ainsi que des transformations logiques. Les analystes peuvent ordonner les résultats par date, nom ou toute autre colonne. Ces caractéristiques font de l'approche relationnelle l'outil de requête le plus populaire du marché.

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

Simplicité d'utilisation

En raison de la durée de vie du produit, il existe une plus grande communauté autour des bases de données relationnelles, ce qui perpétue en partie leur utilisation continue. SQL permet également d'extraire facilement des jeux de données de plusieurs tables et d'effectuer des transformations simples telles que le filtrage et le regroupement. L'utilisation d'index dans les bases de données relationnelles permet également de localiser rapidement ces informations sans rechercher chaque ligne dans la table sélectionnée.

Si les bases de données relationnelles ont toujours été considérées comme une option de stockage des données plus rigide et inflexible, les progrès technologiques et les options DBaaS modifient cette perception. Bien que le développement de schémas soit toujours plus coûteux que celui des bases de données NoSQL, les bases de données relationnelles deviennent plus flexibles à mesure qu'elles migrent 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 appelé normalisation. Comme indiqué précédemment, une table de clients ne doit enregistrer que des enregistrements uniques d'informations sur les clients, sans dupliquer ces informations pour plusieurs transactions.

Les procédures mémorisées aident également à réduire le travail répétitif. Par exemple, si l'accès à la base de données est limité à certains rôles, fonctions ou équipes, une procédure mémorisée peut aider à gérer le contrôle d'accès. Ces fonctions réutilisables libèrent le temps précieux des développeurs d'applications qui peuvent ainsi s'attaquer à des tâches à fort impact.

Simplicité de la sauvegarde et de la reprise après incident 

Les bases de données relationnelles sont transactionnelles, c'est-à-dire qu'elles garantissent la cohérence de l'état du système tout entier à tout moment. La plupart des bases de données relationnelles proposent des options d'exportation et d'importation simples à utiliser qui facilitent considérablement la sauvegarde et la restauration. Ces exportations peuvent avoir lieu même lorsque la base de données est en cours d'exécution, ce qui facilite la restauration suite à une défaillance. Les bases de données relationnelles modernes sur le cloud peuvent effectuer une mise en miroir continue, la perte de données lors de la restauration durant quelques secondes, voire moins. La plupart des services gérés sur le cloud vous permettent de créer des répliques en lecture, comme dans IBM Cloud® Databases for PostgreSQL. Ces répliques en lecture vous permettent de stocker une copie en lecture seule de vos données dans un centre de données cloud. Les répliques peuvent également être transformées en instances de lecture/écriture pour la reprise après incident.