Project

General

Profile

Actions

Bug #486

closed

eml-constraint changes needed

Added by Matt Jones over 20 years ago. Updated over 20 years ago.

Status:
Resolved
Priority:
Immediate
Assignee:
Category:
eml - general bugs
Target version:
Start date:
05/01/2002
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
486

Description

Changes as decided upon at the Sevilleta EML meeting, April 24-25, 2002:
Responsible: David, Peter, Matt

1) change entityType into separate elements for each constraint type so that the
various types are enforceable. Base it on the ASU model for this. For example,
there will be a "foreignKey" element that defines the content model for foreign
keys, indicating which fields are required

I added Peter and myself to this to make sure we got it right.


Files

eml-constraintR.xsd (24.9 KB) eml-constraintR.xsd David Blankman, 05/15/2002 02:30 PM
eml-constraint.xsd (23.4 KB) eml-constraint.xsd David Blankman, 05/24/2002 11:07 AM
Actions #2

Updated by David Blankman over 20 years ago

Here is a 99% complete version. I need to document "constraint name"
and "constraint description"

1. Renamed the "foreignKey" element to "foreignKeyRelationship".
It seemed to me that what was being expressed was not a description of the
foreign key but rather the relationship between two entities.

2. Changed the name of mandatory to existence

Existence is the database industry standard term.

3. Changed the type from boolean to string with a restriction/enumeration
of "mandatory" or "optional"

4. Added relationshipType element with type string with a
restriction/enumeration of "identifying" or "non-identifying".

5. I also changed cardinality to a choice of simple element with an enumerated
list of all of the possible cardinalities except for 1 to exactly N or a
complex element "cardinality1toN" which is a sequence of "parentOccurances"
and "childOccurances"

Here is an example of the output of ER Studio's relationship report:

Relationship Name
FK_CustomerCustomerDemo

Relationship Type
Identifying

Parent Entity
CustomerDemographics

Child Entity
CustomerCustomerDemo

Cardinality
One To Zero or More

Existence
Mandatory

Actions #3

Updated by Peter McCartney over 20 years ago

I've looked at the attachment and have talked with david as well. Here are some
comments:

1 - im not sure it clarifies anything to change the name foreignKey to
foreignKeyRelationship. We've already had debate online whether or not its
appropriate to use one element to describe all kinds of relationships,
regardless of how they are implemented , but weve been working under the
assumption that all relational information between two entities will be under
constraint/foreignKey

2) theres still some ambiguity about how relational pointers are being handled -
entities are being referred to by an id, but their attributes are being
refered to by their names. while idref pointers are superior for processing, im
concerned about readability of the xml files - should we be doing both names
and pointers? perhaps if i understood idref better i wouldnt be asking this.

3) lists of attributes participating in keys should have explicit squence_id
attributes. I dont think we should rely on the order of entry to match up fields

4) the information in "existence" and "cardinality1toN/parentOccurences"
and "cardinality" is redundant. wouldnt it be simpler to drop both existence
and cardinality and rename "cardinality1toN" to "cardinality". define an
enumeration of 0,1 for parentOccurences and set child occurences to integer. if
child occurences is missing, then we can assume it is unrestricted.

5) the module is designed to be linked at the dataset level. that is convenient
for foreignKeys since we want to look them up by either participating entity.
it seems awkward to have to use a relational pointer for the remaining
constraints as they act only on the one entity anyway and could be nested right
there. 6 of one 1/2 dozen of the other, but i just thought id mention it for
the record.

6) what about indexes? are we doing anything there?

Actions #4

Updated by Matt Jones over 20 years ago

1) I agree with Peter -- lets call it foreignKey.
2) the root element should be "constraint", not "eml-constraint", so you'll need
to fold "identifier" into constraint
3) You need entityid in primarykey, uniquekey, and check as well as foreignKey,
so you might as well make it part of ConstraintDefinitionBase. However, the
packaging changes will likely cause a modification to this, which I'll take care
of as part of the packaging bug changes for all modules.
4) as far as pointers go, if we were to choose idref to point among the
attribute names, the only requirement is that it points to an id that is unique
within the document. so as long as two different attributes did not share a
name (which is probably a bad assumption), we could use the name as an idref
pointer. This stuff will all get resolved in the packaging discussion which I'm
going to launch today with a proposal.
5) as Peter said, existence is identical to parentOccurences. I like his
proposed changes (eliminate existence & cardinality1toN, create enumeration for
parentOccurences, set childOccurences to integer)
6) I've noted the desire to nest constraint under entity. I'l address this in
the packaging note.
7) indexes. they are not really constraints, but we could list them here if
desired as an additional type. no need for some purist philosophy as long as it
isn't confusing. what would we need: <index> tag with the same content model as
uniqueKey, right?

Actions #5

Updated by Peter McCartney over 20 years ago

We at one time made a separate model for indexes as they are also redundate
with , but different from, keys. Keys can be indexed or not in some databases,
and indexes can be built on field combinations that dont produce a key. The
information is typically returned from most reverse engineering tools, but we
put it on hold because knowlede of indexes doesnt really affect your ability to
construct a query, it just affects performance.

I think if we turn to EML as a data design language, we may want finer
granularity in this whole area but for now would leave index to a future
module. At most, I might consider putting a boolean attribute called indexed
under each key as a hint to the potential performance of a query involving that
key.

Actions #7

Updated by David Blankman over 20 years ago

Removed "existence" element. Deleleted element "Cardinality"
Renamed "Cardinality 1 to N" to Cardinality. Created new type "CardinalityChildOccurancesType" as a union between a simple xs:integer,
and an xs:string with a restiction of the text "many".
Put entityID as a part of ConstraintDefinitionBase.
Renamed "check" to "checkConstraint".

Actions #8

Updated by Matt Jones over 20 years ago

David -- the element "ConstraintBase" is not needed. I eliminated it, and
checked in the modified version to CVS.

Actions #9

Updated by Matt Jones over 20 years ago

Changes completed, including the re-addition of the not NULL constraint.
Checked into CVS.

Actions #10

Updated by Owen Eddins over 20 years ago

I'm passing the following comments from Tim Bergsma the data manager at Kellog
Biological Station in Michagen. He made them in a eml-dev email. I posting to
bugzilla just to make sure they don't fall through the cracks.

Spelling: parentOccurances and childOccurances should be
-Occurences.

Actions #11

Updated by Matt Jones over 20 years ago

Fixed spelling issues. RESOLVED FIXED.

Actions #12

Updated by Redmine Admin over 9 years ago

Original Bugzilla ID was 486

Actions

Also available in: Atom PDF