[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .
- To: "'firstname.lastname@example.org'" <email@example.com>, Group finalising DDLm and associated dictionaries <firstname.lastname@example.org>
- Subject: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .
- From: "Bollinger, John C" <John.Bollinger@STJUDE.ORG>
- Date: Thu, 27 Jan 2011 17:21:02 -0600
- Accept-Language: en-US
- acceptlanguage: en-US
- In-Reply-To: <4D41C6E7.email@example.com>
- References: <AANLkTi=ATdNovWFiecEwDrbtMdTwZ7guvYuBCGrdnbfirstname.lastname@example.org><8F77913624F7524AACD2A92EAF3BFA54166D7D1EDE@SJMEMXMBS11.stjude.sjcrh.local ><4D404DAA.email@example.com> <firstname.lastname@example.org><8F77913624F7524AACD2A92EAF3BFA54166D7D1EE1@SJMEMXMBS11.stjude.sjcrh.local ><email@example.com><8F77913624F7524AACD2A92EAF3BFA54166D7D1EE8@SJMEMXMBS11.stjude.sjcrh.local ><firstname.lastname@example.org><8F77913624F7524AACD2A92EAF3BFA54166D7D1EEB@SJMEMXMBS11.stjude.sjcrh.local><4D41C6E7.email@example.com>
Hi John, On Thursday, January 27, 2011 1:27 PM, John Westbrook wrote: >I do not wish to complicate the discussion but I have a somewhat different perspective on >the the issue of normalization. By all means DO complicate the discussion if DDLm's relational model and normalization options are inadequate for your needs. [...] >To better address this in software we have added DDL2 extensions to define parent/child linking groups - > >See - > >http://mmcif.pdb.org/dictionaries/mmcif_ddl.dic/Data/history.html > >categories - pdbx_item_link_group and pdbx_item_link_group_list > >The groups defined in these categories allow validation of common items between categories >with multiple connecting relationships. For instance, tables of bonds, angles and torsions >have multiple independent collections of natural keys times the number of nomenclatures. >In some cases the validation must make independent comparisons of each group against >the same group of parents items. To be sure I understand: those categories provide a means for defining relationships involving candidate keys that are not category keys? That's an eminently reasonable thing to do. Do you use them in any broader sense? For example, where neither end of the link is a candidate key for its category? Are you looking to get something like this into DDLm, or are you satisfied to define it at dictionary level? >I raise this issue because it is an unavoidable consequence of denormalization. And, >as Herbert points out the denormalized organization is important in data harvesting >and generally maintaining a connection to laboratory practice. I think we're talking about two different levels of (de)normalization. I can see connections between *dictionary* denormalization and a need or want to define relationships where neither end is a category key. I don't see the same connection with a denormalized presentation of the *data*. For a denormalized presentation to be valid, it must be reducible to a normalized representation (to the extent that the dictionary is normalized), so any validations you can perform on a normalized presentation, you can also perform on a valid denormalized presentation. The possible failure to reduce to a normalized presentation is precisely the additional validation that I already pointed out was required of denormalized presentations. Am I missing something here? >In the original design of DDLm their was an emphasis on adopting simple rather than >complex category keys. This has been an issue of some concern for me as this does >not map well to our data which is rich in complex natural keys. Even for on-line transactional databases I have never been among those who categorically shun natural keys and shudder at compound ones. (I have seen production schema where even join tables have their own surrogate keys. Ridiculous!) For a human-readable and essentially static medium such as CIF, natural keys are highly appropriate, and there is no compelling reason to avoid compound keys where there is no simple candidate key. None of the arguments for doing so in an OLTP schema apply. With that said, the current DDLm draft does provide for compound category keys. I would be open to extending it to provide for explicit definition of candidate keys as well. If we do so, then I see no particular reason to not have a way to define relationships involving a candidate key on at least one side. Before I'll buy into relationships any more generalized than that, however, I'd like to understand the potential uses in more detail. Of course, no matter what facilities DDLm may provide, it is another question entirely whether dictionary authors use them. Regards, John -- John C. Bollinger, Ph.D. Department of Structural Biology St. Jude Children's Research Hospital Email Disclaimer: www.stjude.org/emaildisclaimer _______________________________________________ ddlm-group mailing list firstname.lastname@example.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed) (James Hester)
- Re: [ddlm-group] DDLm aliases (subject changed). . (David Brown)
- Re: [ddlm-group] DDLm aliases (subject changed). . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed). .. . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. . (Herbert J. Bernstein)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. . (Bollinger, John C)
- Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. . (John Westbrook)
- Prev by Date: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .
- Next by Date: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .
- Prev by thread: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .
- Next by thread: Re: [ddlm-group] DDLm aliases (subject changed). .. .. .. .. .