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

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

Databázové patterny Profinit. All rights reserved.

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

Obsah. Zpracoval:

Správa dat v podniku. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu

Information and Data Management. RNDr. Ondřej Zýka

6 Objektově-orientovaný vývoj programového vybavení

Operátory ROLLUP a CUBE

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

Datová kvalita. RNDr. Ondřej Zýka

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

Hierarchický databázový model

M4 PDF rozšíření. Modul pro PrestaShop.

RELAČNÍ DATABÁZOVÉ SYSTÉMY

Předmluva 11. Poděkování 11 O autorech 12 Úvodem 12 Komu je tato kniha určena 13 Jak byste měli tuto knihu číst 13 Web 14

Konceptuální modelování. Pavel Tyl

POKROČILÉ POUŽITÍ DATABÁZÍ

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

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

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

Datová kvalita. RNDr. Ondřej Zýka

Metadata. MI-DSP 2013/14 RNDr. Ondřej Zýka,

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz

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

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í

Architektura informačních systémů. - dílčí architektury - strategické řízení taktické řízení. operativní řízení a provozu. Globální architektura

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

MVC (Model-View-Controller)

Logický datový model VF XML DTM DMVS

Pattern Datový sklad. RNDr. Ondřej Zýka

Databáze Bc. Veronika Tomsová

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

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. Přednáška 1

Metadata. RNDr. Ondřej Zýka

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into

Přínos SEKM pro NIKM

PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI

Správa VF XML DTM DMVS Datový model a ontologický popis

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

Analýza a Návrh. Analýza

PŘÍLOHA C Požadavky na Dokumentaci

PRŮZKUMNÍK ISDP NÁVOD K OBSLUZE INFORMAČNÍHO SYSTÉMU O DATOVÝCH PRVCÍCH (ISDP)

EKONOMICKÝ A LOGISTICKÝ SOFTWARE. Luhačovice

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

Vývoj informačních systémů. Přehled témat a úkolů

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování.

JEDNODUCHÁ A PRAKTICKÁ METODA ODHADU PRACNOSTI PROJEKTU (S UTILITOU KE STAŽENÍ ZDARMA)

Metody tvorby ontologií a sémantický web. Martin Malčík, Rostislav Miarka

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

RNDr. Jakub Lokoč, Ph.D. RNDr. Michal Kopecký, Ph.D. Katedra softwarového inženýrství Matematicko-Fyzikální fakulta Univerzita Karlova v Praze

7.6 Další diagramy UML

1. Integrační koncept

DBS Konceptuální modelování

Objektově orientované technologie Diagram komponent Implementační náhled (Diagram rozmístění) Pavel Děrgel, Daniela Szturcová

Návrh databázového modelu

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

Vývoj informačních systémů. Přehled témat a úkolů

7.6 Další diagramy UML

Zhodnocení architektury podniku. Jiří Mach

TÉMATICKÝ OKRUH Softwarové inženýrství

Databázové a informační systémy Informační systém prodejny nábytku. Jakub Kamrla, KAM087

RNDr. Jakub Lokoč, Ph.D. RNDr. Michal Kopecký, Ph.D. Katedra softwarového inženýrství Matematicko-Fyzikální fakulta Univerzita Karlova v Praze

Programování II. Návrh programu II

Analýza a modelování dat 2. přednáška. Helena Palovská

Průzkumník IS DP. Návod k obsluze informačního systému o datových prvcích (IS DP) vypracovala společnost ASD Software, s. r. o.

2. Konceptuální model dat, E-R konceptuální model

EXTRAKT z mezinárodní normy

XERXES Portál informačních zdrojů. Ing. Lukáš Budínský PhDr. Ondřej Fabián

Kapitola 1: Úvod. Systém pro správu databáze (Database Management Systém DBMS) Účel databázových systémů

MBI - technologická realizace modelu

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

Rozhraní pro práci s XML dokumenty. Roman Malo

Administrační systém ústředen MD-110

PHOTO-ON Profesionální on-line správa fotografií

Analýza dat a modelování. Přednáška 2

Ontologie. Otakar Trunda

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

Klinický informační systém Porodní kniha - případová studie -

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

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

Národní technické specifikace. služeb nad prostorovými daty a metadaty

Transformace dílčích datových zdrojů na jednotnou datovou platformu kontaminovaných míst, analýza potřeb uživatelů a vývoj aplikací

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

Dolování v objektových datech. Ivana Rudolfová

Problém identity instancí asociačních tříd

10. blok Logický návrh databáze

Lotus Quickr - ECM Integrace s LD/LN aplikacemi. Ing. Josef Homolka VUMS Legend

Windows Server 2003 Active Directory

Aplikační software. Řízení lidských zdrojů PRAHA Zpracoval: Ing. Pavel Branšovský pro potřebu VOŠ a SŠSE

Téma Školitel Počet dní Moderní principy řízení výrobního podniku

2. Systémová analýza SA návrhová část projektu = příručka projektu - systémový přístup k analýze problémů, nejdůležitější etapa projektu - podrobné st

MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH. Jindřich Kaluža Ludmila Kalužová

Koncept řešení EOS EVIDENCE ORGANIZAČNÍ STRUKTURY

Konsolidovaný reporting CZ/SK v Cognos případová studie sanofi-aventis

IBM Analytics Professional Services

Entity: Profese, Klient

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

Ruční návrh Připravíme si odpovědi na základní otázky Co chceme řešit (projektovat) a proč Komu to bude sloužit Jaký užitek z toho bude mít uživatel I

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

Transkript:

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

Co to je databázový pettern 2

Databázové patterny Odzkoušené a doporučené způsoby, jak řešit často se vyskytující požadavky Jednoduché N-ární relace Dědičnost Katalog Přiřazení rolí Klasifikace 3 3

Úrovně patternů Stejný typ požadavků může být řešen v databázi mnoha způsoby Jednoduše výhodné pro uživatele I při drobné změně požadavku je nutný zásah do databáze, Lehce srozumitelné uživatelům, analytikům, vývojářům. Složitě výhodné pro vývojáře Hodně změn se dá vyřešit pouze změnou dat. Komplikované datové struktury, uživatelsky nesrozumitelné. Vždy je nutné mít jednoduché uživatelské rozhraní. Koncový uživatel nesmí být zatěžován implementační složitostí. 4 4

Úrovně patternů 5 5

Dědičnost 6

Logický model PARTY 7 7

Fyzický model Child only Otázka unikátnosti ID Jak provést select přes všechny PARTY? (view) 8 8

Fyzický model Parent-Child Vhodné pro více společných atributů 9 9

Fyzický model Parent only (L-schéma) Jak zajistit not null atributy jednotlivých Child Jak zajistit vzájemnou výlučnost dědičnosti 10 10

Fyzický model Parent only se specifikátorem Specifikátor (TYPE) možnost přidání číselníků Výlučná dědičnost i při vícenásobné dědičnosti 11 11

Metamodely 12

Evidence systémů Patern I Srozumitelné Model kontroluje vazby, typy atributů, not null Model neumožňuje více typů vazeb mezi systémy (například vazby přenosů dat) Přidání atributu nebo entity vyžaduje zásah do modelu 13 13

Evidence systémů patern II 14 14

Evidence systémů patern II Definice typů vazeb, vazby mají atributy Definice povolených vazeb pouze v datech, model neověřuje vazby mezi typy elementů, umožňuje ověření Definice atributů pouze v datech, model neověřuje typy, umožňuje ověření 15 15

Evidence systémů patern III 16 16

Evidence systémů patern III Společná entita pro Elementy i Relace Snadné vyhledávání přes všechna data Definice povolených vazeb pouze v datech, model neověřuje vazby mezi typy elementů, umožňuje ověření Definice atributů pouze v datech, model neověřuje typy, umožňuje ověření Model nerozlišuje Elementy a Relace, nutnost kontrol podle OBJECT_KIND 17 17

Evidence systémů patern IV 18 18

Evidence systémů patern V 19 19

Pattern Přiřazení rolí 20

Pattern Přiřazení rolí Definice Model pro správu zákazníků a dalších subjektů kooperující s podnikem Příklady Podnik Zákazník Dodavatel Partner Zaměstnanec Škola Student Zaměstnanec Spolupracovník Přednášející 21 21

Pattern Přiřazení rolí I CUSTOMER ID ORGANIZATION/FIRST/LAST NAME CREDIT LIMIT 100 Moje data s.r.o. 1000000 CZK 101 Tvoje Data s.r.o. null SUPPLIER ID ORGANIZATION NAME TAXATION IDENTIFIER 369 Moje data s.r.o. 123456789 456 Vaše Data s.r.o. 987654321 PARTNER ID ORGANIZATION/FIRST/LAST NAME PARTNER TYPE 1001 Moje data s.r.o. 10 (Global partner) 1002 Tvoje Data s.r.o. 20 (Software testing) 22 22

Pattern Přiřazení rolí I Nejjednodušší řešení - každá role jiná entitu Výhody Přesně definované role Srozumitelné řešení Pravidla hlídaná modelem Některé role mohou zastávat pouze organizace (SUPPLIER), některé pouze lidé (EMPLOYEE), některé jak lidé, tak organizace Nevýhody Atributy jsou společné (Jméno) a specifické (EMPLOYEE NUMBER) Stejná informace je uložena na více místech (Jak řešit změnu adresy firmy Vaše Data); Jedna organizace nebo člověk může mít více rolí Přidání nové role vynucuje změnu modelu Těžko se skládá celkový obrázek o vazbách mezi subjekty Není jasné, jak jednoznačně identifikovat subjekt 23 23

Pattern Přiřazení rolí II 24 24

Pattern Přiřazení rolí II Složitější řešení jednotná identifikace, společné řešení pro základní údaje Výhody Odstranění redundance informací o osobách a organizacích. Pravidla hlídaná modelem Role může být vázána na PARTY, nebo jenom na podtyp ORGANIZATION Umožňuje jednoduše vázat další entity (faktura, objednávka) přímo na PARTY, není potřeba rozlišovat, zda se jedná o osobu nebo organizaci Umožňuje jednoduše přidávat další role existujícím PARTY Umožňuje, aby jedna PARTY vystupovala ve více rolích Nevýhody Nutnost řešit dědičnost na úrovni PARTY Jednotlivé role jsou samostatné entity: nová role = nová entita. Není vhodné pokud nové role vznikají často. Uživatelé mají problém rozlišit PARTY od ROLE Pattern naznačuje, že PARTY vystupuje v roli pouze jednou Neumožňuje řídit informace ohledně typů rolí 25 25

Pattern Přiřazení rolí III 26 26

Pattern Přiřazení rolí III ROLE TYPE ID NAME PARENT ROLE TYPE ID PARENT NAME 100 Party role Null Null 101 Customer 100 Party role 102 Partner 100 Party role 103 Organization role 100 Party role 104 Supplier 103 Organization role 105 Person role 100 Party Role 106 Employee 105 Person role 107 Manager 106 Employee 108 Debtor 100 Party role 27 27

Pattern Přiřazení rolí III Party Role Partner Customer Organization Role Person Role Supplier Employee 28 28

Pattern Přiřazení rolí III Ještě složitější přístup ROLE TYPE je číselník rolí PARTY ROLE je Vazební entita mezi PARTY a ROLE TYPE Rodičovská entita pro všechny role Potomci obsahují specifické atributy Výhody PARTY může přijímat mnoho rolí PARTY ROLE pro jednotlivé PARTY mají časovou specifikaci Existuje stromová hierarchie mezi ROLE TYPE Pokud nové role nevyžadují nové atributy, nevyžaduje přidávání rolí zásah do datového modelu (možno řešit i oddělením atributů. Nevýhody Je to složité!!!!! Při uvedeném číselníku typů rolí je těžko pochopitelná vazba mezi Person role a Organization role a strukturou PARTY Model hlídá méně pravidel, musí být hlídány aplikačně Role může být vázána na PARTY, nebo jenom na podtyp ORGANIZATION Pokud nová role vyžaduje nové atributy, je stále nutné zasáhnout do datového modelu. 29 29

30 30

Konsolidovaný model a datové toky 31 31

Pattern Klasifikace 32

Pattern Klasifikace Definice Podpora členění instancí entity podle typů, do kategorií a taxonomií. Typy skupiny se společnými charakteristikami Kategorie kategorizace podporuje více druhů členění (Typy typů) Taxonomie původně věda zabývající se klasifikací organismů; členění dle definované struktury (například Klasifikace ekonomických činností (CZ-NACE)). Každá instance právě v jedné kategorii. 33 33

Klasifikace Product Type Hardware Software Accessory Processors Business software Cases Storage devices Gaming Software Mouse pads Product Family Disk drives Carrying Cases Computer Memory Desktop Computers Laptop Computers Product Line Home Use Commercial Use Home Business Government 34 34

Pattern Klasifikace I 35 35

Pattern Klasifikace I ID NAME TYPE FAMILY LINE 1 LINE 2 CAPACITY COLOUR 100 Save Disk 2000 HW Disk Drivers Home use Commercial Use 101 Carry All Case Accesory Carrying Case Commercial use 102 HS Software package 103 Memmory card M10 Software Hardware Computer memory Home Business Home use Home Business 20GB 1GB Black Green 36 36

Pattern Klasifikace I Každá klasifikace má své atributy Taxanomie povinný atribut Násobné atributy Výhody Velice jednoduchý model, snadno pochopitelný pro všechny uživatele Vhodný jako základ (prototyp), odrazový můstek pro pochopení a podrobnější analýzu Implementace může používat omezení na hodnoty ve sloupcích (nebo aplikančí omezení) Nevýhody Složitá správa redundantních dat (HW hardware Hardware) Velice nepružný model Přidání kategorie přidání atributu Mnoho typů mnoho atributů Více typů klasifikací více sloupců (Product line 1, Product line 2) Nedají se udržovat data o klasifikacích popis, doba platnosti a podobně Model nepodporuje složitější vazby o klasifikacích pouze povinné a nepovinné klasifikace 37 37

Pattern Klasifikace II 38 38

Pattern Klasifikace II Číselníkové tabulky Taxanomie povinný atribut Vazební tabulky pro více hodnot Výhody Snadno porozumitelný model Změna klasifikace změna číselníku Pro porozumění modelu je důležité znát obsah tabulek (číselníků). Umožňuje nezávislé řízení klasifikací MDM Rozdílné klasifikace mohou mít své atributy a hierarchie Nevýhody Málo pružný model, pokud je potřeba přidávat nové klasifikace. Jednotlivé klasifikace jsou udržovány v oddělených entitách. Mnoho typů klasifikací mnoho atributů, mnoho číselníků. 39 39

Pattern Klasifikace III 40 40

Pattern Klasifikace III Sjednocení všech kategorií do jedné entity Zavedení klasifikace kategorií Hierarchická struktura na kategoriích i typech kategorií (například pro reporting) Výhody Jednoduché řízení klasifikací přidávání nové kategorizace, změna hierarchie kategorií je pouze změna dat Vhodné pokud je potřeba mnoho klasifikací Jednoduchý po databázové stránce jenom čtyři tabulky Umožňuje jednoduše složitější analýzy podle různých klasifikací 41 41

Pattern: Klasifikace III Nevýhody Těžký na porozumění, zejména při úpravách dat číselníků Nevynucuje žádná business pravidla nutno hlídat aplikačně Není vazba mezi hierarchií Kategorií a Typů kategorií. Model neumožňuje mít rozdílné atributy pro specifické typy 42 42

Shrnutí Řešení musí odpovídat Složitosti business domény, Složitosti business pravidel, Schopnosti analytiků a vývojářů porozumět modelu, Schopnosti uživatelů udržovat model. Vždy je vhodné při návrhu modelu vytvářet i data entit. 43 43

Další směry Řešení časové platnosti záznamu. Řešení více hierarchií. Řešení definice různých atributů pro různé typy. 44 44

Co si zapamatovat Co to jsou databázové patterny Jaké databázové patterny se používají Jaké řešení pro pattern Rolí se používají, jaké mají slabé a silné stránky Jaké řešení pro pattern klasifikace se používají, jaké mají slabé a silné stránky 45 45

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