[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .. .. .... .

On Friday, January 21, 2011 2:48 PM, Herbert J. Bernstein wrote:

>This can be made to work,

I am pleased to hear it.

> but for my uses, there are
>some minor issues:
>1.  I will be grouping the primary DDLm tag.  With the
>_definition.xref_code removed, the primary DDLm tag
>will have to be aliased; and


>2.  With multiple xref codes for a given tag (e.g.
>DDL2 and DDLm), it would be more appropriate to
>normalize and put the tags and xref codes into
>a sub-category, rather than to keep repeating the
>same tag.  This would have the advantage of allowing
>the alias category to return to a non-compound key
>and would also allow all the grouping of
>tags in a dictionary to be gathered on a separate
>block, if desired.

The tags and xref could certainly be moved into a subcategory, but that cannot both reduce duplication and model the same data because (xref_code, definition_id) is a candidate key for whichever category you put it in.  Or rather, it could reduce duplication if you pulled ALIAS_XREF up to dictionary level, gave it at least one non-key attribute, and had multiple definitions referring to the same rows, but it doesn't look like that's how Herbert proposes scoping things.

>For these reasons, I suggest
>1.  Leave _alias.dictionary_uri, but deprecate it in
>favor of:

I'm missing something here.  Why is it appropriate to issue a brand new standard that already contains a deprecated feature?

>2.  Create an ALIAS_XREF category with the
>following tags, forming a composite key
>     a tag identifier belonging to a group
>     a code identifying a real or virtual dictionary
>or other logical groups of tags to which the tag

Thus the repetition of definition_id would appear in ALIAS_XREF instead of in ALIAS, and ALIAS_XREF would have a compound key instead of ALIAS having one.  And with this approach there is no way to model a defined item being aliased to some definitions of a particular data name but not to others.

We could take this route as long as the last is of no concern.  It is unlikely that we would ever encounter a problem in practice.  From the perspective of a data modeling purist, however, it makes me uncomfortable.  I could live with it, but to me it looks like the benefits don't justify the costs.

>The other tags that John proposes for David's uses
>actually fit better in terms of normalization in this sub-
>category, than on the top level, but that is a decision
>for David to make.  I am happy either way.

The other tags would be _alias.dictionary_version and _alias.deprecated.  Herbert is right: if ALIAS_XREF were introduced per his proposal then these attributes would best go there.  Personally, I would not be satisfied for ALIAS_XREF to be introduced but these two tags placed in ALIAS instead.  I would most prefer, however, to not introduce ALIAS_XREF at all.



Email Disclaimer:  www.stjude.org/emaildisclaimer

ddlm-group mailing list

Reply to: [list | sender only]