Strukturované metodologie

Komentáře

Transkript

Strukturované metodologie
Strukturované metodologie
Strukturovaný přístup
• aplikace má podobu hierarchie funkcí, která je
realizována strukturovanými programy
• styl práce: AKCE  OBJEKT
Entitně–relační model (ERA)
• alternativní názvy: ERA, ERD, E–R, ER model
(schéma, diagram)
• množina pojmů sloužící k statickému popisu
aplikace na konceptuální úrovni
• model popisující objekty, které nás zajímají,
jejich vlastnosti a jejich vzájemné vztahy
• ERA diagram: grafický prostředek pro analýzu
a zobrazení datového modelu systému
Základní prvky a symboly (notace)
entitně–relačního modelu
1. typy entit (entitní typy, entity types)
• množiny objektů stejného typu (např. ČTENÁŘ,
KNIHA)
• entita: rozlišitelný a identifikovatelný objekt světa
objektů – existuje nezávisle a může být uvažován
sám o sobě
a) popsatelný objekt (odlišitelný od okolí)
b) jednoznačně identifikovatelný objekt (objekty
stejného typu musí být odlišitelné navzájem)
• znázornění: obdélník, název (podstatné jméno v
jednotném čísle)
Základní prvky a symboly (notace)
entitně–relačního modelu 2
2. typy vztahů (relationship types)
• vztahy, do kterých mohou entity vstupovat
(např. JSOU PŮJČENÉ)
• vztah: vazba mezi dvěma nebo více entitami
• znázornění: kosočtverec, čáry spojující
související entity a vztahy, název (sloveso)
Základní prvky a symboly (notace)
entitně–relačního modelu 3
3. atributy (attributes)
• funkce přiřazující entitám či vztahům hodnotu,
určující některou podstatnou vlastnost entity
nebo vztahu (např. DATUM VÝPŮJČKY)
• atribut: vlastnost entity (taková vlastnost z
množiny všech možných vlastností, která je
společná co do výskytu každému výskytu entity
nebo vztahu)
• doména: množina možných hodnot atributu
• znázornění: kružnice (ovál), název (podstatné
jméno)
Základní prvky a symboly (notace)
entitně–relačního modelu 4
4. integritní omezení
• definování vlastností entit, vztahů a atributů,
např. identifikační klíč (klíčová položka), datový
typ, kardinalita vztahu
Identifikátor (klíč) entity – podtržení názvu atributu
Pojmy atribut, entita a vztah jsou relativní – jejich
užití závisí na účelu, pro který ERA model tvoříme.
Příklad 1a [1]
KNIHA –
AUTOR
mohou být:
• dvě entity,
• entita –
atribut
(autor jako
atribut
knihy), nebo
• atribut –
entita (kniha
jako atribut
autora)
Příklad 1b [1]
KNIHA – VÝPŮJČKA
mohou být:
• dvě entity,
• entita – atribut
(výpůjčka jako
atribut knihy),
• atribut – entita
(kniha jako atribut
výpůjčky),
• entita – vztah
(výpůjčka jako
vztah mezi knihou
a nějakou další
entitou – např.
ČTENÁŘ)
Nejčastější způsoby vyjádření ERA
modelu
Příklad: Vladimír Koutecký z Prahy 4 si 2. října
2007 půjčil na tři týdny „Tajný deník Laury
Palmerové“ (signatura A1586)
a) lineární textový zápis
• E: ČTENÁŘ (Jméno, Adresa)
KNIHA (Signatura, Název)
• R: VÝPŮJČKA (Datum, Lhůta)
Nejčastější způsoby vyjádření ERA
modelu 2
b) grafické vyjádření [1]
Nejčastější způsoby vyjádření ERA
modelu 3
b) grafické vyjádření [1]
Nejčastější způsoby vyjádření ERA
modelu 4
b) grafické vyjádření [1]
Integritní omezení v ERA modelu
Vlastnosti entit:
identifikační (klíčové) atributy
ISA hierarchie
funkční závislost
Vlastnosti atributů: jméno
datový typ
identifikátor (klíčový)
povinný (NOT NULL)
unikátní (UNIQUE)
vícehodnotový
skupinový
odvozený
Vlastnosti vztahů: rozměr (stupeň)
kardinalita (mohutnost)
členství ve vztahu
Vlastnosti entit
Každou entitu jednoznačně definujeme v prostoru (tj. rozsahem
– které objekty do entity patří a které už ne?) a v čase (tj.
obdobím či událostí, po které je pro nás objekt součástí
entity).
Příklad: Entita ZÁKAZNÍK zahrnuje všechny osoby, které si od
firmy koupily její výrobek v běžném a v uplynulém
kalendářním roce a dále osoby, které mají výrobky firmy
objednané (i když je ještě nekoupily).
Identifikátor (klíčový atribut)
• atribut nebo množina atributů, jejichž hodnoty umožňují
jednoznačně rozlišit jednotlivé entity navzájem
Vlastnosti entit 2
ISA hierarchie (alternativní názvy: nadtyp/podtyp, generalizace/specializace):
entity nižší úrovně dědí atributy a sdílí identifikátor z entity nadřízené
úrovně
Příklad: Každý závodník má uvedeno jméno a stát, z nějž pochází. U motoristů
se navíc uvádí kubatura motocyklu, u fotbalistů jejich úloha v týmu, u
zápasníků hmotnost a u tenistů umístění na žebříčku ATP nebo WTA. [1]
Vlastnosti entit 2
Znázornění hierarchie v PowerDesigneru [1]
Vlastnosti entit 3 [1]
Vlastnosti entit 3 [1]
• Příklad: Funkční závislost atributů entity STUDENT
Vlastnosti entit 4
slabá (popisná) entita:
• entita existenčně nebo identifikačně závislá na jiné entitě (entitách)
silná (regulární, kmenová, základní) entita:
• entita existující nezávisle na jiných entitách
Příklad:
• ZBOŽÍ: silná entita
• OBJEDNÁVKA: slabá entita
Zboží může existovat bez objednávky, objednávka bez zboží nikoli.
Odstraníme-li nějaký výskyt (instanci) entity ZBOŽÍ (např. lednice
CALEX 3500), je nutné odstranit i výskyty (instance) entity
OBJEDNÁVKY, jež jsou na dané instanci existenčně závislé (tj.
všechny objednávky lednice CALEX 3500).
Vlastnosti entit 5
Typy funkční závislosti entit:
a) existenční závislost
• Prvky slabé entity závisí existenčně na prvcích jiné entity, tj. zrušíme-li
výskyt entity, na níž je slabá entita závislá, zrušíme i existenci závislé entity.
• Existenční závislost vždy obsahuje povinné členství ve vztahu (entita, která
je existenčně nezávislá, se povinně účastní v daném vztahu).
b) identifikační závislost (též externí identifikace)
• Prvky slabé entity závisejí identifikačně na prvcích jiné entity – tj. klíč slabé
entity definujeme pomocí klíče jiné entity (přebíráme identifikátor/y z
jiných entit). Vždy se jedná současně i o existenční závislost (entita, která je
identifikačně nezávislá, má vždy povinné členství ve vztahu).
• Identifikační závislost je zesílením existenční závislosti.
Vazební (asociativní) entita
• realizuje vazbu mezi entitami - využití: při dekompozici vztahů N:M na 1:N
Vlastnosti atributů
Vícehodnotový atribut
• Příklad: Jedna kniha může být zařazena do více žánrových
kategorií. KNIHA (Signatura, Název, Autor1, Autor2, Cena,
Místo vydání, Vydavatel, Rok vydání, Žánr:Multi, ISBN) [1]
Vlastnosti atributů 2
Skupinový atribut
• Příklad: Údaje o knize tvoří skupina evidenčních informací,
skupina vydavatelských informací a skupina obsahových
informací. KNIHA (EVIDENČNÍ INFORMACE (Signatura, Autor,
Cena), VYDAVATELSKÉ INFORMACE (Místo vydání, Vydavatel),
OBSAHOVÉ INFORMACE (Název, Žánr)) [1]
Vlastnosti atributů 3
Odvozený (derived) atribut
• Příklad: Délku výpůjčky zjistíme odečtením data
půjčení od data vrácení.
Vlastnosti vztahů
• vztahy určujeme mezi identifikátory (klíčovými
atributy) entit
• kombinace rozměru, kardinality a typu členství ve
vztahu (navzájem nezávislé)
Rozměr (stupeň) vztahu (relationship degree)
• počet výskytů entit v jednotlivém výskytu vztahu
• unární (rekurzívní), binární (dvojčlenný, dvojkový,
dvourozměrný), ternární (trojčlenný, trojkový,
třírozměrný) ... n-ární (n-rozměrný)
Unární (rekurzívní) vztah [1]
Binární vztah [1]
Ternární vztah [1]
Vlastnosti vztahů 2
Kardinalita (mohutnost, funkčnost) vztahu
• Určení počtu prvků nějakého vztahu – kolik
výskytů (instancí) jedné entity má vztah k
výskytu druhé entity?
a)
b)
c)
d)
písmena a číslice
číslice a symboly
šipky
„vraní stopa“ (crow´s foot)
Vlastnosti vztahů 3
Členství ve vztahu
• Možnost (ne)existence výskytu partnerské entity (vyžaduje
výskyt jedné entity výskyt druhé entity?)
• Členství (účast) ve vztahu (existenční závislost, úplnost) –
slovní vyjádření:
–
–
–
–
povinné (obligatorní) X nepovinné
totální (totalita) X parciální (parcialita)
úplné X částečné
mandatory X optional
Vlastnosti vztahů 4
Kombinované vyjádření kardinality a členství ve
vztahu (min, max notace)
Normalizace
Úprava modelu s cílem omezit redundanci a složitost
Postup: rozdělení složitých entit, atributů a vztahů na
jednodušší celky
Omezení redundance:
• každý atribut se má v modelu vyskytovat jen jednou
Omezení složitosti:
• každý atribut má být atomický (dále nedělitelný)
• každý atribut má být skalární (má obsahovat pouze
jednu hodnotu)
• v každé entitě mají být jen atributy, které spolu těsně
souvisejí
1. normální forma (1NF)
Řešený problém: multizávislost
• každý atribut entity musí obsahovat pouze
jeden údaj (hodnotu)
• jedna entita nesmí obsahovat násobná data
(data ve vztahu 1 : N)
Řešení multizávislostí v entitách, které
nejsou v 1NF
vícehodnotový atribut
• Příklad: Entita ZÁPIS obsahuje údaje o studentech a
předmětech, které si zapsali. Jeden student si může zapsat více
předmětů. [1]
Řešení multizávislostí v entitách, které
nejsou v 1NF
skupinový atribut
Příklad: Údaj o předmětu se skládá z jeho zkratky a z názvu v
češtině a v angličtině. [1]
Řešení: Přidání atributů (sloupců).
2. normální forma (2NF)
Řešený problém: funkční závislost
• entity obsahují pouze takové atributy, které
jsou funkčně (významově) závislé na celém
identifikátoru (primárním klíči) entity
Řešení funkčních závislostí v entitách,
které nejsou v 2NF
• Příklad: Evidence předmětů zapsaných jednotlivými studenty.
Název ani zkratka předmětu nejsou funkčně závislé na ID
studenta. [1]
• Řešení: Rozdělení dat do více entit.
3. normální forma (3NF)
Řešený problém: tranzitivní závislost
• žádný neklíčový atribut entity nesmí být
závislý na jiném neklíčovém atributu
Boyce Coddova normální forma (BCNF)
Byla původní definicí 3NF
• je to vlastně variace 3NF
• podmínka pro 3NF (nezávislost atributů) musí
platit i pro hodnoty uvnitř složeného klíče
4. normální forma (4NF)
Řešený problém: vztahy uvnitř složeného
primárního klíče
• pokud je v tabulce složený primární klíč, může
se stát, že některé hodnoty tohoto klíče jsou
na sobě nezávislé, ale tím, že spolu tvoří klíč,
vzniká falešná souvislost mezi těmito
hodnotami a nemohou existovat nezávisle na
sobě, což není v souladu s modelovanou
realitou
5. normální forma (5NF)
Řešený problém: týká se primárních klíčů, které
jsou tvořeny nejméně třemi atributy
• v případě, že mezi atributy v klíči existují
párové cyklické závislosti, je třeba tyto
závislosti extrahovat do samostatných tabulek,
ale původní tabulku je v některých případech
třeba zachovat
Podrobněji k normalizaci např. viz [3]
Metodika tvorby ERA diagramu [1, 2]
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.
4a. Prověřte funkční vztahy (závislosti) atributů a v případě potřeby entitu
normalizujte.
4b. Prověřte atributy navržené entity (pokud možno ve spolupráci s
uživatelem) a zjistěte, zda je třeba zaznamenávat informace o jednom či
více atributech v nové samostatné entitě.
5. Je-li vhodné vytvořit další entitu, zakreslete ji do diagramu a vraťte se na
krok 2.
6. Spojte entity vztahy, pokud tyto existují. Popište slovně vztahy mezi
entitami z obou stran.
7a. 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.
7b. Prověřte, zda v diagramu nemáte „smyčky“ (kružnice), které mohou
indikovat nadbytečné (odvozené) vztahy. Pokud je vztah skutečně
redundantní, odstraňte ho.
8. Vytvořte ukázková data.
9. Předveďte navržený model (diagram i slovní popis) uživateli. Pokud je to
třeba, upřesněte diagram.
Možné přístupy k tvorbě ERA diagramu
• 1. zdola nahoru (bottom-up)
– nejprve sestavíme seznam atributů, pak je
seskupíme do entit
• 2. shora dolů (top-down)
– nejprve definujeme entity, pak je naplníme
atributy
Ukázky např. na:
http://web.sks.cz/users/ku/DAS/era.htm
Pravidla návrhu správných ERA
diagramů
• Zobrazujeme pouze data a jejich vztahy, žádné procesy
• Každý atribut zobrazujeme pouze jednou – cílem je
strukturovat seznam atributů, nikoli např. znázorňovat
propojení v relační databázi
• Zobrazujeme seskupení dat pro účely databáze, nikoli
pro účely výstupů (kombinaci atributů z různých entit a
případné duplicity realizují až pohledy – formuláře
nebo sestavy)
• Zobrazujeme pouze perzistentní (trvalé) datové objekty
– data, jež hodláme vygenerovat výpočty a agregacemi,
nemodelujeme
Pravidla návrhu správných ERA
diagramů 2
• Zobrazujeme pouze nezbytně nutné vztahy, tj. ty, které k něčemu
využijeme (např. k propojení v dotazu) – nezobrazujeme:
– odvozené vztahy
– kruhové závislosti (smyčky)
– redundantní vztahy
Příklad: Redundantní vztah STUDENT–UČITEL:
• Entity mají být normalizované (např. atributy, mezi kterými je vztah 1 : N,
nepatří do stejné entity)
• Pozor na tyto entity:
–
–
–
–
entita bez atributů
entita, která má pouze identifikátor a žádné další atributy
entita, u níž nastane pouze jeden výskyt
entita, která obsahuje atributy patřící jiným entitám (tzv. cizí atributy)
„Strukturovaná čeština“ pro slovní
popis ERA diagramů
ENTITY
• Informační systém zaznamenává údaje o [název
entity]. Pro každou [název entity] zaznamenáváme v
informačním systému [názvy atributů].
„Strukturovaná čeština“ pro slovní
popis ERA diagramů 2
ATRIBUTY
a) Atomické atributy
Pro každou [název entity] bude existovat vždy jeden a pouze jeden [název atributu].
Hodnota [název atributu] se nebude dále členit (na dílčí údaje).
Pro každou knihu bude vždy jeden a pouze jeden název. Hodnota názvu se nebude dále
členit.
b) Složené (skupinové) atributy
Pro každou [název entity] budeme zaznamenávat [název atributu], který se skládá z
x, y, z…, (x, y, z) jsou součástmi [název atributu].
Pro každou knihu budeme zaznamenávat vydavatelské údaje, jež se skládají z názvu
vydavatele, místa vydání a roku vydání. Název vydavatele, místo vydání a rok vydání
jsou součástí vydavatelských údajů.
„Strukturovaná čeština“ pro slovní
popis ERA diagramů 3
ATRIBUTY
c) Vícehodnotové atributy
Pro každou [název entity] budeme zaznamenávat [název atributu]. Může být
zaznamenán více než jeden [název atributu] pro každou [název entity].
Pro každou knihu zaznamenáváme autory. Může být zaznamenán více než jeden autor
pro každou knihu.
d) Odvozené atributy
Pro každou [název entity] může existovat [název atributu], který bude odvozen
z databáze.
Pro každou knihu může existovat lhůta (počet dnů zapůjčení), která bude odvozena z
databáze (odečet data výpůjčky od data vrácení).
„Strukturovaná čeština“ pro slovní
popis ERA diagramů 4
KLÍČE
a) Jeden kandidát klíče (silná entita)
Pro každou [název entity] budeme mít následující primární klíč:
[název atributu].
Pro každou knihu budeme mít následující primární klíč: přírůstkové číslo.
b) Více než jeden kandidátní klíč (silná entita)
Pro každou [název entity] budeme mít následující kandidátní klíče:
[názvy atributů].
Pro každou knihu budeme mít následující kandidátní klíče: přírůstkové číslo,
signatura, ISBN.
„Strukturovaná čeština“ pro slovní
popis ERA diagramů 5
KLÍČE
c) Žádní kandidáti klíče (slabá entita)
Pro žádnou [název entity1] nepředpokládáme, že by kterýkoli z atributů byl
dostatečně unikátní, aby identifikoval individuální [název entity1] bez
doplňujícího odkazu na [název entity2], vlastnickou silnou entitu.
Pro žádnou rezervaci nepředpokládáme, že by kterýkoli z atributů byl natolik
unikátní, aby identifikoval individuální rezervaci bez doplňujícího odkazu na
knihu, vlastnickou entitu.
„Strukturovaná čeština“ pro slovní
popis ERA diagramů 6
KLÍČE
d) Žádní kandidáti klíče (vazební entita)
Pro žádnou [název vztahové entity] nepředpokládáme, že by kterýkoli z
atributů byl dostatečně unikátní, aby identifikoval individuální [název
vztahové entity] bez doplňujícího odkazu na [název entity2], vlastnickou
entitu.
Pro žádnou výpůjčku nepředpokládáme, že by kterýkoli z atributů byl natolik
unikátní, aby identifikoval individuální výpůjčku bez doplňujícího odkazu na
knihu a čtenáře, vlastnické entity.
„Strukturovaná čeština“ pro slovní
popis ERA diagramů 7
VZTAHY
[název entity1] [název vztahu – aktivum] [název entity2]
a
[název entity2] [název vztahu – pasivum] [název entity1]
Čtenáři si půjčují knihy a knihy jsou půjčovány čtenáři.
nebo
Čtenář si půjčuje knihy a kniha se půjčuje čtenářům
„Strukturovaná čeština“ pro slovní
popis ERA diagramů 8
VZTAHY
• kardinalita:
Slovní vyjádření kardinality a členství
ve vztahu
vztah jedna – jedna
Čtenář si může půjčit pouze jednu knihu, nemusí si půjčit žádnou knihu. Kniha
může být půjčena pouze jednomu čtenáři, nemusí být půjčena žádnému
čtenáři.
Čtenář si musí půjčit jednu a právě jednu knihu. Kniha může být půjčena pouze
jednomu čtenáři, nemusí být půjčena žádnému čtenáři.
Slovní vyjádření kardinality a členství
ve vztahu 2
vztah jedna – jedna
Čtenář si musí půjčit jednu a právě jednu knihu. Kniha musí být půjčena
jednomu a právě jednomu čtenáři.
Čtenář si může půjčit pouze jednu knihu, nemusí si půjčit žádnou knihu. Kniha
musí být půjčena jednomu a právě jednomu čtenáři.
Slovní vyjádření kardinality a členství
ve vztahu 3
vztah jedna – více
Slovní vyjádření kardinality a členství
ve vztahu 4
vztah jedna – více
Slovní vyjádření kardinality a členství
ve vztahu 5
vztah jedna – více
Slovní vyjádření kardinality a členství
ve vztahu 6
vztah jedna – více
Slovní vyjádření kardinality a členství
ve vztahu 7
vztah více – více
Slovní vyjádření kardinality a členství
ve vztahu 8
vztah více – více
Slovní vyjádření kardinality a členství
ve vztahu 9
vztah více – více
Diagram datových toků (DFD)
DFD – data flow diagram
• grafický prostředek návrhu a zobrazení funkčního
modelu systému
funkční model:
• pohled na realitu jako na souhrn neustále
vznikajících různých událostí
• popis procesů a jejich návazností
• popis procesů transformace informace a jejich
vzájemných vztahů
Událost – stimul – reakce
událost: to, co nastane a systém na to musí reagovat – stimul,
který spouští zpracování uvnitř systému
typy událostí:
– příchod dat do systému z okolí (např. zápis nového studenta)
– událost spojená s časem (např. týdenní kontrola prošlých
výpůjčních lhůt)
– řídící událost (vyžádání reakce řídícím prvkem vně systému –
např. výkaz práce na daném úkolu)
stimul: datový tok – sděluje systému, že událost nastala
reakce:
· výstupní datový tok do okolí
· uložení dat v systému
Typy reakcí na událost
• jedna událost –
jedna reakce
(proces)
• jedna událost –
různé reakce
(procesy)
• více událostí –
stejná reakce
(proces)
Základní prvky a symboly (notace)
diagramů datových toků [1]
Základní prvky a symboly (notace)
diagramů datových toků 2
Hierarchický princip tvorby DFD
(top-down) [1]
Kontextový diagram
• lidé, organizace, systémy, které s
modelovaným systémem komunikují
• data, která systém dostává z okolí a která musí
zpracovat
• data, která systém produkuje
• datastory sdílené systémem a terminátory
(zdroj nebo místo určení dat mimo systém)
• seznam událostí, na které musí systém
reagovat
Doporučený postup tvorby DFD
1. vytvořit kontextový diagram
2. sestavit seznam událostí
3. pro každou událost vytvořit proces (proces = reakce
na událost)
4. každý proces pojmenovat podle reakce na událost
5. ke každému procesu doplnit vstupy, výstupy, příp.
datastory
–
–
jaká data proces potřebuje?
co je jeho výstupem?
6. kontrola konzistence – všechny vstupy a výstupy z
kontextového diagramu se musíobjevit v DFD
Příklad DFD [1]
Příklad DFD 2 [1]
Software
•
•
•
•
•
•
•
•
Enterprise Architect
PowerDesigner
Oracle Designer
Microsoft Visio
Visual Paradigm for UML
...
ArgoUML
...
Literatura
• [1] Kučerová, H. Projektování informačních systémů (Sylaby ke
kurzu). Praha: VOŠIS, 2007. [on-line] [cit. 6.12.2011].
Dostupné na URL:
http://web.sks.cz/users/ku/DOKUMENTY/pri_syl.pdf
• [2] BAGUI, Sigha a EARP, Richard. Database design using
entity-relationship diagrams. Boca Raton : Auerbach
Publications, 2003. 264 s. ISBN 0849315484.
• [3] Velbloud. Teorie relačních databází: Normalizace. [on-line]
[cit. 6.12.2011]. Dostupné na URL:
http://www.manualy.net/article.php?articleID=13

Podobné dokumenty

Datový model

Datový model přiřazující entitám či vztahům hodnotu popisného typu, určující některou podstatnou vlastnost entity nebo vztahu. Vymezení pojmů entita, vztah a atribut je dosti volné. Vodítkem může být, že v souv...

Více

Závěrečná zpáva NNŽ - Nákladové nádraží Žižkov

Závěrečná zpáva NNŽ - Nákladové nádraží Žižkov návrhu atelieru Florart v roce 2013. Mottem projektu bylo: „Přebrodit řeku. Poslouchat ticho. Sledovat oblohu. Sednout si do trávy. Přivítat vodáky.“ Automat - Vize Praha 2025 je nový dokument inic...

Více

RFEM 5 / RSTAB 8 - Dlubal Software s.r.o.

RFEM 5 / RSTAB 8 - Dlubal Software s.r.o. 'Pro' získají zákazníci možnost využít navíc technickou podporu po telefonu nebo pomocí online sdílení obrazovky, je-li to vyžadováno. Uvítáme jakékoliv vaše názory k našim produktům. Vaše připomín...

Více

Databázové systémy

Databázové systémy a nerelační je spíše pomocné (ukazuje, která struktura dat byla v té které vývojové etapě nejobvyklejší – existují však i síťové nebo hierarchické databáze). Základním dělítkem je způsob práce s da...

Více

Normální tabulky, entity a relace

Normální tabulky, entity a relace do ní přidat nový sloupec nebo skupinu sloupců tak, aby se vlivem skrytých závislostí rozpadla na několik dílčích tabulek. U tabulek nestačí jen určovat, v jaké jsou normální formě. Je třeba usilov...

Více

zvláštní neprodejná příloha | duben 2015

zvláštní neprodejná příloha | duben 2015 podnikové procesy. Událost HA (jako je například převzetí služeb clusterovým uzlem při selhání) může způsobit přerušení služby na dobu v řádu minut, zatímco obnova ze zálohy na nový hardware může t...

Více

CASE pro podporu databází

CASE pro podporu databází Společnost Oracle nabízí hned několik CASE nástrojů podporujících vytváření databází. Všechny tyto nástroje jsou zdarma s licencí umožňující používat jejich plné verze k vyvíjení vlastních aplikací...

Více

Databázové systémy I.

Databázové systémy I. Indexy - druhy indexu a jejich význam Záznamy v tabulkách jsou neutříděné a často v pořadí v jakém byly zadány. V případě hledání v takovéto oblasti dat je nutné projít minimálně polovinu intervalu...

Více

Studijní text - E-learningové prvky pro podporu výuky

Studijní text  - E-learningové prvky pro podporu výuky aby se v nich údaje dobře vyhledávaly, v případě potřeby opravovaly a doplňovaly, někdy počítaly údaje nové, z původních odvozené, vytvářely různé výsledné přehledné tabulky apod. Objekty (lidi, zv...

Více