dbs Flashcards
(31 cards)
Referencni integrita
Cizi klic musi byt v referujici a stejne tak i v referencni tabulce klicem (PRIMARY KEY nebo UNIQUE)
FALSE
Referencni integrita
U daneho ciziho klice muze byt definovana nejvyse jedna referencni akce obsluhujici udalost DELTE, UPDATE nebo INSERT
TRUE
Referencni integrita
referencni akce popisuje dopad na radky f referujici tabulce, pokud by prislusna aktualizacni operace v referencni tabulce zpusobila naruseni referencni integrity
TRUE
Referencni integrita
Pokud neni definovana zadne akce, chovani je identicke jako u varianty NO ACTION
FALSE
Referencni integrita
Vysledek referencnich akci NO ACTION a RESTRICT muze byt v pripade pouziti vhodne implementovanych triggery rozdilny
TRUE
Relacni model
Relacni databaze obsahuje mnozinu relaci, kazda ma sve relacni schema a vlastni data, tedy mnozinu zaznamu
TRUE
Relacni model
Zaznamy v relacich menaji definovane vzajemne poradi, relace mohou obsahovat duplicitni zaznamy
FALSE
Records in relations (tables) do not have a defined mutual order: This is True. In a relational database, the order in which records are stored does not matter. The model doesn’t consider the order or sequence of rows in a table, and the data can be fetched in any order.
Relations may contain duplicate records: This is False. A proper relational database does not allow duplicate rows in a table, as each row should uniquely represent a relation. This is usually enforced by the use of primary keys, unique identifiers for each record. However, it’s worth noting that this can vary with different SQL implementations, some of which may allow duplicate records if not properly constrained.
So the entire statement is False because the second part is not correct.
Relacni model
Atributy mohou nabyvat pouze a jenom atomickych hodnot, mluvime proto o tzv. prvni normalni forme
TRUE
Relacni model
Klic je libovolna mnozina atributu dane relace, ktera ma idenfitikacni schopnost, tj. dokaze unikatne urcit kazdy zaznam dane relace
FALSE
it needs to be mininal to be a key
Relacni model
Klic je libovolna mnozina atributu dane relace, ktera ma idenfitikacni schopnost, tj. dokaze unikatne urcit kazdy zaznam dane relace
FALSE
it needs to be mininal to be a key
Relacni model
Libovolna relace muze obsahovat i vice klicu, nejvyse vsak jeden jediny nadklic
FALSE
Buffer management
Jeden diskovy blok (stranka) se namapuje do jedne stranky v systeme pameti a to i pokud diskovy blok a pametova stranka maji ruzne velikosi
True
Buffer management
Sekvenvni pristup k blokum primarniho souboru na tradicnim magnetickem pevnem disku je vyrazne rychlejsi ned pristup nahodny
True
Buffer management
U kazde stranky v systemove pameti si (mimo jine) pamatujememe pocet transakci, ktere k dane strance aktualne pristupuji
True
Buffer management
Pokud uz danou stranku v systeme pameti nikdo nevyuziva, je vzdy nutne jeji aktualni obsah zapsat na pevny disk
False
Buffer management
Pokud uz v bufferu neni volne misto, vhodna stranka k uvolneni se najde napr. pomoci politiky LRU
True
Name the 4 coffman conditions
Mutual Exclusion
Hold and Wait
No Preemption
Circular Wait
Coffman conditions
Mutual Exclusion
At least one resource must be non-sharable, meaning it can only be used by one process at a time. For example:
A printer that can only be used by one process at a time. If a process is printing, other processes must wait for the printer to become available.
Coffman conditions
Hold and Wait
A process holding at least one resource can request additional resources while still retaining the ones it currently holds. For example:
Process A holds a lock on a file and requests a lock on a database. While waiting for the database lock, Process A retains the lock on the file.
Coffman conditions
No Preemption
Resources cannot be forcibly taken away from a process; they can only be released voluntarily. For example:
Process A is using a database connection and cannot have that connection forcefully terminated by another process.
Coffman conditions
Circular Wait
A circular chain of two or more processes exists, where each process is waiting for a resource held by the next process in the chain. For example:
Process A is waiting for a resource held by Process B, which is waiting for a resource held by Process C, and so on, until a process in the chain is waiting for a resource held by Process A.
Armstrong’s axioms
name and explain the Armstrong’s axioms
which of these are independent?
Trivial
if Y ⊆ X, then X -> Y
Transitivity
if X -> Y and Y -> Z, then X -> Z
Composition
if X -> Y and X -> Z, then X -> YZ
Decomposition
if X -> YZ, then X -> Y and X -> Z
all of them are independent, if we remove one of them -> we violate the completeness
(porusime vlastnosti uplnosti)
Definujte pojem nezotavitelny rozvrh.
Co musi rozvrh splnovat, abychom zcela vyloucili kaskadove ruseni transakci?
schedule in a database system where the effects of a transaction’s actions cannot be undone or rolled back.
rozvrh musí splňovat tzv. “striktní dvoufázový zamykací protokol” (Strict Two-Phase Locking protocol, Strict 2PL).
Výběr vhodných algoritmů pro jednotlivé operace v rámci plánování vyhodnocení SQL dotazů závisí na několika faktorech, informacích a strukturách:
SSITHC
Schéma databáze: Informace o struktuře tabulek, sloupcích, klíčích a vazbách mezi nimi jsou důležité pro rozhodování o optimálním plánu vyhodnocení. Například, znalost indexů a statistik o rozložení dat může pomoci vybrat efektivní přístupové metody.
Statistiky: Statistiky o distribuci dat v tabulkách, například histogramy nebo frekvence hodnot, jsou důležité pro odhad nákladů a selekční faktory operací vyhledávání. Na základě těchto informací se vybírají nejefektivnější algoritmy, například použití vhodných indexů.
Dostupné indexy: Informace o existujících indexech v databázi a jejich struktura jsou rozhodující pro plánování operací vyhledávání. Správný výběr indexu může výrazně zlepšit výkon vyhledávání.
Typy operací: Různé operace SQL dotazů (např. JOIN, GROUP BY, ORDER BY) vyžadují různé algoritmy a strategie pro efektivní vyhodnocení. Například použití vhodného algoritmu pro spojování tabulek může ovlivnit celkový výkon dotazu.
Dostupná hardwarová a softwarová konfigurace: Výběr algoritmů může být ovlivněn také dostupnými zdroji, jako je velikost paměti, počet procesorů, dostupný diskový prostor a další faktory hardwarové a softwarové konfigurace.
Cíle optimalizace: Závisí na preferovaných cílech optimalizace, jako je minimalizace času vyhodnocení dotazu, minimalizace nákladů na I/O operace, minimalizace spotřeby paměti atd.