Návrh a implementace IS nad databázovým strojem

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

Návrh a implementace IS nad databázovým strojem

Bakalářská práce

Autor:

Filip Hermann Informační technologie, manažer projektů IS

Vedoucí práce:

Praha

Ing. Michal Valenta, Ph.D.

Duben 2011

Prohlášení: Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze, dne 20.4.2011

Filip Hermann

Poděkování Rád bych poděkoval vedoucímu práce Ing. Michalu Valentovi, Ph.D. za konzultace a cenné připomínky.

Anotace Kapitoly této práce odpovídají životnímu cyklu nově vyvíjeného systému pro internetový obchod. Po specifikaci funkčních a nefunkčních požadavků jsou stručně zhodnoceny existující alternativy řešení. Následuje kapitola zabývající se analýzou problémové domény. Konceptuální model, který je jejím hlavním výstupem, je základem pro kapitolu pojednávající o vlastním návrhu řešení. Obsahuje charakteristiku použité třívrstvé architektury včetně detailního popisu jednotlivých vrstev. Základem datové vrstvy je relační model, aplikační vrstva je uložena přímo v databázovém stroji. Životní cyklus software se uzavírá kapitolami o implementaci, v nichž je rozebrána použitá cílová platforma, a nasazení, která dává obraz o konečné podobě systému. Klíčová slova: informační systém, databáze, internetový obchod, životní cyklus

Annotation Chapters of this thesis correspond to the life cycle of the newly developed system for internet shopping. Existing alternatives are evaluated after the specification of functional and non-functional requirements. The following chapter deals with the analysis of the problem domain. Its main output, the conceptual model, is the basis for the chapter dealing with the design of the solution. It contains characteristics of the three-level architecture being used including a detailed description of the separate layers. The data layer is based on the relational model, the application layer is stored in the database engine. The software life cycle ends up with chapters about implementation, describing the target platform, and the final release, providing a picture of the overall system layout. Keywords: information system, database, internet shop, life cycle

Obsah 1 Úvod..................................................................................................................................8 2 Vize projektu.....................................................................................................................8 2.1 Katalog požadavků....................................................................................................9 2.1.1 Funkční požadavky............................................................................................9 2.1.2 Nefunkční požadavky......................................................................................10 3 Alternativy řešení.............................................................................................................11 3.1 osCommerce............................................................................................................11 3.2 Magento...................................................................................................................12 3.3 Vlastní řešení...........................................................................................................13 4 Analýza požadavků..........................................................................................................13 4.1 Případy užití (use cases)..........................................................................................14 4.1.1 Aktér „Zákazník“.............................................................................................14 4.1.2 Aktéři „Správci systému“.................................................................................15 4.1.2.1 Správce produktů.....................................................................................15 4.1.2.2 Správce skladu.........................................................................................16 4.1.2.3 Správce objednávek..................................................................................17 4.1.2.4 Správce uživatelů.....................................................................................19 4.2 Konceptuální model.................................................................................................20 4.2.1 Analytické třídy................................................................................................20 4.2.1.1 Obchodní partneři.....................................................................................20 4.2.1.2 Správa produktů.......................................................................................21 4.2.1.3 Správa skladu...........................................................................................23 4.2.1.4 Správa objednávek...................................................................................23 4.2.1.5 Správa uživatelů.......................................................................................24 5

5 Návrh...............................................................................................................................25 5.1 Architektura.............................................................................................................25 5.2 Datová vrstva...........................................................................................................26 5.2.1 Jmenné konvence.............................................................................................26 5.2.2 Použité techniky...............................................................................................27 5.2.2.1 Hierarchie.................................................................................................27 5.2.2.2 Vícejazyčnost...........................................................................................28 5.2.2.3 Sledování změn........................................................................................28 5.2.2.4 Notifikace a dokumenty...........................................................................29 5.2.2.5 Integrita dat..............................................................................................30 5.2.2.6 Normalizace schématu.............................................................................30 5.2.3 Relační model..................................................................................................31 5.2.3.1 Obchodní partneři.....................................................................................31 5.2.3.2 Evidence produktů...................................................................................32 5.2.3.3 Evidence stavu skladu..............................................................................33 5.2.3.4 Evidence objednávek................................................................................33 5.2.3.5 Evidence uživatelů...................................................................................35 5.3 Aplikační vrstva.......................................................................................................35 5.3.1 Řízení přístupu.................................................................................................35 5.3.1.1 Přístup na úrovni databáze.......................................................................36 5.3.1.2 Přístup na programové úrovni..................................................................36 5.3.2 Rozhraní aplikační vrstvy................................................................................37 5.3.2.1 Základní funkce........................................................................................37 5.3.2.2 Rozhraní pro správu obchodních partnerů...............................................38 5.3.2.3 Rozhraní pro přístup k produktům...........................................................38

6

5.3.2.4 Rozhraní pro správu skladu......................................................................40 5.3.2.5 Rozhraní pro správu objednávek..............................................................40 5.3.2.6 Rozhraní pro správu uživatelů..................................................................41 5.4 Prezentační vrstva....................................................................................................41 5.4.1 Zákaznické uživatelské rozhraní......................................................................41 5.4.2 Administrátorské uživatelské rozhraní.............................................................42 6 Implementace..................................................................................................................43 6.1 Volba implementační platformy...............................................................................43 6.1.1 Databázový stroj..............................................................................................43 6.1.1.1 MySQL.....................................................................................................44 6.1.1.2 PostgreSQL..............................................................................................44 6.1.2 Webový server..................................................................................................45 6.1.3 Webové rozhraní..............................................................................................45 6.1.4 Aplikace pro správu dat...................................................................................45 7 Nasazení..........................................................................................................................46 8 Závěry a doporučení........................................................................................................48 Seznam použité literatury....................................................................................................49 Tištěná literatura.............................................................................................................49 Elektronické zdroje.........................................................................................................49

7

1 Úvod S problematikou informačních systémů nad databázovým strojem se běžně setkávají analytici, vývojáři i uživatelé širokého spektra aplikací navržených pro nejrůznější oblasti lidského konání. Mnozí z nás ve svém zaměstnání využívají moderní ERP systémy, ve školách studentské IS a doma pak najrůznější aplikace a nástroje pro vyhledávání, nákup a prodej produktů či služeb, encyklopedie, sociální sítě, atd. Společným jmenovatelem těchto aplikací je inteligentní správa velkého množství dat pomocí moderních databázových technologií. Vzhledem ke svému praktickému zaměření jsem se rozhodl přiblížit problematiku návrhu a implementace IS nad databázovým strojem prostřednictvím projektu, který jsem realizoval pro společnost Barad-Dur, s.r.o. Cílem byl návrh a implementace eshopu s aplikační logikou na straně databáze a podporou pro více jazyků, sledování stavu objednávek, šablon, … Specifické požadavky zadavatele na funkcionalitu systému znemožnily nasazení některého z existujících řešení a zároveň otevřely řadu zajímavých problémů. Věřím, že právě díky nim budou následující kapitoly přínosem i pro ty, kteří problematiku systémů pro elektronický obchod důvěrně znají.

2 Vize projektu V rámci rozšiřování obchodních aktivit firmy bylo nutné navrhnout a implementovat systém pro online prodej šperků dodávaných tuzemskými i zahraničními výrobci. Klíčovým heslem při specifikaci požadavků nového systému byla flexibilita. Strategie zadavatele počítala s jednotnou datovou základnou pro více obchodů specializovaných na prodej v různých zemích. Oddělené domény jednotlivých eshopů umožňují efektivnější optimalizaci pro vyhledávací nástroje (Grappone/Cousin, 2006) a vzhledem k prodávanému sortimentu i nasazení různých cenových strategií. Společná datová základna na druhé straně zjednodušuje účetnictví, reporting i celkovou správu produktů a objednávek. Vzhledem k firemní organizaci zadavatele, kdy jedna část pracovníků působí na různých místech České republiky a druhá část v SRN, bylo dále nutné navrhnout takový systém, který umožní paralelní práci z různých lokací a v různých jazycích, s interaktivním uživatelským rozhraním, jež automaticky reflektuje změny dat v databázi. Dalším 8

klíčovým bodem bylo detailní sledování pohybu produktů mezi jednotlivými pracovišti a cílovými zákazníky. Následující kapitola přináší seznam požadavků na navrhovaný systém v úrovni detailu potřebné pro analýzu existujících řešení. Jejich hlubší rozbor bude následovat v kapitole 4 .

2.1 Katalog požadavků Požadavky na navrhovaný systém lze rozdělit do dvou základních skupin. Funkční požadavky popisují funkcionalitu systému na základě případů užití (use cases), nefunkční požadavky souvisejí s celkovou architekturou (použitelností, bezpečností, výkonem, atd.).

2.1.1 Funkční požadavky FP1 - vkládání, modifikace a odstraňování výrobců a dodavatelů nabízeného zboží (jméno, adresa, atd.) FP2 - vytvoření hierarchie produktových kategorií; vícejazyčnost FP3 - vkládání, modifikace a odstraňování produků; vícejazyčnost FP4 - kategorizace produktů (přiřazování produktů do jedné či více kategorií); možnost omezení nabízeného zboží pro jednotlivé obchody (na úrovni kategorií i jednotlivých produktů) FP5 - podpora automaticky generovaných (dynamických) kategorií (např. „nejprodávanější“, „nové produkty“, „výprodej“, atd.) FP6 - přiřazování atributů k produktům (rozměry, hmotnost, barva, atd); možnost definice libovolného počtu atributů FP7 - definování relací mezi produkty; možnost definice libovolného počtu typů relací (např. „produkt je doplňkem k jinému produktu“, „produkt je alternativou k jinému produktu“, atd.) FP8 - vkládání, modifikace a odstraňování produktových variant FP9 - možnost nastavení stavu nabízeného produktu („aktivní“, „neaktivní“, „doprodej“) FP10 - možnost vkládání různých cen téhož produktu (např. „velkoobchodní“, „maloobchodní“); cenová historie; podpora různých měn; automatické kurzové přepočty FP11 - evidence skladových pohybů FP12 - podpora sledování pohybu zboží mezi různými sklady

9

FP13 - automatické generování skladových pohybů v závislosti na změně stavu objednávky FP14 - vytváření, úprava a mazání objednávek (informace o zákazníkovi, seznam produktů, způsob platby, atd.) FP15 - možnost rozdělení objednávky (pro případ, že ji nelze vyřídit najednou) FP16 - evidence a úprava stavu objednávky; možnost definice libovolného počtu stavů objednávky („nová“, „zaplacená“, „odeslaná“, atd.) včetně pravidel pro kontrolu integritních omezení souvisejících s posloupností stavů (např. stav „platba vrácena“ může následovat pouze po „zaplacená“) FP17 - podpora různých platebních systémů a zásilkových metod v závislosti na cílové zemi FP18 - automatické generování účetních dokumentů (dodacích listů, faktur, dobrobisů) a uživatelských notifikací (např. o změně stavu objednávky); šablony a vícejazyčnost FP19 - evidence finančních toků (přijaté a vydané faktury) pro potřeby analýzy ziskovosti; výstupy pro účetnictví FP20 - možnost registrace zákazníků (nepovinné pro vytvoření objednávky) FP21 - generování a tisk výstupních sestav (skladové pohyby, produkty, atd.) FP22 - podpora generování a tisku čárových kódů pro produktové a adresové štítky FP23 - kontrola odesílaného zboží pomocí skenování produktových štítků FP24 - podpora uživatelských rolí s definovatelnými právy FP25 - automatická obnova uživatelského rozhraní spravcovské aplikace na základě změn dat v databázi (např. při vytvoření nové objednávky)

2.1.2 Nefunkční požadavky NP1 - náklady na provoz a údržbu systému musí být co nejmenší NP2 - systém musí být provozovatelný na stávající infrastruktuře firmy (server s OS Linux, pracovní stanice s Windows Vista) NP3 - řešení musí v dostatečné míře zaručovat bezpečnost (zejména osobních) dat NP4 - systém musí být v souladu s legislativou ČR (např. zákon o účetnictví) NP5 - ovládání systému musí být natolik intuitivní, aby základní správu produktů a objednávek zvládl i uživatel se základní znalostí práce s PC

10

3 Alternativy řešení Vzhledem k prudkému rozvoji elektronického obchodování v minulých letech vzniklo nepřeberné množství různých řešení zabývajících se problematikou online prodeje. Kromě možnosti vyvinout požadovaný software vlastními silami nebo externí firmou („na klíč“), lze pro realizaci internetového obchodu zvolit i některé z „krabicových“ řešení. Hlavní výhodou specializovaného řešení je vytvoření systému přesně podle představ zadavatele. Bývá však zpravidla vykoupena podstatně vyšší pořizovací cenou. Na druhé straně hotové řešení, jež lze pořídit dokonce zdarma, s sebou nese riziko těžko předvídatelných problémů a dodatečných nákladů v případech, kdy je nutné chování systému vlastními silami přizpůsobit novým potřebám. Takto upravený software pak nemusí být kompatibilní s dalšími verzemi či novými moduly výrobce a počáteční finanční úspora se tak může rychle rozplynout. Vzhledem k požadavku na minimální náklady se analýza existujících řešení zaměřila zejména na software vyvíjený a dodávaný zdarma. V této kategorii lze nalézt řešení, realizovaná na bázi rozšiřujících modulů pro populární CMS 1 systémy (jako např. Drupal nebo Joomla!), a dále pak celou škálu hotových obchodů distribuovaných jako opensource. Detailní analýza všech dostupných řešení by byla neúnosně časově náročná, a proto se následující kapitoly věnují pouze dvěma populárním systémům, porovnávaným na blogu TemplateMonster (eCommerce Wars, 2010).

3.1 osCommerce Systém osCommerce je distribuován pod GPL 2 licencí, jeho vývoj byl zahájen v březnu 2000 a využívá jej více než 12000 registrovaných obchodů (osCommerce, 2011). Patří tak k nejstarším open-source řešením podporovaným širokou komunitou vývojářů a uživatelů. Je založeno na databázi MySQL v kombinaci se skriptovacím jazykem PHP a obsahuje veškerou funkcionalitu nutnou pro provoz online obchodu: •

libovolné množství produktů a kategorií

•

vícejazyčnost a podpora různých měn a daní

1 „Content Management System“ - systém pro editaci a správu obsahu 2 „General Public License“ - licence umožňující svobodné sdílení a úpravu software

11

•

newslettery a možnost kontaktovat zákazníky emailem

•

rychlé i rozšířené vyhledávání produktů

•

hodnocení produktů zákazníky

•

volitelné produktové atributy

•

podpora různých platebních systémů a zásilkových služeb

OsCommerce je poměrně snadno a rychle použitelný, v poslední době však zastarává a jeho vývoj nejde kupředu takovým tempem jako u jeho konkurentů. V neposlední řadě stojí jistě za zmínku, že na jeho bázi byla v minulosti vyvinuta řada dalších řešení, z nichž nejznámější jsou zřejmě systémy ZenCart a CRE Loaded.

3.2 Magento Magento je rychle se rozvíjející platforma pro elektronický obchod vyvíjená firmou Varien od roku 2007. I Magento spoléhá na osvědčenou kombinaci databáze MySQL a skriptovacího jazyka PHP. Zájemce o toto řešení si může zvolit jednu ze tří základních edicí: „enterprise“, „professional“ nebo „community“, přičemž pod open-source licencí je distribuována pouze poslední z nich. Magento vyniká výborným uživatelským rozhraním a širokým spektrem funkcí (Magento, 2011): •

možnost správy více obchodů z jedné administrační aplikace, sdílení informací mezi různými obchody

•

rozsáhlé možnosti konfigurace produktů, jejich atributů, kategorií a cen, import/export produktů

•

optimalizace pro vyhledávače a podpora pro analýzu a reporting návštěvnosti

•

vícejazyčnost a podpora různých měn a daní

•

nástroje a volby pro podporu prodeje, newslettery, hlasování

•

nepovinná registrace zákazníků, možnost spravovat zákaznický účet

•

podpora různých platebních systémů a zásilkových služeb

12

Díky větší komplexitě Magenta je jeho instalace a přizpůsobení vzhledu poněkud složitější. Zároveň i nároky na výkon a konfiguraci serveru jsou vyšší než například u výše zmiňovaného osCommerce.

Obrázek 1 (Správa produktů v Magento CE) Zdroj: http://demo-admin.magentocommerce.com

3.3 Vlastní řešení Zejména open-source systém Magento splňuje celou řadu výše zmiňovaných požadavků. V době rozhodování o způsobu řešení však existoval (obzvláště na českém trhu) teprve krátce a neodpovídal některým specifickým potřebám zadavatele. Řešení internetového obchodu bylo proto realizováno vlastními silami.

4 Analýza požadavků Násladující kapitola se zabývá analýzou problémové domény. Požadavky, specifikované v předchozích kapitolách, budou promítnuty do případů užití a dále pak do entit a vazeb v konceptuálním modelu. 13

4.1 Případy užití (use cases) Případy užití identifikují aktéry a popisují jejich interakci se systémem. Diagram případů užití ilustruje globální kompetence jednotlivých aktérů vůči systému jako celku a byl sestaven s ohledem na jednoduchost a přehlednost doporučovanou odborníky na UML (Arlow/Neustadt, 2005 a Fowler, 2004).

Obrázek 2 (Diagram případů užití) Zdroj: vlastní

4.1.1 Aktér „Zákazník“ Základním posláním systému pro online obchod je prodej zboží prostřednictvím objednávek odeslaných zákazníkem prostřednictvím internetu. Zákazník se tak stává aktérem a objednání zboží klíčovým případem užití. Jedním z požadavků na funkcionalitu systému je i možnost registrace zákazníka, která je volitelnou součástí scénáře vytvoření objednávky. Scénář nákupu 1) prohlížení sortimentu produktů 14

2) vložení zboží do košíku a případný návrat k bodu 1) 3) registrace zákazníka (volitelně) 4) vyplnění doručovací a fakturační adresy 5) výběr zásilkové služby a způsobu platby v závislosti na zvolené cílové zemi 6) odsouhlasení obchodních podmínek 7) v případě platby kartou přesměrování na příslušný platební systém (viz. požadavek FP17); v případě dobírky dodatečné potvrzení objednávky

4.1.2 Aktéři „Správci systému“ Řada dalších případů užití se týká správy dat (produktů, objednávek, dodavatelů, atd.) prostřednictvím dalších aktérů – správců systému. Vytvoření oddělených správcovských rolí souvisí s požadavkem na řízený přístup k datům (viz. požadavek FP24) a jejich zabezpečení. Pracovník v roli správce produktů například nemůže manipulovat s objednávkami, správce objedávek nemůže manipulovat s daty o pohybech zboží, atd. V organizaci zadavatele pracovníci v různých geografických lokacích zastávají různé správcovské role.

4.1.2.1 Správce produktů Příkladem jedné z administrátorských rolí je „Správce produktů“, jehož základní kompetencí je správa sortimentu prodávaného zboží. Vedle elementárních údajů o produktu (název, popis) musí systém umožňovat zadávat následující údaje: •

Kategorie – systém musí podporovat hiararchické rozdělení produktů pomocí volně definovatelných kategorií (viz. požadavek FP4). Každý produkt může být zařazen do libovolného počtu kategorií.

•

Produktové atributy – systém musí umožňovat definování libovolných typů atributů přiřaditelných jednotlivým produktům (viz. požadavek FP6). Příkladem typu atributu může být „hmotnost“, konkrétní hodnotou tohoto atributu pak „100g“.

15

•

Produktové relace – systém musí umožňovat definování libovolných typů relací mezi produkty (viz. požadavek FP7). Příkladem typu relace může být „doplňkový produkt“, který je v případě obchodu prodávajícího šperky použitý např. pro spojení náhrdelníku se stylově odpovídajícím náramkem. Smyslem produktových relací je motivovat zákazníka k dalšímu nákupu.

•

Produktové varianty – produkty lišící se pouze zvoleným atributem (např. barvou) jsou produktovými variantami. Každý produkt může obsahovat libovolné množství variant (viz. požadavek FP8).

•

Stav produktu – stavem produktu se rozumí způsob nabízení daného produktu na stránkách obchodu. Produkty ve stavu „aktivní“ jsou pro zákazníka viditelné, „neaktivní“ jsou mu skryty. Zvláštním případem je stav „doprodej“, který automaticky zajišťuje nabízení produktu pouze do vyčerpání jeho skladových zásob (viz. požadavek FP9).

•

Ceny produktu – systém musí podporovat různé typy cen a uchovávat cenovou historii produktu (viz. požadavek FP10).

Vzhledem k tomu, že důležitou vlastností každého produktu je i informace o jeho výrobci a dodavatelích, spadá správa těchto dat rovněž do kompetence produktového správce.

4.1.2.2 Správce skladu Protože systém musí poskytovat i funkcionalitu pro evidenci stavu skladu, je vhodné definovat i roli zodpovědnou za správu skladových pohybů. Jedním ze základních skladových pohybů je nákup zboží na sklad, s nímž souvisejí i faktury přijaté od dodavatelů. Proto i správa těchto účetních dokladů spadá do kompetence správce skladu. Termínem „skladový pohyb“ se rozumí každý záznam o fyzickém přesunu zboží. Jeho atributy jsou typ pohybu, čas a počet skladových jednotek, ke kterým se pohyb vztahuje (viz. požadavek FP11). Časová posloupnost těchto pohybů dává přesný obraz o pohybu prodávaného zboží. Souhrn všech skladových pohybů konkrétního produktu zároveň vypovídá o aktuálním stavu jeho skladových zásob. Systém musí rozlišovat tyto základní typy skladových pohybů:

16

•

Nákup – reprezentuje operaci nakoupení zboží na sklad.

•

Prodej – reprezentuje prodej zboží cílovému zákazníkovi.

•

Vrácení – reprezentuje vrácení zboží do skladu po neúspěšném ukončení objednávky (zrušení objednávky, vrácení zboží zákazníkem nebo doručovací službou).

•

Vyřazení – odpovídá odpisu (poškozeného) zboží.

•

Přesun – eviduje přesun zboží mezi různými pracovišti (sklady) firmy.

•

Inventura – tento pohyb by měl být využíván pouze ve zcela výjimečných případech, kdy fyzická inventura skladu odhalí rozdíly mezi skutečným a evidovaným stavem a zároveň není možné dohledat a korigovat příčinu takového rozdílu. Tento pohyb umožňuje „umělé“ sladění fyzického stavu skladu s jeho evidencí.

Správce skladu má oprávnění k manipulaci se skladovými pohyby. Vedle manuálního zadávání skladových pohybů musí systém podporovat i jejich automatické generování na základě změny stavu objednávky (viz. požadavek FP13). Je zřejmé, že některé změny stavu objednávky (např. „Platba na cestě“) na stav skladu nemají žádný vliv. Jiné (např. „Odeslaná“) stav skladu snižují a další pak (např. „Vrácená“) stav skladu zvyšují.

4.1.2.3 Správce objednávek Za příjem, správu a vyřizování objednávek je zodpovědná role „Správce objednávek“. Objednávky odeslané prostřednictvím internetu, stejně jako objednávky přijaté telefonicky, se správci zobrazují v aplikaci, pomocí níž může vkládat a upravovat kontaktní a fakturační údaje, editovat seznam a množství objednávaného zboží, rozdělovat objednávky, které nelze vyřídit najednou, a v neposlední řadě měnit stav objednávek. Stav objednávky reflektuje vývoj objednávky v jejím životním cyklu. Systém musí brát v úvahu zákazníkem zvolený způsob platby a umožnit pouze odpovídající přechody mezi stavy (viz. požadavek FP16). Pro objednávky odesílané dobírkou je nezbytné, aby zákazník svou objednávku závazně potvrdil. Při platbě předem se takovým potvrzením 17

stává vlastní zaplacení zboží. Pro zpracovávání plateb kreditními kartami jsou využívány platební brány třetích stran. Po zaplacení kreditní kartou je stav objednávky nastaven na „Platba na cestě“. V případě, že je platba úspěšně ověřena a zpracována (tento proces může trvat i několik dní), je stav objednávky nastaven na „Platba potvrzena“. Pokud z nějakého důvodu transakce nebyla úspěšná, je stav nastaven na „Platba neplatná“. Systém musí dále umožňovat zrušení celé objednávky v případě, že se ji zákazník rozhodne stornovat (resp. refundovat platbu předem). Samozřejmostí musí být i možnost vrácení objednávky zákazníkem či přepravní službou (např. v případě, že cílová adresa nebyla nalezena). Následující stavový diagram zobrazuje životní cyklus objednávky v závislosti na zvoleném způsobu platby. Pro větší přehlednost byly záměrně vynechány některé extrémní případy jako např. ztráta, či nalezení ztracené zásilky:

Obrázek 3 (Životní cyklus objednávky) Zdroj: vlastní

Typickým scénářem, souvisejícím se zpracováním objednávky, je její odeslání pracovníkem v roli správce objednávek. Vedle funkčních požadavků analyzovaných výše musí systém podporovat automatické generování příslušných účetních dokumentů 18

dodacích listů, faktur, dobropisů a emailových notifikací (viz. požadavek FP18). Podobně jako automaticky generované skladové pohyby popsané v kapitole 4.1.2.2 jsou i generované dokumenty a notifikace závislé na typu aktuálního stavu objednávky. Celý proces začíná vyhledáním a otevřením nevyřízené objednávky. Následně správce objednávek provede kontrolu typů a množství produktů obsažených v objednávce pomocí skenování čárových kódů, které jsou umístěny na každém uskladněném produktu (viz. požadavek FP23), a vytiskne dodací list a adresové štítky na obal zásilky. Po předání zásilky zvolené doručovací službě správce objednávek nastaví stav objednávky na „Odesláno“. Systém na základě této události automaticky vygeneruje notifikaci o změně stavu objednávky, fakturu (obojí je formou elektronické zprávy zasláno zakazníkovi) a příslušné skladové pohyby.

Obrázek 4 (Diagram průběhu zpracování objednávky) Zdroj: vlastní

4.1.2.4 Správce uživatelů Pod pojmem „uživatel“ se rozumí jakákoliv osoba interagující se systémem. Uživateli jsou tedy všichni aktéři zmiňovaní v předchozích případech užití – zákazníci a správci. Role 19

správce uživatelů je zodpovědná za registraci a rušení uživatelů a především pak za definování jejich uživatelských oprávnění. Grafické rozhraní systému musí správci poskytnout veškeré prostředky pro manipulaci s uživatelskými účty.

4.2 Konceptuální model Konceptuální model systému se skládá z analytických tříd a příslušných vazeb mezi nimi. Zdrojem pro hledání analytických tříd jsou uživatelké požadavky a případy užití popsané výše. Diagram konceptuálního modelu je k dispozici v příloze č. 1. Úroveň detailu byla záměrně zvolena tak, aby obsahoval pouze základní analytické třídy přímo související s celkovým fungováním systému.

4.2.1 Analytické třídy Analytické třídy reprezentují datové entity modelovaného systému a jsou základem pro návrh relačního modelu, který bude jedním z hlavních výstupů návrhu řešení.

4.2.1.1 Obchodní partneři Kromě zákazníků hrají pro provoz obchodu podstatnou roli i jeho obchodní parteři. Mezi ně patří především výrobci a dodavatelé prodávaného zboží a dále pak poskytovatelé služeb. Základní nakupovanou službou je přeprava zásilek zákazníkům, pro provoz obchodu jsou však zpravidla nutné i další služby (telefon, pronájem obchodních prostor, atd.). Společným rysem obchodních partnerů je generování nákladů na straně provozovatele obchodu. Ačkoliv posláním navrhovaného řešení v žádném případě není suplování účetního systému, pro analýzu ziskovosti je evidence nákladů nezbytná. Hodnota a spolehlivost takové analýzy je přímo úměrná přesnosti a úplnosti vložených údajů (viz. požadavek FP19). Analytická třída „Partner“ je předkem pro třídy specializované na jednotlivé typy obchodních partnerů. Ve světě datového modelování jde o tzv. „ISA hierarchii“ 3. Třída „Dodavatel“

Obchodní záměr počítá s nákupem zboží od dodavatelů a jejich následným prodejem v online obchodu. Atributy této třídy proto obsahují základní informace o dodavateli (název 3 ISA – z angl. „is a“. Odvozené entity (podtypy) dědí atributy a vztahy nadřazené entity (nadtypu). Vždy jde pouze o jednonásobnou dědičnost.

20

firmy, adresa, atd.). Dodavatelé prodávají zboží provozovateli obchodu (na sklad) a vystavují mu faktury, které jsou vztaženy k příslušným skladovým pohybům (typu „Nákup“). Všechny skladové pohyby vztažené ke konkrétní faktuře proto kompletně popisují jednu nákupní objednávku u dodavatele. Třída „Dodavatel“ má vztah k třídě „Výrobce“ (dodavatel produktů daného výrobce). Třída „Výrobce“

Tato třída umožňuje evidovat a prezentovat informace o výrobcích u nabízených produktů (viz. požadavek FP1). „Výrobce“ je v přímém vztahu k třídě „Produkt“. Třída „Přepravce“

Pro doručení objednávek zákazníkovi jsou zpravidla využívány služby externích přepravců. Instance této třídy reprezentují doručovací služby, ze kterých může zákazník při konfiguraci své objednávky volit. Konkrétní přepravce může nabízet více různých služeb, které jsou v konceptuálním modelu reprezentovány třídou „Způsob přepravy“. Podstatným atributem této třídy je informace o její dostupnosti, která je zpravidla závislá na cílové zemi.

4.2.1.2 Správa produktů Řada analytických tříd souvisí s vlastním předmětem prodeje v navrhovaném systému – s produkty a jejich cenami, kategoriemi, produktovými atributy, atd. Třída „Produkt“

Instance třídy „Produkt“ reprezentuje položku sortimentu prodávaného zboží. Vedle jednoznačného identifikátoru musí každá instance nutně obsahovat atributy „název“ (pro označení produktu výrobcem) a „popis“. Třída „Stav produktu“

Stav každého produktu se může v čase měnit. Po vložení do databáze je produkt typicky ve stavu „neaktivní“ do doby, než je kompletně připraven k prodeji (vyfotografován, popsán, atd.). Během prodeje je produkt „aktivní“, tj. viditelný na webové stránce obchodu. V případě, že produkt nebude v budoucnu součástí nabízeného sortimentu, produktový správce nastaví jeho stav na „doprodej“. Produkt je pak automaticky zobrazován pouze do

21

vyčerpání skladových zásob. Protože systém musí rozlišovat mezi různými typy zákazníků (např. maloobchod, velkoobchod), je nezbytné, aby i stav produktu byl specifický pro daný typ zákazníka. Třída „Varianta produktu“

Varianta produktu je specializovanou verzí daného produktu a v konceptuálním modelu je proto znázorněna jako potomek třídy „Produkt“. Varianty produktů se liší klíčovým produktovým atributem. Třída „Kategorie“

Pro potřeby kategorizace sortimentu musí existovat třída, jejíž každá instance reprezentuje jednu z produktových kategorií (viz. požadavek FP2). Atribut „jméno“ slouží k uložení názvu kategorie. Každá kategorie může obsahovat libovolné množství produktů a zároveň každý produkt může být zařazen do libovolného počtu kategorií. Kromě této vazby má třída „Kategorie“ i vazbu sama na sebe umožňující vytváření hierarchií (každá instance obsahuje informaci o rodičovské kategorii). Třída „Atribut produktu“

V závislosti na typu produktu musí systém poskytovat možnost libovolně definovat další produktové atributy. Příkladem produktového atributu může být „rozměr“ či „hmotnost“. Každá instance této třídy v sobě musí logicky obsahovat informaci o typu a hodnotě daného produktového atributu (viz. atributy „typ“ a „hodnota“). Třída „Cena produktu“

Důvodem, proč cena není prostým atributem třídy „Produkt“, je požadavek na podporu různých typů cen (např. „velkoobchodní“, „maloobchodní“), různých měn a dále pak požadavek na cenovou historii. Z těchto důvodu je nutná existence separátní třídy, jejíž každá instance udává cenu produktu v daném okamžiku. Základními atributy této třídy proto musí být „typ“, „čas“, „cena“ a „měna“. Třída „Cena produktu“ má vztah k třídě „Produkt“, přičemž platí, že každý produkt může mít vazbu na libovolný počet instancí třídy „Cena produktu“. Množina instancí stejného typu (tj. se shodným atributem „typ“) pro daný produkt tvoří jeho cenovou historii.

22

Produktová relace

Jedním z požadavků na funkcionalitu systému je možnost definování vztahů mezi produkty a jejich variantami (viz. požadavek FP7). Třída „Produkt“ má v konceptuálním modelu proto vazbu sama na sebe. Podstatným atributem této vazby je „typ“, určující o jakou relaci jde (např. „alternativní produkt“). Každý produkt může mít libovolný počet relací (daného typu) k ostatním produktům.

4.2.1.3 Správa skladu Základním požadavkem pro správu skladu je sledování skladových pohybů tak, aby systém mohl kdykoliv poskytnout informaci o aktuálním stavu skladových zásob. Třída „Sklad“

Řešení musí umožňovat sledování pohybu produktů mezi různými sklady (viz. požadavek FP12). Tato třída umožňuje evidenci skladových míst a jejím základním atributem je „adresa“ udávající polohu skladu. Třída „Skladový pohyb“

Každá instance této třídy reprezentuje informaci o pohybu určitého typu zboží v daném okamžiku. Podstatnými atributy této třídy jsou „typ“, „čas“, „množství“ a „jednotková cena“. Atribut „typ“ určuje, o jaký typ pohybu zboží jde (např. „Nákup“ nebo „Prodej“), „čas“ obsahuje informaci o okamžiku, kdy k pohybu došlo, „množství“ specifikuje, jakého objemu produktu se pohyb týká, a „jednotková cena“ udává cenu připadající na jednotku produktu (typicky na jeden kus). Tato třída má vazbu na třídu „Produkt“ a na třídu „Sklad“. Suma pohybů vztahujících se k danému produktu dává obraz o aktuálním stavu jeho zásob.

4.2.1.4 Správa objednávek Systém musí spravovat informace o objednávkách odeslaných zákazníky obchodu, poskytovat kompletní přehled o jejich životním cyklu a aktuálním stavu. Třída „Objednávka“

Každá instance této třídy reprezentuje jednu objednávku. Její atributy obsahují kontaktní údaje zákazníka, doručovací a fakturační adresu a volitelně i jeho daňové identifikační číslo. Podstatnou součást každé objednávky tvoří seznam a množství objednaných

23

produktů. Třída má proto v konceptuálním modelu vazbu na třídu „Produkt“. Klíčové atributy této vazby představují množství a jednotkovou cenu objednávaného produktu. Volitelná vazba na třídu „Zákazník“ souvisí s požadavkem na možnost registrace zákazníků. Objednávka odeslaná registrovaným zákazníkem obsahuje referenci na příslušného zákazníka. Jedním z požadavků byla i možnost rozdělit objednávku, kterou nelze vyřídit najednou. Z tohoto důvodu třída „Objednávka“ obsahuje i vazbu sama na sebe, která umožňuje vytváření hierarchie objednávek. Třída „Stav objednávky“

Každá instance této třídy reprezentuje stav objednávky v daném časovém okamžiku a obsahuje vazbu na příslušnou objednávku. Časově seřazená sekvence těchto instancí dává kompletní obraz o životním cyklu objednávky. Povinnými atributy jsou „čas“, obsahující informaci o okamžiku, ve kterém ke změně stavu došlo, a „typ“ jednoznačně identifikující nový stav objednávky (např. „Odeslaná“, „Vrácená“, atd.). Třída „Faktura“

Systém automaticky generuje a odesílá faktury zákazníkovi v závislosti na aktuálním stavu objednávky a zvoleném způsobu platby (viz. požadavek FP18). Třída „Faktura“ je zodpovědná za evidenci těchto daňových dokladů a každá její instance je svázána s konkrétní platbou. Vedle faktur vydaných, souvisejících s vlastním prodejem zboží cílovým zákazníkům, systém eviduje i faktury přijaté. Zdrojem přijatých faktur jsou obchodní partneři provozovatele obchodu – dodavatelé zboží a poskytovatelé doručovacích služeb. Při nákupu zboží na sklad obsahují proto příslušné skladové pohyby informaci o přijaté faktuře. Stejně tak i změny stavu objednávky, reprezentující odeslání zboží zvolenou zásilkovou službou, obsahují referenci na příslušný daňový doklad. Atributy této třídy jsou dány účetními předpisy a patří mezi ně například „datum vystavení“, „celková částka“, či informace o použité sazbě daně z přidané hodnoty.

4.2.1.5 Správa uživatelů Analytické třídy popsané v této kapitole souvisejí s potřebou správy informací o uživatelích a jejich oprávněních. 24

Třída „Uživatel“

Každý uživatel systému (zákazník, správce) je reprezentován právě jednou instancí této třídy. Atributy třídy „Uživatel“ obsahují data společná pro všechny typy uživatelů, především údaje potřebné k přihlášení do systému (viz. požadavek FP24). Tato třída je zároveň rodičovskou třídou pro odvozené třídy specializované na určitý typ uživatelů (např. „Zákazník“). Třída „Oprávnění“

Systém musí umožňovat přiřazování uživatelských oprávnění jednotlivým uživatelům. Každá instance třídy „Uživatel“ proto obsahuje seznam uživatelských oprávnění, která mu byla správcem přidělena. Třída „Uživatel“ je rodičovskou třídou pro všechny odvozené typy uživatelů, a proto platí, že i mechanismus přidělování uživatelských práv je společný všem aktérům. Základním atributem je „typ“, který jednoznačně identifikuje a popisuje oprávnění přiřazené uživateli.

5 Návrh Návrh řešení vychází z analýzy požadavků provedené v předchozích kapitolách. Využívá základního principu moderních softwarových architektur, kterým je rozdělení systému do více vrstev (Qin/Xing/Zheng, 2008).

5.1 Architektura Vzhledem k povaze a rozsahu řešeného problému byla zvolena třívrstvá architektura s logicky oddělenou datovou, aplikační a prezentační vrstvou. U vícevrstvých architektur je každá vrstva zodpovědná za řešení určité části problému a vystavuje jasně definované rozhraní pro komunikaci se sousedními vrstvami. Nejinak je tomu i v případě navrhovaného řešení. Logické vrstvení však neimplikuje fyzickou stavbu systému - datová a aplikační vrstva je v tomto návrhu hostována stejnou fyzickou částí – databázovým strojem. Následující diagram zobrazuje komponenty systému a jejich příslušnost k jednotlivým vrstvám navrhovaného řešení:

25

Obrázek 5 (Diagram komponent a vrstev) Zdroj: vlastní

5.2 Datová vrstva Srdcem navrhovaného systému je objektově-relační databáze, jejíž struktura je dána relačním modelem. Jeho návrh vychází z uživatelských požadavků analyzovaných v předchozím textu, především pak z konceptuálního modelu. Analytické třídy v řadě případů přímo vedou k návrhu příslušných datových tabulek. Kromě nich obsahuje relační model i veškeré vazby a integritní omezení vztahující se k uloženým datům. Jazykem pro definici struktury databáze (tzv. “data definition language“) je SQL, respektive podmnožina jeho příkazů určených pro definici databázových struktur.

5.2.1 Jmenné konvence Pro případné nasazení navrhovaného řešení v budoucích projektech byla pro pojmenovávání entit v relačním modelu zvolena angličtina. Prefixy ve jménech databázových objektů navíc umožňují provoz v databázi sdílené s dalšími projekty 26

(typicky v prostředích web hostingových společností). Návrh modelu dále dodržuje následující konvence: •

Přípona „DEF“ - identifikuje tabulku obsahující pevné definice ovlivňující chování vybrané části systému. Změny v jejich obsahu mají konfigurační charakter. Příkladem takové tabulky je „ESHOP_PRODUCT_CATEGORY_DEF“ obsahující názvy produktových kategorií. Tabulky tohoto typu budou v dále označovány jako „číselníky“.

•

Sloupec „id“ - zejména pro potřeby automatizovaného sledování změn dat v databázi (viz. požadavek FP25) každá tabulka obsahuje sloupec „id“, který je zároveň jejím primárním klíčem. Datový typ tohoto sloupce je ve všech tabulkách stejný.

•

Sloupec „update_time“ - hodnota tohoto sloupce reprezentuje čas změny dané věty a rovněž souvisí se sledováním změn dat v databázi. Návrh počítá s automatickým nastavením této hodnoty pomocí triggerů.

•

Sloupec „translated“ - sloupce s tímto názvem se vyskytují v číselnících a vždy slouží k označení vybrané věty pro potřeby její následné identifikace (typicky funkcemi aplikační vrstvy). Návrh se záměrně vyhýbá použití sloupce „id“, kterému je vyhrazena výhradně role „technického“ identifikátoru většinou generovaného automaticky. Při migraci nebo slučování databází se může hodnota identifikátoru

„id“

měnit,

přičemž

hodnota

logického

(„přeloženého“)

identifikátoru „translated“ zůstává spolehlivě neměnná. Na tomto sloupci je vždy definován unikátní klíč, hodnota však může být i prázdná (NULL).

5.2.2 Použité techniky Během návrhu bylo nutné vyřešit některé opakující se problémy. Řešení použité v jednom kontextu bylo zpravidla použito vícekrát a tyto principy budou proto osvětleny před vlastním popisem relačního modelu.

5.2.2.1 Hierarchie Typickým problémem byla potřeba tvorby hierarchií spravovaných dat. Příkladem mohou být hierarchie produktových kategorií či hierarchie vzniklé opakovaným rozdělením 27

objednávky. V těchto případech příslušná tabulka kromě sloupce s primárním klíčem („id“) obsahuje sloupec odkazující na nadřazenou větu („parent_id“). Vzniká tak stromová struktura, v níž věty na stejné vertikální úrovni odkazují na tutéž rodičovskou větu. Původní standard dotazovacího jazyka SQL neobsahoval prostředek pro výběr vět z tabulek tohoto typu. Moderní databázové stroje často podporují klíčová slova pro formulaci takových dotazů, alternativně lze využít i rekurzivních uložených procedur. Tento způsob byl použit v navrhovaném řešení.

5.2.2.2 Vícejazyčnost Řada tabulek v relačním modelu musí uchovávat vícejazyčné texty. Jednoduchým a zároveň flexibilním řešením je využití výhod objektově-relačních databází. Příslušné sloupce nemusí nutně uchovávat pouze jednoduché texty, nýbrž i komplexní struktury. Takovou strukturou je v návrhu řešení pole textových řetězců, které umožňuje snadné přidávání dalších jazyků kdykoliv v budoucnu. Přístup k textu ve zvolené jazykové mutaci probíhá přes index pole (dále „jazykový index“). Je zřejmé, že jazykové indexy musí být po dobu životnosti konkrétního nasazení neměnné.

5.2.2.3 Sledování změn Základem pro sledování změn v databázi je jejich protokolování. Řada systémů generuje protokol o svém provozu ve formě souboru (tzv. log file). V případě relačních databází tuto roli může snadno zastoupit zvláštní tabulka. Pomocí standardních databázových mechanismů (triggerů) lze zajistit, že věta o změně každé sledované tabulky bude automaticky zapsána do protokolovací tabulky. Údaje v protokolovací tabulce jsou poměrně stručné a obsahují pouze následující informace: •

Identifikátor entity - identifikuje tabulku, ve které ke změně došlo.

•

Identifikátor věty - identifikuje větu v entitě (z tohoto důvodu návrh řešení počítá s výše popsanou konvencí existence sloupce „id“ v každé sledované tabulce).

•

Operace – věty v relační databázi mohou být změněny jedním ze tří způsobů (odpovídají jim příkazy jazyka SQL – INSERT, UPDATE a DELETE). Hodnota tohoto sloupce udává, o jaký typ změny jde.

28

•

Čas změny – obsahuje čas, kdy k dané změně došlo.

Z výše uvedeného je zřejmé, že vnější aktér (dále „pozorovatel“), kterým může být například automatizovaný proces, má k dispozici veškeré údaje nutné pro automatizované zpracovávání změn. V případě vložení nové věty či aktualizaci existující věty protokolovací tabulka pouze říká, že k této operaci došlo, neposkytuje ale žádnou informaci o datech v nové (resp. aktualizované) větě. Díky atributům „identifikátor věty“ a „identifikátor entity“ může pozorovatel novou (resp. aktualizovanou) větu načíst. Periodickým čtením nových vět z protokolovací tabulky a prováděním příslušných aktualizací v uživatelském rozhraní může správcovská aplikace automaticky reflektovat změny v databázi, tj. např. upozorňovat na nové objednávky a zobrazovat jejich obsah. Základní mechanismus záznamu a zejména pak vyhodnocování protokolu změn tak, jak je popsán výše, je však poněkud nepružný. Řada tabulek v relačním modelu souvisí s určitou částí problémové domény. Např. tabulka „ESHOP_PRODUCT“, která reprezentuje položky nabídky, má vazby s celou řadou dalších tabulek souvisejících s atributy produktů, relacemi mezi nimi, kategoriemi, atd. Pro odstínění pozorovatele od všech těchto implementačních detailů i pro celkové zjednodušení vyhodnocování změn počítá návrh řešení s možností definování konverzních pravidel. Konverzním pravidlem se v tomto kontextu rozumí předpis, pomocí kterého systém na základě změny jedné (podřízené) tabulky automaticky vygeneruje „umělý“ záznam o změně v tabulce jiné (nadřízené). S výše zmiňovanou tabulkou „ESHOP_PRODUCT“ souvisí například spojovací tabulka „ESHOP_PRODUCT_ATTRIBUTE“, která přiřazuje atributy jednotlivým produktům. Změna vět v této tabulce logicky souvisí s entitou „Produkt“ a příslušný konverzní předpis způsobí vygenerování protokolu o změně příslušné věty v tabulce „ESHOP_PRODUCT“ (viz. příloha č. 2). Pozorovateli, který se zabývá správou produktů, pak stačí sledovat změny týkající se entity „ESHOP_PRODUCT“.

5.2.2.4 Notifikace a dokumenty Systém musí generovat notifikace (např. o změně stavu objednávky) a dokumenty (dodací listy, faktury, dobropisy) zasílané uživateli. Pro zajištění maximální jednoduchosti a flexibility počítá navrhované řešení s jednotným přístupem ke všem dynamicky generovaným textům. Na notifikace je pohlíženo jako na typ dokumentu. I v tomto případě 29

je základem řešení využití možností moderních objektově-relačních databází, zejména jejich podpory datového typu XML, který je samotnou svojí podstatou předurčen k ukládání obsahu strukturovaných dokumentů. Vedle XML existuje další

technologie,

kterou lze pro formátování textu do výsledného dokumentu s výhodou využít. Jde o tzv. XSLT transformaci (World Wide Web Consortium, 1999), jejímž vstupem jsou soubory XML (obsah dokumentu) a soubor XSLT popisující požadovanou transformaci (výsledný formát). Celý proces je plně standardizován a lze pro něj použít libovolný XSLT procesor. Z jednoho XML souboru je tak možné vygenerovat dokumenty v nejrůznějších formátech – HTML, PDF, text, apod. Pole XSLT definic umožňuje uložení formátovacích předpisů v různých jazykových mutacích. XML spolu s XSLT je jádrem řešení požadované podpory automaticky generovaných dokumentů a jejich šablon (viz. Požadavek FP18).

5.2.2.5 Integrita dat Integrita dat je zajištěna pomocí deklarativních prostředků databázového stroje. V komplikovanějších případech, kdy zajištění integrity dat deklarativními prostředky není možné, jsou použity triggery. Jednoduchým příkladem je trigger pro kontrolu příslušnosti státu k dané zemi (viz. příloha č. 4).

5.2.2.6 Normalizace schématu Kvalita schématu relačního modelu klesá s množstvím aktualizačních anomálií, které připouští. Aktualizační anomálie jsou způsobeny funkčními závislostmi mezi atributy a jejich důsledkem jsou redundantní a obtížně udržovatelné obsahy tabulek. V tomto kontextu je proto třeba zmínit teorii normálních forem, zejména pak třetí a Boyce-Coddovu normální formu. Schéma relace je ve třetí normální formě splňuje-li druhou normální formu a neklíčové atributy jsou vzájemně nezávislé. Pro Boyce-Coddovu normální formu navíc platí, že ani žádná část složeného klíče není závislá na části jiného klíče. Prostředkem pro dosažení požadované normální formy je dekompozice (Valenta, 2011). Navrhovaný relační model v některých případech nesplňuje požadavky třetí normální formy. Tyto ústupky byly učiněny s ohledem na účelnost a použitelnost řešení. Příkladem takové relace je tabulka „ESHOP_CUSTOMER“ obsahující mimo jiné atributy „street“,

30

„city“, „zip“, „state_id“ a „country_id“, které slouží k uložení adresy registrovaného zákazníka. Je zřejmé, že např. atribut „city“ je funkčně závislý na atributech „zip“ a „country_id“ (poštovní směrovací číslo v konkrétní zemi jednoznačně určuje město). V ideálním případě by proto pro uložení měst, spadajících do oblasti směrovacího čísla v dané zemi, měla existovat zvláštní tabulka. Prakticky by však vytvoření takového číselníku obsahujícího všechna města světa bylo již vzhledem k (ne)dostupnosti příslušných informací neadekvátně náročné.

5.2.3 Relační model Vzhledem k velikosti relačního modelu se následující popis zabývá pouze jeho podstatnými částmi. Kompletní relační model je k dispozici v podobě elektronické přílohy této práce.

5.2.3.1 Obchodní partneři Analytické třídy související se správou obchodních partnerů byly logickou předlohou pro vznik příslušných databázových tabulek v relačním modelu. Tabulka „ESHOP_PARTNER“

Každá věta této tabulky odpovídá jednomu z obchodních partnerů (viz. analytická třída „Partner“) a odkazuje na ni tabulka přijatých faktur („ESHOP_BILL_IN“). Na tabulku „ESHOP_PARTNER“ dále odkazují specializované tabulky určené pro konkrétní typy obchodních partnerů. Společná tabulka pro obchodní partnery umožňuje v budoucnu snadné rozšíření systému o další dodavatele služeb. Tabulka „ESHOP_SUPPLIER“

Relační model se pro zjednodušení na výrobce dívá jako na zvláštní typ dodavatele, a proto jsou analytické třídy „Dodavatel“ a „Výrobce“ v relačním modelu sloučeny do společné tabulky. Vazba typu M:N, která je v analytickém modelu definována mezi třídou „Dodavatel“ a „Výrobce“, je v relačním modelu realizována pomocí pomocné tabulky „ESHOP_SUPPLIER_REL“ s dvojitou vazbou na tabulku „ESHOP_SUPPLIER“. Každého dodavatele je tak možné logicky spojit s libovolným počtem výrobců. Věta v tabulce „ESHOP_SUPPLIER“, pro níž nejsou definovány žádné vazby, reprezentuje výrobce. Vedlejším produktem zvoleného řešení je možnost zachytit hierarchie dodavatelů, 31

v reálném prostředí však zřejmě zůstane nevyužita, protože informace o vztazích mezi dodavateli zpravidla nejsou provozovateli obchodu dostupné.

5.2.3.2 Evidence produktů Se správou produktů souvisí řada tabulek a nejdůležitějšími z nich se zabývá tato kapitola. Tabulka „ESHOP_PRODUCT“

Tato tabulka spravuje data nabízených produktů a jejich variant (viz. analytické třídy „Produkt“ a „Varianta produktu“). Obsahuje vazbu sama na sebe, díky níž mohou věty reprezentující produktové varianty odkazovat na rodičovský produkt. Typy variant jsou definovány v tabulce „ESHOP_PRODUCT_DEF“. Typ produktového atributu, který rozlišuje jednotlivé varianty od sebe, je dán vazbou z tabulky „ESHOP_PRODUCT_DEF“ na číselník produktových atributů. Vedlejším produktem navrženého řešení je možnost vytvářet hierarchie produktových variant (jinými slovy „varianty variant“). Tabulka „ESHOP_PRODUCT_ATTRIBUTE“

Spojuje produkty a jejich atributy, jejichž jednotlivé typy jsou uloženy v číselníku „ESHOP_PRODUCT_ATTRIBUTE_DEF“ (viz. analytická třída „Atribut produktu“). Tabulka „ESHOP_PRODUCT_CATEGORY“

Spojovací tabulka pomocí které jsou produkty zařazovány do jednotlivých kategorií. Názvy

a

základní

atributy

produktových

kategorií

jsou

dány

číselníkem

„ESHOP_PRODUCT_CATEGORY_DEF“. Tabulka „ESHOP_PRODUCT_RELATION“

Pomocí této tabulky správce definuje relace mezi jednotlivými produkty. Tabulka má vztah k číselníku „ESHOP_PRODUCT_RELATION_DEF“ udávající typ relace. Tabulka „ESHOP_PRODUCT_STATUS“

Tabulka odpovídá analytické třídě „Stav produktu“ a umožňuje nastavit způsob, jakým bude produkt zobrazován na stránkách obchodu. Toto nastavení může být pro každý typ zákazníka různé, a proto obsahuje vazbu na číselník „ESHOP_CUSTOMER_DEF“ popisující jednotlivé typy zákazníků (velkoobchodní, maloobchodní, atd.). Unikátní klíč

32

(na sloupcích „product_id“ a „customer_def_id“) zaručuje existenci vždy jen jediné věty určující stav produktu pro daný typ zákazníka. Tabulka „ESHOP_PRODUCT_PRICE“

Tabulka odpovídá analytické třídě „Cena produktu“ a její věty reprezentují cenu nabízeného produktu pro daný typ zákazníka v konkrétním časovém okamžiku. Kromě uložené nominální hodnoty (atribut „price“) tabulka odkazuje na tabulku měn. Doplňkové atributy umožňují dále specifikovat, zda se jedná o akční či běžnou cenu a správce může rovněž volitelně definovat krátký text, který je zobrazován u ceny produktu (např. „vánoční sleva“, apod.).

5.2.3.3 Evidence stavu skladu Následující kapitola popisuje tabulky související s evidencí skladových zásob. Tabulka „ESHOP_STOCK“

Slouží k evidenci skladových míst a odpovídá analytické třídě „Sklad“. Tabulka „ESHOP_STOCK_OP“

Každá věta v této tabulce reprezentuje jednu skladovou operaci (viz. analytická třída „Skladový pohyb“) a obsahuje v první řadě informace o okamžiku pohybu, množství a jednotkové ceně. Vazba na tabulku „ESHOP_PRODUCT“ určuje, kterého produktu se pohyb týká. Vazba na číselník typů skladových pohybů („ESHOP_STOCK_OP_DEF“) jednoznačně popisuje typ skladového pohybu. Vazba na tabulku „ESHOP_STOCK“ určuje nové umístění produktu. Skladové pohyby, týkající se konkrétní změny stavu objednávky, jsou generovány automaticky (viz. požadavek FP13) a odkazují na příslušnou větu v tabulce „ESHOP_ORDER_STATUS“. Skladové pohyby, pro něž existuje daňový doklad (při nákupu zboží na sklad), odkazují navíc na příslušnou větu v tabulce přijatých faktur „ESHOP_BILL_IN“.

5.2.3.4 Evidence objednávek Centrálním tématem každého obchodu jsou objednávky. Následující kapitola osvětluje nejdůležitější tabulky související s jejich evidencí a správou.

33

Tabulka „ESHOP_ORDER“

Tato tabulka odpovídá analytické třídě „Objednávka“. Její sloupce souvisí s potřebou ukládat informace o doručovací a fakturační adrese, kontaktních údajích, daňovém identifikačním čísle, atd. Nepovinná vazba na tabulku „ESHOP_CUSTOMER“ umožňuje spojit objednávku s registrovaným zákazníkem. Způsob

dopravy

je

dán

„ESHOP_SHIPPING_METHOD“.

vazbou Ta

na

spravuje

tabulku podporované

zásilkových způsoby

metod

doručování

objednávek (viz. analytická třída „Způsob dopravy“) a úzce souvisí s podporovanými zásilkovými službami. Z toho plyne nepovinný vztah s tabulkou „ESHOP_PARTNER“. Tato vazba zůstává prázdná v případě osobního odběru zboží. Způsob platby je analogicky určen vztahem s tabulkou „ESHOP_PAYMENT_METHOD“. Příkladem platební metody může být „bankovní převod“, „platba kartou“, atd. Rozdělování objednávek, které nelze vyřídit najednou (viz. požadavek FP15), je snadno realizovatelné díky vazbě, kterou má tabulka „ESHOP_ORDER“ sama na sebe. Tabulka „ESHOP_ORDER_STATUS“

Klíčovým atributem objedávky je informace o jejím stavu (viz. „životní cyklus objednávky“ popsaný v kapitole 4.1.2.3 ). Za evidenci stavů objednávky je zodpovědná tabulka „ESHOP_ORDER_STATUS“. Každá její věta popisuje stav objednávky v daném časovém okamžiku. Systémem podporované stavy objednávky jsou uloženy v číselníku „ESHOP_ORDER_STATUS_DEF“, na který tabulka „ESHOP_ORDER_STATUS“ odkazuje. Tento číselník obsahuje nepovinnou vazbu sám na sebe popisující vzájemnou souvislost stavů. Příkladem je stav objednávky „Vrácená“, která vždy souvisí se stavem „Odeslaná“ (pouze odeslanou objednávku může doručovací služba vrátit). Zajímavým problémem je požadavek na kontrolu logické návaznosti časového pořadí jednotlivých stavů (viz. požadavek FP16). Návrh proto počítá s možností definovat pravidla pro platné posloupnosti objednávkových stavů. Seznam těchto pravidel je obsažen v tabulce „ESHOP_ORDER_STATUS_RULE“, která má dvojitou vazbu na číselník stavů. Pro jeden stav může existovat „n“ vět odkazujících na stavy, které po něm mohou

34

následovat. Typ pravidla (viz. vazba na „ESHOP_ORDER_STATUS_RULE_DEF“) dále určuje, zda stav musí následovat svého předchůdce bezprostředně. Z předchozího je zřejmé, že číselníky stavů objednávek a typů pravidel spolu s tabulkou seznamu pravidel umožňují libovolně konfigurovat a rozšiřovat způsob vyřizování objednávek.

5.2.3.5 Evidence uživatelů Řada tabulek souvisí s požadavkem na řízený přístup k datům. Vedle výše zmiňované tabulky pro evidenci zákazníků „ESHOP_CUSTOMER“, hraje klíčovou roli tabulka evidující všechny uživatele systému (viz. aktéři v kapitole 4.1 ). Tabulka „ESHOP_USER“

Tato tabulka odpovídá analytické třídě „Uživatel“ a je v přímém vztahu s tabulkami určenými pro specializované typy aktérů. Tabulka „ESHOP_ROLE“ Tato tabulka souvisí s řízeným přístupem k datům. Každá věta odpovídá jednomu aktérovi, resp. jedné uživatelské roli. Vztah mezi tabulkami „ESHOP_USER“ a „ESHOP_ROLE“ jednoznačně určuje roli každého jednoho uživatele. Rolím i konkrétním uživatelům lze přiřazovat oprávnění z číselníku „ESHOP_USER_PERMISSION_DEF“.

5.3 Aplikační vrstva Aplikační logika je postavena na procedurách uložených přímo v databázovém stroji. Implementace aplikační logiky co nejblíže databázovému stroji umožňuje centralizaci veškerých přístupů k datům přes jasně definované rozhraní a zároveň odděluje všechny uživatele systému od interní struktury databáze.

5.3.1 Řízení přístupu Jedním z podstatných požadavků na navrhovaný systém je řízený přístup k datům. Kvůli zvýšení celkové bezpečnosti je navržen na dvou úrovních.

35

5.3.1.1 Přístup na úrovni databáze První úroveň řízení přístupu využívá autorizačních prostředků databáze. Pro prvotní přihlášení je k dispozici pouze veřejně známé jméno a heslo databázového uživatele s minimálními právy. Tento databázový účet umožňuje pouze volání autorizační uložené procedury

„ESHOP_LOGINUSER“, přístup ke klíčovým tabulkám je však odepřen.

Pokud výše zmiňovaná přihlašovací procedura najde příslušné jméno v tabulce uživatelů a úspěšně ověří heslo, vrátí údaje o databázovému účtu odpovídajícímu příslušné roli (viz. tabulka „ESHOP_ROLE“). Klient pak může otevřít nové připojení k databázi s databázovými právy odpovídajícími jeho roli. Následný přístup k objektům je kontrolován na úrovni databázového stroje.

Obrázek 6 (Přihlášení k databázi) Zdroj: vlastní

5.3.1.2 Přístup na programové úrovni Druhá úroveň přístupu k datům je dána seznamem oprávnění přiřazených konkrétnímu uživateli (viz. tabulka „ESHOP_USER_PERMISSION“). Chování uživatelských rozhraní reflektuje tento seznam a přizpůsobuje mu dostupnost ovládacích prvků a funkcí.

36

5.3.2 Rozhraní aplikační vrstvy Procedury uložené v databázovém stroji zprostředkovávají prezentační vrstvě veškerý přístup k datům. Vzhledem k jejich velkému počtu se následující kapitola bude zabývat pouze některými z nich. Kompletní definice všech procedur jsou k dispozici v SQL skriptu, který je elektronickou přílohou této práce.

5.3.2.1 Základní funkce Aplikační vrstva obsahuje řadu funkcí, které řeší některé podstatné dílčí úlohy. Jsou často využívány ostatními částmi aplikační vrstvy a budou proto popsány na úvod. Funkce „ESHOP_GETLOCTEXT“

Jak bylo uvedeno výše, je problém vícejazyčnosti vyřešen pomocí pole textových řetězců. Funkce aplikační logiky ke sloupcům tohoto datového typu však nikdy nepřistupují přímo, nýbrž používají funkci „ESHOP_GETLOCTEXT“ vracející text ve zvoleném jazyce (tj. položku z pole odpovídající danému jazykovému indexu). V případě, že text v požadované jazykové mutaci není k dispozici, vrací funkce text ve zvoleném „standardním“ jazyce (např. angličtině). Chování systému v případě, že text v požadovaném jazyce není definován, lze snadno upravit jednoduchou změnou této funkce. Funkce „ESHOP_BUILDNTFMSG...“

V tomto případě se nejedná o jedinou funkci, nýbrž o sadu funkcí zodpovědných za generování notifikací a dokumentů. Na základě vstupních parametrů vyhledávají příslušné informace v databázi a vrací zformátovaný XML dokument s obsahem zprávy. Volající funkce tento dokument následně uloží do tabulky určené pro skladování zákaznických notifikací („ESHOP_INFORM“). Obsah této tabulky je v pravidelných intervalech analyzován a nové věty jsou odeslány zákazníkovi. Při úspěšném odeslání zprávy je do příslušné věty v této tabulce uložen aktuální čas. V opačném případě je inkrementován obsah sloupce evidujícího počet neúspěšných pokusů o odeslání a tato věta je znovu zpracována při příští analýze. Funkce „ESHOP_CONVERTPRICE“

Navrhovaný systém musí být nejen vícejazyčný, ale zároveň musí podporovat více měn a a zejména pak převody cen mezi nimi. Parametry funkce „ESHOP_CONVERTPRICE“ 37

jsou: cena, identifikátor zdrojové a cílové měny a čas. Funkce se pokusí v tabulce kurzů („ESHOP_CURRENCY_RECALC“) nalézt větu, která odpovídá zdrojové a cílové měně a zvolenému časovému okamžiku. Každá věta v této převodní tabulce obsahuje informaci o intervalu její platnosti (sloupce „valid_from“, „valid_to“) a hledaný čas musí ležet v tomto intervalu. Při změně kurzu je věta s neomezenou platností (atribut „valid_to“ je prázdný) aktualizována tak, že její platnost je ukončena aktuálním časem. Současně je přidána nová věta, s počátečním časem platnosti nastaveným na aktuální čas a s prázdnou hodnotou konce platnosti. Tabulka proto obsahuje historické kurzy a umožňuje kdykoliv zjistit, jakou hodnotu měla cena ve zvolené měně v minulosti.

5.3.2.2 Rozhraní pro správu obchodních partnerů Pro přístup a správu dat souvisejících s obchodními partnery poskytuje aplikační vrstva rozhraní realizované několika jednoduchými funkcemi. Funkce „ESHOP_SAVESUPPLIER“

Slouží pro ukládání a aktualizaci informací o dodavatelích a výrobcích. Proces ukládání začíná voláním funkce „ESHOP_SAVEPARTNER“, která nejprve uloží obecná data obchodního partnera. Následuje aktualizace dat specifických pro dodavatele a výrobce v tabulce „ESHOP_SUPPLIER“. Celý proces tak vzdáleně připomíná běžnou praxi z objektově orientovaných jazyků, kdy metoda odvozené třídy nejprve volá implementaci v rodičovské třídě, aby pak provedla další specializované operace specifické pro odvozenou třídu. Díky transakčnímu zpracování je zajištěna integrita dat v případě selhání kteréhokoliv kroku.

5.3.2.3 Rozhraní pro přístup k produktům Grafické rozhraní obchodu i správcovská aplikace potřebuje rozhraní pro přístup k datům týkajících se sortimentu nabízeného zboží. Produkty jsou zobrazovány zákazníkům, kteří je mohou vkládat do košíku a objednávat. Správce systému může vytvářet, modifikovat a mazat produkty i jejich varianty. Funkce „ESHOP_GETPRODUCTS“

Tato funkce vrací seznam produktů, které odpovídají vstupním (filtračním) parametrům. Je volána z webového rozhraní obchodu pro zobrazení seznamu produktů vybrané kategorie. 38

Jejím jádrem je cyklus vracející jednotlivé řádky výstupu. Zajímavou částí této funkce je blok související s dynamickými kategoriemi (viz. požadavek FP5). V závislosti na sloupci určujícím typ dynamické kategorie v číselníku produktových kategorií (atribut „d_type“) funkce vybírá produkty s příslušnými vlastnostmi (např. produkty s akční cenou, produkty ve výprodeji, atd.). Implementace logiky pro výběr produktů do jediné centrální funkce zajišťuje, že každá část systému vybere vždy přesně stejný seznam produktů zvolené kategorie. Toho lze s výhodou využít nejen pro uživatelské rozhraní obchodu, ale i pro další funkce jako například automatizované generování newsletterů. Funkce „ESHOP_GETPRODUCTVARIANTS“

V souvislosti s prezentací uživatelského rozhraní obchodu a s požadavkem na podporu produktových variant musí aplikační logika poskytovat metodu pro výběr variant daného produktu. Tato funkce vrací identifikátory vět, které odkazují na příslušnou nadřazenou větu v tabulce („ESHOP_PRODUCT“), a informace týkající se typu varianty. Funkce „ESHOP_GETPRODUCTDETAIL“

Uživatelské rozhraní obchodu musí zákazníkovi umožnit zobrazení detailních informací o zvoleném produktu. Funkce „ESHOP_GETPRODUCTDETAIL“ vrací informace o produktu nebo jeho variantě v závislosti na jeho primárním klíči, zvolené jazykové mutaci a typu zákazníka. Spolu s funkcí vracející seznam relací na související produkty („ESHOP_GETRELATEDPRODUCTS“) a funkcí vracející hodnotu produktového atributu daného typu („ESHOP_GETPRODUCTATTRIBUTE“) může webové rozhraní zobrazit zákazníkovi komplexní informaci o zvoleném produktu. Funkce „ESHOP_SAVEPRODUCT“

Správce systému vytváří a modifikuje produkty a jejich varianty. Tato funkce umožňuje uložení vybraného produktu. Parametry funkce obsahují veškeré nutné údaje, včetně informací o jeho atributech, relacích, stavu, ceně, atd. Zápís proto probíhá do více tabulek současně. Díky transakčnímu zpracování je zajištěno, že modifikace produktu buď proběhne úspěšně a úplně, a nebo vůbec. Chování funkce zásadním způsobem závisí na předaném parametru „id“ produktu. Pokud je tato hodnota prázdná (NULL), funkce vytvoří nový produkt, v opačném případě se pokusí aktualizovat data existujícího produktu

39

s příslušnou hodnotou identifikátoru „id“. Pokud je některý z předaných parametrů prázdný, funkce příslušnou databázovou entitu či její atribut neaktualizuje. Pro mazání produktů existuje samostatná funkce „ESHOP_DELETEPRODUCT“, která odstraní produkt s danou hodnotou primárního klíče.

5.3.2.4 Rozhraní pro správu skladu Správce systému musí mít možnost manipulovat s evidencí skladových pohybů. Aplikační logika proto poskytuje rozhraní pro čtení a zápis skladových pohybů. Funkce „ESHOP_SAVESTOCKOP“

Kromě funkce pro čtení skladových pohybů (funguje analogicky s funkcí pro čtení produktů popsanou výše) existuje funkce pro zápis skladových pohybů. Podobně jako funkce „ESHOP_SAVEPRODUCT“ ukládá tato funkce veškeré informace související s daným skladovým pohybem a využívá při tom principu transakčního zpracování. Předaný identifikátor rozhoduje o chování funkce (analogicky s funkcí pro ukládání produktů) a mazání skladových pohybů zajišťuje separátní funkce „ESHOP_DELETESTOCKOP“.

5.3.2.5 Rozhraní pro správu objednávek Objednávky jsou typicky vytvářeny zákazníkem ve webovém rozhraní obchodu. Správce musí mít možnost evidované objednávky upravovat, mazat, rozdělovat a nastavovat jejich stav. Aplikační logika proto poskytuje rozhraní pro čtení objednávek a jejich správu. Funkce „ESHOP_SAVEORDER“

Tato funkce slouží k ukládání objednávek a pracuje obdobně jako funkce pro ukládání produktů a skladových pohybů. Kromě údajů spravovaných tabulkou „ESHOP_ORDER“ jsou během procesu ukládání aktualizovány tabulky s obsahem nákupního košíku („ESHOP_ORDER_PRODUCT“)

a

zejména

pak

nový

stav

objednávky

(„ESHOP_ORDER_STATUS“). Zajímavým aspektem při ukládání nových stavů objednávky je požadavek na automatické generování účetních dokumentů a notifikací. Tuto úlohu vykonává funkce „ESHOP_NOTIFYORDERSTATUS“, která je při ukládání stavu objednávky volána. Jejím klíčovým parametrem je identifikátor („id“) stavu objednávky. Pomocí něj funkce vyhledá příslušnou větu v číselníku stavů objednávky a v případě, že tato odkazuje na definici notifikace („ESHOP_NOTIFICATION“), příslušnou 40

notifikaci vygeneruje a uloží. Díky transakčnímu zpracování je zajištěno, že notifikace vznikne jen v případě, že objednávka byla úspěšně změněna. Funkce „ESHOP_SPLITORDER“

Jedním z požadavků je možnost rozdělovat objednávky, které nelze vyřídit najednou. Funkce „ESHOP_SPLITORDER“ rozdělí objednávku podle specifikovaných požadavků (identifikátorů produktů a jejich množství). Nově vzniklé dceřinné objednávky odkazují na rodičovskou větu podle pravidel hierarchie popsaných v kapitole 5.2.2.1 .

5.3.2.6 Rozhraní pro správu uživatelů Data uživatelů systému jsou přístupná přes rozhraní popsané v této kapitole. Funkce „ESHOP_GETUSERPERMISSIONS“

Kromě funkcí pro ukládání a čtení dat uživatelů a zákazníků musí systém poskytovat prostředek pro zjištění oprávnění přiřazených danému uživateli (viz. kapitola 5.3.1.2 ). Tato funkce vrací pole „translated“ identifikátorů z číselníku uživatelských oprávnění a na základě tohoto seznamu prezentační vrstva zpřístupňuje příslušné ovládací prvky.

5.4 Prezentační vrstva Prezentační vrstva je v návrhu reprezentována uživatelským rozhraním nutným pro ovládání a užívání systému. Jejími základními složkami jsou webové rozhraní internetového obchodu a aplikace pro správu dat. Obě části komunikují se zbytkem systému přes aplikační vrstvu popsanou výše.

5.4.1 Zákaznické uživatelské rozhraní Webové rozhraní obchodu je postaveno na dynamicky generovaném obsahu na straně serveru. Každá stránka obchodu je reprezentována skriptem, který na základě vstupních parametrů posílá dotazy do aplikační vrstvy (volání uložených procedur) a jejich výsledky formátuje do výsledné HTML podoby. Důležitou vlastností navrhovaného systému je podpora různých platebních metod. V relačním modelu je jejich seznam uložen v tabulce „ESHOP_PAYMENT_METHOD“ a zpřístupňován aplikační vrstvou pomocí funkce „ESHOP_GETPAYMENTMETHODS“. Některé z platebních metod jsou realizovány pomocí platebních systémů třetích stran 41

(např. PayPal, WorldPay, 2Checkout, atd.). Každý z těchto systémů vystavuje rozhraní, pomocí kterého online obchod předá platebnímu systému údaje o zákazníkovi a obsahu jeho košíku. Platební systém pak provede vlastní zpracování celé finanční transakce a zpětně informuje obchod o jejím výsledku. Na základě této informace je stav objednávky nastaven na příslušnou hodnotu (automaticky či manuálně v závislosti na možnostech aplikačního rozhraní platebního systému) a správce objednávek zaplacené objednávky odešle. Rozhraní a chování platebních systémů je poměrně rozdílné. Ve většině případů je prohlížeč zákazníka přesměrován na adresu platebního systému, takže online obchod nemá nad dalším děním žádnou kontrolu. Pro dosažení maximální flexibility byl použit návrhový vzor „adaptér“ (Gamma/Helm/Johnson/Vlissides, 1994). Prezentační vrstva obchodu pracuje s abstraktní třídou s jednotným rozhraním pro komunikaci s platebními systémy. Implementace tohoto rozhraní ve specializovaných odvozených třídách překládají obecné rozhraní na rozhraní konkrétního platebního systému. V budoucnu lze proto sadu podporovaných platebních metod snadno rozšířit bez nutnosti zasahovat do zbývajících částí systému.

5.4.2 Administrátorské uživatelské rozhraní Pro administraci systému existuje desktopová aplikace umožňující spravovat všechny podstatné datové entity. Každý uživatel je při startu aplikace vyzván k zadání svých přihlašovacích údajů a ověřen podle pravidel popsaných v kapitole 5.3.1 . Pro každou datovou entitu aplikace poskytuje specializovanou masku, ve které může správce vytvářet, modifikovat a mazat relevantní údaje v závislosti na přiřazených uživatelských oprávněních. Zároveň je možné otevřít a paralelně pracovat s více maskami současně. Jak bylo popsáno výše, změny provedené jedním uživatelem systému se automaticky promítají do uživatelského rozhraní ostatních uživatelů. Kvůli minimalizaci chyb při balení objednávek je uživatel vybaven ručním skenerem a tiskárnou štítků. Po nastavení stavu objednávky do příslušného stavu je mu zpřístupněna možnost tisknout dokumenty, které jsou přikládány k zásilce (dodací list, faktura) a adresové štítky na obal zásilky. Před tím je však povinnen ověřit, že balené produkty odpovídají obsahu objednávky. Kontrola se provádí prostřednictvím naskenování čárových 42

kódů umístěných na každém produktu. Pouze v případě, že ověření proběhne úspěšně, jsou výše zmíněné dokumenty vytisknuty. Kromě masek pro editaci dat obsahuje aplikace i modul pro generování a tisk sestav. Správce má možnost kdykoliv vytisknout přehledy produktů, stavu skladu, faktur, atd. sestavené v závislosti na zvolených filtračních kritériích.

6 Implementace Následující kapitoly shrnují postup při implementaci výše navrženého systému.

6.1 Volba implementační platformy Podstatnou otázkou, kterou bylo nutné před vlastní implementací zodpovědět, byla volba implementační platformy. Klíčem pro hledání vhodných technologií byly zejména požadavky zadavatele a osobní zkušenosti z práce na předchozích projektech.

6.1.1 Databázový stroj Kvůli minimalizaci licenčních nákladů (viz. požadavek NP1) se výběr vhodného databázového stroje zaměřil na produkty distribuované zdarma. Další omezující kritérium představoval požadavek na provoz serverové části systému pod operačním systémem Linux (viz. požadavek NP2). Vzhledem k tomu, že jedním z úkolů systému je správa osobních dat zákazníků, představuje zajištění bezpečnosti dat úlohu s nejvyšší prioritou (viz. požadavek NP3). Zvolený databázový stroj proto musel poskytovat veškeré nutné prostředky k jejímu zajištění. Z návrhu řešení nadále vyplývá řada standardních požadavků, jako např. podpora pro definice triggerů, uložených procedur, transakční zpracování, atd. Dále je potřeba, aby databázový stroj v dostatečné míře podporoval generování XML dokumentů a jejich následné formátování pomocí XSLT transformací. Kvůli minimalizaci případných problémů s podporou a dalším vývojem databázového stroje se výběr soustředil výhradně na produkty dlouhodobě vyvíjené a užívané širokou komunitou vývojářů a uživatelů. K nim již mnoho let patří databázové stroje MySQL a PostgreSQL. Obě se těší velké oblibě u poskytovatelů webhostingových služeb, kde se staly de facto standardem, a umožňují tak případné nasazení navrhovaného systému i v těchto prostředích. 43

6.1.1.1 MySQL Kořeny MySQL sahají až do roku 1979, k databázovému stroji UNIREG, jenž vytvořil Michael Widenius pro švédskou firmu TcX. V roce 1994 TcX začala hledat relační databázový stroj s podporou SQL pro použití ve webových aplikacích schopných výkonně pracovat s velkým množstvím dat. Widenius spolu s Davidem Axmarkem proto začal pracovat na MySQL, jehož první oficiální verze 3.11.1 spatřila světlo světa v roce 1996. MySQL se stalo velice populárním, zejména díky své rychlosti a jednoduchosti. Zaznívala však také kritika týkající se chybějící podpory pro transakční zpracování či cizí klíče. Vývoj MySQL pokračoval přidáním této funkcionality a podpory pro řadu dalších vlastností jako replikace, poddotazy, uložené procedury, pohledy a triggery (DuBois, 2009). Zajímavostí tohoto databázového stroje je konfigurovatelná podpora pro různé způsoby ukládání dat. Každá tabulka v databázi může být spravována jiným tzv. „storage enginem“, optimalizovaným pro specifický způsob využití. Mezi nejčastěji používané patří: MyISAM (rychlý přístup, avšak bez podpory transakcí a cizích klíčů) a InnoDB (s úplnou podporou pro zachování integrity dat).

6.1.1.2 PostgreSQL Původní verze této databáze s názvem „Postgres“ vznikla na University of California v Berkeley, pod vedením profesora Michaela Stonebrakera, v roce 1986 jako pokračování projektu Ingres zahájeného v roce 1977. Rok 1996 přinesl přejmenování projektu na „PostgreSQL“, který je od té doby vyvíjen komunitou dobrovolných vývojářů jako Open Source (PostgreSQL, 2011). Silnou stránkou PostgreSQL je stabilita databázového stroje, podpora všech důležitých zabezbečovacích mechanismů, široké spektrum procedurálních jazyků použitelných pro definici uložených procedur a především konsekventní snaha o soulad se standardy ANSI SQL. Posledně jmenované vlastnosti jsou velkou výhodou zejména s ohledem na návrh implementace aplikační vrstvy na straně databáze. Silné a standardizované prostředky pro její vývoj urychlují implementaci a snižují riziko nepříjemných překvapení během vývoje i provozu systému. Dlouhodobě stabilní licenční politika a nekomerční povaha projektu navíc snižují rizika dalších nákladů v budoucnu. 44

Z výše uvedených důvodů byl pro implementaci systému zvolen databázový stroj PostgreSQL.

6.1.2 Webový server Pro provoz serverové části systému je vedle databázového serveru nutný i webový server podporující zvolený skriptovací jazyk PHP. Osvědčenou volbou je zdarma dostupný webový server Apache, který byl použit i pro implementaci navrhovaného řešení.

6.1.3 Webové rozhraní Webové rozhraní obchodu je tvořeno dynamicky generovaným obsahem. Pro svou jednoduchost a dostupnost na cílové platformě byl zvolen jazyk PHP v kombinaci s knihovnou „Smarty“, která umožňuje snadné použití HTML šablon. Vzhledem k přesunu aplikační logiky na stranu databázového stroje se funkcionalita obsažená v PHP skriptech omezuje výhradně na úlohy související s voláním příslušných funkcí aplikační vrstvy a formátováním výsledků do HTML kódu. Bez větších potíží je proto možné tuto část prezentační vrstvy kdykoliv nahradit libovolnou alternativní technologií (např. ASP).

6.1.4 Aplikace pro správu dat Uživatelské rozhraní aplikace pro správu dat je postaveno na technologii .NET WinForms firmy Microsoft. Její výhodou je snadné použití a široké spektrum podporovaných ovládacích prvků pro tvorbu uživatelsky příjemných grafických rozhraní. Generování výstupních sestav probíhá pomocí „Microsoft Reporting Services“. Pro definici jejich vzhledu lze použít snadno ovladatelný WYSIWYG4 editor, který je přímo integrován ve vývojovém prostředí „Microsft Visual Studio“, jehož bylo použito pro naprogramování celé aplikace.

4 „What You See Is What You Get“ - výsledné zobrazení odpovídá přesně vzhledu při návrhu

45

Obrázek 7 (grafické rozhraní správcovské aplikace) Zdroj: vlastní

7 Nasazení Po ukončení každé vývojové iterace byla nová funkcionalita otestována a zároveň prověřeno bezchybné fungování systému ve všech klíčových scénářích. Konečné nasazení vyvíjeného řešení nejlépe ilustruje následující diagram:

46

Obrázek 8 (diagram nasazení) Zdroj: vlastní

Webový server Apache s nainstalovanou podporou pro PHP běží společně s databázovým strojem PostgreSQL na stejném hardware s operačním systémem Linux. Zákazníci se připojují ze svých počítačů pomocí webového prohlížeče k webovému serveru (protokol HTTP), který vyřizuje jejich požadavky. Přitom komunikuje s databází a vrací dynamicky generovaný obsah ve fromátu HTML. Správci systému na svých pracovních stanicích používají desktopovou aplikaci, která se přes ODBC5 rozhraní připojuje k databázi pomocí zabezpečeného SSL6 kanálu.

5 „Open Database Connectivity“ - univerzální databázové rozhraní odstiňující klientské aplikace od specifického komunikačního rozhraní konkrétního databázového stroje 6 „Secure Socket Layer“ - kryptografické zabezpečení komunikace na úrovní trasnportní vrstvy

47

8 Závěry a doporučení Hlavní přínos mé práce vidím v tom, že na praktickém příkladu demonstruje možný postup tvorby IS nad databázovým strojem za použití standardních metod a modelovacích technik s ohledem na možnosti objektově-relačních databází. Mojí snahou bylo přiblížit celý životní cyklus řešení. Na jeho začátku stojí vize projektu a specifikace požadavků. Jejich následná analýza v modelu jednání odhaluje aktéry a znázorňuje jejich interakci se systémem. Důležité scénáře pomáhají identifikovat entity a vztahy, které se v konceptuálním modelu transformují do analytických tříd a vazeb. Navazující fáze návrhu nejprve definuje základní princip, kterým je rozdělení celého řešení do vrstev, a následně se detailně zaobírá každou z nich. Relační model, který je základem datové vrstvy, vychází z konceptuálního modelu. Aplikační logika, implementovaná na straně databáze, odstiňuje okolí od její vnitřní struktury a poskytuje jasné a ucelené rozhraní pro prezentační vrstvu. Zároveň jsem chtěl ukázat, jak lze vyřešit některé více či méně standardní problémy, jako např. vícejazyčnost, a jakým přínosem může být podpora XML v moderních databázích. Smyslem mé práce proto není ani tak výsledný produkt sám o sobě, jako cesta k němu. O tom, že nevede vždy jen po umetených cestičkách, mě přesvědčila zejména analýza. Nedostatky a chyby, jichž jsem se během této fáze dopustil, se mi vždy vymstily v některé z následujících fází. Z této práce jsem si proto odnesl zejména zkušenost, že staré české přísloví „dvakrát měř, jednou řež“ bezezbytku platí i ve vývoji software.

48

Seznam použité literatury Tištěná literatura 1.

GRAPPONE, Jennifer; COUZIN, Gradiva. SEO – Search Engine Optimization. 1.vyd. Brno: ZONER software, 2007. ISBN 978-80-86815-85-5.

2.

ARLOW, Jim; NEUSTADT, Ilja. UML2 a unifikovaný proces vývoje aplikací: Objektově orientovaná analýza a návrh prakticky. 1.vyd. Brno: Computer Press, 2007. ISBN 978-80-251-1503-9.

3.

FOWLER, Martin. Destilované UML. 1.vyd. Praha: Grada Publishing, 2009. ISBN 978-80-247-2062-3.

4.

QIN, Zheng; XING, Jian-Kuan; ZHENG, Xiang. Software Architecture. 1.vyd. Berlin Heidelberg: Springer, 2008. ISBN 978-3-540-74342-2.

5.

GAMMA Erich; HELM Richard; JOHNSON Ralph; VLISSIDES John. Design Patterns: Elements of Reusable Object-Oriented Software. 1.vyd. USA: Addison-Wesley, 1994. ISBN 0201633612.

6.

DUBOIS, Paul. MySQL. 4.vyd. USA: Pearson Education, 2009. ISBN 978-0-67232938-8.

Elektronické zdroje 1.

World Wide Web Consortium (W3C). XSL Transformations (XSLT) Version 1.0 [online]. c1999 [cit. 2011-01-01]. Dostupný z WWW:

2.

VALENTA, Michal. DBS – Normální formy, normalizace [online]. c2010 [cit. 2011-03-23]. Dostupný z WWW:

3.

eCommerce Wars: The Secret Behind Magento Popularity Over osCommerce [online]. 2010 [cit. 2011-03-24]. Dostupný z WWW: 49

4.

osCommerce: About osCommerce [online]. c2000-2011 [cit. 2011-03-24]. Dostupný z WWW:

5.

Magento: Feature List. [cit. 2011-03-24]. Dostupný z WWW:

6.

MySQL 5.5 Reference Manual [online]. c1997,2011 [cit. 2011-01-01]. Chap. 13, Storage Engines. Dostupný z WWW:

7.

PostgreSQL: History [online]. c1996-2011 [cit. 2011-01-01]. Dostupný z WWW:

50

Příloha č. 1 Konceptuální model – hlavní analytické třídy a vazby mezi nimi:

Zdroj: vlastní

51

Příloha č. 2 Příklady konverzních předpisů pro generování protokolu změn. Proměnná %id% ve výrazech reprezentuje primární klíč „id“ ve změněné (podřízené) tabulce. Konverzní výraz definuje obsah uměle vygenerovaných záznamů o změně nadřízené entity.

Podřízená entita

Nadřízená entita Konverzní výraz

eshop_product_attribute eshop_product

SELECT product_id AS id FROM eshop_product_attribute WHERE id = %id%

eshop_product_category eshop_product

SELECT product_id AS id FROM eshop_product_category WHERE id = %id%

eshop_order_product

eshop_order

SELECT order_id AS id FROM eshop_order_product WHERE id = %id%

eshop_bill_out

eshop_order

SELECT os.order_id AS id FROM eshop_order_status os, eshop_bill_out b WHERE b.order_status_id = os.id AND b.id = %id% Zdroj: vlastní

52

Příloha č. 3 Ukázka funkce aplikační vrstvy (vrací uživatelská oprávnění specifického uživatele): -- Funkce vracející seznam uživatelských oprávnění CREATE OR REPLACE FUNCTION ESHOP_GETUSERPERMISSIONS(ESHOP_ID) RETURNS ESHOP_INT_ARR AS ' DECLARE user_id ALIAS FOR $1; rec RECORD; i ESHOP_INT := 1; arr ESHOP_INT_ARR; BEGIN FOR rec IN SELECT upd.translated FROM eshop_user_permission up, eshop_user_permission_def upd WHERE up.user_id = user_id AND up.user_permission_def_id = upd.id LOOP arr[i] := rec.translated; i := i + 1; END LOOP; RETURN arr; END; ' LANGUAGE 'plpgsql'; Zdroj: vlastní

53

Příloha č. 4 Využití triggeru pro zajištění integrity dat: -- Funkce pro kontrolu příslušnosti státu k dané zemi CREATE OR REPLACE FUNCTION ESHOP_CHECKCOUNTRYSTATE(ESHOP_ID, ESHOP_ID) RETURNS void AS ' DECLARE c_id ALIAS FOR $1; s_id ALIAS FOR $2; BEGIN IF (s_id IS NOT NULL) THEN IF (NOT EXISTS (SELECT id FROM eshop_state WHERE id = s_id AND country_id = c_id)) THEN RAISE EXCEPTION ''Invalid state/country linkage.''; END IF; END IF; END; ' LANGUAGE plpgsql;

-- Deklarace triggeru pro kontrolu příslušnosti státu k dané zemi CREATE OR REPLACE FUNCTION ESHOP_TRIGIMPLSUPPLIERCHECK() RETURNS trigger AS ' BEGIN PERFORM eshop_checkcountrystate(NEW.country_id, NEW.state_id); RETURN NEW; END; ' LANGUAGE plpgsql;

-- Definice triggeru na tabulce dodavatelů (ESHOP_SUPPLIER) CREATE TRIGGER ESHOP_SUPPLIER_CHECK AFTER INSERT OR UPDATE ON ESHOP_SUPPLIER FOR EACH ROW EXECUTE PROCEDURE ESHOP_TRIGIMPLSUPPLIERCHECK(); Zdroj: vlastní

54

Příloha č. 5 Ukázka volání funkce aplikační logiky z prezentační vrstvy (webového rozhraní obchodu):

Zdroj: vlastní

55

Příloha č. 6 Ukázka webového rozhraní – výpis produktů zvolené kategorie 7:

Zdroj: vlastní

7 http://www.simplyme.cz

56

Příloha č. 7 Ukázka webového rozhraní – detail produktu 8:

Zdroj: vlastní

8 http://www.simplyme.cz

57

Příloha č. 8 Ukázka webového rozhraní – obsah nákupního košíku 9:

Zdroj: vlastní

9 http://www.simplyme.cz

58

Příloha č. 9 Správcovská aplikace – maska pro evidenci produktů:

Zdroj: vlastní

59

Příloha č. 10 Správcovská aplikace – maska pro evidenci objednávek:

Zdroj: vlastní

60

Příloha č. 11 Správcovská aplikace – ukázka reportingu skladových pohybů:

Zdroj: vlastní

61

Příloha č. 12 Součástí této práce je kompaktní disk se zdrojovými kódy aplikace, skripty pro vytvoření databáze a obrázkem relačního modelu.

62