Common Mistakes

• Fail to identify all entitieso Some relationships between entities are missingo Some attributes are misplaced

• Forget to include a primary keyoNo primary key at alloUse “first name, last name” as primary key

• CardinalityoDo not specify cardinality at alloOnly specify maximum cardinalityo Specify the cardinality incorrectly (most tricky)

Assignment Instructions

• Read Instructions carefullyoCreate ER Model (namely ERD)oPrimary keyo1:1, 1:m, m:m (maximum cardinality)

üDo we need to specify minimum cardinality?o Two types of attributes: entity attributes and relationship attributes

Create an ER model for each scenario. Make sure that you read the description carefully. Yourdiagram should reflectallentities,attributes,andrelationships in the description. You should makesure each entity has a primarykey (a unique identifier). Use the relationship types we used in class(one-to-one,one-to-many,ormany-to-many). Don’t forget, attributes can describe both entities andrelationships.

Assignment Instructions – Continued

• How to draw ERD?oUse ERDPlus

• How to submit your assignment?o Submit electronically via blackboardo Include your name at the top of a word document

You must submit your diagrams electronically, and they cannot be hand-drawn. Use ERDPlus tocreate your diagrams (http://www.erdplus.com). It’s free, and there is a short YouTube tutorial onthe site that shows you how to export the diagrams as a graphic which can be placed into a Worddocument.

Scenario 1: Park (1)

• What is purpose of this database?oProvide periodic safety reportsoBe ready for “surprise” audits

• What are the entities?oRideo Inspectiono Incidents

• Why don’t we include those nouns safety reports, information record?

Schuffyland Park isamedium-sizedamusementparkinsuburbanPhiladelphia.Theparkisrequiredtoprovideperiodicsafetyreportsto theCommonwealthofPennsylvaniacertifyingitsrides havepassedinspection.Theymustalsokeeparecord ofallsafety-relatedincidents (suchasaccidents)foreachride.Thisinformation alsohastobereadyfor“surprise”audits thatcanoccuranytime.

P1

Scenario 1: Park (2)

• RideoName, Type, Ride ID

• Operatoro First name, Last Name, Operator ID

• IncidentoDate, Time, Description, Incident ID

P2 An incident involves both a ride and an operator. All operators and rides are included in thedatabase whether or not they’ve been involved in a safety incident, and the date and shift arerecordedeachtimeanoperatorrunsaride at the park. Arideisdescribed by a name and type. Anoperator is described by their first and last name. When an incident occurs, its date and time arerecorded along with a description of the incident.

Scenario 1: Park (3)

• Certificationo Title, Certification IDoWhat do we learn from this paragraph except entity certification?

üSentences in green?üAnd the rest?

P3 Operatorsmustbetrainedandcertified on the rides they operate. An operatorcanbecertifiedformultiplerides, and the certification is valid for two years from the date they complete their training.The titleofthecertification indicates the ride for which they are certified. When an incident occurs,it is important that the park can produce a list of current certifications for the operator.

Scenario 1: Park (4)

• InspectionoDate, Time, Score, Notes, Inspection ID

• Inspectoro First Name, Last Name, Inspector ID

P4 Inspection recordsarealsorecordedinthedatabase.Aninspectionoccursataparticulardateandtime,withanumericscore from1to5,andnotes abouttheoutcomeoftheinspection.Thereisonlyonerideperinspection,evenifmultipleinspectionsaredonebythesameinspector onthesamedayandtime.Theinformationthatneedstoberecordedabouttheinspector istheirfirstandlastname.

Draw all entities first

Implement the relationships (1)An incident involves both aride and an operator. Alloperators and rides areincluded in the databasewhether or not they’ve beeninvolved in a safety incident,and the date and shift arerecorded each time anoperator runs a ride at thepark. A ride is described by aname and type. An operator isdescribed by their first and lastname. When an incidentoccurs, its date and time arerecorded along with adescription of the incident.

P2

Implement the relationships (2)Operators must be trainedand certified on the ridesthey operate. An operatorcanbecertifiedformultiplerides, and the certificationis valid for two years fromthe date they completetheir training. The title ofthe certification indicatesthe ride for which they arecertified. When an incidentoccurs, it is important thatthe park can produce a listof current certifications forthe operator.

P3

Implement the relationships (3)P4Inspection records are also

recorded in the database. Aninspection occurs at aparticular date and time,with a numeric score from 1to 5, and notes about theoutcome of the inspection.There is only one ride perinspection, even if multipleinspections are doneby thesameinspector on the sameday and time. Theinformation that needs to berecorded about theinspector is their first andlast name.

We need to figure out the cardinality of the Rest

Scenario 2: SchUber (1)

• What’s the purpose of this database?o Track trips and customersoDrivers and passengers rate each other

• What entities do we have?oDriver, Passenger (Customer), Trip, Rating

AnewPhiladephia startupcalledSchUber isamatchingservicebetweenfreelancetaxidriversandpassengers.Thedatabasetosupporttheservicetrackstrips,customer accounts,andincludesarating systemwheredriversandpassengerscanrateeachother.

P1

Scenario 2: SchUber (2)

• TripoDate, Time, Fare, Trip ID

• Drivero First Name, Last Name, SSN, Email, Driver ID

• Passengero First Name, Last Name, Email, Passenger ID

ThebasictransactionforSchUber isthetrip.Atrip isdescribedbythedateandtime thetripoccursandthefare.Atripinvolvesonedriverandatleastonepassenger.Adriver hasafirstname,alastname,asocialsecuritynumber,andanemailaddress.Apassenger hasafirstname,lastname,andanemailaddress.

P2

Scenario 2: SchUber (3)

• Addresso Street, City, State, Zip Code, Home, Address ID

• Sentences in green do not talk about entities but the relationships.

A trip is also associatedwith at least two addresses. An address is also described by the streetaddress, city, state, and zip code. Eachaddressmustbedesignatedaseitheranoriginordestinationaddress for the trip. Each address also has an attribute which designates the address as a homeaddress 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 theiraccount.

P3

Scenario 2: SchUber (4)

• PaymentoMethods, Expiration Date, Payment IDoWhat should we do with PayPal, Credit Card and Google Wallet?

• Again, sentences in green do not talk about entities but therelationship attributes.

A passenger pays for the trip using any one of the payment methods linked to their account. Validpayment method types are PayPal, Credit Card, or Google Wallet. Credit cards also have anexpiration date, but this information is not needed for PayPal or Google Wallet. Passengerscannotshare a paymentmethod, but if there aremultiple passengers on a trip they can eachpay theirshare, and each of their payments can be a different amount (which should be recorded in thedatabase)tothefare.

P4

Scenario 2: SchUber (5)

• Ratingo Star, Comments, Type, Rating ID

• Nowwehaveidentifiedallentities

The rating system is one of the key features of SchUber. Both drivers and passengers can haveratings, although theymay 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). SchUberuserscanlookupratingsbydriver,passenger,orbytrip (a trip could have more than two ratings if there were multiple passengers onthe trip).

P5

Wedrawallentitiesfirst

Now we implement relationships (1)The basic transactionfor SchUber is the trip.A trip is described bythe date and time thetrip occurs and the fare.A trip involves onedriver and at least onepassenger. A driver hasa first name, a lastname, a social securitynumber, and an emailaddress. A passengerhas a first name, lastname, and an emailaddress.

P2

The relationship betweentrip and passenger is viapayment!

Now we implement relationships (2)Atripisalsoassociatedwithatleasttwo addresses. An address is alsodescribed by the street address,city, state, and zip code. Eachaddress must be designated aseither an origin or destinationaddress for the trip. Each addressalso has an attribute whichdesignates the address as a homeaddress for a passenger – this isuseful for billing and for making arequest for a home pick-up.However, apassengercanonlyhaveone address (their home address)associatedwiththeiraccount.

P3

Now we implement relationships (3)A passenger pays for the trip usingany one of the payment methodslinked to their account. Validpayment method types are PayPal,CreditCard,orGoogleWallet. Creditcards also have an expiration date,but this information is not neededfor PayPal or Google Wallet.Passengers cannot share a paymentmethod, but if there are multiplepassengers on a trip they can eachpay their share, and each of theirpaymentscanbeadifferentamount(which should be recorded in thedatabase)tothefare.

P4

Now we implement relationships (3)The rating system is one of the keyfeatures of SchUber. Both driversand passengers can have ratings,although they may not have anyratings, especially if they juststarted with the service. When adriver or a passenger submits therating, they give a star rating (1 to5), brief comments, and the typeof review (i.e., for driver or forpassenger). SchUber users canlook up ratings by driver,passenger, or by trip (a trip couldhave more than two ratings ifthere were multiple passengers onthe trip).

P5

How to Draw ERD: a Check List

• Step 1: Identify all entitiesoPrimary KeyoAttributes

• Step 2: Implement all relationshipso Identify relationship attributes

• Step 3: CardinalityoMaximum cardinalityoMinimum cardinality