Andmebaasid II (IDU0230) (sügis 2016)

1. Loodud rakendus peab kasutama apex.ttu.ee serveris olevat andmebaasi.
2. Serverirakenduse korral peab teil peab olema keskkond, kus seda käitada.
   • apex.ttu.ee serveris on PHP (5.5.3), pgApex, Oracle APEX (4.2).
   • Väljaspool ülikooli võrku oleva rakenduse korral peate apex.ttu.ee serveriga looma SSH ühenduse.
3. Rakendust peab olema võimalik õppejõule demonstreerida. Üldiselt ei ole vaja tulla projekti, sh rakendust isiklikult ette näitama. Sellele tingimusele on järgmised erandid, mille korral on vaja tulla rakendust eksamisessiooni ajal vastuvõtuajal ette näitama. Projekti tulemuse saab teada alles peale seda kohtumist. Vastuvõtule tulek on vaja eelnevalt e-meili teel registreerida.
   • Kui rakenduse kasutamine eeldab kasutaja arvutisse lisaks PostgreSQL ODBC draiverile või MS Accessile täiendava tarkvara installeerimist.
   • Kui serverirakenduse poolt andmebaasisüsteemiga ühenduse loomine ei õnnestu (nt tasuta keskkonnad ei võimalda luua SSH ühendust) ja rakendus töötab vaid üliõpilase enda arvutis.
4. Sõltumata sellest, kas Teil on vaja tulla rakendust ette näitama või mitte, loetakse projekt esitatuks alles siis, kui kõik projekti osad, sh rakenduse lähtekood on Maurusesse laaditud.
   • Oracle APEXi korral on vaja esitada rakenduse eksportimisel loodud fail.
   • pgApexi korral on vaja esitada apex.ttu.ee serverist andmebaasi pgapex eksportimisel saadud fail (plain formaadis, SQL laused; loomiseks saate kasutada pgAdmin programmi Backup funktsiooni).
   • MS Accessi korral on vaja esitada *.mdb või *.accdb laiendiga fail, mitte *.mde või *.accde laiendiga fail.
   • Kui teete rakenduse mõnes programmeerimiskeeles, siis tuleb saata nii lähtekood, käivitatavad failid kui ka käivitamise juhend (veebirakenduse korral viimase asemel link).

• Oracle SQL Developer
• PostgreSQL ODBC draiver
• Looge ODBC andmeühenduse spetsifikatsioon nimega PostgreSQL_yhendus

VÕI

logige harjutustunnis arvutiklassi arvutisse, sest seal on see tarkvara olemas.

Viited tarkvarale ja ODBC andmeühenduse spetsifikatsiooni loomise juhend on õppeaine kodulehel teates "Tarkvara" (kuupäevaga 05.09.2016)

Testil osalemiseks on kohustuslik registreerida. Registreerimine toimub Mauruse kaudu: Üldist => Teadmiste kontroll (nagu kevadel SQL kontrolltööle). Testil osalemiseks peab olema kaasas isikut tõendav dokument (nagu kevadel SQL kontrolltööl ja eksamil; raamatukogu- krediit- jms kaardid ei sobi ja nendega testi teha ei saa; autojuhiluba sobib).

Test toimub elektrooniliselt, Mauruse testikeskkonnas. Kasutada võib arvutiklassi arvutit või oma arvutit (erinevalt eksamist, mis toimub ainult arvutiklassi arvutites). Küsimustele vastamiseks materjale kasutada ei või. Testis on viis juhuslikult valitud küsimust, vastamiseks on aega 10 minutit. Küsimused on valikvastustega ning ainult üks vastuse variant on õige. Tulemuse saate teada kohe, kuid vastuste õigsust saab vaadata üheksanda nädala harjutustundides. Nädala jooksul saab testi teha maksimaalselt ühe korra. Kui Te ei soovi testi teha, siis võiksite tundi tulla 15 minutit peale algust.

• Shared Nothing Partitioning kasutuselevõtt Pinteresti näitel.
• Suurettevõtte andmebaasi ühest andmebaasisüsteemist (Oracle => PostgreSQL) teise migreerimine Yandex Mail näitel (saab vaadata videot).

Vihje

Kui tegite kevadise projekti MS Accessis ja kasutasite SQL lausete käivitamiseks minu poolt pakutud abiprogrammiga faili, siis seal saate ekraanivormil SQL_skripti_käivitamine vajutada nupule, mis ekspordib MS Accessi andmebaasist CREATE TABLE, DROP TABLE ja INSERT laused (Nupp SQL lausete eksport teatele lisatud pildil). Võibolla on genereeritud INSERT lausetest kasu. Nendes INSERT lausetes puuduvad veergude nimed (tuleb ise juurde kirjutada). Kui peale faili avamist on sisu "välja lülitatud", siis tuleb eksportimise võimaldamiseks valida Enable Content.

• Kui ma projekte vaatan ning küsimustele vastan, siis astuge harjutustunnis julgelt ligi kuulama. Projektide teemad, lahendamist vajavad probleemid ning vastamist ootavad küsimused on sageli ühesugused.
• Reedeti kell 12:00 käib ICT-637 umbes 10 inimest harjutustunnis ning reedeti kell 14:00 käib ICT-404 vaid paar inimest harjutustunnis. Seal jätkub aega kõigile.

Samuti on raamatukogus hetkel saadaval üks eksemplar raamatust SQL antipatterns : avoiding the pitfalls of database programming. Ütleksin, et see on lausa kohustuslik kirjandus kõigile SQL-andmebaaside disainiga tõsisemalt tegeleda soovijatele.

CREATE FUNCTION textcat_coalesce(text, text) RETURNS text AS $$
SELECT coalesce($1,'') || coalesce($2,'');
$$ LANGUAGE sql IMMUTABLE LEAKPROOF;

COMMENT ON FUNCTION textcat_coalesce(text, text) IS
'Stringide konkatenatsiooni operaatorit & realiseeriv funktsioon. Tagab, et operatsiooni tulemus pole NULL.';

CREATE OPERATOR & (
LEFTARG = text,
RIGHTARG = text,
PROCEDURE = textcat_coalesce
);

SELECT NULL || 'katsetus' AS tulemus;
Tulemus: NULL

SELECT NULL & 'katsetus' AS tulemus;
Tulemus: katsetus

Palun lugege sellest raamatust esimese peatüki osi My Approach ja The Black Box Approach.

Jah, seal kiidetakse muuhulgas Oraclet. Võtke seda kergelt, sest ka mitmed teised andmebaasisüsteemid (sh PostgreSQL) on sama võimekad. Kuid seal kirjeldatav üldine andmebaasirakenduste loomise mõtteviis on selline, mida pean mõistlikuks ja millest lähtun ka käesolevas kursuses.

Siit aga leiab info, kuidas pääseda raamatule ligi ka väljaspoolt TTÜ võrku.

Põhimõte on, et hea andmebaasirakenduse loomiseks tuleks tunda ja kasutada andmebaasisüsteemide pakutavaid võimalusi. Lisan siia lõppu tsitaadi raamatust, mida ma tõlkima ei hakka. Viidatud osades tuuakse mõned ilmekad näited selle kohta, kuidas rakenduse arendajate poolne andmebaasi/andmebaasisüsteemi musta kastina vaatamine viis halbade tulemusteni.

My point about the power of database features is not a criticism of tools or technologies like Hibernate, EJBs, and container-managed persistence. It is a criticism of purposely remaining ignorant of the database and how it works and how to use it. The technologies used in this case worked well—after the developers got some insight into the database itself.

The bottom line is that the database is typically the cornerstone of your application. If it does not work well, nothing else really matters. If you have a black box and it does not work, what are you going to do about it? About the only thing you can do is look at it and wonder why it is not working very well. You can’t fix it, you can’t tune it. Quite simply, you do not understand how it works—and you made the decision to be in this position. The alternative is the approach that I advocate: understand your database, know how it works, know what it can do for you, and use it to its fullest potential.

Arvan, et käesolevaks ajaks on NoSQL jõudnud haibitsüklis ülisuurte ootuste tipust üle, pettumuste lohust läbi, võibolla isegi juba taasavastamise tõusule.

Üha rohkem ilmub seisukohti ja tähelepanekuid, mis osundavad lähenemise või süsteemide üldistele puudujääkidele (näide1, näide2) ja konkreetsete süsteemide probleemidele (näide3, näide4, näide5). Muidugi saab öelda, et ühes või teises NoSQL süsteemis selliseid probleeme ei ole, kuid küsimus on, kuidas see toode kümnete teiste seast üles leida ja kas on kindel, et selle teinud idufirma pole viie aasta pärast hingusele läinud. NoSQL süsteemid peavad oma arengus jõudma produktiivsuse platoole ja tõsised tegijad välja settima.

Näen tõsist probleemi selles, et NoSQL süsteeme üritatakse kasutada ka seal, kus see pole kindlasti mõistlik. Teha raamatupidamise tarkvara NoSQL süsteemi põhjal on sama lahe kui kratsida kukalt pannes käe jalge vahelt läbi. Alguses paistab huvitav ja ekstravagantne, sellest tehtud piltidega saab sotsiaalmeedias praalida - pärast on kael ja keha kanged ning selg paigast ära. Mulle meeldis ühes arutelus võrdlus andmete ja koduse tööriistakuuri vahel. Oletame, et Teil on kuuris palju tööriistu. Üks võimalus on võtta erinevat tüüpi tööriistade jaoks kasutusele erinevad kastid. Kahtlemata võtab kastide valimine, neile siltide kleepimine ning tööriista ära panemisel õige kasti otsimine aega. Andmebaaside maailmas vastab sellele skeemi defineerimine SQL/relatsioonilises andmebaasis. Selle tulemusena on vajaliku tööriista leidmine kiire. Kas tõesti oleks lahendus, kus kuuris on hulk kaste ja tööriist pannakse esimesse vabasse kasti, kokkuvõttes kiirem ja parem? Andmebaaside maailmas vastaks sellele skeemitu NoSQL andmebaasi kasutamine.

Näen NoSQL süsteemide peamist kasutusvaldkonda suurandmete (big data) hoiustamisel - andmeid on hästi palju, neid tuleb nagu kosest juurde ja andmete struktuur ei ole ühe vitsaga löödud, vaid küllaltki muutlik. Kena oleks need kuskile kiiresti ja odavalt ära panna, lootuses, et ehk on hiljem aega, tahtmist ja raha, et neid lähemalt uurida. Tööriistade näitel oleks see umbes midagi sellist. Asjade hunnikusse paigutajal oli oma süsteem ja ta leiab vajaliku kiiresti üles. Teistel see nii kiiresti ei lähe. Teisalt, nagu tõestavad seriaalid nagu American Pickers, võib sellisest hunnikust igasugu väärt kraami leida. Samamoodi ei tasu ka andmeid lihtsalt ära visata. Graafipõhistel andmebaasisüsteemidel on kindlasti oma kindel koht igat sorti võrgustike (kes on kelle sõber, kust kuhu tee viib või kaabel jookseb jne) andmete käepäraseks muutmisel. Arvan, et mõistlikuks arengusuunaks on SQL ja NoSQL kokkusulamine, mille näiteks on PostgreSQLis JSON tüüpi andmetega töötamise võimalus. See võimaldab lahendusi, kus ühes geograafilises punktis oleva andmebaasi piires on teatud osa andmetest esitatud rohkem struktureeritult (eraldi veergudes) ja muutlikum osa andmeid on surutud kokku JSON andmeväärtustesse (vt kolmandat disaini selles näites). Kõiki neid andmeid kantseldab ACID omadusi toetav transaktsioonide juhtimise moodul.

NoSQL and Technical Debt on ajaveebi postitus, mis selgitab, miks NoSQL süsteemide ilmumine pole muutnud väärtusetuks SQLi ning andmebaaside projekteerimise õppimist. Nende oskuste puudumine on arendajatel võlg, mis tuleb hiljem intressidega tagasi maksta. NoSQL oma "skeemitute" andmetega loob tegelikult tehnilist võlga.

Vahend käivitab andmebaasi süsteemikataloogi põhjal päringuid. Osa päringuid suudavad leida vigu. Osa aga otsivad andmebaasi disainist halva lõhnaga kohti (vt halvasti lõhnav disain ja halvasti lõhnav kood). Halvasti lõhnavad kohad ei takista andmebaasi ja seda kasutavate süsteemide toimimist, kuid muudavad andmebaasi kasutamise, haldamise või arendamise mingis aspektis raskemaks kui see võiks olla. Halvasti lõhnavad kohad on sügavamate probleemide sümptomid. Nende probleemide lahendamine aitab koodi puhastada. Halb lõhn on tehnilise võla tunnus. Tehniline võlg tähendab, et "asi" töötab, kuid saaks olla sisemiselt tehtud paremini. Kuna praegu on seal midagi "üle jala" lastud, siis see on probleem tulevikus, kui "asja" on vaja edasi arendada. Kliendile kiiresti töötava asja üleandmiseks on võetud võlga tuleviku arenduste arvelt. Tehnilist võlga aitab vähendada refaktoreerimine.

Kui teete oma projekti PostgreSQLis, siis minge aadressile. Logige sisse kasutades apexi kasutajanime ja parooli. Valige kontrollitav andmebaas. Ilmselt on see samasuguse nimega nagu ühe projekti tegija kasutajanimi ja sisaldab tema matriklinumbrit. Valige "Käivita saadaolevaid teste". Valige test "Databases II (fall 2016)". Vaadake päringu tulemusi, milles on üks või rohkem rida. Lugege kirjeldust, vaadake tulemusi. Usaldusväärsus on hinnang sellele, kuidas päring oma eesmärke täidab.

• Alajaotuses "General" on päringud, mis otsivad andmebaasist spetsiifilist infot, kuid otsuse selle kohta, kas midagi on õigesti või valesti peab tegema inimkasutaja, kes tulemust vaatab.
• Alajaotuses "Flaw detection" on päringud, mille tulemuses olev iga riga osundab mingile võimalikule disaini veale. Sõltuvalt päringu usaldusväärsuse hinangust peaks inimkasutaja selle üle kontrollima.
• Alajaotuses "Software measure" on päringud, mis arvutavad andmebaasi skeemi põhjal mingi arvulise väärtuse.

Soovi korral võite kasutada ka kasutajaliidese vana versiooni, kus kõik tulemused on ühel lehel. Mina kasutan tundides Teiega koos andmebaase vaadates seda. Päringud on samad, kasutajaliides erinev.

Kui teete oma projekti Oracles, siis minge aadressile. Päringud, mida saate sealt kaudu käivitada leiate andmebaasi disaini kontrollimiseks mõeldud SQL laused kataloogist Iseseisva töö projekti tegemine. 990999 tuleb asendada matrikli numbriga, mida kasutate projekti tulemusena loodud andmebaasiobjektide nimedes.

Võite neid päringuid regulaarselt ise käivitada ja interpreteerida üritada. Küsimuste korral pöörduge õppejõu poole. Oleks väga hea, kui mõnes semestri lõpu harjutustunnis, kui projekt juba valmis saama hakkab, jõuaksite koos õppejõuga need päringu tulemused üle vaadata.

Oracle andmebaasiga töötamiseks soovitan kasutada Oracle poolt pakutavat programmi Oracle SQL Developer (ülikooli serveriga ühenduse loomisel SID= orcl). Tarkvara on tasuta, kuid selle allalaadimiseks tuleb ennast registreerida.

apex.ttu.ee serveriga SSH ühenduse loomiseks võib kasutada programmi PuTTY või Bitvise SSH Client. Samuti võib mitte-kommerts otstarbel kasutada SSH Secure Shell klienti versiooni 3.2, kuid see on juba üsna vana ja ebaturvaline. Selles lõigus nimetatud programmidest piisab ühest!

apex.ttu.ee serverisse failide ülekandmiseks ja sealt failide allalaadimiseks võib kasutada programmi WinSCP. Tegelikult sisaldavad ka Bitvise ja SSH Secure Shell programmid sellist funktsionaalsust ja siis poleks WinSCPd vajagi.

Lähtekoodiga (sh SQL lausetega) töötamiseks sobib hästi tekstiredaktor SciTe või Notepad++.

Valikuline

PostgreSQL andmebaasisüsteemi kasutava kahekihilise klient-server süsteemi loomiseks läheb vaja PostgreSQL ODBC draivereid. Valige kõige hilisem versioon. Milline draiver valida ja kuidas andmeühendust seadistada lugege palun teatele lisatud failist.

PHP rakenduste genereerimiseks võib kasutada SQL Maestro koodigeneraatorit PostgreSQL jaoks või SQL Maestro koodigeneraatorit Oracle jaoks.

Kui PostgreSQLiga suhtlemiseks pakutud vahenditest väheks jääb, siis siit leiab veel alternatiive.