MySQL 16 - tvorba databázového systému

Dnešní díl je tak trochu na přání, ukázalo se, že by bylo vhodně si projít komplexní tvorbu nového databázového systému jako celku pro web, podíváme se tedy na naši seznamku z pohledu řešení od definice systému přes analytickou část požadavků a návrh struktury a architektury systému až po její dokončení.

Co se to děje?:)

Dnes jsme se původně měli začít zabývat vývojem další kompletní aplikace v jednoduchém podání, ale z diskuse u minulého článku vyplynulo, že by bylo záhodno trošku si ucelit principy konstrukce kompletních aplikací nad rámec pouhé definice a popisu tabulek a funkčnosti systému. Proto se dnes budeme zabývat všemi aspekty vývoje aplikace jeden po druhém. Na úvod jenom dodám, že pracujeme stále se základními SQL znalostmi, které by si případný nový čtenář mohl doplnit v předcházejícím seriálu o základech MySQL na Živě.

Seznam našich úkonů při vývoji WWW aplikace

Pokud budeme tvořit běžnou webovou aplikaci, založenou na modelu skriptovacího jazyka a databázového systému, měli bychom dodržovat alespoň rámcově tyto fáze:

  1. Definice problému a přesná specifikace zadání.
  2. Analýza všech požadavků.
  3. Návrh struktury a architektury aplikace.
  4. Tvorba základního kódu a sestavení aplikace.
  5. Odladění a testování aplikace.
  6. Implementace celého produktu.

Důležité je úvodem vyzdvihnout, že žádnou z vývojových fázi systému nelze odbýt nebo vynechat pokud chceme vytvořit kvalitní produkt. Nyní se začneme jednotlivými kroky vývoje naší Seznamky zabývat po jednom.

Definice problému a přesná specifikace zadání

Ač se to může zdát přehnané, nejdůležitější části při budování našeho projektu musí být jeho přesná specifikace. Je nezbytně nutné vědět, jakou aplikaci máme vyvinout, co má umět, jak bude provozována. Musíme si při jejím zadávání od zákazníka, nebo nás samých, přesně určit jak má co fungovat.

Není možné vyvinout seznamku pro nevidomé uživatele a nezaměřit se na ošetření čitelnosti textu pro speciální čtecí programy, které se řídí strukturou HTML dokumentu naprosto striktně a výsledně nějakým způsobem myslím čtou psaný text dle jeho písmenek. Taktéž u seznamky musíme brát v potaz celý systém a jeho části i jako celek a srovnat si správně rovinu uživatelů, funkcí systému a zároveň i všech možností, které jsou po nás vyžadovány.

Máme vytvořit stránku s odpověďmi na inzeráty, nebo bez nich? Máme tam mít vyhledávání? A kde by mělo přibližně být, co by mělo vyhledávat a poskytovat jako výsledek hledání, jaká data budeme archivovat o každém uživateli systému a takto bychom mohli položit nespočetně mnoho otázek. A je to nutné! Protože pokud si správně nespecifikujeme zadání systému, budou náklady na vývoj aplikace úměrně narůstat spolu se změnami, které budeme muset provádět, pokud si něco předem nevyjasníme správně a efektivita vývoje systému pak nebude určitě optimální – kdo by chtěl 4x přepisovat základní části seznamky jenom proto, že si nedokázal zjistit přesně potřebné informace pro vývoj a dozvěděl se je až při prezentaci výsledného produktu …

Když tedy budeme tvořit nový projekt, začneme rozhodně s obecným popisem naší služby a na tom pak začneme stavět dál. Pokud totiž vše správně na začátku popíšeme, můžeme to srovnat dále s požadavky získané analýzou systému. Naším cílem dnes bude vyvinout WWW aplikaci, díky níž budou zákazníci moci podávat své inzeráty na internet a zároveň budou moci odpovídat na inzeráty jiné.

Analýza systému

Tím, že si zjistíme všechny požadavky na nový systém, si ujasníme podobu výsledné aplikace – co by měla umět. Je potřeba zajistit si, aby uživatel při importu například firemních výrobků do databáze používal ty správná data, resp. abychom my správně tyto data zpracovávali a neměli databázi pro trošku odlišný systém zboží – například můžeme vynechat omylem číselný kód u zboží v samoobsluze a problém je na světě. Přitom je to důležitá položka pro místní pokladny. Také je důležité umět správně ověřit platnost přijímaných dat - počet znaků a tvar řetězce popř. typ hodnot, jenž jsou odesílány.

Uvedeme si tedy příklad provedení seznamu požadavků, které jsou na nás při vývoji systému kladeny z hlediska jeho výsledné podoby – lehce z nich poznáme charakter konečného produktu a můžeme začít navrhovat konkrétní řešení a náročnost aplikace – například bude fungovat na Linuxovém serveru formou spolupráce Apache, PHP a MySQL a půjde o hardwarově nenáročnou záležitost. Tedy k naší seznamce:

  1. Pracovat se systémem může pouze registrovaný zákazník.
  2. Před všemi úkony se musí zákazník přihlásit do systému.
  3. Zákazník může publikovat inzeráty, ty se uloží do databáze a potvrdí se jejich přijetí na email zákazníka.
  4. Zákazník může odpovídat na inzeráty jiných zákazníků, tyto odpovědi se uloží do databáze a zákazník spolu s tím osloveným dostanou potvrzující zprávu o odpovědi na inzerát s jejím textem a kontaktem na autora na jejich emaily.
  5. Zákazník může hledat v inzerátech dle všech parametrů.

Návrh struktury a architektury aplikace

Řekněme, že všechny požadavky již máme pěkně přes sebou zpracovány a víme všechny detaily potřebné k návrhu struktury systému, jsme v době návrhu. Nyní je opravdu důležité pečlivě všechny požadavky zpracovat a nachystat si model struktury databáze systému a celého oběhu dat na WWW serveru, proto si nejprve připravíme návrh naší webové aplikace postupovým diagramem:

Vidíme, že je kladen důraz především na nutnost zaregistrovat se do systému, jinak s ním nemůžeme nijak pracovat. Základním kamenem naší aplikace bude databáze, proto si ji nyní navrhneme:

Návrh databáze

Databázi je nutné navrhnout taky, aby byla pružná vůči novým požadavkům a zároveň výkonná – to se odráží v rychlosti zpracování na webu. Aplikačními objekty tedy budou v našem případě tyto objekty:

  1. Registrovaní zákazníci.
  2. Inzeráty.
  3. Odpovědi na inzeráty.

Všimněme si, že s odpověďmi na inzeráty zatím neoperujeme, ale jsou ukládány do tabulky – v budoucnu bychom mohli chtít přidat výpis uživateli jeho inzerátů a odpovědí na ně na hlavní stránce systému po zalogování. Nyní je důležité definovat si datový typ každého pole tabulek:

seznamka_zakaznici

Pole tabulky Datový typ
IDZakaznika Integer, NOT NULL, PRIMARY KEY, AUTO_INCREMENT
Jmeno Varchar(20), NOT NULL
Prijmeni Varchar(25), NOT NULL
Adresa Varchar(75), NOT NULL
Mesto Varchar(35), NOT NULL
PSC Varchar(15), NOT NULL
Vek Integer
Pohlavi Muž, Žena, Nezadáno
Oci Varchar(25), NOT NULL
Vlasy Varchar(25), NOT NULL
Zajmy Varchar(50), NOT NULL
Zamestnani Varchar(50), NOT NULL
Kurak Ano, Ne, Neznámo

seznamka_inzeraty

Pole tabulky Datový typ
IDInzeratu Integer, NOT NULL, PRIMARY KEY, AUTO_INCREMENT
IDZakaznika Integer, NOT NULL
TextInzeratu Text, NOT NULL
Datum DATETIME, NOT NULL

seznamka_odpovedi 

Pole tabulky Datový typ
IDOdpovedi Integer, NOT NULL, PRIMARY KEY, AUTO_INCREMENT
IDInzeratu Integer, NOT NULL
IDZakaznika Integer, NOT NULL
Text Text, NOT NULL
Datum DATETIME, NOT NULL

Jak vidíte, doplnili jsme rovnou k aplikačním objektům do tabulek i klíče a můžeme se vrhnout na normalizaci tabulek a definici vztahů mezi tabulkami.

Normalizace tabulek

Máme tedy v tabulce zákazníků položku IDZakaznika. To označuje každý uživatelský účet a tento klíč je jedinečný. Obdobně jsme zpracovali i ID u ostatních tabulek a poté jsme tabulky navzájem provázali – u inzerátu je potřeba vědět, kdo ho zadal, u odpovědi na který inzerát odpovídáme a kdo na něj odpovídá. Protože máme pokročile normalizované tabulky, můžeme si dovolit zachovat stávající jednoduchý návrh. Vrhneme se rovnou na definici relací mezi tabulkami. Mezi tabulkami zákazníků a inzerátů a také zákazníků a odpovědí je relace typu 1:N. Vytvořili bychom je následujícími skripty:

CREATE TABLE seznamka_zakaznici(
IDZakaznika INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
Jmeno Varchar(20) NOT NULL,
Prijmeni Varchar(25) NOT NULL,
Mesto Varchar(35) NOT NULL,
PSC Varchar(15) NOT NULL,
Vek INT,
Pohlavi ENUM(“Muž”,”Žena”,”Nezadáno”),
Oci Varchar(25) NOT NULL,
Vlasy Varchar(25) NOT NULL,
Zajmy Varchar(50) NOT NULL,
Zamestnani Varchar(50) NOT NULL,
Kurak ENUM(“Ano”,”Ne”,”Neznámo”));

CREATE TABLE seznamka_inzeraty(
IDInzeratu INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
IDZakaznika INT NOT NULL,
TextInzeratu Text NOT NULL,
Datum DATETIME NOT NULL);

CREATE TABLE seznamka_odpovedi(
IDOdpovedi INT NOT NULL AUTO_INCREMENT PRIMARY KEY
IDInzeratu INT NOT NULL,
IDZakaznika INT NOT NULL,
TextInzeratu Text NOT NULL,
Datum DATETIME NOT NULL);

Takovéto příkazy se dají použít přímo pro tvorbu tabulek, pokud bychom je museli znovu tvořit.

Zabezpečení

Poslední kapitolou před tvorbou samotných skriptů je zabezpečení databázového serveru. Podívejme se v následujícím přehledu, jaké práva by měli mít jednotliví uživatelé našeho systému:

Uživatel Tabulky Privilegia
Nový zákazník seznamka_zakaznici INSERT
Registrovaní zákazníci seznamka_zakaznici SELECT, UPDATE
seznamka_inzeraty SELECT, INSERT, UPDATE, DELETE
seznamka_odpovedi SELECT, UPDATE, UPDATE
Obsluha seznamky vše FULL

Tvorba základního kódu a sestavení aplikace

Při tvorbě našich skriptů bychom neměli mít při dobré znalosti programovacího jazyka, který zvolíme, mnoho problému s realizací navrhnutého systému. My se mu zde již dnes nebudeme věnovat, protože hlavní náplní tohoto seriálu je nastínění rutin práce s MySQL. Naopak bychom si po otestování naší aplikace (známá je poučka, že absolutní laik nám v systému nalezne neočekávané mouchy:) které my, jako programátoři při korektním užívání systému neodhalíme) měli být její funkčností jisti a s klidem ji uvést na web.

V dalším díle …

… opět nahlédneme do praxe práce se systémem MySQL!

Diskuze (19) Další článek: Napster úplně končí

Témata článku: , , , , , , , , , , , , , , , , , , , , ,