ER-modell

Et eksempel på et ER-diagram

I informatikk , i sammenheng med databasedesign , er enhetsrelasjonsmodellen (eller enhetsassosiasjonsmodellen ; mer vanlig ER-modellen ) en teoretisk modell for konseptuell og grafisk representasjon av data på et høyt abstraksjonsnivå , formalisert av Peter Chen i 1976 .

Entity-relationship-modellen brukes ofte i den første fasen av utformingen av en database, der det er nødvendig å oversette informasjonen fra analysen av et gitt domene til et konseptuelt skjema, kalt entity-relationship diagram (eller ER-diagram ). ).

I feltet database engineering design er det tre uavhengige og påfølgende nivåer av design: konseptuell design, logisk design, fysisk design. Riktignok er ER-modellen hovedteknikken for den konseptuelle designfasen, den relasjonelle modellen for den logiske designfasen. Først i den siste fasen av fysisk design tas programvare- og maskinvareapplikasjoner , proprietære eller ikke, som eksisterer på markedet i betraktning.

Generell informasjon

ER-modellen er basert på et sett med konsepter som er svært nær virkeligheten av interesse : derfor lett å forstå av designere (og generelt ansett som tilstrekkelig forståelig og betydningsfull selv for ikke-teknikere), men ikke implementerbar på datamaskiner . Faktisk, selv om modellen er orientert mot utformingen av databaser, er den uavhengig av de spesifikke kriteriene for fysisk organisering av vedvarende data i IT-systemer . Det finnes teknikker for å oversette konsepter på høyt nivå (bedre forstått av mennesker) til konsepter på lavere nivå som er typiske for de ulike logiske modellene (for eksempel relasjonsmodellen ) implementert i de ulike eksisterende DBMS -ene.

ER-modellen har i lang tid (og kanskje fortsatt i dag) representert en av de mest solide tilnærmingene for modellering av applikasjonsdomener innen IT-feltet; av denne grunn har den også ofte blitt brukt utenfor konteksten av databasedesign, og har blitt brukt som en referansemodell for en rekke andre modelleringsnotasjoner. Blant annet ble OMT -notasjonen inspirert av ER-modellen og senere slått sammen til UML .

Gjennom en identifikasjonssupernøkkel (felt: overordnet kode_ID, underordnet kode_ID), representerer Entity-Association-skjemaet en tregraf på et hvilket som helst antall nivåer (spesielt også en stykkliste ), veldig vanlig i dataverdenen. Sunburst Chart gir en enkel og utbredt grafisk representasjon av hierarkiske data.

Hovedkonstruksjonene til modellen

Analyse av hovedkonstruksjonene til ER-modellen: enheter, assosiasjoner og attributter.

Entitet

De representerer klasser av objekter (fakta, ting, mennesker, ...) som har felles egenskaper og autonom eksistens med det formål å anvende interesse. En forekomst av en enhet er et objekt eller en forekomst av klassen som enheten representerer. Vi snakker ikke her om verdien som identifiserer objektet, men om objektet i seg selv. En interessant konsekvens av dette faktum er at en enhetsforekomst har en eksistens uavhengig av egenskapene knyttet til den. I dette presenterer ER-modellen en markant forskjell fra relasjonsmodellen der vi ikke kan representere et objekt uten å kjenne til noen av dets egenskaper.

I et diagram har hver enhet et navn som unikt identifiserer den og er representert grafisk ved hjelp av et rektangel med navnet på enheten inni seg.

Forening

Assosiasjoner (også kalt relasjoner) representerer en kobling mellom to eller flere enheter. Antall beslektede enheter indikeres av graden av assosiasjon: en god ER-ordning er preget av en utbredelse av assosiasjoner med grad to. Det er mulig å binde en enhet med seg selv (gjennom en ringassosiasjon), samt binde de samme enhetene med flere assosiasjoner.

Det er vanligvis representert grafisk med en diamant som inneholder navnet på foreningen. Substantivet kan være et verb for å gi en leseretning, eller det kan være et substantiv for ikke å gi en leseretning. Den nyeste akademiske og profesjonelle orienteringen har en tendens til å bruke substantivet nettopp for å unngå å gi en retning til foreningen.

Attributter

Entiteter og assosiasjoner kan beskrives ved hjelp av et sett med attributter. Alle objekter av samme enhetsklasse (eller assosiasjon) har de samme attributtene - det er dette vi mener når vi snakker om lignende objekter. Valget av attributter gjenspeiler detaljnivået som vi ønsker å representere informasjon om enheter og relasjoner med. En nøkkel er definert for hver enhetsklasse eller forening. Nøkkelen er et minimalt sett med attributter som unikt identifiserer en forekomst av enhet eller assosiasjon. Attributtet er representert med en ellipse der navnet på attributtet er spesifisert eller til og med ganske enkelt, i tilfelle av komplekse diagrammer, som bare indikerer navnet, muligens i korrespondanse. Når det gjelder en primærnøkkel, er attributtnavnet understreket eller omringet.

Andre modellkonstruksjoner

Kardinalitet av assosiasjoner

De er spesifisert for hver enhet som deltar i en assosiasjon og indikerer hvor mange ganger, i en assosiasjon mellom enheter, en forekomst av en av disse enhetene kan knyttes til forekomster av de andre enhetene som er involvert i assosiasjonen (indikerer minimum og maksimum av forekomster ).

Attributtkardinalitet

Det er også mulig å definere kardinalitetsbegrensninger på attributter, med to formål:

• angi valgmuligheter;
• angi attributter med flere verdier.

Hvis begrensningsspesifikasjonen mangler, som i de fleste tilfeller, er kardinaliteten til attributtet (1,1). La oss vurdere følgende eksempel:

Siden kardinalitetsbegrensningsspesifikasjonen mangler i navnet, betyr det at kardinaliteten er (1,1).

• (0,1) NumeroPatente, det betyr at en ansatt kan ha førerkort men heller ikke ha det, eller rettere sagt at en ansatt maksimalt kan ha førerkort.
• (0, n) NumeroTelefono, betyr at en ansatt kan ha mange telefonnumre, men han kan heller ikke ha noe telefonnummer.
• (1, n) TitleStudio, det betyr at en ansatt kan ha mange kvalifikasjoner, men må ha minst én.

Entitetsidentifikatorer

De utgjør et undersett av attributtene til en enhet som unikt identifiserer hver forekomst av den samme enheten. Et eksempel kan utgjøres av CodiceFiscale-attributtet til CittadinoItaliano-enheten. Det er faktisk kjent at hver forekomst av CittadinoItaliano-enheten, det vil si alle borgere som bor på territoriet til den italienske republikken, utvetydig kan identifiseres av skattekoden hans. Dette betyr at det ikke kan være to italienske statsborgere med samme skattekode (med mindre det er et tilfelle av homokodi ).

Generaliseringer

De representerer logiske koblinger mellom to eller flere enheter. Blant de involverte enhetene skiller følgende seg ut:

• én og bare én overordnet enhet;
• en eller flere underordnede enheter.

Underordnede enheter er "spesielle tilfeller" av overordnet enhet. Hvert attributt til den overordnede enheten er også et attributt til underordnede enheter, men underordnede enheter kan ha attributter som skiller dem fra faren og søsken. Følgende eksempel viser at:

• hver person er identifisert av en skattekode og er preget av et etternavn, et navn og en alder;
• hver person skiller seg ut i mann eller kvinne;
• militær stilling kan også vurderes.

Generaliseringer er delt inn i "totalt" og "delvis". En generalisering er total når foreningen av undergruppene til barna utgjør hele faren. For eksempel er generaliseringen fra person til mann eller kvinne total siden alle mennesker er enten menn eller kvinner, derfor, ved å kombinere undergruppene av menn og kvinner, får vi settet med mennesker. En generalisering er delvis når på den annen side foreningen av undergruppene til barna ikke globalt identifiserer settet til faren. For eksempel er en overordnet enhet Bevegelsesmidler med barneenhetene Sykkel og bil en delvis generalisering, siden det i tillegg til sykler og biler finnes andre bevegelsesmidler som mopeder, tog, skip, etc. Sammenslåingen av sykkel- og bildelsettene er derfor ikke tilstrekkelig til å identifisere det overordnede settet av bevegelsesmidler.

En generalisering kan også være "eksklusiv" eller "overlappende". En generalisering er eksklusiv når skjæringspunktet mellom undergruppene til barna er tomt; den overlappes i stedet når skjæringspunktet mellom undergruppene til barna ikke er tomt. En overordnet enhet Arbeider med underordnede enheter Ansatt og Student identifiserer en overlappende generalisering ved at det kan være ansatte som samtidig er studenter. Avslutningsvis kan en generalisering være:

• totalt eksklusiv (t, e);
• totalt overlagret (t, s);
• delvis eksklusiv (p, e);
• delvis overlagret (p, s).

Noen ganger kan forkortelsene (t, e) og sistnevnte nettopp angitt, vises i ER-skjemaene for å legge til informasjon om typen generalisering; deres bruk innenfor ER grafisk skjema er imidlertid ikke bindende.

Entitet – attributt – verdi (EAV) datamodell

En Entity – attribute – value (EAV) datamodell brukes med fordel i tilfeller der databasene består av:

• enkeltattributter av variabel type over tid;
• hundrevis av tabeller eller kategorier med variabel størrelse over tid, men som innenfor dem består av noen få titalls rader eller forekomster; og et relativt lite antall tabeller, men hver har tusenvis eller millioner av rader eller forekomster.

Innenfor business intelligence kan en informasjonsstruktur av denne typen være en flerdimensjonal OLAP-kube , som brukeren ofte trenger å legge til en analysedimensjon, av et uforutsigbart antall og variabel over tid: EAV-tabellene gir en oppsummerende representasjon når dataene som skal analyseres er ekstremt spredt, for eksempel i en biomedisinsk kunnskapsbase. Den samme EAV-modellen kan også brukes til å importere EAV-tabeller direkte inn i OLAP-kuben .

En ER-modell ville ha grensen for å administrere alle tabellene på vanlig måte, selv fra et visuelt synspunkt, uavhengig av størrelse og betydning. Entitet – attributt – verdimodellen er en datamodell som overvinner denne grensen, og lar konsepter representeres på en IT- effektiv måte , i situasjoner der individuelle enheter beskrives av en rekke attributter (egenskaper eller parametere) relativt mye mindre enn de som potensielt egner seg for en effektiv konseptuell og logisk representasjon .

ER skjematisk dokumentasjon

Et ER-skjema er nesten aldri tilstrekkelig alene for å detaljere alle aspekter av en applikasjon av ulike årsaker. Først av alt, i et ER-skjema vises bare navnene på de forskjellige konseptene som finnes i det, men dette kan være utilstrekkelig for å forstå betydningen deres. Ved spesielt komplekse opplegg kan det hende at man ikke klarer å representere de ulike konseptene på en forståelig og uttømmende måte.

Av denne grunn er det viktig å gi hvert ER-skjema støttedokumentasjon som kan tjene til å lette tolkningen av selve skjemaet og for å beskrive egenskaper fra de representerte dataene som ikke kan uttrykkes direkte av modellkonstruksjonene. Derav behovet for å ha verktøy for å fullføre ordningen.

Forretningsregler

Et av verktøyene som brukes mest av informasjonssystemanalytikere for å beskrive egenskaper til en applikasjon som ikke kan representeres direkte med konseptuelle modeller, er forretningsregler . Denne betydningen stammer fra det faktum at i de fleste tilfeller er det vi ønsker å uttrykke bare en regel for det spesielle applikasjonsdomenet vi vurderer.

Begrepet forretningsregel brukes av analytikere med en bredere betydning for å indikere all informasjon som definerer eller begrenser noen aspekter ved en applikasjon. Spesielt, basert på en ganske konsolidert klassifisering, kan en forretningsregel være:

• beskrivelsen av et konsept som er relevant for applikasjonen eller den nøyaktige definisjonen av en enhet, attributt eller assosiasjon til ER-modellen;
• en integritetsbegrensning på applikasjonsdataene, det være seg dokumentasjonen av en begrensning uttrykt med en eller annen konstruksjon av ER-modellen (for eksempel kardinaliteten til en assosiasjon) eller beskrivelsen av en begrensning som ikke kan uttrykkes direkte med modellens konstruksjoner;
• en avledning eller et konsept som kan oppnås gjennom en slutning eller en aritmetisk beregning fra andre konsepter i skjemaet.

For reglene av den første typen er det helt klart umulig å definere en presis syntaks, og generelt brukes setninger i naturlig språk. Disse reglene er vanligvis representert i form av ordlister, som grupperer beskrivelsene på riktig måte.

Reglene som beskriver integritetsbegrensninger og avledninger er i stedet mer egnet for formelle definisjoner med mer eller mindre kompleks syntaks. Men gitt at det ikke finnes noen standardiseringer og at enhver valgt formalisme risikerer å ikke være tilstrekkelig uttrykksfull, vil vi fortsatt bruke definisjoner på naturlig språk, og passe på å strukturere disse definisjonene på en adekvat måte. Spesielt kan reglene som beskriver integritetsbegrensninger uttrykkes i form av påstander eller uttalelser som alltid må verifiseres i vår database. Av klarhetshensyn og for å lette konstruksjonen må disse utsagnene være atomiske, det vil si at de ikke kan dekomponeres til setninger som fortsatt utgjør utsagn. Videre, siden de brukes til å dokumentere et ER-skjema, må påstandene angis deklarativt i en form som ikke foreslår en metode for å tilfredsstille dem. Dette er faktisk et realiseringsproblem og derfor ikke relevant for konseptuell representasjon. Derfor er notasjoner som hvis <tilstand> så <handling> ikke egnet for å uttrykke forretningsregler når de dokumenterer et ER-skjema. En forhåndsdefinert struktur for å gi forretningsregler i form av påstander kan være følgende:

<konsept> må / kan ikke <uttrykk på konsepter>

hvor begrepene som er sitert kan tilsvare enten begreper som forekommer i ER-ordningen det refereres til eller begreper som kan defineres av dem.

Forretningsregler som uttrykker avledninger kan uttrykkes ved å spesifisere operasjoner (aritmetikk eller annet) som gjør det mulig å få det avledede konseptet. En mulig struktur er derfor:

<konsept> resulterer i <operasjon på konsepter>

Dokumentasjonsteknikker

Dokumentasjonen av de ulike konseptene representert i et diagram eller de beskrivende forretningsreglene kan produseres ved hjelp av en dataordbok. Den består av to tabeller: den første beskriver skjemaenhetene med navnet, en uformell definisjon på naturlig språk, listen over alle attributter (med eventuelle tilhørende beskrivelser) og mulige identifikatorer. Den andre tabellen beskriver assosiasjonene med navnet, deres uformelle beskrivelse, listen over attributter (med eventuelle beskrivelser) og listen over involverte enheter sammen med deres deltagelseskardinalitet.

Når det gjelder andre regler, kan du fortsatt bruke en tabell der de ulike reglene er listet opp, og spesifisere deres type hver gang. Det er viktig å representere alle reglene som beskriver begrensninger som ikke er uttrykt av ordningen, men det er noen ganger nyttig å også representere regler som dokumenterer begrensninger som allerede er uttrykt i ordningen.

ER-skjemaoversettelse

Oversettelsen av ER-skjemaet til et ekvivalent logisk skjema (basert på en logisk modell, for eksempel relasjonsmodellen ) , dvs. i stand til å representere den samme informasjonen, er et grunnleggende trinn i den logiske utformingen , som normalt innledes av restruktureringsfasen . av ordningen ER . Hovedelementet i oversettelsen av et ER-skjema til et ekvivalent logisk skjema er det faktum at relasjoner ikke eksisterer i relasjonsmodellen , derfor må både enheter og assosiasjoner oversettes til relasjoner , gjennom passende kodede regler, basert på hovedidentifikatorene som er bestemt i restruktureringsfasen av ER-ordningen, kardinaliteten til foreningene og tilstedeværelsen av eksterne identifikatorer.

Mens den forberedende fasen av restrukturering av ER-ordningen kun er delvis automaterbar , fra den restrukturerte ER-ordningen er forskjellige programvarer på markedet i stand til automatisk å utlede det tilsvarende relasjonsskjemaet, selve databasen. En åpenbar konsekvens av disse fakta, og åpenbart også av modellene som er involvert, er at aktiviteten med å automatisk utlede et ER -skjema fra relasjonsskjemaet utledet på grunnlag av den fysiske implementeringen av DB , en funksjon som er gjort tilgjengelig av noen programvare, generelt tillater den ikke å få den originale ER-ordningen .

Navnet på hver enhet tilsvarer overskriften til en tabellmatrise, med like mange kolonner som det er attributter til enheten. Hvis attributtet er en primærnøkkel eller del av en supernøkkel som består av flere attributter, kan det ikke anta NULL-verdien (ikke-valgfritt, obligatorisk attributt) og kan ikke anta to forekomster av samme verdi (unike, ikke-gjentatte verdier).

Hvis assosiasjonen mellom to eller flere enheter har en eller flere attributter, vil normalt assosiasjonen gi opphav til en tabell som har som en identifikasjonsnøkkel settet med primærnøkler til alle enhetene som er forbundet med forholdet (med hvilken som helst kardinalitet) og som felter attributter plassert på relasjonen i ER-ordningen. Denne passasjen, av logisk karakter, skal ikke forveksles med tingsliggjøring av en assosiasjon til en enhet, en passasje som har en konseptuell karakter som kan gjennomføres i ER-ordningen.

I et andre trinn kan antallet tabeller reduseres betydelig, med tanke på den maksimale kardinaliteten (enhetlig, n-air) som forbinder to tabeller.

Bibliografi

• EF Codd, A Relational Model of Data for Large Shared Data Banks , IBM Research Laboratory, San Jose, California, Communications of the ACM - Volume 13 / Number 6 / June 1970
• Atzeni, Ceri, Paraboschi, Torlone, Databaser (modeller og spørrespråk) , McGraw Hill, 2003
• Atzeni, Ceri, Fraternali, Paraboschi, Torlone, databaser (arkitektur og evolusjonslinjer) , McGraw Hill, 2003
• Ramez Elmasri, Shamkant B. Navathe, Databasesystemer , grunnleggende , Pearson - Addison Wesley, 2003

Andre prosjekter

Andre prosjekter

• Wikimedia Commons

• Wikimedia Commons inneholder bilder eller andre filer på enhetsassosiasjonsmodellen