načítání...
nákupní košík
Košík

je prázdný
a
b

Kniha: Mistrovství - PHP a MySQL - Laura Thomson; Luke Welling

Mistrovství - PHP a MySQL
-12%
sleva

Kniha: Mistrovství - PHP a MySQL
Autor: ;

Naučte se vytvářet interaktivní webové aplikace od těch nejjednodušších formulářů až po komplexní projekty. V Mistrovství najdete vše o PHP a MySQL, co k tvorbě webových aplikací ... (celý popis)
Titul doručujeme za 3 pracovní dny
Vaše cena s DPH:  1 190 Kč 1 047
+
-
rozbalKdy zboží dostanu
34,9
bo za nákup
rozbalVýhodné poštovné: 0Kč
rozbalOsobní odběr zdarma

ukázka z knihy ukázka

Titul je dostupný ve formě:
tištěná forma elektronická forma

hodnoceni - 0%hodnoceni - 0%hodnoceni - 0%hodnoceni - 0%hodnoceni - 0%   celkové hodnocení
0 hodnocení + 0 recenzí

Specifikace
Nakladatelství: » Computer press
Médium / forma: Tištěná kniha
Rok vydání: 2017-11-28
Počet stran: 800
Rozměr: 167 x 225 mm
Úprava: 799 stran
Vydání: 1. vydání
Spolupracovali: překlad: Ondřej Baše
Vazba: vázaná s laminovaným potahem
ISBN: 9788025148921
EAN: 9788025148921
Ukázka: » zobrazit ukázku
Popis

Naučte se vytvářet interaktivní webové aplikace od těch nejjednodušších formulářů až po komplexní projekty. V Mistrovství najdete vše o PHP a MySQL, co k tvorbě webových aplikací potřebujete, na jednom místě. Dvojice autorů s bohatými zkušenostmi v oblasti tvorby webových aplikací vás postupně seznámí s PHP, MySQL a možnostmi jejich propojení při vývoji. Naučíte se správně nastavit prostředí, vytvářet jednoduché dynamické stránky a postupně přidávat další a další funkce až po propracované webové aplikace. V závěru knihy si vyzkoušíte vytvořit vlastního webového e-mailového klienta. Publikace se mimo jiných věnuje následujícím tématům: - Ukládání a načítání dat - Správa webové databáze - Práce se systémem souborů - Generování obrázků - Internacionalizace a lokalizace - Správa relací v PHP, zabezpečení webové aplikace - Ladění, logování, zpracování chyb a výjimek - Autentizace a personalizace uživatelů O autorech: Laura Thomson je technickou ředitelkou ve společnosti Mozilla Corporation. V minulosti bývala ředitelkou ve společnostech OmniTI a Tangled Web Design a pracovala pro univerzitu RMIT University a společnost Boston Consulting Group. Luke Welling pracuje jako softwarový analytik. Pravidelně přednáší o tématech otevřeného zdrojového kódu a webového vývoje na konferencích, jako jsou například OSCON, ZendCon, MySQLUC, PHPCon, OSDC a LinuxTag. Pracoval také ve společnostech OmniTI, Hitwise.com, MySQL AB a jako nezávislý konzultant ve společnosti Tangled Web Design.

Předmětná hesla
Kniha je zařazena v kategoriích
Laura Thomson; Luke Welling - další tituly autora:
Recenze a komentáře k titulu
Zatím žádné recenze.


Ukázka / obsah
Přepis ukázky

8

KAPITOLA

V této části knihy budete

pracovat s databázovým

systémem MySQL. Než se

jím začnete zabývatpodrob

něji (v příští kapitole), měli

byste se dozvědět o:

 Koncepce a terminologie

relačních databází.

 Navrhování webové

databáze.

 Architektura webové

databáze.

Navrhujeme

webovou

databázi

Když už znáte základy jazyka PHP, můžete se začítzabý

vat tím, jak začlenit databáze do svých skriptů. Možná si

pamatujete, že kapitola 2 uváděla výhody databází oproti

prostým textovým souborům. Patří k nim:

 Databáze poskytují rychlejší přístup k datům než

prosté textové soubory.

 Databází se lze dotazovat na skupinu dat, kteráspl

ňují určitá kritéria.

 Databáze mají vestavěné mechanizmy pro zacházení

se současným přístupem více uživatelů a s konflikty

z toho plynoucími, kterými se proto jakoprogramá

toři nemusíte zabývat.

 Databáze poskytují náhodný přístup k datům.

 Databáze mají vestavěný systém oprávnění.

Pomocí databází můžete například rychle odpovědět na

otázky, odkud pocházejí vaši zákazníci, které produkty se

prodávají nejlépe a jaký typ zákazníků nejvíce utrácí. Tyto

informace vám můžou pomoct vylepšovat vaše webové

stránky, abyste zaujali více návštěvníků. Z prostéhotexto

vého souboru byste je dolovali jen stěží.

V této části knihy se naučíte následující:

 V  kapitole 9, „Vytváříme webovou databázi“, se

dozvíte o základní konfiguraci pro připojenídata

báze MySQL k webu. Naučíte se vytvářet uživatele,

databáze, tabulky a indexy a dozvíte seo nejrůzněj

ších typech úložišť systému MySQL.


236 KAPITOLA 8  NAVRHUJEME WEBOVOU DATABÁZI

 Kapitola 10, „Práce s databází MySQL“, vysvětluje, jak se dotazovat do databáze,

jak přidávat, odstraňovat a upravovat záznamy – a to vše z příkazového řádku.

 V kapitole 11, „Přistupujeme do databáze z webu s jazykem PHP“, se dozvíte, jak

propojit jazyk PHP se systémem MySQL, abyste mohli používat a spravovat svou

databázi z webového rozhraní. Můžete používat dvě metody – nativní ovladač

MySQL a databázově nezávislé rozšíření PDO.

 Kapitola 12, „Pokročilá správa systému MySQL“, se věnuje správě systému MySQL

podrobněji. Obsahuje informace o systému oprávnění, zabezpečení a optimalizaci.

 Kapitola 13, „Pokročilé programování se systémem MySQL“, se zabývá typydata

bázových úložišť podrobněji, a to včetně transakcí, fulltextového vyhledávánía ulo

žených procedur.

Koncepce relačních databází

Relační databáze jsou nejrozšířenějším typem databází. Svůj základ mají v relační algebře.

Nemusíte rozumět relační teorii, abyste mohli používat relační databáze, ale musíte znát

základní koncepce relačních databází.

Tabulky

Relační databáze se skládají z tabulek. Tabulky jsou přesně to, co naznačuje jejich název

– tabulky dat. Pokud jste někdy pracovali s Excelem, už jste používali podobné tabulky.

Prohlédněte si ukázkovou tabulku na obrázku 8.1. Obsahuje jména a adresy zákazníků

obchodu Book-O-Rama.

Obrázek 8.1. Informace o zákaznících obchodu Book-O-Rama uložené v tabulce

Tabulka se jmenuje Customers (zákazníci), přičemž obsahuje několik sloupců s různými

kusy data a řádky odpovídající jednotlivým zákazníkům.

Sloupce

Každý sloupec má jedinečný název a obsahuje různá data. Ke každému sloupci se váže

určitý datový typ. V tabulce Customers na obrázku 8.1 můžete vidět, že sloupec CustomerID

obsahuje celá čísla a v dalších třech sloupcích jsou textové řetězce. Sloupce se také občas

nazývají pole nebo atributy.

CustomerID

Customers

1

2

3

Name

Jana Nováková

Aleš Světlý

Michal Starý

Address

Dubová 25

Kopřivová 47

Severní 357

City

Pelhřimov

Horní Bečva

Pustiměř


237

8

Navrhujeme

webovou databázi

KONCEPCE RELAČNÍCH DATABÁZÍ

Řádky

Každý řádek v tabulce reprezentuje jiného zákazníka. Díky tabulkovému formátu mají

všechny řádky stejné atributy. Řádkům se někdy rovněž říká záznamky.

Hodnoty

Jednotlivé řádky se skládají z různých hodnot pro jednotlivé sloupce. Každá hodnota musí

mít datový typ, který odpovídá příslušnému sloupci.

Klíče

Musíte mít možnost identifikovat jednotlivé zákazníky. Jména nejsou vhodným údajem

k identifikaci. Pokud máte rozšířené jméno, pravděpodobně chápete proč. Uvažtekupří

kladu jméno Jana Nováková z tabulky Customers. Když si otevřete telefonní seznam, najdete

v něm příliš mnoho výskytů tohoto jména.

Mohli byste rozlišovat Janu několika způsoby. O  něco pravděpodobnější je, že Jana

Nováková je jedinou nositelkou tohoto jména na své adrese. Identifikace „Jana Nováková,

žijící na adrese Dubová 25, v Pelhřimově“ je však poměrně krkolomná. Pravděpodobně

by vyžadovala zapojení více sloupců tabulky.

V tomto příkladu jste udělali něco, co bude i skvělým řešením ve vašich aplikacích –při

řadili jste jednotlivým zákazníkům jedinečné číselné identifikátory CustomerID. Jedná se

o stejný princip, proč například máte jedinečné číslo účtu v bance nebo jedinečnéklu

bové číslo. Díky tomu bude ukládání osobních údajů do databáze jednodušší. U uměle

vygenerovaného čísla lze snadno zaručit, aby bylo jedinečné. Jen málo typů skutečných

informací má tuto vlastnost, a to i když jich spojíte více.

Identifikující sloupec tabulky se nazývá klíč nebo primární klíč. Klíče se můžou skládat

z více sloupců. Kdybyste se opět vrátili k „Janě Novákové, Dubová 25, Pelhřimov“, mohli

byste složit klíč ze sloupců Name (jméno), Address (adresa) a City (město) a přitom byste

stále nemohli zaručit jedinečnost.

Databáze se obvykle skládají z více tabulek, přičemž klíče slouží jako odkazy z jedné

tabulky do druhé. Obrázek 8.2 ukazuje druhou tabulku přidanou do dané databáze. Každý

řádek tabulky Orders (objednávky) představuje objednávku od nějakého zákazníka. Abyste

neztratili přehled, ke kterému zákazníkovi objednávka patří, budete si ukládatk objed

návce identifikátor zákazníka. Když si prohlédnete tuto tabulku, zjistíte například, že

objednávku OrderID 2 vytvořil zákazník CustomerID 1. Pokud se potom podíváte do

tabulky Customers, uvidíte, že zákazníkem 1 je Jana Nováková.


238 KAPITOLA 8  NAVRHUJEME WEBOVOU DATABÁZI

Obrázek 8.2. Každá objednávka v tabulce Orders se odkazuje na zákazníka

z tabulky Customers

Relační databáze označuje tento typ vztahu jako cizí klíč. Sloupec CustomerID je primárním

klíčem tabulky Customers, ale pokud se objeví v jiné tabulce, například v tabulce Orders,

říká se mu cizí klíč.

Možná se divíte, proč byste měli mít dvě samostatné tabulky. Proč neuložit adresu Jany

do tabulky Orders? O tomto problému pojednává následující část této kapitoly.

Schémata

Kompletní sada návrhů tabulek se nazývá schéma databáze. Jedná se o plán databáze.

Schéma by mělo ukazovat tabulky s jejich sloupci, primární klíče a cizí klíče tabulek.

Schéma neobsahuje data, ale můžete spolu s ním uvádět ukázková data, která pomáhají

objasnit jednotlivé jeho komponenty. Schéma lze znázornit diagramem, kterému se říká

ERD diagram (entity relationship diagram, jehož popis ale není součástí této knihy),

nebo textově; například takto:

Customers(CustomerID, Name, Address, City)

Orders(OrderID, CustomeID, Amount, Date)

Podtržené sloupce jsou primární klíče tabulek, ve kterých jsou uvedené. Kurzíva označuje

cizí klíče tabulek, v nichž jsou uvedené.

CustomerID

Customers

1

2

3

Name

Jana Nováková

Aleš Světlý

Michal Starý

Address

Dubová 25

Kopřivová 47

Severní 357

City

Pelhřimov

Horní Bečva

Pustiměř

OrderID

Orders

1

2

3

4

CustomerID

3

1

2

3

Amount

687.50

325.00

1850.00

175.00

Date

02-Apr-2007

15-Apr-2007

19-Apr-2007

01-May-2007


239

8

Navrhujeme

webovou databázi

NAVRHOVÁNÍ WEBOVÉ DATABÁZE

Vztahy

Cizí klíče reprezentují vztahy mezi daty dvou tabulek. Například cizí klíč z tabulky Orders

odkazující do tabulky Customers představuje vztah mezi řádkem v tabulce Ordersa řád

kem v tabulce Customers.

V relačních databázích jsou k dispozici tři základní druhy vztahů. Rozdělují se podle

počtu prvků na každé straně vztahu. Vztahy můžou být jeden-na-jednoho,jeden-na

-mnoho a mnoho-na-mnoho.

Vztah jeden-na-jednoho znamená, že na každé straně se může nacházet jeden záznam.

Když například oddělíte adresy a zákazníky do samostatných tabulek, můžete mezi nimi

mít vztah jeden-na-jednoho. Cizí klíč byste mohli umístit buď do tabulky Addresses nebo

do tabulky Customers (v obou být nemusí).

Ve vztahu jeden-na-mnoho může patřit k řádku z první tabulky libovolný počet řádků

z druhé tabulky. Například jeden zákazník může odeslat více objednávek. V takovémpří

padě tabulka, která má více řádků (Orders), bude obsahovat cizí klíč, který budeodkazo

vat na řádek druhé tabulky (Customers). Proto jste umístili cizí klíč CustomerID do tabulky

Customers.

Ve vztahu mnoha-na-mnoho se více řádků z první tabulky hlásí k více řádkům z druhé

tabulky. Předpokládejte kupříkladu, že máte dvě tabulky, Books (knihy) a Authors (autoři).

Běžně se stává, že jednu knihu napíše více spoluautorů, případně že jeden autor napíše více

knih, ať už sám, nebo jako spoluautor. Tento typ vztahu vyžaduje samostatnou tabulku,

takže byste měli tabulky Books, Authors a Books_Authors. Tato třetí tabulka budeobsaho

vat jen klíče ze zbývajících dvou tabulek – tj. dvojice cizích klíčů, které říkají, jací autoři

napsali jaké knihy.

Navrhování webové databáze

Poznat, že potřebujete novou třídu a jakou by měla mít klíč, je tak trochu umění. Můžete

si přečíst hromadu materiálů o ERD diagramech a normalizaci databází. Tato témata jsou

však nad rámec této knihy. Většinou si vystačíte s několika základními principy návrhu,

o nichž se naučíte na příkladu obchodu Book-O-Rama.

Představujte si skutečné objekty,

které se snažíte modelovat

Když vytváříte databázi, obvykle modelujete skutečné objekty a vztahy, abyste o nich

mohli ukládat informace.

Každá třída objektů, kterou modelujete, potřebuje svou vlastní tabulku. Můžete si topřed

stavit takto: chcete ukládat stejné informace o všech zákaznících. Pokud skupiny dat mají

stejný „tvar“, můžete pro ně vytvořit odpovídající tabulku.


240 KAPITOLA 8  NAVRHUJEME WEBOVOU DATABÁZI

V obchodu Book-O-Rama budete chtít ukládat informace o zákaznících, o knihách, které

prodáváte a o objednávkách. Všichni zákazníci se nějak jmenují a někde bydlí. Každá

objednávka má datum, celkovou cenu a skupinu objednaných knih. Každá kniha má číslo

ISBN, autora, název a cenu.

Potřebujete tudíž alespoň tři tabulky v této databázi – Customers, Orders a Books. Tento

základ schématu si můžete prohlédnout na obrázku 8.3.

Obrázek 8.3. Základ schématu se skládá z tabulek Customers, Orders a Books

Ze současného modelu nemůžete určit, které knihy patří do dané objednávky. Tutositu

aci vyřešíte za chvíli.

CustomerID

Customers

1

2

3

Name

Jana Nováková

Aleš Světlý

Michal Starý

Address

Dubová 25

Kopřivová 47

Severní 357

City

Pelhřimov

Horní Bečva

Pustiměř

OrderID

Orders

1

2

3

4

CustomerID

3

1

2

3

Amount

27.50

12.99

74.00

6.99

Date

02-Apr--2007

15-Apr-2007

19-Apr-2007

01-May-2007

ISBN

Books

9788025137505

9788025147375

9788025141960

Author Title Price

Ondřej Baše

Timothy Boronczyk

Callum Hopkins

jQuery pro neprogramátory

MySQL Okamžitě

PHP Okamžitě

424

212

212


241

8

Navrhujeme

webovou databázi

NAVRHOVÁNÍ WEBOVÉ DATABÁZE

Neukládejte redundantní data

Dříve jsme si položili otázku: „Co nám brání, abychom uložili adresu Jany Novákové do

tabulky Orders?“

Kdyby si Jana Nováková objednávala z obchodu Book-O-Rama častěji, ukládali bychom

její adresu opakovaně. Tabulka Orders by nakonec mohla vypadat jako na obrázku 8.4.

Obrázek 8.4. Návrh databáze vede k ukládání redundantních dat, která zbytečně zabírají

diskový prostor a můžou způsobovat různé problémy

Takový návrh s sebou nese dva problémy:

 Plýtvá diskovým prostorem. Proč ukládat údaje o Janě čtyřikrát, když je stačíulo

žit jednou?

 Může vést k aktualizačním anomáliím – to jsou situace, kdy změna v databázi skončí

nekonzistentními daty. Jakmile dojde k narušení integrity dat, už nemůžete určit,

která data jsou správná, a která nikoliv. To obvykle vede ke ztrátě dat.

Měli byste se vyhýbat třem aktualizačním anomáliím: anomáliím úprav, vkládání a mazání.

Kdyby se Jana přestěhovala v době, kdy bude mít nevyřízené objednávky, museli byste

měnit její adresu na čtyřech místech současně – to je čtyřnásobné množství práce. Kdybyste

ignorovali tuto skutečnost a změnili její adresu jen na jediném místě, měli bystenekon

zistentní data v databázi (to je velmi špatná věc). Tyto problémy se označují anomálie

úprav, protože nastávají při úpravách záznamů.

S tímto návrhem musíte vkládat Janiny osobní údaje, kdykoliv si něco objedná. Vždy

musíte zajišťovat, aby její údaje zůstaly konzistentní s již uloženými daty. Kdybyste to

neudělali, skončili byste s konfliktními informacemi o Janě. Například jeden řádek by

tvrdil, že Jana žije v Pelhřimově, kdežto druhý řádek by tvrdil, že žije v Humpolci. Tuto

situaci nazýváme anomálií vkládání, jelikož vzniká při vkládání záznamů.

Třetí typ anomálie se označuje jako anomálie mazání, protože nastává, když mažete

záznamy z databáze. Představte si kupříkladu, že po odeslání objednávky zákazníkovi

ji budete chtít vymazat. Jakmile byste vyřídili všechny Janiny objednávky, zmizely by

z tabulky Orders. To by znamenalo, že už neznáte nadále Janinu adresu. Nemůžete jiposí

lat speciální nabídky, a až si bude chtít příště objednat, bude muset vyplňovat všechny

osobní údaje znovu.

OrderID

12

13

14

15

Amount

4987.50

1075.00

399.99

594.00

Date

25-Apr-2007

29-Apr-2007

30-Apr-2007

01-May-2007

CustomerID

1

1

1

1

Name

Jana Nováková

Jana Nováková

Jana Nováková

Jana Nováková

Address

Dubová 25

Dubová 25

Dubová 25

Dubová 25

City

Pelhřimov

Pelhřimov

Pelhřimov

Pelhřimov


242 KAPITOLA 8  NAVRHUJEME WEBOVOU DATABÁZI

Databáze byste měli navrhovat tak, aby k těmto anomáliím nedocházelo.

Používejte atomické hodnoty sloupců

Používat atomické hodnoty sloupců znamená ukládat do každého sloupce každého řádku

jen jedinou informaci. Kdybyste kupříkladu chtěli vědět, z jakých knih se objednávka

skládá, mohli byste to udělat mnoha způsoby.

Jedním řešením by bylo přidat do tabulky Objednavky sloupec se všemi objednanýmikni

hami, jak lze vidět na obrázku 8.5.

Obrázek 8.5. S tímto návrhem by sloupec Books Ordered obsahoval více hodnot

Toto řešení není dobrým nápadem z mnoha důvodů. Ve skutečnost vkládáte celou tabulku

do jednoho sloupce – tabulku, která by měla spojovat objednávky s knihami. Kdyžvytvá

říte podobné sloupce, je složitější odpovídat na otázky typu: „Kolik kopií knihy jQuery

pro neprogramátory si zákazníci objednali?“ Systém nemůže jednoduše spočítatodpoví

dající záznamy. Místo toho je nutné parsovat hodnoty ve sloupcích, abyste mohliporov

návat jejich obsah.

Protože ve skutečnosti vytváříte tabulku v tabulce, měli byste raději vytvořit samostatnou

tabulku. Tuto novou tabulku můžete pojmenovat například Order_Items (viz obrázek 8.6).

Obrázek 8.6. Tento návrh usnadňuje hledání objednaných knih

Tato tabulka vytváří vazby mezi tabulkami Orders a Books. Takový typ tabulkyreprezen

tuje vztah mnoho-na-mnoho mezi dvěma objekty – jedna objednávka se může skládat

z více knih a jedna kniha může být součástí více objednávek.

OrderID

1

2

3

4

Orders

CustomerID

3

1

2

3

Amount

687.50

325.00

1850.00

175.00

Date

02-Apr-2007

15-Apr-2007

19-Apr-2007

01-May-2007

Books Ordered

9788025137505

9788025147375, 9788025141960

9788025137505

9788025147375, 9788025141960, 9788025137505

OrderID

Order_Items

1

2

2

3

4

4

4

ISBN Quantity

9788025137505

9788025147375

9788025141960

9788025137505

9788025147375

9788025141960

9788025137505

1

2

1

1

1

2

1


243

8

Navrhujeme

webovou databázi

NAVRHOVÁNÍ WEBOVÉ DATABÁZE

Jestliže máte řešit problém, který skutečně vyžaduje neatomické hodnoty sloupců, měli

byste zvážit výběr databáze pro tento typ dat namísto relační databáze. Jedná se o tzv.

nerelační databáze, databáze NoSQL nebo datová úložiště. (Databázemi NoSQL se však

tato kniha nezabývá.)

Vybírejte smysluplné klíče

Ujistěte se, že vybíráte klíče, které jsou jedinečné. V tomto případě jste vytvořili speciální

klíče pro zákazníky (CustomerID) a objednávky (OrderID), protože tyto objekty skutečného

světa nemusí mít identifikátory, které jsou zaručeně jedinečné. Nemusíte ale vytvářetjedi

nečný identifikátor pro knihy, protože ten už existuje – jedná se o kód ISBN. Do tabulky

Order_Items byste mohli doplnit další klíč, kdybyste chtěli, ale kombinace sloupců OrderID

a ISBN je jedinečná, dokud pracujete s více kopiemi stejné knihy v objednávce jakos jed

ním záznamem. Tabulka Order_Items obsahuje sloupec Quantity právě z tohoto důvodu.

Přemýšlejte, na co se chcete dotazovat databáze

Popřemýšlejte, na jaké otázky by měla vaše databáze odpovídat. Například, které knihy

se v obchodě Book-O-Rama prodávají nejlépe? Nezapomeňte, že vaše databáze by měla

obsahovat všechna nezbytná data a že k získání odpovědí můžete používat i vztahy mezi

tabulkami.

Vyhýbejte se návrhům s mnoha prázdnými sloupci

Kdybyste chtěli přidat recenze knihy do vaší databáze, mohli byste to udělatpřinejmen

ším dvěma způsoby. Oba můžete vidět na obrázku 8.7.

Obrázek 8.7. Recenze knih je možné doplnit přidáním sloupce Review do tabulky Books

nebo přidáním samostatné tabulky pro recenze

ISBN

Books

9788025137505

9788025147375

9788025141960

Author Title Price

Ondřej Baše

Timothy Boronczyk

Callum Hopkins

jQuery pro neprogramátory

MySQL Okamžitě

PHP Okamžitě

424

212

212

Review

ISBN

Books_Reviews

Review


244 KAPITOLA 8  NAVRHUJEME WEBOVOU DATABÁZI

První řešení spočívá v přidání sloupce Review do tabulky Books. Tímto způsobem získají

všechny knihy sloupec Review. Pokud máte v databázi spoustu knih a recenzent jeneplánuje recenzovat všechny, spousta řádků nebude mít hodnotu v tomto poli. Ve skutečnosti

ale bude mít hodnotu NULL.

Mít spoustu hodnot NULL v databázi není rozumné. Plýtváte tak diskovým prostorem

a způsobuje to problémy se součty a jinými funkcemi pro číselné sloupce. Když uživatel

uvidí hodnotu NULL v tabulce, neví, jestli je tento sloupec irelevantní, databáze obsahuje

chybu nebo zatím nikdo tato data nezadal.

Problémům s mnoha hodnotami NULL se můžete vyhnout, když navrhnete svou databázi

jinak. V tomto případě byste mohli zvolit druhý návrh z obrázku 8.7. V tabulce Book_

Reviews jsou uvedené pouze knihy s recenzemi.

Zapamatujte si, že první návrh předpokládal, že máte recenzenta, který nebude psát více

recenzí pro jedinou knihu – tj. mezi knihami a recenzemi existuje vztah jeden-na-jednoho.

Druhý návrh umožňuje psát více recenzí ke stejné knize – tj. mezi knihami a recenzemi je

vztah jeden-na-mnoho. Pokud si vystačíte s jednou recenzí na knihu, můžete u druhého

návrhu udělat primární klíč ze sloupce ISBN v tabulce Book_Reviews. Kdybyste chtěli mít více

recenzí jedné knihy, měli byste zavést ještě nový jedinečný identifikátor do této tabulky.

Přehled typů tabulek

Často zjistíte, že váš návrh tabulek dopadne tak, že bude obsahovat dva typy tabulek:

 Jednoduché tabulky popisující reálné objekty. Mohou také obsahovat cizí klíčeodkazující na další jednoduché objekty, s nimiž jsou ve vztahu jeden-na-jednoho nebo

jeden-na-mnoho. Například – zákazník může mít více objednávek, ale objednávku

může vytvořit jediný zákazník. Proto vkládáte odkaz na zákazníka do objednávky.

 Spojovací tabulky, které popisují vztahy mnoho-na-mnoho mezi dvěma reálnými

objekty, jako jsou kupříkladu vztahy mezi objednávkami a knihami. Tyto tabulky

většinou odpovídají nějakému typu transakcí skutečného světa. Architektura webové databáze Když už známe interní architekturu databáze, můžeme se zaměřit na externí architekturu webového databázového systému a ukázat si, jak vyvíjet takový systém. Obrázek 8.8 popisuje základní operace webového serveru. Celý systém se skládá ze dvou objektů – webového prohlížeče a webového serveru. Mezi nimi je nezbytnákomunikační linka. Webový prohlížeč odesílá požadavek serveru. Server posílá zpět odpověď. Tato architektura vyhovuje skvěle serveru, který prezentuje statické stránky. Architektura s webovými stránkami postavenými na databázi je o něco složitější.


245

8

Navrhujeme

webovou databázi

ARCHITEKTURA WEBOVÉ DATABÁZE

Obrázek 8.8. Vztah klient-server mezi webovým prohlížečem a webovým serverem

vyžaduje komunikační spojení

Webové aplikace s databází, s nimiž se setkáte v této knize, se řídí běžnou strukturou

webové databáze, kterou můžete vidět na obrázku 8.9. Převážnou část této struktury

byste měli už znát.

Obrázek 8.9. Vztah klient-server mezi webovým prohlížečem a webovým serverem vyžaduje

komunikační spojení

Typická transakce webové databáze má níže uvedené fáze, které jsou očíslované na obrázku

8.9. Tyto fáze si popíšeme na příkladu obchodu Book-O-Rama:

 Webový prohlížeč uživatele odesílá požadavek HTTP pro určitou webovou stránku.

Například uživatel si může skrze webový formulář vyžádat vyhledání všech knih,

které napsala Laura Thomson. Stránka s výsledky hledání se jmenuje results.php.

 Webový server přijímá požadavek na stránku results.php, načítá tento soubora pře

dává ho jádru PHP ke zpracování.

 Jádro PHP začíná parsovat tento skript. Uvnitř tohoto skriptu se nachází příkazy

pro připojení k databázi a pro provedení dotazu (vyhledávajícího knihy). Interpret

PHP otevírá spojení se serverem MySQL a posílá mu tento dotaz.

 Server MySQL přijímá tento dotaz do databáze, zpracovává ho a odesílá výsledky

(seznam knih) zpět jádru PHP.

 Jádro PHP dokončí provádění skriptu, který většinou formátuje výsledky dotazu

do kódu HTML. Potom vrací výsledný kód jazyka HTML webovému serveru.

 Webový server posílá tento kód HTML zpět webovému prohlížeči, v němž siuži

vatel může prohlédnout seznam vyhledaných knih.

Tento proces zůstává stejný, ať používáte jakékoliv skriptovací jádro nebo databázový

server. Někdy běží webový server, jádro PHP a databázový server na jediném stroji. Není

ale ani neobvyklé, aby databázový server běžel na jiném stroji. Může tomu tak být kvůli

vyšší bezpečnosti, vyšší kapacitě nebo rozdělování zátěže. Z pohledu vývoje se ale tento

proces nemění, mění se jen jeho efektivita.

Jak bude vaše aplikace narůstat, začnete ji rozdělovat do vrstev – obvykle se jednáo databá

zovou vrstvu pro komunikaci s databází, vrstvu řídicí logiky, která představuje jádro aplikace,

Prohlížeč Webový server

Požadavek

Odpověď

Prohlížeč Webový server

1

6

Jádro PHP

2

5

Server MySQL

3

4


246 KAPITOLA 8  NAVRHUJEME WEBOVOU DATABÁZI

a prezentační vrstvu, která se stará o generování výstupu. Základní architektura z obrázku 8.9

zůstává i v tomto případě zachována – pouze lépe strukturujete kód jazyka PHP.

Další zdroje

V této kapitole jste se seznámili s návrhem relačních databází. Pokud chcete vícepro

niknout do teorie relačních databází, zkuste si přečíst knihy od nějakého relačního guru,

například od C.J. Data. Měli byste však vědět, že jeho knihy můžou být značně teoretické

a jejich praktický přínos pro webového vývojáře nemusí být přímočarý. Běžná webová

databáze není příliš složitá.

Co bude dál

V příští kapitole vytvoříte databázi MySQL. Nejprve se naučíte, jak ji nakonfigurovat pro

web a jak se do ní dotazovat, a potom také to, jak se dotazovat z jazyka PHP.




       
Knihkupectví Knihy.ABZ.cz - online prodej | ABZ Knihy, a.s.
ABZ knihy, a.s.
 
 
 

Knihy.ABZ.cz - knihkupectví online -  © 2004-2018 - ABZ ABZ knihy, a.s. TOPlist