EnsemblEnsembl Home

Ensembl Regulation (Funcgen) Schema Documentation

Introduction

This document describes the tables that make up the Ensembl Regulation schema. Tables are grouped logically by their function, and the purpose of each table is explained. This document refers to version 86 of the Ensembl Regulation schema.
A simplified entity relationship diagram of the schema is available here. Core, core like and some ancilliary tables have been omitted


List of the tables:

Ancilliary tables

Main feature tables

These define the various genomics features and their relevant associated tables.

regulatory_feature

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

See also:

regulatory_evidence

Denormalised table defining links between a regulatory_feature and it's constituent 'attribute' features.

See also:

segmentation_feature

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

See also:

annotated_feature

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

See also:

The table contains genomic alignments of binding_matrix PWMs.

See also:

mirna_target_feature

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

See also:

associated_motif_feature

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

See also:

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

See also:

external_feature

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

See also:

The table contains genomic alignments probe entries.

See also:

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

See also:

associated_feature_type

Link table providing many to many mapping for feature_type entries.

See also:

Set tables

Sets are containers for distinct sets of raw and/or processed data.

Defines highest level data container for associating the result of an analysis and the input data to that analysis e.g. Seq alignments(Input/ResultSet) and peak calls (FeatureSet)

See also:

Defines association between data_set and underlying/supporting data.

See also:

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

See also:

feature_set_qc_prop_reads_in_peaks

See also:

Think of this as an alignment or a summary of an alignment in form of a wiggleplot in bigWig format. The query used to generate the alignment is found by linking from this table over result_set_input to the input_subset table. The entry in input_subset represents the fastq file that was aligned. The reference to which it was aligned is based on the sequence of the species of the regulation database. It may be gender specific depending on the use case, so the query may have been aligned to the male or the female version of the genome depending on the details of the analysis. Note that although the schema has objects to represent alignments, we don't store the actual alignments in the database. We only store summaries of the alignments as wiggleplots. If a result_set represents a wiggleplot, the location of the file can be found by the entry in the dbfile_registry pointing to it.

See also:

result_set_qc_chance

See also:

result_set_qc_flagstats

See also:

result_set_qc_phantom_peak

See also:

result_set_input

Many to many table for linking between result_set (alignments) and input_subset (fastq files). Fastq files are supporting sets for alignments and this table is used to link them up. The fastq files that are joined to the result_set in this table are the ones that were used to create the alignment.

See also:

This generic table contains a simple registry of paths to support flat file (DBFile) access. This should be left joined from the relevant adaptor e.g. ResultSetAdaptor.

See also:

The name is not descriptive of its content, think of it as: "Fastq files from a sequencing run". The objects stored here are similar to ENA's run: http://www.ebi.ac.uk/ena/submit/preparing-xmls#run Every row in the table represents a fastq file. Fastq files link to the experiments from which they were created. Fastq files from one experiment are grouped into technical and biological replicates. If a sequencing run from one experiment generated multiple fastq files, then the technical and biological replicate numbers will be identical. Fastq files are linked to the method by which they were generated via the analysis_id column.

See also:

Array design tables

Contains information defining an array or array set.

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

See also:

The table contains information about probe sets.

Defines individual probe designs across one or more array_chips. Note: The probe sequence is not stored.

See also:

Experiment tables

These define the experimental meta and raw data.

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

See also:

experimental_group

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

Ancilliary tables

These contain data types which are used across many of the above tables and are quite often denormalised to store generic associations to several table, this avoids the need for multiple sets of similar tables. Some of these tables have been omitted from the schema diagram.

The epigenomes known in Ensembl regulation.

Denormalised table associating funcgen records with a status.

See also:

Simple table to predefine name of status.

Core tables

These are exact clones of the corresponding core schema tables, hence have been omitted from the schema diagram. See core schema docs for more details.

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.

See also:

analysis_description

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

See also:

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.

See also:

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.

See also:

associated_group

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.

See also:

external_synonym

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

See also:

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

See also:

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

See also:

Describes the reason why a mapping failed.

See also:

Core like tables

These are almost exact clones of the corresponding core schema tables. Some contain extra fields or different enum values to support the funcgen schema. These have been omitted from the schema diagram.

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.

See also:

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.

See also:

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

See also:

Stores information about the available co-ordinate systems for the species identified through the species_id field. For each species, there must be one co-ordinate system that has the attribute "top_level" and one that has the attribute "sequence_level". NOTE: This has been extended from the core implementation to support multiple assemblies by referencing multiple core DBs.

See also:

Stores information about sequence regions from various core DBs.

See also: