Difference between revisions of "Chado Tables"
(→Table: feature) |
Dongilbert (Talk | contribs) (→Table: feature : fixed residues problem) |
||
Line 1,172: | Line 1,172: | ||
| seqlen | | seqlen | ||
| integer | | integer | ||
− | | '' ''<br /><br />{{Problem|''this column is required'' should be reworded, as it suggests that the field is required, which cannot be true of genes that are not mapped and features with types that do not have sequences, e.g. protein complexes. Is this use of required is in the sense of "why we had to include it in the schema"?}} | + | | '' ''<br /><br /> <!-- {{Problem|''this column is required'' should be reworded, as it suggests that the field is required, which cannot be true of genes that are not mapped and features with types that do not have sequences, e.g. protein complexes. Is this use of required is in the sense of "why we had to include it in the schema"?}} : fixed; dgg ~~~~ --> |
− | The length of the residue feature. See column:residues. This column is | + | The length of the residue feature. See column:residues. This column is used often because the location may be unknown and the residue sequence may not be manifested, yet it may be desirable to store and query the length of the feature. The seqlen should always be manifested where the length of the sequence is known. It should always equal length(residues) where residues is not NULL. |
|- class="tr1" | |- class="tr1" | ||
| | | |
Revision as of 05:31, 16 April 2007
Contents
- 1 Table: db
- 2 Table: dbxref
- 3 Table: project
- 4 Table: tableinfo
- 5 Table: cv
- 6 Table: cvterm
- 7 Table: cvterm_dbxref
- 8 Table: cvterm_relationship
- 9 Table: cvtermpath
- 10 Table: cvtermprop
- 11 Table: cvtermsynonym
- 12 Table: dbxrefprop
- 13 Table: wwwuser
- 14 Table: wwwuser_cvterm
- 15 Table: wwwuser_expression
- 16 Table: wwwuser_feature
- 17 Table: wwwuser_genotype
- 18 Table: wwwuser_organism
- 19 Table: wwwuser_phenotype
- 20 Table: wwwuser_project
- 21 Table: wwwuser_pub
- 22 Table: wwwuserrelationship
- 23 Table: feature
- 24 Table: feature_cvterm
- 25 Table: feature_cvterm_dbxref
- 26 Table: feature_cvterm_pub
- 27 Table: feature_cvtermprop
- 28 Table: feature_dbxref
- 29 Table: feature_pub
- 30 Table: feature_pubprop
- 31 Table: feature_relationship
- 32 Table: feature_relationship_pub
- 33 Table: feature_relationshipprop
- 34 Table: feature_relationshipprop_pub
- 35 Table: feature_synonym
- 36 Table: featureloc
- 37 Table: featureloc_pub
- 38 Table: featureprop
- 39 Table: featureprop_pub
- 40 Table: synonym
- 41 Table: phylonode
- 42 Table: phylonode_dbxref
- 43 Table: phylonode_organism
- 44 Table: phylonode_pub
- 45 Table: phylonode_relationship
- 46 Table: phylonodeprop
- 47 Table: phylotree
- 48 Table: phylotree_pub
- 49 Table: library
- 50 Table: library_cvterm
- 51 Table: library_feature
- 52 Table: library_pub
- 53 Table: library_synonym
- 54 Table: libraryprop
- 55 Table: contact
- 56 Table: contact_relationship
- 57 Table: stock
- 58 Table: stock_cvterm
- 59 Table: stock_dbxref
- 60 Table: stock_genotype
- 61 Table: stock_pub
- 62 Table: stock_relationship
- 63 Table: stock_relationship_pub
- 64 Table: stockcollection
- 65 Table: stockcollection_stock
- 66 Table: stockcollectionprop
- 67 Table: stockprop
- 68 Table: stockprop_pub
- 69 Table: environment
- 70 Table: environment_cvterm
- 71 Table: feature_genotype
- 72 Table: genotype
- 73 Table: phendesc
- 74 Table: phenotype_comparison
- 75 Table: phenstatement
- 76 Table: acquisition
- 77 Table: acquisition_relationship
- 78 Table: acquisitionprop
- 79 Table: arraydesign
- 80 Table: arraydesignprop
- 81 Table: assay
- 82 Table: assay_biomaterial
- 83 Table: assay_project
- 84 Table: assayprop
- 85 Table: biomaterial
- 86 Table: biomaterial_dbxref
- 87 Table: biomaterial_relationship
- 88 Table: biomaterial_treatment
- 89 Table: biomaterialprop
- 90 Table: channel
- 91 Table: control
- 92 Table: element
- 93 Table: element_relationship
- 94 Table: elementresult
- 95 Table: elementresult_relationship
- 96 Table: magedocumentation
- 97 Table: mageml
- 98 Table: protocol
- 99 Table: protocolparam
- 100 Table: quantification
- 101 Table: quantification_relationship
- 102 Table: quantificationprop
- 103 Table: study
- 104 Table: study_assay
- 105 Table: studydesign
- 106 Table: studydesignprop
- 107 Table: studyfactor
- 108 Table: studyfactorvalue
- 109 Table: treatment
- 110 Table: featuremap
- 111 Table: featuremap_pub
- 112 Table: featurepos
- 113 Table: featurerange
- 114 Table: analysis
- 115 Table: analysisfeature
- 116 Table: analysisprop
- 117 Table: eimage
- 118 Table: expression
- 119 Table: expression_cvterm
- 120 Table: expression_image
- 121 Table: expression_pub
- 122 Table: feature_expression
- 123 Table: feature_phenotype
- 124 Table: phenotype
- 125 Table: phenotype_cvterm
- 126 Table: pub
- 127 Table: pub_dbxref
- 128 Table: pub_relationship
- 129 Table: pubauthor
- 130 Table: pubprop
- 131 Table: organism
- 132 Table: organism_dbxref
- 133 Table: organism_relationship
- 134 Table: organismpath
- 135 Table: organismprop
Table: db
A database authority. Typical databases in bioinformatics are FlyBase, GO, UniProt, NCBI, MGI, etc. The authority is generally known by this shortened form, which is unique within the bioinformatics and biomedical realm. To Do - add support for URIs, URNs (e.g. LSIDs). We can do this by treating the URL as a URI - however, some applications may expect this to be resolvable - to be decided.
F-Key | Name | Type | Description |
---|---|---|---|
db_id | serial | PRIMARY KEY | |
name | character varying(255) | UNIQUE NOT NULL | |
description | character varying(255) | ||
urlprefix | character varying(255) | ||
url | character varying(255) |
Tables referencing this one via Foreign Key Constraints:
Table: dbxref
A unique, global, public, stable identifier. Not necessarily an eXternal reference - can reference data items inside the particular chado instance being used. Typically a row in a table can be uniquely identified with a primary identifier (called dbxref_id); a table may also have secondary identifiers (in a linking table <T>_dbxref). A dbxref is generally written as <DB>:<ACCESSION> or as <DB>:<ACCESSION>:<VERSION>.
F-Key | Name | Type | Description |
---|---|---|---|
dbxref_id | serial | PRIMARY KEY | |
db_id | integer | UNIQUE#1 NOT NULL | |
accession | character varying(255) | UNIQUE#1 NOT NULL The local part of the identifier. Guaranteed by the db authority to be unique for that db. | |
version | character varying(255) | UNIQUE#1 NOT NULL DEFAULT ''::character varying | |
description | text |
Tables referencing this one via Foreign Key Constraints:
Table: project
F-Key | Name | Type | Description |
---|---|---|---|
project_id | serial | PRIMARY KEY | |
name | character varying(255) | UNIQUE NOT NULL | |
description | character varying(255) | NOT NULL |
Tables referencing this one via Foreign Key Constraints:
Table: tableinfo
F-Key | Name | Type | Description |
---|---|---|---|
tableinfo_id | serial | PRIMARY KEY | |
name | character varying(30) | UNIQUE NOT NULL | |
primary_key_column | character varying(30) | ||
is_view | integer | NOT NULL | |
view_on_table_id | integer | ||
superclass_table_id | integer | ||
is_updateable | integer | NOT NULL DEFAULT 1 | |
modification_date | date | NOT NULL DEFAULT now() |
Tables referencing this one via Foreign Key Constraints:
Table: cv
A controlled vocabulary or ontology. A cv is composed of cvterms (AKA terms, classes, types, universals - relations and properties are also stored in cvterm) and the relationships between them.
F-Key | Name | Type | Description |
---|---|---|---|
cv_id | serial | PRIMARY KEY | |
name | character varying(255) | UNIQUE NOT NULL The name of the ontology. This corresponds to the obo-format -namespace-. cv names uniquely identify the cv. In OBO file format, the cv.name is known as the namespace. | |
definition | text | A text description of the criteria for membership of this ontology. |
Tables referencing this one via Foreign Key Constraints:
Table: cvterm
A term, class, universal or type within an ontology or controlled vocabulary. This table is also used for relations and properties. cvterms constitute nodes in the graph defined by the collection of cvterms and cvterm_relationships.
F-Key | Name | Type | Description |
---|---|---|---|
cvterm_id | serial | PRIMARY KEY | |
cv_id | integer | UNIQUE#1 NOT NULL The cv or ontology or namespace to which this cvterm belongs. | |
name | character varying(1024) | UNIQUE#1 NOT NULL A concise human-readable name or label for the cvterm. Uniquely identifies a cvterm within a cv. | |
definition | text | A human-readable text definition. | |
dbxref_id | integer | UNIQUE NOT NULL Primary identifier dbxref - The unique global OBO identifier for this cvterm. Note that a cvterm may have multiple secondary dbxrefs - see also table: cvterm_dbxref. | |
is_obsolete | integer | UNIQUE#1 NOT NULL Boolean 0=false,1=true; see GO documentation for details of obsoletion. Note that two terms with different primary dbxrefs may exist if one is obsolete. | |
is_relationshiptype | integer | NOT NULL Boolean 0=false,1=true relations or relationship types (also known as Typedefs in OBO format, or as properties or slots) form a cv/ontology in themselves. We use this flag to indicate whether this cvterm is an actual term/class/universal or a relation. Relations may be drawn from the OBO Relations ontology, but are not exclusively drawn from there. |
Tables referencing this one via Foreign Key Constraints:
Table: cvterm_dbxref
In addition to the primary identifier (cvterm.dbxref_id) a cvterm can have zero or more secondary identifiers/dbxrefs, which may refer to records in external databases. The exact semantics of cvterm_dbxref are not fixed. For example: the dbxref could be a pubmed ID that is pertinent to the cvterm, or it could be an equivalent or similar term in another ontology. For example, GO cvterms are typically linked to InterPro IDs, even though the nature of the relationship between them is largely one of statistical association. The dbxref may be have data records attached in the same database instance, or it could be a "hanging" dbxref pointing to some external database. NOTE: If the desired objective is to link two cvterms together, and the nature of the relation is known and holds for all instances of the subject cvterm then consider instead using cvterm_relationship together with a well-defined relation.
F-Key | Name | Type | Description |
---|---|---|---|
cvterm_dbxref_id | serial | PRIMARY KEY | |
cvterm_id | integer | UNIQUE#1 NOT NULL | |
dbxref_id | integer | UNIQUE#1 NOT NULL | |
is_for_definition | integer | NOT NULL A cvterm.definition should be supported by one or more references. If this column is true, the dbxref is not for a term in an external database - it is a dbxref for provenance information for the definition. |
Table: cvterm_relationship
A relationship linking two cvterms. Each cvterm_relationship constitutes an edge in the graph defined by the collection of cvterms and cvterm_relationships. The meaning of the cvterm_relationship depends on the definition of the cvterm R refered to by type_id. However, in general the definitions are such that the statement "all SUBJs REL some OBJ" is true. The cvterm_relationship statement is about the subject, not the object. For example "insect wing part_of thorax".
F-Key | Name | Type | Description |
---|---|---|---|
cvterm_relationship_id | serial | PRIMARY KEY | |
type_id | integer | UNIQUE#1 NOT NULL The nature of the relationship between subject and object. Note that relations are also housed in the cvterm table, typically from the OBO relationship ontology, although other relationship types are allowed. | |
subject_id | integer | UNIQUE#1 NOT NULL The subject of the subj-predicate-obj sentence. The cvterm_relationship is about the subject. In a graph, this typically corresponds to the child node. | |
object_id | integer | UNIQUE#1 NOT NULL The object of the subj-predicate-obj sentence. The cvterm_relationship refers to the object. In a graph, this typically corresponds to the parent node. |
Table: cvtermpath
The reflexive transitive closure of the cvterm_relationship relation.
F-Key | Name | Type | Description |
---|---|---|---|
cvtermpath_id | serial | PRIMARY KEY | |
type_id | integer | UNIQUE#1 The relationship type that this is a closure over. If null, then this is a closure over ALL relationship types. If non-null, then this references a relationship cvterm - note that the closure will apply to both this relationship AND the OBO_REL:is_a (subclass) relationship. | |
subject_id | integer | UNIQUE#1 NOT NULL | |
object_id | integer | UNIQUE#1 NOT NULL | |
cv_id | integer | NOT NULL Closures will mostly be within one cv. If the closure of a relationship traverses a cv, then this refers to the cv of the object_id cvterm. | |
pathdistance | integer | UNIQUE#1 The number of steps required to get from the subject cvterm to the object cvterm, counting from zero (reflexive relationship). |
Table: cvtermprop
Additional extensible properties can be attached to a cvterm using this table. Corresponds to -AnnotationProperty- in W3C OWL format.
F-Key | Name | Type | Description |
---|---|---|---|
cvtermprop_id | serial | PRIMARY KEY | |
cvterm_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL The name of the property or slot is a cvterm. The meaning of the property is defined in that cvterm. | |
value | text | UNIQUE#1 NOT NULL DEFAULT ''::text The value of the property, represented as text. Numeric values are converted to their text representation. | |
rank | integer | UNIQUE#1 NOT NULL Property-Value ordering. Any cvterm can have multiple values for any particular property type - these are ordered in a list using rank, counting from zero. For properties that are single-valued rather than multi-valued, the default 0 value should be used. |
Table: cvtermsynonym
A cvterm actually represents a distinct class or concept. A concept can be refered to by different phrases or names. In addition to the primary name (cvterm.name) there can be a number of alternative aliases or synonyms. For example, "T cell" as a synonym for "T lymphocyte".
F-Key | Name | Type | Description |
---|---|---|---|
cvtermsynonym_id | serial | PRIMARY KEY | |
cvterm_id | integer | UNIQUE#1 NOT NULL | |
synonym | character varying(1024) | UNIQUE#1 NOT NULL | |
type_id | integer | A synonym can be exact, narrower, or broader than. |
Table: dbxrefprop
Metadata about a dbxref. Note that this is not defined in the dbxref module, as it depends on the cvterm table. This table has a structure analagous to cvtermprop.
F-Key | Name | Type | Description |
---|---|---|---|
dbxrefprop_id | serial | PRIMARY KEY | |
dbxref_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | NOT NULL DEFAULT ''::text | |
rank | integer | UNIQUE#1 NOT NULL |
Table: wwwuser
Keep track of WWW users. This may also be useful in an audit module at some point.
F-Key | Name | Type | Description |
---|---|---|---|
wwwuser_id | serial | PRIMARY KEY | |
username | character varying(32) | UNIQUE NOT NULL | |
password | character varying(32) | NOT NULL | |
character varying(128) | NOT NULL | ||
profile | text |
Tables referencing this one via Foreign Key Constraints:
Table: wwwuser_cvterm
Track wwwuser interest in cvterms.
F-Key | Name | Type | Description |
---|---|---|---|
wwwuser_cvterm_id | serial | PRIMARY KEY | |
wwwuser_id | integer | UNIQUE#1 NOT NULL | |
cvterm_id | integer | UNIQUE#1 NOT NULL | |
world_read | smallint | NOT NULL DEFAULT 1 |
Table: wwwuser_expression
Track wwwuser interest in expressions.
F-Key | Name | Type | Description |
---|---|---|---|
wwwuser_expression_id | serial | PRIMARY KEY | |
wwwuser_id | integer | UNIQUE#1 NOT NULL | |
expression_id | integer | UNIQUE#1 NOT NULL | |
world_read | smallint | NOT NULL DEFAULT 1 |
Table: wwwuser_feature
Track wwwuser interest in features.
F-Key | Name | Type | Description |
---|---|---|---|
wwwuser_feature_id | serial | PRIMARY KEY | |
wwwuser_id | integer | UNIQUE#1 NOT NULL | |
feature_id | integer | UNIQUE#1 NOT NULL | |
world_read | smallint | NOT NULL DEFAULT 1 |
Table: wwwuser_genotype
Track wwwuser interest in genotypes.
F-Key | Name | Type | Description |
---|---|---|---|
wwwuser_genotype_id | serial | PRIMARY KEY | |
wwwuser_id | integer | UNIQUE#1 NOT NULL | |
genotype_id | integer | UNIQUE#1 NOT NULL | |
world_read | smallint | NOT NULL DEFAULT 1 |
Table: wwwuser_organism
Track wwwuser interest in organisms.
F-Key | Name | Type | Description |
---|---|---|---|
wwwuser_organism_id | serial | PRIMARY KEY | |
wwwuser_id | integer | UNIQUE#1 NOT NULL | |
organism_id | integer | UNIQUE#1 NOT NULL | |
world_read | smallint | NOT NULL DEFAULT 1 |
Table: wwwuser_phenotype
Track wwwuser interest in phenotypes.
F-Key | Name | Type | Description |
---|---|---|---|
wwwuser_phenotype_id | serial | PRIMARY KEY | |
wwwuser_id | integer | UNIQUE#1 NOT NULL | |
phenotype_id | integer | UNIQUE#1 NOT NULL | |
world_read | smallint | NOT NULL DEFAULT 1 |
Table: wwwuser_project
Link wwwuser accounts to projects
F-Key | Name | Type | Description |
---|---|---|---|
wwwuser_project_id | serial | PRIMARY KEY | |
wwwuser_id | integer | UNIQUE#1 NOT NULL | |
project_id | integer | UNIQUE#1 NOT NULL | |
world_read | smallint | NOT NULL DEFAULT 1 |
Table: wwwuser_pub
Track wwwuser interest in publications.
F-Key | Name | Type | Description |
---|---|---|---|
wwwuser_pub_id | serial | PRIMARY KEY | |
wwwuser_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL | |
world_read | smallint | NOT NULL DEFAULT 1 |
Table: wwwuserrelationship
Track wwwuser interest in other wwwusers.
F-Key | Name | Type | Description |
---|---|---|---|
wwwuserrelationship_id | serial | PRIMARY KEY | |
objwwwuser_id | integer | UNIQUE#1 NOT NULL | |
subjwwwuser_id | integer | UNIQUE#1 NOT NULL | |
world_read | smallint | NOT NULL DEFAULT 1 |
Generated by PostgreSQL Autodoc
Table: feature
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.
F-Key | Name | Type | Description |
---|---|---|---|
feature_id | serial | PRIMARY KEY | |
dbxref_id | integer | An optional primary public stable identifier for this feature. Secondary identifiers and external dbxrefs go in the table feature_dbxref. | |
organism_id | integer | UNIQUE#1 NOT NULL The organism to which this feature belongs. This column is mandatory. | |
name | character varying(255) | The optional human-readable common name for a feature, for display purposes. | |
uniquename | text | UNIQUE#1 NOT NULL The unique name for a feature; may not be necessarily be particularly human-readable, although this is preferred. This name must be unique for this type of feature within this organism. | |
residues | text | A sequence of alphabetic characters representing biological residues (nucleic acids, amino acids). This column does not need to be manifested for all features; it is optional for features such as exons where the residues can be derived from the featureloc. It is recommended that the value for this column be manifested for features which may may non-contiguous sublocations (e.g. transcripts), since derivation at query time is non-trivial. For expressed sequence, the DNA sequence should be used rather than the RNA sequence. | |
seqlen | integer | The length of the residue feature. See column:residues. This column is used often because the location may be unknown and the residue sequence may not be manifested, yet it may be desirable to store and query the length of the feature. The seqlen should always be manifested where the length of the sequence is known. It should always equal length(residues) where residues is not NULL. | |
md5checksum | character(32) | The 32-character checksum of the sequence, calculated using the MD5 algorithm. This is practically guaranteed to be unique for any feature. This column thus acts as a unique identifier on the mathematical sequence. | |
type_id | integer | UNIQUE#1 NOT NULL A required reference to a table:cvterm giving the feature type. This will typically be a Sequence Ontology identifier. This column is thus used to subclass the feature table. | |
is_analysis | boolean | NOT NULL DEFAULT false Boolean indicating whether this feature is annotated or the result of an automated analysis. Analysis results also use the companalysis module. Note that the dividing line between analysis and annotation may be fuzzy, this should be determined on a per-project basis in a consistent manner. One requirement is that there should only be one non-analysis version of each wild-type gene feature in a genome, whereas the same gene feature can be predicted multiple times in different analyses. | |
is_obsolete | boolean | NOT NULL DEFAULT false Boolean indicating whether this feature has been obsoleted. Some chado instances may choose to simply remove the feature altogether, others may choose to keep an obsolete row in the table. | |
timeaccessioned | timestamp without time zone | NOT NULL DEFAULT ('now'::text)::timestamp(6) with time zone For handling object accession or modification timestamps (as opposed to database auditing data, handled elsewhere). The expectation is that these fields would be available to software interacting with chado. | |
timelastmodified | timestamp without time zone | NOT NULL DEFAULT ('now'::text)::timestamp(6) with time zone For handling object accession or modification timestamps (as opposed to database auditing data, handled elsewhere). The expectation is that these fields would be available to software interacting with chado. |
Tables referencing this one via Foreign Key Constraints:
Table: feature_cvterm
Associate a term from a cv with a feature, for example, GO annotation.
F-Key | Name | Type | Description |
---|---|---|---|
feature_cvterm_id | serial | PRIMARY KEY | |
feature_id | integer | UNIQUE#1 NOT NULL | |
cvterm_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL Provenance for the annotation. Each annotation should have a single primary publication (which may be of the appropriate type for computational analyses) where more details can be found. Additional provenance dbxrefs can be attached using feature_cvterm_dbxref. | |
is_not | boolean | NOT NULL DEFAULT false If this is set to true, then this annotation is interpreted as a NEGATIVE annotation - i.e. the feature does NOT have the specified function, process, component, part, etc. See GO docs for more details. |
Tables referencing this one via Foreign Key Constraints:
Table: feature_cvterm_dbxref
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.
F-Key | Name | Type | Description |
---|---|---|---|
feature_cvterm_dbxref_id | serial | PRIMARY KEY | |
feature_cvterm_id | integer | UNIQUE#1 NOT NULL | |
dbxref_id | integer | UNIQUE#1 NOT NULL |
Table: feature_cvterm_pub
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.
F-Key | Name | Type | Description |
---|---|---|---|
feature_cvterm_pub_id | serial | PRIMARY KEY | |
feature_cvterm_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: feature_cvtermprop
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.
F-Key | Name | Type | Description |
---|---|---|---|
feature_cvtermprop_id | serial | PRIMARY KEY | |
feature_cvterm_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL The name of the property/slot is a cvterm. The meaning of the property is defined in that cvterm. cvterms may come from the OBO evidence code cv. | |
value | text | The value of the property, represented as text. Numeric values are converted to their text representation. This is less efficient than using native database types, but is easier to query. | |
rank | integer | UNIQUE#1 NOT NULL Property-Value ordering. Any feature_cvterm can have multiple values for any particular property type - these are ordered in a list using rank, counting from zero. For properties that are single-valued rather than multi-valued, the default 0 value should be used. |
Table: feature_dbxref
Links a feature to dbxrefs. This is for secondary identifiers; primary identifiers should use feature.dbxref_id.
F-Key | Name | Type | Description |
---|---|---|---|
feature_dbxref_id | serial | PRIMARY KEY | |
feature_id | integer | UNIQUE#1 NOT NULL | |
dbxref_id | integer | UNIQUE#1 NOT NULL | |
is_current | boolean | NOT NULL DEFAULT true The is_current boolean indicates whether the linked dbxref is the current -official- dbxref for the linked feature. |
Table: feature_pub
Provenance. Linking table between features and publications that mention them.
F-Key | Name | Type | Description |
---|---|---|---|
feature_pub_id | serial | PRIMARY KEY | |
feature_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Tables referencing this one via Foreign Key Constraints:
Table: feature_pubprop
Property or attribute of a feature_pub link.
F-Key | Name | Type | Description |
---|---|---|---|
feature_pubprop_id | serial | PRIMARY KEY | |
feature_pub_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | ||
rank | integer | UNIQUE#1 NOT NULL |
Table: feature_relationship
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.
F-Key | Name | Type | Description |
---|---|---|---|
feature_relationship_id | serial | PRIMARY KEY | |
subject_id | integer | UNIQUE#1 NOT NULL The subject of the subj-predicate-obj sentence. This is typically the subfeature. | |
object_id | integer | UNIQUE#1 NOT NULL The object of the subj-predicate-obj sentence. This is typically the container feature. | |
type_id | integer | UNIQUE#1 NOT NULL Relationship type between subject and object. This is a cvterm, typically from the OBO relationship ontology, although other relationship types are allowed. The most common relationship type is OBO_REL:part_of. Valid relationship types are constrained by the Sequence Ontology. | |
value | text | Additional notes or comments. | |
rank | integer | UNIQUE#1 NOT NULL The ordering of subject features with respect to the object feature may be important (for example, exon ordering on a transcript - not always derivable if you take trans spliced genes into consideration). Rank is used to order these; starts from zero. |
Tables referencing this one via Foreign Key Constraints:
Table: feature_relationship_pub
Provenance. Attach optional evidence to a feature_relationship in the form of a publication.
F-Key | Name | Type | Description |
---|---|---|---|
feature_relationship_pub_id | serial | PRIMARY KEY | |
feature_relationship_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: feature_relationshipprop
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.
F-Key | Name | Type | Description |
---|---|---|---|
feature_relationshipprop_id | serial | PRIMARY KEY | |
feature_relationship_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL The name of the property/slot is a cvterm. The meaning of the property is defined in that cvterm. Currently there is no standard ontology for feature_relationship property types. | |
value | text | The value of the property, represented as text. Numeric values are converted to their text representation. This is less efficient than using native database types, but is easier to query. | |
rank | integer | UNIQUE#1 NOT NULL Property-Value ordering. Any feature_relationship can have multiple values for any particular property type - these are ordered in a list using rank, counting from zero. For properties that are single-valued rather than multi-valued, the default 0 value should be used. |
Tables referencing this one via Foreign Key Constraints:
Table: feature_relationshipprop_pub
Provenance for feature_relationshipprop.
F-Key | Name | Type | Description |
---|---|---|---|
feature_relationshipprop_pub_id | serial | PRIMARY KEY | |
feature_relationshipprop_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: feature_synonym
Linking table between feature and synonym.
F-Key | Name | Type | Description |
---|---|---|---|
feature_synonym_id | serial | PRIMARY KEY | |
synonym_id | integer | UNIQUE#1 NOT NULL | |
feature_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL The pub_id link is for relating the usage of a given synonym to the publication in which it was used. | |
is_current | boolean | NOT NULL DEFAULT true The is_current boolean indicates whether the linked synonym is the current -official- symbol for the linked feature. | |
is_internal | boolean | NOT NULL DEFAULT false Typically a synonym exists so that somebody querying the db with an obsolete name can find the object theyre looking for (under its current name. If the synonym has been used publicly and deliberately (e.g. in a paper), it may also be listed in reports as a synonym. If the synonym was not used deliberately (e.g. there was a typo which went public), then the is_internal boolean may be set to -true- so that it is known that the synonym is -internal- and should be queryable but should not be listed in reports as a valid synonym. |
Table: featureloc
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.
F-Key | Name | Type | Description |
---|---|---|---|
featureloc_id | serial | PRIMARY KEY | |
feature_id | integer | UNIQUE#1 NOT NULL The feature that is being located. Any feature can have zero or more featurelocs. | |
srcfeature_id | integer | The source feature which this location is relative to. Every location is relative to another feature (however, this column is nullable, because the srcfeature may not be known). All locations are -proper- that is, nothing should be located relative to itself. No cycles are allowed in the featureloc graph. | |
fmin | integer | The leftmost/minimal boundary in the linear range represented by the featureloc. Sometimes (e.g. in Bioperl) this is called -start- although this is confusing because it does not necessarily represent the 5-prime coordinate. Important: This is space-based (interbase) coordinates, counting from zero. To convert this to the leftmost position in a base-oriented system (eg GFF, Bioperl), add 1 to fmin. | |
is_fmin_partial | boolean | NOT NULL DEFAULT false This is typically false, but may be true if the value for column:fmin is inaccurate or the leftmost part of the range is unknown/unbounded. | |
fmax | integer | The rightmost/maximal boundary in the linear range represented by the featureloc. Sometimes (e.g. in bioperl) this is called -end- although this is confusing because it does not necessarily represent the 3-prime coordinate. Important: This is space-based (interbase) coordinates, counting from zero. No conversion is required to go from fmax to the rightmost coordinate in a base-oriented system that counts from 1 (e.g. GFF, Bioperl). | |
is_fmax_partial | boolean | NOT NULL DEFAULT false This is typically false, but may be true if the value for column:fmax is inaccurate or the rightmost part of the range is unknown/unbounded. | |
strand | smallint | The orientation/directionality of the location. Should be 0, -1 or +1. | |
phase | integer | Phase of translation with respect to srcfeature_id. Values are 0, 1, 2. It may not be possible to manifest this column for some features such as exons, because the phase is dependant on the spliceform (the same exon can appear in multiple spliceforms). This column is mostly useful for predicted exons and CDSs. | |
residue_info | text | Alternative residues, when these differ from feature.residues. For instance, a SNP feature located on a wild and mutant protein would have different alternative residues. for alignment/similarity features, the alternative residues is used to represent the alignment string (CIGAR format). Note on variation features; even if we do not want to instantiate a mutant chromosome/contig feature, we can still represent a SNP etc with 2 locations, one (rank 0) on the genome, the other (rank 1) would have most fields null, except for alternative residues. | |
locgroup | integer | UNIQUE#1 NOT NULL This is used to manifest redundant, derivable extra locations for a feature. The default locgroup=0 is used for the DIRECT location of a feature. Important: most Chado users may never use featurelocs WITH logroup > 0. Transitively derived locations are indicated with locgroup > 0. For example, the position of an exon on a BAC and in global chromosome coordinates. This column is used to differentiate these groupings of locations. The default locgroup 0 is used for the main or primary location, from which the others can be derived via coordinate transformations. Another example of redundant locations is storing ORF coordinates relative to both transcript and genome. Redundant locations open the possibility of the database getting into inconsistent states; this schema gives us the flexibility of both warehouse instantiations with redundant locations (easier for querying) and management instantiations with no redundant locations. An example of using both locgroup and rank: imagine a feature indicating a conserved region between the chromosomes of two different species. We may want to keep redundant locations on both contigs and chromosomes. We would thus have 4 locations for the single conserved region feature - two distinct locgroups (contig level and chromosome level) and two distinct ranks (for the two species). | |
rank | integer | UNIQUE#1 NOT NULL Used when a feature has >1 location, otherwise the default rank 0 is used. Some features (e.g. blast hits and HSPs) have two locations - one on the query and one on the subject. Rank is used to differentiate these. Rank=0 is always used for the query, Rank=1 for the subject. For multiple alignments, assignment of rank is arbitrary. Rank is also used for sequence_variant features, such as SNPs. Rank=0 indicates the wildtype (or baseline) feature, Rank=1 indicates the mutant (or compared) feature. |
Name | Constraint |
---|---|
featureloc_c2 | CHECK ((fmin <= fmax)) |
Tables referencing this one via Foreign Key Constraints:
Table: featureloc_pub
Provenance of featureloc. Linking table between featurelocs and publications that mention them.
F-Key | Name | Type | Description |
---|---|---|---|
featureloc_pub_id | serial | PRIMARY KEY | |
featureloc_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: featureprop
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.
F-Key | Name | Type | Description |
---|---|---|---|
featureprop_id | serial | PRIMARY KEY | |
feature_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL The name of the property/slot is a cvterm. The meaning of the property is defined in that cvterm. Certain property types will only apply to certain feature types (e.g. the anticodon property will only apply to tRNA features) ; the types here come from the sequence feature property ontology. | |
value | text | The value of the property, represented as text. Numeric values are converted to their text representation. This is less efficient than using native database types, but is easier to query. | |
rank | integer | UNIQUE#1 NOT NULL Property-Value ordering. Any feature can have multiple values for any particular property type - these are ordered in a list using rank, counting from zero. For properties that are single-valued rather than multi-valued, the default 0 value should be used |
Tables referencing this one via Foreign Key Constraints:
Table: featureprop_pub
Provenance. Any featureprop assignment can optionally be supported by a publication.
F-Key | Name | Type | Description |
---|---|---|---|
featureprop_pub_id | serial | PRIMARY KEY | |
featureprop_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: synonym
A synonym for a feature. One feature can have multiple synonyms, and the same synonym can apply to multiple features.
F-Key | Name | Type | Description |
---|---|---|---|
synonym_id | serial | PRIMARY KEY | |
name | character varying(255) | UNIQUE#1 NOT NULL The synonym itself. Should be human-readable machine-searchable ascii text. | |
type_id | integer | UNIQUE#1 NOT NULL Types would be symbol and fullname for now. | |
synonym_sgml | character varying(255) | NOT NULL The fully specified synonym, with any non-ascii characters encoded in SGML. |
Tables referencing this one via Foreign Key Constraints:
Table: phylonode
This is the most pervasive element in the phylogeny module, cataloging the "phylonodes" of tree graphs. Edges are implied by the parent_phylonode_id reflexive closure. For all nodes in a nested set implementation the left and right index will be *between* the parents left and right indexes.
F-Key | Name | Type | Description |
---|---|---|---|
phylonode_id | serial | PRIMARY KEY | |
phylotree_id | integer | UNIQUE#1 UNIQUE#2 NOT NULL | |
parent_phylonode_id | integer | Root phylonode can have null parent_phylonode_id value. | |
left_idx | integer | UNIQUE#1 NOT NULL | |
right_idx | integer | UNIQUE#2 NOT NULL | |
type_id | integer | Type: e.g. root, interior, leaf. | |
feature_id | integer | Phylonodes can have optional features attached to them e.g. a protein or nucleotide sequence usually attached to a leaf of the phylotree for non-leaf nodes, the feature may be a feature that is an instance of SO:match; this feature is the alignment of all leaf features beneath it. | |
label | character varying(255) | ||
distance | double precision |
Tables referencing this one via Foreign Key Constraints:
Table: phylonode_dbxref
For example, for orthology, paralogy group identifiers; could also be used for NCBI taxonomy; for sequences, refer to phylonode_feature, feature associated dbxrefs.
F-Key | Name | Type | Description |
---|---|---|---|
phylonode_dbxref_id | serial | PRIMARY KEY | |
phylonode_id | integer | UNIQUE#1 NOT NULL | |
dbxref_id | integer | UNIQUE#1 NOT NULL |
Table: phylonode_organism
This linking table should only be used for nodes in taxonomy trees; it provides a mapping between the node and an organism. One node can have zero or one organisms, one organism can have zero or more nodes (although typically it should only have one in the standard NCBI taxonomy tree).
F-Key | Name | Type | Description |
---|---|---|---|
phylonode_organism_id | serial | PRIMARY KEY | |
phylonode_id | integer | UNIQUE NOT NULL One phylonode cannot refer to >1 organism. | |
organism_id | integer | NOT NULL |
Table: phylonode_pub
F-Key | Name | Type | Description |
---|---|---|---|
phylonode_pub_id | serial | PRIMARY KEY | |
phylonode_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: phylonode_relationship
This is for exotic relationships that are not strictly hierarchical; for example, horizontal gene transfer. Use of this table would be highly unusual; most phylogenetic trees are strictly hierarchical. Nevertheless, it is here for completeness.
F-Key | Name | Type | Description |
---|---|---|---|
phylonode_relationship_id | serial | PRIMARY KEY | |
subject_id | integer | UNIQUE#1 NOT NULL | |
object_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
rank | integer |
Table: phylonodeprop
F-Key | Name | Type | Description |
---|---|---|---|
phylonodeprop_id | serial | PRIMARY KEY | |
phylonode_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL type_id could designate phylonode hierarchy relationships, for example: species taxonomy (kingdom, order, family, genus, species), "ortholog/paralog", "fold/superfold", etc. | |
value | text | UNIQUE#1 NOT NULL DEFAULT ''::text | |
rank | integer | UNIQUE#1 NOT NULL |
Table: phylotree
Global anchor for phylogenetic tree.
F-Key | Name | Type | Description |
---|---|---|---|
phylotree_id | serial | PRIMARY KEY | |
dbxref_id | integer | NOT NULL | |
name | character varying(255) | ||
type_id | integer | Type: protein, nucleotide, taxonomy, for example. The type should be any SO type, or "taxonomy". | |
comment | text |
Tables referencing this one via Foreign Key Constraints:
Table: phylotree_pub
Tracks citations global to the tree e.g. multiple sequence alignment supporting tree construction.
F-Key | Name | Type | Description |
---|---|---|---|
phylotree_pub_id | serial | PRIMARY KEY | |
phylotree_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: library
F-Key | Name | Type | Description |
---|---|---|---|
library_id | serial | PRIMARY KEY | |
organism_id | integer | UNIQUE#1 NOT NULL | |
name | character varying(255) | ||
uniquename | text | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL The type_id foreign key links to a controlled vocabulary of library types. Examples of this would be: "cDNA_library" or "genomic_library" |
Tables referencing this one via Foreign Key Constraints:
Table: library_cvterm
The table library_cvterm links a library to controlled vocabularies which describe the library. For instance, there might be a link to the anatomy cv for "head" or "testes" for a head or testes library.
F-Key | Name | Type | Description |
---|---|---|---|
library_cvterm_id | serial | PRIMARY KEY | |
library_id | integer | UNIQUE#1 NOT NULL | |
cvterm_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: library_feature
library_feature links a library to the clones which are contained in the library. Examples of such linked features might be "cDNA_clone" or "genomic_clone".
F-Key | Name | Type | Description |
---|---|---|---|
library_feature_id | serial | PRIMARY KEY | |
library_id | integer | UNIQUE#1 NOT NULL | |
feature_id | integer | UNIQUE#1 NOT NULL |
Table: library_pub
F-Key | Name | Type | Description |
---|---|---|---|
library_pub_id | serial | PRIMARY KEY | |
library_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: library_synonym
F-Key | Name | Type | Description |
---|---|---|---|
library_synonym_id | serial | PRIMARY KEY | |
synonym_id | integer | UNIQUE#1 NOT NULL | |
library_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL The pub_id link is for relating the usage of a given synonym to the publication in which it was used. | |
is_current | boolean | NOT NULL DEFAULT true The is_current bit indicates whether the linked synonym is the current -official- symbol for the linked library. | |
is_internal | boolean | NOT NULL DEFAULT false Typically a synonym exists so that somebody querying the database with an obsolete name can find the object they are looking for under its current name. If the synonym has been used publicly and deliberately (e.g. in a paper), it my also be listed in reports as a synonym. If the synonym was not used deliberately (e.g., there was a typo which went public), then the is_internal bit may be set to "true" so that it is known that the synonym is "internal" and should be queryable but should not be listed in reports as a valid synonym. |
Table: libraryprop
F-Key | Name | Type | Description |
---|---|---|---|
libraryprop_id | serial | PRIMARY KEY | |
library_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | ||
rank | integer | UNIQUE#1 NOT NULL |
Table: contact
Model persons, institutes, groups, organizations, etc.
F-Key | Name | Type | Description |
---|---|---|---|
contact_id | serial | PRIMARY KEY | |
type_id | integer | What type of contact is this? E.g. "person", "lab". | |
name | character varying(255) | UNIQUE NOT NULL | |
description | character varying(255) |
Tables referencing this one via Foreign Key Constraints:
Table: contact_relationship
Model relationships between contacts
F-Key | Name | Type | Description |
---|---|---|---|
contact_relationship_id | serial | PRIMARY KEY | |
type_id | integer | UNIQUE#1 NOT NULL Relationship type between subject and object. This is a cvterm, typically from the OBO relationship ontology, although other relationship types are allowed. | |
subject_id | integer | UNIQUE#1 NOT NULL The subject of the subj-predicate-obj sentence. In a DAG, this corresponds to the child node. | |
object_id | integer | UNIQUE#1 NOT NULL The object of the subj-predicate-obj sentence. In a DAG, this corresponds to the parent node. |
Table: stock
Any stock can be globally identified by the combination of organism, uniquename and stock type. A stock is the physical entities, either living or preserved, held by collections. Stocks belong to a collection; they have IDs, type, organism, description and may have a genotype.
F-Key | Name | Type | Description |
---|---|---|---|
stock_id | serial | PRIMARY KEY | |
dbxref_id | integer | The dbxref_id is an optional primary stable identifier for this stock. Secondary indentifiers and external dbxrefs go in table: stock_dbxref. | |
organism_id | integer | UNIQUE#1 NOT NULL The organism_id is the organism to which the stock belongs. This column is mandatory. | |
name | character varying(255) | The name is a human-readable local name for a stock. | |
uniquename | text | UNIQUE#1 NOT NULL | |
description | text | The description is the genetic description provided in the stock list. | |
type_id | integer | UNIQUE#1 NOT NULL The type_id foreign key links to a controlled vocabulary of stock types. The would include living stock, genomic DNA, preserved specimen. Secondary cvterms for stocks would go in stock_cvterm. | |
is_obsolete | boolean | NOT NULL DEFAULT false |
Tables referencing this one via Foreign Key Constraints:
Table: stock_cvterm
stock_cvterm links a stock to cvterms. This is for secondary cvterms; primary cvterms should use stock.type_id.
F-Key | Name | Type | Description |
---|---|---|---|
stock_cvterm_id | serial | PRIMARY KEY | |
stock_id | integer | UNIQUE#1 NOT NULL | |
cvterm_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: stock_dbxref
stock_dbxref links a stock to dbxrefs. This is for secondary identifiers; primary identifiers should use stock.dbxref_id.
F-Key | Name | Type | Description |
---|---|---|---|
stock_dbxref_id | serial | PRIMARY KEY | |
stock_id | integer | UNIQUE#1 NOT NULL | |
dbxref_id | integer | UNIQUE#1 NOT NULL | |
is_current | boolean | NOT NULL DEFAULT true The is_current boolean indicates whether the linked dbxref is the current -official- dbxref for the linked stock. |
Table: stock_genotype
Simple table linking a stock to a genotype. Features with genotypes can be linked to stocks thru feature_genotype -> genotype -> stock_genotype -> stock.
F-Key | Name | Type | Description |
---|---|---|---|
stock_genotype_id | serial | PRIMARY KEY | |
stock_id | integer | UNIQUE#1 NOT NULL | |
genotype_id | integer | UNIQUE#1 NOT NULL |
Table: stock_pub
Provenance. Linking table between stocks and, for example, a stocklist computer file.
F-Key | Name | Type | Description |
---|---|---|---|
stock_pub_id | serial | PRIMARY KEY | |
stock_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: stock_relationship
F-Key | Name | Type | Description |
---|---|---|---|
stock_relationship_id | serial | PRIMARY KEY | |
subject_id | integer | UNIQUE#1 NOT NULL | |
object_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | ||
rank | integer | UNIQUE#1 NOT NULL |
Tables referencing this one via Foreign Key Constraints:
Table: stock_relationship_pub
Provenance. Attach optional evidence to a stock_relationship in the form of a publication.
F-Key | Name | Type | Description |
---|---|---|---|
stock_relationship_pub_id | serial | PRIMARY KEY | |
stock_relationship_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: stockcollection
The lab or stock center distributing the stocks in their collection.
F-Key | Name | Type | Description |
---|---|---|---|
stockcollection_id | serial | PRIMARY KEY | |
type_id | integer | UNIQUE#1 NOT NULL type_id is the collection type cv. | |
contact_id | integer | contact_id links to the contact information for the collection. | |
name | character varying(255) | name is the collection. | |
uniquename | text | UNIQUE#1 NOT NULL uniqename is the value of the collection cv. |
Tables referencing this one via Foreign Key Constraints:
Table: stockcollection_stock
stockcollection_stock links a stock collection to the stocks which are contained in the collection.
F-Key | Name | Type | Description |
---|---|---|---|
stockcollection_stock_id | serial | PRIMARY KEY | |
stockcollection_id | integer | UNIQUE#1 NOT NULL | |
stock_id | integer | UNIQUE#1 NOT NULL |
Table: stockcollectionprop
The table stockcollectionprop contains the value of the stock collection such as website/email URLs; the value of the stock collection order URLs.
F-Key | Name | Type | Description |
---|---|---|---|
stockcollectionprop_id | serial | PRIMARY KEY | |
stockcollection_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | ||
rank | integer | UNIQUE#1 NOT NULL |
Table: stockprop
A stock 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. There is a unique constraint, stockprop_c1, for the combination of stock_id, rank, and type_id. Multivalued property-value pairs must be differentiated by rank.
F-Key | Name | Type | Description |
---|---|---|---|
stockprop_id | serial | PRIMARY KEY | |
stock_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | ||
rank | integer | UNIQUE#1 NOT NULL |
Tables referencing this one via Foreign Key Constraints:
Table: stockprop_pub
Provenance. Any stockprop assignment can optionally be supported by a publication.
F-Key | Name | Type | Description |
---|---|---|---|
stockprop_pub_id | serial | PRIMARY KEY | |
stockprop_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: environment
The environmental component of a phenotype description
F-Key | Name | Type | Description |
---|---|---|---|
environment_id | serial | PRIMARY KEY | |
uniquename | text | UNIQUE NOT NULL | |
description | text |
Tables referencing this one via Foreign Key Constraints:
Table: environment_cvterm
F-Key | Name | Type | Description |
---|---|---|---|
environment_cvterm_id | serial | PRIMARY KEY | |
environment_id | integer | UNIQUE#1 NOT NULL | |
cvterm_id | integer | UNIQUE#1 NOT NULL |
Table: feature_genotype
F-Key | Name | Type | Description |
---|---|---|---|
feature_genotype_id | serial | PRIMARY KEY | |
feature_id | integer | UNIQUE#1 NOT NULL | |
genotype_id | integer | UNIQUE#1 NOT NULL | |
chromosome_id | integer | UNIQUE#1 A feature of SO type "chromosome". | |
rank | integer | UNIQUE#1 NOT NULL rank can be used for n-ploid organisms or to preserve order. | |
cgroup | integer | UNIQUE#1 NOT NULL Spatially distinguishable group. group can be used for distinguishing the chromosomal groups, for example (RNAi products and so on can be treated as different groups, as they do not fall on a particular chromosome). | |
cvterm_id | integer | UNIQUE#1 NOT NULL |
Table: genotype
Genetic context. A genotype is defined by a collection of features, mutations, balancers, deficiencies, haplotype blocks, or engineered constructs
F-Key | Name | Type | Description |
---|---|---|---|
genotype_id | serial | PRIMARY KEY | |
name | text | Optional alternative name for a genotype, for display purposes. | |
uniquename | text | UNIQUE NOT NULL The unique name for a genotype; typically derived from the features making up the genotype. | |
description | character varying(255) |
Tables referencing this one via Foreign Key Constraints:
Table: phendesc
A summary of a _set_ of phenotypic statements for any one gcontext made in any one publication.
F-Key | Name | Type | Description |
---|---|---|---|
phendesc_id | serial | PRIMARY KEY | |
genotype_id | integer | UNIQUE#1 NOT NULL | |
environment_id | integer | UNIQUE#1 NOT NULL | |
description | text | NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: phenotype_comparison
Comparison of phenotypes e.g., genotype1/environment1/phenotype1 "non-suppressible" with respect to genotype2/environment2/phenotype2
F-Key | Name | Type | Description |
---|---|---|---|
phenotype_comparison_id | serial | PRIMARY KEY | |
genotype1_id | integer | UNIQUE#1 NOT NULL | |
environment1_id | integer | UNIQUE#1 NOT NULL | |
genotype2_id | integer | UNIQUE#1 NOT NULL | |
environment2_id | integer | UNIQUE#1 NOT NULL | |
phenotype1_id | integer | UNIQUE#1 NOT NULL | |
phenotype2_id | integer | ||
type_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: phenstatement
Phenotypes are things like "larval lethal". Phenstatements are things like "dpp-1 is recessive larval lethal". So essentially phenstatement is a linking table expressing the relationship between genotype, environment, and phenotype.
F-Key | Name | Type | Description |
---|---|---|---|
phenstatement_id | serial | PRIMARY KEY | |
genotype_id | integer | UNIQUE#1 NOT NULL | |
environment_id | integer | UNIQUE#1 NOT NULL | |
phenotype_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: acquisition
This represents the scanning of hybridized material. The output of this process is typically a digital image of an array.
F-Key | Name | Type | Description |
---|---|---|---|
acquisition_id | serial | PRIMARY KEY | |
assay_id | integer | NOT NULL | |
protocol_id | integer | ||
channel_id | integer | ||
acquisitiondate | timestamp without time zone | DEFAULT ('now'::text)::timestamp(6) with time zone | |
name | text | UNIQUE | |
uri | text |
Tables referencing this one via Foreign Key Constraints:
Table: acquisition_relationship
Multiple monochrome images may be merged to form a multi-color image. Red-green images of 2-channel hybridizations are an example of this.
F-Key | Name | Type | Description |
---|---|---|---|
acquisition_relationship_id | serial | PRIMARY KEY | |
subject_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
object_id | integer | UNIQUE#1 NOT NULL | |
value | text | ||
rank | integer | UNIQUE#1 NOT NULL |
Table: acquisitionprop
Parameters associated with image acquisition.
F-Key | Name | Type | Description |
---|---|---|---|
acquisitionprop_id | serial | PRIMARY KEY | |
acquisition_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | ||
rank | integer | UNIQUE#1 NOT NULL |
Table: arraydesign
General properties about an array. An array is a template used to generate physical slides, etc. It contains layout information, as well as global array properties, such as material (glass, nylon) and spot dimensions (in rows/columns).
F-Key | Name | Type | Description |
---|---|---|---|
arraydesign_id | serial | PRIMARY KEY | |
manufacturer_id | integer | NOT NULL | |
platformtype_id | integer | NOT NULL | |
substratetype_id | integer | ||
protocol_id | integer | ||
dbxref_id | integer | ||
name | text | UNIQUE NOT NULL | |
version | text | ||
description | text | ||
array_dimensions | text | ||
element_dimensions | text | ||
num_of_elements | integer | ||
num_array_columns | integer | ||
num_array_rows | integer | ||
num_grid_columns | integer | ||
num_grid_rows | integer | ||
num_sub_columns | integer | ||
num_sub_rows | integer |
Tables referencing this one via Foreign Key Constraints:
Table: arraydesignprop
Extra array design properties that are not accounted for in arraydesign.
F-Key | Name | Type | Description |
---|---|---|---|
arraydesignprop_id | serial | PRIMARY KEY | |
arraydesign_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | ||
rank | integer | UNIQUE#1 NOT NULL |
Table: assay
An assay consists of a physical instance of an array, combined with the conditions used to create the array (protocols, technician information). The assay can be thought of as a hybridization.
F-Key | Name | Type | Description |
---|---|---|---|
assay_id | serial | PRIMARY KEY | |
arraydesign_id | integer | NOT NULL | |
protocol_id | integer | ||
assaydate | timestamp without time zone | DEFAULT ('now'::text)::timestamp(6) with time zone | |
arrayidentifier | text | ||
arraybatchidentifier | text | ||
operator_id | integer | NOT NULL | |
dbxref_id | integer | ||
name | text | UNIQUE | |
description | text |
Tables referencing this one via Foreign Key Constraints:
Table: assay_biomaterial
A biomaterial can be hybridized many times (technical replicates), or combined with other biomaterials in a single hybridization (for two-channel arrays).
F-Key | Name | Type | Description |
---|---|---|---|
assay_biomaterial_id | serial | PRIMARY KEY | |
assay_id | integer | UNIQUE#1 NOT NULL | |
biomaterial_id | integer | UNIQUE#1 NOT NULL | |
channel_id | integer | UNIQUE#1 | |
rank | integer | UNIQUE#1 NOT NULL |
Table: assay_project
Link assays to projects.
F-Key | Name | Type | Description |
---|---|---|---|
assay_project_id | serial | PRIMARY KEY | |
assay_id | integer | UNIQUE#1 NOT NULL | |
project_id | integer | UNIQUE#1 NOT NULL |
Table: assayprop
Extra assay properties that are not accounted for in assay.
F-Key | Name | Type | Description |
---|---|---|---|
assayprop_id | serial | PRIMARY KEY | |
assay_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | ||
rank | integer | UNIQUE#1 NOT NULL |
Table: biomaterial
A biomaterial represents the MAGE concept of BioSource, BioSample, and LabeledExtract. It is essentially some biological material (tissue, cells, serum) that may have been processed. Processed biomaterials should be traceable back to raw biomaterials via the biomaterialrelationship table.
F-Key | Name | Type | Description |
---|---|---|---|
biomaterial_id | serial | PRIMARY KEY | |
taxon_id | integer | ||
biosourceprovider_id | integer | ||
dbxref_id | integer | ||
name | text | UNIQUE | |
description | text |
Tables referencing this one via Foreign Key Constraints:
Table: biomaterial_dbxref
F-Key | Name | Type | Description |
---|---|---|---|
biomaterial_dbxref_id | serial | PRIMARY KEY | |
biomaterial_id | integer | UNIQUE#1 NOT NULL | |
dbxref_id | integer | UNIQUE#1 NOT NULL |
Table: biomaterial_relationship
Relate biomaterials to one another. This is a way to track a series of treatments or material splits/merges, for instance.
F-Key | Name | Type | Description |
---|---|---|---|
biomaterial_relationship_id | serial | PRIMARY KEY | |
subject_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
object_id | integer | UNIQUE#1 NOT NULL |
Table: biomaterial_treatment
Link biomaterials to treatments. Treatments have an order of operations (rank), and associated measurements (unittype_id, value).
F-Key | Name | Type | Description |
---|---|---|---|
biomaterial_treatment_id | serial | PRIMARY KEY | |
biomaterial_id | integer | UNIQUE#1 NOT NULL | |
treatment_id | integer | UNIQUE#1 NOT NULL | |
unittype_id | integer | ||
value | real | ||
rank | integer | NOT NULL |
Table: biomaterialprop
Extra biomaterial properties that are not accounted for in biomaterial.
F-Key | Name | Type | Description |
---|---|---|---|
biomaterialprop_id | serial | PRIMARY KEY | |
biomaterial_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | ||
rank | integer | UNIQUE#1 NOT NULL |
Table: channel
Different array platforms can record signals from one or more channels (cDNA arrays typically use two CCD, but Affymetrix uses only one).
F-Key | Name | Type | Description |
---|---|---|---|
channel_id | serial | PRIMARY KEY | |
name | text | UNIQUE NOT NULL | |
definition | text | NOT NULL |
Tables referencing this one via Foreign Key Constraints:
Table: control
F-Key | Name | Type | Description |
---|---|---|---|
control_id | serial | PRIMARY KEY | |
type_id | integer | NOT NULL | |
assay_id | integer | NOT NULL | |
tableinfo_id | integer | NOT NULL | |
row_id | integer | NOT NULL | |
name | text | ||
value | text | ||
rank | integer | NOT NULL |
Table: element
Represents a feature of the array. This is typically a region of the array coated or bound to DNA.
F-Key | Name | Type | Description |
---|---|---|---|
element_id | serial | PRIMARY KEY | |
feature_id | integer | UNIQUE#1 | |
arraydesign_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | ||
dbxref_id | integer |
Tables referencing this one via Foreign Key Constraints:
Table: element_relationship
Sometimes we want to combine measurements from multiple elements to get a composite value. Affymetrix combines many probes to form a probeset measurement, for instance.
F-Key | Name | Type | Description |
---|---|---|---|
element_relationship_id | serial | PRIMARY KEY | |
subject_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
object_id | integer | UNIQUE#1 NOT NULL | |
value | text | ||
rank | integer | UNIQUE#1 NOT NULL |
Table: elementresult
An element on an array produces a measurement when hybridized to a biomaterial (traceable through quantification_id). This is the base data from which tables that actually contain data inherit.
F-Key | Name | Type | Description |
---|---|---|---|
elementresult_id | serial | PRIMARY KEY | |
element_id | integer | UNIQUE#1 NOT NULL | |
quantification_id | integer | UNIQUE#1 NOT NULL | |
signal | double precision | NOT NULL |
Tables referencing this one via Foreign Key Constraints:
Table: elementresult_relationship
Sometimes we want to combine measurements from multiple elements to get a composite value. Affymetrix combines many probes to form a probeset measurement, for instance.
F-Key | Name | Type | Description |
---|---|---|---|
elementresult_relationship_id | serial | PRIMARY KEY | |
subject_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
object_id | integer | UNIQUE#1 NOT NULL | |
value | text | ||
rank | integer | UNIQUE#1 NOT NULL |
Table: magedocumentation
F-Key | Name | Type | Description |
---|---|---|---|
magedocumentation_id | serial | PRIMARY KEY | |
mageml_id | integer | NOT NULL | |
tableinfo_id | integer | NOT NULL | |
row_id | integer | NOT NULL | |
mageidentifier | text | NOT NULL |
Table: mageml
This table is for storing extra bits of MAGEml in a denormalized form. More normalization would require many more tables.
F-Key | Name | Type | Description |
---|---|---|---|
mageml_id | serial | PRIMARY KEY | |
mage_package | text | NOT NULL | |
mage_ml | text | NOT NULL |
Tables referencing this one via Foreign Key Constraints:
Table: protocol
Procedural notes on how data was prepared and processed.
F-Key | Name | Type | Description |
---|---|---|---|
protocol_id | serial | PRIMARY KEY | |
type_id | integer | NOT NULL | |
pub_id | integer | ||
dbxref_id | integer | ||
name | text | UNIQUE NOT NULL | |
uri | text | ||
protocoldescription | text | ||
hardwaredescription | text | ||
softwaredescription | text |
Tables referencing this one via Foreign Key Constraints:
Table: protocolparam
Parameters related to a protocol. For example, if the protocol is a soak, this might include attributes of bath temperature and duration.
F-Key | Name | Type | Description |
---|---|---|---|
protocolparam_id | serial | PRIMARY KEY | |
protocol_id | integer | NOT NULL | |
name | text | NOT NULL | |
datatype_id | integer | ||
unittype_id | integer | ||
value | text | ||
rank | integer | NOT NULL |
Table: quantification
Quantification is the transformation of an image acquisition to numeric data. This typically involves statistical procedures.
F-Key | Name | Type | Description |
---|---|---|---|
quantification_id | serial | PRIMARY KEY | |
acquisition_id | integer | NOT NULL | |
operator_id | integer | ||
protocol_id | integer | ||
analysis_id | integer | UNIQUE#1 NOT NULL | |
quantificationdate | timestamp without time zone | DEFAULT ('now'::text)::timestamp(6) with time zone | |
name | text | UNIQUE#1 | |
uri | text |
Tables referencing this one via Foreign Key Constraints:
Table: quantification_relationship
There may be multiple rounds of quantification, this allows us to keep an audit trail of what values went where.
F-Key | Name | Type | Description |
---|---|---|---|
quantification_relationship_id | serial | PRIMARY KEY | |
subject_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
object_id | integer | UNIQUE#1 NOT NULL |
Table: quantificationprop
Extra quantification properties that are not accounted for in quantification.
F-Key | Name | Type | Description |
---|---|---|---|
quantificationprop_id | serial | PRIMARY KEY | |
quantification_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | ||
rank | integer | UNIQUE#1 NOT NULL |
Table: study
F-Key | Name | Type | Description |
---|---|---|---|
study_id | serial | PRIMARY KEY | |
contact_id | integer | NOT NULL | |
pub_id | integer | ||
dbxref_id | integer | ||
name | text | UNIQUE NOT NULL | |
description | text |
Tables referencing this one via Foreign Key Constraints:
Table: study_assay
F-Key | Name | Type | Description |
---|---|---|---|
study_assay_id | serial | PRIMARY KEY | |
study_id | integer | UNIQUE#1 NOT NULL | |
assay_id | integer | UNIQUE#1 NOT NULL |
Table: studydesign
F-Key | Name | Type | Description |
---|---|---|---|
studydesign_id | serial | PRIMARY KEY | |
study_id | integer | NOT NULL | |
description | text |
Tables referencing this one via Foreign Key Constraints:
Table: studydesignprop
F-Key | Name | Type | Description |
---|---|---|---|
studydesignprop_id | serial | PRIMARY KEY | |
studydesign_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | ||
rank | integer | UNIQUE#1 NOT NULL |
Table: studyfactor
F-Key | Name | Type | Description |
---|---|---|---|
studyfactor_id | serial | PRIMARY KEY | |
studydesign_id | integer | NOT NULL | |
type_id | integer | ||
name | text | NOT NULL | |
description | text |
Tables referencing this one via Foreign Key Constraints:
Table: studyfactorvalue
F-Key | Name | Type | Description |
---|---|---|---|
studyfactorvalue_id | serial | PRIMARY KEY | |
studyfactor_id | integer | NOT NULL | |
assay_id | integer | NOT NULL | |
factorvalue | text | ||
name | text | ||
rank | integer | NOT NULL |
Table: treatment
A biomaterial may undergo multiple treatments. Examples of treatments: apoxia, fluorophore and biotin labeling.
F-Key | Name | Type | Description |
---|---|---|---|
treatment_id | serial | PRIMARY KEY | |
rank | integer | NOT NULL | |
biomaterial_id | integer | NOT NULL | |
type_id | integer | NOT NULL | |
protocol_id | integer | ||
name | text |
Tables referencing this one via Foreign Key Constraints:
Table: featuremap
F-Key | Name | Type | Description |
---|---|---|---|
featuremap_id | serial | PRIMARY KEY | |
name | character varying(255) | UNIQUE | |
description | text | ||
unittype_id | integer |
Tables referencing this one via Foreign Key Constraints:
Table: featuremap_pub
F-Key | Name | Type | Description |
---|---|---|---|
featuremap_pub_id | serial | PRIMARY KEY | |
featuremap_id | integer | NOT NULL | |
pub_id | integer | NOT NULL |
Table: featurepos
F-Key | Name | Type | Description |
---|---|---|---|
featurepos_id | serial | PRIMARY KEY | |
featuremap_id | serial | NOT NULL | |
feature_id | integer | NOT NULL | |
map_feature_id | integer | NOT NULL map_feature_id links to the feature (map) upon which the feature is being localized | |
mappos | double precision | NOT NULL |
Table: featurerange
In cases where the start and end of a mapped feature is a range, leftendf and rightstartf are populated. leftstartf_id, leftendf_id, rightstartf_id, rightendf_id are the ids of features with respect to which the feature is being mapped. These may be cytological bands.
F-Key | Name | Type | Description |
---|---|---|---|
featurerange_id | serial | PRIMARY KEY | |
featuremap_id | integer | NOT NULL featuremap_id is the id of the feature being mapped. | |
feature_id | integer | NOT NULL | |
leftstartf_id | integer | NOT NULL | |
leftendf_id | integer | ||
rightstartf_id | integer | ||
rightendf_id | integer | NOT NULL | |
rangestr | character varying(255) |
Table: analysis
An analysis is a particular type of a computational analysis; it may be a blast of one sequence against another, or an all by all blast, or a different kind of analysis altogether. It is a single unit of computation.
F-Key | Name | Type | Description |
---|---|---|---|
analysis_id | serial | PRIMARY KEY | |
name | character varying(255) | A way of grouping analyses. This should be a handy short identifier that can help people find an analysis they want. For instance "tRNAscan", "cDNA", "FlyPep", "SwissProt", and it should not be assumed to be unique. For instance, there may be lots of separate analyses done against a cDNA database. | |
description | text | ||
program | character varying(255) | UNIQUE#1 NOT NULL Program name, e.g. blastx, blastp, sim4, genscan. | |
programversion | character varying(255) | UNIQUE#1 NOT NULL Version description, e.g. TBLASTX 2.0MP-WashU [09-Nov-2000]. | |
algorithm | character varying(255) | Algorithm name, e.g. blast. | |
sourcename | character varying(255) | UNIQUE#1 Source name, e.g. cDNA, SwissProt. | |
sourceversion | character varying(255) | ||
sourceuri | text | This is an optional, permanent URL or URI for the source of the analysis. The idea is that someone could recreate the analysis directly by going to this URI and fetching the source data (e.g. the blast database, or the training model). | |
timeexecuted | timestamp without time zone | NOT NULL DEFAULT ('now'::text)::timestamp(6) with time zone |
Tables referencing this one via Foreign Key Constraints:
Table: analysisfeature
Computational analyses generate features (e.g. Genscan generates transcripts and exons; sim4 alignments generate similarity/match features). analysisfeatures are stored using the feature table from the sequence module. The analysisfeature table is used to decorate these features, with analysis specific attributes. A feature is an analysisfeature if and only if there is a corresponding entry in the analysisfeature table. analysisfeatures will have two or more featureloc entries, with rank indicating query/subject
F-Key | Name | Type | Description |
---|---|---|---|
analysisfeature_id | serial | PRIMARY KEY | |
feature_id | integer | UNIQUE#1 NOT NULL | |
analysis_id | integer | UNIQUE#1 NOT NULL | |
rawscore | double precision | This is the native score generated by the program; for example, the bitscore generated by blast, sim4 or genscan scores. One should not assume that high is necessarily better than low. | |
normscore | double precision | This is the rawscore but semi-normalized. Complete normalization to allow comparison of features generated by different programs would be nice but too difficult. Instead the normalization should strive to enforce the following semantics: * normscores are floating point numbers >= 0, * high normscores are better than low one. For most programs, it would be sufficient to make the normscore the same as this rawscore, providing these semantics are satisfied. | |
significance | double precision | This is some kind of expectation or probability metric, representing the probability that the analysis would appear randomly given the model. As such, any program or person querying this table can assume the following semantics: * 0 <= significance <= n, where n is a positive number, theoretically unbounded but unlikely to be more than 10 * low numbers are better than high numbers. | |
identity | double precision | Percent identity between the locations compared. Note that these 4 metrics do not cover the full range of scores possible; it would be undesirable to list every score possible, as this should be kept extensible. instead, for non-standard scores, use the analysisprop table. |
Table: analysisprop
F-Key | Name | Type | Description |
---|---|---|---|
analysisprop_id | serial | PRIMARY KEY | |
analysis_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | UNIQUE#1 |
Table: eimage
F-Key | Name | Type | Description |
---|---|---|---|
eimage_id | serial | PRIMARY KEY | |
eimage_data | text | We expect images in eimage_data (e.g. JPEGs) to be uuencoded. | |
eimage_type | character varying(255) | NOT NULL Describes the type of data in eimage_data. | |
image_uri | character varying(255) |
Tables referencing this one via Foreign Key Constraints:
Table: expression
The expression table is essentially a bridge table.
F-Key | Name | Type | Description |
---|---|---|---|
expression_id | serial | PRIMARY KEY | |
uniquename | text | UNIQUE NOT NULL | |
md5checksum | character(32) | ||
description | text |
Tables referencing this one via Foreign Key Constraints:
Table: expression_cvterm
F-Key | Name | Type | Description |
---|---|---|---|
expression_cvterm_id | serial | PRIMARY KEY | |
expression_id | integer | UNIQUE#1 NOT NULL | |
cvterm_id | integer | UNIQUE#1 NOT NULL | |
rank | integer | NOT NULL | |
cvterm_type_id | integer | UNIQUE#1 NOT NULL |
Tables referencing this one via Foreign Key Constraints:
Table: expression_image
F-Key | Name | Type | Description |
---|---|---|---|
expression_image_id | serial | PRIMARY KEY | |
expression_id | integer | UNIQUE#1 NOT NULL | |
eimage_id | integer | UNIQUE#1 NOT NULL |
Table: expression_pub
F-Key | Name | Type | Description |
---|---|---|---|
expression_pub_id | serial | PRIMARY KEY | |
expression_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Table: feature_expression
F-Key | Name | Type | Description |
---|---|---|---|
feature_expression_id | serial | PRIMARY KEY | |
expression_id | integer | UNIQUE#1 NOT NULL | |
feature_id | integer | UNIQUE#1 NOT NULL | |
pub_id | integer | UNIQUE#1 NOT NULL |
Tables referencing this one via Foreign Key Constraints:
Table: feature_phenotype
F-Key | Name | Type | Description |
---|---|---|---|
feature_phenotype_id | serial | PRIMARY KEY | |
feature_id | integer | UNIQUE#1 NOT NULL | |
phenotype_id | integer | UNIQUE#1 NOT NULL |
Table: phenotype
A phenotypic statement, or a single atomic phenotypic observation is a controlled sentence describing observable effects of non-wild type function E.g. Obs=eye, attribute=color, cvalue=red
F-Key | Name | Type | Description |
---|---|---|---|
phenotype_id | serial | PRIMARY KEY | |
uniquename | text | UNIQUE NOT NULL | |
observable_id | integer | The entity: e.g. anatomy_part, biological_process. | |
attr_id | integer | Phenotypic attribute (quality, property, attribute, character) - drawn from PATO. | |
value | text | Value of attribute - unconstrained free text. Used only if cvalue_id is not appropriate. | |
cvalue_id | integer | Phenotype attribute value (state). | |
assay_id | integer | Evidence type |
Tables referencing this one via Foreign Key Constraints:
Table: phenotype_cvterm
F-Key | Name | Type | Description |
---|---|---|---|
phenotype_cvterm_id | serial | PRIMARY KEY | |
phenotype_id | integer | UNIQUE#1 NOT NULL | |
cvterm_id | integer | UNIQUE#1 NOT NULL |
Table: pub
A documented provenance artefact - publications, documents, personal communication.
F-Key | Name | Type | Description |
---|---|---|---|
pub_id | serial | PRIMARY KEY | |
title | text | Descriptive general heading. | |
volumetitle | text | Title of part if one of a series. | |
volume | character varying(255) | ||
series_name | character varying(255) | Full name of (journal) series. | |
issue | character varying(255) | ||
pyear | character varying(255) | ||
pages | character varying(255) | Page number range[s], e.g. 457--459, viii + 664pp, lv--lvii. | |
miniref | character varying(255) | ||
uniquename | text | UNIQUE NOT NULL | |
type_id | integer | NOT NULL The type of the publication (book, journal, poem, graffiti, etc). Uses pub cv. | |
is_obsolete | boolean | DEFAULT false | |
publisher | character varying(255) | ||
pubplace | character varying(255) |
Tables referencing this one via Foreign Key Constraints:
Table: pub_dbxref
Handle links to repositories, e.g. Pubmed, Biosis, zoorec, OCLC, Medline, ISSN, coden...
F-Key | Name | Type | Description |
---|---|---|---|
pub_dbxref_id | serial | PRIMARY KEY | |
pub_id | integer | UNIQUE#1 NOT NULL | |
dbxref_id | integer | UNIQUE#1 NOT NULL | |
is_current | boolean | NOT NULL DEFAULT true |
Table: pub_relationship
Handle relationships between publications, e.g. when one publication makes others obsolete, when one publication contains errata with respect to other publication(s), or when one publication also appears in another pub.
F-Key | Name | Type | Description |
---|---|---|---|
pub_relationship_id | serial | PRIMARY KEY | |
subject_id | integer | UNIQUE#1 NOT NULL | |
object_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL |
Table: pubauthor
An author for a publication. Note the denormalisation (hence lack of _ in table name) - this is deliberate as it is in general too hard to assign IDs to authors.
F-Key | Name | Type | Description |
---|---|---|---|
pubauthor_id | serial | PRIMARY KEY | |
pub_id | integer | UNIQUE#1 NOT NULL | |
rank | integer | UNIQUE#1 NOT NULL Order of author in author list for this pub - order is important. | |
editor | boolean | DEFAULT false Indicates whether the author is an editor for linked publication. Note: this is a boolean field but does not follow the normal chado convention for naming booleans. | |
surname | character varying(100) | NOT NULL | |
givennames | character varying(100) | First name, initials | |
suffix | character varying(100) | Jr., Sr., etc |
Table: pubprop
Property-value pairs for a pub. Follows standard chado pattern.
F-Key | Name | Type | Description |
---|---|---|---|
pubprop_id | serial | PRIMARY KEY | |
pub_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | NOT NULL | |
rank | integer | UNIQUE#1 |
Table: organism
The organismal taxonomic classification. Note that phylogenies are represented using the phylogeny module, and taxonomies can be represented using the cvterm module or the phylogeny module
F-Key | Name | Type | Description |
---|---|---|---|
organism_id | serial | PRIMARY KEY | |
abbreviation | character varying(255) | ||
genus | character varying(255) | UNIQUE#1 NOT NULL | |
species | character varying(255) | UNIQUE#1 NOT NULL A type of organism is always uniquely identified by genus and species. When mapping from the NCBI taxonomy names.dmp file, the unique-name column must be used where it is present, as the name column is not always unique (eg environmental samples). If a particular strain or subspecies is to be represented, this is appended onto the species name. Follows standard NCBI taxonomy pattern | |
common_name | character varying(255) | ||
comment | text |
Tables referencing this one via Foreign Key Constraints:
Table: organism_dbxref
F-Key | Name | Type | Description |
---|---|---|---|
organism_dbxref_id | serial | PRIMARY KEY | |
organism_id | integer | UNIQUE#1 NOT NULL | |
dbxref_id | integer | UNIQUE#1 NOT NULL |
Table: organism_relationship
F-Key | Name | Type | Description |
---|---|---|---|
organism_relationship_id | serial | PRIMARY KEY | |
subject_id | integer | UNIQUE#1 NOT NULL | |
object_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL |
Table: organismpath
F-Key | Name | Type | Description |
---|---|---|---|
organismpath_id | serial | PRIMARY KEY | |
subject_id | integer | UNIQUE#1 NOT NULL | |
object_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
pathdistance | integer | UNIQUE#1 |
Table: organismprop
Tag-value properties - follows standard chado model.
F-Key | Name | Type | Description |
---|---|---|---|
organismprop_id | serial | PRIMARY KEY | |
organism_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | ||
rank | integer | UNIQUE#1 NOT NULL |