Base de données relationnelle

Une base de données relationnelle ( RDB ) est une base de données basée sur le modèle relationnel de données, tel que proposé par EF Codd en 1970.

Un système de gestion de base de données utilisé pour maintenir des bases de données relationnelles est un système de gestion de base de données relationnelle ( SGBDR ).

De nombreux systèmes de bases de données relationnelles sont équipés de la possibilité d'utiliser SQL (Structured Query Language) pour interroger et mettre à jour la base de données.

Le concept de base de données relationnelle a été défini par EF Codd chez IBM en 1970. Codd a introduit le terme relationnel dans son article de recherche « A Relational Model of Data for Large Shared Data Banks ». Dans cet article et dans d'autres articles ultérieurs, il a défini ce qu'il entendait par relation . Une définition bien connue de ce qui constitue un système de base de données relationnelle est composée des 12 règles de Codd .

Cependant, aucune implémentation commerciale du modèle relationnel n'est conforme à toutes les règles de Codd, de sorte que le terme en est progressivement venu à décrire une classe plus large de systèmes de bases de données, qui au minimum :

1. Présenter les données à l'utilisateur sous forme de relations (une présentation sous forme de tableau, c'est-à-dire sous forme d'un ensemble de tableaux , chaque tableau étant constitué d'un ensemble de lignes et de colonnes ) ;
2. Fournir des opérateurs relationnels pour manipuler les données sous forme tabulaire.

En 1974, IBM a commencé à développer System R , un projet de recherche visant à développer un prototype de SGBDR. Le premier système vendu en tant que SGBDR était Multics Relational Data Store (juin 1976). Oracle a été publié en 1979 par Relational Software, aujourd'hui Oracle Corporation . Ingres et IBM BS12 ont suivi. D'autres exemples de SGBDR incluent IBM Db2 , SAP Sybase ASE et Informix . En 1984, le premier SGBDR pour Macintosh a commencé à être développé, sous le nom de code Silver Surfer, et a été publié en 1987 sous le nom de 4th Dimension et connu aujourd'hui sous le nom de 4D.

Les premiers systèmes qui étaient des implémentations relativement fidèles du modèle relationnel provenaient de :

• Université du Michigan – Micro DBMS (1969)
• Institut de technologie du Massachusetts (1971)
• Centre scientifique IBM UK à Peterlee – IS1 (1970–72), et son successeur, PRTV (1973–79).

La définition la plus courante d'un SGBDR est un produit qui présente une vue des données sous la forme d'un ensemble de lignes et de colonnes, même s'il n'est pas strictement basé sur la théorie relationnelle . Selon cette définition, les produits SGBDR implémentent généralement certaines, mais pas toutes, des 12 règles de Codd.

Une deuxième école de pensée soutient que si une base de données n'implémente pas toutes les règles de Codd (ou la compréhension actuelle du modèle relationnel, telle qu'exprimée par Christopher J. Date , Hugh Darwen et d'autres), elle n'est pas relationnelle. Ce point de vue, partagé par de nombreux théoriciens et autres adhérents stricts des principes de Codd, disqualifierait la plupart des SGBD comme non relationnels. Pour plus de clarté, ils font souvent référence à certains SGBDR comme des systèmes de gestion de bases de données véritablement relationnelles (SGBDR), en nommant d'autres des systèmes de gestion de bases de données pseudo-relationnelles (SGBDR).

En 2009, la plupart des SGBD relationnels commerciaux utilisent SQL comme langage de requête .

Des langages de requête alternatifs ont été proposés et implémentés, notamment l'implémentation d' Ingres QUEL avant 1996 .

Un modèle relationnel organise les données en une ou plusieurs tables (ou « relations ») de colonnes et de lignes , avec une clé unique identifiant chaque ligne. Les lignes sont également appelées enregistrements ou tuples . Les colonnes sont également appelées attributs. En général, chaque table/relation représente un « type d'entité » (comme un client ou un produit). Les lignes représentent des instances de ce type d' entité (comme « Lee » ou « chaise ») et les colonnes représentent des valeurs attribuées à cette instance (comme une adresse ou un prix).

Par exemple, chaque ligne d'un tableau de classe correspond à une classe, et une classe correspond à plusieurs étudiants, donc la relation entre le tableau de classe et le tableau d'étudiants est « un à plusieurs »

Chaque ligne d'une table possède sa propre clé unique. Les lignes d'une table peuvent être liées aux lignes d'autres tables en ajoutant une colonne pour la clé unique de la ligne liée (ces colonnes sont appelées clés étrangères ). Codd a montré que les relations de données d'une complexité arbitraire peuvent être représentées par un ensemble simple de concepts.

Une partie de ce traitement consiste à pouvoir sélectionner ou modifier de manière cohérente une seule ligne dans une table. Par conséquent, la plupart des implémentations physiques ont une clé primaire (PK) unique pour chaque ligne d'une table. Lorsqu'une nouvelle ligne est écrite dans la table, une nouvelle valeur unique pour la clé primaire est générée ; il s'agit de la clé que le système utilise principalement pour accéder à la table. Les performances du système sont optimisées pour les PK. D'autres clés plus naturelles peuvent également être identifiées et définies comme des clés alternatives (AK). Souvent, plusieurs colonnes sont nécessaires pour former une AK (c'est l'une des raisons pour lesquelles une seule colonne d'entiers est généralement désignée comme PK). Les PK et les AK ont la capacité d'identifier de manière unique une ligne dans une table. Une technologie supplémentaire peut être appliquée pour garantir un identifiant unique dans le monde entier, un identifiant unique mondial , lorsque les exigences du système sont plus larges.

Les clés primaires d'une base de données servent à définir les relations entre les tables. Lorsqu'une clé primaire migre vers une autre table, elle devient une clé étrangère (FK) dans l'autre table. Lorsque chaque cellule ne peut contenir qu'une seule valeur et que la clé primaire migre vers une table d'entités standard, ce modèle de conception peut représenter une relation un-à-un ou un-à-plusieurs . La plupart des conceptions de bases de données relationnelles résolvent les relations plusieurs-à-plusieurs en créant une table supplémentaire qui contient les clés primaires des deux autres tables d'entités. La relation devient alors une entité. La table de résolution est alors nommée de manière appropriée et les deux clés primaires sont combinées pour former une clé primaire. La migration des clés primaires vers d'autres tables est la deuxième raison principale pour laquelle les entiers attribués par le système sont normalement utilisés comme clés primaires. La migration d'un ensemble d'autres types de colonnes n'est généralement ni efficace ni claire.

Les relations sont une connexion logique entre différentes tables (entités), établie sur la base de l'interaction entre ces tables. Ces relations peuvent être modélisées selon un modèle entité-relation .

Pour qu'un système de gestion de base de données (SGBD) fonctionne efficacement et avec précision, il doit utiliser des transactions ACID .

Une partie de la programmation au sein d'un SGBDR est réalisée à l'aide de procédures stockées (SP). Souvent, les procédures peuvent être utilisées pour réduire considérablement la quantité d'informations transférées à l'intérieur et à l'extérieur d'un système. Pour une sécurité accrue, la conception du système peut accorder l'accès uniquement aux procédures stockées et non directement aux tables. Les procédures stockées fondamentales contiennent la logique nécessaire pour insérer de nouvelles données et mettre à jour les données existantes. Des procédures plus complexes peuvent être écrites pour implémenter des règles et une logique supplémentaires liées au traitement ou à la sélection des données.

La base de données relationnelle a été définie pour la première fois en juin 1970 par Edgar Codd , du laboratoire de recherche IBM de San Jose . La vision de Codd sur ce qui constitue un SGBDR est résumée dans les 12 règles de Codd . Une base de données relationnelle est devenue le type de base de données prédominant. Outre le modèle relationnel, d'autres modèles incluent le modèle de base de données hiérarchique et le modèle de réseau .

Le tableau ci-dessous résume certains des termes de bases de données relationnelles les plus importants et le terme SQL correspondant :

Dans une base de données relationnelle, une relation est un ensemble de tuples qui ont les mêmes attributs . Un tuple représente généralement un objet et des informations sur cet objet. Les objets sont généralement des objets physiques ou des concepts. Une relation est généralement décrite comme une table , organisée en lignes et en colonnes . Toutes les données référencées par un attribut sont dans le même domaine et sont conformes aux mêmes contraintes.

Le modèle relationnel spécifie que les tuples d'une relation n'ont pas d'ordre spécifique et que les tuples, à leur tour, n'imposent aucun ordre aux attributs. Les applications accèdent aux données en spécifiant des requêtes, qui utilisent des opérations telles que select pour identifier les tuples, project pour identifier les attributs et join pour combiner les relations. Les relations peuvent être modifiées à l'aide des opérateurs insert , delete et update . Les nouveaux tuples peuvent fournir des valeurs explicites ou être dérivés d'une requête. De même, les requêtes identifient les tuples à mettre à jour ou à supprimer.

Les tuples sont par définition uniques. Si le tuple contient un candidat ou une clé primaire, il est évidemment unique ; cependant, il n'est pas nécessaire de définir une clé primaire pour qu'une ligne ou un enregistrement soit un tuple. La définition d'un tuple exige qu'il soit unique, mais ne nécessite pas la définition d'une clé primaire. Comme un tuple est unique, ses attributs constituent par définition une superclé .

Toutes les données sont stockées et accessibles via des relations . Les relations qui stockent des données sont appelées « relations de base » et dans les implémentations, elles sont appelées « tables ». D'autres relations ne stockent pas de données, mais sont calculées en appliquant des opérations relationnelles à d'autres relations. Ces relations sont parfois appelées « relations dérivées ». Dans les implémentations, elles sont appelées « vues » ou « requêtes ». Les relations dérivées sont pratiques dans la mesure où elles agissent comme une relation unique, même si elles peuvent récupérer des informations à partir de plusieurs relations. De plus, les relations dérivées peuvent être utilisées comme couche d'abstraction .

Un domaine décrit l'ensemble des valeurs possibles pour un attribut donné et peut être considéré comme une contrainte sur la valeur de l'attribut. Mathématiquement, attacher un domaine à un attribut signifie que toute valeur de l'attribut doit être un élément de l'ensemble spécifié. La chaîne de caractères "ABC" , par exemple, n'est pas dans le domaine des entiers, mais la valeur entière 123 l'est. Un autre exemple de domaine décrit les valeurs possibles pour le champ "CoinFace" comme ("Pile", "Face"). Ainsi, le champ "CoinFace" n'acceptera pas de valeurs d'entrée telles que (0,1) ou (H,T).

Les contraintes sont souvent utilisées pour permettre de restreindre davantage le domaine d'un attribut. Par exemple, une contrainte peut restreindre un attribut entier donné à des valeurs comprises entre 1 et 10. Les contraintes fournissent une méthode d'implémentation de règles métier dans la base de données et prennent en charge l'utilisation ultérieure des données au sein de la couche application. SQL implémente la fonctionnalité de contrainte sous la forme de contraintes de vérification . Les contraintes restreignent les données qui peuvent être stockées dans des relations . Celles-ci sont généralement définies à l'aide d'expressions qui génèrent une valeur booléenne , indiquant si les données satisfont ou non à la contrainte. Les contraintes peuvent s'appliquer à des attributs uniques, à un tuple (restreignant les combinaisons d'attributs) ou à une relation entière. Étant donné que chaque attribut a un domaine associé, il existe des contraintes ( contraintes de domaine ). Les deux principales règles du modèle relationnel sont connues sous le nom d' intégrité d'entité et d'intégrité référentielle .

Chaque relation /table possède une clé primaire, conséquence du fait qu'une relation est un ensemble . Une clé primaire spécifie de manière unique un tuple dans une table. Bien que les attributs naturels (attributs utilisés pour décrire les données saisies) soient parfois de bonnes clés primaires, des clés de substitution sont souvent utilisées à la place. Une clé de substitution est un attribut artificiel attribué à un objet qui l'identifie de manière unique (par exemple, dans une table d'informations sur les étudiants d'une école, ils peuvent tous se voir attribuer un identifiant d'étudiant afin de les différencier). La clé de substitution n'a pas de signification intrinsèque (inhérente), mais est plutôt utile grâce à sa capacité à identifier de manière unique un tuple. Une autre occurrence courante, en particulier en ce qui concerne la cardinalité N:M, est la clé composite . Une clé composite est une clé composée de deux ou plusieurs attributs dans une table qui (ensemble) identifient de manière unique un enregistrement.

La clé étrangère fait référence à un champ dans une table relationnelle qui correspond à la colonne de clé primaire d'une autre table. Elle relie les deux clés. Les clés étrangères n'ont pas besoin d'avoir des valeurs uniques dans la relation de référencement. Une clé étrangère peut être utilisée pour croiser des tables et utilise efficacement les valeurs des attributs dans la relation référencée pour restreindre le domaine d'un ou plusieurs attributs dans la relation de référencement. Le concept est décrit formellement comme suit : « Pour tous les tuples dans la relation de référencement projetés sur les attributs de référencement, il doit exister un tuple dans la relation référencée projeté sur ces mêmes attributs de telle sorte que les valeurs de chacun des attributs de référencement correspondent aux valeurs correspondantes dans les attributs référencés. »

Une procédure stockée est un code exécutable associé à la base de données et généralement stocké dans celle-ci. Les procédures stockées collectent et personnalisent généralement des opérations courantes, comme l'insertion d'un tuple dans une relation , la collecte d'informations statistiques sur les modèles d'utilisation ou l'encapsulation d'une logique métier et de calculs complexes. Elles sont souvent utilisées comme interface de programmation d'application (API) pour des raisons de sécurité ou de simplicité. Les implémentations de procédures stockées sur les SGBDR SQL permettent souvent aux développeurs de tirer parti des extensions procédurales (souvent spécifiques au fournisseur) de la syntaxe déclarative SQL standard. Les procédures stockées ne font pas partie du modèle de base de données relationnelle, mais toutes les implémentations commerciales les incluent.

Un index est un moyen de fournir un accès plus rapide aux données. Les index peuvent être créés sur n'importe quelle combinaison d'attributs sur une relation . Les requêtes qui filtrent à l'aide de ces attributs peuvent trouver des tuples correspondants directement à l'aide de l'index (similaire à la recherche dans une table de hachage ), sans avoir à vérifier chaque tuple à tour de rôle. Cela revient à utiliser l' index d'un livre pour accéder directement à la page sur laquelle se trouve l'information que vous recherchez, de sorte que vous n'avez pas à lire l'intégralité du livre pour trouver ce que vous cherchez. Les bases de données relationnelles fournissent généralement plusieurs techniques d'indexation, chacune étant optimale pour une combinaison de distribution de données, de taille de relation et de modèle d'accès typique. Les index sont généralement implémentés via des arbres B+ , des arbres R et des bitmaps . Les index ne sont généralement pas considérés comme faisant partie de la base de données, car ils sont considérés comme un détail d'implémentation, bien que les index soient généralement maintenus par le même groupe qui maintient les autres parties de la base de données. L'utilisation d'index efficaces sur les clés primaires et étrangères peut améliorer considérablement les performances des requêtes. Cela est dû au fait que les index B-tree génèrent des temps de requête proportionnels à log(n) où n est le nombre de lignes dans une table et les index de hachage génèrent des requêtes à temps constant (aucune dépendance de taille tant que la partie pertinente de l'index tient dans la mémoire).

Les requêtes effectuées sur la base de données relationnelle et les relvars dérivées dans la base de données sont exprimées dans un calcul relationnel ou une algèbre relationnelle . Dans son algèbre relationnelle originale, Codd a introduit huit opérateurs relationnels en deux groupes de quatre opérateurs chacun. Les quatre premiers opérateurs étaient basés sur les opérations mathématiques traditionnelles sur les ensembles :

• L' opérateur d'union (υ) combine les tuples de deux relations et supprime tous les tuples en double du résultat. L'opérateur d'union relationnelle est équivalent à l' opérateur SQL UNION .
• L' opérateur d'intersection (∩) produit l'ensemble des tuples que deux relations partagent en commun. L'intersection est implémentée dans SQL sous la forme de l' opérateur INTERSECT .
• L' opérateur de différence d'ensemble (-) agit sur deux relations et produit l'ensemble des tuples de la première relation qui n'existent pas dans la seconde relation. La différence est implémentée en SQL sous la forme de l' opérateur EXCEPT ou MINUS.
• Le produit cartésien (X) de deux relations est une jointure qui n'est restreinte par aucun critère, ce qui fait que chaque tuple de la première relation correspond à chaque tuple de la seconde relation. Le produit cartésien est implémenté dans SQL en tant qu'opérateur de jointure croisée .

Les opérateurs restants proposés par Codd impliquent des opérations spéciales spécifiques aux bases de données relationnelles :

• L'opération de sélection, ou de restriction, (σ) récupère des tuples à partir d'une relation, en limitant les résultats à ceux qui répondent à un critère spécifique, c'est-à-dire à un sous-ensemble en termes de théorie des ensembles. L'équivalent SQL de la sélection est l' instruction de requête SELECT avec une clause WHERE .
• L' opération de projection (π) extrait uniquement les attributs spécifiés d'un tuple ou d'un ensemble de tuples.
• L'opération de jointure définie pour les bases de données relationnelles est souvent appelée jointure naturelle (⋈). Dans ce type de jointure, deux relations sont connectées par leurs attributs communs. L'approximation de MySQL d'une jointure naturelle est l' opérateur de jointure interne . En SQL, une jointure interne empêche la formation d'un produit cartésien lorsqu'il y a deux tables dans une requête. Pour chaque table ajoutée à une requête SQL, une jointure interne supplémentaire est ajoutée pour empêcher la formation d'un produit cartésien. Ainsi, pour N tables dans une requête SQL, il doit y avoir N−1 jointures internes pour empêcher la formation d'un produit cartésien.
• L' opération de division relationnelle (÷) est une opération légèrement plus complexe et consiste essentiellement à utiliser les tuples d'une relation (le dividende) pour partitionner une seconde relation (le diviseur). L'opérateur de division relationnelle est en fait l'opposé de l'opérateur de produit cartésien (d'où son nom).

D'autres opérateurs ont été introduits ou proposés depuis l'introduction des huit opérateurs originaux par Codd, notamment des opérateurs de comparaison relationnelle et des extensions qui offrent un support pour l'imbrication et les données hiérarchiques, entre autres.

La normalisation a été proposée pour la première fois par Codd comme partie intégrante du modèle relationnel. Elle englobe un ensemble de procédures conçues pour éliminer les domaines non simples (valeurs non atomiques) et la redondance (duplication) des données, ce qui évite à son tour les anomalies de manipulation des données et la perte d'intégrité des données. Les formes de normalisation les plus courantes appliquées aux bases de données sont appelées formes normales .

Connolly et Begg définissent un système de gestion de base de données (SGBD) comme un « système logiciel qui permet aux utilisateurs de définir, créer, maintenir et contrôler l'accès à la base de données ». Le SGBDR est une extension de ce sigle qui est parfois utilisé lorsque la base de données sous-jacente est relationnelle.

Une autre définition d'un système de gestion de base de données relationnelle est un système de gestion de base de données (SGBD) basé sur le modèle relationnel . La plupart des bases de données largement utilisées aujourd'hui sont basées sur ce modèle.

Les SGBDR sont une option courante pour le stockage d'informations dans des bases de données utilisées pour les dossiers financiers, les informations de fabrication et de logistique, les données du personnel et d'autres applications depuis les années 1980. Les bases de données relationnelles ont souvent remplacé les bases de données hiérarchiques et les bases de données réseau héritées , car les SGBDR étaient plus faciles à mettre en œuvre et à administrer. Néanmoins, les données stockées relationnelles ont été continuellement contestées sans succès par les systèmes de gestion de bases de données objet dans les années 1980 et 1990 (qui ont été introduits pour tenter de résoudre le soi-disant décalage d'impédance objet-relationnel entre les bases de données relationnelles et les programmes d'application orientés objet), ainsi que par les systèmes de gestion de bases de données XML dans les années 1990. Cependant, en raison de l'expansion des technologies, telles que la mise à l'échelle horizontale des clusters informatiques , les bases de données NoSQL sont récemment devenues populaires comme alternative aux bases de données SGBDR.

L'architecture de base de données relationnelle distribuée (DRDA) a été conçue par un groupe de travail d'IBM entre 1988 et 1994. DRDA permet aux bases de données relationnelles connectées au réseau de coopérer pour répondre aux requêtes SQL. Les messages, les protocoles et les composants structurels de DRDA sont définis par l' architecture de gestion de données distribuées .

Selon DB-Engines , en décembre 2024, les systèmes les plus populaires sur le site Web db-engines.com étaient :

1. Base de données Oracle
2. MySQL
3. Serveur Microsoft SQL
4. PostgreSQL
5. Flocon de neige
6. IBM DB2
7. SQLite
8. Microsoft Access
9. Briques de données
10. MariaDB

Selon la société de recherche Gartner , en 2011, les cinq principaux fournisseurs de bases de données relationnelles propriétaires en termes de chiffre d'affaires étaient Oracle (48,8 %), IBM (20,2 %), Microsoft (17,0 %), SAP , y compris Sybase (4,6 %), et Teradata (3,7 %).