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 these directly, so your diagram captures the real constraints, not just the shape.

Check constraints

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.

Composite unique constraints

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.

Unique indexes show up too

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 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.