Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Physical Views of Logical Data

IP.com Disclosure Number: IPCOM000121569D
Original Publication Date: 1991-Sep-01
Included in the Prior Art Database: 2005-Apr-03
Document File: 5 page(s) / 233K

Publishing Venue

IBM

Related People

Larner, A: AUTHOR

Abstract

A number of data manipulations currently impossible in Relational Data Languages are made into expressible queries by this logic technique.

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

Physical Views of Logical Data

      A number of data manipulations currently impossible in
Relational Data Languages are made into expressible queries by this
logic technique.

      In current data base management systems the meaning of each
stored relation is expected to be informally recorded, e.g., as
commentary in the scheme (definition) of the relation.  The meaning
of each view is effectively given in the view definition.  To
implement physical views, it is necessary to allow schemes of
unstored foundational relations, with their informal definitions.
The physical views defined on these would have ordinary, though
unimplemented, view definitions that would convey their meanings.
For update of a physical view, or any operation on an unstored
foundational relation, it would be necessary to define an algorithm
to implement the required data manipulation.  For instance in the
later examples:  to update the "ancestor" view when the "parent" view
was updated, or to build the ancestor view (either directly or by
building the foundational relational) when required;  to update the
"period" view when the foundational "instant" view was updated, or to
(re)build the period view when required.  Although view definitions
are expressible in the relational data manipulation language, it is
not necessary that the required algorithms should be so expressible.

      It is conventional in Relational Data Base Theories to assume a
set of physical, or stored, data bases ("base relations"), and a
number of logical views defined on these physical data bases.  Such a
definition may be indirect, in the sense that a logical view is
defined on a logical view (which is defined on a logical view ...)
defined on one or more physical data bases.  Thus stored data is
regarded as foundational data:  in a relational system, the meaning
of each stored relation is assumed known, though formally undefined,
but the meaning of each view is defined on the meaning(s) of its
underlying stored relation(s). This disclosed technique distinguishes
between the concepts of foundational (formally undefined) relations
and stored relations.  It allows the meaning of a stored relation to
be defined on the meanings of underlying, formally undefined, and
nowhere stored relations permitting physical views of logical data.
Three exemplary problems are addressed in the remainder of this
article;  the representation of Bills of Material or ancestral
relationships, the handling of temporal data, also indistinguishables
and the Join Trap.
THE ANCESTRAL PROBLEM

      Given a relationship, such as "x is parent of y", say, P(x,y),
it is not (in general) possible to define the ancestor of that
relationship ("x is ancestor of y") in first-order logic, and
therefore it is not possible in a relational data language to define
a query, or a view, say, (x,y), of the relation P(x.y) such that Q is
the ancestor of P.  A "recursive definition" is easily forthcoming:
     ...