Czy schemat relacji bazy danych MySQL dla planu zajęć jest poprawny?

Witam czy jest ktoś w stanie mi pomóc dokładniej chodzi o ten schemat relacji pomiędzy tabelkami bazy danych, która przedstawia plan zajęć w szkole wyższej. Czy jest to dobrze zrobione ?



Jeżeli chodzi o kod w mysql to chyba powinno to wyglądać następująco na początek tworzę tabelki z kluczami głównymi czyli: TERMIN, STUDENCI, WYKŁADOWCY, NAZWA ZAJĘĆ:


Na samym końcu tabelkę ZAJĘCIA z kluczami obcymi:


Nie wpisywałem tych linii kodu w mysql nie wiem czy są poprawne bardzo was proszę o sprawdzenie.
Pozdrawiam

To może zaznacz poprawnie te relacje (typy relacji) pomiędzy tabelami?

Poza tym tabela "Nazwa_zajec" jest źle zbudowana, zamiast wypisywać wszystkie nazwy zajęć (czyli tworzyć tyle kolumn ile jest nazw zajęć - jaki to ma sens?) stwórz jedną kolumnę np. Nazwa i już (tak jak zrobiłeś z tabelą "Wykladowcy"). Po wypełnieniu tabeli będziesz miał coś takiego

Piciu199018 napisał:

Nie wpisywałem tych linii kodu w mysql nie wiem czy są poprawne bardzo was proszę o sprawdzenie.

Ale w czym problem (żeby to wrzucić do bazy i zobaczyć czy coś zgłosi)? Po poprawkach wrzuć do bazy. Jak nie zgłosi błędów to wprowadź kilka przykładowych danych i sprawdź czy tabele wyglądają tak jak sobie założyłeś.

Masz rację Alfred tabelka Nazwa_zajec jest bez sensu poprawiłem na Twoją propozycję. Relację między tabelkami wyglądają następująco, tutaj też proszę o wgląd czy jest ok mogłem gdzieś się machnąć, ale raczej jest ok.



Wrzuciłem wszystkie tabelki do mysql nie obyło się bez poprawek poniżej przedstawiam linie kodu tabelek jakie wrzuciłem oprócz literówek i polskich znaków musiałem zmienić TYPE=InnoDB; na ENGINE=INNODB;



Niestety ostatnia najważniejsza tabelka w końcowej linii kodu wywala mi błąd i nie wiem o co chodzi pomożesz ??



Poniżej wklejam też kod tej głównej tabelki:

Z góry dzięki za pomoc pozdrawiam

Zaznaczam, że dawno nie miałem do czynienia z bazami danych.

Jeśli przyjąć, że dane zajęcia mogą mieć kilku wykładowców to chyba ta relacja pomiędzy tymi tabelami jest ok. Dopiero teraz zauważyłem, że nie ma nigdzie określonego typu zajęć (wykład, laboratorium itd.). Nie potrzeba?

Co do błędu to spróbuj usunąć tę spację przed ID_WYKLADOWCY

Kolego, nie chcę Cię martwić, ale praktycznie cały ten projekt bazy jest zły... Jest już późno i nie chce mi się w szczegóły zagłębiać, zwłaszcza że praktycznie wszytko jest do przeróbki, może jutro jak znajdę chwilkę... Tak na ciepło to: nie mają sensu tabele WYKŁADOWCY (w obecnej formie) i NAZWA ZAJĘĆ (po co wydzielać do osobnej tabeli coś, co ma jedną kolumnę? W dodatku, jak dla wykładowcy, takiego samego typu jak klucz główny? Tak można każdą tabelę rozbić, robiąc osobną tabelę dla każdej jej kolumny i jedną zbiorczą na ID do ich rekordów, w tym wypadku to nie ma sensu... Przy dążeniu do normalizacji bazy danych zawsze mówi się o pewnym kompromisie. Nie ma sensu tworzyć osobnej tabeli tylko na numer legitymacji wykładowcy), tabela ZAJĘCIA w obecnym kształcie, zła relacja ze studentem (może chociaż nazwisko czy numer indeksu im dodaj?) i terminami, nie używa się polskich liter i spacji w nazwach pól i tabel...

marcinj12 napisał:

nie mają sensu tabele WYKŁADOWCY (w obecnej formie) i NAZWA ZAJĘĆ

Do tabeli WYKLADOWCY można dodać imię, nazwisko oraz tytuł, a do NAZWA_ZAJEC można dodać (wspomniany już przeze mnie) rodzaj zajęć (wykład, laboratorium itd.) i już będzie sens. Ale nie wiemy jakie ma założenia autor tematu.

marcinj12 napisał:

zła relacja ze studentem (może chociaż nazwisko czy numer indeksu im dodaj?) i terminami

Studentami, nie studentem A dokładniej to powinno być GRUPY. Przecież w danych zajęciach może brać udział wiele grup (wykład), podobnie jedna grupa bierze udział w wielu zajęciach. I nie ma sensu do grupy studentów dodawać ich nazwisk czy indeksów, można to zrobić w danych studenta (można mu przypisać grupę i indeks), ale to nie baza o studentach. Tak samo z TERMIN, przecież dane zajęcia mają różne terminy (odbywają się kilka razy w tygodniu), a dany termin może mieć tylko jedne zajęcia, bo w danej sali przecież nie będzie kilka wykładów.

marcinj12 napisał:

nie używa się polskich liter i spacji w nazwach pól i tabel...

To już autor zuważył

Piciu199018 napisał:

oprócz literówek i polskich znaków musiałem zmienić TYPE=InnoDB; na ENGINE=INNODB;

Zdaję sobie z tego sprawę, że ten projekt bazy danych nie jest dobry. Mam na niego mało czasu jest to projekt na uczelnie zadany przez wykładowcę. Mam mało czasu na wgłębienie się w ten temat do tego bazy danych nie wchodzą mi kompletnie dlatego dziękuje za zainteresowanie. Przerobiłem trochę ten projekt głownie chodzi mi o to tabelka STUDENCI zapomniałem wywalić kolumnę grupa, moim założeniem jest, że dany rok studentów są tak jakby jedną grupą (tak jak w podstawówce KLASA A itd.) Co do tabelki WYKŁADOWCY skasowałem ją i dane przeniosłem do tabelki NAZWA_ZAJEC (gdzie do każdego przedmiotu jest przypisany dany wykładowca tak chyba będzie wygodniej, dorzuciłem również wspomniany rodzaj czyli wykład lub laborki). Tylko nie wiem jak z dokładnym typem relacji na razie podsyłam taki projekt:



co o tym myślicie ? Ogólnie z liniami kodu, które wcześniej umieściłem, dzięki Alfred miałeś rację co do spacji itp. Co do kodu to przerobię go pod projekt, który będzie w miarę dobry.

1. Tak jak napisał marcinj12 nie używaj w bazie polskich znaków i spacji (przecież zauważyłeś już, że baza tego nie przyjmie).

Piciu199018 napisał:

...(gdzie do każdego przedmiotu jest przypisany dany wykładowca tak chyba będzie wygodniej...

2. Moim zdaniem powinna być tabela WYKLADOWCY, bo dany przedmiot często wykłada/prowadzi wielu wykładowców. Ale jak już też wspomniałem wszystko zależy od założeń i wymagań prowadzącego zajęcia, nie zawsze wymagana jest 100% poprawność, czasem nagina się zasady, żeby przećwiczyć/sprawdzić coś innego.

3. Zaznacz typy relacji, pewnie marcinj12 jeszcze tu zajrzy to będzie miał co sprawdzać.

Tabelka WYKŁADOWCY nie miała sensu kiedy prezentowała tylko jedną kolumnę z legitymacją, jeżeli rozbudowujesz ją o dodatkowe pola, to jej istnienie nabiera sensu, a wręcz jest wskazane
Naprowadzę Cię trochę:

1. Spróbuj zrobić taką tabelkę


2. Zakładając, że w tabeli STUDENCI chcesz trzymać nazwiska studentów, przerób ją na podobną do:


[możesz, nie musisz, przyjąć nr indeksu jako klucz i zamiast id_studenta zostawić nr_indeksu - oczywiście wtedy nie jako pole autoincrement, ale np. INT]

3. Nie są dobre relacje w obecnym układzie, popatrz co się dzieje, kiedy chcesz "zapisać" grupę 100 studentów na jedne tylko zajęcia, które mają 20 terminów w ciągu semestru.
a. dodajesz 100 studentów do tabeli Studenci => OK,
b. dodajesz 20 terminów do tabeli terminy => OK,
c. dodajesz 100x20 = 2000 rekordów do tabeli ZAJĘCIA => NIE OK...

Raz, że niepotrzebnie 2000x powielasz wtedy takie dane jak czas_trwania_zajec, to w dodatek każdy taki rekord będzie miał inny numer ID_ZAJĘCIA, mimo, że dotyczą one tego samego zajęcia... Aby tą samą grupę zapisać na kolejny kurs, dochodzi dodatkowe 2000 rekordów etc.

Najlepiej by było gdybyś doprowadził tabelę z zajęciami do takiej postaci, żeby nie powtarzały się rekordy jak dodajesz studentów i terminy, dzięki temu można zrezygnować z tabeli z nazwą zajęć. Ja bym ją widział mniej więcej tak:


4. Tabla z terminami może zostać jak jest (choć osobiście bym tam dodał godzinę OD i DO, a zrezygnował z czasu trwania zajęć w tabli zajęć), niech zostanie:


5. Teraz, żeby powiązać je razem, wypada stworzyć tabele dodatkowe, przykładowe nazwy:
5a. aby powiązać wykładowców z zajęciami i konkretnymi terminami:


5b. aby "zapisać" studentów na zajęcia:


====================

Jak teraz wygląda wprowadzanie danych do bazy jak przy poprzednim przykładzie?

- masz po jednym rekordzie dla każdego wykładowcy,
- masz po jednym rekordzie dla każdego zajęcia,
- masz po jednym rekordzie dla każdego studenta, łącznie 100 rekordów,
- masz po jednym rekordzie dla każdego terminu, łącznie 20 rekordów,
- masz 20 rekordów wiążących zajęcia z terminem w tabeli Terminy_zajec,
- masz 100 rekordów wiążących studentów z terminami zajęć w tabeli Zapisy_studentow

Łącznie: 120 rekordów zamiast 2000, i to tylko dla jednych zajęć.

Dzięki relacjom zapytaniem SQL jesteś w stanie złożyć je w całość, a dane nie powielają się, gdy nie muszą (chyba ).

Piszę z głowy i mogłem coś pominąć, ale generalnie zasadza jest zrozumiała, jeżeli nie, spróbuj stworzyć obrazek wg tego schematu, to może się rozjaśni...

@marcinj12 ale po co taka "konstrukcja" tabeli Studenci jak autorowi chodzi o grupę (rok) studentów? A tam nie potrzeba przechowywać listy studentów, ich imion, nazwisk itp. bo to do jakiej grupy należy dany student (czyli na jakie zajęcia uczęszcza) można przechowywać w tabeli ze studentami, która jednak nie jest tutaj potrzebna ani omawiana, nie ten fragment bazy.

Piciu199018 napisał:

Przerobiłem trochę ten projekt głownie chodzi mi o to tabelka STUDENCI zapomniałem wywalić kolumnę grupa, moim założeniem jest, że dany rok studentów są tak jakby jedną grupą (tak jak w podstawówce KLASA A itd.)

Jednak jeśli autor tematu uzna, że taka koncepcja mu odpowiada to ok

_alfred_ napisał:

@marcinj12 ale po co taka "konstrukcja" tabeli Studenci jak autorowi chodzi o grupę (rok) studentów? A tam nie potrzeba przechowywać listy studentów, ich imion, nazwisk itp. bo to do jakiej grupy należy dany student (czyli na jakie zajęcia uczęszcza) można przechowywać w tabeli ze studentami, która jednak nie jest tutaj potrzebna ani omawiana, nie ten fragment bazy.

Jeżeli rzeczywiście o to autorowi chodziło to masz rację (w takim wypadku nazwa tabeli jest raczej myląca, czemu nie "Rocznik" albo "Grupa"?), ja założyłem że chodzi o listę studentów

Studia to nie podstawówka gdzie wszyscy ławą szli przez szkołę , normą jest że studenci z jednej "grupy" (tego samego kierunku i roku rekrutacji) uczęszczają na różne zajęcia (poprawki, przedmioty wybieralne, języki obce - różne i na różnych poziomach, zajęcia sportowe), że o powtarzaniu roku, specjalizacji w ramach jednego kierunku czy przenoszeniu na inne kierunki nie wspomnę - zastanów się, czy na pewne chcesz wszystkich traktować jako jedną grupę...

Choć się nie znam na tych całych bazach to jak tak czytam to co napisałeś Marcin wygląda to ok ale czy będzie działać tak jak piszesz . Zrobiłem według twoich wskazówek i podpinam obrazek mam dwa pytania.

Pierwsze pytanie: W tabelkach ZAPISY_STUDENTOW i w tabelce TERMINY_ZAJEC znajdują się te same klucze (ID_ZAJECIA) nie wiem jak to rozumieć na obrazku narysowałem połączenie między nimi, ale czy w tabelce TERMINY_ZAJEC ten klucz jest potrzebny nie wiem czy dobrze myślę. Może jak wcześnie wspominałeś machnąłeś się zerknij na obrazek

I drugie pytanie to jakimi typami połączyć te relację? Do każdych strzałek dopisałem cyferki:
1. wiele-do-wielu
2. jeden-do-jednego
3. wiele-do-jednego
4. wiele-do-wielu
5.(jeżeli to powiązanie ma być) jeden-do-jednego

Myślę, że to połączenie powinno wyglądać tak jak na obrazku (pole id_zajecia powinno się odwoływać się do tabeli zajęć).

Natomiast po rozrysowaniu schematu dochodzę do wniosku, że tak naprawdę tabela TERMINY jest niepotrzebna: ponieważ w danym dniu, w danej godzinie, w danej sali mogą odbywać się tylko jedne zajęcia, prowadzone przez jednego wykładowcę, to można schemat uprościć przenosząc pola data, godzina i sala bezpośrednio to tabeli TERMINY_ZAJEC. Chyba że przyjąć, że zajęcia odbywają się zawsze w tej samej sali, ale w różnych terminach - wtedy można zostawić:

i połączyć ją relacją po id_terminu z tabelą:

jak chcesz możesz spróbować tak to rozbudować...

Na tak zorganizowanej tabeli można pozakładać klucze główne (przy 1) i obce (przy ∞) i powinno to działać.

Jeśli chodzi o te typy relacji 1:1, 1:wielu czy wiele:wielu to przyznam, że niespecjalnie się w nich orientuję (przebrnąłem przez nie na studiach metodą 3Z a teraz nie wykorzystuję ), więc jak coś to proszę mnie poprawić...
Zapisałem je tak ja na obrazku, gdyż tłumaczę je sobie tak:
- rel1: jeden wykładowca może uczestniczyć w wielu terminach zajęć,
- rel2: jedne zajęcia (jeden przedmiot) mogą się odbywać w wielu terminach,
- rel3: na jedne zajęcia może się zapisać wielu studentów,
- rel4: jeden student może się zapisać na wiele zajęć

Nie wiem czy nie trzeba tu jeszcze włączyć relacji typu: "zero lub więcej..." itp., (np. w rel3: mogą być zajęcia, na które nie zapisali się żadni studenci), ale żeby nie komplikować zostawiam jak jest...

Fajnie Marcin jutro się za to zabiorę dzisiaj brak mi już mocy. Wrzucę w bazę tą poprawkę i zobaczę jak to będzie wyglądać w praniu w mysql mam nadzieje że nie napotkam żadnych przeszkód co do kodu. Jeżeli tak to podrzucę listing kodów.

Jeżeli chodzi o typy relacji jak dotąd nie słyszałem o (typ: zero-do-wielu). Tylko te trzy wcześniej przeze mnie wymienione. Według mnie te typy relacji które napisałeś są raczej w porządku jeżeli rzecz jasna opiszemy je wcześniej w odpowiednich założeniach. Aby odbiorca wiedział dlaczego jest tak a nie inaczej.

Myślę tylko nad relacją 3 i 4 (do 4 relacji: jeden bądź wielu studentów może zapisać/uczestniczyć w jednych bądź wielu zajęciach zaś do 3 relacji odwrotność tego co napisałem do rel 4)

Wielkie dzięki jutro jeszcze pomyślę i podeślę listing kodów bazy w mysql jak nie będzie przeszkód to już z uzupełnieniem pozdrawiam

Piciu199018 napisał:

jak dotąd nie słyszałem o (typ: zero-do-wielu)

Źle się wyraziłem, może nie jest to typ relacji, ale pamiętam ze swoich projektów że coś takiego opisywaliśmy, zamiast 1 lub ∞ mogło być też 0... A może to dotyczyło UMLa... Z tymi relacjami 3 i 4 to rzeczywiście lepiej jeszcze z kimś skonsultuj, tutaj pomocny nie będę...

Piciu199018 napisał:

Jeżeli chodzi o typy relacji jak dotąd nie słyszałem o (typ: zero-do-wielu

Powinno być "zero lub jeden do wielu" i takie coś rzeczywiście istnieje, jednak nie mówi się o tym jako relajcji w bazie danych tylko bardziej wykorzystuje na modelach UML aby pokazać że dla danego rekoru może nie istnieć klucz obcy czyli pole_id = NULL.

Przykład odworowania hierarchii przełożony - pracownik:


Każdy pracownik ma swojego przełożonego (klucz obcy ParentID), ale na szczycie drzewa jest główny boss, który nie ma żadnego przełożonego nad sobą więc dla niego nie istnieje żaden klucz obcy, czyli pole ParentID będzie NULL, więc mamy tu klasyczne odwzorowanie relacji "zero lub jeden do wielu"

Oki więc tak zrobiłem bazę według tego wzoru co mi wcześniej Marcin rozrysował wprowadziłem tabelki i powiązałem je według tych linii kodu.

Na początek wrzuciłem te tabelki:


Następnie wpisałem kody związane z tabelkami które mają w sobie komendy wiązania z tymi tabelkami które wyżej wymieniłem w kodzie:




Oki wszystko przebiegło bez przeszkód kod jest prawidłowy
Idziemy dalej

Następnie zająłem się uzupełnianiem tabelek jakimiś informacjami żeby sprawdzić czy baza zadziała. Niestety zatrzymałem się przy tabelce TERMINY_ZAJEC :(tabelka składa się z kolumn:

ID_ZAJECIA
ID_WYKLADOWCY
Data_zajec
Godzina
Sala

w jaki sposób mam wprowadzić dane do tej tabelki ? pomóżcie
czy to ma wyglądać tak:



Po wprowadzeniu przykładowych danych do pozostałych tabelek wygląda to tak:



W tą niedziele mam już oddać ten projekt chciałbym dostać w miarę wysoką ocenę a sam już nie wiem czy idę w dobrym kierunku jesteście w stanie mnie jeszcze pokierować ?? z góry dzięki za wszystkie wskazówki.

Niestety, dopiero teraz spostrzegłem nieścisłość w swoim poprzednim schemacie - jeżeli student zapisuje się na zajęcie (relacja rel3) to tak, jakby jeden przedmiot miał zawsze tylko jednego, tego samego, prowadzącego...

W związku z tym mała zmiana koncepcji:

Doszło pole id_terminu oraz zmieniłem rel3 tak, żeby teraz student zapisywał się na konkretny termin zajęć (który wiąże konkretny przedmiot i wykładowcę z datą i salą).

Co prawda teraz przestajemy mieć oszczędność - jak w poprzednim przykładzie - 120 rekordów zamiast 2000, teraz też ich będzie 2000, ale tylko w tabeli zapisów. Można by tego uniknąć wprowadzając dodatkową tabelę i pole do terminów, ale już nie komplikujmy...

Przykładowe dodanie terminów zajęć wygląda zatem tak:
(zdaje się że dodanie daty i godziny w mySql wymaga umieszczenia ich w apostrofach). Podajesz istniejące id wykładowcy (14 = Pawel Wisniewski) oraz zajęć (15 = Wprowadzenie do pedagogiki) definiując w ten sposób zajęcia w konkretnym terminie. Powtarzasz to wielokrotnie, zwiększając za każdym razem np. datę o tydzień, aż zaplanujesz cały semestr zajęć.

Następnie w podobny sposób "zapisujesz" studentów na konkretne terminy zajęć, łącząc id studenta z id terminu.

Oo kurcze super Marcin nie wiem jak dziękować siadam teraz do tego muszę się sprężyć dużo mi wyjaśniłeś jak zbuduje bazę to wrzucę pokazać Kurcze żeby tylko to jakoś zaliczyć może będzie dobrze. W każdym bądź razie na zajęcia nie przyjdę z pustymi rękami Mam nadzieję, że już sobie poradzę z tym uzupełnieniem jakby co to napiszę wielkie dzięki!

Cześć dzięki wszystkim za pomoc w niedziele pokazałem projekt dostałem 4 jestem bardzo zadowolony. Ale wykładowca kazał poprawić usterkę bo będziemy na tych swoich bazach pracować i muszą być bez usterek. Mianowicie chodzi o to, że w diagramie związków encji zrobiłem typ relacji pomiędzy tabelką TERMINY_ZAJEC i WYKLADOWCAMI wiele do wielu. I trzeba byłoby wstawić pomiędzy nimi jeszcze jedną tabelkę aby wykonać ten typ relacji. Mam pytanie czy muszę to robić ? może lepiej ustawić to powiązanie pomiędzy tymi tabelkami jako jeden do wielu i wtedy będzie ok i op[sać to w założeniach. Co o tym myślicie?

Poniżej diagram związków encji (wszędzie zrobiłem typ wiele do jednego czy może to tak być ogólnie całą bazę w mysql mam pod te typy relacji zrobioną ocenicie moje wypociny ?):