Datenbank erstellen - Probleme bei der Umsetzung der Verknüpfung von Tabellen

[M@xi]

Halli Hallo!

Kurz zur Info: Ich benutze Access 2010 erst seit ein paar Wochen, ich habe einen Kurs über Datenbanken an der Uni und habe Access es dadurch kennengelernt. Bisher bin ich auch super damit zurecht gekommen, nur langsam wird es kniffelig und ich hoffe hier kann mir geholfen werden.

Ich versuche mich nun schon seit einer Woche an einer größeren Aufgabe - dem Erstellen einer Datenbank für fiktive Universitäten.

Folgendes Szenario wurde gestellt:

Universitäten haben diverse Jobs ausgeschrieben (mit verschiedenen Jobbeschreibungen) und laden Bewerber zu Interviews ein.
Die Datenbank muss Informationen über die Bewerber (min. 10), über unterschiedlichen (min. 10) Jobs, die unterschiedlichen (ebenfalls min. 10) Universitäten und die jeweiligen Interviews enthalten. Alles weitere soll selbst hinzugefügt werden.
Jeder Job verlangt dabei verschiedene Fähigkeiten und jeder Bewerber verfügt über diverse Fähigkeiten (z.B. Programmieren, Unterrichten, Organisatorisches etc.)

Das ist soweit alles kein großes Problem. Ich habe verschiedene Tabellen erstellt etc. Nun soll die Datenbank allerdings bestimmte Eigenschaften erfüllen und da stecke ich fest. Ich weiß dass diese Eigenschaften über die Verknüpfungen realisiert werden, aber ich bekomme es einfach nicht vollständig hin.

Folgende Eigenschaften müssen realisiert werden:

1) Eine Uni kann, in Bezug auf eine Jobbeschreibung, viele Interviews mit Bewerbern führen.
2) Ein Bewerber kann, in Bezug auf eine Jobbeschreibung, zu vielen Interviews eingeladen werden.
3) Eine Uni kann, in Bezug auf eine Jobbeschreibung, viele Bewerber einstellen.
4) Jeder Bewerber kann von nur einer Uni - und nur in Bezug auf eine Jobbeschreibung - eingestellt werden.
5) Jeder Bewerber hat mehrere Fähigkeiten.
6) Jeder Job benötigt mehrere Fähigkeiten.

Außerdem soll deutlich werden, an welchem Datum das Interview geführt wurde und ob der Bewerber eingestellt wurde (das Interview also erfolgreich war).

Wie gesagt ich habe mich bereits versucht und es ist hoffentlich auch nicht komplett falsch, aber ich weiß nicht mehr weiter und ich habe das Gefühl die Hälfte vergessen, übersehen oder vernachlässigt zu haben.

Hier einmal ein Screenshot von meiner bisherigen Arbeit:
http://www.directupload.net/file/d/3797/ms4lwmpw_jpg.htm

Das Doofe ist auch einfach dass ich alle folgenden Aufgaben erledigen könnte, nur nicht ohne die 100%igen Zusammenhänge der Tabellen.

Ich hoffe ihr könnt mir helfen.

Mfg M@xi

[MaggieMay]

Hallo,

ich habe zunächst einmal noch ein Verständnisproblem:

2) Ein Bewerber kann, in Bezug auf eine Jobbeschreibung, zu vielen Interviews eingeladen werden

Wenn "Jobbeschreibung" mit einer Stellenausschreibung gleichzusetzen ist, dann kann ein Bewerber nur zu einem Interview (=Bewerbungsgespräch) eingeladen werden. Oder was sonst ist damit gemeint?

Die Beziehungen zwischen Universität, Interview und Job halte ich für faslch und würde sie folgendermaßen definieren:
Universität -> 1:n -> Jobs -> 1:n -> Interviews
Die Universität ergibt sich also aus dem Job und muss beim Interview nicht als Datenfeld vorhanden sein.

Die Bewerber bewerben sich auf einen Job und werden evtl. diesbezüglich zu einem Interview eingeladen. Auch hier müssten also die Beziehungen anders aussehen.

[M@xi]

Hallo MaggieMay,

also zu deinem Verständnisproblem: Ein Bewerber kann zu mehreren Interviews eingeladen werden, da verschiedene Universitäten Jobs ausschreiben bzw evtl. sogar der gleiche Job an zwei verschiedenen Universitäten ausgeschrieben wurde.

Deine vorgeschlagenen Beziehungen zwischen Uni, Jop und Interview finde ich sehr einleuchtend.. allerdings fehlt da noch der Bewerber.

Uni -> 1:n -> Jop -> 1:n -> Interview -> 1:n -> Bewerber ?? Oder würde das auch gleichzeitig bedeuten das 1 Interview mit diversen Bewerbern gleichzeitig geführt wird?

Dann kommt auch noch das Problem, dass ich irgendwie umsetzen muss ob ein Interview erfolgreich verlief, der Bewerber also für diesen Job genommen wurde. :\

Danke erst einmal für die Hilfe, ich hoffe wir können mein Problem hier lösen.

Mfg M@xi

Edit: Es müsste wohl eher
Uni -> 1:n -> Jop -> 1:n -> Interview -> n:1 -> Bewerber sein oder?

Hier nocheinmal ein Screenshot der überarbeiteten Beziehungen:
http://www.directupload.net/file/d/3798/b74f2dej_jpg.htm

[MaggieMay]

bzw evtl. sogar der gleiche Job an zwei verschiedenen Universitäten ausgeschrieben wurde

Der Job mag ähnlich oder gar "gleich" sein, es ist aber nicht derselbe, jeder Job bzw. jede Stellenausschreibung *) ist sozusagen ein Unikat.

*) eine Stelle könnte auch mehrfach ausgeschrieben werden, wenn es keine geeigneten Bewerber gegeben hat

Ein Bewerber kann zu mehreren Interviews eingeladen werden

Ja, natürlich. Das bezieht sich dann aber auf verschiedene Stellenausschreibungen, das darf nicht unter den Tisch fallen.

Zeig doch mal dein aktuelles Tabellenkonzept...

[M@xi]

Hier die aktuellen Beziehungen:
http://www.directupload.net/file/d/3798/b74f2dej_jpg.htm

Ich hoffe du meinst die einzelnen Tabellen mit Tabellenkonzept:
http://www.directupload.net/file/d/3798/mkd774az_jpg.htm

[MaggieMay]

Die Tabellenentwürfe kann ich nicht lesen, weil zu klein, aber das Beziehungsfenster genügt schon.

Ich würde die Bewerber mit den Jobs verknüpfen, da nicht jeder Bewerber zum Interview eingeladen wird, aber dennoch erfasst werden sollte. Die Interviews hängen dann am Bewerber und nicht am Job.

Das wäre zumindest meine Sicht der Dinge, aber vielleicht gibt es ja auch noch andere Meinungen dazu.

[M@xi]

So ich habe es noch einmal überarbeitet und denke / hoffe ich bin auf einem guten Weg um alle Bedingungen zu erfüllen.

Mein Problem ist allerdings noch wie ich nun gewährleiste das eine Uni mehrere Bewerber, für eine Stellenausschreibung, einstellen kann und das ein Bewerber nur einen Jop annehmen kann..

Hier nocheinmal die überarbeiteten Beziehungen und Tabellen (Schlüssel sind ebenfalls etwas abgeändert):
http://www.directupload.net/file/d/3798/hgq49nl4_jpg.htm

Mfg

[database]

Hallo,

mir fehlt da noch eine Tabelle. Nämlich jene, aus der hervorgeht welcher Bewerber für welchen Job eingestellt wurde.
In der Tabelle muss der Bewerber einen eindeutigen Index besitzen um die folgende Voraussetzung zu erfüllen:

Jeder Bewerber kann von nur einer Uni - und nur in Bezug auf eine Jobbeschreibung - eingestellt werden

m.E. lässt sich das in der Interview-Tabelle nicht abbilden.

Zu dem solltest den Feldnamen 'Successful?' gleich ändern und das Fragezeichen rausnehmen.
Weiter fällt mir auf, dass der PK in der Tabelle 'Skills' ein Textfeld sein müsste ... nicht gut!
Stell das um auf einen Autowert für den PK und verknüpfe diesen in die untergeordneten Tabellen statt der Texte.
Naja und wenn mehrere Unis den gleichen Job anbieten können sollte die Beziehung auch aufgelöst werden.
Und um noch mehr langatmiges herumtexten zu sparen    sieh' mal die DB im Anhang - die soll für dich sein und/oder zur Diskussion.

HTH

[M@xi]

Hallo database,

erstmal ein dickes Dankeschön - das ist eine große Hilfe ich bin noch dabei alles nachzuvollziehen Wie gesagt, mir fällt es noch recht schwer die Beziehungen und deren Arbeitsweise zu verstehen.. 

Folgende Dinge habe ich noch nicht so durchschaut:

Die Tabellen "UniJobs" und "Jops" ..ist das nicht doppelt gemoppelt oder braucht man wirklich 2 um von generellen Jops und Jops von genau einer Uni zu unterscheiden?

Ich glaube ich verstehe wie du gewährleistest dass ein Bewerber nur einen Jop annehmen kann, aber wie gewährleistest du dass eine Uni mehrere Bewerber, für einen Job einstellen kann?

Ist das "successful" Feld in Interview nicht überflüssig oder nicht sogar komplett falsch? Ist es nicht durch die "ApplicantHavingJop"-Tabelle möglich direkt darzustellen ob ein Interview erfolgreich war (sprich, ein Bewerber einen bestimmten Jop bekommen hat)?

Ein "_F" hinter einem Attribut, hast du wahrscheinlich einfach nur als Kennzeichnung eines FK benutzt, richtig?

Ich hoffe ich stelle nicht zu dumme Fragen, mir ist einfach noch nicht ganz klar wie Access arbeitet oder wie generell die Beziehungen und Tabellen funktionieren :\

Vielen Dank für die Hilfe, mir ist dennoch schon einiges Klarer geworden

Mfg M@xi

[M@xi]

Ich habe jetzt noch ein wenig weiter gearbeitet und die Datenbank um Städte erweitert.
Ich habe folgende Beziehungen erstellt:
Bewerber -> 1:n -> lebtIn -> n:1 -> Städte
Universitäten -> 1:n -> befindetSichIn -> n:1 ->Städte

Nun stelle ich mir die Frage ob dass überhaupt notwendig ist, hätte ich nicht auch einfach die Tabellen Städte und Uni's um das Attribut Stadt erweitern können? Habe ich so irgendwelche Vorteile?

Mfg

[MaggieMay]

Hallo,

was meinst du denn in wievielen Städten ein Bewerber wohnt bzw. eine Universität sich befinden kann?

Tatsächlich würde wohl ein zusätzliches Datenfeld mit dem Referenz-Key auf die Städtetabelle in  den jeweiligen Tabellen völlig genügen.

[database]

Hallo,

zu #8 ...

"...dass ein Bewerber nur einen Jop annehmen kann, ..."
Das Feld ApplicantID_F  hat in der Tabelle 'UniJobs' einen eindeutigen Index verpasst bekommen, somit kann dieser Fremdschlüssel nur einmal in der Tabelle vorkommen. UniJobID_F hat keine Einschränkung, daher kann dieser Fremdschlüssel mehrfach in der Tabelle verwendet werden. Es ist daher auch möglich mehrere Bewerber zum gleichen Job einzustellen.

"...Die Tabellen "UniJobs" und "Jops" ..ist das nicht doppelt gemoppelt ..."
Nein eigentlich nicht, in der Tabelle Jobs werden die Jobs an sich beschrieben, die (Zwischen)Tabelle UniJobs bildet dann ab welche Uni welche Jobs anbietet/vergibt.
Wenn du - wie angegeben - gleiche Jobs in unterschiedlichen Unis hast braucht's eine eigene Tabelle um diese Beziehung darzustellen.

"...Ist das "successful" Feld in Interview nicht überflüssig ..."
Naja, das ist Ansichtssache, streng gesehen hast du recht.
Kommt halt auch darauf an, wie du den Transfer vom Interview zur Tabelle 'ApplicantHavingJob' veranstaltest.
'Successful' (Ja/Nein) könnte dabei ein Auslöser für den Transfer sein (KÖNNTE) - soll heißen es kann auch weggelassen werden, wenn du den Datentransfer auf Formularebene dann anders anlegst. In einzelnen Fällen ist es durchaus gebräuchlich oder erlaubt eine Tabelle gewollt zu denormalisieren.

"Ein "_F" hinter einem Attribut, hast du wahrscheinlich einfach nur als Kennzeichnung eines FK benutzt, richtig?
"
Volltreffer

"...mir ist einfach noch nicht ganz klar wie Access arbeitet ..."
Das hat nix mit Access zu tun, Normalisierung gilt für alle relationalen Datenbanksysteme gleichermaßen

zu #9 ...

"...hätte ich nicht auch einfach die Tabellen Städte und Uni's um das Attribut Stadt ..."

Ja das solltest du auch so machen, stell' in die Tabellen Universities und Applicants je ein Fremdschlüsselfeld 'TownID_F' und leg die Beziehung zur Tabelle 'Towns' mit referentieller Integrität an.
Die Auflösung zu einer Zwischentabelle (BefindetSichIn) bringt nichts, da sich weder ein Bewerber noch eine Uni gleichzeitig in unterschiedlichen Städten befinden werden.

[M@xi]

Hey Hey,

langsam bekomm ich den Überblick  Einige Fragen bleiben allerdings noch.

stell' in die Tabellen Universities und Applicants je ein Fremdschlüsselfeld 'TownID_F' und leg die Beziehung zur Tabelle 'Towns' mit referentieller Integrität an.

Kann ich nicht einfach die beiden Tabellen um das Attribut City erweitern und die Städte jeweils manuell eintragen? Hat es überhaupt Vorteile eine extra Tabelle für Städte anzulegen?

Kommt halt auch darauf an, wie du den Transfer vom Interview zur Tabelle 'ApplicantHavingJob' veranstaltest.
'Successful' (Ja/Nein) könnte dabei ein Auslöser für den Transfer sein (KÖNNTE) - soll heißen es kann auch weggelassen werden, wenn du den Datentransfer auf Formularebene dann anders anlegst. In einzelnen Fällen ist es durchaus gebräuchlich oder erlaubt eine Tabelle gewollt zu denormalisieren.

Damit kann ich leider nicht viel anfangen, da ich generell nicht weiß wie ich einen solchen Transfer realisiere :\ .. Vll hilft es ja wenn ich die Aufgabenstellung mal weiter vorlege.

Es soll realisiert werden, dass man sehen kann an welchem Datum ein Interview stattgefunden hat und ob der Bewerber nach diesem Interview für diesen Job eingestellt wurde.

Weiter müssen einige Abfragen an die Datenbank implementiert werden, sowie Reports kreiert werden. Dies sollte allerdings kein Problem sein, sobald ich die komplett richtige Beziehung zwischen allen Tabellen erstellt habe

Am Ende soll die ganze Datenbank über eine Art Navigationsleiste "gesteuert" werden können, bzw. einzelne Funktionalitäten darüber abgerufen und ausgeführt werden. Das würde ich dann über verschiedene "Forms" und Macros realisieren (sorry ich weiß leider nicht alle deutschen Begriffe.. ich benutze und lerne Access auf Englisch).
In dieser Navigation muss dann ja irgendwie realisiert werden, dass nach einem Interview der Bewerber genommen wird oder nicht.. dementsprechend müssten die anderen Tabellen sich ja ändern.. oder denke ich da zu kompliziert? :\

Mfg

[database]

Hi,

"...Hat es überhaupt Vorteile eine extra Tabelle für Städte anzulegen..."
JA, das Tabellenmodell bleibt dadurch normalisiert 
Es ist ja auch in der Folge kein besonderer Aufwand in einem FORMULAR ein Kombifeld einzubauen in dem alle Städte aufgelistet werden um sie so an die Fremdschlüsselfelder zu liefern.

"Es soll realisiert werden, dass man sehen kann an welchem Datum ein Interview stattgefunden hat ..."
Naja, das ist in der Interwiew-Tabelle zu ersehen. Andererseits kann man in der Interwiew-Tabelle das Feld 'ApplicantID_F' nicht eindeutig indizieren, da sonst kein Bewerber ein weiteres Interview haben kann.
Daraus folgt die Notwendigkeit der 'ApplicantHavingJob'-Tabelle.

"Damit kann ich leider nicht viel anfangen..."
Nun, wenn du weiter denkst - also an die Zeit nach der Erstellung des Tabellenmodells - könnte man mittels VBA einen Transfer der 'ApplicantID' und der 'UniJobID' in die Tabelle 'ApplicantHavinJob' vernalassen, wenn Successful auf Ja gestellt wird.

...über verschiedene "Forms" und Macros realisieren ..."
Das ist die 'normale' Vorgehensweise, die von meiner Seite (und nicht von meiner) positiv bewertet wird. Allerdings rate ich von der Verwendung von Makros persönlich ab und rate zu VBA. Die Nachteile von Makros wurden in diesem Forum X-Mal deutlich und unmissverständlich abgehandelt.

"In dieser Navigation muss dann ja irgendwie realisiert werden, dass nach einem Interview der Bewerber genommen wird oder nicht.. ..."
Nicht in der Navigation, das passiert bei der Dateneingabe und u.U. in der von mir skizzierten Art.

[MaggieMay]

Hi,

Hat es überhaupt Vorteile eine extra Tabelle für Städte anzulegen?

das hat vor allen Dingen den großen Vorteil, dass man unterschiedliche Schreibweisen zu einem Ort vermeiden kann, wenn diese zentral eingepflegt werden.