Normalisierung vs OOP?

RudolfG

Erfahrenes Mitglied
Hi Leute,

mich beschäftigt seit einiger Zeit eine Frage und zwar was alles zur Normalisierung gehört (ist wohl ein blöder nebeneffekt wenn man OOP programmiert^^)?

Also um mal konkrete Beispiele zu nennen.

Ich habe folgende Tabellen:

Fächer:
Id
Name
Beschreibung

Kategorie:
Id
Name
Beschreibung

Benutzerrollen:
Id
Name
Beschreibung

Aus der Sicht eines OOP-Programmierers erstellt man ein Objekt mit den gemeinsamen Eigenschaften und spezialisiert die Klassen falls erforderlich in den abgeleiteten Klassen. Wie sieht es jetzt mit dem Normalisieren in einer Relationalen Datenbank aus?

Irgendwie weiß ich jetzt nicht genau ob das so getrennt bleiben soll (also im Sinne eines guten DB-Designs) oder ich diese wie bei der OOP in eine Tabelle packen soll und über eine andere Tabelle dann jeder Zeile sagen soll um was es sich jetzt handelt.

So ungefähr:

DAten:
Id
Name
Beschreibung
Id_Typ

Typ:
Id
Name // Beinhaltet: 1|Fächer, 2|Kategorie, 3|Benutzerrollen etc.

Irgendwie bin ich immer hin und her gerissen und ich glaube ich vermische hier das OOP aus der Programmierung mit dem DB-Design und weiß nicht so recht was man eigentlich so machen sollte.

Freue mich über jede Antwort :D

Gruß
RudolfG
 
Meiner Meinung nach (und ich bin momentan davon überzeugt, dass das generell so gehandhabt wird) sollte man die relationale Datenbank ganz normal normalisiert aufbauen. Wie du das objektorientiert abbildest, ist dann aber nahezu beliebig. Wichtig ist, dass das Mapping zwischen deinem Datenmodell innerhalb deines Programms zu deiner Datenbank stimmt.

Bei Java/Hibernate ist es gewöhnlich, dass jede Klasse ihre eigene Spalte id hat. Man kann es aber natürlich auch anders machen - dann muss die Verbindung zwischen Klasse und Tabelle allerdings anders definiert werden. Ich würde die 1:1 Abbildung bevorzugen, aber ich denke, dass es letztlich Geschmackssache ist.
 
Meiner Meinung nach (und ich bin momentan davon überzeugt, dass das generell so gehandhabt wird) sollte man die relationale Datenbank ganz normal normalisiert aufbauen. Wie du das objektorientiert abbildest, ist dann aber nahezu beliebig. Wichtig ist, dass das Mapping zwischen deinem Datenmodell innerhalb deines Programms zu deiner Datenbank stimmt.

Bei Java/Hibernate ist es gewöhnlich, dass jede Klasse ihre eigene Spalte id hat. Man kann es aber natürlich auch anders machen - dann muss die Verbindung zwischen Klasse und Tabelle allerdings anders definiert werden. Ich würde die 1:1 Abbildung bevorzugen, aber ich denke, dass es letztlich Geschmackssache ist.

Hey Danke für die Antwort :D

Was genau heißt den das "ganz normal" normalisieren? Würdet Ihre die Tabellen auch so erstellen wie ich sie erstellt habe (der obere Teil des vorherigen Posts)?

Gruß
RudolfG
 
Deine drei Tabellen können so bleiben, da gibt es nichts mehr sinnvoll zu Normalisieren.
Ich verstehe nicht ganz, was du mit folgendem Satz meinst:

Aus der Sicht eines OOP-Programmierers erstellt man ein Objekt mit den gemeinsamen Eigenschaften und spezialisiert die Klassen falls erforderlich in den abgeleiteten Klassen.

Wieso solltest du alle Eigenschaften in ein Objekt stecken? Wenn du drei Klassen (Fach, Kategorie und Benutzerrolle) hast mit den entsprechenden Eigenschaften aus der Datenbank, ist doch alles in Butter. Und für Beziehung hast du dann entsprechen eine Referenz (1:N) oder eine Liste/ ein Array von Referenzen (N:M) auf die anderen Objekte. Das passt doch genau zu einer Normalisierten Datenbank.
 
Wenn du deinen OOP-Gedanken pflegen möchtest, ist eine rationale Datenbank sicher nicht das Richtige, aber es gibt ja auch noch andere Datenbanktypen siehe dir doch mal couchDB an.
 
Hi Steusi,

Wenn du deinen OOP-Gedanken pflegen möchtest, ist eine rationale Datenbank sicher nicht das Richtige...

Also heißt es, dass die OOP-Gedanken bei der relationalen Datenbank nichts zu suchen haben, richtig? und man hier die Tabellen nach realen "Objekten" trennt und nicht nach "Basisgruppierungen", oder?

Gruß
RudolfG
 
Zurück