Frage zu einem Datenbankdesign

[pillepalle]

Hallo,

ich habe mal eine Frage zu einem Datenbankdesign. Es handelt sich um eine Datenbank für Autos.
Jedes Auto soll sowohl gemeinsame Felder (ID, NAME, DETAILS,... werden ca. 20 Felder), als auch unterschiedliche Felder haben. Die Autos sollen in verschiedene Gruppen aufgeteilt werden(CABRIOLET, TRANSPORTER, COUPE, GELÄNDEWAGEN,... werden ca. 8 Gruppen).
Nun ist ja klar das das Feld "DACHTRÄGER" nicht in der Tabelle CABRIOT zu finden sein soll. Aber z.b. Farbe sollte jeder Fahrzeugtyp als Feld haben.

Nun meine Frage, in welcher Form soll ich die Tabellen in der Datenbank anlegen? Auf Anhieb fallen mir 3 Möglichkeiten ein.

1. Alle Felder werden in eine Tabelle geschrieben und es werden einfach Felder beim füllen freigelassen. Die Autogruppen sollen über eine Extratabelle identifiziert werden.
Vorteil wäre dabei der geringe Arbeitsaufwandt für mich und die einfach gestaltbareren Abfragen. Allerdings hat dieses Modell wohl nichts mehr mit einer relationalen Datenbank zu tun.

2.Jede "Autogruppe" bekommt eine eigene Tabelle, in die auch die gemeinsamen Felder, sowie Name, beschreibung usw. geschrieben werden. Das bringt natürlich mit sich, das viel komplexere Abfragen stattfinden müßten,z.B. bei einer Volltextsuche im Frontend, oder im Administrationsbereich. Außerdem scheint mir der Lösungsansatz auch relativ redundant.

3.Es gibt eine Tabelle die die gemeinsamen Daten beinhaltet und dann zu jeder Autogruppe eine zusätzliche Tabelle, die die individuellen Daten beinhaltet. Auch hier sollen die Autogruppen über eine Extratabelle identifiziert werden. Dabei wäre aber z.B. Dachträger auch in mehreren Tabellen, bloß in einer nicht (Cabriot). Also scheint das Modell auch redundant zu sein.
Zwar könnte ich eine zusätzliche Tabelle anlegen, die die Attribute die quasi nur boolean werte liefern, speichert, aber es gibt auch Felder die nicht jede Gruppe haben soll und die gefüllt werden muß, z.B. mit einem Preis(double).

Mir ist klar das meine Überlegungen vielleicht nicht alle nachvollziehbar sind, über Denkanstöße oder weitere Lösungsansätze wäre ich aber dankbar.

mfg

pillepalle

[xManUx]

hi !

das lässt sich so nicht sagen.. du solltest dir erstmal im klaren sein, welch möglichkeiten es gibt ( brainstorming ) am besten auf blatt papier !
du musst auch bedenken, dass du die tabellen wohl oder übel auch verknüpfen musst z.b. mit INNER JOIN oder LEFT JOIN what ever..

am besten du machst erstmal ganz grob strichwortartig was alles berücksicht werden soll..

farbe, marke, grundrisse ( dach / ohne dach ) , 3 türer, 5, türer, geländewagen / nicht gelände wagen lauter so zeugs..

wenn du das dann mal alles hast, kannste anfangen zu gruppieren

wenn du dann mal ne einigermaßen saubere gruppierung hast kannst dir mal gedanken zu tabellen machen, falls du das noch nicht hast...

war nur mal ein kleiner denkanstoß ! denn die planung ist wichtig am anfang bei größeren projekten bzw. komplizierten, sonst gerät evtl. nacher alles aus dem ruter...


grüße,
manu

[DanielD]

ich würd auch die spezialfelder (z.B. dachträger ) mit in die normale tabelle packen und dann in der typentabelle (wo cabrio, etc. drinstehen) nochmal diese felder aber als int(1) und wenn dann dachträger für jeeps verfügbar ist in zeile für jeeps feld dachträger auf 1 setzen und das ganze mit ner schönen abfrage rauslesen ....

mfG

[pillepalle]

Hi, also meinst du quasi ich soll meinen ersten Lösungsansatz umsetzen und zusätzlich angeben welches Feld für welchen Wagentyp zur Verfügung steht? Dann halt mit nem netten Join die Abfrage gestalten?

Oder habe ich da was falsch verstanden?

mfg

pillepalle

[pillepalle]

Zu der ersten Antwort:

Habe die Informationen alle gesammelt, ahtte bloß eben nich die Lust die Felder alle zu Zählen , deshalb die grobe Anzahl der Felder.
Gruppiert ist auch schon alles, aber es gibt halt Felder die alle gemeinsam haben und felder die nur für manche Typen gelten. Bin dabei nun die Felder in Tabellen zu packen und bin halt dabei auf die Frage gestoßen wie ich das am besten mache.

mfg

pillepalle

[oskar40]

der 1. ansatz sollte die vielseitigsten und gleichzeitig einfachsten abfragen ermöglichen, meine ich

[pillepalle]

Hallo,

ja so sehe ich das auch, aber hat es noch viel mit einer relationalen Datenbank zu tun? Einfach irgendwelche felder freilassen? Hört sich für mich nicht so professionell an.

mfg

pillepalle

[Payne_of_Death]

keineswegs mehr relationel.......

als Denkanstoss:
1.) ne Table mit allen Automarken
2.) ne Typen Tabelle mit den Autotypen
3.) ne Merkmale Table mit allen Merkmalen die es gibt

4.) Verknüpfungstable zwischen Autotypen und Merkmale
5.) Verknüpfungstable zwischen Aotmarke und Autotyp

Hat den Vorteil du kannst bequem Typen, Automarken und Merkmale ergänzen ohne das du die Tabellen umgestalten musst

Bsp:
Table Automarke:
1 | VW
2 | Mercedes

Table Autotypen:
1 | CLK
2 | SLK
3 | Polo 6N
4 | GOLF 2er

Merkmale:
1 | viertürig
2 | zweitürig
3 | Sportfahrwerk
4 | Schiebedach
5 | Klimaanlage

Marke_Typ:
1 | 3
1 | 4
2 | 1
2 | 2

Typ_Merkmal:
1 | 3
1 | 4
2 | 4
3 | 2
3 | 5
4 | 5
4 | 1

Jetzt hast du zwar kompliziertere Abfragen, jedoch ist das ganze dynamisch erweiterbar.
Du kannst Abfragen wenn kein Merkmal im Verhältnis zur Typ_Merkmal vorhanden ist kannst du nein ausgeben lassen.

evtl. kannst du noch erweitern nach Prüfungen wie z.B.
a.) Ein Auto was das Merkmal viertürig hat kann nicht gleichzeitig zweitürig sein etc.
Das mit Tables lösen oder mit Prüfungen.


Du hast jetzt die Wahl zwischen einfache Abfragen und hoher Pflegeaufwand mit statischer DB
Oder kompliziertere Abfragen und bequeme Erweiterbarkeit......
Die Wahl kann ich dir nicht annehmen.......

[pillepalle]

Hallo,

das sind aber nur die Tabellen mit den feststehenden eigenschaften. Du meinst zusätzlich zu der Tabelle:

auto_id,
auto_name,
auto_typ,
auto_marke(int),
...

Das Problem ist das viele Felder die nicht gemeinsam sind keine feststehenden Begriffe sind, wie z.B. Automarke. Es müssen also Zahlen und Buchstaben eingetragen werden können über einen Administrationsbereich.

Mir ist klar das ich feststehende Begriffe über einen Schlüssel zu einer anderen Tabelle festlege z.B. bekommt ein auto seine Marke durch den schlüssel auto_marke(int) über eine zusätzliche Tabelle zugewiesen.

Aber was ist mit z.B. dem Feld auto_dachtraegerkosten, das soll ein double wert sein, den man selber eintragen kann. Darum geht es mir. Soll ich den in der Tabelle aufführen in der auch der auto_name, auto_marke(int) usw. steht, oder soll ich es wie ich es anfangs wie in meiner 3. Möglichkeit beschrieben habe in eine zu dem Autotyp extra angelegen Tabelle speichern? Denn die Kosten kämen nur auf einen Wagen zu der kein Cabriot ist und müßten also bei einem Datensatz eines Geländewagens leer gelassen werden. Von diesen Datensätzen gibt es ca. 15 Stück und wenn ich halt die Tabelle mit den unterschiedlichen eigenschaften auslager habe ich mir gedacht habe ich wenigstens keine leeren Datensätze, bzw nicht so viele.

mfg

pillepalle

[Payne_of_Death]

Du meinst für jeden Autotyp eine eigene Tabelle
Ne das ist schon nicht mehr sinnvoll

Wenn da noch einen Haufen Attribute mit dem Merkmal Cabrio/nichtCabrio dazukommen würde sich eine weitere Tabelle anbieten um das dynamisch halten zu können.

Wenn das aber nur bei diesem Attribut bleibt ist eine weitere Ausdehnung auf Tabellen schon nicht mehr sinnvoll....

Das Problem was es hier gibt ist der Kompromiss aus Übersichtlichkeit, Erweiterbarkeit und Statischen Tabellen.

Ich würde hier mal alle Attribute festhalten die ausgedehnt werden müssten. Sollte mehr als ein Attribut ausgedehnt werden müssen, sollte eine Verknüpfungstabelle und je eine Tabelle für das spezielle Merkmal erstellt werden.

Ansonsten versteht kein Mensch mehr was wozu gehört.
Nachteil ist aber das deine SQL Statements relativ umfangreich ausarten können.......

[pillepalle]

Hallo,

is wahrscheinlich schwer mein Problem zu verstehen. Wie gesagt das mit dem Tabellen verknüpfen ist mir schon klar.
Vielleicht erläutere ich das Problem mal anhand einer Tabelle.

id(int),
name(varchar),
typen(int),<(verknüpft mit tabelle typen)
farbe(int),<(verknüpft mit tabelle farben)
...
...
Dachträger(double)

Dachträgerpreis wird natürlich nur für Autos eingetragen die keine cabriotlets sind. Soll ich also dieses Feld einfach leer lassen, wenn ich einen Geländewagen in diese Tabelle eintrage?
Meine Bedenken sind das ich vielleicht irgendeinen fehler bei der Normalisierung gemacht habe und somit habe ich mir gedacht das ich zusätzlich zu der Tabelle mit dem Primärschlüssel z.b. das Feld Dachträgerpreis in die gesonderten Tabellen (gelaendewagen, coupe, usw) eintrage nur halt nicht in die Tabelle cabriot. Es gibt so ca 15-20 Felder die nicht alle autotypen haben und die ich dann auf diese Weise in die einzelnen Tabellen schreiben wollte um leere Datenfelder zu vermeiden.
Ist das Sinnvoll ,oder nicht war mein Anliegen.

mfg

pillepalle

[oskar40]

stimmt schon, die entscheidung kann dir keiner abnehmen. aber mal ein paar beispiele, die die theoretischen möglichkeiten (relational) einschränken:

- tabelle mit farben: jeder hersteller nennt sein ROT in jedem jahr anders, da ist mit einer extra farbtabelle nicht viel sinnvolles zu verknüpfen -> mein ansatz wäre: evtl. numerisches feld für 1=rot 2=grün 3=blau ..., vielleicht zusätzliches textfeld für "indianabeigemetallic"

- karosserieformen: soviel gibts doch nicht: limousine cabrio roadster und noch ein paar, das läßt sich mit einer einstelligen (oder zweistelligen) klassifizierung machen, ein auto ist nun mal entweder/oder, aber nicht gleichzeitig. und wenn doch, dann gibts noch eine karosserieform "mix" oder so. mein ansatz: 1 feld karosserie

- türen: 2 oder 3 oder 4 oder 5 sollte genügen. mein ansatz: 1 feld tueren

- ps: bis 30, 31-50, 51-70 oder so, also klassenbildung statt einzelnennungen. mein ansatz: 1 feld leistungsklasse

das mit den klassifizierungen sollte relativ leicht per dropdownfeld im erfassungsformular zu kontrollieren sein.

(bei einer adresstabelle mache ich ja auch keine extra tabelle für die hausnummern, obwohl es die hausnummer '13' sicher mehrmals in D gibt). ich bin bestimmt nicht gegen sinnvolle relationen, aber nicht nur um der relationen willen.

[pillepalle]

Ja, ok verstehe was du meinst.
Also mir ist klar das ich nicht für jedes Feld ein dropdownmenu brauche, mir ist bloß wichtig zu wissen, ob es "verwerflich" ist in der Tabelle mit den Autos ein Feld "Dachträger" zu haben und dann auch in diese Tabelle ein cabrio einzutragen, obwohl offensichtlich ist das dieses Feld leer bleiben wird.
Will sauber programmieren. Und es ist ja nicht nur der "Dachträger", es sind ja ca 15-20 Felder die von Autotyp zu Autotyp mal gefüllt werden und mal nicht gefüllt werden.
Also wie ich das so lese scheint das keine Probleme zu geben, bzw. ist besser eine Tabelle zu haben als extra zusätzliche anzulegen für jeden Autotyp.
Mit zusätzlichen meine ich die mit den Werten die nicht jedes Auto hat. (z.B. das Feld "Dachträger" in die Tabelle Gelaendewagen schreiben und in die Tabelle Coupe, aber nicht in die Tabelle cabriot)
mfg

pillepalle

[Abraxax]

in anlehung an POD's und oskar's post mal mein vorschlag dazu ....

tabelle hersteller
- id - autoinc
- name - bmw, audi, volkswagen, usw

tabelle modell
- id - autoinc
- herstellerid - s.o.
- name - a3, a8 usw.
- typ - cabrio, van, combi usw - mysql-feldtyp ENUM
- tueren - 2,3,4,5 - ENUM

tabelle extras
- id - autoinc
- name - schiebedach, klima, sitzheizung usw

tabelle modell_extras
- modellid
- extrasid
- primarykey über beide felder


nur mal als anregung

[pillepalle]

Danke für die vielen Vorschläge erstmal, aber irgendwie kam mein Problem doch noch nicht so an. Vielleicht frage ich mal anders.

Ich beziehe mich nun mal auf den Vorschlag von Abraxas.

Ich habe ein Formular im Adminbereich für Cabriots ein formular für Geländewagen usw.
Das input-Feld in den ich den Preis(double) für den Dachräger eintrage . Welche Tabelle in dem Beispiel von Abraxas soll gefüllt werden bzw in welcher Tabelle soll "Dachtraegerpreis" stehen. in der Tabelle "modell" doch, oder?


mfg

pillepalle