Le modèle Entité/Association est très répondu dans le domaine des Systèmes d'Information. Il permet de modéliser la partie statique (les données) d'un Système d'Information. Il est souvent utilisé comme un Modèle Conceptuel des Données (MCD) pour l'approche Merise.
Contrairement au diagramme de classes, le modèle Entité/Association se concentre sur les données seulement ce qui permet un passage plus précis et plus facile vers une base de données relationnelle au niveau physique.
Le modèle Entité/Association repose sur quatre notions de base :
1. Chaque entité doit avoir des propriétés. Elle doit avoir au moins une propriété qui sera la clé.
2. Une entité est une représentation d'un ensemble d'instances qui partagent les mêmes propriétés. Ainsi, l'entité Etudiant (le nom d'une entité doit être toujours au singulier) est une représentation de plusieurs instances (plusieurs personnes) qui ont le même rôle et qui partage les mêmes attributs dans un établissement d'enseignement. Ainsi, si nous avons des informations constantes (qui ne changent pas dans le temps) et uniques (absence de la notion d'instance), ces informations ne sont pas représentées dans le modèle Entité/Association. Par exemple, si nous avons une seule salle machine, il est évident que toutes les séances de TP seront organisées dans cette salle et il n'y a aucun besoin pour créer une entité Salle Machine, ni pour créer l'association Se Déroule A.
3. Le système ne doit pas figurer comme entité. Mettre le système étudié comme entité représente une grosse erreur qui falsifier complètement le modèle et cela est pour les raisons suivantes :
a. Il n'existe qu'un seul système, ainsi, la notion d'instance est absente.
b. Toutes les entités sont manipulées à l'intérieur du système et toutes les associations sont créées à l'intérieur du système. Si nous le mettons comme entité alors nous devons le lier à toutes les entités et à toutes les associations.
c. Les liaisons du point b ci-dessus, même créées, ne portent aucune information additionnelle. Nous savons déjà que toutes les entités et toutes associations existent à l'intérieur du système.
4. Le modèle doit être connexe, c'est à dire, nous ne devons pas avoir deux sous ensembles des entités S1 et S2 où quelques soit x de S1 et quelque soit y de S2 il n'y a aucune association entre x et y.
5. Il n'y a aucune condition sur le nombre des associations entre deux entités. Nous mettons autant que le système voit comme association entre les deux entités.
6. Il n'y a aucune condition sur les cardinalités aux deux côtés d'une association entre deux entités A et B sauf l'interdiction d'un couple particulier (1, 1) et (1, 1) ( (1, 1) dans les deux côtés de la même association). Ce couple veut dire que ne pouvons pas avoir une instance de A sans une instance de B comme nous ne pouvons pas avoir une instance de B sans une instance de A. Ainsi, nous nous trouvons dans une situation d'interblocage et nous ne pouvons pas créer ni des instances de A, ni des instances de B. Sur le plan conceptuel, ce couple de cardinalités veut dire que les deux instances existent ensembles, par conséquence, elles doivent être fusionnées pour éviter le problème.
Le modèle Entité/Association est très utile pour débuter en systèmes d'information. Comprendre les deux dimensions statique/dynamique du système et pourvoir les séparer sont très essentiel pour tout future concepteur des Systèmes d'Information.
Contrairement au diagramme de classes, le modèle Entité/Association se concentre sur les données seulement ce qui permet un passage plus précis et plus facile vers une base de données relationnelle au niveau physique.
Le modèle Entité/Association repose sur quatre notions de base :
- Entité : tout objet manipulé dans le système.
- Association : les liens entre les entités.
- Propriété : les attributs des entités et des associations.
- Cardinalité : l'aspect quantitatif d'une association.
1. Chaque entité doit avoir des propriétés. Elle doit avoir au moins une propriété qui sera la clé.
2. Une entité est une représentation d'un ensemble d'instances qui partagent les mêmes propriétés. Ainsi, l'entité Etudiant (le nom d'une entité doit être toujours au singulier) est une représentation de plusieurs instances (plusieurs personnes) qui ont le même rôle et qui partage les mêmes attributs dans un établissement d'enseignement. Ainsi, si nous avons des informations constantes (qui ne changent pas dans le temps) et uniques (absence de la notion d'instance), ces informations ne sont pas représentées dans le modèle Entité/Association. Par exemple, si nous avons une seule salle machine, il est évident que toutes les séances de TP seront organisées dans cette salle et il n'y a aucun besoin pour créer une entité Salle Machine, ni pour créer l'association Se Déroule A.
 |
| L'entité Salle Machine n'est pas nécessaire parce qu'il existe une seule Salle Machine |
3. Le système ne doit pas figurer comme entité. Mettre le système étudié comme entité représente une grosse erreur qui falsifier complètement le modèle et cela est pour les raisons suivantes :
a. Il n'existe qu'un seul système, ainsi, la notion d'instance est absente.
b. Toutes les entités sont manipulées à l'intérieur du système et toutes les associations sont créées à l'intérieur du système. Si nous le mettons comme entité alors nous devons le lier à toutes les entités et à toutes les associations.
c. Les liaisons du point b ci-dessus, même créées, ne portent aucune information additionnelle. Nous savons déjà que toutes les entités et toutes associations existent à l'intérieur du système.
4. Le modèle doit être connexe, c'est à dire, nous ne devons pas avoir deux sous ensembles des entités S1 et S2 où quelques soit x de S1 et quelque soit y de S2 il n'y a aucune association entre x et y.
5. Il n'y a aucune condition sur le nombre des associations entre deux entités. Nous mettons autant que le système voit comme association entre les deux entités.
6. Il n'y a aucune condition sur les cardinalités aux deux côtés d'une association entre deux entités A et B sauf l'interdiction d'un couple particulier (1, 1) et (1, 1) ( (1, 1) dans les deux côtés de la même association). Ce couple veut dire que ne pouvons pas avoir une instance de A sans une instance de B comme nous ne pouvons pas avoir une instance de B sans une instance de A. Ainsi, nous nous trouvons dans une situation d'interblocage et nous ne pouvons pas créer ni des instances de A, ni des instances de B. Sur le plan conceptuel, ce couple de cardinalités veut dire que les deux instances existent ensembles, par conséquence, elles doivent être fusionnées pour éviter le problème.
 | ||
| Cardinalités intérdites : (1, 1) et (1, 1) dans la même association. |
Le modèle Entité/Association est très utile pour débuter en systèmes d'information. Comprendre les deux dimensions statique/dynamique du système et pourvoir les séparer sont très essentiel pour tout future concepteur des Systèmes d'Information.
