data_model

Data model

BrainSTEM is built upon a relational data model, as shown in the relational graph above. Click the graph to see it in full size.

Organization of the models

The model is structured into the following apps, each containing related models:

  • STEM: Core models for data management, including projects, subjects, sessions, collections, and cohorts.
  • Modules: Flexible containers for experimental conditions and data, covering procedures, equipment, data acquisition, and consumable stocks.
  • Personal attributes: Models for lab-specific elements such as setups, inventories, behavioral paradigms, and data storage.
  • Resources: Representing materials, equipment, and entities involved in research, including consumables, hardware devices, and suppliers.
  • Taxonomies: Standardized vocabularies and classification systems for neuroscience research.
  • Dissemination: Capturing information related to the publication and sharing of research findings.
  • Users: Managing authentication, authorization, and organizational structure on the platform.

Expandability, permissions, schemas

The data model is designed for expandability with structured permissions and standardized schemas to support flexible data integration.

  • Expandability: The model can incorporate new methods, techniques, data types, resources, and taxonomies while maintaining a standardized structure.
  • Permissions implementation and inheritance: Permissions are applied at the object level, inheriting from users, groups, projects, and personal attributes.
  • Schemas: Schemas define the structure and organization of data components, ensuring consistency across modules, resources, coordinate systems, and inter-model relationships.

Elements of the graph

Tables represent models, while lines represent connections between them. A fork indicates a one-to-many relationship, while forks on both ends indicate a many-to-many relationship. Some models, such as modules and consumables, have subtypes with shared relationships and fields but additional type-specific details.

  • Projects (pink table) serve as the root node connecting to Subjects, Sessions, Cohorts (set of Subjects), and Collections (set of Sessions). Projects can also link to Publications.
  • Subjects can have multiple Procedures, Subject Logs associated with it (green tables). Subjects are further described by their Strain.
  • Sessions can consist of Behaviors, Data Acquisition, Manipulations, and Epochs, representing the data collection and experimental conditions (blue tables).
  • Setups are described by the Equipment (orange and cream-colored tables).
  • Inventories consists of Consumable stocks (orange and cream-colored tables).
  • Data Storage (orange table) links to Sessions, representing where experimental data is archived.
  • Permission and Ownership are linked to Projects and to Personal attributes (grey tables). Learn more about the permissions implementation and inheritance below.

The model can be viewed in three vertical layers:

  1. Organization and Permissions Level
  2. Modules Level
  3. Backend Level (Taxonomies and Resources)

Example usage of the flexible modular design

The graph below illustrates how the data model can be applied to an extracellular recording session during a behavioral experiment involving a rat. Subject-related models are highlighted in green, while session-related models are in blue.

data_model_example