Related forms display data from related tables. Related tables, views and CursorAdapters are tables, views and CursorAdapters that contain records that "belong" to each other. Stated more precisely, related tables, views and CursorAdapters are tables, views and CursorAdapters with records that contain a key (a field or combination of fields) that links their records. The related records that belong to each other in related tables, views and CursorAdapters are the records that contain the same key value.
For example, in an order entry system, a customer table and an invoices table are related because the invoices table contains records that belong to customer records and vice versa. The records in the invoices table that belong to a specific customer record are those that have the same customer ID number, or key value, as the customer record.
Related Tables and Views - The Family Analogy
It has become the custom when referring to related tables, views and CursorAdapters to use a family analogy. The family analogy fits related tables, views and CursorAdapters well because related tables, views and CursorAdapters form a hierarchy just like the hierarchy of a family. Therefore, developers refer to related tables, views and CursorAdapters using familial terms such as parent, child, grandchild, great-grandchild and so on.
What Is a Parent? What is a Child?
Between any two related tables, one table is a parent and one is a child. Sometimes it can be a little confusing as to which is the parent and which is the child. Here's a rule to identify the parent:
∑ Parent Table, View or CursorAdapter Rule: The parent table, view or CursorAdapter is the table, view or CursorAdapter in which a record must exist before a record with the same key value can be entered in the other, or child, table, view or CursorAdapter.
For example, with respect to a customer table and an invoices table, the customer table is the parent because a customer record with a particular customer ID number must exist before an invoice record with that customer ID can exist.
Another necesssary, but not sufficient, rule that a parent table, view or CursorAdapter must satisfy is that the key value must be unique in each record. You can often use this rule to identify the table, view or CursorAdapter that isnít the parent table, view or CursorAdapter in a relationship. By default, then, the other table, view or CursorAdapter in the relationship must be the parent. For example, an invoices table can have records with duplicate customer ID numbers, or linking key values. Therefore, the invoices table isnít the parent table in the customer - invoices relationship. That means the customer table must be the parent.