Distributed Query Optimization
- PDF / 11,481,671 Bytes
- 408 Pages / 547.087 x 737.008 pts Page_size
- 39 Downloads / 222 Views
Daplex T ORE R ISCH Uppsala University, Uppsala, Sweden
Definition Daplex is a query language based on a functional data model [1] with the same name. The Daplex data model represents data in terms of entities and functions. The Daplex data model is close to the entity-relationship (ER) model with the difference that relationships between entities in Daplex have a logical direction, whereas ER relationships are directionless. Unlike ER entities, relationships, and properties are all represented as functions in Daplex. Also, entity types are defined as functions without arguments returning sets of a builtin type ENTITY. The entity types are organized in a type/subtype hierarchy. Functions represent properties of entities and relationships among entities. Functions also represent derived information. Functions may be set-valued and are invertible. The database is represented as tabulated function extents. Database updates change the function extents. The Daplex query language has been very influential for many other query languages, both relational, functional, and object oriented. Queries are expressed declaratively in an iterative fashion over sets similar to the FLWR semantics of the XQuery language. Daplex queries cannot return entities but a value returned from a query must always be a literal. The query language further includes schema (function) definition statements, update statements, constraints, etc.
#
2009 Springer ScienceþBusiness Media, LLC
Key Points Daplex functions are defined using a DECLARE statement, for example: DECLARE name(Student) = STRING Where ‘‘Student’’ is a user defined entity type and ‘‘STRING’’ is a built-in type. Set valued functions are declared by a ‘‘ = > >’’ notation, e.g., DECLARE course(Student) = > > Course Entity types are functions returning the built-in type ENTITY, for example: DECLARE Person() = > > ENTITY Inheritance among entity types is defined by defining entities as functions returning supertypes, for example: DECLARE Student() = > > Person Functions may be overloaded on different entity types. Queries in Daplex are expressed using a FOR EACH – SUCH THAT – PRINT fashion similar to the FLWR semantics of XQuery. For example: FOR EACH X IN Employee SUCH THAT Salary(X) > Salary(Manager (X)) PRINT Name(X) The PRINT statement is here not regarded as a side effect but rather as defining the result set from the query. Derived functions are defined though the DEFINE statement, e.g., DEFINE Course(Student) = > Course SUCH THAT FOR SOME Enrollment Stud#(Student) = Stud#(Enrollment) AND Course#(Enrollment) = Course#(Course) Daplex was first implemented in the Multibase system [2]. There, it was used as a multi-database query language to query data from several databases. The P/FDM [1] data model and query language is close to Daplex. The query languages OSQL and AmosQL are also based on Daplex. These languages extend Daplex with object identifiers (OIDs) to represent actual entities and thus queries can there return entities as OIDs.
548
D
DAS
Cross-references ▶ AmosQL ▶ Fu
Data Loading...
