Databaser: Introduksjon til databaser og filsystemer

Fjernundervisning fra AITeL - HiST Databaser: Introduksjon til databaser og filsystemer 27. juni 2002, Kjell Toft Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å bruke leksjonene til undervisning eller kursformål må ta kontakt med forfatter for nærmere avtale. Copyright: Kjell Toft Hansen/TISIP HVOR BRUKES DATABASESYSTEM...2 FILBASERTE SYSTEM...2 PROBLEMENE VED FILBASERTE SYSTEM...4 DATABASER...4 DATABASESYSTEM...5 HVA INNEHOLDER ET DBMS...6 Programvare og applikasjoner...6 Hvilke personer er involverte i DBMS...7 Datauavhengighet...7 Prøve å unngå dataduplikasjon...8 Effektive søk etter data...8 SQL...8 DATABASEARKITEKTUR...8 Det eksterne nivå...10 Det konseptuelle nivå...10 Det interne nivå...10 DATAMODELLER OG KONSEPTUELL MODELLERING...11 POSTBASERTE DATAMODELLER...11 Relasjonsmodellen...11 OBJEKTBASERTE DATAMODELLER...12 Entity-Relationship modellen...12 FLERBRUKER DBMS-ARKITEKTUR...13 DISTRIBUERT DATABEHANDLING...13 Distribuert bearbeiding...15 LITTERATURLISTE...16 filnavn: leksjon_01

Hvor brukes databasesystem Databaser og databasesystem har blitt en viktig del av hverdagen i et moderne samfunn. I løpet av én dag vil mange av oss utføre aktiviteter som involverer en samhandling med en database. Det kan være bruk av kreditt- eller debetkort ved varekjøp på supermarkedet eller uttak av kontanter i en minibank, ved bestilling av en fly- eller togreise via et reisebyrå, låne bøker på biblioteket, tegne forsikring på vår nye bil eller ved immatrikulering på universitet. Databaser brukes over alt der det er behov for å lagre en viss mengde data og der det er behov for å hente ut disse dataene til forskjellige formål. Tenk bare på alle registrene som du selv er ført opp i: Folkeregister, førekortregister, register over ansatte, bokklubber, abonnementer på tidsskrifter og aviser, banker, forsikringsselskaper etc. Alle disse registrene er laget ved hjelp av et databasesystem. Mindre bedrifter og enkeltpersoner kan også ha behov for å lage et databasesystem som holder oversikt over personer eller gjenstander. Det kan f.eks. være firmaets produkter eller et idrettslags sine medlemmer. Men det kan også være at det er du som ønsker å lage en oversikt over alle objektene i samlingen din, enten det er grammofonplater eller frimerker. Det å lage en database er ikke noe nytt som kun er knytt til vår elektroniske tidsalder. Det å lagre data systematisk på kartotekkort var en vanlig teknikk lenge før vi fikk datamaskinen. Senere, når den teknologiske utviklingen gjorde det mulig for større organisasjoner å lagre og behandle store datamengder, fikk vi de såkalte filbaserte systemene. Disse systemene overtok for de manuelle kartoteksystemene. Filbaserte system Kjennetegnet på filbaserte system er at de består av en samling applikasjonsprogram som utfører tjenester slik som for eksempel produksjon av rapporter for sluttbrukeren. Hvert program definerer og behandler sine egne data. De var det vi kan kalle for desentraliserte system, hver avdeling hadde sine egne data og sine egne program og system. Copyright: Kjell Toft Hansen 2

Figur 1 viser en skjematisk beskrivelse av et filbasert system. Ordreavdeling Regnskapsavdeling Progam A Progam B Progam C Progam A Progam B Ordresystem Fakturasystem Kunde-fil Varelager_pris-fil Ordre-fil Varelager-fil Kunde-fil Figur 1: (Fritt oversatt fra McFadden s. 8) Fra disse systemene fikk vi begrepene data, felt, post og fil som er beskrevet i tabellen under. Data Felt Post Fil Et tegn, d.v.s. en bokstav, tall 0 til 9 eller et symbol (?,+,-,*,&, o.l.). Inneholder et sett med tegn som gir en viss logisk mening. F.eks. et navn, tall, dato, klokkeslett, kode o.a. Sier noe om tings egenskaper. Et sett med felt som hører sammen. Relaterte poster som naturlig hører sammen. F.eks. alle medlemmene i en sportsklubb, ansatte i en bedrift, alle varene på et lager. En fil er altså en samling poster som inneholder logiske data. Hver post består av et logisk sett tilknyttete felt. Hvert felt representerer karakteristiske egenskaper som tilhører objekter fra den virkelige verden. Copyright: Kjell Toft Hansen 3

Filstrukturen for en sportsklubb kan se ut som tabellen under: Navn Adresse Telefon Alder Bet_kont Hagen Nina Grønnergata 3... 83111111 25 1994 Holm Grethe Oslogata 2... 83101010 31 1994 Larsen Eva Brattgata 17... 83777777 34 1993 Nilsen Gunnar Bakkegata 2... 83700000 34 1993 Nilsen Per Bakkegata 14... 83733333 28 1994 Olsen Ole Grønnegata 3... 83111111 36 1993 Problemene ved filbaserte system I et filbasert system er data isolerte i separate filer og det er vanskelig å hente dem fram og kombinere dem. Det kan også oppstå duplisering av data også kalt redundans, dvs. at samme data kan være lagret flere plasser. Dette kan igjen lett føre til at data blir inkonsistente. Vi endrer data ett sted, men kan glemme å endre de samme data som er lagret på en annen fil. Definisjonen av data ligger inne i applikasjonsprogrammet og er ikke lagret uavhengig og separat. Dermed blir data avhengig av programmet. Ofte er det også slik at disse programmene også inneholder faste spørringer. Og for hver ny spørring må et nytt applikasjonsprogram utvikles. Det er ingen kontroll over tilgang og behandling av data ut over det som er implementert i applikasjonsprogrammet. Ofte kan data ligge på ulike filformat; det kan være brukt ulike programmeringsspråk som oppretter ikke-kompatible filformat. Databaser Databasene erstattet de filbaserte systemene. Teknologisk sett er de en langt mer avansert løsning. En database kan defineres som en samling av logiske data som hører sammen og som er en beskrivelse av disse data, designet for å møte informasjonskravene i en organisasjon. En database er et enhetlig lager av data som blir definert én gang og blir brukt samtidig av mange avdelinger og brukere. Dataene i databasen er kjente fakta som kan lagres og som kan si noe om en organisasjon, dvs. ha en mening eller rolle i denne. Et ikke-elektronisk eksempel på en database med data er et kartotek over f.eks. medlemmene i en sportsklubb. En kan tenke seg at hvert kort i kartoteket inneholder opplysninger om et medlem. Aktuelle opplysninger kan være navn, adresse, telefonnummer, medlemsnummer, alder og om vedkommende har betalt medlemskontingent for inneværende år. Copyright: Kjell Toft Hansen 4

Databasesystem 1 Et DBMS er en samling programmer som gjør det mulig å lage og bruke en database og som sørger for en kontrollert tilgang til databasen. DBMS holder rede på tabellene 2 for oss, samt databasens struktur. DBMS, som er brukerens grensesnitt til databasen, er en samling av programvare som tar seg av all tilgang til databasen. Framgangsmåten er som følger: 1. En bruker kommer med en forespørsel vha. et spørrespråk 3. 2. DBMS oppfanger forespørselen og analyserer den. 3. DBMS undersøker det eksterne skjema 4, utfører mappingen 5 mellom det eksterne skjema og de andre skjemaene ned til definisjonen av den lagrede strukturen. 4. DBMS utfører de nødvendige operasjonene på den lagrede databasen. Denne framgangsmåten er framstilt skjematisk i Figur 2. Databaseadministrasjons-lag Applikasjons-lag Brukergrensesnitt-lag Applikasjon 1 Databaseadministrasjon 1 Applikasjon 2 Brukergrensesnitt 1 Databaseadministrasjon 2 Brukergrensesnitt 2 Brukergrensesnitt 3 Figur 2: En tre-lags arkitektur som klart og tydelig skiller dataadministrasjon, applikasjonslogikk og brukergrensesnitt fra hverandre (Blaha, p. 21). 1 DBMS (Database Management System) 2 Data ligger lagret i tabeller i databasen - forklares senere 3 SQL: Structured Query Language 4 Brukerens grensesnitt mot databasen - forklares mer detaljert senere 5 Koble sammen skjemaene og definere samsvaret mellom skjemaene Copyright: Kjell Toft Hansen 5

Hva inneholder et DBMS DBMS inneholder et Data Definition Language (DDL). Dette er et språk som brukes til blant annet å spesifisere databaseskjemaet 6. DDL er et beskrivende språk som gir DBA og superbrukere muligheten til å beskrive og navngi tabeller og sammenhengen mellom tabellene som er nødvendige for applikasjonen. Videre inneholder DBMS et Data Manipulation Language (DML). DML er et språk som inneholder et sett av operasjoner som støtter grunnleggende datamanipulerende operasjoner på dataene i databasen som for eksempel det å legge data inn i databasen, endre data og hente ut data. Et DBMS må også inneholde en datakatalog, dvs. en metadatabase som består av definisjoner av andre objekter enn selve rådataene som for eksempel tabellene, skjemaene, mappingene 7 og informasjon om adgang. I tillegg må et DBMS inneholde komponenter som ivaretar dataintegritet, datasikkerhet, berging av data, ytelse: en effektiv gjennomføring av de ulike funksjonene, tilslutninger og dataabstraksjoner. Programvare og applikasjoner DBMS gir et grensesnitt mot såkalte applikasjoner. En applikasjon er et program som bruker data lagret i en gitt database. Typisk for en applikasjon er at den har et grafisk brukergrensesnitt 8 tilpasset behov hos én bestemt gruppe sluttbrukere. Brukerne kan via brukergrensesnittet få for eksempel de ønskete opplysninger om en ansatt i bedriften opp på dataskjermen. Tradisjonelt er applikasjoner implementert utenfor selve DBMS ved hjelp av programmeringsspråk som C++, Java eller Visual Basic. Men de fleste DBMS i dag 9 tilbyr muligheter for å lage applikasjoner direkte i selve DBMS. En lager da såkalte skjema hvor brukere kan få ønskete data opp på skjermen ved å klikke på knapper eller velge i nedtrekksmenyer. En annen løsning er bruk av World Wide Web som et grensesnitt mot en database. Selv om WWW i dag gir visse begrensninger i hvor avanserte brukergrensesnitt kan lages, er det mulig å lage relativt fine skjema i WWW-språket HTML. Dersom dette skal fungere mot en database, brukes ofte en bestemt type kobling, et såkalt CGI 10, mellom Webtjeneren og DBMS. I dag finnes det CGI-løsninger for alle kjente DBMS. Det finnes en rekke informasjonsdatabaser på WWW, som er mer eller mindre åpne for alle brukere av Internett. Slike løsninger kan også brukes til såkalte elektroniske betalingstjenester ved at en kan bestille varer fra et sentralt vareregister via WWW. Et problem med CGIløsninger er sikkerhetsrisikoen. Det kan være vanskelig å kontrollere bruken av en slik åpen tilgang til en database. På den andre siden gir DBMS også et grensesnitt mot databasestrukturen, som logisk sier hvordan data i databasen faktisk er lagret på filer på det fysiske mediet. Tabeller er en kjent måte å betrakte denne logiske strukturen på. Vi kan logisk betrakte databasen 6 Definere en database, tabeller og utsnitt 7 Samsvaret mellom de ulike skjemaene 8 GUI 9 Bl.a. MS-Access 10 Common Gateway Interface Copyright: Kjell Toft Hansen 6

som en mengde tabeller med data, uten å tenke på hvordan dataene fysisk er lagret på filer. DBMS tar seg altså av filbehandlingen, noe som er en stor fordel både for de som utvikler sine egne databaser og vanlige brukere av databaser. Hvilke personer er involverte i DBMS DBA 11 er ansvarlig for den totale kontrollen av systemet på teknisk nivå. I jobben med å implementere datastrategien vil følgende momenter være viktige: Definere det konseptuelle skjema 12. DBA bestemmer eksakt hvilken info databasen skal inneholde. Dette kalles logisk eller konseptuell databasedesign. Definere det interne skjema. DBA må også bestemme hvordan data skal være representert i den lagrede databasen, såkalt fysisk databasedesign. Kommunisere med brukere; konsultasjon, utdanning, hjelp til å skaffe opplysninger om hvilke data brukeren trenger. Definere sikkerhets- og integrasjonskontroller. Definere sikkerhetskopi og beregningsprosedyrer. Overvåke ytelse og reagere på endrede krav. Andre som er involverte er dataadministrator 13, databasedesigner, applikasjonsprogrammerere og sluttbrukere. Datauavhengighet Det vil ofte være slik at flere applikasjoner bruker en del av de samme dataene. En bedrift kan ha en applikasjon for å regne ut lønn til de ansatte (et lønnssystem), en annen applikasjon som registrerer hvor mange timer overtid ansatte jobber og en applikasjon for å regne ut bonus til de ansatte som er selgere. Alle disse applikasjonene bruker lagrede personopplysninger om de ansatte. Fordelen med et DBMS er at generelle data om de ansatte kan fysisk være lagret på én fil. Vi unngår derfor dobbeltlagring av data. I tillegg vil alle brukerne av databasen vite om endringer som er gjort av en applikasjon. En database kan være et såkalt flerbrukersystem, med mange applikasjoner som bruker mye av de samme dataene. Dette må administreres, og det er en stor trøst at databasesystemet tar seg av dette. 11 Databaseadministrator 12 Se kapittlet: Databasearkitektur 13 DA Copyright: Kjell Toft Hansen 7

Prøve å unngå dataduplikasjon Et problem i et filsystem er at samme data kan lagres flere plasser. Læreboka nevner såkalt data redundans, det vil si at samme felt forekommer i flere tabeller. Videre kan de oppstå problemer knyttet til dataintegritet (samme person har to ulike telefonnummer i to forskjellige tabeller). Det kan også oppstå problemer ved endringer og slettinger av data i en tabell dersom for eksempel en selger slutter. Hva da med alle kundene til den selgeren? Dette er vanskelige begreper å forstå innledningsvis. Alt dette kommer vi tilbake til senere i kurset. Poenget nå er at når vi skal designe databaser, er dette problemer vi må ta hensyn til. Ved å bruke et DBMS på en fornuftig måte, vil en kunne unngå mange av de ovennevnte problemene. Effektive søk etter data En viktig egenskap ved DBMS er at de har optimaliserte rutiner for å lagre og ikke minst søke etter data på det fysiske mediet. Dette betyr at et DBMS vil, under en del gitte forutsetninger, hente ut data raskt og effektivt. Dersom du lager ditt eget filsystem, må du selv lage rutiner (algoritmer) for å søke etter data på filene. Hvis du for eksempel er en profesjonell C++ programmerer, vil du sikkert kunne lage raske søkerutiner som kan konkurrere med DBMS sin rutine. Men å lagre data i en database er en enklere løsning i de fleste tilfellene. SQL En annen viktig egenskap ved de aller fleste DBMS er på markedet i dag, er at de gir støtte for spørrespråket SQL. Det gir muligheten til å aksessere og endre på data i databasen på en relativt enkel måte. Har man først lært SQL, vil en kunne hente data ut fra databaser i ulike DBMS er. En slik standard finnes ikke blant vanlige programmeringsspråk. Databasearkitektur Den databasearkitekturen vi skal bruke i dette kurset bygger på ANSI/SPARC 14 - arkitekturen. Denne arkitekturen representerer en abstrakt og generell måte å betrakte data på. Behandlingen av data er uavhengig av lagringsstruktur. Brukeren trenger ikke å vite noe om organiseringen av data for å behandle de samme data. En tenker her på fysisk rekkefølge, om vi utvider med nye kolonner eller rekker i databasen og enhver annen omorganisering av databasen. ANSI/SPARC skiller mellom lagringsstruktur og logisk struktur. Vi oppnår med dette logisk og fysisk datauavhengighet. Dette er en meget ressurskrevende arkitektur. 14 American National Standard Institute/Standard Planning and Requirements Committee Copyright: Kjell Toft Hansen 8

ANSI/SPARC-arkitekturen, er delt i tre nivåer: Internt nivå: Dette nivået representerer det nærmest vi kommer den fysiske lagringen av data. Sier noe om hvordan dataene er lagret fysisk. Eksternt nivå: Dette nivået ligger nærmest brukeren. Beskriver den måten dataene sees av brukerne. Konseptuelt nivå: En kobling av de to andre nivåene. Her representeres databasen på modellnivå - en abstrakt framstilling av hele databasen. Applikasjons program Applikasjons program Spørregenerator Bruker/Eksternt skjema A Bruker/Eksternt skjema B Bruker/Eksternt skjema C "Mapper" eksternt skjema A med konseptuelt skjema "Mapper" eksternt skjema B med konseptuelt skjema "Mapper" eksternt skjema C med konseptuelt skjema Konseptuelt skjema "Mapper" konseptuelt og internt skjema Internt/Fysisk skjema Database Figur 3: ANSI/SPARC arkitekturen (Beynon-Davis s. 38) Samlet blir de tre lagene kalt arkitekturens skjema 15. 15 Den totale beskrivelsen av databasen de tre nivåene. Copyright: Kjell Toft Hansen 9

Det eksterne nivå Det eksterne nivå er databasen slik den ser ut for en enkelt sluttbruker. Utsnittet kan bestå av sammensatte forekomster av ulike typer av logiske data. Hver sluttbruker har sitt språk til rådighet. Det kan være et spørrespråk eller et spesialtilpasset språk som er skreddersydd brukerens krav og støttet av et online program. Språket blir ofte kalt et Data Sub Language 16 og tar seg av databaseoperasjoner. Hvert DSL vil minst bestå av et DDL for deklarasjon av databaseobjekter og et DML for manipulering med objektene. Det kan være mange ulike eksterne utsnitt av deler av den totale databasen. Det eksterne nivå er uavhengig av det konseptuelle. En kan derfor utføre endringer i det konseptuelle nivå som vil gjenspeile seg i det eksterne nivå. Det konseptuelle nivå Det konseptuelle nivå viser hele informasjonsinnholdet i databasen. Det viser databasen slik den virkelig er, men allikevel mer abstrakt enn den måten dataene er fysisk lagret på. Her ser brukeren data som entitetstyper og tabeller, attributter og kolonner og sammenhengstyper og referanseintegritet. Sikkerhets- og integritetskontroller klargjøres også på det konseptuelle nivået. Brukeren på dette nivået er DBA. Om man skal oppnå datauavhengighet må det ikke være referanser i det konseptuelle skjemaet 17 til fysisk datastruktur eller tilgangsmetoder. De samme objektene kan gjerne ha ulike navn på hvert nivå. Den konseptuelle/interne mappingen definerer samsvaret mellom det konseptuelle nivået og den lagrede databasen på interne nivå. Tilsvarende er det mellom eksternt og konseptuelt nivå. Det interne nivå Det interne skjemaet, som beskriver det interne nivået, definerer de ulike typer av lagrede poster, indekser som finnes, hvordan lagrede poster er representert, den fysiske rekkefølgen til postene som skal lagres etc. Det interne nivå er et skritt unna det fysiske nivå hvor en definerer sider, blokker eller størrelsen på spor og sylindrer for en post. 16 DSL 17 Dokument som inneholder definisjoner av det konseptuelle nivået. Copyright: Kjell Toft Hansen 10

Datamodeller og konseptuell modellering En datamodell er en integrert samling av begreper som beskriver data, sammenhengen mellom data og regler som er knytt til data i en organisasjon. Den prøver å gi en abstraksjon over den virkeligheten vi ønsker å lagre data om. Virkeligheten er så kompleks, at den informasjonen vi klarer å lagre i en database vil uansett bli en forenkling av den. Men jo bedre informasjonen er strukturert, jo enklere er det å nyttiggjøre seg de mulighetene en database gir til for eksempel søk og analyse av data. Derfor er det lurt å ha en oversikt over hvilke typer informasjon vi ønsker å ha med i databasen. En datamodell er ment å gi en slik oversikt. Det er to datamodeller dette kurset omhandler, nemlig relasjonsmodellen og Entity-Relationship-modellen 18. Det ligger i navnene at disse to modellene har en del fellestrekk. Relasjonsmodellen er et resultat av en bestemt matematisk algebra, og er den modellen MS-Access og de fleste andre DBMS ene på markedet i dag bygger på. Dette er en såkalt postbasert datamodell. Modellen består av følgende komponenter: strukturdel, manipuleringsdel og integritetsregler. ER-modellen er en såkalt objektbasert datamodell, og brukes til datamodellering uavhengig av hvilket DBMS vi ønsker å realisere databasen i. Postbaserte datamodeller Følgende datamodeller regnes som postbaserte datamodeller: Nettverksdatamodeller, hierarkisk datamodeller og relasjonsmodellen. Relasjonsmodellen STUDENT STED Studnr Etternavn Fornavn Adresse Postnr Postnr Poststed primærnøkkel fremmednøkkel primærnøkkel 18 ER-modellen Copyright: Kjell Toft Hansen 11

Denne modellen er basert på matematiske relasjoner 19. Data og relasjoner blir presentert som tabeller og bare tabeller. Tabellene knyttes sammen ved hjelp av primærnøkkel / fremmednøkkel. Objektbaserte datamodeller Entity-Relationship, semantiske-, funksjonsorienterte- og objektorienterte datamodeller tilhører objektbaserte datamodeller. Entity-Relationship modellen Enhver datamodell som brukes i databasesammenheng sier noe om entiteter. En entitet er et objekt som vi ønsker å lagre informasjon om. Et eksempel er entiteten Eva Hansen i Figur 4. En entitet vil ha en del egenskaper, representert som en mengde med attributtverdier. Tradisjonelt er dette rene fakta om entiteten som for eksempel etternavn, fornavn, adresse etc. I tillegg vil en entitet ha en eller flere sammenhenger til andre entiteter i databasen. Det er for eksempel en sammenheng mellom entiteten Eva Hansen og entiteten 7000 Trondheim. Vi skal senere i kurset komme tilbake til hvordan dette kan designes både i relasjonsmodellen og ER-modellen. Entitet: Eva Hansen Attributt verdier: Hansen Eva Prinsens gt. 10 Sammenheng til andre entiteter: 7000 Trondheim Figur 4 Det er viktig å skille mellom entitetstyper og entiteter. En entitetstype sier noe om hvilke data vi kan lagre i attributtene, hvilke sammenhenger vi tillater og hvordan dette skal identifiseres i databasen. Figur 4 illustrerer svært overfladisk sammenhengen mellom definisjonen av attributtene og verdiene til entiteten Eva Hansen. Deretter kan vi si at Eva Hansen er en entitet av en bestemt entitetstype. Denne entitetstypen kan vi kalle Student. Dette er illustrert i Figur 5 som er en liten ER-modell 20. 19 Tabeller 20 Symbolbruken kommer vi tilbake til i en senere leksjon. Copyright: Kjell Toft Hansen 12

Student +student_nr {PK} +etternavn +fornavn +adresse * +bor på 1 Sted +postnr {PK} +poststed Figur 5 Flerbruker DBMS-arkitektur Denne arkitekturen bruker kapasiteten som finnes i arbeidsstasjoner og tjenere, ved at disse blir benyttet som intelligente, programmerbare enheter, noe som gjør at all den prosesseringskraften som er tilgjengelig, blir utnyttet. Dette gjøres ved å dele opp en oppgave i to prosesser; en klientdel og en tjenerdel. Klientdelen, som normalt vil være et standard PC-program, presenterer og manipulerer data på arbeidsstasjonen, mens tjenerdelen lagrer, henter og beskytter data på samme måte som på stormaskin. Distribuert databehandling I de siste årene har en gått mer og mer over til såkalte klient/tjener-løsninger og distribuerte løsninger. Ikke minst gjelder dette i databasesammenheng. Klient/tjener modellen splitter applikasjonen i en klientapplikasjon og en tjenerkomponent. Klientapplikasjonen samler spørsmål/data fra brukeren, forbereder dem for tjeneren, og gjør deretter en forespørsel 21 til tjeneren. Tjenerkomponenten venter på sin side på forespørsler fra sine klienter. Når dette skjer, prosesserer tjeneren forespørselen, og returnerer resultatet til klienten. Klienten presenterer til slutt dataene for brukeren gjennom sitt eget brukergrensesnitt. Det mest vanlige er at selve DBMS og det fysiske lageret er en integrert del av database-tjeneren, mens en sprer applikasjonene rundt på mindre maskiner i et datanett. Disse applikasjonene kalles da klienter. De ulike brukerne kan kjøre applikasjoner på sine lokale maskiner, mens selve databasen kan være lagret på en UNIX-maskin i et nett PC ene er tilkoblet. Dette betyr at brukerne ikke trenger å være logget på tjenermaskinen hele tiden, noe som ofte gir en mer effektiv løsning. En annen fordel er at klientene kan tilpasses ulike brukergruppers behov til både programvare og maskinvare. 21 Ved bruk av SQL Copyright: Kjell Toft Hansen 13

Figur 6 illustrerer en klient/tjener-arkitektur. Database Databaseadministrasjon Administrasjon av regler Klient Mellomvare Programvare for kommunikasjon LAN Internett Programvare for kommunikasjon Mellomvare Tjener Applikasjonslogikk Presentasjonslogikk Figur 6: Klient-tjener (Beynon-Davis s. 333) Med en klient/tjenerløsning menes det m.a.o. at flere maskiner knyttes sammen i et kommunikasjonsnettverk slik at databearbeiding kan foretas ved flere maskiner 22. En situasjon med bare én tjenermaskin og flere klientmaskiner er altså kjent som et klient/tjener system. Tjeneren fordeler arbeidsoppgavene utover nettet. Denne arkitekturen kan ha flere fordeler: Vi er ikke bundet til en bestemt maskinvare. Vi sparer trafikk på nettverket. Bare resultatet av en ev. spørring blir sendt tilbake. Sortering etc. foregår bare på tjeneren. Database- og applikasjonsprosesseringen kan kjøres parallelt. Tjeneren kan være spesialtilpasset DBMS et som igjen gir økt ytelse. Klientmaskinen kan være tilpasset brukerens behov. En database kan deles av flere ulike klientapplikasjoner. Reduserte utviklingskostnader: alle prosedyrer deles av alle applikasjoner. Redusert vedlikehold: regler endres bare et sted, i tjeneren. Større pålitelighet: logikken og foretningsreglene er uavhengige av klientapplikasjonen. Større sikkerhet: regler og data beskyttes fra uautorisert bruk. 22 Parallel prosessering Copyright: Kjell Toft Hansen 14

I databasesammenheng kjøres både DBMS og alle applikasjonene på tjeneren, og alle brukere må logge seg inn på denne for å kjøre applikasjoner eller hente data direkte fra DBMS. Dette kalles en sentralisert løsning, og fører til at belastningen på denne ene maskinen blir stor, dersom flere brukere er logget på samtidig. Distribuert bearbeiding Det er også mulig at en klient kan få tilgang til flere tjenere, maskinene er både klienter og tjenere. Dette kan gjøres på to måter: Et klientprogram kan få tilgang til bare et tjenersystem av gangen. Brukeren må vite hvem av tjenersystemene som har de ønskede dataene. Et klientprogram kan få tilgang til flere tjenersystem samtidig. Det vil se ut for brukeren som ett system og det er ikke nødvendig å vite hvor dataene er. Dette kalles et distribuert databasesystem. Copyright: Kjell Toft Hansen 15

Litteraturliste Beynon-Davis, P. (2001): Database Systems, Second Edition, Macmillan. Blaha, M.R. (2001): A Manager s Guide to Database Technology, Building and Perchasing Better Applications, Prentice Hall. Date, C. J. (1995): Introduction to Database Systems, Sixth Edition, Addison-Wesley. Elmasri, R., Navathe, S. (1999): Fundamentals of Database Systems, Third Edition, Addison-Wesley. Conolly, T., Begg, C., Strachan, A. (1998): Database Systems, A Practical Approach to Design, Implementation, and Management, Addison-Wesley. Mallaug, Tore (1998): Introduksjon til databaser og filsystemer, TISIP. McFadden, F.R., Hoffer, J.A., Prescott, M.B. (1999): Modern Database Management, Fifth Edition, Addison-Wesley. Rob, P., Coronel, C. (1997): Database Systems, Design, Implementation and Management, Third Edition, Course Technologies. Copyright: Kjell Toft Hansen 16