Unterstützung bei Datenmodellierung für Trainingsdatenbank gesucht.

[TerraX]

Hallo Forengemeinde,

ich bin neu hier angemeldet, habe mir aber schon einige gute Anregungen hier im Forum geholt. Nun möchte ich ein neues Datenbankprojekt angehen, was ich schon länger plane. Jetzt habe mich tatsächlich an die Umsetzung gemacht (jaja, die dunkle Jahreszeit naht ) und hoffe auf Eure Unterstützung. Es handelt sich um eine Datenbank zur Trainings- und Wettkampfkontrolle. Die Datenbank soll über das Internet abrufbar/bearbeit werden können. Daher möchte ich dieses Projekt auch nutzen, um MySQL/MariaDB zu lernen. Grundsätzliches Verständnis und Interesse für Programmierung ist vorhanden.

Folgendes soll abgebildet werden:
Es gibt verschiedene Sportler, die verschieden Sportarten ausüben (jeweils mehrere). Zum einen sollen die Daten der Sportler (Rahmendaten wie Name, Alter, etc. sowie die physische Entwicklung wie Gewicht, Ruhepuls, Maße, etc.) erfasst werden. Zum anderen soll jede Trainings-Session mit den relevanten Daten erfasst werden. Hierbei zu berücksichtigen ist, dass verschieden Sportarten abgebildet (v.a. Laufen, Fahrrad, Schwimmen, Ausgleichs- und Kraftsport) werden sollen. Der Umfang der Trainingsdaten unterscheidet sich folglich (z.B. Strecke für Kraftsport irrelevant). Außerdem soll die Datenbank als Log für die verwendeten Sportgeräte genutzt werden, die einer Alterung aufgrund von Zeit bzw. Abnutzung unterliegen bzw. gewartet werden müssen. Dies ist v.a. für das Laufen (Schuhe) und Fahrradfahren (Fahrrad) relevant. Auch hier unterscheidet sich wieder der Umfang der zu erfassenden Daten.

Die Datenbanklogik ist aus der beigefügten Access-DB (in Access lediglich nur, weil es für mich am einfachsten darstellbar war) bzw. dem Screenshot ersichtlich.

Folgende Fragen habe ich jetzt:

• Ist das Modell so in Ordnung, oder kann man es noch optimieren bzw. weiter normalisieren? V.a. vor dem Hintergrund des unterschiedlichen Datenumfangs. Bei dem Model hätte ich jetzt einige leere Felder je nach Sachverhalt. Ich weiß aber nicht, wie ich es sinnvoller abbilden soll.
• Ich möchte aus den gegebenen Daten einige andere Daten errechnen (z.B. Alter, BMI, Durchschnittsgeschwindigkeit, km-Zähler für Sportgerät). Bilde ich das sinnvollerweise über neue Abfragen oder innerhalb der einzelnen Tabellen ab?
• Außerdem sollen daraus weitere Reports (Wochen-/Monatssummen, etc.) abgeleitet werden. Dies erfolgt auf jeden Fall über entsprechende Abfragen, oder?
• Glaubt ihr MySQL bzw. MariaDB ist dafür geeignet?
  
• Würdet ihr es eher in Access aufbauen und dann migrieren oder lieber die Datenbank direkt im richtigen Format neu aufsetzen?

Mir schweben auch noch Erweiterungen vor, aber jetzt muss ich erst mal das genannte umsetzen. Also für Anregungen und Kritik bin ich sehr dankbar.

Vielen Dank.

Slay80

P.S.:
Zwar habe ich schon einigen Input für SQL, aber wenn ihr noch den ultimativen Tip für mich habt, wie ich mich für SQL fit machen kann…nur her damit.

 

[akretschmer]

Folgende Fragen habe ich jetzt:

• Ist das Modell so in Ordnung, oder kann man es noch optimieren bzw. weiter normalisieren? V.a. vor dem Hintergrund des unterschiedlichen Datenumfangs. Bei dem Model hätte ich jetzt einige leere Felder je nach Sachverhalt. Ich weiß aber nicht, wie ich es sinnvoller abbilden soll.
• Ich möchte aus den gegebenen Daten einige andere Daten errechnen (z.B. Alter, BMI, Durchschnittsgeschwindigkeit, km-Zähler für Sportgerät). Bilde ich das sinnvollerweise über neue Abfragen oder innerhalb der einzelnen Tabellen ab?
• Außerdem sollen daraus weitere Reports (Wochen-/Monatssummen, etc.) abgeleitet werden. Dies erfolgt auf jeden Fall über entsprechende Abfragen, oder?
• Glaubt ihr MySQL bzw. MariaDB ist dafür geeignet?
  
• Würdet ihr es eher in Access aufbauen und dann migrieren oder lieber die Datenbank direkt im richtigen Format neu aufsetzen?

Mir schweben auch noch Erweiterungen vor, aber jetzt muss ich erst mal das genannte umsetzen. Also für Anregungen und Kritik bin ich sehr dankbar.

Vielen Dank.

Slay80

P.S.:
Zwar habe ich schon einigen Input für SQL, aber wenn ihr noch den ultimativen Tip für mich habt, wie ich mich für SQL fit machen kann…nur her damit.

Mit Bildern hab ich es ja nicht so, aber

• Tabelle Sportler, Pul_Max und Größe sind sicherlich keine Konstanten, oder? Junge Menschen wachsen, ältere werden mit der Zeit auch wieder kleiner...
• berechenbare Daten wie BMI immer berechnen, nichjt speichern
• MySQL oder Access? Wenn das die Frage ist, dann ist die Antwort: weder noch. Es gibt besseres.

 

[TerraX]

Danke schon mal für die schnelle Rückmeldung. Also:

• Zu Puls_Max und Größe hatte ich mir die Frage auch gestellt: Auch wenn das aktuell nicht so das Thema ist (alle aus der Trainingsgruppe im mittleren Alter), ist es natürlich richtig und wieso sollte ich mich künstlich limitieren. Von daher werde ich es in die Tabellen Körper bzw. Maße übernehmen.
• Die Frage der richtigen Datenbank ist für mich erst mal zweitrangig. Erst mal will ich die Logik richtig abbilden. Zur Frage: Access ist für mich raus. MySQL bin ich nicht dran gebunden. Von daher bin ich auch für andere Datenbanken offen, wenn es die bessere Wahl ist.

 

[akretschmer]

Access ist für mich raus. MySQL bin ich nicht dran gebunden. Von daher bin ich auch für andere Datenbanken offen, wenn es die bessere Wahl ist.

Wenn das so ist empfehle ich Dir PostgreSQL. Absolut freie Lizenz (freier als MySQL), mehr Features als viele teure kommerzielle Datenbanken.

 

[Hony%]

Ist das Modell so in Ordnung, oder kann man es noch optimieren bzw. weiter normalisieren?

Als erstes frage ich mich wozu du die ID in den ganzen Tabellen benötigst. Zum Beispiel Sportler_ID und Datum sind als Schlüssel völlig ausreichend würden als PK nebenbei auch verhindern, dass mehrere Datensätze zum gleichen Datum eingepflegt werden. Beim Training gilt die gleiche Überlegung. Allerdings wäre es hier notwendig noch Training in den PK aufzunehmen. Sollte es tatsächlich mehrere Messungen pro Tag zu Körper geben bietet sich noch Tageszeit an.

Für jeden Datensatz eine überflüssige ID zu vergeben kann man natürlich machen. Aber welchen Zweck soll sie erfüllen? Gegebenenfalls wirst du dadurch nur zusätzliche Constraints vergeben müssen ohne zusätzlichen Nutzen zu erzielen.

Ich möchte aus den gegebenen Daten einige andere Daten errechnen

Das sind, wie akretschmer schon schrieb, berechnete Daten. Für einen einfachen und schnellen Zugriff würde ich hier auf VIEWs zurück greifen. »Sehen« aus wie Tabellen, werden allerdings erst zum Zeitpunkt des Zugriffs erzeugt.

Würdet ihr es eher in Access aufbauen und dann migrieren

Wenn du eine lokale Testdatenbank benutzen willst greif zu SQLite. SQLite ist als Backend deutlich leistungsfähiger als Access und besitzt in manchen Bereichen sogar einen größeren Funktionsumfang als MySQL.

Von daher bin ich auch für andere Datenbanken offen

In dem Fall würde ich dir zu PostgreSQL raten. Kostenlos verfügbar. Enormer Funktionsumfang und im Vergleich mit MySQL tatsächlich eine Datenbank. Gerade wenn es um eine Onlineanwendung geht ist die Unterstützung für PG in den letzten Jahren deutlich gewachsen.

Erst mal will ich die Logik richtig abbilden

Das ist sinnvoll. Deine Datenbank sieht relativ übersichtlich aus. Für ein Gesamtbild sind natürlich noch andere Hilfsmittel sinnvoll. Eine Anforderungsanalyse und ein darauf aufbauendes ERD sind sehr hilfreich und dienen später als Teil der Dokumentation.

 

[TerraX]

Als erstes frage ich mich wozu du die ID in den ganzen Tabellen benötigst. Zum Beispiel Sportler_ID und Datum sind als Schlüssel völlig ausreichend würden als PK nebenbei auch verhindern, dass mehrere Datensätze zum gleichen Datum eingepflegt werden. Beim Training gilt die gleiche Überlegung. Allerdings wäre es hier notwendig noch Training in den PK aufzunehmen. Sollte es tatsächlich mehrere Messungen pro Tag zu Körper geben bietet sich noch Tageszeit an.

Für jeden Datensatz eine überflüssige ID zu vergeben kann man natürlich machen. Aber welchen Zweck soll sie erfüllen? Gegebenenfalls wirst du dadurch nur zusätzliche Constraints vergeben müssen ohne zusätzlichen Nutzen zu erzielen

Ich habe es bisher immer als einfacher/praktikabler empfunden, ohne dass ich mir bewusst war, das dies ggf. Einschränkungen mit sich bringt. Aber ich lass mich ja gerne eines Besseren belehren. Von daher werde ich auf die IDs verzichten. Es kann aber in der Tat sein, dass ein Sportler mehrere Trainingseinheiten an einem Tag absolviert, von daher werde ich in dem Fall dann die Tageszeit hinzuziehen.

In dem Fall würde ich dir zu PostgreSQL raten. Kostenlos verfügbar. Enormer Funktionsumfang und im Vergleich mit MySQL tatsächlich eine Datenbank. Gerade wenn es um eine Onlineanwendung geht ist die Unterstützung für PG in den letzten Jahren deutlich gewachsen.

Dann werde ich mich mal mit PostgreSQL auseinandersetzen und mich da etwas einlesen. Kann ich davon ausgehen, dass wenn ich grundsätzlich SQL halbwegs verstanden habe, dass ich dann relativ einfach zwischen den einzelnen Datenbanken wechseln kann?

Für ein Gesamtbild sind natürlich noch andere Hilfsmittel sinnvoll. Eine Anforderungsanalyse und ein darauf aufbauendes ERD sind sehr hilfreich und dienen später als Teil der Dokumentation.

Da werde ich mich auch mal dransetzen und ein paar Sachen zu Papier bringen.

 

[Hony%]

Dann werde ich mich mal mit PostgreSQL auseinandersetzen und mich da etwas einlesen. Kann ich davon ausgehen, dass wenn ich grundsätzlich SQL halbwegs verstanden habe, dass ich dann relativ einfach zwischen den einzelnen Datenbanken wechseln kann?

SQL ist ja kein Hokuspokus, sondern hat sich gegen mehrere ähnliche Abfragesprachen als allgemeiner Standard durchgesetzt. Die Basis für SQL bildet dabei die Relationale Algebra. Dabei handelt es sich grob um eine an Datenbanken angepasste Mengenlehre. Klingt vielleicht erst mal langweilig – hilft aber enorm um ein besseres Verständnis zu erhalten.

SQL-92 wird annähernd komplett von jedem namhaften DBMS beherrscht. Eine »Neuerung« aus SQL:99, die CTE, ist ein extrem nützliches Feature, dass mittlerweile ebenfalls von fast allen DBMS unterstützt wird. Schlusslicht ist hier leider mal wieder MySQL und Forks. Daneben gibt es noch eine Menge andere Erweiterungen die in der Praxis aber nicht portabel sind, da sie nur von wenigen oder sogar nur einem einzigen DBMS unterstützt werden.

Leider hat jede Datenbank so ihre Eigenheiten. Das bedeutet letztendlich auch, dass SQL-Code für DBMS A nicht immer ohne Anpassungen auch in DBMS B funktioniert. Aber ganz grundsätzlich kannst du mit gutem Basiswissen jede SQL-Datenbank bedienen.

Ich habe es bisher immer als einfacher/praktikabler empfunden

Wird oft gemacht und leider auch in vielen Tutorials so gezeigt. Als ganz allgemeine Faustregel kann man sagen: So wenig wie möglich und so viel wie nötig. Künstliche Schlüssel, und nichts anderes ist eine ID, nur dann wenn sie notwendig sind um die Datensätze eindeutig zu machen und andere Möglichkeiten zu kompliziert sind oder neue Attribute erfordern würden.

von daher werde ich in dem Fall dann die Tageszeit hinzuziehen

Wenn es sich bei der Tageszeit um eine Uhrzeit handelt würde ich das Datum sowie die Tageszeit in einem DATETIME Wert als Messzeitpunkt zusammenfassen. Handelt es sich um einen literalen Wert wie zum Beispiel »Vormittag« ginge das natürlich nicht.

 

[ukulele]

Das mit den künstlichen Schlüsseln ist aber auch irgendwie so eine Glaubensfrage. Eine Spalte mehr tut keiner DB wirklich weh, beide Varianten haben Vor- und Nachteile. Ich z.B. empfinde es auch als einheitlicher und kann mich besser in einer DB orientieren wenn es immer nur eine einzelne Spalte als ID gibt.

Deine beiden Tabellen Körper und Maße irritieren mich. In beiden Fällen handelt es sich doch um eine Menge an Atributen die ein Körper zu einer Zeit hat (haben muss), die nur vieleicht aus verschiedenen Gründen nicht alle erfasst werden. Die Unterscheidung in zwei Tabellen ist künstlich und nicht durch die Normalisierung gegeben.

 

[Hony%]

Das mit den künstlichen Schlüsseln ist aber auch irgendwie so eine Glaubensfrage. Eine Spalte mehr tut keiner DB wirklich weh, beide Varianten haben Vor- und Nachteile. Ich z.B. empfinde es auch als einheitlicher und kann mich besser in einer DB orientieren wenn es immer nur eine einzelne Spalte als ID gibt.

Wie ich schon schrieb: Kann man machen. Die Constraints die mit dem PK einhergehen kann man natürlich auch zusätzlich definieren. Bei der Methode ohne ID werden es gegebenenfalls sogar mehr Attribute als mit. Bei einem PK aus zwei Attributen macht es keinen Unterschied. Bei drei Attributen benötigen wir aber ebenfalls drei für den Fremdschlüssel. Die Entscheidung für einen zusammengesetzten PK ist eher semantischer Natur. Eine ID gibt mir keinerlei zusätzliche Informationen, während ein natürlicher PK für sich alleine eine Aussage über die Art der Beziehung zwischen zwei Relationen machen kann. Damit bieten natürliche Schlüssel gleichzeitig eine Selbstdokumentation die von der ID nicht geleistet werden kann.

Praktisch können sich durch die ID aber auch zusätzliche Schreibkosten ergeben, da zusätzliche Constraints geprüft und auch zusätzliche Indizes erzeugt werden müssen. Der Aspekt fällt aber natürlich nur bei richtig großen Datenbanken nennenswert ins Gewicht. Das Projekt hier dürfte diesen Umfang nicht einmal annähernd erreichen.

Deine beiden Tabellen Körper und Maße irritieren mich. In beiden Fällen handelt es sich doch um eine Menge an Atributen die ein Körper zu einer Zeit hat (haben muss), die nur vieleicht aus verschiedenen Gründen nicht alle erfasst werden. Die Unterscheidung in zwei Tabellen ist künstlich und nicht durch die Normalisierung gegeben.

Nach meiner Interpretation werden die Maße einmal pro Trainingstag gemessen während die Körperwerte mehrfach gemessen werden können. Die Alternativen sind damit NULL-Werte oder Redundanzen. Ersteres verkompliziert die Abfrage und zweiteres müsste normalisiert werden.

 

[TerraX]

Das mit den künstlichen Schlüsseln ist aber auch irgendwie so eine Glaubensfrage. Eine Spalte mehr tut keiner DB wirklich weh, beide Varianten haben Vor- und Nachteile. Ich z.B. empfinde es auch als einheitlicher und kann mich besser in einer DB orientieren wenn es immer nur eine einzelne Spalte als ID gibt.

Ich werde hier noch mal in mich gehen, aber ich denke, dass ich den Sportlern eine ID zuordne, bei den anderen IDs aber auf einen Schlüssel aus zwei Attributen zurückgreifen werden.

Deine beiden Tabellen Körper und Maße irritieren mich. In beiden Fällen handelt es sich doch um eine Menge an Atributen die ein Körper zu einer Zeit hat (haben muss), die nur vieleicht aus verschiedenen Gründen nicht alle erfasst werden. Die Unterscheidung in zwei Tabellen ist künstlich und nicht durch die Normalisierung gegeben.

Hony% hat es schon angedeutet. Das ist darauf zurückzuführen, dass die Körperwerte häufiger als die Maße genommen werden sollen. Außerdem sind die Anforderungen je nach Sportart bzw. Trainingszweck unterschiedlich. Nicht für jeden der die Körperwerte nutzt, sind auch die Maße von großer Bedeutung. Daher die Trennung.

Aus einem ähnlichen Grund werde ich bezüglich der Trainingsrelation noch mal überlegen, ob ich da nicht auch eine Trennung vornehme. Strecke, Höhenmeter, Sportgerät werden nicht immer benötigt.

Jetzt werde ich erst mal schlafen gehen und mich dann morgen ausgeruht an das ERD machen und die Datenlogik daran noch mal auf die Anforderungen überprüfen.