###BeginCaseStudy###
Case Study: 4
Scenario 4
Background
You are developing a flight information consolidation service. The service retrieves flight
information from a number of sources and combines them into a single data set. The
consolidated flight information is stored in a SQL Server database. Customers can query and
retrieve the data by using a REST API provided by the service.
The service also offers access to historical flight information. The historical flight
information can be filtered and queried in an ad hoc manner.
The service runs on a Microsoft Azure Web Role. SSL is not used.
Business Requirements
• A new data source for historical flight information is being developed by a
contractor located on another continent.
• If a time zone is not specified, then it should be interpreted as Coordinated
Universal Time (UTC).
• When you upgrade a service from a staging deployment to a production
deployment, the time that the service is unavailable must be minimized.
• The default port must be used for HTTP.
Technical Requirements
The existing sources of flight information and the mechanism of exchange are listed below.
• Blue Yonder Airlines provides flight information in an XML file.
• Consolidated Messenger provides flight information in a Microsoft Access
database that is uploaded every 12 hours to the service using SFTP. The
company uses Dort 22 for SFTP.
• Margie’s Travel provides and consumes flight information using serialized
ADO.NET DataSets. Data is periodically synced between the service and
Margie’s Travel.
• Trey Research provides data from multiple sources serialized in proprietary
binary formats. The data must be read by using .NET assemblies provided by
Trey Research. The assemblies use a common set of dependencies.
• The current version of the Trey Research assemblies is 1.2.0.0. All assemblies
provided by Trey Research are signed with a key pair contained in a file
named Trey.snk, which Trey Research also supplies.
• The application specification requires that any third-party assemblies must
have strong names.
Application Structure
FlightInfo.es
BlueYonderLoader.es
HistoricalDataLoader.es
MargiesTravelSync.es
FlightInfoContext.es
FlightDataController.es
###EndCaseStudy###
DRAG DROP
Historical flight information data will be stored in Windows Azure Table Storage using the
FlightInfo class as the table entity.
There are millions of entries in the table. Queries for historical flight information specify a set
of airlines to search and whether the query should return only late flights. Results should be
ordered by flight name.
You need to specify which properties of the FlightInfo class should be used at the partition
and row keys to ensure that query results are returned as quickly as possible.
What should you do? (To answer, drag the appropriate properties to the correct location or
locations in the answer area. Each property may be used once, more than once, or not at all.
You may need to drag the split bar between panes or scroll to view content.)
Answer: 
Other sites say airline & flight.
This however makes sense…
I think airline and flight make more sense.
The combination of partition key and row key must be unique. This is a requirement in Azure Tables. Airline + Flight arrive many times and so this is not unique. The row key should be Arrival. The partition possibly Flight or maybe Airline, although Flight seems a better choice because a popular airline could have 2 arrivals at the same time, but certainly no two flights! Usually the Flight contains the first 2 or 3 letters of the Airline anyway. So the correct answer is Flight + Arrival.