Nik: Spezialisierung / Generalisierung / Vererbung

Hallo,

kurz dazu was ich überhaupt darstellen will.

Fahrzeug
                     /    |   \                     /     |    \                Schiff    KFZ    ...
              /  |      / | \              /   |     /  |  \       Segelboot ...  BMW VW  Audi
                         /|\                         / | \                     Golf Polo

Zwar will ich es nicht mit Fahrzeugen machen aber so ist es denke ich mal jedem klar. Am Ende will ich dann alle Daten über verschiedene Fahrzeuge abrufen. z.b. als Ergebnis dann: Golf(VW) Auto 10.000Euro 75PS
Das mein Ergebnis von meiner Abfrage abhängt ist mir natürlich klar, aber gibt es ja nun mehrere Möglichkeiten meine Datenbank aufzubauen. Ich hatte vor eine Tabelle für jeden Super und Subtyp zu erstellen. (Angenommen jede/r Fahrzeugtyp, Marke, Model ist einzigartig) Also:

Fahrzeug
id (pk)

KFZ
marke (pk)

VW
model (pk)
ps
preis

Wäre das so sinnvoll oder sollte ich es lieber auf andere weise machen?

Schon mal danke
Gruß

  1. Hallo,

    eine hierarchische Struktur ...

    Fahrzeug
                         /    |   \                     /     |    \                Schiff    KFZ    ...
                  /  |      / | \              /   |     /  |  \       Segelboot ...  BMW VW  Audi
                             /|\                         / | \                     Golf Polo

    ... ist nicht der ideale Ausgangspunkt, um eine relationale Datenbank zu modellieren. Nimm eine hierarchische dafür ... ok, die sind vor ein paar Jahrzehnten ausgestorben.

    Zwar will ich es nicht mit Fahrzeugen machen aber so ist es denke ich mal jedem klar. Am Ende will ich dann alle Daten über verschiedene Fahrzeuge abrufen. z.b. als Ergebnis dann: Golf(VW) Auto 10.000Euro 75PS

    Fahrzeug
    id (pk)

    KFZ
    marke (pk)

    VW
    model (pk)
    ps
    preis

    Wäre das so sinnvoll

    Nein. Es ist keine gute Idee, wenn wegen eines neuen Herstellers, der auf den Markt kommt, neue Tabellen angelegt werden müssen.

    oder sollte ich es lieber auf andere weise machen?

    Ja.

    Gehe von den "Blättern" Deines Baumes aus, den tatsächlichen Fahrzeugen.
    Ein Fahrzeug ist von einem bestimmten Fahrzeugtyp, hat einen Hersteller, ist ein bestimmtes Modell, hat ein bestimmtes Baujahr (oder auch nicht), d.h. sammle alle diese Eigenschaften. Schau', welche Daten spezifisch sind (Segelfläche vs. Motorleistung o.ä.). Wenn Du die Auflistung der Eigenschaften so vollständig hast, wie Du sie benötigst, dann kannst Du mit der Tabellenmodellierung beginnen.

    Freundliche Grüße

    Vinzenz

    1. Sollten dann alle daten in eine Tabelle?

      1. Sollten dann alle daten in eine Tabelle?

        Nein - aber eher so mit einer 1:n-Beziehung

        Fahrzeug
        id | kategorie | marke | leistung
        1  | 1         | 1     | 1
        2  | 1         | 2     | 2
        3  | 2         | 2     | 3

        Kategorie
        id | wert
        1  | PKW
        2  | LKW

        Marke
        id | wert
        1  | VW
        2  | Mercedes

        Leistung
        id | wert
        1  | 100 kW
        2  | 200 kW
        3  | 500 kW

        Wenn es ein Fahrzeug von mehreren Herstellern/Marken geben kann (der Opel Astra wäre so ein Kandidat, den gibts auch als Vauxhall Astra) ist ggf. eine n:m-Beziehnung schlauer.

        Dasselbe für Motorleistungen - ein Fahrzeug kann es vermutlich mit mehreren Motorisierungen geben.

        1. Yerf!

          Ich klink mich mal ein, weil mich das thema momentan selber interessiert...

          Fahrzeug
          id | kategorie | marke | leistung
          1  | 1         | 1     | 1
          2  | 1         | 2     | 2
          3  | 2         | 2     | 3

          Wie bringt man da aber noch die (Segel-)Schiffe unter?

          Ich denke man kommt um mehrere Tabellen nicht drum rum. Eine mit den allgemeinen daten und eine mit den zusätzlichen Ausprägungen der spezialisierung. Bei einer mehrstufigen Hirarchie wirds dann aber trotzdem aufwändig...

          Oder überseh ich da noch einen Punkt?

          Gruß,

          Harlequin

          --
          RIP --- XHTML 2
          nur die Besten sterben jung
          1. Mich würde eben hauptsächlich interessieren wie ich so eine Hirarchie sinnvoll darstelle. Weil wenn alles in einer Tabelle ist und ich will nur alle Hersteller auflisten müsste eine große Tabelle durchgegangen werden, was bei vielen Einträgen wieder lange dauert. Mir ist grade auch aufgefallen, dass mein Beispiel oben nicht so war wie ich eigentlich vor hatte.

            Typ
            -------
            id  (pk)
            typ

            Hersteller
            id (pk)
            vw
            bmw
            golf

            So müsste man nicht für einen neuen Hersteller eine neue Tabelle anlegen. Und um es nochmal zu erwähnen in meiner Anwendung gäbe es jeden Hersteller nur 1mal, jedes Model nur einmal quasi auch nur mit einem Motor.

            1. Yerf!

              Ich würde eben pro Hierarchiestufe eine Tabelle bauen, die nur die dort spezifischen Spalten enthält, sowie einen Verweis auf die Tabelle eine Stufe höher. Somit kann man ausgehend von einer der Blätter-Tabellen über Joins sich alle informationen zusammenholen.

              Gruß,

              Harlequin

              --
              RIP --- XHTML 2
              nur die Besten sterben jung
              1. Hi,

                Ich würde eben pro Hierarchiestufe eine Tabelle bauen, die nur die dort spezifischen Spalten enthält, sowie einen Verweis auf die Tabelle eine Stufe höher. Somit kann man ausgehend von einer der Blätter-Tabellen über Joins sich alle informationen zusammenholen.

                Ich habe ein Problem mal ähnlich gelöst. Dies führt dazu, dass pro Hierarchieebene Felder zur Verfügung stehen, wo alle Eigenschaften entsprechend ihres (Daten-)Typs gespeichert werden können.
                Andererseits: eine wirkliche Stärke sind solche Datenstrukturen für relationale Datenbanken nicht.
                Wenn man nicht gerade eine Abfrage startet, welche nur die "unteren" Hierarchieebenen als Ergebnis haben will, schraubt man dann doch meistens an mit OUTER JOINs rum. Und dann kann man alle Eigenschaften der Kind-Tabellen auch gleich als NULLable-Spalten in die Ursprungstabelle aufnehmen (wenn nicht gerade Speicherplatz ein Problem darstellt).

                Bis die Tage,
                Matti

            2. Hersteller
              id (pk)
              vw
              bmw
              golf

              Golf ist eine Marke und kein Hersteller :p

              So müsste man nicht für einen neuen Hersteller eine neue Tabelle anlegen. Und um es nochmal zu erwähnen in meiner Anwendung gäbe es jeden Hersteller nur 1mal, jedes Model nur einmal quasi auch nur mit einem Motor.

              Wenn jeder Hersteller genau 1 Modell und genau 1 Motor hat, brauchst du dafür auch nicht drei tabellen sondern nur eine.

              1. Ich bin schon müde... :P

                Ähm nein so meinte ich das nicht. Ich meinte nur Modelle sind einzigartig, also es gibt nur 1Golf 1Polo bzw. 1xBMW
                was ja auch egal ist irgendwo ist ja immer die Grenze ich wollte das Beispiel nur nicht zu weit stricken.

                1. was ja auch egal ist irgendwo ist ja immer die Grenze ich wollte das Beispiel nur nicht zu weit stricken.

                  Dein Beispiel ist schlecht gewählt (es verwirrt mich) - denn es gibt mehrere Polos, mehrere Golfs und BMW-Modelle gibt es auch noch eine ganze Menge ;)

                  1. Yerf!

                    Dein Beispiel ist schlecht gewählt (es verwirrt mich)

                    Das ist immer das Problem, wenn man nicht mit den echten Daten arbeitet sondern Analogien verwenden will... es ist schwierig was passendes zu finden.

                    Gruß,

                    Harlequin

                    --
                    RIP --- XHTML 2
                    nur die Besten sterben jung
  2. Wäre das so sinnvoll oder sollte ich es lieber auf andere weise machen?

    Ich entwerfe ab und zu auch Tabellen bei denen ich im Anstz meistens nicht weiß was da mal hinkommen könnte.
    Darum versuche ich sie so offen wie irgendmöglich zu halten. Das hieraisch dabei kein gutes Model ist hatte ja schon jemand geschrieben.

    Ich versuche immer zu granularisieren und die kleinsten Teile in spezifische Tabellen abzulegen, in weiteren Verknüpfungstabllen werden dieses dann sinnstiftent zusammengeführt.

    ich würde wohl so anfangen:

    Eigenschaften
    id | Bezeichnung | Eigenschaft
    ------------------------------
    1  | farbe       | blau
    2  | Leistung    | 26.000 PS
    3  | Türen       | 4

    Fahrzeug
    id | Bezeichnung
    -----------------
    1  | Golf IV
    2  | Öltanker
    3  | Smart 4x4

    Verknüpfung
    id | fahrzeug | eigenschaft
    ---------------------------
       | 1        | 1
       | 1        | 20102
       | 1        | 914
       | 2        | 2
       | 1        | 543
       | 3        | 3

    Du kannst die Relationen jetzt um Deine Hirachien erweitern und diese mit Fahrzeigen oder Eigenschaften beliebig verknüpfen. Oder die HirachieEbene als Eigenschaft laufen lassen. Ganz wie Du willst.

    Das sollte dir optimalste Freiheiten geben.

    Viele Grüße,
    Rob

    1. Yerf!

      Das sollte dir optimalste Freiheiten geben.

      Allerdings verliert man auch jegliche Typisierung die sicherstellt, dass man nur Eigenschaften anlegt, die auch erlaubt sind.

      Für mein eigenes Datenmodell an dem ich momentanüberlege werd ich evtl. alles auf eine Tabelle zusammenführen und dort die Spalten für *alle* Subtypen einbauen. Das Problem ist da nämlich, dass ich Hybride hab, die mit der Hierarchie brechen... (am jetzigen Beispiel: Schwimmautos die als eigener Typ rein müssten, sowie Autos die nachträglich umgebaut wurden und nun Schiffseigenschaften haben die sogar über die der Schwimmautos hinausgehen)

      Ich denk mal, da komm ich nicht drum rum das alles in eine Tabelle zu packen...

      Gruß,

      Harlequin

      --
      RIP --- XHTML 2
      nur die Besten sterben jung