Mając ostatnio dość dużo czasu, postanowiłem się poduczyć projektowania baz danych. Stworzyłem sobie schemat takiej mini-piłkarskiej bazy danych i prosiłbym, żeby mi ktoś to sprawdził czy ma to w ogóle jakiś sens ;). Tak naprawdę to moje pierwsze projektowanie bazy danych (takiej większej) od podstaw, dlatego proszę o poprawki i rady, jak to powinno wyglądać.
Wydaje mi się, że jest ona zrobiona beznadziejnie, dlatego przybywam :P.
Schemat:
Dużo rzeczy do poprawki. Zastanów się jak możesz opisać klub, zawodnika, mecz itd. Jakie czynności mogą wykonać? Co może się z nimi dziać? Póki co zrobiłeś to pobieżnie i wiele rzeczy nie zostało przewidzianych w schemacie, np:
Oczywiście tych rzeczy jest więcej, ja pobieżnie sprawdzając znalazłem powyższe punkty.
Aby dobrze zaprojektować bazę trzeba NAJPIERW zrobić sobie listę WSZYSTKICH atrybutów, które chcesz mieć w bazie danych (czyli np. nazwisko piłkarza, nazwa drużyny, datę meczu, kwota sprzedaży zawodnika, data sprzedaży, itd). Bez tych danych będziesz się tylko irytował jak Ci się coś przypomni i nagle okaże się, że dotychczasowy schemat jest do du**.
Jak masz taką listę to grupujesz dane, np. dane opisujące zawodnika, dane opisujące stadion, dane opisujące drużynę, itd. Jakbyś szukał info to zwie się to normalizacją i jest to pierwszy etap.
Dzięki za wskazówki. Nie chciałem robić tego aż tak szczegółowo:
zawodnik strzela karnego, w którym meczu?
Bardziej chodzi mi o relacje pomiędzy tabelami i klucze w nich, z tym mam największy problem, jak to dobrze powinno wyglądać, bo w niektórych miejscach relacja 1:n pasuje w obie strony. Z samych książek czy tutoriali ciężko to wywnioskować bez praktycznego wykorzystania.
AdamPL napisał(a):
- zawodnik będzie występował na kilku pozycjach np. na środku obrony i jako defensywny pomocnik. Co zrobisz, zapiszesz go w bazie dwukrotnie?
- zawodnik występuje w meczu A na obronie, w mecz B w pomocy, gdzie to zapiszesz?
- zawodnik zmienia klub. Co zrobisz, zapiszesz go w bazie dwukrotnie?
- stadion został rozbudowany, co zrobisz?
A to update sam nie wystarczy, kiedy zajdzie taka potrzeba?
Ten schemat wcześniejszy jest też zły bo mi się strzałki pomyliły w tym całym Workbench'u.
@Misiekd: Dzięki, mam właśnie to tak rozplanowane, kwestia tego, jak połączyć tabele w całość, żeby te relacje były dobre.
Coś poprawiłem (a może jeszcze bardziej zepsułem).
widzisz sprawdzanie schematu to też nie do końca tak się da - Ty możesz mieć całkiem inne założenia niż ja i z Twoimi założeniami Twój schemat może być OK ale z moimi już nie (co masz na przykładzie tego, co napisał Ci Adam). Napisz też coś o założeniach jakie ma spełniać baza to będzie prościej
Chodzi mi głównie o stworzenie bazy danych do prowadzenia statystyk piłkarskich - mecze i tabele. Do tego dojść mają statystyki piłkarzy ogólne (czyli np. ilość bramek w karierze, kartek itd.). Stworzyłem sobie tabelę Players do przechowywania konkretnych danych o zawodnikach, teraz chciałbym połączyć ją z tabelami Team, Injuries, Transfer, Statistics, Penalty, Score - żeby mieć te dane w konkretnych miejscach. Mój problem to w obecnym momencie połączenie tych tabel - np. w jakiej relacji powinna być tabela Player z tabelą Team? Na moje oko, N:1, bo drużyna może mieć wielu zawodników (tak to rozumiem). Połączenie reszty tabel z tabelą Players raczej trudniejsze nie będzie.
Podobnie z samą tabelą Team. Chciałbym, zeby drużyny mogły grać na konkretnym stadionie, ale jeden stadion może mieć kilka drużyn. Trenerzy i drużyny raczej będą w relacji 1:1. Pozostałe tabele raczej wydają mi się oczywiste. Jak najlepiej zbudować tabele Matches? Tak, zeby to miało ręce i nogi.
Chodzi mi głównie o stworzenie takiej prostej bazy danych, żeby właśnie opanować poszczególne relacje, nie jakieś super szczegółowe, ale własnie coś takiego, jak mam teraz. Ogólnie:
TeamPoints ma jakiś sens? Np. jakbym chciał ją później wykorzystać do budowania tabeli ligowej?Team a League.
- Zawodnik może występować w jednym klubie, ale klub może mieć wielu zawodników - jaką relację zastosować.
Jeżeli zawodnik może występować tylko w jednym klubie to relacja 1 do N. Jednak wg mnie zawodnik może występować w wielu klubach/drużynach w ciągu sezonu, więc raczej będzie relacja N do N.
- Jeden klub może grać na jednym stadionie, ale stadion moze posiadać kilku gospodarzy - podobnie.
1 do N.
- Tabela TeamPoints ma jakiś sens? Np. jakbym chciał ją później wykorzystać do budowania tabeli ligowej?
Nie ma wielkiego sensu, ponieważ meczy jest na tyle mało, że można punkty policzyć jednym zapytaniem. Dla ligi liczącej 20 zespołów masz 38 kolejek, z 10 meczami w każdej, czyli razem raptem 380 spotkań w sezonie czyli tyle co nic. Wystarczą w tabeli z meczami kolumny na punkty gospodarza i punkty gościa.
- Podobnie relacja między Team a League.
Jeżeli w jednej lidze może występować wiele zespołów to oczywiście 1 do N, chyba, że zrobisz mechanizm spadków, awansów.
Twój ostatni schemat jest lepszy ale nadal ma masę błędów, wiele drużyn rozgrywa wiele meczów, a na schemacie jest relacja 1 do N. Nie ma żadnego powiązania między meczem, a ligą w ramach której jest rozgrywany mecz. Nie ma powiązania miedzy tabelami score, penalty z tabelami matches, a przecież zawodnik strzela bramki w konkretnym meczu, w konkretnej jego minucie. Relacja między leage, a team jest 1 do 1, a przecież w jednej lidze może występować wiele zespołów (pisałem o tym już wcześniej). Piłkarz otrzymuje kartki, gra i strzela w konkretnym meczu w konkretnej jego minucie. W ogóle kartki, strzały, bramki, karne, kontuzje dałbym w jednej tabeli z wydarzeniami meczowymi... przecież te wydarzenia są do siebie podobne, można je umieścić w jednej tabeli. Tabela ze statystykami zbiorczymi piłkarza jest w ogóle zbędna, przecież możesz to wygenerować jednym zapytaniem, przeszukując tabelę wydarzeń meczowych, dzięki temu będziesz mógł również równie łatwo wygenerować statystyki dla konkretnej drużyny, co dla konkretnego zawodnika.
wie ktos skąd pobrac dane o statystykach za lata sprzed 2014 roku o wynikach z np. 1 ligi pilki noznej ?