DBS1: Databases and database users

Side 1 for Databaser DBS1: Databases and database users onsdag 10. februar 2016 23.25 Databaser og databasebrukere Forskjellige typer databaser Tradisjonell database: Informasjonen er enten tekstlig eller numerisk. Big data / NOSQL: Brukes ofte i forbindelse med sosiale medier, eller skylagring. Litt flere applikasjoner Multimedia databaser: For lagring av bilder, videoer og audio. Geographic Information Systems (GISs): Brukes for å lagre og analysere kart, værdata og satellittbilder. Data-varehus og Online Analytical Processing (OLAP): Brukes av selskaper til å utvinne og analysere forretningsinformasjon fra store databaser som hjelp ved bestemmelser. 1.1 Introduksjon Databaser og data Manuelt styrt eller datastyrt Databasehåndteringssystem DBMS, database management system En database er en samling av data. Data er kjente fakta som kan lagres og har en implisitt mening. En database har følgende egenskaper: Representerer aspekter ved den ekte verden, ofte kalt miniverden eller universe of discourse (UoD). En database er en logisk samling av data som gir mening. En database er designa, bygd og fylt med data til et spesifikt formål. For at en database skal være korrekt og pålitelig, må endringer som skjer i miniverdenen skje i databasen så fort som mulig. En database kan være manuelt styrt eller datastyrt (og vi er interessert i sistnevnte). Et databasehåndteringssystem er et datastyrt system som gjør det mulig for brukere å lage og opprettholde en database. DBMS skal kunne definere, konstruere, manipulere og dele databaser blant brukere og applikasjoner. Å definere en database, involverer å spesifisere datatyper, strukturer og begrensninger. Denne blir lagret i form av en database-katalog, og blir kalt metadata. Å konstruere en database er det å lagre dataen på et lagringsmedium som blir kontrollert av DBMS-en. Å manipulere en database inkluderer funksjoner som å utføre spørringer for å hente data, oppdatere for å speile miniverdenen og å generere rapporter fra dataen. Deling av databasen gir flere brukere og programmer/applikasjoner tilgang til databasen samtidig. Andre viktige tjenester: Beskytte dataen og opprettholde den over lang tid. Man må stole på at dataen ikke forsvinner uten videre. Databasen må være i stand til å utvikle seg, når kravene

Side 2 for Databaser Applikasjoner Spesifikk DBMS Databasesystem endres. Bruker databasen til å gjøre spørringer (queries) og forespørsler om data til DBMS-en. En spørring gjør typisk at data blir hentet, og en transaksjon kan gjøre at data blir lest og skrevet til databasen. Det er også mulig å lage spesifikke databasehåndteringssystemer som fungerer for spesifikke applikasjoner. En database sammen med et databasehåndteringssystem utgjør et databasesystem. 1.2 Et eksempel Eksempelet Designe en database eller en ny applikasjon for en database står på side 6-7. Det er ikke så veldig heftig, men handler litt om forrige delkapittel. Begynner med fasen kravspesifikasjon og analyse, som blir dokumentert og gjort om til et konseptuelt design (ER-modeller er et eksempel på dette). Deretter blir designet oversatt til et logisk design som er uttrykt som en datamodell implementert i en kommersiell DBMS (for eksempel mysql). Til slutt kommer det fysiske designet, der spesifikasjoner for å lagre og få tilgang til databasen er satt. 1.3 Karakteristikker ved databasetilnærmingen Hovedkarakteristikker Ift. Tradisjonelle filsystem Selvbeskrivende natur av et databasesystem: Et databasesystem inneholder ikke kun databasen, men også en komplett definisjon av databasens struktur og begrensninger (lagret i katalogen, metadata). Altså en generell DBMS refererer til katalogen for å vite om strukturen til en database. Nyere databasesystemer (som NOSQL) kan ha metadataen som en del av dataen. I tradisjonell filprosessering er datadefinisjon typisk en del av applikasjonene. Isolering mellom programmer og data, og dataabstraksjon: Strukturen til datafilene er lagret i DBMS-katalogen, adskilt fra programmene som har tilgang til databasen. Støtte for flere views: Deling av data og mulig for flerbruker transaksjoner: 1.3.1 Selvbeskrivende natur av et databasesystem Databasesystem Et databasesystem inneholder ikke kun databasen, men også en komplett definisjon av databasens struktur og begrensninger (lagret i katalogen, metadata). Altså en generell DBMS refererer til katalogen for å vite om strukturen til en database. Filsystem Nyere databasesystemer (som NOSQL) kan ha metadataen som en del av dataen. I tradisjonell filprosessering er datadefinisjon typisk en del av applikasjonene.

Side 3 for Databaser 1.3.2 Isolering mellom programmer og data, og dataabstraksjon Programdatauavhengighet Programoperasjonuavhengighet Dataabstraksjon Strukturen til datafilene er lagret i DBMS-katalogen, adskilt fra programmene som har tilgang til databasen. I noen databasesystemer (objektorienterte, objektrelasjonelle) kan man definere operasjoner på dataen som en del av databasedefinisjonen. En operasjon består av to deler: 1) Interface (grensesnitt, signatur) av operasjonen består av navnet og argumentene. 2) Implementasjonen (metoden) av operasjonen er separat spesifisert og kan endres. Brukere kan kalle på operasjonene uavhengig av hvordan de er implementert, og dette er programoperasjonsuavhengighet. Egenskapene programdatauavhengighet og programoperasjonsuavhengighet heter dataabstraksjon. En DBMS gir brukere en konseptuell representasjon av data, som ikke inkluderer hvordan dataen er lagret eller operasjonene er implementert. En datamodell er en type abstraksjon. 1.3.3 Støtte for flere brukerutsnitt (view) av dataen Brukerutsnitt, views En database har mange forskjellige brukere som kan trenge forskjellige perspektiv av dataen. Et view kan være en delmengde av dataen, eller inneholde virtuell data som er avledet fra databasefilene, men ikke eksplisitt lagret. 1.3.4 Deling av data og flerbruker-transaksjonsprossessering Flerbruker-DBMS OLTP-applikasjoner Online Transaction Processing Transaksjon Isolasjon Atomitet Må la flere brukere få tilgang til databasen samtidig. Må inneholde samtidighetskontroll-programvare (concurrency control software), for å forsikre at resultatet blir korrekt når flere brukere prøver å oppdatere data samtidig. Applikasjoner der flere kan oppdatere data samtidig. En transaksjon er et kjørende program eller prosess som inkluderer en eller flere database-tilganger, som å lese eller oppdatere databasen. Hver transaksjon ser ut til å bli kjørt isolert fra andre transaksjoner, selv om flere hundre transaksjoner kan bli kjørt samtidig. Enten blir alle databaseoperasjoner kjørt i en transaksjon, ellers så blir ingen operasjoner kjørt (det gjøres ikke halvveis). 1.4 Skuespillere på en scene - De som bruker databasen fra dag til dag 1.4.1 Databaseadministratorer DBA Databaseadministrator Ansvarlig for autorisasjon av tilgang til databasen, koordinering og overvåking av bruk, og anskaffelse av nødvendig programvare og maskinvare. DBA-en står ansvarlig for sikkerhetshull og dårlig responstid. I

Side 4 for Databaser store firmaer er DBA-en assistert av en stab. 1.4.2 Database-designere Database-designere Ansvarlig for - Å identifisere dataen som skal lagres i databasen. - Velge passende strukturer for å lagre og representere denne dataen. Database-designere kommuniserer med alle typer brukere av systemet for å forstå deres krav, og for å lage et design som møter disse. Det ferdige designet må møte kravet til alle brukere. 1.4.3 Sluttbrukere Sluttbrukere Casual end users "Uformelle sluttbrukere" Naive sluttbrukere Eller parametriske sluttbrukere Sofistikerte sluttbrukere De som trenger tilgang til databasen for spørringer, oppdateringer og generering av rapporter. Det er disse databasen primært eksisterer for. Bruker databasen en gang i blant, og trenger forskjellig informasjon hver gang. De bruker typisk et sofistikert databasespørringsgrensesnitt. Som regel mellomledere eller ledere. De utgjør en stor del av databasebrukerne. De oppdaterer og leser databasen ved å bruke standard spørringer og oppdateringer, kalt "canned transactions", som er nøye programmert og testet. Mange av disse oppgavene kan gjøres på mobilapper. Eksempler: Bankkunder og bankkasserere som sjekker saldo, gjør uttak og inntak. Sjekke ledighet av flybilletter, hotellrom, biler og lignende. Ingeniører, forskere, forretningsanalytikere og andre som gjør seg kjent med mulighetene til DBMS for å implementere egne applikasjoner som skal møte deres komplekse krav. Har sine egne personlige databaser, ved å bruke ferdiglagde programpakker som tilbyr enkle menybaserte eller grafikkbaserte grensesnitt. 1.4.4 Systemanalytikere og applikasjonsprogrammerere Systemanalytikere Frittstående sluttbrukere Applikasjonsprogrammerere 1.5 Arbeiderne bak scenen De bak scenen DBMS-systemdesignere og implementerere Setter kravene til sluttbrukerne, spesielt naive og parametriske sluttbrukere, og utvikler spesifikasjoner for standard "canned" transaksjoner som møter disse kravene. Implementerer spesifikasjonene som programmer. De tester, debugger, dokumenterer og opprettholder disse hermetiske transaksjonene. er typisk ikke interessert i selve innholde i databasen. Designer og implementerer DBMS-modulene og grensesnittene som en programvarepakke. Moduler kan være for eksempel katalogen, spørringsspråkprosessering, grensesnittprosessering. De må også sørge for at DBMS-en har grensesnitt mot annet

Side 5 for Databaser Tool developers Verktøy-uviklere Operatorer og systemvedlikeholds personale systemprogramvare som operativsystem og programmeringsspråk. Verktøy-utviklere designer og implementerer verktøy, programvarepakker som forenkler databasemodellering og design, databasesystem-design og forbedret ytelse. Disse verktøyene er ofte kjøpt separat. Disse er ansvarlige for den faktiske kjøringen og vedlikeholdet av maskinvaren og programvaren til databasen. 1.6 Fordeler med å bruke DBMS-fremgangsmåten 1.6.1 Kontroll av redundans Kontroll av redundans (overflødighet) I databaser kan man lagre dataen få steder, slik at det ikke blir redundans. Man slipper dermed at data må oppdateres flere steder, man sparer lagringsplass og man kan unngå at filer blir inkonsistente. Normalisering går ut på at data bare skal lagres én plass. Noen ganger er man likevel interessert i å få enklere spørringer, slik at man bruker kontrollert redundans, og lagrer data flere steder. Denormalisering er når man setter all data sammen. Da er det viktig at dette er kontrollert for å unngå inkonsistens. 1.6.2 Begrense uautorisert tilgang En DBMS burde tilby en sikkerhets- og autorisasjondelsystem, som databaseadministratoren kan bruke til å opprette kontoer og spesifisere kontobegrensninger. Så skal DBMS-en kunne håndheve disse restriksjonene automatisk, slik at ikke alle har tilgang til all data. Dette kan også gjøres med DBMS-programvaren. For eksempel kan det være at bare dataadministrasjonsstabben har tilgang til visse program, som den man bruker til å lage nye kontoer med. 1.6.3 Tilby persistent lagring for programobjekter Objektorienterte databasesystem Siden et objekt forsvinner når man avslutter programmet, må man ofte konvertere dem til et passende format og eksplisitt lagre dem. Tradisjonelle databasesystem Et objektorientert databasesystem er kompatibelt med objektorienterte programmeringsspråk som java og c++, og gjør de nødvendig konverteringene som må til for lagring av objekter. Et objekt som "overlever" avslutningen av et program er persistent. Slet ofte med "impedance mismatch"-problem, siden datastrukturen til DBMS-en ikke var kompatibel med programmeringsspråkstrukturene. 1.6.4 Tilby lagringsstrukturer og søketeknikker for effektiv spørringsprosessering Spørringer og oppdatering Indekser Hurtigbuffer-modul Databasesystemer må tilby muligheter for å effektivt utføre spørringer og oppdateringer, altså må man kunne kjapt søke opp i på harddisken etter ønsket data. Blir ofte brukt til dette. Man lagrer ting i trestruktur eller ved hjelp av hashing, som er utviklet for å passe til søk på disker. En DBMS har ofte en hurtigbuffer-modul som har deler av

Side 6 for Databaser Hvorfor ikke i operativsystemet? Query processing and optimization-modul databasen i hovedminnet. Siden databufring er vesentlig for DBMS-ytelsen, gjør DBMS-er ofte sin egen databufring, i stedet for at dette gjøres i operativsystemet. Ansvarlig for å velge en effektiv spørringsutføringsplan for hver spørring, basert på eksisterende lagringsstrukturer. 1.6.5 Backup og gjenoppretting En DBMS må ha tjenester for gjenoppretting fra maskinvare og programvarefeil. Backup and recovery subsystem-delen av DBMS-en er ansvarlig for dette. Hvis systemet for eksempel skulle krasje midt i en kompleks oppdateringstransaksjon, må systemet gjenopprettes til den tilstanden det var i før krasjen. 1.6.6 Tilby flere brukergrensesnitt Forskjellig kunnskap Siden et databasesystem har mange forskjellige brukere med varierende teknisk kunnskap, må en DBMS tilby flere forskjellige brukergrensesnitt. 1.6.7 Representasjon av komplekse relasjoner mellom data En DBMS må ha muligheten til å representere mange forskjellige komplekse forhold i blant dataene. definere nye forhold når de dukker opp. kunne hente og oppdatere relaterte data enkelt og effektivt. 1.6.8 Håndheve integritetsbegrensninger Backup og gjenoppretting Integritetsbegrensninger Integrity Constraints De fleste databaseapplikasjoner har visse integritetsbegrensninger som må gjelde for dataene. En DBMS skal kunne tilby muligheter for å definere og håndheve disse begrensningene. Noen begrensninger kan bli spesifisert i DBMS-en og automatisk bli håndhevet. Andre begrensninger må typisk bli sjekket når man oppdaterer eller legger inn data. Referanseintegritet Nøkkelintegritet Inherent rules For svære applikasjoner er det vanlig å kalle slike begrensninger for business rules. Når for eksempel alle hunder må ha en eier. Når for eksempel alle hunder må ha et unikt registreringsnummer. Regler som gjelder for visse datamodeller. For eksempel, i ERmodeller må en relasjon være koblet til minst to entitetsklasser. 1.6.9 Tillate inferencing og handlinger, med regler og triggere. Deduktive databasesystem Triggere Lagrede prosedyrer Databasesystem som gir mulighet for å definere deduksjonsregler for å trekke konklusjoner fra ny informasjon i databasen. Triggere kan assosieres med tabeller. En trigger er en slags regel som blir aktivert når tabellen oppdateres, og kan resultere i ytterligere operasjoner gjort på andre tabeller, sending av meldinger osv. Kan også brukes til å håndheve regler i databasen, og er mer

Side 7 for Databaser Aktive databasesystem "involverte", altså ikke nødvendigvis knyttet til én tabell, men blir kalt når visse betingelser er oppfylt. Tilbyr aktive regler som automatisk initierer handlinger ved visse hendelser eller betingelser. Mer lesing Deduktive databasesystem: Kapittel 26.5 Aktive databasesystem: Kapittel 26.1 1.6.10 Ytterligere implikasjoner ved å bruke databasetilnærmingen Potensiale for å bruke standarder Redusert applikasjonsutviklingstid Fleksibilitet Tilgjengelig up-to-date informasjon Økonomisk skalering 1.7 Historie - ikke notert Ved å bruke databaser, får databaseadministratoren muligheten til å definere og håndheve standarder blant databasebrukere i en stor organisasjon. Dette kan gi bedre kommunikasjon og samarbeid mellom avdelinger, prosjekter og brukere i organisasjonen. Med en database tar det mye mindre tid å utvikle en ny applikasjon. Moderne DBMS-er gir mulighet for visse endringer av strukturen til databasen, uten at gammel data eller gamle applikasjoner blir påvirket. En DMBS gjør databasen tilgjengelig for alle brukere - så fort én brukers endringer er gjort på databasen, vil denne være tilgjengelig hos alle andre brukere. En DBMS-tilnærming gir mulighet for komprimering av data og applikasjoner, slik at overlapp mellom aktiviteter og dataprosessering i forskjellige prosjekter og avdelinger blir redusert. Redundans i applikasjoner blir også redusert. 1.8 Når skal man ikke bruke et databasehåndteringssystem? Grunner til unødvendige kostnader Grunner til å utvikle tilpassede databaseapplikasjoner 1.9 Sammendrag - ikke notert Store investeringer i maskinvare, programvare og trening i begynnelsen. Generaliteten en DBMS tilbyr for definering og prosessering av data. Overhead for sikkerhet, samtidighetskontroll, gjenoppretting og integritetsfunksjoner. Enkle, veldefinerte databaseapplikasjoner som ikke er forventet å endres i det hele tatt Strenge, sanntidskrav for visse applikasjoner som ikke blir møtt på grunn av DBMS overhead. Embeddede (innesluttede) systemer med begrenset lagringskapasitet, der en generell DBMS ikke ville passet. Ingen behov for flerbrukertilgang.