Gruppieren von Entitätstypen

martin · Anmeldungsdatum: 07.04.2006 Beiträge: 1

Hallo,

habe eine vermutlich simple Frage zur Datenbankmodellierung. Angenommen, ich habe drei Entitätstypen: artikel, gruppe und kategorie. Jeder dieser Entitätstypen besitzt ein Attribut namens id. Die Artikel sollen zu einer Gruppe gehören, die wiederum zu einer Kategorie gehören.

Wie verknüpfe ich in einer relationalen Datenbank (hier: mysql) die Tabellen? Anders ausgedrückt: wo stehen die Fremdschlüssel?

Möglichkeit1: "Verkettung"
Tabelle artikel hat Fremdschlüssel gruppe_id
Tabelle gruppe hat Fremdschlüssel kategorie_id

Möglichkeit2: "Parallel"
Tabelle artikel hat Fremdschlüssel gruppe_id und kategorie_id
Tabelle gruppe hat keinen Fremdschlüssel

Möglichkeit3: Kombination
Tabelle artikel hat Fremdschlüssel gruppe_id und kategorie_id
Tabelle gruppe hat Fremdschlüssel kategorie_id

Gibt es da Vor-/Nachteile? Wie macht man es "richtig" bzw. normalerweise? Oder gibt es andere Aspekte, von denen eine Entscheidung abhängt?

Vielen Dank,
Martin

Crotaphytus · Anmeldungsdatum: 08.05.2005 Beiträge: 213

Ich würde Möglichkeit 1 wählen.

Grund ist der folgende:

Bei Möglichkeit 2 hast du ein Problem, weil du, sobald du einer Gruppe eine andere Kategorie zuordnen willst alle Artikel, die in dieser Gruppe sind, anpassen musst.

Möglichkeit 3 hat das gleiche Problem, zusätzlich kann es da noch zu Inkonsistenzen kommen. Dann wirds wirklich widerlich...

Das sag ich jetzt einfach mal so, ohne irgendwelche speziellen Datenbankvorlesungen gehört zu haben. Aber mein gesunder Menschenverstand sagt mir, dass es so am sinnvollsten ist. Und ich kann mir jetzt auch nicht vorstellen, dass die Abfrage für die Datenbank dadurch so viel komplizierter wird, dass es da merkbare Performanceeinbrüche gibt, wenn man den Query halbwegs richtig aufbaut. Sprich

SELECT * FROM artikel, gruppe, kategorie WHERE artikel.gruppe = gruppe.id AND gruppe.kategorie = kategorie.id

würde ich nicht unbedingt empfehlen... Augenzwinkern

as_string · Anmeldungsdatum: 24.02.2006 Beiträge: 80 Wohnort: Heidelberg

Hallo!

Also, erstmal bin ich mit Crotaphytus einverstanden. Zu Deiner speziellen Frage ist das wohl der beste Ansatz.
2 fällt aus, wie Crotaphytus auch schon geschrieben hat.
3 könnte aber unter bestimmten Vorraussetzungen vielleicht sinnvoll sein. Wenn Du recht häufig Artikel zu bestimmten Kategorien raussuchen mußt aber nur selten über Gruppen gehst, gleichzeitig die Daten selten änderst, und die Performance eine wesentliche Rolle spielt... Aber dann vorsichtig sein bei Änderungen der Daten, damit die Konsitstenz erhalten bleibt. Da mußt Du dann vielleicht mit Transaktionen arbeiten.

Ansonsten vielleicht noch einen anderen Denkanstoß: Man hat ja oft ganze Kategoriebäume. Bei Dir ist so was ja auch schon da, aber nur mit zwei Ebenen, die auch fest und nicht so einfach erweiterbar sind, ohne die DB-Struktur zu ändern. Ist es nicht vielleicht sinnvoll, Deine Gruppen als Unterkatergorie zu sehen und zu ermöglichen noch mehr Ebenen zu machen, wenn das mal irgendwann erforderlich ist? Man nimmt da dann oft eben eine Baumstruktur und macht alles in einer Kategorietabelle, in der man dann noch eine "parent id" einfügt.
In Deinem Bsp. könnte man die ganzen Kategorien also mit parent_id = 0 in die neue Kategorie-Tabelle schreiben und die Gruppen mit einer parent_id, die dem primären Schlüssel der übergeordneten Kategorie entspricht. So kann man relativ einfach eine neue Ebene von Kategorien machen, indem die dann parent_ids haben, die auf ids der bisherigen Gruppen verweisen, etc.
Ich habe dann meistens eine n:m-Verknüpfung zwischen den Artikeln und den Kategorieen/Unterkat./Unterunterkat. gemacht. Allerdings hatte ich das so wie so schon gebraucht, weil bei mir ein Artikel auch in mehreren (Haupt-) Kategorien sein kann. Ist das bei Dir nicht so? Wird das auch nie so sein? Der Ansatz hat sich aber noch am besten erwiesen: Also Kategorieen als Baumstruktur und eine "Zwischentabelle" zwischen Artikel und dieser Kategorieentabelle, um die m:n-Beziehung zu realisieren. Damit ist man sehr flexibel. Die Daten sind recht statisch (also das Kategorieschema ändert sich ja normalerweise nicht sehr häufig), so dass ich teilweise den gesamten Kategoriebaum sogar schon von Anfang an in den Speicher eingelesen habe und so einen sehr schnellen Zugriff realisieren konnte.

Gruß
Marco