Starší komentáře ke článku: Databáze a jazyk SQL
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 22.8.2000 11:45:00
Myslim, ze je to supr clanek.
Datum vložení: 25.7.2002 8:36:49
Je dobrý, že tento seriál existuje, ale mám v tom trochu zmatek...
Datum vložení: 27.6.2004 15:17:48
Dekuji autorovi za skvele zpracovany clanek.
Strucne, snadno pochopitelne a vystizne.
Datum vložení: 27.9.2004 13:30:45
Toto je studnice moudrosti.
Datum vložení: 6.6.2005 8:32:53
tak tenhle článek je pro pochopení mnohem lepší než pdfka ze školy - za chvíli jdu na zkoušku, a z tohodle sem si to výborně ujasnil - díky:)
Datum vložení: 18.6.2005 15:49:22
Obávám se, že autor se sám popírá, když tvrdí, že vzorová tabulka pro odstavec o 3NF není ve 2NF. V této tabulce je přece primárním klíčem číslo zaměstnance a to je jeden sloupeček. Podle tvrzení autora by ale tabulka měla být ve 2NF triviálně. Takže buď 2NF se netýká jen vícesloupcových primárních klíčů, nebo tabulka v příkladu na 3NF už ve 2NF být musí. Prakticky totéž platí o tabulce použité v odstavci o 2NF. Takže tak jako tak, nalézám tu spor.
Datum vložení: 7.7.2005 14:36:58
Zminovana tabulka neni ve 2NF, nebot atr. plat neni zavisly na cislu pracovnika, nybrz na vykonavane funkci => plat je zavisly pouze na casti primarniho klice, kterym by byla zrejme dvojice (cislo,funkce), tj. na atr. funkce.
Datum vložení: 18.5.2006 18:29:50
primarni klic se dvojici (cislo, funkce) je semanticky nesmysl... vam by nevadilo mit v databazi podobne udaje? Protoze presne to by primarni klic s tou dvojici dovolil. CISLO JMENO FUNKCE 1 Petr Vomacka technik 2 Tomas Novak opravar 2 Pepa Novak technik ...
Datum vložení: 12.6.2006 13:43:41
Souhlas, taky mne ten priklad v clanku zarazil. Podle mne je tato tabulka s klicem "cislo" cokoli jineho mi pripada pochybne. Navic vetsina lidi pracuje za smluvni plat. A i kdyby to bylo podle tabulek, tak asi bude jinak ohodnocen technik s mat a praxi a jinak technik zrovna z ucnaku... Jinak dekuji za tuto serii, snazim se vyresit nejaky problem a tady vidim alespon svetlo na konci tunelu (bezne s SQL nepracuji)
Datum vložení: 14.9.2005 11:53:34
Naprosto perfektni prehled pro zacatecniky a mirne pokrocile. A navic [b]CESKY[/b]!!!
Datum vložení: 9.2.2006 19:54:28
Bezva, skvely prehled...
Datum vložení: 25.4.2006 9:47:48
Chtel bych autorovi velmi podekovat za clanky o SQL. Jen mne mrzi, ze tento serial skoncil, protoze si myslim, ze byl velice dobry pro zacatecniky a mohl postupne projit az ke slozitejsim vecem tykajicich se SQL. Je to opravdu velika skoda, ze serial dal nepokracuje, presto jeste jednou diky moc.
Datum vložení: 6.5.2006 15:32:28
Článek je to rozhodně pěkný, jeneom bych rád doplnil, že BCNF není poslední normální formou. BCNF bývá často považována jenom za doplnění 3.NF. Kromě toho eistuje ještě 4.NF a 5.NF. Nicméně pro začátečníka jsou nepodstatně, protože proto, aby byly porošeny, musel by dotyčný navrhovat poměrně rozsáhlou DB s velmi složitýmy vztahy a ještě k tomu poněkud zajímavými způsoby, protože při použití zdravého rozumu a zásad pro návrh DB se prakticky nemůže stát, že by jsme zásady těchto NF porušily.
Datum vložení: 18.5.2006 18:27:19
4NF urcuje, ze zadny atribut nesmi byt nepovinny -- to se naopak porusuje velmi lehce a taky se ani moc nedodrzuje, protoze neprinasi velky prinos a hodne ztezuje navrh. Jen doplnim, ze definice vyssich NF (4,5) se obcas hodne lisi, takze klidne muzete narazit na jinou.
Datum vložení: 6.5.2007 1:48:18
Tak už jsem jich pár viděl, ale tuhle teda ještě ne. A dovolím si tvrdit, že je to nesmysl, neboť 4.NF řeší multizávislosti a to v relacích s klíčem složeným z minimálně tří atributů.
Datum vložení: 22.8.2006 10:18:19
Presne neco takoveho jsem na netu hledal. Klasicke vysvetleni definic, kterym sem nerozumel. :-)
Datum vložení: 14.2.2007 21:00:11
Souhlasim se vsemi je to nejlepsi co jsem zatim cetl.
Datum vložení: 9.8.2007 13:01:15
Dekuji autorovi za uzasne zpracovany a uceleny prehled. Velmi mi pomohl pri praci s SQL :o)
Datum vložení: 13.2.2008 11:24:59
Drazi studenti a ctenari tohoto clanku! Tento clanek obsahuje zavazne chyby z pohledu teorie relacnich databzi a to predevsim v definici 2. NF. Zde uvadeny priklad neni vhodne zvolen. Davejte si DOBRY pozor na informace z internetu, nemusi byt vzdy spravne a pravdive!
Datum vložení: 13.2.2008 13:43:40
Vážení studenti a čtenáři, pan magistr Prokýšek má pravdu. Dávejte si opravdu DOBRÝ pozor na informace z internetu. A přiznejte se, který z vás, vtipálků, se tady vydává za pana Prokýška? ^-^
Datum vložení: 19.2.2008 12:56:37
Abych doplnil svuj predchozi prispevek, tak pridavam informace k te 2NF. Takze, definice 2NF je ve clanku napsana dobre. Problem je s vysvetlenim a prikladem. Pokud budeme operovat s pojmem 'funkcni zavislost', pak to znamena, ze na zaklade daneho klice muzeme jednoznacne urcit hodnotu zavisleho atributu (X -> Y), tzn. ze kdyz vim CISLO pracovnika, tak ho jednoznacne timto klicem identifikuji a mohu rici jak se napriklad jmenuje (CISLO->JMENO). Z toho ale rovnez plyne, ze muzu urcit jednoznacne i cislo a nazev pracoviste, kde pracuje. Takze zde existuje fcni zavislost CISLO->CIS_PRAC, NAZEV_PRAC. Jelikoz je v tomto pripade klic tvoren pouze jednim atributem, tak se jedna rovnez o plnou funkcni zavislost (tj. z klice nemuzeme odebrat zadny atribut, takovy, ze pri jeho odebrani zustane zachovana funkcni zavislost). Je tedy jasne, ze ukazkova tabulka v tomto clanku SPLNUJE 2NF! Neco jineho by bylo, kdyby ukazkovy priklad obsahoval atribut (sloupec), ktery by byl zavisly na CISLO i CIS_PRAC. Takovy si ale nejak nedokazu predstavit. Neco jineho by byl takovyto priklad: CISLO, JMENO, PRIJMENI, PROJEKT, NAZEV, HODINY Zde je atribut HODINY, ktery vynucuje pouziti primarniho klice {CISLO, PROJEKT}. HODINY zde predstavuji pocet hodin odpracovanych pracovnikem na nejakem projektu. Pak zde mame celou radu castecne zavislych atributu (napr. plati CISLO->JMENO). Vysledek je pak asi jasny: CISLO, JMENO, PRIJMENI PROJEKT, NAZEV CISLO, PROJEKT, HODINY Priklad, ktery je v clanku uvaden je perfektni, ale jako ukazka pro 3NF, kde CIS_PRAC je atribut, pres ktery je NAZEV tranzitivne zavisly na CISLO. Takze tak. Ve strucnosti :-) Nebo ma autor clanku jiny nazor?
Datum vložení: 19.2.2008 14:39:42
Osm let po napsání článku už názor autora zjistíme jen těžko, ovšem redakce Intervalu se snaží i starší články udržovat a upravovat. Pokud je připomínka menšího rozsahu, stačí poznámka v diskusi, pokud jde o něco rozsáhlejšího (jako v tomto případě), je možno nám napsat na redakční e-mail a my můžeme poskytnout potřebný prostor pro úpravy, rozšíření nebo dodatky ;-)
Datum vložení: 21.2.2008 9:19:36
Dobrý den, jsem autorem tohoto článku a dovolím si tedy jako autor reagovat. Musím připustit, že článek, napsaný před téměř 8 lety může dnes působit zastaralým dojmem. Pan Prokýšek poukazuje na to, že vysvětlení a příklad pro 2NF není vhodné. Popravdě řečeno, snažil jsem se tehdy o co největší zjednodušení i za cenu ztráty přesnosti i dalších detailů. Tehdy mi příklad, který nesplňuje 2NF ani zároveň 3NF, přišel jako dobrý nápad. Psal jsem tento článek jako nadšený student VŠ, který se snažil na velmi omezeném prostoru ([i]uznejte, že 1 článek v rozsahu asi 5 stran těžko může v detailnosti a úplnosti nahradit odborné přednášky absolvované celé 2 semestry a praxi též[/i]) vyplnit jednu zásadní mezeru v článcích o relačních databázích na českém internetu pro laickou veřejnost. Tehdy problém byl v tom, že "populárně-naučných" článků o relačních databázích bylo velmi málo a ty, které byly k dispozici, nebyly úplně šťastně pojaté (aspoň jsem si to tehdy myslel). Seriál o databázích na jiném portálu začínal například ukázkovým prvním příkladem typu "SELECT * FROM neco...", jako by obdoba známého klišé z výuky libovolného programovacího jazyka "Hello World". Problematika byla vysvětlována zprostředka a nikde nezazněly takové věci, jakože existují nějaká pravidla pro návrh databáze, a o zásadních pojmech jako primární a cizí klíč ani zmínka a když, tak velmi okrajově. Žádnou pasáž článku jsem odnikud neopsal (ono ani té dobré literatury příliš mnoho nebylo). Vycházel jsem z vlastních vědomostí a zkušeností, které jsem získal během studií aktivní účastí na přednáškách a účastí na databázových konferencích. Je jasné, že kdybych na zkoušce z DBS přišel s vědomostmi pouze v rozsahu tohoto článku, bylo by to málo. Opakuji, že tento článek je určen pro laickou, neodbornou, veřejnost. I přesto, že tento článek je už spíše stařečkem (návrh na přesun do nové kategorie "Muzeum"? :-), stále si myslím, že skupině lidí, pro kterou je/byl určen, má co říct. Souhlasím, aby některý z odborných redaktorů Interval.cz provedl aktualizaci tohoto článku, s tím, že bude v aktualizovaném článku uvedeno, že jde o update tohoto článku s uvedením odkazu na původní, originální, znění článku. S pozdravem Jaromír Skřivan
Datum vložení: 6.3.2008 12:34:37
Pane Skřivane! Doufám, že jsem se nějak nedotkl Vás osobně. To ani zdaleka nebylo motivem, který mě vedl k napsání mého příspěvku do diskuze. Už to, že Váš článek má stále co říci, je důkazem, že jste svou práci před 8 lety odvedl dobře. Hlavním motivem mého příspěvku bylo upřesnění tohoto článku, protože z něj čerpají moji studenti při přípravě na zkoušku... Miloš Prokýšek
Datum vložení: 22.4.2008 0:52:16
Dobrý den, osobně si myslím, že dnes již existuje mnoho případů, kdy normalizace věc spíše komplikuje. Například si představme situaci, kdy máme tabulku PracovniSkupina a tabulku Pracovnici. Pracovních skupin může být mnoho a Pracovníků také. Podle normalizace bychom měli vytvořit tabulku Role, která definuje vztah který Pracovnik je ve které PracovniSkupina. To je velmi hezké, ale často budeme dělat dotazy přes dva JOINY. To databázi u velkých tabulek dost zatíží. Mnohem efektivnější je uložit např. seznam Pracovníků, kteří spadají do PracovniSkupina do tabulky PracovniSkupina do pole BLOB, např. odděleno tabulátorem a zaindexovat to. Není to normalizované, ale u velkých tabulek určitě rychlejší.
Datum vložení: 8.11.2008 19:56:20
Dovolim si nesouhlasit - normalizace na uroven minimalne 3NF je NUTNOSTI, hlavne z hlediska tvurce systemu. Nenormalizovane schema se HODNE tezko dotazuje. K Vasemu prikladu: Definujme si velkou tabulku. Ve sve praxi programatora ERP systemu (SAP) jsem se setkal jednou jedinkrat s malinko vetsi tabulkou - jedna se o tabulku polozek ucetnich dokladu (cca 100 atributu), ktera mela u jednoho zakaznika cca 10M radku (a stale roste). Tento rozsah musel byt resen specificky i v systemu. Tabulku pracovniku a pracovnich skupin by bylo zverstvo resit jakkoliv jinak nez pres relaci Pracovnik - je_v - Skupina, uz jen proto, ze byste musel byt galakticke imperium, aby se Vam podarilo mit dostatek zamestnancu a skupin na poradne velkou tabulku. Nejvetsi by byla tabulka s relaci, ovsem ta by obsahovala pouze cisla (pripadne historii - datumy), tzn. indexace by vyhledavani dost urychlila. Dva JOINy v tomto pripade dle meho nazoru na veci nic nemeni.
Datum vložení: 8.11.2008 20:01:20
Navic... povezte mi prosim, jak byste ve svem reseni dotazoval pracovni skupinu, ktera obsahuje pracovnika X? Ve Vasem DBS jde udelat select s where "blobfield" like '%X%'? A pokud ano, je to z hlediska efektivity dobry napad?
Datum vložení: 20.1.2009 9:11:27
Nezlobte se, ale Vas nazor je uplne mimo misu. Porusenim elementarni normalizace si zadelavate na obrovske problemy pri nasledne sprave DB a jeji rozsirovani. Bohuzel, Vas postoj je dnes na vzestupu a podle toho aplikace vypadaji (registr vozidel a pod.)