This section of the user manual provides an overview of the Meta Data Layer (MDL), including the rationale behind its development, its contents and its use. It assumes some 'technical' knowledge.

In this section:

Callista is, by any measure, a large and complex system. The underlying data structures are comprised of many layers of interconnected tables and views. As a result, it is difficult for most people to understand the data structures sufficiently well, or quickly enough, to effectively use them as a resource. The MDL provides a simplified data model for use by skilled end users and local developers.

The MDL consolidates several table layers into a single layer of views containing de-normalised data, i.e. a single parent or child record value from a parent-child table relationship may be repeated as part of numerous records in a de-normalised view. Because an MDL view consolidates data, it is possible to use a simple select statement to retrieve records, in contrast to complex queries required to extract the same records from the source tables. Some MDL views have been designed to pre-filter data. For example, separate views exist for active, inactive and planned course versions. This means that it is not necessary to perform complex queries through multiple table layers in order to return records of a particular system status.

One of the major advantages of the MDL is that its views can include derived data, making derived data available for selection. For example, the view MDL_STUDENT_UNIT_ATTEMPT_V has the column DER_EFTSU, the derived EFTSU for each unit attempt.

The simplified data model provided by the MDL makes information more readily available to a wider audience.

Uses include:

• Easier development of additional inquiry forms by local developers.
• Easier ad-hoc reporting by skilled end users is possible using a multitude of tools.
• Easier development of standard reports by local developers.
• A ready source of information to populate a data warehouse.

The potential of the MDL can be extended by joining MDL views with each other, with other views and with other Callista tables.

It should be noted that the MDL is designed specifically to simplify querying. It is not designed for update purposes.

The MDL has been constructed to a set of general standards. In most cases, the names used for views and columns are relatively self explanatory.

MDL views generally have the same name as the main table from which they are derived, with the addition of the prefix MDL_ and the suffix _V. For example, a view based on the table ATTENDANCE_TYPE has the name MDL_ATTENDANCE_TYPE_V. Where the records selected in a view are restricted to a subset of all possible records, the name of the view is modified to reflect this. For example, the view MDL_COURSE_VERSION_ACTIVE_V selects only active course versions. Some view names are abbreviated where they would otherwise be overly long.

Some views are not in fact true views but are simply an alias for an existing table or view. These are tables and views which have been identified as being useful in the Meta Data Layer in basically their original form. They are identified by the MDL_ prefix (only) appended to their original table/view name. Making these aliases part of the MDL simplifies management of MDL security.

The names of columns (fields) within views are generally the same as the names of the corresponding columns in the tables from which they are derived, prefixed by the alias of the original table. For example, the column Att_Research_Percentage, in the MDL_ATTENDANCE_TYPE_V view, is sourced from the Research_Percentage column in the ATTENDANCE_TYPE table, whose alias is 'att'.

Where calendars of a particular calendar category are included in views, the column names of the calendar type and sequence number are prefixed by the calendar category. For example, if the calendars are academic calendars the prefix 'Acad' is used, resulting in the column names Acad_Cal_Type, Acad_Sequence_Number and Acad_Alternate_Cd.

The following guidelines are applied to the inclusion or exclusion of records in MDL views.

• The columns Update_Who, Update_On and Logical_Delete_Dt are normally not included in MDL views.
• Columns containing system values are generally not included, unless they do not have corresponding institution defined values. e.g. if calendar status is included, system calendar status normally wouldn't be. However, system calendar category, which has no corresponding institution defined values, would normally be included. It is also generally the case that system values are included only where they are in the main table from which the view is derived.
• Closed indicator columns are generally included in views only if they are in the main table from which the view is derived.
• Where attendance mode, attendance type and location code are included in a view, their descriptions and the government values to which they map are normally included.

MDL views cannot be granted to a role or user using the Reconcile Object Grants process unless they are used by a form, report or job. It is also pointless for a DBA to grant access to these views via an internal Callista user role, as the first time the Reconcile Object Grants process is activated for the user role, the grants to these views will be dropped and will not be recreated. There are two solutions:

• A DBA can grant MDL views to a role or user outside of the Callista application. The recommended approach is to grant the views to a role (or roles) exclusively for MDL access, i.e. with no other function grants. The role(s) can be granted to users requiring MDL access in addition to any roles they have been previously granted and will be unaffected by reconciliation of object grants.
• MDL view objects can be associated with a dummy form or job (by a technical specialist). The form or job can be granted to a role, or to individual users. In this case performing the Reconcile Object Grants process will grant the required objects to the role or user.

Data restrictions are not applicable to users granted access to MDL views, as no restriction views exist. MDL access should not be granted to users with data restrictions.

Many MDL views contain large volumes of data, including data which is derived dynamically. Data retrieval rates are in proportion to the increased work load involved. Using criteria which quickly reduce the set of data returned by a select statement can dramatically improve retrieval times.

• A list of MDL views and their descriptions
• Tables detailing the contents of each view
• MDL data diagrams for each subsystem (or area within a subsystem)
• Guidance in the use of the MDL