Database

Article on other languages:

del.icio.us del.icio.us
Digg Digg
Furl Furl
Reddit Reddit
Rojo Rojo
Add to OnlyWire

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.

Indholdsfortegnelse

Krav til et databasesystem

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

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

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

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 igang 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

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

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

Relationel database

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.

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:

  • Hver række i en tabel skal have en unik nøgle
  • Alle rækker har det samme antal kolonner
  • Alle felter har en fast længde. Selv såkaldte variable tekstfelter har en maksimal længde.

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

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

Objektorienteret database

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

  • Fundamentals of database systems af Ramez Elmasri og Shamkant Navathe ISBN 0-8053-1753-8
Hentet fra "http://da.wikipedia.org/wiki/Database"

This article is from Wikipedia. All text is available under the terms of the GNU Free Documentation License.

Giant Panda

Mercedes Car
James Bond Guide
This site monitored by SitePinger.net