1. Databázové systémy, definice, struktura

Transkript

1 I SZ DB Databázvé systémy, definice, struktura Existují 2 základní p ístupy ke zpracvání dat: Subrv rientvaný p ístup Histricky nejstarší zp sb. Prgram, který zpracvává data má svá vlastní data. Dnes se tent zp sb pužívá v aplikacích, které nejsu databázvé (nap. výp ty). P i subrv rientvaném p ístupu se pužívají r zné rganizace dat. Každý takvý prgram musí mít v sb p ístupvý mechanismus k dat m, t je velká nevýhda, která bnáší hdn práce. Další prblémy: Izlace dat Subr bsahuje základní strukturu subr záznam plžka, ale na úrvni dat nelze pdchytit vazbu mezi subry. Duplicita dat Více aplikací pracuje se stejnými daty, ale prtže aplikace vyžadují každá svje vlastní data, musí se data duplikvat. Závislst: data prgramy Databázvý p ístup Odstra uje nevýhdy subrv rientvanéh p ístupu. Definice dat je prvedena mim aplika ní prgramy. Data mhu být ulžena nezávisle na aplika ním prgramu. V aplika ních prgramech není zabudván mechanismus p ístupu k dat m. Základní pjmy: Banka dat rganiza ní frma systému zpracvání dat zahrnující bázi dat a systém ízení báze dat Báze dat mnžina subr a jejich ppisu, které jsu navzájem v ur itém lgickém vztahu a jsu spravvané S BD Systém ízení báze dat (S BD), databáze managment system (DBMS) prgramvý systém, který databázi zabezpe uje, umž uje definvání struktury dat, ukládání dat, výb r dat, chrana dat, kmunikace mezi uživatelem a systémem Pžadavky kladené na databázi Neredundantnst eliminace zbyte ných duplicit Vícenásbná využitelnst ke stejným dat m m že p istupvat více uživatel (pdle právn ní) Integrita dat databáze bsahuje prst edek, který zamezí tmu, aby ulžená data byla ve spru (neknzistentní)

2 I SZ DB1 2 Nezávislst dat zm na struktury v datech nevyvlá zm ny v aplika ních prgramech, uživatelské prgramy v bec neví, kde jsu data ulžena Datvý mdel databáze by m la umžnit implementvat libvlný datvý mdel S BD (DBMS) definvání dat (DDL data definitin language) uživatel m že definvat datvé typy a struktury a m že ur vat mezující pdmínky prst edky pr ukládání, zm nu, vymazání a vyhledávání dat, jsu zna vány jak DML (data manipulatin language), existují dva typy jazyk DML: prcedurální zpracvávají data záznam p záznamu a ur ují, jak pžadvaná data vybrat neprcedurální pracují s mnžinu záznam, ppisují jaká data vybrat, SQL bezpe nst systému, p ístupvá práva vzdálený p ístup více uživatel, dnes je S BD nej ast ji nep etržit spušt n jak démn (na Unixu) neb jak služba (ve Windws NT) a na ur itém scketu ekává pžadavky klient, na tyt pžadavky pak dpvídá, mdel klient/server, prt se také S BD nazývá databázvý server bnva systému p chyb umž ují uživateli p ístup k ppisu dat p íklady S BD: Oracle, MS SQL Server, Sybase, Infrmix, Prgress, InterBase, MySQL, msql, PstgreSQL

3 I SZ DB Databázvé systémy, základní pjmy (klí atd.) Banka dat rganiza ní frma systému zpracvání dat zahrnující bázi dat a systém ízení báze dat Báze dat mnžina subr a jejich ppisu, které jsu navzájem v ur itém lgickém vztahu a jsu spravvané S BD Systém ízení báze dat (S BD), database managment system (DBMS) prgramvý systém, který databázi zabezpe uje, umž uje definvání struktury dat, ukládání dat, výb r dat, chrana dat, kmunikace mezi uživatelem a systémem Databázvé tabulky tabulka slupec (název slupce) ádek hdnta Primární klí identifikátr ádku, jednzna n identifikuje daný ádek, má zárve minimální délku, m že t být 1 atribut neb m že být slžený z více atribut Cizí klí primární klí pužitý v další tabulce pr ur ení vazeb mezi tabulkami, cizí klí jak zprst edkvání vazby d jiné tabulky se bude vždy skládat ze stejných slupc jak primární klí Integrita dat Pd integritu neb knzistencí rzumíme fakt, že data v rn zbrazují reálný stav, který ppisují, nejsu ve spru, nic nechybí. Základním p edpkladem udržení dat v knzistentním stavu je kvalitn navržená datvá základna. Indexy Pmcné ddate né infrmace, které služí zejména pr zrychlení zpracvání našich pžadavk. SQL (structured query language) P íkazy jazyka SQL jsu len ny d n klika skupin: DDL, DML, správa tabulek, index a jiných databázvých bjekt, nastavvání parametr DBMS, správa p ístupvých práv uživatel. Mezi jedntlivými DBMS jsu mírné dlišnsti. Jazyk SQL byl navržen jak tzv. neprcedurální jazyk, v p íkazech ppisuje, c chce získat, a ne jak (pstup, prceduru) t chceme získat. Liší se tak d v tšiny prgramvacích jazyk, které jsu prcedurální a ve kterých vždy ppisujeme p esný pstup th, c se má prvést. Nejpužívan jší p íkazy: SELECT INSERT UPDATE DELETE CREATE TABLE DROP TABLE Transakce Jedním ze základních prblém pr udržení knzistence dat v databázi je situace, kdy b hem zpracvání p íkazu djde k nestandardnímu ukn ení práce s databází. Jeh p í inu m že být nap íklad fyzická chyba za ízení p íta e neb výpadek elektrickéh prudu. Nastane-li tat chyba b hem p íkazu, který aktualizuje hdnty v databázi, stávají se data neknzistentní zvýšení platu se prvedl puze u ásti zam stnanc, a ne u všech, jak byl zamýšlen; byl vymazán zam stnanec z tabulky zam stnanc, ale již se nestihl vymazat všechny jeh pd ízené záznamy (výplaty,

4 I SZ DB1 4 ešené úkly ), klasika p evdy pen z v bance apd. Z t cht d vd byl vytv en kncept transak níh zpracvání. Transakce je ned litelný lgický celek, který bude bu prveden celý, neb se neprvede žádná jeh ást. Transakce se skládá z SQL p íkaz, které jsu pstupn vyknávány. Od za átku transakce až d jejíh ukn ení p íkazem COMMIT jsu všechny zm ny prvedené v datech uschvány, aby byl mžné v libvlném kamžiku prvést návrat d stavu, který byl na za átku transakce. Djde-li p ed ukn ením transakce k chyb (nap. vlivem výpadku prudu), jsu p i p tvném spušt ní databáze všechna data uvedena d stavu, v jakém se nacházela na za átku transakce. Nem že se tedy stát, aby se databáze dstala d neknzistentníh stavu tím, že by se prvedl puze p íkaz vymazání zam stnance z tabulky zam stnanc a již se nestihl prvést vymazání všech statních, na n j se dkazujících záznam. Prcesu, který prvede návrat ke stavu na p átku transakce, se íká drlvání (z anglickéh rllback). Odrlvání je mžné vyvlat kdykliv p ed ukn ením transakce pmcí p íkazu ROLLBACK. Zadáním p íkazu COMMIT je aktuální transakce ukn ena a všechny dsud prvedené zm ny jsu natrval ulženy d databáze. V tmt kamžiku za íná nvá transakce, která bude ukn ena dalším zadáním p íkazu COMMIT. P zadání p íkazu COMMIT již není mžný návrat d stavu, ve kterém byla data na za átku transakce. Žurnál speciální subr, d kteréh se ukládají zm ny (v pdstat transakce) prvedené v tabulkách, becn bsahuje identifikátr transakce, identifikátr bjektu, kd transakci prvedl, as prvedení, nvá hdnta bjektu, stará hdnta bjektu (v n kterých p ípadech) Rzší ení jazyka SQL, prcedury Jazyk SQL se neustále vyvíjí a tv rci databázvých systém se snaží neustále reagvat na pžadavky uživatel a tv rc databázvých aplikací. Mezi tat rzší ení pat í mžnst definice prcedur jak blku SQL p íkazu neb celé prcedury p i vzniku ur ité událsti. Z hlediska jazyka SQL se jedná prušení jeh základníh principu. Jazyk SQL je navržen jak neprcedurální jazyk, kterým ppisujeme c chceme a ne, jak t chceme ud lat. Existují situace, kdy je vhdné pužít neprcedurální jazyk, a napak situace, pr které se více hdí jazyk prcedurální. Prt byly prcedury p idány d databázvých systém a m žeme je zejména p i vytvá ení databázvých aplikací pužívat su asn s p íkazy jazyka SQL. Trigger Trigger je SQL p íkaz neb prcedura, která je spušt na p i vzniku ur ité událsti (prt název trigger anglicky spuš ). Tut událstí m že být p idání ádku d tabulky, zm na hdnt ve slupci neb vymazání ádku z tabulky. Pmcí trigger m žeme ešit zajišt ní integrity dat v p ípad, že databázvý systém neumž uje její zajišt ní autmaticky neb pt ebuje prvést ddate né akce. Definice trigger je zatím puze v p ipravvaném návrhu standardu SQL3. Prt se m žeme setkat s velkými dlišnstmi jejich syntaxe mezi r znými databázvými systémy. P ístupvá práva Pracuje-li s databází více uživatel, není žáducí, aby všichni mhli prvád t v databázi zm ny, p ípadn, aby m li p ístup ke všem infrmacím ulženým v databázi. P ístupvá práva se týkají vždy jednh databázvéh bjektu (tabulky, phledy apd.) a knkrétníh uživatele. Rzlišujeme dv skupiny p ístupvých práv:

5 I SZ DB1 5 práv na tení práv na zápis (aktualizaci) Autmaticky jsu všechna práva p id lena uživateli, který bjekt (nap. tabulku) vytv il. Ten má zárve p id lvat tat práva dalším uživatel m, v etn práva na další p id lvání vlastn ných práv. Práva se p id lují pmcí p íkazu GRANT a dejmut je m žeme pmcí p íkazu REVOKE. Slvník dat Slvník dat (z anglickéh data dictinary ) ppisuje strukturu všech bjekt ulžených v databázi. Jsu zde ulženy infrmace existujících tabulkách a jejich slupcích, ppis mezení pr data v tabulkách, ppis definvaných index a další charakteristiky dat pužívané pr zrychlení zpracvání p íkaz. Jednu z pdmínek rela ních databázvých systému je, že i tyt infrmace jsu ulženy v rela ních tabulkách a jsu dsažitelné pmcí jazyka SQL. V každém databázvém systému se prt m žete setkat s r zným p tem tzv. systémvých tabulek. Z našeh hlediska se jedná nrmální tabulky a m žeme zjistit jejich bsah pmcí p íkazu SELECT. Systémvé tabulky sice m žeme íst, ale bývá zakázán v nich údaje m nit. Názvy systémvých tabulek a jejich ppis jsu su ástí dkumentace ke každému databázvému prst edí.

6 I SZ DB Databázvé systémy, vlastnsti V tét tázce se dá pužít v tšina v cí z 1 a 2. Nejd ležit jší v ci jsu uvedeny ješt jednu. Je p idán p ehled zp sb rganizace dat. Pžadavky kladené na databázi Neredundantnst eliminace zbyte ných duplicit Vícenásbná využitelnst ke stejným dat m m že p istupvat více uživatel (pdle právn ní) Integrita dat databáze bsahuje prst edek, který zamezí tmu, aby ulžená data byla ve spru (neknzistentní) Nezávislst dat zm na struktury v datech nevyvlá zm ny v aplika ních prgramech, uživatelské prgramy v bec neví, kde jsu data ulžena Datvý mdel databáze by m la umžnit implementvat libvlný datvý mdel S BD (DBMS) definvání dat (DDL data definitin language) uživatel m že definvat datvé typy a struktury a m že ur vat mezující pdmínky prst edky pr ukládání, zm nu, vymazání a vyhledávání dat, jsu zna vány jak DML (data manipulatin language), existují dva typy jazyk DML: prcedurální zpracvávají data záznam p záznamu a ur ují, jak pžadvaná data vybrat neprcedurální pracují s mnžinu záznam, ppisují jaká data vybrat, SQL bezpe nst systému, p ístupvá práva vzdálený p ístup více uživatel, dnes je S BD nej ast ji nep etržit spušt n jak démn (na Unixu) neb jak služba (ve Windws NT) a na ur itém scketu ekává pžadavky klient, na tyt pžadavky pak dpvídá, mdel klient/server, prt se také S BD nazývá databázvý server bnva systému p chyb umž ují uživateli p ístup k ppisu dat p íklady S BD: Oracle, MS SQL Server, Sybase, Infrmix, Prgress, InterBase, MySQL, msql, PstgreSQL Organizace dat: Sekven ní rganizace usp ádání pdle n jakéh klí e, 2 lgicky susední záznamy jsu susední i fyzicky Sekven n frekven ní rganizace p idán íta p ístupu k záznamu, záznamy s nej ast jším p ístupem jsu na za átku Indexsekven ní rganizace subr rzd len na blky, existuje speciální tabulka, která ukazuje na za átek blk,

7 I SZ DB1 7 vyhledávání sekven n, u velkých subr se m že pužít víceúrv vá tabulka index Rzptýlené rganizace prakticky nejrychlejší vyhledávání, mezi hdntu klí e a adresu ulžení existuje n jaký vztah, rzd lení: p ímé hdnta klí e p edstavuje p ím adresu ulžení nep ímé adresa = f(klí ), adresa = index v tabulce Seznamvá rganizace lgicky susední záznamy nejsu fyzicky susední, susednst je udržvána pmcí ukazatele, rzd lení: úplná seznamvá rganizace všechny záznamy v subru z et zeny d 1 et zu, tent et z ur uje p adí áste ná seznamvá rganizace více et z, bvykle z et zeny záznamy s n jaku stejnu vlastnstí, tent pstup je v databázích ast jší cyklická úplná rganizace cyklická áste ná rganizace vícenásbná seznamvá rganizace více et z, et zí se pdle více vlastnstí B-strmy, B*-strmy

8 I SZ DB Mdel vztah entit (ERA) Knceptuální mdel V tmt mdelu se snažíme ppsat p edm tnu blast pmcí všech entit, které se v ní vyskytují, a všech vztah mezi t mit entitami. V žádném p ípad však nebereme v úvahu pzd jší zp sb implementace a d jisté míry ani pzd jší mezení technlgickéh charakteru. Tím, že neuvažujeme pzd jším zp sbu implementace v knkrétním databázvém systému, m žeme v nvat veškeru energii na pchpení vlastníh prblému. Naknec získáme i becn platný ppis dané blasti, který m žeme pužít pr implementaci v dlišných databázvých systémech bez nutnsti p tvné analýzy. Cíle knceptuálníh mdelu: vytv it braz reality ve frmalizvané pdb nezávislý na pzd jším zp sbu implementace frmalizvat pžadavky uživatel a dát návrhá m snadn pchpitelný prst edek pr kmunikaci s uživateli, kterému budu i uživatelé rzum t vytv it pdklad pr návrh datvé základny E-R diagramy, ERA diagramy K frmálnímu ppisu reality služí, tzv. E-R diagramy z anglickéh Entity-Relatinship (d eštiny p ekládané jak diagramy entit a vztah ) neb ERA diagramy z anglickéh Entity- Relatinship-Attribute. V ERA diagramech jsu navíc u každé entity uvedeny i její atributy. Pr kreslení bu typ diagram existuje velké mnžství ntací, které se liší mnžstvím zna ek vyjad ující vlastnsti ppisvané blasti. Z praktických zkušenstí vyplývá, že ani nejvíce graficky bhaté ntace nedkážu ppsat všechny situace z reálnéh sv ta a je nutné dplnit každý diagram slvním ppisem. Velké mnžství zna ek pužívaných v diagramech navíc iní tyt diagramy nep ehlednými a zt žuje jejich pchpení. Prvky v datvých mdelech Entita Významný prvek ve zkumané blasti. Entitu m že být zam stnanec, dd lení, výplata apd. Entity se v diagramu vyzna ují jak bdélníky s vepsaným názvem entit. Atribut Vlastnst entity pdstatná z hlediska zkumané blasti. Atributem entity Zam stnanec bude jeh jmén, výše platu apd. Atributy nemusíme v diagramu vyzna vat. Sta í, budu-li uvedeny v textvém kmentá i k tmut diagramu. (V p ednáškách z DB1 se atributy zna ily h lku s kle kem na knci a ppiskem). Vztah Libvlný vztah, ve kterém mhu být dv (neb více) entit. V ta Zam stnanec pracuje v dd lení je vyjád ením vztahu pracuje v mezi entitami Zam stnanec a Odd lení. Vztah je vhdné pjmenvat, prtže mezi dv ma entitami m že existvat více r zných vztah. Vztah je v diagramu vyzna en jak ára, která spjuje entity vystupující v tmt vztahu.

9 I SZ DB1 9 Kardinalita vztahu E-R diagram Vidli ka na stran zam stnance ve vztahu s dd lením vyjad uje tzv. kardinalitu vztahu zam stnance s dd lením. Pd kardinalitu rzumíme p et výskyt bu entit, které se vztahu ú astní. Víme, že v jednm dd lení pracuje bvykle více zam stnanc. Naprti tmu jeden zam stnanec pracuje v jeden kamžik puze v jednm dd lení. Jedná se p íklad vztahu n:1 (n zam stnanc pracuje v jednm dd lení) neb pa n 1:n (v jednm dd lení pracuje n zam stnanc ). Typy kardinalit vztah : 1:1 Vztah, ve kterém na bu stranách vystupuje puze jeden bjekt dané entity. Tyt vztahy se v realit vyskytují puze z ídka a jejich existence v diagramu bývá n kdy zp sbena chybu v ppisu reality. P íkladem vztahu 1:1 m že být vztah manželé mezi entitu Muž a entitu Žena (v p ípad mngamní sple nsti) neb vztah t ídní u itel mezi entitami U itel a T ída. 1:n Na jedné stran je jediný bjekt, který je ve vztahu s jedním neb více bjekty na stran druhé. Jedná se typ vztahu, který se vyskytuje velmi ast. Krm již uvedenéh vztahu zam stnance a dd lení t je nap íklad vztah nad ízený pd ízený, zam stnanec výplata, ale také t ída žák. m:n Specifickým typem vztahu jsu vztahy, ve kterých vystupuje více bjekt na bu stranách. Ve vztahu zam stnanec úkl m že více zam stnanc ešit jeden úkl a zárve m že jeden zam stnanec ešit více úkl. Ntace kardinality vztahu Pvinnst výskytu Krm kardinality vztahu m žeme ješt rzlišvat pvinnst a vlitelnst jeh existence. Je nutné, aby každý zam stnanec byl za azen d ur itéh dd lení? Neb m že existvat zam stnanec, který v su asné db nepat í d žádnéh dd lení? Musí mít každý muž manželku a žena manžela? Pvinnst výskytu se m že zna it r zn. Obvykle se pužívá prázdných a plných zna ek (bvykle šipek), nap. prázdné kle k (vyjad uje vlitelnst na stran entity, která nemusí existvat). Zna ení se liší v jedntlivých CASE nástrjích.

10 I SZ DB1 10 Dekmpzice vztah m:n Vztah m:n je z hlediska další práce velmi kmplexní a je nutné pkusit se jeh zjedndušení. Ned láme tak puze kv li jeh implementaci na další úrvni návrhu, ale i pr p ípad, že v tmt vztahu je schvána další entita, která zatím naší pzrnst unikla. Su ástí tét entity mhu být i atributy, kterých jsme tušili, že existují, ale nev d li jsme, ke které entit je p i adit. Dekmpzicí vztahu m:n rzumíme vytv ení nvé, tzv. vazební entity, která bude mít vztahy typu n:1 na b p vdní entity vztahu m:n. Nv vzniklá entita ešitel úklu vyjad uje fakt, že zam stnanec m že být najednu ešitelem více úkl najednu a jeden úkl m že být ešen najednu více ešiteli. Su ástí tét entity mhu být atributy, které nelze p i adit žádné z entit Zam stnanec a Úkl. P íkladem je atribut ppisující hdncení zam stnance za dvedenu práci na daném úklu. Prtže zam stnanec m že pracvat na více úklech a být hdncen za každý jinak, nem že být tent atribut umíst n d entity Zam stnanec. Zárve nem že být umíst n ani d entity Úkl, prtže na úklu m že pracvat více zam stnanc. Jediným správným umíst ním atributu Hdncení je entita ešitel úklu, prtže se vztahuje vždy k dvjici {zam stnanec; úkl}. Pznámky: Autr Chan Vazba m že mít atribut, veškeré nesnáze s becn jším pjetím vazby v Chanv mdelu ešíme v nástrji CASE frmálním p evedením vazby na entitní mnžinu (nástrje CASE vazbu s atributy bvykle nepdprují) Obecn m že být vazba binární až n-ární. Prst edky CASE pdprují puze binární vazbu. P. ternární vazby u itel místnst t ída, atributem vazby bude as. Další p íklady ERA mdel viz. p ednášky z DB1.

11 I SZ DB Pravidla integrity, nrmální frmy Rela ní mdel dat ERA mdel se zabývá mdelem reálnéh sv ta. Rela ní mdel dat se zabývá mdelváním dat. Relace ERA mdelu je vztah mezi dv ma entitními mnžinami. Relace v rela ním mdelu dat je relace v matematickém pjetí, tj. pdmnžina kartézskéh su inu. Základní pjmy: Dména Mnžina hdnt stejnéh významvéh typu. Dménu m že být nap íklad v k neb p íjmení. Hdnty v dmén jsu stejnéh datvéh typu ísl, et zec znak, datum apd. Kartézský su in Mnžina usp ádaných dvjic [x, y] (becn n-tic [x 1, x 2,, x n ]), pr které platí, že (x A) a zárve (y B). P et prvk v kartézském su inu je dán p tem prvk v mnžin A, krát p et prvk v mnžin B. Relace Libvlná pdmnžina kartézskéh su inu. Relace m že být trvalá (jak nap. tabulka), dvzená (jak ur itý phled na relaci trvalu) neb d asná (puze v pam ti, nap íklad p i spjvání tabulek). Atribut Název dmény pr pužití v relaci. Atributem m že být nap íklad V k neb P íjmení definvané nad dménu hdnt typu ísl, resp. etzec znak. V suvislsti s pužitím tabulek hvíme míst atributu spíe slupci tabulky. Tabulka Zjedndušený a upravený phled na relaci. Nepvažujeme za dležité padí slupc. V tabulce nesmí být dva stejné ádky. Klí neb identifikátr Slupec neb skupina slupc v tabulce jednzna n identifikující ádek tabulky. Primární klí Klí, který má minimální délku. Cizí klí Slupec neb skupina slupc pužitá jak dkaz v jiné tabulce, než ve které tv í primární klí. Relaní schéma R(A 1, A 2,, A n ) STUDENT(jmén, p íjmení, rd. ísl, ísl studenta, adresa) klí je pdtržen Relaní schéma databáze R (R, I) R je mnžina všech rela ních schémat, I je mnžina všech integritních mezení. Operace rela ní algebry: sjedncení pr nik mnžinvý rzdíl kartézský su in

12 I SZ DB1 12 Sjedncení a pr nik m žeme prvést, když tabulky mají stejné rela ní schéma. Pr práci s daty byly ddefinvány další 3 perace: Prjekce Výb r slupc z relace (tabulky) A d relace (tabulky) B. Vybrané slupce jsu dané jmenným seznamem. Restrikce Výb r ádk z relace (tabulky) A d relace (tabulky) B na základ definvané pdmínky. Spjení tabulek Kartézský su in dvu tabulek. Prvky tabulky jsu ádky a výsledkem je tabulka bsahující všechny slupce z bu spjvaných tabulek. P et ádk výsledné tabulky je rven p tu ádk první tabulky krát p tu ádk druhé tabulky. Prtže mezi tímt velkým p tem ádku je mnh t ch, které nept ebujeme, kmbinuje se spjení tabulek s restrikcí. Omezující pdmínka se definuje v tšinu jak rvnst primárníh a cizíh klí e. Funkní závislst a nrmální frmy P i návrhu databáze se snažíme dstranit nep íjemné duplicity. Prblematika je dvzena d závislsti atribut. Nech A, B jsu atributy relace R. Budeme íkat, že atribut B funk n závisí na atributu A, jestliže pr všechny ppulace relace R platí pr libvlné n-tice u a v z relace R následující: u.a = v.a u.b = v.b Oznaujeme A B. Pmcí závislsti lze definvat klí. Je-li dána R(), je mnžina atribut a K, ptm K je klíem schématu R jestliže spluje dv vlastnsti: 1. K 2. K, K K, K Pevedení tabulek d nrmálních frem dstrauje prblémy, které vyplývají ze závislsti atribut. 1NF: Všechny kmpnenty n-tice z relace jsu atmické, atributem v relaci nesmí být pt relace. 2NF: Relace R je v 2NF, jestliže je v 1NF a jestliže každý atribut, který nepatí k žádnému klíi relace R siln závisí na klíi relace R. Def.: Nech v relaci R platí A B, íkáme, že B siln funkn závisí na A, jestliže neexistuje žádná vlastní pdmnžina A A (slženéh atributu A) takvá, že platí A B.

13 ISZ DB1 13 3NF: Relace R je v 2NF, jestliže je v 2NF a žádný atribut, který není slžku klíe relace R, není tranzitivn závislý na klíi relaci R. Def. tranzitivity: X Y a Y Z ptm také X Z BNF: Relace R se nachází v Byce-Cddv NF (BCNF), jestliže pr každu funkní závislst z X Y, kdy Y není v X, platí že X je nadmnžina njakéh klíe neb X je klíem v relaci R. 4NF: Relace R je v 4NF, jestliže je v 3NF a jestliže v pípad, že bsahuje multizávislst X Y, kde Y není pdmnžinu X a XY nezahrnuje všechny atributy R, pak X zahrnuje i klí relace R. Def.: íkáme, že v relaci R atribut Y multizávisí na atributu X, jestliže každá hdnta atributu X uruje njaku mnžinu hdnt atributu Y, a tat mnžina pitm nezávisí na hdnt jiných atribut relace R. Funkní závislst je speciálním pípadem multizávislsti, mnžina které se mluví v definici je jednprvkvá. Integritní mezení Je t subr pravidel, která musí být splnna, aby data v databázi mla smysl, tj. aby dpvídala situaci v reálném svt. Suasné SBD mají umžnit definvat integritní mezení suasn s definicí dat, na úrvni DDL. Hvíme 3 typech integritních mezení: entitní integrita dménvá integrita referenní integrita Entitní integrita pžadavek jednznané identifikace entity, pžadujeme aby systém neumžnil ulžit 2 stejné ádky d tabulky nrma SQL klívé slv UNIQUE, NOT NULL plžka musí být vyplnná, významv lze nahradit nvjším PRIMARY KEY Referenní integrita pdchycuje pvinnst výskytu ve vztahu mezi entitními mnžinami krektnst vztah mezi entitními mnžinami vazba 1:N, realizujeme ji penesením klíe z E 1 d E 2, v E 2 pak hvíme cizím klíi

14 ISZ DB1 14 Udržení ref. integrity Restriktivní zp sb nep ipustit zrušení ádky v E 1 pkud existuje v E 2 ádka na ní závislá, nep ipustit mdifikaci hdnty klí e v E 1 pkud je v E 2 jak cizí klí Kaskádvý zp sb dvést zm ny z E 1 d všech pd ízených entitních mnžin smazání záznamu, zm na hdnty primárníh klí e, tj. mažu plžku v E 1 musím smazat dpvídající plžky v E 2 na plžce v E 1 závislé FOREIGN KEY (garant) REFERENCES ucitel (cisl_ucitele) ON DELETE CASCADE ON UPDATE CASCADE Dsazení NULL pkud mažu ádek v E 1, pak v závislých entitních mnžinách dsadíme d hdnty klí e prázdnu hdntu NULL ON DELETE SET NULL ON UPDATE SET NULL Dménvá integrita mnžina hdnt, kterých m že atribut nabývat vý et hdnt, matematický p edpis SQL: CREATE TABLE ( pcet_kreditu INTEGER CHECK pcet_kreditu BETWEEN 1 AND 6 ) plat INTEGER CHECK plat > 0, priplatek INTEGER CHECK priplatek plat * 0,5 Prgramvé udržení integritních mezení, nástrje STORED PROCEDURE TRIGGER Ob dv se pužívají tehdy, když integritní mezení je pm rn kmplikvané, v tmt p ípad se ppíše skupinu p íkaz DML, skupina p íkaz se m že vyvlat nap. p idáním záznamu, zm nu záznamu atd., skupina p íkaz se prvede p ed neb p knkrétní peraci Ochrana integrity dat chrana prti ztrát dat transak ní zpracvání

15 I SZ DB1 15 P íkladu d Ktu e: Základní pjmy pt ebné pr pchpení Nrmálních frem: Funk ní závislst Máme relaci R a v ní dv mnžiny atribut A a B, pak existuje funk ní závislst B na A, jestliže jedné A- hdnt se p i adí nejvýše jedna B-hdnta. Máme tabulku, ve které evidujeme rzvrh malé vyské škly, kde každý p edm t je u en práv jedním u itelem a každý u itel je natlik vytížen, že u í jen jeden p edm t: P edm t U itel Kružek Místnst as Matematika Nvák A4-01 PC406 Út3 Matematika Nvák A4-01 UL411 P9 Matematika Nvák E3-15 PC406 Út3 Matematika Nvák E3-15 UL411 P9 D jepis SUKOVÁ S1-07 AM701 St5 D jepis SUKOVÁ A4-01 AM701 St5 D jepis SUKOVÁ S1-87 AM701 St5 D jepis SUKOVÁ K3-05 AM701 St5 {Místnst, as}» {U itel} {Místnst, as}» {P edm t} {U itel}» {P edm t} {P edm t}» {U itel} Z ukázky dat (relace) nelze dkázat, že platí n jaká funk ní závislst (nemusí být zbrazeny n které mžnsti, které ptm vedu k tmu, že funk ní závislst mezi ur itými mnžinami atribut neexistuje), ale napak negativní fakta mhu být z dané relace zjistitelná, tv í ttiž prtiklad. Kladná fakta vícemén ur íme z becných znalstí a pdmínek, které se danéh p ípadu týkají. Atribut Uitel je funkn závislý na mnžin atribut {Místnst-as}, prtže pr každu hdntu mnžiny atribut {Místnst-as} existuje nejvýše jedna hdnta atributu Uitel. T jinými slvy znamená, že v jedné místnsti ve stejnu dbu nemhu uit dva uitelé. Atribut Pedmt je funkn závislý na mnžin atribut {Místnst-as}. Atribut Pedmt je funkn závislý na atributu Uitel. T by becn platit nemusel prtže jeden uitel je schpen uit i více pedmt, ale mi t máme v úvdní pdmínce a tak t platí. Atribut Uitel je funkn závislý na atributu Pedmt. Ale atribut Uitel není funkn závislý na atributu Místnst, prtže v jedné místnsti je mžné uit becn nklik pedmt, pestže t z našich dat není na první phled vidt. Mže existvat samzejm výjimka, typu nap. chemické labrate, kde se bude uit jen chemie, ale becn t neplatí a t je dležité. Atribut Uitel není funkn závislý na atributu as. Atribut Uitel není funkn závislý na atributu Kružek. Atribut Pedmt není funkn závislý na atributu Kružek. Atribut Pedmt není funkn závislý na atributu Místnst. Atribut Pedmt není funkn závislý na atributu as. Atribut Kružek není funkn závislý na atributu Pedmt. Atribut Kružek není funkn závislý na atributu Uitel. Atribut Kružek není funkn závislý na atributu Místnst. Atribut Kružek není funkn závislý na atributu as. Atribut Místnst není funkn závislý na atributu Pedmt. Atribut Místnst není funkn závislý na atributu Uitel. Atribut Místnst není funkn závislý na atributu Kružek.

16 ISZ DB1 16 Atribut Místnst není funkn závislý na atributu as. Atribut as není funkn závislý na atributu Pedmt. Atribut as není funkn závislý na atributu Uitel. Atribut as není funkn závislý na atributu Kružek. Atribut as není funkn závislý na atributu Místnst. Multizávislst Máme relaci R a v ní dv mnžiny atribut A a B, pak existuje multizávislst B na A, jestliže jedné A-hdnt se p i adí n klik B-hdnt. Máme tabulku, ve které evidujeme mdely aut, v jaké zemi se vyráb jí a klik mají jejich mtry válc. Platí zde jedn pravidl: mdel se vyrábí ve všech státech ve všech verzích mtr. Mdel Zem P et válc Mustang USA 4 Mustang USA 6 Mustang Kanada 4 Mustang Kanada 6 Atribut Pet válc multizávisí na atributu Mdel. Tut tabulku lze rzd lit na dv tabulky: Mdel Zem Mustang USA Mustang Kanada 1:N Mdel P et válc Mustang 4 Mustang 6 Když nyní p idáme nap. mdel Škda vyráb ný v R se 4 válci, prjeví se t v p vdní i nvých tabulkách takt: Mdel Zem P et válc Mustang USA 4 Mdel Zem Mdel P et válc Mustang USA 6 Mustang Kanada 4 Mustang USA Mustang Kanada 1:N Mustang 4 Mustang 6 Mustang Kanada 6 Škda R Škda 4 Škda R 4 Když nyní za neme v R mdel Škda vyráb t i s 6 válci, prjeví se t v p vdní i nvých tabulkách takt: Mdel Zem P et válc Mustang USA 4 Mustang USA 6 Mustang Kanada 4 Mustang Kanada 6 Škda R 4 Mdel Zem Mustang USA Mustang Kanada Škda R 1:N Mdel P et válc Mustang 4 Mustang 6 Škda 4 Škda 6 Škda R 6 Když nyní za neme v Japnsku vyráb t mdel Škda, musíme h vyráb t se 4 válci i s 6 válci. T se prjeví v p vdní i nvých tabulkách takt: Mdel Zem P et válc Mdel Zem Mdel P et válc Mustang USA 4 Mustang USA 1:N Mustang 4 Mustang USA 6 Mustang Kanada Mustang 6

17 I SZ DB1 17 Mustang Kanada 4 Škda R Škda 4 Mustang Kanada 6 Škda Japnsk Škda 6 Škda R 4 Škda R 6 Škda Japnsk 4 Škda Japnsk 6 Tent rzklad je velice výhdný, prtže zmenšuje využívaný databázvý prstr a zrychluje prhledávání v databázi. Tent rzklad je p edm tem 4. nrmální frmy, kteru prbereme pzd ji. Pkud by neplatila naše pdmínka, tedy že by se v každé zemi nemuseli vyráb t mdely se všemi verzemi mtr (nap. Mustang se v Kanad vyrábí jen ve verzi 4 válcvé), ptm by nešl multizávislst a nebyl by mžný rzklad na dv tabulky. P i návrhu aplikace je tedy nutné se p ádn zamyslet, jaké mezující pdmínky máme a c s nimi dkážeme prvád t. Nrmální frmy: P íklad úpravy databázvéh schématu, aby vyhvval všem nrmálním frmám: Máme šklní rzvrh v tmt stavu: VÝUKA(ísl_uitele, Pedmt, Student, Za azení_u itele, Pracvišt _u itele, Budva_pracvišt, ROZVRH) ROZVRH(Den, as_d) ísl u itele P edm t Student Za azení u itele Pracvišt u itele Budva pracvišt ROZVRH U1 DB1 A97222 asistent KIV UK Út 09:00 U1 CPP E99444 asistent KIV UK Pá 15:00 U1 CPP A97222 asistent KIV UK Pá 15:00 U1 DB1 E99444 asistent KIV UK Út 09:00 U555 GRA H96777 dcent KEE PC t 14:00 Platí zde dv pravidla: Uitel uí více pedmt. Jestliže student navštvuje jeden uitelv pedmt, navštvuje i všechny statní jeh pedmty. P íkladem by mhla být t ída základní škly, kdy všichni žáci chdí d stejné t ídy a na všechny p edm ty je má ten samý u itel. Pracvišt je umístn vždy jen v jedné budv. Tabulka v atributu ROZVRH m že mít i n klik ádk. Relace R je v 1. nrmální frm (1NF), jestliže žádný atribut není relací. T že tabulka bsahuje atribut, který je zárve relací si m žeme také p edstavit tak, že zde máme spjení více údaj (nap. den a as), které budeme chtít pzd ji d lit a využívat samstatn (pkud nebudeme nikdy pt ebvat zvláš den neb as, tak se atribut/relaci nejedná). V našem p ípad relace VÝUKA bsahuje atribut ROZVRH, který je sám relací. Tt musíme dstranit. VÝUKA(ísl_uitele, Pedmt, Student, Za azení_u itele, Pracvišt _u itele, Budva_pracvišt, Den, as_d)

18 I SZ DB1 18 ísl u itele P edm t Student Za azení u itele Pracvišt u itele Budva pracvišt Den as d U1 DB1 A97222 asistent KIV UK Út 09:00 U1 CPP E99444 asistent KIV UK Pá 15:00 U1 CPP A97222 asistent KIV UK Pá 15:00 U1 DB1 E99444 asistent KIV UK Út 09:00 U555 GRA H96777 dcent KEE PC t 14:00 Relace R je v 2. nrmální frm (2NF), jestliže je v 1NF a jestliže každný atribut, který nepatí žádnému klíi relace R, siln závisí na klíi R. V našem p ípad v realaci VÝUKA atributy Za azení_u itele, Pracvišt _u itele a Budva_pracvišt siln závisí na atributu ísl_u itele. T vy ešíme rzpadem: VÝUKA(ísl_uitele, Pedmt, Student, Den, as_d) UITEL(ísl_uitele, Zaazení_uitele, Pracvišt_uitele, Budva_pracvišt) ísl uitele Pedmt Student Den as d U1 DB1 A97222 Út 09:00 U1 CPP E99444 Pá 15:00 U1 CPP A97222 Pá 15:00 U1 DB1 E99444 Út 09:00 U555 GRA H96777 t 14:00 N:1 ísl uitele Zaazení uitele Pracvišt uitele U1 asistent KIV UK U555 dcent KEE PC Budva pracvišt Relace R je v 3. nrmální frm (3NF), jestliže je v 2NF a jestliže žádný atribut, který není slžku klíe relace R, není tranzitivn závislý na klíi relace R. V našem pípad, prtže platí pravidl "pracvišt je umístn vždy jen v jedné budv", atribut Budva_pracvišt který není klíem (tranzitivn) závisí na atributu Pracvišt _u itele, který také není klíem a ten teprve závisí na klíi atributu ísl_u itele. Tranzitivnst = nezávisí pím na klíi, ale siln závisí na atributu, který také není klíem a ten teprve slab závisí na klíi. T je nutné dstranit: VÝUKA(ísl_uitele, Pedmt, Student, Den, as_d) UITEL(ísl_uitele, Zaazení_uitele, Pracvišt_uitele) PRACOVIŠT(Pracvišt, Budva_pracvišt) ísl uitel e Pedm t Student De n as d U1 U1 U1 U1 DB1 CPP CPP DB1 A E A E Út Pá Pá Út 09:0 0 15:0 0 15:0 0 09:0 0 N:1 ísl uitel e U1 Zaazen í uitele U555 dcent asistent KIV Pracvišt uitele KEE N:1 Pracvišt KIV KEE Budva pracvišt UK PC U555 GRA H t 14:0 0 Relace R je v 4. nrmální frm (4NF), jestliže je v 3NF a jestliže v pípad, že bsahuje multizávislst X->->Y, kde Y není pdmnžinu X a XY nezahrnují všechny atributy R, pak X zahrnuje i klí relace R. Prtže platí pravidl "Uitel uí více pedmt. Jestliže student navštvuje jeden uitelv pedmt, navštvuje i všechny statní jeh pedmty.", atribut Student multizávisí na atributu ísl_uitele. A díky tmu je mžné prvést následující úpravu: UITEL_UÍ_PEDMT(ísl_uitele, Pedmt, Den, as_d) UITEL_UÍ_STUDENTY(ísl_uitele, Student)

19 ISZ DB1 19 UITEL(ísl_uitele, Zaazení_uitele, Pracvišt_uitele) PRACOVIŠT(Pracvišt, Budva_pracvišt) ísl uitel e U1 U1 U555 Studen t A E H N:1 ísl uitel e Pedm t De n U1 DB1 Út U1 CPP Pá U555 GRA t as d 09:0 0 15:0 0 14:0 0 N:1 ísl uitel e U1 Zaaze ní uitele U555 dcent Prac. asistent KIV KE E N:1 Prac. Budv a KIV UK KE E PC Pzr: kdyby nap. student A97222 nestudval pedmt CPP nejednal by se už u multizávislst a rzklad by se neuskutenil. Relace R je v Byce-Cddv nrmální frm (BCNF), jestliže pr každu funkní závislst tvaru X->Y, kde Y není v X, platí že X je nadmnžinu njakéh klíe neb je X v R klíem. Píkladem mže být tt schéma: ADRESÁ(Mst, Ulice, PS). Atribut Ulice pitm pedstavuje název ulice, tedy název, který se mže vyskytvat v nklika mstech. Nalezneme zde dv funkní závislsti: Atribut PS je funkn závislý na mnžin atribut {Mst, Ulice} a atribut Mst je fukn závislý na atributu PS. Napak PS není funkn závislý na atributu Ulice, prtže jedna ulice mže mít nklik PS a také atribut PS není funkn závislý na atributu Mst, prtže mst mže mít více PS. Z th vyplývá, že mnžina atribut {Mst, Ulice} je klíem v tmt schématu. Klíem je všem i mnžina atribut {Ulice, PS}, prtže atribut Mst je funkn závislý na atributu PS a atribut Ulice není funkn závislý na atributu PS. Mžeme tedy evidvat msta splu s PS aniž bychm znali njaku ulici v mst. Pvdní schéma mžeme tedy pevést na SEZNAM_ULIC(ULICE, PS) a M STA(PS, M st). Tt schéma je již v BCNF. (Tent p íklad je erpán ze skript: Pkrný, Halaška - Databázvé systémy, Vybrané kapitly a cvi ení, VUT 1997) Je-li relace ve 4NF, je i v BCNF. Obrácen t neplatí. Je-li relace v BCNF, je i ve 3NF. Obrácen t neplatí. Další píklady úpravy schématu databáze dle nrmálních frem: Letadl - týdenní rzvrh let letadel: LET(ísl_letu, Odkud, Kam, ROZVRH) ROZVRH(Den, as) ísl letu Odkud Kam ROZVRH OK101 Praha Bratislava Út 09:00 Ne 16:10 OK101 Praha Bratislava St 14:00 OK101 Praha Bratislava S 18:00 OK800 K.V. Mskva t 08:00 OK800 K.V. Mskva Út 09:00 Tat tabulka nespl uje 1.NF, prtže tabulka Let bsahuje atribut ROZVRH, který je sám relací. Tt musíme dstranit: LET(ísl_letu, Odkud, Kam, Den, as) ísl letu Odkud Kam Den as

20 I SZ DB1 20 OK101 Praha Bratislava Út 09:00 OK101 Praha Bratislava Ne 16:10 OK101 Praha Bratislava St 14:00 OK101 Praha Bratislava S 18:00 OK800 K.V. Mskva t 08:00 OK800 K.V. Mskva Út 09:00 Realace LET není v 2.NF, prtže bsahuje atributy Odkud a Kam, které jsu siln závislé na atributu ísl_letu. LET(ísl_letu, Den, as) LINKA(ísl_letu, Odkud, Kam) ísl letu Den as OK101 Út 09:00 OK101 Ne 16:10 OK101 St 14:00 OK101 S 18:00 OK800 t 08:00 OK800 Út 09:00 N:1 ísl letu Odkud Kam OK101 Praha Bratislava OK800 K.V. Mskva Te už je schéma i v 3.NF, prtže nebsahuje žádný atribut, který není klíem a který by siln závisel na atributu, který také není klíem. Takže tím pr nás rzklad kní. Ptraviny v lednice: POTRAVINY_V_LEDNICE(árvý_kód, Sptebujte_d, Název, Typ_zkratka, Typ_název, Pet) árvý kód Sptebujte d Název Typ zkratka Typ název Pet Jgurt bílý DANONE 0,2 l JO Jgurt Jgurt bílý DANONE 0,2 l JO Jgurt Jgurt YOGOBELLA 0,5 l JO Jgurt Másl RAMA 0,5 kg MA Másl Másl PERLA 0,25 kg MA Másl 3 Tabulka POTRAVINY_V_LEDNICE je v 1.NF, prtže nebsahuje žádný atribut, který by byl relací (slžené atributy). Tabulka POTRAVINY_V_LEDNICE není ve 2.NF prtže bsahuje atributy Název, Typ_zkratka a Typ_název, které jsu siln závislé na atributu árvý_kód. Takže se nám schema rzpadne na dv tabulky. POTRAVINY_V_LEDNI CE(árvý_kód, Sptebujte_d, Pet) POTRAVINY(árvý_kód, Název, Typ_zkratka, Typ_název) árvý kód Sptebujte d Pet N:1 árvý kód Název Jgurt bílý DANONE 0,2 l Jgurt YOGOBELLA 0,5 l JO JO Typ zkratka Typ název Jgurt Jgurt Másl RAMA 0,5 kg MA Másl Másl PERLA 0,25 kg MA Másl Tabulka POTRAVINY tak pr tabulku POTRAVINY_V_LEDNICE p edstavuje íselník. Schéma databáze není ve 3.NF, prtže atribut Typ_název je siln závislý na atributu Typ_zkratka. Takže další rzklad:

21 I SZ DB1 21 POTRAVINY_V_LEDNI CE(árvý_kód, Sptebujte_d, Pet) POTRAVINY(árvý_kód, Název, Typ_zkratka) TYP(Zkratka, Název) árvý kód Sptebujte d Pet N:1 árvý kód Název Jgurt bílý DANONE 0,2 l Jgurt YOGOBELLA 0,5 l Másl RAMA 0,5 kg Másl PERLA 0,25 kg Typ zkratka JO JO MA MA N:1 Typ zkratka JO MA Typ název Jgurt Másl Tabulka TYP tak tví íselník tabulce POTRAVINY. Takt se tví infrmaní íselníky ast, kdy uživateli v aplikaci zbrazujete plný název z íselníku, ale d tabulky zapisujete jen zkratku, kteru uživatel nemusí ani znát.

22 ISZ DB Databázvé úlhy, specifické prblémy jejich analýzy a návrhu Prjekce datvé základny rámcvá funkní analýza rámcvá datvá analýza rámcvý ppis funkcí c chceme v DB. zachytit empirický ppis funkcí vyjmenujeme s jakými daty budeme pracvat funkní analýza datvá analýza ERA mdel funkcí, událstí, perací knfrntace datvé a funkní analýzy, vyladní mdelu knceptuální datvý mdel knceptuální mdel systému návrh algritm návrh datvých struktur ppis prgramvéh vybavení ppis datvých struktur ppis systému

23 ISZ DB1 23 Implementace Pi implementaci vybíráme knkrétní databázvý systém, ve kterém vytvíme datvu základnu. P jeh výbru mžeme zaít využívat i rzných nestandardních funkcí zvlenéh prstedí. Jejich pužití bychm však mli dkladn zvážit, zejména kvli mžnému pzdjšímu pechdu na jiný databázvý systém. Z hlediska jazyka SQL je nutné pi implementaci vzít v úvahu i mžné dílí dlišnsti v píkazech. Návrh datvé základny a její struktury by neml být, zvlášt u rzsáhlejších systém, živelným prcesem pstupn reagujícím na vzniklé pžadavky. V suasné db existují histricky vené pstupy a pravidla návrhu, která umžní a d jisté míry i zaruí vytvení kvalitní datvé základny, která bude ádn zdkumentvaná, lgicky knzistentní a bude umžvat relativn snadné zapracvání skutenstí vzniklých pzdji. Pdstatná je pátení analýza blasti, kteru chceme ppsat v databázvém prstedí, pedtím než zaneme vytváet tabulky a dtazy pmcí jazyka SQL. ím pzdji ttiž dhalíme chyby v návrhu datvé základny, tím vtší námahu a tím i finanní prstedky budeme muset btvat na jejich nápravu. Pln vcí byl naznaen v pedchzích tázkách. Jaké vci jsu nejdležitjší a c je teba prmyslet: vytvit dbrý ERA mdel, v pednáškách z DB1 jsu nkteré píklady na dbré a blbé mdely, pi návrhu se pužívají CASE nástrje dekmpnvat vztahy m:n pevést d nrmálních frem, pi návrhu databáze je slušné splnit 3NF, ale pzr, pkud by prces nrmalizace vedl k extrémnímu ptu 2-slupcvých tabulek je nutné pítat s tím, že mže neúmrn narst dba pr vyhdncvání dtaz (výbr se prvádí pes hdn tabulek) prmyslet perace prvádné s daty, pkud se perace skládá z nklika SQL píkaz dát d transakce uvážit pužití trigger prmyslet pístupvá práva, v pípad velkéh mnžství uživatel pužít další prstedky SQL bhacující nastavvání pístupvých práv rle (šablna uživatelských práv, pdle které se nastaví práva knkrétníh uživatele) a phledy (mezení slupc, které se smí zbrazit ve výsledku SELECT dtaz) Mžné prblémy s transakcemi Pes nesprnu úelnst transakcí se mžeme dstat d situace, kdy nám jejich existence zane vadit. Jedná se zejména pípady aktualizace velkéh mnžství dat jejich zmnu neb mazání. Aby byl mžný návrat d stavu na pátku transakce, musí databázvý systém ukládat všechny zmnné neb vymazané ádky na pedem vyhrazené míst. Máme-li tabulku veliksti 800 MB, ze kterém chceme vymazat plvinu ádk, musíme mít k dispzici dalších 400 MB prstru na disku. Databázvému systému musíme umžnit, aby d th prstru dasn ukládal infrmace zmnách v databázi. P uknení transakce píkazem COMMIT mžeme tent prstr pt zrušit. Triggery Existuje velké mnžství situací, kdy je vhdné trigger pužít. Význam trigger se ješt zvtšuje v pípad, že míst jednh SQL píkazu mhu vyvlat celu prceduru. Na druhu

24 ISZ DB1 24 stranu je nutné vzít v úvahu urité nebezpeí, které pužití trigger pedstavuje. Jejich vyvlání je natlik skryté, že zvlášt u velkých databázvých aplikací mžeme na existenci nkteréh z nich zapmenut. V pípad hledání chyby v zadávaných SQL píkazech pak mžeme strávit dluhé hdiny, než si uvdmíme všechny dsledky, které má vyvlání triggeru.