1  In step1:
We map all the entities types into tables and define their primary keys PKs and alternate keys AKs. Note that Colors in TEAM is a multi-valued attribute and as such will be handled in Step 7.

S1	COACH(Name,Age);
S1	PK(Name)

S1	PLAYER(Name,Age);
S1	PK(Name)

S1	TEAM(Name,Color);
S1	PK(Name)

S1	STADIUM(Name,Size,Location)
S1	PK(Name)

S1	GAME(Number,Date,Socore,Time)
S1	PK(Number)

2  In step2:
We do not take any action, since there are no weak entities satisfying the 1:1 relationship constraint.  
3  In step3:
We do not take any action, since there are no weak entities satisfying the 1:N relationship constraint. 

4  In step4:
We consider the binary 1:1 relationships. Here MANAGES is such a relationship.We choose the COACH table into which to capture (collapse) the relationship.

S1	COACH(Name,Age,Team);
S1	PK(Name)
S4	FK(Team) -> Team(Name)

5  In step5:
We consider 1:N relationships. Here we have one such relationship, namely, PLAYS-FOR. In this case, we choose the table that corresponds to the N-side of the relationship and collapse the relationship in the selected table including all the attributes of the relationship as columns in the table. We choose PLAYER
for the relationship;

S1	PLAYER(Name,Age,PlayedTeam);
S1	PK(Name)
S5	FK(PlayedTeam) -> Team(Name)

6  In step6:
We consider the M:N relationships. Here PRACTICE is such a relationship. We create a new table to store this relationship and its attribute, namely Date. The relationship is expressed using foreign keys. For each participating table, here, Team and Stadium, we include a foreign key referring to their primary keys, Name of TEAM and Name of STADIUM. 

S6 	PRACTICE(Team,Stadium,Date);
S6 	PK(Team,Stadium,Date)
S6	FK(Team) -> TEAM(Name)
S6	FK(Stadium) -> STADIUM(Name)

We consider the N-arys relationship.Here PLAYSWITH is such a relationship.We create a new table to store this relationship.It has three attributes,namely,Host,Visitor and Game, to which we include a foreign key referring to the primary key of HOST Team,VISITOR Team and Game.

S6	PLAYSWITH(Host,Visitor,Game);
S6	PK(Host,Visitor,Game)
S6	FK(Host) -> Team(Name)
S6	FK(Visitor) -> Team(Name)
S6	FK(Game) -> Game(Number)

7  In step7:
We consider all multi-value attributes. Here, we have one multi-valued attribute, namely, Colors in TEAM. We store such an attribute as a separate table, e.g., COLORS, whose rows correspond to each of the values of the multi-valued attribute. In order to relate these values to the originating table, we include the primary key of the originating table, in our case, TEAM, as a foreign key in COLORS. 

S7	COLORS(Color,Team);
S7	PK(Color,Team)
S7	FK(Team) -> TEAM(Name)

------------------------------------------------------------------------------------------

Let us conclude by listing the entire relational schema produced above. It is worth recalling here that PK, AK, and FK correspond to PRIMARY KEY, UNIQUE and FOREIGN KEY REFERENCES statements, respectively, in SQL.

S1	COACH(Name,Age,Team);
S1	PK(Name)
S4	FK(Team) -> Team(Name)

S1	PLAYER(Name,Age,PlayedTeam);
S1	PK(Name)
S5	FK(PlayedTeam) -> Team(Name)

S1	TEAM(Name);
S1	PK(Name)

S1	STADIUM(Name,Size,Location)
S1	PK(Name)

S1	GAME(Number,Date,Socore,Time)
S1	PK(Number)

S6 	PRACTICE(Team,Stadium,Date);
S6 	PK(Team,Stadium,Date)
S6	FK(Team) -> TEAM(Name)
S6	FK(Stadium) -> STADIUM(Name)

S6	PLAYSWITH(Host,Visitor,Game);
S6	PK(Host,Visitor,Game)
S6	FK(Host) -> Team(Name)
S6	FK(Visitor) -> Team(Name)
S6	FK(Game) -> Game(Number)

S7	COLORS(Color,Team);
S7	PK(Color,Team)
S7	FK(Team) -> TEAM(Name)