Difference between revisions of "Chado Library Module"
m |
m |
||
Line 1: | Line 1: | ||
==Introduction== | ==Introduction== | ||
− | + | The library module is designed to store detailed information about molecular libraries. The library module uses the [[Chado_Sequence_Module|sequence module]], thus the library in question could be any collection of sequences that the [[Chado_Sequence_Module|sequence module]] can describe. It is expected that most of the description of a given library would come through the use of ontology terms. | |
+ | |||
Revision as of 13:16, 13 April 2007
Contents
Introduction
The library module is designed to store detailed information about molecular libraries. The library module uses the sequence module, thus the library in question could be any collection of sequences that the sequence module can describe. It is expected that most of the description of a given library would come through the use of ontology terms.
Tables
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 |