Entitetsforholdsmodel

fra Wikipedia, den gratis encyklopædi
Spring til navigation Spring til søgning

Entity-Relationship-modellen -kort ER-Modell eller ERM ; Tysk så meget som: Model (til repræsentation) af ting, objekter, objekter (= 'entiteter') og relationerne / indbyrdes forhold mellem disse (= 'forhold') - bruges i forbindelse med semantisk datamodellering i en given kontekst (f.eks. et projekt til oprettelse af et informationssystem) til at bestemme og vise et relevant afsnit af den virkelige verden. ER -modellen består hovedsageligt af en grafik ( ER -diagram , forkortelse ERD) og en beskrivelse af de elementer, der bruges i den.

En ER-model bruges både i den konceptuelle fase af applikationsudviklingen af ​​kommunikation mellem brugere og udviklere (dette er kun det, der blev behandlet, det vil sige tekniske og faktuelle omstændigheder, ikke hvordan, z. B. teknologien) og i implementeringen fase som grundlag for udformningen af ​​den - for det meste relationelle - database .

Anvendelsen af ​​ER -modeller er de facto -standarden for datamodellering , selvom der er forskellige grafiske repræsentationsformer for datamodeller .

ER-modellen blev introduceret af Peter Chen i hans publikation fra 1976 The Entity-Relationship Model . De beskrivende midler til generalisering og aggregering blev introduceret i 1977 af John M. Smith og Diane CP Smith. Derefter var der flere yderligere udviklinger, for eksempel i slutningen af ​​1980'erne af Wong og Katz.

Betingelser

Enkle eksempler på ERD'er baseret på Chen -notationen

Grundlaget for entitetsrelationsmodellerne er typisering af objekter, deres forhold til hinanden og de oplysninger, der skal opbevares om dem ("attributter").

Grundlæggende komponenter

I diskussioner, eksempler og begrebetekster henvises til objekter og betingelser i den virkelige verden (i forbindelse med observation); disse kaldes:

  • Enhed : individuelt identificerbart objekt for virkeligheden; z. B. medarbejderfræseren, projektet 3232
  • Forhold: forbindelse / forbindelse mellem to eller flere enheder; z. B. Medarbejder Miller leder Project 3232.
  • Attribut: Hvad er interessant ved en enhed (i kontekst); z. B. medarbejdernes møllers indtrædelsesdato.

I forbindelse med modelleringen dannes lignende typer ud fra de førnævnte fakta og præcist defineret og beskrevet i modellen . Disse typer adskiller sig efter:

  • Enhedstype: Indtastning af lignende enheder f.eks. B. Medarbejder, projekt, bog, forfatter, forlag
  • Forholdstype: typisering af lignende relationer; z. B. Medarbejder leder projekt
  • Attribut : Typning af lignende ejendomme, f.eks. B. Efternavn, fornavn og startdato i enhedstypen Medarbejder. Attributten eller kombinationen af ​​attributter, gennem hvilke værdier entiteter er klart genkendelige, dvs. de identificerer, kaldes identificerende attribut (er); for eksempel er attributprojektnummeret i entitetstypeprojektet en identificerende attribut.

Særlige spørgsmål

ER -modellering kender følgende konstruktioner til beskrivelse og repræsentation af særlige fakta:

  • Stærk entitetstype: En enhed kan identificeres ved en eller flere værdier af attributter af samme entitetstype; så er z. B. Identifikation af ordrenummeret for ordrenhedstypen.
  • Svag entitetstype : For at identificere en sådan enhed kræves en attributværdi for en anden enhed af stærk type relateret til den svage enhed; så er z. For eksempel for at identificere den svage entitetstype "værelse" er det ud over værelsesnummeret også nødvendigt at angive en bygning af en anden stærk objekttype "bygning". I udvidelser af ER-modellen, f.eks. SERM , flettes den svage entitetstype og den tilhørende relationstype til en såkaldt ER-type, hvilket gør diagrammer mere kompakte.
  • Kardinalitet : Kardinaliteten definerer (på relationstypeniveau) for hver af de entitetstyper, der er involveret i, hvor mange specifikke relationer (af denne type) dens enheder kan eller skal være involveret. Forskellige former for notation er blevet udviklet til at repræsentere kardinaliteten, hvoraf modelleringsværktøjer for det meste understøtter en bestemt.
  • Refleksivt (selvreferentielt) forhold: forholdet mellem individuelle enheder af en og samme entitetstype, således en relationstype mellem den samme entitetstype (for eksempel træstrukturen i en organisationsstruktur gennem "organisatorisk enhed er opdelt i organisatorisk enhed" og netværksstrukturen for en deleliste gennem "del bruges delvist"). Synonym: rekursivt forhold.
  • Relationstypegrad eller kompleksitet: Antal enhedstyper, der er involveret i en relationstype. Reglen er klasse 2 (binær relationstype); sjældent forekommer grad 3 (ternær relationstype) eller en højere karakter. Ternære og højere niveau-relationstyper kan groft reduceres til binære relationstyper ved at indføre en ny entitetstype (som svarer til den oprindelige relationstype). Eksempel: Medarbejder passer leverandøren (for produktgruppe) ; Ny leverandør support enhed type med relationer til de tre oprindelige typer enhed. En sådan procedure kan imidlertid være tabsrig, det vil sige, at der er fakta, der kun nøjagtigt kan repræsenteres af flercifrede relationstyper.
  • Forholdsattributter: Normalt har relationstyper ingen attributter, da de kun forbinder de entitetstyper, der er involveret i hinanden. Men hvis yderligere attributter er påkrævet, kan der - som med relationer på højere niveau - oprettes en uafhængig entitetstype med relationstyper til de oprindeligt involverede entitetstyper ud fra relationstypen. Attributten tildeles derefter den nye (svage) entitetstype ( f.eks. Grad af projektdeltagelse i relationstypen medarbejder arbejder på projekt ). Afhængigt af den anvendte modelleringsmetode kan der også formuleres "attributive" relationer, men dannelsen af ​​nye entitetstyper bruges ofte som en erstatning.

Forhold til særlig semantik

Betydningen af ​​relationstyperne mellem entitetstyper med hensyn til indhold udtrykkes kun i ER -diagrammet ved en kort tekst i romben (normalt et verbum) eller som en etiket på kanten, hvorved modellereren frit kan vælge, hvilken betegnelse han tildeler. Nu er der relationer til speciel semantik, der forekommer relativt hyppigt i modellering. Af denne grund er der blevet defineret særlige identifikatorer og grafiske symboler for disse relationstyper. Specialisering og generalisering samt aggregering og nedbrydning er yderligere beskrivelsesmidler med særlig semantik. Med disse to særlige former for relationer kan forholdene i den virkelige verden modelleres og repræsenteres mere præcist og efter deres faktiske betydning. Faste navne og særlige grafiske symboler viser, at der er tale om semantisk på forhånd tildelte relationer til særlige regler.

Disse entitets- og relationstyper, som normalt kun er specielt modelleret i semantiske datamodeller , kan implementeres på forskellige måder med hensyn til databaseteknologi, f.eks. (Identisk med modelleringen) som separate tabeller eller i delte tabeller med kommentarer eller attributbetegnelser, der kendetegner det særlige forhold. Implementeringsbeslutningen herom træffes (samt bestemmelse af kardinaliteten for disse særlige forhold) i databasemodelleringens aktiviteter.

Specialisering og generalisering ved hjælp af et is-a- forhold

Under specialisering genkendes og erklæres en entitetstype som en delmængde af en anden entitetstype, idet det specialiserede entitetssæt adskilles fra det højere niveau, generaliseret sæt ved særlige egenskaber (attributter og / eller relationer, der kun gælder for det). Da et individuelt objekt i det specialiserede sæt og det generaliserede sæt er det samme individuelle objekt, gælder alle egenskaber - især identifikationen - og alle forhold mellem det generaliserede individuelle objekt også for det specialiserede individuelle objekt.

Forholdstyper af typen "specialisering / generalisering" er beskrevet af is-a / can-be ("er a" / "kan være en ..."). A-kind-of ("en slags ...") bruges undertiden til is-a . Disse er 1: c -relationer.

Eksempel på is-a- forholdet:

Flyrejser er en rejse

og i en anden læseretning:

Rejser kan være flyrejser,

med ejendomme som f.eks. rejsedato, rejsepris (for rejser) og relationer til flyveenhedstypen (til flyvning).

Den is-en relation, der er beskrevet her (mellem identiske individuelle objekter) må ikke forveksles med is-element-af forholdet (associeringen af ​​et individuelt objekt med et andet), som notationen is-a lejlighedsvis bruges til, f.eks. B. Flyvning er en flyvning (hvilket ville være semantisk forkert).

Om nødvendigt kan flere specialiserede enhedstyper erklæres for en specialisering. Det skal afgøres, om individuelle objekter af den generaliserede entitetstype kan mangle fra specialiseringerne, og om de kun kan forekomme alternativt i et specialiseret enhedssæt eller i flere specialiserede entitetssæt på samme tid. Eksempel: Kunden er en privat kunde eller en virksomhedskunde; et af forholdene skal eksistere.

Generalisering / specialisering skyldes modelleringsprocessen

Mens specialiseringer opstår ved dannelsen af ​​partielle enhedssæt fra givne enheder, kombineres fælles egenskaber og relationer, der forekommer i forskellige enhedstyper, til en ny entitetstype under generalisering . Så z. B. Kunder og leverandører kan samles ud over forretningspartnere, da navn, adresse, bankoplysninger osv. Forekommer både hos kunden og hos leverandøren.

I dette eksempel er den resulterende generaliseringsforholdstype baseret på forretningspartneren og fører til de to enhedstyper kunde og leverandør. Om forholdet kun kan eller skal forekomme i specifikke individuelle tilfælde for enheder fra kun en af ​​de to eller fra begge enhedstyper, bestemmes af kardinaliteten.

Ovenstående skelnen mellem specialisering og generalisering skyldes kun den rækkefølge, som enhedstyper blev identificeret under modelleringen; Som et resultat er der altid relationstyper, der er specialisering i den ene retning og generalisering i den anden. Om nødvendigt kan der forekomme flere specialiseringer / generaliseringer for den samme entitetstype. Eksempel: Medarbejdere kan specialiseres til eksterne medarbejdere eller interne medarbejdere ( disjunct ) og derudover til "ledelsesmedarbejdere". Specialiserede enhedstyper kan også specialiseres / generaliseres igen (fortsat, kaskade).

Den visuelle repræsentation af specialiseringer og generaliseringer er ikke fastsat i det originale ERM -diagram, men bruges i udvidelser som f.eks. B. SERM bruges.

Aggregering og nedbrydning ved hjælp af et er-del-af- forhold

Hvis flere individuelle objekter (f.eks. Person og hotel) kombineres til at danne et uafhængigt individuelt objekt (f.eks. Reservation), kaldes dette aggregering. Den overordnede, uafhængige helhed kaldes aggregatet; de dele, der udgør det, kaldes komponenter. Aggregat og komponenter erklæres som en entitetstype.

I tilfælde af aggregering / nedbrydning skelnes der mellem rolle og mængde -aggregering:

En rolleaggregering eksisterer, når der er flere rollespecifikke komponenter, disse kombineres til et aggregat, og der er et 1: c-forhold.

Eksempel på et er-del-af- forhold:

Fodboldhold er en del af fodboldkamp og spillested er en del af fodboldkamp

og i en anden læseretning:

Fodboldkamp består af et fodboldhold og et spillested.

Der opstår en mængde -aggregering, når aggregatet oprettes ved at kombinere individuelle objekter fra præcis en komponent. Der er et 1: cN forhold her.

Eksempel på mængdeaggregering:

Fodboldspiller er en del af fodboldholdet

og i en anden læseretning:

Fodboldholdet består af (flere, N) fodboldspillere.

Indhold i ER -modellen

ER -diagrammer

Den grafiske fremstilling af entitet og relationstyper (repræsentativ og afledt ved at skrive fra de enheder og relationer, der er identificeret i den givne kontekst) kaldes et enhedsrelationsdiagram (ERD) eller ER -diagram . Dette er en oversigt / grafik over alle relevante enheder og deres indbyrdes forhold, som kan skabe en netværkslignende struktur, der fremstår kompleks. I tilfælde af meget store modeller vises delvist modeller (uddrag fra den overordnede model) normalt af klarhedshensyn. I daglig tale er ERD'er z. Nogle gange kaldet "datamodellen" for enkelhed; i en bredere forstand omfatter dette imidlertid også de tekstbeskrivelser.

Notationsformularer i ER -diagrammer:

ERD i forskellige notationer

Der er forskellige former for repræsentation i brug. Enhedstyper er for det meste repræsenteret som rektangler, relationstyper som forbindelseslinjer med forskellige linieender eller etiketter, der repræsenterer relationernes kardinalitet .

I dag er der et stort antal forskellige notationer , der blandt andet adskiller sig med hensyn til klarhed, omfang af det grafiske sprog, støtte fra standarder og værktøjer. I det følgende er der nogle vigtige eksempler, der gør det klart, at trods alle de grafiske forskelle er ER -diagrammernes kerneudtalelser næsten identiske.

Af særlig - til dels historisk - betydning er blandt andre:

Alle de tilstødende notationer udtrykker følgende på deres egen måde:

  • En person er født et (1) sted. Et sted er fødestedet for et vilkårligt antal (N) mennesker.
  • Om nogen peger på en fødsel skal (det kan muligvis være stedet Ukendt ') og / eller om der kan være steder, hvor (iflg. Datasæt) ingen person blev født, ikke i Chen -notationen og de andre former for notation er vist grafisk med forskellige symboler.

Notationen (min, max) adskiller sig fundamentalt fra de andre former for notation med hensyn til bestemmelse af kardinaliteten og den position, hvor frekvensen er angivet i ER -diagrammet. I alle andre notationer bestemmes kardinaliteten af ​​en relationstype ved at bede om en enhed af en entitetstype om antallet af mulige deltagende enheder af den anden entitetstype. I tilfælde af min-max-notationen på den anden side er kardinaliteten defineret forskelligt. For hver af de enhedstyper, der er involveret i en relationstype, stilles spørgsmålet om det mindste og størst mulige antal relationer , som en enhed af den respektive entitetstype er involveret i. Det respektive min-max resultat noteres for den enhedstype, som spørgsmålet blev stillet til.

Den numeriske forskel mellem min-max-notationen og alle andre notationer bliver kun tydelig i tilfælde af ternære og højere niveau-relationstyper. I tilfælde af binære relationstyper kan forskellen kun ses i en udveksling af kardinalitetsoplysningerne.

Kardinalitetsnotationer med n uden min-max-specifikation har et semantisk underskud. Fordi de ikke angiver, om værdien n indeholder 0 eller ej, så kan relationen eventuelt opstå. Om z. For eksempel, i tilfælde af et 1: n -forhold mellem medarbejder og projekt, forbliver et projekt, selvom det kun må være midlertidigt uden ledelsesmedarbejdere, åbent - og skal eksplicit defineres verbalt.

Beskrivelse af modelkomponenterne

Mens ER -diagrammet viser de enheder, der er relevante i konteksten og deres relationer (på typeplan), registreres detaljer ved hjælp af deres egne beskrivelser. Dokumentationen tjener formålet med at kunne forstå og kommunikere de udviklede fakta ensartet og klart (ensartede termer!) Og at give de oplysninger, der er mulige fra et konceptuelt synspunkt for de efterfølgende projektfaser af implementeringen.

Eksempler på muligt indhold:

  • For enheder: navn, kort navn, definition, eksempler, yderligere forklaringer, estimerede mængder, nye eller allerede tilgængelige, ...
  • For relationer: kort navn, involverede enhedstyper, relationserklæring 1 ("MA leder projekt"), relationserklæring 2 (i modsat retning), kardinalitet, muligvis andre betingelser for forholdet ("kun for privatpersoner"), .. .
  • For attributter: navn, kort navn, definition, eksempel, yderligere forklaringer, informationsformat (f.eks. Tal, 2 decimaler), værdiområde (fra 1 til 99), identifikation for enhed (ja / nej / delvist), ...

Konkret bestemmes indholdet af de anvendte modelleringsværktøjer eller organisationsspecifikke (f.eks. Via dokumentskabeloner). Hvis der er objekter i ER -modellen, der allerede findes i organisationen, bruges disse normalt i deres eksisterende form (kopier, ...). Omvendt er nye objekter fra ERM inkluderet i virksomhedens centrale datamodel efter projektets afslutning.

Brug af ERM i databasedesign

ER -modellen bruges ofte i forbindelse med design af databaser. Her, ved at udvide det semantiske ERM eller bruge det som kopieringsgrundlag, genereres en ny ER -model, og denne udvides på en sådan måde, at den danner grundlag for implementeringen af ​​databasen. Implementeringen af ​​de datafakta, der genkendes (og modelleres) i den virkelige verden i et databaseskema, foregår i flere trin:

  • I erkendelse og sammensluttende virksomheder i enhed typer gennem abstraktion (fx kolleger Fritz Maier og Paul Lehmann og mange andre på medarbejderen enhed typen);
  • Anerkender og kombinerer relationer mellem to objekter for at danne en relationstype (eksempel: medarbejderen Paul Lehmann leder projektforbedringen af arbejdsmiljøet , medarbejderen Fritz Maier leder projektet for at øge effektiviteten i administrationen . Disse fund fører til forholdstypen "medarbejder leder projekt ".);
  • Bestemmelse af kardinaliteterne , dvs. hyppigheden af ​​forekomst (f.eks. Et projekt ledes altid af præcis en medarbejder, en medarbejder får lov til at styre flere projekter).

Disse trin kan repræsenteres i en ER -model i henhold til eksemplerne vist ovenfor.

Følgende trin er også nødvendige, hvis resultat dog ofte ikke vises grafisk, men kun suppleres som en beskrivende tekst:

  • Bestemmelse og detaljeret beskrivelse af de relevante attributter for de enkelte entitetstyper - såsom feltlængde, værdiområder, obligatoriske felter osv.
  • Bestemmelse af egnede attributter af en entitetstype som identificerende attribut (er) , såkaldte key attributes . Om nødvendigt skal kunstige nøgler defineres.
  • Definition af yderligere detaljer til implementering af relationstyper - såsom obligatorisk relation, fremmed nøgle eller relationstabel, referentiel integritet.
  • Generering af skemaet for en relationsdatabase med alle dens tabeller og tilhørende feltdefinitioner med deres respektive datatyper .

Afhængigt af de anvendte modelleringsværktøjer - og specifikationer for projektmetodikken - skal der ikke altid skelnes mellem ERM og databasemodel. Dette kan f.eks. Dette kan f.eks. Være tilfældet med små databaseprojekter eller databaseopgaver, hvor databasedesignet oprettes ved hjælp af slutbrugerdatabaser (f.eks. Microsoft Access ), og dokumentationen inklusive ERD understøttes af funktioner i det samme system.

Det er også muligt (afhængigt af værktøjet) at overføre modelindhold til opfattelse af databasen til et andet værktøj og behandle det videre der. Især i dette tilfælde bør konsistensen mellem de to designniveauer sikres.

Overførsel til en relationel model

Overførslen af ​​en enhedsrelationsmodel til relationsmodellen er i det væsentlige baseret på følgende tal:

  • Enhedstype → relation
  • Forholdskategori → fremmed nøgle; i tilfælde af en n: m relationstype → yderligere relation
  • Attribut → Attribut.

Den nøjagtige overførsel, som kan automatiseres, foregår i 7 trin:

  1. Stærke entitetstyper: For hver stærk entitetstype er der en relation R med attributterne med k som primærnøgle og oprettet som en attribut for enheden.
  2. Svage entitetstyper: For hver svag entitetstype oprettes en relation R med attributterne med fremmednøglen k og den primære nøgle , hvori identificere den svage entitetstype og k identificere den stærke entitetstype.
  3. 1: 1 relationstyper: For en 1: 1 relationstype for entitetstyperne T , S udvides den ene af de to relationer med fremmednøglen til den anden relation.
  4. 1: N-relationstyper: For 1: N-relationstypen for enhed T er S den indgående med kardinaliteten N (eller 1 i min-max-notation) Forhold T udvidet med den udenlandske nøgle til relationen S.
  5. N: M -relationstyper: For hver N: M -relationstype er der en ny relation R med attributterne med også for relationens egenskaber eller. skabt til de primære nøgler til de involverede relationer.
  6. Attributter med flere værdier: For hver attribut med flere værdier i T er der en relation R med attributterne , med skabt som en multi-værdi-attribut og k som en udenlandsk nøgle på T.
  7. n-ary relationstyper: For hver relationstype med en grad der oprettes en relation R med attributterne med som en fremmed nøgle til de indgående enhedstyper samt som attributter for relationstypen. Hvis alle deltagende enheder skriver med kardinalitet modtages, er den primære nøgle sættet med alle udenlandske nøgler. I alle andre tilfælde inkluderer den primære nøgle Udenlandske nøgler, hvor de udenlandske nøgler tilhører enhedstyper med kardinalitet skal altid være inkluderet i den primære nøgle.

Se også

litteratur

Weblinks

Commons : Entity-Relationship-Models -samling af billeder, videoer og lydfiler