Database Reference
In-Depth Information
Both conditions have to be true; just putting more than one table into a FileMaker database
doesn't make it relational. Say you have a Customer table and an Antiques Collection table.
There's no point putting them in the same database unless there's a relationship between
those two things. But if you're selling antiques to your customers, you can create a database
that tracks your inventory and sales to specific people.
Why not just keep two databases—one for customer info and one for sales tracking? There
are several benefits to creating a relational database instead:
▪
You don't have to enter data twice
. Think back to the Lease Document database.
Without two related tables, the Payment table would need a lot more fields in it. It would
need to track the name of the person making the payment and the name of the property
for which the payment is made. But because the payment record is related to a Lease
Document record, that relationship tells you where the payment belongs and who signed
the lease. The relationship also lets you display Payment data on the Lease Document re-
cord and vice versa.
▪
Your data is easier to maintain
. Since the data really “lives” in only one table (although
you can display it in any related table), you can change data in one place, and those
changes are immediately reflected everywhere. When the same data is stored in unrelated
tables, you may have dozens of places to find and fix data when it changes.
▪
Relational databases are easier for users to understand
. Other databases (not
FileMaker, lucky you) use complex queries and reports to show users their data. Spread-
sheets are simpler yet often require manipulation of rows of data to get meaningful in-
formation from them. But even a new user looking at the Lease Document record can see
that the list at the bottom of the layout is for tracking payments. One reason it's so obvi-
ous is because the relationship in the database is an onscreen representation of a real-
world relationship.
Keep these benefits in mind as you plan, because efficiency and clarity can help you make
decisions as you draw your roadmap.
This chapter teaches you how to plan the schema for a database that'll track time and ex-
penses for jobs you do for your clients and then create invoices for those jobs. Although the
database you'll design has specific sets of tasks that may not pertain to your real-world data-
base, the concepts you'll learn can be applied to any tasks you need your custom database to
do.
