Browse Prior Art Database

Treating Data Transformations as Objects

IP.com Disclosure Number: IPCOM000109562D
Original Publication Date: 1992-Sep-01
Included in the Prior Art Database: 2005-Mar-24
Document File: 6 page(s) / 304K

Publishing Venue

IBM

Related People

Merrick, RA: AUTHOR [+2]

Abstract

This article proposes treating Transforms as objects instead of actions which gives the user flexibility in their use and enables the user interface to show graphically the inter-relationship and order of application of the transforms specified. Also, data transformation is achieved consistently with the rest of an object-oriented interface.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 28% of the total text.

Treating Data Transformations as Objects

       This article proposes treating Transforms as objects
instead of actions which gives the user flexibility in their use and
enables the user interface to show graphically the inter-relationship
and order of application of the transforms specified.  Also, data
transformation is achieved consistently with the rest of an
object-oriented interface.

      Treating each data transformation as a discrete object which is
pervasive and can be manipulated like any other object in the user
interface offers increased flexibility of function, and usability
benefits.  For example, the transform objects may contain other
transform objects, and levels of transform can be nested within other
levels.  By treating the transforms as objects, these containment and
nesting relationships can be achieved and shown very easily.  Once
defined, transformers, and groups of transformers, are transportable
(using direct manipulation and other techniques) across all objects
in the system.  So, for example, the data transformations applied to
the data used to produce a chart can easily be re-applied to the data
which is driving a business report.

      Traditionally, transformations applied to data are treated as
actions.  Reversing, or modifying a transform, or even the order in
which transforms are done, is difficult for the user and can be
ambiguous - is the new transform to be applied to the original data
or to the data resulting from the transform that is being reapplied?
Often the path through data transformation tools is tortuous.  There
are blurred relationships and overlaps between Schema, Query, and the
data handling (select rows, calculate percentages, summary analysis,
etc.)  surfaced, inconsistently by individual object handlers.  It is
an unforgiving, largely one-way path.  To change a simple selection
criterion, for example, alter a chart from showing salaries for
department 11 to the same chart for department 12, the user may have
to return to the Query which originally resulted in the data, change
that, save it, then re-run the chart with the new Query.

      The solution is to enable the user to access at least the
simple, one-table operations currently buried in a Query in a
consistent manner anywhere that data is used.  The derived table
produced by these operations should always be available for the user
to re-use as input to another object handler or task.

      Treating Transforms as objects instead of actions gives the
user flexibility in their use and enables the user interface to show
graphically the inter-relationship and order of application of the
transforms specified.  This includes the ability to display levels of
nesting of the transforms, like explicit brackets in a formula.
Also, data transformation is achieved consistently with the rest of
an object-oriented interface.

      Fig. 1 shows a sample data chain for an object handler which
accesses data tra...