A data dictionary defines every piece of data that appears on a data flow diagram, using a small, precise notation. This page teaches the notation and applies it to two complete examples.
A data dictionary is the written companion to a data flow diagram (DFD). For every data flow, data store and data element on the diagram, it records what the data is made of, using a short algebra-like notation. Analysts write it, and developers, testers and database designers read it to agree on exactly what "order details" means. It comes from the structured analysis methods of the late 1970s (DeMarco, Gane and Sarson, Yourdon).
A DFD shows where data moves; the dictionary says what that data is. Together they form a precise, implementation-independent specification.
Each entry has the form name = definition. Definitions combine other names with + (sequence), [ | ] (choose one), { } (repeat, optionally with lower and upper bounds), and ( ) (optional). Comments between asterisks describe elementary items that are not broken down further: their type, range, units or format. The @ sign marks a key. Every name used must itself be defined, down to elementary items.
Walkthrough: the customer sends order-details to process 1.0, which checks them against product information from the Products store and passes a valid-order to process 2.0. That process writes an order-record to Orders and returns an order-confirmation. The dictionary below defines every flow, top-down:
order-details = @customer-id + 1{order-line}50 + payment-method + (gift-message)
order-line = product-code + quantity
quantity = *integer, 1..99*
payment-method = [card-details | paypal-token | gift-card-number]
card-details = card-number + expiry-date + cardholder-name
product-info = product-code + description + unit-price + stock-level
valid-order = order-details + order-total
order-total = *decimal(10,2) in currency* + currency-code
currency-code = *ISO 4217, 3 letters, e.g. USD*
order-record = @order-id + valid-order + order-date + status
status = ["placed" | "paid" | "shipped" | "cancelled"]
order-confirmation = order-id + order-total + estimated-delivery-date
Orders (D2) = {order-record}Read order-details as: one customer id, then between 1 and 50 order lines, then a payment method, then an optional gift message. payment-method is exactly one of three alternatives. The store Orders is defined as any number of order records.
A member asks to borrow up to five books. Process 1.0 checks the member's status and each copy's availability, writes a loan per copy and returns a receipt.
loan-request = member-number + 1{isbn}5
member-status = member-number + ["active" | "suspended"] + loans-outstanding
book-copy = @copy-id + isbn + ["on-shelf" | "on-loan" | "reserved"]
loan = @loan-id + member-number + copy-id + issue-date + due-date
due-date = *issue-date + 21 days*
loan-receipt = 1{copy-id + title + due-date}5
Loans (D3) = {loan}Notice how the dictionary captures business rules the diagram cannot: a member may borrow at most five books per request, a loan is due 21 days after issue, and a copy has exactly three possible states.
Start from the DFD and list every labelled flow and store. Define each one top-down, then keep defining any new name you introduced until you reach elementary items, which get a comment with type, range and units. Finally check both directions: every arrow on the diagram has an entry, and every entry is used somewhere. Inconsistencies found this way, such as a flow that leaves a process containing data that never entered it, are exactly the errors the method is designed to catch.
The Example 1 DFD in Mermaid flowchart syntax, renderable in GitHub Markdown or the Mermaid Live Editor. Mermaid has no native DFD type, so circles stand for processes and cylinders for stores. Keep the dictionary itself in a text or YAML file in the same repository, so diagram and definitions are reviewed together.
flowchart LR
C[Customer] -- order-details --> P1((1.0 Validate order))
D1[(D1 Products)] -- product-info --> P1
P1 -- valid-order --> P2((2.0 Confirm order))
P2 -- order-record --> D2[(D2 Orders)]
P2 -- order-confirmation --> CPros
Cons
When to use: alongside DFDs in structured analysis, in regulated projects that need precise specifications, and when many teams must agree on shared data definitions. When not to: when schemas already live in code (JSON Schema, Avro, dbt models) that can be generated into documentation, or for small, fast-changing prototypes.