Le modèle de bases de données relationnelles

Aujourd’hui encore, la gestion électronique des données est dominée par le modèle de la base de données relationnelle. Les systèmes de gestion de bases de données relationnelles (SGBDR) les plus couramment utilisés sont classés par ordre alphabétique :

• Db2 : Db2 est l’un des SGBD relationnelles propriétaire d’IBM disponible aux utilisateurs sous licence commerciale.
• Microsoft SQL Server : le système de gestion de base de données de Microsoft en langage SQL est disponible sous une licence par utilisateur payante.
•  MySQL : MySQL est le SGBDR open source le plus utilisé dans le monde. Depuis son acquisition par Oracle, MySQL est commercialisé sous une double licence. La communauté des développeurs d’origine poursuit le projet sous le nom de MariaDB.
• PostgreSQL : avec PostgreSQL, les utilisateurs peuvent accéder gratuitement à un système de gestion de base de données relationnel-objet (SGBDRO). Le développement ultérieur est effectué par une communauté open source.
• Oracle Database : le système de gestion de base de données relationnelle de la société du même nom Oracle est commercialisé sous licence propriétaire contre rémunération.
• SQLite : SQLite est une bibliothèque appartenant au domaine public contenant un système de gestion de bases de données relationnelles.

Les informations de tous les systèmes mentionnés ci-dessus sont organisées dans des tables relationnelles. Mais de quoi s’agit-il ? Nous vous présenterons les principes de base de la conception des bases de données relationnelles ainsi que des exemples de bases de données. Enfin, nous identifierons les différences de ce type de base données avec les autres modèles existants.

Le concept central du schéma relationnel de la base de données est la relation. C’est le mathématicien et théoricien britannique, Edgar F. Codd qui inventa les modèles relationnels. Selon lui, une relation représente un ensemble d’entités ayant les mêmes propriétés. Chaque relation est constituée d’une série d’enregistrements de données (appelés tuples) dont les valeurs sont affectées à certains attributs.

Les attributs qu’une relation contient et le type de données auquel correspondent les valeurs affectées aux attributs sont définis à l’aide d’un schéma de relations selon la syntaxe suivante :

R = (A₁ : Typ₁, A₂ : Typ₂ , … , A_n : Typ_n)

Le schéma de relation (R) comprend les attributs A1 à An. Un type de données (Type1, Type2, etc.) est affecté à chaque attribut. Ceci peut être illustré par un exemple concret.

Le schéma suivant définit les attributs de la relation « employé » :

L’exemple suivant montre à quoi peut ressembler une table de base de données pour la table des employés répertorié ci-dessus.

La table d’exemple est utilisée pour enregistrer les données du personnel et se compose de quatre enregistrements de données. Chaque enregistrement de données contient des informations sur un seul salarié.

La base de données d’un système de bases de données relationnelles constitue la base de données tabulaire. Leur structure de données est définie par le système de gestion de la base de données, qui est également responsable de la gestion des accès en lecture et en écriture. Les utilisateurs interagissent avec le système de gestion de base de données en utilisant un langage de base de données. Chaque système de gestion de bases de données relationnelles supporte au moins un langage formel qui peut être utilisé pour effectuer les opérations de base de données suivantes :

• Définir la structure de données : lors de la définition des données, une description de la structure des données est stockée dans le dictionnaire de données du système de base de données à l’aide de métadonnées. Par exemple, si un utilisateur crée une nouvelle table, un schéma de relation correspondant est enregistré dans le dictionnaire de données. Le vocabulaire d’un langage de base de données utilisé pour définir les données est appelé langage de définition des données (DDL).
• Définir les autorisations : chaque langage de base de données fournit une syntaxe qui permet d’attribuer ou de révoquer des autorisations. C’est ce qu’on appelle le langage de contrôle de données (LCD), un vocabulaire partiel du langage de la base de données.
• Définir les conditions d’intégrité : les conditions d’intégrité sont des conditions requises pour l’état d’une base de données. Lorsque des conditions d’intégrité sont définies, la base de données s’assure qu’elles sont respectées en tout temps. On parle d’une condition constante. Une condition de base de l’intégrité dans les systèmes de bases de données relationnelles, par exemple, est que chaque ensemble de données (tuple) puisse être identifié de façon unique.
• Définir les transactions : si une base de données est transférée d’un état cohérent à un autre, il s’agit d’une transaction. Les transactions contiennent un certain nombre d’états financiers et doivent toujours être complétées. Si une transaction est interrompue, la base de données est réinitialisée à son état initial (rollback). Chaque transaction commence par l’instruction de connexion à la base de données. Celles-ci sont suivies de commandes qui déclenchent l’opération des données et d’une étape de test (commit) qui assure l’intégrité de la base de données. Les opérations qui mettent en danger l’intégrité ne sont pas commises (écrites de façon permanente dans la base de données). Enfin, la connexion à la base de données est fermée. Le vocabulaire sous-jacent du langage de base de données est appelé langage de manipulation de données (LMD).
• Définir les vues : une vue est une vue virtuelle des données sélectionnées. Dans le cas d’une vue, le système de gestion de base de données crée une table virtuelle (relation logique) basée sur des tables physiques. Les utilisateurs peuvent appliquer les mêmes opérations de base de données à ces vues qu’aux tables physiques. Il existe différents types de vues en fonction de la fonction de la vue de données. Les vues qui filtrent certaines lignes (vue de sélection) ou colonnes (vue de projection) d’une table sélectionnée et les vues qui relient différentes tables entre elles (vue composée) sont communes.

L'interface standard pour les opérations de base de données énumérées ci-dessus dans le modèle de bases de données relationnelles est SQL (Structured Query Language), un langage de base de données basé sur l'algèbre relationnelle.

Les opérations de base de données telles que l’interrogation, la création, la mise à jour ou la suppression de données sont effectuées à l’aide d’instructions SQL : une combinaison de commandes SQL sélectionnées. Celles-ci sont sémantiquement basées sur la langue anglaise et sont donc largement explicites. La table suivante contient les termes clés du modèle de données relationnelles et leurs équivalents dans la terminologie SQL.

Une simple requête de données sélectionnées peut être implémentée avec SQL selon le schéma suivant, par exemple :

Tout d’abord, nous utilisons la commande SELECT pour demander au SGBDR de récupérer les données. Nous définissons ensuite les données que nous voulons interroger en spécifiant la table et la colonne souhaitée. De plus, avec WHERE, nous intégrons une condition dans l’instruction SQL. Nous ne voulons pas récupérer toutes les valeurs d’attribut stockées dans la colonne, seulement la valeur d’un enregistrement particulier.

En relation avec notre exemple de table « employés », une telle instruction SQL pourrait ressembler à ceci :

L’instruction SQL demande au SGBD relationnelle de récupérer une valeur de la colonne numéro de sécurité sociale de la table employé. Comme condition, nous avons défini que la valeur doit être tirée de l’ensemble de données pour lequel la valeur d’attribut de la colonne e_id correspond à la valeur 3.

En conséquence, la base de données nous fournit le numéro de sécurité sociale d’Hélène Petit, l’employée avec l’ID 3 : 25 091225 M 463.

Lorsqu’ils travaillent avec des bases de données relationnelles, les utilisateurs ont rarement à traiter avec des tables individuelles. En règle générale, on utilise des structures dans lesquelles les données sont triées en fonction de leur signification et stockées dans des tables séparées. Ce concept est associé à la nécessité de relier les tables de données, par exemple lorsque l’on interroge des données stockées dans différentes tables.

En principe, toutes les informations d’une base de données relationnelle peuvent également être stockées dans une table globale complète. Cela aurait l’avantage d’éviter la nécessité de lier les tables de la base de données, ainsi que la syntaxe complexe associée aux requêtes sur plusieurs tables. C’est cependant ce qui fait la force de la base de données et son modèle relationnel. La division de l’information en plusieurs tables sert à réduire les entrées doubles (appelées anomalies) et s’appelle la normalisation. Le degré de normalisation peut être déterminé sur la base de formes normales prédéfinies. Les formes normales courantes pour les tables de bases de données relationnelles sont :

1. La première forme normale (1NF)
2. La seconde forme normale (2NF)
3. La troisième forme normale (3NF)
4. La forme normale de Boyce Codd (BCNF)
5. La quatrième forme normale (4NF)
6. La cinquième forme normale (5NF)

Les conditions préalables s’appliquant aux formulaires normaux énumérés et la façon de transférer une base de données d’un formulaire normal à un autre est l’objet de notre Article de base sur la normalisation.

Les relations entre les tables de base de données séparées sont appelées Relationships dans le schéma relationnel des bases de données et sont créées à l’aide de clés. Les touches relient les tables et sont la base pour interroger ou modifier les données de différentes tables avec une seule et même instruction.

Les tables de base de données telles que la table d'exemple « employés » permettent différentes approches pour interroger des valeurs individuelles ou des enregistrements de données complets. L'accent est mis sur lesdites clés. Dans le modèle des bases de données relationnelles, une clé est un ensemble d'attributs qui peuvent être utilisés pour identifier de façon unique un ensemble de données.

Par rapport à l’exemple de table ci-dessus, la clé suivante permet l’identification unique d’un tuple :

serait donc appropriée pour identifier l’enregistrement des données de l’employée Hélène Petit sans contradiction. Ce type de clé est connu sous le nom de super-clé. Toutefois, les super-clés n’ont que peu d’importance dans la pratique. L’une des raisons en est que les super-clés contiennent souvent plus d’attributs qu’il n’est nécessaire pour l’identification. En d’autres termes, les super-clés ne sont pas minimales.

Dans les bases de données relationnelles, on travaille donc avec le plus petit sous-ensemble possible d’une super-clef imaginable, ce qu’on appelle les clés candidates. Une table peut très bien contenir plusieurs clés candidates avec lesquelles les enregistrements de données peuvent être identifiés de façon unique.

L’exemple de requête de la section précédente a déjà montré que les enregistrements de données de la table « employés » peuvent être identifiés sans contradiction par le simple numéro d’identification de l’employé. Le numéro de sécurité sociale est une autre clé candidate dans la table de l’exemple. Une clé {nom, prénom} ne serait pas une bonne clé candidate, puisque cette combinaison d’attributs ne peut pas être attribuée de façon unique à un employé : plusieurs employées sous le nom d’Hélène Petit peuvent être salariées dans une même entreprise. L’identification au moyen d’une telle clé ne serait donc pas sans ambiguïté. Toutefois, deux employés ne peuvent pas partager le même numéro d’identification d’employé ou numéro de sécurité sociale.

Les clés candidates suivantes peuvent donc être déterminées de cette manière dans l’exemple de table ci-dessus :

Les tables de base de données relationnelles sont généralement structurées de telle sorte que l’une des clés candidates possibles spécifie la séquence des enregistrements de données. Cette clé candidate s’appelle la clé primaire. En pratique, les clés primaires sont généralement des ID consécutifs. Avec le e_id, notre table d’exemple a aussi un tel ID.

Parce que les clés identifient de façon unique les enregistrements dans les tables de bases de données relationnelles, elles sont idéales pour corréler différentes tables dans une base de données. Pour ce faire, vous incluez la clé primaire d’une table comme clé étrangère dans l’autre table.

La table suivante contient des données qu’une entreprise peut avoir enregistrées sur son propre parc de véhicules. La clé primaire de la table « véhicules » est un v_id consécutif.

Table : véhicules

Pour savoir quels employés utilisent quelle voiture de la société, vous devez lier la table « voitures » à la table « employés » par exemple, en intégrant la clé primaire de la table véhicule (v_id) comme clé étrangère dans la table des employés.

Table : employés

La table des employés montre maintenant que le salarié Jacques Dupond utilise une voiture de fonction avec le v_id 3. L’employée Lisa Lefevre conduit un véhicule avec le v_id 2, Jean Martin et Hélène Petit se partagent le véhicule avec le v_id 1.

Si vous voulez déterminer quel employé aura quelle voiture de fonction la prochaine fois, vous devrez interroger à la fois la table « employés » et la table « véhicules ». Comme les deux tables sont liées par des clés étrangères, cela ne peut se faire qu’avec une seule requête. Les opérations de base de données qui impliquent plusieurs tables sont implémentées dans le modèle de base de données relationnelle en utilisant un JOIN.

Un JOIN (jointure en français) est une opération de base de données qui permet à plusieurs tables de base de données d’être interrogées simultanément. Les données des tables sélectionnées sont combinées dans un jeu de résultats et filtrées en fonction des conditions définies par l’utilisateur.

Les bases mathématiques de SQL JOINs sont deux opérations d’algèbre relationnelle : produit cartésien et sélection. Les utilisateurs déterminent quelles données des tables interrogées sont incluses dans le jeu de résultats en sélectionnant le mot clé JOIN et en utilisant une condition de sélection.

Les types de JOIN les plus importants sont les suivants :

• INNER JOIN
• OUTER JOIN
• SELF JOIN

Indépendamment de cela, il convient de distinguer les EQUI JOINs (équijointures) et les NON EQUI JOINs (théta jointures).

Les bases de données relationnelles basées sur SQL doivent être différenciées des concepts qui rompent avec la structure rigide des tables et utilisent des approches alternatives pour la structuration des données. Parmi les concepts les plus importants de ce type, on retrouve les bases de données orientées objet et les systèmes orientés documents.

A la fin des années 1980, un nouveau modèle de base de données, la base de données orientée objet, est apparu sur le marché. Il reprend les concepts de programmation orientée objet et permet le stockage des données sous forme d’objets. Cependant, cette approche n’a guère pu s’affirmer jusqu’à ce jour. Au lieu de cela, les concepts orientés objet ont été incorporés dans le développement de systèmes de bases de données relationnelles. Il en résulte des produits avec des extensions relationnel-objet qui permettent le stockage de types de données abstraites dans le modèle de bases de données relationnelles.

A l’ère du Web 2.0, et avec le changement d’utilisation d’Internet, le modèle relationnel des bases de données a été fortement remis en question au tournant du millénaire. Dans le cadre du mouvement NoSQL (abréviation de Not Only SQL), des modèles alternatifs tels que des bases de données orientées documents ont été développés. L’objectif de ce mouvement était de développer de puissants concepts de bases de données pour les applications gourmandes en données.

Les bases de données orientées objet et les bases de données orientées documents se distinguent du schéma relationnel des bases de données surtout par la manière dont les données sont stockées ainsi que par leur accessibilité.

Le modèle de base de données orientée objet permet le stockage des données sous forme d’objets. La modulation des objets est analogue à la programmation orientée objet. Un objet définit une entité et contient :

• • Les propriétés (attributs) requises pour décrire l’entité,
  • les références (relations) à d’autres objets,
  • les fonctions qui permettent d’accéder aux données stockées (méthodes).

Un objet est donc un groupe de données dans lequel l’interface est également définie pour accéder à ces données. Les objets appartiennent aux types de données abstraites.

Le système de gestion de bases de données orienté objet (SGBDO) attribue automatiquement un ID à chaque objet. Ceci permet d’identifier l’objet de manière unique d’y accéder à l’aide de méthodes. Cet ID d’objet est sans état, c’est-à-dire découplé des valeurs de l’objet. Il est ainsi possible de donner deux ID différents à deux objets avec les mêmes données (c’est-à-dire avec le même état). Ceci distingue clairement le modèle de base de données orienté objet du modèle relationnel, dans lequel chaque tuple peut être identifié par ses données (par exemple par une clé primaire).

Une autre caractéristique du modèle de base de données orientée objet est l’encapsulation de données. Les données enregistrées ne sont accessibles que par les méthodes définies précédemment. Les données encapsulées dans l’objet sont ainsi protégées contre les modifications via des interfaces indéfinies.

Les structures des bases de données sont définies dans le modèle de base de données orientée objet à l’aide d’un système de classification hiérarchique. Dans la programmation orientée objet, une classe est un ensemble d’objets ayant les mêmes caractéristiques. Chaque classe d’objets repose sur une définition de classe. Ce schéma spécifie les attributs et les méthodes de tous les objets de la classe et détermine ainsi la façon dont ils sont créés et modifiés.

Les utilisateurs interagissent avec la base de données orientée objet à l’aide d’un langage de requêtes de type SQL pour les bases de données orientée objets : l’Object Query Language (OQL). Le résultat d’une requête OQL n’est pas, comme pour SQL, un jeu de résultats, mais une liste d’objets qui correspondent aux conditions de l’instruction OQL.

Les implémentations connues du modèle de base de données orientée objet sont Realm, ZODB et Perst.

Les bases de données orientées objet ont été développées pour résoudre un problème de développement d’applications connu sous le nom d’Object-relational impedance mismatch.

Si des objets d’un langage de programmation orienté objet (par exemple C#, C++ ou Java) doivent être stockés dans une base de données relationnelle, des incompatibilités se produisent inévitablement. Elles sont dues à des différences fondamentales entre les deux paradigmes de programmation.

• • Les bases de données relationnelles ne supportent pas les concepts orientés objet tels que les classes et l’héritage.
  • L’identification de l’objet sans état ne peut pas être réalisée dans le modèle de base de données relationnelle.
  • Le mécanisme de protection de l’encapsulation des données n’est pas disponible dans le modèle de bases de données relationnelles.

Une approche pour éviter les problèmes d’incompatibilité mentionnés ci-dessus consiste à renoncer aux bases de données relationnelles et à utiliser une base de données objet dans le cadre d’une programmation applicative orientée objet. Cependant, cela présente inévitablement l’inconvénient que les données encapsulées dans des objets ne sont pas disponibles indépendamment de l’application associée. En outre, les bases de bases de donnée objet ne sont pas très répandues. La plupart des outils et interfaces d’analyse de données sont encore conçus pour les bases de données relationnelles et ne prennent pas en charge le modèle de données orientées objet.

Cependant, les développeurs d’applications qui ne souhaitent pas se passer des avantages du stockage de données relationnelles peuvent compenser les incompatibilités en utilisant des mappeurs objet/relationnel. Les fonctionnalités de mapping objet-relationnel (ORM) sont implémentées via des bibliothèques. Elles créent une couche d’abstraction entre l’application orientée objet et les données stockées dans les tables.

De nombreux fabricants de systèmes de bases de données relationnelles équipent également leurs produits de fonctions qui compensent les incompatibilités avec la programmation orientée objet. Les systèmes de base de données de ce type sont appelés « objet-relationnel ».

Les bases de données orientées objet transfèrent les principes de base de l’orientation objet aux technologies de base de données et sont donc particulièrement adaptées à la programmation applicative orientée objet. Toutefois, les systèmes de bases de données correspondants sont rares et certains d’entre eux ne sont pas encore prêts pour le marché.

Un système de base de données relationnel-objet est un système de bases de données relationnelles qui a été étendu par des concepts d’orientation objet. Les principes éprouvés du modèle de bases de données relationnelles doivent donc être étendus aux types de données abstraites tels que les objets.

Afin de permettre la gestion des types de données abstraites, les bases de données relationnel-objet étendent le modèle de base de données relationnelles en :

• • Types de données complexes et définies par l’utilisateur,
  • constructeurs,
  • fonctions et méthodes.

Alors que les bases de données relationnelles sont essentiellement limitées aux types de données alphanumériques, les types de données définis par l’utilisateur peuvent également être utilisés pour gérer des fichiers multimédias complexes. Les constructeurs vous permettent de dériver de nouveaux types de données à partir des types de base existants. Comme le langage de base de données SQL ne permet pas de créer des fonctions, les systèmes de base de données relationnel-objet doivent fournir des extensions pour définir les fonctions d’accès et de traitement pour les types de données complexes.

Depuis le début des années 2000, des extensions relationnel-objet telles que les types structurés ont été incluses dans les nouvelles versions de la norme SQL. Toutefois, tous les SGBD ne les prennent pas en charge. Les systèmes de base de données bien connus qui fournissent les extensions correspondantes sont IBM Db2, Oracle Database et Microsoft SQL Server.

Alors que le stockage des données dans des bases de données relationnelles s’effectue dans des tables de base de données, le modèle de bases de données orientées document est basé sur une base de données hétérogène de documents individuels. Il peut s’agir de documents structurés tels que des fichiers JSON, YAML ou XML ainsi que des fichiers non structurés tels que des Binary Large Object (BLOBs) qui sont des fichiers image, vidéo ou audio.

Si des documents structurés sont disponibles, les données sont enregistrées sous forme de combinaisons clé/valeur. Une valeur concrète est attribuée à chaque clé. Dans ce contexte, le terme clé est utilisé comme synonyme du terme attribut et n’a rien à voir avec les clés du système de base de données relationnelles. Les valeurs peuvent être n’importe quelle information. Les listes et les tables avec des données imbriquées sont également des valeurs possibles.

Par exemple, un document au format JSON (Notation des objets JavaScript) qui est utilisé pour stocker les données des employés peut ressembler à ceci :

Plusieurs documents peuvent être regroupés pour former des collections de documents. Le document de l’employé affiché peut, par exemple, être « employé » avec d’autres parties de la collection.

Les requêtes sont réalisées à l’aide de fonctions, par exemple via JavaScript. Même les systèmes de gestion de base de données qui fonctionnent orientés document attribuent un identifiant unique à chaque document. Cependant, contrairement au modèle de bases de données relationnelles, il n’existe pas de schéma de base de données qui couvre l’ensemble de la base de données. Les documents d’une base de données basée sur des documents n’ont pas besoin d’être conformes à une forme normale, et il n’existe pas non plus de caractéristiques structurelles prédéfinies qui doivent s’appliquer à tous les documents. En principe, chaque document peut avoir une structure différente. Toutefois, dans le contexte du développement d’applications, il est conseillé de créer des documents dans un schéma correspondant à l’application afin de créer la condition préalable aux requêtes ciblées.

Les relations telles que la liaison de tables de base de données dans le modèle de base de données relationnelle ne peuvent pas être implémentées avec des bases de données orientées document. Bien qu’il soit possible de saisir manuellement l’ID d’un document comme référence dans un autre document, les systèmes de gestion de base de données orientée document n’offrent pas de JOINs. Vous devrez donc programmer vous-même les options de requête correspondantes.

Les systèmes de bases de données orientées documents sont particulièrement adaptés au traitement de grandes quantités de données à structure hétérogène et à faible mise en réseau. Ce modèle de stockage de données est donc particulièrement utile pour les données de grandes taille.

Les systèmes de bases de données relationnelles garantissent que les conditions spécifiées dans les définitions des tables sont remplies à tout moment. Ceci conduit à des vitesses d’écriture relativement lentes lors du traitement de grandes quantités de données. Les systèmes de bases de données NoSQL n’ont pas d’exigences aussi strictes en matière de cohérence des données et sont donc adaptés aux grandes architectures dans lesquelles de nombreuses instances de bases de données sont exploitées en parallèle.

Les applications Web utilisent également de plus en plus de bases de données orientées documents. Si, toutefois, un réseautage solide est nécessaire, le stockage de données documentaires est associé à un effort accru. Dans ce cas, les utilisateurs devraient mieux utiliser les systèmes de bases de données relationnelles.

BaseX, CouchDB, eXist, MongoDB et RavenDB sont des exemples de bases de données orientées documents.

Les bases de données relationnelles ne se sont pas imposées sans raison comme une norme de facto dans le traitement électronique des données. Les points suivants s’appliquent au modèle de bases de données relationnelles.

• • Modèle de données simple : les bases de données relationnelles sont basées sur un modèle de données relativement facile à mettre en œuvre et à gérer. De nombreuses informations, telles que les données clients, les listes de commandes ou les mouvements de compte que les entreprises souhaitent stocker pendant une longue période peuvent idéalement être mappées avec la structure de table sur laquelle le modèle de bases de données relationnelles est basé.
  • Faible redondance des données : le modèle relationnel des bases de données fournit des règles précisément définies pour éviter la redondance avec les différentes formes normales. Si les spécifications de normalisation sont appliquées de manière cohérente, les systèmes de bases de données relationnelles permettent un stockage des données pratiquement sans redondance. Cela facilite la gestion et l’entretien des stocks de données, puisque les modifications ne doivent être effectuées qu’à un seul endroit.
  • Cohérence élevée des données : les bases de données relationnelles normalisées permettent un stockage cohérent des données et contribuent ainsi à la cohérence des données. Les systèmes de bases de données relationnelles offrent également des fonctions permettant de définir et de vérifier automatiquement les conditions d’intégrité. Les transactions qui mettent en danger la cohérence des données sont exclues.
  • Traitement des données quantitatives : le système de bases de données relationnelles est basé sur un traitement des données quantitatives dans lequel chaque entité est décomposée en valeurs atomiques. Cela permet de lier différentes entités via le contenu ainsi que des requêtes de base de données complexes telles que les JOINs.
  • Langage de requête uniforme : pour les requêtes de bases de données relationnelles, le langage de base de données SQL standardisé par un comité de ISO et IEC a été établi. Le but de cette standardisation est que les applications puissent être développées et exécutées en grande partie indépendamment du système de gestion de base de données sous-jacent. Cependant, le support SQL varie encore considérablement d’un SGBD à l’autre.

Selon le scénario dans lequel les systèmes de bases de données relationnelles sont utilisés, des avantages tels que le modèle de données simple basé sur des tables et la division des données en plusieurs tables liées peuvent également être interprétés comme des inconvénients. En outre, les caractéristiques centrales du modèle des bases de données relationnelles sont difficiles à concilier avec les exigences modernes de programmation des applications (telles que l’orientation objet, le multimédia et les données de grande taille).

• Affichage tabulaire des données : tous les types de données ne peuvent pas être compressés dans un schéma rigide de tables bidimensionnelles liées (inadéquation d’impédance). Les types de données abstraites et les données non structurées qui se produisent dans le cadre d’applications multimédia et de grandes solutions de données ne fonctionnent pas avec le modèle des bases de données relationnelles.

• Pas de schéma de base de données hiérarchique : contrairement aux bases de données orientées objet, les bases de données relationnelles n’offrent pas la possibilité d’implémenter des schémas de base de données avec des classes hiérarchiquement structurées. Des concepts tels que les entités subordonnées qui héritent de propriétés d’entités supérieures ne peuvent pas être implémentés avec elles. Par exemple, vous ne pouvez pas créer de sous-tuples avec eux. Tous les tuples d’une base de données relationnelle se trouvent au même niveau hiérarchique.
• Segmentation des données : le principe de base des systèmes de bases de données relationnelles, qui consiste à diviser l’information en tables séparées (normalisation), conduit inévitablement à une segmentation des données. Tout ce qui est connexes n’est pas nécessairement stocké ensemble. Cette conception de base de données entraîne des requêtes complexes sur plusieurs tables au niveau de l’application. Le nombre plus élevé de segments interrogés qui en résulte a généralement un impact négatif sur la performance.
• Performances inférieures à celles des bases de données NoSQL : le modèle de bases de données relationnelles impose des exigences élevées en matière de cohérence des données, ce qui est préjudiciable à la vitesse d’écriture des transactions.

Le schéma relationnel des bases de données est clair, mathématiquement solide et a fait ses preuves dans la pratique depuis plus de 40 ans. Pourtant, le stockage des données dans des tables structurées ne répond pas à toutes les exigences des technologies modernes de l’information.

L’administration de grandes quantités de données dans le cadre de grandes analyses de données et le stockage de types de données abstraits poussent surtout les systèmes relationnels classiques à leurs limites. C’est là que les systèmes spécialisés tels que les bases de données orientées objet ou les concepts développés dans le cadre du mouvement NoSQL marquent des points. Cependant, le modèle de bases de données relationnelles ne peut pas être complètement amorti. Les bases de données relationnelles offrent de nombreux avantages, en particulier dans les domaines d’activité où le traitement des données de transaction est au premier plan.

Les données relatives aux campagnes clients ou aux mesures de marketing peuvent idéalement être stockées dans des systèmes tabulaires. Les utilisateurs bénéficient également d’une syntaxe qui permet des requêtes complexes malgré sa simplicité.