Forholdsmodell - Relational model

Den relasjonsmodellen ( RM ) for databaseadministrasjon er en tilnærming til å administrere data ved hjelp av en struktur og språk som er i samsvar med første ordens predikatlogikk , først beskrevet i 1969 av den engelske informatikeren Edgar F. Codd , hvor alle data er representert i form av tupler , gruppert i relasjoner . En database organisert i forhold til relasjonsmodellen er en relasjonsdatabase .

Formålet med relasjonsmodellen er å gi en deklarativ metode for å spesifisere data og spørringer: brukere oppgir direkte hvilken informasjon databasen inneholder og hvilken informasjon de vil ha fra den, og la databasestyringsprogramvaren ta seg av å beskrive datastrukturer for lagring av data og prosedyrer for henting av spørsmål.

De fleste relasjonsdatabaser bruker SQL -datadefinisjonen og spørrespråket; disse systemene implementerer det som kan betraktes som en teknisk tilnærming til relasjonsmodellen. En tabell i et SQL -databaseskjema tilsvarer en predikatvariabel; innholdet i en tabell til en relasjon; nøkkelbegrensninger, andre begrensninger og SQL -spørringer tilsvarer predikater. Imidlertid avviker SQL -databaser fra relasjonsmodellen i mange detaljer , og Codd argumenterte hardt mot avvik som kompromitterer de opprinnelige prinsippene.

Oversikt

Den relasjonelle modellens sentrale idé er å beskrive en database som en samling predikater over et begrenset sett med predikatvariabler, som beskriver begrensninger for mulige verdier og kombinasjoner av verdier. Innholdet i databasen til enhver tid er en endelig (logisk) modell av databasen, dvs. et sett med relasjoner , en per predikatvariabel, slik at alle predikater blir tilfredsstilt. En forespørsel om informasjon fra databasen (en databasespørring ) er også et predikat.

Alternativer

Andre modeller inkluderer den hierarkiske modellen og nettverksmodellen . Noen systemer som bruker disse eldre arkitekturen er fremdeles i bruk i dag i datasentre med høye datavolumbehov, eller der eksisterende systemer er så komplekse og abstrakte at det ville være kostnadsforbudende å migrere til systemer som bruker relasjonsmodellen. Nyere objektorienterte databaser er også viktige .

Gjennomføring

Det har vært flere forsøk på å produsere en sann implementering av den relasjonsbaserte databasemodellen slik den opprinnelig ble definert av Codd og forklart av Date , Darwen og andre, men ingen har blitt populære suksesser så langt. Fra oktober 2015 er Rel et av de nyere forsøkene på å gjøre dette.

Relasjonsmodellen var den første databasemodellen som ble beskrevet i formelle matematiske termer. Hierarkiske og nettverksdatabaser eksisterte før relasjonsdatabaser, men spesifikasjonene deres var relativt uformelle. Etter at relasjonsmodellen ble definert, var det mange forsøk på å sammenligne og kontrastere de forskjellige modellene, og dette førte til fremveksten av strengere beskrivelser av de tidligere modellene; selv om datamanipuleringsgrensesnittets prosessuelle karakter for hierarkiske og nettverksdatabaser begrenset muligheten for formalisering.

Strukturell databaseanalyse som bruker relasjonsmodalitetsprotokoller bruker ofte datasekvensdifferensialer for å opprettholde hierarkiske arkitekturbetegnelser med inkorporering av nye input. Disse systemene er funksjonelt like i konseptet som alternative reléalgoritmer, som danner grunnlaget for skydatabaseinfrastruktur .

Historie

Den relasjonsmodellen ble oppfunnet av Edgar F. Codd som en generell datamodell, og deretter promotert av blant andre Chris Date og Hugh Darwen . I The Third Manifesto (første gang utgitt i 1995) forsøker Date og Darwen å vise hvordan relasjonsmodellen angivelig kan imøtekomme visse "ønskede" objektorienterte trekk.

Kontroverser

Noen år etter publiseringen av 1970-modellen hans, foreslo Codd en treverdig logisk (True, False, Missing/ NULL ) versjon av den for å håndtere manglende informasjon, og i sin The Relational Model for Database Management Version 2 (1990) gikk han et skritt videre med en logi med fire verdier (True, False, Missing but Applicable, Missing but Inapplicable). Disse har aldri blitt implementert, antagelig på grunn av kompleksitet. SQLs NULL-konstruksjon var ment å være en del av et logisk system med tre verdier, men falt ikke på grunn av logiske feil i standarden og implementeringene.

Emner

Den grunnleggende antagelsen til den relasjonelle modellen er at alle data er representert som matematiske n - ary -relasjoner , et n -ary -forhold er en undersett av det kartesiske produktet av n -domener. I den matematiske modellen blir resonnement om slike data gjort i toverdig predikatlogikk , noe som betyr at det er to mulige evalueringer for hvert forslag : enten sant eller usant (og spesielt ingen tredje verdi som ukjent , eller ikke relevant , hvorav begge er ofte forbundet med begrepet NULL ). Data opereres ved hjelp av en relasjonsberegning eller relasjonsalgebra , disse er ekvivalente i uttrykkskraft .

Den relasjonelle datamodellen gjør det mulig for databasedesigneren å lage en konsekvent, logisk representasjon av informasjon . Konsistens oppnås ved å inkludere deklarerte begrensninger i databasedesignet, som vanligvis kalles det logiske skjemaet . Teorien inkluderer en normaliseringsprosess der et design med visse ønskelige egenskaper kan velges fra et sett med logisk likeverdige alternativer. De tilgangsplaner og andre implementering og drift detaljer håndteres av DBMS motor, og er ikke reflektert i den logiske modell. Dette står i kontrast til vanlig praksis for SQL DBMS der ytelsesjustering ofte krever endringer i den logiske modellen.

Den grunnleggende relasjonelle byggeklossen er domenet eller datatypen , vanligvis forkortet i dag for å skrive . En tupel er et ordnet sett med attributtverdier . Et attributt er et ordnet par med attributtnavn og type navn . En attributtverdi er en spesifikk gyldig verdi for attributtypen. Dette kan enten være en skalarverdi eller en mer kompleks type.

Et forhold består av en overskrift og en kropp . En overskrift er et sett med attributter. En kropp (av en n -ary -relasjon) er et sett med n -par. Overskriften til forholdet er også overskriften til hver av dens tupler.

En relasjon er definert som et sett med n -tupler. I både matematikk og den relasjonsbaserte databasemodellen er et sett en uordnet samling av unike, ikke-dupliserte elementer, selv om noen DBMS pålegger dataene deres en ordre. I matematikk har en tupel en ordre, og tillater duplisering. E.  F. Codd definerte opprinnelig tuples ved å bruke denne matematiske definisjonen. Senere var det en av E.  F. Codds store innsikt i at bruk av attributtnavn i stedet for en bestilling ville være mer praktisk (generelt) på et dataspråk basert på relasjoner. Denne innsikten blir fortsatt brukt i dag. Selv om konseptet har endret seg, har ikke navnet "tuple" det. En umiddelbar og viktig konsekvens av dette særtrekk er at i relasjonsmodellen det kartesiske produktet blir kommutative .

Et bord er en akseptert visuell fremstilling av en relasjon; en tupel ligner konseptet med en rad .

En relvar er en navngitt variabel av en bestemt relasjonstype, som til enhver tid er tilordnet en relasjon av den typen, selv om relasjonen kan inneholde null tupler.

Det grunnleggende prinsippet for den relasjonelle modellen er informasjonsprinsippet : all informasjon er representert med dataverdier i relasjoner. I samsvar med dette prinsippet er en relasjonsdatabase et sett med relvarser og resultatet av hver forespørsel presenteres som en relasjon.

Konsistensen til en relasjonsdatabase håndheves, ikke av regler som er innebygd i programmene som bruker den, men snarere av begrensninger , deklarert som en del av det logiske skjemaet og håndhevet av DBMS for alle applikasjoner. Generelt uttrykkes begrensninger ved hjelp av relasjonelle sammenligningsoperatorer, hvorav bare en, "er delsett av" (⊆), er teoretisk tilstrekkelig. I praksis forventes det at flere nyttige stenografier er tilgjengelige, hvorav de viktigste er kandidatnøkkelen (egentlig supernøkkel ) og utenlandske nøkkelbegrensninger .

Tolkning

For fullt å sette pris på den relasjonelle datamodellen er det viktig å forstå den tiltenkte tolkningen av et forhold .

Kroppen til en relasjon kalles noen ganger dens forlengelse. Dette er fordi det skal tolkes som en representasjon av forlengelsen av et eller annet predikat , dette er settet med sanne proposisjoner som kan dannes ved å erstatte hver ledige variabel i det predikatet med et navn (et begrep som angir noe).

Det er en en-til-en-korrespondanse mellom predikatets frie variabler og attributtnavnene på relasjonsoverskriften. Hver tuppel av relasjonskroppen gir attributtverdier for å instantisere predikatet ved å erstatte hver av de frie variablene. Resultatet er et forslag som på grunn av tupelens utseende i relasjonskroppen anses å være sant. På den annen side anses hver tupel hvis overskrift samsvarer med forholdet, men som ikke vises i kroppen som falsk. Denne antagelsen er kjent som den lukkede verdens antagelse : den blir ofte krenket i praktiske databaser, der fraværet av en tupel kan bety at sannheten i den tilsvarende proposisjonen er ukjent. For eksempel kan fraværet av tupelen ('John', 'spansk') fra en tabell med språkkunnskaper ikke nødvendigvis tas som bevis på at John ikke snakker spansk.

For en formell redegjørelse for disse ideene, se avsnittet Set-teoretisk formulering nedenfor.

Søknad til databaser

En datatype som brukes i en typisk relasjonsdatabase kan være settet med heltall, settet med tegnstrenger, settet med datoer eller de to boolske verdiene true og false , og så videre. De tilsvarende typene for disse typene kan være strengene "int", "char", "date", "boolean", etc. Det er imidlertid viktig å forstå at relasjonsteori ikke dikterer hvilke typer som skal støttes; faktisk forventes det i dag at bestemmelser vil være tilgjengelige for brukerdefinerte typer i tillegg til de innebygde som tilbys av systemet.

Attributt er begrepet som brukes i teorien for det som vanligvis kalles en kolonne . På samme måte brukes tabellen vanligvis i stedet for det teoretiske begrepet relasjon (selv om begrepet i SQL på ingen måte er synonymt med relasjon). En tabelldatastruktur er spesifisert som en liste over kolonnedefinisjoner, som hver spesifiserer et unikt kolonnenavn og typen verdier som er tillatt for den kolonnen. En attributtverdi er inngangs i en bestemt kolonne og rad, slik som "John Doe" eller "35".

En tupel er i utgangspunktet det samme som en rad , bortsett fra i et SQL DBMS, der kolonneverdiene i en rad er ordnet. (Tupler er ikke ordnet; i stedet identifiseres hver attributtverdi utelukkende med attributtnavnet og aldri ved sin ordinære posisjon i tupelen.) Et attributtnavn kan være "navn" eller "alder".

En relasjon er en tabellstrukturdefinisjon (et sett med kolonnedefinisjoner) sammen med dataene som vises i den strukturen. Strukturdefinisjonen er overskriften, og dataene som vises i den er kroppen , et sett med rader. En database relvar (relasjonsvariabel) er kjent som en basistabell . Overskriften til den tildelte verdien når som helst er som angitt i tabelldeklarasjonen, og dens brødtekst er den som sist ble tildelt den ved å påkalle en oppdateringsoperatør (vanligvis INSERT, UPDATE eller DELETE). Overskriften og brødteksten i tabellen som følge av evaluering av noen spørringer, bestemmes av definisjonene til operatørene som brukes i uttrykket for den spørringen. (Vær oppmerksom på at overskriften i SQL ikke alltid er et sett med kolonnedefinisjoner som beskrevet ovenfor, fordi det er mulig for en kolonne å ikke ha noe navn og at to eller flere kolonner har samme navn. Dessuten er brødteksten ikke alltid et sett med rader fordi det i SQL er mulig for den samme raden å vises mer enn én gang i samme brødtekst.)

SQL og relasjonsmodellen

SQL, opprinnelig presset som standardspråk for relasjonsdatabaser , avviker fra relasjonsmodellen flere steder. Den nåværende ISO SQL -standarden nevner ikke relasjonsmodellen eller bruker relasjonelle termer eller konsepter. Imidlertid er det mulig å opprette en database som samsvarer med relasjonsmodellen ved hjelp av SQL hvis man ikke bruker visse SQL -funksjoner.

Følgende avvik fra relasjonsmodellen har blitt notert i SQL. Vær oppmerksom på at få databaseservere implementerer hele SQL -standarden og spesielt ikke tillater noen av disse avvikene. Mens NULL er allestedsnærværende, er det for eksempel uvanlig å tillate dupliserte kolonnenavn i en tabell eller anonyme kolonner.

Dupliser rader

Den samme raden kan vises mer enn én gang i en SQL -tabell. Den samme tupelen kan ikke vises mer enn én gang i et forhold .

Anonyme spalter

En kolonne i en SQL -tabell kan være uten navn og kan derfor ikke refereres til i uttrykk. Den relasjonsmodellen krever at alle attributter er navngitt og refererbare.

Dupliser kolonnenavn

To eller flere kolonner i samme SQL -tabell kan ha samme navn og kan derfor ikke refereres på grunn av den åpenbare tvetydigheten. Den relasjonsmodellen krever at alle attributter kan refereres til.

Spalteordens betydning

Rekkefølgen på kolonner i en SQL -tabell er definert og signifikant, en konsekvens er at SQLs implementeringer av kartesisk produkt og union ikke er kommutative. Den relasjonsmodellen krever at det ikke er noen betydning for noen rekkefølge av attributtene til en relasjon.

Visninger uten CHECK OPTION

Oppdateringer av en visning definert uten CHECK OPTION kan godtas, men den resulterende oppdateringen til databasen har ikke nødvendigvis den uttrykte effekten på målet. For eksempel kan en påkallelse av INSERT godtas, men det er ikke sikkert at de innsatte radene vises i visningen, eller at en påkalling av OPPDATERING kan føre til at rader forsvinner fra visningen. Den relasjonsmodellen krever oppdateringer av en visning for å ha samme effekt som om visningen var en basisrelvar.

Søylefrie tabeller gjenkjennes

SQL krever at hver tabell har minst en kolonne, men det er to forhold mellom grad null (av kardinalitet én og null) og de er nødvendige for å representere utvidelser av predikater som ikke inneholder frie variabler.

NULL

Dette spesielle merket kan vises i stedet for en verdi hvor en verdi kan vises i SQL, spesielt i stedet for en kolonneverdi i en rad. Avviket fra den relasjonelle modellen stammer fra det faktum at implementeringen av dette ad hoc- konseptet i SQL innebærer bruk av treverdiert logikk , der sammenligningen av NULL med seg selv ikke gir sann, men i stedet gir den tredje sannhetsverdien , ukjent ; på samme måte gir sammenligningen NULL med noe annet enn seg selv ikke falsk, men gir i stedet ukjent . Det er på grunn av denne oppførselen i sammenligninger at NULL beskrives som et merke i stedet for en verdi. Den relasjonsmodellen avhenger av loven om ekskludert midte der alt som ikke er sant er falskt og alt som ikke er falskt er sant; det krever også at hver tupel i et forholdskropp har en verdi for alle attributtene til det forholdet. Dette bestemte avviket er omstridt av noen, bare fordi  EF Codd selv til slutt tok til orde for bruk av spesielle merker og en 4-verdig logikk, men dette var basert på hans observasjon om at det er to forskjellige grunner til at man kanskje vil bruke en et spesielt merke i stedet for en verdi, noe som førte til at motstandere av bruk av slike logikker oppdaget mer tydelige årsaker og minst så mange som 19 er notert, noe som ville kreve en 21-verdsatt logikk. SQL bruker selv NULL til flere formål enn å representere "verdi ukjent". For eksempel er summen av det tomme settet NULL, noe som betyr null, gjennomsnittet av det tomme settet er NULL, noe som betyr udefinert, og NULL som vises i resultatet av en VENSTRE JOIN kan bety "ingen verdi fordi det ikke er noen matchende rad i høyre operand ". Det er måter å designe tabeller på for å unngå behovet for NULL, vanligvis det som kan vurderes eller ligner høye grader av databasens normalisering , men mange synes det er upraktisk. Det kan være et sterkt debattert tema.

Relasjonsoperasjoner

Brukere (eller programmer) ber om data fra en relasjonsdatabase ved å sende den en forespørsel som er skrevet på et spesielt språk, vanligvis en dialekt av SQL. Selv om SQL opprinnelig var beregnet på sluttbrukere, er det mye mer vanlig at SQL-spørringer er innebygd i programvare som gir et enklere brukergrensesnitt. Mange nettsteder, for eksempel Wikipedia, utfører SQL -spørringer når du genererer sider.

Som svar på en forespørsel returnerer databasen et resultatsett, som bare er en liste over rader som inneholder svarene. Den enkleste spørringen er bare å returnere alle radene fra en tabell, men oftere filtreres radene på en eller annen måte for å returnere akkurat det ønskede svaret.

Ofte kombineres data fra flere tabeller til en ved å gjøre en join . Konseptuelt gjøres dette ved å ta alle mulige kombinasjoner av rader (det kartesiske produktet ), og deretter filtrere ut alt unntatt svaret. I praksis omskriver relasjonsdatabasehåndteringssystemer (" optimaliserer ") spørringer for å utføre raskere, ved hjelp av en rekke teknikker.

Det er en rekke relasjonsoperasjoner i tillegg til å bli med. Disse inkluderer prosjekt (prosessen med å eliminere noen av kolonnene), begrensning (prosessen med å eliminere noen av radene), union (en måte å kombinere to tabeller med lignende strukturer), differanse (som viser radene i en tabell som er ikke funnet i den andre), krysser (som viser radene i begge tabellene) og produkt (nevnt ovenfor, som kombinerer hver rad i en tabell med hver rad i den andre). Avhengig av hvilke andre kilder du konsulterer, er det en rekke andre operatører - hvorav mange kan defineres ut fra de som er oppført ovenfor. Disse inkluderer semi-join, ytre operatører som ytre join og ytre union, og forskjellige former for deling. Deretter er det operatører for å gi nytt navn til kolonner og oppsummere eller aggregere operatører, og hvis du tillater relasjonsverdier som attributter (relasjonsverdiattributt), så operatører som gruppe og ungroup. SELECT -setningen i SQL tjener til å håndtere alle disse bortsett fra gruppe- og ungroup -operatørene.

Fleksibiliteten til relasjonsdatabaser gjør det mulig for programmerere å skrive spørsmål som ikke var forventet av databasedesignerne. Som et resultat kan relasjonsdatabaser brukes av flere applikasjoner på måter de opprinnelige designerne ikke forutså, noe som er spesielt viktig for databaser som kan brukes i lang tid (kanskje flere tiår). Dette har gjort ideen og implementeringen av relasjonsdatabaser veldig populær blant virksomheter.

Normalisering av databaser

Forhold klassifiseres basert på hvilke anomalier de er sårbare for. En database som er i den første normale formen er sårbar for alle typer anomalier, mens en database som er i domenet/nøkkelen normal form ikke har noen endringer. Normale former er hierarkiske. Det vil si at det laveste nivået er det første normale skjemaet, og databasen kan ikke oppfylle kravene til normale former på høyere nivå uten først å ha oppfylt alle kravene til de mindre normale skjemaene.

Eksempler

Database

Et idealisert, veldig enkelt eksempel på en beskrivelse av noen relvarser ( relasjonsvariabler ) og deres attributter:

• Kunde ( kunde -ID , skatte -ID, navn, adresse, by, stat, postnummer, telefon, e -post, sex)
• Bestilling ( bestillingsnummer , kunde -ID , fakturanummer , dato lagt ut, lovet dato, vilkår, status)
• Bestillingslinje ( Bestillingsnr , Bestillingslinjenr , Produktkode , Antall)
• Faktura ( faktura nr. , Kunde -ID , bestillingsnr. , Dato, status)
• Fakturalinje ( Fakturanr. , Fakturalinjenr. , Produktkode , Antall sendt)
• Produkt ( produktkode , produktbeskrivelse)

I dette designet har vi seks relvarser: Kunde, Ordre, Bestillingslinje, Faktura, Fakturalinje og Produkt. De fet, understreket attributtene er kandidatnøkler . De ikke-fet, understreket attributtene er utenlandske nøkler .

Vanligvis velges en kandidatnøkkel for å bli kalt primærnøkkelen og brukes i stedet for de andre kandidatnøklene, som deretter kalles alternative nøkler .

En kandidatnøkkel er en unik identifikator som håndhever at ingen tupel vil bli duplisert; dette ville gjøre forholdet til noe annet, nemlig en pose , ved å bryte den grunnleggende definisjonen av et sett . Både utenlandske nøkler og supernøkler (som inkluderer kandidatnøkler) kan være sammensatte, det vil si kan være sammensatt av flere attributter. Nedenfor er en tabellvisning av en relasjon til vårt eksempel Customer relvar; en relasjon kan betraktes som en verdi som kan tilskrives en relvar.

Kundeforhold

Kunde ID	Skatte -ID	Navn	Adresse	[Flere felt ...]
1234567890	555-5512222	Ramesh	323 Southern Avenue	…
2223344556	555-5523232	Adam	1200 Main Street	…
3334445563	555-5533323	Shweta	871 Rani Jhansi Road	…
4232342432	555-5325523	Sarfaraz	123 Maulana Azad Sarani	…

Hvis vi forsøkte å sette inn en ny kunde med ID 1234567890 , ville dette bryte utformingen av relvaren siden Kunde -ID er en hovednøkkel, og vi har allerede en kunde 1234567890 . Den DBMS må avvise en transaksjon , slik som dette som vil gjengi den databasen inkonsekvent ved et brudd på en integritet begrensning .

Utenlandske nøkler er integritetsbegrensninger som håndhever at verdien av attributsettet hentes fra en kandidatnøkkel i en annen relasjon . For eksempel, i bestillingsrelasjonen er attributtet Kunde -ID en fremmed nøkkel. En join er operasjonen som trekker på informasjon fra flere relasjoner samtidig. Ved å bli med relvarser fra eksemplet ovenfor kan vi spørre databasen for alle kundene, bestillingene og fakturaene. Hvis vi bare ønsket tuplene for en bestemt kunde, ville vi spesifisert dette ved å bruke en begrensningsbetingelse .

Hvis vi ønsket å hente alle bestillingene for kunde 1234567890 , kunne vi spørre databasen om å returnere hver rad i ordretabellen med kunde -ID 1234567890 og koble ordre -tabellen til ordrelinjetabellen basert på bestillingsnr .

Det er en feil i databasedesignet vårt ovenfor. Faktura relvar inneholder et Order No -attributt. Så, hver tupel i Faktura -relvaren vil ha ett bestillingsnummer, noe som betyr at det er nettopp en ordre for hver faktura. Men i virkeligheten kan en faktura opprettes mot mange bestillinger, eller faktisk for ingen bestemt ordre. I tillegg inneholder bestillingsrelvaren et fakturanummer, som betyr at hver ordre har en tilsvarende faktura. Men igjen er dette ikke alltid sant i den virkelige verden. Noen ganger betales en ordre gjennom flere fakturaer, og noen ganger betales uten faktura. Med andre ord kan det være mange fakturaer per ordre og mange bestillinger per faktura. Dette er et mang-til-mange- forhold mellom orden og faktura (også kalt et uspesifikt forhold ). For å representere dette forholdet i databasen bør det innføres en ny relvar hvis rolle er å spesifisere korrespondansen mellom ordrer og fakturaer:

OrderInvoice (Order No, Invoice No)

Nå har Order relvar et en-til-mange-forhold til OrderInvoice-tabellen, og det samme gjør Invoice relvar. Hvis vi ønsker å hente hver faktura for en bestemt rekkefølge, kan vi spørre for alle bestillinger hvor Bestill Ingen i orden forhold tilsvarer det Bestillingsnr i OrderInvoice, og hvor Faktura Ingen i OrderInvoice lik Faktura Ingen i faktura.

Sett-teoretisk formulering

Grunnleggende begreper i relasjonsmodellen er relasjonsnavn og attributtnavn . Vi vil representere disse som strenger som "Person" og "navn", og vi vil vanligvis bruke variablene og å variere over dem. En annen grunnleggende oppfatning er settet med atomverdier som inneholder verdier som tall og strenger. ${\ displaystyle r, s, t, \ ldots}$${\ displaystyle a, b, c}$

Vår første definisjon gjelder begrepet tupel , som formaliserer forestillingen om rad eller post i en tabell:

Tupel

En tupel er en delvis funksjon fra attributtnavn til atomverdier.

Overskrift

En overskrift er et begrenset sett med attributtnavn.

Projeksjon

Projeksjonen av en tupel på et begrenset sett med attributter er .${\ displaystyle t}$${\ displaystyle A}$${\ displaystyle t [A] = \ {(a, v) :( a, v) \ in t, a \ in A \}}$

Den neste definisjonen definerer relasjon som formaliserer innholdet i en tabell slik den er definert i relasjonsmodellen.

Forhold

En relasjon er en tupel med overskriften og kroppen et sett med tupler som alle har domenet .${\ displaystyle (H, B)}$${\ displaystyle H}$${\ displaystyle B}$${\ displaystyle H}$

En slik relasjon tilsvarer tett det som vanligvis kalles forlengelsen av et predikat i første ordens logikk bortsett fra at vi her identifiserer stedene i predikatet med attributtnavn. Vanligvis sies det i relasjonsmodellen at et databaseskjema består av et sett med relasjonsnavn, overskriftene som er knyttet til disse navnene og begrensningene som bør holde for hver forekomst av databaseskjemaet.

Relasjonsunivers

Et relasjonsunivers over en overskrift er et ikke-tomt sett med relasjoner med overskrift .${\ displaystyle U}$${\ displaystyle H}$${\ displaystyle H}$

Relasjonsskjema

Et relasjonsskjema består av en overskrift og et predikat som er definert for alle relasjoner med overskrift . En relasjon tilfredsstiller et relasjonsskjema hvis den har topptekst og tilfredsstiller .${\ displaystyle (H, C)}$${\ displaystyle H}$${\ displaystyle C (R)}$${\ displaystyle R}$${\ displaystyle H}$${\ displaystyle (H, C)}$${\ displaystyle H}$${\ displaystyle C}$

Nøkkelbegrensninger og funksjonelle avhengigheter

En av de enkleste og viktigste typer relasjons begrensninger er nøkkelbegrensning . Det forteller oss at i hvert tilfelle av et bestemt relasjonelt skjema kan tuplene identifiseres med verdiene for visse attributter.

Supernøkkel

En supernøkkel er et sett med kolonneoverskrifter som verdiene til de sammenhengende kolonnene er unike for på alle radene. Formelt:

En supernøkkel er skrevet som et begrenset sett med attributtnavn.

En supernøkkel holder i et forhold hvis: ${\ displaystyle K}$${\ displaystyle (H, B)}$

• ${\ displaystyle K \ subseteq H}$ og
• det finnes ikke to forskjellige tupler slik .${\ displaystyle t_ {1}, t_ {2} \ i B}$${\ displaystyle t_ {1} [K] = t_ {2} [K]}$

En supernøkkel holder i et relasjonsunivers hvis det holder i alle relasjoner i .${\ displaystyle U}$${\ displaystyle U}$

Teorem: En supernøkkel holder i et relasjonsunivers om hvis og bare hvis og holder .${\ displaystyle K}$${\ displaystyle U}$${\ displaystyle H}$${\ displaystyle K \ subseteq H}$${\ displaystyle K \ rightarrow H}$${\ displaystyle U}$

Kandidatnøkkel

En kandidatnøkkel er en supernøkkel som ikke kan deles videre for å danne en annen supernøkkel.

En supernøkkel holder som en kandidatnøkkel for et relasjonsunivers hvis den holder som en supernøkkel for og det ikke er noen skikkelig delsett av den som også holder som en supernøkkel for .${\ displaystyle K}$${\ displaystyle U}$${\ displaystyle U}$${\ displaystyle K}$${\ displaystyle U}$

Funksjonell avhengighet

Funksjonell avhengighet er egenskapen til at en verdi i en tupel kan avledes fra en annen verdi i den tupelen.

En funksjonell avhengighet (forkortet FD) skrives som for endelige sett med attributtnavn.${\ displaystyle X \ høyre pil Y}$${\ displaystyle X, Y}$

En funksjonell avhengighet holder i en relasjon hvis: ${\ displaystyle X \ høyre pil Y}$${\ displaystyle (H, B)}$

• ${\ displaystyle X, Y \ subseteq H}$ og
• ${\ displaystyle \ forall}$tupler ,${\ displaystyle t_ {1}, t_ {2} \ i B}$${\ displaystyle t_ {1} [X] = t_ {2} [X] ~ \ Høyre pil ~ t_ {1} [Y] = t_ {2} [Y]}$

En funksjonell avhengighet holder i et relasjonsunivers hvis det holder i alle relasjoner i .${\ displaystyle X \ høyre pil Y}$${\ displaystyle U}$${\ displaystyle U}$

Trivial funksjonell avhengighet

En funksjonell avhengighet er triviell under en overskrift hvis den i alle relasjonsuniverser er over .${\ displaystyle H}$${\ displaystyle H}$

Teorem: En FD er triviell under en overskrift hvis og bare hvis .${\ displaystyle X \ høyre pil Y}$${\ displaystyle H}$${\ displaystyle Y \ subseteq X \ subseteq H}$

Lukking

Armstrongs aksiomer : Nedleggelsen av et sett med FD -er under et topptekst , skrevet som , er det minste supersettet av slik at: ${\ displaystyle S}$${\ displaystyle H}$${\ displaystyle S^{+}}$${\ displaystyle S}$

• ${\ displaystyle Y \ subseteq X \ subseteq H ~ \ Rightarrow ~ X \ rightarrow Y \ in S^{+}}$ (refleksivitet)
• ${\ displaystyle X \ rightarrow Y \ i S^{+} \ land Y \ rightarrow Z \ i S^{+} ~ \ Rightarrow ~ X \ rightarrow Z \ i S^{+}}$ (transitt) og
• ${\ displaystyle X \ rightarrow Y \ i S^{+} \ land Z \ subseteq H ~ \ Rightarrow ~ (X \ cup Z) \ rightarrow (Y \ cup Z) \ in S^{+}}$ (forstørrelse)

Teorem: Armstrongs aksiomer er sunne og fullstendige; gitt en overskrift og et sett med FD -er som bare inneholder delsett av , hvis og bare hvis de holder i alle relasjonsuniverser der alle FD -er holder.${\ displaystyle H}$${\ displaystyle S}$${\ displaystyle H}$${\ displaystyle X \ høyre pil Y \ i S^{+}}$${\ displaystyle X \ høyre pil Y}$${\ displaystyle H}$${\ displaystyle S}$

Fullføring

Fullføringen av et begrenset sett med attributter under et begrenset sett med FD -er , skrevet som , er det minste supersettet av slik at: ${\ displaystyle X}$${\ displaystyle S}$${\ displaystyle X^{+}}$${\ displaystyle X}$

• ${\ displaystyle Y \ rightarrow Z \ i S \ land Y \ subseteq X^{+} ~ \ Rightarrow ~ Z \ subseteq X^{+}}$

Fullføringen av et attributsett kan brukes til å beregne hvis en viss avhengighet er i avslutningen av et sett med FD -er.

Teorem: Gitt et sett med FD -er, hvis og bare hvis .${\ displaystyle S}$${\ displaystyle X \ høyre pil Y \ i S^{+}}$${\ displaystyle Y \ subseteq X^{+}}$

Ureduserbart deksel

Et ureduserbart omslag til et sett med FD -er er et sett med FD -er slik at: ${\ displaystyle S}$${\ displaystyle T}$

• ${\ displaystyle S^{+} = T^{+}}$
• det finnes ikke noe slikt${\ displaystyle U \ delsett T}$${\ displaystyle S^{+} = U^{+}}$
• ${\ displaystyle X \ rightarrow Y \ in T ~ \ Rightarrow Y}$ er et singleton -sett og
• ${\ displaystyle X \ rightarrow Y \ in T \ land Z \ subset X ~ \ Rightarrow ~ Z \ rightarrow Y \ notin S^{+}}$.

Algoritme for å utlede kandidatnøkler fra funksjonelle avhengigheter

algorithm derive candidate keys from functional dependencies is
    input: a set S of FDs that contain only subsets of a header H
    output: the set C of superkeys that hold as candidate keys in
            all relation universes over H in which all FDs in S hold

    C := ∅         // found candidate keys
    Q := { H }      // superkeys that contain candidate keys
    while Q <> ∅ do
        let K be some element from Q
        Q := Q – { K }
        minimal := true
        for each X->Y in S do
            K' := (K – Y) ∪ X   // derive new superkey
            if K' ⊂ K then
                minimal := false
                Q := Q ∪ { K' }
            end if
        end for
        if minimal and there is not a subset of K in C then
            remove all supersets of K from C
            C := C ∪ { K }
        end if
    end while

Se også

Referanser

Videre lesning

• Date, Christopher J .; Darwen, Hugh (2000). Fundament for fremtidige databasesystemer: det tredje manifestet; en detaljert studie av typen teoriens innvirkning på den relasjonelle datamodellen, inkludert en omfattende modell for type arv (2 utg.). Reading, MA : Addison-Wesley. ISBN 978-0-201-70928-5.
• ——— (2007). En introduksjon til databasesystemer (8 utg.). Boston: Pearson Education. ISBN 978-0-321-19784-9.

Eksterne linker

• Childs (1968), Mulighet for en sett-teoretisk datastruktur: en generell struktur basert på en rekonstituert definisjon av relasjon (forskning), Handle, hdl : 2027.42/4164 sitert i Codds avis fra 1970.
• Darwen, Hugh, The Third Manifesto (TTM).
• Relasjonsdatabaser på Curlie
• "Relasjonsmodell" , C2.
• Binære relasjoner og tupler sammenlignet med hensyn til det semantiske nettet ( World Wide Web log), Sun.