chado.sequence Tables
Table / View | Referenced | Foreign Keys | Columns | Type | Comments |
---|---|---|---|---|---|
feature | 30 | 3 | 13 | Table | A feature is a biological sequence or a section of a biological sequence, or a collection of such sections. Examples include genes, exons, transcripts, regulatory regions, polypeptides, protein domains, chromosome sequences, sequence variations, cross-genome match regions such as hits and HSPs and so on; see the Sequence Ontology for more. The combination of organism_id, uniquename and type_id should be unique. |
feature_contact | 0 | 2 | 3 | Table | Links contact(s) with a feature. Used to indicate a particular person or organization responsible for discovery or that can provide more information on a particular feature. |
feature_cvterm | 3 | 3 | 6 | Table | Associate a term from a cv with a feature, for example, GO annotation. |
feature_cvterm_dbxref | 0 | 2 | 3 | Table | Additional dbxrefs for an association. Rows in the feature_cvterm table may be backed up by dbxrefs. For example, a feature_cvterm association that was inferred via a protein-protein interaction may be backed by by refering to the dbxref for the alternate protein. Corresponds to the WITH column in a GO gene association file (but can also be used for other analagous associations). See http://www.geneontology.org/doc/GO.annotation.shtml#file for more details. |
feature_cvterm_pub | 0 | 2 | 3 | Table | Secondary pubs for an association. Each feature_cvterm association is supported by a single primary publication. Additional secondary pubs can be added using this linking table (in a GO gene association file, these corresponding to any IDs after the pipe symbol in the publications column. |
feature_cvtermprop | 0 | 2 | 5 | Table | Extensible properties for feature to cvterm associations. Examples: GO evidence codes; qualifiers; metadata such as the date on which the entry was curated and the source of the association. See the featureprop table for meanings of type_id, value and rank. |
feature_dbxref | 0 | 2 | 4 | Table | Links a feature to dbxrefs. |
feature_pub | 1 | 2 | 3 | Table | Provenance. Linking table between features and publications that mention them. |
feature_pubprop | 0 | 2 | 5 | Table | Property or attribute of a feature_pub link. |
feature_relationship | 2 | 3 | 6 | Table | Features can be arranged in graphs, e.g. "exon part_of transcript part_of gene"; If type is thought of as a verb, the each arc or edge makes a statement Subject Verb Object. The object can also be thought of as parent (containing feature), and subject as child (contained feature or subfeature). We include the relationship rank/order, because even though most of the time we can order things implicitly by sequence coordinates, we can not always do this - e.g. transpliced genes. It is also useful for quickly getting implicit introns. |
feature_relationship_pub | 0 | 2 | 3 | Table | Provenance. Attach optional evidence to a feature_relationship in the form of a publication. |
feature_relationshipprop | 1 | 2 | 5 | Table | Extensible properties for feature_relationships. Analagous structure to featureprop. This table is largely optional and not used with a high frequency. Typical scenarios may be if one wishes to attach additional data to a feature_relationship - for example to say that the feature_relationship is only true in certain contexts. |
feature_relationshipprop_pub | 0 | 2 | 3 | Table | Provenance for feature_relationshipprop. |
feature_synonym | 0 | 3 | 6 | Table | Linking table between feature and synonym. |
featureloc | 1 | 2 | 12 | Table | The location of a feature relative to another feature. Important: interbase coordinates are used. This is vital as it allows us to represent zero-length features e.g. splice sites, insertion points without an awkward fuzzy system. Features typically have exactly ONE location, but this need not be the case. Some features may not be localized (e.g. a gene that has been characterized genetically but no sequence or molecular information is available). Note on multiple locations: Each feature can have 0 or more locations. Multiple locations do NOT indicate non-contiguous locations (if a feature such as a transcript has a non-contiguous location, then the subfeatures such as exons should always be manifested). Instead, multiple featurelocs for a feature designate alternate locations or grouped locations; for instance, a feature designating a blast hit or hsp will have two locations, one on the query feature, one on the subject feature. Features representing sequence variation could have alternate locations instantiated on a feature on the mutant strain. The column:rank is used to differentiate these different locations. Reflexive locations should never be stored - this is for -proper- (i.e. non-self) locations only; nothing should be located relative to itself. |
featureloc_pub | 0 | 2 | 3 | Table | Provenance of featureloc. Linking table between featurelocs and publications that mention them. |
featureprop | 1 | 2 | 5 | Table | A feature can have any number of slot-value property tags attached to it. This is an alternative to hardcoding a list of columns in the relational schema, and is completely extensible. |
featureprop_pub | 0 | 2 | 3 | Table | Provenance. Any featureprop assignment can optionally be supported by a publication. |
synonym | 3 | 1 | 4 | Table | A synonym for a feature. One feature can have multiple synonyms, and the same synonym can apply to multiple features. |