Modèle entité-association

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher
Page d'aide sur l'homonymie Pour les articles homonymes, voir ERD.
Un artiste peut jouer une chanson.

Le modèle entité-association (le terme « entité-relation » est une traduction erronée largement répandue), ou diagramme entité-association ou (en anglais « entity-relationship diagram », abrégé en ERD), est un modèle de données ou diagramme pour des descriptions de haut niveau de modèles conceptuels de données. Il fournit une description graphique pour représenter de tels modèles de données sous la forme de diagrammes contenant des entités et des associations. De tels modèles sont utilisés dans les phases amont de conception des systèmes informatiques.

Ils sont utilisés, par exemple, pour décrire les besoins en information et/ou le type d'information qui doit être enregistré dans les bases de données pendant la phase d'élaboration du cahier des charges. La technique de modélisation des données peut être utilisée pour décrire toute ontologie (i.e. une vue globale et des classifications des termes utilisés et de leurs relations) dans un domaine d'intérêt.

Dans le cas de la conception par la méthode Merise d'un système d'information construit sur une base de données, le modèle conceptuel de données est, à un stade ultérieur, transformé en modèle logique de données, tel que le modèle relationnel ; puis ce modèle est transformé en modèle physique pendant la phase de conception physique. Quelquefois, ces deux dernières phases sont appelées "conception physique".

Cette méthode est employée depuis les années 1970 pour concevoir les bases de données informatiques.

Principe du modèle[modifier | modifier le code]

Au niveau conceptuel, le modèle entité-association distingue les objets et leurs associations :

  • Les objets de gestion sont par exemple : une commande, une livraison, une facture, un produit...
  • Les associations entre les objets sont des liens tels que : "contient" entre l'objet "commande" et l'objet "produit".

Les objets sont représentés par des rectangles, les associations par des ellipses ou des losanges. Les entités, objets ou associations, ont des propriétés ou attributs.

Une commande peut contenir plusieurs (n) produits, et réciproquement un même produit peut appartenir à plusieurs (n) commandes.

Une relation (n, n) se traduit par un segment logique. On distingue donc les niveaux conceptuel et logique (ou organisationnel).

Pour la mise en œuvre, on a aussi un niveau physique, qui décrit les systèmes qui seront implantés (unité centrale, base de données, terminal,...).

La méthode MERISE, développée vers 1975 par les sociétés Sema-Metra et Compagnie Générale d'Informatique (CGI) utilise largement le modèle entité/association. La CGI a adjoint des modèles de développement informatiques.

Pour plus de détails techniques, voir aussi la page en anglais sur le modèle entité-association.

A la place des objets de gestion, on parle aujourd'hui des objets métier.

Utilisation du modèle[modifier | modifier le code]

Le modèle entité/association a été très employé pour l'automatisation des processus de gestion dans les années 1970 et 1980. Il est utile pour rationaliser les traitements administratifs : la comptabilité, la paye, la facturation, l'administration des ventes, les achats, le service client,...

Progressivement tous les domaines de gestion ont été gérés en utilisant ces modèles.

Dans les années 1990, la plupart des domaines de gestion étant déjà automatisés, l'enjeu était de remplacer ou d'adapter des systèmes de gestion devenus obsolescents. A 60 % environ dans les grandes entreprises, les applications spécifiques ont été remplacées par des progiciels de gestion intégrés.

Ces progiciels ont conservé le principe du modèle entité-association, d'une façon standardisée : les modèles souvent incohérents d'un domaine de gestion à un autre ont dû être harmonisés pour faire fonctionner les interfaces entre domaines.

Données et traitements[modifier | modifier le code]

Le modèle entité-association porte essentiellement sur les données de gestion.

Un système informatique nécessite de traiter des données, il y a donc deux aspects : données et traitements.

Les modèles (données et traitements) ont permis de réduire considérablement les coûts de gestion par automatisation des tâches.

Les modèles de traitements utilisés dans les méthodes d'analyse et de conception ont eu certains effets relativement négatifs :

Intégration dans un méta-modèle d’urbanisme[modifier | modifier le code]

Article connexe : méta-modèle d’urbanisme.

Le modèle entité-association a été conçu pour le développement des logiciels dans les années 1970, sur la base de modèles de communication assez simples utilisés pour les ordinateurs (au niveau matériel informatique).

À cette époque, les modèles tenaient très peu compte du contexte (voir communication et modèle de Claude Shannon, 1948). Les seules relations entre entreprises (à de rares exceptions près) s'effectuaient par l'intermédiaire des systèmes informatiques des sociétés financières.

La multiplication des flux d'information de l'entreprise avec ses partenaires (extranet), ainsi qu'avec ses parties prenantes (internet, messages électroniques), modifie en profondeur la perception de l'environnement, et révèle des transformations sociétales profondes avec la nécessité d'adapter les stratégies.

Si l'on continue d'utiliser les modèles (données et traitements) comme on l'a fait par le passé, d'une façon séquentielle, on risque de se trouver dépassé par rapport aux enjeux des projets complexes actuels, liés à l'innovation dans un monde rendu très ouvert et interactif par l'apparition des technologies web.

Le passage à des modèles de gestion orientés autour de processus métiers moins linéaires est devenu nécessaire, afin de rendre compte des interactions multi-métiers, multi-règles, et multi-domaines des entreprises modernes.

Un mode de pensée plus global par induction doit compléter le mode de pensée analytique par déduction.

Dans ce contexte, le modèle entité-association conserve tout son intérêt pour définir les structures de données et les ontologies qui sont à la base des interactions des processus les uns avec les autres.

Il s'agit d'intégrer les processus métier et les structures de données du système d'information dans un méta-modèle d’urbanisme (voir aussi diagrammes de classes UML), pour permettre l'interaction multi-métiers, multi-domaines, et multi-règles. Les processus physiques langages de modélisation des processus métier et les workflows doivent pouvoir utiliser les données dans des architectures orientées services (SOA).

Annexes[modifier | modifier le code]

Sur les autres projets Wikimedia :

Articles connexes[modifier | modifier le code]

Sur les données :

Sur les traitements :

Sur l'urbanisation :

Liens externes[modifier | modifier le code]