Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 1 Overview of Data Structures : Re-usability of Data

Re-usability of Data
Much of the data available to you can be used in a number of different ways. By choosing the appropriate table types for your applications, you can limit the number of objects that require modifications as your applications evolve.
Design Options
The following design options can be used to promote re-usability of application code and data. You can use one or a combination of these design options.
Option 1: Using Parameterized Tables
A parameterized table is a table with one or more defined attributes that are used to partition the data in the table. These attributes can be specific to the actual data, the location of the data, or a combination of both the data and the location.
A parameter attribute that is specific to a location is referred to as a location parameter. You would use a location parameter if you require access to the table from a number of different TIBCO Object Service Broker nodes.
Example of Data Parameterization
There are many employees submitting expenses to a company and it is important to know when individual expenses are processed. In a case such as this, you could define a parameterized expense table using employee number and processing date as the parameters, for example, EXPENSES(empno, procdate).
When the data is accessed, you need to reference only the instance of the table that is specific to your requirements. For example, in a rule, to get the first expense for employee number 79912 for the date 2000-03-15, you would use the statement: GET EXPENSES(77912, ’2000-03-15’);
If required, you can access all the instances of the table by defining a parameterized (PRM) table on the base table. Refer to Defining a Parameter Value (PRM) Table for more information.
Example of Location Parameterization
A company stores data on one node and want access to the data from other nodes. For example, all the information regarding exchange rates is stored at a central location and employee expenses are stored at the location where each employee works. In this case, the location of a rates table and its data can be specified through the use of a location parameter and it is possible that the expenses table does not require a location parameter.
Option 2: Using Minimal Definition
A minimal definition is a table definition that consists of only a table name and a location parameter. It is used in environments where the same data is accessed from a number of different nodes. The minimal definition points to the full definition and data located on a node remote to where the initial access is being made to the data.
Option 3: Using Non-persistent Data
Often, when building applications, a particular view of data is required that can be obtained from an already existing data source. Because the real data already exists, less maintenance and storage overhead is incurred if you can make use of non-persistent data in your applications.
Table Types that Use Non-persistent Data
The following table types use non-persistent data:
Refer to Defining a Calculation (CLC) Table for information on defining calculation (CLC), parameter value (PRM), Execution Environment (EES), session (SES), and temporary (TEM) tables.
Example of Using Non-persistent Data
The data required for a parameter value (PRM) table, which holds the values of the data parameters of a parameterized table, can be obtained from the data already stored for the parameterized table. You do not need to add additional data to the data store to be able to use these values. However, it is possible that you require this specialized view of data to meet the requirements of your application.
Option 4: Using Global Fields
A global field is a field defined by an application administrator to be used across applications. The definition of the field and the help associated with it are stored in the @GLOBALFIELDS table. A link to the table can be made when you are defining the fields of your tables. Your administrator determines your site’s global fields implementation. Refer to Selecting Global Fields for more information.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved