Une entité peut être définie comme une chose capable d’une existence indépendante qui peut être identifiée de façon unique. Une entité est une abstraction des complexités d’un domaine. Lorsque nous parlons d’une entité, nous parlons normalement d’un aspect du monde réel qui peut être distingué des autres aspects du monde réel.
Une entité est une chose qui existe physiquement ou logiquement. Une entité peut être un objet physique tel qu’une maison ou une voiture (ils existent physiquement), un événement tel qu’une vente de maison ou un service de voiture, ou un concept tel qu’une transaction ou une commande de client (ils existent logiquement – en tant que concept). Bien que le terme d’entité soit le plus couramment utilisé, il convient de faire la distinction, après Chen, entre une entité et un type d’entité. Un type d’entité est une catégorie. Une entité, au sens strict, est une instance d’un type d’entité donné. Il existe généralement de nombreuses instances d’un type d’entité. Le terme entité-type étant quelque peu encombrant, la plupart des gens ont tendance à utiliser le terme entité comme synonyme de ce terme
Les entités peuvent être considérées comme des noms. Exemples : un ordinateur, un employé, une chanson, un théorème mathématique, etc.
Une relation capture la façon dont les entités sont liées les unes aux autres. Les relations peuvent être considérées comme des verbes, reliant deux ou plusieurs noms. Exemples : une relation de propriétaire entre une entreprise et un ordinateur, une relation de superviseur entre un employé et un département, une relation d’interprète entre un artiste et une chanson, une relation de preuve entre un mathématicien et une conjecture, etc.
L’aspect linguistique du modèle décrit ci-dessus est utilisé dans le langage déclaratif de requête de base de données ERROL, qui imite les constructions du langage naturel. La sémantique et l’implémentation d’ERROL sont basées sur l’algèbre relationnelle remodelée (RRA), une algèbre relationnelle qui est adaptée au modèle entité-relation et qui capture son aspect linguistique.
Les entités et les relations peuvent toutes deux avoir des attributs. Exemples : une entité employé peut avoir un attribut numéro de sécurité sociale (SSN), tandis qu’une relation prouvée peut avoir un attribut date.
Toutes les entités, à l’exception des entités faibles, doivent avoir un ensemble minimal d’attributs d’identification unique qui peuvent être utilisés comme clé unique/primaire.
Les diagrammes entité-relation ne montrent pas d’entités uniques ou d’instances uniques de relations. Ils montrent plutôt des ensembles d’entités (toutes les entités du même type d’entité) et des ensembles de relations (toutes les relations du même type de relation). Exemples : une chanson particulière est une entité ; la collection de toutes les chansons dans une base de données est un ensemble d’entités ; la relation entre un enfant et son déjeuner est une relation unique ; l’ensemble de toutes les relations enfant-repas dans une base de données est un ensemble de relations.En d’autres termes, un ensemble de relations correspond à une relation en mathématiques, tandis qu’une relation correspond à un membre de la relation.
Certaines contraintes de cardinalité sur les ensembles de relations peuvent également être indiquées.
Mappage du langage naturelModification
Chen a proposé les « règles empiriques » suivantes pour le mappage des descriptions en langage naturel en diagrammes ER : » L’anglais, le chinois et les diagrammes ER » par Peter Chen.
| Structure grammaticale anglaise | Structure ER |
|---|---|
| Common nom commun | Type d’entité |
| Nom propre | Entité |
| Verbe transitif | Type de relation |
| Verbe intransitif | Type d’attribut |
| Adjectif | Attribut pour entité |
| Adverbe | Attribut pour relation |
La vue physique montre comment les données sont réellement stockées.
Relations, rôles et cardinalitésModification
Dans l’article original de Chen, il donne un exemple de relation et de ses rôles. Il décrit une relation « mariage » et ses deux rôles « mari » et « femme ».
Une personne joue le rôle de mari dans un mariage (relation) et une autre personne joue le rôle de femme dans le (même) mariage. Ces mots sont des noms. Ce n’est pas une surprise ; nommer les choses nécessite un nom.
La terminologie de Chen a également été appliquée à des idées antérieures. Les lignes, les flèches et les pattes d’oie de certains diagrammes doivent plus aux anciens diagrammes de Bachman qu’aux diagrammes de relations de Chen.
Une autre extension courante du modèle de Chen consiste à « nommer » les relations et les rôles sous forme de verbes ou de phrases.
Nommer les rôlesModifier
Il est également devenu courant de nommer les rôles avec des phrases telles que est le propriétaire de et est possédé par. Les substantifs corrects dans ce cas sont propriétaire et possession. Ainsi, personne joue le rôle de propriétaire et voiture joue le rôle de possession plutôt que personne joue le rôle de, est le propriétaire de, etc.
L’utilisation de substantifs a un avantage direct lors de la génération d’implémentations physiques à partir de modèles sémantiques. Lorsqu’une personne a deux relations avec la voiture, alors il est possible de générer des noms tels que propriétaire_personne et conducteur_personne, qui sont immédiatement significatifs.
CardinalitésEdit
Les modifications de la spécification originale peuvent être bénéfiques. Chen a décrit les cardinalités de look-across. En passant, la notation Barker-Ellis, utilisée dans Oracle Designer, utilise same-side pour la cardinalité minimale (analogue à l’optionnalité) et le rôle, mais look-across pour la cardinalité maximale (la patte d’oie).
Dans Merise, Elmasri & Navathe et d’autres, il y a une préférence pour same-side pour les rôles et les cardinalités minimales et maximales. Des chercheurs récents (Feinerer, Dullea et al.) ont montré que cela est plus cohérent lorsqu’on l’applique à des relations n-aires d’ordre supérieur à 2.
Dans Dullea et al. on lit « Une notation ‘look across’ telle qu’utilisée dans l’UML ne représente pas efficacement la sémantique des contraintes de participation imposées aux relations où le degré est supérieur à binaire. »
Dans Feinerer on lit « Des problèmes surgissent si nous opérons sous la sémantique ‘look-across’ telle qu’utilisée pour les associations UML. Hartmann étudie cette situation et montre comment et pourquoi différentes transformations échouent. » (Bien que la « réduction » mentionnée soit fallacieuse car les deux diagrammes 3.4 et 3.5 sont en fait les mêmes) et aussi « Comme nous le verrons dans les prochaines pages, l’interprétation look-across introduit plusieurs difficultés qui empêchent l’extension de mécanismes simples des associations binaires aux associations n-aires. »
La notation de Chen pour la modélisation entité-relation utilise des rectangles pour représenter les ensembles d’entités, et des diamants pour représenter les relations appropriées aux objets de première classe : ils peuvent avoir des attributs et des relations qui leur sont propres. Si un ensemble d’entités participe à un ensemble de relations, ils sont reliés par une ligne.
Les attributs sont dessinés comme des ovales et sont reliés par une ligne à exactement une entité ou un ensemble de relations.
Les contraintes de cardinalité sont exprimées comme suit :
- une double ligne indique une contrainte de participation, la totalité ou la surjectivité : toutes les entités de l’ensemble d’entités doivent participer à au moins une relation dans l’ensemble de relations ;
- une flèche de l’ensemble d’entités à l’ensemble de relations indique une contrainte de clé, c’est-à-dire l’injectivité.c’est-à-dire l’injectivité : chaque entité de l’ensemble d’entités peut participer à au plus une relation dans l’ensemble de relations;
- une ligne épaisse indique les deux, c’est-à-dire la bijectivité : chaque entité de l’ensemble d’entités est impliquée dans exactement une relation.
- un nom souligné d’un attribut indique qu’il s’agit d’une clé : deux entités ou relations différentes ayant cet attribut ont toujours des valeurs différentes pour cet attribut.
Les attributs sont souvent omis car ils peuvent encombrer un diagramme ; d’autres techniques de diagramme listent souvent les attributs des entités dans les rectangles dessinés pour les ensembles d’entités.
Des techniques de convention de diagramme connexes :
- Notation Bachman
- Notation de Barker
- EXPRESS
- IDEF1X
- Notation de la patte de moineau (également notation Martin)
- Notation (min, max)-notation de Jean-Raymond Abrial en 1974
- Diagrammes de classes UML
- Merise
- Modélisation objet-rôle
Notation de la patte d’oieModification
Notation de la patte d’oie, dont le début remonte à un article de Gordon Everest (1976), est utilisée dans la notation de Barker, la méthode d’analyse et de conception de systèmes structurés (SSADM) et l’ingénierie informatique. Les diagrammes en patte d’oie représentent les entités sous forme de boîtes, et les relations sous forme de lignes entre les boîtes. Des formes différentes aux extrémités de ces lignes représentent la cardinalité relative de la relation.
La notation du pied de corbeau était utilisée dans le cabinet de conseil CACI. De nombreux consultants de CACI (dont Richard Barker) ont ensuite rejoint Oracle UK, où ils ont développé les premières versions des outils CASE d’Oracle, introduisant la notation à un public plus large.
Avec cette notation, les relations ne peuvent pas avoir d’attributs. Lorsque cela est nécessaire, les relations sont promues au rang d’entités à part entière : par exemple, s’il est nécessaire de capturer où et quand un artiste a interprété une chanson, une nouvelle entité « performance » est introduite (avec des attributs reflétant le temps et le lieu), et la relation d’un artiste à une chanson devient une relation indirecte via la performance (artist-performs-performance, performance-features-song).
Trois symboles sont utilisés pour représenter la cardinalité :
- l’anneau représente « zéro »
- le tiret représente « un »
- la patte d’oie représente « beaucoup » ou « infini »
Ces symboles sont utilisés par paires pour représenter les quatre types de cardinalité qu’une entité peut avoir dans une relation. La composante intérieure de la notation représente le minimum, et la composante extérieure représente le maximum.
- anneau et tiret → minimum zéro, maximum un (facultatif)
- timbre et tiret → minimum un, maximum un (obligatoire)
- anneau et patte d’oie → minimum zéro, maximum plusieurs (facultatif)
- traite et patte d’oie → minimum un, maximum plusieurs (obligatoire)
Problèmes d’utilisabilité du modèleModifier
Lors de l’utilisation d’une base de données modélisée, les utilisateurs peuvent rencontrer deux problèmes bien connus où les résultats retournés signifient autre chose que les résultats supposés par l’auteur de la requête.
Le premier est le ‘fan trap’. Il se produit avec une table (maître) qui est liée à plusieurs tables dans une relation un à plusieurs. Le problème tire son nom de la façon dont le modèle se présente lorsqu’il est dessiné dans un diagramme entité-relation : les tables liées se » déploient en éventail » à partir de la table maître. Ce type de modèle ressemble à un schéma en étoile, un type de modèle utilisé dans les entrepôts de données. Lorsque vous essayez de calculer des sommes sur des agrégats en utilisant le SQL standard sur la table principale, des résultats inattendus (et incorrects) peuvent apparaître. La solution consiste à ajuster soit le modèle, soit le SQL. Ce problème se produit surtout dans les bases de données pour les systèmes d’aide à la décision, et les logiciels qui interrogent ces systèmes incluent parfois des méthodes spécifiques pour gérer ce problème.
Le deuxième problème est un « chasm trap ». Un piège à gouffre se produit lorsqu’un modèle suggère l’existence d’une relation entre des types d’entités, mais que la voie n’existe pas entre certaines occurrences d’entités. Par exemple, un bâtiment possède une ou plusieurs pièces, qui contiennent zéro ou plusieurs ordinateurs. On pourrait s’attendre à pouvoir interroger le modèle pour voir tous les ordinateurs du bâtiment. Cependant, les ordinateurs qui ne sont pas actuellement affectés à une salle (parce qu’ils sont en réparation ou ailleurs) n’apparaissent pas dans la liste. Une autre relation entre Bâtiment et Ordinateurs est nécessaire pour capturer tous les ordinateurs du bâtiment. Ce dernier problème de modélisation est le résultat d’une incapacité à capturer dans le modèle toutes les relations qui existent dans le monde réel. Voir la modélisation Entité-Relation 2 pour plus de détails.