4.3. Solutions: Data Models

Figure 4.3.1: Data model for the Barbican Centre exercise.

A partial data dictionary to accompany the data model is this:

Booking = Booking Date + Booking Price Paid + Booking Discount Amount

Discount Qualification = * Data element *
[“School Child” | “Senior Citizen” | “Coach Party” I
“Youth & Music Member” | “Student” | “Unemployed”]

Performance = Performance Date + Performance Description
+ Performance Start Time

Performer = Performer Name

Pricing = * Relationship *
Seat Price + Venue Discount Price + Party Size
+ Party Discounted Price

Seat = Seat Number

Seating Area = Seating Area Identity + Seating Area Name

Ticket Buyer = Ticket Buyer Identification + Discount Qualification
+ Mailing List Subscriber + Children’s Cinema Club Member
+ Party Size

Venue = Venue Name + Venue Discount Conditions

Venue Name = * Data element *
[“Hall” | “Theatre” | “Pit” | “Cinema” | “Music Hall” | “Lecture
Recital Room”]
* Are Hall and Music Hall the same?*

To provide a manageable problem, we gave you a context that was limited to the part of the Barbican’s business related to booking seats. You can ignore any other data. For example, although the name of a performance’s sponsor may be of great concern to the fund-raising part of the business, it doesn’t appear to affect the context that concerns you. For this reason, we didn’t include SPONSOR NAME as one of the attributes of PERFORMANCE.

Let’s discuss this data model by considering the processing circumstances under which the entities and relationships are created and referenced. When the Barbican people schedule a PERFORMANCE, a HOUSING relationship is created between the PERFORMANCE and the VENUE they have chosen to house the performance. At the same time, they know the performers who will be appearing, and so instances of PERFORMER and APPEARING are established.

Each venue has a number of SEATING AREAs, each having a number of SEATs in them. The pricing for a seat is dependent on both the seating area and the performance. Therefore, we have chosen to have a trinary (three-way) relationship between PERFORMANCE, SEATING AREA, and SEAT. It is this PRICING relationship that holds the attributes SEAT PRICE, VENUE DISCOUNT PRICE, PARTY SIZE, and PARTY DISCOUNTED PRICE. In other words, this is the pricing for a seat in a designated seating area for a given performance.

However, the price of the seat may be different from the price actually paid if the ticket buyer qualifies for a discount. When someone wants to book a seat, the BOOKING PRICE PAID and the BOOKING DISCOUNT AMOUNT are calculated using the ticket buyer’s DISCOUNT QUALIFICATION, the SEAT PRICE, the VENUE DISCOUNT CONDITIONS, the VENUE DISCOUNT PRICE, and the PARTY SIZE. A BOOKING entity is created, a RESERVING relationship keeps track of which seats have been booked, and a BUYING relationship keeps track of who made the booking.

Let’s look a little more closely at the pricing policy. The VENUE DISCOUNT PRICE is invoked if the selected VENUE has one and if the TICKET BUYER has the appropriate qualification. For example, the user’s statement says, “In the Pit ... school children and senior citizens can get a £5 ticket for matinees only. Cinema prices are £3.50 for adults. Senior citizens and children pay £2.50.” Party discounts are available for some performances. The qualifying party size and discounted price for a party are attributes of PRICING. Other discounts are available, but are calculated differently. For example, reductions are offered for coach parties, to members of Youth & Music, and to students. On the assumption that the reduction is calculated as a percentage of the SEAT PRICE, we did not store the reduced prices as attributes. However, this is an assumption, and you must check carefully with the user.

The TICKET BUYER entity has an attribute CHILDREN’S CINEMA CLUB MEMBER. This is necessary, as the Cinema has screenings that are restricted to members of this club. The MAILING LIST SUBSCRIBER is a necessary attribute as subscribers are allowed to book earlier than others.

When you do some more process modeling, you will verify everything in the data model against your process models. In other words, even though the data model at this stage may contain assumptions, you will confirm or reject each of them by the end of the analysis effort. The reason for building this model is to understand the data well enough to be able to raise relevant questions with the users.

Your model should be substantially the same as ours, although there will be differences if you made different assumptions about the data.