Grunwaldzka Bistro — rezerwacja stolików
System rezerwacji stolików z blokadą podwójnej rezerwacji tego samego terminu.
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 rezerwacji stolików, jakiego naprawdę używa restauracja: gość wybiera termin i liczbę osób, a program dobiera wolny stolik i pilnuje, żeby ten sam stolik nie został zarezerwowany dwa razy na tę samą godzinę. Projekt bliski zadaniu INF.03, tylko większy i rozłożony na czterech.
Co budujemy
- zarządzanie stolikami (numer, liczba miejsc, lokalizacja: sala / taras),
- rejestracja gości (imię, nazwisko, telefon),
- przyjmowanie rezerwacji na termin (data, godzina, liczba osób) z przypisaniem wolnego stolika,
- blokada kolizji — nie da się zarezerwować zajętego stolika na ten sam termin,
- grafik dnia: które stoliki i o której są zajęte,
- odwołanie rezerwacji zwalniające stolik.
Struktura danych
Goscie 1 ────< Rezerwacje >──── 1 Stoliki Stoliki(id, numer, liczba_miejsc, lokalizacja) Goscie(id, imie, nazwisko, telefon) Rezerwacje(id, stolik_id →, gosc_id →, data, godzina, liczba_osob, status) status: aktywna / odwolana REGUŁA: (stolik_id, data, godzina) niepowtarzalne dla rezerwacji aktywnej
Kontekst z życia
Każda restauracja z rezerwacjami mierzy się z tym samym problemem: nie wpuścić dwóch grup do jednego stolika o tej samej godzinie. To dokładnie ta „blokada podwójnej rezerwacji", którą tu zaprogramujecie — realna reguła biznesowa, nie szkolna wydmuszka.
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 bistro.sql (3–4 tabele + klucze obce), dane testowe (min. 8 stolików, 10 gości, 12 rezerwacji), zapytania: grafik dnia, wolne stoliki na termin, historia gościa |
| Programista interfejsu (UI) | widoki: lista stolików, formularz rezerwacji (wybór terminu i liczby osób), grafik dnia z zajętością, panel odwołań |
| Programista logiki / tester | przyjmowanie rezerwacji z kontrolą kolizji terminu, walidacja (liczba osób ≤ miejsc), odwoływanie, testy (m.in. próba podwójnej rezerwacji) |
Harmonogram
| Tydzień | Kamień milowy |
|---|---|
| 1 | Analiza i projekt: zakres, diagram danych, podział zadań, harmonogram |
| 2 | Baza z danymi testowymi działa; szkielet aplikacji utworzony |
| 3 | Interfejs pokazuje stoliki i grafik z bazy |
| 4 | Rezerwacja z blokadą kolizji + 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):
- poprawne tabele z sensownymi typami danych (1)
- klucze główne we wszystkich tabelach (1)
- klucze obce łączą rezerwacje ze stolikami i gośćmi (2)
- dane testowe: min. 8 stolików, 10 gości, 12 rezerwacji (1)
- zapytanie „grafik dnia" działa (2)
- zapytanie „wolne stoliki na termin" działa (2)
- nazwy tabel i kolumn znaczące i spójne (1)
Programista logiki / tester (0–10 pkt):
- rezerwacja zapisuje się z poprawnym stolikiem i terminem (2)
- podwójna rezerwacja tego samego stolika na ten sam termin jest blokowana (3)
- walidacja: liczba osób ≤ liczba miejsc (2)
- odwołanie zwalnia stolik (1)
- spisane wyniki testów, w tym test kolizji (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.
W tym projekcie szczególnie: pominięcie kontroli kolizji terminu — bez niej system „działa", ale wpuszcza dwie grupy do jednego stolika.
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.