Phase 1: Information requirements and conceptual data modeling

Problem:

Movie buffs can often have hundreds if not thousands of individual items in their collections. How do we help them keep track of this overwhelmingly large number of items?

Proposed solution:

A media tracking database that facilitates ease of entering, tracking, querying and reporting information.

Purpose of Project:

To develop a media tracking database.

Goal:

To develop an easy to use database and front end to facilitate entering, tracking, querying and reporting information. This database will be created using software available on the computer in A240 or otherwise obtainable at BCC.

Objectives:

(Here, I used Ruble, p 37, where he discussed determining problems, then turning them into solutions.)

Sylvia said to map requirements to tasks the user will perform. I think I've generalized on this. Maybe others have more specifics? I suppose we can turn the functional requirements I've entered below into objectives, but let's first ask Sylvia if she wants this level of detail.

  1. (Problem: What information needs to be tracked?)

    2. Determine the information that needs to be tracked and the reporting that is required, by conducting interviews of movie buffs. We will also research the internet to find out what information is stored by online media databases, such as Yahoo Movies and Mr. Showbiz.

  2. (Problem: How do we organize this information in the database to ensure current needs are met and to facilitate growth?)
    3. Develop ERD that will enable current needs and provide flexibility for growth.

  3. (Problem: How do we organize this information for the user)

    4. Develop a user friendly interface for inputing and reporting data.

  4. (Problem: How do we ensure our system is usable?)

    5. Conduct usability tests to ensure our product fits user needs.

Note that I didn't add any details about our forms, queries, etc. Those fall under "solutions"

 

Attributes

ISBN
User Code -if user has an identifier they prefer to use, rather than ISBN
Physical location if user would like to keep track of the phys location where they keep the movie
Title
Actors
Release year
Production company
Producer
Director
Running time
Rating (PG, R, etc)
User Rating (if the user wants to store their own movie rating)
User Review (if the user wants to store their own impression of the movie)
In Color (boolean)
Closed Captioned (boolean)
Description
Reviewers
Review
Date obtained
Place obtained Name
Cost
Status (in house, lent out, damaged).
Lend_date
Person Lent to
Return_date

So major data entities might be:

Movie

Location of Movie

Actor

Production company

Producer

Director

Motion Pic Assocation Rating

Professional Reviewers

Retail Sources

Lending information

 


Business Rules

One Movie can be stored in one location.
One location can store many movies.
One movie can have many actors.
An actor can star in many movies.
A production company can make many movies
A movie can be made by only one production company
One Producer can make many movies.
One movie can have many producers.
One director can make many movies.
A movie can have many directors.
One movie can have one Motion Pic Association Rating
One Motion Pic Association Rating can have many movies.
One movie can have many reviewers.
One reviewer can review many movies.
One movie can have one source.
Many movies can be obtained from one source.
One movie can have many lenders.
One lender can borrow many movies.

Functional requirements.

(I'm not sure I understand what she means by 'functional requirements' but I assume she means, how will the database be used?.

The user can enter movies.

The user can retrieve data about movies, using any attribute in the database.

The user can store the physical location of each movie for easy physical retrieval.

The user can rate movies, and/or store ratings from professional reviewers.

The user can track the status of their movies.

The user can track the lending of movies.

ERD

Page-1