En konseptuell databasemodell er et diagram over relasjonene mellom objekter. Er datamodell

Jeg vil gjerne komme med et lite tillegg til artiklene Utvikling → Relasjoner mellom databasetabeller og Utvikling → Design av databaser av Khabravian ueasley.

Jeg vil gjerne beskrive reglene for hvordan du kan bygge et relasjonsdatabaseskjema. Disse reglene er sannsynligvis til liten nytte for noen, siden de brukes av utviklere på et intuitivt nivå, men de er til og med interessante fordi de formaliserer prosessen med å konstruere et databaseskjema.

Disse reglene gjelder for ER-modellen, det vil si «entity-relationship»-modellen.

ER-modell

ER-modellen er et diagram hvis komponenter er:

Essens- dette er et reelt eller imaginært objekt, informasjon om hvilken må lagres i en database. I et ER-modelldiagram er en enhet avbildet som et rektangel som inneholder navnet på enheten.
Forbindelse- en assosiasjon mellom to (oftest) enheter, eller mellom samme enhet (rekursivt forhold), vist grafisk på et diagram. Forbindelsen er avbildet som en diamant med to ender, en for hver enhet. For hver side av denne forbindelsen er følgende etablert:
1. Tilknytningsgrad - hvor mange forekomster av en gitt enhet er tilknyttet
2. Obligatorisk tilkobling - om denne enheten nødvendigvis må delta i tilkoblingen.

La meg gi deg et eksempel:
Anta at du trenger å lagre informasjon om kunder og deres bestillinger. La oss bygge et diagram

Legg merke til at fra siden av "ORDER"-enheten er forholdet indikert med et ekstra rektangel - dette betyr at hver forekomst av "ORDER"-enheten tilsvarer en forekomst av "CLIENT"-enheten (for klienten, tilstedeværelsen av en bestilling er ikke nødvendig). Graden "M" betyr at for hver forekomst av "KLIENT"-enheten kan det være flere forekomster av "ORDER"-enheten (men ikke omvendt, siden det for hver ordre alltid bare er én kunde - vi setter graden til " 1")

En relasjon (som vanligvis tilsvarer en tabell i en database) skal ikke forveksles med en enhet. En enhet transformeres til en relasjon ved å isolere den fra ER-diagrammet.

Designstadier

Konseptuell design
Et ER-diagram er konstruert som inkluderer alle enheter og relasjoner. Vi får en konseptuell (infologisk) modell. Det skal forstås at en slik modell kanskje ikke samsvarer godt med relasjonsstrukturen til databasen som blir utformet.
La oss si at du må bygge en database der du må lagre fullstendig informasjon om bestillinger, kunder og ansatte. For hver ordre er det en liste over elementer i denne ordren (flere produkter), som hver er knyttet til en liste over forbrukte materialer og utførte operasjoner.
Jeg kom opp med følgende diagram.

Ris. 2

Logisk design

Et sett med foreløpige relasjoner er konstruert, som indikerer primærnøkkelen for hver relasjon. En liste over attributter kompileres, og deretter fordeles disse attributtene i relasjoner. Det er nødvendig at alle relasjoner forblir innenfor BCNF.

Overgangen til en relasjonsstruktur (bygge et sett med relasjoner) gjøres i henhold til følgende regler:

Hvis graden av en binær relasjon er 1:1 og medlemskapsklassen til begge enhetene kreves, kreves det bare ett forhold. Den primære nøkkelen til dette forholdet kan være nøkkelen til en av disse to enhetene. I dette tilfellet vil hver nøkkelverdi garantert vises én gang i en hvilken som helst forekomst av relasjonen.
Hvis graden av en binær relasjon er 1:1 og klassen til en av enhetene er valgfri, er det nødvendig å bygge to relasjoner; en relasjon må tildeles for hver enhet. Nøkkelen til en enhet som medlemskapsklassen er valgfri for, legges til som et attributt til forholdet som er tildelt for enheten med den nødvendige medlemsklassen.
Hvis graden av en binær relasjon er 1:1 og medlemskapsklassen for ingen entitet er valgfri, brukes tre relasjoner - en for hver enhet - hvis nøkler fungerer som primære i de tilsvarende relasjonene og en for relasjonen. Et forhold dedikert til et forhold vil ha én enhetsnøkkel fra hver enhet.
Hvis graden av en binær relasjon er 1: M og medlemsklassen til den M-relaterte enheten er obligatorisk, er det tilstrekkelig å bruke to relasjoner: en for hver enhet, forutsatt at enhetsnøkkelen fungerer som primærnøkkelen for tilsvarende forhold. Nøkkelen til en enkelt tilkoblet enhet må legges til som et attributt til relasjonen som er tilordnet en M-tilkoblet enhet.
Hvis graden av en binær relasjon er 1: M og medlemsklassen til en M-relatert enhet er valgfri, må tre relasjoner brukes: en for enheten og en for relasjonen. En relasjon må blant sine attributter ha en enhetsnøkkel for hver enhet.
Hvis graden av en binær relasjon er M:M, trengs tre relasjoner for å lagre data: en for enheten og en for relasjonen. Enhetsnøkler er inkludert i forholdet. Hvis en av enhetene er degenerert, er det to relasjoner (det vil si at to tabeller vil være nok).
Ved en treveisrelasjon må fire relasjoner brukes: en per enhet og en for relasjonen. Relasjonen generert av forbindelsen inneholder blant attributtene enhetsnøklene fra hver enhet.

La oss bruke reglene og legge dataene inn i en tabell.

Enheter	Regelnummer	Forhold
Klient Rekkefølge	4	Klient(#Client Ordre(#Ordre, #Kunde
Ansatt Rekkefølge	4	Ansatt(#Ansatt Ordre(#Ordre, #Ansatt
Rekkefølge Bestillingsvare	4	Ordre(#Ordre Ordreelement(#Ordreelement, #Order
Brigade Bestillingsvare	4	Brigade(#Brigades Bestillingselement (#Element, #Crew
Produkt Bestillingsvare	4	Produkt(#Produkter Bestillingsvare (#Artikler, #Produkter
Klient Rekkefølge	6	Klient(#Client Ordre(#Ordre Betaling(#Betaling, #Kunde, #Ordre
Brigade Ansatt	5	Brigade(#Brigades Ansatt(#Ansatt Teamansatt(#Brigadeansatt, #Ansatt, #Brigade
Bestillingsvare Operasjon	5	Bestillingsvare(#Item Operasjon(#Operasjoner Ta opp operasjon(#Records, #Element, #Operations
Bestillingsvare Materiale	5	Bestillingsvare(#Item Materiale(#Material Forbruk(#Records, #Element, #Material

Bord 1

Etter å ha distribuert attributtene i henhold til de resulterende forholdene, får vi (i listen over felt er primærnøkkelen på første plass, resten, merket med "#", er fremmednøkler):

BRIGADE	(#Crews, #Foreman, Location)
JOBBTITTEL	(#Positions, Stilling, Lønn)
REKKEFØLGE	(#Ordre, #Client, #Ansatt, Plasseringsdato, Påkrevd dato, Utførelsesdato, Beskrivelse)
KLIENT	(#Kunde, Tittel, Fornavn, Etternavn, Organisasjon Eller Avdeling, Adresse, Telefonnummer, E-postadresse)
OPPTAKSOPPERASJONER	(#Records, #Item, #Operations, #Ansatt, Quantity)
INNBETALING	(#Payment, #Client, #Order, Payment Amount, Payment Date, Notes)
FORBRUK	(#Records, #Consumables, #Items, Quantity)
FORBINDELSE	(#Vare, #Ordre, #Produkt, #Team, Antall)
SOTRBRIGADA	(#CrewBrigade, #Brigade,#Employee)
ANSATT	(#Ansatt, Passnummer, Etternavn, Fornavn, Patronym, #Posisjon, Adresse, Hjemmetelefon, Arbeidstelefon, Fødselsdato, Ansettelsesdato, Dato for slutt på kontrakt, Foto, Notater)
OPERASJON	(#Operasjoner, Beskrivelse, Kostnad, Tid, Utstyr, Utførelse)
MATERIALE	(#Exp.Mat, NaimExp.Mat, Price, Density, Type, Composition)
PRODUKT	(#Produkt, merke, navn, produktbeskrivelse, type, serienummer, på lager, pris)

Bord 2

Dette er hva vi ble lært å gjøre på universitetet. Kanskje noen vil være interessert. Når det gjelder "er dette nødvendig", lytter jeg til dine meninger!

ER-modeller isolert fra temaet design av relasjonsdatabaser.

Men hvis du samtidig trenger å bruke vilkårene for ER-modellen og relasjonsdatamodellen, så må du selvfølgelig bruke begrepene forhold Og forhold ulike russiske ekvivalenter. Det er svært forskjellige konsepter bak disse begrepene. I relasjonsmodellen er relasjon det eneste generiske data struktur. Den samme mekanismen brukes til å representere "relaterte" enheter (tenk for eksempel på fremmednøkler). Som vi skal se litt senere, bruker ER-modellen to like begreper for å representere databaseskjemaet – entitet og relasjon. Relasjoner i ER-modellen spiller en annen rolle enn relasjoner i relasjonsdatamodellen.

I tillegg har ren translitterasjon av begrepet også gått inn i russiskspråklig terminologi forhold akkurat i betydningen holdning. Vi snakker for eksempel om en relasjonsdatamodell, relasjonsalgebra osv., mens vi forstår en relasjonsdatamodell, relasjonsalgebra osv. Ved denne anledningen, i hvert fall i databasesammenheng, er det lurt å til slutt reservere begrepene forhold Og holdning for å betegne begrepene til relasjonsdatamodellen, og for begrepet forhold bruke en annen akseptabel russisk-språklig ekvivalent - kommunikasjon.

De fleste moderne tilnærminger til databasedesign (hovedsakelig relasjonell) er basert på bruk av ulike versjoner av ER-modellen. Modellen ble foreslått av Peter Chen i 1976. Modellering fagområde er basert på bruk av grafiske diagrammer som inkluderer et lite antall heterogene komponenter. Enkelhet og klarhet i presentasjonen konseptuelle databasediagrammer i ER-modellen førte til utbredt bruk i CASE-systemer som støtter automatiserte relasjonsdatabasedesign. Blant de mange variantene av ER-modeller ble en av de mest populære og utviklet brukt i Oracle CASE-systemet. Vi vil diskutere en forenklet versjon av denne modellen. For å være mer presis, la oss fokusere på dens strukturelle og integrerte deler.

Grunnleggende konsepter for ER-modellen

Hovedkonseptene i ER-modellen er enhet, relasjon og attributt. Essens er et reelt eller tenkelig objekt, informasjon om hvilken må lagres og være tilgjengelig. 4 Det er klart at denne "definisjonen" faktisk er en tautologi, siden vi for det første prøver å definere begrepet entitet gjennom det udefinerte begrepet objekt, og for det andre er forsøk på å definere begrepet objekt like håpløse. Vanligvis prøver forfattere å rettferdiggjøre seg selv ved å si at de i en slik sammenheng mener det «hverdagslige» og ikke et eller annet formalisert begrep om et objekt. Dette gjør det selvfølgelig ikke lettere, siden essensbegrepet må forstås i en ganske presis forstand. Men denne tautologien ble ikke oppfunnet av forfatteren av dette kurset; det er tradisjonelt for feltet semantisk modellering. På dette området prøver de å unngå formaliteter i størst mulig grad. I ER-modelldiagrammer er en enhet representert som et rektangel som inneholder enhetsnavnet. I dette tilfellet er navnet på enheten navnet på typen, og ikke en spesifikk forekomst av denne typen. 5 Selv om det ville være mer riktig å alltid bruke begrepene enhetstype og enhetstype forekomst, for å unngå ordlyd (og for å følge tradisjon) i tilfeller der det ikke fører til tvetydighet, vil vi bruke begrepet entitet til å bety enhetstype. For større uttrykksevne og bedre forståelse kan et enhetsnavn ledsages av eksempler på spesifikke forekomster av den typen.

Ris. 9.1.

I fig. Figur 9.1 viser essensen av AIRPORT med eksemplariske forekomster av Sheremetyevo og Heathrow. Dette primitive diagrammet formidler likevel viktig informasjon. For det første viser det at databasen vil inneholde samme type datastrukturer ( enhetsforekomster), som beskriver flyplasser. For det andre, siden det i livet er flere synspunkter på flyplasser (for eksempel synspunktet til en pilot, synspunktet til en passasjer, synspunktet til en administrator) og forskjellige datastrukturer tilsvarer disse synspunktene til visning, tillater de gitte eksemplene på flyplasser oss noe å begrense det akseptable settet med synspunkter. I vårt tilfelle er det gitt eksempler på internasjonale flyplasser, så det er mest sannsynlig et synspunkt fra en passasjer eller pilot på internasjonale flyvninger.

Når du definerer en enhetstype, må du sørge for at hver enhetsforekomst kan skilles fra enhver annen forekomst av samme enhet. Dette kravet ligner noe på kravet om at det ikke skal være dupliserte tupler i relasjonstabeller.

Forbindelse er en grafisk avbildet assosiasjon etablert mellom to enhetstyper. I likhet med en enhet er et forhold et generisk konsept; alle forekomster av begge tilknyttede typer enheter er underlagt etablerte tilknytningsregler. Derfor er det mer riktig å snakke om hvilken type forbindelse som er etablert mellom enhetstyper, og om tilkoblingstype forekomster, installert mellom forekomster av enhetstypen. 6Men som med enhetstype, vil vi ofte bruke begrepet relasjon til å bety relasjonstype. I versjonen av ER-modellen som er omtalt her, er denne assosiasjonen alltid binær og kan eksistere mellom to forskjellige enhetstyper eller mellom typen enhet og seg selv ( rekursiv forbindelse). I enhver forbindelse identifiseres to ender (i samsvar med det eksisterende paret av tilkoblede enheter), på hver av disse er navnet på enden av forbindelsen angitt, grad av slutt på forbindelsen(hvor mange forekomster av en gitt enhetstype må være til stede i hver forekomst av en gitt relasjonstype), obligatorisk kommunikasjon(dvs. om en instans av en gitt enhetstype må delta i en instans av en gitt relasjonstype). 7 I noen versjoner av ER-modellen kalles slutten av forbindelsen kommunikasjonsrollen i denne enheten. Da kan vi snakke om navnet på rollen, graden av rollen og forpliktelsen til kommunikasjonsrollen i denne enheten.

En forbindelse er representert som en urettet linje som forbinder to enheter eller leder fra en enhet til seg selv. I dette tilfellet, på tidspunktet for tilknytning til enheten, brukes følgende:

trepunktsinngang i et enhetsrektangel hvis forholdet kan (eller bør) bruke mange ( mange) enhetsforekomster ;
enkeltpunktinngang, hvis bare man kan (eller bør) delta i forbindelsen enhetsforekomst.

Den nødvendige enden av forbindelsen er avbildet med en heltrukket linje, og den valgfrie enden med en stiplet linje.

Forholdet mellom enhetene TICKET og PASSENGER, vist i fig. 9.2, kobler sammen billetter og passasjerer. En koblingsende kalt "for" lar mer enn én billett knyttes til samme passasjer, med hver billett assosiert med en annen passasjer. Slutten av lenken med navnet "har" indikerer at hver billett kun kan eies av én passasjer, og passasjeren er ikke pålagt å ha minst én billett.

Ris. 9.2.

Hver BILLETT er beregnet på én og kun én PASSASJER;
Hver PASSASJER kan ha en eller flere BILLETTER eller ingen i det hele tatt.

Følgende eksempel (fig. 9.3) viser rekursiv forbindelse, forbinder essensen av MAN med seg selv. Slutten av forbindelsen med navnet "sønn" definerer det faktum at flere personer kan være sønner av samme far. Slutten av forbindelsen med navnet "far" betyr at ikke enhver mann skal ha sønner.

En lakonisk muntlig tolkning av diagrammet som er avbildet er som følger:

hvert menneske er sønn av én og bare én MANN;
hver MANN kan være far til en eller flere MENN.

Entitetsattributt er enhver detalj som tjener til å klargjøre, identifisere, klassifisere, numerisk karakterisere eller uttrykke tilstanden til en enhet. Attributtnavn legges inn i et rektangel som viser

Logisk modell(Entitets)dataene er en uavhengig logisk representasjon av dataene.

Fysisk modell(Tabulære) data inneholder definisjoner av alle implementerte objekter i en bestemt database for en bestemt DBMS.

Modeller er hjørnesteinen i design. Ingeniører må bygge en modell av bilen og finne ut alle detaljene før de settes i produksjon. På samme måte utvikler systemingeniører først modeller for å studere forretningslogikken og utdype forståelsen av databasestrukturen.

I siste forelesning ble vi kjent med metodene IDEF0 og DFD, som lar oss beskrive forretningsprosesser som skjer i et informasjonssystem. I DFD-modellen betraktet vi et element – et datalager, som viser hvilke typer informasjon som systemet opererer på. Denne metodikken er imidlertid ikke ment å beskrive strukturen til lagret informasjon. Ulike Entity Relationship-diagrammer (entity-diagrammer) er mer egnet for dette, hvis formål er å beskrive strukturen til de lagrede dataene og relasjonene mellom dem. Det er utviklet metoder som lar deg konvertere slike data til et sett med kommandoer som vil skape nødvendig lagring (tabeller) i informasjonssystemdatabasen.

ER-modellering

I informasjonssystemer er data delt inn i separate kategorier eller enheter. Tross alt husker vi at en database er et sett med strukturerte data. Ulike typer data lagres separat. Oppgaven til ER-modellen er å vise hvilke typer informasjon som er lagret i systemet, hva deres struktur er og hvordan de henger sammen. ER-modellen er bygget på grunnlag av en forretningsanalyse (konstruert DF-diagram). I dette tilfellet blir i utgangspunktet hver butikk på DF-diagrammet en enhet på ER-diagrammet. Under videre analyse kan de brytes ned i sine komponentdeler. Det er verdt å merke seg at ER-modeller er mer motstandsdyktige mot endringer i forretningsstruktur enn DF-diagrammer. Forretningsprosesser kan endres, men informasjonen som trengs for å implementere dem forblir ofte uendret.

De viktigste fordelene med ER-modeller:

Et nøyaktig og forståelig format for å dokumentere informasjonsstrukturen.
Lar deg spesifisere krav til data og relasjoner mellom dem.
Lar deg tydelig vise lagringsstrukturen for å lette databasedesign.
Det finnes metoder for å kartlegge ER-modeller til databasetabeller og omvendt.
Legger grunnlaget for integrasjon med andre applikasjoner.

Hovedtypene av objekter i ER-diagrammet:

Entitet er en type objekter, informasjon om hvilke vil bli lagret i databasen. For eksempel: avdelinger, ansatte, varer, fakturaer.
Attributt - elementer som utgjør enheter. For eksempel, for «produkter»-enheten, kan attributtene være «navn», «beskrivelse», «mengde», «pris» og andre, avhengig av informasjonssystemets behov. Avhengig av notasjonen til ER-diagrammet, ved siden av attributtet, i tillegg til navnet, angi type og obligatorisk fylling. Lysbildet viser et ER-diagram i "Information Engineering"-notasjonen, i henhold til hvilket navn, type og om det er et eksternt og/eller primærkall er angitt for attributtet.
Relasjoner viser sammenhenger mellom enheter. For eksempel jobber en ansatt i en avdeling der "avdeling" og "avdeling" er enheter.

En enhet er et sett med objekter fra den virkelige verden, som hver har følgende egenskaper:

Unik (kan skilles fra alle andre på en eller annen måte)
Spiller en rolle i systemet som modelleres
Kan beskrives med én eller flere opplysninger (attributt)

Eksempel: personer, ansatte, arrangementer, bestillinger, salg, kunder, leverandører

Et attributt beskriver noen egenskaper til en enhet. En enhet kan ha mange attributter, men bare de som er viktige for systemet velges. Attributter er delt inn i nøkkel (Entity Keys) og beskrivende (Entity Descriptors). Nøkkelattributter må identifisere forekomster av en enhet unikt. For hvert attributt må et domene (type, emneområde) angis.

Lysbildet viser hvordan enheter og attributter er skrevet i ulike ER-modellnotasjoner. I alle notasjoner er en enhet et rektangulært formet objekt, øverst i hvilket navnet på enheten er angitt. Attributtene er oppført under enhetsnavnet.

La oss se nærmere på hva nøkkelegenskaper er. Dette er viktig for å forstå typene relasjoner mellom enheter.

Grunnleggende vilkår

Den relasjonsmodellen kan om nødvendig beskrives i matematisk språk, det vil si den mest nøyaktige oppfunnet av mennesket. Nedenfor følger løse definisjoner av noen begreper i relasjonsmodellen.

"Datatype" (type, domene - domene) - et sett med tillatte verdier ("domene") og operasjoner. Alle typer har sammenlignings- og tildelingsoperasjoner. Mengder er ikke forbudt å ha strukturen til for eksempel en gjenstand.
"Relasjon" (relasjon) - et sett med attributter: unike navn med avklaring av datatypen; pluss et sett med "verdisett" ("serier") som tilsvarer attributtene. Verdier i sett kan bare representeres av enkeltverdier av typene som tilsvarer attributtene, det vil si at de kan være skalarer ("første normalform").
"Nøkkel" (nøkkel) er en gruppe attributter hvis verdier i alle sett er forskjellige i forhold, men ikke en eneste undergruppe av disse attributtene har allerede en slik egenskap (nøkkelens "minimalitet"-egenskap). Spesielt kan en gruppe bestå av et enkelt attributt. En nøkkel i et forhold må alltid være tilstede, og hvis det er flere av dem, må en av dem betegnes som "primær".
"Fremmednøkkel" er en gruppe attributter hvis verdier i hvert sett med relasjonsverdier må falle sammen med verdiene til en nøkkel av muligens en annen relasjon. Fremmednøkler i en relasjon er valgfrie og deklareres i henhold til modelleringsbehov.
"Operasjoner" (operasjon) - et sett med generelle handlinger på relasjoner, som igjen resulterer i relasjoner ("lukkethet av operasjoner"). De brukes til å innhente nye relasjoner for behovene til etterfølgende modellering eller ved uttrekking av nødvendige data fra databasen. Listen over operasjoner kan defineres på forskjellige måter; i de første forslagene til modellen ble åtte operasjoner gitt (projeksjon, tilkobling, utvalg, etc.), ikke lenger et minimumssett, som et kompromiss mellom mangel på redundans og brukervennlighet.
" Relasjonsdatabase" (relasjonsdatabase) - et sett med relasjoner.

En "datatype" kalles noen ganger et "domene", men noen ganger refererer "domene" bare til "definisjonsdomenet" av verdier. Et "sett med mengder" (tuppel) på russisk kalles ellers en "tuppel" eller "n-coy".

For enkelhets skyld er relasjoner ofte avbildet i form av tabeller, selv om en slik representasjon er illegitim (verken rekkefølgen av attributter eller rekkefølgen av sett med verdier er definert i en relasjon, i motsetning til en tabell). I SQL, som Oracle DBMS er bygget på, erstattes konseptet "relasjon" som et modelleringsverktøy med "tabell". En annen representasjon av relasjonsdata kan være en hyperkube, og det er også noen ganger praktisk å ty til det i resonnement om en eksisterende database.

Hvis vi forlater det definerende sporingsordet "relasjonell", kan begrepet "relasjonsdatabase" oversettes til "relasjonsdatabase" (mer presist, "database bygget gjennom relasjoner"; relasjoner som et verktøy, ikke som et objekt for modellering: ellers ville det opprinnelige begrepet vært relasjonsdatabase). På samme måte kan begrepet "relasjonsmodell" oversettes til "relasjonsmodell", det vil si "en begrepssystem for å konstruere en modell av et fagområde i form av et sett relasjoner." Av en rekke grunner, inkludert historiske og språklige, ble dette ikke gjort på den tiden.

Alle dataforhold er beskrevet åpenbart Og bare verdier i sett (dette kan være annerledes i andre modelleringsmetoder). Det er ingen "underforståtte" avhengigheter (inkludert på nivået av programlogikk), bortsett fra relasjonene formulert av variabler. Den relasjonelle tilnærmingen skiller mellom beskrivelsen av data og programlogikken som følger med applikasjonen (i motsetning til for eksempel objekttilnærmingen).

Ovennevnte visning av en relasjonsdatabase (et sett med relasjoner og operasjoner) er typisk for relasjonsalgebra. Dette er ikke det eneste synspunktet. Hvert sett med verdier i en relasjonsvariabel kan forstås som en sann uttalelse ("predikat"): det er en slik og en ansatt med slike og slike egenskaper; slik og slik avdeling og så videre. Dermed representerer relasjonsdatabasen i hvert øyeblikk i tid et sett av sanne utsagn om fagområdet, formulert gjennom relasjoner. Faktisk danner et sett med utsagn i relasjonsvariabler en domenemodell representert av en database. Denne visningen av en relasjonsdatabase er typisk for relasjonsregning. Begge syn på relasjonsmodellen er godt studert og deres ekspressive ekvivalens er bevist.

For begrepene som er oppført på forrige lysbilde, er det uformelle ekvivalenter for å gjøre det lettere å forstå og huske betydningen:

Relasjon → Tabell
Tuple → String, ta opp
Kardinalitet → Antall linjer
Attributt → Kolonne, felt
Grad → Antall kolonner
Primærnøkkel → Identifikator
Domene → Utvalg av akseptable verdier

Nøkkelfelt

Noen av egenskapene til et forhold er nøkler eller nøkler. Det finnes flere typer nøkler:

En enkel nøkkel består av ett attributt, en sammensatt nøkkel består av flere.
Potensiell nøkkel- et attributt eller sett med attributter som kan identifisere hver av tuplene i en relasjon. For eksempel, i forhold til passkontoret («Passnummer») og («Fullt navn» og «Fødselsdato») er potensielle nøkler som lar deg identifisere hver person unikt.
Hvert forhold kan bare ha én primærnøkkel - et attributt eller sett med attributtverdier hvis verdier unikt identifiserer hver post. Hvis flere sett med attributter har slike egenskaper, velges en av dem som den primære, og alle de andre velges som alternative.
Utenlandsk nøkkel - butikker betydning den primære nøkkelen til en annen relasjon. Fremmednøkler brukes til å kommunisere mellom relasjoner.

Primærnøkkel

Hver relasjonsrelasjon har bare 1 primærnøkkel, alle andre er alternative nøkler.
Verdien av alle primærnøkkelattributter Ikke Kan være udefinert. For eksempel lagrer en relasjon informasjon om innbyggerne i en by. Primærnøkkelen er sammensatt (NAVN, ETTERNAVN, fødselsdato). Informasjonssystemet ble installert på Island, hvor de ikke bruker etternavn, noe som betyr at "etternavn"-attributtet vil være tomt for de fleste tupler. Til tross for dette vil den sammensatte primærnøkkelen fortsette å identifisere hver av tuplene unikt. Det er imidlertid uakseptabelt at verdiene til alle primærnøkkelattributter er tomme samtidig.
Verdien til primærnøkkelen påvirker ikke plasseringen av tuplene i tabellvisningen av forholdet. Selv om primærnøkkelverdien er et tall (for eksempel 1,2,3...) gir dette generelt ingen garanti for at tuplene i databasen er lagret i samme rekkefølge og vil bli sendt ut i samme rekkefølge. I det "generelle tilfellet" betyr det at noen ganger, på grunn av spesifikasjonene til en bestemt DBMS, kan rader lagres i rekkefølge etter primærnøkkelen, men dette er snarere et unntak. Når du sender ut spørringsresultater, må vi spesifisere eksplisitt rekkefølgen radene skal skrives ut i hvis den rekkefølgen er viktig. Resultatene av spørringen "gi meg de første 5 personene" er uforutsigbare hvis vi ikke spesifiserer etter hvilket kriterium de skal være "første".
Primærnøkkelen påvirker ikke tilgangen til attributtene til en tuppel. For eksempel, i forhold til "passkontoret", lagres personens registreringsadresse sammen med fullt navn og fødselsdato. Vi kan be databasen trekke ut alle adresser uten å vite fullt navn og fødselsdato.

Ekstern nøkkel

En fremmednøkkel brukes til å etablere forbindelser mellom relasjoner. La oss for eksempel ta to forhold "Eiere" (primærnøkkel "passnummer") og "Eiendom". For å fastslå hvem som eier hver eiendom, vil vi koble disse relasjonene med verdien av "passnummer"-attributtet. I motsetning til primærnøkkelen kan verdien av en fremmednøkkel være udefinert (linje 4 på lysbildet) - hvis vi ikke kjenner eieren av eiendommen, angir vi det ikke. I motsetning til primærnøkkelen, kan verdien av fremmednøkkelen gjentas (lager 1.3 på lysbildet) - én eier kan ha flere eiendomsobjekter. Det faktum at "passnummer"-attributtet i "Eiendom"-relasjonen er en fremmednøkkel til primærnøkkelen til "Eier"-forholdet, garanterer imidlertid at verdien av "pastornummer"-attributtet kun kan være verdier fra primærnøkkelen. Vi kan ikke spesifisere prestebolignummeret til en person som en attributtverdi som ikke allerede eksisterer i Eierrelasjonen (linje 5).

Ved å angi en fremmednøkkel, kan du eksplisitt angi oppførselen til DBMS hvis du endrer verdien på primærnøkkelen eller sletter en tuppel. Regelen "den fremmede nøkkelen lagrer bare verdiene som er i primærnøkkelen eller en udefinert verdi (NULL)" forblir den samme.

En fremmednøkkel mellom relasjoner er vanligvis spesifisert når du designer en database. Den kan imidlertid fjernes når som helst eller installeres på nytt hvis å legge til denne begrensningen ikke er i konflikt med egenskapene til fremmednøkkelen. Fjerning/installering av fremmednøkler gjøres vanligvis når du setter inn svært store datamengder, for å fremskynde denne prosessen - DBMS kan ikke lagre inkonsistente (feil, feilaktige) data, så den sjekker hver begrensning når den setter inn hver rad.

ER-modeller: tilkoblinger

I ER-modeller vises fremmednøkler som relasjoner.

Hver forbindelse er preget av 4 egenskaper - styrke, kraft, grad og deltakelse av enheten i forbindelsen.

La oss se på disse egenskapene.

Entitets deltakelse i forholdet

Indikert på forbindelsen med en tverrgående linje eller sirkel.

Tverrlinjen betyr påbudt, bindende (påbudt, bindende) enhetens deltakelse i forbindelsen, og sirkelen - valgfri (valgfri).

I tilfelle av obligatorisk deltakelse av en enhet i en forbindelse, verbet " må". Hvis enheten ikke nødvendigvis deltar i forbindelsen, vil verbet " Kan være".

På avdelingen Kan være ansette flere ansatte. Ansatt må arbeid i en av avdelingene.

Tilknytningsgrad ( forhold grad) angir antall tilknyttede enheter. Binær kommunikasjon ( binær forhold) beskriver assosiasjonen av to enheter. Ternær forbindelse (ternær forhold) oppstår når tre enheter er tilknyttet. Unær kommunikasjon (unær forhold) beskriver assosiasjoner innenfor en enkelt enhet.

De vanligste er binære forbindelser - de forbinder to forskjellige enheter ("Avdeling" - "Ansatt", "Ordre" - "Varer", "Kurs" - "Forelesninger", "Gruppe" - "Studenter"). Mindre vanlig, men fortsatt ofte brukt, er unære lenker. Med deres hjelp setter de vanligvis et nestforhold på gjenstander av samme type («Deler»-relasjonen - vi kan indikere hvilken del denne delen er en del av, «Ansatte»-relasjonen - vi kan indikere hvilken ansatt som er sjefen for denne).

Koblingsstyrke viser hvor mange forekomster av en enhet som er koblet til forekomster av en annen enhet.

Strøm kan være:

en til en(1:1) - det er en rektor i en gruppe studenter;
en-til-mange(1:N) - mange ansatte jobber i en avdeling;
mange-til-mange(M:N) - én kjøper kjøpte mange varer, mange kjøpere kjøpte varer.

Tilknytningsstyrke: sterk tilknytning (identifiserende forhold)

En underordnet enhet kan ikke eksistere uten en overordnet enhet. (Det er ikke noe svar uten et spørsmål; det er ikke noe produkt i brukerens handlekurv hvis selve handlekurven ikke eksisterer)

I dette tilfellet migrerer primærnøkkelen fra den overordnede enheten til den underordnede enheten, hvor den blir en del av primærnøkkelen.

I et diagram er et sterkt forhold representert av en ubrutt linje mellom enheter.

Relasjonsstyrke: Ikke-identifiserende forhold

Den overordnede og underordnede enheten er relatert, men den underordnede enheten kan opprettes først. (Lasten tilhører ordren, men lasten kan være på lageret før ordren opprettes).

Primærnøkkelen migrerer fra den overordnede enheten til den underordnede enheten og er ikke en del av primærnøkkelen (den blir ganske enkelt en fremmednøkkel).

I diagrammet er et sterkt forhold representert med en stiplet linje mellom enheter.

Rekursiv kobling (unær kobling)

Oftest brukt til å bygge hierarkier.

En leverandør KAN jobbe med NULL eller FLERE kunder (id_Customer).

Kunden MÅ samarbeide med én leverandør (id_Sup).

Men leverandøren og kunden – enten det er en bedrift eller en organisasjon – er gjenstander av samme type og er derfor lagret i samme relasjon.

Mange-til-mange kommunikasjon.

Eksempel: Leverandører kan levere mange typer varer. Ulike leverandører kan levere samme type varer.

Mange-til-mange-relasjoner er gyldige fra ER-modellens synspunkt, men kan ikke reflekteres direkte i forhold til relasjonsalgebra.

Tvetydigheten i forholdet løses ved å introdusere overgangsenheter, som vist på lysbildet.

ER-modeller og virkelighet

Ved nærmere inspeksjon av en en-til-en-relasjon viser det seg nesten alltid at A og B faktisk er forskjellige undergrupper av den samme tingen, eller forskjellige perspektiver på den, bare de har forskjellige navn og ulikt beskrevne relasjoner og attributter.

La oss forestille oss at A er leverandøren, B er produktet.

Obligatorisk-obligatorisk. For eksempelet vist på lysbildet betyr dette forholdet at hver Leverandør må leverer kun én unik sett med varer (Faktura). Fra et teoretisk synspunkt er alt bra her. I praksis er dette ikke akseptabelt: ingen vil se etter en ny leverandør hvis leverandøren du har verifisert kan tilby flere produktserier. Og nå om følelsene operatøren vil oppleve når han prøver å legge inn data om en ny leverandør. Han vil ikke kunne legge inn data i noen av tabellene. Så all bagasjen med uanstendig språk vil bli rettet mot deg.

Valgfritt-obligatorisk. Et eksempel på tilkoblingen er vist på lysbildet. Som vi kan se, er alt bra med operatøren nå: han kan legge inn data. Virksomheten har igjen et problem: den må se etter en ny leverandør, selv om leverandøren du har verifisert kan levere flere produktlinjer. Trenger virksomheten problemer? Nei. Den må fungere. Hvordan tilfredsstille en bedrift? Svaret er enkelt. Når du designer en database, må du tenke på normalisering. Hvis leverandøren er en enhet, bruk valgfrie-obligatoriske (obligatoriske-valgfrie) eller valgfrie-valgfrie relasjoner. Selv om oftest en-til-en-forhold er en feil.

Valgfritt-valgfritt. Som vi ser går det bra igjen med operatøren, men virksomheten har igjen et problem. La oss oppsummere for en-til-en kommunikasjon. Hvis enheter deltar i en forbindelse som: - obligatorisk-obligatorisk, har en slik forbindelse ingen rett til liv; - valgfritt-obligatorisk (obligatorisk-valgfritt) eller valgfritt-valgfritt, da er forretningsstøtte problematisk.

En en-til-mange obligatorisk-obligatorisk relasjon er en ganske sterk konstruksjon som innebærer at en forekomst av entitet B ikke kan opprettes uten samtidig å skape minst en forekomst av entitet A knyttet til den. Oftest er dette en feil relasjon.

Et en-til-mange obligatorisk-valgfritt forhold er den vanligste formen for forhold. Den forutsetter at hver eneste forekomst av enhet A kan eksistere kun i sammenheng med én (og bare én) forekomst av enhet B. I sin tur kan forekomster av B eksistere enten med eller uten forekomster av A.

En-til-mange-forhold valgfritt-valgfritt - Både A og B kan eksistere uten et forhold mellom dem.

Når det gjelder det forrige lysbildet, kan disse diagrammene illustreres med følgende eksempler.

En-til-mange forhold. Disse relasjonene innebærer at én post i én tabell kan være logisk relatert til flere poster i en annen tabell.

Obligatorisk-obligatorisk. For eksempelet vist på lysbildet betyr dette forholdet at hver leverandør (A) må levere ett eller flere sett med varer (B). Fra et teoretisk synspunkt er alt bra her. Men i praksis vil operatøren ikke kunne legge inn data i noen av tabellene, siden postene må være det samtidig gå inn i begge tabellene.

Valgfritt-obligatorisk. I dette tilfellet er alt bra for operatøren: han kan legge inn data, men virksomheten kan ha problemer. Poenget er at det valgfritt-obligatoriske forholdet forutsetter at leverandøren (A) må levere ett eller flere sett med varer (B), mens B Kan være tilhører leverandøren. Med andre ord kan varer eksistere uten leverandør mens leverandøren har varene. De. ukontrollert forretningsatferd er mulig: hvem leverte varene? Hvem skal jeg spørre? Trenger virksomheten problemer? Nei. Det må gi overskudd. I dette tilfellet er det bedre å bruke obligatorisk-valgfritt: Leverandøren kan levere ett eller flere sett med varer, mens varene må tilhøre leverandøren. Med andre ord har produktet en leverandør, og data om leverandørene som en gang leverte produktet vil bli lagret. Og sauene er trygge og ulvene blir matet - operatøren kan legge inn data og forretningsmannen er orientert.

Valgfritt-valgfritt. Som vi ser er alt bra med operatøren igjen, men virksomheten har et problem – mangel på kontroll: Et produkt kan eksistere uten en leverandør og en leverandør uten et produkt.
La oss oppsummere for en-til-mange-kommunikasjon. Hvis enheter deltar i et forhold som: - obligatorisk-obligatorisk, har et slikt forhold ingen rett til liv, siden det er umulig å legge inn poster samtidig i begge tabellene; - valgfritt-valgfritt, da er forretningsstøtte problematisk.

Mange-til-mange-relasjoner er tillatt i ER-diagrammer, men når de konverteres til en tabellvisning, erstattes relasjonen med en mellomliggende enhet.

Mange-til-mange obligatorisk-obligatorisk - denne konstruksjonen forekommer ofte i begynnelsen av analysestadiet og betyr et forhold - enten ikke fullt ut forstått og krever ytterligere oppløsning, eller gjenspeiler et enkelt kollektivt forhold - en toveis liste.

Mange-til-mange obligatorisk-valgfritt - brukes sjelden. Slike forbindelser er alltid gjenstand for ytterligere detaljer.

Rekursive sammenhenger. Disse relasjonene antyder at tabelloppføringer kan være logisk relatert til hverandre.

Valgfritt-valgfritt en-til-en. For eksempelet vist på lysbildet betyr dette forholdet at enhver mann (kvinne) kan være gift med én kvinne (mann). Denne forbindelsen er praktisk for å spore historien til de som gifter seg: for første gang, igjen, ... Med andre ord, en alternativ type forhold.

Valgfritt-valgfritt en-til-mange. Et eksempel på tilkoblingen er vist på lysbildet. Dette er et klassisk hierarki (trestruktur). Relasjonen som vises på lysbildet kan for eksempel tolkes som følger: enhver ansatt kan rapportere til kun én leder, mens en leder kan administrere én eller flere ansatte.

Valgfritt-valgfritt M:M Et eksempel på kommunikasjon er vist på lysbilde 3. Dette er en nettverksstruktur.

Sjekkliste for enhetsspørsmål

Gjenspeiler enhetsnavnet essensen av dette objektet?
Er det noen overlapping med andre enheter?
Er det minst to attributter?
Det er ikke mer enn åtte attributter totalt?
Finnes det noen synonymer/homonymer for denne enheten?
Er enheten fullstendig definert?
Finnes det en unik identifikator?
Er det minst én forbindelse?
Er det minst én funksjon for å opprette, søke, redigere, slette, arkivere og bruke en enhetsverdi?
Er det en historie med endringer?
Er det samsvar med datanormaliseringsprinsipper?
Er det samme enhet i et annet applikasjonssystem, kanskje under et annet navn?
Er essensen for generell?
Er nivået av generalisering nedfelt i den tilstrekkelig?

Sjekkliste for attributter:

Er attributtnavnet et entallssubstantiv som gjenspeiler essensen av egenskapen angitt av attributtet?
Inkluderer ikke attributtnavnet enhetsnavnet (det burde det ikke)?
Har et attributt bare én verdi om gangen?
Er det noen dupliserte verdier (eller grupper)?
Er format, lengde, akseptable verdier, akkvisisjonsalgoritme osv. beskrevet?
Kan dette attributtet være en manglende enhet som vil være nyttig for et annet applikasjonssystem (eksisterende eller foreslått)?
Kan han være en tapt forbindelse?
Er det en referanse et sted til et attributt som en "designfunksjon" som skal forsvinne når du flytter til applikasjonsnivå?
Er det behov for en endringshistorikk?
Avhenger dens betydning bare av denne enheten?
Hvis attributtens verdi kreves, er den alltid kjent?
Er det behov for å opprette et domene for denne og lignende attributter?
Avhenger verdien bare av en del av den unike identifikatoren?
Er verdien avhengig av verdiene til noen attributter som ikke er inkludert i den unike identifikatoren?

Den konseptuelle databasemodellen er

En konseptuell modell er et slags visuelt diagram, tegnet i akseptert notasjon og viser i detalj forholdet mellom objekter og deres egenskaper. Det lages en konseptuell modell for videre databasedesign og dens oversettelse, for eksempel til en relasjonsdatabase. Den konseptuelle modellen skildrer sammenhenger mellom dataobjekter og deres egenskaper i en visuelt praktisk form.

Aksepterte definisjoner i konseptdatabasen

For ensartethet i databaseprogrammering er følgende konsepter introdusert for konseptuelle databaser:

Objekt eller enhet. Dette er den faktiske tingen eller objektet (for mennesker) som brukeren (kunden) ønsker å observere. For eksempel Ivanov Ivan Ivanovich;
Egenskap dette er en egenskap ved et objekt som tilsvarer dets essens. For eksempel. Vi stiller oss selv spørsmålet: Hvilken informasjon skal lagres om Ivan Ivanovich Ivanov? Svarene på dette spørsmålet vil være egenskapene til objektet Ivan Ivanovich Ivanov;
Det tredje konseptet i konseptuell databasedesign er forbindelse eller forhold mellom objekter.

Leksisk er det mer korrekt å si sammenhengen mellom CBD-objekter og forholdet mellom CBD-entiteter (konseptuell database), men du kan finne en rekke kombinasjoner av entitet, objekt, forbindelse og relasjon (oversettelsesfeil).

Konseptuell databasemodellforklaring

Konseptuell databasemodell: Vanlige grafiske notasjoner

Et enhets-/relasjonsdiagram (objekt/relasjon) kalles et ER-diagram eller EDR (entity-relationship diagram). Selve enhetsforholdsmodellen ble foreslått av professor Peter Pin-Shen Chen i 1976. Skrivereglene og konvensjonene til et ER-diagram kalles notasjon. Det er to vanlige notasjoner for ER-diagrammer:

Notasjon av Peter Chen;
Gordon Everest-notasjon. Kalt kråkefot eller gaffel.

ER-diagramnotasjon ifølge Peter Chen

Chen foreslo og vedtok følgende konvensjoner for ER-diagrammer:

En enhet eller et objekt er merket med et rektangel;
Relasjoner er betegnet med en diamant;
Attributter til objekter er indikert med en oval;
Hvis en enhet er assosiert med en relasjon, er relasjonen deres indikert med en rett linje med en pil. Et valgfritt forhold er indikert med en stiplet linje. En kraftig forbindelse er indikert med en dobbel linje.

Hvert attributt kan assosieres med ett objekt (entitet).

Gordon Everest-notasjon

Gordon Everest introduserte en ny betegnelse for forbindelser, som ble kalt gafler eller kråkeføtter. Han introduserte også at et objekt skulle representeres av et rektangel med navnet på objekttypen som et substantiv inne i rektangelet. Dessuten må dette navnet være unikt i databasen som opprettes.

Attributter er ikke atskilt i en egen figur, men passer inn i objektets rektangel som et substantiv med et kvalifiserende ord.

Forbindelsen mellom objekter er indikert med en rett linje. Flere bindinger er indikert med en gaffel på slutten. Selve forbindelsen er signert med et verb, for eksempel "Inkluderer" eller "Hører til."

konseptuell modell av ERD Fork-databasen

Tillegg

Attributter i et ER-diagram kan ha sine egne attributter (sammensatt) attributt.

Et enkelt ER-diagram er ganske enkelt å tegne. Et rikt, tredimensjonalt ER-diagram er en annen sak. Nedenfor er noen tips for å hjelpe deg med å bygge effektive ER-diagrammer:

Identifiser alle objektene i et gitt system og definer relasjonene mellom disse objektene;
Et objekt må bare vises én gang på et bestemt sted i diagrammet;
Definer et nøyaktig og passende navn for hvert objekt, attributt og forhold i diagrammet. Velg enkle og forståelige ord. Ord som er enkle og velkjente vinner alltid over vage, teknisk klingende ord. For objekter, substantiv, for sammenhenger, verb (med mulige forklaringer). Ikke glem det unike med objektnavn;
Fjern implisitte, overflødige eller unødvendige relasjoner mellom objekter;
Koble aldri et forhold til et annet forhold;
Bruk farger for å kategorisere lignende objekter eller fremheve nøkkelområder i et diagram.

[redigere]

Materiale fra Wikipedia - det frie leksikonet

Dette begrepet har andre betydninger, se ER.

Entitetsrelasjonsmodell (ER-modell)(Engelsk) enhet-relasjonsmodell, ERM) er en datamodell som lar deg beskrive konseptuelle diagrammer av et fagområde.

ER-modellen brukes i høynivå (konseptuell) databasedesign. Med dens hjelp kan du identifisere nøkkelenheter og identifisere forbindelser som kan opprettes mellom disse enhetene.

Under databasedesign konverteres ER-modellen til et spesifikt databaseskjema basert på den valgte datamodellen (relasjonell, objekt, nettverk, etc.).

ER-modellen er en formell design, som i seg selv ikke foreskriver noen grafiske midler for visualisering. Som en standard grafisk notasjon for å visualisere ER-modellen, har den blitt foreslått enhetsforholdsdiagram (ER-diagram)(Engelsk) enhetsforholdsdiagram,ERD).

Begreper ER-modell Og ER-diagram ofte feilaktig ikke skilt ut, selv om andre grafiske notasjoner har blitt foreslått for å visualisere ER-modeller (se nedenfor).

Skapelseshistorie[rediger]

Entitetsforholdsmodellen ble foreslått i 1976 av Peter Ping-Shen Chen. Peter Pin-Shen Chen hør), amerikansk professor i informatikk ved Louisiana State University.

Notasjoner[rediger]

Peter Chen-notasjon

En enkel MMORPG ER-modell som bruker Peter Chens notasjon

Sett med enheter er avbildet som rektangler, sett med relasjoner er avbildet som diamanter. Hvis en enhet er involvert i et forhold, er de forbundet med en linje. Hvis forholdet er valgfritt, er linjen stiplet. Attributter er avbildet som ovaler og er forbundet med en linje til ett forhold eller en enhet.

Kråkefot[rediger]

Et eksempel på et forhold mellom enheter i henhold til Crow's Foot-notasjon

Denne notasjonen ble foreslått av Gordon Everest. Gordon Everest) kalt Inverted Arrow ("invertert pil"), men nå oftere kalt Crow's Foot ("kråkefot") eller Fork ("gaffel").

I følge denne notasjonen, essens er avbildet som et rektangel som inneholder navnet hennes, uttrykt som et substantiv. Enhetsnavnet må være unikt innenfor samme modell. Samtidig er enhetsnavnet navnet på typen, og ikke en spesifikk forekomst av denne typen. En enhetsinstans er en spesifikk representant for den enheten.

Forbindelse representert av en linje som forbinder to enheter involvert i et forhold. Graden av terminering av en binding er indikert grafisk, hvor mangfoldet av bindingen er avbildet som en "gaffel" på slutten av bindingen. Modaliteten til forbindelsen er også avbildet grafisk - valgmuligheten til forbindelsen er markert med en sirkel på slutten av forbindelsen. Navngivelse uttrykkes vanligvis med ett verb i den nåværende indikative stemningen: "Har", "Hører til", etc.; eller et verb med forklarende ord: "Inkluderer" osv. Navnet kan være ett for hele forbindelsen eller to for hver ende av forbindelsen. I det andre tilfellet er navnet på den venstre enden av forbindelsen angitt over kommunikasjonslinjen, og navnet på den høyre enden er angitt under linjen. Hvert av navnene er plassert ved siden av enheten det refererer til.

Attributter enheter er skrevet inne i et rektangel som viser enheten og uttrykkes med et entallssubstantiv (eventuelt med kvalifiserende ord). Blant attributtene skiller enhetsnøkkelen seg ut - et ikke-overflødig sett med attributter, hvis verdier sammen er unike for hver forekomst av enheten.

6.2.2. Grunnleggende begreper i Entity-Relationship-modellen

De fleste moderne tilnærminger til databasedesign (hovedsakelig relasjonell) er basert på bruk av varianter av ER-modellen. Modellen ble foreslått av Chen i 1976. Domenemodellering er basert på bruk av grafiske diagrammer som inkluderer et lite antall heterogene komponenter. På grunn av klarheten i presentasjonen av konseptuelle databasediagrammer, har ER-modeller blitt utbredt i CASE-systemer som støtter datastøttet design av relasjonsdatabaser. Blant de mange variantene av ER-modeller brukes en av de mest utviklede i CASE-systemet fra ORACLE. Vi vil vurdere det. Mer presist vil vi fokusere på den strukturelle delen av denne modellen.

Hovedkonseptene i ER-modellen er enhet, relasjon og attributt.

En enhet er et reelt eller tenkelig objekt som informasjon må lagres og tilgjengelig om. I ER-modelldiagrammer er en enhet representert som et rektangel som inneholder navnet på enheten. I dette tilfellet er navnet på enheten navnet på typen, og ikke en spesifikk forekomst av denne typen. For større uttrykksevne og bedre forståelse kan enhetsnavnet ledsages av eksempler på spesifikke objekter av denne typen.

Nedenfor er en AIRPORT-enhet med eksempler på Sheremetyevo- og Heathrow-objekter:

Hver forekomst av en enhet må kunne skilles fra alle andre forekomster av samme enhet (dette kravet er noe analogt med kravet om at det ikke er dupliserte tupler i relasjonstabeller).

Et forhold er en grafisk representert assosiasjon etablert mellom to enheter. Denne assosiasjonen er alltid binær og kan eksistere mellom to forskjellige enheter eller mellom en enhet og seg selv (rekursivt forhold). I enhver forbindelse identifiseres to ender (i samsvar med det eksisterende paret av tilkoblede enheter), som hver indikerer navnet på slutten av forbindelsen, graden av slutten av forbindelsen (hvor mange forekomster av denne enheten er koblet til ), den obligatoriske karakteren av forbindelsen (dvs. om noen forekomst av denne enheten må delta i denne forbindelse).

En forbindelse er representert som en linje som forbinder to enheter eller leder fra en enhet til seg selv. I dette tilfellet, på punktet der forbindelsen "føyes sammen" med enheten, brukes en trepunktsinngang i enhetsrektangelet, hvis mange forekomster av enheten kan brukes for denne enheten i forbindelsen, og et enkeltpunkt oppføring, hvis bare én forekomst av enheten kan delta i forbindelsen. Den nødvendige enden av forbindelsen er avbildet med en heltrukket linje, og den valgfrie enden med en brutt linje.

Som en enhet er et forhold et generisk konsept; alle forekomster av begge par av relaterte enheter er underlagt reglene for tilknytning.

I eksemplet nedenfor knytter forholdet mellom enhetene TICKET og PASSENGER sammen billetter og passasjerer. Dessuten lar slutten av enheten med navnet "for" deg knytte mer enn én billett til én passasjer, og hver billett må være knyttet til en passasjer. Enden på enheten som heter "har" betyr at hver billett bare kan eies av én passasjer, og passasjeren er ikke pålagt å ha minst én billett.