Aplikační a programové vybavení Databáze (obecně)

Pojmy data – údaje získané pozorováním, měřením informace – interpretace dat a vztahů mezi nimi (data, která snižují míru entropie) databáze / báze dat (DB) – obecná struktura pro uchovávání dat systém řízení báze dat (SŘBD) – programové prostředky pro správu dat v databázi databázový systém (DBS) – databáze a systém řízení báze dat rozhraní – prostředky k propojení systémů Pojmy databáze a databázový systém se v praxi často zaměňují, např. databázová aplikace pracuje s databázovým serverem a nikoliv s databází. Je to proto, že žádná aplikace která pracuje s databázovým serverem nemůže přímo přistupovat k databázi (musí vždy využívat systém řízení báze dat). Z toho automaticky vyplývá že aplikace která pracuje s databází musí ve skutečnosti pracovat s databázovým serverem. Entropie je (z pohledu teorie informace) míra neurčitosti systému. Příklad: pokud si přečteme sdělení „Květoslav se oženil“, tak jsme snížili míru neurčitosti systému Květoslav, protože nyní víme, že je ženatý (předtím jsme nevěděli nic), přesto však zůstává množství dalších neurčitostí (nevíme s kým, nevíme kde bydlí, atd...). Pokud si dále přečteme sdělení „Květoslav se oženil s Růženou“, tak dále snížíme neurčitost systému. Pokud bychom si sdělení přečetli v opačném pořadí (nejprve tedy „‘Květoslav se oženil s Růženou“), tak by se neurčitost snížila na stejnou úroveň, nicméně sdělení „Květoslav se oženil“ by neurčitost nijak nesnížilo, protože veškerá informace je již obsažena v prvním sdělení. Opakovaná data tedy nenesou žádnou informaci, současně například slovní spojení „nová informace“ je nesmyslné, informace je vždy nová a pokud není, tak to není informace.

Hromadné zpracování dat Cílem HZD je získat z dat informace. Nejvíce aplikací pro hromadné zpracování dat tvoří informační systémy: podnikové IS specializované (speciální) IS Podnikový informační systém je tvořen množstvím agend (např: sklad, účetnictví, mzdy, výroba, evidence docházky). Specializovaný IS je úzce zaměřený na konkrétní činnost. Ve starší terminologii se informačními systémy nazývaly pouze podnikové informační systémy. Specializované informační systémy se nazývaly agendy a postupně byly integrovány do podnikového informačního systému. Často se ale stává, že se určitá agenda rozroste do rozměrů informačního systému, proto se používá označení „specializované IS“.

Hromadné zpracování dat - agendy Často bývá spojená datová a aplikační vrstva. Informační systém je tvořen souborem nezávislých programů – agend. IS je tvořen souborem několika specializovaných ISů. Formát a struktura dat jsou definované potřebami každé agendy. problémy: závislost dat a programu (agendy) nekompatibilita a izolovanost redundance a nekonzistence Závislost dat a programu znamená, že data jsou zpracovatelná pouze jednou určitou agendou (tou, která data pořídila), to je velký problém při propojování agend do informačního systému. Pokud jedna agenda je například kartotéka zákazníků a druhá agenda je účetnictví, je nutné je nějak propojit, protože musí sdílet data o adresách zákazníků (fakturační adresa, dodací adresa), které jsou zaznamenávány prostřednictvím kartotéky. Ze závislosti dat a programu tedy přímo vyplývá nekompatibilita a izolovanost dat. Často se pak tento problém řeší duplikováním dat, tedy např. adresa zákazníka je jednou zadána do kartotéky a podruhé do účetnictví jako fakturační adresa. Vznikají tak redundantní (nadbytečná) data. Redundantní data s sebou přináší nebezpečí nekonizstence (rozporný stav), tedy stavu ve kterém jedna část dat poskytuje jinou informaci než jiná část dat. Například: v kartotéce je jako fakturační adresa uloženo „Zemědělská 1, Brno“ a v účetnictví je uloženo „Blahoslavova 5, Praha“. Nekonzistence vzniká neúplnou aktualizací redundantních dat, typickým příkladem je změna osobních údajů (bydliště, jméno, stav, číslo OP.), tu je zpravidla nutné nahlásit na desítkách míst (matrika, pojišťovna, banka, škola, zaměstnavatel, ...). Redundace dat je tedy velmi nebezpečná při skladování informací, je však velice výhodná při skladování dat (zálohování, distribuované systémy).

Hromadné zpracování dat - agendy izolovanost a nekompatibilita dat – datový formát definuje aplikace, jiná aplikace nemůže data využívat redundance (nadbytečnost) – jedny údaje jsou uloženy na několika místech nekonzistence (rozpory) – vzniká při neúplné aktualizaci redundantních dat špatné možnosti zabezpečení dat pro neplánované dotazy je potřeba nová aplikace problém zajištění integrity dat V agendovém systému dochází může snadno dojít k narušení zabezpečení, protože je systém nucen sdílet data s jiným (značně nezávislým) systémem. Je potřeba buď sdílet i uživatele i přístupová práva (což je při nekompatibilních datových formátech velmi komplikované), nebo je nutné přístupová práva obcházet, což je velmi nebezpečné. Ze stejného důvodu je problém i zajištění integrity dat.

Integrita dat integrita (celistvost) – stav databáze, ve kterém jsou všechna data úplná a korektní příklady: věk je kladné číslo každý člověk má věk (pole věk nesmí být prázdné) každý občan ČR má trvalé bydliště k porušení integrity může dojít: špatným ošetřením vstupních dat chybnou definicí databáze (chybou aplikace) chybou databázového serveru Nejčastější chyba je špatné ošetření vstupních dat. Integrita je důležitá pro správný chod aplikace (zkuste spočítat průměrný věk osob, pokud nějaká osoba má zadaný záporný věk). Zajištění integrity dat je jeden z nejzdlouhavějších úkolů při vývoji aplikace.

Hromadné zpracování dat - agendy Důvody použití: Historie – nerozvinuté prostředky pro databázové systémy Paralelní vývoj více aplikací a nerozvinutá systémová integrace: Různé aplikace v průběhu vývoje mohou začít požadovat stejná data Sloučení společností s různými informačními systémy Jednodušší počáteční vývoj, mělo by se ale počítat s budoucí integrací

Hromadné zpracování dat - databáze Často jsou spojené s třívrstvou architekturou. Data jsou uložena a spravována centrálně. Datové soubory mají jednotnou vnitřní strukturu, skrytou vnějším aplikacím. K datům je možno přistupovat jen prostřednictvím rozhraní databázového systému (SŘBD). Je vyřešen současný přístup více klientů, oprávnění, integrita dat atd. Operace v DBS jsou optimalizované, mají malou časovou složitost. Databázový systém se stará o spoustu věcí sám a mnohem lépe než jakákoliv aplikace, která se rozhodne DB systém nepoužívat. (Pokud nevěříte, zkuste si napsat aplikaci která dělá totéž co libovolná aplikace s použitím souborů a operací open, seek, write, close a se zachováním stejné časové složitosti)

Datový model soubor prostředků k modelování a popisu dat výstupem je databázové schéma – deklarace databáze (šablona databáze) různé prostředky: funkce množiny grafy relace objekty Databáze je něco, do čeho se dají uložit data. Databázové schéma je popis struktury databáze. Grafy jsou grafy z teorie grafů, tedy struktury skládající se z uzlů a hran. Analogie je kartotéka

Hierarchický model Data jsou organizována ve stromových strukturách. Mezi záznamy je pouze vztah rodič-potomek: potomek má jednoho rodiče rodič může mít více potomků Pro databáze není příliš výhodné a obecně se nepoužívá. Speciální využití: DNS, LDAP Souborové systémy XML Hierarchický model je přístup, který se dnes používá opravdu jen ve speciálních aplikacích, nicméně databázové systémy vzniklé před rozšířením relačního modelu jsou nejčastěji postavené právě jako hierarchické, mezi dodnes používané patří systémy MUMPS a Caché. . cz com mendelu seznam

Síťový model Vznikl rozšířením hierarchického modelu. Každá datová položka (uzel) může být propojena a libovolným počtem jiných položek. Umožňuje vazby 1:N, N:M i cyklické vazby. Jedná se spíš o koncept, který již není příliš funkční: univerzální a velice flexibilní těžko popsatelný a implementovatelný Někdy je mezi síťové modely zařazován HTML DOM (Document Object Model) Síťový model je koncept, ke kterému se IT a teorie grafů v pravidelných cyklech vrací. Je to velice lákavá struktura s množstvím možností, nicméně je obecně velmi těžko implementovatelná a celkově těžko uchopitelná, takže se zatím nijak výrazně neprosazuje.

Relační model popis dat pomocí relací (tabulek) navržen v roce 1970 (E. F. Codd, v rámci projektu IBM) je postaven na matematickém aparátu - relační algebře využívá standardizovaný dotazovací jazyk SQL velmi rozšířený: Adaptive Server Enterprise (Sybase) DB2 (IBM) Firebird MySQL Oracle Database PostgreSQL SQL Server (Microsoft) Relační databázové systémy jsou dnes nejrozšířenější, je to „prošlapaná cesta“. Je také velmi pravděpodobné, že se ještě několik let intenzivně používat budou.

Objektově relační model kombinace relačního a objektového modelu: dotazovací jazyk SQL nebo jiný relační implementace struktury modelování dat pomocí objektů zapouzdření hierarchie tříd rychlejší dobře podporuje vícehodnotové atributy místo záznamů se pracuje s instancemi objektů existují i čistě objektové databáze není zatím úplně rozšířené Proč není databázový objektový model rozšířený? chybí teorie, která by zaručovala, že to bude fungovat, případně definovala podmínky, za jakých to bude fungovat objektový databázový systém je mnohem složitější než relační databázový systém potíže se standardizací relační databázové systémy se vyvíjí přes 30 let a stále se intenzivně vyvíjí, mají tedy velký náskok

Relace – definice Množina n-tic ve tvaru (a1, a2, a3, ..., an) ai – hodnota atributu v dané n-tici, ai in Di Di – doména atributu (množina hodnot, kterých může atribut nabývat) Ai – jméno i-tého atributu (textový řetězec) Příklad: OSOBA(RČ: STRING, VĚK: INTEGER, JMÉNO: STRING) klíč atribut je podtržen domény není povinné uvádět Z toho, že je relace množina vyplývá, že muže obsahovat každý prvek pouze jednou (všimněte si, že tento požadavek se bude dále mnohokrát opakovat při definici tabulky). Relační algebra je teoretickým základem relačních databázových systémů, takže ji nesmíme opomenout, nicméně podrobnostmi se zabývají předměty Databázové systémy a Databázové systémy II.

Relace Na chvíli budeme předpokládat, že platí: relace – tabulka schéma / relační schéma – jméno a záhlaví tabulek (definice tabulek) pojmy relace, schéma a tabulka jsou v praxi často zaměňovány, ale neznamenají totéž prvek relace – řádek tabulky atribut – sloupec tabulky doména atributu – datový typ sloupce tabulky příklad: OSOBA(RČ: STRING, VĚK: INTEGER, JMÉNO: STRING) OSOBA(RČ, VĚK, JMÉNO) Pro začátek si je možné představit, že relace je nějaká tabulka, je to určité zjednodušení jak bude později patrné z vlastností relace.

Relační algebra popis datových struktur pomocí matematické logiky úsporný, jednoduchý a ověřený koncept umožňuje pracovat s daty (tabulkami) před vytvořením programu postavený na množinových operacích součin, sjednocení, průnik, rozdíl, … základ pro dotazovací jazyk SQL

Relační algebra – operace standardní množinové operace: kompatibilní sloupce: sjednocení (union) rozdíl (difference) průnik (intersection) kartézský součin (Cartesian product) speciální operace projekce (projection) selekce (selection) / restrikce (restriction) Θ-spojení (Θ-join) přirozené spojení (natural join)

Relační algebra – množinové operace Barva Vzhled bílá tučně zelená kurzívou červená podtržené růžová KAPITÁLKY Barva Vzhled bílá tučně zelená kurzívou červená podtržené Barva Vzhled růžová KAPITÁLKY zelená kurzívou Barva Vzhled bílá tučně červená podtržené Barva Vzhled zelená kurzívou

Relační algebra – operace Barva Vzhled bílá tučně zelená kurzívou červená podtržené Barva bílá zelená červená Barva Vzhled bílá tučně zelená kurzívou červená podtržené Barva Vzhled růžová KAPITÁLKY zelená kurzívou Barva Vzhled bílá tučně červená podtržené R1[Barva, Vzhled] je projekce R1[(Barva = Bílá)] je selekce Projekce je omezení počtu sloupců, selekce je omezení počtu řádků. Vzhled kurzívou

Relační algebra – operace Barva1 Vzhled zelená tučně kurzívou červená podtržené Barva2 Velikost Písmo růžová 17 Arial červená 24 Times zelená 20 Courier Barva1 Vzhled Barva2 Velikost Písmo zelená tučně 20 Courier kurzívou červená podtržené 24 Times theta join – podmnožina kartézského součinu zadaná podmínkou natural join – stejné jako theta join, ale podmínka je na stejně pojmenovaných sloupcích Písmo Times

http://kantorek.webzdarma.cz/

Klíč Definice relace vyžaduje jednoznačnou identifikaci. Klíč je minimální množina vlastností, které jednoznačně identifikují každou entitu. Příklad – identifikace osoby: jméno + příjmení + datum narození (složený klíč) rodné číslo (jednoduchý klíč) číslo osoby (jednoduchý klíč) Obecně je nejbezpečnější využívat umělé (dumb) atributy, i když to představuje více práce. Klíč je nejzákladnější integritní omezení – tj. každá relace musí mít klíč. „Klíč je minimální množina...“ je potřeba chápat tak, že klíč obsahuje co nejmenší počet sloupců, které ještě stačí k jednoznačné identifikaci každé entity (tedy každého řádku tabulky), neboli klíč nesmí obsahovat zbytečné sloupce. Umělé atributy se používají zpravidla ke zjednodušení práce s relací, zejména pokud je přirozený klíč složený z více sloupců (jméno + příjmení + rodné číslo). Je potřeba myslet na to, že jakákoliv aplikace je jen modelem reality, nikoliv realitou. Tedy je vždy neúplná a nepřesná. Z toho vyplývá, že klíč je má být jednoznačný identifikátor v rámci potřeb aplikace, nejedená se o nějaký univerzální identifikátor. Často tedy jako klíč může stačit kombinace jméno a příjmení nebo e-mail nebo telefonní číslo apod. Pokusy o univerzální klíč jsou předem odsouzeny k neúspěchu (některé věci jdou přímo proti sobě – například univerzalita a rychlost nebo bezpečnost a komfort ovládání nebo univerzalita a spolehlivost atd...). Výraz „Slabý entitní typ“ označuje takové relace u nichž je klíč tvořen pouze nevlastními atributy (tj. atributy získanými z jiných relací), příkladem jsou záznamy v propojovacích tabulkách M:N relací.

Klíč Klíčů může být v tabulce více: OSOBY(ID, RČ, JMÉNO, PŘÍJMENÍ, ČOP) Jeden z klíčů označíme jako primární. Volba primárního klíče není důležitá z hlediska analýzy, ale z hlediska implementace. primární klíč by měl být co nejmenší (z hlediska ukládání) hodnoty primárního klíče by měly být snadno porovnatelné nejvhodnější volbou je jeden atribut typu integer nejvýhodnější pro stroje, lidé s databázemi nepracují Prakticky se jako primární klíč se tedy nejčastěji používá nějaké ID, což je jednoznačný identifikátor, který každému záznamu v tabulce přiřadí databázový systém. Je důležité si ale uvědomit, že je to klíč umělý, tabulka by tedy měla vždy obsahovat ještě minimálně jeden klíč přirozený. Příklad: Databáze zaměstnanců obsahuje sloupce jméno a příjmení. Jméno a příjmení není jednoznačná identifikace osoby, je tedy potřeba buď přidat sloupce (rodné číslo), nebo zavést logickou identifikaci osob (zaměstnanecké číslo), to vše je potřeba bez ohledu na to jestli databáze obsahuje umělý automaticky generovaný primární klíč, nebo nikoliv. Je potřeba myslet na to, že umělý klíč slouží pouze pro vnitřní potřebu systému a nikoliv pro uživatele (hodnotu nesmí změnit a ani by ji neměl číst, naproti tomu zaměstnanecké číslo je možné změnit). Výjimkou mohou být speciální databáze, například databáze výsledků anonymního hlasování, nebo databáze přístupů, ty z podstaty věci neobsahují přirozený primární klíč a je nutné vždy doplnit klíč umělý, aby bylo možné vytvořit relaci.

Cizí klíč referenční integritní omezení (foreign key) atribut jedné relace (R2), který je označen jako cizí klíč, musí mít: prázdnou hodnotu hodnotu primárního klíče jiné relace (R1) R1 – hlavní relace (master, parent) R2 – vedlejší relace (detail, dependent) Příklad: VZTAHY(ID_VZTAHY, ID_OSOBY1, ID_OSOBY2, DATUM) ID_OSOBY1 a ID_OSOBY2 jsou cizí klíče Cizí klíč v přikladu říká, že vztah může existovat jen mezi dvěma existujícími (v databázi) osobami. Tedy že ID osoby ve vztahu nemůže být vmyšlené libovolné, ale musí to být odkaz na konkrétní záznam v tabulce osob. Cizí klíč vždy zahrnuje dvě relace, ale je vždy definován jen v jedné, tedy jedna relace se odkazuje na druhou.

http://kantorek.webzdarma.cz/