Centralize and scale modeling standards

Global Standards (GS) provide a framework to define reusable modeling conventions that are enforced across multiple projects. This ensures consistency, reduces duplication, and enables streamlined governance for data modeling at scale.

Standards are defined in Global Standards project and then applied to mapped projects (also called local projects).

Standards cover:

• Case standards: Control rules for object names for physical and logical models (e.g., PascalCase).
• Name mapping: Automate name declarations across environments.
• Glossary: Define business terms and ensure consistent usage across models.
• Table templates: Reusable templates for standardized table structures.
• Column templates: Reusable column structures for consistency across tables and models.
• Flags: Metadata labels that inform modeling decisions or workflows.

The following video gives a brief overview of Global Standards in action. 

Workflow Overview: From Standard Definition to Inheritance

The Global Standards workflow includes the following steps:

1. Create a Global Standards project
2. Define standards and conventions within the Global Standards project.
3. Map the Global Standard to selected child projects.
   1. (Teams are free to create multiple Standards and apply them to projects of the same database type)
   2. (A child project can only be mapped to one Standards project at a time)
4. Open the child project(s) to set the enforced standards.
   1. (A summary of standards and changes is presented, which must be accepted and applied before further changes to the child project can be saved)
5. Repeat. Make additional changes to the Global Standards project and repeat step 4.  

Implementing Global Standards

The following is a step-by-step walkthrough for creating Global Standards and mapping them to local projects.

Step 1: Create a Global Standard Project

Only account admins (including alternate admins) can create a GS project.

1. Go to Account > Global standards.
2. Click Create standard.

3. Select a database type or choose to copy from an existing project. When copying from an existing project, only the Global standards settings will be copied. The data model itself will not be included.

   

4. Define standards in the new GS project. The standards include:
   • Case standards: Set object name casing rules.
   • Name mapping:  Specify naming conventions for logical and physical model objects.
   • Glossary: Configure rules to automatically transform terms and abbreviations in logical and physical names.
   • Column templates: Define and group column sets for reuse.
   • Table templates: Create structural table blueprints.
   • Flags: Add labels to indicate contextual meanings (e.g., Sensitive, Deprecated).

All the changes made to the standards will be available in the new Global Standards ribbon. Changes can be made directly into this direct access through the contextual menu of every element.

5. Save changes in the GS project.

Account Admins can distribute the standards functionality to other modelers using SqlDBM’s project sharing functionality.

Note: Reverse/forward engineering, model comparison and database documentation are disabled in GS projects.

Step 2: Map Global Standards to Projects

Only admins can perform mapping.

1. Return from GS project to Global standards.

2. On the Global Standards page, click "Map project" for an existing GS project. The control is also available in the Global Standard three-dot menu.

3. Select local projects to map (only projects matching the Database type and not linked to other Global projects will be shown).
4. Once projects have been selected (or deselected) click "Update projects mapping".

When updating project mappings:

• New mapped projects will immediately inherit the latest GS standards.
• Mapping is one-directional: local cannot change global rules.
• If unmapped, standards become local and editable.

Step 3: Use Global Standards in Mapped Projects

Mapped (local) projects display inherited standards via the GS section in the Explorer on the left sidebar.

Inheritance rules:

Conflict Handling:

• Conflicting local project glossary items are automatically set to 'Not used’.
• Column templates naming collisions automatically append postfixes to the local project column template names (e.g., _1, _2).
• Column template update confirmation is required if structural differences are detected.
• Popups will guide through resolution options (e.g., override, rename, detach).
• The system allows for selecting a single solution for all column template conflicts of a given type.

Step 4: Update Global Standards and Apply Changes

When the GS project is updated, mapped projects are notified.

Update workflow:

1. Project teams of the mapped projects are notified about the Global Standard update via email. They are also notified when they open or refresh the local project in the tool:
   "Global standard has been updated. Update in order to save the project."

2. Clicking Update standards in a mapped local project opens a summary pop-up:
   • Column template and column conflict resolution: Review conflicts between existing and updated column templates.
   • Global standards updates summary: Displays added, removed, and modified standards.
   • Local project changes: Summarizes updates to local column templates and columns.

Note: Since flags are automatically applied to each mapped project, they are not included in the summary window.

3. User can:
   • Apply: Changes are applied, and a draft revision is created.
   • Close the pop-up: Changes are not applied.

Note: Saving is blocked until updates are applied.

Example: Applying GS Standards to a Local Project

Scenario:

• A GS project defines a gs_created column template with:
  • created_at (timestamp)
  • created_by (varchar)

In Project B (mapped project):

• new_table already has a created_at column with type date.
• When applying updates:
  • A popup prompts to detach the column template or override the column with template.
  • If overridden: created_at is updated to match GS definition (timestamp).

  • If detached: gs_created is not applied, and the local column remains.

    

Outcome:

• Standards are aligned.
• Conflicts are resolved with user control.
• Traceability is maintained with compare revisions.

Additional Details

• Permissions:
  • Only Admins can have edit access to the Global Standard projects and set the mapping.
  • Modelers can be added to the project team of already-existing GS projects.
  • Consumers have read-only access.
• Concurrent working:
  • GS standards apply per branch.
  • Branches must sync with main to maintain consistency.
• Deleting GS Projects:
  • To delete a GS, all related projects must first be unmapped.
  • Local projects keep the last applied standards as editable copies.
• Grandfathered or legacy exclusions:
  • If the "Exclude from naming rules" property is enabled for an object in a mapped project, the case standards, name mapping, and glossary defined in the GS project will not change its name. (See the related article "Settings and conventions" for more info.) 

See also

• Naming Conventions
• Table Templates
• Column Templates
• Object Flagging
• Project Sharing
• Settings and conventions