Schnelle scharfe und unscharfe Suchen bei Oracle im Adressbestand

Transkript

1 18. Deutsche ORACLE-Anwenderkonferenz Mittwoch, 9. November h00, Stamitzsaal Schnelle scharfe und unscharfe Suchen bei Oracle im Adressbestand Martin Bertelsmeier / Martin Bernhardt OPITZ CONSULTING Gummersbach GmbH / FUZZY! Informatik AG Gummersbach / Ludwigsburg Schlüsselworte: SQL-Tuning, Dubletten, Phonetik, Oracle Text, Adresssegmentierung, function-based-index, Datenqualität, unscharfe Suche, Fehlertoleranz Einleitung Der Verein Deutscher Ingenieure (VDI) in Düsseldorf hat ca. 2 Millionen Geschäftspartner. Für die Pflege und Nutzung dieses wichtigen Beziehungsgeflechtes setzt der VDI eine neue CRM Lösung ein. Besonderen Wert legt die Lösung auf die hohe Datenqualität. Dies hat vor allem damit zu tun, dass viele der Kunden eine jahrzente lange Bindung mit dem VDI pflegen und sich auch teilweise ehrenamtlich engagieren. Daher ist es sehr wichtig, dass die Geschäftspartner in den verschiedenen Rollen immer korrekt angesprochen werden. Ein wesentlicher Aspekt dabei ist die schnelle und sehr treffsichere Suche nach Geschäftspartnern und konsequente Vermeidung von Dubletten. In dem Vortrag werden die praxiserprobten Erfolgsfaktoren für die schnelle scharfe und unscharfe Suche (inkl. Dublettenprüfung) mit Oracle 9i erläutert. IT Experience Der Kunde Abbildung 1: VDI Der Verein Deutscher Ingenieure (VDI) ist heute mit rund persönlichen Mitgliedern der größte technisch-wissenschaftliche Verein in Deutschland und international führend. Sein enormes technisches Wissen in den verschiedensten Branchen und branchenübergreifenden Bereichen sowie in der Ingenieurförderung generiert er aus dem Netzwerk seiner Mitglieder und Kooperationspartner sowie in Zusammenarbeit mit Wirtschaft und Wissenschaft. Dieses Wissen stellt er diesen Zielgruppen sowie anderen Technikinteressierten in Form von zum Beispiel Beratungsleistungen, Broschüren, Seminaren, Tagungen, VDI- Richtlinien, Messen u.v.m. wiederum zur Verfügung. Dieses duale Netzwerk (Nukleus des Wissens) einerseits mit einem enormen Wissen und andererseits einer Vielzahl interessantester, persönlicher Beziehungsgeflechte wird in Zukunft noch stärker im Vordergrund aller Aktivitäten des VDI stehen. Anwender der CRM-Lösung sind die Mitarbeiter der VDI-Gruppe, zu der neben dem VDI e. V. u. a. die folgenden Organisationen gehören: VDI GmbH, VDI Wissensforum GmbH, VDI Versicherungsdienst GmbH, VDI Technologiezentrum GmbH

2 Die Lösung Die Beziehungsgeflechte der VDI-Gruppe werden in einer zentralen Geschäftspartnerverwaltung gepflegt. Darin werden ca. 2 Millionen Geschäftspartner geführt. Aufgrund spezieller Anforderungen (z. B. sind viele Menschen in mehreren Rollen aktiv, s. u.) hat die VDI-Gruppe trotz intensiver Suche keine geeignete und im Preis/Leistungsverhältnis akzeptable Standardsoftware gefunden. OPITZ CONSULTING hat daher unter Nutzung von Standardwerkzeugen wie das Produkt FUZZY! Double der FUZZY! Informatik AG eine neue Java-Swing Lösung auf Basis der Oracle 9i Datenbank erstellt. Abbildung 2: Pflegemaske für Ansprechpartner Grundlegende Anforderungen Dem CRM-System liegen folgende Anforderungen zu Grunde: Alle Geschäftspartner (Mitglieder, Kunden, Interessenten, Lieferanten, Ehrenamtliche etc.) sollen möglichst redundanzfrei nur einmal vorhanden sein. (Fast) alle Geschäftspartner sind für/von (fast) alle/n Anwender pflegbar. Im CRM-System sollen möglichst alle relevanten Informationen zu einem Geschäftspartner zusammenlaufen. Über die Informationen in der Geschäftspartnerverwaltung sollen Zielgruppen-bestimmungen (Adresselektionen) für alle Anwender möglich sein. Ein besonderes Merkmal der Lösung ist das sog. Nasenprinzip : Menschen ("Nasen") treten häufiger in mehreren Rollen (z. B. als Privatperson und Ansprechpartner bei einer Firma) auf. Unterschiedliche Geschäftspartner (=unterschiedliche Rollen) können somit der gleiche Mensch sein. Bestimmte Eigenschaften (z. B. Merkmale, Kontakte, Kommunikationsdaten) sind der Rolle zugewiesen, können aber immer rollenübergreifend eingesehen werden (z. B. dienstliche Telefonnummer bei einer Privatperson, die auch als Ansprechpartner einer Firma bekannt ist). Bei einer Adressselektion wird jeder Mensch ("Nase") nur einmal (nach vorgewählten Präferenzen) ausgewählt. Ein weiterer sehr grundlegender Aspekt der Lösung ist der besondere Fokus auf eine hohe Datenqualität. In dieser Lösung ist es besonders wichtig, dass die Geschäftspartner immer korrekt und mit den richtigen Informationen kontaktiert werden. Hierfür sind i. W. zwei Gründe ausschlaggebend: Viele Geschäftspartner haben teilweise eine jahrzente lange Bindung mit der VDI-Gruppe. Diese Langfristbeziehung charakterisiert das Geschäft und ist in der Regel wichtiger als eine einzelne Marketingmaßnahme. Das gesamte Netzwerk (Nukleus des Wissens) ist in der Regel wichtiger als eine einzelne Marketingmaßnahme.

3 18. Deutsche ORACLE-Anwenderkonferenz Die Lösungsarchitektur Das Herzstück des Systems ist eine Oracle 9i Datenbank (Standard-Edition auf Windows 2003). Dazu kommt eine Oracle 9i FUZZY! Double Datenbank (Standard-Edition auf Windows 2003) für die unscharfe Suche (s. u.). Die Pflege der Geschäftspartnerdaten und die Ausgabe von Selektionsergebnissen erfolgt mit einer Rich-GUI Java-Swing Applikation. Die komplexeren Adresselektionen erfolgen mit dem Ad-Hoc Abfragetool BussinessObjects. Abbildung 3: Architektur Redundanter Selektionsbestand Um eine deutliche Laufzeitverbesserung der Selektionen zu erreichen werden die Grunddaten zu den Adressen und Objekten und weitere abhängige Daten in einer für die Selektion optimierten Form in speziellen flachen Datenbanktabellen redundant gehalten. Die Synchronisierung des redundanten Selektionsbestandes erfolgt asynchron (also außerhalb der Benutzersession). In dieser Struktur sind insbesondere die Namen und Adressen der Firmen so oft enthalten, wie Ansprechpartner und Abteilungen vorhanden sind. Die Verarbeitung erfolgt dann in einem Hintergrundjob. Dieser Job kann so aufgesetzt werden, dass er periodisch in Intervallen oder permanent läuft. Im Produktivsystem läuft der Job natürlich permanent, damit die Änderungen möglichst zeitnah für die Suchen und Segmentierungen zur Verfügung stehen. Dieser Job aktualisiert auch gleichzeitig den FUZZY! Double Datenbestand (s. u.). IT Experience FUZZY! Double und FUZZY! Post Zur performanten, fehlertoleranten (unscharfen) Suche sowie zur fehlertoleranten Dublettenerkennung von Geschäftspartnern wird FUZZY! Double eingesetzt. FUZZY! Post dient zu fehlertoleranten Adressvalidierung. Die Lösungen der FUZZY! Informatik AG werden bei der VDI-Gruppe auf einem dedizierten Windows-Server betrieben. Die APIs beider Produkte werden über Funktionsbibliotheken (Java und PL/SQL) in das CRM-System eingebunden. Abbildung 4: Client Server Architektur von FUZZY! Double und FUZZY! Post Die Suchstrategien Im Folgenden werden die einzelnen Suchstrategien erläutert. Er werden Erfahrungen und "lessons learned" aus dem Projekt dargestellt. Scharfe Suche: ODER und UPPER Natürlich soll in allen Suchen nicht case sensitiv gesucht werden. Hierzu wird immer auf dem Upper-Wert gesucht. Bei einer Suche nach Firmennamen besteht die fachliche Anforderung, dass immer sowohl nach dem Kurznahmen (z. B. VW statt Volkswagen AG) als auch nach dem Langnamen (z. B. Volkswagen AG statt VW) gesucht werden soll.

4 Die Bedingung "upper(sel_jper_langname)='vw' or upper(jper_kurzname)='vw'" führt aber zu einem FULL-TABLE-SCAN auf der Tabelle und somit bei den deutlich mehr als 2 Millionen Sätzen zu unzumutbar langen Laufzeiten (ca. 11 Sekunden). Bei den einzelnen Abfragen "upper(sel_jper_lang- NAME)='VW'" oder "upper(jper_kurzname)='vw'" werden die function-based-indexes auf den UPPER- Wert der Spalten verwendet und die Ergebnisse in wenigen Millisekunden geliefert. Die angestrebte automatische "CONCATENATION" im Ausführungsplan ließ sich nicht erreichen. Aufgrund der Suche auf dem redundanten Selektionsbestandes (s. Kapitel Redundanter Selektionsbestand) war es relativ einfach möglich, zusätzliche redundante Spalten mit den UPPER-Werten in der Tabelle zu ergänzen. Dies führte dann auch zum gewünschten Ergebnis, so dass die Abfrage nur wenige Millisekunden dauert. Abbildung 5: Ausführungsplan mit redundanter UPPER-Spalte Scharfe Suche: Müller in Berlin Es gibt mehr als Geschäftspartner mit dem Nachnamen Müller und mehr als Geschäftspartner mit einer Adresse in Berlin. Es gibt aber nur ca. 450 Geschäftspartner, auf die beide Bedingungen zutreffen. Für diese nicht sehr ungewöhnliche Anfrage (in der Praxis natürlich meist mit weiteren nicht sehr selektiven Bedingungen z. B. über Vornamen) wurde ein kombinierter Index aus Nachname und Ort angelegt. Da es im System aber 3 Ortsangaben (jeweils ein Ort zur Straßenadresse, Postfachadresse und Großkundenadresse) gibt, wurden auch entsprechend 3 Indizes angelegt. Abbildung 6: SQL-Statement und Ausführungsplan für Meier in Berlin Im ersten Schritt hat dies nicht zum gewünschten Erfolg geführt. Obwohl nur geringe Kosten angezeigt werden, läuft diese Abfrage ca. 35 Sekunden. Erst eine Änderung der Statistikpflege hat hier eine deutliche Besserung erbracht. Die Statistiken werden im System jede Nacht mit DBMS_STATS.GATHER_TABLE_STATS aktualisiert. Hier wurde die Methode (Parameter method_opt) "FOR ALL COLUMNS" verwendet. Diese entspricht auch der Methode "FOR ALL COLUMNS SIZE 1". Erst nachdem die BUCKET SIZE deutlich erhöht (es wird jetzt 150 verwendet) haben, änderte sich der Ausführungsplan, so dass die Abfrage nur wenige Millisekunden dauert. Die von Oracle empfohlene Einstellung AUTO (die nicht Defaultwert ist) hat den gewünschten Effekt übrigens nicht erzielt. Abbildung 7: Ausführungsplan mit BUCKET SIZE 150 Unscharfe Suche und Dublettenerkennung. Die scharfen Suchmöglichkeiten mittels SQL und Oracle Text auf dem CRM Server werden ergänzt durch die erweiterten Suchmöglichkeiten von FUZZY! Double auf dem FUZZY! Server. Die CRM-Anwendung übergibt dazu die Suchkriterien der Funktion DoubleSearch(). Die unscharfe Suche nach Geschäftspartnern wird dann durch die durch die im Double Server implementierten Suchalgorithmen durchgeführt.

5 18. Deutsche ORACLE-Anwenderkonferenz Diese Algorithmen basieren auf Merkmalsvergleichen der Strings (Schreibweise und Phonetik) die in punkto Konfigurierbarkeit und Positionstoleranz einfachen Matchcodeverfahren wie z.b. SOUNDEX überlegen. Bei der Suche werden außerdem Stoppwortlisten berücksichtigt, um weniger relevante Namensbestandteile wie etwa Titel, Rechtsformen, Konjunktionen zu erkennen (GmbH, Prof., und Co., Graf, Abteilung). Abbildung 8: unscharfe Suche mit FUZZY! Double Ergebnis der unscharfen Suche ist eine nach Ähnlichkeit sortierte Trefferliste, die von der CRM-Anwendung weiterverarbeitet wird, d.h. beispielsweise als Auswahlliste dem Anwender präsentiert wird. Neben der unscharfen Suche wird DoubleSearch() auch während der Neuanlage von Geschäftspartnern aufgerufen, um sicherzustellen, dass ein ähnlicher Eintrag des neuen Geschäftspartners nicht bereits existiert (Dublettenvermeidung). Der Double Server hält Teile der Geschäftspartner-Selektionstabelle in einem für die unscharfe Suche ausgelegten Format vor in einer 9i-Datenbank vor. Auf die Tabellen dieses GP-Index wird vom Double Server mittels dynamischen SQL zugegriffen. Der in C++ geschriebene Double Server verwendet dazu Methoden der quelloffenen "Oracle Template Library" (OTL 1 ). IT Experience Fehlertolerante Adressvalidierung Ähnliche Algorithmen wie in FUZZY! Double sind auch in FUZZY! Post implementiert, dass ebenfalls als C/S-Anwendung in die CRM-Lösung von OPITZ CONSULTING integriert ist. Mit FUZZY! Post werden fehlerhafte Adressen bei der Neuanlage eines Geschäftspartners geprüft und ggf. normiert und korrigiert. Die aktuellen Referenzdaten der Deutschen Post Direkt werden dazu von FUZZY! Informatik AG viermal jährlich aufbereitet und bei der VDI-Gruppe zur Laufzeit auf dem FUZZY! Server eingespielt. Abbildung 9: unscharfe Adressvalidierung mit FUZZY! Post Segmentierung: ODER und 1:n Veranstaltungen und Merkmale sind beides 0:n Informationen zu einem Geschäftspartner. In der Segmentierung gibt es z. B. folgende Anforderungen alle Geschäftspartner die an Veranstaltung X teilgenommen haben oder die das Merkmal Y haben. Das Selektionstool (z. B. der Oracle Discoverer) würde ein Geschäftspartner, der das Merkmal Y, aber keine Veranstaltung hat, nicht in der Ergebnismenge liefern. 1 siehe

6 Damit auch in allen Fällen korrekte Ergebnismengen selektiert werden, müssen diejenigen Geschäftspartner, die keine Merkmale oder Veranstaltungen haben, ein Pseudo-Merkmal, oder -Veranstaltung erhalten. Diese Pseudo-Einträge werden vom System automatisch vergeben und bei der Pflege der Geschäftspartner nicht angezeigt. Volltextsuchen Eine besondere Form der Suchstrategien sind die Volltextsuchen, die mit Oracle Text (CONTAINS Operator) umgesetzt wurden. Neben klassischen Freitextfeldern (wie z. B. den Inhalt eines Kontaktes) wird diese Suchstrategie vor allem auf die Firmennamen (bzw. vollständige Bezeichnungen der Juristischen Personen) angewendet. Gerade bei den Firmennamen gibt es häufig Fälle, in denen nicht klar ist, an welcher Stelle das entscheidende Wort geschrieben ist (z. B. Gebr. Karl Müller KG wird auch gerne als Müller KG, Gebr. Müller KG oder Karl Müller KG geführt. Eine scharfe Suche nach dem entscheidenden Suchwort Müller ist besonders schnelle und effektiv mit der Volltextsuche. Für die Volltextsuche wird eine separate und redundante Spalte im Selektionsbestand mit den Namensinformationen (inkl. Kurzname z. B. VW für Volkswagen) in der UPPER-Version geführt. Diese Lösung wurde ohne größere Erläuterungen intuitiv von den Anwendern sehr zufrieden stellend angewendet. Insbesondere die Antwortzeiten sind in der Regel sehr gut. Die einzigen Probleme stellen die besonderen Operatoren des CONSTAINS Operator dar. So liefern die Abfragen nach B3- oder FUZZY eine ORA Meldung. Die Ursache sind hier die vielen möglichen Operatoren, die die CONTAINS-Abfrage erlaubt. Aus eher persönlicher Sicht müsste in diesen Fällen aber keine derartige Fehlermeldung erfolgen, aber die Oracle-Hotline sieht dies anders. Da die möglichen Operatoren die meisten Anwender tendenziell überfordern, es aber wiederum einige gibt, für die einige der Operatoren nützlich sind, wird die ORA in der Anwendung mit einem aussagekräftigeren Text übersetzt. Kontaktadressen: Martin Bertelsmeier OPITZ CONSULTING Gummersbach GmbH Kirchstr Gummersbach Telefon: +49(0) Fax: +49(0) martin.bertelsmeier@opitz-consulting.de Internet: Martin Bernhardt FUZZY! Informatik AG Eglosheimer Str Ludwigsburg Telefon: +49(0) Fax: +49(0) Martin.Bernhardt@fazi.de Internet: