Ensembl Regulation (Funcgen) Schema Documentation

The table contains the features resulting from the regulatory build process.

Links a regulatory feature and the epigenome (via regulatory activity) to the underlying structure of epigenetic marks that the regulatory feature has in this epigenome.

For every regulatory feature and epigenome that was a part of the regulatory build, this table links the regulatory feature to the predicted regulatory activity in this epigenome.

Metadata for the regulatory build

Table that links a regulatory build to the epigenomes that were used in it.

Represents a genomic segment feature as the result of an segmentation analysis i.e. Segway or ChromHmm

Table to store metadata about a segmentation file

Represents a genomic feature as the result of an analysis i.e. a ChIP or DNase1 peak call.

Represents a peak calling analysis.

The table contains genomic alignments of binding_matrix PWMs.

The table contains imports from externally curated resources e.g. cisRED, miRanda, VISTA, redFLY etc.

The table provides links between motif_features and annotated_features representing peaks of the relevant transcription factor.

Contains information defining a specific binding matrix(PWM) as defined by the linked analysis e.g. Jaspar.

The table contains imports from externally curated resources e.g. cisRED, miRanda, VISTA, redFLY etc.

Table to store metadata about a file with features

The table contains genomic alignments probe entries.

The table maps probe_features to transcripts.

Contains information about different types/classes of feature e.g. Brno nomenclature, Transcription Factor names etc.

Link table providing many to many mapping for feature_type entries.

Container for genomic features defined by the result of an analysis e.g. peaks calls or regulatory features.

Alignment of reads from a ChIP-seq or similar experiment

Linking table to connect alignments to the reads that were aligned.

Contains information defining an array or array set.

Represents the individual array chip design as part of an array or array set.

The table contains information about probe sets.

This table maps probe sets to transcripts.

Defines individual probe designs across one or more array_chips.

Probe sequences

This table maps probes to transcripts.

Represents a sequencing experiment. Sequencing runs (input_subsets) link to this.

Think: Consortium or laboratory that produced sequencing experiments (@see experiment).

The epigenomes known in Ensembl regulation.

Usually describes a program and some database that together are used to create a feature on a piece of sequence. Each feature is marked with an analysis_id. The most important column is logic_name, which is used by the webteam to render a feature correctly on contigview (or even retrieve the right feature). Logic_name is also used in the pipeline to identify the analysis which has to run in a given status of the pipeline. The module column tells the pipeline which Perl module does the whole analysis, typically a RunnableDB module.

Allows the storage of a textual description of the analysis, as well as a "display label", primarily for the EnsEMBL web site.

Stores data about the data in the current schema. Unlike other tables, data in the meta table is stored as key-value pairs. These data include details about the database, RegulatoryBuild and patches. The species_id field of the meta table is used in multi-species databases and makes it possible to have species-specific meta key-value pairs. The species-specific meta key-value pairs needs to be repeated for each species_id. Entries in the meta table that are not specific to any one species, such as the schema.version key and any other schema-related information must have their species_id field set to NULL . The default species_id, and the only species_id value allowed in single-species databases, is 1.

Describes which co-ordinate systems the different feature tables use.

This table associates extra associated annotations with a given ontology xref evidence and source under a specific condition. For GO this allows qualifiers (with/from) or annotation extensions to be added to a given ontology annotation.

Groups together xref associations under a single description. Used when more than one associated xref term must be used to describe a condition

Describes how well a particular xref object matches the EnsEMBL object.

Some xref objects can be referred to by more than one name. This table relates names to xref IDs.

Stores data about the external databases in which the objects described in the xref table are stored.

This table associates ontology terms/accessions to Ensembl objects (primarily EFO/SO). NOTE: Currently not in use

Describes the reason why a mapping failed.

Holds data about objects which are external to EnsEMBL, but need to be associated with EnsEMBL objects. Information about the database that the external object is stored in is held in the external_db table entry referred to by the external_db column.

Describes links between Ensembl objects and objects held in external databases. The Ensembl object can be one of several types; the type is held in the ensembl_object_type column. The ID of the particular Ensembl gene, translation or whatever is given in the ensembl_id column. The xref_id points to the entry in the xref table that holds data about the external object. Each Ensembl object can be associated with zero or more xrefs. An xref object can be associated with one or more Ensembl objects.

Describes why a particular external entity was not mapped to an ensembl one.