Grundsatzfrage DB-Aufbau

[Josie1234]

Nach durchforsten des Webs nach einer Antwort, bin ich verwirrter als vorher.

Hintergrund:
Ich habe einen SQL-Datenbank mit ein paar Tabellen darin. Es sind Informationen über Veranstaltungen. Eines dieser Tabellen ist ziemlich groß, i.e. viele Spalten. Sie beinhaltet die Informationen über eigentliche Veranstaltung. Noch ist es überschaubar in Anzahl Datensätze. Ich bin dabei die ganze Seite neu zu stricken (versuche ein bisschen "sauberer" zu programmieren), und möchte, wenn ich schon dabei bin, auch den DB neu ordnen - halt wie es sein soll.

Datenbeispiele:
1. z.B. "Schwierigkeitsgrad" einer Führung. Es gibt Abstufungen: leicht, mittel, schwer. Also Einfachauswahl.
2. z.B. "Zielgruppe" einer Führung. Es gibt einige: Kinder, Jugendliche, Erwachsene, Familien. Also Mehrfachauswahl.

Nun meine eigentliche Frage:
Wie speichere ich diese beiden Fälle im Datenbank korrekt ab?
Füge ich einfach direkt die Auswahl in der Tabelle ein (Fall 1)? Hier möchte ich ggf. eine grafische Darstellung zu der jeweiligen mit in der DB vermerken (i.e. "schwer" = rot.jpg) für die Darstellung im Informationsblatt.
Füge ich eine Spalte für jeden Möglichkeit in der "Haupttabelle" ein und arbeite mit "true/false" (Fall 2)
Oder erstelle ich mehrere Tabellen die per "Inner Join" verknüpft sind? Und in dem Fall noch mehr Tabellen die die Zusammenhänge darstellen?

Ich habe schon so viel über "serialize", "implode", "Normalisierung", und vieles mehr gefunden (und versucht zu kapieren). Und in verschiedene Foren die Empfehlungen gelesen. Zum Teil innerhalb eines Threads widersprüchlich.

Wenn also meine Fragestellung sich hier etwas verwirrt anhört, so stellt es genau mein derzeitiges Gemüt dar. *lach*

 

[Duddle]

Ein sehr guter Anfangspunkt ist für mich immer das Entity-Relationship-Modell. Mit diesem kann, mit etwas Übung, für die meisten Fälle mühelos die Problemdomäne modelliert und in einen Datenbankentwurf überführt werden.

In deinem Fall würde ich deine Domäne anfangs so beschreiben: eine Führung hat einen Schwierigkeitsgrad. Ein Schwierigkeitsgrad ist mehreren (das heißt keiner, einer oder mehr) Führungen zugewiesen. Das entspricht einer 1:n-Kardinalität. Überführt ergibt das zwei Tabellen:

Führung(id, bezeichnung, grad_id)
Grad(id, bezeichnung)

Dieses Mini-Beispiel (welches noch nicht alles wiederspiegelt) ist normalisiert. Das passiert (so weit ich weiß) immer automatisch, wenn das ERM korrekt formuliert ist.

Edit:

Oder erstelle ich mehrere Tabellen die per "Inner Join" verknüpft sind? Und in dem Fall noch mehr Tabellen die die Zusammenhänge darstellen?

Ja, alle üblichen Ansätze laufen auf mehrere Tabellen heraus, die dann bei der Abfrage verknüpft werden. Das ist der Punkt einer relationalen Datenbank.


Duddle

 

[dieterD200]

Ein sehr guter Anfangspunkt ist für mich immer das Entity-Relationship-Modell. Mit diesem kann, mit etwas Übung, für die meisten Fälle mühelos die Problemdomäne modelliert und in einen Datenbankentwurf überführt werden.

In deinem Fall würde ich deine Domäne anfangs so beschreiben: eine Führung hat einen Schwierigkeitsgrad. Ein Schwierigkeitsgrad ist mehreren (das heißt keiner, einer oder mehr) Führungen zugewiesen. Das entspricht einer 1:n-Kardinalität. Überführt ergibt das zwei Tabellen:

Führung(id, bezeichnung, grad_id)
Grad(id, bezeichnung)

Dieses Mini-Beispiel (welches noch nicht alles wiederspiegelt) ist normalisiert. Das passiert (so weit ich weiß) immer automatisch, wenn das ERM korrekt formuliert ist.

Edit:

Ja, alle üblichen Ansätze laufen auf mehrere Tabellen heraus, die dann bei der Abfrage verknüpft werden. Das ist der Punkt einer relationalen Datenbank.


Duddle

Hallo,
oder anders ausgedrückt: jede Information wird in einer DB nur einmal gespeichert.
Gruß Dieter

 

[rafoldi]

In meinen DB'S verfolge ich einen hohen Normalisierungsgrad (i.d.R. den 5'ten). Bedeutet schon einen hohen kognitiven Aufwand. Wo sind Wiederholungen etc.. Ebenfalls immer wieder Constrains nicht nur über zwei Tabellen sondern über mehrere Tabellen.
Beispiel
Auftragskopf - Auftragspositionen
- Kunde
- Artikel
- Liefer- Zahlungsbedingungen
- etc.

Da kommt schon eine Menge zusammen. weiterhin die Frage, eher bei MSSQL DB, nach nonclustered oder clustered Indexen.

Will nicht weiter in die Tiefe gehen, manches ist auch DB Spezifisch......

 

[rafoldi]

Zitat von Josie1234:
Oder erstelle ich mehrere Tabellen die per "Inner Join" verknüpft sind? Und in dem Fall noch mehr Tabellen die die Zusammenhänge darstellen?


Ja, alle üblichen Ansätze laufen auf mehrere Tabellen heraus, die dann bei der Abfrage verknüpft werden. Das ist der Punkt einer relationalen Datenbank.

Duddle

Naja es werden von den DB's noch die alten where Verknüpfungen unterstützt wie
select * from t1, t2 where t1.id = t2.id

 

[Josie1234]

Ich wollte mich noch - leider etwas verspätet - für die Unterstützung bedanken.

 

[Chickenshooter]

Hallo Josie.

Beim Lösen solcher Probleme helfen UML Tools mit diesen kannst du das große Ganze für dich darstellen, man hat schneller einen Überblick..

http://de.wikipedia.org/wiki/UML-Werkzeug#Freie_Software

oder nur mysql

http://www.heise.de/download/mysql-gui-tools.html

mfg