Data Management

In March of 2000, a local mountain-biking club (Mountain-Bikers for Life) was organized for recreational purposes in West Virginia. Through the years the club had many members come and go, but the club continued to grow in popularity. As some members moved to other parts of the country, they began to form their own “Mountain-Bikes for Life” Club. The various clubs would even have events once or twice a year with one another. This sport has become so popular that, The Extreme Mountain Bike Racing League (EMBRL) was birthed. The headquarter for the EMBRL is in West Virginia, but they have racing locations in Colorado, Maui, New England, Tennessee, Wisconsin, and Minnesota.

You went to college with the Mike “Mountain Man” Miller, who is the founder and CEO of the EMBRL. He has contacted you to see if you would be interested in creating a database application for his newly formed league. You have been doing contract work for an IT consultant form and have recently left to start your own business and this may just be the opportunity that you have been looking for to jumpstart your business.

After jumping at the opportunity, you scheduled a meeting with Mike to discuss his data needs. After your initial interview with Mike and after having subsequent meetings, Mike has provided you with the Logical Design Criteria listed below.

Logical Design Criteria
The logical and relational requirements for the database that you are designing for the EMBRL are as follows:

The database must keep track of all of the riders who are part of the league. They need to have easy access to their personal address information, contact information, the date they joined the EMBRL and who their agent is.

Each rider is part of a given team. Each team consist of 4 riders. We need to keep track of the team name, the riders on that team.

Many riders have pushed the limit of their bikes by tinkering with them by adding to and/or taking away from the original design of the bikes. This often gives some riders an unfair advantage over the other riders. It is important that the database keeps track of the approved mountain bikes, along with their name, description, weight and a picture. Also, it is important to know which bike a rider is using in a given race.

Since the potential is there for the riders to now get paid quite a bit of money for winning races and even participating in races or outside engagements, the riders thought it necessary that each of them have their own agent. Often, a single agent will represent one or more riders. We need to know the agent’s name, address information, contact info and which riders they represent.

The EMBRL even has corporate sponsors. These sponsors give financial support to the various events (which consist of 1 or more races) and even directly sponsor individual riders. A rider may have 0, 1 or many sponsors and a company may also sponsor 1 or more events. We need to know the name of the sponsor, address information, contact information, which riders they sponsor (if any) and which events (if any) they sponsor. Also, a given company can very well sponsor riders, or events or both, but they will sponsor at least one of them. You cannot be a sponsor and not sponsor anybody.

All advertising is first done at the Event level. The Events may consist of 1 or more races. The races that make up a given event may be in the same location or different locations or even different levels of rider expertise. The event information that we need to track is the name of the event, event location, address information, the beginning and ending dates and who the corporate sponsor of that event is. Again, each Event may consist of one or more races. For example, you may have 4 races spread out over a given weekend that makes up one particular Event. The race(s) that make up a given event keeps track of information about the location of the particular race, the rider’s level of experience, the date of the race, the distance of the race and the start and ending times of the race in question.

Each rider can participate in one or more races. We need to know which riders are riding in which races and what approved bike they are using for that particular race. Lastly, we will need to keep track which place the rider finished in the respective race that they are riding in. We will track all riders placements at the end of each race. Each of these places has bearing on which team wins the overall season’s title and prizes will be dispersed accordingly based on which team has the lowest points of the season.

Deliverables and Grading Rubrics
Entity Relationship Logical Data Model: A visual model which represents each table (entity) and the relationships between the tables. Refer to the Power Point Presentations that cover “Entity Relationship Diagrams” – on the Canvas Schedule page. This diagram can be completed with MS. Word, Visio, Smartdraw, lucid charts or some other graphics program of your choice. However, copy and paste your diagram back into Word along with the other two deliverables or submit it in a PDF format.

Field List: Shows the fields (attributes) for each table (entity) and identify the primary key (by underlining it). Identify any Alternate Keys, Secondary Keys and all Foreign Keys. The field list should include all fields which are found in the problem. We will use the Relational Database Shorthand from the Power Power Point Presentation “Database Design – Using ER Diagrams” on the Canvas Schedule Page.

Technical Summary: The technical summary provides verbal support for the relational data model. The technical summary should answer the question, “Why this logical data design and not some other?” or “Why are these relationships one-to-many or many-to-many?” This is the portion where you get to talk the database language and explain/support your Entity Relationship Logical Data Model. At Least 1 page 12 pt font double-spaced.