Utvikling fra kjernen og ut

Utvikling fra kjernen og ut Informasjonssystem bygd på et databasehåndteringssystem Brukergrensesnitt! inn ut Oppfatning av interesseområdet Flere samtidige brukere gir databasehåndteringssystemet store utfordringer! Applikasjon Virkelighetsmodell Plattform Bruker Oppfatning av interesseområdet Utviklingsretning Databasehåndteringssystem Informasjonssystem jfr. Fra kjernen og ut, fra skallet og inn kapittel 4 Brukere Frakjernen-1 Frakjernen-2 Hva gjør databasehåndteringssystemet? Databaseteknologier Tilbyr grensesnitt for brukere og programmerere Lagrer og henter brukerdata Lagrer og henter metadata Håndhever integritetsregler Optimaliserer spørringer og oppdateringer Håndterer flere brukere samtidig (ikke enbruker-dbms) Utøver tilgangskontroll Sikrer data Det er mulig å håndtere en database uten et databasehåndteringssystem, men særlig praktisk er det ikke... Hierarkiske databaser Nettverksdatabaser Tabelldatabaser/Relasjonsdatabaser Objektorienterte databaser Frakjernen-3 Frakjernen-4

Relasjonsdatabaser I en relasjonsdatabase er data organisert i tabeller. Tabellene må tilfredsstille bestemte krav (mer senere). Flertallet av dagens informasjonssystemer bygd rundt databasehåndteringssystemer er basert på relasjonsdatabaser. Relasjoner og relasjonsdatabaser Relasjon Et matematisk begrep som kan tolkes som en tabell med verdier der alle linjer er forskjellige fra hverandre Relasjonsdatabase En samling relasjoner Relasjonsdatabaseteoriens fødsel: E. F. Codd: A Relational Model for Large Shared Data Banks, Communications of the ACM, Vol 13, Number 6 (June 1970) Frakjernen-5 Frakjernen-6 Figur 4-6. En relasjonsdatabase med to tabeller Fylke fylkenr fylkenavn Østfold 02 Akershus 03 Oslo Husholdningsavfall fylkenr kommunenr kommunenavn avfallsmengde Halden Verdiområde ( domain ) Relasjonsskjema Figur 4-2. Relasjonsdatabaseterminologi 02 03 04 05 06 07 08 09 10 11 12 14 15 16 17 18 19 20 fylkenr Relasjonsnavn Husholdningsavfall kommunenr kommunenavn Attributt avfallsmengde 02 04 0211 Moss Vestby 11549 Tupler/ Linjer/ Forekomster 04 05 Halden Moss Sarpsborg 12600 Frakjernen-7 Frakjernen-8

Krav til relasjoner Relasjonen har et entydig navn innen databasen Attributter har et entydig navn innen relasjonen Attributtenes rekkefølge skal være uten betydning Alle verdier i et attributt er hentet fra samme verdiområde, eller er NULL Et verdiområde kan være endelig eller uendelig Verdiene er atomiske Tuplenes rekkefølge skal være uten betydning I en relasjon kan det ikke finnes to like tupler Figur 4-4. Entydighetsskranke og primærnøkkel Primærnøkkel fylkenr kommunenr 04 05 Moss Entydighetsskranke kommunenavn Halden Sarpsborg innbyggertall avfallsmengde 12600 26417 25860 46692 Mange av disse kravene er en konsekvens av at relasjonsdatabaseteorien definerer en relasjon som en matematisk mengde av likeartede tupler Frakjernen-9 Frakjernen-10 Figur 4-5. Lang entydighetsskranke og sammensatt primærnøkkel y Hvorfor heter det relasjon? Matematisk funksjon: o Til hver x hører bare én y y = f(x) fylkenr kommunenr_ i_fylket kommunenavn innbyggertall avfallsmengde x 04 05 Halden Moss Sarpsborg 12600 26417 25860 46692 y Matematisk relasjon: o Til hver x kan høre flere y og omvendt o To punkter kan ikke ha samme x,y o Kan vises i en tabell med to kolonner x og y x o Kan generaliseres til n dimensjoner Frakjernen-11 Frakjernen-12

Tabeller kontra relasjoner I kommersielle databasehåndteringssystemer brukes tabeller ikke relasjoner: o Tillater like linjer o Attributter er kvasi-atomiske Fremmednøkkel Et attributt eller attributtkombinasjon som deler verdiområde med en primærnøkkel. Fylke fylkenr 02 03 fylkenavn Østfold Akershus Oslo Attributtene behøver ikke å ha samme navn - de må bare få sine verdier fra samme verdiområde Husholdningsavfall Disse to betydningsfulle avvikene er begrunnet i effektivitet og praktiske behov fylkenr kommunenr 04 kommunenavn Halden Moss avfallsmengde 02 0211 Vestby 11549 Frakjernen-13 Frakjernen-14 Intensjon og ekstensjon Databaseskjemaet Relasjonsskjema Husholdningsavfall fylkenr kommunenr kommunenavn Databasens intensjon avfallsmengde Databasens skjema består av skjemaene for alle tabellene som inngår, inkludert skranker og integritetsregler. Databasens skjema er metadata Databasens ekstensjon Metadatabasen oppdateres av databasehåndteringssystemet når DDL-kommandoer utføres Linjer/ Forekomster 04 Halden Moss 05 Sarpsborg 12600 Frakjernen-15 Frakjernen-16

Formaliserte data...er data som er under kontroll av et skjema Fordeler med formaliserte data o Lettere bearbeiding o Mulighet for automatisering o Høyere datakvalitet o Styrende o Bidrar til lik behandling Ulemper med formaliserte data o Restriktivt o Riktig skjema er viktig! Fakta om databaser En database kan inneholde både formaliserte og ikkeformaliserte data En database inneholder en beskrivelse av sine egne data (dvs. metadata) En database inneholder fakta og integritetsregler En database bør i utgangspunktet utformes slik at et faktum lagres bare én gang (ingen redundans) Eventuell redundans skal være kontrollert En database håndteres av et databasehåndteringssystem ( Data Base Management System - DBMS) Frakjernen-17 Frakjernen-18 Figur 4-8 a. Oppretting av relasjonsdatabase med SQL Figur 4-8 b. Oppretting av relasjonsdatabase med grafisk dialog CREATE TABLE Husholdningsavfall ( Fylkenr CHAR(2) NOT NULL, Kommunenr CHAR(2) NOT NULL, Kommunenavn VARCHAR(25) NOT NULL, Avfallsmengde INT NOT NULL, Innbyggertall INT NOT NULL, CONSTRAINT EntydigKommunenr PRIMARY KEY (Kommunenr) ) ; Frakjernen-19 Frakjernen-20

Appliksjonslag og brukergrensesnitt Ad-hoc spørring og oppdatering Brukergrensesnitt Applikasjon OBS! Virkelighetsmodell Informasjonssystemets programmoduler Rutiner fra utviklingsmiljøets bibliotek SQL Databasehåndteringssystem Ad-hoc spørring og oppdatering Operativsystem, datanettprogramvare Ad-hoc spørring og oppdatering SQL-grensesnitt Spørringer og oppdateringer som formuleres på sparket Formuleres enten i SQL. f.eks. i klientprogrammet SQL*Plus eller i et mer brukervennlig grensesnitt, f.eks. bygd på prinsippet Query by Example Maskinvare og datanett Frakjernen-21 Frakjernen-22 Figur 4-9. Eksempel på spørring i SQL Figur 4-9 b. Eksempel på spørring i Query-by-example SELECT Kommune, Avfallsmengde Ønskede attributter FROM Husholdningsavfall hentes fra WHERE Fylkenr = ; med filter Frakjernen-23 Frakjernen-24

Programmer med innebygde spørringer Figur 4-11. Strukturen i brukergrensesnittet gjenspeiler strukturen i databasen Informasjonssystemets programmoduler Kan genereres eller programmeres Fylke Rutiner fra utviklingsmiljøets bibliotek SQL-grensesnitt Forutsetter at programmeringsspråket kan kalle SQLkommandoer Vær oppmerksom på impedance-mismatch - problemer Fylkenr Fylkenavn Husholdningsavfall Kommunenr Kommunenavn Halden 04 Moss Østfold Avfallsmengde 05 Sarpsborg 12600 Frakjernen-25 Frakjernen-26 Distribusjon av systemet Klient P Virkelighetsmodell Brukergrensesnitt Datanett Tjener Applikasjon Plattform Frakjernen-27 Frakjernen-28

Arbeidsdeling klient/tjener Når flere skal samarbeide om å få en jobb gjort, blir det alltid en diskusjon om hvordan arbeidet skal fordeles Om klienten skal være tykk eller tynn, påvirkes av o oppgavens art o maskinenes yteevne o resulterende nett-trafikk o utviklingsverktøyenes egenskaper o vedlikeholdsbetraktninger o sikkerhetsvurderinger Virtuelle tabeller Med virtuelle tabeller kan vi legge mer av applikasjonen i databasen En virtuell tabell er et spørringsresultat som kan brukes på lik linje med vanlige tabeller i etterfølgende SQL-kommandoer Virtuelle tabeller lagres ikke i databasen endrer datagrunnlaget for spørringen seg, endres også den virtuelle tabellen Virtuelle tabeller brukes i hovedsak til: o Mellomregning i kompliserte spørringer o Datagrunnlag for skjermbilder og applikasjonsprogrammer o Adgangskontroll OBS: Begrensede muligheter for oppdatering av virtuelle tabeller Frakjernen-29 Frakjernen-30 Et eksempel: System ReCycle Visjon Funksjonalitet kunnskap Vi skal lage et system som skal fremme gjenbruk av industrielle produkter Som konkret eksempel skal vi ta for oss sykler, som jo er miljøvennlige allerede i utgangspunktet Idéen er å kunne forlenge deres liv, kaste mindre og reparere mer Hvilket spørsmål besvarer vi først? Hva må systemet gjøre? Hva må systemet vite? System ReCycle Frakjernen-31 Frakjernen-32

Mål og mening Hva slags virksomhet informasjonssystemet skal betjene: Gjenvinningsbedrifter, nevenyttige forbrukere Formålet med informasjonssystemet: Skape kontakt mellom gjenvinningsbedrifter og forbrukere mht. produkter. Kjøp og salg av brukte produkter? Interesseområdet: Industrielt framstilte produkter sammensatt av komponenter Hvilke virkninger (effekter) systemet er tenkt å gi: Mer bruk, mindre kast Brukergrupper og hvilke funksjoner systemet skal ivareta for hver brukergruppe: Gjenvinningbedrifter: Registering av gjenbrukbare produkter Produsenter: Registering av stykklister Nevenyttige forbrukere: Finne tilbud på gjenbrukbare produkter Mal for kravspesifikasjon Overordnet systembeskrivelse o Kortfattet beskrivelse av formålet med systemet, og eventuelt av hvordan det samvirker med andre systemer Hva systemet må vite o Oversikt over interessante fenomener i interesseområdet Kvalitetsønsker o Spesifikasjon av godheten på de tjenester systemet skal yte. Eksempler på slike kvalitetsønsker se neste lysark Rammer se senere Frakjernen-33 Frakjernen-34 Mal for kravspesifikasjon Kvalitetsønsker Mal for kravspesifikasjon Rammer Spesifikasjon av godheten på de tjenester systemet skal yte. Typiske eksempler på slike kvalitetsønsker kan være o Gjennomsnittlig svartid kortere enn et bestemt antall sekunder o Lett å lære å bruke: Nødvendig opplæringstid kortere enn et bestemt antall timer o Lett å endre, f. eks. at visse spesifiserte endringer kan legges inn i løpet av en viss tid uten å stoppe driften av systemet Lover og regler Penger Tid Teknologi Regler gitt gjennom lover og forskrifter Krav om en bestemt teknologisk plattform Krav om samvirke med andre systemer Krav om å følge standarder Økonomisk ramme Eventuelle tidsfrister Frakjernen-35 Frakjernen-36

Overordnet systembeskrivelse Kravspesifikasjon Figur 3-8. En trelags-arkitektur for et informasjonssystem o Formål: Skape kontakt mellom gjenvinningsbedrift og forbruker mht. gjenbrukbare produkter. Samvirke: Skal evt. samvirke med produsenters stykklistesystemer Hva systemet må vite o Gjenbrukbare produkter, hvor de finnes, hva de koster, hvordan de er sammensatt Kvalitetsønsker o 90 % av svartid under 1 sekund. Utviklingsverktøy Systemutvikler Brukergrensesnitt Virkelighetsmodell Applikasjon! inn ut Bruker o Lett å utvide til også å omfatte handel med produkter. Rammer Plattform o Maksimal pris 3 mill. Kroner, ferdig til jul, bygges på webteknologi, må ikke være i strid med Lov om personopplysninger og andre relevante lover, bruke produsentenes produktnumre, Frakjernen-37 Frakjernen-38 Produsent prodnr UI Produkt fanavn ReCycle tabelldatabasen prodnr vekt Beholdning fanavn NOT NULL pris UI prodnr sted-org disp-antall Vi skal senere se hvordan vi kommer fram til akkurat disse tabellene! Produsent Produkt fanavn fanavn Monark Beholdning prodnr vekt Syk100 3.5 Syk1 4.7 0.4 fanavn prodnr sted-org disp-antall pris 4999.00 3999.00 400.00 Erstatning fanavn ReCycle tabellforekomster prodnr e-fanavn e-prodnr Syk100 Regnbuen 23 Gir1004 UI Erstatning UI Gjenbruk Regnbuen 124 87 Gir1005 fanavn prodnr e-fanavn e-prodnr Stykkliste Stykkliste UI UI NOT NULL s-fanavn s-prodnr Syk100 d-fanavn d-prodnr modell-antall 1 demont-kost 300.00 s-fanavn s-prodnr d-fanavn d-prodnr modell-antall demont-kost Syk100 Monark Hjul341 1 150.00 Monark Hjul341 Monark Eike209 32 Frakjernen-39 Frakjernen-40

Figur 3-8. En trelags-arkitektur for et informasjonssystem Hvordan databasen er tenkt brukt Kjente produsenter og produkter legges inn Utviklingsverktøy Systemutvikler Brukergrensesnitt Virkelighetsmodell Applikasjon! inn ut Bruker Sammensetningen av produkter (stykklistene) legges inn (Hvor kommer dataene fra?) Ved behov for produkt søkes i Beholdning sammenholdt med Stykkliste (meget komplisert spørring!) Ved deponering og salg registreres endringer i Beholdning. Ved salg av del fra en sammensetning ( kannibalisering ) legges resten av den dekomponerte sammensetningen inn i Beholdning Plattform Ved gjenoppbygging av sammensetninger legges disse inn i Beholdning og delene fjernes Systemet tar forløpig ikke hensyn til produktenes kvalitet Frakjernen-41 Frakjernen-42 Figur 3-8. En trelags-arkitektur for et informasjonssystem Brukergrensesnittet Utviklingsverktøy Systemutvikler Brukergrensesnitt Virkelighetsmodell Applikasjon! inn ut Bruker Ved utvikling fra kjernen og ut inngår ikke detaljerte beskrivelser av brukergrensesnittet i kravspesifikasjonen i alle fall ikke før sent i utviklingen Brukergrensesnittet vil ofte bli av typen data i fokus Hvis vi ikke har antydninger om ønsket funksjonalitet, så må vi i det miste ha brukergrensesnitt for å vise fram og endre tabeller Plattform Vi har allerede sett at også plattformen er lagdelt! Frakjernen-43 Frakjernen-44

Stykklister Brukergrensesnitt - dataorientert Brukergrensesnitt - oppgaveorientert Produktliste med mulige erstatninger Sammensetning Del Modell-antall Demont-kost Produkt finnes hos Pris Syk100 1 300.00 Regnbuen 400.00 Syk100 Monark Hjul341 1 150.00 Gjenbruk 400.00 Monark Hjul341 Monark Eike209 32 Gir1004 Regnbuen 478.00 Oppdater stykklistelinje Slett stykklistelinje Ny stykklistelinje Gi detaljer Frakjernen-45 Frakjernen-46