Fiche de révision : Structure de base de données

Dépendance fonctionnelle

• Soient $A$ et $B$ deux ensembles d'attributs. On dit que $B$ dépend fonctionnellement de $A$, si, à chaque occurrence prise par $A$ ne correspond qu'une et une seule valeur de $B$.
• On note cette dépendance $A \rightarrow B$.
• Il est possible de caractériser une DP : on observera si une dépendance fonctionnelle :
• est élémentaire ;
• et si elle est directe.
• Soient $A$ et $B$ deux ensembles d'attributs tels que $A \rightarrow B$. La dépendance $A \rightarrow B$ est élémentaire s'il n'existe pas un attribut $C$ contenu dans $A$ tel que $C \rightarrow B$.
• Dans notre exemple de base de données du club de cuisine, on a :
• $(idIngredient, idRecette) \rightarrow nomIngredient$
• La DF n'est pas élémentaire.
• $(idIngredient, idRecette) \rightarrow quantite$
• La DF est élémentaire.
• Soient $A$ et $B$ deux ensembles d'attributs tels que $A \rightarrow B$. La dépendance $A \rightarrow B$ est directe s'il n'existe pas un attribut $C$ tel que $A \rightarrow C$ et $C \rightarrow B$.
• Dans notre exemple de base de données du club de cuisine, on a :
• $idRecette \rightarrow nomAdherent$
• La DF n'est pas directe.
• $idRecette \rightarrow idAdherent$
• La DF est directe.

La normalisation

• La normalisation permet de contrôler les relations du schéma relationnel issu du MCD afin d'éviter les redondances.
• Cette démarche peut donc conduire à une modification du schéma relationnel initial.
• La normalisation impose cinq formes : dans ce cours, nous nous focaliserons sur les trois premières formes normales qui sont suffisantes dans une grande majorité des cas.

Première forme normale

• Une relation est dite en première forme normale si, et seulement si, tout attribut qui la compose contient une valeur atomique (pas décomposable). On la note 1FN.
• Si on observe la relation Recette de la base de données du club de cuisine, on voit que son attribut « etapes » est décomposable.
• Notre relation Recette n'est donc pas conforme à la 1FN.
• Si on ne la rend pas conforme, on risque de sous-estimer ou surestimer la place à réserver dans la relation pour l'enregistrement des étapes d’un seul attribut.
• Si on observe la relation Adherent, on voit que son attribut « adresse » est décomposable (numéro, rue, complément, code postal et ville).
• Notre relation Adherent n'est donc pas conforme à la 1FN.
• Si on ne la rend pas conforme, on ne sera pas en mesure de recenser tous les adhérents d'une même commune.
• Une fois les relations du schéma mises en forme 1NF, il est temps de vérifier que le nouveau schéma relationnel respecte la deuxième forme normale.

Deuxième forme normale

• Une relation est dite en deuxième forme normale si, et seulement si, elle est en première forme normale et si toutes les dépendances fonctionnelles entre la clé et les autres attributs sont élémentaires. On la note 2FN et on peut écrire : 1FN ⊂ 2FN.
• Si nous regardons la relation Utilise(idRecette, idIngredient, quantite, unite, type), on a $idRecette, idIngredient \rightarrow type$, mais aussi $idIngredient \rightarrow type$.
• La relation Utilise ne respecte pas la 2FN.
• Si on ne la rend pas conforme, il va se produire une redondance.
• Pour y remédier, sachant que l'on a identifié $idIngredient \rightarrow type$, il semble naturel de sortir « type » de la relation Utilise pour l'ajouter aux attributs de la relation Ingredient.
• Maintenant que les relations du schéma respectent la 2NF, il ne nous reste plus qu'à contrôler que nos relations respectent la troisième forme normale.

Troisième forme normale

• Une relation est dite en troisième forme normale si, et seulement si, elle est en seconde forme normale et si tout attribut n'appartenant pas à la clé primaire n'est pas en dépendance fonctionnelle directe avec un attribut ou un ensemble d'attributs non-clé. On la note 3FN et on peut écrire : 1FN ⊂ 2FN ⊂ 3FN.
• Si nous regardons la relation Adherent, on peut remarquer que $ville \rightarrow codePostal$ ; or ni « ville », ni « codePostal » ne sont des attributs appartenant à la clé primaire de la relation Adherent.
• Notre relation Adherent ne respecte pas la 3NF.
• Si on ne la rend pas conforme, on se trouvera confronté à une redondance (villes et codes postaux).
• Pour y remédier, sachant que l'on a mis en évidence $ville \rightarrow codePostal$, il suffit de sortir « codePostal » de la relation Adherent et de créer une nouvelle relation Ville.
  Ce qui donne :
• Nous avons donc normalisé notre schéma relationnel en veillant à ce que ses relations respectent la 3NF, donc la 2NF et par conséquent la 1NF.
  Voici le MCD et le schéma relationnel final de notre exemple, maintenant normalisé.

Les contraintes d'intégrité

• Les contraintes d'intégrité sont des règles que doivent respecter les attributs des relations.
• On en compte trois principales.
• La contrainte de domaine
• Lors de la création d'une table dans la base de données, il est nécessaire de préciser le domaine dans lequel chacun de ses attributs prend ses valeurs.
• Une fois la contrainte de domaine définie pour chaque attribut, le SGBD interdit l'introduction de tuples dans une relation dont le type d'un des attributs ne serait pas conforme à celui qui lui aura été attribué par la contrainte de domaine.
• La contrainte de relation
• La contrainte de relation impose que la clé primaire formée par un ou plusieurs attributs d'une relation soit unique et non nulle.
• C'est le respect de cette contrainte qui garantit l'identification sans ambiguïté d'un tuple dans une relation.
• Dès lors que cette contrainte de relation est précisée pour une table, le SGBD interdira l'introduction d'un tuple dont la valeur de la clé primaire sera identique à celle d'un tuple déjà présent dans la base ou sera nulle.
• La contrainte de référence
• Si l'on insère un tuple dans une table faisant appel à des clés étrangères, le SGBD doit contrôler l'existence de ces clés dans les relations d'où elles proviennent.
• Il est nécessaire d'indiquer au SGBD ce qu'il doit faire dans le cadre de la suppression d'un tuple dans une table dont la clé primaire est étrangère dans une autre table. Quatre options possible :
• interdire la suppression ;
• supprimer les tuples concernés dans les autres tables ;
• avertir l'utilisateur d'une incohérence ;
• mettre les valeurs des attributs concernés à une valeur nulle dans les tuples concernés, si l'opération est possible.