AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Datenbankmodell überprüfen

Datenbankmodell überprüfen

Ein Thema von Asura · begonnen am 17. Aug 2021 · letzter Beitrag vom 17. Aug 2021
Antwort Antwort
Asura

Registriert seit: 10. Jun 2013
87 Beiträge
 
#1

Datenbankmodell überprüfen

  Alt 17. Aug 2021, 16:40
Datenbank: SQLite • Version: 3.36.0 • Zugriff über: Flask
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 .
Miniaturansicht angehängter Grafiken
datenbankmodellierung.jpg  
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.963 Beiträge
 
Delphi 2010 Enterprise
 
#2

AW: Datenbankmodell überprüfen

  Alt 17. Aug 2021, 22:47
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“
Gruß, Jo
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +2. Es ist jetzt 17:10 Uhr.
Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf