Architektura

BNS řešení je postavené na technologii Microsoft a založené na architektuře klient-server. Komunikace mezi klientem a serverem zajišťuje počítačová síť s využitím standardního protokolu TCP/IP.

Architektura BNS se skládá primárně ze tří důležitých částí:

1. databázová vrstva (MS SQL Server)

2. relační instance BNSI (BNS Integration),

3. analytická instance BNS (analytické služby v multidimenzionálním režimu)

Databázová vrstva se skládá z několika databází. Z hlediska zdrojových dat je důležitá DB BNSI-XXX. Sem se integrují veškerá data, která nevznikají v BNS. Vyskytují se zde tabulky členěné do několika skupin:

Názvy tabulek v BNS

Předpony názvů tabulek v datovém skladu jsou zpravidla následující:

·       a (např. [aVARCFG]) – (administrator) – konfigurační tabulky datového skladu

o   typicky se do těchto tabulek při rutinním běhu již nijak zásadně nezasahuje

o   aBNSICFG – zde se specifikují údaje typu, přes jaký  smtp server komunikuje notifikační e-mail, který se posílá z aktualizací, a dalším parametrem se určuje, na jaké uživatele je onen e-mail odesílán.

o   aBNSIDBIDs – zde se vyplňují názvy databází ve smyslu entit (třípísmenná zkratka názvu společnosti)

o   aBNSIMODULs – v kombinaci s DB_ID se definují i jednotlivé moduly

o aBNSICUBEs – v kombinaci DB_ID a MODUL_ID jsou zde vypsány datové (faktové) tabulky. Jedná se o tzv. aktualizovatelné jednotky, tedy jsou to takové objekty, na které se váže aktualizace (ať už se jedná o celé fyzické tabulky 1:1, či fiktivní, kdy je např. jedna fyzická tabulka rozdělena na několik aktualizovatelných jednotek). V této tabulce je tedy definováno, které tabulky a v jakém rozsahu budou aktualizovány. Mimo identifikaci DB a modulu se zde rovněž nastavuje tzv. první období (období, od kterého jsou v tabulce k dispozici data), a periodicita dat (většinou měsíční, může být i roční nebo jiné).

o aBNSIPROCLIST – uvádí seznam existujících procedur. Zároveň, pokud je to procedura související s aktualizovatelnou jednotkou (faktová tabulka či její část), je zde i vazba na onu jednotku.

o   aBNSIPROCRELATIONs – obsahuje vazby mezi jednotlivými procedurami. Tedy je-li nutné spouštět procedury v určitém pořadí, tj. před nějakou procedurou (např. aktualizace faktové tabulky) spustit jinou (např. aktualizace provázané dimenzionální tabulky), je tato procedura uvedena jako záznam v této tabulce, přičemž nutná předchozí procedura je vyplněna ve sloupci PARENT_PROC_ID. Procedura se může v této tabulce vyskytovat jako záznam víckrát, a to právě tolikrát, kolik procedur je nutné spustit předem (PROC_ID záznamů je stejné, liší se PARENT_PROC_ID). Upozornění: Tyto vazby nastavuje dodavatel softwaru a správce BNS do nich nijak nezasahuje.

o   aBNSIUPDATELOG – obsahuje kompletně celou historii provedených aktualizací (spuštěných prcedut. Každá procedura plnící data datového skladu (koresponduje s konkrétní tabulkou dat. skladu), která byla spuštěna, je zde „zalogována“ a má svůj vlastní identifikátor (LOG_ID). Lze zde zjistit, čeho se konkrétní aktualizace týkala(DB_ID, PROC_ID), kdy byla spuštěna (START_ID) a kdy skončila (END_ID) včetně celkové doby běhu (RUNTIME), zda byla spuštěna automaticky v rámci nějaké skupiny procedur nebo ručně (DTS_ID), zda skončila úspěchem nebo chybou a případně jakou (END_STATUS, ERROR_DESC), jaký objem dat se načetl z datového zdroje do tempové tabulky (selected_rows), kolik bylo případně smazáno ostrých záznamů (DELETED_ROWS) či naopak vloženo (INSERTED_ROWS) nebo změněno (UPDATED_ROWS) (např. změna popisky), jak se nazývá zdroj dat (DATA_BULK), jaké periody byly aktualizovány (PERIOD) (u číselníkové tabulky se uvádí stav ke konkrétnímu okamžiku), uživatel pod kterým aktualizace běžela (USER_ID).

§  Každá celková aktualizace (pravidelná noční) je zahájena uvozujícím logem s názvem ***START FULL BNSI Update***. Je navázána na proceduru BNSIfullUPDATEStart. Tato procedura prochází nastavení ve všech konfiguračních tabulkách pro aktualizaci, a dle toho spouští danou aktualizaci v definovaném rozsahu.

§  U číselníkových (dimenzionálních) tabulek dochází k výmazu řádků pouze ve specifických případech, kdy je aktualizace přírůstková nahrazena přepisem, např. struktura výkazu. U faktových tabulek je vždy vymazáno celé aktualizované období a načtená data jsou vložena znovu (hodnota updated_rows bývá tudíž  0).

§  Někdy se může lišit počet načtených řádků do temp tabulky a počet uložených řádků do ostré tabulky. Způsobeno to může být např. když ze zdroje proudí data ve větším detailu, avšak do datového skladu BNSI jsou již ukládána v nějaké zesumované úrovni. Jiným důvodem může být náhrada u více prvků za jeden totalX, čímž dojde k sumaci dat těchto prvků.

§  Po aktualizaci všech aktualizovatelných jednotek v rámci BNSI ještě většinou dochází ke spuštení aktualizace objektů (převážně procedur) v DB BNSO (uvozeno *START BNSO Update*). Seznam těchto procedur a jejich pořadí se nastavuje v tabulce aBNSOPROCLIST (pozor, nachází se v tabulkách DB BNSO, nikoliv BNSI)

§  Na konci aktualizace relačního světa se většinou provádí i zálohy (položka tabulky backup DB)

§  Poté již následuje aktualizace analytické instance – procesování dimenzí a kostek. Procesování těchto objektů předchází ještě dvě procedury, které automaticky doplňují seznamy a vazby dimenzí a kostek (tabulky aBNSIOBJLIST a aBNSIOBJRELATIONS), pokud jsou vytvořeny nové. V logu procesu dimenzí a kostek již nehrají roli sloupce s počty nalezených (SELECTED), vymazaných (DELETED), vložených (INSERTED) a změněných (UPDATED) řádků – zde je vždy hodnota 0. Každá dimenze i kostka se aktualizuje jako celek. Pouze, když je nad kostkou vytvořena Partition, tak tam lze samozřejmě rozsah aktualizovaných dat omezit.

·       Standardně se aktualizuje formou ProcessFull. Znamená to, že OLAPová technologie začne vytvářet daný objekt úplně znovu mimo aktuální ostrou verzi. Pokud je tvorba (aktualizace) úspěšná, dojde v metadatech k náhradě verze na tu nově vytvořenou. Nová verze 100% odpovídá stavu dat v datovém skladu.

     Tato náhrada verze také způsobí to, že jedná-li se o aktualizaci dimenze, tak všechny kostky s ní provázané zůstanou nedostupné (neaktualizové), dokud samy nebudou zprocesovány. Problém tedy nastává, selže-li poté proces samotné kostky. Pokud selže proces dimenze, zůstává dimenze v posledním úspěšně auktualizovaném stavu, což při neměnnosti podoby dimenze nezpůsobuje žádné omezení.

Pokud selže u dimenze i ProcessUpdate, vidí uživatelé v BNS poslední úspěšně aktualizovanou verzi dimenze. Process Update nezpůsobuje znepřístupnění kostky a neodpojuje připojené uživatele.

·   Spuštění Process Full způsobí, že data budou dočasně nepřístupná a připojení uživatelé budou odpojeni. Pozor tedy na spouštění takového procesu např. v době, kdy uživatelé pracují se zápisovými funkcemi na panelech, či momentálně používají panely k prezentaci.

·    Pokud selže ProcessFull dojde ještě k pokusu o jiný typ aktualizace – ProcessUpdate (v případě dimenzí). Tento typ nedokáže odstranit prvky, které již na zdroji nejsou. Dokáže ovšem přidávat nové prvky do dimenze či měnit jejich zařazení do rodiče (pokud není vazba v dimenzi nastavena jako neměnná). Nekontroluje tedy úplně nějaké nekonzistence v datech např. duplicity. V případě kostky je při neúspěchu plného procesu pokračováno s typem Process Data, v rámci něhož je aktualizace rozdělena na dílčí části. Zprvu se jedná do oddělení aktualizací jednotlivých measure groups. Pokud i to selže, je aktualizace rozdělena ještě i dle Partitions (jsou-li nastaveny). Tedy v případě, kdy ProcessFull neproběhl z důvodu timeoutu (vypršení časového limitu pro aktualizaci), tak ProcessUpdate by měl zafungovat bez problémů. Pokud je ovšem zásadní chyba v datech, jakýkoliv typ procesu skončí chybou.

Measure group je sada ukazatelů, která má stejnou dimenzionalitu či obdobný způsob načítání a aktualizace. Partitions jsou

Při spouštení aktualizace přes den z BNS se používá typ Process Update, resp. Proces Data z toho důvodu, aby v nedošlo k znepřístupnění dat kostek během dne a zároveň aby nedošlo k odpojení připojených uživatelů.

§  V posledním kroku celkové aktualizace se tvoří záloha i pro OLAP databázi (backup OLAP).

§  Konec aktualizace je označen řádkem „***END FULL BNSI Update***

o   aBNSIERRLOG – obsahuje výpis validačních kontrol. Nalezneme zde informace, v rámci které aktualizace (LOG_ID) došlo k náhradě jakého prvku (většinou na totalX) z důvodu neexistence tohoto prvku v příslušné číselníkové tabulce.

o   aBNSIUPDATE – zde nalezneme informaci, kdy a jakým způsobem (automaticky/ručně) byla naposledy aktualizována každá jedna perioda každé jedné datové tabulky (resp. aktualizovatelné jednotky). Obsahuje i údaj o času běhu a LOG_ID aktualizační procedury. Je navázána na ostatní konfigurační tabulky a pokud daná kombinace tabulky a periody má procházet hromadnou automatickou aktualizací, přepíše se automaticky hodnota ve sloupci RUN na 1. Při spouštění manuální aktualizace je možné tuto hodnotu u potřebné kombinace přepsat i ručně.

o   aBNSIUPDATEDEF – v jakém rozsahu se tabulky aktualizují definujeme právě zde. Každé aktualizovatelné jednotce zde můžeme přiřadit od kterého data aktualizace probíhá (PER_FROM), kolik period se má aktualizovat (PER_COUNT) a která je poslední aktualizovaná (PER_TO) (většinou „pa“ jako perioda aktuální – viz tabulka aBNSIPERDEF níže). Logicky tedy stačí vyplnit pouze dvě z těchto tří sloupců – kombinaci počáteční období a počet období, nebo počáteční a konečné období, nebo počet období a konečné období. Pokud jsou vyplněny všechny tři, pak je hodnota v počátečním období ignorována. V dalších sloupcích STARTx lze poté ještě blíže specifikovat, které dny bude aktualizace spouštěna – buď rovnou konkrétní data v měsíci (hodnoty 1-31), nebo využít opět zkratky z aBNSIPERDEF, kde např. ude znamená každý den, udl pak poslední den v měsíci, ud1 každé pondělí apod. Zároveň lze celé toto nastavení aktualizovatelné jednotky dočasně zneaktivnit – ve sloupci RUN se nahradí hodnota 1 za hodnotu 0.

o   aBNSIPERDEF – uvádí pojmenování typů období pro použití v konfiguračních tabulkách. Kromě pa tedy používáme např. pp pro předchozí období (používá se např. pro data v lidských zdrojích, kdy nedává smysl, sledovat tato data průběžně – jsou zpracovávány až v následujícím měsíci). Dále zde jsou kódy začínající na ud_ indikující dny, kdy se aktualizační procedura pouští)

o   aBNSIUPDATE1TIME – je obdobou tabulku aBNSIUPDATEDEF, avšak slouží pro jednorázové aktualizace. Má navíc sloupec pro rok (YEAR_ID).

o   aBNSOBJLIST – obsahuje seznam objektů v OLAPu (dimenze a kostky). Seznam se aktualizuje automaticky pomocí procedury. Pomocí sloupce bUpdate lze aktivovat či zrušit automatickou aktualizaci daného objektu (hodnota 1 nebo 0). Zároveň ve sloupci SRC vidíme, které view/tabulka je zdrojem pro danou dimenzi/kostku

o   aBNSOBJRELATIONS – obdobně jako u aBNSIPROCRELATIONS se zde vyskytují vazby mezi kostkami a dimenzemi. Stejně jako aBNSOBJLIST je však plněna automaticky pomocí pomocné procedury.

o   aBNSPROCESSDEF – pomocí PROCESS_ID lze nastavovat jakési aktualizační balíčky. Do balíčku se dává seznam kostek a pořadí, v jakém mají být procesovány. Pro pravidelnou noční aktualizaci se standardně používá balíček s ID 1, pro aktualizace spouštěné z BNS označení 201. Balíčků je samozřejmě možné vytvářet více dle potřeby. V související aktualizační proceduře poté nastavujeme, který balíček se bude spouštět.

·       d (např. [dACC]) – (dimension) – číselníky a struktury pro aktualizaci dimenzí v BNS

o   snaha ukládat normalizovaně, tj. v číselníku základních prvků dimenze nalezneme jejich kód, název a kód nadřazené (agregované) úrovně. Avšak popisky nadřazené úrovně (případně její další atributy) jsou definovány v samostatné tabulce.

o   Ve všech číselníkových tabulkách podléhajících aktualizacím nalezneme i sloupec INSERTED využívající datový typ datetime, který nese informaci, kdy se daná položka objevila v datovém skladu BNSI (který den a čas poprvé prošla aktualizací). To napomáhá např. zjistit příčinu chyby při aktualizaci, či omezit zobrazované položky číselníku v BNS podle data jejich vzniku.

o   Ve většině případů probíhá načítání přírůstkově, tudíž ze zdroje stačí dodávat nové záznamy a záznamy, u kterých se změnil některý z atributů. Záznamy v číselníkové tabulce zůstávají i historicky (pomineme-li mazání ručním zásahem).

o   Existují výjimky (např. číselník struktury výkazu), kdy je v tabulce uchováván pouze aktuální stav.

·     r (např. [rACC_CONV]) – (relation) – pomocné vazební tabulky pro relace mezi dvěma (d) tabulkami (platí vazby m:n). Typ aktualizace může výt i přírůstek i přepis, dle charakteru a účelu konkrétního vazebníku

·       c (např. [cFINAL]) – (cube) – obsahují data relačně svázaná s (d) tabulkami pomocí identifikátorů prvků (opět normalizovaný způsob uložení). Slouží pro uložení dat multidimenzionálních OLAP tabulek (tzv. “kostek”)

o   každá datová tabulka má svou periodicitu (typicky měsíc) – nastavuje se v aBNSICUBEs

o   aktualizace probíhá tak, že data jsou ze zdroje načtena do pomocné tempové (dočasné) tabulky. Zde jsou provedeny validační kontroly

o   V případě, kdy se v datové tabulce vyskytne identifikátor, který neexistuje v příslušném číselníku, je tato skutečnost zaznamenána do tabulky aBNSIERRLOG, viz její popis výše. Neznámý identifikátor je nahrazen kódem totalX, tzv. prvek neurčen.

·       u (např. [uACC]) – (user) – uživatelské, které nejsou standardně zahrnuty v BNSI

·       ur (např. [urACC_CONV]) – (user realtions) – uživatelské vazební, které nejsou standardně zahrnuty v BNSI

·       e (např. [eFINAL]) – (error) – chybové tabulky. Zaznamenávají chybové stavy dat a číselníků

·       q (např. [qFINAL]) – (query) – pohledy (views), které zajišťují správný dotaz nad více tabulkami pro vstup do BNS

Procedury – Pokud jakákoliv tabulka podléhá aktualizaci, souvisí s ní typicky jedna procedura. Aktualizace lze tedy spouštět i jednotlivě pro každou zdrojovou tabulku. Nebo lze využít procedury BNSfullUPDATEStart pro spuštění celkové aktualizace. V rámci této procedury se nejprve spouští procedura BNSIUPDATEStart, která se stará o aktualizaci relačního světa. Jednotlivé dílčí procedury jsou provázány pomocí dvou konfiguračních tabulek aBNSIPROCLIST, kde je uveden seznam všech procedur, a aBNSIPROCRELATIONs, která zabezpečuje případné vazby mezi nimi.

V ideálním případě se plněná tabulka a ji plnící procedura jmenují stejně. Nicméně procedury mají defaultně delší předpony v názvech, a to ve tvaru: dbo.bnsi_XXX_NazevProcedury. Za XXX se ukrývá konkrétní DB_ID, a samotný název procedury tedy často bývá shodný s názvem plněné tabulky.

Mimo zmíněné procedury existují i další. Např. BNSIUPDATEStartFromBNS je procedura určená pro vyvolávání přímo z aplikace BNS. Má k dispozici specifický seznam aktualizovatelných datových tabulek i seznam OLAPových kostek (z analytických služeb), které mají být aktualizovány (procesovány). Ignoruje tedy to globální nastavení v konfiguračních tabulkách aktualizace.

Zdrojem pro notifikační e-maily jsou tabulky aBNSIUPDATELOG a aBNSIERRLOG