The most common use of a view is to rollup or flatten-out an information structure. In this example we show a "registry of records" according to the model below. Although simplistic, the model meets the general regulatory requirements by allowing records to be uniquely identified from the outside, using Record.Identifier, and by keeping track of who's responsible for the records, using Registry.Custodian.

 

 

Having this model, one immediately becomes interested in listing and managing the records based on the registry, i.e. to find all records that belong to a given registry. This can be accomplished using a view. For sake of clearity it should be noted that you don't need a view to accomplish such a trivial one-step listing, see the article Listing by relation.

 

We create a new view in the RISE Editor, based on the Registry entity and give it the more suitable name RecordsInRegistry. In the view editor we populate the view with the attributes of interest from the Registry entity. Then we extend the view using the Record entity along the Record relation, see the image below. Finally, we mark the Record join (right tree view) as mandatory since we're only interested in receiving pairs of record - registry information.

 

 

Once we're finished editing the view we'll have the below model. The rounded corner box, RecordsInRegistry, represents the created view and displays the attributes returned from that view. Note that RISE automatically names the view attributes to reflect their origin. The Name and Custodian attributes originate from the base entity of the view, to which the view is anchored in the drawing, and thus keep their original names. Attributes derived via a join are named by concatenating the join name with the name of the source attribute, e.g. Record + Indentifier.

 

 

 

 

Read about filtering view and using the where clause.

Learn when and how to use views in views.