Hovi Huotari Lahdenmäki TIETO- KANTOJEN SUUNNITTELU & INDEKSOINTI
|
|
- Martta Nurminen
- 8 vuotta sitten
- Katselukertoja:
Transkriptio
1 Hovi Huotari Lahdenmäki TIETO- KANTOJEN SUUNNITTELU & INDEKSOINTI
2 HARJOITUSTEN RATKAISUT
3 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
4 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
5 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
6 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
7 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
8 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
9 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
10 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
11 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
12 HARJOITUS 10 Tehtävän perusavain tuntuu huonolta. Jos osaston tunnus juoksee osaston sisällä, ovat osaston tunnukset esim. seuraavia: Osastotunnus JuoksevaNro Nimi 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
13 HARJOITUS 11 Taulut liitteen 2 esimerkkiyrityksen käsitemallista tullaan laittamaan virtuaaliammattikorkeakoulun ( 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
14 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, , L, M ); INSERT INTO tilaus VALUES (101, MASI, , V, M ); INSERT INTO tilaus VALUES (102, SARA, , L, M ); INSERT INTO tilaus VALUES (202, MASI, , V, M ); INSERT INTO tilaus VALUES (206, NASI, , V, L ); INSERT INTO tilaus VALUES (207, ITPRO, , L, T ); INSERT INTO tilaus VALUES (208, NUUKIA, , V,NULL); INSERT INTO tilaus VALUES (209, MASI, , L,NULL); /* TILAUSRIVI */ 14
15 CREATE TABLE tilausrivi ( tilausnro INTEGER NOT NULL, rivinro SMALLINT NOT NULL, tuotenro INTEGER, kpl INTEGER, 15
16 OSA HARJOITUSTEN RATKAISUT
17 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
18 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, 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 kb / 4 kb = Läpilukuaika nopeilla nykylevyillä on tällöin ,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 riviä), yhden tapahtuman lukemassa indeksiviipaleessa on keskimäärin riviä = 500 riviä. Lehtisivujen määrä viipaletta kohti on (500 riviä / riviä) lehtisivua = 12 lehtisivua. Levyaika tapahtumaa kohti on 10 ms ,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
19 yhtään riviä ei hylätä. Jos esimerkiksi miljoonarivinen taulu luetaan läpi miljoonalla FETCH-kutsulla, CPU-aika on noin ,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 Täten FETCH-kutsuja on ja tutkittavia rivejä Karkea arvio CPU-ajalle on ,1 ms ,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 ,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 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
20 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 > 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
21 HARJOITUS 14 a) Sovellusohjelma rakentaa koko tulostaulun yhdessä tapahtumassa (1 001 FETCH-kutsua) Indeksiviipaleen paksuus on 1000 riviä. PV = 1 10 ms ,1 ms = 110 ms b) Sovellusohjelma rakentaa yhden kuvaruudullisen yhdessä tapahtumassa (20 FETCH-kutsua) Indeksiviipaleen paksuus on 20 riviä. PV = 1 10 ms ,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, eli 1 / Indeksiviipaleen paksuus on tällöin / = Tauluun ei tehdä yhtään sipaisua, koska indeksi on paksu. PV = 1 10 ms ,1 ms = 210 ms. Lajitteluaikaa ei huomioida pikaennusteessa (eikä rivin lajittelu paljon aikaa viekään). 21
22 Kandidaatti 2 (C, F, A, B, D, E) Rajaavia sarakkeita on kaksi, C ja F. Näiden rajaaman viipaleen maksimipaksuus on 0,02 0, riviä = 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 sipaisua. PV = 1 10 ms ,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/ riviä = 10 riviä. Maksimikoko on 1/10 1/50 ½ 1/100 = riviä = 50 kuvaruudullista. 22
23 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
24 HARJOITUS 17 Vaihtoehto 1 Indeksi ASMAA HS = 1, PS = Taulu ASIAKAS HS = Indeksi ASNO HS = , PS = Taulu MTILAUS HS = , PS = Yhteensä HS = , PS = PV = ms ,1 ms = 341 sekuntia Keskitapauksessa nested loop on siis nopeampi kuin merge scan. MTILAUS-taulun läpiluku veisi VQUBEn mukaan sekuntia. Vaihtoehto 2 Indeksi ASMAA, ASNO, ASNIMI, ASLK HS = 1, PS = Indeksi ASNO, MTILEUR DESC, MTILNO HS = , PS = 20 Yhteensä HS = , PS = PV = ms ,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, ), peräkkäissipaisuja indeksiin ASNO, MTI- LEUR DESC, MTILNO tulee yhteensä 20. Vaihtoehto 3 Indeksi MTILEUR DESC, MTILNO, ASNO HS = 1, PS = Indeksi ASNO, ASMAA, ASNIMI, ASLK HS = Yhteensä HS = 2 001, PS = PV = ms ,1 ms = 20 sekuntia Jos sarakkeiden ASMAA ja MTILEUR välillä ei ole tilastollista korrelaatiota, tulostaulun koko on 0,01 0, = 20 riviä eli yksi kuvaruudullinen. 24
25 Vaihtoehto 4 Indeksi ASMAA, MTILEUR DESC, MTILNO, ASNO HS = 1, PS = 19 Indeksi ASNO, ASNIMI, ASLK HS = 20 Yhteensä HS = 21, PS = 19 PV = ms ,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 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, 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
26 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) 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, 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 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 ). 26
27 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
SQL-perusteet, SELECT-, INSERT-, CREATE-lauseet
SQL-perusteet, SELECT-, INSERT-, CREATE-lauseet A271117, Tietokannat Teemu Saarelainen teemu.saarelainen@kyamk.fi Lähteet: Leon Atkinson: core MySQL Ari Hovi: SQL-opas TTY:n tietokantojen perusteet-kurssin
LisätiedotNORMALISOINTI TIETOJEN MALLINNUS JOUNI HUOTARI & ARI HOVI
TIETOJEN MALLINNUS NORMALISOINTI HOVI, HUOTARI, LAHDENMÄKI: TIETOKANTOJEN SUUNNITTELU & INDEKSOINTI DOCENDO (2003, 2005) LUKU 5 JOUNI HUOTARI & ARI HOVI SUUNNITTELUPUTKI Käyttäjien näkemykset Näytöt, ikkunat
LisätiedotSQL - STRUCTURED QUERY LANGUAGE
SQL Peruskomentoja SQL - STRUCTURED QUERY LANGUAGE SQL on tietokantojen käsittelyyn kehitetty kieli Esimerkkejä kielellä hoidettavistaa toiminnoista: Tietokannan rakenteen määrittely ja muuttaminen Kyselyt
LisätiedotTIEDONHALLINNAN PERUSTEET - SYKSY 2013
TIEDONHALLINNAN PERUSTEET - SYKSY 2013 Kurssikoodi: Saapumisryhmä: Luento 4 XX00AA79-3013 TU12S2 Pasi Ranne 11.9.2013 11/9/13 Helsinki Metropolia University of Applied Sciences 1 Relaatiotietokannan suunnitteluprosessin
LisätiedotNormalisointi. Jouni Huotari & Ari Hovi. kirjan Hovi, Huotari, Lahdenmäki: Tietokantojen suunnittelu & indeksointi, Docendo (2003, 2005) luku 5
Informaatioteknologian instituutti IIO30100 Tietokantojen suunnittelu Normalisointi kirjan Hovi, Huotari, Lahdenmäki: Tietokantojen suunnittelu & indeksointi, Docendo (2003, 2005) luku 5 Jouni Huotari
LisätiedotTIEDONHALLINTA - SYKSY Luento 11. Hannu Markkanen /10/12 Helsinki Metropolia University of Applied Sciences
TIEDONHALLINTA - SYKSY 2011 Kurssikoodi: Saapumisryhmä: Luento 11 TU00AA48-2002 TU10S1E Hannu Markkanen 22.11.2011 9/10/12 Helsinki Metropolia University of Applied Sciences 1 Indeksit Indeksit Taulun
LisätiedotInsert lauseella on kaksi muotoa: insert into taulu [(sarakenimet)] values (arvot)
SQL sisältää operaatiot tietokannan sisällön muodostamiseen ja ylläpitoon: insert - uusien rivien vienti tauluun delete - rivien poisto update - rivien muutos 1 Insert lauseella on kaksi muotoa: insert
LisätiedotTIEDONHALLINTA - SYKSY Luento 10. Hannu Markkanen /10/12 Helsinki Metropolia University of Applied Sciences
TIEDONHALLINTA - SYKSY 2011 Kurssikoodi: Saapumisryhmä: Luento 10 TU00AA48-2002 TU10S1E Hannu Markkanen 14.-15.11.2011 9/10/12 Helsinki Metropolia University of Applied Sciences 1 SQL: Monen taulun kyselyt
LisätiedotTällä viikolla. Kotitehtävien tarkistus Upotettu SQL Indeksi-harjoitus täydennetään pelifirman tietokantamallia SQL-tehtäviä
Tällä viikolla Kotitehtävien tarkistus Upotettu SQL Indeksi-harjoitus täydennetään pelifirman tietokantamallia SQL-tehtäviä Seuraavissa harjoituksissa käytetään tukkukauppa-kantaa. 1. Hae kaikki toimittajat
LisätiedotKäsiteanalyysi prosessina ja tarveanalyysi
Informaatioteknologian instituutti IIO30100 Tietokantojen suunnittelu Käsiteanalyysi prosessina ja tarveanalyysi kirjan Hovi, Huotari, Lahdenmäki: Tietokantojen suunnittelu & indeksointi, Docendo (2003,
LisätiedotKÄSITEANALYYSI PROSESSINA JA TARVEANALYYSI
TIETOJEN MALLINNUS KÄSITEANALYYSI PROSESSINA JA TARVEANALYYSI HOVI, HUOTARI, LAHDENMÄKI: TIETOKANTOJEN SUUNNITTELU & INDEKSOINTI DOCENDO (2003, 2005) LUKU 3 S. 68 73 JA LUKU 4 (S. 79 84) JOUNI HUOTARI
Lisätiedot2. Käsiteanalyysi ja relaatiomalli
2. Käsiteanalyysi ja relaatiomalli lehtori Pasi Ranne Metropolia ammattikorkeakoulu E-mail: pasi.ranne@metropolia.fi sivu 1 Tietokannan suunnitteluprosessin osat sivu 2 Käsiteanalyysi ER-mallinnus, tietomallinnus
LisätiedotHELIA 1 (15) Outi Virkki Tiedonhallinta
HELIA 1 (15) Luento Suorituskyvyn optimointi... 2 Tiedonhallintajärjestelmän rakenne... 3 Suunnittele... 4 SQL-komentojen viritys... 5 Tekninen ympäristö... 6 Fyysisen tason ratkaisut... 7 Indeksit...
LisätiedotHAAGA-HELIA Heti-09 1 (12) ICT05 Tiedonhallinta ja Tietokannat O.Virkki Näkymät
HAAGA-HELIA Heti-09 1 (12) Näkymät Näkymät... 2 Eri tyyppisiä relaatioita... 2 Taulu - Tallennettu relaatio... 2 Tulosrelaatio - Kyselyn tulos... 2 Näkymä - Virtuaalirelaatio... 2 Näkymien määrittely...
LisätiedotPaksut indeksit ja summataulut
Paksut indeksit ja summataulut Ari Hovi, Ari Hovi Oy Esittelen ensin moniosaiset ja paksut indeksit ja summataulut käsitteinä. Artikkelin loppuosassa käyn läpi miten paksut indeksit ja summataulut auttavat
LisätiedotTiedonhallinnan perusteet. H11 Ovien ja kulun valvontajärjestelmän tietokanta
Tiedonhallinnan perusteet H11 Ovien ja kulun valvontajärjestelmän tietokanta Nimi: Mikko Haapanen Opiskelijanumero: 0900568 Ryhmä: T09L Työ tehty: 15.3.2010 Mikko Haapanen 15.3.2010 1(7) 1. Asiakasvaatimukset
Lisätiedotoheishakemistoja voi tiedostoon liittyä useita eri perustein muodostettuja
Tietokantojen hakemistorakenteet Hakemistorakenteiden (indeksien) tarkoituksena on nopeuttaa tietojen hakua tietokannasta. Hakemisto voi olla ylimääräinen oheishakemisto (secondary index), esimerkiksi
LisätiedotTällä viikolla. Kotitehtävien läpikäynti Aloitetaan Pelifirman tietovaraston suunnittelu Jatketaan SQL-harjoituksia
Tällä viikolla Kotitehtävien läpikäynti Aloitetaan Pelifirman tietovaraston suunnittelu Jatketaan SQL-harjoituksia 1.) Mainitse tietokonepelistä (kuvitteellisesta tai todellisesta) esimerkkitilanteita,
LisätiedotOpettajana Mika Sorsa, mika.sorsa@koudata.fi, HAMK:n ammatillisen opettajakoulutuksen opetusharjoittelija
Opettajana Mika Sorsa, mika.sorsa@koudata.fi, HAMK:n ammatillisen opettajakoulutuksen opetusharjoittelija Opintojaksolla: keskitytään relaatiotietokantojen teoriaan ja toimintaan SQL-kieli kyselykielenä
LisätiedotOpenOffice.org Base 3.1.0
OpenOffice.org Base 3.1.0 Sisällysluettelo 1 Tietokannan luominen...1 2 Taulukon eli taulun luominen...3 3 Kysely...9 4 Raportti...14 1 Tietokannan luominen Tietokanta on kokoelma tietoja, joilla on yhteys
LisätiedotKuva 7.2 vastaustaulu harjoitukseen 7.2
Harjoitus 7. Lataa tiedosto http://users.metropolia.fi/~pasitr/opas/ran13b/data/ran13b.zip levylle Z: ja pura se. Kun olet tehnyt kaikki seuraavat 17 tehtävää palauta Tuubiin harjoituksen 7 vastauksena
LisätiedotKirjasto Relaatiotietokannat Kevät 2001. Auvinen Annemari Niemi Anu Passoja Jonna Pulli Jari Tersa Tiina
Kirjasto Kevät 2001 Auvinen Annemari Niemi Anu Harjoitustyö 7.4.2001 Sisällysluettelo 1. Yleiskuvaus... 3 2. Vaatimukset... 3 2.1. Toiminnalliset... 3 2.1.1. Sisäänkirjautuminen... 3 2.1.2. Nimikkeiden
Lisätiedot2. Haet työntekijöiden tiedot etunimen mukaan nousevasti järjestettyinä. (ORDER BY) SELECT * FROM employees ORDER BY firstname ASC;
Tällä viikolla Kotitehtävien läpikäynti SQL-harjoituksia, osa 1 Jatketaan Pelifirman tietovaraston suunnittelua: tietotyyppien kertaus, taulun luonti ER-kaavioon, taulun luonti kaavion avulla tietokantaan,
LisätiedotKirjoita jokaiseen erilliseen vastauspaperiin kurssin nimi, tenttipäivä, oma nimesi (selkeästi), opiskelijanumerosi ja nimikirjoituksesi
Helsingin yliopisto, Tietojenkäsittelytieteen laitos Tietokantojen perusteet, kurssikoe 29.2.2012 (vastauksia) Liitteenä on tiivistelmä SQL-syntaksista Kirjoita jokaiseen erilliseen vastauspaperiin kurssin
LisätiedotRelaatiomalli ja -tietokanta
Relaatiomalli ja -tietokanta > Edgar. F. (Ted) Codd, IBM, 1969 < A Relational Model of Data for Large Shared Data Banks Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377-387. > 70-luvun lopulla
LisätiedotPOLKU LUOKKAKAAVIOISTA TAULUJEN TOTEUTUKSEEN
POLKU LUOKKAKAAVIOISTA TAULUJEN TOTEUTUKSEEN KIRJAN HOVI, HUOTARI, LAHDENMÄKI: TIETOKANTOJEN SUUNNITTELU & INDEKSOINTI DOCENDO (2003, 2005) LUKU 7 JOUNI HUOTARI & ARI HOVI IIO30100 TIETOKANTOJEN SUUNNITTELU
LisätiedotTietovarastojen suunnittelu
Informaatioteknologian instituutti IIO30100 Tietokantojen suunnittelu Tietovarastojen suunnittelu kirjan Hovi, Huotari, Lahdenmäki: Tietokantojen suunnittelu & indeksointi, Docendo (2003, 2005) luku 8
LisätiedotHELIA TIKO-05 1 (22) ICT03D Tieto ja tiedon varastointi E.Räty, O.Virkki 9.3.2010
HELIA TIKO-05 1 (22) SQL SQL... 2 Historiaa... 2 Standardit... 3 Käyttö... 4 Sql-komentojen kirjoittaminen... 5 DDL... 7 Tietokantaobjektien määrittely... 7 SQL:n tietotyypit... 8 Eheyssääntöjen määrittely...
LisätiedotTietokannat II -kurssin harjoitustyö
Tietokannat II -kurssin harjoitustyö Olli Opiskelija (123), olli.opiskelija@foo.fi Maija Mallioppilas (321), maija.mallioppilas@foo.fi 13.3. 2007 1 Sisältö 1 Tietokannan kuvaus 3 1.1 Tietokannan rakenne..................................
LisätiedotHelsingin yliopisto, Tietojenkäsittelytieteen laitos Tietokantojen perusteet, , H.Laine
Helsingin yliopisto, Tietojenkäsittelytieteen laitos Tietokantojen perusteet, 3.5.2007, H.Laine Kirjoita kuhunkin erilliseen vastauspaperiin kurssin nimi, oma nimesi, syntymäaikasi ja nimikirjoituksesi
LisätiedotTIETOVARASTOJEN SUUNNITTELU
IIO30120 DATABASE DESIGN / TIETOKANTOJEN SUUNNITTELU TIETOVARASTOJEN SUUNNITTELU KIRJAN HOVI, HUOTARI, LAHDENMÄKI: TIETOKANTOJEN SUUNNITTELU & INDEKSOINTI, DOCENDO (2003, 2005) LUKU 8 JOUNI HUOTARI & ARI
LisätiedotHELIA 1 (12) Outi Virkki Tiedonhallinta 4.11.2000
HELIA 1 (12) Luento 4.3 Eheyssäännöt (Integrity Constraints)... 2 Eheyden valvonta... 3 Yksilön eheyssääntö... 4 Viite-eheyssäännöt... 5 Arvojoukkoeheyssäännöt... 8 Null-arvoista... 10 Sovelluskohtaiset
LisätiedotJokaisella tiedostolla on otsake (header), joka sisältää tiedostoon liittyvää hallintatietoa
Tietojen tallennusrakenteet Jokaisella tiedostolla on otsake (header), joka sisältää tiedostoon liittyvää hallintatietoa tiedot tiedostoon kuuluvista lohkoista esim. taulukkona, joka voi muodostua ketjutetuista
LisätiedotTiedonhallinnan perusteet. Viikko 1 Jukka Lähetkangas
Tiedonhallinnan perusteet Viikko 1 Jukka Lähetkangas Kurssilla käytävät asiat Tietokantojen toimintafilosofian ja -tekniikan perusteet Tiedonsäilönnän vaihtoehdot Tietokantojen suunnitteleminen internetiä
LisätiedotHakukyselyt: SELECT * FROM taulu WHERE sarake1 = Malli Nimi [WHERE sarake1 LIKE M% ] [WHERE BETWEEN ehto1 AND ehto2] [WHERE sarake1 IN/= (alikysely)]
Tällä viikolla Kertaus SQL-asioista jatketaan SQL-tekstifuntio-harjoituksia tehdään pelifirman tietokannasta ER-malli MySQL:llä, tarkastellaan mallin toimivuutta ja korjataan, jos korjattavaa löytyy, tehdään
LisätiedotHELIA 1 (14) Outi Virkki Tiedonhallinta
HELIA 1 (14) Luento Näkymät... 2 Relaatiotyypit... 2 Taulu - Tallennettu relaatio... 3 Näkymä - Virtuaalirelaatio... 3 Tulosrelaatio - Kyselyn tulos... 3 Otetaulut - Tauluun tallennettu kyselyn tulos...
LisätiedotFyysinen suunnittelu
Informaatioteknologian instituutti IIO30100 Tietokantojen suunnittelu Fyysinen suunnittelu kirjan Hovi, Huotari, Lahdenmäki: Tietokantojen suunnittelu & indeksointi, Docendo (2003, 2005) luvusta 9 Jouni
LisätiedotJouni Huotari & Ari Hovi. Käsitemallinnuksesta relaatiokantaan KÄSITEMALLI. LOOGINEN MALLI: tietomalli valittu. FYYSINEN MALLI: DBMS valittu
Informaatioteknologian instituutti IIO30100 Tietokantojen suunnittelu Polku luokkakaavioista taulujen toteutukseen kirjan Hovi, Huotari, Lahdenmäki: Tietokantojen suunnittelu & indeksointi, Docendo (2003,
LisätiedotTietokantakurssit / TKTL
Tietokantakurssit / TKTL Tietokantojen perusteet - tietokannan käyttö: SQL, sovellukset Tietokannan hallinta - tietokannanhallintajärjestelmän ominaisuuksia: tallennusrakenteet kyselyjen toteutus tapahtumien
LisätiedotLiitokset - haut useaan tauluun
Liitokset Liitokset - haut useaan tauluun Tavallisin liitos on valintaliitos ehtona =,!=, yhtäläisyysliitos (=) yleisin (vrt. Inner join) taulut liitetään toisiinsa yleensä avaimilla (perus-
LisätiedotHELIA 1 (14) Outi Virkki Tiedonhallinta
HELIA 1 (14) Luento SQL... 2 Historiaa... 2 Standardit... 3 Käyttö... 4 DDL... 5 Tietokantaobjektien määrittely... 5 SQL:n tietotyypit... 6 Eheyssääntöjen määrittely... 9 Indeksin määrittely... 11 Syntaksikuvaukset...
LisätiedotHarjoitustehtävä 1. Harjoitustehtävä 2. Harjoitustehtävä 2. Harjoitustehtävä 2. Harjoitustehtävä 2. SQL kysely
Harjoitustehtävä 1 Puutarha Puutarhatunnus omistaja sijainti Vastuualue puutarhatunnus aluenumero maaperä, kosteus valaistus sijainti vastuutonttu Tonttu Tonttutunnus Istutus istutuspäivä paikka_alueella
LisätiedotTIEDONHALLINTA - SYKSY Luento 2. Pasi Ranne /8/17 Helsinki Metropolia University of Applied Sciences
TIEDONHALLINTA - SYKSY 2017 Kurssikoodi: Saapumisryhmä: Luento 2 TX00CN57-3001 TXQ16ICT, TXQ16S1 ja TXQ16PROS Pasi Ranne 28.8.2017 27/8/17 Helsinki Metropolia University of Applied Sciences 1 Oppitunnin
LisätiedotTIETOKANTOJEN SUUNNITTELU
TIETOKANTOJEN SUUNNITTELU - SUUNNITTELUPUTKI KÄSITEANALYYSISTÄ TOTEUTUKSEEN JOUNI HUOTARI & ARI HOVI 2000-2009 TIETOKANTOJEN PERUSTEISSA OSATTAVA Käsiteanalyysin ja käsitemallinnuksen perusidea: Käsitteiden
LisätiedotDenormalisointia turvallisesti. Ougf syysseminaari 4.11.2010 Pörssitalo Helsinki Timo Raitalaakso
Denormalisointia turvallisesti Ougf syysseminaari 4.11.2010 Pörssitalo Helsinki Timo Raitalaakso Timo Raitalaakso Senior Database Specialist Solita Oy 2001- - 2001 Tampereen Teknillinen korkeakoulu Tietokannat
LisätiedotSUBSTANTIIVIT 1/6. juttu. joukkue. vaali. kaupunki. syy. alku. kokous. asukas. tapaus. kysymys. lapsi. kauppa. pankki. miljoona. keskiviikko.
SUBSTANTIIVIT 1/6 juttu joukkue vaali kaupunki syy alku kokous asukas tapaus kysymys lapsi kauppa pankki miljoona keskiviikko käsi loppu pelaaja voitto pääministeri päivä tutkimus äiti kirja SUBSTANTIIVIT
LisätiedotSELECT-lauseen perusmuoto
SQL: Tiedonhaku SELECT-lauseen perusmuoto SELECT FROM WHERE ; määrittää ne sarakkeet, joiden halutaan näkyvän kyselyn vastauksessa sisältää
LisätiedotCSE-A1200 Tietokannat
CSE-A1200 Tietokannat 29.3.2016 CSE-A1200 Tietokannat 29.3.2016 1 / 40 Oppimistavoitteet: tämän luennon jälkeen Tiedät, miten tietokannan relaatioiden (taulujen) määrittelyt kirjoitetaan SQL:llä. Osaat
LisätiedotTIEDONHALLINTA - SYKSY Luento 7. Pasi Ranne /10/17 Helsinki Metropolia University of Applied Sciences
TIEDONHALLINTA - SYKSY 2017 Kurssikoodi: Saapumisryhmä: Luento 7 TX00CN57-3001 TXQ16ICT, TXQ16S1 ja TXQ16PROS Pasi Ranne 02.10.2017 1/10/17 Helsinki Metropolia University of Applied Sciences 1 Tietokannan
LisätiedotMUITA TIETOKANTAOBJEKTEJA NÄKYMÄT, SYNONYYMIT, INDEKSOINTI, VALTUUDET JA SYSTEEMIHAKEMISTO
MUITA TIETOKANTAOBJEKTEJA NÄKYMÄT, SYNONYYMIT, INDEKSOINTI, VALTUUDET JA SYSTEEMIHAKEMISTO NÄKYMÄT Näkymä (view) on looginen näyte tietokannan tauluista tai näkymistä Näkymä ei voi sisältää SELECT INTO,
LisätiedotTietokantojen suunnittelu, relaatiokantojen perusteita
Tietokantojen suunnittelu, relaatiokantojen perusteita A277, Tietokannat Teemu Saarelainen teemu.saarelainen@kyamk.fi Lähteet: Leon Atkinson: core MySQL Ari Hovi: SQL-opas TTY:n tietokantojen perusteet-kurssin
LisätiedotFYYSINEN SUUNNITTELU
IIO30100 TIETOKANTOJEN SUUNNITTELU JA IIO30200 TIETOKANNAN HALLINTA FYYSINEN SUUNNITTELU KIRJAN HOVI, HUOTARI, LAHDENMÄKI: TIETOKANTOJEN SUUNNITTELU & INDEKSOINTI, DOCENDO (2003, 2005), LUKU 9 JOUNI HUOTARI,
LisätiedotFROM-lausekkeessa voidaan määritellä useampi kuin yksi taulu, josta tietoja haetaan: Tuloksena on taululistassa lueteltujen taulujen rivien
Monen taulun kyselyt FROM-lausekkeessa voidaan määritellä useampi kuin yksi taulu, josta tietoja haetaan: SELECT FROM Tuloksena on taululistassa lueteltujen taulujen rivien karteesinen
LisätiedotArvo (value) Taulun sarakkeessa esiintyvä yksittäinen arvo, esim. luku 5.
Page 1 of 14 Tulostuspäivä: Liite 4 Termit Alikäsite (sub-entity, supertype) Pääkäsitteen sisällä oleva käsite, joka perii pääkäsitteen tiedot ja yhteydet. Alikäsitteellä voi lisäksi olla omia tietoja
LisätiedotHELIA TIKO-05 1 ( 12) ICT03D Tieto ja tiedon varastointi Martti Laiho 15.11.2005
HELIA TIKO-05 1 ( 12) Suorituskyky DBMS-järjestelmien keskeisiä laatuvaatimuksia ovat Tiedon luotettavuus (kattaen seuraavat: tietoturva, tiedon eheys, tiedon säilyvyys) Tiedon saatavuus (kattaen myös
LisätiedotFYYSINEN SUUNNITTELU
IIO30120 DATABASE DESIGN / TIETOKANTOJEN SUUNNITTELU JA IIO30220 DATABASE MANAGEMENT / TIETOKANNAN HALLINTA FYYSINEN SUUNNITTELU KIRJAN HOVI, HUOTARI, LAHDENMÄKI: TIETOKANTOJEN SUUNNITTELU & INDEKSOINTI,
LisätiedotOpintopiiritehtävä 3: Verkkohuutokauppa
Opintopiiritehtävä 3: Verkkohuutokauppa Jarmo Vestola, Tommi Voss, Perttu Määttä, Tia Määttänen, Satu Salekari, Henry Kari Helsingin yliopisto Tietojenkäsittelytieteen laitos Tietokantojen perusteet -kurssi
Lisätiedot1. a) Laadi suoraviivaisesti kyselyä vastaava optimoimaton kyselypuu.
Helsingin yliopisto, Tietojenkäsittelytieteen laitos Kyselykielet, s 2006, Harjoitus 5 (7.12.2006) Tietokannassa on tietoa tavaroista ja niiden toimittajista: Supplier(sid,sname,city,address,phone,etc);
LisätiedotTietokannat II -kurssin harjoitustyö
Tietokannat II -kurssin harjoitustyö Jyri Lehtonen (72039), jkoleh@utu.fi Azad Hajipour (72187), azhaji@utu.fi 10.6.2007 Sisältö 1. Tietokannan kuvaus... 1 1.1 Tietokannan rakenne... 1 1.2 Relaatiokaava
LisätiedotHarjoituksen aiheena on tietokantapalvelimen asentaminen ja testaaminen. Asennetaan MySQL-tietokanta. Hieman linkkejä:
Linux-harjoitus 6 Harjoituksen aiheena on tietokantapalvelimen asentaminen ja testaaminen. Asennetaan MySQL-tietokanta. Hieman linkkejä: http://www.mysql.com/, MySQL-tietokantaohjelman kotisivu. http://www.mysql.com/doc/en/index.html,
LisätiedotHAAGA-HELIA TIKO-05 1 (19) ICT23a Tietokannan suunnittelu ja toteutus O.Virkki 4.9.2008
HAAGA-HELIA TIKO-05 1 (19) Relaatiomalli Relaatiomalli... 2 Peruskäsitteet... 3 Relaatio... 5 Attribuutti ja arvojoukko... 6 Monikko... 7 Säännöt... 8 Yksilön eheyssääntö ja Pääavain... 9 Viite-eheyssääntö
Lisätiedotselect tulostietomäärittely from taulukkeet [where valintaehdot] [group by ryhmitystekijät] [having ryhmärajoitteet] [order by järjestysperusta]
SQL kysely Kyselyn yleisrakenne: select tulostietomäärittely from taulukkeet [where valintaehdot] [group by ryhmitystekijät] [having ryhmärajoitteet] [order by järjestysperusta] Kysely tuottaa nimettömän
Lisätiedot3. Käsiteanalyysi ja käsitekaavio
3. Käsiteanalyysi ja käsitekaavio lehtori Pasi Ranne Metropolia ammattikorkeakoulu E-mail: pasi.ranne@metropolia.fi sivu 1 Käsiteanalyysi Selvitetään mitä tietokantaan pitää tallentaa Lähtökohtana käyttäjien
Lisätiedot3. TAULUJEN MÄÄRITTELY JA MUUTTAMINEN
3. TAULUJEN MÄÄRITTELY JA MUUTTAMINEN DDL: TAULUJEN LUONTI, MUUTOS JA POISTO DML: TAULUJEN TIETOJEN YLLÄPITO TAPAHTUMIEN (TRANSAKTIOIDEN) HALLINTA NÄKYMÄT, SYNONYYMIT JA MUUT TIETOKANTAOBJEKTIT TAULUJEN
LisätiedotOhjelmistojen mallintamisen ja tietokantojen perusteiden yhteys
Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys Tällä kurssilla on tutustuttu ohjelmistojen mallintamiseen oliomenetelmiä ja UML:ää käyttäen Samaan aikaan järjestetyllä kurssilla on käsitelty
LisätiedotLuento 2: Tiedostot ja tiedon varastointi
HELIA 1 (19) Luento 2: Tiedostot ja tiedon varastointi Muistit... 2 Päämuisti (Primary storage)... 2 Apumuisti (Secondary storage)... 2 Tiedon tallennuksen yksiköitä... 3 Looginen taso... 3 Fyysinen taso...
LisätiedotHELIA 1 (11) Outi Virkki Tiedonhallinta 4.11.2000
HELIA 1 (11) Access 1 ACCESS...2 Yleistä...2 Access-tietokanta...3 Perusobjektit...3 Taulu...5 Kysely...7 Lomake...9 Raportti...10 Makro...11 Moduli...11 HELIA 2 (11) ACCESS Yleistä Relaatiotietokantatyyppinen
LisätiedotTietokantojen perusteet, syksy 1999 SQL- osa Harri Laine 1. SQL-valintaehto. SQL-valintaehto. Opettajien nimet: Opiskelijoiden pääaineet
DO NOT PRINT THIS DOCUMENT SQL -valintaehto CREATE TABLE opettaja ( opetunnus varchar(12) NOT NULL, nimi varchar(40) NOT NULL, puhelin varchar(12), tyohuone varchar(12), PRIMARY KEY (opetunnus) ) ; CREATE
LisätiedotHELIA 1 (17) Outi Virkki Tiedonhallinta
HELIA 1 (17) Luento 4.1 Looginen suunnittelu... 2 Relaatiomalli... 3 Peruskäsitteet... 4 Relaatio... 6 Relaatiokaava (Relation schema)... 6 Attribuutti ja arvojoukko... 7 Monikko... 8 Avaimet... 10 Avain
LisätiedotKirjoita kuhunkin erilliseen vastauspaperiin kurssin nimi, tentin päiväys, oma nimesi, syntymäaikasi ja nimikirjoituksesi.
Helsingin yliopisto, Tietojenkäsittelytieteen laitos Tietokantojen perusteet, kurssikoe 4.3.2015, H. Laine Tehtävien mukana jaetaan sql-syntaksin tiivistelmä. Kirjoita kuhunkin erilliseen vastauspaperiin
LisätiedotMuita tietokantaobjekteja. Näkymät, synonyymit, indeksointi, valtuudet ja systeemihakemisto
Muita tietokantaobjekteja Näkymät, synonyymit, indeksointi, valtuudet ja systeemihakemisto Näkymät Näkymä (view) on looginen näyte tietokannan tauluista tai näkymistä Näkymä ei voi sisältää SELECT INTO,
LisätiedotTIETOKANTOJEN PERUSTEET MARKKU SUNI
TIETOKANTOJEN PERUSTEET MARKKU SUNI OSIO 01 Peruskäsitteitä Kurssin tavoite: antaa osallistujille valmiudet ymmärtää tietokantojen periaatteet ymmärtää tietokantojen suunnittelunäkökohtia osallistua tietokantojen
Lisätiedot3. Taulujen määrittely ja muuttaminen
3. Taulujen määrittely ja muuttaminen DDL: Taulujen luonti, muutos ja poisto DML: taulujen tietojen ylläpito Tapahtumien (transaktioiden) hallinta Näkymät, synonyymit ja muut tietokantaobjektit Taulujen
LisätiedotMaastotietokannan torrent-jakelun shapefile-tiedostojen purkaminen zip-arkistoista Windows-komentojonoilla
Maastotietokannan torrent-jakelun shapefile-tiedostojen purkaminen zip-arkistoista Windows-komentojonoilla Viimeksi muokattu 5. toukokuuta 2012 Maastotietokannan torrent-jakeluun sisältyy yli 5000 zip-arkistoa,
LisätiedotTIETOKANTOJEN PERUSTEET OSIO 11 MARKKU SUNI
TIETOKANTOJEN PERUSTEET OSIO 11 MARKKU SUNI Tarkastellaan Tietokannan fyysistä suunnittelua Menetelmän vaihetta 4 Looginen suunoitelma muutetaan toimiviksi tauluiksi Id enimi snimi muuta 1 Aki Joki xxx
LisätiedotTietojärjestelmä tuotantoympäristössä. Sovellusohjelmat Helsingin ammattikorkeakoulu Stadia / Tekniikka ja liikenne Vesa Ollikainen
Tietojärjestelmä tuotantoympäristössä Tausta ja tavoitteet Tausta Kurssilla on opiskeltu suunnittelemaan ja toteuttamaan tietokanta, joka on pieni perustuu selkeisiin vaatimuksiin on (yleensä) yhden samanaikaisen
LisätiedotProseduurit, funktiot ja herättimet - esimerkkeinä Oracle, SQL Server, MySQL ja OCELOT. Jouni Huotari S2008
Proseduurit, funktiot ja herättimet - esimerkkeinä Oracle, SQL Server, MySQL ja OCELOT Jouni Huotari S2008 2 Proseduurit Ohjelmamoduuleita, jotka voidaan tallettaa tietokantaan (DBMS:n tietohakemistoon)
LisätiedotTIETOJENKÄSITTELY/TIETOKANTA Tehtävä C
1 Tietojenkäsittely Lajinumero 31 Kopioi levykkeeltä kansio Tietokanta C:-levylle. Käytä tätä kansiota työhakemistona. Tee myös E:-asemalle kansio Tietokanta, johon kopioit ratkaisusi. Älä tuhoa tiedostojasi
LisätiedotPROSEDUURIT, FUNKTIOT JA HERÄTTIMET - ESIMERKKEINÄ ORACLE, SQL SERVER, MYSQL JA OCELOT JOUNI HUOTARI K2009
PROSEDUURIT, FUNKTIOT JA HERÄTTIMET - ESIMERKKEINÄ ORACLE, SQL SERVER, MYSQL JA OCELOT JOUNI HUOTARI K2009 PROSEDUURIT Ohjelmamoduuleita, jotka voidaan tallettaa tietokantaan (DBMS:n tietohakemistoon)
LisätiedotTIETOKANTOJEN PERUSTEET MARKKU SUNI
TIETOKANTOJEN PERUSTEET MARKKU SUNI SQL - KIELI TIETOJEN MUOKKAUS MARKKU SUNI Tarkastellaan tauluissa olevien tietojen muokkausta muokkauskäskyjä: INSERT UPDATE DELETE Kysymys kuuluu: Voiko tietoja muokata
LisätiedotSQL:N PERUSTEET MARKKU SUNI
SQL:N PERUSTEET MARKKU SUNI Relaatiomallisen tietokannan käsittely Tietojen saanti, talletus ja päivitys tapahtuu SQL-kielellä Yhtä operaatiota sanotaan kyselyksi (query) Kyselyjä voidaan laittaa peräkkäin
LisätiedotTIETOKANNAN SUUNNITTELU
TIETOKANNAN SUUNNITTELU HOVI, HUOTARI, LAHDENMÄKI: TIETOKANTOJEN SUUNNITTELU & INDEKSOINTI DOCENDO (2003, 2005) LUKU 2 JOUNI HUOTARI & ARI HOVI TIETOJEN MALLINNUS TIETOJEN MALLINNUKSESTA TIETOKANTAAN Käsiteanalyysin
LisätiedotTIETOKANNAN NORMALISOINTI JA NORMAALIMUODOT
TIETOKANNAN NORMALISOINTI JA NORMAALIMUODOT A271117, Tietokannat Teemu Saarelainen teemu.saarelainen@kyamk.fi Lähteet: Leon Atkinson: core MySQL Ari Hovi: SQL-opas TTY:n tietokantojen perusteet-kurssin
Lisätiedot17 BUDJETOINTI. Asiakaskohtainen Budjetti. 17.1 Ylläpito-ohjelma. Dafo Versio 10 BUDJETOINTI. Käyttöohje. BudgCust. 17.1.1 Yleistä
17 Asiakaskohtainen Budjetti 17.1 Ylläpito-ohjelma 17.1.1 Yleistä BudgCust Ohjelmalla avataan järjestelmään asiakaskohtaisia budjetteja, jotka annetaan kuukausitasolla (oletus). 17.1.2 Parametrit Ohjelmaa
LisätiedotRelaatiotietokantojen perusteista. Harri Laine Helsingin yliopisto
Harri Laine Helsingin yliopisto Suosion syy? Yksinkertaisuus vähän käsitteitä helppo hahmottaa Selkeä matemaattinen perusta ei tulkintaongelmia kuten esim. UML:ssä teoria käytäntö kaavio: R(A 1 :D 1, A
Lisätiedot58131 Tietorakenteet (kevät 2009) Harjoitus 6, ratkaisuja (Antti Laaksonen)
58131 Tietorakenteet (kevät 2009) Harjoitus 6, ratkaisuja (Antti Laaksonen) 1. Avaimet 1, 2, 3 ja 4 mahtuvat samaan lehtisolmuun. Tässä tapauksessa puussa on vain yksi solmu, joka on samaan aikaan juurisolmu
LisätiedotTIEDONHALLINNAN PERUSTEET - SYKSY 2013
TIEDONHALLINNAN PERUSTEET - SYKSY 2013 Kurssikoodi: Saapumisryhmä: Luento 5 XX00AA79-3013 TU12S2 Pasi Ranne 11.9.2013 11/9/13 Helsinki Metropolia University of Applied Sciences 1 Tietokannan normalisoinnin
LisätiedotHelsingin yliopisto, TKTL Tietokantojen perusteet, k 2000 SQL- osa Harri Laine 1. SQL-valintaehto. SQL-valintaehto.
DO NOT PRINTTHIS DOCUMENT SQL -valintaehto SQL-valintaehto CREATE TABLE opettaja ( opetunnus varchar(12) NOT NULL, nimi varchar(40) NOT NULL, puhelin varchar(12), tyohuone varchar(12), PRIMARY KEY (opetunnus)
LisätiedotTIETOKANNAT JOHDANTO
TIETOKANNAT JOHDANTO JOUNI HUOTARI & ARI HOVI 2000-2011 Tieto TAUSTAA Yritykselle tiedot ovat tärkeä resurssi päätöksenteon tukena (JIT) varastointi ja käyttö vaativat investointeja vrt. energia (lähde,
LisätiedotVisual Case 2. Miika Kasnio (C9767) 23.4.2008
Visual Case 2 Miika Kasnio (C9767) 23.4.2008 Työn tarkasti: Jouni Huotari 24.4.2008 1 SISÄLTÖ 1. TYÖN LÄHTÖKOHDAT... 2 2. PERUSTIEDOT... 2 3. ASENTAMINEN... 2 4. OMINAISUUDET... 3 4.1. UML-kaaviot... 4
LisätiedotJoko tunnet nämän Oracle10g SQL:n piirteet? Kari Aalto Saariston IT
Joko tunnet nämän Oracle10g SQL:n piirteet? Kari Aalto Saariston IT Agenda Regular Expression - funktiot Case-insensitive Sort Case-insensitive Seach Merge muutokset Tree-walking in 10g DML Returning Values
LisätiedotTietorakenteet, laskuharjoitus 7, ratkaisuja
Tietorakenteet, laskuharjoitus, ratkaisuja. Seuraava kuvasarja näyttää B + -puun muutokset lisäysten jälkeen. Avaimet ja 5 mahtuvat lehtisolmuihin, joten niiden lisäys ei muuta puun rakennetta. Avain 9
LisätiedotD B. Kyselyjen käsittely ja optimointi. Kyselyn käsittelyn vaiheet:
Kyselyjen käsittely ja optimointi Kyselyn käsittelyn vaiheet: TKHJ ottaa vastaan kyselyn asiakasohjelmalta Kysely selataan ja jäsennetään tarkistetaan kyselyn rakenteellinen oikeellisuus Jäsennetty kysely
LisätiedotTietokantojen perusteet k2004helsingin yliopisto/tktl Tietokantojen perusteet, s 2005 SQL-perusteet. Harri Laine 1. SQL tietokantakieli
tietokantakieli :llä voidaan... määritellä ja muokata tietokantaa ja sen käyttöoikeuksia virittää tietokannan talletusrakenteita hakea tietoa tietokannasta näytölle tai tiedostoon sovellusohjelman käyttöön
LisätiedotLiitosesimerkki Tietokannan hallinta, kevät 2006, J.Li 1
Liitosesimerkki 16.02.06 Tietokannan hallinta, kevät 2006, J.Li 1 Esim R1 R2 yhteinen attribuutti C T(R1) = 10,000 riviä T(R2) = 5,000 riviä S(R1) = S(R2) = 1/10 lohkoa Puskuritilaa = 101 lohkoa 16.02.06
LisätiedotHELIA 1 (16) Outi Virkki Tietokantasuunnittelu
HELIA 1 (16) Luento 3.2 Suorituskyvyn optimointi jatkuu...... 2 Tietojen tallennusratkaisut... 2 Tiedon tallennuksen yksiköitä... 3 Loogiset... 3 Fyysiset... 3 Tallennusmäärittelyt Oraclessa... 5 Loogiset
LisätiedotAri Hovi & Jouni Huotari M3-1
Informaatioteknologian instituutti IIO30100 Tietokantojen suunnittelu Käsitemalli Reaalimaailma Käsiteanalyysi kirjan Hovi, Huotari, Lahdenmäki: Tietokantojen suunnittelu & indeksointi, Docendo (2003,
LisätiedotLohdutus - tietokantadokumentti
Lohdutus - tietokantadokumentti Ohjelmiston tietokanta on toteutettu Oracle-ympäristöön, ja sitä käytetään ohjelmassa Hibernaten kautta. Tietokannan rakenne Tietokannan taulujen merkitykset Taulu Project
LisätiedotHELIA 1 (19) Outi Virkki Tietokantasuunnittelu 9.3.2001
HELIA 1 (19) Luento 11 Eheyssäännöt (Integrity Constraints)... 2 Eheyden valvonta... 3 Yksilön eheyssääntö... 4 Arvojoukkoeheyssäännöt... 5 Null-arvoista... 6 Viite-eheyssäännöt... 7 Emorelaation päivitys...
LisätiedotTIETOKANTOJEN PERUSTEET OSIO 14 MARKKU SUNI
TIETOKANTOJEN PERUSTEET OSIO 14 MARKKU SUNI Tavoite: Suunnitella käyttäjien tarvitsemat turvallisuusmekanismit ja säännöt. Toisin sanoen: tehdä tietokannasta turvallinen ja luotettava. Muistutus: Tietokanta
Lisätiedot