Simple and composite are the two types of geodatabase relationship classes that can be created in ArcGIS Pro. The relationship class type you select will be guided by the data that's available to you, the cardinality of the datasets you want to relate, and the questions you are trying to answer.
Each relationship class type is described in greater detail below.
Simple relationship class type
A simple relationship class is a type of relationship that associates features in one feature class (origin table) with features in another feature class (destination) or objects in a table.
The following describe a simple relationship class:
- The cardinality can be one to one (1:1), one to many (1:M), or many to many (M:N).
- The relationship is defined between two tables, where one is the origin and the other is the destination.
- The relationship is based on a common attribute field.
- The deletion of a feature or row in the origin table does not affect the related features or rows in the destination table.
- The relationship between the tables is maintained as long as the common attribute field values match.
For example, you might have a simple relationship class between a feature class named Campground Facilities (origin) and a feature class named Campsites (destination). Each campground can be related to one or more campsites contained within that campground, but the deletion of a campsite does not result in the deletion of the campground.
In a simple relationship, related objects can exist independently of each other. This means that deleting a destination object has no effect on the primary key value or on the parent record in the related origin table.
For example, a report has come in that a recent storm has washed out Slough Creek campsite #6; therefore, deleting this record from the Campsite (destination) feature class has no effect on the Slough Creek Campground in the Campground Facilities (origin) feature class. 
However, when you delete an origin object in a simple relationship, the foreign key field value for the matching destination object is set to <Null>. This foreign key behavior was designed to maintain referential integrity between features. If the origin feature is deleted, the value in the foreign key is no longer relating that row to a feature in the origin and, as a result, the foreign key value is no longer required and is set to Null.
The sole purpose of the foreign key is to maintain a relationship between the destination object and the related origin object. If there is no origin feature with the matching primary key value, there is no reason to maintain the foreign key value. If you want to relate the same destination feature to a new or different origin feature in the future, the foreign key field can be updated from <Null> to the new foreign key value.
For example, the Slough Creek Campground with a FacilityID of 259310 is the smallest campground in Yellowstone National Park with only six campsites. A decision was made to merge this campground with the larger Pebble Creek Campground. In this simple relationship class, when the record for the Slough Creek Campground is deleted from the origin table, the six campsites remain in the destination table; however their foreign key value changes to <Null>. Now you can update the ParentFacilityID of these six <Null> values to reflect 259307 so that they will now be linked to the ParentFacilityID of the Pebble Creek Campground. 
Composite relationship class type
Similar to a simple relationship, a composite relationship class is a type of relationship that associates features in one feature class (origin table) with features in another feature class (destination) or objects in a table. Composite relationships also maintain referential integrity when objects are deleted, but they do so in a different way. In a composite relationship, destination objects can't exist independently of origin objects, so when the origin is deleted, the related destination objects are also deleted in a process called a cascade delete. Composite relationships always have one-to-many cardinality when you create them but can be constrained to be one-to-one with relationship rules.
The following describe a composite relationship class:
- The cardinality can be one to one (1:1) or one to many (1:M).
- The relationship is defined between two tables, where one is the origin and the other is the destination.
- The relationship is based on a common attribute field.
- The deletion of a feature or row in the origin table does affect the related features or rows in the destination table.
- Features or rows (objects) in the destination table can't exist independently of related features or rows (objects) in the origin table.
- The relationship between the tables is maintained as long as the common attribute field values match.
For example, it has been determined that the current location and land of the Slough Creek Campground would be ideal for a new educational center. Therefore the six Slough Creek campsites will no longer be available so that grading and construction crews can begin preparing the site for the new Slough Creek educational center. Now when you edit the composite relationship class and delete the Slough Creek Campground record from the Campground Facilities feature class (origin), all six of the related Slough Creek campsites in the Campsite feature class (destination) are deleted.
A composite relationship can also help you maintain features spatially; moving or rotating an origin feature causes the related destination features to move or rotate with it when messaging is set to Forward.
Learn how to create a composite relationship class
Learn more about many to many or attributed relationship classes
Learn about relationship class usage tips and options available to modify a relationship class.