Link TF and TF-instance tables

[sefakilic]

Currently we have relationship defined from Curation to both TF and TF-instance tables. Although each TF instance should be associated with a single TF, the link from curation to both tables allow TF-instances be linked to multiple TFs. In order to prevent this, instead of Curation -> TF and Curation -> TF instance, we should have Curation -> TF-instance -> TF.

[ivanerill]

Yes, I do not foresee any obvious situation when a TF-instance could be linked to more than one TF. I imagine that, technically, a sub-unit could be part of two TFs, by binding to two different interacting molecules, but that would be rare in prokaryotes, and could always be resolved by adding twice the TF instance and giving it a different name. Remember that TF->TF_instance should be 1:N, since a TF may be composed of several TF_instances (subunits with different accessions).

[sefakilic]

Moved Curation -> TF relation to TF-instance -> TF.

Browse pages are pretty much same.

For the curation, though, a slight change in the form logic. On curation step 2, the curator selects a TF from the drop-down menu and enters a TF-accession number. We used to link both values to the curation.

In the new scheme, we still let the curator enter both values.

• If the TF-instance is already in the database, we check if the entered TF value and TF-instance's TF value are same. If they are not same, we return an error msg.

Ex: if curator enters NP_744292 (P. putida LexA), he/she should pick LexA in the 'TF' field. Otherwise, the page returns the following error msg:

It seems that NP_744292 is a LexA but you selected Fur.

• If the TF-instance is a new one, when new TF-instance is created in DB, we use the selected TF to link new TF-instance and the TF table.

[ivanerill]

It might be a bit less error prone to ask the curator to choose among TF_instances from a list and, if the desired is not available, enter a new one?