Using Crows Foot notation make this database design base on

Using Crow´s Foot notation make this database design base on following:

You have been asked by the Waterloo Recreational Sports Association (WRSA) to help
them with their database design. The WRSA has come up with a database specification
and included it in the next section. You will be required to create an ER model based
on the specification. Once you have created the ER model you will map it to a relational
model using the steps from lecture.

Requirements/Specification

The WRSA oversees several sports. Each sport has a unique name, the number of referees
required to referee matches of that sport, and a list of locations where the sport can be
played. For simplicity, each location is a single string. The WRSA is comprised of many
teams. Each team plays exactly one sport, and every sport has some team associated with
it.

Each team has a unique name. A team may choose to have one or more coaches.
However, since the WRSA is recreational, teams are not required to have a coach. Coaches
have a name, address, phone number, and certification date. Players who are registered in
the WRSA are members of teams. Each player can be a member of multiple teams, but
they must be a member of at least one team. Players have a name, age, phone number,
and address. Coaches and players are covered by the WRSAs insurance and each have an
insurance number. Each player must have at least one emergency contact. The emergency
contacts each have a name, address, relation to the player, and phone number. A player
cannot be a coach and cannot have two emergency contacts with the same name. The
WRSA selects several players to act as mascots. Each mascot must have a nickname.

Every team plays in matches with other teams. A match is given a unique match number,
a location, and a date and time. Matches are always between two different teams and the
outcomes are recorded. Each match is refereed by a coach that is not involved in that
specific match.
Part 1: ER model
Create a ER model based on the database description. Make a registrant entity that is a
superclass of players and coaches. Give registrants unique IDs.
For each entity you create, ask yourself:
• what are its attributes?
• what attributes can make up its key?
• is the entity weak?
• is the entity a subentity of another entity?
• what relationships does it have with other entities?
• are any attributes multivalued?
For each relation you create, ask yourself:
• what are the cardinality/participation constraints?
• is this an identifying relationship?
Come up with at least one derived attribute and include it in your ER model.
Part 2: Relational model
Create a relational schema based on your ER model. For each constraint implied by your
ER model, ask yourself:
• is the constraint captured in your relational design? (if nor, briefly explain why)

Solution

I called it the “inverted arrow.” at the time to distinguish [it] from Bachman’s notation. I prefered it to the arrow because it did not imply directionality or a physical access path, and it was visually intuitive, showing manyness. Others then started referring to it as chicken feet (e.g., Carlis textbook ¹). I now prefer to call it a FORK, which is short and to the point, and doesn’t require the possessive crow’s or the longer chicken. In my original paper, the focus was on “Basic data structures explained with a common example” ² (the title, which later became chapter 4 in my McGraw Hill text, Database Management, 1986). The use of the notation was incidental though carefully chosen. I like the fork since it can easily be represented in a standard character set as in:

[ X ]------<[ Y ]

showing that an individual X can relate to multiple Ys (and each Y relates to at most one X).