Develop governance reports

Screenshot note: The schema diagram retains the source annotations and physical identifiers.

Use reporting models to build governance statistics and dashboards. Models define views, fields, relationships, and presentation; they do not modify governance objects or replace module permissions. Typical needs include assets by department, metadata by source, report usage, quality remediation, and combined dashboards. SQL examples in the source guidance target MySQL 5.7; revalidate functions, dates, and pagination for other databases.

Build reusable reporting models

Create statistical views before binding dashboards and reports rather than embedding separate SQL in each page.

bi_metadata_*_view views cover custom attributes, reports, files, datasets, systems, and sources. They translate technical fields into reporting semantics and relate IDs, types, departments, times, and states. Extend views and models for new metrics. Consult the Datablau delivery team for version-specific design, SQL, refresh, permissions, and publishing.

1. Define measurement semantics

Document objects, grain, deduplication key, time field, organization and state scope, refresh frequency, null handling, and permission boundaries in metric descriptions and model revisions.

Topic	Typical metrics	Key scope
Metadata	Tables, views, fields, departments, visits, favorites	Deletion and ID deduplication
Reports	Counts, types, refresh, top visits/favorites	Report, multidimensional, and list mappings
Files	Counts, departments, visits, favorites	Separate file objects from reverse-engineered structures
Systems	Counts, importance, domain, business/IT departments	Effective state and ownership
Sources	Connections, departments, types	Visibility and disabled connections
Datasets	Objects, business/physical names, sensitivity, levels, tags	Type IDs and access
Quality	Resolved, manual/automatic, overdue, priority, rules, issues, verification	Combined states and time semantics
Business/technical rules	Departments, importance, states, due within N days	Overdue basis and publication

2. Model layers

Model dictionaries describe catalogs, view catalogs, UDP management, report fields, view fields, relationships, views, connections, and subject areas. Views are primary deliverables. Separate topics and grains.

Subject area
`-- Statistics catalog
    |-- Metadata views
    |-- Report views
    |-- Quality views
    `-- Dimensions and relationships

Register connections, create views and fields, then define relationships and dashboards. Specify physical/display names, types, nullability, sorting, and filtering. Use UDPs for custom dimensions without redefining built-in fields. Record sources, joins, refresh, and permissions.

3. Development workflow

1. Create a reporting model with subject, connection, revision, and publisher.
2. Select authorized sources and define views and relationships. Use supported APIs or controlled reporting sources for cross-service data.
3. Register business names, types, sorting, and aggregation.
4. Parameterize SQL. Separate totals, distributions, rankings, and details. Define distinct-object versus row counts and deterministic ties.
5. Validate counts, departments, time boundaries, nulls, and permissions against known samples.
6. Publish model and dashboard; retain view/SQL revisions, refresh time, sample results, and access acceptance.

4. Types and revisions

Example type ID	Object
80000004	Table
80500008	View
80000005	Field
82800008	Metadata file
82800002	Metadata report

Resolve actual IDs from the current dictionary or type configuration rather than scattering constants through SQL. Retain object revisions so current states do not silently recalculate historical statistics.

5. SQL and permissions

Bind all input parameters. Filter by current user, organization, and catalog access, even when the reporting account can read more. Separate summaries and details. Refresh expensive queries asynchronously and record measurement time and revision. Preserve missing/deleted/inaccessible states rather than treating them as zero. Governance statistics still follow security policies.

6. Dashboard design

Organize systems, reports, files, datasets, and quality separately. Show totals and key states first, departmental/type distributions next, then rankings and details. Titles should state period, scope, and unit.

Quality dashboards should include issues, resolved and overdue counts, priority, rule type, issue state, and verification state. Technical rule dashboards can add importance, departmental states, and due-within-N-days lists.

7. Test, release, and upgrade

Test empty data, duplicates, cross-department permissions, time boundaries, state changes, deletion, field changes, and database differences. Retain manually checked expectations for every metric.

Deliver models, field/relationship dictionaries, SQL, dashboard configuration, refresh tasks, permission matrix, and rollback revision. On upgrades, check types, names, organizations, enums, time fields, source mappings, incremental semantics, and deduplication before comparing results.