Tietokanta ja DBMS: kuka vastaa mistäkin

Luku 1 – ”Arkiston kartta”

Kotomarketin vedos ei ole enää signaali kuolleelta sektorilta – se makaa Vault-9:n karanteeniosastossa, ja sen dumpin viimeisen rivin alla on yhä sama allekirjoitus: ”K.” Aamulla holopaneeliisi syttyy uusi merkintä: ”Käyttöoikeus: arkiston luettelo. Myöntäjä: moduuli S.Q.L.” Arkiston ovi liukuu sivuun; sen takana palvelintelineet huminoivat tasaisesti meripihkanvärisessä valaistuksessa.

QUERY: Ennen kuin luet jonkun toisen muistia, ymmärrä, miten se on rakennettu. Aloitetaan pääasiasta: mikä täällä on varasto ja kuka on vartija.

Tietokanta ja DBMS

Tietokanta on järjestetty varasto. Kotomarketin vedoksessa on ostajat, tuotteet, tilaukset ja tapahtumat: ei hajallaan tiedostoissa, vaan selkeässä rakenteessa – siksi niitä voi lukea vielä satakuusikymmentä vuotta myöhemmin.

Mutta varasto itse ei vastaa kysymyksiin. Tarvitaan ohjelma, joka osaa luoda tauluja, kirjata uusia tilauksia, lukea dataa ja pitää huolen siitä, etteivät yhteydet katkea. Se on DBMS (tietokannan hallintajärjestelmä). Esimerkkejä: PostgreSQL, MySQL, ClickHouse. Meidän vedoksemme on PostgreSQL-tietokanta, ja se puhuu yhä samaa SQL:ää kuin kaupan eläessä.

Kirjoitat kyselyn SQL:llä → lähetät sen DBMS:lle → DBMS hakee pyytämäsi datan ja palauttaa tuloksen. Excel on hyvä henkilökohtaiseen taulukkoon, mutta ei kauppaan, jossa tuhannet käyttäjät selaavat tuotteita, tekevät tilauksia ja jättävät tapahtumia järjestelmään yhtä aikaa.

Database and DBMS

A database is an organized store. The Kotomarket snapshot holds buyers, products, orders, and events — not scattered across files, but in a clear structure. That’s exactly why it can still be read a hundred and sixty years later.

But the store itself doesn’t answer questions. You need a program that can create tables, record new orders, read data, and make sure the links never break. That’s a DBMS (database management system). Examples: PostgreSQL, MySQL, ClickHouse. Our snapshot is a PostgreSQL database, and it still speaks the same SQL it did when the shop was alive.

You write a query in SQL → send it to the DBMS → the DBMS fetches the data you asked for and returns the result. Excel is fine for a personal spreadsheet, but not for a shop where thousands of users browse products, place orders, and leave events in the system all at once.

Mitä DBMS osaa, mitä pelkät tiedostot eivät

Vaikuttaa siltä, että kauppa pärjäisi ilman DBMS:ää: kirjoittaisi tilaukset CSV- tai Excel-tiedostoon. Henkilökohtaisen muistivihon mittakaavassa niin tehdäänkin – kunnes tulevat tehtävät, joita varten DBMS ylipäätään keksittiin.

• Rinnakkainen käyttö. Elävässä Kotomarketissa ostajat tekivät tilauksia yhtä aikaa. Kaksi prosessia, jotka kirjoittavat samaan tiedostoon, pyyhkivät toistensa muutokset; DBMS ajaa muutokset transaktioina ja erottelee rinnakkaiset operaatiot itse. PostgreSQL tekee tämän MVCC-mekanismilla: lukijat eivät estä kirjoittajia eivätkä toisin päin.
• Toipuminen kaatumisesta. Virta välähti kesken kirjoituksen – tiedosto meni rikki, eikä tiedetä, kumpi puoli tilausta ehti tallentua. DBMS kirjaa muutoksen ensin lokiin (PostgreSQL:ssä se on WAL, write-ahead log) ja toistaa sen kaatumisen jälkeen: tilaus joko kirjoitetaan kokonaan tai ei lainkaan.
• Käyttöoikeudet. Tiedosto on auki joko kokonaan tai ei ollenkaan. DBMS:ssä oikeudet ovat hienojakoisia – aina yksittäiseen tauluun asti:

-- Analyytikolle vain tilausten luku, ilman oikeutta muuttaa niitä
GRANT SELECT ON orders TO analyst;

• Eheys. DBMS ei hyväksy tilausta, jonka hinta on tekstiä, eikä viittausta olemattomaan ostajaan: sarakkeiden tyypit ja rajoitteet tarkistetaan jokaisella kirjoituksella. Tiedostoa ei kiinnosta, mitä siinä on.
• Deklaratiiviset kysymykset. ”Näytä yli 5000 maksavat tilaukset” – yksi rivi SQL:ää. Tiedoston kanssa saman työn tekee ohjelma, joka jonkun on kirjoitettava eikä mokattava.