Design databáze. RNDr. Ondřej Zýka

Design databáze

RNDr. Ondřej Zýka

1

Návrh databáze  Čtyři kroky  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

2

2

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

 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ů

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

3

Data-flow diagram 

Data-flow diagram popisuje      



Použití     



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 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ů

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 4

4

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

5

5

Seznam požadavků

6

6

Seznam požadavků  ID požadavku  Krátký popis  Podrobné vysvětlení

 Oblast / systém  Vazba na další požadavky  Zadavatel  Priorita  Funkční / nefunkční požadavky

7

7

Konceptuální model  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)

 Výstupy  ER diagram

 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é. 8

8

Konceptuální model

9

9

10

10

Notace Mnoho standardů a dodavatelských specifik. 

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



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.



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



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.



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



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



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



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

11

11

Násobnost a volitelnost CAR

CAR

 Nejvíce jedno auto

 Právě jedno auto

CAR

 Libovolný počet aut CAR

 Alespoň jedno auto 12

12

Notace entit a atributů

13

13

Notace - příklady

Allowed multiplicities

N/A substituted by

Not Used Used Not Used because not needed

14

14

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 "

15

15

Pravidla pro čtení

16

16

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

 Postup         

Převést entity na tabulky Rozhodnout, jak se bude pracovat se složitými atributy Použít vhodné patterny Rozhodnout, jak se bude pracovat s atributy nabývajícími více hodnot Výběr primárních klíčů 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

 Výstup  Logický datový model 17

17

Kritéria pro výběr primárního klíče  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.

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

18

18

Vazba na objektové modelování 

Object-relational impedance mismatch



Declarative vs. imperative interfaces 



Schema bound 



RM – nepoužívá se

Structure vs. Behaviour 



OOM – nepoužívá se normalizace

Schema inheritance 



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

Normalization 



OOM - úzká vazba mezi objekty a operacemi

Uniqueness observation 



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

Relationship between nouns and actions 



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

Access rules 



RM – data jako interface

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

Set vs. graph relationships 19

19

Převod binární relace 1:N na cizí klíč

20

20

Převod závislosti na cizí klíč

AU T H O R

AU T H O R

A U T H O R ID

A U T H O R ID

LAS T N AME

LAS T N AME

F IR S T N A M E

F IR S T N A M E

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

P IC T U R E ID

A U T H O R ID

F O R MAT B Y T E S IZ E P I X E L W ID T H

P IC T U R E I D

P IX E L H E IG H T

F O R MAT B Y T E S IZ E P IX E L W I D T H P IX E L H E I G H T 21

21

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

BOOK BOOK ID TITLE CATEGORY QUANTITY SOLD

Associative entity 22

22

Rozhodnutí o reprezentaci dědičnosti  Několik používaných možností  V jedné tabulce: L-schéma  Ve více tabulkách  Parent  pouze ID  Společné atributy

 Child  Všechny atributy  Jenom specifické atributy

23

23

První normální forma

 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.  Business pohled je podstatný pro rozhodnutí o první normální formě.

24

24

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

 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

 Výstup  Fyzický datový model  Implementační skripty

25

25

Tabulky (jmenné konvence)  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, …)  Porozumění modelu    

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

 Natural join 26

26

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

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

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

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

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

27

Procesní matice

28

28

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

 Standardní tabulka  Insert, Delete, Update, Scan, Index

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

29

29

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

30

30

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′) 31

31

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

 Na úrovni řádku

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

 Unikátnost hodnot  implementováno unikátním indexem

32

32

Referenční integrita  Implementace foreign key  Deklarativní definice  Použití triggerů  Použití uložených procedur

 Kód aplikace

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

33

33

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

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)

Pouze existující hodnoty PK

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

Pouze pokud nemá vazbu

Bez omezení (sirotci)

Není povoleno

Update FK

Jen na existující hodnoty

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

Bez omezení (sirotci)

Jen na existující hodnoty

Delete PK

Pouze pokud nemá vazbu

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

Pouze pokud nemá vazbu

Bez omezení (sirotci)

Není povoleno

Delete FK

Bez omezení

Bez omezení

Bez omezení

Bez omezení

Bez omezení

Bez omezení

Bez omezení

34

34

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í

35

35

Denormalizace  Partitioning  Horizontální  Vertikální

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

36

36

Horizontální rozdělení tabulek  Přístupy pouze na část tabulky  Příklady:  Aktivní a neaktivní položky  Historické záznamy

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

 Synchronizace  Table partitioning  Triggery  Aplikační logika

37

37

Rozdělení tabulky Rozdělení tabulky

Part 1

Part 1 Table

Part 2

View

Table

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

38

38

Partitioning  Transparentní z pohledu aplikace Part 1

 Rozdělení dle daného rozsahu nebo hodnot

Part 2

 Dynamicky podle hodnot

Part 3

 Dynamicky vytvářeno pro každý měsíc

Part 4

 Nejčastější použití

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

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

39

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

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

 Synchronizace  Triggery  Aplikační logika

40

40

Rozdělení tabulky Rozdělení tabulky

Table

P a r t

P a r t

P a r t

1

2

3

View

Table

P a r t 1

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 41

41

Přidání indexů  Transparentní z pohledu aplikace  Jeden clustrovaný index

I n d e x

I n d e x

 Libovolný počet dalších indexů

1

2

 Automatická údržba  Pokrývající dotazy

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

42

42

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

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

43

43

Materializovaná view  Transparentní z pohledu aplikace  Automatické řízení výpočtu view

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

44

44

Eliminace nákladných joinů  Neustálé dotahování hodnot z číselníků  Omezení datových serverů (Sybase třicet tabulek v jednom joinu)  Suptype/supertype vazba  Možnosti  Redundantní data  Spojení tabulek

45

45

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

 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

46

46

Indexy – přístupové metody  Typy indexů  B-tree  Clustered/nonclustered

 Bitmapové indexy

 Standardní index  Hledání podle indexu  Scan nejnižší úrovně

 Dotaz pokrytý indexem  Ignorování indexu – scan dat

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

47

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

 Group by  Order by  Join  Nepoužívat indexy pro malé tabulky

 Selektivita indexů

48

48

Data uložená po sloupcích

 Vertica

 SAP Sybase IQ

 Oracle – bitmapové indexy

49

49

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

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

Datové bloky

DEPTH DEPTH DEPTH DEPTH DEPTH DEPTH DEPTH DEPTH

50

50

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

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

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 COLOUR NAME ID COLOUR NAME COLOUR NAME COLOUR NAME COLOUR COLOUR COLOUR COLOUR

Struktura tabulky

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

Datové bloky

QTY QTY QTY QTY QTY QTY QTY QTY

51

51

Data uložená po sloupcích

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

52

Data uložená po sloupcích

SELECT SUM(qty) FROM sale

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

53

53

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

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

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

54

54

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

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

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

55

55

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

 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

56

56

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

Tradiční RDBMS

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

57

Co si zapamatovat  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) 58

58

Diskuse • • • •

Otázky Poznámky Komentáře Připomínky

59