|
|
| Zeile 171: |
Zeile 171: |
|
| |
|
| Diese neuen GoM werden jedoch, im Gegensatz zu ihrer ursprünglichen Version, kaum angewendet, obwohl sie sich durch eine hohe theoretische Begründung und praktische Prüfbarkeit auszeichnen. | | Diese neuen GoM werden jedoch, im Gegensatz zu ihrer ursprünglichen Version, kaum angewendet, obwohl sie sich durch eine hohe theoretische Begründung und praktische Prüfbarkeit auszeichnen. |
|
| |
| <span id="datenmodellierung"></span>
| |
| = 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.
| |
|
| |
| <span id="entity-relationship-modell-er-modell"></span>
| |
| == 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.
| |
|
| |
| <span id="modellierungsobjekte-des-er-modells"></span>
| |
| === Modellierungsobjekte des ER-Modells ===
| |
|
| |
| <span id="entitäten"></span>
| |
| ==== 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.
| |
|
| |
| [[File:media/image6.emf|520x262px]]
| |
|
| |
| <span id="_Ref189385924" class="anchor"></span>Abbildung 2 – 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.
| |
|
| |
| [[File:media/image7.emf|225x110px]]
| |
|
| |
| <span id="_Ref189404280" class="anchor"></span>Abbildung 3 – 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).
| |
|
| |
| [[File:media/image8.emf|401x88px]]
| |
|
| |
| <span id="_Ref189405590" class="anchor"></span>Abbildung 4 – Beispiel Schlüsselattribut
| |
|
| |
| <span id="beziehungen"></span>
| |
| ==== 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:
| |
|
| |
| [[File:media/image9.emf|431x193px]]
| |
|
| |
| <span id="_Ref189406510" class="anchor"></span>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.
| |
|
| |
| [[File:media/image10.emf|483x221px]]
| |
|
| |
| <span id="_Ref189408022" class="anchor"></span>Abbildung 6 – 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.
| |
|
| |
| [[File:media/image11.emf|490x259px]]
| |
|
| |
| <span id="_Ref189416544" class="anchor"></span>Abbildung 7 – 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.
| |
|
| |
| [[File:media/image12.emf|499x188px]]
| |
|
| |
| <span id="_Ref189409387" class="anchor"></span>Abbildung 8 – Beispiel Schwache Entität
| |
|
| |
|
| |
|
| |
| <span id="beispiel-eines-er-modells"></span>
| |
| === 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.
| |
|
| |
| [[File:media/image13.emf|551x239px]]
| |
|
| |
| <span id="_Ref189411141" class="anchor"></span>Abbildung 9 – Beispiel „Bank“: ER-Modell
| |
|
| |
| <span id="extensible-markup-language-xml"></span>
| |
| == 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.
| |
|
| |
| <span id="aufbau-eines-xml-dokuments"></span>
| |
| === 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 />
| |
|
| |
| <span id="_Ref402861975" class="anchor"></span>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;''
| |
|
| |
| <span id="xml-elemente"></span>
| |
| === 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"/>
| |
|
| |
| <span id="_Ref402865176" class="anchor"></span>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>
| |
|
| |
| <span id="_Ref402870210" class="anchor"></span>Abbildung 12 – XML Elemente mit unterschiedlichen Tags
| |
|
| |
| <span id="kommentare"></span>
| |
| === 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.
| |
|
| |
| <span id="document-type-definitions-dtd"></span>
| |
| === 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">
| |
|
| |
| <span id="_Ref402877835" class="anchor"></span>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">
| |
|
| |
| <span id="_Ref402877870" class="anchor"></span>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)*>
| |
|
| |
| <span id="_Ref402881692" class="anchor"></span>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)>
| |
|
| |
| <span id="_Ref403373630" class="anchor"></span>Abbildung 16 – DTD Attribute
| |
|
| |
| <span id="beispiel-eines-xml-modells"></span>
| |
| === 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>
| |
|
| |
| <span id="_Ref403048292" class="anchor"></span>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>
| |
|
| |
| <span id="_Ref403048379" class="anchor"></span>Abbildung 18 – Beispiel „Bank“: XML-Modell, XML Datei
| |
|
| |
| <span id="javascript-object-notation-json"></span>
| |
| == 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.
| |
|
| |
| <span id="aufbau-eines-json-dokuments"></span>
| |
| === 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<ref>Die Zusätze ''BE'' und ''LE'' steht für ''Big Endian'' und ''Little Endian'' und beziehen sich auf die Reihenfolge in der die einzelnen Bits des Zeichens gespeichert werden. Somit steht das erste Bit des Zeichens entweder links (LE) oder rechts (BE) in der binären Abbildung.</ref>,
| |
| * 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}]
| |
|
| |
| }
| |
|
| |
| <span id="_Ref403379545" class="anchor"></span>Abbildung 19 – Beispiel JSON Objekt
| |
|
| |
| <span id="json-schema"></span>
| |
| === 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)
| |
|
| |
| <span id="beispiel-eines-json-modells"></span>
| |
| === 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"}
| |
|
| |
| }
| |
|
| |
| ]
| |
|
| |
| },
| |
|
| |
| <span id="_Toc408237669" class="anchor"></span>Abbildung 20 – Beispiel „Bank“: JSON-Modell, Teil 1/2
| |
|
| |
| {"filialname“ : "Seine Bank",
| |
|
| |
| "stadt" : "Wien",
| |
|
| |
| "vermoegen" : "2 mrd eur",
| |
|
| |
| "kredite" : [],
| |
|
| |
| "konten" : []
| |
|
| |
| } ]
| |
|
| |
| }
| |
|
| |
| <span id="_Toc408237670" class="anchor"></span>Abbildung 21 – Beispiel „Bank“: JSON-Modell, Teil 2/2
| |
Einleitung
Modellierung und Modellierungssprachen sind ein essentieller Bestandteil der meisten Themenfelder der Wirtschafsinformatik. Die Modellierung bildet dabei einen existierenden, erwarteten oder geplanten Sachverhalt in Form eines Modells ab. Dabei handelt es sich um eine Darstellung, welche der betroffenen Zielgruppe und Zielsetzung angepasst wurde. In den nachfolgenden Lektionen werden der Modellbegriff und die ordnungsgemäße Modellierung, sowie die Grundlagen einzelner, in der Wirtschafsinformatik besonders relevanter, Modellierungsformen erläutert.
Der Modellbegriff
Bei einem Modell handelt es sich um eine vereinfachte Darstellung der Realität oder ihres Soll-Zustandes. Durch diese Abstraktion ist eine genauere Betrachtung oder Planung bestimmter Einzelaspekte möglich. Es betrachtet nur so viele Details wie nötig sind, um das zugrunde liegende Problem vollständig zu beschreiben. Der Begriff „Modell“ leitet sich aus dem lateinischen Wort „modulus“ ab und bezeichnete einen Maßstab im Bereich der Architektur. Laut dem deutschen Duden Fremdwörterbuch (2010), bedeutet Modell: Objekt, Gebilde, das die inneren Beziehungen und Funktionen von etwas abbildet bzw. [schematisch] veranschaulicht [und vereinfacht, idealisiert].
Für Wirtschaftsinformatiker und Wirtschaftsinformatikerinnen gehören Modelle und Modellierungstechniken zum unumgänglichen Handwerkszeug, insbesondere die Modelle, die in Informationssystemen abgebildet werden und jene, die wir in der Softwareentwicklung verwenden.
Modelle gibt es nicht nur in der Wirtschaftsinformatik, sondern auch in allen anderen Themenfeldern der Wissenschaft, Forschung und Entwicklung. So werden beispielsweise in der Wirtschaftsinformatik Datenmodelle verwendet und anatomische Modelle in der Medizin.
Die gängigen Modelle in der Wirtschaftsinformatik sind:
- Datenmodelle,
- Prozess- und Ablaufmodelle,
- Geschäftsprozessmodelle und
- objektorientierte Modelle.
Auf diese vier speziellen Modelle und ihre gängigsten Ausprägungen wird in den Lektionen 2 bis 5 im Detail eingegangen.
Auch die Erstellung eines Test- oder Entwicklungssystems in der Software- und Systementwicklung ist ein (Soll-)Modell des Echtsystems. Meist hat es jedoch einen sehr geringen Abstrahierungsgrad, da es dem Echtsystem so nahe wie möglich kommen soll.
Die richtige Wahl eines Modells ist essentiell für den Erfolg der gewünschten Betrachtung, da es durch eine zu starke oder falsche Abstraktion der Darstellung auch zu fehlerhaften Annahmen und Resultaten führen kann.
Jedes Modell lässt sich selbst wiederum in einem Metamodell beschreiben, welches die Modellierung selbst definiert. Ein Metamodell definiert somit die einzelnen Bausteine eines Modells und wie sie anzuwenden sind.
Die drei Hauptmerkmale des allgemeinen Modellbegriffs nach Herbert Stachowiak, dem Begründer der allgemeinen Modelltheorie, sind (Stachowiak, 1973, S. 131ff):
- Abbildungsmerkmal: Modelle sind Abbildungen oder Repräsentationen natürlicher oder künstlicher Objekte, die selbst wiederum Modelle sein können. Es handelt sich dabei auch um die Zuordnung von Original-Attributen zu Modell-Attributen.
- Verkürzungsmerkmal: Modelle bestehen, in der Regel, nicht aus allen, sondern nur aus den relevanten, Attributen des betrachteten Objektes. Um die korrekten Attribute für ein Modell auszuwählen ist sowohl das Wissen über alle möglichen Attribute des Originalobjektes als auch über die Attribute des Modells notwendig.
- Pragmatisches Merkmal: Modelle sind nicht alleine einem Zweck, sondern auch einem bestimmten Anwenderkreis und Zeitraum zugeordnet. Eine pragmatisch vollständige Bestimmung des Modellbegriffs hat nicht nur die Frage zu berücksichtigen, wovon etwas Modell ist, sondern auch, für wen, wann und wozu bezüglich seiner je spezifischen Funktionen es Modell ist.
Ein Beispiel für ein einfaches Modell und seine Attribute ist das eines Smartphones:
Je nach Abstrahierungsgrad ändern sich die mögliche Darstellung und die relevanten Attribute. Eine mögliche Aufstellung der Attribute und Abbildungen unterschiedlicher Abstrahierungsgrade ist in Tabelle 1 dargestellt.
Tabelle 1 – Einfaches Modell eines Smartphones
| Anwendungsfall:
|
Technischer Aufbau eines konkreten Smartphones
|
Abbildung eines konkreten Smartphones
|
Piktogramm für Smartphone
|
| Attribute:
|
- Gerätetyp
- Betriebssystem
- Hersteller
- Gehäuse
- Schrauben
- Kabel
- Platinen
- Speicher
- Anschlüsse
- …
|
- Gerätetyp
- Betriebssystem
- Hersteller
|
|
| Abbildung:
|
Datei:Media/image3.png
|
Datei:Media/image4.png[1]
|
Datei:Media/image5.emf
|
Modellbildung und Anforderungen an ein Modell
Bei der Modellbildung geht es um die ausreichende Abbildung eines realen Systems zur Beschreibung einer bestimmten Fragenstellung oder eines Zustandes. Dazu können entweder bestehende Modelle verwendet werden, oder ein eigenes, geeignetes, Metamodell geschaffen werden. Meist handelt es sich bei den gängigen Modellierungsaufgaben in der Wirtschaftsinformatik jedoch um Situationen, in denen bestehende Modellarten zur Anwendung kommen können und sollten. Die Verwendung eines weit verbreitenden, und im eigenen Fachbereich allgemein bekannten, Modells führt zu einem schnelleren Verständnis für alle beteiligten Personen.
Die Modellbildung lässt sich generell in vier Schritten beschreiben und durchführen (Oeser, 2012, S. 7):
- Schritt 1: Vereinfachung und Formulierung des Problems
- Schritt 2: Formalisierung und Quantifizierung des Problems
- Schritt 3: Verarbeitung des Datenmaterials und Erstellung des Modells
- Schritt 4: Interpretation und Rückschluss auf den ursprünglichen Sachverhalt
In Schritt 1 und 2 wird deutlich, dass die Anforderungen an ein Modell durch die Formulierung des zugrunde liegenden Problems definiert werden. Dieser Planungsschritt ist sehr wichtig, da die Modellauswahl für den weiteren Erfolg der Modellierung, und der damit verbundenen Behandlung der Problemstellung, essentiell ist.
Im 4. Schritt wird die Erfüllung der Zielsetzung des Modells nochmals überprüft und damit sichergestellt, dass es den Sachverhalt problemadäquat wiederspiegelt.
Der Modellierer hat, durch seine Tätigkeit, eine hohe Verantwortung gegenüber der Zielsetzung des Modells. Durch eine zu hohe Abstrahierung kann es zu Fehlern in allen, anhand des Modells abgeleiteten, Folgerungen kommen. Diese Fehler wirken sich dann auf alle Bereiche aus, welche das Modell einsetzen. Wesentliche Fehler können in der Praxis auch sehr schlimme Folgen haben, wie das nachfolgende Beispiel beschreibt.
22.09.2006:
23 Menschen sterben in den Trümmern des Transrapid
Bei dem schweren Transrapid-Unglück im emsländischen Lathen sind 23 Menschen getötet worden. Das teilte die Polizei am Freitag abend mit. Zehn Menschen sollen die Katastrophe verletzt überlebt haben. Der Transrapid war am Vormittag auf einen Reinigungswagen geprallt.[2]
Der Transrapid nutzt eine neue Antriebsform und ein spezielles Leitsystem mit einigen Sicherheitsmaßnahmen. Der Zug wird durch Magnete in der Schiene bewegt. Weiter umgreift das Fahrwerk des Zuges die Schiene und haltet ihn in Position, was wiederum ein entgleisen verhindert. Zusätzlich ist jeder Zug mit einem Ortungssystem ausgestattet, welches seine Daten kontinuierlich mit dem Leitsystem der Streckenanlage abgleicht. Ein Zusammenstoß zweier Züge ist daher, zumindest dem Modell nach, durch die zentrale Steuerung des Streckenantriebs und die Positionsbestimmung nicht möglich. Das System galt daher als enorm sicher.
Leider gab es in diesem Modell eine Komponente, welche nicht beachtet wurde. Die Streckenfahrzeuge und Reinigungswagen sind mit herkömmlichen Dieselantrieben ausgestattet und verfügten über keine Ortungssysteme. Daher war es auch möglich, dass ein Reinigungsfahrzeug übersehen wurde und in dessen Folge 23 Menschen starben.
Die Grundsätze ordnungsmäßiger Modellierung (GoM)
Bei den Grundsätzen ordnungsgemäßer Modellierung (GoM) handelt es sich um semantische Empfehlungen zur bedarfsgerechten Informationsmodellierung. Damit wurde eine bewusste Einschränkung der Modellierungsfreiheit, zugunsten der Zielgerichtetheit der Modellierung selbst, eingeführt. Dies soll wiederum die Modellqualität erhöhen. Die GoM wurden von Becker, Rosemann und Schütte, in Anlehnung an den Grundsätzen ordnungsgemäßer Buchführung (GoB), entwickelt. (Becker, Rosemann, & Schütte, 1995, S. 437)
Die GoM definieren einen Ordnungsrahmen, bestehend aus sechs Grundsätzen, welchen wiederum ein Metamodell zugrunde liegt, in dem die einzelnen GoM Objekte, Attribute und ihre Beziehungen untereinander definiert werden (Becker, Rosemann, & Schütte, 1995, S. 437ff):
- Grundsatz der Richtigkeit,
- Grundsatz der Relevanz,
- Grundsatz der Wirtschaftlichkeit,
- Grundsatz der Klarheit,
- Grundsatz der Vergleichbarkeit und dem
- Grundsatz des systematischen Aufbaus.
Zusammengefasst sollen sie die Qualität von Informationsmodellen sicherstellen.
Grundsatz der Richtigkeit
Ein Modell kann sowohl semantisch, als auch syntaktisch richtig sein. Die syntaktische Richtigkeit bezieht sich dabei auf die korrekte Einhaltung der Vorgaben des Metamodells. Bei der semantischen Richtigkeit handelt es sich um die korrekte Abbildung des Modellierungsobjektes. Dies bedeutet nicht nur, dass das Modellierungsobjekt, dem Zweck entsprechend, vollständig abgebildet sein muss, sondern auch, dass es in sich keine Wiedersprüche aufweisen darf. Die Richtigkeit beinhaltet auch die eindeutige und korrekte Benennung von modellierten Objekten. Hierbei sollen Synonyme[3] und Homonyme[4] vermeiden werden.
Grundsatz der Relevanz
Bei der Modellierung müssen die mit ihr bezweckten Ziele eingehalten werden. Die in dem Modell enthaltenen Elemente und Beziehungen sind relevant, wenn das Modellierungsziel bei ihrer Reduzierung nicht mehr erfüllt werden würde. Das Modell muss sich wieder in eine Beschreibung des beschriebenen Objektes zurückführen lassen, ohne für die Betrachtung relevante Aspekte zu verlieren.
Grundsatz der Wirtschaftlichkeit
Der Grundsatz der Wirtschaftlichkeit limitiert die Tiefe und den Umfang eines Modells hinlänglich der, durch die Modellierung selbst, entstehenden Kosten. Es handelt sich dabei um eine Abwägung zwischen dem, durch die Modellierung entstehenden, Nutzen durch eine bessere Abbildbarkeit des zugrunde liegenden Problems und der Verbesserung der Interaktion zwischen den Modellnutzern und den Kosten, die durch die Modellierung entstehen. Je umfangreicher und tiefergehend ein Modell gebildet wird, desto mehr Aufwand muss in seine Erstellung investiert werden.
Grundsatz der Klarheit
Die Anwendbarkeit des Grundsatzes der Klarheit ist, ähnlich der Relevanz, stark von den Anwendern des Modells abhängig. So ist es nötig, die Darstellung eines Modells der Zielgruppe anzupassen. Analog zur syntaktischen Richtigkeit ist auch eine klare Darstellung des Modells essentiell. Dabei geht es insbesondere um die verwendeten Symbole auf Ebene des Metamodells, als auch um die Anordnung der Symbole innerhalb des Modells selbst. Dieser Grundsatz kann beispielsweise bedeuten, dass ein sehr komplexes Modell in weitere Abstrahierungsebenen geteilt werden muss, um für den Anwender verständlich zu bleiben. Hierfür werden meist die Möglichkeiten von Substitutionen und Detailmodellen geschaffen.
Grundsatz der Vergleichbarkeit
Ähnlich dem Grundsatz der Richtigkeit wird beim Grundsatz der Vergleichbarkeit in eine syntaktische und eine semantische Vergleichbarkeit unterschiedenen. Die beiden Grundsätze der Richtigkeit und Vergleichbarkeit lehnen sich dabei auch aneinander an. Bei der syntaktischen Vergleichbarkeit handelt es sich um eine Vergleichbarkeit unterschiedlicher Modelle, mit derselben zugrunde liegenden Modellierungsanforderung. Dadurch soll auch eine Überführung von Modellen mit unterschiedlichen Metamodellen ermöglicht werden. Die semantische Vergleichbarkeit bezieht sich auf die inhaltliche Vergleichbarkeit. Damit soll der Vergleich unterschiedlicher Modelle zueinander ermöglicht werden.
Grundsatz des systematischen Aufbaus
Bei in unterschiedlichen Sichten aufgebauten Modellen müssen die Sichten untereinander konsistent sein. Das bedeutet, dass die Bezüge der unterschiedlichen Sichten zueinander vorhanden sein müssen. So muss beispielsweise ein Ablaufmodell, welches auf ein Datenmodell referenziert, auch sicherstellen, dass das entsprechende Datenmodell entsprechend modelliert ist und umgekehrt. Um hierbei alle relevanten Sichten zu integrieren, liegen solchen Modellen übergreifende Architekturkonzepte zu Grunde.
Erweiterung der GoM
Die eingeführten Grundsätze ordnungsgemäßer Modellierung wurden von ihrem Mitbegründer Reinhard Schütte in Form der „neuen Grundsätze ordnungsgemäßer Modellierung“ überarbeitet. Diese erweiterten Grundsätze weichen von den herkömmlichen in einigen Teilen ab. Das Ziel der Überarbeitung war, die theoretische Begründung und die praktische Prüfbarkeit der Grundsätze zu verbessern.
Diese „neuen Grundsätze ordnungsgemäßer Modellierung“ sind (Schütte, 1997):
- Grundsatz der Konstruktionsadäquanz,
- Grundsatz der Sprachadäquanz,
- Grundsatz des systematischen Aufbaus,
- Grundsatz der Klarheit und der
- Grundsatz der Vergleichbarkeit.
Die erweiterten Grundsätze selbst werden aus, als allgemeingültig erachteten, Zwecken abgeleitet, welche in Abbildung 1 dargestellt sind.
Dabei unterscheiden sie sich primär in zwei Grundsätzen, von den ursprünglichen GoM:
- Grundsatz der Konstruktionsadäquanz und der
- Grundsatz der Sprachadäquanz.
Diese beiden sollten den Grundsatz der Richtigkeit und den Grundsatz der Relevanz ersetzen. Inhaltlich wurden jedoch auch bei den anderen Grundsätzen einige Ergänzungen durchgeführt.
Der Grundsatz der Konstruktionsadäquanz ist dabei als wichtigster Grundsatz definiert. Hierbei wird der Nutzen des Modells, für seinen jeweiligen Modellierungszweck, in den Vordergrund gestellt und der Konsens der Modellersteller herangezogen, da sie bewerten können, ob der Abstrahierungsgrad des Modells die Realität für die Aufgabenstellung angemessen abbildet. Es muss somit zwischen den Anwendern eine Einigkeit über die, ausreichend durch das Modell abgebildete, Problemstellung und die Art der gewählten Darstellung bestehen. Auch muss ein Konsens bezüglich einheitlicher Namenskonventionen herrschen. Ein inhaltlich identes Attribut oder Objekt muss auch in allen Modellen dieselbe Bezeichnung haben.
Der Grundsatz der Sprachadäquanz beschreibt dabei die Spracheignung und Sprachrichtigkeit in Relation zum Modellsystem. Die Spracheignung bezieht sich auf die Auswahl der geeigneten Modellierungstechnik für den jeweiligen Modellierungszweck. Die Sprachrichtigkeit bezieht sich dagegen auf die korrekte Anwendung der, im Metamodell definierten, Sprachsyntax.
Diese neuen GoM werden jedoch, im Gegensatz zu ihrer ursprünglichen Version, kaum angewendet, obwohl sie sich durch eine hohe theoretische Begründung und praktische Prüfbarkeit auszeichnen.
