Prośba o pomoc w projekcie pierwszej bazy danych

Witam

Mam problem ze zrozumieniem zasad/sposobu projektowania baz danych. Prosiłbym o nakierowanie.

Poczytałem trochę literatury i kursów, zrobiłem pare prawie identycznych przykładów sklepu i zatkałem się przy rzeczywistym projekcie.

na razie krętymi drogami doszedlem do takiego schematu, po drodze do niego mialem jeszcze pare innych ale wydawaly mi sie niepoprawne. Ten w sumie teżchyba nie jest jeszcze nawet w 1NF (m.in. NazwaKlienta) ale prosilbym o sprawdzenie go pod kątem wymogów i problemów które opisałem ponizej:

Chciałbym zaprojektować bazę danych - cennik.
na razie jest to robione tak, że wycenia się jakis produkt, określa się jego cenę za 100szt., date wyceny przyjmuje sie za date poczatku obowiązywania nowej ceny. Przy okazji starą cene i date jej obowiązywania się nadpisuje - czyli traci (baza danych papierowa/wordowa).
Chciałbym aby baza przechowywała wszystkie ceny i wszystkie daty od ktorych te ceny obowiazywały, odpowiednim zapytaniem chciałbym miec "samoaktualizujacy się" cennik bieżacy, ewentualnie historie zmian cen dla danego wyrobu, okresy obowiazywania tych cen itp.

Mam problem z okresleniem jak zaprojektowac pole numeru kolejnej zmiany ceny dla tego samego wyrobu. Obecnie jest tak ze przy aktualizowaniu ceny starego wyrobu, nadpisuje sie date poczatku jej obowiazywania, nadpisuje sie jego cene a pole numeru zmiany zwieksza sie o jeden i tez nadpisuje (oznaczenie literowe A, B, C, D itp. A - to pierwsza wycena, D - ostatnia, aktualna).

Chcialbym tez zawzec dane kto robil wycene i kto zatwiedzil do wprowadzenia do cennika bierzącego - jak ten etap zrealizowac w bazie danych - dwa przypadki istnienia wyceny; wykonana do sprawdzenia (moga zostac wprowadzone eszcze poprawki, nie widoczna w biezacym cenniku chociaz numer ma wyzszy od obecnie aktualnego oraz wykonana-zatwierdzona czyli obecnie najaktualniejsza wycena)

W projekcie swojej bazy przyjąłem znaczne uproszczenie, wycene wykonuje sie w zewnetrznym arkuszu Excel, w bazie chcialbym tylko przechowywac sciezkę do niego, i dwa pola wynikowe z tego pliku IloscProduktow dla jakiej robi sie wycene i CeneZa100szt. (Przyszlosciowo chcialbym caly plik łącznie z wyliczeniami wszczepic w tą system zarządzania tą bazą ale na tym etapie jeszcze jest na to za wczesnie, tam trzeba bybylo robic BoM'y Produktow, OperacjeProdukcyjne, AmortyzacjeSprzetu itp. kosmos.).

Za pomoc w nakierowaniu na właściwe myślenie będę wdzieczny.

na początek:
0. Kalkulacja dla produktu: usunąć FK odnoszące się do innych FK

1. cena nie musi liczbą całkowitą
2. co to jest numer produktu?
3. Czym jest oferta klienta?
4. Czym jest grupa produktów i czy na pewno jej cechą jest pojemność wyrażana jako liczba całkowita?
5. może lepiej zrobić osobną tabelę z krajami pochodzenia?
6. kto wprowadził/zatwierdził - tabela użytkownicy i FK do niej
7. pole FK: Produkt -> Kalkulacja - wskazujące na aktualną (upublicznioną) kalkulację

0. OK-to nie problem

1. Ok-to nie problem

2. schemat dzialania wyglada tak:

3. a) klient wyszukuje sobie w katalogu wyroby A, B i C (z dostepnych np. A-Z)

4. b) przesyla zapytanie "Za ile mi wykonacie A, B i C, wstepnie chce zamowic 30szt. A, 45 B i 120C"

5. c) Jezeli ceny są aktualne a na produkcji nic sie nie zmienilo odpowiedz otrzymuje od razu, jezeli nie, wykonuje sie kolejna kalkulacje i wysyla "OFERTE" dla klienta gdzie dane są unikalny numer oferty, dane Klienta, naszej firmy, i wyszczegolniona liste wyrobow i wyliczonych cen dla kazdego z nich. oraz data waznosci tych cen z automatu jest to miesiac, po miesiacu jezeli zamowi musi liczyc sie z tym ze wykona sie nowa wycene i cena bedzie inna.

6. porownując obrazowo, grupą bylby zeszyt formatu A5, a konkretnym wyrobem zeszyt A5 16kartkowy, A5 32kartkowy itp. To i to pakuje sie do tego samego kartonu (analogia z zeszytami nie calkiem trafiona bo roznia sie gruboscia ale w przypadku moich wyrobow pojemnosc w opakowaniu zbiorczym jest taka sama dla calej grupy)

7. OK- nie ma problemu (wydaje mi sie ze powinienem tez uszczegolowic dane klienta imie, nazwisko, e-mail, telefon, itp.)

8. z tym mam problem, czy w jednej tabeli maja byc pracownicy ktorzy wprowadzaja i zatwierdzaja? czym oni sie beda roznic? jak zalatwic sprawde podzialu dostepu do operacji na bazie danych? chcialbym zeby jedna grupa miala mozliwosc wprowadzania wycen, dwie osoby ktore beda moglu zatwierdzac wyceny i cala rzesze osob ktorzy beda mieli sam podglad do danych w bazie.

9. nie rozumiem.

Wszystkie Twoje uwagi jak wroce do domu zaczne wprowadzac, tymczasem przesylam uszczegolowione odpowiedzi do Twoich pytan.
Nie chcialbym na tym etapie zbyt komplikowac tej bazy, ale jednoczesnie najbardziej mnie interesuje porzadny projekt - tak abym mogl go z czasem, jak zalapie w praktyce projektowanie, rozwijac.

Varran napisał(a)

Opuściłeś punkt 2. ;p

Varran napisał(a)

3. schemat dzialania wyglada tak:

4. a) klient wyszukuje sobie w katalogu wyroby A, B i C (z dostepnych np. A-Z)

5. b) przesyla zapytanie "Za ile mi wykonacie A, B i C, wstepnie chce zamowic 30szt. A, 45 B i 120C"

6. c) Jezeli ceny są aktualne a na produkcji nic sie nie zmienilo odpowiedz otrzymuje od razu, jezeli nie, wykonuje sie kolejna kalkulacje i wysyla "OFERTE" dla klienta gdzie dane są unikalny numer oferty, dane Klienta, naszej firmy, i wyszczegolniona liste wyrobow i wyliczonych cen dla kazdego z nich. oraz data waznosci tych cen z automatu jest to miesiac, po miesiacu jezeli zamowi musi liczyc sie z tym ze wykona sie nowa wycene i cena bedzie inna.

Drugiego stycznia przychodzi zapytanie ofertowe, 3 stycznia wraca odpowiedź ważna do 3 lutego. Drugi klient wysyła zapytanie 31 stycznia, co wtedy?

Varran napisał(a)

4. porownując obrazowo, grupą bylby zeszyt formatu A5, a konkretnym wyrobem zeszyt A5 16kartkowy, A5 32kartkowy itp. To i to pakuje sie do tego samego kartonu (analogia z zeszytami nie calkiem trafiona bo roznia sie gruboscia ale w przypadku moich wyrobow pojemnosc w opakowaniu zbiorczym jest taka sama dla calej grupy)

Ok, więc zakładam, że do czegoś to jest potrzebne i wiesz do czego...

Varran napisał(a)

6. z tym mam problem, czy w jednej tabeli maja byc pracownicy ktorzy wprowadzaja i zatwierdzaja? czym oni sie beda roznic? jak zalatwic sprawde podzialu dostepu do operacji na bazie danych? chcialbym zeby jedna grupa miala mozliwosc wprowadzania wycen, dwie osoby ktore beda moglu zatwierdzac wyceny i cala rzesze osob ktorzy beda mieli sam podglad do danych w bazie.

3 pola boolean i nadajesz każdemu userowi prawa, które chcesz

Varran napisał(a)

7. nie rozumiem.

To było o tym jak określać, która wycena jest aktualna, ale jak rozumiem może nie być aktualnej ceny, więc to nie zadziała. Potrzebujesz pól typu data: ważneOd i ważneDo.

Ad. 2. NrProduktu to unikalny numer dla produktu ale unikalny w skali firmy autora tego produktu, moze sie zdarzyc ze produkt autorski mojej firmy bedzie mial ten sam numer z produktem z montazu zleconego przez inna firme dla mojej firmy, dlatego ten numer nie jest kluczem glownym w tabeli.

Rozumiem ze do zaleznosci miedzy tabelami nie ma zastrzezen, wiec na bazie tego projektu postaram sie zrobic nowy uwzgledniajacy Twoje podpwiedzi, moze poznym wieczorem cos wrzuce.

być może będą zastrzeżenia, ale wcześniej muszę dobrze zrozumieć co się dzieje z ofertą, a dokładniej, czy "cena aktualna" jest uniwersalna dla wszystkich klientów w danym momencie, czy jednym może być skalkulowane drożej, a innym taniej (być może ze względu na ilość)?

Drugiego stycznia przychodzi zapytanie ofertowe, 3 stycznia wraca odpowiedź ważna do 3 lutego. Drugi klient wysyła zapytanie 31 stycznia, co wtedy?

Na ten sam wyrob niezwylke rzadko mogloby sie to zdarzyc, poza tym cena w zdecydowanej czesci zalezy od zamawianej ilosci sztuk. Zakladajac ze mamy splot tych zdarzen i jest ponowne zapytanie identyczne jak te z 2 stycznia - nalezaloby sprawdzic czy nie ma zadnych zmian na produkcji, jezeli nie to cena jest ta sama i wazna na kolejny miesiac, jezeli cos sie zmienilo na produkcji cos co ma wplyw na cene (zajetosc parku maszynowego, zmiana materialu na alterntywny drozszy/tanszy rusza ponowna wycena).

3 pola boolean i nadajesz każdemu userowi prawa, które chcesz

Wstepnie daje uprawnienia stanowiskom, stanowisko kierownicze moze miec rozszerzone uprawnienia tak jak na nowym projekcie.

Varran:
7. nie rozumiem.

To było o tym jak określać, która wycena jest aktualna, ale jak rozumiem może nie być aktualnej ceny, więc to nie zadziała. Potrzebujesz pól typu data: ważneOd i ważneDo.

O "samoaktualizujacym sie" cenniku wstepnie myslalem, ze to bedzie odzielna zakladka na stronie aplikacji gdzie do datagrid'a beda pobierane dane z bazy zapytaniem np:

SELECT NazwaProduktu, DlaIlosci, CenaZa100szt (szczegolowo jeszcze ma byc numer aktualizacji, jezeli istnieje to numer oferty na jaka byla dana wycena itp.)
FROM Produkt p, KalkulacjaDlaProduktu kdp
WHERE p.idProduktu = kdp.idProduktu 
AND (jeszcze nie wiem jak ale warunek taki gdzie ma brac takie idProduktu gdzie data jest najwyzsza, najblizsza obecnej)  

Jeszcze jezeli chodzi o oferty to nie kazdy wyceniany produkt ma okresowo weryfikowana wycene ze wzgleu na wplyniecie zapytania klienta. czasami jest potrzeba zweryfikowania cen bez impulsu w postaci zainteresowania klientow danym produktem czy grupa wyrobow.

Wstepnie poprawilem perojekt tak:

1. Nadal nie wiem jak zrobic aby zachowac informacje w bazie odnosnie kolejnych wycen dla tego samego produktu i tej samej ilosci. Domyslnie chcialbym aby to bylo oznaczone literami (A- najstarsza wycena, D-najmlodsza - po paru latach w firmie jest tylko pare wyrobow gdzie doszlo do litery F)
2. Nie jestem pewien czy dobrze jest z tabela "OfertaKlienta" w sumei oferta klienta powinna zawierac takie dane np. w postaci listy prodoktow, zamawianych ilosci tych produktow i odpowiadajacych ich cen. Klienta nie moze dostac linku do Kalkulacji, to informacja wewnetrzna. (Chciaz z drugiej strony ta oferta bedzie efektem zapytania ktore poda tylko to co zaplanuje.)
3. Czy w takiej formie nadawanie uprawnien bedize bardziej elastyczne?

Varran napisał(a)

Drugiego stycznia przychodzi zapytanie ofertowe, 3 stycznia wraca odpowiedź ważna do 3 lutego. Drugi klient wysyła zapytanie 31 stycznia, co wtedy?

Na ten sam wyrob niezwylke rzadko mogloby sie to zdarzyc, poza tym cena w zdecydowanej czesci zalezy od zamawianej ilosci sztuk. Zakladajac ze mamy splot tych zdarzen i jest ponowne zapytanie identyczne jak te z 2 stycznia - nalezaloby sprawdzic czy nie ma zadnych zmian na produkcji, jezeli nie to cena jest ta sama i wazna na kolejny miesiac, jezeli cos sie zmienilo na produkcji cos co ma wplyw na cene (zajetosc parku maszynowego, zmiana materialu na alterntywny drozszy/tanszy rusza ponowna wycena).

Czy aplikacja ma kontrolować to czy coś się zmieniło, czy będą to robić użytkownicy nie korzystając z aplikacji?

Varran napisał(a)

O "samoaktualizujacym sie" cenniku wstepnie myslalem, ze to bedzie odzielna zakladka na stronie aplikacji gdzie do datagrid'a beda pobierane dane z bazy zapytaniem

Jeżeli to miałby być cennik dla klienta, to chyba nie ma sensu, jeżeli powtarzalne zapytania praktycznie się nie zdarzają. Jeżeli dla pracownika, to zależy jaki obowiązuje "algorytm" ustalania ceny i co jest użytkownikowi potrzebne i jak bardzo.

Varran napisał(a)

Jeszcze jezeli chodzi o oferty to nie kazdy wyceniany produkt ma okresowo weryfikowana wycene ze wzgleu na wplyniecie zapytania klienta. czasami jest potrzeba zweryfikowania cen bez impulsu w postaci zainteresowania klientow danym produktem czy grupa wyrobow.

Więc wtedy tworzymy Kalkulację nie przypisaną, do żadnej oferty. Z punktu widzenia użytkowników podających ceny, będzie to wyglądać tak samo jak kolejne zapytanie o cenę. Jeżeli kalkulacja nie będzie powiązana z żadnym zapytaniem ofertowym, to może warto przypisać je do pracownika, żeby się nie zgubiło:) Może warto też przypisać każdą ofertę do pracownika, żeby zawsze był ktoś odpowiedzialny za jej "cykl życia".

Varran napisał(a)

1. Nadal nie wiem jak zrobic aby zachowac informacje w bazie odnosnie kolejnych wycen dla tego samego produktu i tej samej ilosci. Domyslnie chcialbym aby to bylo oznaczone literami (A- najstarsza wycena, D-najmlodsza - po paru latach w firmie jest tylko pare wyrobow gdzie doszlo do litery F)

Nie jestem pewny o co dokładnie pytasz, ale może trafię... Po prostu ich nie usuwać tylko dokładać nowe kalkulacje, a pracownik rozpatrujący zapytanie wyświetli sobie wszystkie rekordy, albo wszystkie aktualne albo jak to tam inaczej potrzebujesz. Z tego co rozumiem literowanie wycen, jest tylko elementem prezentacji, więc możesz je dodać w warstwie prezentacji. Chyba, że stwierdzisz, że jednak ich nie potrzebujesz...

Varran napisał(a)

2. Nie jestem pewien czy dobrze jest z tabela "OfertaKlienta" w sumei oferta klienta powinna zawierac takie dane np. w postaci listy prodoktow, zamawianych ilosci tych produktow i odpowiadajacych ich cen. Klienta nie moze dostac linku do Kalkulacji, to informacja wewnetrzna. (Chciaz z drugiej strony ta oferta bedzie efektem zapytania ktore poda tylko to co zaplanuje.)

W momencie kiedy klient składa zapytanie, w bazie pojawiają się kolejne rekordy tabeli KalkulacjaDlaProduktu, które wiążą zapytanie z produktem i ilością, ale nie mają jeszcze danych takich jak cena czy data. Sam decydujesz w swojej aplikacji o tym co zobaczy klient i kiedy, jeśli klient nie ma czegoś widzieć, to mu tego nie pokazuj.

Varran napisał(a)

3. Czy w takiej formie nadawanie uprawnien bedize bardziej elastyczne?

Będzie bardziej elastyczne, ale pytanie czy będzie bardziej efektywne (dla użytkownika) i czy na prawdę tego potrzebujesz... Jeśli tak, to myślę, że lepiej będzie przydzielać pracownikowi więcej niż jedną rolę (stanowisko), a dopiero rolom nadawać odpowiednie uprawnienia do poszczególnych zasobów.