Andmebaas

Andmebaas on korrastatud infokogum. Digitaalne andmebaas on kogum mingi ühise tunnuse järgi ühendatud andmefaile, samuti võib andmebaasiks olla ka ainult üks fail. Näiteks telefoniraamat on andmebaas, mis sisaldab telefoninumbreid, asutuste nimetusi ja aadresse; sõnastik aga on andmebaas, mis sisaldab sõnu ja nende tähendusi jne. Andmebaasi võib lihtsustatud kujul vaadelda tabelina, mis koosneb ridadest ja veergudest. Tabeli rida nimetatakse andmebaaside terminoloogia kohaselt kirjeks, iga tabeli lahtrit andmeväljaks. Kirje on mugav viis korraldada kindla struktuuriga infot ühetüübiliste objektide (näiteks inimeste) kohta. Andmeväli on kirje element ja samuti väikseim andmekogus. Veergude pealkirjad on seega väljade nimed. Igal andmefailil on struktuur, mis sisaldab informatsiooni selles failis sisalduvatest andmetest, täpsemini nende tüüpidest. Andmefaili struktuur ja andmefailikirje struktuur on / ei ole samaväärsed mõisted, kuna andmefaili struktuur määrab ära tema sisse salvestatavate kirjete struktuuri ja failistruktuur sisaldab lisaks ka kirjetevaheliste seoste infot. Tabelite sisemised seosed on näiteks indeksid ja tabelitevahelised seosed on näiteks relatsioonid. Üldine arusaam on, et lõppkasutajale müüdav toode (andmebaasirakendus, programm jne) peaks toetama rohkem kui ühte andmebaasisüsteemi. Andmebaase on mitut tüüpi, levinumad on lame- ja relatsioonandmebaasid, kuid kasutatakse ka muud tüüpi andmebaase, näiteks puustruktuuriga ehk hierarhilisi ning üha enam objektorienteeritud andmebaase. Lameandmebaasiks nimetatakse andmebaasi, mis koosneb ainult ühest tabelist. Ühe tabeliga saab hakkama, kui soovite selles hoida näiteks klientide, ärikontaktide, töötajate, kaupade vms andmeid. Kui tahate oma töötajate isikuandmetega aga siduda ka palgaandmeid või klientide andmetega neile väljastatud arvete andmed, siis läheb juba vaja keerukamat seotud tabelitega töötavat relatsioonandmebaasi. Hierarhilisel mudelil põhinevas andmebaasis leiavad kajastamist omaniku ja alluva suhted. Kehtivad üks mitmele seosed. Seda liiki andmebaasis ei tohi ega tehniliselt võttes saagi ükski alluvat liiki kirje mitme omaniku vahel jagatud olla. Samal ajal ei saa ükski alumise taseme kirje olla ülemise taseme kirje omanikuks. Nt kataloogide-failide puu arvutites. Võrkmudel sarnaneb ülesehituselt hierarhilise mudeliga. Mõnevõrra on avardunud kirje omaniku ja alluvate kirjete mõisted ning võimalused. Ühel ja samal alluval kirjel võib võrkstruktuurilises andmebaasis olla mitu omanikku ja mitu alluvat. Lisaks võib võrkmudeli korral omaniku ja alluva suhted kui sellised puududa täiesti ja olla asendatud naabrussuhetega. Need omadused tingivad kirjete lisamise või baasist eemaldamise korral tunduvalt töömahukamaid tegevusi ja ümberkorraldusi kui näiteks puustruktuuriga andmebaasis. Relatsioonimudeli puhul on objektid andmebaasis ja nendevahelised seosed esitatud tabelite kujul. Need võivad koosneda enamast kui ühest tabelist, mis on omavahel seotud. Seostamine tähendab andmefailide ühendamist ühesuguse sisuga väljade järgi. Relatsioonandmebaas koosneb nimega tabelitest, kus on nimega veerge üks või enam, ning suvaline arv ridu. Ühes andmebaasis võib olla mitmeid tabeleid. Iga selline tabel kujutab endast üht relatsiooni. Lisatingimuseks on, et üheski relatsioonis ei või olla kahte ühesugust rida. Iga tabeli kohta võime seega määrata ühe või mitu veergu, mille väärtuste kaudu on read identifitseeritavad. Taolist veergude kogumit nimetatakse primaarvõtmeks. Primaarvõtmete või lihtsalt võtmete järgi võime ühendada eri tabelite andmeid. Näiteks tabel "Töötajad" võib sisaldada veergu "Asukoht", sisaldades väärtust, mis sobib tabeli "Asukoht" võtmega. Kuna tabelid on üksteisest sõltumatud, muudab see relatsioonimudelil põhinevad andmed baasis ettenägematute muutuste ja vajaduste suhtes paindlikeks. Oma paindlikkuse tõttu on relatsioonimudelid muid alammudeleid suhteliselt kiiresti välja tõrjumas. Primaarvõti ehk esmasvõti (inglise primary key) on kandidaatvõti, mis on valitud relatsiooni kirjeid unikaalselt identifitseerima. Primaarvõti on võti, mis üheselt identifitseerib ühe kirje. Valiku kriteeriumid: atribuudi domeen (peaks olema võimalikult lühike väärtus); atribuutide arv (peaks olema võimalikult vähe atribuute); tulevane unikaalsuse tõenäosus (peaks sisaldama unikaalseid väärtusi nii praegu kui ka tulevikus). Kandidaatvõti (ka võtmekandidaat) (inglise candidate key) on supervõti, mille alamhulk ei ole korrektne supervõti. See tähendab, et kandidaatvõtmest ei saa enam ühtegi atribuuti eemaldada, ilma et ta kaotaks unikaalsuse. Relatsioonil võib olla mitu kandidaatvõtit. Kandidaatvõtme omadused on: unikaalsus – iga kandidaatvõtme väärtus identifitseerib üheselt ühe relatsiooni kirje. täielikkus – kandidaatvõtmest ei saa eemaldada atribuute, ilma et ta kaotaks unikaalsuse omaduse. Alternatiivseteks võtmeteks (inglise alternate key) nimetatakse primaarvõtmeks mitte valitud kandidaatvõtmeid. Lihtvõti – kui võti sisaldab ühte atribuuti, siis nimetatakse seda lihtvõtmeks (inglise simple key). Liitvõti – kui võti sisaldab mitu atribuuti, siis nimetatakse seda liitvõtmeks (inglise composite key). Supervõti (inglise superkey) on atribuut või atribuutide kombinatsioon, mis identifitseerib unikaalselt relatsioonis olevaid kirjeid. Supervõti võib sisaldada atribuute, mida pole unikaalsuse tagamiseks vajalikud, st. et temast võib atribuute eemaldada ja ta tagab ikkagi unikaalsuse. Intelligentne võti ehk sisulise tähendusega (informatiivne) võti (inglise intelligent key). Sisulise tähendusega võti on küll unikaalne, kuid selle väärtus omab kasutaja jaoks tähendust, näiteks: isikukood; õppeaine kood ülikoolis; üliõpilaskood; auto registrinumber; raamatu ISBN kood. Naturaalne võti (inglise natural key) on sisulise tähendusega võtme eriliik. Selle võtme väärtus on identifitseeritava objektiga üks-üheselt seotud. Näiteks isiku DNA või sõrmejäljed. Kattuvateks võtmeteks (inglise overlapping keys) nimetatakse liitvõtmeid, millel vähemalt üks atribuut langeb kokku). Välisvõti (inglise foreign key) – seose loomiseks kahe relatsiooni vahele "tõmmatakse" ühe relatsiooni ühe (või ka mitme) atribuudi andmed teise relatsiooni salvestamiseks. Ühelt poolt peab suhte loomisel osalema unikaalne võti (mõni kandidaatvõtetest). Enamasti on selleks unikaalseks võtmeks primaarvõti. Selle tulemusel on kahes erinevas relatsiooni ühesuguse sisuga atribuudid, mis loovad suhte nende relatsioonide vahel. Seotud relatsiooni tekkinud atribuuti (atribuute) nimetatakse välisvõtmeks. Relatsioonis võib olla üks või mitu välisvõtit. Relatsioonis võib välisvõti ka puududa. Objektiandmebaas võimaldab säilitada objektorienteeritud programmis loodud objekte. Andmed salvestatakse objektidena ja neid saab interpreteerida ainult vastava klassi meetodit kasutades. Sarnaste objektide vahelised suhted säilitatakse, samuti objektide vahelised viited. Päringud võivad olla kiiremad, sest sageli puudub vajadus relatsioonide liitmise järgi nagu relatsioonilises andmebaasis. Objekte saab andmebaasist välja võtta otse, ilma otsinguta kasutades selleks objekti indikaatorit. Objektorienteeritud andmebaas toetab multimeediarakendusi, sest andmetega seotud klassi meetodid vastutavad nende andmete õige interpreteerimise eest. Objektorienteeritud andmebaasid toetavad harilikult paremini versioonimist, samuti pakuvad süstemaatilist tuge päästikprotsessidele ja tõketele, millel on aktiivandmebaasides põhjapanev roll. Objektorienteeritud andmebaasidest on kasu enamikul andmebaasivajadustega objektorienteeritud rakendusprogrammidel. Kronoloogiline andmebaas (TSDB – time series database) on tarkvarasüsteem, mis on optimeeritud aegridade salvestamiseks ja esitamiseks seotud aja kaudu. Mõnes valdkonnas võidakse aegridu nimetada profiilideks, kõverateks või trendideks. Paljudel juhtudel kasutavad kronoloogilised andmebaasid andmete tõhusaks talletamiseks tihendusalgoritme. Ehkki aegridade andmeid on võimalik salvestada paljudesse erinevatesse andmebaasitüüpidesse, erineb nende süsteemide kujundus selle poolest, et aeg on peamiseks indeksiks erinevalt relatsioonilistest andmebaasidest.  Pikemalt artiklis Andmebaasi disain Projekteerimisetapi ülesandeks on analüüsi etapis väljatoodud nõuetele vastavate loogiliste ja tehniliste lahenduste väljatöötamine. Disain võrdub projekteerimisega. Eristatakse loogilist ja füüsilist disaini. Loogiline disain tegeleb konkreetsest realisatsiooni- ja rakenduskeskkonnast sõltumatute, järelikult nende keskkondade jaoks spetsiaalselt optimeerimata lahenduste loomisega. Füüsiline disain häälestab loogilise disaini lahendusi konkreetsete “füüsiliste” keskkondade jaoks. Projekteerimisetapis toimub: detailmodelleerimine ja tööstsenaariumide koostamine; kasutajaliideste ja kliendi tarkvara loomine; serveri andmebaasi loomine; rakenduspakettide häälestamine; disaini tulemuste hindamine/üleandmine/nõustamine; süsteemi tarkvara hindamine ja üleandmine; puuduste likvideerimine; kasutajate koolitus; dokumenteerimine; projektijuhtimine. Andmete osas tähendab andmete loogiline projekteerimine kõigepealt realatsioonilise andmemudeli sissetoomist ning andmestruktuuride viimist kolmandale normaalkujule. Andmemudelisse ei tohi jääda mitu-mitmele suhteid, mis analüüsi mudelis on lubatud. Erinevalt analüüsietapis koostatud kontseptuaalmudelist nähakse nüüd iga andmeobjekti taga konkreetset andmetabelit. Seepärast nimetatakse andmemudelit loogiliseks andmebaasiskeemiks. Kirjeldatakse kõik andmeväljad, määratakse standardsed (mitte konkreetse tarkvaraga seotud) andmetüübid ja väljapikkused. Füüsiline disain andmete osas sisaldab: andmemudeli viimist konkreetse andmebaasisüsteemi tarkvara (nt Oracle, Microsoft SQL) konteksti; andmetüüpide täpsustamist vastavalt valitud andmebaasisüsteemi võimalustele; andmestruktuuride denormaliseerimist mõningate eriti tähtsate andmebaasioperatsioonide töökiiruse suurendamise eesmärgil; andmete denormaliseerimise vajadused selgitatakse välja transaktsioonianalüüsi (erinevate andmebaasioperatsioonide täitmissagedused ja täitmisajad) käigus; mitmesuguste füüsilise disaini objektide (indeksid, numbrijadad, abitabelid, trigerid, salvestatud protseduurid) lisamist andmebaasi. Andmebaasi projekteerimine eeldab ka andmebaasi kasutavate/uuendavate rakenduste projekteerimist. Andmebaasi rakendused on registri tüüpi rakendused, mis realiseerivad elementaarseid andmete registreerimise ja päringu protsesse ehk andmebaasiliideseid. Andmebaasiliides koosneb kasutajaliidesest (ekraanivorm, aruanne) ning kasutajaliidese (sündmuste) kaudu käivitatavatest andmebaasi operatsioonidest (päringud, andmeuuendused, transaktsioonid). Registri tüüpi rakenduse disain sisaldab: kasutajaliideste loogilist ja füüsilist projekteerimist; konkreetsete ekraanivormidega seotud reaalsete kasutusjuhtumite tööstsenaariumide detailset kirjeldamist ekraanivormi väljade täitmise tasemel; ekraanivormidest käivitatavate andmebaasioperatsioonide (andmete lisamine, muutmine, kustutamine, päringud) loogilist ja füüsilist projekteerimist; andmebaasioperatsiooni teostamist, kasutades loogika tekstilist ja/ või graafilist kirjutuskeelt. Operatsioonide projekteerimine toimub tavaliselt SQL-is (päringukeel) ja seda laiendava protseduurse keele vahenditega. Siin toimub eraldi disainitud andmebaaside ja rakenduste lõplik realiseerimine ja integreerimine terviksüsteemi tasemel. Põhitegevusteks programmeerimine, testimine, integreerimine. Integreerimise õnnestumises mängib võtmerolli hästi projekteeritud andmebaas. Eesmärgiks on süsteemi ehitajate juures realiseeritud ja töötava terviksüsteemi üleviimine tellija keskkonda ja seal toimima panemine. Kõige keerukamaks tegevuseks on siin andmete ülekandmine vana(de)st süsteemi(de)st uue süsteemi andmebaasi(desse). Selles faasis toimub: käituskeskkonna olukorra hindamine; tehniline ettevalmistus; koolitus; tarkvara käituskeskkonda viimine; esmakasutamine; lõppakti koostamine; hoolduse seadistamine; lõppdokumentide allkirjastamine; projektijuhtimine. Järgmine samm on üleminek süsteemi rutiinsele kasutamisele. Tellija keskkonnas toimiva süsteemi ülalhoidmine, vigade parandamine, jõudluse jälgimine, häälestamine, uute arendustööde käivitamine. Andmebaasi hoiab üleval andmebaasi administraator. Arvutiprojektide puhul on tavaks kuni üheaastane hooldus. Hooldusfaasis saab pisivigu parandada ja kasutajat täiendavalt abistada. Siia kuulub hoolduse valmisoleku seadistamine, vigade parandamine ja abistamine. Hindamine on vajalik projektiarenduses reglementeerida nii infosüsteemide audiitori tegevusena kui ka oma projektide kvaliteedi hindamiseks. Hindamist tuleb rakendada projektide kõikide aspektide, nii sisulise kui ka arendustegevuse kohta. Infosüsteemi hindamisel on eesmärgid, teatav projekti seisund (pakkumine võit mitmes etapp või lõpptulem). Kasutatakse teatavaid hindamise parameetreid ja luuakse protseduur, kuidas hindamist korraldada. Hinnang võib olla kvantitatiivne kui ka kvalitatiivne. Hindamise eesmärgid on finantsid, aeg, leping, tellija nõuded/soovid, funktsionaalsus, andmed, arhitektuur, töökorraldus arvutitega, tellija kompetentsus, tehnoloogia faasilisuse järgimine, projekti läbiviimise terviklikkus ning teostatud tööd. Hindamise protseduur on tüüpiliselt kokku lepitav. Hinnang antakse lepingu, dokumentatsiooni, lahenduste/ vahendite kaasaegsuse, teostuse taseme suhtes. Samuti võib anda soovitus, mida veel teha. Projekti tulemuste hindamine toimub ettenähtud või kokkulepitud protseduuride ja meetrika alusel. Kasutatakse seesmist ehk projekti liikmete poolset hindamist ja välisauditit. Projektipakkumise hindamiseks moodustavad firmajuhid ja eksperdid nn eksperdikomisjoni, kes lepib kokku hindamismõõdikute ja protseduuri suhtes. Järgnevalt esitatud hindamise käsitlus ei ole standard. Tavaliselt on igal suuremal organisatsioonil oma käsitlus. Hindamisprotseduurid näevad sageli ette mitmeastmelist hindamist, mille korral halvimad pakkumised eemaldatakse ja paari või kolme parima pakkumisega tegeletakse põhjalikumalt. Hindamisel ei ole kõik parameetrid sama kaaluga. Tavaliselt töötatakse välja nn koefitsientide süsteem. Sellega arvestatakse iga hinde osakaalu. Mõõdikud koostatakse sageli mitmetasemelisena, milles eristatakse näiteks tehnilist, küsitud dokumentatsiooni ja omaduste hindamist. Sellisena formuleeritud protseduuri on hea kasutada halbade pakkumiste kiireks eemaldamiseks konkursilt. andmebaasihaldur (Database Management System, DBMS, vt ka ORDBMS) andmebaasimootor (Database Engine) andmebaaside teooria (Database Theory) andmebaasi tarkvara (Database Software) andmebaasi loomine (Database Design) andmebaasi teisikud (Database replication) andmebaasipäring plokiahel terminibaas mälupõhine andmebaas Mueen, Abdullah; Keogh, Eamonn; Zhu, Qiang; Cash, Sydney; Westover, Brandon. "Exact Discovery of Time Series Motifs" (PDF). University of California, Riverside. Lk 2. Originaali (PDF) arhiivikoopia seisuga 25.06.2010. Vaadatud 31.07.2019. Definition 2:A Time Series Database(D)is an unordered set of m time series possibly of different lengths. Villar-Rodriguez, Esther; Del Ser, Javier; Oregi, Izaskun; Bilbao, Miren Nekane; Gil-Lopez, Sergio (2017). "Detection of non-technical losses in smart meter data based on load curve profiling and time series analysis". Energy. 137: 118–128. DOI:10.1016/j.energy.2017.07.008. ISSN 0360-5442. {{cite journal}}: parameeter |hdl-access= nõuab parameetrit |hdl= (juhend) Pelkonen, Tuomas; Franklin, Scott; Teller, Justin; Cavallaro, Paul; Huang, Qi; Meza, Justin; Veeraraghavan, Kaushik (2015). "Gorilla". Proceedings of the VLDB Endowment. 8 (12): 1816–1827. DOI:10.14778/2824032.2824078. Asay, Matt (26. juuni 2019). "Why time series databases are exploding in popularity". TechRepublic. Originaali arhiivikoopia seisuga 26.06.2019. Vaadatud 31.07.2019. Relational databases and NoSQL databases can be used for time series data, but arguably developers will get better performance from purpose-built time series databases, rather than trying to apply a one-size-fits-all database to specific workloads. Andmebaasi mudelid (arhiiviversioon) Andmebaaside tüübid