Bug #427
closedeml-constraint use of identifers
0%
Description
The current eml-constraint module is designed to reference table and attribute
identifers so that the relationships between two particular entities can be
established. However, we do not currently indicate how the values for these
identifiers should be obtained or constrained. Are they the eml-identifiers
(which doesn't work for attributes), or are they names (entityName,
attributeName) which might run into many problems with uniqueness issues? We
need an easy, consistent, approach that we recommend or require as part of the
semantics of this module.
In addition, constraints will always apply to one or more entities, so it is
reasonable to consider merging the entire eml-constraint module onto eml-entity.
However, doing this means that constraints that affect a table may be only
described in the description of a different table, which could definitely cause
some problems in locating the information. By maintining the independence of
the eml-constrain module, we create a single, identifiable location where both
participants in a constraint can be enumerated. This will be far easier for
applications to use to identify both sides of a constraint, at the cost of
having to specify both sides in the constraint description. Of course, this
does not apply to constraints that apply to only a single entity such as UNIQUE
constraints.
Related issues
Updated by Chad Berkley over 22 years ago
In looking at this issue, I think the best way to handle this would be to split eml-attribute up into multiple files. i.e. one attribute per xml file so that each attribute has its own identifier. This would make it easy to specify a single attribute of a single entity. this may also allow for the precise normalization of attributes in their association to a specific entity. Instead of having to reuse an entire list of attributes per entity, individual attributes can be reused.
Updated by Matt Jones over 22 years ago
Clarified documentation in eml-constraint to indicate that the entities that
participate in the constraint should be indicated using their unique identifier
from eml-entity, and that all entities that are referenced in eml-constraint
should be available in the data package in an eml-entity description (via a
triple link). Attributes that participate in keys are still referenced by their
names, because these are unique within an entity. Using a separate xml document
or file for each attribute would generally be onerous because their can be 100's
of attributes in a table entity, so we decided not to do that, but rather stick
to the current structure. Also, the "triple" element is not expressive enough
to include all of the constraint info, so we decided that a separate mecahnism
was warranted, so we kept the current structure.
Updated by Matt Jones over 22 years ago
- Bug 428 has been marked as a duplicate of this bug. ***