Relational Registry DM

Relational Registry DM

This page describes efforts towards creating a "relational" Registry DM that will express the same data model that is implicit within the resource XML schema, in order that the new DM definition could be used with a next generation Registry interface which might be more TAP-like.

One of the most desirable features of a relational DM is that it contain a few tables as possible to make querying it easier. I have tried to model the VOResource, VODataService and SIA schema (only) to achieve this aim and the result is shown below.

As can be seen this still involves the creation of 22 tables if the current element multiplicities that are in the XML schema are to be fully supported, as well as full round-trip to XML, and note that this number will increase when other schema are included.

The methodology for mapping the XML to relational schema involved the following transformations.

1. Type hierarchies are all collapsed into a single table with a KIND column to distinguish the types. This also means that sub-type properties must be allowed to be nullable.
2. An XML type is embedded directly within its parent whenever it has a cardinality of 1:1 (e.g. Content, Curation and then within those PUBLISHER_IVOID)
3. Lists of enumerations e.g. ContentLevel have been transformed to a single field with a delimited list of enumeration values
4. For elements where the cardinality is one to many a separate table has been created with a foreign key reference on the many side.

A Java library of objects that represent the Registry metadata models along with standard XML schema mapping (via JAXB) and the above relational mapping (via JPA) is available at http://software.astrogrid.org/doc/ivoa-objects/

-- PaulHarrison - 13 Jun 2011

Relational Registry DM

This page describes efforts towards creating a "relational" Registry DM that will express the same data model that is implicit within the resource XML schema, in order that the new DM definition could be used with a next generation Registry interface which might be more TAP-like.

One of the most desirable features of a relational DM is that it contain a few tables as possible to make querying it easier. I have tried to model the VOResource, VODataService and SIA schema (only) to achieve this aim and the result is shown below.

As can be seen this still involves the creation of 22 tables if the current element multiplicities that are in the XML schema are to be fully supported, as well as full round-trip to XML, and note that this number will increase when other schema are included.

The methodology for mapping the XML to relational schema involved the following transformations.

1. Type hierarchies are all collapsed into a single table with a KIND column to distinguish the types. This also means that sub-type properties must be allowed to be nullable.
2. An XML type is embedded directly within its parent whenever it has a cardinality of 1:1 (e.g. Content, Curation and then within those PUBLISHER_IVOID)
3. Lists of enumerations e.g. ContentLevel have been transformed to a single field with a delimited list of enumeration values
4. For elements where the cardinality is one to many a separate table has been created with a foreign key reference on the many side.

A Java library of objects that represent the Registry metadata models along with standard XML schema mapping (via JAXB) and the above relational mapping (via JPA) is available at http://software.astrogrid.org/doc/ivoa-objects/

-- PaulHarrison - 13 Jun 2011

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Relational Registry DM

This page describes efforts towards creating a "relational" Registry DM that will express the same data model that is implicit within the resource XML schema, in order that the new DM definition could be used with a next generation Registry interface which might be more TAP-like.

1. Type hierarchies are all collapsed into a single table with a KIND column to distinguish the types. This also means that sub-type properties must be allowed to be nullable.
2. An XML type is embedded directly within its parent whenever it has a cardinality of 1:1 (e.g. Content, Curation and then within those PUBLISHER_IVOID)
3. Lists of enumerations e.g. ContentLevel have been transformed to a single field with a delimited list of enumeration values
4. For elements where the cardinality is one to many a separate table has been created with a foreign key reference on the many side.

A Java library of objects that represent the Registry metadata models along with standard XML schema mapping (via JAXB) and the above relational mapping (via JPA) is available at http://software.astrogrid.org/doc/ivoa-objects/

-- PaulHarrison - 13 Jun 2011

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Relational Registry DM

This page describes efforts towards creating a "relational" Registry DM that will express the same data model that is implicit within the resource XML schema, in order that the new DM definition could be used with a next generation Registry interface which might be more TAP-like.

One of the most desirable features of a relational DM is that it contain a few tables as possible to make querying it easier. I have tried to model the VOResource schema (only) to achieve this aim and the result is shown below.

As can be seen this still involves the creation of 13 tables if the current element multiplicities that are in the XML schema are to be fully supported, and note that this number will increase when other schema are included.

The methodology for mapping the XML to relational schema involved the following transformations.

1. Type hierarchies are all collapsed into a single table with a KIND column to distinguish the types. This also means that sub-type properties must be allowed to be nullable.
2. An XML type is embedded directly within its parent whenever it has a cardinality of 1:1 (e.g. Content, Curation and then within those PUBLISHER_IVOID)
3. Lists of enumerations e.g. ContentLevel have been transformed to a single field with a delimited list of enumeration values
4. For elements where the cardinality is one to many a separate table has been created with a foreign key reference on the many side.

-- PaulHarrison - 13 Jun 2011

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Relational Registry DM

This page describes efforts towards creating a "relational" Registry DM that will express the same data model that is implicit within the resource XML schema, in order that the new DM definition could be used with a next generation Registry interface which might be more TAP-like.

One of the most desirable features of a relational DM is that it contain a few tables as possible to make querying it easier. I have tried to model the VOResource schema (only) to achieve this aim and the result is shown below.

As can be seen this still involves the creation of 13 tables if the current element multiplicities that are in the XML schema are to be fully supported, and note that this number will increase when other schema are included.

The methodology for mapping the XML to relational schema involved the following transformations.

1. Type hierarchies are all collapsed into a single table with a KIND column to distinguish the types. This also means that sub-type properties must be allowed to be nullable.
2. An XML type is embedded directly within its parent whenever it has a cardinality of 1:1 (e.g. Content, Curation and then within those PUBLISHER_IVOID)
3. Lists of enumerations e.g. ContentLevel have been transformed to a single field with a delimited list of enumeration values
4. For elements where the cardinality is one to many a separate table has been created with a foreign key reference on the many side.

-- PaulHarrison - 13 Jun 2011

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->