I recently traveled overseas and, with a combination of flying status on a particular airline and a bit of luck, I was able to upgrade from economy to business class.
I experienced a nice airy cabin, comfortable seat and attentive flight attendants; one of the flight attendants introduced herself to me and gave me a menu. I mentioned that I had reserved a vegetarian meal and, after some checking, she explained that the “IT systems” erase special meal preferences when a passenger is upgraded. “You should have called at least 24 hours prior to make sure your special meal would be available in business class,” she said. It was a long flight but, with enough peanuts and pretzels I managed. What kept my focus off food was data modeling, and I sketched the following two data models during this flight. One is the current flawed data model, which allows for special meals to be wiped out or replaced, and the other is the ideal data model that they should eventually adopt.
For this challenge, I asked the Design Challenger group which of the models is the “as is” flawed model and which is the “to be” ideal model. If you think neither one of these would keep the special meal preferences on an upgrade, explain why.
The Response
Model B has Special Meal Code in both the original reservation and revised reservation. Therefore, if someone is upgraded that requested a vegetarian meal, this special meal code must be copied to the revised reservation. However, in Model A, Special Meal Code appears just once in the Original Reservation; therefore, when the reservation is revised, this special meal code can be derived. Although the coding behind these models can make both work (or not work), it is easier and less error-prone to retrieve a single data element, than to populate and retrieve this same data element from two different places. The Design Challengers chose Model A and recommended some improvements we could make to this model.
Reasons Why Model A is Preferred
Himanshu Gupta, delivery partner, says. “I believe that Model A has a better approach because it ensures that information flows from Original to Upgrade and, at the same time, the relation between the two ensures special meal code can be derived from the original table itself. In Model B, while it might contain all the required data elements in the Upgrade table, the issue is that it is disconnected from the original table and thus may not work on its own. It would almost be like doing the whole reservation process again but in a different table.”
Data Modeler Georgia Prothero says, “The difference is that, in A, the upgrade is linked to the original reservation and can therefore inherit all of its properties, including the special meal.”
Ed Landale, data architect, says, “When the Revised Reservation is created, the Original Reservation Special Meal Code (which had the code for Vegetarian when you first made your reservation) will still specify Vegetarian when the Revised Reservation is created, and it is referenced by the Revised Reservation, so you’ll get your meal…A bigger issue in my view is that Revised Reservation is not directly related to Original Reservation. Revised Reservation is not some independent thing that hopefully has the same Flight Number and Frequent Flyer Number as some Original Reservation. It is a revision to an Original Reservation and should be modeled as such, with a direct relationship.”
Suggestions on Improving Model A
Data Modeler Lucy Rossano says, “I would pull the Special Meal Code out of those tables into a table relating just the Passenger and the Flight, as the Special Meal is not truly dependent on the Class of Service, but just the Passenger and the Flight.”
Håkan Edvinsson, CTO, says, “I suggest you introduce a reservation ID for your trip that remains throughout upgrades (or downgrades) and keeps the information about any special arrangements.”
Dave Hay, guru, says “Instead of a separate entity type, you should have simply added a recursive pig’s ear to the original reservation box. Thus, each Reservation may be ‘a revision of’ one and only one other Reservation. Then, you can attach a business rule that says: If a Reservation is created that is ‘a revision of’ another Reservation, it must inherit all the constraints that were on the original (through all levels).”
Marcin Kulakowski, principal data analyst, says, “A reservation is a reservation. It doesn’t matter if it’s an original or revised reservation. I would simply combine the two reservation entities and have one Reservation, with Flight Number, Frequent Flyer Number and a Reservation Date in the key.”
Summary
We can make either model work, yet by minimizing redundancy, we reduce the chances of having a data quality issue or a business rule misinterpreted. The suggestions of distinguishing a reservation from changes to that reservation is something we can play with and see if this makes an even better model. Maybe instead of a Model A, we have a Model A+. Until the next challenge! To receive Steve's monthly Design Challenges, visit his website at
stevehoberman.com. Steve can be reached at
me@stevehoberman.com.
Steve Hoberman is currently a data modeling consultant and instructor. He taught his first data modeling class in 1992 and has educated more than 10,000 people about data modeling and business intelligence techniques since then. Steve balances the formality and precision of data modeling with the realities of building software systems with severe time, budget, and people constraints. In his consulting and teaching, he focuses on templates, tools, and guidelines to reap the benefits of data modeling with minimal investment. Steve is the author of five books on data modeling, the founder of the Design Challenges group, and inventor of the Data Model Scorecard.
