obousmˇernˇe mapovat na adres´aˇrovou strukturu pˇri extrakci specifikac´ı model˚u a report˚u, aby byl pˇr´ısluˇsn´y odkazovan´y soubor nalezen.
Pro ˇc´asteˇcnou anal´yzu datov´ych tok˚u v Cognos existuje n´astroj Cognos Data Lineage, kter´y je integrovan´y v Cognos Analytics. Je tak´e znaˇcnˇe ne-aktu´aln´ı a nezn´a nov´e objekty pˇredstaven´e v Cognos Analytics 11. Nav´ıc neum´ı propojit analytick´e modely s datov´ymi zdroji. Pokr´yv´a pouze ˇc´asti podporo-van´ych objekt˚u a ˇrada tok˚u je d´ıky tomu ztracena. Uz jen prototyp konektoru pro Manta Flow pokryje vˇetˇs´ı rozsah datov´ych tok˚u v Cognos.
3.5.1 Souvisej´ıc´ı n´astroje Cognos m´a pomˇernˇe velk´y
”ekosyst´em“ podp˚urn´ych n´astroj˚u a to zejm´ena na analytick´e vrstvˇe. ˇRada z nich produkuje specifick´e objekty, kter´e se r˚uznˇe mohou ´uˇcastnit datov´ych tok˚u. Tyto n´astroje s jejich produkty pokr´yv´a n´ a-sleduj´ıc´ı v´yˇcet.
• Cognos Analytics – hlavn´ı webov´a aplikace bˇeˇz´ıc´ı na Cognos Analy-tics serveru. Poskytuje grafick´e uˇzivatelsk´e rozhran´ı pro tvorbu r˚uzn´ych
druh˚u dokument˚u. Je v nˇem integrov´an reporting, dashboarding a data modeling.
– Reporting– komplexn´ı n´astroj pro tvorbu report˚u. D˚uraz je kla-den na volnost, flexibilitu, tabulky a pod´an´ı ˇsirok´e sady informac´ı.
Vych´az´ı z Report studia obsaˇzen´eho v Cognos BI 10. Produktem jsou reporty s XML specifikacemi.
– Dashboarding – intuitivn´ı rozhran´ı pro rychlou tvorbu dashbo-ard˚u. Myˇslenkou je uˇsetˇrit uˇzivateli ˇcas str´aven´y nepodstatn´ymi designov´ymi rozhodnut´ımi, proto je ˇrada styl˚u a konfigurace pˇ red-pˇripravena. Produktem jeDashboard, jehoˇz specifikaci lze z Content store z´ıskat ve form´atu JSON.
– Data modeling – novinka v Cognos Analytics. Poskytuj´ı dalˇs´ı
´
uroveˇn datov´e abstrakce a umoˇzˇnuj´ı modelovat zdroje dat sloˇzen´e z datab´az´ı i soubor˚u z´aroveˇn. Dok´aˇz´ı tak´e seskupit v´ıce model˚u do jednoho modulu a obch´az´ı tak dˇr´ıvˇejˇs´ı omezen´ı, kdy reporty mohly m´ıt jen 1 datov´y zdroj.
• Framework manager – starˇs´ı, ale st´ale ˇsiroce vyuˇz´ıvan´y a vyv´ıjen´y analytick´y modelovac´ı n´astroj. Podporuje tabul´arn´ı i multidimenzion´aln´ı modely a simuluje tak OLAP funkcionalitu. Jeho produktem jsoumodely se specifikacemi form´atu XML.
• Transformer – p˚uvodn´ı n´astroj pro tvorbu OLAP kostek a analytick´e pl´anov´an´ı nad nimi. Uˇz nen´ı vyv´ıjen a v budoucnu bude nejsp´ıˇs nahra-zen n´astrojem Dynamic cube designer. Hlavn´ım produktem jsouPower cubes, kter´e fyzicky kop´ıruj´ı data do jin´e lokality na disku. N´astroj m´a ˇsirokou ˇradu funkc´ı, ale kapacita jednotliv´ych kostek je omezena na 2 Gb.[42]
• Dynamic cube designer– nejnovˇejˇs´ı Cognos n´astroj pro tvorbu OLAP kostek, zde oznaˇcen´ychDynamic cubes. Do budoucna maj´ı plnˇe nahra-dit Power Cubes. Jsou zaloˇzeny na pokroˇcil´em cachovac´ım syst´emu, kter´y data pouze modeluje dle datov´eho zdroje, ale fyzicky je nikam nepˇresouv´a. Zaruˇcuj´ı v´ybornou odezvu i pˇri velk´em objemu dat, ale jako pomˇernˇe nov´y produkt jeˇstˇe nepokr´yvaj´ı vˇsechny funkce Transformeru.
3.5.2 Datovˇe relevantn´ı objekty Cognos
V t´eto sekci jsou rozebr´any objekty, kter´e lze nal´ezt ve specifikac´ıch report˚u a model˚u Framework Manageru a pˇr´ıpadn´e z´avisl´e objekty, nach´azej´ıc´ı se v Con-tent store. Nen´ı c´ılem prototypu pokr´yt toky ve vˇsech n´astroj´ıch a objektech.
Vynech´any tak napˇr´ıklad budou Dashboardy a z´avisl´e objekty a v Cognos Analytics novˇe pˇredstaven´y Data module. OLAP anal´yza bude omezena jen
3.5. IBM Cognos na dimenzion´alnˇe modelovan´y FM Model, proto aniDynamic cubes a Power cubes nebudou rozebr´any.
Reportpˇredstavuje v´ysledn´y dokument. Kaˇzd´y objekt tohoto typu m´a svou vlastn´ı specifikaci, kterou lze extrahovat. V t´eto specifikaci je uveden odkaz na zdroj dat. Specifikace reportu tak´e obsahuje ˇradu datovˇe zaj´ı-mav´ych objekt˚u, kter´e budou pops´any d´ale.
Layoutreprezentuje zvolen´e rozloˇzen´ı str´anek. V r´amci reportu m˚uˇze b´yt de-finov´ano v´ıce layout˚u, narozd´ıl od OBIEE je ale viditeln´y vˇzdy jen jeden zvolen´y. Tento objekt tedy slouˇz´ı napˇr´ıklad k pˇrep´ın´an´ı jazyku prezen-tace nebo volbˇe jin´eho rozvrˇzen´ı str´anek apod. Je definov´an ve specifikaci reportu.
Page (str´anka) se nach´az´ı uvnitˇr layoutu, v r´amci kter´eho je jej´ı jm´eno unik´atn´ı. Obsahuje prvky urˇcuj´ıc´ı jej´ı rozvrˇzen´ı a hlavnˇe pak datov´e vizualizace a ovl´adac´ı prvky, kter´e slouˇz´ı k interakci s reportem.
Controlje umˇele zaveden´y n´azev pro interaktivn´ı prvky, kter´e mˇen´ı podobu reportu. Jedn´a se o r˚uzn´e formy z´aloˇzek, dropdown˚u28, tlaˇc´ıtek atp.
Nˇekter´e z tˇechto prvk˚u mohou vyuˇz´ıvat dynamick´a data, proto jsou pro anal´yzu datov´ych tok˚u tak´e relevantn´ı.
Visualizationpˇredstavuje r˚uzn´e formy graf˚u, tabulek a vizualizac´ı pro zob-razen´ı dat. Je hodnˇe typ˚u tˇechto objekt˚u, kter´e mohou m´ıt velmi r˚uznou strukturu. Spoleˇcn´ym rysem je zp˚usob, jak´ym referencuj´ı data. Ve vˇsech tˇechto vizualizac´ıch se XML atributemrefDataodkazuje na uˇzit´yQuery item.
Queryje definov´ano tak´e jeˇstˇe ve specifikaci reportu, ale uˇz je souˇc´ast´ı sp´ıˇse logick´e vrstvy, neˇz prezentaˇcn´ı. Slouˇz´ı k v´ybˇeru dat z datov´eho zdroje, pˇr´ıpadnˇe i k prov´adˇen´ı dalˇs´ıch kalkulac´ı a filtrac´ı. Query m˚uˇze pˇr´ımo obsahovat SQL dotazy do datab´az´ı ve strukturovan´e formˇe, ˇcastˇeji je ale vyuˇz´ıv´an novˇejˇs´ı pˇr´ıstup, kdy na analytick´e vrstvˇe mezi Query a datab´az´ı je jeˇstˇe tabul´arn´ı model nebo OLAP kostka. V tom pˇr´ıpadˇe je generov´an dotaz v MDX syntaxi podle obsaˇzen´ychQuery item˚u.
Query item (report)pˇredstavuje prvky v´ysledku dotazu reprezentovan´eho objektem Query. Na Query itemy se odkazuje z vizualizac´ı a interak-tivn´ıch Control objekt˚u uvnitˇr specifikac´ı report˚u. Query itemy mohou samy o sobˇe odkazovat na jin´e objekty tohoto typu a to vˇcetnˇe tˇech, kter´e jsou souˇc´ast´ı jin´ychQuery objekt˚u.
28Dropdown je oznaˇcen´ı pro prvek uˇzivatelsk´eho rozhran´ı, kter´y vyb´ır´a jednu z moˇznost´ı v nab´ıdce.
Model je oznaˇcen´ı pro produkt n´astroje Framework Manager (FM model).
Modeluj´ı se v nˇem tabul´arn´ı i multidimenzion´aln´ı sch´emata. V urˇcit´em kontextu tedy m˚uˇze pˇredstavovat OLAP kostku. Je jedn´ım z moˇzn´ych zdroj˚u dat pro reporty a dashboardy.
Namespace m´a podobnou funkci jako adres´aˇre v diskov´ych struktur´ach – funguje jako kontejner pro nez´avisl´a sch´emata modelu. Jednotliv´e na-mespace b´yvaj´ı modelov´any bud’ tabul´arnˇe nebo dimenzion´alnˇe. Mohou tak´e obsahovat tzv.Shortcuts, coˇz jsou strukturovan´e reference do jin´ych ˇc´ast´ı modelu.
Calculationje objekt vypoˇcten´y dle jin´ych prvk˚u v rodiˇcovsk´emNamespace.
Query subjectje souˇc´ast´ı tabul´arn´ıchNamespace a obsahuje SQL dotaz do datab´aze. V pˇr´ıpadˇe, ˇze SQL dotaz neobsahuje, odkazuje vˇzdy na jin´y Query subject, kter´y tuto podm´ınku uˇz splˇnuje.
Query item (model)se poj´ı ke sloupci datab´azov´e tabulky, nebo odkazuje na jin´yQuery item. Zaj´ımav´e je, ˇze tento prvek, respektive XML element s t´ımto n´azvem, se zde pouˇz´ıv´a i jako potomek dimenz´ı. Napˇr´ıklad SSRS pro tento v´yznam pouˇz´ıv´a pojmenov´an´ıAttribute.
Dimensionje potomkem multidimenzion´alnˇe modelovan´ehoNamespace. Po-dobnˇe jako Query subject m˚uˇze obsahovat SQL dotaz nebo referenci na jinou dimenzi, kter´a ho obsahuje.
Hierarchy, Level zde maj´ı v´yznam konzistentn´ı s jejich definic´ı v OLAP kostce 3.1.1. Spoleˇcnˇe s dimenz´ı se nach´az´ı ve specifikaci FM modelu.
DataSource oznaˇcuje datov´e zdroje, kter´e jsou pops´any v r´amci samo-statn´ych extrahovan´ych soubor˚u. Tyto soubory obsahuj´ı informace po-tˇrebn´e k pˇripojen´ı k datov´emu zdroji, fyzickou adresu na disku apod.
3.6 Shrnut´ı
V t´eto sekci shrnu objeven´e spoleˇcn´e rysy analyzovan´ych reportingov´ych n´ a-stroj˚u, kter´e budou z´akladem pro nalezen´ı spoleˇcn´e reprezentace objekt˚u v tˇ ech-to n´astroj´ıch.
I kdyˇz nebyl tento objekt vˇzdy explicitnˇe uveden, vyskytuje se Server reprezentuj´ıc´ı ´uloˇziˇstˇe report˚u v kaˇzd´em z n´astroj˚u kromˇe Excelu, kter´y si vystaˇc´ı s jednotliv´ymi reporty uloˇzen´ymi v libovoln´e adres´aˇrov´e struktuˇre na disku. Nen´ı pˇrekvapen´ım, ˇze z´asadn´ım pojmem je zm´ınˇen´yReport. V Excelu lze za report povaˇzovatWorkBook obsaˇzen´y v samostatn´em XLS dokumentu.
Prvky reportu jsou vizualizace a r˚uzn´e filtraˇcn´ı nebo kontroln´ı prvky, kter´e interaktivnˇe s reporty pracuj´ı. Tyto prvky byly uˇz v anal´yze opakovanˇe
3.6. Shrnut´ı naz´yv´any jakoReport itemy. Spoleˇcn´ym znakem Report item˚u bylo, ˇze obsa-huj´ı odkazy na data. V´ıcekr´at se objevil n´azev Data series pro datov´e ˇrady samostatn´ych hodnot. Tyto hodnoty jsou ale napˇr´ıˇc n´astroji pojmenov´any r˚uznˇe a bude pro nˇe potˇreba ve spoleˇcn´e reprezentaci zav´est jednotn´e pojme-nov´an´ı.
V Cognos a OBIEE se objevila rozloˇzen´ı report˚u nazvan´a jako Layout, kter´a se dˇelil´a na obsaˇzen´e str´anky (Page). V Excelu lze koncept str´anky tak´e nal´ezt pod oznaˇcen´ım Sheet, neboli list. Pouze reporty SSRS jsou jed-nostr´ankov´e a tak danou str´anku ani explicitnˇe nezmiˇnuj´ı.
V ´uvodu kapitoly byly pˇredstaveny OLAP kostky, kter´e mohou b´yt uˇzity jako zdroje dat ve vˇsech analyzovan´ych n´astroj´ıch. Na dimenzion´aln´ı model jsem narazil i v pr˚ubˇehu anal´yzy pro Cognos a nezjistil ˇz´adn´e vˇetˇs´ı odliˇsnosti.
Pˇri navrˇzen´ı spoleˇcn´e reprezentace se tedy d´a vych´azet z objekt˚u v OLAP kostk´ach popsan´ych v sekci 3.1.1.
Jako protip´ol dimenzion´aln´ıho modelu byly objeveny napˇr´ıˇc n´astroji r˚uzn´e podoby tabul´arn´ıch model˚u. Mezi spoleˇcn´e objekty nalezen´e v tˇechto modelech patˇr´ı objekty symbolizuj´ıc´ı potenci´alnˇe propojen´e tabulky, kter´e se skl´adaj´ı z poloˇzek, kter´e jsou bl´ızk´e sloupc˚um datab´azov´ych tabulek. Pojmenovan´e byly r˚uznˇe a v n´avrhu spoleˇcn´e reprezentace se pˇriklon´ım k oznaˇcen´ıTable a Column, coˇz se zd´a b´yt nejpˇresnˇejˇs´ım oznaˇcen´ım v´yznamu, pˇrestoˇze se nejedn´a o fyzickou (datab´azovou) vrstvu. V modelech se tak´e v´ıcekr´at vyskytly r˚uzn´e kalkulace, vypoˇcten´e a agregovan´e hodnoty.
Samotn´e reporty si v SSRS a Cognos vyhradily jeˇstˇe jednu modelovac´ı vrstvu, kter´a byla souˇc´ast´ı reportu. Objekty v n´ı opˇet pˇripom´ınaly tabulky.
Na stranˇe SSRS to bylyData sety aFieldy, u Cognosu stejn´a funkce pˇripadla Query a Query item objekt˚um.
Anal´yza uk´azala, ˇze SSRS, Cognos i OBIEE jsou si pomˇernˇe podobn´e a objekty v jednom n´astroji maj´ı ˇcasto paralelu v ostatn´ıch. Pro nˇekolik ob-jekt˚u Excelu toto tvrzen´ı plat´ı tak´e, ale jinak je Excel oproti ostatn´ım nejv´ıce odliˇsn´y. To m˚uˇze vych´azet z faktu, ˇze Excel se sice pouˇz´ıv´a k reportingov´ym
´
uˇcel˚um, ale prim´arnˇe byl zam´yˇslen jako tabulkov´y editor. Nˇekter´e jeho tabul-kov´e objekty, jako napˇr.Query table, nativn´ı a statick´e tabulky, by teoreticky mohly b´yt namapov´any na objekty v ostatn´ıch n´astroj´ıch, ale rozhodnˇe jde silnˇe o vˇec interpretace tˇechto objekt˚u. Spoleˇcnou reprezentaci tak bude nej-lepˇs´ı ˇreˇsit prim´arnˇe na ´urovni SSRS, Cognos a OBIEE a Excel ˇreˇsit samo-statnˇe.
Kapitola 4
N´ avrh spoleˇ cn´ e reprezentace reportingov´ ych n´ astroj˚ u
V pˇredchoz´ı kapitole byly analyzov´any datov´e objekty ve ˇctyˇrech r˚uzn´ych reportingov´ych n´astroj´ıch. Na z´akladˇe identifikace v´yznamovˇe podobn´ych ob-jekt˚u v z´avˇereˇcn´em shrnut´ı je v t´eto kapitole navrˇzen model uzl˚u pro repor-tingov´e n´astroje.
Hlavn´ı motivac´ı pro sjednocen´ı uzl˚u reportingov´ych n´astroj˚u je zjednodu-ˇsen´ı integrace grafu datov´ych tok˚u do n´astroj˚u tˇret´ıch stran. V r´amci tˇechto integrac´ı je totiˇz ˇcasto nezbytn´e uzly modelu opˇet transformovat na jin´e ob-jekty specifick´e pro dan´y software. ˇC´ım vˇetˇs´ı bude rozmanitost uzl˚u na stranˇe Manty, t´ım komplikovanˇejˇs´ı a n´akladnˇejˇs´ı bude tato transformace.
Podstatn´ym zjiˇstˇen´ım, kter´e z anal´yzy objekt˚u vyplynulo, je skuteˇcnost, ˇze i pˇres ˇradu podobn´ych objekt˚u se napˇr´ıˇc n´astroji vyskytlo velk´e mnoˇzstv´ı spe-cifick´ych objekt˚u, kter´e se v ostatn´ıch n´astroj´ıch neobjevily. Tyto unik´atn´ı uzly ˇ
casto maj´ı z´asadn´ı v´yznam a pokouˇset se je umˇele mapovat a tento v´yznam mˇenit jen za ´uˇcelem sjednocen´ı modelu by bylo neˇz´adouc´ı.
Moˇzn´ym ˇreˇsen´ım by bylo v´yznamovˇe podobn´e objekty sjednotit a unik´atn´ı objekty jednoduˇse do modelu pˇridat s vˇedom´ım, ˇze jen mal´a podmnoˇzina reportovac´ıch n´astroj˚u je vyuˇzije. Toto ˇreˇsen´ı jsem zavrhl, protoˇze nen´ı ˇsk´ alo-vateln´e. S nov´ymi podporovan´ymi reportovac´ımi n´astroji by model zbyteˇcnˇe bobtnal a postupnˇe se stal nepˇrehledn´ym a kontraproduktivn´ım.
Rozumnˇejˇs´ı variantou je unik´atn´ı objekty ze spoleˇcn´eho modelu vynechat a nechat implementuj´ıc´ımu program´atorovi volnou ruku pˇri jejich definici. M´ısto toho bude lepˇs´ı zamˇeˇrit se na objekty, kter´e se v analyzovan´ych n´astroj´ıch vyskytly opakovanˇe a z nich vytvoˇrit sadu spoleˇcn´ych uzl˚u. Nab´ız´ı se dvˇe varianty, jak pot´e pˇristoupit ke zm´ınˇen´e sadˇe.
1. Vynucen´ı vyuˇzit´ı modelu – v pˇr´ıpadˇe podobnosti uzlu s uzlem spo-leˇcn´eho modelu by bylo preferov´ano vyuˇzit´ı jiˇz definovan´e varianty. Hro-zila by ztr´ata informace o autentick´em pojmenov´an´ı objekt˚u v dan´em
n´astroji. Tomu by se dalo zabr´anit zobrazen´ım tohoto n´azvu v podobˇe jednoho z atribut˚u uzlu. Tato varianta m˚uˇze trochu brzdit v´yvoj, po-kud se program´ator bude pˇr´ıliˇs rozm´yˇslet, zda dan´y uzel m´a povaˇzovat za podobn´y a vyuˇz´ıt tak uzel ze spoleˇcn´eho modelu, nebo zda vytvoˇrit unik´atn´ı.
2. Preference specifick´ych objekt˚u– tento pˇr´ıstup d´av´a program´ atoro-vi volnost v definici objekt˚u a poskytuje pro uˇzivatele jednoduch´y pˇr´ıstup k typu objektu. St´ale je ale tˇreba m´ıt o spoleˇcn´em modelu povˇedom´ı a hlavnˇe b´yt schopen vysvˇetlit v´yznam uzl˚u inˇzen´yrovi, zab´yvaj´ıc´ımu se zm´ınˇen´ymi integracemi. V pˇr´ıpadˇe potˇreby je vyˇzadov´ana pomoc s ma-pov´an´ım. Urˇcitou n´apovˇedu vyjadˇruj´ıc´ı podobnost v˚uˇci uzlu spoleˇcn´eho modelu by mohlo b´yt napˇr´ıklad uveden´ı tohoto protˇejˇsku ve formˇe jeho n´azvu v atributu vrcholu.
Pˇri implementaci konektoru pro Cognos se pˇriklon´ım k 2. variantˇe a d´am tak pˇrednost autenticky pojmenovan´ym typ˚um uzl˚u, abych pˇredeˇsel jak´ emu-koliv zmaten´ı uˇzivatel˚u Cognosu spojen´emu s n´azvy objekt˚u. Toto rozhod-nut´ı vˇsak nebude nezvratn´e a bude pomˇernˇe snadn´e zpˇetnˇe zvolit jin´y pˇr´ıstup pro kohokoliv, kdo dan´ym objekt˚um rozum´ı. Stejnˇe tak bude pozdˇeji moˇzn´e tento pˇr´ıstup zmˇenit i pro ostatn´ı reportingov´e n´astroje, u kter´ych imple-mentace prob´ıhala jeˇstˇe v dobˇe, kdy spoleˇcn´y model nebyl vytvoˇren nebo finalizov´an.
Z anal´yzy objekt˚u d´ale vyplynulo, ˇze objekty se daj´ı t´emˇeˇr vˇzdy zaˇradit do jedn´e ze ˇctyˇr skupin. Tyto skupiny jsou nav´ıc uspoˇr´ad´any dle pomysln´e vzd´alenosti od fyzick´eho zdroje k v´ysledn´emu reportu. V t´eto pr´aci je proto budu oznaˇcovat za vrstvy.Patˇr´ı mezi nˇe:
• fyzick´a – zahrnuje uzly reprezentuj´ıc´ı datov´e zdroje a jejich struk-turu. Patˇr´ı do n´ı napˇr´ıklad datab´aze, jej´ı sch´ema, tabulky, sloupce, ale i zdrojov´e soubory (napˇr´ıklad v CSV form´atu29). Anal´yzu datov´ych tok˚u v t´eto vrstvˇe ze znaˇcn´e ˇc´asti pokr´yv´a jiˇz implementovan´a DataflowQue-ryService.
• analytick´a– vrstva, o kterou se ˇcasto star´a dedikovan´y n´astroj pro tvor-bu analytick´ych model˚u, OLAP kostek a podobn´ych. Mezi uzly t´eto vrstvy proto patˇr´ı dimenze, hierarchie, specifick´e uzly tabul´arn´ıch mo-del˚u apod.
• logick´a – nˇekter´e reportovac´ı n´astroje jeˇstˇe umoˇzˇnuj´ı dalˇs´ı vrstvu abs-trakce nad analytickou vrstvou. Typicky se tato vrstva modeluje uˇz v r´amci reportovac´ıho n´astroje a dan´e objekty umoˇzˇnuj´ı r˚uzn´e formy kalkulac´ı a agregac´ı nad hotov´ym modelem.
29CSV (Comma-separated values) je form´at sloupcovˇe strukturovan´ych datov´ych sou-bor˚u.
4.1. Model reprezentace objekt˚u
• prezentaˇcn´ı – uzly v t´eto vrstvˇe reprezentuj´ı nejˇcastˇeji viditeln´e ob-jekty, kter´e jsou pˇr´ımou souˇc´ast´ı report˚u. Pˇr´ıpadnˇe jsou to objekty, kter´e prezentaci viditeln´ych objekt˚u ovlivˇnuj´ı nebo reprezentuj´ı z´ıskan´a data apod.
4.1 Model reprezentace objekt˚ u
Vˇetˇsina definovan´ych typ˚u uzlu reprezentuje objekty, kter´e jiˇz byly pops´any v pˇredchoz´ı kapitole 3 a nebudou proto znovu pops´any. Plat´ı, ˇze pokud se stejnˇe pojmenovan´e uzly vyskytuj´ı na jin´ych vrstv´ach, jedn´a se o jin´e uzly30. Pˇri implementaci doporuˇcuji vˇsechny uzly prefixovat n´azvem jejich vrstvy, aby byly vz´ajemnˇe odliˇseny.
Ve spoleˇcn´em modelu uzl˚u bude vynech´ana fyzick´a vrstva, protoˇze da-tab´azov´e uzly i uzly spojen´e se soubory jako datov´ymi zdroji jsou jiˇz v r´amci Manta Flow definovan´e a prax´ı ovˇeˇren´e. Zbytek spoleˇcn´ych uzl˚u je seˇrazen dle vrstvy v n´asleduj´ıc´ım v´yˇctu.
• analytick´a
– Server je jiˇz tak´e v k´odu definov´an. M˚uˇze se vyskytnout ve fy-zick´e, analytick´e i prezentaˇcn´ı vrstvˇe. Ve vˇsech pˇr´ıpadech se jedn´a o jeden stejn´y definovan´y uzel, nebot’ jeho v´yznam na kaˇzd´e z nich je totoˇzn´y.
– Model– obecn´e pojmenov´an´ı pro jak´ekoliv tabul´arn´ı modely – Table– tabulka v tabul´arn´ım modelu. M˚uˇze pˇr´ımo korespondovat
s datab´azovou tabulkou, nebo b´yt z jedn´e ˇci v´ıce vytvoˇrena.
– Column– sloupec v tabulce tabul´arn´ıho modelu. Koresponduje se sloupcem datab´azov´e tabulky.
– Calculation – obecn´e pojmenov´an´ı pro jak´ekoliv vypoˇcten´e hod-noty na z´akladˇe ostatn´ıch ˇclen˚u modelu.
30Jedinou v´yjimkou tohoto pravidla je uzel Server, ten nen´ı tˇreba rozliˇsovat, protoˇze v´yznam je na kaˇzd´e vrstvˇe stejn´y.