Ever since version 4.0, FileMaker Pro has been capable of serving its data directly to the World Wide Web as the back end of an online product catalog or for an online store. FileMaker can make fast ODBC connections with other powerful, popular databases such as Microsoft SQL Server and Oracle.
And FileMaker supports third-party plug-ins, which can add all kinds of useful functionality like credit card validation, graphing and charting, and file management. All this for a price even a one-employee not-for-profit can afford. In addition, since version 5.0, FileMaker Pro “plays nice” in a predominantly Microsoft Office-ized world with its new, Office-like interface (detachable menu bars and such) and seamless
Excel imports. Yes, FileMaker Pro has definitely come of age, and it has a very exciting future. This is for those of you who are new to the world of databases. You’ll discover what a database is and what it’s made of. You’ll also learn the difference between flat-file and relational database systems. Next, you’ll fire up FileMaker Pro and explore its easy-to-understand environment and discover the elements of its interface (what its buttons, menus, and windows do).
Try not to get too put off by the many strangely named terms and concepts introduced here, especially if you are new to relational database development. As you begin to use FileMaker Pro, you’ll find out pretty quickly just how easy it is to get up and running with it. Before long, you’ll start to see the big picture, and a lot of what you didn’t previously “get” will fall into place. As you get further along with FileMaker, some of the advanced stuff such as ODBC connections and XML can be tricky, but you certainly don’t have to be a computer science major (the author majored in Theatre Arts) or attend weeks of training classes to master FileMaker Pro. Just give it a go and practice, practice, practice.
What Is a Database?
Every time you wait in line to get grocery money out of an ATM, you are waiting to access a database. Whenever you are asked for your zip code while paying for a DVD at your local audio or video superstore, you are being asked so that the store’s corporate office can track your buying habits in a database (and perhaps track how far you travel to indulge these habits). Even when you go to a public library to find a woodworking how-to book, chances are you’ll use the library’s electronic card catalog (database) to find out on what shelf and in what section your desired book lives.
A database is essentially a structured collection of information stored in an organized manner. Yes, “organized” is a relative term people have rather different views on what constitutes being organized but the definition holds.
When you think of databases, you probably can’t help but think of electronic ones, like the one at the public library or the one in the sales department at your place of business, but even a nonelectronic object could be considered a database, like that dusty recipe box on your kitchen counter, for instance. A recipe box contains a collection of information stored, probably, on index or Rolodex cards. The cards are filed in the box in an intelligent manner, usually alphabetically, maybe also by type of recipe (main course, dessert, or appetizer) separated by tabbed “type” dividers. And, inked on the surface of the cards themselves, the recipe is typed or handwritten in a generally regular way, with a name for each recipe, ingredients in specific quantities, and directions for how to transform the ingredients into the final product.
Beyond the idea that a database holds data, a useful database also allows a user to view the data in meaningful ways, such as by sorting the data, summarizing it, creating meaningful reports based on it, and isolating sets of data by querying it. (Queries are questions asked of the database such as “Give me all customers who live in the state of California” or “Give me the top five sales reps in Dresden, Germany.”)
A good database will also have a pleasant and well-designed interface, that which the user sees and interacts with by clicking with their mouse or entering information from the keyboard. Figure below shows an example of a data-entry screen for a simple recipe database created in FileMaker Pro.
Data-entry screen for FileMaker Pro recipe database
In our recipe box example we introduced a few of the main parts of a database, so let’s give names and definitions to these parts, as shown in below on the following page.
First, we have a table. A table is an object that holds data of only one type, like a recipe. The recipe box, the wooden enclosure itself, is the table in this example.
A much more complex database would comprise many tables. For example, you might have a completely separate table in your database to keep track of the source of each recipe (like Grandma, a magazine article, or a cooking Web site) and then link this source table to your recipe table via a relationship.
A table, in electronic terms, comprises rows and columns; respectively, records and fields in the FileMaker world. A record is one individual set of data in a table. For instance, one of the cards in the box, the recipe for Mama’s Famous Shortbread, would be one record. The next card, Marsha’s Mean Malted Milkballs, would be another record.
A simple recipe box database. The recipe box is the table, and every recipe card is a record in this table; RecipeName is a field that contains a value in every record in this table.
Each record in turn comprises one or more fields, containing individual bits of data. One field on the Mama’s Famous Shortbread recipe (record) is RecipeName, which contains the text data, “Mama’s Famous Shortbread.”
Another field is called Directions, and it contains all the information on how to mix the ingredients, what temperature to preheat the oven to, and how long to let the bread cool when it’s finished baking. If you wanted to get fancy, you would break this information up into two or more unique “directions” fields called MixingDirections, BakingDirections, and so on. Another field in the recipe table might be called RecipeID, which would contain some unique code that you could use to organize your recipes.
Of course, only if you had a degree in mathematics or were, yourself, a robot, would you organize your kitchen’s recipe box this way, but a unique ID or serial number for each record in a table is crucial when developing any relational database system.