From b59e3493dffa9bc027852bba695be08c0511b6ea Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Agnieszka=20G=C4=85bka-Buszek?= Date: Sat, 16 Dec 2023 10:14:53 +0100 Subject: [PATCH 1/4] zmieniono dla customer --- model_hurtowni.sql | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/model_hurtowni.sql b/model_hurtowni.sql index 7b29d20..6d5e13c 100644 --- a/model_hurtowni.sql +++ b/model_hurtowni.sql @@ -9,12 +9,10 @@ CREATE TABLE `fact_service` ( CREATE TABLE `dim_customer` ( `customer_id` int PRIMARY KEY, - `first_name` varchar(64) , - `last_name` varchar(64) , + `name` varchar(64) , `birth_date` DATE , `email` varchar(64) , `address` varchar(64) , - `address2` varchar(64) , `city` varchar(64) , `country` varchar(64) , `postal_code` varchar(64) From 218a2081c125c46c82af119852b13991444d10a4 Mon Sep 17 00:00:00 2001 From: Wojciech Borowski-Dobrowolski Date: Sat, 16 Dec 2023 10:16:46 +0100 Subject: [PATCH 2/4] Uwagi do pierwotnego modelu od Ilii --- komentarz_grupa_3.txt | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 komentarz_grupa_3.txt diff --git a/komentarz_grupa_3.txt b/komentarz_grupa_3.txt new file mode 100644 index 0000000..14e5ea5 --- /dev/null +++ b/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. From 8680a85e5ac55b07c3a1f8ea8fb56dbf275669f7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Charzewski?= Date: Sat, 16 Dec 2023 10:20:32 +0100 Subject: [PATCH 3/4] zmiany dla staff --- model_hurtowni.sql | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/model_hurtowni.sql b/model_hurtowni.sql index af446f1..af2f6ea 100644 --- a/model_hurtowni.sql +++ b/model_hurtowni.sql @@ -79,12 +79,11 @@ CREATE TABLE `dim_service_type` ( CREATE TABLE `dim_staff` ( `staff_id` int PRIMARY KEY, - `full_name` varchar(64) , - `address` varchar(64) , - `city` varchar(64) , - `country` varchar(64) , - `manager_id` int , - `email` varchar(64) + `staff_full_name` varchar(64) , + `staff_address` varchar(64) , + `staff_city` varchar(64) , + `staff_country` varchar(64) , + `staff_email` varchar(64) ); CREATE TABLE `dim_car` ( From 736e7912f6d19500b2d84f816798af17e0728cfd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Charzewski?= Date: Sat, 16 Dec 2023 10:26:49 +0100 Subject: [PATCH 4/4] dim staff zmiany --- model_hurtowni.sql | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/model_hurtowni.sql b/model_hurtowni.sql index af2f6ea..079af09 100644 --- a/model_hurtowni.sql +++ b/model_hurtowni.sql @@ -83,7 +83,8 @@ CREATE TABLE `dim_staff` ( `staff_address` varchar(64) , `staff_city` varchar(64) , `staff_country` varchar(64) , - `staff_email` varchar(64) + `staff_email` varchar(64) , + `staff_manager_name` varchar(64) ); CREATE TABLE `dim_car` (