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

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

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

Konceptuální datové modely používané při analýze

Databázové patterny. MI-DSP 2013/14 RNDr. Ondřej Zýka,

Databáze I. Přednáška 4

Obsah přednášky. Databázové systémy. Normalizace relací. Normalizace relací. Normalizace relací. Normalizace relací

Databázové patterny. RNDr. Ondřej Zýka

Databázové systémy Cvičení 5.2

Kapitola 7: Návrh relačních databází. Nástrahy relačního návrhu. Příklad. Rozklad (dekompozice)

Transformace konceptuálního modelu na relační

RELAČNÍ DATABÁZOVÉ SYSTÉMY

01. Kdy se začala formovat koncept relačních databází (Vznik relačního modelu, první definice SQL)? a) 1950 b) 1960 c) 1970 d) 1980

Databázové systémy. - SQL * definice dat * aktualizace * pohledy. Tomáš Skopal

Relace x vztah (relationship)

Úvod do databázových systémů

Návrh a tvorba WWW stránek 1/14. PHP a databáze

Primární klíč (Primary Key - PK) Je právě jedna množina atributů patřící jednomu z kandidátů primárního klíče.

Relační databázový model. Vladimíra Zádová, KIN, EF, TUL- DBS

Jaký je rozdíl v definicicíh VARCHAR2(20 BYTE) a VARCHAR2(20 CHAR):

Obsah přednášky. Databázové systémy RDBMS. Fáze návrhu RDBMS. Coddových 12 pravidel. Coddových 12 pravidel

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů.

Informační systémy 2008/2009. Radim Farana. Obsah. Jazyk SQL

7. Integrita a bezpečnost dat v DBS

7. Integrita a bezpečnost dat v DBS

Relační datový model. Integritní omezení. Normální formy Návrh IS. funkční závislosti multizávislosti inkluzní závislosti

Konceptuální modelování a SQL

Databáze. Logický model DB. David Hoksza

Základy informatiky. 06 Databázové systémy. Kačmařík/Szturcová/Děrgel/Rapant

Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky.

Databáze 2011/2012 SQL DDL (CREATE/ALTER/DROP TABLE), DML (INSERT/UPDATE/DELETE) RNDr.David Hoksza, Ph.D.

OBJECT DEFINITION LANGUAGE. Jonáš Klimeš NDBI001 Dotazovací Jazyky I 2013

Konceptuální modelování. Pavel Tyl

Ing. Bc. Robert Haken [MVP ASP.NET/IIS, MCT] software architect, HAVIT, Návrh schématu DB

Kapitola 6: Omezení integrity. Omezení domény

2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE

5. Formalizace návrhu databáze

A5M33IZS Informační a znalostní systémy. Relační databázová technologie

Úvod do databází. Modelování v řízení. Ing. Petr Kalčev

Informační systémy 2008/2009. Radim Farana. Obsah. Obsah předmětu. Požadavky kreditového systému. Relační datový model, Architektury databází

8.2 Používání a tvorba databází

SQL - trigger, Databázové modelování

Základy informatiky. 08 Databázové systémy. Daniela Szturcová

Databázové systémy trocha teorie

Základy databází. O autorech 17 PRVNÍ ČÁST. KAPITOLA 1 Začínáme 19

Semestrální práce z DAS2 a WWW

Tvorba informačních systémů

5. Formalizace návrhu databáze

Databázové systémy. Vztahy a relace. 3.přednáška

Marketingová komunikace. 2. a 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph)

Databázové systémy. Ing. Radek Holý

Michal Krátký. Tvorba informačních systémů, 2008/2009. Katedra informatiky VŠB Technická univerzita Ostrava. Tvorba informačních systémů

Jiří Mašek BIVŠ V Pra r ha

Úvod do databázových systémů. Ing. Jan Šudřich

Tvorba informačních systémů

Databázové systémy II. KIV/DB2 LS 2007/2008. Zadání semestrální práce

DBS Transformace konceptuálního schématu na

Marketingová komunikace. 2. soustředění. Mgr. Pavel Vávra Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph)

5. POČÍTAČOVÉ CVIČENÍ

Databázové systémy. Přednáška 1

UNIVERZITA PALACKÉHO V OLOMOUCI

Použití databází na Webu

Databázové systémy. Datová integrita + základy relační algebry. 4.přednáška

4IT218 Databáze. 4IT218 Databáze

Databáze I. 4. přednáška. Helena Palovská

Materiál byl vytvořen v rámci projektu Nové výzvy, nové příležitosti, nová škola

Databázové systémy. Doc.Ing.Miloš Koch,CSc.

Úvod do databázových systémů

Co bude výsledkem mého SELECTu? RNDr. David Gešvindr MVP: Data Platform MCSE: Data Platform MCSD: Windows Store MCT

Obchodní akademie a Jazyková škola s právem státní jazykové zkoušky Jihlava

2 Konceptuální modelování a návrh databáze

PL/SQL. Jazyk SQL je jazykem deklarativním, který neobsahuje procedurální příkazy jako jsou cykly, podmínky, procedury, funkce, atd.

Databázové modelování. Analýza Návrh konceptuálního schématu

2 Konceptuální modelování a návrh databáze

Relační databázová technologie

Databáze 2013/2014. Konceptuální model DB. RNDr. David Hoksza, Ph.D.

Kritéria hodnocení praktické maturitní zkoušky z databázových systémů

Kritéria hodnocení praktické maturitní zkoušky z databázových systémů

Co se stane po jeho vykonání? Vyberte libovolný počet možných odpovědí. Správná nemusí být žádná, ale také mohou být správné všechny.

Relační DB struktury sloužící k optimalizaci dotazů - indexy, clustery, indexem organizované tabulky

Tabulka fotbalové ligy

Analýza a modelování dat. Helena Palovská

12. blok Fyzický návrh databáze

Kurz Databáze. Obsah. Dotazy. Zpracování dat. Doc. Ing. Radim Farana, CSc.

Databázové systémy. Cvičení 3

Návrh databázového modelu

Primární klíč, cizí klíč, referenční integrita, pravidla normalizace, relace

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1

Informační systémy 2008/2009. Radim Farana. Obsah. Dotazy přes více tabulek

Databáze II. 1. přednáška. Helena Palovská

Obsah. Kapitola 1. Kapitola 2. Kapitola 3. Kapitola 4. Úvod 11. Stručný úvod do relačních databází 13. Platforma 10g 23

Databáze SQL SELECT. David Hoksza

Roční periodická zpráva projektu

Střední průmyslová škola Zlín

Otázka č. 1 (bodů za otázku: 4)

1. Relační databázový model

Databáze I. Přednáška 3

DATABÁZE A INFORMAČNÍ SYSTÉMY

DJ2 rekurze v SQL. slajdy k přednášce NDBI001. Jaroslav Pokorný

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115

4IT218 Databáze. 4IT218 Databáze

Transkript:

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

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

Tabulky Sloupce Relace Indexy Logika Triggery Procedury Zabezpečení Práva k objektům Chybová hlášení Obsah databáze 3

Obsah databáze Databáze slouží jako model reality Popisuje realitu na úrovni detailu, který vyžadují uživatelé Informace o entitách Informace o vazbách mezi entitami Nabízí operace, které vyžadují uživatelé Operacích nad daty Zabezpečení dat 4

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 (z nuly) Nutnost začlenění stávajícího stavu nebo okolních stavu okolních systémů (prostředí) 5

Shromáždění business požadavků Cíle Pochopit business doménu Prostředky Interview Studium a dokumentace systémů Spolupráce s experty v business oblasti Informace o organizační struktůře a další dokumenty Výstup Data-flow diagram Seznam požadavků Dokument popisující doménu 6

Datové toky 7

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

Data-flow diagram Datové toky na různých úrovních granularity Podnikové toky dat Toky dat na technické úrovni Popisy ETL procesů Popisy integračních procesů 9

Data-flow diagram 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 Často vyžadováno předpisy Například Payment Card Industry (PCI) Data Security Standard vyžaduje přesný popis kam všude se přenášejí čísla kreditních karet a další atributy kdo k nim má přístup. 10

DFD příklad Decomposition Level 2 1.1.1 databáze/ soubor CUSTOMER CUSTOMER_ORDER 1.1.2 Place Orders + [BOOK_ORDER] Book Supplier Receive Orders + 1.1.3 Book Shipment Invoice [SHIPMENT] Book Supplier datová entita/ business object funkce Process Invoices + [PAYMENT] Book Supplier vstup/výstup 11

Cíle Konceptuální model 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) a identifikovat vazby mezi entitami. Výstupy ER diagram 12

Konceptuální model - příklad 13

Definice Entity objekty o kterých hovoří business požadavky, mají instance Atributy charakteristiky, které musí nebo mohou být známy o entitách Data value hodnoty, které nabývají atributy Klíče (identifikátory) skupiny atributů, které identifikují jednotlivé instance entit Relationship vazby mezi entitami 14

Potenciální klíče Identifikují jednotlivé instance entit Neobsahují hodnoty null Jsou stabilní Vždy se dá uvažovat umělý klíč 15

Relace Vazba mezi dvěma nebo více entitami U relací je důležité Kardinalita relace Jméno relace Role relace (popis) Notace realcí 16

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. 17

Násobnost a volitelnost CAR Nejvíce jedno auto CAR Právě jedno auto CAR Žádné nebo libovolný počet aut, CAR Nejméně jedno auto 18

Entity and Attribute Notation E/R UML Barker/Ellis NATURAL PERSON «id» Person ID Current first name Current middle name [0..1] Current last name Birth date [0..1] Gender [0..1] Identification number [0..1] /Age Identifying attribute symbol Mandatory attribute symbol Optional attribute symbol Computed (derived) attribute NATURAL PERSON # PERSON ID CURRENT FIRST NAME o CURRENT MIDDLE NAME CURRENT LAST NAME o BIRTH DATE o GENDER o IDENTIFICATION NUMBER (AGE) 19

Cardinality (=Multiplicity) and Association Notation Mapping Allowed multiplicities N/A substituted by Not Used Used Not Used because not needed 20

Pravidla pro čtení Assertion 2: "Each LINE ITEM must be part of exactly one ORDER " Reading direction LINE ITEM Line number Quantity Price Delivery date part of 0..* 1 composed of ORDER Order number Order date Assertion 2: "Each ORDER may be composed of one or more LINE ITEMS " 21

Pravidla pro čtení 22

Závislost Jedna entita záleží na druhé a je jí identifikována Partner musí mít vztah právě k jednomu zaměstnanci. ZAMĚSTNANEC LAST NAME FIRST NAME PHONE NUMBER ADDRESS PARTNER LAST NAME FIRST NAME PHONE NUMBER ADDRESS 23

Dědičnost ZAMĚSTNANEC EMPLOYEE EMP_LAST_NAME EMP_FIRST_NAME EMP_PHONE_NUMBER EMP_HIRE_DATE EMP_STATUS SALES OBCHODNIK PERSON EMP_YTD_SALES 24

N-arní relace EMPLOYEE COURSE EMPLOYEE- COURSE-ROLE ROLE 25

Relace s atributy EMPLOYEE EMPLOYEE ID EMPLOYEE LAST NAME EMPLOYEE FIRST NAME EMPLOYEE PHONE manage START DATE WORK GROUP WORK GROUP ID WORK GROUP NAME WORK GROUP PROJECT 26

Entity-Relationship Diagram Zápis entit Jméno Popis definici, příklady a protipříklady Klíče Zápis atributů Jméno Popis definice, příslušnost k entitě, domain, omezení, rozsah Kardinalita Zda je to odvozený atribut Zápis relací Kardinalita, povinnost Role na obou stranách Popis definice Ke kterým entitám se váže Grafická representace 27

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 realcí 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é. 28

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 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ůsobe reprezentace subtypů Normalizace modelu Výstup Logický datový model 29

Převod entit na tabulky Jméno entity -> Jméno tabulky Atribut -> Sloupec Instance -> Řádek V tabulce nemají sloupce ani řádky žádné speciální uspořádání. Tabulka nemůže mít dva stejné řádky. Tabulka nemůže mít dva sloupce stejného jména. V průsečíku řádku a sloupce musí být právě jedna hodnota (může to být null). 30

Převod entit na tabulky BOOK BOOK ID BOOK TITLE CATEGORY QUANTITY SOLD AUTH_ID ID TITLE CATEGORY QUANTITY ------- -- -------------- --------- -------- 7749 60 New Poems Poetry 4500 1100 61 Killing Time Fiction 5000 7749 62 Cats in Love Essays 1000 8568 70 The Snail Fiction 1000 8568 67 All in the Day Biography 500 0123 63 Look Here Drama 500 31

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. Pro rozhodnutí o primárních a cizích klíčích musí být tabulka v prvním normálním tvaru. 32

Strukturované atributy Atributy obsahující více než jednu informaci PUBLISHER PUB_ID NAME PHONE MAILING_ADDRESS ------ ----- -------- ----------------------------------- 2233 Aris 232-5555 50 Temple Place Orlando FL 09327 1100 Totum 456-0000 143 Seaborg Seattle WA 96505 4680 Felix 555-1212 1 Info Plaza Mountain View CA 94501 33

Atributy nabývající více hodnot CUSTOMER NAME PHONE#1 PHONE#2 PHONE#3 ADDRESS ----------- -------- -------- -------- ---------------- Max Brown 555-1415 null null 423 5th Street Ted Green 444-0607 111-9999 null 231 Ash Avenue Joy Gray 333-2121 333-2001 546-1313 P.O. Box 9876 Tia Puce 222-0005 null null 700 8th St, #2 Molly Brown 555-1414 null null 444 Forest Drive 34

Atributy nabývající více hodnot CUSTOMER NAME ADDRESS PHONE NAME EXTENSION CUSTOMER NAME ADDRESS ---------- ----------------- Max Brown 423 5th Street Ted Green 231 Ash Avenue Joy Gray P.O. Box 9876 Tia Puce 700 8th St, #2 Molly Brown 444 Forest Drive PHONE NAME EXTENSION ---------- --------- Max Brown 555-1415 Ted Green 444-0607 Ted Green 111-9999 Joy Gray 333-2121 Joy Gray 333-2001 Joy Gray 546-1313 Tia Puce 222-0005 Molly Brown 555-1414 35

Výběr primárního klíče Primární klíč je skupina sloupců které identifikují jednotlivé řádky tabulky. Tabulka má pouze jeden primární klíč, ten může obsahovat více sloupců. 36

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, hodnoty nemají význam pro uživatele 37

Převod binární relace 1:N na cizí klíč AUTHOR AUTHOR ID LAST NAME FIRST NAME PHONE NUMBER ADDRESS AUTHOR AUTHOR ID LAST NAME FIRST NAME PHONE NUMBER ADDRESS PICTURE PICTURE ID FORMAT BYTESIZE PIXEL WIDTH PIXEL HEIGHT PICTURE AUTHOR ID PICTURE ID FORMAT BYTESIZE PIXEL WIDTH PIXEL HEIGHT 38

Převod závislosti na cizí klíč AUTHOR AUTHOR ID LAST NAME FIRST NAME PHONE NUMBER ADDRESS AUTHOR AUTHOR ID LAST NAME FIRST NAME PHONE NUMBER ADDRESS PICTURE PICTURE ID FORMAT BYTESIZE PIXEL WIDTH PIXEL HEIGHT PICTURE AUTHOR ID PICTURE ID FORMAT BYTESIZE PIXEL WIDTH PIXEL HEIGHT 39

Relace typu n:n AUTHOR AUTHOR ID LAST NAME FIRST NAME PHONE NUMBER ADDRESS BOOK BOOK ID TITLE CATEGORY QUANTITY SOLD AUTHOR AUTHOR ID LAST NAME FIRST NAME PHONE NUMBER ADDRESS AUTHOR-BOOK Associative entity BOOK BOOK ID TITLE CATEGORY QUANTITY SOLD 40

Relace typu n:n AUTHOR AUTHOR ID LAST NAME FIRST NAME PHONE NUMBER ADDRESS AUTHOR-BOOK AUTHOR ID BOOK ID BOOK BOOK ID TITLE CATEGORY QUANTITY SOLD 41

Vyřešit n-arní relace EMPLOYEE COURSE EMPLOYEE- COURSE-ROLE EMPLOYEE ID COURSE ID ROLEID ROLE 42

Rekursivní relace EMPLOYEE EMPLOYEE ID EMPLOYEE LAST NAME EMPLOYEE FIRST NAME EMPLOYEE HIRE DATE EMPLOYEE STATUS supervises 43

Rekursivní relace EMPLOYEE EMPLOYEE ID EMPLOYEE LAST NAME EMPLOYEE FIRST NAME EMPLOYEE HIRE DATE EMPLOYEE STATUS SUPERVISOR ID Renamed foreign key 44

Rozhodnutí o reprezentaci dědičnosti Několik možností V jedné tabulce: L-schéma Ve více tabulkách 45

Normalizace Změna logického modelu Změna je bezeztrátová Za normalizací je teorie relací Výhody Snížení redundancí Zjednodušení správy dat Snížení nutnosti používat null hodnoty NULL hodnoty způsobují problémy při sumarizaci dat 46

Další výhody normalizace Možnost přesnějšího vyjádření business pravidel datovým modelem. Normalizace většinou odhalí další entity a pravidla. Umožňuje konstrukci velkých projektů spolehlivým a opakovatelným způsobem. Plně normalizovaný model se dá použít jako benchmark zda denormalizace přináší nějakou výhodu. Datové stroje jsou připraveny pracovat s normalizovanými modely. 47

Hierarchie Normálních forem 1. Normální forma 2. Normální forma 3. Normální forma Boyce/Codd normální forma 4. Normální forma 5. Normální forma 48

Funkční závislost Mějme dva sloupce A, B Jestliže platí pro kterékoliv dva řádky že pokud se shoduje hodnota ve sloupci A, potom už se shoduje hodnota i ve sloupci B, říkáme A funkčně určuje B B je funkčně závislé na A Tvrzení musí platit pro všechny možné (i budoucí) hodnoty Definice platí jak pro sloupce, tak pro množiny sloupců. 49

Funkční závislost INVENTORY CATALOG PRODUCT CODE COLOR ------- ------------ ------- 1234 2 blue 2345 3 yellow 6543 5 orange 8765 3 yellow 1357 13 yellow 0098 4 orange 4444 7 red CATALOG PRODUCT CODE Determinant Dependent PRODUCT CODE COLOR 50

První a druhá normální forma Tabulka je v první normální formě, když všechny sloupce jsou atomické obsahují jenom jeden typ hodnot. Tabulka je v druhé normální formě pokud je v první normální formě a každý sloupec, který není součástí primárního klíče je funkčně závislý na celém primárním klíči. 51

2NF - příklad MAYOR STATE_CODE CITY MAYOR_NAME STATE_NAME STATE_CODE STATE_NAME STATE_CODE + CITY MAYOR_NAME STATE_CODE STATE_NAME CITY MAYOR_NAME 52

2NF - příklad A C B D A B D A C MAYOR STATE_CODE CITY MAYOR_NAME STATE STATE_CODE STATE NAME 53

Třetí normální forma Tabulka je ve třetí normální formě pokud je v druhé normální formě a každý sloupec, který není součástí primárního klíče je přímo funkčně závislý na klíči a ničem jiném. 54

3NF - příklad 1. A B C 2. A B B C 3. CATALOG PRODUCT CODE PRODUCT CODE COLOR ------- ------------ ------------ ------- 1234 2 2 blue 2345 3 3 yellow 6543 5 5 orange 8765 3 13 yellow 1357 13 4 orange 0098 4 7 red 4444 7 CATALOG-PRODUCT CODE PRODUCT CODE-COLOR 55

Boyce / Codd normální forma Tabulka je v BCNF právě když pro každou netriviální funkční závislost X Y, je X superklíč, což znamená, že X je kandidátní klíč nebo jeho nadmnožina. Tabulky, které je potřeba normalizovat do BCNF splňují kritéria: Mají několik kandidátních klíčů. Kandidátní klíče jsou složené. Složené klíče mají alespoň jeden sloupec společný. Existují případy, kdy se BCDN nedá dosáhnout. 56

Vyšší normální formy Definice založená na vícehodnotové závislosti. Málo používané. Je-li tabulka v 3NF žádný z kandidátních klíčů není složený, je již v 5NF a tedy i v 4NF. 57

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 58

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 59

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 60

Procesní matice Způsob jak zaznamenat požadavky jednotlivých obchodních procesů na data Create/Update/Modify/Read Frekvece použití Požadovaná doba odezvy (service level) Algoritmy Sloupce, joiny, where podminky 61

Procesní matice - příklad 62

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 63

Rozhodnutí o primárním klíči Terminologie Klíč Index Primární klíč Primární index Požadavky na primární klíč podle procesní matice Joiny Možnost vytvořit foreign key pro jiné indexy než primární Jiné omezení datového serveru 64

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 65

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ší 66

Příklad obchodnik_id name diskount... obchodnik int varbinary(255) numeric(5,3) <pk> zakaznik_id obchodnik_id jmeno adresa... zakaznik int int varchar(255) varchar(255) <pk> <fk> 67

Možné typy referenční integrity - příklad 68

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

Typy indexů B-tree Indexy Clustered/nonclustered Bitmapové indexy 70

Standardní index Přístupové metody Procházení indexu Scan nejnižší úrovně Dotaz pokrytý indexem Clustered index Procházení indexu Scan dat od nalezeného sloupce 71

B-tree index 72

Clustered index 73

Select Pokrývající query Group by Order by Join Použití indexů Nepoužívat indexy pro malé tabulky Selektivita indexů 74

Partitioning Horizontální Vertikální Denormalizace Uložení vypočtených hodnot Spojení tabulek 75

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) Synchronizace Table partitioning Triggery Aplikační logika 76

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 77

Uložení vypočtených dat Přidání sloupce Hodnoty jsou závislé na jiných hodnotách řádku Hodnoty odpovídají primárnímu klíči (a libovolných datech) Přidání tabulky Synchronizace Trigerry Uložené procedury Aplikační logika Nutno zavést procedury pro údržbu 78

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 79

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 80

Doporučená literatura Typy modelů http://www.1keydata.com/datawarehousing/c oncepts.html Steven Feuerstein: Ideas for Oracle PL/SQL Naming Conventions and Coding Standards (http://www.toadworld.com/sf/standards) Microsoft SQL Server 2000 Unleashed (2nd Edition) by Ray Rankins, Paul Jensen, and Paul T. Bertucci (Paperback - 18 Dec 2002) 81