Student new to access

[walter21907]

Hello my name is Walter and I’m working receiving my Bachelors of Business Administration Degree from the University of Alaska. I’m currently taking a Microsoft Assess class as part of the degree program. The instructor has asked us to follow and to post to an Access Forum. So if anyone has any tips or tricks that will help me earn a good grade I would greatly appreciate. Thanks Walter

[ssanfu]

Welcome to the forum!

UAA or UAF?

Microsoft Assess class as part of the degree program

My #1 suggestion would be to understand normalization.

[walter21907]

My Access class is based out of UAF but my degree program is actually with UAS. I’ll make sure to pay extra attention to normalization when we get to that section, thank you for your help.

[ItsMe]

Start with your tables.

Access is a data management tool. Use Access as a tool to design applications that offer a GUI to manage data.

It is tempting to go straight to building forms. Start with your tables (relations). Look at your tables using Access queries. Then go back to your tables.

[Dal Jeanis]

Two sites to go to first -

First, Access MVP Roger Carlson's site at http://www.rogersaccesslibrary.com/ has some great tutorials and exercises on database design.

Second, Access MVP Crystal Long's site at http://www.accessmvp.com/strive4peace/. She has posted (free) her book on beginning Access. It's based on 2003, but all the basic concepts are the same.

Third, do the free Access 2010 tutorial at FunctionX - http://www.functionx.com/access/

That's enough basics. From then on, you need to actually do something with Access, make mistakes, get confused, and ask for help.

Get help, understand something, repeat.

After you get your legs under you, start reading forums looking for problems that YOU can help with. Anything you ALMOST know how to do, figure it out, post an answer.

Be right, be wrong, learn something. Repeat. Forever.

[June7]

Correctly identifying data entities and how they relate and normalizing table structure is essential to good database design. However, I am of a mind that normalization can sometimes be taken too far. In a 'real world' situation, I find it a balancing act between normalization and ease of data entry/output. I have a database that certainly violates normalization but it better suits requirements for most of our entry/output. I have to do some manipulation of data to emulate normalization (note: UNION query) and in all cases this involves graphing of data. If I normalized the structure to accommodate these few graphs, I would face more complication and frustration in design of queries, forms, reports to accomplish the primary purpose of this db, which is to publish a report for each laboratory sample that presents the data from numerous tests performed. Other than the graph representations, we do very little data analysis and essentially never search/filter/sort on test data.

Good luck with your classes.

[Dal Jeanis]

Absolutely agree with June7 about normalization.

First, learn how to do it so that it becomes natural to think in terms of normalized tables. (Roger Carlson's entity relationship exercises will help you get there.)

Then, learn what times it is more appropriate NOT to normalize. If you are currently in a class, the chances are good that the answer for you right now will be "never until I get out of this class", since teachers tend not to have much real world experience.

Later, you'll learn that the proper level of normalization is based primarily on how your database is used. Properly selected redundant data can cut your query time to a fraction, at the cost of disk space and a little extra overhead on updates.