Metadata

Metadata is data that resides within the ExtraView database. Metadata describes other data items. For example, the description for fields and their characteristics is metadata that is contained within the data dictionary. The following examples represent some of the types of metadata within ExtraView:

  • Data Dictionary
  • UDF Permissions
  • Title Mapping for localized data
  • Layouts for screens.

Metadata drives a very significant amount of functionality within ExtraView. Very little in the way of data relationships or field definitions is hard-coded within ExtraView.

For example, when you define a new User Defined Field, ExtraView does not create a new column in a database table. Metadata is created in a number of tables that describe the new field and its behavior; if the field is one of the list display types, pointers are set up to the members of the list where the values are stored.

The traditional method of setting up parent child relationships between fields in a database is to use foreign key constraints. While ExtraView makes extensive use of foreign key constraints, they are not used to manage the parent child relationships that you create yourself, between two or more of your fields. Instead, ExtraView uses metadata to describe these “Allowed Values”. This avoids the need to modify the database. It is interesting to note that every single ExtraView customer has the identical schema to its database. This avoids many of the headaches that application building companies have had in the past, when different customers had different schemas.

Issue Data

Issue data is the data stored within your system that contains the values of data. For example, issue data contains the text within an issue, or the value of the status of an issue. Sample issue data includes:

  • The item table which stores the key information about an issue
  • item UDF’s. These are the values of the user defined fields within an issue
  • product table information. This is where the product information is stored
  • module table information. This is where the module information (which is a child of product information) is stored
  • Repeating row records. These are structures that are dependent upon the issue data, and which can be repeated for different values within the issue.

Reports

Report data holds key information about reports held within ExtraView. For example, a report consists of a layout, filters, a title and description. There are several types of reports within ExtraView:

  • Quicklist – this is a built-in report format, used as a default layout for reports, when summary report information is required
  • Detailed Report – this is a built-in report format, displayed when the user wants a complete detailed record of their issues
  • Columnar Reports – these are designed by the user, and can display any set of fields (assuming the user’s role has permission) with a given set of filters
  • Summary Reports – these allow the summarizing of counts of issues of up to four fields, for a given set of filters
  • Matrix Reports – these allow the production of a table of information using two different fields, one as the count on the X axis and one as the count on the Y axis
  • Aging Reports – These provide information that summarizes the number of issues within different statuses, according to the time the issues selected by the filters for the report, have spent within the statuses. A drilldown allows the user to see the time each issue spent in all statuses up to the current point in time
  • Charts – these display information in a pie, line or bar chart form. Unlike other reports, they can display information for any date in history, up to the current date
  • Custom Report – allow an entry on the report menus for reports designed using techniques discussed in this document, and reports which cannot be built using the standard ExtraView reporting tools
  • Layouts for Existing Reports – These allow the user to combine the results of summary and other reports together and to create a style that is used to place the results on a layout. This layout is then rendered to PDF output when the layout is placed within a Container report
  • Container Reports – These are used to take the output from a Layout and place the output into a PDF file. Multiple layouts can be placed on a single Container report.