Biblioteka szkolna
Ewidencja książek, czytelników i wypożyczeń z naliczaniem kar — najbliższy realnym zadaniom INF.03.
Technologie: WPF lub PHP + MySQL
⬇ Pobierz bazę startową (.sql.gz)Uwaga przed importem: plik z bazą jest spakowany jako .gz. phpMyAdmin w XAMPP przyjmuje takie pliki bez rozpakowywania. Jeżeli po pobraniu nazwa wygląda np. bistro.sql_.gz i import nie przejdzie, zmień nazwę pliku na bistro.sql.gz, a potem wybierz go w zakładce Importuj.
Po co ten projekt
Zbudujecie system biblioteczny: ewidencja książek, rejestracja wypożyczeń i zwrotów, naliczanie kar za przetrzymanie. To najbardziej „egzaminacyjny" z projektów bazodanowych — praktycznie gotowe zadanie z części praktycznej INF.03.
Co budujemy
- zarządzanie książkami (tytuł, autor, ISBN, rok, liczba egzemplarzy),
- rejestracja czytelników (imię, nazwisko, klasa, numer karty),
- wypożyczenie i zwrot z terminem oddania,
- naliczanie kary za dzień zwłoki,
- lista książek wypożyczonych i czytelników z zaległościami.
Struktura danych
Czytelnicy 1 ────< Wypozyczenia >──── 1 Ksiazki
│
└───< Kary
Ksiazki(id, tytul, autor, isbn, rok, liczba_egz)
Czytelnicy(id, imie, nazwisko, klasa, nr_karty)
Wypozyczenia(id, ksiazka_id →, czytelnik_id →, data_wyp, termin_zwrotu, data_zwrotu)
Kary(id, wypozyczenie_id →, kwota, oplacona)Kontekst z życia
Wasza biblioteka szkolna działa dokładnie tak: skanuje kartę, zapisuje wypożyczenie, przypomina o terminie, nalicza karę. Budujecie system, który znacie z drugiej strony lady.
Podział obowiązków
| Rola | Konkretne zadania w tym projekcie |
|---|---|
| Lider / analityk | ustala zakres, rysuje diagram danych, zakłada tablicę w Trello, pilnuje terminów, pisze dokumentację (instrukcja użytkownika + opis bazy), przygotowuje i prowadzi prezentację, scala pracę zespołu (Git / wspólny dysk) |
| Projektant bazy danych | skrypt biblioteka.sql (4 tabele + klucze obce), dane testowe (min. 15 książek, 10 czytelników, 8 wypożyczeń), zapytania: książki dostępne, czytelnicy z zaległościami, suma kar czytelnika |
| Programista interfejsu (UI) | widoki: lista książek, lista czytelników, formularz wypożyczenia, panel zaległości |
| Programista logiki / tester | wypożyczanie/zwrot, naliczanie kary wg dni zwłoki, walidacja (nie wypożyczysz niedostępnej książki), testy |
Harmonogram
| Tydzień | Kamień milowy |
|---|---|
| 1 | Analiza i projekt: zakres, diagram danych, podział zadań, harmonogram |
| 2 | Baza z danymi testowymi działa |
| 3 | Interfejs pokazuje książki i czytelników z bazy |
| 4 | Wypożyczenie/zwrot + kara + testy |
| 5 | Scalenie, poprawki, dokumentacja, prezentacja przed klasą |
Kryteria oceny
Każdy uczeń dostaje ocenę indywidualną za swoją rolę (kryteria zero-jedynkowe) plus wspólny bonus zespołowy. Proporcja: 70% rola + 30% zespół.
Projektant bazy danych (0–10 pkt):
- 4 tabele z poprawnymi typami (1)
- klucze główne wszędzie (1)
- klucze obce łączą wypożyczenia z książkami i czytelnikami (2)
- dane testowe: min. 15 książek, 10 czytelników, 8 wypożyczeń (1)
- zapytanie „czytelnicy z zaległościami" (2)
- zapytanie „suma kar czytelnika" (2)
- nazewnictwo spójne (1)
Programista logiki / tester (0–10 pkt):
- wypożyczenie zmniejsza liczbę dostępnych egzemplarzy (2)
- kara nalicza się poprawnie wg dni zwłoki (3)
- walidacja dostępności książki (2)
- zwrot w terminie bez kary (1)
- spisane wyniki testów (2)
Analogiczne zestawy kryteriów obowiązują Lidera (dokumentacja, harmonogram, prezentacja, scalanie) oraz Programistę UI (kompletność widoków, czytelność, połączenie z bazą, walidacja formularzy).
Ocena zespołowa (0–10 pkt):
- aplikacja uruchamia się i działa jako całość (3)
- części zespołu są zintegrowane, nie luźne kawałki (3)
- prezentacja jasno pokazuje działanie i podział pracy (2)
- dokumentacja kompletna: instrukcja + opis bazy (2)
Typowe błędy w pracy zespołowej
- brak wspólnego miejsca na kod → wersje się rozjeżdżają; ustalcie od razu Git albo jeden dysk,
- „zrobimy wszystko na końcu" → kamienie milowe są po to, żeby tego uniknąć,
- każdy pisze w swoim stylu → uzgodnijcie nazewnictwo tabel i zmiennych na starcie,
- nikt nie testuje integracji → tester wchodzi już w 4. tygodniu, nie na końcu.
Nawiązanie do egzaminu
Ten projekt to w praktyce rozbudowane zadanie z części praktycznej INF.03 (baza danych + aplikacja operująca na danych, z regułą biznesową). Rozdzielając role, każdy z Was ćwiczy inny fragment tego, co na egzaminie trzeba umieć samodzielnie — a przy okazji uczycie się pracy zespołowej, którą sprawdza się i na maturze, i w prawdziwej firmie.