TitanRDM Key Concepts

Reference Data

Reference data is additional data, often not found in transactional systems, that is used to map, categorise, augment, bucketize, rank, and organise data for the purposes of reporting, data integration, data migration, regulatory reporting, config data management, metadata and even simple apps. Examples include:

• Product categories and hierarchies
• GL account mappings
• Configuration parameters
• Bucketizing time of day into shifts (e.g., morning, afternoon, evening)
• Augmenting data with additional attributes or values, e.g. capacity limits
• Categorising Customers
• Simple lists like Country, currency codes, Status and type codes

In TitanRDM, each reference data set is stored as a table with a defined structure (columns, data types, primary keys, foreign keys). The tables can reference other tables for mapping, categorisation, and hierarchy definition.

Domains

A domain is an information subject area (e.g., Finance, Sales, HR) used to organise your tables and control who can access them. Every table belongs to exactly one domain. Permissions are granted at the domain level (or at the table level), so you can give your finance team access to finance tables without exposing HR data.

• Domains — more details about domains and how they are used to organise tables and control access

Table Definitions and Column Definitions

A table definition describes the structure of a reference data table — its name, domain, and the set of column definitions that specify each column's name, data type, constraints (primary key, required, foreign key), and validation rules (valid values, length).

Table definitions are metadata — they describe what the table looks like. When you deploy a table definition, TitanRDM creates or alters the actual physical database table to match.

• Table Definitions — more details about table definitions and how they are used to define the structure of reference data tables

Branches

TitanRDM uses a branching model inspired by Git to manage changes safely:

• Permanent branches (Production, Test) are long-lived environments. Every account starts with these.
• Development branches Every developer has their own dedicated development branch to make changes in isolation before merging back.

Each branch corresponds to a separate database schema, allowing developers to work independently without affecting each other. Changes made on one branch do not affect other branches until they are explicitly promoted.

• Branches — more details about branches and how they are used to manage changes

Deployments

A deployment takes the table definitions on a branch and applies them to the physical database. When you create or modify a table definition, those changes are not live until you deploy. The deployment process shows you a diff of exactly what will change — new tables, altered columns, removed columns — so you can review before applying.

• Deployments — more details about deployments and how they are used to apply table definition changes to the physical database

Promotions

A promotion moves table definition changes from one branch to another — typically from Development to Test, or from Test to Production. Promotions include a diff review and an approval workflow, so changes are reviewed before they reach production.

• Promotions — more details about promotions and how they are used to move changes between branches

Imports and Exports

TitanRDM supports importing data from CSV, Excel, JSON, and Parquet files, and exporting data to CSV. Imports can be performed through the UI or programmatically via the API/SDK. You can define reusable import mappings that map file columns to table columns, making repeated imports consistent and fast.

• Exporting Data
• Importing Data