Argee's Access Blog

In my last article, I discussed the idea of recognizing 'things' that are similar (and therefore require their own specific table. The second aspect of database design involves distinguishing things from values that describe things. This part of the analysis helps you decide what fields each table will require.

After you have made extensive lists of what you want and need to include in your database, the basic question to ask about each item  one your lists is, "Is this a thing, or the description of a thing?" Just to keep the whole process interesting, many of the descriptions will have their own lists of values which (can you guess?) belong in their own table.

Back to the ice cream, meat, and potatoes analogy, food groups are one of the characteristics that can be used to describe foods. Food groups are categories to which each food belongs. I am not a nutritionist or dietitian so at this point I am assuming that each particular food belongs to a specific food group and that no food can belong to more than one food group.

If I were designing an actual database of course I would have to verify with a food expert or other research whether my assumption is correct. Is there any food that belongs to more than one food group? The answer to that question is at the heart of the next stage of design, determining the relationships between tables.

Staying with determining the values that describe things for the moment (technically these values are known as 'attributes' or 'properties'), clearly understanding and grouping these descriptions is one of the key points in making your database as powerful and flexible as you want and need it to be.

For example, if the furniture table described included the name of each type of furniture in the store, you would only be able to search for tables, chairs, sofas, beds, etc. Adding fields to the furniture table that describe each furniture piece will make the database a far more useful tool in the business.

So you might include fields like typical room assignment, color, price range, style, and so on. Keep in mind that this understanding is vital to your coming up with a solid design and a database that will stand the test of time.

At this point, you might be asking yourself, 'If I need all this information to know my data, where and how do I learn it?' Sure, you may have some general knowledge about the subject of the database is supposed to be dealing with, but how do you ever get to know enough so you can get on with building the database?

I gave a clue to how you go about it a few paragraphs back. Ask the experts. The people for whom you are creating the database most likely do not understand data structuring (that's your job and should be your expertise) they do understand their business and what they want to do with the data associated with the business.

Whether you are working as an independent database developer or are creating databases as part of your day to day employment, the person or people who requested the database or who will be working with it after you build it are your clients. Recognize that your clients are the subject matter experts for the database. They know the 'what', what the data is about and what they want to do with the data.

Your job as the database designer is to come up with the 'how.' How can all this data be best organized so that mountains of raw data can be turned into gems of information that will help your clients manage and grow their business. So look to you clients for the 'what' but do not let them dictate the 'how.'

Data in its raw state is essentially useless. Distilling and refining data by organizing it into a database is a key step in turning raw data into a wealth of business information. Understanding the data opens the door to getting it organized.

The next article will discuss the third aspect in understanding your data from a relational point of view: determining the relationships.