Klaim-DB: A Modeling Language for Distributed Database Applications

Abstract

Abstract. We present the modelling language, Klaim-DB, for distributed database applications. Klaim-DB borrows the distributed nets of the coordination language Klaim but essentially re-incarnates the tuple spaces of Klaim as databases, and provides high-level language abstractions for the access and manipulation of structured data, with integrity and atomicity considerations. We present the formal semantics of Klaim-DB and illustrate the use of the language in a scenario where the sales from different branches of a chain of department stores are aggregated from their local databases. It can be seen that raising the abstraction level and encapsulating integrity checks (concerning the schema of tables, etc.) in the language primitives for database operations benefit the modelling task considerably.

A Coordination Language for Databases

“…Pattern matching and predicates. Our preliminary work [24] considered templates featuring both formal and actual fields and was in line with Klaim templates and the database query language QBE (Query by Example [25]). In the present work templates are restricted to formal fields only, since the combined power of pattern matching with such templates and predicates provides a more powerful mechanism with respect to the bare pattern matching used, for instance, in Linda and Klaim variants (e.g.…”

“…Allocation environments are needed at each physical site to record which logical localities are locally mapped to which physical ones. Compared to the conference version ( [24]) of this paper, we have replaced this two-layer structure with a single notion of "locality", to be able to focus on the exposition of the semantics and typing of database management constructs and primitives. Recovering this missing mechanism would not create any technical difficulties for the development.…”

“…in the headers of the tables in Figure 2 and Figure 3. These field names were part of the schemas in the conference version [24], and getting rid of them in the current development is a deliberate choice -all the operations on schemas can be realized positionally, and the existence of field names in the schemas would be purely symbolic.…”