14 RNDr. Ondřej Zýka,

Design databáze

MI-DSP – 2013/14 RNDr. Ondřej Zýka, [email protected]

Prostředí datově orientovaného systému Etapy životního cyklu

Komponenty

Skupiny uživatelů

Vlastníci aplikace

Plánování

Aplikační programy

Vývoj

Interface

Testování

DBMS

Provozování

Data

Udržování

Hardware

Ukončení používání

Architekti (IT, Aplikační, …) Datový architekt Vývojáři Administrátoři databází Systémoví administrátoři Koncoví uživatelé

Pravidla relačních databází (E.F. Codd) #

Název

Popis

1

Informace

Všechny informace musí být logicky reprezentovány jako hodnoty v sloupcích řádků v tabulkách

2

Přístup

Každá hodnota je přístupná přes jméno tabulky, sloupce a hodnotu primárního klíče

3

Null

Hodnota null musí být ošetřana univerzálně nezávisle na datových typech

4

Metadata

Metadata musí být prezentována kjako tabulky v databázi

5

Jazyk

Musí rozumět deklarativnímu jazyku pro definici dat, view a integrity, pro manipulaci s daty a pro řízení transakcí

6

Update

Každé teoreticky updatovatelné view musí být možné updatovat

7

IUD

Musí být podporovány množinové operace pro IUD

8

Fyzická nezávislost

Aplikační programy musí být nezávislé na fyzickém hardware.

9

Logická nezávislost

Aplikační programy musí být nezávislé na změnách mimo použitou datovou strukturu.

10

Integritní nezávislost

Integritní omezení musí být uloženy v systému, nikoliv v aplikaci.

11

Nezávislost na umístění

Koncové aplikace musí být nezávislé na umístění databáze

12

Konzistence

Systém musí vynucovat integritní omezení i při přístupu na nejnižší úrovni.

Návrh databáze o Čtyři kroky – – – –

o o o o

Shromáždění business požadavků Konceptuální model Logický model Fyzický model

Modelování od začátku nebo rozvoj stávajících systémů Nutnost začlenění okolních systémů (prostředí) Vazba na logický model organizace Vazba na existující datové modely

Shromáždění business požadavků o Cíle – Pochopit business doménu – Porozumět potřebám a požadavkům zadavatelů a uživatelů – Ověřit pochopení zadání

o Prostředky – – – – – –

Interview Studium a dokumentace systémů Spolupráce s experty v business oblasti Informace o organizační struktuře a další dokumenty Data assesment Review stávajících systémů a procesů

o Výstup – Prioritizovaný seznam požadavků – Dokument popisující doménu (byznys slovník) – Data-flow diagram

Data-flow diagram o Data-flow diagram popisuje – – – – – –

S jakými daty se pracuje Kdo data vytváří Kdo a jak data zpracovává (modifikuje) Kde jsou data uložena Kdo data používá Interface na úrovni dat

o Použití – – – – –

Datové toky na různých úrovních granularity Podnikové toky dat (obchodní procesy) Toky dat na technické úrovni Popisy ETL procesů Popisy integračních procesů

o Ověření – – – –

Všechna data jsou definována Persistentní data jsou uložena Každá data mají zdroj Pro každá data existuje odběratel

Data-flow diagram - příklad Decomposition Level 2 1.1.1 CUSTOMER

databáze/ soubor

CUSTOMER_ORDER

Place Orders

[BOOK_ORDER]

Book Supplier

+ 1.1.2 Receive Orders

+

Book Shipment Invoice

[SHIPMENT]

funkce

1.1.3 Process Invoices

+

Book Supplier

datová entita/ business object

vstup/výstup

[PAYMENT] Book Supplier

Seznam požadavků

Seznam požadavků o o o o o o o

ID požadavku Krátký popis Podrobné vysvětlení Oblast / systém Vazba na další požadavky Zadavatel Priorita

o Funkční / nefunkční požadavky

Konceptuální model o Cíle – – – –

Určit entity a jejich atributy U atributů určit jejich hodnoty a vlastnosti U entit určit jejich potenciální klíče (identifikátory) Identifikovat vazby mezi entitami • Kardinalita relace • Jméno relace • Popis (role)

o Výstupy – ER diagram

o Formální ověření E/R diagramu – – – – –

Mezi každými dvěma entitami je maximálně jedna relace. Neexistuje cyklická závislost. Entity s relací typu 1:1 zřejmě budou tvořit pouze jednu entitu. Žádná entita nemá atribut, který je kandidátním klíčem jiné entity. Nepřímé relace jsou asi zbytečné.

Konceptuální model

Notace Mnoho standardů a dodavatelských specifik. o

UML – notace dle standardu UML, použita ve všechny nástroje podporující UML.

o

Information Engineering – standard používaný v mnoha nástrojích. Existuje několik verzí. Obecně, entity jsou obdélníka a relace jsou linky s různými zakončeními.

o

IDEF1X – standardní notace pro modelování relací a entit. Symboly označují kombinaci volitelnosti a kardinality entity.

o

Barker – Vytvořena Richardem Barkerem. Používaná zejména case nastroji Oracle. Speciální notace pro dědičnost, vlastní notace pro násobnost a speciální značky pro atributy.

o

Filtered IE – pouze v Embarcadero. Nezobrazuje cizí klíče.

o

Entity/Relationship – Sybase specific, Entity/Relationship je speciální verze IE notace.

o

Merise – používá asociace místo relací.

o

Crow's Feed – Jedna z verzí IE notace, tuto notaci používá FSLDM.

Násobnost a volitelnost CAR

CAR

o Nejvíce jedno auto

o Právě jedno auto

CAR

o Libovolný počet aut

CAR

o Alespoň jedno auto

Notace entit a atributů

Notace - příklady

Allowed multiplicities

N/A substituted by

Not Used Used Not Used because not needed

Pravidla pro čtení relací

Reading direction

Assertion 2: "Each LINE ITEM must be part of exactly one ORDER "

LINE ITEM Line number Quantity Price Delivery date

ORDER part of 0..*

1 Order number Order date composed of

Assertion 2: "Each ORDER may be composed of one or more LINE ITEMS "

Pravidla pro čtení

Vytvoření logického modelu o Cíle – Vytvořit platformově nezávislý logický datový model

o Postup – Převést entity na tabulky – Rozhodnout, jak se bude pracovat se složitými atributy – Rozhodnout, jak se bude pracovat s atributy nabývajícími více hodnot – Výběr primárního klíče – Převést binární relace (závislosti) typu 1:n na cizí klíče – Vyřešit n-ární relace a relace typu n:n – Rozhodnout o způsobu reprezentace subtypů – Normalizace modelu

o Výstup – Logický datový model

Kritéria pro výběr primárního klíče

o Primární klíč: – – – – –

musí mít vždy definovanou hodnotu (not null), musí mít stálou hodnotu (během celého životního cyklu řádku), musí být co možná nejmenší, nesmí obsahovat žádné zakódované informace, musí být přístupný pro všechny uživatele.

o Umělý klíč – Nevýhody: přidává sloupec do tabulky (s indexem), hodnoty nemají význam pro uživatele – Výhody: snadná implementace rozhraní, uniformní řešení

Vazba na objektové modelování o Object-relational impedance mismatch o Declarative vs. imperative interfaces – RM – data jako interface

o Schema bound – RM – Sloupec k jedné tabulce, tabulka do schématu, OOM – dědičnost objektů

o Access rules – RM – relační algebra, OOM – volnější a složitější konstrukty

o Relationship between nouns and actions – OOM - úzká vazba mezi objekty a operacemi

o Uniqueness observation – RM – identifikace na základě klíče s jasným obsahem

o Normalization – OOM – nepoužívá se normalizace

o Schema inheritance – RM – nepoužívá se

o Structure vs. Behaviour – OOM – údržba, srozumitelnost, upravovatelnost, rozšiřitelnost, reuse, RM – logická integrita, efektivita, fault-tolerance

o Set vs. graph relationships

Převod binární relace 1:N na cizí klíč o Slabá relace (neidentifikující relace) o PICTURE je nezávislá entita (existují samostatné instance entity PICTURE

Převod závislosti na cizí klíč o Silná (identifikující vazba, závislost) o PICTURE je závislá entita (neexistují samostatné instance entity PICTURE) AU T H O R

AU T H O R

AU T H O R ID

AU T H O R ID

L AS T N AME

L AS T N AME

F IR S T N AME

F IR S T N AME

P H O N E N U MB E R

P H O N E N U MB E R

AD D R E S S

AD D R E S S

P IC T U R E P IC T U R E ID F O R MAT B Y T E S IZ E P IX E L W ID T H P IX E L H E IG H T

P IC T U R E AU T H O R ID P IC T U R E ID F O R MAT B Y T E S IZ E P IX E L W ID T H P IX E L H E IG H T

Relace typu n:n AUTHOR AUTHOR ID LAST NAME FIRST NAME PHONE NUMBER ADDRESS

AUTHOR AUTHOR ID LAST NAME FIRST NAME PHONE NUMBER ADDRESS

BOOK BOOK ID TITLE CATEGORY QUANTITY SOLD

AUTHOR-BOOK

Associative entity

BOOK BOOK ID TITLE CATEGORY QUANTITY SOLD

Rozhodnutí o reprezentaci dědičnosti o Několik používaných možností

o V jedné tabulce: L-schéma o Ve více tabulkách – Všechny atributy – Jenom vlastní atributy

První normální forma

o Tabulka je v první normální formě, když každý sloupec obsahuje právě jeden atomický datový typ, který již nemá vnitřní strukturu z pohledu businessu.

o Pro rozhodnutí o primárních a cizích klíčích musí být tabulka v prvním normálním tvaru.

Vytvoření fyzického modelu o Cíle – Vytvořit fyzický model s ohledem na specifika aplikace a použitý typ databáze, použitý hardware

o Postup – – – – – – – – –

Tabulky (jmenné konvence) Datové typy Vytvoření procesní matice Rozhodnutí o struktuře tabulek Rozhodnutí o primárním klíči (indexu) Implementace business pravidel - constraints Indexy, partitioning, Denormalizace, uložení redundantních dat, spojení tabulek Fyzické uložení tabulek

o Výstup – Fyzický datový model – Implementační skripty

Tabulky (jmenné konvence) o o o o

Case sensitive/case insensitive servery Omezení délky jména tabulek (Oracle 30 znaků) Omezení délky jmen sloupců Omezení na jmenné prostory (tabulky, view, indexy, procedury, …) o Porozumění modelu – – – –

Datové tabulky Číselníky Logy Uživatelské tabulky

o Natural join

Datové typy o Domain – uživatelské datové typy – + lepší porozumění – + zajištění konzistence – - nároky na údržbu

o Char, varchar, nvarchar, … o Numerické datové typy – int, tinyint, bigint, numeric(p,s), …

o Datum – rozsah, přesnost, způsob práce – Timestamp – je to čas nebo není

o Binary, image, text, memo, … o Boolean - raději "column_name" CHAR(1) default 'A' not null constraint CKC_check_name check ("column_name" in ('A','Y'))

o Identity, Autoincrement o NULL, Not null, Default value o Speciální datové typy

Procesní matice

Rozhodnutí o struktuře tabulek o Cíle: – Minimalizovat velikost – Použít optimální přístupové metody

o Standardní tabulka – Insert, Delete, Update, Scan, Index

o Index-organized tables (Clustered index) – – – –

+ menší + rychlejší přístup po indexu - náročnější insert, delete (update) Oracle – novější implementace, podpora 7x24

Implementace business pravidel Domain integrity - Check – Na úrovni sloupce • Null/Not null • Default • Check (format)

– Na úrovni řádku

o Entity integrity - primary key – implementováno unikátním indexem na not null sloupcích – záznam v katalogu

o Unikátnost hodnot – implementováno unikátním indexem

Referenční integrita o Implementace foreign key – – – –

Deklarativní definice Použití triggerů Použití uložených procedur Kód aplikace

o Co se stane když – Primární klíč se přidá/změní/zruší – Cizí klíč se přidá/změní/zruší

Typy referenčních integrit Constraint

Cascade update / delete

Cascade Null

Cascade Default

Automatic insert

Bez omezení

Restriktivní

Insert PK

Zachování PK

Zachování PK

Zachování PK

Zachování PK

Zachování PK

Zachování PK

Zachování PK

Insert FK

Pouze existující hodnoty PK


Existující hodnoty PK nebo Null

Existující hodnoty PK nebo Default

Existující hodnoty nebo přidá řádek s PK

Bez omezení (sirotci)


Update PK

Pouze pokud nemá vazbu

Změní i odpovídající FK

Odpovídající FK změní na Null

Odpovídající FK změní na Default



Není povoleno

Update FK

Jen na existující hodnoty


Jen na existující hodnoty PK nebo Null

Jen na existující hodnoty PK nebo Default

Existující hodnoty nebo přidá řádek s PK



Delete PK


Delete všech řádků s odpovídajícím FK

Odpovídající FK změní na Null

Odpovídající FK změní na Default



Není povoleno

Delete FK

Bez omezení

Bez omezení

Bez omezení

Bez omezení

Bez omezení

Bez omezení

Bez omezení

Důsledky použití integritních omezení

+ zaručují konzistentní model - zvyšují výpočetní složitost i v případě, kdy nedochází ke změnám (Oracle not null)

- komplikují údržbu povolení/zakázání ověřování integritních omezení

Denormalizace o Partitioning – Horizontální – Vertikální

o Uložení vypočtených hodnot o Eliminace nákladných joinů

Horizontální rozdělení tabulek o Přístupy pouze na část tabulky

o Příklady: – Aktivní a neaktivní položky – Historické záznamy

o Možnosti – Rozdělení tabulek – Přidání tabulky (duplicitní záznamy) – Partitioning

o Synchronizace – Table partitioning – Triggery – Aplikační logika

Rozdělení tabulky Rozdělení tabulky

Part 1

Part 1 Table

Part 2

View

Part 3

Výhody práce s menším množstvím dat méně problémů se zamykáním lepší řízení indexů možnost detailní optimalizace Nevýhody nutnost synchronizace – triggery, aplikační logika Náročnější údržba

Table

Partitioning o Transparentní z pohledu aplikace Part 1

o Rozdělení dle daného rozsahu nebo hodnot o Dynamicky podle hodnot – Dynamicky vytvářeno pro každý měsíc – Nejčastější použití

o Podle hash klíče (určuje se pouze počet partitions) o Více úrovňový partitioning – Podle času, podle pobočky

o Možnost individuálního řízení partition o Omezený počet partition podle implementace

Part 2 Part 3 Part 4

Vertikální rozdělení tabulek o Přístupy pouze na některé sloupce tabulky o Příklady: – Bloby, obrázky, popisy

o Možnosti – Rozdělení tabulek – Přidání tabulky (duplicitní záznamy) – Vytvoření indexu

o Synchronizace – Triggery – Aplikační logika

Rozdělení tabulky Rozdělení tabulky

Table

P a r t

P a r t

P a r t

1

2

3

View

Table

Výhody práce s menším množstvím dat méně problémů se zamykáním možnost optimalizace Nevýhody nutnost synchronizace – triggery, aplikační logika náročnější údržba

P a r t 1

Přidání indexů o Transparentní z pohledu aplikace

o o o o

Jeden clustrovaný index Libovolný počet dalších indexů Automatická údržba Pokrývající dotazy

o Nároky na diskový prostor o Snížení výkonu pro OLTP aplikace

I n d e x

I n d e x

1

2

Uložení vypočtených dat o Přidání sloupce o Přidání tabulky o Synchronizace – Trigerry – Uložené procedury – Aplikační logika

o Nutno zavést procedury pro údržbu a resynchronizaci

Materializovaná view o Transparentní z pohledu aplikace

o Automatické řízení výpočtu view o Nákladné výpočty, nutnost možnosti řízení výpočtů asynchronně o Duplicitní uložení dat – nároky na diskový prostor

Eliminace nákladných joinů o Neustálé dotahování hodnot z číselníků

o Omezení datových serverů (Sybase třicet tabulek v jednom joinu) o Suptype/supertype vazba

o Možnosti – Redundantní data – Spojení tabulek

Fyzické uložení tabulek o Cíl – Distribuce zátěže na co nejvíce fyzických disků

o o o o o o

Rozložení tabulek/indexů na disky Možnosti datových serverů (tablespace, segment) Možnosti hardware (SAN, NAS, diskové pole) Pouze RAID 1+0 Vazba na počet procesorů Možnosti paralelního zpracování datového serveru

B-tree index – příklad kořen

vnitřní blok indexu

listová úroveň indexu

data

Blok 1212 Blok 1132 Blok 1007

klíč

řádek blok Blok 1001

Bennet

Chet

1421,1 1007

Karsen

Kit

1876,4 1306

Smith

Ade

1242,3 1062

Bennet

Chet

1421,1 1132

Fox

John

1317,3 1133

Hunter

Leon 1213,1 1127

Bennet

Chet

1421,1

Burns

Saly

1409,4

Claim

Dave

1129,3

Dull

Rob

1409,1

Larry

John

254

A3

Jetkins

Paul

244

C3

White

Susan

156

A1

Blok 1213 Blok 1133

Blok 1306 Karsen

Kit

1876,4 1198

Larn

Pard

1451,2 1199

Peters

Mary 1856,4 1200

Hunter

Leon

124

A3

Fox

John

1317,3

Green

Mitch

125

B1

Greane

David

1876,4

Smith

Ade

156

A3

Green

Mitch

1213,2

Greene

Joe

1409,2 Blok 1421

Blok 1127

Hunter

Leon 1213,1

Jetkins

Paul

1212,2

Bennet

Chet

101

B2

Ringer

John

144

C1

Blok 1409

INSERT INTO user VALUES (′Burns′, ′Saly′,128,′A1′)

Dull

Rob

128

B1

Greene

Joe

142

A2

Port

Joe

156

C3

Burns

Saly

128

A1

Clustered index – příklad kořen

vnitřní blok indexu

listová úroveň indexu

Blok 1132

klíč

blok Blok 1007

Blok 1001 Bennet

Chet

1007

Karsen

Kit

1306

Smith

Ade

1062

Bennet

Chet

1132

Fox

John

1133

Hunter

Leon 1127

Bennet

Chet

101

B2

Burns

Saly

128

A1

Claim

Dave

123

A1

Blok 1133 Blok 1306 Karsen

Kit

1198

Larn

Pard

1199

Peters

Mary 1200

Fox

John

100

A0

Greane

David

111

E3

Green

Mitch

125

B1

Greene

Joe

156

C3

Blok 1127

Hunter

Leon

122

A3

Jetkins

Paul

124

A5

INSERT INTO user VALUES (′Burns′, ′Saly′,128,′A1′)

Indexy – přístupové metody o Typy indexů – B-tree • Clustered/nonclustered – Bitmapové indexy

o Standardní index – – – –

Hledání podle indexu Scan nejnižší úrovně Dotaz pokrytý indexem Ignorování indexu – scan dat

o Clustered index – Hledání podle indexu – Scan dat od nalezeného řádku – Scan nejnižší úrovně (scan dat)

Použití indexů o Select – Pokrývající query

o Group by o Order by o Join o Nepoužívat indexy pro malé tabulky o Selektivita indexů

Data uložená po sloupcích

o Vertica

o SAP Sybase IQ

o Oracle – bitmapové indexy

Tabulka – relační uložení dat ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID ID ID ID ID ID ID ID

NAME NAME NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID ID ID

NUMBER VARCHAR2(50 BYTE) VARCHAR2(500 BYTE) NUMBER VARCHAR2(20 BYTE) NUMBER VARCHAR2(40 BYTE) NUMBER NUMBER NUMBER

Struktura tabulky

Datové bloky

DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH NAME DESCRIPTION QTY COLOUR PROVIDER DESCRIPTION QTY COLOUR PRICE PRICE PROVIDER WIDTH WIDTH HEIGHTHEIGHT DEPTH DEPTH NAME DESCRIPTION QTY COLOUR PROVIDER DESCRIPTION QTY COLOUR PRICE PRICE PROVIDER WIDTH WIDTH HEIGHTHEIGHT DEPTH DEPTH NAME DESCRIPTION QTY COLOUR PROVIDER DESCRIPTION QTY COLOUR PRICE PRICE PROVIDER WIDTH WIDTH HEIGHTHEIGHT DEPTH DEPTH NAME DESCRIPTION QTY COLOUR PROVIDER DESCRIPTION QTY COLOUR PRICE PRICE PROVIDER WIDTH WIDTH HEIGHTHEIGHT DEPTH DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT HEIGHT DEPTH DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH WIDTH HEIGHT HEIGHT DEPTH DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH NAME DESCRIPTION PRICE PROVIDER WIDTH ID NAMEQTY COLOUR DESCRIPTION QTY COLOUR PRICE HEIGHT PROVIDERDEPTH WIDTH HEIGHT ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT

DEPTH DEPTH DEPTH DEPTH DEPTH DEPTH DEPTH DEPTH

Tabulka – data uložená po sloupcích ID NAME DESCRIPTION QTY COLOUR PRICE PROVIDER WIDTH HEIGHT DEPTH ID ID ID ID ID ID ID ID

NUMBER VARCHAR2(50 BYTE) VARCHAR2(500 BYTE) NUMBER VARCHAR2(20 BYTE) NUMBER VARCHAR2(40 BYTE) NUMBER NUMBER NUMBER ID ID ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME NAME NAME

ID ID ID NAME ID NAME ID NAME ID NAME ID COLOUR NAME ID COLOUR NAME COLOUR NAME COLOUR NAME COLOUR COLOUR COLOUR COLOUR

Struktura tabulky

Datové bloky

ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID NAME NAME NAME NAME NAME NAME NAME ID ID ID ID ID ID ID NAME NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME ID NAME COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR NAME NAME NAME NAME NAME NAME NAME ID ID ID ID ID ID ID NAME COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR NAME NAME NAME NAME NAME NAME NAME COLOUR NAME COLOUR COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR NAME COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR NAME QTY NAME QTY NAME QTY NAME QTY NAME QTY NAME QTY NAME QTY NAME QTY QTY COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR QTY QTY QTY QTY QTY QTY QTY QTY QTY COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR QTY QTY QTY QTY QTY QTY QTY QTY QTY COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR QTY QTY QTY QTY QTY QTY QTY QTY QTY COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR COLOUR QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY QTY

QTY QTY QTY QTY QTY QTY QTY QTY


SELECT Count(*) FROM sale where color = ′Green′ SELECT Count(*) FROM sale where color in (′Green′, ′Red′)


SELECT SUM(qty) FROM sale

(2 * 64) + (3 * 32) + (2 * 16) + (1 * 8) + (3 * 4) + (2 * 2) + (3 * 1) = 283

Bitmapové indexy o Rychlé pro sloupce s malou kardinalitou o Rychlé pro operace na málo sloupcích

o Složitý update – Zamykání a rebuild velkých bloků

o Pomalé pro dotaz na jeden konkrétní řádek

Metody ukládání bitmapových indexů o Samé nuly nebo jedničky – Bloky se neukládají – pouze indikátor jejich existence

o Do 20% nul nebo jedniček – Data se kódují jako souvislé množiny hodnot

o Mezi 20% a 80% jedniček – Ukládá se skutečná mapa hodnot

Typy sloupcových indexů o Mnoho různých typů – Více indexů na jednom sloupci

o o o o o o

Bitový index pro sloupce s malou kardinalitou Bitový index pro sloupce s velkou kardinalitou a malou selektivností Indexy pro sloupce s velkou kardinalitou G-Array (příbuzný B-tree) Prosté komprimované uložení dat (pro textové řetězce) Speciální indexy pro čas a datum Indexy pro joiny, porovnání a další operace

Sybase IQ – uložení dat a indexů

500

Velikost databáze (GB)

450

Indexy Sumace Čistá data

400 350 300 250 200 150 100 50 0 Čistá data

CBRD

o Indexy jsou už data o Nízké náklady na uložení dat o Rychlé zpracování malého množství dat

Tradiční RDBMS

Co si zapamatovat o o o o o o o o o o o o o o o

Jaké jsou hlavní kroky při návrhu datového modelu Co to je konceptuální model a co obsahuje Co je cílem sběru byznys požadavků při vytváření konceptuálního modelu Co je logický model a co obsahuje Jaké aktivity je nutné provést při převodu konceptuálního datového modelu na logický datový model Jaké požadavky je potřeba brát v úvahu při výběru primárních klíčů Jaké jsou hlavní rozdíly mezi relačním a objektově orientovaném modelování Kdy a proč se vytváří fyzický datový model Které aktivity je nutné provést při převodu logického datového modelu na fyzický datový model Co to je denormalizace Jaké typy denormalizace znáte Jaký je rozdíl mezi strukturou tabulky s klastrovaným a neklastrovaným indexem K čemu slouží indexy a pro jaké přístupové metody k datům se používají Jak vypadají bitmapové indexy Co to je sloupcové uložení dat (sloupcové indexy)

www.profinit.eu

Diskuse

14 RNDr. Ondřej Zýka,

Recommend Documents