Problem z utworzeniem właściwej tabeli

0

Witam, dostałem do zrobienia projekt bazy danych sklepu komputerowego. Wykładowca zażyczył sobie, żeby każdy podzespół był dokładnie opisany, co uniemożliwia mi łatwe wprowadzanie towarów do magazynu. Moja baza ma spełniać funkcje zakupu części od dostawców, składanie komputera/zestawów komputerowych, oraz ich sprzedaż. Możliwy ma być też zakup pojedynczego towaru. Problem polega na tym, że jeśli chciałbym kupować wszystkie towary oddzielnie to musiał bym mieć klucze podstawowe zarówno w tabeli z magazynem i w tabelach z częściami...na fakturze zakupu również pojawiło by się wiele kluczów, nie wiem jak sobie z tym poradzić, mam nadzieję, że mogę liczyć na waszą pomoc. Pozdrawiam

Oto moja baza (Tabela "Towary" jeszcze nie usunięta, miałem zamiar przerobić ją na tabelę "Magazyn" i podpiąć do niej każdą tabelę z częściami (Procesory, Monitory itp.). Proszę nie zwracać też uwagi na typy danych, bo prawie wszędzie jest INTEGER,na razie muszę zrobić poprawne relacje i tabele a dopiero na końcu zajmę się tymi typami. Projekt wykonuję w programie DBDesigner.

Daję link, ponieważ obrazek nie zmieści się na forum:

Link -> http://img87.imageshack.us/img87/3420/baza.png

0

Powinieneś mieć jedną tabelę Towary, w niej trzymać i pamięci, i dyski, i monitory, i cokolwiek tam masz. Nie ma sensu robienie miliona tabel, tak jak Ty to zrobiłeś. To Ci znacznie uprości bazę. Do tego tabela AtrybutyTowarów (Id, IdTowaru, NazwaAtrybutu, Wartość), w której będziesz trzymał i częstotliwość pamięci, i rozmiar dysku, i przekątną monitora. Każdy towar będzie miał tam tyle wpisów ile potrzeba. Można się w zasadzie pokusić nawet o tabele TypTowaru i TypAtrybutu, żeby to ładnie znormalizować.
Do tego tabela Faktury z tym, co tam jest potrzebne i tabela PozycjeFaktur, wiążąca Fakturę z Towarem.
Nie widzę sensu istnienia czegoś takiego jak "zestaw komputerowy". Z punktu widzenia sprzedaży to tylko kilka pozycji na fakturze.

0

Dziękuję za odpowiedź. Ale podczas próby stworzenia tego o czym napisałeś zacząłem się zastanawiać jak później wprowadzać do bazy towar jeśli będzie trzeba podać kilka atrybutów? Np. ktoś sobie zażyczy procesor "Intel" "Core2Duo" "2GHz", a to są już 3 atrybuty, bo rozumiem, że wprowadzanie atrybutów do tabeli ma polegać na tym:

Id_atr Nazwa_atr wartosc
P1 Producent Intel
P2 Producent AMD
P3 Predkosc 2GHz
P4 Predkosc 2,5GHz
P5 FSB 800MHz
P6 FSB 667MHz

=> http://img186.imageshack.us/img186/8940/baza2.png

0

Producentów wrzuciłbym do oddzielnego słownika.
Zrobiłbym też słownik typów produktów ("Procesory", "Pamięci", "Klawiatury", itd.).
W Atrybuty_Towarów musisz mieć jakieś powiązanie do tabeli Towary, a Ty zrobiłeś odwrotnie! Jeden Towar może mieć 0 lub więcej Atrybutów, tak jak teraz to wymuszasz powiązanie 1:1, co jest bez sensu.
A ponieważ atrybuty będą się powtarzały dla danych grup, to też dałbym je do słownika, np. (FSB, Prędkość obrotowa, szerokość,...).

Podsumowując - ja bym widział tabelę Towary połączoną z Producenci, Typy_towaru i posiadającą kolumnę nazwa. Do tego tabela Atrybuty_towaru, która ma wskazanie na Towary oraz powiązana z tabelą Typ_atrybutu.

Nie jestem pewien, czy w tabeli Towary powinna być przechowywana ilość czy też cena produktu. Moim zdaniem tu powinien być tylko opis towaru, a ceny w jakiejś tabeli Oferta, która zawierałaby też daty obowiązywania. Wtedy można śledzić zmiany cen w czasie, itd. (No chyba, że nie ma takiej potrzeby).

Masz trzy tabele do faktur, które są w zasadzie identyczne... Ja bym zrobił jedną tabelę Faktury i dał jej kolumnę Typ_faktury, ewentualnie ze wskazaniem na słownik typów faktur.

No i Faktury z Towarami są powiązaniem N:N, więc bez tabeli pośredniczącej się nie obejdzie.

Do tego masz całkiem pokićkane typy danych. Ale to chyba wiesz i poprawiasz?

0

Tak wiem o złych typach danych, na razie chcę tylko utworzyć właściwe tabele i relacje, później zajmę się typami, bo to już tylko formalność. Zgodnie z Twoimi wskazówkami utworzyłem nowe tabele. Teraz już jakoś to wygląda, nie to co na początku. Zdecydowałem, żeby pozostawić ilości oraz ceny towarów w tabeli "Towary", nie chcę, żeby ta baza była strasznie skomplikowana, bo w końcu się w tym pogubię.

Tak to teraz wygląda -> http://img832.imageshack.us/img832/6131/baza3f.png

EDIT: Teraz zauważyłem, że skoro mam tabelkę TYP_TOWARU (która ma określać, czy to jest procesor czy klawiatura) to w tabeli TOWARY nie potrzebuję chyba kolumny Nazwa? Bo przecież nazwą ma być to czy to jest klawiatura czy monitor. Dodatkowo w tabeli Towary nie mogę określić jakie atrybuty będą miały poszczególne towary, a przecież procesor będzie miał kilka tych atrybutów...jak sobie z tym poradzić?

0

Dodatkowo w tabeli Towary nie mogę określić jakie atrybuty będą miały poszczególne towary, a przecież procesor będzie miał kilka tych atrybutów...jak sobie z tym poradzić?

Z czym masz problem?! Dajesz wszystkie atrybuty częstotliwość zegara, cache itd do ATRYBUTY_TOWAROW i po zawodach.

0
radzix napisał(a)

EDIT: Teraz zauważyłem, że skoro mam tabelkę TYP_TOWARU (która ma określać, czy to jest procesor czy klawiatura) to w tabeli TOWARY nie potrzebuję chyba kolumny Nazwa?

:|
Jak to nie potrzebujesz kolumny nazwa? To gdzie będziesz przechowywał informację o tym, jak się produkt nazywa? Są różne procesory, np. i5 750, i5 760, Core 2 Duo T5600. Są różne dyski twarde, np. Barracuda ST31000528AS.
A Ty w ofercie będziesz miał tylko jeden procesor, który będzie się nazywał "procesor" i jeden dysk twardy, który będzie się nazywał "dysk twardy"?

0
somekind napisał(a)
radzix napisał(a)

EDIT: Teraz zauważyłem, że skoro mam tabelkę TYP_TOWARU (która ma określać, czy to jest procesor czy klawiatura) to w tabeli TOWARY nie potrzebuję chyba kolumny Nazwa?

:|
Jak to nie potrzebujesz kolumny nazwa? To gdzie będziesz przechowywał informację o tym, jak się produkt nazywa? Są różne procesory, np. i5 750, i5 760, Core 2 Duo T5600. Są różne dyski twarde, np. Barracuda ST31000528AS.
A Ty w ofercie będziesz miał tylko jeden procesor, który będzie się nazywał "procesor" i jeden dysk twardy, który będzie się nazywał "dysk twardy"?

Faktycznie, mój błąd, nie pomyślałem o tym.

AdamPL napisał(a)

Dodatkowo w tabeli Towary nie mogę określić jakie atrybuty będą miały poszczególne towary, a przecież procesor będzie miał kilka tych atrybutów...jak sobie z tym poradzić?

Z czym masz problem?! Dajesz wszystkie atrybuty częstotliwość zegara, cache itd do ATRYBUTY_TOWAROW i po zawodach.

Mój problem (za chwilę okaże się, że nie ma problemu) polega na tym, że w tabeli towary będę chciał podać kilka atrybutów dla danego towaru, przykładowo w tabeli Typ_Atrybutu będę miał coś takiego

ID_Typu TYP
PF FSB
PP Predkosc
PC Cache

Tabela Atrybuty_Towarów:

ID_Atrybutu ID_Typ_Atrybutu ID_Towaru Wartosc
AP1 PF T1 667
AP2 PF T2 800
AP3 PC T3 2MB
AP4 PP T4 2GHz

I teraz w tabeli TOWARY chcę dodać dla jakiegoś towaru 2 atrybuty. Czyli w Tabeli Towary wpisuję tylko pojedyncze towary i ich nazwy a atrybuty mam ustawiać w tabeli Atrybuty_towarów? Strasznie można się w tym wszystkim pogubić...

0
radzix napisał(a)

Strasznie można się w tym wszystkim pogubić...

Jeśli masz lepszy pomysł, w którym się nie pogubisz, to zrób to inaczej.

0

Ostatecznie wyszło mi takie coś, bardzo dziękuję wszystkim za pomoc, samemu było by mi trudno do tego dojść (ew. poprawki mile widziane) Pozdrawiam

link -> http://img51.imageshack.us/img51/9549/bazaa.png

0

Trochę dziwi mnie, że w tabelach po prawej stronie diagramu jako kluczy używasz typu char. Ja bym dał wszędzie integer.
Nazewnictwo nie moje, ale spójne i zrozumiałe, więc ok.
Masz farta z tym, że dałeś 20 znaków na nazwę miasta, bo nazwa mojego akurat ma 20 znaków. :) Ale są dłuższe. Podobnie na nazwę towaru dajesz tylko 30 znaków, czasem to może nie wystarczyć (patrząc chociażby na nazwy niektórych kart graficznych). 10 znaków na numer telefonu to też za mało (nawet bez spacji, nawiasów i myślników, nie zmieści się w tym międzynarodowy numer kierunkowy).
Ja bym to przemyślał i nie oszczędzał na znakach w typie varchar, bo jaka to oszczędność?

Co jeszcze można zrobić, to utworzyć tabelę adresy, wsadzić do niej kolumny Ulica, Kod_pocztowy, Miasto i oczywiście jakieś Id, i połączyć ją z tabelami Dostawcy, Klienci, Pracownicy. Centralna tabela adresów czasem ułatwia życie.

Spec_Faktury i Towary - tutaj wielu rzeczy chyba nie rozumiem.

  • Wydaje mi się, że symbol PKWiU określa dany Towar - jest jeden dla całego produktu na całą Polskę. Dobrze myślę? Bo jeśli tak, to ta kolumna powinna być w tabeli Towary.
  • Jm to jednostka miary, tak? (BTW - bardzo zła nazwa kolumny, nic ona nie mówi). Jednostka miary również określa Towar, a nie pozycję na fakturze. Podobnie rzecz ma się z Ceną_Jedn (jak sądzę równą zarówno Wartosc_bez% jak i Cena_Jsprzedazy z tabeli Towary), Podatek%.
  • Czym Wartosc_brutto ma się różnić od Do_zapłaty i czemu chcesz to trzymać w tej tabeli?
  • Stawka VAT, to nie jest dowolna liczba, tylko wartość z określonego zbioru. Ja bym je trzymał w oddzielnym słowniku.
0
somekind napisał(a)

Trochę dziwi mnie, że w tabelach po prawej stronie diagramu jako kluczy używasz typu char. Ja bym dał wszędzie integer.
Nazewnictwo nie moje, ale spójne i zrozumiałe, więc ok.
Masz farta z tym, że dałeś 20 znaków na nazwę miasta, bo nazwa mojego akurat ma 20 znaków. :) Ale są dłuższe. Podobnie na nazwę towaru dajesz tylko 30 znaków, czasem to może nie wystarczyć (patrząc chociażby na nazwy niektórych kart graficznych). 10 znaków na numer telefonu to też za mało (nawet bez spacji, nawiasów i myślników, nie zmieści się w tym międzynarodowy numer kierunkowy).
Ja bym to przemyślał i nie oszczędzał na znakach w typie varchar, bo jaka to oszczędność?

Co jeszcze można zrobić, to utworzyć tabelę adresy, wsadzić do niej kolumny Ulica, Kod_pocztowy, Miasto i oczywiście jakieś Id, i połączyć ją z tabelami Dostawcy, Klienci, Pracownicy. Centralna tabela adresów czasem ułatwia życie.

Spec_Faktury i Towary - tutaj wielu rzeczy chyba nie rozumiem.

  • Wydaje mi się, że symbol PKWiU określa dany Towar - jest jeden dla całego produktu na całą Polskę. Dobrze myślę? Bo jeśli tak, to ta kolumna powinna być w tabeli Towary.
  • Jm to jednostka miary, tak? (BTW - bardzo zła nazwa kolumny, nic ona nie mówi). Jednostka miary również określa Towar, a nie pozycję na fakturze. Podobnie rzecz ma się z Ceną_Jedn (jak sądzę równą zarówno Wartosc_bez% jak i Cena_Jsprzedazy z tabeli Towary), Podatek%.
  • Czym Wartosc_brutto ma się różnić od Do_zapłaty i czemu chcesz to trzymać w tej tabeli?
  • Stawka VAT, to nie jest dowolna liczba, tylko wartość z określonego zbioru. Ja bym je trzymał w oddzielnym słowniku.

W tabelach po prawej używam typu CHAR ponieważ chcę łatwo (dla siebie) oznaczyć konkretne pozycje w bazie, np. tabela TYP_PRODUKTÓW:

PG Płyta główna
PC Procesor
KG Karta graficzna
DT Dysk twardy

TYP_ATRYBUTU:

PG1 Rodzaj procesora
PG2 Ilość USB
PG3 Chipset
PG4 FSB
PG5 Rodzaj RAM
PG6 Sloty RAM
PG7 Złącze HDD
PC1 Socket
PC2 Prędkość
PC3 Cache

Faktycznie trochę pożałowałem tych znaków w niektórych miejscach, ale to łatwo zmienić. Tabelkę z adresami sobie podaruję, ale dzięki za pomysł.
Co do stawki VAT, w skrypcie SQL dodałem "CHECK (Podatek IN ('7', '22'))" (zmieniłem nazwę kolumny z Stawka_VAT na Podatek).
Wartosc_bez% to Cena_Jedn*Ilosc. Tabela Spec_faktury będzie dotyczyć zarówno faktur zakupu jak i sprzedaży, więc Ceną_Jedn na fakturze zakupu będzie cena mniejsza niż Cena_Jsprzedazy z tabeli Towary. Natomiast na fakturze sprzedaży Cena_Jedn=Cena_Jsprzedazy(z tabeli towary)
Wartość_brutto to wartość jakiejś ilości towaru wraz z doliczoną kwotą podatku (np. 5 szt procesorów -> 3000zł to jedna wartość_brutto, 4szt. monitorów -> 2000zł to druga wartość_brutto) a kolumna Do_zapłaty będzie łączną sumą wszystkich wartości_brutto. Chyba lepiej będzie ją przenieść do tabeli Faktury.

0
radzix napisał(a)

W tabelach po prawej używam typu CHAR ponieważ chcę łatwo (dla siebie) oznaczyć konkretne pozycje w bazie

No można i tak... Tylko, że baza danych nie ma być czytelna dla użytkownika, ma po prostu przechowywać dane.

Co do stawki VAT, w skrypcie SQL dodałem "CHECK (Podatek IN ('7', '22'))" (zmieniłem nazwę kolumny z Stawka_VAT na Podatek).

Czyli za dwa miesiące projekt będzie do wyrzucenia w związku ze zmianą stawek?

Wartosc_bez% to Cena_Jedn*Ilosc. Tabela Spec_faktury będzie dotyczyć zarówno faktur zakupu jak i sprzedaży, więc Ceną_Jedn na fakturze zakupu będzie cena mniejsza niż Cena_Jsprzedazy z tabeli Towary. Natomiast na fakturze sprzedaży Cena_Jedn=Cena_Jsprzedazy(z tabeli towary)

Czyli w tabeli Spec_Faktury Cena_jedno = Cena_Jzakupu dla faktury zakupu albo Cena_Jsprzedazy dla faktury sprzedaży.
Zatem dublujesz dane.

Wartość_brutto to wartość jakiejś ilości towaru wraz z doliczoną kwotą podatku (np. 5 szt procesorów -> 3000zł to jedna wartość_brutto, 4szt. monitorów -> 2000zł to druga wartość_brutto) a kolumna Do_zapłaty będzie łączną sumą wszystkich wartości_brutto. Chyba lepiej będzie ją przenieść do tabeli Faktury.

I tutaj też dublujesz dane. Każdą wartość możesz wyliczyć na podstawie Spec_faktury.Ilosc, Towary.Cena_Jsprzedazy i Towary.Podatek%. (Hmm... w sumie to dziwne dawać % w nazwie... Tak się w ogóle da?).

Owszem, można powielać dane ze względów wydajnościowych. Ale może to spowodować ich niespójność. Jeśli to projekt na studia, to Twoja baza na 90% powinna być znormalizowana, a jak na razie nie jest.

0

Będę musiał później uzupełnić tabele przykładowymi danymi za pomocą INSERTów, więc żeby się nie pogubić albo pomylić wolałem sobie oznaczyć ID w tabelkach za pomocą CHARów.

Faktycznie z tą stawką VAT dobrze podpowiedziałeś, dorobiłem dodatkową tabelkę.

Poprzenosiłem dane z tabeli Spec_faktury do Towarów, i teraz patrząc na tą tabelę (spec_faktury) zastanawiam się, czy nie usunąć pozycji z "wartościami", które później można wyliczyć i utworzyć za pomocą widoków? Zostawił bym tylko pozycję "Ilość", bo to nie będzie taka sama pozycja jak w tabeli Towary ( wiadomo, towarów mogę mieć 10, a na fakturze sprzedać przykładowo 5 sztuk)

Projekt oczywiście na studia, więc normalizacja jest wskazana.

-> http://img812.imageshack.us/img812/959/18748692.png

0
radzix napisał(a)

Będę musiał później uzupełnić tabele przykładowymi danymi za pomocą INSERTów, więc żeby się nie pogubić albo pomylić wolałem sobie oznaczyć ID w tabelkach za pomocą CHARów.

Skoro Ci tak łatwiej, a wykładowca nie będzie miał nic naprzeciwko.
Ale nie przyzwyczajaj się... Bo gdy np. w prawdziwej bazie będzie wymóg, aby wszystkie Id były typu GUID, to nie będzie łatwo. ;)

czy nie usunąć pozycji z "wartościami", które później można wyliczyć i utworzyć za pomocą widoków? Zostawił bym tylko pozycję "Ilość"

O to mi właśnie chodziło, żeby w tej tabeli były tylko numer faktury, id towaru i ilość towaru, a reszta była dynamicznie wyliczana. :)

0

Witam po krótkiej przerwie z kolejnym problemem. Otóż, chodzi o to, że skoro prowadzę bazę danych sklepu, to nie mogę sprzedawać towaru wyłącznie na faktury, przydała by się też możliwość sprzedaży za pomocą paragonów, gdzie nie potrzebował bym danych klientów. Wpadłem na pomysł, żeby dodać do tabeli TYP_FAKTURY (przydało by się zmienić nazwę) dodać opcję "paragon", wtedy nie musiał bym podawać żadnych danych klientów, tylko za pomocą tabeli SPEC_FAKTURY dodawać kolejne towary na paragon.W Tabeli FAKTURY ustawić wszystko by mogło być NULL oprócz klucza i Daty_zakupu. Myślicie, że to by zdało egzamin? Pozdrawiam

1 użytkowników online, w tym zalogowanych: 0, gości: 1