chado.cv Tables
| Table / View | Referenced | Foreign Keys | Columns | Type | Comments |
|---|---|---|---|---|---|
| chadoprop | 0 | 1 | 4 | Table | This table is different from other prop tables in the database, as it is for storing information about the database itself, like schema version |
| cv | 3 | 0 | 3 | Table | 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. |
| cvprop | 0 | 2 | 5 | Table | Additional extensible properties can be attached to a cv using this table. A notable example would be the cv version |
| cvterm | 122 | 2 | 7 | Table | 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. |
| cvterm_dbxref | 0 | 2 | 4 | Table | 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. |
| cvterm_relationship | 0 | 3 | 4 | Table | 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". |
| cvtermpath | 0 | 4 | 6 | Table | The reflexive transitive closure of the cvterm_relationship relation. |
| cvtermprop | 0 | 2 | 5 | Table | Additional extensible properties can be attached to a cvterm using this table. Corresponds to -AnnotationProperty- in W3C OWL format. |
| cvtermsynonym | 0 | 2 | 4 | Table | 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". |
| dbprop | 0 | 2 | 5 | Table | An external database 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, dbprop_c1, for the combination of db_id, rank, and type_id. Multivalued property-value pairs must be differentiated by rank. |
| dbxrefprop | 0 | 2 | 5 | Table | 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. |