SDB_View - View definition

A view definition allows defining the elements of a database view. A view is considered as method of a structure (or a combination of structures), which is called the structural (or intentional) base of the view. The structural base is defined in the FROM clause of the view.

The result of a view can be stored as persistent view by making the view persistent. This allows defining one or more ODABA extents for storing the view. Persistent views are not updated automatically, but must be updated by the user.

The view structure is defined by a number of properties (attributes and references) in the view. Defining relationships makes sense in case of persistent views, only. All properties defined for a view should have a source definition, which defines the expression or path for the property. Properties, which do not have a source definition, can be evaluated in an appropriate context class or the view structure or the property.

One may define views based on views or properties based on view structures. When a property is defined with a view structure as type, the view applies on the source for the property, which is defined in the constraint. When applying a view to a property, one may refer directly to a source property (or property path or expression) or to a local view extent.

Aggregated views can be defined by using the GROUP [BY] clause. Aggregated views always contain a value and a partition property. Other properties can be defined by means of aggregation expressions for the partition collection.

One may define one or more keys for the view, which consist of view attributes. Those keys can be used for creating indexes for persistent views. Aggregated views do always have an identifying key __ident_key.

Views can be used as reading or updating views. One may, however, update only those properties, which are connected with its source directly via property paths. This is possible also via several steps, i.e. when defining views on views. As soon, as at least one expression is defined on the way to the database source for a property, this property cannot be updated.

A view becomes an aggregation schema, when an aggregation type has been defined. For ordinary structures or views, the aggregation type is AGT_undefined.

An aggregation data type is an extended structural view definition. It defines a hierarchical view to a complex data type, which provides aggregated data in a simple or complete aggregation hierarchy. Each level in the hierarchy represents aggregated data evaluated from the attributes included in the aggregation (values). The aggregation levels are created according to the defined aggregation key components (grouping attributes, dimensions). Dimensions and attributes (values) define the attributes of the aggregation data type.

The lowest aggregation level is defined as view attributes follow the rules for view attributes defined in the SELECT clause of the view definition. Transient view attributes are not aggregated but calculated on instance level. Aggregation attributes are calculated by means of aggregation functions. Same rules apply on higher aggregation levels, i.e. same aggregation functions used for calculating view attributes are used for calculation aggregation attributes on higher levels. Since higher level aggregations are based on aggregated values, one should not use average() or variance() as aggregation functions in an aggregation model. Instead, the statistic() function may be used, which provides average, variance and standard deviation as derived values.

Aggregations may be defined as transient or persistent aggregations. Transient aggregations are calculated on demand, while persistent aggregation instances are stored in the database. Persistent aggregations are maintained automatically, when values in source instances change. Transient aggregations are calculated once, but need to be refreshed explicitly in order to reflect updates in the source. For defining a persistent aggregation, an extent definition has to be provided for the aggregation structure.

Regardless on aggregation storage type (transient or persistent), aggregation instances for all levels are stored in one collection. Besides, aggregation instances form hierarchies, i.e. each aggregation instance provides a number of grouping instances and aggregation parents.

Values are evaluated in the sequence as they are defined. Aggregated levels are evaluated by instance or by collection. Each aggregation instance contains a level identifier (char[8]), which defines the variable grouping attributes on this level. When, e.g. defining grouping attributes region, sex and age_group for persons, the aggregation on region level gets the level identifier 10000000. Level region|age_group gets identifier 10100000 etc. In order to get aggregation instances for a certain aggregation level, a filter condition may be set with the level identifier.

Besides aggregation values and dimensions, several implicit attributes and relationships are created in order to maintain aggregation hierarchies properly. Moreover, one may define additional properties for the aggregation data type. This properties (attributes, relationships or references) have to be maintained by the application. Typically, those properties are set by implementing doAfterCreate() or doBeforeStore() handler in the context o the aggregation data type.