Formate

Metadaten können mit dem Upload-API bzw. Download-API in unterschiedlichen Formaten importiert bzw. exportiert werden. Referenzen zwischen Metadatenobjekten werden über ihre fachlichen Schlüssel abgebildet. Reports können in gängigen Formaten generiert werden.

Hinweis

Die folgenden Trennzeichenregeln und die Vorgehensweise zum Erzeugen fachlicher Schlüssel gelten für Version 3. Frühere Versionen sind veraltet und können abweichende fachliche Schlüssel verwenden.

Fachlicher Schlüssel

Beim Upload oder Download werden Metadatenobjekte über ihre fachlichen Schlüssel identifiziert (im Gegensatz zur technischen UUID). Ein fachlicher Schlüssel wird aus einem oder mehreren Schlüsselwerten zusammengesetzt (meist Bezeichnungen, bei bestimmten Typen z.B. Codes oder Namen) und stellt einen eindeutigen, hierarchischen Pfad zu einem Metadatenobjekt dar. Fachliche Schlüssel werden in Beziehungen (z.B. inCollection, hasDomain) und Verknüpfungen (z.B. Herkünfte) verwendet, um Metadatenobjekte zu referenzieren.

Zum Beispiel, das Metadatenobjekt BusinessAttribute (im Format JSON) referenziert andere Metadatenobjekte über ihre eindeutigen fachlichen Schlüssel Rechnung und /Datentypen/Datum:

{
  "_type" : "BusinessAttribute",
  "hasDomain" : "Rechnung",
  "label" : "Buchungsdatum",
  "hasRange" : "/Datentypen/Datum"
}

Fachliche Schlüssel haben folgende Merkmale:

Die lokalen Schlüssel der einzelnen Metadatenobjekte werden bei zusammengesetzten fachlichen Schlüsseln durch / getrennt.
Falls das referenzierte Metadatenobjekt in einem anderen Modell liegt, dann beginnt der fachliche Schlüssel mit / und der Bezeichnung des Modells. Anderenfalls wird das Modell im fachlichen Schlüssel weggelassen.
Bei Metadatenobjekten, die nur innerhalb des übergeordneten Metadatenobjekts jedoch nicht im Modell eindeutig sein müssen (z.B. Subsammlungen, Subsysteme), muss das übergeordnete Metadatenobjekt (z.B. Sammlung, System) durch / getrennt vorangestellt werden.

Erklärung

Aus der letzten Regel ergibt sich, zum Beispiel:

Bei Subsammlungen, die nur innerhalb der übergeordneten Sammlung jedoch nicht im Modell eindeutig sein müssen, muss die übergeordnete Sammlung vorangestellt werden. Folglich müssen alle übergeordneten Sammlungen angegeben werden.
Bei Subsystemen, die nur innerhalb des übergeordneten Systems jedoch nicht im Systemkatalog eindeutig sein müssen, muss das übergeordnete System vorangestellt werden.
Bei technischen Metadatenobjekten (z.B. Datenobjekte, technische Datentypen oder Enumerationen), die nur innerhalb der übergeordneten Sammlung jedoch nicht im Datenmodell eindeutig sein müssen, muss die übergeordnete Sammlung vorangestellt werden.
Bei Geschäftsobjekten, die im Geschäftsobjektmodell eindeutig sein müssen, darf die übergeordnete Sammlung vorangestellt werden. Falls ja, dann müssen folglich alle übergeordneten Sammlungen ebenfalls angegeben werden (siehe oben).

Bezeichnungen	Fachlicher Schlüssel
`Adresse`	`Adresse`
`Fachdatenmodell`, `Person`	`/Fachdatenmodell/Person`
`Enterprise Model`, `Billing`, `Invoice`, `Date`	`/Enterprise Model/Billing/Invoice/Date`

Trennzeichen

In fachlichen Schlüsseln werden unterschiedliche Trennzeichen verwendet:

/ trennt die einzelnen Metadatenobjekte im hierarchischen Pfad.
Einige Typen bilden den lokalen fachlichen Schlüssel aus mehreren Werten, bevor dieser lokale Schlüssel als Teil des /-Pfads verwendet wird. Dabei gelten typspezifische Trennzeichen, z.B. . für Codes in hierarchischen Referenzwerten, > für Beziehungen und Überleitungen, # für Operationen sowie Leerzeichen für Personen.

Das jeweils relevante Trennzeichen ist / für Pfadsegmente und das typspezifische Trennzeichen für lokale Schlüssel. Falls in einem Wert eines Pfadsegments oder lokalen Schlüssels das jeweils relevante Trennzeichen oder das Zeichen " vorkommt, dann muss gekennzeichnet werden, dass es sich dabei um einen Teil des Werts und nicht um ein Trennzeichen des fachlichen Schlüssels handelt. Dazu wird der jeweilige Wert innerhalb des fachlichen Schlüssels in Anführungszeichen (") gesetzt. Jedes Anführungszeichen innerhalb des Werts wird verdoppelt.

Bezeichnungen	Fachlicher Schlüssel
`dataspot.`	`dataspot.`
`Technische Objekte`, `INPUT/OUTPUT`	`Technische Objekte/"INPUT/OUTPUT"`
`Datei bzw. Schnittstelle`, `Zeiterfassung`	`Datei bzw. Schnittstelle/Zeiterfassung`
`Datei bzw. Schnittstelle`, `Mitarbeiter.csv`	`Datei bzw. Schnittstelle/Mitarbeiter.csv`
`Kategorie`, `28" City Bike`	`Kategorie/"28"" City Bike"`
`Codename "Kronos"`	`"Codename ""Kronos"""`

Hinweis

Falls am Anfang (bzw. am Ende) einer Bezeichnung das Zeichen " vorkommt, dann ergibt sich aufgrund der beschriebenen Regeln, dass am Anfang (bzw. am Ende) der Bezeichnung im zusammengesetzten fachlichen Schlüssel drei Anführungszeichen (""") stehen. Zum Beispiel, die Bezeichnungen Projekte und Projekt "Zeus" werden zu Projekte/"Projekt ""Zeus""".

Typspezifische Trennzeichen

Bei einer Beziehung trennt > den Namen und die Zielklasse. Falls der Name selbst > oder " enthält, wird er zuerst im lokalen Schlüssel in Anführungszeichen gesetzt. Wird dieser lokale Schlüssel anschließend in den /-Pfad eingesetzt, werden diese Anführungszeichen erneut escaped:

Beziehung	Lokaler Schlüssel	Fachlicher Schlüssel
`Auto`, `hatBesitzer`, `Person`	`hatBesitzer>Person`	`Modell/Auto/hatBesitzer>Person`
`Interface`, `source>target`, `Mapping`	`"source>target">Mapping`	`Modell/Interface/"""source>target"">Mapping"`

Überleitungen, Operationen und Personen verwenden dieselbe Regel mit ihren eigenen typspezifischen Trennzeichen:

> für Überleitungen
# für Operationen
Leerzeichen für Personen

Falls ein Teil das jeweilige typspezifische Trennzeichen oder " enthält, wird nur dieser Teil zuerst in Anführungszeichen gesetzt. Falls der dadurch entstandene lokale Schlüssel anschließend in einen /-Pfadteil eingesetzt wird, werden seine Anführungszeichen erneut escaped.

Hinweis

Das typspezifische Trennzeichen ist immer nur für den jeweiligen Typ relevant. Zum Beispiel, > muss nur in lokalen Schlüsseln von Beziehungen und Überleitungen behandelt werden; in einem gewöhnlichen Pfadsegment ist > kein besonderes Zeichen.

Referenzwerte

Referenzwerte sind Metadatenobjekte unter einem Referenzobjekt. Daher besteht ihr fachlicher Schlüssel aus dem fachlichen Schlüssel des Referenzobjekts, einem / und dem Code des Referenzwerts. Bei hierarchischen Referenzwerten besteht der letzte Pfadteil aus einer Code-Kette: Die Code-Kette des übergeordneten Referenzwerts wird um den aktuellen Code ergänzt, getrennt durch ..

Referenzobjekt	Code	Übergeordneter Referenzwert	Fachlicher Schlüssel
`Level1`	`1`		`Level1/1`
`Level2`	`2`	`Level1/1`	`Level2/1.2`
`Level3`	`3.1`	`Level2/1.2`	`Level3/"1.2.""3.1"""`

Falls ein Code das Trennzeichen . oder das Zeichen " enthält, wird dieser Code innerhalb der Code-Kette in Anführungszeichen gesetzt. Wenn diese Code-Kette im vollständigen fachlichen Schlüssel als letzter /-Teil verwendet wird, werden ihre Anführungszeichen erneut escaped. Zum Beispiel wird der Referenzwert unter dem Referenzobjekt Referenzobjekt mit den Codes A.1 und B als Referenzobjekt/"""A.1"".B" abgebildet.

Vorgehensweise

Zum Erzeugen eines fachlichen Schlüssels gilt zusammenfassend:

Pfadsegmente und lokale Schlüssel bestimmen.
Lokale Schlüssel mit ihrem typspezifischen Trennzeichen bilden:
. für hierarchische Referenzwerte
> für Beziehungen und Überleitungen
# für Operationen
Leerzeichen für Personen
Nur Werte, die das jeweils relevante Trennzeichen oder " enthalten, in Anführungszeichen (") setzen.
Jedes Anführungszeichen innerhalb eines solchen Werts verdoppeln.
Die Pfadsegmente mit / verbinden.

Import/Export

Metadaten können in folgenden Formaten importiert bzw. exportiert werden:

XLSX (Microsoft Excel)
CSV (Gezippt)
XML
JSON
DDL/SQL
XSD (Gezippt)
JSON Schema (Gezippt)

Die Properties richten sich nach dem Modell, für welches Metadaten importiert bzw. exportiert werden, und bestehen aus allen Properties, die laut Metamodell standardmäßig definiert sind, ergänzt um alle kundenspezifischen Custom-Properties, die in der jeweiligen Datenbank konfiguriert sind.

Hinweis

Die Properties eines Modells in einem bestimmten Format können auch praktisch mittels Download in der Benutzeroberfläche im jeweiligen Format ermittelt werden.

Beziehungen zwischen Metadatenobjekten (z.B. inCollection, hasDomain) werden über fachliche Schlüssel dargestellt. Verknüpfungen zwischen Metadatenobjekten (z.B. Herkünfte) werden als eigene Objekte abgebildet:

Format	Verknüpfungen
`XLSX`	Verknüpfungen werden als fachliche Schlüssel in einer eigenen Tabelle abgebildet. Verknüpfungsattribute sind Spalten in dieser Tabelle.
`CSV`	Verknüpfungen werden als fachliche Schlüssel in einer eigenen CSV-Datei abgebildet. Verknüpfungsattribute sind Spalten in dieser CSV-Datei.
`XML`	Verknüpfungen werden als fachliche Schlüssel in einem eigenen XML-Element abgebildet. Verknüpfungsattribute sind untergeordnete XML-Elemente.
`JSON`	Verknüpfungen werden als fachliche Schlüssel in einem eigenen JSON-Objekt abgebildet. Verknüpfungsattribute sind JSON-Properties in diesem JSON-Objekt.

XLSX (Microsoft Excel)

Der Import/Export im Format XLSX (Microsoft Excel) ist ein Spreadsheet, welches für jeden Typ von Metadatenobjekten eine eigene Tabelle enthält (z.B. Sammlungen, Geschäftsobjekte, Attribute, Beziehungen, usw.). Jede Tabelle enthält eine Liste der ausgewählten Metadatenobjekte des jeweiligen Typs. Die Beziehungen zwischen den Metadatenobjekten werden über fachliche Schlüssel dargestellt.

Hinweis

Die einzelnen Tabellen in XLSX (Microsoft Excel) sind analog zu den einzelnen CSV-Dateien im Format CSV zu sehen.

Im Format XLSX entsprechen die Namen der Properties den angezeigten Beschriftungen in der Benutzeroberfläche. Für Properties, die als Datentyp literal haben, wird die Bezeichnung des Codes (wie in der Benutzeroberfläche angezeigt) erwartet.

Tooltipp

Die Tabellennamen und Überschriften entsprechen den angezeigten Beschriftungen in der Benutzeroberfläche und können in unterschiedlichen Sprachen importiert und exportiert werden (z.B. Sammlungen oder Collections, Schreibgeschützt oder Read-only). Die Sprache kann im Upload-API und im Download-API mit der Option language bzw. mit dem HTTP-Header Attribut Accept-Language definiert werden.

Achtung

Nicht nur die gewählte Sprache sondern auch die Konfiguration wird berücksichtigt, um die Tabellennamen und Überschriften zu ermitteln. Benutzer oder Schnittstellen, die das Format XLSX verwenden, müssen daher einrechnen, dass die Beschriftungen nicht festgelegt sind sondern kundenspezifisch angepasst sein könnten.

Hinweis

Aus Gründen der Übersichtlichkeit sind in den folgenden Beispielen bestimmte Spalten ausgeblendet.

Die Verknüpfungen zwischen Metadatenobjekten (z.B. Herkünfte) werden als fachliche Schlüssel in einer eigenen Tabelle abgebildet (z.B. die Tabelle Herkünfte mit den Spalten Herkunft zu und Herkunft von). Verknüpfungsattribute sind Spalten in dieser Tabelle (z.B. die Spalten Favorit und Kennzeichnung).

XLSX

Tooltipp

Alle Properties, die aufgrund der Konfiguration Pflichtfelder sind, werden mit der Hintergrundfarbe "Flieder" gekennzeichnet. Diese Felder müssen beim Upload verpflichtend befüllt sein.

Hinweis

Das Format XLSX (Microsoft Excel) schränkt die Größe einer Zelle auf 32,767 Zeichen ein.

CSV (Gezippt)

Hinweis

Für CSV wird eine Kodierung in UTF-8 verwendet. Falls bestimmte Zeichen (z.B. Umlaute, ß, €, usw.) nach dem Import fälschlicherweise als ? dargestellt werden, dann sollte die CSV-Datei vor dem Import in UTF-8 umgewandelt werden.

Der Import/Export im Format CSV ist eine ZIP-Datei, welche für jeden Typ von Metadatenobjekten eine eigene CSV-Datei enthält (z.B. Collection.csv, BusinessObject.csv, BusinessAttribute.csv, Relationship.csv, usw.). Jede CSV-Datei enthält eine Liste der ausgewählten Metadatenobjekte des jeweiligen Typs. Die Beziehungen zwischen den Metadatenobjekten (z.B. inCollection, hasDomain, hasRange) werden über fachliche Schlüssel dargestellt.

Hinweis

Die einzelnen CSV-Dateien sind analog zu den einzelnen Tabellen im Format XLSX (Microsoft Excel) zu sehen.

Im Format CSV entsprechen die Namen der Properties den (internen englischen) Attributsnamen (laut Metamodell) und weichen daher von den angezeigten Beschriftungen in der Benutzeroberfläche ab. Für Properties, die als Datentyp literal haben, wird der jeweilige Code (laut Metamodell) erwartet. Der Typ von jedem Metadatenobjekt (Collection, BusinessObject, BusinessAttribute, usw.) entspricht dem Namen der jeweiligen CSV-Datei.

Hinweis

Aus Gründen der Übersichtlichkeit sind in den folgenden Beispielen bestimmte CSV-Spalten ausgeblendet.

Die Verknüpfungen zwischen Metadatenobjekten (z.B. Herkünfte) werden als fachliche Schlüssel in einer eigenen CSV-Datei abgebildet (z.B. die CSV-Datei Derivation.csv mit den Spalten derivedTo und derivedFrom). Verknüpfungsattribute sind Spalten in dieser CSV-Datei (z.B. die Spalten favorite und qualifier).

Collection.csv:

label,title
Abrechnung,Verrechnung und Fakturierung

BusinessObject.csv:

label,inCollection
Rechnung,Abrechnung

BusinessAttribute.csv:

hasDomain,label,hasRange
Rechnung,Buchungsdatum,/Datentypen/Datum
Rechnung,Summe,/Datentypen/Betrag

Derivation.csv:

derivedTo,derivedFrom,favorite,qualifier
Rechnung,/Enterprise Model/Billing/Invoice,false,SPOT

Fachliche Schlüssel in CSV

Das Format CSV definiert, dass eine Zeichenkette, in der das Zeichen ", das CSV-Trennzeichen , oder ein Zeilenumbruch vorkommt, in Anführungszeichen (") gesetzt werden muss und jedes Anführungszeichen innerhalb der Zeichenkette verdoppelt wird.

Zum Erzeugen von syntaktisch korrekten fachlichen Schlüsseln im Format CSV ergibt sich daraus folgende zweistufige Vorgehensweise:

Werte gemäß der beschriebenen Vorgehensweise in einen fachlichen Schlüssel umwandeln.
Den daraus entstandenen fachlichen Schlüssel nach CSV konvertieren: Jeder fachliche Schlüssel, in dem das Zeichen ", das CSV-Trennzeichen , oder ein Zeilenumbruch vorkommt, wird in Anführungszeichen (") gesetzt und jedes Anführungszeichen innerhalb des fachlichen Schlüssels wird verdoppelt.

Ausgehend von den vorigen Beispielen, werden die fachlichen Schlüssel in CSV folgendermaßen abgebildet:

Fachlicher Schlüssel	CSV
`Adresse`	`Adresse`
`/Fachdatenmodell/Person`	`/Fachdatenmodell/Person`
`/Enterprise Model/Billing/Invoice/Date`	`/Enterprise Model/Billing/Invoice/Date`
`dataspot.`	`dataspot.`
`Technische Objekte/"INPUT/OUTPUT"`	`"Technische Objekte/""INPUT/OUTPUT"""`
`Datei bzw. Schnittstelle/Zeiterfassung`	`Datei bzw. Schnittstelle/Zeiterfassung`
`Datei bzw. Schnittstelle/Mitarbeiter.csv`	`Datei bzw. Schnittstelle/Mitarbeiter.csv`
`Kategorie/"28"" City Bike"`	`"Kategorie/""28"""" City Bike"""`
`Projekte/"Projekt ""Zeus"""`	`"Projekte/""Projekt """"Zeus"""""""`
`"Codename ""Kronos"""`	`"""Codename """"Kronos"""""""`
`Level3/"1.2.""3.1"""`	`"Level3/""1.2.""""3.1"""""""`
`Referenzobjekt/"""A.1"".B"`	`"Referenzobjekt/""""""A.1"""".B"""`
`Modell/Auto/hatBesitzer>Person`	`Modell/Auto/hatBesitzer>Person`
`Modell/Interface/"""source>target"">Mapping"`	`"Modell/Interface/""""""source>target"""">Mapping"""`

Vereinfachte Vorgehensweise

Beim fachlichen Schlüssel darf grundsätzlich jeder Wert eines Pfadsegments oder lokalen Schlüssels in Anführungszeichen (") gesetzt werden, egal ob das jeweils relevante Trennzeichen (/, ., >, # oder Leerzeichen) oder " darin vorkommt oder nicht. In CSV darf grundsätzlich jede Zeichenkette in Anführungszeichen (") gesetzt werden, egal ob das Zeichen " darin vorkommt oder nicht.

Daraus ergibt sich folgende vereinfachte (weniger konservative) Vorgehensweise zum Erzeugen von fachlichen Schlüsseln in CSV:

Jeder Wert innerhalb des fachlichen Schlüssels wird in Anführungszeichen (") gesetzt und jedes Anführungszeichen innerhalb jedes Werts wird verdoppelt. Dieser Schritt entfällt, falls der fachliche Schlüssel einfach (nicht zusammengesetzt) ist und weder ein relevantes Trennzeichen noch " enthält.
Der gesamte fachliche Schlüssel wird in Anführungszeichen (") gesetzt und jedes Anführungszeichen innerhalb des fachlichen Schlüssels wird verdoppelt.

XML

Der Import/Export im Format XML enthält eine flache, nicht-hierarchische Liste aller ausgewählten Metadatenobjekte. Die Beziehungen zwischen den Metadatenobjekten (z.B. inCollection, hasDomain, hasRange) werden über fachliche Schlüssel dargestellt.

Hinweis

Beim Export im Format XML ist eine Referenz auf das vollständige XML Schema (XSD) enthalten. Basierend auf dem Metamodell enthält das XML Schema eine technische Beschreibung aller Strukturen, Properties und Beziehungen.

Im Format XML entsprechen die Namen der Properties den (internen englischen) Attributsnamen (laut Metamodell) und weichen daher von den angezeigten Beschriftungen in der Benutzeroberfläche ab. Für Properties, die als Datentyp literal haben, wird der jeweilige Code (laut Metamodell) erwartet. Der Typ von jedem Metadatenobjekt (Collection, BusinessObject, BusinessAttribute, usw.) entspricht dem Namen des jeweiligen XML-Elements.

Hinweis

Aus Gründen der Übersichtlichkeit sind in den folgenden Beispielen bestimmte XML-Elemente ausgeblendet.

Die Verknüpfungen zwischen Metadatenobjekten (z.B. Herkünfte) werden als fachliche Schlüssel in einem eigenen XML-Element abgebildet (z.B. das XML-Element Derivation mit den untergeordneten XML-Elementen derivedTo und derivedFrom). Verknüpfungsattribute sind untergeordnete XML-Elemente (z.B. die untergeordneten XML-Elemente favorite und qualifier).

<?xml version="1.0" encoding="UTF-8"?>
<BusinessDataModel xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:noNamespaceSchemaLocation="/api/test/meta/schemas/BusinessDataModel.xsd">
  <Collection>
    <label>Abrechnung</label>
    <title>Verrechnung und Fakturierung</title>
  </Collection>
  <BusinessObject>
    <label>Rechnung</label>
    <inCollection>Abrechnung</inCollection>
  </BusinessObject>
  <BusinessAttribute>
    <hasDomain>Rechnung</hasDomain>
    <label>Buchungsdatum</label>
    <hasRange>/Datentypen/Datum</hasRange>
  </BusinessAttribute>
  <BusinessAttribute>
    <hasDomain>Rechnung</hasDomain>
    <label>Summe</label>
    <hasRange>/Datentypen/Betrag</hasRange>
  </BusinessAttribute>
  <Derivation>
    <derivedTo>Rechnung</derivedTo>
    <derivedFrom>/Enterprise Model/Billing/Invoice</derivedFrom>
    <favorite>false</favorite>
    <qualifier>SPOT</qualifier>
  </Derivation>
</BusinessDataModel>

JSON

Der Import/Export im Format JSON enthält eine flache, nicht-hierarchische Liste aller ausgewählten Metadatenobjekte. Die Beziehungen zwischen den Metadatenobjekten (z.B. inCollection, hasDomain, hasRange) werden über fachliche Schlüssel dargestellt.

Im Format JSON entsprechen die Namen der Properties den (internen englischen) Attributsnamen (laut Metamodell) und weichen daher von den angezeigten Beschriftungen in der Benutzeroberfläche ab. Für Properties, die als Datentyp literal haben, wird der jeweilige Code (laut Metamodell) erwartet. Der Typ von jedem Metadatenobjekt (Collection, BusinessObject, BusinessAttribute, usw.) steht in der Property _type.

Hinweis

Aus Gründen der Übersichtlichkeit sind in den folgenden Beispielen bestimmte JSON-Properties ausgeblendet.

Die Verknüpfungen zwischen Metadatenobjekten (z.B. Herkünfte) werden als fachliche Schlüssel in einem eigenen JSON-Objekt abgebildet (z.B. das JSON-Objekt Derivation mit den JSON-Properties derivedTo und derivedFrom). Verknüpfungsattribute sind JSON-Properties in diesem JSON-Objekt (z.B. die JSON-Properties favorite und qualifier).

[ {
  "_type" : "Collection",
  "label" : "Abrechnung",
  "title" : "Verrechnung und Fakturierung"
}, {
  "_type" : "BusinessObject",
  "label" : "Rechnung",
  "inCollection" : "Abrechnung"
}, {
  "_type" : "BusinessAttribute",
  "hasDomain" : "Rechnung",
  "label" : "Buchungsdatum",
  "hasRange" : "/Datentypen/Datum"
}, {
  "_type" : "BusinessAttribute",
  "hasDomain" : "Rechnung",
  "label" : "Summe",
  "hasRange" : "/Datentypen/Betrag"
}, {
  "_type" : "Derivation",
  "derivedTo" : "Rechnung",
  "derivedFrom" : "/Enterprise Model/Billing/Invoice",
  "favorite" : false,
  "qualifier" : "SPOT"
} ]

DDL/SQL

Geschäftsobjektmodelle können als DDL/SQL exportiert werden. Datenmodelle können als DDL/SQL exportiert und importiert werden. Der Import/Export ist eine .ddl oder .sql Datei.

Beispiel `Abrechnung.sql`

CREATE SCHEMA "Abrechnung"; 

CREATE TABLE "Abrechnung"."Rechnung" ("Buchungsdatum" DATE); 

ALTER TABLE "Abrechnung"."Rechnung"
ADD COLUMN "Summe" DOUBLE PRECISION;

Die Metadatenobjekte (Sammlungen, Datenobjekte, Geschäftsobjekte, usw.) werden in entsprechende Definitionen (Schemas, Tabellen, Spalten, usw.) in der Datenbank abgebildet - und umgekehrt.

Hinweis

Die konkrete SQL-Syntax ist abhängig von der gewählten Datenbank (PostgreSQL, Oracle, Microsoft SQL Server, MySQL) und wird mit der Option targetDatabase definiert.

XSD (Gezippt)

Datenmodelle können als XSD (XML Schema Definition) importiert werden. Der Import ist eine ZIP-Datei, welche eine oder mehrere .xsd Dateien enthält.

Beispiel `Abrechnung.xsd`

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="Rechnung">
    <xs:complexType>
      <xs:attribute name="Buchungsdatum" type="xs:date"/>
      <xs:attribute name="Summe" type="xs:float"/>
    </xs:complexType>
  </xs:element>
</xs:schema>

Die Komponenten des Schemas (xs:element, xs:attribute, xs:complexType, usw.) werden in entsprechende Metadatenobjekte (Datenobjekte, technische Attribute, Enumerationen, usw.) abgebildet.

JSON Schema (Gezippt)

Datenmodelle können als JSON Schema importiert werden. Der Import ist eine ZIP-Datei, welche eine oder mehrere .json Dateien enthält.

Beispiel `Abrechnung.json`

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "$id": "https://dataspot.io/test/abrechnung.json",
  "title": "Rechnung",
  "type": "object",
  "properties": {
    "Buchungsdatum": {
      "type": "string"
    },
    "Summe": {
      "type": "number"
    }
  }
}

Die Komponenten des Schemas (type, properties, usw.) werden in entsprechende Metadatenobjekte (Datenobjekte, technische Attribute, Enumerationen, usw.) abgebildet.

Reports

Die vorgefertigten Reports können in folgenden Formaten generiert werden:

Tooltipp

Zusätzlich zu den vorgefertigten Reports können kundenspezifische Reports in XSLT implementiert und beim Mandanten hochgeladen und bearbeitet werden. Kundenspezifische Reports können weitere, zusätzliche Formate unterstützen.

Hinweis

Bei bestimmten Reports handelt es sich um proprietäre Formate während andere Reports sich an gängige Standards oder Anforderungen halten (z.B. DSGVO Verarbeitungsverzeichnis).

Fachlicher Schlüssel​

Trennzeichen​

Typspezifische Trennzeichen​

Referenzwerte​

Vorgehensweise​

Import/Export​

XLSX (Microsoft Excel)​

CSV (Gezippt)​

Fachliche Schlüssel in CSV​

XML​

JSON​

DDL/SQL​

Beispiel Abrechnung.sql​

XSD (Gezippt)​

Beispiel Abrechnung.xsd​

JSON Schema (Gezippt)​

Beispiel Abrechnung.json​

Reports​

Fachlicher Schlüssel

Trennzeichen

Typspezifische Trennzeichen

Referenzwerte

Vorgehensweise

Import/Export

XLSX (Microsoft Excel)

CSV (Gezippt)

Fachliche Schlüssel in CSV

XML

JSON

DDL/SQL

Beispiel `Abrechnung.sql`

XSD (Gezippt)

Beispiel `Abrechnung.xsd`

JSON Schema (Gezippt)

Beispiel `Abrechnung.json`

Reports