1. K.Stencel. SBQL Views, slide 1 March 2008 SBQL Object Views. Unlimited Mapping and Updatability Presentation prepared for 1 st International Conference on Object Databases Berlin, 13-14 March 2008 by Krzysztof Stencel Polish-Japanese Institute of Information Technology, Warsaw, Poland SBA/SBQL pages: http://www.sbql.plhttp://www.sbql.pl

2. K.Stencel. SBQL Views, slide 2 March 2008 Views Users and applications expect data in other forms than they are stored –Derived data –De-normalization Furthermore, users and applications should not touch stored data –Secret data, limited visibility –Schema evolution (logical data independence) View is the right tool to be in the middle Views map stored data onto virtual data

3. K.Stencel. SBQL Views, slide 3 March 2008 Updateable views Users read objects, but update them as well Views must also map updates of virtual data onto updates on stored data –Possibly also other operations like the retrieval can be mapped! If views are not updateable, some workarounds must be invented. This compromises view transparency

4. K.Stencel. SBQL Views, slide 4 March 2008 Views manifesto Views should be able to provide any mapping of stored data onto virtual data Views should be able to provide any mapping of updates of virtual data onto updates of stored data Or more: views should be able to provide any mapping of operations on virtual data onto operations on stored data –E.g. retrieval –E.g. Storing the virtual object reference in a persistent store The code of a view and its calls should be optimisable (to the possible extent) –Full algorithmic power of the language does not prohibit optimisation!

5. K.Stencel. SBQL Views, slide 5 March 2008 SQL Views No proposed view mechanism conforms to the manifesto Most prominent example: SQL views –Mapping of data: limited to SQL queries –Mapping of updates: very limited (so called simple views), but promisingly expanded in vendor implementations and by INSTEAD OF triggers Note the possibility of warping programmer’s intension –Mapping of retrieval: none –Optimisation: query modification

6. K.Stencel. SBQL Views, slide 6 March 2008 SBQL Views Seed: a small piece of a virtual object that uniquely identifies it Invocation of an SBQL view returns only seeds of its virtual objects. The query returning seeds is defined in SBQL - full algorithmic power Seeds are opaque: users/application receive them encapsulated in returned virtual objects, i.e. virtual object identifiers Overriding operations: - operations which are performed instead of operations on virtual objects –retrieve: (dereference) returns the value of the given virtual object; –update: modifies the value of the given virtual object; –create/insert : create a new virtual object, insert an object into a virtual object; –delete: removes the given virtual object; –navigate: navigates according to a virtual pointer. View creator defines: the seed query + overriding operations

7. K.Stencel. SBQL Views, slide 7 March 2008 Example schema type EmpType is record { name: string; deptName: string; salary: integer; opinion: string [0..1]; } type DeptType is record { dName: string; location: string; } Emp: EmpType [0..*]; Dept: DeptType [0..*];

8. K.Stencel. SBQL Views, slide 8 March 2008 Administrative name, seeds, virtual objects view RichEmpDef { virtual RichEmp : record { name:string; salary:integer; worksIn: ref Dept; }[0..*]; seed: record {e: ref Emp;}[0..*] { return (Emp where salary > 2000) as e; }... delete RichEmpDef;

9. K.Stencel. SBQL Views, slide 9 March 2008 Traceable retrieval view RichEmpDef {... seed: record {e: ref Emp;}[0..*] { return (Emp where salary > 2000) as e; } on_retrieve { checkPermission(currentUser); logRetrieval(currentUser, e); return e.name as name, e.salary as salary, ref (Dept where dName = e.deptName) as worksIn; }

10. K.Stencel. SBQL Views, slide 10 March 2008 Freely mappable update view RichEmpDef {... seed: record {e: ref Emp;}[0..*] { return (Emp where salary > 2000) as e; }... on_update { if (e.salary < value) { e.salary := value; }

11. K.Stencel. SBQL Views, slide 11 March 2008 And insert and delete too... on_new { if(value.salary > 2000) create permanent Emp( value.name as name, value.salary as salary, value.worksIn.dName as deptName ); } on_delete { log_deletion(e); delete e; }

12. K.Stencel. SBQL Views, slide 12 March 2008 Example usage seed foreach RichEmp as re do re := re.salary * 1,25; on_updateon_retrieve foreach RichEmpDef.seed() as re do on_update(re, on_retrieve(re).salary * 1,25); Definition can be expanded inline and futher rewritten E.g. dead queries removal will be applied

13. K.Stencel. SBQL Views, slide 13 March 2008 Nested views view RichEmpDef {...// declaration of objects, seeds, operators view nameDef { virtual name:string; seed : record { n : string; } { return e.name as n; } on_retrieve { return n; } } Exactly the same semantics as this of the super-view (object relativism) Handles well multi-valued sub-objects (attributes)

14. K.Stencel. SBQL Views, slide 14 March 2008 Virtual pointers view worksInDef { virtual worksIn:ref Dept; seed :record{ dn:Emp.deptName; } { return e.deptName as dn; } on_navigate { return Dept where dName = dn; } on_retrieve { return deref(Dept where dName = dn); } on_update { dn := value.dName; } }

15. K.Stencel. SBQL Views, slide 15 March 2008 Stateful views view RichEmpDef { virtual RichEmp : record {name:string;...}[0..*]; seed: record {e: ref Emp;}[0..*] { return (Emp where salary > threshold) as e; } //declaration of the view local object threshold: integer;... } RichEmpDef.threshold := 5000; avg(RichEmp.salary);

16. K.Stencel. SBQL Views, slide 16 March 2008 Optimisation Full algorithmic power does not prohibit optimisation Optimiser picks optimisable constructs and perform its duties All relational (and more) techniques apply for SBA and its views –Query modification –Predicate move-around (SBA: query tail absorption) –Dead queries removal (especially important for views) –Factoring out independent sub-queries –Index utilisation –Query caching –Rewriting based on operator associativity

17. K.Stencel. SBQL Views, slide 17 March 2008 Conclusions SBQL Views are perfectly flexible and universal –Any mapping onto virtual data –Any mapping of semantics of operations (also retrieval) –The structure of virtual objects can reflects stored objects in all models AS0, AS1,... (nesting, pointers, multi-valued attributes,...) –Virtual objects can belong to classes (and inherit their invariants) –Virtual objects can be dynamic object roles (AS2) SBQL Views are as optimisable as relational views (or more)

18. K.Stencel. SBQL Views, slide 18 March 2008 Conclusions cont. SBQL Views are a robust tool for complex data integration (due to the flexibility of their mappings) with various distributed architectures including P2P –Used by eGov-Bus UE project where ODRA plays the role of integration platform (with views in the central place) SBQL Views are implemented and tested –The most mature version in the ODRA VRMS SBQL Views were verified on top of wrappers of relational data with promising optimisation results –Successfully mapped SBQL view calls to single SQL queries