header image

Uporabna vrednost podatkovnega strežnika in ERP-a

Objavil: P.J. | 21.03.2010 | 4 Komentarjev |

Ko nanese beseda na podatkovne zbirke in podatkovni strežnik, večina spremeni temo na kaj manj abstraktnega. Vendar vprašanja ostajajo in terjajo odgovore. Dolga poročila, ki jih generirajo ERP1 sistemi so navadno preobsežna, da bi človek lahko na hitro iz njih kaj razbral. Ko pa se človek obrne na koga, da bi naredil nek zbirni pregled, v katerem bi zgoščeno prikazal odgovor na neko vprašanje, pa naleti na zmajevanje z glavo in nagubana čela, ki sporočajo: »To pa ne bo šlo.«. V tem prispevku bom skozi praktičen primer prikazal, da zbirna poročila2 niso noben »bav bav« in jih lahko tudi sami na hitro pripravimo.

Za primer bom vzel vprašanje: »Kakšna so sezonska nihanja prihodkov in odhodkov skozi zadnja leta?«.  Lahko bi vzel kako drugo, a zaradi svete preproščine se bom vzdržal kompliciranja. Vsak spodoben sistem nekam beleži plačila podjetja. Sam za ta namen uporabljam tabelo, ki jo poimenujem transactions. Če torej na tej tabeli opravim preprosto poizvedbo:

Poizvedba 1: Leto, mesec in znesek transakcije

Poizvedba 1: Leto, mesec in znesek transakcije

dobim potreben nabor podatkov. No, ne še čisto. Sam finančne transakcije opremim še s podatkom o vrsti posla. Med drugim mi ta pove, kako ta transakcija vpliva na finančni tok (+1: priliv ; 0: ne vpliva  -1: odliv). Ker imam posebno tabelo, v katero lahko vnašamo vrste poslov, bom poizvedbo malo dopolnil:

Poizvedba 2:

Poizvedba 2: Leto, mesec, znesek in smer finančnega toka transakcije

Sedaj smo pa čisto zares pripravil podatke zato, da si bomo lahko odgovorili na zgoraj zastavljeno vprašanje. Vendar smo podatke dobili v nepredstavljivo velikem številu vrstic, kar je še vedno nepregledno in neuporabno, kot je razvidno iz slike.

Rezultat poizvedbe 2 vrne kar nekaj tisoč vrstic...

Rezultat poizvedbe 2 vrne kar nekaj tisoč vrstic...

Najprej si bomo zadevo znatno poenostavili tako, da bomo mesece posameznega leta postavili v stolpce3. To bomo storili tako, da bomo za vsako transakcijo posebej pogledali, v kateri mesec spada in njeno vrednost zapisali v ustrezen stolpec. Naša poizvedba sedaj zgleda nekako tako:

Poizvedba 3: Spremenimo vrstice v stolpce

Poizvedba 3: Spremenimo vrstice v stolpce

Sedaj smo že pri koncu naše telovadbe. Preostane nam samo še agregiranje (sinteza). Sešteli bomo vse vrstice in prikazali zgolj seštevke po letih in po smeri finančnega toka. Za to pa obstaja preprosta funkcija, imenovana SUM(). Naša poizvedba na kocu zgleda nekako tako, kot je razvidno iz slike.

Poizvedba 4: Sumarni pregled mesečnih prihodkov in odhodkov po letih

Poizvedba 4: Sumarni pregled mesečnih prihodkov in odhodkov po letih

Veliko bolj impresiven, kakor poizvedba sama, pa je rezultat, ki ga je sproducirala. Dobili smo namrež podatke, oblikovane natanko tako, kot smo jih želeli. Če smo na začetku lahko gledali nepregledno množico podatkov (nekaj tisoč vrstic), smo sedaj dobili zgolj nekaj vrstic (po dve za vsako poslovno leto) in 14 stolpcev.

Končni rezultat: pregled mesečnih prihodkov in odhodkov po letih

Seveda ne bomo vsakič posebej pisali takšne poizvedbe. Smisel podatkovnega strežnika je, da nam postreže na zahtevo. Zato bomo sedaj našo poizvedbo shranili – v našem primeru v OpenOffice.org Base. To storimo tako, da odpremo ODB datoteko, ki hrani povezavo z našim strežnikom in dodamo novo poizvedbo (na voljo za »copy-paste« na koncu prispevka).

Poimenujemo jo kar »Sezonska nihanja prihodkov in odhodkov po letih«. Naslednjič zadostuje, da zgolj zaženemo poizvedbo. Marsikdo se bo vprašal, zakaj nisem za vse skupaj raje uporabil vrtilne tabele v Excelu ali Calcu. Odgovor je preprost:

  • poizvedba je podatke (prb. 6500 vrstic) na strežniku spravila skupaj v prbl. 0,01 sekunde in mi jih prikazala v 0,15 sekunde. Koliko časa bi vse skupaj uvažal v Excel ali Calc lahko preizkusite sami
  • po mreži prenašam zgolj peščico podatkov, v nasprotju s prej opisano metodo, kjer bi mrežo zabasal z nekaj tisoč vrsticami, ki jih sploh ne želim gledati

Nekaj pozornosti smo torej namenili tudi optimizaciji. Excel, oz. bolj točno Calc v dotičnem primeru pa bomo uporabili za prikaz podatkov uporabniku. O tem več na naslednji strani.

  1. Enterprise Resource planing – Planiranje oz. upravljanje virov v podjetju []
  2. angl: synthetic reports []
  3. tega bodo posebej veseli tisti, ki me sprašujejo, kako vrstice spremeniti v stolpce []
  • Share/Bookmark

Strani: 1 2 3

Zapisano pod: Naredi si sam, Pisarna in poslovanje, Programiranje, Zbirke podatkov
Tags:

Odzivi

Ta zapis je očitno že pretrd oreh za nas plebejce. Še nobenega komentarja… :-)

Spomnil si me na nek stranski učinek danes tako modernega zbiranja osebnih podatkov v razne baze predvsem za izrabljanje v trženjske namene. Kako vedno bolj polno in zastarelo bazo vzdrževati in predvsem ažurirati?
Kako vedeti, kdo se je preselil, ločil, se besen znebil tvojega (pokvarljivega) izdelka in ga vsak stik s tvojim podjetjem samo spomni na tegobe in spravi v slabo voljo? Kaj se že da storiti, a potem kar nekaj stane…

No, ta primer je za “laike” morda res na prvi pogled pretrd oreh. Vendar bi ga tudi laik znal naklikati skupaj v OOo Base-u (ali MS Accessu).

Kar sem jaz v resnici tukaj naredil je, da sem tri poizvedbe oblikoval v eno samo. Če bi to delal “laik”, bi odprl Čarovnika za poizvedbe, naklikal prvo poizvedbo in jo shranil.

Nato bi naklikal še drugo poizvedbo, pri čemer bi si izračunane (CASE … ) stolpce naklikal s pomočjo Urejevalnika formul. Ko bi s tem zaključil, bi se lotil tretje.

To bi naredil tako, da bi v Čarovniku za poizvedbe določil vsa polja iz predhodne in pri tistih, ki predstavljajo mesece bi pač izbral možnost agregiranja iz spustnega seznama imenovano SUM. Na koncu bi še to shranil.

Petdesetvrstično klobaso bi torej zlahka naklikal vsak laik. Težjje je priti do same ideje. Še težje pa navadno sploh priti do relevantnih podatkov.

Navadno pa “končni uporabniki” sploh ne pridejo na idejo, da niso odvisni od ponudnika programske opreme in da lahko z orodji, s katerimi povečini vsi razpolagajo (npr. pisarniška zbirka) lahko avtomatizirajo veliko število procesov.

Glede tvoje druge pripombe pa bom krajši – vedno trdim: Garbage in, garbage out.

Nekoč sem delal na projektu vrednem kar nekaj deset tisoč takratnih dojčmark. Moje področje je bilo BI (bussiness inteligence). Torej analitična/sinetična obdelava podatkov. Na koncu je zadeva izpadla tako, da so programerji na “front-endu” morali programirati, kako “obiti” omejitve, ki jih je moj BI vsiljeval.

Da se bomo razumeli: kolega je imel nalogo sprogramirati, da lahko komercialist brez vnosa pojasnila odobri izdajo blaga kupcu, ki je več kakor 90 dni zamujal s plačili več, kakor je sploh imel “limita”… Šlo je za preprosto pojasnilo, ki naj bi v CRM zabeležilo, zakaj je temu kupcu to takrat odobril… pa se jim ni dalo vnašat.

:D

Kdo potem sploh potrebuje BI in “work-flow”-e?

Tvoj zadnji stavek me je spomnil na vlogo in delo številnih nadzornih svetov pomembnih podjetij… Kdo jih potem sploh potrebuje? :-)

Glede na to, da sem se šele pred kratkim naučil kako se prižge računalnik je to za mene prevelik zalogaj :lol: če pa bi kdaj potreboval nasvet sem pa vesel, da smo se srečali :lol: pa vesele praznike :lol:

Pustite komentar

Tvoj odziv :

Komentiranje iz tujine je omogočeno zgolj prijavljenim uporabnikom !

Kategorije