Reprenons notre formulaire d’inscription au club de basket.
On en avait déduit un dictionnaire des données:
| Données | Obligatoire |
|---|---|
| nom | x |
| prénom | x |
| date de naissance | x |
| rue | x |
| code postal | x |
| localité | x |
| téléphone | x |
| nom du contact | x |
| prénom du contact | x |
| téléphone du contact | x |
Extraction des groupes répétitifs
Comme groupe répétitif, il y a les moyens de communication (téléphone et email). On va donc extraire ceux-ci de l’entité principale “Membre”
On pourrait s’étonner que le téléphone du contact n’est pas sorti mais c’est un cas particulier car il n’est pas lié directement au membre mais à la personne de contact. Mais ne vous inquiété pas, il sortira plus tard.
Extraction des attributs non lié directement à la clé
Il y a deux groupes qui doivent sortir, commençons par les données lié à la localité. C’est un cas d’école, qu’on commence à connaitre.
Ensuite on a la personne de contact. Il est tout a fait possible qu’une personne soit personne de contact pour plusieurs personne donc cela vaut la peine de le sortir.
Mais quand on regarde bien la personne de contact à un téléphone, qui est u moyen de communication. Donc on pourrait le lier à notre table. De cette manière là, si notre client veut aussi le mail de la personne de contact, c’est déjà fait.
Cardinalité
Ensuite on ajoute les cardinalités
Agrégation des données
Dans ce cas, on voit que l‘“Entité” membre et l’entité “Personne de Contact” sont fort similaire. Il serait donc possible les fusionnée pour n’en faire même entité. La relation entre les membres et les personnes de contact serait une relation qui pointent sur l’entité elle-même. Ceci est tout a fait possible et apparaît souvent en fin d’analyse. L’exemple le plus courant est celui des enfants et des parents, on est enfants de quelqu’un e
Et donc on peut faire de même avec la personne de contact et le membre
De plus, cela permet que les personnes soit membres aussi ce qui est plus que probable.