Understand metamodels and built-in models

A metamodel defines object types, properties, and relationships. Metadata contains instances of those definitions. It is a structural design, not a single table or task.

Understand the four components

Component	Purpose	Example
Model	Overall structure for an asset class	Database, API, data product model
Object	Managed entity type	Database, table, endpoint, data product
Property	Object characteristic	Name, definition, owner, URL
Relationship	Containment, reference, dependency, association	Database contains table; metric derives from column

Objects are units in Datasets and the catalog. Properties determine details; relationships support tree navigation, links, and analysis.

Use built-in metamodels

Built-in models include dedicated harvesting and governance pages:

• Database model: databases, schemas, tables, columns, views, procedures, functions, indexes, primary and foreign keys.
• REST API model: services, endpoints, request/response parameters, relationships.

You do not need to redesign these objects or individually map columns to custom models. See Compatibility for supported sources.

Choose a built-in or custom model

Need	Path	Reason
Databases, warehouses, conventional columns	Built-in database model	Dedicated harvesting and display
OpenAPI/REST endpoints	Built-in API model	Reusable structures and harvesting
Regulatory submissions, devices, enterprise products	Custom model	Organization-specific structures
Add business descriptions to tables	Maintain properties or mappings	No new model required

Create custom models only when built-in models cannot express the object boundary. Assess impacts before changing core objects referenced by tasks, catalogs, or APIs.

Understand DAM and SQLink paths

DAM commonly uses plugins and Excel templates; SQLink emphasizes file harvesting and lineage. Do not interchange their root, namespace, and schema rules.

Next: Design metamodels and Harvest custom objects.