Temat: Baza danych Dziennik Szkolny
Dziękuję gorąco za wszystkie propozycję. Niedługo wstawię schemat bazy który powstał w wyniku dyskusji.
Na tą chwilę będę realizował następujące założenia:
podział klasy na grupy (wf|języki|zajęcia dodatkowe):
najpierw tabela łącząca uczeń <-> klasa, ale określona kluczem głównym dzięki czemu tworzę dodatkową tabele group_delegation w której odnosząc się do wcześniejszego id relacji uczeń<->klasa - mogę konstruować przynależność ucznia do konkretnej grupy.
używam tego później przy definicji przedmiotu gdzie będę miał pole group_type które wybierze docelowy typ grupy której się tyczy (dziewczyny|zaawansowaniu j. angielski) jako uczniów docelowych przedmiotu w kontekście danej klasy.
kwestię uczeń nauczyciel klasa rozwiązuję natomiast tworząc najpierw tabelę łącznikową przedmiot <-> nauczyciel (z kluczem głównym zamiast klucza zbiorowego), dzięki czemu tworząc dalej relację klasa(class_instance) tabela przedmiot_nauczyciel również z pojedynczym kluczem głównym.
Dzięki powyższemu zabiegowi umieszczając w tabeli ocen id z poprzedniej tabeli identyfikuje jednoznacznie klasę-grupę-przedmiot przy wstawianiu ocen. Na pewno w praktyce jak już wygeneruje odpowiedni kod klas i zacznę z nich korzystać wyniknie jeszcze parę niuansów.
Marcin Mackiewicz:
1. Tabela z profilem [profile] (id) jest ok. Proponuje takze zrobic [profile_extra] jako tabele z dynamicznynie dodawanymi polami (cechy dodatkowe jakie sobie wymysli dana szkola
To będzie przysłowiowa wisienka na torcie, jeśli bazowe funkcjonalności będą działały to na pewno będę dodatkowo rozszerzał schemat bazowy. Tak naprawdę to tą zmianę mogę wykonać w każdym momencie bo nie koliduje z innymi relacjami i tabelami.
2. Tabela [history], (id PK, lp PK, rok_immatr, rok_szkolny, semestr_w_roku, semestr_kolejny, rok_nauki) gdzie prowadzimy historie danego ucznia (kazdy wpis odpowiada kolejnemu semestrowi nauki). Raz na pol roku (tak jak ida semestry) dokonujemy potem promocji ucznia na nastepny semestr. To pomoze np sprawdzac czy uczen w danym semestrze ma wszystko zaliczone. Proponuje tutaj takze dodac rok immatrykulacyjny ktory pozwoli zidentyfikowac proces dydaktyczny w danym cyklu nauki (rozroznianie powtarzajacych rok).
Przy tabeli class_instance mam informację o roku i semestrze, natomiast tabelę history widzę raczej jako widok.
Przy obecnych założeniach bazy, nie tracę informacji o ocenach ucznia w na przełomie klas, bo jak już powiedziałem w tabeli ocen jest klucz który okresla klasę-przedmiot-nauczyciela więc wyciągnięcie informacji który uczeń dostał 3 z polskiego w 2 semestrze 3 klasy w 2009 roku będzie (mam nadzieje :D) możliwe.
Tutaj mozna tez wprowadzic statusy na jakich jest uczen (OK, Trwa rozliczanie, Powtarzanie, itp.)
Jak najbardziej, ale muszę o tym pamiętać bo zauważyłem że takie rzeczy często uciekają.
3. Tabela [przedmiot] gdzie przechowujemy informacje o tym jakie przedmioty na danym semestrze ma dany uczen. W tym miejscu zapisujemy rowniez koncowa ocene z danego przedmiotu.
Tutaj chyba też skłaniał bym się co do widoku.
4. Tabela [przedmiot_czastkowe] w ktorej to przechowujemy eventy przeprowadzane w ciagu roku (testy, sprawdziany, kartowki, odpytka, itp.). Pamietane dla ucznia, przedmiotu
Tak, zrobiłem coś takiego w tabeli ocen, gdzie jest id do eventu (dodatkowo w evencie robię jeszczę wage rozliczania danego wydarzenia)
5. Tabela [history_zachowanie] powiazana scisle z [history] gdzie wpisujemy informacje o okresowej ocenie postepow studenta
A tutaj tak naprawdę nie wiem co zrobić bo zachowanie jest tak jakby z innej beczki ni to przedmiot ni to status ucznia nadawany raz na semestr.
6. Tabela [przedmiot_zachowanie] w ktorej prowadzacy przedmiot moze wystawic opinie, spostrzerzenia, uwagi, itp.
Nauczyciel by chyba życie stracił na prowadzenie tego dziennika :D
Ale zrobiłem funkcjonalność skrzynki albo jakiegoś message boarda, żeby sobie bardziej nie komplikować w ocenianiu. (w końcu uwagi itd. to rzeczy nieformalne)
Definiowanie klas:
Klasy w szole to nic innego jak grupa uczniow stworzona dla potrzeb przeprowadzania zajec.
Proponuje wiec stworzyc tabele [groups] oraz [groups_sklad] w ktorej beda trzymane sklady grup. Teraz klasa specjalna (np mat-fiz) to nic innego jak specjalna grupa tak wiec proponuje dodac to tego tabele [groups_cechy] w ktorej beda przechowywane informacje o tym jaka to jest klasa (cechy do grup). Jezeli chodzi o grupy to zakladane powinny byc z kluczem (rok_immatr) poniewaz grupa funkcjonuje tak dlugo jak uczniowie sie ucza (np gminazjum 3 lata) ale pamietac trzeba ze klasa 1A wystepuje co roku czyli po 2 latach mamy klasy 1A(2008) oraz 1A(2009) gdzie data jest rokiem kiedy uczniowie przyszli do szkoly.
Kazda klasa ma wychowawce (opiekun) co nasowa zrobienie slownika [wykladowcy] i przypisywania go bezposrednio do grupy, posrednio do ucznia.
mam coś podobnego, z tym że mam układ:
definicja klasy - ogólnie o klasie np 3 klasa o profilu mat-fiz (dodatkowa tabela z profilem klasy)
instancja klasy - klasa z definicji plus specyfikacja w czasie + wychowawca.
Tutaj miałem pewien dylemat czy określać przedmiot - klasa, dla definicji czy dla instancji
Intuicja mi mówi że tu i tu bo czasem może się program zmienić i odstawać od przyjętego w danej klasie, ale z drugiej strony to kolejne komplikacje.
Na razie jednak robie dla definicji i widzę to tak że robie zapytanie:
select c.name, t.lastname
from
course c inner join class_course cc on (cc.course_id = c.id)
inner join class_definition d on (cc.class_id = d.id)
left join class_course_teacher cct on
(cct.class_id = cc.class_id and cct.course_id = cc.course_id)
inner join teacher t on (t.id = cct.teacher_id)
where cct.class_id is null
pisałem z głowy ale wydaje mi się że to zapytanie powinno wyświetlić jakie przedmioty mamy do obsadzenia i dodatkowo jakimi nauczycielami
spodziewam się uzyskać np.
polski | wołkow
polski | kukułka
angielski | grucha
No to mamy szkielet.
W takim wypadku jak teraz problemem jest nadawanie przedmiotow uczniom. Jeden uczen ma ok 15 przedmiotow. W klasie jest ok 30 uczniow co powoduje ze uzytkownik musialby nadac 15*30= 450 wpisow do tasbeli. W tym wypadku warto by pomyslec nad ramowym przebiegiem zajec (kazdy rocznik uczy sie wg jakiegos planu dydaktycznego). Proponuje dodac tabele [ramowka] oraz [ramowka_sklad] gdzie bedzie zdefiniowany standardowy rozklad przedmiotow dla danego roku_immatr, klasy, semestru. Pozwoli to dobudowac funkcje w UI ktora dla danej klasy (grupy studentow) nada w odpowiednim wpisie w historii odpowiednie przedmioty.
no i idąc tym kierunkiem opracować pewne metody automatyzacji wprowadzania danych. no temat jak najbardziej przyszłościowy, ale pewnie nie starczy czasu
uffff...
пропозиції роботи
