Difference: RelationalRegistryDM (1 vs. 6)

Revision 62012-08-30 - MarkusDemleitner

 
META TOPICPARENT name="RestfulRegistryInterfaceReq"
Changed:
<
<
Jumps: IvoaResReg :: registry mail archive :: RegistryMetadata :: VOResourceV10
>
>
Jumps: IvoaResReg :: registry mail archive :: RegistryMetadata :: VOResourceV10
Meetings: InterOpMay2011Registry
Deleted:
<
<

Meetings: InterOpMay2011Registry
 

Relational Registry DM

Added:
>
>
(Note there's now a page for RI2Discussion).
 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.
Changed:
<
<
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.
>
>
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.
 
Changed:
<
<
regDM.png
>
>
regDM.png
  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.
Changed:
<
<
The methodology for mapping the XML to relational schema involved the following transformations.
>
>
The methodology for mapping the XML to relational schema involved the following transformations.
 
Changed:
<
<
  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.
>
>
  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.
 
Deleted:
<
<
 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/
Changed:
<
<
>
>

-- PaulHarrison - 13 Jun 2011
Deleted:
<
<
 
META FILEATTACHMENT attr="" comment="VOResource Relational model" date="1336812501" name="regDM.png" path="regDM.png" size="321722" user="PaulHarrison" version="1.3"

Revision 52012-06-26 - root

 
META TOPICPARENT name="RestfulRegistryInterfaceReq"
Jumps: IvoaResReg :: registry mail archive :: RegistryMetadata :: VOResourceV10
Meetings: InterOpMay2011Registry

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.

regDM.png

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

META FILEATTACHMENT attr="" comment="VOResource Relational model" date="1336812501" name="regDM.png" path="regDM.png" size="321722" user="PaulHarrison" version="1.3"

Revision 42012-05-12 - PaulHarrison

 
META TOPICPARENT name="RestfulRegistryInterfaceReq"
Jumps: IvoaResReg :: registry mail archive :: RegistryMetadata :: VOResourceV10
Meetings: InterOpMay2011Registry

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.

regDM.png

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

<--  
-->

Changed:
<
<
META FILEATTACHMENT attr="" comment="VOResource Relational model" date="1336735723" name="regDM.png" path="regDM.png" size="318222" user="PaulHarrison" version="1.2"
>
>
META FILEATTACHMENT attr="" comment="VOResource Relational model" date="1336812501" name="regDM.png" path="regDM.png" size="321722" user="PaulHarrison" version="1.3"
 

Revision 32012-05-11 - PaulHarrison

 
META TOPICPARENT name="RestfulRegistryInterfaceReq"
Jumps: IvoaResReg :: registry mail archive :: RegistryMetadata :: VOResourceV10
Meetings: InterOpMay2011Registry

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.

Changed:
<
<
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.
>
>
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.
 
Changed:
<
<
regDM.png
>
>
regDM.png
 
Changed:
<
<
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.
>
>
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

<--  
-->

Changed:
<
<
META FILEATTACHMENT attr="" comment="VOResource Relational model" date="1307974859" name="regDM.png" path="regDM.png" size="174520" user="PaulHarrison" version="1.1"
>
>
META FILEATTACHMENT attr="" comment="VOResource Relational model" date="1336735723" name="regDM.png" path="regDM.png" size="318222" user="PaulHarrison" version="1.2"
 

Revision 22011-09-13 - PaulHarrison

 
META TOPICPARENT name="RestfulRegistryInterfaceReq"
Jumps: IvoaResReg :: registry mail archive :: RegistryMetadata :: VOResourceV10
Meetings: InterOpMay2011Registry

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.

regDM.png

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.
Changed:
<
<
>
>
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

<--  
-->

META FILEATTACHMENT attr="" comment="VOResource Relational model" date="1307974859" name="regDM.png" path="regDM.png" size="174520" user="PaulHarrison" version="1.1"

Revision 12011-06-13 - PaulHarrison

 
META TOPICPARENT name="RestfulRegistryInterfaceReq"
Jumps: IvoaResReg :: registry mail archive :: RegistryMetadata :: VOResourceV10
Meetings: InterOpMay2011Registry

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.

regDM.png

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

<--  
-->

META FILEATTACHMENT attr="" comment="VOResource Relational model" date="1307974859" name="regDM.png" path="regDM.png" size="174520" user="PaulHarrison" version="1.1"
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback