Witam serdecznie, jesli nie jest to odpowiedni dział to wybaczcie, nie mogłem jednak znaleźć bardziej odpowiadającego działu.
Mam zaprojektować na cele szkolne (nic komercyjnego ani nic z tych rzeczy) prostą bazę danych sklepu komputerowego. Na razie mam prosty projekt jaki widoczny jest w załączniku.
Chciałbym dodać do niego takie informacje jak specyfikacja czy gwarancja, nie mam jednak pomysłu jak (tworząc nowe tabele czy nowe pola - dowolnie)
Będę wdzięczny za wszelkie pomysły i sugestie.
Internet nie wybacza.
Zacznij od tego: http://software.com.pl/analiza-biznesowa-wymagania-%E2%80%93-pozyskiwanie-dokumentowanie-komunikowanie-weryfikacja/
Bez tego nie da się powiedzieć, czy to co zrobiłeś ma sens czy nie. Masz jakiś diagram i on reprezentuje model i on jest poprawny dla jakiegoś modelu systemu, ale nie wiedząc jaki jest cel systemu, nie możemy powiedzieć, czy ten model jest dobry, czy nie, albo czy spełnia wymagania, czy też nie. Dlatego najpierw przedstaw opis wymagań biznesowych. Tu nawet nie napisałeś nawet dla kogo to system miałby w teorii być, dla sklepu czy sieci sklepów? Przydałoby się też jakieś podstawowe modelowanie procesów, biznesowych etc. Więcej znajdziesz w linku.
Uwagi ogólne. Tworze je nie na podstawie wymagań, bo tych nie ma, tylko na podstawie generycznych systemów e-commerce, z którymi miałem do czynienie (gdzie nawet nie wiem czy to coś wyżej jest jakimś e-commercem):
Pierwszy raz się spotykam, by relacja między produktem, a dostawcą była w stosunku jeden do wielu. Nie ma to logicznego sensu dla bardzo dużej grupy produktów. Nie mniej może być dobre jeśli takie są wymagania.
Brakuje zarządzania adresami, to jest gdzie należy dostarczyć produkt (ogólnie brakuje b. wielu rzeczy, ale to raczej taka podstawa).
Specyfikacja i gwarancja to z reguły atrybuty produktu http://faq.miiduu.com/category/7-attributes-and-variations/ tak jak to pokazano tutaj. Robisz tablicę w nawiązaniu jeden wiele do produktu o polach kod atrybutu, nazwa, wartość i tam to umieszczasz, a potem wydobywasz jako mapę kluczy i wartości. Dzięki temu niektóre produkty mogą mieć atrybuty jak specyfikacja komputera, ale np. bluzka mieć go nie będzie, tylko coś innego, opis, etc. Często spotykam się też z podziałem atrybutów definiujących i opisujących produkt, też warto taki podział zastosować.
Zastanowiłbym się nad złączeniem klientów i kierowców z użyciem dyskryminatora, w myśl zasady, aby sztucznie nie mnożyć bytów ponad potrzebę. Ale to też zależy od wyników analizy biznesowo-funkcjonalnej.
Zastanowienie się nad wywaleniem samochodów i kierowców. Pytanie jeśli to ma być sklep, to czy ma to sens, by system sprzedażowy zajmował się ewidencjonowaniem pojazdów i kierowców, czy tym przypadkiem nie powinien zajmować się magazyn albo sourcing? Sklep zrobił to co do niego należało ładnie zaprezentował produkt i go sprzedał, czy to jest dobre miejsce do robienia obsługi przesyłki? Moim zdaniem nie, bo po pewnym czasie okaże się, że tę część proesu sprzedaży będziemy outsorcingować, do jakiegoś DHL, albo innego tworu, bo najzwyczajniej w świecie jest taniej, niż prowadzić coś takiego samemu. Dlatego lepiej chyba zrobić to jako osobny, wymienialny moduł, aby potem się nie obudzić z ręką w nocniku.
Więcej się powiedzieć nie da bez analizy biznesowej i funkcjonalnej.
PS
Jeszcze mi tak szybko wpadło do głowy, na pewno w każdym sklepie przydałby się jakiś silnik promocji. Nie widzę w obecnym schemacie tego by można było w jego oparciu tworzyć promocje i przypisywać je do produktów. A to jest raczej must have jeśli chodzi o sklep.