Connectivity

The Connectivity of a relationship is restricted to three types:

M:N

Many to Many relationship. The application will create a composite entity using the primary keys of the related entities as the primary key of the resultant composite entity.

1:M

One to Many relationship. The primary key of the related entity are copied to the Many side of the relationship.

1:1

One to One relationship. If possible, the application will join the two tables into one. If this is not possible because of the participation or other relationships, the application will place the foreign key in the optional side of the relationship. If the relationship is mutually optional, the application will place the foreign key in the strong entity, and if that is not possible, the entity that was first introduced to the model.

Weak Relationships
Further to the Connectivity, an additional constraint on the relationship can be imposed by using a Weak Entity and a Weak Relationship. A Weak is used when the weak entity cannot logically exist in the database without the strong side of the relationship. Consider the relationship of an EMPLOYEE and their SPOUSE. An organization is only interested in the spouses of its employees, and therefore, the validity of the spouse in the database is totally dependent upon the existence of the employee.

In the absence of a Weak 1:M relationship, a Weak Entity behaves exactly like a normal entity.

Generalization and Specialization Relationships
Semantically, the Generalization/Specialization relationship behaves like a Weak Relationship to a Weak Entity. Therefore the UPDATE and DELETE rules will both be CASCADE as per the Foreign Key Rules chart.

M:N	Many to Many relationship. The application will create a composite entity using the primary keys of the related entities as the primary key of the resultant composite entity.
1:M	One to Many relationship. The primary key of the related entity are copied to the Many side of the relationship.
1:1	One to One relationship. If possible, the application will join the two tables into one. If this is not possible because of the participation or other relationships, the application will place the foreign key in the optional side of the relationship. If the relationship is mutually optional, the application will place the foreign key in the strong entity, and if that is not possible, the entity that was first introduced to the model.