"Models" for Relational Tables.

[WWGD]

Hi again, say we are given the relational table:

TEAM(TeamID, TeamName, TeamColor, Game, DatePlayed).

Question is: how many games can we play, meaning, while preserving the properties of relational tables?

This is what I have.We know
We know TeamID, TeamName andTeamColor are fixed in any row , while Game and DatePlayed are variable. All tables will be of this type 1 N1 C1 G_11 D_11

2 N2 C2 G_21 D_21

........

1 N1 C1 G_{1j} D_ {1j}

......

Now, while this is not stated, I would assume either of TeamID, TeamName are candidate keys; two teams
may have the same color. Obviously, we have at least two teams.

 

[phinds]

I know this doesn't answer your question, but that seems like a very awkward way to organize things. It would be way more reasonable in a relational db to have a team table with one entry per team

team ID, team #, team color

and then have each game in a different table with foreign keys into the team table

game #, play date, team 1 ID, team 2 ID

This is a well organized relational structure and imposes no restrictions on the number of teams or the number of games.

 

[WWGD]

Yes, good point, but I am trying to help someone ( for free, or I would have been fired) with some questions from a book.

 

[phinds]

Well, I don't really understand the question then. Why would there be any limit on the number of games played? If there is a specific set of teams and each should only play the other once, then that does put a restriction on the number of games, but I see no specification for that or for a specific number of teams, so there's no answer there.

 

[WWGD]

All I can think is you want to avoid inconsistency: Once a team is selected, the TeamID, TeamName, TeamColor, are determined. But your free to choose a game and a date, so that, e.g., every game played by a fixed team must be played in a fixed date, I think. Maybe we need to use the fact that both TeamID and TeamName are candidate keys, but I am not sure.