1
Přehled metodiky vývoje GIS aplikací
(vytvořeno pro seminář na FIMU: Vybrané kapitoly z GIS, podzimní semestr)
Lekce 4: Datové modely
2
1. Datové modelování - proč vytvářet datové modely?
2. Tři úrovně datových modelů
3. Konceptuální datový model (analytický model tříd), entity, vztahy mezi entitami,
atributy, datové typy, primární klíče, unikátní klíče
4. Logický datový model (LDM), tabulky, vazby mezi nimi, sloupce, postup vytváření
LDM
5. Fyzický datový model
6. Datové typy
7. Formální náležitosti datového modelu
8. Příklady datových modelů
9. Zásady tvorby datového modelu
10. Normální formy datového modelu
11. Na závěr: DTO a jejich využití
12. Podklady pro další samostudium
Obsah
3
• Datové modelování (Anatoliy Kybkalo, Datové modelování, Unicorn College,
2013):
• Datové modelování je oborem, který se zabývá návrhem struktury a organizace dat.
• Je to proces, při kterém převádíme reálné objekty na objekty datové, s cílem zachytit v datovém
modelu realitu, o které si chceme uchovávat informace.
• Návrh správné databáze není vždy jednoduchý úkol a mnoho databázových architektů se potýká s
problémy již v počátcích projektu, kdy je potřeba identifikovat základní entity, které budou
obsazeny v databázi.
• Při návrhu databáze není pouze jedno správné řešení, ale je jich hned několik.
• Proč vytvářet datové modely:
• Protože chci poznat realitu (WOI, world of interest), její objekty a vztahy mezi nimi
• Protože chci dobře navrhnout uložení dat v informačním systému
• Protože chci dobře navrhnout funkce informačního systému
• funkce pracují s XML daty, proč vytvářet datové modely?
Datové modelování - proč vytvářet datové modely?
4
Tři úrovně datového modelu
analýza
objekt reálného světa konceptuální datový model (model tříd)
design
logický datový model (technologický datový model)
programování
(implementace)
cmp Konceptuální DM
Budova
- cisloDomovni :CisloDomovni_T
- pocetPodlazi :Int_T
CastObce
- kod :KodUP_T
- nazev :NazevCO_T10..*
CREATE TABLE Budova (
cisloDomovni CisloDomovni_T,
pocetPodlazi Int_T,
budovaID Integer NOT NULL,
castObceID Integer);
CREATE TABLE CastObce (
kod KodUP_T,
nazev NazevCO_T,
castObceID Integer NOT NULL);
fyzický datový model (implementační datový model)
5
• Postup
• vymezení entit, jejich přesná definice
• pozor: gnoseologické kategorie obecné x jednotlivé = entita x instance entity
• určení vztahů mezi entitami, orientace z nadřízené do podřízené entity (tabulka reprezentující v logickém DM
podřízenou entitu bude obsahovat cizí klíč)
• nahrazení vztahů m:n asociativními entitami (pokud to nechci dělat až v LDM)
• určení významných atributů a jejich definice
• určení datových typů atributů, jejich formální popis a jejich průběžná konsolidace
• doplnění všech atributů, jejich definic a jejich datových typů
• určení speciálních atributů - unikátních (business) klíčů
• Diagram (ERD) není datový model, datový model je uložen v repository (úložišti) CASE nebo (také) v hlavě analytika
• Diagram slouží jednak jako jedna z možností vytváření prvků modelu, jednak pro prezentaci modelu
• Diagramů může (musí) být v jednom modelu více!
• Údržba konceptuálního datového modelu (?)
Konceptuální datový model
cmp Konceptuální DM
Budova
- cisloDomovni :CisloDomovni_T
- pocetPodlazi :Int_T
CastObce
- kod :KodUP_T
- nazev :NazevCO_T10..*
entitaatribut
vztah mezi entitami (orientace, kardinalita)datový typ
Entitně relační diagram - ERD
6
Zdroj langer.zam.slu.cz/teaching/db/P02-Konceptualni%20modelovani.pps
1. Zvolte jednu (primární) entitu ze specifikace požadavků.
2. Určete atributy, jejichž hodnoty se mají pro tuto entitu zaznamenávat. Označte případné klíče
(identifikátory) a vytvořte ukázková data.
3. Popište slovně navrženou entitu, její atributy a klíče.
4. Prověřte funkční vztahy (závislosti) atributů a v případě potřeby entitu normalizujte.
5. Prověřte atributy navržené entity a zjistěte, zda je třeba zaznamenávat informace o jednom či více
atributech v nové samostatné entitě.
6. Je-li vhodné vytvořit další entitu, zakreslete ji do diagramu a vraťte se na krok 2.
7. Spojte entity vztahy, pokud tyto existují. Popište slovně vztahy mezi entitami z obou stran.
8. Prověřte seznam atributů a určete, zda některé z nich potřebují být identifikovány prostřednictvím
dvou (či více) entit. Pokud ano, umístěte atribut na příslušný vztah, který spojuje dané entity.
9. Prověřte, zda v diagramu nemáte „smyčky“, které mohou indikovat nadbytečné (odvozené) vztahy.
Pokud je vztah skutečně redundantní, odstraňte ho.
10. Vytvořte ukázková data.
11. Předveďte navržený model uživateli - pokud je to třeba, upřesněte diagram.
Další návod: Zendulka,
http://www.fit.vutbr.cz/study/courses/DSI/public/pdf/nove/DodatekA_metodologieERD.pdf
Konceptuální datový model – „kuchařka“
7
• Postup
• automatické vygenerování LDM z konceptuálního DM pomocí CASE
• vytvoření asociačních entit ze vztahů m:n (pokud jsem neudělal už v rámci konceptuálního datového
modelu nebo pokud to neudělá CASE sám)
• pro Enterprise Architect: změna datových typů vygenerovaných sloupců
• Údržba logického DM – ANO! (a bude líp)
• neudržovat jen fyzický DM v DDL skriptech, ale odvozovat jej z LDM!
• Trochu algebry: tabulka je n-nární relace na doménách D1, D2, ... , Dn (přesněji je to dvojice R = (R, R*), kde R = R(A1:D1, A2:D2, ...
An:Dn) je schéma relace R* ⊆ D1 x D2 x ... x Dn je tělo relace. A1, …, An jsou atributy. Schéma relace zapisujeme často zjednodušeně ve
tvaru R(A1, A2, ... , An).
Logický datový model (relační přístup)
Tabulka (relace, relation)sloupec
vazba (relationship) mezi tabulkami (orientace)datový typ
Datové schéma
primární klíčcizí klíč
8
Konceptuální a logický datový model – vztahy
kardinality m:n
cmp Konceptuální DM
Budova
- cisloDomovni :CisloDomovni_T
- pocetPodlazi :Int_T
CastObce
- kod :KodUP_T
- nazev :NazevCO_T
Obyvatel
10..*
0..*
0..*
9
• Postup
• automatické vygenerování PDM z LDM
pro konkrétní DB pomocí CASE
• doplnění PDM o další objekty (DB view,
sekvence, …)
Fyzický datový model pro relační databáze
Fyzický (physical) datový model (PDM) tvoří příkazy DDL (data definition
language, část SQL, analytik musí zásady znát!), například:
CREATE TABLE Budova
(
cisloDomovni CisloDomovni_T,
pocetPodlazi Int_T,
budovaID Integer NOT NULL,
castObceID Integer
)
;
CREATE TABLE CastObce
(
kod KodUP_T,
nazev NazevCO_T,
castObceID Integer NOT NULL
)
;
ALTER TABLE Budova ADD CONSTRAINT PK_Budova
PRIMARY KEY (budovaID)
;
ALTER TABLE CastObce ADD CONSTRAINT PK_CastObce
PRIMARY KEY (castObceID)
;
ALTER TABLE Budova ADD CONSTRAINT FK_Budova_CastObce
FOREIGN KEY (castObceID) REFERENCES CastObce (castObceID)
;
10
Datové typy
 Všechny atributy entit a dalších prvků datového modelu jsou striktně popsány datovými typy.
 Datový typ je prvek typu class, stereotypu dataType.
 Pro název datového typu je použita notace CamelCase (slova spojená bez mezery, počáteční písmena slov velké),
navíc má příponu _T.
 Pravidla, která splňuje atribut daného datového typu, jsou popsána buď v popisu (notes) datového typu, nebo
v dokumentech, které jsou připojeny k datovému typu (pomocí links nebo files).
 Doporučení: využít definice z informačního systému datových prvcích (ISDP, https://www.sluzby-
isvs.cz/ISDP/DefaultSSL.aspx)
Příklad definice datového typu
CisloOrientacni_T
Typ DataType
Package Datove typy
Popis Řetězec, max. délka 4 znaky, obsahuje
pouze číslice a malá a velká písmena,
začíná číslicí, písmeno je max. 1 a je
uvedeno jako poslední znak v řetězci
Formát a omezení String 4
pouze malá a velká písmena a číslice, 1-4
class Datové typy
«dataType»
cisloOrientacni_T
notes
Řetězec, max. délka 4 znaky, obsahuje
pouze číslice a malá a velká písmena,
začíná číslicí, písmeno je max. 1 a je
uvedeno jako poslední znak v řetězci
11
• Předepsaná struktura repository
 Názvy objektů (entit, tabulek, datových typů a dalších) v CamelCase (CastObce)
 (názvy entit v jednotném čísle, názvy tabulek v množném čísle)
• Názvy atributů (a také operací, metod) v camelCase (cisloDomovni)
• Názvy bez diakritiky
• V názvech minimalizovat zkratky
• Neuvádět typy objektů v jejich názvech (přípona _T v datových typech je z tohoto pohledu chybně)
• Při prezentaci modelu rozdělit diagramy tak, aby každý z nich obsahoval okolo devíti objektů
• nesdělovat čtenáři „podívej, jak složitý (datový) model jsem vytvořil“, ale „podívej, jak umím (datový)
model přehledně prezentovat“
• diagramy obsahují skupiny z nějakého pohledu příbuzných objektů
• pokud se objekt vyskytuje ve více diagramech (například z důvodu znázornění vazeb je to nutné), výskyt
objektů v kmenovém a ostatních diagramech je vhodné barevně odlišit
Formální náležitosti modelů
12
Příklad 1: budova – část obce – obec – okres – kraj
cmp Normalni formy
Budova1
- cisloDomovni :CisloDomovni_T
- pocetPodlazi :Int_T
- nazevUlice :NazevUlice_T
- cisloOrientacni :CisloOrientacni_T
CastObce
- kod :KodUP_T
- nazev :NazevCO_T
Obec
- kod :KodUzemnihoPrvku_T
- nazev :NazevObce_T
Okres
- kod :KodOkresu_T
- nazev :NazevOkresu_T
Kraj
- kod :KodKraje_T
- nazev :NazevKraje_T11..*
1
0..*
11..*11..*
13
Příklad 2a: Adresa
class Adresy 1
Budova1
- cisloDomovni :CisloDomovni_T
- pocetPodlazi :Int_T
- nazevUlice :NazevUlice_T
- cisloOrientacni :CisloOrientacni_T
CastObce
- kod :KodUP_T
- nazev :NazevCO_T
Obec
- kod :KodUzemnihoPrvku_T
- nazev :NazevObce_T
1
0..*
1
1..*
Problém?
Každý vchod budovy má svoji adresu. Dokonce mohou být v různých ulicích.
14
Příklad 2b: Adresa
Problém?
Překlep v názvu ulice:
ulice Otokara Březiny x ulice Otakara Březiny
Změna názvu ulice.
Definiční čára ulice.
class Adresy 2
CastObce
- kod :KodUP_T
- nazev :NazevCO_T
Obec
- kod :KodUzemnihoPrvku_T
- nazev :NazevObce_T
Budova
- cisloPopisne :CisloPopisne_T
- pocetPodlazi :Int_T
AdresniMisto1
- cisloOrientacni :CisloOrientacni_T
- nazevUlice :NazevUlice_T
- definicniBod :GeometrieBod_T
1
1..*
1
0..*
1
0..*
class Adresy
CastObce
- kod :KodUP_T
- nazev :NazevCO_T
Obec
- kod :KodUzemnihoPrvku_T
- nazev :NazevObce_T
Ulice
- kod :KodUlice_T
- nazev :NazevUlice_T
- definicniCaraUlice :GeometrieLinie_T
AdresniMisto
- cisloOrientacni :CisloOrientacni_T
- definicniBod :GeometrieBod_T
Budova
- cisloPopisne :CisloPopisne_T
- pocetPodlazi :Int_T
1
1..*
0..1
0..*
1
0..*
1
0..*
1
0..*
15
Příklad 2c: Adresa
smyčka v datovém modelu
16
Příklad 3: místnost – podlaží – budova – část obce
class Podlaží budov
CastObce
- kod :KodUP_T
- nazev :NazevCO_T
Podlazi
- kod :KodPodlazi_T
- plocha :M2_T
TypBudovy
- kod :KodTypuBudovy_T
- nazev :NazevTypuBudovy_T
Mistnost
- kod :KodMistnosti_T
- plocha :Plocha_T
TypMistnosti
- kod :KodTypuMistnosti_T
- nazev :NazevTypuMistnosti_T
Budova
- cisloPopisne :CisloPopisne_T
- pocetPodlazi :Int_T
10..*
1
0..*
1
1..*
10..*
1
0..*
17
Modeluj
 Pochybuj!
 Diskutuj v týmu, ptej se, čti, googluj! Všechno už bylo namodelováno.
 Rozhoduj, hodnoť varianty podle účelu DM!
 Uvědomuj si stále, že krása i kvalita je v jednoduchosti!
 Pokud ti model někde drhne, je to tvoje chyba, není to tak složité, jak se ti to jeví!
Připrav si balíček první pomoci před tím, než model ukážeš programátorovi 
Minimalizuj chyby
• Nechybí ti entita? Hlavnímu analytikovi ISKN chyběl list vlastnictví.
• Nechybí ti atribut v nějakém vztahu? V RPP analytikům Accenture chybělo pořadí právního předpisu.
• Nenamodeloval jsi náhodou jednoduchý datový model všeho? „Nedomodelováno“, příklady: PTE, obecný model GIS,
kmenové evidence v ČSSZ.
• Nenamodeloval jsi náhodou příliš složitý datový model? „Přemodelováno“.
• Nemáš v modelu příliš detailů (entit, atributů) bez struktury?
• Nemáš v modelu příliš hlubokou strukturu objektů (entit, atributů)?
• Vyšlo ti při konverzi konceptuální DM – logický DM něco jiného, než jsi chtěl?
• Zdá se ti konceptuální DM nadbytečný?
• Zdá se ti datové modelování zbytečné? Však on někdo pro xml to xsd napíše.
Zásady tvorby datového modelu
18
Normální formy datového modelu
cmp Normalni formy
Budovy1NF
- cisloPopisne :char
- kodCastiObce :char
- nazevCastiObce :char
- kodObce :char
- nazeviObce :char
- kodOkresu :char
- nazevOkresu :char
- kodKraje :char
- nazevKraje :char
BudovyNN
- cisloPopisne :char
- kodANazevCastiObce :char
- kodANazevObce :char
- kodANazevOkresu :char
- kodANazevKraje :char
Budova
- cisloDomovni :CisloDomovni_T
- pocetPodlazi :Int_T
CastObce
- kod :KodUP_T
- nazev :NazevCO_T
Obec
- kod :kodUzemnihoPrvku_T
- nazev :nazevObce_T
Okres
- kod :kodOkresu_T
- nazev :nazevOkresu_T
Kraj
- kod :kodKraje_T
- nazev :nazevKraje_T
3NF (Boyce - Coddova normální forma, BCNF)
Nenormalizovaný První normální forma
1
0..*
11..* 11..* 11..*
19
• Objekt, který přenáší data mezi procesy.
• To se obvykle děje přes vzdálené
rozhraní (např. webové služby). Je
vhodné snížit náročnost této operace
snížením počtu volání služeb ->
agregace dat do jednoho datového
objektu.
• DTO umožňuje provést denormalizaci
dat
 DTO mohou a nemusí být odvozeny z
datového modelu (např. uživatelem
zadané parametry služby).
 DTO je modelován prvkem typu class,
stereotypu DTO. Formálně se podobá
prvku modelu typu entita, může mít
však atribut stereotypu seznam.
 Použití: například u webových služeb.
Na závěr: data transfer objekty (DTO) a jejich využití
class DTO ZalozNZ
«DTO»
NavrhZmeny
- kodTypuNZ :T_Kod
- nazev :T_Text
- popis :T_Text
«DTO»
IdNavrhuZmeny
- idNZ :T_Identifikator
Konceptualni datovy model::
NavrhZmeny
- externiIdentifikator :T_Text
- idNavrhuZmeny :T_Identifikator
- idTransakceRUIAN :T_Cislo
- nazev :T_Text
- platnostOd :T_Datum
- popis :T_Text
- schvalenoKdy :T_Cas
- schvalilKdo :T_Text
- zapisRUIANKdy :T_Datum
Konceptualni datovy model::
TypNZ
- kod :T_Kod
- nazev :T_Nazev
1
0..*
20
Příklad využití DTO při modelování webové služby
21
Podklady pro další samostudium
 Anatoliy Kybkalo, Datové modelování, Bakalářská práce, Unicorn College, 2013
(http://www.unicorncollege.cz/european-it-center/kybkalo-anatoliy/attachments/PB_Kybkalo_Anatoliy_1-4146-
1.pdf, vedoucí práce Ing. Miroslav Žďárský)
 Doc.Ing.Jaroslav Zendulka,CSc.: Databázové systémy a návrh databází
http://www.fit.vutbr.cz/study/courses/DSI/public/.cs#Heading2
 http://langer.zam.slu.cz/teaching/db/P02-Konceptualni%20modelovani.pps, autor neuveden