Laden...

Benötige Hilfe bei Datenbankdesign

Erstellt von -acid- vor 17 Jahren Letzter Beitrag vor 17 Jahren 3.090 Views
-
-acid- Themenstarter:in
885 Beiträge seit 2004
vor 17 Jahren
Benötige Hilfe bei Datenbankdesign

Guten Abend,

leider stehe ich momentan etwas auf dem Schlauch und weiß nicht, wie ich das Problem lösen soll. Daher bitte ich um eure Hilfe. Folgende Problemstellung:

Ich benutze verschiede Objekte die man einer Kategorie zuordnen kann. Zb.: **Baum ** gehört zur Kategorie Natur. Die Kategorien können vom Anwender editiert werden und/oder neue erstellt werden.

Nun möchte ich gerne die Kategorien etwas verfeinern und dem Anwender die Möglichkeiten geben, weitere Unterkategorien zu erstellen. Meine DB-Table der Kategorien sieht momentan so aus:

[Kategorien]

  • KategorieId
  • ObjektId
  • Name

Jetzt könnte ich natürlich eine weitere Table für Unterkategorien erstellen, wäre damit aber auf max. zwei Ebenen beschränkt... ich hoffe ich versteht jetzt wo mein Problem liegt. Wie gehe ich richtig vor?

1.549 Beiträge seit 2004
vor 17 Jahren

wie wäre es mit einer zusätzlichen Spalte Mutter oder änlich in der die ID der Über geortneten Kategorie steht

Wir Arbeiten eigendlich nicht wir nehmen nur das geld

4.207 Beiträge seit 2003
vor 17 Jahren

Hallo,

entweder eine ParentID (so wie S.H.-Teichhof) das vorgeschlagen hat verwenden, was insbesondere dann einfach zu handhaben ist, wenn Du eine Datenbank einsetzt, die rekursive Abfragen erlaubt wie beispielswiese die DB2 oder der SQL Server 2005 ...

... oder schau Dir mal das Modell der "Nested sets" an, was ein wenig aufwändiger zu implementieren ist, dafür aber auch mit einer Datenbank ohne rekursive Abfragen performant zu verwenden ist. Für nähere Infos einfach nach dem Begriff mal bei Google suchen.

Viele Grüße,

Golo

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

-
-acid- Themenstarter:in
885 Beiträge seit 2004
vor 17 Jahren

Ahhhh jetzt sehe ich klarer. Werde versuchen das so umzusetzen. Danke.

P.S.: Nutze SQL 2005.

-
-acid- Themenstarter:in
885 Beiträge seit 2004
vor 17 Jahren

Habe eben mal den Entwurf fertig entworfen was'n Satz 🙂

Vielleicht habe ich mich falsch ausgedrückt, oder ich denke zu kompiziert. Denke aber dennoch den korrekten Weg eingeschlagen zu haben. Hier nun mein Entwurf:

[Objekte]

  • ObjektId (PK)
  • KategorieId (FK)

[Kategorien]

  • KategorieId (PK)
  • ObjektId (FK)

[Beziehungen_Objekte_Kategorien] (Namensvorschlag?)

  • KategorieId (PK)
  • ParentId
  • ChildId

Hier ein Beispiel:
Seitenschweller gehören zu der Kategorie Karossiere. Karosserie liegt unter PWK, dort liegt aber auch Antrieb. PKW wiederrum liegt unter Transportmittel.

Somit kann ein Objekt nur eine Kategorie enthalten (1:1). Eine Kategorie kann aber mehrere Unterkategorien (Childs) (1:n) haben. Bitte gebt eure Meinung ab und verbessert mich, falls nötig 🙂

L
497 Beiträge seit 2006
vor 17 Jahren

Also grundsätzlich gesprochen: Bei einer 1:n-Beziehung benötigst Du keine extra Tabelle, um diese Beziehung abzubilden. Das ist nur bei m:n nötig.
Grundsatz 2: Tabellennamen sind immer Einzahl.

Wieso hast Du in Objekt einen Fremdschlüssel auf Kategorie und in Kategorie einen Fremdschlüssel auf Objekt?
Diese Beziehungstabelle verstehe ich jetzt so, dass es in einer bestimmten Kategorie eine Zuordnung von Parent-Objekten zu Child-Objekten gibt - diese gilt dann auch nur für diese Kategorie. Kann mir nicht vorstellen, dass Du das realisieren wolltest.

Meiner Meinung würde nach Deinen Beschreibungen folgendes völlig ausreichen (haben ja auch meine Vorrednre schon so gesagt):

[Objekt]

  • ObjektId (PK)
  • KategorieId (FK)

[Kategorie]

  • KategorieId (PK)
  • ParentKat
    Hier wird kein Verweis auf Objekt benötigt. Wenn man für eine Kategorie wissen will, welche Objekte zu ihr gehören, dann holt man alle ObjecktIds aus Objekt, wo die KategorieId passt.

Bist Du aber sicher, dass ein Objekt nur zu einer Kategorie gehören kann?

Sarkusmus ist, wenn nichts mehr hilft, außer Lachen.

-
-acid- Themenstarter:in
885 Beiträge seit 2004
vor 17 Jahren

Hallo Lord Hessia,

erstmal danke für die Beratung. Immer gut dazu zu lernen 🙂

Klar aus [Kategorie] muss ObjektId raus. War mein Fehler. Ich schaue mal ob ich das so hinbekomme (was hab ich mir da gestern gedacht?).

// EDIT: Ich habe mir eben als ich den Beitrag geschrieben habe alles aufgemalt. Plötzlich frage ich mich wo mein Problem ist. Gestern hab ich ganz anders drüber gedacht. Deswegen hab ichs wieder gekürzt.

Hier mal Pseudocode wie ichs machen will:

SELECT Hauptebenen (ParentID=0) -> Transportmittel (ID1, ParendID=0) -> SELECT ... WHERE ParendID=1 -> PKW (ID=2, ParentID=1) -> SELECT ... WHERE ParendID=2 -> Karosserie (ID=3, ParendID=2) / Antrieb (ID=4, ParendID=2) -> SELECT ... WHERE ParendID=2 ....

L
497 Beiträge seit 2006
vor 17 Jahren

Ja, so hatte ich Deine Anforderung auch verstanden, nur Deine Tabellen konnte ich diesem Problem nicht so recht zuordnen.

Dein Problem ist ganz klar ein rekursives. Ebenso klar ist es, dass Rekursion in relationalen Datenbanken schlecht abzubilden ist. Entweder Du mogelst Dich da irgendwie durch indem Du einen fette Logik in Dein Programm einbaust, die aus den "flachen" Datenbankeinträgen eine Baumstruktur aufbaut oder Du setzt Dich mit den von Golo angesrochenen Techniken oder Technologien auseinander.

[EDIT]Upps. Da hat sich Dein Beitrag aber in der Zwischenzeit erheblich verändert... Na ja, vielelicht kannst Du ja trotzdem noch Informationen aus meinem oben geschriebenen ziehen, auch wenn's jetzt nicht mehr so ganz als Antwort passt.[/EDIT]

Sarkusmus ist, wenn nichts mehr hilft, außer Lachen.