Modèle relationnel

Introduction

Le modèle entité-association décrit dans la section précédente est un modèle abstrait, pas directement implantable dans un ordinateur. Il faut par conséquent le traduire en un schéma de base de données relationnelle sous forme de tables, de colonnes et de contraintes d'intégrité. Un schéma de base de données relationnelles contient la définition des tables, des attributs et des clés primaires. Les contraintes d'intégrité imposeront des limites aux domaines de définition des attributs et définiront des dépendances entre les tables de la base de données.

Le passage du modèle entité-association à un schéma de base de données conduisant à plusieurs variantes possibles, il incombe aux architectes de données de prendre les décisions appropriées. Remarquons néanmoins que de mauvais choix peuvent engendrer des redondances dans la base de données impliquant par les suites des incohérences lors de l'insertion, de la suppression ou de la modification de certaines données dans la base. A titre d'exemple, considérons la table EMPLOYE qui contiendrait, pour chaque employé de l'entreprise pour laquelle vous concevez une base de données, le nom, la rue, la ville ainsi que le numéro et la description du département auquel est affecté l'employé en question:

Dans l'exemple ci-dessus, le nom du département «Finances» apparaît pour chaque employé du département numéro 6. Il en est de même pour les autres départements car plusieurs employés peuvent travailler dans un même département. Puisque le nom d'un département donné apparaît plusieurs fois dans la table, l'attribut «Description» est redondant. Or, une table contenant des informations redondantes peut entraîner des anomalies de mutation pouvant se présenter sous trois formes:

• Anomalie d'insertion
  Supposons qu'il faille définir un nouveau département «Marketing» dans l'entreprise. Avec la table actuelle, cette opération est impossible sans insérer un nouvel employé ou modifier l'attribution d'un employé existant. Il existe donc une anomalie d'insertion car nous ne pouvons insérer aucune nouvelle ligne dans la table sans donner un numéro d'employé unique.
• Anomalie de suppression
  En supprimant de la table tous les employés d'un même département, nous perdons simultanément le numéro et la désignation du département en question. Nous parlons alors d'anomalie de suppression dans la mesure où nous perdons des informations involontairement.
• Anomalie de mise à jour
  Si la description du département numéro 6 devient «Service des finances» au lieu de «Finances», il est nécessaire d'appliquer ce changement de nom à l'ensemble des employés du département concerné. En d'autres termes, même si la mise à jour ne porte que sur une seule pièce d'information, elle entraîne une adaptation de la table EMPLOYE à plusieurs endroits différents. Cet inconvénient s'appelle anomalie de mise à jour.

Afin d'éviter l'apparition de redondance et des anomalies qui en résultent, une meilleure approche que celle présentée ci-dessus consiste à enregistrer une fois pour toutes la description de chaque département dans une table séparée au lieu de la répéter pour chaque employé:

Cette section a pour but de définir une méthode permettant de représenter les ensembles d'entités et de liens par des tables. Des règles simples permettent de traduire correctement un modèle entité-association en un schéma de base de données relationnelle cohérente. La méthode présentée dans cette section se composera de trois étapes.