Datele de salarizare pentru mai multe şcoli şi pentru mai multe luni sunt păstrate într-o anumită bază de date, sub gestiunea unei aplicaţii de salarizare. La un anumit moment de pe parcursul exploatării aplicaţiei, se cere înlocuirea datelor corespunzătoare unei anumite şcoli şi unei anumite luni, cu datele existente într-o arhivă anterioară.
Există mai multe şcoli înscrise. Fiecare şcoală face salarizarea pe mai multe luni, nu neapărat aceleaşi pentru toate şcolile (o şcoală a început din Sep-06, alta din Apr-07, etc.). Uneori, salarizarea pe luna curentă trebuie să ţină cont de datele lunilor anterioare (de exemplu, în cazul modificării retroactive a coeficienţilor) - astfel că este necesară păstrarea datelor pe toate lunile.
Fiecare şcoală are mai mulţi angajaţi. Fiecare angajat are mai multe state de plată (chiar şi pe o aceeaşi lună, dacă angajatul are mai multe funcţii plătite) şi poate avea, pe o lună sau alta, diverse categorii (specifice şcolii) de drepturi, indemnizaţii sau reţineri.
Fiecare şcoală are asociat un anumit cont de acces, prin intermediul căruia pot fi exploatate datele acelei şcoli (de către un user autorizat).
Sintagmele evocate mai sus au stat la baza conceperii tabelelor şi relaţiilor necesare. Tabelul scoala este destinat păstrării informaţiilor generice asupra şcolilor înscrise (denumire, adresă Mail, cod fiscal, etc.). Tabelul scoala este relaţionat one-to-many cu diverse alte tabele; fiecărei înregistrări din scoala îi corespund anumite înregistrări din tabelul angajaţilor, anumite înregistrări din tabelul lunilor, respectiv din tabelul statelor de plată, din tabelul concediilor medicale, etc. Tabelul angajaţilor are şi el, o relaţie one-to-many cu tabelul statelor de plată, ş.a.m.d.
Aplicaţia de salarizare trebuie să asigure exploatarea acestei baze de date, permiţând:
— înscrierea unei şcoli (prin crearea la cerere a unui cont de acces corespunzător);
— înscrierea iniţială a angajaţilor (cu posibile modificări sau adăugări pe parcursul anului), de către userul autorizat;
— înscrierea iniţială a unor date care în general nu variază pe parcursul anului: categorii standard de concedii medicale, de "alte drepturi" şi "alte reţineri", categorii de cotizaţii (sindicat), băncile unde angajaţii au carduri de salarii, etc.;
— înscrierea datelor iniţiale ale angajaţilor (funcţie, studii, grad, vechime, etc.), asigurând calculele de salarizare corespunzătoare;
— posibilitatea transferării datele din luna precedentă pe luna curentă, permiţând modificările necesare pe noua lună;
— posibilitatea de a recalcula salariile pe una sau mai multe luni anterioare (conform noilor coeficienţi instituiţi) şi de a transfera diferenţele rezultate ca drepturi pe luna curentă;
— posibilitatea considerării mai multor funcţii pentru un acelaşi angajat, corelând corespunzător statele de plată ale acestuia (în privinţa contribuţiilor şi impozitelor datorate);
— raportarea statelor de plată lunare şi a altor situaţii centralizatoare necesare;
— downloadarea unor fişiere cu datele necesare realizării unor declaraţii către diverse instituţii (Casa de Pensii, Agenţia de Şomaj, Casa de Sănătate, Bănci, Sindicate)
În plus, trebuie asigurată actualizarea unitară (de către administratorul sistemului) a diverşilor coeficienţi stabiliţi / modificaţi periodic de către organele abilitate; trebuie asigurate posibilităţi de comunicare ("forum") şi de "help"; etc.
Intenţia principală a aplicaţiei descrise mai sus este aceea de a refolosi datele anterioare, uşurând operarea pe noua lună. În prima lună de folosire a aplicaţiei, utilizatorul trebuie să înscrie cam toate datele menţionate mai sus (descrierea categoriilor specifice şcolii, datele pentru fiecare angajat, etc.); dar apoi, începând din a doua lună - utilizatorul nu are de operat decât modificări de natură globală (de exemplu, eventuala modificare a numărului de zile lucrătoare, sau înscrierea la majoritatea angajaţilor a unor sume corespunzătoare unei anumite categorii de "alte drepturi" sau "alte reţineri"), sau modificări individuale (la unii angajaţi).
Utilizatorul este informat în mod explicit—cum altfel, decât printr-un scurt text explicativ şi eventual, printr-o fereastră de alertare—asupra operaţiei de trecere la noua lună: luna curentă se "închide", adică datele respective nu vor mai putea fi modificate (scopul acestei interdicţii este evident: asigurarea coincidenţei între sumele înregistrate şi acelea plătite în realitate pe luna respectivă); iar datele lunii tocmai închise sunt copiate (în majoritatea lor), devenind datele iniţiale de salarizare pe noua lună (urmând ca utilizatorul să le modifice dacă şi acolo unde este necesar, în concordanţă cu specificul noii luni create). Cu alte cuvinte, această operaţie trebuie efectuată după ce s-au semnat statele de plată finale (şi nu mai este cazul de a mai face modificări pe luna curentă); dacă nu s-au încheiat operaţiile corespunzătoare lunii curente, atunci nu trebuie trecut la noua lună (este clar că decizia de trecere la noua lună este responsabilitatea utilizatorului şi nu a programului).
Constatăm însă un obicei prost, capcană indusă de educaţia point-and-click: în procesul de folosire a aplicaţiei respective, utilizatorul nu mai implică propria inteligenţă şi nici deprinderile elementare (precum deprinderea de a citi) - acceptând substituirea facilă a acestora prin clickuri (ignorând astfel şi textele explicative oricât ar fi de scurte, şi ferestrele speciale de alertare).
S-a întâmplat astfel, ca un utilizator să modifice datele (la mai mulţi angajaţi) după ce s-au achitat salariile şi să treacă apoi pe noua lună; prin urmare, datele înregistrate pentru luna tocmai încheiată nu mai concordă cu cele reale pentru luna respectivă şi pe de altă parte, ele nu mai pot fi modificate (pentru a le "repara", ca să corespundă realităţii; aplicaţia pune la dispoziţie o operaţie de "recalculare", dar recalcularea salariilor pe o lună anterioară se face în conformitate cu ultimii coeficienţi în vigoare - iar aceştia tocmai se modificaseră).
Mai precis, odată "închisă" luna curentă, datele ei nu mai pot fi modificate de către user-ul respectiv, dar încă pot fi modificate de către administratorul sistemului. Conform uzanţelor specifice lucrului cu baze de date, administratorul face periodic copii ale bazei de date şi le păstrează într-o anumită arhivă (în scopul reconstituirii, dacă s-ar întâmpla distrugerea bazei de date în urma vreunei intervenţii neautorizate, sau în urma vreunei greşeli de operare din partea administratorului, sau în urma unui eventual cataclism). Presupunând că acea copie arhivată a fost făcută la timpul potrivit (adică după ce s-au listat statele finale şi înainte ca utilizatorul să efectueze modificări faţă de momentul achitării salariilor), administratorul va putea folosi această copie a datelor pentru a înlocui (în baza de date de pe server) datele lunii închise, prin datele corecte (ale acelei şcoli).
Conform uzanţelor, autorul aplicaţiei are pe propriul calculator o copie de lucru, a întregii aplicaţii care rulează pe serverul aflat la dispoziţia utilizatorilor. Pentru a rezolva problema descrisă mai sus, autorul trebuie să actualizeze baza de date de pe calculatorul propriu cu baza de date (din arhivă) corespunzătoare situaţiei descrise şi apoi să selecteze din baza de date actualizată astfel înregistrările corespunzătoare şcolii şi lunii respective; tabelul obţinut astfel va trebui transferat pe server, unde urmează apoi să fie inserat corespunzător în baza de date (de pe server) pentru a înlocui înregistrările deteriorate.
Fie salarii numele bazei de date MySql şi fie state numele tabelului din această bază de date, care conţine datele de salarizare (relaţionat faţă de şcoli, luni, angajaţi, etc.). Descriem succesiunea de comenzi mysql (pe calculatorul propriu, respectiv pe server) care conduce la rezolvarea problemei.
1. Actualizarea bazei de date existente pe calculatorul propriu:
mysql -u nume_user -pParola_mysql salarii < 2008-02-07.sql
Am deschis un terminal (interpretor de comenzi, sau "shell") şi la promptul respectiv am tastat comanda scrisă mai sus. Prin această comandă se invocă shell-ul mysql, prin intermediul căruia utilizatorul autentificat prin "nume_user" şi "Parola_mysql" va putea interoga şi opera asupra bazei de date "salarii"; şi anume, prima operaţie cerută este aceea de a înlocui datele existente în "salarii" cu cele citite din "2008-02-07.sql" (aceasta din urmă fiind baza de date din arhiva de unde trebuia făcută actualizarea necesară). Această comandă va fi executată neinteractiv: după încheierea ei se revine la promptul terminalului; reîncărcăm comanda în terminal (săgeată-sus), ştergem ultima porţiune din cadrul ei şi ENTER - astfel, se invocă mysql în mod interactiv (putând apoi introduce comenzi MySql, la promptul "mysql>").
2. Creează un tabel de lucru, cu aceeaşi structură ca tabelul state:
mysql> create table state5ian like state;
3. Selectează din state înregistrările necesare şi inserează-le în state5ian:
mysql> insert into state5ian select * from state where id_scoala=50 and id_luna=200;
După această operaţie, părăsim mysql (mysql> quit).
4. Extrage din salarii şi salvează tabelul state5ian:
mysqldump -u nume_user -pParola_mysql salarii state5ian > state5ian.sql
5. Transferă fişierul state5ian.sql pe server; intră pe server (conform drepturilor alocate de către administratorul serverului) şi la promptul terminalului alocat introdu:
mysql -u nume_user_server -pParola_mysql_server salarii < state5ian.sql
Astfel, în baza de date de pe server este adăugat şi tabelul state5ian. Relansăm comanda, ştergând însă partea finală a ei; obţinem astfel un shell interactiv mysql.
6. Înscrie înregistrările din state5ian în locul celor corespunzătoare lor din state:
mysql> replace into state select * from state5ian;
Înregistrările "corespunzătoare" sunt recunoscute prin faptul că au aceeaşi valoare în câmpul declarat primary key la construirea tabelelor.
Desigur, în final rămâne de eliminat tabelul de lucru state5ian (mysql> drop state5ian;) şi operaţia este completă.
vezi Cărţile mele (de programare)