Prosta baza relacyjna - dziennik lekcyjny

0

Witam, mam takie zadanie na studiach:

Jestem świeży z bazami danych i SQL, ale wykonałem szkic jak w załączniku.

Czy ktoś byłby w stanie doradzić co zmienić lub co wykonałem źle?

3

Czy możesz wyjaśnić, po co stworzyłeś tabelę class_student (prawy dolny narożnik obrazka)? Do czego ona służy, gdzie będzie wykorzystana?

Dlaczego ograniczasz do 50 znaków długość pól tekstowych (nazwisko, imię itp.)? Jeśli chodzi o reguły biznesowe to spoko (aczkolwiek i tak pierwszym etapem powinno być sprawdzenie wprowadzonych przez usera danych w aplikacji), ale jeśli w ten sposób chcesz oszczędzać miejsce w bazie - to nie ma większego sensu. Rzuć okiem na https://stackoverflow.com/questions/8295131/best-practices-for-sql-varchar-column-length

Jak wygląda kwestia kasowana danych - chociażby tabela student? Co zrobisz, jak uczeń odejdzie - po prostu go skasujesz? Tak się nie powinno robić (mówię oczywiście o prawdziwym świecie, a nie projekcie na zaliczenie na uczelnię) - bo jakbyś usunął ucznia o ID=4532, a jakiś dokument (dziennik, plan lekcji itp) się odwoływał do tego ID to masz mocnego zonka. Zamiast tego raczej stosuje się jakąś flagę w stylu active = TRUE i jak ucznia kasujesz to wtedy przełączasz na FALSE. W bazie nic się nie pogubi, a jak chcesz pobrać aktualnych uczniów to dajesz coś w stylu SELECT uczeń WHERE active=TRUE.

Masz takie coś jak subject_id. Zakładam, że chodzi o przedmiot - w sensie, że inny subject będzie dla polskiego, inny dla matematyki itp. Jeśli mam rację i chodzi w tym subject o dany przedmiot (jeśli nie, to wyjaśnij, co miałeś na myśli) to powinna być jakaś korelacja między przedmiotem a nauczycielem. Zobacz - aktualnie teacher ma jedynie imię, nazwisko oraz datę urodzenia. Po pierwsze - po co data urodzenia nauczyciela? Ma to znaczenie dla szkolnego działu kadr, ale przy planie lekcji jest to zupełnie nieistotne. Za to brakuje informacji dość ważnej - jakiego przedmiotu dany nauczyciel uczy. Czy na pewno nauka muzyki przez faceta od biologii to dobry pomysł? :P

Behaviour_grade czyli ocena z zachowania - czemu ma być opisowa jako varchar? Jeśli masz tam dać recenzję zachowania, to 50 znaków to trochę mało na napisanie oceny opisowej. Jeśli masz dawać konkretną ocenę w skali 1-6, to daj jakiś typ liczbowy (analogicznie do tego, co masz przy grade). A tak w ogóle - moim zdaniem najlepszą opcją by było stworzenie jakiegoś osobnego słownika z dostępnymi ocenami, a następnie powiązanie tego słownika z kolumną z ocenami.

0

dzięki wielkie za podpowiedzi, w załączniku przesyłam aktualny stan.
Co do flag, to nie wiem jakby miały one wyglądać na tym diagramie.

Co do treści zadania, myślisz, że powinienem rozdzielić kolumnę przedmioty na przedmioty zwykłe oraz przedmioty językowe?
Czy w takich diagramach obok powiązań wpisuje się liczby odwołujące się do kardynalności? przykładowo: 1...25 uczniów może być tylko w jednej klasie
Czy ocena końcowa musi mieć powiązanie z ocenami zwykłymi (przykładowo w celu liczenia średniej)? Nie jest chyba to określone w zadaniu i zastanawiam się czy zostawić tak jak jest.

1

Co do flag, to nie wiem jakby miały one wyglądać na tym diagramie.

Tak, jak masz zadeklarowane inne kolumny - np. student_id int to zrób analogicznie is_active BOOLEAN. Przy czym nie wskazałeś jakiej bazy konkretnie chcesz używać, więc konkretna implementacja zależy od wybranego silnika. Popatrz na tabelkę poniżej - różne bazy mają to inaczej rozwiązane.

https://www.databasestar.com/sql-boolean-data-type/
https://www.postgresqltutorial.com/postgresql-tutorial/postgresql-boolean/

screenshot-20220915114430.png

myślisz, że powinienem rozdzielić kolumnę przedmioty na przedmioty zwykłe oraz przedmioty językowe?

Który fragment mojego poprzedniego posta zrozumiałeś jako taką sugestię? Bo nie wiem, czy ja napisałem coś niejasno, Ty coś źle zrozumiałeś, czy może to pytanie jest niezwiązane z moją odpowiedzią :P Tak poza tym - czemu chcesz te dwa typy przedmiotów traktować odmiennie? Wyjaśnisz?

1...25 uczniów może być tylko w jednej klasie

tak w ogóle, co do klas - wydaje mi się, że brakuje powiązania klasy z uczniami. Masz tabelę z uczniami, masz tabelę, w której masz klasy. Ale w jaki sposób masz teraz wskazane, że uczeń o ID=43 chodzi do klasy o ID=17? Na ogół rozwiązuje się to tak, że masz 3 tabele:

  • tabela z uczniami
  • tabela z klasami
  • tabela przyporządkowująca ucznia do klasy.

W tej ostatniej nie potrzeba zbyt wielu informacji, tylko jakiś PK, do tego ID ucznia i ID klasy. I masz tam wpisane właśnie, że uczeń o danym ID należy do wskazanej klasy. Jak chcesz pobrać wszystkich uczniów z danej klasy to po prostu pobierasz z tabeli z powiązaniami wpisy posiadające ID klasy równe temu, którego szukasz. Do tego jeszcze potem możesz sprawdzić, czy uczeń jest aktywny (kwestia omawianej wcześniej flagi is_active) - żeby nie wypluć na listę ludzików, którzy już do tej klasy nie chodzą.

Czy ocena końcowa musi mieć powiązanie z ocenami zwykłymi (przykładowo w celu liczenia średniej)? Nie jest chyba to określone w zadaniu i zastanawiam się czy zostawić tak jak jest.

Opcje są dwie:

  • średnia się sama liczy w bazie w oparciu o oceny cząstkowe. Wymaga to przeniesienia części logiki do bazy. Plus - może tak się stać, że coś zostanie zmienione i średnia się samodzielnie zaktualizuje, mimo że nauczyciel nie miał takiej woli
  • średnia jest wprowadzana z poziomu aplikacji (nieważne, czy apka ją liczy sama, czy nauczyciel wprowadzi ręcznie) i jest niepowiązana wprost z ocenami czatkowymi.

Oba rozwiązania są poprawne od technicznej strony, ale biorąc pod uwagę wymogi biznesowe (tak się fachowo określa cel, który chcesz osiągnąć/wymagania klienta) to lepsza wydaje się opcja druga.

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