estre schrieb:
Hallo zusammen,
ich möchte gerne Daten aus verschiedenen Datenbanksystemen (MSSQL, Oracle, etc.) rausziehen, miteinander verknüpfen und für meine Anwender über ein Frontend (z.B. Excel) zur Verfügung stellen.
Kennt jemand ein leichtgewichtiges BI-Tool (oder ähnliches) mit dem man sowas machen kann?
Ich habe es bereits mit Windows Tabular Model versucht, aber das gefällt mir irgendwie nicht so.
Habt ihr Vorschläge für ein Tool mit dem man sowas umsetzen kann?
Besten Dank!
Hier mal ein paar Ansätze. Es ist in der Regel auch eine Frage des Geldes.
Pentaho Suite
Als BI-Tool würde ich Pentaho vorschlagen. Die bieten das ganze auch in einer kostenlosen OpenSource Variante an (jedenfalls noch). Ob es dabei bleibt muss die Zukunft zeigen. Pentaho wurde vor 3 Jahren von Hitachi gekauft und seit Q3/2017 läuft Pentaho unter "Hitachi Vantara". Hitachi fasst darunter alles an Analysezeugs zusammen.
Die Pentaho Suite besteht aus verschiedenen Komponenten (Pentaho Data Integration auch unter dem Namen "Kettle" bekannt, Pentaho BI-Server, Pentaho Report Designer, etc.).
Grundsätzlich würde man die Daten aus verschiedenen Daten aus den verschiedenen Quellen zusammenführen (z.B. mit automatischen Importvorgängen in ein "Data Warehouse" (DWH)), um dann darauf die Auswertungen zu fahren.
Hier geht es zur OpenSource Version von Pentaho bzw. den einzelen Komponenten
https://sourceforge.net/projects/pentaho/
https://sourceforge.net/projects/mondrian/ <-- Mondrian ist ein In-Memory OLAP Server, an den man auch die verschiedenen anderen Datenquellen via JDBC (Java Datenbanktreiber) andocken kann.
Hier die kommerzielle Pentaho Version:
http://www.pentaho.com/
R Project
Alternativ kann man auch R installieren. Ein RStudio-Server ist auch eine schöne Sache. Damit bringt man die R-Konsole in den Browser und der Nutzer muss nichts installieren um damit zu arbeiten.
Es gibt auch eine Excel Add-On für R (RExcel) und Alternativen um auf die Daten zuzugreifen.
R ist quasi die Mutter alle Analysewerkzeuge. Es gibt einen Haufen Funktionen die R schon standardmäßig hat plus eine sehr große Zahl von Funktionen, die von anderen geschrieben und als installierbares Modul zur Verfügung gestellt werden.
Ich vermute aber das übersteigt die Fähigkeiten der Benutzer, es sei denn Du hast da Mathematiker und Datenanalysten als Endbenutzer...was ich stark bezweifle, da die Frage sonst vermutlich nicht hier im Forum erschienen wäre.
Ein Bild sagt mehr als tausend Worte...ich verweise auf das 2. Bild mit der Überschrift "If statistic programs/languages where cars"
http://www.win-vector.com/blog/2018/03/the-many-faces-of-r/
alternativ:
https://twitter.com/statsepi/status/795655917446561792
R-Project Webseite
https://www.r-project.org/
Excel und R
https://www.r-bloggers.com/a-million-ways-to-connect-r-and-excel/
https://de.wikipedia.org/wiki/RExcel
RStudio
https://www.rstudio.com/products/rstudio/
Tableau
Mit Tableau kann man relativ schnell etwas erreichen, aber es stellt sich die Frage was das Ziel ist.
Neben einem teuren Tableau Server gibt es noch Tableau Desktop. Ich vermute letzteres könnte etwas sein. Da kommt man recht schnell zu einem Ergebnis...schneller als bei anderen Varianten.
https://www.tableau.com/de-de
Kombinieren kann man die oben genannten Varianten mit PostgreSQL als zentraler Datenbank, die die Anfragen an die anderen weiterleitet. Noch besser wäre es aber man würde die Daten direkt in PostgreSQL vorhalten, so dass PostgreSQL nicht nur als Wrapper für alle anderen Datenquellen dient (wäre auch noch schneller).
PostgreSQL + Foreign Data Wrapper
Mit den PostgreSQL Foreign Data Wrappern (FDW) kann man andere Quellen anzapfen als wären die Daten in PostgreSQL Tabellen vorhanden. Das geht z.B. mit dem SQL Server via TDS Protokoll und auch dem genannten Oracle.
Bitte darauf achten das man auf dem SQL Server und auch Oracle nur User mit lesendem Zugriff anlegt. Wir wollen doch nicht, das hier jemand versehentlich Daten löscht oder andere Unfug treibt (das gilt für die vorherigen Varianten ebenfalls).
Es könnte auch sinnvoll sein statt "Excel" auf "OpenOffice/LibreOffice Calc" (gerne auch wieder mit der oben genannten zentralen PostgreSQL Datenbank) für die Auswertungen umzusteigen.
Hier kommt man nämlich mit einem einfachen JDBC-Datenbanktreiber (Java) aus und muss nicht den ganzen ODBC-Kram installieren und konfigurieren. Ich finde es jedenfalls mit dem JDBC-Treiber einfacher.
Wenn Visual Basic bei Excel im Spiel ist, ist dies vielleicht keine denkbare Variante.
Weitere Option...unterschiedliche Datenbanksysteme zu möglichst einem reduzieren
Wenn es möglich ist, die Datenbanken zu PostgreSQL zu migrieren dann sollte das in Angriff genommen werden. Im Falle von Oracle um die Lizenzkosten loszuwerden.
Hat man sich aber seine Seele an Oracle verkauft (ich sage nur "Oracle APEX" - ist so ein ich klicke mir meine Anwendung zusammen ähnlich Microsoft Lightswitch...wird es komplexer verflucht man sich später für diese Entscheidung
), dann wird das wohl eher nicht möglich sein.
Sollte es um den regelmäßigen Import von größeren Datenmengen gehen und die damit verbundenen Schreibperformance Engpässe gehen dann ist das natürlich ebenfalls ein guter Grund für einen Wechsel zu PostgreSQL (der SQL Server ist beim Schreiben von Daten gerne um den Faktor 8x mal langsamer als PostgreSQL (SQL Server 2014 zu PostgreSQL 9.4-10.1 - basierend auf eigenen Erfahrungen...ohne das ich die hier im Detail ausbreite; beim SQL-Server kann man noch ein paar Optionen setzen um das zu beschleunigen, aber bei vergleichbaren Einstellungen der Datenbank ist es wie beschrieben). MySQL (MariaDB) gilt auch als schnell, aber nachdem man bei MySQL ab 5.7.x nun auch alle Sicherheit-Features aktiviert um im Falle von MySQL relativ sicher zu sein das die Daten gespeichert sind (InnoDB plus einen Haufen Parameter wie strict SQL, fsync (Platte meldet über das Betriebssystem "ja die Daten wurden wirklich geschrieben", etc. statt z.B. dem alten MyISAM Backend (eine "Transaktion" was ist das denn?), verliert nun gegen PostgreSQL, das per Default seit jeher "(Daten)Sicherheit zuerst" in der Default-Konfiguration verankert hatte.
Beim lesen sind eigentlich alle schnell, es sei denn man verlässt sich auf "Hibernate" das gerne mal völlig unbrauchbare Abfragen generiert. Wenn es "optimiert" sein muss, weil es sich um komplexe Abfragen handelt, bitte selbst die SQL-Abfrage schreiben. Indizies bitte ebenfalls nicht vergessen. PostgreSQL kann auch hervorragend mit "partiellen Indizes umgehen" (Index mit einer WHERE-Abfrage). Auch die Volltextsuche/Indizierung nicht vergessen (GIST/GIN INDEX, die man mit Sprachen kombinieren kann "simple" verändert die Wörter nicht; "english"/"german" hingegen vereinfacht die Worte in der jeweiligen Sprache z.B. Mehrzahl zu einzahl, Stopwords, etc.).
PostgreSQL:
https://www.postgresql.org/
Übersicht über verschiedene existierende Foreign Data Wrapper für PostgreSQL:
Ich sage nur "Twitter API FDW"...musst selber mal testen ob der noch funktioniert (war eines der ersten Beispielimplementierungen).
https://wiki.postgresql.org/wiki/Foreign_data_wrappers
PostgreSQL zu MS SQL Server FDW:
https://github.com/tds-fdw/tds_fdw
PostgreSQL zu Oracle FDW:
https://github.com/laurenz/oracle_fdw
PostgreSQL zu anderen PostgreSQL Datenbanken u.a. auf dem gleichen PostgreSQL Server:
Das wird revant wenn man einen zentralen PostgreSQL Server für verschiedene Anwendungen betreibt die jede seine eigenen Datenanbank verwendet (OTRS-Helpdesk "otrsdb", Atlassian JIRA "jiradb", Atlassian Confluence "confluencedb").
Wenn ich nun identische Schlüssel z.B. in OTRS (Kundennummer) und JIRA Projekte in denen die Kundennummer hinterlegt ist (in einem CustomField), dann kann ich hier die Daten mit dem Schlüssel (Kundennummer) verbinden.
Hier gibt es zwei Optionen:
- postgresql_fdw - Die "neue" und zu empfehlende Methode (postgresql_fdw) wird seit PostgreSQL 9.3 (?) mitgeliefert.
- dblink - Die "alte" Methode wie man datenbankübergreifende Abfragen vornehmen kann. Wird mit PostgreSQL mitgeliefert.
https://www.postgresql.org/docs/current/static/postgres-fdw.html
So, das soll an dieser Stelle genügen. Ich habe mit allem schon zu tun gehabt bzw. nutze verschiedene Varianten oben.
Zentral ist bei mir immer eine PostgreSQL Datenbank. Wenn möglich, werden die verschiedenen Produkte (wie OTRS, Atlassian JIRA/Conflucene, etc.) oder unsere eigenen Produkte mit PostgreSQL als Datenbank installiert.
In der Firma bin ich gerade dabei einen Kunden vom SQL Server auf PostgreSQL umzustellen. Intern steht gerade das Andocken vom SQL Server via FDW an. Es geht um eine wichtige Datenauswertung und Zusammenführung mit Atlassian JIRA (Projekte/Projektforschritt). Die Daten werden über ein SQL-Add-On in Atlassian Confluence verwendet. Dort im Wiki gibt es eine "Seite" die nur aus einer komplexen SQL-Abfrage besteht und sich die Daten zur Anzeige über PostgreSQL aus dem SQL Server und eben aus PostgreSQL selbst holt.
Man kann auch schön mit dem Confluence Chart Plugin und darin eingebetteter SQL-Abfrage Charts generieren (das habe ich z.B. für die Erstellung von Montatsstatistiken über 3-Jahre und Wochenstatistiken über ein Jahr im Einsatz). Damit wird gezeigt in welchen Bearbeitungsqueues die Abteilungen wie viele Tickets in den genannten Zeiträumen bearbeiten. Steigt dies also über einen Zeitraum X kontinuierlich an, ist ggf. eine weitere Person im Support nötig, damit der Workload besser verteilt wird.
Die Möglichkeiten sind im Grunde grenzenlos...
Ich hoffe mit den Ausführungen den einen oder anderen relevanten Hinweis gegeben zu haben.
