Dataset Design

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 7 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Dataset Design

    Hallo zusammen,ich habe gerade ein Verständnis Problem beim designen des Daten Schemas.

    Aber erst mal kurz erklärt was ich habe:
    Ich habe ein typisiertes Dataset wo die Daten lediglich in einer XML Datei gespeichert werden.

    Kunde -> Kann einen oder mehrere Ansprechpartner haben -> Die Auswahl geschieht über die Tabelle -> Gesamtliste Ansprechpartner ->diese kann einen oder mehrere Aufgabenbereiche zugeordnet werden.

    Habe zum besseren verständig mal die Bilder angehängt.

    So jetzt die Frage:Wie bekomme ich jetzt die Beziehung von Ansprechpartner zu den Aufgabengebieten dargestellt.
    Also wenn ich den Ansprechpartner vom Kunden auswähl sollen mir alle seine Aufgabengebiete angezeigt werden.

    Benötige ich dazu eine m:n Beziehung Zwischen Ansprechpartner_Kunde und Ansprechpartner_Gesamt?
    Bilder
    • DataSet.JPG

      35,85 kB, 517×251, 74 mal angesehen
    • Gesamtliste_Ansprechpartner.JPG

      44,15 kB, 1.036×365, 67 mal angesehen
    • Kunde_Ansprechpartner.JPG

      45,38 kB, 1.018×415, 59 mal angesehen
    • Auswahl des Ansprechpartners.JPG

      54,9 kB, 743×408, 81 mal angesehen
    nein, es liegen 2 m:n - relationen vor:
    1. Kunde <-> Ansprechpartner
    2. Ansprechpartner <-> Aufgabengebiet
    Bitte erfinde keine Ansprechpartner_Gesamt - Tabelle. Fasse die Tabellen nicht als Liste auf, sondern lieber als "Entität" - als Baustein deines Denkens, welches die Realität abbildest.
    Ein Ansprechpartner ist etwas - das kann man denken, und sich vorstellen.
    ein Ansprechpartner_Gesamt - was soll das sein? Kannst du dir einen Ansprechpartner_Gesamt vorstellen, wie er durch die Tür kommt, und dich anspricht? Und davon sollen dir auch noch mehrere zugeordnet werden? Was soll man denn mit 3 Ansprechpartner_Gesamts anfangen?

    lies nochmal auf codeproject.com/Articles/1030969/Relational-Datamodel und folge-Artikel nach, wie man modelliert, und auch die Benamungs-Regeln.
    Hallo Ede,


    lies nochmal auf codeproject.com/Articles/1030969/Relational-Datamodel und folge-Artikel nach, wie man modelliert, und auch die Benamungs-Regeln.


    Dafür reicht mein Englisch leider nicht aus.


    nein, es liegen 2 m:n - Relationen vor:


    Könntest du mir dabei erweiterte Hilfestellung geben?
    Oder hast du eventuell noch einen anderen Link?

    Oder meinst du so wie auf dem Bild dargestellt?
    Bilder
    • DataSet2.JPG

      46,41 kB, 344×792, 88 mal angesehen

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „darkman203“ ()

    Ja, so meinte ich das.
    Auch die Benamung viel besser. Einzig AufgabenBereiche ist plural - das verstößt gegen eine der Regeln.
    Wie gesagt: Betrachte die Tabellen als Entität - ein Aufgabenbereich ist klar, aber was soll ein Aufgabenbereiche sein? Das ist vonne Sprache her paradox, wenn ein Ding - eines! plural flexiert ist.
    Und genau mit diesem paradoxen Namen hast du dann viel zu tun - der Designer generiert davon die Klasse AufgabenBereicheRow, und das ist definitiv falsch benamt, denn so eine Row enthält nicht viele Aufgabenbereiche, sondern nur einen.

    Also Zumindest die Richtlinien sollteste versuchen, dir zu erschließen, mit Online-Übersetzer und Zeugs sollte das doch möglich sein.
    Hallo Ede,

    danke für deine Antwort.

    ​Also Zumindest die Richtlinien sollteste versuchen, dir zu erschließen, mit Online-Übersetzer und Zeugs sollte das doch möglich sein.


    Da Kämpfe ich mich gerade durch. ;)

    Ich denke vom eigentliche Prinzip habe ich es jetzt mit den n:m Beziehungen verstanden.

    Das Anzeigen von allen Aufgaben zum aktuell ausgewählten Ansprechpartner habe ich so gelöst.

    VB.NET-Quellcode

    1. Private Sub Kunde_AnsprechpartnerBindingSource_PositionChanged(sender As Object, e As EventArgs) Handles Kunde_AnsprechpartnerBindingSource.PositionChanged
    2. Dim _Zeile_Kunde_Ansprechpartner As DataSet1.Kunde_AnsprechpartnerRow = DirectCast(DirectCast(Kunde_AnsprechpartnerBindingSource.Current, DataRowView).Row, DataSet1.Kunde_AnsprechpartnerRow)
    3. Dim Filter As String = CStr(_Zeile_Kunde_Ansprechpartner.Id_Ansprechpartner)
    4. AnsprechpartnerAufgabeBindingSource.Filter = "Id_Ansprechpartner = '" & Filter & "'"
    5. End Sub


    Aber das nur am Rande.

    Ich danke für die Hilfe und sehe diesen Tread als geschlossen an.
    jo, sieht sehr gut aus! :thumbsup:
    Guck - und wenn du deine Benamung optimierst, kann dein Code noch deutlich lesbarer werden:

    VB.NET-Quellcode

    1. Imports <meinProjekt>.Dataset1
    2. '...
    3. Private Sub bsKunde_Ansprechpartner_PositionChanged(sender As Object, e As EventArgs) Handles bsKunde_Ansprechpartner.PositionChanged
    4. Dim rwAnsprechPartner = DirectCast(DirectCast(bsKunde_Ansprechpartner.Current, DataRowView).Row, Kunde_AnsprechpartnerRow)
    5. bsAnsprechpartnerAufgabe.Filter = "Id_Ansprechpartner = " & rwAnsprechPartner.Id_Ansprechpartner
    6. End Sub
    ich hab Dataset1 importiert, dann kann man den Row-Datentypen kürzer addressieren.
    Weiters lasse ich - Option Implicit - den compiler den Datentyp der Row selbst ermitteln - das verkürzt auch nochmal, und der macht da keinen Fehler :)
    Und die BindingSources benenne ich mit bs-Prefix, statt des generierten -BindingSource - Postfix-Ungetüms.
    Und ich glaub dein filter-Ausdruck war falsch - muss ohne ', jdfs. wenn du Integer-Spalten als SchlüsselSpalten verwendest (empfohlen).

    (Und ich würde keine Leerzeilen innerhalb einer Methode machen - im Editor ist sehr nützlich, Methoden als etwas zusammenhängendes zu erkennen - Leerzeilen sollten (allenfalls) Methoden voneinander absetzen.
    Je mehr von deim Code du auf einem Schirm kriegst, desto besser - dann hast du es sprichwörtlich "auffm Schirm".)

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „ErfinderDesRades“ ()

    einen Thread schließen kann nur die Moderation, und tut das nur bei gravierenden Regelverstößen.

    Aber der TE kann einen Thread als "erledigt" markieren. Sone Markierung hat keine weiteren Konsequenzen, ausser dass man gleich bescheid weiß.
    Die Markierung entfernt sich auch wieder, wenn der TE denn doch noch einen weiteren Post anhängt.