Stack-Based Architecture and Stack-Based Query Language

1
Stack-Based Architecture and Stack-Based Query
Language
Presentation prepared for 1st International
Conference on Object Databases Berlin, 13-14
March 2008 by Kazimierz Subieta
Polish-Japanese Institute of Information
Technology, Warsaw, Poland SBA/SBQL pages
http//www.sbql.pl
2
State of the theory

• Books

K.Subieta. Theory and Construction of
Object-Oriented Query Languages (522 pages in
Polish)
K.Stencel. Semi-strong Type Checking in
Object-Oriented Database Programming Languages
(210 pages in Polish)

• 20 years of research, 80 research papers, 2
  habilitations, 14 PhD-s (10 finished),
  several (gt10) implementations
• We describe SBA and SBQL on http//www.sbql.pl
  (work in progress)

3
What is SBA and SBQL?

• No border between querying and programming
• A single theory that uniformly covers both
  aspects
• Query languages are programming languages
• SBA offers a conceptual semantic frame for
  queries and programs involving queries
• SBQL is a model query programming language
  according to SBA
• It has the same role and meaning as object
  algebras, but it is formally sound, semantically
  precise and more universal
• SBA deals with various data models and all
  reasonable query constructs
• Including the most advanced OO models

4
Database models and SBA

• Database semantics depends on the assumed data
  model
• Data model is an ideological rather than
  technical notion
• People believe or not
• The relational database model is an ideology,
  supported by very limited mathematical theories
• OO is an ideology, too.
• SBA is a theory supporting the OO database
  ideology
• But no limits
• Full algorithmic and pragmatic power
• All imaginable and reasonable query and
  programming constructs
• However, SBA is neutral to database models
• It deals with data structures rather than with
  data models

5
Abstract implementation

• is a semantic specification method used in SBA
• A kind of operational semantics
• Denotational semantics abandoned due to heavy,
  obscure mathematics
• Abstract machine acting on abstract data
  structures
• object store
• environment stack (thus Stack-Based Architecture)
• query result stack
• The structures are well-known in PLs
• Query operators (selection, projection, join,
  quantifiers, ) can be precisely specified
  using the above abstract structures
• No loss for query optimization (just otherwise)

6
Features and functionality of SBQL

• All well-known database models, including the
  relational model, XML and the most advanced OO
  models
• All well-known query operators
• Less known operators (transitive closures,
  fixpoint equations, ...)
• Updating statements integrated with queries,
• Procedures, functions and methods
• Recursive, with parameters being queries
• Object-oriented virtual updatable views
• Static (semi-) strong type checking
• Query optimization methods (indices, rewriting
  rules, )

7
Query Languages as Programming Languages

• SBA adopts a run-time mechanism of PLs
• with necessary improvements
• The main syntactic decision is the unification of
  PL expressions and queries - no conceptual
  difference
• 22
• (xy)z
• Employee where salary 1000
• (Employee where salary (xy)z).name
• All such expressions/queries can be used as
• arguments of imperative statements
• parameters of procedures, functions or methods
• a return from a functional procedure

8
Naming, scoping, binding and ENVS

• 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
• Scopes are organized in an environment stack
  (ENVS) with the search from the top rule
• All names occurring in queries programs must be
  bound via ENVS
• No name can be bound otherwise

9
SBA object store models

• SBA assumes a family of formal object store
  models which are enumerated AS0, AS1, AS2 and AS3
• AS0 covers relational, nested-relational and
  XML-oriented databases
• including complex objects and pointer links
• AS1 store model extends AS0 by classes and static
  (multiple) inheritance
• AS2 store model extends AS1 by object roles and
  dynamic inheritance
• AS3 store model extends AS1 or AS2 by
  encapsulation

10
Notions common to store models

• Internal object identifier (OID)
• Uniquely identifies an object in the store.
• Assigned automatically, no external meaning.
• Used as a reference or a pointer to an object.
• External object name
• Usually bears some external semantics of an
  object, e.g. Person, Customer.
• Explicitly assigned by a database designer,
  programmer, etc.
• It is usually not unique, e.g. many objects named
  Person.
• Atomic object value
• Cannot be subdivided into smaller parts
• E.g. 2, 3.14, Doe, Hello, World!.
• The size is not constrained from 1 bit to
  gigabytes.

11
SBQL objects
lt i9, Emp, lt i10, name, Lee gt,
lt i11, sal, 900 gt, lt
i12, address, lti13, city, Rome gt,
lti14, street,
Boogie gt,
lti15, house, 13 gt gt,
lt i16, worksIn, i22 gt gt
lt i22, Dept, lt i23, dname, Ads gt,
lt i24, loc, Rome gt,
lt i25, employs, i5 gt,
lt i26, employs, i9 gt gt
12
SBQL query operators

• Algebraic operators do not use ENVS
• arithmetic and string operators and comparisons
• set-oriented operators
• auxiliary naming operators
• Boolean operators
• Non-algebraic operators use ENVS
• selection (where),
• projection, navigation, path expression (dot),
• dependent join (join),
• quantifiers,
• Non-algebraic operators cannot be expressed by
  any algebra (in the style of the relational
  algebra)

13
Environment stack (ENVS)

• A.k.a. call stack
• For query processing we modified it
• It contains binders rather than objects
• A binder is a named reference to an object (but
  not only)
• The same object can be referenced from different
  stack sections
• ENVS has usually two forms static (compilation)
  and dynamic (run-time)
• Some properties of a static stack must be shifted
  to a dynamic stack
• Static stack necessary for strong typing and
  optimizations
• A new role of ENVS processing non-algebraic
  operators

14
ENVS example of state
bind( Emp ) i1 bind( Y ) i128 bind( I )
Maria bind( sal ) i11 bind( Dept) i17,
i22
15
Opening a new section of ENVS (1)

• In PLs opening a new scope on ENVS is caused by
  entering a new procedure or entering a new block
• Respectively, removing the scope is performed
  when the control leaves the body of the
  procedure/block.
• To classical situations we add a new one
• Non-algebraic operators behave similarly to
  program blocks
• In query
• Emp where ( name Poe and sal gt 1000 )
• the part ( name Poe and sal gt 1000 ) behaves
  as a program block executed in an environment
  consisting of the interior of an Emp object.
• Binding must concern names name and sal
• Hence, we push on ENVS a section with the
  interior of the currently processed Emp object
  (next slide)

16
Opening a new section of ENVS (2)
condition
Emp where
(name Poe and sal gt 1000)
binding
binding
name(i10) sal(i11) address(i12)
worksIn(i16) Emp(i1) Emp(i5) Emp(i9)
Dept(i17) Dept(i22)
Interior of the 3-rd object Emp
Emp(i1) Emp(i5) Emp(i9) Dept(i17)
Dept(i22)
Initial ENVS state. bind( Emp ) i1, i5, i9
ENVS during evaluation of the condition for the
third object Emp. bind( name ) i10 bind(
sal ) i11

• Binder a pair n(x), n is a name that can be
  used in a query, x is some run-time entity
  (usually object identifier, but not only)
• Function nested returning binders to the
  interior of a processed object (generalized to
  other cases)

17
Classes, Roles and Inheritance

• AS1 introduces classes and static inheritance in
  the classical variant known e.g. from modeling
  tools such as UML
• AS2 introduces dynamic object roles and dynamic
  inheritance
• AS3 introduces subdivision of class properties
  into public and private
• The extensions imply small and obvious changes of
  the behavior of ENVS concerning semantics of
  non-algebraic operators
• For AS2 some new operators are necessary

18
UML-like schema (ODRA)
19
SBQL queries

• Get all information on departments for employees
  named Doe
• (Emp where lName Doe).worksIn.Dept
• Get the name of Does boss
• (Emp where lName Doe).worksIn.Dept.bo
  ss.Emp.lName
• Names and cities of employees working in
  departments managed by Kim
• (Dept where (boss.Emp.lName)
  Kim).employs.Emp.
• (lName, if exists(address) then
  address.city else No address)
• 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 . (lName as n, (((if exists(sal)
  then sal else 0) as s).
• ((s 12 100)/(worksIn.Dept.budget))
  as percentOfBudget)

20
SBQL programs

• For each employee having no salary give the
  minimal salary in his/her department
• A method

for each Emp where not exists(sal)
changeSal( min(worksIn.Dept.employs.Emp.sal) )
changeSal( newSal real ) boolean if
not exists(self.sal) then       self ltlt
newSal as sal //create and insert else
    if self.sal gt newSal then return
false        else self.sal
newSal        return true
21
Conclusions

• SBA is a universal theory that offers the methods
  of semantic specification concerning OO databases
• SBA is a come back from various DB theories to
  the PLs theory
• SBA is holistic - it does not give up any (even
  the most advanced) feature of current OO database
  QL PL
• Proven by several advanced implementations
• SBQL is the most advanced OO QL ever invented
• With precisely defined formal semantics
• Strongly typed, optimized, PL capabilities,
  updatable views
• Currently, no theory concerning OO databases can
  seriously compete with SBA