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.See related Model A image here.See related Model B image here.
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
Suggestions on Improving Model A
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 firstname.lastname@example.org.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access