diff --git a/Latex/BP_Radek_Pus_2019.pdf b/Latex/BP_Radek_Pus_2019.pdf
index 7cd85c5220e6074daa70ae5c7fb6884b49e3bf67..bc3c9e252c1e5651f07c391e5ebde5d177d4b0cf 100644
Binary files a/Latex/BP_Radek_Pus_2019.pdf and b/Latex/BP_Radek_Pus_2019.pdf differ
diff --git a/Latex/BP_Radek_Pus_2019.tex b/Latex/BP_Radek_Pus_2019.tex
index ef048645ad94ad3874ee816669d6e7a23c93cc3c..4e52bd1607f105267e280f7aee9754fdaabe9ab3 100644
--- a/Latex/BP_Radek_Pus_2019.tex
+++ b/Latex/BP_Radek_Pus_2019.tex
@@ -43,8 +43,8 @@
 {V Bakalářské práci byl řešen problém předpovídání budoucích transakcí klientovi, na základě jeho uplynulé finanční historie. Cílem práce je pokusit se implementovat toto předvídání pomocí umělé inteligence spolu s vytvořením webového rozhraní. Toho bylo dosaženo pomocí  Angularu JS, tvořící klienskou aplikaci, frameworkem .NET Core, který tuto aplikaci obsluhuje ve spojení s databází Microsoft SQL. Zabezpečení využívá JWT tokenu a o šifrování uživatelských hesel se stará RFC~2898/SHA512. Umělá inteligence byla řešena jako lineární regrese.
 %=============
 % <= mělo by obsahovat mojí vlastní implementaci problému
-\newline  Umělou inteligenci jsem implementoval jako několik po sobě jdoucích vrstev, jejichž počet neuronu se postupně snižuje na jeden jediný, který mi dává informaci, zdali se bude transakce opakovat, či nikoli. Abych posléze mohl vyhodnotit, zda se transakce opravdu opakovala, porovnával jsem velikosti transakcí po jednotlivých týdnech a ty částkou si nejvíce podobné jsem označil za opakující se.
-\newline Tento způsob předvídání jsem dále doplnil o odfiltrování trvalých transakcí, jež se už ze své podstaty vždy opakují.
+\newline  Umělá inteligence je implementována jako několik po sobě jdoucích vrstev, jejichž počet neuronů se postupně snižuje na jeden jediný, který dává informaci, zdali se bude transakce opakovat, či nikoli. Aby se posléze mohlo vyhodnotit, zda se transakce opravdu opakovala, porovnávala se velikosti transakcí po jednotlivých týdnech a ty částkou si nejvíce podobné byly označeny za opakující se.
+\newline Tento způsob předvídání je dále doplněn o odfiltrování trvalých transakcí, jež se už ze své podstaty vždy opakují.
 }
 %=============
 \abstractEN{
@@ -92,12 +92,14 @@ Jak už název napovídá, je to web, skládající se z jediné stránky. Strá
 \subsection{Multiple Page website}
 Tyto weby, vývojově starší, obsahují zpravidla hodně informací. Obsahují nějakou formu routování - ať už složitější, dynamickou, či jednodušší, statickou. Uživateli podávají poměrně velké množství informací. Jsou to zpravidla nejrůznější blogy, e-shopy, fóra. Jejich implementace je často snazší (zejména u statických webů), jsou schopny, často přehledněji, zprostředkovat uživateli více informací a jsou (i z historických důvodů) běžnější.
 
+\newpage
 \section{ZabezpeÄŤenĂ­}
-\subsection{Session}
-\subsection{JWT}
+V aplikaci bude nutné zabezpečit REST API. To je možné pomocí Session anebo pomocí, novějšího, JWT tokenu. Tyto dva přístupy se v zásadě liší způsobem ukládání informace o autentifikaci uživatele. Session tuto informaci ukládá do databáze, kdežto JWT tokeny jsou uloženy u uživatele. 
+Ukládání u uživatele má tu výhodu, že se nemusí ukládat na serveru tolik dat do mezipaměti. Ukládání na straně serveru, v případě několika uživatelů, není nijak zásadní, avšak u většího množství to přináší podstatně vyšší nároky na server.\cite{JWTvsSessionPerformance} Navíc JWT tokeny jsou imunní vůči CSRF útoku\cite{JWTvsSessionCSRF}.
+Výhodou ukládání na server je zase fakt, že je mnohem snazší znevalidnit uživatelské přihlášení - stačí odebrat záznam z databáze. U JWT je nutné vyčkat na vypršení tokenu anebo vytvořit nějakou formu blacklistu (seznam neplatných tokenů).
 
-\section{Databáze}
-Při výběru druhu databáze jsem se musel rozhodnout mezi strukturovaným a nestrukturovaným přístupem k datům. První ze zmíněných je reprezentován SQL, druhý pomocí NoSQL
+\section{Ukládání data}
+%TODO přepracovat v závislosti na konečném výsledku
 \subsection{NoSQL}
 % TODO screen z excelu
 Tento přístup je vhodný pro nestrukturované informace a zvažoval jsem ho jako první. Veškeré záznamy, ve výpisu z účtu, jsou tedy vlastně jen jedna \mbox{"velká tabulka"/super-entita.} Záznamy mohou být nevyplněné (př. jednotlivé symboly) a na první pohled nijak nesouvislé. Pokud se ale na data zaměřím více, mohu si všimnout, že transakce lze rozdělit například na Trvalé a jednorázové příkazy, poplatky~atp. Použití NoSQL databáze pro transakční historii i tak ale nic nebrání. Nakonec zmíněná data dokonce vždy dostanu jako jednu jednu jedinou, nic neříkající, tabulku.
@@ -108,12 +110,34 @@ Druhým přístupem, který jsem nakonec zvolil, jsou standardní  SQL databáze
 Na českém trhu je, co se týče předpovídání transakcí, velmi pravděpodobně zatím jediné finanční bankovnictví České Spořitelny, zvané "\textit{George}." a její doplněk "\textit{Moje zdravé finance}."\cite{George} Aplikace je přístupná pouze klientům České spořitelny a zobrazuje pouze příjmy a výdaje. V části "Moje zdravé finance" lze pak vidět, jak dlouho mi vystačí současné úspory nebo například odhadnout výši mého budoucího důchodu. Je ale schopna předpovědět některé mé budoucí transakce, tedy funkci, kterou mám za úkol implementovat. Aplikace byla spuštěna v průběhu května 2018\cite{vznikGeorge_Investujeme},\cite{vznikGeorge_Mesec} (ačkoli přesné datum jsem nebyl schopen dohledat), tedy chvíli po schválení zadání mé Bakalářské práce. To tedy dokazuje, že o témá je v praxi zájem, ale bohužel také to, že v mezičase mého vypracovávání, byl problém zpracován jinde.
 \newline Na zahraničním trhu pak existují aplikace, které umožňují klientům sledovat např. jejich měsíční útratu a na základě výpočtu jim poskytnout informaci, jestli a jak moc, překročili průměrné výdaje v tom kterém měsíci.\cite{zahranicni_aplikace}. Ve využití umělé inteligence je tedy asi Česká spořitelna, resp. Erste Group.
 
-\section{ObohacenĂ­}
+\begin{figure}\centering
+ 	\includegraphics[width=0.75\textwidth]{img/Moje_zdrave_finance_anonymized.png}
+ 	\caption[Moje zdravé finance]{Moje zdravé finance - předpovídání transakcí České spořitelny}\label{fig:float}
+ \end{figure}
+
+\section{ObohacenĂ­ dat}
+Pro obohacení dat by bylo možné využít teoreticky využít veřejně dostupnou databázi MFČR - ARES (Adminstrativní registr ekonomických subjektů)\cite{ARES_zip}. Bohužel data v ní nejsou ukládána jednotným způsobem. Je sice zadefinována základní struktura dokumentu\cite{ARES_struktura}, avšak data v ní nejsou nijak strukturována. Živnosti jsou zadaný naprosto nahodile a není využito žádného oficiálního klíče. Nedefinované hodnoty obsahují výrázay jako: "0", "null", "NULL", "prázdné", "nic", "není", "nedefinováno",... Jako nejlepší příklad záznamu v databázi by pak mohla dobře posloužit Komerční banka. Ta nemá dokonce definováno vůbec nic, až na popis, který obsahuje přibližně 1500 znaků. Lze tedy usoudit, že využití tohoto zdroje je téměř nemožné a pro obohacení se nehodí.
+Další možnost, která by se nabízela je využití bankovních symbolů. Variabilní a specifické symboly opět neobsahují žádné informace. Někdy do nich bývá zadáváno IČO, které by se dalo napojit na ARES, ale jak už je zmíněno výše, toto napojení nepřipadá v úvahu.
+Zbývají tedy už jen Konstantní symboly. Ty se bohužel využívají pouze v rámci České Republiky, ale mají alespoň částečně definovanou strukturu. A ačkoli její použití již není povinné, ve výpisech z účtů, které byly pro tuto práci získány, se vyskytují hojně a mohou o transakcích něco říci.
 
 \chapter{Realizace}
 \section{Webové rozhraní}
-Pro webové rozhraní jsem zvolil, s vyjímkou stránek pro registraci a přihlášení, One Page website. Nepotřebuji uživateli předávat velké množství informací. V zásadě jen zobrazuji grafy a své předpoklady. Nemusím tedy vytvářet rozsáhlý web a jen jednoduché routování. V případě jedné stránky se navíc snadněji pracuje s responzivitou, protože ji stačí vyladit na jednu, resp. dvě stránky webu. U Multiple Page webu by mohl tuto responzivitu rozbít přechod na jinou stránku. To zde nemůže nastat.
+Pro webové rozhraní byla zvolena, One Page website, doplněná o stránky s registrací a přihlášením. Není potřeba uživateli předávat velké množství informací. V zásadě jen zobrazovat grafy a předpoklady. Nemusí se tedy vytvářet rozsáhlý web a jen jednoduché routování. V případě malého množství stránek se navíc snadněji pracuje s responzivitou, protože ji stačí vyladit na jednu, resp. tři stránky webu. Jakákoli práce s responzivitou pro každou další stránku pak zvětšuje prostor na chybu. 
 
+\section{ZabezpeÄŤenĂ­}
+V případě zabezpečení komunikace mezi backendem a frotendem (API) bylo využito JWT tokenu. Kromě výhod, uvedených v analýze, je tento přístup k zabezpečení i novější (dle Wikipedie poprvé vydán 28.12.2010\cite{JWT_published} - v průběhu psaní práce starý necelých osm let) a umožní vyzkoušet si novou technologii.
+Pro zabezpečení routování na straně Klienta bylo využito tzv. Guardů - součást zabezpečení přímo v Angular frameworku. A konečně k zabezpečení uživatelských hesel se využilo hashovacího algoritmu RFC~2898/SHA512. Zároveň se pro každé heslo generuje jiná sůl a proto by nemělo být možné v databázi najít dvě stejná hesla se stejným hashem.
+
+\section {Umělá inteligence}
+%FFFFFFFFFFFUUUUUUUUUUUUCCCCCCCCCCCCCCCCCKKKKKKKKKKKKKKK
+
+\section{Databáze}
+Při výběru druhu databáze jsem se musel rozhodnout mezi strukturovaným a nestrukturovaným přístupem k datům. První ze zmíněných je reprezentován SQL, druhý pomocí NoSQL
+\subsection{NoSQL}
+% TODO screen z excelu
+Tento přístup je vhodný pro nestrukturované informace a zvažoval jsem ho jako první. Veškeré záznamy, ve výpisu z účtu, jsou tedy vlastně jen jedna \mbox{"velká tabulka"/super-entita.} Záznamy mohou být nevyplněné (př. jednotlivé symboly) a na první pohled nijak nesouvislé. Pokud se ale na data zaměřím více, mohu si všimnout, že transakce lze rozdělit například na Trvalé a jednorázové příkazy, poplatky~atp. Použití NoSQL databáze pro transakční historii i tak ale nic nebrání. Nakonec zmíněná data dokonce vždy dostanu jako jednu jednu jedinou, nic neříkající, tabulku.
+\subsection{SQL}
+Druhým přístupem, který jsem nakonec zvolil, jsou standardní  SQL databáze. Tento přístup vyžaduje strukturování dat a to, jak jsem již zmínil výše, je splněno. Lze zde nalézt různé závislosti. Pro vstupy pro mnou implementovanou umělou inteligenci je navíc mnohem lepší jasně definované vstupy, což SQL přístup nabízí. Navíc veškerou historii transakcí všech uživatelů nechci ukládat do databáze, ale raději v *.csv souborech na disk a zaregistrovat jen některé transakce. V opačném případě by se celá databáze stala zbytečně velkou a pomalou.
 
 \section{Backend}
 Při výběru formy zpracování umělé inteligence jsem se rozhodl pro využití neuronových sítí. Tato forma zpracování je novější, ale jinak nemá žádné výrazné výhody.\cite{DynamicCF}. Vybral jsem si ji tedy hlavně proto, že se mi zdá zajímavější. Pro zjištění, který model je přesnější, bych ale musel implementovat obě varianty, což je výrazně časově náročný problém a rozdíl by patrně nebyl markantní. Navíc lze jen těžko odhadnout, jak přesně by se jednotlivé modely chovaly v horizontu let.
@@ -139,12 +163,16 @@ Pro svou práci jsem si nastudoval syntaxi a použití jazyků, jmenovitě Types
 \appendix
 
 %============= seznam zkratek disabled ===================
-%\chapter{Seznam použitých zkratek}
-%% \printglossaries
-%\begin{description}
-%	\item[GUI] Graphical user interface
-%	\item[XML] Extensible markup language
-%\end{description}
+\chapter{Seznam použitých zkratek}
+%\printglossaries
+\begin{description}
+	\item [JSON] JavaScript Object Notation
+	\item [JWT] JSON Web Token
+	\item [SQL] Structured Query Language
+	\item [NoSQL] non SQL
+	\item [CSRF] Cross-site request forgery
+	\item [ARES] Administrativní registr ekonomických subjektů
+\end{description}
 
 
 % % % % % % % % % % % % % % % % % % % % % % % % % % % % 
diff --git a/Latex/mybibliographyfile.bib b/Latex/mybibliographyfile.bib
index 16948ec2ebead6a13a352315d16f7c285094b7f4..fd8eb0841574fd6cd1d731099b0cd73273e6acf3 100644
--- a/Latex/mybibliographyfile.bib
+++ b/Latex/mybibliographyfile.bib
@@ -26,6 +26,35 @@
     note = "[cit. 2019-11-10]"
 }
 
+@MANUAL{ARES_zip,
+    title = "Seznam všech IČO - ARES  (531MB) {[online]}",
+    organization = "Ministerstvo financí České republiky",
+    url = "https://wwwinfo.mfcr.cz/ares/ares_vreo_all.tar.gz",
+    note = "[cit. 2019-13-11]"
+}
+
+@ARTICLE {JWTvsSessionCSRF,
+    title  = "Auth Headers vs JWT vs Sessions: Choosing Right Auth Technique for APIs",
+	author = "Sripathi Krishnan",
+    journal = "HashedIn Technologies Pvt. Ltd. {[online]}",
+    howpublished = "[online]",
+    month  = "18" # "leden",
+    year   = "2018",
+    note = "[cit. 2019-13-11]",
+    url    = "https://hashedin.com/blog/auth-headers-vs-jwt-vs-sessions-choosing-right-auth-technique-for-apis/"
+}
+
+@ARTICLE {JWTvsSessionPerformance,
+    title  = "JSON Web Tokens vs. Session Cookies: What’s the Difference?",
+	author = "Jenni McKinnon",
+    journal = "WP Rocket {[online]}",
+    howpublished = "[online]",
+    month  = "21" # "květen",
+    year   = "2019",
+    note = "[cit. 2019-13-11]",
+    url    = "https://wp-rocket.me/blog/difference-json-web-tokens-vs-session-cookies/"
+}
+
 
 @ARTICLE {YoutubeTechnet,
     title  = "Jak vám Google vnucuje videa? Nahlédněte pod pokličku YouTube",