Datenbankmodell überprüfen

[Asura]

Hallo miteinander,

ich bin gerade dabei ein kleines Datenbankmodell zu erstellen für ein Tool zur Abspeicherung von Ausbildungsnachweisen.
Ich würde mich freuen, wenn ihr dieses mal kritisch beurteilen und mir Tipps geben könntet, wie ich es eventuell besser/richtiger gestalte.

Ich möchte es aber vorerst kurz beschreiben (in Klammern sind die Entitäten):

1. Bevor eine Ausbildungsleistung gespeichert wird, wird ein Ausbildungsereignis (AE) erstellt. Hier trägt der Anwender Daten ein, wie wo, wann, welche Firma, welches Ausbildungspersonal und welche Ausbildungsnachweisnummer im Ereignis hinterlegt werden soll.
2. Danach kann der Auszubildende sich zu diesem Ausbildungsereignis registrieren (AR).
3. Nach einer Leistung soll dann in Ausbildungsleistung (AL) ein Datensatz erstellt werden, zu welchem Ausbildungsereignis die Leistung gehört, wer der Auszubildende ist (FK_Personal_PersNr_ID), wer der Ausbilder war, welche Übung und ob bestanden oder nicht bestanden.

So viel zum Ablauf, nun noch ein paar Anmerkungen:

• In den Entitäten Ort, Firma und Übung sollen einfach standardisierte Werte hinterlegt werden, damit man über ein DropDown diese auswählen kann. Eventuell macht es aber auch Sinn diese gar nicht als FKs zu fassen, sondern einfach nur eigene Entitäten zu erstellen ohne Verbindung.
• In der Entität "Personal" sind alle Daten jedes Personals hinterlegt mit seiner Personalnummer, um eine eindeutige Zuweisung zu haben.

Nun zu meinen Fragen:

1. Sollte ich die Entitäten Übung, Ort, Firma als FKs einbinden oder ohne FKs arbeiten?
2. Wie sollte die Benennung eindeutiger verlaufen. Aktuell ist es ein kunter und drüber und ich bin mir unsicher über eine eindeutige Beschriftung. Insbesondere bei den Ausbilder 1 - 4, da das ja FKs von FK_Personal_PersNr_ID darstellen.
3. UUID oder doch lieber Autoincrement verwenden?
4. Ist der Schritt über die Registrierung notwendig? Ich dachte mir halt, dass nach einer Registrierung der Anwender (Ausbilder) eine Liste der Auszubildenen angezeigt bekommt und dann schneller über ein entsprechendes FrontEnd die Ausbildungsleistungen eintragen kann.

Ich würde mich freuen, wenn ihr mir hier weiterhelfen könntet .

[jobo]

1. Was wäre der Vorteil ohne echten FK? FK steigern sicher die Datenqualität. Der Inhalt der FK Entitäten muss einfach erweiterbar und auch korrigierbar sein.
(man kann vielleicht fragen, mandatory oder nicht, das sind Details, die evtl. auch fallweise unterschiedlich sind. Z.B.: der eine Ausbildungsort ist immer konstant für den einen Ausbilder und sowieso klar, also warum muss man ihn angeben? So was kann nerven und zu Ablehnung führen. Man macht es idR eher locker und schärft bei Bedarf nach)
2. Insgesamt sind Benennungen frei. Eher Englisch als Deutsch, Hauptsache einheitliche Sprache, das ist offenbar gegeben. Ist alles in ein bereits bestehendes System eingebunden, mit vorhandenen Regeln, würde man sich daran halten. FK muss nicht in den Namen des Feldes, das ist eine Eigenschaft, die dem Entwickler anhand der „Karte“/ des Modells deutlich sein sollte. Wenn mit „FK“, dann lieber als Suffix, statt als Präfix. Es erschließt sich nicht, warum einige Dinge als (starke) Abkürzung benannt sind, andere nicht. (Es ist mir nicht bekannt, dass es nennenswerte Längenbeschränkungen bei SQLite gibt.) Ausbilder1 - 4 ist nicht so toll. Sind es immer genau 4? Werden es absehbar nie mehr oder weniger? Ich würde es ohne Detailkenntnis einen Konstruktionsfehler nennen. Das sollte per n:m Relation angegeben werden. Sonst hat man z.B. Probleme, wenn man Abfragen/ Reports über alle Ausbilder macht, alles immer 4x.
Primärschlüssel werden gerne nur mit ID bezeichnet. Der Sinn ergibt sich dann durch <tabellenname>.id., Fremdschlüssel dann als <tabellenname>.<fremdtabellenname>_id. (wie gesagt, ohne „FK“ Anhängsel).
3. UUID nimmt man gerne in verteilten Systemen, weil sie autark eindeutige Werte bilden, ohne Server Verfügbarkeit/-Vorgabe. Wäre nicht meine erste Wahl in einem kleinen Client Server System.
4. Wenn das dem Ausbilder etwas Arbeit abnimmt okay (wenn es in der Praxis auch funktioniert) Wenn es aber praktisch bedeutet, alle AZUBIS brauchen Systemzugriff -nur dafür allein- und der Prozess ist blockiert, falls sie keinen Zugriff haben/bekommen oder zu faul sind, es zu machen, dann wird es komplizierter, als es sein muss. (Es ist einfacher, ein System zu bauen und zu betreuen für 100 Ausbilder, als für 100 Ausbilder mit jeweils 200 AZUBIS – jeweils als Anwender- durch die Registrierung)
Vielleicht lieber Import von Namenslisten, oder „Runtertippen“ von Namenslisten oder Copy/Paste aller Namen der Übungsteilnehmer… das bietet aber auch Raum für Fehler. Ebenso wie die Registrierung durch den AZUBI selbst. Ich habe nirgendwo eine fachliche oder individuelle ID für den AZUBI entdeckt. Wie geht man mit Doppelregistrierung, falscher Registrierung, Autorisierung, Authentifizierung um? Fehlbedienung, Manipulationsschutz?

Und wenn schon Personal und viele AZUBI Namen, dann die Frage:
Warum werden nicht auch die AZUBI einmalig angelegt/erfasst und sind „wiederverwendbar“