Differences

This shows you the differences between two versions of the page.

--- statnice:vyvoj:otazka16 [06.05.2008 15:01] – xvalo07
+++ statnice:vyvoj:otazka16 [29.05.2008 23:07] (current) – normalizace databáze xvalo07
@@ Line 11: / Line 11: @@
   * Jak se vyrovnáte s uvedenými třemi úrovněmi?
   * Analyzujte faktory ovlivňující dobu odezvy, jak identifikovat slabé místo, databázové objekty ovlivňující výkonnost SŘBD, databázové optimalizéry, postup optimalizace dotazů, resp. fyzické struktury
+===== Teorie =====
+Tzv. princip tří architektur = P3A
+Vycházíme z konceptuální úrovně návrhu. Ta se vyznačuje tím, že je zcela nezávislá na konkrétním implementačním prostředí. Vychází z reality a modeluje ji tím, že vybírá podstatné entity a vztahy mezi nimi. Konceptuální návrh nesmí být nijak omezen z hlediska realizačního prostředí (realizačním prostředím se myslí souhrn konkrétních softwarových i hardwarových prostředků, ve kterých bude práce realizována, stejně jako další omezení z hlediska personálního, finančního, časového, atd.).
+Konceptuální návrh by měl být dokonale přenositelný mezi různými platformami, resp. neměl by jimi být nijak omezen. Je to výchozí bod pro realizaci změn a pro detailní pohledy. Záruka konzistence celého návrhu a jeho dokumentace.
+Dělí se na hrubý návrh – konceptuální schéma reality – pro pochopení reality a datovou strukturu – konceptuální schéma dat – přesný popis reality.
+Implementační úroveň – technologická – logická – určíme logickou podobu dat, jestli nějakou vlastní strukturu nebo SŘBD. Pokud SŘBD, relační model, navrhneme jednotlivé tabulky a vztahy mezi nimi, kardinalita, parcialita, atd. Implementační – fyzickou strukturu v tomto případě zajišťuje databáze. Pokud realizujeme sami, musíme příslušné datové struktury nějak ukládat a nějak s nimi manipulovat – vymyslet princip uložení na disk, atd.
+Všechny tyhle věci jsou dnes poměrně solidně podporovány automaticky, tozn. že ve většině případů např. nemusíme příliš řešit tu fyzickou architekturu – buď to dělá SŘBD nebo pokud programujeme v nějakém vyšším jazyce, jsou tam na to příslušné třídy (třeba Map v Javě, apod., které zajišťují i serializaci, atd.).
+I návrh se dá poměrně solidně automatizovat – dnešní CASE nástroje podporují psaní konceptuálního návrhu, dokáží v něm najít nekonzistence, vytvořit z něj návrh logické vrstvy, případné úpravy v jednom nebo druhém přenášet na druhou vrstvu a nabízí nástroje pro orientaci v modelovaném prostředí. V neposlední řadě dokáží vygenerovat přímo SQL kód pro vytvoření databáze. V tom případě se o vytvoření té fyzické vrstvy postará samo SŘBD.
+Použitelné techniky – zásadně oddělit konceptuální a implementační úroveň, vyvarovat se redundancí dat, chápat data jako centrální zdroj, ke kterému se bude paralelně přistupovat, navrhovat datovou základnu tak, aby byla v budoucnu rozšiřitelná, dosáhnout co největšího stupně datové nezávislosti.
+Také by šlo zmínit [[http://www.manualy.net/article.php?articleID=13|normalizaci databáze]].
+===== Praxe =====
+Principiálně vzato nemá objektově orientovaný přístup k programování s relačními principy návrhu databází problém. Entity a atributy lze v podstatě chápat i v podobě objektů. Všechna současná vývojová prostředí se s relačními databázemi vyrovnávají zdatně a některé (C#) mají solidní nástroje pro implementaci objektových přístupů do práce s daty (definování SELECT, atd. příkazů jakožto metod). Záleží na vnitřní reprezentaci dat – např. nasávání dat do objektů z relačních tabulek s tím, že v IS se s tím pracuje už jenom jako s objekty. Event. existují i objektové databáze s nevalným výkonem. Jejich výhoda je, že jejich logická reprezentace dat v podstatě odpovídá konceptuální struktuře, nicméně nemají takovou algoritmickou základnu.