Do the reading Bob suggested. I've seen that article before. It is reasonably good.
The first thing you should create is a design on paper. This is because of the "Old Programmer's Rule" that says Access won't do in a computer anything you could not have done on paper first. Drilling down deeper into that rule, you realize that since YOU are the implementer, Access won't do anything you don't understand well enough to tell Access how to do it. So if you can't do it on paper, you can't do it with Access.
Regarding your second question, yes. You do that by assuring that your design list includes that function as a requirement of your database application. This leads to the second "Old Programmer's Rule" that says Access won't tell you anything you didn't tell it first. Drilling down into that rule, it means if you want to see an address, you have to plan to store an address. 'cause if it ain't there, you can't ever see it.
Therefore, in your initial design document, you list the things you want to see (and it wouldn't hurt to think about how you want to see them.) Discovering what you want to see and what you want to do is called "Discovering (or determining) requirements." You don't go ANYWHERE without a list of requirements. Doing so would be the moral equivalent of target shooting while wearing a blindfold.
The next thing that I usually advise is to invest in a big white dry-erase board (which you can use in your business later for other purposes), get some multi-colored dry-erase markers, and invest in a carton of sticky-note pads (and yes, you can use up the rest in your business later). You will use this when you go about the business of table design. Because you do yourself the greatest favor by designing before you attempt to commit your design to Access. No, this commitment isn't cast in stone, but it takes longer to undo an error if you don't discover it quickly and base some other things on the erroneous design.
Here's a little hint: Do you know why government contracts are so lucrative? Because the government makes mistakes and has to correct them, and the contractors are thereby employed not only for the original design but for all the retro-fitting that has to occur. Thus speaks 35+ years of experience in the industry. But I digress...
Before you start the table-design phase, I strongly, urgently advise you to web-search for articles on Database Normalization. Use any search engine you like. Two places that are really nice starting points are Access Help (where the keyword is simply "Normalization" in that case) and Wikipedia.ORG ("Database Normalization").
When you have read through those two articles, search with Google or Yahoo or your other favorite search engine for "Database Normalization" as a phrase. You'll get (conservatively speaking) a gazillion hits. Only look at those articles originating from two general sources: Colleges and universities you know about, almost always in the .EDU domain; and database vendors you know about, almost always in the .COM domain. Select a few articles and read them. But this isn't a never-ending story. When you have read a few articles, you will realize that you recognize everything in the article because you have read it before and understand it. At that point, you are ready to take what you have learned to the drawing board (white-board).
Your goal is to build a representational model of your business using access. Sounds daunting? It is only as daunting as your business model. If you understand every major and most minor facets of your business model, you are already ahead of the game. But if you really don't understand or haven't formalized your business model, you should be tending to your business first and modernizing when your business model is well-defined.
Since you are talking about your own business, you might find an interesting situation. When you are trying to define your table structure to represent the business entities that you need to track, you will suddenly realize that there is something you don't know how to do because your model doesn't cover it. I.e. you found a gap in your own set of business rules. Which might lead you to be able to streamline or strengthen your business before you ever automate anything. Thinking about one's business is never wrong and never a mistake if you want to be successful.
Anyway, search this forum for some other articles with the Design topic. I've written several, as have the other veteran forum members. Don't hesitate to post back here in this or a new thread when you have more specifics.
