What Is a One to One Relationship in ERD? A Complete Guide with Examples

In database design, understanding how different entities relate to each other is essential for creating efficient and accurate data models. One of the most straightforward yet powerful types of relationships is the one-to-one relationship. This occurs when each record in one table is linked to exactly one record in another table—and vice versa.

In this guide, we’ll explore what a one-to-one relationship is, how it works in real-world scenarios, and how to represent and implement it correctly in Entity Relationship Diagrams (ERDs) and relational databases. With detailed examples, clear visuals, and practical best practices, you’ll gain a solid understanding of when and how to use 1:1 relationships to design clean, organized data structures.

Understanding a One to One Relationship in ERD

What is a one-to-one (1:1) relationship?

In a one-to-one relationship, each record in one table or entity is connected to only one record in another table or entity—and vice versa. This means that for every instance of Entity A, there is exactly one matching instance in Entity B, and no more.

In ER diagrams, this is often shown by a line between two entities, with a “1” near each entity to indicate that both sides of the relationship allow only a single connection.

This type of relationship is used when two pieces of information are closely related but are separated into different entities for clarity, performance, optionality, or security.

Edit this Template

• Ready to use
• Fully customizable template
• Get Started in seconds

Close

Real-world examples of one-to-one relationships

1. Person ↔ Passport

• Explanation: Each person has only one passport (at a time, in most countries), and each passport is issued to only one person.
• Why it’s one-to-one: A passport can’t belong to multiple people, and a person can’t have multiple passports from the same country.
• In an ER diagram: You might have a Person entity and a Passport entity, with a one-to-one relationship connecting them.

2. Country ↔ Capital City

• Explanation: A country usually has one official capital city, and a capital city is the capital of only one country.
• Why it’s one-to-one: Even though a country may have multiple major cities, there is typically only one capital recognized for administrative purposes.
• Edge cases: Some countries (like South Africa) have more than one capital, but in general, this holds true for most.

3. User ↔ User Profile

• Explanation: On many websites or platforms, a user has one profile that stores information like their name, bio, and picture.
• Why it’s one-to-one: Each User account has exactly one User Profile, and each User Profile belongs to one User.
• Why split them: Sometimes this relationship is split into two entities for modular design—e.g., to store optional profile data separately.

4. Employee ↔ Company Car

• Explanation: In some companies, an employee may be assigned a company car. That car is used only by that employee.
• Why it’s one-to-one: One employee gets one car, and that car is not assigned to anyone else.
• Note: This is a one-to-one relationship only if each employee gets exactly one car and each car is assigned to one employee.

5. Person ↔ Birth Certificate

• Explanation: Every person has one birth certificate issued at birth, and each birth certificate is assigned to one person.
• Why it’s one-to-one: A birth certificate can’t belong to two people, and a person should only have one original birth certificate.
• Real-world use: In systems like a national registry, these two entities are strictly paired with one-to-one correspondence.

Why use a one-to-one relationship?

• To separate optional or sensitive data: For example, medical records can be stored in a separate table related one-to-one to the person.
• To improve organization and clarity: Keeping logically distinct sets of data in different tables makes the system easier to maintain.
• To manage performance: In large databases, splitting data can help queries run faster when not all information is always needed.

Representing 1 to 1 Relationships in ERDs

Standard Notations in ER Diagrams

To show a one-to-one relationship in an Entity Relationship Diagram, you use a combination of:

1. Entities (boxes)

• Each entity (like Person, Passport, or Profile) is represented by a rectangle.
• Inside the rectangle, you usually list the entity name and its attributes (fields like ID, Name, etc.).

2. Relationship line

• A straight line connects the two entities.
• This line shows that the entities are related.

3. Cardinality and participation notations

• These tell us how many instances from one entity relate to the other and whether the relationship is mandatory or optional.

Here are the components used to define this:

Edit this Template

• Ready to use
• Fully customizable template
• Get Started in seconds

Close

Example: Mandatory one-to-one

[Person]───1:1───[Passport]

• Each person in this system must have exactly one passport.
• Each passport is assigned to one person only.

Example: Optional one-to-one

[Employee]───1:0..1───[Company Car]

• An employee may or may not have a company car.
• If they do, it’s only one.
• Each company car is assigned to at most one employee.

Where to Place the Foreign Key

When translating a one-to-one relationship from an ER diagram to a relational database, a foreign key is used to enforce the link between the two entities. The foreign key ensures referential integrity by making sure that a value in one table corresponds to a valid value in another. In a 1:1 relationship, you must also ensure that the foreign key points to only one record, which is done by applying a UNIQUE constraint or sharing primary keys.

Edit this Template

• Ready to use
• Fully customizable template
• Get Started in seconds

Close

There are two common ways to implement this:

1. Foreign key in one of the tables

In this approach, the primary key of one table is added as a foreign key in the other. To enforce a true 1:1 relationship, you must also apply a UNIQUE constraint to the foreign key column, ensuring that no more than one record can reference the same primary key.

Example: If each user has exactly one user profile:

Store the user_id as a foreign key in the UserProfile table and make it unique.

CREATE TABLE UserProfile (

profile_id INT PRIMARY KEY,

user_id INT UNIQUE,

FOREIGN KEY (user_id) REFERENCES User(id)

);

• Each UserProfile belongs to one user.
• Each User can be linked to only one profile, because of the UNIQUE constraint.

2. Shared primary key

In this method, both tables share the same primary key value, and the key in the second table also acts as a foreign key. This setup guarantees that the relationship is strictly one-to-one—both records must exist together, and no duplicates can occur.

Example: A Person and their Passport

CREATE TABLE Passport (

person_id INT PRIMARY KEY,

passport_number VARCHAR(20),

FOREIGN KEY (person_id) REFERENCES Person(id)

);

• person_id in the Passport table is both a primary key and a foreign key.
• This enforces a tight 1:1 dependency—a passport cannot exist without a matching person.

Both of these methods are valid for modeling one-to-one relationships. The choice depends on whether the related data is optional, tightly coupled, or serves a different purpose in the system.

Key Differences and Considerations

Why Separate Data Into 1:1 Relationships?

Using a one-to-one relationship in your data model can help when:

• You want to separate optional or sensitive data into a different table (e.g., medical records, user profiles).
• Not all records need the same fields, so you split the data to avoid empty values.
• Security or access control: Some data may be more restricted and stored separately.
• Performance: Loading smaller, more focused tables can improve speed.

Best Practices for Designing 1 to 1 Relationships in ERD

1. Decide if it should really be one-to-one

Before creating a 1:1 relationship, ask:

• Could this be part of the same table instead?
• Will the relationship always be one-to-one in the future?

Sometimes, what looks like a 1:1 relationship now might actually become a one-to-many relationship later. Or, both sets of attributes might logically belong in the same table.

When to use 1:1:

• You want to separate optional or sensitive information.
• Two parts of data serve different business purposes.
• You’re working with different access levels or permissions.

Example: A User table and a UserProfile table. The user account and profile might be managed by different teams or loaded separately in an app.

2. Use shared primary keys for strong dependencies

If one table cannot exist without the other, use a shared primary key. This means:

• The primary key in one table also serves as a foreign key referencing another table.
• It ensures strict one-to-one mapping and tight coupling.

Best for: Things like Person and Passport or Student and Transcript.

CREATE TABLE Person (

person_id INT PRIMARY KEY,

name VARCHAR(100)

);

CREATE TABLE Passport (

person_id INT PRIMARY KEY,

passport_number VARCHAR(20),

FOREIGN KEY (person_id) REFERENCES Person(person_id)

);

3. Use foreign key + UNIQUE constraint for flexibility

If one side of the relationship is optional, and the other should exist independently, use:

• A foreign key referencing the other table’s primary key.
• A UNIQUE constraint on the foreign key to keep it one-to-one.

Best for: Optional relationships like Employee ↔ CompanyCar.

4. Clearly show optionality in the ERD

When drawing the ERD:

• Use “0..1” or an open circle to show optional participation.
• Use “1” to show mandatory participation.

This helps developers and stakeholders understand the business rules clearly.

Example:

[Employee] —— 1 : 0..1 —— [Parking Spot]

• One employee may have zero or one parking spot.
• One parking spot can belong to only one employee.

5. Label cardinality accurately

Always add cardinality (1, 0..1, etc.) next to the relationship lines in the ERD.

6. Group attributes based on access, usage, or frequency

Split entities into separate tables when:

• Some data is accessed rarely (e.g., audit logs).
• Some attributes are sensitive (e.g., medical info).
• You want to apply different permissions.

This reduces table size and helps with performance and security.

7. Plan for future changes

Even if your relationship is one-to-one today, it might become one-to-many in the future. So:

• Design with scalability in mind.
• Document your assumptions clearly in your ERD.
• Review your ERDs during major business or system changes.

8. Ensure referential integrity

When implementing a 1:1 relationship in your database:

• Use foreign key constraints to maintain integrity.
• Use triggers or checks if needed to enforce stricter rules (especially for optional relationships).

This helps prevent data mismatches and orphan records.

9. Use descriptive names and documentation

In your ER diagram and database schema:

• Use clear and descriptive entity and relationship names.
• Add notes if the 1:1 relationship serves a specific purpose (e.g., regulatory compliance, privacy separation).

This improves communication and helps future developers understand your design quickly.

Conclusion: What Is a One to One Relationship in ERD

One-to-one relationships are often overlooked but can be incredibly useful in organizing data that is unique, sensitive, or logically separate. By understanding how to model these relationships visually in ERDs and enforce them at the database level—whether using shared primary keys or foreign keys with unique constraints—you can build systems that are both efficient and easy to maintain.

Always consider the business context when deciding whether to use a one-to-one relationship, and follow best practices for clarity, performance, and scalability. With the right approach, your database design will be more secure, flexible, and future-ready.

To make the process easier, Creately allows you to intuitively create ER diagrams with built-in database shapes, relationship notations, and collaboration features. Whether you’re building your first ERD or refining a complex schema, Creately helps you visualize and validate one-to-one relationships with ease.

References

Frantiska, J. (2017). Entity-Relationship Diagrams. Visualization Tools for Learning Environment Development, pp.21–30. doi:https://doi.org/10.1007/978-3-319-67440-7_4.

ResearchGate. (n.d.). (PDF) A Comparative Analysis of Entity-Relationship Diagrams. [online] Available at: https://www.researchgate.net/publication/243781001_A.

‌