Good, terse explanation.

The only issue I'd have with it is the use of the terminology "Parent" and "Child" to describe the relationship between the primary key and the foreign key(s) that reference it. In the best methodologies I've seen, the terms "parent" and "child" are reserved for unusual situations where you have things that depend for their existence on other things. An example of this might be a line on an invoice - the invoice must exist for the line to exist, do the invoice would be the "parent" and the line the "child". With dissimilar things, such as drivers and racecars, you'd have two distinct entities that were related by a foreign key, but neither would be the "parent" of the other.

That's terminology, but it avoids confusion.