Au chapitre précédent, nous avons vu le Modèle Conceptuel des Données. Nous allons maintenant examiner le niveau logique des données, et un de ses formalismes particulièrement adapté aux bases de données relationnelles, le modèle relationnel. Nous examinerons également les règles de passage du MCD vers le modèle relationnel. De ce type de formalisme, nous verrons qu'il est aisé de passer à la représentation physique des données, et à la mise en oeuvre du SI sur un système de gestion de base de données relationnelles (SGBDR).
Comme pour le modèle entité - association, on définit des domaines dans lesquels des attributs prennent leur valeur. Une relation est un ensemble d'entités et sa description peut prendre la forme d'un tableau dans lequel chaque ligne représente une occurrence d'entité et chaque colonne un attribut.
La relation COUREUR(nom, prénom, dateNaissance) peut se représenter par :
La relation ETAPES (NuméroEtape, VilleDépart, VilleArrivée, NbKm) peut se représenter par
Un n-uplet est une occurrence d'une relation. Plus concrètement, il représente une ligne du tableau. On dit aussi t-uple au lieu de n-uplet. Exemple : (1,St Denis, StPaul, 50) est un n-uplet de la relation ETAPES
La cardinalité d'une relation est son nombre d'occurrence. Dans l'exemple précédent, la cardinalité de la relation COUREUR est de 2.
Le degré d'une relation est son nombre d'attribut. . Dans l'exemple précédent, le degré de la relation COUREUR est de 3.
Une clef primaire est constituée d'un ou plusieurs attributs de la relation. Elle permet d'identifier sans équivoque chaque n-uplet de la relation.
Dans la relation Coureur, NOM peut ne pas être suffisant pour distinguer les occurrences, en cas d'homonymie. On peut rajouter un attribut à la relation, un numéro de coureur, qui devient clef primaire
Selon les dépendances fonctionnelles observées, il peut être nécessaire de connaître la clef primaire d'une relation pour identifier un n-uplet d'une autre relation. Dans ce cas, la clef primaire de la première devient clef étrangère de la seconde.
Exemple : soit la nouvelle relation qui permet de modéliser les temps des coureurs : TEMPS(NumCoureur, NumeroEtape, tempsrealisé). Les clefs NumCoureur et NuméroEtape, clefs primaires des relations COUREUR et ETAPES, permettent d'identifier chaque n-uplet de la relation. En effet, un coureur ne participe qu'une seule fois à une étape ! Ce sont donc les clefs étrangères de COUREUR.
On représente chaque relation de la modélisation par : NOMRELATION (clefPrimaire1, clePrimaire2, ..., attribut1, Attribut2, .. ,#clefEtrangère1,#clefEtrangère1)
Exemple : TEMPS (#NumCoureur,#NumeroEtape, tempsrealisé)
COUREUR (NumCoureur, (nom, prénom, dateNaissance)
ETAPES (NuméroEtape, VilleDépart, VilleArrivée, NbKm)
Le modèle relationnel est une modélisation des données. Nous pouvons le normaliser, de la même manière que nous avions normalisé le MCD. Ainsi, nous allons reprendre les règles de formes normales :
Pour être en 1FN, une relation doit avoir une clef et chaque attribut doit être une donnée élémentaire.
Exemple :
EMPLOYE (NomEmployé, PrénomEmployé, AdresseEmployé, DateEmbauche).
Cette table pose des problèmes d'homonymie, deux employés peuvent avoir le même nom, donc le même identifiant !! Pour passer le modèle en 1FN, il faut rajouter un matricule :
EMPLOYE (MatriculeEmploye, NomEmployé, PrénomEmployé, AdresseEmployé, DateEmbauche)
Pour être en 2FN, une relation doit être en 1FN et tout attribut non-clef ne doit pas dépendre d'une partie de la clef. Seules les relations dont la clef est composée de plusieurs attributs sont concernés.
Exemple :
COMMANDE (#N°Client, #N°Produit, Qte, Nomclient) CLIENT (N°Client, Adr, VilleClient)
Dans la relation commande, NomClient dépend seulement de la partie de la clef N°Client. Pour normaliser le modèle en 2FN, il faut donc mettre NomClient dans la relation CLIENT :
COMMANDE (#N°Client, #N°Produit, Qte) CLIENT (N°Client, Adr, VilleClient, Nomclient)
Pour être en 3FN, une relation doit être en 2FN et tout attribut non clef ne doit pas dépendre d'un autre attribut non clef. (pas de transitivité)
Exemple :
FACTURE(N°Facture, dateFact, N°Fournisseur, RSFournisseur, AdrFournisseur, VillFournisseur)
Les attributs AdrFournisseur et VilleFournisseur dépendent de la propriété N°Facture, mais aussi de RSFournisseur, qui elle-même dépend de la clef. On a donc 2 dépendances fonctionnelles transitives, qu'on peut supprimer en créant une nouvelle relation.
FACTURE (N°Facture, dateFact, N°Fournisseur, #RSFournisseur) FOURNISSEUR (RSFournisseur, AdrFournisseur, VillFournisseur)
La normalisation de Boyce - Codd a pour but de supprimer les dépendances fonctionnelles autre que celles de la clé vers les attributs non-clefs.
Exemple :
Dans une entreprise de production qui travaille à la commande de on veut pouvoir comptabiliser le temps consacré par chaque employé à chaque commande. Un employé n'est pas affecté d'une manière fixe à un atelier et un atelier est entièrement consacré à une commande. Soit la relation suivante :
ATTRIBUTION (#employé, #Commande, NbHeures, N°Atelier)
La DF fonctionnelle à supprimer dans cette relation est N°Atelier -> N°Commande. L'application de la BCFN se traduit par les relations suivantes :
ATTRIBUTION (#employé, #Commande, NbHeures) ATELIER (N°Atelier, N°Commande)
Le passage du MCD vers le modèle relationnel se base sur l'application de quatre règles simples, énoncées ci-dessous. Il est à noter que cette transformation peut se faire en sens inverse, en appliquant les mêmes règles.
Toute entité du MCD est traduite en une table dont la clef primaire et les attributs proviennent de l'entité
Une association binaire qui a une cardinalité égale à 0,1 ou 1,1 pour une entité est traduite par une clef étrangère ajoutée à la table qui traduit cette entité. Cette clef étrangère est la clef primaire de l'entité associée.
Une association binaire qui n'a pas de cardinalité égale à 0,1 ou 1,1 est traduite en une table dont la clef primaire est constituée de l'ensemble des identifiants des entités qui y participent.
