randomaeiou
New member
- Local time
- Yesterday, 22:34
- Joined
- Sep 19, 2011
- Messages
- 1
Hi everybody, I'm a total noob at Access, but have been given a relatively massive database project that I need to complete. (massive in terms of volume of data, but I believe the actual database design to be relatively straightforward.)
Attached is a zip file with a pdf and the beginnings of a database. The story is as such - The pdf contains a proforma that is filled out in hardcopy by hand by a reviewer (i.e. me), based upon raw data from elsewhere. I currently have a mountain of about 800+ forms filled out, sitting in a thick stack on my table, awaiting data entry.
I originally thought that using Excel to capture this data electronically in a form that is easily manipulated would be sufficient - however, I have since discovered the severe limitations of using forms to input data in Excel - specifically, that only 32 fields can be simultaneously captured by an Excel form. I have WELL over 32 fields, and so have been instructed to turn to Access, which I have never used before.
As mentioned, the input will be from these hardcopy forms. The desired output is a raw data table that can then be queried and converted/exported into Excel for manipulation with a statistics package (I have yet to decide on which statistics package, so that is flexible). No printable or visual output is necessary if it takes excessive effort. The queries will not require the entirety of the data set - it will usually involve picking out individual entries with certain fields filled in (a lot of the forms will have most of the fields left empty, such is the nature of the data set), and using anywhere between 2 to about 10 of these fields for statistics. Hence, the desired Excel output should be anywhere between 3 columns (including paperID) and 11 columns, however many rows as there are entries with that particular field filled in.
I have begun constructing the back end of tables for the data - I could technically put the entire data set in one giant table, but I thought to break it into a few more manageable segments rather than a single table with 100+ columns. Now I'm running into trouble trying to create the form to input data and populate all these tables with.
Basically, each unique paper should have an AutoNumber (or some other method I don't know about) ID, which remains constant throughout the tables, and the form will then update the individual tables directly. In this project, all relationships are one-to-one, there will be one entry in each table for each proforma entered.
The unique PaperID is based upon Journal, Year of Publication and 1Author. If this combination is not unique, 2Author (and occasionally 3Author) is necessary - there are no non-unique combinations of Journal, Year, 1, 2 and 3Author.
Can any kind soul help me? Suggestions?
*p.s. - some of the data fields in the proforma and database do not match - this is due to the evolution of the data collection process. The data to be entered will require the fields that have been put into the database, and the proforma can be considered to be an earlier, mildly outdated version. The changes are minor and should not affect the actual coding of the database, which is the bit I need MAJOR help with.
Attached is a zip file with a pdf and the beginnings of a database. The story is as such - The pdf contains a proforma that is filled out in hardcopy by hand by a reviewer (i.e. me), based upon raw data from elsewhere. I currently have a mountain of about 800+ forms filled out, sitting in a thick stack on my table, awaiting data entry.
I originally thought that using Excel to capture this data electronically in a form that is easily manipulated would be sufficient - however, I have since discovered the severe limitations of using forms to input data in Excel - specifically, that only 32 fields can be simultaneously captured by an Excel form. I have WELL over 32 fields, and so have been instructed to turn to Access, which I have never used before.
As mentioned, the input will be from these hardcopy forms. The desired output is a raw data table that can then be queried and converted/exported into Excel for manipulation with a statistics package (I have yet to decide on which statistics package, so that is flexible). No printable or visual output is necessary if it takes excessive effort. The queries will not require the entirety of the data set - it will usually involve picking out individual entries with certain fields filled in (a lot of the forms will have most of the fields left empty, such is the nature of the data set), and using anywhere between 2 to about 10 of these fields for statistics. Hence, the desired Excel output should be anywhere between 3 columns (including paperID) and 11 columns, however many rows as there are entries with that particular field filled in.
I have begun constructing the back end of tables for the data - I could technically put the entire data set in one giant table, but I thought to break it into a few more manageable segments rather than a single table with 100+ columns. Now I'm running into trouble trying to create the form to input data and populate all these tables with.
Basically, each unique paper should have an AutoNumber (or some other method I don't know about) ID, which remains constant throughout the tables, and the form will then update the individual tables directly. In this project, all relationships are one-to-one, there will be one entry in each table for each proforma entered.
The unique PaperID is based upon Journal, Year of Publication and 1Author. If this combination is not unique, 2Author (and occasionally 3Author) is necessary - there are no non-unique combinations of Journal, Year, 1, 2 and 3Author.
Can any kind soul help me? Suggestions?
*p.s. - some of the data fields in the proforma and database do not match - this is due to the evolution of the data collection process. The data to be entered will require the fields that have been put into the database, and the proforma can be considered to be an earlier, mildly outdated version. The changes are minor and should not affect the actual coding of the database, which is the bit I need MAJOR help with.