FACT COPY · DE
Faktenfassung: Explorer für Travel-Datenmodelle
Begriffe und Beziehungen zwischen Produkt, Verfügbarkeit, Offer, Order, Reisenden und Zahlung.
Originalseite: https://travel-mcp.com/de/praxiswissen/travel-datenmodelle/
Sachliche Zusammenfassung
Der Explorer verhindert, dass sprachlich ähnliche, fachlich aber unterschiedliche Zustände in einem Tool vermischt werden. Welche Entität ist zu welchem Zeitpunkt autoritativ, und welche Beziehungen dürfen nicht durch sprachliche Ähnlichkeit zusammengezogen werden?
Leitfrage und Entscheidungsgrenze
Welche Entität ist zu welchem Zeitpunkt autoritativ, und welche Beziehungen dürfen nicht durch sprachliche Ähnlichkeit zusammengezogen werden?
Der Explorer verhindert, dass sprachlich ähnliche, fachlich aber unterschiedliche Zustände in einem Tool vermischt werden.
Architektur und Verantwortlichkeiten
Produkt, Verfügbarkeit, Suchergebnis, Offer, Order, Service, Reisender, Zahlung und Dokument sind getrennte Entitäten. NDC und ONE Order liefern wichtige Airline-Semantik; OpenTravel deckt weitere Segmente ab. MCP stellt diese Semantik nicht bereit, sondern transportiert fachlich geschnittene Capabilities darüber.
Analytische Methode
Für jede Entität werden Identität, Namensraum, Owner, System of Record, Version, Zeitgültigkeit und erlaubte Übergänge erfasst. Codes wie IATA, UIC oder GTFS stop_id bleiben mit ihrem Namensraum verbunden. Geld enthält Betrag, Währung, Bestandteile und Gültigkeit; Zeit enthält lokale Bedeutung und Zeitzone.
- Produkt und Leistung
- Verfügbarkeit und Bestand
- Offer und Gültigkeit
- Order und Servicing
- Identität, Dokumente und Zahlung
Travel-Fallstudie
Ein Suchergebnis ist kein Offer, ein Offer keine Order und eine erfolgreiche API-Antwort noch keine bestätigte Lieferantenbuchung.
Das Beispiel gilt erst dann als belastbar, wenn Quellen, Zustände, Rechte und Fehlerpfade genauso konkret dokumentiert sind wie der gewünschte Normalfall.
Typische Fehlkonstruktionen
Ein Suchtreffer wird häufig als buchbares Offer dargestellt, eine erfolgreiche API-Antwort als bestätigte Order und eine Itinerary als Vertragszustand. Solche Vereinfachungen erzeugen falsche Preise, Doppelbuchungen und unklare Haftung. Ein kanonisches Modell darf anbieterspezifische Bedingungen nicht wegaggregieren.
Erforderliche Evidenz
Ein Datenmodell braucht Beispielinstanzen für Normalfall, Ablauf, Änderung, Teilbestätigung und Storno. Mappingtabellen dokumentieren Informationsverlust. Provenienz und retrievedAt sind besonders für modellgenerierte Zusammenfassungen unverzichtbar.
Messgrößen und Abnahmekriterien
Datenqualität wird über Vollständigkeit, Aktualität, Mappingverluste, unbekannte Codes, inkonsistente Zustände, Revalidierungsdifferenzen und Abgleich mit dem System of Record gemessen.
Ergebnis und weiterführende Analyse
Entitätskarten zeigen Systeme der Wahrheit, zeitliche Gültigkeit und geeignete Capability-Grenzen.