| M. Carey, D. DeWitt, and S. Vandenberg. A data model and query language for EXODUS. In Proc. of the ACM SIGMOD Conf. on Management of Data, pages 413--423, 1988. 37 |
....A s ti l A l=i j=n Here s ti denotes thai type s has to be identical to type ti 1 or a subtype thereof. 3 The Query Language and the Term Expressions 3. 1 The Query Language For our object model we developed a QUEL like query language along the lines of the EXCESS object query lan guage [3]. Let Xi be variables, T set typed expressions or type names (which represent the types extension) and S a selection predicate. Then, a query has the following form: range X: T, X, T, retrieve Xi where S Of course, the selection predicate S may itself contain retrieve statement. Example ....
M. J. Carey, D. J. DeWitt, and S. L. Vandenberg. A data model and query language for EXODUS. In Proc. of the ACM SIGMOD Conf. on Managemenl of Data, pages 413-423, Chicago, II., Jun 1988.
....of large amounts of data with complex structures. However, such capabilities are not directly supported by the existing database systems. In the past decade, various advanced data models such as nested relational and complex object models [1, 3, 9, 14, 19, 28, 31, 32] and object oriented models [5, 11, 15, 17, 18] were developed to support the storage of large amounts of data with complex structures. On the other hand, a lot of interests arose in the deductive database approach which integrates the logic programming and relational database techniques and provides more powerful query language to support ....
M. Carey, D. DeWitt, and S. Vanderberg. A Data Model and Query Language for EXODUS. In Proceedings of the ACMSIGMOD International Conference on Management of Data, pages 413--423, Chicago, Illinois, 1988.
....These advanced applications differ from conventional (business) applications in a number of important aspects including data modeling and processing, concurrency control and recovery mechanisms, as well as access methods and storage structures. Most of the design and implementation approaches [5,6,8,25,26,28,36,41] refer to some kind of object orientation and extensibility. In these cases, the overall uniting characteristic is adequate support for complex objects. This is accomplished in different ways starting from only a few selected extensions of the relational model and leading up to the integration and ....
.... (e.g. path expressions in OPAL [33] By now a lot of research focuses on full fledged query languages for object oriented database models [22, 44] Seen from a more general point of view the upcoming object oriented query languages exploit facilities to query along predefined relationships (in [6] called functional join) as well as to use traditional value based relational join capabilities. The functional join facility resembles the molecule building concept of MAD, and the general relational join capability is also available in MAD MQL. Therefore, there seems to be on one hand a ....
[Article contains additional citation context not shown here]
M.J. Carey, D. DeWitt, and S. Vandenberg, A Data Model and Query Language for EXODUS, in: Proc. ACM SIGMOD Int. Conf. on Management of Data, Chicago, (1988) 413-423.
....is to extend objectoriented programming languages with DBMS features such as persistence and a query facility. The resulting systems are typically a merger between object oriented and relational systems. Out of this approach there has emerged extensions to C (e.g. ObjectStore [21] and EXODUS [7]) and SmallTalk (e.g. GemStone [5] among others. The second approach is to develop a language independent object model and consistently extend it with DBMS features. TIGUKAT follows the second approach along with ORION [4] O 2 [3] and IRIS [11] TIGUKAT adopts the functional behavioral ....
....(CASCON) pages 595 611, October 1993. 2 a database. There have been programming language extensions (GemStone OPAL [5] O 2 O 2 C [10] SQL like query languages with object oriented extensions (IRIS OSQL [16] ORION SQL like [18] O 2 RELOOP [8] and extensions to QUEL (EXODUS Excess [7]) TIGUKAT incorporates a complete SQL like user language called TQL (TIGUKAT Query Language) an object definition language called TDL (TIGUKAT Definition Language) and a control language called TCL (TIGUKAT Control Language) An identifying characteristic of our language is that TQL is proven ....
M. Carey, D.J. DeWitt, and S.L. Vandenberg. A Data Model and Query Language for EXODUS. In Proc. ACM SIGMOD Int. Conf. on Management of Data, pages 413--423, September 1988.
....bear in a research environment) in particular when only a small fraction of the system components is of a major research interest. When the project started, we also considered to use extensible database management systems. However, the data model and query language of Exodus (called Extra Excess) [8] have no longer been available back then, and systems such as Open OODB [73] and Shore [11] have not yet been available when the SAMOS implementation started. We therefore decided to follow a layered approach, where we tried to add active functionality on top of a passive system. By doing this, ....
M.J. Carey, D.J. DeWitt, S.L. Vandenberg. A Data Model and Query Language for EXODUS. Proc. ACM SIGMOD Int'l Conf. on Management of Data, Chicago, Illinois, June 1988.
....be able to request the names of salespersons with April quotas over 5000 as follows: select name from SALESPERSON where quota[4] 5000 Consequently, the query language must be extended with syntax for addressing into arrays. Prototype syntax for a variety of type constructors is contained in [CARE88]. 7 The utility of these type constructors is well understood by DBMS clients who have data to store with a richer structure. Moreover, such type constructors will also make it easier to implement the persistent programming languages discussed in Proposition 3.2. Furthermore, as time unfolds it ....
Carey, M., et. al., "A Data Model and Query Language for EXODUS," Proc. 1988 ACM-SIGMOD Conference on Management of Data, Chicago, Ill., June 1988.
.... just a vehicle for optimisation as in [30,19] or a notation for studying the theoretical foundation of query languages as in [7,17] The design criteria adopted are thoroughly discussed in [15] A comparison of object comprehensions with ONTOS SQL [29] OSQL [24] O 2 SQL [3] ORION [21] EXCESS [8], OQL[C ] 6] CQL [16] and XSQL [20] can be found in [12] 3.2 Object Comprehensions Q0. Return names of staff earning less than 20000. set[ s StaffMembers; s.salary 20000 s.name ] 5 An example of an object comprehension query is given above. The result of evaluating this query ....
M.J. Carey, D.J. DeWitt, and S.L. Vandenberg. A Data Model and Query Language for EXODUS. In Proceedings of the ACM SIGMOD International Conference on Management of Data, pages 413--422. ACM Press, 1988.
....As mentioned earlier, the core of dooD (according to the author of the present note) is the introduction of declarative languages in objectoriented systems. Several declarative query languages for object oriented database management systems have already been proposed in the last few years (e.g. [11, 14, 21]) A survey of that topic can be found in [26] Most proposals consisted in relational language extensions, often extensions of relational algebra or of SQL. However, it seems now clear that object orientation requires to consider entirely new languages and new techniques for compiling and ....
M. Carey, D. DeWitt, and S. Vandenberg. A data model and query language for exodus. In Proc. SIGMOD, Chicago, Illinois, 1988.
....loop evaluation which may be very inefficient. Hence, the second phase unnests nested algebraic expressions to allow for more efficient evaluation. 1 Introduction Many declarative query languages for object oriented database management systems have been proposed in the last few years (e.g. [3, 5, 2, 18, 14]) To express complex conditions, access nested structure, or produce nested results, an essential feature found in these languages is the nesting of queries, i.e. the embedding of a query into another query. The optimization of object oriented (oo) queries has been intensively studied using ....
....the algebra. The algebraic equivalences used to unnest nested algebraic expressions are presented in Section 5 and applied to some representative nested queries. Section 6 concludes the paper. 2 Preliminaries The data model we are working on is similar to the O 2 [9] GOM [14] or Exodus [5] model. It features objects that have an identity, that are manipulated through user defined methods, whose structures are complex and that belong to classes that may be refined into subclasses. Each class has an extent which is a set containing all the objects belonging to the class. The model ....
M. Carey, D. DeWitt, and S. Vandenberg. A data model and query language for EXODUS. In Proc. of the ACM SIGMOD Conf. on Management of Data, pages 413--423, 1988.
....easy and exhaustive factorization of duplicated subqueries, and (iii) that supports heuristics in order to reduce the optimization rewriting phase. 1 Introduction Many declarative query languages for object oriented database management systems have been proposed in the last few years (e.g. [4, 5, 9]) Currently, a very serious concern is their optimization. Interesting techniques have been imported from other environments or developed for this context. However, although complementary, these techniques are often supported by distinct formalisms. The implementation of a query optimizer is thus ....
....and respect the encapsulation and identity principles. A concrete type only defines a structure. It may be named or not. Its instances are called values and know neither encapsulation nor identity. A concrete type does not have an extent. Concrete type can also be found in the Exodus data model [9]. The next figure presents the classes of a partial toy schema for a travel agency database. We comment it briefly. In the representation, concrete type names are in lowercase (e.g. activities ) while class names are capitalized (e.g. Country ) An object of class Country has two atomic ....
[Article contains additional citation context not shown here]
M. Carey, D. DeWitt, and S. Vandenberg. A Data Model and Query Language for EXODUS. In Proc. SIGMOD, Chicago, Illinois, USA, 1988.
.... data [29, 6] The lack of query languages likes those available in the relational systems has been criticized as a major drawback of the object oriented approach [35, 4] Consequently, recent research on OODB s has emphasized the importance and the design of high level declarative query languages [9, 13, 2, 5, 23, 19]. Most, if not all, of the second generation commercial OODB s provide or will provide some form of high level declarative query languages [31, 15, 30, 24, 25, 26] In an OODB, classes are named collections of similar objects. A class C could be refined into subclasses; that is, a subclass is a ....
Carey, M.J., DeWitt, D.J. and Vandenberg, S.L., "A Data Model and Query Language for EXODUS," Proceedings of the ACM SIGMOD , Chicago, 1988, pp. 413-423.
....Design data encompasses data for describing entities modelled by the Computer Aided Design applications. Design data describes static and dynamic design object properties. While the constructs for description of static object structure have been studied in many object oriented data models [5, 3], functional database models [11, 6] and others [1, 4, 8, 2] there has been, to our knowledge, little attention paid to the dynamic properties of objects. By the dynamic object properties we mean the way an object reacts on specified messages and how the change of its state influences the states ....
M.J. Carey, D.J. DeWitt, S.L. Vandenberg, A Data Model and Query Language for EXODUS, ACM SIGMOD 1988
.... and it can be extended through the addition of ADT functions and operators (written in E) and procedures and functions for manipulating EXTRA schema types (written in EXCESS) This section of the paper presents an overview of the key features of EXTRA and EXCESS; more details can be found in [Care88]. 6.1. The EXTRA Data Model An EXTRA database is a collection of named persistent objects of any type that can be defined using the EXTRA type system. EXTRA separates the notions of type and instance. Thus, users can collect related objects together in semantically meaningful sets and arrays, ....
....procedures are invoked in a manner consistent with the EXCESS syntax for performing updates. Procedures differ from functions in that functions return a value and have no side effects, while procedures usually have side effects and return no value. Further details and examples are presented in [Care88]. 6.3. The EXTRA EXCESS System Architecture The EXTRA EXCESS environment will consist of a frontend process and a backend process, as illustrated in Figure 7 (which is essentially an EXTRA EXCESS specific version of Figure 1) The frontend process parses a query, converts it to an optimizable ....
Carey, M., DeWitt, D., and Vandenberg, S., "A Data Model and Query Language for EXODUS," Proc. of the 1988 SIGMOD Conf., Chicago, IL, June 1988.
No context found.
M. Carey, D. DeWitt, and S. Vandenberg. A data model and query language for EXODUS. In Proc. of the ACM SIGMOD Conf. on Management of Data, pages 413--423, 1988. 37
No context found.
M.J. Carey, D.J. DeWitt and S.L. Vandenberg. A data model and query language for EXODUS. Proceedings of the ACM SIGMOD Conference on Management of Data, pp. 413-423 (1988).
No context found.
M. J. Carey, D. J. DeWitt, and S. L. Vandenberg. A Data Model and Query Language for EXODUS. In ACM SIGMOD Int. Conf. on Management of Data, page 413423, 1988.
No context found.
M.J. Carey, D.J. DeWitt and S.L. Vandenberg, \A Data Model and a Query Language for EXODUS," in Proceedings of ACM-SIGMOD Conference on Management of Data, Chicago, 1988, pp. 413-423.
No context found.
M.J. Carey, D.J. DeWitt and S.L. Vandenberg, \A Data Model and a Query Language for EXODUS," Proceedings of ACM-SIGMOD Conference on Management of Data, Chicago, pp. 413-423, May 1988.
No context found.
M.J. Carey, D.J. DeWitt, S.L. Vandenberg, A Data Model and Query Language for EXODUS, Proc. of the ACM SIGMOD Conference on the Management of Data, 413-423, (1988).
No context found.
M.J. Carey, D.J. DeWitt, S.L. Vandenberg, A Data Model and Query Language for EXODUS, Proceedings of the ACM SIGMOD Conference on Management of Data, 413-423 (1988).
No context found.
M. J. Carey, D. J. DeWitt, and S. L. Vandenberg. A data model and query language for EXODUS. In Proc. of the ACM SIGMOD Conf. on Management of Data, pages 413--423, Chicago, Il., Jun 1988.
No context found.
M. Carey, D. DeWitt, and S. Vandenberg. A data model and query language for EXODUS. In Proc. of the ACM SIGMOD Conf. on Management of Data, pages 413--423, 1988. 37
No context found.
M.J. Carey, D.J. DeWitt, and S.L. Vandenberg. A Data Model and Query Language for EXODUS. In Proc. ACM SIGMOD Conference, pp. 413--423, 1988.
No context found.
M. J. Carey, D. J. DeWitt and Scott L. Vandenberg, `A data model and query language for EXODUS', Proc. 1988 ACM SIGMOD International Conference on Management of Data, June 1988, pp. 413--423.
No context found.
M. J. Carey, D. J. DeWitt, and S. L. Vandenberg. A data model and query language for EXODUS. In Proc. of SIGMOD International Conferencee on Management of Data, pages 413-423, 1988.
First 50 documents Next 50
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC