3.4 Unity Catalog Naming Conventions, Environment Isolation, & Data Granularity

3.4 Unity Catalog Naming Conventions, Environment Isolation, & Data Granularity

DP-750 Exam Focus: Two blueprint bullets meet here - "Apply naming conventions based on requirements, including isolation, development environment, and external sharing" and "Choose granularity on a column or table based on requirements." Both look like style questions and are actually architecture questions: names encode the isolation boundary, and grain encodes what the table can and cannot answer.

---

1. The Hard Rules Unity Catalog Enforces

Before any convention, these are constraints the platform itself imposes on all Unity Catalog object names:

-- Legal, but every future reference needs backticks:
CREATE CATALOG `retail-prod`;
SELECT * FROM `retail-prod`.sales.orders;

-- Illegal: space and forward slash are rejected even inside backticks
CREATE CATALOG `retail prod`;   -- ERROR

-- The convention that avoids the problem entirely:
CREATE CATALOG retail_prod;
SELECT * FROM retail_prod.sales.orders;

Legacy contrast. Objects created in the legacy hive_metastore catalog are stricter still: schema, table, view, and function names there may contain only alphanumeric ASCII characters and underscores, and anything else raises INVALID_SCHEMA_OR_RELATION_NAME. Unity Catalog is more permissive, which is exactly why an explicit convention matters.

Delta Lake Column-Name Restriction

Delta tables without column mapping (delta.columnMapping.mode = name) cannot have column names containing a space, comma, semicolon, curly brace, parenthesis, newline, tab, or equals sign. Enabling column mapping lifts the restriction but upgrades the table protocol - which, as Section 2.5 notes, can lock out older readers.

---

2. A Naming Standard That Encodes Isolation

Unity Catalog's three-level namespace (catalog.schema.object) gives you exactly one strong isolation boundary - the catalog - and one organizational boundary - the schema. A working convention:

Why Environment Belongs in the Catalog Name

Putting the environment in the catalog rather than the schema or the table gives you three properties at once:

1. Fully qualified names differ across environments, so a notebook promoted from dev to prod fails loudly if someone forgot to parameterize the catalog, instead of silently writing dev data into a prod table.
2. Privileges are grantable at the isolation boundary. GRANT USE CATALOG ON CATALOG prod_retail TO prod_retail_readers scopes an entire environment in one statement.
3. Workspace bindings become meaningful. A catalog can be bound to specific workspaces so that prod_retail is not even resolvable from the development workspace:

-- Restrict a catalog to named workspaces (also available in Catalog Explorer -> Workspaces)
ALTER CATALOG prod_retail SET WORKSPACE BINDINGS ('<prod-workspace-id>');

Combine this with a Databricks Asset Bundle target variable so the catalog name is injected per environment rather than hardcoded (see Section 12.3).

Naming for External Sharing

Delta Sharing objects are read by people outside your organization, so their names leak information. Two rules:

• Never encode internal system names, cost centers, or project codenames in share and recipient names - a share called finco_project_bluebird_m_and_a tells a partner more than intended.
• Name the relationship, not the storage. retail_partnerco_sales is stable when the underlying table moves; adls_prod_container3_export is not.

---

3. Choosing Table Granularity (Grain)

Grain is the answer to one sentence: "one row in this table represents exactly one ____." If you cannot finish that sentence in a few words, the table has no defined grain and its aggregates cannot be trusted.

The One-Way Door

A finer grain can always be rolled up later. A coarser grain permanently destroys the detail needed to answer a question nobody has asked yet. If a gold table stores revenue per store per day, no query can ever recover revenue per hour. Practically:

• Keep bronze and silver at the finest grain the source provides.
• Aggregate only in gold, and only to a grain a stakeholder has actually requested.
• Build additional gold tables at different grains rather than coarsening an existing one.

Column Granularity

The same decision applies within a column:

Finer column granularity raises cardinality, which is exactly the input to the clustering decision in Section 8.3: high-cardinality, high-selectivity filter columns are good liquid clustering keys, while low-cardinality columns are usually better left unclustered.

Declare the Grain in Metadata

A grain that lives only in a design document is a grain that will be violated. Put it where every consumer and every discovery tool can read it:

COMMENT ON TABLE prod_retail.gold.store_sales_daily IS
  'Grain: one row per store_id per business_date. Revenue is net of returns. Late-arriving
   sales are restated for 7 days after business_date.';

ALTER TABLE prod_retail.gold.store_sales_daily
  ALTER COLUMN business_date COMMENT 'Store local calendar date, not UTC ingest date.';

Section 6.5 shows how these descriptions feed Catalog Explorer search and AI/BI Genie.

---

4. Exam Traps

• "Add the environment to the table name" (orders_prod) is the wrong answer. Environment belongs in the catalog so it can be bound and granted.
• Backticks do not rescue a space or a period. Those characters are rejected outright; only characters like hyphens are merely inconvenient.
• Aggregating in silver to "save storage" is a grain violation; the correct answer is a gold table at the requested grain.
• Case sensitivity: Unity Catalog lowercases object names, so Orders and orders are the same table. Column casing is preserved but queries are still case-insensitive.