Grundlagen der Modellierung - Datenmodellierung

Datenmodellierung

Bei der Datenmodellierung geht es um die zweckmäßige und effiziente Strukturierung von Daten in Informationssystemen. Die Modelle behandeln unterschiedliche Arten von Speicheranwendungen. Beispielsweise ist das ER-Modell im Bereich der Datenbanksysteme beheimatet, XML und JSON dahingegen im Bereich der Nahtstellen und Datenstrukturen innerhalb und zwischen einzelnen Systemen auf Dateiebene.

Entity-Relationship Modell (ER-Modell)

Das Entity-Relationship Modell (ER-Modell) wurde bereits im vorherigen Semester, im Studienheft „Datenbanksysteme“ (Schikuta, E.), genau erläutert. Nachfolgend werden nun die wesentlichen Punkte dieses Skriptums nochmals auszugsweise wiederholt.

Das Entity-Relationship-Modell (ER-Modell) ist eines der ältesten (Chen, 1976) und am weitesten verbreiteten Modelle zum Entwurf von Datenbankmodellen und wird auch gerne im Bereich der allgemeinen Software Entwicklung eingesetzt. Durch seine besonders einfachen Darstellungsmöglichkeiten ist es sehr gut für die Kommunikation mit den Endbenutzern geeignet.

Die Grundidee des Entity-Relationship-Modells (Objekt-Beziehungs-Modell) besteht darin, die Welt als Sammlung von Entitäten (Entity oder Objekttypen) und Beziehungen (Relationship) zwischen diesen Objekttypen zu sehen.

Modellierungsobjekte des ER-Modells

Entitäten

Ein Objekt wird Entität-Instanz genannt. Entität-Instanzen sind dabei einzelne Exemplare von Dingen oder Begriffen. Dies können beispielsweise sein:

• Personen: der Kunde, Lieferant, Mitarbeiter etc.
• Gegenstände: Handelsware, Rohstoff, Maschine etc.
• Abstrakte Begriffe: Konto, Buchung, Bestellung etc.

Entität-Instanzen mit gleichen Eigenschaften lassen sich zu Entitäten (Objekttypen) zusammenfassen, z.B. Kunden, Bestellungen etc. Die Eigenschaften einer Entität-Instanz werden durch Attribute beschrieben, z.B. Name, Baujahr, Preis, Bestellnummer.

Hinweis: Im ER – Modell bezeichnet der Begriff Entität immer eine Klasse (Typ) von Instanzen, nicht eine Instanz!

Zwischen zwei, aber auch mehr, Entitäten können Beziehungen bestehen, z.B. „Kunde bestellt Maschine“. Die Beziehung wird dabei durch die Rolle der an ihr beteiligten Entitäten beschrieben. Die Beziehungen können zwischen Entitäten gleichen Typs oder zwischen Entitäten verschiedenen Typs bestehen.

Die wichtigsten Symbole in der grafischen Notation des ER-Modells werden in der Abbildung "Grafische Notation im ER-Modell" dargestellt.

Grafische Notation im ER-Modell

Attribute können auch Beziehungen zugeordnet werden (siehe Abbildung "Beispiel Beziehungsattribut"). Hier ist bei der Modellierung zu entscheiden, ob dieses Beziehungsattribut nicht einer der beiden Entitäten zugeordnet werden kann oder soll.

Beispiel Beziehungsattribut

Eine minimale Menge von Attributen, deren Werte die zugeordnete Entität-Instanz eindeutig innerhalb aller Instanzen seines Objekttyps identifiziert, nennt man Schlüssel. Oft gibt es Attribute, die künstlich als Schlüssel eingebaut werden, z.B. Personalnummer, Vorlesungsnummer, …

Schlüsselattribute werden durch Unterstreichen (manchmal auch durch doppelt gezeichnete Ovale) gekennzeichnet (siehe Abbildung "Beispiel Schlüsselattribut").

Beispiel Schlüsselattribut

Beziehungen

Beziehungen repräsentieren eigentlich Aggregate von zwei oder mehreren an der Beziehung teilnehmenden Entitäten. Die Anzahl der aggregierten Entitäten heißt Grad der Beziehung (unäre, binäre, n-äre Beziehung). Entitäten haben in einer Beziehung eine minimale und eine maximale Kardinalität bzw. Komplexität.

Die Beziehungen können vom Typ 1:1, 1:n, n:1, oder m:n sein. Entsprechende Beispiele für die einzelnen Kardinalitäten findet man in der Abbildung "Beispiele Kardinalitäten":

Beispiele Kardinalitäten

Diese Kardinalitäten können folgendermaßen interpretiert werden:

• 1:1 – ein Ehemann hat genau eine Ehefrau (normalerweise), und umgekehrt.
• 1:n – ein Kunde besitzt mehrere Konten, aber jedes Konto gehört genau einem Kunden.
• m:n – Ein Kunde kann mehrere Artikel kaufen und jeder Artikel kann von mehreren Kunden gekauft werden.

Bei der Angabe der Kardinalitäten ist es auch möglich Intervalle durch Angabe der minimalen und maximalen Kardinalität zu definieren. In der Abbildung "Beispiel Kardinalitäten mit Intervallen" ist sowohl eine n:m und eine n:1 Beziehung definiert, wobei das Maximum der Kardinalität die Beziehungsmultiplizität definiert.

Beispiel Kardinalitäten mit Intervallen

Im obigen Beispiel sieht man, dass es ohne weiters möglich ist, auch mehr als eine Beziehung zwischen Entitäten zu definieren. Im spezifischen Fall sind dies zwei binäre Beziehungen.

In manchen Fällen ist es notwendig auch n-äre Beziehungen zu modellieren. In der Abbildung "Beispiel ternäre Beziehung" ist eine ternäre Beziehung dargestellt und die entsprechende Interpretation der Kardinalitäten angegeben.

Beispiel ternäre Beziehung

Es ist aber empfohlen n-äre Beziehungen nur in wirklich begründeten Fällen zu modellieren.

Unter einer schwachen Entität versteht man eine Entität, die kein Schlüsselattribut besitzt (d.h. wo die Instanzen nicht eindeutig unterschieden werden können). Solche Instanzen können nur über eine Beziehung zu einer anderen Entität eindeutig identifiziert werden. Schwache Entitäten werden grafisch durch einen doppelten Rand gekennzeichnet.

In der nachfolgenden Abbildung "Beispiel Schwache Entität" ergibt sich die schwache Entität dadurch, dass ein Hörsaal durch seine Nummer, Größe und seinen Typ nicht eindeutig auf einem Universitätscampus identifiziert werden kann, auf dem es eine Vielzahl von Gebäuden mit jeweils mehreren Hörsälen gibt, die in jedem Gebäude von der Nummer 1 an gezählt werden. Das bedeutet es gibt in jedem Gebäude einen Hörsaal mit der Nummer 1. Erst mit der Angabe des Gebäudes (identifying owner) kann dadurch jeder Hörsaal eindeutig identifiziert werden.

Beispiel Schwache Entität

Beispiel eines ER-Modells

Im abschließenden (vereinfachten) Beispiel dieser Lektion wollen wir, basierend auf einem gegebenen Ausschnitt der Realität einer „Bank“, eine Modellierung mit Hilfe des ER-Modells durchführen.

Ausgangsposition für unseren Ansatz bildet eine Anforderungsbeschreibung in natürlichsprachiger Form. Es wird angenommen, dass sich diese Beschreibung aus den Interviews mit den Benutzern bzw. Auftragsgebern ergeben hat. Eine in der Praxis simple, aber übliche Vorgangsweise, um Entitätskandidaten zu erhalten, ist alle Hauptworte im Text zu identifizieren und als ersten Ansatz für Entitäten zu verwenden. Dieses Verfahren wird in der CRC-Methode vertieft (siehe die Aufgaben zu dieser Lektion).

Anforderungsbeschreibung:

„Eine Bank gliedert sich in Filialen. Filialen werden an ihrem Namen unterschieden, sind in einer Stadt beheimatet und weisen ein Vermögen aus. Jede Filiale verwaltet ihre eigenen Konten und Kredite, die über Nummern identifiziert werden. Jedes Konto und jeder Kredit besitzt eine eindeutige Nummer und weist einen Kontostand (bei Konto) bzw. einen Betrag (bei Krediten) auf. Kunden wiederum besitzen Konten und haben auch Kredite laufen, wobei jedes Konto wie auch jeder Kredit genau einem oder mehreren Kunden zugeordnet wird. Kunden haben einen eindeutigen Namen und wohnen in einer Straße in einer Stadt.“

Eine mögliche Modellierung dieser Anforderungsbeschreibung als ER-Modell findet man in der Abbildung "Beispiel Bank: ER-Modell".

Beispiel „Bank“: ER-Modell

Extensible Markup Language (XML)

Die Extensible Markup Language (XML) ist ein Standard für den Aufbau von Dateidokumenten. Sie wurde vom World Wide Web Consortium (W3C) entwickelt. Es handelt sich dabei um eine sehr flexible Modellierungsform für Textformate welche wiederum von der Standard Generalized Markup Language (SGML, ISO8879) abgeleitet wurde. (World Wide Web Consortium (W3C), 2014)

XML ist eine Markup-Sprache, und es ist nur eine Markup-Sprache. […] Der XML-Hype ist so extrem geworden, dass viele Leute glauben, XML könne sogar Kaffee kochen der den Familienhund waschen. (Harold & Means, 2005, S. 5)

Die Designziele von XML selbst sind (World Wide Web Consortium (W3C), 2008):

• XML soll direkt und unkompliziert über das Internet nutzbar sein,
• XML soll eine große Anzahl unterschiedlicher Applikationen unterstützen,
• XML soll mit SGML kompatibel sein,
• eine Programmierung von Anwendungen, welche XML Dokumente verarbeiten können, soll einfach möglich sein,
• die Anzahl von optionalen Features soll in XML so gering wie möglich gehalten werden und optimal Null sein,
• XML Dokumente sollen menschenlesbar und leicht verständlich sein,
• die Modellierung von XML Dokumenten soll schnell erstellt werden können,
• das Design von XML Dokumenten soll formal und präzise sein,
• die Erstellung von XML Dokumenten soll einfach sein und
• die Kürze und Kompaktheit der XML Elemente ist von geringer Bedeutung.

Der Hauptvorteil bei XML liegt, im Gegensatz zu eigen entwickelten Dateistrukturmodellen, in der schnellen und einheitlichen Verarbeitbarkeit für den Entwickler. In nahezu jeder gängigen Programmiersprache existieren bereits fertige Parser, welche die Generierung und Verarbeitung der Datenstrukturen, ohne größeren Programmieraufwand, ermöglichen.

Aufbau eines XML Dokuments

Baumstruktur:

Die Struktur eines XML-Dokuments entspricht einer Baum-Struktur und wird oft als XML-Baum bezeichnet.

XML Baumstruktur

Jedes XML Dokument beinhaltet ein einziges XML Wurzel-Element, welches selbst jeweils wiederum beliebig viele weitere Elemente beinhalten kann. In unserem Beispiel ist das Wurzel-Element die Firma.

Alle Elemente dürfen wiederum beliebig viele weitere Elemente enthalten - sog. Kind-Elemente (child elements). In unserem Beispiel ist der Mitarbeiter ein Kind-Element von Firma und hat wiederum Vorname, Nachname, Kontakt Nr. E-Mail und Adresse als Kind-Elemente. Wie Sie erkennen können, hat auch die Adresse wiederum 4 weitere Kind-Elemente. Diese Verzweigungen lassen sich beliebig fortsetzen und sind in der tiefe der Verzweigungen nicht begrenzt.
Im Folgenden sehen Sie die Umsetzung des oben genannten XML-Baumes in ein XML-Dokument. 

<?xml version="1.0"?>

<Firma>
   <Mitarbeiter>

         <Vorname> Peter </Vorname>
         <Nachname> Huber </Nachname>
         <KontaktNr> 123 </KontaktNr>
         <E-Mail> phuber@ffh.ac.at </E-Mail>
         <Adresse>

             <Strasse> Ferdinand Porsche Ring 3 </Strasse>
             <PLZ> 2700 </PLZ>
             <Stadt> Wr. Neustadt </Stadt>
             <Land> Austria </Land>

         </Adresse>       
    </Mitarbeiter>
</Firma>
<span id="_Ref402870210" class="anchor"></span>

Zusätzlich kann das Dokument XML Deklarationen, auch bezeichnet als Processing Instructions (PI), und beliebig viele Kommentare enthalten. Die Zeichenkodierung der Dokumente darf alle Unicodezeichen enthalten, wobei jedes XML verarbeitende Programm zumindest die Kodierungen UTF-8 und UTF-16 akzeptieren muss. Alle Bezeichnungen eines Dokuments, seien es die von Elementen oder Attributen, sind Case Sensitive. Da es sich dabei um ein einfaches Textdokument handelt, kann es auch von allen Texteditoren und Internetbrowsern, ohne weitere Hilfsmittel und Plugins, angezeigt werden. (World Wide Web Consortium (W3C), 2008)

Vom Aufbau sehen sich XML und HTML (Hypertext Markup Language) Dokumente sehr ähnlich. Sie unterscheiden sich jedoch darin, dass die Art und teilweise die Anzahl der Elemente in HTML fest vorgegeben, in XML jedoch alle Elemente frei modellierbar, sind. Das Metamodell der zu verwendeten Elemente eines XML Dokuments kann somit vom Modellierer selbst festgelegt werden. HTML dient der Modellierung von Webseitendokumenten und hat fest vorgegebene Strukturen und Elemente um eine einheitliche grafische Verarbeitung durch die Internetbrowser zu ermöglichen. Das Design der Elemente selbst ist jedoch in beiden Fällen sehr restriktiv vorgegeben.

Die XML Deklaration gibt die eingesetzte XML Version, und optional das Encoding, an. Dadurch wird den verarbeitenden Programmen die Verarbeitung erleichtert. Gerade die Angabe des Encodings kann viele Verarbeitungsprobleme im Vorfeld abfangen, da der Parser damit die eingesetzten Zeichen kennt und sie korrekt interpretieren kann. Nachfolgend ist in Abbildung 10 ein minimales XML Dokument dargestellt, welches nur eine XML Deklaration und ein einzelnes XML Element, namens „mein_wurzel_element“, ohne weitere Attribute und ohne Wert, beinhaltet.

<?xml version="1.0" encoding="UTF-8"?>

<mein_wurzel_element />

Minimales XML Dokument

Da einige Zeichen in der XML Syntax eine spezielle Bedeutung haben, müssen sie im Text nötigenfalls in einer anderen Form geschrieben werden, um sie innerhalb von XML Elementen nutzen zu können:

• < wird zu &lt;
• > wird zu &gt;
• " wird zu &quot;
• ' wird zu &apos;
• & wird zu &amp;

XML-Elemente

Die einzelnen XML Elemente sind alle nach demselben Schema aufgebaut. Sie haben eine Elementbezeichnung und können beliebig viele Attribute enthalten. Weiter können sie selbst einen Inhalt haben, welcher wiederum aus Elementen bestehen kann.

Ein Element besteht aus einem oder zwei sogenannten Tags. Ein Tag wird durch spitze Klammern (<,>) an seinem Beginn und Ende ausgezeichnet. Ob ein Element aus einem oder zwei Tags besteht, hängt davon ab, ob es selbst einen eigenen Inhalt besitzt, oder nicht. Der Inhalt kann aus Text oder weiteren Elementen bestehen. Am Beginn jedes Tags steht der Name des Elements.

Hat ein Element keinen Inhaltsbereich, besteht es aus nur einen einzigen Tag. Dessen abschließenden spitzen Klammer wird ein Schrägstrich vorangestellt (<elementname />) um die Abwesenheit eines Inhaltbereiches zu signalisieren.

Sollte das Element dahingegen einen Inhaltsbereich haben, wird der erste Tag durch eine einfache spitze Klammer geschossen (<elementname>). Danach folgt dann der eigentliche Inhalt des Elements. Nach dem Inhalt, und damit am Ende des Elements, steht in diesem Fall ein zweiter Tag, welcher wiederum einen Schrägstrich nach der einleitenden spitzen Klammer hat (</elementname>).

Die Attribute eines Elements befinden sich immer innerhalb des ersten Tags. In einem Element darf ein gewählter Attributname nur einmal vorkommen. Somit ist es beispielsweise nicht möglich einem Element „person“ mehrmals das Attribut „name“ zu zuzuweisen. die Reihenfolge der einzelnen Attribute eines Elements ist dahingegen nicht relevant und kann beliebig gewählt werden. Ein möglicher Aufbau eines Elements „person“ mit den Attributen „vorname“, „nachname“ und „ausweisnummer“ ist in Abbildung 11 dargestellt.

<person vorname="Peter" nachname="Völkl" ausweisnummer="1234567"/>

Abbildung 11 – XML Element „person“

In Abbildung 12 sind weiter:

• ein Element „element_1“ ohne Inhalt und ohne Attribute,
• ein Element „element_2“ ohne Inhalt und mit Attributen,
• ein Element „element_3“ mit Inhalt und ohne Attributen,
• ein Element „element_4“ mit Inhalt und mit Attribut und
• ein Element „element_5“ mit Attributen und weiteren Elementen im Inhalt exemplarisch dargestellt.

<element_1 />

<element_2 attribut_1="Attributwert 1" attribut_2="Attributwert 2" attribut_3="Attributwert 3"/>

<element_3>Dies ist ein Inhaltstext</element_3>

<element_4 attribut_1="Wert 1">Noch ein Inhaltstext</element_4>

<element_5 attribut_1="Attributwert 1">

<element_1 />

<element_2 attribut1="Test 1"<br>
attribut_2="Test 2" attribut_3="Attributwert 3"/>

<element_3>Dies ist ein anderer Inhaltstext</element_3>

</element_5>

Abbildung 12 – XML Elemente mit unterschiedlichen Tags

Kommentare

Zusätzlich zu den Deklarationen und Elementen, kann ein XML Dokument auch Kommentare enthalten. Diese können sich an jeder Position im Dokument befinden an der auch ein Element stehen dürfte, also überall außer im Attributbereich eines Tags. Sie werden bei der Interpretation des Dokuments ignoriert. Kommentare dienen primär der Lesbarkeit durch Menschen. Mit ihnen können einzelne Teile des Dokuments mit Erklärungen versehen werden, die dem Anwender bei nicht automatisierter Betrachtung helfen können, den Inhalt zu verstehen.

Ein Kommentar ist hinlänglich seines Inhaltes kaum beschränkt. Es darf einzig keine zwei direkt zusammenhängenden Minuszeichen (--) enthalten. Sollte sich innerhalb eines Kommentars ein XML Element befinden, wird es nicht als Element, sondern als Kommentartext interpretiert. Damit können auch einzelne Teile eines Dokuments „auskommentiert“ werden, um sie bei der Interpretation zu ignorieren, ohne sie aus dem Dokument löschen zu müssen. Dies ist gerade bei der Entwicklung von Schnittstellen hilfreich, da die Musterdateien somit abgeändert werden können, ohne einzelne Inhalte zu löschen.

Kommentare werden durch die Zeichenfolge <!-- begonnen und danach durch --> wieder beendet. Alle Zeichen, welche sich zwischen diesen beiden Teilen befinden gelten damit als Kommentartext und nicht als XML Element.

XML-Schema (XSD)

Was ist ein Schema?

Ein Schema ist die formale Beschreibung der Organisation, Struktur und des Inhalts von Dokumenten.

Aufgrund des wachsenden Einsatzgebietes und der gestiegenen Anforderungen an XML, wurde ein Werkzeug benötigt, mit dem man sowohl für Maschinen als auch für Menschen das Vokabular von XML-Dokumenten lesbar beschreiben, dokumentieren und, vor allem, validieren kann.

Damit wird gewährleistet, dass jede Anwendung, die ein wohlgeformtes XML verwendet, den hier definierten Formalismus verwendet, um syntaktische-, strukturelle- und Wert-Beschränkungen auszudrücken, die für ihre Dokumentinstanzen gelten.

Ein XML-Schema dient also dazu, Regeln und Strukturen zu beschreiben. Allerdings gelten diese Beschreibungen nur für XML-Dokumente. Die Menge der XML-Dokumente, für die ein Schema gilt, wird Klasse genannt.

Anwendungsgebiete

Die Anwendungsgebiete für ein XML-Schema lassen sich in folgende Kategorien zusammenfassen:

1. Validierung - ist die meistverbreitete Anwendung eines XSDs. Sie kann in zwei Ebenen unterteilt werden.
   1. Strukturvalidierung - es wird die Einhaltung der Regel für das Vorkommen von Elementen und Attributen überprüft.
   2. Datenvalidierung - Der Inhalt der Elemente und Attribute wird auf die Art der Daten, welche in Elementen und Attributen verwendet werden dürfen, überprüft.
2. Abfrageunterstützung - Durch die Unterstützung von XML-Schema-Datentypen wird eine genaue Analyse und Abfrage mittels XSLT, XPath und XQuery unterstützt.
3. Datenbindung, Editierung - mit geeigneten Tools lassen sich Informationen direkt aus der Dokumentenstruktur in eine Datenbank einbinden.
4. Dokumentation - XML-Schemata können dazu genutzt werden, um das verwendete XML-Vokabular zu dokumentieren.

Vorteile von XSD

1. Interoperabilität – Mit Hilfe von XSD können Organisationen konsistente Datenformate definieren, was die Interoperablilität zwischen verschiedenen Systemen und Plattformen verbessert.
2. Neue Datentypen – Neue Datentypen können aus bestehenden abgeleitet werden.
3. Wiederverwendbarkeit – XSD ermöglicht den Einsatz von benutzerdefinierten Datentypen und Elementen. Diese können in verschiedenen Teilen eines Schemas wiederverwendet werden.
4. Default-Werte und Einschränkungen - XSD erlaubt die Festlegung von Standard- oder Vorgabewerten für Elemente und Attribute. Außerdem können Einschränkungen für Datentypen definiert werden, um sicherzustellen, dass die eingegebenen Daten bestimmten Kriterien entsprechen.
5. Namensräume - XSD unterstützt die Verwendung von Namensräumen, was es ermöglicht, komplexe XML-Schemata zu entwickeln, die aus mehreren Modulen oder Quellen stammen können. Dies ist besonders wichtig in umfangreichen Projekten und bei der Integration verschiedener Datenquellen.
6. Erweiterbarkeit - XSD bietet Mechanismen für die Definition von optionalen Elementen und Attributen sowie für die Erweiterung von bestehenden Schemata. Dies ermöglicht es, Schemata im Laufe der Zeit anzupassen und zu erweitern, ohne die bestehenden Datenstrukturen zu brechen.
7. Tool-Unterstützung - Es gibt eine breite Palette von Tools und Bibliotheken, die die Arbeit mit XML-Schemas erleichtern. Diese Tools bieten Funktionen wie Validierung, automatische Generierung von XML-Daten basierend auf einem Schema und umgekehrt, sowie Schema-Transformationen.
8. XSD ist selbst ein XML Dokument – Da XSD ebenfalls ein XML Dokument ist, kann es auch entsprechend validiert werden. D.h. es kann geprüft werden, ob das Schema den Regeln der Schemaspezifikation entspricht.

Bestandteile eines XSDs

• Header: wie bei XML Dokument plus dem Namespace
• Attributdefinition
• Elementdefinition
• Datentypdefinition

Header

In einem XML-Dokument ist der Header ein optionaler Abschnitt, der spezielle Informationen über das Dokument enthält. Der Header befindet sich am Anfang des XML-Dokuments und wird in spitzen Klammern (< und >) eingeschlossen. Der Header besteht aus einem oder mehreren benannten Teilen, die als "Attribut-Wert-Paare" bezeichnet werden. Ein typischer XML-Header sieht folgendermaßen aus:

<?xml version="1.0"?>

Namespace / Namensräume sind besonders nützlich, wenn in einem XML-Dokument, Daten aus verschiedenen Quellen kombiniert werden. Durch die Verwendung von Namensräumen kann sichergestellt werden, dass Elemente und Attribute eindeutig identifizierbar sind, selbst wenn sie denselben Namen haben. Das fördert die Interoperabilität und Flexibilität beim Austausch von Daten zwischen verschiedenen Systemen und Plattformen.

Der Namensraum für XML-Schema ist: http://www.w3.org/2001/XMLSchema

Jedes Element und Attribut, das zum Schema gehört wird mit einem Namensrau-Präfix (entweder „xs“ oder „xsd“) versehen.

Das <schema> Element

Das <schema> Element ist das Root Element von jedem XML-Schema und kann einige Attribute enthalten.

Eine Schema-Deklaration sieht oft so aus:

<?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

...

...

</xs:schema>

Typisierung von Daten

In einem XSD unterscheidet man zwei Typ-Arten:

1. Einfacher Typ – das sind Elemente, die nur Zeichenketten – (Zeichen oder Zahlen) enthalten und keine Attribute besitzen dürfen.
2. Komplexer Typ – das sind Elemente, die Unterelemente enthalten oder Attribute besitzen können.

   
   

Einfacher Typ

In einem XML-Schema (XSD) wird ein einfaches Element definiert, indem das <xs:element>-Element verwendet wird. Ein einfaches Element enthält nur Textinhalt.

Die grundlegende Struktur für die Definition eines einfachen Elements in einem XS:

<xs:element name="elementName" type="dataType" />

• name: Gibt den Namen des Elements an.
• type: Gibt den Datentyp des Elements an. Dieser kann ein vordefinierter einfacher Datentyp wie "string", "integer", "boolean", usw. sein, oder er kann ein benutzerdefinierter Datentyp sein, der im Schema definiert ist.

Beispiel XSD einfacher Typ:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:element name="nachname" type="xs:string" />

</xs:schema>

In diesem Beispiel wird das Element „nachname“ vom Datentyp „string“ definiert.
Das XML-Dokument, das diesem Schema entspricht, könnte sein:

<nachname>Huber</nachname>

Default Variablen

Für einfache Elemente kann ein Standardwert ODER ein fester Wert angegeben werden.

Ein Standardwert wird dem Element automatisch zugewiesen, wenn kein anderer Wert angegeben wird.

Im folgenden Beispiel ist der Standardwert "rot":

<xs:element name=“Farbe" type="xs:string" default=“rot"/>

Fixe  Variable

Bei einer fixen Variablen wird dem Element automatisch ein fester Wert zugewiesen, und es kann kein anderer Wert verwendet werden.

Im folgenden Beispiel ist der fixe Wert "rot":

<xs:element name=“Farbe" type="xs:string" fixed=“rot"/>

Komplexer Typ

Ein komplexes Element ist ein XML-Element, das andere Elemente und/oder Attribute enthält.

Es gibt vier Arten von komplexen Elementen:

• leere Elemente
• Elemente, die nur andere Elemente enthalten
• Elemente, die nur Text enthalten
• Elemente, die sowohl andere Elemente als auch Text enthalten

Achtung: Jedes dieser Elemente kann auch Attribute enthalten!

In einem XML-Schema (XSD) wird ein komplexes Element definiert, indem das <xs:element>-Element zusammen mit dem <xs:complexType>-Element verwendet wird. Ein komplexes Element kann sowohl Textinhalt als auch andere verschachtelte Elemente enthalten.

Die grundlegende Struktur für die Definition eines komplexen Elements in einem XS:

<xs:element name="elementName">

<xs:complexType>

<!-- Hier folgen Definitionen für verschachtelte Elemente, Attributen, usw. -->

</xs:complexType>

</xs:element>

Innerhalb des <xs:complexType>-Elements kann die Struktur des komplexen Elements definiert werden, einschließlich der verschachtelten Elemente, ihrer Datentypen und anderer Einschränkungen.

Beispiel XSD für komplexer Typ

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="person">

<xs:complexType>

<xs:sequence>

<xs:element name="nachname" type="xs:string" />

<xs:element name="alter" type="xs:integer" />

</xs:sequence>

</xs:complexType>

</xs:element>

/xs:schema>

In diesem Beispiel enthält das komplexe Element "person" zwei verschachtelte Elemente: "nachname" und "alter".

Das <xs:sequence>-Element stellt sicher, dass die Elemente in der angegebenen Reihenfolge erscheinen müssen.

In Folgendem sieht man beispielshaft, wie das dem Schema entsprechende XML aussehen könnte:

<person>

<nachname>John Doe</nachname>

<alter>30</alter>

</person>

Attribut

Der Aufbau einer Attributdefinition sieht wie folgt aus:

<xs:attribute name="xxx" type="yyy"/>

“xxx” = Name des Attributes

“yyy” = Datentyp des Attributes

Beispiel

XS: <xs:attribute name="lang" type="xs:string"/>

Ein entsprechendes XML-Dokument würde wie folgt aussehen:

XML: <nachname lang="EN">Smith</nachname>

Für Attribute kann ein Standardwert ODER ein fester Wert angegeben werden.

• Ein Standardwert wird dem Attribut automatisch zugewiesen, wenn kein anderer Wert angegeben wird.
• Einem fixen Attribut wird vorab ein fester Wert zugewiesen. Es kann kein anderer Wert angegeben werden

Im folgenden Beispiel ist der Standardwert „DE":

<xs:attribute name="lang" type="xs:string" default=„DE"/>

Im folgendem Beispiel ist der fixe Wert „EN“.

<xs:attribute name="lang" type="xs:string" fixed=„EN"/>

Attribute sind standardmäßig optional.

Um anzugeben, dass das Attribut erforderlich ist, verwenden Sie das Attribut "use":

<xs:attribute name="lang" type="xs:string" use="required"/>

Inhaltsbeschränkungen:

Wenn für ein XML-Element oder -Attribut ein Datentyp definiert ist, gelten Einschränkungen für den Inhalt des Elements oder Attributs.

Wenn ein XML-Element vom Typ "xs:date" ist und eine Zeichenkette wie "Hello World" enthält, wird das Element nicht validiert.

Mit XML-Schemas können Sie Ihren XML-Elementen und -Attributen auch Ihre eigenen Einschränkungen hinzufügen.

Um den Inhalt eines XML-Elements einzuschränken und eine Reihe von Zahlen oder Buchstaben zu definieren, die verwendet werden können, wird die Mustereinschränkung verwendet.

Im folgenden Beispiel wird ein Element namens "letter" mit einer Einschränkung definiert. Der einzige akzeptable Wert ist EINER der Buchstaben in Kleinbuchstaben von a bis z:

<xs:element name="letter">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:pattern value="[a-z]"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

Das folgende Beispiel definiert ein Element namens "Buchstabe" mit einer Einschränkung. Der akzeptable Wert ist null oder mehr Vorkommen von Kleinbuchstaben von a bis z:

<xs:element name=„Buchstabe">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:pattern value="([a-z])*"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

Im folgenden Beispiel wird ein Element namens „periode" mit einer Einschränkung definiert. Der einzige akzeptable Wert sind FÜNF Ziffern in einer Folge, und jede Ziffer muss in einem Bereich von 0 bis 9 liegen:

<xs:element name=„periode">

<xs:simpleType>

<xs:restriction base="xs:integer">

<xs:pattern value="[0-9][0-9][0-9][0-9][0-9]"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

Nach dem gleichen Muster funktioniert das auch mit weiteren Definitionen:

<xs:pattern value="[A-Z][A-Z][A-Z]"/>	3 Großbuchstaben
<xs:pattern value="[a-zA-Z][a-zA-Z][a-zA-Z]"/>	3 Groß- oder Kleinbuchstaben
<xs:pattern value="[xyz]"/>	Entweder „x“ oder „y“
<xs:pattern value="[0-9][0-9][0-9][0-9][0-9]"/>	5 Ziffern aus dem Zahlenbereich 0-9
<xs:pattern value="[1-5][ 1-5][ 1-5][ 1-5][ 1-5]"/>	5 Ziffern aus dem Zahlenbereich 1-5
<xs:pattern value="([a-z])*"/>	beliebig viele Kleinbuchstaben
<xs:pattern value="male|female|divers"/>	einer der Gender-Werte ist erlaubt
<xs:pattern value="[a-zA-Z0-9]{8}"/>	8 Zeichen bestehend aus Groß- oder Kleinbuchstaben oder Ziffern oder gemischte Zeichenfolge

Vorgehen beim Erstellen eines XSD

Um ein XSD für ein XML – Dokument zu erstellen, geht man wie folgt vor:

1. XML-Dokument analysieren:
   Zunächst sollten Sie das gegebene XML-Dokument gründlich analysieren, um die Struktur und Hierarchie der Elemente sowie die Art der enthaltenen Daten zu verstehen.
2. Elemente identifizieren:
   Identifizieren Sie die verschiedenen Elemente im XML-Dokument, einschließlich ihrer Hierarchiebeziehungen. Im gegebenen Beispiel gibt es die Elemente example, name, firstname, lastname, age, address, street, zip-code, city und country.
3. Datentypen bestimmen:
   Bestimmen Sie die Datentypen für jedes Element. Zum Beispiel könnten firstname, lastname, street, city und country vom Typ xsd:string sein, während age und zip-code vom Typ xsd:integer sein könnten.
4. Elemente und Typen im XSD definieren:
   Definieren Sie die Elemente und ihre Datentypen im XSD. Beachten Sie dabei die Hierarchie der Elemente. Verwenden Sie xsd:element für jedes Element und weisen Sie ihm den entsprechenden Datentyp (xsd:string, xsd:integer, etc.) zu.
5. Attribute definieren:
   Wenn das XML-Dokument Attribute enthält (wie plz im gegebenen Beispiel), definieren Sie diese mit xsd:attribute.
6. Wiederholbare Elemente festlegen:
   Beachten Sie, welche Elemente im XML-Dokument mehrmals auftreten können (wie address und name im Beispiel). Verwenden Sie maxOccurs="unbounded" oder einen anderen geeigneten Wert, um diese Wiederholbarkeit im XSD festzulegen.
7. Validierungen hinzufügen (optional):
   Wenn spezifische Muster oder Validierungen für die Daten erforderlich sind (z.B. für Namen, Postleitzahlen), können Sie xsd:restriction und xsd:pattern verwenden, um diese Einschränkungen im XSD festzulegen.
8. Beispiel-Instanzen testen:
   Erstellen Sie einige Beispiel-XML-Instanzen, um sicherzustellen, dass sie dem erstellten XSD-Schema entsprechen. Dies hilft dabei, sicherzustellen, dass das Schema die gewünschte Struktur und Validierung aufweist.

Beispiel:

Für ein XML, das folgendem Strukturbaum folgt, soll ein XML Definition File erstellt werden.

Das XSD File soll folgende Merkmale enthalten:

1. Die Reihenfolge der Elemente ist, entsprechend der Baumstruktur einzuhalten.
2. Alle Namen (Vorname, Nachname, Straßennamen etc…) müssen mit einem Großbuchstaben beginnen.
3. Das Element „example“ muss das Attribut “plz” enthalten welches als String zu definieren ist.
4. Für die Elemente „name“ und „address“ sollen eigene Typen erstellt werden welche die jeweiligen Unter-Elemente definieren.
5. Beim Alter muss sichergestellt sein, dass sowohl Kleinkinder als auch Senioren im Alter von 99+ erfasst werden können. (200+ Jahre dürfen nicht erfasst werden.)

Beispiel XSD:

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<!-- Identifizierte Elemente mit entsprechenden Datentypen und Restriktionen definieren -->

              <xsd:element name="firstname">

                            <xsd:simpleType>

                                          <xsd:restriction base ="xsd:string" >

                                              <xsd:pattern value="[A-Z][a-z]*"/>

                                          </xsd:restriction>

                            </xsd:simpleType>

              </xsd:element>

              <xsd:element name="lastname">

                            <xsd:simpleType>

                                        <xsd:restriction base ="xsd:string" >

                                              <xsd:pattern value="[A-Z][a-z]*"/>

                                          </xsd:restriction>

                            </xsd:simpleType>

              </xsd:element>

              <xsd:element name="age">

                            <xsd:simpleType>

                                          <xsd:restriction base ="xsd:integer" >

                                              <xsd:pattern value="[0-1][0-9][0-9]"/>

                                          </xsd:restriction>

                            </xsd:simpleType>

              </xsd:element>

              <xsd:element name="street">

                            <xsd:simpleType>

                                          <xsd:restriction base ="xsd:string" >

                                              <xsd:pattern value="[A-Z][a-z]*"/>

                                          </xsd:restriction>

                            </xsd:simpleType>

              </xsd:element>

              <xsd:element name="city">

                            <xsd:simpleType>

                                          <xsd:restriction base ="xsd:string" >

                                              <xsd:pattern value="[A-Z][a-z]*"/>

                                          </xsd:restriction>

                            </xsd:simpleType>

              </xsd:element>

              <xsd:element name="country">

                            <xsd:simpleType>

                                          <xsd:restriction base ="xsd:string" >

                                                         <xsd:pattern value="[A-Z][a-z]*"/>

                                          </xsd:restriction>

                            </xsd:simpleType>

              </xsd:element>

<!-- das Rootelement "example" ist vom Typ "MultAddress" -->

              <xsd:element name="example"               type="MultAddress" />

<!-- der Typ "MultAddress" besteht aus dem Typ "name" und dem Attribut "plz" -->

              <xsd:complexType name="MultAddress">

                            <xsd:sequence>

                                          <xsd:element ref="name" maxOccurs="unbounded" />

                            </xsd:sequence>

                            <xsd:attribute name="plz" type="xsd:string" use="required" />

              </xsd:complexType>

<!-- der Typ "name" wird definiert durch "firstname", "lastname", "age" und "address" -->    

              <xsd:element name="name"                    type="nametype" />

              <xsd:complexType name="nametype">

                            <xsd:sequence>

                                          <xsd:element ref="firstname" />

                                          <xsd:element ref="lastname" />

                                          <xsd:element ref="age" />         

                                          <xsd:sequence>

                                                         <xsd:element ref="address" maxOccurs="unbounded" />

                                          </xsd:sequence>

                            </xsd:sequence>

              </xsd:complexType>

<!-- das Element "address" wird durch "addresstype" definiert -->

              <xsd:element name="address" type="addresstype" /> 

              <xsd:complexType name="addresstype">

                            <xsd:sequence>

                                          <xsd:element ref="street" />     

                                          <xsd:element ref="city" />         

                                          <xsd:element ref="country" /> 

                            </xsd:sequence>

              </xsd:complexType>

</xsd:schema>

Beispiel XML:

So könnte das, dem oben beschriebenen XSD File, entsprechende XML File aussehen:

<?xml version="1.0" encoding="UTF-8"?>

<example plz="1030" >

<xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" \>

< xsi:noNamespaceSchemaLocation="path/to/external-schema.xsd">

  <name>

        <firstname>Hans</firstname>

        <lastname>Müller</lastname>

        <age>30</age>

        <address>

            <street>Hauptstraße 1</street>

            <city>Wien</city>

            <country>Österreich</country>

        </address>

        <address>

            <street>Rochusgasse 12</street>

            <city>Wien</city>

            <country>Österreich</country>

        </address>

    </name>

    <name>

        <firstname>Heidi</firstname>

        <lastname>Fischer</lastname>

        <age>25</age>

        <address>

            <street>Rennweg 3</street>

            <city>Wien</city>

            <country>Österreich</country>

        </address>

    </name>

</example>

Zu beachten

Das XSD File kann sowohl in dem jeweiligen XML File am Beginn integriert werden, oder als externes XSD File zur Verfügung gestellt werden.  Dazu muss zunächst der XML Schema Instance Namensraum im XML definiert und danach der Pfad, unter den das XSD File zu finden ist, angegeben werden.

Der allgemeine Aufbau für den Aufruf sieht wie folgt aus:

<rootElement xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

             xsi:noNamespaceSchemaLocation="path/to/external-schema.xsd">

  <!-- XML-Inhalt hier -->

</rootElement>

Beispiel eines XML Modells

Anforderungsbeschreibung:

„Eine Bank gliedert sich in Filialen. Filialen werden an ihrem Namen unterschieden, sind in einer Stadt beheimatet und weisen ein Vermögen aus. Jede Filiale verwaltet ihre eigenen Konten und Kredite, die über Nummern identifiziert werden. Jedes Konto und jeder Kredit besitzt eine eindeutige Nummer und weist einen Kontostand (bei Konto) bzw. einen Betrag (bei Krediten) auf. Kunden wiederum besitzen Konten und haben auch Kredite laufen, wobei jedes Konto wie auch jeder Kredit genau einem oder mehreren Kunden zugeordnet wird. Kunden haben einen eindeutigen Namen und wohnen in einer Straße in einer Stadt.“

Die Anforderungsbeschreibung gleicht dem Beispiels eines ER Modells. In diesem Fall soll jedoch kein Datenbankmodell, sondern ein Modell für ein Dateibasiertes XML Dokument für den Datenaustausch erstellt werden. Eine mögliche Modellierung dieser Anforderungsbeschreibung als DTD findet sich in der Abbildung "Beispiel „Bank“: XML-Modell, DTD Datei" und ein mögliches darauf basierendes XML Dokument in Abbildung "Beispiel „Bank“: XML-Modell, XML Datei". Dabei wurde aus Sicht der Filialen ausgegangen. Eine Betrachtung aus Sicht des Kontos, Kredites oder aus Sicht des Kunden wäre ebenfalls möglich. Dies hängt natürlich stark vom beabsichtigten Modellierungszweck ab. Als Wurzelelement dient das Element Filialliste, welches 0-n Filialen enthalten darf.

<!ELEMENT filialliste (filiale*)>

<!ELEMENT filiale (kredit*, konto*)>

<!ATTLIST filiale filialname ID>

<!ATTLIST filiale stadt CDATA>

<!ATTLIST filiale vermoegen CDATA>

<!ELEMENT kredit (kunde)>

<!ATTLIST kredit nummer ID>

<!ATTLIST kredit betrag CDATA>

<!ELEMENT konto (kunde)>

<!ATTLIST konto nummer ID>

<!ATTLIST konto kontostand CDATA>

<!ELEMENT kunde EMPTY>

<!ATTLIST kunde name ID>

<!ATTLIST kunde strasse CDATA>

<!ATTLIST kunde stadt CDATA>

Beispiel „Bank“: XML-Modell, DTD Datei

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE bank SYSTEM "bank.dtd">

<filialliste>

<filiale filialname="Meine Bank" stadt="Wien" vermoegen="5 mrd eur">

<kredit nummer="100" betrag="200000 eur">

<kunde name="Max Muster" strasse="Musterplatz 1" stadt="Wien">

</kredit>

<kredit nummer="101" betrag="10000 eur">

<kunde name="Maria Muster" strasse="Mustergasse 3" stadt="Wien">

</kredit>

</filiale>

<filiale filialname="Deine Bank" stadt="Wien" vermoegen="1 mrd eur">

<konto nummer="200" kontostand="3000 eur">

<kunde name="Hans Meier" strasse="Mustergasse 1" stadt="Graz">

</konto>

</filiale>

<filiale filialname="Seine Bank" stadt="Wien" vermoegen="2 mrd eur">

</filiale>

</filialliste>

Beispiel „Bank“: XML-Modell, XML Datei

JavaScript Object Notation (JSON)

Die JavaScript Object Notation (JSON) wurde ursprünglich zur Speicherung und Übertragung von Datenstrukturen in JavaScript entwickelt. Es handelt sich dabei um ein reines Textformat, welches, ähnlich wie in XML, durch die Vorgabe einer klaren Struktur, eine einheitliche Abbildung von Daten ermöglicht. JSON ist in der RFC 4627 definiert und ist wiederum Teil des ECMAScript Programming Standards, welcher wiederum die wesentlichen Objekt Literale von JavaScrip definiert. (RFC Network Working Group, 2006)

Genau wie in XML, zeichnet sich JSON durch seine Menschenlesbarkeit und die Vielzahl verfügbarer Implementierungen in allen gängigen Programmiersprachen aus. JSON ist somit nicht auf JavaScript beschränkt, hat dort jedoch seinen eigentlichen Ursprung. Damit ist auch hier eine schnelle und einfache Implementierung von Nahtstellen zwischen unterschiedlichen Anwendungen möglich. Da die Syntax in JSON wesentlich kompakter geschrieben wird, als in XML, wird es häufig für die Datenübertragungen in Webservices, wie beispielsweise Services mit REST Schnittstellen (Fielding, 2000), eingesetzt.

Aufbau eines JSON Dokuments

Die Elemente und Attribute sind in JSON werden als Objekte und Key-Values bezeichnet. Jede Struktur ist über Objekte Abgebildet, welche selbst wiederum beliebig Objekte enthalten können. Ähnlich wie in XML muss in der obersten Hierarchiestufe ein einzelnes Objekt stehen. Die gemeinsame Verschachtelung von Objekten geschieht über Arrays Struktur.

Die möglichen Datentypen der einzelnen Objekte sind:

• String,
• Number,
• Boolean und
• null.

Sie müssen jedoch nicht eigens deklariert werden, sondern ergeben sich durch ihre Schreibweise innerhalb der Datei. Strings werden mit umschließenden Anführungszeichen geschrieben, Numbers in Zahlenschreibweise ohne Anführungszeichen und Booleans direkt als Werte true und false.

Objekte werden durch geschwungene Klammern ( { , } ) deklariert. Sie können beliebig viele Key-Values enthalten. Nach dem Namen einer Key-Value steht immer ein Doppelpunkt, gefolgt von ihrem enthaltenen Wert, welcher wiederum ein eigenes Objekt sein kann. Die einzelnen Key-Values werden durch Beistriche getrennt. Ein Wert kann auch ein Array aus Werten sein. Es wird durch eckige Klammern ( [ , ] ) deklariert und enthält beliebig viele, durch Beistriche getrennte, Werte.

Im Gegensatz zu XML gibt es in JSON Dateien keine Kommentare.

Der Text der JSON Dokumente soll laut Spezifikation (RFC Network Working Group, 2006) Unicode kodiert sein, wobei standardmäßig UTF-8 verwendet wird. Der verwendete Zeichensatz des Dokuments wird vom Parser über seine ersten beiden Zeichen erkannt. Es werden dazu die, in ihrer binären Form, enthaltenen Nullen betrachtet:

• 00 00 00 xx ergibt UTF-32BE ,
• 00 xx 00 xx ergibt UTF-16BE,
• xx 00 00 00 ergibt UTF-32LE,
• xx 00 xx 00 ergibt UTF-16LE und
• xx xx xx xx ergibt UTF-8.

In der Abbildung "Beispiel JSON Objekt" ist ein JSON Objekt für eine Person definiert, welches Key-Values für einen Vornamen, einen Nachnamen und eine Ausweisnummer enthält. Weiter hat die Person ein Array mit Objekten, welche je einen Schlüssel der Person mit der jeweiligen Raumnummer abbilden.

{"vorname" : "Peter",

"nachname" : "Völkl",

"ausweisnummer" : 1234567,

"schluessel" : [{"raumnummer" : 22},{"raumnummer" : 33}]

}

Beispiel JSON Objekt

JSON Schema

Im Gegensatz zu XML gibt es bei JSON Daten keine standardisierte Möglichkeit eine eigene, formale, Definition zu erstellen, gegen welche die Struktur automatisiert geprüft werden kann. Eine entsprechende Standardisierung, das JSON Schema, befindet sich derzeit in Ausarbeitung und liegt bereits im Entwurfsstadium vor. Es kann jedoch aktuell nicht davon ausgegangen werden, dass diese unfertige Standardisierung mit jedem Parser eingesetzt werden kann. (Galiegue, 2013)

Beispiel eines JSON Modells

Anforderungsbeschreibung:

„Eine Bank gliedert sich in Filialen. Filialen werden an ihrem Namen unterschieden, sind in einer Stadt beheimatet und weisen ein Vermögen aus. Jede Filiale verwaltet ihre eigenen Konten und Kredite, die über Nummern identifiziert werden. Jedes Konto und jeder Kredit besitzt eine eindeutige Nummer und weist einen Kontostand (bei Konto) bzw. einen Betrag (bei Krediten) auf. Kunden wiederum besitzen Konten und haben auch Kredite laufen, wobei jedes Konto wie auch jeder Kredit genau einem oder mehreren Kunden zugeordnet wird. Kunden haben einen eindeutigen Namen und wohnen in einer Straße in einer Stadt.“

Die Anforderungsbeschreibung gleicht dem Beispiel eines ER-Modells und XML Modell. Die JSON Struktur könnte beispielsweise dem Austausch von Filialdaten über ein Webservice dienen. Eine mögliche Modellierung dieser Anforderungsbeschreibung findet sich nachfolgend in der Abbildung "Beispiel „Bank“: JSON-Modell, Teil 1/2". Dabei wurde ebenfalls wieder aus Sicht der Filialen ausgegangen. Eine Betrachtung aus Sicht des Kontos, Kredites oder aus Sicht des Kunden wäre ebenfalls möglich. Dies hängt natürlich stark vom beabsichtigten Modellierungszweck ab. Als Wurzelelement dient das Element Filialliste, welches 0-n Filialen enthalten darf. Die, in dem Beispiel enthaltenen, Einrückungen dienen der besseren Lesbarkeit und nicht erforderlich.

{"filialliste" : [ {"filialname“ : "Meine Bank",

"stadt" : "Wien",

"vermoegen" : "5 mrd eur",

"kredite" : [ {"nummer" : "100",

"betrag" : "20000 eur"},

"kunde" : {"name" : "Max Muster",

"strasse" : "Musterplatz 1",

"stadt" : "Wien"}

},

{"nummer" : "101",

"betrag" : "10000 eur"},

"kunde" : {"name" : "Maria Muster",

"strasse" : "Mustergasse 3",

"stadt" : "Wien"}

}

],

"konten" : []

},

{"filialname“ : "Deine Bank",

"stadt" : "Wien",

"vermoegen" : "1 mrd eur",

"kredite" : [],

"konten" : [ {"nummer" : "200",

"betrag" : "3000 eur"},

"kunde" : {"name" : "Hans Meier",

"strasse" : "Mustergasse 1",

"stadt" : "Graz"}

}

]

},

Beispiel „Bank“: JSON-Modell, Teil 1/2

{"filialname“ : "Seine Bank",

"stadt" : "Wien",

"vermoegen" : "2 mrd eur",

"kredite" : [],

"konten" : []

} ]

}

Beispiel „Bank“: JSON-Modell, Teil 2/2