Business Ontology relationships¶
A relationship in Business Ontology is a governed, directed link between two nodes. Each node is a term, metric, or entity. The relationship is a typed edge that says how those nodes relate, so people and AI can follow approved meaning across domains instead of guessing from table names or a single Semantic View.
Relationships are not join paths and they are not representations. A Semantic View relationship tells the engine how to join logical tables at query time. A representation binds a node to an asset that implements it, such as a table, a view, a column, or a Semantic View. An ontology relationship links two business concepts to each other.
Business Ontology provides ten built-in relationship types plus the CUSTOM type. Choose the most specific built-in
type whose definition is satisfied. Use a custom type only when no built-in type fits and you explicitly define its
meaning and label.
Concepts, relationships, and underlying data¶
The core of Business Ontology is a graph of business concepts and the relationships among them. Its nodes represent concepts such as Customer, Customer ID, Region, and Net Revenue. They don’t represent individual customer records or the value of a metric at a particular time.
Actual records and values stay in the underlying data. For example, a row for customer C123 belongs in a table, and
the net revenue value for September belongs in a query result. Representations bind a table, view, column, or
Semantic View to the corresponding ontology concept. A Semantic View binding can name the view itself or a part of
it, such as an entity, dimension, fact, or metric. Cortex can then use the concept graph to reason about meaning
and use the binding to find the data that implements that meaning.
For example, the ontology can state that Customer is identified by Customer ID and that Region classifies
Customer. From those relationships, Cortex can reason about which identifier and classification concepts apply to
the Customer concept. A representation can then bind Customer to a Semantic View entity, Customer ID to its
identifier field, and Region to a dimension. The customer and region for record C123 are determined from the
underlying data, not stored as ontology edges.
How a relationship is defined¶
Every relationship has a source node, a target node, and a type. A custom relationship also has a label. You always author from source to target. The system stores one directional edge. If the UI shows the other node first, it renders the inverse reading. It doesn’t store a second edge.
For a custom relationship, the label must read as a grammatical English sentence in this template:
{Source name} {label} {Target name}
For example, a custom depends on label produces the sentence Order Fulfillment depends on Inventory Availability. Source doesn’t always mean the parent or the authoritative concept. Direction is defined per type so that the sentence reads naturally.
Ground every edge in a governed definition or an explicit assertion. Don’t infer a relationship from similar names, co-occurrence, or a physical foreign key alone. Don’t store every edge that could be inferred by walking a path; keep authored facts distinct from inferences.
Proposed relationships are stored as draft suggestions, separately from canonical relationships. In this preview, Snowsight lists draft nodes and doesn’t list draft relationships. Approve or reject a suggested relationship in Snowflake CoCo. Approval creates the canonical relationship. Canonical relationships have the following states:
- Approved: steward-approved and available to search and Cortex.
- Deprecated: kept for history and not served.
The following constraints apply when you author relationships:
- The source and target must be different nodes. Self-relationships are rejected.
- A source-target pair can have more than one relationship only when each relationship has a different type.
- A duplicate of the same source, target, and type is rejected.
- A draft suggestion is rejected immediately when the same approved source, target, and type already exists.
For the symmetric types, equivalent to and related to, an edge in either direction states the same fact, so check both directions before you create one. The reverse edge isn’t rejected: creating it produces a second relationship that appears as a separate edge in the graph.
On a node page, the ontology neighborhood places the current node in the center, with related nodes on either side. Switch the glossary to Graph to see the same edges across the domain.
Graph results are bounded. The graph for a node returns up to 1,000 relationships in each direction. The account-wide graph returns up to 10,000 relationships. If an imported glossary exceeds these limits, the graph doesn’t display every relationship.
Standard relationship types¶
The following types are the standard vocabulary. Each row lists the stored direction, the inverse reading the UI can show, and when to use the type:
| Label | Source → target | Inverse reading | When to use | Example |
|---|---|---|---|---|
| has variant | General concept → scoped, windowed, or parameterized variant | is variant of | The target is the same concept as the source, narrowed by time window, geography, segment, or another qualifier. This doesn’t assert type inheritance. | Same Store Sales Growth has variant Same Store Sales Growth - Trailing 28 Days |
| has part | Whole → component | part of | The target is a structural constituent of the source. Parts can be optional, replaceable, or repeated. This isn’t set membership, type inclusion, or physical location. | Order has part Line Item |
| derives | Input metric or concept → output computed from the source | derived from | The target’s value is calculated using the source as an input. Correlation or a generic dependency isn’t enough. The edge doesn’t claim the source is the only input. | Gross Revenue derives Net Revenue |
| measures | Metric → entity or concept it quantifies | measured by | The source is a numeric measure of some aspect of the target. | NPS Score measures Customer Satisfaction |
| identified by | Entity or concept → identifier concept | identifies | The target is the reference key that uniquely picks out instances of the source, not a particular ID value. | Customer identified by Customer ID; Product identified by SKU |
| classifies | Dimension or category → entity being categorized | classified by | The source assigns categorical grouping to instances of the target. | Region classifies Store |
| applies to | Policy, rule, or constraint → concept it governs | governed by | The source is a business rule or governance artifact that constrains the target. | Return Policy applies to Online Orders |
| scopes | Qualifying dimension, panel, cohort, or context → metric or concept valid in that boundary | scoped by | The source defines the population or context in which the target is meaningful. The target exists independently; the source narrows where it applies. | Fiscal Quarter scopes Revenue Recognition |
| equivalent to | Preferred term → term with the same meaning (direction is a display convention) | equivalent to (symmetric) | Both nodes are independently defined concepts with the same meaning and matching scope. For a name or abbreviation that isn’t its own concept, use the synonyms attribute instead. | Net Revenue equivalent to Net Sales |
| related to | Any node → any node | related to (symmetric) | A meaningful association exists, but no other built-in type fits. Use sparingly. Don’t use this to hide uncertainty. | Average Order Value related to Basket Size |
Choose the right type¶
Several types look similar. Decide from the roles of the two nodes, not from informal wording such as “contains.”
has variant vs. type inclusion. A trailing-28-days revenue metric is a qualified version of revenue, so use has variant. Type inclusion isn’t a built-in relationship in this preview. If you need to connect a subtype to a supertype, define a custom relationship with an explicit label. Custom relationships don’t provide automatic subtype inference.
has part vs. scopes vs. classifies vs. applies to.
- has part connects a whole to a constituent: Order has part Line Item.
- scopes connects a context boundary to a concept defined inside it: a data panel scopes a spend metric.
- classifies assigns a category label to instances: Region classifies Store.
- applies to connects a policy or rule to what it governs: Return Policy applies to Online Orders. A rule says what you must do. A scope says the metric means something only within a population.
“Contains” is not a type. Interpret that wording from the definitions:
- Structural composition (“an order contains line items”) is has part.
- Type inclusion (“Person contains the types Player and Coach”), set membership (“a segment contains customers”), and physical location (“a warehouse contains products”) aren’t built-in types. Model one as a custom relationship only when its meaning, label, direction, and endpoint roles are explicit.
equivalent to vs. synonyms. If two independently governed concepts have the same meaning and scope, connect them with equivalent to. If one string is only an alternate name or abbreviation, store it on the node’s synonyms list. Don’t create a second node for “GMV” if it’s just an abbreviation of Gross Merchandise Value.
Custom relationships¶
Use a custom relationship only when no built-in type fits and you supply a nonempty source-to-target label plus a definition of the endpoint roles. Custom types don’t inherit symmetry, transitivity, or other behavior from the built-in vocabulary. Don’t recreate a built-in type under another name.
Relationships outside the standard vocabulary¶
You can model the following ideas as custom relationships when the meaning is explicit and no built-in type fits. Don’t substitute a built-in type with different semantics:
- Depends on. Use derives only for an evidenced calculation input. For a generic operational dependency, define a custom depends on relationship, including its endpoint roles and direction.
- Type inclusion / subtype of. Define a custom relationship when the governed graph must connect one concept type to a more general concept type. Custom relationships don’t provide transitive subtype reasoning.
- Member of. A governed membership relationship between two concepts can use a custom member of relationship. Membership of an actual record in a set belongs in the underlying data.
- Instance of. Individual-to-type membership (for example, customer
C123is an instance of Customer) isn’t modeled in the concept graph. Actual instances are records in the underlying data, not ontology nodes. Use a representation to bind the Customer concept to the data structure that contains those records. - Owned by / stewarded by. Accountability is node metadata (owner, steward), not an edge.
- Represented as / implemented by. Bindings from a node to a table, view, column, or Semantic View are representations, not ontology relationships.
- SQL joins and foreign keys. Those belong on the Semantic View.
Relationships don’t automatically copy definitions, formulas, identifiers, ownership, access control, or other metadata from one node to another.