Proiect de atestat în Access: schema, obiectele aplicației și ce te întreabă comisia

Proiectul cu bază de date e cea mai apropiată temă de ce certifică efectiv atestatul. Se suprapune peste subiectul I de la proba practică, iar motivația se scrie singură: normalizare, chei străine, integritatea datelor. E și cea mai frecventă alegere — deci diferența n-o face ideea, ci schema și felul în care o justifici.

Pagina asta e despre partea care se notează: proiectarea, nu clickurile din interfață.

Dacă încă alegi între tehnologii, pornește de la cum îți alegi tema de proiect. Cadrul general al examenului e în ghidul atestatului.

Pentru cine e potrivit

Un proiect în Access merge dacă:

• tema ta are entități care se leagă — cititori și împrumuturi, pacienți și consultații, mașini și reparații;
• vrei să petreci timpul pe modelul de date, nu pe CSS și layout;
• îți convine o aplicație care rulează local, fără server și fără instalare complicată.

Nu merge dacă tema e în esență un site de prezentare, sau dacă vrei să demonstrezi algoritmi. Pentru prima variantă e mai potrivit un proiect în HTML, CSS și JavaScript.

Capcana numărul unu: un tabel și un formular nu sunt o bază de date

Un proiect cu un singur tabel nu demonstrează nimic din ce certifică atestatul. Fără a doua entitate nu există relație, fără relație nu există cheie străină, fără cheie străină nu ai ce justifica — și exact justificarea se notează.

Nivel	Ce conține	Cum e primit
Un tabel, un formular	Listă de înregistrări	Insuficient
2 tabele legate	O relație, câteva interogări	Minim acceptabil
3–5 tabele, relații corecte, interogări cu JOIN și agregare, rapoarte	Model de date real	Ținta
Plus validări, VBA, meniu de navigare	Aplicație închegată	Peste așteptări

Ținta rezonabilă e rândul al treilea. Peste el se trece doar dacă îți rămâne timp după documentație — nu înainte de ea.

Schema: partea care decide nota

Proiectarea se face pe hârtie, înainte să deschizi Access. Trei întrebări, în ordine:

1. Ce entități există? Substantivele din descrierea temei: cititor, carte, împrumut.
2. Cum se leagă? Un cititor are mai multe împrumuturi; o carte apare în mai multe împrumuturi.
3. Ce se repetă? Orice dată care s-ar scrie de două ori identic aparține altui tabel.

Un exemplu concret, pentru o bibliotecă școlară:

CITITORI(id_cititor, nume, clasa, telefon)
CARTI(id_carte, titlu, autor, an_aparitie, exemplare)
IMPRUMUTURI(id_imprumut, id_cititor→CITITORI, id_carte→CARTI, data_imprumut, data_returnare)

Relația mai mulți la mai mulți dintre cititori și cărți e rezolvată prin tabelul IMPRUMUTURI. Asta e exact decizia de proiectare pe care o cauți: nu se poate lega direct, deci apare un al treilea tabel care ține legătura plus datele proprii ale împrumutului.

De ce nu un singur tabel — răspunsul pe care trebuie să-l ai pregătit: dacă titlul cărții ar sta pe fiecare rând de împrumut, s-ar scrie de o sută de ori; corectarea unei greșeli de tipar ar cere o sută de modificări, iar o singură omisiune ar lăsa baza cu două titluri pentru aceeași carte. Asta e redundanța pe care o elimină normalizarea, spusă în cuvinte, nu în definiții memorate.

În Access, relațiile se creează în fereastra Relationships, cu Enforce Referential Integrity bifat. Bifa aia e ce împiedică un împrumut către un cititor care nu există — și e prima lucru pe care îl verifică un evaluator care știe ce caută.

Obiectele aplicației

Access nu e doar tabele. Un proiect complet folosește patru tipuri de obiecte:

• Tabele — structura și datele. Tipuri de date potrivite, chei primare, câmpuri obligatorii.
• Interogări — filtrări, JOIN-uri, totaluri. Aici se vede dacă înțelegi SQL, nu doar interfața. Scrie-le în SQL View, nu doar din Query Design.
• Formulare — adăugare și editare. Un formular principal cu subformular (cititorul cu împrumuturile lui) demonstrează relația vizual, în două secunde.
• Rapoarte — ieșirea tipăribilă: situația împrumuturilor restante, grupată și totalizată.

Un meniu de navigare care leagă totul, plus câteva validări pe câmpuri, transformă colecția de obiecte într-o aplicație. Fără el, evaluatorul deschide obiectele din panoul din stânga — și se vede.

SQL-ul din Access nu e identic cu cel din teorie

Diferența asta prinde pe picior greșit pe toată lumea care a exersat pe interogări SQL și apoi deschide Access:

Standard	În Access
LIKE 'A%'	LIKE "A*" — metacaractere * și ?, nu % și _
LIMIT 5	SELECT TOP 5 ...
|| sau CONCAT()	& pentru concatenare
CURRENT_DATE	Date(), iar Now() include și ora
JOIN a JOIN b	parantezele sunt obligatorii la trei tabele sau mai multe

Ultimul punct e cel care dă erori greu de citit. La trei tabele, Access cere:

SELECT c.nume, ca.titlu, i.data_imprumut
FROM (IMPRUMUTURI AS i
      INNER JOIN CITITORI AS c ON i.id_cititor = c.id_cititor)
      INNER JOIN CARTI AS ca ON i.id_carte = ca.id_carte;

Restul — WHERE, GROUP BY, ORDER BY, funcțiile de agregare — funcționează la fel ca în teoria de baze de date. Tehnicile sunt aceleași, doar dialectul diferă.

Planul pe luni

Termenul de depunere e 1 mai, cu referatul profesorului îndrumător. Înapoi de la data aia:

Când	Ce faci
Decembrie	Alegi tema, o discuți cu profesorul. Scrii pe hârtie entitățile și relațiile
Ianuarie	Tabelele, tipurile de date, relațiile cu integritate referențială. Date de test
Februarie	Interogările și rapoartele — partea care se notează tehnic
Martie	Formulare, subformular, meniu de navigare, validări
Aprilie	Documentația și repetiția prezentării
1 mai	Depunere

Introdu datele de test din ianuarie, nu la final. O bază cu trei înregistrări nu arată nimic la prezentare: interogările cu grupare ies goale, rapoartele ies pe o pagină albă, iar tu nu descoperi că relația e greșită. Douăzeci-treizeci de înregistrări realiste pe tabel sunt suficiente.

Ce te întreabă comisia

Întrebările sunt previzibile, pentru că decurg din schemă. Scrie-ți răspunsurile în documentație înainte să le spui cu voce tare:

„De ce ai împărțit datele în tabelele astea și nu altfel?” Întrebarea centrală. Răspunsul pornește de la ce s-ar repeta dacă n-ai împărți.

„Ce e cheia primară și ce e cheia străină în proiectul tău?” Nu definiția din manual — arată-le în schema ta, pe tabelele tale.

„Ce se întâmplă dacă șterg un cititor care are împrumuturi?” Aici se vede dacă integritatea referențială e doar bifată sau înțeleasă. Răspunsul corect explică ce ai ales: blocarea ștergerii, sau ștergerea în cascadă, și de ce.

„Arată-mi o interogare mai complicată și explică-mi-o.” Alege dinainte una cu JOIN și GROUP BY și repet-o. Treizeci de secunde de ezitare aici costă mai mult decât orice buton lipsă.

„Ce ai face altfel dacă ai lua-o de la capăt?” O limitare reală a aplicației tale, spusă concret, valorează mai mult decât „nimic”.

Cum decurge proba și ce înseamnă motivarea teoretică: prezentarea proiectului în fața comisiei.

Greșeli frecvente

• Un singur tabel mare. Fără relații n-ai ce demonstra și n-ai ce justifica.
• Relații desenate fără integritate referențială. Linia există, dar baza acceptă un împrumut către un cititor inexistent. Se verifică în treizeci de secunde.
• Chei primare de tip text. Numele ca și cheie primară pică la primul omonim. Folosește un identificator numeric.
• Tipuri de date greșite. Telefon și CNP se țin ca text, nu ca număr — încep cu zero, nu se adună și nu se împart. Aceeași capcană ca la subiectul I de la proba practică.
• Bază aproape goală. Trei înregistrări nu produc niciun raport convingător.
• Interogări făcute doar din Query Design. Dacă nu poți arăta SQL-ul și explica ce face, nu se notează ca înțelegere.
• Fără niciun raport. Raportul e singura ieșire tipăribilă și cel mai ușor punct de luat.
• Fișierul nu se deschide pe alt calculator. Salvează .accdb, testează pe alt PC și adu o copie pe stick și una în cloud.
• Documentația fără diagrama relațiilor. E singura imagine pe care o caută toți evaluatorii.

Dacă nu ai Access

Licența lipsește destul de des. Alternativele se acceptă aproape peste tot, cu condiția să spui în documentație de ce ai ales altceva:

• LibreOffice Base — gratuit, aceleași concepte, aceeași fereastră de relații;
• MySQL cu phpMyAdmin sau SQLite cu DB Browser — dacă te interesează SQL-ul standard mai mult decât interfața vizuală;
• PHP + MySQL, dacă vrei aplicație web peste baza de date — altă temă, pe care o tratez separat.

Conceptele pe care le notează comisia — entități, relații, normalizare, integritate — sunt identice în toate. Doar interfața și dialectul SQL diferă.

Ce livrezi

Trei lucruri, nu unul:

1. Aplicația — fișierul bazei de date, cu datele de test înăuntru;
2. Documentația — cu diagrama relațiilor și justificarea schemei;
3. Prezentarea — maximum 30 de minute, în care explici de ce ai proiectat așa.

Pentru partea de SQL, teoria e în baze de date și SQL și în interogări SQL, cu probleme rezolvate din examenele reale.

Întrebări frecvente

Câte tabele trebuie să aibă proiectul de atestat în Access? Nu există un număr impus de metodologie. Practic, sub două tabele nu ai nicio relație de justificat, iar trei-cinci tabele legate corect sunt suficiente pentru orice temă de liceu. Contează ca relațiile să fie corecte, nu ca tabelele să fie multe.

Pot folosi altceva în loc de Access? Da. LibreOffice Base, MySQL cu phpMyAdmin sau SQLite acoperă aceleași concepte. Regula o stabilește catedra liceului tău, iar alegerea se justifică în documentație.

Trebuie să știu VBA pentru atestat? Nu. Un proiect cu tabele, relații, interogări, formulare și rapoarte e complet fără nicio linie de VBA. Codul e un plus, nu o cerință.

De ce nu merge interogarea mea copiată din alt tutorial? Access are un dialect SQL ușor diferit: * și ? la LIKE în loc de % și _, TOP în loc de LIMIT, & pentru concatenare și paranteze obligatorii la trei sau mai multe tabele în JOIN.

Ce înseamnă integritate referențială? Regula prin care baza refuză o înregistrare care trimite spre ceva inexistent — de exemplu un împrumut către un cititor care nu e în tabelul de cititori. În Access se activează din fereastra Relationships.

Câte înregistrări de test trebuie să introduc? Douăzeci-treizeci pe tabel sunt suficiente. Cu mai puține, interogările cu grupare și rapoartele nu produc nimic vizibil la prezentare.

Se poate folosi același proiect ca la proba practică? Nu sunt același lucru. Proba practică e biletul cu trei subiecte rezolvate pe loc, iar proiectul e lucrarea depusă până la 1 mai. Se aseamănă ca materie, dar se notează separat.

De unde vin informațiile de aici

Cerința ca proiectul să fie un produs software însoțit de prezentarea și motivarea teoretică, termenul de depunere de 1 mai și referatul profesorului îndrumător finalizat cu admis sau respins sunt din Metodologia de organizare și desfășurare a examenului de atestare a competențelor profesionale ale absolvenților claselor de matematică-informatică și matematică-informatică, intensiv informatică, aprobată prin OMECI nr. 4.843/2009 și modificată prin OM nr. 3.009/2021.

Numărul de tabele, tehnologiile permise, nivelul tehnic așteptat și criteriile de notare nu sunt prevăzute în metodologie — se stabilesc de catedra de specialitate a liceului tău. Recomandările de aici sunt un punct de plecare pentru cazul în care nu ți s-a impus un format. Verifică întotdeauna cerința profesorului îndrumător.