Automatizovaný vyhledávač aukčních položek

Mendelova univerzita v Brně Provozně ekonomická fakulta

Automatizovaný vyhledávač aukčních položek Diplomová práce

Vedoucí práce: doc. Ing. František Dařena, Ph.D.

Brno 2014

Bc. Filip Vaníček

Rád bych touto formou poděkoval vedoucímu práce doc. Ing. Františku Dařenovi, Ph.D. za cenné připomínky a rady, které mi pomohly tuto práci vytvořit.

Čestné prohlášení Prohlašuji, že jsem tuto práci: Automatizovaný vyhledávač aukčních položek vypracoval samostatně a veškeré použité prameny a informace jsou uvedeny v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle § 60 odst. 1 Autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity o tom, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše. V Brně dne 12. 5. 2014

__________________

Abstract Vaníček, F. Automatic search engine of auction items. Diploma thesis. Brno: MUAF, 2014. Diploma thesis deals with the analysis, design and implementation of an application that allows users to search the auction results of companies that organize auctions. This work describes two mutually independent parts of application – the extracting robot and the search engine. Extracting robot takes care of automatic extraction of auction results from Web pages based on user-created extracting template. Automation of the extraction process is achieved by analyzing the Web links using Bayes classifier and use of automatic detection of the auction items. Second part of the application is used to search the extracted auction results. Search results will help users to determine the financial value of collectibles and investments items (coins, medals and banknotes). Keywords Auction search engine, extracting robot, Bayes classifier, DOM, PHP, Nette Framework, JavaScript, jQuery.

Abstrakt Vaníček, F. Automatizovaný vyhledávač aukčních položek. Diplomová práce. Brno: MZLU v Brně, 2014. Diplomová práce se zabývá analýzou, návrhem a implementací aplikace, která uživatelům umožní vyhledávat v aukčních výsledcích společností pořádajících sálové aukce. Práce popisuje dvě vzájemně nezávislé části aplikace – extrakčního robota a vyhledávač. Extrakční robot se stará o automatickou extrakci aukčních výsledků z webových stránek na základě uživatelem vytvořené extrakční šablony. Automatizace procesu extrakce je dosaženo analýzou odkazů pomocí Bayesova klasifikátoru a využití automatické detekce aukčních položek. Pro vyhledávání v aukčních výsledcích slouží druhá část aplikace. Výsledky vyhledávání uživatelům pomohou k určení finanční hodnoty sběratelských a investičních předmětů (mincí, medailí, vyznamenání a bankovek). Klíčová slova Aukční vyhledávač, extrakční robot, Bayesův klasifikátor, DOM, PHP, Nette Framework, JavaScript, jQuery.

Obsah

5

Obsah 1

2

Úvod a cíl práce 1.1

Úvod ......................................................................................................... 11

1.2

Cíl práce ................................................................................................... 12

Analýza současného stavu

Sběr informací v prostředí webu ............................................................. 16

2.2

Analýza webových odkazů ....................................................................... 16

2.2.1

Analýza sociálních sítí ...................................................................... 17

2.2.2

Klasifikace webových odkazů ..........................................................18

2.2.3

Bayesův klasifikátor ......................................................................... 19

Dolování obsahu webových stránek ....................................................... 20

2.3.1

4

14

2.1

2.3

3

11

Algoritmus extrakce datových záznamů .......................................... 21

Metodika řešení

23

3.1

Analýza a návrh aplikace ........................................................................ 23

3.2

Implementace aplikace ........................................................................... 25

3.2.1

Nette Framework ............................................................................ 25

3.2.2

jQuery .............................................................................................. 26

3.2.3

AJAX ............................................................................................... 26

3.2.4

Cron ................................................................................................. 27

3.2.5

MySQL............................................................................................. 27

Analýza a návrh aplikace

29

4.1

Specifikace problému.............................................................................. 29

4.2

Analýza a návrh extrakčního robota ....................................................... 30

4.2.1

Proces tvorby extrakční šablony ..................................................... 30

4.2.2

Proces extrakce ................................................................................ 31

4.2.3

Proces standardizace měn a časových údajů .................................. 32

4.2.4

Automatizace extrakčního robota................................................... 32

4.2.5

Diagram tříd extrakčního robota .................................................... 33

Obsah

6

4.2.6 4.3

5

Analýza a návrh vyhledávače .................................................................. 36

4.3.1

Proces registrace ..............................................................................37

4.3.2

Proces vyhledávání...........................................................................37

4.3.3

Proces přidávání mezi oblíbené položky ........................................ 38

4.3.4

Diagram tříd vyhledávače ............................................................... 38

4.3.5

Schéma databáze vyhledávače ........................................................ 40

Implementace extrakčního robota 5.1

43

Popis tříd ................................................................................................. 43

5.1.1

Třída Robot ..................................................................................... 43

5.1.2

Třída Extractor ................................................................................ 43

5.1.3

Třída Scheduler ............................................................................... 44

5.1.4

Třída Action .................................................................................... 45

5.1.5

Třída Template ................................................................................ 45

5.1.6

Třída PageData................................................................................ 46

5.1.7

Třída BayesFilter ............................................................................. 46

5.1.8

Třída Link ........................................................................................ 47

5.1.9

Třída Factory ................................................................................... 47

5.1.10

Třída DB .......................................................................................... 48

5.1.11

Třída HTML .................................................................................... 49

5.1.12

Třída User ....................................................................................... 49

5.2

6

Schéma databáze extrakčního robota ............................................. 35

Popis funkce extrakčního robota ............................................................ 49

5.2.1

Tvorba extrakční šablony ................................................................ 50

5.2.2

Automatická extrakce ..................................................................... 54

Implementace vyhledávače 6.1

56

Popis tříd ................................................................................................. 56

6.1.1

Třída Repository ............................................................................. 56

6.1.2

Třída UserRepository...................................................................... 56

6.1.3

Třída Authenticator .........................................................................57

6.1.4

Třída TokenRepository ....................................................................57

6.1.5

Třída SearchSettings ....................................................................... 58

Obsah

7

6.1.6

Třída ItemRepository...................................................................... 59

6.1.7

Třída SearchHistoryRepository ...................................................... 60

6.1.8

Třída SearchFormControl............................................................... 60

6.1.9

Třída SearchResultControl .............................................................. 61

6.1.10

Třída VisualPaginatorControl.......................................................... 61

6.1.11

Třída HomepagePresenter .............................................................. 62

6.1.12

Třída RegisterPresenter .................................................................. 62

6.1.13

Třída SignPresenter ........................................................................ 63

6.1.14

Třída PremiumPresenter ................................................................ 63

6.1.15

Třída ListingPresenter .................................................................... 64

6.1.16

Třída ItemPresenter ........................................................................ 64

6.1.17

Třída FavoritePresenter .................................................................. 65

6.1.18

Třída SettingsPresenter .................................................................. 65

6.1.19

Třída AdminPresenter .................................................................... 66

6.2

Popis funkce vyhledávače ....................................................................... 66

6.2.1

Registrace a přihlášení do aplikace ................................................ 67

6.2.2

Prémiová část aplikace.................................................................... 68

6.2.3

Vyhledávání aukčních položek ....................................................... 69

6.2.4

Prohlížení aukčních výsledků ......................................................... 70

6.2.5

Oblíbené položky.............................................................................. 71

7

Testování

73

8

Diskuze

75

9

Závěr

77

10 Literatura

78

A

83

Praktické použití

Seznam obrázků

8

Seznam obrázků Obr. 1

Vyhledávač McSearch nedokáže nalézt korunovou minci (zdroj: mcsearch.info) 14

Obr. 2

Příklad části strany s aukčními výsledky (zdroj: aurea.cz)

Obr. 3

Příklad sociální sítě s centrální stránkou označenou symbolem i (zdroj: [4])

15

17 Obr. 4

Schéma stránky s dvěma podobnými datovými záznamy (zdroj: [13]) 21

Obr. 5

Jedna z možných konfigurací datových záznamů (zdroj: [13])

22

Obr. 6

Diagram případu užití extrakčního robota

30

Obr. 7

Proces extrakce

31

Obr. 8

Diagram tříd extrakčního robota

34

Obr. 9

Schéma databáze extrakčního robota

35

Obr. 10 Diagram případů užití vyhledávače

36

Obr. 11

Diagram tříd vyhledávače

40

Obr. 12

Schéma databáze vyhledávače

42

Obr. 13

Třída Robot

43

Obr. 14

Třída Extractor

44

Obr. 15

Třída Scheduler

45

Obr. 16

Třída Action

45

Obr. 17

Třída Template

46

Obr. 18 Třída PageData

46

Obr. 19

47

Třída BayesFilter

Obr. 20 Třída Link

47

Obr. 21

48

Třída Factory

Obr. 22 Třída DB

48

Obr. 23 Třída HTML

49

Obr. 24 Třída User

49

Obr. 25 Extrakční robot – úvodní obrazovka

50

Seznam obrázků

9

Obr. 26 Extrakční robot – naučený Bayesův filtr

51

Obr. 27 Extrakční robot – tvorba šablony

52

Obr. 28 Extrakční robot – testování šablony

53

Obr. 29 Třída Repository

56

Obr. 30 Třída UserRepository

57

Obr. 31

57

Třída Authenticator

Obr. 32 Třída TokenRepository

58

Obr. 33 Třída SearchSettings

59

Obr. 34 Třída ItemRepository

60

Obr. 35 Třída SearchHistoryRepository

60

Obr. 36 Třída SearchFormControl

61

Obr. 37 Třída SearchResultControl

61

Obr. 38 Třída VisualPaginatorControl

62

Obr. 39 Třída HomepagePresenter

62

Obr. 40 Třída RegisterPresenter

63

Obr. 41

63

Třída SignPresenter

Obr. 42 Třída PremiumPresenter

64

Obr. 43 Třída ListingPresenter

64

Obr. 44 Třída ItemPresenter

65

Obr. 45 Třída FavoritePresenter

65

Obr. 46 Třída SettingsPresenter

66

Obr. 47 Třída AdminPresenter

66

Obr. 48 Vyhledávač – výřez úvodní obrazovky

67

Obr. 49 Vyhledávač – přihlašovací a resetovací formulář

68

Obr. 50 Vyhledávač – prémiová část (se zobrazenou kontextovou nápovědou) 69 Obr. 51

Vyhledávání aukčních položek

70

Obr. 52 Prohlížení aukčních položek – seznam aukcí

71

Obr. 53 Prohlížení aukčních položek – detail aukce

71

Obr. 54 Přidávání do oblíbených položek

72

Obr. 55 Tvorba šablony pro Sixbid.com – dvousloupcové rozvržení

73

Seznam obrázků

10

Obr. 56 Sixbid.com – test správnosti extrakce

74

Obr. 57 Praktická ukázka – hledání dukátu Karla IV. (první část)

83

Obr. 58 Praktická ukázka – hledání dukátu Karla IV. (druhá část)

84

Obr. 59 Praktická ukázka – hledání dukátu Karla IV. (třetí část)

84

Obr. 60 Praktická ukázka – hledání dukátu Karla IV. (čtvrtá část)

85

Obr. 61

85

Praktická ukázka – hledání dukátu Karla IV. (pátá část)

Úvod a cíl práce

11

1 Úvod a cíl práce 1.1

Úvod

Peníze hrají v životě mnoha lidí civilizovaného světa důležitou roli. Většina lidí žijících v civilizovaném světě je s funkcí peněz seznámena již během svého dětství, kdy postupně pochopí, že si za ně mohou koupit věci, které nemají a které chtějí. Tomuto se říká, že peníze představují prostředek směny [1]. Člověk může vyměnit peníze za zboží, které chce a které pro něj má vyšší hodnotu, než druhý člověk za zboží vyžaduje. Peníze nejsou k životu člověka úplně nezbytné, umožňují však žít pohodlnější život. Zároveň se prostřednictvím nich lidé mohou vyrovnávat s nejistotou, která jim do budoucna hrozí [1]. Hodnota peněz není stálá a je určena nejen minulou hodnotou peněz, ale také mírou inflace. Inflace znamená zvyšování množství peněz v oběhu. Toto zvyšování dostupných peněz způsobuje zvyšování cen zboží, protože více lidí si najednou může koupit více zboží, ale množství zboží se nezvýšilo. Z tohoto důvodu inflace snižuje kupní sílu peněz. Proto se někteří lidé snaží hodnotu svých úspor chránit [1]. Pokud člověk používá své volné peněžní prostředky k tomu, aby nakoupil zboží, které mu umožní mít se v budoucnosti lépe, říká se tomu investice. Základem investování je využití volných finančních prostředků pro nákup aktiv. Aktiva představují vše, co člověk může vlastnit a přinese to člověku do budoucnosti zisk nebo to alespoň pokryje inflaci. Mezi třídy aktiv patří například cenné papíry, nemovitosti nebo komodity [1]. Možností spojení investice a sběratelství je nákup historických sběratelských předmětů. Na tomto trhu dochází v posledních letech k obrovskému růstu. Jeden z nejvíce rostoucích trhů je trh s historickými americkými mincemi, který má odhadovaný obrat za rok 2013 kolem 5 miliard amerických dolarů. Zároveň byla během tohoto roku vydražena nejdražší mince světa za rekordní sumu přesahující 10 miliónů dolarů [2]. O tom, že neroste pouze trh s mincemi, svědčí finanční výsledky největší světové aukční společnosti – americké Heritage Auction, která pořádá aukce různých sběratelských předmětů (mincí, bankovek, knih, uměleckých předmětů a obrazů, komiksů, filmových plakátů, sportovních suvenýrů, luxusních vín a šperků). Tato společnost vydražila za rok 2013 předměty v celkové hodnotě přes 900 miliónů dolarů [3] a z toho mince v hodnotě 236 miliónů dolarů [2]. Tyto částky mohou vést člověka k zamyšlení, že by se na tomto trhu daly jednoduše investovat a vydělat peníze. Opak je bohužel pravdou. Člověk potřebuje mít nejen značné teoretické vědomosti, musí neustále sledovat historické ceny aukčních předmětů a mít praktické zkušenosti s oceňováním předmětů s ohledem na jejich stav, aby mohl na těchto trzích uspět. Asi časově nejnáročnější je sledování a dohledávání historických aukčních cen. Tyto ceny uvádějí společnosti převážně na svých webových stránkách a u některých společností jsou zde pouze po určitou dobu. Aukční společnosti většinou neumožňují vyhle-

Úvod a cíl práce

12

dávat ve svých aukčních výsledcích. Proto se pro většinu sběratelů stává jedinou možností procházení mnoha stránek s mnoha pro ně nezajímavými výsledky, než se dostanou k výsledkům, které je zajímají. Z tohoto důvodu jim jakákoliv možnost, která jim pomůže si tuto zdlouhavou práci usnadnit, velmi zjednoduší práci. K tomuto účelu by byla vhodná webová aplikace, která by aukční výsledky shromažďovala a umožnila v nich jednoduše vyhledávat. Taková aplikace by měla výhodu, že by uchovávala historické údaje, které aukční společnosti postupně odstraňují. Zároveň by obsahovala aukční výsledky z různých zdrojů, čímž by výsledky vyhledávání získaly vyšší objektivitu a pro investory-sběratele by se staly užitečnějšími. Jelikož jsou aukční výsledky nejčastěji uloženy ve formě webových stránek formátovaných pomocí HTML značek, lze využít pro hromadné procházení a indexování stránek webového robota [4]. Tento robot musí umět automatizovaně procházet a zpracovávat stránky obsahující výsledky různých aukčních společností. Aby tohoto byl robot schopen, bude nejprve nutné robota naučit chápat různé údaje na stránce, případně je i konvertovat do správných formátů (časové údaje, měny). Správné interpretace údajů by mohlo být dosaženo tvorbou šablon pro extrakci dat z webových stránek skládajících se z množiny klíčových cest. Klíčová cesta představuje absolutní cestu objektového modulu dokumentu (DOM), která jednoznačně identifikuje prvek na určité stránce. Na základě takto vytvořené šablony bude moci robot rozpoznat význam jednotlivých HTML elementů nebo bloků na stránce a na základě toho je extrahovat [5]. Dále musí být robot schopen přecházet mezi jednotlivými stránkami, aby dokázal extrahovat všechny stránky aukce. Musí tedy rozpoznávat, které odkazy jsou relevantní a které ne. Toto se neobejde bez využití nějakého algoritmu pro analýzu odkazů vedoucích na další strany. Administrátor aplikace by měl být schopen jednoduše nastavit extrakci webového robota, a to zcela bez znalosti jakýchkoliv programovacích nebo značkovacích jazyků. Nastavení extrakce robota by měla probíhat interaktivně a jednorázově, kdy je robotovi jednou vytvořena extrakční šablona, a poté by už vše mělo probíhat automatizovaně. V ideálním případě by měl administrátor aplikace pouze za pomoci kurzoru myši označit jednotlivé bloky webové stránky a automaticky by se měla vygenerovat celá extrakční šablona webu. Zároveň by se šablona měla vytvořit co nejobecněji, aby byla zaručena funkčnost extrakce i při malé změně webové stránky. Z tohoto důvodu bude návrh a tvorba takové aplikace netriviální záležitostí.

1.2 Cíl práce Cílem práce je analyzovat, navrhnout a implementovat aplikaci, která uživatelům poskytne podporu pro rozhodování o nákupu nebo případném prodeji sběratelských předmětů na sálových aukcích aukčních společností. Podporou pro rozhodování je myšleno nabídnutí relevantních aukčních výsledků pro zadaný dotaz uživatele. Aplikace by měla být schopna extrahovat data o aukčních vý-

Úvod a cíl práce

13

sledcích z různých webových stránek aukčních společností za pomoci extrakčního robota. Nastavení extrakce tohoto robota by mělo být jednoduché, aby byl tento proces schopen provést i méně zkušený administrátor. Poté by už měla celá činnost robota probíhat automatizovaně.


14

2 Analýza současného stavu Aukční společnosti pořádají pravidelně, obvykle dvakrát ročně, prodej sběratelských předmětů na sálových aukcích. Informace o dražených předmětech obsahují popis, vyvolávací cenu a někdy i fotografie předmětu a jsou dopředu zveřejňovány prostřednictvím papírového katalogu a webových stránek dražebníka. Ve většině případů není ve webových aukčních výsledcích umožněno vyhledávání, a proto musí sběratelé procházet jednotlivé aukční výsledky manuálně. Aby sběratel dokázal odhadnout konečnou cenu položky, kterou hodlá dražit, musí najít co nejvíce podobných aukčních výsledků, aby byla maximalizována objektivita výsledné ceny. Tato činnost je proto velmi časově náročná a často se může stát, že sběratel nějakou položku přehlédne nebo započítá vícekrát. Z tohoto důvodu by sběratelům ušetřila hodně času aplikace, která by tato data obsahovala už extrahovaná, předzpracovaná a připravená pro vyhledávání. Aplikace, která alespoň částečně předcházející požadavky splňuje, už existuje. Jmenuje se McSearch a slouží k vyhledávání v historických aukčních výsledcích pouze numismatických předmětů. Proto by zde sběratelé jiných oborů hledali informace zbytečně [6]. Tato aplikace je určena převážně pro vyhledávání ve výsledcích největších světových aukčních portálů a největší české aukční společnosti vůbec neobsahuje. Z těchto důvodů není aplikace vhodná pro stanovené podmínky. Ostatní vyhledávače jsou na tom podobně jako McSearch a jejich databáze už většinou nedosahuje velikosti databáze McSearch [6].

Obr. 1

Vyhledávač McSearch nedokáže nalézt korunovou minci (zdroj: mcsearch.info)

Další možností, jak vyhledávat historické ceny aukčních položek, je použití aukčních portálů Ebay nebo českého Aukra. Oba tyto portály umožňují vyhledávat v historických údajích na nich vydražených položek a trpí stejnými neduhy. Starší údaje jsou postupně odstraňovány a poté už v nich není možné znovu dohledávat. Dále je zde k prodeji velmi málo kvalitních předmětů v porovnání s velkým množstvím lidí, kteří zde draží a mají zájem koupit kvalitní zboží. Z tohoto důvodu zde vzniká situace, kdy poptávka mnohokrát převyšuje nabídku


15

[1]. To způsobuje, že se zde skoro jakýkoliv kvalitní sběratelský materiál stabilně prodává dráže než na sálových aukcích. Z tohoto důvodu není ani jeden portál ideálním vyhledávacím nástrojem pro jakoukoliv investici do sběratelských předmětů. Pro české uživatele by byl mnohem vhodnější vyhledávač, který by uměl vyhledávat převážně v českých aukčních výsledcích společností pořádajících sálové aukce. Příkladem takového aukčního portálu je pražská společnost Aurea, která pravidelně pořádá sálové aukce mincí, bankovek, vyznamenání a doplňující literatury [7]. Aukční výsledky svých aukcí společnost pravidelně zveřejňuje na svých webových stránkách ve formě tabulkového výpisu propojeného pomocí odkazů.

Obr. 2

Příklad části strany s aukčními výsledky (zdroj: aurea.cz)

Na Obr. 2 je možné vidět, jak vypadá typická strana s aukčními výsledky společnosti Aurea. Z pohledu formátování pomocí HTML značek se jedná o množinu tabulek, kdy je každá položka uložena ve vlastní tabulce a v jednotlivých řádcích a sloupcích jsou uloženy různé informace o položce. Tato stránka také obsahuje odkazy na mnoho dalších stránek, z nichž je mnoho odkazů nerelevantních nebo duplicitních. Takové odkazy mohou vést úplně do jiné části webu nebo na jiný web. Z tohoto důvodu bude muset robot umět odkazy nějakým způsobem třídit. Webový robot, který se o extrakci bude starat, musí nejenom fungovat automatizovaně, musí být také jednoduše nastavitelný. Aplikace nesmí po administrátorovi vyžadovat nějakou speciální znalost. Jediné, co by měl administrátor vědět, je URL adresa webové stránky s odkazy na aukce, které chce extrahovat. Příkladem takového jednoduchého nastavení může být administrační rozhraní, kdy je po kliknutí na tlačítko „Vytvořit novou šablonu“ administrátor požádán o zadání URL adresy stránky se seznamem aukcí. Následně by měla být zobrazena určitá aukce, na které bude probíhat tvorba šablony. Jelikož


16

každá webová stránka má trochu jinou strukturu, musí být extrakční robot naučen, jak má danou strukturu interpretovat. Webová stránka s aukčními výsledky může být tvořena jako jednosloupcová (viz Obr. 2) nebo i vícesloupcová. Může být tvořena různými HTML prvky – tabulkami, seznamy, případně jinými prvky, které jsou pozicované pomocí kaskádových stylů (CSS). Proto musí tvorba extrakční šablony probíhat na základě interakce s administrátorem. V ideálním případě bude administrátor pouze za pomoci kurzoru myši označovat jednotlivé bloky stránky jako odezvu na jednotlivé výzvy aplikace. Tímto způsobem bude extrakční robot naučen, jak má správně chápat význam jednotlivých částí stránky. Důležité je, aby se šablona generovala co nejobecněji, protože jen tak může být zaručeno, že bude fungovat na co největší množinu webových stránek.

2.1 Sběr informací v prostředí webu Pro sběr informací v prostředí webu se používají následující techniky dolování dat z webových stránek (web mining) [4]: 1. dolování z webových logů (web usage mining), 2. analýza vzájemného propojení webových stránek (web structure mining), 3. dolování obsahu webových stránek (web content mining). V této práci budou diskutovány pouze techniky z bodů dva a tři, protože technika z prvního bodu slouží převážně pro analýzu chování uživatele, což není pro sběr informací z webových stránek důležité. Pro dolování obsahu z webových stránek se používají techniky web content mining. Použití těchto technik předpokládá, že se každá webová stránka určená k extrakci skládá ze strukturovaných dat. Jednoduše si lze strukturovaná data představit jako text, který je formátován pomocí značek. Jako formátovací značky se nejčastěji používají HTML tagy [4]. Pomocí těchto značek je určen pouze vzhled stránky, značky už neříkají nic o významu jednotlivých bloků textu. Z tohoto důvodu je potřeba extrakční program naučit jednotlivé bloky správně interpretovat. Techniky web structure mining nám umožňují analyzovat vzájemné propojení webových stránek. V tomto konkrétním případě lze této techniky využít pro analýzu relevantnosti nebo irelevantnosti odkazů, které se nacházejí na webových stránkách určených k extrakci. Při analýze webových odkazů je důležité analyzovat nejen odkaz nebo titulek odkazu, pro dosažení lepších výsledků je třeba se zaměřit na obojí. Na základě analýzy obou částí odkazu bude výsledná klasifikace přesnější [4].

2.2 Analýza webových odkazů Webové stránky jsou vzájemně propojené pomocí hypertextových odkazů, které obsahují důležité informace. Vyhledávače tyto informace používají pro určení relevantnosti jednotlivých webových stránek pro zadaný vyhledávací dotaz. Vy-


17

užívá se zde princip, kdy je webová stránka významnější, pokud na ni vedou odkazy z dalších webových stránek, které jsou také významné. Tohoto principu využívá původní verze algoritmu PageRank, který je použit ve vyhledávacím nástroji Google [4]. Webové odkazy se nemusí používat pouze pro zjištění jejich relevantnosti v závislosti na vyhledávacím dotazu, je možné je použít pro hledání webových komunit [4]. Komunita v tomto případě představuje množinu vzájemně propojených stránek, kde jednotlivé stránky reprezentují profilové stránky lidí, kteří mezi sebou mají nějakou interakci nebo vztah. Z tohoto důvodu se této analýze říká analýza sociálních sítí. Výhodou této analýzy je, že nemusí sloužit pouze pro zkoumání vztahů mezi lidmi, je možné ji využít na úplně jiné věci, jako je analýza vzájemného propojení dokumentů nebo webových stránek [4]. Díky tomu lze využít informace v hypertextových odkazech pro vytvoření komunity webových stránek, které představují jednotlivé stránky seznamu aukčních výsledků. 2.2.1

Analýza sociálních sítí

Analýza sociálních sítí může být prováděna dvěma způsoby, a to v závislosti na vztahu klíčové webové stránky k ostatním stránkám v komunitě. Jedná se o analýzu na základě centrálnosti a analýzu na základě prestiže.

Obr. 3

Příklad sociální sítě s centrální stránkou označenou symbolem i (zdroj: [4])

Analýza na základě centrálnosti využívá pojem centrální stránka, kdy se jedná o webovou stránku, která má největší počet vztahů s dalšími stránkami komunity. Takovou stránku je možné chápat jako nejdůležitější. Vztah mezi stránkami si lze představit jako odkazy vedoucí z jedné stránky na druhou i zpět. Z tohoto důvodu vztah nevzniká, pokud je odkaz pouze jednosměrný. Jak je možné vidět na Obr. 3, pro znázornění sociální sítě s centrální stránkou se používá neorientovaného grafu. V tomto případě je centrální stránkou prvek se symbolem ozna-


18

čeným písmenem i [4]. V kontextu této práce bude centrální stránkou úvodní stránka aukce, ze které vedou odkazy na další stránky aukce, a zároveň je na každé straně umístěn odkaz zpět. Naopak analýza na základě prestiže rozlišuje odkazy na dva typy, a to odkaz vedoucí ze stránky a odkaz vedoucí na stránku. Pro výpočet prestiže stránky se používají pouze odkazy vedoucí na stránku. Z tohoto důvodu vede na stránku s nejvyšší prestiží nejvíce odkazů z největšího počtu různých stránek. V reálném případě si to lze představit jako člověka, se kterým chce kamarádit co nejvíce různých lidí. On už s nimi kamarádit nemusí. Pro znázornění takovýchto vztahů se používá orientovaný graf. Tento algoritmus se na první pohled může zdát podobný algoritmu PageRank, diskutovanému v kapitole 2.2. Není tomu tak. PageRank algoritmus na rozdíl od algoritmu analýzy prestiže využívá nejen odkazy na stránku vedoucí, ale i odkazy vedoucí ze stránky na jiné stránky. Takové odkazy slouží ke zvyšování prestiže ostatních stránek [4]. Pro vytvoření komunity stránek s určitou vlastností nestačí zkoumat pouze propojení mezi stránkami. Je třeba data v odkazech nějakým způsobem klasifikovat, protože by se mohlo stát, že odkaz vedoucí na jiný web a zpět by mohl být extrakčním algoritmem chápán jako součást komunity [4]. 2.2.2

Klasifikace webových odkazů

Pro správnou klasifikaci webových odkazů je třeba nejprve pochopit data, která se mají klasifikovat. Z pohledu analýzy a klasifikace dat mají data dvě různé složky [8]: • deterministickou složku, • nedeterministickou složku. Deterministická složka představuje užitečná data, na základě nichž probíhá klasifikace. Naproti tomu nedeterministická složka pouze komplikuje klasifikaci, protože obsahuje rušení a šum. Takové rušení může být už v datech obsaženo. Velmi často se stává, že se šum do dat dostane po použití nevhodného algoritmu pro předzpracování dat. Z tohoto důvodu se proces klasifikace musí dělit na další procesy, které se starají o jednotlivé části zpracování dat [8]. Těmito procesy je předzpracování dat, analýza dat a klasifikace dat. Všechny tyto procesy jsou zapojeny sériově a výstup z jednoho procesu je brán jako vstup dalšího procesu. Prvním procesem, do kterého vstupují surová neboli nezpracovaná data, je předzpracování dat. Během tohoto procesu dochází k čištění a filtraci dat. V podstatě dochází k odstraňování šumu (nedeterministické složky). Jak bylo uvedeno výše, pro každý charakter dat je třeba vybrat vhodný algoritmus předzpracování, protože by jinak mohlo dojít k dalšímu přidání rušení. Proces předzpracování rozděluje data podle jejich charakteru na statická a dynamická. Statická data se v průběhu času nemění, proto je jejich zpracování jednodušší. Dynamická data musí zachovávat určité uspořádání, protože na čase závisí (časové řady, signály) [8].


19

Druhým procesem zpracování dat je analýza dat. Analýza je zde chápána jako hledání důležitých vlastností a zákonitostí v datech. Dále zde dochází k hledání proměnných, na základě nichž bude probíhat celková klasifikace nebo predikce. Pro řešení problému algoritmického hledání těchto proměnných zatím neexistuje žádný algoritmus, proto se pro tento výběr používá empirická znalost o problému [8]. Posledním procesem při zpracování dat je klasifikace dat. Zde už dochází k finálnímu rozdělování množiny objektů, jevů nebo procesů do konečného počtu kategorií, kde jednotlivé prvky výsledných kategorií mají podobné vlastnosti. Klasifikaci dat se provádí pomocí klasifikátoru, kde je na vstup přiveden klasifikovaný objekt x. Tento objekt se na základě rozhodovacího pravidla klasifikátoru d(x) převádí na výsledné klasifikační třídy ωr, kde r je identifikátor klasifikační třídy [8]. Obecně je možné chápat klasifikaci jako učení s učitelem. Základní algoritmy klasifikace jsou následující [4]: • rozhodovací stromy, • k-nejbližších sousedů, • lineární regrese, • Bayesův klasifikátor, • neuronové sítě, • SVM (algoritmus podpůrných vektorů). Jedním z nejúčinnějších algoritmů pro detekci spamu na základě analýzy slov je Bayesův klasifikátor [9]. Schopnosti tohoto algoritmu mohou být využity i v případě analýzy odkazů, kde se každý odkaz skládá z množiny slov stejně jako při analýze e-mailových zpráv [4]. Z tohoto důvodu a z důvodu jednoduchosti implementace se Bayesův klasifikátor jeví jako vhodný pro problém klasifikace webových odkazů. 2.2.3

Bayesův klasifikátor

Bayesův klasifikátor funguje na principu teorie pravděpodobnosti, konkrétně slouží k výpočtu aposteriorní (podmíněné) pravděpodobnosti. Základním stavebním kamenem tohoto klasifikátoru je Bayesův teorém, který představuje matematický model klasifikátoru. Na základě tohoto matematického modelu dochází k zpřesňování původní hypotézy, což způsobuje odkrývání nových skutečností. Prakticky jsou nejprve jednotlivým jevům přirazeny určité apriorní (počáteční) pravděpodobnosti. Následně je pomocí Bayesova teorému spočítána výsledná aposteriorní (podmíněná) pravděpodobnost. Bayesův klasifikátor se běžně používá pro řešení mnoha různých problémů, kde použití jiných technik selhává (detekce spamu). Základní vzorec, který je nazýván Bayesův teorém, má následující tvar [8]:


20

|

=

|

Bayesův teorém slouží k výpočtu podmíněné pravděpodobnosti jevu A za předpokladu, že nastal jev B. K tomu využívá P(A) a P(B), což jsou apriorní (počáteční) pravděpodobnosti jevů A a B. Dále je zde použit výraz P(B|A), což je aposteriorní (podmíněná) pravděpodobnost jevu B za předpokladu, že nastal jev A [8]. Bayesův klasifikátor lze na základě výsledné podmíněné pravděpodobnosti použít pro zařazení vstupních dat do určité třídy. Tato klasifikace využívá tzv. mezní hodnotu, po jejíž překročení jsou vstupní data klasifikována do první třídy, jinak jsou klasifikována do druhé třídy. Jelikož se Bayesův klasifikátor běžně využívá pro klasifikaci textu, bude jej možné také použít pro klasifikaci webových odkazů [4].

2.3 Dolování obsahu webových stránek Jak bylo zmíněno v kapitole 2.1, web content mining se používá pro dolování obsahu webových stránek. Jelikož jsou webové stránky běžně strukturované pomocí HTML značek, pro získávání obsahu se mluví jako o extrakci strukturovaných dat z webových stránek. Pro extrakci strukturovaných dat z webových stránek se používají tři různé přístupy [4]: • manuální extrakce, • poloautomatická extrakce, • automatická extrakce. Rozdíl mezi těmito přístupy je v množství práce, kterou musí programátor vykonat, než bude možné extrahovat další webovou stránku. Manuální extrakce vyžaduje největší zapojení programátora, protože ten musí pro každou novou stránku vytvořit manuálně šablonu, pomocí které bude extrakce probíhat. Poloautomatická extrakce vyžaduje vytvoření označených trénovacích dat, pomocí nichž proběhne učení klasifikátoru. Aby byly výsledky co nejlepší, je potřeba mít dostatečný počet označených dat, která budou pokrývat co nejvíce možných typů vzorů ve stránkách. Nejpokročilejší a zároveň nejsložitější na vytvoření je automatická extrakce. Zde se jedná o učení bez učitele, neboť extrakční program nedostane žádná označená data a natrénovat se musí sám na neoznačených datech. Z tohoto důvodu je potřeba mít velké množství reálných dat, na kterých proběhne učení extrakčního algoritmu. V opačném případě může jednoduše dojít k špatnému naučení algoritmu, což nutně vede ke špatné extrakci [4]. Pro vytvoření extrakční šablony tak, aby byla zajištěna její opětovná použitelnost, je možné použít algoritmus extrakce datových záznamů [5].


2.3.1

21

Algoritmus extrakce datových záznamů

Webová stránka je chápána jako množina kořenových (root-to-link) cest v DOM stromu (stromu objektového modelu dokumentu) [11]. Pro tento strom se používá označení schéma stránky [12]. V této struktuře je potřeba hledat množinu podobných struktur, které jsou vloženy pod jeden rodičovský uzel a vytváří zde podstromy. Těmto strukturám se říká datové záznamy. Ty je možné chápat jako podmnožiny DOM stromu, které mají obecně několik společných strukturálních vlastností, a to [13]: • stejný rodičovský uzel, • stejný počet poduzlů (child nodes), • jsou vždy sousední. Důležité je zjištění, že datové záznamy jsou většinou formátovány stejnými HTML tagy [13]. Zároveň mají odkazy vedoucí na stránky s podobnými datovými záznamy také podobný tvar [10].

Obr. 4

Schéma stránky s dvěma podobnými datovými záznamy (zdroj: [13])

Předchozí zjištění umožňuje jednotlivé podstromy uspořádat do tříd podle struktury a vytvořit algoritmus, který bude umět hledat datové záznamy na základě jejich struktury na jakékoliv stránce.


Obr. 5

22

Jedna z možných konfigurací datových záznamů (zdroj: [13])

Algoritmus extrakce datových záznamů je možné definovat následovně. Nejprve jsou na stránce nalezeni všichni kandidáti, kteří mohou odpovídat naučenému datovému záznamu. V druhém kroku probíhá porovnávání vnitřních struktur podstromů takto nalezených kandidátů s vnitřní strukturou naučeného datového záznamu. Pokud dojde ke shodě vnitřních struktur, je možné kandidáta prohlásit za nově nalezený datový záznam. Tento algoritmus hledání datových záznamů je i pro rozsáhlé webové stránky rychlejší než analýza souvislostí mezi jednotlivými textovými řetězci [10].

Metodika řešení

23

3 Metodika řešení Jelikož hlavním cílem této práce je vytvoření funkční aplikace, musí metodika práce toto reflektovat. Každá aplikace si musí projít několika fázemi životního cyklu. Těmito fázemi jsou [14]: • specifikace problému, • analýza a návrh aplikace, • implementace aplikace, • testování, • provoz a údržba. Fáze specifikace problému představuje většinou slovní popis funkce aplikace. Další fází je analýza a návrh aplikace. Tyto fáze jsou většinou propojené, protože během analýzy dochází i k hrubému návrhu aplikace. Cílem těchto fází je dekompozice problému na jednotlivé podproblémy a návrh řešení jednotlivých podproblémů. Poté následuje fáze implementace aplikace, kdy je za použití zvolených programovacího jazyků a nástrojů aplikace programována. Součástí této fáze by mělo být i pravidelné testování, protože se tím může zamezit pozdějším nepříjemnostem. Nakonec po provedení celkového testování aplikace dochází k uvedení aplikace do provozu. Nyní už programátor provádí pouze údržbu aplikace, a to až do konce životního cyklu aplikace [14]. Jelikož fáze specifikace problému představuje pouze slovní popis celé aplikace, budou nyní rozebrány metodické postupy pro následující fáze životního cyklu aplikace.

3.1 Analýza a návrh aplikace Jak bylo zmíněno výše, cílem analýzy je dekompozice aplikace na jednotlivé podproblémy. K této dekompozici se používají dva přístupy [14]: • strukturovaná analýza, • objektová analýza. Pro zpracování analýzy v této práci byla zvolena objektová analýza, protože umožňuje k modelování využít vizuální modelovací jazyk UML (Unified Modeling Language) [14]. V objektovém přístupu k analýze aplikace dochází k dekompozici aplikace na jednotlivé objekty. Objekt je zde chápán jako model určité části reálného světa. Uchovává v sobě atributy, které představují důležité vlastnosti reálného vzoru. K těmto vlastnostem se přistupuje pomocí metod aktuálního objektu nebo metod jiného objektu. Jelikož objekt představuje model reálně existující části světa, používá se pro obecný popis objektu třída. Z tohoto důvodu představuje třída tzv. předpis, který definuje, jak má objekt vypadat a jakou má mít strukturu [14]. Jelikož dekompozice aplikace na jednotlivé objekty lze provést mnoha

Metodika řešení

24

různými způsoby, které mohou ovlivnit budoucí znovu použitelnost částí aplikace, využívá se proto tzv. návrhových vzorů [15]. Návrhové vzory jsou postupy, které řeší často se opakující problémy ve fázi návrhu aplikace. Tyto postupy představují optimální, praxí ověřené řešení různých problémů. Existuje mnoho různých druhů návrhových vzorů, každý je určen pro řešení jiného typu problému. Z tohoto důvodu bývají návrhové vzory rozděleny do skupin podle typu problému, který řeší. Těmito skupinami jsou návrhové vzory [15]: • týkající se tvorby objektů (tvořivé vzory), • zabývající se kompozicí různých objektů (strukturální vzory), • zabývající se interakcí různých objektů (vzory chování). Skupina tvořivých vzorů obsahuje návrhové vzory, které se zabývají vytvářením instancí objektů. Konkrétně se jedná o omezení používání operátoru new. Tento operátor se používá v mnoha programovacích jazycích pro tvorbu nového objektu a jeho omezeným používáním lze získat kontrolu nad tvorbou nových objektů. Oproti tomu skupina strukturálních vzorů obsahuje návrhové vzory, které umožňují spojovat objekty do větších struktur. Výhodou těchto vzorů je, že není nutné měnit původní objekty. V poslední skupině se nachází návrhové vzory, které se zabývají interakcí a chováním mezi jednotlivými objekty. V podstatě se tato skupina zabývá metodami, kterými mezi sebou objekty a struktury objektů komunikují [15]. Návrhové vzory úzce souvisí s jazykem UML. Konkrétně se tento jazyk používá pro popis jednotlivých vzorů pomocí diagramu tříd [15]. Jazyk UML používá i další modely, které usnadňují analýzu a návrh aplikace. Jedná se o diagram případů použití (use-case diagram), stavový diagram, diagram objektů, diagram spolupráce, diagram sekvencí, diagram činností, diagram komponent a diagram nasazení [14]. Každý z diagramů představuje jiný pohled na řešený problém. V této práci budou nejčastěji používány diagramy případů užití a diagramy tříd. Diagram případů užití představuje pohled na systém z hlediska uživatelů systému a toho, co mohou uživatelé se systémem dělat. Jednotlivými prvky diagramu jsou aktéři a případy užití. Aktéři jsou skupiny uživatelů, které mohou se systémem pracovat. Případy užití představují funkcionalitu systému, kterou mohou aktéři provádět. Aktéři a případy užití jsou propojeny pomocí relací (vazeb), čímž je definováno, který aktér může s daným případem užití pracovat. Druhým typem diagramu používaný v této práci je diagram tříd. Tento diagram představuje statický pohled na systém, skládající se z jednotlivých tříd a vazeb mezi nimi [14]. Pro usnadnění vytváření UML diagramů bude v této práci využit modelovací nástroj Microsoft Visio 2013, který umožňuje jednoduchou tvorbu různých diagramů [16].

Metodika řešení

25

3.2 Implementace aplikace Pro implementaci aplikace je potřeba zvolit vhodné technologie, pomocí kterých bude celý systém vytvořen. Jelikož tato aplikace musí být dostupná velkému množství uživatelů, nejlepší volbou bude vytvořit celý systém jako webovou aplikaci. Tato webová aplikace může být vytvořena za použití mnoha různých technologií, avšak každá má jiné požadavky na webový server, na kterém může být spuštěna. Pokud mají být minimalizovány náklady na provoz aplikace, je možná pouze jediná volba. Tou volbou je webový server Apache, který běží na mnoha portálech společností poskytujících hosting webových stránek. Tyto společnosti většinou umožňují použití pouze jediného programovacího jazyku pro hosting zdarma. Tímto programovacím jazykem je PHP a k němu bývá dostupný databázový server MySQL [17]. Příkladem takové společnosti poskytující hosting zdarma je Hostinger [18]. Na skriptovacím jazyku PHP jsou založené PHP frameworky, což jsou softwarové struktury, které usnadňují proces tvorby aplikace. Usnadnění je dosaženo tím, že framework obsahuje jednoduché programovací rozhraní (API), které umožňuje jednoduše řešit časté problémy při tvorbě aplikace. Všechny frameworky jsou vytvořeny na základě návrhových vzorů a doslova nutí programátora, aby psal znovupoužitelný kód [19]. Asi celosvětově nejpopulárnější ze všech PHP frameworků je Zend Framework 2 [20]. V této práci však bude využit Nette Framework, protože je to moderní framework, který v českém prostředí patří mezi nejpoužívanější a nejpopulárnější [21]. 3.2.1

Nette Framework

Autorem Nette Frameworku je David Grudl, který tento framework uvolnil v roce 2004 jako open source. O vývoj frameworku se stará autorem založená společnost Nette Foundation, která na začátku roku 2014 uvolnila framework ve verzi 2.1.1. Framework je založen na softwarové architektuře MVC (Model View Controller). Architektura MVC [22] odděluje kód aplikační logiky (model) od kódu zobrazující data (view) a od kódu obsluhy (controller). Jde tedy o oddělení do tří logických částí. V Nette je pro Controller použit název Presenter, protože na základě příchozího požadavku (akce) presentuje HTML stránku. Tím je zpřehledněn kód celé aplikace, což zjednodušuje vývoj a testování jednotlivých částí aplikace [21]. Existují tři druhy vazeb mezi jednotlivými komponentami architektury MVC. Konkrétně obsahuje Controller vazbu na Model, aby mohl upravovat data Modelu. Dále View má vazbu na Model. Třetí vazba mezi View a Controllerem se používá pouze u některých typů architektur, a to jednosměrná nebo obousměrná. Důležitou vlastností MVC architektury je, že Model nikdy neobsahuje vazbu na View nebo Controller. Další významnou vlastností Modelu je, že neslouží pouze pro práci s databází. Může být použit pro mnoho různých datových zdrojů, kde databáze je pouze jedním z mnoha. Příkladem dalších takových zdrojů je RSS, textové soubory, webové služby a další [22].

Metodika řešení

26

Nette Framework má v sobě integrováno mnoho technologií, které usnadňují programátorovi práci. Příkladem jsou propracované ladící nástroje, které se starají o kompletní diagnostiku aplikace, automatické zabezpečení ošetřující výskyt bezpečnostních děr, propracovaná tvorba a ošetření formulářů, podpora šablon, znovu použitelnost logických částí aplikace na základě pluginů a další podpora mnoha různých moderních technologií. Jelikož Nette provádí některé procesy už na straně klienta, k jejich zjednodušení využívá javascriptový framework jQuery [21]. 3.2.2

jQuery

jQuery je malá, rychlá a volně dostupná javascriptová knihovna [23]. Funguje ve všech běžně používaných webových prohlížečích. Slouží ke zjednodušení práce s objektovým modelem dokumentu [11], umožňuje zpracování událostí, manipulaci s kaskádovými styly (CSS), animace, podporuje pluginy a zjednodušuje implementaci technologie AJAX (Asynchronous JavaScript and XML) [24]. To vše je dostupné díky jednoduše použitelnému programovacímu rozhraní. Knihovnu jQuery poprvé veřejnosti představil John Resig v roce 2006 a od té doby se stala knihovna velmi známou a podporovanou mnoha známými společnostmi jako WordPress, Intel, Microsoft a dalšími [23]. 3.2.3

AJAX

Webové aplikace postavené na bezstavovém protokolu HTTP mají několik závažných nedostatků. Pro změnu stavových proměnných je vždy potřeba načíst další stránku. Zároveň je zde problém s přenosem stavových proměnných. Tyto dva velmi omezující nedostatky vedly ke vzniku technologie AJAX (Asynchronous JavaScript and XML). Technologie AJAX umožňuje tvorbu dynamických aplikací, které interaktivně reagují na uživatelovy požadavky. K tomu je využívána kombinace technologií HTML, XHTML, XML, CSS a JavaScript [24]. Nejdůležitější částí technologie AJAX je JavaScript. Pomocí něj se provádí asynchronní komunikace s webovým serverem a pomocí něj dochází k manipulaci s HTML a CSS objektového modelu dokumentu (DOM). Tímto způsobem dojde ke změně webové stránky, aniž by ji bylo potřeba znova načíst. Pro komunikaci webového prohlížeče s webovým serverem se používá objekt XMLHttpRequest. Pomocí tohoto objektu dochází k asynchronnímu přenosu XML formátovaných bloků. K přenosu se však nemusí používat vždy XML, je možné použít mnoho dalších formátů jako prostý text, HTML kód nebo JSON [24]. Technologie AJAX má jako každá technologie určité výhody i nevýhody. Hlavní výhodou je výrazné urychlení běhu webové aplikace. Toho je dosaženo tím, že stránku není potřeba po akci uživatele načítat celou. Vždy se odesílá jen určitý blok stránky, ve kterém došlo ke změně. Zároveň tak dochází ke snížení množství dat, které jsou mezi klientem a serverem přeneseny. Hlavní nevýhodou použití technologie AJAX je, že protokol HTTP není stavěn na velký provoz mezi klientem a serverem. Proto je třeba při každém požadavku klienta na ser-

Metodika řešení

27

ver vždy navazovat nové spojení. Další nevýhodou je, že komunikaci navazuje vždy webový klient. Tato nevýhoda se nejvíce projeví v aplikacích, kdy klient potřebuje být upozorňován na změny na serveru. Z tohoto důvodu, se klient musí periodicky dotazovat na stav serveru, i když ke změně stavu nedošlo [24]. 3.2.4

Cron

Jelikož je PHP skriptovací jazyk, skripty tohoto jazyka neběží na serveru stále. Pouze pokud uživatelův webový prohlížeč odešle požadavek na HTML kód stránky, dojde ke spuštění PHP skriptu, který HTML kód stránky generuje. Po vygenerování kódu stránky dojde k ukončení běhu skriptu. V PHP je zároveň defaultně omezena maximální doba běhu skriptu na 30 sekund, aby nebyl zbytečně přetěžován webový server [17]. Z tohoto důvodu je potřeba některé skripty spouštět opakovaně, než je dosaženo např. extrakce všech dostupných aukčních výsledků na portálu s aukčními výsledky. K opakovanému spouštění PHP skriptů se využívá linuxový softwarový démon Cron [25]. Jedná se o softwarovou službu, která je spuštěna po startu počítače a běží na pozadí neustále. Uživatel může za pomoci konfiguračního souboru crontab definovat, jak často se má provádět určitá akce. Příkladem takové akce může být i spuštění PHP skriptu pomocí PHP interpreteru operačního systému. Proces Cron kontroluje soubor crontab každou minutu a spouští všechny příkazy, jejichž záznam odpovídá aktuálnímu času. Každý záznam v konfiguračním souboru crontab se nachází na jednom řádku a má následující formát [26]: <minuty> <den v měsící> <měsíc> <den v týdnu>

Tagy ve špičatých závorkách představují proměnné, za které jsou dosazovány různé hodnoty. Například tag <minuty> může být nahrazen číselnou hodnotou v rozmezí 0–59. Tato hodnota udává, kolikátou minutu v hodině se bude příkaz spouštět. Další možností je místo číselné hodnoty použít znak hvězdičky, který v tomto případě znamená spouštění příkazu každou minutu v hodině. U ostatních tagů je situace podobná, jenom rozmezí čísel je jiné. Pouze tag musí obsahovat cestu k spustitelnému souboru nebo PHP interpreteru [26]. 3.2.5

MySQL

Aby bylo možné data aplikace ukládat, je pro to třeba nejprve zvolit vhodný nástroj. Ideálním řešením se jeví využití databázového systému MySQL [17]. Jak už bylo popsáno na začátku této kapitoly, MySQL bylo zvoleno, protože je dostupné na mnoha serverech hostingových společností zdarma. Zároveň se jedná o nástroj, který umožňuje běh nejen jednoduchých, ale i profesionálních aplikací [17]. K vizualizaci struktury databáze a znázornění propojení mezi jednotlivými tabulkami bude potřeba využívat nějaký program, který tuto činnost maximálně

Metodika řešení

28

zjednoduší. K tomuto účelu lze použít modelovací program MySQL Workbench [27]. Tento program umožňuje vizuálně navrhovat, modelovat, generovat a spravovat databáze pro databázový systém MySQL. Kromě těchto činností zvládá vytváření, spouštění a optimalizaci SQL dotazů. Výsledné diagramy je možné exportovat do mnoha různých formátů nebo z nich automaticky vygenerovat SQL CREATE skripty [27]. Z tohoto důvodu se program jeví jako ideální kandidát pro modelování celé struktury databáze.


29

4 Analýza a návrh aplikace Před započetím fáze analýzy a návrhu aplikace je potřeba nejprve projít fází specifikace problému [14]. Jelikož byl cíl práce už specifikován, bude se fáze specifikace problému zabývat jeho podrobnějším rozborem.

4.1 Specifikace problému Cílem práce je vytvořit aplikaci, která bude svým uživatelům poskytovat podporu pro rozhodování o nákupu nebo o době vhodného prodeje na sálových aukcích aukčních společností. Podporou pro rozhodování je myšleno nabídnutí relevantních historických aukčních výsledků pro zadaný dotaz. Toho bude dosaženo automatizovanou extrakcí dat z webových stránek s aukčními výsledky. K tomuto účelu bude aplikace využívat extrakčního robota, který se, po základním nastavení pro webovou stránku dané aukční společnosti, o extrakci už sám postará. Proces přidání nového webu pro extrakci bude probíhat následovně. Nejprve administrátor do aplikace zadá úvodní URL adresu stránky, na které se nacházejí odkazy na jednotlivé aukční výsledky. Poté bude probíhat tvorba extrakční šablony, na základě které bude moci robot obsah stránky správně interpretovat. K tomuto účelu bude možné využít algoritmus automatické extrakce datových záznamů [5][10][12][13], díky čemuž se proces tvorby šablony výrazně zjednoduší. Po označení jednoho bloku s aukčním výsledkem si už robot sám dohledá všechny ostatní. Díky tomu bude definice šablon dost obecná na to, aby extrakce fungovala co nejlépe a zaručila určitou schopnost správné extrakce i po menší změně struktury webových stránek. Robot bude muset také umět automatizovaně extrahovat měny a časové údaje, případně je převést do standardního formátu. Aby byl robot schopný extrahovat všechny aukční výsledky, bude muset automatizovaně procházet odkazy nacházející se na webových stránkách. Z toho plyne, že si bude muset pamatovat navštívené odkazy a bude muset být schopen rozlišovat mezi odkazy, které vedou na stránky s aukcemi a které na ně nevedou. Pro automatickou funkčnost celé extrakce bude nutné vytvořit alespoň jednoduchý plánovač, který bude činnost robota řídit. Extrakční robot musí být funkční nezávisle na zbytku aplikace, aby byla zajištěna možnost provozu extrakčního robota na jiném serveru, než bude zbytek aplikace. Z tohoto důvodu bude celá aplikace rozdělena na dvě části. První částí bude dříve popsaný extrakční robot. Druhá část aplikace bude prezentovat extrahovaná data uživateli. Tato část bude představovat vyhledávač, kde po zadání údajů o hledané položce budou nalezeny co nejrelevantnější informace o historických aukčních výsledcích z různých webů aukčních společností. Díky těmto informacím bude aplikace uživateli poskytovat podporu pro rozhodování o správném nákupu nebo o vhodné době prodeje na sálové aukci.


30

4.2 Analýza a návrh extrakčního robota Jak bylo popsáno ve fázi specifikace problému, aplikace bude rozdělena na dvě části. První částí je extrakční robot, který se bude starat o extrakci dat z webových stránek různých aukčních společností. Pro analýzu této části je potřeba identifikovat, jak jednotlivé entity interagují se systémem. K tomuto účelu je nejvhodnější použít diagram případů užití [14]. Tento diagram obsahuje dva aktéry, kde první představuje administrátora aplikace a druhý představuje časové spouštění souboru pomocí linuxového softwarového démona Crona [25]. Po přihlášení do administrátorského rozhraní aplikace může administrátor zobrazovat logovací soubor robota, naplánované akce a vytvářet extrakční šablony pro webové stránky. Cron provádí pouze časové spouštění plánovače, což má za následek vygenerování nové akce nebo sekvence akcí a následné provedení poslední akce s nejvyšší prioritou.

Obr. 6

Diagram případu užití extrakčního robota

Jelikož je základní funkčností extrakčního robota extrakce dat z webových stránek, bude v následujících odstavcích podrobněji rozebrán proces extrakce. První fází extrakce je tvorba extrakční šablony, na základě které bude možné extrakci provést. 4.2.1

Proces tvorby extrakční šablony

Extrakční šablonu lze vytvářet různými způsoby. Jelikož nastavení extrakčního robota nemá vyžadovat informatické znalosti, musí tvorba šablony probíhat in-


31

teraktivně. První možností je využití kurzoru myši pro označování jednotlivých prvků stránky. Tento postup je zbytečně složitý a zdlouhavý, protože nutí administrátora aplikace k postupnému označování jednotlivých prvků stránky. Tento přístup má další nevýhodu. Pokud nějaký prvek stránky nebude označen, nebude také extrahován. Z tohoto důvodu se jeví jako mnohem lepší využít algoritmus extrakce datových záznamů [5][10][12][13]. Na základě této techniky bude stačit, pokud uživatel označí jeden blok stránky a jednotlivé prvky v něm. O zbytek už se postará extrakční robot, který dohledá všechny ostatní bloky stránky, přičemž nebude záležet, jaké má webová stránka uspořádání, případně kolik bloků celkem je. 4.2.2

Proces extrakce

Po vytvoření extrakční šablony může začít proces extrakce. Tento proces funguje následujícím způsobem. Extrakční robot začíná na stránce, kterou zadal administrátor jako výchozí URL adresu pro daný web. Na této stránce se nachází seznam odkazů na stránky s aukčními výsledky. Robot musí být schopen rozpoznat, který odkaz vede na stránku s aukčními výsledky a který naopak ne (na Obr. 7 zelené a červené čáry). K tomu může být použit Bayesův klasifikátor [4][8], který provede analýzu slov v odkazu a na základě podmíněné pravděpodobnosti určí míru relevance odkazu. Poté už stačí, aby robot z množiny odkazů směřujících na aukční výsledky vybral jeden ještě nezpracovaný a načetl webovou stránku nacházející se za ním.

Obr. 7

Proces extrakce

Na základě dříve vytvořené extrakční šablony už robot sám pozná, zda se na stránce nachází nějaké aukční výsledky. Pokud se na stránce aukční výsledky


32

nebudou nacházet, předpokládá se, že se robot nachází na tzv. přehledu aukce. Tento přehled většinou představuje rozcestník pro návštěvníka webu a slouží k zjednodušení navigace mezi jednotlivými částmi aukce (zlato, středověk, novověk, …). Robot proto analyzuje všechny odkazy na webové stránce a pokusí se najít odkaz na první stranu aukce. Poté načte stránku nacházející se za tímto odkazem a za pomoci extrakční šablony ji extrahuje. Proces dále pokračuje procházením jednotlivých stránek s aukčními výsledky. Cílem je, aby extrakční robot postupně prošel všechny stránky a následně je extrahoval. Proces končí, když robot navštíví všechny odkazy, tudíž už nezbývá žádný, který by na stránku s aukčním výsledkem vedl. Posledním krokem je uložení všech výsledků do databáze. Během extrakce samozřejmě musí docházet k automatickému rozpoznávání měn, časových údajů a k jejich převodu do standardního formátu. 4.2.3

Proces standardizace měn a časových údajů

Aby byl robot schopen provádět korektní extrakci dat z různých webových stránek, které používají různé formáty pro měny a časové údaje, musí obsahovat funkce pro automatické rozpoznávání a standardizace těchto dat. Robot nebude schopen rozpoznávat, na jakém místě webové stránky se nachází měna nebo časový údaj ke standardizaci. K tomuto účelu bude robot používat extrakční šablonu. Každé pole extrakční šablony bude mít nastaveno, zda se má kromě extrakce provádět i standardizace dat. Z tohoto důvodu se bude např. pole extrahující datum aukce snažit toto datum extrahovat a následně i standardizovat do formátu, který umožní jeho uložení do databáze. To stejné bude platit o polích s vyvolávací a konečnou cenou předmětu. Zde se robot bude snažit provést extrakci a standardizaci měn. Standardizace bude v obou případech zjednodušena pomocí regulárních výrazů [28]. Regulární výrazy představují druh textového vzoru, který lze využít pro vyhledání a filtrování dat. Vzory jsou definovány pomocí obecné notace, díky čemuž je zaručena jejich budoucí znovupoužitelnost. Existuje několik různých formátů zápisu regulárních výrazů, všechny ale vychází ze syntaxe jazyka Perl. V PHP se pro zápis regulárních výrazů používá formát PCRE (Perl-Compatible Regular Expressions), což je knihovna regulárních výrazů napsaná v jazyce C a kompatibilní s jazykem Perl. Regulární výrazy nemusí být použity pouze pro hledání a filtrování dat, lze je použít i pro dynamické nahrazování textů. Jedná se o opětovné použití částí textu, které odpovídají danému vzoru v regulárním výrazu [28]. Tímto způsobem lze standardizaci měn a časových údajů zjednodušit. 4.2.4

Automatizace extrakčního robota

Extrakční robot musí obsahovat alespoň jednoduchý plánovač, který zajistí automatizované provádění akcí. O periodické spouštění plánovače se postará linuxový démon Cron [25]. Na základě provedení PHP skriptu dojde ke spuštění plánovače, který se už postará o provedení příslušné akce. Pokud nebude žádná akce dostupná, plánovač vygeneruje novou akci nebo více nových akcí a spustí


33

jednu z akcí. Z tohoto vyplývá, že každé spuštění PHP skriptu se bude rovnat provedení jedné akce extrakčního robota. Akce představují činnosti, které bude moci webový robot provádět. Ty budou dvojího typu. Pokud databáze plánovače nebude obsahovat žádnou akci, vygeneruje plánovač akci získání všech platných odkazů na jednotlivé aukční výsledky na jedné webové stránce. Po provedení této akce se v databázi plánovače vytvoří množina akcí, které budou představovat extrakce jednotlivých aukčních výsledků. Po provedení akce extrakce dojde k extrakci dat jedné webové stránky s aukčními výsledky. Součástí extrakce bude i uložení extrahovaných dat do databáze, která bude moci být na jiném serveru než extrakční robot. 4.2.5


Po prozkoumání jednotlivých procesů, ke kterým bude v extrakčním robotovi docházet, lze přejít k tvorbě diagramu tříd robota. Tento diagram obsahuje jednotlivé třídy, rozhraní a vztahy mezi nimi. Vše je zatím bez atributů a metod jednotlivých tříd. Takto zjednodušený diagram tříd je přehlednější. Diagram tříd extrakčního robota je znázorněn na Obr. 8. Základním prvkem diagramu je třída Robot, která představuje extrakčního robota provádějícího extrakci. Tato třída využívá pro různé účely další bloky tříd, které jsou v diagramu označeny jako zelené obdélníky. Mezi tyto bloky tříd patří Debugger, Exceptions, Database, Extractor a Scheduler. První blok Debugger je blok tříd sloužících k výpisu a logování informací o stavu a chybách, ke kterým došlo během činnosti robota. Dalším blokem je Exceptions. Tento blok představuje výjimky, které jsou vyhazovány, pokud dojde při běhu extrakčního robota k chybě. Extrakci robot provádí pomocí třídy Extractor. Tato třída se stará o stahování webových stránek a jejich další zpracování. Ke zpracování stránky používá třída Extractor třídu Template, což je extrakční šablona. Na základě použití extrakční šablony na webovou stránku dojde k extrakci dat a jejich uložení do třídy PageData. Poté může dojít extrakci odkazů z webové stránky. K účelu uložení extrahovaných odkazů se používá pomocná třída Link. Po extrakci dat z webové stránky může dojít k jejich uložení do databáze. K tomuto účelu aplikace používá blok tříd Database. V tomto bloku se nachází dvě možnosti, jak se připojit ke vzdálené databázi. K uložení do databáze na stejném serveru, kde probíhá extrakce, se používá třída DB. Pokud databáze neumožňuje připojení pomocí předchozí třídy, lze využít třídu RemoteDB. Aby mohl extrakční robot provádět svou činnost automatizovaně, provádí jeho řízení třída Scheduler. Tato třída představuje plánovač, která se stará o vytváření a zpracovávání akcí, které následně robot vykonává.


Obr. 8

34


Diagram také obsahuje čtyři další třídy, které se nenacházejí v žádném bloku. Těmito třídami jsou HTML, User, Factory a BayesFilter. Třída HTML slouží ke generování HTML kódu stránek. Třída User se stará o správu uživatelů extrakč-


35

ního robota a přihlašování do administrace. Dále třída Factory se používá pro jednoduché vytváření instancí objektů tříd a jejich zpřístupňování dalším třídám. Nakonec třída BayesFilter implementuje Bayesův filtr pro analýzu webových odkazů. 4.2.6


Schéma databáze extrakčního robota je znázorněno na Obr. 9 a má celkově sedm tabulek. Pro přihlášení uživatelů do administrace extrakčního robota slouží tabulka user. Přístup do administrace nebude umožněn všem uživatelům, pro přihlášení musí daný uživatel patřit do skupiny administrátorů. Tabulka uživatelů má stejný tvar jako tabulka user vyhledávače. To je z důvodu kompatibility, aby bylo možné používat obě části databáze v jedné na jednom databázovém serveru.

Obr. 9


Databáze dále obsahuje tabulky bayesfilterdata a bayesfilter. Tyto tabulky slouží k ukládání Bayesových filtrů [4][8] a označených dat, které se dále používají pro klasifikaci do různých tříd. Pro označování dat na pozitivní a negativní příklady se používá atribut tag tabulky bayesfilterdata. Důležitou částí databáze jsou tři tabulky, které se starají o ukládání extrakčních šablon. Těmito tabulkami je auction_list, template a base_path. Jak bylo zmíněno v předchozích kapitolách, šablona se skládá z cest objektového modelu dokumentu. Prakticky slouží tabulka template k ukládání relativních XPath cest a tabulka base_path slouží k ukládání absolutních XPath cest od kořenového elementu dokumentu. Aktualizací dat v tabulce base_path lze umož-


36

nit funkčnost extrakce i při změně struktury webových stránek. Poslední z trojice tabulek auction_list slouží k uchovávání počátečních URL adres, na kterých se má extrakce provádět. Poslední tabulkou v databázi extrakčního robota je scheduler_action. Tato tabulka slouží k ukládání akcí, které vygeneroval plánovač extrakčního robota. U každé akce se ukládá typ akce, priorita a příznak provedení akce. Příznakem provedení je zaručeno, že se žádná akce neprovede vícekrát a nedojde k vícenásobné extrakci. Tvar jednotlivých akcí a způsob jejich použití bude vysvětlen později. Nyní bude rozebrána druhá část aplikace, a to vyhledávač.

4.3 Analýza a návrh vyhledávače Stejně jako extrakční robot, musí mít i vyhledávač svůj diagram případů užití. Tento diagram bude obsahovat aktéry a činnosti, které budou moci v aplikaci provádět.

Obr. 10

Diagram případů užití vyhledávače

Vyhledávač bude mít tři typy aktérů (neregistrovaného uživatele, registrovaného uživatele a administrátora). Nejméně činností bude moci provádět neregistro-


37

vaný uživatel. Jemu bude umožněno pouze vyhledávat s omezením na maximálně deset možných výsledků. Pokud se neregistrovaný uživatel v aplikaci zaregistruje, vznikne aktér registrovaný uživatel. Registrace nového uživatele bude podmíněna systémem registračních pozvánek, což umožní kontrolu nad tím, kdo bude moci používat pokročilé funkce aplikace. Aktér registrovaný uživatel bude moci vyhledávat bez omezení a zároveň bude mít dostupné pokročilé vyhledávání. Registrovaný uživatel bude dále moci prohlížet jednotlivé aukce a aukční výsledky nebo provádět nastavení svého účtu. Také si bude moci nalezené aukční položky přidávat mezi své oblíbené. Vše bude samozřejmě podmíněno přihlášením do aplikace. Pokud by se náhodou uživateli stalo, že zapomene heslo, bude si ho moci resetovat. V tomto případě bude uživateli odesláno nové náhodně vygenerované heslo na e-mail. Tímto způsobem bude odbourána nutnost akce administrátora aplikace při ztrátě hesla uživatele. Nejvyšší práva bude mít administrátor aplikace. Tento aktér bude moci provádět stejné činnosti jako registrovaný uživatel. Zároveň bude moci spravovat jednotlivé uživatele, zobrazovat historii vyhledávání, zobrazovat systémové logy a generovat pozvánky pro registraci do aplikace. 4.3.1

Proces registrace

Životní cyklus registrovaného uživatele začíná registrací do aplikace. Jelikož aplikace nebude podporovat běžnou registraci, jedinou možností, jak se z neregistrovaného uživatele stane uživatel registrovaný, je registrace prostřednictvím systému registračních pozvánek. Tímto omezením bude zaručeno, že pokročilé funkce budou dostupné pouze administrátorem vybraným uživatelům. Pokud se administrátor přihlásí do aplikace, bude mít v administrátorské části možnost správy registračních pozvánek. Touto pozvánkou je myšlena speciální URL adresa s unikátně vygenerovaným klíčem. Pokud neregistrovaný uživatel použije tuto URL adresu, bude mít možnost vytvořit nový uživatelský účet. Tento proces bude možné v průběhu ukončit bez ztráty platnosti pozvánky. Pouze pokud neregistrovaný uživatel správně vyplní všechna požadovaná pole, dojde k zneplatnění pozvánky, vytvoření uživatelského účtu a přihlášení do aplikace. 4.3.2

Proces vyhledávání

Pokud se uživatel přihlásí do aplikace, bude mít dostupnou možnost vyhledávání v aukčních výsledcích. Vyhledávání bude obsahovat dvě pole. První pro vyhledávání v názvu a druhé v období aukčních položek. Tento způsob byl vybrán, protože uživatelům umožňuje jednodušeji tvořit vyhledávací dotazy, které umožní filtrování zobrazených výsledků. Při použití jednoho vyhledávacího pole by muselo být využito nějaké rozlišení mezi hledáním v názvu a v období aukční položky, které by uživatelé museli znát a používat. Z tohoto důvodu je vyhledávání pomocí dvou vyhledávacích polí pro uživatele mnohem intuitivnější.


38

Vyhledávání musí uživateli také nabídnout možnost využití pokročilých funkcí. Základem je filtrování podle jednotlivých aukcí, řazení od nejnižší nebo nejvyšší dosažené konečné ceny, řazení od nejstarších nebo nejnovějších výsledků, volba zobrazování položek bez obrázků a volba zobrazování neprodaných položek. Další možností, jak uživatelské hledání zjednodušit, je využití booleovského modelu hledání [29]. Booleovský model používá pro upřesnění hledávání logické spojky AND, OR a NOT. Logická spojka AND umožňuje tvořit tzv. úzké dotazy. Tyto dotazy umožňují zúžit množinu výsledků vyhledávání. Pro rozšíření množiny výsledků se využívá logické spojky OR. Tato spojka tvoří tzv. široké dotazy. Možností, jak odebrat určitá slova nebo fráze z výsledků vyhledávání, je využití logické spojky operátoru NOT. Tato spojka umožňuje definovat slova, která se nesmí ve výsledcích vyhledávání objevit [29]. Kromě logických spojek booleovského modelu dále vyhledávače využívají vlastní operátory, které umožňují ještě více zpřesnit vyhledávání. Příkladem vlastního operátoru je uzavření fráze do uvozovek, kdy vyhledávací dotaz musí obsahovat přesně zadanou frázi [30]. 4.3.3

Proces přidávání mezi oblíbené položky

Aplikace bude uživatelům umožňovat nalezené výsledky přidat mezi své oblíbené položky. Všechny položky, které si uživatel vložil mezi své oblíbené, bude moci později najít v seznamu oblíbených položek. Tímto způsobem si uživatelé budou moci ukládat položky, které je zajímají, a budou je moci kdykoliv najít na jednom místě bez toho, aniž by je museli stále dokola hledat. Přidávání a odebírání z oblíbených položek bude uživatelům umožněno v jakékoliv části presentující aukční položky uživateli (vyhledávání, prohlížení). Aby proces manipulace s oblíbenými položkami uživatele při práci nerušil, bude použita technologie AJAX [24], která umožňuje přenos mezi částí na klientském počítači a webovým serverem tzv. na pozadí. Tímto termínem je myšleno, že dojde k aktualizaci části stránky bez toho, aby byla celá stránka obnovena. U každé položky na stránce bude umístěna ikonka, která bude uživateli ihned signalizovat, zda je daná položka mezi uživatelovými oblíbenými položkami. Po kliknutí na tuto ikonku dojde k odeslání HTTP požadavku na webový server prostřednictvím JavaScriptu. Na serveru dojde k následnému zpracování požadavku a v závislosti, zda je položka v uživatelových oblíbených položkách nebo ne, dojde k odebrání nebo přidání do databáze. Následně dojde k odeslání výsledku celé operace zpět na počítač klienta. Zde je výsledek zpracován a dojde ke změně HTML kódu stránky tak, aby vzhled stránky odpovídal aktuálnímu stavu. Pro uživatele je proto změna pomocí technologie AJAX přirozenější a aplikace se chová jako by se jednalo o desktopovou aplikaci. 4.3.4


Jelikož je vyhledávač postaven na Nette Frameworku, který využívá MVC architektury, musí diagram tříd toto reflektovat. Z tohoto důvodu je celý diagram na


39

Obr. 11 rozdělen na jednotlivé části. Tyto části jsou Model, Controller (zde Presenter) a Components, které představují znovupoužitelné komponenty aplikace. Část View v diagramu není přítomna, protože je v Nette reprezentovaná pomocí Latte šablon. V podstatě lze říci, že ke každému presenteru je připojena jedna nebo více Latte šablon, které ovlivňují způsob vykreslení výsledné HTML stránky. V diagramu je možné si všimnout osamocené třídy RouterFactory. Tato třída se stará o obousměrné routování mezi URL adresami a akcemi presenterů. Umožňuje tak automaticky nastavit způsob generování URL adres pouze na základě změny v třídě routeru [21]. V diagramu jsou využity dvě barvy pro označení původu tříd. Třídy označené šedou barvou jsou součástí Nette Frameworku. Tyto třídy by v diagramu být nemusely, ale pro pochopení kontextu byly do diagramu přidány. Z těchto tříd jsou dále odvozeny všechny ostatní modré třídy. Modré třídy byly vytvořeny pro účel fungování této aplikace. Struktura tříd Nette obsahuje pár důležitých tříd, které je potřeba pro pochopení funkce diagramu vysvětlit. Předkem všech tříd, od kterých je možné vytvářet instance, je Nette\Object. Dále jsou v diagramu znázorněny třídy předků presenteru (Presenter), komponent (Control) a rozhraní pro autentizaci do aplikace (IAuthenticator) [21]. Část model obsahuje převážně třídy Repository, tyto třídy slouží ke komunikaci s databází. Další třída, která se v modelu nachází, je Authenticator. Ta se stará o přihlašování uživatelů do aplikace. Poslední třídou v této části je SearchSettings. Tato třída slouží jako přepravka pro přenos informací o aktuálním nastavení vyhledávání uživatele. V části presenter jsou pouze třídy, které slouží k prezentování dat z modelu uživatelům aplikace. Všechny třídy jsou potomkem základní třídy BasePresenter a už název každé třídy napovídá o jejím účelu. První stránku aplikace, na kterou se každý uživatel dostane, reprezentuje třída HomepagePresenter. Následně se uživatel může zaregistrovat (RegisterPresenter) a přihlásit pomocí (SignPresenter) a je přesměrován na PremiumPresenter. Zde už má uživatel možnost vyhledávání nebo může kdykoliv přejít na jednu z dalších stránek. Mezi tyto stránky patří nastavení účtu uživatele (SettingPresenter), zobrazení oblíbených položek (FavoritePresenter), nápověda (HelpPresenter) a prohlížení aukčních položek (ListingPresenter). Administrátoři aplikace mají navíc možnost používat administrátorské rozhraní aplikace (AdminPresenter). Aby se při vývoji aplikace zabránilo opakování částí kódu, obsahuje Nette komponenty. Komponenta je logická část kódu s vlastními šablonami, která může být díky tomu různě přizpůsobená. Aplikace obsahuje tři komponenty – SearchForm, SearchResult a VisualPaginator. Komponenty SearchForm a SerchResult reprezentují vyhledávací formulář a výsledný seznam nalezených položek. Obě komponenty jsou přizpůsobitelné, aby je bylo možné použít v různých částech aplikace. Poslední komponentou je VisualPaginator, což je oficiální komponenta z webu Nette. Tato komponenta se stará o stránkování prohlížených aukčních položek [21].


Obr. 11


4.3.5


40

Celé schéma databáze vyhledávače je znázorněno na Obr. 12 a skládá se z celkového počtu jedenácti tabulek. Nejdůležitější jsou tabulky auction, item, picture, picture_url. Všechny tyto tabulky se používají pro ukládání dat z extrahovaných webových stránek. Tabulka auction obsahuje jednotlivé aukce, tabulka item obsahuje extrahované aukční položky a tabulky picture


41

a picture_url slouží k ukládání odkazů na aukční obrázky. Poslední dvě jmenované tabulky mohou působit nezvykle, protože by se problém, který řeší, dal vyřešit jednou tabulkou. To by bylo možné pouze v případě, kdy by nedocházelo k postupnému odstraňování obrázků z webových serverů. V takovém případě by bylo řešení pomocí jedné tabulky dostatečné. Databáze je však připravena na to, že je jeden obrázek uložen na několika různých místech. Pokud dojde k odstranění jednoho obrázku, nastaví se hodnota valid u picture_url na false a aplikace hned může použít obrázek z jiného serveru. Databáze bude také umožňovat ukládání položek do kategorií. K tomuto účelu slouží tabulky category a item_has_category. Druhou částí databáze je práce s uživateli. Zde je nejdůležitější tabulka user, která ukládá informace o jednotlivých uživatelích aplikace. Informace o historii vyhledávání se ukládá do tabulky search_history. Nalezené položky si uživatel může přidat mezi své oblíbené položky, aby je v budoucnu nemusel znovu hledat. K tomuto účelu slouží tabulka favorite. Poslední dvě tabulky v diagramu jsou token a token_type. Tyto tabulky slouží k ukládání bezpečnostních tokenů, které se využívají převážně pro registraci do aplikace nebo jako ověřovací při resetování hesla.


Obr. 12


42

Implementace extrakčního robota

43

5 Implementace extrakčního robota V kapitole implementace bude podrobněji rozebrána implementace obou částí aplikace. Tato část se bude zabývat implementací extrakčního robota.

5.1

Popis tříd

V této části budou detailněji popsány třídy, které se nacházejí v diagramu tříd extrakčního robota. 5.1.1

Třída Robot

Nejdůležitější třída v diagramu tříd je Robot. Při každém spuštění extrakčního robota je potřeba vytvořit instanci této třídy. Konstruktor třídy přebírá objekty Debugger a Extractor, kterým je delegována činnost ukládání logů a extrakce webových stránek. Hlavní funkcí třídy Robot je provádění automatické extrakce dat a webových odkazů z webových stránek. K tomuto účelu je využívána metoda execute. Tato metoda přebírá objekt Action a následně volá jednu z metod executeExtract nebo executeAddLinks v závislosti na tom, zda se mají extrahovat data nebo odkazy z webové stránky.

Obr. 13

Třída Robot

Kromě provádění akcí slouží třída Robot k vytváření a testování nových šablon pro extrakci. K tomuto účelu slouží metody saveTemplate a testTemplate. 5.1.2

Třída Extractor

Jak bylo popsáno dříve, třídu Extractor využívá třída Robot k extrakci dat a odkazů z webových stránek. Třída Extractor umí stahovat webové stránky, manipulovat s jejich obsahem a extrahovat z nich data v různých formátech. Pro stažení webové stránky se využívá metoda loadWeb. Během načítání dochází


44

k automatické detekci a opravě kódování na základě HTTP hlaviček. Pokud se webovou stránku podařilo stáhnout, je načtena do třídy jako objektový model dokumentu (DOM). Nyní je možné se stránkou manipulovat. Extractor umí na stránce přidávat a odebírat skripty nebo opravovat odkazy na obrázky a styly z relativních na absolutní. Toho je využito při interaktivní tvorbě šablony, kdy je stránku potřeba vložit do rámu, aby mohl uživatel provádět označování prvků kurzorem myši.

Obr. 14

Třída Extractor

Nejdůležitější činností, kterou třída Extractor provádí, je extrakce dat z webových stránek. K tomuto účelu je metoda extractItem, která přebírá XPath adresu prvku [11] a typ, který se má extrahovat. Označení typu slouží k výběru typu extrakce určitých dat. Třída umí extrahovat data jako čistý text, případně extrahovat a standardizovat z textu určitý údaj jako cenu (extractPrice), měnu (extractCurrency) nebo datum (extractDate). 5.1.3

Třída Scheduler

Třída Scheduler představuje jednoduchý plánovač, který řídí činnost celého extrakčního robota. Tato třída obsahuje pouze dvě metody. První z nich je getAction a slouží k získání jedné existující akce z databáze. Pokud v databázi žádná taková akce není, Scheduler se postará o vytvoření jedné nebo více akcí na základě aktuálně vytvořených extrakčních šablon.


Obr. 15

45

Třída Scheduler

Druhá metoda třídy Scheduler slouží k označování akcí za úspěšně splněné. U této metody je možné zadat, zda má být akce z databáze smazána nebo jenom označena za splněnou. To je nutné z toho důvodu, že některé akce je nutné provádět pravidelně (extrakce odkazů na nové aukce) a jiné pouze jednou (extrakce webové stránky). První typ akce se musí z databáze mazat, druhý se pouze označí za splněný. 5.1.4

Třída Action

Třída Action je generována pomocí třídy Scheduler. Action tedy slouží pouze jako přepravka pro databázovou reprezentaci akce. Každá akce obsahuje unikátní identifikátor, typ akce (extrakce aukce nebo kontrola nových aukcí) a několik dalších atributů, které označují URL adresu stránky a ID šablony, která se má pro extrakci použít.

Obr. 16

Třída Action

5.1.5

Třída Template

Třída Template slouží jako přepravka pro databázovou reprezentaci šablony. Skládá se z množiny XPath dotazů, které odkazují na jednotlivé části aukce. XPath dotazy uložené v této třídě jsou dvojího typu. Metoda getBasePaths vrací pole absolutních XPath odkazů. Tyto jsou použity pro určení pozic jednotlivých bloků s daty pro extrakci. Na rozdíl od toho metoda getRelativePaths vrací množinu relativních XPath dotazů. Ty identifikují jednotlivé prvky v bloku.


Obr. 17

Třída Template

5.1.6

Třída PageData

46

Pro uchovávání extrahovaných dat z webových stránek se používá třída PageData. Stejně jako předchozí třída slouží pouze jako přepravka. Rozdíl proti předchozím třídám je v možnosti postupného plnění instance třídy. Ta je plněna podle toho, jak extrakční robot postupně prochází jednotlivé stránky. Až jsou data připravena na uložení, je zavolána metoda insert. Tato metoda má velkou výhodu, protože jako parametr se zadává rozhraní IDatabase, kam se mají data uložit. Je tedy možné jednoduše nastavit, zda se data mají ukládat na lokální nebo na vzdálenou databázi. Další výhodou je budoucí rozšiřitelnost vytvořením mnoha různých tříd, které mohou data ukládat mnoha různými způsoby.

Obr. 18

Třída PageData

5.1.7

Třída BayesFilter

Extrakční robot musí být schopen procházet jednotlivé webové stránky aukce bez toho, aby se ztratil. Z tohoto důvodu používá třídu BayesFilter, která umožňuje klasifikovat jakýkoliv webový odkaz do dvou skupin na základě toho, zda se jedná nebo nejedná o odkaz na aukci. Třída BayesFilter v podstatě implementuje dříve popsaný Bayesův klasifikátor [4][8] a kromě učení umožňuje i následnou klasifikaci.


47

Pro učení slouží metoda getTrainedWords, která přebírá jako parametry dvě pole řetězců, která patří a nepatří do klasifikované třídy. Následně je pomocí metody getWords získán seznam všech unikátních slov, která se v řetězcích nalézají. K rozdělení řetězců do slov se používá metoda multiexplode, která využívá seznam oddělovačů. Následně dojde k výpočtu podmíněné pravděpodobnosti pro každé takto získané slovo, které nepatří na seznam výjimek. Na tento seznam byla manuálně vložena slova, na kterých nezáleží výsledná klasifikace. Příkladem je slovo „www“.

Obr. 19

Třída BayesFilter

Po natrénování třídy umožňuje BayesFilter klasifikovat řetězce znaků. Ke klasifikaci se používá metoda getClassScore. Tato metoda nejprve rozdělí klasifikovaný řetězec na základě seznamu oddělovačů. Poté dojde k zjištění pravděpodobnosti pro každé slovo a nakonec je vypočítána podmíněná pravděpodobnost pro celý řetězec. Na základě této pravděpodobnosti se poté může extrakční robot rozhodnout, zda bude odkaz následovat nebo ne. 5.1.8

Třída Link

Pro ukládání extrahovaných odkazů slouží třída Link. Tato třída představuje pouze přepravku pro jeden extrahovaný odkaz.

Obr. 20

Třída Link

5.1.9

Třída Factory

Aby bylo co nejvíce zjednodušeno vytváření složitých objektů, využívá se třída Factory. Výhodou použití této třídy je, že ostatním třídám umožňuje jednoduše


48

získávat složité objekty, které pro vytváření potřebují načítat data z databáze. Třída obsahuje několik metod, které umožňují získávat objekty šablon, získávat objekty akce, získávat data pro učení Bayesova klasifikátoru a získat natrénovaný Bayesův klasifikátor.

Obr. 21

Třída Factory

5.1.10

Třída DB

Třída DB slouží pro komunikaci s databází. Jelikož také implementuje rozhraní IDatabase, není do budoucna problém vytvořit třídu pro jakýkoliv způsob ukládání dat. Výhody třídy DB plynou z využití PDO (PHP Data Objects) [31]. PDO představuje abstraktní vrstvu, která umožňuje pracovat s různými databázemi pomocí jednotného rozhraní. Zároveň přestavuje nový způsob zápisu SQL dotazů, kde jsou data vázána později pomocí metody bind. Tímto je zajištěna obrana před útoky na webové stránky pomocí vkládání nebezpečných znaků (SQL injection).

Obr. 22

Třída DB

Třída DB zároveň podporuje transakce. Ty se mohou hodit v případě, kdy se do databáze má vložit pouze celá aukce. Pokud by se vložení nepodařilo, nedojde k nekonzistentnímu stavu databáze. Stav databáze je pomocí metody rollBackTransaction vrácen do stavu před započetím transakce.


5.1.11

49

Třída HTML

Třída HTML slouží ke zjednodušení generování často používaných bloků HTML kódu. Mezi tyto bloky patří hlavička, obrázky, odkazy, tabulky, tlačítka a stavové zprávy aplikace.

Obr. 23

Třída HTML

5.1.12

Třída User

User představuje jednoduchou třídu pro přihlašování administrátorů ke správě nastavení extrakčního robota. Tato metoda je velmi jednoduchá, proto není třeba další popis.

Obr. 24

Třída User

5.2 Popis funkce extrakčního robota Po přihlášení je administrátor přesměrován na stránku s úvodní obrazovkou. Zde se zobrazují nejdůležitější informace o výsledku provedených akcí, o chybách a o naplánovaných akcích. Pro zjištění výsledku provedených akcí se používá zobrazování obsahu textového souboru logu. Forma textové místo databázové reprezentace pro log soubor byla zvolena záměrně, protože jsou sem zapisovány i informace o chybách, které by při chybě připojení k databázi nešly zapsat. Informace o naplánovaných akcích je načítána z databáze a umožňuje okamžitě zjistit, jakou posloupnost akcí bude extrakční robot vykonávat. Každá akce může být typu extract nebo addLinks. Akce typu extract slouží pro extrakci dat z dané URL adresy. Akce typu addLinks slouží pro získávání odkazů na nové aukce, které jsou pak uloženy do databáze jako akce extract. Úvodní stránka


50

také obsahuje seznam aktivních extrakčních šablon, který je možné rozšířit přidáním nové šablony.

Obr. 25

Extrakční robot – úvodní obrazovka

5.2.1

Tvorba extrakční šablony

Administrátor aplikace se může z úvodní stránky dostat na tvorbu extrakční šablony. K tomu slouží horizontální menu v horní části stránky. Toto menu už kromě jména přihlášeného administrátora a tlačítka pro odhlášení z aplikace nic jiného neobsahuje, protože extrakční robot provádí veškerou další činnost automatizovaně. Po kliknutí na tlačítko pro přidání extrakční šablony je administrátor přesměrován na stránku, kde bude proveden procesem tvorby extrakční šablony pro zvolený web. Cílovou webovou stránku administrátor zvolí pomocí pole s titulkem „Seznam aukcí“. Do tohoto pole administrátor vloží URL adresu stránky se seznamem odkazů na aukční výsledky. Po vložení URL adresy a potvrzení dojde k automatické extrakci všech URL odkazů, které se na dané stránce nachází (viz Obr. 26). Každý odkaz je zobrazen jako řádek tabulky, ve kterém jsou, kromě URL adresy aukčního výsledku, i ovládací prvky se symboly plus a mínus. Ovládací prvky slouží k učení algoritmu Bayesova filtru [4][8]. Kliknutí na tlačítko se symbolem plus znamená přidání celého textu odkazu a URL adresy odkazu mezi pozitivní trénovací příklady. Takové příklady bude extrakční robot považovat za odkazy na aukce a bude se je snažit extrahovat.


51

Administrátor má možnost využít kliknutí na tlačítko se symbolem mínus. Toto tlačítko, jak název napovídá, přidá odkaz mezi negativní příklady. Mezi tlačítky se také nachází číselná hodnota, která určuje vypočítanou podmíněnou pravděpodobnost pro daný odkaz. Na základě této hodnoty je poté každý odkaz označen barvou. Červená barva je použita pro odkazy, které se nebudou extrahovat. Zelená barva je naopak použita pro odkazy, které se extrahovat budou. A nakonec šedé jsou odkazy, u kterých Bayesův filtr nedokáže určit, do jaké skupiny patří.

Obr. 26

Extrakční robot – naučený Bayesův filtr

Po implementační stránce je proces učení Bayesova filtru řešen pomocí technologie AJAX. Je tedy možné komunikovat se serverem a měnit obsah stránky bez nutnosti celkového obnovení stránky. Naučené odkazy jsou poté na serveru ukládány do databáze. Při každé změně samozřejmě dojde k přepočítání podmíněných pravděpodobností pro všechny odkazy a následně dojde k aktualizaci hodnot score. Proces učení Bayesova filtru je díky tomu velmi intuitivní a administrátor může mít pocit, že pracuje s desktopovou aplikací. Když je administrátor spokojen s procesem učení a následnou schopností rozpoznávání odkazů, může přejít k vlastní tvorbě extrakční šablony. K té se dostane po kliknutí na jednu z malých zelených šipek u zeleně podbarvených odkazů. Po kliknutí na jednu z těchto šipek dojde k načtení cílové webové stránky a vložení jejího obsahu do rámu. Proces mezi kliknutím a zobrazením stránky je složitější, protože odkazy běžně nevedou na stránku, kde se extrakce má provést.


52

Většinou se zde nachází i stránka, která slouží pro návštěvníky aukčních výsledků jako rozcestník, který jim umožňuje rychle se přepínat mezi různými částmi výsledků (zlato, středověk, novověk, …). Robot proto musí nejprve nalézt odkaz na první stranu aukce. Algoritmus hledání odkazu první strany aukce funguje následovně. Extrakční robot nejprve extrahuje všechny odkazy, které se na stránce nacházejí. Poté jsou z této množiny vybrány pouze odkazy, které rozpozná naučený Bayesův filtr. Ve výsledné množině odkazů dochází k hledání odkazu, který obsahuje nejmenší číslo. Právě ten většinou odkazuje na první stranu aukce.

Obr. 27

Extrakční robot – tvorba šablony

Po nalezení odkazu dojde k načtení obsahu webové stránky a jeho následnému zpracování pro vložení do rámu stránky (viz Obr. 27). Celý proces od kliknutí na zelenou šipku až po zobrazení stránky je po implementační stránce mnohem složitější. Po kliknutí na tlačítko se zelenou šipkou dojde k odeslání ajaxového požadavku na server. Server vyhledá první stranu aukce a následně stáhne obsah této stránky. Poté musí odstranit všechny skripty, zrušit funkčnost odkazů a tlačítek, opravit odkazy na kaskádové styly a obrázky. Díky tomu je stránka zobrazena ve stejné podobě, ve které se zobrazí administrátorovi po zadání URL adresy do


53

webového prohlížeče. Důležitým krokem je vložení skriptu do těla stránky, který administrátorovi umožňuje vybírat jednotlivé bloky stránky pouze za pomoci kurzoru myši. Proces tvorby extrakční šablony je proto jednoduchý. Nejprve je administrátorovi zobrazena stránka, na které bude vytvářet extrakční šablonu. Administrátor následně může, pomocí kurzoru myši, označovat jednotlivé bloky stránky s tím, že jsou okamžitě generovány XPath dotazy, které blok jednoznačně identifikují. Přepínání mezi výběrem jednotlivých bloků stránky se provádí pomocí tlačítek s popiskem další. V praxi administrátor nejprve označí název aukce a přejde na další krok. Následně vybere text, ve kterém se nachází datum aukce. Poté následuje krok, který významně ulehčuje tvorbu celé šablony. Administrátor vybere jakýkoliv blok, ve kterém se nacházejí data jedné aukční položky. Jakmile vybírá jednotlivé prvky, které se v tomto bloku nacházejí, může si všimnout, že XPath dotazy jsou generovány relativně k absolutní cestě celého bloku. Díky tomuto výběru je možné provést následující akci. Administrátor stiskne tlačítko s popiskem „Vyhledat“ a okamžitě jsou nalezeny absolutní cesty ke všem ostatním blokům. Celý proces využívá algoritmus extrakce datových záznamů [10][12][13]. Ostatní bloky jsou dohledány díky podobnosti jejich vnitřní struktury XPath dotazů s označeným blokem. Nakonec, po kliknutí na tlačítko uložit, dojde k uložení celé šablony do databáze. Poté dojde automaticky k testu extrakční šablony. Extrakční robot se pokusí extrahovat první stránku zvolené aukce a výsledek administrátorovi zobrazí (viz Obr. 28).

Obr. 28

Extrakční robot – testování šablony

Jak je možné vidět na předchozím obrázku, extrakční robot provádí i automatickou extrakci odkazů na obrázky, i když administrátor nemusel při tvorbě extrakční šablony žádný obrázek vybírat. Je to tím, že obrázky jsou ex-


54

trahovány automaticky. Extrakční robot automaticky extrahuje všechny obrázky, které se nacházejí v bloku aukční položky. 5.2.2

Automatická extrakce

Po vytvoření alespoň jediné extrakční šablony už může robot začít sám pracovat. Celý proces automatické extrakce funguje následovně. Činnost robota je spuštěna provedením skriptu cron.php. Tento skript je spouštěn pomocí softwarového démona Crona. Jakmile dojde k aktivaci skriptu, vytvoří se objekt třídy Scheduler, který se stará o plánování práce robota. Pokud bude v databázi nalezena jedna nebo více neprovedených akcí, provede se ta akce, která má nejvyšší prioritu a je nejstarší. Po provedení akce dojde k jejímu označení za provedenou nebo dojde ke smazání. Záleží na tom, zda se stejná akce bude někdy v budoucnu provádět znovu. Po vytvoření extrakční šablony je však tabulka akcí prázdná, proto si musí plánovač nějakou vytvořit. Vytváření nových akcí funguje jednoduše. Pokud není v databázi žádná akce, plánovač vytvoří pro každou extrakční šablonu jednu akci typu AddLinks. Jak už název této akce může napovědět, po jejím provedení dojde k extrakci všech odkazů z webové stránky, které vedou na aukce. Z těchto odkazů jsou vytvořeny akce typu Extract, pouze pro ty odkazy, které se ještě v databázi nenacházejí. Během extrakčního procesu kromě vlastní extrakce dochází i k automatické extrakci a standardizaci cen, měn a data aukce. Jak už bylo zmíněno dříve, extrakční robot nedokáže poznat, kde se tyto údaje na stránce nachází. Určování pozic jednotlivých údajů na webové stránce provádí administrátor při tvorbě extrakční šablony. Pomocí kurzoru myši administrátor označuje jednotlivé bloky stránky a podle typu pole je následně použit správný algoritmus pro extrakci a standardizaci. To znamená, že pro pole datum aukce bude použit algoritmus extrakce a standardizace data. Pro pole s počáteční nebo konečnou cenou budou použity algoritmy dva. První algoritmus se bude z bloku snažit extrahovat a standardizovat cenu a druhý algoritmus měnu. Všechny algoritmy pro standardizace údajů fungují na principu regulárních výrazů. Nejjednodušší je algoritmus pro standardizaci ceny. Algoritmus využívá znalosti o aukčních příhozech, kdy se vždy draží v celých korunách (eurech, dolarech, …). Drobnější částky se zde nepoužívají. Díky tomu nemusí algoritmus umět rozpoznávat desetinná čísla. Algoritmus pak pracuje na následujícím principu. Nejprve jsou z řetězce odstraněny všechny bílé znaky. Poté dojde k odstranění znaku uvozovky, který je typický pro některé zápisy měn. Nakonec se použije regulární výraz pro extrakci první nepřerušené posloupnosti číslic nezačínající nulou. Pokud by takový řetězec nebyl nalezen, vrací funkce nulu. To může být užitečné pro určení položek aukce, které nebyly vydraženy. Složitějším algoritmem je standardizace měn. Tento algoritmus využívá tabulky světových měn podle standardu ISO 4217 [32] a jednopísmenných symbolů pro označení známých měn [33]. Princip fungování je podobný jako u předchozího algoritmu. Rozdíl je pouze v použití regulárního výrazu, který hledá, zda se před nebo za cenou nachází jeden ze symbolů měn. Pokud dojde


55

k nalezení takového symbolu, dojde k přerušení hledání dalších a k vrácení měny na výstup algoritmu. Nejsložitější z algoritmů slouží k extrakci a standardizaci dat z textového řetězce. Ten využívá PHP funkci strtotime, která umožňuje převést datum z textového řetězce ve známém formátu do zvoleného formátu. Nebylo by jednoduché a univerzálně použitelné snažit se zjistit formát data v řetězci. Proto je lepší vytvořit si formát vlastní, který může být převeden do formátu typu MySQL DATE (YYYY-MM-DD) [34]. Jelikož funkce strtotime podporuje pouze anglické názvy měsíců, musí být nejprve převedeny české názvy měsíců na anglické. Poté dochází k hledání jednotlivých elementů data za pomoci regulárních výrazů. Nejjednodušší formát má rok, protože stačí hledat čtyřčíselnou kombinaci začínající číslem dva. Formát dne v měsíci obsahuje čísla 1 až 31. Nejhorší je to s hledáním měsíce, protože může být zapsán jak číselně, tak slovně. Pro číselné hledání se používají čísla 1 až 12 a pro slovní hledání se používá seznam názvů anglických měsíců. Jakmile jsou nalezeny všechny části data, je už jednoduché vytvořit vlastní formát data a ten převést. Během extrakce jsou postupně extrahovány všechny odkazy ze stránky. Z těchto odkazů jsou pomocí Bayesova filtru vybrány pouze ty odkazy, které vedou na aukce. Robot poté postupně prochází všechny takto získané odkazy. Proces končí, když už nezbývá žádný neextrahovaný odkaz. Poté dojde k uložení všech extrahovaných výsledků do databáze pomocí třídy DB případně jiné třídy, která implementuje rozhraní IDatabase.

Implementace vyhledávače

56

6 Implementace vyhledávače Implementace vyhledávacího nástroje byla provedena v Nette Frameworku [21]. Jelikož tento framework používá pro vývoj MVC architekturu, jsou i jednotlivé třídy vyhledávače rozděleny do několika skupin. Jedná se o model, presenter a komponenty. Zjednodušeně lze popsat funkci jednotlivých skupin tříd následujícím způsobem. Třídy modelu představují datový a funkční základ aplikace. Třídy presenteru slouží k zpracování akcí uživatelů a vykreslení šablon. Nakonec třídy komponent slouží k definování logických komponent, které je možné opakovaně používat v celé aplikaci.

6.1 Popis tříd Jelikož byl celkový diagram tříd představen už dříve, budou v této části podrobněji rozebrány nejdůležitější třídy vyhledávače. 6.1.1

Třída Repository

Jednou z nejdůležitějších tříd, která je součástí modelu, je třída Repository. Tato třída představuje základní repositář, který je předkem všech ostatních repositářů v aplikaci. Poskytuje tedy ostatním třídám přístup k objektu Connection, který představuje připojení k databázi. Asi nejdůležitější metoda třídy Repository je getTable. Tato metoda umožní všem potomkům přistupovat k databázové tabulce na základě části názvu před textem Repository. Z toho plyne, že tato metoda ve třídě UserRepository umožní pracovat s tabulkou User nebo ve třídě ItemRepository umožní pracovat s tabulkou Item.

Obr. 29

Třída Repository

6.1.2

Třída UserRepository

Třída UserRepository slouží pro práci s uživatelskými účty vyhledávače. Umožňuje například vyhledávat uživatele, získávat seznamy všech uživatelů, vytvářet nové uživatelské účty prostřednictvím metody createUser, měnit a resetovat hesla nebo měnit a přidávat e-mail k jednotlivým uživatelským účtům. Resetování hesla lze provést pomocí metody resetPassword a slouží pro změnu hesla


57

uživatele na nové, které bylo vygenerováno prostřednictvím metody generatePassword. Toto heslo je následně odesláno prostřednictvím e-mailu uživateli, který si o reset hesla požádal.

Obr. 30

Třída UserRepository

6.1.3


Jednou z tříd, která používá třídu UserRepository, je třída Authenticator. Tato třída slouží k přihlašování uživatelů do aplikace. Pro přihlášení se zde používá metoda authenticate, která jako parametr přebírá přihlašovací údaje uživatele. Pokud uživatel tyto údaje vloží správně, dojde k vrácení naplněného objektu Identity, který obsahuje veškeré informace o uživateli. Třída Authenticator obsahuje další dvě metody. Metoda calculateHashOld slouží pro výpočet hashe hesla. Metoda getIdentity slouží k získání nové identity uživatele na základě jeho identifikátoru. To se může hodit, když uživatel změní některý údaj ve svém profilu a je potřeba získat aktuální verzi objektu Identity.

Obr. 31


6.1.4

Třída TokenRepository

Vyhledávací část aplikace neumožňuje uživatelům volnou registraci a registrace je možná pouze prostřednictvím odkazu s pozvánkou. Pro správu tokenů (klíčů) v pozvánkách slouží třída TokenRepository. Tato třída umožňuje vygenerovat nový token pomocí metody generateToken, zkontrolovat platnost tokenu pomocí metody tokenExists nebo odstranit z databáze token, který byl použit pomocí metody removeToken.


Obr. 32

Třída TokenRepository

6.1.5

Třída SearchSettings

58

Jelikož aplikace umožňuje v aukčních výsledcích vyhledávat, je potřeba použít nějaký elegantní způsob, jakým budou předávána uživatelská nastavení pro vyhledávání. Tímto způsobem je použití třídy SearchSettings, která představuje neměnitelnou přepravku na data. Nastavení hledání uživatele je do této třídy předáno jako klíčové pole v definovaném tvaru. V konstruktoru třídy dojde ke kontrole správnosti tvaru vkládaného pole. Pokud by pole ve správném tvaru nebylo, došlo by k vyhození výjimky. Po naplnění uchovává třída SearchSettings mnoho různých informací o aktuálním hledání uživatele (např. hledaná položka, období, maximální počet výsledků, způsob třídění výsledků a další).


Obr. 33

Třída SearchSettings

6.1.6

Třída ItemRepository

59

Jednou z nejdůležitějších tříd v celém vyhledávači je třída ItemRepository. Tato třída umožňuje jednoduše vyhledávat v extrahovaných aukčních položkách. K tomuto účelu slouží metoda search, která jako parametr přebírá objekt SearchSettings. Tato metoda dále používá další metody, které dohromady sestaví finální SQL dotaz. Jednou ze zajímavých metod je getExclude, která vytvoří část SQL dotazu pro vyloučení hledání určitých slov. Jedná se o ta slova, před kterými se nachází znak minus. Třída ItemRepository dále umožňuje práci s uživatelovými oblíbenými položkami. Jedná se o jejich přidávání a odebírání prostřednictvím metod addToFavorite a removeToFavorite. Takto přidané položky pak může uživatel nalézt na seznamu svých oblíbených položek, který je vytvořen pomocí metody getFavoritedItems.


Obr. 34

Třída ItemRepository

6.1.7

Třída SearchHistoryRepository

60

Třída SearchHistoryRepository slouží k ukládání jednotlivých hledání uživatelů prostřednictvím aplikace. K tomuto účelu slouží metoda save, která přebírá objekt SearchSettings a identifikátor uživatele, který hledání provedl. K takto získaným údajům má přístup pouze administrátor aplikace a může je využít k následným analýzám.

Obr. 35

Třída SearchHistoryRepository

6.1.8

Třída SearchFormControl

První z komponent vyhledávače je třída SearchFormControl. Slouží k vytvoření vyhledávacího formuláře ve verzi pro neregistrované nebo registrované uživatele. Ke zvolení, jaký typ formuláře má třída vytvořit, slouží parametr premium. Pokud je parametr premium roven pravdě, vytvoří se formulář pro registrované uživatele, jinak se vytvoří formulář pro neregistrované uživatele. Výhodou komponent je jejich možná znovu použitelnost v rámci celé aplikace a nastavení vzhledu stránky prostřednictvím vlastní šablony. Třída komponenty SearchFormControl má dvě různé šablony. Každá slouží pro jiný typ formuláře. Důležitá je metoda render, kterou musí mít každá třída komponenty. Tato metoda se stará o připojení a vykreslení šablony komponenty.


Obr. 36

Třída SearchFormControl

6.1.9

Třída SearchResultControl

61

Stejně jako předchozí třída představuje třída SearchResultControl komponentu. Tato komponenta slouží k výpisu všech položek, které jsou vloženy do konstruktoru třídy jako pole items. Komponenta umí na základě parametru premium vykreslit dva typy výpisů. Stejně jako v předchozí třídě slouží pro neregistrované a registrované uživatele. Dále třída obsahuje metody začínající textem handle, které slouží pro zpracování signálů komponenty. V tomto případě se používají pro přidávání a odebírání oblíbených položek uživatele.

Obr. 37

Třída SearchResultControl

6.1.10

Třída VisualPaginatorControl

Aby bylo možné výsledné výstupy jednoduše stránkovat, používá aplikace třídu komponenty VisualPaginatorControl. Autorem této komponenty je David Grudl [35]. Třída slouží k vykreslení číselné navigace u dlouhých seznamů. Uživatelé poté mohou pomocí kliknutí na určité číslo okamžitě přejít na danou stránku. Výhodou této třídy je, že automaticky vygeneruje správný počet odkazů v závislosti na celkovém počtu stránek. Zároveň si poradí i s velkým množstvím stránek, kdy dojde ke skrytí určitých odkazů, v závislosti na aktuální stránce.


Obr. 38

Třída VisualPaginatorControl

6.1.11

Třída HomepagePresenter

62

Pro vykreslování jednotlivých stránek se používají třídy patřící do skupiny presenterů. Tyto třídy používají stejně jako komponenty vlastní šablony, na základě kterých je definováno, jak má vypadat vzhled výsledné stránky. Každá presenter třída prochází mnoha různými fázemi (životními cykly), během kterých dochází k volání korespondujících metod. Příkladem je metoda startup, která se provádí jako první a dochází zde většinou ke kontrole autorizace a k následnému připojení tříd modelu. Dalším důležitým typem metod jsou metody začínající textem render. Tyto metody jsou volány pro vykreslení šablony presenteru. Třída, která obsluhuje úvodní stranu aplikace, je HomepagePresenter. Tato třída využívá komponenty SearchForm a SearchResult pro základní vyhledávání aukční položek. Pro vytvoření těchto komponent se využívají metody začínající textem createComponent. Takto vytvořené komponenty je pak možné ihned používat v šabloně třídy.

Obr. 39

Třída HomepagePresenter

6.1.12

Třída RegisterPresenter

Aby se mohl uživatel dostat k pokročilým funkcím vyhledávače, musí se nejprve zaregistrovat. Registrace do aplikace je však umožněna pouze na základě odkazu s pozvánkou. Proto dochází v metodě startup ke kontrole platnosti vložené pozvánky. Následně se vytvoří komponenta pro registrační formulář, pomocí něhož může uživatel dokončit svou registraci.


Obr. 40

Třída RegisterPresenter

6.1.13


63

Po registraci se uživatel může do aplikace přihlásit pomocí přihlašovacího formuláře. O vytvoření a zpracování tohoto formuláře se stará třída SignPresenter. Zároveň se stará o vykreslení a zpracování formuláře pro resetování hesla uživatele. Uživatel si po vložení svého uživatelského jména a e-mailové adresy může nechat resetovat své zapomenuté heslo, které je následně odesláno na jeho emailovou adresu.

Obr. 41


6.1.14

Třída PremiumPresenter

Po přihlášení se uživatel dostane na úvodní stranu pro přihlášené uživatele. Tato strana je obsluhována pomocí třídy PremiumPresenter a uživateli umožňuje používat pokročilé vyhledávání aukčních položek. Oproti základní verzi zde není omezen maximální počet výsledků na deset. Zároveň se zde vyskytují různá nastavení pro filtrování výsledků. Jedná se o možnost vyhledávání pouze položek s obrázky, vyhledávání bez neprodaných položek nebo vyhledávání pouze na určitých aukcích. Dále zde může uživatel použít různé třídění nalezených výsledků. Zde se jedná o třídění od nejlevnější nebo od nejdráže prodané položky a třídění od nejnovější nebo od nejstarší aukce.


Obr. 42

Třída PremiumPresenter

6.1.15

Třída ListingPresenter

64

Přihlášení uživatelé nemusí využívat pouze hledání, aby našli položky, které hledají. Extrahované aukce mohou procházet jako katalogy. K vygenerování všech katalogů slouží třída ListingPresenter. Tato třída umí zobrazovat dva typy stránek. Prvním typem je seznam všech extrahovaných aukcí, ze kterých si může uživatel vybrat určitou aukci k prohlížení. Po kliknutí na určitý odkaz aukce dojde k zavolání metody renderAuction, která vytvoří druhý typ stránky. Jedná se o tabulkový seznam všech položek dané aukce. Pro rozdělení všech položek na stránky se používá komponenta VisualPaginatorControl.

Obr. 43

Třída ListingPresenter

6.1.16

Třída ItemPresenter

Aplikace pro každou nalezenou položku generuje odkaz, který ji jednoznačně identifikuje. Po kliknutí na tento odkaz je uživatel přesměrován na stránku, kde se zobrazí veškeré informace o dané položce. Pro generování těchto stránek slouží třída ItemPresenter. Odkazy fungují pro registrované i neregistrované uživatele, proto je možné poslat je e-mailem kamarádovi.


Obr. 44

Třída ItemPresenter

6.1.17

Třída FavoritePresenter

65

Každá položka umožňuje přidání na seznam oblíbených položek uživatele. K zobrazení seznamu těchto položek slouží třída FavoritePresenter. Zde jsou všechny oblíbené položky uživatele zobrazeny na jedné stránce. Uživatel tedy nemusí hledat stejné položky stále dokola.

Obr. 45

Třída FavoritePresenter

6.1.18

Třída SettingsPresenter

Důležitou funkcí v aplikaci je nastavení uživatelského účtu. To je umožněno prostřednictvím třídy SettingsPresenter, která umožňuje změnit heslo nebo změnit e-mail uživatele. Třída SettingsPresenter proto umí zobrazovat několik různých typů formulářů, pomocí nichž uživatel změnu provádí. Pro změnu hesla je vygenerován formulář pomocí metody createComponentChangePasswordForm, kde je uživatel požádán o zadání starého a dvakrát nového hesla. Pokud vše proběhne v pořádku, je heslo uživatele změněno. Obdobně slouží metoda pro generování formuláře pro změnu e-mailové adresy. Zde uživatel musí vložit své heslo a dvakrát svůj nový e-mail. Po provedení jakékoliv změny dojde k aktualizaci objektu Identity, aby následně mohly být zobrazeny správné údaje.


Obr. 46

Třída SettingsPresenter

6.1.19

Třída AdminPresenter

66

Pokud se do aplikace vyhledávače přihlásí někdo s administrátorskými právy, bude mít v menu dostupný odkaz pro zobrazení administrátorského rozhraní. O vykreslení a obsluhu tohoto rozhraní se stará třída AdminPresenter. V tomto rozhraní lze nalézt seznam všech zaregistrovaných uživatelů a seznam všech aktivních pozvánek pro registraci do aplikace. Administrátor má možnost vygenerovat novou pozvánku nebo pozvánku smazat.

Obr. 47

Třída AdminPresenter

6.2 Popis funkce vyhledávače Po spuštění aplikace se uživatel dostane na úvodní stranu (viz Obr. 48). Tato strana umožňuje funkci vyhledávání, která je jako jediná dostupná i neregistrovaným uživatelům. Vyhledávání se provádí pomocí dvou vyhledávacích polí, kdy první pole vyhledává v popisu a druhé v období aukční položky. Tento způsob vyhledávání byl použit, protože stejný text v popisu položky a rozdílné období vede k diametrálně rozdílným výsledkům. Například při vy-


67

hledávání jedné koruny může být v závislosti na zvoleném období nalezena mince z běžného kovu, stříbrná mince, zlatá mince nebo papírová bankovka. Vyhledávání bez přihlášení je značně omezené, protože neobsahuje žádné možnosti filtrování výsledků a zároveň je maximální počet výsledků omezen na deset položek. Pro základní hledání to stačí, pokud chce uživatel využít vyššího uživatelského komfortu, musí se do aplikace zaregistrovat.

Obr. 48

Vyhledávač – výřez úvodní obrazovky

Vzhled aplikace má jednotný styl, kde se menu nachází v horní liště aplikace. Nepřihlášený uživatel zde může vidět několik ikonek, které slouží pro zobrazení přihlašovací stránky a pro zobrazení stránky s nápovědou. U každého formulářového pole se nachází ikonka s malým otazníkem. Ta slouží k zobrazení plovoucího pole s kontextovou nápovědou, která se zobrazí, pouze pokud je kurzor myši umístěn nad touto ikonkou. 6.2.1

Registrace a přihlášení do aplikace

Aby mohl uživatel používat pokročilé funkce aplikace, musí se do aplikace zaregistrovat. Registrace však není dostupná pro každého, používá se zde systém registrace pomocí tzv. pozvánek. Pozvánkou se rozumí webový odkaz ve speciálním tvaru, kdy je po jeho navštívení uživateli zobrazena webová stránka umožňující vytvoření nového uživatelského účtu. Před tímto zobrazením musí dojít ke kontrole existence a platnosti pozvánky, aby nemohlo dojít k opakovanému použití jedné pozvánky. Pro registraci stačí uživateli vyplnit do formuláře své uživatelské jméno, heslo a e-mailovou adresu. Pokud uživatel vyplní vše správně, je automaticky přihlášen. Pro opakované přihlášení se používá přihlašovací formulář, který je dostupný pod první ikonkou lišty aplikace (viz Obr. 49). Tento formulář, kromě standardního přihlášení pomocí uživatelského jména a hesla, nabízí i možnost resetování hesla. Možnosti resetovat heslo může využít každý registrovaný uživatel, který svoje heslo zapomněl. Při procesu rese-


68

tu hesla dojde k vygenerování nového hesla, které je odesláno na e-mailovou adresu uživatele.

Obr. 49

Vyhledávač – přihlašovací a resetovací formulář

V aplikaci se proces resetování hesla provádí pomocí kliknutí na odkaz s textem „Zapomněl jsem heslo“. Poté je uživatel přesměrován na formulář, kde je vyzván pro vložení svého uživatelského jména a e-mailu. Pokud je kombinace platná, dojde k vygenerování a odeslání nového hesla na e-mailovou adresu uživatele. 6.2.2

Prémiová část aplikace

Pokud je uživatel v aplikaci registrován a přihlásí se, dostane se do prémiové části aplikace (viz Obr. 50). Úvodní strana prémiové části aplikace nabízí, podobně jako úvodní strana aplikace, vyhledávání v aukčních výsledcích. Rozdíl je pouze v množství doplňkových funkcí, které může uživatel používat. Tyto funkce umožňují lépe filtrovat hledané položky. Konkrétně se jedná o výběr prohledávané aukce, způsob řazení výsledků nebo možnost výběru, zda se mají vyhledávat neprodané položky nebo položky bez obrázků. Prémiová část aplikace také obsahuje možnost zvolit si maximální počet výsledků vyhledávání. Uživatel zde není omezen pouze na limit deseti výsledků, který je na pevno nastaven v neregistrované části aplikace. Menu prémiové části aplikace obsahuje několik ikonek, které je možné vidět na Obr. 50. Zleva doprava je jejich význam následující – nastavení účtu uživatele, odhlášení z prémiové části, vyhledávání, prohlížení aukcí, zobrazení


69

oblíbených položek uživatele, zobrazení nápovědy a přístup do administrátorského rozhraní. Poslední ikonka je dostupná pouze pro administrátory aplikace, ostatním uživatelům se nezobrazuje.

Obr. 50

Vyhledávač – prémiová část (se zobrazenou kontextovou nápovědou)

Jelikož je aplikace velmi obsáhlá, v následující části budou popsány pouze nejdůležitější procesy v aplikaci. Procesy jako zobrazení nápovědy nebo nastavení účtu uživatele nebudou více rozebírány. 6.2.3


Hlavním účelem aplikace je umožnit uživatelům vyhledávat v extrahovaných datech aukčních výsledků. Pokud uživatel vloží název hledané položky do formuláře, jsou uživateli vráceny všechny aukční položky, které obsahují uživatelem zadaný text. Uživatel může následně upravit text dotazu, aby se dostal k relevantnějším výsledkům. Z nalezených výsledků se uživatel může dozvědět mnoho důležitých informací, které se týkají ceny a četnosti výskytu hledané položky. Nalezené výsledky jsou uživateli zobrazeny ve formě tabulky, kde každý řádek obsahuje jednu relevantní aukční položku. Každá položka obsahuje popis, období, vyvolávací a konečnou cenu, datum a jméno aukce, na které byla položka dražena, a někdy i aukční fotografie. Při vyhledávání uživatel není omezen na prostý text. Může využívat několika speciálních znaků, které slouží k zpřesnění výsledků vyhledávání. Jedná se o znak uvozovek a znak minus. Znak uvozovek slouží pro vyhledání přesné fráze uzavřením dané fráze do uvozovek. To se může hodit při hledání všech položek obsahující text 10 korun. Pokud uživatel vloží tento text do vyhledávače bez uvozovek, dojde k nahrazení všech mezer za znak procenta. Bude tedy vyhledán výraz %10%korun%. Tomuto výrazu odpovídají nejenom všechny položky obsahující text 10 korun, ale také 100 korun, 1000 korun nebo třeba 10 medvědů s cibulkou má na hlavě korunu. Při uzavření hledaného výrazu do uvozovek


70

nebudou nahrazeny mezery nacházející se v uvozovkách. Bude tedy hledán výraz %10 korun%, který mnohem pravděpodobněji nalezne to, co uživatel hledá. Znak minus se používá pro definici slov, která se v textu nalezených položek nesmí vyskytnout. Příklad použití ukazuje Obr. 51, kde je hledán výraz „10 koruna“ 1933 -soubor. Při použití tohoto výrazu dojde k vyhledání všech aukčních položek, které odpovídají výrazu %10 koruna%1933% a zároveň neobsahují text soubor. Pro definici více slov, která se ve výsledku vyhledávání nemají objevit, se před každý slovem použije znak minus.

Obr. 51


6.2.4

Prohlížení aukčních výsledků

Kromě vyhledávání aplikace umožňuje i prohlížení extrahovaných aukčních výsledků. K této funkci se uživatelé dostanou po kliknutí na čtvrtou ikonku menu (otevřená kniha). Stránka, která umožňuje prohlížení aukčních výsledků, je celá generována automaticky, a to na základě extrahovaných aukcí. Vše je přehledně rozděleno podle názvu aukce a jednotlivé aukce jsou řazeny podle data konání. Díky tomu může uživatel velmi rychle nalézt aukci, kterou hledá. Reálnou automaticky vygenerovanou stránku je možné vidět na Obr. 52. U každého termínu aukce se nachází ikonka lupy, která slouží pro přesměrování na detail zvolené aukce. Tato stránka obsahuje seznam všech aukčních položek, které byly na zvolené aukci draženy. Výpis položek je stejně jako při vyhledávání tabulkový, kde každý řádek obsahuje jednu aukční položku. Pro všechny tyto výpisy se používá třída komponenty SearchResultControl, která byla popsána dříve. Jelikož aukční výsledky běžně obsahují stovky nebo i tisíce položek, je nutné toto množství nějak stránkovat, aby nedocházelo k pomalému načítání stránky nebo k dlouhému scrolování uživatele. Z tohoto důvodu používá aplikace třídu komponenty VisualPaginatorContol.


Obr. 52

71

Prohlížení aukčních položek – seznam aukcí

Po vložení VisualPaginatorControl do šablony stránky dojde k vykreslení vizuální komponenty, která umožňuje přesun mezi jednotlivými stránkami aukce. Tato komponenta aplikaci předává rozsah položek, které mají být na dané stránce zobrazeny. Programátor se už nemusí starat o přepočítávání jednotlivých rozsahů položek k zobrazení.

Obr. 53

Prohlížení aukčních položek – detail aukce

6.2.5

Oblíbené položky

Aplikace také umožňuje přidávání položek, které uživatele nějak zaujaly, na seznam oblíbených aukčních položek. Všechny oblíbené položky jsou poté dostupné na jednom místě aplikace (ikonka hvězdička). Přidávání na tento seznam


72

může být užitečné pro ukládání položek, které by jinak uživatel musel zdlouhavě znovu hledat. Ikonka pro přidání položky mezi oblíbené se nachází na začátku každého řádku aukční položky. Pouze na základě obrázku ikonky je uživatel schopen okamžitě poznat, zda se položka nachází na jeho seznamu. Pokud je ikonka bílá hvězda, položka se na seznamu oblíbených položek nenachází. Pouze pokud je ikonka žlutá hvězda, uživatel má jistotu, že se položka nachází mezi jeho oblíbenými položkami.

Obr. 54

Přidávání do oblíbených položek

Po implementační stránce funguje celý proces přidávání a odebírání pomocí technologie AJAX. Díky tomu je možné položku přidat nebo odebrat bez toho, aby bylo potřeba znovu načíst webovou stránku. Pokud uživatel klikne na bílou hvězdu, dojde k odeslání ajaxového požadavku na server. Zde dojde k přidání položky do tabulky Favorite. Následně je zpět odeslán výsledek operace a změněn stav ikonky na žlutou hvězdu. Při opětovném kliknutí dojde k podobné akci jako v předchozím případě s tím rozdílem, že je položka z tabulky oblíbených položek odebrána. V aplikaci je vyřešen problém s opakovaným klikáním před dokončením operace, kdy běžně dochází k odeslání více požadavků. Po kliknutí je ikonka hvězdy změněna na běžící tečku, která neumožní další kliknutí a tedy ani odeslání požadavku.

Testování

73

7 Testování Testování aplikace bylo zaměřeno převážně na proces tvorby extrakční šablony a následnou kontrolu správnosti extrahovaných dat. Proces tvorby extrakční šablony byl testován na následujících webových stránkách: • http://aurea.cz/index.php?main=katalog&lang=cz, • http://www.numismatika.cz, • http://www.sixbid.com. Tato množina testovaných webových stránek byla zvolena záměrně, protože reprezentuje nejdůležitější české i zahraniční sběratelské aukce. Zároveň jsou zde zastoupeny stránky s různým rozvržením aukčních položek. S problémem extrakce aukčních položek ze stránek s různým rozvržením se extrakční robot musel být schopen vypořádat už během tvorby extrakční šablony. Proces testování probíhal v několika krocích. Prvním krokem bylo vytvoření extrakční šablony. Nejprve proběhlo učení Bayesova filtru. Tento filtr při dostatečném množství trénovacích příkladů fungoval vždy správně a extrakční robot byl schopen poznat, které odkazy vedou na aukční položky a které ne. Následně probíhala manuální tvorba extrakční šablony. Zde byla věnována pozornost schopnosti automatické detekce aukčních položek při různých rozvrženích stránek. Aplikace si dokázala poradit s jednosloupcovým i dvousloupcovým rozvržením aukčních položek, který se na těchto webových stránkách používá (viz Obr. 55).

Obr. 55

Tvorba šablony pro Sixbid.com – dvousloupcové rozvržení

Extrakční robot neměl potíže ani s následnou extrakcí dat z webů a podařilo se mu správně extrahovat datum aukce, ceny i měny (viz Obr. 56). Během testová-

Testování

74

ní byla zjištěna pouze jediná omezující podmínka. Pokud odkaz na stránku s aukčními výsledky vede na jiný web, robot nemůže výsledky z této stránky extrahovat. To je způsobeno rozdílným objektovým modelem dokumentu oproti naučené šabloně, kterému se šablona extrakce nedokáže přizpůsobit. S tím však bylo počítáno už při tvorbě extrakčního robota a algoritmus Bayesova filtru tyto odkazy efektivně filtruje. Druhou nevýhodou extrakčního robota je, že nedokáže extrahovat aukční výsledky ze stránek, kde jsou data načítána prostřednictvím technologie AJAX. Pro funkční extrakci dat z takovýchto stránek by extrakční robot musel umět provádět skripty, což není triviální problém. S tímto však nebylo při návrhu počítáno, a proto robot všechny skripty ze stránek odstraňuje. Díky tomu dokáže robot vytvořit šablony pro stránky, které mají skriptem zamezeno načtení v rámu.

Obr. 56

Sixbid.com – test správnosti extrakce

Diskuze

75

8 Diskuze Zadání práce se podařilo splnit, což bylo potvrzeno testováním na reálných webových stránkách. Aplikace po vytvoření extrakčních šablon dokázala automaticky extrahovat veškeré dostupné aukční výsledky. Celkově bylo do testovací databáze extrahováno 46 aukcí s 33 921 aukčními položkami. Vynechány byly pouze ty aukce, kde byl obsah generován prostřednictvím JavaScriptu. S extrakcí stránek generovaných pomocí skriptu však nebylo počítáno. Vysoké úspěšnosti při extrakci dat z webových stránek bylo dosaženo pomocí několika technik, které byly využity během procesu extrakce. Konkrétně se jedná o: • automatické rozpoznávání odkazů pomocí Bayesova klasifikátoru, • automatická identifikace a extrakce datových záznamů z webových stránek, • automatická extrakce a standardizace dat, měn a cen, • plánování práce prostřednictvím třídy plánovače. Extrakční robot potřebuje automaticky rozpoznávat odkazy, které vedou na webové stránky obsahující aukční výsledky. K automatickému rozpoznávání odkazů byl použit Bayesův klasifikátor [4][8] umožňující učení pomocí technologie AJAX. Výběr a přeučení Bayesova klasifikátoru díky tomu může probíhat živě a administrátor aplikace může okamžitě vidět, zda už je klasifikátor správně naučen. Filtr odvozený z Bayesova klasifikátoru je nejefektivnějším a nejpoužívanějším nástrojem pro detekci spamu. Přesnost klasifikace tohoto filtru roste se zvyšujícím se množstvím trénovacích příkladů [9]. Z tohoto důvodu byl výběr Bayesova klasifikátoru pro klasifikaci odkazů nejvhodnějším řešením. Pro tvorbu extrakční šablony byl využit algoritmus identifikace a extrakce aukčních položek [10][12][13]. Během tvorby extrakční šablony uživatel používá kurzor myši pro výběr jednotlivých bloků webové stránky. Následně jsou pomocí skriptu generovány XPath dotazy, které jednoznačně identifikují určitý blok na webové stránce [11]. Díky použití techniky automatické identifikace datových záznamů není potřeba vybírat jednotlivé bloky stránky ručně. Stačí označit pouze jeden blok a jeho vnitřní prvky. Aplikace si už všechny ostatní sama dokáže vyhledat na základě shodnosti vnitřních struktur XPath dotazů všech bloků. Tato skutečnost dělá z extrakčního robota velmi efektivní nástroj, který se dokáže přizpůsobit mnoha různým rozvržením aukčních položek na webových stránkách. Zároveň je robot schopen extrahovat data z webových stránek, u kterých došlo k určité změně struktury stránek. Nesmí však dojít ke změně vnitřní struktury aukčních položek. Poté by už extrakční robot nedokázal jednotlivé položky identifikovat. Součástí procesu extrakce je i automatická extrakce a standardizace dat, měn a cen. Na základě uživatelského výběrů bloků extrakční robot pozná, v kterých částech stránky má provést extrakci a standardizaci daného údaje. Pro účel extrakce a standardizace údajů se osvědčily regulární výrazy. Nejsložitější je

Diskuze

76

extrakce a standardizace data aukce, které může být uloženo v mnoha různých formátech. Zde se kromě regulárních výrazů používá i PHP funkce strtotime, která dokáže převést řetězec v zadaném formátu do zvoleného formátu. K úplné automatizaci procesu extrakce bylo nutné použít jednoduchý plánovač, který řídí práci extrakčního robota. Vhodným řešením se ukázalo být použití jednoduché třídy, která generuje a žádá o zpracování akcí. Celkově bylo nutné použít dva typy akcí, kde první slouží k extrakci odkazů a druhá slouží pro extrakci dat ze zvoleného odkazu. Po úspěšném provedení akce dojde k jejímu smazání nebo označení za provedenou v závislosti na tom, zda má být v budoucnu provedena znovu nebo ne. Při návrhu bylo myšleno i na chyby ukládání do databáze. Ta podporuje transakční zpracování. Je tedy možné zaručit konzistenci dat v databázi. Použití transakční databáze sice znemožnilo vložení nekonzistentních dat, ale bohužel způsobilo problémy s nemožností použití fulltextového vyhledávání. Z tohoto důvodu aplikace pro vyhledávání používá pouze operátor LIKE, který má určitá omezení. Nejvýznamnější nevýhodou je nutnost vkládat hledaná slova v pořadí, ve kterém se běžně vyskytují v aukčních textech. Výraz pro hledání „10 korun“ a „korun 10“ tedy nemůže vrátit stejný výsledek. Při tvorbě bylo experimentováno s vyhledáváním, kde dochází k hledání všech možných posloupností zadaných slov. Z důvodu vysoké časové složitosti takto generovaných SQL dotazů při větším množství slov bylo od tohoto upuštěno.

Závěr

77

9 Závěr Cílem práce bylo analyzovat, navrhnout a implementovat aplikaci, která by uživatelům poskytla podporu pro rozhodování o nákupu nebo případném prodeji sběratelských předmětů na sálových aukcích aukčních společností. Podporou pro rozhodování bylo myšleno nabídnutí relevantních aukčních výsledků pro zadaný dotaz uživatele. Zároveň byl kladen důraz na jednoduchost ovládání aplikace a automatizaci procesu extrakce. Všechny tyto požadavky se podařilo úspěšně splnit. Výsledná aplikace uživatelům umožňuje dohledat cenu sběratelského předmětu na základě jeho popisu. Program pro vložený dotaz vrátí všechny relevantní položky, které byly na aukcích draženy. Na základě těchto informací poté uživatel může odhadnout výhodnost budoucích nákupů nebo prodejů sběratelských a investičních předmětů (mincí, medailí, vyznamenání, bankovek a dalších). Aplikace tedy svým uživatelům umožňuje jednodušeji a lépe dosáhnout zisku. Z tohoto důvodu je v praxi velmi dobře použitelná. Celá aplikace se skládá ze dvou částí, a to z extrakčního robota a vyhledávacího nástroje. Extrakční robot se stará o extrakci aukčních výsledků z proběhlých webových aukcí. Vyhledávací nástroj následně umožňuje v těchto extrahovaných datech vyhledávat, prohlížet seznamy aukcí a ukládat oblíbené položky. Činnost extrakčního robota se podařilo z velké části automatizovat. Uživatel musí vytvořit extrakční šablonu, poté už je činnost robota spouštěna pomocí softwarového démona Crona. Proces tvorby extrakční šablony nevyžaduje od uživatele žádné mimořádné znalosti. Uživatel nejprve provede učení Bayesova klasifikátoru výběrem relevantních a irelevantních odkazů. Následně vybere jeden blok s aukční položkou. Ostatní bloky jsou dohledány automaticky pomocí algoritmu extrakce datových záznamů [5][10][12][13]. Extrakční robot může poté automaticky plnit databázi extrahovanými daty. V naplněné databázi následně může vyhledávat vyhledávací část aplikace. Tato část registrovaným uživatelům umožňuje vyhledávat v aukčních výsledcích, prohlížet extrahované aukce a ukládat vybrané položky mezi oblíbené. Pro upřesnění vyhledávání může uživatel použít několik operátorů (hledání přesné fráze a odebrání slova z vyhledávání). Jelikož aplikace obrázky aukčních položek nestahuje a pouze na ně odkazuje, nejsou po odstranění ze zdrojového serveru ve vyhledávači dostupné. To je dáno nutností provozu na hostingu zdarma, kdy je diskový prostor omezený a obrázky by se sem nevešly. Pokud by aplikace běžela na placeném hostingu, nebyl by problém obrázky stahovat. Databáze aplikace nepodporuje fulltextové vyhledávání a musí být využíván operátor LIKE. To vede k nemožnosti nalezení položek, které mají v popisu prohozená hledaná slova. Je to způsobeno využitím tabulek typu InnoDB, které podporují transakční zpracování, ale nepodporují fulltextové vyhledávání. Problém bude možné jednoduše vyřešit v MySQL 5.6, kde tabulky InnoDB začnou podporovat fulltextové vyhledávání [36].

Literatura

78

10 Literatura [1]

HAVEL, J., ODEHNAL, A. Peníze do kapsy. 1. vyd. Praha: Albatros, 2004, 455 s. ISBN 80-000-1408-4.

[2]

YAHOO FINANCE. U.S. Rare Coin Market Roared in 2013, Reports Professional Numismatists Guild. [online]. [cit. 2014-02-02]. Dostupné z: http://finance.yahoo.com/news/u-rare-coin-market-roared130000408.html.

[3]

HERITAGE AUCTIONS. [online]. [cit. 2014-02-02]. Dostupné https://www.ha.com/c/register.zx?ic=join-header-121913-interior.

[4]

LIU, B. Web Data Mining : Exploring Hyperlinks, Contents, and Usage Data. 2nd edition. Heidelberg : Springer, 2011. 622 p. ISBN 978-3642194-597.

[5]

CHAKRABARTI, D. MEHTA, R. The Paths More Taken: Matching DOM Trees to Search Logs for Accurate Webpage Clustering. [online] 2010. Dostupné z: http://www.cs.cmu.edu/afs/cs.cmu.edu/Web/People/deepay/mywww/ papers/www10-wrappers.pdf.

[6]

MCSEARCH. The medieval & modern coin search engine [online]. [cit. 2014-02-03]. Dostupné z: http://www.mcsearch.info.

[7]

AUREA NUMISMATIKA. Mince, medaile, bankovky, vyznamenání [online]. [cit. 2014-02-03]. Dostupné z: http://aurea.cz.

[8]

HOLČÍK, J. Analýza a klasifikace dat. Vyd. 1. Akademické nakladatelství CERM, 2012, 111 s. ISBN 978-807-2047-932.

[9]

GFI WHITEPAPER. Why Bayesian filtering is the most effective anti-spam technology. [online]. 2011 [cit. 2014-05-02]. Dostupné z: http://www.gfi.com/whitepapers/why-bayesian-filtering.pdf.

z:

[10] BLANCO, L., DALVI, N., MACHANAVAJJHALA, A. Highly Efficient Algorithms for Structural Clustering of Large Websites. [online]. 2011 [cit. 2014-02-10]. Dostupné z: http://www.ra.ethz.ch/CDstore/www2011/proceedings/p437.pdf.

Literatura

79

[11] KOSEK, J. PHP a XML. Praha: Grada, 2009. 368 s. ISBN 978-80-2471116-4. [12] CRESCENZI, V., MERIALDO, P., MISSIER, P. Clustering Web pages based on their structure. [online]. 2004 [cit. 2014-02-10]. Dostupné z: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.158.8406&rep =rep1&type=pdf. [13] LIU, B., GROSSMAN, R., ZHAI, Y. Mining data records in web pages. [online]. 2003 [cit. 2014-02-10]. Dostupné z: http://www.cs.uic.edu/~liub/publications/kdd2003-dataRecord.pdf. [14] SCHMULLER, J. Myslíme v jazyku UML: knihovna programátora. Vyd. 1. Praha: Grada, 2001, 360 s. ISBN 80-247-0029-8. [15] BÖHMER, M. Návrhové vzory v PHP. Vyd. 1. Brno: Computer Press, 2012, 320 s. ISBN 978-80-251-3338-5. [16] MICROSOFT OFFICE. Visio Professional 2013. [online]. 2014 [cit. 2014-0224]. Dostupné z: http://office.microsoft.com/en-us/visio/. [17] ULLMAN, L. PHP a MySQL: Názorný průvodce tvorbou dynamických WWW stránek. Vyd. 1. Brno: Computer Press, 2004, 534 s. ISBN 80-2510063-4. [18] HOSTINGER. PHP a MySQL hosting zdarma. [online]. 2014 [cit. 2014-0212]. Dostupné z: http://www.hostinger.cz/. [19] ROOT.CZ. Přehled a vývoj PHP frameworků. [online]. 2008 [cit. 2014-0212]. Dostupné z: http://www.root.cz/clanky/prehled-a-vyvoj-phpframeworku/. [20] ZEND FRAMEWORK 2. The most popular framework for modern, highperforming PHP applications. [online]. 2014 [cit. 2014-02-12]. Dostupné z: http://framework.zend.com/. [21] NETTE. Nette framework. [online]. 2014 [cit. 2014-02-12]. Dostupné z: http://nette.org/cs/. [22] BÖHMER, M. Zend Framework: programujeme webové aplikace v PHP. Vyd. 1. Brno: Computer Press, 2010, 416 s. ISBN 978-80-251-2965-4.

Literatura

80

[23] JQUERY. Write less, do more. [online]. 2014 [cit. 2014-02-13]. Dostupné z: http://jquery.com/. [24] LACKO, Ľ. Ajax: hotová řešení. Vyd. 1. Brno: Computer Press, 2008, 269 s. ISBN 978-80-251-2108-5. [25] SHAH, S., SOYINKA, W. Administrace systému Linux: překlad čtvrtého vydání. Vyd. 1. Praha: Grada, 2007, 426 s. ISBN 978-80-247-1694-7. [26] UNIX MAN PAGEs. Crontab - tables for driving cron. [online]. 2007 [cit. 2014-02-14]. Dostupné z: http://unixhelp.ed.ac.uk/CGI/mancgi?crontab+5. [27] ORACLE. MySQL Workbench 6.0. [online]. 2014 [cit. 2014-03-04]. Dostupné z: http://www.mysql.com/products/workbench/. [28] GOYVAERTS, J., LEVITHAN, S. Regulární výrazy: kuchařka programátora. Vyd. 1. Brno: Computer Press, 2010, 381 s. ISBN 978-80-251-1935-8. [29] BERKA, P. Dobývání znalostí z databází. Vyd. 1. Praha: Academia, 2003, 366 s. ISBN 80-200-1062-9. [30] GOOGLE SUPPORT. Search operators. [online]. 2014 [cit. 2014-02-26]. Dostupné z: https://support.google.com/websearch/answer/136861?p=adv_operators &hl=en. [31] PHP.NET. PHP Data Objects [online]. [cit. 2014-03-26]. Dostupné z: http://www.php.net/manual/en/book.pdo.php. [32] ISO. Currency codes - ISO 4217. [online]. [cit. 2014-04-01]. Dostupné z: http://www.iso.org/iso/home/standards/currency_codes.htm. [33] XE. World Currency Symbols. [online]. [cit. 2014-04-01]. Dostupné z: http://www.xe.com/symbols.php. [34] MYSQL 5.1 REFERENCE MANUAL. The DATE, DATETIME, and TIMESTAMP Types. [online]. [cit. 2014-04-01]. Dostupné z: https://dev.mysql.com/doc/refman/5.1/en/datetime.html.

Literatura

81

[35] DOPLŇKY NETTE. VisualPaginator. [online]. 2011 [cit. 2014-04-03]. Dostupné z: http://addons.nette.org/cs/visualpaginator. [36] MYSQL 5.6. FULLTEXT Indexes [online]. 2014 [cit. 2014-04-17]. Dostupné z: http://dev.mysql.com/doc/refman/5.6/en/innodb-table-andindex.html#innodb-fulltext-index.

Přílohy

82

Přílohy

Přílohy

83

A Praktické použití Praktická ukázka použití programu bude ukazovat hledání orientační ceny zlatého dukátu českého krále Karla IV. Jedná se o velmi vzácnou minci, za kterou by se dal koupit osobní vůz. Pro hledání vydražených položek uživatel do formulářového pole s popiskem hledaná položka vloží text dukát. Pro odstranění nepůvodních a neoriginálních mincí z výsledků hledání je možné tyto výsledky z hledání odebrat přidáním textu -novoražba -replika. Aby aplikace nenašla dukátové mince všech panovníků, je nutné do formulářového pole s popiskem období vložit text karel IV. Nyní už stačí spustit vyhledávání. Výsledek hledávání byl z důvodu lepší čitelnosti rozdělen do následujících pěti obrázků.

Obr. 57

Praktická ukázka – hledání dukátu Karla IV. (první část)

Přílohy

84

Obr. 58

Praktická ukázka – hledání dukátu Karla IV. (druhá část)

Obr. 59

Praktická ukázka – hledání dukátu Karla IV. (třetí část)

Přílohy

85

Obr. 60

Praktická ukázka – hledání dukátu Karla IV. (čtvrtá část)

Obr. 61

Praktická ukázka – hledání dukátu Karla IV. (pátá část)

Na základě takto vrácených výsledků si může sběratel nebo investor udělat představu o ceně této mince. Je zde vidět, že mezi roky 2010 až 2014 bylo draženo na českých aukcích celkem pět dukátů Karla IV. Poslední se neprodal, u ostatních se cena pohybovala od 70 000 Kč za velmi špatně zachovalý kus až

Přílohy

86

k 500 000 Kč za velmi krásně zachovalý kus. Z výsledků lze vyčíst mnoho dalších informací ohledně místa prodeje, data prodeje, čísla dražené položky, popisu položky nebo vyvolávací ceny. U této mince nelze dopředu určit výslednou cenu, protože se naskýtá k prodeji velmi málo. Pro prezentaci funkčnosti aplikace je to však dostačující příklad.

Automatizovaný vyhledávač aukčních položek

Recommend Documents