Hovi Huotari Lahdenmäki TIETO- KANTOJEN SUUNNITTELU & INDEKSOINTI

Hovi Huotari Lahdenmäki TIETO- KANTOJEN SUUNNITTELU & INDEKSOINTI

HARJOITUSTEN RATKAISUT

HARJOITUS 1 Formula 1 -maailmaan liittyviä käsitteitä ovat mm. talli, kuski, kierros, rata, kilpailu, sijoitus kilpailussa, sijoitus MM-taulukossa, kausi ja sopimus. Kun 1. brainstorming-kierros on tehty, mietitään mitä käsitteitä (ominaisuuksia) em. käsitteisiin liittyy, esimerkiksi tallista voidaan tallentaa logo, sijainti, tallipäällikkö ja kuskista nimi, kotimaa, puoliso ja asuinpaikka. 3

HARJOITUS 2 Ratkaisuvaihtoehtoja tallin ja kuskin välisen yhteyden mallintamiseksi on ainakin kaksi. Tallin voidaan ajatella olevan riippumaton kuskeista ts. talli voidaan tallentaa ilman, että siihen on liitetty kuskeja. Jos kuskin historiatietoja tallien osalta ei haluta tallentaa ja kuskia ei ole olemassa ilman tallia, saadaan käsitemalliksi Jos kuskin historiatiedot tallien osalta halutaan tallentaa (kuski voi kauden aikana tehdä sopimuksen useamman tallin kanssa) ja kuski voi olla olemassa ilman tallia, saadaan käsitemalliksi Muista, että toimeksiantajalta on osattava kysyä mm. tarve historiatietojen tallentamiseen. Joskus asiaa on kysyttävä useammalta kuin yhdeltä henkilöltä. Käytäntö on osoittanut, että vastaajan nimi ja vastauspäivämäärä kannattaa tallentaa muistiin suunnittelupäätösten tueksi. 4

Moni moneen-yhteys puretaan relaatiomallin mukaan siten, että käsitteiden väliin tulee uusi käsite. Tällä kertaa eräs käsitteistä, sopimus, sopii hyvin tallin ja kuskin väliin. HARJOITUS 3 Käsitteisiin liiittyviä ominaisuuksia ovat esimerkiksi: 5

HARJOITUS 4 Joukkueella on moni moneen-yhteys itseensä. Se puretaan luomalla käsite peli, jolla on kaksi yhteyttä joukkueeseen (yhdessä pelissä tarvitaan kaksi joukkuetta). 6

HARJOITUS 5 Seuraavat yhden käsitteen ratkaisut ovat henkilöiden ja vanhemmuuden mallintamisessa parempia kuin kirjan esimerkki. Nyt kaikki henkilöt, niin vanhemmat kuin lapsetkin, ovat samassa paikassa (huomaa ehdollisuus: henkilöllä ei ole pakko olla isää tai äitiä). Oikeanpuoleinen ratkaisu on sikäli parempi, että mukaan saadaan molemmat vanhemmat. Vasemmanpuoleisesta ratkaisusta syntyy taulujen muodostuksessa yksi viiteavain (vanhemman_htun) ja oikeanpuoleisesta kaksi (aidin_htun, isan_htun). Jos halutaan olla oikein tarkkoja, niin käytännössä lapsella saattaa olla vielä useampia vanhempia kuin äiti ja isä, nimittäin kasvatusisä, äitipuoli jne. Alla oleva ratkaisu on mahdollistaa tämänkin, eli se on vielä yleisempi (tosin nyt ei selvitty yhdellä käsitteellä kuten tehtävässä edellytettiin). Tyyppi pitää sisällään tiedon vanhemmuudesta, esimerkiksi isä, äiti, kasvatusisä. 7

HARJOITUS 6 Kirjassa olevan kuvan ratkaisu on kahdessa suhteessa huono sukututkijan kannalta. Ensinnäkään se ei mahdollista kuin joko biologisten tai kasvatusvanhempien tallentamisen. Vielä suurempi vika on, että lasten lapsien tallentaminen on vaikeaa ja henkilön nimi tulisi tietokantaan kahteen kertaan silloin, jos tallennetaan henkilö, jolla on sekä vanhempia että lapsia. HARJOITUS 7 Tilauksesta puuttuu useita tietoja, esimerkiksi toimitusaika ja -tapa. Tilausriveiltä puuttuvat määrä ja yksikkö. 8

HARJOITUS 8 a) Alla olevassa taulukossa on plus tai miinus sen mukaan, onko ko. asia hyvä vai huono (tietysti joudutaan hieman yleistämään). Esimerkiksi kyselyjen helppous saa plussan denormalisoidussa ratkaisussa, koska liitosten tarve on pienempi ja kyselyt ovat siis yksinkertaisempia. Tauluissa olevien koodien päivittäminen taas on helpompaa normalisoidussa ratkaisussa, koska tarvitsee päivittää vain yhteen paikkaan. Tietokannan eheys on parempi, kun tietoja ei toisteta eikä ole vaaraa, että tiedot ovat eri tasolla. Toisaalta triggerillä voi automatisoida muutokset toistettuihin tietoihin. Rakenteen selkeys -kohdasta kannattaa keskustella. Pienet kantarakenteet ovat selkeitä normalisoituna, mutta mallin laajentuessa ymmärrettävyys saattaa heiketä. Hyvin tehty denormalisointi on yleensä käyttäjien mielestä selkeää ( löytyy samasta taulusta... ). Denormalisointi kuluttaa enemmän levytilaa, mutta levyjen nykyhinnoilla juuri tämä asia ei useinkaan ole enää merkittävä seikka. Asia Normalis. Denorm. kyselyjen helppous - + kyselyjen tehokkuus - + tietokannan eheys + - rakenteen selkeys +/- +/- päivitysten helppous + - päivitysten tehokkuus + - levytila + - b) Ratkaisumalli on kuvattu kirjan liitteessä 3, Rajaton luokittelu. 9

HARJOITUS 9 Tässä ratkaisut esitetään tauluina kuten tehtävässäkin. Normalisoinnin idea on kuvattu selkeyden vuoksi kirjassa taulujen (eikä käsitteiden) avulla; on siis hypätty vähän sivuun suunnitteluputkesta. Nämä harjoitukset kannattaa tehdä normaalimuotojen läpikäynnin jälkeen ja katsoa sen jälkeen kirjasta kohta Denormalisointi. Jakso Normalisointi ja suunnitteluputki sitten kertoo, miten normalisointia sovelletaan käsitemalliin eli palataan tauluista suunnitteluputkeen käsitteiden pariin. a) Normalisoituun ratkaisuun tulee 3 taulua: Henkilotunnus Henkilonimi Valmisohjelmatunnus Valmisohjelmanimi Henkilotunnus Valmisohjelmatunnus Tunnit b) 2 taulua: Tyontekija Osastotunnus Osastotunnus OsastonSijainti c) 2 taulua: Varastotunnus VarastonOsoite Varastotunnus Tuotenumero Varastosaldo 10

d) Jos henkilö kuuluu yhteen projektiin, tulee 2 taulua: Henkilotunnus Henkilonimi Kuukausipalkka Projektitunnus Projektitunnus Projektibudjetti Jos henkilö voi kuulua moneen projektiin (mikä olisi joustavampaa), tulee 3 taulua: Henkilotunnus Henkilonimi Kuukausipalkka Projektitunnus Henkilotunnus Projektitunnus Projektibudjetti 11

HARJOITUS 10 Tehtävän perusavain tuntuu huonolta. Jos osaston tunnus juoksee osaston sisällä, ovat osaston tunnukset esim. seuraavia: Osastotunnus JuoksevaNro Nimi... 10 1 Joki 10 2 Järvi 10 3 Ranta 20 1 Virta 20 2 Lehto...... Perusavain on erityisen huono tilanteessa, jossa henkilö vaihtaa osastoa (kaikki viiteavaimet muistakin tauluista on tällöin päivitettävä). Kannattaa valita koko talon sisällä juokseva numero, siis surrogaatti; annamme sille nimeksi Hnro, joka nyt ei koskaan muutu. Oletamme, että henkilö voi kuulua vain yhteen osastoon, jolloin Osastotunnus-sarakkeesta tulee tavallinen, funktionaalisesti perusavaimesta riippuva sarake muiden joukkoon. Lisäksi huomataan, että taitokoodi ei ole funktionaalisesti riippuva perusavaimesta se on siis erotettava omaan tauluunsa. Ratkaisu on nyt seuraava (2 taulua): Hnro Nimi Osoite Tyonimike Palkka Osastotunnus Hnro Taitokoodi Huomaa erityisesti, että sekä Hnro:n että Taitokoodin pitää olla mukana uuden taulun perusavaimessa (jos perusavain on pelkkä Hnro, ei taitokoodi edelleenkään ole funktionaalisesti riippuva Hnrosta). 12

HARJOITUS 11 Taulut liitteen 2 esimerkkiyrityksen käsitemallista tullaan laittamaan virtuaaliammattikorkeakoulun (http://www.amk.fi) Tietokantojen perusteet -opintojakson sivuille. Seuraa kurssitarjontaa! Tässä on yksi esimerkki tietokannan taulujen luontilauseista: /* Demox Oy -tietokannan perustaminen */ /* ASIAKAS */ CREATE TABLE asiakas ( astunnus CHAR(6) NOT NULL, asnimi CHAR(30) NOT NULL, yhteyshlo CHAR(30), /* lahios CHAR(35), lisätään myöhemmin */ postinro CHAR(5), postitmp CHAR(30), /* puhelinnro CHAR(15), lisätään myöhemmin */ asvuosi SMALLINT, CONSTRAINT asiakas_pk PRIMARY KEY (astunnus), CONSTRAINT asnimi_un UNIQUE (asnimi) ) ; INSERT INTO asiakas VALUES ( MANNIN, Manninen, Jokinen, 90100, Oul u,1997) ; INSERT INTO asiakas VALUES ( SARA, Sara Oy, Herva, 00100, Helsinki,2000) ; INSERT INTO asiakas VALUES ( NASI, Näsi Oy,, 33700, Tampere,200 0) ; INSERT INTO asiakas VALUES ( ITPRO, IT-Profes, Ojala, 90100, Oulu,2001) ; INSERT INTO asiakas VALUES ( MASI, MasiYards, Oja, 20100, Turku,1 999) ; INSERT INTO asiakas VALUES ( NUUKIA, Nuukia Ky, Aro, 90100, Oulu, 2002) ; INSERT INTO asiakas VALUES ( TELE, Tele Oy,, 00100, Helsinki,20 02) ; /* TUOTERYHMÄ */ CREATE TABLE tuoteryhma ( trnro CHAR(3), trnimi CHAR(30), CONSTRAINT tuoteryhma_pk PRIMARY KEY (trnro) ) ; 13

INSERT INTO tuoteryhma VALUES ( 11, Asusteet ); INSERT INTO tuoteryhma VALUES ( 12, Laukut ); INSERT INTO tuoteryhma VALUES ( 13, Taloustavarat ); INSERT INTO tuoteryhma VALUES ( 14, Toimistotarvikkeet ); /* TUOTE */ CREATE TABLE tuote ( tuotenro INTEGER, tuotenimi CHAR(30) NOT NULL, hinta DECIMAL(5,2), kustannus DECIMAL(5,2), /* lisätty tuotantokustannus */ trnro CHAR(3) NOT NULL, CONSTRAINT tuote_pk PRIMARY KEY (tuotenro), CONSTRAINT tuotenimi_un UNIQUE (tuotenimi), CONSTRAINT tuote_ryhma_fk FOREIGN KEY (trnro) REFERENCES tuoteryhma (trnro) ) ; INSERT INTO tuote VALUES (1, Silkkisolmio,15.00,6.00, 11 ) ; INSERT INTO tuote VALUES (2, Kuksa,28,14.5, 13 ) ; INSERT INTO tuote VALUES (3, Puukko,27,19.6, 13 ) ; INSERT INTO tuote VALUES (4, Silkkihuivi,20,12.3, 11 ) ; INSERT INTO tuote VALUES (5, Paperiveitsi,16,7.4, 14 ) ; INSERT INTO tuote VALUES (6, Lompakko,31,24.85, 12 ) ; INSERT INTO tuote VALUES (7, Kukkaro,16,NULL, 12 ) ; /* TILAUS */ CREATE TABLE tilaus ( tilausnro INTEGER NOT NULL, astunnus CHAR(6) NOT NULL, tilauspvm DATE NOT NULL, tapa CHAR(1) NOT NULL, tila CHAR(1) NOT NULL, CONSTRAINT tilaus_pk PRIMARY KEY (tilausnro), CONSTRAINT tilaus_asiakas_fk FOREIGN KEY (astunnus) REFERENCES asiakas (astunnus) ) ; INSERT INTO tilaus VALUES (100, MANNIN, 1999-9-19, L, M ); INSERT INTO tilaus VALUES (101, MASI, 1999-11-11, V, M ); INSERT INTO tilaus VALUES (102, SARA, 2000-2-12, L, M ); INSERT INTO tilaus VALUES (202, MASI, 2002-2-10, V, M ); INSERT INTO tilaus VALUES (206, NASI, 2002-4-13, V, L ); INSERT INTO tilaus VALUES (207, ITPRO, 2002-9-15, L, T ); INSERT INTO tilaus VALUES (208, NUUKIA, 2002-10-10, V,NULL); INSERT INTO tilaus VALUES (209, MASI, 2002-10-20, L,NULL); /* TILAUSRIVI */ 14

CREATE TABLE tilausrivi ( tilausnro INTEGER NOT NULL, rivinro SMALLINT NOT NULL, tuotenro INTEGER, kpl INTEGER, 15

OSA HARJOITUSTEN RATKAISUT

HARJOITUS 12 Minimoidaan hajalukujen määrä Jos taulurivejä luetaan indeksin kautta, jokainen iso mies aiheuttaa ainakin yhden hajaluvun tauluun. Tauluun kohdistuvien hajalukujen välttämiseksi on kaikki SELECT-lauseen sarakkeet kopioitava samaan indeksiin. SUKUPUOLI on ainoa sarake, joka voi rajata tutkittavan indeksiviipaleen (jos luetaan pelkästään sarakkeiden SUKUPUOLI ja PAINO rajaama viipale, pitkät ja laihat miehet jäävät pois tulostaulusta). Muiden sarakkeiden järjestys ei vaikuta tutkittavan indeksiviipaleen paksuuteen. Koska ASNO on perusavain, indeksin päivityskustannusten minimointi puoltaa sen sijoittamista toiseksi indeksisarakkeeksi. Tällöin esimerkiksi asiakkaan painon päivitys ei aiheuta indeksirivin siirtoa lehtisivulta toiselle. Vaihtoehto 1 SUKUPUOLI, ASNO, PITUUS, PAINO, SUKUNIMI, ETUNIMI Tästä indeksistä on luettava puolet, jos asiakkaiden sukupuolijakautuma on 50/50. Tulosrivit on lopuksi lajiteltava ORDER BY -määreen mukaiseen järjestykseen. Indeksipuolikkaan läpiluvun vaatima CPU-aika on suunnilleen puolet taulun läpiluvun vaatimasta CPU-ajasta. Levyaikojen suhde on suurempi kuin 1:2, koska taulusivuja on todennäköisesti enemmän kuin tämän indeksin lehtisivuja (aivan varmaa tämä ei ole, koska taulurivit voivat olla tiivistettyjä ja lisäksi lehtisivuille halutaan ehkä määritellä enemmän tyhjää tilaa kuin taulusivuille etenkin, jos uudet asiakkaat lisätään taulun loppuun). Tämän indeksin hyöty on siis varsin vähäinen: se lyhentää kyselyn kestoa noin 50 % taulun läpilukuun verrattuna, jos peräkkäiskäsittely on CPU-sidonnaista hieman enemmän, jos peräkkäiskäsittely on levysidonnaista ja jos indeksi on pienempi kuin taulu. Eliminoidaan lajittelu Jos sarakkeet SUKUNIMI ja ETUNIMI sijoitetaan toiseksi ja kolmanneksi, isojen miesten indeksirivit ovat ORDER BY -määreen mukaisessa järjestyksessä. Kun ASNO on neljäs indeksisarake, pituus- ja painomuutokset eivät aiheuta indeksirivin siirtoa. Sen sijaan nimimuutokset ovat hieman kalliimpia kuin vaihtoehdossa 1, koska ne voivat vaatia kahden lehtisivun hajaluvun ja päivityksen. Vaihtoehto 2 SUKUPUOLI, SUKUNIMI, ETUNIMI, ASNO, PITUUS, PAINO Lajitteluajan osuus vasteajasta on nykylaitteistoilla vähäinen, jos lajittelun työtilat keskusmuistissa ovat riittävän suuret. Siksi tämä indeksi johtaa vain hieman ly- 17

hyempään vasteaikaan kuin vaihtoehto 1, jos ohjelma rakentaa koko tulostaulun. Vaihtoehto 2 on tuntuvasti parempi kuin vaihtoehto 1, jos yksi tapahtuma rakentaa vain yhden kuvaruudullisen (esimerkiksi enintään 20 FETCH-kutsua): lajittelun eliminointi merkitsee sitä, että TKHJ ei aineellista tulostaulua OPEN CURSOR -kutsussa tai ensimmäisessä FETCH-kutsussa. Levyaikaennusteita Oletetaan, että viiden indeksisarakkeen yhteispituus on 60 tavua. Karkea arvio indeksin koosta saadaan kaavalla 1.5 taulurivien määrä indeksisarakkeiden yhteispituus. Kerroin 1.5 kattaa sirotellun tyhjän tilan, osoittimet ja muut TKHJtiedot sekä ylätasot (ei-lehtisivut). Se ei sisällä RAID-lisäkustannuksia, jotka vaikuttavat levytilantarpeeseen mutta eivät indeksin läpilukuaikaan. Oletetaan, että indeksin sivukoko on 4 kilotavua. Tällöin peräkkäisluvun kesto on nopeimmilla levypalvelimilla 0,1 ms per sivu. 8 kilotavun sivut johtavat samaan lopputulokseen, koska levyaika on tällöin 0,2 ms per sivu. Vaihtoehto 1 Indeksin koko on karkean kaavan mukaan 1,5 1 000 000 60 tavua = 90 MB. Tämä sisältää ei-lehtisivut, mutta niiden osuus on yleensä vain pari prosenttia, joten yksinkertaisuuden vuoksi voidaan olettaa, että neljän kilotavun lehtisivuja on 90 000 kb / 4 kb = 22 500. Läpilukuaika nopeilla nykylevyillä on tällöin 22 500 0,1 ms = 2,2 sekuntia. Jos puolet asiakkaista on miehiä, luetaan puolet indeksistä. Tähän kuluva levyaika on 1,1 sekuntia. Täydellisyyden vuoksi on vielä mainittava, että indeksiviipaleen ensimmäinen lehtisivu vaatii aina hajaluvun. Koska yhden sivun hajaluku kestää noin 10 ms, se ei tässä tapauksessa vaikuta estimaattiin. Vaihtoehto 2 Jos ohjelma lukee (FETCH) kaikki tulosrivit, tulos on sama kuin yllä. Jos ohjelma lukee korkeintaan 20 tulosriviä tapahtumaa kohti, yksi tapahtuma lukee indeksiviipaleen, josta löytyy 20 isoa miestä. Jos joka 25. mies on iso (jolloin tulostaulussa on 20 000 riviä), yhden tapahtuman lukemassa indeksiviipaleessa on keskimäärin 20 25 riviä = 500 riviä. Lehtisivujen määrä viipaletta kohti on (500 riviä / 1 000 000 riviä) 22 500 lehtisivua = 12 lehtisivua. Levyaika tapahtumaa kohti on 10 ms + 11 0,1 ms = 11 ms. Entä CPU-aika? CPU-ajan arviointi on työläämpää kuin levyajan arviointi. Peräkkäisluvussa se riippuu ensisijaisesti FETCH-kutsujen määrästä ja tutkittujen sivujen määrästä. Peräkkäislukuun liittyvän FETCH-kutsun vaatima CPU-aika on helppo saada selville parilla mittauksella. Nopeimmilla nykysuorittimilla se on noin 0,1 ms, jos 18

yhtään riviä ei hylätä. Jos esimerkiksi miljoonarivinen taulu luetaan läpi miljoonalla FETCH-kutsulla, CPU-aika on noin 1 000 000 0,1 ms = 100 sekuntia Rivin tutkimiseen kuluva aika vaihtelee huomattavasti. Se riippuu lähinnä predikaattien määrästä ja monimutkaisuudesta. Peukalosääntö melko yksinkertaisille WHERE-lausekkeille on 0,01 ms nopeimmilla nykysuorittimilla. Vaihtoehto 1 Isoja miehiä on 20 000. Täten FETCH-kutsuja on 20 001 ja tutkittavia rivejä 500 000. Karkea arvio CPU-ajalle on 20 000 0,1 ms + 500 000 0,01 ms = 7 sekuntia. Vaihtoehto 2 Jos ohjelma suorittaa enintään 20 FETCH-kutsua tapahtumaa kohti, tutkittavia rivejä on keskimäärin 500. Karkea arvio CPU-ajalle on 20 0,1 ms + 500 0,01 ms = 7 millisekuntia. Vasteaika Koska peräkkäisluvussa levyaika ja CPU-aika limittyvät (sekä TKHJ että levypalvelin lukevat tietyn määrän sivuja eteenpäin), läpiluvun kesto on hajaluvun levyaika + MAX (peräkkäisluvun levyaika, (CPU-aika + CPUjonoaika)). Esimerkkitapauksessa peräkkäisluku on CPU-sidonnaista: sivut eivät koskaan pääse loppumaan keskusmuistin puskurialtaasta. Vaihtoehdon 1 vasteaika on ainakin 7 sekuntia ja vaihtoehdon 2 ainakin 17 millisekuntia Miksi ainakin? Lähinnä siksi, että monen käyttäjän ympäristössä kukin ohjelma joutuu joskus odottamaan vapaata suoritinta. Jos suorittimet ovat ylikuormituksen partaalla, CPU-jonoaika voi olla samaa luokkaa kuin CPU-aika. Vaihtoehdon 1 vasteaika voi tällöin olla 14 sekuntia. Lisäksi vasteaikaa kasvattaa tapahtuman käynnistämiseen ja lopettamiseen kuluva CPU-aika, esimerkiksi pari millisekuntia. Vaihtoehdon 2 vasteaika voi täten olla 10 ms + 2 9 ms = 28 millisekuntia. Nämä vasteajat tarkoittavat ensimmäistä kuvaruudullista. Seuraavien kuvaruudullisten lukeminen on hyvin nopeaa vaihtoehdossa 1 (ehkä vain muutama millisekunti). Vaihtoehdossa 2 jokainen täysi kuvaruudullinen vaatii noin 28 millisekunnin odotuksen. Tätä eroa ei käyttäjä taida huomata. 19

HARJOITUS 13 Kandidaatti 1 Kaikki predikaatit ovat riittävän helppoja optimointiohjelmalle, ainakin jos tietotyypit täsmäävät. 1. Poimitaan sarakkeet C ja F. Järjestyksellä ei ole väliä. 2. Poimitaan sarake B, koska siihen viittaavalla arvoväliehdolla on pienempi läpäisykerroin kuin predikaatilla E > 0. 3. ORDER BY -määreen sarakkeet B, C ja F on jo poimittu vaiheessa 1. Nyt poimitaan sarake A. 4. Lisätään puuttuvat sarakkeet D ja E mielivaltaisessa järjestyksessä. Lopputulos on C, F, B, A, D, E. Seuraavat variaatiot ovat yhtä hyviä annetun SELECT-lauseen näkökulmasta: C, F, B, A, E, D F, C, B, A, D, E F, C, B, A, E, D Indeksirivit eivät ole oikeassa järjestyksessä, joten TKHJ joutuu lajittelemaan tulosrivit. Tarvitaan kandidaatti 2. Sivuhuomautus: koska lajittelua ei onnistuttu torjumaan, on kolmen viimeisen sarakkeen järjestys mielivaltainen jos A on volatiili sarake, se voidaan sijoittaa viimeiseksi. Kandidaatti 2 1. Poimitaan sarakkeet C ja F. Järjestyksellä ei ole väliä. 2. Poimitaan sarakkeet A ja B. ORDER BY -määreen redundantit sarakkeet C ja F on jo poimittu. 3. Lisätään loput sarakkeet mielivaltaisessa järjestyksessä. Lopputulos on C, F, A, B, D, E tai jokin seuraavista: C, F, A, B, E, D F, C, A, B, D, E F, C, A, B, E, D 20

HARJOITUS 14 a) Sovellusohjelma rakentaa koko tulostaulun yhdessä tapahtumassa (1 001 FETCH-kutsua) Indeksiviipaleen paksuus on 1000 riviä. PV = 1 10 ms + 1 000 0,1 ms = 110 ms b) Sovellusohjelma rakentaa yhden kuvaruudullisen yhdessä tapahtumassa (20 FETCH-kutsua) Indeksiviipaleen paksuus on 20 riviä. PV = 1 10 ms + 19 0,1 ms = 12 ms Voiko tämä olla totta? Kyllä. SUKUNIMI, KUNTA, ETUNIMI, ASNO on kolmen tähden indeksi. HARJOITUS 15 Pahimman tapauksen pikaennusteet Kandidaatti 1 (C, F, B, A, D, E) Rajaavia sarakkeita on kolme (MC = 3). Lajittelun vuoksi TKHJ joutuu lukemaan koko sen indeksiviipaleen, jonka näihin kolmeen sarakkeeseen viittaavat predikaatit rajaavat. Pahimmassa tapauksessa rajaavien predikaattien (matching predicates) läpäisykertoimet ovat 10 %, 2 % ja 1 %. Jos näiden välillä ei ole tilastollista korrelaatiota yhdistetyn predikaatin B BETWEEN :B1 AND :B2 AND C = 1 AND F = :F läpäisykerroin on suurimmillaan 0,1 0,02 0,01 = 0,000 02 eli 1 / 50 000. Indeksiviipaleen paksuus on tällöin 100 000 000 / 50 000 = 2 000. Tauluun ei tehdä yhtään sipaisua, koska indeksi on paksu. PV = 1 10 ms + 2 000 0,1 ms = 210 ms. Lajitteluaikaa ei huomioida pikaennusteessa (eikä 2 000 rivin lajittelu paljon aikaa viekään). 21

Kandidaatti 2 (C, F, A, B, D, E) Rajaavia sarakkeita on kaksi, C ja F. Näiden rajaaman viipaleen maksimipaksuus on 0,02 0,01 100 000 000 riviä = 20 000 riviä. Koska saantipolussa ei ole lajittelua ja ohjelma suorittaa enintään 20 FETCHkutsua, pahin tapaus on nyt se, jossa tulosrivit ovat kaukana toisistaan toisin sanoen ei-rajaavien predikaattien läpäisykertoimet ovat pienimmillään: LK(B BETWEEN :B1 AND :B2) = 1 % LK(E > 0) = 50 % Jos sarakkeiden B ja E välillä ei ole tilastollista korrelaatiota, yhdistetyn predikaatin LK on 0,5 %. Yhden tulosrivin löytäminen vaatii siis keskimäärin 200 sipaisua (1 / LK) ja 20 FETCH-kutsua aiheuttaa 20 200 sipaisua. PV = 1 10 ms + 4 000 0,1 ms = 410 ms. Johtopäätös Kandidaatti 1 on paras mahdollinen indeksi. Ensimmäisen kuvaruudun rakentava tapahtuma kestää pikaennusteen mukaan tällä indeksillä pahimmassa tapauksessa 0,2 sekuntia. Sivuhuomautus Miten suuri tulostaulu on? Montako kuvaruudullista? Minimikoko on 1/100 1/50 ½ 1/1 000 100 000 000 riviä = 10 riviä. Maksimikoko on 1/10 1/50 ½ 1/100 = 1 000 riviä = 50 kuvaruudullista. 22

HARJOITUS 16 Muu SQL-aika 7 sekuntia Jos SQL-kutsu ei suorita käskyjä eikä odota lukon vapautumista tai tietokantasivun lukua levyltä, se odottaa jotakin muuta. Tavallisin selitys on CPU-jonoaika, mutta se vaikuttaa tämän naulan kohdalla epätodennäköiseltä, koska CPU-aika on alle puoli sekuntia. Näin suuri suhde jonoajan ja palveluajan välillä merkitsisi suorittimien vakavaa ylikuormitusta, jolloin samantyyppisiä nauloja olisi paljon. Luultavasti kyse on tiedostoluettelon päivityksestä tiedostojen avaamisen tai laajentumisen vuoksi. Todellisen syyn paljastaa se laaja naulakohtainen raportti, josta naularaportin luvut on poimittu. Laaja raportti kannattaa säilyttää levyllä, kunnes naularaportti on tutkittu. Joka tapauksessa kyseessä on uhri. Sovellusohjelmaa tai indeksointia parantamalla ei tähän vasteajan osaan varmaankaan voi vaikuttaa. Synkroninen levyaika 1 sekunti Synkronisen levyluvun keskimääräinen kesto (9 ms) välimuistilukujen ja kiintolevylukujen painotettu keskiarvo on pitkähkö. Valtaosa synkronisista levyluvuista menee kiintolevylle asti tai kiintolevyt ovat lievästi ylikuormittuneita. Koska 91 % synkronisista levyluvuista kohdistuu taulusivuihin, on virityspotentiaali lähes 1 sekunti. Tätä ohjelmaa kannattaa tutkia, jos se aiheuttaa toistuvasti (ainakin kerran tunnissa) lähes sata synkronista levylukua. Jos kiintolevyjen käyttöaste (drive busy) on yli 25 %, keskimääräinen levyluvun kesto nousee ja tulee yhä vaihtelevammaksi kuormituksen kasvaessa. Johtopäätös Jos tämäntyyppisiä nauloja esiintyy useita tunnissa, on käyttöorientoituneen tietokantaspesialistin syytä tutkia, mikä odotuksia aiheuttaa. Kyseessä voi olla systeemitason epävireisyys. Tauluihin kohdistuvien levylukujen vähentäminen indeksointia parantamalla tai optimointiohjelmaa auttamalla on suositeltava ennaltaehkäisevä virityshanke, jos isommat ongelmat on jo hoidettu. 23

HARJOITUS 17 Vaihtoehto 1 Indeksi ASMAA HS = 1, PS = 10 000 Taulu ASIAKAS HS = 10 000 Indeksi ASNO HS = 10 000, PS = 200 000 Taulu MTILAUS HS = 10 000, PS = 200 000 Yhteensä HS = 30 001, PS = 410 000 PV = 30 001 10 ms + 410 000 0,1 ms = 341 sekuntia Keskitapauksessa nested loop on siis nopeampi kuin merge scan. MTILAUS-taulun läpiluku veisi VQUBEn mukaan 2 000 sekuntia. Vaihtoehto 2 Indeksi ASMAA, ASNO, ASNIMI, ASLK HS = 1, PS = 10 000 Indeksi ASNO, MTILEUR DESC, MTILNO HS = 10 000, PS = 20 Yhteensä HS = 10 001, PS = 10 020 PV = 10 001 10 ms + 10 020 0,1 ms = 101 sekuntia MTILEUR on rajaava sarake. Jos asiakkaalla ei ole yhtään isoa tilausta, TKHJ tekee vain yhden hajasipaisun indeksiin ASNO, MTILEUR DESC, MTILNO. Jos asiakkaalla on yksi iso tilaus, se luetaan hajasipaisulla. Seuraava peräkkäissipaisu paljastaa, että muita isoja tilauksia ei tällä asiakkaalla ole. Jos tulostaulussa on 20 riviä (0,01 0,0001 20 000 000), peräkkäissipaisuja indeksiin ASNO, MTI- LEUR DESC, MTILNO tulee yhteensä 20. Vaihtoehto 3 Indeksi MTILEUR DESC, MTILNO, ASNO HS = 1, PS = 2 000 Indeksi ASNO, ASMAA, ASNIMI, ASLK HS = 2 000 Yhteensä HS = 2 001, PS = 2 000 PV = 2 001 10 ms + 12 000 0,1 ms = 20 sekuntia Jos sarakkeiden ASMAA ja MTILEUR välillä ei ole tilastollista korrelaatiota, tulostaulun koko on 0,01 0,0001 20 000 000 = 20 riviä eli yksi kuvaruudullinen. 24

Vaihtoehto 4 Indeksi ASMAA, MTILEUR DESC, MTILNO, ASNO HS = 1, PS = 19 Indeksi ASNO, ASNIMI, ASLK HS = 20 Yhteensä HS = 21, PS = 19 PV = 21 10 ms + 19 0,1 ms = 0,2 sekuntia Sarake ASMAA kannattaa ilman muuta kopioida MTILAUS-tauluun. HARJOITUS 18 Nested loop -liitoksen ensimmäinen taulu on luonnollisesti ASIAKAS (vain yksi paikallisrivi). Muiden taulujen järjestyksellä ei ole väliä. Jos vain yläsivut ovat keskusmuistissa tai levypalvelimen välimuistissa, tämä SELECT aiheuttaa 8 hajalevylukua. Pieniin kooditauluihin ASK1, ASK2 ja ASK3 kannattaa luoda paksut indeksit (ASK1P, ASK1T jne). Tällöin hajalevylukujen määrä putoaa viiteen. Jos SELECT-lause suoritetaan miljoona kertaa eräajossa, pienten taulujen paksujen indeksien lehtisivut luetaan todennäköisesti vain kerran; sen jälkeen ne pysyvät keskusmuistissa, koska kuhunkin lehtisivuun viitataan usein. Liitoksen aiheuttama lisäkustannus on tällöin lähinnä CPU-aikaa. Kunkin indeksirivin lukeminen voi viedä esimerkiksi 50 mikrosekuntia CPU-aikaa, vaikka indeksirivi on valmiiksi tietokanta-altaassa. Liitos kasvattaa tällöin eräajon CPU-aikaa 1 000 000 3 50 s = 150 sekuntia. Tämän verran voidaan säästää, jos sarakkeet ASK1T, ASK2T ja ASK3T lisätään ASIAKAS-tauluun. Oletetaan, että näiden sarakkeiden pituus on 40 tavua. Levytilatarve kasvaa tällöin noin 1,5 1 000 000 120 tavua = 180 MB. Jos gigatavun kuukausivuokra on 100 euroa, taulun paksunnos maksaa 18 euroa kuukaudessa. Pienet parametritaulut ja vastaavat voivat kasvattaa tuntuvasti CPU-aikaa, jos tapahtuma tai eräajon kukin tapaus viittaa kymmeniin tällaisiin tauluihin. 25

HARJOITUS 19 Bittikarttaindeksi 200 miljoonan bitin vektori vie tiivistämättömänä 25 megatavua levytilaa. CIAesimerkin kuudessa bittikarttaindeksissä on yhteensä noin 300 arvoa (100 syntymävuotta, 100 toimialaa, 50 osavaltiota, 10 hiusten väriä, 10 silmien väriä ja 2 silmälasiarvoa). 300 25 MB = 7,5 GB. Koska moniarvoisissa bittikartoissa on pitkiä nollaketjuja, tilantarve on huomattavasti pienempi tiivistyksen jälkeen. B-puu-indeksi Ominaisuussarakkeet ovat lyhyitä (yksi tai kaksi tavua), mutta perusavain voi tässä tapauksessa viedä esimerkiksi 50 tavua (miten USA:ssa asuvat yksilöidään?). Oletetaan, että indeksisarakkeiden yhteispituus on 60 tavua. Tällöin indeksin koko on 1,5 200 000 000 60 tavua = 18 GB. Ero paksun B-puu-indeksin ja tiivistetyn bittikarttaindeksin välillä voi olla lähes 18 GB. Jos levytilan kuukausivuokragigatavulta on 100 euroa, kustannusero on lähes 1 800 euroa kuukaudessa. Johtopäätös Levytilan halpeneminen vähentää bittikarttaindeksien houkuttelevuutta. On kuitenkin huomattava, että CIA-tyyppisissä sovelluksissa paksuja indeksejä tarvitaan todennäköisesti useita ja niiden suunnittelu vaatii kyselyjen ennakointia. Yksi bittikarttaindeksi per hakutekijä luo valmiuden minkä tahansa WHERE-lausekkeen tehokkaaseen käsittelyyn kunhan tulostaulun koko eli luettavien taulurivien määrä on kohtuullinen (korkeintaan noin 10 000). 26

HARJOITUS 21 Ne, jotka vielä muistavat Boolen algebraa opiskeluajoiltaan, voivat muuntaa WHERE-lausekkeen mekaanisesti sellaiseksi, jossa ei ole OR-operaattoria. Meidän muiden on ehkä turvauduttava kaavioon, joka kuvaa kursorin CURSOR15 tulostaulua: Kursorin CURSOR15 tulostaulu voidaan ilmaista seuraavasti ilman OR-operaattoria: WHERE SUKUNIMI => :SUKUNIMIED AND SUKUNIMI =< :SUKUNIMI2 AND NOT (SUKUNIMI = :SUKUNIMIED AND ASNO =< :ASNOED). Kaksi ensimmäistä predikaattia ovat BT ja riittävän yksinkertaisia optimointiohjelmalle. SUKUNIMI on siis rajaava sarake (MC = 1). Kun tämän WHERElausekkeen sisältävä kursori avataan, TKHJ alkaa tutkia indeksiviipaletta, jonka ensimmäisillä riveillä sarakkeen SUKUNIMI arvo on :SUKUNIMIED. TKHJ ei siis aloita indeksin alusta, mutta se lukee (ja hylkää) joitakin jo näytettyjä rivejä. Turhat sipaisut ovat kuitenkin peräkkäissipaisuja, joten vasteaikaero kahden kursorin ratkaisun ja ylläesitetyn yhden kursorin ratkaisun välillä on usein hyvin pieni. 27