Understanding Database Design

By now you've designed a simple FileMaker database, and built some nice data-entry screens and some reports. Your friends and co-workers are clamoring for you to add features. Can your system do invoicing? Inventory tracking? Bar-coding?

Well, it can probably do all those things. But it's going to take some planning. If this is your first time out with FileMaker, you're like the home carpenter who's just built her first birdhouse. It's a nice birdhouse, but your kids want a tree fort. That's not just going to take more work; it's going to take more thought as well.

FileMaker is a tool for building database applications. Both parts of that term are important. By applications we mean coherent pieces of software with which users can interact in defined and predictable ways. And by databases, of course, we mean databases, pointing to the fact that FileMaker applications are, in the end, designed to help generate, store, and retrieve data.

Much of the rest of this book concentrates on either the application angle or the database angle. In this chapter, we're going to lay out for you the fundamentals of database design. When you're designing a simple contact manager or recipe book, the database structure is pretty clear. You know what fields you need to track and what kinds of fields they are. But when you get into tracking additional categories of data in the same database, things get trickier. If you want to build bigger and better databases, you'll need a firm grounding in database analysis and database design. Don't worry if that sounds ominous. It's easier than it appears.