DB2 Flashcards
PL/SQL
• PL/SQL - Procedural Language/SQL
• PL/SQL rozšiřuje SQL o konstrukce s procedurálního programování.
• Doplňuje SQL, nikoliv nahrazuje.
– PL/SQL kombinuje možnosti deklarativního a imperativního programování.
Kurzory
- Privátní pracovní oblasti, které jsou databázovým serverem vytvořeny pro každý příkaz SQL.
- Kurzory jsou v podstatě ukazatele do paměti, ne přímo do dat. Výsledné záznamy dotazu jsou do paměti vloženy ve chvíli otevření kurzoru.
- V podstatě se jedná o mechanismus, kdy SELECT příkazu přiřadíme jméno, přes které pak můžeme manipulovat s daty získanými příkazem.
- Implicitní kurzory jsou vytvářeny automaticky databázovým serverem, není nutné je otevírat, zavírat, deklarovat nebo z něj načítat data,
- Explicitní – deklarované programátorem
Základní kroky pro práci s explicitními kurzory:
- Deklarace kurzoru
- Otevření kurzoru
- Výběr dat prostřednictvím kurzoru
- Uzavření kurzoru
Explicitní kurzory - syntaxe, testování stavu, + podívat se na příklad
- Deklarace kurzoru CURSOR IS <p>; - Otevření kurzoru OPEN ; - Výběr dat prostřednictvím kurzoru (opakovat v cyklu) FETCH INTO ; - Uzavření kurzoru CLOSE ;
Pro testování stavu kurzoru jsou k dispozici atributy %ROWCOUNT Zjištění pořadového čísla aktuálního záznamu (pokud nebyl vybrán žádný, je hodnota 0) %FOUND Pokud poslední příkaz FETCH načetl nějaký záznam, má atribut hodnotu TRUE Používá se pro zjišťování konce cyklu %NOTFOUND Používá se pro zjišťování konce cyklu %ISOPEN Pokud je kurzor otevřen, má hodnotu TRUE Použití: %ROWCOUNT</p>
Práce s implicitními kurzory
a) Příkaz SELECT … INTO … FROM … musí vrátit alespoň jeden a nejvýše jeden řádek, počet sloupců musí odpovídat počtu proměnných uvedených za klauzulí INTO včetně použitelnosti datových typů.
b) Následující příklad ukazuje využití implicitního kurzoru pro sady výsledků s omezeným počtem řádků (řekněme méně než 100)
BEGIN
FOR x IN (SELECT jmeno, Id FROM trpaslici)
loop
DBMS_OUTPUT.PUT_LINE(‘Jméno ‘ || x.jmeno || ‘, Id ‘ || x.Id);
END LOOP;
END;
Explicitní vs. implicitní kurzory
- Implicitní kurzory jsou obecně výkonnější.
- Implicitní kurzory jsou z pohledu kódu úspornější a automatizují operace OPEN, CLOSE, FETCH a EXIT WHEN .. %NOTFOUND explicitního kurzoru.
- Nehrozí opomenutí EXIT WHEN, což má za následek uváznutí v nekonečné smyčce.
- Explicitní kurzory lze předávat parametrem mezi jednotlivými procedurami/funkcemi.
- Využívá se při tom datový typ SYS_REFCURSOR.
- Větší flexibilita než implicitní kurzory.
Záznamy
Struktura typu záznam zapouzdřuje více položek i rozdílných datových typů. Deklarace záznamu DECLARE TYPE IS RECORD ( [, …] ); Příklad DECLARE TYPE rec_ucitel IS RECORD ( jmeno ucitel.jmeno%TYPE, Id ucitel.Id%TYPE ); Nebo po zjednodušení jen DECLARE rec_ucitel ucitel%ROWTYPE;
Práce s kurzory a záznamy
DECLARE
rec_trpaslik a_snehurka.trpaslici%ROWTYPE;
CURSOR k1 IS SELECT jmeno, Id FROM a_snehurka.trpaslici;
BEGIN
OPEN k1;
LOOP
FETCH k1 INTO rec_trpaslik.jmeno, rec_trpaslik.id;
EXIT WHEN k1%NOTFOUND;
DBMS_OUTPUT.PUT_LINE(‘Jméno ‘ || rec_trpaslik.jmeno || ‘, Id ‘ || rec_trpaslik.Id);
END LOOP;
CLOSE k1;
END;
S využitím záznamů můžeme s kurzory pracovat mnohem efektivněji
Cyklus FOR s explicitním kurzorem
(kurzor v tomto případě nemusíme ani otevírat ani zavírat, dokonce ani cyklicky vybírat data pomocí příkazu FETCH, všechny tyto úkony za nás provede server standardně)
Příklad
DECLARE
rec_ucitel ucitel%ROWTYPE;
CURSOR k1 IS
SELECT jmeno, Id FROM ucitel;
BEGIN
FOR rec_ucitel IN k1
LOOP
DBMS_OUTPUT.PUT_LINE('Jméno ' || rec_ucitel .jmeno || ', Id ' || rec_ucitel.Id);
END LOOP;
END;
Kurzory s parametry
Kurzor můžeme rozšířit o parametry, které budou dosazeny do dotazu až během otevření kurzoru
Deklarace explicitního kurzoru s parametrem
CURSOR [( , … )] IS <p>;
Příklad
DECLARE
rec_ucitel ucitel%ROWTYPE;
CURSOR k1 (v_jmeno VARCHAR2) IS
SELECT jmeno, Id FROM ucitel WHERE jmeno LIKE (v_jmeno || '%');
BEGIN
FOR rec_ucitel IN k1 (‘Za’)
LOOP
DBMS_OUTPUT.PUT_LINE('Jméno ' || rec_ucitel .jmeno || ', Id ' || rec_ucitel.Id);
END LOOP;
FOR rec_ucitel IN k1 (‘Sm’)
LOOP
DBMS_OUTPUT.PUT_LINE('Jméno ' || rec_ucitel .jmeno || ', Id ' || rec_ucitel.Id);
END LOOP;
END;
</p>
Ošetření chyb PL/SQL
V zásadě se mohou v PL/SQL vyskytnout 2 druhy chyb:
Syntaktické – projeví se ještě v procesu kompilace (upozorní nás na ně překladač)
Run-time – projeví se až za běhu programu
Nejčastěji se vyskytují následující výjimky:
DUP_VAL_ON_INDEX výskyt duplicitní hodnoty ve sloupci, který připouští jen jedinečné hodnoty
INVALID_NUMBER neplatné číslo nebo data nemohou být převedena na číslo
NO_DATA_FOUND nebyly nalezeny žádné záznamy
TOO_MANY_ROWS dotaz vrátil více než jeden záznam
VALUE_ERROR problém s matematickou funkcí
ZERO_DIVIDE dělení nulou
+ všeobecná syntaxe (a RAISE (ten může i vlastní výjimky))
+ obsluha výjimky
+ chyba má SQLCODE a SQLERRM
+ nezachycené výjimky jsou propagovány výš a výš až do hostitelského prostředí
Procedury a funkce
Bloky příkazů jazyka PL/SQL lze pojmenovat a uložit ve spustitelné formě do databáze. Těmto blokům říkáme procedury, resp. funkce.
Vlastnosti procedur a funkcí:
Jsou uloženy ve zkompilovaném tvaru v databázi.
Mohou volat další procedury či funkce, či samy sebe.
Lze je volat ze všech prostředí klienta.
Funkce, na rozdíl od procedury, vrací jedinou hodnotu (procedura může vracet hodnot více, resp. žádnou).
+ syntaxe
+ parametry, vstupní, výstupní, vstupně-výstupní
Aktivní pravidla
aktivní pravidla (active rules)
◦ pro vyhodnocení složitých podmínek kladených na data (tzv. business rules)
◦ kontrola na databázové úrovni
◦ usnadnění práce – auditovatelnost, bezpečnost
triggery (triggers) ◦ v překladu „spoušť“ , „kohoutek“ ◦ jiný název pro aktivní pravidla ◦ v praxi je dávána přednost názvu trigger AKTIVNÍ PRAVIDLA = TRIGGERY
• Trigger („spoušť“) je “procedura”, která se spustí při
výskytu nějaké sledované události.
• V relačních databázích trigger = aktivní pravidlo
• Od SQL 1999
Vs. integritní omezení (ty jsou jednodušší, rychlejší, ale ne vždy postačující, nejsou auditovatelné)
Starburst
• IBM, Almaden Research Center -> Starburst Active Rule System • Získalo popularitu -> Jednoduchá syntaxe a sémantika -> Množinově orientovaná • Pravidla založena na ECA-paradigmatu (Event-Condition-Action)
• Událost (Event)
-> SQL-příkazy pro manipulaci s daty (INSERT, DELETE,
UPDATE)
• Podmínka (Condition)
-> booleovský predikát nad stavem databáze, vyjádřen pomocí SQL
• Akce (Action)
-> provádí libovolné SQL dotazy (například SELECT, INSERT, DELETE, UPDATE)
-> navíc mohou obsahovat příkazy pro manipulaci s aktivními pravidly a transakční instrukci ROLLBACK WORK
Sémantika aktivních pravidel
• Když nastane Událost, pokud je splněna Podmínka, proveď Akci.
Říkáme, že pravidlo je:
• spuštěno (triggered) – pokud nastane příslušná Událost
• vyhodnoceno (considered) – po vyhodnocení dané
Podmínky
• vykonáno (executed) – po provedení jeho Akce
Vlastnosti aktivních pravidel
• Jsou přidané do schématu databáze a jsou sdílené všemi aplikacemi.
• Mohou být dynamicky aktivovány a deaktivovány každou transakcí.
• Mohou tvořit skupiny.
• Každé pravidlo ve Starburstu má jedinečné jméno a je spojeno s jednou určitou tabulkou, zvanou rule’s target.
• Každé aktivní pravidlo může sledovat více Událostí, tzv. rule’s triggering operations.
• Jeden SQL příkaz může být sledován více pravidly.
-> Pořadí pravidel je určeno na základě jejich částečného uspořádání.
Problémy s triggery
• standardizace
- > není
- > snaha by byla od 80. let v normě SQL-92 nejsou standardně uvedeny
- SQL 1999 – základní podmínky realizace, ale …
- proprietární řešení výrobců DB systémů
- > rozdíly v syntaxi i sémantice
- > vazba aplikace na konkrétního výrobce
• technické problémy
- > nekonečné vzájemné volání triggerů (retriggering)
- > několik možných řešení
- > používají se všechna
Triggery v PL/SQL
- Jedná se o PL/SQL objekty spouštěné vyvoláním příslušné události v DB
- Vyvolání může způsobit DML událost, DDL operace nebo speciální DB událost
- Vyvolat trigger můžeme před nebo po provedení operace
- Existuje také možnost vyvolání místo příslušné operace
- Je možné omezit vyvolání podmínkou
+ DML triggery (delete, insert, update)
+ DML triggery vyvolání pro celou operaci / for each row / sloučením OR
Syntaxe DML triggeru:
CREATE OR REPLACE TRIGGER jméno BEFORE | AFTER | INSTEAD OF DELETE | INSERT | UPDATE OF cols ON tabulka [ způsob odkazování ] [ FOR EACH ROW ] [ WHEN ( podmínka ) ] AS pl/sql kód
Způsob odkazování • Definuje, jak budou přístupné původní a nové záznamy (vstupující do DML operací) • Implicitně :new, :old, :parent • Existuje klauzule: REFERENCING [ OLD AS jméno ] [ NEW AS jméno ] [ PARENT AS jméno ]
- Pro BEFORE a AFTER je trigger chápán jako tzv. statement trigger a vyvolán je pouze jedenkrát (není-li klauzulí FOR EACH ROW explicitně stanoveno jinak)
- V případě INSTEAD OF triggeru je trigger implicitně chápán jako řádkový trigger, protože zde statement trigger nemá prakticky žádný význam
DDL triggery
• Jsou vyvolány po provedení DDL příkazu • Mohou být BEFORE, AFTER • Mohou být omezeny podmínkou (WHEN) • Definují se dvěma způsoby: ->jméno události ON DATABASE -> jméno události ON jméno schématu • Existuje řada definovaných událostí, např. CREATE, ALTER, DROP, RENAME, GRANT, COMMENT, AUDIT, DDL
Triggery databázových událostí
- Pracují stejně jako DDL triggery, pouze je jiná množina povolených událostí
- Typicky se jedná o události zásadních událostí v celé databázové instanci, např. STARTUP, SHUTDOWN, LOGON, LOGOFF, SERVERERROR, SUSPEND apod.
- Uvnitř DDL a databázových triggerů nelze provádět jiné DDL operace
- Velmi specifické použití
Omezení triggerů
- BEFORE a AFTER triggery nelze specifikovat nad pohledy
- V BEFORE triggerech není možné zapisovat do :old záznamů
- V AFTER triggerech nelze zapisovat ani do :old, ani do :new záznamů
- INSTEAD OF triggery pracují jen s pohledy, mohou číst :old i :new, ale nemohou zapisovat ani do jednoho
- Nelze kombinovat INSTEAD OF a UPDATE
- Nelze definovat trigger nad LOB atributem
- Nelze použít transakce, pokud je zpracovávána jiná transakce (tedy prakticky nelze použít transakce vůbec)
- Není možné sledovat (ani modifikovat) data v tabulce, která způsobila vyvolání DML triggeru – toto omezení je často velice nepříjemné
- Jediné známé řešení: zrcadlení tabulek
Emulace AUTOINCREMENT
- Některé SQL databázové systémy používají modifikátor typu AUTOINCREMENT pro definici číslování primárních klíčů
- Je možné toto chování emulovat umístěním BEFORE INSERT triggeru, který vyčte novou hodnotu ze sekvence a modifikuje :new.id na tuto hodnotu
Základní možnosti uložení XML dat
- Uložení v systému souborů
- Uložení v relační databázi
- Uložení v objektově orientovaném systému
- Uložení v objektově-relačním databázovém systému
- Nativní XML úložiště
Uložení xml v systému souborů
1) konstrukce celých DOM stromů
- > nutnost držet celý dokument v paměti
- > nutnost analyzovat celý text
2) možnost značkování, abychom se vyhnuli nevýhodám
- > zbytečně složité, nemožná aktualizace
Uložení xml v relační databázi
1) buď xml jako LOB
- snadná implementace
- s xml se musí pracovat jako s celkem
2) xml dokument se rozloží do několika tabulek
- dekompozice xml dokumentu do relačního modelu
- relační model špatně hierarchickou strukturu => je to pomalé
- některé dotazy rychlé převedením na SQL dotaz
a) Uložení hran stromu
b) Odvození schématu z DTD
Uložení hran stromu xml do relačních tabulek
• Id uzlu získané preorder průchodem
• Hrana: pětice
(výchozí ID, cílové ID, značka, pořadí, vložený obsah)
• Elementy se smíšeným obsahem jsou modelovány jako stromy s více textovými elementy
• Nula ve sloupci cílového ID značí, že uzel je atribut
• Doporučuje se index: (značka, data),
(výchozí ID, ordinál), (ID cíle)
• Uložení pomocí hran je poměrně neúporné
• Možnost zrušení sloupce se značkou a rozdělení do více relačních tabulek
• Zbavíme se tím ale možnosti ukládat libovolná XML data
• Se stovkami relačních tabulek se RDBMS hůře vypořádá
Odvození schématu z DTD pro uložení xml do relačních tabulek
• DTD (Document Type Definition, česky Definice typu dokumentu) je jazyk pro popis struktury XML případně SGML dokumentu.
Omezuje množinu přípustných
• Tabulky se generují od kořene DTD
• Každé n-tici je přiřazen unikátní identifikátor a vyplněn sloupec identifikující rodičovský element
• Elementy bez vícenásobného výskytu jsou vloženy přímo jako další sloupce do tabulky rodičovského elementu
• Problém: zkoumání vztah předek-potomek
-> Mnoho operací join
-> Problém s dokumenty s cyklickým DTD – hluboké hnízdění SQL dotazů, případně potřeba nějakého (např. procedurálního) rozšíření dotazovacího jazyka
• Netriviální převod XQuery -> SQL
Uložení xml v objektově-relační databázi
- Využívá ADT, abstraktní datové typy
- Obvykle je vyžadováno DTD
- Podobné strukturálnímu uložení do RDBMS
- Problém s rekurzivními strukturami, smíšenými elementy, problematické složitější modelové skupiny DTD
Nativní uložení xml
• Zcela přizpůsobeno stromové struktuře XML dat
• Výhody
+ Rychlost, flexibilita
+ Snadné a efektivní XML dotazování
• Nevýhody
- Nutnost vybudování zcela nových datových struktur a metod pro vyhodnocení dotazů
Oracle + XML
SŘBD Oracle podporuje XML formát od verze 10g.
• Zavádí datový typ XMLType, kterým lze buď:
-> definovat strukturu tabulky (OF XMLType),
-> nebo určit datový typ jednoho daného atributu tabulky
Oracle SQL Developer a XMLType
• Oracle SQL Developer komunikuje s databází Oracle prostřednictvím JDBC ovladače, který je součástí distribuce produktu. Obecně platí, že společnost Oracle distribuuje v jediném archivu (např. ojdbc6.jar) dva JDBC ovladače.
Thin
• tenký ovladač, vystačí si jen s metodami implementovaným v daném archivu, obvykle postačuje pro základní komunikaci s Oracle databází.
OCI/Thick
• tlustý ovladač, který vyžaduje další instalované knihovny
• knihovny jsou dostupné přes systémovou proměnnou OracleHome (uchovává cestu k instalované produktu, kterým může být Oracle Client (může být i instantní), případně celý Oracle Database Server).
Vložení XML dokumentu do databáze
Existuje několik způsobů:
A) S dodatečnými oprávněními
- Nejobvyklejší způsob předpokládá, že na serveru (stejný stroj, kde běží databázový stroj) vytvoříme/vyhradíme adresář, který musíme v databázi zaregistrovat příkazem CREATE DIRECTORY.
- Tento způsob vyžaduje dodatečná oprávnění, která běžný uživatel nemá přidělena a mít nebude.
- Do zmíněného adresáře je nutno umístit XML soubory, které chceme do databáze uložit.
- Jejich uložení provést příkazem INSERT
B) bez potřeby výše zmiňovaných oprávnění.
- Formulace příkazu INSERT, který do připravené tabulky vloží nový záznam (tj. XML soubor) jako objekt vytvořený implicitním konstruktorem typu XMLType - v případě použití Oracle SQL Developeru využívajícího tlustého JDBC ovladače to lze provést nahráním obsahu zvoleného souboru při vyplňování pole obsahující XML soubor.
- Do databáze se neukládá příslušný název ukládaného XML souboru, to je nutno v případě potřeby vytvořit explicitně.
Klasický x Temporální databázový systém
Čas je potřeba uchovat a pracovat s ním:
Klasický databázový systém
- > Zachycuje stav systému v daném okamžiku
- > Jak pracovat se starými daty?
Temporální databázový systém
- > Podporuje práci s časem – zohledňuje časové vlastnosti vkládaných dat
- > Jednodušší dotazy přes časová období
Případová studie temporální databáze
1) Databáze zaměstnanců
=> Zamestnanec(Jmeno, Plat, Titul)
2) Přidáme do záznamu datum narození
=>Zamestnanec(Jmeno, Plat, Titul, DatumNarozeni DATE)
3) Nyní chceme přidat záznam o vývoji v zaměstnání
=> Zamestnanec(Jmeno, Plat, Titul, DatumNarozeni,
Start DATE, Stop DATE)
a) Potřebujeme zjistit hisotrii platů zaměstnanců
b) Potřebujeme zjistit maximální dobu, kdy měli stejný plat
=> V SQL obtížné
=> Koalescence
Temporální databáze - důvod
- Data závislá na čase jsou běžně využívána
- Práce s časově závislými daty je běžná, potřebná.
- Velmi malá podpora klasických databází ==> temporální databáze a databázové systémy.
- Netemporální databáze nemají dostatečnou podporu pro práci s těmito údaji
- Temporální databáze umožňuje jednodušší dotazy
Časová doména
- Modelování a reprezentace času
- Čas v temporální logice = libovolná množina okamžiků s částečným uspořádáním
•Další axiomy model upřesňují
- > Lineární – uspořádání celé množiny
- > Větvení – lineární do teď, pak možné budoucnosti
- > Cyklický – rekurentní proces (týden)
• Axiomy mohou charakterizovat hustotu
• Diskrétní modely – isomorfní přirozeným číslům
-> každý bod v čase má jednoho předchůdce
• Husté modely – isomorfní racionálním nebo reálným
číslům
-> mezi každými dvěma momenty existuje další
• Průběžné modely – isomorfní reálným číslům
- V průběžném modelu každé reálné číslo odpovídá bodu v čase
- V diskrétním modelu každé přirozené číslo odpovídá nedělitelné jednotce času s libovolným trváním – chronon
- Chronon není bod, ale úsečka
Obvykle se používá diskrétní model
• nepřesnost měření
• přirozenost v jazyce
• přirozená modelace událostí, které trvají
Další axiomy:
• Omezení
• Koncept vzdálenosti
• Relativní a Absolutní čas
Datové typy času
• okamžik – specifický chronon
• událost – něco, co se stalo v daném okamžiku
• doba události – okamžik, kdy se událost stala ve
skutečnosti
• SQL92 – DATE, TIME, TIMESTAMP
• časová perioda – čas mezi dvěma okamžiky
-> neplést s typem INTERVAL
- časový interval – známý časový úsek, ale nemá specifické hraniční okamžiky
- množina okamžiků
- temporální elementy – konečné sjednocení period
Vztah události a času
2 ortogonální dimenze:
1) Čas platnosti (valid time)
- Doba, kdy byla událost v realitě pravdivá – kdy se stala
- I v budoucnosti
2) Transakční čas (transaction time)
- Doba, kdy byla událost reprezentovaná v DB
- Pouze minulost a současnost
Událost a čas – datové modely
1) Snapshot
2) Transaction-time model
3) Valid-time model
4) Bitemporální model
Snapshot (temporální databáze)
- Nepodporuje ani čas platnosti ani transakční čas
- Klasický relační model
- Při změně reality se mění stav relace (vložení, odebrání, změna prvků)
- snímek – nepodporuje ani jeden model, okamžik v databázi
Transaction-time model
Podporuje pouze transakční čas Posloupnost snapshotů indexovaných transakčním časem Nemění existující data Append-only (snapshot) Hledání v minulosti
Transaction time – období, po které je fakt uložený v databázi
Transaction-time relace
• Snímek se neupravuje
• Dojde ke změně aktuálního snímku, který se poté přidá do relace
•Využitelné pro dotazy na stav databáze v minulosti
Valid-time model
Podporuje pouze čas platnosti
Dotazy i na fakta platná v budoucnosti
Možná úprava čehokoli
Valid time – čas, po který fakt byl/je/bude pravdivý.
- Uchovává platnost dat
- Kterákoliv část se dá upravit
- Nedá se určit předchozí stav databáze
Bitemporální model
Podporuje čas platnosti i transakční čas
4D: n-tice, hodnoty atributů, čas platnosti, transakční čas
append-only
• bitemporální čas – podporuje oba modely (valid a transcation)
- „append only“ jako transaction-time
- Platnost dat jako valid-time
- S rozvojem databáze transaction-time roste monotónně, ale valid-time může mít velký rozptyl
Flashback v Oracle
- Technologie flashback používá své flashback logy, undo segmentů a odpadkového koše.
- Jednoduše ji lze přirovnat k tlačítku Undo v textovém editoru, nastalý problém řešíte použitím akce „krok zpět“.
- Veškeré akce a změny provedené v databázi jsou označeny svým číslem SCN (system change number). V případě, že budete chtít změnu vrátit, udělat tzv. rollback, musíte stanovit, ke kterému SCN číslu se chcete vrátit.
- Flashback můžete použit na veškeré tabulkové prostory vyjma systémového.
- Flashback je rozdělen do různých oblastí podle akce, kterou chcete provádět.
Dotazovací jazyk – TSQL2
- TSQL2 byl navržen skupinou asi 18 badatelů, kteří už dříve samostatně navrhli mnoho různých temporálních dotazovacích jazyků.
- Cílem TSQL2 bylo sjednotit přístupy k temporálním datovým modelům a dotazovacím jazykům založeným na kalkulu a získat sjednocené rozšíření SQL-92 a datový model, nad kterým by mohl být založen další výzkum.
- TSQL2 bylo začleněno do vyvíjejícího se standardu SQL3.
Pojetí času
• Časová osa TSQL2 je na obou koncích omezena, ale dostatečně daleko (18 miliard let)
• U časových údajů jsou možné různé granularity
• Časové typy
• DATE, TIME, TIMESTAMP, INTERVAL, PERIOD
Datový model
• Je použit BCDM (Bitemporal Conceptual Data Model)
• Řádek relace je orazítkován množinou bitemporálních chrononů
• Bitemporální chronon je dvojice (chronon transakčního času, chronon času platnosti)
Časová ontologie TSQL
- Lineární časová struktura, omezená z obou stran (+-18 miliard let)
- diskrétní reprezentace reálného času, která může být považována za diskrétní, hustou nebo průběžnou
- granule – seskupení po sobě jdoucích chrononů – různá granularita
- nevyžaduje výběr mezi diskrétní, hustou nebo průběžnou ontologií
- Dokonce nedovoluje otázky, které by nutili rozhodnout mezi modely
- Nelze se ptát, zda okamžik A předchází okamžik B - pouze v rámci zvolené granularity (vteřiny, dny,…)
- Přidává datový typ PERIOD
Datový model temporálních databází
• jednoduchý
• zachovává obecnost a jednoduchost relačního modelu
• separátní modely pro prezentaci dat, ukládání dat a
vyhodnocování dotazů
• Více koordinovaných datových modelů zvládne co by
jeden nedokázal
Relační databáze v kontextu No SQL
• Data organizována do tabulek, řádek reprezentuje záznam. (koncept matematické relace, řádek prvkem relace nad doménami sloupců tabulky)
• Každý sloupec má přesně daný (jednoduchý) datový typ. (tj. množina/doména odpovídající části relace)
• Záznam v tabulce se může odkazovat na záznam
(jiné) tabulky. (hodnota cizího klíče odpovídá hodnotě primárního klíče odkazovaného záznamu)
- Organizace dat musí splňovat normální formy. (1NF, 2NF, 3NF, EKNF, BCNF, 4NF, 5NF, DKNF, 6NF1; jinak hrozí redundance/chyby)
- Dotazy a úpravy nad daty pomocí SQL. (dotazování pomocí SELECT vychází z relační algebry)
- Databázový systém zaručuje ACID změny uložených dat. (Atomicity, Consistency, Isolation, Durability)
Požadavky na moderní databáze
- cloud, distribuované databáze (decentralizace úložiště dat, úmyslná redundance pro odolnost proti výpadkům a rychlost, velké objemy dat a velké množství operací /big data/, atd.)
- problematické datové typy (údaje klíč-hodnota, objekty, nestrukturované dokumenty, RDF grafy, atd.)
- iterativní vývoj (časté změny schématu databáze nebo dokonce žádné schéma, různé/nejasné způsoby použití databáze, atd.)
- vysoké požadavky na škálovatelnost (mobilní zařízení jako klienti i úložiště/poskytovatelé dat, nerovnoměrné rozložení zátěže prostorově i časově, specifické požadavky na dostupnost, předem neznámé dotazy - nelze optimalizovat indexy, atd.)
Moderní relační databáze? (no sql kapitola)
- Snaha přizpůsobit relační databázi moderním požadavkům. (post-relační relační databáze /objektově-relační, s podporou XML, . . . /, univerzální datové modely, úmyslná denormalizace, zavádění cache, datové sklady, atd.)
- „Relační“ databáze přestává odpovídat relačnímu konceptu. (už ne matematické relace, ale spíše kolekce/množiny/grafy nestrukturovaných dat)
• Dodržování ACID nevhodně omezuje práci s databází.
(úmyslné zanedbání/odpuštění Atomicity, Consistency, Isolation nebo Durability pro zisk rychlosti a dostupnosti dat)
• Vznik specializovaných nerelačních (post-relačních)
databází:
– pro specificky strukturovaná data,
– (čistě objektové či XML databáze, úložiště tagovaných
dokumentů, atd.)
– pro specificky uložená/přistupovaná data.
(in-memory, embedded a real-time databáze či map-reduce zpracování dat)
Vznik NoSQL databází
- Webové aplikace - nová řešení více vyhovující těmto potřebám.
- Pro malá, často používaná data, se začaly využívat paměťové cache s jednoduchou architekturou klíčhodnota (key-value).
- Nejprve jako doplněk k tradičním relačním databázím, později se začalo experimentovat s rozhraním klíč-hodnota i pro perzistentní databáze.
- Úspěch - další experimentování přineslo nová řešení uspokojující požadavky na škálování, distribuovaná data, vysokou propustnost a spolehlivost.
- Výsledek - skupina databází označených jako NoSQL.
Termín NoSQL „Not only SQL“ databáze byl zvolen pro volně specifikovanou třídu nerelačních datových úložišť. …
• Někdy se pro tato datová úložiště používá i termín postrelační.
SQL a NoSQL databáze (terminologie)
Pojem SQL:
• Především relační a objektově-relační databáze používající jazyk SQL.
• Dlouhý vývoj - na velmi vysoké úrovni poskytovaných služeb i spolehlivosti.
• Transakční zpracování - silná konzistence dat.
• Je-li silná konzistence podmínkou zpracování – SQL databáze je správná volba, není důvod hledat jiné řešení.
Pojem NoSQL:
• Systém databází s možností horizontálního i vertikálního škálování.
• NoSQL databázový systém (nevyužívá tabulky, jako je tomu u relačních databází, v tomto případě je cílem jednoduchost vzhledu a možnost horizontálního i vertikálního škálování.
• NoSQL je optimalizovanou databází, kdy jsou využívány klíče i hodnoty.
• Struktura ukládání dat je u NoSQL rovněž odlišná, často se jedná o struktury stromovou nebo grafovou.
• NoSQL databázové systémy získávají na stále větší popularitě, především pokud hovoříme o segmentu real-time web.
• Dosud ale nejsou tolik rozšířené, což je dáno především absencí podpory transakčního modelu ACID či neúplnou standardizací rozhraní. Navíc jsou pro některé firmy NoSQL databáze dosti nákladné.
• Různá algoritmická složitost operací při SQL a NoSQL
Vlastnosti NoSQL
- Nerelační
- Jednoduché rozhraní API
- Distribuovanost
Nerelační vlastnosti NoSQL
- NoSQL databáze se nikdy neřídí relačním modelem
- Nikdy neposkytují tabulky s plochými záznamy v pevných sloupcích
- Práce se samostatnými agregáty nebo BLOB
- Nevyžadují objektově-relační mapování a normalizaci dat
- Žádné složité funkce, jako jsou jazyky dotazů, plánovače dotazů, spojení referenční integrity, ACID
- Databáze NoSQL jsou buď bez schématu nebo mají uvolněná schémata
- Nevyžadují žádnou definici schématu dat
- Nabízejí heterogenní struktury dat ve stejné doméně
Jednoduché rozhraní API NoSQL
- Nabízejí snadno použitelná rozhraní pro ukládání a dotazování poskytnutých dat
- API umožňují metody zpracování a výběru dat na nízké úrovni
- Textové protokoly většinou používané s HTTP REST a s JSON
- Většinou se nepoužívá žádný standardní dotazovací jazyk
- Webové databáze, které fungují jako internetové služby
Distribuovanost NoSQL
• Více distribuovaných databází NoSQL
• Nabízejí automaticky škálovatelnost a schopnost zamezit selhání
• Koncept ACID může být často obětován pro škálovatelnost a propustnost
• Většinou neexistuje žádná synchronní replikace mezi distribuovanými uzly
• Asynchronní Multi-Master replikace, peer-to-peer, replikace HDFS
• Pouze zajištění případné konzistence
• Sdílená architektura “nothing”. To umožňuje
menší koordinaci a vyšší distribuci.
• V NoSQL není “nothing” sdílené.
ACID
- Koncept ACID je základem transakčního zpracování dosud nejvíce rozšířených a používaných relačních databází.
- ACID - skupina vlastností, které zaručují spolehlivé provádění databázových transakcí a konzistenci dat.
Atomicity - série modifikací databáze uskutečňující se během transakce je provedena celá nebo je databáze ponechána v původním stavu. Systém musí garantovat toto chováni v každé situaci včetně nečekaných poruch.
Consistency – každá transakce převede databázi z jednoho konzistentního stavu do druhého. Do databáze budou zapsána pouze data odpovídající integritním omezením.
Isolation – data měněná transakcí jsou ostatním uživatelům až do úspěšného ukončení transakce viditelná v původní podobě, jako byla před začátkem transakce.
Durability – změny v databázi vyvolané úspěšně ukončenou transakcí jsou trvale uloženy na persistentním úložišti.
Partitioning
- Technologie sloužící v relační databázi k fyzickému rozdělení rozsáhlých datových tabulek do menších částí na základě logického členění dat v tabulce.
- Části jsou nazývány partition
- Tato technologie umožňuje rychlejší manipulaci s tabulkami, jejichž velikost se pohybuje na hranici možností použitých systémových prostředků.
- Prakticky (a nejčastěji) bývá realizován rozdělením tabulky na více pevných disků, což představuje rozložení zátěže oproti stavu, kdy všechny požadavky musel obsluhovat pouze jeden disk.
- Důvodem může být kromě velikosti dat také požadavek na větší rychlost.
- Podle jakého klíče k rozdělení dojde, dovoluje většina databázových strojů s podporou partitioning, určit pomocí rozdělení podle určitého sloupce nebo jeho hašovací funkce.
Prtitioning (dělení, vlastnosti)
Horizontální partitioning / Vertikální partitioning
Statický / Dynamický
Vlastnosti:
Užitečnost partitioningu vyplývá z možnosti pracovat
pouze s relevantní částí tabulky:
• Rozdělená tabulka se pak ukládá do více souborů, z nichž každý může být uložen na jiném disku - to je vhodné především u velkých tabulek jako jsou faktové tabulky v datovém skladu.
- Procesy, které hromadně mění data v tabulce, jsou řádově rychlejší - vycházejí ze způsobu členění tabulky do partitions - například u mazání starých dat (příkazem DELETE jazyka SQL) může být tento rozdíl oproti stejnému příkazu spuštěnému nad nerozdělenou velkou tabulkou až tisícinásobný.
- Agregační funkce spouštěné nad dělenou tabulkou může databázový server rozdělit podle rozdělení v definici partitioningu do více procesů, spustit každý takový proces na respektivním místě souborového systému, a nakonec získané mezivýsledky sloučit do celkového výsledku.
- Pokud to SŘBD dovoluje, může mít každá partition trochu jiné nastavení z pohledu její správy – dle příkladu u dynamického partitioningu je logické, aby partitions obsahující objednávky starší tří měsíců byly pouze pro čtení (read-only), což podstatně sníží časové a kapacitní nároky na zálohování celé tabulky.
- Podstatně se zvyšuje počet uživatelů, kteří mohou s tabulkou pracovat paralelně, aniž by se vzájemně omezovali - tato vlastnost se ještě umocňuje, pokud je databáze umístěna na víceprocesorovém serveru.
