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 Abbildung 2 dargestellt.

Grafische Notation im ER-Modell

Attribute können auch Beziehungen zugeordnet werden (siehe Abbildung 3). 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 4).

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 Abbildung 5:

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 Abbildung 6 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 7 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.

Im nachfolgenden Beispiel Abbildung 8 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 Abbildung 9.

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

Jedes XML Dokument beinhaltet ein einziges XML Wurzel-Element, welches selbst jeweils wiederum beliebig viele weitere Elemente beinhalten kann. Alle Elemente dürfen wiederum beliebig viele weitere Elemente enthalten. 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 />

Abbildung 10 – 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"
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.

Document Type Definitions (DTD)

Die Document Type Definition (DTD) wird verwendet um die Struktur eines XML Dokuments zu definieren. Ohne eine DTD darf es auf beliebigen Elementen in beliebiger Reihenfolge mit beliebigem Inhalt und Attributen aufgebaut sein. Die DTD schränkt nun genau diese Freiheit wieder ein und definiert damit das Metamodell des XML Dokuments.

Um, in einem XML Dokument, eine zugehörige DTD anzugeben. Wird eine eigene Deklaration verwendet, welche am Beginn des Dokumentes nach der XML Deklaration stehen muss. Sie wird mit <!DOCTYPE eingeleitet und wiederum mit einer einfachen Spitzen Klammer abgeschlossen. Es kann auch mehrere dieser Deklarationen in einem Dokument geben.

Innerhalb der DTD Deklaration des XML Dokuments wird zuerst der Name der Dokumentenart angegeben und danach einer der Identifier SYSTEM oder PUBLIC, sowie ihre zugehörigen Parameter.

Der Identifier SYSTEM gibt an, dass es sich dabei um eine eigene Definition handelt. Der zugehörige Parameter ist hierbei der Pfad zu der Datei, welche die angegebene DTD enthält.

Der Identifier PUBLIC weist auf eine allgemein standardisierte DTD hin, welche dem XML Parser bekannt sein sollte. Hier werden zwei Parameter benötigt. Der Erste gibt an, um welchen Public Identifier es sich dabei handelt und der zweite Parameter verweist optional auf eine alternative DTD Datei, welche verwendet wird falls der genannte Identifier dem Parser nicht bekannt ist.

In Abbildung 13 ist die Deklaration einer eigenen DTD „schema.dtd“ angegeben und in Abbildung 14 die Deklaration eines XML Dokumentes als, dem System bekannten, Dokumententyp HTML.

<!DOCTYPE mein_schema SYSTEM "schema.dtd">

Abbildung 13 – XML DOCTYPE für eigene DTD

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 //EN" "http://www.w3.org/TR/html4/strict.dtd%22>

Abbildung 14 – XML DOCTYPE für HTML

In der DTD Datei können nun die einzelnen Elemente und die Struktur des XML Dokuments definiert werden:

• Elemente werden durch <!ELEMENT …> und
• Attribute über <!ATTLIST …> definiert.

Element Definition <!ELEMENT …>

Bei der Definition eines Elements wird sowohl die Bezeichnung des Elements, als auch sein möglicher Inhalt definiert. Dabei wird als erstes der Elementname und dahinter der Inhalt in Klammer angegeben.

Der Inhalt kann entweder:

• leer (Schlüsselwort EMPTY),
• beliebig (Schlüsselwort ANY),
• reiner Text (Schlüsselwort #PCDATA) oder
• weitere Elemente (Angabe des gewünschten Elementnamen) sein.

Dabei sind auch die Angaben unterschiedlicher Inhalte und Typen kombinierbar.

Sollen mehrere Inhalte, wie beispielsweise unterschiedliche Elemente, beinhaltet sein, werden diese innerhalb der Klammer durch Beistriche ( , ) oder Pipes ( | ) getrennt.

Dabei gibt ein Beistrich das Vorhandensein beider Elemente in genau dieser Reihenfolge und eine Pipe das Vorhandensein nur eines der beiden Elemente an.

Weiter sind auch Verschachtelungen dieser beiden Operatoren durch Setzen von Klammern zulässig.

Zusätzlich gibt es noch die Möglichkeit hinter jedem Element, oder Klammerausdruck, anzugeben, ob das Element:

• optional ist (durch ein Fragezeichen: ?),
• beliebig oft aber mindestens einmal vorkommt (durch ein Pluszeichen: +) oder
• beliebig oft und optional vorkommen kann (durch einen Stern: *).

Wird hinter einem Eintrag keine Angabe über die Häufigkeit gemacht, muss er genau einmal vorkommen.

Im nachfolgenden Beispiel, in Abbildung 15, sind folgende Elemente definiert:

• element_1 hat keinen Inhalt,
• element_2 hat einen Textinhalt,
• element_3 beinhaltet element_1 und element_2,
• element_4 beinhaltet element_1 und (entweder element_2 oder element_3),
• element_5 beinhaltet 0-n Mal element_1 und 1-n Mal element_4,
• element_6 beinhaltet optional element_4,
• element_7 beinhaltet element_1 und optional element_7 und
• element_8 beinhaltet beliebig viele element_1, element_2 und element_3 in beliebiger Reihenfolge.

Bei der Definition von verschachtelten Elementen sind auch Rekursionen zulässig, wie das gerade genannte Beispiel mit element_7 zeigt. Hier muss jedoch darauf geachtet werden, die Rekursion als optional zu deklarieren (Angabe von ?, * oder |), da die Rekursion sonst verpflichtend endlos und damit nie erfüllbar wäre.

<!ELEMENT element_1 EMPTY>

<!ELEMENT element_2 #PCDATA>

<!ELEMENT element_3 (element_1, element_2)>

<!ELEMENT element_4 (element_1, (element_2 | element_3))>

<!ELEMENT element_5 (element_1*, element_4+)>

<!ELEMENT element_6 (element_4?)>

<!ELEMENT element_7 (element_1, element_7?)>

<!ELEMENT element_8 (element_1|element_2|element_3)*>

Abbildung 15 – DTD Elemente

Attribut Definition <!ATTLIST …>

Um ein definiertes Element mit Attributen auszustatten wird mittels <!ATTLIST eine Attributliste definiert. Dazu wird zuerst der Name des Elements angegeben, für das die Attributliste gilt sowie danach der Attributname und sein Typ, sowie optional eine Definition von möglichen Werten und ob der Parameter verpflichtend vorkommen muss. Dabei können entweder mehrere Attribute in einer Definition oder jedes Attribut einzeln in einer eigenen Definition angegeben werden.

Mögliche Datentypen für Attribute sind:

• CDATA für beliebige Zeichenketten,
• ID für einen eindeutigen Wert unter den Elementen desselben Typs innerhalb des XML Dokuments,
• IDREF für eine Referenz auf ein anderes Element desselben Typs innerhalb des Dokuments mittels Wert des ID Attributs,
• ENTITY für eine Referenz auf ein externes Element,
• ENTITYS für eine Liste von ENTITY‘s,
• NMTOKEN für einen Namen (eine Bezeichnung) des Elements innerhalb des XML Dokuments,
• NMTOKENS für eine Liste von NMTOKEN’s oder
• eine fest definierte Menge möglicher Eingabewerte, getrennt durch Pipes in der Form (wert1|wert2|wert2).

Zusätzlich kann hinter der Angabe des Datentyps noch:

• #REQUIRED, für verpflichtend anzugebende Attribute,
• #IMPLIED, für optionale Attribute,
• oder ein automatischer Standardwert in Anführungszeichen,

angegeben werden.

Eine Sonderform der Angabe des Standardwertes ist der Parameter #FIXED, gefolgt von einem Standardwert in Anführungszeichen. Dabei handelt es sich um einen nicht veränderbaren Standardwert bzw. einen statischen Attributwert.

Im nachfolgenden Beispiel, in Abbildung 16, wird eine DTD für ein Element element_1 mit den Attributen e1_id, welches eine eindeutige ID innerhalb des Dokuments enthält, e1_name, welches eine eindeutige Bezeichnung des Element enthält, e1_kommentar, welches einen Kommentartext enthalten soll und e1_wochentag, welches ein Wochentagkürzel enthält.

<!ELEMENT element_1 EMPTY>

<!ATTLIST element_1 e1_id ID>

<!ATTLIST element_1 e1_name ENTITY>

<!ATTLIST element_1 e1_kommentar CDATA>

<!ATTLIST element_1 e1_wochentag (MO|DI|MI|DO|FR|SA|SO)>

Abbildung 16 – DTD Attribute

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 der des Beispiels eines ER Modells in Punkt 2.1.2. 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 Abbildung 17 und ein mögliches darauf basierendes XML Dokument in Abbildung 18. 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>

Abbildung 17 – 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>

Abbildung 18 – 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 Abbildung 19 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}]

}

Abbildung 19 – 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 der des Beispiels des ER Modells in Punkt 2.1.2 und des XML Modells in Punkt 2.2.5. Die JSON Struktur könnte beispielsweise dem Austausch von Filialdaten über ein Webservice dienen. Eine mögliche Modellierung dieser Anforderungsbeschreibung findet sich nachfolgend in Abbildung 17. 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"}

}

]

},

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

{"filialname“ : "Seine Bank",

"stadt" : "Wien",

"vermoegen" : "2 mrd eur",

"kredite" : [],

"konten" : []

} ]

}

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