(Go: >> BACK << -|- >> HOME <<)

Eksempel på en enkel relasjonsmodell
Eksempel på en relasjonsmodell: Arkeologiske gjenstander og funnsted
Eksempel på en enkel relasjonsmodell
Lisens: CC BY SA 3.0
Spørring
Tabell med innhold og resultattabell fra spørringen SELECT tittel, type FROM eiendeler WHERE plassering = «Hylle 5»
Spørring

Utvikling av datamodeller

1970-tallet

Hierarkisk og nettverksdatabase

Midten av 1970-tallet–

Relasjonsdatabase og ER-modellen

Sent 1980-tallet / 1990-tallet

Objektorientert database

2010-tallet–

NoSQL-database (ulike datamodeller)

En database er en samling med lagrede data. Datasamlingen er organisert og strukturert etter en bestemt strategi eller modell – en databasemodell. Dataene brukes og vedlikeholdes gjennom et bestemt programsystem som kalles et databasesystem eller databasehåndteringssystem.

En database dekker behov for å lagre data på en (semi-)strukturert og sikker måte for enkelt å kunne søke i data og holde dataene oppdatert. Sikker lagring betyr både å ikke miste eller uforvarende slette dataene, samt å ha kontroll over hvem som kan lese dataene og eventuelt endre på de lagrede dataene.

Relasjonsdatabase har siden 1980-tallet vært dominerende. En relasjonsdatabase er basert på relasjonsmodellen. Her lagres data i rader (poster) med et sett felt (attributter) i todimensjonale tabeller. Alle operasjoner på relasjonsmodellen er definert i en standard som kalles SQL-standarden. SQL står for Structured Query Language. Det blir på norsk kalt et strukturert spørrespråk.

Tidligere var også databaser basert på enten hierarkisk modell eller nettverksstruktur brukt. Fra 2010-tallet er NoSQL-databaser en betegnelse for løsninger med alternative datamodeller tilpasset lagring av semistrukturelle data.

Noen begreper

Begrep

Beskrivelse

Tabell

En logisk fremstilling av data i en todimensjonal tabell. Kalles også en relasjon i relasjonsdatabase

Rad En rad (en linje) i en tabell med et sett med attributter. Kalles også et tuppel. Fra gammelt av kalles også dette en post (engelsk record). For eksempel fornavn, etternavn, adresse og postnummer til en person

Kolonne

En kolonne i en tabell med samme type attributt. For eksempel etternavnene til personene i tabellen

Attributt

En verdi med et attributtnavn og datatype (verdidomene). For eksempel attributtnavnet etternavn med verdien Hansen (av datatypen tekst)

Nøkkel

en referanse, eller peker, til en forekomst i databasen. Eksempler er en entydig identifisering av en rad/tuppel i relasjonsdatabase kalt primærnøkkel, eller en referanse mellom to rader kalt fremmednøkkel

Indeks

brukes for raskere søk på en spesifikk kolonne eller attributt, for eksempel kundenummer eller kundenavn

Spørring

Et spørsmål til databasen for å sette inn data i databasen, slette data i databasen eller endre på data i databasen. Dette gjøres gjennom kommandoer, hierarkiske menyer eller spørrespråk, som SQL

Transaksjon

I database metoder for å sikre korrekt utførelse av spørringer for eksempel ved oppdatering/endring av en tabell. Spesielt brukt i databasesystem som tillater at flere brukere utfører spørringer mot for eksempel samme tabell samtidig

Normalisering

I database løsninger for å unngå dobbeltlagring av samme data i en database. I relasjonsdatabase finnes det regler for å normalisere en tabell ved å se på sammenhenger mellom attributter eller data

Databasesystem

Det finnes mange databasemodeller og tilhørende databasesystemer. Årsaken er delvis datateknologisk utvikling, men også at brukere av databaser har forskjellige behov.

Databasesystem med tilhørende databasemodell
System Datamodell
Relasjonsdatabase Bygger på relasjonsmodellen, matematisk bygd på relasjonsalgebra. Alle kommersielle løsninger bruker spørrespråket SQL
NoSQL Ulike systemer kan ha ulik (egen) datamodell. En oppdeling kan være i dokumentdatabase, ulike nøkkelverdi-løsninger, og grafdatabase
Hierarkisk database Bygger på en ren trestruktur også kalt hierarkisk modell hvor hver post eller node i trestrukturen kan lagres sekvensielt
Nettverksdatabase En utvidelse av trestruktur til et nettverk hvor hver post eller node kan peke på flere andre poster i nettverket
Objektorientert database Bygger på en objektorientert tankegang hvor data lagres som objekter, inspirert av objektorientert programmeringsspråk

Databasemaskin

Et databasesystem må kjøres på en databasemaskin, eller databasetjener, på et gitt operativsystem. Maskinen kan enten kjøres lokalt i et datanett eller eventuelt kjøres i en skytjeneste.

Tradisjonelt brukes klient-/tjenerteknologi, hvor databasesystemet i sin helhet kjører på en vertsmaskin, typisk kalt databasetjener (engelsk database server) i et datanett hvor mange ulike programmer, kalt klienter, har tilgang til samme database. Vertsmaskinen må være skalert til å håndtere både datamengden som skal lagres, og prosessering av spørringer mot databasen.

Et alternativ er en distribuert database lokalisert på forskjellige maskiner som er knyttet sammen i et datanett, et nettverk. Fysisk lagring av data samt prosessering av spørringer kan da spres utover flere maskiner (fragmentering). Begrepet brukes også ved at maskiner i nettverket kan ha en kopi (replikasjon) av deler av databasen lagret lokalt for raskere søk i data. NoSQL-databaser garanterer typisk ikke for at lokale kopier inneholder oppdaterte data til enhver tid. Databasesystem må fortsatt vite hvordan den nyeste versjonen av den totale databasen kan finnes.

En nyere løsning er å lagre databasen i en skytjeneste. Dette kan medføre at en overlater til en leverandør av skytjenester å sørge for at databasesystemet til enhver tid er oppdatert og skalert i forhold til bruken.

Datasikkerhet og databaser

Generelt har et databasesystem innebygd funksjonalitet for å sikre både lagring av data og hvem som har rettighet til å lagre og hente ut (aksessere) data fra en database. Databaseadministrasjon (forkortes DBA) er her viktig, ikke minst hvis databasemaskinen er koblet til internett. En sikkerhetstrussel er hacking utenfra.

Ved lagring av data i skytjeneste kan det for eksempel i offentlig forvaltning være juridiske utfordringer knyttet til at en kanskje ikke har full oversikt over hvor i verden data i en database faktisk er lagret.

Databasevern inneholder juridiske krav knyttet til lagring av data.

Personvern

Datasikkerhet handler også om personvern. Databaser i for eksempel helsetjenester eller i offentlig forvaltning, inneholder sensitive personopplysninger. I Norge skal for eksempel ikke fødselsnummer lagres eller brukes som identifikasjon (nøkkel) i databaser uten at det finnes saklige grunner til dette. I stedet kan en bedrift for eksempel bruke et eget lokalt kundenummer som nøkkel i en database.

Spesialiserte databasetyper

Lagring av tekst og multimedia

Tradisjonelt er databaser gode på håndtering av formaterte data, men lite fleksible ved behov for å lagre andre typer data som tekst, film, video og lyd, tegninger, kart, matriser og vektorer, og data med komplekse eller variable strukturer, for eksempel dokumenter. Ikke alle typer data trenger å lagres i en database. For eksempel kan multimediafiler lagres i et filsystem utenfor databasen, og heller lagre referanser til filene med metadata, data om data, i selve databasen.

Tekstbaserte dokumenter kan i dag håndteres av NoSQL eller tilleggsfunksjonalitet i kommersielle relasjonsdatabasesystem.

Objektorienterte databaser er brukt i geografiske informasjonssystemer (GIS). For å lagre fakta og regler er det utviklet deduktive databaser.

Løsninger for søk i fritekst kan være et alternativ til en tradisjonell database. Fritekstsøk kan utføres gjennom spesielle algoritmer på egne fritekstdatabaser som inneholder ustrukturert informasjon.

Lagring av historiske data

Tradisjonelt har det vært slik at databaser oppdateres, den gamle verdien overskrives med den siste og mest gyldige verdien. Dette fører til at historikken, det vil si historiske data, går tapt. Skal en ta vare på historikken må dette bygges inn i databasemodellen, altså den aktuelle databases utforming eller struktur. Eventuelt kan en kan ha en database som aldri sletter eller overskriver data – en såkalt temporal database. Nye verdier for en attributt lenkes inn i front på kjeden av alle foregående verdier, og til alle verdier hører en tidsangivelse, et tidsstempel.

Historie

Den tradisjonelle databasen lagrer data i form av poster. Hver post inneholder et antall felter der ett eller flere felter i kombinasjon utgjør en entydig identifikasjon – postens nøkkel. Databasene vokste ut av de postorienterte filsystemene, der alle poster var lagret i en sekvensiell fil. Databasene utviklet strukturer, eller relasjoner, mellom posttypene. Først kom en ren trestruktur også kalt hierarkisk modell med IBMs IMS. Poster i trestrukturer lar seg linearisere, det vil si at de kan lagres etter hverandre på sekvensielle medier, for eksempel magnetbånd.

Med inntog av disker som er adresserbare, kunne en ved hjelp av pekere (adresser) hoppe fra én post til en annen, og det gir muligheter for mer avanserte strukturer hvor en lenker sammen poster. Datamodeller basert på lenker kalles settbaserte modeller. Postene i en lenke danner et sett, og posten som lenken starter fra blir settets eierpost. Når samme post inngår i flere lenker dannes en nettverksstruktur. CODASYL foreslo i 1971 en standard for databasesystemer, både strukturell utforming og operasjoner, basert på en nettverksstruktur av lenkede lister.

De settbaserte (lenkede lister av poster) var omstendelige å programmere. I 1970 lanserte Edgar Frank Codd relasjonsmodellen som prioriterte enkelthet og enklere programmering, samt at den var basert på en helhetlig teoretisk modell. Problemet var at ingen ennå kunne fortelle hvordan systemet kunne realiseres i praksis slik at en oppnådde akseptabel kapasitet.

1970-årene var preget av at operative databaser var realisert av databasesystemer basert på settmodellen, enten trestrukturert modell eller nettverksmodellen (CODASYL-modellen). Forskningsmiljøene prøvde å finne løsninger på hvordan relasjonsmodellen kunne realiseres for praktisk bruk. Blant annet ble det bygget flere databasemaskiner med spesialisert maskinvare.

Fra slutten av 1970-årene ble relasjonsdatabasesystemer mest vanlig, typisk i en klient-/tjenerarkitektur. Dette ga rom for at flere (klient-)programmer kunne aksessere samme databasesystem (tjener) over et datanett. Relasjonsdatabaser har overlevd teknologisk ved at både hardvare, fysisk lagringsmedium og datakommunikasjon har blitt stadig billigere og raskere. Dette inkluderer ulike distribuerte løsninger for både prosessering (ytelse) og lagring av data. I tillegg har kommersielle aktører sørget for å optimalisere og tilpasse sine databasesystemer etter hva kundene/markedet har etterspurt.

I 1976 ble ER (Entitets Relasjons)-modellen introdusert. Dette er en såkalt konseptuell datamodell for visualisering av databasen i form av en figur, kalt ER-diagram. ER-diagram er ikke teoretisk knyttet til relasjonsdatabase, men i praktisk bruk er det vanlig at et ER-diagram viser databasens struktur. Dette letter forståelsen for databasens oppbygging for utenforstående, og har derfor vært viktig for utbredelsen av spesielt relasjonsdatabase. Kommersielt finnes det verktøy som automatisk oversetter mellom ER-diagram og relasjonsdatabase. Et tidlig eksempel på et slikt verktøy er Modelator, utviklet av det norske selskapet Metodedata.

Sent på 1980-tallet og innover på 1990-tallet kom først objektorienterte datamodeller og deretter objektrelasjonsdatabaser. Objektorientert tankegang ble veldig populært innen systemutvikling eller programmering i denne perioden. Fullt ut objektorienterte databasesystemer representerer data som objekter med mulighet for å inkludere egenskaper, eller metoder, for å lagre og manipulere data i objektet. Rene objektorienterte løsninger ble, i motsetning til objektorientert programmering, ingen kommersiell suksess. Tanken er imidlertid delvis videreført som tilleggsfunksjonalitet i SQL-standarden for relasjonsdatabaser.

Utover 2010-tallet kom NoSQL-databaser. Begrepet NoSQL ble første gang brukt i 2009. NoSQL adresserer behovet for å lagre store mengder data med litt struktur, semistrukturelle data, men i en friere form enn det relasjonsdatabaser legger opp til. Populariteten har kommet i kjølvannet av stordata, knyttet til dataanalyse og KI. Teknologisk har utviklingen vært mulig fordi lagringskapasitet er billig og fordi både prosessering og lagring av data kan spres utover flere maskiner i et datanett ved behov.

Tilgjengelighet

Å lage en egen database krever i praksis grunnleggende kunnskap innen programmering.

På egen maskin kan verktøy som Microsoft Access (tidligere kalt fjerdegenerasjonsverktøy, et tidlig eksempel er verktøyet dBase) brukes til å opprette en enkel relasjonsdatabase med tilhørende tabeller. Slike verktøy kan imidlertid ha begrensninger på antall samtidige brukere av databasen, og egner seg derfor kanskje best til personlig bruk.

Å kombinere relasjonsdatabasesystem som støtter SQL med programmering er i dag vanlig. Eksempler på mulige databasesystemer for dette er SQLite, MySQL og MariaDB. Disse kan installeres gratis på egen maskin for uttesting, for eksempel via en programpakke som WampServer eller XAMPP. Hvis man vil gjøre en slik løsning tilgjengelig på internett, kan eventuelt et web-hotell benyttes.

NoSQL-løsninger er ofte gratis for uttesting. Kommersielt er MongoDB et av de mest populære verktøyene.

Les mer i Store norske leksikon

Litteratur

  • Kristoffersen, Bjørn (2020). Databasesystemer Oslo: Universitetsforlaget
  • Hansen, Kjell Toft & Mallaug, Tore (2008). Databaser Oslo Trondheim: Gyldendal akademisk

Kommentarer (2)

skrev Kjell Bratbergsengen

Bør overføres til Databaseteknologi og informasjonsgjenfinning

svarte Guro Djupvik

Det har du rett i, flyttet den nå.

Kommentarer til artikkelen blir synlig for alle. Ikke skriv inn sensitive opplysninger, for eksempel helseopplysninger. Fagansvarlig eller redaktør svarer når de kan. Det kan ta tid før du får svar.

Du må være logget inn for å kommentere.

eller registrer deg