witam, mam taki projekcik - stworzyć aplikacje zarządzania stacją paliw. Ma to wyglądać mniej więcej tak, że jestem właścicielem stacji i moge sobie sprawdzić przychodzy itp.
Aplikacja ma wyglądać tak że klienci tankują i płacą za paliwo czyli pracownik po prostu będzie podawał rodzaj i ilość paliwa jaką klient zatankował zostanie obliczona kwota do zaplaty i zapisana do bazy. W bazie będą ceny benzyny od róznych dostawców od których stacja będzie kupować benzynę. Jako właściciel stacji będę też musiał opłacać pracowników. Ogólnie chodzi o to, jak mi Pani prof powiedziała, żebym mógł robić róznego rodzaju zestawienia, jak obrót miesięczny, obrót miesięczny z opłatami pracowników, kwoty na jakie dany pracownik sprzedał benzynę itp. Zacząłem tworzyć schemat bazy ale niestety jestem cienki z tego... Skonstruowałem coś takiego i chciałem Was prosić o wasze zdanie, jakieś sugestie, porady.
schemat bazy

Może zacznij od stworzenia modelu związków encji, a następnie przejdź do diagramu klas.

czyli mam rozumiec ze to jest źle? Chodzi mi czy ogolnie dobrze jest to wszystko polaczone, czy ten szkic bazy jest dobry?

To co zrobiłeś to diagram klas.

Innymi słowy (przykład Klienta):
Zaprojektowałeś sobie obiekt Klient
Obiekt Klient ma dwie właściwości (zmienne): Firma i Prywatny; obie są publiczne, tzn. możesz się do nich odwołać spoza klasy.
Obiekt Klient ma dziwne powiązania z klasami Prywatny i Firma.

Podejrzewam, że nie o to Ci chodziło. Użyłeś ZŁEJ notacji.

A tutaj masz jak mniej więcej powinien wyglądać diagram ERD w jednej z używanych notacji.

Z innych uwag jest to i tak nie do końca dobrze zaprojektowane, ale może wynika to głównie z niewłaściwego przedstawienia diagramu.
Na diagramie baz danych musisz zawrzeć:

Wszystkie pola w bazie
Klucz, jeśli takowy jest wymagany
Klucze obce, jeśli istnieją
Innymi słowy WSZYSTKIE pola, które potem dodasz do bazy.

Btw, jaki cel miałeś w wydzielaniu Paliwa i Ilości paliwa na stacji?

Jeśli chodzi o połączenia klas, to tym się zajme potem. Teraz przede wszystkim zależy mi na samym układzie, wyglądzie tego schematu, czy to tak powinno wyglądać? Czy coś jest źle? Bo teraz się zastanawiam czy w ogóle potrzebna jest ta klasa klient, zamiast od razu połączyć Prywatnego i Firmę z formularzem zapłaty?

Teraz tak w skrócie objaśnię co ja tak naprawdę chcę tu stworzyć. Aplikacja ta ma wyglądać następująco:
-mamy w sumie 3 rodzaje klientów - zwykli klienci, stali klienci którzy będą mieć kartę stałęgo klienta(zniżki) na kartach będize podany nr rejestracyjny auta, oraz trzeci rodzaj klientów to będą firmy które również będą posiadać zniżki.
- co do tego paliwa i paliwa na stacji, to w "paliwie na stacji" będzie umieszczona ilość paliwa każdego rodzaju w zbiornikach, a w "paliwo" będą umieszczone ceny danego paliwa. Teraz się tak zastanawiam czy to dobre rozwiązanie czy jednak niepotrzebna ta klasa "paliwo"?
- administrator-właściciel stacji będzie miał podgląd finansowy, czyli ile zostało sprzedanej benzyny, z jakim przychodem, ustalanie cen paliwa, wybór i zamawianie od dystrybutora benzyny i ogólne zestawienia obrotów całej stacji benzynowej.

w tym schemacie uzupełniłem trochę, ale jakoś nie jestem przekonany że to wszystko jest dobrze;/ dlatego będę wdzięczy za wszelakie wskazówki

schemat


tutaj wprowadziłem delikatne zmiany, wydaje mi się że tak lepiej - Diagram

Ale to nadal nie jest schemat bazy danych tylko diagram klas. Używasz złej notacji.

Gdzie są klucze obce? W którą stronę łączą się relacje 1:1 lub 1:* ?
Czym połączone są tabele Klient i Firma?

Klient ma tylko dwa pola - firma i prywatny.
Dwa pola wykluczają się.
Po co ta tabela? Jaki miałeś cel ją projektując? Jeśli zbiór wszystkich klientów w jednej tabeli, to jest to złe podejście:

raczej coś w guście:

Klienci:
id PRIMARY KEY
type ENUM('prywatny', 'firma', 'inny')

Jeśli ID chcesz mieć per firma i prywatny, to tabela Klienci moim zdaniem zbędna. Nic Ci nie daje.

Brakuje typów pól w Twojej bazie (ze względu na złą notację).

Zmień notację na poprawną (ERD) - będzie można pomysleć dalej.

rozmawiałem z kolegą i powiedział że na zajęcia będzie potrzebny jednak diagram klas, nie schemat bazy, czy w takim razie ten diagram jest już w miarę ok?
diagram klas
ale też będę potrzebować diagramu przypadków użycia, zmajstrowałem takie coś, ale nie wiem czy to dobrze jest diagram przypadków użycia

W takim razie mam pytanie: czy nie musicie robić metod klas?

Jest jakaś przyczyna czemu wszystkie właściwości są publiczne?

Zrób dziedziczenie po kliencie w przypadku firm i prywatnych.
Dziedziczenie ma inną strukturę linii.

Ilość paliwa na stacji w stosunku do stacji to raczej agregacja (również inne zakończenie linii).

Nie musicie umieszczać typów argumentów?

Polecam na początek: http://en.wikipedia.org/wiki/Class_diagram

mam takie 3 pytania: diagram
1.czy pomijając to co napisałeś, czyli że nie ma metod i to, że wszystkie właściwości są publiczne, to czy teraz ogólnie ten diagram jest ok?
2.oraz czy ten diagram przypadków użycia z mojego poprzedniego postu też jest ok?
3.Chciałbym jeszcze zrobić historię zakupu benzyny stacji od dystrybutora i zastanawiam się czy stworzyć do tego nową tabele, czy umieścić to w którejś z tych co jest?