Wichtig im Zusammenhang mit der Struktur der Daten sind folgende Eigenschaften, anhand deren die hierarchisierten Elemente unterschieden werden können:
Die ‚bid‘ ordnet jedem Betrieb seine vollständigen Daten, inklusive des Namens zu.
Die ‚f_id‘ identifiziert jedes Feature. Außerdem können anhand der Feature-ID Daten identifiziert werden, die dem Feature zugeordnet sind.

Die Features im Ackerflächen-Layer besitzen sowohl Attribute, die innerhalb eines Intervalls von Jahren gültig sind und Attribute, die nur in einem bestimmten Jahr gültig sind. Um die sich wenig verändernden Intervall-Daten nicht mehrmals abspeichern zu müssen, wurden 2 Tabellen angelegt: Eine ist direkt dem Betrieb (Tabelle ‚betriebe‘) zugeordnet und heißt ‚fields‘, während die andere den ‚fields‘ zugeordnet ist und ‚invekos‘ heißt. Die ‚invekos‘-Daten besitzen eine eigene ID.
Bei Daten mit Jahresintervall sind Startjahr und Endjahr oft an der Beschriftung ‚creation‘ und ‚archivation‘ zu erkennen. Bei Angaben, die sich direkt auf das relevante Jahr beziehen, heißt das entsprechende Featur-Attribut ‚request_year‘.
Die ‚s_id‘ ermöglicht die Aufspaltung der Daten in verschiedene Versionen, je nach Simulation. Die realen Daten werden stets mit der s_id = 0 gekennzeichent.
Alle Spalten, die sich auf die Szenario-ID beziehen, referenzieren die Tabelle ‚szenarien‘ als Fremdschlüssel in der Datenbank:

Tabelle 'szenarien', Stand: 2015
Ein Betrieb kann nur einen Acker-Layer enthalten.
Ein Acker-Layer kann beliebig viele Features (die ‚fields‘ heißen) enthalten und ein bestimmtes Jahres-Intervall über gültig sind.
Ein ‚fields‘-Feature kann mehrere ‚invekos‘-Features enthalten und zwar maximal ein ‚invekos‘-Feature pro Jahr, das im ‚fields‘-Feature Jahres-Intervall liegt. Da ein ‚invekos‘-Feature immer nur für ein bestimmtes Jahr Gültigkeit besitzt.