DBS otázka 1

DBS otázka 1

1. Datové modely

   • Kolekce konceptuálních nástrojů pro popis objektů reality. Snaží se reprezentovat data, vztahy mezi realnými objekty, sémantiku a integritní omezení.
   • Konceptuální model
     • 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
     • Výhody
       • 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).
     • Nevytvoření
       • 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.
     • Entity (třídy)
       • Slabá entita (identifikační závislost)
         • 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...
     • Vztahy (asociace)
       • Kardinalita
         • 1:1, 1:N, M:N
       • Účast
         • Povinná / Nepovinná
       • Dekompozice
         • 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))
       • Rekurzivní vztah
         • Vyjádření vztahu mezi zástupci té samé entity (rodič a potomek..)
       • ISA hiearchie
         • z anglického is a, např: Jednotka - byt nebonebytový prostor. Nevhodné pro role, výhodnější je použití slabé entity..
   • Databázový model
     • Definují podobu dat v databázi (vztahy mezi nimi..) tzn určují strukturu dat v databázi)
     • Relační model
       • 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)
       • Relace
         • 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,
         • n-tice
           • jeden záznam, prvek relace, řádek v tabulce
         • domény atributů, značeno dom(A)
           • datový typ atributu?
         • Schéma relace R(A)
           • 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
           • Schéma relační db (R, I)
             • 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
             • Klíč schématu
               • Klíč K schématu R(A) je podmnožina atributů z A, která jednoznačně určí každou n-tici relace R
               • MInimalnost klice
                 • Neexistuje K' ktere je podmnozinou K a pri tom jednoznacne urcuje kazdou n-tici relace R
               • Podklíč
                 • Pokud se klíč skládá z více atributů, podklíč je každý z těchto atributů.
               • Neklíčový atribut
                 • Atribut, který není podklíčem nebo klíčem dané relace.
       • Dotaz
         • 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
     • Síťový model
       • Množina záznamů (síť), vztahy pojmenovány, konec 60. let
     • Hiearchický model
       • Data v hiearchické struktuře (strom), vznik v 60. letech min. století)
     • OO model
     • Objektově relační model

2. Fyzický pohled na data

   • http://www.fit.vutbr.cz/study/courses/DSI/public/pdf/nove/6_fyzurDBS.pdf
   • Uspořádání souborů
     • Soubor: posloupnost záznamů seskupovaných do bloků tvořících logický celek
     • Neuspořádaný soubor (HEAP)
       • Neuspořádanost záznamů, záznam se uloží tam, kde je zrovna místo.
     • Hashovaný soubor
       • Záznamy jsou umisťovánay do bloků na základě hashovaci funkce
     • Sekvenční soubor (CLUSTER)
       • 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)
   • Indexování
     • 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íč)
     • B strom řádu m
       • 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é
     • Bitmapové indexy

3. Pojmy

   • DBMS / SŘBD
     • DataBase Management System // Systém řízení bází dat Programová vrstva, která řídí operace nad databází a poskytuje API.
     • RDBMS - relational
     • ODBMS - object
     • ORDBMS - object-relational
   • DB
     • Množina strukturovaných perzistentních dat. DB je nezávislá na programu
     • Velké množství dat
     • Perzistence
       • Data přetrvávají od zpracování ke zpracování.
     • Spolehlivost
       • Data lze rekonstruovat po chybe (zalohovani)
     • Sdílení
       • Data sdílena mezi více uživateli, možnost nastavení práv. Možnost práce více uživatelů najednou.
     • DDL - data definition language
       • Jazyk pro definici dat (např. logické a fyzické schéma) - tzn definuje data, která budou v DB uložena
       • Datový slovník
         • Obsahuje metadata(data o datech)
     • DML - data manipulation language
       • Jazyk pro manipulaci s daty tzn update, insert...
     • TCL - transfaction control language
       • jazyk pro řízení transakcí
     • DCL - data control language
       • jazyk pro definici přístupových práv k datům
     • Dotaz (query)
       • Požadavek v dotazovacím jazyku.
       • Výsledek dotazu
         • Odpoved v podobe datove struktury
       • Dotazovací jazyk
         • Množina všech výrazů pro konstrukci dotazu
     • Integritní Omezení (IO)
       • IO jsou tvrzení, které určují, jaká data v databázi mohou být a jaká ne.
       • Integrita dat
         • Správnost dat z hlediska jejich IO, například věk člověka nesmí být záporné číslo.
     • Persistentní data
       • Data, která svou životností přesahují dobu běhu aplikačního programu či vypnutí počítače.
     • Schéma DB
       • Odráží použitý DB model, popisuje strukturu dat v databázi.
   • DBS = DB + DBMS
     • Hlavní úloha: abstrakce pohledu na data, uživatel nemusí řešit, kde a jak jsou uloženy...

4. Normalizace

   • 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.
   • Proč normalizovat
     • Redundance
     • Aktualizační anomálie
       • 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.
   • Funkční závislost (FZ)
     • 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}
     • Armstrongova pravidla
       • triviální funkční závislosti (FZ1)
         • Pokud Y náleží do X, poté X -> Y
       • Tranzitivita
         • Jestli ze X -> Y a Y -> Z, pak X->Z
       • Kompozice prave strany
         • Jestlize X -> A a X -> B, pak X -> AB
       • Dekompozice prave strany
         • Jestlize X->AB, pak X->A a X->B
     • Nalezení klíče
     • Tranzitivní uzávěr množiny atributů
       • 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}
   • 2NF
   • 3NF
     • 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!
   • Boyce-Codova normální forma (BCNF)
     • 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í

   • 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ů.
   • Řízení souběžného zpracování
     • 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.
   • Zotavení z chyb
     • Chyba software, programu nebo fyzického uložení dat během transakce nesmí vést k nekonzistenci databáze.
     • Globální chyby
       • Výpadek serveru (ztráta cache)
       • Výpadek komunikace server klient
       • Chyby médií (výpadek disku)
     • Logické chyby
       • Nechtěný výsledek transakce (špatný update, delete..)
     • Po pádu
       • Roll forward
         • Obnovení paměti ze žurnálu, dokončení transakcí, které byly potvrzeny, ale nebyly provedeny (např. zápis na disk)
         • Rollback
           • Odvolání všech transakcí, které nebyly v době pádu dokončeny.
   • Transakce
     • 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.
     • Konec transkace
       • Explicitní
         • Commit (potvrzení)
         • Rollback (zrušení)
       • Implicitní
         • Ukonení session
         • Autocommit on
     • Začátek transakce
       • Konec předchozí
       • Zahájení session
     • Stavový diagram transakce
     • Vlastností transkací (ACID)
       • Atomicity - bud probehne transakce celá nebo vůbec
       • Consistency - transakce transformuje db z konzist stavu opet do konzist stavu
       • Independency - dílčí operace jedné transkace nejsou viditelné ostatním transakcím
       • Durability - trvanlivost - efekty úspešné transakce jsou trvale uloženy (persist)
     • Rozvrh
       • Stará se o něj rozvrhovač, nemělo by docházet k tomu, že si 2 transakce mění data pod rukama.
       • Konfliktní operace
         • Různé pořadí sériového volání poskytne jiné výsledky

Images and files in the map