Stack-Based Architecture (SBA) and

Stack-Based Query Language (SBQL)


Overview by Kazimierz Subieta (November 2008)

For more information see



General Overview of SBA/SBQL

SBA/SBQL in projects

Basic Topics of SBA/SBQL

Examples of SBQL queries

Conclusion: 10 unique qualities of SBA/SBQL

SBA/SBQL Sources


General Overview of SBA/SBQL


What is SBA?

The Stack-Based Architecture (SBA) is a formal methodology addressing object-oriented database query and programming languages. In SBA we reconstruct query languages’ concepts from the point of view of programming languages (PLs). The approach is motivated by our belief that there is no definite border line between querying and programming; thus there should be a universal theory that uniformly covers both aspects. SBA offers a unified and universal conceptual and semantic basis for queries and programs involving queries, including programming abstractions such as procedures, functions, classes, types, methods, views, etc.

Abstract implementation as a semantic specification method

SBA assumes a semantic specification method that is referred to as abstract implementation. It is a kind of operational semantics where one has to determine precisely on an abstract level all the data structures that participate in query/program processing and then to specify the semantics of all the languages’ operators in terms of actions on these structures. SBA introduces three such structures that are well-known in the specification of PLs: (1) an object store, (2) an environment stack, (3) a query result stack (thus the stack-based architecture). These structures are fundamental for precise semantic description of everything that may happen in database query/programming languages. In particular, classical query operators, such as selection, projection, joins and quantifiers, can be generally and precisely specified using the above three abstract structures, with no references to classical database theories such relational/object algebras or calculi.

What is SBQL?

SBA introduces a model query/programming language SBQL (Stack-Based Query Language). In our intention SBQL plays the same role as relational algebra for the relational model, but SBQL is incomparably more powerful. The power of SBQL concerns a wide spectrum of data structures that it is able to serve and complete algorithmic power of querying and manipulation capabilities. At the same time, SBQL is fully precise with respect to the specification of semantics. SBQL has been carefully designed from the pragmatic (practical) point of view. We were struggling severely with parasite syntactic sugar, redundant operators and semantic reefs (when human intuitive semantics does not match machine semantics). The pragmatic quality of SBQL is achieved by orthogonality of introduced data/object constructors, orthogonality of all the language constructs, object relativism, orthogonal persistence, typing safety, introducing all the classical and some new programming abstractions (procedures, functions, modules, types, classes, methods, views, etc.) and following commonly accepted programming languages’ principles.

SBA/SBQL database models

SBA and SBQL are neutral to database models. SBA covers all database models that we are aware of, starting from the relational model, through XML-oriented data model, RDF-oriented data model, up to sophisticated object-oriented models with static and dynamic inheritance, collections, associations, polymorphism, etc. Our fundamental assumption is that SBA and SBQL address data structures rather than data models. Once we determine how particular concepts in a data model are to be mapped as abstract data structures, we can propose a corresponding subset of SBQL that will be able to handle these structures with full algorithmic universality and precision. In this way we have shifted the discussion of query language to another level: we can talk about how particular features of data structures are to be served by SBQL rather than sticking to a concrete query language with a concrete data model. For instance, when we determine how XML files will be mapped as abstract data structures, we can propose SBQL to serve these structures. In this way we achieve a unique universality, flexibility and performance optimization potential. In particular, SBQL is the first and only query language that deals with dynamic object roles and dynamic inheritance. Moreover, powerful query optimization methods that are developed for SBQL are prepared to work with such advanced features.

SBA can be considered as a theoretical approach with a strong and complete bridge to practice. Because the development of SBA was preceded by several implementations of query languages, it can also be considered as a practical approach resulting in a consistent and universal theory. SBQL specification of semantics is fully independent from a particular implementation platform – it is expressed in terms of actions performed on an abstract representation of an object store and an abstract view on all the internal data structures that participate in query processing.

Query languages as programming languages

The design of modern and universal database PLs having querying capabilities requires methods and principles that are already acknowledged by the common practice of developing compilers and interpreters. Practically useful PLs deal with object-oriented notions (classes, methods, inheritance, etc.), procedures and functional procedures (including recursive ones), parameter passing methods, various control statements, binding strategies, scoping rules, modularization, strong typing, etc. They should follow software engineering principles such as orthogonality, modularity, minimality, universality, genericity, typing safety, and clean, precise semantics. SBA is an alternative to theoretical concepts emerging on the object-oriented wave, such as nested relational algebras, object algebras, object calculi, F-logic, comprehensions, structural recursion, monoid calculus, functional approaches, etc. Careful analysis of them and our implementation experience convinced us that all of them are limited and inadequate for this kind of query/programming languages that we intend to develop.

The SBA solution relies on adopting a run-time mechanism of PLs and introducing necessary improvements to it. The main syntactic decision is the unification of PL expressions and queries; queries remain the only kind of PL expressions. For instance, in SBA there is no conceptual difference between expressions such as 2+2 and (x+y)*z, and queries such as Employee where Salary = 1000 or (Employee where Salary = (x+y)*z).Name. All such expressions/queries can be used as arguments of imperative statements, as parameters of procedures, functions or methods and as a return from a functional procedure.

Naming, scoping, binding and the environment stack

Concerning semantics, we focus on the classical naming-scoping-binding paradigm. Each name occurring in a query is bound to run-time programming entities (persistent data, procedures, actual parameters of procedures, local procedure objects, etc.), according to the actual scope for the name. The common PLs’ approach that we follow in SBA is that the scopes are organized in an environmental stack with the “search from the top” rule. Some extensions to the structure of stacks used in PLs are necessary to accommodate the fact that in a database we have persistent and bulk data structures and the fact that the data is kept on a server machine, while the stack is kept on a client machine. Hence the stack contains references to data rather than data themselves (i.e., we separate the stack from a store of objects), and possibly multiple objects can be simultaneously bound to a name occurring in a query (for processing collections). The operational semantics (abstract implementation) of query operators, imperative programming constructs and procedures (functions, methods, views, etc.) is defined in terms of the three above mentioned abstract data structures: object store, environmental stack (ENVS) and query results stack (QRES).

SBQL functionalities

Because various object models introduce a lot of incompatible notions, SBA assumes a family of object store models which are enumerated AS0, AS1, AS2 and AS3[1]. The simplest is AS0, which covers relational, nested-relational and XML-oriented databases. AS0 assumes hierarchical objects with no limitations concerning the nesting of objects and collections. AS0 also covers pointer links (relationships) between objects. The AS1 store model extends AS0 by classes and static inheritance, the AS2 store model extends AS1 by object roles and dynamic inheritance, and the AS3 store model extends AS1 or AS2 by encapsulation. Clean, rigorous semantics of SBQL, supporting the principle of object relativism and full orthogonality of SBQL operators create a big potential for query optimization and for strong static type checking of SBQL queries and programs integrated with SBQL queries. Following these conceptual lines, SBQL is extended by imperative statements (programming options such as updating, inserting and deleting), programming abstractions (functions, procedures and methods), updateable object-oriented database views, and a lot of other options; some of them are so far unique for SBQL (in particular, fixed point equations, dynamic object roles, updateable views, overloading views, and others).


SBA/SBQL in projects


·         1989: NETUL – an expert system shell developed for Intra Video GmbH in West Berlin, Germany. Implementation of SBQL for the AS0 store model. The project is not continued.

·         1990: LOQIS - an advanced prototype implementation. Includes modules, elements of dynamic inheritance (AS2 store model), typed objects, transitive closures, recursive functions and methods, binding to C libraries and other features. The project is not continued.

·         2002: SBQL for XML DOM. XML files are mapped to the AS0 store model, then queried by SBQL. Results of queries are returned as XML files. At that time the most powerful XML querying tool. The project is not continued.

·         2003: YAOD – a prototype OODBMS. Client-server architecture with an advanced SBQL implemented for the AS0 store model. The project is not continued.

·         2004: European Project ICONS (commercialized). ICONS assumed an object-based database (no classes) on the top of a relational database. SBQL was implemented on the client side. A powerful query rewriting optimizer was also implemented. The project is not continued.

·         2004: SBQL prototype for Objectivity/DB. A student project aiming at enhancing the Objectivity/DB OODBMS with SBQL in the AS1 store model. The project is not continued.

·         2005: BPQL for OfficeObjects® Workflows (commercial). BPQL is a subset of SBQL embedded into XPDL, an XML process definition language. A very successful project resulting in incredible flexibility (change potential) of workflows implemented in Java+XPDL+BPQL.

·         2005: ODRA.NET (Object Database for Rapid Application development). An OODBMS prototype under .NET written in C#. The project is not continued.

·         2005 (pending) ODRA: ODRA.NET ported to Java for the AS3 store model, with all the functionalities of SBQL, imperative constructs and programming abstractions, classes, types, methods, inheritance, modules, recursive querying capabilities, query optimization by rewriting and by indices, distributed query processing, and many other advanced features.

·         2006 (pending) LoXiM – a client-server prototype OODBMS with SBQL, developed at the Warsaw University.

·         2006 (pending): European project eGov Bus. The project aims at integrating distributed resources being under control of various European governmental institutions. SBQL is to be used as an embedded QL for application programming in Java. Alternatively, SBQL can be a self-contained DBPL for application programming. SBQL updateable views will play the following roles: as mediators (adapting local resources to the global requirements), as integrators (fusing fragmented collections) and as customizers (adapting the data to the needs of end users).

·         2006 (pending): European project VIDE. VIDE aims at developing a visual programming language for the OMG MDA. We assume that OCL and other concepts related to Executable UML are to be implemented through SBA concepts, much more universal and consistent from the programming languages perspective. We hope that in this way we will be able to relax MDA from some skepticism and critique.

·         2008 (pending): Extended workflow. The project funded by Polish Ministry of Science and Higher Education aims at developing a new declarative workflow paradigm which is more close to PERT networks rather than to Petri nets. The project is implemented on top of ODRA, with SBQL as a declarative query/programming language.


Basic Topics of SBA/SBQL


  1. General architecture of query processing
  2. Abstract models of object stores
  3. Environment stack and query result stack
  4. Syntax, semantics and pragmatics of query/programming languages
  5. Algebraic and non-algebraic query operators
  6. Classes, methods and static inheritance in query languages
  7. Dynamic object roles and dynamic inheritance in query languages
  8. Processing irregular data structures (semi-structured data)
  9. Transitive closures and fixed-point equations in SBQL
  10. Extension of SBQL with imperative (updating) constructs
  11. Procedures, functions and methods in SBQL
  12. Parameter passing for procedures, functions and methods
  13. Encapsulation in SBQL
  14. Virtual updatable views in SBQL
  15. Classes, interfaces, types, schemas and metamodels
  16. Three-level architecture of object database applications
  17. Static (semi-) strong type checking of SBQL queries and programs
  18. Query optimization in SBQL
  19. Query processing and optimization in distributed systems
  20. Data-intense grids and P2P networks
  21. Aspect-oriented databases


1.      General architecture of query processing. In a basic variant it is a client-server architecture, where majority of query processing is performed on the client side. The architecture involves the following elements: integrated development environment (IDE) for preparing source SBQL programs, parser which generates a query syntax tree, and interpreter which recursively traverses a syntax tree producing the result of a query or of a program. The interpreter is implemented on the client side and involves an object store (on the client and on the server sides), an environment stack and a query result stack. For query optimization modules and for strong type checker the architecture involves a metabase, a static environment stack and a static query result stack. There are further elements of the architecture related to processing database views, transactions, distributed query processing, etc.

2.     Abstract models of object stores. To be fully implementation platform independent, SBA and SBQL introduces a database state and a local program state in the form of abstract (mathematical) concepts. The abstract form is sufficiently precise to express almost everything that may happen in real object-oriented database systems. For covering typical situations we introduce the store models AS0, AS1, AS2 and AS3. Less typical situations (for instance, supporting substitutability for collections in the AS1 model or dealing with sequences of objects) require extensions or amendments to these models. In the construction of abstract store models we follow the total internal identification principle (each database or program entity should possess a unique internal identifier, including atomic entities) and the object relativism principle (each object consists of objects and nothing else; atomic attributes are objects too; objects on any object hierarchy level have the same formal properties and are served by the same query constructs).

3.     Environment stack and query result stack. These concepts are fundamental for majority of programming languages. We describe their role in processing of queries and programming constructs based on queries. The domain of query results is precisely determined for the introduced store models. The stack-based machinery is carefully designed and expressed in abstract terms.

4.     Syntax, semantics and pragmatics of query/programming languages. SBQL semantics is driven by its abstract syntax, following the compositionality principle (semantics of a complex constructs is recursively expressed through semantics of its components). SBA/SBQL follow abstract and universal specification of semantics through the method of abstract implementation. Examples of SBQL show its pragmatic (practical) similarity and advantage in comparison to better-known query languages, such as SQL, OQL, XQuery and others.

5.     Algebraic and non-algebraic query operators – syntax and semantics. Algebraic operators do not use the environment stack and cover typical operators known from other languages, such as arithmetic and string comparisons and functions, set-oriented operators, aggregate functions, auxiliary naming operators, Boolean operators, etc. The essence of SBA/SBQL are non-algebraic operators, which semantics assumes operations on the environment stack. In general, non-algebraic operators cannot be expressed by any mathematically correct algebra. Non-algebraic SBQL operators include selection (where), projection/navigation and path expressions (dot), dependent join (join), existential and universal quantifiers, sorting (order by), iterator (for each) and several variants of transitive closures. It is quite surprising that these apparently different operators have the same semantic core based on the environment stack. This has a great meaning for implementation, documentation, learning, reasoning on properties of a query language, for strong typing and for developing query optimization methods.

6.     Classes, methods and static inheritance in query languages. The AS1 store model introduces classes and (multiple-) inheritance in the classical variant known from languages such as C++ and Java and modeling tools such as UML. It appears that this new feature requires rather obvious and relatively small extensions to SBQL defined for the AS0 store model. The changes concern only non-algebraic operators and behavior of the environment stack. Invocation of methods (that are the feature of the AS1 store model) can also be easily expressed through actions of the stack-based machine. New situation is caused by collections, which (in general) are in contradiction to substitutability and open-close (reuse), the basic principles of object-orientedness. Finding a solution to the problem requires some modification of the AS1 store model and of the SBQL semantics.

7.     Dynamic object roles and dynamic inheritance in query languages. Static inheritance assumed in the AS1 store model (and in majority of object-oriented models and tools) is insufficient for expressing precisely some situations that appear in conceptual modeling of data-intensive business environments. The most well-known problem of this kind concerns multiple-inheritance which leads to several anomalies, in particular, it may violate substitutability and open-close principles. Other problems concern multiple-aspect inheritance (known from UML), repeating inheritance, changing objects’ classes, aspect-oriented decomposition, temporal object properties, and others. Dynamic object roles assume that an object consists of sub-objects that are its roles; each role dynamically inherits properties of its super-role, in particular, of the entire object. Roles can be dynamically inserted and deleted from an object. As previously, this revolutionary feature requires rather obvious and relatively small extensions to SBQL defined for the AS0 and AS1 store models. The changes concern only non-algebraic operators and behavior of the environment stack. Dynamic object roles imply however some new features concerning strong typing and some new query/programming operators such as inserting/deleting a role into/from an object.

8.     Processing irregular data structures (semi-structured data). Recent technologies introduce a lot of irregularities to data structures, in particular, optional data, variants, null values, untyped properties and perhaps others. An example is XML files and related technologies. Irregular (semi-structured) data is an inherent feature of the AS0, AS1, AS2 and AS3 store models and can be processed by all SBQL operators. Some new quality of processing irregular data is caused by strong typing. While other approaches assume that strong typing of irregular data is impossible, we take a different point of view: semistructured data has to be typed by a semi-strong typing system. The system should discover as many typing errors as possible, despite the semi-structured nature of data. The semi-strong SBQL typing system is the first and unique among all the known current proposals concerning strong typing.

9.    Transitive closures and fixed-point equations in SBQL. There are some business processing tasks that may require recursive queries. Classical examples concern Bill-Of-Material (BOM) software, genealogical trees, various networks (water, electricity, road, telecommunication, airlines, etc.), metadata processing, and others. SBQL offers three methods of expressing recursive queries. The first one is well-known and is based on recursive procedures. The second one concerns transitive closures, which are the property of Oracle and DB2 systems. SBQL offers transitive closures in a much more universal, convenient and easy-to-use manner. The third possibility concerns fixed–point equations in SBQL. A similar option is offered by Datalog systems. While Datalog is presented as a stand-alone, self-contained programming system (which is probably the reason of its low popularity in the commercial domain), SBQL fixed-point equations capability is one of SBQL option, fully orthogonal to other options and to data models.

10. Extension of SBQL with imperative (updating) constructs. SBQL queries can be embedded within statements that can change the database or program state. Concerning this issue we follow state-of-the-art standards known from majority of programming languages. Typical imperative constructs are creating a new object, deleting an object, assigning new value to an object (updating) and inserting an object into another object. We also introduce typical control and loop statements such as if…then…else…, switch, while loops, for each iterators and others. Some peculiarities are implied by queries that may return collections; thus there are possibilities to generalize imperative constructs according to this new feature.

11. Procedures, functions and methods in SBQL. In classical programming languages these concepts (procedural abstractions) are accomplished by the stack-based machine and there is no essential difference concerning SBQL. All procedural abstractions of SBQL can be invoked from any procedural abstractions with no limitations and can be recursive.

12. Parameter passing for procedures, functions and methods. The stack-based machine is prepared to specify precisely various parameter passing methods, including variants of call-by-value, call-by-reference, strict-call-by-value, the method with parameter defaults, call-by-value-return, etc. SBQL deals with parameters being any queries; thus corresponding parameter passing methods are generalized to take collections into account.

13. Encapsulation in SBQL. As usual, encapsulation means that properties of objects, classes and modules are subdivided into public and private. We assume orthogonal encapsulation, where each kind of property (a method, an attribute, a pointer, etc.) can be public or private, depending on the decision of the designer or programmer. Encapsulation implies rather obvious changes to the stack-based machine and to the semantics of SBQL.

14. Virtual updatable views in SBQL. We have invented a new method that allows us to achieve the power of updateable views that has not been even considered so far in the database domain. Our method has some commonalities with instead of trigger views implemented in Oracle, SQL Server and DB2, but it is based on different principles, is much more powerful and efficient, and may address any object-oriented database model, including XML. In general, the method is based on overloading generic updating operations (create, delete, update, insert) acting on virtual objects by invocation of procedures that are written by the view definer. The procedures are the inherent part of the view definition. The procedures have full algorithmic power, thus there are no limitations concerning the mapping of view updates into updates of stored data. SBQL updatable views allow one to achieve full transparency of virtual objects: they cannot be distinguished from stored objects by any programming option. This feature is very important for distributed and heterogeneous databases. SBQL views can be used as mediators on top of local resources to convert them virtually to the required format, as integrators that fuse fragmented data from different sources, and as customizers that adopt the data to the needs of a particular end user application.

15. Classes, interfaces, types, schemas and metamodels. In SBA/SBQL we make an attempt to clarify these concepts by assigning pragmatic roles to them. Classes are source code units that contain implementation; after compilation they became special kind of database objects employed by the stack-based machine. Interfaces are external specifications of access to objects; they contain no implementation. Interfaces need not 1:1 match classes - one class may have zero or many interfaces and one interface can be defined for more than one class (due to views). Interfaces usually contain more information than types. Types are determined by interfaces, but types can also exist without interfaces. Types are intended as constraints on the construction and behavior of any program entities (in particular, modules, objects, values, links, procedures, etc.) and constraints on the query/programming context in which these entities can be used. Schemas are external (application programmer oriented) specifications of a database content and are inevitable pragmatic part of a query/programming languages. A metamodel is an internal representation of a schema; it is internally used by the database management system and externally for generic programming with reflection. The above concepts present a definitional knot (especially due to static and dynamic inheritance), having source code incarnation and internal representation.

16. Three-level architecture of object database applications. A classical architecture involves two levels: database server and application client. Following the ANSI/SPARC model, we strive to introduce more levels. On the first level there are database programmers who prepare the server-side database schema and implement (in SBQL + classical object-oriented languages) database classes together with methods. On the second level there are server-side administrative programmers who determine access privileges and external views for applications and application users. The external views are determined by virtual updateable views, which might accomplish sophisticated mappings between stored and virtual data and mappings between updating of virtual data and updating of stored data. Such mappings require programming in some View Definition Language based on SBQL. On the third layer there are client-side application programmers, who use interfaces to virtual views delivered by the second layer. The subdivision on these three layers could make business applications very flexible for development and maintenance. It qualifies programmers of business-oriented software to a few kinds with independent jobs and specializations. To a large extent, such an architecture is inevitable in distributed applications.

17.  Static (semi-) strong type checking of SBQL queries and programs. Because of new database models, new semantic properties of query languages and semi-structured data, all the known strong typing systems developed for programming languages became too limited and not flexible enough. We have developed a new strong typing theory and corresponding implementations for SBQL. We distinguish internal and external type systems. The internal type system reflects the behavior of the type checking mechanism, while the external type system is used by the programmer. A static strong type checking mechanism simulates run-time computations during compile time by reflecting the run-time semantics with the precision that is available at the compile time. Roles of the SBQL typing system are the following: compile-time type checking of query operators, imperative constructs, procedures, functions, methods, views and modules; user-friendly, context dependent reporting on type errors; resolving ambiguities with automatic type coercions, ellipses, dereferences, literals and binding irregular data structures; shifting type checks to run-time, if it is impossible to do them during compile time; restoring a type checking process after a type error, to discover more than one type error in one run; preparing information for query optimization by properly decorating a query syntax tree. The internal SBQL type system includes three basic data structures that are compile-time counterparts of run time structures: a metabase, a static environment stack and a static result stack. Static stacks process type signatures – typing counterparts of corresponding run time entities. Signatures are additionally associated with attributes, such as mutability, cardinality, collection kind, type name, multimedia, etc. For each query/program operator a decision table is provided, which determines allowed combinations of signatures and attributes, the resulting signature and its attributes, and additional actions.

18.  Query optimization in SBQL. SBA, as a formal methodology of building OO query languages, is exceptionally well prepared for query optimization. We have developed (and implemented) the methods based on rewriting: factoring out independent subqueries, rules based on the distributivity property, removing dead subqueries, query modification for processing stateless functions and views, and query tail absorption. We have also developed the methods based on indices, which include utilization of dense and range indices, fast linear hashing indices and index management utilities. We are developing methods based on query caching - storing results of queries in order to reuse them. Another group of methods concerns pipelining and other ways of parallel execution of queries. We also start investigations on heuristics and cost models concerning an optimal query execution plan.

19. Query processing and optimization in distributed systems. The methods concern query optimization for distributed databases with horizontal and vertical fragmentations. Research is in an initial stage, however, some significant results have already been achieved.

20. Data-intense grids and P2P networks: integration of distributed, heterogeneous, fragmented and redundant resources. The research concerns creating virtual repositories that integrate distributed, heterogeneous, fragmented and redundant data and service resources on the ground of virtual updateable views. We have developed and implemented an architecture of such an virtual repository, its metamodel and other functional properties. As part of this research, we have developed a P2P network, which is technically based on the Sun JXTA technology and conceptually on the SBQL engine and its virtual updateable views.

21.  Aspect-oriented databases. Aspect-oriented decomposition is a key feature for creating a truly user–friendly application development environment. In SBA/SBQL we have approached the problem from two sides: by introducing database features that make some aspects no more tangled, and by introducing overloading views that make it possible to introduce new semantics to already existing database objects. Both features have been confirmed by prototype implementations.


Examples of SBQL queries

(just to give some impression on the language)



An example UML-like database schema

Note bi-directional pointer links rather than UML association roles. Cardinalities concern all database entities. Nested classes are allowed.


Get all information on departments for employees named Doe:

(Emp where name = “Doe”).worksIn.Dept


Get the name of Doe’s boss:

(Emp where name = “Doe”)


Names and cities of employees working in departments managed by Kim:

(Dept where ( = “Kim”).employs.Emp.

(name, if exists(Address) then else “No address”)


Get the average number of employees in all departments:



Is it true that each department employs an employee earning more than his/her boss?:

forall (Dept as d) (forsome(d.employs.Emp as e)

(forsome(e.sal as s) s > d.boss.Emp.sal))


Get names of departments and the average age of their employees:

Dept . (dname, avg(employs.Emp.age) as a)


Get departments together with the average salary of their employees:

Dept join avg(employs.Emp.sal)


For each employee get the name and the percent of the annual budget of his/her department that is consumed by his/her monthly salary:

Emp . (name as n, (((if exists(sal) then sal else 0) as s).

((s * 12 * 100)/(worksIn.Dept.budget)) as percentOfBudget)


For each person having no salary give the minimal salary in his/her department:

for each (Emp where not exists(sal)) as e do

e.changeSal( min(e.works_in.Dept.employs.Emp.sal) )


Conclusion: 10 unique qualities of SBA/SBQL


1.      Orthogonal syntax, full compositionality of queries.

2.      Universal formal semantics based on abstract implementation.

3.      Computational universality, advanced data structures, integration with PL constructs.

4.      Strong typing of advanced O-O queries and programs.

5.      Several advanced implementations, further ones pending.

6.      Fully transparent O-O virtual updatable views.

7.      Strong potential for query optimization.

8.      All O-O notions treated formally and uniformly.

9.      Sound and manageable metamodel.

10.  The potential for distributed query processing.


SBA/SBQL Sources


1.      SBQL Web pages: (permanently extended)

2.      Various info:

3.      Papers and reports:

4.      DBLP record:

5.      PhD theses:


Last modified: November 17, 2008


[1] Originally,  AS0, AS1, AS2 and AS3 were denoted M0, M1, M2 and M3, correspondingly.