Title: Ei dian otsikkoa
1Database comparison model
Jari Porrasmaa University of Kuopio, computing
centre HIS research and development unit
2Topics for today
- Conversion model - From FileMan to objects
- main principles
- standards and technologies used
- Other parts of the comparison model
- a list of comparison criteria
- modifications (add/delete/change) to this list
3Very short background
- M(umps) is a programming language that offers
automatic persistence for data structures - FileMan (FM) is a DBMS based on Mumps
- originates from USA (VA,DOD), but is also used in
Finland, Germany, African countries,... - FixIT is a RAD development toolkit that enables
building of GUIs for FileMan databases - Windows apps ( delphi FixIT)
- Java apps (client applets or server beans, Web
FixIT) - HTML apps (front ends, e-FixIT)
- Please refer to other presentations and project
web pages for more background material
4Introduction, what and why?
- What? Comparison of different database types
using one example case (the demo application,
Labworks). Also database features as is with the
demo app. - Why? To research utilisation of component based
software engineering paradigm in the healthcare
domain. Also to provide a strategy for
introducing new technology into existing software
assets in case - current technology (FM) dies and needs to be
replaced - new technology gives enough additional value
- It is NOT a beauty contest! No one clear winner
in the end. The objective is to bring out the
strengths and weaknesses of each solution in
context of different starting points in client
organisations (hospitals and companies in the
healthcare software business).
5Contents of the database comparison
- How can the Labworks demo app be implemented with
DBMS (and related) technology family X. Work done
by vendors (them) and HIS RD (us) together. - Each vendor presents their own solution,
specification of what is actually implemented
together - Conversion of the legacy database into each
target database (mainly on paper, but maybe
prototypes?) - Evaluation of other database features (the stuff
generally associated with DBMSs) - Comparison can be thought as a model for other
comparisons (hospitals and companies can attach
other technologies and products to it)
6Databases to be compared
- Representative of each DBSM genre
- Cache Objects
- roots in M language, has OO extensions
- Oracle
- based on the relational model, has OO extension
- Jasmine ODB
- pure object model representative
- FileMan
- viability of legacy technology, starting point
for other implementations
7Conversion model
- Its goal is to represent FileMan datamodel, data
and functionality as an object oriented model - Also to find a standard object model(s) which can
be used in the conversion process
8Conversion model in more detail
- Mapping of FM data model into OO data model
- FileMan stuctures
- FileMan datatypes (fields)
- automatic and manual conversion (refactoring the
generated model, or mapping FM to a non-generated
model) - Conversion of FM data into objects
- Implementation of FM functionality in other DBMS
technologies - Selection of the object model used in the
conversion - Possibly specification of gateways and wrappers
to integrate different technologies
9High level view of conversion and comparison
source and targets
Jasmine (ODQL)
FileMan data definitions and data
Cache (CDL)
Oracle PL/SQL?
10Help from the ODMG standard?
Jasmine ODQL
ODGM standard
FileMan data definitions and data
Cache CDL
Oracle PL/SQL
11Help from SQL1999 standard?
Jasmine ODQL
FileMan data definitions and data
Cache CDL
SQL1999 (SQL3)
Oracle PL/SQL
12Metadata can be utilised more generally...
Jasmine ODQL
CWM
FileMan data definitions and data
Cache CDL tiedosto
SQL1999 (SQL3)
Oracle PL/SQL
XMI
FixIT (DoIT, etc.IT) toolkits interoperability
with other software development tools
etc. etc
XMI CWM explained soon...
Component integration
Modelling tools
13The overall picture...
- Using the model for other purposes than the
conversion - Modelling, other developement tools, FixIT
toolkit, etc.
14OMG MOF, XMI and CWM explained
- OMG open consortium producing spefications/standar
ds based on requests made by members - known mainly from the following specs CORBA
UML - MOF - Meta Object Facility, unifying MOF
compatible metamodels (MOF is a metametamodel) - XMI - XML Metadata Interchange, Interchange of
metamodels using XML - CWM - Common (data)Warehouse Metamodel,
application of XMI (and MOF and UML) for
datawarehouse model and data interchange
15XML Metadata Interchange (XMI)
- Generates an XML structure definition (DTD) from
a MOF compliant metamodel (eg. MOF metamodel for
UML generates the UML XMI DTD) - DTD can be extended!
- Generates an XML document from metadata (metadata
is an instance of metamodel, eg. UML model
generates an XML document) - Can be seen as a MOF interchange format or as an
independent metadatastandard - Meta layers are not absolute. XMI can be used for
data interchange also.
16Simplified XMI as a diagram
Metamodel layer
If one uses a UML model on the metamodel layer
XMI can then be used as a data interchange format!
model layer
17Common Warehouse Metamodel (CWM)
- Defines the CWM MOF metamodel which is then used
for generating the interchange format - Generates from the MOF CWM metamodel the XMI CWM
DTD - Generates from a MOF CWM model an XMI CWM
document - Metamodels can also be interchanged as documents
- Defines APIs for handling datawarehouses and
metadata - Based on UML and XMI
- Could it be used in conversions by stretching the
ELT scenario specified in CWM standard?
18Usage scenarios for CWM
- Taken from the CWM specification
- ETL Extract, Transform and Load
- Data is extracted from some sources, then
transformed into the desired format and finally
loaded into some destination. Types of sources
and destinations can vary. Transformations can be
performed in different stages and several times. - Could it be used for DB 2 DB conversions?
- Which vendors will support CWM?
- CWM specification name many other usages for CWM,
but these are not of any interest here
19SQL1999 (SQL3) and basic-SQL
- SQL-99 is a very broad standard which introduces
many OO concepts into the SQL world - Implementations now and in the future? (even
partial implementations on the OO part of the
standard could be very useful) - Wide implementation of Basic-SQL is a strong
plus for using SQL, also SQL standard family is
the strongest one in the DBMS world - Significance of other SQL standards like SQLJ?
20Other standards?
- Are there other standards that weve overlooked
and could be useful for us? - In regard of the datamodel and data conversion
- and in the integration of development tools
trough the use of metadata
21Using standards pros and cons
- Are the tools and software supporting standards?
- Amount of work and new things to study
- Which actual products support different standards
and to what extent? Future plans? - Standards can help in achieving some degree of
interoperability, integration, product
independence etc.
22FileMan structures as OO structures
23FileMan field types and other features in the OO
model
This array doesnt have all FileMan features
(e.g. printing, user privileges). More complete
description in a separate document!
24Other comparison criteria
- Support for object orientation
- Support for development tools
- Support for component architectures and standards
- General DBMS features
- Market situation of technology, costs, vendor
situation on the market - Each criteria will be assessed according to
resources available and importance of criteria
25Object orientation
- Software engineering is done in an object
oriented way. The persistence layer should also
support OO. - DBMS implements concepts generally associated
with OO - DBMS offers bindings to OO languages
- DBMS has support for OO modelling and analysis
software
26Component architectures
- Comparison is architecture independent so
databases should interoperate with several
architectures - CORBA
- Windows DNA (.NET)
- Java 2 Enterprise Edition
- Can DBMS provide persistence for components
implemented in different architectures? - Also a separate master thesis on different
products implementing architectures mentioned
above (Juha Rannanheimo)
27Support for standards
- Standards on a more general level (not just the
standards used in the project) - Standards on database languages
- Database interface standards
- Standards on transaction control
- Metadata standards
28Development tools
- For each tier of the target architecture
- presentation, user interfaces (although focus
mainly on the layers below) - enterprise, business logic
- persistence, DBMS
- Reporting tools
- How do different tools work with a particular DB?
29General database features
- Hardware and operating system platforms
- User management (on DB and application level?)
- Authorisation
- Concurrency control
- Security
- Backups
- Administration tools
- ...
30Performance and scalability
- No resources for doing benchmarks. Any applicable
and independent benchmarks available? - Experiences and observations from prototypes
- Performance conversion / production
- Scalability up/down, same application running in
small and very large environments
31Vendor and technology specifics,soft issues
- Vendor and technology situation in the current
market / future? - Independent evaluations?
- soft issues
- available human resources?
- learning curve of technology?
32Your comments / ideas?
- Was there something missing?
- Something too much?
- What is essential?
- What do you as vendors want to tell to people
reading the report?