Schemat erd - siłownia do oceny i popraw

0

Siemka, wrzucam poniżej schemat bazy danych którą chciałbym zaimplementować a nastepnie utworzyć aplikacje do zarządzania siłownią. Prosiłbym o ocene tego schematu i ewentualne poprawy jakby cos było źle.

https://zapodaj.net/1f072ef372a5c.png.html

0

W tabeli Logowanie zamieniłbym hasło na salt i hash oraz dodał email.

Id loginu na pewno jest potrzebne?

0

W sumie nie jest, można by wyrzucić.

0

A poza tym te relacje, klucze są sensownie rozplanowane?

0

Przede wszystkim brakuje podstawowych informacji o procesach jakie ta baza ma obsługiwać. Stąd trudno wskazać kwestie wątpliwe. Bardzo ogólne tematy:

  1. Co najmniej nieczytelna kwestia kategorii zajęć, rodzaju zajęć jak i samych zajęć.
  2. Jak rezerwacje_zajec "przechodzą" w faktyczne zajęcia?
  3. Jakie produkty zamawia się np. napoje? Ilość w produkty to raczej stan magazynu. Jak zamówienia "przechodzą" w sprzedaż?
  4. rezerwacja_zajec - w jakim celu dzień jako varchar? Raczej mówimy o konkretnym terminie z godziną rozpoczęcia i zakończenia.
  5. Czlonkostwa - jak będzie widoczna sytuacja gdy klient zapisał się na roczny okres (roczny karnet) ale opłaca miesięcznie?
1

Dodatkowo:

  1. klienci.nr_telefonu integer. Będziesz go sumował, czy jak?
  2. karnety.cena integer, produkty.cena float - oba źle
  3. kategorie_zajec.rodzaj_zajec -prosi się o słownik lub enum. Podobnie personel.funkcja_pracownika
  4. adresy - powiat + wojewodztwo są pochodną kodu + miejscowosci.
  5. złe nazewnictwo. O ile Klienci.id_klienta jest OK, to personel.id_pracownika już nie.
  6. Tabela Logowanie jest zbędna (jej nazwa wprowadza w błąd). Te dane powinny być w Personel. Za to z Personel powinna wyl;ecieć data_urodzenia
1

Id_loginu powinno zostać, powinno wylecieć ID_pracownika, Brakuje wiązania do loginu z Personelu. Nie do końca wiem, jaki procesy i dane chcesz zamodelować, ale jak dla mnie to brakuje mi wiązania między rezerwacją i karnetem - aby rozliczyć rezerwacje karnetem, to chyba powinieneś mieć ten konkretny, a nie jakiś karnet klienta. Zamówienie powinno mieć nagłówek i pozycje: jak ktoś zamówi dwa różne produkty, to musisz robić dwa zamówienia.

1

Tak sie jeszcze czepiając: W adresie powinien być numer mieszkania, Ważność karnetu to powinny być dwie daty: od do albo data startu i ilość dni.

0

Wygląda, że zabierasz się nie od tej strony co trzeba, tj. od modelu danych, a nie tego jakie funkcjonalności ma ten model wspierać. W efekcie jaki ten model by nie był, to i tak rozbije się o funkcjonalności.

0
Marcin.Miga napisał(a):

Dodatkowo:

  1. klienci.nr_telefonu integer. Będziesz go sumował, czy jak?
  2. karnety.cena integer, produkty.cena float - oba źle
  3. kategorie_zajec.rodzaj_zajec -prosi się o słownik lub enum. Podobnie personel.funkcja_pracownika
  4. adresy - powiat + wojewodztwo są pochodną kodu + miejscowosci.
  5. złe nazewnictwo. O ile Klienci.id_klienta jest OK, to personel.id_pracownika już nie.
  6. Tabela Logowanie jest zbędna (jej nazwa wprowadza w błąd). Te dane powinny być w Personel. Za to z Personel powinna wyl;ecieć data_urodzenia
  1. Chodziło mi o to żeby zapobiec wpisywaniu innych wartosci niż int, ale moge zmienic na varchar a później w programie zrobić jakiegoś if'a.
  2. Dlaczego obydwa, myśle że jak dam float w obydwu będzie ok.
  3. Ale będzie wiecej mozliwosci wyszukiwania danego użytkownika.
  4. id_personelu masz na myśli?
  5. Chciałem to podzielić żeby nie robić większego zamieszania.
dbuser napisał(a): > Przede wszystkim brakuje podstawowych informacji o procesach jakie ta baza ma obsługiwać. Stąd trudno wskazać kwestie wątpliwe. Bardzo ogólne tematy: > >
  1. Co najmniej nieczytelna kwestia kategorii zajęć, rodzaju zajęć jak i samych zajęć. >

  2. Jak rezerwacje_zajec "przechodzą" w faktyczne zajęcia? >

  3. Jakie produkty zamawia się np. napoje? Ilość w produkty to raczej stan magazynu. Jak zamówienia "przechodzą" w sprzedaż? >

  4. rezerwacja_zajec - w jakim celu dzień jako varchar? Raczej mówimy o konkretnym terminie z godziną rozpoczęcia i zakończenia. >

  5. Czlonkostwa - jak będzie widoczna sytuacja gdy klient zapisał się na roczny okres (roczny karnet) ale opłaca miesięcznie?

  6. Co masz na myśli?

  7. Tak np napoje, jakieś białko itp. Bardziej chodziło mi o to że przechodzi to troche w historie tego jakie produkty zostały zakupione i historia tego.

  8. varchar dlatego że będą to zajęcia cyklicznie odbywające sie co tydzien czyli np: pon, wtorek itp..

  9. może dodać coś w rodzaju statusu płatnosci.

0
  1. Co masz na myśli?
  2. Tak np napoje, jakieś białko itp. Bardziej chodziło mi o to że przechodzi to troche w historie tego jakie produkty zostały zakupione i historia tego.
  3. varchar dlatego że będą to zajęcia cyklicznie odbywające sie co tydzien czyli np: pon, wtorek itp..
  4. może dodać coś w rodzaju statusu płatnosci.

Ad1. tablica kategorie_zajec, a atrybuty sugerują że to jednak tablica zajęcia. Dobrze byłoby mieć słowniki dla kategorii zajęć jak i dla rodzajów zajęć jeśli są potrzebne.
Ad2. Może jednak tablica zamówienia powinna obsługiwać zamówienia różnych "produktów" tj, karnetów, konkretnych zajęć, napojów itd.w końcu za każdy się płaci bezpośrednio bądź wynika z posiadanego członkostwa.
Ad3. Czyli mogę dane zajęcia zarezerwować w dowolnym dniu tygodnia - raczej możliwy termin zajęć powinien być zgodny z grafikiem zajęć na dany okres. Wtedy wybierasz konkretną datę z czasem rozpoczęcia i zakończenia i z niej możesz odczytać dzień tygodnia.
Ad4. Pytanie, na jakie powinieneś sobie odpowiedź to - Jak można regulować płatności zarówno formy i cykle?

Jak poprzednicy już wspomnieli, napisz sobie funkcjonalności/procesy, które ma mieć Twoje rozwiązanie i dopiero w kolejnym kroku zastanawiaj się nad szczegółami technicznymi.

1 użytkowników online, w tym zalogowanych: 0, gości: 1