Generalisierung

[siffkroete]

Hi Leute
Gehört Generalisierung zum klassischen Relationalen Datenmodell? Also ich habe z.B. Transaktion und Transaktionsteilnehmer. Person und Firma sind in einer "ist ein" Transaktionsteilnehmer Beziehung. Mein Lehrmeister (er hat 3 Master in Informatik so sagt er zumindest) behauptet das gehört nur in eine Hierachische Datenbank oder eine Objektorientierte. Ich behaupte, dass das auch eine klassische Relationale Datenbank drauf haben muss. Wer hat recht? Kann man diese Art von Beziehung in Microsoft Access abbilden?

 

[ukulele]

Gehört Generalisierung zum klassischen Relationalen Datenmodell?

Nach Wikipedia würde ich sagen nein, nicht zum klassischen.

Ich behaupte, dass das auch eine klassische Relationale Datenbank drauf haben muss.

Natürlich kann SQL problemlos generalisierte Daten in einer Tabelle abbilden, es gibt aber keinen Weg diese explizit als solche auszuweisen oder zumindest kenne ich keinen. Ich wüsste auch derzeit keine Funktionen die das erforderlich machen würden. Wenn ich eine Teilmenge aus einer Tabelle abbilden will kann ich einen Typen in einer Spalte definieren, eine n:m Beziehung mit einer anderen Tabelle mit Gruppen herstellen oder eine Sicht bauen die mir genau die gewünschte Teilmenge zurück liefert.

das gehört nur in eine Hierachische Datenbank oder eine Objektorientierte

Kann man sicherlich machen, muss man meiner Meinung nach nicht. Generallisierung scheint mir sehr allgemein und eigentlich in allen Datenstrukturen irgendwie vor zu kommen. Die bessere Datenhaltung bestimmt sich aber sicherlich nicht allein dadurch.

Ist allerdings nur meine Meinung. Ich nutze nur realationale Datenbanken und zur Generealsierung habe ich jetzt Wikipedia gelesen...

 

[siffkroete]

Vielen Dank für die Antwort. Aber wie kann ich den die Entitäten Transaktionsteilnehmer, Person (ist ein Trans. Teiln.) und Firma (auch Trans. Teil.) in einem erm abbilden? Kann ich das so machen, dass Transaktionsteilnehmer zwei Attribute hat nämlich Firmen_Nr und Personen_Nr und eine ist dann immer ein NULL-Wert d.h. Ein Trans. Teiln. ist entweder Person oder Firma, geht das? Oder ist das schlechter Stil? Und bei der Entität Transaktion mache ich einfach ein Attribut für Trans. Teiln. Debior und ein Attribut Trans. Teil. Kreditor?

 

[ukulele]

Also das würde so gegen Normalformen verstoßen und wäre auch schlechter Stil. Das heißt natürlich nicht das es in der Praxis nicht vor kommt. Häufig, weil es die Entwickler nicht besser wussten, zu faul waren oder die Datenbank später erweitert aber nicht verändert wurde. Manchmal aber ist es halt das kleinere Übel.

Wenn ich deinen Fall jetzt seperat beleuchte gäbe es für mich erstmal nur einen konsequenten Weg:
Eine Entität "Transaktionsteilnehmer" mit einer n:m Beziehung "Transaktionen" mit sich selbst. Die "Transaktionsteilnehmer" Tabelle hat ein Atribut "Typ" das zwischen Unternehmen / Organisation und natürlicher Person unterscheidet.

Natürlich kann man jetzt sagen Unternehmen und Personen sind nicht das Selbe und haben zu wenig übereinstimmende Atribute als das eine Datenhaltung in einer Tabelle in Frage kommt. Aber genauso gut könnte ich über Gesellschaften philosophieren, die keine Firma haben und daher in einer Tabelle "Firma" deplatziert wären. Es kommt immer darauf an was man drum herum noch abbilden muss.

 

[siffkroete]

Hi
Danke für die Antwort. Du meinst Transaktionsteilnehmer n:m mit Transaktionen? Und Transaktionsteilnehmer mit sich selbst? Dann müsste man bei Transaktionsteilnehmer ein Feld machen wo draufsteht ob es Firma oder Person ist? Und noch ein Feld wo draufsteht ob Kreditor oder Debitor?

 

[ukulele]

Transaktionsteilnehmer n <--Transaktionen --> m Transaktionsteilnehmer

Um Firma und Person zu unterscheiden wäre ein Flag eine Möglichkeit. Wenn keine weiteren Atribute davon abhängig sind ist das okay denke ich. Kreditor und Debitor kann beides gleichzeitig zutreffen, das solltest du bedenken. Grundsätzlich geht das aber genauso.

 

[siffkroete]

Hi
Merci für die Mühe.
D.h. aber, dass in Transaktion ein Feld Kreditor auf Transakt.Teiln. verweist und ein Feld Debitor auch auf TransT. verweist, oder? Ich dachte mir noch, dass Transaktion eine Reflexive Beziehung eingehen könnte mit sich selbst, würde das gehen? Es sind ja immer 2 an einer Transaktion beteiligt, das könnte man mit einer Reflexiven Beziehung lösen oder, sozusagen Kreditor auf Debitor n-m? Ist das guter stil? Dann müsste man das andere oben natürlich anders machen.
Ich bin erst seit ca. 1 Monat an den Datenbanken, dachte nicht, dass das so kompliziert ist.

 

[ukulele]

Du gehst das recht theoretisch an. Ich habe mich zwar mit der Theorie befasst, ist aber schon was her.

Was genau meinst du mit ein Feld "verweist" auf Transaktionsteilnehmer? Wenn du meinst ein Fremdschlüssel aus "Transaktionen" zeigt auf Tabelle "Transaktionsteilnehmer" dann ja, man könnte sagen der FKn zeigt immer auf den Empfänger des Geldes und der FKm immer auf den Absender. Das würde dir soetwas wie ein Soll/Haben Kennzeichen sparen und (aus deiner Sicht) bestimmen, wer Debitor und wer Kreditor dieser einen Transaktion ist.

Ich dachte zunächst an etwas Anderes: Wenn du das aus buchhaltärischer Sicht eines Teilnehmers abbildest, hat dieser Debitoren und Kreditoren. Um z.B. Transaktionsempfänger nach Debitoren / Kreditoren zu durchsuchen möchtest du in so einem Fall vermutlich deinen Teilnehmern eine entsprechende Einordnung zuweisen. In diesem Fall wäre allerdings auch aus Sicht dieses einen Teilnehmers einer der beiden FKs immer gleich. Das zeigt wie unterschiedlich die Anforderung an ein Datenmodell sein kann, je nach dem was du abbilden möchtest.

 

[siffkroete]

Hi
Ja genau das meinte ich was du im ersten Abschnitt gesagt hast. Dort wäre nur noch das Problem mit der Firma und Person, die ja Spezialisierungen von Trans.Teil. sind und ich nicht weiss ob das von M.Access oder MySql worbench unterstützt wird, ob die Integrität automatisch bei der Generalisierung überprüft wird.
Den 2 Abschnitt deiner letzten Antwort habe ich nicht ganz verstanden, du meinst bei den Trans.Teil. einen Fremdschlüssel bzw. 2 Fremdschlüssel die auf Debitor oder Kreditor verweisen? In meiner Datenbank dachte ich ohne Entitätstypen Debitor und Kreditor auszukommen. Sonst habe ich: Debitor ist ein Trans.Teil. ist eine Firma oder eine Person, das gleiche bei Kreditor, das wäre sehr kompliziert. Nach wie vor weiss ich nicht: Gibt es einen schönene, 3 Normalform gerechten Weg der Generalisierung anders darstellt, soll man den Generalisierung vermeiden?

 

[ukulele]

Dort wäre nur noch das Problem mit der Firma und Person, die ja Spezialisierungen von Trans.Teil. sind und ich nicht weiss ob das von M.Access oder MySql worbench unterstützt wird, ob die Integrität automatisch bei der Generalisierung überprüft wird.

Ich denke Generalisierung ist nicht verkehrt und du kannst weitere Atribute zu Unternehmen oder Personen auch in weiteren Tabellen abbilden. Die Integrität sicherzustellen ginge hier möglicherweise über CHECK Constraints oder über Trigger. Access und MySQL sind aber beide keine gute Wahl wenn die Datenbank derlei Aufgaben übernehmen soll. Access nicht weil es nur einen geringen Umfang an Funktionen hat (ich glaube weder CHECK Constraints noch Trigger sind hier möglich) und MySQL weil es sich einfach einen Dreck um viele CHECK Constraints scheert und vieles nicht kann. Oracle, MSSQL oder Postgres sind hier anspruchsvoller.

In meiner Datenbank dachte ich ohne Entitätstypen Debitor und Kreditor auszukommen.

Müsste eigentlich gehen ich wollte wirklich nur auf eine andere Darstellung aus Buchhalter Sicht hinaus. Dort sind Debitoren eben meine Kunden und Kreditoren meine Lieferanten, natürlich bekomme ich auch mal Geld von einem Kreditor und umgekehrt. Wenn das für dein Datenmodell nicht wichtig ist, bilde es nicht ab.

Gibt es einen schönene, 3 Normalform gerechten Weg der Generalisierung anders darstellt, soll man den Generalisierung vermeiden?

Ich denke mal nein und nein. In der Theorie stecke ich nicht so drin aber in der Praxis sehe ich keine Nachteile. Vieleicht bei Performancefragen in richtig großen Umgebungen aber für mich zählt ein gut strukturierte Datenhaltung mehr als nur Performance.