Integrating View Schemata Using an Extended Object Definition Language

1. Integrating View Schemata Using an Extended Object Definition Language Mark Roantree Dublin City University

2. Content • Introduction • Background, Problem & Motivation • View Concepts & Language Overview • View Language Usage • Generation of Virtual Class Extents • Implementation & Conclusions

3. Introduction • Federated Database Systems • Heterogeneous Information Systems communicate through a common (ODMG) interface. • Each system specifies data views to share with other systems. • A view is a subschema of virtual classes. • An Integration Service imports views and combines them to form a federated view.

4. Integration Service ODMG view Oracle 8 ODMG view Legacy ODMG Federated Schema ODMG view Informix ODMG view Versant

5. Background • The OASIS Project: research into building a healthcare prototype. • Six information systems to share data in the HIV department of a Dublin hospital. • Forward interoperability is a requirement. • Four of these systems may participate in alternate federations.

6. Problem & Motivation • Global database imports locally defined views. • Specific views are selected to comprise each federated schema. • To support forward interoperability, the usage of a standard model is important. • ODMG is a published standard which supports the necessary o-o features. • A semantically rich model helps integration engineers to “understand” each schema.

7. Problem & Motivation • Problem • ODMG has no view mechanism. • Requirements: • View mechanism must: • retain as much semantic information as possible; • easily facilitate complex restructuring (o-o model is not as simple as the relational model); • support schema integration.

8. View Concepts • A view is a subschema comprising one or more (multi-class) segments. • A segment comprises one or more classes connected through either inheritance or association relationships. • Each segment contains apivotal class which determines the extent for all classes in that segment. • No new object identifiers are created i.e. an object preserving semantics with tight bindings between virtual and base classes.

9. Language Overview • Property Declarations: • rename • hide • derive • Class Declarations • operation (restructure & integrate) • rename • filter • The ODLv language is an extension to ODMG’s ODL.

10. Property Declarations Subschema PASlocal1 { SchemaSegment { ImportBase Patient, Consultant; Restructure { use Patient property { rename Fname as Firstname hide DOB,Bloodtype,NextOfKin derive cm_height as height * 2.5 } } Export PASlocal1.Patient, PASlocal1.Consultant; } }

11. Class Restructuring • aggregate operator Patient MRN Quantity Date_in EpisodeRef Date Details Episodes EpisodeRef Date Details PatientRef Patient MRN Quantity Date_in EpisodeRef Episodes := aggregate (EpisodeRef,Date,Details) from Patient {as EpisodeRef to PatientRef} expand Patient.EpisodeRef(reverse operation)

12. Class Restructuring • subclass, superclass operators Person := superclass (Fname,Lname,DOB,Address) from Patient flatten Patient into Person rename Person as Patient (reverse operation) Person Patient Fname Lname DOB Address Fname Lname DOB MRN NextOfKin bloodtype consultant Address Episodes Patient MRN NextOfKin bloodtype consultant Episodes

13. Restructuring Sample subschema AggFed1 { SchemaSegment{ ImportVirtual PAS1.Patient; Restructure { use PAS1.Patient class { Episodes := aggregate (EpisodeRef, Date, Details) from Patient as EpisodeRef to PatientRef} }; Export AggFed1.Patient, AggFed1.Episodes}; };

14. Integration operator • join, ojoin Patient Fname Lname PatientID DOB Address bloodtype Patient Fname Lname MRN DOB Address Patient Firstname Lastname DOB PatientID bloodtype PAS database HIV database Property Mapping

15. Using join • How to deal with synonyms? • Use link to bind two properties. • What happens if all four semantically related properties are not equal? • Objects are not a member of the extent for the new virtual class or • Use prefer to choose one value or • Use with to amend the contents of one property so that the property pair becomes equal.

16. join sample (i) class { join Patient from PAS.Patient, HIV.Patient on PAS.Patient.MRN link PatientId := MRN } • This view will use MRN and PatientID to perform the join operation. PatientID is the chosen label in the view class. • It will also require that both DOB properties match, otherwise the objects will not form part of the view class extent. • Name properties (eg. Fname and Firstname) are treated as unrelated properties.

17. join sample (ii) class { join Patient from PAS.Patient, HIV.Patient on Pas.Patient.MRN link PatientId := MRN link Fname := Firstname link Lname := Lastname } • This view will expect that Fname and Firstname are equal otherwise objects will not form part of the view class extent. • The term after the link statement is used in the view class (Fname, Lname).

18. join sample (iii) class { join Patient from PAS.Patient, HIV.Patient on Pas.Patient.MRN link PatientId := MRN link Fname := Firstname link Lname := Lastname with Fname prefer PAS.Fname with Lname prefer PAS.Lname } • Where names do not match, values from the PAS database are chosen. • Note that the DOB properties must still match.

19. Integration operator • superjoin, osuperjoin Patient Firstname Lastname DOB MRN Patient Fname Lname MRN DOB Address Patient Firstname Lastname DOB PatientID bloodtype P_Patient Address H_Patient bloodtype

20. Class Filters • A filter function f()is applied to a pivotal class. • The filter function is used to create the extents for all classes in that segment of the schema. • A filter is an OQL where clause. filter Patient where bloodtype = ‘A’

21. Generation of Extents • How are extents for base classes generated? • A shallow extent Es(C) is the set of all objects for the class C. The extent query for this class is “select *.*”. • A deep extent Ed(C) is the set of all objects for the class C, plus the deep extents for all of its sub-classes Si. Ed(C) = Es(C)  Ed(Si) i

22. Virtual Class Extents • Let VC be the Virtual Class and f() be the filter function applied to that class. Ed(f(VC)) = Es(f(VC))  Ed(fi(VSi)) i • A different filter function is generated for each class based on the filter for the pivotal class.

23. Implementation • ODMG metamodel was extended to hold virtual entities (new metaclasses). • Versant OOdb was used to store ODMG representations of local Information Systems. • Java/ANTLR was used to construct parser for view and wrapper definitions. • Visual C++ 6.0 used to implement the semantic actions for each view command.

24. view definition View Service Database Schema Repository Schema ODMG-defined metadata types (describe database schema) user-defined object instances Wrapper Service Extension metadata types (describe view schemata & object wrappers wrapper definition Database ODL Process ODL file Model Transformation Process Local IS

25. Conclusions • Research into federated databases has proposed an o-o canonical model. • ODMG provides a standard solution but does not support virtual classes and properties, or view schemata. • The ODLv and ODLw languages overcome this problem, with the inclusion of rich semantics. • Carefully crafted views allow updates for some federations.