In the previous chapters, you learned how to give your database all kinds of cool features and powers, but it still contains just a single table to hold your data. In the real world, one table is rarely enough. In your private investigator business, for example, you need to keep track of more than just people. You need to record the time you spend working for your customers, the invoices you send them, and the payments you receive. And you need to organize all this stuff into recognizable jobs.
You could make a separate database for each of these needs. But that’s far from ideal, since you don’t want to use each kind of information in isolation. You need all these different kinds of information to work in harmony, like a well-rehearsed orchestra. In database terms, what you need is a single, integrated file that keeps all your various lists, files, and records in one place, so you can arrange and rearrange them according to your needs—a relational database.
Before you dive into relational databases, you’ll find it helpful to review some vocabulary. First, a database is a collection of tables, layouts, and other features that forms an organized system. A table holds information about one kind of thing, like people, orders, products, or suppliers. A field holds one attribute of something: the person’s first or last name, the order date, the color of a product, or the supplier’s address. (An attribute