OM DATABASER DATABASESYSTEMER

Transkript

1 OM DATABASER DATABASESYSTEMER Begrepet database brukes på flere måter, og det er ikke uvanlig å bruke det for å angi en total samling av data (i dette tilfellet lagrede opplysninger) uavhengig av hvordan den er lagret eller finnes; for eksempel en bedrifts database. Likevel brukes begrepet oftest mer begrenset, for eksempel knyttet til data som fra eierens eller brukerens perspektiv har en viss logisk sammenheng med hverandre og behandles som en helhet i bruk. Vi snakker derfor om regnskapsdatabasen, personaldatabasen, kundedatabasen, studentdatabasen osv. Begrepet er generelt og skjelner ikke mellom hvordan opplysningene er lagret. Noe kan finnes i bøker, noe på kartotekkort og noe i elektronisk form. På den annen side vil vi konsentrere oss om data som er lagret elektronisk, i filer, og når vi bruker begrepet til daglig er det samlinger av slike data vi omtaler. Hvorvidt databasen fremstår som en eller flere filer på et lagringsmedium (disk/diskett) vil vanligvis være avhengig av edbsystemet (databasesystemet) som brukes for databasen. Microsoft Access lagrer alle data knyttet til en database i en fil med tillegget.mdb. Denne filen har da en komplisert indre struktur av en rekke filer, som programsystemet holder orden på. Tilsvarende gjelder Sybase SQL Adaptive Server, der alle data for en database er samlet i en fil (ytre sett) med tillegget.dba, og Microsoft SQL Server som bruker.mdf. Slike filer har en omfattende indre struktur, som vi skal se etter hvert. Andre databasesystemer lagrer hver fil, enten den gjelder brukerdata, indekser eller systemdata, som en selvstendig fil synlig for enhver, og med forskjellige tilleggsnavn, slik som i DataEase (og Enterprise Developer) kunder.dbm for kundedata; kunder, dba for skjemabeskrivelsen, kunder.i01 for indeks nr 1, og repo.dbr for oversikt over lagrede rapporter osv. Siden en slik edbbasert samling av data i mange tilfeller samles i en fil, knyttes gjerne databasebegrepet i praksis til denne. En snakker derfor også om å kople data sammen fra flere databaser, når en oppretter elektroniske forbindelser mellom dem som gjør at en får tilgang til data fra alle basene. Siden faget konsentrerer seg om det edb-baserte, vil vi i hovedsak bruke begrepet databaser som synonymt med edbdatabaser. Husk likevel at databasebegrepet egentlig er 1. generelt, dvs gjelder uavhengig av hvordan / hvor dataene er lagret 2. avgrensningen av hvilke data som inngår er relativ, og bestemmes av hva som er praktisk database, en samling data som anses og behandles som en helhelt I forbindelse med edb-baserte databaser, bruker vi begrepet databasesystem eller databasehåndteringssystem (DataBase Management System, DBMS) om den totale samling av programmer og støttedata som brukes for å behandle og administrere databasen, slik som Sybase Adaptive Server, Oracle, Microsoft SQL Server, Informix, DB2 etc. Hvordan en database eller et databasesystem oppfattes, dvs. hva de regnes å omfatte, vil i tillegg ofte være avhengig av betrakterens perspektiv. Hva en studentadministrativ database omfatter vil trolig oppfattes forskjellig av en student, av en konsulent i studieadministrasjonen, og av vedkommende som er edb-teknisk ansvarlig for systemet. Det samme gjelder hvordan en database beskrives. Det er særlig to hovedhensyn som ligger til grunn for den historiske utviklingen av database systemer.

2 For det første er det en rekke fordeler med å samle data i en sentral base (sted og struktur) og så gjøre den tilgjengelig for alle som har legitime behov for dataene. Redundans (dobbeltlagring) reduseres eller om mulig unngås Inkonsistens (manglende samsvar) reduseres eller om mulig unngås Dataintegritet (gyldigheten av dataene) kan sikres Helhetlig sikkerhetskontroll kan etableres og påtvinges systemet Motstridende hensyn kan søkes avveid (balanseres) på en helhetlig måte Standarder kan implementeres og overholdes bedre For det andre er det viktig å skille datastrukturen og lagringen fra tilgangen til og behandlingen av dataene (sikre datauavhengighet) ivaretar fleksibiliteten i bruken og tillater endringer i strukturen. Hierarkisk - og nettverksdatabase To typer av databasestrukturer, som kan ses som historiske forløpere til relasjonsdatabaser, er hierarkisk og nettverk. Slike er basert på faste, forhåndsdefinerte strukturer og som etableres og vedlikeholdes når nye data registreres og registrerte data endres. Når vi så skal bruke dataene (søke og finne igjen), vil vi raskt og effektivt kunne gjøre det hvis våre behov/ønsker passer med den lagrede strukturen. Har vi behov for å søke etter eller samle data på andre måter, kan det være både vanskelig og en omfattende, tidkrevende oppgave. Vi trenger et eller flere eksempler på databaser med oversikt over hva slags data de kan eller bør inneholde. Relasjonsdatabase En kunne derfor ønske seg et databasekonsept, som: ikke favoriserer eller forutsetter bestemte søke- og gjenfinningsbehov (strukturer) ikke forutsetter at dataene må lagres i noen bestemt rekkefølge, eller holdes ordnet på bestemte måter (dvs. ikke må flyttes for å opprettholde en bestemt orden/rekkefølge) er basert på en enkel struktur, der alle data er selvstendige, udelelige (atomistiske) og direkte (eksplisitte). Direkte i betydningen at de virkelig representerer den opplysningen vi ønsker å lagre, ikke bare en peker til den. Løsningen på dette ble i sin tid: relasjonsdatabaser Relasjonsdatabaser - kjennetegn Oppfattes som bestående av tabeller og bare tabeller Radene i en tabell er usorterte, ingen krav til ordnet rekkefølge nye rader settes inn til slutt eller en skriver over rader som skal slettes. Alle data i tabellene er atomiske ("udelelige"); dvs. hver rad/kolonne (felt) har kun 1 verdi repeterende r tillates ikke Alle data i en kolonne er av samme type; når datatypen er bestemt for en kolonne gjelder den for alle radene i tabellen Alle data i tabellene er eksplisitte og representerer virkelige data om entiteter (ikke bare pekere eller lignende)

3 NB: En tabell som tilfredsstiller disse kravene kalles relasjon; og en database som består av slike tabeller er da en relasjonsdatabase og det systemet som brukes for å lage og arbeide med databasen, er et relasjonsdatabase(håndterings)system. Operasjoner alltid på mengder (sett) av data, dvs tabeller eller deler av dem få operasjoner operasjoner på tabeller gir tabeller tilbake - (operasjonene er "lukket") Struktur/skranker oppnås ved: innen tabellen: Primærnøkkel (evt. andre unike i tillegg) mellom tabeller: Fremmednøkler (tilsvarer relasjonstyper i en datamodell) evt. andre, brukerdefinerte skranker Evt. indekser o.l. er bare til hjelp for hastighet, ikke nødvendige for bruk av dataene. Hoveduttrykk i forbindelse med en relasjon (skisse av Edgar Bostrøm, MetodeData As, 1997) Domene Relasjon Avdelingskode Avdelingsnavn Etasje AVDELING attributter avdkode avdnavn gammelt_avdnav etasjenr 1 Parfymeri Bijouteri 1 4 Herreklær Herreekvipering 1 3 Skotøy Skotøy og sokker 5 2 Kjøkkensaker Kjøkken 8 5 Sengetøy Tepper og sengetøy 5 her = 5 grad (aritet), her = 4 attributtverdi (for en rad/kolonnekobling) Tupler kardi- nalitet Relasjonshode (entitetstype, tabellhode) Relasjonskropp (entitet, forekomst)

4 Attributt: Kolonne i en relasjon (felt, field); og doméne (domain) er samlingen (settet) av alle gyldige verdier i en kolonne. Tuppel (tuple): Rad i en relasjon (post, record).

5 Transparent 1 Databasesystem deltakende personr og perspektiver Desktop System Sun SPARC Monitor Multimedia PC Laptop computer (Brukere - brukerr) Applikasjonsutviklere DBMS Systemadministrator Database (strukturbeskrivelser egentlige data applikasjonsprogrammer systemdata)

6 Transparent 2 En databases struktur - hovednivåer Eksternt nivå Konseptuelt nivå Felles/total (logisk totalstruktur) Internt nivå System/lagring (systemavhengig 'fysisk' struktur)