Obligatorisk oppgave 2 i Databaseadministrasjon.

Transkript

1 Obligatorisk oppgave 2 i Databaseadministrasjon. Gruppenummer 7 Av Kai Hagali Ole J. Schön Cato Goffeng Høgskolen i Østfold 8. Oktober

2 Avklaring vedrørende gruppesammensetning. I forbindelse med obligatorisk oppgave 1 og starten på obligatorisk oppgave 2 var det åpenlyst at gruppen hadde problemer med sammensettningen. Generelt er det konsensus i gruppen om at en er gjensidig ansvarlig for å være med på å løse de gitte oppgavene. Dette medfører at vi regner oss som voksne nok til å klare å løse oppgavene uten å måtte innkalle til arbeidsmøter. Dette er det som med enkle ord kalles å ta ansvar for å løse felles oppgaver. Et av gruppemedlemmene var ikke å se under de viktige delene av obligatorisk oppgave 1 og starten av obligatorisk oppgave 2. Ved forespørsel på et tidspunkt fikk vi melding om at personen skulle dukke opp innen kort tid. Dette gjorde han ikke. Vi sendte derfor en mail for å etterlyse initiativ fra personen. Responsen vi fikk tilbake medfører at gruppen nå er redusert til 3. Mailen som ble sendt: Vi har hverken hørt eller sett mye til deg siden starten av prosjekt 1. Vi undres derfor på om du fremdeles tar faget. Det forventes en innsats i gruppesamarbeidet. Innlevering av neste obligatoriske oppgave vil slik det vurderes nå bli levert med de deltakende personene nevnt i oppgaven. Ønsker en redegjørelse fra din side på hva som eventuelt ikke fungerer eller hvilken problematikk som eksisterer. Uavhengig av dette vil vi klargjøre med faglærer hvordan vi skal gå frem i forhold til både gruppesammensetningen og kommende innlevering. Responsen: Det er helt forståelig. Ønsker ikke å surfe på noen så dere og er desverre ikke motivert på noen måte for å fortsette med dette faget så blir til at jeg dropper det. Har nok annet å sette fingra i om dagen. Komunikkasjonen har jo vært relativt dårlig, så her tar jeg kritikk. Jeg beklager dette og ønsker dere alle lykke til videre. Mvh Thor Jarle Kinstad Vi har ingen annen måte å respondere på enn at vi må ta dette til etterretning. Gruppe 7 Databaseadministrasjon

3 Innhold Oppgave A:... 5 B:... 5 C:... 5 D:... 6 E:... 7 F:... 7 G:... 8 H:... 8 I:... 8 J:... 9 K:... 9 L:... 9 M: N: O: P: Q: R: S: T: U: Oppgave Del A: OLE Cato Goffeng KAI

4 Del B: Lasting av data, optimalisering og SQL Del Indeksering Splitte tabeller Optimalisere Database Optimalisere spørringer Minimalisere tabeller Hvordan MySQL åpner og lukker tabeller Del Del Del Del Del Del Del Del C: Datavarehus Del Del Ekstra Del Del Oppgaveløsning i gruppen

5 Oppgave 1 Lag utsagn i relasjonsalgebra: A: Prosjektnr og Prosjektnavn med budsjett < R1: σ< (Prosjekt) R2: πprosjektnr, Prosjektnavn (R1) πprosjektnr, Prosjektnavn (σ< (Prosjekt)) B: Liste over Prosjekter hvor ansattnr 12 er med. Formuler det med en natural join innerst, dvs. slik at den utføres før restriksjon. R1: PrAns Prosjekt R2: σansattnr=12(r1) R3: πprosjektnr, Prosjektnavn (R3) πprosjektnr, Prosjektnavn (σansattnr=12(prans Prosjekt)) Alternativt π Prosjektnr (σ Ansattnr=12(Prosjekt Prans )) C: Som over, men sett en restriksjon innerst, dvs. slik at den utføres før join. πprosjektnr, Prosjektnavn (Prosjekt σansattnr=12 (PrAns)) 5

6 Alternativt π Prosjekt.Prosjektnavn (Prosjekt (σ Prans.Ansattnummer = 12 (Prans))) D: Avdelinger som har minst en ansatt i prosjekt nr. 2012_01. Risiker du å få samme avdelingsnr flere ganger? πavdnr (Ansatt σprosjektnr = 2012_01 (PrAns)) Delsvar: Ja. Når tabellene joines vil prosjektnr 2012_01 bli sjekket opp mot hver enkelt ansatt. Siden hver enkelt ansatt har en unik id vil avdelingen dukke opp flere ganger om det er mer enn en i avdelingen som har deltatt i prosjektet. Dette gjelder ved bruk av både semijoin og natural join. Ved en SQLspørring ville vi unngått dette ved å bruke DISTINCT eller GROUP BY. mysql> SELECT ansatt.avdnr FROM ansatt, prans WHERE prans.ansattnr = ansatt.ansattnr; avdnr << de to fra avdeling 1 er ansatt 100 og mysql> SELECT DISTINCT ansatt.avdnr FROM ansatt, prans WHERE prans.ansattnr = ansatt.ansattnr; avdnr rows in set (0.03 sec) mysql> SELECT ansatt.avdnr FROM ansatt, prans WHERE prans.ansattnr = ansatt.ansattnr GROUP BY avdnr; avdnr rows in set (0.00 sec) 6

7 Alternativ løsning: π Avdnr \ (σ Prosjektnr = 2012_01(Prans Ansatt)) Vi tror svaret her blir nei. Vi vurderte også aggregering, men dette ville kanskje ikke gi oss det vi trengte eksempel på dette ville da gi : π Avdnr ( Avdelingsnr G First (Ansattnr σ Prosjektnr = 2012_01)(Prans Ansatt) Her vil vi da kun få den første ansatt i en avdeling på prosjekt 2012_01, men vi er ikke sikre på om det gir oss mer enn 1 ansatt. E: Prosjektnavn, Etternavn og fornavn på alle i avdeling 31 som har vært med i prosjekt 2012_17. Denne skal vises verst mulig fra et optimaliseringssynspunkt. Hint: produkt. π Prosjektnavn, Etternavn, Fornavn (σprosjektnr=2012_17 (σavdnr=31 (σprans.ansattnr = Ansatt.Ansattnr (σprosjekt.prosjektnr = PrAns.Prosjektnr (Prosjekt χ Ansatt χ PrAns))) kai π Prosjektnavn, Etternavn, Fornavn (σ prosjektnummer = 2012_17 (σavdelingsnummer = 31 ( Prosjekt x Ansatt x Prans ))) F: Som over, men med natural join, ellers verst mulig. π Prosjektnavn, Etternavn, Fornavn (σprosjektnr=2012_17 (σavdnr=31 (Prosjekt Ansatt PrAns))) 7

8 G: Som over, men bra fra et optimaliseringssynspunkt. Pass på at det ikke blir identisk med spørsmålet under. π Prosjektnavn, Etternavn, Fornavn (σprosjektnr=2012_17(prosjekt) (Ansatt) PrAns) σavdnr=31 kai π Prosjektnavn, Etternavn, Fornavn (σ avdelingsnummer = 31 (Ansatt (σ prosjektnummer = (Prans )))) H: Som over, men hvor du prøver å projisere mest mulig (dvs. alt som ikke skal joines) så tidlig som mulig. π Prosjektnavn, Etternavn, Fornavn (Ansatt) (π Prosjektnavn(σProsjektnr=2012_17(Prosjekt)) (Ansatt)) PrAns) (Prosjekt)) I: π Etternavn, Fornavn (σavdnr=31 Gi en vurdering av disse løsningene ut fra optimaliseringssynspunkt. Oppgave E: Her ser vi en alle-mot-alle sammenslåing der hver enkelt rad i den ene tabellen blir parret med hver enkelt rad i den andre. Altså vil i vårt tilfelle antall rader i den ene tabellen multipliseres med radene i den andre og tredje tabellen og alle kolonner i alle tre tabeller vil være representert etter sammenslåing (kartesisk produkt). Tabellen inneholder nå de data vi er interessert i, men også en stor mengde data vi ikke har bruk for før vi setter restriksjoner på hva vi ønsker. Dette blir en dårlig optimert spørring siden alle tabeller slåes sammen før utplukk. Oppgave F: Med natural join vil hver enkel av radene kun matches med rader som har en relatert verdi i den andre tabellen for eksempel samme id i begge tabeller. De kolonner som har de samme verdier slås sammen så vi har ingen duplikate kolonner eller rader etter sammenslåing. I forhold til oppgave E slipper vi duplikater. Sammenslåingen av alle tabeller før utplukk er fremdeles dårlig optimalisering siden vi har mer data å sjekke mot ved utplukk enn det som er nødvendig.. Oppgave G: Her gjør vi en natural join av to tabeller og projiserer den ene restriksjonen først før 8

9 neste natural join utføres. På denne måten får vi en mindre datamengde som skal joines og vi får en spørring som er raskere enn i oppgave E og F. Oppgave H: Her settes restriksjoner som projiseres i hver enkelt tabell før tabellene slås sammen. Datamengden i hver tabell blir redusert til det vi ønsker å hente ut fra alle tabellene samlet. Fra et optimaliseringssyspunkt blir fremgangsmåten i oppgave E og F en tung og dårlig måte å gjøre spørringen på siden vi kun skal ha utvalgte deler av tabellene. Neste eksempel i oppgave G er en langt bedre metode siden det gjøres en restriksjon underveis som gjør neste natural join enklere og raskere. Den mest optimale metoden er den vi ser i oppgave H i det alle restriksjoner er satt før tabellene settes sammen. Vi tror likevel at metoden som gjøres i oppgave H vil være mer oversiktlig og effektiv enn oppgave G ved store spørringer. J: Etternavn og fornavn på alle ansatte i prosjekt nr. 2012_01 som jobber i Avdnr. 1. Du skal ta denne skrittvis, slik at du i hvert skritt bare har med en operasjon. R1: σ Prosjektnr = 2012_01(PrAns) R2: (R1 Ansatt) R3: σ Avdnr=1(R2) R4: π Etternavn, Fornavn (R3) K: Sett deretter sammen dette til et utsagn. π Etternavn, Fornavn (σ Avdnr=1 (σ Prosjektnr = 2012_01(PrAns) Ansatt)) L: Prosjekter som Avdnr 17 har vært med på. Alle attributter i relasjonen Prosjekt skal være med. Ikke bruk av semijoin. π Prosjektnr, Prosjektnavn, Budsjett (Prosjekt σ Avdnr=17(Ansatt PrAns )) 9

10 M: <som over>, men nå formulert med en semijoin. Prosjekt σ Avdnr=17 (Ansatt PrAns) N: Prosjekter (Prosjektnr, Prosjektnavn) som avdnr 17 ikke har vært med på (se også neste oppgave). π prosjektnr, prosjektnavn(prosjekt PRANS (ANSATT / σ ansatt.avdnr = 17 (ANSATT))) O: Som løsning ble det foreslått noe med. Prosjekt... ρavdnr<>17(ansatt). Forklar, gjerne med bruk av et eksempel hvor du tar med noen tupler, hvorfor dette blir feil. Vi kan ikke joine noe på ulikhet slik eksemplet i denne oppgaven indikerer. Vi kan kun joine på likhet. Derfor blir svaret slik vår besvarelse indikerer i oppgaven N P: Det er vanlig å tillate operatoren OR i relasjonsalgebra., f.eks. ρansattnr=5 or ansattnr=7(ansatt). Hvordan kan dette formuleres uten bruk av OR? v = OR Eksempel på ansatt 4 eller ansatt 7 fra Ansatt tabellen σansatt.ansattnr = 4 σansatt.ansattnr = 7 Her vil kun tuppeler med ansattnummer 4 eller 7 være de to mulige i den videre prosess. Q: Hvordan kan full join uttrykkes via outer join. En full join er kombinasjonen av left og right outer joins. Med andre ord vil dette medføre at : A B A B = A B Hvorfor passer ikke eksempelet med Avdeling, PrAns og Ansatt til å illustrere dette? 10

11 Gitt at det ikke er en direkte kobling vil eventuelle tomme celler bli populert med ikke eksisterende innhold. Det nærmeste en kan komme en forklaring er at det er tilnærmet Null i sql. Men det spesifiseres i de forklaringene vi har sett på at en kan sette det til en vilkårlig ubenyttet bokstav som ikke representerer en verdi, men er der som et symbol på et innhold uten match. For eksempel kan denne cellen i en tabellmessig presentasjon settes til å inneholde W. Hvor da en W ikke representerer noen verdi. Det vil i vår sammenheng med prosjekter ikke være naturlig å se på muligheten for tomt innhold i en celle. Dette fordi selv om selve referanse integriteten er opprettholdt har ikke nødvendigvis de data som er i tabellen lenger den nødvendige systemintegriteten. Konstruer et eksempel selv. 1. σ<bet> π* (tabell) R: Personer (med for- og etternavn) som har deltatt i alle prosjekter med budsjett over R1: σ Prosjekt.Budsjett > R2: Prans R1 R3: Ansatt R2 R4: π Fornavn, Etternavn (R3) π Fornavn, Etternavn (Ansatt Prans σ Prosjekt.Budsjett > ) S: Prosjekter som har involvert alle i en avdeling. Prosjektnr, navn og avdnr skal være med. S1: S2: S3: R1: PrAns Ansatt R2: π Ansattnr,Avdnr,Prosjektnr(R1) R1: π Ansattnr,avdnr(ansatt) R2: S1 / R1 π prosjektnr, prosjektnavn, avdnr(s2 Prosjekt PrAns Ansatt) S1: π Ansattnr,Avdnr,Prosjektnr(PrAns Ansatt)) S2: S1 / π Ansattnr,avdnr(ansatt) π prosjektnr, prosjektnavn,avnr (π ansattnr, avdnr,prosjektnr(prans ansattnr, avdnr(ansatt) Prosjekt PrAns Ansatt) Ansatt) / π 11

12 T: <som over>, men formuleres i SQL. SELECT PA.prosjektnr, PA.prosjektnavn, ANSATT.avdnr FROM (SELECT PA.prosjektnr FROM PA.prosjektnr NATURAL JOIN ANSATT.avdeling NATURAL JOIN ANSATT.ansattnr) U: Boka tar opp grupperingsoperatorer i relasjonsalgebra. Finn ut av dette og lag et utsagn som gir antall ProsjektAnsatt-linjer og sum timetall pr. prosjekt. Med grupperingsoperatorer menes det operatorer som utfører noe på en mengde. Jfr. boken og E.F. Codd. Det defineres 7 aggregerings operatorer og extend. Totalt 8 varianter som kan utføres på en mengde. Normalt sett tas de mere åpenbare som union vekk fra en slik definisjon av mengde/grupperingsoperatorer. Vi har da : Sum Antall Gjennomsnitt Maximum Minimum First Last Eksempel på bruk: Vi ønsker å finne totalen på raden kostnad i tabellen posteringer: G Sum(kostnad) (Posteringer) G funksjonen har samme mening som group by i SQL. Attributtene etter G er de som det grupperes etter. Extend er spesiell. Denne benyttes for å foreta beregninger fra to forskjellige poster. For eksempel antall kg fra en post og pris pr. kg. fra en annen post som da kan presenteres som: EXTEND (pris * kg) AS Total_Pris Antall ProsjektAnsatt-linjer. Forståelsen av tabellopsettet er at Prosjektnr og ansatt i sammenheng er nøkklene. Derav vil antall linjer fremkomme av å telle antall linjer i en av disse to kolonnene. Velger å bruke Prosjektnr som den det beregnes på: G Antall(Prosjektnr) (Prosjektansatt) 12

13 Sum timetall pr. prosjekt. Her vil vi måtte gruppere pr. prosjekt. Med forståelsen av oppsettet for grupperingsoperatorer vil da oppsettet bli: ProsjektnummerG Sum(Timeantall) (Prosjektansatt) Her vil vi få ut timeantall pr. prosjektnummer ved en forandring på dette vil vi kunne få ut Prosjektnavn. Vi mener at dette da vil kunne se slik ut. πprosjektnavn ( Prosjektnummer G Sum(Timeantall) (Prosjektansatt)) Etter å ha diskutert med andre grupper vedrørende besvarelsene for å finne ut om vi var på rett vei. Er vi ikke lenger sikker på om det ovenstående er rett. Vi tror at det må til en ny gruppering. Dette medfører da dette oppsettet: ProsjektnummerG Sum(Timeantall) G Antall(Prosjektnr) (Prosjektansatt) Dette bør kunne gi ønsket gruppering av begge elementer i svaret. Oppgave 2. Del A: Hvert medlem i gruppa skal lage sitt eget eksempel med minst 3 relasjoner. Lag deretter 5 oppgaver, og løs dem med relasjonsalgebra. Følgende skal være representert: 1. Restriksjon, natural join og projeksjon, med bruk av alle tre relasjonene. 2. En spørring i to varianter, en som er effektiv, en som ikke er det. 3. Snitt og/eller union 4. Minus/mengdedifferanse 5. Divisjon Regn med å kunne forklare disse for foreleser. Angi navn på gruppemedlem for hvert eksempel. 13

14 OLE MEDLEM medlemsnr etternavn fornavn adresse postnr TUR ruteid rute maaned aar MEDLEMSTUR medlemsnr ruteid km 1. Restriksjon, natural join og projeksjon, med bruk av alle tre relasjonene. Medlemsnr, Etternavn, Fornavn som har gått mer enn 2000 km i 2012 π medlemsnr, etternavn, fornavn (MEDLEM (σ aar= 2012(TUR) (σ km < 2000(MEDLEMSTUR))) 2. En spørring i to varianter, en som er effektiv, en som ikke er det. Medlemsnr og rute for de som har etternavn Nilsen og har gått ruteid 15 Ueffektiv: πmedlemsnr,rute(σetternavn=nilsen(σruteid=15(σtur.ruteid=medlemstur,ruteid(σmedlem.m edlemsnr=medlemstur,medlemsnr (MEDLEM χ TUR χ MEDLEMSTUR))))) Effektiv: πmedlemsnr,rute (σetternavn=nilsen(medlem) (TUR (σruteid=15(medlemstur)))) 3. Snitt og/eller union Alle ruteid er som medlemmene enten benytter eller har benyttet πruteid (TUR) πruteid (MEDLEMSTUR) Union definerer alle tupler i enten den en eller andre tabellen, eller begge. Duplikate tupler blir fjernet. Tabellene må være Union kompatible (her ved ruteid). 14

15 Alle ruteid er som er tilgjengelig og minst en som medlemmene enten benytter eller har benyttet πruteid (TUR) πruteid (MEDLEMSTUR) Snitt definerer en relasjon som består av alle tupler som er i begge tabeller. Tabellene må være Union kompatible (her ved ruteid). 4. Minus/mengdedifferanse Alle ruter som ikke har vært benyttet πruteid(tur) - πruteid(medlemstur) Minus definerer en relasjon der tuplene i den ene tabellen ikke finnes i den andre tabellen. Tabellene må være Union kompatible (her ved ruteid). 5. Divisjon List ut alle medlemmer som ikke har gått ruteid 12 (π medlemsnr (MEDLEM) \ π medlemsnr (σruteid=12(medlemstur))) MEDLEM 15

16 Cato Goffeng KUNDE kundeid fnavn enavn 1 cato goffeng 2 arne bjarne 3 kai hagli 4 ole schon 5 kurt nilsen VISAKONTO kontonr saldo

17 GOLDKONTO kontonr saldo KUNDEKONTO kontonr kundeid Oppg1: Effektiv måte List ut alle i relasjonen KUNDE som har en visakonto med saldo over all info fra relasjonen KUNDE skal være med. R1: σsaldo > 1000(visakonto) R2: kundekonto R1 R3: kunde R2 R4: πkundeid, fnavn,enavn(r3) πkundeid, fnavn,enavn( kunde ( kundekonto ( σsaldo > 1000(visakonto)))) 17

18 Oppg2: Mindre effektiv måte Løs oppgave 1 mindre effektivt. R1: kunde X kundekonto X visakonto R2: πkundeid, fnavn,enavn(r1) R3: σsaldo >1000 (R2) σsaldo >1000 (πkundeid, fnavn,enavn(kunde X kundekonto X konto)) Oppg3: Snitt eller union List opp fult navn på alle kunder med en konto enten i visakonto eller goldkonto med saldo over 550 R1: visakonto U goldkonto R2: σsaldo > 550 (R1) R3: kundekonto R2 R4: kunde R3 R5: π fnavn,enavn (R4) π fnavn,enavn (kunde (kundekonto (σsaldo > 550 (visakonto U goldkonto)))) Oppg4: Minus List opp kundeid på alle med visakonto uten å bruke visakonto relasjonen R1: kundekonto - goldkonto R2: π kundeid (R1) π kundeid (kundekonto - goldkonto) 18

19 Oppg5: Divisjon List opp alle kontonummerene til kunden med kundeid 1 R1: σkundeid=1(kunde) R2: kundekonto / R1 R3: πkontonr(r2) πkontonr(kundekonto / (σkundeid=1(kunde))) 19

20 KAI Oppsett av relasjonstabellene: 1. Restriksjon, natural join og projeksjon, med bruk av alle tre relasjonene. 2. En spørring i to varianter, en som er effektiv, en som ikke er det. Skriv ut organisasjonsnr og medlemsnr til medlemmene i organisasjon Snitt og/eller union 4. Minus/mengdedifferanse 20

21 5. Divisjon 21

22 Del B: Lasting av data, optimalisering og SQL. Del 1 1. Lag en oversikt over ulike måter å optimalisere en databasestruktur på, ca. 1-2 sider, punktvis, med kommentarer og referanser på hvert punkt bør være med. Optimalisering som grunnprinsipp handler om mer enn bare databasestrukturen. Vi ønsker å poengtere at dette er et av de punktene en må se på i forbindelse med at en database skal ha best mulig ytelse. De andre punktene som er viktig for ytelse er hardware, grunnoppsett av databasen (Planlegge for best ytelse), benchmarking (Teste databasens ytelse) og monitorering. Den siste er kanskje den viktigste. For uten å se hva som egentlig skjer med databasen vil det være vanskelig å optimalisere på best mulig måte. For database struktur har vi gjennomgått forskjellige bøker samt besøkt en rekke nettsteder for å se om det finnes en rød tråd i dette arbeidet. Vi ser følgende trekk fra de fleste stedene : 1. Indeksering Indeksering hjelper Mysql med å finne de relevante data tilhørende en spørring raskere enn om den må gå gjennom hele tabellen hver gang den skal hente ut informasjon. Manualen til Mysql beskriver at i en tabell med 1000 rader vil tabellen indeksert kunne aksesseres over 100 ganger raskere enn om hver rad skal leses sekvensielt. Men det kommer ann på hva slags spørring som skal utføres siden Mysql oppfører seg forskjellig i forhold til dette. Det vil da være essensielt å vite hva som skjer i spørringene da feil metodikk for indeksering kan medføre at spørringene går tregere enn det de ville gjort uten indeksering. For Mysql er indeksering benyttet i where statement, sorteringer, eliminering (Mysql velger default det som gir lavest antall rader hvis det er mulig å velge mellom indekser), Join statement her bør indeksene være av samme datatype og størrelse for å få best mulig ytelse, Ved Maks/Min beregninger vil Mysql se om det finnes en konstant verdi av denne representasjonen/spørringen hvis ikke vil Mysql første gang gjøre beregningen og lagre en konstant for dette slik at påfølgende spørring om det samme går kjappere (En optimaliserings effekt som er innebygd), det er også en funksjon i Mysql som via algoritmer som er innebygd kan aksessere deler av en rad for å raskere finne de nødvendige verdier. 22

23 B-tree Er den indekseringen som passer for sammenligninger og like statement. Dog kun i de like statement der det startes med en konstant. Hvis et like statement starter med wildcard benyttes ikke B-tree indeksering. Så om en har satt opp en slik indeksering og det da spørres feil vil ikke indekseringen ha noen betydning. Hash Indeksering Brukes der en finner sammenligninger som bruker = og. Denne indekserinsmetoden vil ikke kunne få en order by til å gå raskere. Sammenlignet med et B-tree søk vil søk med hash indeksering kun gå på hele nøkkler og ikke kun deler av en nøkkel. Indeksering generelt går da på kolonner slik at databasesystemet på raskest mulig måte kan finne frem til de relevante data. Som vi har vært inne på er det forskjeller i indekseringsmetodene med tanke på den hastighetsytelsen en får. Noen indekseringsmetoder passer best for noen spørringer, mens andre passer for andre. Avarter av indeksering Spatial Indeksering - Benyttes for databaser der en har med geometriske punkter i et rom. Denne avarten krever at selve databasen er satt opp som en spatial database. En av de mest kjente databasene som benytter en slik teknikk er google maps. Her benyttes det såkalte quad tree. Dvs at hver grafiske visning av et utsnitt kan deles inn i 4 uansett hvor i representasjonen en er i. En slik deling medfører at det er ikke hovedpunktet som det indekseres etter, men hvilken 4. del som velges. Fulltext Index Dette er passende for databasesystem som inneholder tekster. I generelle vendinger kan dette være database over tekster fra bøker eller aviser. Mysql vil ved kun 2 rader ikke finne noen treff som en kuriositet. Mysql definerer nemlig halvparten av radene som uaktuelle basert på indeksen. Derav må det være 3 eller flere rader for å få treff. En kan heller ikke søke på wildcard muligheter med en slik indeksering. Referanse Indeksering: Mysql High performance MySQL - Schwartz, Zaitsev og Tkackenko - O Reilly Mysql Administrators Bible - Cabral, Murphy - O Reilly 23

24 2. Splitte tabeller En enkel tommelfinger regel er at jo mindre datamengde en skal gå igjennom jo raskere vil et søk kunne gå. Derfor vil det være viktig å splitte tabellene opp slik at det å hente informasjon går så raskt som mulig. Metodikken for en slik oppsplitting defineres ut fra Codd`s begrep om normal former. Sålenge databasens tabeller oppfyller den 3. formen vil tabellene være av en slik orden at de er såkalt normaliserte. Dette hjelper drastisk på i hvordan en database fungerer i praksis. Effekten av høyere form er ikke gitt bedret i forhold til den 3. som i vanlig database metodikk anses som normalisert form. High performance MySQL - Schwartz, Zaitsev og Tkackenko - O Reilly Mysql Administrators Bible - Cabral, Murphy - O Reilly 3. Optimalisere Database OPTIMIZE TABLE Etterhvert som tabellene blir oppdatert via slettinger vil de kunne bli fragmenterte. Ved å bruke optimiseringsfunksjonen i MySQL vil en raskt kunne øke effektiviteten til de tabellene som er mest brukt. Indeksering Som vi har vært inne på er det viktig med indeksering. Disse vil også kunne optimaliseres på et vis. Det viktige er hvorvidt tabellen er en tabell som det skal lese fra (Select) eller skrives til (Insert/delete/update). Hvis indeksering er på i en tabell som skal skrives til ofte og hovedsaklig det vil det beste være å ikke indeksere. Dette fordi hver gang det er en oppdatering vil indekseringsrutinen resortere alle data. Med mange slike vil dette medføre at systemet har en tregere respons. Skal en hovedsaklig lese fra en tabell er indeksering vesentlig for å kunne finne frem. Det viktige her er da oppdatering når og hvordan. High performance MySQL - Schwartz, Zaitsev og Tkackenko - O Reilly Mysql Administrators Bible - Cabral, Murphy - O Reilly 24

25 4. Optimalisere spørringer Like viktig som å lage indekser er det å lage de spørringene en trenger slik at de bruker minst mulig ressurser. Det er en stor fordel å unngå kartesiske produkt av tabeller. Ved å sette hovedbegrensningene så tidlig så mulig vil det være mindre data å prossesere for et resultat. Hvis vi har 3 tabeller på rader hver og joiner disse sammen får vi etterhvert en tabell med rader. Hvis resultatet vi forventer er på ca 1000 rader vil det være mye som må tas vekk i påfølgende operasjoner i spørringen. Hadde hver enkelt tabell vært begrenset til 100 rader hver hadde vi kommet unna med rader. High performance MySQL - Schwartz, Zaitsev og Tkackenko - O Reilly Mysql Administrators Bible - Cabral, Murphy - O Reilly 5. Minimalisere tabeller Riktig datatype. Ved å bruke den rette datatypen til en rad vil kunne gi store effekter. Ved å velge MEDIUMINT fremfor INT kan en spare inn 25% av plassen siden MEDIUMINT har litt over +- 8 millioner muligheter vil det holde lenge for de fleste anvendelser. Det samme ved å velge for eksempel antall tegn i en navne del til for eksempel maks 20 tegn kontra 40 tegn eller benytte alle 255 som ligger i en udefinert VAR. High performance MySQL - Schwartz, Zaitsev og Tkackenko - O Reilly Mysql Administrators Bible - Cabral, Murphy - O Reilly 6. Hvordan MySQL åpner og lukker tabeller. Siden MySQL er et multitasking system kan vi definere hvordan tabellene skal aksesseres og lukkes i forhold til tilkoblinger. Det er dog avgjørende hvordan operativsystemet som ligger i bunn kan håndtere tilkoblinger (Concurrency`s). Hvis det er for eksempel 200 tilkoblinger som bruker de samme 6 tabellene hver bør systemet settes til å holde 200*6 tabeller åpne til enhver tid. Dette for å gi en raskere adgang til tabellene. High performance MySQL - Schwartz, Zaitsev og Tkackenko - O Reilly Mysql Administrators Bible - Cabral, Murphy - O Reilly 25

26 Del 2 2. Last inn mye data i et eller flere databasesystemer. Splitt i flere tabeller som kan kobles hvis det ikke allerede er flere tabeller i systemet. Evt. kan du til en viss grad bruke self-join for å få til koblinger. For oppgavene benyttet vi den database som ble foreslått av foreleser. Siden den totale datamengde og tabell rader var store ble det vurdert slik at tabellene var i utgangspunkt klare til å kjøre spørringer på uten modifikasjoner. Del 3 3. Prøv ut ulike tunge spørringer, uten og med indeksering noter forskjellen (hvis noen). Vi satte igang denne spørringen på artsfunn databasen SELECT * FROM artsfunn NATURAL JOIN stasjonsaar; Det første forsøket gikk feil siden mysql returnerte kun 1000 rader, etter å ha fjernet denne limiten gikk det bedre (Relativt sett). Tidsforbruket her er da 1847/60= 30,73 minutter. 26

27 Denne testen ble gjort med og uten optimizer switchene. Resultatet med og uten disse var det samme. For sammenligning ble det da satt på indekser på begge tabellene, og samme spørring ble kjørt: Etter å ha kjørt denne en stund kom vi på at det kanskje ikke var unike indekser her. Denne ble da litt moderert. Etter en tid ble det et resultat: Spørringen tok da 2458 sekunder. Justert til minutter tilsvarer dette 40 minutter. Med andre ord omtrent 10 minutter lenger enn spørringen uten indekser. 27

28 Del 4 4. Prøv å få til en spørring hvor du får hastighetsforskjell avhengig av om du bruker distinct eller ikke. For sikkerhets skyld var eventuelle cache satt til null : Vi valgte en enkel distinct setning for å få et raskt som mulig svar. 1. SELECT familienavn, slektsnavn FROM slekt; 2. SELECT DISTINCT familienavn, slektsnavn FROM slekt; Vi ser en ørliten hastighetsforskjell. Hvor distinct er noe tregere. Tidsforskjellen her var mindre. Vi valgte derfor å utvide dette med order by for å se om dette fikk større innflytelse på søket. 1. SELECT slektsnavn, familienavn, gruppenavn, gruppekode FROM slekt, gruppe ORDER BY familienavn; 2. SELECT DISTINCT slektsnavn, familienavn, gruppenavn, gruppekode FROM slekt, gruppe ORDER BY familienavn; På den maskinen spørringene ble gjennomført på er det ikke stor forskjell på disse spørringene. Vi ser at distinct medfører litt mer tidsforbruk. 28

29 Det er mulig at dette resultatet ville vært noe klarere vedrørende forskjeller på en annen maskin. Del 5 5. Prøv å formulere tunge spørringer på ulike måter (f.eks. ulike måter å koble data på, som vanlig join,.in., exists.) og se hva systemet/ene foreslår. Hint: Både mysql, MS SQL Server og en del andre systemer viser hvordan en SQL-setning gjennomføres. Vi valgte en presumtivt tung spørring med distinct, join og exist. Denne ble da eksekvert i workbench med explain extended. Som vi ser av bildet legger MySQL opp til en stor bruk av temporere tabeller. Dette medfører en stor bruk av minne. Som vi ser av neste deloppgave fikk dette konsekvenser. Del 6 6. Sjekk hastighetsforskjeller og prøv å forklare disse forskjellene, hvis noen. SELECT DISTINCT familienavn FROM `mod_veritas`.`artsfunn` NATURAL JOIN `mod_veritas`.`familie` WHERE EXISTS (SELECT * FROM `mod_veritas`.`stasjon` WHERE Stasjonsnavn='A1-01'); Kontra SELECT familienavn FROM `mod_veritas`.`artsfunn` NATURAL JOIN `mod_veritas`.`familie` WHERE EXISTS (SELECT * FROM `mod_veritas`.`stasjon` WHERE Stasjonsnavn='A1-01'); 29

30 Begge spørringene feilet Forskjellen var at den med distinct brukte 600 sekunder før feilen oppsto, mens den andre uten feilet med en eneste gang. Oppsettet på maskinen er 12 GB ram, noe som burde ha holdt litt lenge Del 7 7. Prøv å se om dere klarer å få til hastighetsforskjeller mellom ulike databasesystemer, generelt og i forbindelse med spesielle spørringer. Uttrykket NATURAL JOIN eksisterer ikke i MS SQL og spørringen blir også litt annerledes. Det nærmeste vi kommer er JOIN men tabellene kan ikke kobles sammen uten at de er relatert til hverandre, I dette tilfellet har vi kolonnene Aarstall begge. Spørringen vil da se slik ut: SELECT * FROM artsfunn JOIN stasjonsaar ON artsfunn.aarstall = stasjonsaar.aarstall Mens vi venter på at Sqlserver skal tygge seg gjennom de to tabellene vi setter sammen, reflekterer vi over at mens vår MySql dump var på 78 mb ble backupen vi gjorde på Ms Sql 344 mb på de sammen dataene. 30

31 Bildet over viser spørringen vi startet i T-SQL som stoppet etter 1 time og 31 minutter og den var da oppe i rader. I tillegg fikk vi en feilmelding som forteller oss at det er lite plass på disken. Det blir desverre ikke riktig å sammenligne spørringen mot MySql siden denne spørringen ikke var lignende NATURAL JOIN (vi har duplikate kolonner) og at lite diskplass ser ut til å ha påvirket resultatet. Feilmeldingen vi fikk i T-SQL Vi tror heller ikke at målingene vi gjør blir noen eksakt vitenskap siden vi arbeider på en virtuell server der flere servere kjører tunge spørringer samtidig. 31

32 For å gjøre spørringen mer effektiv trenger vi en index og må finne den som fungerer best for formålet. Indekseringsmetodene vi forholder oss til i SQL server 2008 er blant annet cluster og non clustered indexes, XML indekser, spatial indekser, filtered indexes og full-text indekser. Hva disse brukes til avhenger av type data vi skal indeksere. Clustered: Det unike med clustered indeks er at man kun kan ha en unik index pr tabell og det er fordi; Om man oppretter en index basert på en nøkkel som for eksempel etternavn, fødselsnummer eller kanskje et telefonnr så vill indexen sortere om på rekkefølgen på all informasjon i tabellen på grunnlag av den verdien. Det siste elementet i cluster strukturen vil være den som inneholder all informasjon om strukturen. Non clustered : Benytter seg av B-Tree der noder peker til andre noder som igjen peker til andre noder. I non cluster er ikke dataene en del av strukturen, men lever på en måte sitt eget liv. I motsetning til clustered som kun kan ha en idnex pr tabell kan non clustered ha opp til 249 per tabell. Det benyttes pekere (pointers) for å linke til data. Som vi sa ble clustered indekser s sortert på nytt på grunnlag av en verdi. I non clustered blir indexen sortret på grunnlag av andre indexer i samme tabellen. Man kan få ptoblemer med ytelsen i et slikt oppsett om man ikke passer på strukturen i disse. 32

33 Filtered : Fungerer på samme måte som et view der vi for eksempel sørger for å filtrere data fra det siste året istedet for å måtte hente fra de ti siste årene. Spatial: Rettet mot lagring av grafisk type informasjon i databasen XML : Dataene lagres i en XML struktur på serveren 33

34 Eksempel på XML indeks Full-text: Denne gir seg vel litt selv i det vi har muligheten til å indeksere store teksmengder som for eksempel innhold i en bok der vi for kanskje ønsker å finne ut hvor mange ganger et ord er brukt. Å lage index i ms sql kan gjøres både som drag and drop eller i commandline med t-sql. Under et eksempel på hvordan vi starter å bygge index i object explorer. Figur: Grensesnittet når det lages indexer i SQL Server Management Studo 34

35 Figur: Feilmeldingen som kom ved forsøk på å lage indexer. Vi er i ferd med å gå tom for både tid og diskplass. Med to Mysql server og to SQL servere slet vi med å få til indeksering. Vi har forsøkt oss på replikkering mellom to sql servere og disse er litt store for plassen vi er tildelt. Vi vil prøve dette igjen ved å avinstallere den ene sql serveren, men det vil desverre bli etter at oppgaven er levert inn på grunn av tidsnød. Figur: Det er fullt på disken 35

36 Del 8 8. Det er vanlig å snakke om regelbasert vs. kostbasert optimalisering. Hva ligger i dette? Dette handler om hvordan databasesystemet planlegger utføringen av spørringene. Kostnadsbasert Her vil en vurdere faktorer som cpu, cachestørrelse, lengden av spørringen. Regelbasert Predefinerte heuristikker avgjør hvordan spørringen skal gjennomføres. I realiteten er det ikke bare en av disse som brukes, men en kombinasjon av de. Ekstra for de som synes det er moro (ikke del av oppgaven). 1. Eksperimenter videre med andre eksempler på forskjeller med og uten optimalisering, evt. ulike måter å formulere en spørring på. Forklar forskjellene du observerer. 2. Finn informasjon om systemer (f.eks. fra industrien eller web - med Google som et opplagt eksempel) som har massive mengder med data og beskriv hvorledes de klarer å få bra responstid. Evt. også sammenlign flere slike bruker de de samme teknikkene? Google - Benytter seg av teknikker som optimaliserer data på best mulig måte. Mens vi her i denne oppgaven fokuserer på selve spørringen jobber Google med et litt større perspektiv. For å ta tall først. I 2006 hentet søkerobotene (Automatisk tjeneste for å indeksere websider) ca 850 TB med data. Dette ble komprimert ned til 88 TB. Søk i google er delt opp slik at en snakker om chunkservere som benytter teknikker for redundans : 36

37 En chunk er på 64 MB. Dette settes opp med dedikert filsystem utviklet av Google. I en serverpark der clustere av billigere hardware er den rådende teknologi. En spørring vil gå til flere slike hovedclustere, men respons kommer kun fra det som er mest ledig der og da. I tillegg har Google i stor grad benyttet språket Zaswall for en ekstra ytelsesøkning. Slik at ja Google optimaliserer i allerhøyeste grad, men de er nødt til å benytte optimalisering på et høyere nivå for å kunne ha en responstid som tilfredsstiller kundene. Dette innebærer som nevnt blant annet mye redundante data, clusterparker, trafikk kontroll, egen filstruktur med mer

38 Del C: Datavarehus. Arbeidet/eksperimenteringen dere gjør under skal dokumenteres detaljert, og/eller med detaljert referanse der det er relevant. Del 1 1. Datavarehus er en av "nyere trender" innen databaser. Finn fram til firmaer som arbeider med datavarehus, beskriv og sammenlign hva de bruker datavarehus til. Vi så på flere firmaer som tilbyr slike tjenester til sluttkunder. Dette var Sherpa Consulting, Norske Systemarkitekter AS, Affecto og Bwise. Med unntak av Sherpa Consulting forklares dette med at datavarehus hjelper sluttkundene med å produsere rapporter. Sherpa Consulting påpeker at det handler om mer enn bare en lagerplass. Vi kan ikke se at noen av disse firmaene forklarer på en tilfredsstillende måte hva et datavarehus kan innebære for brukerene av det. Det blir mer et lagersted for historiske data som ikke har annet bruksområde enn å kunne søkes i ved passende anledninger. Det er ingen informasjon heller om at dette handler om en prosess som ikke avsluttes ved levering av systemet. Forrige semester var en av gruppens deltakere tilstede på en gjesteforelesing i faget It i virksomheter. Der gikk Anne Marit Diedrichsen konsulent i Platon gjennom det arbeidet de gjorde for Choice Hotels Norge. Her danner selve datavarehuset fundamentet for besluttningsplattformen de øverste lederene skal benytte. Her vil en rekke trafikklys komme opp hver morgen ved pålogging. Er det ønskelig kan de gå direkte på de delene som ikke fungerer for å kunne nøste opp i data. Dette er en såkalt drill down metode der datagrunnlaget hentes frem for visning ved behov. Fremtidig utvikling av dette systemet skal blant annet inneholde funskjoner som tar vare på den enkelte stamkunde på en best mulig måte. Og hvor kundens preferranser blir lagret slik at de skal kunne øke servicenivået. Her er det en grunnleggende filosofi som ligger i bunnen av selve datavarehuset og BI løsninger. En slik sammenheng er det vanskelig å spore blant de firmaene vi var inne på. Ei heller ser vi at det for kundene forklares at datagrunnlaget kan benyttes for å kunne se bedre eventuelle trender og avvik i eksisterende datagrunnlag. En forklaring av den nødvendige ELT prosessen er ikke å se i noen av disse firmaene sine presentasjoner. 38

39 Del 2 2. Ta for deg et anvendelsesområde, f.eks. en klesbutikkjede, flyselskap, bank, lag først en OLTP-variant av systemet, deretter et datavarehus. Det er naturlig å dokumentere dette med en datamodell pluss kommentarer. Vi satte opp følgende modell for en OLTP variant: Transformert til at OLAP (datavarehus system) blir da dette med vår forståelse av problematikken slik: 39

40 Ekstra Ekstra for de som synes det er moro (ikke del av oppgaven). Del 1 1. Prøv ut datavarehusfunksjonalitet i et eller flere databasesystemer, og/eller i et spesialsystem for datavarehus. Det ble gjort et forsøk på å sette opp Eclipse Birth for en slik test. Her feilet oppsettet med eksempeltabeller og innhold samt integrering av dette. I prosessen med å velge grunnlagsmateriale frem til rapportene var det ikke gitt hvordan en skulle løse det med et forhånsdefinert dataoppsett. Del 2 2. Gjør rede for hva data mining er. Datamining innebærer å utnytte de dataene som er i et datavarehus/datamart. Via predefinerte filtere og algoritmer søker vi å finne de elementene i datamengden hvor sammenheng ikke er gitt ut fra en vanlig beskuelse. Med dette mener vi at en kan benytte datamining for å finne unntakene fra den vanlige transaksjonsrutinen som datamengden tilsier. For eksempel vil datamengden si oss at hovedsalget av en bestemt vare ligger mellom klokken 2 og 4. Dette forteller oss at på denne tiden må det settes inn mer personale. Men via datamining kan vi for eksempel se at kundene som kom klokka 9 brukte 2 minutter på å kjøpe produktet forutsatt ledige betalingsmuligheter, mens de som handler mellom klokka 2 og 4 bruker lenger tid på å bestemme seg selv med hjelp/veiledning uavhengig av betalingsmuligheter. Dette medfører at kundene som kommer klokka 9 kanskje har større behov for en rask kjøpsprosess. Vi trenger derfor å ha en større andel av personalet på jobb klokka 9. Datamining kan også av banker benyttes for å avdekke transaksjoner som er irregulære. Med andre ord finne de transaksjonene som har en høyere prosentsjanse for å være svindel kontra de andre transaksjonene. Datamining handler da om å finne den ukjente informasjonen i datamengden. Det er viktig for et firma å kunne vite hvem kundene er, hvilke kjøpsmønstre en kan identifisere slik at en for eksempel kan spå fremtidige handlingsmønstre. Slik at det vi finner via datamining vil være valide data som enten understøtter eksisterende besluttninger eller skaper nye besluttninger. Dog er dette den klassiske tilnærming der en benytter konseptet datamining i en bedriftssammenheng. Ved å utvide begrepet kan en benytte prinsippene i et oppsett av sensorer for å spå fremtidige hendelser basert på historiske data og nåverdier i sensorene. Eller en kan benytte det slik amerikanske myndigheter har gjort det for å finne terrorister/antatte terrorister i lister over flypassasjerer via programmer som blant annet Patriotic Act. 40

41 Selv om datamining da i starten hadde sammenheng med begrepet Buisness Intelligence og bruk i forbindelse med bedriftsstrategier. Kan en nå si at datamining kan benyttes til å forutse fremtidige handlinger basert på kjent datamateriale. Og på den annen side finne avvikene i større datamengder som kan ha påvirkning på en fremtidig eller historisk forståelse. Dog er det viktig å påpeke som presentert i gjesteforelesing i faget It i virksomheter at det å spå fremtiden kan gi urealistiske forventninger. En kan ikke lese forventet salg ut fra en spådom, men en kan muligens klare å se at det ser lysere eller mørkere ut basert på fortiden. En kan da ha en formening om hvordan en skal agere proaktivt inn i fremtiden. Det fremheves også i den samme gjesteforelesingen at det å kunne visualisere resultatene av dette er mer viktig siden forståelsen av en graf oftere kommer raskere enn det å lese en halvside + med samme datamengde. Som vi ser av figuren over er det en målsettning etter prosessene å komme frem til en visualisering av datamengden. Øvrige referranser er: 3. Om mulig: besøk et firma som jobber med datavarehus og rapporter! Gruppen har ikke kontakter eller kjennskap til slike firmaer i nærområdet og desverre falt denne bort. 41

42 Oppgaveløsning i gruppen. Oppgave 1 er løst i fellesskap Oppgave 2 del A av den respektive Oppgave 2 del B og C av Kai med unntak av test mot MsSql som er utført av Ole 42