none
Masterdatenmanagement - Synchronisieren von Daten aus einer Masterdb zu den div. Kunden RRS feed

  • Frage

  • Hallo,

    ich habe eine Frage die mich seit einiger Zeit beschäftigt, ich aber hierfür noch keine richtige Erklärung habe.

    Ausgangssituation:

    Masterdatenbank "Stamm" auf einem SQL Server

    In dieser Datenbank werden alle Informationen an Stammdaten gepflegt.

    Die dadurch entstehenden Masterdaten sollen zu den div. Kunden synchronisiert werden. Die Krucks an der Sache ist aber, dass der Kunde die Möglichkeit erhalten soll, div. Felder selbst zu verändern.

    Den Datenaufbau als Beispiel könnt ihr dieser  Grafik entnehmen:

    Masterdatenbank - Tabelle Artikel:

    Artikelnummer          Bezeichnung            Breite           Stärke          Glasluft

    1243535                   Rahmen                   70                70                 3

    445e343                    Flügel                     76                70                  3

    synch zu Kunden 1

    Kundendatenbank- Tabelle Artikel:

    Artikelnummer          Bezeichnung            Breite           Stärke          Glasluft

    1243535                   Rahmen                   70                70                 4   (manuell durch Kunde geändert

    445e343                    Flügel                     76                70                  4  (manuell durch Kunde geändert

    synch zu Kunden 2

    Kundendatenbank- Tabelle Artikel:

    Artikelnummer          Bezeichnung            Breite           Stärke          Glasluft

    1243535                   Rahmen                   70                70                 5   (manuell durch Kunde geändert

    445e343                    Flügel                     76                70                  5  (manuell durch Kunde geändert

    usw.

    Die Updatefähigkeit soll aber erhalten bleiben. Wie machen das den andere?! Wer kann mir sowas mal erklären?!

    Freue mich auf eure Antworten.

    CharlyOli

    Freitag, 22. Dezember 2017 19:16

Alle Antworten

  • Moin,

    ich hatte so etwas vor Jahren mal schnell lösen müssen. Da der Umfang der Daten (waren, so wie bei Dir, Stammdaten und keine Bewegungsdaten) überschaubar war, habe ich die Tabellenstruktur einfach um den Zeitstempel der letzten Änderung für jedes durch den Mandanten veränderbare Feld erweitert (der durch die Applikation beim Mandaten gesetzt wurde). Beim Einspielen der Updates wurde halt geschaut, welcher Zeitstempel aktueller ist - der des angenommenen Wertes "ab Werk" oder der des Mandantenwertes.

    Ich will nicht behaupten, dass dies eine "Best Practice" darstellt, ganz im Gegenteil, aber man kriegt's zum Laufen.

    Eine andere Methode wäre, der Mandant ändert nicht direkt die Stammdaten-Tabelle, sondern es wird eine Änderungshistorie für jedes änderbare Feld geschrieben. Der Wert "ab Werk" wird direkt in der Tabelle geändert und bleibt immer (aus Herstellersicht) aktuell. Existiert aber die Änderungshistorie, so wird der jüngste Wert der Historie genommen. So kann man sogar die Werksvorgaben mit den aktuellen Einstellungen direkt vergleichen.

    Das sind zwei Ansätze eines Laien. Nun bin ich gespannt, wie die Profis das angehen.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    Freitag, 22. Dezember 2017 22:45
  • Da man bei solchen Szenarien auch mögliche Konflikte durch zeitgleiche Änderungen auf verschiedenen Systemen beachten muss, klingt das für mich nach einem Einsatzfall für Replikation, genauer Merge-Replikation. Hier kann man sich darin einlesen:

    https://docs.microsoft.com/en-us/sql/relational-databases/replication/merge/merge-replication

    Man mus aber auch sagen, dass das keineswegs mehr trivial ist. Sollte es also wirklich um nur wenige Daten & Clients gehen, kommt man mit einem Eigenbau ev. sogar besser. Um das zu entscheiden muss man alle möglichen Szenarien kennen und auch wissen, wohin die Reise später mal gehen kann.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform MCSE Data Platform
    MCSM Charter Member, MCITP Charter Member etc.
    www.SarpedonQualityLab.com
    (Founder)

    Samstag, 23. Dezember 2017 12:03
  • Hallo Andreas,

    vielen Dank für deine Info. Hierzu gleich noch ein paar Fragen/Hinweise:

    Es handelt sich um eine "Masterdatenbank" welche von Lieferanten gepflegt wird.

    Generell ist es dann so, dass die Kunden diese Daten bekommen. (Aktuell noch manuell!! )

    Wie müssen die Tabellen dann aufgebaut sein. Erkennt die Merge-Replication anhand des Feldes

    ob eine manuelle Änderung vorgenommen wurde oder ob es sich um Mastereinträge handelt.

    Hast du hierzu ein kurzes Beispiel?!

    Viele Grüße und vielen Dank.

    Samstag, 23. Dezember 2017 15:02
  • Wie müssen die Tabellen dann aufgebaut sein. Erkennt die Merge-Replication anhand des Feldes

    Hallo,

    eine solche Funktionalität gibt es bei der Merge Replikation nicht. Man kann zwar festlegen, das nur bestimmt Felder repliziert werden sollen, die gehen dann aber in beide Richtungen, d.h. ändert ein Kunde manuell die Daten, werden diese Änderungen dann auch so in Deine Master Datenbank zurück übertragen.

    Wenn ihr einen .NET Entwickler zur Verfügung habt, dann solltet ihr euch mal das Microsoft Sync Framework ansehen, da kann man eigene Logiken einbauen.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Mittwoch, 27. Dezember 2017 08:24
  • ...Erkennt die Merge-Replication anhand des Feldes

    ob eine manuelle Änderung vorgenommen wurde oder ob es sich um Mastereinträge handelt.

    ...

    Wie gesagt, lies Dich in das Thema am Besten mal ein. Das ist ja alles bereits erklärt un dokumentiert worden.

    In Kürze: jede Tabelle erhält dann eine zusätzliche Spalte mit dem Datentyp uniqueidentifier um Änderungen an Zeilen zu erkennen. Zusätzlich kommn Trigger und Systemtabellen zur Anwendung. (Mehr dazu im Detail hier: How Merge Replication Tracks and Enumerates Changes)

    Von welchem Subscriber oder dem Master selber die Änderung ausging, ist demnach natürlich bekannt. Wie man damit umgeht kann man mit den sogenannten "Conflict Resolvern" konfigurieren. Zum Beispiel eben "Publisher/Master gewinnt".

    Ich weiß nicht, ob man noch guten Gewissens das Sync Framework empfehlen kann. Da hat sich Jahre Nichts getan und es ist nun in "extended Support".

    Der Nachfolger wird Azure SQL Data Sync sein.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform MCSE Data Platform
    MCSM Charter Member, MCITP Charter Member etc.
    www.SarpedonQualityLab.com
    (Founder)

    Mittwoch, 27. Dezember 2017 09:31