Osvědčené postupy pro tvorbu zpráv
Toto téma popisuje klíčové faktory, které je třeba vzít v úvahu při používání aplikace Application Studio k psaní reportů nad datovými kostkami OLAP.
Úvahy o přední části
V této tabulce jsou uvedeny klíčové aspekty návrhu přední části sestavy:
| Úvaha | Popis |
|---|---|
| Obsahují vaše reporty vnořené hyperbloky? | Lépe funguje sestava založená na výseči, kde jsou hyperbloky filtrovány například tak, aby byly vyloučeny nulové hodnoty. S používáním řezů je spojena křivka učení a některé žádoucí funkce chybí, ale dostupné funkce splňují 80 % případů použití. |
| Vyžadují zprávy vertikální rolování? | Pokud ano, zařaďte do zápatí sestavy webové rozšíření pro stránkování. Zlepšuje uživatelský komfort a výkon. |
| Používají sestavy podmíněné formátování? | Podmíněné formátování je výkonná funkce, ale používejte ji střídmě kvůli jejímu vlivu na výkon při vyhodnocování podmínek. Při použití formátu čísla se vyhnete podmíněnému formátování a spoléháte se na formáty čísel definované v databázi. Application Studio shlukuje datové požadavky vzorců, které jsou odesílány do databáze OLAP. Výsledkem je jeden celkový dotaz namísto více dotazů na jednotlivé buňky. Klastrové dotazy jsou rychlejší než přístup k jednotlivým buňkám. Vzorce pro čtení dat v podmíněných formátech a skocích sestavy nelze seskupovat a vždy se dotazují jako požadavek na jednu buňku. |
| Jsou sestavy stylů nadměrně konstruované? | Při tvorbě nových stylů myslete na jednoduchost a pokud je to možné, odolejte nutkání přidávat obsah do stávajících stylů. Počet stylů zvyšuje velikost sestavy. |
| Zadali jste počáteční výběry entit sestavy? | .reports se načítají rychleji, pokud je uložena poslední entita, kterou uživatel vizualizoval. Pokud se sestava načítá například na úrovni All Entity, je třeba načíst mnohem více dat a načtení sestavy trvá déle. |
| Používáte bezstavové ovládací prvky, jako jsou objekty Lookup, spíše než ovládací prvky založené na zobrazeních seznamu? | Ovládací prvky založené na zobrazeních seznamu, jako jsou například výběrová pole, načítají seznamy prvků při načítání sestavy. Bezstavové ovládací prvky nezískávají seznamy prvků, což urychluje jejich načítání. |
| Testujete důkladně své zprávy? | Můžete sestavit sestavy, které spojují řetězce a odvozují ID prvků, ale pokud odešlete požadavek na server OLAP pro neexistující prvky, riskujete chyby a časové výpadky. Testování by mělo vždy zohledňovat nastavení zabezpečení koncového uživatele. |
| Filtry seznamu | Některé typy filtrů jsou pomalejší než jiné, například atributové filtry jsou pomalejší než hodnotové filtry. Filtry jsou obecně pomalejší než výběry struktury. Vyhněte se velkým datovým oblastem ve filtrech. Čím více elementů vyberete pro jednu dimenzi, tím pomalejší bude filtr. |
| Globální akce | Zvažte použití globálních akcí, abyste ušetřili čas potřebný k výpočtu jednotlivých sestav. Globální akce se spouštějí během přihlášení uživatele, po vytvoření modelu úložiště a před vytvořením jakéhokoli motoru. Hodnoty globálních proměnných jsou nastaveny ještě před zahájením načítání sestavy. |
| Proměnná reportu | Vyhněte se velkým řetězcům v proměnných. |
Zpětné, environmentální a interpersonální aspekty
U úspěšného projektu existuje zpětná vazba mezi tvůrci sestav a autory datových kostek. Špatný design datové kostky je pravděpodobně největším faktorem špatného výkonu. V této tabulce jsou uvedeny důležité faktory, které je třeba vzít v úvahu:
| Úvaha | Popis |
|---|---|
| Psaní a testování zpráv s reálným souborem dat | Sestavy, jejichž dimenze obsahují až 30 prvků a datové kostky několik stovek datových bodů, mohou fungovat dobře, ale kvůli velkému souboru dat je obtížné je udržovat. Je důležité provádět testy s reálnými soubory dat. |
| Psaní správných pravidel OLAP. Příklad špatně napsaného pravidla: [Výnosy] = [Cena] * [Množství] nebo [Účet 1] = [Účet2} + [Účet3] + [Účet4] | Seznamte se s osvědčenými postupy pro psaní pravidel OLAP. Pokyny naleznete v online dokumentaci. |
| Špatně strukturované dimenze | Uvažujme dimenzi produktu s vrcholovým prvkem Všechny produkty, ale s 10 000 podřízenými prvky. V určitém okamžiku uživatel pravděpodobně vyvolá požadavek na server OLAP, který vyžaduje načtení a případné zobrazení všech prvků. Díky mezivrstvám je sestava založená na hierarchii výkonnější. |
| Vysoký počet uživatelů | Vyhněte se změnám dimenzí během pracovní doby, kdy je online nejvíce uživatelů. |
| Chybějící nadřazené prvky v dimenzích, například prvek rok celkem | Sestava, která načítá denní data ve skrytých sloupcích, aby je sečetla a zobrazila jako roční součet, je mnohem pomalejší než sestava, kde se součet počítá v databázi OLAP. |
| Zneužití atributů | Atributy lze libovolně definovat a používat k filtrování sestav, ale filtrované sestavy mají horší výkon než hierarchie, která seskupuje prvky podle potenciálních hodnot atributů. |
| Zajistěte, aby měl OLAP server dostatek paměti RAM | OLAP je databáze v paměti. Špatně napsané dotazy mohou spotřebovat značné množství paměti RAM. Pokud váš OLAP server stránkuje, můžete očekávat nízký výkon. |
| Nevkládejte transakční data do datových kostek | Infor OLAP je optimalizován pro reporting na úrovni bilance. Můžete sestavit sestavu, která není výkonná, aniž by vám v tom aplikace bránila. Můžete například vytvořit podrobnou datovou kostku nad řádkovým souborem objednávek, ale pravděpodobně nebude výkonná. |
| Psaní špatné zprávy jako krátkodobé řešení | Odolejte tlaku projektu, abyste udělali něco, co vytvoří nevýkonnou zprávu. Své obavy vyjádřete písemně a navrhněte alternativy. |
| Neukládejte do datové kostky nuly | Nula je číslo, které musí být uloženo v paměti OLAP a vyhodnoceno při výpočtech pravidel, zatímco alternativa nuly nikoli. Můžete vytvořit proces Application Engine, který dokáže nahradit nuly v datové kostce nulou. |
| Nejlepší místo pro výpočty | To závisí na více faktorech, včetně toho, jak často jsou vypočtené hodnoty vyžadovány. Toto jsou příklady možností, kde provádět výpočty, seřazené podle preferencí:
|
| Nastavení konkrétních výchozích elementů | Pokud pro hierarchické dimenze nevybereš konkrétní výchozí prvky, bude jako výchozí vybrán nejvyšší prvek. To vyžaduje více času na vynulování výchozích elementů. V současné době jsou výchozí prvky nastaveny v rozšířených vlastnostech dimenze. |
| Použití rozhraní XML je pomalejší než komunikace prostřednictvím integrovaného rozhraní ve verzi 11 | Pro urychlení komunikace doporučujeme, abyste hodnoty nečetli pomocí jednobuněčných požadavků, ale vložili je do jednoho nebo několika požadavků na OLAP. To lze provést pomocí požadavku na čtení datové kostky přidáním více značek CellCoordinate. |
| Použití stránkování na straně serveru k vytvoření sestavy pro dotazování pouze na viditelné hodnoty | Stránkování ve stránkách hyperbloků je na straně klienta. Ze serveru se vrátí všechny buňky, ale vykreslí se pouze stránka.
V seznamech OLAP použijte funkci subset pro stránkování na straně serveru. V relačních seznamech použijte pokročilé metody v dotazu pro vytvoření podmnožin. |
| Filtrování dotazů, abyste se ujistili, že se nedotazujete na všechny prvky z dimenze | Pomocí potlačení nulových hodnot můžete zobrazit pouze vyplněné buňky, zobrazit všechny elementy pod určitým nadřazeným prvkem namísto celé dimenze. Snížení počáteční úrovně rozbalení v řezech a seznamech. |
| Vyhněte se vkládání velkého množství dimenzí do osy | Optimální počet je tři dimenze na osu řádků a jedna dimenze na osu sloupců. |