Skip to Content
DocsVisual ModelingCardinality

Cardinality

Cardinality defines how many records in one table can be associated with records in another table.

It is one of the most important concepts in database modeling because it describes the business rules behind a relationship.

In Qubase, cardinality is configured when creating or editing relationships on the ERD Canvas.

Before you begin

Before working with cardinality, make sure you have:

  • Created at least two tables
  • Created a relationship between them
  • Defined the required Primary and Foreign Keys

[!NOTE] Cardinality describes the relationship between records, not between tables.

Why cardinality matters

Cardinality helps define business rules such as:

  • Can one customer place multiple orders?
  • Can one employee manage many departments?
  • Can one student enroll in many courses?

Correct cardinality ensures that your database accurately reflects real-world relationships.

Cardinality symbols

Qubase follows standard ERD notation.

SymbolMeaning
1Exactly one
0..1Zero or one
1..*One or many
0..*Zero or many

One-to-One (1:1)

Each record is associated with exactly one record in another table.

Example:

User
   │
   │
Profile

Business example:

  • One User has one Profile.
  • One Passport belongs to one Citizen.

Use this relationship when both records should exist only once.

One-to-Many (1:N)

One record can be related to multiple records.

Example:

Customer
     │
     ├────────► Order
     ├────────► Order
     └────────► Order

Business example:

  • One Customer places many Orders.
  • One Department has many Employees.
  • One Category contains many Products.

This is the most common relationship in relational databases.

Many-to-Many (N:M)

Multiple records in both tables can be related to each other.

Example:

Student
     │
     ▼
Enrollment
     ▲
     │
Course

Business example:

  • Students enroll in multiple Courses.
  • Courses contain multiple Students.
  • Products belong to multiple Categories.

Qubase represents this relationship using a junction table.

Optional relationships

Some relationships allow records to exist without a related record.

Example:

Customer

0..1

Membership

Meaning:

  • A customer may have a membership.
  • A customer may also have no membership.

Mandatory relationships

Some relationships require every record to participate.

Example:

Order

1

Customer

Meaning:

Every Order must belong to exactly one Customer.

Choosing the correct cardinality

Ask the following questions:

  • Can one record have multiple related records?
  • Is the relationship optional?
  • Must every record be connected?
  • Should a junction table be used?

These questions help determine the correct relationship type.

Validation

Qubase validates cardinality before generating SQL.

Validation checks may include:

  • Missing Foreign Keys
  • Invalid relationship rules
  • Duplicate relationships
  • Unsupported cardinality combinations

Validation helps prevent inconsistent database designs.

Best practices

  • Understand the business rules before creating relationships.
  • Avoid using many-to-many relationships unless necessary.
  • Review cardinality during schema validation.
  • Keep relationship definitions simple and consistent.
  • Validate your model before exporting SQL.

[!TIP] If you’re unsure which cardinality to use, start by asking how the real-world entities interact with each other.

Last updated on
RelationshipsCanvas Tools