I am trying to make simple app for chess tournaments, but I have problem with database, I have users that participate in tournament (thats fine) but how do I give users to the round and match, should i make another relations user_tournament-round-tournament, user_tournament-match-round?
Please see this answers a food for though rather than a solution. In your question there is not enough information to fully cover all use cases, so the answer below contains a lot of speculation.
In my over simplistic view and picking up on your initial model, the tournament_competitors (renaming from user_tournament as we have competitors and not users) table would create a unique id for each enrolled competitor. This id would be used as a reference in a tournament_matches table (the table would link twice to the tournament_competitors this table would connect two opponents - constraint warning). The table would also register the match type.
For the match type, I see two possibilities.
The matches table would list all possible match types (final, semi-final, quarter-final, elimination rounds, etc.) and these would be referred to in the tournament_matches table via id (composite key in the form tournament_id-competitor_id-group_id). This approach, specially for the elimination round matches, requires the need to find a way to link the number of competitors in each elimination group with then number of matches each competitor has to through before they are considered eliminated or not - creating a round number. I see this as a business logic part so not on the DB. The group_id also needs to be calculated and it would be best done on the application.
The alternative is to have the various match types in the tournament_matches table as a free field - populated by the application. The tournament structure (Number of Groups, number of opponents in each group, etc.) would be defined as attributes in the tournaments table. In this view there is no need for the rounds table.
If I have a fact table for various NFL Teams. One of the relationship is between a Player and a Team. A team contains many players. If the fact table is based on the Season+Team how would I add a one-to-many key from the player to the fact table? The below is what I currently have:
The short answer is that you wouldn't add a one-to-many key from the player to the fact table. Instead you would add a bridge table between the Team Dim and the Player Dim.
Longer Answer/Background...
When you design a fact table you need to define its grain i.e. which dimensions uniquely identify each record in the fact. Once you have defined this grain you should never make any changes to the design that will change the grain (unless you've realised that the initial grain was wrong and you need to re-define your fact table from scratch.
You've defined your fact table grain as Season+Team and therefore you cannot add Player to your fact table as this would change the grain.
If you do add a bridge table then it will allow you to report on your fact by player but it also introduces a risk to your reporting that you need to be aware of. For example, you can show wins per year per player but you can't aggregate up these results as your wins would be double counted (every player in the same team is effectively claiming those same wins)
I am working on an app that tracks which tv shows you are watching and which episodes from that show you have watched.
Currently I have can track which users are watching which shows, this is relatively simple and it is structured like so:
table structure
So I have a User table which has a primary key id that identifies that user and some other info about that user which is not relevant.
Following this I have another table TV_SHOWS which stores a user_id as a foreign key some information about the show and crucially a field called user_watching that gives a boolean value as to whether the user is watching that show.
How it works is this, when the user clicks a button to add the show a row is inserted into the TV_SHOWS table with the all the information and user_watching = true at some point the user may wish to stop watching so they can click another button that will simply update the user_watching = false.
Now I wish to expand on this idea so that users can track which seasons and episodes of a tv show they have watched, a tv show is comprised many seasons and each season is comprised of many episodes in most cases.
I would like some help with how best to structure this database schema.
I initially thought that I could just expand along the same lines I had previously for instance:
I simply add two id's for the season and episode, in that way I can tell if a user has watched a season by seeing if they have watched all the episodes in that season and if they have watched a show by checking if they have watched all the seasons in the show, but I don't think this seems like good practice.
I could try and do a one table for shows, another for seasons and a final for episodes but I am not sure where I would "track" is a user had watched one of those, would it have to be in that specific table or would I need another table to track it?
Short answer: I think the latter design is a better option from a scalable design perspective.
Longer Answer:
The latter option with show <--> season <--> episodes separated into individual tables is closer to a textbook design. Third Normal Form, I think. The idea being that you want to reduce redundant data as much as possible, as to minimize storage space. Minimizing redundant data is a general best practice. By separating the three you are able to keep attributes that are specific to the each topic from being replicated.
For example, let's assume you track TV Show attributes like title, description or an average ranking. If you maintain a single table with show/season/episode, then the TV Show attributes should technically be replicated (i.e. redundant) for every season and every episode in order to maintain a table constraints. Conversely, separating out the TV show attributes avoids the redundant attribute data. It also helps to allow the attributes set to grow/change overtime.
This design practice though comes with a computational cost as you need to JOIN the structures together depending upon the use cases. For example, if you always need to know show title, season X, and episode title (attributes from each of the tables), then you'll need to develop the necessary join logic to obtain those attributes. This cost can be mitigated using a View, which opens another set of decisions.
To your comment on the need for two keys. Following the three table design, you'll likely want a primary key of some sort on each table. If you structure the episode table with reference key to the season (and maybe the show), then you should only need to use the episode key as you can de-reference the season and TV show from the episode using join logic. In effect, the episode should be enough to figure out the season and TV show from the linking.
-- User USR exists.
--
user {USR}
PK {USR}
-- TV show SHW exists.
--
show {SHW}
PK {SHW}
-- Season number SEA# of show SHW exists.
--
season {SHW, SEA#}
PK {SHW, SEA#}
FK {SHW} REFERENCES show {SHW}
-- Episode number EPI# of season number SEA#
-- of show SHW, in duration of DUR_E minutes, exists.
--
episode {SHW, SEA#, EPI#, DUR_E}
PK {SHW, SEA#, EPI#}
FK {SHW, SEA#} REFERENCES season {SHW, SEA#}
-- User USR watched DUR_W minutes of episode number EPI#
-- of season number SEA# of show SHW.
--
user_show {USR, SHW, SEA#, EPI#, DUR_W}
PK {USR, SHW, SEA#, EPI#}
FK1 {SHW, SEA#, EPI#} REFERENCES
episode {SHW, SEA#, EPI#}
FK2 {USR} REFERENCES user {USR}
Note:
All attributes (columns) NOT NULL
PK = Primary Key
FK = Foreign Key
Using suffix # to save on screen space.
OK for SQL Server and Oracle, for others use _NO.
For example, rename EPI# to EPI_NO.
OK, so I will probably get slaughtered for being lazy and not researching this myself - but I just can't get my head around it and it is making my brain hurt. And I am sure for some of you guys out there it is a pretty basic problem.
I have one Excel table with football (soccer) players and their attributes...
Player Table
and another with six-a-side football (soccer) teams, with six players in six positions.
Teams Table
I want to be able to link the two tables so that I can make aggregate team attributes based on the player attributes and then run queries on the qualities of the teams (i.e. best passing teams, most aggresive teams etc).
In Excel I would just do a vlookup from the player table into the teams table and then add up various combinations of the attributes of the players.
However in SQL it seems complicated - i.e. each team has many players, any one player can be in more than one team and any one player can play in a number of different positions. Which position the player plays in affects the weighting it contributes to the team attributes (i.e. a defender would contribute less to the teams creativity than an attacking midfielder, and more to the teams tackling ability than a forward). I think I need an intermediate join table or maybe several? Or maybe it is just simple after all?
Does anyone have any suggestions?
thankyou
Ben
If I get your question, the answer is the following. You will have a table for players (PlayerID, PlayerName, PlayerAtribbute1,...), a table for the teams (TeamId, TeamName, HomeTown,...) and an intermediate table for the connection of the two (PlayerId, TeamId, Position,...). The last intermediate table is used in SQL and database design to represent many-to-many relationships.
If you go with this approach, you should also index PlayerId in the Players table, TeamID in the Teams table and have a composite index on (PlayerId, TeamID) in the intermediate table and you should be golden.
The missing piece in the jigsaw in my mind was the composite index in the join table (provided by S Karras). I can now take this forward and see how it progresses.
What is the best database schema to represent an NCAA mens basketball bracket? Here is a link if you aren't familiar: http://www.cbssports.com/collegebasketball/mayhem/brackets/viewable_men
I can see several different ways you could model this data, with a single table, many tables, hard-coded columns, somewhat dynamic ways, etc. You need a way to model both what seed and place each team is in, along with each game and the outcome (and possibly score) of each. You also need a way to represent who plays who at what stage in the tournament.
In the spirit of March Madness, I thought this would be a good question. There are some obvious answers here, and the main goal of this question is to see all of the different ways you could answer it. Which way is best could be subjective to the language you are using or how exactly you are working with it, but try to keep the answers db agnostic, language agnostic and fairly high level. If anyone has any suggestions on a better way to word this question or a better way to define it let me know in the comments.
The natural inclination is to look at a bracket in the order the games are played. You read the traditional diagram from the outside in. But let's think of it the other way around. Each game is played between two teams. One wins, the other loses.
Now, there's a bit more to it than just this. The winners of a particular pair of games face off against each other in another game. So there's also a relationship between the games themselves, irrespective of who's playing in those games. That is, the teams that face off in each game (except in the first round) are the winners of two earlier games.
So you might notice that each game has two "child games" that precede it and determine who faces off in that game. This sounds exactly like a binary tree: each root node has at most two child nodes. If you know who wins each game, you can easily determine the teams in the "parent" games.
So, to design a database to model this, you really only need two entities: Team and Game. Each Game has two foreign keys that relate to other Games. The names don't matter, but we would model them as separate keys to enforce the requirement that each game have no more than two preceding games. Let's call them leftGame and rightGame, to keep with the binary tree nomenclature. Similarly, we should have a key called parentGame that tracks the reverse relationship.
Also, as I noted earlier, you can easily determine the teams that face off in each game by looking at who won the two preceding games. So you really only need to track the winner of each game. So, give the Game entity a winner foreign key to the Team table.
Now, there's the small matter of seeding the bracket. That is, modeling the match-ups for the first round games. You could model this by having a Game for each team in the overall competition where that team is the winner and has no preceding games.
So, the overall schema would be:
Game:
winner: Team
leftGame: Game
rightGame: Game
parentGame: Game
other attributes as you see fit
Team:
name
other attributes as you see fit
Of course, you would add all the other information you'd want to the entities: location, scores, outcome (in case the game was won by forfeit or some other out of the ordinary condition).
For a RDBMS, I think the simplest approach that's still flexible enough to accommodate the majority of situations is to do the following:
Teams has [team-id (PK)], [name], [region-id (FK to Regions)], [initial-seed]. You will have one entry for each team. (The regions table is a trivial code table with only four entries, one for each NCAA region, and is not listed here.)
Participants has [game-id (FK to Games)], [team-id (FK to Teams)], [score (nullable)], [outcome]. [score] is nullable to reflect that a team might forfeit. You will have typically have two Participants per Game.
Games has [game-id (PK)], [date], [location]. To find out which teams played in a game, look up the appropriate game-id in the Participants table. (Remember, there might be more than two teams if someone dropped out or was disqualified.)
To set up the initial bracket, match the appropriate seeds to each other. As games are played, note which team has outcome = Winner for a particular game; this team is matched up against the winner of another game. Fill in the bracket until there are no more winning teams left.
Since you didn't specify RDBMS, I'm gonna be a little different and go with a CouchDB approach since I was reading about that this weekend. Here's the document structure I've come up with a represent a game.
{
"round" : 1, //The final would be round 5, and I guess Alabama St. vs. Morehead would be 0
"location" : "Dayton, OH",
"division": "South",
"teams" : ["UNC", "Radford"] //A feature of Couch is that fields like teams don't need a fixed nuber of columns.
"winner" : "UNC" //Showing my bias
}
A more interesting or complete application might have data for teams, rankings, and the like stored somewhere as well. John's approach covers that angle well, it seems. I welcome any comments from people who know better on my Couch skills.
I created a small system with the following tables:
Games: GameId, TournId, RoundId, Sequence, Date, VisitorId, VisitorScore, HomeId, HomeScore, WinnerId, WinnerGameId, WinnerHome (bit)
Predictions: PredId, UserId, GameId, PredVisitorId, PredHomeId, PredWinnerId
Rounds: RoundId, TournId, RoundNum, Heading1, Heading2
Teams: TeamId, TournId, TeamName, Seed, MoreInfo, Url
Tournaments: TournId, TournDesc
Users: TournId, UserName
WinnerGameId connects the winner of a game to their next game. WinnerHome tells whether the winner is the home or visitor of that next game. Other than that, I think it's pretty self explanatory.
Proposed Model
Proposed ER Diagram http://img257.imageshack.us/img257/1464/ncaaer.jpg
Team Table
All we need to know about a team is the name and seed. Therefore we need a "Team" table to store the seed value. The only candidate key is team name so we will use that as the primary to keep things simple. NCAA team names are unlikely to change over the course of a single tournament or contain duplicates so it should be an adequate key.
MatchUp Table
A "MatchUp" table can be used to pair the teams into each of the match ups. Foreign Keys (FK1, FK2) to the "Team" will ensure that the teams exist and a primary key over these values ensures that teams are only matched up against each other once.
A foreign key (FK4) to the "Team" table from the "MatchUp" table will record the winner. Logically the winner would need to be one of the two teams participating in the match up. A check constraint against the primary key could ensure this.
Once the outcome of a match up has been determined the Victor's seed could be retrieved from the team table in order to compare against other Victor's in order to determine subsequent match ups. Upon doing so an FK (FK3) to the resulting match up can be written to the determining match ups in order to depict the progress of the tournament (although this data could probably be derived at any time).
Games Table
I also modeled out the games of each Match Up. A game is identified by the match up it is a part of and a sequence number based on the order in which it took place during the match up. Games have a winner from the team table (FK2). Score could be recorded in this table as well.
4 tables:
Team(Team, Region, Seed)
User(UserId, Email, blablabla)
Bracket(BracketId, UserId, Points)
Pick(BracketId, GameId, Team, Points)
Each bracket a person submits will have 63 rows in the Pick table.
After each game is played you would update the pick table to score individual picks. Points field in this table will be null for game not yet played, 0 for an incorrect pick or positive number for correct pick. GameId is just a key identifying where in that users bracket this pick goes (ex: East_Round2_Game2, FinalFour_Game1).
The points column in the bracket table can be updated after each update of the pick table so it contains the sum of points for that bracket. The most looked at thing will be the standings, don't want to re-sum those every time someone wants to view the leader board.
You don't need to keep a table with all the games that actually get played or their results, just update the pick table after each game. You can even do the bracket highlighting of correct/incorrect picks by just looking at the Points column in the pick table.
In keeping track of a large number of different bracket predictions: You could use 67 bits for keeping track of the outcome of each game. (ie. Each of the sixty-seven games played in the tournament is each represented by a bit, 1 = "team A wins", 0 = "team B wins"). To display any given bracket, you can use a pretty simple function to map the 67 bits to the UI. The function knows the team names and their initial location, and then it tracks their movement through the bracket as it traces the 'bitboard'.
I use the same schema for all of my databases.
t
--------
1 guid PK
2 guid FK
3 bit
Then in my code:
select [2],[3] from t where [1] = #1
#1 is the id of the data I am fetching. Then if [2] is not null, I select again, setting #1 to [2].
This makes it really easy to model the situation you posted.