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

Transkript

1 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

2 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 Filip Hermann

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

4 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

5 Obsah 1 Úvod Vize projektu Katalog požadavků Funkční požadavky Nefunkční požadavky Alternativy řešení oscommerce Magento Vlastní řešení Analýza požadavků Případy užití (use cases) Aktér Zákazník Aktéři Správci systému Správce produktů Správce skladu Správce objednávek Správce uživatelů Konceptuální model Analytické třídy Obchodní partneři Správa produktů Správa skladu Správa objednávek Správa uživatelů

6 5 Návrh Architektura Datová vrstva Jmenné konvence Použité techniky Hierarchie Vícejazyčnost Sledování změn Notifikace a dokumenty Integrita dat Normalizace schématu Relační model Obchodní partneři Evidence produktů Evidence stavu skladu Evidence objednávek Evidence uživatelů Aplikační vrstva Řízení přístupu Přístup na úrovni databáze Přístup na programové úrovni Rozhraní aplikační vrstvy Základní funkce Rozhraní pro správu obchodních partnerů Rozhraní pro přístup k produktům

7 Rozhraní pro správu skladu Rozhraní pro správu objednávek Rozhraní pro správu uživatelů Prezentační vrstva Zákaznické uživatelské rozhraní Administrátorské uživatelské rozhraní Implementace Volba implementační platformy Databázový stroj MySQL PostgreSQL Webový server Webové rozhraní Aplikace pro správu dat Nasazení Závěry a doporučení...48 Seznam použité literatury...49 Tištěná literatura...49 Elektronické zdroje

8 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

9 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 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.) 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

10 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) 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

11 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ž 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

12 newslettery a možnost kontaktovat zákazníky em 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 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

13 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: 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

14 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í 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

15 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 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 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

16 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 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

17 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í 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

18 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

19 dodacích listů, faktur, dobropisů a ových notifikací (viz. požadavek FP18). Podobně jako automaticky generované skladové pohyby popsané v kapitole 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í 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

20 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 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í 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

21 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 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

22 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

23 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 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 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

24 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 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

25 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

26 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 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

27 (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) 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 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

28 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í 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é 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

29 Č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 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

30 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) 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) 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

31 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é 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 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

32 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é 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

33 (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.) 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 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

34 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 ). 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

35 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 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 Ří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

36 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í 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

37 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 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

38 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 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 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

39 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

40 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 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 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

41 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 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 ). 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 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

42 (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 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 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

43 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 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

44 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 spatřila světlo světa v roce 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) 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 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

45 Z výše uvedených důvodů byl pro implementaci systému zvolen databázový stroj PostgreSQL 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í 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) 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

46 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

47 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

48 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

49 Seznam použité literatury Tištěná literatura 1. GRAPPONE, Jennifer; COUZIN, Gradiva. SEO Search Engine Optimization. 1.vyd. Brno: ZONER software, ISBN ARLOW, Jim; NEUSTADT, Ilja. UML2 a unifikovaný proces vývoje aplikací: Objektově orientovaná analýza a návrh prakticky. 1.vyd. Brno: Computer Press, ISBN FOWLER, Martin. Destilované UML. 1.vyd. Praha: Grada Publishing, ISBN QIN, Zheng; XING, Jian-Kuan; ZHENG, Xiang. Software Architecture. 1.vyd. Berlin Heidelberg: Springer, ISBN GAMMA Erich; HELM Richard; JOHNSON Ralph; VLISSIDES John. Design Patterns: Elements of Reusable Object-Oriented Software. 1.vyd. USA: Addison-Wesley, ISBN DUBOIS, Paul. MySQL. 4.vyd. USA: Pearson Education, ISBN Elektronické zdroje 1. World Wide Web Consortium (W3C). XSL Transformations (XSLT) Version 1.0 [online]. c1999 [cit ]. Dostupný z WWW: < 2. VALENTA, Michal. DBS Normální formy, normalizace [online]. c2010 [cit ]. Dostupný z WWW: < pdf > 3. ecommerce Wars: The Secret Behind Magento Popularity Over oscommerce [online] [cit ]. Dostupný z WWW: 49

50 < > 4. oscommerce: About oscommerce [online]. c [cit ]. Dostupný z WWW: < 5. Magento: Feature List. [cit ]. Dostupný z WWW: < 6. MySQL 5.5 Reference Manual [online]. c1997,2011 [cit ]. Chap. 13, Storage Engines. Dostupný z WWW: < 7. PostgreSQL: History [online]. c [cit ]. Dostupný z WWW: < 50

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

52 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

53 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

54 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

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