Link to home
Start Free TrialLog in
Avatar of froshcoach
froshcoach

asked on

Access 2010 correctly configure tables and relationships to retrieve all records

Hi,

I have a functioning Access 2010 DB that I use to keep track of basketball teams for scouting purposes. The basic table concept/design is:
Year>School>Team>Team Summary>Game>Quarter Scores>Player Points>Players

So in any given year a school has a team (players and coaches) that play games and report scores for both the team and the players. Here's the problem.

When setting the relationships, The game table has two entries, one for the Home team, one for Visitor. I can only link from Team Summary to either Home or Visitor in the GameID table but have not been able to work out a design that would allow me to get both home and visitor records as part of the 'normal flow'.

I have been using queries to get to this data but wonder if I have overlooked a re-design that would return both home and visitor records as the result of a relational design rather than making use of queries. I have attached a pdf with the relational map.

Thanks,

Den
2013-2014-Relationship-Report.pdf
ASKER CERTIFIED SOLUTION
Avatar of Norm Dickinson
Norm Dickinson

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of froshcoach
froshcoach

ASKER

tqfdotus,

I had considered separating the game table into two tables but I am still faced with the same problem.

In the current design, if I want to get all of the games played by Team A, I need to interrogate all records in the GamesID table  but the problem is looking for two fields in one record. If I split the table into two I need to check all records in two tables. I'm not sure how I can get this to cascade.

I tested splitting the game table into a home and visitor table but in datasheet view, when I click on the + sign to expand the next level after TeamSummary, I am presented with a dialog to select which table should be next in the path so I can select either home or visitor.

This would appear to be an inherent design problem as there is a split path between the team table and the next step to the game data, either home/visitor field in a record or home/visitor table. Perplexing.

Thanks tqfdotus, hope I'm not missing something simple.
Maybe if you keep the same design you have now, but give games a meaningful identifier based on whether you are recording them from the home perspective or the visitor perspective it could work. For instance, whatever you call a game now, add a single letter to the end of it to record it from the home perspective and then copy all the data to a new record, changing only the single letter designation and switching the relevant info to reflect the other team. That way when you look it up or perform calculations on the data it will be able to consolidate the information the way you want it.
tqfdotus,

No matter how I look at it, this particular scenario has an either/or logic that does not lend itself to the relational nature of the DB that relies on a unique result based on a prior selection.

I just tested by combining home/visitor into one field called team with an extra yes/no field called home. This has the effect of returning all games that a team has participated in but doubles the size of the games table, two records for each game and which requires a complete redesign of forms and queries. It seems, however, that this may be the only option unless a clever solution can be found.

Thanks again,

Den
In effect you will not be doubling the size of the game table if you only record information related to one team for each "game," but instead you will have twice as many "games" with half as much information in each.
a general but accurate assessment of the issue
Thanks. The problem with relational databases is that if you start out on the wrong foot and have data recorded, forms and reports created and generally are using the database, it is extremely difficult to change the fundamentals without having to re-tool the rest. That would be one big advantage of a flat-file database design, albeit probably the only advantage.