Entity-Relationship-Modell – Wikipedia

Le Modélisation de la relation entité – court Modèle ER ou Erm ; Allemand autant que: Modèle (pour afficher) des choses, des objets, des objets (= ‚Entités’) et les relations / relations entre ces (= ‚Relation’) – Pour déterminer et présenter l’extrait du monde réel pertinent dans un contexte donné (par exemple un projet pour créer un système d’information). Le modèle ER se compose essentiellement d’un graphique ( Er-diagramme , Abbey Earth) ainsi qu’une description des éléments qui y sont utilisés.

Un modèle ER sert à la fois dans la phase conceptuelle du développement d’applications de la communication entre les utilisateurs et les développeurs (seulement c’est Était traité, d. H. conditions techniques, pas que Comment , par exemple. B. La technologie) ainsi que dans la phase de mise en œuvre comme base de la conception de la base de données – principalement relationnelle.

L’utilisation des modèles ER est la norme de facto pour la modélisation des données, même s’il existe différentes formes graphiques de représentation pour les modèles de données.

Le modèle ER a été publié en 1976 par Peter Chen dans sa publication Le modèle de relation entité présenté. Les descriptions de généralisation et d’agrégation ont été introduites en 1977 par John M. Smith et Diane C. P. Smith. Après cela, il y a eu plusieurs autres développements, la fin des années 80 par Wong et Katz.

La base des modèles de hanche de relation d’entité est le typage des objets, leurs relations entre eux et les au propos de vous Pour mener des informations («Attributs»).

Composants de base [ Modifier | Modifier le texte source ]]

Dans les discussions, les exemples et les textes conceptuels, Objets et conditions du monde réel (dans le contexte d’une vision) référé; Ceux-ci sont mentionnés:

• Entité (entité): objet individuellement identifiable de la réalité; Z B. l’employé Müller, le projet 3232
• Relation (relation): lier / connexion entre deux ou plusieurs entités; Z B. employé Müller guidé Projet 3232.
• Propriété (attributs anglais): Était est intéressant une entité (en contexte); Z B. La date d’entrée du Miller employé.

Dans le cadre de la modélisation, les faits susmentionnés sont Types similaires formé et défini avec précision et décrit dans le modèle. Ces types diffèrent selon:

• Type d’entité: Typage des entités similaires z. B. Employé, projet, livre, auteur, éditeur
• Type de relation (type de relation): Taping de relations similaires; Z B. employé guidé Projet
• Attribut: typage de propriétés similaires, par ex. B. Nom, prénom et date d’entrée dans le type d’entité. L’attribut ou la combinaison d’attribut, par la valeur de la valeur de la valeur, c’est-à-dire H. Identifier celles-ci sont appelées attribut d’identification (e); Par exemple, le numéro de projet d’attribut dans le projet de type entité est un attribut d’identification.

Problèmes spéciaux [ Modifier | Modifier le texte source ]]

Pour décrire et présenter des faits spéciaux, la modélisation ER connaît les constructions suivantes:

• Type d’entité fort: l’identification d’une entité est possible par une ou plusieurs valeurs d’attributs du même type d’entité; Donc z. B. Identification du numéro de commande pour l’ordre de type d’entité.
• Type faible d’entité: Pour identifier une telle entité, une valeur d’attribut d’une autre avec l’entité faible par rapport à l’entité faible est requise; Donc z. B. Pour l’identification du type d’entité faible “salle” en plus du numéro de pièce mais également la spécification d’un bâtiment d’un autre “bâtiment” de type d’objet fort. Dans les extensions du modèle ER telles que le SERM, le type d’entité faible et le type de relation associé sont réunis pour former un soi-disant type ER, ce qui rend les diagrammes plus compacts.
• Cardinalité: La cardinité (au niveau du type de relation) détermine pour chacun des types d’entités impliqués dans le nombre de relations concrets (ce type) peut ou doit être impliquée. Diverses formes de notation ont été développées pour représenter la cardinalité, dont les outils de modélisation en soutiennent généralement un certain.
• Relation réflexive (auto-référence): relation entre les entités individuelles et le même type d’entité, donc un type de relation entre le même type d’entité (par exemple la structure des arbres d’une unité organisationnelle se divise en Unité organisationnelle »et la structure du réseau d’une liste de pièces par« partie est utilisé dans Partie”). Synonyme: relation récursive.
• Degré ou complexité d’un type de relation: nombre de types d’entités impliqués dans un type de relation. La règle est la 2e année (type de relation binaire); Rarement le degré 3 (type de relation ternaire) ou un degré plus élevé se produit. Les types de relations Ternar et supérieurs peuvent être attribués aux types de relations binaires en introduisant un nouveau type d’entité (qui correspond au type de relation d’origine). Exemple: Employé soutient le fournisseur (pour le groupe de produits) ; NOUVEAU TYPE ENTITY Soins aux fournisseurs Avec des relations avec les trois types d’entités originaux. Cependant, une telle procédure peut être perdue, c’est-à-dire Autrement dit, il existe des faits qui ne peuvent être représentés que par les types de relations multi-chiffres.
• Attributs de la relation: Habituellement, les types de relations n’ont pas d’attributs car ils ne combinent que les types d’entités impliqués. Cependant, si des attributs supplémentaires sont nécessaires, le type de relation – comme pour les relations de niveau supérieur – un type d’entité indépendant avec des types de relations avec les types d’entités à l’origine impliqués peut être créé. L’attribut est ensuite attribué au nouveau type d’entité (faible) (par exemple Diplôme de participation au projet Avec le type de relation L’employé travaille sur le projet ). Selon la méthodologie de modélisation utilisée, les relations «attribuées» peuvent également être formulées, mais la formation de nouveaux types d’entités est souvent pratiquée.

Le contenu des types de relations entre les types d’entités dans le diagramme ER ne s’exprime que par un texte court dans le diamant (principalement un verbe) ou comme lettrage du bord, qui est exempté du modélisateur, qui s’accorde. Il existe maintenant des relations avec une sémantique spéciale qui se produisent relativement souvent dans la modélisation. Par conséquent, des identifiants spéciaux et des symboles graphiques ont été définis pour ces types de relations. La spécialisation et la généralisation ainsi que l’agrégation et la décomposition sont des descriptions supplémentaires avec une sémantique spéciale. Avec ces deux types de relations spéciaux, les circonstances du monde réel peuvent être modélisées et présentées en conséquence et leur signification réelle. Avec des noms fermement définis et des symboles graphiques spéciaux, il est démontré que ce sont des relations sémantiquement présumées avec des règles spéciales.

Ces types d’entités et de relations, qui ne sont généralement spécialement modélisés dans les modèles de données sémantiques, peuvent être mis en œuvre de différentes manières de différentes manières, telles que (la modélisation identique) comme leurs propres tables ou dans des tables courantes avec les caractéristiques relationnelles spéciales ou les noms d’attribut. La décision de mise en œuvre est prise (comme la détermination de la cardinalité pour ces relations spéciales) dans les activités de la modélisation de la base de données.

Spécialisation et généralisation au moyen de est un -Relation [ Modifier | Modifier le texte source ]]

Dans le spécialisation Si un type d’entité est reconnu et déclaré comme sous-ensemble d’un autre type d’entité, par lequel la quantité spécialisée d’entité est caractérisée par des propriétés spéciales (seuls les attributs et / ou les relations qui leur sont applicables) à la quantité généralisée et généralisée. Puisqu’il s’agit d’un seul objet de la quantité spécialisée et de la quantité généralisée la même chose Un seul objet agit, toutes les propriétés – en particulier l’identification – et toutes les relations de l’objet individuel généralisé s’appliquent également à l’objet individuel spécialisé.

Les types de relations du type «spécialisation / généralisation» sont à travers est un / / peut être (“Est un” / “peut être un …”) décrit. Pour est un Sera aussi occasionnellement une sorte de (“Une sorte de …”) utilisé. Ce sont des relations 1: C.

Exemple pour est un -Relation:

Vol est un Voyage

Et dans une direction de lecture différente:

Voyage peut être Vol,

Avec des propriétés telles que les dates de voyage, le prix de voyage (lors des déplacements) et les relations avec le vol de type entité (sur le vol).

Celui décrit ici est un -Les relation (entre les objets individuels identiques) ne doivent pas avec le IS-Element-of -Les relation (l’appartenance d’un seul objet à un autre) peut être confuse, pour laquelle l’orthographe est un est utilisé, comme B. Vol IS-A volant (Ce qui serait mal d’être sémantiquement).

Pour la spécialisation, peut également être Plusieurs types d’entités spécialisées être déclaré. Il faut déterminer si les objets individuels du type d’entité généralisé peuvent être manquants dans les spécialisations et s’ils ne peuvent se produire alternativement que dans une quantité spécialisée d’entités ou dans plusieurs quantités d’entités spécialisées.
Exemple: le client est un client privé ou des études d’entreprise; L’une des relations doit être présente.

Alors que les spécialisations découlent de la formation d’un droit partiel des entités données, la Généralisation Propriétés et relations communes qui se produisent dans différents types d’entités combinées en un nouveau type d’entité. Donc B. Les clients et les fournisseurs sont réunis en plus des partenaires commerciaux, car le nom, l’adresse, les détails bancaires, etc. se produisent chez les clients et les fournisseurs.

Dans cet exemple, le type de généralisation qui en résulte provient du partenaire commercial et conduit aux deux types d’entités de clients et de fournisseurs. La cardinalité doit être déterminée si la relation ne peut se produire que dans des cas individuels concrètes pour les entités d’un seul des deux ou des deux types d’entités.

La distinction ci-dessus entre la spécialisation et la généralisation ne résulte que l’ordre dans lequel les types d’entités ont été identifiés lors de la modélisation; En conséquence, il existe toujours des types de relations qui sont une spécialisation dans une direction dans l’autre généralisation. Si nécessaire, pour le même type d’entité Plusieurs spécialisations / généralisations apparaître. Exemple: les employés peuvent être spécialisés dans la MA externe ou la maîtrise interne (disjoint) et en plus des “employés de premier plan”. Les types d’entités spécialisés peuvent également être spécialisés / généralisés à nouveau (suite, en cascade).

La représentation visuelle des spécialisations et des généralisations n’est pas prévue dans le diagramme Mer original, mais est en extensions telles que: B. utilisé par le serm.

Agrégation et décomposition au moyen de fait partie de -Relation [ Modifier | Modifier le texte source ]]

Si plusieurs objets individuels (par exemple, personne et hôtel) sont résumés en un objet individuel indépendant (par exemple, réservation), on parle d’agrégation.
L’unité entière indépendante globale est mentionnée; Les pièces à partir desquelles il est composée est appelée composants. Contregate et les composants sont déclarés comme un type d’entité.

Dans le cas de l’agrégation / décomposition, une distinction est faite entre le rôle et l’agrégation de quantité:

Une agrégation de rôles existe s’il existe plusieurs composantes spécifiques au rôle, qui sont résumées en un agrégat et c’est une relation 1: C.

Exemple pour fait partie de -Relation:

Équipe de football fait partie de Match de football et lieu fait partie de Jeu de football

Et dans une direction de lecture différente:

Jeu de football consiste Équipe de football et lieu.

Une agrégation de quantités existe si l’unité surgit exactement un composant en résumant des objets individuels. Voici une relation 1: CN.

Exemple de l’agrégation de quantité:

Joueur de football fait partie de Équipe de football

Et dans une direction de lecture différente:

Équipe de football consiste (plusieurs, n) joueurs de football.

Ère [ Modifier | Modifier le texte source ]]

La représentation graphique des types d’entités et de relations (représentative et dérivée par dactylographie dérivée des entités et des relations identifiées dans le contexte donné) Diagramme de la relation d’entité (Terre) ou Er-diagramme appelé. Il s’agit d’un aperçu / graphique sur toutes les entités pertinentes et leurs connexions, ce qui crée une structure complexe en forme de réseau, entre autres. Pour de très grands modèles, pour des raisons de clarté i. d. R. Modèles partiels (Extraits du modèle global). Les terres sont familièrement z. T. Simplifié appelé “modèle de données”; Dans le sens supplémentaire, cependant, cela signifie également les descriptions textuelles.

La forme de notation dans l’er-diagramme:

Différentes formes de représentation sont utilisées. Les types en entités sont principalement représentés comme un rectangle, les types de relations sont des lignes de connexion entre les deux extrémités de ligne ou le lettrage qui représentent la cardinalité des relations.

Il y en a un grand nombre de différents aujourd’hui Urgence , qui diffèrent, entre autres, en clarté, la portée du langage graphique, le support des normes et des outils. Dans ce qui suit, il existe des exemples importants qui montrent clairement que toutes les différences graphiques sont presque identiques dans toutes les différences graphiques.

D’une importance particulière – parfois historique – signification: entre autres::

À leur manière, toutes les notations adjacentes expriment les faits suivants:

• Une personne est née dans un (1) endroit. Un endroit est le lieu de naissance d’un certain nombre de personnes.
• Si chaque personne fait référence à un lieu de naissance devoir (Si nécessaire, il y aurait «inconnu») et / ou s’il peut également y avoir des endroits où (selon la base de données) aucune personne n’est pas né dans la notation de Chen et présenté graphiquement dans les autres formes de notation avec différents symboles.

La notation (min, max) diffère fondamentalement des autres formes de notation en ce qui concerne la détermination de la cardinalité et la position dans laquelle l’indication de fréquence dans le diagramme ER est effectuée. Dans toutes les autres notations, la cardinalité d’un type de relation est déterminée par le fait que pour une entité d’un seul type d’entité selon le nombre de participants possibles Entités de l’autre type d’entité. En revanche, la cardinalité est définie différemment en ce qui concerne la notation min-max. Pour chacun des types d’entités impliqués dans un type de relation, selon le plus petit et plus grand nombre possible de Des relations Demandé dans lequel une entité du type d’entité respectif est impliquée. Le résultat respectif Min-Max est noté pour le type d’entité pour lequel la question a été posée.

La différence numérique entre la notation Min-MAX et toutes les autres notations n’apparaît que dans les Ternréaires et les types de relations de qualité supérieure. Dans le cas des types de relations binaires, la différence ne peut être observée que dans un échange des informations de cardinalité.

Les notations de cardinalité avec n sans spécification Min-Max contiennent un déficit sémantique. Parce que vous n’avez pas les informations si la valeur N comprend 0 ou non, c’est-à-dire que la relation peut éventuellement se produire. Si z. B. Dans une relation 1: n- «dirigée» entre l’employé et le projet, un projet, même si ce n’est que temporairement, peut être sans employé de gestion, reste ouvert et doit être explicitement défini verbalement.

Description des composants du modèle [ Modifier | Modifier le texte source ]]

Bien que le diagramme ER montre les entités pertinentes dans le contexte et leurs relations (au niveau du type), les détails sont enregistrés sur leurs propres descriptions. La documentation a le but de pouvoir comprendre et communiquer les faits développés uniformément et clairement (termes uniformes!) Et de fournir des informations possibles d’un point de vue conceptuel pour les phases du projet suivantes de la mise en œuvre.

Exemples de contenu possible:

• Pour les entités: nom, nom court, définition, exemple (e), explications supplémentaires, montants appréciés, nouveaux ou déjà disponibles, …
• Pour les relations: nom court, types d’entités impliqués, déclaration de relation 1 (“MA dirige le projet”), déclaration de relation 2 (dans le sens inverse), cardinalité, peut-être d’autres conditions pour la relation (“uniquement pour les particuliers”), …
• Pour les attributs: nom, nom court, définition, exemple, explications supplémentaires, format d’information (par exemple, numéro, 2 décimales), plage de valeur (de 1 à 99), identifiant (oui / non / partiellement), …

Plus précisément, le contenu est déterminé par les outils de modélisation utilisés ou spécifiques à l’organisation (par exemple via des modèles de documents). Si des objets se produisent dans le modèle ER qui existent déjà dans l’organisation, ceux-ci sont généralement utilisés sous la forme existante (copies, …). À l’inverse, de nouveaux objets de l’ERM entrent dans le modèle de données central de l’entreprise après la fin du projet.

Le modèle ER est souvent utilisé en relation avec la conception des bases de données. Ici, la capacité sémantique de l’élargir ou de l’utiliser comme base de copie, crée un nouveau modèle ER et l’a élargi de telle manière qu’il constitue la base de la mise en œuvre de la base de données. La mise en œuvre du comportement de l’axe de données (et modélisé) dans un schéma de base de données est reconnue en plusieurs étapes:

• Reconnaître et résumer également les entités Types d’entités Par abstraction (par exemple ses collègues Fritz Maier et Paul Lehmann et bien d’autres au type d’entité employé ));
• Reconnaître et résumer les relations entre deux objets à un Relation (Exemple: l’employé Paul Lehmann dirige le projet Amélioration de l’atmosphère de travail , l’employé Fritz Maier dirige le projet Augmentation de l’efficacité de l’administration . Ces résultats conduisent au type de relation “projet employé”.);
• Détermination de Cardinalités , d. H. La fréquence d’occurrence (comme un projet est toujours gérée par exactement un employé, un employé peut mener plusieurs projets).

Ces étapes peuvent être affichées dans un modèle ER en fonction des exemples indiqués ci-dessus.

Les étapes suivantes sont également nécessaires, mais dont le résultat n’est souvent pas montré graphiquement, mais n’est complété que comme texte descriptif:

• Détermination et description plus détaillée des Attribut des types d’entités individuels – tels que la longueur du champ, les valeurs, le champ obligatoire, etc.
• Déterminer les attributs appropriés d’un type d’entité comme Identification de l’attribut (E) , So -talled Key Attributs. Si nécessaire, les clés artificielles doivent être définies.
• Déterminer plus de détails sur Implémentation de types de relations – comme une relation de devoir, une clé étrangère ou une table relationnelle, une intégrité référentielle.
• Génération du Schémas Une base de données relationnelle avec tous ses tableaux et définitions de champ associées avec leurs types de données respectifs.

Selon les outils de modélisation utilisés – et les spécifications de la méthodologie du projet – pas toujours une distinction entre l’émail et le modèle de base de données. Cela peut z. B. Pour les petits projets de base de données ou pour les tâches de base de données, où la conception de la base de données est créée à l’aide de bases de données d’utilisateurs finales (par exemple Microsoft Access) et la documentation, y compris la Terre, est prise en charge par les fonctions du même système.

Il est également possible (selon l’outil) de transférer le contenu du modèle à la conception de la base de données dans un autre outil et de continuer à le traiter là-bas. Dans ce cas en particulier, la cohérence des deux niveaux de conception doit être assurée.

Le transfert d’un modèle de hanche de relation d’entité au modèle de relation essentiellement basé sur les illustrations suivantes:

• Type d’entité → Relation
• Type de relation → clé étrangère; Dans le cas d’une relation N: M Type → Relation supplémentaire
• Attribute → Attribute.

Le transfert exact qui peut être automatisé a lieu en 7 étapes:

1. Types d’entités fortes: une relation est faite pour chaque type d’entité forte R Avec les attributs
   ${displayStyle r = lbrace a_ {1}, a_ {2}, ldots, a_ {n} rbrace cup lbrace {k} rbrace}$

   avec k Comme clé primaire et

   ${displayStyle a_ {1}, a_ {2}, ldots, a_ {n}}$

   créé comme des attributs de l’entité.

2. Types d’entités faibles: pour chaque type d’entité faible, une relation est R Créé avec les attributs
   ${displayStyle r = lbrace a_ {1}, a_ {2}, ldots, a_ {n} rbrace cup lbrace krbrace}$

   Avec la clé étrangère k ainsi que la clé principale

   ${Displaystyle lbrace krbrace cup lbrace a_ {x} rbrace}$

   , par lequel

   ${displaystyle lbrace a_ {x} rbrace}$

   le type d’entité faible et k Identifiez le type d’entité fort.

3. 1: 1 Types de relations: pour un type de relation 1: 1 des types d’entités T , S L’une des deux relations est élargie pour inclure la clé étrangère pour l’autre relation.
4. 1: n Types de relations: pour le type de relation 1: n des types d’entités T , S Si la relation incorporée à la cardinalité (ou 1 en notation min-max) T À la clé étrangère de la relation S étendu.
5. N: M TYPES DE RELATION: Pour chaque type de relation N: M, une nouvelle relation sera R Avec les attributs
   $gens$

   avec

   ${displayStyle lbrace a_ {1}, a_ {2}, ldots, a_ {n} rbrace}$

   Pour les attributs de la relation également

   ${displaystyle k_ {t}}$

   ou.

   ${displaystyle k_ {s}}$

   créé pour les clés primaires des relations impliquées.

6. Divers attributs: pour chaque attribut majoritaire dans T Sera une relation R Avec les attributs
   ${displayStyle r = lbrace krbrace cup lbrace a_ {x} rbrace}$

   , avec

   ${displaystyle lbrace a_ {x} rbrace}$

   Comme un attribut multi-valeurs et k En tant que clé étrangère T créé.

7. Types de relations N-Are: pour chaque type de relation avec un degré
   ${displayStyle n> 2}$

   

   $gens$

   avec

   ${displayStyle lbrace k_ {1}, k_ {2}, ldots, k_ {n} rbrace}$

   En tant que clé étrangère sur les types d’entités entrants également

   ${displayStyle lbrace a_ {1}, a_ {2}, ldots a_ {m} rbrace}$

   Comme attributs du type de relation. Lorsque tous les types d’entités impliqués avec cardinalité

   ${DisplayStyle> 1}$

   

   ${displaystyle n-1}$

   Clé étrangère, par laquelle la clé étrangère des types d’entités avec cardinalité

   ${DisplayStyle> 1}$

   Le modèle de relation entité – parde une vue unifiée des données . Dans: ACM trans. Syst de base de données. Groupe d’abord , Non. d’abord , Mars 1976, S. 9–36 , est ce que je: 10.1145 / 320434.320440 .

8. Peter Pin-Shan Chen: Modélisation de la relation entité – événements historiques, tendances futures et leçons apprises (PDF; 417 Ko) . Dans: M. Broy, E.Denert (Hrsg.): Pionniers du logiciel: contributions à l’ingénierie logicielle. Springs-Publis, Berlin 2002, ISBN 3-540-430-43081-4, PL 296-310.
9. John Miles Smith, Diane C. P. Smith: Abstractions de base de données: agrégation et généralisation . Dans: Transactions ACM sur les systèmes de base de données . Groupe 2 , Non. 2 , Juin 1977, S. 105–133 , est ce que je: 10.1145 / 320544.320546 .
10. John Miles Smith, Diane C. P. Smith: Abstractions de base de données: agrégation . Dans: Communications de l’ACM . Groupe 20 , Non. 6 , Juin 1977, S. 405–413 , est ce que je: 10.1145 / 359605.359620 .
11. Ramez Elmasri, Shamkant B. Navathe: Fondamentaux des systèmes de base de données . 5e édition. Addison-Wesley, 2006, ISBN 0-321-36957-2.