Evaluierung des Schnittstellen-Standards

INHALTSVERZEICHNIS

1. Einleitung
1.1. Inhalt und Aufbau dieser Arbeit

2. Überblick zu existierenden Data Mining Schnittstellen
2.1. Object Linking And Embedding DataBase für Data Mining (OLE DB DM)
2.1.1. Object Linking And Embedding (OLE)
2.1.2. Object Linking And Embedding DataBase (OLE DB) und Open Database Connectivity (ODBC)
2.2. Object Management Group’s Common Warehouse Metamodel (OMG CWM)
2.2.1. Die Object Management Group (OMG)
2.2.2. Das Common Warehouse Metamodel (CWM)
2.2.3. Das CWM Data Mining Metamodel
2.3. Structured Query Language für Medienobjekte (SQL/ MM Data Mining)
2.3.1. Data Mining Phasen
2.3.2. SQL/ MM Typen am Beispiel von Klassifikation
2.4. Java Data Mining Application Program Interface (JDMAPI)
2.4.1. Java Database Connectivity (JDBC)

3. Beschreibung von PMML
3.1. Die aktuelle PMML Version
3.1.1. Die allgemeine Struktur eines PMML Dokuments
3.1.2. Die Grundstruktur eines PMML Dokumentes
3.1.3. Das Mining Schema
3.1.4. Grundlegende Datentypen und Entitäten
3.2. Zusammenfassung und Vergleich mit anderen Schnittstellen
3.3. Die Zukunft von PMML/ Geplante Änderungen

4. Beschreibung möglicher Data Mining Lösungs-architekturen
4.1. Data Mining „ Über dem Warehouse“
4.2. Data Mining „Neben dem Warehouse“
4.3. Data Mining „Innerhalb des Warehouses“

5. Existierende Data Mining-Tools (PMML Provider) und Möglichkeiten der PMML Implementierung
5.1. SAS Enterprise MinerTM
5.2. SPSS Clementine®
5.3. IBM DB2® Intelligent Miner
5.4. Oracle9 i ® Data Mining
5.5. NCR Teradata® Warehouse Miner
5.6. Quadstone DecisionhouseTM
5.7. ANGOSS® KnowledgeSTUDIO
5.8. KXEN Analytic Framework™
5.9. prudsys® Softwarepaket

6. Einsatzmöglichkeiten von PMML in operativen Systemen (PMML Clients)
6.1. Supply Chain Management (SCM)
6.2. Customer Relationship Management (CRM)
6.3. eCommerce
6.4. Datenbanken

7. Fazit

Anhang
Anlage 1: Document Type Definition (PMML 2.0 DTD)
Anlage 2: Gängige OLE DB Provider
Anlage 3: Beispiel-Code JDMAPI, JSR-073
Anlage 4: Beispiel einer Data Mining Lösungsarchitektur der Firma prudsys (PREMINER):
Anlage 5: Übersicht der features früherer Clementine Versionen:
Anlage 6: Abkürzungsverzeichnis
Anlage 7: Begriffsdefinitionen
Anlage 8: Abbildungsverzeichnis
Anlage 9: Tabellenverzeichnis
Anlage 10: Literaturverzeichnis

1. Einleitung

Steigender Wettbewerbsdruck sowie wachsende Umfelddynamik zwingen Unternehmen dazu, ihr internes und externes Umfeld systematisch zu analysieren. Die innerhalb der Analyse anfallenden Daten, die es auszuwerten gilt, stellen für das Unternehmen eine wichtige Ressource dar. Die dadurch gewonnenen Informationen werden in intelligentes Wissen umgewandelt, um gezielte Maßnahmen und Strategien entwickeln beziehungsweise einleiten zu können.

Im Zuge der Globalisierung, führt die voranschreitende weltweite informationstechnologische Vernetzung zu einem Anstieg des gesamten Datenvolumens der Unternehmen. Aufgrund des Preisverfalls von Datenverarbeitungs- und Speichermedien können Unternehmen die enormen Mengen anfallender Daten bewältigen, ohne dass dies einen allzu gewichtigen Kostenfaktor darstellt. In diesen Daten ist wertvolles Wissen enthalten, welches für die Unternehmen nutzenbringend eingesetzt werden kann. So können sie sich beispielsweise gezielter am Markt positionieren, ihre Marktanteile steigern oder gesamte Geschäftsprozesse optimieren, was einer Umsatzsteigerung und Kostenreduktion gleichkommt.

Dem Prozess der Informationsgewinnung kommt eine für Unternehmen immer wichtiger werdende Bedeutung zu, da hierdurch entscheidende Wettbewerbsvorteile erlangt werden können. Dabei werden Unternehmen jedoch mit der Problematik sehr großer Datenbestände konfrontiert, die mit klassischen Analysesystemen nicht mehr auswertbar sind. Aus diesem Grund entwickelte sich Ende der 80er Jahre die interdisziplinäre Forschungsrichtung „Knowledge Discovery in Databases“, die mittlerweile überwiegend als Data Mining bezeichnet wird.

Verschiedene Branchen verlangen nach unterschiedlichen Lösungen. Selbst innerhalb einer bestimmten Branche werden eine Vielzahl von unterschiedlichen Systemen, Plattformen und Anwendungen eingesetzt, um die anfallenden Daten erfassen, verarbeiten, darstellen und ablegen (speichern) zu können. Will man diese Daten minieren und analysieren, um intelligentes Wissen zu entdecken (Knowledge Discovery (KD)), benötigt man hierzu oft mehrere auf unterschiedlichen Systemen und Plattformen basierende Data Mining-Tools, um den speziellen Anforderungen gerecht werden zu können. Doch diese Vielfalt verbirgt das Problem proprietärer und heterogener Systeme. Daher wird ein Schnittstellen-Standard benötigt, der dieses Problem umgeht – Predictive Model Markup Language (PMML).

1.1. Inhalt und Aufbau dieser Arbeit

Für den Einsatz von Data Mining in branchenspezifischen Projektlösungen bietet sich die Einbeziehung von etablierten Schnittstellen-Standards an. Dies ermöglicht einerseits eine dynamisch strukturierte Analyse-Infrastruktur, die je nach Bedarfs- und Marktentwicklung erweitert werden kann und erlaubt andererseits einen schnelleren und effizienteren Einsatz der erstellten Modelle in der operativen Umgebung.

Um die Bedeutung des PMML Standards für Data Mining Lösungen in der nächsten Zukunft einschätzen zu können, ist der Gegenstand der Arbeit die Untersuchung der verschiedenen Aspekte dieser Schnittstelle.

Im zweiten Kapitel erfolgt ein Überblick über die neben PMML existierenden Data Mining Schnittstellen, um diese später (am Ende des dritten Kapitels) mit dem PMML Standard vergleichen zu können. Dabei soll im zweiten Kapitel auf die Entstehung, Zusammenhänge und Komponenten beziehungsweise Bestandteile jedes einzelnen Standards eingegangen werden.

Im dritten Kapitel erfolgt die Evaluierung des PMML Standards. Dies geschieht zunächst anhand der Beschreibung von PMML bezüglich der Struktur und Document Type Definition (DTD). Anschließend werden die in Kapitel zwei betrachteten Schnittstellen mit ihren Besonderheiten zusammengefasst, um sie dann mit PMML vergleichen zu können. Anhand einer SWOT-Analyse werden die Stärken/ Schwächen- beziehungsweise Chancen- und Risiken von PMML erarbeitet und beurteilt. Am Kapitelende erfolgt ein Ausblick bezüglich der Zukunft von PMML.

In Kapitel vier werden mögliche Data Mining Lösungsarchitekturen aufgeführt, um dem Leser den Zusammenhang von Data Mining und Data Warehouse aufzuzeigen und ihn auf die folgenden Kapitel bezüglich des PMML Einsatzes vorzubereiten.

Die Kapitel fünf und sechs stellen den praxisorientierten Teil dar. Dabei werden in Kapitel fünf zunächst die drei für SBS Siemens Business Services interessantesten und auch mächtigsten Data Mining-Tools als PMML Provider ausführlicher betrachtet und bezüglich der Möglichkeiten der PMML Implementierung beurteilt. Folgend werden weitere Data Mining-Tools anhand der entwickelten Kriterien in tabellarischer Form aufgeführt.

Kapitel sechs befasst sich mit den Client-seitigen Einsatzmöglichkeiten von PMML in den Bereichen des Supply Chain Managements (SCM), Customer Relationship Managements (CRM), Electronic Commerce (eCommerce) und in Datenbanken.

Abschließend sollen die wichtigsten Erkenntnisse im Rahmen eines Fazits zusammengefasst werden.

2. Überblick zu existierenden Data Mining Schnittstellen

2.1. Object Linking And Embedding DataBase für Data Mining (OLE DB DM)

OLE DB DM von Microsoft® ist eine Erweiterung der OLE DB für OLAP services Spezifikationen, die es schon in der früheren Version des SQL Server 7 gab, so dass keine neuen OLE DB Schnittstellen hinzukamen. Im Herbst 2000 stellte Microsoft das neue Release SQL Server 2000 vor. Microsoft’s Annäherung an das Ziel, die Fähigkeiten der OLAP services zu erweitern, nahm in Form der im SQL 2000 Server integrierten OLAP/ Data Mining Umgebung namens Analysis Services Gestalt an.^[1] Mit dem neuen Release wurden neue Fähigkeiten und Varianten bezüglich Datentaxonomien und Mechanismen für die Transformation von Daten eingeführt.

OLE DB DM erlaubt Data Mining über nur ein etabliertes API: OLE DB. OLE DB DM ist eine Schnittstelle für Data Mining, die es Anwendern und Entwicklern ermöglicht, auf relativ einfache und komfortable Art hoch skalierbare Data Mining Operationen in ihren Anwendungen einzubetten. Somit lautet die Oberprämisse Data Mining Algorithmen und Abfragen mit einem vereinfachten Mechanismus zu unterstützen beziehungsweise zu ermöglichen.

Des weiteren kommt eine der SQL Syntax sehr ähnliche leichte Abfragesprache zum Einsatz, über die spezielle Schemata von row sets definiert werden. Hierdurch können Consumer-Anwendungen mit Data Mining Providern kommunizieren (vergleiche Abbildung 2.2: UDA-Architektur).

OLE DB DM unterstützt vor allem die Data Mining Algorithmen Clustering/ Segmentierung und Klassifikation (Entscheidungsbäume). Data Mining Anwendungen können sich mittels eines OLE DB Providers aus sämtlichen Datenquellen in Form von Tabellen bedienen. Dieser Vorgang ermöglicht Data Mining Analysen mit direktem Zugriff auf relationale Datenbanken.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: OLE DB DM Architektur auf höchster Ebene

(Quelle: In Anlehnung an Ville, B. de, 2001, S. 66)

In Abbildung 2.1 wird die Sicht auf höchster Ebene auf die OLE DB DM Architektur dargestellt. Sowohl Clients als auch Server, wie SQL Server und andere OLE DB Datenquellen, werden unterstützt (unterer Teil der Abbildung). OLAP und user Anwendungen, system services wie commerce Server und eine Vielfalt von third-party Tools und Anwendungen, können sich der Möglichkeiten bedienen, die ihnen OLE DB DM bietet. Der Zugang erfolgt dabei über wizards/ Assistenten oder programmierte OLE DB command Objekte.^[2]

2.1.1. Object Linking And Embedding (OLE)

Object Linking And Embedding (OLE), zu deutsch Objektbindung und -einbau, ist ein Standard von Microsoft, der bei graphischen Betriebssystemen zum Datenaustausch zwischen Anwendungen dient.

2.1.2. Object Linking And Embedding DataBase (OLE DB) und Open Database Connectivity (ODBC)

Object Linking and Embedding DataBase (OLE DB) ist eine mächtige Datenbanktechnologie, die ungeachtet des Datentyps eine universelle Datenintegration in ein unternehmensweites Netzwerk vom Großrechner bis zum Desktop erlaubt.

Im Vergleich zu dem älteren Industriestandard Open Database Connectivity (ODBC) bietet OLE DB eine allgemeinere und effizientere Strategie des Datenzugriffs, weil es einen Zugriff auf mehre Datentypen erlaubt und auf dem Component Object Model (COM) basiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: UDA-Architektur

(Quelle: Faust, T. u.a., 2002, S.18)

Über die Universal Data Access-Architektur (UDA, vergleiche Abbildung 2.2)^[3] unterstützt Microsoft® ODBC und OLE DB für den Remotezugriff auf relationale Datenbanken. ODBC wurde insbesondere für die Zusammenarbeit mit relationalen Datenbankmanagement-Systemen (RDBMS) entwickelt, auf die über SQL zugegriffen wird. ODBC wird von unabhängigen Softwareherstellern entweder als Back-End-Datenbanktreiber oder als Front-End-Anwendung (zum Beispiel Berichterstellungs- oder Abfragetool) implementiert. Microsoft und andere Anbieter bieten ODBC-Treiber für die am weitesten verbreiteten relationalen Datenbankmanagement-Systeme (DBMS) an.

Microsoft hat OLE DB als mehrschichtig verteilte Architektur für den Zugriff auf SQL-RDBMS-Systeme und Nicht-SQL-Datenquellen (zum Beispiel Internet-Serverspeicher und Flat file-Systeme) definiert.

Unabhängige Softwarehersteller entwickeln in der OLE DB Architektur Software, die eine der drei folgenden Rollen haben kann:

1. OLE DB Provider oder Back-End-Datenquellentreiber,
2. OLE DB Dienstkomponente (zum Beispiel Abfrageprozessor, Cursormodul) und
3. OLE DB consumer (zum Beispiel Webdienst oder -anwendung, grafisches Abfrage- oder Berichterstellungstool).

OLE DB Provider legen eine bekannte Menge von Schnittstellen offen. Wenn ein Provider eine bestimmte nützliche oder häufig benötige Funktionalität nicht offen legen kann, wird eine OLE DB-Dienstkomponente verwendet, um die Fähigkeiten des Providers zu erweitern und zu standardisieren. Auf diese Weise können OLE DB consumer erstellt werden, die auf mehrere Datenquellen zugreifen, ohne die Unberechenbarkeiten oder Beschränkungen eines gegebenen Back-End-Providers zu kennen.

Für gängige OLE DB Provider, vergleiche Anhang 2.

2.2. Object Management Group’s Common Warehouse Metamodel (OMG CWM)

2.2.1. Die Object Management Group (OMG)

Die Object Management Group (OMG) ist das weltweit größte Software-Konsortium.^[4] Sie ist ein Zusammenschluss von Hardwareherstellern, Softwareentwicklern, Netzwerkbetreibern und kommerziellen Nutzern von Software.

Sie wurde 1989 von 8 Firmen (Apple, AT&T, DEC, HP, IBM, NeXT, Siemens Nixdorf, Sun) gegründet, öffnete sich aber nach wenigen Monaten als unabhängige Organisation auch für andere Unternehmen. Bis zum heutigen Zeitpunkt haben sich der OMG über 800 Unternehmen angeschlossen.^[5]

Kern der Arbeit der OMG ist neben der Standardisierung einer objektorientierten Architektur auf der Basis verteilter Objekte und der Förderung objektorientierter Technologien bei der Entwicklung verteilter Systeme, die Wiederverwendung, (Inter-) Portabilität objektorientierter Softwarekomponenten in heterogene Umgebungen und die Übernahme kommerziell verfügbarer Technologien.

Die frameworks für die Entwicklung objektorientierter Komponenten sind hierbei die Object Management Architecture (OMA^[6] ), die Common Object Request Broker Architecture (CORBA[6]), die Interface Definition Language (IDL[6]), das Internet Inter-ORB[6] Protocol (IIOP[6]) und das Common Warehouse Metamodel (CWM[6], vergleiche Kapitel 2.2.2.).

Ziel der OMG ist es, diese frameworks als Standard für verteilte Applikationen zu etablieren.

2.2.2. Das Common Warehouse Metamodel (CWM)

Das Common Warehouse Metamodel (CWM) ist ein Standard der OMG und wird unter anderem von Gesellschaften wie IBM, Oracle, Unisys, Hyperion, Genesis und NCR ständig weiterentwickelt.

Das oberste Ziel von CWM ist es, einen einfachen Austausch von Business Intelligence- und Warehouse-Metadaten zwischen Warehouse-Tools, Warehouse-Plattformen und Warehouse-repositories bei verteilten heterogenen Umgebungen zu ermöglichen.

Die Datenmenge eines Unternehmens verdoppelt sich circa alle fünf Jahre.^[7]

Viele Unternehmen leiden unter dieser unüberschaubaren Menge oft redundanter und inkonsistenter Daten. Dadurch fällt es den Unternehmen schwer, einen Zugang zu diesen Daten zu finden und sie zu managen, geschweige denn sich diese Daten zur Entscheidungsunterstützung zunutze machen zu können.

Data Warehousing stellt eine geeignete Annäherung dar, Daten in wertvolle und verlässliche Informationen zu transformieren, damit sinnvolle betriebliche Entscheidungsprozesse zu unterstützen und schließlich Business Intelligence zu erreichen.

Für das weitere Verständnis ist eine detaillierte Beschreibung der Begriffe Data Warehouse und Metadaten sinnvoll:

Exkurs Data Warehouse und Metadaten:

Ein Data Warehouse ist eine physische Datenbank, in der Daten gesammelt werden (historisiert), um diese auswerten beziehungsweise analysieren zu können.

Der Sinn und Zweck eines Data Warehouse liegt in der themenorientierten, integrierten, zeitbezogenen und dauerhaften Sammlung von (historisierten) Informationen zur Entscheidungsunterstützung des Managements (Decision Support System (DSS)). Ein Data Warehouse ist eine von den operationalen Daten isolierte Datenbank.

Systeme zur Verarbeitung von operationalen Daten laufen meist unter OLTP (On-Line Transaction Processing). OLTP Systeme haben hauptsächlich die Aufgabe, Transaktionen zu verarbeiten. Sie sind auf einen möglichst hohen Durchsatz optimiert, das heißt, es sollen möglichst viele Transaktionen pro Zeiteinheit durchgeführt werden, wobei die Datenmenge pro Transaktion relativ klein ist.

Analysen zur Entscheidungsunterstützung sind meist sehr zeitaufwendig. Für eine Betrachtung und Analyse längerer Zeiträume sind vor allem historisierte Daten erforderlich, die von einem OLTP System nicht zur Verfügung gestellt werden können. Dies erzwingt eine Speicherung der Daten auf einem separaten Datenspeicher, dem Data Warehouse.

Bei größeren Unternehmen sind die Datenbestände oft auf mehrere OLTP Systeme, zum Beispiel für Marketing und Vertrieb, verteilt. Dies hat zur Folge, dass dafür meist unterschiedliche, nicht miteinander kompatible Datenbanken verwendet werden. Zu Analysezwecken müssen diese operationalen Daten vorverarbeitet werden, bevor sie im Warehouse abgelegt werden können. Die Vorverarbeitung erfolgt meist über ETL. Dies steht für den E xtraktions-, T ransformations- und L adeprozess (vergleiche Abbildung 2.3).

Bei der Extraktion werden die für die Analyse notwendigen Daten zur Weiterverarbeitung aus den jeweiligen Quellsystemen in ein einheitliches Format gebracht.

Bei der Transformation der Daten werden neben der Filterung, Anreicherung, Verdichtung, Vereinheitlichung und Harmonisierung insbesondere Fehler korrigiert und Inkonsistenzen beseitigt.

Durch das anschließende Laden der Daten wird eine Art Index erstellt und bestehende Datenbestände werden aktualisiert.

Eine nach diesen Prozessen schematisch und thematisch vor- beziehungsweise aufbereitete Ansammlung von Daten wird als Data Warehouse bezeichnet.

Gewöhnlich basiert die Modellierung eines Data Warehouse auf einem multidimensionalen Schema.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Data Warehouse Architektur

(Quelle: In Anlehnung an Han, J.; Kamber, M., 2000)

Einer der wichtigsten Aspekte von Data Warehousing sind Metadaten.

Für Metadaten gibt es keine einheitliche Definition. Die wohl einfachste Definition lautet: Metadaten sind „Daten über Daten". Unter Metadaten im Allgemeinen versteht man strukturierte Daten, mit deren Hilfe eine Informationsressource bezüglich ihrer Qualität, Herkunft, Aktualität etc. beschrieben und dadurch besser auffindbar gemacht werden kann.

Von Tim Berners-Lee, dem Erfinder des World Wide Web und Direktor des World Wide Web Consortiums (W3C), stammt die Definition: "Metadaten sind maschinenlesbare Informationen über elektronische Ressourcen oder andere Dinge."

Metadaten bestehen aus drei Kategorien von Informationen, i.e. aus semantischen Metadaten, die den Business-Kontext von Daten beschreiben, Navigations-Metadaten, die das Informations-Management im Rahmen der Information Supply Chain beschreiben und aus verwaltungsorientierten Metadaten, die die Nutzung der Metadaten beschreiben. Metadaten werden in einem Repository oder Daten-Diktionär gespeichert und verwaltet.^[8]

Innerhalb eines Data Warehouse werden Metadaten genutzt, um zu erfahren, aus welcher Datenbank und aus welcher Tabelle dieser Datenbank bestimmte Daten ursprünglich stammen, an welchem Tag und welcher Uhrzeit sie genau extrahiert wurden und welchen Status die Datenbank zu diesem Zeitpunkt hatte.

So kann man ausgehend von einer Information aus dem Data Warehouse „Schritt für Schritt" in die Vergangenheit zurückgehen und die Ereignisse und Daten rekonstruieren, aus denen sich die spezifische Information zusammensetzt.

Ende Exkurs

Beim Data Warehousing werden Metadaten zum konstruieren, pflegen, managen und aufrechterhalten des Warehouse benutzt beziehungsweise benötigt.

Der starke Zuwachs von Datenmanagement und den dazugehörigen AnalyseTools hat dazu geführt, dass für den Umgang mit Metadaten nahezu ähnlich viele unterschiedliche Ansätze wie Tools existieren.

Da jedes Datenmanagement- und AnalyseTool auf unterschiedlichen Metadaten und Metadatenmodellen (metamodels) basiert, liegt es auf der Hand, dass es ein Metadaten repository zur Generierung eines geeigneten Metadatenmodells für ein Unternehmen nicht gibt.

Vielmehr muss es einen Standard für den Austausch von Warehouse Metadaten geben. Für diese Problematik liefert CWM die passende Lösung.

2.2.2.1. Das CWM Metamodel

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Das CWM Metamodel

(Quelle: In Anlehnung an Object Management Group (OMG), 2001)

Das CWM Metamodel sieht ein framework vor (vergleiche Abbildung 2.4), worin Metadaten bezüglich ihrer Datenquellen, Bestimmungsorte, Transformationen und Analysen repräsentiert werden. Es beschreibt Prozesse und Operationen, welche Warehousedaten generieren und managen, und wie die daraus abgeleiteten Informationen verwendet werden.

Das CWM Metamodel umfasst eine Vielzahl weiterer untergeordneter Modelle, welche CWM in den folgenden Interessengebieten von Data Warehousing und Business Intelligence darstellen:

- Resource:

Data Resources enthält Metadatenmodelle, welche objektorientierte, relationale, multidimensionale, record und XML data resources repräsentieren. Im Falle objektorientierter data resource wird vom CWM das Basis object model wiederverwendet (siehe Abbildung 2.4 hervorgehobenes unteres object model).

- Analysis:

Data Analysis beinhaltet Metadatenmodelle, welche Datentransformationen, OLAP, Data Mining, information visualization und business nomenclature repräsentieren.

- Management:

Warehouse Management schließt Metadatenmodelle ein, die Warehouse Prozesse und Ergebnisse von Warehouse Operationen wiedergeben.

2.2.2.2. Die OMG Metadaten repository Architektur

Das CWM basiert auf den drei Industriestandards:

1. Unified Modeling Language (UML), ein OMG Modellierungsstandard,
2. Meta Object Facility (MOF), ein OMG Metamodellierungs- und Metadata repository Standard und dem
3. XML Metadata Interchange (XMI), einem OMG Metadata interchange Standard.

Die Standards UML, MOF und XMI bilden das Herzstück der Metadaten-repository Architektur in Abbildung 2.5:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: OMG Metadaten-repository Architektur

(Quelle: In Anlehnung an Object Management Group (OMG), 2001, S. xvii)

Der UML Standard definiert eine „reichhaltige“, objektorientierte Modellierungssprache, welche noch von einer Vielzahl graphischer Design-Tools unterstützt wird.

Der MOF Standard definiert ein erweiterbares framework zur Definition von Metadaten-Modellen. MOF ermöglicht Tools mit einer Programmierschnittstelle, auf Metadaten in einem repository zugreifen beziehungsweise sie darin speichern zu können.

Der XMI Standard erlaubt den Austausch von Metadaten über streams oder Dateien eines Standardformats basierend auf XML.

Die komplette 4-Schichten-Architektur bietet Entwicklern von Tools, repositories und Objekt-frameworks die Möglichkeit, Metadaten für verteilte Objekt-repositories manipulieren zu können und von einer Vielzahl von Implementierungsmöglichkeiten die für sie am besten Geeignete auszuwählen.

Zusammenfassend kann man OMG’s CWM somit als ein objektorientiertes, UML-basiertes Standard-Metamodell zum einheitlichen Metadaten-Austausch mit XMI als Austauschformat und MOF als Metamodell beschreiben.

2.2.3. Das CWM Data Mining Metamodel

Das Data Mining Paket ist Teil des CWM Analyse Pakets und hängt von den Paketen

- CWM: ObjectModel: Core und
- CWM: ObjectModel: Instance ab.

Es enthält Klassen und Assoziationen zur Wiedergabe von Metadaten diverser Data Mining-Tools.

Das CWM Data Mining Metamodel wird in drei Bereiche eingeteilt:

1. Das Modell an sich (Abbildung 2.6),
2. Settings (Abbildung 2.7) und
3. Attributes (Abbildung 2.8).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6: CWM Data Mining Metamodel: Modell

(Quelle: Object Management Group (OMG), 2001, S. 12-3)

Der Bereich Modell besteht aus einer „gattungsmäßigen“ Repräsentation eines Data Mining Modells, das heißt, es handelt sich um ein durch die Ausführung eines Data Mining Algorithmus generiertes mathematisches Modell.

Dazu gehören MiningModel (die Wiedergabe des Mining Modells an sich), MiningSettings, durch welche die Konstruktion des Modells bestimmt wird, ApplicationInputSpecification, wodurch die Anzahl der eingegebenen Attribute für das Modell spezifiziert werden und das MiningModelResult, wodurch das Ergebnis eines Tests oder einer Applikation eines generierten Modells wiedergegeben wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.7: CWM Data Mining Metamodel: Settings

(Quelle: Object Management Group (OMG), 2001, S. 12-4)

Im Bereich Settings werden die MiningSettings des Bereichs Modell unter Berücksichtigung der AttributeUsageRelation aus der Eingabespezifikation weiter und tiefergehend ausgeführt.

MiningSettings besitzt die vier Unterklassen StatisticsSettings, ClusteringSettings, SupervisedMiningSettings und AssociationRules-Settings.

Die SupervisedMiningSettings haben die Unterklassen Classification-Settings und RegressionSettings, wobei noch eine CostMatrix zur Anzeige von Kostenpositionen und damit verbundenen Fehlbeträgen definiert wurde.

AttributeUsageRelation besteht aus Attributen, welche die Verwendung der MiningAttributes durch die MiningSettings klassifizieren.

Mehrere Verbindungen werden dazu genutzt Attributbedingungen, die in Unterklassen der settings gestellt wurden, näher zu definieren (zum Beispiel: target, transactionId, and itemId).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.8: CWM Data Mining Metamodel: Attributes

(Quelle: Object Management Group (OMG), 2001, S. 12-5)

Der Bereich Attributes definiert zwei Unterklassen des MiningAttribute:

NumericAttribute und CategoricalAttribute.

Category beschreibt die category Werte und Eigenschaften, die entweder aus einem CategoricalAttribute oder einem OrdinalAttribute bestehen.

CategoryHierarchy gibt eine beliebige Taxonomie^[9] an, die mit einem CategoricalAttribute in Verbindung gebracht werden kann.

2.2.3.1. Die Vererbung des CWM Data Mining Metamodels

Die Vererbung des CWM Data Mining Metamodels vom CWM Object Model wird in Abbildung 2.9 veranschaulicht:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.9: Vererbung des CWM Data Mining Metamodels

(Quelle: Object Management Group (OMG), 2001, S. 12-6)

2.3. Structured Query Language für Medienobjekte (SQL/ MM Data Mining)

SQL/ MM ist ein von der International Standard Organisation und International Electrotechnical Commission (ISO/ IEC 9075, SQL/ MM: ISO/ IEC 13249) festgelegter eigenständiger SQL Standard für Medienobjekte/ Multimedia und Application Packages wie Full Text, Spatial, Still Image, Still Graphic, Animation, Full Motion Video, Audio, Seismic, and Music^[10].

SQL/ MM besteht aus sechs Teilen:

- Teil 1: SQL/ MM Framework

(Juli 2000: FDIS-Abstimmung erfolgreich)

- Teil 2: SQL/ MM Full Text

(Juli 2000: FDIS-Abstimmung erfolgreich)

- Teil 3: SQL/ MM Spatial

(Februar 2000: IS)

- Teil 5: SQL/ MM Still Image

(FDIS seit Sept. 2000)

- Teil 6: SQL/ MM Data Mining

(ISO/ IEC 13249-6)

Teil 1 soll einen Überblick geben und die Konformität spezifizieren. Jeder weitere Teil ist ein Paket für (eine Art von) Mediendaten, bestehend aus User Defined Types (UDT), Methoden und User Defined Functions (UDF). Dabei können User Defined Functions als Typ einer Tabellenspalte, Typ eines Attributs in einem anderen UDT und Obertyp für einen abgeleiteten UDT verwendet werden.^[11]

SQL/ MM liegen folgende Motivationen zugrunde:

- Die Verwendung von Mediendaten und -operationen in vielen Anwendungen.
- Die Ausnutzung der Erweiterbarkeit von ORDBMS für die Definition von Medienobjekten.
- Die Bereitstellung von Erweiterungen in Paketen, die die Verwaltung (Installation, Upgrade, Entfernen) und Wiederverwendung (ein Paket kann anderes benutzen) erleichtern.
- Proprietäre Pakete existieren bereits für:

- Informix: Excalibur Text Search DataBlade, Excalibur Image DataBlade, Informix Video Foundation Data-Blade Module
- DB2: Image Extender, Audio Extender, Video Extender, Text Extender
- Oracle: Visual Information Retrieval (VIR) Cartridge, ConText Cartridge, InterMedia

- Die Standardisierung ermöglicht:
- Eine gemeinsame „Sprache“,
- den Datenaustausch und
- Anwendungen, die auf verschiedenen Implementierungen laufen.

Wie oben aufgeführt, betrifft der sechste Teil Data Mining: Teil 6: SQL/ MM Data Mining.

Teil 6 hat zum Ziel, Daten im allgemeinen mit Data Mining im speziellen zusammenzubringen.

Für Data Mining Modelle soll eine standardisierte SQL Schnittstelle zur Verfügung gestellt werden, die Data Mining als einen Teil von SQL-Abfragen und -Anwendungen, wie zum Beispiel Enterprise Resource Planning, erlaubt.

Dabei soll Data Mining vielmehr ein middleware-service als ein stand-alone Tool sein.^[12]

Die von SQL/ MM betroffenen Data Mining Techniken sind Assoziationsregeln, Clustering/ Segmentation, Klassifikation und Regression.

2.3.1. Data Mining Phasen

Um den Einsatz von SQL/ MM später besser veranschaulichen zu können, wird auf die folgenden drei Hauptphasen des Data Mining eingegangen:^[13]

1. Training (Training),
2. Anwendung (Apply) und
3. Test (Test).

Zu 1.) Trainingsphase:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.10: Trainingsphase

(Quelle: In Anlehnung an Schwenkreis, F., 2000, S. 6)

Die Trainingsphase (vergleiche Abbildung 2.10) ist bei allen Data Mining Techniken gleich. In dieser Phase wird das Data Mining Modell berechnet. Hierbei ist bedeutend, dass zur Modellberechnung diverse Einstellungen und Datendefinitionen bekannt sind. Beachtenswert ist, dass hierfür oft ein mehrmaliger Eingabeprozess erforderlich ist, bevor ein Modell generiert werden kann. Darüber hinaus müssen die meisten Data Mining Techniken Felder identifizieren können. Dadurch ist es möglich, Data Mining bezogene Informationen, wie zum Beispiel eine spezielle Behandlung eines Feldes oder Feldtypen vor allem bei prädiktiven Techniken, richtig zuordnen zu können.

Zu 2.) Anwendungsphase:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.11: Anwendungsphase

(Quelle: In Anlehnung an Schwenkreis, F., 2000, S. 7)

Gegenwärtig gibt es nur Anwendungsmodi für Clustering, Klassifikation und Regression. Während der Applikation eines Modells wird eine Zeile gegen ein Modell ausgewertet und ein oder mehrere Werte berechnet. Wendet man zum Beispiel das Clusteringmodell bei einer Kundenzeile an, so wird dieser Zeile eine Cluster-ID zugewiesen. Im Falle einer Klassifikation wird für die Zeile ein class label berechnet.

Um das Modell auf eine Datenzeile richtig anzuwenden, müssen die Felder der Zeile denjenigen Feldern zugeordnet werden, die während der Trainingsphase als relevant identifiziert wurden. Daher ist es nicht ausreichend, nur die Feldwerte zu übergeben.

Zu 3.) Testphase:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.12: Testphase

(Quelle: In Anlehnung an Schwenkreis, F., 2000, S. 8)

Es haben nur die Data Mining Techniken Klassifikation und Regression eine Testphase (vergleiche Abbildung 2.12). Testen bedeutet hier eine Überprüfung des Vorhersagemodells hinsichtlich seiner Qualität.

Während eines Tests werden mehrere Zeilen mit einem speziellen Trainingsfeld ausgelesen und für jede Zeile die entsprechende Data Mining Anwendung aufgerufen. Danach wird der vorhergesagte Wert mit dem tatsächlichen Wert verglichen. Wurden alle Zeilen ausgelesen, wird ein statistisches Ergebnis über die falschen Vorhersagen berechnet und als Testergebnis ausgegeben.

2.3.2.SQL/ MM Typen am Beispiel von Klassifikation

Man kann die in 2.2.3.1. aufgeführten Phasen in folgendes SQL/ MM Typen-Schema (vergleiche Abbildung 2.13) einbetten:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.13: SQL/ MM Typen und eingebettete Phasen^[14]

(Quelle: In Anlehnung an Schwenkreis, F., 2000, S. 9)

2.3.2.1. Klassifikation: Classification Settings

Classification Settings Table (CST):

(id, owner, created, settings)

INSERT INTO CST (id, owner, settings)

VALUES (111, ’mthilo’,

NEW DM_ClassificationSettings());

DM_ClassificationSettings erlaubt eine Anpassung der Einstellungen, zum Beispiel die Festlegung der Tiefe bei Entscheidungsbäumen.

2.3.2.2. Klassifikation: Input Data

Customer table CT: (age, gender, income, risk)

Classification data definition table (CDT):

(id, owner, created, data)

INSERT INTO CDT (id, owner, data)

VALUES (222, ’mthilo’,

NEW DM_ClassificationData());

UPDATE CDT SET

data =

data.addClassificationDataSource(’CT’, ’risk’)

WHERE ID = 222

2.3.2.3. Klassifikation: Classification Model

Classification model table (CMT):

(id, owner, settings, data, model)

WITH settings, data AS (

SELECT CST.settings, CDT.data

FROM CST, CDT

WHERE CST.id = 111 AND CDT.id = 222

)

INSERT INTO CMT

(id, owner, settings, data, model)

VALUES

(333, ’mthilo’, settings, data,

NEW DM_ClassificationModel (settings, data))

2.3.2.4. Klassifikation: Classification Training

UPDATE CMT

SET model = model.computeModel()

WHERE ID = 333

Leitet die Berechnung eines Modells ein.

2.3.2.5. Klassifikation: Classification Application

WITH model AS ( SELECT model FROM CMT WHERE id = 333 )

SELECT model.applyClassificationModel(

age, ’age’,

gender, ’gender’,

income, ’income’)

FROM CT

Sagt die Klasse der Eingabedaten (input data) voraus.

Es ist noch anzumerken, dass mit SQL/ MM keine Data Mining Modelle und Metadaten formatiert werden sollten. Genauso steht das Generieren von speziellen Algorithmen zur Implementierung einer Data Mining Technik außen vor.

2.4. Java Data Mining Application Program Interface (JDMAPI)

Das Java Data Mining Application Program Interface (JDMAPI), Java Specification Request JSR-073, stellt eine reine Java™ API für Business Intelligence Anwendungen zur Verfügung^[15].

JDMAPI zielt auf die Java 2™ Plattform, Enterprise Edition (J2EE™) ab.

Die Spezifikation unterliegt einer ständigen Weiterentwicklung von Sun Microsystems, IBM, SAP AG, SPSS, SAS Institute, Hyperion Solutions Corporation und weiterer sich mit der Thematik befassender Firmen. Angeführt wird die community beziehungsweise dieser „Expertenpool“ von der Firma Oracle^[16].

Neben der Verabschiedung des community drafts im Juni 2002 und der über UML Modelle generierten API erfolgen die Reference Implementation (RI) und der Technology Compatibility Kit (TCK) im ersten Quartal 2003.

Folgende Paketnamen sind für die API Spezifikation vorgesehen:

- javax.datamining
- javax.datamining.settings
- javax.datamining.models
- javax.datamining.transformations
- javax.datamining.results

Mit JDMAPI soll ein Weg der Standardisierung gefunden werden, der das Konstruieren von Data Mining Modellen, deren Ergebnisse, Auswertungen und Transformationen, ferner das Scoring von Data Usage Modellen und das Speichern und Pflegen von Daten und Metadaten J2EE-fähiger Anwendungs Server sowie den Zugriff auf diese erlaubt.

Mit JDMAPI kann bei Data Mining Anwendungen ein einziges Standard-API implementiert werden, welches von einer Vielzahl von Client Anwendungen und Komponenten, auf der J2EE Plattform laufend, verstanden wird.

Auf ähnliche Art und Weise können Data Mining Clients über ein vom Data Mining System unabhängiges API verschlüsselt werden.

Das oberste Ziel von JDMAPI ist für Data Mining Systeme, was JDBC (vergleiche Kapitel 2.4.1.) für relationale Datenbanken ist.

Die JDMAPI zugrunde liegende Technologie basiert auf einem sehr verallgemeinerten, objekt-orientierten Data Mining Konzept-Modell.

JDMAPI ist kompatibel mit Data Mining Standards wie Common Warehouse Metamodel (CWM) der Object Management Group (OMG), SQL/ MM für Data Mining und PMML der Data Mining Group.

Das JDMAPI Modell unterstützt vier begriffliche Bereiche, die für Anwender von Data Mining Systemen von besonderem Interesse sind:

1. Settings
2. Modelle
3. Transformationen
4. Ergebnisse

Das Objektmodell umfasst einen core layer (zu deutsch eine Art „Herzstück“) von Diensten und Schnittstellen, welche jedem Client zur Verfügung stehen. Dies hat zur Konsequenz, dass jeder Client dieselbe Schnittstelle und Semantik sieht.

Ein besonderer oder spezieller Einsatz des Objektmodells ist nicht unbedingt gleichbedeutend damit, dass die von JDMAPI definierten Schnittstellen und Dienste alle unterstützt werden.

JDMAPI stellt dem Client Mechanismen zur Verfügung, die es ermöglichen Zusammenhänge herauszufinden, welche Schnittstellen mit zum Beispiel welcher Leistungsfähigkeit und welchen Beschränkungen unterstützt werden.

Jeder Anbieter kann bei der Implementierung von JDMAPI frei entscheiden, wie implementiert werden soll. Es gibt zum Beispiel die Möglichkeit, dass manche Anbieter JDMAPI als das „natürliche“ (native) „Standard“-API ihres Produktes implementieren, andere sich wiederum die Option offen lassen eine Art Treiber/ Adapter zu entwickeln, welcher zwischen einem core JDMAPI layer und anderen Anbieterprodukten vermittelt. Die JDMAPI Spezifikationen schreiben also keine besondere Strategie oder Vorgehensweise bei der Implementierung vor.

JDMAPI bedient sich anderer Spezifikationen und gleicht sie mit den seinen ab, um J2EE Kompatibilität garantieren zu können beziehungsweise doppelte Arbeiten, Anstrengungen und Bemühungen zu vermeiden. JDMAPI bezieht sich hierbei insbesondere auf die Java Connection Architecture (JSR-000016), um resource management, transaction management, security management, record mapping und result set management gerecht werden und zur Verfügung stellen zu können. Eine weitere Spezifikation derer sich JDMAPI bedient ist das Java Metadata Interface (JSR-000040) für core metadata management.

Die spezielle Ausrichtung von JDMAPI an JSR-000040 und den CWM Data Mining Metamodellen hat den Vorteil, dass es die Entwicklung und Konstruktion eines Data Warehouses und anderer Business Intelligence Anwendungen, -Tools und -Plattformen, basierend auf den OMG offenen Standards für Metadaten und Systemspezifikationen (zum Beispiel UML, CWM), unterstützt.

JDMAPI ist von keinem speziellen Betriebssystem oder bestimmten Hardwarevoraussetzungen abhängig.

Alle gängigen Data Mining Funktionen werden unterstützt:

- Klassifikation
- Regression
- Clustering
- Assoziationsregeln
- Neuronale Netze
- Naïve Bayes

Die Architektur^[17] setzt sich aus den Komponenten (vergleiche Abbildung 2.14)

- Application Programming Interface (API),
- Data Mining Engine (DME) und
- Metadata Repository (MR) zusammen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.14: Architekturkomponenten

(Quelle: In Anlehnung an Hornick, M. F. (2002), S. 24)

Die Anwendungsarchitektur (vergleiche Abbildung 2.15) stellt sich wie folgt dar:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.15: Anwendungsarchitektur des JSR-073

(Quelle: Hornick, M. F. (2002), S. 25)

Ein Beispiel-Code befindet sich im Anhang (Anlage 3: Beispiel-Code JDMAPI, JSR-073).

2.4.1. Java Database Connectivity (JDBC)

Java Database Connectivity (JDBC) ist ein Java API der Firma Sun Microsystems zur Ausführung von SQL statements. Es ermöglicht einen einheitlichen Zugriff auf unterschiedliche Relationale Datenbank Management Systeme (RDBMS). JDBC besteht aus einer Vielzahl von Java-Klassen beziehungsweise -Interfaces und bietet die Möglichkeit, Datenbankanwendungen in „reinem“ Java zu schreiben. Dabei wird über JDBC eine Verbindung zur Datenbank aufgebaut, außerdem werden die SQL Statements gesendet und die Ergebnisse verarbeitet.

Ein solche connection könnte folgendermaßen aussehen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.16: Beispiel für eine DB-connection mit JDBC

JDBC setzt auf dem X/OPEN SQL-Call-Level-Interface (CLI) auf und besitzt damit die gleiche Basis wie die ODBC-Schnittstelle.

Die API-Spezifikation für JDBC wurde von JavaSoft im März 1996 als vorläufige Version 0.50 vorgestellt. Sie liegt nunmehr in der Version 1.1 vor und wird im Rahmen des Java Development Kit (JDK) 1.1.x^[18] ausgeliefert.

Das JDBC API ist ein sogenanntes low-level Interface, das heißt die SQL statements werden direkt aufgerufen. Dies führt zu einem relativ einfachen Verständnis, setzt aber SQL-Kenntnisse voraus.

Das JDBC API ist aber auch durchaus als Basis für high-level Interfaces gedacht, welche dann SQL generieren.

Zur Zeit wird an der Entwicklung zweier high.level APIs gearbeitet:

1. Ein Embedded SQL für Java:

Java und SQL vermischt, zum Beispiel Nutzung einer Java-Variable in SQL Statements; Der Embedded SQL Preprocessor übersetzt dies dann in JDBC-Aufrufe.

2. Tabellen der relationalen Datenbanksysteme direkt auf Java-Klassen gemappt:

Jede Zeile als Instanz einer Klasse, jede Spalte darin als Attribut, aber auch Erweiterungen, zum Beispiel Zusammenfassung von Zeilen mehrerer Tabellen.

Bei speziellen Anwendungen kann ein selbst geschriebener mapper zum Beispiel SQL aus Nutzereingaben in Textfeldern oder Auswahllisten generieren.

[...]

^[1] Vgl. Ville, B. de (2001), S. 60ff.

^[2] Vgl. Ville, B. de (2001), S. 66.

^[3] Vgl. Faust, T.; Linke, A.; Schäfer; S. (2002), S. 18.

^[4] Vgl. Lüders, P. (2002), (2002), S. 12.

^[5] Vgl. URL: www.omg.org vom 12.08.2002.

^[6] Vgl. Begriffsdefinitionen

^[7] Vgl. Object Management Group (OMG) (2001), S. 3-1 – 3-2.

^[8] Vgl. Martin, W. (2002)

^[9] Vgl. Begriffsdefinitionen.

^[10] Vgl. International Standard Organization (ISO) (2001).

^[11] Vgl. Berthold, H. (2001), S. MMDB-10a-2 - MMDB-10a-4.

^[12] Vgl. Schwenkreis, F., IBM, SQL/ MM Part 6: Data Mining.

^[13] Vgl. Schwenkreis, F. (2000), S. Concepts 11-13.

^[14] Vgl. Schwenkreis, F., IBM, SQL/ MM Part 6: Data Mining.

^[15] Vgl. The Java Community Process (JCP) (2002).

^[16] Vgl. Hornick, M. F. (2002).

^[17] Vgl. Hornick, M. F. (2002).

^[18] Vgl. Sun (2002).