Matrix: Abstraction layer

The layer that sits between the data and the reports: single definitions, structure, reuse, row-level rights, languages, description, change, performance.

≈ 11 min readReading

In brief

8 dimensions, levels 0 to 5, 112 criteria.
Tool: run an assessment by choosing "Abstraction layer".
Levels and criteria: original synthesis, references cited at the bottom of the page.

On this page

Overview
Definitions and structure
Access and security
1. Row-level and object-level security
2. Languages, formats and labels
Change and usage
Sources and verification

Scope

The abstraction layer between the stored data and the reports, whatever the technology (semantic model, cube, views, metrics layer): single definition of measures, model structure, reuse, row-level security, languages and formats, description, version compatibility, performance. The underlying tables belong to the "Storage" theme, the reports to the "Reporting" theme.

8 dimensions, six levels (0 to 5) and 112 observable criteria. To place your product: open the assessment for this theme. The scoring rules are here.

Overview#

Each cell is the level's signature for the dimension.

Dimension	0 · Handcrafted	1 · Locally tooled	2 · Shared	3 · Industrialized	4 · Integrated and governed	5 · Autonomous
Single definition of measures	Each report calculates its indicators its own way.	Indicators listed.	Measures centralized.	Measures managed.	Measures verified.	Measures steered.
Model structure	One big flat table, or as many tables as there are reports.	Tables separated by subject.	Facts and dimensions.	Conformed model.	Controlled model.	Model checked automatically.
Reuse and sharing	A model copied and modified for each report.	Models identified.	Shared model.	Common model and specifics.	Governed composition.	Reuse steered.
Row-level and object-level security	Confidentiality ensured by separate reports for each audience.	Filters in the reports.	Rights in the layer.	Dynamic rights.	Controlled rights.	Rights verified continuously.
Languages, formats and labels	Technical labels, a single language, formats specific to each report.	Readable labels.	Common formats.	Languages managed.	Translations controlled.	Translations automated.
Description and discoverability	Technical names, no description.	Explicit names.	Descriptions in place.	Descriptions managed.	Discovery made easy.	Description maintained automatically.
Versions and compatibility	A change to the model breaks reports, discovered in use.	Changes known.	Changes versioned.	Compatibility sought.	Compatibility verified.	Compatibility automated.
Layer performance	Slow response, unexplained.	Slowness known.	Lightened model.	Systematic optimization.	Performance under control.	Adaptive performance.

Link with the overall model

Dimensions of the overall model that are most relevant: Semantic model and metrics, Access and entitlements, Documentation and traceability and Availability and performance.

Definitions and structure#

Single definition of measures#

Is each indicator defined once, in one place, for all reports?

Level	Signature	Criteria to meet
0 · Handcrafted	Each report calculates its indicators its own way.	Starting point: no criteria.
1 · Locally tooled	Indicators listed.	The main indicators are listed with their formula. Known discrepancies between reports are explained.
2 · Shared	Measures centralized.	Indicators are defined in the abstraction layer, not in each report. Each indicator has a unique name and a description. A report that needs an existing indicator reuses it without redefining it.
3 · Industrialized	Measures managed.	Each indicator has a business owner who validates its definition. Indicators are named according to a common rule (base, period, variant). A variant of an indicator (period, scope) is derived from the base indicator, without copying the formula.
4 · Integrated and governed	Measures verified.	Each indicator has a set of test cases with an expected value. A change of definition is announced to users before it goes live. Indicators can be queried from several tools (reports, spreadsheet, queries) with the same result.
5 · Autonomous	Measures steered.	Definitions are kept in versioned files, applied automatically to the layer. An indicator that is defined twice or contradictorily is detected automatically. The usage of each indicator is measured so that those nobody uses can be retired.

Effect on the user

The same figure has the same value everywhere, and a change of definition is made in one place only.

Model structure#

Does the structure serve analysis: analysis tables, relationships, grain?

Level	Signature	Criteria to meet
0 · Handcrafted	One big flat table, or as many tables as there are reports.	Starting point: no criteria.
1 · Locally tooled	Tables separated by subject.	Tables are separated by subject (sales, customers, products). Each table has a unique key.
2 · Shared	Facts and dimensions.	Tables are classified as fact tables (measures) and dimensions (filter and grouping axes). Relationships are declared, and their direction is chosen (one to many). The grain of each fact table is homogeneous.
3 · Industrialized	Conformed model.	Common dimensions are shared across fact tables. The roles of a single dimension (for example order date, delivery date) are modeled explicitly. Inactive or bidirectional relationships are rare and justified.
4 · Integrated and governed	Controlled model.	The effect of each relationship on the figures (back-filtering, double counting) is analyzed and documented. Special cases (many-to-many, dimension history) have a defined treatment. Technical columns are hidden, so that only what is useful for analysis is visible.
5 · Autonomous	Model checked automatically.	Automatic checks detect any deviation from the structure rules (grain, keys, relationships). The structure is generated or verified from the metadata of the storage layer. Discrepancies between the model and the underlying tables are detected before go-live.

Effect on the user

Figures can be cross-analyzed as expected, without producing a wrong result through a bad chain of joins.

Reuse and sharing#

Does a single model serve several reports, several customers, several teams?

Level	Signature	Criteria to meet
0 · Handcrafted	A model copied and modified for each report.	Starting point: no criteria.
1 · Locally tooled	Models identified.	Existing models are listed with their reports. Copies are spotted.
2 · Shared	Shared model.	Several reports rely on one published model. Reports do not contain a copy of the model's data. A change to the model is visible to all its reports without republishing.
3 · Industrialized	Common model and specifics.	A common model carries the standard definitions; specifics are isolated. A customer- or project-specific element is added to the common model without modifying it. Specific elements are listed and linked to whoever requested them.
4 · Integrated and governed	Governed composition.	Models can be composed (one model reuses another) according to written rules. The impact of a change in the common model on the specific models is known before deployment. A specific element that is useful to several parties is considered for inclusion in the common model.
5 · Autonomous	Reuse steered.	The reuse rate of the common model is measured, and the gaps to close are tracked. Specific models are rebuilt automatically with each new version of the common model. Elements duplicated between models are detected automatically.

Effect on the user

Fixing or enriching something once benefits everyone, and nobody maintains their own copy.

Access and security#

Row-level and object-level security#

Does everyone see only the rows and objects they are entitled to, whichever report is used?

Level	Signature	Criteria to meet
0 · Handcrafted	Confidentiality ensured by separate reports for each audience.	Starting point: no criteria.
1 · Locally tooled	Filters in the reports.	Visibility scopes are filtered in the reports. The list of people authorized for each scope is maintained.
2 · Shared	Rights in the layer.	Row-level restriction is defined in the abstraction layer, not in each report. Role membership is managed through groups, not person by person. A person with no role sees no data.
3 · Industrialized	Dynamic rights.	A single rule depends on the person's identity and on an assignment table (dynamic rights). Rights are tested by role before go-live, including edge cases. Sensitive columns and objects are protected at the layer level (object security).
4 · Integrated and governed	Controlled rights.	The effect of security on the figures (totals that differ by role) is explained to users. Security works in every tool that reads the layer, including direct access. Special cases (administrators, service accounts, external guests) have a documented treatment.
5 · Autonomous	Rights verified continuously.	Automatic tests check each role with every new version. Discrepancies between expected rights and effective rights are detected automatically. Access to data outside the usual scope is flagged.

Effect on the user

The confidentiality rule is applied in the layer, and therefore everywhere, including in a spreadsheet or a new report.

Languages, formats and labels#

Do names, formats and languages adapt to the user?

Level	Signature	Criteria to meet
0 · Handcrafted	Technical labels, a single language, formats specific to each report.	Starting point: no criteria.
1 · Locally tooled	Readable labels.	Visible labels are understandable (no technical names). Units are specified on measures.
2 · Shared	Common formats.	Each measure has a default format (decimals, separators, currency). Labels are managed in a single place in the layer. Dates and periods follow a common calendar.
3 · Industrialized	Languages managed.	The layer's labels exist in several languages. A label missing in a language displays the fallback language, not an empty value. Translations are kept in a single source, outside the reports.
4 · Integrated and governed	Translations controlled.	Translations go through a review process. A new label without a translation is detected before go-live. Each user's language and formats are applied automatically.
5 · Autonomous	Translations automated.	A translation is proposed automatically for any new label, then validated. Terminology discrepancies between languages are detected. Translations are applied to the model by a process, with no manual entry.

Effect on the user

Everyone reads the figures in their own language and format, without the model being duplicated.

Change and usage#

Description and discoverability#

Does a user find the right fields, and understand their meaning and limits?

Level	Signature	Criteria to meet
0 · Handcrafted	Technical names, no description.	Starting point: no criteria.
1 · Locally tooled	Explicit names.	Tables, columns and measures have explicit names. Objects that are useless for analysis are hidden.
2 · Shared	Descriptions in place.	Each useful table, column and measure has a description that explains its meaning and use. Hierarchies (year, month, day; category, product) are declared. Data categories (country, address, link) are filled in.
3 · Industrialized	Descriptions managed.	Descriptions are reviewed with the business owners. Each field states its data source and its freshness. Fields being retired are flagged as such.
4 · Integrated and governed	Discovery made easy.	Fields and measures are searchable from report authoring tools. Models are published in a catalog with their description and their owner. Usage examples (typical reports, typical questions) accompany each model.
5 · Autonomous	Description maintained automatically.	Descriptions are generated from metadata and proposed for validation. A field with no description or no usage is detected automatically. Users' questions about the meaning of a field improve the descriptions.

Effect on the user

An analysis can be built without asking the technical team what a field means.

Versions and compatibility#

Does a change to the layer break existing reports, your own and your customers'?

Level	Signature	Criteria to meet
0 · Handcrafted	A change to the model breaks reports, discovered in use.	Starting point: no criteria.
1 · Locally tooled	Changes known.	Changes to the layer are announced to the teams concerned. Reports that use a modified field are searched for by hand.
2 · Shared	Changes versioned.	Each change to the layer is recorded in a dated version. The names of published fields do not change without reason. A rename or a removal is treated as a change that must be announced.
3 · Industrialized	Compatibility sought.	Fields have stable identifiers: a rename does not break the reports that use them. The list of reports that consume each field is known. An incompatible change is preceded by a period during which the old and the new field coexist.
4 · Integrated and governed	Compatibility verified.	Reference reports are rechecked before each go-live of the layer. Reports of customers or third-party teams are covered by the check, or their owner is notified. Removing a field follows an announced deprecation schedule.
5 · Autonomous	Compatibility automated.	An incompatible change is detected automatically by comparing two versions of the layer. Affected reports are listed and fixed automatically when the change is simple. The stability of the model (number of breaking changes per version) is tracked.

Effect on the user

The model can evolve without the reports already built ceasing to work.

Layer performance#

Does the layer respond quickly, even with a lot of data and many people?

Level	Signature	Criteria to meet
0 · Handcrafted	Slow response, unexplained.	Starting point: no criteria.
1 · Locally tooled	Slowness known.	Slow queries are identified. The size of the layer is known.
2 · Shared	Lightened model.	Columns that are useless for analysis are not loaded into the layer. High-cardinality columns (identifiers, timestamps) are dealt with. The storage mode (copy, direct access, mixed) is chosen for each table according to its use.
3 · Industrialized	Systematic optimization.	Measures are written so as to limit the computation cost (reviews, analysis tools). Aggregations prepare the most requested calculations. Response times are measured with row-level rights applied.
4 · Integrated and governed	Performance under control.	A degradation in response time is detected before a version goes live. The layer is tested with the expected number of concurrent users. Resources are sized according to the measured load.
5 · Autonomous	Adaptive performance.	Aggregations are created or removed according to measured usage. Capacity adjusts automatically to the load. A performance threshold is part of the acceptance criteria for a new version.

Effect on the user

Figures display quickly and predictably, without report authors having to work around the model.

Origin of the criteria

The dimensions are inspired by the references cited below; the levels and criteria are an original synthesis, not a reproduction of a framework. They are offered for discussion and adaptation, not as authoritative.

Sources and verification#

Microsoft Learn — Understand star schema and the importance for Power BI — dimension tables (filter, group) and fact tables (summarize), grain, surrogate keys, role-playing dimensions, slowly changing dimensions
Microsoft Learn — Row-level security (RLS) with Power BI — roles and row filters, dynamic rules based on identity, testing by role, limits (the restriction does not apply to workspace editing roles)
dbt — About MetricFlow (semantic layer) — define metrics once, as a single source, and generate queries; entities, dimensions, simple, derived, ratio and cumulative metrics
Kimball Group — Dimensional Modeling Techniques — grain, conformed dimensions, surrogate keys, slowly changing dimensions
Microsoft Learn — Optimization guide for Power BI — names, descriptions, hiding, hierarchies, measures, formats and data categories as aids for users of the model; storage modes