Many resources are needed to download a project. Please understand that we have to compensate our server costs. Thank you in advance. Project price only 1 $
You can buy this project and download/modify it how often you want.
DDMSence: Relational Database Model for DDMS 3.1
<%@ include file="../shared/header.jspf" %>
Relational Database Model for DDMS 3.1
This document is an attempt to map the DDMS specification to a relational database model. The intent of this mapping is to be comprehensive first
and pragmatic second -- the full scope of DDMS will be modeled, but some design decisions may be made for simplicity, such as modeling lists of values
as a delimited string value. Although direct-to-table persistence mapping will probably not be a feature in any version of DDMSence, this table model
may be useful when integrating DDMSence with an existing persistence framework like Hibernate or the Oracle XML SQL Utility (XSU).
General Notes
Column names generally match the XML element name, which is consistent with DDMSence's object model. There are a few minor differences
(such as using "timePeriodName" in a temporalCoverage element to avoid confusing it with the plain XML element name).
The unique sequenced id value which is the primary key in each table should be unique across all tables. This will allow foreign key
references in child components without requiring the child table to know what kind of parent it has. All id columns could also contain
generated UUID values instead of sequenced integers.
Child elements will have links back to their parents, but not in the reverse direction. This key is allowed to have an initial
<NULL> value, to support a bottom-up approach to building DDMS metacards from scratch.
If a table column is a character string and a value is not provided, an empty string should be favored instead of <NULL>.
The intent of the tables is to model the metacard data, not schema data. XML namespaces and other schema constructs are not necessarily modeled.
Reference tables (i.e. the four types of producers, or the valid names of ISM security attributes) are not included here. Columns which have string
values for these constants could just as easily have foreign keys to a reference table.
Most validation constraints are omitted from this model, since it is assumed that a validating library like DDMSence would be placed in front of the tables.
Character string lengths are fairly arbitrary, although the numbers I chose are relatively reasonable for the types of data the fields contain.
URI fields are set at 2048 characters to match Internet Explorer URL restrictions.
The pipe character, |, is suggested as a delimiter for columns containing lists in string form.
Please see the documentation on Extensible Attributes on a Resource to
understand the ambiguity problem associated with modeling security attributes as extensible attributes.
Columns:
id
integer, not null, sequenced
primary key of this row. This value is a foreign key in all child component tables.
resourceElement
boolean
Whether this tag sets the classification for the XML file as a whole (required)
createDate
char(32)
the creation date (dates are stored in string format to ensure
that the date value is retrieved in the same xsd:date that it was entered in).
desVersion
char(8)
the version of the ISM Data Encoding Specification used.
This modeling assumes that there is no reuse of producer entities between various roles. So, while the person named "Brian Uri" might have a creator
role and a contributor role, and while Brian's details might be identical in each XML element, each set of details would have a separate
row in this table.
Columns:
id
integer, not null, sequenced
primary key of this row
resourceId
integer
foreign key to the parent DDMS resource
producerType
char(24)
the type of this producer, i.e. "creator", "contributor", "pointOfContact" or "publisher"
All four entities share similar characteristics (at least one name, and optional phone numbers and email addresses), so
they are grouped into a single table, rather than a separate table for each entity type. The latter approach is equally viable.
This modeling also assumes that there is no reuse of entities between various roles. So, while the person named "Brian Uri" might have a creator
role and an addressee role, and while Brian's details might be identical in each XML element, each set of details would have a separate
row in this table.
Columns:
id
integer, not null, sequenced
primary key of this row
producerType
char(64)
the producer type (contributor, creator, pointOfContact, publisher)
producerId
integer
foreign key to the parent producer role fulfilled by this entity
entityType
char(24)
the type of this entity, i.e. "Organization", "Person", "Service" or "Unknown"
name
char(256), not null
a delimited string-list of names for this producer. At least one is required.
phone
char(256)
a delimited string-list of phone numbers for this producer. Optional.
email
char(2048)
a delimited string-list of email addresses for this producer. Optional.
surname
char(256)
This is a Person-specific column, containing a surname. Exactly one surname is required for
Person records.
userId
char(64)
This is a Person-specific column, containing an ID for a user.
affiliation
char(256)
This is a Person-specific column, containing an organizational affiliation for a user.
Optional.
acronym
char(64)
This is an Organization-specific column, containing an organizational acronym.
Optional.
Unlike the ISM Security Attributes table, where each row is an attribute, the rows in this table represent a complete set of
SRS information for a single element. Because the required/optional status of each attribute varies based on the parent,
no constraints enforce any rules here.
Columns:
id
integer, not null, sequenced
primary key of this row
parentId
integer
foreign key to the parent component of this attribute
srsName
char(2048)
the URI-based SRS name, optional on Positions,
but required on Points and Polygons
srsDimension
integer
a positive integer dimension
axisLabels
char(2048)
an ordered list of axes labels, as a
space-delimited list of NCNames
uomLabels
char(2048)
an ordered list of unit-of-measure labels for
the axes, as a space-delimited list of NCNames
As described in the class description,
DDMSence requires the top-level unitOfMeasure and datum attributes to be consistent on both
the parent component and the two extents, so this information need only be stored once for a table row.
Columns:
id
integer, not null, sequenced
primary key of this row
parentId
integer
foreign key to the parent geospatialCoverage row of this attribute
unitOfMeasure
char(64), not null
should be one of Meter, Kilometer, Foot, StatuteMile, NauticalMile, Fathom, Inch
Because a polygon is comprised of ordered positions that create an enclosed area, it is assumed that positions are ordered
according to their index value. As a closed shape, the first and last positions should be identical, but no
validation is done on this constraint here. The last position should definitely be a separate row in the gmlPosition table.
Columns:
id
integer, not null, sequenced
primary key of this row
parentId
integer
foreign key to the parent boundingGeometry element of this attribute
This table contains the custom elements which can appear at the top-level of the DDMS resource. The table merely stores the
XML of the element (DDMSence does not dig into these elements either). Each row in this table should map to one top-level
extensible element. Also note that the XML namespaces may have been defined higher up, so the XML fragment may not be correct on its own.
