Trys sistemos, kurios tą patį vilkiką vadina skirtingai

Vežėjo duomenys apie tą patį vilkiką gyvena trijose vietose. TMS sistemoje jis – V-104. Kuro kortelių išklotinėje – LT104. Buhalterijoje – Volvo FH 104 (ABC104). Tas pats vilkikas, trys skirtingi vardai.

Kol jų nesujungiate, negalite atsakyti į paprasčiausią klausimą: kiek uždirbo arba prarado konkretus vilkikas. Nes pajamos, kuras ir sąnaudos apie jį saugomos skirtingomis „pavardėmis”.

1. Ta pati realybė, trys pavadinimai

Kiekviena sistema buvo sukurta savo tikslui, todėl ir vilkiką užrašo savaip. TMS naudoja vidinį parko kodą, kuro kortelių tiekėjas – savo numeraciją, buhalterija – markę su valstybiniu numeriu. Nė viena jų nėra „neteisinga” – tiesiog jos niekada nebuvo suderintos tarpusavyje.

Žmogui akivaizdu, kad tai tas pats vilkikas. Duomenų lentelėms – ne, ir būtent čia prasideda darbas.

2. Kodėl sistemos nesusijungia pačios

Sujungimas visada remiasi tiksliu sutapimu. Jei viename stulpelyje parašyta V-104, o kitame LT104, programai tai du nesusiję tekstai – lygiai taip pat, kaip du skirtingi žodžiai. Ji neturi iš kur žinoti, kad tai tas pats objektas.

Todėl bandymas „tiesiog sujungti” tris failus baigiasi tuščiais langeliais arba dvigubomis eilutėmis. Prieš jungiant reikia sukurti bendrą kalbą.

3. Sprendimas: vienas žinynas

Bendra kalba – tai nedidelė rankomis sudaryta lentelė (žinynas), kurioje kiekvienam vilkikui surašyti visi jo pavadinimai: parko kodas, kuro kortelės numeris, buhalterijos objektas. Ji sukuriama vieną kartą ir tampa vieninteliu tašku, per kurį visos sistemos randa viena kitą.

Techniškai tai yra dimensijos lentelė – tas pats principas, kuriuo remiasi bet koks tvarkingas duomenų modelis. Vėliau pasikeitus vilkikų sąrašui pataisote tik žinyną, o ne kiekvieną ataskaitą.

TMS, kuro kortelės ir buhalterija tą patį vilkiką užrašo trimis vardais. Žinynas sujungia juos į vieną eilutę.

4. Kaip sujungti – Merge Queries

Sujungimas atliekamas su Merge Queries (Left Outer): prie žinyno prijungiami kuro ir sąnaudų duomenys pagal atitinkamą kodą, o tada išskleidžiamas bendras parko kodas. Po šio žingsnio visi trys šaltiniai kalba ta pačia kalba – vietoj trijų pavadinimų lieka vienas.

Svarbu tvarka: pirma sutvarkomi patys pavadinimai (pašalinami tarpai, suvienodinamas formatas), ir tik tada jungiama. Priešingu atveju net teisingas žinynas nesujungs įrašų, kuriuose slypi nematomas tarpas ar kitoks brūkšnelis.

5. Kad naujos rūšys įsitrauktų pačios

Sąnaudos dažnai ateina „plačiu” formatu – kiekviena sąnaudų rūšis atskirame stulpelyje. Jei tokią lentelę jungsite tiesiogiai, atsiradusi nauja sąnaudų rūšis (pavyzdžiui, devinta) tyliai liks už borto.

Todėl naudojamas Unpivot Other Columns, o ne fiksuotas stulpelių sąrašas: taip bet kuri nauja rūšis įsitraukia automatiškai, nieko netaisant. Demonstracinėje ataskaitoje tai 192 eilutes pavertė 1 536 – ir paruošė modelį ateities pokyčiams.

6. Tyli patikra, kad niekas neiškristų

Sujungus verta palikti nedidelę patikros užklausą, kuri atrenka įrašus be atitikmens žinyne (kur kodas liko tuščias). Įprastai ji tuščia. Bet jei kada nors atsiras naujas vilkikas, kurio dar nėra žinyne, jis iškris būtent čia – o ne pasislėps bendroje sumoje ir nesugadins tyliai skaičių.

Tai pigi apsauga, kuri vėliau sutaupo valandas ieškant, kodėl skaičiai „šiek tiek nesueina”.

Išvada

Didžiausias barjeras sujungiant vežėjo duomenis yra ne technologija, o tai, kad sistemos tą patį vilkiką vadina skirtingai. Vienas rankomis sudarytas žinynas, Merge Queries ir Unpivot išsprendžia tai visam laikui – ir paverčia tris nesikalbančias išklotines viena ataskaita, kuri žino, kuris vilkikas ką uždirbo.

Kaip visa tai atrodo baigtoje ataskaitoje, galite pamatyti čia: vilkikų maržos ataskaitos atvejo studija.