Projekt bazy danych dla sklepu z książkami

pytanie zadane 21 października 2019 w SQL, bazy danych przez Kamilu01 Nowicjusz (120 p.)
edycja 21 października 2019 przez Kamilu01

Witam,
bardzo proszę o sprawdzenie przedstawionego projektu. Mam wątpliwości co do odpowiedniego połączenia relacjami, szczególnie w przypadku "zamowien" oraz "faktur". Czy kolumny dotyczące cen powinny się znaleźć zarówno w tabeli "ksiazka", "pozycjeFaktury", jak u "faktura"?

Link do zdjęcia: https://tinypic.pl/8jw7vu2nk9qf
Będę wdzięczny za każdą pomoc :D

komentarz 21 października 2019 przez Tnifey Pasjonat (24,190 p.)

ehh te obrazki na forum, szerokość: 600, wysokość: *
mógłbyś wrzucić bardziej wertykalnie ? :P

komentarz 21 października 2019 przez Kamilu01 Nowicjusz (120 p.)

Jasne, najlepiej podeślę link: https://tinypic.pl/8jw7vu2nk9qf

2 odpowiedzi

odpowiedź 21 października 2019 przez adrian17 Ekspert (345,160 p.)
edycja 21 października 2019 przez adrian17

Czy kolumny dotyczące cen powinny się znaleźć zarówno w tabeli "ksiazka", "pozycjeFaktury", jak u "faktura"?

Cena produktu może się zmienić z czasem (np wyprzedaż). Cena na fakturze nie.

Jeśli sumę na fakturze można wywnioskować z sumy pozycji faktury, to można by się zastanowić nad pozbyciem się tej duplikacji.

Natomiast nie rozumiem kolumn "wydawnictwo_id1", "ksiazka_wydawnictwo_id1" etc. To jakieś przypadkowe przeoczenie? Podobnie, "pracownik_kontakt_id" na fakturze wydają się dziwne.

Zamiast pary "czyPrzyjeto", "dataPrzyjecia" etc można się zastanowić nad jedną nullowalną kolumną. Alternatywnie, kolumna "stan zamówienia" z wartością enumerowalną w środku (co zazwyczaj bardziej odpowiada rzeczywistym interfejsom sklepów).

Ale same relacje wyglądają rozsądnie.

O, właśnie, brakuje koszyka? ;) Chyba że chcesz traktować zamówienie jak tymczasowy koszyk.

komentarz 22 października 2019 przez Kamilu01 Nowicjusz (120 p.)
edycja 22 października 2019 przez Kamilu01

Dziękuję bardzo!

Obecność kolumn ("pracownik_kontakt_id") wynika z zastosowania "identifying relationship". Nauczyciel powiedział, żeby korzystać z tego rodzaju relacji, więc tak też robię, choć faktycznie muszę przyznać, że wygląda to dziwnie i z postanowiłem to zamienić. Teraz powinno być lepiej :D

Na chwilę obecną baza wygląda tak: https://tinypic.pl/9hgga695ux1q

Nie wiem czy nie przekombinowałem z tym koszykiem?

Dodatkowo pozbyłem się jeszcze tej duplikacji cen.

komentarz 22 października 2019 przez adrian17 Ekspert (345,160 p.)

Obecność kolumn ("pracownik_kontakt_id") wynika z zastosowania "identifying relationship". Nauczyciel powiedział, żeby korzystać z tego rodzaju relacji

Brzmi dziwnie, jak widzimisię nauczyciela, ale OK.

komentarz 22 października 2019 przez Kamilu01 Nowicjusz (120 p.)

Dlatego to zmieniłem. Wydaje mi się, ze powinno być w porządku, chociaż nie jestem pewien relacji między klientem a koszykiem. Co sądzisz?

odpowiedź 21 października 2019 przez jared Gaduła (3,600 p.)

Trochę dziwne z tymi cenami, bo tak jakby masz je w faktura, pozycje faktury gdzie są tej samej precyzji 10,2 a w książka masz tylko 5,2.

Ja to widzę w ten sposób:

Każda książka ma cenę.

Każde zamówienie łączy klienta z książką.

Faktura może zawierać wiele zamówień.

Faktura łączy klienta z pracownikiem i zamówieniem.

Faktura może zawierać wiele zamówień. Płatność faktury to zsumowanie wszystkich zamówień.

Nie wiem czy mój tok myślenia pomoże :)

Fajnie wygląda ta baza, skąd takie kolorowe oznaczenia, jakiś kurs polecisz?

komentarz 21 października 2019 przez adrian17 Ekspert (345,160 p.)

Mi osobiście bardziej pasuje podejście: jedna faktura ma jedno zamówienie (teoretycznie może być kilka, ale nawet prościej byłoby obsługiwać pojedynczo), jedno zamówienie ma dowolną liczbę produktów (analogicznie do koszyka).