Obligatorisk oppgave 3 i Databaseadministrasjon.

Transkript

1 Obligatorisk oppgave 3 i Databaseadministrasjon. Applikasjonsutvikling med databaser Gruppenummer 7 Av Kai Hagali Ole J. Schön Cato Goffeng Høgskolen i Østfold 22. Oktober 2012

2 Innhold 1 Tilkobling til database... 3 Databasetest Triggere og prosedyrer... 7 Nivå Funksjonalitet tekst:... 8 I databasen... 8 Triggere... 8 Prosedyrer... 9 Applikasjonen... 9 Nivå Loggtabellen Trigger before_update_deltaker Nivå Prosedyre HentebrukerenBolle() Prosedyre Terningkast () Trigger after_insert_deltaker Mellomvare Nivå Nivå Oppsett og utvikling med Doctrine Referanser Figurliste

3 1 Tilkobling til database Det ble valgt å lage en enkel database som skulle aksesseres via php script. Valget falt slik siden det er dette språket de fleste i gruppen kjenner best. Databasens utgangspunkt er hentet fra ideen og fenomenet Geocaching. To av gruppens medlemmer er fascinert av dette jfr. Holone sine forelesinger med fugle eksempler. Vi valgte følgende oppsett for en database med 3 tabeller: Databasen oblig3 Tabeller Cache_id, Cachename Deltaker_id, Fornavn, Etternavn Cachefunn_id, Deltaker_id, Cache Database CREATE DATABASE oblig3 CHARACTER SET 'utf8'; USE oblig3 Tabeller CREATE TABLE cache ( Cache_id INT NOT NULL AUTO_INCREMENT, 3

4 Cachename VARCHAR(45) NULL, PRIMARY KEY (Cache_id)); CREATE TABLE deltaker ( Deltaker_id INT NOT NULL AUTO_INCREMENT, Fornavn VARCHAR(45) NULL, Etternavn VARCHAR(45) NULL, PRIMARY KEY (Deltaker_id)); CREATE TABLE cachefunn ( Cachefunn_id INT NOT NULL AUTO_INCREMENT, Cache_id INT NOT NULL, Deltaker_id INT NOT NULL, time TIMESTAMP NOT NULL, PRIMARY KEY (Cachefunn_id, Cache_id, Deltaker_id)); Her skal cachefunn være en mange til mange i forhold til deltaker. Med andre ord en og samme cache kan bli funnet av flere deltakere. Vi valgte også å legge på en timestamp slik at vi får en loggføring av tid på en forekomst. Det ble satt en bruker som skulle aksessere denne databasen. Vi prøvde først med : GRANT USAGE ON *.* to webuser@localhost identified by 'webuser'; Dette ga meget lite hell, vi hadde en bruker ifølge brukertabellen, men den fungerte dårlig. Etter noen minutter i tenkeboksen ble aksesseringsproblemet løst med: GRANT ALL ON oblig3enkel.* to 'webuser'@'localhost' identified by 'webuser'; Med dette var databasen opprettet. For å kunne benytte ønsket programmeringsspråk og få et webgrensesnitt under windows 2008 r2 ble da IIS lagt til som rolle, samt at vi måtte installere php. 4

5 Det å legge til en IIS server løses lett i server administrasjon uten spesielle problemer. Det viste seg dog at det å installere php ble en utfordring. Den første guiden vi fant på nettet ga oss en oppskrift som ble fulgt. Når denne var ferdig fungerte ikke php. Det ble da forsøkt en annen variant via php.iis.net som er en side fra Microsoft. Her lastet vi ned en installer, kjørte denne. Og kjørte en refresh i browseren som via php script skulle kalle phpinfo. Som bildet på neste side viser fungerte dette. Figur 1 phpinfo på fungerende system Det som ikke fungerte var oppskriften på denne websiden : Databasetest 1 Etter å ha laget noen testdata ble det laget et enkelt phpscript som skulle hente ut alt i en tabell og skrive ut en kolonne rad for rad. 5

6 Scriptet: Figur 2 PHP kode for oppkobling til database. Resultatet : Figur 3 Resultat ved testspørring mot MySQL med PHP. Siden dette er innholdet i tabellen i databasen så kan vi konkludere med at det fungerer. 6

7 2 Triggere og prosedyrer Modeller en eksempeldatabase med et tiltenkt applikasjon-/webgrensesnitt. Tenk nøye gjennom og argumenter for hvilken funksjonalitet(forretningslogikk) som bør ligge i hhv. Databasen og i applikasjonen. Vi valgte å benytte vår eksisterende database fra del 1 av denne innleveringen. Men det ble også foretatt noen forandringer slik at databasen nå ser slik ut : Databasen oblig3 Tabeller Cache Cache id, Cachename, Gjemt_dato, Gjemt_av, Koordinater, Status Deltaker Deltaker id, Fornavn, Etternavn, Brukernavn, Mailadresse, GPS Cachefunn Cachefunn id, Cache, Deltaker_id, FTF, terningkast Cachestatus_id, statustype, FTF_id, cache_id, bruker_id, terningkast <p>medlems ID <br /><input type="text" name="medlid" /></p><br /> Nivå 1 Basert på vurderingene rund plassering av funksjonalitet skal dere lage nyttige og muligens unyttige triggere og prosedyrer. Disse skal ikke implementeres men bare beskrives, her kan dere gjerne gå litt "overboard". Vi velger å utvide vår database fra oppgave 1. 7

8 Som en start på oppgaven beskrev vi rent tekstbasert hva vi kunne finne på å hente ut i denne databasen. Dette ble gjort uten hensikt på hvilken del den skulle tilhøre. Funksjonalitet tekst: Før insert cachefunn sjekk at deltaker_id ikke er samme som gjemt_av Hente ut cacher med terningkast x oppdatere deltaker info sende gammel info til forandringslogg med tilhørende informasjon og tid ny cache oppdatere hjelpetabell cache-logg forandre cache info oppdatere cache-logg Cachefunn, sjekke om det er første registrering før noe skjer, hvis så skal all info om registrering i ftf tabell, samt at ftf_id skal lagres Hente ftf pr bruker Hente all ftf Hente cacher gjemt av x Hvis cachestatus skal settes til arkivert- gammel info til cache-log med timestamp Etter insert av ny bruker sende mail til brukerene om den nye Etter ny cache insert sende brukere mail Vi analyserte oss gjennom de forskjellige og definerte følgende oppsett for hvor vi ville legge de. I databasen Triggere Før insert cachefunn sjekk at deltaker_id ikke er samme som gjemt_av oppdatere deltaker info sende gammel info til forandringslogg med tilhørende informasjon og tid ny cache oppdatere hjelpetabell cache-logg 8

9 forandre cache info oppdatere cache-logg Cachefunn, sjekke om det er første registrering før noe skjer, hvis så skal all info om registrering i ftf tabell, samt at ftf_id skal lagres Hvis cachestatus skal settes til arkivert- gammel info til cache-log med timestamp Prosedyrer Hente ut cacher med terningkast x Hente ftf pr bruker Hente all ftf Hente cacher gjemt av x Applikasjonen Etter insert av ny bruker sende mail til brukerene om den nye Etter ny cache insert sende brukere mail De delene som da ble lagt i triggere falt naturlig at en trigger funksjon skulle utføre. Disse delene er noe som skal skje før eller etter en eller annen form for oppdatering av databasen. Prosedyrene er jo de elementer vi kan kalle på for å få et eller flere resultat til skjerm. Dette dreier seg ofte om database oppslag med eller uten inngående variabler. Som oversikten viser er det dekket opp begge scenario typene. Ved nye medlemmer av databasen vil det være naturlig å bruke en sendmail funksjon for å sende mail til eksisterende og nye brukere. Siden det å sende mail naturlig ikke er en del av databasens funksjonsområde slik vi ser det er det naturlig at dette gjøres fra tilknyttet applikasjon. Denne kan da hente ut mailadressene fra databasen via en SQL spørring for så å videre bearbeide dette før mail sendes. En kunne nok her kanskje hatt en trigger som la alle mailadressene i en egen tabell ferdig formatert og som da kunne hentes opp med en prosedyre. 9

10 Hvilke fordeler gir triggere og prosedyrer brukerne av databasen? Se dette både fra DBAs og utviklers synsvinkel. Vil bruken av triggere og prosedyrer by på utfordringer knyttet til drift og annen bruk av databasen? En DBA ønsker gjerne å benytte seg av triggere for både loggføring og aktiv backup av tabeller slik at tiden det tar før en backup er restored tar kortere tid. I en slik sammenheng hvor noe er gått tapt er kostnaden pr time databasen er nede minimum lik antall ansatte ganger timelønn. I tillegg handler det ofte om tapt fortjeneste. Dog er det slik at en DBA med kontroll på hva triggerne gjør en lykkelig DBA. Hvis denne DBA på en eller annen måte mister kontroll eller er borte på et tidspunkt hvor noe skjer med databasen og ingen andre kjenner triggerne i databasen kan uheldige situasjoner oppstå. For eksempel kan en da komme frem til en situasjon hvor triggere trigger triggere. Noe som brått da kan medføre at databasen kneler. Oppsummert er en database med triggere velfungerende i de fleste situasjoner der DBA har kontroll over oppsettet. Ved å samarbeide med utviklere kan DBA lage funksjoner som gir utviklerne det de til enhver tid trenger. Men det å gi fra seg kontrollen over også dette kan gi uheldige konsekvenser da en ikke vet hva som skjer med databasen. For utviklerne er ikke triggere nødvendigvis det viktigste, men tilgang til det å lage prosedyrer kan være en ønskedrøm. Ved å samarbeide med DBA vil integriteten i databasen eksistere over tid. Ved å kreve å lage egne prosedyrer og triggere kan det føre til at integriteten til databasen er borte. En operasjon for å redde en slik database hvor flere personer har vært med på å lage egne triggere og prosedyrer kan i verste fall ta lang tid. En kan dog se at for en utvikler vil det være godt å kunne ha en slik tilgang. Men det vil dessverre medføre at en DBA mister kontroll. Ved å ha en ydmyk tilnærming til DBA kan en utvikler komme lengre med ett samarbeide. Det medfører også at det tar kortere tid for en DBA å feilsøke om spørringer oppfører seg annerledes enn tenkt. 10

11 Nivå 2 Lag en enkel trigger i databasen dere laget i oppgave 1. Husk en kort forklaring til hva triggeren gjør. For enkelthetsskyld ble det valgt å benytte seg av en loggtabell. I denne skal da alle forandringer i Deltaker tabellen inn. Både INSERT og UPDATE. Dette medfører bruk av 2 triggere. Ved INSERT skal trigger kjøres etter at en bruker er lagt til. Dette for å kunne få informasjonen direkte fra databasen. Ingenting av det gamle skal tas vare på så derfor er det ikke viktig at den kjøres før INSERT. Ved UPDATE skal gammel informasjon tas vare på så dette må kopieres over til loggtabellen før selve INSERT kjøres. Loggtabellen id(auto), deltaker_id, Deltaker_fornavn, Deltaker_etternavn, Deltaker_brukernavn, Deltaker_mailadresse, Deltaker_GPS CREATE TABLE `oblig3`.`deltaker_logg` ( `id` INT NOT NULL AUTO_INCREMENT, `aksjon` VARCHAR(45) NULL, `deltaker_id` INT NULL, `Deltaker_fornavn` VARCHAR(45) NULL, `Deltaker_etternavn` VARCHAR(45) NULL, `Deltaker_brukernavn` VARCHAR(45) NULL, `Deltaker_mailadresse` VARCHAR(45) NULL, `Deltaker_GPS` VARCHAR(45) NULL, `Timestamp` TIMESTAMP NULL, PRIMARY KEY (`id`) ) COMMENT = 'Loggtabell for forandringer i deltagertabellen. Alt hit styres av triggere'; 11

12 Vi valgte å implementere en trigger som tok vare på gammel informasjon om en deltaker før det ble kjørt en update spørring. Trigger before_update_deltaker Figur 4 Triggeren before_update_deltaker Før vi la denne triggeren inn i databasen foretok vi en select * på tabellen deltaker. Figur 5 Sjekk av tabellen deltaker før triggeren ble kjørt Dernest utførte vi en select * på deltaker_logg Figur 6 Sjekk av tabellen deltaker_logg Som bildet ovenfor viser er det ikke noen oppføringer i logg tabellen. 12

13 Vi eksekverte da spørringen som skulle lage triggeren i workbench. Denne feilet med en gang. Figur 7 Feilmelding ved forsøk på å legge til trigger. Vi lurte endel på hvorfor dette skjedde. Vi skulle jo være inne med root brukes som hadde alle rettigheter. Vi fant en forklaring på nettet som ikke ga oss et bedre svar. Etter å ha sjekket hvilken bruker som var logget inn kom vi til en enkel forklaring. Det var ikke root brukeren som var der, men webuser fra oppgave1. Etter et raskt bytte av bruker og utføring av innlegging av triggeren i kommandovinduet så resultatet bedre ut. Ingen feilmelding og klar til å resette delimiter. Figur 8 Trigger legges inn med brukeren root. Vi kjørte da en update på den ene deltakeren der vi forandret på brukernavnet. UPDATE deltaker SET Brukernavn = Bolla WHERE Deltaker_id = 1001; 13

14 Figur 9 Oppdatering av tabell for å teste trigger. Denne spørringen ble eksekvert uten problemer. Greit nok er det en warning, men vi brydde oss ikke om denne. Deretter valgte vi naturlig nok en select * fra deltaker_logg for å se om triggeren hadde gjort jobben sin. Som bildet under viser er resultatet slik det skal være. Triggeren hadde fungert og deltaker_logg hadde en oppføring. Figur 10 Det er en ny oppføring i deltaker_logg etter trigger Deretter gjorde vi en bekreftende select * fra deltakere for å se om forandringen var satt slik den skulle. Figur 11 Oppdatering av brukernavn Bolla i deltaker tabellen Vi klarte da å lage en trigger som utførte den jobben den var satt til å utføre. 14

15 Nivå 3 Lag eksempeldatabasen(eller deler av den) i MySQL og implementer noen av triggerne og prosedyrene dere beskrev i nivå 1. Sørg også for å inkludere SQL-statements som viser at triggerne/prosedyrene fungerer som de skal. Prosedyre HentebrukerenBolle() Vi startet med å lage en enkel prosedyre som skulle hente opp et eneste objekt. Nemlig all informasjonen om brukeren med brukernavnet Bolle. For den observante leser er dette den brukeren som vi i sted satte til å hete Bolla. Det ble nødvendig med en ørliten forandring av denne brukeren før prosedyren fungerte DELIMITER CREATE PROCEDURE HentebrukerenBolle() BEGIN SELECT * FROM deltaker WHERE Brukernavn = "Bolle"; END DELIMITER ; Figur 12 Opprette en prosedyre HentebrukerenBolle() Selve prosedyren ble lagt til uten feilmeldinger. Denne ble så kalt opp for å få en respons. 15

16 Figur 13 Kaller på prosedyren HentebrukerenBolle() kalles opp Som bildet ovenfor viser er det hentet opp en deltaker og den deltakeren har brukernavnet Bolle. Prosedyre Terningkast () Deretter valgte vi å lage en prosedyre som tok med et parameter inn. I dette tilfellet valgte vi å søke etter terningkast N. DELIMITER CREATE PROCEDURE Terningkast (IN terning INT) BEGIN SELECT * FROM Cachefunn WHERE terningkast = terning; END DELIMITER ; Figur 14 Oppretter prosedyren Terningkast Denne ble da lagt inn i databasen uten feilmeldinger. Vi kalte så på den for å hente opp der hvor det var terningkast 4. 16

17 Figur 15 Kaller på prosedyren Terningkast for å hente ut alle terningkast som er 4. Og den returnerte det den skulle. Trigger after_insert_deltaker Til slutt la vi inn i databasen en trigger som logger en insert i tabellen deltaker. delimiter CREATE TRIGGER after_insert_deltaker AFTER INSERT ON deltaker FOR EACH ROW BEGIN INSERT INTO deltaker_logg SET action = insert, Deltaker_id=NEW.Deltaker_id, Deltaker_fornavn=NEW.Fornavn, Deltaker_etternavn=NEW.Etternavn, Deltaker_brukernavn=NEW.Brukernavn, Deltaker_mailadresse=NEW.Mailadresse, Deltaker_GPS=NEW.GPS, Timestamp=NOW(); END delimiter ; Etter at dette var lagt inn valgte vi å legge til to brukere på denne måten. 17

18 INSERT INTO deltaker (Fornavn, Etternavn, Brukernavn, Mailadresse, GPS) VALUES ("Johan","Halvorsen","Jallaisen", "Montana"), ("Kaare","Halvorsen","Kaarini", "620C"); Figur 16 Nye rader er lagt inn i tabellen deltaker. Som vi ser er brukerne lagt inn. Vi sjekket deretter loggtabellen. Figur 17 Brukerne som er lagt inn i deltaker tabellen er logget. Vi ser her to nye loggføringer, med action type insert slik triggeren skulle skrive. 18

19 For å kunne holde oversikten over triggere er det viktig med dokumentasjon. Vårt forslag til en slik dokumentasjon ser slik ut: Figur 18 Triggerkart 19

20 3 Mellomvare Nivå 1 Utrykket mellomvare, av engelsk middleware, dukket opp på slutten av 80 tallet der konteksten i ordet beskrev programvare for nettverks oppkoblinger. På midten av 90 tallet var det blitt en utbredt bruk av utrykket i det denne nettverksteknologien hadde modnet og det fantes flere typer av denne tjenesten. Inntil da hadde begrepet generelt vært synonymt med bruk mot relasjonelle databaser. På midten av 90 tallet var det utviklet flere forløpere til dagens mellomvarekonsepter (Bakken, 2003). Definisjonen på mellomvare er alle typer programvare som gjør det mulig for annen programvare, applikasjoner eller enheter å kunne samhandle uansett versjoner. Et eksempel på en type mellomvare kan være programvare som kjøres på en server og har som oppgave å sørge for kommunikasjon mellom applikasjoner ved hjelp av en webserver. Som nevnt er det flere typer av mellomvare konsepter, men det er ingen klare standarder siden hver enkelt mellomvareløsning tilpasses det systemmiljøet der det skal brukes. Noen av de mer kjente er: RPC mellomvare (Remote Procedure Call) er en av de tidlige versjonene av mellomvare. Her utføres synkron kommunikasjon mellom prosedurale (ikke objektorienterte) systemer. Dette vil si at applikasjonen hos klienten kaller på en prosedyre på tjeneren. Siden kallet er synkront er klienten blokkert mens den venter på svar fra tjeneren. 20

21 Objektorientert mellomvare Denne mellomvaren er en videreutvikling av RPC der man i stedet for prosedural håndtering gjør det objekt-orientert. Kall på eksterne metoder er det primære målet med objekt-orientert mellomvare. For eksempel kan et objekt som har behov for å benytte ressurser som er i en gitt komponent bruke denne uten å forholde seg til hvor denne befinner seg fysisk. Dette vil si at ressursene som trengs for å eksekvere ikke behøver å være lokale og kan være på en annen node et helt annet sted i systemet. Meldingsorientert mellomvare (MOM). Sender meldinger mellom komponenter der meldingene legges i kø på en server. Komponentene i systemet kommuniserer asynkront med hverandre ved å skrive til og lese fra disse køene. Mottakerkomponenten behøver ikke være operativ hele tiden siden meldingene lagres i køen og kan hentes på et senere tidspunkt. Figur 19 Et enkelt eksempel på MOM basert system (Oracle, 2012) Database mellomvare Kanskje den mest kjente formen for mellomvare som vi ble kjent med gjennom eksempelet med Doctrine i forelesningen der alle applikasjoner har tilgang til å benytte en eller flere typer databaser samtidig og mellomvaren oversetter til et format som applikasjonen forstår. 21

22 Det finnes flere andre typer mellomvare og noen er kombinasjoner av hverandre i det løsningene blir tilpasset hvert enkelt system eter behov. Figur 20 Et eksempel på mellomvare (Bakken, 2003) Den store fordelen med mellomvare er som tidligere nevnt at man kan ha flere forskjellige applikasjoner og versjoner av disse i samhandling siden mellomvaren oversetter all kommunikasjon mellom disse. Noen andre fordeler ved mellomvare er at: man slipper å ha forretningslogikken i applikasjonene eller databasene man slipper å binde seg til en spesiell leverandør for at systemene skal fungere. 22

23 man slipper å ta hensyn til hva slags database som skal brukes ved utvikling av applikasjoner siden mellomvaren sørger for at det vil fungere mot forskjellige versjoner av databaser. man behøver bare å oppdatere mellomvaren i stedet for mange forskjellige versjoner av applikasjoner og databaser. man løser skaleringsproblemer. man oppnår en bedre sikkerhet ved å ha sentral kontroll over hvem som kan koble seg opp mot databasene eller servere. man kan kjøre brannmurer i mellomvaren for å beskytte databaser og klienter. man kan oppnå raskere spørringer mot databaser ved caching i mellomvaren. Noen utfordringer vi ser for oss med mellomvare kan være økonomirelaterte. Fordi det finnes så mange forskjellige former for mellomvare kan det være vanskelig å velge riktig type og denne prosessen kan fort bli kostbar. Når en løsning er så er valgt må det trolig videreutvikling til for å tilpasse løsningen til bedriftens forretningslogikk. Dette er også en prosess med store kostnader avhengig av kompleksiteten i systemet. 23

24 Nivå 2 Doctrine er et ORM (Objekt Relational Mapper) verktøy. ORM brukes på applikasjonssiden og gir utviklere en proprietær og objekt orientert SQL dialekt, her ved DQL (Doctrine Query Language). Det finnes flere forskjellige ORM verktøy der ute og Hibernate er et eksempel for dataspråket Java. Hibernate har igjen sin egen dialekt kalt HQL, og formålet med begge verktøyene er stort sett det samme. ORM er en teknikk for å oversette datatyper som ikke er kompatible, her mellom et objekt orientert dataspråk (PHP) og en relasjons database. Under objekt orientert programmering oppretter vi objekter ut av klasser (Fig.21) som representerer dataen vi jobber med, disse objektet vil da tilsvare en tuppel i en tabell (Fig.22) og objektets medlemsvariabler tilsvarer kolonnene. Figur 21 Tabell brukerklasse Figur 22 Tabell 24

25 For å lagre informasjonen i et objekt til databasen må utvikleren ta alle medlemsvariablene fra klassen og pakket dem inn i en insert SQL setning som førte dem inn i den tabellen som korresponderer med objektet. For å gjenskape dette objektet må det kjøre en select setning på databasen og fylle medlemsvariablene med resultatsettet fra select setningen. For å slippe å gjøre dette manuelt hver eneste gang du skal lagre eller gjenskape et objekt er det behagelig å delegere denne jobben videre til f.eks. Doctrine. Gjennom Doctrine sin DBAL (DataBase Abstraction Layer) skapes det kontakt opp mot databasen du skal jobbe med. Konfigurasjonen kan skje både via XML eller rett in i PHP koden. Figur 23 Konfigurering av databaseoppkobling Hibernate bruker et sett med importerte.jar filer i for eksempel Eclipse (IDE for JAVA og andre språk) for å sette opp kontakten med databasen. Dette separerer utvikleren fra database siden av systemet. ORM verktøyet vil da kunne ta seg av det å skape en tabell for objektet ditt hvis det ikke eksisterer fra før, samt det å bryte ned objektene dine og legge variablene inn i SQL setninger som igjen kobles opp mot de aktuelle tupplene i tabellen. For å si ifra til ORM verktøyet hva som er modell klassen(e) bruker for eksempel annotasjonen. Denne annotasjonen settes rett over klassedeklarasjonen. For at Doctrine skal vite hvilken medlemsvariabel som tilsvarer primary nøkkelen i tabellen annotasjonen som også plasseres rett over den 25

26 aktuelle medlemsvariabelen. Ved riktig oppsett av drivere og koblinger opp mot databasen, samt korrekt bruk av annotasjon vil ORM verktøyet ta seg av alt som har med databasen å gjøre på egen hånd. ORM verktøyene passer derfor ganske bra inn under definisjonen av mellomvare ettersom de påtar seg input/output ansvaret og sparer utvikleren for dette (forbeholdt litt konfigurering). Eneste ulempen er at flere parter som skal arbeide sammen øker risikoen for feil i systemet, selv om ORM verktøyet tar seg av SQL for utvikleren betyr ikke det at han slipper å lære seg det, tilfeller kan oppstå hvor ORM verktøyet ikke klarer jobben og da må utvikleren ta på seg ansvaret igjen. Oppsett og utvikling med Doctrine Prinsippene i Doctrine er de samme som i Hibernate men språket som brukes er PHP. Det Doctrine gjør er å mappe tabeller i en database opp mot objekter i php. I eksemplet som ble presenter av Harald Holone i forelesningen ble det laget en enkel applikasjon med et sett med script som skulle jobbe mot en database. Det ble ikke benyttet noe rammeverk i eksempelet, men det kan bygges på i ettertid.. Det er kun kommandolinje php som benyttes og på den måten kan vi se isolert på kjernen i det som er denne objektrelasjonelle mappingen. Her skal objektenene i PHP lagres i databasen og at de kan hentes tilbake derfra inn i PHP Teknologiene som benyttes i eksempelet er: PHP - programmeringsspåk MySQL - database Doctrine - som blant annet fungerer som et rammeverk for PHP. 26

27 Composer - som er avhengighetshåndterer. Composers oppgave er å laste ned det vi trenger til prosjektet, blant annet Doctrine. En annen oppgave er å laste ned alle nødvendige oppdateringer som trenges til prosjektet så man slipper å hente til hver enkelt ting som skal oppdateres manuelt. Disse to linjene gjøres tilgjengelige i php.ini: extension=phar.so extension=pdo_mysql.so Deretter installeres Composer som igjen skal laste ned det som trengs for prosjektet. Avhengighetene konfiguereres i Composer der vi legger inn at vi skal ha Doctrine ORM modul og deretter installeres Doctrine automatisk. Det må det opprettes en database i MySQL og en bruker som skal administrere om dette ikke finnes fra før. Katalogen der prosjektet skal ligge opprettes. Doctrine kan ta utgangspunkt i en eksisterende database og lage konfigurasjonsfiler. Dette er mapping filer som mapper mellom objektene i PHP og databasen. I dette eksempelet i forelesningen lages konfigurasjonsfilene først ved at modellen beskrives, så genereres databaseskjema og klassefiler. På den måten ungås feil i klassefiler som kan skje om man koder dem manuelt. Konfigurasjonsfilene som blir generert er XML filer der hver enkelt fil beskriver et skjema for en tabell med alle feltene i tabellen. Det er mulig å bruke andre formater enn XML om man ikke vil det, for eksempel YAML. 27

28 Vi trenger nå to php filer som beskriver oppsettet for hvilken database vi skal jobbe med og en for oppsettet mot EntityManager i Doctrine. Den ene fila ble kalt bootstrap.php og sørger for å inkludere autoload.php som Composer har laget da vi kjørte den første gang. Autoload.php er en fil som sørger for at bootstrap.php har tilgang til funksjonene i rammeverket. I tillegg inneholder bootstrap blant annet XMLpath som peker til der XML mapping filene er lagret og innloggingsinformasjon til databasen, Den andre php fila er cli-config.php som henter informasjonen fra bootstrap.php og kobler dette opp mot Entity Manager i Doctrine. I denne fila legger vi til require for bootstrap og et HelperSet som peker mot Symfony i Doctrine og lager en datastruktur som innholder koblingene til databasen og EntityManager. Når dette er gjort vil verktøyene som skal generere php filene og databaseskjemaene fungere. Basert på XML filene vi har blir nå php filene med klasser generert ved at vi går inn i vendor mappen i Doctrine og kjører $ vendor/bin/doctrine orm:generate-entities entities og deretter blir database skjemaene generert med $ vendor/bin/doctrine orm:schema-tool:create Nå er systemet i prinsippet klart til å tas i bruk siden koblingene for mapping nå er satt opp og databasen kan populeres med data. 28

29 Referanser Ressurssider for del 1 og 2 av oppgaven: PHP the right way (2012) W3Schools.com (2012) PHP MyQL select Databasejournal.com (2102) The Trigger-Happy DBA Middleware.org (2012) What is Middelware, Hentet 19. Oktober 2012 fra Bakken, David E. (2003) Middleware, Hentet 19. oktober 2012 fra Ressurssider Del 3 nivå 2 Doctrine (2012) Composer (2012) Hibernate (2012) Notater fra forelesningene 29

30 Figurliste Figur 1 phpinfo på fungerende system... 5 Figur 2 PHP kode for oppkobling til database Figur 3 Resultat ved testspørring mot MySQL med PHP Figur 4 Triggeren before_update_deltaker Figur 5 Sjekk av tabellen deltaker før triggeren ble kjørt Figur 6 Sjekk av tabellen deltaker_logg Figur 7 Feilmelding ved forsøk på å legge til trigger Figur 8 Trigger legges inn med brukeren root Figur 9 Oppdatering av tabell for å teste trigger Figur 10 Det er en ny oppføring i deltaker_logg etter trigger Figur 11 Oppdatering av brukernavn Bolla i deltaker tabellen Figur 12 Opprette en prosedyre HentebrukerenBolle() Figur 13 Kaller på prosedyren HentebrukerenBolle() kalles opp Figur 14 Oppretter prosedyren Terningkast Figur 15 Kaller på prosedyren Terningkast for å hente ut alle terningkast som er Figur 16 Nye rader er lagt inn i tabellen deltaker Figur 17 Brukerne som er lagt inn i deltaker tabellen er logget Figur 18 Triggerkart Figur 19 Et enkelt eksempel på MOM basert system (Oracle, 2012) Hentet fra Figur 20 Et eksempel på mellomvare (Bakken, 2003) Figur 21 Tabell brukerklasse Figur 22 Tabell Figur 23 Konfigurering av databaseoppkobling