Systém řízení báze dat: Porovnání verzí
m (použití singuláru v názvu a definici namísto plurálu) |
(Doplnění citace a zapracování připomínek ze strany vyučujícího) |
||
| Řá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í [[data|dat]]. Druhy DBMS souvisejí s modely [[databáze|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 souvisejí s modely [[databáze|databází]], nad kterými pracovaly<ref name="raghu" />. Souvisí s [[datové struktury|datovými strukturami]]. |
===Hierarchická architektura=== | ===Hierarchická architektura=== | ||
| − | Hierarchické [[databáze]] byly první komerčně úspěšné [[databáze]]. Jak název napovídá, [[data]] v [[databáze|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áze|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=== | ||
| Řádek 28: | Řádek 28: | ||
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 <ref name="ullman" /> a převládají dodnes. Jednotlivé záznamy jsou v [[relační databáze|relační databázi]] uloženy v tabulkách. Každý záznam v tabulce má ta samá pole. <ref name="nirupma" /> | 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 <ref name="ullman" /> a převládají dodnes. Jednotlivé záznamy jsou v [[relační databáze|relační databázi]] uloženy v tabulkách. Každý záznam v tabulce má ta samá pole. <ref name="nirupma" /> | ||
===Objektově orientovaná architektura=== | ===Objektově orientovaná architektura=== | ||
| − | 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. | + | 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=== | |
Dalším pojmem je ještě objektově relační model, ve kterém je k relační [[databáze|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áze|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 [[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ě. | + | 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. | ||
* Peníze z prvního účtu se odečtou a nepřičtou na druhý - zmizí. | * Peníze z prvního účtu se odečtou a nepřičtou na druhý - zmizí. | ||
| Řádek 40: | Řádek 41: | ||
Proto se takové operace združují do [[transakce|transakcí]], které mají vlastnosti označované zkratkou ACID<ref name="ullman" />: | Proto se takové operace združují do [[transakce|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. | + | * '''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. | + | * '''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. | + | * '''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. | + | * '''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. | 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 2. 7. 2014, 12:40
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 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
- ↑ 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.
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
