A DBMS prototype to support extended NF2 relations: an integrated view on flat tables and hierarchies

Dadam, Peter; Kuespert, K.; Andersen, F.; Blanken, Henk; Erbe, Rossin

doi:10.1145/16856.16889

Cited by 126 publications

(19 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Access to collections of objects is provided via built in procedure calls to the storage manager. 7 Related Work…”

Section: Storage Managermentioning

confidence: 99%

“…This section presents some work closely related to Triton. Like Triton, the Advanced Information Management Prototype (AIM-P) [7], is also intended to be the database implementation "backend" for design application tools and uses the nested relational data model to represent the underlying structure of the database. However, AIM-P's physical storage structure differs from Triton's in that Triton maps relation definitions into a programming language, while AIM-P uses a tree structure to hold the same information.…”

Section: Storage Managermentioning

confidence: 99%

See 1 more Smart Citation

The design of the Triton nested relational database system

1991

View full text Add to dashboard Cite

Unique database requirements of applications such as computer-aided design (CAD), computer-aided software engineering (CASE), and office information systems (OIS) have driven the development of new data models and database systems based on these new models. In particular, the goal of these new database systems is to exploit the advantages of complex data models that are more efficient (in terms of time and space) than their relational counterparts.In this paper, we describe the design and implementation of the Triton nested relational database system, a prototype system based on the nested relational data model. Triton is intended to be used as the backend storage and access component of the aforementioned applications.This paper describes the architecture of the Triton system, and compares the performance of the nested relational model versus the relational model using Triton. In addition, this paper evaluates the EXODUS extensible database toolkit used in the development of the Triton system including key features of the persistent programming language E and the EXODUS storage manager. IntroductionIn recent years, database research has focused on the development of database systems to support non-standard applications, such as computer-aided design (CAD), computer-aided software engineering (CASE), and office information systems (OIS). Requirements in these new application areas have driven the development of new data models and database systems based on these new models to efficiently manage large volumes of non-standard data (such as textural or pictoral information). This paper presents the Triton nested relational database system [11,17], a prototype database intended to be used as the backend storage component for non-standard applications. The Triton system is based on an extension of the relational model [5], called the nested relational model [20], which allows a hierarchical representation of complex objects. There were three goals to our research: 1. To implement a DBMS prototype (Triton) to process data within the context of the nested relational data model using the tools provMed by the EXODUS extensible database toolkit [.i], 2. To use Triton 'to evaluate the capability of the nested relational model versus tile relat.ional model, and 3. To evaluate the effectiveness of the EXODUS toolkit in the development of the Triton system.We begin in Section 2 by discussing some background information on the nested relational data model and the EXODUS extensible database toolkit. Section 3 gives an overview of the Triton system I)y describing the components that make up its design. In Section 4, we demonstrate query processing withi, Triton through the use of an example. A preliminary discussion of the advantages of the nested relational data model versus the relational data model using Triton is presented in Section 5. Section 6 highlight.s our evaluation of the EXODUS toolkit in the development of Triton. Section 7 presents some relat.ed work in the realm of nested relational database implementations. Final...

show abstract

“…Access to collections of objects is provided via built in procedure calls to the storage manager. 7 Related Work…”

Section: Storage Managermentioning

confidence: 99%

Section: Storage Managermentioning

confidence: 99%

The design of the Triton nested relational database system

1991

View full text Add to dashboard Cite

show abstract

“…In addition, a different kind of attempts to attain a compromise solution is to extend relational databases with new features, such as clustering of composite objects, by which the concatenated foreign keys of ancestor paths are stored in a primary key (see [22,33,38] for detailed description). Another extension to relational system is nested relations (or NF 2 relations, see, e.g., [16]). Although it can be used to represent composite objects without sacrificing the relational theory, it suffers from the problem that subrelations cannot be shared.…”

Section: Introductionmentioning

confidence: 99%

On the transitive closure representation and adjustable compression

Chen

Cooke

2006

Proceedings of the 2006 ACM Symposium on Applied Computing

View full text Add to dashboard Cite

A composite object represented as a directed graph (digraph for short) is an important data structure that requires efficient support in CAD/CAM, CASE, office systems, software management, web databases, and document databases. It is cumbersome to handle such objects in relational database systems when they involve ancestor-descendant relationships (or say, recursive relationships). In this paper, we present a new encoding method to label a digraph, which reduces the footprints of all previous strategies. This method is based on a tree labeling method and the concept of branchings that are used in graph theory for finding the shortest connection networks. A branching is a subgraph of a given digraph that is in fact a forest, but covers all the nodes of the graph. On the one hand, the proposed encoding scheme achieves the smallest space requirements among all previously published strategies for recognizing recursive relationships. On the other hand, it leads to a new algorithm for computing transitive closures for DAGs (directed acyclic graph) in O(e⋅b) time and O(n⋅b) space, where n represents the number of the nodes of a DAG, e the numbers of the edges, and b the DAG's breadth.The method can also be extended to graphs containing cycles. Especially, based on this encoding method, a multi-level compression is developed, by means of which the space for the representation of a transitive closure can be reduced to O((b/d k )⋅n), where k is the number of compression levels and d is the average outdegree of the nodes.

show abstract

“…In order to model complex objects more naturally the nested relational model[Abit89, Dada86,Colb89,Thorn86] relaxed the first normal form requirement of the relational model. Attributes of a nested relation can have non-atolnic values, and their values can be relations.…”

Section: Introductionmentioning

confidence: 99%

“…Many query languages such as HDBL [Dada86], Excess[Care88] and Reloop [Clue89] can access multi-level nested sets by defining tuple variables or range variables in FROM clause. Therefore, in order to query over multi-level nested sets, users must know the nesting informations of objects as well as the structures of objects, and the formulation of queries is dependent on nesting levels of complex objects.…”

Section: Introductionmentioning

confidence: 99%

A formalization of a query language for complex objects

Kim

Lee

1991

Proceedings of the 19th Annual Conference on Computer Science - CSC '91

View full text Add to dashboard Cite

In this paper, we present forntal descriptions of a complex object model and a query language for complex objects, hi the query language, the .orion of path expressions is used as the basis c!f qtteo:ing complex objects and other database operatio~ts are cooperated for associative access :o comt)lex objects. Because of the recursive lzature off complex objects it is consMered beneJ?'cial to define recursively path expressions a~zd operations. Especially multi-level nested sets are ve~ 3, common components of complex objects aml these cause queries to be complicated. llowever, it is desirable for users to manipulate m.lti-level nested sels without knowing the nesting iJ!formations of complex objects. Our query lang.age supports such capability called the nesting level independence.

show abstract

A DBMS prototype to support extended NF2 relations: an integrated view on flat tables and hierarchies

Cited by 126 publications

References 12 publications

The design of the Triton nested relational database system

The design of the Triton nested relational database system

On the transitive closure representation and adjustable compression

A formalization of a query language for complex objects

Contact Info

Product

Resources

About