Relationship Purpose¶

Every relationship type in the open metadata types has a relationship purpose. The purpose says why the relationship type exists: whether the element at the other end is part of the element, information attached to it, or something independent that it is linked to.

The purpose is stored in the relationshipPurpose attribute of the relationship type's definition (RelationshipDef). For the metadata repositories it is informational: they store it and return it with the type, but nothing in the repository depends on it. The Open Metadata Framework (OMF) defines the values in the OpenMetadataRelationshipPurpose enumeration, records them against each relationship type in OpenMetadataType, and returns them in the relationshipPurpose property of OpenMetadataRelationshipDef when a type is retrieved through the APIs.

Values¶

How the purpose is used¶

Operations that start on an anchored element¶

An anchor is the root of a group of elements that are managed as one object. Each member of the group carries the anchor's unique identifier in its Anchors classification. When an operation starts on the anchor itself, it takes the whole group: every element anchored to it, whatever relationships link them. The purpose does not come into it.

The purpose matters when an operation starts on an element that is anchored to something else, such as one table in a database schema. The operation must take the element and the parts that belong to it, but not its parent, its siblings or the things it happens to be linked to. All of these carry the same anchor identifier, so the Anchors classification alone cannot tell them apart. Egeria uses the direction and purpose of each relationship instead:

• It follows a relationship only to the element at end 2 (downstream of the starting element). Its parent and anything else upstream are never taken.
• It follows only relationships whose purpose is STRUCTURAL or ATTACHMENT. An element linked for any other purpose is independent of the starting element, even when it shares the same anchor.
• It only takes elements that share the starting element's anchor. The anchor itself is never taken.
• An element whose Anchors classification names an element that has already been taken is always taken too, whichever end of the relationship it is at. For example, an endpoint is anchored to its connection.

This rule applies to three operations:

• Delete - deleting a table also deletes its columns and the comments attached to them. It does not delete a column in another table that one of its columns refers to with a foreign key, or the role of a person assigned to it.
• Archive - archiving uses the same rule to decide which elements receive the Memento classification. All of them get one shared archive suffix on their qualified names.
• Create from template - when the template is a member of another element's group, the new element copies only the template's downstream structure. Relationships into the rest of the template's group are not reproduced.

Elements that are their own anchor, such as most assets, are not affected: they are not taken by these operations whatever the purpose of the relationship. A cascaded delete is the way to remove a hierarchy of independent elements, such as a folder and its files.

Inheritance¶

A relationship type that has no purpose of its own uses the purpose of its nearest super type. A relationship type with no purpose at all is treated as independent and is never followed. If you add relationship types in an extension archive, set the purpose explicitly.

Visualization and tools¶

The purpose groups the relationships around an element by meaning: what it is made of, what is attached to it, who and what governs it, and where it runs. User interfaces and tools can read it from the type definition to lay out or filter a view of the element.

Relationship types by purpose¶

Each relationship type links to the page of the type model that defines it.

STRUCTURAL¶

Part of what the element is: the attributes of a schema, the endpoint of a connection, the steps of a process. There are 30 relationship types with this purpose.

ATTACHMENT¶

Information attached to, and owned by, the element: comments, notes, ratings, search keywords. There are 15 relationship types with this purpose.

ASSIGNMENT¶

Links the element to independent information that describes or governs it: an owner's role, a catalog template, a governance definition. There are 37 relationship types with this purpose.

MEMBERSHIP¶

Groups or organizes elements without owning them, such as collection membership. There are 13 relationship types with this purpose.

ASSOCIATION¶

Relates elements that keep their own identity, often in one direction, such as a foreign key between columns. There are 29 relationship types with this purpose.

PEER¶

A purely peer link between elements of equal standing, such as related glossary terms. There are 12 relationship types with this purpose.

DEFINITION¶

Links a design or specification to its implementation. There are 18 relationship types with this purpose.

DEPLOYMENT¶

Where something runs or is stored. There are 16 relationship types with this purpose.

DESIGN_LINEAGE¶

LineageRelationship and its subtypes: how data and control are designed to flow. There are 14 relationship types with this purpose.

ACTION¶

Information gathered so that action can be taken, such as the targets of a governance action or the subscribers to a notification. There are 7 relationship types with this purpose.

ACTIVITY¶

A record of action that took place. There are 12 relationship types with this purpose.

Raise an issue or comment below