83 Views

A view is a named, pure transformation over a model. It gives a stable read-only shape to a query result without making relations primary values in the denotational semantics.

Views are useful when one model should expose a controlled public interface over another. The view definition records the navigation and reshaping once, so clients can depend on the public shape rather than the internal storage shape.

Example: A View to Control Exposed Information

Imagine an internal employee system that stores operational details, including fields that should not be exposed outside the organisation:

namespace Internal
{
    entity Employee
    {
        Integer id;
        String name;
        String address;
        Money salary;
        key {id};
    }
    entity System
    {
        Employee employee*;
    }
}

The public interface is intentionally narrower. It reveals only the attributes external consumers are permitted to observe:

namespace Public
{
    entity Employee
    {
        Integer id;
        String name;
        key {id};
    }
    entity System
    {
        Employee employee*;
    }
}

A one-way transformation from the internal model to the public model can then be defined as a pure function:

func Public.System directory(Internal.System i) =
    Public.System {
        employee = i.employee.(id, name)
    };

The expression i.employee.(id, name) is ordinary query notation. It navigates to the internal employees and observes only the selected attributes needed by Public.Employee. The function body constructs a Public.System value whose employee extension is that shaped result.

Without the view, each downstream system would need to understand the internal schema, remove sensitive fields such as salary and address, and manually reshape the result into the Public.System structure. The directory function centralises that responsibility and gives consumers a stable read-only contract while the internal model remains free to evolve.

Semantic Status

A view does not introduce a new denotational category. Its body is interpreted using the same query semantics as any other expression: paths denote logic frames, and relation-shaped outputs are observed extensions of those frames.