Qu'est-ce qu'un diagramme entité-relation ?

Dans le modèle relationnel de la conception des bases de données, les ERD établissent la manière dont les entrées d’une base de données sont connectées. Les ERD sont un modèle conceptuel de données de haut niveau qui définit le cadre d'une conception et d'une analyse plus avancées de la base de données.

En outre, la modélisation des relations entre les entités peut aider à distiller des descriptions et des informations à partir d'une collection apparemment disparate de points de données.

Les analystes métier et les ingénieurs de bases de données utilisent des diagrammes ER comme outils de modélisation de données pour évaluer l’étendue des bases de données dont leur entreprise a besoin, puis planifier comment les données seront stockées.

Les ERD renseignent la partie ingénierie logicielle d'un projet de base de données en définissant les exigences relatives à l'architecture des systèmes d'information et à la structure de la base de données. Dans l’approche à trois schémas de l’ingénierie logicielle pour les systèmes de gestion de bases de données (SGBD), l’ERD est le niveau conceptuel.

L’intégration des données est un processus complexe d’ingénierie des données composé de nombreuses pièces mobiles. Un ERD peut aider les ingénieurs de données à conceptualiser l’ensemble du système et à réduire le risque d’erreurs.

En comparant les bases de données existantes à un ERD, il est possible d'identifier les erreurs de conception des bases de données qui pourraient poser problème. Les bases de données complexes comportant de nombreux tableaux nécessitent des connaissances approfondies de SQL pour le processus de débogage. Un ERD résume la base de données afin que les ingénieurs puissent rapidement identifier les erreurs potentielles.

Lors des projets de réingénierie des processus métier, il peut s’avérer utile d’obtenir une vue d’ensemble de toutes les données au sein des systèmes d’information. Les ERD permettent de rédiger des solutions d’architecture de données plus récentes et plus efficaces qui facilitent les autres étapes du processus BPR.

Les diagrammes de relations entre entités, les schémas de base de données et les diagrammes de flux de données représentent tous visuellement la manière dont les données sont organisées dans un système.

• Les diagrammes de relations entre entités illustrent les entités d’une base de données et les relations entre elles. Les diagrammes ER représentent souvent des schémas de base de données.

• Les schémas de base de données établissent la manière dont les entités du monde réel seront modélisées dans une base de données relationnelle. Ils contiennent les règles et les instructions qui déterminent l’organisation de la base de données, telles que les noms de tableaux, les champs et les types de données.

• Les diagrammes de flux de données sont des types d’organigramme qui représentent le flux de données à travers un processus ou un système. Ils montrent comment les données passent du processus aux emplacements de stockage internes et externes.

Les diagrammes de relations entre entités incluent les entités, les attributs de ces entités et les relations entre elles. Certains ERD transmettent également la cardinalité, qui quantifie la relation entre deux entités.

Une entité ERD est définissable, telle qu’une personne, un rôle, un événement, un concept ou un objet, et peut être stockée dans une base de données relationnelle. De nombreux styles de diagrammes de relations entre entités représentent les entités sous forme de rectangles.

• Personnes ou rôles : étudiants, commerciaux, cadres ou clients.
• Événements : transactions, inscriptions ou désabonnements.
• Concepts : profils ou personas.
• Objets : produits, factures ou e-mails.

Les entités sont similaires aux noms dans un sens grammatical. Il s’agit d’éléments essentiels de la base de données, dont les attributs et les relations fournissent des informations sur ces entités, tout comme les adjectifs et les verbes fournissent plus d’informations sur les noms d’une phrase.

Les types d’entités sont une categories d’entités. Si les entités sont similaires aux noms, les types d’entités sont des categories de noms : aliments, sports et pays. Les entités individuelles d’un type d’entité sont appelées instances. Dans le type d'entité, les légumes peuvent être le brocoli, la carotte et l'asperge.

Les entités sont classées comme fortes ou faibles. Les entités fortes contiennent suffisamment d'informations d'identification dans leurs attributs pour ne pas nécessiter de clarification supplémentaire. Quant aux entités faibles, elles n'existent qu'en tant que résultat ou conséquence d'une autre entité. L'entité forte associée à une entité faible donnée est appelée entité mère ou propriétaire.

Prenons l’exemple d’une base de données modélisant une commande client dans une entreprise d'e-commerce. Chaque commande est une entité forte, car elle peut être définie comme une instance unique en fonction de l’acheteur, de l’heure et de la date. Cependant, les postes au sein de chaque commande sont des entités faibles. Ils n’ont de signification que dans le contexte de leurs commandes respectives. Cette dépendance est connue sous le nom de dépendance d’existence ou de contrainte de participation.

Les entités fortes sont représentées sous la forme de rectangles solides, tandis que les ERD représentent les entités faibles sous la forme d’un double rectangle.

Une entité associative relie les instances entre deux ensembles d’entités et possède ses propres attributs, qui fournissent plus d’informations sur cette relation. Dans un ERD utilisé par une université, l'entité définit les étudiants et les professeurs comme ayant de nombreuses connexions entre eux. L’entité associative qui relie les deux montrerait quels étudiants suivent des cours enseignés par quels professeurs.

Les bases de données relationnelles utilisent des entités associatives pour informer les tableaux de jonction, qui combinent des champs provenant de plusieurs autres tableaux de la base de données. Dans les diagrammes ER, les entités associatives sont représentées par un losange dans un rectangle.

Les attributs sont des qualités, des propriétés et des caractéristiques qui définissent une entité ou un type d'entité. Dans une conception ERD classique, les attributs sont représentés par des ovales et figurent à côté de l'entité correspondante dans un ERD.

• Les attributs simples ne peuvent pas être simplifiés ni divisés en attributs supplémentaires. Un code postal est un exemple d’attribut simple.

• Les attributs composites sont compilés à partir d’autres attributs, qui peuvent ou non être simples. Une adresse est un attribut composite contenant un numéro de rue, un nom de rue, un code postal, une ville et d’autres informations d’identification.

• Les attributs dérivés sont calculés à partir d’autres attributs. La valeur du salaire d'un employé est dérivée de son nombre d'heures travaillées, de la période de paie et de son salaire. Les ERD représentent les attributs dérivés sous forme d’ovales en pointillés.

• Les attributs à valeurs multiples peuvent avoir plus d'une valeur par enregistrement, ce qui n'est pas le cas des attributs à valeur unique.

Les clés d’entité sont les attributs qui définissent de manière unique chaque entité dans un ensemble de données. Tout attribut peut être désigné comme clé, à condition qu’il remplisse ce rôle. Par exemple, dans un ensemble d’entités de personnes, un attribut clé approprié peut être un numéro d’identification national. À l’inverse, les noms de famille ne fonctionneraient pas comme attribut clé dans ce contexte, car plusieurs personnes peuvent partager le même nom de famille.

• Super clé : un ou plusieurs attributs permettant de définir une entité de manière unique au sein d’un ensemble d’entités.

• Clé candidate : la super clé la plus simple possible, aucun attribut d'une clé candidate ne peut être une super clé en soi. Les clés candidates peuvent être composées d'un ou de plusieurs attributs si chaque attribut n'est pas une super clé.

• Clé primaire : la clé candidat est choisie pour définir de manière unique un ensemble d’entités. Étant donné que la clé primaire est ce qui distingue chaque entité, deux entrées dans une base de données ne peuvent pas partager la même valeur de clé primaire. Dans un diagramme ER, la clé primaire de chaque entité sera soulignée. Toute entité contenant une clé primaire est considérée comme une entité forte. 

• Clé étrangère : un attribut qui identifie la relation entre une entité et une autre. Les entités faibles se basent sur des clés étrangères pour les définir comme des entités fortes. Par exemple, le compte bancaire de l’entité faible aurait besoin d’une clé étrangère le reliant à la banque concernée.

Les relations sont les lignes connectées qui relient les entités d’un ERD. Elles indiquent comment les entités d’un ERD sont associées les unes aux autres. Si les entités sont des noms et que les attributs sont des adjectifs, les relations sont des verbes.

Dans un ERD classique, les relations sont représentées par des losanges. Les relations faibles lient une entité faible à son propriétaire et sont représentées par des doubles losanges.

La participation des entités à une relation peut être totale, auquel cas la totalité de l'ensemble des entités est impliquée dans la relation, ou partielle. Dans le cas d'une participation partielle, une partie ou la totalité des entités de l'ensemble peuvent être impliquées dans la relation à un moment donné.

La cardinalité est la qualité d’une relation qui définit le nombre d’instances d’une entité qui se rapportent aux instances d’une autre.

• Les relations biunivoque (1:1) indiquent qu'un enregistrement d'une entité ne peut être référencé que par un seul enregistrement de l'autre entité. La relation entre les universités et les présidents des entités est une relation univoque car chaque université n'a qu'un seul président. Inversement, chaque président est responsable d'une seule université.

• Les relations un-à-plusieurs (1:M) décrivent des situations dans lesquelles chaque enregistrement au sein d’une entité est lié à plusieurs enregistrements dans une autre entité. Il existe une relation un-à-plusieurs entre les entités universités et départements. Une université peut avoir plusieurs départements, mais chaque département fait partie d’une seule université.

• Les relations plusieurs-à-plusieurs (M:M) démontrent qu’un ou plusieurs enregistrements au sein des deux entités peuvent être connectés. Les entités étudiantes et professeures ont une relation plusieurs-à-plusieurs car, tout comme un professeur enseigne un cours à de nombreux étudiants, chaque étudiant peut également s’inscrire à des cours avec d’autres professeurs.

Les ERD représentent la cardinalité par des variations dans les lignes de connexion entre les entités. La façon dont la cardinalité est représentée dépend du style d'ERD utilisé.

La plupart des ERD sont établis selon l'un des trois modèles entité-relation : conceptuel, logique et physique. Tous trois représentent des entités, ainsi que leurs attributs et leurs relations, mais leurs cas d’utilisation et leur public visé diffèrent. Les modèles conceptuels sont les moins détaillés, tandis que les ERD physiques offrent les informations les plus granulaires.

• Les modèles conceptuels ER offrent un aperçu détaillé des données contenues dans l'ERD. Les analystes métier les utilisent dans le cadre de projets de conception de bases de données à grande échelle, tels que les entrepôts de données. Les modèles de données conceptuels contiennent généralement des entités et des relations sans approfondir les tableaux et la cardinalité des bases de données.

• Les modèles ER logiques sont similaires aux modèles conceptuels, mais avec un peu plus de détails. Dans un modèle de données logique, les colonnes ou attributs de chaque entité sont définis, tout comme les entités opérationnelles et transactionnelles. Les analystes commerciaux utilisent des modèles de données logiques pour des projets de conception de bases de données à plus petite échelle.

• Les modèles ER physiques constituent les schémas directeurs concrets pour les projets de conception de bases de données. Elles incluent la quantité maximale de détails, comme la cardinalité et les clés primaires et étrangères. Les concepteurs de bases de données et les ingénieurs métier créent des modèles de données physiques à partir des modèles conceptuels et logiques qui leur sont fournis par les analystes métier.

Depuis que l’informaticien et théoricien des bases de données Peter Chen a introduit les ERD dans les années 1970, de multiples types de diagrammes sont apparus pour répondre à un éventail croissant de cas d’utilisation.

Les ERD Chen ressemblent à des organigrammes classiques, avec différentes formes reliées par des lignes. La cardinalité est montrée avec les caractères 1, M et N le long des lignes connectées. M et N représentent tous deux le « plusieurs » dans une relation un-à-plusieurs ou plusieurs-à-plusieurs ; la notation M:N ou N:M implique que le nombre d’entités dans la relation n’a pas besoin d’être égal des deux côtés.

Le style Chen représente la participation totale par une ligne de connexion simple et la participation partielle par une ligne de connexion double.

La notation crow’s foot, qui doit son nom à sa ligne de connexion à trois branches fourchues indiquant de nombreuses relations, remplace les symboles de Chen par des tableaux. Chaque tableau représente une entité et contient tous ses attributs. Elle permet aux créateurs d’ERD de faire figurer des informations sur la cardinalité des relations.

Les diagrammes de structure des données de Charles Bachman ont directement inspiré Chen lors de la création de l'ERD. Bachman a utilisé des lignes avec des flèches pour indiquer la cardinalité des relations.

L'armée de l'air américaine a introduit son langage IDEF1X (Integration DEFinition for information modeling) dans les années 1980 pour soutenir le développement de modèles de données sémantiques. Ce langage a fait progresser le travail de Chen en présentant les attributs dans un tableau partagé et en introduisant davantage d'options pour la cardinalité.

Créé par Richard Barker en 1981, le style Barker est la norme d’utilisation dans Oracle. La notation Barker partage le style de la notation crow’s foot pour relier les lignes tout en utilisant des lignes pointillées pour représenter une participation partielle ou facultative.