zpět: [[Bakalářská státnice - Informatika - Základy informatiky - obor Správa počítačových systémů]]
zdroje:
* slidy k přednáškám [http://urtax.ms.mff.cuni.cz/skopal/DBI025.htm datázové systémy] (Tomáš Skopal)
* článek [http://interval.cz/clanky/databaze-a-jazyk-sql/ Databáze a jazyk SQL] (Interval.cz)
== Podstata a architektury DB systémů ==
?? co přesně zde má být? ER a relační model možná ne?
* databáze, systém řízení báze dat (SŘDB)
* ER modelování
** entity a vztahy, entitní typy, vztahové typy, slabý entitní typ, atributy, identifikátory
* relační model
** integritní omezení
** nadklíč, klíč, cizí klíč
** tabulky, řádky, sloupce, schéma tabulky, schéma relační databáze
** převod ER -> relační model
** relace, domény (typy atributů)
** funkční závislosti
** klíčový atribut, neklíčový atribut
** Armstrongova pravidla
** funkční uzávěr
** pokrytí, minimální pokrytí, redundantní atribut, atributový uzávěr
== Normální formy ==
* cílem je především odstranění redundance dat a tím zajištění jejich integrity
* '''1NF''' - každý atribut schématu je elementárního typu a je nestrukturovaný
** tj. tabulka je plochá - dvourozměrné pole, žádné stromy ani grafy
* '''2NF''' - neexistují částečné závislosti neklíčových atributů na klíči
** tj. nějaký atribut nesmí záviset pouze na části klíče -> rozdělit tabulku na dvě
* '''3NF''' - žádný neklíčový atribut není tranzitivně závislý na žádném klíči
** typická závislost: Firma -> PSČ -> Sídlo (rozdělíme dle tranzitivity na tabulky Firma+PSČ a PSČ+Sídlo)
* '''BCNF''' (Boyce-Coddova NF) - každý atribut je závislý na klíči
** tj. žádný samostatný atribut nesmí záviset na něčem jiném než na celém klíči
Další info: [http://en.wikipedia.org/wiki/Database_normalization Database normalization] (Wiki en) - kdyby někdo trval na tom, že chce znát 4NF, 5NF, 6NF a další :-)
== Referenční integrita ==
* pomáhá udržovat vztahy v relačně propojených databázových tabulkách, zabraňuje vzniku nekonzistentních dat
* kontrola přípustných hodnot
* kontrole existence položky s daným klíčem v druhé tabulce (podle cizího klíče)
chování při porušení integrity:
* hlášení chyby, pokud není nastavena jiná akce
* ON UPDATE, ON DELETE - podmínka spuštění akce
* CASCADE - kaskádová aktualizace/smazání
* SET NULL
* SET DEFAULT
* NO ACTION
zdroje:
* [http://cs.wikipedia.org/wiki/Referen%C4%8Dn%C3%AD_integrita Referenční integrita] (Wiki cs)
== Transakční zpracování, vlastnosti transakcí, uzamykací protokoly, zablokování ==
Požadované vlastnosti transakcí ('''ACID'''):
* '''Atomicity''' - transakce se provede buď celá nebo vůbec
* '''Consistency''' - databáze je před i po transakci konzistentní
* '''Isolation''' - souběžné transakce o sobě neví, navzájem se neovlivňují
* '''Durability''' - změny jsou po skončení transakce trvale uloženy v databázi
* úspěšné ukončení transakce - '''COMMIT'''
* neúspěšné
** uživatelský '''ABORT'''
** vynucený ABORT (porušení integrity, neexistující objekt, ...)
** pád systému
* architektura transakcí v SŘBD:
** aplikační program
** manažer transakcí
** rozvrhovač transakcí (scheduler)
** manažer dat
* sériový rozvrh
* prokládání transakcí
* uspořádatelný rozvrh (serializovatelný)
* konflikty WR (čtení nepotvrzených dat), RW (neopakovatelné čtení), WW (přepsání nepotvrzených dat)
* konfliktově uspořádatelný rozvrh, precedenční graf
* (ne)zotavitelný rozvrh
* exkluzivní a sdílené zámky
* uváznutí (deadlock, zablokování), detekce uvzáznutí (waits-for graf), konverze zámků, prevence uváznutí
* fantom
* ARIES - algoritmus pro zotavení po havárii - analysis, redo, undo
uzamykací protokoly:
* '''2PL''' (dvoufázový) - nelze požadovat zámek na entitu, pokud již nějaký zámek na ni transakce měla
* '''S2PL''' (striktní dvoufázový) - všechny zámky uvolněny až při ukončení transakce
* konzervativní 2PL - všechny zámky na začátku transakce - nepoužívané
* '''optimistické řízení''' - třífázový optimistický protokol (lokální datový prostor)
* '''časová razítka'''
There are some fascinating clnsiog dates in this article however I don't know if I see all of them middle to heart. Theres some validity however I will take hold opinion till I look into it further. Good article , thanks and we would like extra! Added to FeedBurner as properly
== Vícevrstevné architektury ==
(bez záruky, nenalezeny pořádné zdroje)
* centralizované systémy
** klient/server monoliticky - všechny služby soustředěny na serveru, klient pouze terminál
** klient/server s rozdělenou logikou - prezentační služby a logika u klienta
** třívrstvá architektura:
*** klient - prezentační služby
*** aplikační server - logika aplikace a dat
*** databázový server - datové služby
*** výhody/nevýhody: pružnější rozdělení práce, škálování (více serverů), klientský SW může být hloupější (snadný upgrade nebo není vůbec nutný), centralizace dat -> lepší ochrana
** n-vrstvá architektura: ještě podrobnější rozdělení logických celků
* distribuované systémy
** fyzické uložení na více počítačích, replikace
zdroje:
* [http://student.cvut.cz/cwut/index.php/Architektury_datab%C3%A1zov%C3%BDch_syst%C3%A9m%C5%AF Architektury databázových systémů] (ČWUT)
* [http://www.fit.vutbr.cz/study/courses/DSI/public/pdf/nove/10_clsrv.pdf Architektura klient/server a třívrstvá architektura] (J. Zendulka, VUTBR)
fQj7pj , [url=http://ribgfsuijtkf.com/]ribgfsuijtkf[/url], [link=http://ssrikaribwee.com/]ssrikaribwee[/link], http://rdoxqezyubbk.com/
k9d2Y5 , [url=http://ophrmxdmutjl.com/]ophrmxdmutjl[/url], [link=http://cxnjiivzqtxu.com/]cxnjiivzqtxu[/link], http://ldtayvtzspcs.com/
