Beyond keys and types, real schemas carry rules: a value must be positive, a status must be one of a set, or a pair of columns must be unique together. Schemity supports check constraints and composite unique constraints directly in the ERD, so your diagram captures the real validation rules and multi-column uniqueness, not just the shape.

How do I add a check constraint?

ERD check constraints support lets you attach a boolean condition to an entity. The check-constraint dialog offers two ways to write it:

  • Visual mode - pick a Target field and the allowed Values, and Schemity builds the expression for you (great for status IN (...) style rules).
  • Expression mode - write the raw SQL condition yourself, for example price >= 0 or end_date >= start_date, with a live preview.

When you export DDL, Schemity emits each one as a CHECK constraint.

How do I add a composite unique constraint?

A single-column unique flag lives on the field (see Entities & Fields). When uniqueness spans more than one column, add a composite unique constraint through the Unique Constraint dialog, where you choose the fields, an optional name, and a color:

  • (tenant_id, email) - email is unique per tenant, not globally.
  • (order_id, line_number) - line numbers are unique within an order.

This is essential for multi-tenant RBAC schema designs, where uniqueness is almost always scoped by tenant.

Do unique indexes show up on the diagram?

A multi-column unique index carries the same “unique together” meaning as a unique constraint. Schemity surfaces both with a U marker on the involved fields, so you can see uniqueness on the diagram whatever its source - while the index still stays in the index list.

Why should I model constraints in the ERD?

Putting constraints in the diagram keeps the ERD single source of truth. A reviewer reading the diagram sees the same rules the database enforces - no drift between the picture and production.

Next

Control connector routing with Custom Waypoints.