PROJECT : Ticket-Reservation Database Model

A number of e-commerce websites specialize in ticket sales for entertainment and performing arts, like Ticketmaster and TicketWeb. You are to design and model a database suitable for ticket-sales websites like these. The intended users are customers that are searching for information on events, wish to purchase tickets, or have purchased tickets. You are to model that part of a database system which stores information relevant to customers. Omit information internal to ticket e-commerce companies and irrelevant to customers, such as records on employees and business deals with performers and promoters.

The objective of Project 1 is analysis of the application domain and identification of class objects, including pertinent composition/aggregation parts, and incorporation of basic association relations specified below.

The main entities to be modeled are:

venues like halls, theaters, clubs, stadiums, arenas

events like music concerts, theatrical plays, magic shows, sports events

performers like (groups of) musicians, (groups of) actors, sports teams

customer accounts containing information on people that have purchased tickets, including history of past purchases

These entities will be organized by two kinds of hierarchies: generalization-specialization (inheritance) hierarchies and composition/aggregation whole-part hierarchies.

For example, venues may be categorized by their intended types of events, like halls used for performing arts/entertainment generally, concert halls used specifically for music performance, and sports stadiums/arenas. Note that venues may be used for non-intended types of events; for example, sports stadiums/arenas are sometimes used for music performances. A venue may be a complex of multiple halls, stadiums, and/or arenas, e.g., Madison Square Garden, Lincoln Center, Carnegie Hall.

The most important component of each venue is the collection of seats, with their seat labels. The seats are normally divided into sections by their locations and/or price ranges, and also by special status or needs of customers, like season ticket holders or handicapped people. The prices of seats may vary depending on events.

Incorporate the following association relations suitably into your model:

performs(Performer, Event): performs(p, e) means performer p performed or will perform in event e.

holds(Venue, Event): holds(v, e) means venue v held or will hold event e. If the venue in question is a complex of multiple component sub-venues, v should be a sub-venue.

price(Seat, Price, Event): price(s, p, e) means seat s has price p for event e. On the (reasonable) assumption that all seats in any seat section have the uniform price, SeatSection class may be used instead of Seat.

available(Seat, Event): available(s, e) means seat s is available (i.e., has not been purchased) for event e.

ticket(CustomerAccount, Seat, Event): ticket(c, s, e) means customer account c purchased a ticket for seat s in event e. Instead of CustomerAccount, its component class like Payment may be used.

You may build your model based on the basic ticket model included in flowing example :

For "field research", you are encouraged to visit a few ticket websites (like Ticketmaster and TicketWeb above) and also websites of well-known venues of various types. Keep in mind, however, that structures of websites do not necessarily translate into good database models. Certain structural aspects of websites are influenced by human user interface issues (e.g., ease and efficiency of the user's reading and navigation) that are largely irrelevant to internal database models.

Here is a summary of key points:

All the classes, inheritance hierarchies, whole-part relations, and association relations must be modeled in a UML class diagram. The multiplicity ranges of each binary relation must be specified.

Include basic, essential attributes in classes. Attribute data types may be specified or omitted.

Key attributes, if any, should be specified by appending (key) to the attribute names. For example, if the customer account class has a key attribute emailAddress, put emailAddress (key) in the class box.

If attribute/relation names are not self-explanatory, concisely describe their intended semantics by English comments in the text documentation area. Your UML tool should provide text documentation areas for this purpose.

Consider using different background colors of class boxes for different groups of classes. For example, you might use blue for the group of classes involving venues, green for the group of classes involving events, etc.

The projects must be completed by a UML tool. If you've never used a UML tool, Visual Paradigm UML free community edition is recommended.

Example College Model Person DNum Name JobDescription name position Title startDate 1 lastName midInitial dDate Student Em employee . ment major program hasGraduated 0..1 office Grade student Staff inalGrade Date datedGrade office Officelnfo roomNum building ake grade !updated radeDate Professor rank nowEmployed01 Office office 0..1 me CourseSection registrationCode teach Department Course number title credits hours description offer Powered ByVisual Paradigm Community Edition Example College Model Person DNum Name JobDescription name position Title startDate 1 lastName midInitial dDate Student Em employee . ment major program hasGraduated 0..1 office Grade student Staff inalGrade Date datedGrade office Officelnfo roomNum building ake grade !updated radeDate Professor rank nowEmployed01 Office office 0..1 me CourseSection registrationCode teach Department Course number title credits hours description offer Powered ByVisual Paradigm Community Edition