Home Client Class Page Teacher's Home CS Dept. WSU
Hurrah

Video Rental System

Formal Technical Review

(Design Walkthrough)

On Monday March 29, 1999 we presented our design to our peers, development team of YESH.

Group lead Faisal, started out with handing out the ER and class diagrams, and a list of important definitions that could be referenced during the presentation. Then he gave a brief description of client requirements, followed by an introduction to the system design. He explained the two options that were explored and the reasons for choosing the Database based design.

Alexey, our database expert explained the database design. He started out with explaining the different jobs that the database has to perform. He concluded that since these are two totally different functions that the database has to perform therefore it is best to split the database into two subDataBase.

Cindy followed with the detailed description of the entities and relationships. She explained the attributes that each entity is comprised of. Then she explained the relationships that exist between entities.

Jimmy explained the many classes that are needed to build the interface and functionality. Furthermore he explained the structure of the classes and the relationship of classes with each other and the database.

Lily explained a few of the functions from a couple of classes. She explained the interface among the classes and the flow of information. She also demonstrated, with the use of ValidID() function from the Video class, the interface between classes and tables.

Even though no problems were found with the design, there were some good questions raised, specially about the database design.

  1. Why is the relation StarsIn defined as zero-to-many (0:M) not one-to-many (1:M)?

    2. The relation StarsIn between Movie and MovieStar is zero to many for several reasons
    1. If the movie is a documentary then there are no MovieStars and the system will accept that. If the cardinality is made 1:M then at least one MovieStar is needed which will not make sense in this situation.
    2. The clients can keep information about a MovieStar even though he/she does not appear in any of the movies owned by the store. If the cardinality was 1:M they will not be able to do so.
    3. The clients don't have to include the MovieStars if they don't want to. If the cardinality was 1:M they would be forced to do so.

  2. Why don't you merge the Family and Customer entities into one?

  3. Why the relation BelongsTo has a cardinality of 1:1 on the Family side?

    4. The above two questions are very closely related because they are about the same entity and the relation between them. Therefore the answer to both of these is below.

    The Family and Customer entities can not be merged into one because the client requires a primary account entity and an individual account entity. The client wants to control the number and the highest rating of movie that can be rented by an individual, and the total number of movies that can be rented by a primary account. Even though this requirement adds some complexity to the design but helps get rid of some of the redundacy and duplication of data, such as phone number and address, which needs to be stored only once for all members of same household. We are certain the client didn't think about this added benefit when coming up with the requirements.

    The abstractions used by Hurrah are very real life. That is, a family or household can have many members, e.g. a head, and potentially many family members. Therefore an individual family member, known as Customer in Hurrah, belongs to one and only one household, known as Family, that's why the cardinality of 1:1. On the other hand, a Family can have many members but no less than one i.e. every household has at least one member who is the head of household as well. Therefore the relation BelongsTo has cardinality of 1:N on Customer.

  4. Why is Reserve not a ternary relation like Rentals?

  5. Why is Reserve a one-to-many relation, not a many-to-many relation?

    6. The Reserve is a relation between Video and Customer only. If a Video is reserved it tells which Customer reserved it. Since Video is related to Movie, the availability status of a Movie can be found fairly easily.

    The reservation information is not stored permanently, i.e. it is deleted as soon as the Customer picks up the Movie, or the reservation time expires. Therefore there is no need to store the information about the employee who helped reserve the movie(s).

    The Reserve is a one-to-many relation because at a given time one Video can be reserved by a maximum of one Customer, but one Customer can reserve more than one Videos.

    Click to return to
    Home Page Client Page Class Page Teacher's Home CS Dept. WSU