my first database is too much

[kantrobus]

I am just learning Access, and I am working on my first database. I have 31 tables which are connecting company locations, departments, and production figures in those departments. I want to create forms that will allow people within the company to enter production numbers with a date and then be able to run reports showing monthly or quarterly figures.

At this point, I am stumped. None of my tables include dates, and I'm not sure if they should or not. Do I need additional connected tables that would hold the data with the dates? And then I need it to be as simple as possible for those who are entering the data; I have to figure out how to create the forms to collect the information.

I took a day long class on Access, but before that I had never used it at all, so I definitely didn't retain everything. I have no idea what the right next step is, and I don't really know enough to figure it out with just Google, so I hope one of you can help me.

 

[kantrobus]

Two weeks is a very short time frame, but having said that, you can post your DB to a third party site like Dropbox.com or Box.Net and post the link here. Hopefully, someone will have enough time and energy to review what you have done. You will need to explain what you hope to accomplish with what you have. I would not be optimistic about the two weeks and having a production viable database.

Alan, thank you; I'll consider doing that. I'm disappointed to know that two weeks probably not enough time. I do have some flexibility, but my two week deadline would have been ideal.

 

[Joe4]

I agree with Alan, two weeks may be a bit aggressive/optimistic. My first database took 6 months, but it was pretty big/involved, and I was learning as I working on it.

 

[kantrobus]

6 months? I'm thinking 3 or 4 weeks instead of 2 weeks. LOL. I guess it's a good thing I'm a workaholic.

I found a friend who knows Access, so I'm going to look at it with her tomorrow, and if I don't make progress, I'll share here. Thanks for the help!

 

[Joe4]

6 months? I'm thinking 3 or 4 weeks instead of 2 weeks.

Like I said, it was a big database. It was used for billing, IRS tax tracking, and creating various forms.
But I probably spent two weeks learning about Relational Database, Rules of Normalization, and Database Design.
Understanding those are a big must, in order to create a well-designed database, that allows you to complete tasks without too much difficulty.
The big things for me were not to create repeating fields (i.e. if a plan has 20 funds, you do NOT have twenty fields in one record, you have 20 records with one fund).

In a well designed database, once you have it up and running, you seldom have to create new fields in your tables. So if you find yourself having to do that often, it is usually a sign that you hae a design issue. Likewise, when creating queries, if you find yourself having to apply the same criteria to multiple fields, that is another sign you may have a design issue.

 

[jackd]

I agree with Joe4 in that you can easily spend weeks on learning database concepts. The bigger issue is to be able to put those concepts into practice especially if you are new to database, new to an application and/or new to a programming language/software. From experience I would suggest most "new to this situation" development fails to understand the requirement at a detail level. Assumptions are made in hopes of getting something to work and then being able to adjust/refine same with time. Do not overlook the importance of the analysis, build some models (especially on paper where things can be changed easily) and test that model with sample forms(inputs/outputs) sample data and scenarios. Bounce some ideas/approaches with colleagues to ensure you have not overlooked something basic and to get some consensus on the overall picture. Also remember that not all pieces have to be delivered on day 1. Projects have priorities and identifying those and approaching development in that order can make the workload "tolerable". Many database problems can be traced back to basic design--take time to understand the "issue" before jumping into programming and physical database.

Good luck with your project.