+ evitaDB je NoSQL databáze s vlastním dotazovacím jazykem, který byl navržen s ohledem na podobnost v různých + webových API i programovacích jazycích a srozumitelnost nezasvěcenému čtenáři. +
++ Na první pohled by se mohlo zdát, že dotazovací evitaQL jazyk trpí syndromem dlouhých názvů, tolik typickým pro + Java vývojáře, kteří jej navrhovali. Pokud se však zamyslíte nad naší argumentací, věříme, že návrh jazyka vám + bude dávat smysl. +
++ Nejprve si pojďme ukázat krátký příklad jednoduchého evitaQL dotazu: +
+ + +query(
+ collection("Product"),
+ filterBy(
+ attributeEquals("status", "ACTIVE"),
+ attributeGreaterThan("battery-life", 10),
+ or(
+ attributeIs("validity", NULL),
+ attributeInRangeNow("validity")
+ )
+ ),
+ orderBy(
+ attributeNatural("orderedQuantity", DESC)
+ ),
+ require(
+ entityFetch(
+ attributeContentAll()
+ )
+ )
+)
+
+
+ + Vyzkoušejte + si dotaz v evitaLab +
++ Dříve, než budete pokračovat ve čtení dál, zkuste odhadnout, co tento dotaz představuje a jaká by měla být + odpověď databázového serveru. Zkusmo jsme tuto otázku položili i ChatGPT (v. 4) a zdá se, že jeho účel + pochopil velmi dobře i přesto, + že evitaQL nebyl v roce 2021 v datech, na kterých se učil. +
++ Srozumitelnost jazyka je do jisté míry dána tím, že jeho konstrukce a názvy jednotlivých podmínek odpovídají + konstrukci anglické věty: `query collection XY, filter it by attribute A that + equals to B, order it by attribute C in natural descending order, + require entity to be fetched with entire attribute content`, a nejspíš proto + bylo odvození významu pomocí ChatGPT takto přesné. +
++ Velkou výhodou takto konstruovaného jazyka je to, že ve webových GraphQL a REST API je jeho znění velmi podobné. + Zápis v jazyce Java je identický a v případě C# klienta jsou odlišnosti taktéž minimální. Vývojáři používající + různé technologie pro svou práci (např. frontendový tým využívající v JavaScriptu GraphQL formát a backendový + tým využívající Java či C# jazyk) si tedy budou navzájem rozumět, i když uvidí dotaz vytvořený druhým týmem v + odlišné technologii. Sami se můžete o podobnosti dotazů přesvědčit v naší dokumentaci, pokud si + v pravém sloupci budete přepínat mezi různými podporovanými jazyky. +
++ Konstrukce jazyka připomíná sadu vnořených funkcí, což dává mnohem větší prostor pro to, aby se v jednotlivých + prostředích mohla převést na nativní konstrukty daného jazyka. Tím získáme možnost využít podpory kompilátorů a + linterů cílových prostředí ke kontrole obsahu dotazu (např. typové kontroly). Řada IDE také díky tomuto přístupu + nabízí vývojářům další podporu ve formě automatického doplňování dotazu, protože na základě typů a schémat ví, + jaké konstrukty (podmínky) dávají smysl v daném místě dotazu. Díky automatickému doplňování věříme, že vývojář + bude zřídkakdy nucen psát celé názvy podmínek, ale bude mu stačit zapsat pár úvodních písmen slov podmínky a + zbytek práce za něj odvede vývojářské prostředí. +
+ +Klíčové pasáže dotazu
+ ++ Dotaz se skládá ze 4 hlavních bloků, z nichž každý může za určitých situací chybět – tj. žádný z nich není + bezpodmínečně povinný: +
+-
+
+
- collection – určuje cílovou kolekci katalogu, na kterou dotaz cílí a může chybět v případě, + že se dotazujeme na entity podle globálně + unikátních atributů. + +
- filterBy – umožňuje omezit počet vrácených entit pouze na takové, které splňují filtrovací + podmínku (dokumentace). + +
- orderBy – definuje způsob řazení vrácených entit (dokumentace). + +
- require – ovlivňuje rozsah (počty, hloubku načtení) vrácených dat, umožňuje ovlivnit + chování stroje při vyhodnocování dotazu a definovat dodatečné požadavky na vedlejší výpočty, které souvisí s + vyfiltrovanými entitami (dokumentace). + +
+ Entity v kolekcích se dají vyhledávat podle primárních + klíčů, existence lokalizace + do konkrétního jazyka, shody hodnot + atributů nebo porovnání + s konstantou na vstupu, překryvu + rozsahových hodnot, řetězcových + operací nad atributy, existencí cen, existence reference na jinou + entitu či atributů definovaných na této referenci či zařazení do hierarchické + struktury. Samozřejmostí je možnost kombinovat více podmínek dohromady pomocí logických operátorů. +
++ Pokud nejsou uvedeny požadavky na řazení, jsou entity vždy řazeny vzestupně podle primárního klíče – tedy ve + formě, která je pro databázi „přirozená“. Řadit ovšem můžete podle přirozeného pořadí + hodnot atributů, exaktního + pořadí atributů či primárních + klíčů, cen, atributů referencí + (a to včetně referenci + s kardinalitou „one-to-many“) nebo náhodně. +
++ Na výstupu můžeme seznam nalezených entit stránkovat, ovlivňovat jejich + rozsah, jazyk a + to včetně možnosti načítat + graf referencovaných entit do libovolné hloubky s případnou filtrací + či řazen + uzlů v rámci načítaného grafu entit. Kromě požadavků na vrácené entity, si můžeme nechat spočítat podklady pro + zobrazení parametrického + filtru, menu či histogramů + hodnot. Ke každému dotazu si můžeme nechat vrátit i rozpad výpočtu na + straně serveru spolu s informací o času potřebném na jeho jednotlivé kroky (obdoba EXPLAIN v jazyce SQL). +
++ Některé z těchto funkcí si v rychlosti rozebereme v dalších kapitolách tohoto článku s důrazem na ty, které jsou + pro evitaDB specifické. +
+ +Načítání lokalizovaných dat
+ ++ Velká řada katalogů je lokalizovaná do různých národních prostředí. Uživatel se při práci s aplikací na tato + data kouká typicky optikou jednoho konkrétního vybraného jazyka. Tento scénář evitaDB řeší následujícím dotazem: +
+ +query(
+ collection("Product"),
+ filterBy(
+ entityPrimaryKeyInSet(103885, 103911, 105715),
+ entityLocaleEquals("cs")
+ ),
+ orderBy(
+ attributeNatural("name", DESC)
+ ),
+ require(
+ entityFetch(
+ attributeContent("name", "descriptionShort"),
+ associatedDataContent("localization")
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ Dotaz nám vrátí 3 záznamy v české lokalizaci seřazené sestupně podle české varianty jejich názvu. Pokud by + některý ze jmenovaných produktů českou mutaci neobsahoval, vůbec se ve výsledku nevrátí. Použití podmínky + `entityLocaleEquals` nejen že ovlivňuje filtraci entity, ale zároveň se stává zdrojem pro volbu implicitního + jazyka při získávání hodnot lokalizovaných atributů a asociovaných dat. Pokud změníte hodnotu `locale` na `en`, + získáte hodnoty pro anglický jazyk. Pro identifikaci locale se používá zápis ve formátu tzv. language tagu, který je univerzálním zápisem pro + řadu různých platforem. +
++ Ačkoliv tento mechanismus celkem snadno vyřešíte třeba i s běžnou relační databází, jeho nativní podpora + databázovým strojem přináší značné zjednodušení při zápisu dotazů, což bude umocněno funkcionalitami + popisovanými v dalších kapitolách. +
++ V některých případech budete potřebovat získat více než jen jediný jazyk entity – typicky při vytváření entit ať + už z administračního rozhraní nebo importem z jiných datových zdrojů. V těchto případech bude konstrukce dotazu + mírně odlišná: +
+ + +query(
+ collection("Product"),
+ filterBy(
+ entityPrimaryKeyInSet(103885, 103911, 105715)
+ ),
+ require(
+ entityFetch(
+ attributeContent("name", "descriptionShort"),
+ associatedDataContent("localization"),
+ dataInLocales("cs", "en")
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ V dotazu došlo ke dvěma změnám – vypadla podmínka `entityLocaleEquals` byla nahrazena žádostí o vrácení + lokalizací `cs` a `en` v deklaraci `dataInLocales`, která je součástí `require` bloku. +
++ Tato změna způsobí, že dotaz vždy vrátí všechny tři entity dle jejich primárních klíčů bez ohledu na + (ne)dostupnost lokalizací. Nalezené entity budou obsahovat lokalizovaná data pro všechny požadované jazyky + (pokud taková mají). +
+ +Načítání grafu entit (join)
+ ++ Podobně jako se v relačních databázích používá klauzule JOIN pro spojování záznamů skrz více tabulek, je v + evitaDB možné získávat nejen hlavní entitu, ale skrz reference (odkazy) na další entity celý graf provázaných + entit prakticky do libovolné hloubky. Tento mechanismus má samozřejmě svá technická omezení. Teoreticky byste si + mohli v rámci jednoho dotazu limitně načíst celý obsah databáze, což jednak nedává smysl a jednak byste se + výsledku na větších datových sadách nedočkali ani na seberychlejší databázi. +
++ Při načítání entit do hloubky používáme výraz graf entit, protože tento princip byl do značné míry inspirován + přístupem GraphQL. Ve své podstatě odpovídá tomu, jak s logickými celky pracují ORM knihovny. + Tento přístup je pro aplikační vývojáře přirozenější a používá se jim lépe než relační forma práce s daty. +
++ Na následujícím příkladě si ukážeme, jak je možné načíst produkt se všemi hodnotami jeho parametrů (např. + červená, Android, 8GB), které se dále odkazují na entitu parametru (barva, operační systém, velikost paměti). + Zároveň si vypíšeme i všechny atributy náležící referenci mezi produktem a hodnotou parametru, mezi které patří + především bool příznak, zda se jedná o vazbu identifikující variantu produktu: +
+ +
+
+ 
+
+
query(
+ collection("Product"),
+ filterBy(
+ entityPrimaryKeyInSet(103885),
+ entityLocaleEquals("cs")
+ ),
+ require(
+ entityFetch(
+ attributeContent("name"),
+ referenceContentWithAttributes(
+ "parameterValues",
+ entityFetch(
+ attributeContent("code", "name"),
+ referenceContentWithAttributes(
+ "parameter",
+ entityFetch(
+ attributeContent("code", "name")
+ )
+ )
+ )
+ )
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ Na tomto příkladě si můžete všimnout, že požadovaný jazyk stačí deklarovat jednou a všechny načtené entity + včetně těch vnořených jej respektují. Vyzkoušejte si místo češtiny vyžádat anglické názvy entit. +
++ Příklad je do velké míry zjednodušený, protože i v těch velmi jednoduchých katalozích bude mít položka velké + množství relací na okolní entity a nedávalo by smysl se je snažit všechny zohledňovat v tomto článku. Běžné jsou + i reference s kardinalitou „1:N“, které se mohou odkazovat na značné množství okolních entit. Proto jazyk + umožňuje na úrovni jednotlivých referencí definovat filtrovací podmínky a definovat řazení referencí s + kardinalitou větší než jedna: +
+ + +query(
+ collection("Product"),
+ filterBy(
+ entityPrimaryKeyInSet(103885)
+ ),
+ require(
+ entityFetch(
+ referenceContentWithAttributes(
+ "parameterValues",
+ filterBy(
+ entityHaving(
+ referenceHaving(
+ "parameter",
+ entityHaving(
+ attributeContains("code", "r")
+ )
+ )
+ )
+ ),
+ orderBy(
+ entityProperty(
+ attributeNatural("code", DESC)
+ )
+ ),
+ entityFetch(
+ attributeContent("code"),
+ referenceContentWithAttributes(
+ "parameter",
+ entityFetch(
+ attributeContent("code")
+ )
+ )
+ )
+ )
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ Tento dotaz je prakticky shodný s předchozí ukázkou, pouze při načítání hodnot parametrů vrátí pouze ty, které + patří do parametru s kódem obsahujícím písmeno `r`. Zároveň tyto hodnoty parametrů seřadí sestupně podle jejich + kódu. To zajistí nové podmínky `filterBy` a `orderBy` deklarované na úrovni deklarace zajišťující načtení + reference `parameterValues`. +
+Parametrizované filtry (facety)
+ + ++ Parametrizované filtry dávají smysl u katalogů s velkým množstvím položek, ve kterých by se uživatel jen těžko + vyznal. Parametrické filtry jsme zmiňovali už v prvním + článku této série a vidíte je běžně na internetu, takže zde se budeme soustředit pouze na to, jak vám s nimi + může pomoci právě evitaDB. +
++ Podklady pro zobrazení filtru si můžete nechat připravit v rámci tzv. vedlejších výpočtů, které jsou spojené se + základním dotazem na položky katalogu. Dotaz obsahující parametrický filtr by mohl vypadat například následovně: +
+ +query(
+ collection("Product"),
+ filterBy(
+ attributeEquals("status", "ACTIVE"),
+ userFilter(
+ facetHaving(
+ "groups",
+ entityHaving(
+ attributeEquals("code", "sale")
+ )
+ )
+ )
+ ),
+ require(
+ facetSummary(
+ COUNTS,
+ entityFetch(
+ attributeContent("code")
+ ),
+ entityGroupFetch(
+ attributeContent("code")
+ )
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ Klíčovými položkami tohoto dotazu je `facetSummary` v bloku `require` a `userFilter` v bloku `filterBy`. Z + dotazu je patrné, že se snažíme vypsat entity typu `Product`, které splňují nějaké základní vlastnosti – v tomto + případě je to reprezentováno podmínkou, že atribut `status` musí obsahovat hodnotu `ACTIVE` (tzv. systémová + podmínka) a také uživatelem definované vlastnosti – v tomto případě musí obsahovat referenci `groups` na entitu + s kódem `sale`. Rozdělení na systémovou a uživatelskou část filtrovací podmínky je klíčové pro výpočet hodnot v + rámci `facetSummary`, jak si vysvětlíme následně. +
++ Požadavek na výpočet `facetSummary` vám pro všechny položky, které splňují systémové podmínky základního dotazu, + vrátí seznam odkazovaných entit s informací o počtu položek, které se na danou entitu odkazují. Tyto entity jsou + seskupeny do logických celků (skupin) podle informací nastavených ve schématu katalogu. +
++ Pokud si přečtete dokumentaci o tvorbě + schématu, zjistíte, že na úrovni schématu reference je možné označit danou referenci jako `faceted`. Zároveň + je možné u každé reference nastavit vazbu na sekundární entitu, která reprezentuje její zařazení do nějaké + logické skupiny. Tím, že je tato informace nastavená už na úrovni schématu, si může databázový stroj dopředu + připravit požadované indexy a zároveň tento přístup zjednodušuje následné sestavování dotazů, kde již není třeba + tyto informace neustále opakovat. +
++ V našem dotazu tedy stačí pouze definovat požadavek na výpočet podkladů pro parametrický filtr s žádostí o + dotažení atributu `code` jak pro odkazovanou entitu, tak i pro entitu, která reprezentuje logické seskupení + odkazovaných entit. evitaDB pak už ví, že si má všímat všech referencí, označených ve schématu jako `faceted` a + ví vše o těchto odkazovaných entitách. +
++ Pokud si dotaz spustíte v nástroji evitaLab, vrátí se vám výsledek + primárně ve formátu JSON – tedy tak, jak jej budete pravděpodobně konzumovat ve své aplikaci, ale máte zde i + možnost v pravé části přepnout pohled na vizualizaci typizovaného parametrizovaného filtru pro jednodušší + porozumění vráceným datům. Náhled bude vypadat následovně: +
+
+
+ 
+
+
+ Z vizualizace je patrné, že evitaDB vrátila informaci o odkazovaných entitách, kdy na úrovni každé této entity + je dostupná informace, kolik produktů se váže ke každé jednotlivé referenci na cílovou entitu (pro entitu `sale` + – výprodej – to je 39 produktů, pro `for-men-group` je to 239 atp.). Zároveň je u všech entit, které jsou + vyžadované tzv. uživatelským filtrem, informace o tom, že tyto entity jsou součásti požadovaného výběru, a tudíž + je jejich položka `zaškrtnutá`. Tyto podklady jsou vypočteny i pro všechny ostatní reference produktu, které + jsou ve schématu označeny jako `faceted` – tj. pro sklady, štítky, kategorie, značky a hodnoty parametrů. Pokud + si rozkliknete právě hodnoty parametrů, uvidíte, že ty jsou členěny do dvou úrovní, kdy první úroveň + reprezentuje parametry a teprve v nich jsou informace o hodnotách. +
++ Dotaz reprezentuje pouze základní výstup pro parametrizovaný filtr, který dokážete získat i pomocí + alternativních databází, jako jsou Elasticsearch, Typesense, Meilisearch nebo Algolia. V evitaDB + však můžete při výpočtu požádat o výpočet tzv. „dopadové analýzy“, pro kterou ve výše uvedených databázích + neexistuje alternativa. +
++ Dopadová analýza spočítá ke každé nabízené entitě informaci o tom, jaký by mělo její zahrnutí do filtru dopad na + výsledek dotazu. Prakticky to znamená vypočítat pro každou takovou položku další dodatečný dotaz vycházející ze + stávajícího dotazu a rozšířený o podmínku na existenci reference pro tuto, v současnosti nevybranou, entitu. +
++ Pro výpočet dopadové analýzy nám stačí změnit typ výpočtu z `COUNTS` na `IMPACT`: +
+ +query(
+ collection("Product"),
+ filterBy(
+ attributeEquals("status", "ACTIVE"),
+ userFilter(
+ facetHaving(
+ "groups",
+ entityHaving(
+ attributeEquals("code", "sale")
+ )
+ )
+ )
+ ),
+ require(
+ facetSummary(
+ IMPACT,
+ entityFetch(
+ attributeContent("code")
+ ),
+ entityGroupFetch(
+ attributeContent("code")
+ )
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ Výpočet je logicky výkonnostně mnohem náročnější, ale ve výsledku u každé položky uvidíte informaci o počtu + produktů, které z výsledku zmizí nebo přibudou, pokud do uživatelského výběru zahrnete podmínku na existenci + vazby na odpovídající entitu. Pokud se podíváme do nástroje evitaLab na výsledky vizualizace tohoto dotazu pro + parametr `Typ displeje`, uvidíme, že výběrem vlastnosti `TFT` displej by ve výběru ze současných 39 produktů + zůstalo pouze 12 (tj. o 27 bychom přišli). V případě `OLED` displejů bychom přišli téměř o celý výběr a zůstal + by nám pouze jediný produkt, který je aktivní a je ve skupině výprodej. +
+
+
+ 
+
+
+ Výpočty podkladů pro parametrické filtry vychází z předpokladu „běžných vztahů“ položek v nabídce – tedy že + položky ve stejné skupině se spojují logickou vazbou OR a položky v různých skupinách / odlišných referencích se + spojují logickou vazbou AND. V praxi se občas setkáváme s odlišnými požadavky, a proto je možné tyto vztahy v + rámci dotazu upravit – například stanovit, že logická skupina „alergeny“ se chová tak, že výběr položky „buráky“ + znamená vyloučení + všech produktů vztahujících se k burákům z výběru. Popřípadě možnost definovat, že u reference typu „štítky“ se + jednotlivé entity kombinují + logickým AND – tedy že zaškrtnutí štítků „novinka“ a „skladem“, které jsou ve stejné logické skupině + znamená, že se vyberou produkty, které jsou na skladě a zároveň se jedná o novinky. Tyto vztahy mají dopad jak + na chování podmínky `facetHaving` uvnitř `filterBy` bloku, tak na chování výpočtu v rámci `facetSummary`. +
++ Výchozí chování `facetSummary`, kdy se vypočtou všechny údaje pro úplnou sadu referencí označenou jako + `faceted`, je na řadě míst nežádoucí, protože dává příliš velký výsledek. Výpočet je tedy možné omezit + pouze na určité typy referencí nebo v rámci konkrétního typu reference omezit pouze na entity, které splňují + určitou podmínku. Toto chování si můžeme ukázat na příkladu hodnot parametrů (např. červená), které spadají do + parametrů (např. barva). Produkt má obvykle celou sadu parametrů, ale pouze podle některých má smysl filtrovat. + Můžeme si tedy na úrovni parametru vést informaci o tom, zda má být daný parametr zahrnutý do filtru či slouží + pouze k zobrazení dat na detailu produktu. Udělejme to pomocí jednoduchého boolean atributu `isVisibleInFilter`, + který bude nastaven na `true` u těch parametrů, které mají být v nabídce uživatelského filtru a upravme dotaz + následovně: +
+ +query(
+ collection("Product"),
+ filterBy(
+ attributeEquals("status", "ACTIVE"),
+ userFilter(
+ facetHaving(
+ "groups",
+ entityHaving(
+ attributeEquals("code", "sale")
+ )
+ )
+ )
+ ),
+ require(
+ facetSummaryOfReference(
+ "parameterValues",
+ IMPACT,
+ filterGroupBy(
+ attributeEquals("isVisibleInFilter", true)
+ ),
+ entityFetch(
+ attributeContent("code")
+ ),
+ entityGroupFetch(
+ attributeContent("code")
+ )
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ Vidíme, že ve výsledku dotazu zbyla pouze nabídka parametrů, která je ještě znatelně menší než nabídka původní. + Kromě filtrování obsahu parametrického filtru je možné nabídku položek i seřadit. + V rámci načítání entity parametrického filtru samozřejmě funguje i načítání grafu do hloubky, takže ke každé + skupině či odkazované entitě si můžete načíst všechna potřebná data v rámci jednoho dotazu. +
+ +Histogramy
+ ++ Histogramy se občas používají pro vizualizaci rozložení hodnot s velkou kardinalitou na omezené ploše. V praxi + se příliš nevídají, ačkoliv jsou šikovnou pomůckou uživateli při výběru v intervalovém filtru. +
++ V rámci evitaDB query si můžeme aktuálně říci o výpočet histogramu pro libovolný filtrovatelný atribut číselného + typu, ale v blízké budoucnosti plánujeme rozšíření i o výpočet + histogramu přes reference. O kalkulaci histogramu pro atribut si říkáme následujícím způsobem: +
+ +query(
+ collection("Product"),
+ filterBy(
+ priceValidInNow(),
+ priceInPriceLists("basic"),
+ priceInCurrency("EUR"),
+ userFilter(
+ priceBetween(100, 2000),
+ attributeBetween(
+ "battery-capacity", 2000, 6000
+ )
+ )
+ ),
+ require(
+ priceHistogram(30),
+ attributeHistogram(30, "battery-capacity")
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ V bloku `require` si požádáme o výpočet `priceHistogram` a `attributeHistogram` s uvedením počtu požadovaných + sloupců pro výstupní histogram a v případě atributu i o jeho název. Blok `filterBy` opět obsahuje systémovou a + uživatelskou podmínku. Uživatelská část podmínky obsahuje rozsah stanovený uživatelem, které mají být vzaty v + potaz při výběru odpovídajících entit. +
++ Výstupní kalkulaci si opět představíme ve formě vizualizace, kterou nám nabízí nástroj evitaLab: +
+
+
+ 
+
+
+ Vrácená data nám umožňují vykreslit histogram s četnostmi produktů v rámci různých cenových hladin a číselné + hodnoty kapacity baterie. Při výpočtu histogramu se bere v potaz celý dotaz vyjma podmínky týkající se daného + atributu / ceny v uživatelské části filtrovací podmínky (`userFilter`). Pokud by tomu tak nebylo, uživatel by + nikdy nebyl schopný zase rozšířit svůj původní výběr. Součástí vypočtených sloupců je i informace, jestli daný + sloupec nebo jeho část byla součástí uživatelského filtru či nikoliv, což umožňuje vizuálně odlišit část + histogramu reprezentovanou současným výběrem produktů. +
++ Standardně databáze vrací počet sloupců přesně odpovídající hodnotě požadované v klauzuli histogramu. V rámci + uživatelského testování se ovšem ukázalo, že u menšího počtu hodnot lépe funguje tzv. adaptivní přístup, kdy je + počet sloupců přizpůsoben datům. Mějme hypotetickou situaci, kdy chceme vizualizovat histogram se 100 sloupci, + ale současnému dotazu odpovídají pouze nízké jednotky položek – např. dvě. Pak bychom měli histogram, kde by + byly pouze dva sloupce, a to první a poslední, a mezi nimi by byl prázdný prostor. +
++ Tento výstup jednak nevypadá vizuálně dobře a často se kvůli šířce sloupců špatně vybírá ten správný rozsah. + Proto můžete v histogramu požádat o tzv. „optimální“ výstup, který zaručuje, že nikdy nebude vrácen větší počet + sloupců než jste požádali, ale v případě velkých mezer mezi sloupci histogramu bude jejich počet snížen tak, aby + mezera nebyla širší než jeden sloupec +
+ +Hierarchické struktury
+ ++ Valná většina katalogů pohlíží na položky skrze hierarchicky organizované menu kategorií různého druhu typicky + tak, že zobrazuje položky z kategorie, kterou má uživatel vybranou, a zároveň i ze všech podkategorií této + kategorie. Vzhledem k tomu, že se jedná o tak běžný scénář, má evitaDB pro tuto oblast celou sadu výrazových + prostředků a zároveň optimalizuje své indexy tak, aby dotazy do hierarchické struktury byly rychlejší, než + dotazy bez tohoto zacílení. +
++ V našich příkladech budeme vycházet z následující struktury kategorií, které můžete nalézt i v naší ukázkové + datové sadě: +
+
+
+ 
+
+
+ Ukažme si nejprve úplně typický příklad dotazu, který vypíše všechny produkty z kategorie Accessories + (Příslušenství): +
+ + +query(
+ collection("Product"),
+ filterBy(
+ hierarchyWithin(
+ "categories",
+ attributeEquals("code", "accessories")
+ )
+ ),
+ require(
+ entityFetch(
+ attributeContent("code")
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ Dotaz vyhledá všechny záznamy z kolekce produktů, které mají referenci s názvem `categories` odkazující se na + entitu s kódem `accessories`. Ze schématu se dozvíme, že reference `categories` cílí na entitu s názvem + `Category`, která je označena jako hierarchická. Pokud by nebyla, evitaDB by u tohoto typu dotazu vrátila chybu. + Z této informace si evitaDB odvodí, že chcete vrátit všechny kódy produktů v kategorii `accessories` a všech + jejích podřízených kategorií. Samozřejmě je možné dotaz upravit tak, že se zobrazí jen produkty v kategorii + přímo zařazené nebo si vylistovat nikoliv seznam produktů, ale přímo podkategorií dané + kategorie. V dokumentaci najdete + ještě řadu dalších možností. +
++ Zajímavé jsou především podřízené podmínky `having` + a `excluding`. + Ty umožňují při procházení hierarchie (tj. stromu kategorií) některé části (podstromy) vynechat. Občas jste si + mohli všimnout, že v nákupních domech je určitá část regálů za plentou – protože se připravuje nový prodejní + prostor se specializovanou nabídkou. Obdobně i v katalozích se často připravují nové části, do kterých mají + přístup pouze zaměstnanci, kteří na nich pracují. Tyto funkce nám podobné scénáře umožňují řešit celkem + jednoduše: +
+ +query(
+ collection("Product"),
+ filterBy(
+ hierarchyWithin(
+ "categories",
+ attributeEquals("code", "accessories"),
+ excluding(
+ attributeEquals("code", "wireless-headphones")
+ )
+ )
+ ),
+ require(
+ entityFetch(
+ attributeContent("code")
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ Výše uvedený dotaz simuluje podobný případ – jako návštěvník vidím v kategorii `accessories` všechny produkty, + které do ní patří vyjma těch, které jsou zařazeny do podstromu kategorie `wireless-headphones`. Uživatel + vystupující jako zaměstnanec, by danou podmínku v dotazu neměl, a tudíž by viděl i za zmíněnou hypotetickou + „plentu“. Samozřejmě můžeme celý problém ještě o něco více zobecnit a umožnit uživatelům vidět např. všechny + produkty z kategorií, které mají hodnotu atributu `access` nastavenou na `PUBLIC` atp. +
++ Podobně elegantním způsobem se dají řešit i časově omezené nabídky. Dejme tomu, že v kategorii příslušenství si + chceme dopředu připravit „Vánoční nabídku“, která obsahuje LED osvětlení vánočních stromků, pyrotechniku a + podobně. Pokud v entitě kategorie vytvoříme atribut typu `DateTimeRange` s názvem `validity` a nastavíme jeho + hodnotu pouze na vánoční období, můžeme potom definovat následující dotaz: +
+ +query(
+ collection("Product"),
+ filterBy(
+ hierarchyWithin(
+ "categories",
+ attributeEquals("code", "accessories"),
+ having(
+ or(
+ attributeIsNull("validity"),
+ attributeInRangeNow("validity")
+ )
+ )
+ )
+ ),
+ require(
+ entityFetch(
+ attributeContent("code")
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ Tedy: vypiš mi všechny produkty z kategorie `accessories` za předpokladu, že jsou zařazeny v kategorii bez + definované platnosti (`validity`) nebo mají definovaný rozsah platnosti, do které spadá současný okamžik. +
++ Některé položky bývají zařazeny v různých kategoriích – např. žvýkačky v obchodech uvidíte v sekci „sladkosti“, + ale také před pokladnami mezi produkty, na které máte dost času se dívat než zaplatíte. Pokud obchodní dům + oplotí sekci sladkostí, protože je předělává do nové podoby, měli byste přestat mít možnost koupit žvýkačky u + pokladny? Jistěže ne. Stejně se zachová i evitaDB a pokud nalezne alespoň jednu referenci produktu do viditelné + části hierarchického stromu, zahrne tento produkt do výsledků vyhledávání. +
+ +Transpozice hierarchie
+ ++ Tím však možnosti hierarchického vyhledávání nekončí. Kromě výpisu záznamů náležejících do konkrétního místa + stromu běžně potřebujeme současně tuto hierarchickou strukturu vizualizovat v podobě nějakého menu. Bohužel + neexistuje nic jako „univerzální menu“ – možností jak pohlížet a vizualizovat hierarchické struktury je celá + řada. Oblíbená jsou třeba „mega-menu“: +
+
+
+ 
+
+
+ Běžně také vidíme jednoduchý výpis nejbližších podřízených kategorií: +
+
+
+ 
+
+
+ Či plně dynamická rozklikávací menu: +
+
+
+ 
+
+
+ Až po různá hybridní řešení, kdy se zobrazují třeba jen kategorie první úrovně a cesta k aktuálně vybrané + kategorii se zobrazením kategorií stejné úrovně, jako třeba na následujícím obrázku: +
+
+
+ 
+
+
+ Zcela běžně na stejné stránce potkáte i více různých druhů menu najednou – např. mega-menu, výpis nejbližších + podřízených kategorií a levé vertikální menu současně. +
++ Otázka tedy zní, jak získat všechny potřebné údaje pro zobrazení menu souvisejících s aktuálním výpisem položek + z daného místa hierarchie a příliš nekomplikovat dotazovací jazyk? +
++ Pro tyto účely evitaDB využívá možnosti bloku `require`, který dovoluje výpočet přidružených kalkulací + souvisejících se základním dotazem. V rámci tohoto bloku je možné nechat si vypočítat všechny + potřebné podklady pro to, abychom dokázali sestavit taková menu, jaká budeme potřebovat. Stačí vytvořit + požadavek na vytvoření daného řezu hierarchií, pojmenovat si ho a pak si už jen vyzvednout výsledek kalkulace ve + výsledných datech. Pro demonstraci si pojďme ukázat, jak by mohla vypadat kalkulace hybridního menu: +
+ + +query(
+ collection("Product"),
+ filterBy(
+ hierarchyWithin(
+ "categories",
+ attributeEquals("code", "audio")
+ )
+ ),
+ require(
+ hierarchyOfReference(
+ "categories",
+ fromRoot(
+ "topLevel",
+ entityFetch(attributeContent("code")),
+ stopAt(level(1))
+ ),
+ parents(
+ "parents",
+ entityFetch(attributeContent("code"))
+ ),
+ siblings(
+ "siblings",
+ entityFetch(attributeContent("code"))
+ )
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ Tento dotaz kromě produktů vrátí i 3 složky dodatečné kalkulace. Kalkulace `topLevel` obsahuje hierarchické + záznamy propojené s vypsanými produkty na kořenové úrovni. Kalkulace `parents` vypíše osu nadřízených + hierarchických záznamů vůči záznamu `audio`, na který cílí dotaz pro výpis produktů, a nakonec kalkulace + `siblings` vypíše osu sousedních hierarchických záznamů (tj. záznamů sdílejících stejného rodiče jako záznam + `audio`). Z těchto dat je pak možné poměrně jednoduše vytvořit kombinované hybridní menu. Záměrně je vybraný + jeden ze složitějších případů užití, aby bylo možné demonstrovat kombinace různých řezů hierarchií. Vytvoření + megamenu je podstatně jednodušší záležitostí. +
+ +query(
+ collection("Product"),
+ require(
+ hierarchyOfReference(
+ "categories",
+ fromRoot(
+ "megaMenu",
+ entityFetch(attributeContent("code")),
+ stopAt(level(2))
+ )
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ Tip: když si tento dotaz vyzkoušíte v evitaLab + a přepnete záložku výsledků na vizualizaci, uvidíte fragmenty menu v mnohem srozumitelnější podobě. +
++ Ke každé položce hierarchického menu je možné si nechat vypočítat + následující údaje: +
+-
+
+
- Počet podřízených hierarchických úrovní. + +
- Počet záznamů výpisu, které se vztahují k danému hierarchickému záznamu. + +
+ Jedná se o prostá čísla, která napoví, jestli dává smysl danou kategorii otevřít, i když jsme si v rámci + kalkulací nenechali tyto části stromu vypsat, protože je nutně nepotřebujeme. +
+ + +query(
+ collection("Product"),
+ require(
+ hierarchyOfReference(
+ "categories",
+ fromRoot(
+ "megaMenuWithCounts",
+ entityFetch(attributeContent("code")),
+ stopAt(level(2)),
+ statistics(
+ CHILDREN_COUNT,
+ QUERIED_ENTITY_COUNT
+ )
+ )
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ Čísla korektně reflektují podmínky stanovené ve filtrační části dotazu – pokud jsou tedy některé podstromy + podmínkou vyloučeny, nebudou započteny do těchto součtů ani přímo (tj. na úrovni počtu podřízených + hierarchických úrovní) ani transitivně (tj. položky do nich zařazené se nezapočítají do počtu záznamů v dané + části stromu). Položky zařazené do stromu se načítají očekávaným způsobem – tedy pro strom: +
+
+
+ 
+
+
+ Počet položek zařazených do stromu `Portables` tvoří součet položek zařazených do třech podřízených kategorií + plus počet položek zařazených přímo do kategorie `Portables`. Pokud je některá z položek zařazena zároveň do + více kategorií (např. do `Tablets` a `E-readers` zároveň) je do součtu zahrnuta pouze jednou. +
+Nalezení prodejní ceny
+ + ++ Stanovení prodejní ceny je potřeba pouze pro třídění položek podle ceny (od nejdražší / nejlevnější) a pro + nalezení položek v určité cenové hladině. Pokud u svého katalogu tuto funkcionalitu nepotřebujete, celá tato + kapitola se vás netýká. +
++ Určení prodejní ceny může být v B2C segmentu velmi přímočaré – tyto katalogy si často drží jen jedinou prodejní + cenu či cenu akční. V B2B segmentu je naopak cenotvorba velmi pestrá a různé ERP systémy, které bývají primárním + zdrojem cen, přistupují k tvorbě prodejní ceny odlišně. Proto evitaDB obsahuje velmi jednoduchý algoritmus pro + výpočet prodejní ceny, který jednak umožňuje tuto cenu spočítat relativně rychle a zároveň umožňuje tyto + složitější algoritmy do tohoto zjednodušeného přístupu převést. +
++ Každá položka katalogu může mít jednu i více cen v různých měnách, přiřazené k různým ceníkům. Při vyhledávání + ceny se potom hledá první cena, která odpovídá kombinaci požadované měny a sady ceníků v pořadí dle důležitosti + (tj. pořadí ceníků v položeném dotazu hraje klíčovou roli). Pojďme si hned jeden takový dotaz ukázat: +
+ +query(
+ collection("Product"),
+ filterBy(
+ priceInPriceLists("management-price", "employee-basic-price", "basic"),
+ priceInCurrency("EUR")
+ ),
+ require(
+ entityFetch(
+ attributeContent("code"),
+ priceContentRespectingFilter()
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ Pro tento dotaz se algoritmus bude nejdříve snažit u každé položky najít cenu v měně EUR v ceníku + `management-price`, a pokud ji nenajde, zkusí ji najít v ceníku `employee-basic-price`. Pokud nebude ani zde, + vyzkouší ještě ceník `basic`. Pokud nenajde žádnou cenu, produkt ve výsledné sadě nebude. Algoritmus je velmi + jednoduchý, ale doposud se nám vždy podařilo najít způsob, jak na něj cenové politiky na straně zákazníka + převést. Často to ovšem vyžaduje předpočítání cen, které na straně ERP neexistují (protože se počítají + dynamicky) a trochu kreativity. Stále + zvažujeme přínosy možných rozšíření algoritmu, ale zároveň se nechceme připravit o stávající jednoduchost a + pochopitelnost. +
++ Dalším faktorem, který ve výpočtu ceny často hraje roli, je časové hledisko. Na úrovni ceny je možné stanovit + její časovou platnost a do filtračního bloku přidat `priceValidIn` + podmínku, která v daném časovém okamžiku neplatné ceny vyloučí. +
++ Simulace výpočtu je dostupná i v našem nástroji evitaLab. Pokud si zobrazíte + tabulku entit, které obsahují ceny (v případě demo datasetu se jedná o entitu `Product`), můžete se + prokliknutím buňky s cenou produktu dostat do podrobnějšího výpisu všech cen produktu. V tom můžete filtrovat + podle ceníku a měny, což vám umožňuje i náhled výpočtu prodejní ceny v různých situacích, a tudíž i možnost se s + principy výpočtu seznámit blíže: +
+
+
+ 
+
+
+ Výpis produktů je možné také podle prodejní ceny filtrovat. Typicky chceme mít možnost vylistovat pouze + produkty, které lze koupit v cenovém rozpětí, na které máme připravené finanční prostředky. Podobný dotaz včetně + třídění produktů dle prodejní ceny vzestupně (od nejlevnějšího k nejdražšímu) by tedy vypadal takto: +
+ + +query(
+ collection("Product"),
+ filterBy(
+ priceInPriceLists("management-price", "employee-basic-price", "basic"),
+ priceInCurrency("EUR"),
+ userFilter(
+ priceBetween(100.0, 125.0)
+ )
+ ),
+ orderBy(
+ priceNatural(ASC)
+ ),
+ require(
+ entityFetch(
+ attributeContent("code"),
+ priceContentRespectingFilter()
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ V dotazu vidíte typické použití, kdy podmínka `priceBetween` je umístěna v kontejneru `userFilter` a to proto, + že argumenty této podmínky ovlivňuje uživatel svým zásahem a mohou být za určitých podmínek „porušeny“, kdežto + podmínky ležící mimo tento kontejner porušeny být nikdy nesmí. K porušení podmínek dochází například v případě + výpočtu `facetSummary`, kdy není vhodné, aby nastavení cenového rozmezí ovlivňovalo výpočet základního počtu + produktů pro jednotlivé vlastnosti. +
++ Při výpočtu prodejní ceny se standardně používá cena s daní. V případě B2B segmentu je však vhodné pracovat s + cenami bez daně, protože plátce DPH zajímá právě tato cena. Přepnutí výpočtu na ceny bez DPH se provádí pomocí + `require` požadavku `priceType`. +
+ +Výpočet ceny pro virtuální produkty s agregovanými cenami
+ +Základní produkty
+ ++ V prostředí e-commerce se běžně setkáváme s tzv. základními produkty (často také nazývanými mateřské, primární + či v angličtině master / basic / parent), které zastřešují sadu variantních produktů. Typickým příkladem mohou + být trička v módním katalogu, která se vyrábí v různých velikostech či barevných odstínech, a přesto se jedná o + stejná trička se společným motivem. Protože by byl výpis produktů v tomto případě velmi nepřehledný seskupují se + tyto variantní produkty do jednoho společného (zastřešujícího), nicméně virtuálního produktu, který je ve + výpisech zastupuje (byť se sám o sobě nedá koupit). +
++ V tomto případě potřebujeme ze všech prodejních cen variantních produktů vybrat jednu z cen, která bude + zastupovat celou sadu. Výběr jediné ceny je nutný z toho důvodu, aby bylo možné produkt společně s ostatními + řadit podle prodejní ceny nebo podle prodejní ceny filtrovat. +
++ Tuto úlohu modelujeme tak, že k záznamu virtuálního základního produktu přiřadíme ceny všech jeho variantních + produktů a použijeme pole `innerRecordId` pro odlišení sad cen jedné varianty od cen varianty druhé. Virtuálnímu + produktu je dále nutné nastavit režim výpočtu ceny na `FIRST_OCCURRENCE`. Tato kombinace způsobí, že pro daný + produkt se nejprve vypočítají prodejní ceny pro variantní produkty (tj. separátně pro každou shodnou hodnotu + `innerRecordId`) a následně se vybere nejnižší z těchto prodejních cen, která se stane cenou prodejní pro + zastupující virtuální produkt. Drobně odlišné chování bude v případě použití `priceBetween` podmínky, kdy dojde + před volbou finální ceny k vyfiltrování prodejních cen variantních produktů podle zvoleného rozsahu a teprve + potom výběr nejnižší ceny pouze z těch, které zbyly. Tj. z pohledu uživatele dojde k nalezení virtuálního + produktu, pokud alespoň jednu z jeho variant lze v požadovaném cenovém rozsahu koupit a tento produkt bude + následně označen právě touto nejnižší cenou z požadovaného cenového rozsahu. +
++ Způsob dotazování je samozřejmě shodný – změněný způsob výpočtu je daný nastavením údajů na dané entitě. + Následující dotaz cílí na produkty, u kterých víme, že se jedná o základní produkty a můžeme tak lépe + experimentovat s odlišným výpočtem: +
+ +query(
+ collection("Product"),
+ filterBy(
+ attributeEquals("productType", "MASTER"),
+ priceInPriceLists("management-price", "employee-basic-price", "basic"),
+ priceInCurrency("EUR"),
+ userFilter(
+ priceBetween(100.0, 125.0)
+ )
+ ),
+ require(
+ entityFetch(
+ attributeContent("code"),
+ priceContentRespectingFilter()
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ ++ Poznámka: do budoucna plánujeme ještě plnohodnotnou podporu seskupování (groupBy) na základě + některých atributů entity. Ta by měla umožnit řešit úlohu s variantními produkty ještě jiným způsobem, který + má zároveň další pozitivní dopady na problematiku parametrického (facetového) filtrování. +
+ +Produktové sady (komplety)
+ ++ Existuje ještě další druh virtuálních produktů a to jsou produkty, které se skládají z více položek + (pod-produktů) a jsou oceňovány zvlášť. Příkladem může být skříňka, která se skládá z korpusu, dvířek, pantů a + madel. Cena skříňky se pak skládá ze součtu cen všech těchto částí, přičemž v B2B prostředí může být tato cena + vypočtená různě pro různé zákazníky. Například zákazník „A“ má 30% slevu na madla a panty, kdežto zákazník „B“ + 15% slevu na korpus. Vzhledem k různorodým slevám na různé části není možné vypočítat všechny kombinace slev + dopředu a je nutné finální prodejní cenu počítat v reálném čase unikátně pro každého ze zákazníků. +
++ Způsob práce s cenami je podobný tomu pro „základní produkty“ popsané v minulé kapitole. Na úrovni virtuálního + kompletu jsou evidované ceny všech jeho částí, které se od sebe odlišují identifikátorem v `innerRecordId` ceny. + Nicméně na úrovni entity je nastavena výpočetní strategie `SUM`. Pro tyto případy pak postupuje algoritmus tak, + že nejdříve vypočte prodejní ceny pro každou z jeho částí dle `innerRecordId`, následně všechny prodejní ceny + sečte a tím dojde k výsledné prodejní ceně celého kompletu, která se používá pro následné třídění a filtrování + produktů dle ceny. +
++ Následujícím dotazem si můžete toto chování sami vyzkoušet: +
+ +query(
+ collection("Product"),
+ filterBy(
+ attributeEquals("productType", "SET"),
+ priceInPriceLists("management-price", "employee-basic-price", "basic"),
+ priceInCurrency("EUR"),
+ userFilter(
+ priceBetween(100.0, 125.0)
+ )
+ ),
+ require(
+ entityFetch(
+ attributeContent("code"),
+ priceContentRespectingFilter()
+ )
+ )
+)
+
+ + Vyzkoušejte + si dotaz v evitaLab +
+ +Závěr
+ ++ Celým dotazovacím jazykem se prolíná myšlenka získat jediným dotazem všechna data potřebná pro zpracování + uživatelského scénáře. Čím méně dotazů, tím menší daň bude nutné zaplatit ve fixních nákladech za uskutečněné + požadavky na databázový server (režie na zpracování HTTP požadavku jako takového). Zároveň databáze vidí mnohem + širší kontext a umožňuje jí to lépe optimalizovat provedení dotazu a znovu použít již vypočtené mezivýsledky při + zpracování dotazu. +
++ Ačkoliv byla tato kapitola celkem dlouhá, je patrné, že dotazovací jazyk není tak bohatý jako jazyk SQL, ale + pokrývá základní functionality, které budete pro vývoj katalogového systému potřebovat. V budoucnosti chceme + přidat alespoň základní podporu pro prostorové + dotazy, které by nám dovolily vyhledávat body zájmu v prostoru (například výdejnomaty v oblasti). Stejně tak + plánujeme podporu fulltextového vyhledávání. Pokud + máte v dané oblasti expertízu a chtěli byste nám ve vývoji pomoci, ozvěte se nám na našem Discord kanálu – jakoukoliv pomoc či konzultace s radostí uvítáme. +
++ V dalším dílu našeho seriálu si povíme o webových API (GraphQL, REST, gRPC), které databáze automaticky + vystavuje, a které můžete využít při vývoji svých aplikací. Věříme, že po přečtení dalšího dílu a vyzkoušení + těchto API pochopíte hlouběji, proč je dotazovací jazyk designován takovým způsobem, jakým je. +
+ +