Conception et normalisation d’une base de données

Cours conception et normalisation d’une base de données, tutoriel & guide de travaux pratiques en pdf.

Informations redondantes dans les tuples et anomalies de mise à jour

• Un objectif de la conception de schémas est de réduire l’espace de stockage utilisé par les relations de base (voir figure 9.4 sur l’acétate suivante)
• Un autre problème important que pose l’emploi des relations de la figure 9.4 comme relations de base est celui des anomalies de mise à jour.
Parmi celles-ci, on peut distinguer des anomalies d’insertion, de suppression et de modification.
– anomalie d’insertion : l’ajout d’un entité employé-service impose soit
*l’ajout de l’information de deux entités à la fois, et on doit s’assurer de la cohérence entre les dupli-cations d’information
*ajoute l’information avec des valeur nulles si l’employé ne se voit pas attribué immédiatement un service
*si on ajoute un nouveau service alors il n’y a pas d’employé au départ ce qui signifie que la clé pri-maire est nulle
– anomalie de modification : si on doit modifier un service alors on doit modifier tous les tuples où l’information est dupliquée
– anomalie de suppression : si on doit supprimer tous les tuples où l’information est dupliquée (par exemple tous les employés d’un service alors on perd l’information sur ce service, on doit donc pré-server au moins un tuple.
• performance : on doit parfois avoir de la redondance pour améliorer la performance.

Principe 2
Concevez les schémas des relations de base de telle sorte qu’il ne puisse pas survenir d’anomalies d’inser-tion, de suppression et de modification dans les relations. S’il y a des anomalies, indiquez-les clairement et assurez-vous que les programmes qui mettent à jour la base de données opèreront correctement.

Valeurs nulles dans les tuples

• éviter les valeurs nulles
• comment les traiter dans une fonction (ex: count, sum, etc)
• elles ont 3 interprétations possibles
– l’attribut ne s’applique pas à ce tuple (ex: NoSSDir dans relation EMPLOYEE);
– la valeur de l’attribut est inconnue pour le tuple (elle le sera plus tard);
– la valeur de l’attribut est connue pour le tuple, mais elle n’est pas encore enregistrée (elle le sera plus tard);
• créer une nouvelle entité regroupant les valeur peu fréquente.
Par exemple, si 10 % des employés disposent de bureaux individuels, il y a peu de raisons d’inclure un attribut NUMERO_BUREAU dans la relation EMPLOYE. Mieux vaut dans ce cas créer une relation BUREAU_EMPLOYE (NoSS_EMPL, NUMERO_BUREAU) qui inclut des tuples pour les seuls employés disposant d’un bureau individuel.

Principe 3
Dans la mesure du possible, évitez de placer dans une relation de base des attributs dont les valeurs sont susceptibles d’être souvent nulles. Si cela est inévitable, faites en sorte qu’elles n’apparaissent que pour des cas exceptionnels et qu’elles ne concernent pas une majorité de tuples dans la relation.

Génération de tuples parasites

• s’assurer que la jointure de deux relations sur des clés étrangères et des clés primaires ne donnent pas de tuples erronés.

Principe 4
Veillez, au cours de la définition des schémas relationnels, à ce qu’ils puissent être réunis à l’aide de condi-tions d’égalité spécifiées sur des attributs jouant le rôle de clés primaires ou de clés étrangères d’une manière qui garantisse l’absence de tuples parasites dans le résultat de la jointure.
Évitez de produire des relations qui ne résultent pas de l’association d’attributs uniques (qui ne sont pas des clés primaires ou étrangères) car les jointures réalisées à partir d’attributs de ce type sont susceptibles de contenir des tuples parasites.

Dépendance fonctionnelle
Définition de la dépendance fonctionnelle

Supposons que la totalité de la base de données peut être décrite par un seul schéma relationnel universel R = {A1, A 2 …, An}. Nous noterons par Z l’ensemble des attributs i.e. A1, A2 …, An
Soit R(Z) une relation. Il existe une dépendance fonctionnelle dans R entre deux ensembles d’attributs X ⊆ Z et Y ⊆ Z, notée X → Y, ssi pour tous tuples t1, t2 de tout état r de R, on a
t1[X]= t2[X] ⇒ t1[Y]= t2[Y]
• On dit qu’il y a dépendance fonctionnelle de X vers Y ou que Y est fonctionnellement dépendant de X.
• L’abréviation de la dépendance fonctionnelle est DF ou d.f.
• L’ensemble des attributs de X est appelé la partie gauche de DF tandis que Y est appelé la partie droite.
• Si une contrainte sur R établit qu’il ne peut pas y avoir plus d’un tuple avec une valeur X donnée dans n’importe quelle instance r(R) (c’est-à-dire si X est une clé candidate de R), cela implique que X → Y pour n’importe quel sous-ensemble d’attributs Y de R.
• Si X → Y dans R, cela ne permet pas de savoir si Y → X est vrai ou faux.