Witam wszystkich.
Mam problem - chcąc zaprojektować prostą bazę danych dla uczelni (kursy, studenci, pracownicy,oceny itp.) nie wiem jak rozwiązać fakt, że student też może prowadzić zajęcia a nie jest on pracownikiem uczelni., model relacyjny (pominięcie dat)

[pracownicy]
IDPrac (primary key)
Imię
Nazwisko
....

[studenci]
Index (primary key)
Imię
Nazwisko
...

[kursy]
IDKursu (primary key)
Nazwa

Teraz standardowo byłyby tabele

[Ocena]
IDKursu (foreign key)
Ocena

[Prowadzi]
IDPrac (foreign key)
IDKursu (foreign key)

Ale chcę dodać studentów.
Jeśli rozbiję tę tabelę na 2: "ProwadziPracownik" i "ProwadziStudent" to nie mam jak wyciągnąć z tabeli "Ocena" informacji o prowadzącym - powstaje alternatywa wykluczająca bo kurs może prowadzić student lub pracownik.

----------------------------
Innym pomysłem jest wprowadzenie IdProwadzacyKurs

[ocena]
IDProwacyKursy (foreigh key)
Ocena

[prowadzacy]
IDProwadzacyKursy (primary key)
IDPrac (foreign key)
Index (foreign key)

ale wtedy przypisuję dla IDProwadzacyKursy tylko 1 z wartości.

Podejrzewam, że nie jest to trudny problem, tylko nie wiem jak się go powinno rozwiązać - osobno 2 tabele dla ProwadziStudent i ProwadziPracownik które mają 1 wspólny klucz IDProwadzacyKursy? Tylko wtedy też nie wiadomo czy dla IDProwadzacyKursy = 22 mam go szukać w tabeli ProwadziStudent czy ProwadziPracownik. Byłbym wdzięczny za wskazówki, to nie będzie nigdzie zaimplementowane : )

hm... woźny też jest pracownikiem uczelni, a nie prowadzi wykładów, więc może to nazwać wykładowcy? :PPP

ja bym wprowadził studenta podwójnie do każdej tabeli, a np. ustawił pole dodatkowe, że się uczy czy coś, ewentualnie dodał dodatkową tabelę pracownik_studiuje i tam odnotował taką informację

Hmmm

Single Table Inheritance (http://wiki.rubyonrails.org/rails/pages/SingleTableInheritance , http://www.martinfowler.com/eaaCatalog/sin...nheritance.html ) -- w jedne tabeli 'osoby' trzymasz pracownikow i studentow z polem 'typ' okreslajacym rodzaj osoby.


Zalety:
- student i wykladowca moga prowadzic wyklad (wozny tez, ale rozchodzi sie tu o Foregin Key z constraintem, bo bez tych wiezow to da sie prosciej zrobic)

Wady
- w jednej tabeli trzymasz pola od wszystkich typow osob -- duzo 'wartosci' NULL dla niepotrzebnych pol



Albo podobnie jak ~sf mowi: tabela pracownicy, studenci; studenta wpisujesz w obu ALE jego dane osobowe mozesz umiescic w osobnej tabeli, przez co nie bedziesz powielal danych.