1. Player Entity:

- Attributes:

- Social Security Number (SSN) [Unique Identifier]

- Name

- Major

- Grade Point Average (GPA)

2. Team Entity:

- Attributes:

- University Name [Unique Identifier]

- Current Ranking

- Capacity of Home Court

- Number of Players

3. Game Entity:

- Attributes:

- Game Number [Unique Identifier]

- Final Score

- Attendance

- Date of the Game

Explanation:

Now, let's define the relationships:

- A "Player" plays for a "Team," and a "Team" can have many "Players." This is a one-to-many relationship.

- A "Game" involves at least ten "Players." This is a many-to-many relationship between "Game" and "Player."

A "Game" is

associated

with a "Team," where the "Team" is one of the participating teams in the game. This is also a many-to-many relationship between "Game" and "Team."

To capture the business rules and constraints:

1. Maximum and minimum player limits for a "Team" (between 13 and 20 players) can be

enforced

in the application logic or as part of a semantic integrity constraint.

2. Ensuring that a "Player" can play for only one "Team" can also be enforced in the application logic or using a unique constraint on the "SSN" attribute in the "Player" entity.

3. The requirement that a "Game" involves at least ten "Players" can be documented as a business rule.

19. This exercise contains additional information in the form of deletion rules that will enable us to develop a Design-Specific ER diagram for the NCAA database in Exercise 18. If a team is canceled, Likewise, all links to the players for that team should be dropped. a. Incorporate the above business rules in the Presentation Layer ER diagram for the NCAA database developed in the previous exercise. b. Transform the design in (a) to a Design-Specific ER diagram