WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Gestion d'informations. Mutation vers les bases de données relationnelles et le langage SQL.


par Jacques MUDUMBI
Université de Yaoundé 1 - Master 2017
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

III.6.3. Cas pratique

Pour éprouver ces différentes formes normales, il faut dire que les critères des formes normales sont satisfaits si le modèle entité-association est bien construit et que si les règles de passage au modèle relationnel ont été correctement appliquées. Par-là, la vérification de toutes les formes normales successives n'a plus alors besoin d'être systématique [26].

Outre, avec notre part, supposons au contraire que le modèle entité-association ait fourni la relation suivante (figure III.5.).

A l'évidence, celle-ci n'est pas en 1NF ; il faut donc la transformer conformément à la figure III.6. Or, la clé de la nouvelle table, composée des attributs N°E et Option, détermine bien de manière unique les attributs non-clé (c'est-à-dire qu'on a les dépendances fonctionnelles (N°E,Option)--Nom, (N°E,Option)--Prénom, et (N°E,Option)--Adresse). Cependant, la transformation a manifestement créé des redondances et, intuitivement, on sait que l'adresse de l'élève n'a aucun rapport avec l'option choisie. Cela se traduit par le fait que les attributs non-clé sont fonctionnellement dépendants d'une partie de la clé (N°E--Nom, N°E--Prénom, et N°E--Adresse). La deuxième forme normale exige donc de créer deux tables séparées (figure III.7.).

Figure III.9. Passage en 3NF, après ajout de la table Code_postal avec attributs (rue et ville).

61

Supposons qu'en plus des attributs précédents, on ait stocké dans la table ELEVE le code postal et la ville, et qu'on ait séparé le numéro de voie et la rue. La 2NF correspondante est représentée figure III.8. (la table CHOIX n'a pas été représentée). Dans cette table, l'attribut CodePostal dépend fonctionnellement de l'attribut composé (Rue, Ville) et, par là même, dépend transitivement de la clé.

Pour passer en 3NF, il faut donc créer une table CODE_POSTAL distincte, et faire apparaître dans ELEVE l'attribut codant la rue et la ville sous forme de clé étrangère (figure III.8.) :

Figure III.8. Passage en 3NF, en ajoutant la table Code_postal avec attributs (rue et ville).

On trouve seulement, dans la nouvelle table, qu'il y a encore de la redondance. C'est la raison pour laquelle, si la clé composée de la rue et de la ville détermine bien le code postal, la ville est aussi fonctionnellement dépendante du code postal (c'est-à-dire (Rue,Ville)--CodePostal et CodePostal--Ville). Ceci est lié au fait que l'attribut (Rue, CodePostal) constitue également une clé candidate (clé secondaire). Pour obtenir une forme normale de Boyce-Codd, il faut donc décomposer cette relation en deux (figure 6-3) :

62

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Tu supportes des injustices; Consoles-toi, le vrai malheur est d'en faire"   Démocrite