Stwórz narzędzie (wyłącznie backend) dla kupca w dużej firmie handlowej. Kupiec handluje wieloma towarami różnych typów (różne rodzaje monitorów, procesorów itp.). Każdy typ towaru (np. procesor, monitor) ma swoją specyfikację - nie więcej niż 1000 różnych parametrów opisujących go. Niektóre parametry są wspólne pomiędzy wieloma typami (np. cena, długość gwarancji). Każdy towar może mieć wielu dostawców jednak ten sam towar (np. konkretny model procesora) jest identyczny u każdego dostawcy. Kupiec składa zamówienia porównując specyfikację towarów w obrębie typu towaru, czasem analizuje również dane grupując towary po ich typie.

Parametry mogą mieć następujące rodzaje:

  • parametry sortable (liczby lub napisy)
  • parametry enum, przyjmujące wartość z ustalonego zbioru wartości.

Twój program powinien posiadać następujące funkcjonalności:

  • definiowanie nowych parametrów z rodzajami,
  • konserwatywne redefiniowanie parametrów: rozszerzanie zbioru dopuszczalnych wartości parametru.
  • definiowanie i modyfikowanie typów towarów,
  • dodawanie, modyfikowanie i usuwanie towarów,
  • porównywanie i filtrowanie towarów wg dowolnych kombinacji parametrów - porównywanie rosnąco i malejąco wg parametrów, filtrowanie za pomocą operatorów =, <=, >= (dla sortable) lub wg równości z wykorzystanie stałych z wejścia lub wartości ze aktualnych statystyk (średnia, maksymalna i minimalna wartość danego parametru dla danego typu towaru w bazie).
  • porównywanie i filtrowanie jak wyżej ale z agregacją i grupowaniem wg typu towaru.

Twój program będzie uruchamiany wielokrotnie - za każdym razem po uruchomieniu powinien wczytać ze standardowego wejścia obiekt JSON  zawierający specyfikację tego co należy zrobić (np. zdefiniowanie nowego parametru o określonej nazwie, określonego rodzaju, w przypadku rodzaju enum z wyliczeniem zbioru możliwych wartości i innych koniecznych informacji). Wynikiem działania powinien być wypisany na standardowym wyjściu obiekt JSON zawierający odpowiednie informacje - komunikat o wprowadzeniu zmian w bazie albo wynik zapytania (np. listę przefiltrowanych i uporządkowanych towarów). Zaproponuj specyfikację formatu obiektów JSON dla każdej funkcjonalności.

Pomiędzy kolejnymi uruchomieniami dane powinny być przechowywane w relacyjnej bazie danych. Użyj PostgreSQL, język programowania dowolny.

Załóż, ze pliki z wejściem są już zweryfikowane pod kątem poprawności i bezpieczeństwa danych, weź też pod uwagę, że każde uruchomienie może wprowadzić masywne zmiany zarówno na poziomie danych (towary) jak i meta-danych (parametry). Przetestuj działanie swojej aplikacji przed spotkaniem zaliczeniowym.

Przygotuj model konceptualny i fizyczny bazy i zademonstruj go prowadzącemu ćwiczenia.

Co będzie oceniane?

  • Model konceptualny - powinien składać się z diagramu E-R (lub UML) oraz ew. komentarza zawierającego więzy pominięte w diagramie (20% punktacji).
  • Model fizyczny - powinien być plikiem sql nadającym się do czytania (i oceny) przez człowieka. Powinien zawierać definicję wszystkich tabel, więzów, indeksów, kluczy, akcji referencyjnych, funkcji, perspektyw i wyzwalaczy. Nie jest niezbędne wykorzystanie wszystkich tych udogodnień, ale tam, gdzie pasują, powinny być wykorzystywane (20% punktacji).
  • Program - oceniany będzie kod źródłowy oraz poprawność i efektywność działania (60% punktacji). Ocenie podlegają pliki źródłowe programu, model konceptualny w pliku pdf oraz model fizyczny w pliku sql.

Aby uzyskać ocenę projektu należy się umówić na rozmowę z prowadzącym ćwiczenia (linki do umawiania terminów pojawią się tutaj poniżej).

11.06:  Projekty są indywidualne. Można będzie dostać punkty za oddanie zestawu: oba modele - konceptualny + fizyczny, ale z karą 50%, tj. oba modele bez poprawnie działającego programu ocena do 20%, a z programem -  modele 40% + program 60%.

Ostatnia modyfikacja: sobota, 11 czerwca 2022, 14:57