Datenbankmodellierung "erlernen" - benötige Tipps zum Einstieg

[gospat83]

Hallo zusammen,

ich bin von Beruf Diplom-Wirtschaftsinformatiker und habe eigentlich täglich mit Datenbanken zu tun, vor allem im Bereich Business Intelligence / Reporting. Meine SQL Kenntnisse sind sehr gut, nichtsdestotrotz habe ich mich bisher nie so richtig mit dem Thema Datenbankdesign- bzw. Modellierung beschäftigt. Das soll sich nun ändern. Rein zu Übungszwecken möchte ich eine Datenbank für einen Personal Trainer gestalten (und später in Verbindung mit Python als Anwendung umsetzen).

Könnt ihr mir konkrete Lektüre für mein Vorhaben empfehlen (natürlich nicht für die Personal Trainer Datenbank). Das DB-System ist mir egal, ich arbeite beruflich momentan mit MS SQL und in der Vergangenheit mit Oracle. MySQL / MariaDB geht natürlich auch. Am liebste wäre mir ein Buch, dass ein durchgehendes Beispiel verwendet um die Zusammenhänge bestmöglich zu verstehen. Schön wäre auch, wenn verschiedene Modelle erwähnt würden, z.B. Star Schema, Data Vault etc. Ich bevorzuge deutsch, auch wenn englisch kein Problem ist.

Danke und viele Grüße
gospat

 

[ukulele]

Also Normalisierung hatte ich tatsächlich mal in der Berufsschule und fand das mit das Beste, was man mir da überhaupt sinnvoll vermitteln konnte. Darüber hinaus habe ich mir alles in der Praxis angeeignet und um solche Dinge wie jetzt Star Schema zu verstehen reicht mir ein Blick in Wikipedia. ich habe also leider keine Buch-Empfehlung. Du scheinst sehr stark auf Datawarehouse abzuzielen, da stehe ich noch ziemlich am Anfang (bastel mir das in einigen Fällen grade selbst). Ich gucke mir tatsächlich meist real existierende, produktive Datenbanken von sehr lang gewachsenen Anwendungen an.

 

[gospat83]

Mir geht es eigentlich um eine Art "Best Practice". Es muss dafür nicht zwingend ein Buch sein, es könnte z.B. auch ein Tutorial sein. Ein kleines DWH zu erstellen ist relativ simpel, beruflich nutzen wir dafür momentan den Data Services Designer von SAP. Bei diesem Schritt sind die Tabellen in der Regel aber schon vorhanden.

Ich könnte ja mal bei Gelegenheit meinen Entwurf skizzieren und hier zur Diskussion stellen. Da lässt sich dann sicherlich noch einiges verbessern.

 

[ukulele]

Ich könnte ja mal bei Gelegenheit meinen Entwurf skizzieren und hier zur Diskussion stellen. Da lässt sich dann sicherlich noch einiges verbessern.

Konkrete Fragen lassen sich sicherlich gut klären. Zur Theorie in Form von Büchern oder Tutorials habe ich leider nichts beizutragen, habe da nicht die Zeit oder das berufliche Umfeld für.

 

[gospat83]

Hier mal eine schnelle Skizze in Excel (nicht UML konform), einfach zur Veranschaulichung.



Beziehungen sollten wie folgt sein denke ich:

Person - Trainingsplan 1:1
Übung - Trainingsplan n:m

Was bisher gar nicht berücksichtigt ist, ist ein zeitlicher Verlauf. Was passiert wenn der "Athlet" sich verbessert? Dann müsste man zumindest die Anzahl der Sätze und Wiederholungen anpassen oder sollte ich dem kompletten Trainingsplan einen Gültigkeitszeitraum geben und bei Veränderungen einfach ein neues Intervall starten?

 

[ukulele]

Person.Alter ist so eine Sache, besser währe Geburtsdatum oder Jahr oder du brauchst einen Bezugspunkt, z.B. ein Erstellzeitpunkt des Datensatzes.

Person.Geschlecht ist so eine Sache, das ist ein personenbeziehbares Datum i.S.d. DSGVO. Das ist ein hervorragendes Streitthema ob hier ein Verarbeitungsgrund gegeben ist. Viele CRM Systeme umgehen das Thema in dem sie eine Anrede und nicht das Geschlecht speichern. Wenn es dir also um Praxis geht, musst du auch die DSGVO berücksichtigen.

Person.TrainingsplanID bedeutet, eine Person kann einem Trainingsplan folgen. Die Person darf nicht nächstes Jahr wieder kommen und ein neues Training ablegen. Manche Systeme sind so spezifisch und das passt dann auch aber solche Einschränkungen sollte man erst gar nicht einbauen, finde ich. Besser wäre eine n:m Beziehung und auch Datum von, Datum bis.

Trainingsplan.ÜbungID ist vermutlich falsch. Ein Trainingsplan kann doch mehrere Übungen enthalten und nicht nur eine. Auch sollte eine Übung in mehreren Trainingsplänen vorkommen können. Die Anzahl Widerholungen gehört dann in die Beziehungstabelle und vermutlich auch was immer Anzahl Sätze sein soll

Wenn der Athlet das Training absolviert hat würde ich das Ergebnis ermitteln und ggf. hinterlegen. Es folgt dann ggf. ein verändertes Training, also ein neuer Trainingsplan. Ich habe den Trainingsplan jetzt als Programm aufgefasst, das von mehreren Athleten durchlaufen werden kann. Eventuell wird das dann für jeden Athleten auch noch individuell angepasst bei der Menge der Einheiten etc.

 

[gospat83]

Danke dir, das sind genau die Tipps die ich mir erhofft habe. Da fehlen mir einfach die Erfahrungswerte.

Ich glaube ich installiere mir mal lokal PostgreSQL, das wird hier ja ziemlich gelobt und dann habe ich eine konkrete Spielwiese. Einen lokalen Microsoft SQL Server habe ich bereits.

Ich werde mein Modell nochmal überdenken, dort ist auch noch nicht alles abgebildet was ich mir so vorstelle. Sobald ich Details habe, melde ich mich noch einmal hier zwecks Rückmeldung und Tipps.

 

[Dukel]

Für Historische Daten gibt es bei MSSQL Historale Tabellen:

Temporal tables - SQL Server

System-versioned temporal tables bring built-in support for providing information about data stored in the table at any point in time.

learn.microsoft.com

Bei anderen Datenbanksystemen muss man das ggf. nachbauen.

Historical Data Tracking in PostgreSQL - Part 1: Historical Table and Triggers

Introduction to Historical Data Tracking in PostgreSQL Historical data tracking, also known as #historification, plays a crucial role in maintaining a comprehensive record of changes made to data over time. This process allows us to access previous versions of data and analyze its evolution, providi

www.linkedin.com

Storing Historical Data with PostgreSQL and Automatic Partitions | Stable Kernel

stablekernel.com

EDIT:
Postgresql hat eine Extension dafür:

GitHub - arkhipov/temporal_tables: Temporal Tables PostgreSQL Extension

Temporal Tables PostgreSQL Extension. Contribute to arkhipov/temporal_tables development by creating an account on GitHub.

github.com