MODÈLE DE BASE DE DONNÉES RELATIONNELLE: ÉLÉMENTS, COMMENT LE FAIRE, EXEMPLE - LA TECHNOLOGIE - 2025

Le modèle de base de données relationnelle est une méthode de structuration des données à l'aide de relations, en utilisant des structures de type grille, constituées de colonnes et de lignes. C'est le principe conceptuel des bases de données relationnelles. Il a été proposé par Edgar F. Codd en 1969.

Il est depuis devenu le modèle de base de données dominant pour les applications d'entreprise, par rapport à d'autres modèles de base de données, tels que hiérarchique, réseau et objet.

Source: pixabay.com

Codd n'avait aucune idée à quel point son travail en tant que plate-forme pour les bases de données relationnelles serait extrêmement vital et influent. La plupart des gens connaissent très bien l'expression physique d'une relation dans une base de données: la table.

Le modèle relationnel est défini comme la base de données qui permet de regrouper ses éléments de données dans une ou plusieurs tables indépendantes, qui peuvent être liées les unes aux autres grâce à l'utilisation de champs communs à chaque table associée.

Gestion de base de données

Une table de base de données est similaire à une feuille de calcul. Cependant, les relations qui peuvent être créées entre les tables permettent à une base de données relationnelle de stocker efficacement une grande quantité de données, qui peuvent être récupérées efficacement.

Le but du modèle relationnel est de fournir une méthode déclarative pour spécifier les données et les requêtes: les utilisateurs déclarent directement quelles informations la base de données contient et quelles informations ils en veulent.

D'autre part, ils laissent au logiciel du système de gestion de base de données le soin de décrire les structures de données pour le stockage et la procédure de récupération pour répondre aux requêtes.

La plupart des bases de données relationnelles utilisent le langage SQL pour interroger et définir les données. Il existe actuellement de nombreux systèmes de gestion de bases de données relationnelles ou RDBMS (Relational Data Base Management System), comme Oracle, IBM DB2 et Microsoft SQL Server.

Caractéristiques et éléments

- Toutes les données sont représentées conceptuellement comme un arrangement ordonné de données en lignes et en colonnes, appelé relation ou tableau.

- Chaque tableau doit avoir un en-tête et un corps. L'en-tête est simplement la liste des colonnes. Le corps est l'ensemble de données qui remplit le tableau, organisé en lignes.

- Toutes les valeurs sont des scalaires. Autrement dit, à n'importe quelle position de ligne / colonne donnée dans le tableau, il n'y a qu'une seule valeur.

-Éléments

La figure suivante montre un tableau avec les noms de ses éléments de base, qui constituent une structure complète.

Tuple

Chaque ligne de données est un tuple, également appelé enregistrement. Chaque ligne est un n-uplet, mais le "n-" est généralement ignoré.

Colonne

Chaque colonne d'un tuple est appelée un attribut ou un champ. La colonne représente l'ensemble de valeurs qu'un attribut spécifique peut avoir.

mot de passe

Chaque ligne a une ou plusieurs colonnes appelées une clé de table. Cette valeur combinée est unique pour toutes les lignes d'une table. Au moyen de cette clé, chaque tuple sera identifié de manière unique. Autrement dit, la clé ne peut pas être dupliquée. C'est ce qu'on appelle la clé primaire.

D'autre part, une clé étrangère ou secondaire est le champ d'une table qui fait référence à la clé primaire d'une autre table. Il est utilisé pour référencer la table primaire.

-Règles d'intégrité

Lors de la conception du modèle relationnel, vous définissez certaines conditions qui doivent être remplies dans la base de données, appelées règles d'intégrité.

Intégrité des clés

La clé primaire doit être unique pour tous les tuples et ne peut pas être nulle (NULL). Sinon, vous ne pourrez pas identifier la ligne de manière unique.

Pour une clé à plusieurs colonnes, aucune de ces colonnes ne peut contenir NULL.

Intégrité référentielle

Chaque valeur d'une clé étrangère doit correspondre à une valeur de la clé primaire de la table référencée ou primaire.

Une ligne avec une clé étrangère ne peut être insérée dans la table secondaire que si cette valeur existe dans une table primaire.

Si la valeur de la clé change dans la table primaire, en raison de la mise à jour ou de la suppression de la ligne, toutes les lignes des tables secondaires avec cette clé étrangère doivent être mises à jour ou supprimées en conséquence.

Comment faire un modèle relationnel?

-Collecter des données

Les données nécessaires doivent être collectées pour être stockées dans la base de données. Ces données sont divisées en différents tableaux.

Un type de données approprié doit être choisi pour chaque colonne. Par exemple: nombres entiers, nombres à virgule flottante, texte, date, etc.

-Définir les clés primaires

Pour chaque table, une colonne (ou quelques colonnes) doit être choisie comme clé primaire, qui identifiera de manière unique chaque ligne de la table. La clé primaire est également utilisée pour faire référence à d'autres tables.

-Créer des relations entre les tables

Une base de données composée de tables indépendantes et non liées n'a pas d'utilité.

L'aspect le plus crucial dans la conception d'une base de données relationnelle est l'identification des relations entre les tables. Les types de relations sont:

Un à plusieurs

Dans une base de données «Class Listing», un enseignant peut enseigner zéro ou plusieurs classes, tandis qu'une classe est enseignée par un seul enseignant. Ce type de relation est appelé un-à-plusieurs.

Cette relation ne peut pas être représentée dans une seule table. Dans la base de données «Liste des classes», vous pouvez avoir une table appelée Enseignants, qui stocke des informations sur les enseignants.

Pour stocker les classes enseignées par chaque enseignant, vous pourriez créer des colonnes supplémentaires, mais vous seriez confronté à un problème: combien de colonnes créer.

D'un autre côté, si vous avez une table appelée Classes, qui stocke des informations sur une classe, vous pouvez créer des colonnes supplémentaires pour stocker des informations sur l'enseignant.

Cependant, comme un enseignant peut enseigner de nombreuses classes, ses données seraient dupliquées sur plusieurs lignes de la table Classes.

Concevez deux tables

Par conséquent, vous devez concevoir deux tables: une table Classes pour stocker des informations sur les classes, avec Class_Id comme clé primaire et une table Teachers pour stocker des informations sur les enseignants, avec Teacher_Id comme clé primaire.

La relation un-à-plusieurs peut ensuite être créée en stockant la clé primaire de la table Master (Master_Id) dans la table Classes, comme illustré ci-dessous.

La colonne Master_Id de la table Classes est appelée clé étrangère ou clé secondaire.

Pour chaque valeur Master_Id dans la table Master, il peut y avoir zéro ou plusieurs lignes dans la table Classes. Pour chaque valeur Class_Id de la table Classes, il n'y a qu'une seule ligne dans la table Teachers.

Plusieurs à plusieurs

Dans une base de données "Vente de produits", une commande client peut contenir plusieurs produits et un produit peut apparaître dans plusieurs commandes. Ce type de relation est connu comme plusieurs à plusieurs.

Vous pouvez démarrer la base de données "Ventes de produits" avec deux tables: Produits et Commandes. La table Products contient des informations sur les produits, avec productID comme clé primaire.

D'autre part, la table Orders contient les commandes du client, avec orderID comme clé primaire.

Vous ne pouvez pas stocker les produits commandés dans la table Commandes, car vous ne savez pas combien de colonnes réserver pour les produits. Les commandes ne peuvent pas non plus être stockées dans le tableau Produits pour la même raison.

Pour prendre en charge une relation plusieurs à plusieurs, vous devez créer une troisième table, appelée table de jointure (OrderDetails), où chaque ligne représente un élément dans un ordre particulier.

Pour la table OrderDetails, la clé primaire se compose de deux colonnes: orderID et productID, identifiant de manière unique chaque ligne.

Les colonnes orderID et productID de la table OrderDetails sont utilisées pour référencer les tables Orders et Products. Par conséquent, ce sont également des clés étrangères dans la table OrderDetails.

Un à un

Dans la base de données "Vente de produits", un produit peut avoir des informations facultatives, telles qu'une description supplémentaire et son image. Le garder à l'intérieur de la table Products générerait beaucoup d'espaces vides.

Par conséquent, une autre table (ProductExtras) peut être créée pour stocker les données facultatives. Un seul enregistrement sera créé pour les produits avec des données facultatives.

Les deux tables, Products et ProductExtras, ont une relation un-à-un. Pour chaque ligne de la table Products, il existe au maximum une ligne dans la table ProductExtras. Le même productID doit être utilisé comme clé primaire pour les deux tables.

avantage

Indépendance structurelle

Dans le modèle de base de données relationnelle, les modifications apportées à la structure de la base de données n'affectent pas l'accès aux données.

Lorsqu'il est possible de modifier la structure de la base de données sans affecter la capacité du SGBD à accéder aux données, on peut dire que l'indépendance structurelle a été atteinte.

Simplicité conceptuelle

Le modèle de base de données relationnelle est encore plus simple sur le plan conceptuel que le modèle de base de données hiérarchique ou réseau.

Étant donné que le modèle de base de données relationnelle libère le concepteur des détails du stockage physique des données, les concepteurs peuvent se concentrer sur la vue logique de la base de données.

Facilité de conception, de mise en œuvre, de maintenance et d'utilisation

Le modèle de base de données relationnelle permet à la fois l'indépendance des données et l'indépendance de la structure, ce qui rend la conception, la maintenance, la gestion et l'utilisation de la base de données beaucoup plus faciles que les autres modèles.

Capacité de requête ad hoc

La présence d'une capacité de requête très puissante, flexible et facile à utiliser est l'une des principales raisons de l'immense popularité du modèle de base de données relationnelle.

Le langage de requête du modèle de base de données relationnelle, appelé langage de requête structuré, ou SQL, fait des requêtes ad hoc une réalité. SQL est un langage de quatrième génération (4GL).

Une 4GL permet à l'utilisateur de spécifier ce qui doit être fait, sans spécifier comment cela doit être fait. Ainsi, avec SQL, les utilisateurs peuvent spécifier les informations qu'ils souhaitent et laisser les détails sur la manière d'obtenir les informations dans la base de données.

Désavantages

Frais de matériel

Le modèle de base de données relationnelle cache les complexités de sa mise en œuvre et les détails du stockage physique des données utilisateur.

Pour ce faire, les systèmes de bases de données relationnelles ont besoin d'ordinateurs dotés de matériel et de périphériques de stockage de données plus puissants.

Par conséquent, le SGBDR a besoin de machines puissantes pour fonctionner correctement. Cependant, comme la puissance de traitement des ordinateurs modernes augmente à un rythme exponentiel, le besoin de plus de puissance de traitement dans le scénario actuel n'est plus un très gros problème.

La facilité de conception peut conduire à une mauvaise conception

La base de données relationnelle est facile à concevoir et à utiliser. Les utilisateurs n'ont pas besoin de connaître les détails complexes du stockage physique des données. Ils n'ont pas besoin de savoir comment les données sont réellement stockées pour y accéder.

Cette facilité de conception et d'utilisation peut conduire au développement et à la mise en œuvre de systèmes de gestion de bases de données mal conçus. Étant donné que la base de données est efficace, ces inefficacités de conception ne seront pas mises en évidence lors de la conception de la base de données et lorsqu'il n'y a qu'une petite quantité de données.

À mesure que la base de données se développe, des bases de données mal conçues ralentiront le système et entraîneront une dégradation des performances et une corruption des données.

Phénomène des «îles d'information»

Comme mentionné précédemment, les systèmes de bases de données relationnelles sont faciles à mettre en œuvre et à utiliser. Cela créera une situation où trop de personnes ou de services créeront leurs propres bases de données et applications.

Ces îlots d'informations empêcheront l'intégration de l'information, qui est essentielle pour le bon fonctionnement et l'efficacité de l'organisation.

Ces bases de données individuelles créeront également des problèmes tels que l'incohérence des données, la duplication des données, la redondance des données, etc.

Exemple

Supposons une base de données composée des tables Fournisseurs, Pièces et Expéditions. La structure des tables et de certains exemples d'enregistrements est la suivante:

Chaque ligne du tableau Fournisseurs est identifiée par un numéro de fournisseur unique (SNo), identifiant de façon unique chaque ligne du tableau. De même, chaque pièce a un numéro de pièce unique (PNo).

En outre, il ne peut pas y avoir plus d'une expédition pour une combinaison fournisseur / pièce donnée dans la table Expéditions, car cette combinaison est la clé primaire des Expéditions, qui sert de table d'union, car il s'agit d'une relation plusieurs-à-plusieurs.

La relation entre les tables des pièces et des expéditions est donnée en ayant le champ PNo (numéro de pièce) en commun et la relation entre les fournisseurs et les expéditions résulte du fait que le champ SNo (numéro de fournisseur) est en commun.

En analysant le tableau des expéditions, il est possible d'obtenir des informations selon lesquelles un total de 500 noix sont envoyés par les fournisseurs Suneet et Ankit, 250 chacun.

De même, 1 100 boulons au total ont été expédiés par trois fournisseurs différents. 500 vis bleues ont été expédiées par le fournisseur Suneet. Il n'y a pas d'envois de vis rouges.

Références

1. Wikipédia, l'encyclopédie gratuite (2019). Modèle relationnel. Tiré de: en.wikipedia.org.
2. Techopedia (2019). Modèle relationnel. Tiré de: plafondpedia.com.
3. Dinesh Thakur (2019). Modèle relationnel. Notes sur l'ordinateur. Tiré de: ecomputernotes.com.
4. Geeks pour les geeks (2019). Modèle relationnel. Tiré de: geeksforgeeks.org.
5. Université technologique de Nanyang (2019). Un didacticiel de démarrage rapide sur la conception de bases de données relationnelles. Tiré de: ntu.edu.sg.
6. Adrienne Watt (2019). Chapitre 7 Le modèle de données relationnelles. BC Open Textbooks. Tiré de: opentextbc.ca.
7. Toppr (2019). Bases de données et schémas relationnels. Tiré de: toppr.com.