Reicht die  Generische Speicherung nicht aus, lassen sich Modellelemente flexibel auf applikationsdefinierte Tabellen in Datenbank abbilden, vgl. Schema-Deklaration.

Klassen

Konkrete Klassen (TLClass) können über die Annotation <table name="..."/> auf Datenbanktabellen abgebildet werden:

<class name="MyClass">
   <annotations>
      <table name="MyTable"/>
   </annotations>
   <attributes>
      ...
   </attributes>
</class>

In obigem Beispiel werden alle Instanzen der Klasse MyClass in der Datenbanktabelle MyTable gespeichert.

Wird eine Klasse A in einer Tabelle T gespeichert, so werden automatisch alle primitiven Eigenschaften von A zu denen es Spalten mit demselben Namen in der Tabelle T gibt, in der entsprechenden Spalte von T gespeichert. Alle anderen Attribute verwenden weiterhin eine generische interne Tabelle für die Speicherung, siehe Generische Speicherung. Dies stellt sicher, dass das Modell zur Laufzeit erweitert werden kann, ohne die Tabellendefinition anpassen zu müssen.

Referenzen

Bei einer Referenz entscheidet die Speicherabbildung über die verwendete Tabelle. Wenn bei der Referenz nichts spezielles angegeben wird, verwendet die Engine eine generische Tabelle für die Speicherung der Referenz:

<class name="A">
   <attributes>
      <reference name="bs" type="B" />
   </attributes>
</class>

<class name="B">
   <attributes>
      ...
   </attributes>
</class>

Möchte man die Datenbankabbildung selbst bestimmen, hat man bei "zu eins" Referenzen (solche, die auf höchstens ein anderes Objekt zeigen, und somit nicht als multiple ausgezeichnet sind) zwei Möglichkeiten: Speicherung in einer separaten Link-Tabelle (singleton-link-storage) oder Speicherung als Fremdschlüssel (foreign-key-storage). Bei "zu-n" Referenzen (solche, die als "multiple" ausgezeichnet sind) wird immer eine Link-Tabelle benötigt (list-storage oder set-storage).

Link Tabelle

Eine Link-Tabelle kann man bei den Speicherabbildungen list-storage und set-storage angeben (jeweils für geordnete oder ungeordnete Referenzen):

Z.B. legt die folgende Definition die Links bs von A nach B in die spezielle Link-Tabelle AB:

<class name="A">
   <attributes>
      <reference name="bs" type="B">
         <annotations>
            <storage-algorithm>
               <set-storage table="AB"/>
            </storage-algorithm>
         </annotations>
      </reference>
   </attributes>
</class>

Referenzen über Fremdschlüssel

"Zu-eins" Referenzen kann man auch "inline" als Fremdschlüssel in die Tabelle desjenigen Typs ablegen, der die Referenz enthält. In diesem Fall muss die Tabelle des Typs eine entsprechende Fremdschlüsselspalte definieren, vgl. Schema-Deklaration. Die Referenz muss den foreign-key-storage verwenden und darin angeben, in welche Fremdschlüsselspalte gespeichert werden soll. In diesem Fall gibt es keinen Defaultwert für den Spaltennamen, sondern dieser muss immer explizit angegeben werden. Aus technischen Gründen muss auch der Name der Tabelle, in der der Typ selbst gespeichert wird, in dem Fremdschlüsselattribut nochmals wiederholt werden:

<class name="A">
   <annotations>
      <table name="ATable"/>
   </annotations>

   <attributes>
      <reference name="bs" type="B">
         <annotations>
            <storage-algorithm>
               <foreign-key-storage
                  storage-attribute="bsKey"
                  storage-type="ATable"
               />
            </storage-algorithm>
         </annotations>
      </reference>
   </attributes>
</class>

Obige Deklaration gibt an, dass Instanzen von A in der Tabelle ATable gespeichert werden sollen. Die "zu-eins" Referenz bs soll in der Fremdschlüsselspalte bsKey gespeichert werden.

Gibt man bei Referenzen keinen storage-algorithm an, wählt die Engine aufgrund der Referenzauszeichnung (multiple, ordered) eine passende Implementierung mit einer generischen Tabelle für die Speicherung.

Für die Definition von Datenbanktabellen und Fremdschlüsselspalten siehe Schema-Deklaration.