poprawna baza i relacje w znormalizowanej postaci

Witam,
Mam do stworzenia program, który będzie obsługiwał bazę MSSQL, pomijam w tym temacie wątek programistyczny gdyż prosiłbym o pomoc w utworzeniu przyzwoitej bazy danych. Wymyśliłem że moim tematem będzie program do obsługi sklepu dla pracowników, wyświetlanie widoków, tabel, edycja, dodawanie, usuwanie itp.
Bardzo zależy mi aby baza była zrobiona po bożemu, czyli w 3 postaci normalnej, ponad 8 tabel, mam trochę problemów z wymyśleniem jakich, a nie chce też za bardzo skomplikować, jak na http://ifotos.pl/zobacz/projekt_qpeapr.png/

Zamieszczam screen jak i plik .mvb gdzie stworzyłem bazę gdyby ktoś wolał operować na tym(w Workbenchu jest to bardzo przejrzyste, w MSSQL Server Managment nie znalazłem podobnej opcji niestety)

Mam również problem z wyborem typu dla poszczególnych pól, oczywiście dam NOT NULL, ale co wybrać dla takich jak Cena [ money? double? decimal(16,2)? ], kodpocztowy [varchar(5)?, varchar(6)?, int? ]

Pozdrawiam

http://www.speedyshare.com/files/29074374/sklep.mwb

Nie wiem co to Workbench, ale w MSSQL można generować diagramy (w ramach bazy "katalog" Database diagrams").

Cena to kwota pieniędzy, więc raczej typ money. Kod pocztowy - dla Polski to char(6) (a nawet char(5), jeśli ktoś jest sprytny), ale nie wiem jak w innych krajach. Ogólnie być może dobrze trzymać miasta, kody pocztowe, kraje w słownikach.
Fakturę chyba należałoby jakoś połączyć z Produktami. Do tego faktura ma jeszcze datę wystawienia, zapłaty, kwotę łączną, itp.
Nie bardzo rozumiem czemu w encji Produkt jest pole Ilosc. Moim zdaniem Produkt to opis produktu, a ilość produktu to kwestia magazynu.

Ogólnie jakieś takie niepowiązane te tabele, więc trudno coś więcej powiedzieć.

somekind napisał(a)

Ogólnie być może dobrze trzymać miasta, kody pocztowe, kraje w słownikach.
Możesz rozwinąć?

somekind napisał(a)

Moim zdaniem Produkt to opis produktu, a ilość produktu to kwestia magazynu.
Sugerujesz

CREATE TABLE Produkty 
(
Produkty_ID INT IDENTITY (1,1) PRIMARY KEY NOT NULL,
Nazwa NVARCHAR(150) NOT NULL,
Cena MONEY NOT NULL
)

CREATE TABLE Magazyn
(
Magazyn_ID INT IDENTITY(1,1) PRIMARY KEY NOT NULL,
Ilosc INT NOT NULL,
)

ALTER TABLE Produkty ADD Magazyn_ID INT NOT NULL

ALTER TABLE Produkty ADD FOREIGN KEY (Magazyn_ID ) REFERENCES Magazyn (Magazyn_ID) 

Zgodne to z 3postacią normalną?

somekind napisał(a)

Ogólnie jakieś takie niepowiązane te tabele, więc trudno coś więcej powiedzieć.
Stąd moja prośba o pomoc, bardzo się obawiam etapu projektowania bazy, później już pójdzie z górki.
Dziękuję za odpowiedź i pozdrawiam

1. poczytaj o tabelach słownikowych. Powinny się tam znaleźć takie dane (dla każdego jedna tabela z id i nazwą) jak kraj, miasto, ulica.
2. wg Ciebie to magazyn jest w produkcie a logika podpowiada, że to jednak produkt leży na magazynie. To raz, dwa to to, że stan magazynu wynika z ruchów magazynowych - czyli zakup towaru zwiększa stan magazynu a sprzedaż go zmniejsza. Do tego dochodzą jeszcze takie rzeczy jak możliwość przesunięcia towaru z magazynu do magazynu (przecież może być więcej niż jeden magazyn) i inwentaryzacje :p

Zanim się zabierzesz za projektowanie bazy MUSISZ mieć jakiekolwiek pojęcie o tym jak faktycznie dana dziedzina wygląda. Weź sobie jakąkolwiek fakturę, np. z googla, zobacz co na niej jest, jakie pola potrzebujesz. Następnie weź kartkę wypisz w słupku wszystkie te pola. Potem spróbuj przyporządkować co będzie do produktu, co do klienta, co do faktury, co do pozycji faktury itd.

Faktura musi być zapisywana w dwóch tabelach (poczytaj o tabelach master - detail) - nagłówek w jednej i pozycje w drugiej

Znajdzie się jakaś duszyczkazorientowana w tym odpowiednio z 5 wolnymi 5 minutami ?:)

somekind napisał(a)

Ogólnie być może dobrze trzymać miasta, kody pocztowe, kraje w słownikach.

Moim zdaniem ma to sens tylko wtedy, gdy zaciągniemy sobie do bazy cały TERYT razem z miastami i ulicami (XMLe ważące w sumie ponad 100 MB). W przeciwnym razie pozostaje nam budowanie słowników przyrostowo na podstawie danych wprowadzanych przez użytkowników, co jest w większości przypadków bez sensu, bo i tak nie mamy żadnej kontroli nad ich poprawnością.
O ile w przypadku miast moglibyśmy zaoszczędzić trochę miejsca w bazie, bo gdyby się powtarzały, to trzymalibyśmy w tabeli klientów tylko identyfikator ze słownika, o tyle w przypadku ulic ilość rekordów w słowniku równałaby się w przybliżeniu ilości klientów.
Co do kodów pocztowych, to nie wiem, czy można gdzieś za friko dostać ich listę - może na eMule ;)
Te wszystkie przemyślenia to oczywiście z praktyki. Wszelkie projekty do szkoły, czy na studia mają z nią zwykle niewiele wspólnego.

uczen94 napisał(a)

Znajdzie się jakaś duszyczkazorientowana w tym odpowiednio z 5 wolnymi 5 minutami ?:)

znaczy szukasz jelenia, który to za ciebie zrobi... Zapomnij

scovron napisał(a)

Moim zdaniem ma to sens tylko wtedy, gdy zaciągniemy sobie do bazy cały TERYT razem z miastami i ulicami (XMLe ważące w sumie ponad 100 MB). W przeciwnym razie pozostaje nam budowanie słowników przyrostowo na podstawie danych wprowadzanych przez użytkowników, co jest w większości przypadków bez sensu, bo i tak nie mamy żadnej kontroli nad ich poprawnością.

Wystarczy, aby w organizacji były osoby odpowiedzialne za ich kontrolę - rozwiązanie z praktyki. Ale łatwiej (i taniej) wgrać dane z TERYTA.

O ile w przypadku miast moglibyśmy zaoszczędzić trochę miejsca w bazie, bo gdyby się powtarzały, to trzymalibyśmy w tabeli klientów tylko identyfikator ze słownika, o tyle w przypadku ulic ilość rekordów w słowniku równałaby się w przybliżeniu ilości klientów.

W normalizacji chodzi nie tylko o oszczędność, ale także o spójność danych.

Co do kodów pocztowych, to nie wiem, czy można gdzieś za friko dostać ich listę - może na eMule ;)

Ale czemu ktoś miałby dostawać coś za darmo? Jeśli ktoś potrzebuje listy wszystkich kodów pocztowych to go na nią stać.

Poprawny projekt bazy danych ma sens zawsze. Nawet jeśli to tylko zadanie do szkoły i nie będziemy słowników wypełniali wszystkimi danymi.