Seit das Thema Künstliche Intelligenz (KI) im Tourismus allgegenwärtig ist, stellt sich vermehrt die Frage, ob Destinationen überhaupt auf diese Entwicklung vorbereitet sind. Während in den letzten Jahren der Fokus auf strukturierter Datenpflege und Open Data lag, rückt nun die Integration von Destinationsdaten in KI-Anwendungen in den Vordergrund.
Wer oder was ist diese KI?
Es gibt nicht „die KI“. KI bezeichnet die Fähigkeit von Maschinen und Computern, menschliches Denken und Lernen nachzuahmen. KI-Systeme verarbeiten große Datenmengen, erkennen Muster und treffen eigenständige Entscheidungen oder geben Empfehlungen. Wichtig ist, dass jede KI auf einen spezifischen Anwendungsfall programmiert wurde. Eine KI für Textgenerierung kann zum Beispiel keine Bilder erstellen und umgekehrt.
Doch woher hat die KI all das Wissen?
KI-Anwendungen sind nur so gut wie die Daten, mit denen sie trainiert wurden, und die Qualität ihrer Trainer:innen. Das Prinzip „Garbage in, garbage out“ trifft hier zu: Schlechte Daten führen zu schlechten Ergebnissen. Ein Beispiel ist ChatGPT, das mit großen Mengen an Textdaten aus verschiedenen Quellen trainiert wurde. Neuere Versionen können in Echtzeit auf das Internet zugreifen und Informationen aus aktuellen Webseiten beziehen, ohne diese Daten dauerhaft zu speichern.
KI-Systeme können auch direkt über APIs mit spezifischem Wissen gefüttert werden, etwa mit Daten aus den eigenen Destinationsdatenbanken.
Welche Datenbank braucht meine KI? Relationale vs. Graphdatenbanken
Es gibt verschiedene Datenbanktypen, hauptsächlich unterteilt in relationale und nicht-relationale Datenbanken. Relationale Datenbanken nutzen tabellarische Modelle mit vordefinierten Schemata, während Graphdatenbanken Daten als Knoten und Kanten in einem Netzwerk darstellen.
Gegenüberstellung der Datenbanktypen:
Relationale Datenbanken sind besonders gut geeignet für Anwendungen, die mit klar strukturierten und standardisierten Daten arbeiten. Dazu gehören etwa Listen, Buchungssysteme, Verfügbarkeitsübersichten oder andere standardisierte Datenausgaben, die eine einfache und zuverlässige Verwaltung erfordern.
Graphdatenbanken hingegen bieten große Vorteile bei Anwendungen, die auf komplexen Beziehungen und Vernetzungen basieren. Sie sind ideal für Empfehlungs- und Interaktionssysteme, beispielsweise um Attraktionen zu identifizieren, die ähnliche Besucher:innen anziehen oder miteinander in Verbindung stehen. Ihre Stärke liegt in der schnellen Analyse und Darstellung dynamischer Datenbeziehungen, die in solchen Szenarien besonders gefragt sind.
Relevanz im deutschsprachigen Tourismus:
In der Realität des deutschsprachigen Tourismus müssen wir uns an die DSGVO halten, was die Verwendung personenbezogener Daten stark einschränkt. Wir dürfen keine personenbezogenen Daten in KI-Anwendungen verarbeiten, die außerhalb Europas gehostet werden. Dadurch sind viele komplexe Anwendungsfälle, die Graphdatenbanken erfordern würden, aktuell nicht realisierbar.
Die Beziehungen zwischen Datensätzen wie Veranstaltungen und Orten sind meist statisch und nicht besonders komplex. Solche Verknüpfungen lassen sich problemlos in relationalen Datenbanken abbilden. Erst wenn wir individuelle Vorlieben, Buchungsgewohnheiten und persönliche Rahmenbedingungen von Gästen einbeziehen könnten – was derzeit rechtlich nicht möglich ist – würden die Vorteile von Graphdatenbanken zum Tragen kommen.
Relationale und Graph-Datenbank im Check
Kriterium |
Relationale Datenbank |
Graphdatenbank |
Datenstruktur |
Tabellen, Zeilen und Spalten (relationales Modell) |
Knoten und Kanten (Graphenmodell) |
Ideal für… |
Stark strukturierte, weniger dynamische Daten mit klaren Beziehungen |
Hochvernetzte und dynamische Daten mit komplexen Beziehungen |
Beispiel für Abfragen |
Lineare Abfragen, wie „Liste aller Attraktionen in Stadt X“ |
Mehrstufige Abfragen, wie „Ermittle Attraktionen, die ähnliche Besucher anziehen“ |
Flexibilität in der Datenmodellierung |
Feste, vordefinierte Struktur, Anpassungen sind komplex |
Flexible Modellierung; Knoten und Beziehungen lassen sich leicht erweitern |
Abfragegeschwindigkeit |
Schnell bei einfachen, standardisierten Abfragen |
Schnell bei tief verschachtelten und vernetzten Abfragen |
Kosten und Wartung |
Häufig niedriger, einfacher in der Implementierung und Wartung |
Oft höherer Aufwand in der Implementierung und spezialisierte Pflege |
Kompatibilität |
Sehr verbreitet, viele unterstützte Systeme und Standards |
Weniger verbreitet, wachsender, aber eingeschränkterer Support |
Sicherheit und Datenschutz |
Gut geeignet für strukturiertes Management öffentlicher Daten |
Gleichwertig; gut für stark vernetzte, aber nicht personenbezogene Daten |
Beispiele |
MySQL, PostgreSQL, Microsoft SQL Server |
Neo4j, Amazon Neptune, ArangoDB |
Skalierbarkeit |
Gut horizontal skalierbar, besonders bei read-heavy Anwendungen |
Gut bei write-heavy und vernetzten Datenanwendungen |
Einsatz im Tourismus |
Gut für Listen, Buchungen, Verfügbarkeiten, standardisierte Datenausgabe |
Gut für Empfehlungs- und Interaktionssysteme, z. B. ähnliche Attraktionen finden |
Benutzerfreundlichkeit |
Bekannte SQL-Syntax, einfache Handhabung |
Spezialwissen erforderlich, meist proprietäre Abfragesprachen (z. B. Cypher) |
Fazit:
Für den aktuellen Bedarf im Tourismus sind relationale Datenbanken in vielen Fällen ausreichend. Während Graphdatenbanken technologisch fortschrittlich sind und bei komplexen, vernetzten Daten Vorteile bieten, besteht keine zwingende Notwendigkeit, auf sie umzusteigen. Es ist wichtiger, eine solide Datenstrukturierung zu gewährleisten und die Datenschutzstandards einzuhalten. Wir sollten uns nicht für Anwendungen rüsten, die aufgrund rechtlicher Beschränkungen wahrscheinlich nicht relevant werden. Stattdessen sollten wir die vorhandenen Ressourcen effektiv nutzen, um Gästen ein besseres Reiseerlebnis zu bieten und die Arbeit in den DMOs zu optimieren.