Utvikling fra kjernen og ut PHP-arkitektur Brukergrensesnitt! inn ut Dynamisk web-side bygges opp på grunnlag av spørring mot databasen Utviklingsretning Applikasjon Virkelighetsmodell Plattform Bruker Oppfatning av interesseområdet Nettleser Netscape, Internet Explorer, Opera... HTTP/ PHP WWWtjener http:// maskinnavn /~brukernavn/ SQL Database Databasetjener (Oracle) Maskinnavn Databasenavn jfr. Fra kjernen og ut, fra skallet og inn kapittel 4 Frakjernen-1 Frakjernen-2 Informasjonssystem bygd på et databasehåndteringssystem Hva gjør databasehåndteringssystemet? Flere samtidige brukere gir databasehåndteringssystemet store utfordringer! Oppfatning av interesseområdet Tilbyr grensesnitt for brukere og programmerere Utfører spørringer og oppdateringer o brukerdata o metadata Optimaliserer spørringer og oppdateringer Brukere Databasehåndteringssystem (DBMS) Informasjonssystem Håndhever integritetsregler 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... Frakjernen-3 Frakjernen-4
Databaseteknologier Hierarkiske databaser Nettverksdatabaser Tabelldatabaser/Relasjonsdatabaser Objektorienterte databaser I dag stort sett kun av historisk interesse Relasjonsdatabaser I en relasjonsdatabase er data organisert i tabeller. Tabellene må oppfylle bestemte krav (mer senere). Flertallet av dagens informasjonssystemer bygd rundt databasehåndteringssystemer er basert på relasjonsdatabaser. Frakjernen-5 Frakjernen-6 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 Figur 4-6. En relasjonsdatabase med to tabeller Fylke fylkenavn Akershus 03 Oslo Relasjonsdatabaseteoriens fødsel: E. F. Codd: A Relational Model for Large Shared Data Banks, Communications of the ACM, Vol 13, Number 6 (June 1970) 04 11 Frakjernen-7 Frakjernen-8
Verdiområde ( domain ) Relasjonsskjema Figur 4-2. Relasjonsdatabaseterminologi 03 04 05 06 07 08 09 10 11 12 14 15 16 17 18 19 20 Relasjonsnavn Attributt 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 (teoretisk) uendelig Verdiene er atomiske Tuplenes rekkefølge skal være uten betydning I en relasjon kan det ikke finnes to like tupler Tupler/ Linjer/ Forekomster 04 05 Sarpsborg 12600 Mange av disse kravene er en konsekvens av at relasjonsdatabaseteorien definerer en relasjon som en matematisk mengde av likeartede tupler Frakjernen-9 Frakjernen-10 y Hvorfor heter det relasjon? Tabeller kontra relasjoner x Matematisk funksjon: o Til hver x hører bare én y y = f(x) Matematisk relasjon: I kommersielle databasehåndteringssystemer brukes tabeller ikke relasjoner: o Like linjer er tillatt o Attributter er kvasi-atomiske y 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 Disse to betydningsfulle avvikene er begrunnet i effektivitet og praktiske behov x o Kan generaliseres til n dimensjoner Frakjernen-11 Frakjernen-12
Figur 4-4. Entydighetsskranke og primærnøkkel Figur 4-5. Lang entydighetsskranke og sammensatt primærnøkkel Primærnøkkel Entydighetsskranke 04 05 Sarpsborg 12600 26417 25860 46692 _ i_fylket 04 05 Sarpsborg innbyggertall 12600 innbyggertall 26417 25860 46692 Frakjernen-13 Frakjernen-14 Fremmednøkkel Et attributt eller attributtkombinasjon som deler verdiområde med en primærnøkkel. Referanseintegritet Skranke som uttrykker at verdiene i fremmednøkkelen også må finnes i primærnøkkelen Fylke 03 fylkenavn Akershus Oslo Attributtene behøver ikke å ha samme navn - de må bare få sine verdier fra samme verdiområde UI Fylke 03 fylkenavn Akershus Oslo Referanseintegriteten er her vist med et delmengde-symbol Pass på at åpningen vender riktig vei! 04 04 11 11 Frakjernen-15 Frakjernen-16
Intensjon og ekstensjon Databaseskjemaet Relasjonsskjema Databasens intensjon Databasens skjema består av skjemaene for alle tabellene som inngår, inkludert skranker/integritetsregler. Databasens skjema er metadata Databasens ekstensjon Metadatabasen oppdateres av databasehåndteringssystemet når DDL-kommandoer utføres Linjer/ Forekomster 04 05 Sarpsborg 12600 Frakjernen-17 Frakjernen-18 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-19 Frakjernen-20
SQL - Structured Query Language ISO SQL-standardene SQL-89 o Originalstandarden o Addendum for Embedded SQL (1994) SQL-92 o ISO/IEC 9075 SQL:1999 o ISO/IEC 9075:1999 SQL Database DBMS (f.eks. Oracle) Det finnes i dag enklere språk for å kommunisere med databaser, men SQL er standardisert... Frakjernen-21 Oppretting av relasjonsdatabase med SQL CREATE TABLE ( Fylkenr CHAR(2) NOT NULL, Kommunenr CHAR(2) NOT NULL, Kommunenavn VARCHAR(25) NOT NULL, Avfallsmengde INT, Innbyggertall INT NOT NULL, CONSTRAINT EntydigKommunenr PRIMARY KEY (Kommunenr) ) ; CREATE TABLE Fylke ( detaljene utelatt ) ; ALTER TABLE Kommune ADD CONSTRAINT _fk FOREIGN KEY() REFERENCES Fylke; Rød tekst: Oppretting av skranker Frakjernen-22 ISO SQL datatyper CHARACTER(antall tegn) tegnstreng (inntil 254 tegn) VARCHARACTER( ) tegnstreng (variabel lengde) INTEGER heltall (opptil 11 siffer) SMALLINT små heltall (DBMS-avhengig) NUMERIC(ant siffer,ant desimaler) desimaltall (opptil 20 siffer) DECIMAL(ant siffer,ant desimaler) desimaltall (DBMS-avhengig) FLOAT(presisjon) flytende tall REAL flytende tall (DBMS-avhengig) DOUBLE PRECISION flytende tall (DBMS-avhengig) DATE dato TIME klokkeslett TIMESTAMP dato og klokkeslett BIT binære siffer Frakjernen-23 Figur 4-8 b. Oppretting av relasjonsdatabase med grafisk dialog Frakjernen-24
Legge inn forekomster eksempel Figur 4-9. Eksempel på spørring i SQL INSERT INTO VALUES('', '', '',,26417,387.174925237536); INSERT INTO VALUES('', '04', '',,25860,403.054911059551); INSERT INTO VALUES('', '05', 'Sarpsborg', 12600,46692,269.853508095605); SELECT Kommune, Avfallsmengde FROM WHERE Fylkenr = ; Ønskede attributter hentes fra med filter Frakjernen-25 Frakjernen-26 Figur 4-9 b. Eksempel på spørring i Query-by-example Spørringer mot flere tabeller ( join ) SELECT Fylke.,fylkenavn,,, FROM, Fylke WHERE.=Fylke.; Legg merke til: FROM-leddet inneholder flere tabeller WHERE-leddet inneholder join-betingelsen Det må være like mange join-betingelser som det er tabeller i FROMleddet utover den første hvis ikke får vi kartesiske produkter For å kunne referere til ulike attributter med samme navn kvalifiserer vi dem med tabellnavnet Resultat på neste lysark! Frakjernen-27 Frakjernen-28
fylkenavn Fylke Eksempel på join Appliksjonslag og brukergrensesnitt UI 03 Akershus Oslo 04 11 SQL-kommandoen på forrige lysark Brukergrensesnitt Applikasjon OBS! Virkelighetsmodell Informasjonssystemets programmoduler Rutiner fra utviklingsmiljøets bibliotek SQL Databasehåndteringssystem Ad-hoc spørring og oppdatering Resultat fylkenavn Operativsystem, datanettprogramvare 04 Maskinvare og datanett Akershus 11 Frakjernen-29 Frakjernen-30 Ad-hoc spørring og oppdatering Programmer med innebygde spørringer 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 Informasjonssystemets programmoduler Rutiner fra utviklingsmiljøets bibliotek SQL-grensesnitt Kan genereres eller programmeres Forutsetter at programmeringsspråket kan kalle SQL-kommandoer Vær oppmerksom på impedance-mismatch - problemer Frakjernen-31 Frakjernen-32
Transaksjon: Database-transaksjoner Et udelelig stykke arbeid mot databasen Skal ideelt sett tilfredsstille ACID -kravene: ACID Atomiticy Consistency preservation (serializability) Durability Isolation Hva du gjør, gjør fullt og helt, og ikke stykkevis og delt! Virtuelle tabeller En virtuell tabell er et spørrings-resultat 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-33 Frakjernen-34 Bruk av virtuell tabell - eksempel Vi oppretter en virtuell tabell: Mer SQL i gruppeundervisningen CREATE VIEW AvfallAkershus AS SELECT Kommunenr,Kommunenavn,Avfallsmengde FROM WHERE Fylkenr = ; Se også Systemutvikling fra kjernen og ut, fra skallet og inn, Appediks A Vi kan nå bruke den virtuelle tabellen: SELECT * FROM AvfallAkershus ; SQL Database DBMS (f.eks. Oracle) Frakjernen-35 Frakjernen-36