This setting defines the cardinality of the relationship.  It answers the question: how many are allowed.  For each side of the relationship you may allow only a single relationship or you may allow multiple relationships.  Usually, all four combinations may be selected: one-to-one, one-to-many, many-to-one and many-to-many.  For symmetric relationships only one-to-one and many-to-many are possible.  The most common setting is one-to-many (or many-to-one depending on which side you're editing).  Some of the side effects of a single-only relationship can be confusing, but are fairly intuitive if you compare them to human relationships:

Consider the one-to-one relationship of "ballroom dance partner".  If Bob is dancing with Betty, and Carl is dancing with Carol, then Bob decides to cut-in and dance with Carol...what happens?  All four people are no-longer dancing with the person they were previously dancing with.  Of course if Bob and Betty weren't dancing when Bob cuts-in then only three people are affected.  If no-one is dancing when Bob decides to dance with Carol then only two people are affected.  The same things occur in a one-to-one relationship field:   Two, three or four form entries may be affected by a single change.

Next consider the one-to-many relationship of "telephone provider".  If Sally signs up for new phone service with AT&T, then Sally and AT&T have a new relationship.  None of AT&T's other customers are affected because many relationships are allowed on AT&T's side of the relationship.  If Sally then changes her provider to Sprint, it terminates her telephone provider relationship with AT&T because Sally's is only allowed one telephone provider relationship.  With a one-to-many or many-to-one relationship two or three form entries may be affected by a single change.

Many-to-many relationships such as "friend" are the most intuitive in this area:  Any change affects exactly two form entries.  Regardless of how relationships are connected or disconnected, they never affect other relationships.  (Except in real llfe when your old friends don't like your new friends...we won't get into that because computers don't get to have opinions.)

This setting is equivalent to choosing between a single-select and multi-select field.  However, it can be changed after the field is created, unlike select fields.  From an end-user's perspective a relationship field looks and behaves exactly like a single select field or a multi-select field depending on how this setting is configured.  If multiple relationships are allowed on this form, then the field will look exactly like a multi-select field.  If only a single relationship is allowed on this form, then the field will look like a single-select field.  The only exception is for intra-record relationships to a single-entry form.  This scenario is described under the "Label (Related)" setting below.

Changing this setting can be dangerous if data already exists and/or formulas have already been written.  If you reduce the cardinality from many-allowed down to one-allowed and existing data already has multiple relationships, the existing relationships do not cease to exist immediately. However, only one can be represented while editing the field, and which is shown is arbitrary.  The next time a change occurs to one of the existing relationships, the new single-only rule will be enforced with unpredictable results since all but one relationship must be terminated under the new rules.  If you increase the cardinality from one-allowed up to many-allowed and formulas exist which only use the first related item, they will fail to recognize and properly deal with the additional relationships that can now be created.

This setting is only available for cross-record relationships, not intra-record relationships.  It determines which records may have their form entries related.  It does NOT affect which entries of a multi-entry form may be selected, even if the query/report chosen has search criteria for the related multi-entry form.

This setting affects available options for both sides of the relationship.  This is easier to understand if considering human relationships:  Imagine a world where nerds are happy to have a relationship with any woman, but women are only willing to have a relationship with nerds who have a net worth over $500,000.  In this imaginary scenario nerds cannot actually have a relationship unless they have a high net worth.

Relationship fields work in the same way.  If you configure a relationship field between doctors and patients, you can configure the query/report setting on the doctor's side of the relationship to include only active clients but the query/report setting on the patient's side of the relationship to allow any doctor.  If you look at a doctor's record and attempt to select a patient, you will see all active patients as expected.  However, by the same rule, if you then go to an inactive patient's record and try to select a doctor there will be no doctors to select, not because the inactive patient is restricted to particular doctors, but because the current record does not meet the requirements of any doctor.

This can be particularly powerful when used with the unit settings of queries and reports.  If a query is used on each side of the relationship which shows the current unit and sub units, then effectively only records in the same unit can be related because if one record is in a parent unit of the other, then the record in the child unit cannot be related to the record in the parent unit.  This senario is not generally useful.  However, it can be become useful if one side of the relationship uses a query that shows the current unit and below, and the other side of the relationship uses a query that shows all units (starts at the top unit and shows sub-units).  What actually occurs, is that the side that is configured to show "all" units actually shows the current unit and above because those are the only units which allow the relationship.  The "current and below" rule gets applied in reverse to the opposite side of the relationship.

If there are no available options to select, then the relationship field becomes hidden, unless the current user is a Relate administrator.  Relate administrators see a message indicating why there are no available options.

Changing this setting has significant consequences because it will change the list of potential relationships available to users editing the data on both sides of the relationship.  It may remove items from the list that should be there, add some that shouldn't, or change the list to something completely different.  Be careful when modifying this setting.

The "format" setting only applies to single-relationship fields.  To be precise, it only applies when the "single/multi relationship" setting is single-relationship for this form.  It determines whether the relationship field uses a list of radio buttons or a drop-down list.  Radio buttons are more appropriate with a short list of options, and drop-down lists are more appropriate for longer lists of options.  However, each record can have a different number of options available for the same relationship field, so there is no way to make a universal choice between radio buttons and a drop-down list.

The format setting defines the cut-off point when the field transitions from radio buttons to a drop-down list.  If the format option is blank, or the number of available options is smaller than the configured value, then radio buttons are shown.  Otherwise, a drop-down select field is shown.  Valid values for the "format" setting are between 0 and 1000.