Witam.
Na zaliczenie z ćwiczeń potrzebuję zrobić prostą bazę danych. Całą bazę danych mam już zrobioną, pytanie tylko czy odpowiednio ją połączyłem.
Jakby ktoś bardziej zaawansowany miał chwilę i mógł spojrzeć, za wszystkie rady dziękuje z góry!
www.sendspace.com/file/f628xq"]Baza.mwb ( link do bazy danych w MySql Workbench)
Niby wszystko ok, ale np. raportu w stylu "ile ASG sprzedało się w oddziale X" albo "który pracownik ma największa sprzedaz wiatrówek" na podstawie tej bazy nie zrobisz?
No nie wszystko ok... Tabele wiatrówki, broń ręczna i repliki ASG są identyczne, więc czemu trzymasz to oddzielnie? Lepiej zrobić jedną tabelę i dodać pole "typ broni". Dodatkowo, czy w przypadku sklepu nie powinieneś gdzieś przechować historii sprzedaży/stanu magazynowego?
[edit] Jak chcesz to odezwij się na priv (pod tym samym nickiem znajdziesz mnie choćby na stackoverflow albo wykopie) to pogadamy o szczegółach :)
Dzięki za porady! Właśnie pracuję nad połączeniem typów w jedno i coś ze sprzedażą :3
Jaki jest sens trzymania liczby pracownikow i liczby oddzialow jako parametry firmy, skoro te informacje sa w osobnych tabelach? To samo z liczba pracownikow w oddziale, i brak powiazania pracownika z konkretnym oddzialem.
Przyznaje, ze z accessem nie pracuje, i moze tam sie to tak robi, ale z punktu widzenia normalnej bazy danych jest to mocno dziwne.
Osobiscie zrobilbym powiazania:
firma -= oddzial -= pracownik - funkcja
oferta (wszystko w sprzedarzy) - typ broni (zdefiniowany podobnie jak funkcje pracownikow)
(-= jeden do wielu; - jeden do jeden)
@wysiak: nie zwróciłem uwagi ale faktycznie masz rację - częściowo. :) Chodzi mi o to, że pracownik jest powiązany z firmą a nie oddziałem? Przecież musi być w którymś oddziale zatrudniony a że oddział podlega firmie to połączenie jest banalne. W tym schemacie zapisujesz info o tym, że Kowalski pracuje dla firmy XYZ ale nie, czy robi to w Sosnowcu czy Radomiu :)
[edit] Aha, i powinieneś w bazie trzymać też informacje o modelach broni. Obecnie masz id_modelu ale nigdzie nie ma wyjaśnienia, co dany numerek oznacza...
Trochę lepiej. Ale dalej:
1. Po co łączysz pracownika z firmą? Przecież relacja pracownik->oddział->firma wystarczy
2. czemu "potrzeba_pozwolenia" jest varchar? Toż to zwykłe tak/nie
3. Dalej brakuje historii sprzedaży.
A z niuansów zależnych od faktycznych potrzeb to masz stan magazynów poszczególnych oddziałów ale nie ma magazynu centralnego, który może być oddzielny.
A z niuansów zależnych od faktycznych potrzeb to masz stan magazynów poszczególnych oddziałów ale nie ma magazynu centralnego, który może być oddzielny.
Tu w zasadzie wystarczy zdefiniowac oddzial glowny firmy, przypiac do niego magazyn centralny, i po sprawie. W zasadzie chyba nawet trzeba byloby tak zrobic tak czy owak, jesli chcialoby sie trzymac dane np o adresie firmy.
Co do 2, to nie wiem jak zrobić żeby było tak/nie. Nad 1 się zastanowię i chyba zrobię tak jak mówisz, Moby :) A nad historią też się zastanawiam :3
Mozesz po prostu wprowadzić encje Zamówienia między Oddział, a Broń i to Ci powinno załatwić histroię sprzedaży.
Dodatkowo of cuz relacja miedzy Zamowieniem a Pracownikiem
Ad 1
Jeśli nie ma pracowników centralnych, to możesz zrobić tylko relacje do Oddziału. W innym przypadku przez relacje do Firmy zamodelujesz tych, którzy nie pracują w żadnym z oddziałów.
@wysiak
Tu w zasadzie wystarczy zdefiniowac oddzial glowny firmy, przypiac do niego magazyn centralny, i po sprawie
Niby tak ale w tej opcji przydałaby się jednak flaga "spółki matki"... Na upartego można uznać, że wszystkie oddziały, które nie mają powiązania do nadrzędnych są "matkami". No ale wtedy po co oddzielać tabele firma od oddział? Toż to klasyczna relacja 1-m na tą samą tabelę się robi.
@Favonius: Jeśli chodzi o tak/nie to prostu zapisuj wartości 0/1 - w zależności od konkretnego silnika to boolean, tinyint albo int(1).
@Cainoor:
Jeśli rozwiążesz kwestję centrali tak jak zasugerował wysiak to wszyscy pracownicy muszą być przypisani do oddziału...
Moby04
W takim przypadku faktycznie zrezygnowałbym z dwóch encji Firma/Oddział i zostawił tylko Oddział wraz z flagą typu "głowny" i po sprawie.
Zrobiłem główny oddział i magazyn. Oczywiście w Foreign Keys połączyłem żeby było przejrzyściej czyli połączenia są wszędzie. Pytanie tylko czy dobre, oraz nadal nie jestem pewny co do sprzedaży.
Jeszcze raz wielkie dzięki i czekam na kolejne porady :D
1. Wydaje mi się, że nie masz potrzeby posiadania dwóch encjii Oddział. Wystarczy jedna i flaga jako atrybut, czy to główny czy nie. Analogicznie Magazyn.
2. Co do nowej encji Sprzedaż to zakładam, ze na jednym zamówieniu można wziąć więcej niż 1 typ broni? :) I teraz jak to zamodelujesz? Standardowo robi się coś takiego, że masz jakiś nagłówek sprzedaży (gdzie masz właśnie informacje odnośnie kto sprzedał, kiedy, komu -> btw. gdzie baza klientów?? ;-), a dodatkowo masz encje z liniami sprzedaży, gdzie masz relacje miedzy liczba sztuk, a typem produktu (w tym przypadku broni).
Cainoor masz rację, ale aż tak głęboko nie chce wnikać. Jako że to jest coś pierwszego, chce żeby były błędy, żeby wykładowca widział że robiłem i próbowałem i mi nie wychodziło. Mam chociaż nadzieję że w porównaniu do pierwszego modelu zmieniło się dużo i to na lepsze.
Jeszcze raz wszystkim dziękuję :3
Magazynu głównego w tym schemacie nie potrzebujesz w sumie - wystarczy uznać, że to ten przypisany do głównego oddziału (tak jak pisze Cainoor flaga wystarczy).
Dodatkowo nie wiązałbym bezpośrednio produktu ze sprzedażą. Na pierwszy rzut oka może wyglądać ok ale pamiętaj, że parametry produktu (cena, [EDIT]swoją drogą stawki podatkowe też warto zapisać[/EDIT]) mogą się zmienić a nie możesz sobie pozwolić na stratę tak ważnych danych.
Dodatkowo, tak jak powiedział Cainoor, jedna transakcja może obejmować wiele towarów (ba! w tym przypadku do pistoletu wypadałoby też chyba amunicję kupić?). No i fajnie byłoby zapisać informację o tym KOMU broń była sprzedana... :)
Usunąłem magazyn główny, ale oddział bym zostawił, w końcu każda firma ma jakieś swoje biuro które zarządza ale nie prowadzi sprzedaży. Dodałem klientów, ale nie wiem czy o to wam chodziło :3
Szczerze mówiąc to spaprałeś. Przyczyny:
1. Fakt, każda firma ma siedzibę ale to jest właśnie oddział główny. Po co to dzielić?
2. Sprzedaż powinna dotyczyć asortymentu I klienta - w tym schemacie sprzedaż dotyczy jedynie klienta (produkty są połączone z klientem). Jak pan Zbysio będzie robił zakupy raz w miesiącu to za każdym razem stworzysz nowego klienta? Pomijam wydajność i objętość ale jak chcesz później znaleźć najaktywniejszych klientów?
3. Amunicję przypisałeś do broni. Tyle tylko, że ta sama amunicja może pasować do wielu pukawek i co ważniejsze...
4. Co jeśli wspomniany pan Zbysio wystrzelał co miał i chce kupić TYLKO amunicję? W tym schemacie jest przypisana do broni więc "panie nie da rady, musisz Pan nowego Colta kupić"? :P
[edit] Tu się już rozdrabniam ale może przy amunicji warto też zapisywać jej typ (ślepaki, przeciwpancerne, etc)? :)
Już prawie jest dobrze. Bez pośpiechu. Podoba mi się, że sam starasz się to poprawić i kombinujesz. Takiej osobie z przyjemnością można pomagać :)
1. Naprawde wg mnie ten główny oddział można złączyć z oddziałami. Nawet jeśli nie prowadzi sprzedazy, to to nic nie zmienia. Co go wg Ciebie wyróżnia? Atrybuty ma takie same.
2. Klientów zrób jako encje powiazana tylko ze sprzedaza, a bron tak jak byla tez ze Sprzedaza
3. Amunicja to juz imo zbyt duza komplikacja :P To juz lepiej wprowadzic linie sprzedazy z liczba sztuk i cena sprzedazy w danym momencie
Zniosłem oddział główny. Jeśli chodzi o amunicje połączyłem ją z klientem. A tabelka klienci powstała z połączenia sprzedaży z bronią ( wielu do wielu ) a tabelka bron_ma_amunicje też powstała z wielu broni do wielu amunicji. Klucze połączyłem żeby były bezpośrednio połączone. Nie wiem czy o to chodziło :(
Ja bym wprowadził te dwie modyfikacje (o amunicji się nie wypowiadam, bo imo to nadmiar jak na zaliczenie;):
1. Sprzedaż powinna być bezpośrednio połączona z Bronią, a nie przez Klientów (na razie model uproszczony, gdzie cena broni nie jest zmienna wczasie).
2. Klienci nie powinni byc połączeni z Bronią (jak chcesz wiedzieć co dany klient kupił, zawsze możesz zrobić zapytanie przez Sprzedaż)
Całkowicie popieram Cainoora - starasz się i to widać. Nawet jak bywam szorstki to pomogę. :)
W sprawie amunicji to (jeśli uznajemy to za istotny element "układanki") czemu chcesz to wiązać z klientem a nie transakcją jako taką?
Czyli robię oddzielną tabelke klienci oraz sprzedaż łącze wiele do wielu z amunicją i wiele do wielu z bronią. Tylko wtedy mi się stworzą 2 kolejne tabelki, jak je nazwać i co z kluczami?
Utwórz tabelę "produkt", która będzie zawierać relację do broni albo amunicji. Z kolei tabela "sprzedaż" (sensowniej byłoby "transakcja" swoją drogą) łączy się z klientem i z produktem. Dzięki temu możesz sprzedać broń bez amunicji albo amunicję bez broni.
Zmieniłem połączenia, tylko teraz nie wiem czy nie mam zbędnych tabel. Pomysły?
No niestety ale masz. Czym się różni sprzedaż amunicji od sprzedaży broni? To przecież wciąż produkt-nabywca. druga sprawa, po co tabela "kupno"?
Spróbuję połączyć amunicje i broń w jedną tabele, potem ze sprzedażą. A tabelka kupno powstała z relacji wiele sprzedaży do wielu klientów.
No ale jak? Wielu klientów robi jeden zakup? No pomyśl chwilę :)
ps. Ale i tak jest już nieźle.
Już jest nieźle :)
Spokojnie na pierwszą wizytę u prowadzącego możesz z tym iść. :)
[edit] chociaż w sumie sprzedaż produktu wydaje się zbędna... albo źle nazwana
Dobra dzięki jeszcze raz chłopaki! Chociaż czekam na ostatnie słowo Cainoora i temat do zamknięcia :)
Fajnie się pomaga jak ktoś nie woła od razu gotowca więc też dzięki :)
[edit] Tylko pamiętaj, że decyzje projektowe musisz umieć wyjaśnić!
A ja zauważyłem jeden drobiazg jeszcze: pole "ilosc_sztuk" powinno być w tabeli "sprzedaz_produktu" raczej. W końcu pojedyńcza transakcja może obejmować wiele pozycji (np. 1 pistolet i 10 opakowań amunicji). Ale to detal, który można przepchnąć na pierwszych konsultacjach :)
