Create an ER model for each scenario. Make sure that you read the description carefully. Your diagram should reflect all entities, attributes, and relationships in the description. You should make sure each entity has a primary key (a unique identifier). Use the relationship types we used in class (one-to-one, one-to-many, or many-to-many). Dont forget, attributes can describe both entities and relationships.

Scenario 1: Safety Incident Database for Schuffyland Park Schuffyland Park is a medium-sized amusement park in suburban Philadelphia. The park is required to provide periodic safety reports to the Commonwealth of Pennsylvania certifying its rides have passed inspection. They must also keep a record of all safety-related incidents (such as accidents) for each ride This park also has to be ready for "surprise" audits that can occur any time. An incident involves both a ride and an operator. All operators and rides are included in the database whether or not they've been involved in a safety incident, and the date and shift are recorded each time an operator runs a ride at the park. A ride is described by a name and date of last service. An operator is described by their first and last name. When an incident occurs, its date and time are recorded along with a description of the incident. Operators must be trained and a record of certification must be maintained for the rides they operate. Each certification record is associated with multiple operators but only one ride. An operator can have multiple certifications. The certification is valid for two years from the date they complete their training. (problem description continues on next page...) The database also tracks the agency issuing the certification. When an incident occurs, it is important that the park can produce a list of current certifications for every operator and every ride, and the park must be able to report which operators have up-to-date certification for the rides they operate Inspection records are also recorded in the database. An inspection occurs at a particular date and time, with a numeric score from 1 to 5, and notes about the outcome of the inspection. There is only one ride per inspection, even if multiple inspections are done by the same inspector on the same day and time. The information that needs to be recorded about the inspector is their first and last name Scenario 2: Tracking Trips for the SchUber Taxi Service A new Philadephia startup called SchUber is a matching service between freelance taxi drivers and passengers. The database to support the service tracks trips, customer accounts, and includes a rating system where drivers and passengers can rate each other The basic transaction for SchUber is the trip. A trip is described by the date and time the trip occurs and the fare. A trip involves one driver and at least one passenger. A driver has a first name, a last name, a social security number, and an email address. A passenger has a first name, last name, and an email address. A trip is also associated with at least two addresses. An address is also described by the street address, city, state, and zip code. Each address must be designated as either an origin or destination address for the trip. Each address also has an attribute which designates the address as a home address for a passenger-this is useful for billing and for making a request for a home pick-up. However, a passenger can only have one address (their home address) associated with their account. Payment for a trip can be paid for entirely by a single passenger, or each passenger can pay their share as long as all passenger's individual payments add up to the total fare. A payment is described by a fare and date of payment. Passengers can also add a tip, but this is not included in the fare. Passengers can use any one of several payment methods that can be linked to their passenger record Valid payment method types are PayPal, Credit Card, or Android Pay. Payment methods have an account number, but only credit cards have an expiration date. Passengers cannot share a payment method. The rating system is one of the key features of SchUber. Both drivers and passengers can have ratings, although they may not have any ratings, especially if they just started with the service. When a driver or a passenger submits the rating, they give a star rating (1 to 5), brief comments, and the type of review (i.e., for driver or for passenger). SchUber users can look up ratings by driver, passenger, or by trip (a trip could have more than two ratings if there were multiple passengers on the trip)