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
froshcoachAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
Norm DickinsonConnect With a Mentor GuruCommented:
Database normalization is the key to relational databases and what sets them apart from simple flat files. You seem to have gotten to a level of normalization that is one step shy of what you need to work with the data in a meaningful way, so a little redesign is probably in order. For some good tips and an overview, see http://office.microsoft.com/en-us/access-help/database-design-basics-HA010341617.aspx.

In this case you may want to rethink the division of home team / visiting team, and instead create a separate entry to reflect each game, from each team's perspective instead of just from the home team's perspective. Sure, it will give you twice as many "games" to track, but it will let you design the relationships you need. Relational databases are great at storing lots of information like that without taking up lots of extra room, so it should remain efficient.
0
 
froshcoachAuthor Commented:
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.
0
 
Norm DickinsonGuruCommented:
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.
0
Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
froshcoachAuthor Commented:
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
0
 
Norm DickinsonGuruCommented:
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.
0
 
froshcoachAuthor Commented:
a general but accurate assessment of the issue
0
 
Norm DickinsonGuruCommented:
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.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.