Uwagi do pierwotnego modelu od Ilii

komentarz_grupa_3.txt

@@ -0,0 +1,35 @@
+uwagi ogólne:
+- brak konsekwencji w formułowaniu nazw: raz jest liczba mnoga (fact_rentals, dim_cars), a raz pojedyńcza (dim_store, fact_service)
+- dla naszych potrzeb relacja między fact_service, a dim_store nie jest konieczna, ale nie jest to błąd, więc można zostawić. Zresztą DataBricks i tak nie obsługuje kluczy obcych.
+
+fact_rentals
+- rental_id powinno mieć inną nazwę - ta jest zbyt podobna do nazw kluczy zastępczych z hurtowni, a przecież nie jest sama kluczem zastępczym. Ewentualnie możnaby zmienić konwencję nazywanie kluczy zastępczych a zostawić rental_id i inne identyfikatory źródłowe nietknięte.
+- Dlaczego equipment_hash ma przyrostek FK, a inne klucze obce nie? Brak spójności utrudnia pracę użytkownikom naszego produktu.
+- brakuje długości wypożyczenia, kwoty zapłaconej oraz miary opóźnienia zapłaty względem terminu płatności. To trzeba dodać inaczej będziecie mieli problem ze spełnieniem wymagań na raportowaniu.
+
+bridge_equipment
+- id_FK nie dość że jest bardzo wieloznaczne, to jeszcze nie widać po nim powiązania z dim_equipment.equipment_id. Warto aby klucze obce jeśli nie są identyczne ze swoimi polami relacji, to przynajmniej miały jakieś części wspólne.
+- Czy equipment_hash_DK na pewno będzie typu int? To szczegół, ale zastanówcie się, żeby było Wam łatwiej zrozumieć implementację: jakiej funkcji skrótu użyjecie? niektóre zwracają tylko bigint, inne tylko tekst, lub dane binarne.
+- Brakuje tabeli grupującej wyposażenie (osobna tabela equipment_group, lub użycie dim_inventory w tej roli). Bez tabeli grupującej nie dacie rady utrzymać relacji wiele do jednego między faktem a tabelą bridge. Lub naprawiając to sprawicie, że tabela pomostowa będzie miała więcej wierszy niż tabela faktu, co niesie ze sobą kilka sporych rodzajów ryzyka np. pisanie zapytań analitycznych jest skomplikowane, niektóre narzędzia analityczne gubią się budując swoje relacje, trzeba optymalizować przechowywanie dancyh pomostu zamiast faktu (może nie w DataBricks, ale w tradycyjnych hurtowniach pewnie tak)
+
+dim_staff
+- first_name i last_name powinny być jednym polem. Chcemy statystyki osób, a nie wszystkich o nazwisku Nowak.
+- address i address2 powinny być złączone. systemy transakcyjne czasem mają dwa pola na adres, żeby pomieścić dłuższe adresy, ale w hurtowni, zwłaszcza z użyciem data bricks to ograniczenie nas nie dotyczy.
+- nie ma id z systemu żródłowego - bez tego nie zrobicie ładowania przyrostowego (trzeba mieć dane według których identyfikujemy które wiersze w źródle są nowe, a które już załadowaliśmy)
+- manager_id nie wystarczy - potrzeba manager_name zamiast tego, albo w dodatku do tego.
+
+dim_customer
+- first_name i last_name jak wyżej
+- address i address2 jak wyżej
+
+dim_store
+- (store) address i address2 jak wyżej
+- nazwy kluczy: biznesowego i zastępczego mogłyby być czytelniejsze.
+- store_manager_start/end_date sugeruje, że jest to raczej SCD4 (jeśli się nie mylę), gdzie zakładamy, że różne kolumny, lub grupy kolumn będą podlegać zmianom w różnym tempie i chcemy śledzić zmiany osobno. Nie uważam tego za błąd, tylko chciałem zaznaczyć gwoli pełniejszej informacji.
+
+dim_calendar
+- nazwę month_end mozna odczytać jako data końca miesiąca. Lepiej nazwać to pole is_month_end
+
+dim_cars
+- co znajdzie się w polu availability?
+- sell/purchase price nie są w zasadzie błędami, ale jesli mają służyć jako kategorie analizy, to może warto wydzielić mini-wymiar z kubełkami cenowymi samochodów i tam grupować nasze auta? Taki mini-wymiar uzgodniony z analityką powinien znacznie ułatwić im pracę. Jeśli zaś chcemy liczyc zysk/stratę ze sprzedaży samochodu, to powinniśmy zastanowić sie nad nową tabelą faktu.