ezModel · Data modeling · Early access

Write what the business needs. ezModel draws the model.

A data modeling tool that builds the conceptual-logical model and the relational model from your requirements, with a business glossary and traceability.

REQ-01Each customer is identified by a document.
REQ-02A customer has many orders.
REQ-03Each order belongs to one customer.
Join the waitlistSee how it works
The model those three requirements produce · IE notation
CUSTOMER document (UID) name ORDER number (UID) date document (RID) R_CUSTOMER_ORDER Each CUSTOMER relates to zero, one or many ORDER. Each ORDER relates to exactly one CUSTOMER.

Sound familiar?

If any of these happened on your last project, ezModel is for you.

The model and the requirements drifted apartNobody can say which requirement a table came from.
Two names, one thing"Buyer" and "customer" became two entities.
Diagrams by handEvery change means redrawing boxes and lines.
Expensive modeling suitesLicenses that cost more than the project's tooling budget.

From the business conversation to the tables

Each step leaves something you can review before the next one. Nothing is generated blindly.

Narrative
Describe the business in your own words, as a user would tell it. An AI assistant can help draft it (optional).
Requirements
The narrative becomes coded sentences in controlled language. You review and correct them in the editor.
Conceptual-logical model
A deterministic builder creates entities, identifiers and relationships. The same text always gives the same model.
Relational model
Tables, foreign keys, bridge tables for many-to-many and referential actions, up to the normal form the project sets.

The same relationship, in your team's notation

There is only one model. Switch the notation and the diagram is redrawn without losing anything.

IECrow's foot, James Martin's notation.
BarkerDashed line where participation is optional.
BachmanArrows and participation circles.
UMLMultiplicities written on each end.
IDEF1XDependent entities with rounded corners.

One vocabulary for the whole project

When the model is generated, each entity is linked to its term in the business glossary. What doesn't exist yet is added as a proposed term, with its meaning taken from the requirements.

  • Business synonyms point to the same term, so "buyer" doesn't create a second entity.
  • Every entity and relationship keeps the requirements it came from.
  • A term with entities linked to it can't be deleted.
TermMeaningStatus
CustomerPerson or organization that buys. Synonym: buyer.approved
OrderA customer has many orders. Each order belongs to one customer.proposed
DocumentAttribute of Customer (from REQ-01).proposed

The relational model comes from the logical one

The identifier that migrates through each relationship becomes a foreign key, named after the relationship and with its delete action. Many-to-many relationships get their bridge table.

  • Natural identity or surrogate keys, as the project decides.
  • Diagnostics flag broken rules before anything reaches the database.
  • Every save is a version you can restore.
-- generated from R_CUSTOMER_ORDER
CREATE TABLE customer_order (
  number     VARCHAR(20) NOT NULL,
  order_date DATE,
  document   VARCHAR(20) NOT NULL,
  PRIMARY KEY (number),
  CONSTRAINT fk_customer_order
    FOREIGN KEY (document)
    REFERENCES customer (document)
    ON DELETE NO ACTION
);

Get early access

ezModel is in its final stage. Join the waitlist and we'll email you when early access opens. The first 50 teams get 40% off for life.