Databases
For a project i need to produce a database for a firm but i am having huge problems doing this. Is there anyone out there who's brain i can pick on msn, aim etc about this or that is willing to help. Normalisation has got me stumped and i am about ready to die....
edit: i am using microsoft access by the way
edit: i am using microsoft access by the way
0
Comments
I just moved to Colorado new email here is mwithers@alephia.net. I can still be reached at the old email linked to this site or by PM also.
I still have to bring the rest of our network up this afternoon so I'll be scarce untill afternoon/evening time her in the mountain time zone. Been using Robins computer just to check email basicaly.
Tex
Tex
Example:
A simple address database would use a unique record as the key. Typically you wouldn't make it a person's name because what happens if you have to JOHN SMITH names?
You may assign it, as an example, as a keyword ADD0001 (it gives you a clue...address = add and 0001 allows you 9999 unique entries.
The rest of the information stored in that record could be a space for the persons first name, last name, apt number and so on.
Your query would then use the KEY and be coded to display by whatever record you wanted...person's last name for example. So once you build your query in the interface...through a pull down menu, for example, by selecting the person's last name then it would display the corresponding information as you so designated in your query.
Where databases start to become more complex is when you run multiple databases and begin to link them together.
For example: An employee database with contact info could be linked to a project file...which is then linked to a supporting database of material names and associated costs. The three work together to assemble the final information.
Basic tip:
Design databases on paper first to get an idea of the relational structure based on the "thing" you want the database to do. Plan..plan and more plan before you begin working on the computer. It's a good idea to understand your database and what you want it to do before trying to build it.
Always enter information once. You wouldn't enter a person's name in two root databases. You may pull information from one database to import into another but that is what the KEY is for. The KEY is one entry that represents a lot of records.
Once you have your database tables built THEN you can begin to hang queries on them...and finally...build the GUI.
I hope this helps.
Last piece of info. ACCESS can seem a bit complex when first looking at it. I used a couple of books on ACCESS databases (not the MS ones) to help me understand how to build queries etc. They really helped.
But...in time you can become much more proficient on it. The last time I really dealt with ACCESS was some time ago though.
Tex