Earlier I embarked on the journey to create an AODB based on a NoSQL datamodel, moving away from a relational model and discuss its benefits. As a quick refresher about What’s an AODB ? for the new reader, the elevator-pitch style version describing an AODB:
AODB – Aiport Operational Database
An AODB system is one of the core IT systems to support the airport ground operations, it integrates with various systems in the heterogeneous airport IT landscape by processing data from airline seasonal flights schedules, flight plan and slot management, ground movement from Radar, air movement from ATC, and other sources. It serves as CDM (Collaborative Decision Making) platform for the various parties and stakeholders forming the airport community, from airport operators, airlines, groundhandling agents, authorities to ATC (Air Traffic Control) and others.
It handles seasonal and operational flights by providing planning, real-time and historical data, supports resource management for facilities, equipment and human resource and feeding information to public via FIDS and other external links. The below diagram shows an exemplary common orchestration of systems where the AODB is embedded at the core.
Now lets have a look at the typical data layout and relation of flight data entities and attributes. These are the common business entities and a relational model is the traditional approach to design it. We need to apply a rather high level of normalization to avoid redundant data, but the relations (typical 1:N) across the model have an impact on the performance of the DB. This can be counterbalanced by tuning, indexing and more powerful hardware underneath. Building SQL statements with joins across several tables becomes challenging (hard to create) and might cause inefficient reads of tables (full table scan). In comparison with a NoSQL design we have a document approach, one document (like a index card in the analog world) would contain all relevant data (ignoring the redundancy problem for now).
At the end of this exercise we have to ask the question: Is NoSQL the right tool for an AODB ? (We will revisit this question later on)
I like to elaborate the redundancy problem on one particular case:
A flight is operated with a specific aircraft (registration, tail number) on a certain date. The related information (AC Type, seats, owner, lease, etc) we retrieve from the relational table (containing all aircrafts in the system,) quite the standard scenario. The problem starts when we keep operational data long term (years) for auditing/research/statistical purpose. It is quite common registrations get transferred due to sale or scrapping of aircraft (find a sample here). Using the relational model with an aircraft registration table that only carries current registrations we would end up looking at the wrong information for a historical flight that operated on the previous aircraft with the same registration. A solution would be introducing the concept of validity for certain entities ,which again adds to the complexity.
The main problem is not solved, we should not replicate or mimic a relational model with NoSQL. Keeping the data redundant will increase the data volume but we would have one document with all relevant information. One usecase which is appealing for the document approach is creating a final snapshot of the flight in an archive like repository. The design question we have to answer, what data or details of the operations lifecyle (schedule, planning, operation, post-operation) we want to keep in the flight “document” ?
As an academic exercise, lets get started and create the most basic (primitive) version of a flight document in JSON format and look at all its weakness to start to evolve to improved versions of it.
{
"flight": "AA123D",
"org": "AKA",
"des": "FRA",
"service": "J",
"actype": "A350",
"position": "Z19",
"gate": "A5",
"baggagebelt": "09",
"scheddep": "2017-11-23T19:35:00.000Z",
"schedarr": "2016-11-24T13:15:00.000Z",
"estimatearr": "2016-11-24T13:55:00.000Z",
"estimatedep": "2016-11-23T19:39:00.000Z",
"onblock": "2016-11-23T13:35:00.000Z",
"offblock": "2016-11-23T19:31:00.000Z",
"landed": "2016-11-23T13:27:00.000Z",
"airborne": "2016-11-23T19:39:00.000Z",
"pax": "128",
"via": [
"ABR",
"ACL"
],
"codeshare": [
"LH123",
"TG123",
"AF123"
]
}
What is good about this entry level model ? Not too much other than highlighting the benefit to have all info in one document.
Lets look at the problems, at least the highlights. There is quite a number of attributes missing (eg. registration) but here the main flaws:
- There is no clear concept of the flight as entity. Is it a segment or a complete journey ?
- No naming convention, more or less random abbreviation for eg. timings.
- No proper key identifier.No separation of airline code, flight number and suffix, missing schedule departure date (as key).
- Resource should be an array of objects. Multiple resources with different timings might be in use.
Same applies to any pax or cargo/load data. - Representing VIA and CS information like this might be good enough for a FIDS system but for a mature model we need to break down the whole entity into segments.
- No links which provide dependencies to other segments, codeshares, arrival or departures.
- Milestones (timings) should be an array too.
- No audit information. (Might not in the scope of our model though.)
- No unique (technical) identifier beyond flight keys.
We will elaborate and finetune in upcoming posts. Stay tuned.
Disclaimer: This discussion, datamodel and application is for study purpose solely. It does not reflect or replicate any existing commercial product.
Image: Creative Commons, DeGolyer Library, Southern Methodist University on The Commons, “DC-3 Aircraft at Houston Municipal Airport, Eastern Airlines”
