3.1 Normalisation
3.1.1 Introduction
Déterminer le moment où un nouveau tableau et d'en choisir les clés est nécessaire est un art complexe. De nombreuses ressources sont disponibles concernant les diagrammes de relations d'entité et de normalisation (1X,2X ou la très rarement utilisée 3x).
Afin de vous proposer des informations pratiques et directement opérationalisables dans des projets de petites tailles, il sera évoqué ici uniquement les concepts basiques de conception de l'architecture d'une base de données.
3.1.2 Refléxion concernant les objets réels que vous souhaitez modéliser.
La création d'une base de données correspond à la modélisation d'objets et de relations existants déjà dans le monde réel. Il est important d'avoir une visions claire de ces objets et relations afin de pouvoir les modéliser et ensuite procéder à leur implémentation.
Tous les types d'objet réels que vous souhaitez modéliser correspondent généralement à un tableau qui leur est propre.Celà s'explique par le fait que les information stoquées à propos d'un même objet doivent être homogènes et consistantes.
L'exemple d'une base de données rudimentaire de librairie serait constituée d'un tableau client, un tableau commandes et un tableau livres.
3.1.3 Pas d'informations redondantes
Exemple
On pourrait envisager d'enregistrer l'adresse du client dans le tableau des commandes.
A votre avis quel est le problème ?
Si le même client passe plusieurs fois la même commande...son nom sera donc stoqué plusieurs fois dans la base de données.
A votre avis pourquoi celà est - il génant ?
C'est un gaspillage de ressources systèmes donc une conduite à proscrire.
Dans le cas ou votre client change de nom ou d'adresse la maintenance des données est difficille étant donné qu'il faut mettre à jour plusieurs endroits dans la base. Celà peux être une cause directe de la violation des règles d'intégrité et donc entrainer des hétérogénéités et des disfonctionements dans les processus de traitement des données. On ne peut plus savoir quelles sont les information correctes, celà aboutit à une perte d'informations.
Trois types d'anomalies
Anomalie de modification (cf exemple)
Anomalie d'insertion
avec l'architecture ou il faut enregistrer l'adresse avec la commande, dans le cas où on enregristre une nouvelle commande il faut rester vigilent quand à la cohérence des données par rapport à celles déjà présentent dans la base.
Si on enregistre deux fois le même client avec des adresses différentes ont aboutit à un stoquage non consistant des données, c'est donc un résultat à proscrire.
Ce type d'anomalie est appellé anomalie d'insertion car elle intervient au moment ou on insère du contenu dans la base
Anomalie de suppression
Ce type d'anomalie est appellé de la sorte car le problème apparaît quand on effectue une opération de suppresion dans la base de données.
En imaginant toujours l'architecture commande/informations client, il y aurait un problème une fois que la commande serait traitée elle serait effacée du tableau commandes. Les données relatives au profil du client seraient perdues, celà pourrait-être souhaitable dans le cadre du respect de la vie privée cependant lea fichiers clientènles représentent une ressource précieuse pour une entreprise, il est donc naturel de s'assurer que ces informations seront conservées.
La suppression de données est directement déterminées a priori par le DBA (database administrator) qui met en place notamment, les règles de contraintes d'intégrités.
3.1.4 Utiliser des valeurs atomiques
Chaque attribut de chaque ligne ne correspond qu'à une seule chose.
Figure 7.5
Si l'attribut d'une ligne contient deux données différentes, il est alors impossible de pouvoir extraire cette information par la suite.
3.1.5 Importance du choix des clés
Il faut que les clés que vous choisissiez soient impérativement uniques !
L'utilisation d'une clé est indispensable afin de pouvoir discriminer chaque élément dans la base de données.
Certains éléments n'ont pas besoin d'être identifiés par une clé car ils sont uniques, par exemple un numéro ISBN pour un livre. Il faut être vigilent car ces cas sont assez rares ! Dans la majorité des cas une clé est impérativement nécessaire.
3.1.6 Eviter les attributs vides
Par exemple nous souhaitons permettre aux utilisateurs de pouvoir mettre un commentaire à un objet.
On peux ajouter une table commentaire
A votre avis dans quel contexte cette architecture peux s'avérer problématique ?
Si tous les utilisateurs joingnent un commentaire tout va bien. Mais si la fréquence de ce cas est faible votre base de données va comporter un nombre importants d'attributs vides.
Pour des raisons d'optimisation et d'intégrité celà est bien évidemment à éviter.
Comment faire ?
Figure 7-7
Seuls les objets qui sont commentés sont référencés dans le tableau Article_Commentaire
Top