49
4.1 Modélisation de la base de données
• Cardinalité non identifiante – La clé primaire est migrée dans un attribut
non-clé de la table fille : relation de un-à-plusieurs.
• Cardinalité optionnelle – Relation non identifiante avec valeur non
nécessaire : relation de zéro-à-plusieurs.
• Cardinalité récursive – L’attribut clé est lié à un autre attribut de la même
table.
• Cardinalité plusieurs-à-plusieurs – Non-identifiant dans les deux sens. En
implémentation physique, cette cardinalité nécessite une table intermédiaire.
Lorsqu’une clé est migrée plusieurs fois dans la même table fille, on parle de rôles
joués par la clé. Il est de bon aloi de préfixer le nom de l’attribut déplacé par son rôle.
Par exemple, pour un lien avec un identifiant de personne : VendeurPersonneID, et
ClientPersonneID.
4.1.2 Normalisation
Un bon modèle de données n’exprime une information qu’une seule fois, au bon
endroit. Dès que la même information est placée à deux endroits du modèle, sa
valeur est compromise… parce qu’elle peut être différente. Si nous pouvons trouver
le numéro de téléphone d’un contact dans la table Contact et dans la table Adresse
qui lui est liée, que faire lorsque les deux numéros ne sont pas les mêmes (et croyeznous, tôt ou tard il y aura des différences) ? Il y a peut-être un numéro erroné, mais
lequel ? Ou il s’agit simplement de son numéro privé et de son numéro professionnel… mais lequel ? Toute information doit être précisée, délimitée et unifiée :
tel est le but de la normalisation.
Ce qui sous-tend le concept de normalisation, est en fin de compte, le monde
réel. Il n’y a rien de particulièrement technique, il n’y a pas d’ingénierie particulièrement obscure et sophistiquées dans la modélisation de données, fort heureusement.
La plupart des tentatives de sophistication, surtout si elles entraînent le modèle à
s’éloigner de la réalité, sont des errements malheureux. Que cela signifie-t-il ? Qu’un
modèle de données relationnel est formé d’entités et de relations : des tables, et des
relations entre ces tables. Chaque entité décrit une réalité délimitée, observable
dans le champ modélisé par la base de données. Il suffit d’observer autour de soi, de
comprendre la nature élémentaire des processus à l’œuvre, pour dessiner un modèle
de données. Avons-nous des clients, des magasins, des employés, des produits ? Nous
aurons donc les tables Client, Magasin, Employe, Produit. Un employé vend-il à ses
clients des produits dans un magasin ? Nous aurons donc une table de vente, qui
référence un vendeur, un magasin, un client, un produit, à une date donnée, avec un
identifiant de vente, peut-être un numéro de ticket de caisse. Mais, vend-il plusieurs
produits lors de la même vente ? Nous aurons donc à supprimer l’identifiant de produit dans la table de ventes, et à créer une table de produits vendus, liée à la vente.
L’employé est-il toujours dans le même magasin ? Sans doute, alors retirons l’identifiant de magasin de la vente, et ajoutons l’identifiant du magasin dans la table des
employés. Et si l’employé peut changer de magasin ? Créons alors une table intermé-
4.1 Modélisation de la base de données
• Cardinalité non identifiante – La clé primaire est migrée dans un attribut
non-clé de la table fille : relation de un-à-plusieurs.
• Cardinalité optionnelle – Relation non identifiante avec valeur non
nécessaire : relation de zéro-à-plusieurs.
• Cardinalité récursive – L’attribut clé est lié à un autre attribut de la même
table.
• Cardinalité plusieurs-à-plusieurs – Non-identifiant dans les deux sens. En
implémentation physique, cette cardinalité nécessite une table intermédiaire.
Lorsqu’une clé est migrée plusieurs fois dans la même table fille, on parle de rôles
joués par la clé. Il est de bon aloi de préfixer le nom de l’attribut déplacé par son rôle.
Par exemple, pour un lien avec un identifiant de personne : VendeurPersonneID, et
ClientPersonneID.
4.1.2 Normalisation
Un bon modèle de données n’exprime une information qu’une seule fois, au bon
endroit. Dès que la même information est placée à deux endroits du modèle, sa
valeur est compromise… parce qu’elle peut être différente. Si nous pouvons trouver
le numéro de téléphone d’un contact dans la table Contact et dans la table Adresse
qui lui est liée, que faire lorsque les deux numéros ne sont pas les mêmes (et croyeznous, tôt ou tard il y aura des différences) ? Il y a peut-être un numéro erroné, mais
lequel ? Ou il s’agit simplement de son numéro privé et de son numéro professionnel… mais lequel ? Toute information doit être précisée, délimitée et unifiée :
tel est le but de la normalisation.
Ce qui sous-tend le concept de normalisation, est en fin de compte, le monde
réel. Il n’y a rien de particulièrement technique, il n’y a pas d’ingénierie particulièrement obscure et sophistiquées dans la modélisation de données, fort heureusement.
La plupart des tentatives de sophistication, surtout si elles entraînent le modèle à
s’éloigner de la réalité, sont des errements malheureux. Que cela signifie-t-il ? Qu’un
modèle de données relationnel est formé d’entités et de relations : des tables, et des
relations entre ces tables. Chaque entité décrit une réalité délimitée, observable
dans le champ modélisé par la base de données. Il suffit d’observer autour de soi, de
comprendre la nature élémentaire des processus à l’œuvre, pour dessiner un modèle
de données. Avons-nous des clients, des magasins, des employés, des produits ? Nous
aurons donc les tables Client, Magasin, Employe, Produit. Un employé vend-il à ses
clients des produits dans un magasin ? Nous aurons donc une table de vente, qui
référence un vendeur, un magasin, un client, un produit, à une date donnée, avec un
identifiant de vente, peut-être un numéro de ticket de caisse. Mais, vend-il plusieurs
produits lors de la même vente ? Nous aurons donc à supprimer l’identifiant de produit dans la table de ventes, et à créer une table de produits vendus, liée à la vente.
L’employé est-il toujours dans le même magasin ? Sans doute, alors retirons l’identifiant de magasin de la vente, et ajoutons l’identifiant du magasin dans la table des
employés. Et si l’employé peut changer de magasin ? Créons alors une table intermé-