Systém řízení báze dat

Systémy řízení bází dat (SŘBD), anglicky Database management systems (DBMS), alternativně systémy řízení databází, je software pro správu a údržbu kolekcí dat. Běžný DBMS umožňuje databáze vytvářet, dotazovat se jich, upravovat je a jinak je spravovat. Pojem je úzce spjatý s databází, je potřeba mezi nimi rozlišovat. Zatímco databází se rozumí kolekce dat, systém pro řízení databází zprostředkovává k takové databázi přístup a umožňuje její manipulaci.

Úkoly DBMS

Běžný DBMS by měl umožňovat následující úkoly:

• Tvorbu nových databází a definici jejich schémat, obvykle pomocí specializovaného jazyku DDL (data definition language)

• Provádění dotazů nad daty, jejich získávání a úpravu. Jazyk pro takovou komunikaci označujeme jako DML (data manipulation language).

• Ukládání velkého množství dat po delší časový úsek a poskytování efektivního přístupu k takovým datům.

• Zajišťovat trvanlivost a odolnost vůči chybám a výpadkům.

• Poskytovat přístup více uživatelům současně aniž by došlo k nežádoucímu chování a porušení integrity dat.

Vývoj a databázové modely

Tak jak se vyvíjela počítačové technologie, vyvíjel se i způsob ukládání a zpracování dat. Druhy DBMS souvisely s modely databází, nad kterými pracovaly.

Hierarchická architektura

Hierarchické databáze byly první komerčně úspěšné databáze. Jak název napovídá, data v databázi byla ukládána do hierarchické struktury. Ta se vyznačuje tím, že data mají posloupný řád, kdy jedna datová entita je nadřazená další. Všechny vztahy jsou jednosměrné, od nejvyšší entity, kořene nebo otce, po nejnižší entity, potomky. Vztahy mezi jednotkami jsou jeden ku více. Modely pak mají stromovou strukturu. Podobné uspořádání dat v současné době používají počítače pro ukládání souborů. Tento model byl rozšířen v 60. letech 20. století.

Síťová architektura

Síťová databáze byla dostupná jen o něco později než hierarchická. Po dlouhou dobu to byly jediné druhy užívaných databází a pracovaly pouze na mainframech. Síťová architektura byla organizována odlišně než hierarchická architektura a umožňovala vztahy více ku více, takže jedna entita mohla mít více otců. Navíc umožňovala rekurzi, takže mohla být otcem svému otci.

Relační architektura

Přelom nastal v roce 1970 prací Teda Codda, ve které navrhl organizovat data do relací. Datová struktura umožňovala rychlé řešení různých dotazů. Důležité ale bylo, že programátoři nemuseli znát přesně strukturu dat, ale měli k nim přístup přes abstrahovaný jazyk. V roce 1990 byly tyto systémy již normou a převládají dodnes. Jednotlivé záznamy jsou v relační databázi uloženy v tabulkách. Každý záznam v tabulce má ta samá pole.

Objektově orientovaná architektura

Jako reakce na nástup objektově orientovaného programování vznikají objektově orientované databáze, které umožňují ukládání dat ve stejném formátu, jako je využívá programátor v objektově orientovaném jazyce. Je tak vhodné pro ukládání složitých struktur i vztahů více ku více.

Dalším pojmem je ještě objektově relační model, ve kterém je k relační databázi přidána schopnost ukládat objekty.

Transakční zpracování

Pro zachování uspokojivého konzistentního stavu databáze se často operace s daty provádějí v takzvaných transakcích. Proto je podpora transakcí součástí velké části DBMS. Příkladem transakce je převedení peněz z jednoho účtu na druhý. To probíhá ve dvou krocích – odečtení peněz z účtu odesílatele a přičtení na účet příjemce. Je důležité, aby tyto operace proběhly najednou a izolovaně. Lze ukázat hned několik nežádoucích jevů, kterým se transakčnost operací snaží zabránit.

• Peníze z prvního účtu se odečtou a nepřičtou na druhý - zmizí.
• Peníze se přičtou k druhému účtu, ale nestrhnou z prvního.
• V průběhu zpracování někdo bude chtít zjistit stav peněz na obou účtech a to ve chvíli, kdy sice peníze zmizely z prvního účtu, ale ještě se nepřipsaly na druhý. Takový uživatel tedy bude mít špatnou informaci o současném stavu.

Proto se takové operace združují do transakcí, které mají vlastnosti označované zkratkou ACID:

• Atomicita – provedou se všechny operace transakce, nebo neproběhne ani jedna. V případě neúspěchu některého z kroků se předchozí změny během transakce vrátí do původního stavu.
• Konzistence (Consistency) – po provedení transakce se databáze nachází v konzistetním stavu. V našem příkladu to třeba znamená, že žádné peníze nezmizely ani nepřibyly, aniž by k tomu byl důvod.
• Izolace – v průběhu jedné transakce nemůže ke zpracovávaným datům přistupovat nikdo další, protože by mohl získat data v nekonzistentním stavu.
• Durabilita – všechny změny jednou provedené úspěšnou transakcí jsou perzistetní a nebudou ztraceny.

K podpoře transakčního zpracování provádí DBMS několik podpůrných úkolů. Všechny operace jsou zaznamenávány do transakčního logu aby bylo dosaženo trvanlivosti provedených změn v případě havárie systému. Je kontrolován současný (konkurenční) přístup více uživatelů, protože typicky se v databázi provádí více transakcí najednou. Toho se dosahuje systémem takzvaných zámků, které zamykají data, nad kterými probíhají transakce. Třetím úkolem je řešit krajní stavy, kdy se transakce zámky navzájem zablokují tak, že nemůže proběhnout ani jedna. V takovém případě musí systém zasáhnout zrušením alespoň jedné z nich.