Struktura evidencije partnera

Thursday, 16.08.2007 – Srdjan

S vremena na vreme mi je posao da izvršim transfer podataka iz jednog sistema za čuvanje podataka u drugi sistem. Obično se izvorni sistemi sastoje od DBF datoteka. Česti problemi koji nastaju prilikom ovakvih transfera podataka su:
– različite strukture izvornih i ciljnih podataka i
– “prljavi” izvorni podaci (duplirani podaci (a usput različiti), podaci koji nedostaju, podaci koji se nalaze tamo gde im nije mesto,…).

Pre neki dan sam opet imao “čast” da vršim transfer takvih podataka. Od svega što sam zatekao u izvorni DBF datotekama, ovom prilikom ću prodiskutovati evidenciju o poslovnim partnerima.

Evidencija o partnerima se nalazila u jednoj DBF datoteci, sledeće strukture:

Field   Type Size 
------- ---- ---- 
PRED     C    2 
SIFRA    C    6 
NAZIV1   C   30 
NAZIV2   C   30 
ADRESA   C   30 
POSTBR   C    5 
MESTO    C   24 
GRAD     C   30 
ZRACUN   C   25 
ZRACUN2  C   25 
ZRACUN3  C   25 
ZRACUN4  C   25 
ZRACUN5  C   25 
ZRACUN6  C   25 
OPISD    C   40 
TELEFD   C   12 
TEFAXD   C   12 
OPISK    C   40 
TELEFK   C   12 
TEFAXK   C   12 
OPIS     C   40 
TELEF    C   12 
TEFAX    C   12 
GRUP1    C    2 
GRUP2    C    2 
MATBR    C    8 
REGBR    C   11 
SIFDEL   C    6 
TREBA    L    1 
PIB      C    9 
OBVPDV   L    1

Sama struktura mi je otkrila nekoliko stvari:
– naziv partnera je podeljen na dve kolone,
– predviđeno je da se može zapisati do 6 tekućih računa (pojam žiro račun se ne upotrebljava već 2 i po godine) za jednog partnera,
– predviđeno je da se može zapisati do 6 brojeva telefona za jednog partnera.

Pogled na sadržaj tabele je otkrio mnogo više:
– Za neke partnere je bilo upisano i više od 6 brojeva telefona! Za upis dodatnih brojeva su korišćene kolone ‘opisd’, ‘opisk’ ili ‘opis’.
– Gore spomenute kolone su služile i za upisivanje e-mail adresa (ipak smo u 21-vom veku 🙂 ) ili adrese istovarnog mesta.
– Vrednosti u koloni grad su izvedene od vrednosti kolone ‘postbr’ i ‘mesto’.
Prilično sam se namučio dok nisam podatke prebacio u ciljnu bazu. Posebno su problematične bile kolone opisa, koje su kako sam već rekao korišćene u razne svrhe. Iz ovoga i proizilazi zaključak da korišćena struktura podataka nije odgovarala potrebama za vođenje podataka o partnerima i kontaktima.

Hteo sam malo da se poigram sa postojećom strukturom i postavio sam pitanje: Kakva bi to struktura bila kvalitetnija od postojeće?

Kvalitetnija struktura mora da obezbedi:
1. unos više od 6 tekućih računa (koliko god to ludo zvučalo),
2. unos više od 6 brojeva telefona,
3. unos adresa poslovnica
4. unos e-mail adresa.

Pored gornje liste poboljšanja (koja bi se i još mogla proširiti), kvalitetnija struktura mora obezbediti kvalitetnija imena kolonama (da niko ne mora da razmišlja šta znači ‘grup1’, a šta ‘grup2’).

Ostvarenje prvog cilja

Izdvojio sam sve što se tiče tekućeg računa u novu tabelu kao što je prikazano na donjem dijagramu.

Slika 1

Ostvarenje drugog cilja

Izdvojio sam podatke o kontaktima (osobama, odeljenjima, službama) u posebnu tabelu kao što je prikazano na donjem dijagramu.

Slika 2
Svaki kontakt može imati više brojeva telefona (mobilni, kućni, direktan u firmi, lokal preko centrale). Takođe broj faks nije ništa drugo do još jedne vrste broja telefona. Izdvojio sam brojeve telefona iz tabele kontakata i oformio sam novu tabelu, kao na donjem dijagramu.

Slika 3

Ostvarenje trećeg cilja

Izdvojio sam podatke o adresi (ulica, broj, pošta i mesto) u posebnu tabelu i dodao sam svakoj adresi opis, kao što je prikazano u donjem dijagramu.

Slika 4

Ostvarenje četvrtog cilja

Za ovu potrebu sam jednostavno dodao novu tabelu u koju se zapisuju e-mailovi kontakata. Slično telefonu i adresi, i e-mail ima svoj (jedinstveni) opis.

Slika 5
Evo me na kraju zacrtanih ciljeva. Ova struktura je daleko fleksibilnija od polazne strukture.

Ova struktura ne odgovara samo programerima GUI-a, jer ju je daleko teže prikazati od prvobitne strukture, koja je i bila napravljena sa idejom što lakšeg pisanja programa. Programeri često zaborave da podaci jedne firme često nadžive njihove programe.

Mentalna napomena: Ako se u nekoj koloni očekuje unos imena (osobe, službe) koje se sastoji isključivo od slova, treba zabraniti unos cifara, pluseva, crtica i ostalih ne slovnih znakova. Ako se to ne uradi, naći će se neki korisnik koji će u tu kolonu uneti cifre ili nešto neočekivano.

Post a Comment