Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Informační systémy a technologie > VI. Návrh databáze, databázové systém a databázové jazyky. > Flashcards

VI. Návrh databáze, databázové systém a databázové jazyky. Flashcards

1
Q

Návrh databáze

A

Návrh databáze vždy vychází z modelu, resp. datového modelu, který říká, jaká data budeme uchovávat, jaké mají vlastnosti a vzájemné vazby.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Modelování

A

ER (Entity Relationship) modelování se používá pro abstraktní a konceptuální znázornění dat. Spočívá ve využití základních konstruktů jazyka pro tvorbu diagramů a v metodice tvorby těchto diagramů – základní myšlenkou je, že databáze uchovává fakta o entitách a o vztazích mezi entitami. Výsledkem je ERD (Entity Relationship Diagram, ER diagram).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Zásady modelování

A

Zásady

  • Minimalizace redundance (normalizace)
  • Maximalizovat znovupoužitelnost (dědičnost)
  • Maximalizovat výkonnost (de-normalizace, metody, database tuning)
  • Minimalizovat nároky na uložení dat (compression)

Využívá se přitom princpy tří architektur. Smyslem P3A je postupně upřesňovat datový model tak, aby zcela odpovídal požadavkům využívané databázové technologie. Stejně tak je naopak žádoucí, aby model v první vrstvě byl, pokud možno, abstraktní a tech. nezávislý.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Modely (3)

A

Konceptuální – model reality

Logický – Popis způsobu realizace systému v termínech jisté třídy technologického prostředí (lineární, relační, hierarchické, síťové datové struktury) Např. u RDM – doplnění cizích klíčů.

Fyzický – Popis vlastní realizace systému v konkrétním implementačním prostředí (doplnění i typu indexu, velikosti, rozmístění pracovního prostoru apod.).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Konceptuální schéma

A

Konceptuální schéma
(„nezávislý“) model obsahu datové základny na konceptuální úrovni (tj. nezatížený jakýmikoliv
implementačními a technologickými implementacemi)

  • konceptuální schéma reality – hrubý model vytvořený za účelem poznání reality
  • konceptuální schéma dat (datový model) – za účelem přesné specifikace obsahu datové základny. Předběžný návrh databázové základny
  • Funkce konceptuálního schématu:
    • Zadání pro implementační fázi
    • Nástroj (záruka) pro zachování konsistence
    • Lze z něj odvozovat dílčí pohledy na obsah databáze
    • Východisko pro nové požadavky na data
    • Východisko pro zásahy do existující datové základny
    • Nástroj dokumentace
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Logický model

A

Logický model
Popis způsobu realizace systému v termínech jisté třídy technologického prostředí (lineární, relační,
hierarchické, síťové datové struktury) Např. u RDM – doplnění cizích klíčů

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Fyzický model

A

Fyzický model
Popis vlastní realizace systému v konkrétním implementačním prostředí (doplnění i typu indexu,
velikosti, rozmístění pracovního prostoru apod.)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Návrh databáze

A

Návrh databáze

Spočívá v určení entit (tabulek), klíčů (referenční integrita), vztahů (relace), dodržení normálních forem, indexů.

Datové modelování – činnosti

  • Rozlišení množin objektů (entitních množin)
  • Pojmenování entitních množin a identifikace entit
  • Rozlišení entitních podmnožin (zaměstnanec – učitel, vědec, administrátor, zaměstnanec)
  • Určení vztahů mezi entitními množinami, určení kardinality (počet) a parciality (volitelnost) vztahů
  • Určení atributů entitních množin a vztahů
  • Vyřešení problémů synonym a homonym

Data v tabulce jsou uložena v polích uspořádaných do řádků (= záznamy) a sloupců (= atributy)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Entita

A

Entita

  • tabulka (ale až v DB), která vykazuje stejné společné znaky
  • něco, co je natolik důležité, že nám stojí zato to pojmenovat ⇒ v ER modelech modelujeme entitní typy, příklad:
  • entitní typ: STUDENT, entita: Ondřej Horák
  • výskyty entit musí být identifikovatelné na základě jejich atributů nebo vztahů s jinými entitami
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Vztahy

A

Vztahy = Pojmenované spojitosti mezi entitami

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Sloupec

A

Sloupec = množina dat jednoho typu (jeden atribut)

  • atribut je modelovaná vlastnost entit nebo vztahů zahrnutých do modelu
  • každá vlastnost zjistitelná pro nějakou entitu (atribut) je v modelu zakreslena nejvýše jedenkrát
  • existují také odvozené atributy, které se dají odvodit z vlastností jiných entit
  • je několik typů atributu / sloupce
    • povinný
    • Volitelný – může nemít hodnotu
    • Vícehodnotový – má hodnoty definované v dané doméně (např. JménoOsoby― u SmluvníPartner)
    • Skupinový / složený– vnitřní struktura např. u adresy (ulice, město, psč) – obvykle se normalizuje
    • Atomický – není vícehodnotový ani skupiný
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Vztahy

A

Vztahy

  • mezi entitami lze popsat vztah větou, ve které vztah vyjádříme přísudkovou částí. Např. „Zákazník vytváří Objednávku“
  • mohou být binární (vztahy dvou entit), ternární (vztah tří entit) i více-ární
  • u vztahu zjišťujeme a do diagramu zakreslujeme tzv. kardinalitu vztahu
    • kardinalita vztahu říká, kolik výskytů entit jednoho typu může být v daném vztahu s jedinou entitou druhého typu – říkáme, že vztah je buď 1:1, nebo 1:N nebo N:1 nebo M:N
  • dále zjišťujeme tzv. povinnost členství ve vztahu
    • říká, zda všechny výskyty entitního typu, jenž je určen pro danou roli v tomto vztahu, musí do tohoto vztahu skutečně vstupovat – například ne všichni učitelé musí v konkrétním semestru učit nějaký předmět
  • někdy do konceptuálního modelu zahrnujeme i informaci o tom, zda je vztah přenositelný
    • například „Učitel učí Předmět“ může být přenositelný vztah, kdy se učitelé ve výuce daného předmětu střídají semestr po semestru.
  • Zpracování vztahů
    • 1:1 – záznam obsahuje sloupec pro zapsání právě jednoho primárního klíče jiného záznamu
    • 1:M – záznam obsahuje sloupec pro zapsání právě jednoho primárního klíče jiného záznamu – na onen jiný záznam se může odkazovat více různých záznamů
    • M:N – může existovat více vzájemných odkazů – realizovano pomocí samostatné vazební tabulky (=dekompozice, neboli rozdělení na dvojici vztahů 1:M)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

INTEGRITA

A

Integrita = pravidla pro zajištění správnosti a konzistence

  • Entitní = nutnost existence primárního klíče pro každý záznam
  • Referenční = odkazování pouze na exitující záznamy v povolené kardinalitě
  • Doménová = stanovení povolených hodnot ve sloupci
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Konzistence databáze

A

Konzistence databáze – data v databázi zachycují stavy, které jsou v popisovaném světě MOŽNÉ

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Integrita databáze

A

Integrita databáze – databáze je v konzistentním stavu.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Relační integrita

A

Relační integrita – Určení primárního klíče (PK) a cizích klíčů (FK)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Primární klíč (PK)

A

Primární klíč (PK) – Je klíč, který splňuje následující vlastnosti:

  • jednoznačnost – jednoznačně identifikuje prvek relační množiny (jeden řádek v relační tabulce)
  • minimálnost – PK se skládá minimálního počtu atributů, tj. žádný z atributů tvořících PK nelze vynechat, aniž by byla porušena jednoznačnost PK.
  • hodnota PK nesmí být prázdná = nesmí být NULL
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Cizí klíč (FK)

A

Cizí klíč (FK) – PK použitý v dalším výskytu k vyjádření vazeb mezi objekty zachycenými v relační databázi.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Transformace do relačního modelu dat

A

Transformace do relačního modelu dat

  • Entity → tabulky
  • Atributy → sloupce
  • 1:N vztahy → FK
  • M:N vztahy → asociativní tabulky
  • identifikátory → PK
  • volitelnost → (povolené hodnoty null FK)
  • povinnost → (not null FK)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Pravidla transformace konceptuálního schématu do relačního modelu dat

A

Pravidla transformace konceptuálního schématu do relačního modelu dat

  • Entitní množina → 1 tabulka, identifikátory => atributy tvořící PK tabulky
  • Vztah je vyjádřen cizím klíčem
    • Jaká varianta je vhodnější pro transformaci vztahu 1:1?
  • Vztah M:N je vyjádřen vazební relační tabulkou s dvěma FK
  • Generalizace / specializace – více variant
    • 1 relační tabulka
    • Relačními tabulkami na úrovni specializovaných entitních množin
    • Relačními tabulkami na úrovni generalizující entitní množiny i na úrovní specializovaných entitních množin
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Constrainty

A

Constrainty = omezení, kterými lze vynutit nějaké podmínky

  • PK (jedinečná, unikátní hodnota – not null)
  • FK (odkaz na hodnotu PK jiné tabulky – může být null)
  • not null („hodnota musí být vložena“)
  • check (kontrola hodnoty)
  • unique (jedinečná hodnota – může být null)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Proces normalizace

A

Proces normalizace

  • Proces zjednodušování a optimalizace databázových struktur
  • správně navržené (normalizované) tabulky by měly splňovat podmínky pro zařazení do tzv. normálních forem
  • čím je tabulka ve vyšší normální formě, tím lépe by se s ní mělo pracovat
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Cíle databáze

A

Cíle

  • Vytvořit co nejvěrnější obraz v modelovaném světě existujících entitních množin
  • Zajistit interní konzistenci datového modelu resp. databáze
  • Minimalizovat redundance
  • Maximalizovat stabilitu databázových struktur
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Normální formy

A

Normální formy

  • pravidla, která se dodržují při návrhu DB
  • Nejčastěji uváděné jen normální formy 1-3
  • Normální formy 1-4 zkoumají neklíčové položky na PK
  • Poslední 2 pak vztahy uvnitř složených PK
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Normalizace dat

A

Normalizace dat?

  • 1NF
  • 2NF
  • 3NF
  • Boyce-Coddova NF.
  • 4NF
  • 5NF
  • Indexy
  • Použití indexu
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

1NF

A

1NF

Tabulka je v 1NF, pokud neobsahuje opakující se položku nebo skupinu položek. Např. v tabulce Zaměstnanec nesmí být info o tom, na jakém projektu pracuje – pro projekt se musí vytvořit zvlášť tabulka a tyto 2 tabulky se navzájem propojí cizím klíčem.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

2NF

A

2NF

Tabulka splňuje podmínky 2NF, pokud splňuje 1NF + pokud jsou všechny neklíčové položky závislé na celém složeném primárnímklíči. U každého atributu tedy musíme být schopni říci, že se vztahuje k celému PK. (např. nelze mít tabulku Použití, kde máme PK složen z ID_služby a ID_programu a neklíčové atributy se pak vztahují buď k službě, nebo programu – to je špatně, musíme pro službu a program vytvořit vlastní tabulku a spojit je vztahem Použití)

28
Q

3NF

A

3NF

Tabulka splňuje podmínky 3NF, pokud splňuje 2NF + neobsahuje tranzitivní závislosti (závislost jednotlivých neklíčových položek). Příklad: Máme atributy ID (PK), Jméno, Město a PSČ. Město a PSČ jsou vzájemně závislé a tak stačí Město vynechat a mít extra tabulku přiřazující PSČ-Město.

29
Q

Boyce-Coddova NF

A

Boyce-Coddova NF

Eliminuje potenciální redundance v záznamu, kde existuje více variant primárního klíče (kandidátů na PK). Pokud existuje jiná varianta PK, pak ji zvolím a opětovně provedu prověření prvních tří NF.

30
Q

4NF

A

4NF

Umožňuje rozlišení a oddělení nezávislých vícehodnotových atributů tvořících složený PK. Tabulka splňuje podmínky 4NF, pokud splňuje 3NF + popisuje jen jeden fakt či souvislost. Mezi atributy tedy neexistuje vztah one-to-many. Například nemáme atributy [RČ, Jméno, Telefon, Kvalifikace] pokud může mít jeden člověk více kvalifikací. Uděláme si extra tabulku [RČ, Kvalifikace] a původní změníme na [RČ, Jméno, Telefon].

31
Q

5NF

A

5NF

Umožňuje rozlišení a oddělení párových cyklických závislostí, které se objevují ve složeném PK (3 a více atributů). Tabulka splňuje podmínky 5NF, pokud splňuje 4NF + není možno přidat do tabulky nový sloupec bez toho, aby se rozpadla na několik dílčích tabulek. (pokud bychom chtěli přidat nový atribut, tak se tabulka rozpadne na víc tabulek)

32
Q

Indexy

A

Indexy = databázový objekt, sloužící ke zrychlení vyhledávacích a dotazovacích procesů v databázi, definování unikátní hodnoty sloupce tabulky nebo optimalizaci fulltextového vyhledávání.

33
Q

Použití indexu

A

Použití indexu
Na první pohled by se mohlo zdát, že čím víc indexů, tím lepší chování databáze a že po vytvoření
indexů pro všechny sloupce všech tabulkách dosáhneme maximálního zrychlení. Tento přístup naráží
bohužel na dva zásadní problémy:

  • Každý index zabírá v paměti vyhrazené pro databázi nezanedbatelné množství místa
    (vzhledem k paměti vyhrazené pro tabulku). Při existenci mnoha indexů se může stát, že paměť
    zabraná pro jejich chod je skoro stejně velká, jako paměť zabraná jejími daty – zvláště u
    rozsáhlých tabulek (typu faktových tabulek v datovém skladu) může něco takového být
    nepřijatelné.
  • Každý index zpomaluje operace, které mění obsah indexovaných sloupců (INSERT, UPDATE (update však před změnou nejprve vyhledává záznam (de facto provádí SELECT), tam index trochu pomůže)).
    To je dáno tím, že databáze se v případě takové operace nad indexovaným sloupcem musí
    postarat nejen o změny v datech tabulky, ale i o změny v datech indexu.

Pro správné zvolení indexů by ten, kdo databázi navrhuje, měl vědět, jak často se vybírané záznamy z
dané tabulky třídí podle zamýšleného sloupce (a kandidáta na index) a nakolik je důležité, aby
vyhledávání a třídění podle něj bylo rychlé. U některých tabulek, které jsou např. číselníky o stálém
počtu položek, řekněme max. několika desítkách, nemusí být třeba index definován vůbec.

Index je zkrátka pomocná struktura, která může zrychlit hledání (SELECT). Index je výhodný, když předpokládáme, že bude v tabulce hodně dat a když předpokládáme, že budeme data často vyhledávat. Index však využijeme, pouze pokud v dotazu vyhledáváme podle zaindexovaného sloupce

34
Q

Databázové systémy - charakteristika

A

Databáze je definovaná pomocí jistého schématu (který umožňuje porozumět datům v databázi) a existuje nezávisle na aplikačních programech. Centrální správa databáze je organizována prostřednictvím programového vybavení – systému řízení bází dat (SŘBD či anglická zkratka DBMS). Ten systém spolu s databází tvoří databázový systém (DBS). Kvůli volnému používání výše uvedené terminologie, pod pojmem databáze může být myšlen jak SŘBD, tak DBS. („Databázové systémy“ Jaroslav Pokorný a Michal Valenta)

Databáze = integrovaná počítačově zpracovávaná množina persistentních dat

Systém řízení bází dat (SŘBD / DBMS) = množina programových prostředků, který umožňuje:

  • vytvoření databáze
  • použití databáze (manipulaci s daty v databází –S,I,U,D)
  • údržbu a správu databáze
35
Q

Databázový systém (DBS) = SBŘD + Databáze, důvody pro vznik databázových systémů

A

Důvody pro vznik databázových systémů:

  • Vyšší datová abstrakce – SŘDB zahrnují manipulační jazyky pro práci s datovými strukturami vyšší úrovně.
  • Nezávislost aplikačních programů na změnách ve fyzickém uložení dat – při změnách ve fyzické struktuře báze dat není třeba měnit aplikační programy, protože se na data obracejí na logické úrovni.
  • Ochrana dat před neoprávněným přístupem a poruchami – SŘDB kontroluje, zda uživatel je oprávněn používat příslušná data příslušným způsobem, a obsahuje mechanismy pro znovuvytvoření báze dat po selhání systému nebo poškození vnějších médií.
  • Odstranění redundance – každý údaj, i když se vyskytuje několikrát v různém kontextu, je v bázi dat ve většině případů uložen pouze jedenkrát.
  • Sdílení dat – na rozdíl od situace, kdy každý aplikační program vytváří své vlastní datové struktury, při využití SŘDB mohou být taktéž data používána několika uživateli; důležitou funkcí SŘDB je zajištění paralelního přístupu ke stejným datům z několika programů.
  • Podpora transakčního zpracování
  • Údržba integrity databáze
36
Q

Výše uvedené problémy klasických metod hromadného zpracování dat vedly ke vzniku a rozvoji databázových systémů. Mají následující vlastnosti:

A

Výše uvedené problémy klasických metod hromadného zpracování dat vedly ke vzniku a rozvoji databázových systémů. Mají následující vlastnosti:

  • Struktury datových souborů jsou odděleny od aplikačních (uživatelských) programů.
  • Přístup k datům je možný jen prostřednictvím programů databázového systému.
  • Data je možné vyhodnotit jakýmkoliv způsobem.
  • Je umožněn přístup více uživatelů současně a vyřešena ochrana dat před zneužitím.
37
Q

Důležitost databází

A

Důležitost databází:

  • Vzrůstající velikost ukládaných dat
  • Internetová úložiště (FB)
  • Rostoucí složitost a různorodost dat
  • Rostoucí požadavky na výkon a dostupnost
  • Rostoucí závislost na přesné a včasné informace
38
Q

Nezávislost dat

A

Nezávislost dat

Nezávislostí dat se v databázových systémech rozumí možnost změnit definice dat na nižší úrovni abstrakce, aniž by se tím ovlivnila definice na vyšší úrovni abstrakce. Mluvíme o dvou úrovních nezávislosti dat:

  1. Fyzická nezávislost dat umožňuje změnit fyzické schéma a přitom nedojde ke změně logického schématu ani uživatelských aplikačních programů.
  2. Logická nezávislost dat umožňuje změnit konceptuální úroveň popisu dat, aniž by bylo třeba přepisovat aplikační programy. Na externí úrovni se přitom nemění pohled těch uživatelů, jichž se změna logického schématu přímo netýká.
39
Q

Sdílení dat

A

Skutečnost, že se data sdílejí všemi aplikačními programy má kromě snížení redundance také příznivý vliv i na celkovou integrovanost informačního systému. Centralizací dat do sdílené databáze se odpovědnost za správu dat přenesla z jednotlivých agend na databázový systém. V rámci uživatelské organizace se předpokládá, že jeho provoz má na starosti pověřená osoba, tzv. administrátor (správce) databáze. Do jeho kompetence patří vytváření schémat na všech úrovních a definice a popis vazeb mezi jednotlivými úrovněmi. Externí schémata vytváří přitom podle požadavků uživatelů.

40
Q

Transakční zpracování

A

Transakční zpracování

Transakce slouží k zajištění konzistence a řízení víceuživatelského přístupu.
Vlastnosti transakce – ACID:

  • A (atomicity) = transakce je jako celek, musí proběhnout celá nebo žádná
  • C (consistency) = transformuje DB z jednoho konzistentního stavu do jiného konzistentního
  • I (indepedency) = transakce jsou nezávislé, změny prováděné jsou neviditelné pro ostatní transakce
  • D (durability) = efekty potvrzené transakce jsou uložené do databáze
OLAP = zpracování vícedimenzionálních dotazů (datové sklady)
OLTP = zpracování velkého množství relativně malých transakcí
41
Q

Integrita

A

Konzistence databáze= data v databázi zachycují stavy, které jsou v popisovaném světě MOŽNÉ

Integrita databáze= databáze je v konzistentním stavu.

Integritní omezení =pravidla pro zajištění správnosti a konzistence uložených dat:

  • ENTITNÍ – Výskyt každé entity musí být jednoznačně identifikovatelný. Musí existovat primární klíč! (unique)
  • REFERENČNÍ – Cizí klíč obsahuje pouze hodnoty, které existují v jemu odpovídajícím primárním klíči!
  • DOMÉNOVÁ – Atribut může obsahovat pouze přípustné hodnoty omezené integritním pravidlem! (check, trigger)
42
Q

Integrita (celistvost databáze)

A

Integrita (celistvost) databáze je stav, v němž jsou data v plném rozsahu přípustná a využitelná v aplikačních programech a mezi hodnotami položek souborů databáze platí vztahy, které jsou stanoveny k zaručení sémantické korektnosti databáze. Jinak se dá také říci, že je to stav, kdy hodnoty dat jsou správné, konzistentní a aktuální. K narušení integrity může dojít chybami technického i základního programového vybavení, chybami v aplikačních programech a v datech apod. Příkladem integritního omezení je požadavek, aby věk oprávněného voliče bylo celé kladné číslo větší nebo rovné 18. Procedury ukládání dat musí být takové, aby systém řízení báze dat v případě vzniku chyby mohl obnovit data beze ztrát. Z tohoto důvodu je SŘBD vybaven funkcemi kopírování celé databáze anebo jejich částí na záložní paměťové médium. V případě, že došlo ke ztrátě integrity, použije se kopie databáze k její obnově. Vzhledem k většinou velkým rozsahům databáze a z toho vyplývající časové náročnosti kopírování nelze jej provádět příliš často, což způsobuje ztrátu dat, která byla získána v době od posledního kopírování po poruchu. Pokud je riziko ztráty velké anebo má značné důsledky, používají se jemnější kopírovací procedury. Jednou z nich je použití tzv. žurnálové záložní paměti (redo logy), kam se při každé změně dat v databázi zaznamená stav menších oblastí (záznamu, bloku) před změnou a po změně.

43
Q

Náhodný přístup

A

Náhodný přístup

  • Agendové zpracování je zaměřené jednoúčelově a předpokládá, že všechny požadavky na výstupní informace jsou specifikovány předem
  • Při používání programu se velmi často objeví dodatečné požadavky na jeho funkci, jejichž realizace si může vyžádat značné programátorské úsilí
  • V databázovém systému vzhledem k nezávislosti dat na aplikačních programech je snadné napsat nový aplikační program, který zabezpečí provedení požadované akce
  • V mnoha případech jde o požadavek na výběr dat podle zadaného kritéria
  • Většina SŘBD je vybavena speciálními uživatelskými jazyky neprocedurálního charakteru, které jsou orientovány na využití ne-programátory.
  • Možnost realizace náhodného přístupu k databázi výrazně zlepšuje využití dat v informačním systému a je často jedním z hlavních důvodů přechodu na databázovou technologii zpracování dat.
44
Q

Kritéria pro výběr databázového systému

A

Kritéria pro výběr databázového systému

  • Základní funkční a technologická kritéria
  • Architektura
  • jaký typ (relační, objektově relační, síťový, stromový, lineární)
  • jakou podporuje architektury – client/server
  • jaká data podporuje
  • jestli lze používat SQL
  • Rozhraní k HW a SW
  • Výkonnost
  • Zabezpečení a utajení dat – jestli je možné utajení, kódování dat, dešifrování, jaký katalog
  • Rozšířenost
  • Podpora od dodavatele – tuzemské firmy, školení, ceny, možnost ukládat, vyhledávat a třídit česká data, problém s tříděním „ch“
  • Cena
  • Další rozvoj
45
Q

Modely dat a databázové systémy

A

Modely dat a databázové systémy

  • Hierarchické DBMS (1960s)
  • Síťové DBMS (1970s)
  • Relační DBMS (1980s)
  • Objektově Orientované DBMS (1990s)
  • Objektově-Relační DBMS (1990s)
  • XML DBMS (2000s)
  • NoSQL DBMS (2010s) – nerelační (dokumentové) databáze
46
Q

Hierarchické DBS

A

Hierarchické DBS

Data jsou organizována do stromové struktury. Každý záznam představuje uzel ve stromové struktuře. Vzájemný vztah mezi záznamy můžeme označit jako rodič a potomek. Použití tohoto modelu je vhodné tam, kde i popisovaná skutečnost má obdobnou stromovou strukturu. Při pohybu v datech se pohybujeme směrem dolů (od rodiče k potomkovi), nahoru (od potomka k rodiči) nebo na stejné úrovni (od potomka přes rodiče k potomkovi – sourozenci.

Nevýhody tohoto hierarchického modelu:

  • v některých případech nepřirozená organizace dat (zejména obtížné znázornění vztahu mezi více rodiči a více potomky)
  • složité operace vkládání a rušení záznamů.
47
Q

Síťové DBS

A

Síťové DBS

Síťový model dat je v podstatě zobecněním hierarchického modelu dat, který doplňuje o mnohonásobné vztahy, které předchozí model neumožňoval přímou cestou. Tyto propojují záznamy různého či stejného typu, přičemž spojení může být realizováno na jeden nebo více záznamů. Nevýhodou síťové modelu databáze je zejména nepružnost a obtížná změna její struktury.

48
Q

RDBS (relační databázový systém) E. F. CODD

A

Relace lze chápat jako tabulku dat uspořádanou do sloupců (atribut + doména) a řádků (n-tic – n rozměrný vektor). Databázová relace je tabulka, pohled, výsledek dotazu, což nám dává možnost pracovat s výsledky dotazů stejně jako s tabulkou (není podporováno ve všech DBMS). Vzhledem k tomu, že relace je množina, která nesmí obsahovat duplicitní prvky a není uspořádána jinak než do sloupců a řádků, neexistuje první, druhý nebo n-tý řádek. Řádky v relaci nemají specifické pořadí, tudíž nejsou ani dosažitelné číslem řádku, musí existovat nějaká konstrukce, která nám umožní adresovat jednotlivé řádky. Tato konstrukce se nazývá primární klíč.

Primární klíč je atribut, nebo soustava atributů, jejichž hodnoty tvoří jednoznačnou identifikaci řádku relace. Například primárním klíčem v tabulce zaměstnanců bude rodné číslo. Jednoznačnou identifikací manželského páru budou sloupce obsahující r. č. manželů. Každá relace musí obsahovat primární klíč, v nejhorším případě jím jsou všechny atributy. Každý atribut, který je součástí klíče, se nazývá klíčový, ostatní jsou neklíčové.

Ve zkratce se dají zásady relačního modelu zapsat třemi pravidly:

  • Veškerá data se reprezentují ve strukturách se sloupci a řádky, kterým se říká relace.
  • Všechny hodnoty v databázi jsou skalární.
  • Operace se provádějí vždy a pouze nad relací a jejich výsledkem je jiná relace.
49
Q

OODBS (objektově orientované databázové systémy)

A

OODBS (objektově orientované databázové systémy)

Data v OODBS jsou chápána jako objekty odpovídající přímo entitám reálného světa. Objekty zahrnují data i chování, tj. funkčnost ve stávajících RDBS zajištěnou aplikačními programy. Dva způsoby vzniku

  • přidávání databázových vlastností do OO programovacích jazyků (smalltalk –> gemStone C ++ objectStore, Ontos, Versant List Orion )
  • rozšíření relačních DBS o OO vlastnosti (Ingres PostGres SQL Starburst standardizace ve sdružení OMG (Object Management Group)
50
Q

Manifest OODBS (1989)

A

Manifest OODBS (1989)

  • komplexní objekty – kromě n-tic a tabulek i další typy komplexních objektů, např. sestavy či pole. Komplexní objekty je možné navzájem skládat, komplexní objekt může být hodnotou atributu nebo může existovat jako samostatná entita.
  • identita objektů – OODBS má při vytváření objektů generovat jeho OID (unikátní identifikaci v celé DB)
  • logická datová nezávislost – skrývání dat. Hodnoty atributu nejsou přístupné přímo z programovacího jazyka. Je nutné k nim přistupovat přes definované rozhraní.
  • třídy a typy – možnost definice typu (resp. třídy) jako popisu společné struktury množiny objektů se stejnými vlastnostmi.
  • dědění – odvození nových tříd z již existujících.
  • polymorfismus – schopnost operací pracovat v objektech více než jednoho typu.
  • rozšiřitelnost – možnost definovat vlastní základní typy
51
Q

Srovnání relačních a objektových přístupů

A
52
Q

Prvky ORDBS

A

Prvky ORDBS

  • LOB’s (Large object)
    • mechanismus umožňující uchovávat velké objemy dat – dokumentů, map
    • Nelze použít order by ani group by
    • Nelze používat metody
  • UDT – user defined type ( uživatelsky definované typy např. Adresa – město, psč, ulice , č.p.)
  • Collections
    • Varray (variable array)
      • Seřazená kolekce
      • Není možný update
      • nelze se dotazovat na jednotlivé záznamy
    • Nested table („vnořená tabulka“)
      • Neseřazená kolekce
      • lze se dotazovat na jednotlivé záznamy
      • „vnořenost“ je neomezená
  • OIDs („object ID‘s) – objekt v řádku má svoje OID
  • REFs (reference) – logický ukazatel na řádek v tabulce
53
Q

Charakteristika DB systémů:

A
54
Q

Databázové jazyky - základní pojmy

A

Základní pojmy

  • data: formalizované a fyzicky zaznamenané znalosti, poznatky, zkušenosti, výsledky pozorování
  • informace: smysluplná interpretace dat
  • databáze: integrovaná počítačově zpracovaná množina persistentních dat
  • relační model dat: založený na predikátové logice prvního řádu, k manipulaci s daty možno použít relační kalkul nebo operace relační algebry
  • dotazovací jazyk: slouží pro získání dat z databáze; v relační databázi je odpovědí relace, jejíž n-tice splňují nadefinované podmínky
  • systém řízení bází dat (SŘBD): množina programovým prostředků, která umožňuje:
    • vytvoření databáze >> použití databáze (manipulace s daty – výběr, vkládání, update, mazání) >> údržbu a správu databáze
  • databázový systém (DBS): SŘBD + databáze
55
Q

Význam a užití databázových jazyků

A

Význam a užití

  • Prostředek komunikace člověka s databázovým systémem
  • Pravidlo komplexního datového jazyka: Relační systémy mohou podporovat více jazyků a režimů přístupů, ale musí existovat minimálně jeden jazyk, jehož příkazy jsou vyjádřitelné dobře definovanou syntaxí jako řetězce znaků, který podporuje definici dat, manipulaci s daty, ochranu dat a omezení integrity (lze považovat za standard)
56
Q

Základní dělení jazyků podle nejčastěji identifikovaných částí

A

Základní dělení jazyků podle nejčastěji identifikovaných částí

  • DDL (Data Definition Language): definice databázových objektů; příkazy create, alter, drop
  • DML (Data Manipulation Language): manipulace s daty; příkazy select, insert, update, delete
  • DCL (Data Control Language): řízení přístupu k datům; příkazy grant, revoke
  • TCL (Transaction Control Language): řízení transakcí; příkazy commit, rollback, savepoint
57
Q

Příklady využití

A

Příklady využití

  • Databáze jako samostatný prvek – využití pro evidenci a správu dat
  • Databáze jako podpora aplikace – uložení dat do databázové struktury, ze které aplikace čerpá
58
Q

Příklady dotazovacích databázových jazyků 4. generace

A

Databázové jazyky 4. generace (4GL: 4th Generation Language; pokročilé programovací jazyky, které dovolí laikům (neprogramátorům) psát krátké programy extrahující data z databází a vytvářet reporty).

  • FOCUS
  • Informix-4GL
  • Quel
  • Progress 4GL
  • SQL (v současné době nejrozšířenější)
59
Q

Databázový jazyk SQL

A

Standardizovaný dotazovací jazyk používaný pro práci s daty v relačních databázích. SQL je zkratka anglických slov Structured Query Language (strukturovaný dotazovací jazyk).

V 70. letech 20. století probíhal ve firmě IBM výzkum relačních databází. Bylo nutné vytvořit sadu příkazů pro ovládání těchto databází. Vznikl tak jazyk SEQUEL (Structured English Query Language). Cílem bylo vytvořit jazyk, ve kterém by se příkazy tvořily syntakticky co nejblíže přirozenému jazyku (angličtině). Relační databáze byly stále významnější, a bylo nutné jejich jazyk standardizovat. Americký institut ANSI původně chtěl vydat jako standard zcela nový jazyk RDL. SQL se však prosadil jako de facto standard a ANSI založil nový standard na tomto jazyku. Tento standard bývá označován jako SQL-86 podle roku, kdy byl přijat.

Standardy podporuje prakticky každá relační databáze, ale obvykle nejsou implementovány vždy všechny požadavky normy. A naopak, každá z nich obsahuje prvky a konstrukce, které nejsou ve standardech obsaženy. Přenositelnost SQL dotazů mezi jednotlivými databázemi je proto omezená.

60
Q

Standardizace SQL

A

Postupně standardizován organizacemi:

  • ISO: Mezinárodní organizace pro normalizaci (International Organization for Standardization)
  • IEC: Mezinárodní elektrotechnická komise (International Electrotechnical Commision)
  • ANSI: Americká standardizační organizace (American National Standards Institute)
61
Q
A

I přes přesný popis standardů přežívá (z důvodu zpětné kompatibility) řada odchylek – dialektů – implementací jazyka SQL výrobci jednotlivých databázových systémů.

62
Q

Příklady použití SQL - vytvoření tabulky

A

Vytvoření tabulky

CREATE TABLE název tabulky (atribut, typ, PK, NOT NULL…);

CREATE TABLE zamestnanci (ID_zam int primary key, jmeno_zam varchar (20) NOT NULL…);

Smazání tabulky

DROP TABLE název tabulky

DROP TABLE zamestnanci

Vložení dat

INSERT INTO název tabulky (název atributu) VALUES (hodnota atributu);

INSERT INTO zamestnanci (ID_zam, jmeno_zam) VALUES (1, ‘Novák‘);

Výběr dat

SELECT * FROM název tabulky;

SELECT * FROM zamestnanci;

Aktualizace dat

UPDATE název tabulky SET název atributu = nová hodnota WHERE podmínka;

UPDATE zamestanci SET jmeno_zam = Nováková WHERE ID_zam = 1;

Mazání dat

DELETE FROM název tabulky WHERE podmínka;

DELETE FROM zamestnanci WHERE jmeno_zam=‘Novák‘;

63
Q

PL/SQL

A

Procedural Language / Structured Query Language je procedurální nadstavba jazyka SQL od firmy Oracle založená na programovacím jazyku Ada.

Pomocí PL/SQL je možno vytvářet:

  • Uložené procedury a funkce
  • Programové balíky
  • Triggery
  • Uživatelsky definované datové typy

Tato nadstavba se rozšířila a její deriváty převzaly i jiné relační databáze.

64
Q

OQL

A

Object Query Language (OQL) je standardizovaný dotazovací jazyk pro objektově-orientované databáze vytvořený podle SQL. OQL byl vyvinut Object Data Management Group (ODMG). Kvůli jeho komplexitě zatím žádný výrobce neimplementoval OQL v úplnosti. OQL ovlivnil návrh některých novějších dotazovacích jazyků jako JDOQL a EJB QL.

Jazyk OQL je záměrně navržen tak, aby byl velmi podobný jazyku SQL-92. Dokonce platí, že část syntaxe SQL, která se týká manipulace s daty, je kompletně obsažena v OQL. Proto je například řada dotazů konstrukce select-from-where zcela shodná v SQL i OQL. Na druhou stranu se jazyk OQL nezabývá tvorbou datových struktur. To znamená, že příkazy SQL týkající se definice dat (např. create-table, create-index atd.) nemají v OQL žádný ekvivalent. K definici tříd, kolekcí a metod jazyk OQL nejde použít. Počítá se zde buď s nějakým běžným objektovým programovacím jazykem jako např. Java, C#, C++, Smalltalk

Databázovým dotazem je nejen konstrukce select-from-where, ale každý výraz, který reprezentuje nějaká data. Proto například prostý výraz v OQL zaměstanci se v SQL musí napsat jako select * from zaměstnanci

65
Q

JPQL

A

JPQL

Java Persistence Query Language je platformě nezávislý objektově-orientovaný dotazovací jazyk definovaný jako součást specifikace Java Persistence API (JPA). JPQL se používá k dotazování se na entity uložené v relační databázi. Je silně inspirován SQL a má podobnou syntaxi.

JPQL odstiňuje programátora od specifik konkrétního datového úložiště. Jinými slovy, programátor se nestará o to, zda jsou v konečném důsledku dotazy prováděny nad Oracle nebo MySQL databází. Stále píše stejné dotazy. Tato vlastnost je velice pohodlná, může však mít i jistá omezení. Každý výrobce databází přináší do svého produktu jinou funkcionalitu, kterou se odlišuje od ostatních.

Používáním standardních „univerzálních“ dotazů pomocí JQPL o tyto výhody přichází. Někdy se v této souvislosti hovoří o zákonu netěsných abstrakcí. Ten ve zkratce říká, že jakákoli abstrakce vede k zúžení funkcionality nebo k neefektivnímu využívání zdrojů. Jako příklad se často uvádí tato abstrakce SQL:

  • WHERE a=b AND b=c
  • WHERE a=b AND b=c AND a=c

Matematicky jsou tyto zápisy totožné. Může však u některých databází docházet v případě použití druhého zápisu k výraznému zlepšení výkonnosti zpracování.

66
Q

XQuery

A

XQuery je dotazovací a funkcionální programovací jazyk navržený pro dotazování na kolekce dat v XML. XQuery poskytuje prostředky pro extrahování a manipulaci dat z XML dokumentů nebo jakéhokoli datového zdroje, který může být jako XML zobrazen, například relační databáze nebo některé dokumenty (např. OpenOffice, MS Office 2007,…).

XQuery používá syntax jazyka XPath pro adresování konkrétních částí XML dokumentů. To je doplněno SQL-podobnými „FLWOR výrazy“ pro provádění Joinů. FLWOR výraz je sestaven z pěti klauzulí, po kterých je pojmenován: FOR, LET, WHERE, ORDER BY, RETURN.

Informační systémy a technologie (12 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions