Database

Fra Wikipedia, den frie encyklopædi
Gå til: navigation, søg
Searchtool.svg Eftersyn
Denne artikel bør gennemlæses af en person med fagkendskab for at sikre den faglige korrekthed.
Forklaringen vedrørende relationelle databaser er ikke korrekt!

Et database-system gør det muligt, at gemme en større mængde af information på en form, så informationen er maskinel omkostningslet at tilgå og opdatere. I modsætning til data, der er gemt i en fil kan flere programmer opdatere de samme data uden information tabes på grund af overskrivninger.

Krav til et databasesystem[redigér | redigér wikikode]

Et databasesystem skal stille følgende faciliteter til rådighed:

  • Atomare transaktioner, hvilket betyder, at en ændring enten skal gennemføres helt eller også skal der ryddes så godt op, at det ser ud som om ændringen ikke er forsøgt gennemført.
  • Konsistens De atomare transaktioner skal føre databasen fra en sammenhængende tilstand til en anden. Dette kræver, at de enkelte transaktioner er designet korrekt og hænger ikke kun på databasesystemet.
  • Isolation To eller flere programmer, der bruger samme database, må ikke kunne se hinandens ændringer, før de er helt gennemførte. Der anvendes dog forskellige grader af isolation.
  • Varighed Det skal sikres, at data ikke bare forsvinder. Det stiller krav til den anvendte hardware og krav om at skrivninger til disk laves, så data ikke kun lander i en cache undervejs.

På engelsk kaldes disse krav om bestemte egenskaber for ACID-properties efter forbogstaverne i de engelske betegnelser atomicy, consistency, isolation og durability.

Atomare transaktioner[redigér | redigér wikikode]

Hvis en transaktion kun omfatter læsning, vil den altid kunne startes forfra. Resten af afsnittet handler om transaktioner, der omfatter skrivning til databasen. Der findes flere måder at implementere atomare transaktioner på, men det almindeligste er at bruge en "skriv-foran-log" (write ahead log). Denne log vil i det følgende blive omtalt som en transaktionslog. Først skrives en beskrivelse af ændringen i transaktionsloggen og derefter gennemføres ændringen i selve databasen. Når en transaktion er gennemført, markeres den som gennemført i loggen.

Fejl håndteres forskelligt alt efter om det er fejl, der opdages af databasesystemet eller det er fejl, der opdages af det opdaterende program. Hvis fejl opdages af programmet, markeres transaktionen som fejlbehæftet, og alle opdateringer føres tilbage til udgangspunktet ved hjælp af oplysningerne i transaktionsloggen. Selvom databaseprogrammet finder en fejl, skal transaktionen så vidt muligt gennemføres. Hvis det er lykkedes at skrive transaktionen i loggen, gennemføres den fra oplysningerne her, ellers ikke. I visse tilfælde kan hensynet til korrekt isolation gøre, at en transaktion ikke kan gennemføres. I disse tilfælde bliver ændringerne ført tilbage, og det opdaterende program må forsøge at gennemføre transaktionen på ny.

Isolation[redigér | redigér wikikode]

Der opstår forskellige problemer, hvis forskellige programmer, der bruger den samme database, kan se hinandens ændringer inden de er helt gennemførte. Løsningen er, at isolere de enkelte databasetransaktioner fra hinanden. En høj grad af isolation sikrer, data hænger rigtigt sammen, men begrænser også parallelle opdateringer, hvilket kan give lange afviklingstider for de opdaterende programmer.

De mest gængse niveauer af isolation er fra det laveste til det højeste:

  • Læs ikke gennemførte (read uncommitted): Ingen isolation. Et program kan læse data, som måske bliver tilbageført eller overskrevet senere.
  • Læs gennemførte (read committed): Et program kan kun læse data, der er skrevet endeligt til databasen. Det er muligt, at de læste data ændres fra anden side inden transaktionen er slut.
  • Gentagelige læsninger: Et program kan læse de samme data flere gange og få det samme resultat inden for den aktuelle transaktion.
  • Serialisering: Ud over gentagelige læsninger er mulige, sikres det, at en transaktion ikke har kunnet læst data, der er slettet eller ændret inden transaktionen er gennemført. Data, der er tilføjet fra en anden transaktion kan heller ikke ses.

I mange tilfælde er niveauet "læs gennemførte" tilstrækkeligt.

Varighed[redigér | redigér wikikode]

For at sikre, at data opbevares i databasen så længe, det er nødvendigt, er sikkerhedskopiering en nødvendighed. Det er i den sammenhæng vigtigt, at data hænger rigtigt sammen (er konsistente) inden backup foretages. Løsningen er, at etablere et kontrolpunkt (checkpoint).

Etablering af et kontrolpunkt kan ske på denne måde:

  1. Der lukkes af for nye transaktioner
  2. Transaktioner, der er i gang gennemføres
  3. Det sikres, at alle data er skrevet til disk
  4. Det markeres i databasens log, at der er lavet et kontrolpunkt
  5. Der laves backup og eventuelt anden vedligeholdelse
  6. Transaktionsloggen tømmes
  7. Der åbnes for transaktioner igen

Nogle databasesystemer kan sætte transaktioner i kø under oprettelse af et kontrolpunkt.

Anvendelse af en database[redigér | redigér wikikode]

For at et databasesystem skal kunne bruges, skal flere ting være på plads. Der skal oprettes en database med en passende struktur. Det skal sikres, at de rette brugere har adgang til de dele af databasen der er relevant for dem. Der skal eventuelt fyldes data i fra en anden kilde som for eksempel et sæt filer.

Når databasen er på plads, kan man læse, oprette, ændre eller slette data i den. Ofte sker det med et program, der afvikles uden for databaseprogrammet som en klient/server-løsning.

Forskellige slags databaser[redigér | redigér wikikode]

Der findes overordnet nogle forskellige måder at implementere eller tilgå en database på. De præsenteres i de følgende afsnit.

Relationel database[redigér | redigér wikikode]

I en relationel database kan man oprette tabeller. Tabeller består af rækker af felter. De felter, i hver kolonne, der står i samme række, kaldes en post. Relationerne mellem tabellerne udgør den enkelte databases struktur. Reglerne for denne struktur kaldes referentiel integritet.

Det teoretiske grundlag for den relationelle datamodel er mængdelæren. I praksis er det dog de færreste systemer, der lever helt op til reglerne om mængder. For eksempel er det ofte muligt at have resultater af forespørgsler, der indeholder dubletter af rækker.

Data i en relationel database skal som minimum overholde følgende:

Ved læsning af data bruges tre grundlæggende operationer.

  • Selektion: Find rækker, der opfylder en bestemt betingelse som for eksempel "alder = 42"
  • Projektion: Vælg et antal kolonner fra en tabel. Det kunne være fornavn og efternavn.
  • Krydsprodukt: Kombiner alle rækker i en tabel med alle rækker i en anden tabel.

Operationerne kan kombineres, så man kan lave forespørgsler i stil med "Kombiner persontabellen og og adressetabellen. Find fornavn, efternavn og adresse på dem, der er 42 år gamle".

Med det meget udbredte forespørgselssprog SQL kunne det se sådan ud:

SELECT fornavn, efternavn, gade, husnr, postnr
FROM persontb, adressetb
WHERE persontb.adresseID = adressetb.adresseID
AND persontb.alder = 42

Hierarkisk database[redigér | redigér wikikode]

Den hierarkiske databasetype er en af de ældste med en oprindelse tilbage i 1960'erne. Data er, som navnet siger, ordnet hierarkisk i træstrukturer med forældre/børn-relationer.

Til nogle formål er det den klart hurtigste databasetype der findes, men ulempen er, at data kun effektivt kan tilgås i den orden som den hierarkiske struktur dikterer. Ændres måden man vil tilgå data på, skal databasen reelt set omdesignes og data konverteres.

I dag er den hierarkiske databasetype stort set erstattet af den relationelle pga. dennes større fleksibilitet.

Netværksdatabase[redigér | redigér wikikode]

I korthed er en netværksdatabase opbygget af "poster", organiseret i "post-typer". Mellem to post-typer kan der defineres en "set-type", hvor den ene post-type er "owner", og den anden post-type er "member". På en set-type kan der defineres et antal forskellige betingelser, der skal gælde, f.eks. sortering, éntydighed, hvordan søgning skal foregå, om sletning skal videreføres fra owner til member, og om en ny post kan indsættes i member uden kontrol af nøglen mod owner.

Objektorienteret database[redigér | redigér wikikode]

En objekt orienteret database er database baseret på objekter i en form svarende til den der bruges i objekt orienteret programmering. Der er meget få databasesystemer, der fungerer på denne måde, men der findes flere programmeringsværktøjer, der giver mulighed for automatisk opdatering af en relationel database på baggrund af objekter. Som programmør slipper man ikke for at tænke på databasen, men meget af den trivielle programmering kan automatiseres.

Kilder[redigér | redigér wikikode]

  • Fundamentals of database systems af Ramez Elmasri og Shamkant Navathe ISBN 0-8053-1753-8