DRAG DROP
###BeginCaseStudy###
Case Study: 1
Scenario 1
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 Windows 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 port 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
###EndCaseStudy###
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.)
Explanation:
block1: WasLate
block2: Flight
Use the [Airline] property as the partition key.
Use the Flight property as the row key.
Airline and Flight is the correct answer in other sources.
“query should return only late flights”
Data must be separated into partitions based on “WasLate”. So our queries work only one Partition and is more reasonable.
The combination of partition and row key should provide a unique identifier for a flight. From the properties specified in the FlightInfo class, I think the Flight and Arrival properties would provide unique identification for each flight because the flight name is usually reused at airlines but the arrival is unique for every flight. So I would suggest the Flight property for partition key and Arrival property for row key. That way flights can be grouped by name(Flight) and uniquely identified by arrival.
Looking back, the historical data is not after individual flights so we can group by Airline and use Arrival as row key. This combination, in my opinion, still provides unique identification and is more suited to the question.
[Airline] = partition key
[Arrival] = row key
[Airline] = partition key
[Flight] = row key
Airline and Flight is the correct answer in other sources.
“Queries for
historical flight information specify a set of airlines to search” The start of the search is by airline, so this should be in the primary key. Using this as the partition key allows azure to assign one server per airline. If you used a binary (waslate) as the partition key, you’d have a single server running your request (Millions of records). Next, the entire key (partition | row) must be unique with the row being unique in the partition. So we cannot use waslate as row. Flight name (e.g. BA715) is unique within the airline and would work. Arrival time is not unique as this would limit airlines to having only sixty flights an hour!.
Answer is Airline, Flight.
Below you will come across the link to some internet sites that we consider you should visit.