Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Podnikové informační systémy
Datamining v bázi KKL
Řešitelský tým: Jan Duchaň - vedoucí týmu Jakub Malina - zástupce vedoucího týmu Ondřej Fila Natalya Chernykh Michal Chramosta Karolína Neukirchner
Obsah
Zadání projektu........................................................................................................................................ 5 Vysvětlení použitých zkratek .................................................................................................................... 6 Harmonogram projektu ........................................................................................................................... 9 Inventarizace schopností a znalostí členů týmů ...................................................................................... 10 Technická dokumentace řešení projektu ................................................................................................ 11 Jmenovitý podíl jednotlivých členů týmu na řešení projektu .................................................................. 16 Problémy, s nimiž se tým setkal při řešení projektu ................................................................................ 17 Přínos projektu pro členy týmu .............................................................................................................. 17 Závěr ..................................................................................................................................................... 18
2|P ag e
Zadavatel
Zadavatelem je Národní knihovna České republiky (NK ČR). NK ČR je centrem systému knihoven, vykonává koordinační, odborné, informační, vzdělávací, analytické, výzkumné, standardizační, metodické a poradenské činnosti. Svým rozsahem je NK ČR největší a nejstarší veřejná knihovna v České republice a řadí se mezi nejvýznamnější evropské i světové knihovny. Soubor literatury obsahuje více jak 6 milionů dokumentů. Ročně přibude kolem 70 tisíc nových titulů.
3|P ag e
Zadání projektu
Datamining v bázi KKL Datamining znamená v českém jazyce „dolování“ z dat či „vytěžování dat“. Předně je potřeba si říct, že ze samotného pojmu „data mining“ se stalo populární slovo, které se často nesprávně používá pro jakoukoliv analýzu většího množství dat a jejich dílčí grafickou reprezentaci. Data mining v přesnějším slova smyslu využívá kombinace metod umělé inteligence, strojového učení a statistiky k automatickému nalezení požadovaných vzorů ve velké množině dat a to často podle předem stanoveného datového modelu. Jde skutečně o velmi široký pojem, jehož konkrétnější podoba závisí na dané aplikaci, jako může být například automatické rozpoznávání obličeje, vyhledávání shodných pasáží textu atd.
-
Use Case diagram sběru zpracovávaných informací
-
Data pro analýzu jsou vlastně data – záznamy z vyhledávacích relací uživatelů databáze KKL, díky kterým máme možnost vyvodit zdánlivě skryté informace, které by pak měly přinést těmto uživatelům další užitek anebo alespoň přehled pro správu KLL.
5|P ag e
Národní knihovna České republiky nám poskytla soubory, ve kterých byla zdrojová data, která bylo nutné exportovat. Databáze knihovnické literatury (KKL) aktuálně obsahuje 67 627 záznamů.
Cílem našeho projektu bylo zanalyzovat poskytnutá data a vyvodit závěry, které by mohly být využitelné.
Příklad formátu poskytnutých zdrojových dat:
Vysvětlení použitých zkratek SESSION_ID Označení relace dotazování uživatele vygenerovaným ID systémem databáze
TIME_STAMP „časové razítko“ – označení časovým údajem
IP IP adresa počítače, ze kterého uživatel databáze přistupuju 6|P ag e
HITS Počet výsledků vrácených databází uživateli na jeho zadaný dotaz
TYP – událost; ve sloupci jsou uvedeny kódy událostí: •
10 – hledání – záznamy nalezeny
•
11 – hledání – dosaženo limitu
•
12 – hledání – záznamy nenalezeny
•
20 – vyhledávání z více polí (find-a)
•
21 – základní vyhledávání (find-b)
•
22 – vyhledávání CCL (find-c)
•
23 – pokročilé vyhledávání (find-d)
•
24 – vyhledávání z více bází (find-m)
•
25 – zpřesnit dotaz
•
26 – kombinovat dotaz
•
29 – vyhledávání v rejstřících
•
31 – vyhledávání protokolem Z39.50
•
32 – prohlížení rejstříků protokolem Z39.50
DB – báze, ve které byl proveden dotaz: •
KTD – oficiální báze
•
KTDP – pracovní báze
•
KTDBN – dílčí báze „Termíny bez normativního výkladu“
•
KTDN – dílčí báze „Termíny s normativním výkladem“
SEARCH / SCAN – vyhledávání / prohlížení rejstříků
7|P ag e
Označení rejstříků TDKIV •
TR – termín/ekvivalent
•
TE – anglický ekvivalent
•
TK – věcná skupina
•
AU – autor hesla
•
RE – redaktor hesla
•
KZ – konzultant hesla
•
LK – lektor hesla
•
ZD – zdroj/norma
(kód bez hodnoty např. TR= znamená, že dotaz pouze „odklepnut“ bez zadání)
8|P ag e
Harmonogram projektu Harmonogram navržený vyučujícím: Datum
Činnost
20.3.2012
Formulace zadání, stanovení harmonogramu projektu - předložení vyučujícímu
20.3.2012
Inventarizace schopností a znalostí členů týmů, využitelných v projektu
4.4.2012
1. kontrolní den projektu - prezentace věcných výsledků dosavadního průběhu řešení vyučujícímu a zadavateli
9.5.2012
2. kontrolní den projektu - příprava veřejné prezentace a odevzdání výsledků práce
21.5.2012 23.5.2012
Odevzdání výsledků práce zadavateli, odevzdání tištěné dokumentace projektu vyučujícímu Veřejná prezentace projektu, odevzdání elektronické verze dokumentace projektu vyučujícímu
Skutečný harmonogram a plán týmu: Datum 29.2.2012
Činnost Výběr týmu a zadání projektu
Kde
Kdo
Škola
Tým
7.2.2012
Miniseminář k problematice řešené v projektu
Škola
Jan Duchaň Karolína Neukirchner Michal Chramosta
7.3.2012
Zadána zdrojová data pro datamining KKL
Škola
Tým
19.2.2012
Formulace a zadání projektu
SIC
Tým
SIC
Tým
20.3.2012 21.3.2012 - 28.3.2012 3.4.2012 4.4.2012
Inventarizace schopností členů týmu – předání základní dokumentace Výběr vhodného DM SW, porozumění datům, příprava dat, aplikace DM, vyhodnocení výsledků Schůze členů týmu – shromáždění výsledků, individuální připomínky, příprava výstupu 1. kontrolní den projektu - prezentace věcných výsledků dosavadního průběhu řešení vyučujícímu a zadavateli
Individ. SIC
Tým
Škola
Tým
16.4.2012
Úprava dat, doplnění grafů a doplnění dokumentace
Škola
Tým
9.5.2012
2. kontrolní den projektu - příprava veřejné prezentace a odevzdání výsledků práce
Škola
Tým
20.5.2012 21.5.2012 23.5.2012
Úprava nedostatků v projektu + dokumentace
Individ.
Odevzdání výsledků práce zadavateli, odevzdání tištěné dokumentace projektu vyučujícímu Veřejná prezentace projektu, odevzdání elektronické verze dokumentace projektu vyučujícímu 9|P ag e
Inventarizace schopností a znalostí členů týmů Jan Duchaň – organizace týmu, finální úpravy dokumentace, kontrola výsledků, prezentace týmu Jakub Malina – doplňování a kompletace dokumentace a postupů od ostatních členů, kontrola Ondřej Fila – určení vhodných úprav zdrojových dat, kontrola DM postupů Natalya Chernykh – vyhledávání vhodného SW, kontrola úprav zdrojových dat Michal Chramosta – provádění DM na zdrojových datech Karolína Neukirchner – příprava dokumentace projektu, kontrola výstupu DM
Základním předpokladem pro úspěšné „dolování“ dat a využitelné výsledky je znalost a porozumění vstupních dat každým členem týmu.
10 | P a g e
Technická dokumentace řešení projektu
Podle povahy našich dat jsme se rozhodli, že budeme analyzovat dotazy především co do jejich počtu, což se dá dále využít naším zadavatelem např. pro správné dimenzování obslužného systému. Pokud bychom chtěli analyzovat dotazy z hlediska úspěšnosti je situace mnohem obtížnější. Mohli bychom například zkoumat souvislost mezi délkou textového řetězce a počtem výsledků apod. To ale nemá moc dobrou vypovídající hodnotu. Důležité je, jak nejlépe úspěšnost dotazu definovat. Samotný počet výsledků ještě neříká nic o tom, jestli jsou správné… Pro takovou analýzu by bylo potřeba znát nejen počet výsledků, ale především jejich hodnoty. Potom už se dostáváme k opravdovým data mining technikám a především k poměrně složitým algoritmům pro porovnávání textů atd. Pracovat s těmito algoritmy a hodnotit jejich úspěšnost už je záležitost spíše pro studenty kybernetiky a souvisejících oborů. Proto jsme se rozhodli postupovat první cestou a získat následující vypovídající informace.
11 | P a g e
Statistické výsledky vyhledávání:
Graf 1,2 - Počet hledání/závislost na měsíci v roce
12 | P a g e
Graf 3,4 - Počet hledání/závislost na denní době
13 | P a g e
Graf 5, 6 - Počet hledání/závislost na dni v týdnu
14 | P a g e
Graf 7 – Počet hledání/závislost na typu
TYP – událost; ve sloupci jsou uvedeny kódy událostí: •
20 – vyhledávání z více polí (find-a)
•
21 – základní vyhledávání (find-b)
•
22 – vyhledávání CCL (find-c)
•
23 – pokročilé vyhledávání (find-d)
•
24 – vyhledávání z více bází (find-m)
•
25 – zpřesnit dotaz
•
26 – kombinovat dotaz
•
29 – vyhledávání v rejstřících
•
31 – vyhledávání protokolem Z39.50
U tohoto grafu nám nastává výše uvedený problém a to sice, že nám zobrazuje pouze počet „hitů“ tzn. výsledků, ale neznáme jejich hodnoty, proto nemůžeme zhodnotit jejich relevanci v celkovém kontextu hledání. Avšak dá se použít jako určité vodítko o rozsáhlosti obsahu databáze v závislosti na typu hledání. 15 | P a g e
Jmenovitý podíl jednotlivých členů týmu na řešení projektu
Jan Duchaň – vedoucí týmu -
Vedení a tvorba dokumentace
-
Tvorba statistických grafů
-
Příprava prezentací
-
Prezentace výsledků týmu
Jakub Malina – zástupce vedoucího týmu -
Tvorba dílčích částí dokumentace a její korektura
-
Úprava dat pro statistické zpracování
-
Zkoumání funkcionality a ovládání SW Statistica
Ondřej Fila -
Dílčí statistické zpracování
Natalya Chernykh -
Zkoumání funkcionality a ovládání SW Statistica
Karolína Neukirchner -
Tvorba základní dokumentace
-
Úprava dat pro statistické zpracování
-
Konzultace s externím poradcem
Michal Chramosta -
Příprava dat pro DM – očištění, odstranění duplicit ze SEARCH
16 | P a g e
Problémy, s nimiž se tým setkal při řešení projektu
•
Komunikace v týmu a scházení se k řešení projektu
•
Vhodný klíč pro očištění a přípravu dat.
•
Najít vhodný SW, který by byl funkční pro data mining a byl volně dostupný
Přínos projektu pro členy týmu -
Řešení problémů při týmové spolupráci
-
Řešení zajímavého problému
-
Osvojení přípravných částí pro DM
-
Zjistili jsme, že od tzv. „data-mining“ programů nelze čekat žádné zázraky. Je jenom na uživateli aby si rozmyslel, jakou závislost chce sledovat, co porovnávat atd. Programy jako rapid miner, lisp miner apod. potom podle zadání pouze provedou výpočet a mají sloužit k jednoduchému a rychlému grafickému znázornění výsledků (Což se mimochodem dá zvládnout i přímo v Excelu a v mnoha ohledech i lépe).
-
Tvorba statistických grafů
-
Práce s rozsáhlými daty a metody jak z nich získávat relevantní informace
17 | P a g e
Závěr Z námi získaných informací lze navrhnout relevantní řešení dimenzování obslužného systému databáze s ohledem na její vytíženost. Jednoznačně lze říci, že by bylo velice vhodné celý vyhledávací proces a uživatelské rozhraní udělat více uživatelsky přívětivější. V prvním kroku by rozhodně usnadnila práci tolerance zadaných dotazů podobně, jako ji známe např. z portálu google.com. Pomocí strojového učení a statistických metod by nám nabízel vyhledávací engine nápovědu, omezily by se tak chybná hledání, která vznikají překlepy, které byli hlavním zdrojem neúspěšných hledání. Lze říci, že nejužívanějšími typy hledání jsou typy 21, 24, 31 a z těchto typů byl logicky nejúspěšnější typ 21, jelikož se jedná o základní, nespecifikované vyhledávání.
18 | P a g e
Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Podnikové informační systémy
Datamining v bázi KKL (Dodatek)
Řešitelský tým: Natalya Chernykh Karolína Neukirchner
19 | P a g e
Datamining: Zdrojový soubor ve formátu .xls byl importován do databáze MS Access a následně exportován do databáze SQL (použit program MS SQL Server 2005), kde byly zjištěny pomocí vhodně zvolených dotazů následující výsledky: Tabulka sum.hits/TYP
Tabulka znázorňuje celkový počet úspěšných vrácených výsledků v závislosti na zvoleném typu vyhledávání. Typ vyhledávání 21 (základní vyhledávání (find-b)) vracel v průměru největší počet výsledků vyhledávání, s velkým odstupem následován typy 23, 22 a 31. Naopak nejméně výsledků zaznamenal typ 20. Sloupec “sum hits“ označuje celkový počet úspěšných hledání k danému typu hledání a sloupec “TYP“ typ hledání.
20 | P a g e
Tabulka max.hits/TYP Tabulka znázorňuje maximální počet vrácených výsledků u každého typu vyhledávání. Z tohoto hlediska byl nejúspěšnější typ 22 (vyhledávání CCL (find-c)), těsně následován typy 21, 31 a 23. Sloupec “max hits“ označuje maximální počet výsledků hledání k danému typu hledání a sloupec “TYP“ typ hledání.
Tabulka TYP/count.typ
Tabulka znázorňuje počet použití jednotlivých typů vyhledávání. Z tohoto
hlediska
byl
nejfrekventovanější
typ
31
(vyhledávání
protokolem Z39.50), 24 a 21. Sloupec “count.typ“ označuje počet použití typů hledání a sloupec “TYP“ typ hledání. Tabulka TYP/max(HITS)/SEARCH_TEXT (tabulka exportována do MS Excel)
21 | P a g e
Tato Tabulka je rozšířením tabulky max.hits/TYP, kde je doplněn i v databázi knihovny hledaný výraz, takže vímě, že nejčastěji hledaným výrazem bylo slovo “bu“, které nemá vypovídající hodnotu, ale je spíše pokusem, zda vyhledávání v databázi funguje. Prvním smysluplným nejčastěji hledaným výrazem je výraz “národní knihovna“
Tabulka IP/sum.hits (tabulka exportována do MS Excel)
Tabulka IP/sum.hits znázorňuje prvních dvacet nejčastěji hledajících IP adres v databázi, které měly největší počet úspěšných hledání. Pro lepší orientaci je pridán i třetí sloupec, který doplňuje informaci, kolik pokusů hledání z jednotlivých IP bylo zaznamenáno.
22 | P a g e
Tabulka IP/count.ip (tabulka exportována do MS Excel)
Tato tabulka znázorňuje IP adresy, které nejčastěji v databázi hledaly. Je zřejmé, že nejvíce se v databázi hledalo lokálně (adresa 127.x.x.x). Pro lepší souvislost je doplněna daty z předchozí tabulky, kde je k jednotlivým IP adresám přiřazena úspěšnost hledání. Jen pro úplnost tabulka vpravo ukazuje, že celkový počet jedinečných IP adres hledajících v databázi bylo 784.
23 | P a g e
Top 30 hledaných výrazů, které jsou seřazené podle počtu vyhledávání. Hledaný výraz Slova-Všechna pole= bu* and ( Kód země vydání= xr or Kód země vydání= xo and Druh dokumentu= se ) Slova-Všechna pole= národní knihovna Slova-Všechna pole= knihovna AND národní Slova-Všechna pole= národní AND Slova-Všechna pole= knihovna ISBN,ISSN= ")&$((!%!&X" Slova-Všechna pole= Národní knihovna Klíčová slova= národn? or státn? AND Klíčová slova= knihovn? and Kód jazyka dok.= cze Slova-Názvy= alldocuments and Kód země vydání= xr and Druh dokumentu= BK Slova-Všechna pole= alldocuments and Druh dokumentu= BK and Kód jazyka dok.= cze Slova-Názvy= alldocuments and Druh dokumentu= BK and Kód jazyka dok.= cze Druh dokumentu= alldocuments and Druh dokumentu= BK and Kód jazyka dok.= cze Stavové kódy= "an*" Slova-Všechna pole= knihovni W-All fields= čtenář? AND W-All fields= knihovn? Klíčová slova= knihovny and Druh dokumentu= BK Klíčová slova= knihovní W-All fields= služby Slova-Všechna pole= služby Slova-Všechna pole= služb* Slova-Názvy= Knihovny Kód jazyka dok.= eng and Druh dokumentu= BK Slova-Všechna pole= vzděláv? or škol? Slova-Všechna pole= The Library Slova-Všechna pole= papík or knih Slova-Všechna pole= knih Slova-Všechna pole= knihovnictví W-All fields= knihovnictví Slova-Všechna pole= kultur* Klíčová slova= dokument? W-All fields= organizace OR W-All fields= fondů
Počet hledání 8984 8852 8782 8782 8762 8637 8538 8516 8431 8413 8355 8261 7753 7640 7283 7151 6889 6885 6870 6335 6287 6162 6021 5927 5844 5657 5521 5487 5443 5367 24 | P a g e
Závěr Výsledky projektu by šly shrnout do následujících závěru. Datamining v generálním pojetí je jistě považován za efektivní řešení k optimalizacím, ovšem toto nelze vhodně použít na zdrojový soubor dodaný zadavatelským týmem. I přes veškeré procesy směřující k očištění dat, odstranění redundance a ostatních nežádoucích jevů, výsledný analyzovaný soubor sice poskytne po dataminingu velké množství výstupů, které ovšem nelze úspěšně aplikovat na zlepšení chodu databáze. Prostřednictvím softwaru pro analýzu dat jsme zjistili nejčastější hledané výrazy, nejčastěji hledající IP, IP s největším množstvím “HITů“ a nespočet dalších výstupů, ale po praktické stránce silně pochybujeme, že tento výstup a jeho aplikace v nějakém směru pomůže zadavatelskému týmu k vylepšení služeb uživatelům. K tomu by mohlo spíše dojít vytvořením více “user friendly“ rozhraní (např. automatické doplňování), než analýzou zadávaných dat. Z výsledků lze například zcela jednoznačně určit, že nejužívanějšími typy hledání jsou typy 21, 24, 31 a z těchto typů byl logicky nejúspěšnější typ 21, jelikož se jedná o základní vyhledávání. Dále lze určit pomocí text-miningu nejhledanější slovní spojení a slova, například slova knihovna, služby, dokument, ale stále zůstává otázkou celý smysl analýzy dat. Pro sestavení žebříčku a jakousi analýzu zájmu uživatelů by výsledky hledání šly použít spíše pro komerční účely (zadavatelský tým je ovšem nekomerční organizace), technický přínos je ale nulový. Výsledek, ať už je jakýkoli nijak neovlivní chod databáze, ani žádným způsobem nepřispěje k jejímu zlepšení. Snad jen časová analýza využití analýza pokusů hledání, případně analýza užití jednotlivých adres by mohla přispět k posílení připojení vyhledávacího serveru k síti ve špičkách, i když je zde i patrné časté využití lokální IP 127.x.x.x. ukazuje, že zátěž serveru je tak malá, že tyto úkony by zvládl i standardní server nejnižší cenové hladiny a není třeba dodatečných investic. Pro ilustraci v době nejvyššího zatížení serveru vyhledáváním (úterý a čtvrtek kolem 10:00 hodin) byly na server průměrně ne více než deset přístupů za hodinu (pokud budeme hodně optimističtí). Tento (ne)zájem o vyhledávání na serveru zadavatelského týmu tak snad ani není třeba analyzovat za účelem technické způsobilosti databáze. 25 | P a g e
