Frequently-asked questions »

Question »

Questions

OO class modelling 1 »

OO class modelling 2 »

Data/ Attribute Normalisation »

Fact Gathering »

DFDs and STDs 1 »

DFDs and STDs 2 »

Text in bold is suggested wording and text is italics is commentary on the answer.

First, it is important to remember to answer each part of the question.  Make it clear which part of the question you are answering by using the question parts indicated (a, b and c). It is useful to start each part of your answer on a new page, allowing you to add extra detail after your initial answer. 

• Answer to part a
• Answer to part b

• Answer to part c

Part a

The functional dependencies are shown in the attached diagram.

Note in this functional dependency diagram that passenger, date of issue and booking reference are only dependent upon the ticket number, whilst the flight details are dependent upon both the ticket number and journey leg, i.e. a journey leg is a line on the ticket.

The significance of the third point is that even though a flight number provides standard details about a flight, e.g. origin and destination,  the departure time of the flight varies according to the date.  Therefore the functional dependency diagram that departure time is dependent upon both flight number and date, whilst from-code and to-code is only dependent upon the flight number.

Part b

The first problem is that there is a repeating group of fields (which relate to each journey leg), therefore these need to be removed to make the classes into 1NF.

TICKET (ticket-number, passenger-name, issue-date, booking-reference)

TICKET-LEG (ticket-number, journey-leg, from-code, from-airport, to-code, to-airport, date, flight-number, departure-time)

A new class called TICKET-LEG has been produced to contain the repeating fields.  It has the same key as the original class (ticket-number) together with something to make each occurrence unique (journey-leg).

For 2NF, all non-identifying fields must be dependent upon the whole of a key. 

In this case, the only classes we needs to consider is the class with a composite key (i.e. has two fields), TICKET-LEG.

All classes are already in 2NF, since in TICKET all non-identifying fields are dependent upon ticket-number and in TICKET-LEG, all non-identifying fields are dependent upon ticket-number and journey-leg (together).

For 3NF, no non-identifying field must be dependent upon another non-identifying field.  In this case, there are relationships between airport code and airport name which violate 3NF and therefore these are removed to create separate classes.

TICKET (ticket-number, passenger-name, issue-date, booking-reference)

TICKET-LEG (ticket-number, journey-leg, from-code, to-code, date, flight-number, departure-time)

FROM (from-code, from-airport)

TO (to-code, to-airport)

Part c

The data flow diagram showing the appropriate control processes and flows are shown on the attached diagram.

The corresponding state-transition diagram for the checkin-control process is shown on the attached diagram.

Note that the names of the control flows are the same as the names of the transitions in the state-transition diagram.

Hide comments »