Názory k článku
Modelování databází

Ackoliv mam z toho nekolik zkousek, tak furt nechapu, co je mysleno temi NF (tu 1. NF chapu, ale 2. a 3. uz ne) - muzete mi nekdo uvest nejaky priklad neceho, co neni a proc neni 2. NF a 3. NF? Moc d', Libor

skus pozriet http://fria.fri.utc.sk/~kmat/dbs/dbs.html
su to skripta o databazovych systemoch, kapitola 7 je venovana normalizacii datoveho modelu, urcite tam nieco vhodne najdes.

Příklad:
Místo rod. čísla bude dohromady klíčem datum narození, pohlaví a část za lomítkem (z toho se dá odvodit RČ). Pak když bude nějaký atribut záviset např. pouze na pohlaví, nesplňuje to 2. NF (závisí na podklíči, nikoli na celém klíči).

Jiný příklad:
Mějme např. databázi platebních příkazů, každý bude obsahovat mj. název banky a její číselný kód. Za předpokladu, že každá banka má přiřazen právě 1 kód, nebude splněna 3. NF (závislost na jiném atributu než klíči, jinak řečeno tranzitivní závislost na klíči).

V případě pochybností vysvětlí odborník na databáze ing. Halaška (halaska@fel.cvut.cz) nebo přímo náš databázový guru prof. Pokorný (pokorny@fel.cvut.cz, pokorny@mff.cuni.cz).

Mel jsem v rukou skripta od p.Pokorneho z CVUT a musim rict, ze to byla jedna z nejlepsich veci co jsem na dane tema videl. Dopurucuji k precteni kazdemu kdo chce prekrocit horizont "instatnich" clanku/manualu o SQL a zaroven nezkoncit u pouhe matematiky :-)

Omlouvam se za to, ze jsem v clanku neuvedl ukazky NF, snad nekdy priste.

Z mého (laického) pohledu jde vesměs o to, aby v datech nebyly žádné duplicity údajů.
Co myslel autor 2.NF si taky nejsem až tak jistý.
3.NF by podle toho jak to popisuje mělo být toto:
Když mám tabulku FIRMY a ZAMESTNANCI a do ZAMESTNANCI zapíšu na každý řádek nejen cizí klíč, který mi to propojuje do FIRMY, ale navíc ještě adresu firmy, pak to ve 3.NF NEBUDE. Když tam tu adresu (duplicitní údaj) neuvedu, ve 3.NF to BUDE. Nemusí to ale být jen takovéto surové opsání údaje duplicitně, ale i nějaká kalkulace - např. když v ZAMESTNANCI mám DatumNarozeni a do FIRMY bych si přidal pole (atribut) PrumernyVek, uz to NEBUDE ve 3.NF, protoze je to duplicitní informace k tomu ZAMESTNANCI.DatumNarozeni.
Autor zde vlastně popírá sám sebe (toto se traduje u naprosté většiny analytiků) tím, že píše: "vyhledáme klíčové atributy". Použití atributu (který něco reálně popisuje) jako klíče totiž porušuje 3.NF, tj. zavádí zbytečnou duplicitu. Kromě asi 5-ti dalších dobrých důvodů stačí už toto, abychom nikdy jako klíč nepoužívali reálný údaj, ale raději nějaké automaticky generované ID.

Parciální a tranzitivní závislosti jsou IMHO tak triviální věci, že nerozumět jim je snad skoro zločin. Vámi zmiňovaný příklad ZAMESTNANCI.DatumNarozeni vs. FIRMY.PrumernyVek je nesmysl, protože o tomhle 3.NF rozhodně není. Přečtěte si tu definici ještě jednou a pomalu! Já jsem si nevšiml, že by tam byla zmínka o větším počtu tabulek než jedna. Každá hraje, pokud jde o NF, sama za sebe. Apropos, průměrný věk je očividným kandidátem na COMPUTED sloupec nebo na zařazení do pracovního pohledu místo do tabulky. Takže to ani nemusí být perzistentní pole a klidně si může žít vlastním životem bez ohledu na nějaké normálové formy :) Chyb ve vašem příspěvku je mnoho, je jedna ráno a já nemám sílu je hledat...dost na tom, že tu dřepím, nadávám na hlásky Informixu, které si snad psali vývojáři sami a lokalizovat to po nich je práce pro vraha :/

Trochu nudny clanek, nic noveho se clovek nedovi. Treba ale dalsi clanek bude praktictejsi - co treba napsat neco o praci v nekterem free CASE systemu pod Linuxem nebo se je pokusit srovnat?

Pobavila me veta o programu pro vsechny - super ftipek.

Lidí, kteří se bezhlavě vrhli do praxe, je kolem spousta. Když pak vidím články typu "MySQL instantně za 20 minut" na některých webech (nebudu jmenovat Živě ;-), nestačím se většinou divit, jaké "návrhy databází" autoři vytvářejí.

Zdravime Daliho! :o)))
Mas pravdu, znam par OS projektu, ktere maji neudrzitelny datovy navrh a diky nemu i malou sanci na preziti. Coz je v nekterych pripadech dost skoda. :o(((

Specializuji se na optimalizaci MySQL a musím Vám dát za pravdu. Nějteří udělají takový prasácký návrh, že zatěžují databázi na 90% a nic jin0ho tam skoro nejede.

Statistik Hampel kdysi prohlásil něco jako:
"Není nic praktičtějšího, než dobrá teorie."
Naprosto s tím souhlasím a je to i jeden z důvodů, proč se mi srozumitelně napsané teoreticky orientované články na Rootu líbí. Vzhledem k tomu, že nemám žádnou teoretickou knihu o (relačních) databázích, jsem za každý článek tohoto typu docela rád.

Nemyslím. Pro laika popř. začátečníka je to dobrý a rychlý úvod do tvorby struktury db. Samozřejmě až praxe mu ukáže, co všechno je teorie a co se dá použít v produkčních systémech.
Ale faktem je, že takto má vypadat teoretický postup návrhu db. Ovšem výkon db železa, kdy je všechno provázáno klíči a na každém sloupečku jsou nějaká constraints je mimo dosah obyčejných smrtelníků.

Můj názor je ten, že když se udělá dobře základ db (koncept. návrh, tvorba tabulek, přidání integritních omezení atd.), odpadá spousta problémů v aplikacích nad touto db. Platí to zvlášť tehdy, když každou část dělá někdo jiný. Je proto nejlepší dát toho co nejvíc přímo do databáze a na aplikace nechat jen to, co se nedá řešit jinak.

Jistě. Ale už v okamžiku vytváření db architektury se musí vzít v potaz možnosti železa a db softu na kterém to pojede.
Např. na Oracle není problém s vyjížděním stromů a nemusí se k tomu psát žádná rekurze a otvírat mraky kurzorů.

a jak stromy?
ja to ted chci delat rekurivni procedurou.
jsem prave ve stadiu topeni se v referencni prirucce. a prechod mysql->oracle je fakt krize

Kouknete se do SQL-reference na prikaz SELECT ... START WITH ... CONNECT BY PRIOR ... Mozna pak nebudete rekurzivni proceduru potrebovat.

Jedine, co k tomu dodat, je - nepouzivat pro vetsi tabulky - pokud mate tabulku s cca stovkami zaznamu, je to v pohode ... pokud jsou zaznamu desetitisice, mohl by jste lehce narazit...

Nesouhlasim. Pouzival jsem to nad tabulkou s mnoha zaznamy (cca 100 tis.). Pokud jsou klice spravne oindexovane - neni problem.

Používám to i na tabulky s miliony záznamů a je to mnohem rychlejší než "ručně".

"Je proto nejlepší dát toho co nejvíc přímo do databáze a na aplikace nechat jen to, co se nedá řešit jinak."

Jak kdy. Souhlasim s autorem článku že podstatné je rozmyslet, jakou roli hraje databáze v architektuře aplikace a vytvořit dobře definované (transparentní) rozhraní mezi databázovou vrstvou a ostatními částmi (obecně mezi všemi částmi) aplikace.

Článek je myslím dobrým úvodnem do problematiky a může otevřít oči těm, kteří do toho skočili nabo spadli po hlavě. Opakování a shrnutí základních a osvědčených postupů není nikdy na škodu.

>> "Je proto nejlepší dát toho co nejvíc přímo do databáze a na aplikace nechat jen to, co se nedá řešit jinak."

Tohleto je dost diskutabilní. Jestliže do databáze bude psát 5 různých aplikací nebo 1 aplikace 10 různými způsoby, pak je to asi na místě. Účel ale NENÍ aby se to zajišťovalo zrovna v databázi, účel JE, aby se to zajišťovalo na jednom centrálním místě, které se nedá obejít. Jestliže vím, že žádná jiná aplikace nebude mít práva zápisu přímým přístupem do databáze (tj. obejitím níže popisované střední vrstvy), a jestliže mám objektově orientovanou aplikační logiku, kde např. rušení záznamu bude VŽDY zajišťovat jediná třída, pak je lepší integritu implementovat do této třídy - budu to totiž mít velice snadno přenositelné z jednoho datového stroje na druhý. Tím zůstaneme u otevřené architektury a nebudeme nuceni psát 3x stejný algoritmus ve 3 poněkud různých "skriptech" při používání 3 různých datových strojů u 3 zákazníků/uživatelů aplikace.

Jen by me zajimalo: prochazeni stromem nasledujicim SQL prikazem je specialita DB Oracle? Nebo jde o standard?
SELECT name, id, id_top
FROM tree
CONNECT BY PRIOR id = id_top --- vazba ve stromu
START WITH name = 'FIRST';

je to specialita oracle. imho se nejedna o nejake lepsi reseni, ale jen o zjednoduseni syntaxe... (nebo se pletu?)

Ne, neni to zjednoduseni syntaxe. Ani nevim, jak bych totez v SQL napsal jinak.

V nekterem materialu k Oracle jsem to videl trefne pojmenovane jako WALK TREE. Pokud je mi znamo tak jina DB nez Oracle tuto vlastnost primo na urovni SQL neimplementuje a ani standard nic takovaho neobsahuje. Ostatne SQL jako takove je nerekurzivni. Obavam ze, ze i to prochazeni strumu bude uvnitr Oracle implementovano jak mnoho selectu. Jine reseni mne moc nenapada, snad jen nejak specialne delane indexy, kere v sobe zahrnuji danou hierarchii. Jinak viz. docs k Oracle8:
Oracle uses the information from the above clause to form the hierarchy using the following steps:

1. Oracle selects the root row(s) of the hierarchy-those rows that satisfy the condition of the START WITH clause.
2. Oracle selects the child rows of each root row. Each child row must satisfy the condition of the CONNECT BY clause with respect to one of the root rows.
3. Oracle selects successive generations of child rows. Oracle first selects the children of the rows returned in step 2 , and then the children of those children, and so on. Oracle always selects children by evaluating the CONNECT BY condition with respect to a current parent row.
4. If the query contains a WHERE clause, Oracle eliminates all rows from the hierarchy that do not satisfy the condition of the WHERE clause. Oracle evaluates this condition for each row individually, rather than removing all the children of a row that does not satisfy the condition.

http://techdocs.postgresql.org/college/002_referentialintegrity/index.php ... tady je dobry kurz, sice pro PosgreSQL, ale analogicky to funguje i jinde.

Děkuji moc za výše zmíněný odkaz. Jsem jedním z těch, kteří se vrhli rovnou do praxe, a proto tento článek a tento kurz měly pro mě vysokou informační hodnotu!

A co takto ErWin ? To ste o nom ani nepocul alebo ho nespominate zamerne ?! Rozne obskurne sw Vas projekt nezachrania , je nutna aj kvalitna podpora fyzickych charakteristik . Napr TABLESPACE a pod ...

Pisete, ze meno tabulky ma byt v jednotnom cisle. Urcite to ma nejaku pricinu, preto by som Vam bol vdacny keby ste mi ju prezradili. Dakujem.

Existují tři různé názorové proudy. Jeden tvrdí, že se má používat jednotné číslo pro databázové entity a množné číslo pro vztahy mezi nimi (to prosazují hlavně ti, kteří všechno nejdřív modelují E-R modelem; po převodu do SQL se vztahové tabulky liší tím, že obsahují cizí klíče). Další názor dva názory tvrdí, že názvy tabulek mají být vždy v jednotném (množném) čísle. Odůvodňuje se to především konzistencí (oba způsoby) a každý zvlášť má i svoje vlastní argumenty. Těžko říct, co je vlastně nejlepší.

Vazeni, slibuji odmenu (slovni pochvala, atp...) kazdemu, kdo mi vysvetli, co je na databazich za vedu. Mluvili jste tu o nejake teorii, me to vsak pripada vsechno kolem databazi se da resit "zdravym selskym rozumem". Nemam ted na mysli implementaci databazovych stroju. Mluvim o navrhu relacni databaze. Nepamatuju se ze skoly, ze by se v databazich pouzivala nejaka algebra. Mluvilo se tam o normalnich formach, to je pravda, ale to snad trkne kazdeho, ze v databazi ma byt co nejmene redundantnich informaci. Druha vec je navrhnout databazi a SQL dotazy tak, aby byly co nejefektivnejsi. Jenomze to uz je zavisle na tom kterem konkretnim db stroji. Prosim, pomozte mi. Mam pocit, ze mi v DB ujel vlak. Co je na tech databazich za vedu ???

Dejme tomu, že na formulářích potřebujete obvykle zobrazovat 1 záznam z nějaké základní tabulky, dále související záznamy z několika 1:m tabulek a pak ještě záznamy z m:1 tabulek. Pak si řeknete: Fajn, napíšu si pro to jedinou obecnou třídu, která mi tuto podporu bude zajišťovat ve všech formulářích mé aplikace, resp. dokonce ve všech mých aplikacích. Pak zjistíte:
1) že to je podstatně větší věda, než byste si myslel, a že skutečně potřebujete dobrý teoretický aparát, který vám pokryje všechny varianty datového modelu,
2) že většina současných analytických teorií jde trochu mimo reál a zmíněný potřebný teoretický aparát vám neposkytne,
3) že přijaté různé standardy (např. SQL) jsou rovněž poněkud mimo potřeby reálného světa a praktickou realizaci takové třídy neuvěřitelně zkomplikují.

Normovanie je pekna vec, ale v praxi sa velmi casto prave z vykonnostnych dovodov musia porusit. Myslim pravdaze vacsie objemy dat.

Jenom drobná připomínka - celá tabulka není entita, ale entitní typ. Entita je jeden záznam (řádek) tabulky - entitního typu :-)

Jen by me zajimalo k cemu to je.

Gratuluji. O DB jsem toho četl hodně, ale tento článek je nejlepší. Stručný a přehledný, avšak přesně postihující nejdůležitější věci, na co by měl programátor u návrhu DB dávat pozor.

http://www.dwbicc.cz

Prosim mam ukol do skoly,s databazema sem nikdy nic nedelal ani nepracoval nevim o nich vubec nic.Nevite nedko nejaky dobry odkaz ktery by mel navedl a ukazal jak podle nej vytvorit tuhle ulohu:

Vytvořte datový model realizující Telefonní seznam.

Požadavky: Seznam osob i firem, možnost více čísel (též rozlišovat typ) pro jeden subject. Možnost vyhledávat subjekt dle zaměření (např. Truhláři, ....)

Datový model nechť je navržen ve 3. normální formě .

Diky moc za jakkekoliv info.
David

Ahoj, projíždim web a hledám návod na muj domácí úkol.
A koukám že máme stejný úkol na datové modelování:) Jelikož o tom taky nic nevim a nikdy jsem s tím nepracoval, tak sem se chtěl jenom zeptat, jestli jsi nějak pokročil a přišel jak na to. Budu rád za každou pomoc. Předem moc děkuji. Karel.
Muj email: jumper"zavináč"seznam.cz

Tohle je strašný článek. Za takovýhle blábol bych se skutečně styděl. Autor by se měl nad sebou zamyslet a přečíst si nějaký kvalitní článek o SQL, aby to mohl příště lépe opsat.