Mam wykonać projekt bazy danych sklepu spożywczego do szkoły. Muszę zrobić diagram ERD, a potem napisać wszystko w SQL, zainsertować jakieś wymyślone dane i napisać kilka przykładowych zapytań. Wydaje mi się, że na diagramie wszystko działa i jest zachowana logika. Ale nie mam pojęcia jak miałaby wyglądać sytuacja, w której klient składa jedno zamówienie, w którym zamawia wiele produktów naraz. Jeśli tylko jeden produkt na jedno zamówienie, to nie ma problemu, ale nie wiem jak wyglądałby np. rekord w bazie danych, gdzie mam jedno ID zamówienia i kilka ID produktów naraz. Jeżeli są jeszcze jakieś inne błędy, to prosiłbym również o ich wskazanie. Diagram w załączniku. Z góry dziękuję za pomoc.
0
3
W przypadku większej ilości produktów na zamówieniu masz relacje jeden do wielu - jedno zamówienie do wielu produktów. Ilość z zamówienia powinna być w tabeli Zamowienia_produkty - wówczas będziesz miał wiele rekordów do jednego zamówienia z różnymi produkatami i ilościami.
W bazie bedzie coś takiego
| id_zazmowienia_produkty | id_zamowienia | id_produktu | ilosc |
|---|---|---|---|
| 1 | 1 | 2 | 315 |
| 2 | 1 | 3 | 20 |
| 3 | 1 | 4 | 200 |
| 4 | 2 | 1 | 145 |
| 5 | 2 | 4 | 156 |
4
Zaznaczyłem 2 wątpliwe punkty.
Dlaczego wymagasz by Pracownik i Klient mieli przynajmniej 1 zamówienie? W takim modelu nie jest możliwe utworzenie pracownika czy klienta bez tworzenia zamówienia.
O ile Klienta można jeszcze zrozumieć (Rejestracja możliwa tylko przy składaniu zamówienia), to dla Pracownika ciężko to uzasadnić.
0
@yarel: Faktycznie większy sens ma możliwość stworzenia konta przez klienta bez konieczności składania zamówienia oraz możliwość zatrudnienia pracownika bez konieczności od razu przydzielania mu zamówienia do zrealizowania. Zmieniłem wskazane wyżej punkty, ale wciąż nie jestem pewny jak czytać te relacje. Czy mój diagram mówi, że "Jeden klient może mieć 0 lub wiele zamówień, zaś jedno lub wiele zamówień może mieć tylko jednego klienta, a jeden pracownik może mieć wiele zamówień do realizacji, zaś jedno lub wiele zamówień może mieć przydzielonego tylko jednego pracownika"? Bo chyba nie do końca jeszcze rozumiem te relacje.
2
Nie wiesz jak czytać? Podpisz, to następnym razem będziesz wiedział.
Jako twórca modelu powinieneś odbiorcom ułatwić zrozumienie. Jeśli Ty jako twórca nie jesteś w stanie go zrozumieć, to co dopiero odbiorca? :)
W przypadku prostych domen można się domyślać/zgadywać.
- Relacje - "Pracownik" , "Klient", ... (rzeczowniki w liczbie pojedynczej)
- Związki - opisuje to co jest między relacjami (czasownik) ; tu masz 2 kierunki i mogą być różne czasowniki użyte do pisania związku w zależności od kierunku, np.
- Klient - składa -> Zamówienie (0..N)
- Zamówienie -> jest składane przez Klienta (dokładnie 1)
- Opcjonalność (musi/może), Krotność (ile instancji relacji=ile encji wchodzi w skład takiego związku)
Czasem między relacjami możesz mieć wiele związków, np.
- Pracownik - przyjmuje -> Zamówienie
- Pracownik - dostarcza -> Zamówienie
- Pracownik - anuluje -> Zamówienie
Przechodząc z modelu na coś bardziej namacalnego, czyt. tabele, klucze, wiersze, będziesz miał:
- Tabele: Pracownik, Zamówienie
- Atrybuty w tabeli Zamówienie (odnoszące się do różnych związków):
przyjete_przez,dostarczone_przez,anulowane_przez - Klucze obce do tabelki Pracownik (przyjete_przez -> Pracownik, itd.)
Jeśli na diagramie zostawisz same kreski, bez nazywania rzeczy po imieniu, to nie będzie wiadomo o co chodzi. Patrzy przykład jak NIE modelować 3 związków ;-)
0
@UglyMan: Dziękuję za odpowiedź. Właśnie wpisuję przykładowe dane do kolejnych tabel i kolumn. Jestem teraz przy tabelach zamowienie i zamowienie_produkt. Mam jedną wątpliwość - chciałem wpisywać kolejno ID zamówień oraz ID produktów do tabeli zamowienie, ale zdałem sobie sprawę, że w taki przypadku mogę przypisać do jednego zamówienia tylko jeden produkt, a tego nie chcemy. Zaś w tabeli zamowienie_produkt, gdzie miało pojawiać się kilka razy to samo ID zamówienia z różnymi ID produktu w przypadku zamówienia z kilkoma produktami, chyba nie będzie się tak mogło pojawiac, bo id_zamowienia jest kluczem obcym dla klucza głównego id_zamowienia w tabeli zamowienie, więc muszą to być chyba wartości unikalne. Czy powinienem więc usunąć id_produktu z tabeli zamowienie i zostawić je tylko jako klucz obcy w tabeli zamowienie_produkt?