Beispiel Metadaten Regel

Metadatenregeln sind ganz allgemein gesprochen – Aussagen über Daten. Diese Aussagen beschreiben aus einer fachlich orientierten Sicht, was die Daten ausmacht und welche Regeln für sie gelten. Auf dieser Ebene ist eine Metadatenregel eine Liste aller Aussagen über ein Datenelement.

Beispiele für mögliche Aussagen über Datenelemente:

Das Datenelement “com.my.Person”

  • ist allgemein eine Person
  • sie besitzt eine eindeutige ID, die sie unternehmensweit identifizierbar macht
    • die ID
      • ist ein String, hat min 16 und max 16 Zeichen und das Format “[a-zA-Z0-9]+”

Das Datenelement “com.my.JuristischePerson”

  • ist eine konkrete juristische Person
  • sie ist abgeleitet von der allgemeinen Person  ”com.my.Person”
  • sie besitzt einen Namen mit max 64 Zeichen und …
  • sie besitzt zwingend eine Rechtsform vom Typ  ”com.my.Rechtsform”

Das Datenelement “com.my.Rechtsform”

  • ist der Schlüsselwert für eine Rechtsform
    • der Schlüssel ist ein String mit 3 Zeichen und dem Format “[0-9]+”
  • die Schlüsselwerte und ihre Namen für Deutschland sind
    • “101″: “GmbH”
      “102″: “GbR”
      “103″: “OHG”
  • die Schlüsselwerte und ihre Namen für England sind
    • “201″: “Ltd”
      “202″: “PLC”
      “203″: “LLP”

… usw.

Es geht bei diesen Aussage Beispielen NICHT um die verbale Form oder Formulierung – sondern lediglich darum zu zeigen, dass mit solchen Aussagen alle Aspekte von Datenelementen eindeutig beschrieben werden können und das diese Aussagen sehr nahe an einem allgemeinen Verständnis und Sprachgebrauch liegen.

Der zweite wesentliche Aspekt dieser Aussagen ist, dass sie nicht nur Angaben über die prinzipielle Struktur von Daten machen – sondern auch alle konkreten Informationen beinhalten, die die Eigenschaften, den Umgang, die Form oder den Inhalt der Daten definiert.1

Damit befinden sich alle definierenden Aussagen über ein Datenelement an einem einzigen, zentralen und über den Datenelementnamen eindeutig identifizierbaren Ort.
Alle Elementdefinitionen zusammen bilden dadurch ein allgemeines Datadictionary (Demo).

Ein solches Datadictionary kann natürlich z.B. in Form eines Excel- oder Worddokumentes verfasst werden oder mit Hilfe eines entsprechend erweiterten oder profilierten Objektmodells. Allerdings ist bei diesen Varianten unklar ob und wie diese Metainformationen in der Entwicklung und/oder zur Laufzeit im Programm selbst verwendet bzw. verfügbar gemacht werden können.2

ISA Rules verwenden daher für die Formulierung solcher Aussageregeln für Datenelemente die Datenbeschreibungssprache JSON3. Zum einen weil JSON sehr einfach und auch für NICHT Techniker gut les- und bearbeitbar ist. Zum anderen, weil es plattformunabhängig und formal hoch flexibel ist.

Die oberen Beispiele sehen in JSON so aus:

com.my.Person (…/com/my/Person.json)

{
	"name": "Person",
	"description": "Eine allgemeine Person",
	"datatype": "object",
	"version": "1.0.0",

	"member": {
		"id": {
			"description": "Eine eindeutige Kennung einer Person",

			"datatype": "string",
			"constraints": {
				"min": 16,
				"max": 16,
				"format": "[a-zA-Z0-9]+"
			}
		}
	}
}

com.my.JuristischePerson (…/com/my/JuristischePerson.json)

{
	"name": "JuristischePerson",
	"description": "Eine juristische Person",
	"datatype": "com.my.Person[version=1.0.*]",
	"version": "1.0.0",

	"member": {
		"name": {
			"description": "Name der Person",

			"datatype": "string",
			"constraints": {
				"max": 64,
				"format": "[a-zA-Z]+"
			}
		},

		"rechtsform": {
			"description": "Rechtsform der juristischen Person",

			"datatype": "com.my.Rechtsform[version=1.0.*]",
			"cardinality": "1"
		}
	}
}

com.my.Rechtsform (…/com/my/Rechtsform.json)

{
	"name": "Rechtsform",
	"description": "Eine Rechtsform",
	"version": "1.0.0",

	"datatype": "string",
	"constraints": {
		"min": 3,
		"max": 3,
		"format": "[0-9]+"
	},

	"label": {
		"de": "Rechtsform",
		"en": "Legal form"
	},

	"values": {
		"de": {
			"101": "GmbH",
			"102": "GbR",
			"103": "OHG"
		},
		"en": {
			"201": "Ltd",
			"202": "PLC",
			"203": "LLP"
		}
	}
}

Das Beispiel zeigt, wie einfach und klar mit JSON beliebige Datenelemente, deren Strukturen und deren Eigenschaften beschrieben werden können und wie nahe diese technische Beschreibung trotzdem noch an prosaischen, fachlichen Aussagen ist – diese in allgemeiner Lesbarkeit und Klarheit sogar übertrifft.

Zudem ist diese Beschreibung jederzeit frei mit neuen Eigenschaften und Informationen ergänzbar und kann sich so evolutionär entwickeln. Auf der Sourcecodeebene werden die entsprechenden Definitionsdateien einfach mit einem üblichen Versionssystem (z.B. SVN) verwaltet.

Ein weiterer entscheidender Vorteil von JSON ist der, dass JSON auf jeder Plattform und in nahezu jeder Programmiersprache verfügbar ist und die Datenelementregeln auf diese Weise überall zur Laufzeit in einem System genutzt werden können – ohne dass dafür eine Compilierung oder Paketierung notwendig ist.

Der ISA RuleService speichert und verwaltet solche Datenelementregeln in einer Dokumentendatenbank und bietet damit einen einfachen und für jeden überall verfügbaren Zugriff auf diese Metainformationen4. Dabei werden auch die Vererbungs- und Assoziationbeziehungen aufgelöst und automatisch durch die entsprechenden Regeldokumente ersetzt.

________________________
1: Gerade die konkreten Informationen wie z.B. Größen-, Längen-, Wertebereichs-,  Darstellungs- oder Formatangaben etc. sind Informationen, die für die Regelung eines Anwendungssystems entscheidend sind – gleichzeitig finden aber gerade diese Informationen nur umständlich einen Platz in sehr strukturorientierten, abstrakten Modellen. Ein Standard UML Klassenmodell zum Beispiel muss i.d.R. erst profiliert und mit entsprechenden Tagged Values erweitert werden um solche Informationen aufnehmen zu können. Und selbst dann ist es schwierig strukturierte Informationen, die wieder aus Schlüsseln und Werten bestehen unterzubringen, weil Tagged Values zunächst einmal nur eindimensionale Properties sind.

2: Die Nutzung und Einbindung von Meta- oder Modelldaten ist ein wichtiger Punkt in der Systementwicklung und Wartung. Zum einen weil beim Einsatz von Metadaten immer ein Konsistenzproblem besteht und zum anderen, weil ein Nutzen von Metadaten, über den rein dokumentatorischen Charakter hinaus nur gegeben ist, wenn die dort spezifizierten Dinge auch direkt oder automatisch in die Systementwicklung einfließen. Das kann z.B. über Generierung erfolgen oder über eine direkte Nutzung der Metadaten selbst.

3: Warum nicht xml und/oder xsd? Weil JSON viel einfacher zu erstellen und zu verarbeiten ist!

4: Einfach und für jeden überall verfügbar – ist ein ebenso unscheinbarer wie wichtiger Aspekt – denn die Produktivität bei der Entwicklung und Wartung von Anwendungssystemen hängt auch zu einem großen Teil davon ab, wie schnell und einfach die Beteiligten an benötigte Informationen gelangen können. Das Lesen zigseitiger Dokumente oder das Durchklicken umfangreicher UML Modelle ist jedoch i.d.R. relativ aufwendig. Gerade auch in agilen Umgebungen, wo mehrere unterschiedliche Teams parallel arbeiten, ist es wichtig schnell und konsistent an zentral verwaltete Informationen zu gelangen. Dokumente in einer Dokumentendatenbank sind dabei auch aufgrund der flexiblen Abfrage- und Aggregationsmöglichkeiten ein großer Vorteil.