Benötige Tipps für Datenbankdesign für Objekte mit verschiedenen Ausprägungen

Computer: Software & Programmierung SQL & Datenbank - Programmierung
#1

Guten Tag,

ich habe eine Datenbank übernommen, welche in der Haupttabelle bereits 63 Spalten aufweist und mittels einer zweiten Tabelle (1:1-Beziehung, weitere 40 Spalten) um weitere Attribute erweitert wird.

Die Spalten in der Haupttabelle sind soweit berechtigt da die Entität einfach so viele Attribute zur Beschreibung benötigt. Die weiteren Attribute aus der zweiten Tabelle sind allerdings nur teilweise notwendig. Es hängt von der Ausprägung der Entität in der Haupttabelle ab welche Attribute der zweiten Tabelle benötigt werden (zwischen 1 und 5 Spalten).

Irgendwie fühlt sich das Konstrukt falsch an, weiß allerdings nicht wie man das schicker lösen könnte. Ist es sinnvoll alles in einer Tabelle zusammenzufassen? Das würde zumindest die Programmierung von Masken erheblich erleichtern.

Gruß
M

#2

Moin,

bei einem großen deutschen Autohersteller existiert ein Datenmodell mit zigtausend Entitäten. Wenn mich meine Erinnerung nicht täuscht, hat keine davon mehr als 10 Attribute.

Zum Einlesen: https://de.wikipedia.org/wiki/Entity-Relationship-Modell

Gruß
Ralf

#3

Hallo Ralf,

ich wüsste auch nicht, was man für Tipps bei einem Datenbankdesign geben soll, wo angeblich 63 Spalten „soweit berechtigt“ sind. Dein Beispiel bestärkt mich in dem Glauben, dass irgendwas an der Möchtegern-Datenbank des UP nur absolut falsch modelliert wurde.

Ich war schon versucht, bei der Idee, die zwei Tabellen in eine zu überführen, gleich anzuraten, Excel zu benutzen. :smiley: Aber ich unterrichte gerade Normalisierung, das wäre ja kontraproduktiv. :stuck_out_tongue:

Link zum ERM schön und gut, aber ich denke, da wäre erstmal Normalisierung angebracht, wenn nicht die Datenbank von Grund auf neu angelegt werden soll.

Gruß
Christa

#4

Haha lustig. Die Datenbank ist allerdings schon normalisiert und besteht aus dutzenden weiteren Tabellen.

Die meisten Spalten der Haupttabelle sind Fremdschlüssel. Hinzu kommen noch Spalten für Koordinaten, Fläche, Höhenlage sowie verschiedene Datumsfelder und Metainformationen.

#5

Bist du sicher?

Wenn ich dich daran erinnern darf …

Das war jetzt nicht wirklich ersichtlich, dass es Dutzende von weiteren Tabellen gibt.

Dann ist DABEI bei der Modellierung irgendwas schiefgegangen, denn auch das ist nicht wirklich üblich. Dann müssten es etliche 1:n-Beziehungen mit dem Entitytypen der Haupttabelle geben.

#6

Das ist soweit korrekt. Wie in meinen Anfangspost schon geschrieben, kommt mir das auch alles viel vor und es würden noch mehr werden wenn ich die 1:1-Beziehung auflöse. Die Vorstellung das die Haupttabelle dann noch größer ist, hält mich davon ab, denn 1:1-Beziehungen machen für mich auch irgendwie keinen Sinn.

Es sind schon viele Fremdschlüssel, aber ich muss das etwas relativieren. Es sind auch einige Spalten, die nur binäre Werte aufnehmen um den Zustand zu definieren.

Evtl. könnte ich die Tabellen schmaler bekommen indem ich abstrakter vorgehe und mit mehr Enumerationstabellen arbeite, welche Spaltenbezeichnung und Werte enthalten. Aber damit habe ich nicht viel Erfahrung.

#7

Hi!

Pah, ich hab hier beispielsweise eine Tabelle, die aus mehreren Quellsystem (derzeit dürften es so ca. 15 sein) befüllt wird, mit 238 Attributen - eine von 897 Tabellen und Materialized Views in diesem einen Schema/System; und da waren aber sehr viele „gescheite“ Köpfe am Werk, die hier normalisiert haben (und von manchen Applikationsentwicklern für die tw. „Übernormalisierung“ am liebsten abgewatscht werden würden).
Es geht ganz einfach nicht mit weniger Attributen bzw. anderem Datenmodell.

Massenhaft … dazu noch massenhaft Indikatoren … eigentlich gar nicht mal so außergewöhnlich, wenn ich da an meine Erfahrungen mit Datenbanksystemen denke :smirk:

Zum UP:

Dadurch wird zwar das Datenmodell schlanker, ob es aber wirklich einfacher wird, sei dahingestellt.

Siehe meinen obigen Einwand: Es fühlt sich falsch an, aber manchmal ist sowas notwendig.

Das kommt auf das Werkzeug an, womit entwickelt wird; bei manchen ist es egal, bei manchen ist eine einzige Tabelle einfacher (wobei sich Entwickler da zu helfen wissen :wink:)

Grüße,
Tomh

#8

Hallo,

klingt für mich ein wenig nach Entity-Attribute-Value (engl.). Allerdings eher für eine noch größere Anzahl an Attributen (potentiell unendlich) konstruiert.