Invatare Atomica

De ce o baza de date si nu inca o foaie de calcul

Tipurile de date dintr-o baza si alegerea corecta pentru fiecare camp al unei evidente de piese auto

Progres lectie:
0%
🎯

De ce conteaza aceasta lectie

Daca tii evidenta pieselor, preturilor si furnizorilor intr-un fisier Excel care a crescut la mii de randuri, ai simtit deja problema: acelasi cod de piesa scris in trei feluri diferite, cautari care nu gasesc ce cauti, totaluri care nu se potrivesc cu factura. Lectia de azi iti arata de ce apar aceste probleme si cum le previi din start, alegand tipul de date corect pentru fiecare camp inainte sa introduci o singura piesa in evidenta.

Dupa aceasta lectie vei putea:

  • Sa explici de ce o evidenta mare, cu mai multe legaturi intre date, are nevoie de o baza de date si nu de o foaie de calcul
  • Sa recunosti campul de tip Text si sa il folosesti corect pentru coduri de piesa cu zerouri la inceput
  • Sa alegi intre Numar intreg si Numar cu zecimale pentru cantitati si masuratori
  • Sa folosesti campul de tip Data pentru receptii si termene de garantie, inclusiv calculul datei de expirare
  • Sa folosesti campul de tip Logic (Da/Nu) pentru starile cu doar doua variante posibile
  • Sa explici de ce preturile stau in campul Moneda si nu intr-un camp Numar obisnuit
  • Sa recunosti si sa repari cele mai frecvente greseli de alegere a tipului de date

Incearca singur!

Provocare — inainte sa citesti:

Un coleg cauta in fisierul Excel al atelierului "amortizor fata Dacia Logan" si gaseste trei randuri diferite: unul cu codul AM-0231, unul cu codul am 0231 si unul cu codul 231 (fara zerouri, scris ca numar). Fiecare rand are alt pret si alta cantitate in stoc. Colegul nu stie cate bucati are de fapt in stoc si nici care pret e cel real. Scrie mai jos: de ce credeti ca s-a ajuns aici, desi toate datele sunt in acelasi fisier, si ce ar trebui sa impiedice de la inceput acest haos?

💡 Ai nevoie de un indiciu?

Ganditi-va la un raft de scule fara etichete standard: fiecare mecanic isi noteaza ce a pus pe raft cum crede el de cuviinta — unul scrie cu majuscule, altul cu spatii, altul doar cifrele. Rezultatul: nimeni nu mai gaseste nimic sigur, desi toate sculele sunt fizic pe acelasi raft. O foaie de calcul obisnuita se comporta la fel — orice celula accepta orice fel de continut, fara nicio regula.

O baza de date rezolva exact asta: fiecare camp (coloana) are un tip de date fix, stabilit o singura data, pe care il respecta absolut toate randurile introduse dupa aceea. Asta e subiectul lectiei de azi.

1

De ce o baza de date si nu inca o foaie de calcul

O foaie de calcul (Excel) este o retea libera de celule: orice celula poate contine orice — text, numar, data, formula — fara nicio regula impusa in mod implicit (Excel ofera si o functie de Validare date, dar ea trebuie activata manual, celula cu celula sau coloana cu coloana — nu vine impusa din start ca la o baza de date). O baza de date este o colectie de tabele in care fiecare coloana (numita camp) are un tip de date declarat pentru acel camp si respectat de toate randurile introduse in tabel. Tipul unui camp poate fi schimbat ulterior (in Access, din Design View) — asa cum vei face de cateva ori chiar in aceasta lectie — dar in orice moment dat, toate randurile respecta tipul curent al campului; nu exista rand care sa "faca exceptie".
Programul folosit in aceste lectii:

Baza de date pe care o vei construi pas cu pas in acest capitol o vei face in Microsoft Access, programul de baze de date inclus in pachetul Microsoft Office. Termenii tehnici din lectiile urmatoare (Text scurt, Field Size, Design View etc.) sunt denumirile exacte pe care le vei intalni in meniurile Access.

Cand chiar ajunge Excel-ul:

Liste scurte, de cateva zeci de randuri, fara legaturi cu alte liste, folosite de o singura persoana — de exemplu un inventar rapid al sculelor din propria trusa.

Cand Excel-ul nu mai ajunge:

Cand ai mii de piese, mai multe tabele care trebuie legate intre ele (piese, furnizori, comenzi, clienti) si mai multi oameni care introduc date in acelasi timp. Baza de date impune un tip de date fix per camp (asa cum vei vedea in atomii urmatori) si poate impiedica de la inceput introducerea unui cod de piesa duplicat, prin regula de cheie primara — subiect pe care il vei aprofunda in lectia urmatoare.

2

Tipul de date Text — coduri, denumiri, furnizori

Campul de tip Text (in Access: Text scurt / Short Text, pana la 255 de caractere) pastreaza orice sir de litere, cifre si semne care nu va fi folosit in calcule matematice. Aici intra codul piesei, denumirea, numele furnizorului, observatiile.
Exemplu din atelier:

Campul Cod_Piesa cu valoarea AM-0231 sau 00452 trebuie sa fie Text. Chiar daca "0231" sau "00452" par numere, ele sunt de fapt identificatori — codul de catalog al furnizorului — si trebuie comparate caracter cu caracter, nu calculate.

❌ Greseala frecventa: Campul Cod_Piesa este setat ca Numar pentru ca "sunt cifre". Rezultat: codul "00452" se salveaza ca 452 — zerourile din fata dispar automat, pentru ca nu au valoare matematica. Cand cauti dupa codul de pe factura furnizorului ("00452"), evidenta ta nu il mai gaseste, pentru ca la tine e stocat "452".
Cum recunosti: codul afisat in evidenta are mai putine cifre decat cel de pe factura sau catalogul furnizorului.
Cum repari: schimba tipul campului in Text inainte sa reintroduci codurile; intr-un tabel deja populat gresit, va trebui sa retastezi valorile dupa schimbarea tipului, pentru ca zerourile pierdute nu se recupereaza automat.
3

Tipul de date Numeric — cantitati si masuratori

Campul de tip Numar (Number) este pentru valori pe care chiar le vei folosi in calcule: adunari, inmultiri, medii. Un camp Numar are un subtip (in Access, Field Size): Numar intreg (Integer) — fara zecimale, pentru cantitati de bucati; Numar cu zecimale — Single (precizie simpla, suficienta pentru masuratori uzuale de atelier: diametru, greutate, capacitate in litri) sau Double (precizie dubla, cu mai multe zecimale exacte — folosita doar cand ai nevoie de o precizie stiintifica, nu pentru evidenta obisnuita de piese).
Atentie la Field Size ales pentru Numar intreg:

In Access, subtipul Integer ocupa 2 octeti si accepta doar valori intre -32.768 si 32.767 — suficient pentru cantitati de piese mari (amortizoare, planetare), dar prea putin pentru un depozit de piese marunte vandute cu miile (suruburi, clipsuri, saibe). Din acest motiv, Field Size implicit propus de Access pentru un camp numeric este de fapt Long Integer (pana la peste 2 miliarde), iar pentru Cantitate_Stoc la piese marunte alegi explicit Long Integer, nu Integer.

Exemplu complet, dus pana la rezultat:

Ai in stoc Cantitate_Stoc = 24 de amortizoare (Numar intreg — se numara doar in bucati). Fiecare amortizor cantareste Greutate_Unitara = 3,2 kg (Numar cu zecimale — masuratoare reala). Greutatea totala pentru transport se calculeaza asa:
Greutate_totala = Cantitate_Stoc x Greutate_Unitara = 24 x 3,2 = 76,8 kg.

❌ Greseala frecventa: Campul pentru cantitatea de ulei (in litri, ex. 2,5 l) este setat ca Numar intreg. Programul rotunjeste automat valoarea introdusa, fara niciun avertisment vizibil: Access foloseste rotunjire bancara (banker's rounding) pentru campurile Integer, deci 2,5 devine intotdeauna 2, iar 3,5 devine intotdeauna 4 — nu e un rezultat la intamplare, ci un tipar fix, dar care oricum falsifica cifrele reale.
Cum recunosti: valorile din evidenta au mereu cifre rotunde, desi pe bonul de achizitie scrie o cantitate cu zecimale.
Cum repari: schimba subtipul campului la Numar cu zecimale (Single sau Double) cand valoarea poate avea fractii de unitate.
4

Tipul de date Data — receptii si termene de garantie

Campul de tip Data/Ora (Date/Time) stocheaza o zi calendaristica (an, luna, zi si, optional, ora) intr-un format pe care programul il poate folosi in calcule: cate zile au trecut, cand se implineste un termen. Aici intra Data_Receptie a unei piese sau Data_Expirare_Garantie.
Exemplu complet, dus pana la rezultat:

O piesa este receptionata pe Data_Receptie = 01.01.2026, iar garantia furnizorului este de 90 de zile. Data expirarii se calculeaza adaugand 90 de zile calendaristice: ianuarie are 31 de zile, februarie 2026 are 28 de zile, martie are 31 de zile — 31 + 28 + 31 = 90. Asadar Data_Expirare_Garantie = 01.04.2026 (1 aprilie 2026). In Access, acest calcul se face automat cu functia DateAdd, fara sa numeri manual zilele din fiecare luna: DateAdd("d", 90, [Data_Receptie]) — primul argument ("d") spune ca adaugi zile, al doilea (90) e numarul de zile de adaugat, al treilea e campul cu data de start; functia intoarce direct 01.04.2026.

Cand receptia nu cade pe inceput de luna (tehnica de numarat pe luni):

Cand data de start e la mijlocul lunii, nu mai ai granite de luna "pe gratis" — numeri in doi pasi, luna cu luna. Exemplu: Data_Receptie = 15.03.2026, garantie 100 de zile.
1) Din 15 martie pana la sfarsitul lunii: martie are 31 de zile, deci raman 31 − 15 = 16 zile pana pe 31.03. Din cele 100, mai raman 100 − 16 = 84.
2) Aprilie are 30 de zile: 84 − 30 = 54 ramase, ajungi la 30.04.
3) Mai are 31 de zile: 54 − 31 = 23 ramase, ajungi la 31.05.
4) Cele 23 de zile ramase intra in intregime in iunie: 23 zile de la inceputul lunii inseamna 23.06.2026. Asadar Data_Expirare_Garantie = 23.06.2026. Tehnica, in scurt: scazi din total zilele ramase pana la sfarsitul lunii curente si treci in luna urmatoare, repetand pana cand restul de zile incape intr-o singura luna.

❌ Greseala frecventa: Data este scrisa ca simplu text, iar formatul zi/luna se confunda cu luna/zi: "03.04.2026" poate insemna 3 aprilie sau, in alt format, 4 martie, in functie de setarile calculatorului pe care a fost introdusa.
Cum recunosti: datele din rapoarte par "amestecate" pentru valori sub 12 (zilele si lunile isi schimba locul de la un rand la altul).
Cum repari: foloseste intotdeauna campul de tip Data (nu Text) si verifica formatul de afisare stabilit pentru camp (de exemplu zi.luna.an), astfel incat toate randurile sa fie interpretate la fel.
5

Tipul de date Logic — stari cu doar doua variante

Campul de tip Logic (in Access: Da/Nu / Yes/No) retine o singura informatie cu exact doua stari posibile: adevarat/fals, da/nu. In interfata apare de obicei ca o casuta de bifat (checkbox) — bifat inseamna "da", nebifat inseamna "nu".
Exemplu din atelier:

Campul Piesa_Originala: bifat inseamna ca piesa e originala, fabricata de OEM (Original Equipment Manufacturer — producatorul de echipament original, adica exact specificatia constructorului auto); nebifat inseamna ca e piesa echivalenta, de tip "aftermarket" (piesa compatibila OEM, dar fabricata de alt producator — atentie, in limbajul de atelier "compatibil OEM" e eticheta pe care si-o pun chiar piesele aftermarket, nu piesele originale). La fel, un camp Stoc_Epuizat (Da/Nu) iti da o alerta rapida, fara sa numeri manual fiecare cantitate din tabel.

❌ Greseala frecventa: In loc de camp Logic, cineva foloseste un camp Text in care fiecare scrie liber "da", "Da", "DA" sau "da " (cu spatiu la sfarsit). Pentru program, acestea sunt siruri de caractere diferite.
Cum recunosti: un filtru dupa "da" nu prinde toate randurile care, la ochiul liber, par identice.
Cum repari: schimba campul in tip Logic (Da/Nu), care impune structural doar doua valori posibile, indiferent cine introduce datele.
6

Tipul de date Moneda — preturi de achizitie si vanzare

Campul de tip Moneda (Currency) este construit special pentru valori banesti: pastreaza zecimalele cu precizie fixa si nu acumuleaza erorile mici de rotunjire pe care le poate avea, dupa multe calcule succesive, un camp Numar obisnuit cu zecimale (Single/Double), care lucreaza in virgula mobila — o metoda de stocare aproximativa a numerelor cu zecimale (rapida si folosita pe scara larga), care insa poate acumula mici diferente de rotunjire dupa multe calcule la rand. Campul Moneda evita exact aceasta problema, printr-o stocare cu numar fix de zecimale.
Exemplu complet, dus pana la rezultat:

Ai Cantitate_Stoc = 24 bujii (Numar intreg), cu Pret_Achizitie = 12,35 lei/bucata (Moneda). Valoarea totala a stocului pentru acest tip de piesa:
Valoare_totala = Cantitate_Stoc x Pret_Achizitie = 24 x 12,35 = 296,40 lei.

❌ Greseala frecventa: Preturile sunt tinute intr-un camp Numar cu zecimale (Single) in loc de Moneda. Dupa sute de calcule (adunari, scaderi la fiecare intrare/iesire din stoc), totalul din raport nu se mai potriveste exact cu suma facturilor — diferenta e de 1-2 bani, greu de gasit.
Cum recunosti: totalul calculat de program difera cu cativa bani fata de totalul adunat manual de pe facturi.
Cum repari: schimba tipul campului in Moneda pentru orice valoare baneasca — pret de achizitie, pret de vanzare, valoare totala.
7

Recapitulare — tabelul tipurilor de date

Iata cum arata alegerea tipului de date pentru un tabel real de evidenta a pieselor, Piese_Auto, cu sase campuri:
Structura tabelului Piese_Auto:
CampTip de dateExemplu de valoareDe ce acest tip
Cod_PiesaText scurtAM-0231identificator, poate avea zerouri la inceput
Denumire_PiesaText scurtAmortizor fatasir de caractere, nu se calculeaza
Cantitate_StocNumar intreg24se numara doar in bucati intregi
Pret_AchizitieMoneda12,35 leivaloare baneasca, fara erori de rotunjire
Data_ReceptieData/Ora01.01.2026permite calcule cu date calendaristice
Piesa_OriginalaLogic (Da/Nu)Dadoar doua stari posibile, impuse de camp
Legatura cu lectia urmatoare:

Ai vazut cum se alege tipul de date pentru fiecare camp in parte. In lectia urmatoare vei invata cum se organizeaza aceste campuri intr-un tabel propriu-zis, ce este o inregistrare (un rand), ce este o cheie primara (campul care garanteaza ca fiecare piesa are un identificator unic, fara duplicate) si de ce ai nevoie de un index pentru cautari rapide.

Exercitii practice

Exercitiul 1 (Nivel minim) — Alege tipul de date corect

Pentru fiecare camp de mai jos, scrie tipul de date potrivit (Text, Numar intreg, Numar cu zecimale, Moneda, Data, Logic) si justifica alegerea intr-o propozitie: Cod_Piesa (ex: "00452"), Denumire_Piesa (ex: "Placuta de frana fata"), Cantitate_Stoc (ex: 15 bucati), Pret_Vanzare (ex: 45,50 lei), Data_Ultimei_Comenzi (ex: 20.02.2026), In_Stoc (ex: da/nu).

Vezi rezolvarea

Rezolvare pentru fiecare camp, dupa modelul din lectie:

  1. Cod_Piesa ("00452") este Text. E un identificator cu zerouri la inceput; daca ar fi Numar, zerourile dispar si codul nu se mai potriveste cu factura.
  2. Denumire_Piesa ("Placuta de frana fata") este Text. E un sir de caractere, nu se calculeaza cu el.
  3. Cantitate_Stoc (15 bucati) este Numar intreg. Bucatile intregi nu au sens cu zecimale.
  4. Pret_Vanzare (45,50 lei) este Moneda. E valoare baneasca, cu precizie fixa pe zecimale, fara erorile de rotunjire ale unui camp Numar cu zecimale.
  5. Data_Ultimei_Comenzi (20.02.2026) este Data. Permite calcule cu zile (cate zile au trecut, termene).
  6. In_Stoc (da/nu) este Logic. Are exact doua stari posibile, impuse de tipul campului, nu scrise liber.

Exercitiul 2 (Nivel standard) — Gaseste greselile de tip de date

Un coleg a construit tabelul asa: campul Cod_Piesa e setat ca Numar (a introdus codul "00187" si s-a salvat "187"); campul Cantitate_Stoc e setat ca Text (a introdus "12 buc" si acum nu poate face nicio suma cu acest camp); campul Pret_Achizitie e setat ca Numar cu zecimale (Single) in loc de Moneda; campul Piesa_Verificata e setat ca Text, iar in evidenta apar valorile "da", "Da" si "DA" pe randuri diferite. Pentru fiecare din cele patru campuri: explica exact ce problema va aparea in folosirea de zi cu zi a evidentei si spune care e tipul de date corect.

Vezi rezolvarea

Analiza pe fiecare camp:

  1. Cod_Piesa ca Numar: "00187" devine 187 pentru ca zerourile din fata nu au valoare matematica si dispar. La cautare dupa codul de pe factura ("00187"), evidenta nu il mai gaseste. Tip corect: Text.
  2. Cantitate_Stoc ca Text: valoarea "12 buc" e un sir de caractere, nu un numar, deci Access nu poate face nicio suma sau medie pe acest camp. Tip corect: Numar intreg (fara zecimale, doar bucata cantitatea).
  3. Pret_Achizitie ca Numar cu zecimale (Single): lucreaza in virgula mobila si poate acumula mici erori de rotunjire dupa multe calcule succesive. Tip corect: Moneda, care pastreaza zecimalele cu precizie fixa.
  4. Piesa_Verificata ca Text: cu "da"/"Da"/"DA" scrise liber, o interogare care cauta exact "da" rateaza randurile scrise "Da" sau "DA". Tip corect: Logic (Da/Nu), care impune doar doua stari posibile, indiferent cum scrie fiecare persoana.

Exercitiul 3 (Nivel performanta) — Comanda de placute de frana

Atelierul primeste o factura de la furnizor: 18 seturi de placute de frana, la 84,75 lei/set. Codul de catalog al furnizorului este AB-00073 (cele doua zerouri fac parte din cod). Data receptiei este 10.06.2026, iar garantia furnizorului este de 180 de zile. Rezolva: a) calculeaza valoarea totala a comenzii (scrie calculul complet); b) calculeaza data exacta la care expira garantia, aratand cum ai numarat zilele pe luni; c) propune structura tabelului Comenzi_Piese cu minimum sase campuri, indicand tipul de date exact pentru fiecare (dupa modelul din lectie), si justifica in mod special alegerea de tip pentru codul AB-00073 si pentru pret.

Vezi rezolvarea

a) Valoare totala: 18 seturi x 84,75 lei = 1525,50 lei.

b) Expirare garantie: 10.06.2026 + 180 zile. Zile ramase in iunie: 20; iulie 31 (total 51); august 31 (82); septembrie 30 (112); octombrie 31 (143); noiembrie 30 (173); mai raman 7 zile in decembrie, deci expira pe 07.12.2026. In Access se face automat cu DateAdd("d", 180, [Data_Receptie]), fara numarat manual.

c) Structura Comenzi_Piese (schita, nu tabel gata facut): alege minimum 6 campuri dupa modelul Piese_Auto din lectie — de exemplu ID_Comanda (cheie), Cod_Piesa, Cantitate, Pret_Unitar, Data_Receptie, Zile_Garantie/Data_Expirare. Justifica fiecare tip: Cod_Piesa (AB-00073) trebuie Text, pentru ca cele doua zerouri sunt parte din identificator si un camp Numar le-ar sterge; Pret_Unitar trebuie Moneda, nu Numar cu zecimale, ca sa nu acumuleze erori de rotunjire pe seturi multiple. Criterii de evaluare: fiecare tip justificat explicit, calculul de la a) si b) corect, minimum 6 campuri coerente cu exemplul din lectie.

Ce ai invatat astazi

  • O baza de date impune un tip de date fix per camp si poate lega mai multe tabele, spre deosebire de o foaie de calcul libera
  • Text (Text scurt) — pentru coduri, denumiri, orice sir care nu se calculeaza; pastreaza zerourile din fata unui cod
  • Numar intreg — pentru cantitati numarate in bucati; Numar cu zecimale — pentru masuratori (greutate, capacitate)
  • Data/Ora — pentru receptii si termene, permite calcule automate cu zile calendaristice (ex. DateAdd)
  • Logic (Da/Nu) — pentru stari cu exact doua variante, impuse structural de camp, fara variatii de scriere
  • Moneda (Currency) — pentru preturi, cu precizie fixa pe zecimale, fara erorile de rotunjire ale unui camp Numar obisnuit
  • Greseala cea mai frecventa: alegerea unui tip "aproape potrivit" (Numar in loc de Text, Text in loc de Logic) care pare sa functioneze pana cand evidenta creste

Vrei mai mult?

Provocare: Deschide tabelul Piese_Auto din lectie (sau construieste-l in Access) si adauga un camp nou, Cod_Bare, tip Text scurt, cu valoarea "00734521". Introdu apoi un rand in care scrii Cantitate_Stoc ca 3,5 (desi campul e Numar intreg) si noteaza exact ce mesaj de eroare da Access la salvare.

  • Intrebare: Daca schimbi in Design View un camp deja plin de date din Numar in Text, valorile care si-au pierdut zerourile din fata (452) nu redevin automat "00452". De ce Access nu poate reconstitui, doar din schimbarea tipului, o informatie disparuta deja la prima salvare?

Deschidere: Acelasi motiv face ca un numar de telefon sau un cod postal sa fie pastrate tot ca Text intr-o baza de date reala: sunt identificatori, nu cantitati de calculat. Orice sistem de gestiune (stocuri, clienti, elevi) aplica aceeasi regula la fiecare camp nou pe care il proiecteaza.

Urmatoarea lectie

Continua cu Structura bazei: tabel, inregistrare, camp, cheie primara, index — cum organizezi campurile din aceasta lectie intr-un tabel real, ce e o inregistrare si de ce ai nevoie de o cheie primara care sa nu accepte duplicate.

Continua →