• 20 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 20/10/2020

Évitez la redondance

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Réfléchissons ...

C'est bien beau d'avoir plusieurs tables avec des clés étrangères entre elles, mais dans ma base de données, je préfère que toutes mes informations soient regroupées dans une seule grande table !

En effet, en suivant ce raisonnement, nous aurions ce type de relation, dans laquelle les informations sur les pommes et sur les variétés seraient regroupées :

Cela pose plusieurs problèmes :

  •  Si le prix au kilo d'une variété change, il faudra le modifier sur toutes les lignes correspondant à des pommes de la variété en question. En informatique, on n'aime pas vraiment qu'une information soit stockée à plusieurs endroits (i.e. la redondance de données), car en cas de modification, il est probable d'oublier d'actualiser l'information partout où c'est nécessaire. Si l'information n'est pas modifiée partout, alors la cohérence est perdue !

  • Si nous souhaitons ajouter les informations d'une nouvelle variété à notre base de données, mais que nous n'avons pas encore de pomme de cette variété, nous ne pouvons pas le faire. En effet, chaque ligne de la relation ci-dessus représente une pomme. Si nous n'avons pas plus de pommes qu'avant, il nous est interdit d'ajouter une ligne à cette table, même si nous avons découvert les caractéristiques d'une nouvelle variété !

Comment éviter la redondance ?

Très bien, mais si j'avais été mis face à cette relation (qui regroupe à la fois des pommes et des variétés), comment aurais-je pu savoir qu'il fallait la diviser en deux relations ?

La règle

Il y a une règle pour cela ! ;) Elle est compliquée, mais je donne un exemple juste en dessous :

Dans une relation, si un attribut A dépend uniquement d'un groupe d'attributs G (et que ce groupe d'attributs n'est pas une clé candidate), alors il est possible de créer une nouvelle relation qui contiendra les attributs A et G.

Il faut cependant s'assurer que G soit minimal (c'est-à-dire que l'on ne puisse pas enlever d'attribut au groupe G sans casser la dépendance entre A et G).

Avons-nous appliqué cette règle avec nos relations pomme et variété ?

Dans l'exemple en haut de cette page, l'attribut prix_au_kilo ne dépend que de la variété, mais nom_variété n'est pas une clé candidate.

Ainsi on peut créer une nouvelle table dans laquelle nom_variété est la clé primaire. Elle contiendra l'attribut prix_au_kilo. De même, les attributs maturation et goût ne dépendent eux aussi que de nom_variété ! On peut donc les ajouter à notre nouvelle relation.

Notre nouvelle relation
Notre nouvelle relation

Nous voici donc avec une relation toute nouvelle et toute belle ! Que remarquez-vous ? Que cette nouvelle relation est exactement la même que la table variété que nous avions définie dans les chapitres précédents (au nom de colonne près) :

Faut-il à tout prix éviter la redondance ?

Dans les chapitres suivants, lorsque nous manipulerons les données, nous serons amenés à former de nouvelles tables, dont certaines ressembleront à la table du haut de cette page, qui est redondante. Ce n'est pas un problème lorsqu'on manipule les données pour les questionner. La redondance, il faut l'éviter dans le stockage des données.

Aller plus loin : les dépendances fonctionnelles

Oui, mais comment savoir si "un attribut dépend d'un groupe d'attributs" ? Cela ne semble pas toujours évident !

C'est vrai. Voici donc un petit "truc":

Soit une relation pomme. Imaginez-vous une pomme hypothétique, donc vous ne connaissez pas les caractéristiques. Ou plutôt, vous ne connaissez d'elle que certaines caractéristiques, c'est-à-dire certains attributs seulement. Appelons ces attributs G. Maintenant, demandons-nous si un attribut A dépend (ou non) de G. La question à se poser est la suivante :

En ne connaissant que G, et en ayant à disposition la relation pomme, puis-je trouver de manière certaine A ?

Exemple : Je vous dis que j'ai une pomme cachée derrière mon dos. Je vous donne également un papier sur lequel est imprimée la totalité de la relation pomme. Si la seule chose que je veuille bien vous dire est...

  • que cette pomme est de variété Gala ( G=[nom_variete] ). Pouvez-vous me dire si son goût sera sucré ou acidulé ( A=gout )?

    • La réponse est oui. Remarquez que vous n'avez même pas besoin de savoir précisément de quelle pomme il s'agit, car de toute manière, toutes les pommes Gala sont toujours sucrées !

  • que cette pomme est de variété Gala. Pouvez-vous me donner sa masse ?

    • La réponse est non.

  • que cette pomme a pour identifiant 2 et qu'elle est de couleur jaune ( G=[identifiant,couleur] ). Pouvez-vous me donner sa masse ?

    • La réponse est oui.

Si la réponse est non, alors A ne dépend pas (ou pas uniquement) de G. Si la réponse est oui, alors A dépend de G.

Aller plus loin : la normalisation

Séparer des relations comme nous venons de le faire évite la redondance de données. En effet, cela permet qu'une information ne soit présente qu'à un seul endroit.

Dans le domaine des bases de données, le fait d'enlever les redondances s'appelle la normalisation.

Pour en savoir plus, je vous renvoie vers le chapitre Optimisez votre modèle relationnel avec les formes normales du cours Faites une base de données avec UML, qui explique très bien la normalisation. Mais pensez à revenir ici ensuite, sinon je serai jaloux ! ;)

En résumé

  • Dans les bases de données, on n'aime pas la redondance d'information.

  • Si une table contient de la redondance, mieux vaut la séparer en plusieurs tables avant de la stocker dans la base de données.

  • Il y a une règle pour savoir comment séparer une table redondante.

Exemple de certificat de réussite
Exemple de certificat de réussite