DBS otázka 1

Martin Pavlík
Mind Map by Martin Pavlík, updated more than 1 year ago
Martin Pavlík
Created by Martin Pavlík over 5 years ago
47
0

Description

Zdroje: edux, prednasky z VUT v Brne

Resource summary

DBS otázka 1

Annotations:

  • 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

Annotations:

  • 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.1 Konceptuální model

Annotations:

  • 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.1.1 Výhody

Annotations:

  • 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).
1.1.2 Nevytvoření

Annotations:

  • 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.
1.1.3 Entity (třídy)
1.1.3.1 Slabá entita (identifikační závislost)

Annotations:

  • 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...
1.1.4 Vztahy (asociace)
1.1.4.1 Kardinalita

Annotations:

  • 1:1, 1:N, M:N
1.1.4.2 Účast

Annotations:

  • Povinná / Nepovinná
1.1.4.3 Dekompozice

Annotations:

  • 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))
1.1.4.4 Rekurzivní vztah

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

  • 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.2.1.1 Relace

Annotations:

  • 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.2.1.1.1 n-tice

Annotations:

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

Annotations:

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

Annotations:

  • 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.2.1.1.3.1 Schéma relační db (R, I)

Annotations:

  • 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.2.1.1.3.1.1 Klíč schématu

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

  • 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
1.2.2 Síťový model

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

  • 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.2 Indexování

Annotations:

  • 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íč)
2.2.1 B strom řádu m

Annotations:

  • 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.2.2 Bitmapové indexy
3 Pojmy
3.1 DBMS / SŘBD

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

  • Odpoved v podobe datove struktury
3.2.9.2 Dotazovací jazyk

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

  • 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.
4.1 Proč normalizovat
4.1.1 Redundance
4.1.2 Aktualizační anomálie

Annotations:

  • 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.
4.2 Funkční závislost (FZ)

Annotations:

  • 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}
4.2.1 Armstrongova pravidla
4.2.1.1 triviální funkční závislosti (FZ1)

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

  • 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}
4.3 2NF
4.4 3NF

Annotations:

  • 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!
4.5 Boyce-Codova normální forma (BCNF)

Annotations:

  • 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í

Annotations:

  • 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ů.
5.1 Řízení souběžného zpracování

Annotations:

  • 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.
5.2 Zotavení z chyb

Annotations:

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

Annotations:

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

Annotations:

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

Annotations:

  • 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.
5.3.1 Konec transkace
5.3.1.1 Explicitní
5.3.1.1.1 Commit (potvrzení)
5.3.1.1.2 Rollback (zrušení)
5.3.1.2 Implicitní
5.3.1.2.1 Ukonení session
5.3.1.2.2 Autocommit on
5.3.2 Začátek transakce
5.3.2.1 Konec předchozí
5.3.2.2 Zahájení session
5.3.3 Stavový diagram transakce
5.3.4 Vlastností transkací (ACID)
5.3.4.1 Atomicity - bud probehne transakce celá nebo vůbec
5.3.4.2 Consistency - transakce transformuje db z konzist stavu opet do konzist stavu
5.3.4.3 Independency - dílčí operace jedné transkace nejsou viditelné ostatním transakcím
5.3.4.4 Durability - trvanlivost - efekty úspešné transakce jsou trvale uloženy (persist)
5.3.5 Rozvrh

Annotations:

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

Annotations:

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

Similar

Spanish Conversation Phrases
silviaod119
An Inspector Calls - Themes
mhancoc3
IB Economics: International Trade
Han Zhang
Business Studies Unit 1
kathrynchristie
NEW: ExamTime's Mind Map Maker
Andrea Leyden
Physics
Holly Bamford
English Language Techniques
lewis001
Variation and evolution Quiz
James Edwards22201
AQA GCSE Chemistry Unit 2
Gabi Germain
French Revolution quiz
Sarah Egan
Core 1.3 Energy Generation, Storage and Use
T Andrews