Microsoft Access 2010 Tutorials
Access 2010 Basics / Where to Really Start
Visitors to VTC.com will be able to view all introductory videos for each training course.
Free Trial Members will gain access to first three chapters for each training course.
Full Access Members have full access to VTC.com�s entire library of video tutorials.
Learn More
Subtitles of the Movie (Microsoft Access 2010 / Access 2010 Basics / Where to Really Start)
In this video I want to talk to you about where to really start. Now, before we open up Access and begin to build our tables and so forth, let's do this real world stuff here and make sure that we're all on the same page here. The first thing that you need to do when you're working with Access or any database product to create a database is to determine exactly what data you need to manage; that means, what data you need to collect, and then what data you need to report on. Now, the question about what data to collect seems to make perfect sense. If I don't collect it I can't report on it. But you also need to consider what you need to query and report on because that may make a determination on how you collect it and to what level of detail you collect it at the very beginning. So, first thing you've got to know is, what data am I going to try to manage here? Then you need to divide that data into separate related sections. Now, there's no easy way to do this and there's no really pretty way to do this. Some people use Excel, some people use various software things, some just use a legal pad and a pencil. However you do it, make sure that you write the stuff down, make sure you get it down in a form that you can get back to it and you can edit it. Now, as you divide your data into separate related sections, these are going to become your tables. Don't even think about them as tables when you're doing this, just get the data in the related form that it needs to be and these are naturally going to become your tables. Then you need to determine the level of Normalization required. Now, how do you do this? And the answer is, the one you do this time will be a little better than the one you did last time, and that is just the way it is, OK? One of the things that you need to determine is how the database is going to be used - if there's going to be a lot of heavy updates, data edits, adding new rows, deleting rows, and that sort of thing, then you're looking at a kind of a data management type database and there needs to be probably a little more Normalization there. Split your data out into as many tables as you can logically see and then connect these tables with relationships. And, if you're predominantly going to be using these tables for queries to pull data out of, to report on things, then you might want to have more Indexes. And, as you remember, in a different place in the course we talked about how Indexes are cool for pulling data out but they will slow you down on getting the data in. Now, after that, you need to determine your table structures, and by that I mean, what are your Field Names? Because if you do these kind of ad hoc, as you go, as you build the tables, you will inevitably name the same field names in different tables and this will get very confusing for you. Now, in some cases it makes sense - First Name, Last Name, those sorts of things - but just make sure that you don't create your own little abbreviations that mean different things in different tables but are spelled the same way. The Data Types - when you start to establish relationships between tables you have to have the same Data Types. And you can spend a lot of frustrating time jumping from table to table correcting Data Types and getting confused about them. Think about your relationships, which tables are going to join to which tables, and you'll just learn to watch for those One-to-Many Relationships and those sorts of things. Here's the most key thing I can tell you in this video. Maintain good documentation. Even, and I would even say especially, if there is only one designer and that's you, OK? We're now out of the realm of ad hoc, throw something together, start writing some junk down, let's build a database, let's just see what happens. You're going to get into some serious problems there if you do that kind of database construction and design. Now, once we get into creating the database we'll go into Access. We're going to create a database and then we will immediately begin to create our tables based on our documentation. Once we have our table structures all created then we will establish relationships between those tables. Then we will begin to input our data and we'll see at that point if anything is throwing any red flags. And a lot of times, once you start to input data, you can realize real quickly, oh, wait a minute, there is something I forgot. The next thing is you will begin to, once you have a certain amount of your data in, begin to create the queries that are going to feed your forms, your reports, those sorts of things - start to look at the normal ways that you know you're going to have to pull data out of this database. I would put in just a little bit of data, work with my queries just a bit and make sure that I can easily get the data that I want. Sometimes you may have to go back and tweak your table structures just a little bit. And then, once you've got your tables built, your data in those tables, at least some test data, you've written some queries, you're easily getting the stuff out that you need, or not easily, but you are getting the information out of the databases that you need, now you can go start to create your forms to make it a little easier for people to interface with the database. Then you can create your reports so that people can get stuff out. Now, here's kind of a surprising step, but I'm dead serious here. About three months later you can go back and discuss with people how you should have designed the database, and this is just the way it is. It's just like life. Database design is really tricky and there's not necessarily a right way to do it until after you've used it a few months. Now, what's going to happen here is, a lot of times we begin using the database and then used our requirements more based on business changes, political changes in the company, reorganizations, new products, change in company direction, the economy, humidity, all sorts of things, and so, as long as you have that really good documentation on your database, and as long as you understand your database, you should be able to go back and start to make changes there, OK? But trust me, your second database design will be better than your first, your third will be better than your second, and your five-hundredth will be better than your four-hundred ninety-ninth, OK? So that's where you really start. I don't want you to lose that. While we are talking about Access 2010 here, and you're not going to see a lot of this stuff, just know that in the real world when you build these things this is how you should go through it.
Tutorial Information
| Course: | Microsoft Access 2010 |
| Author: | Mark Long |
| SKU: | 34224 |
| ISBN: | 1-936334-91-7 |
| Release Date: | 2011-05-12 |
| Duration: | 9 hrs / 121 lessons |
| Work Files: |
Yes |
| Captions: | No |
| Compatibility: |
Vista/XP/2000, OS X, Linux QuickTime 7, Flash 8 |
VTC Sign up & Benefits
- Unlimited Access
- 81,350 Video Tutorials (14,200 free)
- Video Available as Flash or QuickTime
- Over 715 Courses
- $30 for One Month Access
- Multi-User Discounts Available
