Building and Administering the Presentation Layer
Purpose of the presentation layer
The presentation layer is the user-facing skin of the repository. It renames logical columns into business-friendly terms, organizes them into subject areas and folders, defines presentation hierarchies for drill-down, and controls which columns are visible. Users never see BMM names; they see what the presentation layer exposes. Good design groups related columns, hides surrogate keys, and gives hierarchies meaningful level names so drill-down behaves intuitively.
Administration tasks
Admins create presentation catalogs and tables, set column visibility, define hierarchies, and manage aliases so the same logical column appears under different names. They also control formatting defaults and sorting behavior. Because presentation objects reference BMM objects, renaming or restructuring the BMM layer can break presentation objects - always validate the repository after changes. Permissions on presentation objects are enforced alongside catalog permissions, so a column hidden here is invisible regardless of catalog rights.
Traps to watch
A common trap is assuming presentation-layer changes affect stored data - they do not; they only change exposure and labeling. Another is confusing hide with delete: hiding a column keeps it available to existing analyses in some configurations, whereas removing it breaks references. Questions may ask where drill-down hierarchies are defined - the answer is the presentation layer, built on BMM logical levels. Also remember that a column can be visible in one presentation table and hidden in another.
Rule of thumb
If a question asks about user-facing names, folders, visibility, or drill paths, the answer is the presentation layer. If it asks about calculations, aggregation, or mappings, it belongs in the BMM layer.