Bitte um Hilfe beim Modellieren einer Datenbank für einen gemeinnützigen Verein

saerdna

Fleissiger Benutzer
Beiträge
82
Hi.

Ich habe noch nie eine richtige Datenbank modelliert.

Der gemeinnützige Verein heilehaus-berlin.de bat mich um Hilfe.
Wir unterstützen unter anderem Geflüchtete und Obdachlose.

Eine Lösung um Räume für Gesundheitskurse zu verwalten wird dringend benötigt.

Das Ganze ist sicher nicht trivial.

Als ersten Schritt habe ich alle Entitäten gesammelt und eine erste grobe Skizze angelegt:

Hat vielleicht jemand Lust mich bei der Modellierung etwas zu begleiten und zu unterstützen? Ich würde mich sehr freuen : )
 
Werbung:
Kleine Kritik: Namensgebung mit TBL_ als Präfix wird üblicherweise (jedenfalls in meiner Bubble) als recht sinnlos angesehen. Ich vergleiche das gerne damit, dass man beim Programmieren alle Klassen mit dem Präfix Class versieht, alle Variablen mit dem Präfix Var oder seine Kinder z.B. "Kind_Peter" oder "Kind_Maria" nennt.
 
Danke für den Hinweis zur Namenskonvention.

Ich hatte die Empfehlung mal in einem Buch zu Datenbanken gelesen und fand sie plausibel. Denn ohne Präfix kann man ja in Abfragen, wo sowohl Tabellen- als auch Spaltennamen vorkommen diese nicht unterscheiden.

Aber ich werde dazu nochmal recherchieren.
 
Denn ohne Präfix kann man ja in Abfragen, wo sowohl Tabellen- als auch Spaltennamen vorkommen diese nicht unterscheiden.
Anhand der Stelle innerhalb der Abfrage kann man immer unterscheiden ob es eine Spalte oder eine Tabelle ist. select tabelle from spalte geht halt schlicht nicht.

Was man aus diesem Grund tatsächlich vermeiden sollte, sind Spaltennamen, die genauso heißen wie die Tabelle.
 
Im Frontend einer gestern erstellten Test-Datenbank steht z.B.:

LOOKUP([taReporterEmail], "TBL_Reporter", "reEmail", "reForename")

Ohne Präfix "TBL_" wäre es meinem Empfinden nach schwerer sofort zu erkennen, ob der Tabellenname an der richtigen Stelle steht.

Und das andere Argument, was für ein Präfix spricht, hattest du gerade genannt: es wird automatisch vermieden, dass es ein Spaltenname einem Tabellennamen entsprechen kann. Dieses Versehen ist dann praktisch ausgeschlossen.

Möchtest du mir deine vollständige Namenskonvention nennen?
Auch in Bezug auf CamelCase, Unterstriche, Bindestriche, Präfixe in Spaltennamen, etc.
 
Möchtest du mir deine vollständige Namenskonvention nennen?
Auch in Bezug auf CamelCase, Unterstriche, Bindestriche, Präfixe in Spaltennamen, etc.
Das ist natürlich sehr subjektiv, ich persönlich verwende grundsätzlich Kleinschreibung mit Unterstrich, Tabellennamen im Singular und weder für Spalten noch für Tabellen irgendwelche Präfixe. Wenn ich Tabellen irgendwie thematisch "gruppieren" möchte, dann verwende ich Schemata (wie gut das funktioniert, hängt natürlich vom verwendeten DBMS ab, in Oracle ist das sehr umständlich in Postgres sehr einfach).
 
Ich habe die Namen nun angepasst. Zum Tabellenpräfix "tbl_" konnte ich mir noch keine abschließende Meinung bilden. Lasse ich nochmal sacken.

Kann denn jemand etwas zu meiner Skizze der Modellierung sagen?
 
Raum finde ich etwas dünn definiert, eine RaumNr, Etage, Gebäude,... wären nicht schlecht

Kursleiter und KursleiterErsatz kommt mir sehr redundant und gleichzeitig steif vor. Keine Ahnung ob das so irgendwie die Realität abbildet. Ersatze sind m.E. von Natur aus spontan und nicht so statisch definiert.

Kurs und KursSerientermin sind auch etwas steif und redundant oder?

Ich würde vielleicht gar keine Verbindung von Kurs zu Leiter definieren, sondern eher so eine Definition wie in KursSerientermin.

Eine Tabelle, die aus einem abstrakten Kurs und einem (beliebigen) Referenten einen echten Termin definiert, konkreter Tag, Uhrzeit, Kursleiter (oder Vertretung egal).

Und vielleicht einfach mal schauen, was es schon gibt in der OpenSource Welt. Fertige Webanwendungen dafür existieren wahrscheinlich, nicht grad die Obdachlosen Raum App, aber Anwendungen, die Kurse und Räume verwalten, egal für wen.
 
@dabadepdu

Erstmal vielen Dank, dass du das angesehen hast : )

Raum finde ich etwas dünn definiert, eine RaumNr, Etage, Gebäude,... wären nicht schlecht
Wir haben nur 6 Räume. Alle haben einen eindeutigen sprechenden Namen.
Kursleiter und KursleiterErsatz kommt mir sehr redundant und gleichzeitig steif vor. Keine Ahnung ob das so irgendwie die Realität abbildet. Ersatze sind m.E. von Natur aus spontan und nicht so statisch definiert.
kursleiter_ersatz ist einfach eine zusätzliche Person, die jeder Kursleiter benennt. Wir können diese zusätzliche Person in dringenden Fällen ansprechen, wenn wir den Kursleiter nicht erreichen.

Mir ist noch kein besserer Name eingefallen : )

Kurs und KursSerientermin sind auch etwas steif und redundant oder?
Hier weiß ich noch nicht, warum du "Kurs" steif findest?
Wie würdest du so eine Veranstaltung nennen?

KursSerientermin drückt aus:
Es gibt Kurse, die finden nur ein einziges Mal statt.
Und es gibt Kurse, die finden wiederkehrend wöchentlich oder zweiwöchentlich statt: ein Serientermin.

Ich habe jetzt die Entities zum Serientermin in der Tabelle tbl_kurs integriert.

Eine Tabelle, die aus einem abstrakten Kurs und einem (beliebigen) Referenten einen echten Termin definiert, konkreter Tag, Uhrzeit, Kursleiter (oder Vertretung egal).
Meintest du das so wie in der aktuellen Skizze?
Und vielleicht einfach mal schauen, was es schon gibt in der OpenSource Welt. Fertige Webanwendungen dafür existieren wahrscheinlich, nicht grad die Obdachlosen Raum App, aber Anwendungen, die Kurse und Räume verwalten, egal für wen.
Klar, das könnte man auch noch schauen.

Aber erstmal möchte ich einen eigenen Versuch mit AppSheet und einer Datenbank starten. Bisher gab es ja keine GUI-Tools zum Erstellen von Frontends im Web oder auf einem Mobilgerät.
 
Also lautet deine Empfehlung PostgresSQL, wenn auch MariaDB und MySQL möglich wären?

Und welches Datenbanktool mit integriertem ER-Diagramm empfiehlst Du bitte?
 
kursleiter_ersatz ist einfach eine zusätzliche Person
Es ging mir da weniger um den Namen, sondern ein realistisches und flexibles Modell.
Siehe unten.
Wie würdest du so eine Veranstaltung nennen?
Dito, es geht nicht um den Namen, sondern die definierten Referenzen.
Ein Kurs ist für mich etwas generelleres. Der hat einen Namen, ein Thema und sowas wie Dauer, Openair, Schwimmbad, Office und anderen Kram.
Ob er einmal oder mehrmals stattfindet, an festen Wochentagen oder immer im Herbst, wo konkret und mit welchem Referenten, das ist erstmal egal.

Ich habe jetzt die Entities zum Serientermin in der Tabelle tbl_kurs integriert.
Wahrscheinlich keine gute Idee. Eher andersrum, die Dinge voneinander entkoppeln.
Das was glaub ich vorher der Serientermin war oder so , würde ich ausbauen. Ein tatsächlich stattfindender Termin, konkretes Datum, Uhrzeit., Kursleiter (oder Vertretung), Raum, Schlüsselkram usw. für jede abzuhaltende, verschobene, stattgefundene Veranstaltung.
Der Kurs selbst nur mit allgemeinen, statischen Infos.
So können Kurse regulär geplant, verschoben werden, mit dem geplanten Leiter oder seiner Vertretung (wer auch immer durchgeführt hat) usw. usw. eingetragen werden. Entweder planerisch oder akut, bei Krankheit usw., die App kann immer(!) die richtigen Daten zeigen, auch bei Feiertagen, Raumänderungen usw.
Das geht natürlich auch für Kurse, die nur einmal stattfinden.
Also lautet deine Empfehlung PostgresSQL, wenn auch MariaDB und MySQL möglich wären?
Das wäre auch meine Empfehlung. Nicht nur weil es sehr reich an Funktionen ist, es ist robuster, näher am SQL Standard, bietet zahlreiche Erweiterungen (wie schon gesagt wurde, Range Types, Exklusion Constraints und vieles mehr), hat eine starke Community und folgt einem schnellen, regelmäßigen Update Zyklus.
welches Datenbanktool mit integriertem ER-Diagramm empfiehlst Du bitte?
Du hast doch schon DBeaver gefunden, versuch mal damit, wie weit Du kommst.
Ich kann aktuell nichts empfehlen, weil ich schon lange keine dieser Tools mehr benutzt habe, ist eher was für große Teams und große Projekte finde ich und man kann problemlos nur für solche Tools in der Profiliga 4-stellige Beträge oder mehr ausgeben.
 
Werbung:
Ein Kurs ist für mich etwas generelleres. Der hat einen Namen, ein Thema und sowas wie Dauer, Openair, Schwimmbad, Office und anderen Kram.
Ob er einmal oder mehrmals stattfindet, an festen Wochentagen oder immer im Herbst, wo konkret und mit welchem Referenten, das ist erstmal egal.
Jeder Kurs wird eigenständig gehalten vom Kursleiter. Daher gehören aus meiner Sicht alle Attribute zum Kurs.

Denn nicht wir bieten den Kurs an und sorgen für Kursleiter oder gegebenenfalls für einen Nachfolger.

Das war mein Motiv für die Integration des Attributes "Periodizität" (einmalig, wöchenlich, zweiwöchentlich) zurück in die tbl_kurs.

[PostgreSQL]
OK, da gibt es also einen Konsens, prima. Also werde ich die nehmen.
Du hast doch schon DBeaver gefunden, versuch mal damit, wie weit Du kommst.
Ich kann aktuell nichts empfehlen, weil ich schon lange keine dieser Tools mehr benutzt habe, ist eher was für große Teams und große Projekte finde ich und man kann problemlos nur für solche Tools in der Profiliga 4-stellige Beträge oder mehr ausgeben.
Hätte ja sein können, dass jemand ein ganz anderes Tool aus Erfahrung empfehlen möchte.

Aus Neugier:

In welchen konkreten Merkmalen unterscheiden sich Tools der Profiliga für 4stellige Beträge von den FOSS-Tools wie DBeaver?

Insbesondere in Bezug auf Usability.

Es geht ja nicht um riesige Datenmengen oder riesige Zugriffszahlen durch Clients. Es geht vorrangig um organisationsinterne Nutzung.
 
Zurück
Oben