Kolikrát jste již slyšeli: „Pošli mi data v Excelu!“ Anebo jste možná sami říkali: „Spočítám si to v Google Sheets.“ Všichni známe tabulkové editory jako užitečné nástroje, v nichž lze shromažďovat data, analyzovat je, řešit jednorázové výpočty i pravidelné analýzy. Všestranné využití je umožněno velkou flexibilitou, kterou tabulky přináší. Tato vlastnost je nesporně kladná při jednoduchých a jednorázových analýzách, které neopustí náš hard-disk.

Chceme-li však data a z nich spočítané výsledky sdílet s někým jiným, natož vytvořit snadno replikovatelný report, který pošleme kolegům, může se tabulkový editor ukázat jako špatná volba: množství dat je omezené stejně jako výkon programu, hledání chyb není triviální, porovnávání verzí se může stát noční můrou a aktualizace reportů je do značné míry manuální prací. V následujícím textu si přečtete, jak tyto potíže vyřešit přechodem do databázového prostředí, kde se data zobrazují a analyzují pomocí jazyka SQL (Structured Query Language). Doufám, že po přečtení už nebudete váhat, jak firemní reporting modernizovat, avšak věřím, že uvedené body budou užitečné pro všechny, kdo o možnostech tabulkových editorů přemýšlí.

Co práce v databázi vlastně obnáší? V čem se liší od práce v tabulkovém editoru? Pojďme začít dvěma fakty, která nám pomohou si práci v databázi představit. První zprávou je to, že koncepty pro práci s daty, které umíte z tabulkových editorů, fungují v SQL téměř identicky: Data se uchovávají v tabulkách, které sestávají z řádků a sloupců. Řádky představují záznamy a sloupce vlastnosti záznamů. Sloupce mají jména. Řádky v tabulkách lze filtrovat a řadit. Také je lze seskupit a pro každou skupinu spočítat sumární statistiky. Různé tabulky lze propojovat přes shodnou hodnotu sloupců. Co to znamená? Způsob uvažování nad daty se nemění! Vaše zkušenosti s VYHLEDAT a kontingenčními tabulkami stačí „přeložit“ do jazyka SQL. Pro naprostou většinu uživatelů je proto přechod od tabulkových editorů k SQL snadný.

Druhou zprávou je, že zpracování dat v jazyku SQL je založeno na psaní skriptů, tj. textů, které popisují, jaké operace s daty chcete vykonat. Patříte k lidem, o které se při pomyšlení na programování v jakékoliv podobě pokoušejí mdloby? Zhluboka se nadechněte, protože v případě databázového jazyka SQL se nejedná o nic složitého: představte si, že v databázi vidíte (stejně jako v tabulkovém editoru) tabulku „zaměstnanci“ a chcete z ní vypsat sloupce „jméno“ a „kancelář“ pro řádky, na nichž jsou kolegové z oddělení „HR“. V tabulkovém editoru byste nyní zobrazovali a skrývali sloupce, filtrovali v záhlaví a řadili. V databázi získáte týž výsledek kódem „select jmeno, kancelar from zamestnanci where department='HR'“. Takový skript můžete jednoduše uložit v textovém souboru a sdílet jej s kolegy; databázový přístup k analýze totiž odděluje zpracování dat (to kompletně popisuje váš skript) od uložení dat (zdrojová data zůstávají na databázovém serveru). Právě oddělení těchto dvou aspektů je lékem na mnohé z bolestí tabulkových editorů.

• Rychlost

Tuto situaci jistě všichni známe: otevíráme v tabulkovém editoru velký soubor nebo aktualizujeme kontingenční tabulku a náš editor na nějakou dobu přestane odpovídat; nejprve trpělivě čekáme, potom přichází známky netrpělivosti a nakonec jen doufáme, že to skončí jinak než pádem programu. Náš lokální počítač totiž v tu chvíli musí načíst zdrojová data nebo přepočítat operace v kontingenční tabulce, což trvá. Při přechodu do databáze naopak náš lokální počítač pouze posílá na databázový server SQL kód a po chvíli přijímá spočítané hodnoty. Počítání samotné však probíhá na serveru v prostředí, které je optimalizováno pro ukládání a zpracování velkého množství záznamů. Časově a objemově náročné operace tedy probíhají mimo náš počítač, což dle složitosti analýzy může přinést klidně i stonásobné zrychlení výpočtu. Na svém počítači si pouze uložíme text skriptu a získané výsledky.

• Objemy dat

Dne 6. října 2020 oznámila britská státní organizace Public Health England, že po neuvedenou dobu postrádala výsledky 16 000 testů na covid, neboť nevěnovala pozornost omezení na počet řádků v MS Excel. (Toto téma můžete v britském tisku snadno dohledat; v datově-analytické komunitě se událost stala terčem vtipů.) Moderní verze tabulkových editorů mohou sice teoreticky obsahovat libovolné množství dat, ovšem práce s velkými objemy je v nich velmi nepohodlná. Zpomalení běžných operací jsme popisovali výše, nyní se však zaměřme na možnost sdílení: objem souboru nabobtná často natolik, že je prakticky nemožné jej předat kolegům. Tento problém v databázi zcela odpadá, neboť data jsou uložena na jednom centrálním místě, které je optimalizováno pro uchovávání a zpracování velkého množství dat. Uživatelé mezi sebou sdílejí pouze skripty, anebo výstupy. Rozdíl ve velikosti sdílených souborů je obrovský: výše uvedený miniskript pro zobrazení záznamů zaměstnanců z HR má 70 bajtů. Skript o desítkách tisíc řádků může mít 300 kB. Přechod k SQL tedy zásadně navyšuje množství dat, která můžeme analyzovat, aniž bychom narazili na problém se sdílením.

• Transparentnost postupu a hledání chyb

Dostali jste někdy report v Excelu s mnoha záložkami a zkoušeli jste pochopit, z čeho a jak se jednotlivé hodnoty počítají? Toto je úmorná práce, neboť není zřejmé, co přesně se děje a v jakém pořadí. Dohledávat v moři dat detaily obnáší procházet vzorce a zdrojové řádky a sloupce. Obtížnost při replikaci výsledků je často kritizovanou vlastností tabulkových editorů. Je velmi složité odhalit postup, který pro vás připravil někdo jiný, ale také najít po sobě chybu. Výzkumník Raymond R. Panko z University of Hawai auditem velkých tabulkových souborů zjistil, že v každých 100 buňkách se vzorci se průměrně vyskytují dvě buňky s chybou. Vzpomeňte si na své obsáhlé tabulkové soubory, představte si, jak byste v nich hledali chyby a porovnejte to se situací, kdy je analýza popsána kódem: snadno si můžete přečíst, co se v jednotlivých krocích děje, která data jsou zdrojová a která se z nich dopočítávají. V textovém dokumentu také snáze označíte, kterou část jste od minulého běhu upravili nebo smazali. Pro účely verzování také můžete zvolit některý z dostupných verzovacích systémů (SubVersion, GitHub, GitLab a jiné).

• Automatizace

I když postup výpočtu znáte, může aktualizace reportu vytvářeného v tabulkovém editoru vyžadovat mnoho manuální práce. Zažil jsem situaci, kdy report vznikal ručním kopírování listů z jedenácti jiných reportů. Ta práce trvala několik hodin a měla se provádět několikrát do měsíce. Pro takovéto požadavky je ideální pracovat v databázi: tam je snadné a rychlé si spočítat všechny vstupy pro váš report (zde by to znamenalo vygenerovat 11 mezivýsledků) a rovnou v databázi je i propojit. Jedinou investici potom představuje čas věnovaný jednorázovému vytvoření skriptu. Aktualizovat takovýto report typicky znamená změnit na začátku skriptu datum a potom spustit jeho výpočet. Automatizací rutinní práce získáte více času na analýzu výsledků.

Předchozí odstavce popisují, jak efektivně zpracovávat velká množství dat a sdílet výstupy. Na několika vlastnostech tabulkových editorů jsem ukázal, proč je výhodné mít data uložená v centrální databázi a dotazovat se do ní pomocí skriptu, který se snadno čte, sdílí i verzuje. Ptáte se však, jak máte s kolegy sdílet spočítané hodnoty? Právě k tomu se hodí tabulkový editor: připravte si v MS Excel barevnou šablonu s grafy, každý měsíc do ní zkopírujte výstupní data a sdílejte jen takto pěkně zpracovaný výstup! Náročnou práci s udržováním zdrojových dat a výpočtem výstupů však přenechejte databázi.

Ing. Vojtěch Filipec

Datový vědec specializující se na prediktivní metody. Jeho akademické vzdělání v jaderné fyzice je doplněno dlouholetými zkušenostmi s řízením a statistickým modelováním úvěrového rizika finančních institucí (KB, Erste Bank Group, BAWAG). Několik let působil jako interní konzultant pro kvantitativní metody ve farmaceutické firmě MSD a od roku 2017 pomáhá fin-techové společnosti Twisto vytěžovat data za účelem prevence rizik.

V Controller Institutu školí téma Analýza dat pomocí SQL