Modèle de diagramme Entité-Relation (ER) avec exemple de SGBD
Fiona Brun
⚡ Résumé intelligent
Exemple de diagramme entité-relation (ER) avec un SGBD Cette figure illustre une méthode structurée de représentation visuelle des données et de leurs interconnexions au sein des bases de données relationnelles. Proposée par Peter Chen, elle fournit un cadre de modélisation conceptuelle permettant de définir précisément les entités, les attributs, les relations et leurs cardinalités.
Qu'est-ce qu'un diagramme ER ?
Le diagramme entité-association (EA) est un outil visuel puissant pour la conception de structures de bases de données relationnelles. Proposé initialement par Peter Chen en 1976, il offre un cadre de modélisation conceptuelle qui définit avec précision les entités, les attributs, les relations et leurs cardinalités. Ce tutoriel aborde tous les aspects, des concepts de base aux techniques avancées, pour vous aider à maîtriser la conception de schémas de bases de données.
Les diagrammes ER contiennent différents symboles qui utilisent des rectangles pour représenter les entités, des ovales pour définir les attributs et des losanges pour représenter les relations.
À première vue, un diagramme ER ressemble beaucoup à un organigramme. Cependant, un diagramme ER comprend de nombreux symboles spécialisés, et sa signification le rend unique. L'objectif d'un diagramme ER est de représenter l'infrastructure du cadre d'entités.
Histoire des modèles ER
En 1976, Peter Chen a proposé le diagramme ER dans son article fondateur intitulé « Le modèle entité-relation : vers une vision unifiée des données ». Son objectif était de créer une convention uniforme applicable aussi bien aux bases de données relationnelles qu'aux réseaux. Chen envisageait le modèle ER comme une approche de modélisation conceptuelle permettant de combler le fossé entre les exigences du monde réel et l'implémentation technique des bases de données.
Depuis, le modèle ER a évolué avec différents systèmes de notation, notamment la notation de Chen (l'originale), la notation Crow's Foot (courante dans les outils modernes) et les approches basées sur UML. Malgré ces variations, les concepts fondamentaux restent les mêmes dans toutes les implémentations.
Pourquoi utiliser des diagrammes ER ?
Les diagrammes ER offrent de nombreux avantages pour la conception et le développement de bases de données :
- Communication visuelle: Elles offrent une représentation visuelle claire que les parties prenantes, qu'elles soient techniques ou non, peuvent comprendre.
- Plan directeur pour le développement : Ils indiquent précisément comment les tables doivent être connectées et quels champs chaque table contiendra.
- Prêt pour la traduction: Les diagrammes ER peuvent être directement traduits en tables relationnelles, ce qui vous permet de créer rapidement des bases de données.
- Prévention des erreurs: Ils permettent d'identifier les défauts de conception et les redondances avant la mise en œuvre, ce qui permet de gagner du temps et des ressources.
- Documentation: Elles constituent une documentation durable qui aide les nouveaux membres de l'équipe à comprendre l'architecture du système.
- L'analyse du système: Ils permettent d'identifier toutes les entités présentes dans un système et les relations qui les unissent.
Composants du diagramme ER
Tout diagramme entité-relation (ER) est construit à partir de trois composants essentiels : les entités, les attributs et les relations. Comprendre chaque composant et leurs interactions est fondamental pour concevoir des bases de données efficaces.
Exemples de diagramme ER
Par exemple, dans une base de données universitaire, on peut avoir des entités pour les étudiants, les cours et les enseignants. Une entité étudiant peut avoir des attributs comme le numéro d'inscription, le nom et l'identifiant du département. Les étudiants peuvent avoir des relations avec les cours et les enseignants.
Entités
Une entité représente tout objet du monde réel — vivant ou non — clairement identifiable et pour lequel des données peuvent être stockées. Il peut s'agir d'un objet physique, d'une information relative à l'entreprise ou d'un événement survenant dans le monde réel. Les entités peuvent inclure des personnes, des lieux, des objets, des événements ou des concepts.
Exemples d'entités par catégorie :
- Personne: Employé, étudiant, patient, client
- Lieu: Magasin, bâtiment, bureau, entrepôt
- Objet: Machine, Produit, Voiture, Livre
- Event: Vente, immatriculation, renouvellement, transaction
- Concept: Compte, Cours, Département, Projet
Ensemble d'entités
Un ensemble d'entités est un groupe d'entités similaires partageant des attributs communs. Par exemple, tous les étudiants d'une université forment un ensemble d'entités « Étudiant ». Dans les diagrammes entité-relation, les entités sont représentées par des rectangles contenant leur nom.
Les entités sont représentées par leurs propriétés, également appelées attributs. Chaque attribut possède des valeurs distinctes. Par exemple, une entité « étudiant » peut avoir pour attributs un nom, un âge et une classe.
Entités fortes contre entités faibles
Les entités sont classées comme fortes ou faibles selon leur capacité à exister indépendamment. Comprendre cette distinction est essentiel pour une conception de base de données adéquate.
Une entité forte possède sa propre clé primaire et peut exister indépendamment. Par exemple, une entité « Étudiant » peut être identifiée de manière unique par son identifiant étudiant (Student_ID) sans dépendre d'aucune autre entité.
Une entité faible ne possède pas de clé primaire propre et dépend d'une entité forte (appelée entité propriétaire) pour son identification. Elle utilise une clé partielle (discriminateur) combinée à la clé primaire de l'entité propriétaire pour garantir son unicité. Par exemple, dans un système bancaire, une entité « Transaction » dépend d'une entité « Compte » : le numéro de transaction seul n'est pas unique dans toute la base de données, mais combiné au numéro de compte, il le devient.
| Entité forte | Entité faible |
|---|---|
| Possède sa propre clé primaire | Ne possède pas de clé primaire ; utilise une clé partielle |
| Représenté par un seul rectangle | Représenté par un double rectangle |
| La clé primaire est soulignée d'un trait plein. | La partie de la légende est soulignée en pointillés. |
| Peut exister indépendamment | Son existence dépend de l'entité propriétaire. |
| Lié à une relation de diamant unique | Relié par un double diamant (relation d'identification) |
| Exemple : étudiant, employé, produit | Exemple : Transaction, Dépendant, Article_de_commande |
Lien familial
Une relation représente une association entre deux ou plusieurs entités. Les relations sont généralement identifiées par des verbes ou des groupes verbaux qui décrivent comment les entités interagissent entre elles. Dans les diagrammes ER, les relations sont représentées par des losanges. Exemple : Tom travaille au département de chimie.
Les entités participent à des relations. Nous pouvons souvent identifier des relations avec des verbes ou des phrases verbales.
Exemples :
- Vous assistez à cette conférence
- je donne la conférence
- Un étudiant assiste à un cours
- Un conférencier donne une conférence
Attributs
Un attribut est une propriété ou une caractéristique qui décrit une entité ou une relation. Les attributs fournissent les informations détaillées qui rendent chaque instance d'entité unique et significative. Dans les diagrammes entité-relation, les attributs sont représentés par des ovales (ellipses) reliés à leur entité parente par une ligne.
Par exemple, une entité Étudiant peut avoir des attributs tels que Student_ID, Name, Date_of_Birth, Email et Phone_Number.
Types d'attributs
| Type d'attribut | Description | Exemple |
|---|---|---|
| Simple (Atomje) | Ne peut être divisé en composants plus petits | Numéro de téléphone, numéro de sécurité sociale, courriel |
| Obturation En | Peut être décomposé en sous-attributs plus petits | Nom complet (Prénom, Deuxième prénom, Nom de famille), Adresse (Rue, Ville, Code postal) |
| Dérivé | La valeur est calculée à partir d'autres attributs ; elle n'est pas stockée directement. | Âge (calculé à partir de la date de naissance), Prix total |
| Multivalué | Peut contenir plusieurs valeurs pour une seule entité | Numéro de téléphone NumbersAdresses e-mail, compétences |
| Attribut clé | Identifie de manière unique chaque instance d'entité (clé primaire) | Numéro d'étudiant, numéro d'employé, ISBN |
Conseil clé: Dans les diagrammes ER, les attributs clés sont représentés par un nom souligné. Les attributs dérivés sont représentés par des ovales en pointillés, et les attributs multivalués par des doubles ovales.
Cardinalité (Types de relations)
La cardinalité définit les contraintes numériques d'une relation, c'est-à-dire le nombre d'instances d'une entité pouvant être associées à des instances d'une autre entité. Comprendre la cardinalité est essentiel pour concevoir des structures de bases de données efficaces.
1. Un à un (1:1)
Une entité de l'ensemble A peut être associée à au plus une entité de l'ensemble B, et vice versa.
Exemple : Chaque étudiant se voit attribuer un seul identifiant, et chaque identifiant appartient à un seul étudiant.
2. Un-à-plusieurs (1:N)
Une entité de l'ensemble A peut être associée à plusieurs entités de l'ensemble B, mais chaque entité de B n'est associée qu'à une seule entité de A.
Exemple : Une classe est composée de plusieurs élèves.
3. Plusieurs-à-Un (N:1)
Plusieurs entités de l'ensemble A peuvent être associées à une seule entité de l'ensemble B.
Par exemple, plusieurs élèves appartiennent à la même classe.
4. Relation plusieurs-à-plusieurs (M:N)
Plusieurs entités de l'ensemble A peuvent être associées à plusieurs entités de l'ensemble B, et vice versa.
Par exemple, les étudiants en tant que groupe sont associés à plusieurs membres du corps enseignant, et les membres du corps enseignant peuvent être associés à plusieurs étudiants.
Symboles et notations des diagrammes ER
Les diagrammes ER utilisent des symboles normalisés pour représenter différents composants. Parmi les nombreux systèmes de notation existants, les deux plus répandus sont la notation de Chen et la notation en pattes de corbeau.
Notation de Chen
La notation Chen, développée par Peter Chen en 1976, utilise des formes géométriques pour représenter différents éléments :
| Symbole | Nom | représentent |
|---|---|---|
| Rectangle Réf | Entité | Entité forte (ex. : étudiant, produit) |
| Double Rectangle Réf | Entité faible | Entité dépendante d'une autre (ex. : transaction) |
| Ellipse/Oval | Attribut | Propriété d'une entité (ex. : nom, identifiant) |
| Double Ellipse | Attribut multivalué | Attribut à valeurs multiples (ex. : Téléphone) Numbers) |
| Ellipse en pointillés | Attribut dérivé | Valeur calculée (ex. : âge à partir de la date de naissance) |
| Diamond | Lien familial | Association entre entités (ex. : Inscriptions) |
| Double Diamond | Identification de la relation | Relation avec une entité faible |
| Ligne | Lien | Permet de relier les composants entre eux. |
| Texte souligné | Clé primaire | Identifiant unique de l'entité |
Notation en pattes de corbeau
La notation en pattes de corbeau (également appelée notation IE) est plus couramment utilisée dans les outils modernes de conception de bases de données. Elle utilise différentes fins de ligne pour représenter la cardinalité et est particulièrement efficace pour indiquer le côté « plusieurs » des relations.
| Symbole Description CMS | Sens |
|---|---|
| Ligne verticale simple (|) | Obligatoire (un seul) |
| Cercle avec ligne (O|) | Optionnel Un (zéro ou un) |
| Patte de corbeau avec ligne (>|) | Obligatoire Plusieurs (un ou plusieurs) |
| Patte de corbeau avec cercle (>O) | Facultatif Plusieurs (zéro ou plus) |
Notation de Chen vs. notation patte de corbeau : quand utiliser l’une ou l’autre ?
| Aspect | Notation de Chen | Notation en pattes de corbeau |
|---|---|---|
| Meilleur pour | Modélisation conceptuelle, utilisation académique | Modélisation physique/logique, usage industriel |
| Affichage des attributs | Affiche visuellement tous les attributs | Liste les attributs à l'intérieur de la boîte d'entité |
| Cardinalité | Utilise les nombres (1, N, M) | Utilise des symboles visuels |
| Complexité | Peut devenir encombré | Plus compact et plus propre |
| Support d'outils | Support limité des outils modernes | Largement pris en charge par les outils |
Comment créer un diagramme de relation d'entité (ERD)
Dans ce tutoriel sur les diagrammes entité-association (ERD), nous allons apprendre à créer un diagramme ER. Voici les étapes à suivre :
Étudions-les avec un exemple de diagramme de relation d'entité :
À l'université, un étudiant s'inscrit à des cours. Chaque étudiant doit être inscrit à au moins un cours. Chaque cours est enseigné par un seul professeur. Afin de garantir la qualité de l'enseignement, un professeur ne peut dispenser qu'un seul cours.
Étape 1) Identification de l'entité
Nous avons trois entités :
- Étudiant·e
- Course
- Professeur
Étape 2) Identification de la relation
Nous avons les deux relations suivantes :
- L'étudiant est attribué un cours
- Le professeur offre un cours
Étape 3) Identification de la cardinalité
D'après l'énoncé du problème, nous savons que :
- Un étudiant peut être affecté plusieurs cours
- Un professeur ne peut délivrer que UN cours
Étape 4) Identifier les attributs
Il vous faut étudier les fichiers, formulaires, rapports et données actuellement conservés par l'organisation afin d'identifier les attributs. Vous pouvez également mener des entretiens avec différentes parties prenantes pour identifier les entités. Dans un premier temps, il est important d'identifier les attributs sans les associer à une entité particulière.
Une fois votre liste d'attributs établie, vous devez les associer aux entités identifiées. Veillez à ce qu'un attribut soit associé à une seule entité. Si vous pensez qu'un attribut devrait appartenir à plusieurs entités, utilisez un modificateur pour le rendre unique.
Une fois le mappage effectué, identifiez les clés primaires. Si une clé unique n’est pas facilement disponible, créez-en une.
| Entité | Clé primaire | Attribut |
|---|---|---|
| Étudiant·e | Carte d'étudiant | Nom d'étudiant |
| Professeur | ID_employé | Nom du professeur |
| Course | ID_cours | Nom du cours |
Pour l'entité Cours, les attributs pourraient être la durée, les crédits, les devoirs, etc. Par souci de simplicité, nous n'avons considéré qu'un seul attribut.
Étape 5) Créer le diagramme ER
Exemple de représentation plus moderne d'un diagramme entité-relation :
Meilleures pratiques pour des diagrammes ER efficaces
Suivez ces directives pour créer des diagrammes ER clairs, maintenables et efficaces :
- Éliminer la redondance : Supprimez les entités, attributs ou relations en double.
- Utilisez des conventions de dénomination claires : Utilisez des noms cohérents et descriptifs. Évitez les abréviations.
- Valider par rapport aux exigences : Assurez-vous que le schéma prenne en charge tous les besoins de stockage de données.
- Rester simple: Créez plusieurs diagrammes à différents niveaux plutôt qu'un seul diagramme surchargé.
- Utilisez la couleur avec parcimonie : Utilisez les couleurs de manière cohérente pour mettre en évidence les catégories.
- Hypothèses relatives au document : Inclure des notes expliquant les hypothèses relatives aux règles métier.
- RevVision avec les parties prenantes : Faites examiner le diagramme par les utilisateurs métiers et l'équipe technique.
- Contrôle de version: Maintenir à jour les versions au fur et à mesure de l'évolution de la conception.
Diagrammes ER vs. Diagrammes de classes UML
Bien que les diagrammes ER et les diagrammes de classes UML soient tous deux utilisés pour la modélisation des données, ils répondent à des objectifs et s'inscrivent dans des contextes différents. Il est donc important de savoir quand utiliser l'un ou l'autre pour concevoir efficacement un système.
| Aspect | Diagramme ER | Diagramme de classes UML |
|---|---|---|
| Objectif principal | Conception de base de données | Conception logicielle/objet |
| Focus | Données et relations | Objets, méthodes et comportements |
| Méthodes/Operations | Non pris en charge | Entièrement pris en charge |
| Droit des successions | Limité (uniquement en EER) | Plein soutien |
| Utilisation de l'industrie | Administrateurs de bases de données, analystes de données | Développeurs de logiciels, architectes |
