Database View or Entity Projection¶
Data projection — instantiates Aspect-Scoped Identity Projection
Exposes an entity under one aspect as a derived record assembled at read time from the underlying source, showing only the columns and rows that aspect is entitled to.
A Database View or Entity Projection is a read-time rule that presents an underlying entity under a single aspect: a stored query — a SQL view, a materialized projection, an API resource shaping — that selects which columns to expose, which to hide, and which rows to include, producing a derived record that looks like a standalone object but owns no data of its own. Its defining idea is that the aspect is computed, not stored. Nothing new is written; the same base rows are re-presented through a lens. The moment the underlying data changes, every view over it changes with no migration, because the view is a formula, not a copy. That is exactly what separates it from a stored schema: a view is a window onto the bearer, not a second record beside it.
Example¶
A retail company keeps one customers table — name, home address, purchase history, marketing-consent flag, internal credit score, support notes. Three teams need the same customer under three aspects. The finance team gets a view customer_as_billing: billing name, billing address, tax ID, outstanding balance — and nothing about marketing or support. The analytics team gets customer_as_segment: age band, region, lifetime value, purchase cadence, with the name and address projected out entirely so the segment record cannot be re-identified. The support team gets customer_as_case_contact: display name, contact email, open tickets, but not the credit score.
Each view is one CREATE VIEW … AS SELECT … over the single base table. A correction to the customer's address updates in one place and is instantly right in the billing view; it never appears in the analytics view at all, because that column was never selected. No team can see a field outside its projection, and because the views store nothing, there is no second copy to drift out of sync.
How it works¶
- Declare the projection. A query names the columns to surface, the columns to withhold, and any row filter (only active customers, only this tenant). This is the aspect.
- Bind to the source, don't copy it. The view references base tables by reference. Reads resolve against live data; the derived record is regenerated on each query (or refreshed on a schedule, if materialized).
- Map inheritance and exclusion. Each surfaced column is either passed through from the base, transformed (bucketed, masked, aggregated), or omitted — an explicit column-by-column decision recorded in the query text.
- Expose the derived record. Consumers treat the result as an entity —
billing_customer— querying and joining it as if it were a table, unaware it is a lens.
Tuning parameters¶
- Materialization — virtual (recomputed every read, always fresh, costs query time) versus materialized (precomputed and stored, fast reads, can go stale). The core latency-vs-freshness dial.
- Projection width — how many columns the aspect surfaces. Narrow views minimize leakage and honor least-exposure; wide ones reduce the number of views to maintain but weaken the boundary.
- Transform depth — whether columns pass through raw or are masked, bucketed, or aggregated on the way out. Heavier transforms strengthen privacy but move logic into the view where it is easy to overlook.
- Updatability — whether the view is read-only or writes flow back to the base. Writable views are convenient but the write-back semantics of a projection are notoriously ambiguous.
- Row-filter scope — how tightly rows are constrained (tenant, status, region). Tighter filters isolate aspects better but multiply near-duplicate views.
When it helps, and when it misleads¶
Its strength is logical data independence: one authoritative base, many aspect-shaped windows, none of which can drift because none stores its own copy.[n1] Corrections propagate for free, exclusion is enforced by omission rather than trust, and a new aspect is a new query rather than a data migration. For read-heavy separation of concerns it is the cheapest correct answer the archetype offers.
It misleads when a view is mistaken for a boundary it is not. A view that merely hides a column still resolves it underneath, so an unfiltered join or a careless SELECT * on the base can leak what the projection was meant to exclude — the hiding is presentational unless the base access is also restricted. Materialized views invite the opposite error: treated as fresh when they are hours stale, they quietly report yesterday as today. And because a view owns no lifecycle or key of its own, it cannot answer "which aspect is this, and is it still valid?" — only "what does the bearer look like through this lens right now." The guarding discipline is to pair the projection with real base-table access control, label materialized views with their refresh time, and never let a view stand in for a boundary that must actually keep two capacities apart.
How it implements the components¶
projection_scope_boundary— theSELECTlist and row filter are the boundary: what is surfaced, what is withheld, what is included.derived_bearer_record— the query result is the derived record — a bearer-shaped object assembled from, and linked to, the base rows without duplicating them.property_inheritance_and_exclusion_map— the column-by-column decision of pass-through, transform, or omit is exactly this inheritance-and-exclusion map.
It does not implement scoped_identifier_rule or aspect_conflict_resolution_rule — a view carries no key of its own and no rule for reconciling clashes with the bearer; those belong to its nearest twin, Role-Scoped Record Type, which stores a real record rather than computing a window.
Related¶
- Instantiates: Aspect-Scoped Identity Projection — the low-cost read-time way to present a bearer under an aspect without minting a second record.
- Sibling mechanisms: Role-Scoped Record Type · Aspect Lifecycle Register · Legal Capacity or Status Record · Role-Based Access Profile · Scoped Namespace Suffix · Typed Identity-Relation Edge · Work / Expression / Manifestation / Item Model
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: Database View or Entity Projection operates as a persistent arrangement of components, resources, interfaces, or technical topology because it exposes an entity under one aspect as a derived record assembled at read time from the underlying source, showing only the columns and rows that aspect is entitled to.
Independent corroboration: The frozen evidence defines Database View or Entity Projection as 'Exposes an entity under one aspect as a derived record assembled at read time from the underlying source, showing only the columns and rows that aspect is entitled to', so its operative form is Structure, Architecture & Configuration.
Nearest alternative: Intervention, Treatment & Transformation — A declared database view is an enduring configured projection whose live reads derive one aspect of the source.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Relational database theory cohered views as computed read-time projections over base data that provide logical data independence without owning a second copy of the represented entity.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
[n1] Logical data independence — E. F. Codd's relational principle that applications should see a stable logical view even as the physical schema beneath changes. A database view is the canonical instrument for it: consumers depend on the projection, not the base layout. ↩