Witam,
muszę zrobić projekt bazy danych i wybrałem sobie sklep internetowy. Teraz pracuje na diagramem UML i trochę się zawiesiłem, zamieszałem. Mój pomysł wygląda tak:
1. Jest user, który się loguje.
2. User może być firmą lub zwykłą osobą
3. User składa zamówienie
4. Na zamówieniu jest data złożenia, data wysyłki, ilość towaru
5. Oczywiście jest tabela towar
6. Zamówienie i towar łącze za pomocą pozycje

i dalej już się zamieszałem. Teraz chce jeszcze dodać dostawców, faktury kupna i faktury sprzedaży.

To jest mój diagram UML:




Tak przy okazji ktoś mógłby mi pomóc jeszcze z relacjami typu jeden do wielu itd.?

Dobrze zaprojektować strukturę bazy sklepu nie jest łatwo, więc cieszę się że zadałeś to pytanie. Ja dam rady ze swego doświadczenia i liczę na ciekawą dyskusję.

W pozycjach zamówienia dodałbym: nazwę, ilość, cenę, vat - można zadać pytanie dlaczego skoro te dane są w produktach - otóż co się stanie w przypadku zmiany nazwy produktu, jego ceny, vatu jeśli nie dodamy tych pól ? Wówczas klient, który będzie przeglądać historię swoich zamówień zdziwi się widząc inne nazwy produktów czy ceny niż zamawiał.

W tabeli zamówienia dajesz pola z informacjami o kliencie: imię, nazwisko itp. - czyli ponownie powielasz pola, bo klient przecież może je zmienić w profilu.

Zamówienia łączysz z tabelą faktury, a ją z tabelą pozycje faktury.

Zapewne w Twoim sklepie wszystkie produkty będą mieć ten sam vat, więc jak za 2 lata vat zmieni się na 22% to będziesz musiał aktualizować wartość vat wszystkich produktów. Polecam więc stworzenie tabeli sklep, w której będziesz przechowywać procent vat.

To takie rady na szybko.

Hmmm... dobre rady, ale zamieszały mi jeszcze bardziej

Ale teoretycznie można przewidzieć taki scenariusz. Jest realizowane zamówienie i wystawiane faktury, które lądują w księgowości np. każdego 5 miesiąca i zamówienia zrealizowane są usuwane po 5.

Ta baza nigdzie nie będzie wykorzystana, to tylko projekt do oddania na zaliczenie i wzorowałem się na tym -> http://szuflandia.pjwstk.edu.pl/~amb/bazy-lab/PW/index.html

Aha, jeśli to projekt na zaliczenie to zlekceważ moje rady - ja jak oddałem projekt bazy danych rzeczywistego sklepu to usłyszałem wykład o normalizacji, a na pytanie jak by wykładowca to zrealizował biorąc pod uwagę nieustanne zmienianie przez klientów danych czy pisanie do sklepu żeby jednak wysłać produkt na inny adres usłyszałem dalszy ciąg wykładu o normalizacji.

To co dalej z tymi dostawcami i fakturami. Ewentualnie te faktury wywalę.

przepraszam za OT, ale:
Wiewiorku, a czy rozwiązanie problem ciągłych edycji danych nie można by rozwiązać poprzez rewizje? Przechowywanie wszystkich wersji danych jakie podał użytkownik, ewentualnie z datą ich wprowadzenia. Aktualnym adresem byłby ten z największym numerem wersji, a zamówienie z przeszłości posiadałoby np. ver. 2.
Niestety, nie mam okazji przetestować takich rozwiązań, ani nie mam doświadczenia z dużymi sklepami internetowymi aby znać problemy jakie mogą wystąpić przy tym rozwiązaniu, a Ty sprawiasz wrażenie osoby kompetentnej

Zamowienia powinny laczyc sie z tabela Faktury, a tabela Faktury z pozycjami faktury. Nie wiem po co masz tabele fakture kupna i sprzedazy ?

----------------------------

@grizzlli w nawiazaniu do tego co piszesz to ja zwykle robie tak:
tabela KLINCI: id_klienta, imie, nazwisko, telefon, email
tabela ADRESY: id_adresu, id_klienta, imie, nazwisko, adres, miasto, ..., uzyty (te kolumne robie typu BOOL z domyslna wartoscia 0 i gdy jest modyfikowany adres to modyfikuje ten rekord, a gdy skladane jest zamowienie to ustawiam na 1 i tworze nowy rekord z takimi samymi danymi i znowu wartoscia 0, dzieki czemu mozna bez przeszkod modyfikowac rekord) - dzieki temu nie jest tworzony nowy rekord przy kazdej modyfikacji danych adresowych.

Klient moze miec wiele adresow i wiele zamowien, adres moze wystapic w wielu zamowieniach. W tabeli zamowienia daje kolumny: id_adresu_dostawy i id_adresu_faktury.

Bo teoretycznie mając sklep kupujesz towar i go sprzedajesz. Kupuje od dostawców, a sprzedaje klientom

No ja sie spotkalem ze sklepami, ktore wystawiaja faktury tylko klientom, z fakturami dla dostawcow ci nie pomoge, bo nie bardzo rozumiem, mozliwe ze tak jest, ale klienci nigdy o tym mi nie wspominali.

W sumie to może rzeczywiście trochę bezsensu, bo dostawca wystawia fakturę, a jakieś obliczenia można wykonać na np. cenie zakupu

Dobra zrezygnowałem z tego sklepu, a zabrałem się za bazę dla szpitala i wyszło mi mniej więcej coś takiego:

Faktury, zakupy, lepiej nie wnikaj, przeklikaj małą księgowość rzeczpospolitej, zrozumiesz dlaczego, studia na 2 lata. Dobrze się sklepem pod ten programik podłączyć(ma wersję na sql).

Ogólnie system sklepu internetowego to dość skomplikowany problem na dzisiejsze czasy. Zakładając, że wypchnąłeś już sprawy księgowe do jakiegoś gotowca, pozostaje Ci problem asortymentu. Musisz go mieć, tu trzeba dostawców, och dzięki bogu mają oni w postaciach elektronicznych swoje oferty. No to wypadałoby to od nich zassać, a do tego potrzebna jest chociażby jedna tabela, czyli to co jest u dostawców. Teraz stajesz przed kolejnym pytaniem, co robić z produktami, które są u kilku dostawców, a jak je powiązać, a może dublować.......... Ceny, marża, podatki, gospodarka odpadami, RMA, listy przewozowe, płatności, kursy walut. Ale myślę skromnie, że to prostsze niż szpital.

mam pytanko odnosnie tego sklepu i faktur ;p
jakie elementy powinna zawierac faktura sprzedazy a jakie pozycje faktury?