{"id":55001000,"date":"2015-10-01T00:00:00","date_gmt":"2020-05-22T19:11:20","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=1000"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Kundendatensaetze_zusammenfuehren","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Kundendatensaetze_zusammenfuehren\/","title":{"rendered":"Kundendatensätze zusammenführen"},"content":{"rendered":"

\"\"<\/p>\n

Wer eine Kundendatenbank pflegt, wird früher oder später Dubletten in seiner Datenbank vorfinden. Sei es, weil Kunden sich mit neuer E-Mail und neuer Adresse erneut im Onlineshop anmelden und von dort importiert werden oder weil man bei der Suche nach einem vorhandenen Konto für einen Kunden wegen eines Tippfehlers keinen Treffer landet – langfristig lassen sich doppelte Kundendatensätze nicht verhindern. Aber das ist kein Problem: In Datenbanken lässt sich zum Glück alles nachträglich ändern. Wie dies bei Kundendaten und den damit verknüpften Daten wie etwa Bestellungen funktioniert, erklärt dieser Beitrag.<\/b><\/p>\n

Das Problem nach der Erstellen eines doppelten Kundendatensatzes lautet: Wie mache ich aus den beiden Kundendatensätzen einen, und vor allem: Wie sorge ich dafür, dass die Daten, die mit dem zu löschenden Kundendatensatz verknüpft sind, mit dem verbleibenden Kundendatensatz zusammengeführt werden<\/p>\n

Es wäre ja leicht, wenn man einfach den „alten“ Kundendatensatz löschen könnte und dann Ruhe hätte. Aber in der Regel erstellt man ja einen Kundendatensatz erst, wenn für diesen auch eine Bestellung vorliegt. Wenn wir ein Datenmodell wie in Bild 1 zugrunde legen, bei dem ein Bestelldatensatz auf der einen Seite mit dem bestellenden Kunden, auf der anderen Seite mit der Tabelle Bestelldetails verknüpft wird, ist klar: Wir können nicht einfach den alten Datensatz löschen, sondern müssen auch alle Daten der Tabelle tblBestelldetails <\/b>auf den Kundendatensatz übertragen, der beibehalten werden soll. Das bedeutet eigentlich nur, dass der Wert des Fremdschlüsselfeldes KundeID<\/b> mit dem entsprechenden Primärschlüsselwert des neuen Kundendatensatzes gefüllt werden muss. Das allein lässt sich mit einer einfachen UPDATE<\/b>-Abfrage erledigen. Danach noch den nicht mehr benötigten Kundendatensatz löschen oder als inaktiv markieren, schon ist man fertig.<\/p>\n

\"Tabellen<\/p>\n

Bild 1: Tabellen der Beispieldatenbank<\/span><\/b><\/p>\n

Um solche änderungen nachher wieder rückgängig machen oder zumindest nachvollziehen zu können, sollten Sie die geänderten oder gelöschten Daten archivieren. Wenn Sie Access ab Version 2010 verwenden, können Sie dies etwa gemäß dem Beitrag Geänderte Daten archivieren <\/b>(www.access-im-unternehmen.de\/925<\/b>) erledigen. Beim SQL Server würden Sie entsprechende Trigger nutzen oder in die gespeicherten Prozeduren, welche die Daten ändern, passende Anweisungen zum Sichern der Datensätze einbringen.<\/p>\n

Benutzeroberfläche<\/h2>\n

Nun hätten wir die Theorie bereits erledigt. Wie aber sieht die Praxis aus Otto Normalverbraucher kann leider meist nicht mal eben eine UPDATE<\/b>-Anweisung ins Direktfenster schmeißen, sodass wir für die gewünschte Funktion eine entsprechende Benutzeroberfläche bereitstellen müssen. Nehmen wir doch ein herkömmliches Formular mit Unterformular als Basis, wie es zur Darstellung von Daten aus zwei Tabellen einer 1:n-Beziehung aussieht. Im Beispiel aus Bild 2 finden Sie die Tabelle tblKunden <\/b>im Hauptformular und die Bestellungen des aktuell angezeigten Kunden aus tblBestellungen <\/b>im Unterformular vor.<\/p>\n

\"Formular<\/p>\n

Bild 2: Formular zur Anzeige der Bestellungen eines Kunden<\/span><\/b><\/p>\n

Im Gegensatz zum Standard-Bestellformular, das eine Bestellung samt Bestellpositionen anzeigt, fallen hier die Bestelldetails unter den Tisch. Wir können diese mit einem zweiten Unterformular nachreichen, das die Bestellpositionen zu der jeweils im ersten Unterformular ausgewählten Bestellung anzeigt. Dies ist allerdings unnötig, denn wir wollen ja nur die Bestellungen des nicht mehr benötigten Duplikats eines Kunden auf einen anderen Kunden übertragen. Die Bestellpositionen sind ja ohnehin mit der Tabelle tblBestellungen <\/b>verknüpft und werden quasi „mit übertragen“.<\/p>\n

Gibt es nun eine sinnvolle Variante, um diesen Datensatz mit einer Dublette zusammenzuführen Nun, eigentlich nicht – denn diese müssten wir ja auf jeden Fall erst einmal ausfindig machen. Gelegentlich wird sich vielleicht ein Kunde melden, der vielleicht Kundennewsletter an die beiden unterschiedlichen E-Mail-Adressen seiner beiden Accounts erhält und somit das Vorhandensein eines Duplikats aufdecken. In der Regel sollten Sie sich allerdings, je nach der Anzahl der zu verwaltenden Kunden, von Zeit zu Zeit selbst auf die Suche nach Duplikaten machen.<\/p>\n

Aufmerksame und langjährige Access im Unternehmen<\/b>-Leser werden jetzt aufhorchen: War da nicht mal was Ja, genau: Im Beitrag Duplikatsuche in Access <\/b>(www.access-im-unternehmen.de\/744<\/b>) haben wir ein Formular vorgestellt, mit dem Sie flexibel Duplikate in Ihren Datenbeständen finden können. Die Lösung aus diesem Beitrag werden wir für unsere Zwecke nutzen und entsprechend aufbohren.<\/p>\n

Integration der Lösung in eigene Datenbanken<\/h2>\n

Wenn Sie die Lösung in einer eigenen Datenbank nutzen möchten, müssen Sie zunächst die folgenden Objekte aus der Beispieldatenbank in Ihre Datenbank importieren:<\/p>\n