Lobster Experten Fragen

Datenbanken

Datenbanken stehen für gewöhnlich nicht einfach so für sich in der Gegend herum. Vielmehr dienen sie als Unterbau für die verschiedenen Systeme, die in einem Betrieb laufen. Ob großes ERP oder kleine Lohnbuchhaltung, kaum eine Software setzt heute noch auf Datenhaltung im Dateisystem. Statt dessen werden die Fähigkeiten eines Datenbanksystemes genutzt. Manche Programme stellen sehr spezielle Anforderungen an die Datenbank oder arbeiten gar nur mit einem einzigen Produkt zusammen, andere sind da flexibler.
Stand der Technik ist heute nach wie vor das RDBMS, das Relationale Datenbank-Management-System. Anders gesagt, es sind Datenbanken, die mittels SQL (der Structured Query Language) angesprochen werden. Es gibt auch andere Ansätze, z.B. die Objektorientierten Datenbanken, die aber eher ein Nischendasein fristen. Relationale Datenbanken sind nun mal für fast alles verwendbar und ungeschlagen, wenn es darum geht, enorme Datenmengen zu schlucken und zu verwalten.

Zugriff

Damit ein Programm seine Daten in einem Datenbanksystem verwalten kann, ist eine Schnittstelle zwischen beiden nötig. Auf Windows-Systemen üblich ist ODBC (Open Database Connectivity), das es auch unter Unix/Linux gibt. Plattformunabhängig ist man mit JDBC (Java Database Connectivity), dafür muss die Software jedoch in Java geschrieben sein. Jede ernstzunehmende Datenbank stellt heute sowohl ODBC- als auch JDBC-Treiber zur Verfügung. Allerdings gibt es oft APIs (Application Programming Interfaces), also direkte Programmierschnittstellen, über die Programme auf eine Datenbank zugreifen können. Das aber setzt eine sehr enge Verbandelung zwischen Software und Datenbank voraus, die man eigentlich eher meiden sollte. Nutzt man die standardisierten Schnittstellen ODBC und JDBC, lässt sich dagegen das DB-System theoretisch einfach austauschen, ohne dass die darüber setzende Software überhaupt etwas davon merkt. Theoretisch. In der Praxis unterstützen Datenbanken eben nicht nur das reine Standard-SQL, sondern haben immer auch spezifische Eigenheiten. Das fängt bei kleinen Unterschieden in der Notation der SQL-Statements an und endet noch lange nicht bei der Aufruf-Syntax von Stored Procedures, also kleinen Progrämmchen, die in einer Datenbank-eigenen Sprache direkt im DB-System selbst geschrieben sind, um dort nützliche Arbeiten zu übernehmen. Bedient sich eine Software irgendwelcher spezifischer Features eines bestimmten DB-Systems, ist es mit dem einfachen Wechsel schon wieder Essig.
Aber das hat jetzt relativ wenig mit EDI und EAI (oder auch ETL) zu tun.

Datenbanken und EDI/EAI/ETL

Software aus diesem Bereich hat die Aufgabe, viele unterschiedliche Systeme miteinander zu verknüpfen. Ein solches Programm darf also per se keine Sonderwünsche bzgl. der angesprochenen Datenbanken haben. Es muss vielmehr in der Lage sein, möglichst viele unterschiedliche Datenbanksysteme anzusprechen. Sicher kann auch das Programm selbst einiges in eigenen Datenbanktabellen ablegen, aber da es für seine tägliche Arbeit sehr flexibel sein muss, wäre es eigenartig, wenn es für die eigenen Daten eine Extrawurst verlangt.
Kurz und gut: Die Systeme, um die es hier geht, müssen ODBC und/oder JDBC beherrschen. Für ganz besonders eigenwillige Datenbanken, die womöglich nur via API ansprechbar sind, kann man zur Not noch etwas „dranstricken“, aber der Standard muss abgedeckt sein. Das Tool hat sich nach den Gegebenheiten in Ihrer Firma zu richten, nicht umgekehrt.

Allerdings sollten Sie nicht euphorisch die Datenbanken aller möglichen Programme mit einem eventuell neu angeschafften EDI- oder EAI-Programm anzapfen und wie wild Daten hineinschreiben. Solange Sie nur lesen, kann wenig passieren, aber komplexere Software (von etwas so großem wie einem SAP ERP mal ganz zu Schweigen) mag es gar nicht, wenn man an ihr vorbei einfach in ihren Tabellen herumpfuscht. Zu viele Abhängigkeiten sind zu beachten, da können Sie sich ganz schnell etwas „zerschießen“. Hier sind andere Schnittstellen zu bevorzugen – sofern sie existieren.
Auch, wenn Sie ETL-Prozesse aufsetzen wollen, sollten sie wirklich wissen, was Sie tun.

Sei’s drum, alleine für Lookups (also das Nachsehen von Informationen, zum Beispiel das Auslesen einer Adresse zu einer Kundennummer) ist der direkte Zugriff auf Datenbanken einfach eine feine Sache. Und da Sie womöglich nicht nur ein einziges Datenbanksystem im Hause haben, sollte sich der Zugriff auf die Systeme nicht allzu schwierig gestalten. Wenn Sie einen halben Tag damit verbringen, Zugriff auf eine weitere Datenbank zu erhalten oder bei der Definition jedes neuen Prozesses wieder alles einzeln konfigurieren müssen, passt was nicht. Auch sollte es möglich sein in einem Prozess mehrere, unterschiedliche Datenbanken anzusprechen, die jeweils Teile der benötigten Daten beinhalten.
Ist das DB-System selbst erst mal angesprochen, muss man sich mit den Tabellen herumschlagen. Das kann einfach sein oder kompliziert, je nach Software. Je mehr Unterstützung Sie hierbei von Ihrer Software erhalten, desto besser können Sie sich auf die eigentliche Definition eines EDI- oder EAI-Prozesses konzentrieren.

Bleibt noch eine Sache zu erwähnen: Wenn man von Datenbanken spricht, spricht man auch ganz schnell mal von Massendaten. Da werden ganze Artikelstämme hin und her geschaufelt, und auch der Kundenstamm ist hoffentlich groß; da prasseln im Sekundentakt Aufträge, Rechnungen, Lieferscheine und und und herein, die entweder direkt in die verschiedenen Datenbanken geschrieben oder daraus gelesen werden, oder die zumindest mengenweise Lookups erfordern. All das muss performant ablaufen. Datenbanken sind normalerweise auf Performance getrimmt, aber auch das Programm, das sie anspricht, muss mit diesen Datenmengen klarkommen. Auch Millionen von Datensätzen müssen klaglos ausgelesen, verarbeitet und gespeichert werden.

Fazit

Fassen wir einfach mal kurz zusammen, was eine Software für EAI, EDI oder ETL (oder alles zusammen) im Datenbankbereich bieten sollte:

  • Zugriff auf (annähernd) beliebige Datenbanken via ODBC und/oder JDBC
  • Einfache, schnelle Anbindung neuer Datenbanksysteme
  • Unkomplizierter Zugriff nicht nur auf die DB-Systeme, sondern auch auf die Tabellenstrukturen darin
  • Einfache Methoden sowohl zum Auslesen und Speichern größerer Datenmengen als auch für schnelle Lookups oder kleinere Insert-/Update-Statements, nicht zu vergessen zum Aufruf von Stored Procedures
  • Performante Bearbeitung auch wirklich großer Datenmassen
  • Die Fähigkeit, Daten aus verschiedenen Datenbanken zu sammeln und gemeinsam zu verarbeiten

Auch, wenn Sie in einem ersten Schritt noch nicht mit direktem Datenbank-Zugriff rechnen, achten Sie trotzdem bei der Auswahl eines Produktes darauf, dass es diesen Anforderungen genügt. Wenn Sie es nicht tun, und sich später eine solche Aufgabe ergibt, stehen Sie womöglich mit einem Fehlgriff da. Außerdem lassen sich Datenbanken manchmal ganz wunderbar als Hilfsmittel in EDI- und EAI-Prozessen nutzen, um die verarbeiteten Daten zwischenzuspeichern und sich danach – zum Beispiel mittels „order by“ sortiert – wiederzuholen.