Tvorba databází v MySQL - I

20. 3. 2003 | David Hauzar | Návody | 61180×

První část podrobného seriálu o MySQL. Základní pojmy, návrh databáze.

V tomto seriálu se dozvíte to nejdůležitější, co budete potřebovat k tvorbě dobře strukturovaných databází i jejich správě v MySQL. Ve výkladu je počítáno i s úplnými začátečníky. MySQL jsem vybral, protože je v podstatě zadarmo (pro podrobnější informace si přečtěte licenční ujednání na domovské adrese MySQL), je velmi rychlý a jeho správa je poměrně jednoduchá. Navíc pokud budete v budoucnu nuceni naučit se pracovat s jiným relačním databázovým systémem, znalosti získané studiem a používáním MySQL snadno využijete.

Základní pojmy

Databázový systém

Databázový systém se skládá z programu pro práci s databázemi a celé řady podpůrných programů. Databázový systém obstarává přístup k datům. Mezi nejznámější databázové systémy patří např. Oracle9i, Microsoft SQL Server nebo PostgreSQL.

Jazyk SQL

Jazyk SQL je dotazovací jazyk, který se používá k manipulaci s daty v databázích.

Databáze

Databáze v sobě uchovává strukturovaná data. Se strukturovanými daty se pracuje mnohem lépe, než s daty uloženými např. v souborech. Databázový systém vám navíc poskytne řadu funkcí pro manipulaci s daty.

Tabulky (objekty)

Databáze se skládá z tabulek (objektů). V tabulkách jsou uloženy informace, které spolu nějakým způsobem souvisí. Například v tabulce Hudebni_Alba budou informace o hudebních albech.

Sloupce (pole)

Ve sloupcích jsou popsány vlastnosti objektu. Objekt Hudebni_Alba může mít sloupce Autor, Nazev_Alba, Cena.

Záznamy (řádky)

Záznamy jsou už konkrétní data uložená v databázi. Záznam v tabulce Hudebni_Alba by mohl vypadat třeba takto:

Doors, L. A. Woman, 450 nebo Queen, The Game, 600.

Primární klíč

Primární klíč je sloupec, který jednoznačně identifikuje záznam. To znamená, že tento sloupec musí být u každého záznamu jiný.

Pokud by jste tedy v databázi chtěli mít alba o stejné ceně, nemohl by primární klíč být sloupec Cena. Za předpokladu, že by žádná skupina neměla album se stejným jménem jako jakékoli album jakékoli jiné skupiny, mohl by primární klíč být sloupec Jmeno_Alba. To ale vždy nemůžeme předpokládat, proto si vytvoříme nový sloupec ID_Alba. Ten bude muset mít vždy jinou hodnotu. Nejjednodušší je vkládat do tohoto sloupce číslo, které bude u každého dalšího záznamu o jedna větší, než u předchozího.(jak na to se dozvíte v některém z dalších dílů)

Primární klíč se používá k vytváření relací mezi tabulkami.

Relační databáze

Relační databáze se skládá z více objektů (tabulek). Některé z nich spolu mohou souviset - tvořit relaci. Máme-li například objekty Hudebni_Alba(ID_Alba, Autor, Nazev_Alba, Cena), Objednavky(ID_Objednavky, Datum_Objednavky, Mnozstvi, Produkt) objekty Hudebni_Alba a Objednavky spolu mohou souviset - sloupec Proudukt může být Hudebni_Album.

Rozlišujeme několik typů relací.

Relace 1:1

Mějme objekty Objednavky a Transakce(ID_Transakce, Datum_Transakce, Dopravce, Datum_odeslani). Tyto objekty spolu mohou vytvořit relaci 1:1. Každá objednávka může souviset pouze s jednou transakcí a každá transakce může souviset pouze s jednou objednávkou.

Relaci 1:1 mezi tabulkami vytvoříme tak, že do jednoho z objektů přidáme primární klíč souvisejícího objektu a ten označíme jako jedinečný(tj. v objektu do kterého vložím primární klíč souvisejícího objektu nebudou smět být záznamy se stejným primárním klíčem souvisejícího objektu).

Když je primární klíč nějakého objektu přidán do souvisejícího objektu, v souvisejícím objektu mu říkáme cizí klíč. To, zda-li přidáme v našem případě do objektuObjenavky primární klíč objektu Transakce nebo naopak záleží na nás. My vložíme primární klíč objektu Objednavky do objektu Transakce. Objekt Transakce tedy bude vypadat takto Transakce(ID_Transakce, ID_Objednavky Datum_Transakce, Dopravce, Datum_Odeslani). Sloupec ID_Objednavky bude v objektu Objednavky primární klíč, kdežto v objektu Transakce to bude cizí klíč. Cizí klíč je vrelaci 1:1 jedinečný.

Relace 1:N

Mějme objekty Objednavky a Zakaznici(ID_Zakaznika, Jmeno, Adresa, Mesto, PSC). Mezi objekty Objednavky a Zakaznici je relace 1:N. Jeden zákazník může mít více objednávek, ale každá objednávka přísluší pouze jednomu zákazníku.

Při relaci 1:1 byly oba objekty rovnocenné. V relaci 1:N je jeden objekt primární a druhý s ním související. Primární objekt obsahuje záznamy, jejichž jeden záznam odpovídá mnoha záznamům souvisejícího objektu. Relaci 1:N vytvoříme tak, že do souvisejícího objektu vložíme primární klíč primárního objektu. Primární klíč primárního objektu ale nebude v souvisejícím objektu jedinečný. Související objekt bude tedy obsahovat svůj primární klíč, který bude jedinečný, a cizí klíč, který bude moci obsahovat i duplicitní hodnoty.

V našem případě bude primární objekt objekt Zakaznici a související objekt bude objekt Objednavky. Objekt Objednavky bude tedy vypadat takto:

Objednavky(ID_Objednavky, ID_Zakaznika, Datum_Objednavky, Mnozstvi, Produkt).

Sloupec ID_Zakaznika nebude v objektu Objednavky označen jako jedinečný. Kdyby byl cizí klíč jedinečný, vytvořili bychom relaci 1:1!

Relace M:N

Relace M:N by mohla vzniknout mezi objekty Objednavky a Hudebni_Alba. Jedno hudební album může být ve více objednávkách a jedna objednávka může obsahovat více hudebních alb.

Relaci M:N si můžeme představit jako dvě relace 1:N. Potřebujeme, aby oba dva objekty byly primární. Abychom toho dosáhli, musíme vytvořit nový objekt Rozpis_Objednavek a vytvořit relaci 1:N mezi objekty Objednavky a Rozpis_Objednavek a dále mezi objekty Hudebni_Alba a Rozpis_Objednavek, kde objekty Objednavky a Hudebni_Alba budou primární objekty. Objekt Rozpis_Objednavek bude tedy obsahovat sloupce Rozpis_Objednavek(ID_Rozpisu_Objednavek, ID_Objednavky, ID_Alba), kde ID_Rozpisu_Objednavek bude primární klíč a ID_Objednavky,ID_Alba budou cizí klíče, které budou moci obsahovat duplicitní hodnoty.

Normalizace databáze

Normalizace databáze je v podstatě souhrn pravidel, které nám pomáhají vytvářet správné objekty, které obsahují správná pole. Normalizace také usnadňuje pochopení vzájemných vazeb (relací) mezi objekty.

Existují 3 běžně používané stupně normalizace. Jsou uspořádány vzestupně podle úrovně uspořádání.

První normalizovaná forma (1NF)

Pravidlo 1NF říká, že všechny objekty obsahující opakující se sloupce je třeba rozdělit do nových objektů.

V nerelační databázi bychom vytvořili objekt Zakaznici, který by obsahoval veškerá data týkající se zákazníků. Objekt Zakaznici by mohl vypadat třeba takto:

Zakaznici(ID_Zakaznika, Jmeno, Adresa, Mesto, PSC, Produkt_Cena, Produkt_Nazev, Produkt_Cena, Produkt_Nazev2, Produkt_Cena2, Objednavka_Datum, Objednavka_Mnozstvi, Dodavatel_Nazev).

Sloupce vztahující se k produktům budou zcela jistě obsahovat duplicitní hodnoty. Proto podle pravidla 1NF musíme objekt Zakaznici rozbít a sloupce s duplicitními položkami umístit do samostatného objektu. Nový objekt nazveme Produkty. Mezi objekty Zakaznici a Produkty vytvoříme relaci 1:N, kde zákazníci bude primární objekt.

Objekty normalizované na úroveň 1NF budou tedy vypadat takto:

Zakaznici(ID_Zakaznika, Jmeno, Adresa, Mesto, PSC, Objednavka_Datum, Objednavka_Mnozstvi, Dodavatel_Nazev)
Produkty(ID_Produktu, ID_Zakaznika, Produkt_Nazev, Produkt_Cena)

Nyní, když je databáze normalizovaná na úroveň 1NF, je mnohem snažší jak vyhledávání informací v databázi, tak přidávání nových položek do databáze.

Druhá normalizovaná forma (2NF)

Pravidlo 2NF říká, že všechny objekty obsahující sloupce s duplicitními položkami, které mezi sebou vytvářejí částečné závislosti, je třeba rozdělit do objektů nových, v nichž bude každý záznam uložen pouze jednou.

Každý záznam v objektu Zakaznici obsahuje informace o objednávce. Jestliže si zákazníci budou objednávat pouze jeden druh zboží, bude vše vpořádku. Jestliže si ale objednají více druhů zboží, bude se muset pro každý druh objednaného zboží vytvořit nový záznam v objektu Zakaznici. Lepší by bylo vytvořit nový objekt Objednavky a mezi objekty Produkty a Objednavky vytvořit relaci M:N. K tomu ale potřebujeme vytvořit nový objekt Rozpis_Objednavek.

Objekty budou tedy vypadat takto:

Zakaznici(ID_Zakaznika, Jmeno, Adresa, Mesto, PSC),
Objednavky(ID_Zakaznika, ID_Objednavky, Objednavka_Datum, Objednavka_Mnozstvi, Dodavatel_Nazev),
Rozpis_Objednavek(ID_Rozpisu, ID_Pruduktu, ID_Objednavky),
Produkty(ID_Produktu, Produkt_Nazev, Produkt_Cena) .

A to už je něco jiného. Nyní jsme se můžeme doslova kochat výhodami relační databáze. Můžeme do databáze přidávat zákazníky, bez toho, aby to mělo negativní dopad na ostatní objekty.

Třetí normalizovaná forma (3NF)

Pravidlo třetí normalizované formy vyžaduje důsledné odstranění a oddělení veškerých dat, která nejsou v přímém vztahu s daným objektem.

Objekt Objednavky obsahuje sloupec Dodavatel_Nazev. Tento sloupec ale přímo nesouvisí s daným objektem Objednavky (nepopisuje žádnou jeho vlastnost). Podle pravidel 3NF je nutné tento sloupec vyčlenit do nového objektu. Vytvoříme proto nový objekt Dodavatele a mezi objekty Objednavky a Dodavatele vytvoříme relaci 1:1.

Objekty naší databáze normalizované na úroveň 3NF budou vypadat takto:

Zakaznici(ID_Zakaznika, Jmeno, Adresa, Mesto, PSC),
Objednavky(ID_Zakaznika, ID_Objednavky, Objednavka_Datum, Objednavka_Mnozstvi),
Dodavatele(ID_Dodavatele, ID_Objednavky),
Rozpis_Objednavek(ID_Rozpisu, ID_Pruduktu, ID_Objednavky),
Produkty(ID_Produktu, Produkt_Nazev, Produkt_Cena) .

Nyní naše databáze vyhovuje pravidlům 3NF. Tento typ normalizace poskytuje maximální pružnost (stejně jako 2NF) a navíc předchází vzniku logických chyb. Každý sloupec objektu přímo souvisí s daným objektem a je proto jednoznačně identifikován primárním klíčem daného objektu.

Kam až normalizovat?

To záleží na konkrétní databázi. Normalizace je tu proto, aby udělala databázi přehlednější, lépe rozšiřitelnou a výkonnější. Je proto zbytečné normalizovat, když normalizace nepřinese zvýšení přehlednosti, rozšiřitelnosti nebo výkonu. Zbytečně velký počet objektů může naopak udělat databázi nepřehlednou.

Jako příklad zbytečné normalizace uvedu toto: Máme objekt Zakaznici(ID_Zakaznika, Jmeno, Adresa1, Adresa2). Podle pravidel 1NF bychom měli informace o adrese z objektu Zakaznici odstranit, vytvořit nový objekt Adresy a mezi těmito objekty vytvořit relaci M:N - 1 zákazník může mít více adres a 1 adresa může příslušet více zákazníkům (spolubydlící). Musíme tedy vytvořit nový objekt Rozpis_Adres.

Objekty by vypadaly takto:

Zakaznici(ID_Zakaznika, Jmeno)
Rozpis_Adres(ID_Rozpisu_Adres, ID_Zakaznika, ID_Adresy)
Adresy(ID_Adresy) .

Teď databáze odpovídá standardům normalizace, ale kde je přehlednost?

Návrh databáze

Proces návrhu databáze se skládá z následujících kroků.

Definice aplikačního procesu

Definice aplikačního procesu je posloupnost kroků, které vedou ke splnění určitého cíle.

Například Aplikační proces internetového obchodu by mohl vypadat takto:

Zákazník si vybere produkty, které si u vás chce zakoupit -> bude ověřeno, zda je uživatel přihlášen, jestliže ne, musí se přihlásit popřípadě zaregistrovat -> bude odeslána zpráva,která bude obsahovat zákazníkovu objednávku -> pracovníci expedice zabalí objednávku, ověří adresu příjemce a poštou odešlou objednávku zákazníkovi

Definice aplikačních objektů

Aplikační objekty obsahují informace, které chcete v databázi uchovávat. Většinou obsahují klíčové informace, které jsou pro uskutečnění dané operace nezbytné. Aplikační objekt je například produkt nebo zákazník. Dále musímevytvořit sloupce objektů.

Definice aplikačních pravidel (aplikační logiky)

Aplikační pravidla jsou pravidla, kterými se koncová aplikace bude řídit.

Uvedu několik příkladů:

• Internetový obchod musí uživatelům umožňovat vyhledávání produktů
• Uživatelům by mělo být umožněno zobrazení všech jejich transakcí
• Nelze vykonávat záporné transakce
• Vždy, když objednávka vyhovuje požadavkům zpracování, mělo by dojít k odeslání objednávky...

Rozlišujeme dva typy aplikačních pravidel. Předpokládaná aplikační pravidla a platná aplikační pravidla. Předpokládané aplikační pravidlo by mohlo být, že každý zákazník má jméno, nebo že má adresu. Platné pravidlo je pravidlo vynucené konkrétní implementací. Tak například, že objednávka může obsahovat víc produktů.

Modelování databáze

Modelování databáze je nakreslení si všech objektů a jejich sloupců. Dále by jste měli stanovit datové typy sloupců a stanovit, zda-li budou jednotlivé sloupce v databázi vyžadovaná.

Normalizace databáze a vytvoření relací mezi objekty

Tyto dvě činnosti mezi sebou do značné míry souvisí. Na normalizaci by jste měli myslet už při modelování databáze, ale často se vám může stát, že při vytváření relací zjistíte, že vaše databáze není dostatečně normalizovaná.

Při vytváření relací musíte nejprve určit, jestli mezi objekty existuje nějaký vztah a pak určit jaký.

Závěr

Tak a to je všechno. V prvním díle jste se naučili základní databázové pojmy, víte, co to jsou relační databáze, umíte normalizovat a měli by jste být schopni správně strukturovanou databázi vymodelovat.

Příští díl bude podstatně méně teoretický. Napřed si v rychlosti připomeneme výhody MySQL a dále se naučíte MySQL používat.

       

Komentáře

[kamenac]

Clanek je dobry, jen me zarazily ony "normovane formulare". Vznikly patrne otrockym prekladem z "normal form" (cesky casto opet mylne prekladane jako "normalni forma").
Spravny preklad je "prvni normalizovana forma".

[Robert Krátký]

moje chyba: autor me na tuto svou chybu upozornil, ale ve shonu jsem ji zapomnel opravit.

[Kocour_easy]

Celkem dobre,ale: 1."Se strukturovanými daty se pracuje mnohem lépe, než s daty uloženými např. v souborech", to mam chapat jako, ze Databaze uklada data nekam do prostoru?? 2.Proc by nemohl byt primarni klic duplicitni??? Dik

[Radek]

ad 1. At uz databaze uklada data kam chce, smysl je prave v tom, ze to nas pri praci s daty v databazi nemusi zajimat a mohu s daty pracovat skutecne tak, jako by byly ulozeny nekde v prostoru

ad 2. Lepe receno hodnota primarniho klice nemuze byt duplicitni. Tato hodnota totiz slouzi k tomu, aby jednoznacne identifikovala prave jeden radek v tabulce. Primarni klic muze byt tvoren i kombinaci vice sloupcu. Relacni model nezna jiny zpusob, jak jednoznacne identifikovat jeden radek tabulky. Proto to tak musi byt a databaze hlida, ze je tato vlastnost splnena.

[xyz]

1. Nie databaza si to tiez uklada do suborov na FS, ale nie ako bezny textovy subor, alebo podobne. MySQL ako aj ostatne databazy to storuje ako binarne data. Napr: oracle to ma tak, vytvoris si tablespace s nejakou velkostou, tento tablespace je vacsinou na zaciatku jeden subor (datafile ulozeny na disku). Samozrejme tablespace sa moze mat viacej data files. No a v tablespace sa sklada este z mensich logickych jednotiek tzv. data segemnts a tie sa skladaju este z mensich, co su extenty (extents), ktore sa postupne tvoria ako sa plni databaza a tvoria sa podla pravidiel, ktore si vies nadefinovat. No a ked sme sa dostali uz sem, tak spomeniem, ze extenty sa skladaju z blokov alebo presnejsie z data blocks. 2. primarny kluc je nieco, co sluzi na jednoznacnu identifikaciu zaznamu a z tohto dovodu, nemoze a nesmie byt duplicitny!

[t0rN]

mluv česky, sakra, jsi na českym serveru!!!

[d.f.h]

t0rN> zabij se, ty nadhero!

[Santa Klaus]

Sa nepotentuj ty pepik!!!

[Richard Gavenda]

Primární klíč je tu od toho, aby jednoznačně identifikoval záznam. Pokud by byl duplicitní, jak pak neleznu záznam se kterým se má pracovat?
Autorovi: skvělý článek, doufám, že kvalita zůstane i v dalších dílech.

[rat]

jen k tomu prikladu s adresou - nejde jen o prehlednost (ta je navic subjektivni), ale i o schopnost reprezentovat data. v tomto konkretnim pripade pred normalizaci "neexistuje" (mysleny) objekt adresa, nedokazu ho popsat pokud na te adrese nekdo z me databaze nesidli a ani pak neni nezavisly. to nemusi ale muze vadit, casto se to ukaze az po nejake dobe a musi se to nejak zaprasit, cimz jde prehlednost zcela do haje. takze doporucuju nehledat v konkretnich pripadech duvody "proc normalizovat", ale naopak "proc nenormalizovat".

[met]

Pekny clanek, doufam, ze casem dojde i k tomu jak pracovat s MySQL z PHP ci Perlu.

[Tomáš Hofman]

Ne, ze bych proti MySQL neco mel (jako, ze mam :), ale zacina to vypadat na hegemonii jednoho (navic pomerne spatneho db serveru), proc taky nekdo nenapise neco o PostgreSQL? Navic podle toho co jsem precetl to neni o MySQL, ale o SQL (ze by skryta reklama? ale to snad ne...).

[Jan Kubik]

pan asi necetl zakladni dila ceskeho guru Karla Zaka na rooto a jinych zdrojich. Stydte se.

[theo]

cesky guru Karel Zak mi neni prilis znamy takze mi neni jasna souvislost. Stydet se nemam za co.

[Robert Krátký]

Clanek o PgSQL se uz mam "na stole". Vyjde doufam pristi tyden. Pak si muzete zaflamovat .

[Zdeněk Burda]

Uz se tesiiim

[buffery]

Ja taky

[pavel 'goldenfish' kysilka]

vydrzte, urcite neco vyjde.

[xyz]

Odkaz pre T. Hofmana Podla coho sudis, ze MySQL nie je dobra databaza? My sme pouzivali PostgreSQL, problemy zacali byt cca u 1GB databazy. Momentalne pouzivame MySQL a momentalna velkost DB je nieco cez 3G a doposial sme nenarazili na ziadny problem s rychlostou. FUD1. MySQL nema transakcie - MA! dokonca pouziva dva typy transakcnych databaz BDB (na tejto je zalozene aj postgre), InnoDB (je rychlejsia a ma kopec vymozenosti oproti BDB). FUD2. MySQL sa nehodi na vacsie projekty, NASA vymenilo Oracle za MySQL na vsetkych weboch. MySQL pouziva aj Yahoo. FUD3. MySQL nepozna subselecty - pozna, 4.1.0, mam ju skompilovanu a ide to super! MySQL nema trigre, ani stored procedury - ano nema, stored procedury sa chystaju a dokonca budu moct byt aj v roznych jazykoch na zaciatok to budu dva nativny (nieco ako PL/SQL alebo postgre bastard PSQL) a PHP, pretoze do MySQL sa integruje ZEnd Engine a neskor to bude C, Perl. Trigre autori nechcu kvoli rychlosti, ale postupom casu aj tak budu donuteny. BTW: na pseudo stored procedury existuju patche do MySQL. FUD4. Z Postgre sa jednoduchsie prechadza na oracle - skusali ste napr. uz migrovat vase stored procedury Na zaver len dodam, ze "milujem" ludi, ktory si niekde nieco precitaju alebo vypocuju na prednaske a zacnu sirit FUD. Pri tom tito ludia ani netusia, co to je full table scan, prip. rollback segment, redo log alebo aky je rozdiel medzi B-tree indexom a bitmapovym indexom a co a kedy pouzit. MySQL je velmi dobry a rychly SQL server a vrele ho doporucujem. Neexistuje najlepsi ani "unbreakable" SQL server, kazdy je na nieco dobry, len je potrebne poznat ich prednosti a slabiny a podla toho postupovat pri vybere pre nejaky projekt.

[Pavel 'Goldenfish' Kysilka]

zdravim,
a pridam si do flame.
1) rychlost je sice hezka vec, ale pokud dana database nema nejake featury, tak si je potom muzete doprogramovavat a jako programator si to opravdu hodite.a o prenositelnosti na dalsi projekty si muzete nechat zdat.
2)subselecty - nevim, jak vy, ale ja bych si nedal na server versi databasoveho serveru, ktera neni poradne ozkousena.
3) funkce a trigery - pokud je znate, tak tam se da teprve rici, ze umite neco s databasemi.a v tom je sila pouziti databasi. ne v tom, ze umite udelat SELECT A INSERT.tento bod nemyslim nejak spatne.
4)pokud je database pomala pri urcitem mnozstvi dat, tak se to vyplati mozna si dat do database nejaka testovaci data.menit potom uz databasovy server je pozde.
5) taky jsem se domnival, ze mysql je to nejlepsi, pred pul rokem jsem zmenil nazor. ale zalezi to od projektu.
zatim goldenfish

[theo]

Co treba View? V MySQL planovane nekde ve verzi 5.?.? Co relacni integrita? Co zabezpeceni integrity dat (uznavam, ze ani PostgreSQL tohle nema dotazene do konce, ale kdyz uz jste nekousl ten Oracle :). Je mi uprimne jedno co pouzivate vy, ale zaujalo me to, ze clanek popisujici SQL ma v nazvu MySQL...

[Michal]

Dobry den, Mam dve laicke otazky. Mozna jsem plne nepochopil ty vazby, ale u finalniho prikladu (3NF) nemohu vycist vazbu na zakaznika. Cekal bych, ze v nejake jine tabulce (produkty, objednavky ?) bude uveden klic ID_Zakaznika. A druhy dotaz. Chapu spravne, ze se u tabulky Dodavatele meni Dodavatel_Nazev na ID_Dodavatele ? Dekuji moc, michal

[David Hauzar]

Diky za objeveni chyby. 1. V prikladu u 2NF i 3NF vazba na objekt Zakaznici skutecne chyby. Objekt Objednavky by mel obsahovat sloupec ID_Zakaznika. 2.Kdyz bychom predpokladali, ze v databazi nebudou dodavatele se stejnym nazvem, mohl by se sloupec Nazev_Dodavatele "zmenit" v primarni klic nove vycleneneho objektu Dodavatele (tj.v ID_Dodavatele). Pokud bychom toto nemohli predpokladat, museli bychom v objektu Dodavatele vytvorit novy sloupec Nazev_Dodavatele (sloupec ID_Dodavatele by pak obsahoval treba nejake u kazdeho zaznamu jine cislo). U prikladu k Kam az normalizovat chyby v objektu Adresy sloupec Adresa (kdyz bychom predpokladali, ze v databazi nemohou mit 2 zakaznici stejnou adresu, mohl by sloupec ID_Adresy obsahovat adresu a mohlo by to zustat i tak, jak to je - situace je podobna jako u sloupce ID_Dodavatele).

[David Hauzar]

Mezi objektem Zakaznici a Adresy by mela byt relace M:N, protoze 1 zakaznik muze mit 2 adresy, ale i 1 adresa muze prisluset vice zakaznikum (spolubydlici). Objekty tedy budou vypadat takto: Zakaznici(ID_Zakaznika, Jmeno) Rozpis_Adres(ID_Rozpisu_Objednavek, ID_Zakaznika, ID_Adresy) Adresy(ID_Adresy) Ve sloupci ID_Adresy bude ulozena adresa. (V tomto pripade nemusime vytvaret zadny novy sloupec Adresa, protoze adresa v sloupci ID_Adresy bude vzdy jina)

[Michal]

Diky. Uz mi to zacina davat smysl ;) m. P.S. Tesim se na dalsi dily.

[David Hauzar]

oops udelal jsem dalsi chybu... v popisu objektu Rozpis_Adres ma byt samozrejme misto ID_Rozpisu_Objednavek ID_Rozpisu_Adres

[vit novotny]

zajimalo by mne zda lze mysql vyuzit bez znalosti programovacich jazyku.. zda lze nejak volat data z mysql do html..treba ze bych mel html stranku a zni bych si cucal mysql data ? pokud ne asi nema smysl se tu zabejvat jen (my)sql a rovnou by to chtelo vzit od podlahy i s nejakym tim programovanim aby clovek potom rovnou mohl neco zkusit udelat.. a ne znat jen 1/2 nutneho.. ..ja bych radeji kdyby tu byla poradna vyuka php v cestine pro zacatecniky nebo programovani C pod linux pro zacatecniky.

[David Hauzar]

Pro programovani www stranek php bez znalosti programovani vyuzit nemuzes. K databazi se potrebujes pripojit a pak ji sdelit, jaka data od ni chces. Databaze ti vrati data a ty musis jejich vkladani do html nejak ridit. Vse se dela pomoci programovaciho jazyku. Pro rychle nauceni doporucuji PHP. Literatury v cestine o PHP je mraky - pro zacatecniky vrele doporucuji: Ucebnice zakladu PHP4 od Grady - ani neni draha - stoji 200 KC. Rekl bych, ze poradna vyuka php pro zacatecniky tady nikdy nebude, protoze to je dost rozsahle a kvalitni literatury v cestine je hodne. Jeden z duvodu, proc jsem napsal tenhle serial je, ze v literature o php je mysql vetsinou probrano jen hodne povrchne a aktualnich, strucnych, prehlednych, v cestine napsanych knih o MySQL neni mnoho.

[Frank]

Mám doma knihu Naučte se MySQL za 21 dní, a přijde mi hodně dobrá. Též mám rád knihu PHP tvorba interaktivních internetových aplikací - podrobný průvodce (J. Kosek). Pak se můžete mrknout i do PHP a MySQL - rozvoj webových aplikací (Luke Welling, Laura Thomson) nebo do PHP a MySQL (Hugh E. Williams, David Lane). Kvalitních knih v češtině je spousta, stručné sice nejsou (to je spíš úloha on-line úvodů a tutoriálů), ale není se co divit. Pokročilý uživatel stručnou referenci nepotřebuje a začátečníkovi je IMHO k ničemu.

[Jan Kubik]

Mam malou prosbu na autora, jestli by nebylo mozno v pristim dile take napsat, proc vubec SQL, co jsou nevyhody, jake existuji alternativy. Do jakych slepych ulicek se napr. zenou projekty, stavici na SQL. Nekdy mam takovy pocit, ze cela programatorska obec akceptuje SQL jako neco od Boha - asi jako kdyz se myslelo, ze Zeme je placata. Povazoval bych za spravne, nez se dalsi generace vrhnou do diskuzi o tom, jestli je subselect potreba ci ne, si udelat jasno, jestli je ta SQL potreba - a jestlize ano, v cem nas omezuje. Dekuji

[Pavel Stehule]

Ac nejsem autor, dovolim si odpovedet. Jsem totiz jeden z tech, kteri do programatorske obce busi nazor, ze SQL je dar od boha (i kdyz mi chvili trvalo, nez jsem se SQL naucil pouzivat, a jeste dyl nez jsem se s nim nejak dusevne smiril). Duvody proc pouzivat SQL jsou podle mne dva: a) radikalne se zjednodusi program, resp "zasmodrchanost" se presune do SQL, b) davam prostor k optimalizaci provedeni dotazu tim, ze problem popisi pomoci SELECTU. Musel bych znat velice dobre konkretni system abych navrhnul aplikaci, ktera bude stejne efektivni jako zoptimalizovane SQL. Kdysi jsem kvuli tomu odmital programovat v MS Accessu, kdy misto programovani se provadela jakasi alchimie. Krome jineho si mohu dotaz odzkouset nanecisto mimo programovanou aplikaci. Dale citelnost SQL dotazu je vetsi nez citelnost ISAM aplikaci (i kdyz jde asi o zvyk). Nevyhoda mi prijde jedina, ve vyjmecnych pripadech mohou byt reseni nezalozene na SQL databazich mnohem rychlejsi. viz rychlost ruznych malych systemu zalozenych na Foxce. Navic znalost SQL se vyplati i proskolenym uzivatelum, kteri at nemusi programovat jsou sto vyzobat z bazi potrebna data a nemusi kvuli tomu otravovat programatory, kteri se mohou venovat bohulibejsi praci, jako je psani nejapnych clanku pro internet:->. Co se tyce funkcionality, pro relacni databaze nevim o nicem co by neslo resit skrze SQL+ulozene procedury. Diskuze o tom, zdali db podporuje vnorene selecty, triggery atd je jen o tom, ze s temito vymozenostmi mohu napsat aplikaci o fous jednodussi, kratsi a pravdepodobne i robustnejsi a spolehlivejsi. Moznosti databaze maji samosebou dopad na navrh aplikace. Pokud databaze neumoznuje triggery, pak mam tenkou db vrstvu a mnohem slozitejsi aplikacni vrstvu (a nemusim tolik rozumet databazim). S triggrama a ostatnima paradickama napisi aplikaci skorem jenom na urovni databaze a vsechno ostatni je vlastne jen uzivatelsky interface. Velice silne a rychle generovani reportu je napriklad databaze generujici XML, ke kteremu se pripoji jen CCS a cele se to posle klientovi. Aplikaci mohu napsat i v tom nejpomalejsim skriptovacim jazyku a neovlivnim tim nijak vykon. Debata SQL ano ci ne uz dneska je pase. Pripomina to casy, kdy se diskutovalo o tom, zda-li je lepsi FORTRAN nebo strukturovane jazyky. NESQL databaze budou existovat stale (pro zvlastni pripady), ale bude to jen zlomek pouzivani db. Navic SQL nebo jazyky na nem zalozene celkem dobre integruji pristup k datovym zdrojum. Skrze SQL mohu odesilat filtrovat a cist maily, sledovat a monitorovat konfiguraci pocitace (WMI), dohledavat soubory, vyhledavat fultextove (FileNET) atd. Pavel

[Jiri Matejka]

Zdravim, rad bych se dozvedel proc jsou casti clanku temer shodne s texty z knihy Naucte se MySQL za 21 dni (vydal cPress, autor Mark Maslakowski)?
Napriklad cely blok o normalizeci databaze vcetne prikladovych tabulek s nazvy sloupcu jsou identicke a texty trochu poupraveny a nektere nadpisy odstavcu uplne stejne...
Nikde ale nevidim, ze by tato kniha byla napsana jako zdroj ze ktereho se cerpalo...
Muze autor dat odpoved?
Diky

[David Hauzar]

Zdroje ze kterych jsem pri psani tohoto prvniho dilu cerpal: Naucte se MySQL za 21 dni, clanek (a jeho komentare) Modelovani databazi ze serveru root.cz, okrajove jeste i z PHP pokrocile programovani pro world wide web.

Jinak na tom, ze jsem pouzil stejnou definici normalizovanych forem, nevidim nic spatneho. Tech definic normalizovanych norem je sice vice, vsechny jsou ale obdoby originalni anglicke.

Cely dil je zalozen na vytvareni databaze internetoveho obchodu. Neni to zrovna originalini reseni (priklad tvorby internetoveho obchodu se dnes vyskytuje temer ve vsech knihah o PHP nebo MySQL), nicmene databaze internetoveho obchodu je prakticky a pro lidi snadno predstavitelny priklad).
Priklad k normalizaci databaze je vytvoren tak, ze se do jednoho objektu z databaze internetoveho obchodu "nacpou" vsechny sloupce z ostatnich objektu (pro prehlednost jsem vybral jen nektere z nich) a objekt se pak pomoci normalizacnich pravidel rozklada. Vim, ze stejne je to provedeno i v MySQL za 21 dni, toto je ale nejlepsi reseni. (samozrejme bych mohl vymyslet na normalizaci priklad nesouvisejici z databazi internetoveho obchodu. Vzhledem k tomu, ze vyuzivam priklad internetoveho obchodu v predchozi casti, nebylo by to tak vhodne).

Nadpisy odstavcu: Odstavec pojednavajici o prvni normalizovane forme se ve vetsine literatury jmenuje Prvni normalizovana forma atd.

PS: Procital jste si uz manual o MySQL? Jiste (by) jste si vsiml, ze v MySQL za 21 dni jsou nektere nadpisy odstavcu identicke a nektere texty temer stejne jako v manualu. Vetsinou totiz nema smysl vymyslet nove definice, popisy funkci apod.

[radan]

tady to snad pujde

[zabi]

zdar

[radan]

jj sem to pujde

[m]

/*1 vytvořte funkce sachta_max(id_trpaslika,mesic, rok) vstupními argumenty jsou id_trpaslika, mesic a rok v číselném vyjádření(rok na 4 číslice), pro které dany trpaslik  zadanem mesici vytezil nejvice kg rudy. pokud v danem mesici trpaslik v zadne sachte netezil, vrati funkce hodnotu null, pokud mel ve vice sachtach stejny max vysledek, vrati funkce zreteteny seznam techt sachat, napr 'u potoka, v chvoji

[m]

/*2 vytvorte pohled trp_max_smen, jehoz vystupem jsou sloupce s nazvy, trpaslik, sachta, pro kazdeho trpaslik z tabulky trpaslici bude v pohledu uvedeno, v ktere sachte natezil nejvice kg rudy v roce 2006 v unoru pokud to bylove vice sachtach budou tyto zretezeny ve 2.sloupce-viz popis predchozi funkce  */
/*3   */

[zabi]

to je pekny teda :X

[m]

/*1 vytvořte funkce sachta_max(id_trpaslika,mesic, rok) vstupními argumenty jsou id_trpaslika, mesic a rok v číselném vyjádření(rok na 4 číslice), pro které chceme vratit nazev sachty, v ktere dany trpaslik v zadanem mesici vytezil nejvice kg rudy. pokud v danem mesici trpaslik v zadne sachte netezil, vrati funkce hodnotu null, pokud mel ve vice sachtach stejny max vysledek, vrati funkce zreteteny seznam techt sachat, napr 'u potoka, v chvoji*/

znova byla tam chyba

[zabi]

create or replace view  trp_max_smen as
select jmeno,sachta from
(select trpaslici.jmeno,sachty.sachta,max(tezby.skutecnost)as pocet from trpaslik.trpaslici
join trpaslik.tezby on trpaslici.id=tezby.id_trpaslika
join trpaslik.sachty on tezby.id_sachty=sachty.id
where tezby.den BETWEEN TO_DATE('01.02.2006','dd.mm.yyyy') AND
TO_DATE('28.02.2006','dd.mm.yyyy')
group by trpaslici.jmeno,sachty.sachta)

[zabi]

 

nejni osetreny kdyz so utreba dve sachty kde ma stejne

[zabi]

RETURN VARCHAR2 AS v_vysledek VARCHAR2; BEGIN SELECT trpaslici.id, trpaslici.jmeno, id_sachty, sachty.sachta INTO v_vysledek, MAX(tezby.skutecnost) FROM trpaslik.trpaslici JOIN trpaslik.tezby ON trpaslici.id = tezby.id_trpaslika JOIN trpaslik.sachty ON tezby.id_sachty = sachty.id WHERE trpaslici.id = in_id_trpaslika AND (TO_CHAR(den, 'MM') = in_mesic) AND (TO_CHAR(den, 'YYYY') = in_rok) GROUP BY trpaslici.id, trpaslici.jmeno, id_sachty, sachty.sachta HAVING MAX(tezby.skutecnost) = (SELECT MAX(tezby.skutecnost) FROM trpaslik.trpaslici JOIN trpaslik.tezby ON trpaslici.id = tezby.id_trpaslika JOIN trpaslik.sachty ON tezby.id_sachty = sachty.id WHERE trpaslici.id = in_id_trpaslika AND (TO_CHAR(den, 'MM') = in_mesic) AND (TO_CHAR(den, 'YYYY') = in_rok) GROUP BY trpaslici.id, trpaslici.jmeno); RETURN v_vysledek; END;

[zabi]

CREATE OR REPLACE FUNCTION sachta_max(in_id_trpaslika NUMBER, in_mesic NUMBER, in_rok NUMBER)
RETURN VARCHAR2
AS
v_vysledek VARCHAR2;
BEGIN
SELECT trpaslici.id, trpaslici.jmeno, id_sachty, sachty.sachta INTO v_vysledek, MAX(tezby.skutecnost)
FROM trpaslik.trpaslici
JOIN trpaslik.tezby ON trpaslici.id = tezby.id_trpaslika
JOIN trpaslik.sachty ON tezby.id_sachty = sachty.id
WHERE trpaslici.id = in_id_trpaslika AND (TO_CHAR(den, 'MM') = in_mesic) AND (TO_CHAR(den, 'YYYY') = in_rok)
GROUP BY trpaslici.id, trpaslici.jmeno, id_sachty, sachty.sachta
HAVING MAX(tezby.skutecnost) =
(SELECT MAX(tezby.skutecnost)
FROM trpaslik.trpaslici
JOIN trpaslik.tezby ON trpaslici.id = tezby.id_trpaslika
JOIN trpaslik.sachty ON tezby.id_sachty = sachty.id
WHERE trpaslici.id = in_id_trpaslika AND (TO_CHAR(den, 'MM') = in_mesic) AND (TO_CHAR(den, 'YYYY') = in_rok)
GROUP BY trpaslici.id, trpaslici.jmeno);
RETURN v_vysledek;
END;

[zabi]

SELECT sachta_max(7,2,2006) FROM DUAL;