Introduktion till databaser och databashanterare

Vad är en databas?

Med ordet databas brukar man mena

• en samling data som
• hör ihop,
• som modellerar en del av världen, till exempel ett företag och dess verksamhet,
• och är persistent, dvs inte försvinner när man avslutar programmet eller stänger av datorn.

• ha ett schema, dvs det ska finnas en explicit beskrivning av vad det är för data,
• vara konsistent eller logiskt koherent, dvs den får inte innehålla motsägelser.
• Åtminstone i det följande antar vi också att databasen lagras och hanteras av en dator.

Vad är en databashanterare?

Många databashanterare är mycket stora och komplicerade, och är egentligen hela system av olika program.

Några kända exempel på databashanterare är DB2 från IBM, Informix, INGRES, InterBase från Borland (fd Inprise), Microsoft Access, Microsoft SQL Server, MySQL, ObjectStore, Oracle och Postgres.

Språkförbistring

Databashanterare - varför?

Om man exempelvis vill ha ett kundregister, med nummer, namn och adress, börjar man kanske med att definiera en post:

    struct kund {
        int nummer;
        char namn[50 + 1];
        char adress[50 + 1];
        struct kund* nextp;
    };

Det finns ganska många fördelar med att i stället använda en databashanterare. De viktigaste fördelarna är att det är

• enkelt,
• kraftfullt, och
• flexibelt.

Fördel 1: Enkelt!

    create table kund
    (nummer integer,
    namn char(50),
    adress char(50));

Uppgifterna i tabellen kallar vi (förstås) för data. Tabellens utseende, dvs vilka kolumner som finns, vad de heter, och vad de får innehålla, kallas för schema. Schemat bestämmer vilka data som kan lagras i databasen. I schemat ovan använder vi oss av tabeller och kolumner. Vi kunde i stället ha använt något annat, t ex objekt och klasser. Hur schemat kan se ut bestäms av databasens datamodell. Om man vill kan man säga att datamodellen är ett "schema för schemat". Datamodellen bestämmer alltså hur schemat får se ut, och schemat bestämmer vilka data som får lagras i databasen. (Datamodellen med tabeller kallas relationsmodellen.)

Nu ska vi använda vår databas också. Antag att vi vill ha reda på namnet och adressen för kunden med kundnummer 17. Då skriver vi bara:

    select namn, adress
    from kund
    where nummer = 17;

Fördel 2: Kraftfullt!

Antag att vi vill ha reda på alla kunder som har namn som börjar med S, och få dem utskrivna i bokstavsordning efter adressen. Då skriver vi bara så här:

    select *
    from kund
    where namn like 'S%'
    order by adress;

    select adress, count(*)
    from kund
    where namn = 'Anders'
    group by adress;

Fördel 3: Flexibelt!

Kommer du plötsligt på att du vill göra en helt ny sorts sökning i databasen? Enkelt! Skriv bara in sökningen som en fråga:

    select namn
    from kund
    where adress = 'Vägen 8'
    and namn like 'S%';

    alter table kund add telefon char(10);

Nu har du utökat tabellen kund med en ny kolumn, som heter telefon!

Har kundregistret använts ett tag, och nu innehåller det så många kunder att det tar lång tid att till exempel söka efter en kund med visst namn? Enkelt! Skriv:

    create index foo on kund(namn);

Andra fördelar

Databasteknik möjliggör samtidig åtkomst av data.

Databasteknik möjliggör återställande efter krascher.

Med en databashanterare slipper man sådana problem. Den ser till att inga data någonsin försvinner, hur olyckligt ett strömavbrott än skulle komma.

Databasteknik gör det lättare att möta olika användares behov.

    create view kund2
    as select nummer, namn
    from kund;

Det går att definiera mer komplicerade vyer. Till exempel kanske en annan användare bara är intresserad av antalet kunder, och bryr sig inte om vilka de är? En vy löser det problemet:

    create view kund3
    as count(*)
    from kund;

Databasteknik möjliggör bättre säkerhet.

Nackdelar med databaser

Å andra sidan kan en lösning med databashanterare i stället gå mycket fortare än ett specialskrivet program! Orsaken är att databashanteraren innehåller avancerade datastrukturer och algoritmer, som man sällan orkar ta med i det specialskrivna programmet.

Användningsområden för databasteknik

Datamodeller

Man brukar dela in datamodellerna i tre klasser:

• Konceptuella eller begreppsmässiga datamodeller. Om man ska skapa en databas som beskriver en del av verkligheten, t ex ett företag, brukar man börja med att göra en beskrivning av hur den delen av verkligheten ser ut och fungerar. Till det kan man använda en konceptuell datamodell. Den konceptuella modellen behöver egentligen inte ha någonting med datorer att göra, utan är bara en beskrivning av verkligheten som lika gärna skulle kunna användas av någon som bara vill analysera hur företaget fungerar.
  Exempel: ER-modellen.
• Implementationsmodeller. Det här är de datamodeller som används i databashanterare. Om man vill skapa en databas måste den beskrivning man gjort med hjälp av en konceptuell datamodell översättas till något som går att stoppa in i en dator, nämligen en beskrivning enligt en implementationsmodell.
  De vanligaste implementationsmodellerna numera är relationsmodellen och olika objektorienterade modeller. Tidigare var den hierarkiska datamodellen och nätverksmodellen vanliga.
• Fysiska datamodeller, som kan användas för att beskriva hur data lagras fysiskt.

Tre-schema-arkitekturen

• Den externa nivån, eller vy-nivån, beskriver hur de olika användaren ser databasen. Detta beskrivs av det externa schemat.
• Den logiska nivån beskriver hela databasen, uttryckt i den implementationsmodell som databashanteraren använder. I en relationsdatabas består den logiska nivån av alla tabellerna i databasen. Detta beskrivs av det logiska schemat.
• Den interna eller fysiska nivån, som beskriver hur data är lagrat. Som användare märker man oftast inte alls av den här nivån, utom som hur fort det går att göra olika operationer. Den fysiska nivån beskrivs av det fysiska schemat.

• Logiskt dataoberoende innebär att man kan ändra det logiska schemat, utan att det externa schemat påverkas.
• Fysiskt dataoberoende innebär att man kan ändra det fysiska schemat, utan att det logiska schemat påverkas.

De tre nivåerna i tre-schema-arkitekturen motsvaras inte av de tre klasserna av datamodeller. På den lägsta nivån kan man använda en fysisk datamodell för att uttrycka det fysiska schemat, och på den logiska nivån använder man en implementationsmodell för att uttrycka det logiska schemat, men på den översta nivån i tre-schema-arkitekturen, vy-nivån, uttrycks det externa schemat normalt med samma implementationsmodell som det logiska schemat. Den tredje klassen av datamodeller, konceptuella datamodeller, används inte i databashanterare. (Det finns enstaka databashanterare som arbetar direkt med en konceptuell datamodell, till exempel ER-diagram. Det förekommer också felaktiga påståenden om att någon databashanterare arbetar med ER-diagram, men då handlar det inte om riktiga ER-diagram, utan om att rita upp tabeller --- som ju hör till implementationsmodellen --- på ett sätt som har vissa likheter med ER-diagram.)

Olika typer av användare

• Expertanvändare använder databasen ofta, kanske dagligen. De är väl insatta i databasens uppbyggnad och databashanterarens funktion, och sitter kanske och skriver SQL-frågor.
• Tillfälliga eller naiva användare kan inte lika mycket om databasen, kanske för att de använder den mer sällan. De behöver enklare och mer nybörjarvänliga verktyg än experterna. Man kan inte kräva att alla biljettförsäljare på SJ ska lära sig SQL. (Termen "naiv användare" betyder förstås inte att personerna i fråga är naiva i största allmänhet, ifall någon nu trodde det, utan bara att de inte har en djup förståelse just när det gäller databassystemet.)
• Databasadministratören, förkortat DBA, ansvarar för databasens drift, ungefär som en systemansvarig för vilket datorsystem som helst. För stora databassystem kan det vara en hel grupp av DBA-personal. DBA-personalen utformar och förändrar databasschemat, registrerar nya användare, och ser med olika justeringar till att databassystemet fungerar bra och effektivt.
• Andra datorprogram. Det är inte ovanligt att en del av databasens "användare" är andra datorprogram, som hämtar data från databasen, och skickar data till den. En del databaser har inga mänskliga användare alls, utan det är bara ett eller flera datorprogram som använder sig av dem. Kanske kommunicerar de där andra programmen sen i sin tur med människor, men inte ens det är säkert.

Databashanterare - hur?

Det är också vanligt att en databashanterare innehåller verktyg för att bygga applikationsprogram. Ett applikationsprogram är ett program som är avsett för ett specifikt ändamål, till exempel för att låta biljettförsäljarna på SJ boka tågresor. I det här sammanhanget tänker vi oss att alla data lagras i en databas som hanteras av databashanteraren, och applikationsprogrammet kommunicerar med databashanteraren, men applikationsprogrammet är enklare att använda för biljettförsäljaren. I det programmet kan man kanske klicka på knappar för att välja resmål. Det är lättare än att kommunicera med databashanteraren direkt, i värsta fall genom att skriva SQL-kommandon. Med verktygen för att bygga applikationsprogram kan man (mer eller mindre enkelt) sätta ihop ett sådant program, kanske utan att man behöver skriva någon programkod.

Applikationsprogrammerare är ännu en typ av databasanvändare. Applikationsprogrammeraren tillverkar applikationsprogram, antingen med hjälp av särskilda verktyg eller genom att skriva program i ett vanligt programmeringsspråk med inlagda anrop till databashanteraren.

En normal databashanterare lagrar alla data på disk, och hämtar bara in de data som den för tillfället behöver till primärminnet. Men det finns också databashanterare som har alla data i primärminnet hela tiden.

När man installerat en databashanterare på sin dator, kan den ofta hantera flera olika databaser samtidigt. Varje databas består egentligen av två samlingar data: dels databasens innehåll, dels schemat. Schemat kallas också datakatalog eller meta-data, vilket betyder "data om data".

De viktigaste begreppen

data, information, kunskap, databas, databashanterare (DBMS), schema, datamodell, SQL, fråga, frågespråk, logiskt dataoberoende, fysiskt dataoberoende, tre-schema-arkitekturen, gränssnitt, vy, konceptuell datamodell, implementationsmodell, relationsmodellen, DBA, applikationsprogram, applikationsprogrammerare, datakatalog, meta-data

Litteratur

• Padron-McCarthy/Risch, kapitel 1
• Connolly et al, fjärde upplagan: kapitel 1-2
• Date, åttonde upplagan: kapitel 1-2
• Elmasri/Navathe, fjärde upplagan: kapitel 1-2
• Silberschatz et al, fjärde upplagan: kapitel 1