Registry Data Model

Overview

The COmanage Registry Data Model revolves around the CO Person, which conceptually represents one person associated with a CO.

• A COmanage installation is referred to as a Collaboration Management Platform, or CMP.
• A CMP is a multi-tenant installation, each tenant is referred to as a Collaborative Organization or CO.
• The core operational record of a participant within the CO is the CO Person.
  • The CO Person record maintains information that is unique to a person within the CO, such as names and identifiers.
  • An individual person should only have one CO Person record within a CO.
  • However, an individual person may participate in multiple COs housed within the same CMP, and could therefore have multiple CO Person records (each isolated from the other) within the CMP.
• In order for a person to become a CO Person, they must first have at least one Organizational Identity, which conceptually represents their identity as asserted by a "home" or "external" institution, such as their University or a social identity provider.
  • It is possible for Org Identity records to be pooled across all COs within the CMP, however this setting is deprecated and not recommended.
  • A person's external credentials (federated or social login information) are attached to the Organizational Identity, and typically used for access to the platform's services.
• A CO Person record is created and one or more Org Identities are linked to it. 
• A CO Person may have one or more CO Person Roles within the CO. A CO Person Role record maintains information that is unique to a role a person has within a CO, such as title and physical address.
  • For some use cases, it is necessary for the CO to manage credentials such as SSH Keys. In this case, these Authenticators attach to the CO Person.

There are two ways to create sets of CO People within a CO.

• CO Groups are simple collections of CO People. Any CO Person can create a CO Group.
• CO Units (or COUs) are intended to represent an organizational hierarchy, including delegation of CO Person administration. Only CO Administrators can create COUs.
  • When COUs are enabled, CO Person Roles are attached to COUs.

See Also: Understanding Registry People Types

Tables

Registry is a database oriented application, with quite a few tables under the hood. These tables fall into a few broad categories:

• Primary Objects: Primary objects are those that directly relate to the primary purpose of Registry: storing information about people and other entities related to the organization. Example include CO Person and CO Departments.
• Secondary Objects: Secondary objects store additional information about Primary objects, in particular when there is a many-to-one relationship. Examples include Name and Email Address. 
• Configuration Objects: Configuration objects primarily relate to the behavior of the application.

Table Metadata

In addition to the column definitions available for each table below, all tables have additional columns used by the framework and supporting code. These columns include

• Timestamps managed by Cake (created, modified)
• Columns used in support of Changelog Behavior

Table Status

The statuses for each table are defined as

• Stable: The table definition will not change in a backwards-incompatible manner across minor releases. Stable tables may only be removed in major releases.
• Tentative: The table definition will likely become stable, but may change in a backwards-incompatible manner across minor and patch releases. Tentative tables may be refactored or removed without notice.
• Experimental: No specific assertion is made about the stability of the table. It may be changed significantly or even removed without notice.
• Obsolete: The table is no longer in use as of the specified version.
• Not Implemented: The table definition is for planning purposes only.

Major, minor, and patch releases are as defined in semantic versioning.

Table Inventory

• View All Tables in a list
• View data model as a high level ERD.