Introduksjon til databaser

Hva er en database

En database er en samling sammen­hengende data som beskriver en virksomhet — kunder og kontoer i en bank, studenter og emner ved et universitet, brukere og innlegg på et sosialt nettverk. Et databasebehandlingssystem (DBMS) er et programvarelag som lar mange brukere lagre, oppdatere og hente disse dataene samtidig, effektivt, og uten å miste dem.

Tre kjennetegn på data som hører hjemme i en database

• Verdifulle — virksomheten kan ikke fungere uten dem.
• Store — vesentlig større enn det som får plass i hovedminnet.
• Delte — flere brukere og applikasjoner aksesserer dem samtidig.

Hvor møter du databaser?

Hvorfor ikke bare bruke filer

Før relasjons­databasenes inntog ble bedrifter drevet av hjemme­snekrede fil­basert systemer: Hvert program leste og skrev sine egne filer i sitt eget format. Det fungerer for små problemer. Det havarerer i stor skala — av seks bestemte grunner.

Lost update — en konkret race condition

Konto A har 10 000 kr. To kasserere skal samtidig trekke fra: kasserer T₁ skal ta 500 kr, T₂ skal ta 100 kr. Riktig svar er 9 400 kr. Klikk gjennom for å se hva som faktisk kan skje.

Hva er en datamodell

En datamodell er et begreps­apparat for å beskrive data, sammenhengene mellom dem, og hvilke regler som må gjelde. Modellen gir oss et språk å snakke om data i, uavhengig av lagrings­detaljer.

instructor                        department
+-------+------------+----------+ +-----------+----------+--------+
| ID    | name       | dept     | | dept      | building | budget |
+-------+------------+----------+ +-----------+----------+--------+
| 22222 | Einstein   | Physics  | | Physics   | Watson   |  70000 |
| 76766 | Crick      | Biology  | | Biology   | Watson   |  90000 |
| 10101 | Srinivasan | Comp.Sci.| | Comp.Sci. | Taylor   | 100000 |
+-------+------------+----------+ +-----------+----------+--------+

  ┌──────────┐         ┌────────┐         ┌──────┐
  │ Student  │────◇────│  tar   │────◇────│ Emne │
  └──────────┘         └────────┘         └──────┘

{ "id": 22222, "name": "Einstein", "dept": "Physics" }
{ "id": 76766, "name": "Crick",
  "dept": "Biology", "office": "Watson 305",
  "publications": ["dna-1953", "..."] }

Lag av abstraksjon

Et DBMS skjuler implementasjons­detaljer. Bruker som kjører en SQL-spørring trenger ikke vite at radene ligger som komprimerte byte i 8 KB-blokker på en SSD, eller at det finnes en B+-tre-indeks som gjør oppslaget raskt. Denne separasjonen organiseres i tre lag.

Skjema og instans

Skjemaet er designet — strukturen, typene, reglene. Det er som type­deklarasjonene i et program. Instansen er innholdet i øyeblikket — det som ligger i tabellene akkurat nå. Den endres for hver INSERT, UPDATE, DELETE; skjemaet endres knapt.

CREATE TABLE instructor (
  ID        CHAR(5)        PRIMARY KEY,
  name      VARCHAR(20)    NOT NULL,
  dept_name VARCHAR(20),
  salary    NUMERIC(8, 2)
);

22222  Einstein    Physics    95000
12121  Wu          Finance    90000
10101  Srinivasan  Comp.Sci.  65000
...

22222  Einstein    Physics    95000
12121  Wu          Finance    90000
10101  Srinivasan  Comp.Sci.  65000
99999  Hopper      Comp.Sci.  88000   ← ny
...

Analogi: I et Java-program er class Instructor { ... } skjemaet, og den faktiske List<Instructor> i minnet er instansen — samme kode, ulik tilstand fra øyeblikk til øyeblikk.

Database­språk

SQL er to språk i ett. DDL (Data Definition Language) brukes til å definere skjemaet — CREATE, ALTER, DROP. DML (Data Manipulation Language) brukes til å lese og endre data — SELECT, INSERT, UPDATE, DELETE.

DDL — definere strukturen

CREATE TABLE department (
  dept_name VARCHAR(20) PRIMARY KEY,
  building  VARCHAR(15),
  budget    NUMERIC(12, 2) CHECK (budget >= 0)
);

ALTER TABLE instructor
  ADD CONSTRAINT fk_dept
  FOREIGN KEY (dept_name) REFERENCES department(dept_name);

DDL-utdata legges i data dictionary — en intern tabell med metadata om alle tabeller, kolonner, og constraints. DBMS-en konsulterer denne før hver eneste spørring.

DML — manipulere innholdet

SELECT instructor.name
FROM   instructor
WHERE  instructor.dept_name = 'History';

Resultatet er en ny tabell med én kolonne (name) og radene til alle historikere. SQL er deklarativt: vi sier hva vi vil ha, ikke hvordan den skal hentes. Optimizer­en velger plan.

Integritets­krav som DDL kan uttrykke

• Domene­krav — kolonnen er NUMERIC(8,2), kan ikke inneholde tekst.
• Referansiell integritet — instructor.dept_name må finnes i department.dept_name.
• Autorisasjon — hvem får read, insert, update, delete?

Fire bokstaver, fire garantier

En transaksjon er en logisk arbeidsenhet — én eller flere SQL-setninger som hører sammen. DBMS-en garanterer fire egenskaper for enhver transaksjon. Klikk en bokstav for detaljer.

Recovery-manager (Kap. 8) sørger for atomicity og durability ved å skrive en logg-post for hver endring før selve datasiden flushes. Concurrency-control-manager sørger for isolation ved bruk av låser eller multiversioning.

Database­motorens komponenter

Et DBMS er ikke ett program — det er et knippe samarbeidende moduler. Tre hoved­komponenter: query processor (forstår SQL), storage manager (snakker med disk), og transaction manager (lover ACID).

Hva gjør hver komponent?

• DDL-interpreter — leser CREATE TABLE osv. og legger metadata i datakatalogen.
• DML-kompilator — oversetter SQL til en kostnads­basert spørreplan; gjør spørrings­optimalisering.
• Query evaluation engine — kjører planen; ber storage manager om data og lar transaction manager gjøre gjeldende.
• Buffer manager — holder de heteste blokkene i RAM så de ikke må leses fra disk hver gang.
• File manager — vet hvilke blokker som er ledige, hvor radene ligger, hvilke indekser som peker hvor.
• Concurrency control — sørger for at parallelle transaksjoner ikke ødelegger for hverandre.
• Recovery manager — skriver logg, ruller tilbake aborterte transaksjoner, gjenoppretter etter krasj.

To-tier vs. tre-tier

Når en applikasjon snakker med databasen, kan den enten gjøre det direkte fra klienten (to-tier) eller gå via en applikasjonsserver (tre-tier). Moderne web- og mobil-applikasjoner er nesten alltid tre-tier.

Sentralisert, parallell, distribuert

• Sentralisert — én maskin, eventuelt med flere CPU-er som deler minne.
• Parallell — en klynge av maskiner samarbeider om en database for å håndtere store volum.
• Distribuert — data ligger geografisk spredd på flere maskiner.

Hvem bruker en database

Database­systemenes historie

Det er nyttig å se hvor relasjons­modellen kom fra — og hva som finnes ved siden av den i dag.

Test deg selv

Et siste sett spørsmål som dekker hele kapittelet — fra terminologi til hvor­for-spørsmål.

Når du synes disse spørsmålene sitter, er du klar for Kapittel 2 — Relasjonsmodellen.