Excel durch einen Datenbank-Generator mit Low-Code in der Cloud ersetzen

Tabellenkalkulationsprogramme spielen in den meisten Unternehmen nach wie vor eine große Rolle – und sie werden dort für Aufgaben genutzt, für die es heute bessere Werkzeuge gibt. Ist es klug, unternehmenskritische Daten in Excel & Co. zu halten statt in einer Datenbank? Auf welche Leistungsmerkmale muss man verzichten, wenn man Geschäftsprozesse auf einer Tabellenkalkulation digitalisiert statt mit einem dafür ausgelegten No-Code- und Low-Code-Tool in der Cloud? Der webbasierte Datenbank-Generator als Unternehmens-App ist die Alternative zur Tabellenkalkulation.

Lesezeit: ca. 14 Minuten

Der Industriestandard „Tabellenkalkulation“

capterra1

Bilder: Capterra. Nutzerstudie: CRM Software Trends 2019 in deutschen KMUNutzerstudie 2018: Wie Projektmanagement-Software in Deutschland genutzt wird

Excel, OpenOffice und Google Spreadsheets allüberall

Ich muß hier sicherlich niemandem Funktionsweise und Vorzüge einer Tabellenkalkulation näherbringen, wie sie 1979 mit VisiCalc das Licht der Welt erblickte, sich mit Lotus und Quattro Pro weiterentwickelte und schließlich mit Microsoft Excel als Killer-App in allen Arten von Unternehmen allgegenwärtig wurde. Mit OpenOffice liegt eine starke Open-Source-Alternative vor, und Google Spreadsheets brachte das Konzept in den Web-Browser, wohin OpenOffice mit Collabora und Microsoft mit 365 folgten.

Tabellarische Daten mit einfachen Formeln ohne Programmierkenntnisse berechnen zu können, erst recht, wenn man noch Diagramme, Makros und Visual-Basic-Programmierung hinzunimmt, macht die Tabellenkalkulation zu einem mächtigen und universellen Werkzeug mit niedriger Eintrittsbarriere. Scheinbar alles, was mit Daten zu tun hat, läßt sich in der Tabellenkalkulation so einfach und schnell wie möglich umsetzen.

Einsatzbereiche der Tabellenkalkulation

Probleme, die unzählige Unternehmen mit Excel & Co. lösen:

  • Daten speichern – Adressen, Preise, Mengen, Datums- und Zeitangaben, Informationen in Textform und vieles mehr, oft in Form von Datensätzen, d.h. einem festen Schema in Zeilen mit jeweils Preis (Dezimalzahl) eines Artikels (Name als Text) zu einem bestimmten Zeitpunkt (Datum).
  • Daten analysieren – auf der Grundlage in Tabellen eingetragener Daten Berechnungen anstellen – mit Formeln Zahlen in alle erdenklichen Berechnungen einfließen lassen.
  • Daten visualisieren – Rohdaten oder berechnete Zahlen lassen sich komfortabel graphisch darstellen.
  • Geschäftsprozesse abbilden – nicht nur Planungsrechnungen und Nachkalkulation, sondern auch ERP, Projektmanagement, Personalwesen: die Erkenntnis, daß Datensatz-Listen mit Zahlen, Datumsangaben und Text sich zur Abbildung praktisch aller Prozesse im Unternehmen eignen, führt dazu, daß dies auch getan wird. Sind nicht Kunden- und Mitarbeiterverzeichnisse, Aufgaben eines Teams, Artikel im Sortiment und deren Lagerbestände allesamt tabellarisch gut darstellbar? Und wenn ich auch noch jede erdenkliche Berechnung damit anstellen kann: wieso nicht dem ganzen Betrieb ein digitales Abbild in Excel geben?

Resultat: Daten werden in etlichen kreuz und quer verknüpften Excel-Tabellen gespeichert, verwaltet und organisiert. Automatisierung wird durch Makros und Visual Basic implementiert. Laut Forrester Q2 2021 Global Digital Process Automation Vision Survey ist „die brutale Realität“, daß es in praktisch allen Unternehmen noch Geschäftsprozesse per „Electronic manual routing“ gibt, d.h. mit geteilten Excel-Dateien, Email etc., die zwar in elektronischer Form erfolgen, aber nicht im engeren Sinne digitalisiert sind. Nur 1% der befragten Unternehmen hatten angegeben, dies gar nicht mehr zu tun, knapp die Hälfte, daß in ihrem Unternehmen „viele“ Prozesse noch auf Excel, Email & Co. beruhen, und ein Viertel, daß es gar „die meisten“ Prozesse sind.

Schwachpunkte der Tabellenkalkulation

Hier lauern Probleme, wenn Geschäftsprozesse mit Excel abgebildet werden sollen:

Schwer leserliche verschachtelte Formel in Excel
  • Verständlichkeit der Formeln – der Verzicht auf Absätze und gar auf Leerzeichen in Kombination mit vielen Zellbezügen (bei denen man erst nachsehen muß, was in der Zelle überhaupt steht) und nur wenigen fixen Namensbezügen (bei denen man, wie in der Programmierung eigentlich Standard, eine Information über den Inhalt in die Namensgebung einfließen läßt) macht die Formeln schwer lesbar und schwer wartbar.
  • Schutz der Programmierungsschicht – es ist ja gerade die Stärke von Excel, daß man einfach in eine Zelle klicken kann und eine Formel ändern. Dies ermutigt jedoch schlechte Programmierpraxis und eröffnet Fehlerpotential, indem ein u.U. versehentlicher Klick in ein Formelfeld zu Fehlern in einer einzigen Zelle führen kann, während alle anderen noch korrekt sind, ohne daß der Fehler auffällt. Dasselbe passiert, wenn Formeln herunterkopiert werden, aber nicht weit genug. D.h. es kann inkonsistente Formeln in einer einheitlich aussehenden Spalte geben, ohne daß man dies bemerkt, was schlimm ist, wenn Formeln ab Zeile x einfach fehlen, aber noch schlimmer, wenn korrigierte Formeln im Zuge der Entwicklung oder des Bug-Fixing nur bis Zeile x kopiert sind, aber dann vergessen wird, abschließend die ganze Spalte zu aktualisieren.
  • DRY: Don't repeat yourself – in der zentralen Excel-Praxis, Formeln in einer Spalte herunterzukopieren, manifestiert sich ein Verstoß gegen dieses Grundprinzip der Programmierung. Die Formel, mit der z.B. die Summe zweier Spalten errechnet wird, steht in jeder Zelle der Ergebniszeile erneut, lediglich mit um 1 erhöhten Zeilen-Indizes. Man wiederholt sich am laufenden Band. Die zahlreichen Zellbezüge führen dazu, daß ein mal fertiggestellte Rechenwege nicht mehr angetastet werden, auch wenn man nachher merkt, daß es auch besser gegangen wäre. Änderungen sind durch die Verteilung einer Berechnung auf viele Zellen wesentlich aufwendiger sind als die Änderung einer Funktion, die nur an einer Stelle definiert ist und x-fach benutzt wird.
  • Kopplung von Berechnung und Formatierung – der Widerstand, ein mal Programmiertes einer grundlegenden Revision zu unterziehen, wird noch dadurch verstärkt, daß ja zugleich die Formatierung an den Zellen hängt. Auch dies ist ja eine zugleich eine Stärke von Excel, jedenfalls für eine aus der Hüfte geschossene Ad-hoc-Berechnung. Für ein planvoll angelegtes und langfristig weiterzuentwickelndes System ist das ein Scheingewinn. Schnell geschrieben, langsam geändert. Provisorisch hält am längsten.
  • Information in einem System – die Verteilung von Daten auf einzelne Dateien statt der Ablage in einem allumfassenden, konsistenten und verbundenen System stellt den Nutzer vor die Herausforderung, gesuchte Daten zu finden. Geschickt eingerichtet, kann dies durch ein streng einzuhaltendes Schema von Dateiordnern und Dateinamenskonventionen erleichtert werden. Die Herausforderung wächst, wenn die Datei-Zuständigkeit auf mehrere Benutzer oder gar auf verschiedene lokale Rechner/Ordnerstrukturen/GDrive-Konten verstreut ist. Die zersplitterten Informationen manuell zu zusammenzuführen, ggf. turnusgemäß, macht viel Arbeit und ist fehleranfällig. Die zersplitterten Informationen durch dateiübergreifend verknüpfte Formeln zusammenzuführen ist auch bei strenger Disziplin aller Beteiligten (Dateien nicht verschieben oder umbenennen! Zellbezüge nicht verändern!) eine wackelige Angelegenheit.
  • Mehrbenutzerfähigkeit – bearbeitet jemand eine Tabellendatei auf seinem Rechner, und jemand anderes tut das gleichzeitig auch, entstehen abweichende Versionen. Das paßt nicht mehr mit dem heutigen Arbeitsstil zusammen: Mitarbeiter sollen gemeinsam an denselben Daten arbeiten, und Benutzer sollen von überall auf die Softwarelösung zugreifen können. Dieses Problem wird durch Online-Spreadsheets aus dem Weg geräumt, aber auch hier sehen alle Nutzer immer alle Daten: man kann nicht Nutzern verschiedener Rollen nur die Daten zeigen, die sie gerade benötigen.
  • Dokumentation – Änderungen überschreiben schlicht den vorherigen Stand, so daß die vorherige Version verloren ist, wenn niemand mehr eine Kopie hat. Dieses Problem adressiert z.B. Google Spreadsheets mit seiner Versionsgeschichte. Doch auch hier gibt es durch das Fehlen von Rollen kein Protokoll von Änderungen pro Benutzer. Nachvollziehbarkeit, Transparenz und Revidierbarkeit sind jedoch für viele Geschäftsprozesse eine wichtige Anforderung.
  • Parallelprozesse – dieselbe komplexe Berechnung für viele analoge Anwendungsfälle: Datei klonen? Dies resultiert in Versionschaos, und jede Verbesserung und jeder Bugfix muß in jeder einzelnen Datei (oder gar Set von Dateien) manuell eingepflegt werden. Die Alternative, eine gigantische Datei für alle zu nutzen, stößt nicht nur wegen der Performance, sondern auch wegen fehlender Mehrbenutzerfähigkeit schnell an Grenzen.
  • Performance – je größer die Datenmenge, um so langsamer wird alles. Diesem Problem läßt sich auch mit einem schnelleren Rechner nicht beikommen, denn bauartbedingt lädt Excel die gesamte Datei und damit den gesamten Datenbestand in den Hauptspeicher (während ein Datenbanksystem immer nur die unmittelbar benötigten Daten lädt, siehe unten).
  • Skalierbarkeit – nicht nur große Datenmengen begrenzen das Wachstum, sondern auch Komplexität. Diese läßt sich wegen der „freien“ Verknüpfung durch Formeln, die in Zellen „versteckt“ sind, d.h. nur sichtbar, wenn man diese direkt anklickt, und die daher nur schwer und ad hoc testbar sind, wesentlich schlechter beherrschen als mit Verknüpfungen, die einem abstrakten Schema folgen, und einer vom Datenmodell strikt getrennten Geschäftslogik. Zugegeben: wer sehr diszipliniert ist und auf hohem Abstraktionsniveau arbeitet, kann das mit „seinem“ Excel auch schaffen. Gut merken sollte man sich aber, daß eine .xlsx-Datei maximal 1.048.576 Zeilen und 16.384 Spalten haben kann – sonst erlebt man vielleicht so etwas: Excel: Why using Microsoft's tool caused Covid-19 results to be lost.
  • Sicherheit – Tabellendateien sind ein Sicherheitsrisiko: sie sind schnell mal aus Versehen an jemanden vermailt, für dessen Augen sie nicht gedacht waren. „Reply to all“. Ein Link zu einer Tabelle in der Cloud erfordert immer noch einen Login, ggf. mit Zwei-Faktor-Authentifizierung.
  • Qualifikation der „Excel-Programmierer“ – gerade weil die Tabellenkalkulation so eine geringe Einstiegshürde hat und jeder einfach loslegen kann, laborieren viele Sheets, die tragende Säulen der Datenhaltung und Prozesse in Unternehmen sind, auf bedenklichem Niveau.

Kurzum: Tabellenkalkulationen sind schnell geschrieben, aber je mehr Daten, Benutzer, Parallelprozesse, Dokumentations- und Sicherheits-Anforderungen, vor allem je mehr Komplexität und je mehr Bugs hinzukommen, desto fragiler und wartungsintensiver wird das Ganze. Aber deswegen den Mitarbeitern ihre heiligen Excel-Tabellen wegnehmen?

„Unternehmenskritische Daten in Excel zu halten und unternehmenskritische Prozesse in Excel ablaufen zu lassen ist wie eine OP, während der der Patient ganz normal weiterarbeitet. Als Dauerzustand.“

Die Alternative „Relationale Datenbank“

Eine Datenbank, kurz DB, kann (große) Datenmengen effizient, widerspruchsfrei und dauerhaft speichern. Wie im vorangegangenen Abschnitt deutlich geworden ist, verfügt die Tabellenkalkulation nicht über die Mittel, widerspruchsfreie Daten zu garantieren und ist nur bei kleinen Datenmengen effizient. „Echte“ Datenbanksysteme lösen diese Probleme.

Dies sind, grob gesagt, die Einschränkungen einer Datenbank im Vergleich zu einer Tabellenkalkulation:

  • Es ist „nur noch“ eine Datenbank – Jede Spalte hat einen Namen und enthält nur Daten desselben, für die jeweilige Spalte festgelegten Datentyps (nur Datum oder Ganzzahl oder...), und das wird vorab definiert. Also nichts mit mal eben eine Nebenrechnung im Spreadsheet machen oder im Tabellenkopf für den Ausdruck Meta-Informationen eintragen. In der ersten Zeile befinden sich die Spaltenköpfe, keine Ausnahme möglich.
  • Erst abfragen, dann rechnen, visualisieren etc. – bevor man eine Berechnung durchführen kann, müssen die Daten dafür erst aus der DB abgefragt werden. Auch deshalb nicht mal eben eine Nebenrechnung (es sei denn, man spricht fließend SQL). Noch weniger als Berechnungen gehört das Anzeigen von Daten in Diagrammen zum Leistungsumfang einer Datenbank!
Datenmodell als Entity-Relationship-Diagramm (ER-Diagramm)

Dies sind demgegenüber die Fähigkeiten, die die Datenbank der Tabellenkalkulation voraus hat:

  • Relationen – dieses Feature ist so wichtig, daß es namensgebend für den etablierten Standard von Datenbanksystemen ist. Eine Tabellenspalte einer DB kann eine Relation, eine Beziehung, eine Verbindung, eine Verknüpfung, einen „Schlüssel“ zu Einträgen einer anderen Tabelle enthalten. Wenn man bei einer Bestellung den Kunden auswählt, trägt man nicht wie in der Tabellenkalkulation schlicht den Namen des Kunden ein, sondern man wählt den passenden Eintrag in der Kundendatenbank aus. Dadurch gibt es kein Vertippen oder abweichende Schreibweisen mehr. Zudem können bei Datenbankabfragen aus beiden Richtungen auch Informationen verbundener Einträge mit ausgelesen werden, also etwa die Kunden-Postleitzahlen aller Bestellungen oder alle Bestellungen eines Kunden. So lassen sich die Daten hervorragend strukturieren. Das Excel/Spreadsheet-Problem der Zersplitterung von Information ist auf äußerst systematische Weise gelöst. In Summe bilden die Tabellen mit ihren Relationen das Datenmodell, auf dem die Unternehmensprozesse ablaufen – dieses zu analysieren, oder überhaupt einmal hinzuschreiben, und bei der Gelegenheit zu verbessern ist allein Grund genug, eine DB einzuführen!
  • Saubere Trennung zwischen Datenspeicherung und Anwendung – die Flexibilität von Excel ist für nach einem festen Schema strukturierte Daten und wiederholt ablaufende Geschäftsprozesse, für die die Einhaltung von Standards wichtig ist, eher ein Nachteil. Eine DB wird abgefragt, und dann werden diese Daten in die Geschäftslogik eingespeist, um das Ergebnis schließlich wieder in die DB abzulegen, und an jeder dieser Schnittstellen können Eingaben und Ergebnisse validiert werden und Compliance gesichert. Eine Berechnung wird für alle Datensätze identisch ausgeführt, garantiert! Das DRY-Prinzip („Don't repeat yourself“) kann eingehalten werden. Hier zahlt sich auch der eventuell höhere Aufwand beim Aufbau des Systems aus: statt der Verquickung von Datenspeicherung, Berechnung und sogar Formatierung in der Tabellenkalkulation kann hier an jeder „Schicht“ separat gearbeitet werden. Modularisierung.
  • Verständlichkeit der Programmierung – auch wenn man hier spontan widersprechen möche – Excel-Formeln sind doch einfach, aber eine Programmiersprache ist kompliziert! –, ist doch das obige Beispiel
  • Datentypen – die erste Einschränkung „nur noch DB“, der gemäß man in einer Spalte nur Daten eines vorher definierten Typs eintragen kann, ist ein wichtiges zur Datenkonsistenz beitragendes Leistungsmerkmal: in eine Datumsspalte können nur gültige Datumswerte eingetragen werden; andere Datentypen wie Text oder eine Fließkomma-Zahl werden nicht akzeptiert.
  • Abfragen – oben schon als zweite Einschränkung vorgestellt, sind die Abfragen zugleich ein mächtiges Werkzeug. Sie sind nicht nur die Grundlage dafür, daß wesentlich größere Datenmengen mit sehr guter Performance bearbeitet werden können, denn es werden eben nur die benötigten Daten geladen. Mit der Datenbankabfrage oder „query“ kann bereits all das sehr konzise geleistet werden, was man in der Tabellenkalkulation mit Filtern, Pivot-Tabellen, XVERWEIS (früher SVERWEIS) und INDEX unter Beugung und Dehnung dessen, wofür Excel eigentlich mal gedacht war, auf schwer nachvollziehbare und schwer wartbare Weise hinbastelt.
  • Redundanzfreiheit – wenn eine Kundennummer oder eine Adresse nur ein mal vorkommen kann, setzt man das entsprechende Feld auf „unique“, und damit ist es nicht mehr möglich, ein Duplikat anzulegen (es sei denn mit unterschiedlichen Schreibweisen...).
  • Versionen und Verlaufsdokumentation – alle modernen DB-Systeme eignen sich für automatisierte Backups, ermöglichen das Zurückspielen alter Datenstände, auch in Teilen, und eine Verlaufsdokumentation besteht letztlich nur aus weiteren Tabellen, in denen Änderungen protokolliert werden, d.h. ist gut machbar.

Bis vor nicht allzu langer Zeit war, wer eine relationale DB wollte, vor die Wahl zwischen einer lokalen Installation z.B. von Microsoft Access (über dessen gravierende Schwächen bezüglich Anpassbarkeit, Mehrnutzerfähigkeit und Zugriff von extern oder gar mobil wir hier gnadenhalber schweigen wollen) oder dem aufwendigen Betrieb eines Webservers und der Entwicklung einer auf diese zugreifenden Anwendungssoftware gestellt. Die Lage hat sich mittlerweile deutlich gebessert, wie im folgenden Abschnitt offenbar wird.

No-Code/Low-Code-Datenbank-Generator in der Cloud

Es ist mittlerweile möglich, webbasierte Datenbank-Apps mit einem Datenbank-Generator bzw. DB-Builder zu erstellen. Diese werden in der Regel als Software-as-a-Service (SaaS) in der Cloud bereitgestellt. Mit solchen DB-zentrierten App-Buildern geht das, wenn man die im Vergleich zu Excel auch nicht heftigere Lernkurve hinter sich gebracht hat, durchaus ähnlich schnell wie eine Entwicklung mit Excel! In der Konzeption etwas anspruchsvoller, Stichwort „Datenmodell“, aber durch die „erzwungene Stringenz“ hinterher leichter erweiter- und wartbar.

Wie in einem Website-Builder, bloß nicht für Layout-Elemente, sondern eben für Datenstrukturen: in No-Code-Manier werden per Drag & Drop Datenspalten hinzugefügt, sei es Text-, Zahlen-, Datums-, und sonstige Datenfelder. Unter den Feldtypen gibt es zwei besondere: Relations- und Berechnungsfelder. Fügt man ein Relationsfeld hinzu, kommt die Frage, mit welcher anderen Datentabelle. Man wählt eine aus, und fertig ist die Verbindung! Fügt man ein Berechnungsfeld hinzu, kann darin mit Formeln gearbeitet werden, das fällt dann unter das Stichwort „Low-Code“. 

Mehr dazu: unser White-Paper Digitale Geschäftsprozesse mit No Code, Low Code, Pro Code

No-Code-DB-Builder mit Drag&Drop, Low-Code-Berechnungsfelder in Citrix Podio

Dies sind die Vorteile, die sich bei einer Cloud-DB im Vergleich zu Excel ergeben:

  • Schutz der Programmierungsschicht – die meisten DB-Builder haben eine Benutzeroberfläche für die Anwendung und eine andere Benutzeroberfläche für die Einrichtung, also für die No-Code- und Low-Code-Programmierung. Der Wechsel ist meist deutlich markiert und in der Regel auf bestimmte Benutzer(gruppen) eingeschränkt. Andere DB-Builder verfolgen hier eher einen Excel-Ansatz einer einheitlichen Benutzeroberfläche. Aber alle sind natürlich dem Prinzip treu, daß eine Spalte einen Titel und einen Datentyp hat, der sich im Verlauf der Tabelle nicht ändern kann! Das allein ist ein die Konsistenz wesentlich absicherndes Merkmal.
  • Mehrbenutzerfähigkeit – dies ist, wenig überraschend, ein zentrales Leistungsmerkmal aller Cloud-Lösungen: gemeinsam an denselben Daten zu arbeiten, ob am Rechner oder mobil, ohne Sorge haben zu müssen, etwas „kaputtzumachen“, ist Standard. Das Konzept einer gefilterten Ansicht, das auch sehr verbreitet ist, ermöglicht es, Nutzern verschiedener Rollen nur die Daten zu zeigen, die sie gerade benötigen.
  • Dokumentation – je mehr ein Anbieter in Richtung KMU oder gar Industrie ausgerichtet ist, um so mehr sind Änderungen inklusive „Täter“ protokolliert.
  • Parallelprozesse – dieses Problem stellt sich bei Verwendung einer relationalen Datenbank systembedingt nicht; Werte werden einzeln überschrieben. Wer zuletzt schreibt, bleibt.
  • Performance, Skalierbarkeit – der Vorteil, nur die Daten auszulesen, mit denen man arbeiten möchte, relativiert sich durch das Online-Merkmal, denn so schnell der Lesevorgang aus der DB auch gehen mag, die Daten müssen ja immer noch über das Netz übermittelt werden! Dieses Manko schlägt jedoch nur zu, wenn man große Mengen roher Daten tatsächlich auf dem Bildschirm sehen möchte, nicht jedoch für Berechnungen – denn die finden ja in der Cloud des Anbieters statt, und die kann sehr schnell sein.
  • Sicherheit – alle Anbieter verlangen einen Login, viele ermöglichen Zweifaktor-Authentifizierung, so daß dort ein Standard vorgelegt wird, den man mit Dateien auf lokalen Rechnern nur schwer wird erreichen können (Excel-Fans entgegnen hier, daß eine Datei auf einem lokalen Rechner doch sicherer sei als ein öffentlicher Server, aber hier gebe ich zurück, daß das größte Sicherheitsrisiko bei Dateien nicht technischer Natur ist, sondern der Mensch, der die Datei mit anderen teilt). Erwähnenswert ist an dieser Stelle sicherlich, daß einige namhafte Anbieter ihren Sitz im EU-Ausland haben. Bei solchen Anbietern ist z.B. die DSGVO-Konformität zu prüfen und zu überlegen, ob es für das eigenen Unternehmen ein Problem darstellen könnte, daß die jeweiligen Landesgesetze (USA!) dem Staat dort viel weitreichendere Möglichkeiten des Zugriffs geben als hierzulande.
  • Triggern von Aktionen – hier kommt ein Punkt hinzu, den eine reine Datenbank nicht abdeckt (d.h. in der Anwendungs-Schicht eigens zu programmieren wäre), aber der in den meisten Cloud-Datenbanken großen Raum einnimmt: Benutzereingaben führen nicht nur, wie in der Tabellenkalkulation, zur Neuberechnung von Werten in anderen Zellen, sondern können auch einen Ablauf anstoßen. Dies kann z.B. die Erstellung einer Aufgabe sein, etwa durch Klick auf einen Button oder das Erreichen eines Wiedervorlagedatums.
  • Schnittstelle/API – während genau wie Cloud-Datenbanken auch Cloud-Spreadsheets regelmäßig über eine Webschnittstelle verfügen (mit [Microsoft Graph](https://developer.microsoft.com/de-de/graph) auch Office 365), ist die Lage bei lokalen Excel-Dateien etwas unübersichtlicher: mit mit Power Query kann Excel Daten von externen APIs konsumieren, z.B. Wetterdaten von openweathermap.org oder Daten des eigenen Online-Shops. Aber Daten vollautomatisch aus lokalem Excel herauszubekommen, ist nicht trivial. Anbieter wie xlwings bauen hier Brücken, aber die Eleganz und Robustheit einer für Datenaustausch ausgelegten Lösung wird man wohl kaum erreichen.
  • Künstliche Intelligenz, Maschinelles Lernen – ähnlich wie beim Thema API gibt es hier seit kurzem z.B. in Form des Excel-Add-ins [Azure Machine Learning](https://appsource.microsoft.com/en/product/office/WA104379638?tab=Overview) und schon länger bei Google Spreadsheet per Verbindung mit dem reichhaltigen und weltweit führenden Ökosystem von Cloud-Apps zu KI durchaus Möglichkeiten. Viele Cloud-DBen müßte man über API an KI-Dienste anbinden, was eher mehr Aufwand macht als bei Excel & Co. Jedoch haben einige Cloud-DB-Builder das Thema im Fokus und bieten hier einen deutlich leichteren Einstieg.

Kurzum: die neuen Tools nehmen dem Aufbau eines Datenmodells einer relationalen Datenbank mit No-Code den Schrecken, sie ersetzen den Zellbezugs- und Berechnungsteil von Excel-Formeln durch besser geschützten Low-Code (der übrigens regelmäßig viel besser lesbar ist als die verschachtelten Excel-Formeln!), und machen das Ganze als Web-App mit fertiger Benutzeroberfläche verfügbar.

Das alles lernt man nicht über Nacht, aber es ist keinesfalls schwieriger als Excel! Man wird bei der architektonischen Konzeption auf professionelle Unterstützung nicht verzichten wollen, aber eine leistungsfähige Excel-Lösung ist in dieser Hinsicht nicht weniger anspruchsvoll: es kommt einem nur später in den Sinn, daß man dilettiert an einer Stelle, an der Qualität wichtig wäre. Bei komplexeren Anforderungen stößt man mit Excel früher als bei guten DB-Buildern an Grenzen, die man allein nicht überwinden kann.

Welche DB-Builder-App ist die richtige?

Die Phase, in der wenige Pioniere das Thema angehen, ist mittlerweile übergegangen in eine, in der sich einzelne Paradigmen herauskristallisieren und mehrere Anbieter ihr Produkt ins Rennen schicken. Es würde den Rahmen dieses ohnehin schon sehr, sehr langen Artikels sprengen, hier einen Marktüberblick zu versuchen; dazu später mehr!

Hier also lediglich eine grobe Einteilung. Alle relevanten Produkte fallen in die Klasse der Low Code Applications Plattform (LCAP), also SaaS, die über grundlegende Funktionen zum Entwurf webbasierter Oberflächen sowie über Werkzeuge zum Datenmanagement verfügt.

Nur Listenansicht

Datenbank in Notion

Die klassische Ansicht für Datenbank-Daten ist dieselbe wie die in Excel: eine Liste in Form einer Tabelle mit den Datensätzen in Zeilen und den Feldern in Spalten. Anbieter wie Airtable und Rows, aber auch etwa die Datenbank-Funktion von Notion, setzen auf Einfachheit und bauen die gesamte App-Nutzung um die Listenansicht herum auf.

Verschiedene Ansichten im Standard-Layout (Liste, Formular, Karten, Kanban...)

Kanban-Board-Ansicht bei Citrix Podio

Die meisten Anbieter nutzen für ihre Cloud-App auch andere Ansichten, wie sie, ermuntert durch die Trennung der Datenabfrage von der Datendarstellung, auch in der Vor-Cloud-Zeit bereits in datenbankbasierter Individualsoftware Gang und Gäbe sind. Einschlägige Anbieter sind, ohne Anspruch auf Vollständigkeit und in alphabetischer Reihenfolge, 4D, Caspio, dashjoin, datenbanken24, Honeycode (amazon), kintone, Knack, Ninox, APEX (Oracle), Podio (Citrix), Quickbase, Scopeland, SeaTable, Smartsheet, Zoho Creator. Im nächsten Abschnitt „App-Builder“ tauchen weitere auf, denen keine DB-Features fehlen, sondern die noch andere gewichtige Features haben, so daß der DB-Builder nicht mehr das zentrale Feature ist.

Google AppSheet nimmt einen Sonderstatus ein: die Daten und Kalkulation können in Spreadsheets oder Excel 365 liegen; dann fällt jedoch die „disziplinierende“ Wirkung der Datenbank weg, also die technisch erzwungene Regelkonformität. Doch AppSheet kann auch strukturierte Daten aus einer SQL-Datenbank verarbeiten – die Datenbankstruktur muß jedoch dort traditionell, ohne No-Code, definiert werden, und aus SmartSheet. Das heißt: AppSheet selbst ist gar kein DB-Builder. Zudem sind die Low-Code-Möglichkeiten begrenzt, sofern man nicht auch noch Google Apps Script mit in den Werkzeugkasten nimmt.

Zusätzlich mit frei gestaltbarer Benutzeroberfläche

„Vollwertige“ App-Builder im engeren Sinne Plattformen wie Bubble.io, die auf Startups zielen, die mit einer Web-App an den Markt gehen wollen, und solche wie Outsystems, Appian und Mendix (Siemens), die vor allem die Industrie targetieren, d.h. von einer sehr hohen Nutzerzahl und großen Entwicklungs-Budgets ausgehen, geben sich mit einer nicht gemäß Webdesign-Vorstellungen frei gestaltbaren Oberfläche für den Endbenutzer zufrieden. Für diese Zielgruppen reicht ein Standard-Frontend mit vorgegebenen Bausteinen, die hin- und hergeschoben und höchstens noch in ihrer Größe angepaßt werden können, nicht aus.

Frontend-Builder von Bubble.io

Jeder App-Builder enthält technisch gesehen einen Datenbank-Builder, denn eine App ohne Daten wäre nutzlos, und die Daten wollen strukturiert abgelegt werden – und zwar gemäß eines den Funktionen der App dienenden Datenmodells. Demnach ist ein anpassbares Datenmodell auch hier Pflicht-Feature. Diese App-Builder sind dann jedoch nicht mehr „datenzentriert“, d.h. die DB wird zu einer Schicht neben anderen zu gestaltenden Schichten. Komfort der DB-Einrichtung und freie Konfigurierbarkeit des Datenmodells rücken ggf. in den Hintergrund, wenn auch viele der Apps in dieser Kategorie den DB-zentrierten Apps in nichts nachstehen. Jedoch kann man nicht nur, man muß die Benutzeroberfläche gestalten. Für viele interne Geschäftsanwendungen ist das überflüssige Arbeit.

Abgrenzung: dies sind keine Datenbank-Generatoren

Website-Builder

Der Vollständigkeit seien hier auch noch die Website-Builder wie Webflow, Wix, Jimdo, Squarespace etc. eingeordnet: auch diese verfügen natürlich über eine DB, aber hier ist, mindestens bei denen für Endverbraucher, gar kein „Custom Data Model“ möglich, d.h. es gibt keinen DB-Builder, sondern ein vorgegebenes, eben ein für Standard-Webseiten für optimal befundenes, Datenmodell. Hier liegt die Betonung auf der der Anpaßbarkeit der Benutzeroberfläche. Wix & Co. machen es dem Bediener möglichst einfach; Webflow & Co. sind anspruchsvoller in der Bedienung und betonen die Möglichkeit, Webdesign pixelgenau umzusetzen.

Cloud-ERP, -CRM, -PM, -HR

Nicht zu verwechseln: ein DB-Builder ist, genau wie die Tabellenkalkulation, völlig offen für alle erdenklichen Datenmodelle und Geschäftsprozesse, während Cloud-Anbieter von Standardsoftware für Unternehmen keine frei konfigurierbare Plattformen anbieten. Vielmehr ist in Cloud-Software für ERP (SAP S/4HANA, Oracle NetSuite, Bitrix24) , CRM (Salesforce, Hubspot, Mailchimp), PM (Trello, Basecamp, JIRA, Asana) das Datenmodell und die Abläufe durch den Softwarehersteller weitestgehend vorgegeben. Mit einem Datenbank-Generator erstellen Sie hingegen, genau wie mit der Tabellenkalkulation, Ihre eigene Individualsoftware, die genau auf Ihr Unternehmen zugeschnitten ist.

Database as a Service (DBaaS)

Amazon AWS, Google Cloud SQL, Microsoft Azure Cloud und ähnliche Dienste bieten eine Cloud-Datenbank – aber keinen Datenbank-Builder! Hier wird eine „nackte“ MySQL-, PostgreSQL- oder sonstige gängige Datenbank als Cloud-Lösung angeboten, d.h. hier wird lediglich die Cloud-Infrastruktur genutzt, statt die selbe DB auf einem eigenen Server einzurichten und zu hosten.

Fazit / Executive Summary

Gute Bedienbarkeit, vorhandenes (wenngleich oft gar nicht so tiefes) Excel-Wissen, vorhandene Lizenz und die besonders im Bereich Datenvisualisierung leistungsfähigen Features sichern der Tabellenkalkulation einen bleibenden Platz im Unternehmen. Speziell im Bereich Business Intelligence, also in der Auswertung betrieblicher Daten, gibt es Excel-Virtuosen, die die Latte für gleichwertige DB-basierte Lösungen ziemlich hoch legen, vor allem in Sachen Umsetzungsgeschwindigkeit. Da hier i.d.R. nur wenige bis ein Nutzer an den Tabellen arbeitet, fallen hier Excel-Nachteile nicht so ins Gewicht. Dennoch wird jedes komplexere Rechenwerk im Vergleich tendenziell als „Bastellösung“ dastehen.

Das Rollen- und Rechtemanagement, der zeitgleiche Lese- und Schreibevorgang für mehrere Anwender, die Skalierbarkeit und Eignung für große Datenmengen, die Sicherung von Datenqualität durch Unterbindung von Falscheingaben, die explizite Darstellung einer komplexen Datenstruktur im Datenmodell, die Versionierung und automatische Datensicherung, die Integrationsmöglichkeit durch Schnittstellen und das Einbeziehen von Aktionen bzw. Workflows und ggf. KI/ML sind starke Argumente, für die Datenhaltung und die Digitalisierung von Geschäftsprozessen nicht die Tabellenkalkulation zu strapazieren, sondern auf eine solide DB-Lösung zu setzen.

Updates direkt in Ihr Postfach

Tragen Sie Ihre E-Mail ein und erhalten Sie wöchentlich unseren Newsletter. Kostenlos und jederzeit abbestellbar.
Ihre Daten sind sicher. Hier ist unsere Datenschutzerklärung.

Noch keine Kommentare vorhanden

Was denken Sie?

Beliebte Artikel

Excel durch einen Datenbank-Generator mit Low-Code in der Cloud ersetzen

Excel durch einen Datenbank-Generator mit Low-Code in der Cloud ersetzen

Tabellenkalkulationsprogramme spielen in den meisten Unternehmen nach wie vor eine große Rolle – und sie werden dort für Aufgaben genutzt, für ...
Weiterlesen
Drupal 7 Migration White Paper veröffentlicht

Drupal 7 Migration White Paper veröffentlicht

Wir haben heute unser erstes White Paper veröffentlicht. in diesem haben wir alle Informationen zusammengetragen, um den Wechsel von Drupal ...
Weiterlesen
No-Code- und Low-Code-Development mit Citrix Podio

No-Code- und Low-Code-Development mit Citrix Podio

Der von immer neuen „Buzz Words“ geplagte Entscheider hört, wenn es um Unternehmenssoftware geht, zunehmen davon, dass die Zukunft ...
Weiterlesen