Data Model

Table of contents
  1. Overview
  2. Entity Hierarchy
  3. Key Relationships
    1. Space Programme → Mission
    2. Mission → Segment → System
    3. System → Payload (Instrument) and Platform
    4. Mission → Data Product → ECV
    5. Project and Programme
    6. Requirements Hierarchy
    7. Categories and Parameter Values
  4. Inheritance Model

Overview

EORSA-DB organizes Earth Observation data around a hierarchical domain model. The diagram below shows the main entities and their relationships.

Example data model diagram showing all entities and their relationships (UML or ER diagram)

Entity Hierarchy

The core data model follows this containment hierarchy:

Space Programme
├── Mission (1..*)
│   ├── Segment (1..*) ──── [Space | Launch | Ground]
│   │   └── System (1..*)
│   │       ├── Payload (Instrument) (0..*)
│   │       │   ├── Child Payloads (0..*)
│   │       │   ├── Equipment (0..*)
│   │       │   ├── SubSystem (0..*)
│   │       │   └── Spectral Bands (0..*)
│   │       ├── Platform (0..*)
│   │       │   ├── Equipment (0..*)
│   │       │   └── SubSystem (0..*)
│   │       └── Orbit Parameters
│   ├── Mission Phase (1..*)
│   │   └── Milestone (0..*)
│   ├── Data Product (0..*)
│   │   └── Essential Climate Variable (0..*)
│   ├── Auxiliary Product (0..*)
│   └── Requirement Specification (0..*)
│       └── Requirement Group (0..*)
│           ├── Requirement (0..*)
│           └── ECV Requirement (0..*)
│               └── Parametric Constraint (0..*)
├── Project (0..*)
│   └── Project Phase (0..*)
└── Organisation (0..*)

Key Relationships

Space Programme → Mission

A Space Programme is the top-level grouping entity. Each Programme contains one or more Missions and optionally Projects. Examples of Programmes include ESA’s Earth Explorer programme or Copernicus.

From Relationship To Cardinality
Space Programme contains Mission 1..*
Space Programme contains Project 0..*
Space Programme involves Organisation 0..*

Mission → Segment → System

A Mission is decomposed into Segments that represent major functional areas:

  • Space Segment: Satellites and orbital elements
  • Launch Segment: Launch vehicles and infrastructure
  • Ground Segment: Ground stations and data processing facilities

Each Segment contains one or more Systems, which are the top-level assemblages (e.g., a specific satellite).

From Relationship To Cardinality
Mission decomposes into Segment 1..*
Segment contains System 1..*
System has Orbit Parameters 1
System active during Mission Phase 0..*

System → Payload (Instrument) and Platform

Each System contains Elements, which can be either a Payload (instrument/sensor) or a Platform (spacecraft bus providing power, communications, navigation).

Payloads can be hierarchically nested — a Payload may contain child Payloads — and they define the Spectral Bands they cover.

Both Payloads and Platforms contain Equipment and SubSystems.

From Relationship To Cardinality
System contains Payload 0..*
System contains Platform 0..*
Payload contains Child Payload 0..* (hierarchical)
Payload has Spectral Band 0..*
Payload / Platform contains Equipment 0..*
Payload / Platform contains SubSystem 0..*
Equipment contains Child Equipment 0..* (hierarchical)

Mission → Data Product → ECV

Data Products represent the geophysical measurements produced by a Mission’s instruments. They have a processing level (L1, L2, L3, etc.) and are linked to the Equipment that measures them.

Data Products contribute to Essential Climate Variables (ECVs), which represent the physical, chemical, or biological variables relevant to characterizing Earth’s climate.

From Relationship To Cardinality
Mission produces Data Product 0..*
Data Product measured by Equipment 0..*
Data Product contributes to Essential Climate Variable 0..*
Data Product supported by Auxiliary Product 0..*
Mission has Auxiliary Product 0..*

Project and Programme

Projects represent coordinated activity sets with defined start and end dates. They exist within a Space Programme and may be linked to multiple Missions.

From Relationship To Cardinality
Space Programme contains Project 0..*
Project involves Mission 0..*
Project has lifecycle Project Phase 0..*

Requirements Hierarchy

Requirements in EORSA-DB follow a three-level hierarchy:

  1. Requirement Specification: The top-level document (e.g., a Mission Requirements Document), owned by a Mission.
  2. Requirement Group: A section or chapter within a specification. Groups can contain sub-groups.
  3. Requirement: An individual verifiable condition. Requirements may have Parametric Constraints — boolean expressions evaluated against parameter values.

ECV Requirements are a specialised type of Requirement used for Essential Climate Variable compliance checking.

Tree diagram showing Requirement Specification → Requirement Group → Requirement with Parametric Constraints

From Relationship To Cardinality
Mission has Requirement Specification 0..*
Requirement Specification contains Requirement Group 0..*
Requirement Group contains Requirement 0..*
Requirement Group contains ECV Requirement 0..*
Requirement has Parametric Constraint 0..*

Categories and Parameter Values

Categories form an acyclic hierarchy (via Super Categories) and can be assigned to most entities. Each Category defines Permissible Classes that control which entity types it can be applied to.

Parameter Values can be assigned to any categorizable entity. Each value is typed by a Parameter Type which determines the allowed data format (boolean, date, text, enumeration, quantity, etc.).

From Relationship To Cardinality
Category has super Category 0..* (acyclic)
Category defines Permissible Class 1..*
Any categorizable entity classified by Category 0..*
Any parameterizable entity has Parameter Value 0..*
Parameter Value typed by Parameter Type 1

Inheritance Model

All entities in EORSA-DB inherit from a common base:

IThing (root — has Iid, RevisionNumber, ClassKind)
├── IDefinedThing (adds Name, Definition, Attachments, Images, DataSource)
│   ├── ICategorizableThing (adds Category list, Permissible Classes)
│   │   └── ISimpleParameterizableThing (adds DataType, Parameter Values, Financial Transactions)
│   │       ├── Mission
│   │       ├── Project
│   │       ├── Segment
│   │       ├── Mission Phase
│   │       ├── Project Phase
│   │       ├── Space Programme
│   │       ├── Organisation
│   │       ├── Data Product
│   │       ├── Payload
│   │       ├── Platform
│   │       ├── Equipment
│   │       ├── System
│   │       └── Requirement
│   └── IParameterType (abstract — adds Symbol, NumberOfValues)
│       ├── Scalar Parameter Type
│       │   └── Boolean Parameter Type
│       └── Compound Parameter Type
│           └── Array Parameter Type
└── IRequirementsContainer
    └── Essential Climate Variable

This means all domain entities share common properties like Name, Definition, Categories, Parameter Values, and Attachments.