Skip to content

Concepts Overview

DeltaVault holds two pictures of your data and keeps them joined. One is physical: what actually exists in your platform, down to the column. The other is the business meaning: what your organization calls those things and what they are for. Almost everything else in the product, generation included, follows from that join being accurate.

The physical picture is a tree, and it is called the Catalog

Section titled “The physical picture is a tree, and it is called the Catalog”

Catalog is the screen where your metadata lives, and it is a tree you expand from the outside in:

  • A connection points at one data source or target. It is the root of a branch of the tree.
  • A catalog under a connection is one physical catalog on that platform.
  • A schema inside a catalog is a storage namespace.
  • A table or view sits in a schema.
  • Columns are on the table, each with its data type, its position, and flags for whether it is a primary key, a business key or nullable.

Two words are doing double duty here and it is worth separating them once. Catalog, the item in the sidebar, is the whole browsable tree. A catalog inside that tree is a single platform catalog under one connection. The screen contains many of the rows that share its name.

You do not type this tree in by hand. Import metadata, on a workspace, reads the structure of a real source and writes it into the Catalog for you. Adding nodes by hand is available and is the exception rather than the route in.

The business picture is a separate vocabulary, mapped onto the physical one

Section titled “The business picture is a separate vocabulary, mapped onto the physical one”

The business layer is deliberately not a copy of the physical one, because your organization’s language rarely matches the shape of its warehouses.

  • An entity is a business level thing your organization talks about, such as a customer or an order. Each carries a status, so you can tell a Draft definition from an Approved one.
  • The Glossary is where an entity’s attributes live: the named, defined properties that belong to it. It is the answer to “what do we mean by this field”, kept in one place instead of in several people’s heads.
  • A model groups entities and the relationships between them, either relationally or dimensionally. One route presents models as Domains; they are the same things.
  • Map & Match is where the two pictures are joined: a table is linked to an entity, and a column to an attribute. Until that link exists, DeltaVault knows a column’s data type but not its meaning.

Projects and workspaces are how the work is scoped

Section titled “Projects and workspaces are how the work is scoped”

A project is a unit of work with its own source and target connections. A workspace is a scoped area inside a project, so that several people can work on different parts of it without colliding. Both narrow what you see: the Catalog opens scoped to whichever one you are inside. Both belong to the paid editions: the free edition has no catalog for a workspace to select from, so its models live at organization level.

Two actions live on a workspace and they are the loop you will use most. Import metadata brings source structure in. Build generates pipeline code from what the catalog now knows, and each run is recorded under Builds.

Changes are versioned before they are permanent

Section titled “Changes are versioned before they are permanent”

Metadata edits do not land on your organization’s canonical state immediately. They accumulate on a branch, and what you see is the canonical state with your branch’s pending changes laid over it. Branches is where you review those pending changes and commit them. That is why a new organization spends a moment creating a main branch before it shows you anything: there has to be somewhere for your first change to go.

Where to go next

Section titled “Where to go next”