Newbie braucht einen Tip zur Strukturierung

[arnold85]

Hallo Ihr,
ich bin eigentlich Webdesigner der aber immer mehr zur Programmierung überläuft. Nun habe ich mein erstes Projekt wo eine etwas aufwändigere Datenbank zum Einsatz kommen muss und ich weiß schon nicht richtig weiter.
Mit dem dazugehörigen Programm erstellt man Trainingspläne (also eine Abfolge von Übungen). Man kann aber nicht nur Übungen betrachten sondern auch selbst welche erstellen sowie natürlich nach Übungen anhand bestimmter Schlüsselwörter suchen.

Jede Übung beinhaltet folgende Daten:
1. Name der Übung
2. Ziele der Übung
3. Keywords der Übung
4. Beschreibung des Übungsablaufes
5. Bilder/Fotos zur Übung
6. Kurzbeschreibung zu jedem Foto

Von all diesen Punkten sind nur 1 und 4 immer nur ein Wert (Varchar). Jede Übung kann aber beliebig viele Ziele, Keywords, Bilder und entsprechende Kurzbeschreibung haben die auch alle völlig frei gewählt werden können.
Wie kann ich das umsetzen und dabei sicherstellen das die Datensätze gut durchsuchbar bleiben und einigermaßen übersichtlich.
Eigentlich wollte ich mySQL verwenden allerdings komm ich nicht drauf wie ich das anständig strukturieren soll. Auch stundenlange suchen nach ähnlichen Beispielen brachte mir keine hilfreichen Erkenntnisse.
Wie würdet Ihr das angehen und aufbauen. Oder doch eine Objectorientierte Datenbank? Wir sieht es da mit der Durchsuchbarkeit aus?
Bitte um Hilfe

[arnold85]

Bisher wäre mein Einsatz mit mySQL alles in einer Tabelle zu halten und den den Spalten
2. Ziele der Übung
3. Keywords der Übung
5. Bilder/Fotos zur Übung
6. Kurzbeschreibung zu jedem Foto
alle Werte als Varchar einzufügen mit einer bestimmten Zeichenfolge wie $$?? voneinander getrennt und diese dann in der Webanwendung (flash .swf bzw. im zwischengeschalteten PHP/Java) wieder zu zerstückeln. Würde wohl gehen aber richtig optimal ist das sicher nicht

[Falk Prüfer]

Hallo,

...Würde wohl gehen aber richtig optimal ist das sicher nicht

Das ist nicht nur Suboptimal, sondern auch vom Ansatz her völlig falsch. Eine vernünftige Suche wird damit kompliziert bzw. unmöglich. Du solltest dich mit den Normalformen eines relationalen Datenbankschemas auseinandersetzen und danach entscheiden, in welche Relationen du dein Daten aufteilst.
Anbieten würde sich:
Übungen (id, Beschreibung des Übungsablaufes),
Ziele (id, FK_Übung, Ziel),
Keywords (id, FK_Übung, Keyword),
Bilder/Fotos (id, FK_Übung, Bild/Foto, Kurzbeschreibung)

Gruß Falk

[arnold85]

okay, schonmal vielen dank dafür. Ich hatte mich schon mit Normalisieren auseinandergesetzt aber ich denke man muss es doch ein paar mal praktisch gemacht haben um sich da so durchzudenken. Werde die Struktur die Du vorgeschlagen hast erstmal versuchen so umzusetzen. Vielleicht kannst Du mir ja später nochmal ein bischen helfen denn ich habe das Gefühl hier und da sicher nochmal zu hängen.
Vielen dank
Arne

[arnold85]

Hallo Ihr,
also die Anforderungen die mein Programm an die Datenbank stellt sind schon recht komplex denke ich so dass ich mich als absoluter Anfänger ein bischen schwer tue. Bis jetzt ist folgendes als Struktur dabei rausgekommen. Wäre toll wenn Ihr mal drüber schauen könntet und mir sagen ob das ganze so sinn macht oder ob ich noch grundsätzliche Fehler mache bzw wo schwächen in der Struktur liegen.
Das Programm soll letztendlich dazu dienen das Physiotherapeuten ihren Patienten in kurzer Zeit Eigenübungspläne am Computer zusammenstellen und ausdrucken können.
Unten findet ihr die Grafik zum Aufbau der Datenbank
Beschreibung von links im Uhrzeigersinn:

1.Die vorgefertigen Übungen (in der Mitte) sollen in mehrere Modulen(bzw Pakete) aufgeteilt sein. Somit soll jedem Modul mehrere Ubungen zugeordnet werden. Eventuell können auch einige Übungen in mehreren Modulen vorkommen. Welche Ubungen welchen Modulen zuzuordnen sind wird in Table lnkModuleUbungen geregelt.
2.Jeder Übung soll genau eine Ausgangsposition zugeordnet werden. Die gleiche Ausgangsposition soll mehreren Übungen zugeordnet werden können.
3. Jede Übung kann mehrere Übungsziele haben. Jedes Übungsziel kann mehreren Übungen zugeordnet werden.

ab jetzt wird es etwas komplexer:
4. Jeder Übung sollen mehrere Geräte zugeordnet werden können die in der Übung benötigt werden.Jedes Gerät kann auch in mehreren Übungen gebraucht werden. Es gibt aber noch eine weitere Verbindung zu den Geräten und zwar von Kunden(bzw Patienten). Über das Table lnkKundenGeraete soll gespeichert werden welche Geraete (wie z.B. ein Gymnastikball oder eine Hantel) welcher Kunde a)zuhause hat b)geplant hat zu kaufen oder c)vom Therapeut zur Anschaffung empfohlen bekommen hat. a) b) oder c) ist in der Tabelle KundenGeraeteStatus gespeichert.

5. Im Programm können mehrere Ubungen als ein Übungsplan zusammengestellt und so angespeichert werden. Jedem Ubungsplan können also mehrere Übungen zugeordnet werden und jede Übung kann in mehreren Übungsplänen vorkommen. In lnkKundenUbungsplaene soll wiedrum gespeichert werden welche Ubungspläne welchen Kunden an welchem Datum von welchem Trainer(bzw Therapeut) zugeordnet worden sind.

6. Da die Trainer auch selber Ubungen erstellen können soll in lnkTrainerUbungen gespeichert werden welcher Trainer welche Übung erstellt hat.

Wer mir bis hierhin folgen konnte dem sollte der Rest aus der Grafik klar werden.
Bitte gebt mir mal ne Rückmeldung ob Ihr dass für einen guten, sinnvollen und einsetzbaren Entwurf haltet oder wo meine Denk- und Verständnisfehler zur Datenbankstrukturierung liegen.
Danke schonmal
klick hier für größere Ansicht

[Falk Prüfer]

Hallo,

...Bitte gebt mir mal ne Rückmeldung ob Ihr dass für einen guten, sinnvollen und einsetzbaren Entwurf haltet oder wo meine Denk- und Verständnisfehler zur Datenbankstrukturierung liegen.

es ist nicht unbedingt Sinn und Zweck dieses Forums kostenlose Reviews komplexer Strukturen und Datenbankentwürfe anzubieten. Wir werden dir gerne bei konkreten Problemen helfen, aber offensichtlich hat niemand Zeit und Lust dein umfangreiches Schema einer Prüfung zu unterziehen. Daran ändert sich auch nichts, wenn du die gleiche Frage mehrfach postest. Den zweiten Thread habe ich als Doppelposting gelöscht.
Und bitte hänge solche rieseigen Bilder als Anhang an! Der gesamte Thread wird sonst nahezu unlesbar. Also bitte wandle das Bild in ein JPG um, editiere deinen Beitrag und füge es als Anhang hinzu!

Gruß Falk

[arnold85]

okay, ich hätte gedacht dass es für einen Profi nur ein paar kurze blicke benötigt um einzuschätzen ob die Prinzipien relationaler Datenbanken verstanden und sinnvoll umgesetzt wurden oder nicht. Und ein komplettes Review war auch nicht meine Erwartung sondern mehr ein "sieht sinnvoll aus, kann man so machen" oder "du hast scheinbar jenes und welches noch nicht richtig verstanden. Guck mal hier und hier und beschäftige dich nochmal damit". Ich möchte ja nicht dass jemand für mich meine Datenbank gestaltet sondern nur eine Information ob ich grundlegend in die falsche Richtung arbeite damit ich nicht erst am Ende meiner Arbeit feststelle dass es alles so nicht funktionieren kann.
Wenn ich gewusst hätte wie man einen Beitrag in ein anderes Forum verschiebt hätte ich dass gemacht so habe ich aber nun doppelt gepostet weil mein Beitrag in diesem Bereich einfach nicht mehr ganz passend war.
Ich bin auch in vielen anderen Foren zum Thema Programmierung und häufig überrascht wie enorm hilfsbereich sich die anderen zeigen. Eine solche kurze Einschätzung wie ich mir hier erhofft habe stellt sonst halt kein Problem da. Jetzt weiß ich dass es hier wohl nicht so funktioniert und das akzeptiere ich auch keinem vorwerfen. Ich habe es nur einfach falsch eingeschätzt.
danke

[dimitri]

ich hätte gedacht dass es für einen Profi nur ein paar kurze blicke benötigt um einzuschätzen ob die Prinzipien relationaler Datenbanken verstanden und sinnvoll umgesetzt wurden oder nicht.

Eher nicht. Ein Grundsatz bei kommerziellen Anwendungen lautet: pro Entität 50 Tsd Euro Entwicklungskosten. Du hast 28 Stück davon. Entweder ist Deine Anwendung so komplex oder aber dein ER Modell ist überdimensioniert.

Bei einem Millionenprojekt wie Deinem Bedarf es also schon deutlich mehr als einen kurzen Blick, wobei mein Tipp eher Richtung überdimensioniert geht ;-) Alle Entitäten mit einem PK und einem weiteren Attribut würde ich mir näher ansehen, die erscheinen mir nicht ganz koscher. Warum verwendest Du z.B. zwischen Übungen und Fotos eine n:m Auflösungstabelle. Werden Bilder wirklich mehreren Übungen zugeteilt?

Dim

PS: Gegen das Posten von ER-Modelen hat niemand etwas und ich seh das auf meinem 24'' Zöller auch entspannter, aber auf einem 21'' Monitor wird das schon sehr lästig.

[hwoess]

Hallo Dimitri,

rechnest du wirklich mit 50.000 € je Entität? Wo kommt das her? Ich würde gefühlsmäßig sagen, das ist eine 10er-Stelle zu hoch. Aber ich habe meine Projekte eh immer zu billig verkauft

bye,
Helmut

[arnold85]

vielen dank für die Rückmeldung.
@dimitri: bzgl. der Beziehung Fotos und Übungen soll es tatsächlich möglich sein ein Foto auch mehreren Übungen zuzuordnen. Wäre zwar nicht unbedingt notwendig aber da viele Übungen eine gleich Ausgangsstellung haben könnte es nützlich und vorallem speichersparend sein.
"Alle Entitäten mit einem PK und einem weiteren Attribut würde ich mir näher ansehen, die erscheinen mir nicht ganz koscher" weil Du dich wunderst, dass so viele Entitäten wie Module, Ubungsziele, Gerät... nur ein einziges Attribut haben. Zunächst hatte ich auch deutlich weniger einzelne Tabellen und dafür mehr Attribute aber da zwischen fast allen "Komponenten"(mir fehlt hier ein passender Begriff) ein n:m Beziehung besteht habe ich keine andere Möglichkeit gesehen als aus einem Großteil der Attribute eigenen "Entitäten" zu machen und die dann über Auflösungstabellen zu verbinden. Gibts dafür nen anderen Ansatz und siehst du das als problematisch an?
Und die Rechnung von 50000€ pro Entität wäre mir bei meinem bisherigen Aufwand für meine Datenbankstruktur mit wie du schreibst 28 Entitäten(wobei es meinem leihenhaften Verständniss nach zwar 28 Tabellen aber lange nicht 28 Entitäten sind) auch ein Rätsel. Selbst bei 5000€ käme ich auf einen unfassbarer Stundenlohn (Vorrausgesetzt, dass was ich bisher gemacht habe, macht tatsächlich auch nur ansatzweise Sinn und könnte so funktionieren).