DBS otázka 1

Nota:

• Datové modely: konceptuální datový model, databázové modely, fyzický pohled na data. Relační model, relace, normální formy, transakční zpracování (vlastnosti transakcí - ACID).
• Mnohem lepší než ten bordel na eduxu v přednáškách je: www.fit.vutbr.cz/study/courses/DSI/public/pdf/nove/1_uvod.pdf

1. Datové modely

   Nota:

   • Kolekce konceptuálních nástrojů pro popis objektů reality. Snaží se reprezentovat data, vztahy mezi realnými objekty, sémantiku a integritní omezení.
   1. Konceptuální model

      Nota:

      • Zabývá se modelováním reality, není ovlivněn budoucím prostředkem řešení. Modelován v ER modelu nebo UML class diagramech.
      • Orientace na entity (třídy) a vztahy (asociace) mezi nimi.
      • Popis reality ne realizace v konkretnim db stroji.
      • Pokud se v modelu objeví cizí klíče, jedná se o grafickou podobu relačního modelu
      1. Výhody

         Nota:

         • Společné chápání objektů aplikace uživateli a návrháři. Výsledek je vstupem pro realizaci databáze. Slouží jako dokumentace (zrychluje orientaci ve velkých DB).
      2. Nevytvoření

         Nota:

         • Nízká úroveň pohledu na data, což vede k obtížné komunikaci se zákazníkem a nemožnosti zrealizovat větší databázi. V rozsáhlých DB je obtížné se zorientovat.
      3. Entity (třídy)
         1. Slabá entita (identifikační závislost)

            Nota:

            • Entita je identifikovaná částečně nebo plně vtahem k jiné entitě. Například Blok (např. A) a Pokoj (105). Pokoj je slabou entitou Bloku (k jeho identifikaci používáme entitu Blok).
            • Omezení: slabá entita může mít vztah pouze s max jednou entitou, která jí identifikuje. Tzn Pokoj 105 nemůže být zároveň v Bloku A a v Bloku B... Každá osoba může mít maximálně 1 profil...
      4. Vztahy (asociace)
         1. Kardinalita

            Nota:

            • 1:1, 1:N, M:N
         2. Účast

            Nota:

            • Povinná / Nepovinná
         3. Dekompozice

            Nota:

            • Každý vztah M:N můžeme dekomponovat na dva vztahy 1:N
            • vložíme silnou entitu nebo použijeme slabou entitu (identifikační závislost) ((je si to dost podobné, ale ve druhém vztahu nemá nově vzniklá slabá entita PK(je identifikována původními dvěmi) - Kino může hrát film pouze jednou))
         4. Rekurzivní vztah

            Nota:

            • Vyjádření vztahu mezi zástupci té samé entity (rodič a potomek..)
         5. ISA hiearchie

            Nota:

            • z anglického is a, např: Jednotka - byt nebonebytový prostor. Nevhodné pro role, výhodnější je použití slabé entity..
   2. Databázový model

      Nota:

      • Definují podobu dat v databázi (vztahy mezi nimi..) tzn určují strukturu dat v databázi)
      1. Relační model

         Nota:

         • Rozšiřuje konceptuální model o cizí klíče, splňuje 1NF, relace mají unikátní n-tice (neobsahují duplicitní řádky) (relace = tabulka). 
         • Vyhodnocení dotazu nezáleží na fyzickém uložení dat
         • Silné prostředky pro dotazování - relacni algebra, relacni kalkul, formální abstrakce textových souborů, slouží pro posouzení kvality relačního schématu
         • Standardizován pomocí SQL (Structured Query Language)
         1. Relace

            Nota:

            • Nezáleží na pořadí n-tic, neobsahují duplicitní záznamy, relace = nepřesně řečeno tabulka, prvek relace (n-tice) = řádek této tabulky
            • Relace = tabulka, Schéma relace = záhlaví tabulky, Atribut = sloupec, Prvek relace (n-tice) = řádek,
            1. n-tice

               Nota:

               • jeden záznam, prvek relace, řádek v tabulce
            2. domény atributů, značeno dom(A)

               Nota:

               • datový typ atributu?
            3. Schéma relace R(A)

               Nota:

               • R(A1:D1, A2:D2) kde A1 je prvni atribut a D1 je jeho doména, R je relace, zkráceně R(A)
               • Něco jako záhlaví tabulky
               1. Schéma relační db (R, I)

                  Nota:

                  • Schéma relařní databáze je množina relací a integritních omezení. Tzn. (R, I), kde R náleží R1, R2... Rn) a I je množina integritních omezení
                  • Např. schéma databáze s rozvrhem předmětů: Rozvrh(Přednáška, Učitel, Místnost...) a slovně popsané IO
                  1. Klíč schématu

                     Nota:

                     • Klíč K schématu R(A) je podmnožina atributů z A, která jednoznačně určí každou n-tici relace R
                     1. MInimalnost klice

                        Nota:

                        • Neexistuje K' ktere je podmnozinou K a pri tom jednoznacne urcuje kazdou n-tici relace R
                     2. Podklíč

                        Nota:

                        • Pokud se klíč skládá z více atributů, podklíč je každý z těchto atributů.
                     3. Neklíčový atribut

                        Nota:

                        • Atribut, který není podklíčem nebo klíčem dané relace.
         2. Dotaz

            Nota:

            • Dotaz nad schématem S je výraz, který vrací odpověď se schématem T. Def. obor =  všechna uložiště se schématem S Obor hodnot = všechny relace se schématem T Data odpovědi pocházejí z databáze Odpoved nezavisi na fyzickem ulozeni dat
      2. Síťový model

         Nota:

         • Množina záznamů (síť), vztahy pojmenovány, konec 60. let
      3. Hiearchický model

         Nota:

         • Data v hiearchické struktuře (strom), vznik v 60. letech min. století)
      4. OO model
      5. Objektově relační model
2. Fyzický pohled na data

   Nota:

   • http://www.fit.vutbr.cz/study/courses/DSI/public/pdf/nove/6_fyzurDBS.pdf
   1. Uspořádání souborů

      Nota:

      • Soubor: posloupnost záznamů seskupovaných do bloků tvořících logický celek
      1. Neuspořádaný soubor (HEAP)

         Nota:

         • Neuspořádanost záznamů, záznam se uloží tam, kde je zrovna místo.
      2. Hashovaný soubor

         Nota:

         • Záznamy jsou umisťovánay do bloků na základě hashovaci funkce
      3. Sekvenční soubor (CLUSTER)

         Nota:

         • Logicky podobné záznamy se ukládájí relativně blízko sebe. Klíč pro shlukování se nazývá cluster key (pokud neni použito shlukování clustering, tak se klíči říká jen search key)
   2. Indexování

      Nota:

      • Indexy slouží pro rychlejší vyhledávání dat v databázi. Indexovací struktury většinou odkazují na ID řádku (ROWID), kde se data nacházejí. (tzn klíč)
      1. B strom řádu m

         Nota:

         • Kořen min 2 potomky, pokud není listem. Každý uzel mimo kořene a listu má min m/2 potomků a max m potomků. Každý uzel má nejméně m/2 a nejvíce m-1 záznamů (většinou jen klíčů) Všechny cesty jsou ve stromu stejně dlouhé
      2. Bitmapové indexy
3. Pojmy
   1. DBMS / SŘBD

      Nota:

      • DataBase Management System // Systém řízení bází dat Programová vrstva, která řídí operace nad databází a poskytuje API.
      1. RDBMS - relational
      2. ODBMS - object
      3. ORDBMS - object-relational
   2. DB

      Nota:

      • Množina strukturovaných perzistentních dat. DB je nezávislá na programu
      1. Velké množství dat
      2. Perzistence

         Nota:

         • Data přetrvávají od zpracování ke zpracování.
      3. Spolehlivost

         Nota:

         • Data lze rekonstruovat po chybe (zalohovani)
      4. Sdílení

         Nota:

         • Data sdílena mezi více uživateli, možnost nastavení práv. Možnost práce více uživatelů najednou.
      5. DDL - data definition language

         Nota:

         • Jazyk pro definici dat (např. logické a fyzické schéma) - tzn definuje data, která budou v DB uložena
         1. Datový slovník

            Nota:

            • Obsahuje metadata(data o datech)
      6. DML - data manipulation language

         Nota:

         • Jazyk pro manipulaci s daty tzn update, insert...
      7. TCL - transfaction control language

         Nota:

         • jazyk pro řízení transakcí
      8. DCL - data control language

         Nota:

         • jazyk pro definici přístupových práv k datům
      9. Dotaz (query)

         Nota:

         • Požadavek v dotazovacím jazyku.
         1. Výsledek dotazu

            Nota:

            • Odpoved v podobe datove struktury
         2. Dotazovací jazyk

            Nota:

            • Množina všech výrazů pro konstrukci dotazu
      10. Integritní Omezení (IO)

          Nota:

          • IO jsou tvrzení, které určují, jaká data v databázi mohou být a jaká ne.
          1. Integrita dat

             Nota:

             • Správnost dat z hlediska jejich IO, například věk člověka nesmí být záporné číslo.
      11. Persistentní data

          Nota:

          • Data, která svou životností přesahují dobu běhu aplikačního programu či vypnutí počítače.
      12. Schéma DB

          Nota:

          • Odráží použitý DB model, popisuje strukturu dat v databázi.
   3. DBS = DB + DBMS

      Nota:

      • Hlavní úloha: abstrakce pohledu na data, uživatel nemusí řešit, kde a jak jsou uloženy...
4. Normalizace

   Nota:

   • Dva přístupy:  normalizační teorie, z konceptuálního modelu. Převod konceptuálního modelu do relačního nemusí nutně vést k vytvoření normalizovaného relačního schématu
   • Normalizace se provádí DOKOMPOZICÍ. Tzn. schéma R(U,F) převedeme na schéma {R(U), R(F)}
   • Výsledné schéma by mělo mít stejnou sémantiku. Nové relace by měly obsahovat stejná data, jako před změnou.
   1. Proč normalizovat
      1. Redundance
      2. Aktualizační anomálie

         Nota:

         • Změníme li jednu věc, musíme jí změnit vícekrát (vyřeší např. normalizace dekompozicí).  Můžeme přijít o některé informace (např adresa Kina, kdybychom měli Program(jmeno_f, nazev_k, adresa_k) atd.
   2. Funkční závislost (FZ)

      Nota:

      • Neformálně:  NAPŘ: Ke každému kinu existuje maximálně 1 adresa. Zapíšeme jako: NAZEV_K -> ADRESA Pro každou dvojici kino film existuje max jedno datum, kdy má dané kino film na programu. (NAZEV_K, JMENO_F)  -> DATUM
      • FZ vyjadřují IO (integritní omezení). Je vhodné si jendotlivé atributy zkracovat.
      • PS -> Z PS -> Y ==> PS->ZY --------------- PS -> S platí vždy
      • Sada Funk. zavilosti: F = {AB->X, X->Z, C->A}
      1. Armstrongova pravidla
         1. triviální funkční závislosti (FZ1)

            Nota:

            • Pokud Y náleží do X, poté X -> Y
         2. Tranzitivita

            Nota:

            • Jestli ze X -> Y a Y -> Z, pak X->Z
         3. Kompozice prave strany

            Nota:

            • Jestlize X -> A a X -> B, pak X -> AB
         4. Dekompozice prave strany

            Nota:

            • Jestlize X->AB, pak X->A a X->B
      2. Nalezení klíče
      3. Tranzitivní uzávěr množiny atributů

         Nota:

         • Tranzitivní uzávěr je množiny atributů X+ vzhledem k množině funkčních závislostí F jsou všechy atributy, které jsou závislé na X.
         • např:  P -> U, PU->X P+ = {P, U, X}
   3. 2NF
   4. 3NF

      Nota:

      • Ríkáme, že schéma relace R je ve 3. normální formě (3NF), jestliže každý neklíčový atribut schématu R není tranzitivně závislý na žádném klíči schématu. (tzn. přímo závislý může být)  Tranz. závislý je třeba C když X -> Y -> C, C je tedy tranz. zavisle na X
      • Pokud relace nemá neklíčový atribut, je v 3NF!
   5. Boyce-Codova normální forma (BCNF)

      Nota:

      • Ríkáme, že schéma relace R je v Boyce - Coddove normální forme (BCNF), jestliže pro každou netriviální  závislost X -> Y platí, že X obsahuje klíč schématu R. Netriviální závislost chápu tak, že X se musí skládat z více atributů.
      • Každé schéma v BCNF je zároveň ve 3NF, obráceně to neplatí. Máli schéma jen jednoduché klíče nebo jediný klíč, pak platí, že jeli ve 3NF je i ve BCNF
5. Transakční zpracování

   Nota:

   • Dva základní požadavky na DBMS: chránit data (zotavení po havárii) a poskytnout korektní, rychlý a asynchroní přístup pro více uživatelů.
   1. Řízení souběžného zpracování

      Nota:

      • Zajišťuje, že každý uživatel přistupuje ke konzistentnímu stavu databáze. Tzn. i asynchroně se dostávájí k těm samým datům v ten samý čas.
   2. Zotavení z chyb

      Nota:

      • Chyba software, programu nebo fyzického uložení dat během transakce nesmí vést k nekonzistenci databáze.
      1. Globální chyby
         1. Výpadek serveru (ztráta cache)
         2. Výpadek komunikace server klient
         3. Chyby médií (výpadek disku)
      2. Logické chyby
         1. Nechtěný výsledek transakce (špatný update, delete..)
      3. Po pádu
         1. Roll forward

            Nota:

            • Obnovení paměti ze žurnálu, dokončení transakcí, které byly potvrzeny, ale nebyly provedeny (např. zápis na disk)
            1. Rollback

               Nota:

               • Odvolání všech transakcí, které nebyly v době pádu dokončeny.
   3. Transakce

      Nota:

      • Programová jednotka a mechanizmy, které zajistí, že po skončení akce zůstane databáze v konzistentím stavu (i když skončí chybou)
      • Během zpracovávání transakce může být databáze dočasně v nekonzistentním stavu.
      1. Konec transkace
         1. Explicitní
            1. Commit (potvrzení)
            2. Rollback (zrušení)
         2. Implicitní
            1. Ukonení session
            2. Autocommit on
      2. Začátek transakce
         1. Konec předchozí
         2. Zahájení session
      3. Stavový diagram transakce
      4. Vlastností transkací (ACID)
         1. Atomicity - bud probehne transakce celá nebo vůbec
         2. Consistency - transakce transformuje db z konzist stavu opet do konzist stavu
         3. Independency - dílčí operace jedné transkace nejsou viditelné ostatním transakcím
         4. Durability - trvanlivost - efekty úspešné transakce jsou trvale uloženy (persist)
      5. Rozvrh

         Nota:

         • Stará se o něj rozvrhovač, nemělo by docházet k tomu, že si 2 transakce mění data pod rukama.
         1. Konfliktní operace

            Nota:

            • Různé pořadí sériového volání poskytne jiné výsledky