“How to calculate initial size of SQL Server 2008 initial size?”
Initial size- ja auto growth- arvojen merkitys.

Collation:

finnish_swedish_CI_AS Collation, yhteensopiva 2000, 2005 ja 2008 version kanssa.
finnish_sedish_100_CI_AS yhteensopiva vain 2008 version kanssa.

Compability options: jos käytetään sovellusta joka on optimoitu 2000-version kanssa, niin silloin se kannattaa valita aktiiviseksi.

HETU = 6 merkkiä
SOTU = 5 merkkiä!, 1800-luvulla syntyneillä = “+”, 1900-luvulla syntyneillä = “-”, 2000-luvulla syntyneillä = “A”

“IDENTITY (1,1)”, aloitetaan ykkösellä ja lisätään aina ykkösellä

GUID = Global unit identifier

Teimme pienimuotoisia kokeiluja testikannan, ja rajoitetun käyttäjän muodossa.

Workbench: Identifying relationship = PFK

1NF, Poista:
- moniarvoiset tiedot (esim. puh nrot)
- toistuvat ryhmät (esim. puhNro1, puhNro2)

2NF, Jokaisen ei-avaintiedon sarakkeen pitää riippua koko avaimesta
(esim. OPPITUNTI(opiskelijaID, opiskelijaNimi, opeID, opeNimi, oppintuntiID)

3NF, ei sisäisiä riippuvuuksia

Joka kerta jos sääntöjä rikotaan, sille pitää olla hyvä peruste. Lisäksi pitää tiedostaa siitä syntyvät ongelmatapaukset!

Varsinaisena aiheena fyysinen suunnittelu.

Tässä vaiheessa vasta päätetään lopullisesti millä tuotteella tietokanta tullaan toteuttamaan. Lisäksi mietitään tarkemmalla tasolla tietotyypit mitä relaatioissa esiintyy.

Tietovarasto != tietokanta
Tietovarastolla tarkoitetaan denormalisoitua ratkaisua joka on hajautettu eli clusteroitu.

Kävimme läpi perustoimenpiteitä TOAD Data Modeler:sta. Käytännössä samoja toimenpiteitä joita aiemmin olemme tehneet MySQL Workbench:llä.

Perista viiteavaimille indeksi. Ei kuitenkaan UNIQUE. Tehostaa toimintaa huomattavasti.

Kävimme läpi SQL-Server 2008 R2 Express-versiota pintapuolisesti. Ensimmäiseksi katsoimme mistä näkee että tarvittavat palvelut ovat varmasti päällä, jonka jälkeen avasimme Management Studio:n (sa/sqladmin), ja sitä kautta “Server properties”.

Server collation =
CI = Case in-sensitive
AS = Accent sensitive
Arithmetic abort = kiertää matemaattisen virheen esim. 0:lla jakamisen -> palautus tuotekohtaista
Grant = annetaan oikeus
With Grant = oikeus antaa oikeuksia eteenpäin
Facets = Snipplet/template

SQL-Serverin data- ja loki-polut tulisi vaihtaa. Mieluiten ainakin eri levylle kuin käyttöjärjestelmä ja swap-ajo.

Prosessorin kuorma raskaissa systeemeissä kannattaa jakaa joka toinen prosessori-kuormalle, ja joka toinen I/O-kuormalle.

Useimmiten kantahitaus johtuu levykuormasta!

Saimme pikaisen esimerkin replikoinnista, ja mitä se käytännössä tarkoittaa.

Jos kahdella käsitteellä on 50% samannimisiä, tai samoja attribuutteja, tällöin tulisi miettiä niiden “yhdistämistä”.

UML-notaatiossa avoin “kolmio” tarkoittaa “heikkoa” riippuvuutta, kun taas musta kolmio = CASCADE UPDATE/DELETE!

Championzone esimerkit ja kaaviot. Esimerkkejä siitä kuinka samaa asiaa käsitellään erilaisilla kaavioilla eri näkökulmista.

Kävimme läpi hyviä, ja ei niin hyviä tapoja implementoida ORM-mallia käytännön tasolla. Aina tulisi pyrkiä siihen että lopullinen ratkaisu olisi mahdollisimman joustava, mikäli tietoihin lisätään jotain uutta, kuten esimerkiksi henkilötyyppi.

Hovi & kumppanit ovat tehneet suorituskykytestin joitakin vuosia taaksepäin eri strategioista, ja yhden taulun strategia on kaikista tehokkain suorituskyvyltään.

Loppuaijan käytimme harjoitustyömme kimpussa.

Ensimmäiseksi yleistä MySQL-toimivuudesta Labranetissä. Miten MySQL-kanta tulisi backupata? -> mysqldump

Jos yhdestä tietokannasta ottaa dumpin mysqldump:lla, ongelmaksi syntyy se että käyttäjät eivät ole tällöin backupin mukana.

Oletuksena MySQL-asennettaessa my.cnf (tai my.ini) on kaukana optimista. Asennuksen mukana tulee kuitenkin templateja mm. my-small.cnf, my-medium.cnf jne.

Uuden käyttäjän luominen ja oikeuksien antaminen:

CREATE USER ‘kayttaja’@'host’ IDENTIFIED BY ‘salasana’;
GRANT USAGE ON ‘kanta’ TO ‘kayttaja’@'host’ IDENTIFIED BY ‘salasana’;
FLUSH PRIVILEGES;

Kaikki oikeudet annetaan käskyllä:

GRANT ALL PRIVILEGES

MySQL-kannan dumppaus ja palautus onnistuu Workbench:in, tai phpMyAdminin kautta.

MySQL-kannan dumppaus komentoriviltä:

mysqldump -u root -p -A > dumppi.sql;

MySQL-kannan palautus komentoriviltä:

mysql -u root -p < dumppi.sql;

Lopuksi tutustumista PostgreSQL:ään….

Kävimme läpi kaikista eleganteimman ratkaisun, miten tämän tyyppinen tehtävä tulisi ratkaista.

Varsinainen aihe: normalisointi (ja denormalisointi).

Huono suunnittelu voi johtaa redudanttisuuteen, säännöttömyyteen ja lukuisiin poikkeuksiin.

- Älä yhdistä sarakkeiden tietoja yhteen, vaan tee oma sarake jokaiselle eri tiedolle
- Minimoi redudanttius taulujen riveillä
- Pyri välttämään null-arvoja riveillä

First normal form (1NF): Mikäli sarakkeen nimi on monikossa, on aistittavissa ongelmia. Esim. PhoneNumbers
Second normal form (2NF): Melko harvinainen tapaus, mikäli yhdessä taulussa on useita PK-avaimia
Third normal form (3NF): Sisäinen riippuvuus. Esim. (CourseID, CourseName, InstructorID, InstructorName (ID määrittää nimen))
Boyce-Codd normal form (BCNF): Käytännössä schema noudattaa 3NF:ää, ne noudattavat BCNF:ää

Historiaa MySQL:n takaa, sen perustajasta ja hänen muista “lapsistaan”.

Tietokantamoottoreiden läpi käymistä, joista aikaisemmin tunnistin nimeltä tasan kaksi: InnoDB ja MyISAM. Memory-tyyppiset tulevat todennäköisesti yleistymään tulevaisuudessa, ja ne ovat hyvin nopeatoimisia.

MySQL varmuuskopiota otettaessa täytyy muistaa varmistaa myös my.ini-tiedosto!

Kävimme kiinni MySQL-kantaan suoraan komentoriviltä, jota olen käyttäny jonkin verran aiemmin. Lähinnä käyttäjien ja tietokannan luomisessa, ja varmuuskopion ja palautuksen yhteydessä. “DESC TABLES;” oli kuitenkin mielenkiintoinen uusi tuttavuus :)

Oraclessa annetaan oikeuksia käskyillä RESOURCE ja CONNECT, kun MySQL:ssä se tapahtuu USAGE-komennolla. Huomioitavaa on myös, että DOS:in komentoikkuna saattaa näyttää ääkköset väärin, vaikka tietokanta käsittelisi ne täysin oikein.

Sarakkeiden ei tulisi käyttää välilyöntejä, koska jos kanta konvertoidaan toiseen, se saattaa aiheuttaa ongelmia, esim. “Customer name” => “Customer_name”.

Kävimme läpi tarkemmin taulujen ja käsitteiden välisiä yhteyksiä, yksi-yhteen, yksi-moneen, moni-moneen jne.. Yksi hyvä tapa nimetä lapsi-taulu on tehdä siitä assosiatiivinen käsite. Kuten esim. “Projekti” ja “Henkilo”, ja niiden välinen lapsitaulu joka voitaisiin nimetä “Osallistuminen”.

Mitä kaikkea tulisi ottaa huomioon suunniteltaessa tiedontallennus tarvetta, ja mitä kysymyksiä pitää osata kysyä sekä asiakkaalta, sekä itseltään suunniteltaessa tietokantaa ja siihen tallennettavia tietoja.

Jatkoimme myös Demox OY:n esimerkkiä pidemmälle.

Käsiteanalyysi prosessina. Käsitteitä etsitään kysymällä miksi, mitä, miten… Käsitteiden määrittely ja niiden yhdistäminen, sekä tietojen lisäys. Tietotarveanalyysiä pidetään viimeistelynä, jonka jälkeen tulisi tehdä prototyyppi joka esitellään asiakkaalle ja kerätään sitä kautta palautetta. Samalla pyritään sitouttamaan käyttäjät tekemäämme ratkaisuun.

Tarkistuslista käsiteanalyysin tekijälle:
• käsitteiden nimen tarkistus
• käsitteiden abstraktiotason valinta
• yhteyksien tarkistus
• käsitemallin ulkoasu
• käsitemallin jakaminen ymmärrettäviin kokonaisuuksiin
• vaihtoehtoisten ratkaisujen etsiminen
• tulevaisuuden huomioonottaminen

Aluksi kävimme läpi hieman historiaa ja taustoja Oraclesta historian varrelta.

Oracle-tietokannan rakenne ja sen yksittäisiä osa-alueita.
- Yksi Oraclen tietokanta/instanssi koostuu yhdestä tai useammasta taulualueesta.
- Tietokantatiedostot voidaan hajauttaa tarvittaessa ympäri maailman.
- Tietolohko on käyttöjärjestelmän varausyksikön kerrannainen

Oracle Database XE, sql+, virtuaalikone.

Jokainen haku tallennetaan muistiin, mikäli se ei siellä jo ole. Mikäli haku on jo muistissa, se palautetaan sieltä kyselyn tekijälle.

Tietokannan hallintapuoli pelkästään teorian pohjalta ei kovin hyvin vielä auennut, mutta toivottavasti meillä on mahdollisuus tutustua johonkin DBMS-työkaluun tarkemmin käytännön tasolla.