attribute will finally create a unique set of PK attribute values - but the PK is now composed of four attributes: TRUCK_NUM, DRIVER_NUM, LOG_DATE, and LOG_TIME_OUT. (The combination of these attributes yields a unique outcome, because the same driver cannot check out two trucks at the same time on a given date.)Because multi-attribute PKs may be difficult to manage, it is often advisable to create an"artificial" single-attribute PK, such as LOG_NUM, to uniquely identify each record in the LOG table.(Access users can define such an attribute to be an "autonumber" to ensure that the system will generate unique LOG_NUM values for each record.) Note that this solution produces a LOG table that contains two candidate keys: the designated primary key and the combination of foreign keys that couldhave served as the primary key.While the preceding solution simplifies the PK definition, it does not prevent the creation of duplicate records that merely have a different LOG_NUM value. Note, for example, the first tworecords in the following table:To avoid such duplicate records, you can create a unique indexon TRUCK_NUM + DRIVER_NUM + LOG_DATE + LOG_TIME_OUT.Composite entities may be named to reflect their component entities. For example, an employee may have several insurance policies (life, dental, accident, health, etc.) and each insurance policy may be held by many employees. This M:N relationship is converted to a set of two 1:M relationships, by creating a composite entity named EMP_INS. The EMP_INS entitymust contain at leastthe primary key components of each of the two entities connected by it. How many additional attributes are kept in the composite entity depends on the end-user information requirements.