La représentation du modèle entités-associations s’appuie sur trois concepts de base :
L’objet est une entité ayant une existence propre. L’association est un lien ou relation entre objets sans existence propre. La propriété est la plus petite donnée d’information décrivant un objet ou une association.
Exemples d’entité : Jean Dupont, Pierre Bertrand, le livre que je tiens entre les mains, la Ferrari qui se trouve dans mon garage, etc.
Les entités ne sont généralement pas représentées graphiquement.
Les personnes, les livres et les voitures sont des exemples de type-entité. En effet, dans le cas d’une personne par exemple, les informations associées (i.e. les propriétés), comme le nom et le prénom, ne changent pas de nature.
Une entité est souvent nommée occurrence ou instance de son type-entité.
La figure 2.1 montre la représentation graphique d’un exemple de type-entité (Personne) sans ses propriétés associées.
Les type-entité Personne, caractérisé par un nom et un prénom, et Voiture, caractérisé par un nom et une puissance fiscale, ne peuvent pas être regroupés car ils ne partagent leurs propriétés (le prénom est une chaîne de caractères et la puissance fiscale un nombre). Les type-entité Personne, caractérisé par un nom et un prénom, et Livre, caractérisé un titre et un auteur, possèdent tous les deux deux attributs du type chaîne de caractères. Pourtant, ces deux type-entités ne peuvent pas être regroupés car ils ne partagent pas une même sémantique : le nom d’une personne n’a rien à voir avec le titre d’un livre, le prénom d’une personne n’a rien à voir avec un auteur.
Par abus de langage, on utilise souvent le mot entité en lieu et place du mot type-entité, il faut cependant prendre garde à ne pas confondre les deux concepts.
Exemples d’attribut : le nom d’une personne, le titre d’une livre, la puissance d’une voiture.
La figure 2.2 montre la représentation graphique d’un exemple de type-entité (Personne) avec trois attributs.
Par exemple, si le modèle doit comporter des informations relatives à des articles et à leur fournisseur, ces informations ne doivent pas coexister au sein d’un même type-entité. Il est préférable de mettre les informations relatives aux articles dans un type-entité Article et les informations relatives aux fournisseurs dans un type-entité Fournisseur. Ces deux type-entités seront probablement ensuite reliés par un type-association.
Il est donc impossible que les attributs constituant l’identifiant d’un type-entité (respectivement type-association) prennent la même valeur pour deux entités (respectivement deux associations) distinctes. Exemples d’identifiant : le numéro de sécurité sociale pour une personne, le numéro d’immatriculation pour une voiture, le code ISBN d’un livre pour un livre (mais pas pour un exemplaire).
Ainsi, chaque type-entité possède au moins un attribut qui, s’il est seul, est donc forcément l’identifiant.
Dans la représentation graphique, les attributs qui constituent l’identifiant sont soulignés et placés en tête (cf. figure 2.3).
Exemples d’association : l’emprunt par l’étudiant Tanidute du 3 ème exemplaire du livre « Maîtrisez SQL ».
Les associations ne sont généralement pas représentées graphiquement.
Comme les type-entités, les type-associations sont définis à l’aide d’attributs qui prennent leur valeur dans les associations.
Un type-association peut ne pas posséder d’attribut explicite et cela est relativement fréquent, mais on verra qu’il possède au moins des attributs implicites.
Exemples de type-association : l’emprunt d’un livre à la bibliothèque.
Une association est souvent nommée occurrence ou instance de son type-association.
La figure 2.4 montre la représentation graphique d’un exemple de type-association.
Par abus de langage, on utilise souvent le mot association en lieu et place du mot type-association, il faut cependant prendre garde à ne pas confondre les deux concepts.
Cette collection comporte au moins un type-entité (cf. section 2.3.2), mais elle peut en contenir plus, on parle alors de type-association n-aire (quand n=2 on parle de type-association binaire, quand n=3 de type-association ternaire, …).
Comme un type-entité, un type-association possède forcément un identifiant, qu’il soit explicite ou non.
Cette règle implique que deux instances d’un même type-association ne peuvent lier un même ensemble d’entités.
Souvent, un sous-ensemble de la concaténation des identifiants des type-entités liés suffit à identifier le type-association.
On admet également un identifiant plus naturel et explicite, à condition qu’il ne soit qu’un moyen d’exprimer plus simplement cette concaténation.
Exemple de cardinalité : une personne peut être l’auteur de 0 à n livre, mais un livre ne peut être écrit que par une personne (cf. figure 2.5).
Ainsi, si une cardinalité maximale est connue et vaut 2, 3 ou plus, alors nous considérons qu’elle est indéterminée et vaut n. En effet, si nous connaissons n au moment de la conception, il se peut que cette valeur évolue au cours du temps. Il vaut donc mieux considérer n comme inconnue dès le départ. De la même manière, on ne modélise pas des cardinalités minimales qui valent plus de 1 car ces valeurs sont également susceptibles d’évoluer. Enfin, une cardinalité maximale de 0 n’a pas de sens car elle rendrait le type-association inutile.
Les seuls cardinalités admises sont donc :
Une cardinalité minimale de 1 doit se justifier par le fait que les entités du type-entité en questions ont besoin de l’association pour exister. Dans tous les autres cas, la cardinalité minimale vaut 0. Ceci dit, la discussion autour d’une cardinalité minimale de 0 ou de 1 n’est intéressante que lorsque la cardinalité maximale est 1. En effet, nous verrons que, lors de la traduction vers un schéma relationnel (cf. section 3.1.3), lorsque la cardinalité maximale est n, nous ne ferons pas la différence entre une cardinalité minimale de 0 ou de 1.
La seule difficulté pour établir correctement les cardinalités est de se poser les question dans le bon sens. Pour augmenter le risque d’erreurs, il faut noter que, pour les habitués, ou les futurs habitués, du modèle UML, les cardinalités d’un type-association sont « à l’envers » (par référence à UML) pour les type-associations binaires et « à l’endroit » pour les n-aires avec n>2.
La notion de cardinalité n’est pas définie de la même manière dans le modèle Américain et dans le modèle Européen (Merise). Dans le premier n’existe que la notion de cardinalité maximale.
Avec un SGBD relationnel, nous pourrons contraindre des cardinalités à des valeurs comme 2, 3 ou plus en utilisant des déclencheurs (trigger, cf. section ??).
