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
ODMG view
Integration Service
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 a pivotal 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 ODMGs 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 Detai
ls
Episodes EpisodeRef Date Details PatientRef
Patient MRN Quantity Date_in EpisodeRef
Episodes aggregate (EpisodeRef,Date,Details) fr
om Patient as EpisodeRef to PatientRef expand
Patient.EpisodeRef (reverse operation)
12
Class Restructuring

• subclass, superclass operators

Person superclass (Fname,Lname,DOB,Address) fr
om 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 bloodtyp
e
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.