Information ausblenden
Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm

Generalisierung

Dieses Thema im Forum "Datenmodellierung, Datenbank-Design" wurde erstellt von siffkroete, 27 Januar 2016.

  1. siffkroete

    siffkroete Benutzer

    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?
     
  2. ukulele

    ukulele Datenbank-Guru

    Nach Wikipedia würde ich sagen nein, nicht zum klassischen.
    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.
    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...
     
  3. siffkroete

    siffkroete Benutzer

    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?
     
  4. ukulele

    ukulele Datenbank-Guru

    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.
     
  5. siffkroete

    siffkroete Benutzer

    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?
     
  6. ukulele

    ukulele Datenbank-Guru

    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.
     
  7. siffkroete

    siffkroete Benutzer

    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.
     
  8. ukulele

    ukulele Datenbank-Guru

    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.
     
  9. siffkroete

    siffkroete Benutzer

    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?
     
  10. ukulele

    ukulele Datenbank-Guru

    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.
    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.
    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.
     
Die Seite wird geladen...

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden