O
            <sub>2</sub>
            an object-oriented data model

Lécluse, Christophe; Richard, Philippe; Vélez, Fernando

doi:10.1145/101620.101635

Cited by 15 publications

(8 citation statements)

References 2 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Object identifiers are assumed to be known only to the system, and are associated with objects throughout their lifetimes. (Typically, object identifiers are implemented as pointers (as in the OID's of [15]) although we impose no restrictions on their implementation here.) Two objects with the same object identifier are indistinguishable, even via mutation, and hence are referred to as identical.…”

Section: The Role Of User-defined Equalities In Setsmentioning

confidence: 99%

To Form a More Perfect Union (Intersection, Difference)

Cherniack

Zdonik

Nodine

1995

Electronic Workshops in Computing

View full text Add to dashboard Cite

The AQUA [16] query algebra allows user-defined equivalence relations as arguments to query operators that generalize standard set operations. These predicates determine what objects are included in the query result, and the duplicates that must be removed.While an expressive enhancement, the use of arbitrary equivalence relations to decide set membership can result in sets with counterintuitive behavior, and therefore can make queries return unreasonable results. In this paper, we show that equality predicates assume two roles with respect to sets. Distinguishers differentiate between set members and implicitly give meaning to standard set properties such as set equality. Constructors determine which object from input sets contribute to the query result. The requirements of distinguishers and constructors differ. AQUA's set operators are problematic because they use constructors where distinguishers are required. We propose alternatives to AQUA's set operators that address this limitation.

show abstract

Section: The Role Of User-defined Equalities In Setsmentioning

confidence: 99%

To Form a More Perfect Union (Intersection, Difference)

Cherniack

Zdonik

Nodine

1995

Electronic Workshops in Computing

View full text Add to dashboard Cite

show abstract

“…Swizzling might also benefit execution of compiled queries in object-oriented databases (OODBs), distinguished from traditional databases in that they manage objects having identity, etc. OODBs described in the literature include Exodus [23], DAMOKLES [24], CACTIS [25], VBase [26], Gemstone [19,27], O 2 [28,29], Orion [30], and Iris [31]. OODBs generally include a data manipulation language; such a language may be classified as a DBPL if it is rich enough in programming constructs.…”

Section: Related Workmentioning

confidence: 99%

Working with persistent objects: to swizzle or not to swizzle

Moss

1992

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

Pointer swizzling 3 is the conversion of database objects between an external form (object identifiers) and an internal form (direct memory pointers). Swizzling is used in some object-oriented databases, persistent object stores, and persistent and database programming language implementations to speed manipulation of memory resident data. Here we describe a simplifying model of application behavior, revealing those aspects where swizzling is most relevant in both benefits and costs. The model has a number of parameters, which we have measured for a particular instance of the Mneme persistent object store, varying the swizzling technique used. The results confirm most of the intuitive, qualitative tradeoffs, with the quantitative data showing that some performance differences between schemes are smaller than might be expected. However, there are some interesting effects that run counter to naive intuition, most of which we explain using deeper analysis of the algorithms and data structures.

show abstract

“…There are at least two problems with the relational model when used for more involved applications [10]: users must introduce properties of objects to serve as their means of reference, and all relationships between objects must be expressed indirectly in terms of these properties. Virtually all semantic or object-oriented data models overcome these problems by assuming that objects have an identity separate from any of their parts, and by allowing users to define complex object types in which part values may be any other objects [1,2,11,14,16]. A more general language of functional constraints for a data model supporting the definition of such complex object types was considered in [20].…”

Section: Introductionmentioning

confidence: 99%

“…each path function in Z has a form pf 1 •pf 2 such that v.pf 1 is an accepting state,11 and (3) v.pf is in V and is a non-accepting state, then change v.pf into an accepting state and remove all proper descendants and their incident arcs.…”

mentioning

confidence: 99%

Implication Problems for Functional Constraints on Databases Supporting Complex Objects

Ito

Weddell

1995

Journal of Computer and System Sciences

View full text Add to dashboard Cite

Virtually all semantic or object-oriented data models assume objects have an identity separate from any of their parts, and allow users to define complex object types in which part values may be any other objects. In [20], a more general form of functional dependency is proposed for such models in which component attributes may correspond to descriptions of property paths, called path functional dependencies (PFDs). The main contribution of the reference is a sound and complete axiomatization for PFDs when databases may be infinite. However, a number of issues were left open which are resolved in this paper. We first prove that the same axiomatization remains complete if PFDs are permitted empty left-hand sides, but that this is not true if logical consequence is defined with respect to finite databases. We then prove that the implication problem for arbitrary PFDs is decidable. The proof suggests a means of characterizing an important function closure which is then used to derive an effective procedure for constructing a deterministic finite state automation representing the closure. The procedure is further refined to efficient polynomial time algorithms for the implication problem for cases in which antecedent PFDs are a form of complex key constraint.

show abstract

O ₂ an object-oriented data model

Cited by 15 publications

References 2 publications

To Form a More Perfect Union (Intersection, Difference)

To Form a More Perfect Union (Intersection, Difference)

Working with persistent objects: to swizzle or not to swizzle

Implication Problems for Functional Constraints on Databases Supporting Complex Objects

Contact Info

Product

Resources

About

O 2 an object-oriented data model

Cited by 15 publications

References 2 publications

To Form a More Perfect Union (Intersection, Difference)

To Form a More Perfect Union (Intersection, Difference)

Working with persistent objects: to swizzle or not to swizzle

Implication Problems for Functional Constraints on Databases Supporting Complex Objects

Contact Info

Product

Resources

About

O ₂ an object-oriented data model