Witam czy mógłby ktoś sprawdzić czy ten diagram er jest poprawny. Baza ma dotyczyć sklepu. Z
góry dziękuje bardzo za pomoc.
0
1
Nie zauważyłem ewidentnych baboli, jest kilka dyskusyjnych wyborów i brakuje mi tu spisanych założeń (pytanie, czy masz je przemyślane).
Skupiłbym się na dwóch rodzajach.
- Czy obiekt XXX może mieć jeden czy więcej powiązań z YYY? Czyli "klient ma zawsze zdefiniowaną max jedną osobę kontaktową", "produkt przechowywany jest tylko w jednym magazynie",
- Czy potrzebujemy jednej wersji obiektu w perspektywie życia aplikacji. "Czy klient może zmienić adres i czy będę potrzebował poprzedniej wersji do starej faktury"?
Jeśli to studencki projekt, to jako prowadzący zadawałbym tego rodzaju pytania.
Dlaczego adres klienta czy forma płatności są wydzielone do innej tabeli, a Producent.KrajPochodzenia już nie?
Jak na fakturze umieścić kilka pozycji?
Czym jest Zamówienie.status?
Dlaczego faktura ma cenę brutto, netto i VAT, a produkt nie?
Czy kilku producentów może dostarczać jeden produkt?
Część z tych kwestii to małe smrodki inne mogą wynikać ze świadomych wyborów lub być nieprzemyślane (ale tu wystarczyłoby odwołanie się do specyfikacji i założeń).
0
Wygląda ogólnie spoko. Jedno co wygląda dziwnie to to, że klient może mieć kilka adresów, a zamowienie ma tylko id klienta, więc może być problem z określeniem, który adres to ma być. Poza tym relacja jest „wiele” po stronie adresu, ale to w kliencie jest ID „adresu”. Jeśli to jest jeden klient do wielu adresów, to ID musi być w adresie.
Jak rozumiem „dostawa” to tylko taka enumeracja, żeby nie wpisywać na sztywno w kodzie opcji dostawy? Nie rozumiem do czego ma służyć encja „magazyn”, ile jest danego produktu w magazynie? Wtedy chyba nazwałbym to „dostępność” czy jakoś tak. Też prawdopodobnie przydałaby się opcja „na zamówienie”. Czym jest „pozycja” w „osobie kontaktowej” też jest zastanawiające :)
0
@elwis: faktycznie z adresem jest to bez sensu zrobię jeden do jeden. Magazyn zmienię na dostępność. Co masz na myśli jeśli chodzi o ,,na zamówienie”? Zamiast pozycja miało być stanowisko mój błąd
@Los Bomberos: adres dałem osobno żeby nie było zbyt dużo kolumn w jednej tabeli. Jak umieścić kilka pozycji na fakturze nie mam pojęcia jak to można zrobić masz jakieś sugestie jak mogłoby to wyglądać? Status mam na myśli zrealizowane lub nie. W relacji producent a produkt rozumiem dać wiele do wielu?
0
@markone_dev: Gdy zrobię tabele PozycjeFaktury to nie jestem w stanie określić ile pozycji będzie na fakturze
0
1
macfal napisał(a):
@Los Bomberos: adres dałem osobno żeby nie było zbyt dużo kolumn w jednej tabeli.
Rozdzielenie klient-adres ze względu na zbyt dużą liczbę kolumn jest głupie.
Rozdzielenie klient-adres ze względu na to, że klient może mieć kilka adresów jest mądre.
Serio, polecam spisanie założeń w punktach i odwoływanie się do tego.
Jeśli na zamówieniu może być kilka produktów - tabelka Produkt_has_Zamówienie jest ok.
Jeśli zamówienie zawiera zawsze tylko jeden produkt - tabelka Produkt_has_Zamówienie jest bez sensu.
I tak powinieneś przemyśleć wszystkie relacje między zidentyfikowanymi obiektami domeny takimi, jak zamówienie, produkt, producent, faktura, klient, adres, dostawa itp.
Do tych założeń dopasowujesz bazę.
Co do drugiego diagramu - coś chyba pomieszałeś wyklikując klucze, np. w Zamówieniach masz Id_Klienta i Klient_Id_Klient.
1
macfal napisał(a):
@markone_dev: Gdy zrobię tabele PozycjeFaktury to nie jestem w stanie określić ile pozycji będzie na fakturze
Nie rozumiem. Weź wpisz sobie w google invoice table sql design i zobacz jak inni to modelują, tutaj masz pierwszy lepszy przykład z wielu z tabelą InvoiceItem czyli pozycja na fakturze
0
Jak widać za bardzo tego nie rozumiem. Co powiecie na takie rozwiązanie
0
Wydaje mi się że teraz powinno być już ok. 