Snímek 1

Popis snímku:

Snímek 2

Popis snímku:

Databáze V užším slova smyslu je databáze soubor dat potřebných pro práci. Data jsou však abstrakcí; nikdo nikdy neviděl „jen data“; nevznikají a neexistují samy. Data jsou odrazem objektů v reálném světě. V nejširším slova smyslu je databáze souborem popisů objektů v reálném světě a souvislostí mezi nimi, které jsou relevantní pro konkrétní oblast aplikace.

Snímek 3

Popis snímku:

Snímek 4

Popis snímku:

Snímek 5

Popis snímku:

Pojmy databáze Například tabulka Díl obsahuje informace o všech částech uložených ve skladu a její řádky jsou sady hodnot atributů pro konkrétní součásti. Každý sloupec v tabulce je souborem hodnot pro konkrétní atribut objektu. Sloupec Materiál je tedy sada hodnot „Ocel“, „Cín“, „Zinek“, „Nikl“. Sloupec Množství obsahuje nezáporná celá čísla. Hodnoty ve sloupci Weight jsou reálná čísla rovnající se hmotnosti součásti v kilogramech. Tyto hodnoty se neobjevují ze vzduchu. Jsou vybrány ze sady všech možných hodnot pro atribut objektu, který se nazývá doména. Hodnoty ve sloupci materiálu jsou tedy vybrány ze sady názvů všech možných materiálů - plastů, dřeva, kovů atd. Ve sloupci Materiál je proto zásadně nemožné, aby se objevila hodnota, která není v odpovídající doméně, například „voda“ nebo „písek“. Každý sloupec má název, který je obvykle napsán v horní části tabulky. Musí být v tabulce jedinečný, ale různé tabulky mohou mít sloupce se stejným názvem. Každá tabulka musí mít alespoň jeden sloupec; sloupce jsou v tabulce uspořádány podle pořadí jejich názvů při jejím vytvoření. Na rozdíl od sloupců řádky nemají názvy; jejich pořadí v tabulce není definováno a počet není logicky omezen.

Snímek 6

Popis snímku:

Snímek 7

Popis snímku:

Snímek 8

Popis snímku:

Snímek 9

Popis snímku:

Tabulky nelze ukládat a zpracovávat, pokud v databázi nejsou žádná „data o datech“, například deskriptory tabulek, sloupců atd. Běžně se jim říká metadata. Metadata jsou také prezentována v tabulkové formě a jsou uložena v datovém slovníku. Tabulky nelze ukládat a zpracovávat, pokud v databázi nejsou žádná „data o datech“, například deskriptory tabulek, sloupců atd. Běžně se jim říká metadata. Metadata jsou také prezentována v tabulkové formě a jsou uložena v datovém slovníku. Kromě tabulek může databáze ukládat další objekty, jako jsou displeje, sestavy, zobrazení a dokonce i aplikace, které s databází pracují. Uživatelům informačního systému nestačí, že databáze jednoduše odráží objekty skutečného světa. Je důležité, aby taková reflexe byla jednoznačná a konzistentní. V tomto případě se říká, že databáze splňuje podmínku integrity. Aby byla zaručena správnost a vzájemná konzistence dat, jsou na databázi kladena některá omezení, která se nazývají omezení integrity.

Snímek 10

Popis snímku:

Snímek 11

Popis snímku:

Snímek 12

Popis snímku:

Snímek 13

Popis snímku:

Snímek 14

Popis snímku:

Snímek 15

Popis snímku:

Snímek 16

Popis snímku:

Snímek 17

Popis snímku:

Snímek 18

Popis snímku:

Snímek 19

Popis snímku:

Jiné normální formuláře První normální forma zakazuje tabulkám, aby měly neatomové nebo vícehodnotové atributy. Existuje však mnoho modelových situací, které vyžadují vícehodnotové atributy. Například učitel na univerzitě je zodpovědný za několik oborů. Existuje několik řešení, z nichž každé má určité nevýhody. Všechny vyžadují dodatečnou paměť kvůli přítomnosti prázdných hodnot nebo kvůli potřebě zadat nadbytečná data. Ti s nulovými hodnotami narušují kategorickou integritu, protože všechny atributy dohromady tvoří klíč tabulky. Tyto zjevné vztahy mezi nezávislými atributy lze eliminovat požadavkem, aby byla každá hodnota atributu kombinována s každou další hodnotou atributu alespoň na jednom řádku. Podmínka, která zajišťuje nezávislost atributů vyžadováním opakování hodnot, se nazývá vícehodnotová závislost. Vícehodnotová závislost je stejně omezující jako funkční závislost. Je zřejmé, že vzhledem k tomu, že vyžadují velký počet opakování hodnot dat, je důležitým krokem v procesu normalizace zbavení se vícehodnotových závislostí. Tabulka má čtvrtý normální tvar (4NF), pokud má 3NF a neobsahuje závislosti s více hodnotami. Abychom se zbavili některých dalších anomálií, bylo navrženo několik dalších normálních forem: pátá normální forma (5NF), normální oblast / klíčová forma (NFOK) atd. Mají však velmi omezené praktické využití.

Snímek 21

ZÁKLADNÍ POJMY VZORKOVÉHO MODELU ÚDAJŮ

• Relační systémy jsou založeny na relační datový model.
• Principy relačního modelu byly stanoveny v letech 1969-1970. Američtí vědci E. F. Coddom(E. F. Codd), poté v IBM. Vyučený matematik přinesl do oblasti správy databází přísné matematické principy a přesnost, které raným systémům chyběly. Přestože relační přístup nebyl zaveden okamžitě, lze poznamenat, že téměř všechny byly vytvořeny od konce 70. let. databázové produkty jsou založeny přesně na relačním přístupu.
• V tomto směru byla také provedena drtivá většina vědeckých výzkumů v oblasti databází za posledních 35 let.
• Při zvažování a postupném zdokonalování základních konceptů relačního modelu budeme mít na paměti tři komponenty datového modelu:
• datové struktury,
• operace, které lze provádět s daty, a
• omezení integrity dat.

• Hlavní datové struktury v relačním modelu jsou stoly, v relační teorii nazývané vztahy. Vlastně z pojmu přístup(v anglickém vztahu) a název samotného modelu se stal - relační... Obrázek ukazuje příklad takového tabulkového vztahu a vysvětlení základních pojmů relačního modelu - řazená kolekce členů, kardinál, atribut, stupeň, doména, primární klíč.

ZÁKLADNÍ POJMY VZORKOVÉHO MODELU ÚDAJŮ

• Vztah je tabulka, podobný tomu, který je zobrazen na obrázku, řádek a sloupec a má linku nahoře volal záhlaví vztahu.
• Volají se řádky tabulky vztahů n -tice(n -tice) a sloupce atributy(atribut).
• Počet n -tic ve vztahu se nazývá základní číslo vztahu a počet atributů se nazývá stupeň vztahu.
• Každý atribut ve vztahu má název, která je uvedena v záhlaví vztahu.
• Klíč vztahu Je atribut nebo sada atributů vztahu taková, že v daném okamžiku ve vztahu neexistují žádné řádky, pro které jsou hodnoty nebo kombinace hodnot klíčových atributů stejné. Klíč je tedy jedinečný identifikátor n -tic vztahy (na obrázku je klíčový atribut tučně).
• Vztahová doména Je sada hodnot, ze kterých lze převzít hodnoty konkrétního atributu. To znamená, že konkrétní sada hodnot pro atribut v daném okamžiku musí být podmnožinou sady hodnot pro doménu, ve které je atribut definován. Hodnoty atributů, které nejsou obsaženy v sadě určené doménou, jsou neplatné.

ZÁKLADNÍ POJMY VZORKOVÉHO MODELU ÚDAJŮ

• Koncept domény je pro relační model důležitý. Doména ve skutečnosti nastavuje omezení, která musí hodnoty odpovídajícího atributu splňovat.
• Jak již bylo uvedeno, výše uvedené definice nejsou přísné. Pojmy jako tabulka, řádek, sloupec, přísně vzato, nejsou zcela ekvivalentní matematickým konceptům používaným v relačním modelu: relace, řazená kolekce členů, atribut, resp. V praxi se však často používají právě jako synonyma, což je obecně přípustné, pokud je současně pochopeno, jaký skutečný význam je v těchto pojmech zakotven.

• Hlavní úkoly návrhu databáze:
• Poskytování úložiště všech potřebných informací v databázi.
• Zajištění možnosti získat data o všech nezbytných požadavcích.
• Snížení redundance a duplikace dat.
• Zajištění integrity dat (správnost jejich obsahu): odstranění rozporů v obsahu dat, eliminace jejich ztráty atd.
• Hlavní fáze návrhu databáze:
• 1) Koncepční (infologický) design- vybudování formalizovaného modelu předmětné oblasti. Takový model je postaven pomocí standardních jazykových nástrojů, například obvykle grafických ER diagramy(diagramy „Vztah entity“). Takový model je postaven bez zaměření na konkrétní DBMS.
• Hlavní prvky tohoto modelu:
• Popis objektů předmětné oblasti a spojení mezi nimi.
• Popis informačních potřeb uživatelů (popis základních dotazů do databáze).
• Popis algoritmických závislostí mezi daty.
• Popis omezení integrity, tj. požadavky na platné hodnoty dat a vztahy mezi nimi.

KROKY A ZÁKLADNÍ ZÁSADY NÁVRHU DATABÁZE

• 2) Logický (datalogický) návrh- mapování infologického modelu na datový model používaný v konkrétním DBMS, například na relační datový model. Pro relační DBMS datalogický model- sada tabulek, obvykle s uvedením klíčových polí, vztahy mezi tabulkami. Pokud je infologický model postaven ve formě ER diagramy(nebo jiné formalizované prostředky), pak datový design je konstrukce tabulek podle určitých formalizovaných pravidel, stejně jako normalizace těchto tabulek. Tuto fázi lze do značné míry automatizovat.
• 3) Fyzický design- implementace datologického modelu pomocí konkrétního systému DBMS, jakož i výběr řešení souvisejících s fyzickým prostředím ukládání dat: volba metod pro správu diskové paměti, způsoby přístupu k datům, metody komprese dat atd. - tyto úkoly jsou řešeny převážně pomocí DBMS a jsou skryty před vývojářem databáze.
• Ve fázi infologického návrhu je při shromažďování informací o předmětné oblasti nutné zjistit:
• hlavní objekty předmětné oblasti (objekty, o kterých by měly být informace uloženy v databázi);
• atributy objektu;
• spojení mezi objekty;
• základní dotazy do databáze.

KROKY A ZÁKLADNÍ ZÁSADY NÁVRHU DATABÁZE

• Principy návrhu pro víceuživatelské databáze by mělo být omezeno na dodržení dvou předpokladů: systémový přístup a standardizace.
• Systémový přístup. Systematický přístup k vývoji informačního systému znamená, že je takový systém považován za rozsáhlý systém skládající se z řady vzájemně propojených a interagujících prvků. Při navrhování informačních systémů je třeba dodržovat následující zásady:
• s přihlédnutím k zájmům všech potenciálních uživatelů systémů;
• modulární design a implementace.
• Standardizace. Standardizace vývoje informačních systémů vzhledem k jejich víceuživatelské povaze má následující aspekty:
• informační;
• program;
• Hardware.
• Standardizace informace poskytování je způsobeno zásadami počítačového zpracování symbolických informací, protože databázové objekty musí počítač jednoznačně rozpoznat.

ÚDAJE O MODELU

• Model vztahu entity(ERM) je datový model, který vám umožňuje popsat koncepční schémata domény.
• ER model se používá při návrhu databáze na vysoké úrovni (koncepční). S jeho pomocí si můžete vybrat klíčové entity a k označení spojení které lze mezi tyto entity nainstalovat.
• Během návrhu databáze je model ER převeden do konkrétního schématu databáze na základě vybraného datového modelu (relační, objektový, síťový atd.).
• Model ER je formální konstrukce, který sám o sobě nepředepisuje žádné grafické prostředky jeho vizualizace.
• Model vztahu entity byl navržen v roce 1976 Peterem Pin-Shen Chenem, americkým profesorem počítačové vědy na Louisianské státní univerzitě.

ÚDAJE O MODELU

• Notace Petera Chena
• Sady entity jsou zobrazeny jako obdélníky, mnoho vztahů jsou znázorněny jako kosočtverce.
• Pokud se subjekt účastní úcta, jsou spojeny čarou. Pokud je vztah volitelný, pak tečkovaná čára.
• Atributy jsou zobrazeny jako ovály a jsou spojeny čarou s jedním vztahem nebo s jednou entitou

• Převedení konceptuálního modelu na relační model je následující:
• Vytvořte sadu prozatímních tabulek a zadejte primární klíče.
• Proveďte proces normalizace.
• Uvažovali jsme o prvním bodu ve třetí lekci, s druhým ještě nejsme obeznámeni, ale seznámíme se v praxi. Musíme tedy sestavit sadu tabulek.
• To není těžké, protože tabulky jsou naše objekty a pole tabulky jsou atributy objektů. Sada předběžných tabulek, založená na našem konceptuálním modelu, vypadá takto:

PŘEVOD KONCEPČNÍHO MODELU NA VZTAHOVÝ MODEL

• Tak jsme definovali stoly, pole, primární klíče(RK) a připojení(FK).
• V tabulkách Deníku doručení a Deníku nákupu jsou primární klíče - kompozitní, tj. skládá se z dvě pole.
• Teoreticky existují tabulky, ve kterých jsou všechna pole jedna složený klíč.
• Normalizace je krok za krokem, reverzibilní proces nahrazení původního schématu jiným schématem, ve kterém mají tabulky jednodušší a logičtější strukturu. To je nezbytné k eliminaci redundance dat.

Podobné dokumenty

abstrakt, přidáno 3.8.2010


Základní principy návrhu relační databáze a jejich praktická implementace v MS Access. Koncepční a logický model relační databáze, její fyzický design. Automatizace procesu interakce se zákazníky a dodavateli.

semestrální práce, přidáno 03/10/2015


Vývoj koncepčního modelu databáze „Car Championship“: popis předmětové oblasti, katalog úkolů, popis tabulek, datové schéma, ER-diagram. Navrhování relačního modelu „Sports Complex“. Implementace a výsledek databáze.

semestrální práce, přidáno 14. 6. 2011


Koncept databáze, její architektura. Klasifikace databáze. Základní datové modely. Příklady strukturovaných a nestrukturovaných dat. Výhody a nevýhody architektury souborového serveru. Hierarchický datový model. Typy indexů, normalizace.

prezentace přidána 08/06/2014


Funkce automatizovaného systému „Katedra postgraduálního studia“. Návrh relačního modelu a vývoj SQL databáze. Analýza informační podpory funkcí. Navrhování globálního modelu ER. Místní omezení a specifikace pravidel.

semestrální práce, přidáno 04/01/2011


Konstrukce infologického datového modelu katalogu digitálních diskových úložišť. Nové okno pro vytvoření souboru. Datové typy ve Visual FoxPro. Seznam typů indexů. Struktura tabulek, vztah mezi nimi. Přizpůsobte vzhled formuláře. Výběr pole pro třídění dat.

semestrální práce, přidáno 24. 9. 2013


Počítačový informační systém. Hlavní rozdíl mezi databázovým systémem a tradičním souborovým systémem. Budování konceptuálního modelu, relačního modelu. Normalizace. Návrh databáze v ACCESS. Vytváření SQL dotazů.

semestrální práce, přidáno 11. 6. 2008


Relační algebra jako systém operací se vztahy v relačním datovém modelu. Set-teoretické operátory, syntaxe sjednocení, průnik, odčítání a karteziánské součinové operace. Využití databází ve výpočetní technice.

semestrální práce přidána 1. 2. 2015


Charakteristika síťového datového modelu a jeho přednosti. Budování hierarchického datového modelu založeného na principu hierarchické podřízenosti typů objektů, jeho uvedení do podoby stromu zavedením redundance. Relační model založený na teorii vztahů.

abstrakt, přidáno 28.11.2011


Definice databáze a datových bank. Součásti datové banky. Základní požadavky na integrovanou technologii ukládání a zpracování dat. Systém řízení a modely pro organizaci přístupu k databázím. Vývoj a správa aplikací.

| Typy datových modelů

Lekce 40
Typy datových modelů

Po prostudování tohoto tématu se naučíte a zopakujete:

Co je to datový model;
- jaká je zvláštnost hierarchického datového modelu;
- jaká je zvláštnost síťového datového modelu;
- jaká je zvláštnost relačního datového modelu;
- jak jsou vztahy vytvářeny v relačním modelu.

Vztahy mezi tabulkami v relačním datovém modelu

Relační datový model se obvykle skládá z několika souvisejících tabulek. Pokud vázáte dva objekty nití, pak je jeden objekt připojen k jednomu konci vlákna a druhý objekt je připojen k druhému konci. Také mezi tabulkami: jeden konec odkazu patří k jedné tabulce a druhý konec odkazu na druhý. Odkaz tedy vždy spojí pouze dvě tabulky.

Vztahy mezi tabulkami jsou jednoho ze tří typů:

- „jeden na jednoho“;
-„jedna k mnoha“;
-„mnoho-k-mnoha“.

Jak vidíte, název typu odkazu se skládá ze dvou slov, která představují dva konce odkazu mezi tabulkami.

Předpokládejme, že máme dvě tabulky - TAB1 a TAB2.

Vztah „jeden na jednoho“ (symbol 1: 1) znamená, že jeden záznam v tabulce TAB1 odpovídá pouze jednomu záznamu v tabulce TAB2 a jeden záznam v tabulce TAB2 odpovídá pouze jednomu záznamu v tabulce TAB1. Ve vztahu jeden k jednomu mají obě tabulky, TAB1 a TAB2, stejný počet záznamů a mezi těmito záznamy je vytvořena korespondence jedna k jedné.

Jedna tabulka například popisuje třídu školy. Může obsahovat data, jako je číslo školy, směr (výchovná předpojatost), adresa, telefon. Další tabulka popisuje třídu ředitele podle následujících parametrů: příjmení, jméno, příjmení a osobní údaje ředitele. Protože každá škola může mít pouze jednoho ředitele a každá osoba může být ředitelem pouze v jedné škole, existuje mezi těmito dvěma tabulkami individuální vztah. Osobní vztah je poměrně vzácný typ vztahu.

Vztah „jedna k mnoha“ (symbol 1: M) znamená, že jeden záznam v tabulce TAB1 (konec vztahu „jeden“) odpovídá mnoha záznamům v tabulce TAB2 (konec vztahu „mnoho“ ), ale jeden záznam v tabulce TAB2 odpovídá pouze jednomu záznamu v tabulce TAB1. Tabulka na straně jednoho vztahu se nazývá hlavní a tabulka na straně vztahu mnoho se nazývá podřízená. Tento vztah je také charakterizován skutečností, že záznamy v hlavní tabulce nemusí mít podřízené záznamy, ale pro každý záznam v podřízené tabulce musí existovat záznam v hlavní tabulce. Vztah jedna k mnoha je nejběžnějším typem vztahu.

Předpokládejme například, že tabulka Dům obsahuje informace o ulicích a číslech domů, zatímco tabulka Apartmány obsahuje informace o čísle bytu v domě, počtu pokojů a celkovém obytném prostoru. Mezi tabulkami House a Apartment existuje vztah „one-to-many“-„jeden“ ze strany stolu House, „many“ ze strany stolu Apartment. Důvodem je, že jeden dům může obsahovat mnoho bytů, ale jakýkoli konkrétní byt se nachází pouze v jednom domě. Při popisu vztahu typu „jedna k mnoha“ nejprve určete hlavní tabulku a poté podřízenou.

Vztah „mnoho k mnoha“ (symbol M: M) znamená, že jeden záznam v TAB1 odpovídá mnoha záznamům v TAB2 a jeden záznam v TAB2 odpovídá mnoha záznamům v TAB1.

Tabulka Stops obsahuje například adresy zastávek pro trasy veřejné dopravy a tabulka Routes obsahuje seznam tras. Mezi těmito tabulkami je vytvořen vztah mnoho k mnoha, protože mnoho tras může dorazit na jednu zastávku a naopak každá trasa má mnoho zastávek.

Grafické znázornění relačního modelu

Graficky lze relační model znázornit, jak je znázorněno na obr. 4.9. Každá tabulka je v horní části zobrazena jako obdélník s názvem tabulky (třída objektu). Níže můžete zadat názvy polí. Klíčová pole jsou zvýrazněna. Spojovací čáry mezi tabulkami představují vztahy. Nad odkaz v konkrétní databázi můžete napsat jeho význam a také typ vztahu: „one-to-many“, „many-to-many“.

Rýže. 4.9. Relační model

Pojďme vytvořit relační model pro databázi Song. Pojďme reprezentovat informace o písních ve formě dvou vzájemně propojených tříd - Umělci a Písně. Poté místo jedné tabulky získáte dvě (tabulky 4.3, 4.4).

Budeme uvažovat o modelu, kde každou skladbu hraje pouze jeden interpret. O třídách Umělci a Písně pak lze říci, že mají vztah jedna k mnoha. Tabulka Artists bude mít přirozeně méně záznamů než tabulka Songs.

Tabulka 4.3. Účinkující

Tabulka 4.4. Písně

Pokud bychom přijali podmínku, že každou skladbu může hrát několik interpretů, pak by se vztah mezi stoly stal mnoha a to by byl jiný model.

Jako klíč v tabulce Umělci můžete vybrat pole Umělec, protože jména umělců se neopakují. Toto pole je text. Při navrhování databází se často zavádí další pole číselného typu, ve kterém je uvedeno pořadové číslo každého záznamu v tabulce.

Obvykle se toto pole jmenuje Code<имя объекта>... Toto pole se zadává za účelem dalšího počítačového zpracování dat. Jde o to, že pro softwarové prostředí je „jednodušší“ pracovat s čísly než s textem. Sekvenční čísla se neopakují, takže takové pole lze vybrat jako klíčové pole.

V tabulce Umělci tedy můžete zadat pole Kód umělce číselného typu a v tabulce Písně můžete zadat pole Kód písně.

V tabulkách propojených vztahem jedna k mnoha je vztah mezi tabulkami prováděn klíčovým polem následujícím způsobem. Do tabulky Songs je přidáno pole s názvem Artist code a u každé skladby jsou uvedena odpovídající čísla interpretů. Takové číslo ve skutečnosti nese všechny informace o umělci uvedené v odpovídající tabulce. To znamená, že vztah mezi tabulkami se provádí pomocí klíče Executor Code. Relační model této databáze je znázorněn na obr. 4.10.

Rýže. 4.10. Model relační databáze Oblíbené písně

Nabízí se logická otázka: proč bylo nutné rozdělit jednu tabulku na dvě? Na první pohled se může zdát, že jedna tabulka (viz tabulka 4.1) je pro vnímání informací pohodlnější. Ale v takové tabulce jsme museli pokaždé zcela uvést jméno umělce a všechny jeho vlastnosti. Protože podle vlastnosti relačních tabulek je každý záznam (řádek) považován za nezávislý na jiných záznamech, taková tabulka plně neodráží vztah mezi skladbami a umělci. Navíc pokud do nějakého řádku napíšete exekutor s chybou, pak to bude vnímáno jako nová hodnota. Pokud jsou umělci rozděleni do samostatné tabulky, pak takové operace, jako je mazání nebo změna dat, lze provádět mnohem jednodušeji a rychleji.

Je třeba poznamenat, že vztah mnoho k mnoha je implementován jiným, složitějším způsobem.

Převod hierarchických a síťových datových modelů na relační

Viděli jsme tři datové modely. Preferovaný model úložiště je relační model. Většina výpočetních prostředí je orientována na relační model. Hierarchický a síťový model lze redukovat na relační.

Už jsme diskutovali, že v těchto modelech každá úroveň představuje jednu třídu objektů. V relačním modelu tabulka popisuje samostatnou třídu objektů. Aby se tedy hierarchický a síťový model zredukoval na relační, je nutné každou úroveň (třídu) popsat jako samostatnou tabulku a navázat mezi nimi vazby.

Uvažujme příklad hierarchického modelu lidských sídel na planetě Zemi (obr. 4.11). Je v něm zvýrazněna kořenová úroveň - planeta Země, druhá úroveň označuje kontinenty, třetí - země, čtvrtá - osady.

Rýže. 4.11. Hierarchická modelová planeta Země

Kořenová úroveň bude sloužit jako název databáze. Každou další úroveň popisujeme jako samostatnou tabulku. Dostaneme následující relační model (obrázek 4.12).

Rýže. 4.12. Relační model planety Země

Mezi tabulkami jsou navázány vztahy jedna k mnoha. Vztah ze strany „jedné“ odkazuje na tabulku popisující nejvyšší úroveň, vztah ze strany „mnoha“ pak na tabulku popisující podřízenou úroveň.

Pro síťový model Záliby dospívajících (obr. 4.13) je každá úroveň také koncipována jako samostatná tabulka. Mezi tabulkami je navázán vztah mnoho k mnoha.

Rýže. 4.13. Relační model Dospívající koníčky

Kontrolní otázky a úkoly

1. Co je to datový model a k čemu slouží?

2. Uveďte definici informačního modelu a porovnejte jej s definicí datového modelu. Najděte mezi nimi společné a odlišné vlastnosti.

3. Jaké formy prezentace informačního modelu znáte? Porovnejte je a udělejte závěr, kdy je lepší použít jednu nebo jinou formu prezentace.

4. Uveďte příklady datových modelů pro různé tematické oblasti.

5. Co je to obecně hierarchický datový model?

6. Co je to hierarchický datový model?

7. Jaké jsou vlastnosti hierarchického datového modelu?

8. Uveďte příklady hierarchických datových modelů.

9. Co je to síťový datový model obecně?

10. Jaké jsou vlastnosti síťového datového modelu?

11. Uveďte příklady síťových datových modelů.

12. Jaký je obecný relační datový model?

13. Jak rozumíte vztahu mezi informačními objekty 1: 1? Uveďte příklady tohoto typu vztahu.

14. Jak rozumíte vztahu mezi informačními objekty 1: M? Uveďte příklady tohoto typu vztahu.

15. Jak rozumíte vztahu mezi informačními objekty M: M? Uveďte příklady tohoto typu vztahu.

16. Jaké jsou vlastnosti relačního datového modelu?

17. Uveďte příklady relačních datových modelů.

18. Jak je grafický model relačních dat zobrazen?

19. Uveďte příklady převodu hierarchického modelu na relační.

20. Uveďte příklady převodu síťového modelu na relační.

Tento datový model implementováno v mnoha stávajících DBMS , a dnes je

nejčastější. Hlavní výhody relační přístup:

malá sada jednoduchých a přesných konceptů které vám umožní simulovat různé tematické oblasti; teoretická podpora ve formě

mocný matematický aparát

teorie množin a relační algebra;

Formálně s ohledem na tento model, který odkazuje na datové modely nízké úrovně, se rozlišují následující hlavní.

Aspekty: Strukturální organizace dat

- závisí na tom účinnost ukládání dat a rychlost jejich zpracování;

způsoby poskytování integrita dat- k odstranění rozporů mezi vzájemně souvisejícími datovými prvky;

manipulace s daty, tj.

Strukturální organizace dat v relačním modelu

Základem relačního modelu je

matematický koncept vztahu.

Fyzická reprezentace vztahu je obvyklá dvourozměrná tabulka.

Samostatná tabulka pro některé obvykle ukládá data

informační objekt (IO).

U této metody strukturování dat se databáze nazývá relační.

Příklady informačních objektů

V tabulce relační databáze se sloupcům říká pole a odpovídají podrobnostem IO, pro kterou je uvažovaná tabulka určena.

Každé pole má obvykle smysluplný název a je v samostatné tabulce názvy polí nejsou

by se mělo opakovat.

Řádky tabulky pro ukládání dat se nazývají záznamy (nebo řazené kolekce členů).

Pole samostatného záznamu ukládají hodnoty atributů pro konkrétní instanci uvažovaného IO.

Ukázková tabulka pro ukládání dat

Při vytváření záhlaví tabulky nezáleží na pořadí sloupců.

Počet sloupců určuje

stupeň vztahu (tabulka).

Unární vztah má stupeň 1 a binární vztah stupeň 2.

Mohutnost vztahu

měřeno počtem záznamů

Základní (základní) vlastnosti relace (tabulky)

1. Každá buňka vztahu obsahuje pouze jednu elementární (atomovou, nedělitelnou) hodnotu.

2. Každý záznam je jedinečný, tj. duplikace záznamů není povolena.

Vyplývá to z definice tabulky jako sady záznamů a každá sada podle definice sestává z různých prvků.

3. Na pořadí umístění záznamů nezáleží, což také vyplývá z konceptu „sady“.

Pokud potřebujete nahrávat, můžete

objednat podle provozu

Integrita dat v relačním modelu

Tyto požadavky na zajištění správnosti údajů zahrnují dvě podmínky:

integrita tabulek (vztahů);

Vyžadující integritu tabulky

je, že jakýkoli záznam v dané tabulce musí být odlišitelný od jakéhokoli jiného záznamu.

Minimální sada atributů, která umožňuje jednoznačnost

identifikovat každý záznam dotyčného vztahu,

nazvaný potenciální klíč. Klíč se nazývá jednoduchý pokud se skládá z jednoho atributu (pole).

Například číslo daňového poplatníka (DIČ) lze použít k jedinečné identifikaci jeho adresy, příjmení a dalších osobních údajů.

Klíč se nazývá složený, pokud je

vytvořené z několika atributů.

Vztah má vždy alespoň jeden klíč, protože jako poslední možnost pro tuto roli můžete použít všechny

mnoho atributů.

Potenciální klíč, který je vybrán pro jednoznačnou identifikaci

nazývají se záznamy v tabulce primární klíč(Primární klíč - PK).

Jako součást primárního klíče nesmí žádný z atributů obsahovat hodnoty null.

Další potenciální klíče

stát alternativními klíči (AK).

Pro primární klíč je nejlepší

Požadavek reference
integrita je dána skutečností, že
velmi často data pro
vzájemně související informace
objekty (IO) jsou uloženy v různých
	Výuka
stoly.
(RK Kodteli prep
		Oddělení_kód
	prostřední jméno
	Pozice	název
(Oddělení FК