Ask Ms. GeekSpeak

By: Laurie Weaver
Member Columnist

Have you been trying to work with Information Technology, but your initiatives and patience grind to a screeching halt? Do the terms they use sound like so much gobbledygook? Do you ever get the sneaking feeling that IT professionals just may, in fact, have come from Mars? If so, you've probably run headlong into some common "GeekSpeak" roadblocks. The aim of this ongoing column is to help forms professionals and technology professionals overcome roadblocks by gaining mutual understanding, vocabulary, and context. So if you need help with specifics, or if you'd just like to know more about a techie topic, email or post any and all questions to Ask Ms. GeekSpeak. This month's topic: "Database 101."

Dear Ms. GeekSpeak, I’d like to know more about databases. What can you share?

I’m delighted to speak about one of our Forms Team’s best tools, the database. In the forms industry, many of us talk about and/or use databases. But what is under the hood of a database?

Most of the time, we think of databases as being computer based, but in the simplest terms, a database is any method by which we store and retrieve data. Surprisingly, even my grandma’s old method of storing her recipes on 3x5 index cards in a recipe box can be considered a database. In that case, just what are the attributes that make up a database?

Let’s start off with Grandma’s recipes. What could she do with those?

Databases store data. If Grandma wanted to remember a great recipe, she’d write it down on a 3x5 card and add it to her recipe box. The card is the recipe record. The box is the recipe table (the main category of the data).

Databases allow retrieval of data. If Grandma wanted to make a recipe again, she could pull the record out of her recipe box, assemble the ingredients from the stored information on that record and make it.

Databases usually have a method to sort data. Now, if Grandma was a disorganized cook, she might have just put her recipes in the box willy-nilly. But then her recipe retrieval would be a matter of looking, one by one, through all of her recipe records. Not very time efficient for a busy lady like my grandma. Her sort method is to have tabs that separate the type of recipe card by main category: cookies, main dish, salads, etc. Then, within the tabs, she would sort alphabetically. This did lead to some interesting confusion when filing “Cousin Betty’s Famous Apple Crumble” — did this go under A, B, C or F?

Databases usually have a method for searching data. Going back to the Apple Crumble recipe — searching the recipe box means going to the correct tab and looking alphabetically by the main ingredient — in this case, “a” for apple. This is my grandma’s logical design for recipes. More on that term later.

Databases usually allow the tracking of historical records and trends. To track her favorite recipes, Grandma draws stars in the upper right-hand corner to indicate a good recipe. Three stars is the ultimate recipe – good, fast and cheap! She also makes notes like “Use a little less lemon zest next time.”

Databases have records that can be created or deleted. Grandma might add an entry card from her friends or relatives if she liked their recipe. However, if a recipe bombed with her family, or turned out to be too time-consuming for the results, Grandma would toss the card, thereby optimizing the speed of future database searches.

Now let’s compare and contrast how Grandma’s recipe box is similar to tracking forms in a database:

Grandma’s Recipes	Forms Team Database
Recipe box on the kitchen table	Forms table within a FileMaker Pro application on a server
Recipe card for each recipe	Form record for each form
Ingredients, notes, instructions about each recipe are the data	Attributes about each form are the data
Entered by writing	Entered via fields
Grandma had pretty much one method of searching the recipe box	The Forms Team can electronically search the Forms Database by job number, due date, location of the production folder, or any other attribute or combination of attributes
Add and remove cards	Add and remove records

OK, now that we have the basics down, let’s take a closer look at our main GeekSpeak database phrase for the day, logical design. Database logical design is how the database designer defines the required tables, fields, and sort criteria. This also includes defining table relationships. Tables are the main categories of data, like forms or recipes. Fields are for the data we wish to track, like job numbers or ingredients. Relationships are how the records and tables relate to other records and tables.

Let’s say Grandma also has an address book of friends and relatives. Within this book, she notes the favorite recipe of each person in case he or she might come for Sunday dinner. What information would she write down that would let her most easily find the correct recipe? In this scenario, she might choose the recipe name. Since recipe name is the same in the address book as in the recipe card box, it would be considered the key between them. This would be similar in concept to creating a separate business contacts table in the Forms Database with one business contacts record for each form sponsor. One method to “hook” these two together would be adding the appropriate contact name to each form record to represent the form’s sponsor.

In order for the database designer to create a good logical design, he or she needs a good understanding about the purpose of the database. What will it be used for? What attributes do you wish to track? What kind of reports might be needed? Who will enter the data? Who will keep up the data? Are there any character limitations?

For more on that thought, see my previous column about crafting better business requirements. Like any other technology, a forms database is only as good as the planning behind it! As always, if you’d like to know more about databases, requirements, Cousin Betty’s Famous Apple Crumble, or any other “geeky” word or topic, post here, or email Ask Ms. GeekSpeak.