Pour concevoir un modèle entités-associations, vous devrez certainement passer par une succession d’étapes. Nous les décrivons ci-dessous dans l’ordre chronologique. Sachez cependant que la conception d’un modèle entités-associations est un travail non linéaire. Vous devrez régulièrement revenir à une étape précédente et vous n’avez pas besoin d’en avoir terminé avec une étape pour commencer l’étape suivante.
Un autre exemple est celui d’une entreprise de production fabricant des produits à destination d’une autre société du même groupe. Il se peut que dans ce cas, le prix de production (i.e. le coût de revient industriel) soit le même que prix de vente (aucune marge n’est réalisée). Même dans ce cas où les deux caractéristiques sont identiques pour chaque entité (prix de production égale prix de vente), il faut impérativement les scinder en deux attributs au niveau du type-entité Produit. Sinon, cette égalité factuelle deviendrait une contrainte imposée par le modèle, obligeant alors l’entreprise de production à revoir son système le jour où elle décidera de réaliser une marge (prix de production inférieure au prix de vente).
Attention, un même concept du monde réel peut être représenté dans certains cas comme un attribut et dans d’autres cas comme un type-entité, selon qu’il a ou non une existence propre. Par exemple, la marque d’une automobile peut être vue comme un attribut du type-entité Véhicule de la base de données d’une préfecture mais aussi comme un type-entité Constructeur automobile dans la base de données du Ministère de l’Industrie.
Lorsqu’on ne parvient pas à trouver d’identifiant pour un type-entité, il faut se demander s’il ne s’agit pas en fait d’un type-association. Si ce n’est pas le cas, un identifiant arbitraire numérique entier peut faire l’affaire.
Il est parfois difficile de faire un choix entre un type-entité et un type-association. Par exemple, un mariage peut être considéré comme un type-association entre deux personnes ou comme un type-entité pour lequel on veut conserver un numéro, une date, un lieu, …, et que l’on souhaite manipuler en tant que tel.
Étudiez également les cardinalités des type-associations retenus. Lorsque toutes les pattes d’un type-association portent la cardinalité 1,1, il faut se demander si ce type-association et les type-entités liés ne décrivent pas en fait un seul type-entité (cf. règle 2.29).
pour faciliter la lecture du schéma, il est assez courant de ne pas y faire figurer les attributs ou de ne conserver que ceux qui font partie des identifiants. Les attributs cachés doivent alors absolument être spécifiés dans un document à part.
Pour les type-entités, choisissez un nom commun décrivant le type-entité (ex : Étudiant, Enseignant, Matière). Certain préfèrent mettre le nom au pluriel (ex : Étudiants, Enseignants, Matières). Restez cependant cohérents, soit tous les noms de type-entité sont au pluriel, soit ils sont tous au singulier.
Pour les type-association, choisissez un verbe à l’infinitif, éventuellement à la forme passive ou accompagné d’un adverbe (ex : Enseigner, Avoir lieu dans).
Pour les attributs, utilisez un nom commun au singulier éventuellement accompagné du nom du type-entité ou du type-association dans lequel il se trouve (ex : nom de client, numéro d’article).
Évitez les identifiants composés de plusieurs attributs (comme, par exemple, un identifiant formé par les attributs nom et prénom d’un type-association Personne) car :
Évitez les identifiants susceptibles de changer au cours du temps (comme la plaque d’immatriculation d’un véhicule).
Évitez les identifiants du type chaîne de caractère.
En fait, il est souvent préférable de choisir un identifiant arbitraire de type entier pour les type-entités. Cet identifiant deviendra une clé primaire dans le schéma relationnel et le SGBD l’incrémentera automatiquement lors de la création de nouvelles instances. L’inconvénient de cette pratique est qu’il devient possible de se retrouver avec deux instances du type-entités représentant le même objet mais avec deux numéros différents. Malgré cette inconvénient, cette politique de l’identifiant reste largement avantageuse dans la pratique et permet, en outre, de s’affranchir (en la satisfaisant automatiquement) de la deuxième forme normale (cf. section 2.5.4).
La modélisation conceptuelle de données exclut la représentation des traitements futurs sur ces données. Toutefois, elle nécessite la connaissance de ces traitements pour prévoir les données élémentaires indispensables à ceux-ci. En conséquence, il existe une confusion fréquente entre les concepts de données et de traitements. Par exemple, la facturation est un traitement qui nécessite de connaître toutes les caractéristiques d’une commande. Par contre, la facturation ne se traduit ni par un type-entité, ni par un type-association dans le schéma entités-associations.