Databases
AuraScore 79/100

Longitudinal Research Data Schema Strategy

Design a relational schema and data-retention strategy for multi-institutional scientific research datasets.

Use this template when planning a new longitudinal research database that requires strict provenance tracking and reproducible querying across institutions. It delivers an architectural brief covering schema normalization, participant pseudonymization, and audit trails.

Template

Role: Principal Research Data Architect specializing in FAIR-compliant longitudinal study infrastructures.

Context

  • Research Institution: {{institution_name}}
  • Scientific Domain: {{research_domain}}
  • Ingestion Cadence: {{data_collection_frequency}}
  • Compliance & Privacy Level: {{privacy_classification}}
  • Engine Platform: {{target_database_engine}}
  • Projected Record Volume: {{expected_record_volume}}

Task

Produce an architectural schema brief defining normalized relational table structures, pseudonymization boundaries, and partition strategies for {{institution_name}}'s {{research_domain}} program.

Method

  1. Analyze {{privacy_classification}} requirements to segregate directly identifiable participant information from observation records.
  2. Model core entity boundaries for participant cohorts, collection waves, instrument runs, and raw measurements based on {{data_collection_frequency}}.
  3. Define surrogate primary key generation standards and cross-institution namespace conventions.
  4. Design time-series and wave-based partitioning strategies tailored for {{target_database_engine}}.
  5. Establish audit logging structures to capture every insert, soft delete, and data transformation event.
  6. Specify foreign key constraints, cascading rules, and check constraints to preserve referential integrity without bottlenecks.
  7. Detail indexing strategies targeting cohort selection, longitudinal window functions, and time-range filters for {{expected_record_volume}}.
  8. Outline an immutable snapshotting and schema migration policy to maintain reproducibility across multi-year analyses.

Constraints

  • MUST isolate personally identifiable information into an encrypted, access-restricted schema boundary.
  • MUST NOT recommend database engines or proprietary extensions incompatible with {{target_database_engine}}.
  • Technical specifications must prioritize query reproducibility over hyper-aggressive denormalization.
  • Deliver the brief in technical markdown without narrative fluff or filler.

Output format

Longitudinal Research Data Schema Brief

1. Schema Topology & Entity Relationships

(Table definitions with primary/foreign keys and data types)

2. Partitioning & Storage Layout

(Partition key strategies and storage tiering)

3. Indexing & Query Acceleration

(Targeted indexes for longitudinal aggregations)

4. Compliance & Immutability Controls

(Audit schema, pseudonymization mapping, and versioning rules)

Self-review

  • Ensure every table definition accommodates the volume requirements of {{expected_record_volume}}.
  • Verify all participant identifiers adhere to {{privacy_classification}} isolation rules.
  • Confirm 6-9 actionable implementation details are present in the strategy.
AuraScore breakdown
79/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering10/12 · Adequate

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-databases
research-productivity-operations
databases
research
schema-design