ER Diagrams   «Prev  Next»
 Lesson 4 One-to-one relationships, part 1 Objective Define one-to-one Relationships

# One-to-one Relationships in an ER Diagram

A one-to-one (1:1) relationship in an Entity Relationship Diagram (ERD) is a type of association between two entities, where each instance of one entity corresponds to exactly one instance of the other entity, and vice versa. This relationship signifies that the two participating entities have a unique and direct connection with each other, and there are no instances of either entity that can be linked to multiple instances of the other entity. To represent a one-to-one relationship in an ERD, follow these steps:
1. Identify the entities: Begin by determining the two entities that participate in the relationship. Ensure that the entities have been clearly defined and have the necessary attributes to establish the unique connection between them.
2. Draw the entities: Represent each entity using a rectangle, and label it with the entity's name. Inside the rectangle, list the attributes of the entity, typically in a vertical arrangement.
3. Establish the relationship: Draw a diamond shape connecting the two entities to signify the relationship between them. Label the diamond with a name that describes the nature of the association. For example, if you have two entities, 'Person' and 'Passport,' the relationship could be labeled as 'Holds.'
4. Indicate cardinality: To specify the one-to-one relationship, add '1' next to both entities, adjacent to the diamond shape. This indicates that each instance of one entity is related to exactly one instance of the other entity. For example, in the 'Person' and 'Passport' scenario, placing '1's next to both entities shows that each person can hold only one passport, and each passport can be issued to only one person.
5. Optional or mandatory: Depending on the business rules or constraints, a one-to-one relationship can be either optional or mandatory. An optional relationship means that an instance of one entity can exist without a corresponding instance of the other entity. In contrast, a mandatory relationship implies that an instance of one entity must always have a related instance in the other entity. To denote the optionality or mandatory nature, use dashed lines for optional relationships and solid lines for mandatory relationships.
By following these steps, you can effectively define and represent a one-to-one relationship in an ERD, ensuring that the unique connection between the participating entities is visually communicated and understood. This aids in creating a clear and accurate database design that aligns with the intended data structure and business requirements.

## Further Explanation of (1:1) Relationships

A one-to-one (1:1) relationship exists when zero or one instance of `entity A` can be associated with zero or one instance of `entity B`, and zero or one instance of `entity B` can be associated with zero or one instance of `entity A`. To illustrate such a relationship graphically, think of entities A and B in terms of generic tables, where generic tables are not populated with data.A one-to-one relationship exists when one record in Table A can be associated with one record in Table B, and one record in Table B can be associated with one record in Table A. The following diagrams illustrate a 1:1 relationship between Table A (entity A) and Table B (entity B) from the viewpoint first of Table A and then of Table B.

1. 1:1 relationship between Table A (entity A) and Table B (entity B) from the viewpoint of Table A.
2. The same relationship between Tables A and B appears this way from the viewpoint of Table B.

### Mandatory Relationship

When transforming a one-to-one relationship, you create a foreign key and a unique key and all columns of this foreign key are also part of a unique key. If the relationship is mandatory on one side, the foreign key is created at the corresponding table. If the relationship is mandatory on both sides or optional on both sides, you can choose on which table you want to create the foreign key. There is no absolute rule for deciding on which side to implement it.

### Optional Relationship

If the relationship is optional on both sides you may decide to implement the foreign key in the table with fewer numbers of rows, as this would save space. If the relationship is mandatory at both ends, we are facing the same RDBMS limitation you saw earlier. Therefore, you need to write code to check the mandatory one at the other side, just as you did to implement m:1 relationships that are mandatory at the one end.

## one-to-one Relationship between Tables of a Database

Question: Are there any real world use cases for one-to-one relationships in data modeling?
Yes, there are several real-world use cases for one-to-one relationships in data modeling. Although less common than other relationship types such as
1. one-to-many or
2. many-to-many,
one-to-one relationships are still important in certain situations where data needs to be organized and structured efficiently.
One common use case for one-to-one relationships is in situations where a subset of data needs to be separated from the main data set for security or performance reasons. For example, a database might store sensitive information such as credit card details separately from other customer information. In this scenario, a one-to-one relationship can be established between the customer entity and the sensitive data entity, ensuring that access to the sensitive data is restricted to authorized users only.
Another use case for one-to-one relationships is in situations where certain attributes of an entity need to be separated from the main entity for performance or storage reasons. For example, a user entity might have a large number of attributes, but only a few of these attributes are accessed frequently. In this scenario, a one-to-one relationship can be established between the user entity and a separate entity containing the frequently accessed attributes, improving query performance and reducing storage requirements.
One-to-one relationships are also useful in situations where data needs to be partitioned or distributed across different systems. For example, a customer entity might be partitioned across multiple databases based on geographic location, with each database containing only a subset of the customer's attributes. In this scenario, a one-to-one relationship can be established between the customer entity and the database entity, ensuring that data is properly organized and easily accessible.
In summary, while one-to-one relationships are less common than other relationship types in data modeling, they are still useful in certain situations where data needs to be organized, separated, or partitioned efficiently. By understanding the different use cases for one-to-one relationships, businesses and organizations can create more effective and efficient data models that accurately reflect their real-world operations.

## Connectivity of a Relationship

The connectivity of a relationship describes a constraint on the connection of the associated entity occurrences in the relationship. Values for connectivity are either
1. one or
2. many.
For a relationship between the entities Department and Employee, a connectivity of one for Department and many for Employee means that there is at most one entity occurrence of Department associated with many occurrences of Employee. The actual count of elements associated with the connectivity is called the cardinality of the relationship connectivity; it is used much less frequently than the connectivity constraint because the actual values are usually variable across instances of relationships. Note that there are no standard terms for the connectivity concept, so the reader is admonished to consider the definition of these terms carefully when using a particular database design methodology.

The next lesson explores one-to-one relationships further.