Dennis,


Change your desing to the one below.

Table 1: telephone manufacturers

ID      Name
001     Sony
002     Lucent
003     Motorola

Table 2: telephone models

PK   ID   Name     Company ID
001  001  KZY123     001
002  002  KZY345     001
003  003  ZZ9        001
004  001  987Z       002
005  002  988X       002
006  001  Mr. Phone  003
007  002  Portaphone 003

Whay, because one of the requirements in the relational model is that any attribute (field) must be atomic. That measn that the field cannot be broken down further and still have meaning. Your compound key is not atomic, you can break it aprat and the two pieces have meaning without each other. Break them apart and make them two distinct fields. As for the PK of the child table, I have a personla preference for using surrogate PKs, but you can easily create and index on CompanyID + Id to produce a primary key for the child table.

A primary key is defiend as a field or group of fields that uniquely identifies a specific record. Ther is nothing worng with using a two field primary key, there is something worng with using a non-atomic field in the table structure.

Your observation regarding 1st NF is incorrect, in fact relational desing principles state that you should have two separate fields here.

One of the problems with compound primary keys is that the RI builder in VFP generates RI code that doesn;t wokr well with compound PKs. But that is easily dealt with by not using the RI Buider and writing your own RI code.