About Relational Databases
FileMaker is a relational database program. That means two important things. First, it's a tool for taking a collection of information items and imposing a formal organization on them. (That's the part that makes it a database program.) All the earliest computer databases shared this characteristic, as, to some degree, do modern spreadsheet programs. Second, FileMaker allows you to fluidly retrieve, add to, and dynamically assemble that information in separate but connected database elements, without having to modify the initial database structure or create duplicate data entries. (That's the relational part.) Relational database programs are more flexible, sophisticated, and powerful than simple flat database programs.Just because FileMaker allows you to create relational databases doesn't mean that every database you create using FileMaker will take full advantage of these features. In fact, most beginning users of FileMaker understand the database part of its capabilities long before they understand (and effectively use) the relational parts.
Dynamic data
One of the primary principles behind a relational database is that data should never be duplicated. If you create a file with one set of information, you shouldn't need to copy or reenter any of the field entries. At most, you need a single duplicated field to act as the place where two sets of information "join." That join is also referred to as a key field, a category of unique information that identifies which records in one database table refer to a particular record in another table. You can use this key field to display the data from another table on a layout alongside the data in the first table.A classic example used by database mavens to illustrate relational databases is a college course registration. Colleges can have thousands of students and hundreds of courses, so it would be really impractical to duplicate all the student information for each course roster. Instead, a course roster is created from a database of students, a database of faculty, and a database of courses. The course roster is the place where these separate entities join, with the course number serving as the field where the connections are made. We'll examine that scenario in greater detail later in this chapter.