Systém řízení báze dat: Porovnání verzí
(Přidání křížových odkazů) |
(přidání transakčního zpracování) |
||
Řádek 1: | Řádek 1: | ||
− | Systémy řízení bází dat (SŘBD), anglicky Database management systems (DBMS), 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émy řízení bází [[data|dat]] (SŘBD), anglicky Database management systems (DBMS), alternativně systémy řízení 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 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. | 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. | ||
Řá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í dat. Druhy DBMS souvisely s modely databází, nad kterými pracovaly. | + | Tak jak se vyvíjela počítačové technologie, vyvíjel se i způsob ukládání a zpracování [[data|dat]]. Druhy DBMS souvisely s modely databází, nad kterými pracovaly. |
===Hierarchická architektura=== | ===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.<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. | + | 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.<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=== | ||
Řádek 32: | Řádek 32: | ||
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" /> | 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í== | ||
+ | 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ě. | ||
+ | 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<ref name="ullman" />: | ||
+ | * 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 [[transakce|transakcí]] jsou perzistetní 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 [[databáze|databázi]] provádí více [[transakce|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. | ||
==Zdroje== | ==Zdroje== | ||
<references /> | <references /> |
Verze z 12. 6. 2014, 14:58
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. [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 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.[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.
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ě. 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[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 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ů[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.
Zdroje
- ↑ 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.
- ↑ 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 PATHAK, Nirupma. Database management system. 1st ed. Mumbai [India]: Himalaya Pub. House, 2008, 318 p. ISBN 9788184881394.