Qu’est-ce qu’un schéma relationnel ? Comment créer une base de données efficace ?

Il n’existe pas de structure de base de données unique qui soit toujours plus efficace qu’une autre. En effet, le type et la quantité de données stockées modifient la structure optimale de la base de données.

Cependant, il y a une grande différence entre la construction d’une base de données optimisée pour les performances et une base de données optimisée pour le volume de données.

En utilisant un schéma relationnel dans MySQL, vous pouvez créer une base de données optimisée pour le volume de données. C’est idéal dans les situations où le coût du stockage, du traitement et de la mémoire est prohibitif.

Bien que ce ne soit plus le cas pour l’électronique standard, il y a encore beaucoup de situations où les programmeurs et les développeurs voudraient utiliser le schéma relationnel. Bien que le stockage, la puissance de traitement et la mémoire soient peu coûteux pour les utilisateurs d’ordinateurs conventionnels, ces choses sont massivement coûteuses dans le monde de l’informatique quantique.

De même, un schéma relationnel est important dans les bases de données MySQL qui s’appuient sur les relations pour générer du sens. Les dossiers des employés et des universitaires, par exemple, peuvent être facilement considérés comme des réseaux de relations mieux décrits à l’aide d’un schéma relationnel que, par exemple, des bases de données clé-valeur ou graphe.

Le schéma relationnel est l’élément principal de la base de données relationnelle. Ces bases de données sont gérées à l’aide d’un langage et d’une structure conformes à la logique du premier ordre. Cela permet une gestion des bases de données basée sur les relations entre entités, ce qui les rend faciles à organiser en fonction du volume.

Le schéma relationnel fait référence aux méta-données qui décrivent la structure des données dans un certain domaine. C’est le plan d’une base de données qui décrit la façon dont sa structure organise les données en tables.

Par exemple, si votre base de données contient des enregistrements d’employés pour une grande entreprise, alors vous pourriez avoir des relations d’entité décrivant chaque employé comme une entité forte comme ceci :

  • Nom de l’employé
  • Numéro d’identification
  • Adresse
  • Compétences de l’employé
  • Date d’embauche
  • Années de service

Dans cet exemple, vous auriez deux attributs de données de schéma relationnel. D’abord, vous auriez l’attribut Employé, qui est la clé primaire de la table (puisque tout est lié à l’employé) et un attribut Adresse, qui est un attribut composite composé de différents éléments.

L’attribut Adresse serait composé des valeurs suivantes :

  • Ville
  • Rue
  • Numéro d’adresse
  • Code postal

Sachant cela, vous êtes prêt à mapper un diagramme de relation entre entités vers un schéma relationnel. Il devrait ressembler à ceci :

  • Employé (Nom, numéro d’identification, numéro d’adresse, rue, ville, code postal, date d’embauche)
  • Ensemble de compétences de l’employé (numéro d’identification, ensemble de compétences)

Vous devriez remarquer que les années de service sont exclues de cette liste. C’est parce que c’est un attribut dérivé qui peut être calculé en soustrayant la date d’embauche de la date actuelle. La raison pour laquelle l’ensemble des compétences de l’employé a son propre schéma est qu’il s’agit d’un attribut à valeurs multiples.

Pour un schéma relationnel, chaque type d’entité devient sa propre table, et chaque attribut à valeur unique est une colonne dans cette table. Les attributs dérivés peuvent être ignorés en toute sécurité, tandis que les attributs à valeurs multiples deviennent des tables distinctes.

La méthode de conversion des types d’entités faibles au schéma relationnel est similaire au processus décrit ci-dessus, sauf que les types d’entités faibles deviennent des tables à part entière et que la clé primaire de l’entité forte agit comme une clé étrangère dans la table.

Cela signifie que pour l’entité forte Employé, vous créeriez une clé primaire composite composée de la clé étrangère Dépendant et de la clé de l’entité faible elle-même. Cela donnerait le schéma suivant :

  • Employé (Nom, numéro d’identification, numéro d’adresse, rue, ville, code postal, date d’embauche)
  • Dépendant (Employé, ID dépendant, nom, adresse)

La corrélation ici est entre le numéro d’identification dans la table Employé et l’élément Employé de la table Dépendant.

Avec ce travail effectué, vous êtes prêt à commencer à convertir les relations. Pour ce faire, il faut comprendre la cardinalité et le degré de chaque relation.

  • Il existe trois cardinalités possibles – 1:1, 1:M, 1:N
  • Il existe trois degrés possibles – unaire, binaire et ternaire.

En poussant plus loin l’exemple ci-dessus, Employé pourrait être combiné avec une nouvelle table Département pour former une relation binaire 1:1. Si l’employé gère un département spécifique, alors il peut être décrit comme un participant partiel, tandis que le département serait décrit comme un participant total.

Le schéma relationnel ressemblerait à ceci:

  • Employé (Nom, numéro d’identification, numéro d’adresse, rue, ville, code postal, date d’embauche)
  • Département (numéro d’identification du gestionnaire, numéro d’identification du département, nom, adresse)

Dans ce cas, la clé primaire du participant partiel devient la clé étrangère du participant total. Le numéro d’identification du manager est en corrélation avec le numéro d’identification de l’employé approprié.

Ceci met en évidence une partie importante de la création du schéma relationnel. La clé primaire de l’un des participants dans une relation binaire 1:1 peut devenir une clé étrangère dans l’autre. Une autre façon de décrire la relation ci-dessus serait d’utiliser Manages comme clé étrangère sous Employé, en corrélation avec la clé primaire ID du département sous Département.

Un exemple de relation binaire 1:N serait celle entre un Enseignant enseignant une matière. Dans une classe particulière, les enseignants peuvent enseigner plus d’une Matière à une variété d’étudiants, mais toutes les Matières partagent la même relation avec l’enseignant.

Dans la relation binaire 1:1 ci-dessus, chaque département avait un gestionnaire unique. Avec cette relation binaire 1:N, un nombre variable d’étudiants peut partager le même enseignant. La clé primaire de l’enseignant serait l’ID de l’enseignant, qui serait corrélée à la clé étrangère du sujet, sous l’enseignant.

Pour décrire une relation binaire M:N, imaginez un étudiant qui s’inscrit à un cours. Créez une nouvelle table décrivant l’étudiant et une autre décrivant le cours. Ces deux tables sont liées par l’acte d’inscription, et toutes deux comportent des clés étrangères.

  • La clé étrangère de l’étudiant est l’ID de l’étudiant.
  • La clé étrangère du cours est l’ID du cours.

La clé primaire de la nouvelle table est la combinaison des clés étrangères de chaque entité. Vous la décririez comme (ID de l’étudiant, ID du cours). Il s’agit d’un schéma relationnel binaire unique M:N qui relie les étudiants individuels aux cours.

Cela fonctionne parce que les ID sont, par nature, créés dans le but d’être des clés étrangères dans les bases de données relationnelles.

Vous pouvez utiliser un schéma relationnel pour décrire des relations d’auto-référencement. Par exemple, deux employés qui sont mariés l’un à l’autre pourraient présenter la clé étrangère Conjoint. Pour les clés étrangères de ces deux employés, la référence sera l’ID de l’employé de l’autre, qui est la clé primaire de la table respective de chaque employé.

Cela fonctionne également dans un schéma relationnel avec une cardinalité 1:N. Le champ de clé primaire lui-même deviendrait la clé étrangère de la même table dans ce cas. C’est la même chose qu’un schéma unaire 1:1.

Par exemple, un employé qui est le manager d’un subordonné peut avoir manager comme sa clé étrangère. Dans ce cas, l’ID de l’employé serait la clé primaire dans la même table.

L’autoréférencement d’une relation M:N nécessite deux tables. L’une doit représenter l’entité en question et l’autre doit représenter la relation M:N.

Imaginez un employé qui est chargé de garantir la qualité d’un certain produit ou service. Cette relation devrait inclure à la fois le Garant et le Bénéficiaire comme clés étrangères qui se combinent pour être en corrélation avec l’ID de l’employé de la table Employé. Le garant et le bénéficiaire agiraient tous deux comme des clés primaires et étrangères au sein de la table du schéma relationnel nouvellement créée.

Alors que les relations binaires et unaires sont simples à décrire en utilisant le schéma relationnel avec une ou deux tables. Les tables ternaires nécessitent une troisième et nouvelle table.

La clé primaire de cette nouvelle table est constituée de la clé étrangère de chaque entité participante, additionnée. Cela signifie que la nouvelle table doit contenir trois clés étrangères à corréler.

Par exemple, la relation entre un médecin et son patient se compose en réalité de trois entités : Le médecin, le patient et le médicament. Pour décrire correctement cette relation sous forme de schéma relationnel, vous devez attribuer des clés étrangères à chacune de ces entités et les corréler à une nouvelle table intitulée Prescription.

C’est une façon simple de visualiser le fonctionnement d’une table ternaire. La clé primaire de la table Prescription nouvellement créée est (ID du médecin, ID du patient, ID du médicament). Tout schéma qui n’inclut pas ces trois pièces importantes de données manque une partie importante du puzzle.

Cette approche permettrait à un gestionnaire de base de données de créer une archive organisée d’ordonnances qui rend compte de types de médicaments spécifiques, immédiatement corrélés aux noms des patients qui les utilisent et offrent les noms des médecins qui les ont prescrits.

Pour être complet, vous pouvez souhaiter ajouter la date d’expiration à la table Médicament afin que cette donnée soit disponible dans la matrice principale. Vous pouvez ajouter Rendez-vous suivant ou Date de renouvellement à la table Prescription. Vous voudrez logiquement ajouter la date de naissance, l’adresse et d’autres données relationnelles importantes à la table Patient.

Tous ces outils se combinent pour rendre possible la création de bases de données orientées relations dans MySQL. Vous pouvez vous entraîner à créer vos propres bases de données MySQL en ligne avec n’importe quel navigateur en utilisant SQLDBM.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.