Environments and data

Tables, columns, objects, results, naming schemes.

Dalea has two ways to store information: documents (free-form, rich-text, collaborative) and environments (structured, schema-validated, queryable). Most labs use both.

This page explains the structured side — environments and the four primitives that live in them.

Why structure matters

A spreadsheet is structured. An ELN page is unstructured. The first lets you ask "what was the average plasma concentration at 4 h across all 3 mg/kg dose groups?". The second forces you to read.

In Dalea you can have both: write up the experiment in a document, and have the underlying data be queryable in real time because it lives in an environment.

The five primitives

Environment
A schema container. Holds tables, columns, and naming schemes. Reusable across studies.
Table
Either an entity table (samples, animals, reagents) or a result table (measurements over time).
Column
A field on a table. Has a type — text, number, date, enum, reference, formula — and validation rules.
Object
A row in an entity table. One sample, one animal, one reagent. Gets a unique ID and a human-readable display ID like SMP-024.
Result
A measurement row in a result table. Always belongs to a result batch (a recording session). Splits explicitly into dimensions and measurements.

The lifecycle

Designing a schema in Dalea always follows the same six steps. Watch them auto-cycle or click any to inspect:

🧪
Environment
In-vivo PK
Tables
Animals, Doses, Samples, PK Results
|
Columns
Sex (enum), Weight (number, g)…
#
Naming schemes
Animal: ANM-{N}
Objects
ANM-001 … ANM-024
📈
Results
Concentration vs time

Schema design first (left three boxes), then data entry (right three). Most labs only revisit columns and naming schemes a few times before stabilising.

The environment lifecycle: schema design then data entry. The PK study you'll build in the tutorial follows exactly this sequence.

Entity vs result tables

This is the only schema decision that occasionally trips people up.

  • Entity tables describe things — animals, plasma samples, plates. One row = one thing. They're optimised for lookup and reference.
  • Result tables describe measurements — concentrations, viability values, expression levels. They're optimised for analytical queries (group, aggregate, filter on dimensions).

Result tables explicitly split columns into:

  • Dimensions — the axes you'll query and group by (animal, timepoint, treatment).
  • Measurements — the numeric values you actually recorded (concentration_ug_ml, body_weight_g, ct_value).

This split is what lets you ask "mean concentration at 4 h, grouped by dose group" in one click.

Naming schemes

Most labs hate manually typing IDs. Naming schemes generate them for you. A scheme is a pattern with placeholders:

  • ANM-{N} → ANM-001, ANM-002, …
  • SMP-{YYYY}-{N} → SMP-2026-001
  • [Sex]{N:000} → F001, F002 …

Schemes can reset per table, per workspace, or never. They run as soon as you create an object — you almost never assign a display ID by hand.

What's next