Tuple Layer

Forces Driving the Design of the Tuple Layer

As Mapping Objects to Tables is treated in a separate fragment of the language, the remaining field of decisions for the tuple layer is the design of the query interface - The dominant forces here are Ease-of-use versus power of the interface: Your interface should be easy to use. On the other hand the complexity of a database interface stems from its power. Hence, the interface of the databases encapsulation should be easy to use but still powerful enough for your project. In object/relational access layers you can live with moderate complexity as you have another layer upon your queries - your persistent objects. You should only be forced to use SQL database queries directly in very rare cases.


Local Roadmap

or_roadmap_tupleLayer.gif (12900 Byte)

Figure 9: Roadmap from Accessing Relational Databases [Kel+98a]. Merely all patterns are also found in object/relational access layers.

If you take a fully fledged relational access layer that can also be used as a surrogate for an object/relational access layer its interesting to see where the patterns used there are moving to in this language.

Pattern List

So the pattern that remains in the tuple layer is Physical Views which is also known as Query [Bra+96]. If you want real luxury, you can also add an additional layer of Logical Views to implement Cluster Read

-> on to Moving Attributes

-> up to the Contents Page