Modèle entité-relation

Un article de Wikipédia, l'encyclopédie libre.

Pour les articles homonymes, voir ERD.

Le modèle entité-relation, ou diagramme entité-relation ou entity relationship diagram en anglais (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 entité-relation. 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 de 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 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 (appelé habituellement modèle logique), 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.

Sommaire

[modifier] Principe du modèle

Au niveau conceptuel, le modèle entité-relation distingue les objets et les relations :

  • Les objets de gestion sont par exemple : une commande, une livraison, une facture, ...
  • Les relations entre les objets sont par exemple : une commande porte sur plusieurs produits.

Les objets sont représentés par des rectangles, les relations par des ellipses ou des losanges. Les entités, objets ou relations, 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é/relation. 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.

[modifier] Utilisation du modèle

Le modèle entité/relation 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é-relation, 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.

[modifier] Données et traitements

Le modèle entité-relation 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 :

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

Icône de détail Article connexe : méta-modèle d’urbanisme.

Le modèle entité-relation 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).

A 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é-relation 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).

[modifier] Liens internes

Sur les données :

Sur les traitements :

Sur l'urbanisation :