Systém řízení báze dat: Porovnání verzí
| Řádek 1: | Řádek 1: | ||
'''Systém řízení bází [[data|dat]]''' (SŘBD), anglicky Database management system (DBMS), alternativně systém řízení [[databáze|databází]], je [[software]] pro správu a údržbu kolekcí dat. <ref name="raghu">RAMAKRISHNAN, Raghu a Johannes GEHRKE. <i>Database management systems</i>. 3rd ed. Boston: McGraw-Hill, c2003, xxxii, 1065 p. ISBN 00-711-5110-9.</ref> | '''Systém řízení bází [[data|dat]]''' (SŘBD), anglicky Database management system (DBMS), alternativně systém řízení [[databáze|databází]], je [[software]] pro správu a údržbu kolekcí dat. <ref name="raghu">RAMAKRISHNAN, Raghu a Johannes GEHRKE. <i>Database management systems</i>. 3rd ed. Boston: McGraw-Hill, c2003, xxxii, 1065 p. ISBN 00-711-5110-9.</ref> | ||
| − | Běžný DBMS umožňuje [[databáze]] vytvářet, dotazovat se jich, upravovat je a jinak je spravovat. Pojem je úzce spjatý s | + | 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== | ==Úkoly DBMS== | ||
| Řádek 7: | Řádek 7: | ||
</ref>: | </ref>: | ||
| − | * Tvorbu nových | + | * 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]]). | * Provádění dotazů nad daty, jejich získávání a úpravu. Jazyk pro takovou komunikaci označujeme jako DML ([[data manipulation language]]). | ||
| Řádek 18: | Řádek 18: | ||
==Vývoj a databázové modely== | ==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í | + | Tak jak se vyvíjela počítačové technologie, vyvíjel se i způsob ukládání a zpracování dat. Druhy DBMS souvisejí s modely databází, nad kterými pracovaly<ref name="raghu" />. Souvisí s [[datové struktury|datovými strukturami]]. |
===Hierarchická architektura=== | ===Hierarchická architektura=== | ||
| − | Hierarchické | + | 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í [[Datové struktury |stromovou strukturu]].<ref name="mattison">MATTISON, Rob. <i>Understanding database management systems</i>. 2nd ed. New York: McGraw-Hill, c1998, xxxi, 666 p. ISBN 00-704-9999-3. |
</ref> 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í. | </ref> 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á architektura=== | ||
| − | Síťová | + | 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 [[mainframe|mainframech]]. Síťová architektura byla organizována odlišně než hierarchická architektura a umožňovala vztahy více ku více<ref name="nirupma">PATHAK, Nirupma. <i>Database management system</i>. 1st ed. Mumbai [India]: Himalaya Pub. House, 2008, 318 p. ISBN 9788184881394. |
</ref>, takže jedna entita mohla mít více otců. Navíc umožňovala rekurzi, takže mohla být otcem svému otci. | </ref>, 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=== | ===Relační architektura=== | ||
| Řádek 30: | Řádek 30: | ||
Jako reakce na nástup [[objektově orientované programování|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. <ref name="nirupma" /> | Jako reakce na nástup [[objektově orientované programování|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. <ref name="nirupma" /> | ||
===Objektově relační architektura=== | ===Objektově relační architektura=== | ||
| − | Dalším pojmem je ještě objektově relační model, ve kterém je k relační | + | 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. <ref name="nirupma" /> |
==Transakční zpracování== | ==Transakční zpracování== | ||
| − | Pro zachování uspokojivého konzistentního stavu | + | Pro zachování uspokojivého konzistentního stavu databáze se často operace s daty provádějí v takzvaných [[transakce|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ě.<ref name="mattison" /> |
Lze ukázat hned několik nežádoucích jevů, kterým se transakčnost operací snaží zabránit. | Lze ukázat hned několik nežádoucích jevů, kterým se transakčnost operací snaží zabránit. | ||
| Řádek 41: | Řádek 41: | ||
Proto se takové operace sdružují do transakcí, které mají vlastnosti označované zkratkou ACID<ref name="ullman" />: | Proto se takové operace sdružují do transakcí, které mají vlastnosti označované zkratkou ACID<ref name="ullman" />: | ||
| − | * '''Atomicita''' – provedou se všechny operace, | + | * '''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 konzistentní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. | * '''Konzistence''' (Consistency) – po provedení transakce se [databáze]] nachází v konzistentní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 | + | * '''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 persistentní a nebudou ztraceny. | * '''Durabilita''' – všechny změny jednou provedené úspěšnou transakcí jsou persistentní a nebudou ztraceny. | ||
| − | K podpoře transakčního zpracování provádí DBMS několik podpůrných úkolů<ref name="ullman" />. 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 | + | K podpoře transakčního zpracování provádí DBMS několik podpůrných úkolů<ref name="ullman" />. 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. |
==Odkazy== | ==Odkazy== | ||
Verze z 10. 3. 2016, 16:32
Systém řízení bází dat (SŘBD), anglicky Database management system (DBMS), alternativně systém řízení databází, je software pro správu a údržbu kolekcí dat. [1] 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.
Obsah
Úkoly DBMS
Běžný DBMS by měl umožňovat následující úkoly[2]:
- 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 souvisejí s modely databází, nad kterými pracovaly[1]. Souvisí s datovými strukturami.
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.[3] 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[4], 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 [2] 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. [4]
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. [4]
Objektově relační architektura
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. [4]
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ě.[3]
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 sdružují do transakcí, které mají vlastnosti označované zkratkou ACID[2]:
- 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 konzistentní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 persistentní a nebudou ztraceny.
K podpoře transakčního zpracování provádí DBMS několik podpůrných úkolů[2]. 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.
Odkazy
Reference
- ↑ 1,0 1,1 RAMAKRISHNAN, Raghu a Johannes GEHRKE. Database management systems. 3rd ed. Boston: McGraw-Hill, c2003, xxxii, 1065 p. ISBN 00-711-5110-9.
- ↑ 2,0 2,1 2,2 2,3 ULLMAN, Jeffrey D a Jennifer WIDOM. A first course in database systems. 3rd ed. Upper Saddle River, NJ: Pearson/Prentice Hall, c2008, xxi, 565 p. ISBN 01-360-0637-X.
- ↑ 3,0 3,1 MATTISON, Rob. Understanding database management systems. 2nd ed. New York: McGraw-Hill, c1998, xxxi, 666 p. ISBN 00-704-9999-3.
- ↑ 4,0 4,1 4,2 4,3 PATHAK, Nirupma. Database management system. 1st ed. Mumbai [India]: Himalaya Pub. House, 2008, 318 p. ISBN 9788184881394.
Související články
Klíčová slova
systém řízení databází, databáze
Text je dostupný pod licencí Creative Commons Uveďte autora 3.0 Česko při dodržení případných autorských práv a dalších podmínek
© 2013 ISSN: 2336-5897
