Analysis, Design and Development of Information Systems ...

Prof. Dr. rer.nat.habil. Bernhard Thalheim 

Information Systems Engineering 

Institute of Computer Science 

Christian-Albrechts-University Kiel 

Olshausenstr. 40 

D - 24098 Kiel 

 

Skript zur Vorlesung 

Analysis, Design and Development of Information Systems 

& Modellierung von Informationssystemen 

& Web-Informationssysteme 

1. Einführung ab SS 2012 

Sonderfarben der Seiten im Skript für zusätzliches Material. 

Forschung 

Hintergrundinformation (auch Inhalte der Grundvorlesungen) 

Zusatzliteratur und Lesestoff 

Dieses Skript ist ein kombiniertes Skript für drei Vorlesungen und wird im Verlaufe des kommenden 

Jahres auch um die Vorlesungen Information Systems Integration, Evolution and Migration, Systematische Datenanalyse 

und Datenbank-Programmierung ergänzt. 

0. Vorbemerkungen 

Gebraucht der Zeit, sie geht so schnell von hinnen! 

Doch Ordnung lehrt Euch Zeit gewinnen. 

Mein teurer Freund, ich rat euch drum 

Zuerst Collegium Logicum. 

J.W. Goethe, Faust, Erster Teil, Studierzimmer, Mephistopheles 

Gründe zum Besuch dieser Vorlesung 

Viele in der Industrie fehlgegangene Projekte. 

• SAP - am Rande des Abgrundes 

• Lufthansa-Projekt 

• DW - ein hype und eine Riesenenttäuschung 

• Fehlerpyramide 

• siehe auch Standish Group oder Gartner reports

CAU zu Kiel, IfI, ISE, β 1. Einführung ab SS 2012 2 

• Hartz-IV-Programme, Maut-Probleme 

• ... 

Material 

Hauptreferenzen für alle Vorlesungen 

• D. Embley, B. Thalheim. Handbook of Conceptual Modelling. Springer 2011 

• B. Thalheim: Entity-Relationship-Modeling. Springer 2000 

(rabattierte Exemplare des Bches können über den Lehrstuhl TIS bestellt und ’abgeholt’ werden) 

• Preprint 15/2003 der BTU Cottbus (als Ergänzung zur Co-Design-Methodik) 

• Die Vorlesungen finden im wesentlichen als Tafelvorlesung statt. (Verwendete) Folien werden deshalb nicht im 

Netz extra verfügbar sein. Sie sind jedoch über die unten zitierten Foliensammlungen erreichbar. 

• Parallel zur Vorlesung Web-Informationssysteme wird das Buchprojekt Design and Development of Web Information 

Systems (K.-D. Schewe, B. Thalheim), das beim Springer-Verlag 2012 veröffentlicht wird, erarbeitet. 

Es werden zu diesem Buch Folien zu einem Konferenz-Tutorials entstehen, die verfügbar gemacht werden. 

Die folgenden Bücher sind als Ergänzung des Stoffes sehr gut geeignet: 

Joachim Biskup: Grundlagen von Informationssystemen, Vieweg, 1995 1 

Das Skriptum zu Vorlesungen zu diesem Buch ist abgelegt unter: 

http://www.is.informatik.uni-kiel.de/∼thalheim/vorlesungen/biskup/Biskup.pdf 

Alfons Kemper, André Eickler: Datenbanksysteme - Eine Einführung, 5. Auflage. Oldenbourg 2003 

Die Skripte zur Vorlesung sind abgelegt unter: 

http://www.is.informatik.uni-kiel.de/∼thalheim/vorlesungen/kemper/kapitel1.pdf — kapitel 13.pdf 

Einige Argumente zum ER-Modell und seinen Erweiterungen 

http://www.is.informatik.uni-kiel.de/∼thalheim/HERM/hermdiscussion/HERMdiscussion.html 

Ergänzende Literatur 

• R. Wieringa. Design Methods for reactive systems. 

• C. Batini, S. Ceri, S. Navathe. Conceptual database design (der ‘Klassiker’) 

• Conolly/Begg. Database solutions. 

• D. Dori. Object-process methodology. Springer 

• H. Dreßler. Datenbankentwurf (eines der klügsten Praxisbücher) (DAMA) 

• Simsio. Data modeling essentials. 

• Hay. Data model patterns. 

1 Dieses Buch ist leider nicht in der Bibliothek der CAU Kiel vorhanden und mittlerweile vergriffen. Es wird trotzdem empfohlen, weil es 

eine der bestverstandenen Einführungen in die Datenbanktechnologie darstellt. Außerdem ist das Entwurfskapitel einzigartig. Antiquarisch ist 

dieses Buch jedoch erhältlich. 

Mod IS IS ADD Web IS


• P. Wise. Metapattern. Addison 2001 

• M. Jennings. Universla meta data models. 

• Inmon/Zachman/Geiger. Data warehouse and the Zachman framework 

• M. Brackett. Data resource quality. (ein Praktikerbuch) (DAMA) 

• Reingruber/Gregory. Data modeling handbook. 

• Pascal. Practical issues in database management. (DAMA) 

Weitere empfehlenswerte Literaturquellen zu Informationssystemen sind: 

• Ramesh Elmasri, Sham B. Navathe: Fundamentals of Database Systems (4nd Edition), Benjamin/Cummings, 

Redwood City etc., 2004 (auch in Deutsch) 

• Jeffrey D. Ullman, Jennifer Widom: A First Course in Database Systems. Prentice-Hall 1997 

• Carlo Batini, Stefano Ceri, Shamkant Navathe: Conceptual Database Design - An Entity-Relationship Approach, 

Addison-Wesley, 1991 

• Toby J. Teorey: Database Modeling & Design, Morgan Kaufmann, 1998 

• Robert J. Muller: Database Design for Smarties - Using UML for Data Modeling, Morgan Kaufmann, 1999 

• David Harel, Michal Politi: Modeling Reactive Systems - the Statemate Approach, McGraw Hill, 1998 

• Frank Leymann, Dieter Roller: Production Workflow - Concepts and Techniques, Prentice Hall, 1999 

Weitere Literatur des Lehrstuhles für alle Vorlesungen 

• Co-Design von Informationssystemen 

http://www.is.informatik.uni-kiel.de/∼thalheim/pdffiles/Auckland06CodesignTalk.pdf 

http://www.is.informatik.uni-kiel.de/∼thalheim/CodesignPapers.pdf 

und Content-Management 

http://www.is.informatik.uni-kiel.de/∼thalheim/ContentManagement.pdf 

sowie Kollaboration von Informationssystemen 

http://www.is.informatik.uni-kiel.de/∼thalheim/CollaborationManagement.pdf 

• Modell-Engineering 

http://www.is.informatik.uni-kiel.de/∼thalheim/ModelEngineering.pdf 

• Business Process Modelling and Notation 

http://www.is.informatik.uni-kiel.de/∼thalheim/BPMN.pdf 

• Web-Informationssysteme 

http://www.is.informatik.uni-kiel.de/∼thalheim/WIS.pdf 

Einige Vorträge des Lehrstuhles 

2008: http://www.is.informatik.uni-kiel.de/∼thalheim/BThalheim2008Talks.pdf 

2009: http://www.is.informatik.uni-kiel.de/∼thalheim/BetaAllTalks2009.pdf 

2010: http://www.is.informatik.uni-kiel.de/∼thalheim/BetaAllTalks2010.pdf 

Vorsicht: Files sind etwas größer! 



LaTex und ER-Diagramme 

Das Zeichnen von ER-Diagrammen ist einfach, wenn man sich in der LaTex-Umgebung bewegt. Es gibt zwei Sourcen: 

http://www.svenies-welt.de/?page id=26 

http://www.is.informatik.uni-kiel.de/∼thalheim/bilder.sty 

Werkzeuge für den Entwurf 

DBMain 

ERWin 

Silverrun 

RADD (ist leider nicht mehr betreibbar, dank Solaris). Unterstützt aber Co-Design 

Werkzeuge für die Funktionalität 

Advantage Modeler (das ausgerefteste BPMN Werkzeug) 

VisualSQL (unsere Eigenentwicklung sowohl unter Java als auch .Net 

http://www.informatik.uni-kiel.de/en/information-systems-engineering/ 

miscellaneous/visualsql/ 




Beschreibung 

Es werden ausgehend von der Erfassung und Beschreibung des Anwendungsbereiches Problembeschreibungen abgeleitet, 

mit denen eine Exploration des Lösungsraumes vorgenommen und entsprechende Anforderungen abgeleitet 

werden können. Es werden weitere moderne Modellierungskonzepte zur Modellierung von Strukturierung, Funktionalität 

und Interaktivität eingeführt und detailliert analysiert. 

Die Betrachtung dieser Modellierungsmethoden dient dazu, Sicherheit bei ihrer Anwendung zu gewinnen und 

Vorgehensweisen und Heuristiken zu beschreiben und kritisch zu bewerten. 

Themen 

Die Vorlesung betrachtet den Entwicklungsprozeß für Informationssystemanwendungen als ganzheitlichen Prozeß 

auf der Grundlage der Co-Design-Methodik, die eine Spezifikation der Strukturierung, Funktionalität, Interaktivität 

und Verteilung von Anwendungen unterstützt. Es werden daneben auch Methoden des Projektmanagement im Detail 

eingeführt und praktiziert. 

Lehrziel 

Die Studenten beherrschen nach der Vorlesung und den praktikumsorientierten Übungen die wesentlichen Methoden 

zur Modellierung von Strukturen von Informationssystemen, deren Semantik,zur Modelllierung und Umsetzung von 

Datenbankfunktionalität und zur Kollaboration von Systemen und Benutzern. Sie können entwickelte Schemata umsetzen 

und in entsprechenden Umgebungen realisieren. Die Studierenden sind in der Lage, selbständig einen Anwendungsbereich 

mit seinen Probleme, Beschränkungen, Risiken und Möglichkeiten zu analysieren und dafür wichtige 

Probleme einer adäquaten Lösung durch eine Informationssystem zuzuführen. Sie kennen wesentliche Techniken zur 

Modellierung von Strukturierung, Funktionalität und Interaktivität und zur Umsetzung dieser Modelle in aktuellen 

Systemumgebung. Die Studierenden sollen aktuelle angewandte Technologien (EJBs, SOA etc.) ebenso kennen wie 

aktuelle Forschungsschwerpunkte, z.B. Modelltransformationen zur Erzeugung von Software-Prototypen. 

Inhaltliche Voraussetzungen: 

Die Vorlesung stellt die wesentlichen Herangehensweisen für die Entwicklung von Strukturierung, Funktionalität 

und Interaktivität von Informationssystemen vor. Es werden vorlesungsbegleitend zwei große und komplexe Anwendungen 

vorgestellt. Die Studierenden entwickeln selbständig Schemata für Strukturierung, Funktionalität und 

Interaktivität einer webbasierten Anwendung ausgehend von der Analyse eines Anwendungsgebietes, der Ableitung 

entsprechender Entwicklungsanforderungen und der Entwicklung einer adäquaten Architektur. Diese Lösung wird 

mit entsprechenden Werkzeugen innerhalb einer Systemumgebung realisiert. 

Zentrale Literatur für diese Vorlesung 

D. Embley, B. Thalheim. Handbook of Conceptual Modelling. Springer 2011 (Kapitel 6, 4, 5, 7, 8) 

B. Thalheim. Entity-relationship modeling. Springer 2008. 

Weitere Literatur für diese Vorlesung 

A. M. Langer. Analysis and Design of Information Systems. Springer 2008. 

IS ADD


Abschlußbedingungen: 

Ein Übungsschein wird ausgegeben bei: 

(1) 90 % aller Übungsblätter, die mit mindestens 50 % erfüllt sind 

(2) erfolgreiches vorlesungsbegleitendes Projekt 

Studenten, die einen Übungsschein benötigen, müssen sich in der ersten Übung definitiv einschreiben. Einschreibungen 

danach werden nicht mehr berücksichtigt. Am Ende der Vorlesungsperiode wird eine Klausur angeboten, 

die keine Zulassungsvoraussetzungen hat, die sich aber in starkem Maße auf alle (30) Vorlesungen und auf alle (12) 

Übungen stützt. 

Benutzte Systemumgebungen: 

Oracle Developer 2000 

DB2, Sybase und Oracle als Systeme 

ERWin 

Silverrun (Mahagony) 

DBMain 

Advantage Modeler 

Zeit und Ort: 

siehe UnivIS 

Übungen durch Team des Lehrstuhles koordiniert durch Dipl.Inf. Kai Jannaschk und Dipl.Inf. Ove Sörensen 

IS ADD


Vorlesungsbegleitendes Projekt: 

Erstellen einer informationsintensiven Website mit entsprechender Pflege des Inhaltes, Storyboarding 

Eine E-Health-Anwendung 

siehe auch eine Einführung in Kapitel 

IS ADD


Modellierung von Informationssystemen 

Kurzfassung 

Die Vorlesung betrachtet den Entwicklungsprozeß für Informationssystemanwendungen als ganzheitlichen Prozeß 

auf der Grundlage der Co-Design-Methodik, die eine Spezifikation der Strukturierung und Funktionalität, sowie 

im weiteren Interaktivität und Verteilung von Anwendungen unterstützt. Es werden daneben auch Methoden des 

Projektmanagement im Detail eingeführt und praktiziert. 

Lernziele 

Die Studierenden verfügen über grundlegende Kenntnisse der Stärken und Schwächen verschiedener Modellierungsansätze 

und ihrer Anwendungsmöglichkeiten. Sie verstehen die Grundlagen von Datenbankmodellen und deren historischer 

Entwicklung, können DBMS basierend auf erweiterten Datenbankmodellen einsetzen und haben eine Befähigung 

zum Entwurf und zur Entwicklung einer Datenbank mit Hilfe erweiterter Datenbankmodelle. 

Lehrinhalte 

Modellierung ist im Kontext von Informationssystemen ist für viele Aspekte von zentraler Bedeutung z.B. für die Entwicklung 

von Systemen, umfaßt das Verstehen der Funktionalität der Systeme und berücksichtigt die Unterstützung 

der Wartung und der Weiterentwicklung. Es werden in dieser Vorlesung die wesentlichen Aspekte der Datenbanksystemund 

Informationssystemmodelliering vorgestellt. 

Voraussetzungen 

Informationssysteme, Softwaretechnik 

Lehr- und Lernmethoden 

Vorlesung und anwendungsorientierte Übungen 

Verwendbarkeit 

Modul innerhalb des Wirtschaftsinformatik-Studienganges 

Lehrsprache 

Deutsch, ggf. Englisch 


D. Embley, B. Thalheim. Handbook of Conceptual Modelling. Springer 2011 (Kapitel 3, 4, 5) 



John Carlis and John Magure. Mastering data modeling - A user-driven approach. Addison Wesley, 2001. 

Terry Halpin. Information modeling and relational databases. Morgan Kaufmann, 2001. 

Bernhard Rumpe. Modellierung mit UML. Springer, 2004. 

Mod IS


Vorlesungsbegleitendes Projekt: 


Eine E-Commerce-Anwendung (Cottbus Interaktiv) 

Übersicht über Komponenten der Anwendung 

1. Personen, Rollen und Beziehungen 

2. Kontakte für E-Commerce-Anwendungen 

3. Beschreibung des Benutzer-Logins 

4. Objekte in Web-Inhalten 

5. Beschreibung des Bedarfs von Parteien 

6. Beschreibung der Subskriptionen 

7. Modellierung der Web-Benutzung 

Auswertungsschemata 

1. Auswertung der Besuche 

2. Benutzer-Profile 

3. Abrechnung für kostenpflichtige Inhalte 

Teil 1 

Personen, Rollen und Relationships 

Personen und Organisationen als Partei 

Modellierung als Spezialisierungshierarchie 

agieren (als Relationship-Typ) 

in Rollen für Person : Webmaster 

Employee 

für Organisation : ISP 

Supplier 

Interne Org. 

für SW-Agent : Hosting Server 

in Beziehungsrolle : Besucher 

Kunde 

möglicher Kunde (Prospekt) 

Subscriber 

Konsultant 

und unterschiedl. Ausprägungen der Beziehungen 

z.B. Webmaster-Auftrag 

Besucher - ISP 

Host-Server-Besucher 

mit Attributen (Von, Bis, Kommentar). 

Teil 2 

Kontakte für E-Commerce-Anwendungen 

Mod IS


Möglichkeiten mit Partei Kontakt aufzunehmen 

über 

Postadresse (u. Liste) 

Telefonnummer 

Elektronische Adresse (email oder web oder IP) 

mit Kontakt-Mechanismus-Typ, 

wobei Kontakte aufeinander verweisen können. 

Der Kontaktmechanismus ist eine Beziehung zwischen 

Partei(en) und 

den Kontaktmöglichkeiten 

unter Berücksichtigung des Partei-Rollen-Typs 

Kontakte dienen einem Ziel (als Beziehung zwischen 

Ziel-Typ und dem Kontaktmechanismus. 

Fast alle Beziehungen sind zeitlich begrenzt. 

Teil 3 

Beschreibung des Benutzer-Logins 

Nutzer haben Zugriff auf Web-Content 

in unterschiedlichen Rollen (Gast, ...) 

und sind Partei(en). 

Es wird der Zugriff als Zugriffsgeschichte erfasst. 

Nutzern werden Präferenzen je nach Präferenz-Typ zugeordnet. 

Für Parteien wird je nach Web-Content-Rollen-Typ eine Web-Content-Rolle benutzt, um Beziehung zum Web- 

Content herzustellen. 

Web Content ist charakterisiert durch entsprechende 

Web-Adressen, den Web-Content-Typ 

sowie den Web-Content-Status-Typ. 

Es gibt außerdem je nach Funktionstyp 

Beziehungen zwischen Web-Content. 

Es sind entsprechend adäquate Attribute hinzuzufügen und alle Kardinalitätsabhängigkeiten auszuspezifizieren. 

Teil 4 

Objekte in Web-Inhalten 

Web-Inhalte (Content) bestehen aus Objekten (die in diesen verwendet werden). 

Objekte können Parteien zugeordnet sein in unterschiedlichen Zuordnungstypen. 

Objekte sind charakterisiert durch Namen, Beschreibung und URI. Sie können Text-Objekte sein, Bildobjekte, 

Video-Objekte, Audio-Objekte oder sonstige Objekte. Der Objekt-Typ wird separat beschrieben. 

Einige Objekte sind Produkte. 

Produkte besitzen Hauptmerkmale. Der Hauptmerkmals-Typ ist einfach charakterisiert durch eine Identifikation und 

durch eine Beschreibung. 

Mod IS


Diese Hauptmerkmale sind auch Objekten zugeordnet. 

Objekte sind mit anderen Objekten in unterschiedlicher Art und Weise assoziiert. Assoziationen können didaktisch, 

inhaltlich oder vom Kontakt her determiniert sein. 

Produkte sind kategorisiert anhand einer Kategorie-Landkarte. 

Teil 5 

Bedarf von Parteien 

Parteien (insbesondere Kunden mit den Teiltypen) haben einen Bedarf, der 

klassifiziert wird durch einen Bedarfstyp (mit Identifikation und einer Beschreibung), 

auf Produkte (mit Identifikation und Kategorisierung orientiert), 

durch Kommunikationsereignisse, die durch eine Identifizierung, eine Startzeit und 

optimale Endzeichen und Kommentare beschrieben sind, verweist und 

durch Clicks zu einem Zeitpunkt auf Webcontent einen Zugriff indiziert. 

Teil 6 

Subskriptionen 

Ein Benutzer kann in der Rolle des Abonnenten (Subscriber) auftreten. Er bestellt i.A. ein 

Produkt oder eine Produktpalette (ab einem Zeitpunkt, mit einem Bestelldatum, mit 

weiteren Anmerkungen). 

Eine Subskription wird durch eine Subskriptionsabwicklung erfüllt. Die Subskriptionsabwicklung folgt dem Subskriptionstyp 

der Subskription oder kann auch einem eigenständigen folgen. Es wird geliefert an einen Kontaktmechanismus 

je nach Parteienbedarf und Subskription. 

Eine Abwicklung kann auch stückweise durch eine Lieferliste erfolgen. 

Kennzeichen von Elementen einer Lieferliste oder auch Gesamtabwicklungen sind Anzahl, Preis/ Einheit, Vereinbarungspreis, 

vorläufiges Zustelldatum, Zustellinstruktionen, ein Laufzettel und weitere Kommentare. 

Teil 7 

Modellierung der Web-Benutzung 

Die Web-Benutzung wird charakterisiert mit dem Zachman-Pattern 

wer-wann-was-womit-worauf-mit welchem Vertrag, 

d.h. durch 

ein User login mit der User ID, dem aktuellen Benutzer, seinem Paßwort, 

eine Session bzw. einen Besuch auf eine Webadresse 

mit einer ID, einem Beginn, einem optionalen Ende, einer Aufzeichnung 

wie z.B. einem Cookie 

einen Content, 

einem Benutzeragenten, 

einer identifizierten IP-Adresse bzw. einer referenzierten Web-Adresse 

und einem Server-Hit-Typ 

sowie durch die Traffic-Parameter Zeit, Anzahl Bytes. 

Mod IS


Ein Benutzeragent ist ein virtuelles Objekt, das charakterisiert ist durch eine Plattform (mit 

ID, Name, Version), einen Browser-Typ (mit ID, Name, Version, einen Agentenmethoden- 

Typ (mit ID und Beschreibung) sowie einen Agenten-Typ (mit ID und Beschreibung) und 

einen Protokoll-Typ (ID, Beschreibung)). 

Man beachte, daß sowohl Web-Adresse als auch ID-Adresse Spezialisierungen von elektronischen 

Adressen sind als auch letztere eine Spezialisierung von Kontaktmechanismus ist. 

Mod IS













ERWin 


DBMain 


Zeit und Ort: 

siehe UnivIS 


Mod IS


Web-Informationssysteme 

Kurzfassung 

In der Vorlesung wird in die Entwicklung von Web-Informationssystemen, das Storyboarding von Web-Anwendungen 

und die Entwicklung von e-Business, edutainment, infotainment, community und identity websites eingeführt. Es 

werden die wesentlichen Spezifikations- und Programmiertechniken eingeführt. Ziel der Vorlesung ist es, Kenntnisse 

über Grundlagen und weitergehende Methoden und Techniken des Web Engineering zu vermitteln. 

Lernziele 

Die Studierenden werden mit dem Einsatz von Informationssystemen in Web-Anwendungen bekannt gemacht. Sie 

sind in der Lage, Web-Informationssysteme für Anwendungen schrittweise zu entwickelt, Datenbanksysteme in 

Informationssystem-Anwendungen einzubetten und dafür aufzubereiten und geeignete Realisierungsvarianten und 

Architekturen auszuwählen. Die Studierenden haben einen Überblick über die derzeit vorhandenen und gebräuchlichen 

Lösungen und können damit ihre persönliche Informationsumgebung besser nutzen und gestalten. Nach Abschluss 

des Modules besitzenden die Studierenden detailierte Kenntnisse über existierende Ansätze, Technologien 

und Systeme und sind in der Lage auf diesen Grundkenntnissen aufbauend, selbst webbasierte Systeme zu entwerfen 

und zu gestalten. 

Lehrinhalte 

Das Modul behandelt die Disziplin des Web Engineering. Im Vordergrund stehen Vorgehensweise und Methoden, die 

zu einer systematischen Konstruktion webbasierter Anwendungen und Systeme führen, wobei auf dedizierte Phasen 

und Aspekte des Lebenszyklus eingegangen wird. Das Phänomen “Web” wird dabei aus unterschiedlichen Perspektiven 

wie Web Designer, Analysten, Architekten oder Ingenieuren betrachtet. Es werden Methoden vorgestellt, mit 

denen Web-Anwendungen systematisch aufgesetzt, betrieben, gewartet und erweitert werden können. Darüber hinaus 

werden Beispiele aufgezeigt, welche die Notwendigkeit für die agile Ausrichtung von Teams, Prozessen und 

Technologien aufzeigen. 

Voraussetzungen 

Informationssysteme, Softwaretechnik, Programmierung 

Prüfungsleistung 

WIS-Projekt mit anschließender Verteidigung 

Lehr- und Lernmethoden 

Es werden in der Vorlesung Sprachen der Entwicklung eingeführt, im Detail vorgeführt und gemeinsam mit den 

Studierenden erprobt. In der Übung erarbeiten die Studierenden ein Storyboard und eine prototypische Lösung für 

eine Anwendungsaufgabe. Das Übungspraktikum wird in Kleingruppen durchgeführt. 

Verwendbarkeit 

Akzentmodul in der Säule: Entwicklung und Management von Informationssystemen 

Web IS



D. Embley, B. Thalheim. Handbook of Conceptual Modelling. Springer 2011 (Kapitel 10,11) 



G. Alonso, F. Casati, H. Kuno, V. Machiraju, Web Services, Springer Verlag, 2003 

Web IS


Vorlesungsbegleitendes Projekt 


Eine Edutainment-Anwendung 

Web IS













ERWin 


DBMain 


Zeit und Ort: 

siehe UnivIS 


Web IS


Literatur und Profil des Lehrstuhles 

Unsere Kompetenz 

Kompetenz des Lehrstuhles 

• Modellierungserfahrung seit 1985 

• größte Schematabibliothek 

• SAP-Sabbatical 

• Rückkopplung international: DAMA und ER 

• Extra-Website zum erweiterten ER-Modell: 

http://www.is.informatik.uni-kiel.de/∼thalheim/HERM.htm 

• Kapitel 4 aus dem Handbook 

http://www.is.informatik.uni-kiel.de/∼thalheim/HERMHandbook.pdf 

Literatur für alle Vorlesungen 

D. Embley, B. Thalheim. Handbook of Conceptual Modelling. Springer 2011 (Kapitel 6, 4, 5, 7, 8) 


HERM ’bible’ 

Handbook 

Practical Database Design Methodologies. 

Kuwait University 

Press, 1989 

Web IS


Instead of a Personal Profile: Editing (until 2011) 

ADBIS ASM CM EJC e-Bus. ER 

FoIKS MFDBS NLDB Semantics WIS WISE 

i.e., almost reaching the big triple ”3”s (3, 30, 300) 

(3 (habilitation students, profs, books), 30 (PhD students, editorials, projects), 300 (master/diploma students 200, papers, presentations)) 

Instead of a Personal Profile: General (until 2011) 

Source: http://dblp.uni-trier.de/ und http://www.wordle.net/ 

Instead of a Personal Profile: My Co-Authors (until 2011) 

Source: http://dblp.uni-trier.de/ und http://www.wordle.net/ 

Web IS


Most Cited Papers (h ≥ 25) (until 2011) 

Source: http://quadsearch.csd.auth.gr/index.php?lan=1&s=2 und http://www.wordle.net/ 

Web IS


1 Einführung 

Denn eben, wo Begriffe fehlen, 

Da stellt ein Wort zur rechten Zeit sich ein. 

Mit Worten läßt sich trefflich streiten, 

Mit Worten ein System bereiten, 

An Worte läßt sich trefflich glauben, 

von einem Wort läßt sich kein Jota rauben. 


In der ersten einführenden Vorlesung werden Spezifika, Probleme und Lösungsmethodiken der Entwicklung 

großer Informationssysteme beleuchtet, die Separation von Gesichtspunkten für Informationssysteme und darauf aufbauend 

eine Herangehensweise zur Begleitung von Entwicklungsprojekten vorgestellt und das Abstraktionsschichtenmodell, 

das eine systematische und integrierte Entwicklung aller Aspekte von Informationssystemanwendungen 

erlaubt, eingeführt. Die Themen der einführenden Vorlesungen werden in den späteren Übungen vertieft. 

1.1 Modellierung von Informationssystemen 

1.1.1 Ausgangslage 

Modellierung ist ein iterativer Prozeß, d.h. die Entwicklung eines konzeptuellen Schemas erfolgt in iterativen Verfeinerungsund 

Restrukturierungsschritten 

dies gilt auch dann, wenn das konzeptuelle Schema durch die Abbildung eines konzeptuellen Vorentwurfsschemas 

entstanden ist 

siehe schrittweise Entwicklung, wesentliche Phasen 

Anhaltspunkte (Faustregeln) für diese Schritte erforderlich, um Konsistenz zu erhalten 

Transformationsregeln 

1.1.2 Besonderheiten bei der Modellierung von Informationssystemen 

Ich bin nicht ihr bester Freund. 

Ich bin ihr einziger Freund! 

Danny DeVito in Das Geld anderer Leute 

Datenbank- und Informationssysteme sind heute integrierte, eingebettete oder selbständige Anwendungen und 

integraler Bestandteil der Infrastruktur von vielen Betrieben. Meist wird zwischen diesen Systemtypen nicht unterschieden. 

Wir wollen im weiteren jedoch Datenbanksysteme als die Hauptkomponente von Informationssystemen 

auffassen. Informationssysteme verfügen außerdem über eine Reihe von Anwendungsschnittstellen im Rahmen von 

Präsentationssystemen. Ein Datenbanksystem umfaßt wiederum ein Datenbank-Management-System (DBMS) und 

eine Reihe von Datenbanken. Information umfaßt immer eine Deutung von Daten. Information ist aus unserer Sicht 

nicht einfach ‘Mikro’-Wissen oder eine Menge von Daten. Wir unterschieden zwischen 

dem Datum als Folge von Symbolen, 

Nachrichten als übermittelte Daten, 

dem Wissen als validierter, wahrer Glaube bzw. zusammengefaßte, kondensierte Fakten (Daten) und Regeln und 

Mod IS


Informationen als gedeutete Nachrichten, Daten oder Mitteilungen, die ein Empfänger mit bestimmten Regeln 

intuitiv oder explizit auswählt innerhalb eines Kontextes, verarbeitet und in seinen Informations-, Daten- bzw. 

Wissensbestand integriert. 

Darauf aufbauend sind verschiedene Entwurfsszenarios möglich: 

Datenstrukturgetriebener Entwurf: Es wird zuerst die Struktur der Anwendung dargestellt, darauf aufbauend die 

Funktionalität und die Interaktion. Dieser Zugang wird am häufigsten im Informationssystementwurf angewandt. 

Prozeßorientierter Entwurf: Es werden zuerst die Prozesse und die erwünschte Funktionalität der Anwendung 

dargestellt und auf dieser Grundlage die Struktur und Interaktion. Dieser Zugang wird im Rahmen der Softwaretechnologie 

angewandt, er ist aber für den Datenbankentwurf in dieser Ausprägung wenig sinnvoll. 

Architekturdominierter Entwurf: Es wird zuerst ein “Bauplan” des Informationssystemes anhand der Anwendung 

abgeleitet. Die Architektur basiert auf Komponenten und Assoziationen zwischen den Komponenten. Es werden 

die einzelnen Komponenten unter Berücksichtigung ihrer Assoziationen und daraus entstehender Obligationen 

entwickelt. 

Interaktionszentrierter Entwurf: Es wird zuerst der Interaktionsraum oder der Storyraum modelliert und daraus 

werden dann Anforderungen an die Strukturierung und Funktionalität abgeleitet. Diese Anforderungen führen 

zur Ableitung des Anwendungssystemes. 

Weitere Strategien sind möglich, wie z.B. parallele Entwicklung verschiedener Konzepte bzw. Teilkonzepte. 

Orthogonal dazu sind verschiedene Unabhängigkeitskonzepte möglich: 

Unabhängigkeit des Endnutzers von spezifischer konzeptueller Repräsentation 

Unabhängigkeit der Repräsentation der Implementierung. 

Diese Unabhängigkeitskonzepte sind an der Vorgehensweise zur Implementation und der 3-Ebenen-Architektur (Endnutzerebene, 

Konzeptionelle Ebene, Implementationsebene) orientiert. 

Im Datenbankentwurf wird die Struktur, Funktionalität und Semantik einer Datenbankanwendung so spezifiziert, 

daß die infragekommende Anwendung auf einer Plattform bzw. einem Datenbankverwaltungssystem (DBMS) 

effizient verwaltet und bearbeitet sowie in benutzerfreundlicher Form dargestellt werden kann. Damit ist neben 

der Speicherkomplexität und der Verarbeitungskomplexität auch die Einfachheit der Benutzung zu optimieren. Diese 

Aufgabe ist sehr komplex. Aufgrund dieser Komplexität tendieren viele Entwurfsmethodiken zu einem Teilentwurf 

oder einem partiellen Entwurf. Oft wird nur die Struktur einer Anwendung entworfen. Die Semantik wird z.T. als 

intuitiv erklärt vorausgesetzt. Es wird dann angenommen, daß - auf der Grundlage der aus der Struktur ableitbaren 

generischen Operationen und Transaktionen - jede Funktion auch in einfacher Form dargestellt und entwickelt 

werden kann. Da 4GL-Sprachen eine benutzerfreundliche Notation nachgesagt und deshalb eine Benutzeroberfläche 

nicht entwickelt wird, ist ein Datenbanksystem nach wie vor extrem benutzerunfreundlich. Viele DBMS erlauben 

deshalb die Erstellung von sichtenbasierten Formularen bzw. Menüs. Aufgrund dieser Vorgehensweise wird durch 

die Struktur einer Anwendung die gesamte Funktionalität und Benutzbarkeit durch den Strukturentwurf dominiert. 

Der Datenbankentwurf ist Bestandteil jedes Datenbankkurses. Zwischen 30 und 50 % des Umfanges von Datenbankbüchern 

werden diesem Teil gewidmet. Oft wird z.B. in der folgenden Reihenfolge vorgegangen: Struktur des 

Entwurfsprozesses, Anforderungsanalyse, Modellierung mit dem Entity-Relationship-Modell, relationale Modellierung 

und Normalisierung, objekt-orientierte Modellierung, Sichtenentwurf, Übersetzung in logische Datenmodelle, 

physischer Entwurf, verteilte Datenbanken, Tuning und Optimierung. Eine Methodologie für den Datenbankentwurf 

ist damit jedoch nicht gegeben. Eine Methodik 2 wird allerdings durch die Reihenfolge der Kapitel vorgegeben. 

2 Eine Methodik, die auf der strukturellen Rekursion aufsetzt, besteht i.a. aus drei Bestandteilen: einer Sprache zur Darstellung der Urteile 

(Entwurfsurteile), einer Menge von Regeln zur Konstruktion neuer Urteile und einer Menge von Konsistenzregeln, mit denen falsche 

Konstruktionen ausgesondert werden können. Eine Entwurfsentscheidung geht meist als Urteil über die darzustellende Realität ein. 

und 

Mod IS


Diese oft empfohlene, aber den Entwerfer grausam überfordernde Methodik bedeutet, für jeden Schritt ein anderes 

Modell zu verwenden: für die Anforderungsanalyse ein Fragment der natürlichen Sprache, für den Strukturentwurf 

das Entity-Relationship-Modell, für den Semantikentwurf das relationale Modell, für den operationalen Entwurf eine 

Methodik der Softwaretechnologie, für den physischen Entwurf verschiedene Datenstrukturen, für das Tuning ein 

operationales Modell etc. Die Beschränkung ist nicht nur, daß kaum jemand alle diese Modelle im Detail beherrscht 

und filigran anwenden kann, sondern das damit verbundene Abbildungs- und Konsistenzproblem. Man entwirft mit 

einem Modell, setzt diesen Entwurf im anderen Modell fort und muß die bisherigen Resultate in das andere Modell 

transformieren. Dabei geht meist bereits entwickeltes Entwurfswissen verloren und muß neu entwickelt werden. Hier 

verwenden wir dagegen durchgehend ein erweitertes Entity-Relationship-Modell, das es gestattet, das vollständige 

Entwurfswissen in nur einem Modell darzustellen. Die Transformation auf die logischen und physischen Modelle 

ist bereits seit längerer Zeit vollständig erforscht. Diese Transformation kann uns ein Entwurfswerkzeug vollständig 

abnehmen. 

Wenige geübte Datenbankentwerfer sind in der Lage, beim Strukturentwurf auch die Funktionalität, die Benutzbarkeit 

und die Effizienz in Einklang zu bringen. Diese ‘Genialität’ wird jedoch nur in jahrelangem Training erworben 

und ist spätestens bei einer Modifikation der Anwendung, die bereits meist nach kurzer Einführungszeit erfolgt, zum 

Scheitern verurteilt. Deshalb benötigen wir eine Entwurfsmethodik, die Struktur, Funktionalität, Benutzbarkeit und 

Effizienz in gleichem Maße berücksichtigt. 

Die Qualität von Schemata wird bestimmt durch: 

1. Für den Benutzer: 

Natürlichkeit impliziert ein einfaches Verstehen und einfaches Formulieren von Anfragen. Deshalb ist für die 

Akquisition die Darstellung semantischer Einheiten von zentralem Interesse. Schemata werden 

leicht lesbar und selbsterklärend, wobei enkryptische Namen vermieden werden und die Bedeutung einfach 

erhalten werden kann. Dadurch werden Integritätsbedingungen in verständlicher Form formulierbar 

und künstliche abstrakte Typen vermieden. 

Minimalität impliziert ein eindeutiges Verstehen der Komponenten des Schemas. Unterschiedliche Gesichtspunkte 

werden vermieden. Ein Schema ist konzeptuell minimal, wenn nicht alle möglichen Teilfälle, 

sondern nur die relevanten dargestellt werden. 

Sichtendarstellung für einzelne Benutzergruppen unterstützt die Verständlichkeit und die Benutzbarkeit des 

Schemas. 

Systemunabhängigkeit und das Ausschließen unnatürlicher Systembeschränkungen ermöglichen eine Konzentration 

auf die inhaltlichen Konzepte der Anwendung. 

Verständliche Darstellung komplexer Zusammenhänge vereinfacht das Erfassen und Verstehen komplexer 

Integritätsbedingungen und eine hohe Anzahl von Integritätsbedingungen. 

Ein Verständnis der Speicherung gibt dem Benutzer einen intuitiven Überblick über die Implementation 

der Datenbank. 

2. Für die Unterstützung durch das System: 

Wenig oder keine Redundanz verringert den Pflegeaufwand, der durch das System zu leisten ist. Damit 

werden Inkonsistenz und update-Anomalien vermieden. Mitunter ist eine Pflege so aufwendig, daß kein 

System diese leisten kann. 

Durch Systemunabhängigkeit wird eine Portierbarkeit erleichtert. 

Durch eine adäquate Sichtenunterstützung kann jede Sicht eines Benutzers auf einfache Weise unterstützt 

werden. 

3. Für die Anwendung: 

Mod IS 

Bei Vollständigkeit werden alle Aspekte der Anwendung, die notwendig sind, repräsentiert.


Durch Flexibilität bedingen Änderungen in der Anwendung nicht sofort Änderungen aller Teilschemata. 

Werden relevante Dinge repräsentiert und nicht alle möglichen Situationen, dann kann ein Schema einfacher 

gepflegt, erweitert und verstanden werden. 

Betriebliche Modelle dienen der Repräsentation betrieblicher Einschränkungen (operationale Beschränkungen, 

Gesetze, Regulierungen, Planung, Kontrolle, etc.). 

Daraus können Prinzipien des Entwurfes abgeleitet werden: 

• Was wird modelliert? In einer korrekten Repräsentation verkörpert jeder dargestellte Typ Objekte einer bestimmten 

Klasse in der realen Welt und jede relevante Klasse wird aufgezeigt. Der Grad der Detailliertheit 

wird nur soweit vorangetrieben, daß Anfragen und Updates in einer einfachen Form möglich sind, aber zugleich 

soweit, daß die Entwicklung von Anwendungen unterstützt wird. Prinzipiell werden nur stabile Strukturen 

repräsentiert. Teiltypenhierarchien können ansonsten bis ins letzte Detail aufgespleißt werden, so daß jede 

Änderung in der Anwendung eine andere Hierarchie bringt. 

• Die Darstellung semantisch sinnvoller Einheiten ist so einfach wie möglich zu gestalten. Damit ist die 

Bedeutung einfach herauslesbar. Jede semantische Einheit besitzt eine einfach erklärbare Bedeutung. 

• Jeder Fakt wird nur einmal repräsentiert, wodurch Anomalien vermieden werden. Jede Assoziation erscheint 

nur einmal. Zerlegbare Fakten sollten in Abhängigkeit von den updates auch zerlegt dargestellt werden. Beispiele 

eines ungünstigen Entwurfes sind solche, die eine update Anomalie besitzen. Surrogat-Attribute werden 

demzufolge erst auf logischen Niveau wirksam. 

• Durch Sicherung der Identifizierbarkeit jeden Faktes wird auch eine Modifikation einzelner Fakten ermöglicht. 

• Durch eine saubere Unterscheidung der Nullwerte (unbekannt, nicht anwendbar, etc.) kann auch eine entsprechende 

Funktionalität unterstützt werden. Nicht anwendbare Werte deuten auf unsaubere Modellierung. 

Eine bessere Modellierung ist die Darstellung durch Teiltypen. Schwierigkeiten bei Anfrageauswertung und 

-formulierung können so umgangen werden. Es gibt strukturelle Nullwerte und Ausnahmenullwerte. 

• Wir benötigen klare Regeln für die Zuordnung zu den Konzepten (Attribut oder Entity-Typ oder Relationship- 

Typ). Mitunter muß auch für Konzepte, die eigentlich durch Attribute dargestellt werden, ein Entitytyp eingeführt 

werden. 

• Attributnamen dienen einer intuitiv verständlichen Charakterisierung von Objekten der Datenbank. 

• Hierarchische Strukturen sind meist einfacher zu behandeln. Insbesondere wird die Pflege der Integritätsbedingungen 

und die Generierung von Operationen einfacher. 

• Surrogate sollten im konzeptuellenn Entwurf nur in Ausnahmefällen verwendet werden. Modifikationen werden 

ansonsten schwieriger. 

Damit können kritische Faktoren für die Entwicklung einer Entwurfsstrategie abgeleitet werden: 

1. Ein schrittweiser Entwurf kann unterstützt werden. 

2. Rollen und Verantwortlichkeiten müssen wohldefiniert sein. 

3. Eine klare Unterscheidung zwischen allgemeinen und produktspezifischen Entwurfstechniken erleichtert die 

Migration zu anderen Werkzeugen. 

4. Das Datenwörterbuch (data dictionary) sollte auch Versionen und weitergehende Informationen enthalten. 

Mod IS


5. Der Entwurf basiert auf einem und nur einem Modell, das mindestens die gesamte Funktionalität von logischen 

Datenmodellen repräsentieren kann. 

6. Durch die Darstellung der Entwurfsentscheidungen für ein späteres Reviewing und Einführung von Checkpoints, 

denen sich Entwerfer unterwerfen müssen, insbesondere zum Einholen von Kompetenz, kann eine 

spätere Modifikation und die Diskussion von Varianten vereinfacht werden. 

7. Der Struktur-, Funktions- und Semantikentwurf wird integriert durchgeführt. 

8. Durch übersichtliche Repräsentationstechniken wird ein Entwurf intuitiv auch in seiner Entwurfsgeschichte 

verständlich. 

Außerdem muß eine entsprechende Transformationstechnik existieren, mit der ein Prototyping, z.B. in relationalen 

DBMS, erleichtert wird. 

In diesem Skript wird eine Methodik vorgestellt, die sich ein Entwerfer selbst verändern kann. Wir gehen davon 

aus, daß jeder Entwerfer seine eigene Methodik verwendet. Es gibt zwar Gemeinsamkeiten, aber die Wahl der 

Methodik hängt nicht nur von den Kenntnissen und Erfahrungen des Entwerfers ab, sondern wird auch durch das 

Anwendungsgebiet und durch die Projektpartner mitbestimmt. Deshalb wird im Skript auch dargestellt, wie man 

die Methodik, die im Hauptteil des Co-Design-Buches vorgestellt wird, durch eine eigene Methodik ersetzen kann. 

Unsere Methodik hat sich in den mehr als 100 (DB) 2 -Anwendergruppen als eine der am häufigsten und am weit 

verbreiteten Methodiken erwiesen. Neben dieser Methodik existieren viele verschiedene andere Methodiken. 

Die Modellierung wird immer von der Verfeinerung begleitet. Verifikation und Validierung dienen der Kontrolle 

der Resultate wie in Bild 1 dargestellt. 

Modellierung 

“was”, “wie”, “wo”, “wer”, “wann”, ... 

Realität 

❄ 

Modell 

✻ 

Validierung 

Wird das richtige Produkt erstellt? 

✻ 

Verfeinerung 

Verifikation 

Qualitätsforderungen 

Wird das Produkt richtig erstellt? 

❄ 

Implementation 

Abbildung 1: Modellierung, Verfeinerung, Verifikation und Validierung 

Obwohl ein Datenbankentwurf immer für eine bestimmte Umgebung und damit für eine bestimmte Plattform 

durchführt wird, sollte der Entwurf zuerst die Anwendung adäquat widerspiegeln und zuletzt erst durch die Implementationseinschränkungen 

der gewählten Plattform getragen werden. Ein solcher Entwurfszugang ist erst durch die 

Entwicklungen der Datenbanktechnologie und der -theorie während der letzten 10 Jahre ermöglicht worden. Es gibt 

erst in Ansätzen methodische Umsetzungen auf dem internationalen Markt. 

In diesem Skript stellen wir eine Zugang vor, der auf tiefliegenden theoretischen Erkenntnissen beruht. Es ist in 

diesem Skript nicht unser Ziel, die Datenbanktheorie in aller Tiefgründigkeit vorzustellen, sondern eine Methodik 

zu entwickeln, die auf den Erkenntnissen dieser Theorie beruht, diese aber nicht vordergründig verwendet. Viele der 

Tips in diesem Skript haben Lehrsätze im Hintergrund. Wir versuchen weiterhin, die Fallen und Untiefen, die mit 

ungeschickten Methodiken verbunden sind, zu vermeiden oder zu umschiffen. Dadurch wird auch eine Reihenfolge 

der Entwurfsschritte mit diktiert. 

Es gibt eine umfangreiche Literatur zum Datenbankentwurf auf der Grundlage des relationalen Modelles. Das relationale 

Modell eignet sich jedoch nur für einige Entwurfsphasen. Die Semantik und der Zusammenhang zwischen 

Mod IS


den relationalen Schemata ist nur relativ umständlich und abstrakt darstellbar. Das damit erforderliche Abstraktionsniveau 

überfordert auch aufgrund der Komplexität die Entwerfer. Selbst die ‘Perle’ der relationalen Theorie, die 

Normalisierungstheorie, erfordert vom Entwerfer umfangreiche und tiefgehende Kenntnisse. Die Werkzeuge generieren 

meist nur eine von vielen möglichen Normalisierungen, so daß eine Korrektur per Hand oft erforderlich ist. 

Aus diesem Grund hat sich das auf eine graphische Darstellung stützende Entity-Relationship-Modell für die ersten 

Entwurfsphasen durchgesetzt. Es gibt heute fast kein Entwurfssystem, das dieses Modell nicht in irgendeiner Form 

benutzt. Wir folgen diesem Trend, erweitern aber das Modell, um auch die anderen Entwurfsphasen mit diesem 

Modell durchführen zu können. 

Es gibt allerdings bislang keine Theorie der Modellierung von Informationssystemen 3 . In der Literatur finden 

sich nur einige Bestandteile einer solchen Theorie: Theorie relationaler Schemata, Theorie der Petri-Netze, Theorie 

von Workflows. Wir benötigen einen vollständigen Zugang, der eine Modellierung der Strukturierung, Funktionalität 

und Interaktivität unterstützt. Außerdem sollten Aspekte der Verteilung dargestellt werden. Unsere Theorie 

stützt sich auf zwei Darstellungssprachen: das erweiterte Entity-Relationship-Modell (HERM) und die Webseiten- 

Beschreibungssprache SiteLang, sowie der Verteilungssprache DistrLang. Mit der ersteren können wir alle datenbankbasierten 

Aspekte wie Strukturierung, Funktionalität, Verteilung und Sichten-Suiten (als Verallgemeinerung des Sichtenbegriffes) 

darstellen. Mit SiteLang können wir alle Aspekte der Interaktivität und der Einbettung von Datenbanksystemen 

in interaktive Systeme darstellen. SiteLang umfaßt neben der Darstellung von Interaktion und Stories auch 

die entsprechenden Kontextbedingungen, zu denen insbesondere der Gestaltungsrahmen, der Kommunikationsrahmen 

und der Arbeitsrahmen gehören. DistrLang stellt die Dienste und die Kollaboration für die Verteilung dar. Die 

unterschiedlichen Elemente unseres Modellierungsansatzes sind auf Seite ?? zusammengefaßt. 

Modellieren ist das Herstellen, Modifizieren, Analysieren und Nutzen von Modellen zur Herstellung von Vorstellungen 

zu Dingen der Realität. Der Modellbegriff basiert auf drei Abstraktionsmerkmalen: 

• Abbildungsmerkmal: Ein Modell stellt einen Ausschnitt der Realität dar. Es werden somit Objekte Dingen 

der Realität zugeordnet. 

• Verkürzungsmerkmal: Ein Modell abstrahiert von den Eigenschaften der Realität. Es werden nur einige “relevante” 

bzw. “wichtige” Eigenschaften dargestellt. 

• Pragmatisches Merkmal: Ein Modell wird nicht ein für alle mal bestimmt, sondern hängt von den Zeitpunkten, 

dem Anwendungskontext und den Auffassungen der beteiligten Individuen ab. Diese können sich jederzeit 

ändern. 

Damit werden in der Modellierung Urteile durch den Modellierer gefällt, welche Dinge der Realität für welchen 

Ausschnitt mit welchen Eigenschaften von Interesse sind. Es gibt eine ganze Reihe von Urteilen, die für uns von 

Interesse sind: 

• Existenzurteile konstatieren die Existenz von Dingen. 

• Belegurteile dienen dem Belegen von Beobachtungen. 

• Beziehungsurteile stellen Dinge in ihren Beziehungen dar. 

• Bestimmungsurteile dienen der Assoziierung von Urteilen mit Eigenschaften. 

• Assoziierungsurteile erlauben die Assoziierung, die Aggregation und die Komposition. 

• Abhängigkeitsurteile stellen semantische Beschränkungen dar. 

Ein Urteil ist bei weitem nicht absolut. Wir stellen deshalb die Modalität explizit dar. Die Modalität erlaubt je nach 

Urteilsart auch die Entwicklung logischer Theorien. Ein Modellierungsurteil kann eine Annahme, eine Meinung, eine 

Hypothese, eine Gedankenverbindung oder auch eine Frage darstellen. 

3 Einen ersten Ansatz liefert die Arbeit [Kas03], in der ein Theorieansatz angegeben wird. Wir verdichten diesen Ansatz im folgenden. 

Mod IS


Ein Modellierer ist ein Individuum, das in einem Kontext (z. B. der Anwendung oder in einem kulturellen Kontext) 

Urteile fällt. Oft folgt das Modellierungsurteil einer Referenzdarstellung. Demzufolge fassen wir ein Modellierungsurteil 

als ternäre Beziehung zwischen Eigenschaft, Theorien und den im Kontext agierenden Individuen auf. 

Weiterhin kann im Entwicklungsprozeß ein Urteil wieder revidiert werden. 

Redundanz kann eine sinnvolle Eigenschaft sein, sollte aber explizit erfaßt und gepflegt werden. Inkonsistenz ist 

selten sinnvoll. Vollständigkeit ist eines der Hauptkriterien bei der Beurteilung der Qualität neben diesen Kriterien. 

Ein wichtiger Problemkreis vor Einführung eines Informationssystemes ist das Abwägen, ob dieser Einsatz nicht 

zu höheren Kosten führt. Der Nutzen von Informationssystemen besteht 

1. in der gemeinsamen und parallelen Benutzung von Daten bei gleichzeitiger Benutzung unterschiedlicher Sichtweisen 

auf die Daten, 

2. in kontrollierter Redundanz von gleichen Datenbeständen, 

3. in der Unterstützung von eingeschränktem Benutzerzugriff, die auch Sicherheitsmechanismen einschließt, 

4. in der Bereitstellung verschiedener Schnittstellen für unterschiedliche Benutzungsgruppen, 

5. in der Darstellung komplizierter Beziehungen der Daten, 

6. in der Bereitstellung von Mechanismen zur automatischen Integritätserzwingung und 

7. in einer Robustheit, die einen Wiederanlauf auch nach Systemfehlern erlaubt. 

Ein Einsatz von Datenbank-Management-Systemen (DBMS) ist besonders sinnvoll 

• zur Unterstützung heterogener Benutzergruppen, die eine gemeinsame Datenhaltung präferieren, 

• falls keine oder kontrollierte Redundanz gewünscht ist, 

• falls eine Benutzerverwaltung und Authorisierung sinnvoll ist, 

• falls unterschiedliche Schnittstellen für unterschiedlich geschulte Benutzer bereitgestellt werden sollen, 

• falls komplexe Daten oder komplexe Beziehungen zwischen den Daten vorliegen, 

• falls Integritätsmechanismen genutzt werden sollen, 

• falls eine Fehlerbehandlung und Archivierung erforderlich ist und 

• falls eine geringe Entwicklungszeit für sich ändernde Anwendungen bevorzugt wird. 

Ein DBMS sollte man nicht benutzen, 

• wenn ein hoher zusätzlicher Aufwand entsteht 

• durch hohen initialen Aufwand für Hardware und Software bei geringem Nutzen durch den späteren 

Betrieb, 

• durch hohe Allgemeinheit der vorhandenen Funktionen und 

• durch die Einführung von Algorithmen zur Unterstützung von Sicherheit, konkurrierenden bzw. parallelen 

Betrieb, 

• wenn die Anwendung und die Datenbank eher einfach sind, 

• wenn Real-Zeit-Forderungen nicht vom DBMS unterstützt werden können und 

Mod IS


• wenn kein Mehrfachparallelzugriff auf Daten vorliegt. 

Das Skript beabsichtigt nicht, eine vollständige Einführung in die Datenbank- oder zumindest in die Datenbankentwurfsliteratur 

zu geben. Das Literaturverzeichnis wurde bewußt kurz gehalten 4 . Die Referenzen in [Tha00a] und 

[Tha91], sowie in [GMUW00] und [FvH89] sind stattdessen für weitere Studien zu verwenden. Wir gehen in diesem 

Skript davon aus, daß der Leser bereits grundlegende Begriffe der Datenbanktechnologie kennt. Eine Reihe von 

Fachbegriffen, die standardisiert verwendet werden, werden deshalb nicht nochmals eingeführt 5 . 

Dieses Skript konzentriert sich auf die Spezifikation der konzeptuellen, Benutzer-, Geschäftprozeß- und strategischen 

Schicht. Deshalb werden Aspekte der Darstellung auf logischer oder physischer Schicht vollständig ausgelassen. 

Für die Spezifikation von Strukturierung und Funktionalität auf logischer Sicht verweisen wir auf [Tha03]. 

Wir wollen kein XML- oder auch HTML-Buch ersetzen. Dieser Buchmarkt ist unübersichtlich und strotzt vor vorgespiegelter 

Einfachheit. Unter den soliden Einführungen sticht [KM03] hervor. Zum Storyboarding gibt es leider auch 

meist nur Erzählliteratur von Autoren, denen eine sehr kleine Website als Illustration und Erfahrungshintergrund 

dient. Zur Spezifikationstheorie verteilter Systeme auf logischer Sicht kann am besten [ALSS03, DGH03] herangezogen 

werden. Auf höherem Abstraktionsniveau existiert unserer Beobachtung nach keine einzige Literaturquelle. 

4 Die Bibliographie in [Tha00a] ist bereits länger als 50 Seiten. 

5 Stattdessen empfehlen wir [Bis95, KE96] oder den Klassiker der Modellierung [LM78]. 

Mod IS


Relationales 

Paradigma 

ER-basierte 

Struktur 

Statische ER- 

Semantik 

ER-basierte 

Prozesse 

Dynamische 

ER-Semantik 

Konzeptionelle Aspekte von Informationssystemen im Codesign-Zugang zur integrierten Entwicklung von 

Informationssystemen 

Zugrundegelegte 

Sprache 

Verwendete Instanzenwelt 

Modell zur iterativen Konstruktion der Syntax 

Theorie 

Klasse Objekte Schema AggregationBeziehungenBasistyp Grundtyp 

Mengenlehre 

Relationenalgebra 

bzw. 

-kalkül 

Tabelle Tupel relationales 

Schema 

implizit 

durch Integritätsbedingungen 

rudimentär, 

z.B. IsA 

Relation(entyp) 

Steuerbedingung 

Unterstützende 

Sichten- 

Suite 

HERM- 

Algebra 

HERM 

Abstract 

State Machines 

Temporale 

Logik 

Workflow- 

Klasse 

Workflow- 

Objekt 

Workflow- 

Schema 

HERM - - Semantik des 

Workflow- 

Schemas 

Programm 

Workflow- 

Feld 

Prozeß 

Dynamische Integritätsbedingung 

HERM Sichtenklasse Sichtenobjekt Sichtenschema Sichtentyp Kooperative 

Sichten 

Sichtentyp 

Attribut 

Attribut-Typ 

Mengenlehre HERM Klasse Objekte ER-Schema Relationship- Cluster- und Entity-Typ 

Typ 

Teiltyp 

Prädikatenlogik 

HERM - - Semantik des Statische Integritätsbedingungen 

ER-Schemas 

Datentyp- 

Semantik 

Read/Write- 

Operation 

Sichten- 

Attribut-Typ 

Interaktion Mengenlehre SiteLang Content- 

Klasse 

Content- 

Objekt 

Content- 

Typen-Raum 

Content-Typ Container Content-Typ Content-Typ- 

Attribut 

Stories (Story- SiteLang Szenario Szenarium Storyraum Story Kooperative Dialogszene Dialogschritt 

Boarding) 

Stories 

Modellierung Organisationstheorie 

SiteLang Klasse von Benutzer Akteurschema Gruppen Kooperative Akteur Rolle 

von Benutzern 

Benutzern 

Akteure 

Kollaborationsrahmevertraschemwirken 

Gruppenarbeit SiteLang Kollaborations- 

Arbeitsgruppe Kollaborations- 

Zusammen- 

Kollaboration, Zusammen- 

Aufgabe 

Kooperation wirken 

Gestaltungsrahmen 

User- SiteLang Interfaceklasse Interface Arbeitsplatzsuite Arbeitsplatz Menus Oberflächen- 

Layoutform 

Interfaces 

typ 

Arbeitsrahmen Methoden 

Auftragsklasse Auftrag Arbeitsfeld Portfolio Verfahren, Arbeitsschritt Aufgabe, Ressourcen 

des Problemlösens 

(Teil-)Lösung 

Verteilung 

Abstract 

State 

Machines 

DistLang 

Akte, 

Logfile 

Protokollinstanz, 

Kontraktinstanz 

Schema 

des verteilten 

Systems 

Komponente, Kollaborationsrahmen, 

Proto- 

Komponente, Knoten 

Architektur 

Kontrakt kolltyp, 

Logtyp 

Modellierung der Strukturierung: ER-basierte Struktur und statische ER-Integritätsbedingungen 

Modellierung der Funktionalität: ER-basierte Prozesse und dynamische ER-Integritätsbedingungen 

Modellierung der Verteilung: Schema des verteilten Systemes mit Architektur und Komponenten, sowie deren Kollaboration 

Modellierung der Interaktivität: Content-Typen und Story-Raum mit Akteuren unterlegt durch Arbeits-, Kommunikationsund 

Gestaltungsrahmen 

Sichten-Suiten zur Unterstützung der Interaktivität und Verteilung: Sichtenschema mit Sichtentypen 

IS ADD


1.2 Computer Science - an Engineering Discipline 

die vier Quellen der modernen Informatik 

Mathematik mit den 4 Prinzipien 

1. Abstraktion 

2. Strukturierung im großen und im kleinen 

3. Evolution im im großen und im kleinen 

4. Kollaboration 

Electrical engineering und die Kunst der Hardware 

Applications such as medical, biological, .... computer science 

Engineering as the art of building with completely different success criteria 

Übung: 

• “Scientists look at things that are and ask ‘why’; engineers dream of things that never were and ask ‘why 

not’.” (Theodore von Karman) 

• “Engineers use materials, whose properties they do not properly understand, to form them into shapes, 

whose geometries they cannot properly analyse, to resist forces they cannot properly assess, in such a 

way that the public at large has no reason to suspect the extent of their ignorance.” (John Ure 1998) 

• 

Lesen und Interpretieren eines Anwendungsschemas 

Language Layers of Specification 

Specification Engineering: Separation and Abstraction 

1. Declaration layer based on logical formulas or constructs description 

2. Technical layer, e.g., methods for maintenance, by rules for compensation, enactment strategies, auxiliary 

methods 

operational semantics 

3. Technological layer under explicit consideration of implementation and refinement context 

application 

4. Organizational layer by integration into the architecture of the system, by obligations for users and for components 

of the system 

establishment 

5. Economical layer: (economical and technological) feasibility, quality satisfaction 

6. Handling satisfaction of properties and predicting changes of satisfaction 

7. Optimisation for evolution and adaptation 

8. Experiences utilisation for innovation and generalisation


Engineering 

see Encyclopedia Britannica 

ingenerare, “to create” and/or “to contrive” 

application of science to the optimum conversion 

of the resources of nature to the uses of humankind 

The field has been defined by the Engineers Council for Professional Development, in the United States, as the creative application of 

“scientific principles to design or develop structures, machines, apparatus, 

or manufacturing processes, or works utilizing them singly or in combination; or to 

construct or operate the same with full cognizance of their design; or to forecast 

their behaviour under specific operating conditions; all as respects an intended function, 

economics of operation and safety to life and property” 

The term engineering is sometimes more loosely defined, especially in Great Britain, as the manufacture or assembly of engines, machine 

tools, and machine parts. 

The words engine and ingenious are derived from the same Latin root, ingenerare, which means “to create.” The early 

English verb engine meant “to contrive.” Thus the engines of war were devices such as catapults, floating bridges, and assault towers; 

their designer was the “engine-er,” or 

The counterpart of the military engineer was the engineering: military - civil - , who applied essentially the same knowledge 

and skills to designing buildings, streets, water supplies, sewage systems, and other projects. mechanical - chemical - industrial 

Associated with engineering is a great body of special knowledge 

preparation for professional practice involves extensive training in the application of that knowledge 

standards of engineering practice 

are maintained through the efforts of professional societies, usually organized on a national or regional basis, with each member acknowledging 

a responsibility to the public over and above responsibilities to his employer or to other members of his society. 

functions: (scientist; to know verified, systematized knowledge of the physical world), 

(engineer; to do and bring knowledge to bear on practical problems) The scientist adds to the store of verified, systematized 

knowledge of the physical world; the engineer brings this knowledge to bear on practical problems. Engineering is based principally 

on physics, chemistry, and mathematics and their extensions into materials science, solid and fluid mechanics, thermodynamics, transfer and 

rate processes, and systems analysis. 

Unlike the scientist, the engineer is not free to select the problem that interests him, solves problems as they arise 

solution must satisfy conflicting requirements 

(technical, technological, economical, ..., social) 

Usually efficiency costs money; safety adds to complexity; improved performance increases weight. The engineering solution is the optimum 

solution, the end result that, taking many factors into account, is most desirable. It may be the most reliable within a given weight limit, the 

simplest that will satisfy certain safety requirements, or the most efficient for a given cost. In many engineering problems the social costs are 

significant. 

Engineers employ two types of resources: materials, information and energy . Materials are useful because of their properties: their 

strength, ease of fabrication, lightness, or durability; their ability to insulate or conduct; their chemical, electrical, or acoustical properties. 

Important sources of energy include fossil fuels (coal, petroleum, gas), wind, sunlight, falling water, and nuclear fission. Since most resources 

are limited, the engineer must concern himself with the continual development of new resources as well as the efficient utilization of existing 

ones.


1.3 Modelle der Informatik sind sprachbasiert 

Denn eben, wo Begriffe fehlen, 

Da stellt ein Wort zur rechten Zeit sich ein. 

Mit Worten läßt sich trefflich streiten, 

Mit Worten ein System bereiten, 

An Worte läßt sich trefflich glauben, 

von einem Wort läßt sich kein Jota rauben. 


Sprachen sind meist konstruktiv gegeben. Damit betrachten wir semantische Dreiecke wie z.B. die folgenden in 

Bild 2. Man kann die vollen Aufwand in eines der Ecken verwenden oder auch das Gesamtbild betrachten. 

Parallelisierung 

Semantik 

Zeit 

Kommunikationsbedarf 

Komplexität 

der Aufgabe 

Syntax 

Pragmatik 

Energie 

Information 

Abbildung 2: Das linguistische, Schimmler und quantenphysikalische Dreieck 

Als Lehre aus dem Einführungskapitel betrachten wir das Co-Design-Dreieck in Bild 3. Es hat seine Wiederspiege- 

Kollaboration 

Strukturierung 

Entwicklung 

Integrität 

Verwaltungsfunktion 

Akteur 

Struktur 

Sicht 

Anfragefunktion 

Modifikationsfunktion 

System 

Aufgabe 

Abbildung 3: Das Co-Design-Dreieck 

lung in den unterschiedlichen Aspekten wie im unteren Teil von Bild 3. 

Why we do not concentrate on object-oriented approaches? 

• 88 pitfalls of object-orientation (see DBS I) 

• Encapsulation challenge (146 UML diagrams) 

• Model multiplicity challenge (errors encountered in oo models) 

• Complexity management challenge 

IS ADD


Generelle Aspekte von Informationssystemen 


Funktionalität 

Interaktivität 

Verteilung 

Qualität 

Struktur 

Statische 

Integritätsbedingungen 

Prozesse 

Content-Objekte 

Dynamische 


Stories 

Dienste 

Kollaborationsrahmen 

Szenarien 

Aufgaben 

Benutzergruppen 

Konzeptionelle Spezifikation von Informationssystemen 

ER-Schema 

Datenbank-Maschine 

Interaktionsraum 

Diensteraum 

Content-Typen 

Story-Raum 

Drehbuch 

Architektur 

Sicht Container 

Funktionalität Szenen 

Akteure 


Logische Spezifikation von Informationssystemen 

relationales Schema 

XML-Schema 

... Schema 

Stored procedures 

Transaktionen 

Programme, Trigger 

Dialogverwaltungssystem 

Oberflächen 

Dienste- und Kollaborationsverwaltungssystem 

Verteilung, Protokolle, Qualität 

Abbildung 4: Integrierte Entwicklung von Strukturierung, Funktionalität, Interaktivität und Verteilung 

IS ADD


Wir wollen im weiteren zeigen, wie sich die vier Aspekte Strukturierung, Funktionalität, Interaktivität und Verteilung 

verbinden lassen. Eine allgemeine Vorstellung der integrierten Elemente vermittelt Bild 4. 

Wir beabsichtigen, den vollen Entwicklungsprozeß in seiner Gesamtheit zu begleiten. Deshalb ist für eine Spezifikation 

eines Informationssystemes auch eine Beschreibung der Datenbank-Maschine und eine Beschreibung der 

Content-Objekte und des Story-Raumes sowie des Diensteraumes notwendig. 

IS ADD


1.4 Modellierung und Synthese 

1.4.1 Introducing modelling and synthesis for structural integrity 

Engineering is oriented towards encapsulation of of experiences with design problems pared down to a manageable 

scale. 

Real-life engineering is full of uncertainties and risks, impossible to replicate effectively in a formalised way in a 

text. 

• Engineering component means any engineering structure, which may be constructed from several interconnected 

elements into a single entity. 

• Effectively withstanding loads is defined as the capacity to accept service loads without exceeding either the 

specified maximum stress, specified maximum deflection, of both of this specifications. 

force - moment - pressure 

information processing capacity, traffic intensity 

• Service loads are those loads, specified or unspecified, that the designer considers as creditable to be imposed 

on the component during its service life. 

Two main factors 

• service load estimation 

• structural modelling 

Assumptions of engineering 

1. Engineers are inherently concerned with failure and our vision of success is t develop modelling tools to avoid 

it. 

2. Engineering failures may be categorised as technical, operational or unpredictable. 

3. Incentives to avoid engineering failures are related to failure intensity - the degree of seriousness of the failure. 

4. Failure is essentially related to risk: given extreme conditions, all structures and systems can fail. 

• Generate design specifications that best meet the required operating conditions of the system with acceptable 

levels of risk; 

• Identify the limits of know-how associated with the structure or system and assign factors of ignorance 

(commonly referred as factors of safety) to cope with these limits, also within acceptable levels of risk 

(notion of worst credible accident). 

Designers are typically only aware of “normal”, or expected, or most likely operating conditions 

Be aware of abnormal situations. 

Estimation is a euphemism for informed guess. 

• heuristic rules of thumb 

• insurance against loss 

Key elements of engineering 

• work is well-spaced


• assumptions and simplifications are stated unambiguously 

• the arguments unfolds in a logical sequence 

• good balance between algebra and calculation 

• useful intermediate values are calculated 

• important intermediate results are highlighted 

• related results are summarised 

• you know when you have got a ridiculous answer 

• awareness of meaningful accuracy 

Structural distillation 

process of structural decomposition into meaningful components 

• simple engineering components 

• simple behaviour 

meaning component models 

focus on the way a system is to be used; operational loads 

1.4.2 Design against failure 

based on integrity constraints etc, 

“The concept of failure is central to the design process, and it is by thinking in terms of obviating failure that 

successful designs are achieved. It has long been practically a truism among practicing engineers and designers that 

we learn much more from failures than from successes. Indeed, the history of engineering is full of examples of 

dramatic failures that were once considered confident extrapolations of successful designs; it was the failures that 

ultimately revealed the latent flaws in design logic that were initially masked by large factors of safety and a design 

conservatism that became relaxed with time.” Henri Petroski, 1994 

• study of properties and operating 

• predictive power of experimental science 

Design choices 

Engineering component 

Operating conditions 

Failure focus 

analysing each component for its influence on the eventual failure 

• Design variables: material, local character (static loading, time dependent loading), geometry (distribution, 

stress intensity factors), environment


• Failure focus: rupture yielding, excessive deflection, fatigue, buckling, wear, corrosion, stress corrosion, creep 

Failures due to 

• the component breaks 

• the component sustains plastic, nonrecoverable, deformation 

• the component experiences a time dependent failure mechanism known as fatigue 

• the component experiences a form of elastic instability with large lateral deflections under compressive loading 

• at elevated temperatures there is a long-term, relatively slow, plastic deformation of the component under steady 

load 

• the component experience elastic or plastic deformation beyond some permitted bound 

• one r more surfaces of the component suffer local failure due to high local rubbing or concentrated loads 

• the material suffers some form of degradation or chemical conversion 

based on material selection 

• will it work 

• will it last 

• can it be made 

• can it be done within specified limits 

Kinds of Exceptions 

Exceptions caused by errors: operation errors, design errors, organizational errors, hardware errors 

explicit error treatment 

recovery management based on explicit specification of errors 

Exceptions caused by randomness or non-determinancy: appear and vanish at any point of time 

cannot be eliminated not described 

extensions of recovery management? 

Exceptions caused by incompleteness: modelling, specification incomplete due to complexity, limitations of 

languages and abilities 

robust system specification? 

Exceptions as systems flexibility: exceptions as ‘normal’ states or ‘normal’ reactions 

exception handler: exceptional situations and correct treatment 

Occurrence of Exceptions: Incompleteness of specifications as “modelling gap” 

Reasons, causes 

Possible resolution 

incomplete knowledge 

negated specifications 

incomplete coverage 

robust specifications 

macrodata modelling 

redesign to microdata 

inability to represent 

approximative specifications


Occurrence of Exceptions: Insufficiency to represent the current knowledge 



implementation restrictions 

extending by theories and languages 

advanced logics 

restricted attention of developers 

⇈ scope of reference models 

non-axiomatizabilty 

change of logics 

locality of reasoning 

interference reasoning 

Occurrence of Exceptions: Dynamic changes over time due to evolution 



change-sensitive normalization change of normal form 

time overload and mingling separate TA, user, validity time 

non-temporal types 

temporal types 

too restrictive models 

flexibility 

instability of schema 

dynamic schemata 

temporary runtime error 

similar to 9 kinds of nulls 

Occurrence of Exceptions: Hidden cases due to limiting to “normal case” 



pragmatic assumptions 

explicit modelling 

hidden assumptions 

iterative testing 

self-restrictions 

detection of reasons 

restricted scope of users 

education, sharpening 

overlooked cases 

analysis, verification 

1.4.3 Design synthesis of some generic engineering components 

1.4.4 Design of connections 

1.4.5 Revisiting structural integrity of engineering systems 

Problem solving strategies: An engineering culture 

1.4.6 The evolution of problems 

1.4.7 Economic, social and environmental issues


1.5 Probleme der Entwicklung von Informationssystemen 

Übung: 

Lesen und Interpretieren eines Anwendungsschemas 

1.5.1 Die Theorie der konzeptuellen Modellierung 

Siehe Manifesto (Kapitel 1) im Handbuch: 

Modellierung als Programmierung von “morgen” 

1. Assembler-Programmierung 

2. Programmierung der zweiten Generation mit Compiler 

Verlust der Hardwareprogrammierung 

physische Unabhängigkeit 

Programmierung mit Konstrukten 

3. Programmierung der dritten Generation mit Compiler 

Verlust der externen Optimierung 

logische Unabhängigkeit 

Damit bald: 

• Modellierung 

• Modellierung mit Konstrukten 

• Modellierung mit Compiler 

There is no “Swiss Knife” for models, modelling, to model!!!!


1975 1985 1990 1995 2000 2004 2006 2008 2010 2012 

Business applications 

Internet 

Content 

Components 

Banking 

Artificial intelligence 

XML 


Engineering applications 

Complexity 

Standards 

Usability 

gains: 

+ application 

+ decomposition 

losses: 

- exclusivity 

+ usability 

+ HC interfaces 

+ MVC 

- simplicity 

- faith 

+ availability 

+ services 

+ infrastructure 

+ adaptation 

+ generation 

+ context 

- homogeneity - centralisation 

- Seeheim/Arch 

- redundancy freeness 

- programming culture 

Abbildung 5: Modern Kondradjeff Cycles of Computer Science 

+ production 

+ architectures 

+ composition 

- programming 

Modellierung: Verfahren zur Konstruktion von Modellen, die der Gewinnung oder Vermittlung von Erkenntnissen 

oder als Ersatz der Funktion dynamischer Systeme dienen. Die Modellierung kann rein semiotisch in Gestalt 

abstrakter zeichensysteme erfolgen (mathematische, logische Modellierung), der Schaffung realer Modelle auf einer 

bestimmten stofflich energetischen Grundlage (künstliche, natürliche Modelle) dienen und für den zeitweiligen 

oder dauerhaften Ersatz der Funktion bestimmter objektiv-realer Systeme Verwendung finden. [Meyers Neues Lexikon, 

VEB Bibliographisches Institut Leipzig, 1974, Band 9, 463] (leider sind die anderen Lexika ohne eine solche 

Definition) 

Verfahren: Methode, mit deren Hilfe ein Subjekt einn bestimmten Typ von Aufgabe löst, indem es ein Modell 

als ... Repräsentanten bestimmter Eigenschaften eines Originals zweckentsprechend herstellt und im wesentlichen 

zur Informationsgewinnung über das Original benutzt [Philosphisches Wörterbuch, VEB Bibliographisches Institut 

Leipzig, 1971, Band II, 733] 

Hauptabschnitte: 

1. Auswahl oder Herstellung eines zweckentsprechenden Modells, ausgehend von der gegebenen Aufgabe, den Eigenschaften 

des Originales und den Bedingungen der Situation; 

2. Bearbeitung des Modells zwecks Gewinnung von zusätzlichen Informationen über das Original, insbesondere das 

Modellexperiment; 

3. Analogieschluss oder andersartige Ableitung von Informationen über das Original, ausgehend von 2. und vom 

Inhalt der gegebenen Modellrelation; 

4. Durchführung der Aufgabe direkt gegenüber dem Original durch Nutzung der Ergebnisse von 3., zugleich als ihre 

Verifizierung and als Entscheidungsgrundlage über die gegebenenfalls zyklische Fortsetzung des Prozesses mit 1. in 

Richtung schrittweise verbesserter Modellvarianten. 

Modell: ein Objekt, das auf der Grundlage einer Struktur-, Funktions- oder Verhaltensanalogie zu einem entsprechenden 

Original von einem Subjekt eingesetzt und genutzt wird, um eine bestimmte Aufgabe zu lösen, deren 

Durchführung mittels direkter Operationen am Original zunächst oder überhaupt nicht möglich bzw. unter gegebenen


Bedingungen zu aufwendig ist. 

Modellfunktionen: 

1. Erkenntnis durch neue Informationen über das Original 

2. Erklärung und Demonstration durch Hilfsinformationen, die das Verständnis für im Prinzip bekannte, nicht absolut 

neue Erkenntnisse über das Original erleichtern bzw. ermöglichen; 

3. Indikation zum Sichtbarmachen und Messen von Eigenschaften des Originals; 

4. Variation und Optimierung mittels gezielter Operationen 

5. Verifikation von Hypothesen ode rauch technischen Konstruktionen am verkleinerten Modell 

6. Projektierung oder Konstruktion durch Reproduktion 

7. Steuerung 

8. Ersatzfunktion 

Konzeptional oder konzeptuell? 

• abgegrenzt von “konzeptionell”: eine Konzeption betreffend 

• konzeptuell: eine Konzeption aufweisend (austauschbar, unabhängig von der Implementierung) 

Theorie: System von Begriffen und Regeln 

• Theorie deskriptiv mit deduktivem System 

• Theorie induktiv mit Beispielen mit ggf. induktiver Theoriebildung 

• Theorie abduktiv 

• Theorie exemplarisch 

1. Define the Purpose of the Theory 

2. Select a Paradigm for the Theory 

3. Determine the Specific Domain, Situation, or Scope of the Theory 

4. Identify an Optimal Process on Which to Model the Theory 

5. Develop general criteria for goals, methods, and conditions 

6. Develop Goals for the Theory 

7. Develop Methods for the Theory 

8. Identify Conditions for the Theory 

9. Create a Variable Taxonomy for the Theory 

10. Finalize the Theory Prototype 

11. Formatively Research the Prototype Theory 

12. Finalize the Goals, Methods, and Conditions 

13. Write Up the Theory 

Dreieck von Resultat (Inhalt, Konzept, Symbol) 

Programmierung ist ggf. Modellierung (wie kann man dies verallgemeinern)[Darstellung von algorithmischer Modellierung] 

Zweck: Lehre; bislang: naive Theorie der Modellierung (semiotisches Dreieck, Qualitätsbegriffe (Korrektheit, Vollständigkeit), 

Vereinheitlichung der Terminologie, empirische Herangehen (was ist für den Einstieg eine gute Abstraktion 

(z.B. prozeßorientiert scheint einfacher in bestimmten Kulturkreis), Begrifflichkeiten) eigentlich Modell-Original 

und unterschiedliche Referenzmodi 

Modellierung: was ist ein Modell, woraus besteht es, Modell hat reference mode und bezieht sich auf ein “Original” 

(deskriptiv, präskriptiv, konstitutiv, prognostizierend) Modell unterscheidet sich mit Absicht vom Original (siehe 

Kaschekbeitrag zu den 3 Eigenschaften) , wobei Unterschied durch Zweck determiniert wird; Modell als Mittler 

Abbildungen innerhalb der Triade: Realität, Vorstellung, Realisierung


descriptiv: Realität2Modell 

präskriptiv: Modell2Programm 

konstitutiv 

idealisierend 

vorausschauend 

Modellieren: Erstellung eines Modells als Triple (Original, Abbild, Abbildung) 

Eigenschaften von Abbildungen: Abbildungseigenschaften (als Relation oder besser Funktion), Verkürzungseigenschaften 

(Abstarktion), Pragmatismus der Abbildung (Zweck der Modellierung) 

unter Berücksichtigung der Subjektebenen (nur Modelle innerhalb einer Gruppe kommunikationsfähig; Gruppe 

agiert als “cultural unit” 

Lehren aus anderen Disziplinen: aus der Programmierkunst für die Modellierkunst lernen 

Dimensionen der Modellierung: 

semiotische (Repräsentation durch Sprache: syntaktisch, semantisch, pragmatisch) (siehe auch Hesse: conceptualisation, 

domain, pragmatics (bei Hesse nicht)) unter Benutzung einer Sprache (metaphysical adequacy (McCarthy, 

Hayes bei Hesse)(a representation is called metaphisically adequate if the world could be ...)) mit Zeichen (siehe 

Kangassalo Folien von San Diego (auch in Vorlesung IntInfSyst WS2008)) und ggf. deren Annotation (ggf. auch mit 

Beschränkungen der Sprache 

Assoziation zur realen Welt (siehe auch Einleitung zu SDKB) 

Perception of a community/culture (willing to agree on a model) 

================= 

siehe auch Vorlesung IntInfSystKoinzepte (Kangassalo-Teil) 

Dynamic Quality Properties of Modelling 

Monotonicity: any change leads to a refinement 

Incrementality: any step is only based on new requirements or obligations and on the current specification 

Finiteness: any quality criteria can be checked in finite time applying a finite number of checks 

Application domain consistency: corresponds to the requirements and the obligations of the application domain 

Conservativeness: any model revision that cannot be reflected already in the current specification is entirely based 

on changes in the requirements. 

at least conservative and application domain consistent 

any finite modelling process can be transformed into a process 

that is application domain consistent 

if the modelling process is application domain consistent then it can be 

transformed into an incremental one if we can extract such area of change 

in which consistency must be enforced 

Modellieren:. 

Erstellung eines Modells als Triple (Original, Abbild, Abbildung) 

Eigenschaften von Abbildungen: Abbildungseigenschaften (als Relation oder besser Funktion), Verkürzungseigenschaften 

(Abstarktion), Pragmatismus der Abbildung (Zweck der Modellierung) 

unter Berücksichtigung der Subjektebenen (nur Modelle innerhalb einer Gruppe kommunikationsfähig; Gruppe agiert 

als “cultural unit” 

Lehren aus anderen Disziplinen: aus der Programmierkunst für die Modellierkunst lernen 

to model 

• to plan or form after a pattern or shape


• to make into an organization (as an army, government, or parish) 

• to produce a representation or simulation to model a problem 

• to construct or fashion in imitation of a particular model 

Problems 

• attitutes, profiles of modellers 

• style of specification 

• multi-model reasoning 

• integration 

Quality 

Static qualities for a model 

Development quality: pervasiveness, analysability, changeability, stability, testability, privacy of the models, 

ubiquity 

Internal quality: accuracy, suitability, interoperability, robustness, self-contained, independence 

Quality of use: understandability, learnability, operability, attractiveness, appropriatedness 

Dynamic qualities within a selected development approach 

executability, refinement quality, scope restriction, effect preservation, context explicity, completion tracking 

modelling properties: monotonicity, incrementality, ... 

see below 

Pitfalls 

formal versus superformal 

(1) wrong: formal specification to everybody better: take the formal specification to the implementor so that you 

know what happens and talk informally to the stakeholder and users but have in mind what kinds of ambiguities 

might appear, what misunderstandings might appear and what clarifications must be made and what questions 

should be ask to the stakeholder in order to be sure that you have the right formal underpinning 

(2) assumption often made: consistent informaiton with respect to the constraints in the schema and resulting 

assumption: complete information about each term in the schema 

Reasoning: Integrating integrity constraints and deduction 

Religious wars which model ist the right, most appropriate 

Representational models: Hui Ma + KDS: variety of viewpoints bound to one conceptual model that is 

mapped to the relational (logical) model and which are interrelated (e.g., MVD sets that conflict) with 

each other and may be used in their context without causing problems 

Overfitted types: rigid type system with lazy/liederlicher application 

Ex.: XML uses list types in most cases as set types but sometimes lists becomes important; therefore we 

use list types 

Functional dependencies together with XML: in reality is interpreted within the weaker type system (sets) 

Missing models: storage models: for implementation 

Principles: Map2DB world: Mapping property + Truncation property + Pragmatic property + Distortion property 

+ Extension property


Principles: Application landscapes: Funktionseinheiten (Wittgenstein) 

Niches (ER’07) 

Principles: CWA - closed schemata: allow to use negation as failure 

CWA querying of databases becomes possible 

Principles: OWA - open schemata: often used in XML 

Open problems and not yet solved 

Reasoning and surprises 

• (1) Given types system T (or better schema) and a weaker types system T ′ . Given constraints defined 

over T ′ . How these constraints can be mapped to constraints in T ? 

Ex. see pitfalls -¿ overfitting: XML FD’s 

• (2) Given a schema that has a precise semantics and given a schema defintion language that uses lazy 

interpretation. Find a way to express 

Forgetful mappings: like in category theory 

• (1) Given a conceptual schema, itmapping to a logical schema and the portfolio of DB usage defined 

over the logical schema . 

Which constraints of the conceptual schema can be forgotten due to the fact that the portfolio does 

not invalidate those constraints, i.e. they are maintained by the portfolio. 

Define forgetful mappings that allow to use only those constraints that are necessary for db operating. 

Define a class of constraints or soft constraints that are necessary for understanding the application 

but that are not necessary for running the application. 

Die Theorie der konzeptuellen Modellierung umfaßt: 

1. Theorie der Modellierungsbegriffe 

Auswahl einer Sprache, Sapir-Whorf-Begrenzung 

finden einer gemeinsamen Sprache (Menge von Festlegungen zum Sprachgebrauch, Übereinkunft über Benutzung) 

Semantik z.B. lexikalische Semantik mit Topics, Ontologien 

Einbettung in einen Anwendungsbereich 

siehe auch IntInfSystKonzepte mit Konzept (Name, Intension, Extension, Werteverlauf) 

(a) Bestandteile: Konzepte zur Darstellung von Struktur, Verhalten, Kausalität, Protokolle etc. 

mit einer Darstellung von Dingen durch Konzepte, mit Begrenzung der Anwendbarkeit, Modalität, Konfidenz 

durch einer Gruppe in einer Welt (d,k,a,m,k,g,w) 

mit Integritätsbedingungen (gültig, adäquat, dient dem Zweck) und Qualitätseigenschaften zur Anwendung 

der Konzepte (ggf. mit Stachowiak’scher Theorie der methodischen Ordnung (erst das Original, 

dann das Modell); 

β: ergänzt um Abstraktionsordnung (erst Abstraktum dann Konkretum)[wie z.B. beim Architekten (erst 

mock-up, Modell, dann Spezifikation; ausgehend von Begrifflichkeiten und Herangehensweisen, vorgefertigten 

Begriffen (Fenster, Türen, Mauern, Säulen))], sowie nachvollziehbarer Begründung, Wiederholbarkeit, 

Abbildung auf Wirkung; 

Regeln und Methoden zur qualitätsorientierten Entwicklung (z.B. ISO-Ansatz (Eignung für Verwendung)); 

Hegel “Schön”: Kennen des Vertrauten im Neuen; 

Architekten betrachten Hunderte von Blaupausen oder haben einen Meister; 

intuitive Behandlung von explizit darstellbaren Wissen


mit Abstraktionseigenschaft 

Fachsprache mit Begriffen 

rudimentäre Konzepte wie z.B. in UML ausgehend von Metakonzepten 

vorgefertigte Konzepte 

ggf. auch mit einer kulturkreisbasierten Methode 

(b) Referenzmodus 

Beziehung zwichen Modell und Original 

Präskriptive Beziehung (ausgehend von existierenden Originalen (Software), dann Beschreibung) 

Deskriptiv (frühe Phasen der SW-Entwicklung; erst requirements, dann Schema) 

Konstuitutive/prognostizierende 

ggf. auch mit Einbeziehung der community und der Kultur der Modellierer, Beobachter, Implementierer 

2. Theorie der Modellierungsaktionen 

als eine spezifische Theorie des Problemlösens (Istzustand, Zielzustand, Operationen zur Zustandstransformation) 

Ausrichtung (vom abstrakten zum konkreten, vom generischen zu parametrisierten zum speziellen; vom speziellen 

Beispiel zu Konzept) 

pragmatische Begrenzung (siehe amerikanischer Pragmatismus) 

Steuerung durch Qualitätssicherung (composability, controllability, most liberal, timing constraints, operating 

guideline) 

Stile der Anwendung dieser Aktionen (z.B. overlay-Modell, Specialisation model, ...)(siehe bei Stilen) 

finden einer adäquaten Sprache für die Abbildung (domain-specific language) und der entsprechenden Repräsentation 

(siehe Dezember 08 email von Ulrich Frank) 

finden von gemeinsamen, akzeptablen Begriffen 

(a) Schritte 

schrittweise, halb-algorithmische Entwicklung 

ggf. mit entsprechenden Vorgehensmodellen 

(b) Abstraktion/Verfeinerung 

1:n Verfeinerung, 

Verfeinerung bei Erhaltung von Eigenschaften 

Abstraktion bestimmt vom Zweck 

Abstraktionsarten (Konstruktionsabstraktion, Sichtweisenabstraktion, Implementationsabstraktion) 

(c) Validierung/Verifikation 

Beweisen von Eigenschaften 

Korrektheit/Vollständigkeit 

(d) Finden von Konzepten 

(e) Qualitätsmanagement 

Adäquatheitsbegriff, Robustheit, Modalität, Vollständigkeit 

(f) Transformationstechniken 

Kompilierung/Interpretation/Abbildung 

Kollaboration 

Abstraktion/Verfeinerung 

(g) Pragmatik 

im Sinne des semiotischen Dreiecks (siehe Vorlesung Abschnitt 1.2.) 

ggf. mit entsprechenden sinnvollen Beispielen 

(h) Inhalte 

Kausalität 

Statische Begriffe


3. Theorie der Modellierungseigenschaften 

(a) Gegenstand der Modellierung 

R. Kaschek: Kulturelle Einheit 

Anwendungsgebiet ggf. mit einer Fachsprache 

mit gewissem Scope 

Organisationseinheit 

Zweck der Modellierung durch community 

Auswahl der Sprache, Herangehen der community zur Bildung von Begriffen, ggf. mit stereotyping 

Auswahl der Sprachebene, der Kategorisierung, der Klassifikation, der Terminologie, der Ontologie 

(b) Qualität der Modellierung 

Anforderungen an eine Theorie der Modellierung 

(a) an die Modellierungssprache: Ausdrucksstärke, Unabhängigkeit der Konzepte, Korrektheit von Transformationen 

(b) an die Modellierungsabbildungen: 

(c) an das Modellierungsresultat: Komplexität des Modelles, an die Größe, an den Informationsgehalt 

(d) an die Möglichkeiten zur formalen Behandlung, z.B. zum Ableiten von Eigenschaften 

Messung 

• Qualität der Begriffe 

• was heißt richtiges Modell? was heißt angemessen? 

• relative (bzgl. des Modelltripels) Vollständigkeit 

• “richtig” und “korrekt” nur relativ zur verwendeten Theorie; keine absolute Korrektheit möglich 

• einfache Modelle: wofür, wann, mit welchen Partnern 

• wann ist ein Modell ausreichend (“good enough software”) 

• gut/schön, schief (“windschief”) 

• Qualität der Aktionen 

Qualität der Aktionen 

Modellqualität (nach ISO 9126, 15504) 

Qualität des Modelles (Modell: Beschreibung mit bestimmten Ziel) 

je nach Ziel, unterschiedliche Kriterien 

Validierung und Relevanz gegenüber Welt 

Qualität der Repräsentation 

reusability (context-sensitivity) 

functionality: suitablity, accuracy, interoperabilty 

maturity 

understandabiltiy (Komplexitätsmetriken McCabe, Anzahl der Elemente je Digramm, Anzahl der Kreuzungen 

von Katen, modularisation), ... 

Merkmale der Prozeßqualität für Modellerstellung und -verwendung 

(c) Ökonomie der Modellierung 

ggf. auch unter Einbeziehung von standards 

sowie mit Darstellung der kognitiven Distanz, wobei Modell einen echten Mehrwert besitzen müssen 

4. Modell-Management 

Benutzung von entsprechenden Modellfamilien in ihrem Zusammenhang ggf. auch unter Rückgriff auf attributierte 

Grammatiken 

nicht nur von Metamodellen 

je nach Zweck und daraus resultierenden Inhalten 

(a) Modifikation von Modellen


(b) Lebenszyklus von Modellen 

Fortschrittsdarstellung 

deskriminierende Faktoren, was ist Fortschritt, was ist Qualität 

ggf. auch mit Beibehaltung falscher Modelle (“Erde ist eine Scheibe”) 

(c) Ökonomie der Modelle 

Kosten: Bemessung der verursachten Kosten 

variable Nutzungskosten 

Fixkosten (Schulung, Erstellung, ... ) 

in Relation zum vermuteten Nutzen, da Modellierung eine Gemeinkostentreiber ist 

Angemessenheit ggf. auch mit einfachen, aber verständlichen Erklärungen (z.B. Atommodell) 

Risikovermeidung 

“good enough” Software 

Nutzen: 

Verhältnis von Kosten und Nutzen - Ökonomie: 

(d) Referenzmodellierung 

mit generischen Modellen 

(e) Strategie/Taktik 

Größe der Modelle (unterschiedliche Metriken für die Größe von Modellen; Verfahren zur Bewertung 

eienr Abstraktion) 

Modularisierung 

Architektur der Modelle 

5. Aspekte 

(a) Statisch 

(b) Dynamisch 

(c) Kollaborativ 

6. Theorie der Modellierungsstile 

als Ergebnis der Theorie der CM (siehe rechte Seite mindmap) z.B. auch overlay-Modellierung 

(a) Kollaboration 

der Akteure mit Kommunikation, Kooperation, Koordination sharing agreed, common representation 

(b) Reference model injection 

(c) Refinement 

(d) Separation of concern 

7. Ziel der CM 

SeparationOfConcern.eps 

• Funktionen: analog zu den Funktionen der Sprache 

• Analyse 

Domänenmodellierung (Probleme, Lösung, Prozesse, Strukturen) 

Embedded: MiL , SiL, HiL (model, software, hardware), frühe Performanzevaluierung, QoS, Robustheit, 

Business: BPM, class diagrams, CSD, business objects, IT as a landscape, cartography 

Risikobeurteilung


• Konstruktion 

von Systemen 

business: datenintensiv 

MDD, MDA, UML: CSD/CD 

embedded: berechnungsintensiv 

Mißbrauch von Werkzeugen wie MatLab, Simulink, Targetlink 

• Kommunikationsfunktion 

siehe auch Searle und Hausser zur Pragmatik der Sprachbenutzung 

multiple stakeholder 

Verständnis 

siehe Skandinavienmodell zum kommunikativen Akt (siehe β und WIS book) 

für wen: Kunde (systemnutzer, andere Stakeholder) und Entwickler (Komponentenentwickler, Leiter, 

Team member), für Zertifizierungsbehörde 

typische Quality in use Kriterien wie z.B. Verständlichkeit 

reasoning for evolution, Wartbarkeit 

Variantenbildung (insbesondere embedded aber auch business (z.B. Lagerverwaltung)) und Adaption 

System rationale 

Risiken, Aufwandsverständnis, Robustheitsbeurteilung 

Modelle zur Kommunikation 

• Ziel: Requirements; Vertragsgestaltung SLA; Produktbeschreibung, Werbung; Aufwandseinschätzung 

(Budget/Ressourcen); Entwicklungsvorbereitung; Entwurfsentscheidung; Alignment mit anderen 

Gruppen; Koordination in der Entwicklung; Wissensweitergabe und Bewahrung (Handbuch, 

Schulungen, Seminare; Systemdoko; Handlungsanweisungen) 

• Eigenschaften: je nach Zweck und Ziel; Veranschalichung; Durchgängigkeit; einheitliche Begriffswelt 

(Glossar); Einfachheit (bzgl. Partner)(Freihandtauglichkeit; spontan erstellbar, wenige 

Symbole, wenige Konzepte); beispielhaft; Präzision; Angemessenheit; Ästhetik; secondary 

notation (Layout, Graphische Muster (Farbcodierung)) 

• Eigene Rolle: Dolmetscher, Botschafter 

• Partnerrolle: Nutzer, Betreiber; Experten; Entwickelr; Zulieferer; Management (Auftragnehmer, 

-geber); Support 

• Modelltypen: für Prozesse; für Objekte und Verhalten; für Architekturen; preskriptiv und deskriptiv


• Prüfungsfunktion 

Verifikation, Implementierung 

Reasoning functions 

Entscheidung machen, begründen 

Vollständigkeit 

Relevanz 

weitere Qualitätskriterien 

Zachman (bewußt welche, warum, wann wo, warum, ...) 

siehe auch Kommunikation für Zertifiizierer 

Angemessenheit 

Vermarktbarkeit 

Ästhetik 

embedded: compliance, safety 

business: compliance, security 

• Dokumentation von Entwurfsentscheidungen 

-alternative, verwendete und abgelehnte Konzepte, Varianten, zugrundegelegte Modelle, Paradigmen, 

Referenzentscheidungen, Referenzmodelle, Dokumentation des modelling gaps (was wird derzeit 

betrachtet, was könnte einmal betrachtet werden, was wird nie betrachtet werden) und orthogonal 

dazu (was ist relevant) 

• Beherrschung 

• Komplexität 

Variablität 

configuration (siehe auch configuration management) 

siehe auch Modularisierung 

Unvollständigkeit, Beherrschung der Unvollständigkeit 

Beherrschung der Zerlegung (siehe Wissenschaftstheorie: Technologie) 

• Verbesserung 

• Umsetzung 

realistische und umsetzbare Umsetzungsvorschläge 

8. Resultate der CM 

• Impact: see ER08 PhD workshop 

• State of the art (Zürich 2009) 

(a) Denn sie wissen nicht, was sie tun: Passung der Modelle, Realitätsbezug, Pragmatismus, quantitativ, 

qualitativ 

(b) Babylonische Sprachverwirrung: Mittel, Zielgruppen, Schulen Domänen, Kompetenzen 

(c) It’s not a bug, it’s a feature: de-facto-Standards, Lobbyisten 

(d) Was interessiert uns unser Geschwätz von gestern: stetige Aktualisierung von Modellen im Projektfortschritt; 

Evolution; Wartbarkeit, Versionierung, ... 

(e) Jeden Tag ein neues Rad: Wiederverwendung von Modellen, Varianten von Modellen, Produktlinien 

(f) Entscheidend ist was hinten herauskommt: Wirtschaftlichkeit der Modellierung; was bringt die Modellierung, 

welche Finanzen 

(g) Konkurrenz ist das Geschäft: Inhomogenität, Standardisierung von Modellen, Werkzeuge 

(h) Laokoon forever: Komplexität, Modularisierung, Visualisierung = Zeitverschwendung?; abstrakte 

versus konkrete Syntax 

(i) Wir sind alle Traumtänzer: fehlende mathematische Grundlage; ausgefranste Syntax, unvollständige 

formale Semantik


(j) Friss oder stirb: Kommunizierbarkeit der Modelle (Verständlichkeit, kognitiver Aufwand, verschieden 

Zielgruppen 

(k) Gut leben im Elfenbeintum: fehlende Praktikabilität von Modelltransformationen (horizontal (life 

cycle, verschiedene Werkzeuge); vertikal im Entwicklungsprozess z.B. Pragrammtransformation) 

(l) Modern times: Automatisierungswahn mit z.B. ausführbaren Modellen 

(m) Wo ist der Ariadne-Faden: back tracing z.B. zum Zwecke des debugging, nachträgliches upgrading 

von Modellen 

9. Principles of CM 

siehe Brassard/Harel: Kategorisierung von Algorithmen (devide et impera, ...) 

(a) Abstraktion 

• von unten für oben (Abstraktionsschchten) 

• durch Konzentration auf einzelen Aspekte, Facceten, Komponenten, scoping, Lokalisierungsabstraktion 

• Kapselung (Implementationsabstraktion) 

• Komponentenabstraktion, class, aggregate, hierarchy 

• durch Zusammenfassung zu pattern/templates 

siehe auch: Wissenschaftstheorie was ist Abstraktion 

Modelle für Stakeholder, Nichtmodellierer (siehe auch model suites) 

siehe auch Modularisierung 

(b) Modularisierung 

Implementation and localisation abstraction 

data, functional, and control decomposition 

Explicit modularisation: skeleton-based modelling and architecturing 

interfaces and collaboration of components 

side-effect free computation and controlled effect on partners 

Implicit modularisation: through name spaces 

Advantages 

separation of concerns, discovery of basic concepts, validation and verification of development, efficiency 

of tool support, scoped changes, evolution and extension, analysability, conservativeness, incrementality, 

testability 

Disadvantages 

does not support agile development and brute-force prototyping 

SOA ML wie wird component zugeschnitten z.B. geschäftsbezogen 

Komponente 

Schnittstellen: Protokolle, Funktionen, Parameter, Wertebereiche 

Verantwortlichkeiten 

Ggf. nach Herangehensweise von Technischer Architektur 

• Sichten (-gliederung) (Kontextsicht (technische Infrastruktur), Struktursicht, Verhaltenssicht, Abbildungssicht, 

Anwendungssicht (Quasar) 

• Abstraktion, hierarchische Gliederung u.a. Abstraktionsarten


• Zerlegung nach Zuständigkeiten 

• Schnittstellen mit Zusicherung 

• konzeptionelle Integration 

Probleme die dabei zu lösen sind 

• Bezüge und Abhängigkeiten 

• Unvollständigkeit und Ungenauigkeit 

• open world potential composability 

Konsistenzsicherung zwischen Sichten 

Moduldefinition 

Architektur als logische Architektur 

Modularisierung nach Parnas (siehe Artikel zu aspektorientierter Programmierung) unabhängige Units of 

deployment, maintenance Sichten (reformulation, representation change; J.-D. Zucker) und Abstraktion 

(domain hiding, co-domain hiding, domain reduction, co-domain reduction, domain aggregation, transformation; 

J.-D. Zucker) meta-structures nach Thalheim funktionale Dekomposition Hierarchisierung, 

Layers (Schichtenbildung), Komposition Unabhängigkeitskonzept, Orthogonalisierung 

Parametrisierung 

Modularisierung bei Architekturen muß mit gewählten Sichtweisen harmonisierbar sein (Kontext-, Daten- 

, Funktionen- und Funktionsweisearchitektur)(ggf. andere Arten von Harnesses für jede Art) 

Parnas principle of information hiding 

Liskov principle of substitutability (Andere Formulierung von totalem Polymorphismus): Wenn es für 

jedes Objekt O 1 vom Typ S ein Objekt O 2 vom Typ T gibt, so daß sich für alle Programme definiert in 

T das Verhalten nicht ändert, wenn O 2 durch O 1 ersetzt wird: Dann ist S eine Subtyp von T . (Liskov 

Prinzip, 1988) 

Skelett-Technik bzw. Kristallisationstechnik zur Modularisierung: Modalisierung durch Einführung eines 

Skeletts mit expliziter Assoziation von Teilstrukturen zu Skelett- Elementen und Herausfaktorisierung 

von Bindern zu anderen Skelett-Elementen 

Modularisierung nutzt Abstraktion 

• Komponentenabstraktion: Generalisierung, Aggregation, Klassifizierung; Skelett- Technik zur Kristallisation 

• Lokalisierungsabstraktion: Lokalisierung des Verständnisses;; Dekontextualisierung; was gehört zusammen, 

name space 

• Implementationsabstraktion: gemeinsame Nutzung von Komponenten, Separation input/output/sharing 

from control; components hide the internal details and processing from each other 

Data, functional, and control decomposition 

• Explicit modularisation: skeleton-based modelling and architecturing, interfaces and collaboration 

of components, side-effect free computation and controlled effect on partners 

• Implicit modularisation: through name spaces, Algol 60 functions as parameter 

Principle of syntactical substitutability: If a composition system or module only binds the declared hooks 

of the declared composition interface, the composition system can ensure that data are exchanged only 

for variants that have syntactically compatible composition interfaces. 

• Architektur 

ggf. auch für Pattern von Architekture 

siehe auch embedded SOA 

ganzheitliche Architektur 

• Dimension 1:


• contextual : why 

• what: conceptual 

• how: logical 

• with what: physical 

• Integrated architecture framework (IAF) in 3 Dimensionen 

• orthogonal dazu: 

• Business aspects (business (services), information (services)), 

• IT aspects (IS, Technology infrastructure) 

• orthogonal dazu (als dritte Dimension): security, governance 

SAP-Umfrage 2008 

Architektur stark mit Organisation verwoben, Abstimmung, Politik 

Evolutionsstrategien zur Weiterentwicklung von Produkten 

Enterprise SOA for mid-size companies (Architecture of AP /ByDesign (R. Buck- Emden, J. Boeder, 

B. Gtoene, M. Luenzmann; internal SAP, 2008) 

β-Ansatz wie für workplace and workspace 

siehe auch Vorlesung IntInfSyst 

• logische 

• story space architecture 

• physische 

einschließlich Kontextarchitektur 

(c) Kopplung 

lose und enge Kopplung, eager/lazy enforcement 

10. Special approaches 

• instance-based CM 

similar to ER’08 PhD workshop: test-driven CM 

• model suites 

• co-design 

11. Choices for Specification: Agents 

Context or localisation abstraction 

Distributed data, operation and control with isolation of effects and explicit macro-consistency enforcement 

Submachines collaboration through specified communication, coordination and cooperation, 

Advantages 

separation into local and global behaviour, explicit scopes of functions, user oracles and open specifications, 

monotonicity, testability, changeability, monotonicity, incrementability, interoperability, self-contained, independence 

Disadvantages 

separation of functions depending on agents, abstraction


The theory fundamentals for modeling 

set theory 

graph theory 

combinatorics 

mathematical logics 

construction theory 

The software development or generally the modelling process is intentionally or explicitly ruled by a number of 

development strategies, development steps, and development policies. Modelling steps lead to now specifications to 

which quality criteria can be applied. Typical quality criteria are completeness and correctness in both the syntactical 

and semantical dimensions. We assume that at least these four quality criteria are taken into consideration. The 

modelling process can be characterised by a number of (ideal) properties: 

Monotonicity: The modelling process is monoton in, if any change to be applied to one specification leads to a 

refinement. It thus reflects requirements in a better form. 

Incrementality: A modelling process is iterative or incremental if any step applied to a specification is only based 

on new requirements or obligations and on the current specification. 

Finiteness: The modelling process is finite if any quality criteria can be checked in finite time applying a finite 

number of checks. 

Application domain consistency: Any specification developed corresponds to the requirements and the obligations 

of the application domain. The appropriateness can be validated in the application domain. 

Conservativeness: A modelling process is conservative if any model revision that cannot be reflected already in the 

current specification is entirely based on changes in the requirements. 

Typical matured modelling processes are at least conservative and application domain consistent. Any finite modelling 

process can be transformed into a process that is application domain consistent. The inversion is not valid but depends 

on quality criteria we apply additionally. If the modelling process is application domain consistent then it can be 

transformed in an incremental one if we can extract such area of change in which consistency must be enforced. 

Assumptions of Layered Modelling 

We elaborate one kind of modelling in more detail. Layered modelling is based on modularisation and on architectures 

of the system. The language layering approach we use has already been reported in a similar form in [Wal97]. 

Layered modelling is based on the architectural assumption that the system can be separated into components 

and a general layering is achievable. We base layered modelling on the unique name assumption, the domain closure 

assumption, and the universal machine assumption. We may use the closed world assumption and the unique meaning 

assumption. Layered modelling is not restricted to the last two assumptions. 

In general, we use architecture-driven development that starts first with the prescription of the architecture pattern 

and style. The agent-oriented specification of allows the development of a system as a collaborating society of subsystems. 

This society uses shared functions where the sharing is based on contracts for the usage of these functions, 

on workflows that describe the cooperation among these sub-systems, and on implicit communication based on the 

locations for these functions [ST07]. We may use different views of the same architecture [Sie04] such as technical 

views displaying the modules with their functionality, application views displaying activity zones depending on the 

stage of the application, infrastructure views displaying the dependence of the system from its infrastructure and 

supporting systems, or the context view that considers the whole organisational, story and application context.


Patterns and Styles of Modelling 

• pattern: 

Structure-oriented perspective: structural description of the system + semantic perspective 

Behavior-oriented perspective: behavior of the system during its lifetime 

event approaches, Petri-net approaches, predicate transition systems 

Process-oriented perspective operation of the system 

Advantages 

development methodology and scheduling, results in development strategies (top-down, inside-out, ...), analysability 

Disadvantages 

depends on whether a system will have this perspective 

• styles: 

Depending on the style of development 

Structure-oriented pattern such as 

• Compacting patterns 

• Typing patterns 

• Unfolding patterns 

• Union patterns 

system rule pattern 

separation 

pattern 

variation 

pattern 

state transition control virtual machine convenience 

pattern pattern pattern pattern 

Abbildung 6: Kind of System Rule Pattern 

Advantages 

efficient development with controlled refinement, repeatability, robustness, incrementality 

Disadvantages 

restrictions in the development style, incrementality 

• Choices for Specification: Invariants 

Separation of concern: syntax, semantics and pragmatics


Operational representation by integration of invariants into the programs or rules 

Descriptive representation with explicit specification and refinement obligations 

• Eager enforcement 

• Lazy enforcement 

• Refusal enforcement 

Advantages 

analysability, changeability, stability, testability, understandability, learnability, robustness, separation of syntax 

and semantics 

Disadvantages 

refinement quality, scope restriction, effect preservation, context explicity, monotonicity, incrementality, completeness 

of invariant sets, reasoning and axiomatisation restrictions 

• Choices for Specification: Modelling Assumptions - Never Explicitly Given 

First by example: Entity-Relationship Model 

• inductivity (updates are essentially atomic) 

• compositionality for any type construction 

• pragmatic assumptions names by noun as standard markers 

• closed schemata 

• context-free specifications 

• canonical semantics (e.g. sets instead of multisets, ...) 

• value-identifiability of objects 

• explicitly only computable functions of low complexity 

Additional modelling assumptions of the extended ER model (HERM) 

• unique name, unique flavour, fully fledged domains 

• non-triviality of structuring of compositional types 

• strictly hierarchical schemata 

• keys with at least one component 

• inside identification, no weak types 

• explicit bounded recursion 

• Choices for Specification: Modelling Assumptions 

Syntactical assumptions 

• Unique name assumption 

• Closed world assumption 

• Domain closure assumption 

• Unique meaning assumption 

• Universal machine assumption 

Architectural assumptions such as layering 

Advantages 

generic documentation and explanation, pervasiveness, stability, testability, understandability, learnability, ubiquity, monotonicity, incrementality,


Disadvantages 

rigidity of requirements 

• Typical Styles of Functions Declaration 

Beispiele zu ASM: 

Predicative style based on the notion of a characteristic function 

Student : StudentID × Birthdate × Address → Boolean 

Functional style based rigid function presentation 

student : StudentClass × Birthdate → Date 

super : Class → Class 

Functional dependence style based on implicit invariants 

direction : Lift → Direction 

crtStateOfLift : Lift → { halting, moving } 

floor : Lift → Floor 

buttonPressed : Lift × Floor → Boolean 

property of lift 

lift states 

relationship 

relationship 

Complete separation of properties based on universal relations 

birthdate : StudentID → Birthdate 

address : StudentID → Address 

Generic style combining properties to a bundle 

getData : StudentID × property → string 

getData : StudentID × ”BirthDate” → string 

globals : Class × Field → Value 

folding of types 

• andere Qualitätscharakteristika 

pervasiveness, analysability, changeability, stability, testability, 

privacy of the models, ubiquity 

accuracy, suitability, interoperability, robustness, 

self-contained, independence 

understandability, learnability, 

operability, attractiveness, appropriatedness 

executability, 

refinement quality, scope restriction, effect preservation, context explicity, completion tracking 

modelling properties: monotonicity, incrementality, ... 

Refinement during Modelling 

• Layered Modelling 

Based on assumptions 

1. unique name assumption 

2. domain closure assumption 

3. universal machine assumption.


4. additionally: closed world assumption, unique meaning assumption 

The system can be separated into components 

1. prescription of the architecture pattern and style 

2. explicit sharing of functions 

3. views of the same architecture 

• technical views 

• application views 

• infrastructure views 

• context view 

• Deriving Plans and Primitives for Refinement 

Inside-out refinement 

Top-down refinement 

Bottom-up refinement 

Modular refinement 

Mixed skeleton-driven refinement 

These different kinds of refinement styles allow one 

Derivation of plans for refinement and primitives 

Generic Refinement Steps and Their Correctness 

The perspectives and styles of modelling rule the kind of refinement styles. As an example we consider structureoriented 

strategies of development depicted in Figure 7: 

Inside-out refinement: Inside-out refinement uses the given machine for extending it by additional part. These parts 

are hocked onto the current specification without changing it. 

Top-down refinement: Top-down refinement uses decomposition of functions in the vocabulary and refinement of 

rules. Additionally, the system may be extended by functions and rules that have not yet been considered. 

Bottom-up refinement: Bottom-up refinement uses composition and generalisation of functions and of rules to more 

general or complex ones. Bottom-up refinement also uses generation of new functions and rules that have not 

yet been considered. 

Modular refinement: Modular refinement is based on parqueting of applications and separation of concern. Refinement 

is only applied to one module and does not affect others. Modules may also be decomposed. 

Mixed skeleton-driven refinement: Mixed refinement is a combination of refinement techniques. It uses a skeleton 

of the application or a draft of the architecture. This draft is used for deriving plans for refinement. Each 

component or module is developed on its own based on top-down or bottom-up refinement.


structure-oriented strategies 

✙ 

flat 

second-order controlled 

(first-order) 

(uncontrolled) 

(one-dimensional) 

✠ ❘ ✠ ❘ 

✠ 

bottom-up 

1. design all 

basic concepts 

2. build more 

complex concepts 

from them 

mixed 

❘ (skeleton-based flat) 

top-down 1. design general 

module schema 

(bottom-up or top-down) 

1. design (skeleton) 

all main concepts 2. refine each module 

2. refine concepts (bottom-up or 

top-down) 

modular 

(design by modules) 

1. design basic modules 

with interface 

2. (iteration step) 

connect modules 

or design 

combined modules 

Abbildung 7: Structure-Oriented Specification Strategies 

inside-out 

(by neighborhood) 

1. design central type 

2. (recursion step) 

design next level 

(bottom-up or 

top-down) 

design or attach 

concept 

These different kinds of refinement styles allow one to derive plans for refinement and and primitives for refinement. 

[Bör03, Sch05] have developed a general theory to refinement. Control of correctness of refinement takes into 

account (a) a notion of refined state and refined vocabulary, (b) a restriction to states of interest, (c) abstract computation 

segments, (d) a description of locations of interest, and (e) an equivalence relation among those states of interest. 

The theory developed in [Bör03, Sch05] allows to check whether a given refinement is correct or not. 

A typical engineering approach to development of work products such as programs or specifications is based on a 

general methodology, operations for specification evolution, and a specification of restrictions to the modelling itself. 

Each evolution step must either be correct according to some correctness criterion or must lead to obligations that 

can be used for later correction of the specification. The correctness of a refinement step is defined in terms of two 

given system together with the equivalence relations. Already in [Sch05] it has observed that refinement steps can be 

governed by contracts. We may consider a number of governments [BST06] in the sense of [Cho82]. However we 

should take into account the choices for style and perspectives. 

Refinement pattern 

Perspectives 

and styles 

✲ 

❄ 

Derivation of 

generic 

refinement 

steps 

✛ 

Development 

contract 

❄ 

Generic refinement step 

Consistency 

conditions 

✲ 

❄ 

Derivation of 

specific 

refinement 

steps 

✛ 

specification 

assumptions 

❄ 

Refinement step 

Abbildung 8: The Derivation of Correct Refinement Steps 

Given a refinement pattern, perspectives, styles and contract, we may derive generic refinement steps such as data 

refinement, purely incremental refinement, submachine refinement, and (m,n) refinement. The generic refinement is 

adapted to the assumptions made for the given application and to consistency conditions. Typically such consistency 

are binding conditions of rules to state and vocabulary through the scope of rules. The general approach we envision


is depicted in Figure 8. 

1.5.2 Das Modellierungsloch 

Urteile. 

extending the Pfänder approach to 

(concept, kind, valuation (value, modality, existence, world)) or 

(concept (name, world (name, existence)), kind (name, kind expression), valuation (value, modality)) 

R. Kaschek’s Beobachtung: 

Unsere Vorstellung vom Modellierungsurteil haben wir in Bild 9 in vereinfachter Form zusammengefaßt. 

“Realität” 

Ausschnitt 

der Realität 

✻ 

Dinge der 

Realität 

✛ 

Beobachtete 

Eigenschaft 

✲ 

“Begriff” 

Prädikator 

✻ 

✻ 

Urteilsart 

Modellierungsurteil 

✻ ✻ 

Kontext 

✻ 

Theorie 

Revision 

☛ im Entwicklungsprozeß 

❯ 

agiert 

im 

✛ 

unter 

Benutzung 

❄ 

Modalität 

“Schema” 

als Resultat und Ausschnitt 

eines Entwicklungsprozesses 

❄ 

Individuum 

❄ 

Referenzmodellierung 

Gewißheit 

Schärfe 

Abbildung 9: Modellierungsurteile durch Individuen im Modellierungskontext und das Dilemma der Modellierung 

Mit der Darstellung in Bild 9 wird gleichzeitig auch das Dilemma der Modellierung sichtbar. Sind nach der Modellierung 

nur noch die Modellierungsurteile verfügbar, dann sind nicht mehr die impliziten Annahmen, die theoretischen 

Grundlagen, die Beobachtung der Realität und oft auch die Spezifika des Entwicklers nachvollziehbar. Damit 

entstehen Schemata, die der Nachwelt nicht mehr verständlich erscheinen, die zu einer Doppelentwicklung innerhalb 

von großen Anwendungen, wie z.B. bei SAP R/3, führen und neben Redundanz- auch erhebliche Konsistenzprobleme 

besitzen. 

The Knowledge Gap on Development Decisions 

Recording Decisions Partially Leads to Incompleteness


1.5.3 Was ist ein Modellierungskonzept 

Vorteile konzeptbasierter Modellierung. 

Einfacheres Auffinden von Anfragen durch konzeptbasierte Anfrageformulierung und begriffsbasierte Schnittstellen 

siehe unten Bild 14 

Wiederverwendung von Schemata 

... 

Die konzeptuelle Beschreibung umfaßt auch der Beschreibung der Funktionsweise eines implementierten Informationssystemes, 

d.h. auch die Beschreibung der Content-Typen und des Story-Raumes. Gewöhnlich wird dieser Teil 

dem Präsentationssystem zugeordnet und erst später entwickelt. Damit werden Performanzengpässe von Anfang an 

mit ausgelöst. 

Wir führen hier erstmals eine allgemeine Theorie der Content-Objekte 6 und Content-Typen ein. Content ist ein 

derzeit häufig überladener Begriff. Man verlangt heute von einem Content-Management-System (CMS), daß folgende 

Teilsysteme und Lösungen eingeschlossen werden. 

• Portal-Verwaltung, Enterprise Content Management; 

• Content-Anlieferung, Agentur-Lösungen, Content-Provider, Customer Relationship Management, E-Commerce- 

Lösungen, E-Marketing, Online Payment; 

• Dokument-Verwaltung, -Archivierung, und -Suche, Unterstützung von Dokumenten-Arbeitsabläufen; 

• Intelligente, benutzerspezifische Erzeugung von Inhalten; 

• ASP-Lösungen, Media Asset Management; 

• Group-Ware-Lösungen, Intranet-Lösungen; 

• Redaktionssystem, Ausspielsystem, Erneuerungssystem; 

• Skalierbare Lösung, Agententechnologien, Performance Monitoring, Sicherheitstechnologien, Hochverfügbarkeit; 

• Open-Source-Lösungen, Community-Lösungen. 

Diese Liste ist zu umfangreich. Außerdem wird damit der Begriff Content vollständig überladen. Stattdessen bevorzugen 

wir eine Separation von Gesichtspunkten, Begriffsbildungen und Aspekten so, wie sich dies in der Semiotik, 

der Linguistik und der Mathematischen Logik eingebürgert hat. Wir unterscheiden deshalb zwischen 

Content als Extension eines Referenzobjektes (Intension), als eine Menge oder i.a. Kollektion von Daten, Nachrichten 

oder Informationen, 

Konzept als Plan, als Zusammenfassung eines Vorhabens oder Begriffes in konsistenter, überschaubarer und nachvollziehbarer 

Form, mit dem die Gesamtheit der Merkmale zusammengefaßt wird und 

6 Obwohl auch diese Arbeit eine weitgehende Verwendung deutschsprachiger Begriffe bevorzugt, müssen wir beim Begriff “Content” 

bleiben. Die richtige deutsche Übersetzung führt zum Begriff “Inhalt”. Da dieser Begriff in der Umgangssprache und der Informatik zu breit 

verwandt wird, bleiben wir beim Begriff “Content”.


Begriff als Intension oder als Versuch des Zeichenbenutzers, Erscheinungen zu erfassen, in einer kognitiven Einheit 

zusammenzufassen und in einen Zusammenhang zu bringen, der eine Abstraktion enthält, die das Wesentliche 

für den Interpreten, Benutzer oder auch Benutzergruppen (im weiteren repräsentiert durch Akteure) enthält und 

vom Unwesentlichen im derzeitigen Kontext abstrahiert. 

Diese Separation von Gesichtspunkten entspricht dem Herangehen der Semiotik, in der zwischen verwendeter Syntax, 

der unterlegten Semantik und der Art der Verwendung (Pragmatik) unterschieden wird. In der Semiotik wird unterschieden 

zwischen Zustands-, Vorgangs-, Tätigkeits- und Handlungsdarstellungen. Syntaktische Formen werden oft 

in der klassischen SPO-Notation gegeben: Das Subjekt ist Geschehnisträger, Täter, Handelnder, Akteur; das Prädikat 

ist der Aussagekern; Objekte sind Sinnergänzungen. Außerdem werden freie adverbiale Bestimmungen zur Charakterisierung 

des Kontextes verwendet. Die Semiotik unterscheidet vier Aspekte: Syntaktischer Aspekt zur Darstellung 

der Beziehung der Zeichen zueinander; sigmatischer Aspekt zur Widerspiegelung der objektiv-realen Wirklichkeit; 

semantischer Aspekt zur Interpretation der Welt durch die Sprache; pragmatischer Aspekt zur Konventionalisieurng 

der sigmatischen, semantischen und syntaktischen Relationen. Der sigmatische Aspekt spielt in der Modellierung 

keine Rolle mehr, nachdem die Urteile zur Modellierung gefällt wurden. 

Ebenso wie in der Modellierung spielen pragmatische Annahmen eine Rolle. So werden z.B. die aktuelle Kommunikationssituation 

mit der vierstelligen Beziehung zwischen Sender, insbesondere seinem Verständnis, dem Inhalt, 

der Beziehung zwischen Sender und Empfänger einer Nachricht und dem Empfänger, insbesondere seinem Verständnis 

mit betrachtet. Ein Analogon der Kommunikationssituation ist die Anwendungssituation. 

Daraus können wir eine semiotische Triade zu einem Informationssystem ableiten: Der Content bestimmt den 

syntaktischen Aspekt. Der semantische Aspekt wird durch die Konzeptwelt dargestellt. Der pragmatische Aspekt 

wird ggf. durch eine Anwendungssituation determiniert und durch eine Begriffslandkarte repräsentiert. In Bild 10 

Semantik 

Repräsentationswelten, 

Datenwelten 

Content 

Syntax 

Allgemeines Verständnis 

Pragmatik 

Semantik 

Erweiterte Sichten 

Content 

Syntax 

Erzeugbarkeit / Darstellbarkeit / Verwaltbarkeit 

Pragmatik 

Konzepte 

Theorienwelten, 

Modellierungswelten 

Begriffe 

Benutzerwelten 

je nach Gruppen 

-common-sense 

Konzepte 

Konzeptionelle 

Theorien 

Begriffe 

Begriffslandkarte 

Abbildung 10: Semiotik-Darstellung von Content, Konzepten und Begriffen 

stellen wir die Verbindung zwischen den einzelnen Aspekten kurz dar. 

Damit sind auch die theoretischen Grundlagen von CMS gegeben wie in der folgenden Tabelle: 

Content Konzepte Begriffe 

Theorie erweiterte Sichten und “kleine” logische Theorieverbände 

erweiterte Begriffs- 


Spezifikationsresultat erweitertes ER-Schema Konzeptfelder Begriffslandkarte 

Die Assoziation zwischen Content, Konzepten und Begriffen kann erfolgen durch spezielle Abbildungen. Im 

Rahmen unserer Entwicklung hat es sich als ausreichend erwiesen, dabei wenige ausdrucksstarke Verbindungen der 

unterschiedlichen Aspekte der Assoziation zu verwenden.


von / zu Content Konzepte Begriffe 

Content Integration Aufbereitung Annotation, allgemeine 

Assoziation 

Konzepte Spezialisierung Komposition Verbalisierung, allgemeine 

Assoziation 

Begriffe allgemeine Assoziation Untermauerung Komposition 

Content kann z.B. durch eine Datenbankspezifikation wie der folgenden gegeben sein. 

create table Benutzer (BenutzerID smallint not null, 

FirmaID numeric (18,0) not null 

Vorname varchar (20) null, 

Name varchar (20) null, 

Tel varchar (20) null, 

Zugriff tinyint null, ...) 

go 

create table BProfile (BPID numeric (18,0) identity (1,1) not null, 

BPName char (100) null, 

BenutzerID smallint null, 

Rechte char (18) null, ... ) 

go 

create view SysusersBenutzer 

as select S1.Name as Login, S2.Name as Gruppe, BP.Name as Profil, BP.Rechte, 

B. Name, B.Vorname, B.Tel, B.Funk, B.FirmaID, S1.GID, S1.UID, ... 

from Sysusers S1 inner join Sysusers S2 on S1.UID S2.GID and 

S1.GID = S2.UID left outer join 

Benutzer B on S1.UID = B.BenutzerID left outer join 

BProfile BP on B.BenutzerID = BP.BenutzerID 

where (S1.UID between (select typ_integer from tc_parameter 

where Name = ’UserAnzeigenAb’) and 16380) 

go 

Im allgemeinen wird dies nicht ausreichen. Wir verwenden deshalb erweiterte Sichten, die in den nächsten Kapiteln 

ausführlich behandelt werden. Sichten müssen um Funktionen erweitert werden, mit denen die Sichten verändert, 

anders präsentiert und für das Portfolio des Benutzers aufbereitet werden können. Dazu benutzen wir den Definitionsrahmen: 

generate MAPPING : VARS → [temp] OUTPUT STRUCTURE 

from DATABASE TYPES where SELECTION CONDITION 

represent using GENERAL PRESENTATION STYLE 

& ABSTRACTION (GRANULARITY, MEASURE, PRECISION) 

& ORDERS WITHIN THE PRESENTATION 

& HIERARCHICAL REPRESENTATIONS 

& POINTS OF VIEW 

& SEPARATION 

browsing definition CONDITION 

& NAVIGATION 

functions SEARCH FUNCTIONS 

& EXPORT FUNCTIONS 

& INPUT FUNCTIONS 

& SESSION FUNCTIONS 

& MARKING FUNCTIONS 

maintenance functions MAINTENANCE FRAME 

& CONTROL (OBLIGATIONS, PERMISSIONS, RESTRICTIONS) 

Konzepte können durch Konzeptnetze dargestellt werden. Konzeptnetze widerspiegeln die drei semiotischen 

Aspekte Syntax, Semantik und Pragmatik, wobei die Syntax und die Pragmatik durch Kontexte verbunden werden. 

Konzepte besitzen allgemeine Parameter, die mit einer Wertebereich-Spezialisierungsbeziehung mit Content unterlegt 

werden können. Diese Parameter können optional oder auch allgemein oder obligatorisch sein. Wir können die


Spezifikation von Konzepten mit einem Definitionsrahmen unterstützen oder durch ein Konzeptnetz der Form von 

Bild 11. 

Assoziierte 

Konzepte 

Umfeld 

Wort 

Bedingungen 

Wortformen 

Regeln 

Constraints 

Optionalität 

Null 

Kontext 

[ ] 

Syntax 

* 

Parameter 

Default 

Valenz 

Historie 

Pragmatik 

Konzept 

Bindungsform 

Semantische 

Fälle 

Semantik 

Kernsemantik 

Anwendungsportfolio 

Erweiterungssemantik 

Modellwelt 

Abbildung 11: Die Mindmap-Strukturierung der Spezifikation von Konzepten 

Im allgemeinen wird diese Darstellung durch Konzeptnetze allerdings nicht ausreichend übersichtlich sein. Deshalb 

kann man nach einer anderen Darstellung suchen. Wir benutzen neben dieser Darstellung auch eine graphische 

Darstellung durch erweiterte ER-Modelle, bei denen optional Parameter durch eckige Klammern, Identifikationsparameter 

durch eine Unterstreichung und allgemeine Parameter nicht extra ausgewiesen werden. 

Im Falle des Person-Konzeptes können wir drei wichtige Parameter auszeichnen: die Charakterisierung von Personen 

mit ihren Eigenschaften, die Angabe des Beziehungsumfeldes der Personen und eine Darstellung des Kontextes. 

Diese Aspekte sind durch entsprechende Logiken unterlegt. Da wir Personen in einer gewissen Allgemeinheit 

behandeln wollen, wird die Semantik und damit die Theorie mit einer epistemischen, temporalen Logik spezifiziert. 

Wir betrachten Personen nur im betrieblichen Umfeld und nur aufgrund der Aufgaben, die durch das Informationssystem 

unterstützt werden. Damit kann man das Person-Konzept holzschnittartig durch eine allgemeine Spezifikation 

unterlegen der folgenden Form: 

Person(( charakteristik, beziehung, kontext), (Σ DeontTempPL/1 

Person 

, M Person , Σ EpistemLogik 

Person 

), 

( betriebsIS, aufgabenAkteur)). 

Wir können die Parameter spezialisieren. Eine mögliche Spezialisierung ist die folgende: 

τ( beziehung) = angestellter ∪ · 

partner 

τ( charakteristik) = namen ∪ · 

gebDaten ∪ · 

identDaten ∪ · 

geschlecht 

· 

∪ familie ∪ · 

weitereCharakt ∪ · 

profil 

Die Formeln zur Darstellung der Semantik können unterschiedliche Bereiche der Anwendung abdecken. So können 

wir z.B. festlegen, daß Personen ihr Geburtsdatum nicht verändern. Eine Person, die geschieden ist, war einmal verheiratet. 

Wir erhalten damit Formeln der folgenden Form, wobei wir uns der deontischen Quantoren F (forbidden), O


(obliged) und P (permitted) bedienen: 

F(update(Person. gebDaten)) 

α “geschieden ′′( person) → ∃ past y 

(Beziehung(Ist.Partner. y,Von.Partner. person,Ab,Bis) 

∧ Bis < today 

In analoger Form können wir Adressen spezifizieren: 

Adresse(( geographAdr, kontaktAdr, historie), (Σ PL/1 

Adresse , M Adresse, Σ Qualität 

Adresse ), 

( betriebsIS, aufgabenAkteur)). 

Die Darstellung der Konzepte kann auch in der Form von ER-Modellen erfolgen. Ein typisches Beispiel wird in 

Bild 12 vorgestellt. 

externe 

interne 

Fähigkeitenprofil 

+ 

✻ 

❄ 

Bildungsprofil 

✻ 

AnzJahreBerufserfahrung 

Profil 

CV 

LetzterEintrag 

✲ 

[Paß] 

Charakterisierung Intervall 

Angestellter ✲ 

❄ 

Person 

Name 

Familienname 

Vornamen Titel Anrede 

Geburtsdaten Biometriedaten 

Geschlecht Familiengeschichte 

Charakterisierung 

Beschreibung 

Eigenschaft 

❄ 

Rufname 

Art 

✙ 

■ 

✛ 

✛ 

+ 

Ist 

Beschreibung 

Organisation 

Rollentyp 

✻ 

✻ 

Partner 

✻ 

Ab 

Von 

Beziehung 

[Kommentar] 

Bis 

[Kommentar] 

Datum 

Abschluß 

durch 

Gegenstand 

Spezialisierung 

✲ 

Bildungseinrichtung 

Name 

Ort 

Beschreibung 

[Priorität] 

Status 

Abbildung 12: Das Person-Konzept mit obligatorischen, allgemeinen und optionalen Bestandteilen 

Konzepte sollen durch Content unterlegt werden können, wobei der Content und seine Struktur variabel sein 

können, solange sie miteinander verbunden werden können. Wir schränken diese Verbindung durch die Forderung 

einer Spezialisierungsbeziehung ein: 

Die Spezifikation des Content stellt eine Verfeinerung der Spezifikation der zugehörigen Konzepte dar. 

Konzepte können miteinander kombiniert werden. So kann z.B. wie in Bild 13 das Konzept Person mit dem Konzept 

Rolle und dem Konzept Adresse verbunden werden, wobei z.B. nur der Angestellte eine interne Kontaktadresse 

und eine externe Partneradresse besitzt. Diese Verbindung wird allgemein durch Filter oder “Theta”-Operatoren sichergestellt. 

Wir können dies durch die Algebra unterstützen und erhalten: 

Adressen ✶ Θ(α) Personen ✶ Θ(β) Rollen 

Eine Algebra zur Verbindung wird aus der HERM-Algebra abgeleitet. Wir verwenden dabei die HERM-Operationen: 

∪ , ∩ , \ , π , ✶, µ , ν , ρ NameSpace , Aggr , src h0 ,h 1 ,h 2 

. 

Eine Spezialisierungsbeziehung zwischen dem Person-Konzept und dem Content erfolgt dann durch Instantiierung 

der Parameter, Dadurch “paßt” die Sicht zu Person-Content auch zum Person-Konzept. Ein Beispiel ist die 

Spezialisierung des Parameters familie oder des Parameters name: 

T (Geburtname, Vater, Mutter) oder 

familie ⇋ 

T (Geburtname, { Kind } ) 

✠


Rollenkonzepte 

✻ 

Interne Rolle 

• 

• 

Lieferant 

Kunde 

Angestellter 

Beauftragter 

Privatperson 

Externe Rolle 

• 

• 

• 

Kontaktadresse 

• 

• 

• Partneradresse 

✲ 

Adreßkonzepte 

✠ 

Personenkonzepte 

Abbildung 13: Die Kombination von Konzepten Person, Rolle und Adresse 

name 

⇋ 

T (Vornamen, FamName, [GebName,] 

Titel:{AkadTitel} ∪ · 

FamTitel) 

oder 

T (Vorname, Familienname, Spitzname) 

Begriffe sind i.a. nicht so stark durch Merkmale oder Eigenschaften unterlegt, besitzen häufig eine hohe Ambiguität 

und sind oft in einer ellipsenartigen Form gegeben. Außerdem werden sie oft metaphorisch verwendet. Begriffe 

können als Funktionen verstanden werden, die Dinge (im weitesten Sinne) mehr oder weniger abbilden. So wird 

meist ein Begriff mit einer Menge von Beispielen verbunden, die explizit oder auch abstrakt definiert sein können. 

Begriffe sind sprachabhängig, meist jedoch nicht reduzierbar auf die Gebrauchsregeln, von denen sie erzeugt werden. 

Das begriffliche Klassifikationssystem, das eine Sprache unterlegt, ist in hohem Maße Ergebnis eines adaptiven und 

anwendungskontextgeprägten Sprachwandels. 

Begriffe können determiniert werden in der Art und Weise, wie ihre Extension determiniert wird. Sie können 

scharf begrenzt sein im Sinne “Fregescher Begriffe”. Wir bevorzugen diese Form. In der Alltagspraxis werden Begriffe 

nicht so scharf eingegrenzt. Es ist jedoch Aufgabe der Modellierung, Begriffe so exakt wie möglich Extensionen 

(Content) und Konzepten zuzuordnen. Begriffe können auch prototypische Begriffe sein oder Familienähnlichkeitsbegriffe. 

Ein Beispiel ist das Adreß-Konzept. Wir können mit diesem Konzept unterschiedliche Begriffe verbinden: 

• Hauptwohnsitz, Nebenwohnsitz, 

• Zustelladresse, 

• Anschrift oder Email.


Nicht verbindbar sind dagegen der Begriff Glückwunschschreiben, der Begriff Speicheradresse oder auch der Begriff 

Eingabe (schriftliche Kundgebung). 

Analog stellen wir für das Person-Konzept fest, daß Begriffe wie Mensch assoziierbar sind, nicht aber Figur (Akteur) 

oder abstrakte Person (“ich für meine Person”). 

Wir werden im weiteren uns nicht mehr mit Konzepten oder Begriffen auseinandersetzen, da dies den Rahmen 

dieser Arbeit sprengen würde. Für die Spezifikation von Informationssystemen spielen Begriffe und Konzepte eine 

untergeordnete Rolle. Wenn wir allerdings eine allgemeinere Architektur, wie z.B. in Bild 14 anstreben, dann 

kann eine essentielle Verbesserung der Kultur erfolgen. Normalerweise befindet sich ein Benutzer eines Informationssystemes 

in der SQL-Falle. Er muß sowohl das Schema kennen und verstehen als auch mit SQL seine Anfragen 

formulieren können. Einfacher und zugleich sinnvoller ist es, dem Benutzer durch eine Assoziation seiner Begriffe 

mit Konzepten und durch eine Verbindung dieser Konzepte mit Anfrage- und Antwortformen zu unterstützen. Die 

Anfrageformen können mit dem Datenbankschema ebenso assoziiert werden wie die Antwortformen. Damit erhält 

ein Benutzer für seine Frage die richtige Antwort aus dem System heraus. 

✲ 

?? 

Tina Musterfrau, 

zufälliger 

Nutzer 

Benutzer 

in der 

DBMS-Falle 

✻ 

✻ 

❄ 

Anfrageschnittstelle 

Suchanforderung 

Begriffslandkarte 

✿ 

Konzepte 

❄ 

Suchkonzept 

parametrische 

HERM- 

Ausdrücke 

❄ 

✲ Anfrageform 

✲ 

relationales 

Datenbankschema 

❄ 

SQL 

query 

✛ 

❄ 

❄ 

Ergebniskonzept 

✲ Antwortform 

❄ 

SQL Anfragemenge 

✛ 

Datenbank 

❄ 

✮ 

 

Antwort 

auf Suche 

DBS 

DBMS Antwortrepräsentation 

Abbildung 14: Konzept- und begriffsbasierte Anfrageschnittstellen von Informationssystemen 

Mit dieser Lösung kann ein Content-Management-System dem Benutzer maximal entgegenkommen. 

Terminological object 

1. high-level general concepts steeming from Mathematical logic 

2. language for expressing conceptions


3. modeling based on terminological objects theory defined by axioms named as concept-oföntological object 

(better terminological): name of a theory + axioms of a theory models of a theory defined as ontological object 

result: collection of associated terminological conceptions 

4. communication schema (encoding) for a database 

Bestandteile:. 

Combination 

Core integration 

Construction 

Inductive definition 

1.5.4 Qualitätsmanagement 

Vollständigkeit, Konsistent, Korrektheit Minimalität, Verständlichkeit, Transparenz 

Vollständigkeit: alle relevanten Sachverhalte der Miniwelt (Universe of Discourse, UoD) sind im Schema repräsentiert 

Abgleich mit den Anforderungsdokumenten 

Maßeinheit: Prozentsatz repräsentierter Anwendungssachverhalte 

Konsistenz: die möglichen Instantiierungen des Schemas beschreiben im UoD 

zulässige (mögliche) Zustände (vgl. Datenbank-Konsistenz) 

Konsistenzverletzungen entstehen typischerweise durch 

• Schema-Elemente, die kein Urbild im UoD haben 

z.B. - Assoziation zwischen zwei Klassen, die in der Realität nicht besteht 

• unnötige Charakteristiken/Werte 

• falsch gewählte Werttypen 

• falsche Kardinalität von Assoziationen, Attributen etc. 

• unzweckmäßige Abstraktionen (falsche Vererbung) 

• Nichtberücksichtigung von Änderungen im UoD 

Korrektheit: richtige Anwendung der Konzepte des zugrundeliegenden Modells 

(Begriffssystems) hinsichtlich 

• der vorgegebenen syntaktischen Regeln: syntaktische Korrektheit (wird von Tools meistens verhindert) 

• ihrer a priori Semantik (vereinbarte Bedeutung): semantische Korrektheit 

Typische Verletzungen der semantischen Korrektheit: 

• Klasse statt Charakteristik bzw. umgekehrt, z.B.: Klasse mit nur einer Charakteristik 

• Aggregation statt Generalisation bzw. umgekehrt 

• Assoziation statt Aggregation oder Generalisation 

• Klasse statt Assoziation 

• fehlende identifizierende Charakteristik(en) bei Klassen 

• Verwendung inadäquater Modellierungskonzepte, so daß zusätzliche Beschriftungen (Konsistenzbedingungen) 

erforderlich werden


Minimalität (Redundanzfreiheit): jeder relevante UoD-Sachverhalt ist höchstens einmal im Schema repräsentiert, 

d.h. es kann kein Schemaelement ohne Informationsverlust entfernt werden 

beabsichtigte Redundanzen sind zu dokumentieren 

Beispiele: 

• redundante Charakteristik: Handelspartner(Name, Rabattklasse, Anzahl Produkte), Produkt(Produktnr., 

Wert), vertreibt ((0,n) (1,1)) 

• redundante Assoziation: Unternehmen, Niederlassung, hat Niederlassung , ist Filiale von 

Ausdruckskraft/Verständlichkeit: die relevanten UoD-Sachverhalte werden auf intuitiv verständliche Weise dargestellt 

• Klarheit 

• Detailiertheit 

• Ordnung 

• Präsentation 

• Dokumentation in unterschiedlichen Formatierungen 

Beispiel (nach Batini, Ceri, Navathe): Assistant, Seminar, Professor, offers(Professor, Seminar), Course, supports(Assistant, 

Course), teaches(Assistant, Course), Instructor, offers(Instructor, Seminar), teaches(Instructor, 

Course), Technician, supports(Technician,Course) 

stattdessen: TeachingStaff, SupportingStaff, CourseOffering 

Transparenz, Lesbarkeit: 

• übersichtliche Darstellung (graphisch, tabellarisch) 

• Zusammengehöriges ’ 

nahe beieinander’ 

• firmenweit einheitlicher Strukturaufbau (z.B. SERM: von links oben (Kernklassen) nach rechts unten 

(Dateilklassen bzw. Abstraktionen von unten nach oben, d.h. Detaillierungen (Spezialisierung, Zerlegung) 

von oben nach unten) 

• wenige ’ 

Kreuzungen’ (-¿ möglichst planarer Graph) 

• Erkennbarkeit der Kernklassen (Schwerpunkte im Graphen) bzw. Kerngruppen (graphentheoretisch: Cliquen) 

• Erkennbarkeit von Symmetrien 

Zeitunabhängigkeit 

• rechtzeitig: immer dann wenn benötigt 

• aktuell: immer auf neuestem Stand 

• Frequenz: so oft wie benötigt 

• Zeitperiode: über alle benötigten Zeiten verfügbar 

Qualitätverbessernde Transformationen. 

informationserhaltende Transformationen 

• Beseitigung von Redundanzen ( Minimalität)


• Beseitigung von Zyklen 

• Beseitigung unnötiger Charakteristiken 

• Zusammenfassung (ggf. unter Generalisierung) von Klassen, die dasselbe bzw. Varianten desselben 

UoD-Sachverhalts beschreiben 

• Beseitigung unnötiger Klassen und ggf. damit verbundener Generalisationen ( Ausdruckskraft) 

z.B. wenn die Unterklassen ausser den ererbten keine weiteren Charakteristiken haben, der Oberklasse 

also nur die Generalisierungscharakteristik zuzuschlagen ist ’ 

‘hängende Subklassen’ 

• Beseitigung ‘hängender Klassen’ (total und n:1 assozierte Klassen mit wenigen Charakteristiken) durch 

Übernahme ihrer Charakteristiken in die ‘Masterklasse’ ( Ausdruckskraft) 

• Erhöhung von Transparenz und Lesbarkeit (Änderung der Anordnung) 

informationsverändernde Transformationen 

• erweiternd 

Top-down, Bottom-up, Inside-out Transformationen Vollständigkeit, Konsistenz 

z.B. Einführung einer Spezialisierung, um genauere Kardinalitäten zu ermöglichen (Teilmengenbildung) 

Fahrer/in (Führerscheinklasse,Mitarbeiter/in,MNr.,MName), Firmenfahrzeug(Amtl. Kennzeichen,Typ,Jahr 

der Erstzulassung) fährt (Mitarbeiter/in(0,1) Firmenfahrzeug(1,n) ) 

Stattdessen: Mitarbeiter/in mit Subtypen Fahrer/in 

qualitätverbessernde Transformationen 

• verringernd: Beseitigung von Schemaelementen, die keinen Bezug zu UoD-Sachverhalten haben Konsistenz 

• anpassend 

1.5.5 Qualitätsdaten 

• Korrekturmaßnahmen 

• Anpassung an veränderte UoD-Gegebenheiten 

• bei Konflikten (Namen, Typen) während der Integration von Teilschemata (verschiedene Teilbereiche 

eines UoD) 

Unvereinbarkeit von Datenmassiven 

• mißverstandene Geschäftsanforderungen 

• unvereinbare Daten z.B. nicht vorhandenes Wissen zu vorhandenen Datenbeständen, nicht verstandene Semantik 

vorhandener Daten, hohe Redundanz, hohe Variabilität (Formate, Inhalte, Bedeutung, Darstellung, DB) 

• unvereinbarer Datenfluß (Zyklus: Erzeugung, keine Integration oder Dokumentation, kein Auffinden, Unkenntnis 

über Daten) 

• unvereinbare Migration und Injektion (z.B. in XML-Welten 

• Daten-Ressourcen-Drift hin zu immer schlechterer Qualität 

• Auswirkungen auf die Informationsqualität z.B. in OLAP- und DW-Anwendungen 

Anforderungen an das Qualtätsmanagement 

• Analyse der Fehlerquellen in Datenmassiven


• Verstehen von Daten als Ressource, als Eigentum und Wert 

• integrierte und subjektorientierte Aufbereitung 

• gemeinsame Architektur zur Datenhaltung 

• anforderungsadäquate, storybasierte Aufbereitung von Daten 

• Terminologiemanagement 

• Qualitätspflege innerhalb der Daten 

• Wertekette von Qualitätsdaten hin zu Wissensdaten, business intelligence, business strategies, business goals 

• Risiko- und Unfallmanagement


1.6 Aspekte von Informationssystemanwendungen 

1.6.1 Die unterschiedlichen Betrachtungsweisen 

1.6.2 Semiotik der Modellierung von Informationssystemen 

Die Entwicklung eines Informationssystemes muß deshalb alle Aspekte einer Anwendung umfassen: 

Strukturierung: Die Struktur eines Informationssystemes und die statischen Integritätsbedingungen werden im 

Datenbank-Schema zusammengefaßt, das die Strukturierung einer Datenbank beschreibt. 

Funktionalität: Informationssysteme stellen eine Vielzahl von Funktionen, eine Anfrageschnittstelle, eine Modifikationsschnittstelle, 

eine Transaktionsverarbeitungskomponente, Programme etc. zur Verfügung. Für eine 

Anwendung werden Prozesse auf der Grundlage dieser Funktionen entwickelt. Für die Prozesse gelten dynamische 

Integritätsbedingungen. Wir fassen die Prozesse und die dynamischen Integritätsbedingungen in der 

Datenbank-Maschine zusammen, die die Funktionalität der Anwendung beschreibt. 

Verteilung: Informationssysteme werden heutzutage in andere Systeme eingepaßt, sind selbst oft nur Bestandteile 

einer Infrastruktur und kooperieren miteinander. Wir entwickeln hier eine allgemeine Spezifikation der Verteilung 

basierend auf dem Konzept der Dienste, der Austauschrahmen und der Kooperationsbedingungen. Diese 

Spezifikation verallgemeinert Zugänge aus dem Bereich der Kommunikationssysteme, der verteilten Systeme 

und der Betriebssysteme. 

Interaktivität: Ein Informationssystem soll den Benutzer bei einer Vielzahl von Aufgaben unterstützen. Es werden 

je nach Anwendungskontext unterschiedliche Handlungsabläufe ausgelöst. Wir fassen diese Abläufe im 

Story-Raum zusammen. Gruppen von Benutzern werden abstrakt durch Akteure dargestellt. Die einzelnen Arbeitsschritte 

fassen wir in Szenen zusammen. Die benötigte Unterstützung durch das Datenbanksystem erfolgt 

durch Content-Objekte, die eine Verallgemeinerung von Sichten darstellen und um eine Funktionalität erweitert 

wurden. Der Story-Raum und die Content-Objekte werden im Interaktionsraum zusammengefaßt. 

Diese vier Aspekte müssen gemeinsam bei der Entwicklung eines Informationssystemes betrachtet werden. Wir sprechen 

deshalb vom integrierten Entwurf von Strukturierung, Funktionalität, Verteilung und Interaktivität eines 

Informationssystemes bzw. vom integrierten Entwurf von Strukturierung und Funktionalität eines Datenbanksystemes. 

Der Entwurfsprozeß ist ein Prozeß des Abstrahierens und des Konstruierens. Wir können deshalb die unterschiedlichen 

Abstraktionsarten und Konstruktionsarten miteinander vergleichen. 

Mit dem Zachman-Zugang [IZG97] können wir beim Konstruieren unterschiedliche Aspekte von Informationssystemen 

unterscheiden: 

Strukturierung (was): Die Strukturierung der Anwendung wird durch Datenbankmodelle angegeben. Datenbanklehrbücher 

konzentrieren sich meist auf diesen Aspekt. 

Funktionalität (wie): Funktionen und Prozesse, die für die Manipulation und das Retrieval benötigt werden, werden 

meist erst mit der Entwicklung der Funktionalität der Anwendung auf dem Niveau der Implementierung 

betrachtet. Da aber die Optimierung des Verhaltens der Anwendung eine dedizierte Unterstützung durch die 

Strukturierung erfahren muß, sollte die Spezifikation der Funktionalität und der Strukturierung abgestimmt 

erfolgen. 

Lokalisierung (wo): Anwendungen sind meist verteilt auf Struktureinheiten, auf unterschiedliche Orte und auf die 

Infrastruktur. Die Verteilung des Datenbanksystemes war von untergeordnetem Interesse, solange eine verteilte 

Verarbeitung keine Effizienzvorteile brachte. Mit der Entwicklung der Vernetzung und der effektiven 

Unterstützung hat sich dies grundlegend geändert. 

IS ADD


Akteure (wer): Mit der Entwicklung der künstlichen Intelligenz wurde auch das Mensch-Maschine-Interface komfortabler. 

Spezielle Schnittstellen für unterschiedliche Benutzer, je auch Fähigkeiten, Fertigkeiten, Wissen, 

Arbeitsaufgaben, Arbeitsumfeld, Rollen und Rechte, können mittlerweile durch DBMS unterstützt werden. 

Demzufolge sind die Akteure als Gruppen von Benutzern mit zu modellieren. 

Zeitpunkte (wann): Daten altern auf unterschiedliche Art und Weise je nach der Benutzung, der Sichtweise der 

Benutzer, der Erneuerungsstrategie und der zur Verfügung stehenden Infrastruktur und Systeme. Der Alterungsund 

Erneuerungsprozeß kann durch Modellierung der Zeitaspekte beherrscht werden. 

Motivation (warum): Die Akzeptanz der Systeme wird stark durch die Motivation der Akteure mit bestimmt. Wir 

verallgemeinern die Motivationsschicht zur allgemeinen Benutzbarkeitsschicht. 

Metaaspekte werden im Zachman-Modell bis auf die Motivation nicht betrachtet. Beispiele solcher Kategorien sind 

Qualitätskategorien wie Allgegenwart, Sicherheit, Konsistenz, Bedeutungstreue, Robustheit, Skalierbarkeit 

und Dauerhaftigkeit. 

Benutzungsaspekte werden im Zachman-Modell vernachlässigt. Es gehören hierzu insbesondere das Aufgabenportfolio 

und das Organisationsmodell. 

Unser Modell der Entwicklung von Informationssystemen im Co-Design-Zugang folgt den ersten drei Aspekten 

(Strukturierung, Funktionalität und Verteilung) und betrachtet anstelle der letzten drei Aspekte das Storyboard, 

d.h. die Interaktivität. 

Wir fügen dem Zachman-Modell noch weitere Dimensionen hinzu: 

Kompetenz (wofür): Es werden die Aufgaben, die durch das Informationssystem unterstützt werden sollen explizit 

dargestellt. 

Kontext (in welcher Umgebung): Meist werden Kontextentscheidungen implizit in die Modellierung eingebracht. 

Dazu gehören nicht nur die technische und organisatorische Umgebung sondern auch die Strategie des Betreibers 

des Systemes. 

Qualitätsgarantien (in welcher Qualität): Es wird explizit dargestellt, inwieweit bestimmte Qualitätskriterien durch 

das System unterstützt werden und welche Qualitätskriterien nicht oder nur bedingt erfüllt werden. 

Laufzeitcharakteristiken (wie derzeit): Da die Arbeitsumgebung auch durch Ausnahmesituationen, durch aktuelle 

Parameter, durch zeitweilige Verschiebung der notwendigen Schritte zum Abschluß und durch benutzungsspezifische 

Aspekte geprägt ist, sollte die Anpassung des Systemes an die Arbeitssituation auch explizit modelliert 

werden. 

Kollaboration (mit wem): Arbeitsaufgaben werden oft in Gruppen bewältigt. Die Kollaboration von Gruppen muß 

deshalb explizit dargestellt werden. Wir unterschieden zwischen Kommunikation, Kooperation und Koordination 

und stellen dazu Kollaborationsrahmen dar. Damit wird das Akteursmodell weiter ausspezifiziert. 

Diese Dimensionen untersetzen z.T. die Zachman-Dimensionen. Da im Verlaufe des Modellierungsprozesses alle 

Aspekte der Anwendung explizit dargestellt werden sollten, umfaßt unsere Methodik auch diese Betrachtungswinkel. 

Die Semiotik und die Linguistik unterscheiden für Sprachen drei unterschiedliche Betrachtungsweisen, die auch 

für unsere Spezifikationssprachen gelten: 

Die Syntaktik (bzw. Syntax) untersucht die Beziehungen der Zeichen (Worte) selbst, stellt Regelsysteme zur Erzeugung 

korrekter Ausdrücke der Sprache bereit und führt oft zu einem Beweissystem, mit dem bestimmte 

Eigenschaften für Kollektionen von Ausdrücken dargestellt werden können. 

Die Semantik untersucht die Beziehung zwischen Worten und Ausdrücken einer Sprache und den Objekten bzw. 

Dingen der Realität. Es werden demzufolge “Welten” Kollektionen von Ausdrücken gegenüber gestellt. Typische 

Gegenüberstellungen sind die Gültigkeits- bzw. die Erfüllbarkeitsrelation. 

IS ADD


Die Pragmatik untersucht die Beziehung zwischen Worten und Ausdrücken einer Sprache und dem Wort- bzw. 

Ausdruckbenutzer und konzentriert sich auf Aspekte der Bedeutung für den Benutzer, für eine Gruppe und für 

einen Kontext. Die Pragmatik wird durch eine Reihe von pragmatischen Axiomen geprägt: 

• Man kann nicht nicht kommunizieren. Jedes Verschweigen ist auch eine Darstellung. Im allgemeinen akzeptieren 

wir für die Modellierung eine closed-world-Annahme, bei der die Nichtdarstellung von Dingen 

der Realität auf der Irrelevanz für die Anwendung beruhen. 

• Jede Modellierung hat einen Inhalt- und einen Beziehungsaspekt, wobei der letztere den ersteren bestimmt. 

Es wird implizit oder ggf. explizit die Beziehung zwischen Benutzer und System dargestellt. 

• Die Spezifikation wird durch die Interpunktion der Darstellung mitbestimmt. Interpunktion tritt beim Austausch 

von Mitteilungen auf, bei der zwei Seiten eine unterschiedliche Dekomposition der Mitteilung in 

Bestandteile und die Bedeutungszuordnung für diese Bestandteile vornehmen. Dadurch entstehen unterschiedliche 

Sichtweisen auf den gleichen Ausdruck und entsprechende Beziehungskonflikte. 

• Kommunikation in den Anwendungen bedient sich digitaler Repräsentation. Da aber die Beobachtungen 

oft analog möglich sind, entsteht durch falsche Digitalisierung bzw. Abtastung ggf. ein falsches Bild wie 

z.B. in der Monatsabrechung bei Lagerhaltungsanwendungen oder Monatsstatistiken. 

• Kommunikationsabläufe sind entweder symmetrisch oder asymmetrisch, je nachdem, ob Facetten der 

Kollaboration auf Gleichheit oder Unterschiedlichkeit beruhen. Die unterschiedlichen Facetten können 

gleichzeitig und in unterschiedliche Symmetrierichtungen wirken und sich komplementär ergänzen wie 

in den Beziehungen Fachmann-Laie und Mitarbeiter-Vorgesetzter. 

Neben den semiotischen Aspekten erfordert auch eine Spezifikationsmethodik eine explizite Widerspiegelung 

des Pragmatismus. Der Pragmatismus ist die Lehre, nach der sich das Handeln und Denken am praktischen Leben 

orientiert und diesem dient. Durch den Pragmatismus werden pragmatische Annahmen determiniert. Übliche pragmatische 

Annahmen sind die Auswahl der Sprache, die (Selbst-) Beschränkung bei der Benutzung der Sprache, die 

Wahl der Begriffe und ihrer Assoziationen, sowie die Wahl der Darstellungsmittel im Falle einer Auswahlmöglichkeit. 

Typische pragmatische und nicht dokumentierte Annahmen sind die Art der Attributdarstellung, die Auswahl 

der Wertebereiche und die Handlungsabläufe. Sie werden implizit vorgenommen, z.B. durch eine Annahme zur ersten 

Normalform, die nur atomare Attribute zuläßt, wobei der Begriff des Atoms je nach Modellierungsurteil auch variieren 

kann. Postleitzahlen werden oft als Atom zugelassen, obwohl sie bereits aus Komponenten wie Zustellbereich 

und Zustellbezirk zusammengesetzt sind. Pragmatische Annahmen bilden Tatsachen, Handlungsweisen, Erfahrungen, 

Möglichkeiten, Potenzen und auch Fertigkeiten aus dem Anwendungsgebiet entsprechend dem praktischen Nutzen 

ab. Sie dienen damit dem Ziel einer möglichst effektiven Abbildung des Anwendungsgebietes. 

Das semiotische Dreieck 

• Syntax bzw. Syntaktik 

• Semantik 

• Pragmatik 

ggf. erweitert um Pragmatismus 

ergänzt um die Theorie des Content: Bild 11 

Abstraktionsarten 

1. Konstruktionsabstraktion 

2. Sichtweisenabstraktion 

3. Implementationsabstraktion 

IS ADD


Computation theory 

Computation 

Foundation 

SemT h 

Content 

Syntax 

Annotation 

Intension 

☛ 

✕ 

Semantical 

unit 

Asset 

❑ 

❯ 

Interpretation 

Content, Mod 

Concepts 

Validation 

Model theory 

Semantics 

Pragmatics 

Infon 

Information delivery 

Knowledge map Extension, Content 

Presentation✲Sym, Intension 

Explanation ✛ SemT h 

Symbols 

Presentation 

Presentation theory 

Abbildung 15: Das semiotische Content-Modellierungsdreieck 

Referent 

ViewContentView 

Referent 

Referent 

schema 

View ContentView 

schema 

Referent 

schema 

Chunk 

Unit 

Asset 

Utterance 

Chunk 

Unit 

Asset 

Utterance 

Concept Infon Symbol 

Chunk Utterance 

Referent 

Concept 

schema 

Chunk 

Infon 

Referent 

schema 

Symbol 

schema 

Utterance 

Abbildung 16: The schemata of the semiotic tetrahedron 

IS ADD


Referent 

understanding 


macrodata 

Referent 


Referent 

mems 


ER schemata 

Referent 

mems 

Chunk 

Unit 

Asset 

Utterance 

Chunk 

Unit 

Asset 

Utterance 

Concept 

world 

Chunk 

Infon 

Referent 


Symbol 

map 

Utterance 

Logic 

theories 

Chunk 

Infon 

Referent 

mems 

Symbol 

landscapes 

Utterance 

Abbildung 17: The data and representation languages of the semiotic tetrahedron 

ETL 

Think 

Content 

Referent See 

Think 

Referent 

mems ER schemata mems 

Interprettate 

Anno- 

Logic 

Symbol 

Derive Explain Enrich 

theories 


Look Map 

derivation 

Compute 

Reason 

Content 

Referent 

Query 

Reason 

Referent 

mems ER schemata mems 

Develop Add 

theory metadata 

Logic Represent 


Symbol 

Derive 

Integrate 

theories 

Understand Associate 

Referent 

mems 

Reason 

Referent 

mems 

Think 

Abbildung 18: Conceptual abilities and activities on “content” within the semiotic tetrahedron 

IS ADD


Content 

Symbols 

❦ query ✸ 

Thinking, associate 

reasoning 

by referent 

understand 

❄ 

Concepts 

Referent 

Symbols 

❦ provide ✸ 

Computing 

annotate, add meta-data 

content 

ETL 

build theory 

❄ 

Concepts 

Content 

Symbols 

❦ interpret represent 

✸ 

Derivation 

of concepts 

explain 

❄ 

Referent 

Content 

Referent 

❦ add data ✸ 

Enrich, express 

integrate 

symbols 

explain 

❄ 

Concepts 

Abbildung 19: The referents activities and mappings within the semiotic tetrahedron 

1.6.3 Die Prinzipien der Informatik 

Übersicht: 

Struktur 

Entwicklung 

Kollaboration 

Abstraktion 

Die Informatik hat bislang nicht allzu viele Prinzipien hervorgebracht. Die Mathematik kann man auf die Triade 

reduzieren: Strukturierung, Topologie und Symmetrie bzw. Erzeugung. In der Kristallographie unterscheidet man drei 

Grundbegriffsarten wie in Bild 20. Diese drei Prinzipien sind analog zu den Prinzipien der Quantenphysik. Dieses 

Modell kehrt auch in den Gesellschaftswissenschaften wieder 7 . In analoger Form kann auch die Strukturtheorie der 

Mathematik verstanden werden. 

Gesellschaft 

Topologie 

Topologie 

Gesellschaftswissenschaft 

Kristallographie 

Strukturierung in der Mathematik 

Individuum Entwicklung 

Geometrie Symmetrie 

Algebra Ordnung 

Abbildung 20: Die drei Prinzipien der Kristallographie, der Gesellschaftswissenschaft und der Mathematik 

Die Informatik fügt diesen drei Prinzipien ein weiteres Prinzip hinzu: die Abstraktion. Das Abstraktionsprinzip 

ist bereits in den Ansätzen der Quantenphysik implizit enthalten und ist bei den Prinzipien der Gesellschaftswissenschaften 

verwirklicht. Gleichzeitig erfahren diese Prinzipien viele Ausprägungen. 

7 Diese Vorstellung haben wir leider bislang nicht in der Literatur nachweisen können, obwohl sie zur Folklore gehört. Das Dreieck wird 

oft jedoch als Spannungsdreieck für gesellschaftliche Beziehungen aufgeführt. 

IS ADD


Kommunikation 

Kooperation 

Koordination 

Kollaboration 

Interaktion 

Verteilung 

Agenten 

Systeme 

Zustand 

Architektur 

Modellierung 

Abbildung 

Verfeinerung 

Struktur 

Abstraktion 

Entwicklung 

Evolution 

Regeln 

Konservative Abstraktion 

Approximation 

Zeitliche Entwicklung 

Integration 

Migration 

Komponentenabstraktion 

Lokalisierungsabstraktion 

Implementationsabstraktion 

Abbildung 21: Die vier Prinzipien der Informatik 

e.g., 

• Database engines: structuring, derived rules (for functions), multi-layer abstraction 

• Script programming: collaboration through contracts and name spaces, local binding 

• Communication: protocols and services, networks, standardised rules, packet structuring 

Jedes der vier Prinzipien besitzt unterschiedliche Facetten. So sind die Kooperation, die Kommunikation und die 

Koordination Facetten der Kollaboration. Eine andere Dimension von Facetten ist auch Verteilung und Interaktion. 

Auch für die Abstraktion können wir unterschiedliche Facetten unterscheiden: Facetten des “wie” (Modellierung, 

Abbildung, Verfeinerung) und Facetten des “wodurch” (Approximation, konservative Approximation). 

Die Strukturierung besitzt die Zachman-Aspekte: 

womit materialisiert: Speicher-Struktur, Repräsentationsstruktur und abstrakte Strukturen; 

wodurch repräsentiert: direkte Darstellung und kodierte Darstellung; 

wie konstruiert: Basis-Typen, Konstruktor-Arten und Abschlußbedingungen. 

Je nach Wahl erhalten wir unterschiedliche Sprachen (bzw. “Modelle” wie das relationale oder auch objekt-relationale 

Modelle), Erzeugungsregeln und Materialisierungssprachen. 

Diese vier Prinzipien werden in Zweigen der Informatik unterschiedlich akzentuiert. So konzentriert sich der klassische 

Datenbankentwurf auf die Strukturierung, verwendet eine Art der Abstraktion (die konservative Abstraktion) 

und integriert die Kollaboration implizit im Schema. Komponenten werden innerhalb eines Schemas verschmolzen 

und sind dann Bestandteil einer großen Struktureinheit. Gegebenenfalls werden Aspekte der Verteilung separat behandelt. 

Die Entwicklung von Systemen wird dagegen gar nicht betrachtet. Da die Approximation gar keine Rolle 

spielt, wird sie im weiteren nicht betrachtet. 

Programmiersprachen konzentrieren sich eher auf die Entwicklung von Regeln zur Zustandstransformation. Zustände 

werden durch eine Struktur definiert. Die abstrakten Zustandsmaschinen erlauben darüber hinaus eine Abstraktion 

durch Einführung einer expliziten Verfeinerungsbeziehung. Regeln können sowohl sequentiell, als auch konkurrierend 

als auch parallel angewandt werden. Erstmals mit den abstrakten Zustandsmaschinen wurden auch Postulate 

aufgestellt [Gur00]: 

Postulat der sequentiellen Zeit: Zustandstransformationen erfolgen schrittweise mit einer Zeitlogik, die sequentiell 

ist. 

Postulat der abstrakten Zustände: Zustände können durch eine Struktur über einer Signatur definiert werden, wobei 

Zustandstransformationen nicht die Struktur ändern und invariant gegenüber Strukturisomorphismen sind. 

Postulat der beschränkten Exploration: Zustandstransformationen erfolgen für eine beschränkte bzw. endliche Menge 

von Zuständen des gesamten Zustandsraumes. 

IS ADD


Oft ist es sinnvoll, die vier Prinzipien auf spezifische Art zu betrachten. In unserem Anwendungsfall betrachten 

wir nicht die allgemeine Kollaboration, sondern nur einige Aspekte: Kollaboration im Rahmen der Verteilung und 

Interaktion von System und Akteuren (anstelle von Agenten). Wir betrachten auch im wesentlichen nur die Entwicklung 

von Information innerhalb eines Informationssystemes und weniger die Entwicklung von Systemen selbst. Die 

Abstraktion wird ebenfalls nur in als konservative Abstraktion behandelt. Wir nutzen die Modellierung und konzentrieren 

uns weniger auf Abbildungen und Verfeinerungsmechanismen. Aus diesen vier Prinzipien leiten wir deshalb 

die vier Modellierungsaufgaben ab: 

Modellierung der Strukturierung, 

Modellierung der Funktionalität, 

Modellierung der Verteilung 

Modellierung der Interaktivität. 

und 

Im Abstraktionsprozeß kann man unterschiedliche Aspekte betrachten: 

• Wir unterscheiden drei Abstraktionsarten: 

• Die Komponentenabstraktion kann aufgrund unterschiedlicher Konstruktoren unterschiedliche Ausprägungen 

besitzen: 

• Die Klassenabstraktion orientiert sich auf die Unterscheidung von Instantiierung und Klassifizierung. 

• Die Konstruktorabstraktion orientiert sich an der Benutzung der im Datenbankmodell vorhandenen 

Konstruktoren. Daraus resultieren Operationen wie die Aggregation und die Dekomposition. 

• Die Beziehungen zwischen Klassen können explizit modelliert sein. 

· Durch Teiltypenhierarchien werden die Generalisierung und Spezialisierung von Klassen dargestellt. 

· Die Konstruktionsbeziehungen folgen meist der Definitionsbeziehung. 

· Abbildungsbeziehungen werden für Datenbanken auf die Sichtenmodellierung reduziert. 

• Die Lokalisierungsabstraktion orientiert auf eine Verallgemeinerung ohne Bezug zur konkreten Umgebung. 

• Die Wiederholung von Konzepten (Parametrisierung von Konzepten) orientiert auf der Grundlage 

einer Anwendungsabstraktion auf analoge Konzepte und Hierarchien artgleicher Konzepte. Der Entwurf 

von Einheiten kann auf verschiedene Abstraktionsebenen verteilt werden. 

• Durch Sharing von Konzepten, adäquate Namensgebung (Variablenkonzepte) und Verbinden kann 

ein Muster von Konzepten wiederholt werden. 

• Die Wiederholung von Funktionen kann sowohl für unterschiedliche Strukturen als auch unterschiedliche 

Teile der Anwendung sinnvoll sein. 

• Die Verteilungsabstraktion auf der Grundlage eines Namensgebungs- und Verbindungskonzeptes 

verbessert die Einsichtigkeit und Nachvollziehbarkeit von Konzepten. 

• Durch Implementationsabstraktion oder Modularisierung von Struktur, Semantik und Operationalität auf 

der Grundlage von Verkapselung und Scoping kann die Konzeptunabhängigkeit verbessert werden. Wichtige 

Methoden sind: 

• das Verstecken von Konzepten (Sichtenbildung) (private, Gruppen- und Weltkonzepte) und 

• Abbildungsmechanismen für Sichten. 

• Wir unterscheiden im Informationssystementwurfsprozeß Konstruktionsarten. Allgemeine Hilfsmittel 

zur Darstellung der einzelnen abstrakten Konstrukte sind in Anlehnung an Konstruktorkonzepte die folgenden 

Elemente: 

• Elementare Einheiten zur Darstellung von Basiskonzepten, 

IS ADD


• Konstruktionsregeln zur induktiven Konstruktion von komplexeren Konzepten aus bereits konstruierten 

oder Basiskonzepten (die meist als Konstruktionsmethodiken verstanden werden) und 

• Konsistenzregeln wie Integritätsbedingungen und die ‘Normalisierung’ erlauben eine Sicherung der Qualitätsanforderungen. 

Einbettungsregeln ermöglichen eine Integration in den bereits vorhandenen Entwurf unter Berücksichtigung 

von Prioritäten, Anwendbarkeitsregeln etc. 

Zur Darstellung von Strukturierung und Funktionalität können verschiedene Repräsentationsmechanismen 

gewählt werden. 

1.6.4 Herangehensweisen des SW-Entwicklungsprozesses 

In der Softwaretechnik und der Wirtschaftsinformatik wird oft eine Herangehensweise im Rahmen eines Software- 

Entwicklungsprozesses präferiert [HP97]: 

1. Definition des Gestaltungsbereiches: Die bisherigen Prozesse werden rudimentär analysiert. Damit kann 

eine Definition der Kerngeschäftsbereiche und der wichtigsten Prozesse erfolgen. 

2. Formulierung der provisorischen Ziele: Die Probleme und Schwachstellen des derzeitigen Systemes werden 

durch Interviews, Fragebogen, Beobachtungen und Experimente aufgefunden. 

3. Analyse der bisherigen Prozesse: Die aktuell vorhandenen Prozesse werden mit entsprechenden Aktivitäten 

verglichen. Es wird die Systemleistung mit Meßkriterien wie Durchlaufzeit, Kosten, Fehlerquote etc. ermittelt. 

Die Untersuchung beruht auf einer Reihe von Qualitätsparametern: 

• Allgemeine Aspekte wie der Output des Produktes, Abnehmer, Häufigkeit der zukünftigen Änderungen, 

• Zeitaspekte wie Länge, Liegezeit, Bearbeitungszeit, Transportzeit, termingerechter Abschluß, 

• Qualitätsaspekte und Zufriedenheit wie Arbeitszufriedenheit, Anforderungen der ‘Kunden’, Beanstandungen, 

iterative Fehlerreparaturen, weitere Anpassungen des Prozesses, 

• Struktur- und Mengendaten, z.B. die Anzahl der Teilnehmer, Häufigkeit, parallele Prozesse, Rollen, Organisationseinheiten, 

Anzahl der Aktivitäten, parallele Aktivitäten, Adressaten, Inputinformationen, Koordinierungsaktivitäten, 

Verantwortlichkeit, benötigte Sachmittel, 

• Aufwand und Ertrag versus Kosten/Nutzen, z.B. Materialkosten, Informatikkosten, Personalkosten, Gemeinkosten. 

4. Globale Strukturierung und Selektion eines zu verändernden Prozesses: Es wird eine Migrationsstrategie 

vom abzulösenden System hin zum neuen System erarbeitet. 

5. Formulierung der definitiven Ziele: Es werden die Ziele an den notwendigen Verbesserungen orientiert und 

je nach Bedeutung für zukünftige Prozesse gruppiert und geordnet. Dadurch entsteht ein Zielportfolio mit einer 

Konzentration auf zentrale Ziele. 

6. Ermittlung von organisatorischen Maßnahmen: Zum Erreichen des Zieles werden Maßnahmen anhand der 

vorher herausgearbeiteten Schwerpunktaufgaben abgeleitet. 

7. Ermittlung von technischen Maßnahmen: Darauf aufbauend wird die technische Infrastruktur abgeleitet. 

8. Grobmodellierung der Geschäftsprozesse: Im ersten Entwicklungsschritt wird eine Grobstruktur des zukünftigen 

Prozesses mit echten obligatorischen Aufgaben abgeleitet. Dazu werden Darstellungsmittel wie ereignisorientierte 

Prozeßketten, Information Control Nets, Process Analysis and Design Method, Petrinetze, Role 

Activity Diagrams, semantische Objektmodelle, Triggermodellierung genutzt. Einzelne Schritte sind dabei: 

• Modellierung des Geschäftsvorfalles, 

IS ADD


• Ablaufmodellierung, 

• Organisationsmodellierung nach der Iststruktur, 

• Informationsmodellierung, 

• Definition objektbezogener Business-Regeln und 

• Organisationsmodellierung nach der Sollstruktur. 

9. Feinmodellierung des zukünftigen Geschäftsprozesses: Es kann nun die Aufgabenverteilung für die einzelnen 

Partner im Entwicklungsprozeß abgeleitet werden. Diese analysieren den Daten- und Dokumentenfluß, 

die Entscheidungsregeln, die Geschäftsfalldaten, die Kompetenzregeln, die Kooperationsregeln, die Methodenregeln 

und die Zeitregeln. Auf dieser Grundlage werden einzelne Komponenten des Systemes erstellt. 

10. Evaluierung der einzelnen Komponenten des Systemes: Die erstellten Komponenten werden anhand der 

Ziele evaluiert. Es werden außerdem Benutzungsoberflächen und die Dokumentation erstellt. 

11. Systemkonfiguration: Nach Erstellung der Einzelkomponenten wird das Gesamtsystem entwickelt und konfiguriert. 

12. Aus- und Weiterbildung der Mitarbeiter: Die Mitarbeiter im Betrieb werden schrittweise an das neue System 

herangeführt. 

13. Prüfen der Systemsicherheit, Wirtschaftlichkeit und Ergonomie: Das System wird anhand von Qualitätskriterien 

wie 

• Sicherheitskriterien, z.B. Integrität, Verbindlichkeit, Verfügbarkeit, Vertraulichkeit 

• Wirtschaftlichkeit, wie Anpassungsfähigkeit an veränderte Prozeßabläufe, Durchlaufzeit, Durchschaubarkeit, 

Nachvollziehbarkeit der Prozesse, Investitionen und Betriebskosten, Zahl und Qualifikationsniveau 

der Mitarbeiter 

analysiert. 

14. Inbetriebnahme des Systemes: Nach einem Migrationsplan wird das System schrittweise in die Praxis 

überführt. 

Diese und andere Methodiken zeichnen sich z.T. durch sehr große Detailliertheit aus, sind aber in den wesentlichen 

Teilen zu unscharf und wenig brauchbar. 

Ein anderer, ebenso wenig praktikabler Zugang wird in der klassischen Datenbankliteratur verfolgt. Der klassische 

Entwurf einer Informationssystemanwendung ist von einer Reihe von Brüchen gekennzeichnet. 

Struktur-/Funktionsbruch: Die meisten Methodiken und Werkzeuge unterstützen beim Entwurf keine gleichgewichtige 

Sicht auf Strukturierung und Funktionalität von Informationssystemen. Prozesse werden meist nur in 

einer rudimentären Form spezifiziert. Durch zusätzliche Einflußnahme kann ein Administrator auch Strukturen 

und Funktionen im internen Schema einer Datenbank verändern. Damit kann der Zusammenhang mit dem 

konzeptuellen Schema vollständig zerstört werden. 

Struktur-/Semantikbruch: Datenintensive Anwendungen zeichnen sich meist durch eine komplexe Struktur aus. 

Die statische Semantik wird entweder intuitiv durch die angewandten Konstruktoren verstanden oder erfordert, 

wie im relationalen Fall, tiefgründige Kenntnis der mathematischen Logik. Damit wird aber die Konsistenz in 

der Spezifikation entweder willkürlich oder nicht mehr nachvollziehbar. 

Funktions-/Verhaltensbruch: Die Funktionen werden durch mehr oder weniger komplexe Prozesse und Operationen 

implementiert. Das Verhalten dieser Prozesse kann auf der Grundlage einer kompositionellen Semantik in 

einigen Spezialfällen hergeleitet werden. Damit ist aber nur ein Teil der dynamischen Semantik erfaßt. Sobald 

Prozesse zumindest in den Strukturen zyklisch werden, ist eine kompositionelle Semantik nur noch mit tiefgründigen 

Theorien darstellbar. Noch schwieriger ist die Darstellung der Abhängigkeiten zwischen Prozessen. 

IS ADD


Oberflächenbruch: Verschiedene Anwender verlangen unterschiedliche Sichten auf die Datenbank und unterschiedliche 

Arbeitsweisen für die Arbeit mit der Datenbank. Werden die Oberflächen erst nachträglich entwickelt, 

dann ist eine Vielfalt von Sichten zur Unterstützung unterschiedlicher Benutzungsarten zu entwickeln. Außerdem 

verlangt eine Sicht oft auch eine eigenständige Funktionalität. Diese Vielfalt ist spätestens bei einer 

Modifikation nicht mehr zu überschauen. 

Workflow-Bruch: Geschäftsprozesse können analog zu langandauernden Transaktionen im Ablauf unterbrochen 

werden, auf anderen Geschäftsprozessen basieren und unterschiedliche Granularität besitzen. Damit entsteht 

ein komplexes Ausführungsmodell, das von einem Normalentwickler nicht mehr überschaut wird. 

CASE-Tool-Bruch: Die meisten Entwicklungsumgebungen erlauben, wenn sie über reine Malprogramme hinausgehen, 

nur eine Einbahnstraße in der Entwicklung. Nach der Erzeugung des logischen Modelles aus dem Entwurfsmodell 

ist es in der Regel unmöglich oder zumindest sehr schwer, beide Modelle miteinander konsistent 

zu halten. Es ist deshalb eine ‘harte Kopplung’ der konzeptuellen, externen und internen Modelle erforderlich. 

Jede Modifikation eines Schemas zieht ansonsten schwierige Reorganisationen der Datenbank nach sich. 

Diese Brüche entstehen durch unterschiedliche Ziele im Verlaufe des Entwicklungsprozesses, wie z.B. 

• Konzentration auf einen Aspekt ohne Berücksichtigung anderer Aspekte oder 

• Verfügbarkeit einer bestimmten (zumeist unvollständigen) Entwicklungsumgebung oder einer bestimmten Entwicklungsmethodik 

und resultieren in 

• unterschiedlichen Spezifikationssprachen und 

• unterschiedlicher Semantik und Bedeutung der einzelnen Sprachkonstrukte. 

Außerdem implizieren sie eine Nichtberücksichtigung der Bedürfnisse des Endbenutzers. 

Das Matrixmodell zur Einordnung der Modellierungsmethoden (nach Specker) 

primär/sekundär Prozeßsicht Funktionssicht Objektsicht Aufgabensicht Techniksicht 

Funktionssicht 

Objektsicht 

Aufgabensicht 

Techniksicht 

Werkzeuge 

Flußdiagramm 

(UML) 

Systemschrittstellendiagramm 

Funktionsmodell 

(UML) 

Systemfunktionsdiagramm 

Sequenzdiagramm 

(UML) 

Stellenorientiertes 

Ablaufdiagramm 

Prozeß- 

Technologie- 

Diagramm 

Datenflußdiagramm 

(UML) 

Use Case Diagramm 

(UML) 

Prozeßsicht Prozeßmodell Funktionen- 

Blockdiagramm 

(UML) 

Zustandsübergangsdiagramm 

(UML) 

Class- 

Responsibility- 

Collaborator 

(UML) 

Objektmodell 

(UML) 

Kollaborationsdiagramm 

(UML) 

Stellenorientierter 

Informationsfluß 

Stellenfunktionsdiagramm 

(UML) 

Arbeitsobjektdiagramm 

Datenobjektdiagramm 

Organisationsdiagramm 

Systemnutzungsdiagramm 

Funktionsunterstützungsdiagramm 

Objektzugriffsdiagramm 

Technikeinsatzdiagramm 

Systemarchitekturmodell 

IS ADD


1.6.5 Grundlegende Herangehensweisen 

• datenflußorientiert, 

• prozeßorientiert, 

• integriert 

IS ADD


1.7 Komponentenbasierte Herangehensweise 

Model-driven architectures 

als der erste (leider kleine) Schritt zur Vernunft Data model pattern (Hay), Kompositionslehre 

1.7.1 Architekturen von Informationssystemanwendungen 

einschließlich Realisierungsarchitekturen 

IS ADD


1.8 Das Abstraktionsschichtenmodell 

1.8.1 Probleme abgeleiteter Konzepte 

Probleme mit Sichten. 

Das Sichten-Update-Problem 

Sichten-Turm-Probleme z.B. auch mit Wegflutschen von Objekten nach update 

Sichten- 

Die Modellierung von Strukturierung, Funktionalität und Verteilung wird nicht vollständig durch die vorhandene 

DBMS-Welt unterstützt. Ein Hindernis ist das Sichtenupdate-Problem. Da mit der Erzeugung von Sichten ggf. 

auch nicht jedes Sichtenobjekt einem Datenbankobjekt zugeordnet werden kann, muß deshalb für eine Modifikation 

der Datenbank eine andere Funktion zur Verfügung gestellt werden. Deshalb ist die Architektur in Bild 22 eine 

sinnvolle Alternative, die unserem Vorhaben des integrierten Entwurfes entgegenkommt. Wir unterscheiden damit 

zwischen Retrieval-Sichten und Modifikationssichten. Dieses Bild zeigt zugleich auch die Unterschiede in der Betrachtungsweise 

relativ gut auf. Für den Benutzer oder eine Benutzergruppe ist die Anwendung stets lokal. Er nutzt 

Dialoge, um mit dem Informationssystem bestimmte Aufgaben zu lösen. Dabei werden ihm entsprechende Daten 

zusammengestellt und übermittelt. Diese Zusammenstellung fassen wir mit einem Container zusammen. Außerdem 

besitzt dieser Container auch die entsprechende Funktionalität, um den Umgang mit den Daten entsprechend den 

Dialoganforderungen zu erleichtern. Die Modifikationssichten und die Retrievalsichten sind hierbei entsprechend zusammengefaßt. 

Das DBMS unterstützt die Anwendung durch die Bereitstellung von Prozessen, die Speicherung der 

Daten und die Erzeugung und Verarbeitung der Sichten. 

Lokalisierungsabstraktion 

✻ 

lokale 

unterstützte Sichten, 

Funktionalität, 

Container 

Sichten, 

✲ 

Informationseinheiten 

Szenen 

Akteure 

✻ 

✻ 

Filtrierung 

Konstruktion 

zugelassene 

Modifikationsanforderungen 

zugelassene 

Prozesse 

globale 

Datenbankschema 

✠ 

statische Aspekte 

✲ 

bereitgestellte 

Prozesse 

Prozesse 

dynamische Aspekte 

Aspektkategorien 

✲ 

Abbildung 22: Die Infrastruktur für die integrierte Entwicklung von Informationssystemen 

Unsere Vorstellungen zur Infrastruktur wird durch Datenbanksysteme gut unterstützt. 

Ein gut entwickeltes Datenbanksystem erlaubt die Pflege der Strukturierung und stellt die entsprechende Funktionalität 

für die Prozesse zur Verfügung. Ein Benutzer sieht ein Informationssystem aus einer anderen Sicht. Ihm 

wird ein Interaktionsraum zur Verfügung gestellt. Die Benutzung des Systemes findet im Rahmen des Story-Raumes 

IS ADD


✻ 

✻ 

Informationssystem 

Datenbanksystem 

Content- 

Typen 

✻ 


Story- 

Raum 

✲ 

✲ 

✲ 

Abbildung 23: Die Unterstützung von Informationssystemen durch Datenbanksysteme und Content-Typen 

statt. Durch Content-Typen werden der Interaktionsraum und das Datenbanksystemes zu einem Informationssystem 

verbunden. Wir werden im weiteren sehen, daß Content-Typen eine komfortable Erweiterung des Sichtenkonzeptes 

für Informationssysteme darstellen. 

Probleme mit abgeleiteten Attributen. 

Zyklische Berechnung 

Probleme mit Ableitungsoperationen. 

Aggregationsfunktionen 

Simpson-Paradox 

Probleme mit optionalen Konzepten. 

Nullwerte 

optionale Beziehungen 

Modellierungstricks am Beispiel von ERM. 

Attribut-/Entitytypen: rigide Trennung in Eigenschaften und Dinge auch auf Objekt- und Attributebene fortgesetzt 

Eigenschaften können auch nichtableitbar oder nichtzuordenbar sein: dann eigener Entity-Typ 

Entity-/Relationshiptypen: Dinge der Realität mit unabhängiger Existenz stets als Entitytyp 

Dinge der Realität, die als Verbindung dienen oder Rollen darstellen können auch durch Relationshiptyp dargestellt 

werden 

Taxonomische Strukturen zur Abbildung von Teilmengen, Teilrollen, Superrollen, Generalisierungen 

• Regeln zur Klassifikation: Vorhandensein eines Klassifikationsattributes für Spezialisierung; Subklassen 

sollten eine entsprechende Größe haben; Spezialisierungen sollten informativ sein 

• Statische versus dynamische Klassifikation: dynamisches Umshiften von Objektmengen sollte vermieden 

werden (z.B. abhängig vom Verwendungszweck (Speichergefäß, Kochgefäß)); ansonsten Migrationsprobleme 

• Klassifikation und Abzählungen: jedes Objekt sollte in einer Subtypenhierarchie auch als Wurzelobjekt 

auftauchen (ansonsten komplexe Berechnungen); Vorsicht mit Klassifikationen, die zu komplexen Berechnungen 

führen 

Daumenregel: dividing range wird auf dem Ding-Niveau angesetzt, nicht auf Abstraktionen 

IS ADD


• Teiltypen und Rollen, Supertypen und Abstraktionen: Rollen sollten explizit ausgewiesen werden 

(Bsp: Firma - Angestellte(Firma,Person) - Person anstatt Firma - Person(in Rolle Angestellter)) 

am bestem strikte Modellierung von Rollen 

Validierung anhand von Daumenregeln 

• Konsistenztest ggf. durch Werkzeuge 

• Formulierungstest durch einfache Sätze 

• Schnappschußtest anhand von Beispielen 

• Identifikationstest: jedes Objekt muß einfach identifizierbar sein 

1.8.2 Aspekte von Informationssystemen auf unterschiedlichem Abstraktionsniveau 

Gebraucht der Zeit, sie geht so schnell von hinnen! 

Doch Ordnung lehrt Euch Zeit gewinnen. 

Mein teurer Freund, ich rat euch drum 

Zuerst Collegium Logicum. 


Natürliche Abstraktion durch unterschiedliche Detailiertheit. 

Wir erhalten aus Anforderungen der vorigen Kapitels die Aufgabe, Strukturierung, Funktionalität, Dialoge, Verteilung 

und Sichten auf eine Datenbank im Zusammenhang zu entwerfen. Vereinfachend ist dabei, daß die Dialoge 

auf den Sichten und den Prozessen aufsetzen und daß die Sichten in das Schema einbindbar sein sollen. Die Prozesse 

werden damit über diese Einbindung in das Schema auch für die Sichten benutzbar. Damit erhalten wir ein 

Entwurfsviereck, bestehend aus der Datenspezifikation, der Funktionsspezifikation, der Verteilungsspezifikation und 

der Dialogspezifikation. 

Das Zachman-Modell zur Separation von Aspekten. 

Durch Zachman wurden Ende der achtziger Jahre allgemeine Modellierungsregeln eingeführt, die mit dem Abstraktionsschichtenmodell 

verallgemeinert werden: 

• Es werden verschiedene Dimensionen der Entwicklung unterschieden: 

• Die Dimension der statischen Aspekte stellt Strukturierung der Daten und die Sichten dar. 

• Die Dimension der dynamischen Aspekte soll die Funktionalität und die Interaktivität der Anwendung 

repräsentieren. 

• In der Verteilungsdimension wird die Lokalität der Strukturen und Prozesse dargestellt. 

• Die Benutzerdimension dient der Darstellung des Systemes aus Benutzersicht einschließlich der Organisationsmodelle. 

• In der Zeitdimension wird die Entwicklung der Anwendung dargestellt. 

• Mit der Motivationsdimension erfolgt eine explizite Darstellung der Umstände, Ziele und Motive für die 

einzelnen Aspekte der Anwendung. 

• Jede der Dimensionen verfügt über ein einfaches und eindeutiges Basismodell. 

• Jede der Dimensionen repräsentiert genau eine Sichtweise auf die Anwendung. 

• Jedes abstrakte Objekt wird nur einmal repräsentiert. 

IS ADD


• Entwurfsprodukte sind aufgrund ihrer Architektur und Entwurfsgeschichte rekursiv oder iterativ aufgebaut. 

Ziel Produkt Randbedingungen 

Planer Beschreibung des Spielraumes Beschreibung des Spielraumes Finanzierung, Regeln, Infrastruktur 

Besitzer Reales Produkt Geschäftsmodell Strategie, Verwendung, Storyraum 

Entwerfer Beschreibung des abstrakten Produktes 

System-Modell 

Umgebung, Stories, “Chemie” 

Implementierer Beschreibung des Produktes und 

seiner Verwendung 

Technologie-Modell 

State-of-the-art bei Hard- und Software, 

Verteilung 

Komponentenlieferant 

Beschreibung der Komponenten Out-of-context-Modelle Implementation, Integration 

Das Entwicklungsmodell in den unterschiedlichen Sichtweisen 

Mit dieser Verallgemeinerung wird die Mitwirkung unterschiedlicher Personen zu unterschiedlichen Zeiten im 

Entwicklungsprozeß sichtbar: 

Planer in der Anwendungsschicht: Durch den Systemplaner wird eine Analyse des gegebenen Zustandes und eine 

Zielbestimmung für die gesamte Anwendungsentwicklung vorgenommen. 

Besitzer in der Anwendungsschicht: Durch den Besitzer werden die Randbedingungen für die Entwicklung vorgegeben. 

Entwerfer in der konzeptuellen Schicht: Ein Entwerfer ist hauptverantwortlich in der konzeptuellen Schicht, zugleich 

allerdings Partner der anderen Personen in allen anderen Schichten. 

Programmierer und Anwendungsentwickler in der Implementationsschicht verwenden die Entwurfsdokumente 

zum Erstellen der Programme. Änderungen der Entwurfsdokumente sind abzustimmen. 

Komponentenlieferant in Abhängigkeit vom Entwicklungsmodell: Das Komponentenmodell ist orthogonal zu 

den anderen Entwicklungsmodellen und wird deshalb auch in die anderen Entwurfsdokumente integriert. Je 

nach Abstraktionsschicht erfolgt eine unterschiedliche Einbindung. 

Das Zachman-Modell der Rollen während der Entwicklung von Informationssystemen ist noch relativ grob. Wir 

können feiner unterscheiden z.B. 

Rollen aus dem Umfeld (Genehmigungsbehörden, Einspruchsberechtigte, Öffentlichkeit), 

Rollen der Bestellung (‘Bauherr’, Eigentümer, Finanzgeber (Investor, Finanzierender, Subventionsgeber), Betreiber 

(Verwaltung, Erhaltung), Benutzer, Projektleiter, Besteller, Berater), 

Rollen der Lenkung: (Gesamtleitung, Leitung Projektierung, Leitung Programmierung, Leitung Administration, 

Leitung Infrastruktur), 

Rollen der Gestaltung (Projektierung, Architekt, Berater) und 

Rollen der Ausführenden (Entwerfer, Graphikdesigner, Programmierer). 

Das Zachman-Modell verdeutlicht unterschiedliche Abstraktionsschichten mit unterschiedlicher Spezifikation und 

unterschiedlicher Detaillierung. Ein integrierter Entwurf muß deshalb auch unterschiedliche Detaillierungsgrade 

ermöglichen. Günstig ist, wenn die Entwurfsdokumente aufeinander Bezug nehmen bzw. eine Untersetzung der Entwurfsdokumente 

der nächsthöheren Schicht wie in Bild 24 darstellen. 

Gleichzeitig beobachten wir, daß drei Dimensionen in der Modellierung auseinander gehalten werden müssen: 

IS ADD


✌ 

❄ 

☛ 

❄ 

Abbildung 24: Entwurfseinheiten auf verschiedenen Abstraktionsebenen 

Abstraktionsschicht: Die Schichtung sollte hierarchisch wie in Bild 24 erfolgen, damit die Entwurfsdokumente 

zueinander einfach in Beziehung gesetzt werden können. 

Architektur der Komponenten: Können die Komponenten der Anwendung separiert werden, dann kann auch eine 

Architektur der Komponenten mit expliziter Darstellung ihrer Zusammenhänge erfolgen. 

Versionen der Entwicklungsresultate: Jedes Entwurfsdokument kann im Verlaufe der Entwicklung revidiert werden. 

Deshalb sollte man eine explizite Pflege von Versionen in den Entwurfsprozeß integrieren. 

Diese drei Dimensionen spannen einen Entwicklungsraum wie in Bild 25 auf. 

Abstraktionsschicht 

✻ 

✲ Version 

✠ 

Architekturkomponente 

Abbildung 25: Entwicklungsdimensionen für dei Entwurfsdokumente 

Das Abstraktionsschichtenmodell zur integrierten und abgestuften Entwicklung. 

Wir betrachten explizit unterschiedliche Abstraktionsschichten und integrieren die Darstellung der Architektur 

der Anwendung und die Versionierung explizit in die einzelnen Entwurfsschritte. Damit unterscheiden wir folgende 

Schichten: 

die Motivationsschicht zur Spezifikation der Ziele, der Aufgaben und der Motivation der Informationssystemanwendung, 

IS ADD


die Geschäftsprozeßschicht zur Spezifikation der Geschäftsprozesse, der Ereignisse, zur Grobdarstellung der unterlegten 

Datenstrukturen und zur Darstellung der Anwendungsstory, 

die Aktionsschicht zur Spezifikation der Handlungen, der Detailstruktur der Daten im Sinne eines Vorentwurfs, zur 

Darstellung eines Sichtenskeletts und zur Darstellung von Szenarien zu den einzelnen Anwendungsstories, 

die konzeptuelle Schicht zur Darstellung der Prozesse, des konzeptuellen Schemas, der konzeptuellen Sichten und 

der Dialoge in zusammenhängender Form, 

die Implementationsschicht zur Spezifikation der Programme, der physischen und logischen Schemata, der externen 

Sichten und zur Darstellung der Inszenierung. 

Die Motivationsschicht kann als strategische Schicht aufgefaßt werden. Es werden alle strategischen Entscheidungen 

zum Informationssystem getroffen. Die Geschäftsprozeßschicht wird oft auch als Anforderungsspezifikationsschicht 

bezeichnet. Im Rahmen dieser Schicht werden neben den Anforderungen jedoch auch konkrete Entscheidungen 

zur Realisierung getroffen, so daß wir diese Schicht zur Spezifikation der Anforderungen, der pragmatischen 

Annahmen, der Systemumgebung und der Systemorganisation und -architektur erweitern müssen. Die Aktionsschicht 

ist mit dem Abstraktionsschichtenmodell eingeführt worden, um eine explizite Darstellung der Anwendungsszenario 

vornehmen zu können. Im klassischem Systementwurf wird diese Schicht meist übergangen und zu einem späteren 

Zeitpunkt durch entsprechende Sichten-Suiten hinzu gefügt. Damit entsteht ein Systembruch, den wir mit der 

expliziten Darstellung vermeiden können. 

Die Betrachtung der physischen Realisierung ist keine Aufgabe des Informationssystementwurfes und wird ebenso 

wie die Pflege- und Einführungsschicht in diesem Buch nicht behandelt. Die Verteilungs- und die Sicherheitsaspekte 

sind orthogonale Aspekte und werden mit den Entwicklungsschritten verflochten. 

Das Abstraktionsschichtenmodell in Bild 26 erlaubt eine Entwicklung von Informationssystemen im Zusammenhang. 

Wir können ein schichtenorientiertes Vorgehensmodell ebenso wie ein Modell anwenden, das sich zuerst auf 

einen der Aspekte orientiert. 

Die Spezifikationssprachen können sich für die Schichten und die einzelnen Spezifikationsteile stark unterscheiden. 

Eine solche Sprachvielfalt ist jedoch nicht immer angebracht. Wir können aber einen Sprachmix verwenden, 

der sich mit jeder weiteren Schicht immer stärker auf die formalen Teile orientiert. Vorstellbar und praktikabel ist ein 

Sprachmix aus natürlichsprachigen Äußerungen, Formulartechniken und formalen Darstellungsmitteln wie Diagrammen 

zur Darstellung der Datenstrukturen und der Sichten, formalen Prozeßsprachen und Skriptsprachen zur Darstellung 

von Drehbüchern. Für die Implementationsschicht benötigen wir eine formale Darstellung mit exakt definierter 

Semantik, für die konzeptuelle Schicht ist dies ebenso notwendig. Wenn wir uns für einen Sprachmix entscheiden, 

dann sollten wir in jedem Fall die Abbildbarkeit der Konstrukte von Schicht zu Schicht garantieren können. 

Auf die natürliche Sprache sollte schon aufgrund des ihr innewohnenden Potentials keinesfalls verzichtet werden. 

Formulartechniken sind eine Vorstufe der formalen Darstellung. Formale Techniken wie ER-Modelle oder CSP- 

Modelle sind für den direkten Anwender weniger geeignet, sind aber - mit einer entsprechenden Semantik versehen 

- sehr gut zur Darstellung in der konzeptuellen Schicht geeignet. 

Wir werden im weiteren zuerst einmal die einzelnen Spezifikationsteile im Abstraktionsschichtenmodell untersuchen. 

Dabei können wir auf die Erkenntnisse, die in den vorangegangenen Kapiteln dargestellt sind, zurückgreifen. 

Anschließend zeigen wir, wie ein schichtenorientiertes Vorgehensmodell im Sinne eines allgemeinen Top-down- 

Modelles sinnvoll, einfach und im Zusammenhang angewandt werden kann. 

Mit unserem Vorgehen entsteht für eine etwas umfangreichere Anwendung mit etwa 500 Entity-, Relationshipund 

Cluster-Typen im ersten Schritt ein kurzes (sechsseitiges) Essay mit der Beschreibung der Ideen und Motive, 

ein längeres (30-seitiges) Treatment (Lastenheft) zur groben Darstellung der Strukturen, Prozesse, Dialoge und Zusammenhänge, 

ein (100-seitiges) Rohbuch (Pflichtenheft) zur Darstellung der Aktionen, Vorentwürfe, Handlungen, 

Sichtenskelette, Szenarien, ein (200-seitiges) Buch zur Darstellung des konzeptionellen Entwurfes und ein (500- 

seitiges) Werk zur Darstellung der Implementation. Diesem Vorgehen kann entgegengehalten werden, daß ein von 

Intuitionen geprägter Entwicklungsprozeß eher geeignet ist, ein Ziel zu erreichen. Damit kann ein einfacher Entwurf 

entstehen, der in einem Lehrbuch etc. dargestellt werden kann, nicht aber ein komplexerer Datenbankentwurf. Wie 

IS ADD


Feinstudie 

Vorstudie 

❄ 

Entwurf 


❄ 


Schicht 

❄ 

Implementationsschicht 

❄ 

Aktionsschicht 

Geschäftsprozeßschicht 

Anwendungsschicht 

Spezifikation 

der Strukturierung 

Spezifikation 

der Verteilung 

Spezifikation 

der Funktionalität 

Spezifikation 

der Interaktivität 

Abbildung 26: Das Abstraktionsschichtenmodell des Informationssystem-Entwicklungsprozesses 

IS ADD


sehr ein intuitiver Stil gepflegt werden kann, hängt auch von der Professionalität der Entwerfer ab, die - wie die (DB) 2 

bzw. ID 2 community zeigt - z.T. umfangreiche, verarbeitete, bewußte und vor allem unbewußte Kenntnisse über die 

Strukturen, Prozesse und Dialoge einer Anwendung besitzen. 

In den nächsten Teilkapiteln stellen wir zuerst die Datenspezifikation, die Funktionsspezifikation und die Sichtenspezifikation 

in aller Kürze vor. Anschließend führen wir exemplarisch die Dialogspezifikation detailliert ein. Da 

für die ersten drei Spezifikationen bereits viele Untersuchungen existieren, für die letzte aber kaum Material existiert, 

versuchen wir damit auch zugleich eine Lücke in der Datenbankliteratur zu schließen. 

Resultate der Entwicklung auf unterschiedlichem Abstraktionsniveau. 

Das Abstraktionsschichtenmodell erlaubt die Darstellung der Entwicklungsresultate auf unterschiedlichem Abstraktionsniveau. 

Wir folgen hier im wesentlichen dem induktiven Ansatz zur Beschreibung. Damit ist jedes Resultat 

aus jeder Sichtweise (Strukturierung, Funktionalität, Interaktivität, Unterstützung der Interaktivität) als generelle Einheit 

oder Basiseinheit spezifizierbar. Resultate der Entwicklung der Informationssystemanwendung sind: 

Produkte zur Darstellung der Strukturierung sollen die Strukturierung der Daten auf unterschiedlichem Abstraktionsniveau 

beschreiben. Wir nutzen dazu eine Separation der Spezifikation in 

Schema zur Beschreibung der gesamten Strukturierung und 

Daten-Typ zur Beschreibung der einzelnen Struktur und der Integritätsbedingungen. 

Produkte zur Darstellung der Funktionalität sollen eine Darstellung der Funktionsaspekte ermöglichen. Wir unterscheiden 

Workflows zur Darstellung der Folgen von 

Prozessen der Anwendung. 

Produkte zur Darstellung der Interaktivität sollen eine Beschreibung der Anwendung aus der Sicht der Benutzer 

ermöglichen. Deshalb wird die Interaktivität als Raum von Handlungsabläufe der Benutzer oder ihrer Abstraktionen 

als Akteure, d.h. als Story-Raum beschrieben. Dieser Story-Raum fußt auf 

Szenen zur Beschreibung eines generellen Schrittes der Anwendung und auf 

Dialogschritten zur Beschreibung der einzelnen Aktionen. 

Produkte zur Darstellung der Unterstützung der Verteilung sind im Rahmen von Anwendungen der Informationssysteme 

Sichten auf die Datenbanksysteme, 

Dienste zur Bereitstellung der erweiterten Sichten und deren 

Austauschrahmen. 

Wir wollen diese Entwicklungsresultate auf unterschiedlichem Abstraktionsniveau darstellen. Wir können jeweils die 

Resultate mit der Abstraktionsschicht verbinden. Dann sind die Abstraktionsschichten mit folgenden Entwicklungsresultaten 

verbunden: 

Motivationsschicht mit dem Lastenheft, 

Geschäftsprozeßschicht mit dem Pflichtenheft, 

Aktionsschicht mit der Aktionsspezifikation und den vier Aspekten Anwendungsschema, Nutzer-Maschine, Storyboard 

und Aktionssichten-Suite, 

IS ADD


Konzeptionelle Schicht auf Grundlage der konzeptuellen Spezifikation und der Beschreibung der vier Aspekte durch 

ER-Schema, Workflow-Maschine, Drehbuch und Sichten-Suite, 

Implementationsschicht auf Grundlage der logischen Spezifikation und einer Beschreibung der vier Aspekte durch 

logisches Schema, Datenbank-Maschine, Inszenierung und logische Sichten-Suite. 

Demzufolge können wir die Entwicklungsprodukte für die entsprechenden Abstraktionsschichten wie auf der folgenden 

Seite darstellen. 

Anwendungsschichschicht 

Geschäftsprozeß-Aktionsschicht 

Konzeptionelle Implementationsschicht 

Schicht 

repräsentiert 

im 

Konzept 

Datenteil des 

Lastenheftes 

Workflow Workflow durch 

Produktfunktionalität 

Prozeß Prozeß durch 

repräsentiert 

im 

benutzt in 

Workflow durch 

Geschäftsprozesse 

Prozeß durch 

Arbeitsschritt 

Funktionenteil 

des Pflichtenheftes 

Produktfunktion 

Funktionenteil 

des Lastenheftes 

Szene Szene im Anwendungsgebiet 

Dialogschritt Dialogschritt 

durch Anwendungsschritt 

repräsentiert Diskursteil 

im 

des Lastenheftes 

Schema 

Skizze 

durch 

Datentyp durch 

groben Typ 

Datenteil des 

Pflichtenheftes 

Schema Schema durch 

Konzeptlandkarte 

Datentyp Datentyp durch 

Schema durch konzeptuelles 

Anwendungsschema 

Schema 

Datentyp durch konzeptueller 

Anwendungstyp Datentyp 

Anwendungsschema ER-Schema 

Workflow durch 

Handlungen 

konzeptueller 

Workflow 

Prozeß durch konzeptueller 

Aktion 

Prozeß 

NutzermaschineWorkflow- 

Maschine 

Content- 

Typen 

Content- 

Typen 

logisches Schema 

logischer Datentyp 

logischen 

Schema 

Module 

Programm 

Datenbank- 

Maschine 

Content- 

Typen 

Szene in einer Szene im Plot Szene im Szenenraum 

Szene im 

Story 

des Präsentations- 

Drehbuchs raum 

Dialogschritt Dialogschritt konzeptueller Dialogschritt 

durch Anwendungsereignis 

durch Thema Dialogschritt durch Arbeitso- 

der Anwendung 

berfläche 

Handlungsrahmenteil 

Storyboard Drehbuch Inszenierung 

des 

Pflichtenheftes 

Content- Content- Content- 

Typen Typen Typen 

benutzt direkt 

Sicht Produktdatensicht Skizze der Sicht Skelett der Sicht Schema der 

Sicht 

Typ der Produktdatentyp Typ durch ontologische 

Kerntyp konzeptueller 

Sicht 

Einheit 

Typ 

repräsentiert Sichtenteil Sichtenteil Aktionssichten- Sichtenim 

des Lastenheftetenheftes 

des Pflich- 

Suite Suite 

benutzt in 

Content- Content- 

Typen Typen 

Entwicklungsprodukte auf den entsprechenden Abstraktionsschichten 

Ein Vorgehensmodell. 

Anfragemenge 

der Sicht 

Anfrage des Typen 

logische 

Sichten- 

Suite 

Wir können mit dem Abstraktionsschichtenmodell zur Entwicklung von Informationssystemen eine Reihe verschiedener 

Entwicklungsmodelle unterstützen: 

In der Strukturierungsorientierten Entwicklung wird zuerst die Datenbank-Struktur weitestgehend entwickelt. Dar- 

IS ADD


auf aufbauend werden die Prozesse und die Sichten und abschließend die Präsentationskomponente entworfen 

und implementiert. Diese Vorgehensweise entspricht dem klassischen Entwicklungsansatz, hat aber den Nachteil 

einer hohen Modifikationsrate aller vorher erstellten Dokumente. 

In der prozeßorientierte Entwicklung wird zuerst die Funktionalität der Anwendung entworfen und prototypisch 

realisiert. Danach werden die entsprechenden Datenstrukturen entwickelt und abschließend die Präsentationskomponente 

und die entsprechenden Sichten. Dieser Zugang wird im Software-Engineering präferiert, entspricht 

aber selten den Gegebenheiten der Entwicklung von Informationssystemen. 

Interaktionsraum-determinierte Entwicklung: Es werden zuerst die Stories und Szenarien der Anwendung abgenommen. 

Auf dieser Grundlage werden die entsprechenden Medientypen konzipiert. Damit sind die Anforderungen 

für die Strukturierung und die Funktionalität bekannt, so daß eine Entwicklung dieser Aspekte integriert 

erfolgen kann. Diese Vorgehensweise entspricht der Entwicklungsmethodik von informationsintensiven Websites. 

Sie bedingt jedoch eine weitestgehende Erfassung aller Szenarien der Anwendung. 

Sichtenorientierte Entwicklung: Es wird ein Skelett oder eine Architektur der Anwendung entwickelt. Die einzelnen 

Sichten werden schrittweise und an ihren Schnittstellen integriert entwickelt. Darauf aufbauend können die 

Strukturierung, der Story-Raum und die Funktionalität entwickelt werden. Diese Vorgehensweise eignet sich 

besonders für gut strukturierte Anwendungsgebiete mit separierbaren Datenbeständen. Sie bedingt jedoch eine 

höhere Disziplin und Koordinierung bei der integrierten Entwicklung. 

Schichtenbasierte Entwicklung: Es werden zuerst alle Aspekte auf der Motivationsschicht, danach auf der Geschäftsprozeßschicht, 

dann auf der Aktionsschicht und abschließend die Aspekte auf der konzeptuellen Schicht entwickelt. 

Nach Abschluß des konzeptuellen Entwurfes wird eine Transformation hin zur logischen Spezifikation 

vorgenommen. Dieser Zugang erfordert wenige Korrekturen im Entwicklungsprozeß und erscheint deshalb 

besonders geeignet. Er wird im weiteren präferiert. 

Wir kombinieren diese Vorgehensmodelle zu einem schichtenbasierten Vorgehensmodell. Innerhalb einer Abstraktionsschicht 

determiniert der Interaktionsraum die anderen Aspekte. 

Damit erhalten wir ein Vorgehensmodell, dessen Schrittfolge in Bild 27 dargestellt wird und das als Grundlage 

für die einzelnen Entwicklungsschritte dient. 

Die einzelnen Schritte in Bild 27 sind die folgenden: 

* Motivationsschicht 

1. Entwicklung der Motivation und der Ziele der Anwendung, Informationsanalyse 

2. Entwicklung des Lastenheftes zur Anwendung 

* Geschäftsprozeßschicht 

3. Separation der Systemes in Komponenten und Entwicklung der Architektur des Systemes 

4. Skizzierung des Story-Raumes, Formulierung der Interaktivität für das Pflichtenheft 

5. Skizzierung der Sichten-Suite für die einzelnen Komponenten, der Dienste und des Austauschrahmens, Formulierung 

der Verteilung und Strukturierung für das Pflichtenheft 

6. Spezifikation der Business-Prozesse, Formulierung der Funktionalität für das Pflichtenheft 

* Aktionsschicht 

7. Spezifikation der Szenario der Anwendung 

8. Beschreibung der Haupttypen der einzelnen Sichten und deren Assoziationen 

IS ADD



Motivationsschicht 


(Fkt.) Struktur Verteilung Dialoge Funktionen (Str.) 

1 

2 

3 

5 4 6 

8 7 

(8) 


10 9 

11 

14 

12 

16 13 15 


Schicht 

18 

19 

20 

17 

21 

(22d) 22 

22c 

22d 

23 (23) 

(24d) 24a 24b 24c 24d 

25 25 

(26) 27 (27) 26 (27) 

28a 28b 28c 28d 

Abbildung 27: Schritte in unserem Vorgehensmodell 

IS ADD


9. Entwicklung der Integritätsbedingungen und deren Erzwingungsstrategie 

10. Spezifikation der Benutzeraktionen, Rollen, Skizzierung der Content-Typen 

11. Spezifikation der Qualitätsanforderungen und deren Umsetzung im System, Entwicklung von Sicherungsstrategien 

* Konzeptionelle Schicht 

12. Spezifikation des Story-Raumes 

13. Spezifikation der Akteure, ihrer Portfolio, Rollen, Rechte, Profile 

14. Spezifikation der Sichten-Suite, der Dienste und Austauschrahmen 

15. Entwicklung der Workflows 

16. Kontrolle der Content-Typen anhand von Content-Objekten, Validierung der statischen Semantik, Kontrolle 

der Integritätserzwingung 

17. Spezifikation der Szenen, der Dialogschritte, der Bedingungen für die Stories, der Handlungsübergänge 

18. Spezifikation der Content-Typen-Suite, der notwendigen Funktionalität zu deren Unterstützung 

19. Modulare Verfeinerung der Datentypen 

20. Normalisierung der entwickelten Datentypen 

21. Kontrolle des Story-Raumes anhand der Szenario, Ableitung weiterer möglicher Szenario, Blockierung unerwünschter 

Szenario, Ableitung der Verlinkungs- und Navigationsstruktur, Kontrolle der unterstützten Funktionalität 

22. Spezifikation der Funktionalität, Kontrolle des Verhaltens der Anwendung, Abstimmung der Unterstützung für 

Dienste, Austauschrahmen, Kollaboration 

23. Integration der Sichten-Suite anhand der Architektur des Systemes, Auflösung der Entwurfsobligationen 

* Implementationsschicht 

24. Transformation der konzeptuellen Modelle in logische Modelle zur Darstellung der Strukturierung, Funktionalität, 

Interaktivität und Verteilung 

25. Restrukturierung und Optimierung auf der Grundlage von Performanzbetrachtungen und des Tuning 

26. Ableitung des Dienstverwaltungssystemes, der Protokolle und der Funktionen zur Unterstützung der Verteilung 

27. Transformation der logischen Modelle in physische Modelle des DBMS 

28. Kontrolle der Dauerhaftigkeit und der Skalierbarkeit der Lösung, Entwicklung von Erweiterungs- und Migrationstrategien 

unter Berücksichtigung möglicher Technologieentwicklungen und Veränderungen in der Anwendung 

Das Verfeinerungsmodell der abstrakten Zustandsmaschinen. 

Given two ASM’s M, M ∗ , refinement is based on 

refinement of states 

IS ADD


states of interest S, S ∗ , correspondence between the states of interest 

abstract computation segments τ 1 , ...., τ m on M and σ 1 , ...., σ n on M ∗ 

(m,n)-refinement 

locations of interest 

equivalence relation ≡ on locations of interest 

M ∗ is a correct refinement of M if 

there for each M ∗ -run S ∗ 0 , ...., S∗ k , ... there is an M-run and sequences i 0 and j 0 < j 1 < ... such that 

i 0 = j 0 = 0 S ik ≡ S ∗ j k 

for each k and either 

• both runs terminate and their final states are the last pair of equivalent states, or 

• both runs and both sequences are infinite. 

Complete refinement: M correct refinement of M ∗ and M ∗ correct refinement of M 

Abgeleitete Schichten der Verfeinerung. 

siehe oben 

Abstraktionsschichten. 

Modellannahmen je nach Abstraktionsschicht (Identifizierung, Makro- versus Mikrodaten, Striktheit) 

(Wiederholung) Modellierung ist ein iterativer Prozeß, d.h. die Entwicklung eines konzeptuellen Schemas erfolgt in 

iterativen Verfeinerungs- und Restrukturierungsschritten 

dies gilt auch dann, wenn das konzeptuelle Schema durch die Abbildung eines konzeptuellen Vorentwurfsschemas 

entstanden ist 

Anhaltspunkte (Faustregeln) für diese Schritte erforderlich, um Konsistenz zu erhalten 

Transformationsregeln 

Unterschiedliche Strategien (Literatur) [im weiteren eigene Strategie] 

Top-Down-Regeln (Verfeinerung) 

• T1: class ↣ associated classes 

• T2: class ↣ generalization 

• T3: class ↣ aggregation 

• T4: class ↣ unrelated classes 

• T5: association ↣ parallel associations 

• T6: association ↣ class with associations 

• T7: attribute development (auch für Assoziationen) 

• T8: attribute refinement (auch für Assoziationen) 

Anm.: Nicht alle möglichen Schemata können ausgehend von einer Klasse mit den Regeln T1-T8 erzeugt 

werden 

Bottom-Up-Regeln (Einführung neuer Konzepte, die im ursprünglichen Entwurf nicht enthalten waren) 

IS ADD


• B1: class generation 

• B2: association generation 

• B3: generalization generation 

• B4: aggregation generation 

• B5: attribute aggregation 

• B6: composite value aggregation 

Top-Down-Strategie 

Bottom-Up-Strategie 

- beginne mit einer Klasse - beginne mit Attributen 

- wende nur top-Down Regeln an - wende nur Bottom-Up Regeln an 

- schrittweise Verfeinerung n - häufige Restrukturierungen erforderlich 

- keine unerwünschten Seiteneffekte - leichter Start 

- erfordert hohe Abstraktionsfähigkeit bereits zu Beginn - leichte lokale Entwurfsentscheidungen 

Inside-Out Strategie 

• Spezialfall der Bottom-Up Strategie 

• beginnt mit den wichtigsten oder evidentesten Konzepten 

• breitet sich von dort aus (‘Ölfleck’) 

• Konzepte, die ’ 

nahe’ zu bereits modellierten sind, können leicht erkannt werden 

• leicht am Start 

• eine globale Sicht entsteht erst am Ende 

Gemischte Strategie (‘divide and conquer’) 

• Top-Down Verfeinerung der Bestandteile eines Schemaskeletts (‘skeleton schema’) 

• Bottom-up Zusammenfassung (‘Integration’) auf Basis des Schemaskeletts Schemaskelett hat zentrale 

Bedeutung, d.h. über die Grobstruktur des Gesamtschemas wird bereits zu Beginn des Entwurfsprozesses 

entschieden (Bestimmung der zentralen Klassen (Chen: ‘key entity sets’) 

IS ADD


1.8.3 Modellierung der Verteilung 

Ein Aspekt, der nicht vernachlässigt werden kann, bislang aber nur auf strukturellem Niveau behandelt wurde, ist die 

Verteilung. Es sind dazu eine Reihe von Ansätzen bekannt: 

Dienste in verteilten Systemen überwinden die räumliche Trennung von Systemen durch eine Funktionalität zur 

Datenübertragung und eine zeitliche (gemeinsame) Taktung der Datenspeicherung. Es können in diesem Zusammenhang 

Dienstgeber und Dienstnehmer unterschieden werden. Der Austausch wird durch durch eine 

entsprechende Dienstgeber-Dienstnehmer-Architektur unterstützt. Meist basiert diese Architektur auf einer 

Trennung der Datenverwaltung und des Datenaustausches bzw. der Datenübertragung. Dienste werden charakterisiert 

durch 

eine Dienstleistungsvereinbarung als verbindliche Regelung des Dienstverhältnisses, 

eine Sammlung von Funktionen, die zur Erfüllung des Dienstes abgerufen werden können, und 

Dienstmerkmalen zur Darstellung der Qualitätsparameter. 

Die Funktionalität des Dienstes und die Dienstmerkmale werden oft als Diensteigenschaften zusammengefaßt. 

Verteilte Datenbanksysteme setzen auf Datenbanksystemen auf, erlauben eine Verteilung der Daten durch Partitionierung 

der Daten, Allokation der Partitionen zu Knoten und eine verteilte Bearbeitung von Daten auf der 

Grundlage von erweiterten Protokollen für den Abschluß von Transaktionen. 

Eine klassische Darstellung der Verteilung wird oft anhand von drei Modellen dargestellt: 

Das Kollaborationsmodell oder Interaktionsmodell dient der Spezifikation der kommunizierenden Prozesse, ihrer 

Kommunikation und ihrer Koordination. Es wird meist ein Zeitmodell unterlegt, das auch erlaubt, die Verzögerung 

der Kollaboration darzustellen. 

Das Fehlermodell definiert und klassifiziert die auftretenden Fehler, die Behebungsmöglichkeiten und die Ausführung 

der Kompensation. 

Das Sicherheitsmodell klassifiziert und definiert die Form, mit der Angriffen und Systemgefährdungen begegnet 

werden kann. 

Die Kollaboration führt oft zu einer Einschränkung der Leistung von Systemen. Außerdem kann relativ selten ein globales 

Zeitkonzept realisiert werden. Deshalb unterscheiden wir auch verteilte Systeme in asynchrone und synchrone 

Systeme. Die Kollaboration kann oft durch Interaktionsdiagramme, die die Abfolge der Kollaborationsereignisse 

darstellen, unterstützt werden. Typische Modelle zur Darstellung sind dann Weg-Zeit-Diagramme. 

Im Datenbank- und Informationssystementwurf ist jedoch eine größere Vielfalt von Anwendungen darzustellen. 

So sind z.B. e-Business-Anwendungen mit den Methoden der OSI-Schichtung, mit einfachen Diensten und auf 

der Grundlage von einfachen Austauschprotokollen nur partiell darstellbar. Deshalb wird versucht, über mehrdimensionale 

Strukturierung, wie z.B. in [ALSS03], mit den Dimensionen Datenübertragungssystem und Datenverwaltungssystem 

und den klassischen Schichten des OSI-Modelles (Bitübertragung, Sicherung, Netz und Vermittlung, 

Transport, Anwendung wie z.B. Middleware) und des verallgemeinerten 5-Schichten-ANSI-Modelles (extern, intern, 

physisch, Segment, Datei) mit Erweiterungen zu einer dritten Dimension, die durch HW-SW-Systeme determiniert 

wird, sich eine Übersicht zu verschaffen. Anwendungssysteme wie Middleware-Systeme unterstützen die Kopplung 

von Informationssystemen. Middleware kann bei der Überwindung der Heterogenietät durch entsprechende Transformationsmechanismen 

zur Typkonversion und Aufrufumformung unterstützen. Diese Umformungen können auf 

der Grundlage von Regeln vorgenommen werden. Stummel-Objekte werden dienstnehmerseitig erzeugt und Gerüst- 

Objekte werden dienstgeberseitig bereitgestellt. Es wird ein Funktionsaufruf wie in Bild 28 realisiert. 

Die Vermittlung von Dienstgebern basiert auf einem Vermittlungsdienst, einem Namendienst mit einem Namensraum 

und einer entsprechenden Navigationsunterstützung. Innerhalb des verteilten Systemes werden Dienste aktiviert


Dienstnehmer 

Dienstgeber 

Dienstnehmercode Stummel Gerüst Dienstgebercode 

✕ 

Verpacken 

Parameter 

✲ 

Senden 

✲ 

Empfangen ✲ 

Auspacken✲ 

Parameter 

Funktionseintritt 

Funktionsaufruf 

❑ 

Auspacken 

Ergebnis ✛ 

(Warten) 

❄ 

Empfangen 

✛ 

Senden 

✛ 

Verpacken 

Ergebnis 

✛ 

Funktionsende 

❄ 

Abbildung 28: Entfernter Funktionsaufruf mit einer Schichtung [ALSS03] 

und beendet, Lasten verteilt, die Sicherheit und die Persistenz garantiert und eine verteilte Transaktionsverwaltung mit 

einem Ressourcen-Verwalter, einem Synchronisationsdienst und einem Transaktionsverwalter unterstützt. Typische 

Architekturen für Middleware-Systeme sind CORBA und Web-Dienste. 

Wir sind jedoch mehr an einer konzeptionellen Modellierung der Verteilung interessiert. Eine CORBA- oder Web- 

Dienste-Spezifikation ist eine physische oder logische Umsetzung. Deshalb verwenden wir das Diensteverwaltungssystem 

mit den entsprechenden Schnittstellen und Protokollen auf dem Implementationsniveau. Zur Spezifikation der 

Verteilung abstrahieren und verallgemeinern die Ansätze zur Verteilung: 

Die Verteilung ist gegeben durch eine Spezifikation der Dienste des Kollaborationsrahmens und der Architektur. 

Dienste setzen auf Sichten-Suiten auf. Der Kollaborationsrahmen faßt die Kommunikation, die Koordination 

und die Kooperation zusammen. Die Architektur stellt den Zusammenhang der Komponenten dar. 

Dienste S = (I, F, Σ S ) sind gegeben durch die Informationseinheiten, durch das Dienstverhalten, und durch 

den Dienstvertrag, insbesondere die Qualitätsparameter. 

Informationseinheiten I = (V, M, Σ T ) bestehen aus Content-Typen der Sichten-Suite, einem Informationseinheit 

Manager und einer Menge von Regeln zur Darstellung der Kompetenz. 

Das Dienstverhalten wird 

• innerhalb der Aktionsschicht durch Vereinbarungen zur Dienstgüte, 

• innerhalb der konzeptuellen Schicht durch konzeptuelle Eigenschaften und 

• innerhalb der Implementationsschicht durch Dienstgüteeigenschaften der Implementation 

angegeben. 

Der Dienstvertrag legt die Rahmenbedingungen des Dienstes fest. 

Das Vertragsschema stellt die Bedingungen des Vertrages dar. Insbesondere werden Parameter wie 

• das Benutzungsmodell (mit den Akteuren, ihren Beziehungen, Rollen und Rechten), 

• das Zeitmodell, 

• der Vertragskontext und 

• die vertraglich vereinbarte Qualität 

spezifiziert. 

Qualitätsparameter der Dienste sind je nach Abstraktionsniveau 

• innerhalb der Aktionsschicht Eigenschaften wie Allgegenwart (ubiquity) und Sicherheit, 

• innerhalb der konzeptuellen Schicht Eigenschaften wie Bedeutungstreue und Konsistenz und 

• innerhalb der Implementationsschicht Eigenschaften wie Dauerhaftigkeit, Performanz, Robustheit 

und Skalierbarkeit.


Der Kollaborationsrahmen ist durch die Darstellung der verschiedenen Facetten der Kollaboration spezifiziert: 

Der Kommunikationsrahmen legt die Art der Kommunikation und die benutzten Austauschmechanismen 

fest. 

Der Kooperationsrahmen bestimmt die Art des Zusammenwirkens der unterschiedlichen Akteure und Komponenten 

im Rahmen des Portfolios bzw. der Arbeitsprozesse. 

Der Koordinationsrahmen bestimmt die Synchronisation der Kollaboration, die Organisation und die Aufgabenverteilung. 

Die Facetten der Kollaboration werden durch jeweils drei Teilspezifikationen angegeben: 

Der Diskurs bestimmt den Ablauf der Kollaboration. Er basiert auf den anderen drei Bestandteilen des Co- 

Design-Ansatzes: 

Die Daten werden zu Content verdichtet und durch Sichten über dem Datenbanksystem angegeben. 

Die Funktionalität wird durch Angabe der unterstützenden Systemfunktionen dargestellt. 

Die Interaktivität basiert auf dem Storyboard der Anwendung. 

Der Stil der Kollaboration legt die vertraglichen Vereinbarungen fest. Er wird durch 

• die Unterstützungsprogramme wie Sitzungsverwaltung, Benutzerverwaltung und der Abrechnung, 

• den Datenzugriffsrahmen mit den Varianten zwischen broadcast und peer-to-peer, dem gemeinsamen 

Benutzen von Ressourcen und den Zugriffsformen und 

• die Art wie peer-to-peer- oder der Ereignis- oder der Komponentenkollaboration sowie 

• den Koordinations-Workflow mit den Partnerbeziehungen, dem Diskurstyp, dem Namensraum und 

den Workflow-Regeln 

determiniert. 

Die Kollaborationsarchitektur bzw. das Kollaborationsmuster verbinden die Komponenten. Das Kollaborationsmuster 

ist eine Verallgemeinerung der Protokolle mit einer Darstellung der Partner, ihrer Aufgaben, 

ihrer Rollen und Rechte. Wir unterschieden zwischen 

• Proxy-Kollaboration, 

• Broker- bzw. Trader-Customer-Kollaboration, 

• Client-Dispatcher-Kollaboration, 

• Publisher-Subscriber-Kollaboration und 

• Model-View-Controller-Kollaboration. 

Die Architektur kann als Verallgemeinerung der Architektur verteilter Datenbanksysteme angesehen werden. Architekturen 

föderierter Systeme, von Datenbank-Farmen und inkrementellen Datenbanksystem-Suiten basieren 

auf einer Trennung in lokale und globale Komponenten und auf der expliziten Spezifikation der Austauschbeziehungen 

zumindest für die Strukturierung von Objekt-Suiten, mitunter auch die Funktionalität von Objekt- 

Suiten. 

Architekturen können durch entsprechende Austauscharbeitsplätze unterstützt werden. 

Unsere konzeptuelle Darstellung kann auf die logische und physische Ebene abgebildet werden durch: 

Abbildungsregeln zur Transformation von Sichten, 

Abbildungsregeln zur Erzeugung der Architektur, 

Abbildungsregeln zur Erzeugung des Kollaborationsmodelles, 

Abbildungsregeln zur Erzeugung des Fehlermodelles und 

Abbildungsregeln zur Erzeugung des Sicherheitsmodelles.


1.8.4 Auswahl der Ausrichtung auf bestimmte Aspekte 

Preprint S. 39o-39m 

1.8.5 Abstraktionsschichtung zur integrierten und abgestuften Entwicklung 

KADS-Methode bzw. andere klassischen Zugänge. 

Machbarkeitsstudie 

Kickoff 

Verfeinerung 

Evaluierung 

Erweiterung nd Anpassung 

Die Abstraktionschichtung dieser Vorlesung. 

Preprint S. 34 - 36 

1.8.6 Resultate der Entwicklung auf unterschiedlichem Abstraktionsniveau 

Preprint S. 36-37 

1.8.7 Resultate der Entwicklung auf unterschiedlichem Abstraktionsniveau 

Preprint S. 39 

Pragmatik der Modellauswahl. 

Typenwahl 

IC-Auswahl 

Erzwingung 

Pragmatik der Abbildung. 

Pragmatik der Modellierung. 

Theorie der Trennlinie, Typengrat (stripline; dividing wall/rule; separator type; ridge). 

1.8.8 Methodik 

Guide for application of methods


1.8.9 Architektur von Informationssystem-Anwendungen 

am Beispiel von data-warehouse-Anwendungen 

OLTP Schemata. 

wie bereits besprochen 

Classes of Aggregation Functions. 

• The simplest class of aggregation functions turn data into information by (one-pass) aggregation. One typical 

example is the statistical summary from that data. Into this class fall the following functions: count (tally), 

average (arithmetic mean), sum (total), min, max. 

• More complex aggregation functions are used in cumulative or running statistics which relate data values to the 

whole data, e.g., changes in an aggregate value over time or any dimension set (banded reports, control break 

reports, OLAP dimensions). Typical examples the queries: 

“What percentage each customer contributes to total sales?” 

“Total sales in each territory, ordered from high to low!” 

“Total amount of sales broken down by salesman within territories”. 

These functions are often weak descriptive statistics since minor database changes result in major reflection 

within the aggregation. 

In [LT01] we distinguished between distributive, algebraic and holistic aggregation functions: 

Distributive or inductive functions are defined based on structural recursion. Given a types T , T ′ and a collection 

type C T on T and operations such as generalized union ∪ C T , generalized intersection ∩ C T , and generalized 

empty elements ∅ C T on C T and given further an element h 0 on T ′ and two functions defined on the types 

h 1 : T → T ′ and 

h 2 : T ′ × T ′ → T ′ , 

then we define the structural recursion by union presentation for R C on T as follows 

srec h0 ,h 1 ,h 2 

(∅ C T ) = h 0 

srec h0 ,h 1 ,h 2 

(|{|s|}|) = h 1 (s) for singleton 

collections |{|s|}| 

srec h0 ,h 1 ,h 2 

(R1 C ∪ C T RC 2 ) = 

h 2 (srec h0 ,h 1 ,h 2 

(R1 C), srec h 0 ,h 1 ,h 2 

(R2 C)) 

iff R1 C ∩ C T RC 2 = ∅ C T . 

Distributive functions preserve partitions of sets, i.e. given a set X and a partition X = X 1 ∪ X 2 ∪ ... ∪ X n of 

X into pairwise disjoint subsets. Then for a distributive function f there exist a function g such that f(X) = 

g(f(X 1 ), ..., f(X n )). Functions such as count, sum, min, max are distributive. 

Algebraic functions can be expressed by finite algebraic expressions defined over distributive functions. Typical 

examples of algebraic functions in database languages are average and covariance. The average function 

for instance can be defined on the basis of an expression on count and sum. 

Holistic functions are all other functions. For holistic functions there is no bound on the size of the storage needed 

to describe a sub-aggregate. Typical examples are mostFrequent, rank and median . Usually, their 

implementation and expression in database languages require tricky programming. 

Holistic functions are computable over temporal views. We will not discuss in detail these functions within this 

paper.


OLTP-OLAP Transformations. 

OLTP-OLAP transformations are based on transforming functions 

• grouping G, 

• aggregation F, and 

• linear transformations and nonlinear transformations such as the conversion of fuel consumption 

miles 

gallon . 

l 

100km 

Since we require for application frameworks that properties must be provable we need a formal framework for OLTP- 

OLAP transformations too. This framework is based on the theory of aggregation functions introduced next. 

Aggregation functions are very powerful. SQL-92 is not first-order [Lib01] due to the existence of these functions. 

The higher expressive power is based on aggregation functions, on grouping and on arithmetical functions 

that can be applied to numerical values. In general, an aggregation function is definable as a specific family 

F = {f 0 , ...., f k , ..., f ω } with functions f k : Bag k → Num that map bags with k elements to a numerical value. 

Definition 1 [CMM02] The family of functions 

(f k : Bag k → Num|k ∈ N 0 ) 

for bags on dom(M j ) is called aggregation function on M j if 

• the equalities f k (min, ...., min) = min and 

f k (max, ..., max) = max are valid for the minimal and maximal elements in dom(M j ) and 

• they are monotone according to the order of dom(M j ). 

Additionally, aggregation functions 

F = {f 0 , ...., f k , ..., f ω } 

may have the following properties: 

Idempotent: f k (x, ...., x) = x for all x ∈ dom(M j ), 

Continuous: lim xi →x f(x i ) = f(x) for all sequences x i of size k, 

Lipschitz property: |f k (x 1 , ..., x k ) − f k (y 1 , ..., y k )| 

≤ c ∑ n 

i=1 |x i − y j | for some constant c, 

Symmetric: f k (x 1 , ..., x k ) = f k (x ρ(1) , ..., x ρ(k) ) for any k-permutation ρ, 

Self-identical: f k (x 1 , ..., x k ) = 

f k+1 (x 1 , ..., x k , f k (x 1 , ..., x k )), 

Shift-invariant: f k (x 1 + b, ..., x k + b) = 

f k (x 1 , ..., x k ) + b, 

Homogeneous: f k (bx 1 , ..., bx k ) = bf k (x 1 , ..., x k ), 

Additive: f k (x 1 + y 1 , ..., x k + y k ) = 

f k (x 1 , ..., x k ) + f k (y 1 , ..., y k ), 

Associative: f r (f k1 (x 1 ), ..., f kr (x r )) = 

f k1 +...+k r 

(x 1 , ..., x r ). 

Proposition 1 The aggregation functions of the first-order query algebra have the following properties: 

↦→


max, min are idempotent, continuous, symmetric, self-identical, additive, homogeneous, and associative and obey 

the Lipschitz property, 

sum is continuous, symmetric, homogeneous, additive, associative, obeys the Lipschitz property, and is not idempotent, 

not self-identical, not shift-invariant, 

avg is idempotent, continuous, symmetric, shift-invariant, homogeneous, additive, obeys the Lipschitz property, is 

not self-identical, not associative, 

count is continuous, symmetric, associative, obeys the Lipschitz property, not idempotent, not self-identical, not 

shift-invariant, not homogeneous, not additive. 

The proof of the proposition is straight-forward and thus omitted. 

Depending on these properties, the behavior of aggregation functions varies. For instance, if the aggregation 

function is not associative then roll-up may falsify the result. 

The existence or the non-existence of null values in 

dom(M j ) is not only a design issue but heavily influences the behavior of aggregation functions. For instance, as 

noted in [LT01] the min and max functions will not remain to be idempotent, the average function can be defined in 

at least nine different ways. 

The OLAP Cube. 

The data cube [GCB + 97] also know as the multidimensional database in OLAP systems is based on attributes 

that are categorized into dimension attributes and measure attributes. The measure attributes of those records with the 

same functional attributes are combined (mainly summed up) into an aggregate value. The intuition behind the cube 

is intriguing. Since it seems so simple to combine values the cube operator is applied whenever a summary is needed. 

But intuition may fail or may be misled. [VS00] introduces a general theory of the cube. We extend and simplify this 

definition. 

Definition 2 A dimension D is given 

• by a lattice L D = ({L 1 , ..., L nD }, ≼) of domain data types (dom(L i ), op(L i ), pred(L i )) with a partial order, 

• by a family F D of composite, equivalence-invariant and monotone functions anc L i,L j 

such that for each pair 

L i ≼ L j the function anc L i,L j 

maps each element of the domain dom(L i ) to an element of dom(L j ). 

The type L 1 is called the root type of the dimension. The family F D is associated to the family R D of relationships 

desc L i,L j 

inverse to anc L i,L j 

. Instead of using a family of functions we may use a family of values associations A D 

of relations ass L i,L j 

that associate elements of the domain dom(L i ) to elements of dom(L j ) for each pair L i ≼ L j . 

The types NONE and ALL are consisting of all possible elements or of none and may thus be added to any dimension 

hierarchy. Dimensions may by composed of n dimensions by cartesian product of each of their types of the 

lattice. 

A typical example of a dimension may be the time dimension with the types Seconds, Minutes, Hours, Days, 

Weeks, Months, Year and the linear partial orders Seconds ≼ Minutes ≼ Hours ≼ Days ≼ Months ≼ Years, Days ≼ 

Weeks, Weeks ⋠ Months, Weeks ⋠ Years, where the function anc Minutes,Hours maps minutes (e.g. 10:02 am) to the 

hour they are embedded (e.g. 11 am). We may add also FiscalDays, WorkingDays etc. 

Definition 3 A cube is given by 

• a family D of dimensions D i = (L D i 

, F D i 

) (1 ≤ i ≤ m) with a partial association among dimensions, 

• a cube scope (p 1 , ...., p m ) with 1 ≤ p i ≤ n Di , and 

• a set of aggregation functions agg 1 (M 1,1 ), ..., 

agg 1 (M 1,p 1 

), agg 2 (M 1,1 ), ..., agg k (M k,p k) 

which form the fact types.


The cube may be canonically based on the root types of the dimensions. The associations among dimensions may lead 

to a snowflake structure of the cube. In the usual case, however, the cube is computed by one aggregation function, 

e.g. count while grouping objects based on desc L i,L j 

and applying the aggregation function to groups. 

[LS97] have shown that summarizability is depends on three properties: 

Disjointness: The objects can be distinguished at any level of summarization. 

Completeness: None of the objects is lost during summarization at some level. 

Atomicity and Timelessness: The attributes values are atomar and discrete. They are not used for storing complex 

values like comparison or scaled values or flow values. 

The first two properties lead directly to a restriction of the lattice association functions. 

Theorem 1 Disjointness and completeness can be guaranteed within a cube iff the values associations A D are total 

functions. 

This theorem forces us to consider dimensions for which each value of a more detailed type is associated to one and 

only one value. Monotonicity and compositionality is required if we consider aggregation functions. 

The cube algebra consists of 

• navigation functions on the basis of compositions of the anc L i,L j 

functions for associated types, 

• selection functions which is the equivalent of relational selection and 

• projection functions on fact types. 

This definition demonstrates the complexity of the data cube. In the sequel we show that cube operations must be 

applied and used with care and with full understanding of the properties of the data taken from the application domain. 

OLAP Query Operations. 

The data cube is mainly queried by selection and navigation. Selection is based on a criterion that is evaluated 

against data or levels of dimension in order to restrict the set of retrieved data. Possible navigation operations which 

can be applied to a cube are roll-up (aggregation of data from a lower level to a higher level of granularity within a 

dimensions hierarchy), drill-down (the inverse to roll-up) and slice (by grouping of data with respect to a subset of 

dimensions of a cube). 

More formally, the following basic OLAP query functions are introduced for a cube C = {(l 1 , ..., l m , m 1 , ..., m k )} 

defined on the cube schema (L 1 , ..., L m , M 1 , ..., M k ) , the lattice ({L 1 , ..., L n , ALL}, ≼) of dimensions, and the set 

of aggregation functions 

agg 1 (M 1,1 ), ..., agg 1 (M 1,p 1 

), ..., agg k (M k,p k): 

Basic drill-down functions are used for decomposing groups of data along a hierarchy. They refine grouping for 

one dimension L i ≼ L ′ i . The values for the fact values on M 1, ..., M k are obtained through anc L i,L ′ i by decomposition. 

We obtain the cube 

C ′ = {(l 1 ′ , ..., l′ m, m ′ 1 , ..., m′ k )} 

∑ 

that is bound to C by the condition m j = 

(l i ,l i ′)∈ancL i ,L′ i,(l 1 ,...,l ′ i,...,l m, ,...,m ′′ m′′ 

j , ,..., )∈C′ j . 

We observe that the corresponding aggregation functions must be additive along L i ≼ L ′ i . 

Basic dice functions are similar to projection in the first-order query algebra. Given a dimension L i ≼ ALL. The 

projection C ′ = π L1 ,...,L i−1 ,L i+1 ,...,L n 

(C) computes the cube C ′ with objects 

(l 1 , ..., l i−1 , l i+1 , ..., l m , m ′ 1 , ..., m′ k , ) ∈ C′ such that 

m ′ j = ∑ (l 1 ,...,l m,m 1 ,...,m k )∈C m j 

for all j(1 ≤ j ≤ k). 

We observe that the corresponding aggregation functions must be additive along L i ≼ L ′ i .


Basic slice functions similar to selection of tuples within a set. Given a dimension L i and a set D of values d with 

the granularity of L i , i.e. such values d for which desc ALL,L i 

is defined. The cube δ Li ∈D(C) consists of those 

objects (l 1 , ..., l m , m 1 , ..., m k ) ∈ C for which l i ∈ D. 

These operations may be combined using superposition of functions in the classical way. We, thus, obtain drill-down 

functions by superposing drill-down functions. 

Generalizing the first-order query algebra, [Tha00a] defines additional OLAP operations such as 

join functions supporting combination of cube, 

union functions for union of two or more cube of the same type, 

rotate functions functions for rearrangement of the order of dimensions of cube, and 

rename functions functions for renaming of dimensions. 

We observe: 

Proposition 2 The slice, drill-down, dice, union, rotate, and rename functions form a relationally complete query 

algebra of OLAP operations. 

The proof is based on the relational completeness of the corresponding operations of the first-order query algebra.


1.9 Architektur von Informationssystemen 

1.9.1 Definition of Architecture 

• Architecture in civil engineering: discipline dealing with the principles of design and construction and ornamentation 

of fine buildings; “architecture and eloquence are mixed arts whose end is sometimes beauty and 

sometimes use” 

• art and science of designing buildings and other physical structures 

• Bass, Clements, and Kazman. Software Architecture in Practice 2nd ed, Addison-Wesley 2003: 

The software architecture of a program or computing system is the structure or structures of the system, which 

comprise software elements, the externally visible properties of those elements, and the relationships among 

them. 

• UML 1.3: 

Architecture is the organizational structure of a system. An architecture can be recursively decomposed into 

parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts 

that interact through interfaces include classes, components and subsystems. 

• Bass, Clements, and Kazman. Software Architecture in Practice, Addison-Wesley 1997: 

The software architecture of a program or computing system is the structure or structures of the system, which 

comprise software components, the externally visible properties of those components, and the relationships 

among them. 

By “externally visible” properties, we are referring to those assumptions other components can make of a 

component, such as its provided services, performance characteristics, fault handling, shared resource usage, 

and so on. The intent of this definition is that a software architecture must abstract away some information from 

the system (otherwise there is no point looking at the architecture, we are simply viewing the entire system) 

and yet provide enough information to be a basis for analysis, decision making, and hence risk reduction.” 

• Garlan and Perry, guest editorial to the IEEE Transactions on Software Engineering, April 1995: 

Software architecture is “the structure of the components of a program/system, their interrelationships, and 

principles and guidelines governing their design and evolution over time.” 

• IEEE Std. 610.12-1990: 

Architecture is the organizational structure of a system. 

• software architecture workshops: 

Software architecture is: 

an overall view of the solution to a problem 

the high-level design of modular components and how they interact 

a foundation that one can build on to solve a problem (e.g., rules, policies, attributes, etc.) 

an efficient method to meet a fixed set of well-defined attributes 

• Phaniraj Adabala (Systems Manager, Prasad Film Laboratories, Chennai, TN, India): Software Architecture is 

defined as a style that is proven scientifically and adopted by the engineering discipline, with which a software 

is developed so as to sustain and adopt to the growing needs of the industry from time to time. 

• Ozten Chelai (University lecturer, Ovidius University of Constantza, Constanta, Romania): A system architecture 

represents the conceptual model of a system. A conceptual model is the map of concepts, relationships and 

constraints. 

IS ADD


• Ebenezer Adegbile (Consultant, Self Employed, London, England): Software Architecture can be defined as 

language-independent representation of a given software system. It represents the skeleton of a software system, 

emphasizing a clear definition of the structure, communication and interrelationship of the body of the 

components that fulfills the purpose of a given software system. The components of the architecture should 

expose the protocol of the components only to its clients. Software architecture should implement a clear separation 

of concerns in all the core observable and non-observable behaviour of a software system. 

• Vijaya Agarwal (Associate Consultant, ICFAI, Hyderabad, India): Software architecture is aligning the software 

components with proper collaboration and integration to sustain in the changing business environment by 

utilizing and abstracting the involver at maximum. 

• Wahab Ahmed (Software Engineer, National, Islamabad, Federal, Pakistan): Software architecture is a coherent 

set of abstract patterns, or principles, guiding the design of each aspect of a large software system. Software architecture 

is a sketchy map of the system. Software architecture describes the coarse grain components (usually 

describes the computation) of the system. The connectors between these components describe the communication, 

which are explicit and pictured in a relatively detailed way. In the implementation phase, the coarse 

components are refined into “actual components”, e.g., classes and objects. In the object-oriented field, the 

connectors are usually implemented as interfaces. 

• Charlie Alfred (Technical Director, Foliage Software Systems, Inc., Burlington MA USA): Software architecture 

consists of the rules and principles for how a system is decomposed into its component parts, the rationale 

for how responsibilities are allocated among those parts, and the policies and mechanisms that coordinate the 

interactions between those parts as they collaborate to fulfill the purpose of the system. Software architecture is 

at once the partitioning of a system into its significant elements, and the organization and integration of those 

elements into a cohesive whole. 

• Christophe Alviset (Applications and Projects Department Head, INSEE, Paris, France): A systems architecture 

is the set of components, their attributes and the ways of using them that are necessary to build a system or a 

set of systems. It depends on the set of people working to build the systems, their skills and the current state of 

the art. It helps them to agree on their respective roles. It aims to achieve some desirable functionalities in the 

systems that are built, such as evolutivity, robustnesss, redundancy, and so forth. 

• Wouter Beneke (Paradigm Systems Technology): The architecture of a system is an abstraction of the system 

giving the semantics and specification for the patterns of information content and context. 

• Wallace Byczek (Director of Development/Integration, U. Mass. Medical Center): Software architecture is the 

blueprinted or mapped definition of the component relationships formed by the domain architectural models, 

business related functions, application structure, and architecture inclusive of information architecture and its 

supporting infrastructure: tools, best practices, methods. In its modeled form it also establishes the dependencies 

between components – in short, it is a model of the “ultrastructure” of systems. 

• Ramayya Darbhamulla (Software Engineering Manager, Boeing Australia Limited, Brisbane QLD Australia): 

Software Architecture is a subset of the overall system architecture and it defines the contribution of software to 

the overall functionality of the system, by defining the location, distribution and the interaction of the software 

components. System architecture on the other hand defines the physical, logical and information elements of 

the system which come together to realise a required set of functionality. 

• Kameshwar Eranki (Senior Product Manager, PeopleSoft Inc., Pleasanton, CA, USA): Software Architecture 

defines the fundamental elements, components and the framework in which the elements/components work and 

how they interact with each other to deliver the desired business expectations, meeting the cost performance 

criteria and defined constraints, and taking into account the requirements of scalability, reliability, usability, 

and maintainability factors. 

IS ADD


• Philippe Kruchten (Director of Process Development, Rational Software Corporation, Vancouver, B.C.): Software 

Architecture encompasses the significant decisions about 

* the organization of a software system, 

* the selection of the structural elements and their interfaces by which the system is composed together with - 

their behavior as specified in the collaboration among those elements, 

* the composition of these elements into progressively larger subsystems, 

* the architectural style that guides this organization, these elements and their interfaces, their collaborations, 

and their composition. 

Software architecture is not only concerned with structure and behavior, but also with usage, functionality, 

performance, resilience, reuse, comprehensibility, economic and technological constraints and tradeoffs, and 

aesthetics. 

1.9.2 Paradigms of Programming in the Large 

Architecture with a variety of viewpoints (application architecture, technical (component/module) architecture, infrastructure 

architecture) 

Component construction via components, interfaces, connectors 

Development methodology for teamwork, team chairing, chair, roles, responsibilities, obligations 

Integration/Collaboration of components, also dynamic 

Distributed and embedded systems via networks 

Testing, verification, validation for control and coherence/consistency check 

Open source development under guru supervision 

Pattern-based refinement 

Mit dem integrierten Entwurf dieses Buches kann die Entwicklung “im Kleinen” sehr gut für alle Aspekte von 

Informationssystemen gemeistert werden. Wir können sogar die Entwicklung “im Großen” gut unterstützen. Dies 

gründet sich auf eine Reihe von Vorteilen, die unser Zugang bietet: 

Architektur von Systemen: Es wird eine allgemeine Architektur von Informationssystemen unter gleichberechtigter 

Berücksichtigung von Strukturierung, Funktionalität, Interaktivität und Verteilung ermöglicht. 

Einbettung in die Infrastruktur: Unser Zugang erlaubt Informationssysteme als eingebettete Komponente mit Einspielund 

Ausspielsystemen im Sinne der Data-Warehouse-Architektur wie in Kapitel ?? zu betrachten. 

Integration versus Kooperation: Da eine vollständige Integration weder möglich noch gewünscht ist für viele Anwendungen 

werden mit diesem Zugang die Kooperationsbeziehungen explizit dargestellt. Damit eignet sich 

auch Skriptprogrammierung für die Unterstützung der Kooperationsbeziehungen. 

Informationseinheiten und Container: Dem Akteur werden die Informationen in der erforderlichen Granularität 

bereitgestellt ohne ihn zu überfluten mit Daten. 

IS-Farmen: Integrierte, verteilte Informationssysteme sind selten möglich. Stattdessen präferieren wir Farmen von 

Informationssystemen als Mehr-Datenbanksysteme mit Austauschprotokollen, Be- und Entladung von Containern. 

Globale versus lokale Funktionalität: Jede lokale Anwendung verfügt über eine eigenständige Funktionalität und 

wird durch expliziten Anschluß mit ‘Fern’anwendungen integriert. 

IS ADD


Kontrollierte Redundanz und Replikation: Redundanz kann zugelassen werden, damit Datenbestände eine höhere 

Verfügbarkeit besitzen. 

Kontrollierte Inkonsistenz: Da eine vollständige Konsistenz aller Komponenten nicht erforderlich ist, können ‘Alt’anwendun 

und z.T. unzuverlässige Kommunikation mit Mechanismen des Aufladens unterstützt werden. 

Eine etwas überraschene Entdeckung können wir mit den Diskussionen in [Jac07] machen. Dort wird lang und 

breit erläutert, wie man eine Straßenkreuzung doch nicht vollständig modellieren kann. Das Erstaunliche daran ist 

allerdings, daß einfach die falsche Granularität für das Modell gewählt wurde. Es wird dort statt einer Modellierung 

im Globalen eine Modellierung im Lokalen genutzt. Damit versucht der Autor leider, eine Kreuzung vom Verhalten 

der einzelnen Bestandteile zu erklären, was aufgrund der vielen Nebenbedingungen eine Spaghetti-Modellierung 

wird, bei der einfache Zusätze wie z.B. die Möglichkeit für Fußgänger zur Rufen des grünen Signals zum Albtraum 

werden. 

Im Handbuch (Kapitel 17) wird ein globales Modell entwickelt, das in seiner Einfachheit besticht und mit einem 

Local-As-View-Konzept auch die einzelne Komponente von Kreuzungen abbildet. 

Eine allgemeine Konstruktionslehre verfügt über Potentiale wie die folgenden: 

Standardisierte Komponenten: Standardisierte Komponenten sind einfach instantiierbar, relativ einfach mit Methoden 

von Skriptsprachen integrierbar und sind selbst parametrisierbar. Damit werden die Komposition und 

deren Effekte beherrschbar. 

Kooperation von Komponenten: Mit einer Input-Output-Assoziierung von Komponenten und einer Separation 

von Einspiel- und Ausspielmaschine ist eine variable Integration in Web-Anwendungen möglich. 

Adaptierbarkeit: Komponenten und Informationssysteme auf der Grundlage von Komponenten erlauben eine Adaption 

an Anwendungen mit Bildung von Variationen je nach Benutzung, Benutzern, (technischer) Infrastruktur 

und Netz. 

Beherrschbarkeit von Anwendungen: Die Pflege, die Veränderung, der Versionswechsel, eine Erweiterung, die 

Integration, die Weiterverwendung von Teilen und die Altlasten-Beherrschung werden einer neuartigen Lösung 

zugeführt. 

1.9.3 Examples of Layered Architectures: Presentation-Control-Mediator-Entity-Foundation Layering 

Presentation layer: communication user-control 

Control layer: intermediate to domain layer 

Domain layer: consists of entity and mediator components 

Foundation layer: intermediate between domain and service systems (DBMS,...) 

Main principles: 

Downward-dependency principle 

Upward-dependency principle: 

Neighbor communication principle 

Explicit association principle 

Cycle elimination principle 

Class naming principle 

Acquaintance package principle 

IS ADD


1.9.4 Examples of Layered Architectures: Database System Architecture 

Application 

system 

(workflow 

(functionality)) 

Presentation 

system 

(playout 

(story)) 

❄✻ 

✛ 

✲ 

DBMS 

Communication subsystem 

Input-output 

processor 

Parser 

Update 

processor 

Optimizer 

Code generation 

Compiler 

Query 

processor 

Access plan 

generation 

Authority 

control 

Pre-compiler 

Integrity 

control and 

enforcement 

Distribution management 

DBS = 

DBMS + 

{ DB } 

Synchronization 

of parallel 

access 

✻❄ 

Supporting 

systems 

(graphical 

etc. ) 

Storage management 

Data manager 

✻❄ ✻ 

Log Data 

book✲ ✛ 

dictionary 

Recovery 

Transaction manager 

management 

Scheduler 

Buffer manager 

❄ 

Database 

✻❄ 

Operating 

system 

1.9.5 Examples of Layered Architectures: OLTP-OLAP: Generalized Data Warehouse Architecture 

1.9.6 Examples of Layered Architectures: Componentised Architectures 

SAP R/3 ARIS schemata are huge, unsurveyable, incomprehensible 

Templates definieren eine Familie von Typen oder Funktionen. Teile ihrer Definitionen sind parametrisiert, so daß 

sie nach einer Instantiierung leicht unterschiedliche Merkmale haben können. 

Komponenten werden zwei Bedeutungen gebraucht: 

als Teil eines Soft- und Hardwaresystems oder 

als Asset als Produkt des Softwareleebenszyklus, das möglicherweise wieder verwendet werden kann. 

Wir verwenden hier die erste Form und weichen damit bewußt von der Microsoft-Auffassung ab. 

Pattern bieten für ein Problem eine Lösung an, ggf. auch mit Parametern zur Anpassung an einen Kontext, in der 

diese Lösung greift. Sie beinhalten keinen Code, sondern eine Beschreibung einer Technik. Sie sind damit 

abstrakter als Frameworks, da sie keiner Beschränkung des Anwendungsbereiches unterliegen. 

Frameworks erfassen die Gemeinsamkeiten von Anwendungen und werden im Entwurfsprozeß erstellt. Mit Frameworks 

wird dargestellt, wie eine Menge von abstrakten und konkreten Klassen mit welchen Schnittstellen 

zusammenarbeiten. Sie enthalten i.a. mehrere Pattern und sind für einen speziellen Anwendungsbereich festgelegt. 

Ein Framework kann als Komponente aufgefaßt werden. Sie liefern auch eine wieder verwendbare Umgebung 

IS ADD


Units generator 

Unit, applet, 

data provider 

Purger 

Storage 

Workspace 

Gate 

User profiles 

Payment 

manager 

Active acquisition 

Data suites 

Access, history 

manager 

OLTP 

data 

Foreign 

Data 

Legacy 

Data 

✲ 

Micro-data 

✲ import 

export 

✲ tools 

✲ 

Content 

management 

system 

OLAP/DW System 

✲ 

Macro-data 

extractors 

database 

mining 

✲Anonymous 

user 

✲ 

✲ 

Business 

unit user 

EIS/DSS 

user 

Abbildung 29: Data Warehouse Architecture of the DaMiT System 

für Komponenten, z.B. zur Behandlung von Fehlern, zum Austausch von Daten und Prozessen. Sie erleichtern 

die Entwicklung neuer Komponenten, da sie eine Spezifikation für neue Komponenten und Templates zu ihrer 

Implementation bereitstellen. 

Generatoren sind Software-Werkzeuge, die Software-Entwürfe und Anforderungsbeschreibungen nutzen, um Teile 

einer Software-Anwendung automatisch zu generieren, einschließlich des Codes und Anweisungen zur Programmsteuerung. 

Wir weichen leicht von diesen Begriffen ab und verwenden eine Begriffsumgebung, die in anderen Ingenieurdisziplinen 

üblich ist. 

Characterisation 

classification 

schemes 

Contracted 

party 

✛✮ 

✐ 

Supplier 

deliverer 

supporter 

Ontology 

Thesauri 

Official 

glossaries 

Marketing 

Organization 

✛✮ 

✐ 

✲ 

✶ 

✍ ✻▼ 

Characterisation 

◆ ❄✌ 

Product 

✛✮ 

✐ 

Production 

Instruments 

✍ ✻▼ 

Production 

process 

✲ 

✶ 

◆ ❄✌ 

Production 

Asset 

✍ ✻▼ 

Production 

act 

◆ ❄✌ 

✍ ✻▼ 

◆ ❄✌ 

◆ ❄✌ 

Associated 

company 

✛✮ 

✐ 

Technical/ 

application/ 

... architecture 

Construction 

technology 

Person 

personality 

SAP R/3, Version 3: 4.200 relational types, ≈ 90 % are relationship types 

≈ 20 k attributes , ≈ 11 k views 

IS ADD


Layered Solution 

Lebenszyklusmodelle von Komponenten von Schemata. 

Flußmodelle entlang der Entwicklung 

darauf aufbauend Flußmodelle der Semantik 

Darstellung durch 

Phasen-Darstellung (Objekttyp ← Ist In → Phase) 

Nachteil: Historie schwierig nachvollziehbar 

Universalrelationen-Objekttyp 

Vorteil: einfache Struktur 

Subtypenstruktur mit einer based on Konstruktion 

Beispiel: Lebenszyklus eines Studenten 

mit Identifikationsvererbung 

ggf. mit Identifikationsanreicherung 

Nachteil: linearisierte Verläufe nur darstellbar, ansonsten verwirrend 

Detailstruktur 

Erweiterbarkeit, geringe Flexibilität Vorteil: Kodierung, IC-Pflege 

Typische Entwicklungmodelle: siehe Bestellungsmodellierung 

Based On-Modellierung: Typ(Typentyp, Agent, Proponent) 

ggf. erweitert um Rollen von Agenten und Proponenten 

Vorteil: einfach, übersichtlich 

Nachteil: schwierige Agent-Proponent-Dimension 

Auffaltung 

Inkrementelle Entwicklung Beispiel: wissenschaftliche Arbeit 

Grundtyp mit Spezialisierung je nach Dimension der Charakterisierung 

Vermischung mit based on 

Kreismodelle am besten mit Typ in Phase 

Varianten bzw. Variantionen bzw. Versionen 

ggf. mit Baumdarstellung 

Assoziationen mit vollem erweiterten ER-Modell 

ggf.mit dynamischen Aktivitätenmodell 

sowie Rechten zur Modifikation 

Bindungsarten (siehe 89 Arten von Links) 

• streng 

• ... 

• referenziert 

Metacharakterisierung unterschiedliche Arten: 

• Log 

• history 

• Archiv 

• Qualität 

• Benutzungsinformation (eingebettet in Story-Raum) 

• Autorenschaft 

• allgemeine Charakterisierung 

IS ADD


siehe auch Metainformationsstandards 

Verlaufscharakterisierung mit dockets 

Zusatzlösungen für Architekturen von Komponenten von Schemata. 

Typisches Beispiel: Dreiebenenarchitektur von DBS mit Sicht(weis)en über der logischen (objekt-relationalen) Datenbank, 

Ausspiel, Einspiel, ... 

Architektur und Komponenten von Schemata. 

Für die Entwicklung im Großen präferieren wir eine allgemeine Konstruktionslehre für Informationssysteme, die man folgendermaßen 

charakterisieren kann: 

IS-Planung und IS-Engineering: Es wird ein Skelett oder eine Architektur eines Informationssystemes entwickelt, die eine 

komponentenbasierte Entwicklung unterstützt. 

‘Komponentenkunde’: Wir entwickeln eine allgemeine Methodik zu Klassifikation, zu Definition von Basiskomponenten, zu 

Konstruktor und Konstruktion von komplexen Systemen aus Komponenten. 

Grundlagen des Konstruierens: Die komponentenbasierte Entwicklung von Systemen kann dargestellt werden als Entwicklung 

von Strukturierung, Funktionalität und Interaktivität sowie Verteilung von Komponenten und aus Komponenten 

bestehenden Informationssystemen. 

Allgemeiner Konstruktionsprozeß: Die Entwicklung von Informationssystemen basiert auf Funktionskomponenten und erlaubt 

restriktionsgerechtes Konstruieren. Damit wird auch eine Minimierung und Kostenreduktion unterstützt. 

Funktionsbauweisen: Es können allgemeine Kostruktionsprinzipien abgeleitet werden für unterschiedliche Typen von Informationssystemen 

wie Mono-Informationssysteme, Multi-Informationssysteme und Farmen von Informationssystemen. 

Standardisierung: Komponenten können zu Gruppen in Baukästen zusammen gefaßt werden und damit zur Konstruktion 

neuer Informationssysteme herangezogen werden. 

Anwendungsspezifischer Konstruktionsprozeß: Der Konstruktionsprozeß kann den Spezifika, den spezifische (quantitative) 

Parameter, der Optimierung, der unterschiedlichen Bewertung un Interaktion Rechnung tragen. 

Die allgemeine Grundlage des Konstruierens ist der hier propagierte Prozeß des integrierten Entwurfes. Sie basiert auf 

der Entwicklung des Skeletts der Anwendung mit Einheiten und Assoziationen der Einheiten bzw. Assoziationen, auf Meta- 

Charakteristiken der Einheiten und Assoziationen, 

Entwicklung der Basiskomponenten meist als Stern-Schema oder auch als Schneeflocken-Schema wie in diesem Kapitel dargestellt, 

auf der Konstruktion der Meta-Strukturen im Schema, die unterschiedliche Aspekte darstellen wie 

strukturelle Aspekte der Komponenten-Architektur, der Faltung nach Analogie und konstruktor-basierte Entwicklung, 

Lebensphasen-Aspekte je nach Art der Lebensphasen wie zyklische, gesteuerte, nicht-deterministisch, duplizierende 

Lebensläufe, 

Aspekte zu Kontext-Dimensionen zur Meta-Charakterisierung, zu Benutzung und zur Qualität, 

und 

der Detailentwicklung nach unserem Entwicklungszugang ‘im Kleinen’ zur Entwicklung von Strukturierung, Funktionalität, 

Interaktivität und Verteilung von Informationssystemen. 

Konstruktionslehre für Informationssysteme ? 

• Basiskonstrukte (Strukturierung, Funktionalität, Sichtweisen, Import-Export) 

• Konstruktion von komplexen Systemen mit 

• Konstruktoren (Verbindungen der Import-Export-Sichten) 

• Konstruktionskunde durch Regeln und Methodik 

IS ADD


• Sinnvoll und möglich? 

Beobachtungen in unserer Schema-Bibliothek 

Zusammenfassung zu wenigen verallgemeinerten Schemata 

Wiederholungen gleicher Strukturen 

Mehrdimensionalität in Schemata zur Darstellung von Aspekten 

(Spezialisierung, Assoziation, Kontext, Benutzung, 

Geschichte, Meta-Charakteristik) 

Versionen und Sichten zur Darstellung von Benutzungsaspekten 

Allgemeine Herangehensweise: 

Komponentenbasierte Software-Entwicklung 

• Aufbau von Anwendungen aus existierenden Komponenten 

als Meta-Programming-Paradigma 

Denken in interoperablen Komponenten statt einzelnen Elementen 

• Softwarewiederverwendung statt Neuentwicklung 

• Strukturerhaltende Modellierung der Anwendung 

• Ausnutzung von Domänenwissen 

• Produzenten/Konsumenten-Idee 

• interaktive Entwicklung 

Softwareproduktion 

Komponententechnologie 

OO-Technologie 

3GL-Technologie 

Abbildung 30: Evolutionsstrategie der Software- (Datenbank-) Entwicklung 

Dabei werden verallgemeinernd die Komponenten charakterisiert wie in der Pattern-Technologie (Entwurfsmuster) 

(Dort meist noch ungeordnet (2 Linien: Gamma-Linie (siehe sein Buch) und Siemens-Linie) und unstrukturiert. Besser bereits einmal 

benutzt bei der Erstellung von Programmbibliotheken.) : 

• Name (Akronym oder Bedeutung) 

auch mit einer Angabe von Alias-Namen (Also-Known-As bzw. Save-As) 

• Kontext (sowohl system-orientiert als auch human-oriented) 

Anwendungsbereich mit einer Charakterisierung von Anwendungsfällen (Known-Uses) 

Einbindung in Umgebungen mit einer Angabe der Integrationsstrategie und related pattern und der 

Konsequenzen der Anwendung dieses Musters 

Charakterisierung von Akteuren und deren Rollen 

und einer Darstellung der Intension bzw. Motivation 

Gründe für die Darstellung der Motivation 

IS ADD


Selektive Wahrnehmung von Benutzern und Entwerfern (multi-perspective approach) 

multiple angled 

Semantik versus Vorstellung (unterschiedliche Semantik der Darstellung) (‘paralysis by the analysis 

syndrome’) notwendig wird ein einheitliches Basis-Modell 

uniqueness of the basic model (guardian) 

‘not invented here’ Syndrom (shared meaning (diplomatic)) 

minimal appeal: Entwickler warten auf Lösung durch andere 

initializable (strawman) 

unterschiedliche Abstraktion der gleichen Realität und damit Konsistenzprobleme 

consistency (validator) 

Zerlegung bzw. Modularisierung erfordert meist bereits tiefgründiges Verständnis 

adversarial (devil’s advocate) 

‘knee jerk’ Effekte: meist werden unlösbare Probleme übersehen 

lateral (fact-finder) 

• Charakterisierung des Problemes 

• Angabe der Lösung 

Struktur 


Semantik (sowohl statisch als auch dynamisch) 

Angabe von Beispielen 

Implementation und Charakterisierung von Plattformen 

mit einer Angabe von Varianten 

und sample code 

Ein Beschreibung der Komponenten umfaßt: 

allgemeine Architektur der Anwendung als Komponenten-Schema 

Zusammenhänge der Komponenten 

Abgrenzung der Komponenten voneinander, 

Kooperationsbeziehungen der Komponenten auf der Grundlage eines Kooperationsvertrages bzw. Föderierungsvertrages 

Vererbung und Steuerung von Strukturierung und Funktionalität einer Komponente durch andere Komponenten. 

Stern-Schema als Komponente Produkte haben neben spezifischen Eigenschaften 

Spezialisierungen z.B. materielles Gut, Service, 

Versionen, 

und Beziehungen, Kontext (z.B. Klassifikation). Dreidimensionale Meta-Struktur! 

Spezielle Sichten für Assoziation 

Schneeflocken-Schema als Komponente 

IS ADD


Produktkode 

Einführdatum 

BeginnVerkaufDatum 

BeginnServiceDatum 

Kommentar 

Gut Service ProduktVersion 

Produktspezifische 

Eigenschaften 

 

✶ 

❄ 

Produkt 

✻ 

✮ 

✐ 

Weitere 

Eigenschaften 

Name 

UniversalProductCode 

... 

EndeVerkaufDatum 

EndeServiceDatum 

Kategorisierungen 

Spiegel von 

Kurs 

✛ 

Basiert 

Auf 

Kurs 

✻ 

✒ 

Raum 

IstEin 

Feiertag 

✲ 

Tag 

✛ 

❥ 

Vorlesung 

❄ 

Lehrkraft 

✻ 

Arbeitet 

In 

✲Studiengang 

✲ 

✻ 

Angeboten 

Durch 

❄ 

Institut 

Vorlesung-Lehrkraft-ArbeitetIn-Institut ⊆ ⊇ 

Vorlesung-Studiengang-AngebotenDurch-Institut 

Vorlesung-Kurs ‖ Vorlesung-BasiertAuf-Kurs 

Konstruktionslehre 

Komponenten, aufbereitet zur Komposition 

• die zentrale Komponente Product Intext Data: 

Product, Item, Service, ProductCharacteristics, 

• Categorization Schema (α, Code; 

ProductCategoryClass(α,ProductCategory(Code)) , 

• Availability Schema (α; ProductObsolesence(α)) , 

• Product Associations Schema (α, β, δ; 

Associates(what : α, toWhat : β, kind : δ)) , 

• Inventory Schema (γ, ɛ; Inventory(what : γ, store : ɛ)) 

Marken (what, store) 

für binären Relationship-Typen InventoryItem, 

• Container Schema (ζ, η; Container(kind : ζ, partyAddress : η)) 

• Producer Schema (α; ProducerOf(α, Organization)) 

• Pricing Schema (α; ProductPriceComponent(α)) 

Konstruktion aus Komponenten 

Product Schema ✶ α:=CategorySet Categorization Schema 

✶ α:=P roduct Availability Schema 

✶ α:=P roduct,β:=P roduct,δ=P roductSubstitute 

⊕ ConsistsOf 

IS ADD


Product Association Schema 

✶ ζ:=ContainerT ype,η:=Address Container Schema 

✶ γ:=Item,ɛ:=Container 

⊕ Address Inventory Schema 

✶ α:=P roduct Producer Schema 

✶ α:=AdditionalCharacteristics Pricing Schema 

Komposition durch 

• Parameter-Instantiierung mit entsprechender Gleichungslogik, 

• Unifikation der Ausdrücke mit Methoden des term rewriting, 

• ER-Restrukturierung mit Methoden der ER-Schematologie und 

• Ableitung der Sichten-Kooperation mit Graph-Grammatik-Methoden. 

Als Beispiel betrachten wir folgende Schemata: 

Dimension 

Type 

✛ 

Dimension 

OfType 

✲ 

Dimension 

❑ 

Color 

✻ 

Other 

Characteristic 

✕ 

Quantity 

Break 

✻ ✕ 

Price 

Component 

Type 

Party 

Type 

Brand 

Name 

Used To 

Base Define 

Purchaser 

Of 

Product ■ 

Product 

Price Discount LocationGeographic 

Type 

Level UsedToDefine 

❦ 

✿Boundary 

Product 

Quality 

2 

Component Discount 

OptionalComponent 

❫❯ 

Product 

Price Estimated 

DependentOn ✒ UsedTo 

Component Product Define 

UOM 

UnitOf ✛ 

⊕ Specified ✗ 

Cost 

Costed 

Measure 

Product 

2 

✙ For Priced 

By 


Product 

may be 

Surcharge By 

Converted 

❘ ✌ Supplier 

converted Conversion in 

Component Product 

Product ✻ 

✲ RatingType 

Factor 

Supplier 

Obsolesence 

AReplacementNeededFor ❘ Product 

SuperceededBy Characterized 

Product 

❘ Supplier 

Substitute Product 

Consists Product 

Of ✲ ❥ Preference 

By UsedAs ❘❘ ❄ 

✠ 

MadeUpOf 

❫ 

✛ Producer ✲ Organization 

UsedIn 

Of 

✻ WorkIn ✻ ✻ 

Progress 

Prod 

Category 

Additional 

Raw Class 

❂ Material 

✛ 

✾ 

Identification Item 

Item ✛ Finished ❄ 

Type 

Good Product 

Category 

✻ 

✛ Market 

Identification 

Interest 

Item 

Item Shrinkage ✲ Inventory 

❄ 

Variant Item ⊕ 

Party 

Overages 

WarehousedAt 

Type 

StorageFor 

Service 

✮ ❄ 

Party ✛ Container ✲ Container 

Address Type 

❄ 

❃ 

The Specialization and Product-Product-Association Dimensions 

Product 

Obsolesence 

Product 

Substitute ✲ ❥ ❘❘ 

Consists 

Of 

✻ 

Product 

✻ 

WorkIn 

Progress 

Additional 

❂ Material 

Raw 

✛ 

✾ 

Identification Item 

Item ✛ Finished 

Type 

Good 


✻ 

Item 

Item Shrinkage ✲ Inventory 

Variant Item ⊕ 

Overages 

WarehousedAt 

StorageFor 

Service 

✮ ❄ 

Party ✛ Container ✲ Container 

Address Type 

IS ADD


Dimension 

Type 

✛ 

Dimension 

OfType 


Name 

Product 

Type 

✲ 

Dimension 

❑ 

■ 

❦ 

Color 

✻ 

Product 

Quality 

2 

UOM 

UnitOf ✛ 

⊕ 

Measure 

Product 

2 

may be 


converted in Converted 

Conversion 

Factor ✻ 

❘ Product 

Characterized 

❄ 

Product 

Other 


✕ 

The Characterization Dimension 

Consists 

Of ✲ ✲ ✻ 

Used To 

Base Define 

Purchaser 

Of 

Product 

Price Discount LocationGeographic 

Level UsedToDefine ✿Boundary 

Component Discount 


❫❯ 

Product 

Price Estimated 

DependentOn ✒ UsedTo 

Component Product Define 

Specified ✗ 

Cost 

Costed 

Product ✙ For Priced 

By 

Characteristic Surcharge By 

Product 

❘ ✌ Supplier 

Component Product ✲ RatingType 

Supplier 

Product 

Characterized 

Product 

❘ Supplier 

Preference 

❄ 

Product 

Quantity 

Break 

✻ ✕ 

✠ 

✛ 

❄ 

Price 

Component 

Type 

Producer 

Of 

❃ 

❫ 

✲ 

Party 

Type 

Organization 

The Producer, Supplier and Pricing Dimensions 

IS ADD


The Product-Product-Association and Categorization Dimensions 

Product 

Obsolesence 

AReplacementNeededFor 

SuperceededBy 

Substitute 

Product 

By 

Consists 

Of ✲ ❥ UsedAs 

MadeUpOf 

UsedIn 

❘❘ 

Product 

✻ 

Prod 

Category 

Class 

❄ 

Product ✛ 

Category 

Market 

Interest 

❄ 

Party 

Type 

Meta-Strukturen in Schemata. 

Komponenten-Schema 

wie vorher 

hier noch einmal Suite (wie bereits bei Sichten (Aktionssichtensuite)) Mikro-Strukturen in Schemata. 

Komposition von Schemata. 

IS ADD


1.10 The Loss of Architectural Knowledge during System Evolution 

Observation: Once a system has been developed, architectural solutions are kept in the documentation. During evolution 

phases, architectural knowledge is not updated. 

Result: architectural decay, outdated architecture, loss of essential dependencies among components and introduction 

of undocumented dependencies. 

Typical dependencies in the code: invocation of a method/constructor, access of an attribute (field, property), 

extensions of classes or structures by implementing an interface, usage of a class (structure, enumeration) as a type 

for an attribute (field, variable, parameter), annotation of an attribute. 

Explicit quality (coherence, conformance) checks, explicit architecture monitors (at least for the technical architecture), 

continuous architecture analysis. 

Metrics might be useful. 

Application features drive evolution and the technical architecture. 

Tactics (Brass) for evolution to influence quality. 

1.10.1 QuaSAR Architecture: Separation of Viewpoints 

Abbildung 31: Der Alptraum einer falschen Architektur; besser gleich mit QuaSAR 

Source von Bild 31: 

Technische Open Source Komponenten implementieren - Die Referenzarchitektur Quasar 

Dr. Bernhard Humm, sd&m Research, Bremen, 17. September 2004


Viewpoints: application zones, system structure, infrastructure embedding 

Geometry!! 

ground plan 

profile view 

top view 

Architecture!! 

function view 

infrastructure view 

deployment view 

1.10.2 Software Architecture: Our Approach 

A system architecture represents the conceptual model of a system. 

• Different abstractions: application domain .... specification ... coding ... sub-coding 

• Different viewpoints: module structure, ... 

• Different concerns: structure, functionality, distribution, interaction 

• Differences for stakeholders: programmers view, embedding into infrastructure, business user view 

Application domain description 

Architecture 

blueprint 

Requirements 

prescription 

Software specification 

Abbildung 32: The Software Engineering Quadruple 

What is now the problem? 

How architecture concerns can be integrated into systems development? 

Integration into IS development processes: late, early, escorting 

Architecturing as an orthogonal concern


Software Architectures Description Language. 

ADL 

Architecture Modeling Features 

Components 

Interface 

Types 

Semantics 

Constraints 

Evolution 

Non-functional properties 

Connectors 

Interface 

Types 

Semantics 

Constraints 

Evolution 


Component-Based Specification. 

Architectural 

Configurations 

Understandability 

Compositionality 

Refinement and 

traceability 

Heterogeneity 

Scalability 

Evolution 

Dynamism 

Constraints 

Non-functional 

properties 

Tool Support 

Active Specification 

Multiple Views 

Analysis 

Refinement 


Generation 

Dynamism 

Software architecture as the starting point 

Signature: 

COMPONENT = (Name, Exported Services, Imported Services, 

Usage Constraints ) 

Functions of the component: 

• Exports: COMPONENT → P(EXP SERVICE) 

• Imports: COMPONENT → P(IMP SERVICE) 

• Constraint: COMPONENT → CONSTRAINT 

• Name: COMPONENT → STRING 

Views of the component: 

• Application architecture view 

• Infrastructure architecture view 

• Technical architecture view 

Services of Components. 

defined by the union of 

SERVICE = EXP SERVICE ∪ IMP SERVICE 

Signature: 

SERVICE = (Name, , ServiceResType, 

Component, Quality of service )


Functions of the service: 

• ServiceParam: SERVICE → (TYPE × MODE) ∗ 

• MODE = { in, out, inout } 

• ServiceResType: SERVICE → TYPE 

• Component: SERVICE → COMPONENT 

• Name: SERVICE → STRING 

Services of Components. 

defined by the union of 

SERVICE = EXP SERVICE ∪ IMP SERVICE 

Signature: 

SERVICE = (Name, , ServiceResType, 

Component, Quality of service ) 

Exported services exported by the component 

• ExportStructure: EXP SERVICE → P(USE STRUCTURE) 

Imported services based on corresponding signature 

• ContainedServices: USE STRUCTURE → P(IMP SERVICE) 

• MeetsConstraint: USE STRUCTURE × CONSTRAINT → BOOL 

Interfaces of Components. 

defined through an interface signature SPEC 

• ProvidedServices: VIEW × EXP SERVICE → SPEC 

• RequiredServices: VIEW × IMP SERVICE → SPEC 

• SatisfiesConstraint: VIEW × SPEC × SPEC → BOOL 

Connections among the components based on CONNECTOR 

• Connector: IMP SERVICE × EXP SERVICE → CONNECTOR 

• ImportServices: CONNECTOR → IMP SERVICE 

• ExportServices: CONNECTOR → EXP SERVICE 

Interfaces of Components. 

defined through an interface signature SPEC 

• ProvidedServices: VIEW × EXP SERVICE → SPEC 

• RequiredServices: VIEW × IMP SERVICE → SPEC 

• SatisfiesConstraint: VIEW × SPEC × SPEC → BOOL 

with constructors axioms


Application domain 

layer 

Scoping 

❄ 

Requirements 

acquisition 

layer 

❄ 

Conceptual 

layer 

Implementing 

specification 

Structuring 

❄ 


layer 

Variating 

❄ 

Business user 

layer 

Designing 

Distribution 

specification 

Functionality 

specification 

Dialogue 

specification 

Abbildung 33: Abstraction Layers and Model Categories in WIS Co-Design 

• s imp ∈ ContainedServices(ImportStructure(s exp )) 

• acyclic connections (no exported service used in its body an imported service that is connceted 

• each imported service is conncted with at most one exported service through a connector or an abstract connector 

Abstraction Layers and Model Categories in WIS Co-Design.


Description/ 

prescription 

layer 

Design 

Refinement 

Application 

area 

description 

Requirements 

prescriptions 

WIS description 

and prescription 

Conceptual 

layer 


layer 

Presentation system 

specification 


Transformation 

WIS specification 

Information system 

specification 


system 

Presentation 

system 

Web information system 

Abbildung 34: The classical dichotomy of human-computer systems and the systems ladder 

1.10.3 Web Information Systems Architectures 

So far: Presentation is driven by the system 

Content Management: Known Choices. 

Media type architecture has been settled but ... 

Example: Architectures of Web Information Systems: Infrastructure Collaboration. 

Web IS



layer 

Scoping 

❄ 

Requirements 

acquisition 

layer 

❄ 

Conceptual 

layer 

Implementing 

specification 

Structuring 

❄ 


layer 

Variating 

❄ 

Business user 

layer 

Designing 

Distribution 

specification 

Functionality 

specification 

Dialogue 

specification 

Abbildung 35: Abstraction Layers and Model Categories in WIS Co-Design 

Presentation 

systems 

✻ 

❄ 

Web middleware 

system 

✻ 

❄ 

Application logic 

system 

✻ 

❄ 

DBMS 

Support systems 

✻ ✻ ✻ 

❄ ❄ ❄ 

Layout/ playout 

systems 

✻ 

❄ 

Web middleware 

system 

✻ 

❄ 

Storybord layout/ 

playout system 

✻ 

❄ 

Media type 

management system 

✻ 

❄ 

DBMS 

Support systems 

✻ ✻ ✻ 

❄ ❄ ❄ 

Classical 3-tier web server 

Media type architecture 

PCMEF architecture 

Web IS


Community 

& leisure 

groups 

Web Information Systems 

Infrastructure Management 

Forum & 

discussion 

corner 

Minor art events 

✮ 

✛ 

✐ 

Inject 

Book 

Response 

Information logistics 

 

✲ 

✶ 

Big events 

Restaurant 

City administration 

events 

Educational 

institutes 

events 

◆ ❄✌ 

Sport events Traffic about 25 other 

collaboration 

DBS 

✠ 

Architectures 

Signatures/ schemata/ specification languages 

✻founded annotated aggregated macro-schema 

annotated aggregated macro-schema 

aggregated macro-schema 

macro-schema 

schema 

(sensor) micro-schema 

Feature A Aspect B 

mainframe 

client/server 

federated 

collaborated 

collaborating on demand 

✲Processes and products 

of development 

Abbildung 36: The Development Space for Web Information Systems 

Web IS


Description/ 

prescription 

layer 

Conceptual 

layer 


layer 

Design 

Refinement 



Application 

area 

description 

Presentation system 

specification 

Presentation 

system 

Requirements 

prescriptions 

WIS description 

and prescription 

WIS specification 

Information systems 

specification 

Web information system 


system 

Abbildung 37: The dichotomy of human-computer systems and the systems ladder 

1.11 Modellierung im Großen als der Normalfall 

1.11.1 CIDOC als gewachsenes Beispiel 

Siehe Bild 38 bzw. 39 

1.11.2 Eine einfache Website-Anwendung 

Siehe Bild 40. 

1.11.3 Eine etwas problematische Website-Anwendung 

siehe Bild 41 

1.11.4 Vorlesungsverzeichnis als ein einfaches System 

Siehe Bild 42 

1.11.5 Zwei nicht allzu professionelle DB-Schema 

Siehe Bild 43 bzw. 44


Abbildung 38: CIDOC Conceptual Reference Model Diagram V9 

Abbildung 39: CIDOC Conceptual Class Hierarchy V9


Abbildung 40: Das Stadtinformationssystem der Stadt Forst


untitled -- Display1 / 

Nutzer 

n_id 

f_id (FK) 

nutzername 

nutzerpw 

nutzernr 

k_id 

sprach_id 

Liefzahlbed 

lzb_id 

f_id (FK) 

liefzahlbed 

Firma 

f_id 

firma1 

firma2 

firmakurz 

gesellform 

land_id 

bl_id 

reg_id 

plz 

ort 

strasse 

tel 

fax 

html 

email 

gruendjahr 

mitarbzahl 

umsatz 

waehrung 

hrb 

ust 

institution 

iso9000 

oko 

frei 

letzteaender 

hrort 

hrart 

hrbnr 

cmitarbzahl 

cumsatz 

herkunft 

Anzeigen 

f_id (FK) 

anz_id 

anzeige 

zeigen 

zeigen2 

1, 1 / 3, 4 -- 09:14:44 , 02/08/1999 

Abbildung 41: Das Web-Informationssystem Wirtschaft Online


Abbildung 42: Das Web-Informationssystem zur Vorlesungsplanung


Abbildung 43: Das DB-Schema von Facebook 1.0


Abbildung 44: Das DB-Schema von MediaWiki 1.0 

1.11.6 Entwurfsheuristiken für große Schemata 

Große Schemata erfordern ein diszipliniertes Herangehen an die Entwicklung. Dies wird jedoch erschwert durch die 

inhärente Unvollständigkeit der Entwurfsinformationen. Damit sich unvollständige oder verspätet erkannte Informationen 

nicht auswirken benötigen wir allgemeine Entwurfsregeln, Entwurfsheuristiken und Entwurfsstrategien 

Für die Darstellung mit dem ER-Model können wir pragmatische Regeln entwickeln: 

Entity-Typen: Ein Entity-Typ ist kein relationaler Typ. Er hat die Aufgabe, Konzepte der Anwendung zu beschreiben. 

Damit muß auch aufgezeigt werden, warum dieser Typ in der Anwendung relevant ist. Existenzregeln und 

Streichungsregeln gehören zur vollständigen Definition von Typen. 

Oft werden Informationen archiviert. Damit muß eine Möglichkeit existieren zur Darstellung der Gleichheit 

von Objekten. Namenskonventionen sollten nachvollziehbar sein. Für schwache Entitytypen sollte die Relevanz 

für die Anwendung besonders geprüft werden. Variationen von Typen können durch verschiedene Benutzergruppen 

gefordert werden. Die Darstellung kann meist über Sichten erreicht werden. Ist dies nicht möglich, 

dann sind die ‘analogen’ Typen durch entsprechende Integritätsbedingungen zu verknüpfen. Sichten sind oft 

einer komplexeren Struktur vorzuziehen, weil damit auch die Zuordnung von ‘Besitz’verhältnissen erleichtert 

wird. 

Relationship-Typen: Zur vollständigen Relationship-Typ-Definition ist auch die Angabe der Kardinalitätsbeschränkungen 

notwendig. Die Spezifikation der Rollen ist notwendig für die relationale Untersetzung des Entwurfes. 

Verschiedene Schlüssel der Komponententypen können in die Definition einbezogen werden. Mitunter ist 

ein Sekundärschlüssel eher für einen Relationshiptypen geeignet. 

Unterscheidung von Spezialisierung und Generalisierung: Gerade im klassischen ER-Modell und insbesondere 

in binären ER-Modell wird die Generalisierung nicht von der Spezialisierung unterschieden. Sie sind auf die


gleiche Art über IsA-Relationshiptypen modelliert. In späteren Entwurfstadien ist jedoch ein unterschiedliches 

Verhalten für generalisierte bzw. spezialisierte Typen darzustellen. Außerdem muß eine Generalisierungs- und 

Spezialisierungshierarchie von einer Art-von-Verknüpfung von Typen unterschieden werden. 

Attribute: Eine Attributdefinition erfordert auch die exakte und vollständige Darstellung der zugrunde gelegten Typen. 

Operationen: Anwendungsszenarien verwenden verschiedene Operationen in unterschiedlicher Häufigkeit und Priorität. 

Diese Information für die Optimierung der Funktionalität essentiell. Deshalb gehört auch zur Darstellung 

der Anwendung eine Darstellung der Verwendung der Operationen. Damit werden Schlüssel gewichtet, die 

dann wiederum durch geeignete Mechanismen der DBMS zur Effizienzsteigerung benutzt werden können. 

Die Optimierung kann durch eine Spezifikation der Größe der Extension erleichtert werden. Minimale, durchschnittliche 

und maximale Anzahl von Objekten, die zu einer Klasse gehören, erleichtern das konzeptuelle 

Tuning. Der Strukturentwurf geht mit dem Entwurf der Funktionen einher. So kann z.B. eine Relationship 

einen begrenzte Einfügeoperation haben, ohne daß ein extra Teiltyp dafür eingeführt werden muß. 

Die Anwendungsszenarien können auch eine unterschiedliche Häufigkeit und Priorität ergeben. Oft gibt es 

voraussehbare plötzliche Veränderungen im Systemverhalten wie z.B. den Semesterbeginn in der Universitätsanwendung. 

Entwurfsheuristiken werden benutzt, um eine Zuordnung von Konstrukten der Realität zu den verschiedenen Typen 

zu erleichtern. 

Unterscheidung von Entity- und Relationship-Typen: Modelle, in denen zwischen Entity- und Relationship-Typen 

nicht unterschieden werden kann, führen zu Konfusion und auch zu falschen Attributzuordnungen. Entity- 

Typen sollten auf die unabhängig voneinander existierenden Objekte der Realität konzentriert werden. Relationship- 

Typen sollten insbesondere Anwendung finden bei der Darstellung von Rollen. 

Kerntypen: Voneinander potentiell unabhängige Mengen von Dingen der Anwendung werden in Kerntypen dargestellt, 

die pragmatisch als Entity-Typ spezifiziert werden. 

Unterscheidung von Attribut-Typen und Entity-Typen: In Entity-Typen werden Objekte mit ihren Daten dargestellt. 

In Attribut-Typen werden Charakteristika von Objekten materialisiert. Die Attribute selbst können wieder 

strukturiert sein. Ein wichtiges Unterscheidungsmerkmal ist die unabhängige Existenz. Werte existieren nur 

im Zusammenhang mit Objekten. Entity-Typen können auch im Entwicklungsprozeß is zur konzeptionellen 

Schicht ohne Attribute existieren. 

Ob eine Eigenschaft vorliegt oder ein Ding der Realität entscheidet die Anwendung. So ist z.B. eine Adresse 

meist dargestellt als Attribut-Typ. Handelt es sich jedoch um eine Anwendung der Post, dann ist eine Adresse 

besser durch einen Entity-Typ. 

Materialisierung von Funktionen: Funktionen sollten nur dann materialisiert werden, wenn durch ihre Speicherung 

aus verschiedenen Gründen wirklich erforderlich ist, z.B. bei Änderung der definierenden Werte bei Beibehaltung 

des errechneten Wertes oder bei hoher Komplexität und wiederholter Benutzung. 

Synonym-, Homonym- und Alias-Typen: Oft werden gleiche Dinge der Ralität in unterschiedlichen Sichtweisen 

unterschiedlich dargestellt. Diese unterschiedliche Darstellung führt zu einer höheren Redundanz und bedingt 

die Einführung von entsprechenden Beziehungstypen bzw. Alias-Typen. 

Andererseits werden oft Eigenschaften mit der gleichen Bezeichnung dargestellt, obwohl sie unterschiedliche 

Bedeutung haben. Deshalb wird oft empfohlen, diese Unterscheidung explizit in der Bezeichnung mitzuführen 

wie z.B. IName, PName für einen Institutsnamen und einen Personennamen. Diese Unterscheidung ist jedoch 

auch mit dem zugehörigen Typ Institut bzw. Person gegeben, so daß eine Unterscheidung im Schema mit 

Institut.Name und Person.Name bereits gegeben ist.


Namenskonventionen: Die einführung von Namenskonventionen kann aus dem Anwendungsbereich abgeleitet 

werden. Häufig und allgemein verständliche Bezeichnungen kann man einfach übernehmen. 

Eine allgemeine Technik für das Einführen von Namen z.B für Teil-Typen mit Verweis auf Supertypen, Generalisierungen 

mit Verweis auf Komposita, Relationship-Typen, Attribut-Typen, Wertebereichen, Entity-Typen 

z.B. nach Konzepten) und deren Unterscheidung (Homonyme) ist eine Aufgabe der Vorbereitung vor dem Entwicklungsprozeß. 

Dazu gehören auch Standards für Abkürzungen, eine konsistente Benutzung von # und $, 

die Berücksichtigung von existierenden Standards und die Benutzung eines Fachwörterbuches. 

Relationship-Typen und Entity-Typen: Teiltypen, die durch eine anders geartete Funktionalität erforderlich sind 

(z.B. Vorlesungen in der Weiterbildung, im Fernstudium und im Präsenzstudium können verschiedenen Bedingungen 

unterliegen), sollten nicht eingeführt werden, wenn die Verwaltung auf andere Art einfach erfolgen 

kann. Außerdem sollten Versionen nicht in Typenbildung integriert werden. 

Sichtenbehandlung: Die späte Einführung von Sichten im konzeptionellen Entwurf nach der Definition des ER- 

Schemas führt sehr schnell zu einer Sichtenlawine für unterschiedliche Aspekte der Anwendung. Damit werden 

Sichten gleicher Art auf unterschiedliche Art unterstützt. Außerdem sollten Sichten stets Akteuren zugeordnet 

sein. 

Zulassen unvollständiger Informationen: Nullwerte sollten eine wohlverstandene Bedeutung besitzen. Die Benutzung 

von Default-Werte ist mitunter eine Alternative, die eine einfachere Verwaltung ermöglicht. Das Weglassen 

von Werten sollte nicht zur impliziten Typspezifikation benutzt werden. 

Schlüssel und Identifizierung: Schlüssel sollten zumindest bis zum konzeptionellen Entwurf eine eigenständige 

Bedeutung in der Anwendung besitzen. Werden sie erweitert, dann sollte die Bedeutung und die Schlüsseleigenschaft 

nicht verloren gehen. Namen sind gewöhnlich schlechte Identifikationen. Attribut-Typen, die Nullwerte 

zulassen sollten bewußt mit dieser Option eingesetzt werden. 

Dagegen läßt die DBMS-Technologie Nullwerte in Primärschlüsseln nicht zu. Deshalb sollten für Primärschlüssel 

alle Werte zu insert-Zeit bekannt sein. 

Die Update-Häufigkeit sollte bei der auswahl der Identifikation berücksichtigt werden 

Identifikatoren sollten legal sein und nicht über Sicherheitsmechanismen zu schützen sein (Beschäftigtennummer 

als Gegenbeispiel). Allen Akteuren, die sie benutzen müssen, sollten sie bekannt sein. 

Eine Pflege der Identifikation wird durch selbstkontrollierende Werte gut unterstützt. 

Die konzeptionelle Modellierung sollte alle Informationen erfassen, die für eine effiziente Speicherung und ein effizientes 

Verarbeiten notwendig sind. 

Die Ausarbeitung einer ER-Entwurfsstrategie ist auch aus anderen Gründen notwendig: 

Unvollständigkeit der Integritätsbedingungen: Normalisierungszugänge erfordern die Angabe der vollständigen 

Menge von funktionalen und evt. der mehrwertigen Abhängigkeiten. Damit ist ein Entwerfer oftmals überfordert. 

Einige Abhängigkeiten sind zu offensichtlich, um modelliert zu werden. Andere sind zu komplex oder zu 

tiefgründig. 

Darstellung von semantisch sinnvollen Einheiten: Jeder Entity-Typ und jeder Relationship-Typ sollte natürlich 

sein. Damit wird eine spätere Erweiterung und Überarbeitung gut unterstützt. Sind alle Typen “nat¨rlich”, dann 

ist auch die Formulierung von Anfragen wesentlich einfacher. 

Relationale Entwurfsstrategien dominieren die verwendeten Methodiken zur Entwicklung von Informationssystemen. 

Damit wird jedoch die Entwicklung für objekt-relationale und semi-strukturierte Datenbanksysteme 

erschwert. Durch relationale Strategien wird z.B. über Erzwingungsmechanismen für referentielle Integrität 

viel diskutiert, nicht aber für andere Abhängigkeiten.


Weiterhin ist die Verwendung von verschiedenen Typen einer Kontrolle zu unterziehen. Oft werden in der Literatur 

problematische Entwurfsentscheidungen propagiert wie die folgenden: 

Schwache Entity-Typen: Da der Identifizierungs- und Pflegeaufwand nicht zu vernachlässigen ist, sind bei Einführung 

von schwachen Entity-Typen besondere Vorsichtsmaßnahmen einzuleiten. 

Binarisierung von Relationshiptypen: Da sich nicht jeder n-ärer Relationship-Typ durch eine Menge von binären 

Typen darstellen läßt, ist eine Ausrichtung auf ein binäres ER-Modell mit einer hohen, meist nicht mehr überschaubaren 

Komplexität verbunden. 

Noch problematischer ist die Ausrichtung auf Modelle, die bestimmte Darstellungsrichtungen fordern oder 

binaäre Relationship-Typen weiter einschränken. 

Abstrakta: Die einzige sichere Binarisierung ist die Einführung abstrakter Entitytypen analog zur Netzwerkrepräsentationen 

. Abstrakta besitzen selbst keine zusätzliche Semantik. Ihre Semantik wird aus der Konstruktion hergeleitet 

und ist dadurch weder für den Entwerfer durchschaubar noch beherrschbar. 

Daraus können wir auch einige Fallen vermeiden wie z.B die folgenden: 

Verlassen auf Diagramme: Oft wird das Modellieren einer Anwendung mit dem Erstellen eines ER-Diagrammes 

verwechselt. Meist ist mit dem Diagramm nicht einmal die Interpretation des Diagramms klar. 

Klare Definitionen sind aus einer Reihe von Gründen notwendig: 

Grundlage für Informationsaustausch: Die Bedeutung der einzelnen entworfenen Typen und der benutzten 

Terminologie ist eine Grundlage für die Kommunikation mit dem Benutzer eines Informationssystemes 

und der Entwerfer untereinander. 

Elimination der Ambiguität und Verminderung der Vagheit: Klare Definitionen eliminieren die Ambiguität 

und Mißverständnisse. Vague oder unscharfe Begriffe der Anwendung werden schärfer gefaßt. Da Worte 

der natürlichen Sprache oft mehrere Bedeutungen und eine intensionalen und extensionale Erklärung 

haben, wird durch Defintionen die Interpretation auf die intendierte Darstellung der Anwendung eingegrenzt. 

Bedeutung wird erklärt: Die Bedeutung der einzelnen Typen wird erklärt. Sie ist damit einfacher erfaßbar 

und zu einem späteren Zeitpunkt einfacher modifizierbar. 

Abstrakte Konzepte sind theoretisch basiert: Abstrakte Konzepte unterliegen nicht der Variationsbreite natürlichsprachlicher 

Konstrukte. Eine Einigung ist einfacher. 

Gewählter Darstellungsweg wird verständlich: Oft existieren verschiedene äquivalente Darstellungen der 

gleichen Anwendung. Mit einer sauberen Definition wird die ausgewählte Darstellung erklärt. 

Standardisierung: Mitunter wird ein neue Anwendung beispielhaft neu entworfen. Der gewählte Weg kann 

als Standardweg weiterentwickelt werden, wenn seine Definitionen klar und unmißverständlich sind. Damit 

werden weitere analoge Entwicklungen vorgeprägt. 

Lexikondefinition: Durch ein unmißverständliche Darstellung wird das benutzte Lexikon verfeinert. 

Analyse wird ermöglicht: Spätestens während der Analyse und der Optimierung des Verhaltens sind präzise 

Definitionen notwendig. 

Für das klare Definieren kann man verschiedene Techniken anwenden. 

Verweis auf Beispiele: Durch Beispiele kann zusätzliche Semantik, die mitunter schwer formal gefaßt werden 

kann, dargestellt werden. 

Animation: Insbesondere für die Darstellung von Funktionalität ist die Animation von Entscheidungen zur 

Strukturierung, Funktionalität und Semantik sinnvoll.


Erklärendes Lexikon: Anwendungsspezifische Synonyme, das Aufzeigen des spezifischen Unterschieds zu 

anderen Darstellungen können die Entwurfsentscheidungen verdeutlichen. 

Zu wenig Strukturierung (Müllkorb-Entwurf): Es wird die gesamte Variantenbreite auf einen Typ reduziert, der um 

viele optionale Elemente, mit ‘flags’ auf die Teiltypen und einer komplexen Semantik dargestellt werden muß. 

Damit wird die Behandlung der Operationen zu schwierig. 

Oftmals werden auch Megaattribute verwendet. die alles umfassen, die allerdings ausgefeilter Funktionen 

bedürfen, damit sie benutzt werden können. Das Attribut Adresse ohne Teilstruktur ist ein solches Beispiel. 

Analog wird oft der Name von Personen mit einem flachen Attribut dargestellt. 

Überstrukturierung: Das andere Extrem ist der Entwurf im Elfenbeinturm, bei dem eine zu detaillierte Strukturierung 

entsteht, die dann auch durch eine stark ausgebaute aber unnütze Funktionalität unterstützt werden muß. 

Unwesentliche Teile der Anwendung: Ein Entwurf kann auch überladen werden mit Typen, die für die eigentliche 

Anwendung weniger Bedeutung haben und die Information darstellen, die in einem Kommentarfeld viel 

einfacher dargestellt ist. 

Ungeeignete Schlüssel: Es werden Schlüssel verwendet, die in der Anwendung einen vollständigen Zugriff auf 

alle Aspekte auch solchen Benutzern ermöglichen, die dafür keine Berechtigung besitzen. Beispiele solcher 

Schlüssel sind Immatrikulationsnummer, Personalnummer oder Versichertennummer. 

Zyklische Definitionen: Zyklische Definitionen erfordern einen Rekursionsmechanismus zu ihrer Behandlung. Damit 

wird aber dem DBMS eine Funktionalität abgefordert, die durch ein einfacheres Schema nicht erforderlich 

wäre. 

Ein typisches Beispiel zyklischer Definitionen sind Attribute, die aus anderen Attributen abgeleitet werden, die 

dann in der Konsequenz wieder auf die gerade eingeführten Attribute verweisen. 

Definitionen über die Negation: Begriffe werden mitunter in der negierten Form eingeführt, ohne die Art der Negation 

genau darzustellen. Ein Begriff wie AndereVeranstaltung als Teiltyp von Lehrveranstaltung macht nur 

in diesem Kontext Sinn. Der Kontext muß bei der Negation angegeben werden. Ansonsten trifft der Typ AndereVeranstaltung 

auch auf Sitzungen oder auch Studiengänge zu. 

Namenskollisionen: Insbesondere bei Attributen sollte der Kontext klar gestellt werden. Ansonsten besteht die 

Möglichkeit einer Konfusion und damit einer falschen Verwendung z.B. in Anfragen. 

Zu viel Redundanz: Redundanz ist oft für einen schnellen Zugriff notwendig. So kann z.B. eine Wiederholung von 

Attribut-Typen in Teiltypen sinnvoll sein. In diesem Fall sollte allerdings die Redundanz kontrollierbar und 

damit berechenbar sein.


1.11.7 An Application Example: Health Information Systems 

The application example is a compilation of about two dozen of application schemata developed with ID 2 tool mainly 

in the 90ies in Arabian and Asian countries and the schemata discussed in [SIG97, MJ04, Sil01] 8 . It is based on 

approaches developed in [Tha00b, Hay95, Wis01, Noc04, Keren, Fownn, Jac06]. The schema has been used for an 

international response answering a call for proposals issued by the health care organisation in the Gulf area. The 

approach has been extended to [BST06]. It resulted in [Bie08]. 

Like a typical application schema the health application schema is based on a multi-shell meta-model. 

General data shell: The general information is typically representing the conventions for data structures. Typical 

conventional data use in health care applications are 

• data on people based on a commonly used format for data on people, 

• data on equipment used for medical services, and 

• data on general associations and relationships of people. 

Installation and preparation shell: The preparation shell reflects data that are rather stable, are updated only in 

special situations and that are necessary for keeping other production data. These data reflect the chosen solution 

for the problems to be reflected. They are often considered to be the knowledge data since they represent the 

knowledge or professional skill level. Typical such data in health care applications reflect types representing 

• roles of people in health care applications such as being a patient or a health care professional, 

• services offered in a health care organisation, 

• agreements on which the health care process is based, 

• parties that act in a health care application such as insurance companies, financial institutions and professional 

organisations, and 

• types that specify the general categorisation of data. 

The last structures allow to define a component structure of types. 

Production data shell: Production data reflect the production process as such. The process has typically a process 

workflow. Therefore production data are typically reflected by horizontally layered sub-model suites with 

data that are used in steps that follow up but that are not modified in these steps. Therefore, the ER schema 

results in higher-order relationship types since this layering allows to keep track on the based-on layers. 

Production data also may reflect variants for a production. 

The workflow may either be recorded by log data or may result only in final data. 

After-production data shell: The production process is typically realised and their results are sold to other partners. 

Therefore, the after-production business may require additional data structures. 

Typical after-production data structures in health care reflect the 

• billing data and their tracking, 

• after care data, 

• education progress data of employees, and 

• referral data with their inherent redundancy. 

8 We do not use the SAP R/3 schema for health management. It contains far more data structures that allow to capture and to track the health 

status of an employee. Many companies use this part of the schema for deriving measures against health problems of their employees. 

IS ADD


IS ADD


Archive data shell: Archive data types allow to archive the health care processes for 

• track keeping of the main application processes and their outcome, 

• analysis of data and decision or management support, experience record, 

• exchange with other partners at the current and later stage, and 

• education of people involved into one of the processes. 

The archive data shell needs a special bookkeeping facility for privacy and security reasons. 

These shells may be refined to recursive shells and are sometimes not strict but interleaved and tunnelled. A typical 

tunnelling process is the early collection of data upon their first appearance. For instance, health care processes typically 

start with collection of billing data. This eager data collection is not only raising privacy concerns but also 

results in badly maintained data [Bra00, Ols03]. 

Health care information systems store data on 

• people and organisations that are concerned with patients, health care provider organisations, individual practitioners, 

insurance companies, 

• relationships between parties such as patient relationships and practitioners relationships, 

• types of services and goods available from the health care providers, 

• types of agreements that exist between the various parties, 

• records of health care services performed, 

• claims submitted and the status of the claim, 

• amounts directly owned from the patients as well as payments made by the patients, 

• other supporting information such as accounting information to create the financial statements and human 

resource information to track personnel. 

People and organisations in health care. 

Health care organisations need to track information about people and organisations with which they interact. 

Typical people involved into health care processes are patients, insured individuals, individual health care practitioners, 

administrators, provider staff support, and contact people such as those within an insurance company and in a 

pharmaceutical company. 

They also need to track information about organisations involved in health care such as health care providers, 

employers and associated groups, insurance companies, health care networks, and health care associations. 

There are some generic dimensions of people such as CONTACT, EMPLOYEE. A health care organisation may 

need to record various contacts within pharmaceutical companies, third party administration organisations, or insurance 

companies. 

Various standard organisation rules include EMPLOYER, SUPPLIER, HOUSEHOLD, REGULATORY AGENCY, OR- 

GANISATIONAL UNIT and INTERNAL ORGANISATION. ORGANISATION UNITS are subtyped into PARENT ORGA- 

NISATION, SUBSIDIARY, DIVISION, DEPARTMENT, and OTHER ORGANISATION. Depending on the purpose of the 

information system, we may represent them by role types, kind types, and special subtypes. The last opportunity 

is only chosen if there are essential and specific properties and thus attributes. 

IS ADD


Typical health care industry organisations are HEALTH CARE PROVIDER ORGANISATION, GROUP, NETWORK, 

EMPLOYER, THIRD PARTY ADMINISTRATOR, INSURANCE PROVIDER, PAYOR, and HEALTH CARE ASSOCIA- 

TION. Providers may be subtyped into INSTITUTION, HEALTH CARE PRACTICE, or others. An INSTITUTIONAL 

PROVIDER represents organisations providing health facilities such as hospitals and psychiatric institutions. A HE- 

ALTH CARE PRACTICE represents one or more individual health care practitioner who form a coalition to provide 

health care to patients. A NETWORK is a collection of HEALTH CARE PROVIDER ORGANISATIONS that are linked 

together to provide services under certain guidelines established by the organisation that set up the network. A GROUP 

is a collection of individuals who are classified within an organisation to receive coverage through the organisation. 

Typical groups are EMPLOYER, THIRD PARTY ADMINISTRATOR, INSURANCE PROVIDER, PAYOR (organisation 

that pays for the claims), and HEALTH CARE ASSOCIATION. 

Insurance is a major constituent of health care. A person may be insured for health care. The INSURED PARTY 

role captures information about people or organisations that have insurance. The INSURED ORGANISATION is the 

organisation that is insured and covers individuals for health care. It may also play the role of an EMPLOYER. INSU- 

RED INDIVIDUALS are important to track for proper insurance reimbursement. The INSURED CONTRACT HOLDER 

is the main party that is covered for the insurance. The INSURED DEPENDENT is a person being covered for a policy 

in addition to the insured contract holder. 

An alternative model could also to be include the INSURED ORGANISATION as a subtype of the ORGANISATION 

ROLE and the INSURED PERSON as a subtype of PERSON ROLE. Because there is probably more common information 

about the insurance information surrounding these parties, the decision to sub-type based on the INSURANCE 

PARTY has been preferred. 

We observe in applications a number of standard relationships such as ORGANISATION CONTACT RELATION- 

SHIP, SUPPLIER RELATIONSHIP EMPLOYMENT, ORGANISATION ROLLUP. The FAMILY DEPENDENCY is a typical 

example of a HOUSEHOLD MEMBERSHIP. Health care uses also some specific relationship types such as PATIENT 

PRACTITIONER RELATIONSHIP, PATIENT PROVIDER RELATIONSHIP, PRACTICE AFFILIATION, and PROVIDER 

NETWORK. A doctor may act as a primary care provider (PCP). The PATIENT PROVIDER RELATIONSHIP identifies 

which patients are with which HEALTH CARE PROVIDER ORGANISATION. The PRACTICE AFFILIATION type identifies 

which INDIVIDUAL HEALTH CARE PRACTITIONERS are associated with which HEALTH CARE PROVIDER 

ORGANISATION. 

People and organisations may play a variety of roles. The PARTY ROLE type stores the kind of role somebody 

may play. The PARTY RELATIONSHIP type links roles to relationships that exist between parties. A party has in a 

certain party role a party relationship with another party and its role. 

Health care facilities such as HOSPITAL, OFFICE, ROOM, CLINIC are used in health care. Therefore, we use the 

generic type FACILITY that combines these facilities. Additional subtypes of FACILITY are MEDICAL BUILDING, 

AMBULATORY SURGERY CENTER, and FLOOR. We might also include specific facilities such as BED, which would 

be related to ROOM. 

PATIENT, INDIVIDUAL HEALTH CARE PRACTITIONER, HEALTH CARE PROVIDER ORGANISATION are typical 

examples of PARTY ROLE. The PARTY QUALIFICATION and PARTY SKILL are associative types that maintain 

the competencies and background expertise for PARTY. To avoid redundancy we introduce the SKILL TYPE and 

QUALIFICATION TYPE that allow to collect all related information into one type. 

Health care is also based on LICENCE restrictions that are valid for certain states or a GEOGRAPHIC BOUNDARY 

for which the licence may apply. 

Specific patient information may be kept in types such as MEDICAL CONDITION and PHYSICAL CHARACTERI- 

STIC. 

Health care products. 

Health care organisations still consider themselves as being service-oriented. They are service providers, they 

perform procedures, offer diagnoses, and help patients through their time and expertise. What about pharmaceuticals, 

supplies, and medical equipment they may offer? Therefore they offer at the same time goods and services. We thus 

IS ADD


may generalise services and goods to Products. To be more neutral we model them by by HEALTH CARE OFFERING. 

It contains however typical product characteristics such as supplier product, inventory item storage, price components, 

cost components, and price components. 

Health care orders. 

Health care shipments and delivery. 

Health care claims. 

Payment settlement. 

Health care referral. 

Reporting schemata. 

Reporting schemata are typically OLAP cubes. OLAP cubes can be represented by relationship types which components 

are OLAP dimensions and which attribute types are derived functions [LST99, LT09]. 

Cubes used for health applications analyse how successful the health care enterprises have been treating patients. 

These cubes need to support the following: 

Financial analysis: Balance sheets and statement trends allow to determine trends on the income and the profitability 

over time, incident types, patient types, health care practitioner types etc. 

Human resource analysis: Employees can be classified regarding age, gender, marital status, position and other 

demographic information. 

Claims analysis: History of claims and settlements can be classified regarding service codes, types of diagnosis, 

episode types, geographic areas, dates, and payors. Trend analysis allows an insight what types of health care 

deliveries have been reimbursed and allows to predict what to expect regarding insurance receipts. 

Health care delivery outcome analysis: The outcome of health care deliveries can be analysed under various circumstances. 

Health care episode outcome analysis: The outcome of different kinds of health care episodes is of specific interest 

depending on various circumstances. 

The cube in Figure 45 accommodates the last need of analysis. It allows for instance to analyse the positive outcomes 

of health care treatment. Questions such as “How successful have health care treatments been in treating patients for 

particular health care episodes in particular regions and in dependence on treatment time?” can be answered. The fact 

type is represented as a relationship type and uses derived attribute types for the number of episodes, the number of 

health care visits, the average legnth of the episode, and the total charges associated with the episodes. The purpose 

of this relationship type is to provide measurements in order to analyse the success and lack of success for various 

health care episodes depending on eight dimensions. 

The dimension OUTCOMES provides an explicit representation of the outcome of the episode. This dimension 

OUTCOMES is used as a separation dimension. The seven other dimensions EPISODES, DIAGNOSES, INCIDENTS, 

TIMES, PRACTITIONERS, PROVIDES, and PATIENTS allow the analysis of health care episodes to be viewed under 

different conditions. These dimensions are used in the cube for clustering and are supported by drill-down, roll-up, 

dice and slice operations. For instance, the PATIENT dimension supports a separation of outcomes depending on the 

main characteristics of a patient. Typically dimensions are hierarchically structured. 

There are several issues to consider when deploying and using OLAP cubes within an application. What is the 

data volume that needs to be available in the cube? Which part of the cube must be materialised and which part of 

the cube may remain to be virtualised? Transformation processing time to create and to update the cube may go far 

beyond what can be tolerated. The data refresh frequency and the data transformation processing window size must 

be sufficient to meet the business needs. Therefore we need to determine the needs, the query issuing frequency and 

IS ADD


(0,n) 

(0,n) 

(0,1) 

(0,n) 

EPISODES 

ID, Description, ... 

■ 

PRACTITIONERS 

ID, Description 

Name(Last, ... First), 

✻ 

(0,1) 

✒ 

PROVIDERS 

ID, Description, 

Name, ... 

(0,1) 

(0,1) 

(0,1) 

(0,n) 

(0,n) 

DIAGNOSES 


INCIDENTS 


✛ 

✠ 

# Of 

Episodes HEALTH 

CAREEPISODE 

Total FACT 

Charges 

(0,1) 

Avg 

Length 

Of 

Episode 

❄ 

TIMES 

ID, Description, 

Day, Weak, Month, 

Quarter, Year 

(0,n) 

# Of 

Visits 

# Of 

Deliveries 

✲ 

❘ 

PATIENTS 


OUTCOMES 


(0,n) 

(0,n) 

(0,1) 

(0,1) 

Abbildung 45: The Star Schema for Health Care Episode Outcome Analysis 

the response time behavior in such applications. Depending on the infrastructure, the cube may be build on one server 

or may be distributed within a network of servers. Therefore we need to consider the computation time within the 

distribution. Object-level security needs may increase transformation processing time and thus may make it harder to 

meet processing window schedules. 

Data to be represented in an OLAP schema may have various meta-properties. These meta-properties are often 

dumped into the schema. This approach leads to schemata that are combinatorially exploding 9 . It seems to be more 

appropriate to explicitly separate the dimensions within a schema. Such approach is useful for surveying, zooming, 

landmarking, and querying the schema and for generating abstractions on the schema. 

OLAP cubes typically have a number of dimensions. We observe that these dimensions can be separated into: 

(A) Specialization dimensions that reflect the specific kinds of things represented with in a schema. 

(B) Associations to related types bind the objects at the different levels of detail and are typically represented by 

snowflake associations or integrity constraints. Associations among stars and snowflake types may be strict and 

thus glue types tightly together or may be volatile, i.e. may be released whenever it is necessary. 

(C) Usage of data in business processes results in different levels of granularity and precision of data. 

(D) Data history and source for storing the acquisition of data results in a different data quality. 

The mind map in Figure 46 represent the main dimensions for star types. 

Objects and things they represent do not exist as stand-alone concepts. They are related to other objects and they 

have a context in applications. We observe at least four main categories of dimensions in schemata that form the 

context of the star and snowflake types: 

Schema and units associated: Associations are modelled on the basis of bridges or hinges. They related units in 

the schema with other units. Units are composed of star and snowflake sub-schemata. Units, thus, form a forest 

9 The schemata used in [Sch92] are often of this kind. The separation used there does not lead to a better surveyability. The meta-aspects 

blow up the schema to large schemata which seem to have a number of internal similarities among the types. 

IS ADD


Representational 

Restriction 

Data 

Existence Partiality Exception 

Subtype 

Contextual 

Source 

User 

Variation 

Hierarchy 

Role 

Accessibility 

Process 

Category 

Intrinsic 

Quality 

Qualitative 

Specialization 

TA Time 

Development 

User Time 

Temporality 

Dimensions 

Version 

Representation 

Validity Time 

Measure 

History 

Usage 

Association 

Related Types 

Dialogue step 

Meta-Association 

Actor 

Time 

Occasion 

Scene 

Actual 

Orthogonal 

Abbildung 46: Mind Map of Dimensions Used For Multi-Dimensional Structuring of Star Types 

IS ADD


of stars. The association among units forms a skeleton of the application. The skeleton abstracts from the 

internal structuring of the units and only relates units to other units. Medical applications such as discussed in 

[Tha00a] consists of three main units: 

• The unit Person combined the star type Personnel (of the hospital) with its subtypes Nurses, Physician, 

Surgeon, Guard, Research Assistent etc. with the star type Patient (with corresponding specialization 

types) to the cluster type Person. 

• The unit Organization contains the types Pharmacy, Department, Room, Special Room, Medical Equipment, 

Supplier Equipment, Labor etc. which are star types. The unit thus combines the star types to a more general 

ontological unit. 

• The unit Knowledge combines the snowflake type Disease (with Symptom, Disease Association etc.) 

with the snowflake type Drug that consists of a mixture of Factor. The last are related to each other by 

potential associations to diseases by the types May Cure, May Cause, May Aggravate etc.. 

The units have a number of hinges between them: 

• The work of physicians is recorded by types such as Examination Patient, Physician in Charge, Surgeon 

of, Observe Occurrence of Symptoms, and Diagnosis. 

• The treatment of patients is recorded by types such as Description of Medicine, Cure Record, Hospitalization, 

and Surgeon of. 

• Further, patients may be associated with the knowledge unit. Typical such associations are Sensitivity 

to Drug and Experimental Treatment. 

Therefore, the skeleton consists of the sub-schemata Person, Organization, Knowledge and connects these units 

by a number of hinge or bridge types. 

Source and acquisition: Source and acquisition is an orthogonal dimension. This dimension is applicable to all 

types of the schema. 

Time: The time context appears in a number of variants. We use storage time, validity time, display time, userdefined 

time, transaction time etc. The time context is applicable in a number of combinations. Sometimes it 

is necessary to use all these characterizations. It is often observed, however, that only one variant of the time 

context is necessary. 

Version: Versions show the life cycle of the objects under consideration. Versions can often be systematically structured 

by database system phases: 

• The initialization phase allows to develop objects storing initial information. Integrity constraints are 

applicable in a very limited form. 

• The production phase is the central phase considered in all database books. It consists of the runtime 

querying, runtime modification, runtime transaction management etc. 

• The maintenance phase is often not considered in classical database applications. It is, however, used in 

productive database applications for clarification of soft constraints, for maintenance of constraints that 

have been cut out from runtime maintenance and for changing the structuring and functionality of the 

entire database system. Maintenance phases are used in data warehouse applications for recharging the 

data warehouse with actual information. 

• The archiving phase is used for archiving the content of the database in a form that data relevant for 

historical information can easily be retrieved. Data modification is not allowed. The only modification 

operation is archive load by new changes. 

IS ADD


Security: Security concepts describe encipherment and encryption (keys, authentication, signatures, notarisation, 

routing control, access control, data integrity, and traffic padding) for data exchange. 

. 

Literatur 

[ALSS03] 

[Bie08] 

[Bis95] 

S. Abeck, P.C. Lockemann, J. Schiller, and J. Seitz. Verteilte Informationssysteme - Integration von 

Datenübertragungstechnik und Datenbanktechnik. dpunkt Verlag, Heidelberg, 2003. 

A. Bienemann. A generative approach to functionality of interactive information systems. PhD thesis, 

CAU Kiel, Dept. of Computer Science, 2008. 

J. Biskup. Foundations of information systems. Vieweg, Wiesbaden, 1995. In German. 

[Bör03] E. Börger. The ASM refinement method. Formal Aspects of Computing, 15:237–257, 2003. 

[Bra00] M. H. Brackett. Data resource quality. Addison-Wesley, Boston, 2000. 

[BST06] 

[Cho82] 

[CMM02] 

[DGH03] 

[Fownn] 

[FvH89] 

[GCB + 97] 

A. Bienemann, K.-D. Schewe, and B. Thalheim. Towards a theory of genericity based on government 

and binding. In Proc. ER’06, LNCS 4215, pages 311–324. Springer, 2006. 

N. Chomsky. Some concepts and consequences of the theory of government and binding. MIT Press, 

1982. 

T. Calvo, G. Mayor, and R. Mesiar. Aggregation operators - New trends and applications. Physica, 

Heidelberg, 2002. 

S. Dustdar, H. Gall, and M. Hauswirth. Software-Architekturen für verteilte Systeme. Springer, Berlin, 

2003. 

M. Fowler. Analysemuster. Addison-Wesley, 1999, Bonn. 

C. C. Fleming and B. von Halle. Handbook of relational database design. Addison-Wesley, Reading, 

MA, 1989. 

J. Gray, S. Chaudhuri, A. Bosworth, A. Layman, D. Reichart, and M. Venkatrao. Data cube: A relational 

aggregation operator generalizing group-by, cross-tab, and sub-totals. Data Mining and Knowledge 

Discovery, 1(1):29–53, 1997. 

[GMUW00] H. Garcia-Molina, J. D. Ullman, and J. Widom. Database systems implementation. Prentice-Hall, 2000. 

[Gur00] Y. Gurevich. Sequnetial abstract-state machines capture sequential algorithms. ACM TOCL, 1(1):77– 

111, 2000. 

[Hay95] D. C. Hay. Data model pattern: Conventions of thought. Dorset House, New York, 1995. 

[HP97] L. J. Heinrich and G. Pomberger. Theorie und Praxis der Wirtschaftinformatik 9, 1997. 

[IZG97] W. H. Inmon, J. A. Zachman, and J. G. Geiger. Data stores, data warehousing and the Zachman 

framework. McGraw Hill, New York, 1997. 

[Jac06] M. Jackson. Problem frames. Pearson, Harlow, 2006. 

IS ADD


[Jac07] 

[Kas03] 

M. Jackson. Problem Frames: Analysing and structuring software development problems. Pearson 

Education, Harlowe, 2007. 

R. Kaschek. Konzeptionelle Modellierung. PhD thesis, University Klagenfurt, 2003. Habilitationsschrift. 

[KE96] A. Kemper and A. Eikler. Datenbanksysteme. Oldenbourg-Verlag, München, 1996. 

[Keren] 

[KM03] 

[Lib01] 

[LM78] 

J. Kerievsky. Refactoring to patterns. Addison-Weslay, 2005, München. 

M. Klettke and H. Meyer. XML & Datenbanken - Konzepte, Sprachen und Systeme. dpunkt.verlag, 

Heidelberg, 2003. 

L. Libkin. Expressive power of SQL. In J. Van den Bussche and V. Vianu, editors, Database Theory 

- ICDT 2001, 8th Intern. Conf., London, UK, Jan 4-6, 2001, Proc., LNCS 1973, pages 1–21. Springer, 

Berlin, 2001. 

P. C. Lockemann and H. C. Mayr. Computer-based information systems. Springer, Berlin, 1978. In 

German. 

[LS97] H.-J. Lenz and A. Shoshani. Summarizability in OLAP and statistical databases. In SSDBM IX, 1997, 

Washington, 1997. 

[LST99] J. Lewerenz, K.-D. Schewe, and B. Thalheim. Modeling data warehouses and OLAP applications 

by means of dialogue objects. LNCS 1728, pages 354–368, Paris, France, Nov. 15-18, 1999, 1999. 

Springer, Berlin. 

[LT01] 

[LT09] 

H.-J. Lenz and B. Thalheim. OLAP Databases and Aggregation Functions. In Proc. 13th Intern. Conf. 

on Scientific and Statistical Database Management, Jul 18-20, 2001, George Mason University, Fairfax, 

Virginia, USA, pages 91–100. IEEE Computer Society, 2001. 

H.-J. Lenz and B. Thalheim. A formal framework of aggregation for the OLAP-OLTP model. Journal 

of Universal Computer Science, 15(1):273 – 303, 2009. 

[MJ04] D. Marco and M. Jennings. Universal meta data models. Wiley Publ. Inc., 2004. 

[Noc04] 

C. Nock. Data Access Patterns - Database Interactions in Object Oriented Applications. Addison- 

Wesley, Boston, 2004. 

[Ols03] J.E. Olson. Data quality - The accuracy dimension. Morgan Kaufman, 2003. 

[Sch92] 

[Sch05] 

A.-W. Scheer. Architektur integrierter Informationssysteme - Grundlagen der Unternehmensmodellierung. 

Springer, Berlin, 1992. 

G. Schellhorn. ASM refinement and generalizations of forward simulation in data refinement: A comparison. 

Theor. Comput. Sci., 336(2-3):403–435, 2005. 

[Sie04] J. Siedersleben. Moderne Softwarearchitektur. dpunkt-Verlag, Heidelberg, 2004. 

[SIG97] 

L. Silverston, W. H. Inmon, and K. Graziano. The data model resource book. John Wiley & Sons, New 

York, 1997. 

[Sil01] L. Silverston. The data model resource book. Revised edition, volume 2. Wiley, 2001. 

[ST07] 

K.-D. Schewe and B. Thalheim. Development of collaboration frameworks for web information systems. 

In IJCAI’07 (20th Int. Joint Conf on Artificial Intelligence, Section EMC’07 (Evolutionary 

models of collaboration), pages 27–32, Hyderabad, 2007. 

IS ADD


[Tha91] B. Thalheim. Dependencies in relational databases. Teubner, Leipzig, 1991. 

[Tha00a] 

[Tha00b] 

B. Thalheim. Entity-relationship modeling – Foundations of database technology. Springer, Berlin, 

2000. 

B. Thalheim. The person, organization, product, production, ordering, delivery, invoice, accounting, 

budgeting and human resources pattern in database design. Technical Report Preprint I-07-2000, Brandenburg 

University of Technology at Cottbus, Institute of Computer Science, 2000. 

[Tha03] B. Thalheim. Visual sql - an er based introduction into database programming. Technical Report 08/03, 

Brandenburg University of Technology at Cottbus, Insitute of Computer Science, May 2003 2003. 

[VS00] 

[Wal97] 

P. Vassiladis and S. Skiadopoulos. Modeling and optimization issues for multidimensional databases. 

In Proc. CAiSE’2000, LNCS 1789, pages 482–497. Springer, Berlin, 2000. 

C. Wallace. The semantics of the Java programming language. Technical Report CSE-TR-355-97, 

University of Michigan, EECS Dept., December 1997. 

[Wis01] P. Wisse. Metapattern - Context and time in information models. Addison-Wesley, Boston, 2001. 

IS ADD






D - 24098 Kiel 

 





2. Strukturierung von IS ab SS 2012 


Forschung 



1 Einführung 

In den Vorlesungen werden vier zentrale Spezifikationssprachen zur Spezifikation von Informationssystemen im 

Co-Design-Zugang vorgestellt: die Strukturierung und die Funktionalität auf der Grundlage des erweiterten Entity- 

Relationship-Modellen HERM, die Verteilung auf der Grundlage der Verteilungsspezifikationsprache DistrLang und 

die Spezifikation durch die Web-Informationssystem-Spezifikationssprache SiteLang. 

Übungen: jeweils eine Übung zur Spezifikation der Strukturierung, zur Spezifikation der Funktionalität, zur Spezifikation 

der Medientypen und zur Spezifikation der Interaktivität. 

Es werden die Systeme ERWin und Silverrun, sowie DBMain zur Modellierung der Strukturierung bzw. Funktionalität 

eingesetzt. 

2 Strukturierung von Informationssystemen 

Strukturierung = Struktur + statische Integritätsbedingungen (+ Modellinhärentes !!!) 

HERM : higher-order entity-relationship model 

EER : extended ER model (meist auch nur für die Definition der Struktur(ierung) genutzt!!!) 

Bemerkung: Modell meint hier eigentlich Sprache. 

Brief Survey: The Higher-Order Entity-Relationship Model (HERM). 

The entity-relationship model has been extended by more than three-score proposals in the past. Some of the extensions contradict other 

extensions. Within this chapter we use the higher-order (or hierarchical) entity relationship model (HERM). It is a special case of an extended 

entity-relationship model (EER) e.g. [EWH85, Gog94, Hoh93, Tha00]. 

The higher-order ER model used in this chapter has the following basic and extended modeling constructs: 

Simple attributes: For a given set of domains there are defined attributes and their corresponding domains. 

Complex attributes: Using basic types, complex attributes can be defined by means of the tuple and the set constructors The tuple 

constructor is used to define complex attributes by Cartesian aggregation. The set constructor allow construction of a new complex 

attribute by set aggregation. Additionally, the bag, the list, and the variant constructors can be used.

CAU zu Kiel, IfI, ISE, β 2. Strukturierung von IS ab SS 2012 152 

Entities: Entity types are characterized by their attributes. Entity types have a set of attributes which serve to identify the elements of the 

class of the type. This concept is similar to the concept of key known for relational databases. 

Clusters: A disjoint union · 

∪ of types whose identification type is domain compatible is called a cluster. Cluster types (or variant types) are 

well known in programming languages, but are often overlooked in database models, where this absence creates needless fragmentation 

of the databases, confusing mixing of generalization and specialization and confusion over null values. 

First-order relationships: First-order relationship types are defined as associations between single entity types or clusters of entity 

types. They can also be characterized by attributes. 

Higher-order relationships: The relationship type of order i is defined as an association of relationship types of order less than i or of 

entity types and can also be characterized by attributes. 

Integrity constraints: A corresponding logical operator can be defined for each type. A set of logical formulas using this operator can 

define the integrity constraints which are valid for each instance of the type. 

Operations: Operations can be defined for each type. 

• The generic operations insert, delete, and update are defined for each type. 

• The algebra consists of classical set operations, such as union, intersection, difference and restricted complement, and general 

type operations, such as selection, map (particular examples of this operation are (tagged) nest, unnest, projection, renaming), 

and pump (particular examples of this operation are the classical aggregation functions). The fixpoint operator is not used. 

• Each type can have a set of (conditional) operations. 

• Based on the algebra, query forms and transactions can be specified. 

The extensions of the ER model should be safe in the sense that appropriate semantics exist. There is a large variety of proposals which are 

not safe. Some reasons for this include higher-order or function types, such as those used for the definition of derived attributes, or the loss of 

identification. 

It can be observed that higher-order functions can be attached to the type system. However, in this case types do not specify sets, although 

their semantics can be defined by topoi [Sch94, Gol06]. This possibility limits simplicity for the introduction of constraints and operations. 

Furthermore, these semantics are far too complex to be a candidate for semantics. The ER model is simpler than OO models. 

Es taucht oft die Frage auf, ob dies adäquat ist. In [HL07] wurde dazu ein Vergleich von englischen Sprachäußerungen 

und dem HERM vorgenommen. Eine der Tabellen dazu ist die folgende 

English sentence concept HERM feature 

transitive verb 

relationship type 

common noun 

component of relationship type 

adjective 

attribute of component 

adverb 

attribute of relationship type 

numerical expression attribute of object type 

preposition 

role name of component 

gerund 

relationship type that is component of another relationship type 

clause 

relationship type with components 

complex sentence relationship type of order higher than 1 

alternative phrase cluster type 

plural collection type/nested attribute 

“IsA” sentence 

specialisation 

Comparison to Chen’s original correspondences by [HL07] 

Peter P.-S. Chen: English Sentence Structure and ER Diagrams, Inf. Sci. 29(2-3): 127-149, 1983 



English sentence ER feature 

concept 

transitive verb relationship type 

common noun entity type 

adjective 

attribute of entity type 

adverb 

attribute of relationship type 

numerical expression attribute of entity or relationship type 

gerund 

relationship-converted entity type 

clause 

high-level entity type abstracted from group of interconnected low-level entity and 

relationship types 

complex sentence one or more entity types connected by relationship type in which each entity type can 

be decomposed recursively into low-level entity types interconnected by relationship 

types 

Conclusions: 

EER reflects (English) sentence structures more soundly and naturally 

higher-order object types reflect dependence between sentences 

this provides justification for introduction of new ER features 

ER model does not just provide safe constructs that result in good database design, but also features that enable 

good communication between designer and user 

essential to best approximate requirements 

additional EER features justified in the sense that modelling becomes more natural 

provides also a justification why the EER features exist 

higher-order object types reminiscent of nested sentence structure in natural language text 

2.1 Spezifikation der Struktur von Datenbanken 

eine Vorlesung (da bereits in der Vorlesung Informationssystem in Grundzügen in abweichender Form behandelt) 

2.1.1 Modellierungsannahmen 

• Konstruktiver Aufbau mit kompositioneller Semantik 

damit dann auch induktive Sprache 

(inkrementelle Modellierung als resultierende Variante des Modellierens) 

Vorteil: die Semantik wird kompositional 

• Abstraktionsresistenz, Verfeinerungsstrategie (scaling depending on its modes (visibility (zoom), hierarchy 

(fold), manifestation (express, suppress))) 

Modularisierbarkeit als Option 

• Äquivalenzbegriff für Sprachkonstrukte 

• rigide Trennung von Klassen und Typen, aber 1-1-Bindung von Klassen an Typen 

• Abbildungseigenschaften 

• Wohlfundiertheit 

• Einschränkung auf Mengensemantik, keine Kollektionssemantik 

• Visualisierung 

• Skalierbarkeit/Modularisierbarkeit der Sprachäußerungen je nach Auffassungsmöglichkeiten 

Modularisierbarkeit als Option 

Modular modelling supports information abstraction and hiding by encouraging and facilitating the decomposition of systems [BM97] into components 



and their modular development based on a precise definition of interfaces and the collaboration of components through which the systems are put 

together. Implicit modularisation can be achieved by introduction of name spaces on signatures. Explicit modularisation offers a better understanding 

of structure and architecture of systems and thus supports consideration of evolution of systems and of collaboration of systems. 

Modularisation offers a number of advantages: separation of concerns, discovery of basic concepts, validation and verification of development, efficiency 

of tool support, and - last but not least - scoped changes. The last advantage of modularisation is based on an explicit framing of development to a number 

of elements while preserving all other elements in its current form. We model this impact by introducing name spaces on signatures. 

Typically, small submachines capture smaller models that are easier to understand and to refine. Small models can better be ascertained as to whether 

we need to apply refinements. 

Modularization is a specification technique of structuring large specifications into modules. It is classically based on structural and functional decomposition 

[BS00]. We additionally consider control decomposition. Modules form a lattice of associated submachines having their own states and their 

own control. 

Modularisation is based on implementation abstraction and on localization abstraction. Implementation abstraction selectively hides information about 

structures, semantics and the behavior of ASM concepts. Implementation abstraction is a generalization of encapsulation and scoping. It provides data 

independence through the implementation, allowing the private portion of a concept to be changed without affecting other concepts using that concept. 

Localization abstraction “factors out” repeating or shared patterns of concepts and functionality from individual concepts into a shared application 

environment. Naming is the basic mechanism for achieving localization. Parametrisation can be used for abstraction over partial object descriptions. 

We use the name space for handling localisation abstraction. 

• Agentorientierte Darstellung und damit Separation für verteilte Anwendungen 

A submachine consists of a vocabulary and a set of rules. In this case, any clustering of rules and of elements from the vocabulary may define a 

submachine. Turbo machines [BS03] capture our notion of a submachine by encapsulating elements of the vocabulary and rules into a machine. They 

hide the internals of subcomputations within a separate machine. The submachine has its own local state and its own interface. 

The set of functions of each submachine can be separated into basic and derived functions. Basic functions may be static functions or dynamic functions. 

Classically [BS03] dynamic functions can be classified as in(put) functions, out(put) functions, controlled or local functions that are hidden from the 

environment, and shared functions that are visible to the environment. A similar classification can also be applied to basic static functions. They are 

either functions only used by a its own machine or read by several environments. We thus extend the notion of shared and controlled functions to static 

functions as well. We do not use derived static functions since they can be considered as syntactic sugar. We differentiate these functions according to 

their role in Figure 1 which displays the functions internal for an agent machine. A similar classification can be developed for functions external to an 

agent. An agent machine consists of all functions that assigned to the agent and of rules that are assigned to the agent and that use only those functions 

assigned to the agent. 

function/relation/location 

basic 

derived 

static 

non-updatable 

by any agent 

controlled shared 

in (monitored) 

non-updatable 

by agent 

controlled 

updatable 

by agent 

dynamic 

shared (interaction) 

updatable 

by agent 

out 

updatable 

by agent 

indirectly 

monitored controlled indirectly indirectly 

shared 

Abbildung 1: The Kinds of Internal Functions for Agent Machines 

Static functions may also be local functions. They are not updated by any submachine. [BM97] distinguish derived function to whether these functions 

are monitored functions, controlled functions, or shared functions. Typically, derived functions are functions that do not exist on their own right, but 

may be dynamically computed from one or more base functions. They provide a powerful and flexible information hiding mechanism. Updates made 

in the base functions that affect the derived function are immediately reflected in derived functions. 

We may additionally assume that derived functions are allowed to update dynamic functions. In this case, dynamic functions may be used as a security 

mechanism, as an access mechanism, and as a simplification mechanism that allows to use complex derived functions in rules instead of complex 

computations in rules. 

• Perspektiven und Stile der Modellierung sind explizit wählbar 

Different modelling perspectives can be distinguished: 

1. The structure-oriented perspective focuses on structural description of the machine. Sometimes, the structure-oriented perspective is unified 

with the semantic perspective. In this case, design of the structure is combined with design of invariants. 

2. The behavior-oriented perspective is concerned with the behavior of the machine during its lifetime. It can be based on event approaches or on 

Petri-net approaches and predicate transition systems. 

3. The process-oriented perspective is concerned with the operation of the system. 



The structure-oriented perspective is often used for data-intensive applications. Almost all recognized database design approaches are based on the 

structure-oriented perspective. The process-oriented perspective uses approaches considered in software engineering. The behavior-oriented perspective 

is a high-level descriptive approach to an integrated specification of the vocabulary and rules. 

Modelling styles provide a very abstract description of a particular set of general characteristics of a model. Different constructional notations may be 

useful for describing a machine. We use the Turbo machine approach for component or submachine description. Typically, the role of the components 

of the system follow the rules specified by the style. The modelling style explains the structure, the abstraction and grouping of the elements. Parts of 

the system may follow different modelling styles. 

The style of modelling is a specification of the high level structure and organisation of system modelling. The structure describes the handling of 

elements of the vocabulary, the topology or relationships between elements, the semantical limitations for their usage, and the interaction mechanism 

between the elements such as blackboard, submodule calls,etc. The organisational style describes relevant local and global structures, the decomposition 

strategy, and control mechanisms between parts of the machine. The organisational style is based on the architectural style. It is our aim to maintain and 

to preserve the strategy over the life cycle of the system. 

The perspective and the style result in strategies that are use for step-wise development of specifications. The different strategies [Tha00] based on the 

structure-oriented perspective are sketched in Figure 2. 

structure-oriented strategies 

✙ 

flat 

second-order 

controlled 

(first-order) 

(uncontrolled) 

(one-dimensional) 

✠ ❘ ✠ ❘ 

mixed 

modular 

✠ 

❘ (skeleton-based flat) (design by modules) 

bottom-up 

1. design all 

basic concepts 

2. build more 

complex concepts 

from them 

top-down 1. design general 

module schema 

(bottom-up or top-down) 

1. design (skeleton) 

all main concepts 

2. refine concepts 

2. refine each module 

(bottom-up or 

top-down) 

1. design basic modules 

with interface 

2. (iteration step) 

connect modules 

or design 

combined modules 

Abbildung 2: Structure-Oriented Specification Strategies 

inside-out 

(by neighborhood) 

1. design central type 

2. (recursion step) 

design next level 

(bottom-up or 

top-down) 

design or attach 

concept 

• Integritätsbedingungen werden anhand von Mustern definiert und eingesetzt 

Invariants, e.g. integrity constraints in database applications, are used to define semantics of applications. We know different pattern for their specification: 

• Operational representation of invariants incorporates invariants into the programs or rules. The invariant enforcement mechanism may be hidden 

because of control conditions or to the specification of actions. 

• Descriptive representation uses explicit specification and refinement obligations. These descriptions are combined with the specification of 

invariant enforcement: 

• Eager enforcement maintains invariants based on a scheduling mechanism for maintenance of invariants. Transactional systems are typical 

scheduling mechanisms. They bind invariant enforcement to programs. 

• Lazy enforcement maintains invariants in a delayed mode. Inconsistency is temporarily tolerated. This tolerance reduces some of the cost 

of enforcing invariants within large structures. 

• Refusal enforcement maintains invariants by rollback of all activities since the last consistent state and by executing a subset of activities. 

Partially ordered runs are based on refusal enforcement. 

Depending on the pattern chosen invariant handling is varies. If we choose an implicit invariant handling then any change applied to the current ASM 

must explicitly consider all invariants and must be entirely aware of the effects of these. Therefore this pattern is the most inefficient for early design 

phases. This pattern is however applicable during implementation if later revision is going to be based on a more general ASM. 

The completeness of invariant specification is a dream that is never satisfied. Sets of invariants are inherently open since we cannot know all invariants 

valid in the current application, we cannot envision all possible changes in invariant sets, and we cannot choose the most appropriate selection of 

invariants from which all other invariants follow. Therefore, we use a separation into 

• hard (or iron) invariants that must be preserved and which are valid over a long time in the application and 

• soft invariants that can be preserved or are causing later corrections or which are not valid for a longer time in the application. 

Unterschiedliche HERM-Annahmen je nach Abstraktionsschicht 

• mit Identifikation 



• mit partiellen Constraintmengen (z.B. nur ein Schlüssel) 

• Schemavollständigkeitskriterium 

Pragmatische strikte Unterscheidung 

Wir unterscheiden in modernen Sprachen zwischen 

Einführung von Variablen, Daten, die damit auch Rechte an der Modifikation und am Auslöschen mit einschließt, 

Mitnutzung von Variablen, Daten, die immer eine entsprechende Koordination mit einschließt und 

Mitbenutzung von Variablen, Daten etc., die keine Rechte an Modifikation und Auslöschen einschließt! 

siehe auch Handbook, HERM-Kapitel 

Implicit Assumptions and Inherent Constraints of DB Specification Languages. 

Each language used should be based on a clear definition of structure, semantics, operations, behavior and environment. At the same time, 

languages presuppose implicit assumptions and constraints. The enhanced or extended ER (EER) model might, for instance, use the following 

assumptions: 

Set semantics: The default semantics of entity and relationship types are set semantics. If extended type constructors are used then their 

semantics are explicitly defined. 

Identifiability: Each entity type is identifiable. Each component type needs to be labelled whenever it cannot be distinguished from 

other components. In relationship types components are ordered. Their labels can be omitted whenever there is an identification. Set 

semantics implies identifiability of any element in the database. 

Partial Unique Name Assumption: Attribute names are unique for each entity and relationship type. Entity type names and relationship 

type names are unique for the ER-schema. 

Referential Integrity: If a type is based on component types then each value for this type can only use such values in components which 

exist as values in the component instance. 

Monotonicity of Semantics: If integrity constraints Φ are added to a given set of integrity constraints Σ, then the set of possible 

instances which satisfy the extended set of constraints Σ ∪ Φ is a subset of the set of instances which satisfy Σ. 

Resulting coincidence theorems as a matter of convenience. 

Storage and Representation Alternatives. 

The classical approach to objects is to store an object based on strong typing. Each real-life thing is thus represented by a number of 

objects which are either coupled by the object identifier or by specific maintenance procedures. This approach has led to the variety of types. 

Thus, we might consider two different approaches: 

Class-wise, strongly identification-based representation and storage: Things of reality may be represented by several 

objects. Such choice increases maintenance costs. For this reason, we couple things under consideration and objects in the database 

by an injective association. Since we may be not able to identify things by their value in the database due to the complexity of the 

identification mechanism in real life we introduce the notion of the object identifier (OID) in order to cope with identification without 

representing the complex real-life identification. Objects can be elements of several classes. In the early days of object-orientation it 

was assumed that objects belonged to one and only one class. This assumption has led to a number of migration problems which have 

not got any satisfying solution. The association among facets of the same thing that are represented by several objects is maintained by 

the object identifier. 

Object-wise representation and storage: Graph-based models which have been developed in order to simplify the object-oriented 

approaches [BT99] display objects by their sub-graphs, i.e. by the set of nodes associated to a certain object and the corresponding 

edges. This representation corresponds to the representation used in standardization. 

Object-wise storage has a high redundancy which must be maintained by the system thus decreasing performance to a significant extent. Beside 

the performance problems such systems also suffer from low scalability and poor utilization of resources. The operating of such systems leads 

to lock avalanches. Any modification of data requires a recursive lock of related objects. 

Therefore, objects-wise storage is applicable only under a number of restrictions: 

• The application is stable and the data structures and the supporting basic functions necessary for the application do not change during 

the lifespan of the system. 



• The data set is almost free of updates. Updates, insertions and deletions of data are only allowed in well-defined restricted ‘zones’ of 

the database. 

A typical application area for object-wise storage is archiving or information presentation systems. Both systems have an update system 

underneath. We call such systems play-out system. The data are stored in the way in which they are transferred to the user. The data 

modification system has a play-out generator that materializes all views necessary for the play-out system. 

Two implementation alternatives are already in use albeit more on an intuitive basis: 

Object-oriented approaches: Objects are decomposed into a set of related objects. Their association is maintained on the basis of 

OID’s or other explicit referencing mechanisms. The decomposed objects are stored in corresponding classes. 

XML-based approaches: The XML description allows to use null values without notification. If a value for an object does not exist, 

is not known, is not applicable or cannot be obtained etc. the XML schema does not use the tag corresponding to the attribute or the 

component. Classes are hidden. Thus, we have two storage alternatives for XML approaches which might be used at the same time or 

might be used separately: 

Class-separated snowflake representation: An object is stored in several classes. Each class has a partial view on the 

entire object. This view is associated with the structure of the class. 

Full-object representation: All data associated with the object are compiled into one object. The associations among the 

components of objects with other objects are based on pointers or references. 

We may use the first representation for our storage engine and the second representation for out input engine and our output engine 

in data warehouse approaches. The input of an object leads to a generation of a new OID and to a bulk insert into several classes. The 

output is based on views. 

The first representation leads to an object-relational storage approach which is based on the ER schema. Thus, we may apply translation 

techniques developed for ER schemata[Tha00]. 

The second representation is very useful if we want to represent an object with all its facets. For instance, an Address object may be 

presented with all its data, e.g., the geographical information, the contact information, the acquisition information etc. Another Address 

object is only instantiated by the geographical information. A third one has only contact information. We could represent these three 

object by XML files on the same DTD or XSchema. 

Grundlegende Strukturbeziehungen 

Modellierung muß ist auch eine Ingenieursdisziplin. Deshalb werden auch die Engineering-Annahmen des Einführungskapitels 

betrachtet. 

The four fundamental structural relations used for construction abstraction are: 

Aggregation/participation characterizing which object consists of which object or resp. which object is part of 

which object. 

Aggregation is based on constructors such as sets, lists, multisets, trees, graphs, products etc. It may include 

naming. 

Generalizeation/specialization characterizing which object generalizes which object or resp. which object specializes 

which object. 

Hierarchies may be defined through different classifications and taxonomies. So, we may have a different 

hierarchy for each point of view. 

Hierarchies are built based on inheritance assumptions. So, we may differentiate between generalization and 

specialization in dependence on whether characterization are not or are inherited and on whether transformation 

are or are not applicable. Qualifications may form their orthogonal hierarchy (e.g., Bachelorette for Female and 

Single and Bachelor for Male and sl Single). 

Exhibition/characterization specifying which object exhibits which object or resp. which object is characterized 

by which object. 

Exhibitions may be multi-valued depending of the data type used. They may be qualitative or quantitative. 

Classification/instantiation characterizing which object classifies which object or resp. which object is an instance 

of which object. 



Modes of States. 

• Initial 

• Ultimate 

• Default 

Generalisation und Spezialisierung sind besser zu unterscheiden 

Aus der Enzyklopädie der Datenbanksysteme: Langfassung hier (in Enzyklopädie: Kurzfassung 

Specialisation and Generalisation. 

Definition 1 The generalisation and specialisation principles are main principles of database modelling. Generalisation maps or groups 

types or classes to more abstract or combined ones. It is used to combine common features, attributes, or methods. Specialisation is based on 

a refinement of types or classes to more specific ones. It allows to avoid null values and to hide details from non-authorised users. Typically, 

generalisations and specialisations form a hierarchy of types and classes. The more general types or classes may be bound by a mapping or by 

inheritance of attributes and methods from the more general one to the more special ones. Clusters of types to a type that represents common 

properties and abstractions from a type are the main kinds of generalisations. Is-A associations that specialise a type to a more specific one 

and Is-A-Role-Of associations that considers a specific behaviour of objects are the main kind of specialisations used in database modelling 

and implementation. 

Specialisation introduces a new entity type by adding specific properties belonging to that type which are different from the general 

properties of its generic type. Thus, generalisation introduces the Role-Of relationship or the Is-A relationship between a subtype and its 

generic type. Therefore, the constructs are different. For generalisation the generic type must be the union of its subtypes. Thus, the subtypes 

can be virtually clustered by the generic type. This tends not to be the case for specialisation. Specialisation is a refinement or restriction of 

a type to more special ones. Typical specialisations are Is-A and Has-Role associations. Exceptions can be modelled by specialisations. We 

distinguish different kinds of specialisation: 

Structural specialisation T ′ ≼ St T : The structure S ′ is a substructure of S. An embedding function η exists which relates each object in 

T ′ to one object in T . For instance, the tuple structure (A, B, C) is a substructure of (A, B). In addition, structural specialisation requires that 

according to η the class T ′C of the type T ′ is a subclass of T C , i.e., we require that for each o ′ ∈ T ′C an o ∈ T C exists such that o = η(o ′ ). 

The relationship among objects can be supported by identifiers or keys. In this case the subtype uses the identifier and keys and provides 

additional attributes and methods. 

Semantic specialisation T ′ ≼ Se T : The logical language of T ′ can be mapped onto the logical language of T in such a way that the 

constraints on T ′ are stronger than the constraints on T , i.e., a mapping θ from L T ′ to L T exists such that θ(Σ ′ s) |= Σ s . The constraints used 

in T ′ are stronger than those used in T . 

The constraint sets of types are partitioned into static constraints Σ s (applicable to elements of the type sets) and dynamic constraints Σ d 

(applicable to operations of the types). 

The strong semantic specialisation T ′ ≼ St,Se T is defined on the basis of both mappings η and θ whereas θ is created using η as the 

mapping primitive. 

Pragmatical specialisation T ′ ≼ P r T : Objects may be used in different contexts. Pragmatical specialisation allows to separate the 

different usage of objects in contexts. The identification of objects is not changed. Therefore pragmatical specialisation can be based on 

structural specialisation. We require that the additional properties of objects in T ′C represent the additional properties that context requires. 

Operational specialisation T ′ ≼ Op T : The operations defined for T can also be applied to T ′ objects. 

The strong operational specialisation T ′ ≼ St,Op T requires that mappings η : Struc ′ → Struc, θ : L T ′ → L T and ζ : Ops ′ → Ops 

exist which commute, i.e., for any n-ary operation o ′ from Ops and arbitrary objects o ′ 1, ..., o ′ n from T ′ t the equality η(o ′ (o ′ 1, ..., o ′ n)) = 

ζ(o ′ )(η(o ′ 1), ..., η(o ′ n)) and ζ(θ(Σ ′ d)) |= Σ d . 

Type specialisation T ′ ≼ T ype T requires strong operational and strong semantic specialisation. 

Is-A specialisation T ′ Is − A T requires structural and strong semantic specialisation. Is-A relationship (types) are typical semantical 

specialisations. We require that the properties of objects in T ′C specialise those in T C or are not applicable to T . 

Is-A-Role-Of specialisation T ′ Is − A − Role − Of T requires structural, pragmatical and strong semantic specialisation. We require that 

the additional properties of objects in T ′C represent the additional properties that context requires. 



Generalisation can be treated in a similar manner and is based either on abstraction or on grouping. The cluster construct of the 

extended ER model is used to represent generalisations. Generalisation tends to be an abstraction in which a more general (generic) type is 

defined by extracting common properties of one or more types while suppressing the differences between them. These types are subtypes 

of the generic type. New types are created by generalizing classes that already exist. Typical such feature abstractions are the separation or 

extraction of constructors, destructors, and identification from the rest of the type. Similarity of attributes or methods may be used for the 

development of more abstract ones. Grouping allows to combine types that partially share properties or methods into a new type that represents 

the commonalities. 

We thus consider structural combination, semantical combination, and pragmatical combinations of types into a more general one. 

Structural combination typically assumes the existence of a unifiable identification of all types. Typically unambiguity is assumed, i.e. the 

combination is based on a disjoint union of the types. Semantical combination allows the disjunction of types through the linear sum of 

semantics. Pragmatical generalisation is based on building collections whenever applications require a consideration of commonalties. 

Abstraction is the opposite of refinement. In this case, generalisation can been seen as the inverse of specialisation. The main difference is 

however which of the types has a practical relevance or importance. Kernel types can be generalised to more general types by abstraction from 

some attributes or methods, by consideration of generic methods with parameters that are mapped to the kernel type methods by instantiating 

parameters or by introduction of more general attributes. 

Generalisation and specialisation are supported by inheritance of properties and methods. It helps to factor out shared specifications 

and implementations. Type inheritance is defined on the basis of the definition of types and can be further partitioned into aggregation/decomposition 

inheritance, classification/instantiation inheritance and generalisation/specialisation inheritance. Localisation inheritance is 

based on localisation abstraction. Naming, parametrisation and binding are basic mechanisms to extract repeating or shared patterns. Implementation 

inheritance is concerned with the encapsulation and hiding of types. A typical kind of implementation inheritance is that of the 

operational environment of a type. Interface inheritance or view inheritance can cause some confusion since these can reverse other inheritance 

approaches, e.g. inclusion inheritance. Object-oriented databases allow four different kinds of inheritance: Substitution inheritance, inclusion 

inheritance, constraint inheritance, and specialisation inheritance, 

Specialisation and generalisation are based on the concept of refinement. We may use refinement steps such as refinement through instantiation 

replacing types by partially instantiated, refinement through separation using decomposition operators enabling in vertical or horizontal 

decomposition, refinement through specialisation specializing types to structurally, behaviorally or semantically more specific subtypes, and 

refinement through structural extension extending types by other components, additional semantical constraints or functions. 

B. Thalheim. Entity-relationship modeling – Foundations of database technology. Springer, Berlin, 2000. 

J. H. Ter Bekke. Semantic data modelling. Prentice-Hall, London, 1992. 

J. C. Mitchell. Type systems for programming languages. In J. Van Leeuwen, editor, Handbook of Theoretical Computer Science, 

Vol. B - Formal Models and Semantics, pages 365–458. Elsevier, Amsterdam, 1990. 

Modellierungsstil im HERM 

Aus den Annahmen heraus können wir uns einen spezifischen Modellierungsstil leisten: 

Mengensemantik als präferierte Semantik obwohl auch eine Listensemantik oder eine Referenzsemantik nicht ausgeschlossen 

ist 

Modularisierung innerhalb der Spezifikation als eine strukturelle Separation von Aspekten 

Bevorzugung der struktur-orientierten Spezifikation gegenüber der prozeß-orientierten Spezifikation 

Inhärente Unvollständigkeit der Spezifikation wird toleriert. 

Agenten-orientierte Spezifikation für verteilte Anwendungen mit expliziter Separation der Einheiten des gesamten 

Namensraumes der Modelle in 

• Input-Einheiten 

• Sharing-Einheiten 

• Control-Einheiten und 

• Output-Einheiten 

IS als Transaktionssysteme mit resultierender Steuerung und Ableitbarkeit von Informationen aus Daten 

anstatt eines prozeduralen Systemes 



Resultierende Annahmen. 

• Grunddatentypen werden als unstrukturiert vorausgesetzt 

in OLAP-Anwendungen ist dies nicht mehr aufrecht zu erhalten!!!!!! 

• Pragmatik der Typeneindeutigkeit für jede Einheit 

z.B. Typen sind entweder Attribut- oder ... Cluster-Typen 

• Eine linguistische Semantik der Namen für Einheiten kann verwendet werden. 

Es wird dazu ein Stil der Benennung im Vornherein vereinbart und dann eingehalten. 

Wir verwenden damit für alle Namen eine Minisemantik. 

• Es wird eine Pragmatik für die Repräsentation zugelassen und vorher vereinbart. 

• Wir unterscheiden explizit zwischen Rolle und Objektexistenz. 

Kern-Objekte sind in der Existenz unabhängig und werden durch Entity-Typen dargestellt. 

An object is a thing that has the potential of stable, unconditional physical or mental existence. 

Existence is derived from ‘be’, ‘have being’, ‘continue to be’. Existence means to stand out, to show 

itself, and have a identifiable, distinct uniqueness with the physical or mental realm.(D.Dori, Websters 

dictionary) 

2.2 HERM-Strukturen 

Abstrakter Datentyp mit allen Eigenschaften der Grunddatentypen 

Finiteness Granularity Expression 

Textual Symbolic Numeric 

Finite Discrete Text-enumerated Symbol-enumerated Integer-enumerated 

Continuous - Symbol-floating-enumerated Floating-enumerated 

Infinite Discrete - - Integer 

Continuous - - Floating-point 

Eine Sprache zur Beschreibung der Strukturierung von Datenbank-Anwendungen verfügt über Konstrukte zur 

Darstellung der Struktur einer Anwendung. Falls diese Sprache nicht-zyklisch und induktiv aufgebaut ist, ist damit 

auch eine Einbettung in die Sprache der Prädikatenlogik (der ersten Stufe) gegeben. Deshalb lassen sich dann statische 

Integritätsbedingungen als Formeln der Prädikatenlogik mit einer Standardinterpretation angeben. Mit der 

Sprachkonstruktion und mit Annahmen aus dem Umfeld werden implizite Integritätsbedingungen aufgenommen. Die 

Sprache zur Beschreibung der Strukturierung von Datenbanksystemen wird genutzt, um diese mit einem sogenannten 

Datenbank-Schema zu beschreiben. Inhalte eines statischen Modelles sind daher: 

Strukturen einer Anwendung, 

Statische Integritätsbedingungen einer Anwendung (meist für die zusätzliche Beschränkung evt. in einer Anwendung 

vorkommender Daten) und 

Common-sense-Annahmen (über das Modell, die Modellierungsart, über die Interpretation der Daten etc.). 

Damit wird das Wissen über die statischen Gesichtspunkte einer Anwendung modelliert durch: 

Die Spezifikation der Struktur in Abhängigkeit vom Typensystem mit der Spezifikation des Seienden (entity), der 

Beziehungen (relationship) und der Eigenschaften (Attribute). 

Dinge stehen in Beziehung bzw. besitzen Eigenschaften, die klassifiziert werden durch eine Rolle oder durch 

Klassenbildung. 

Die Gesamtheit der Dinge wird unter Berücksichtigung der Beziehungen untereinander modelliert: 



• Aussonderung (Separation/Spezialisierung), 

• Verallgemeinerung (Generalisierung von Gemeinsamkeiten) und 

• Aggregation (zur Darstellung komplexerer Daten mit entsprechenden Operationen). 

Die Spezifikation der statischen Semantik, d.h. durch einschränkende Bedingungen für wirklichkeitsgetreue Nachbildung 

der Anwendung wie 

• die eindeutige Bestimmung aller Objekte durch Schlüsselbedingungen, 

• die Hierarchie der Objekte (Aussonderungsbedingungen (specialization, IsA), Verallgemeinerungsbedingungen 

(partition constraints, uniqueness constraints)) 

• und Bedingungen für Beziehungsklassen wie die folgenden: 

• Darstellung eines funktionalen Zusammenhangs (viele-eins-Bedingung), 

• Bedingungen zur Assoziation mit Komponentenobjekten (Seinsbedingung (existence constraint)) 

und 

• Verweisbedingungen auf Objekte der Komponentenklassen, 

sowie 

• allgemeine Bedingungen (inhärente Bedingungen des Modells) wie die folgenden: 

• Gesamtheitsregel (universe of discourse) 

• Verneinungsregel 

Sichten und abgeleitete Begriffe sind erschließbare Objekte und werden durch Anwendung von Spezifikationen aus 

den Objekten der Datenbank erzeugt. 

Das allgemeine Vorgehen der statischen Datenbankmodellierungssprachen läßt sich somit wie folgt charakterisieren: 

• Typen sind über ihre Typausdrücke definiert. Den (freien) Variablen werden wiederum Typen zugeordnet. 

• Die Zuordnungsvorschrift für Typausdrücke kann sowohl hierarchisch als auch zyklisch sein. Wählt man 

eine zyklische Struktur, dann sind meist nur Topoi-Semantiken geeignet. Wählt man hierarchische 

Strukturen, dann kann meist eine Mengensemantik noch garantiert werden. 

• Typen haben eine assoziierte statische Semantik. 

• Typen haben Operationen zu ihrer Manipulation und Veränderung. Man kann diese Operationen generisch 

definieren, wenn die Typenstruktur hierarchisch aufgebaut ist. Einige Operationen können auch Prädikate 

sein. 

A type constructor is a function from types to a new type. The constructor can be supplemented 

• with a selector for retrieval (like Select) with a retrieval expression and update functions (like Insert, 

Delete, and Update) for value mapping from the new type to the component types or to the new type, 

• with correctness criteria and rules for validation, 

• with default rules, 

• with one or several user representations, and 

• with a physical representation or properties of the physical representation. 

• Klassen sind Typen zugeordnet. 

• Sie stellen “Container” für die Objekte des jeweiligen Typs dar. 

• Die assoziierte statische Semantik der Typen muß zu jedem Zeitpunkt für eine Klasse erfüllt sein. 



• Die Operationen der Typen werden auf Klassen ausgeführt. 

Wir bezeichnen Typen mit ihrem Namen, z.B. T und die zugehörigen Klassen mit einer Annotation zum Typennamen, 

z.B. T C (C steht für Klasse). 

Es sind verschiedene Modelle möglich. Jedes Modell ist durch eine Menge von inhärenten Bedingungen gekennzeichnet. 

Jeder benutzte Typ hat neben Konstruktor, Selektoren (für Retrieval) und Updatefunktionen, Korrektheitskriterien, 

default-Regeln auch eine Benutzerrepräsentation und eine physische Repräsentation. 

Günstig ist eine graphische Repräsentation. 

Eines der populärsten Modelle ist das Entity-Relationship-Modell. Wir erweitern dieses Modell zu einem 

Higher-Order Entity-Relationship-Modell (HERM). 

2.2.1 Attribut-Typen 

können einfache oder auf der Grundlage von Konstruktoren wie Mengenkonstruktor, Tupelkonstruktor, Listenkonstruktor, 

Multimengenkonstruktor induktiv konstruierte komplexe Attribut-Typen sein. Sie werden induktiv definiert: 

Basis-Datentypen sind parametrisierte Typen T = (dom(T ), ops(T ), pred(T )) des DBMS. Sie sind gegeben 

durch eine Bezeichnung T (evt. auch mit Abkürzung), einen Wertebereich dom(T ), eine Menge von Funktionen 

ops(T ) und eine Menge pred(T ) von Prädikaten. 

Oft wird auch der Basis-Datentyp mit einem Informationstyp assoziiert. 

Ein Beispiel ist der Typ der ganzen Zahlen in der 4-Byte-Repräsentation 

integer := (IntegerSet 4Byte , {0, s, +, -, *, ÷, }, { =, ≤ }) mit der Nachfolgefunktion s . 

Basis-Datentypen verfügen neben dem Wertebereich auch über Funktionen und Prädikate. Sie sind außerdem 

durch eine Reihe von Eigenschaften eingeschränkt, die im Datenbanksystem zu beachten sind und oft im Entwurf 

übersehen werden: 

• Die Präzision und Genauigkeit sind ggf. für Typen wie REAL eingeschränkt. 

• Die Granularität von Daten kann sehr unterschiedlich sein. Die Skalierung von Datentypen kann sich 

ggf. auch auf die Funktionalität auswirken. 

• Datentypen verfügen nur ggf. über eine eigene Ordnungsbeziehung. 

• Datentypen verfügen ggf. über eine Klassifikation innerhalb der Daten des Wertebereiches. Diese Klassifikation 

kann einfach oder mehrfach hierarchisch, analytisch oder synthetisch, monothetisch oder polythetisch 

und ein- oder mehrdimensional sein. 

• Datentypen können über unterschiedliche Präsentationsformen verfügen. Das Format umfaßt Länge und 

Größe. 

• Datentypen können auf unterschiedliche Art abgespeichert werden. 

• Datentypen verfügen über eigenständige Default- und Nullwerte. 

• Datentypen können durch Casting-Funktionen aufeinander abgebildet werden. 

• Datentypen sind bestimmten Anwendungen und Arbeitsgebieten zugeordnet. 

• Die Funktionen und Prädikate lassen unterschiedliche Berechnungen zu, die sich auf die Erfassung, Berechnung, 

Algorithmen etc. auswirken. 

• Bestimmte Funktionen, wie z.B. der Durchschnitt, sind evt. anders oder gar nicht definiert. 

• Datentypen sind oft mit Maßeinheiten ausgewiesen, womit auch Berechnungen unterlegt werden müssen. 

Basis-Datentypen sind meist auch in einem Typenverband geordnet. 

Neben den Basis-Datentypen des DBMS kann auch eine Anwendung über eigene Basis-Datentypen verfügen. 

Wir können z.B. den Typ varnumbersequence20 zur Darstellung von Telefonnummern mit einer angepaßten 

Ordnungsbeziehung und ohne Unterdrückung führender Nullen einführen. Analog kann ein Typ EmailTyp oder 

URL eingeführt werden. 



Kind of data type Natural order Natural zero Predefined functions Example 

extension based 

absolute + +/- +/- number of boxes 

ratio + +/- +(type dependent) length, weight 

intension based 

nominal - - (-) (except concatenation) names of cities 

ordinal + - - preferences 

rang + + - competitions 

interval + - (+)(e.g., concatenation) time, space 

Tabelle 1: Data types and their main canonical assumptions 

Attribut-Typen werden über einem Basis-Datentypen-System und einem Markierungssystem L für Attributnamen 

induktiv ausschließlich durch die folgenden beiden Regeln definiert: 

• Ein Attribut-Typ ist für eine Markierung A und einen Basis-Datentyp durch einen Ausdruck A :: T 

gegeben. Der Wertebereich dom(A) des Attribut-Typs ist der Wertebereich des Basis-Datentyps. Der 

Wertebereich des leeren Datentyps λ besteht aus ⊥. 

• Sind X 1 , ..., X n , Y Attribut-Typen und A, B, C, D Markierungen, dann sind A(X 1 , ..., X n ) (Tupel- oder 

Produkt-Konstruktor), A{Y } (Mengen-Konstruktor), A < Y > (Listenkonstruktur), A[Y ] (Konstruktor 

für optionale Elemente), A{| Y |} (Konstruktor für Multimengen). 

Die entsprechenden Wertebereiche sind durch Anwendung der Konstruktion gegeben, z.B. 

dom(A(X 1 , ..., X n )) = dom(X 1 ) × ... × dom(X n ) und dom(A{Y }) = 2 dom(Y ) . 

Markierungen können auch weggelassen werden. 

Beispiele von komplexeren Attributen sind 

Name (Vornamen, 

Familienname :: varstring30, [Geburtsname :: varstring30,] 

[Titel:{AkademischeTitel :: varstring10 } ∪ · 

FamilienTitel :: varstring10]) 

Kontakt (Tel({dienstl :: varnumbersequence20 }, privat :: varnumbersequence20), 

email :: emailType, ...) 

Geburtsdatum :: date . 

Attribute können in einer verkürzten Notation verwendet werden, wenn dies eindeutig im Schema bleibt. Das Attribut 

Kontakt ist z.B. dann auch ohne seine Bestandteile verwendbar. 

Attribute sind hierarchisch strukturiert wie - im Falle des Namens einer Person - der Baum in Bild 3 zeigt. Diese 

hierarchische Struktur ermöglicht auch Elemente auszuzeichnen, z.B. mit der Eigenschaft Element eines Schlüssels 

zu sein. So kann z.B. zum Schlüssel das Teilattribut 

Name (Vornamen, Familienname, [Geburtsname ]) 

hinzugenommen werden, wobei wir als Abkürzungsregel benutzen, daß mit dem Nennen eines Bezeichners auch der 

damit verbundene Teilbaum mit übernommen wird, z.B. für Vornamen auch die gesamte Teilstruktur Vornamen . 

2.2.2 HERM-Typen 

werden induktiv aufeinander basierend definiert. 

Entity-Typ: Eine Seiendenklasse (Objektklasse) (Entity-Klasse im weiteren) wird durch einen Entity-Typ dargestellt. 

Ein Entity-Typ besteht aus einer nichtleeren Folge von Attributen und einer Menge von statischen Integritätsbedingungen. 

Der Primärschlüssel wird direkt durch Unterstreichen der Attribute angegeben. Ist die Menge der 



Name 

❄ 

( ... ) 

✾ 

Vornamen 

❄ 

< ... > 

❄ 

( ... ) 

✮ 

 

Vorname Benutzung 

❄ 

string1 

❄ 

varstring15 

✠ 

Familienname 

❄ 

varstring30 

3 

[ ... ] 

❄ 

Geburtsname 

❄ 

varstring30 

✾ 

{ ... } 

❄ 

AkademischeTitel 

❄ 

varstring10 

3 [ ... ] 

❄ 

Titel 

❄· 

∪ 

3 

Familientitel 

❄ 

varstring10 

Abbildung 3: Semi-strukturiertes Attribut Name 

statischen Integritätsbedingungen leer, dann kann sie auch weggelassen werden. Eine Klasse von der Struktur 

des Entity-Typs ist gültig, falls alle Integritätsbedingungen gelten. Wir folgen der klassischen Notation, bei 

der ein Entity-Typ mit einer Definitionsgleichung dargestellt wird. Zum Beispiel ist ein Person-Typ spezifiziert 

durch 

Person = (Name, Adresse, Kontakt, GebDatum, PersNr : StudNr ∪ · 

MitarNr, ..., ∅) 

mit einer Folge von Attributen. Markierungen sind als solche ausgewiesen. 

Ein Entity-Typ wird durch ein Rechteck graphisch repräsentiert. 

Eine Entity-Klasse besteht aus einer Menge von Objekten vom Entity-Typ, die die statischen Integritätsbedingungen 

des Entity-Typen erfüllt. 

Zum Beispiel ist das folgende Objekt mit dem Identifikator β 

β: ((, Thalheim, {Prof., Dr.rer.nat.habil., Dipl.-Math.}), 

BTU Cottbus, (({ +49 355 692700, +49 355 692397}, +49 355 824054), 

thalheim@informatik.tu-cottbus.de), 10.3.52, 637861) 

vom Entity-Typ Person, wobei mit ‘z’ der Zusatzname und mit ‘r’ der Rufname bezeichnet wird. 

Einfacher Relationship-Typ: Ein Relationship-Typ (erster Ordnung) besteht aus einer nicht-leeren Folge von Entity- 

Typen, einer Menge von Attributen und einer Menge von statischen Integritätsbedingungen. Eine Menge von 

der Struktur des Relationship-Typen ist eine gültige Menge, wenn sie den statischen Integritätsbedingungen 

genügt. Elemente können markiert sein. 

Ein Beispiel sind die Relationship-Typen 

InGruppe = (Person, Gruppe, { Zeit(Von [,Bis]), Funktion }, ∅ ) 

DirektVoraussetz = (setztVoraus: Kurs, vorausges : Kurs, ∅, ∅ ) 

Professor = (Person, { Berufungsgebiet }, ∅ ) . 

Ein Relationship-Typ wird mit einer Raute graphisch repräsentiert. Wir erlauben auch optionale Komponenten 

von Relationship-Typen, solange eine Identifikation über die obligatorischen Elemente definiert ist. 

Ein Objekt eines Relationship-Typs ist ein Tupel, das zu den jeweiligen Elementen auf die entsprechenden Objekte 

der Klasse der Elemente durch Angabe von identifizierenden Werten (Identifikator bzw. Primärschlüssel 

bzw. anderer Schlüssel) verweist und Werte für die Attribute des Relationship-Typs besitzt. 

Eine Relationship-Klasse besteht aus Objekten des Relationship-Typs, die den statischen Integritätsbedingungen 

genügen. 



z.B. sind Objekte der Typen Professor, InGruppe und DirektVoraussetz 

Profβ: ( 637861, Datenbank- und Informationssysteme ) 

Senator3β: ( 637861, Senat, (1995,1998), Dekan) 

Senator5β: ( 637861, Senat, (2000), Vorsitzender) 

VorausDBIVHaupt: (DBIV, DBI) . 

Cluster-Typ Eine disjunkte Vereinigung von bereits konstruierten Typen wird als Cluster-Typ bezeichnet. Ein Cluster- 

Typ wird mit einem ⊕ -Zeichen graphisch repräsentiert. 

Beispiele sind durch folgende Typen gegeben: 

JuristischePerson = Person ∪ · 

Betrieb ∪ · 

Vereinigung 

Gruppe = Senat ∪ · 

Arbeitsgruppe ∪ · 

Vereinigung, 

die den Typ JuristischePerson bzw. Gruppe als disjunkte Vereinigung von anderen Typen einführen. 

Cluster-Typen können weitere Attribute besitzen. In diesem Fall wird der Cluster-Typ durch eine Raute mit den 

Attributen repräsentiert. 

Objekte von Cluster-Typen sind analog zu den Objekten anderer Typen durch entsprechende Zuordnung zu den 

Element-Typen eingeführt. So können z.B. die Objekte β, LIM, CottbusNet e.V. juristische Personen sein. 

¨ 

Uber die Nutzung der disjunkten Vereinigung hinaus kann auch der Cluster-Konstrukt für alle algebraischen Operationen genutzt werden. 

Ein Beispiel aus dem Titelbild der 7. Auflage des Buches von A. Kemper/ A. Eickler dazu: 

The following three schemata are equivalent to each other and are tightly associated with each other by transformation mappings. A typical example of these two schemata is given in 

Figure 4. Students enrolled in a course may be examined by docents that give the course. 

Examines.Enrolls.Course 

= Examines.GivenBy.Course 

Θ := Enrolls.Course ✶ P rovides.Course 

Course ✛ GivenBy ✲ 

Docent 

Course ✛ GivenBy ✲ 

Docent 

✻ 

✻ 

✻ 

✻ 

Enrolls 

✛ 

Examines 

Enrolls 

✛ 

Θ 

Examines 

❄ 

❄ 

Student 

Student 

The simple HERM schema 

The sophisticated HERM schema 

The representational conceptual schema 

Student = ({ StudId, ... }, ...), 

Course = ({ CourseID,... }, ...), 

Docent = ({ DocentID,... }, ...), 

Enrolls ✲ Course ✛ GivenBy Enrolls = ({ StudId, CourseID,... }, ...), 

Provides = ({ CourseID, DocentID,... }, ...), 

Examines = ({ StudId, DocentID, CourseID,... }, ...) 

⊇ ✻ ⊆ 

Examines[StudId, CourseID] 

❄ 

❄ 

⊆ Enrolls[StudId, CourseID] 

Student ✛ Examines ✲ Docent Examines[CourseID, DocentID] 

⊆ Provides[CourseID, DocentID] 

The “optimized” conceptual schema 

The logical relational schema 

The association between the “optimised” schema and the relational schema 

Abbildung 4: The ‘Janus’ schema cluster for conceptual modelling 

The optimised conceptual schema can be easily mapped to a structure that supports smooth operating of the database. The sophisticated HERM schema uses the Θ-join for the correct 



building of the relationship type that records downloads. The optimised conceptual schema is equivalent to this schema due to the equivalence of the join decomposition and the inclusion 

constraints [Tha00]. 

Relationship-Typ höherer Ordnung: Ein Relationship-Typ i-ter Ordnung besteht aus einer nicht-leeren Folge von 

Entity- und Relationship-Typen einer Ordnung von maximal (i-1), wobei ein Typ (i-1)-ter Ordnung sein muß, 

einer Menge von Attributen und einer Menge von statischen Integritätsbedingungen. Eine Menge von der 

Struktur des Relationship-Typen ist eine gültige Menge, wenn sie den statischen Integritätsbedingungen genügt. 

Eine Identifikation kann sowohl aus den Elementen bestehen als auch aus den Attributen. 

Es ist mitunter vorteilhaft, über Relationship-Typen höherer Ordnung zu verfügen, wie Bild 5 zeigt. Im oberen 

Student’ 

✻ 

✶ 

✯ 

Professor’ 

eingeschr. 

in 

Vorlesung 

☛ ✾ 

Semester 

✰ 

Raum 

 

❄ 

Kurs 

✛ 

✛ 

Direkt- 

Voraussetz 

Student’ 

✻ 

✯ 

Professor’ 

eingeschr. 

in 

✲ 

Vorlesung 

✾ 

Semester 

✰ 

Raum 

❄ 

Kurs 

✛ 

✛ 

Direkt- 

Voraussetz 

Abbildung 5: HERM Diagramme mit und ohne Relationship-Typen höherer Ordnung 

Diagramm muß eine zusätzliche Integritätsbedingung zwischen den Typen eingeschriebenIn und Vorlesung 

gelten, weil man sich nur dann einschreiben kann, wenn diese Vorlesung existiert. 

Ein etwas komplexeres Beispiel ist das Beispiel in Bild 6. Eine Lehrveranstaltung, z.B. eine Vorlesung, wird 

durch einen Lehrstuhl angeboten. Dieses Angebot kann angenommen werden. Dann wird die Lehrveranstaltung 

geplant. Wird sie auch gehalten, dann werden die aktuellen Daten in der Klasse zum Typ GehalteneLehrveranst 

gespeichert. Der Typus und die Raumzuordnung können sich vom Vorschlag zum Plan und für den Raum 

vom Plan zu den gehaltenen Lehrveranstaltungen ändern. Ein Vorschlag für eine Lehrveranstaltung wird durch 

Berechtigte eingetragen. Eine Person ist für die Lehrveranstaltung verantwortlich. Eine Lehrveranstaltung kann 

für mehrere Studiengänge angeboten werden. 

Wir wollen hier nicht die vollständige Entfaltung von Objekten zu Typen höherer Ordnung fordern. Deshalb 

erbt ein Relationship-Typ höherer Ordnung nur die Identifikation seiner Elemente oder - wenn wir an einer 



Kurs Semester Professor ✲ 

✯ 

❦ 

✻ 

✒ 

Dozent 

Person 

✶ 

eingetragen 

Verantwortlicher4LV 

Studiengang 

{} 

✛ angebotene Wunsch 

Vorlesung 

Zeit(Vorschlag, 

Vorschlag ✻ Nebenbeding) 

✲ 

✯ 

✻ 

Raum 

Typus 

✰ 

✛ 

geplante ✛ 

Lehrveranst 

Zeitrahmen 

gehaltene 

Lehrveranst 

Abbildung 6: HERM Diagramm zu unserem Hauptbeispiel 

vollständigen Wertedarstellung interessiert sind - nur die identifizierenden Werte der Objekte seiner Komponenten. 

So können z.B. Objekte vom Typ geplanteLehrveranstaltung in Bild 6 auch nur auf Objekte verweisen, 

die Kurs, Semester, Professor bezeichnen, wenn wir voraussetzen, daß ein Schlüssel des Typs angeboteneVorlesung 

aus Kurs, Semester, Professor besteht. 

Ein Objekt vom Typ 

angeboteneVorlesung = (Kurs, Semester, Studiengänge, 

Professor, eingetragen, Verantwortlicher4LV, Raumwunsch, Typus, { Zeit }, ∅) ist z.B. 

VorlesungDBIVSS02: (DBIV, SS2002, { Informatik, IMT }, 

637861, KK, 637861, SR1, Vorlesung/Übung/Praktikum 2+2+2, Mo. 1.DS) . 

Generalisierung versus Spezialisierung: Ein Cluster-Typ erlaubt die explizite Darstellung einer Generalisierung. 

Ein unärer Relationship-Typ stellt dagegen eine Spezialisierung dar, wenn der Relationship-Typ bzw. Entity- 

Typ als sein Element diesen identifiziert. Rollen werden oft durch einen generischen Typ mit der Bezeichnung 

IsA dargestellt. Da die relationalen Schemata auch ohne diesen Typ auskommen, bevorzugen wir die Darstellung 

als Rolle mit unären Relationship-Typen oder ggf. auch mehrstelligen Relationship-Typen, falls die Rolle 

durch eine Beziehung zu anderen Typen ausgezeichnet ist. Damit sind wir in der Lage, zwischen Generalisierung 

und Spezialisierung zu unterscheiden. 

Rollen, die exklusiv bzw. hierarchisch sind, lassen sich auch anstelle einer HERM-Rautenstruktur durch hierarchische 

Strukturen abbilden, wie in Bild 7 dargestellt. Welche Darstellungsform gewählt wird, hängt vom erforderlichen 

Detaillierungsgrad ab. Sollen Attribute mit dargestellt werden, wird das hierarchische ER-Modell 

sehr schnell zu unübersichtlich. In den ersten Abstraktionsschichten stellt es aber eine gute Alternative zum 

HERM-Diagramm zum. 

Aggregation: Wir können die Konstruktion von Relationship-Typen zu einer allgemeinen Aggregationskonstruktion 

erweitern, indem wir weitere Konstruktoren zulassen: 

• Vereinigung, 

• Mengenbildung, 

• Aggregation durch Beziehungsklasse und 

• Abstraktion durch Komponentenbildung. 



Person 

Student 

Diplomand 


✲ 

Student 

✲ 

Person 

Universitätsmitarbeiter 

Professor 

Projektmitarbeiter 

Projektmitarbeiter 

✻ 

✲Universitäts-✛ 

mitarbeiter 


Abbildung 7: Hierarchisches ER-Diagramm versus HERM Diagramm 

Klassen werden mit der hochgestellten Annotation ‘C’ und dem Typnamen bezeichnet. Z.B. sind Person C und 

InGruppe C Klassen entsprechenden Typs. 

IsA-Beziehungen können auf sehr unterschiedliche Art repräsentiert werden, ebenso wie unterschiedliche Schemata letztendlich das gleiche 

darstellen können. 

Three different styles are depicted in Figure 8. We prefer the compact style in the left diagram. 

Person 

Person 

Person 

✻ 

✻ 

✻ 



IsA 


Abbildung 8: Variants for Representation of Unary Relationship Types 

IsA-Typen: 

hier wurde partielle, nicht disjunkte Darstellung über Teiltypen bevorzugt, denkbar sind jedoch verschiedene Typen: 

1. partiell, nicht disjunkt; 

dieser Fall wird als der typische Fall angenommen (keine weiteren semantischen Informationen) 

Im HERM darstellbar über unäre Teiltypen. 

Person ⊇ Professor ∪ Mitarbeiter ∪ Student 

E ⊇ E 1 ∪ ... ∪ E n 

2. partiell, disjunkt 

die Teiltypen erfüllen eine Exklusionsbeschränkung 

Person ⊇ Professor ∪ Student 

E = E 1 ∪ ... ∪ E n 

3. total, nicht disjunkt 

E = E 1 ∪ ... ∪ E n 

Projektmitarbeiter = Professor ∪ Mitarbeiter ∪ Student 

4. total, disjunkt 

E = E 1 ∪ ... ∪ E n 

Studenten = StudImVordiplom ∪ StudImHauptstudium ∪ Diplomand 

Weiterhin kann auch für die Spezialisierung mit Partitionsbedingung eine analoge Strukturierung betrachtet werden (wird auch in den 

meisten Büchern ‘vergessen’): 

1. partiell, nicht disjunkt 

E ⊆ E 1 ∪ ... ∪ E n 

Teilnehmer ⊆ Vortragender ∪ Organisator ∪ NormalerTeilnehmer 

2. partiell, disjunkt 

E ⊆ E 1 ∪ ... ∪ E n 

Literatur ⊆ Buch ∪ Preprint ∪ Zeitschrift 



3. total siehe oben Generalisierung ≠ (Spezialisierung) −1 

E = E 1 ∪ ... ∪ E n 

Gewöhnlich wird in der Literatur nur versimplifizierend die IsA-Beziehung als strukturelle Beziehung betrachtet. Richtig ist aber die IsA- 

Beziehung im vollen Typeninhalt zu betrachten: 

Typ = Struktur + Operationen + Semantik 

In diesem Fall wird die Richtung der Vererbung bekanntgegeben. 

Damit dann besser modellierbar: 

• Vererbung von Eigenschaften von Teiltyp nach Supertyp 

• Vererbung von Eigenschaften von Supertyp nach Teiltyp (als Weiterbenutzung, Wiederverwendung) 

• Operationen des Teiltyps sind operationale Spezialisierung der Operationen des Supertyps (wenn im supertyp definiert) 

• Semantik des Teiltyps (eingeschränkt auf im Supertyp darstellbares) folgt aus Semantik des Supertyps 

Statische Integritätsbedingungen: Die Semantikspezifikationssprache umfaßt Schlüssel und Integritätsbedingungen, 

wie funktionale Abhängigkeiten, Exklusions- und Inklusionsabhängigkeiten, mehrwertige Abhängigkeiten, Viele- 

Eins-Bedingungen, Seinsbedingungen (Existenzbeziehung), Verweisbedingungen, Teiltypenbedingungen und Regeln, 

wie z.B. die Gesamtheitsregel, die Verneinungsregel und die Sichtregeln, sowie vor allem Komplexitätsbedingungen 

(Kardinalitätbedingungen) zur Spezifikation der Beziehung zwischen einem Relationship-Typen und seinen 

Komponenten. 

Unterscheidung (s.o.) von 

Generalisierung von Typen zur Zusammenfassung gleichartiger Beziehungen, gleichartigen Verhaltens 

Spezialisierung von Typen mit Einführung zusätzlicher Charakteristiken (Attribute) und zur Spezialisierung des 

Verhaltens 

u.a. auch 

• Auszeichnung von Rollen 

• Darstellung von Zusatzeigenschaften, ggf. auch optionaler Eigenschaften 

• Darstellung von Teiltypen 

Unterschiede von Generalisierung Spezialisierung 

... ... 

Beispiel: Verantwortlichkeit 

tbd 

Mehrdimensionale Modellierung 

Im Schema in Bild 9 beobachten wir mehrere Dimensionen, die relativ unabhängig voneinander betrachtet werden 

können: 

• Gegenstandsdimension, z.B. Partei, Person, Position und Organisation 

• Klassifikationen, hierarchische und andere Untergliederungen 

• Organisationsmodelle 

• Bedienungsmodelle und deren Komponenten, z.B. Verantwortlichkeit, Verantwortlichkeitsbereich 



Kind of 

business 

✛ 

Business 

hierarchy 

Range 

Protocol 

type 

■ 

✒ 

✻ 

Product 

type ❨ 

Responsibility 

Amount range 

Quantity ■ 

Position ❦ 

Person 

✛ 

Resource 

type 

is of type 

✠ 

Party ✛server 


⊕ ✛ client 

✲ 

Party 

hierarchy 

❄ ❄ 

Party 

type 

✻ ✻server 

client 

✲Responsibility 

type 

✲Responsibility 

contract 

Product 

hierarchy 

Rule 

❄ 

❄ 

✲ Kind ✛ 

of hierarchy Hierarchy ✲ Organization 

✻ ✻ 

✛ 

son 

father 

Organization 

based on ✲ ✛ 

type Structure 

✒ 

❄ 

Time 

slot 

❄ 

Responsibility✛ 

hierarchy 

✻ 

Hierarchical 

hierarchy 

Layered 

hierarchy 

Abbildung 9: A generic model of responsiblities 

2.3 Statische Integritätsbedingungen 

At present we know at least five application fields of database constraints theory: 

(1) normalization for a more efficient storage, search and modification; 

(2) reduction of relations to subsets with the same information together with the semantic constraints; 

(3) utilization of dependencies for deriving new relations from basic relations in the view concept or in so-called 

deductive databases; 

(4) verification of dependencies for a more powerful and user-friendly, nearly natural language design of databases; 

(5) transformation of queries into more efficient search strategies. 

A large number of structural and dynamical database constraints have been introduced in the past. We must however 

acknowledge that a fully fledged theory of database constraints is not yet existing. 

Separation of Integrity Constraints by Their Use and Usage. 

There are several classifications for integrity constraints: 

• either utilization characteristics are used for classification into domain constraints, key and functional dependencies, referential integrity 

constraints, join dependencies etc. 

• or their specific format of the formulas is used for classification into tuple-generating dependencies, equality-generating dependencies, 

existence constraints, single-table constraints, singleton-tuple constraints, etc. 

These characterizations are useful whenever constraints are formally defined. Their practical utility is, however, more restricted. Another 

characterization approach has been used in [Tha00] by relating constraints to the phase of database modelling into design, structural, semantic 

and representational constraints. We may combine the three approaches by clustering constraints according to their structural properties into 

• constraints expressing identification or partial identification of values by other values, 

• constraints stating relative independence of values in a class or within an object, 

• constraints stating existence (or non-existence) of values in an object, or values in groups of objects, or objects in a class, and 

• constraints expressing redundancy of values or objects. 

At the same time we may distinguish constraints according to their utilization in the design process. They might be meaningful at the level of 

the user, or at the level of the conceptual schema or at the level of the implementation. The following table shows this characterization. 



Business 

user level 

Conceptual 

level 


level 

Partial identificatiocy 

Relative independence Existence dependency Redundancy dependen- 

identification structure no null elementary facts 

functional, 

equality generating 

key, uniqueness, 

trigger, check 

multivalued, hierarchical, join 

dependencies, exclusion dependency, 

tuple generating, horizontal 

decomposition 

decomposition, stored procedures, 

trigger 

null-value-free, union 

constraints, numerical, 

cardinality constraint 

no null, stored procedures, 

trigger 

inclusion constraint, exclusion 

constraint 

referential integrity, surrogate, 

container 

Quality Criteria for Constraint Sets. 

Database systems aim in automatic support of quality. There are a number of quality criteria that have classically been considered in many 

textbooks and papers. Structural quality criteria are structural completeness, satisfiability of the schema, liveness of the database, applicability 

of automatic control features, explicit exception handling, applicability of operations, executability of operations and framing consistency 

procedures. The first three conditions are well discussed in the database literature. Automatically generated tests and control conditions are 

still an open research field. Operations are currently mainly applied based on the transaction approach, i.e., forcing a rollback after problems 

have been detected. Exception handling and execution control use the same approach. The framing or ramification problem is not yet solved. 

It requires a separation within a database into data that are not affected by a change and into data that are under potential change. A typical 

example of non-framed executions are trigger avalanches. 

Quality control must also consider the abstraction level of the stakeholder involved. Integrity constraints may be ambiguous or may be based 

on context or ellipses. We therefore need an explicit statement of the abstraction level. For instance, join dependencies are a specific vehicle 

for structuring the database. They are not used by the requirements engineer. There are however specification constraints at the requirements 

level that must be mapped to the internal levels. 

Optimisation of Behaviour Through Normalisation of Database Structuring. 

Normalisation has been developed as a vehicle for performance improvement of database systems. It addresses at least seven different targets: 

(A) Redundancy becomes problematic whenever additional actions are required for consistency management of data that are stored within 

different objects. 

(B) Blocking of management due to the information capacity of the schema. For instance, the insertion anomaly occurs since units of 

storage such as schema types do not support insertion of partial information. 

(C) Information loss after database modification occurs whenever data are eagerly deleted despite the importance of parts of it. The deletion 

anomaly is observed whenever facts are deleted together with the objects where they are contained despite its importance for the 

application. 

(D) Evolution sensitivity and instability of the database whenever changes are applied to the database. 

(E) Different abstractions are used for the database schema at the same time. For instance, views, derived attributes, logs are stored together 

with the basic data that are used to derive these values. 

(F) Performance problems can also be solved through restructuring. Typical performance problems considered are caused by integrity 

constraint maintenance. Update anomalies have been considered as a prominent example of a performance problem since singleton 

fact operations resulted in complex bulk operations. Performance problems are however also caused by architectures chosen for the 

application, by specific behaviour of the application, by retrieval requirements, by generation and maintenance of supporting structures 

such as indexes, etc. The last set of performance problems is often resolved by denormalisation, i.e., by intentional acceptance of another 

normalisation. Denormalisation may decrease complexity of retrieval and maintenance operations, may avoid additional join operations 

and may prepare special derived data for support of repeating computations. It allows us to consider semantically meaningful units 

instead of normalised structures. Index management is optimised. Denormalisation increases however complexity of some database 

operations, leads to redundancy problems, may result in inflexibility against evolutionary changes. 

(G) Expensive maintenance, operating and modification of databases often occurs due to consistency maintenance. Parallel execution of 

transactions may result in deadlocks. 

As far as we know there is not yet any theory that integrates the six targets of normalisation. Moreover, (A), (C) and (G) are considered to be 

the primary issues. 



2.3.1 Revisiting Database Dependency Theory 

The Power of Simplicity. 

Functional and multivalued dependencies are a very powerful and simple class of integrity constraints. It is wellknown 

that their reasoning and deduction can be based on propositional formulas [Tha91a]. At the same time, a 

simple and powerful axiomatisation can be given for simple dependencies and their negations. As an example we 

give an axiomatisation for functional and negated functional dependencies: 

Axioms 

XY → Y 

Rules 

(1) 

(4) X −→/ Y 

X −→/ Y Z 

X −→ Y 

XV W −→ Y V 

(5) 

XZ −→/ Y Z 

XZ −→/ Y 

(2) 

X −→ Y , Y −→ Z 

X −→ Z 

(3) 

(6) 

X −→ Z , X −→/ Y Z 

X −→/ Y 

X −→ Y , X −→/ Z 

Y −→/ Z 

(7) 

Y −→ Z , X −→/ Z 

X −→/ Y 

Funktionale Abhängigkeiten umfassen zu viele Aspekte auf einmal. 

Explicit declaration of partial identification: Functional dependencies are typically explicitly declaring a functional 

association among components of types. The left hand attribute uniquely identify right side attributes, i.e. 

X Ident −→ Y . 

Identification can either be based on surrogate or on natural attributes. 

Tight functional coupling: Functional dependencies may also be numerical constraints. We denote such constraints 

by i.e. X Num −→ Y . Another denotation is based on cardinality constraints. 

Semantic constraint specific for the given application: Constraints may be stronger than observed in usual life 

since the application has a limited scope and allows to strengthen the constraint. In this case, constraints restrict 

the application only to those cases in which the left side has only one associated right side value despite that 

this restriction may not be valid for any application. We denote this case by X −→ Sem Y 

Semantical unit with functional coupling: Semantical units are those reducts of a type that are essential in the 

given application. Their components cannot be separated without loosing their meaning. Semantical units may 

have their inner structure. This structure tightly couples dependent object parts to those that are determining 

them. We denote this coupling by X Unit −→ Y . 

Structural association among units: Semantical units may allow a separation of concern for certain elements. 

Their separation supports a more flexible treatment while requiring that the dependent part cannot exist without 

the determining part. If this dependence is functional we may represent such by the constraint X Struct −→ Y . 

Funktionale Abhängigkeiten als Funktion 1 kann direkt ausgelagert werden bereits vor Normalisierung 

ISBN kodiert bereits den Verlag 

ISBN/ISSN muß aber nicht für Buch existieren (alte Bücher), kann ggf. auch mehrere Ausgaben mit umfassen 

oder auch nur genau die Ausgabe mit bezeichnen 

ist dann tacit knowledge, auf das die anderen Daten aufbauen, das ggf. nicht einen update erfährt 

Example 1 Let us consider an abstract example with the functional dependencies 

{A} −→ {B, C} and {B} −→ {D}. 

The functional dependency {A} −→ {C} declares an explicit and direct dependency among the attributes. 

The functional dependency {A} −→ {B} is an inter-type constraint and leaves the scope of type T A . These two 

dependencies are completely different and need different support mechanisms. 

IS ADD


T A 

✛ 

(1,1) 

T A .to.T B 

✲ 

T B 

A 

C 

B 

D 

The first five cases may be observed for the following instantiations of this example: 

instantiation 

Explicit declaration T B = StudyProgram , B = ProgramCode, D = ProgramName 

Tight coupling T A = Student, T A .to.T B = MajorProgram, T B = StudyProgram 

Semantic constraint T B = StudyProgram , B = ProgramCode, D = ResponsibleProfessor 

Semantical unit T B = StudyProgram , B = ProgramCode, D = ProgramDegree 

Structural association T A = Student, T B = RegisteredStudent, A = PersonID, B = StudentNr 

Let us consider, for instance, that the type T B represents a study program, and the attributes B represent a program 

code, D the program name. The functional dependency {B} −→ {D} is an explicit key dependency. If the attribute 

D represents the professors that are responsible program then we might assume or not assume {B} −→ {D}. This 

depends on the given application. Therefore the dependency is a semantical constraint. From the other side, if the 

attribute D represents the program degree then this degree cannot be separated from the values for the program 

code. In this case the attributes form a semantical unit. Furthermore, in most universities a student is registered for 

one and only one major degree. The student must have a major program. In this case, the two types Student and 

StudyProgram are thus tightly coupled. Finally, we can separate the student personal data from the student university 

data. The person identification number is structurally associated to the student number. 

This separation results also in a different meaning of derivation rules. For instance, the augmentation rule has a 

different meaning depending on the kind of functional dependency: 

Trivilisation 

of identification 

R : X Ident −→ Y ⊔ R Y ′ 

R : X ⊔ R X ′ 

Ident 

−→ Y 

Adaptation of 

semantics scope 

R : X Sem −→ Y ⊔ R Y ′ 

R : X ⊔ R X ′ 

Sem 

−→ Y 

We may also use the Armstrong axiomatisation for derivation of functional dependencies of a given kind. The following 

two rules are examples of refined rules: 

R : X Ident −→ Y, R : Y Sem −→ Z 

R : X Ident −→ Z 

R : X Sem −→ Y, R : Y Ident −→ Z 

R : X Sem −→ Z 

Kinds of Key Dependencies.. 

A key dependency or simply key X is a functional dependency R : X −→ R . A key is called minimal if none 

of its proper substructures forms a key. The set of all minimal keys of R is denoted by Keys(R). We notice that this 

set may be very large. For instance, an entity type E with n atomic attributes may have ( ) 

n 

⌊ n minimal keys which is 

2 ⌋ 

roughly 2n 

c √ n . 

The key concept reflects a variety of descriptive meanings depending of the level of consideration. Let us distinguish 

between external, conceptual and internal levels. The meaning of the key concept can be based on the 

uniqueness property (each object is unique with this key in the database), the identification property (each object can 

be identified by its key values), the existence property (for each object there exist key values), the integrity property 

(the database satisfies a key constraint), and the accessibility property (the properties of an object can be accessed 

through the key values of the object). These meaning are not equally important at all levels: 

• At the language definition level, the uniqueness concept is used to express the key property. The identifier, 

existence, integrity and accessibility functionalities are not considered. 

IS ADD


• The uniqueness concept is inherited by the external level and expressed mainly via the identification property. 

The existence property plays a secondary role. The integrity and accessibility concepts are not mainly under 

consideration. 

• At the conceptual level, the uniqueness concept of the language definition level is inherited by the identification 

and the integrity property. In order to express the identification concept, the surrogate concept is introduced. 

The key dependency is the integrity constraint usually used to express the key property. 

• At the internal level, the uniqueness concept is completely covered by the identification concept. From the 

external level the existence and uniqueness concepts are inherited and used in implementation restrictions 

like the requirement of invariant values in keys. The internal levels also inherit the integrity concept of the 

conceptual level and uses this concept for the accessibility property of the key. 

These descriptive meanings of the key concept are pictured in Figure 10. 

language definition level 

uniqueness 

external level 

✠ 

identification 

existence 

conceptual 7 

level internal level 


(surrogate) 

❯ 

integrity constraint 

(key dependency) 

❥ identification 

3 accessibility 

✲ invariance 

Abbildung 10: Descriptive meanings of the key concept depending on the levels 

Beside the descriptive meanings we may also use implementation concepts such as pointers and pragmatic meanings 

such as naming. 

Typen mit genau einem minimalen Schlüssel. 

Menge der Extremalattribute für gegebene Menge Σ von funktionalen Abhängigkeiten und Komponenten R eines 

Typs T : 

extr(R, Σ) := {B ∈ R | Σ ̸|= R \ {B} −→ {B}} 

Corollary 1 Folgende Aussagen sind äquivalent: 

• T besitzt genau einen Schlüssel. 

• extr(R, Σ) ist ein Schlüssel von T . 

• Σ |= extr(R, Σ) −→ R. 

The Power of Graphical Reasoning. 

FD Graphs.. 

Functional dependencies are typically treated in a linear fashion. Graphical representation can however be used for 

reasoning on constraints as well. It is a folklore approach that deserves more attention. 

Example 2 Given the set U R = {A, B, C, D, E} of attributes and the set σ R = {A −→ E, B −→ E, CE −→ D} 

of functional dependencies. This set can be represented by the following graph: This graph is easier to survey, simpler 

for reasoning and contains the full information on σ R . 

Let us consider for instance, the dependency {A, C} −→ E. The derivation can directly be derived from the 

following schema due to the validity of the left-side extension rule 

IS ADD 

X−→Y,Y ∪Z−→V 

X∪Z−→V 

.


A 

B 

✲ 

✯ 

E 

C 

CE 

✲ 

D 

A 

AC 

✲ 

D 

C 

FD graphs can be axiomatised. This axiomatisation mainly follows the rule system of the Armstrong axiomatisation 

except that right hand side attributes are limited to singleton attribute sets. This axiomatisation [DMT04] 

provides the first axiomatisation for FD graphs (Y denotes a set; A, B, C denote attributes): 

(S) Y → B 

Y C → B 

Y → A, Y → B 

(Q) 

Y A → B 

(T ) Y → A, Y A → B 

Y → B 

Y A → B, Y → B 

(R) 

Y → A 

(P ) Y C → B 

Y → B 

()¬(Y → B, Y → B) 

() is a formalization of ’→’ being the negation of ’→’, i.e., ¬() can be deduced starting with contradictory sets of 

constraints. 

Theorem 1 [DMT07] The ST implication system over graphs of functional dependencies with rules (S) and (T) and 

no axioms is sound and complete for functional dependencies. 

The PQRST implication system over graphs of functional and negated functional dependencies with all the presented 

rules and the symbolic axiom (), which is used for indicating contradiction, is sound and complete for functional 

dependencies and their negations if they are not conflicting. 

At the same time reasoning on graphs is more appropriate also for normalisation. Yang [Yan86] has discussed a 

reduction algorithm that allows a simple generation of canonical covers and of minimal covers for a set of integrity 

constraints. 

We can also use graphs of functional dependencies for detection of normal forms that are better than those 

generated by classical synthesis algorithms. Synthesis algorithms blindly collect all dependencies with the same left 

side at the final step. Using graphical reasoning we may collect only those dependencies that are not covered by any 

other group. 

Example 3 Given: the set U R = {A, B, D, F, G, I} of attributes and the set σ R = {A −→ IG, D −→ F G, IAB −→ 

D, IF −→ AG} of functional dependencies. This set can be represented by the graph in the left picture. The graph 

I 

IF 

✛ 

✯ A 

ABI 

✙ 

F 

✲ 

✯ 

✲ 

G 

✻ 

D 

I 

IF 

✛ 

✯ 

A 

AB 

F 

✙ 

✯ 

✲ 

G 

✻ 

D 

in the right picture displays its reduction to a minimal cover. 

These graph also support reasoning on redundancy of constraints. Consider, for instance, whether AB −→ D 

can be redundant. The answer is “no” since D has only one entry point. The same observation is true for A −→ I, 

D −→ F . 

By a similar reasoning we can derive non-redundancy of D −→ G. 

Additionally we can directly see that {A −→ I, F I −→ A} creates a structure that cannot be represented by a 

BCNF. 

Classical synthesis algorithms generate the following relation schemata: 

IS ADD


(1) 

A 

(2) 

A 

(3) 

A 

C 

B 

C 

B 

C 

× 

× 

B 

Abbildung 11: Examples of the triangle representation. From left to right: (1) The functional dependency {A} → {B} 

(filled circle at B side (right side of the FD) of the AB edge) and the implied functional dependency {A, C} → {B} 

(circle around node B in the ABC triangle). (2) The functional dependencies {A} → {B}, {B} → {C} and their 

implied functional dependencies {A} → {C}, {A, B} → {C}, {A, C} → {B}. (3) The negated functional 

dependency {A, C} → {B} (crossed filled circle around node B in the ABC triangle) and the implied negated 

functional dependencies {A} → {B} (crossed circle at B side of the AB edge) and {C} → {B}. 

R 1 = ({A, G, I}, {A −→ GI}) 

R 2 = ({A, F, I}, {A −→ I, F I −→ A}) 

R 3 = ({A, B, D}, {AB −→ D}) 

R 4 = ({D, F, G}, {D −→ F G}) 

This normalisation is however not minimal. Instead of R 1 we can use 

R 1 ′ = ({A, G}, {A −→ G}). 

The relation schema R 1 is obtained through the relation schema R 2 in combination with R 1 ′ . R 2 is not in BCNF. It 

cannot be split into two relation schemata. 

The graph in the picture directly allows us to detect this better normalisation since the dependency A −→ I is 

covered by R 2 . 

This example illustrates the power of graphical reasoning. Normalisation is typically driven by goals such as being 

dependency preserving, providing the basis for key-based integrity maintenance (BCNF) or being redundancy-free 

(3NF) at least at the attribute level or avoiding maintenance problems (e.g., insert anomaly) or avoiding data losses 

(e.g., delete anomaly) or occurrence of performance traps (e.g., update anomaly). It might be extended to such criteria 

as being redundancy-free at the value level. 

Textbooks typically dont’t mention that normalisation also introduces additional constraints. 

Example 4 The last example results in pairwise inclusion constraints such as the multiple value occurrence bindings 

R ′ 1 [A] ⊆⊇ R 2[A] ⊆⊇ R 3 [A]. This inclusion dependency set adds an overhead to integrity maintenance. The functional 

dependencies are directly represented through key dependencies. At the same time, any change to A-values in 

one of the relations must be harmonised with changes to A-values in the other relations. 

FD Set Graphs.. 

Demetrovics, et al., [DMT07] introduce graphical reasoning for sets of constraints. We may represent validity and 

invalidity of functional dependencies by a graph. Let us illustrate this approach for relational schemata with three 

attributes. Visualisations may be based on more complex figures, e.g. a hexagon for six attributes. To do so we 

distinguish two kinds of functional dependencies and display them as follows in Figure 11: Functional dependencies 

of the form {A} → {B, C} can be decomposed to canonical functional dependencies {A} → {B} and {A} → {C}. 

They are represented by endpoints of binary edges in the triangle representation. Functional dependencies with twoelement 

left-hand sides {A, B} → {C} cannot be decomposed. They are represented in the triangle on the node 

relating their right side to the corner. 

This notation has the advantage that we are supported for reasoning on potential validity of constraints as well. 

We may represent also candidates for excluded functional dependencies by crossed circles for the case that we know 

IS ADD


Abbildung 12: Graphical versions of rules (P), (Q), (R), (S) and (T) in terms of the triangle representation. The small 

black arrows indicate support (necessary context) while the large grey arrows show the implication effects. 

that the corresponding functional dependency is not valid in applications or by small circles for the case that we do 

not know whether the functional dependency holds or does not hold. 

Since the ST implication system is sound and complete for non-trivial canonical functional dependencies, rules 

(S) and (T) can be used for deriving all implied functional dependencies given an initial set. Moreover, the PQRST 

implication system forms a sound and complete system for both positive and negative (excluded) non-trivial singleton 

functional constraints, rules (P), (Q) and (R) can be applied as complements of rules (S) and (T) when excluded 

functional constraints are taken into account. 

These rules can be interpreted in terms of the graphical representation as well. A deduction step using one of 

them deals with a node of a higher-dimension object (e.g., a triangle as a two-dimensional object with one of its three 

vertices) and one or two of its borders (with one dimension lower, e.g., edges of the same triangle as one-dimensional 

objects). 

Graphical versions of rules are shown on Figure 12 for the triangle representation (case Y = {C}). The large 

grey arrows indicate the implication effect of each rule. Rule (S) is a simple extension rule and rule (T) can be called 

the “rotation rule” or “reduction rule”. We may call the left-hand side of a functional dependency the determinant of 

it and the right-hand side the determinate. Rule (S) can be used to extend the determinant of a dependency resulting in 

another dependency with one dimension higher, while rule (T) is used for rotation, that is, to replace the determinate 

of a functional dependency by the support of another functional dependency with one dimension higher (the small 

black arrow at B indicates support of AC → B). Another possible way to interpret rule (T) is for reduction of the 

determinant of a higher-dimensional dependency by omitting an attribute if a dependency holds among the attributes 

of the determinant. 

For excluded functional constraints, rule (Q) acts as the extension rule (i.e., it needs the support of a positive 

constraint, i.e., functional dependency) and (R) as the rotation rule (which needs a positive support too). These two 

rules can also be viewed as negations of rule (T). Rule (P) is the reduction rule for excluded functional constraints, 

with the opposite effect of rule (Q) (but without the need of support). Rule (Q) is also viewed as the negation of rule 

(S). 

Mehrwertige Abhängigkeiten im falschen Modell. 

Cadiou-Definition als die zweitbeste Form und ER-Definition als die bei weitem beste Form!!! 

It is often claimed that multivalued dependencies are difficult to model, to teach, to learn and to handle. They are 

IS ADD


introduced in almost any database book. The classical introduction is based on the tuple-generating definition of the 

multivalued dependency X → Y |Z . It requires that whenever two tuples have the same value on the left-hand 

side then there also exists a tuple in the relation class which matches to the first tuple by the left-hand side and the first 

element of the right-hand side and which matches to the second tuple by the left-hand side and the second element 

of the right-hand side. This definition has the clarity of a mathematical definition and the problematic treatment often 

observed for other mathematical constructs. 

There are however five other definitions for multivalued dependencies that are easier to understand, to handle, 

and to represent. We may group these definitions as follows: 

Derivation constraint: The classical definition is based on the above mentioned tuple generating property. Another 

definition uses the construction approach for hinged Cartesian products and binds the validity of the multivalued 

dependency to the equality on query expressions (σ X=x (R C ))[Y ∪Z] = (σ X=x (R C ))[Y ] ×(σ X=x (R C ))[Z] 

is valid for Y, Z with Y ∩ Z = ∅ for all x ∈ R C [X]. 

Structure constraint: The structure-oriented definition can be given through 

• the decomposition of the original class into two classes, i.e., the original class can be reconstructed by 

applying the natural join to the projection of R C to X ∪ Y and X ∪ Z respectively or 

• the potential structuring by a nested relation class 

ν Y (ν Z (R C )) X {Y } {Z} 

A 1 ... A k A k+1 ... A m A m+1 ... A n 

... ... ... ... ... ... ... ... ... 

or 

• the potential restructuring in an ER model in the following form 

Y ✛ XY ✲ X ✛ XZ 

(1,n) (1,n) 

✲ 

Z 

Independence concept: The original definition [Cad76] uses relative independence of Y -components from Z- 

components in a relation class, i.e., the values of the X-components determine the values of Y-components of 

objects in R C independently from the values of Z-components, ( (σ X=x (R C ))[Y ] = (σ (X=x)∧(Z=z) (R C ))[Y ] 

for all x-values x ∈ R C [X] and all z-values z ∈ R C [Z]). 

The generation definition is certainly the most mathematical and the least useful among the definitions. The construction 

definition provides a facility for checking validity. Both definitions also demonstrate that the relational model 

language is not appropriate for reasoning on these constraints. The independence notion is the simplest for modelling 

and for considering. The structure definitions are certainly the best way for the understanding of these constraints. 

The ER approach is the best suited model language for multivalued dependencies. 

Example 5 Let us consider a relationship type EmployeeAssociation defined on the entity types: StaffMember, 

DependentPerson, Project, Supplier, Product with the following multivalued dependencies: 

{ StaffMember } → { Department, DependentPerson }|{ Project, Product, Supplier } 

{ StaffMember } → { DependentPerson }|{ Department, Project, Product, Supplier } 

{ Project } → { StaffMember, Department, DependentPerson }|{ Product, Supplier } 

{ Product } → { Department, StaffMember, DependentPerson, Project }|{ Supplier } . 

The ER model allows us to derive a new structuring by the decomposition of the relationship type. We obtain the schema 

in Figure 13 for which a new type ‘Working’ reflects the separation of concern to P P roduct, Department StaffMember 

and the independence of suppliers and projects according to the multivalued dependencies. 

Inklusions- und Exklusionsabhängigkeiten. 

in 2 verschiedenen Facetten 

IS ADD


Department 

Project 

of Product 

✛ 

✲ 

Working 

0..1 

❄ 

Product 

✛ 

0..1 

✲ 

StaffMember 

Supplier 

of Product 

✛ 

Dependent 

Abbildung 13: The decomposition of the relationship type based on multivalued dependencies 

• Klassenabhängigkeiten zur Existenz von Klassen 

daraus resultierend verschiedene Art von Schemata R[X] ⊆ S[Y ] 

• partielle Objektredundanz 

spezielle Form: referentielle Abhängigkeit mit Fremdschlüssel-Imputation in die existierende Klasse und entsprechender 

imputierter zusätzlicher Identifikation 

2.3.2 Umgebungsdefinition für Integritätsbedingungen 

Allgemeines Herangehen: 

Umgebung 

Gültigkeit 

Ausnahmebehandlung 

Erzwingungsstrategie mit Erzwingungsregel und Erzwingungszzeitpunkt, sowie Priorisierung 

Nachsorgestrategie 

genauere Ausführung nach den HERM-IC 

IS ADD


2.3.3 Statische Integritätsbedingungen von HERM 

Statische Integritätsbedingungen werden als Formeln der hierarchischen Prädikatenlogik allgemein dargestellt. Wir 

verwenden jedoch die üblichen Kurzdarstellungen. 

Wir gehen davon aus, daß statische Integritätsbedingungen einer Interpretation mit einer “Normallogik” unterliegen. 

Mitunter wird auch im Entwurf eine Integritätsbedingung mit einer schwachen, deontischen Interpretation benutzt, bei 

der ihre Gültigkeit für die meisten Objekte einer Datenbank oder einer Klasse gefordert wird. Mitunter wird auch eine 

strikte Form der Interpretation genutzt, bei der z.B. obere bzw. untere Schranken für Kardinalitätsbeschränkungen 

auch durch entsprechende Objektmengen genau erfüllt sein müssen. 

Wir verwenden im weiteren folgende Klassen von Integritätsbedingungen: 

Schlüssel dienen der Darstellung der Identifizierbarkeit von Objektmengen, insbesondere in Entity-Klassen). Wir 

nehmen an, daß Entity-Klassen stets eigen-identifiziert sind, d.h. Mengen sind. Eine Teilmenge der Strukturelemente 

kann auch als Schlüssel dienen. Gewöhnlich hat jeder Typ mehr als einen Schlüssel. Deshalb verwenden 

wir von vornherein Schlüsselmengen. Der Primärschlüssel eines Entity-Typs wird direkt angegeben und kann 

in der Schlüsselmenge weggelassen werden. 

Wir nehmen z.B. für das Diagramm in Bild 6 folgende Schlüssel an: 

Key(Person) = { { PersNr }, { Name, Geburtsdatum } } 

Relationship-Typen haben ggf. auch eigene Attribute, die auch Bestandteile eines Schlüssels sind. 

Zum Beispiel nehmen wir für das obige Beispiel an, daß die Zeit essentiell für InGruppe ist, d.h. 

Key(InGruppe) = {{ Person, Gruppe, Zeit }} oder 

Key’(InGruppe) = {{ Person, Gruppe, Zeit, Funktion }} 

Weiterhin kann z.B. gelten 

Key(Vorlesung) = { {Kurs, Semester}, {Semester, Raum, Zeit}, {Semester, Dozent, Zeit} } 

Schlüssel folgen der Komponentenkonstruktion und können auch für einen Teil gelten, z.B. 

Name(Vornamen, FamName). 

Mindestens ein Schlüssel wird über die Komponente an den Relationship-Typen ‘vererbt’. 

Schlüsselvererbung aus den Komponenten heraus 

z.B. in Bild 22: 

• Projekt, Institution, Mitarbeiter, Labor besitzen ihre Schlüssel; jeweils einer davon kann ausgezeichnet 

sein 

• fördert leitet, arbeitet in, zugeordnet erben die Schlüssel der jeweiligen Elemente zur Identifikatioon der 

Relationships in den jeweiligen Relationship-Klassen 

• analog kann auch ein Relationship-Typ höherer Ordnung seine Identifikation durch die Identifikation der 

Komponenten beziehen 

• ggf. kann auch für einen Relationship-Typen gelten, daß einige seiner Attribute für die Identifikation mit 

herangezogen werden 

Funktionale Abhängigkeiten sind eine wichtige Gruppe von Abhängigkeiten. Eine funktionale Abhängigkeit R : 

X → Y ist für einen Typ R und Teilmengen X, Y seiner Elemente definiert. Sie gilt in einer Klasse R C , 

falls die Gleichheit von Objekten o, o ′ aus R C über X die Gleichheit über Y für o, o ′ impliziert. 

Funktionale Beziehungen von Attributgruppen in unserem Beispiel sind 

geplanteLV : {Semester, Zeitrahmen, Raum} → {{Studiengang}, Professor, Kurs} 

geplanteLV : {Professor, Semester, Zeitrahmen} → {Kurs, Raum} 

angeboteneLV: {Semester, Kurs} → {Professor} . 

Mod IS 

IS ADD


Kardinalitätsbeschränkungen werden als kombinatorische Beschränkungen in der (min,max)-Notation und der 

Partizipations-Semantik als Paar von Kardinalitäten verwendet. Damit unterscheidet sich unsere Notation von 

der Lookup-Semantik, die z.B. UML verwendet. Die letztere kann jedoch in einer n..m-Notation ebenso mitgeführt 

werden. Wir betrachten hierzu ein vereinfachtes Diagramm in Bild 14. 

(gehaltene) ✛ 

Vorlesung (1,n) 

setztVoraus ✻ 

(0,2) 

✻vorausgesetzt 

(3,4) 

3..4 0..2 

Voraussetzung 

0..2 

legtab ✲ 

(0,n) 

Resultat 

(0,n) 

❄ 

Student 

Ablageform 

Abbildung 14: Kardinalitätsbeschränkungen im Vorlesungsbeispiel 

Eine Kardinalitätsbeschränkung card(R, R i ) = (n, m) gilt in einer Klasse R C , falls jedes Objekt o i von 

Ri 

C in R C mindestens n-mal und höchstens m-mal vorkommt. 

Eine Kardinalitätsbeschränkung card(R, R i ) = (n, 1) für R = (R 1 , ...., R n , attr(R)) ist äquivalent 

zur funktionalen Abhängigkeit R : R i −→ R 1 , ...., R i−1 , R i+1 , ..., R n . 

Eine Kardinalitätsbeschränkung card(R, R i ) = (1, m) für R = (R 1 , ...., R n , attr(R)) ist äquivalent 

zur Inklusionsabhängigkeit R : R i ⊆ π Ri (R). 

Eine Kardinalitätsbeschränkung in der Lookup-Notation look(R, R i ) = (n, m) gilt in einer Klasse R C 

mit k Elementen, falls zu jeder Kombination von Objekten o j von Rj 

C (j ≠ i, 1 ≤ j ≤ k) mindestens n und 

höchstens m entsprechende Objekte o i aus Ri 

C in der Klasse R C vorkommen. 

Im Fall binärer Relationship-Typen ohne Attribute, die zur Identifikation von Relationships herangezogen werden 

müssen, kann man damit einem Objekt o von R i mindestens n und höchstens m Objekte aus Rj 

C zuordnen, 

d.h. das Objekt sieht vermittels R C höchstens m und mindestens n Objekte aus der anderen Klasse. Wir erhalten 

damit das folgende Bild: 

C 

A 

✛ 

(a,b) 

c...d 

A with B 

(c,d) 

✲ 

a ...b 

A 


Diese Beziehung zwischen lookup und participation-Bedingungen gilt allerdings nicht, wenn die Attribute C 

bei der Identifikation des Relationship-Typen herangezogen werden!!! 

Eine Kardinalitätsbeschränkung look(R, R i ) = (n, 1) für R = (R 1 , ...., R n , attr(R)) ist äquivalent 

zur funktionalen Abhängigkeit R : R 1 , ...., R i−1 , R i+1 , ..., R n −→ R i . 

Eine Kardinalitätsbeschränkung look(R, R i ) = (1, m) für R = (R 1 , ...., R n , attr(R)) ist äquivalent 

zur verallgemeinerten Inklusionsabhängigkeit 

R : ∀o i ∈ R C i ∃(o 1 , ..., o i−1 , o i+1 , ..., o n ) ∈ π R1 ,....,R i−1 ,R i+1 ,...,R n 

(R C ) : 

(o 1 , ..., o i−1 , o i , o i+1 , ..., o n ) ∈ π R1 ,....,R i−1 ,R i ,R i+1 ,...,R n 

(R C ) . 

Sie kann auch durch R C i ⊆ π Ri ( R C i × π R1 ,....,R i−1 ,R i ,R i+1 ,...,R n 

(R C ) ) dargestellt werden. 

Mod IS 

IS ADD


Manchmal wird sogar das Kartesische Produkt von R C 1 , ...., RC i−1 , RC i+1 , ..., RC n anstelle der Projektion verstanden. 

Diese Interpretation wurde z.B. UML unterlegt. 

Trotzdem sind Lookup-Abhängigkeiten auch von Nutzen. Man betrachte z.B. Bild 16. Die Lookup-Bedingung 

look(Angebot, verantw. P erson) = 0..1 impliziert direkt ein Pivoting im Schema auf der rechten Seite, 

das relativ natürlich scheint. 

Kurs 

✛ 

(a,b) 

Angebot 

0..1✲ 

verantwortl. 

Person 

Semester 

✻ 

Person 

✻ 

❄ 

Semester 

Kurs 

✛ 

Angebot 

✛ Verantwortlicher 

0..1 


0..1 

Wird dagegen auch noch card(Angebot, Kurs) = (0, 1) gesetzt, dann ergibt sich natürlich eine viel 

stärkere Dekomposition in Bild 17. 

Semester 

✛ 

Angebot ✲ Kurs ✛ Verantwortl. ✲ 

(0,1) (0,1) 

Person 


Die Lookup-Notation ist für binäre Relationship-Typen ohne eigene Attribute äquivalent zur Partizipation- 

Notation. Sie wird jedoch am anderen Element angetragen. Im Beispiel nehmen an, daß 

card(Voraussetzung, setztVoraus) = (0,2) 

look(Voraussetzung, setztVoraus) = 3..4 

card(Voraussetzung, vorausgesetzt) = (3,4) 

look(Voraussetzung, vorausgesetzt) = 0..2 

gilt. Damit haben wir äquivalente Formen. 

Für n-äre Relationship-Typen ohne eigene Attribute ist die Lookup-Notation look(R, R i ) = n..m äquivalent 

zur verallgemeinerten Kardinalitätsabhängigkeit card(R, R \ R i ) = (n, m) . 

In unserem Beispiel gilt z.B. die Einschränkung, daß erst dann ein Eintrag in die Klasse legtab geführt wird, 

wenn der Student eine Vorlesung erfolgreich abgelegt hat. 

Die Lookup-Bedingung look(legtab, Ablageform) = 0..2 stellt dar, daß nur Prüfung und Schein bzw. 

Schein und Praktikum bzw. Prüfung und Praktikum absolviert werden müssen. Diese Bedingung ist äquivalent 

zu 

card(legtab, Student Vorlesung) = (0,2). 

Eine Kardinalitätsbeschränkung card(R, R i ) = (0, 1) ist äquivalent zur funktionalen Abhängigkeit R : 

{R i } → R . 

Eine Lookup-Kardinalitätsbeschränkung look(R, R i ) = 0..1 ist äquivalent zur funktionalen Abhängigkeit 

R : R \ {R i } → R . 

Spannend ist das Zusammenwirken von card und look. 

Wir betrachten z.B. einmal einen Relationshiptypen in Bild 

Mod IS 

IS ADD


Weiterhin können wir z.B. fordern, daß nur solche Vorlesungen als gehalten gelten, die auch zu studentischer 

Beteiligung geführt haben. Dies wird durch card(legtab, Vorlesung) = (1,n) dargestellt. 

Eine strengere Bedingung ist, daß dies auch für das Semester gelten muß. Dann können wir spezifizieren 

look(legtab, Student) = 1..n bzw. card(legtab, Vorlesung Semester) = (1,n). 

Für Relationship-Typen mit eigenen Attributen ist die Lookup-Notation in verschiedenen Formen definiert. 

(DBIV,SS2002,β) 

(DBI,WS2002,β) 

(Compiler,SS2002,PB) 

(Informatik III,WS2002,BvB) 

(Informatik III,WS2003,β) 

◦ 

◦ ◦ ◦ 

◦ 

◦ 

◦ 

◦ ◦ ◦ 

◦ 

◦ 

◦ 

◦ 

Schein 

Prüfung 

◦ Praktikum 

Antje Bärbel Cornell Doris Emil Fjodor 

Abbildung 18: Beziehungen der Objekte im Vorlesungsbeispiel 

Wir betrachten in diesem Beispiel in Bild 18 eine kleine Klasse mit 14 Objekten. Z.B. hat Bärbel sowohl die 

(Informatik III,WS2002,BvB) als auch (DBIV,SS2002,β) mit Prüfung und Schein abgelegt, Emil dagegen nur 

Scheine in (Informatik III,WS2002,BvB) und (DBI,WS2002,β). 

Kardinalitätsbeschränkungen sind mitunter nicht erfüllbar in nicht-leeren, endlichen Klassen. Ein Beispiel einer 

solchen nicht-erfüllbaren Menge von Integritätsbedingungen ist das Paar 


card(Voraussetzung, vorausgesetzt) = (3,4) . 

Wir können dies einfach nachvollziehen, indem wir eine endliche Menge von Vorlesungen z.B. {a, b, c, d, e} 

betrachten. Mit der Kardinalitätbeschränkung card(Voraussetzung, vorausgesetzt) = (3,4) kann man z.B. folgende 

Besetzung für Voraussetzung betrachten: 

{(a, b), (a, c), (a, d)} wird dann weiter fortgeführt zu {(a, b), (a, c), (a, d), (b, a), (b, c), (b, d)}. Damit kommen 

c, d in keiner Beziehung auf der rechten Seite mehr vor aufgrund von 

card(Voraussetzung, setztVoraus) = (0,2). Wir setzen also fort mit {(c, a), (c, b), (c, e)}. Nun sind auch a, b 

“verbraucht”. Dann haben wir bereits für d als linke Seite nicht genug Elemente auf der rechten Seite. Wir 

benötigen also noch f, g. Wir können nun weiter fortsetzen und erkennen, daß nur die leere und eine unendliche 

Menge von Vorlesungen diese Kardinalitätsbeschränkungen erfüllen. 

Dagegen ist 


card(Voraussetzung, vorausgesetzt) = (3,4) 

erfüllbar und impliziert 


card(Voraussetzung, vorausgesetzt) = (3,3) . 

Mehrwertige Abhängigkeiten stellen im Entwurf i.a. die Separation von Gesichtpunkten bzw. Aspekten dar. Sie 

werden oft weggelassen, da ihre mathematische Notation schwierig nachzuvollziehen ist. 

Eine mehrwertige Abhängigkeit X → Y |Z wird für einen Typ R = (U R , Σ R ), mit Teilmengen X, Y ⊆ 

U R und Z = U R \ (Y ∪ X) definiert und gilt in einer Klasse Relation R C über R (dargestellt durch R C |= 

X →→ Y |Z ), falls für alle o, o ′ ∈ R C , die den gleichen Wert für die X-Elemente von R haben, ein Objekt 

o ′′ in R C existiert, das aus der Faltung von o und o ′ hervorgehen kann, d.h. formal 

für alle o, o ′ ∈ R C mit o = X o ′ existiert ein Objekt o ′′ ∈ R C mit o ′′ = X∪Y o und o ′′ = X∪Z o ′ . 

Mod IS 

IS ADD


Eine nützliche, allgemein bekannte Eigenschaft von mehrwertigen Abhängigkeiten ist die Dekompositionseigenschaft. 

Es gilt R C |= X →→ Y |Z genau dann, wenn sich R C nach X ∪ Y und X ∪ Z vertikal 

dekomponieren läßt, d.h. formal R C = R C [X ∪ Y ] ✶ R C [X ∪ Z] . 

Weniger bekannt ist dagegen, daß die Gültigkeit der mehrwertigen Abhängigkeit zu einem neuen äquivalenten 

Schema führt, bei dem der Typ R durch die dekomponierten Typen wie in Bild 19 ersetzt wird. 

Y ✛ XY ✲ X ✛ XZ ✲ 

Z 

Abbildung 19: Die Zerlegung von R in zwei Relationship-Typen 

Weitere relationale Integritätsbedingungen, z.B. Wertebereichsabhängigkeiten, können im erweiterten ER- 

Modell verwendet werden. So gilt in unserem Beispiel 

Semester.Bezeichnung 

∈ {W S, SS} × {x/x+1|x ∈ 80..99, 00, 01, 02, ..., 17} . 

Andere wichtige Klassen von Abhängigkeiten sind Exklusions- und Inklusionsabhängigkeiten. 

Probleme mit Integritätsbedingungen 

Zerstörung der Lokalität durch globale Auswirkungen innerhalb von Zyklen 

{ 1 } 

Reise 

✻ 

✛ besucht 

{ 3,4,7 } 

richtig: { 3 } 

{ 1,2,3,6 } richtig: { 6 } 

❄ 

startet 

✲ 

{ 2,3,5,6 } 

richtig: { 2 } 

Stadt 

Abbildung 20: Lokale Integritätsbedingungen mit globalen Auswirkungen 

Pivotisierung durch Identifikation von faktorisierbaren Konstrukten z.B. Integritätsbedingungen, die auf Fakten hinweisen 

Globalisierende Integrititätsbedingungen hervorgerufen durch Zyklen 

weitere Beispiel in Hartmann-Habil 

Löcherfraß in den Integritätsbedingungen durch Nichterfüllbarkeit für Konfigurationen 

siehe Hartmann-Mitteilung 

Warum dann HERM anstatt von UML. 

Mod IS 

IS ADD


Übungsleiter 

❨ 

0..1 

Professor ✛ 

Kurs 

✻ 

Vorlesung 

Plan 

Übungsleiter✛ 

Professor ✛ 

betreut 

❄ 

Vorlesung 

✲ 

(3,5) 

Kurs 

✻ 

Angebot 

✙ 

Stud-Gang 

❄ 

Semester 

✙ 

Stud-Gang 

Plan 

❄ 

Semester 

look(Vorlesung,Übungsleiter) = 0..1 card(Vorlesung, Kurs Semester) = (3,5) 

Abbildung 21: Pivotisierungsauswirkungen lokaler Integritätsbedingungen in zwei Facetten 

Institution leitet ✲ 

(0,2) 

✻ 

(0,.) 

(1,1) 

❄ 

fördert ✲ Projekt ✛ 

(1,.) 

(0,5) 

Mitarbeiter ✛ arbeitet in 

(1,1) 

✻ 

(1,3) 

(30,50) 

❄ 

zugeordnet ✲ Labor 

(0,10) 

richtig: (0,30); besser (0,.) 

Abbildung 22: Globale Verwicklungen lokaler Integritätsbedingungen 

Übung: 

• EER-Modelle 

• Struktur 

• Komponenten 

• stat. Integritätsbed. 

Global versus Local Normalisation. 

Normalisation is typically carried out on the basis of one database type. This type is normalised (e.g. decomposed, split or reduced) according 

to a set of integrity constraints. The association and the influence of this normalisation to other types is typically neglected. Therefore, 

normalisation is typically local. 

Local normalisation of a singleton database type is well reflected in most database books (e.g., [AHV95, Bis95, Leo92, Yan86]) and 

publications, most database courses, and in actual database practice. It is considered as one of the pearls of database research and known 

to almost everybody who knows database technology. The provenance and acknowledgement is based on the facility it provides: keeping as 

much as possible locally and globally supporting only those processes that are inherently global. Both independence concepts of databases 

(conceptual independence and implementation independence) are based on localisation. 

Local normalisation of database structures aims in derivation of such structures of databases that can easily be supported by the DBMS. 

In the past DBMS have been supporting keys, domain constraints and key-based inclusion constraints. Therefore, it is a goal to derive another 

equivalent schema to the given one which has an equivalent but supportable set of integrity constraints. This approach can be understood as a 

procedural approach to optimisation of database structuring depending on the platform for implementation. 

Normalisation is typically considered to be vertical normalisation. Deductive normalisation and horizontal normalisation are alternatives 

to vertical normalisation. 

Horizontal normalisation [PBGG89] is based on selection and union. Horizontal normalisation uses selections based on predicates 

α 1 , ..., α n which may be pairwise exclusive (α i → ¬α j , i ≠ j) and cover the truth value 1 (( ∧ n 

i=1 α i) → 1). Horizontal normalisation also 

allows us to separate the part of a set for which a dependency is valid from the part that invalidates a dependency. For instance 2 , α X−→Y = 

2 We use the symbol R for type or class specification and denote the class of elements of the type by R C . Tuples (in the case of objectrelational 

models) or elements of R C are denoted by o. X −→ Y is a functional dependency. 

Mod IS 

IS ADD


(o ∈ R C → ¬∃o ′ ∈ R C (o[X] = o ′ [X] ∧ o[Y ] ≠ o ′ [Y ])) separates those objects in R C for which the functional dependency is valid from 

those which invalidate the functional dependency. 

Deductive normalisation [Tha91a] is based on reduction and extended selection. Deductive normalization reduces relations to 

those elements that cannot be generated from the other elements by generation rules. It is the most storage effective and the best computational 

method for normalisation as long as the tuple-generating dependency used for decomposition is acyclic. Horizontal and deductive normalisation 

methods have not yet received a support from the database systems vendors. Local normalisation must however take into account these three 

kinds of normalisation. 

Global normalisation aims in normalisation of the schema as a whole. It must take into account the three kinds of local normalisation. 

Global normalisation has not got an appropriate attention in research despite the interest in implementations. Therefore, a systematic treatment 

of this normalisation has not yet been given in the literature. 

2.3.4 Rahmen zur Spezifikation von Integritätsbedingungen 

Integritätsbedingungen werden in der Literatur noch immer leichtfertig nur in einfacher Form bzw. Rohform spezifiziert. 

Eine Spezifikation der Integritätsbedingungen muß umfassen: 

Integritätsbedingung in Rohform: Angabe der Integritätsbedingung als logische Formel 

Lokalisierung der Integritätsbedingung im Kontext des Systemens, d.h. 

durch Angabe der Schema-Umgebung einer Integritätsbedingung (Schema-Frame-Problem) und 

durch Angabe der betroffenen Datenbankobjekte, die neben den betroffenen Objekten kontrolliert werden 

müssen (DB-Frame-Problem) 

Gültigkeit der Integritätsbedingungen je nach Phase der Anwendung, mindestens für die folgenden Phasen 

Einfahrphase des Systemes 

Normallauf des Systemes 

Archivierung der Datenbestände 

Ausführungsmodi zur Kontrolle der Integritätsbedingungen je nach Operation 

Ausführungszeit der Kontrolle z.B. verzögert, sofort ggf. auch mit Aussetzen unter bestimmten Bedingungen 

Anwendungsmonitoring der Kontrolle der Integritätsbedingungen z.B. auf Objektniveau oder auf Anweisungsniveau 

Umformung (term rewriting) der Operationen 

Behandlung für den Fall des Nichtgeltens der Integritätsbedingung je nach Datenbankereignis: 

Zurückweisen der verursachenden Anweisung 

Propagierung der Integritätsbedingung 

Nutzung von (temporären) Zusatzwerten zur Kennzeichnung der Situation 

Rangordnung der Integritätsbedingung unter den Klassen von Integritätsbedingungen zur Ableitung der Kontrollreihenfolge 

Daneben können wir Default-Rahmen angeben: 

1. harte Integritätsbedingung ohne das Zulassen von Ausnahmen 

2. volle Schema- und DB-Umgebung 

3. keine Unterscheidung von Phasen 

Mod IS 

IS ADD


4. sofortige Kontrolle bei Datenbankereignissen ohne Ergänzung der Operationen 

5. gleichwertige Klassen von Integritätsbedingungen 

Insbesondere nutzen wir die folgenden Rahmen und Erzwingungsmodi: 

1. Spezifikation von Existenzabhängigkeiten 

Durch die Komplexitäten sind bereits Abhängigkeiten dargestellt worden, die von den generischen Operationen 

insert, delete, update eingehalten werden müssen. Ist für eine Komplexität comp(R, R ′ ) = (a, b) a ≥ 1, dann 

ist jedes insert in R ′ durch ein insert in R zu unterstützen. Jedes delete in R ′ kann ein delete in R nach sich 

ziehen. Alle derartigen Komplexitäten werden zusammengestellt und in den folgenden Schritten angewandt. 

Man kann für jeden Typen eine insert-, delete- und eine update-Umgebung mit folgendem Algorithmus konstruieren. 

(a) Env I (R) := Env D (R) := Env U (R) := {R} für jeden Entity- und Relationshiptypen. 

(b) Man generiere die Umgebungend erster Ordnung wie folgt. 

i. Gilt comp(R, R ′ ) = (a, b) für a ≥ 1 dann sei Env I (R) := Env I (R ′ ) ∪ Env I (R), Env U (R) := 

Env U (R ′ ) ∪ Env U (R) und Env D (R ′ ) := Env D (R) ∪ Env D (R). 

ii. Für jeden Relationshiptypen R ′ , in dem R eine Komponente bildet: Env I (R ′ ) := Env I (R) ∪ 

Env I (R ′ ), Env U (R ′ ) := Env U (R) ∪ Env U (R ′ ) und Env D (R) := Env D (R) ∪ Env D (R ′ ). 

iii. Für jede Exklusionsabhängigkeit R ‖ R ′ gilt Env I (R ′ ) := Env D (R)∪Env I (R) und Env U (R ′ ) := 

Env U (R) ∪ Env U (R). 

iv. Weitere Abhängigkeiten werden analog behandelt. 

(c) Man wiederhole diesen Schritt bis keine der Mengen verändert wird: 

i. Gilt comp(R ′′ , R ′ ) = (a, b) für a ≥ 1 und R ′′ ∈ Env I (R ′ ) dann sei Env I (R) := Env I (R ′ ) ∪ 

Env I (R). Gilt comp(R ′′ , R ′ ) = (a, b) für a ≥ 1 und R ′′ ∈ Env U (R ′ ) dann sei Env U (R) := 

Env U (R ′ ) ∪ Env U (R). Gilt comp(R ′′ , R ′ ) = (a, b) für a ≥ 1 und R ′′ ∈ Env D (R ′ ) dann sei 

Env D (R ′ ) := Env D (R) ∪ Env D (R). 

ii. Für jeden Relationshiptypen R ′′ mit R ′′ ∈ Env I (R ′ ), in dem R eine Komponente bildet, sei Env I (R ′ ) := 

Env I (R) ∪ Env I (R ′ ). Für jeden Relationshiptypen R ′′ mit R ′′ ∈ Env U (R ′ ), in dem R eine Komponente 

bildet, sei Env U (R ′ ) := Env U (R) ∪ Env U (R ′ ). Für jeden Relationshiptypen R ′′ mit 

R ′′ ∈ Env D (R ′ ), in dem R eine Komponente bildet, sei Env D (R) := Env D (R) ∪ Env D (R ′ ). 

iii. Für jede Exklusionsabhängigkeit R ‖ R ′′ mit R ′′ ∈ Env I (R ′ ) gilt Env I (R ′ ) := Env D (R) ∪ 

Env I (R). Für jede Exklusionsabhängigkeit R ‖ R ′′ mit R ′′ ∈ Env U (R ′ ) gilt Env U (R ′ ) := 

Env U (R) ∪ Env U (R). 

iv. Weitere Abhängigkeiten werden analog behandelt. 

Diese Umgebungen sind maximale Umgebungen. Sie werden durch Eigenschaften der Anwendung eingeschränkt. 

Durch die Hierarchien sind entsprechende Existenzabhängigkeiten gegeben. Die Generalisierung (z.B. eine 

Person-de-jure ist eine Firma oder eine Person) führt zu einer Existenzabhängigkeit des Supertypen von Subtypen, 

die unbedingt gepflegt werden muß (d.h. werden die Daten einer Firma entfernt, dann werden diese 

auch für die Persona-de-jure entfernt). Die Spezialisierung führt zu einer Existenzabhängigkeit des Subtypen 

(in unserem Falle Teiltypen (Relationshiptypen definiert über dem Supertypen)) vom Supertypen. 

2. Erzwingungsregeln für insert- Operationen 

Man kann für insert-Operationen verschiedene Optionen bestrachten: 

• Abhängigkeit: Eine Einfügung ist nur erlaubt, wenn alle korrespondierenden Objekte bereits existieren. 

Mod IS 

IS ADD


• Automatismus: Eine Einfügung ist stets erlaubt. Wenn entsprechende Objekte nicht existieren, dann werden 

sie ebenfalls eingefügt. 

• Nullwertebehandlung: Eine Einfügung ist stets erlaubt. Existieren die entsprechenden Objekte nicht, dann 

werden für das neue Objekt Nullwerte benutzt. 

• default-Werte: Eine Einfügung ist stets erlaubt. Existieren die entsprechenden Objekte nicht, dann werden 

für das neue Objekt default-Werte benutzt. 

• Zusätzliche Einfügebedingungen: Ein Einfügen ist nur dann erlaubt, wenn eine zusätzliche Bedingung 

gilt. 

• Keine Einschränkung: Das Einfügen unterliegt keiner Beschränkung. 

Die letzten beiden Möglichkeiten betreffen alle Typen außerhalb von Env I (R). Die ersten vier Möglichkeiten 

sind für Env I (R) bei der Spezifikation der Anwendung zu nutzen. 

3. Erzwingungsregeln für delete-Operationen 

Man kann für delete-Operationen verschiedene Optionen bestrachten: 

• Beschränkung: Ein Streichen ist nur erlaubt, wenn kein anderes Objekt davon betroffen ist. 

• Kaskadierung: Ein Streichen zieht das Streichen anderer Objekte nach sich. 

• Bedingte Kaskadierung: Ein Streichen zieht das Streichen anderer Objekte nach sich, die nur aufgrund 

des zu streichenden Objektes noch existieren. 

• Nullwertebehandlung: Beim Streichen werden Objekte, in die das Objekt eingeht auf einen Nullwert 

gesetzt. 

• default-Werte: Beim Streichen werden Objekte, in die das Objekt eingeht auf einen Nullwert gesetzt. 

• Zusätzliche Streichungsbedingungen: Das Streichen ist nur unter bestimmten Bedingungen erlaubt. 

• Keine Einschränkung: Das Streichen unterliegt keiner Beschränkung. 

Die letzten beiden Möglichkeiten betreffen alle Typen außerhalb von Env D (R). Die ersten vier Möglichkeiten 

sind für Env D (R) bei der Spezifikation der Anwendung zu nutzen. 

SQL2 läßt in der Vollversion Kaskadierung, Nullwertebehandlung, Default-Werte und Beschränkung (ist default) 

(als ‘no action’) zu. 

4. Erzwingungsregeln für update-Operationen 

• Beschränkung: Ein update ist nur erlaubt, wenn kein anderes Objekt davon betroffen ist (z.B. auch über 

Sekundärschlüsseln, die nicht in Beziehungen verwandt werden). 

• Automatismus: Ein update ist stets erlaubt, solange Integritätsbedingungen des Typs nicht verletzt werden. 

• Kaskadierung: Ein update löst weitere Operationen aus. 

• Nullwertebehandlung: Konflikte werden durch Nullwerte gelöst. 

• default-Werte: Zur Konfliktbereinigung werden default-Werte benutzt. 

• Zusätzliche update-Bedingungen: Ein update ist nur unter zusätzlichen Bedingungen möglich. 

• Keine Einschränkung. 

Eine update-Operation ist nicht das Gleiche wie eine delete;insert-Folge. 

SQL2 läßt in der Vollversion Kaskadierung, Nullwertebehandlung, Default-Werte und Beschränkung (ist default) 

zu. 

Mod IS 

IS ADD


Erzwingungsregeln 

✙ 

Unbedingte 

Erzwingung 

❄ 

Keine 

Erzwingung 

❥ 

Bedingte 

Erzwingung 

Kaskadierung 

Abhängigkeit 

✙ ❄ ❥ 

Nullwertebehandlung 

default- 

Werte 

❄ 

an Existenz 

gebunden; 

Rollback 

Abbildung 23: Mögliche Erzwingungsregeln für generische Operationen 

❥ 

mit zusätzlichen 

Einfügebedingungen 

; 

Prädikat 

Die Erzwingung kann auch aufgrund von Regel-Trigger-Systemen spezifiziert werden. Dann ist jedoch das Resultat 

bei automatischer Erzwingung falsch. Der GCS-Zugang von Schewe/Thalheim ist ein sicherer automatischer 

Zugang. Er ist allerdings für die Betrachtungen hier zu komplex. 

Die Integritätsbedingungen sind in SQL-92 in unterschiedlichen Modi und Matching unterstützt, wobei deren 

Zusammenwirken nicht erklärt ist. 

Integrity Constraint Specification. 

Integrity Constraint ϕ 

[Localization: < unit name> ] 

[Partiality: < validity condition >] 

[Exception: < exception condition >] 

[In-Context: < enforcement rule, time, granularity >] 

[Out-Context: < conditional operation, accept on >] . 

Enforcement through 

Direct enforcement through declarative constraints with RESTRICT, NO ACTION, CASCADE, SET VALUE (null, default), [INITIALLY] DEFERR 

[INITIALLY] IMMEDIATE [DEFERABLE] 

Transactions with three mechanisms on failure: 

(1) rollback on inconsistency currently exclusive treatment 

(2) erasing effects of TA: transaction COMPENSATED_ON_FAILURE_BY transaction 

(3) raising an exception: transaction CONTINGENTED_ON_EXCEPTION_BY exception 

Triggers with the after-before activation time, row-statement granularity, 

1-n (SQL:1999, DB2, Informix, SQL Server) , n-1 (Sybase) or n-n (Ingres,Oracle) event-trigger pairs 

IC enforcement policy - checking mode (immediate, deferred), triggering, scope, checking time (before, after), row/statement level 

Problems to be Solved for Maintenance. 

A: Integrity preservation with consideration of enforcement policies 

User-defined types 

SQL’99 constraints in a large variety: 

Checking mode 

Choice of statement or row level 

Constraints may be pre- or post-conditions 

Scope conditions 

Matching conditions 

Reference types 

Triggers in variations: 

Number of triggers per events and events per triggers 

Mod IS 

IS ADD


Activation time 

Conflict resolution of execution order 

Order of constraint check differs for DB2 Sybase, Oracle, Informix, Ingres, and MS SQL 

SQL’92 declarative constraints 

B: Effect preservation of the intended update operation 

Insert effect preservation 

Delete effect preservation 

Update effect preservation 

Resultierende Betrachtungen für die Pflege der Integritätsbedingungen. 

• Problems of Integrity Maintenance 

Incompleteness of maintenance 

Infeasibility of maintenance 

Infeasibility of programming 

• Integrity maintenance is based on: 

Integrity constraint checking 

Integrity constraint detection 

• Integrity maintenance suffers from: 

Non-existence of integrity constraint axiomatisation 

Complexity of constraint check 

Complexity of database maintenance 

SQL’99 Proposals for Transactions and Consistency Specification. 

Level of enforcement: On row-level or on statement level 

Modus of enforcement: Immediate or deferred 

Equality functions: full, partial, normal 

differences in treatment of null values 

Check time for constraints: Before execution, after execution 

Hinzu kommt dann noch die Herstellung einer globalen Konsistenz der Erzwingungsmechanismen. Man betrachte 

z.B. die Erzwingung in Bild 24. 

R 1 

✾ 

R 2 

restrict 

✙ 

R 3 

nullify 

cascade 

❥ 

R 4 

cascade 

3 

R 5 

cascade 

❄ 

R 6 

cascade 

❄ 

R 6 

nullify 

❄ 

R 6 

default 

❄ 

R 6 

restrict NULL NIL ??? DEFAULT 

Abbildung 24: Das ‘diamond’-Problem bei der Erzwingung von foreign key constraints 

Es werden zwei Wertezuweisungen für den Wert des gleichen Objekts in R 1 vorgenoomen ausgehend von gleichen 

Objekt in R 6 . Die zugehörigen foreign key constraints sind R 2 ⊆ R 6 , R 3 ⊆ R 6 , R 4 ⊆ R 6 , R 5 ⊆ R 6 , R 1 ⊆ 

R 2 , R 1 ⊆ R 3 , R 1 ⊆ R 4 , R 1 ⊆ R 5 , . 

Mod IS 

IS ADD


2.4 Ein Datenbank-Schema 

ER besteht aus einer Menge von Typen {T i = (U Ti , Σ Ti )} und globalen statischen Integritätsbedingungen Σ ER . 

Datenbankmodellierung und das Abstraktionsschichtenmodell 

Unsere Strukturierungssprache unterstützt das Abstraktionsschichtenmodell. Es kann die Strukturierung der Daten 

in jeder Schicht durch das Entity-Relationship-Modell repräsentiert werden. Wir verwenden dazu Schemata unterschiedlicher 

Abstraktheit und Granularität. 

Datenstrukturierung des Lastenhefts: Es wird ein allgemeines HERM-Diagramm mit den Haupttypen entwickelt. 

Datenstrukturierung des Pflichtenhefts: Es wird ein grobes HERM-Diagramm mit entsprechenden Integritätsbedingungen 

angegeben, das die Typen des Lastenhefts verfeinert. Die Verfeinerung findet durch Spezialisierung 

der Typen, Dekomposition, strukturelle Erweiterung, semantische Einschränkung, Separation von Aspekten 

und durch Instantiierung statt. Zusätzlich werden weitere Typen eingeführt. 

Anwendungsschema: Das Anwendungsschema repräsentiert alle Typen, die für den Anwender eine Bedeutung 

haben. Die Typen stellen eine Verfeinerung der Typen des Pflichtenhefts dar oder sind neu eingeführt. 

Konzeptionelles ER-Schema: Auf der konzeptionellen Schicht wird ein detailliertes HERM-Diagramm erstellt, 

das u.a. auch für alle Typen des Anwendungsschemas entsprechende Verfeinerungen enthält. Diese Beziehungen 

finden auch Eingang in die Sichten-Suite. 

Logisches Schema: Das HERM-Schema wird in ein entsprechendes Schema des logischen Datenbank-Modelles 

transformiert. Es kann üblicherweise ein objekt-relationales oder relationales Schema, aber auch eine Beschreibung 

als XML-Schema oder DTD-Datei (document type definition) sein. 

Diese Schemata sind aufeinander abbildbar. Demzufolge kann jede Entwurfseinheit einer höheren Schicht - so wie 

in Bild ?? auf Seite ?? dargestellt - einer Menge von Entwurfseinheiten der folgenden Schicht direkt zugeordnet 

werden. 

Wir merken an, daß wir über zwei unterschiedliche Methoden zur Darstellung, Repräsentation, Verarbeitung und 

Speicherung von Objekten verfügen: 

Klassen-Separation: Die Menge aller Objekte wird durch ein ER-Schema dargestellt. Jedes Objekt wird genau 

einer Klasse zugeordnet und in beliebig vielen anderen Klassen auf der Grundlage des ER-Schemas verwendet. 

Die Verwendung kann über einen Surrogat-Schlüssel, eine Markierung oder Werte zum ausgewählten Schlüssel 

des Objektes erfolgen. 

Wir nennen diese Form der Behandlung von Objektmengen klassen-separierte Darstellung. Ein Objekt ist 

dann mit dem erweiterten ER-Modell als Schneeflocke mit einer Wurzel darstellbar. 

Objekt-Entfaltung: Die Menge aller Objekte bildet unter Einbeziehung der Beziehungen der Objekte untereinander 

einen Objektmengen-Graphen. Wir können über diesem Graphen beliebige Überdeckungen U bilden, 

d.h. Mengen von Teilgraphen, die zusammen den Objektmengen-Graphen ergeben. Ein Teilgraph besitzt evt. 

ein Wurzel-Objekt, d.h. es gibt ein Objekt, das rekursiv auf alle anderen Objekte des Teilgraphen verweist. 

Besitzt jeder dieser Teilgraphen ein Wurzelobjekt, dann heißt U Objekt-Gesellschaft. 

Damit ist in Objekt-Gesellschaften jedes Objekt ein volles Objekt mit allen Eigenschaften. 

Ein Beispiel für eine Objekt-Entfaltung zum Schema in Bild 6 ist folgendes XML-Dokument: 

 

 

 

Mod IS 

IS ADD



Vorstudie 

Skizzierung 

Konzeptlandkarte 

Konzept 

Lastenheft: Daten 


Feinstudie 

Darstellung 

Skizze 

Grober Typ 

Pflichtenheft: Daten 


Entwurf 

Entwurf 

Skelett 

Anwendungstyp 

Anwendungsschema 

konzeptionelle 

Schicht 



Schema 

Typ 

ER-Schema 


Schema 

logischer 

Typ 

logisches Schema 

Abbildung 25: Die Arbeitsprodukte im Abstraktionsschichtenmodell für die Strukturierung 

Mod IS 

IS ADD


Montag 

Mittwoch 

 

 

Normalvorlesung 2+2+2 

.... ... 

Sommersemester 2000, 10.4. 2000 - 15.7.2000 

 

 

Fak.-Ref. Schenk 

1.4.1999, .... 

AB, Montag, 7.30-11.00 

Beamer, Netzanschluß 

Datenbanken I 

 

Die erste Methode wird meist für die Speicherung und Verarbeitung in relationalen und objekt-relationalen DBMS angewandt. 

Die Repräsentation erfolgt auf der Grundlage von Sichten, die im Kapitel ?? ausführlich dargestellt werden. 

OLAP-Zugänge verwenden oft den zweiten Zugang. Die zweite Methode wird auch bei XML-DBMS angewandt. 

Die Redundanz-Beherrschung ist nach wie vor für beliebige Objektmengen wichtig. Deshalb ist der erste Zugang 

vorzuziehen. Wir unterstützen diesen Zugang durch Einführung einer Sichten-Suite. 

Mod IS 

IS ADD


2.5 Ausgewählte Muster von Referenzschemata 

2.5.1 Werte, Beobachtungen und Messungen 

The assignment of values is often not as simple as stated. Quantities must be given together with their units of 

measure. The placement of quantity properties either as attribute type or as relationship type depends mainly on the 

usage of the property either as characterisation or as associating property. Additionally, reuse of the same kind of 

representation may lead to an introduction of a separate entity type. 

Beside the assignment of values we also need to consider the conversion of units. The schema in Figure 26 shows 

one possible generic representation that might be used a the general units conversion dimension. 

Unit 

to 

✛ 

from 

✛ 

Conversion 

factor 

✲ 

Number 

Abbildung 26: Conversion of units of measure 

If many units must be converted then the physical dimension comes into play. Also, international standards such 

as S.I. standards must then be considered. 

Often conversion factors are dynamic, e.g. exchange rates. 

Units of measure are often complex units, e.g. consumption. If we need a direct representation we might use the 

schema in Figure 27. 

Unit 

✛ 

Negative 

✲ 

(0,1) 

Atomar 

unit 

✛ 

Positive 

✲ 

Complex 

unit 

(0,n) 

Abbildung 27: Direct representation of complex units 

Measurement and observations are typically based on a separation into the knowledge level and the activity of 

observing or measuring. So we might record this activity directly as displayed in Figure 28. 

Type of 

phenomenon 

Knowledge/strategic level 

Temporal/tactical level 

✻ 

Person 

✛ 

Measurement 

✲ 

Quantity 

Abbildung 28: Activity of measuring 

This picture might be more complex if we consider that measurements and most observations are subjective. 

We explicitly introduce Observations in Figure 29. 

Additionally, observations may be co-related (see, for instance, Figure 30). 

Also, we might have to distinguish between the type of phenomenon and the phenomenon itself. So Figure 29 

becomes extended to Figure 31 

IS ADD



phenomenon 

✻ 

Measurement 

✒ 

✲ 

Quantity 

Person 

✛ 

Observation ⊕ 

✲ 

Perception 

✲ 

Category 

Abbildung 29: Activity of observing 

Observation 

✛ 

Judgement 

✛ Co-relation 

Hint 

Abbildung 30: Recursive relationships to for observations 


phenomenon 

✛ 

Phenomenon 

❑ 

✻ 

Measurement 

✒ 

✲ 

Quantity 

Person 

✛ 


✲ 

Perception 

✲ 

Category 

Abbildung 31: Activity of measuring, observing and perceiving 

IS ADD


The phenomenon might be bundled by a concept of perception. The information whether we perceive a category 

or not will also have to recorded for certain purposes. So, we need to capture that in Figure 32. At the same time, 

observations might be classified as wrong, erroneous or rejected. Also, we might want to distinguish which type of 

observation is made: hypothesis, projection, or active observation. 

Person 

✛ 


phenomenon 

✻ 

✛ 

⊕ 

Observation 

Phenomenon 

Perception ✛ 

✒ ❦ 

✲ Measurement 

✲ 

✶ 

Concept of 

perception 

Negative 

perception 

Positive 

perception 

Active 

observation 

Hypothesis 

Projection 

 

✲ 

✸ 


observation 

✠ 

✻ 

Rejected 

observation 

❄ 

Quantity 

Abbildung 32: Activity of measuring, observing and perceiving 

Finally, the association of observations might be based on constructors for associating observations. So, the picture 

becomes more complex and can be represented by a schema similar to the one in Figure 33. 

Arguments 

for selection 

❄ 

Association 

function 

✲ 

❘ 


observation 



✻ 

✻ 

Associated 

observation 

✻ 

✲ 

Observation 

✒ 

Hints 

for selection 

Abbildung 33: Associations and constructors for observations 

Observation is still an overloaded concept. Additionally, we need to establish a recording or protocolling component 

with the schema. We therefore extend the schema in Figure 32 to the schema in Figure 34. This schema omits 

some of the types of the former schema 

IS ADD


Comparison-based 

measurement 

method 

Computed 

measurement 

protocol 

✲ 

Computing 

method 

✛✢ 

Causal 

measurement 

method 

❄ 

Protocol 

prototype 

✛ 

Is For TypeOPr 

✲ 


phenomenon 

✛ 

Phenomenon 

✲ 

✶ 


perception 

✻ 

Source 

measurement 

protocol 

❪ 

Protocol 

✲ 

✻ 

⊕ 

Observation 

Perception 

✒ 

✲ Measurement 

✯ 

Quantity 

✲ 

Method of 

measurement 

❄ 

Person 

✠ 

❄ 

Object under 

observation 

❘ 


observation 

❘ 

Planning 

Abbildung 34: Activity of measuring, observing and perceiving, protocolling and planning (without positive and 

negative observations and perceptions) 

Measurement is typically based on the Factory-Method pattern. Measurement and to a certain extent observations 

are based on data. So, the type Quantity is a complex type or a schema by themselves. We therefore should 

shuffle the state under consideration into the schema in Figure 34. 

Typically quantity is based on a a state. The explicit representation of state with different sub-states allows to 

apply the state pattern to measurement processes. The state pattern allow an object to alter its behaviour when its 

internal state changes. Figure 35 displays the first schema draft for state representation. 

The comparison operator is complex. Therefore, we shuffle the complex units schema displayed in Figure 27 into 

this schema. Another shuffle schema to be incorporated into this schema is the schema for the representation of dates 

and moments. 

2.5.2 Zeitmodellierung 

Date is either based on the current calendar (for instance, finance year, study period) or on specific representation of 

time. Data may be temporal and depend directly on one or more aspects of time. We distinguish three orthogonal 

concepts of time: temporal data types such as instants, intervals or periods, kinds of time, and temporal statements 

such as current (now), sequenced (at each instant of time) and non-sequenced (ignoring time). Kinds of time are: 

existence time, lifespan time, transaction time, change time, user-defined time, validity time, and availability time. The 

first two kinds of time are not considered in databases since they are integrated into modelling decisions. Temporal 

data are supported by specific temporal functions. These functions generalize Allen’s time logic [All84]. 

2.5.3 Geometrie-Modelle 

2.5.4 Interval-Modellierung 

The representation of intervals is a typical task in most information systems applications. Figure 36 display a general 

injection schema for interval representation. 

IS ADD


Comparison 

operator 

■ 

Duration 

✻ 

✻ 

✒ 

Date 

✯ 

State 

✛ 

Real 

state 

✲ 

State type 

✠ 


❄ 

✲Measurement 

❘ 

✲ 

❪ 

Method of 

measurement 

❘ 

Planning 

Planned 

state 

✲ 

Planning 

of state 

Abbildung 35: Considering states for measurement 

Object life 

period 

Boolean 

✛Lower bound 

included 

✛Upper bound 

included 

❄ 

Interval 

Lower 

bound ✲ 

Upper ✲ 

bound 

Value 

type 

Abbildung 36: Representation of intervals 

IS ADD


This constructor is also applicable to the construction of complex observation types. 

2.5.5 Geschichtete Modellierung 

Responsibilities are typically based on the kind/type-of constructor. The schema in Figure 37 displays responsibilities 

in dependence on their kind and the association to parties. Organisations have a structure that is valid in certain time 

periods. It is constructed depending on the structure type that has been chosen. This structure type is based on the 

regulations for construction. 

Fixed 

Temporal 


type 

✛ 

requested by ✲ 


responsible ✲ 

Party 

❄ 

❄ 

Regulations 

Time 

frame 

Abbildung 37: The assignment of responsibilities to parties 

We notice again that such structures are typical for schemata that represent at the same time strategic information 

or knowledge and tactical information or data. 

We can extend this pattern by associating the kinds upon which the types are based. For instance, the schema may 

be fold for representation of actions or activities. At the same time, parties may be hierarchically structured. 

Regulations ✛ 


requested by ✲ 


type 

responsible ✲ 

✻ 

Party 

type 

✻ 


for 

✲ 

requested by 


responsible 

✲ 

✲ 

Party 

(0,n) 

(0,1) 

❄ 

❄ 

Action 

Time 

frame 

Abbildung 38: The assignment of responsibilities to parties 

The roles of responsibilities must be a specialisation of the roles of the corresponding responsibility type. A 

similar requirement may be enforced for the hierarchies. 

Responsibilities may also be hierarchically structured and can be classified according to the type of hierarchy. We 

distinguish between 

IS ADD


layer-based responsibilities where the party can only be responsible for the party that is in the next lower layer and 

hierarchical responsibilities that restrict the responsibility to the matching level of the parties. 

The layer-based responsibility can be 

general for a general responsibility of one party for an entire layer (represented by a unary relationship of responsibility 

for a party) or 

directed for a (binary) relationship between the parties. 

Responsibilities may be shuffled with a logging facility that store the results of being responsible for the parties. 

Figure 39 displays one way of shuffling according to the constructor pattern of the previous subsection. 

Protocolling 

schema 

2 

Quantity 

schema 

✻ 

⊕ 

✿ 

Product 

kind 

Service 

area 

✾ 

Service 

kind 

3 

Resource 

utilisation 

✻ 


✛ 

Service 

✲ 

Spatial 

schema 

Abbildung 39: Service record for responsibilities 

Responsibilities may already by pre-assigned to parties. In this case we introduce another type: Position. This 

type may either be generalised within the Party type or may be a unary relationship defined on Party. 

2.6 Grenzen der Modellierung 

2.6.1 Grenzen hierarchischer Modellierung 

The higher-order entity-relationship model (HERM) [Tha00] extends the classical entity-relationship model by complex 

attributes (type), relationship types of higher order and cluster types. Relationship types may have only one component 

and represent in this case a specialization of the its component. For instance, the relationship type Porsche 

in Figure 41 specializes the type car. The type Car is a specialization of the type Product. Relationship types may 

have key components beyond the keys of their components. For instance, the type Book has an additional key beyond 

the identification for products. It is required that any type has a key. For this reason, the HERM schema requires that 

each type has either its key or a key that consists of keys from its components and if necessary its additional key. 

Cluster types allow a representation of generalization hierarchies. For instance, the Product type can be understood 

as a generalization of the types Car and Product. This opportunity is not represented in our HERM schema. 

Modeling typically allows to apply a number of approaches. The classical ER approach to modeling is given in 

the specialization schema in Figure 40. We have been choosing a compact schema that avoids Is-A relationship types 

and directly uses specialization types. Extended ER modeling requires that any type has its identifying components. 

Identifiers may also be attributes of the relationship type. Typically identification is inherited from components. It may 

IS ADD


however also replace identification, e.g. ISBN is the identification for the book type. Specialization may either be 

subtype specialization or property specialization (e.g. Porsche911GT8 for Porsche911) or both (e.g. Book for 

Product with value assignment for taxRate and type specialization for the relationship type). Typically, (entity 

or relationship) classes are not singleton classes. The type myPorsche911CarreraS defines a singleton class for 

this application. 

serialNr 

taxRate 

desc 

Product 

✙ 

❨ 

listPrice 

Hierarchie layer: 

Product Catalog 

maxSpeed 

maxSpeed=310km/h 

listPrice=108.083 

Porsche911GT3 

porsche911club 

porsche911club=true 

millage taxRate=20 

Car ✛ Porsche911 

✠ millage=100000 

✛ Porsche911 

CarreraS 

✛ myPorsche911 

CarreraS 

marketLaunch 

maxSpeed listPrice 

=293km/h =91.838 

serialNr=’C33333333’ 

author marketLaunch=1964 

author=J.K. Rowling 

Book ✛ HarryPotter4 ✛ myCopyOf 

HarryPotter4 

taxRate=15 

listPrice=11.50 serialNr=’A121212’ 

Hierarchie layer: Hierarchie layer: Hierarchie layer: Hierarchie layer: 

Product Category Product Brand Product Model Product Physical Entity 

Abbildung 40: Product catalog modeled with HERM specialisation types 

Another representation of the same application is given in the overlay schema. This schema combines the car 

and book category in the example within a schema that allows to consider the similarity of the types within the same 

diagram without separating the categories into different diagrams. The model in Figure 41 uses optional attributes 

which may either be populated or not. The population is constrained by null-value constraints of the following kind: 

[author] 0 binds the population of values for authors in the entity type Model to those models which category kind 

is BOOK. 

[millage] 0 binds the population of values for millage in the relationship type Entity to those physical entities 

which category kind is CAR. 

[clubAccepted] 0 binds the population of values for clubs in the relationship type Entity to those physical entities 

which category kind is CAR and which brand allows club membership. 

This binding is simple as long as paths have a uniqueness condition. For instance, models have at most one brand and 

one and only one category. The overlay model assumes that brands and categories are orthogonal dimensions and that 

models have at most one brand and have one and only one category. 

ID 

[listPrice] 0 

ID 

desc 

ID 

✛ Brand 

Brand to ✲ Model ✛ 

Model (0,1) 

Entity 

[club] 0 

✻ 

[author] 0 [maxSpeed] 0 serialNr 

[marketLaunch] 0 

(1,1) 

Catalog ✛ 

Catalog 

to ✲ 

Category 

of 

Category 

Model 

✲ Category 

[clubAccepted] 0 

[millage] 0 

taxRate 

kind 

ID 

Abbildung 41: Product catalog modeled with HERM in the overlay modeling style 

Another equivalent schema may make use of cluster types. The category type has two specialisations into Car 

and Book subtypes. The general model properties bind these two subtypes into general model characterisations and 

use special types for an association to specific model properties of each categories. This representation is based on 

horizontal decomposition of types. This representation is therefore very similar to the m-object representation. 

IS ADD


The schema in Figure 40 combines the object and the class model. The type myCopyOfHarryPotter represents 

a singleton class consisting of one singleton book. Furthermore, the type Porsche911GT3 uses in the class 

name a description of the objects in the corresponding class. If we use an overlay schema then this implicit description 

must be made explicit. The attribute kind is therefore added to the entity type Category in Figure 41. 

2.6.2 Fallen anderer Modelle: Identification 

The representation of object and thing identities is one of the main source for errors in schemata. It is surprising 

that many textbooks still follow the direct representation approach through object identities that are assigned by 

the system. Object identity is rather a concept at the logical layer of database operating. This approach looks very 

convenient. The user does not have any chance to interfere with the object identity generation. 

The paper [BT99] (see also [ST98]) shows that object identification must either be given by (weak) value identification 

[ST93] or will cause many computational problems. Otherwise a rather complex complex logical theory must 

be developed. [Sch94] show that we need a higher-order intutionistic predicate logic. Since object-identity allows self 

reference the logic must also be epistemic. The results of [BT99] and its preliminary versions e.g. [BT92], [BT95] 

have led the concept of object identity constraints in [RK02]. The starting point for this theory have been the reports 

[Tha91b] and [AFT92]. 

Consider, for instance, the schemata in Figures 42 and 44. 

s 

✲ 

o 1 

❑ 

o 4 

o 5 

s ′ 

s ❄ s 

s s 

s 

1 

s ′ ✯ ❨ 

☛ s s 

′ 

✌ 

o 2 ✲ o 

s ◆ 

3 a ✲ o 

s ◆ 

6 ✲ 

(a) 

(b) 

Abbildung 42: Identification in Object-Oriented Databases 

b 

The identification of the objects in Figure 43 can neither be based on structural properties nor on values. So, the 

user is lost whenever an object must be accessed. The question how many object exist in the database may give a 

result of either 3 or 4. Both are correct due to the limitations of represented knowledge about the objects. 

o 2 

s 

✿ 

2 

s 2 2 

✲ 

✻ 

s 3 

3 

s 1 o 1 s 1 

o 4 

2 3 o ❄ s 1 s ✛ 

s 1 

s 

s 3 

3 2 

3 ✾ s 2 

s 3 

Abbildung 43: Objects which cannot be distinguished 

One trick to represent object identification is to use a tree representation. The schema in Figure 44 displays a tree 

representation. 

o 1 

o 2 

o 3 

o j 

s 

✙ 

o 2 

s s 

❄ 

′ ❥ 

! o 3 1 

s 

✙ 

o 3 

s s 

❄ 

′ ❥ 

! o 1 1 

s 

✙ 

o 1 

s s 

❄ 

′ ❥ 

! o 2 1 

s 

✙ 

o j+1 mod 3 

s s 

❄ 

❥ 

!o j+2 mod 3 1 

Abbildung 44: Trees of of depth 1 for o 1 , o 2 , o 3 

IS ADD


Extended entity-relationship models explicitly define two constructs which can be implicitly used in nested relational 

database models: 

• Relationship types express the association among types. This association can be used for identification as well. 

• The differentiation among types allows to distinguish concepts which are defined by a certain construction 

and concepts which are using a certain construct. Thus, relationship types are based on entity types. Their 

identification mechanism is based on the identification mechanism of component types. 

Weak entity types, i.e. types whose identification is defined through associations, use the first extension. An entity 

type is defined as nested relational type. Its semantics, however can be based on other types as well. Let as consider 

the example pictured in figure 45. 

House 

✛ 

(1,1) 

HInS ✲ Street ✛ 

(1,1) 

SInT ✲ 

Town 

Number Name Name Area 

Abbildung 45: Address defined by weak entity types 

We can use pathes for the identification. The dot is used for component declaration, i.e. moving downwards. The 

exclamation mark is used for moving upwards. For example, the attribute Number can be reached from Town using 

the path 

Town!SInT.Street!HInS.House and is denoted by 

Town!SInT.Street!HInS.House.Number. 

Thus we can use pathes for identification of objects and the extension of the notion of a key as well. In the example 

the key of the type House is the set 

{ House!HInS.Street!SInT.Town.Name, House!HInS.Street!SInT.Town.Area, House!HInS.Street.Name, Number 

} . 

This identification mechanism can be displayed by trees or forests in the general case. 

There can be defined other identification mechanisms. The second new construct of entity-relationship databases 

extends the identification concept as well. Let us consider the example in figure 46. 

(1,m) 

Multiset ✛ HasMember ✲ 

Element 

MNumber 

OccurNr 

Value 

Abbildung 46: Complex Identification through Relationship Types 

Multisets are identical if they have the same elements with the same occurrence number. 

This condition can be expressed by generalizing the notion of key dependencies. A key dependency is a functional 

dependency 

s −→ R 

for a substructure s of R. 

This dependency can be expressed also by a first-order predicate formula 

∀v, v ′ (P R (v) ∧ P R (v ′ ) ∧ v R′ 

= v ′ −→ v = R v ) . 

In the relational model at the external level keys are used to represent identification and existence. This idea directs 

to another formula which is equivalent to the above key constraint: 

IS ADD


∀v 1 | R ′′, v 2 | R ′′ ( ∀v | R ′ ( P R (v | R ′✶ v 1 | R ′′) ←→ P R (v | R ′✶ v 1 | R ′′) ) −→ v 1 

R ′′ 

= v 2 ) 

where R ′′ is the “difference” of R and R ′ . 

Based on this re-definition we express now the key constraints for multisets by the formula 

∀m, m ′ ( ( ∀e, o ( P HasMember (m, e, o) ←→ P HasMember (m ′ , e, o) ) −→ m = m ′ ) . 

Notice that this notion is the indiscernability relation introduced by Leibniz [Lei60]. 

Integrity constraints can be used for identifiability as well. They can impose distinguishability or indistinguishability 

of objects. 

Samuel Clemens 

Mark Twain 

✛ name o 2 

✛ name o 1 

one-author-book 

✻ 

❥✲ Huckleberry Finn 

o 3 

✻ 

brother brother 

❄ 

o 4 

Abbildung 47: Integrity constraints influence identifiability 

Let us consider the objects in Figure 47. 

It is known that the relation ‘brother’ is irreflexive. For this reason we find that o 3 ≠ o 4 although there is no 

possibility to identify one of the objects. Thus, distinguishability of objects is weaker than identifiability of objects. 

It can be possible to distinguish objects which cannot be identified. If objects are identifiable then the objects can be 

distinguished. 

From the other side, since the book Huckleberry Finn was written by one author the objects o 1 and o 2 can be 

identified. 

The identification concept is based in these cases on integrity constraints. We consider different classes of integrity 

constraints and the treatment of identification based on our concepts. We use the relational notation since this notation 

can be easily extended to other models. 

• Equality generating dependencies are constraints of the following form: 

∀(x 1,1 , ..., x m,n ) 

(P R (x 1,1 , ..., x 1,n ) ∧ ... ∧ P R (x m,1 , ..., x m,n ) ∧ F (x 1,1 , ..., x m,n ) → 

G(x 1,1 , ..., x m,n )) 

where F (x 1,1 , ..., x m,n ), G(x 1,1 , ..., x m,n ) are conjunctions of equalities of the form x i,j = x i ′ ,j′ and P is the 

predicate symbol associated with R. 

Based on the transformation of the constraint to the equivalent formula 

∀(x 1,1 , ..., x m,n ) 

(P R (x 1,1 , ..., x 1,n ) ∧ ... ∧ P R (x m,1 , ..., x m,n ) ∧ ¬G(x 1,1 , ..., x m,n ) → 

¬F (x 1,1 , ..., x m,n )) 

we can use the inequality set IE in order to extend the deductive system DV 

IE . Thus, we can express the 

identification properties on the basis of value-distinguishabability or equational logic in the case of equality 

generating dependencies. 

Identification extended by equality-generating dependencies can be expressed by V-identifiability. 

Notice, that functional dependencies and generalized functional dependencies are special equality generating 

dependencies. 

• An exclusion dependency is an expression of the form 

R[R.A 1 , ...., R.A n ] ‖ S[S.B 1 , ..., S.B n ] . 

The property specified by the exclusion dependency can be directly translated to inequalities among objects. 

IS ADD


A generalized inclusion dependency is an expression of the form 

R 1 [X 1 ] ∩ ... ∩ R n [X n ] ⊆ S 1 [Y 1 ] ∪ ... ∪ S m [Y m ] 

for compatible sequences X i , Y j . 

Similarily to equality-generating dependencies, generalized inclusion dependencies can be transformed to negated 

formulas. These formulas are the basis for the extension of the deductive system D IE 

V . 

Identification extended by generalized inclusion dependencies and exclusion dependencies can be expressed by 

V-identifiability. 

• Disjunctive existence constraints X ⇒ Y 1 , Y 2 , ..., Y n specify that if a tuple is completely defined on X then it 

is completely defined on Y i for some i. There is an axiomatization for disjunctive existence constraints. They 

can be represented by monotone Boolean functions. 

Since the existence has been treated explicitly in the definition of value-identifiability we conclude directly: 

Identification extended by existence dependencies can be expressed by V-identifiability. 

V-identifiability and E-identifiability are equivalent for generalized inclusion, exclusion, existence and equalitygenerating 

dependencies. 

These results extend the results of [KR97] where functional dependencies, special cases of inclusion and exclusion 

constraints have been considered and which summarized the results in [Tha91b], [BT92] and [BT95]. 

Constraints can be easily used for value identification. We can use constraints also for extending the identification 

on the basis of queries. However this extension has to be changed whenever the inequality set is changed. Thus, 

integrity constraints cannot be incorporated into the computation of identifying queries. The same argument is valid 

for homomorphisms and automorphisms. Thus, the use of integrity constraints leads to another hierarchy in our 

identification mechanisms. 

It is possible to characterize an object without denoting it. For this purpose, queries or formulas can be used. 

Examples of such identifying formulas are: 

1. the current queen of England, 

2. the current king of France, 

3. the mother (father) of x, 

4. the x for which it is valid x + y = z, 

5. the x for which it is valid x 2 = y, 

6. the largest prime number, 

7. the x for which for all y it is valid that x + y = y. 

The first characterization identifies an entity. The second characterization is partial. The third characterization identify 

an object since we know that the relation is functional. The object x can be taken as a parameter. The fourth 

characterization uses two parameters. This characterization can be partial. The case 6 shows that the characterization 

depends on existence of objects. The last characterization identifies one object based on the properties of the function 

+. 

Characterization can be based on formulas α(x, y 1 , ..., y n ) which depend on x and on n parameters y 1 , ..., y n . 

The formula is a characterization formula if ∃ ! x α(x) or resp. ∀y 1 ∀y n ∃ ! x α(x, y 1 , ..., y n ) is valid where 

by ∃ ! x we denote the unique existence of x. The characterization formula α is called essential if n = 0 and 

non-essential otherwise. 

Whether such characterizations can be used depends on the provability of unique existence of such objects and on 

the properties of the used logical language. We notice that a special cases of unique existence are equality generating 

dependencies and functional dependencies. 

If we use integrity constraints then identification may depend also on axiomatizability of constraints defined for 

the database. Since there are classes of constraints which are not axiomatizable, identification may be not computable. 

For example, equality-generating dependencies and inclusion dependencies are not finitely axiomatizable. 

Names as identification. 

IS ADD


Many languages explicitly use names for identification of objects. Often names are confused with the thing they 

denote. The name “Stuttgart” may refer to very different objects such as the city of Stuttgart, the entry point traffic 

sign for Stuttgart. Names may denote references, e.g. the word “Karajan” may denote a piece of music as well as a 

person. L.J.J. Wittgenstein [Wit58] uses the ‘language games’ instead of the mapping from names to denotations. In 

general this notion is based on the mapping from names to denotations that is additionally dependent on the utilisation 

context, culture and the user. If we use a name 16GL for a car then we are denoting some of the properties of the 

car, i.e. the motor and the comfort. The mapping may be a referential one. This ‘label usage’ may cause a number of 

confusions. It is only useful if the meaning can be uniquely deducted. 

The meaning of a word is typically however context-dependent. It depends on the act of denoting. This act of 

denoting should be embedded into the complete situation (language life form). The meaning requires uniqueness 

or clarity of the interpretation. It typically requires preliminary knowledge and a well-assigned context. Naming 

is therefore related to the function units, especially the use in dependence of the function. Word denote things. 

Denotation is an activity. The meaning of a word is the set of denoted things under consideration. 

A name must have at least the three properties: 

• It must reliable assign the notion to the thing under consideration. 

• The reference must be stable. 

• The reference is invertible. 

The assignment of a name may be based on a name space. Sometime we use additionally an identification schema or 

a coding for the names. The identification schema may be implicit or explicit. 

Object 

appearance 

✛ 

appearance 


schema 

alias 

former usage 

✻ 

Object 

equivalence 

✲ ❄ 

Object ✛ 

✲ 

✰ ✰ 

Name 

✲ 

Name 

space 

Abbildung 48: The explicit representation of names 

Amalgamation of identification. 

Object have their own history. They may be copied, replaced, updated and deleted. If we are interested in maintaining 

the original object whenever the object obtains new properties then we need either an explicit representation of 

the history of objects or an explicit replacement mechanism. The simplest replacement mechanism is the introduction 

of aliasing schemata. The most rigid replacement schema is the liquidation of the older identification. We might also 

use the data type Alias or Former usage in Figure 48 that explicitly stores all name changes. 

The same problem appears if we can observe the same thing in various beings and appearances. Observations 

are typically made by people who might classify the same thing in a different way. Therefore we can additionally 

introduce the appearance into the schema. This appearance notion is based on the sponsor-selector pattern that 

separates the three fundamentally different responsibilities: recommending a resource, selecting among resources, 

and using a resource. 

Furthermore, objects observed may be equivalent to each other based on a notion of equivalence. This notion 

should be stored whenever complex evaluations are going to be made. The equivalence schema is important for 

almost all aggregations if we are interested in well-founded statistics. We can use the mediator pattern for an 

explicit annotation of the equivalence notion. 

IS ADD

CAU zu Kiel, Code IfI, Description ISE, β 2. Strukturierung von IS ab SS 2012 207 

Dimension 

Type 

2.7 Conceptual ✻ Modelling in the Large 

see ER 2010 tutorial 

Dimension 

OfType 

[Reason] 

FromDate 

ThruDate 

[Quantity] 


Name 

Product 

Type 

Product 

Quality 

UOM 

UnitOf 

Measure 

2 

Product 

Obsolesence 

Product 

Substitute 

Consists 

Of 


Type 

Item 

Variant 

✮ 

Party 

Address 

✛ 

✲ 

■ 

❦ 

2 

✛ 

may be 

converted in 

Conversion 

Factor 

AReplacementNeededFor 

SuperceededBy 

[Comment] 

[Instruction] 

[Comment] 

[QuantityUsed] 

ThruDate 

FromDate 

❥ ❥ ❘ 

✲ 

✲ 

By UsedAs 

Additional Identifier 

(ManifacturerID | 

StockKeepingUnit | 

UniversalProductCode 

(American UPCA | European UPCE) | 

IntStandBookNumb ISBN)) 

Id TypeCode Description 

PhysicalInventoryDate 

Quantity 

Reason 

[Comment] 

Dimension 

❑ 

Converted 

❘ 

✻ 

✻ 

Inventory 

Item ⊕ 

❄ 

Container 

⊕ 

Product ✙ 


❄ 

Product 

✲ 

Color 

✻ 

✻ 

Code 

Description 

❘ Product 

Characterized 

WorkIn 

Progress 

Container 

Type 

Other 


✕ 

Base 

Product 

Price 

Discount 

Component 

PriceSequenceNum 

Specified 

For 

Surcharge 

Component 

MadeUpOf 

ProdCode Name [Comment] 

[IntroductionDate] 

[SalesDiscontinuationDate] 

[SupportDiscontinuationDate] [ManufSuggestRetailPrice] 

UsedIn 

WarehousedAt 

Id 

Organization 

Raw 

Material 

Additional 

✾ 

❂ 

Item 

✛ Item ✛ 

Finished 

Good 


Item 

Shrinkage ✲ 

Overages 

[ReorderQuantity] 

[ReorderLevel] 

PhysicalOccurenceOf 

StorageFor 

SerialNumber 

QuantityOnHand 

Id 

✻ 

ID 

[ThruQuantity] 

Service 

FromQuantity 

❄ 

Quantity 

Price 

Component 

Break Type 

✻ ✕ ❃ 

Discount 

Level 

❯ 

❫ Product 

Component 

Price 

✗ 

Code 

✠ 

✛ 

✻ 

Priced 

By 

Prod 

Category 

Class 

❄ 

Product 

Category 

Used To 

Define 

[ThruDate] 

[Price] 

FromDate 

[Percent] 

[Comment] 

[Comment] 

AvailableTruDate 

❘ 

✌ 

Product 

Supplier 

FromDate 

FromDate 

Description 

✛ 

Costed 

By 

Producer 

Of 

[ThruDate] 

[Comment] 

PrimaryFlag 

[ThruDate] 

Code 

CompTypeCode 

Description 

Purchaser 

Of 

Location 

UsedToDefine 

Estimated 

Product 

Cost 

Market 

Interest 

❄ 

Party 

Type 

✿ 

Product 

Supplier 

✲ RatingType 

❘ 

✒ 


DependentOn 

Supplier 

Cost 

RatingTypeCode 

❫ 

✲ 

Name 

FromDate 

Comment 

Description 

PartyTypeCode 

Party 

Type 

Description 

GeoAreaCode 

Geographic 

Boundary 

Name 

FromDate 

[ThruDate] 

PrefTypeCode 

Product 

Supplier 

Preference 

Description 

Description 

[TaxIdNum] 

UsedTo 

Define 

[ThruDate] 

From 

Id 

Code 

Description 

Abbildung 49: Pattern for Products 

IS ADD


2.8 Transformation von Schemata in andere Modelle 

Man kann für die Übersetzung zwei verschiedene Zugänge unterscheiden: 

Interpretation: Typen des Ausgangschemas werden in einer bestimmten Reihenfolge in Konstrukte der Zielsprache 

überführt. 

Compilierung: Eine Transformation kann zu Schemata führen, die ein ungünstiges Verhalten haben. Deshalb wird 

oft von einem Entwerfer erwartet, daß er nach einer Übersetzung das Zielschema ‘glättet’. Ein Compilierungszugang 

dagegen 3 berücksichtigt Eigenschaften der Zielsprache bei der Übersetzung mit. Übersetzer können 

wie ein klassischer Compiler aufgebaut sein. 

siehe auch H.C. Mayr’s Vorlesungen 

siehe Embley-Kapitel im Handbuch 

Wir stellen zuerst einige Transformationstechniken vor. Diese Techniken stellen den Hintergrund der betrachteten 

Konzeptualisierung. Sie können bereits in diesem Schritt angewandt werden. Da wir uns hier jedoch vollständig auf 

den konzeptionellen Entwurf konzentrieren und nicht mit mehreren Entwurfsmodellen und -sprachen den Entwerfer 

verwirren wollen, dient die folgende Darstellung der Transformationstechniken nur dem Verständnis der folgenden 

Schritte. Erst im letzten Schritt wenden wir eine Transformation an. Dadurch wird gesichert, daß sich der Entwerfer 

nur mit einem Modell beschäftigen muß. Er kann die Transformation am Ende als vollständig automatisierbares 

Verfahren anwenden, ohne gezwungen zu sein, das physische oder das logische Schema im Detail zu betrachten. 

Spätere Änderungen oder Anpassungen sind dadurch stets auf konzeptionellen Niveau darzustellen. Dieser Vorteil 

rechtfertigt das Verschieben der Transformation auf den letzten Schritt. 

Grundkenntnisse. 

Übersetzungstechniken kann man analog zu den Ansätzen der Theorie der Programmiersprachen unterscheiden 

nach 

ER-Modellen: Es gibt eine Vielzahl von erweiterten Entity-Relationship-Modellen. Meist sind jedoch nur strukturelle 

Erweiterungen vorgeschlagen wurden. 

Einbeziehen von Integritätsbedingungen: Ein Schema hat implizite und explizite Integritätsbedingungen. Übersetzungstechniken 

verwenden oft nur einen Teil der entwickelten semantischen Bedingungen. 

Prozeßunterstützung: Einige erweiterte Entity-Relationship-Modelle lassen das explizite Modellieren von Prozessen 

z.B. durch Transaktionen zu. Andere dagegen erlauben keine Operationen. Aufgrund der Integritätserzwingungsmechanismen, 

die in Kapitel ?? bereits entwicklet wurden, sind generische Operationen bereits 

modelliert. Darüber hinausgehende Mechanismen können angewandt werden. 

Entwerferinteraktion: Einige Transformationstechniken sind nichtdeterministisch und lassen eine direkte Interaktion 

mit dem Entwerfer zu. 

Übersetzungsvoraussetzungen: Oft setzen Übersetzungen spezifische Normalformen voraus. Weiterhin werden 

oft Metaannahmen (unique-name-assumption u.a.) vorausgesetzt. 

Erhaltung der gesamten Entwurfsinformation: Es ist möglich, die gesamte Entwurfsinformation in das logische 

Zielmodell zu transformieren. Meist fehlt aber eine Umsetzung in ein physischen Modell, so daß darauf auch 

für physische Modelle verzichtet werden muß. 

3 Die Arbeit Incremental translation of database schemas as an optimization process von N. Runge und P.C. Lockemann ist leider nach einer turbulenten 

EMISA-Tagung in Tutzingen 1996 nach unberechtigter Kritik von der Veröffentlichung zuruückgezogen worden. Wir verwenden diesen Ansatz aufgrund seiner 

Richtigkeit jedoch im weiteren. 

Mod IS IS ADD WebIS


Qualität des Zielschemas: Durch eine Reihe von Zugängen kann ein minimales, normalisiertes oder nichtredundantes 

Schema für verschiedene Arten von Ausgangsschemata erreicht werden. 

Mod IS IS ADD WebIS


2.8.1 Interpreter-Zugang 

Interpretation von ER-Konstrukten durch relationale Konstrukte. 

Fast alle Bücher und auch die entsprechenden Vorlesungen bieten nur den interpretierenden Zugang 

an!!! 

Mehrschrittverfahren wobei Semantik und Funktionalität mit übertragen werden muß 

Schlüssel und funktionale Abhängigkeiten in Schlüssel, funktionale und mehrwertige Abhängigkeiten 

implizite Komponenten in Inklusionsabhängigkeiten 

Exklusionsabhängigkeiten in Exklusionsabhängigkeiten 

Kardinalitätsbedingungen in funktionale, Inklusions- und No-null-Abhängigkeiten 

1. Herstellen der ersten Normalform (Tupelattribute durch Verkettungsregel, Mengenattribute entweder über Wiederholung 

in Tupeln oder durch eigene Relation); Neuberechnung der Schlüssel (bei Mengenattributen, die bislang 

im Schlüssel vorkamen, wird dann eine mehrwertige Abhängigkeit generiert und der Schlüssel verändert 

sich stark) 

2. Flache Entity-Typen werden in Relationenschema überführt 

3. Schwache flache Entity-Typen werden in Relationenschema übersetzt, wobei die Attributmenge um die Schlüssel 

der identifizierenden Schemas erweitert werden. 

4. Hierarchien von Typen sind in einem der folgenden Zugänge überführbar 

• event-nonseparation: Student, Professor, Person 

• event-separation: Student, Professor, AnderePerson 

• union: Person = Student + Professor + AnderePerson 

• weak universal relation: Person 

5. Relationship-Typen werden entsprechend ihrer Ordnung überführt 

• Binäre 1:1-Relationship-Typen : 

Mehrere Optionen: 

• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h. bei (1,1):(0,1)- 

Typen in ersten Typ) des Primärschl¨ssels des anderen Typen, sowie der Attribute des Relationship- 

Typen (Einfügen eines Fremdschlüssels) 

• Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten und Attributen 

des Relationship-Typen 

• Zusammenfügen der beiden Relationenschemas unter Beifügung der entsprechenden Relationship- 

Typ-Attribute 

falls Attribute keine Nullwerte enthalten dürfen, dann nur bei (1,1):(1,1)-Typen 

• N-äre 1:...-Relationship-Typen (n > 2): 


• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h. bei (1,1):(0,1)...- 





Mod IS



Typ-Attribute 


• Binäre 1:n-Relationship-Typen : 







• N-äre 1:n...-Relationship-Typen (n > 2): 


• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite; d.h. bei (1,1):(0,1)...- 





• n:m -Relationship-Typen 

Definieren eines separaten Relationenschemas mit Primärschlüssel der Komponenten und Attributen des 

Relationship-Typen 

• Rekursive Relationship-Typen 

wier normale Relationship-Typen aber unter Beibehaltung der Rollennamen 

• Is-A-Relationship-Typen 







Typ-Attribute 


• Cluster 



des Relationship-Typen unter Einbeziehung der Rollennamen 

• Einbetten in vorhandenes Relationenschema (möglichst der ‘mandatory’-Seite) des Primärschl¨ssels 

des anderen Typen (Einfügen eines Fremdschlüssels) unter Beibehaltung der Rollennamen 

Interpretation durch XML-Modelle (DTD). 

Nach Lipeck/Kleiner [KL02] 

Mod IS


Der Algorithmus nach Lipeck/Kleiner: 

Mod IS


Übersetzung von HERM in XML-Bäume. 

HERM ist besser geeignet als einfache ER-Modelle 

• Typen bereits genestete Struktur 

• Typen höherer Ordnung 

• unäre Kardinalitätsbeschränkungen mit Participation-Semantik 

HERM ist besser geeignet als UML 

• Typen haben klar definierte Semantik 

• Schematakomponenten sind integriert 

• durch Codesign auch Pragmatik und Entwicklungsmethodik 

XML ist Einschränkung von HERM 

• XML Schema und XForms geeignet für hierarchische Extrakte von HERM 

• HERM-Spezialisierung entspricht Schema-Typen-Spezialisierung 

• einelementige Kardinalitäten 

ansonsten clustering mit pivoting 

• Varianten von I-Objekten über XDNL-Zugang 

Mod IS


• XML - objekt-orientiertes hierarchisches Datenmodell 

• Mehrfach-Szenarien werden mit XDNL-Varianten verbunden 

damit ist Übertragung von HERM-Schemata in XML Schemata determiniert 

Übersetzung 

• Objektifizierung mit Master-Slave-Mirror 

für Auflösung mit ID’s 

alle Typen, auf die verwiesen wird 

unter Beachtung der Exklusionsabhängigkeiten 

• starke Aggregationen sind exklusiv (Komponente gehört zu genau einem Supertyp) 

• schwache (nicht-exklusive) Aggregationen werden in (evt. auch künstliche) Mirror-Beziehung abgebildet 

evt. mit Varianten je nach Interaktion un Szenarien 

• schrittweise Übersetzung von HERM-Typen von 0. Ordnung bis zu i. Ordnung 

Entity-Typen werden direkt übertragen 

Attributtypen sind auch in HERM exklusiv, gehören zu ER-Typen 

Cluster-Typen werden in Varianten übertragen 

Relationship-Typen werden ggf. auch kolladiert ((1, 1)(1, 1)-Typen) bzw. objektifiziert 

Hierarchien müssen nicht aufgelöst werden, sondern werden direkt als Subtypen realisiert 

• Sichten werden als Anfragen in XML-QL formuliert, falls nicht bereits in Schema-Definition eingegangen 

• Integritätsbedingungen der Datenbank für XML-Interaktion müssen spezifisch behandelt werden 

• Translationsmechanismus wird analog für die Datenbank mit HERM-Reengineering-Zugang erweitert 

damit ist dann Direktanbindung der Datenbank möglich 

Interpretation durch Netzwerk- und hierarchische Modelle. 

Netzwerkmodell 

Zwei Konstrukte: Recordtyp, Settyp 

stark implmentationsabhängig trotz Codasyl-Standards 

Recordtyp : Name, Menge von Attributen mit ihren Wertebereichen 

Attribute 

• einfache Attribute 

• mengenwertige Attribute: Vektor 

• zusammengesetzte mengenwertige Attribute: Wiederholgruppe 

Settyp : beschreibt 1-m-Beziehung zwischen Recordtypen 

Records, die mit mehreren anderen Records in Beziehung stehen: Owner 

die in Beziehung gesetzten: Member 

hat eigenen Namen und keine Attribute 

Settypen können auch mehrere Membertypen haben, meist wird jedoch Zweistelligkeit der Beziehung hervorgehoben 

Mod IS



hält 

✲ 

Vorlesung 

und nur jeweils ein Membertyp zugelassen; damit dann graphische Repräsentation durch Bachman-Diagramme 

Settyp ist kein Mengentyp !! Codasyl empfiehlt Liste !! 

Ein Pfeil wird von A nach B gezeichnet, wenn eine partielle Funktion von B C nach A C existiert. entgegen der 

Pfeilrichtung 

Settyp (Member-Records eines Sets) wird kann auf folgende Art und Weise implementiert: 

• entweder first/last: neuer Record stets als erstes/letztes Mitglied einer Set-Occurrence eingefügt 

• oder next/prior: Einfügen jeweils vor bzw. nach laufendem Pointer (z.B. letzte Anfrag) 

• oder System Default: wird durch System übernommen 

• oder Sortiert: nach Werten vorgegebener Attribute 

Einschränkungen : 

jeder Record - Member in höchstens einer Occurrence eines gegebenen Settyps 

Member-Record kann nicht im gleichen Settyp Owner sein 

erlaubt ist jedoch zusätzlich: 

ein Record kann mehrfach Owner-Record verschiedener Settypen sein 

ein Record kann gleichzeitig Member-Record verschiedener Settypen sein 

es können gleichzeitig mehrere Settypen zwischen gleichen Paaren von Recordtypen gebildet werden 

Abfederung der Inflexibilität durch: 

Set-Insertion-Option Einfügen eines neuen Member-Records vom Typ R 

• Automatisch: falls R Membertyp in Settyp S, dann neuer Record auch in S eingefügt 

• Manual: Einfügen in S ist Programmierersache 

Set-Retention-Option Member-Record vom Typ R in S löschen 

• Optional: Record kann ohne Mitgliedschaft in Set-Occurrence in DB existieren 

• Mandatory: Record muß in eine Occurrence eingebunden sein 

• Fixed: Record R muß in S verbleiben 

Da im obigen Schema Vorlesung kein Attribut haben darf: 

• entweder Hinzunahme der Vorlesungsattribute zum Professor 

• oder 

Übersetzung von ER-Schemata in Netzwerkdiagramme 

Verschiedene Strukturen müssen aufgelöst werden: 

• Relationship-Typen höherer Ordnung (> 1) bzw. Arität (> 2) 

• Relationship-Typen mit eigenen Attributen 

Mod IS


• rekursive Relationship-Typen 

• IsA-Relationship-Typen 

• z.T. 1-1-Beziehungen 

• Cluster 

Folgende Strukturen können im wesnetlichen erhalten bleiben: 

• Entity-Typen mit genesteten Attributen 

• attributlose, binäre 1:n Relationshiptypen 

Übersetzung der Problemfälle 

• 1-1-Beziehungen ohne Attribute: entweder Zusammenfassen zu einem Typ oder Bildung eines Settyps für einen 

der beiden Typen 

• m-n-Beziehungen bzw. nicht-binaäre Beziehungen: Einführen mehrerer Settypen und eines Membertyps (Kett- 

Typ) mit Set-Beziehungen zwischen diesem und dem Ownertypen 

Attribute werden dem Kett-Typen zugeordnet 

• IsA-Beziehungen: wie 1-1-Beziehungen in umgekehrter Richtung 

Unterscheidung total/partiell geht verloren; muß über DML gelöst werden 

• Rekursive Typen: Duplizierung des Recordtyps mit Umbenennung oder Einbeziehung eines Dummy-Member- 

Typs 

Person 

IsA 

IsA 

❄ 


✠ 

Student 

✠ betreut 

hält 

❘ 

Vorlesung 

besucht wird-besucht 

❘ 

✠ 

Stud-Vorles 

Optimierung der Übersetzung durch entsprechende ER-Normalisierung 

Ersetzung der genesteten Strukturen durch flache: 

Mengennestung wird durch Einführung eines neuen Kett-Typs aufgehoben mit entsprechender Set-Typen-Einführung 

Tupelnestung wird verflacht 

Integritätsbedingungen sind Programmiereraufgabe bis auf: 

Domain-Bedingungen: mit CHECK-Klausel 

Mod IS


Vorlesung 

setzt 

voraus IsA 

❄ ❄ 

Dummy 

Vorlesung 

wird vorausgesetzt 

von IsA 

✻ 

❄ 

Vorausges 

Vorlesung 

Vorlesung 

✻ wird vorausgesetzt 

von 

✻ 

IsA 

Vorausges 

Vorlesung 

Intrarecord-Bedingung: duplicates are not allowed for < Attribut > 

ist aber keine Schlüsselbedingung 

Interrecord-Bedingung: gleichbenannte Attribute können über CHECK getestet werden (damit referentielle Integrität 

möglich) 

Hierarchisches Modell 

alle Daten durch Baumstrukturen dargestellt 

Datenbank durch Wald strukturiert 

Beziehungen sind 1:1 oder 1:n 

Wurzel ist nicht optional 

Mod IS


2.8.2 Intelligente Übersetung durch Beachtung der Spezifika von HERM-Schemata 

Spezifika der Struktur-Übersetzung von HERM-Schemata. 

Beobachtung 1. 

Es können komplexe Attribute auch eine harmonisierte Übersetzung anderer komplexer Attribute erfordern. 

Beispiel: 

Name(Vornamen(...), Familienname, [Geburtsname] ,...) 

Adresse(PlzBezirk ◦ Zustellamt, Ort, ...) 

erfordert Harmonisierung der Übertragung beider Attribute, da diese über Primärschlüssel gekoppelt sind 


Die bisherigen Übersetzungsregeln sind nur Interpretationsregeln, die induktiv über dem Schemaaufbau definiert 

sind und nicht die Möglichkeiten von SQL92 und SQL:1999 unterstützen. 

Ein compilierender Zugang wird i.a. besser sein. 

Übersetzungsregeln in SQL:1999 nach S. Schoradt: 

1. Datensammelnde Regeln 

Für die Transformation eines Typen werden Informationen benötigt, die am Typen direkt anliegen, sich aus den 

Verbindungen zu anderen Typen ergeben oder aber aus anderen Typen bezogen werden müssen. 

Da die Übersetzungsregeln, der Übersichtlichkeit halber, nur lokal auf einem Typen des Schemagraphen wirken 

sollen, werden durch Regeln zur Datensammlung die notwendigen Daten zur Tranformation der Typen zusammengetragen. 

Dies können z. B. die Notwendigkeit der Erstellung eines Surrogatschlüssels zu einer Entitytypen 

oder das Hinzufügen von Integritätsbedingungen zu einem Typen sein. 

(a) Erstellen von Surrogatschlüsseln 

Das Erstellen von Surrogatschlüsseln ermöglicht es Objekte, die in der konzeptionellen Sicht nur auf 

sehr komplexe Art zu identifizieren sind, in einem DBMS zu verwalten. Hierzu wird zu dem Objekt ein 

atomares Attribut hinzugefügt, das als neuer Schlüssel für das Objekt fungiert. Die existierende Schlüsselbeziehung 

wird weiterhin mitgeführt und gepflegt, dient aber nicht mehr der Identifikation der Instanzen 

des Objektes. Der Surrogatschlüssel zu einem Objekt sollte vom DBMS gepflegt werden, so das die 

darüberliegende Applikation diese technische Veränderung des Schemas nicht beachten muss. 

Dies kann durch Mittel des DBMS zum generieren eindeutiger Objektschlüssel geschehen oder aber durch 

die Erzeugung eines Schlüssels in einem Trigger zum Objekt. 

Durch diese Regel wird zu jeder Entity-Typen oder Relationship-Typen, die Komponente einer Relation 

oder eines Clusters ist, ein Surrogatschlüssel angelegt. Mittels diesem wird im Weiteren die Implementation 

der Relation und die Pflege der damit verbundenen Integritätsbedingungen realisiert. 

(b) Optimierung der Schemastruktur 

Bei der Übersetzung von Schemata kann es notwendig sein das Schema strukturell zu verändern, um ein 

optimales Ergebnis zu erzielen. Eine häufig genutzte Optimierungsvariante ist das Auflösen von Relationen 

mit der Kardinalitätsbeschränkung (1, 1) oder (0,1). 

Über den Controller wird festgelegt, ob für (1,1)-(0,1)-Relationship-Typen condense zu einem zusammenhängenden 

Typen, reference oder stay alone angestoßen wird. 

(c) Integritätsbedingungen 

Oftmals sind Integritätsbedingungen indirekt im konzeptionellen Schema kodiert. Um diese bei der Transformation 

zu beachten, müssen sie zur Menge der Integritätsbedingungen eines Typen hinzugefügt werden. 

IS ADD


Diese Regeln weisen zum Einen die Komponenten einer Relation als Schlüssel aus, falls noch nicht 

geschehen und vergeben für alle Relationen deren Kardinalität nicht spezifiziert ist die Kardinalitätsbeschränkung 

(0,n). 

2. Elementare Transformationen 

An dieser Stelle sollen für die einzelnen Schemaelemente elementare Übersetzungsregeln angegeben werden. 

Diese Wandeln einen Typen in eine SQL Anweisung oder einen Anweisungsteil um. 

Die Transformationen, die in diesen Regeln verwandt werden, stammen grösstenteils aus [Tha00] und wurden 

an die Möglichkeiten von SQL:1999 und den entworfenen Übersetzungsprozess angepasst. 

(a) Regeln für Domaintypen 

Jeder Domaintyp im Schemagraph repräsentiert eine Domäne aus dem HER Schema. Diese sind durch die 

Menge aller erlaubten Elemente beschrieben und müssen durch die Transformation auf die vorhandenen 

SQL Datentypen abgebildet werden. 

SQL:1999 kennt Datentypen der Kategorien: 

• Zeichendaten 

• numerische Daten 

• Wahrheitswerte 

• Datumswerte 

Die richtige Transformation der Domains in SQL Datentypen wird durch die Kombination von Transformationsregel 

und Bewertungsfunktion erreicht. 

(b) Regeln zur Behandlung von Attributtypen 

Bei den AttributTypen hängt die Anwendung einer Regel von ihrem Konstruktor und den globalen Parametern 

für die Attributtransformation ab. 

Für die komplexen Attribute sind mehrere Möglichkeiten für die Transformation vorhanden: 

• verflachen des Attributs durch Transformation in eine Zeichenkette mit Trennzeichen 

• einführen von Blattattributen, z. B. wird ein Tupelattribut Name(vname,nname) in die Attribute Name.vname 

und Name.vname transformiert 

• erstellen eines eigenen Subschemas 

• als komplexes Attribut belassen 

In SQL:1999 ergibt sich weiterhin die Möglichkeit komplexe Attribute in komplexe Datentypen zu transformieren. 

Diese Option wurde soweit möglich verfolgt, um die Möglichkeiten von SQL:1999 auszunutzen. 

Bei der Transformation von Tupeltypen, kann als Implementation ein ROW Typ verwandt werden. 

Mengentypen werden rekursiv, anhand ihrer Struktur, transformiert. Es existieren mehrere Möglichkeiten 

Mengen in einer Datenbank zu repräsentieren, hier soll dies durch das Erstellen einer Tabelle zu jeder 

Menge geschehen. Zur Transformation eines mengenwertigen Attributs muss zuerst der Inhalt der Menge 

transformiert werden und danach das Attribut in eine Tabelle und eine Referenz in die Mengentabelle 

transformiert werden. 

(c) Transformation der Entity-Typen 

Die Transformation eines Entity-Typen kann erfolgen wenn alle enthaltenen Attribut-Typen transformiert 

wurden. 

(d) Transformation von Relationship-Typen 

Die Transformation eines Relationship-Typen kann erfolgen wenn alle Attribute und alle enthaltenen 

Objekte transformiert wurden. 

Hierzu müssen die enthaltenen Relationen und Entityen in Fremdschlüsselbeziehungen umgewandelt 

werden. Die enthaltenen Attribute werden analog zur Transformation eines Entity-Typen behandelt. 

IS ADD


(e) Transformation von Cluster-Typen 

Ein Cluster-Typ wird transformiert nachdem alle enthaltenen Relationen bzw. Entityen transformiert wurden. 

Der Cluster C = R1 + R2 + . . . + Rn wird in eine Referenz auf die Surrogatschlüssel der enthaltenen 

Relationen transformiert, ohne aber mittels einer Fremdschlüsselbeziehung abgesichert zu werden. 

Spezifika der Semantik-Übersetzung von HERM-Schemata. 


Weder SQL’92 noch SQL:1999 erlauben eine vollständige direkte Übertragung von Integritätbedingungen. 

Es können Integritätsbedingungen auf unterschiedliche Art übertragen werden: 

• Restrukturierung des Schemas bis eine vollständige Übertragung unterstützt wird. 

• Deklarative Spezifikation der Integritätsbedingungen. 

• Prozedurale Spezifikation der Integritätsbedingungen. 

• Abbildung der Integritätsbedingungen in eine Wirtssprache 

• Zusätzliche integritätsbedingungssichernde Maßnahmen 

• Sicherstellung durch Benutzungsschnittstellen 

• Sicherstellung durch Ausnahmebehandlung 

• Generierung und Benutzung von sicheren integritätspflegenden Funktionen anstelle der nicht invarianten 

Funktionen 

• Verwaltung von Integritätsverletzungen durch das System 

• Transaktionssysteme 

• ... 

MATCH-Bedingungen. 

SQL-92 erlaubt unterschiedliche MATCH-Bedingungen: 

• einfach als nicht spezifiziertes “default” und Anwendung auf alle Tupel t über Attributliste X mit t[X]!, d.h. 

über Teilmenge {t ∈ R C | ∀A ∈ X : t(A) ≠ NULL} , 

d.h. z.B. für R[X] ⊆ S[Y ], X = A 1 ...A k , und Y = B 1 ...B k wird die Bedingung 

∀t ∈ R C ( (∃i (1≤i≤k) t(A i ) = NULL) ∨ ∃s ∈ S C (t[X] = s[Y ])) 

• FULL wird angewandt auf alle Tupel, die nicht das NULL-Tupel sind, wobei dann Nullwerte nicht erlaubt sind, 


∀t ∈ R C ( ∀i (1≤i≤k) (t(A i ) = NULL) ∨ 

(∀i (1≤i≤k) (t(A i ) ≠ NULL) ∧ ∃s ∈ S C (t[X] = s[Y ]))) 

• PARTIAL wird angewandt auf alle Tupel t, deren X-Wert nicht das NULL-Tupel ist, wobei in der Kontrollmenge 

eine Gleichheit bis auf Nullwerte in t[X] besteht, 


∀t ∈ R C ( ∀i (1≤i≤k) (t(A i ) = NULL) ∨ 

∃s ∈ S C (∀i (1≤i≤k) (t(A i ) = NULL ∨ t(A i ) = s(B i )))) 

wobei diese Bedingung äquivalent ist zu 

∀t ∈ R C (∃s ∈ S C (∀i (1≤i≤k) (t(A i ) = NULL ∨ t(A i ) = s(B i )))) . 

IS ADD


FULL kann auch direkt ausgedrückt werden durch: 

CHECK ( 

(A1 IS NULL AND ... AND Ak IS NULL) 

OR 

( A1 IS NOT NULL AND ... AND Ak IS NOT NULL 

AND A1,...,Ak 

IN SELECT B1 ... Bk FROM S )) 

PARTIAL ist auch darstellbar durch eine Fallunterscheidung je nach vorkommenden Nullwert im referenzierendem 

Tupel: 

CHECK ( 

(A1 IS NULL AND ... AND Ak IS NULL) 

OR 

( A1 NULL AND A2 IS NOT NULL ... AND AK IS NOT NULL 

AND A2,...,Ak 

IN SELECT B2 ... Bk FROM S ) 

OR ... OR 

( A1 IS NOT NULL ... AND A(k-1) IS NOT NULL AND AK IS NULL 

AND A1,...,A(k-1) 

IN SELECT B1 ... B(k-1) FROM S ) 

OR ... OR 

( A1 IS NULL AND ... A(k-1) IS NULL AND AK IS NOT NULL 

AND Ak 

IN SELECT Bk FROM S ) 

) 

Ausführungsmodi. 

SQL-92 hat bereits Asuführungsmodi eingeführt: 

DEFERRED 

IMMEDIATE 

kann. 

erlaubt das Aufschieben eine Kontrolle der Integritätsbedingungen bis zum Ende einer Transaktion. 

fordert die Kontrolle einer Integritätsbedingung für jede Anweisung, mit der diese verletzt werden 

Diese Ausführungsmodi können gesetzt werden auf einen initialen Modus, der dann auch ggf. überschrieben werden 

kann. Damit erhalten wir: 

INITIALLY IMMEDIATE NOT DEFERABLE ist die default-Bedingung für Integritätsbedingungen. 

Diese Bedingung kann auch durch NOT DEFERABLE INITIALLY IMMEDIATE deklariert werden. 

INITIALLY DEFERRED NOT DEFERABLE Diese Bedingung kann auch durch NOT DEFERABLE INITIALLY 

DEFERRED deklariert werden. 

INITIALLY DEFERRED DEFERABLE Diese Bedingung kann auch durch DEFERABLE INITIALLY DEFERRED 

deklariert werden. 

INITIALLY IMMEDIATE DEFERABLE sollte stets für alle Bedingungen deklariert werden, die mit Transaktionen 

ggf. verletzt werden können. Diese Bedingung kann auch durch DEFERABLE INITIALLY IMMEDIATE 

deklariert werden. 

Der Ausführungsmodus kann umgesetzt werden mit 

bzw. 

SET CONSTRAINTS name list IMMEDIATE 

IS ADD


bzw. 

bzw. 

SET CONSTRAINTS name list DEFERRED 

SET CONSTRAINTS ALL IMMEDIATE 

SET CONSTRAINTS ALL DEFERRED 

Deklarative Spezifikation mit CHECK-Bedingungen. 

CHECK-Bedingungen werden definiert 

• auf Attributniveau zu den Werten dieses Attributes, 

• auf Tabellenniveau für jedes einzelne Tupel der Relation, wobei hier auch subselect erlaubt sind und 

• über den Umweg der Defintion mit Assertions. 

Deklarative Spezifikation mit ASSERTION. 

ASSERTION ist eine Schema-Bedingung. Sie ist jedoch relativ selten realisiert. Oracle erlaubt z.B. nicht die 

Spezifikation. 

CREATE ASSERTION Institut 

CHECK (Bedingung); 

Sie wird immer dann aktiviert, wenn die Klassen zu den verwendeten Tabellen modifiziert werden. 

CREATE TABLE Fakultaet ( 

... 

Nummer FakNr PRIMARY KEY, 

.. ); 

CREATE ASSERTION AssignFakultaet 

CHECK (NOT EXISTS ( 

SELECT * 

FROM Institut 

WHERE FakNr IS NULL) 

); 

CREATE ASSERTION AnzahlInstZuFak 

CHECK ( 

(SELECT COUNT(*) FROM Fakultaet)


CREATE OR REPLACE TRIGGER TriggInstitutFakult 

AFTER INSERT ON Institut 

FOR EACH ROW 

WHEN (new.Fakultaet NOT IN 

(SELECT Nummer FROM Fakulataet)) 

BEGIN 

INSERT INTO Fakultaet (Nummer) 

VALUES (:new.Fakultaet); 

END; 

. 

run 

Folgende Besonderheiten sollten beachtet werden: 

• OR REPLACE kann auch nicht spezifiziert werden. Sollte jedoch bereits ein Trigger existieren, dann ist dies 

ein Fehler. 

• AFTER kann auch ersetzt werden durch BEFORE . 

• Wird der Trigger für eine Sicht spezifiziert, dann kann auch anstelle von AFTER der Ersatz durch INSTEAD OF be 

nutzt werden. Damit kann auch eine Sicht modifiziert werden. 

• Anstelle von INSERT kann auch DELETE oder UPDATE OF verwendet werden. 

• FOR EACH ROW kann man auch weglassen. In diesem Fall wird der Trigger nur einmal für jede Modifikationsmenge 

zur Relation angewandt. 

• Die Variablen new und old repräsentieren den Zustand nach bzw. vor Anwendung der Modifikationsoperation. 

Bei Verwendung der Variablen in Anfragen ist der Doppelpunkt erfoderlich ( :new.Fakulataet ). 

• Die Aktionen sind Anweisungen des Systemes. Mitunter sind sie verschieden in verschiedenen Systemen. 

• Durch den Punkt wird die Triggerdefinition abgelegt mit einem run . 

• Oracle erlaubt keine Veränderung einer Relation, deren Trigger feuert, sowie auch von assoziierten Relationen 

(z.B. über Fremdschlüssel). 

Trigger in Sybase 

Eine Integritätsbedingung als Sybase-Trigger in unserem Beispiel wird z.B. wie folgt beschrieben 

create trigger tI_eingeschriebenIn on eingeschriebenIn for INSERT as 

begin 

declare @numrows int, 

@nullcnt int, 

@validcnt int, 

@errno int, 

@errmsg varchar(255) 

select @numrows = @@rowcount 

if 

update(MatrNr) 

begin 

select @nullcnt = 0 

select @validcnt = count(*) 

IS ADD


from inserted,Student 

where 

inserted.MatrNr = Student.MatrNr 

if @validcnt + @nullcnt != @numrows 

begin 

select @errno = 30002, 

@errmsg = ’Cannot INSERT eingeschriebenIn because Student does not exist.’ 

goto error 

end 

end 

return 

error: 

raiserror @errno @errmsg 

rollback transaction 

end 

go 

Trigger in Oracle 

Analog wird ein Trigger mit Oracle deklariert, mit dem ein Update in anderen Relationen erzwungen wird: 

create trigger tI_eingeschriebenIn 

after INSERT 

on EingeschriebenIn 

for each row 

declare numrows INTEGER; 

begin 

/* ON CHILD INSERT CASCADE */ 

insert into Student (MatrNr) 

select MatrNr 

from EingeschriebenIn 

where 

not exists ( 

select * from Student 

where 

:new.MatrNr = Student.MatrNr 

); 

end; 

/ 

create trigger tD_EingeschriebenIn 

after DELETE 


for each row 


begin 

/* ON CHILD DELETE RESTRICT */ 

select count(*) into numrows from Student 

where 

:old.MatrNr = Student.MatrNr; 

if (numrows > 0) 

then 

raise_application_error( 

-20010, 

’Cannot DELETE EingeschriebenIn because Student exists.’ 

); 

IS ADD


end if; 

end; 

/ 

create trigger tU_EingeschreibenIn 

after UPDATE 


for each row 


begin 

/* ON CHILD UPDATE RESTRICT */ 

select count(*) into numrows 

from StarkerTyp 

where 

:new.MatrNr = Student.MatrNr; 

if ( 

numrows = 0 

) 

then 


-20007, 

’Cannot UPDATE EingeschriebenIn because Student does not exist.’ 

); 

end if; 

end; 

/ 

create trigger tD_Student 

after DELETE 

on Student 

for each row 


begin 

/* ON PARENT DELETE RESTRICT */ 

select count(*) into numrows 

from einfachabhangig 

where 

EingeschriebenIn.MatrNr = :old.key; 

if (numrows > 0) 

then 


-20001, 

’Cannot DELETE Student because EingeschriebenIn exists.’ 

); 

end if; 

end; 

/ 

/* Student ON PARENT UPDATE CASCADE */ 

/* Student ON CHILD DELETE RESTRICT */ 

/* Student ON CHILD INSERT CASCADE */ 

/* Student ON CHILD UPDATE RESTRICT */ 

Trigger in PostgreSQL 

Trigger könne in PostgreSQL durch Funktionen realisiert werden, die die neue RECORD Variable nutzen: 

IS ADD


• Es wird die Funktion deklariert. 

• Der Trigger benutzt die Funktion. 

Funktionendefinition: 

CREATE FUNCTION trigger_insert_update_relName() 

RETURNS opaque 

AS 

’BEGIN 

IF ... 

THEN RAISE EXCEPTION ’’Mitteilung an alle’’; 

END IF; 

RETURN new; 

END;’ 

LANGUAGE ’plpgsql’; 

Damit kann nun der Trigger spezifiziert werden: 

CREATE TRIGGER tr_relName 

BEFORE INSERT OR UPDATE 

ON relName 

FROR EACH ROW 

EXECUTE PROCEDURE 

trigger_insert_update_relName() 

; 

Zusammenfassende Übersicht. 

Art SQL-92 SQL-99 

Entry Level Intermediate Level Full Level 

Primary immer sofort immer sofort 

key, domain 

constraints 

Unique NOT NULL, immer 

constraints sofort 

Referential MATCH wird nicht MATCH wird nicht 

constraints unterstützt 

unterstützt 

Check- ohne subquery ohne subquery 

Bedingungen 

Assertions nicht unterstützt nicht unterstützt 

2.8.3 Allgemeine Grundlagen der Erzwingung von Integritätsbedingungen 

In SQL 99 bestehen mehrere Möglichkeiten Integritätsbedingungen auszudrücken und zu erzwingen. Diese sind 

• Tabellenbedingungen, wie PRIMARY KEY, UNIQUE oder CHECK Beschränkungen 

• Ausnahmen (Assertion), die einen unerwünschten Zustand in der Datenbank verhindern 

• Trigger, die ermöglichen auf Datenbankoperationen zu reagieren 

IS ADD


Tabellenbedingungen, wie PRIMARY KEY, UNIQUE oder CHECK können nur über den Daten einer Tabelle formuliert 

werden. Dies macht sie für die meisten der benötigten Integritätsbedingungen nur bedingt nutzbar. 

Komplexere Bedingungen können mittels Ausnahmen (Assertions) oder Trigger beschrieben werden. 

Bei einer Ausnahme, wird ein erwünschter Datenbankzustand beschrieben, und es wird von der Datenbank nach 

jeder datenverändernden Aktion garantiert, das dieser noch erfüllt wird. Wird der Zustand nicht erfüllt, so wird die 

Aktion abgelehnt. Durch Trigger kann nach einer datenverändernden Aktion individuell reagiert werden. 

Schlüsselbedingungen: Die Behandlung von HER Schlüsselbedingungen kann auf zwei Arten erfolgen. Zum einen 

durch eine statische UNIQUE Bedingung über den Schlüsselfeldern der erstellten Tabelle oder aber durch eine 

Ausnahmebehandlung mittels ASSERTION. 

Die Auswahl des geeigneten Mittels hängt von der Komplexität des Schlüssels ab. Schlüssel im HER Ansatz 

werden als generalisierte Untermengen [Tha91, S. 7] der Attributmenge eines Entity-Typs beschrieben. Diese 

können nur auf die Schlüsselbedingungen in SQL abgebildet werden, wenn die Untermenge nur aus atomaren 

Attributen des Entity-Typen besteht. 

Ist diese Bedingung für den Schlüssel nicht erfüllt, so muss dieser in eine ASSERTION transformiert werden. 

Stehen keine Ausnahmen zur Verfügung, kann ebenfalls ein Trigger, der bei Verletzung der noch zu definierenden 

Schlüsselbedingung key condition ein Rollback der letzten Datenbankaktion auslöst, verwandt werden. 

Solch ein Trigger müsste zu allen des Objekt E betreffenden Tabellen in der Datenbank erstellt werden. 

Aus diesem Grunde stellt eine Ausnahme die vorzuziehende Alternative dar. 

Um die Schlüsselbedingung zu garantieren darf es keine zwei verschiedenen Datensätze in E geben, bei denen 

alle atomaren Schlüsselattribute und die aus den mengenwertigen Schlüsselattributen ableitbaren Mengen 

gleich sind. Da Mengen in SQL nicht auf kanonische Weise vergleichbar sind, wird der Zusammenhang 

M 1 = M 2 ⇔ M 1 ∪ M 2 \ M 1 ∩ M 2 = ∅ für den Vergleich zweier Mengen verwandt. Dieser lässt sich mittels 

UNION, INTERSECTION und EXCEPT in SQL ausdrücken. Anhand dieser Betrachtungen wurde die Abfrage 

key condition abgeleitet: 

SELECT COUNT(_) FROM E e1, E e2 

WHERE e1.s1 = e2.s1 AND . . . AND e1.sk = e2.sk 

AND NOT EXISTS 

( 

( 

( SELECT i1 FROM set m1 WHERE set id = e1.k1.m1 ) 

UNION 


) EXCEPT ( 


INTERSECT 


) 

) 

. . . 


( 

( 

( SELECT il FROM set ml WHERE set id = e1.kl.ml ) 

UNION 


) 

EXCEPT 

( 


INTERSECT 

IS ADD



) 

) 

AND e1. E id e2. E id 

Wertebereichsbeschränkungen sollen den Wertebereich direkt spezifizieren. Diese können entweder durch einen 

extra spezifizierten Wertebereich dargestellt werden (die bessere Variante) oder durch eine Bedingung in der 

Tabellendefinition. 

CREATE TABLE Institut ( 

... 

Fakultaet 

.. ); 

char(1) NOT NULL 

CHECK VALUE IN (’1’, ’2’, ’3’, ’4’), 

Besser ist die Definition eines Wertebereiches 

CREATE DOMAIN FakNr CHAR(1) CHECK VALUE IN (’1’, ’2’, ’3’, ’4’); 

und die Benutzung dieses Wertebereiches mit 

CREATE TABLE Institut ( 

... 

Fakultaet 

.. ); 

FakNr NOT NULL, 

Hierarchiebedingungen: Oft werden Hierarchien abgebildet im Vereinigungszugang. So kann z.B. due Hierarchie 

Person, Professor in einen Typ abgebildet werden: 

CREATE TABLE Person ( 

Name char[40] Primary Key, 

Gebdatum date Primary Key, 

Geburtsort char[20], 

Adresse 

char[60] 

Spezialisierung varchar[50] CHECK ((InIName IS NULL 

AND Spezialisierung IS NULL) 

OR (InIName IS NOT NULL 

AND Spezialisierung IS NOT NULL)) 

InIName char[15] CHECK ((InIName IS NULL 

AND Spezialisierung IS NULL) 

OR (InIName IS NOT NULL 

AND Spezialisierung IS NOT NULL)) 

); 

Kardinalitätsbedingungen: Die Transformation der Kardinalitätsbeschränkungen, benötigt einige Vorbetrachtungen, 

die es uns im späteren ermöglichen einigen Problemen bei der Behandlung dieser zu umgehen. 

Kardinalitätsbeschränkungen beschreiben die Beziehungen zwischen Relationen und ihren Komponenten in 

einem HER Schema. 

Bei der Betrachtung einer Menge von Kardinalitätsbeschränkungen ist schnell ersichtlich, das bei schlechtem 

Design Konstellationen entstehen können, die nach der Transformation auf eine Datenbank in dieser unerwartete 

Effekte erzeugen können, z.B. zu unerfüllbaren Datenbankschemata führen. 

IS ADD


In [Tha00] wird die Nichterfüllbarkeit eines Systems von Kardinaliträtsbeschränkungen auf die Existenz eines 

kritischen Pfades im System reduziert. Unter Nutzung des dort beschriebenen Tests auf Nichterfüllbarkeit und 

der Möglichkeiten zur Korrektur der Kardinalitätsbeschränkungen eines Schemas kann die Menge der Kardinalitätsbeschränkungen 

soweit möglich in einen konsistenten Zustand gebracht werden, so das die Transformation 

auf das Datenbankniveau keine unerwarteten Effekte erzeugt. 

Die Transformation der Kardinalitätsbeschränkung kann analog zu den Schlüsselbeschränkungen in einen Trigger 

oder eine Ausnahme erfolgen. Es ist aber auch unter speziellen Bedingungen möglich, Kardinalitätsbedingungen 

durch eine Transformation des Ergebnissschemas auszudrücken. So kann bei Kardinalitätsbedingungen 

der Form comp(R, R i ) = (n, 1) , mit n ∈ {0, 1} auf einer binären Relation R, die Relation R aufgelöst werden 

und in die Relation R i hineingezogen werden. Das bewirkt das alle Attribute aus R zu Attributen von R i 

werden. 

Gilt n = 0 wird der Spaltendefinition noch eine NULL Definition hinzugefügt. 

Handelt es sich nicht um eine Kardinalitätsbeschränkung der obigen Art, so ist die Transformation in einen 

Trigger der Ausnahme vorzuziehen, da individuell auf die Verletzung der Bedingung reagiert werden kann. 

Zu jeder Kardinalitätsbeschränkung ist die zu triggernden Aktionen bei Veränderung oder Löschen des referenzierten 

Datensatzes als Transformationsparameter zu beachten. Die Transformation der Kardinalitätsbeschränkung 

comp(R, R i ) = (m, n) führt zu einer Veränderung der Relation und zu mehreren Triggern. Für 

die Kardinalitätsbedingung sind die Aktionen 

• Einfügen von Elementen in Ri 

• Verändern der Identifikationsspalte (hier des Surrogatschlüssels) von Ri. Dieser Fall sollte nicht auftreten, 

ist aber aus Stabilitätsgründen trotzdem zu behandeln. 

• Einfügen von Elementen in R. Es können hier die Beschränkungen von 26 überschritten werden. 

• Verändern der Ri Spalte von R. Hier sind die unteren und oberen Grenzen der Kardinalitätsbedingungen 

zu überprüfen. 

• Löschen von Elementen von R. Hier ist die untere Grenze der Bedingung zu prüfen. zu überwachen. 

Werden durch eine dieser Aktionen die Bedingungen verletzt, so wird die auslösende Aktion zurückgenommen. 

Hierbei ist im Zusammenhang mit dem Hintergrund der Datenpflege zu beachten das bestimmte Integritätsbedingungen 

erst nach dem Ende einer Transaktion gepflegt werden dürfen, da sonst ihre Erfüllung praktisch 

ünmöglich ist. Dies ist z. B. bei Kardinalitätsbeschränkungen der Form comp(R, E) = (1, n) der Fall. Beim 

Einfügen eines Datensatzes in E muss auch ein Eintrag in der Relation R erfolgen. Dies kann praktisch durch 

eine Transaktion geschehen, in der erst der Datensatz in E angelegt wird und daraufhin der Datensatz in R. 

Für die Transformation einer Kardinalitätsbeschränkung werden auch Trigger erzeugt, durch die die Einhaltung 

der Kardinalitätsbedingung comp(R, R i ) = (m, n) erreicht wird. Sie verhindern jede datenverändernde 

Aktion (Insert, Update oder Delete), durch die die Kardinalitätsbedingung verletzt werden könnte. Da die Kardinalitätsbedingung 

per Definition in der leeren Datenbank erfüllt ist, so ist sie es auch in jeden Folgezustand. 

Wir können Kardinalitaätsbedingungen in zwei Klassen von Integritätsbedingungen aufspleißen: 

1. Unäre tupelgenerierende Bedingungen 

LHS ⊑ minimal multiplicity RHS bzw. card(RHS, LHS) = (a, .) 

• Insertion in LHS: Kaskadierend in RHS oder Verbot für LHS (wenn IC ungültig, RESTRICT (als 

harte Bedingung: wird sofort vor allen anderen kontrolliert) oder NO ACTION (als weiche Bedingung: 

wird nach allen anderen IC kontrolliert)) oder Benutzung von Ersatzwerten (DEFAULT oder 

NULL)[wobei diese Optionen nur in Ausnahmefällen sinnvoll sind] in RHS oder bewußte Verletzung 

(REFERENCES ARE NOT CHECKED, SKIP) 

Default-Strategie für fast alle Systeme: REJECT 

IS ADD


• Insertion in RHS: keine Auswirkungen 

• Delete in RHS: CASCADE in LHS oder RESTRICT (in SQL-92: Default-Regel; wenn nicht deklarierts) 

bzw. NO ACTION in RHS oder SET DEFAULT bzw. SET NULL in LHS oder bewußte 

Verletzung (SKIP) 

• Delete in LHS: keine Auswirkungen 

• Update in LHS: CASCADE in RHS oder RESTRICT bzw. NO ACTION in LHS oder SET DEFAULT 

bzw. SET NULL in RHS [wobei diese Optionen nur in Ausnahmefällen sinnvoll sind] oder bewußte 

Verletzung (SKIP) 

Default-Strategie für fast alle Systeme: REJECT 

• Update in RHS: CASCADE in LHS oder RESTRICT bzw. NO ACTION in RHS oder SET DEFAULT 

bzw. SET NULL in LHS oder bewußte Verletzung (SKIP) 

Erzwingungsmodus als Hexatupel (i LHS , λ, λ, d RHS , u LHS , u RHS ) 

ausreichend ist bereits Quadrupel (i LHS , d RHS , u LHS , u RHS ) 

z.B. card(EingeschriebenIn, Student) = (1, .) erfordert (i Stud =C,λ,λ,d Eing =R,u Stud =R,u Eing =R) 

bzw. (i Stud =C,d Eing =R,u Stud =R,u Eing =R) 

Realisierung: 

• RESTRICT für Insert und Update bei card(RHS, LHS) = (1, .) bei EingeschriebenIn 

: 

ALTER TABLE Student ADD CONSTRAINT 

CHECK(EXISTS(SELECT * FROM EingeschriebenIn 

WHERE EingeschriebenIn.StudMatrNr = MatrNr)); 

Alternativ kann auch bei einigen Systemen die RESTRICT-Regel direkt den Attributen zugeordnet 

werden: 

CREATE TABLE EingeschriebenIn ( 

StudMatrNr char[7] CHECK( 

StudMatrNr IN (SELECT MatrNr FROM Student) 

), 

... 

Bis date CHECK ( Von < Bis ) 

PRIMARY KEY (SName, StudMatrNr) 

); 

Die Möglichkeit wird z.Z. nur rudimentär unterstützt. Z.B. Oracle erlaubt keine Subqueries in Bedingungen. 

Die CHECK-Bedingung ist weniger restriktiv, da eine Veränderung in Student nicht 

auf EingeschriebenIn durchgegeben wird! Sie wird nur kontrolliert, wenn das entsprechende 

Attribut sich in EingeschriebenIn ändert (d.h. bei Update und Insert). 

Analog für RESTRICT für Insert und Update bei card(RHS, LHS) = (3, .) 


CHECK(EXISTS( 

SELECT * FROM EingeschriebenIn E1, 

WHERE E1.StudMatrNr = MatrNr 

AND EXISTS( 

SELECT * FROM EingeschriebenIn E2 

WHERE MatrNr = E2.StudMatrNr 

AND E1.SName E2.SName 

AND EXISTS( 


WHERE E3.StudMatrNr = MatrNr 

IS ADD



AND E2.SName E3.SName)))); 

• Modi für Delete und Update für Komponentenabhängigkeiten R[S] ⊆ S 

z.B. EingeschriebenIn[Student] ⊆ Student bei Student 

wird durch Nebenbedingung für den Fremdschlüssel mit bewältigt: 


StudMatrNr char[7] FOREIGN KEY 

REFERENCES Student(MatrNr) 

ON DELETE CASCADE 

ON UPDATE RESTRICT, 

... 



); 


CHECK(EXISTS(SELECT * FROM EingeschriebenIn 

WHERE EingeschriebenIn.StudMatrNr = MatrNr)); 

Damit erhalten wir die folgende Auflösung für den Fall R 1 [X] ⊑ (1,.) R 2 [Y ] für den Fall, daß Y ein 

Schlüssel von R 2 ist: 

CASCADE RESTRICT NO ACTION NULL/DEFAULT 

insert R1 

delete R1 – – – – 

update R1 

insert R2 – – – – 

delete R2 foreign key foreign key foreign key foreign key 

update R2 foreign key foreign key foreign key foreign key 

Im allgemeinen Fall erhalten wir die folgende Auflösung für den Fall R 1 [X] ⊑ (a,.) R 2 [Y ] : 

CASCADE RESTRICT NO ACTION NULL/DEFAULT 

insert R1 stored procedure CHECK CHECK DEFER- 

RED 

delete R1 – – – – 

update R1 trigger CHECK CHECK DEFER- 

RED 

insert R2 – – – – 

delete R2 

update R2 

2. Numerische Beschränkungen card(RHS, LHS) = (0, b) 

• Insertion in LHS: kein Effekt 

• Insertion in RHS: CASCADE in RHS (Bereinigung (DELETE von Konkurrenten)) oder RESTRICT bzw. NO 

ACTION in RHS oder bewußte Verletzung (SKIP) 

• Delete in LHS: keine Auswirkungen (bzw. positive Auswirkungen) 

• Delete in RHS: keine Auswirkungen 

• Update in LHS: CASCADE in RHS oder RESTRICT bzw. NO ACTION in LHS oder bewußte Verletzung 

(SKIP) 

• Update in RHS: CASCADE in RHS (Bereinigung (DELETE von Konkurrenten)) oder RESTRICT bzw. NO 

ACTION in RHS oder bewußte Verletzung (SKIP) 

Erzwingungsmodus als Hexatupel (λ, i RHS , λ, λ, u LHS , u RHS ) 

ausreichend ist bereits Tripel (i RHS , u LHS , u RHS ) 

z.B. card(EingeschriebenIn, Student) = (0, 3) erfordert (i Eing =R,u Student =C,u Eing =R) . 

IS ADD


Spezielle numerische Beschränkungen sind funktionale Abhängigkeiten. Diese können wie card(RHS, LHS) = 

(0, 1)-Abhängigkeiten behandelt werden. 

• Primärschlüsselabhängigkeiten werden sowohl im Entry als auch Intermediate Level von SQL’92 

sofort erzwungen. Es wird die “Entity-Integrität” gefordert (keine Nullwerte in diesen Attributen), 

d.h. es wird gefordert ∀t ∈ R C (t[K]!). 

• Sekundarschlüsselabhängigkeiten erlauben einen variablen Erzwingungsmodus: immediate oder deferred. 

Im Entry Level von SQL’92 ist noch die “Entity-Integrität” gefordert. Der Nullwert wird wie 

ein Wert in der Ungleichung t(A) ≠ t ′ (A) behandelt. 

Die DBMS haben ggf. hier eine abweichende Behandlung: 

• SQL-99 fordert bei UNIQUE-Bedingungen den Vergleich nur bei gleichzeitig voll definierten 

Teiltupeln: 

∀t∀t ′ (t[X]! ∧ t ′ [X]! → t[X] ≠ t ′ [X]). 

• ORACLE erzwingt UNIQUE nur für vollständig definierte Teiltupel, d.h. 

∀t∀t ′ (t[X] = NULL ∨ t ′ [X] = NULL ∨ 

((∃A ∈X (t[A]! ∨ t[A]!)) → t[X] ≠ t ′ [X]). 

• DB2, Informix, Sybase, MS SQL, Ingres, Sybase Anywhere definieren dagegen 

∀t∀t ′ (t[X] ≠ t ′ [X]) . 

Realisierung: 

• RESTRICT für Insert und Update bei card(RHS, LHS) = (0, 2) in der Relation EingeschriebenIn 

ALTER TABLE EingeschriebenIn ADD CONSTRAINT 

CHECK(NOT EXISTS( 

SELECT * FROM EingeschriebenIn E1, 

WHERE EXISTS( 


WHERE E1.StudMatrNr = E2.StudMatrNr 


AND EXISTS( 


WHERE E3.StudMatrNr = E2.StudMatrNr 


AND E2.SName E3.SName)))); 

Analog mit Schachtelung der Tiefe b + 1 für card(RHS, LHS) = (0, b). 

Besser ist in diesem Fall sogar die Einführung eines Surrogat-Schlüssels für die Relation 

EingeschriebenIn, weil bei komplexeren Schlüsseln die Bedingungen E1.SName E3.SName 

dann um den gesamten Schlüssel von EingeschriebenIn erweitert werden müssen. 

Relationale Integritätsbedingungen: Relationale Integritätsbedingungen werden auf der Basis der relationalen Algebra 

formuliert. 

Unter der Menge der möglichen relationalen Integritätsbedingungen sind zwei Klassen besonders zu beachten, 

da sie in der Modellierungspraxis recht häufig benötigt werden: 

Inklusionsbeziehungen: Durch Inklusionsbeziehungen werden statische Beziehungen zwischen Objekten in 

der Datenbank beschrieben. Ihre Transformation kann, wie in den vorherigen Fällen, in Trigger oder Ausnahmen 

erfolgen. Da die beiden Transformationen ineinander überführbar sind, wird hier im folgenden 

nur die Transformation in eine Ausnahme betrachtet. 

CREATE ASSERTION R inc S 

CHECK ( 

NOT EXISTS ( 

SELECT * FROM R 

IS ADD


) 

WHERE NOT EXISTS ( 

SELECT S id 

FROM S 

WHERE S.Y1 = R.X1, . . . , S.Yk = R.Xk 

) 

) 

Bei mehreren Inklusionsabhängigkeiten zwischen R und S muss der Name der Ausnahme mittels einer 

Nummer erweitert werden. 

Es sollen u.a. Bedingungen der Daten untereinander abgebildet werden. Typische Beispiele sind Beschränkungen 

über Kalenderdaten oder referentielle Integritätsbedingungen wie z.B. 


StudMatrNr char[7] CHECK( 

StudMatrNr IN (SELECT MatrNr FROM Student) 

), 

... 



); 

Exklusionsbeziehungen: Die Exklusionsbeziehungen werden analog zu den Inklusionsbeziehungen in eine 

Ausnahme transformiert. Hierzu ist zu prüfen, das es kein Element in R gibt, zu dem ein passendes 

Element in S existiert. Dies wird durch den SQL Ausdruck 

CREATE ASSERTION R_exclus_S 

CHECK ( 

NOT EXISTS ( 

SELECT * FROM R 

WHERE EXISTS ( 

SELECT S id 

FROM S 

WHERE S.Y1 = R.X1, . . . , S.Yk = R.Xk 

) 

) 

) 

comp(R, R i ) = (m, n) 

CREATE TRIGGER comp_R_i_R_insert 

AFTER INSERT ON R_i 

REFERENCING NEW TABLE inserted 

WHEN ( ( SELECT COUNT(*) FROM R, inserted 

WHERE R.R i = inserted.R_i_id ) < m ) OR 

( SELECT COUNT(*) FROM R, inserted 

WHERE R.R_i = inserted. R_i_id ) > n ) ) 

ROLLBACK TRANSACTION 

CREATE TRIGGER comp_R_i_R_update 

AFTER UPDATE OF R_i id ON R_i 


REFERENCING OLD TABLE deleted 

WHEN ( ( SELECT COUNT(*) FROM R, deleted 

WHERE R.R_i = inserted.R_i_id ) < m ) OR 


IS ADD


WHERE R.R_i = inserted. R_i_id ) > n ) ) 


CREATE TRIGGER comp R_R_i_insert 

AFTER INSERT ON R 


WHEN ( ( SELECT COUNT(*) FROM R_i, inserted 

WHERE inserted.R_i = R_i. R_i_id ) < m ) OR 


WHERE inserted.R_i = R_i. R_i_id ) > n ) ) 


CREATE TRIGGER comp_R_R_i_update 

AFTER UPDATE OF R_i ON R 



WHEN ( ( SELECT COUNT(*) FROM R_i, deleted 

WHERE deleted.R_i = R_i.R_i_id ) < m ) OR 

( SELECT COUNT(*) FROM R_i, inserted 

WHERE inserted.R_i = R_i. R_i_id ) > n ) ) 


CREATE TRIGGER comp_R_R_i_delete 

AFTER DELETE ON R 


WHEN ( ( SELECT COUNT(*) FROM R_i, deleted 

WHERE deleted.R_i = R_i.R_i_id ) < m ) ) 


2.8.4 Compiler-Zugang 

Abbildung 50: Übersetzungsphasen eines Mehrpaßcompilers 

Die Umgebung eines Compilers. 

IS ADD


Präprozessor: Der Präprozessor wird vom Compiler aufgerufen und hat die Aufgabe Makros 4 zu ersetzen. Falls 

das Programm aus mehreren Quelltexten besteht, ist er außerdem dafür zuständig, die verschiedenen Teile 

zusammenzusetzen. 

Compiler: Der Compiler erhält seine Eingabe, den Quellcode, vom Präprozessor und übersetzt diesen Code in eine 

Zielsprache: Assembler- oder Maschinencode. Auf die Arbeitsweise des Compilers wird später genau eingegangen. 

Assembler: Es gibt Compiler, die Assemblercode ausgeben und an den Assembler weitergeben. Dieser erzeugt 

dann einen verschiebbaren Maschinencode, indem er Assemblerbefehle in Maschinenbefehle transformiert, 

symbolischen Namen (z.B. Labels) Maschinenadressen zuweist und ein Objektprogramm 5 erzeugt. 

Binder: Der Binder hat die Aufgabe, Objektprogramme aus verschiedenen Dateien (aus verschiedenen Übersetzungen 

oder systemeigene Bibliotheksdateien) in verschiebbarem Maschinencode zu einem Programm zusammenzufassen 

und die Querverweise 6 und externen Referenzen 7 aufzulösen. 

Lader: Der Lader fordert entsprechend der Größe des Programms Speicherbereich vom Betriebssystem an. Anschließend 

lädt er das Programm in diesen Bereich im Arbeitsspeicher, ersetzt die verschiebbaren Adressen 

durch nicht verschiebbare absolute Adressen und startet das Programm. Häufig sind Binder und Lader zu einem 

sogenannten Bindelader zusammengefasst, der dann sowohl die Aufgaben des Binders als auch des Laders 

übernimmt. 

Abbildung 51: Übersetzungsphasen eines Mehrpaßcompilers 

Compilerarten. 

Die Mächtigkeiten von Quell- und Zielsprache können unterschiedlich sein, daher werden Compiler wie folgt klassifiziert: 

Compiler: Die Quellsprache ist mächtiger als die Zielsprache, z.B. der Compiler gcc, welcher einen C-Quelltext in 

Maschinensprache übersetzt. 

4 Makro: Zusammenfassung von Befehlen zu einer mit einem Befehl ansprechbaren Einheit 

5 Objektprogramm: maschinenunabhängiger Zwischencode, in dem unter anderem vorbesetzte Bibliotheken vorliegen 

6 Querverweise - hier: symbolische Verweise, die in anderen Programmteilen definiert sind 

7 externe Referenz - hier: noch nicht aufgelöste Bezeichner, die z.B. in Bibliotheken definiert sind 

IS ADD


Decompiler: Die Zielsprache ist mächtiger als die Quellsprache. 

Präcompiler: Quell- und Zielsprache haben etwa die gleiche Mächtigkeit, deshalb wird ein Präcompiler auch 1-1- 

Compiler genannt, z.B. der Präprozessor vom gcc Compiler unterscheiden sich nicht nur in Mächtigkeit von 

Quell- und Zielsprache sondern auch in Konstruktion und Verwendungszweck: 

Ein-Pass-Compiler: Er benötigt nur einen Arbeitsgang, um den Quelltext in den Zielcode zu übersetzen. 

Mehr-Pass-Compiler: Zunächst wird der Quellcode von einem Präcompiler bearbeitet und anschließend vom Compiler 

in die Zielsprache übersetzt. Hier sind folglich mehrere Arbeitsgänge für die Übersetzung erforderlich. 

Compiler-Compiler: Ein Compiler-Compiler erhält die Beschreibungen für zwei Programmiersprachen und gibt 

anschließend einen Übersetzer (Compiler) von der einen in die andere Sprache aus. Er wird auch Compilergenerator 

genannt 

optimierender Compiler: Dieser Compiler optimiert ein Programm bezüglich Laufzeit und Speicherbedarf, er verändert 

jedoch nicht den Inhalt des Programms. 

Native-Code-Compiler: Der erzeugte Code ist auf dem System lauffähig, auf dem auch der Compiler das Programm 

übersetzt hat. 

Cross-Compiler: Soll das Programm auf einem Rechner B ausgeführt werden, kann aber nicht auf B compiliert 

werden (z.B. Mikrocomputer), benötigt man einen Cross-Compiler, der auf einer anderen Maschine A das 

Programm übersetzt. Cross-Compiler ermöglichen also die Übersetzung für andere Rechnerarchitekturen. 

Just-In-Time-Compiler: Von einem Compiler wird zuerst aus dem Quellcode ein plattformunabhängiger Zwischencode 

erstellt. Dieser wird dann zur Laufzeit des Programms von einem Just-in-Time-Compiler Stück für Stück 

umgewandelt, prozessorspezifisch optimiert und ausgeführt. Eine aufwendige Optimierung hätte allerdings 

eine negative Auswirkung auf die Ausführungszeit. Der Zwischencode wird also nicht interpretiert sondern 

unmittelbar vor seiner Ausführung compiliert, dadurch ist der Just-in-Time-Compiler sehr schnell. 

Übersetzungsphasen eines Compilers. 

Während der Übersetzung durchläuft ein Quelltext verschiedene Phasen des Compilers: die lexikalische, syntaktische 

8 und semantische 9 Analyse, die Zwischencodeerzeugung, die Codeoptimierung und schließlich die Codegenerierung. 

Diese Phasen lassen sich unterschiedlich zusammenfassen. Zum Einen in die Analysephase und die Synthesephase 

(s. Abb.), zum Anderen in Front-End und Back-End. Das Front-End besteht aus den Phasen, die von der 

Quellsprache und nicht von der Zielsprache abhängen, also aus der Analysephase, Zwischencodeerzeugung und teilweise 

der Optimierung. Zum Back-End gehören die Phasen, die sich auf die Zielmaschine beziehen, wie teilweise 

die Codeoptimierung und die Code-Erzeugung. 

Oft entfällt die Synthesephase und der vom Compiler nach der Analyse erzeugte Zwischencode wird von einem 

Laufzeitsystem 10 , das eigene Datenstrukturen verwaltet, direkt interpretiert. 

• Analysephase 

• Lexikalische Analyse 

Die lexikalische Analyse wird vom sogenannten Scanner durchgeführt, ist für die Bearbeitung des Quelltextes 

zuständig und liefert dem Parser einen Strom von Token. Bei der Bearbeitung des Quelltextes filtert 

der Scanner Leerzeichen, Leerzeilen und Kommentare heraus, wertet die Konstanten aus, überprüft, 

8 Syntax: Festlegung, welche Zeichenfolgen als Programme zugelassen sind 

9 Semantik: Festlegung, welche Auswirkung die Ausführung des Programms auf einem Rechner hat 

10 Laufzeitsystem: System, das alle zur Ausführung eines Programms nötigen Routinen zur Verfügung stellt, wie Speicheranforderung, 

Fehlerroutinen, Interaktion mit dem Betriebssystem 

IS ADD


Abbildung 52: Analysephase eines Mehrpaßcompilers 

ob alle Zeichen aus dem Zeichenvorrat der Quellsprache sind und erkennt Grundsymbole und Token. 

Des weiteren ist das Nachladen weiterer Source-Dateien, die in C zum Beispiel über die #include- 

Anweisung angegeben werden, eine Aufgabe der lexikalischen Analyse. Der Scanner arbeitet auf der 

Basis eines deterministischen Automaten 

Erkennt der Scanner ein gelesenes Symbol bzw. eine Symbolteilfolge, wird anhand einer Symboltabelle 

festgestellt, ob dieses Lexem11 irgendwann schon einmal vorkam. Ist dies nicht der Fall, so wird ein 

neuer Symboltabelleneintrag erzeugt und dem Symbol als Attribut einen Verweis auf den entsprechenden 

Eintrag in der Symboltabelle angefügt. 

• Syntaktische Analyse 

Die syntaktische Analyse wird vom Parser 11 durchgeführt. Seine Aufgaben sind es, die syntaktische 

Struktur des Programms entsprechend der Grammatik der Programmiersprache zu erkennen, Syntaxfehler 

zu entdecken und den Ableitungsbaum zu erstellen. Letzterer wird aus den grammatikalischen Grundkomponenten 

erstellt, deren Beziehung untereinander durch die Verbindungen der einzelnen Knoten im 

Baum dargestellt werden. Grundsätzlich gibt es zwei verschiedene Arten von Parsern, die Top-down- 

Parser und die Bottom-up-Parser. Der Top-down-Parser betrachtet zuerst das Programm als Ganzes und 

zerlegt dieses dann bis in seine grammatikalischen Grundkomponenten. Der Bottom-up-Parser beginnt 

mit der Analyse der grammatikalischen Grundkomponenten und baut hieraus das Programm auf. In jeder 

Programmiersprache gibt es Regeln wie z.B. eine Schleife, eine Bedingung oder eine Zuweisung aufgebaut 

sein müssen, ob Variablen vor ihrem ersten Zugriff deklariert werden müssen usw. Wird gegen eine 

dieser Regeln verstoßen, startet der Parser eine Fehlerbehandlung. Um bei einem Compiler-Durchlauf 

möglichst viele Fehler entdecken und melden zu können, bricht der Parser nach einem Fehler seine Analyse 

nicht ab, sondern überliest die nachfolgenden Zeichen bis zu einem synchronisierenden 12 Symbol 

und setzt seine Arbeit dort fort. Der Parser arbeitet auf Basis eines Kellerautomaten, dessen Aufgabe 

es ist, Anfang und Ende von geschachtelten Konstruktionen zu erkennen. Dieser Automat hat endlich 

viele Zustände und besitzt als Speicher für die einzelnen Zeichen einen stack. Abhängig vom Eingabezeichen, 

vom aktuellen Zustand und vom obersten Kellersymbol wechselt der Automat seinen Zustand und 

verändert die Kellerspitze. 

• Semantische Analyse 

Die semantische Analyse baut auf den Ergebnissen der syntaktischen Analyse auf. Im Wesentlichen finden 

drei Überprüfungen statt, nämlich die Typ-, die Eindeutigkeits- und die Gültigkeitsprüfung. Die Typprüfung 

basiert dabei auf dem Typ-System der Quellsprache, welches definiert, wie bestimmte Typen 

11 engl. to parse: zerlegen 

12 synchronisierendes Symbol: abschließendes Zeichen von grammatikalischen Komponenten (wie Deklarationen und Anweisungen), Beispiel: 

; 

in C 

IS ADD


in Ausdrücken verwendet werden dürfen und welchen Typs das Resultat zu sein hat. In C würde eine 

arithmetische Verknüpfung zweier int-Variablen zum Beispiel ein Ergebnis wiederum vom Typ int zur 

Folge haben. Die statische Typprüfung wird während des Kompilierens durchgeführt, kann jedoch nicht 

garantieren, dass es zur Laufzeit nicht zu Typfehlern kommt. 

Prinzipiell ist aber, falls Typ und Wert eines Elements auch in der Zielsprache bekannt sind, die sogenannte 

dynamische Typprüfung ausreichend. Sie findet zur Laufzeit des Programms statt. Die semantische 

Analyse überprüft jedoch nicht nur die Typen sondern sammelt auch Typinformationen, um mit ihnen sowohl 

die Symboltabelle als auch den Ableitungsbaum aus der syntaktischen Analyse durch Attribute zu 

erweitern. Erste Ergebnisse der semantischen Analyse sind also ein attributierter Ableitungsbaum sowie 

eine erweiterte Symboltabelle. Im attributierten Ableitungsbaum werden die syntaktischen Komponenten 

von der Wurzel bis zu den Blättern, die die grammatikalischen Grundkomponenten enthalten, immer 

weiter verfeinert. Die dann folgenden Eindeutigkeits- und Gültigkeitsprüfungen dienen schließlich zur 

Vorbereitung auf die Codeerzeugung, indem beim Durchlaufen des Ableitungsbaumes den Variablen und 

Konstanten bereits relative Adressen zugewiesen werden und des weiteren die eigentliche semantische 

Richtigkeit überprüft wird. Darunter fällt zum Beispiel die Überprüfung von Indexgrößen, von Argumentenanzahl 

und -typ bei Funktionsaufrufen sowie von Typkonformität beiderseits einer Anweisung. Auch 

hier wird, wie bei den vorigen Phasen, im Fehlerfall die Analyse nicht abgebrochen, damit die Fehlerausgabe 

am Ende des Compiliervorgangs möglichst vollständig ist. 

↑ v 

Attributierte Grammatiken A = (G, V, F ) sind durch eine kontextfreie Grammatik G, Attribute V und Attributzuweisungen 

F bestimmt. So kann z.B. für die kontextfreie Grammatik mit den Regeln 

N → S ′′ . ′′ S 

S → S B 

S → B 

B → ′′ 0 ′′ 

B → ′′ 1 ′′ 

eine Ergänzung um den Scale-Faktor f, den Wert v und die Länge l vorgenommen werden, so daß dann für 

eine Werteweitergabe nach unten ↓ bzw. nach oben ↑ im Baum die folgende attributierte Grammatik entsteht: 

N ↑ v → S ↓ f 1 ↑ v 1 ↑ l ′′ 1 . ′′ S ↓ f 2 ↑ v 2 ↑ l 2 [v = v 1 + v 2 ; f 1 = 1; f 2 = 2 −l 2 

] 

S ↓ f v ↑ l → S ↓ f 1 ↑ v 1 ↑ l 1 B ↓ f 2 ↑ 2 

[v = f 1 · v 1 + f 2 · v 2 ; f 1 = 2f; f 2 = f; l = l 1 + 1] 

S ↓ f ↑ v ↑ l → B ↓ f ↑ v [l = 1] 

B ↓ f ↑ v → ′′ 0 ′′ [v = 1] 

B ↓ f ↑ v → ′′ 1 ′′ [v = 1] 

Wir erhalten damit für die Ableitung von 11.01 = 3 1 4 

den folgenden Ableitungsbaum: 

N 

N 

N; v = 3 1 4 

S; l=2 

S; l=2 

S; f = 1 

S; f = 1 4 

S; v=3 

S; v = 1 4 

S; l=1 

B 

S; l=1 

B 

S; f=2 B; f=1 

S; f = 1 2 

B; f = 1 4 

S; v=2 

B; v=1 

S; v=0 

B; v=1 

B; l=1 

1 

B 

1 

B; f=2 

1 

B; f = 1 2 

1 

B; v=1 

1 

B; v=0 

1 

1 

0 

1 

0 

1 

0 

IS ADD


• Synthesephase 

• Zwischencodeerzeugung 

Nach der Analyse und somit als Ende des Front-Ends wird eine maschineneunabhängige Form des Quellprogramms 

aus den Zwischendarstellungen der vorherigen Phasen erzeugt. Dies ist vorteilhaft, falls das 

Programm auf eine andere Maschine portiert wird, denn dann muss ausgehend vom Zwischencode lediglich 

die Codeerzeugungsphase erneut ausgeführt werden. Ein Zwischencode erleichtert also die Weiternutzung 

für ähnliche Zielsprachen. Voraussetzung ist allerdings, dass die Zwischensprache leicht erzeugt 

werden kann und ebenso leicht in die eigentliche Zielsprache übersetzbar ist. Häufig bietet sich dazu der 

sogenannte Drei-Adress-Code an. Nach einer eventuell notwendigen Aufteilung in Teilanweisungen wird 

das gesamte Programm in diesem Code in Instruktionen implementiert, die jeweils eine Zuweisung sind, 

außer dem Zuweisungsoperator höchstens einen weiteren Operator enthalten dürfen und insgesamt aus 

maximal 3 Operanden bestehen. Gegebenfalls werden dazu zusätzliche, temporäre Variablen erzeugt. 

• Codeoptimierung 

Die Codeoptimierung bildet nicht immer eine eigene Phase, da sie meistens in die letzte Phase, die Codegenerierung, 

integriert ist. Es können jedoch immer zwei Arten der Codeoptimierung unterschieden 

werden, nämlich zum Einen die maschinenabhängige und zum Anderen die maschinenunabhängige. Die 

maschinenabhängige Codeoptimierung konzentriert sich, wie schon der Name sagt, auf eine Verbesserung 

des Zielcodes hinsichtlich der Zielmaschine. Es wird versucht, Eigenschaften der Zielmaschine 

auszunutzen, so dass zum Beispiel eine ganzzahlige Multiplikation mit 2 durch Shift-Operationen realisiert, 

bestimmte Befehle der Zielmaschine genutzt oder auch die Nutzung von Registern hinsichtlich 

weniger Rechenzeit verbessert werden. Die maschinenunabhängige Codeoptimierung hingegen lässt die 

Eigenschaften der Zielmaschine außen vor und ist dafür zuständig, die Qualität des Zwischencodes zu 

verbessern, dabei aber die Funktionalität zu erhalten. In diesem Zusammenhang kann wieder eine Unterscheidung 

statt finden und zwar die der Übersetzungs- und der Codeoptimierung an sich. Erstere bemüht 

sich die Übersetzungszeit möglichst gering zu halten, dabei aber trotzdem eine umfangreiche Fehlerprüfung 

durchzuführen. Die Codeoptimierung erstellt derweil ein Zielprogramm, das wenig Rechenzeit 

sowie wenig Speicherplatz in Anspruch nimmt. Dazu wird zum Beispiel “passiver” oder ”nicht erreichbarer” 

Code entfernt , Operationskosten eingespart, indem “teure” Operatoren durch “günstige” ersetzt 

werden, oder konstanter Code aus Schleifen herausgezogen. 

Typische Schritte bei der Codeoptimierung sind: 

• einfache Optimierung z.B. algebraische Vereinfachungen, Konstantenfaltung, Unterdrücken von Laufzeitprüfungen 

• Entfernen gemeinsamer Teilausdrücke 

• Fortpflanzung von Zuweisungen 

• Schleifeninvarianter Code 

• Befehlsanordnung 

• Registerzuordnung 

• Codegenerierung 

Im letzten Schritt wird aus dem vorher optimierten Zwischencode der entgültige Zielcode erzeugt, der 

meistens aus verschiebbarem Maschinen- oder seltener aus Assemblercode besteht. Es werden nun also 

ëchte”Befehle erzeugt, was bedeutet, dass jede Zwischencodeanweisung in eine gleichwertige Folge von 

Maschinenbefehlen übersetzt wird und den Programmvariablen verschiebbarer Speicherplatz zugeordnet 

wird. 

Typische Schritte bei der Codegenerierung sind: 

• Erhebung der Eigenschaften der Zielmascheine 

• Coderzeugung für Ausdrücke 

IS ADD


• Coderzeugung für Anweisungen 

• Coderzeugung für Prozeduren 

• Objektdatei, die durch den Binder später zusammengeführt werden kann 

Verfahren der Compilerentwicklung (Wie baut man einen Compiler?) . 

Das Bootstrapping-Verfahren Ein Compiler ist nicht nur durch Quell- und Zielsprache gekennzeichnet, sondern 

auch noch durch die Implementierungssprache des Compilers, das ist die Programmiersprache, in der der 

Compiler geschrieben wurde und wird deshalb auch Basissprache des Compilers genannt. Diese drei Sprachen 

werden in einem sogenannten T-Diagramm dargestellt. 

Abbildung 53: Bootstrapping Verfahren eines Mehrpaßcompilers 

Compiler haben zwei für den Compilerbau wichtige Eigenschaften: 

1. Wie viel Speicherplatz braucht der Compiler und wie schnell ist er? 

2. Wie schnell sind die durch den Compiler erzeugten Programme und wie viel Speicherplatz brauchen sie? 

In einem T-Diagramm wird dann an der entsprechenden Stelle je nach Eigenschaft ein Plus- oder ein Minus- 

Zeichen notiert. 

Abbildung 54: T-Diagramm des Bootstrapping-Verfahren 

Compilerbau-Werkzeuge: Für eine Programmiersprache kann es verschiedene Compiler geben, wie für C zum Beispiel 

den Borland Compiler, den gcc usw. Für ein und dieselbe Programmiersprache müssen alle Scanner und 

Parser der Compiler immer nach den gleichen Regeln arbeiten. Deshalb ist es nützlich Scanner und Parser beim 

Compilerbau nicht immer neu generieren zu müssen, sondern Funktionen zur Verfügung zu haben, die die Implementierung 

dieser Routineaufgaben erleichtern. In diesem Zusammenhang sind besonders die kostenlosen 

Tools Lex als ein Scanner-Generator und Yacc als ein Parser-Generator zu nennen. Sie finden sowohl unter 

UNIX/Linux als auch unter Windows Verwendung und können Scanner und Parser für C/C++, Java, Pascal 

usw. generieren. 

IS ADD


Fehlerbehandlung. 

Lexikalische Fehler werden durch Verletzungen der Syntax hervorgerufen. Die Fehlerart wird zusammen mit der 

Position des fehlerhaften Symbols gemeldet. Die fehlerhaften Symbole werden trotzdem an den Syntaxanlysator 

weitergegeben. 

Fehlerbehandlung in der Syntaxanalyse analog zum recovery realisierbar 

Verfahren 

Panikmodus für rekursiven Abstieg: Die Syntaxanalyse wird abgebrochen. 

Wiederaufsatz mit allgemeinen Fangsymbolen für rekrsiven Abstieg: Tritt ein Syntaxfehler auf, wird der Symbolstrom 

solange überlesen, bis ein Symbol auftritt, das an der Fehlerstelle erwartet wurde oder das 

Nachfolger eines in Arbeit befindlichen Nichtterminalsymboles ist. Mit diesem Symbol wird die Analyse 

fortgesetzt. 

Wiederaufsatz mit speziellen Fangsymbolen für rekrsiven Abstieg: Es werden spezielle Symbole ausgezeichnet, 

mit denen ein Wiederanfahren oder eine Fortsetzung einfach möglich ist. 

Fehlerbehandlung bei tabellengesteuerter Top-Down-Analyse: meist durch allgemeine Fangsymbole 

Fehlerbehandlung bei tabellengesteuerter Bottom-Up-Analyse: meist durch allgemeine Fangsymbole 

Fehlerbehandlung in der Semantikverarbeitung: 

Fehlerbehandlung während der Optimierung: 

Fehlerbehandlung während der Codeerzeugung: 

Qualitätskriterien. 

Sowohl für die Transformation als auch die Compilierung wird strukturelle, semantische und funktionelle Korrektheit 

gefordert. Die Korrektheit muß auch beweisbar sein. Dies ist jedoch selbst für einfache Klassen von Integritätsbedingungen 

wie die Menge der Kardinalitätsbedingungen {(0, 1), (1, 1), (1, n), (0, n)} bereits nicht mehr gegeben, da 

damit auch Inklusions- und funktionale Abhängigkeiten ausgedrückt werden können. Diese Menge ist jedoch nicht 

axiomatisierbar. Damit kann auch die semantische Korrektheit von Transformationen nicht bewiesen werden. Deshalb 

ist eine Compilierung für Datenbankschema nur in Teilfällen möglich. Damit ist unser Ziel eine Transformationstechnik, 

die sowohl den Korrektheitsforderungen genügt als auch Optimierungstechniken einschließt (Optimierender 

Transformer). Einen Teilschritt haben wir bereits mit der Normalisierung von Schemata in HERM-Normalform vorgenommen. 

Die hier vorgestellten Transformationstechniken sollten Qualitätkriterien genügen: 

• Der Transformationsprozeß sollte einfach sein. 

• Der Transformationsprozeß sollte die Strukturen im wesentlichen erhalten. 

• Der Transformationsprozeß sollte die Eigenschaften der unterlegten Implementationstechnologie unterstützen. 

Insbesondere im Falle des relationalen Modelles als logisches Modell sollte durch die Transformation die 

Einfachheit, Pruduktivität und Flexibilität erhalten bleiben. 

• Der Transformationsprozeß sollte weitestgehend unabhängig vom gewählten Datenbank-Management-System 

sein. Das bedeutet nicht, daß die gewählte Plattform eine Berücksichtigung finden sollte. Da mit einer Änderung 

von Versionen stets zu rechnen ist, sollte man die Transformation und damit auch das physische Schema nicht 

zu stark an die Version koppeln. 

IS ADD


• Der Transformation sollte daten-orientiert und weniger prozeß-orientiert angelegt sein. Eine Reihe von Tuningtechniken 

lassen sich konzeptionalisieren wie im folgenden gezeigt wird. Darauf aufbauend können die 

Performanzprobleme direkt in den Entwurf einbezogen werden. 

2.8.5 Compilation von HERM-Schemata 

Vorsicht: Vorgriff auf Funktionalität aufgrund der notwendigen Optimierung 

Schwierigkeiten und Fallen: 

1. Man muß den Unterschied zwischen Primärschlüssel, Primärindex und primärer Zugriffsmechanismus klar 

herausstellen. Der Primärschlüssel ist ein Instrument zur Pflege der Integrität von Daten. Es werden die 

beiden anderen Begriffe nicht impliziert. Der Primärindex kann verschiedenste Verwirklichungen haben. 

Noch unterschiedlicher ist der Zugriffsmechanismus. Er ist der meist aus Performanzgründen favorisierte 

Zugriffsmechanismus. Er kann auf dem Primärschlüssel beruhen, kann aber auch auf einen anderen 

Schlüssel oder sogar auf einen künstlichen Schlüssel wie dem Tupelidentifikator beruhen. 

2. Mit nullwertigen Attributtypen sind nicht alle Auswertungsoperationen mit der gleichen Semantik versehen. 

Da der Vergleich von Daten in diesem Fall zum Wert wahr, falsch oder unbekannt führen kann, 

sind für Nullwerte zusätzlich die Auswertungsoperationen (z.B. Operationen der relationalen Algebra oder 

Aggregationsoperationen) zu betrachten. Hinzu kommt, daß verschiedene Plattformen mit Nullwerten auf 

unterschiedliche Art und Weise umgehen. Eine zusätzliche Programmierung von weiteren Operatoren kann 

nur eine teilweise Lösung bieten. 

Begründung der Notwendigkeit. 

• Verlust des Zusammenhanges zum konzeptuellen Schema nach Transformation im klassischen Zugang, insbesondere 

nach Denormalisierung 

• zu uniforme Übersetzung, jeder Typ muß eigentlich mit seiner Option laufen, dies ist aber zu schrecklich zum 

Spezifizieren, erfordert dann Handarbeit 

• Trigger-Generierung geht meist schief, muß dann per Hand nachgearbeitet werden; wer beherrscht diese Aufgabe? 

• ohne Berücksichtigung der Funktionen 

Wissenschaftlicher Hintergrund: Der ETL-Prozeß. 

ETL: Extract-Transform-Load 

• anstatt des klaasischen Interpreter-Zuganges 

• mit Integration des Profiles und des Portfolio 

• sowie ERzwingungsprofil für Integritätsbedigungen 

einschließlich der berücksichtigung des diamond problems 

IS ADD


Abbildung 55: The Kiel approach to performance forecasting: Parameter zur Erhebung der DBMS-Performanz 

c 1 

c 2 

... 

c n 

✲ 

✲ 

{S i (¯c, ¯p)|1 ≤ i ≤ m} 

✲ 

✻p 1 

✻ p2 ... ✻p l 

o 1 

o 2 

... 

o m 

✲ 

✲ 

✲ 

Abbildung 56: The general model for performance forecasting 

Abbildung 57: The Kiel approach to performance forecasting: Der Synergetik-Zugang 

IS ADD


Abbildung 58: The Kiel approach to performance forecasting: Auswahloberfläche des Prototyps 

Abbildung 59: The Kiel approach to performance forecasting: Auswahl der CPU-Analyse 

Abbildung 60: Comparing the prediction with the real behaviour 

IS ADD


Erfahrungs: Explizite Berücksichtigung des Performanz-Profiles und -Portfolio. 

Beispiel von ETL: Beyond SQL Querying (Not trapped into the SQL trap). 

Tina Musterfrau, 

casual 

user 

?? 

✲ 

user 

in the 

help !! 

DBMS trap help !! 

✻ 

❄ 

Search 

request 

topic 

✿ welt 

concepts 

❄ 

search 

concept 

❄ 

result 

concept 

parametric 

HERM 

expressions 

✲ query ❄ 

form 

✲answer 

form 

❄ 

✮ 

answer 

for search 

relational 

database 

schema 

❄ 

✲ SQL ✛ 

query 

❄ 

SQL query 

set 

DBS 

✛ 

 

❄ 

query 

interface 

data 

base 

DBMS query 

representation 

✻ 

Abbildung 61: Concept-Based Query Processing Instead Of Direct SQL Querying 

Three-Step Approach to SQL Query Generation 

The Cottbus Intelligent NL Request Transformer 

IS ADD


Generation of SQL query candidates based on full information 

Ontology / WordNet / 

thesaurus 

NL 

utterance 

Relational 

database 

content 

Database schema 

in extended 

ER model 

3 ❄ 3 ❄ 

Enriched syntax Proper name 

tree 

candidates 

3 ❄ ✾ 

Priority-ordered paths 

in the extended ER schema 

Translation style 

used for compilation 

of relational schemata 

from HERM schemata 

3 ✾ 

priority-ordered set of SQL query candidates 

Abbildung 62: Three-step Approach to SQL Query Generation 

ONTO- 

LOGY 

WORD 

NET 

Query 

Liquefaction 

RADD 

DB Design 

Tool 

❄ 

DB 

Schema 

Manager 

(e)ER 

Schema 

❘ 

❄ 

DB 

Thesaurus 

Manager 

✒ 

✻ 

❘ 

✯ 

Syntactical 


❄ 

Syntax 

tree 

❄ 

Intelligent 

Path 

Extractor 

❄ 

Paths in 

ER Schema 

✛ NL query ✛ Web Input 

ER2R 

Translation 

Style 

ISL ✻ 

DBMain 

DB Design 

Tool 

■ 

... 

✲ 

Database 

❄ 

Relational 

Query 

Melting-Pot 

Database 

✛✲ Managem. 

System 

✲ Paths and 

SQL queries 

✲✛ 

DB2Web 

System 

✲ 

✲✛ 

Web 

Presenter 

Abbildung 63: The Cottbus Intelligent NL Request Transformer 

IS ADD


Abbildung 64: 

Das Vorlesungsplanungsbeispiel zur Illustration 

IS ADD


Which lectures are given by Vierhaus and Thalheim? 

IS ADD


The Trick Behind the Curtain: Media Types for Specification of Content 

• Raw media types = (cont(M), sup(M), view(M), op(M)) 

content type cont(M), set of supertypes sup(M), 

view(M) = Q (S inp , S outp ) 

generic functions op(M) for changing the database 

• Attached operations: (signature, selection type, body) 

selection type - supertype of cont(M) 

e.g. generalization/specialization, reordering, browsing, linking, surveying, searching, join 

HERM view 

• Media type: raw media type + unit extension 

+ order extension + cohesion/adhesion + hierarchical versions 

• Usage modeling: usage dimensions, scales, user profiles, user kind 

• Container = (cont(C), layout(C), kind(C)) 

for shipping and representation 

IS ADD


HERM-Compiler 0. Konfiguration des HERM-Übersetzers. 

Kanonische Spezifikation von Typen 

HERM-Typ 

T comp(T) keySyst(T) integr(T) Σ T 

.... ... ... 

relationaler Typ 

R attr(R) keySyst(R) Σ R 

.... ... ... 

• “abgebogene” 

Constraints 

• domain constraints 

• constrained references 

innere 

Listen-Typ 

XML multilist(L) keySyst(L) integr(T) Σ L 

.... ... ... 

• Σ L als refStructure mit expliziter variabler Listensemantik 

• hier auch expliziter Stil 

eg., “Russian doll” oder auch “Venetian 

blind” oder auch “Salami slice” 

DBMS-Profil z.B. 80er Jahre 

• atomare Attribute 

• primary key - entity integrity rule / assumption 

• rudimentäre domain constraints 

• domain-key-NF als die präferierte NF 

wobei auch viele Einschränkungen hinzukommen z.B. INT4 als Typ 

• Index-Strukturen 

oder auch DBMS der 90er 

• domains als UDT’s 

• automatische ID als TID 

oder auch XML oder semistructured DBMS 

• rationale Bäume mit expliziter Führung der Referenzen 

• semantically meaningful units overlay structure with units 

Architektur des Systemes mit einigen expliziten Annahmen z.B. 

• Integritätspflege über Schnittstellen z.T. 

• nur über stored procedures werden interfaces gefildet 

• ... 

Unterstützung der Integritätspflege 

Typensystem ist 

• mengenbasiert 

• multimengenbasiert 

• listenbasiert 

IS ADD


Complex attributes mit Default-Einstellung 

• Flattening z.B. zum String-Datentyp 

• Wurzel-Attribute 

• Separates Schema 

• Listen-Type 

Hierarchies entweder mit dem event-separation oder dem union oder der Universal-Relationen-Annahme 

Null value support je anch DBMS 

Strong or weak semantics 

Weak support as the normal case 

Cluster mit/ohne Harmonisierung der Identifikation oder verallgemeinerter, angereicherter Integrität [Wan98] 

Treatment of cardinality constraints 

Inherent constraints 

Controlled redundancy 

Naming conventions 

Abbreviation rules z.B. bei Erzeugung von .-Notationen 

Portfolio-Aufnahme der Anwendung. 

(DB − Schema, F unctionality, Support − Schema) mit 

Functionality umfaßt auch: access portfolio und modification portfolio 

modelliert am einfachsten als Überlagerungsschema 

schema × function → P(schema) 

y.B. auch S × Q → query − subschema 

mit DBschema × q → (DB − sub − schema, result − schema) 

oder auch DBschema ∪ views × q → (DB − sub − schema, result − schema) 

wobei auch Anfrageformen und Antwortformen verwendet werden können 

Abgeleitete Übersetzungsoptionen. 

analog zu den compiler directives (C, C++) 

1. Hierarchien-Behandlung 

2. kontrolleirte Redundanz 

3. NULL support 

4. Constraint enforcement insbesondere für 

• ID und Integration 

• cardinality constraints 

• inherent constraints 

IS ADD


siehe auch das vorgestellte enforcement profile and portfolio 

nach den Jaakkola-Thalheim-Rahmenwerk 

5. naming conventions 

6. !!! Schattentypen 

7. Mengen oder Pointer- oder hybride Semantik 

8. explizite abgeleitete Attribute mit refresh-Funktion (Trigger, stored procedures, ...) 

9. Separation der Integritätspflege 

interface-basiert 

TA-basiert 

maintenance-based 

10. orthogonale Schemata separat oder eingefaltet (z.B. Währung, Adresse mit PLZ,...) 

11. Referenztypus: schlüsselbasiert oder reference based 

12. identifier based treatment 

Resultierendes Preprocessing. 

1. Trennung von Defintions- und Nutzungsbaum 

optional normalisiertes HERM-Schema mit IC-Anreicherung 

Trick: Attribut-Graph-Schema 

2. Pivoting von Nutzungstypen 

siehe Vorlesungsbeispiel: inserted by ist separierbar 

3. Reduktion ableitbarer Typen 

4. explizite Injektion von impliziten ER-IC 

uses constraints (based-on types) 

5. Bereitstellung von Hilfskonstrukten 

Transformationsobligationen Typus Obligation 

... ... ... 

HERM-Compiler 1. Lexikalische Analyse. 

Resultat: Syntaxbaum und aufgelöste Token 

als Beispiel: β-Schema nach Embley-Beispiel im Handbook, Kapitel 5, Bild 5.2. 

ggf. auch mit bereits erfaßten interface-gepflegten IC 

Aufteilung in Sinneinheiten 

1. Ableitung eines kanonischen HERM-Schemas 

Definitionstypen unabhängig in der Existenz, hin zu Kern-Entity-Typen 

ER-Schema mit expliziten Existenzabhängigkeiten 

2. FD-Umgebung eines Typen 

auch unter Einbeziehung der Subtypen 

i.a. nur erste Stufe erfoderlich 

Env 1 F D = {T 1(...), .T p (.....)} 

IS ADD


3. Aufbau eiens Token-Waldes 

Entfernung der Redundanz unter den Zeichen 

Entfernung von Pragmas (processing directives) 

HERM-Compiler 2. Syntaktische Analyse. 

Resultat: erweiterter Syntaxbaum, Baum der Integritätsbedingung 

ggf. auch mit bereits erfaßten interface-gepflegten IC 

Zusammenfassung zu Einheiten (Abletungsmechanismen dazu, auch unter Berücksichtigung der hierarchischen 

Struktur) 

d.h. von 

T comp(T) keySyst(T) integr(T) Σ T 

.... 

zu 

... ... 

mit Env(T) = ∅ 

T ∪ env(T) comp(T) ∪ foeignKeys(T) keySyst(T) integr(T) Σ T ∪ foreignKeyConstraints(T) 

.... ... ... 

beachte auch mit Erzwingungsform 

damit 

1. Env(T)-Ermittlung 

2. Auflösung der Compiler-Directives 

• Hierarchien-Behandlung (union, root entity type, new attribute for each specilisation, cluster) 

• redundancy 

• NULL support 

• enforcement style 

• naming and binding 

• shadow, set semantics, derived notions 

• orthogonale Schemata, reference type, ID 

HERM-Compiler 3. Semantische Analyse. 

Resultat: Schema korrekt, Schema erfüllbar 

Ermittlung und Überprüfung der semantischen Eigenschaften 

Verbesserung der Schemata 

Typensystem für Dom(S) ggf. mit Überprüfungsmechanismen und Ableitung 

Optionen für Optimierer 

Steeg-Beispiel 

Ableitung einer attributierten Grammatik 

eiinschließlich azyklischer Attributierung 

1. Ableitung der IC 

2. Control of IC 

3. Coherence of IC, e.g., diamond property 

IS ADD


HERM-Compiler 4. Zwischencodeerzeugung. 

Resultat: Schema in der Zielsprache als logisches Schema 

anhand von HERM Regeln 

1. Auflösung der komplexen Attribut-Typen (Menge, Liste, Multimenge, Tupel, ...) zu (STRING, RECORD, separates 

Schema, Kodierung, Einmbettung in anderes Attribut) 

2. mit expliziter Umgebungsintegration 

von 

T comp(T) keySyst(T) integr(T) Σ T env(T) 

.... ... ... ... 

zu 

T comp(T) ∪ primKey(T) keySyst(T) integr(T) Σ T ∪ foreignKeys(T) 

.... ... ... 

Damit dann direkte Zwischencodeerzeugung 

1. Ableitung von Hilfsstrukturen 

Indizes, views, Schlüssel, ID-Types 

2. Preschema 

einschließlich der Mengengerüste, nullable attributes, default values 

3. view derivation 

4. index derivation 

5. precedural components, trigger, stored procedures 

Girokontokarte 

(1,1) 

✛ 

nutzt 

⊕ 

✲ 

berechtigt 

❄ 

❫ 

Girokonto ✛ besitzt 

✲ 

(1,1) 

❘ 

Kunde 

Abbildung 65: Ein einfache Bankanwendung mit alternativer relationaler Wiederspiegelung des Clustertypen 

wird durch die explizite Einführung der Art der Girokontenkarte anstatt einer Einführung eines weiteren Relationentyps, 

mit dem die Kundenkarte des Berechtigten von der Kundenkarte des Inhabers unterschieden wird (Vorteil: 

damit sind Kontobewegungen mit der Karte direkt der Karte zugeordnet) 

Kunde KundenNr Konto KontoNr KundenNr 

IS ADD


Berechtigter KundenNr KontoNr Kundenkarte KartenNr KontoNr Art 

Berechtigter[KundenNr] ⊆ Kunde[KundenNr] 

Berechtigter[KontoNr,KundenNr] || Konto[KontoNr,KundenNr] 

σ Art=“direkt ′′(Kundenkarte[KontoNr,KundenNr]) ⊆ Konto[KontoNr,KundenNr] 

σ Art=“berechtigt ′′(Kundenkarte[KontoNr,KundenNr]) ⊆ Berechtigter[KontoNr,KundenNr] 

Durch ein derartiges Herangehen kann dann auch aufNormalform-Garantien (siehe Embley spüter, translate & 

normalise (im compiler) versus normalise & translate (im Preprocessor)) orientiert werden. 

HERM-Compiler 5. Vorbereitung zur Schema-Optimierung. 

Ziel: Vermeidung überflüssiger oder schelchter Berechnungen 

Ersetzung von Berechnungen durch billigere 

Anpassung an die Hardware und Architektur 

1. post normalisation 

2. view optimisation 

index optimisation 

3. materialisation options 

4. process separation into database phases 

initialisation phase 

production phase 

archive phase 

... 

5. query etc. hints 

Vorbereitung auf Performanzbetrachtungen 

1. Kernentitytypen 

Kernentitytypen stellen unabhängig voneinander existierende Klassen von Objekten dar. Ausgehend von Kernentitytypen 

werden Spezialisierungs- und Generalisierungshierarchien dargestellt. Damit wird festgelegt, welcher 

der Transformationszugänge (event-separation, event-nonseparation, union, weak-universal-relation) für 

Hierarchien benutzt werden. 

Die Reihenfolge der Attributtypen kann aus Performanzgründen verändert werden. Häufig benutzte bzw. Typen 

mit Wertebereichen fester Länge sollten zuerst entworfen werden. Die Reihefolge hängt von der beabsichtigten 

Plattform ab, deren Eigenschaften nun zu integrieren sind. 

Attributtypen 

Pragmatik: 

Die Zuordnung der Transformationszugänge kann durch eine Betrachtung der Inklusionsabhängigkeiten vereinfacht 

werden. Liegen echte Inklusionsabhängigkeiten vor und keine ‘Geschwister’typen, dann liegt eine 

Spezialiserungshierarchie für diesen Kerntypen vor. 

Im Beispiel können wir die Typen Lehrstuhlinhaber, Dekan, Person und Angestellter betrachten. Es gilt keine 

Exklusionsbeziehung der ersten beiden Typen, aber eine Exklusionsabhängigkeit dieser beiden Typen zum 

letzten Typen. Somit sind entweder die Typen Lehrstuhlinhaber, Dekan einem gemeinsamen Supertypen zugeordnet, 

der mit dem Typen Angestellter einen Kerntypen bildet, oder der Typ Person ist ein Kerntyp. 

Analog sind zusätzliche Attribute ein Hinweis auf eine Eigenständigkeit der Teiltypen. 

Hierarchien können kompakter gestaltet werden, sobald entsprechende Komplexitätsbeschränkungen comp(R, R ′ ) = 

IS ADD


(1, 1) gelten. In diesem Fall ist zu prüfen, ob eine Eigenständigkeit beibehalten werden muß aufgrund der Anwendung. 

Da in der Modellierung aus bestimmten Gründen Entitytypen auseinander gehalten wurden, bleibt auch bei 

einer automatischen Übersetzung diese Differenzierung erhalten. Sollte davon abgegangen werden für das physische 

oder logische Schema, dann liegt ein Modellierungsfehler auf der HERM-Ebene vor. 

Für die spätere Übersetzung verwenden wir den Typennamen, die Typenbeschreibung, den Entwerfernamen, 

Synonymbeziehungen, die Quelle (falls Daten durch Algorithmen generiert werden), die Häufigkeiten und andere 

quantitative Charakteristika. Daneben können die Behandlung von Backup und Wiedergewinnung, Reorganisationsparameter, 

Monitoringanforderungen, Sicherheitsbeschränkungen, Eliminationsbedingungen und 

andere Parameter der Umgebung und der Plattform von Bedeutung sein. Ist dies noch nicht erfaßt oder kann 

nicht aus den bereits entworfenen Informationen erschlossen werden, dann sind diese Informationen für die 

entsprechenden Typen zu erfassen. 

Da Plattformen meist beliebige Reihenfolgen von Attributen nicht unterstützen, ist die Reihenfolge explizit 

festzulegen. Speicherblöcke, Fragmentierungszugänge können eine andere Reihenfolge implizieren. 

2. Anpassung an die Plattform 

Wir unterscheiden relationale, hierarchische und Netzwerkplattformen. Weiterhin können Plattformen nach ihrer 

Hardware (PC, Workstation, Mainframe) und der Architektur (Client/Server etc.) unterschieden werden. 

Eine Transformation legt auch die Speicherzuordnung (Primärspeicher, Sekundärspecher, freier Speicher) für 

Klassen fest. Durch die Kardinalität der Entitytypen wird diese Zuordnung mit bestimmt. Sie ist damit an die 

Eigenschaften der Plattform gebunden, die nun explizit zu berücksichtigen ist. Ein Zugriff im Sekundärspeicher 

ist meist weniger effizient. Deshalb sollte ausreichend Primärspeicher vorgesehen werden können. Ansonsten 

ist eine horizontale Dekomposition vorzusehen. 

Die Affinität von verschiedenen Entitytypen bedingt oft auch einen gemeinsamen Zugriff bzw. eine gemeinsame 

Modifikation. Sieht eine Plattform nur relativ kleine Teile einer Datenbank zur gemeinsamen Abspeicherung 

vor, dann ist durch die Affinität bereits eine Abspeicherungsstrategie determiniert. Für solche Plattformen 

ist die Affinität mit zu modellieren. 

Analog ist der parallele Zugriff verschiedener Benutzergruppen zu behandeln. In diesem Fall ist das gemeinsame 

Benutzen von Daten mit darzustellen. 

Pragmatik: 

Meist sind die Regeln für eine Plattform nur sehr schwer aus den Begleitdokumentationen abzuleiten. Eine 

Abhilfe kann dann eine Benutzung von entsprechenden Entwurfshinweisen für die gewählte Plattform sein. Es 

werden die Entwurfshinweise mit unserem liberaleren Zugang verglichen und die Unterschiede auf Implementationsbeschhränkungen 

untersucht. 

3. Erzwingungsregeln für Entitytypen 

Einige Plattformen erlauben nur eine Erzwingung über Primärschlüsseln. In diesem Fall sind die Schlüssel, die 

vererbt werden, an die Erzwingungsregeln anzupassen. Weiterhin erlauben einige Plattformen für Primärschlüssel 

keine Nullwerte. Dann sind auch Nullwerte auszuschließen oder entsprechende Identifikatoren einzuführen. 

Die Komplexität der Erzwingungsregeln kann für verschiedene Plattformen unterschiedlich sein. Deshalb ist 

diese Komplexität bei der Beurteilung der Erzwingungsregeln mit einzubeziehen. 

Pragmatik: 

Obwohl das Einschränken der Schlüssel auf Primärschlüssel unserer Entwurfsphilosophie widerspricht, erhöht 

dieses Einbeziehen die Transparenz der Übersetzung des Schemas für den Benutzer. Deshalb wurde in diesem 

Schritt diese Einschränkung mit eingeschlossen, sobald die Plattform nur diese Behandlung zuläßt. Zugleich 

wird aber diese Einschränkung auch zu einer relativ harten Einschränkung für die modellierten Schemata. Ein 

Mittelweg ist das explizite Darstellen der Implementationseinschränkungen für eine spätere Berücksichtigung 

während des Transformationsprozesses. 

Werden Wertebereiche für die Erzwingungsregeln benutzt, dann entsteht in vielen Fällen ein nur für diesen 

IS ADD


Wertebereich zugeschnittener Code. Damit wird eine spätere Modifikation des Schemas nicht mehr unterstützt. 

Deshalb ist es besser nach einer optimalen Erzwingungsregel zu suchen. Wird durch eine Plattform diese Suche 

nicht unterstützt, dann kann auch die Plattform falsch gewählt sein. 

Eine Reihe von DBMS unterstützen nicht mehrere Schlüssel oder auch nicht komplexere Schlüssel. In diesem 

Fall sind die Erzwingungsmechanismen anzupassen. Das Schema bedarf keiner Änderung. 

4. Regeln für Relationshiptypen 

Auf analoge Art werden Erzwingungsregeln für Relationshiptypen auf ihre Umsetzung und Umsetzbarkeit für 

die gewählte Plattform untersucht. 

Die bereits entworfenen Erzwingungsregeln sind für einen Benutzer transparent. Sie können direkt in den 

meisten DBMS umgesetzt werden. Ist dies nicht für die gewählte Plattform möglich, sind entsprechende Maßnahmen 

zu ergreifen. 

Pragmatik: 

Oft steht für Erzwingungsregeln nur die referentielle Integrität zur Verfügung Deshalb können solche Erzwingungsregeln 

entweder durch Zurückführung auf die Erzwingungsregeln oder durch entsprechende Anwendungsprogramme 

unterstützt werden. 

5. Erzwingungsregeln für Attributtypen 

Es wird für die gewählte Plattform überprüft, inwieweit die entworfenen Datentypen, die Formate, die Wertebedingungen, 

die Eindeutigkeit, Nullwerte und Defaultwerte unterstützt werden können. Ist dies nicht der Fall, 

dann sind evt. Kompromisse ausreichend oder es sind entsprechende Veränderungen am Schema oder an der 

Plattform vorzunehmen. 

Nullwerte sollten anhand der Eigenschaften der Plattform nochmals auf Notwendigkeit untersucht werden. 

Man kann oft eher auf Defaultwerte ausweichen. In diesem Fall sind automatisch generierte Defaultwerte einsetzbar. 

Im Falle der Verletzung der Integritätsbedingungen können Standardfunktionen zur Mitteilung an den Benutzer 

oder den Datenbank-Administrator entwickelt werden. 

Pragmatik: 

Welche der Veränderungsoptionen genutzt wird im Falle eines Konfliktes zwischen Attributtyp und der Darstellbarkeit 

durch die Plattform, hängt von den Möglichkeiten der Plattform, den Kosten und Schwierigkeiten 

einer Integritätserzwingung und der Unterstützung durch Anwendungsprogramme ab. Eine Schlüsseleigenschaft 

kann meist entweder durch entsprechende Datenwörterbücher der Plattform oder durch eindeutige Indizes 

unterstützt werden. Die Eigenschaft, daß ein Schlüssel minimal ist (d.h. keine echte Teilmenge von diesem 

Schlüssel ist wiederum ein Schlüssel) wird sehr selten unterstützt. Ein Ausweg aus der Nichtdarstellbarkeit 

kann auch die Entwicklung einer Menge von Standardprozeduren für die Pflege der Semantik einer Datenbank 

sein. Damit werden jedoch die Implementationsmechanismen für den Benutzer evt. etwas schwieriger nachvollziehbar. 

Es wird eine zusätzliche Programmierung erforderlich. Dieser Zugang ist jedoch einfacher als die 

direkte Benutzergesteuerte Pflege. 

Werden Defaultwerte anstatt von Nullwerten eingesetzt, dann sind die Erzwingungsregeln zu überarbeiten. 

Insbesondere Aggregationsoperationen können zu inkorrekten Werten führen. Werden zusätzlich Standardfunktionen 

eingesetzt, dann sind die generischen Funktionen und die Retrievaloperationen zu kontrollieren und 

gegebenenfalls zu programmieren. Damit werden die Standardoperationen abhängig vom jeweiligen Typ. 

Da ein ständiges Berichten über Integritätsverletzungen nicht nur die Performanz verschlechtert, sondern auch 

dem Benutzer lästig werden kann, sind eher akkumulierende Funktionen sinnvoll, die zu einem festgelegten 

Zeitpunkt die Verletzung von Integritätsbedingungen anmelden. Damit wird jedoch auch das Verhalten von 

Transaktionen verändert, da diese erst mit dem Abarbeiten der Verletzungsliste zuende geführt werden können. 

6. Regeln für die Funktionalität 

IS ADD


Alle Anfragen sind auf ihre Unabhängigkeit von anderen Modifikationen zu überprüfen. 

Für Updateoperationen muß genügend freier Speicher zur Verfügung stehen. Damit ist nach einer umfangreichen 

Modifikationsoperation eine Neuorganisation des Speichers vorzusehen. 

Aus Sicherheitsgründen kann die Weitergabe von Klarnamen an Benutzer nicht erlaubt sein. In diesem Fall 

ist ein Standard für die Namenbehandlung über eine Synonymbeziehung für die ensprechenden Namen mitzuführen. 

Locking-Mechanismen werden benutzt, um eine konsistente Verwaltung konkurrierender Operationen verschiedener 

Benutzer zu ermöglichen. Diese Mechanismen sind durch die Größe der zu blockierenden Datenbankteile, 

durch den Lock-Modus und durch die Lock-Dauer zu unterstützen. Diese Spezifikation ist wiederum 

von der gewählten Plattform abhängig. 

Pragmatik: 

Vorbereitete Anfragen, die Attributnamen nicht näher eingrenzen, sollten möglichst nur in Ausnahmefällen 

verwendet werden. Sie sind für jeder Modifikation des Schemas wieder zuu überprüfen. Damit sind solche Anfragen 

kontextsensitiv. 

Für Lock-Mechanismen ist es sinnvoll, den allgemeinsten Mechanismus auszuwählen. Für die Auswahl der 

entsprechenden Lock-Mechanismen sind bei verschiedenen DBMS die Zuordnung der logischen Tabelle zur 

physischen Speicherstruktur, das physische Layout der Elemente von Klassen, die Bedeutung des Wortes ‘Datenbank’ 

im Rahmen der Plattform und die Herausschälung der Lock-Parameter, die vom Entwerfer wirklich 

beeinflußt werden können. 

HERM-Compiler 6. Schema-Tuning (Operationale Optimierung durch Tuningtechniken). 

Aufgabe: Tuning des Zugriffs und Spezifikation von Indizes 

Tuningtechniken und ihre konzeptionelle Wiederspiegelung 

Weder für das relationale, noch das hierarchische oder Netzwerkmodell gibt es inhärente Probleme, die zu einer 

schlechten Performanz, insbesondere beim Retrieval führen. Die Implementation dieser Konzepte führt erst zu den 

Performanzproblemen. Um das Tuning einer Anwendung zu ermöglichen können folgende Charakteristika betrachtet 

werden: 

1. Es werden Eigenschaften des Anwendungsszenarios betrachtet: 

(a) Art der Berechnung 

i. erforderliche Operationen 

ii. Art der Selektionskriterien 

iii. Datenvolumen (Anzahl der durchmusterten Objekte und der berechneten Resultatsobjekte) 

(b) Sichtbarkeit 

i. Organisationsniveau der Benutzer 

ii. Häufigkeit der Operationen 

iii. Beziehung zum Geschäftsprozeß und seinen Implikationen 

(c) Berechnungsmodi 

i. online (voraussichtlich) 

ii. batch (voraussichtlich) 

iii. interaktiv (ad hoc) 

iv. Berechnung während oder außerhalb von Spitzenzeiten 

(d) Performanzerwartungen 

IS ADD


i. Ausführungszeit (im online- oder batch-Betrieb, während interaktiver Anfragen bzw. die Zeit bis zur 

Auslieferung von batch-Jobs) 

ii. Durchlaßfähigkeit (Transaktions-/Anfrageraten, Modifikationsraten) 

iii. Priorität der Operationen 

2. Es werden Benutzer, die kritische Anforderungen an die Performanz haben, analysiert. Damit können entsprechende 

Bewertungen (Priorität) für deren Operationen gefunden werden und in das Anwendungsszenario mit 

einfließen. 

3. Kritische Transaktionen, Anfragen, batch-Prozesse, die eine Herausforderung für die Performanz darstellen, 

werden besonders angemerkt. 

4. Kritische Prozesse werden mit ihrem Berechnungs- und Zugriffsmechanismus modelliert. Man kann z.B. spezifische 

Zugriffspattern für die Darstellung auf konzeptionellen Niveau nutzen ohne die genauen Zugriffsmechanismen 

oder Berechnungsalgorithmen zu kennen oder weiter vergröbernd nur die involvierten Typen als 

solche kennzeichnen. 

5. Es werden verschiedene Entwurfsalternativen für kritische Teile von Schemata betrachtet. 

Im weiteren werden verschiedene Tuningmechanismen im Detail betrachtet. Die Reihenfolge ist dabei durch die 

Erhaltung der Schemaqualität (Korrektheit, Konsistenz, Stabilität, Natürlichkeit) determiniert. Tuningmechanismen, 

die sich nicht auf konzeptionellen Niveau widerspiegeln, werden im weiteren nur angezeigt, nicht aber ausführlich 

erörtert. 

Tuningtechniken für Zugriffsmechanismen 

Zugriffsmechanismen beeinflussen die Performanz in starkem Maße. Es gibt verschiedene Speicherungsmethoden 

und darauf aufbauend sehr verschiedene Zugriffsmethoden (Durchmustern, Gruppieren, Benutzung von Hash- 

Funktionen). Damit wird auch eine Speichermethode auszuwählen sein, die von der gewählten Plattform zu unterstützen 

ist. Darauf aufbauend können entsprechende Algorithmen für den Zugriff ausgewählt werden. Ein weiterer 

Schritt zur Steigerung der Effizienz ist die Einführung von Indizes. 

Zugriffspfade werden gewöhnlich durch den Optimierer generiert. Der Optimierer benutzt dazu als Eingabedaten 

Statistiken der Datenbankbenutzung (I/O-Raten, Speicherverbrauch, CPU-Zeit usw.). Es werden allerdings durch 

den Optimierer nur die endgültigen Zugriffspfade ausgewählt. Durch die Angabe von Zugriffspfaden kann jedoch 

ein Entwerfer den Zugriffsmechanismus determinieren. Damit ist eine Spezifikation zum einem abhängig von der 

gewählten Plattform und dem Stand der Technologie, zum anderen aber von der Anwendung, insbesondere den 

Prozessen und somit typische Zugriffsmuster. 

Voraussetzung zur Spezifikation der Zugriffspfade sind damit 

Zugriffsmechanismen, die durch die Plattform unterstützt werden können, 

Auswahlmechanismen, die die Plattform für die Auswahl einer spezifischen Zugriffsmethode benutzt 

und die 

kritischen Prozeßanforderungen der Anwendung. 

Man kann und soll sich nicht auf eine Auswahl genau einer Zugriffsmethode konzentrieren, sondern eher auf die 

Auswahl einer optimalen Menge von Zugriffsmechanismen. Damit sind die folgenden Problemstellungen von 

Interesse: 

· Welcher Zugriffsmechanismus kann am besten die verschiedenen Anforderungen der Anwendung befriedigen? 

· Welche Zugriffsmechanismen werden zusätzlich benötigt? Kann evt. die Einführung eines zusätzlichen Index Abhilfe 

schaffen? Kann eine Sortierung den Zugriff erleichern? 

· Welche Zugriffsmechanismen sind zu komplex? Kann z.B. eine Gruppierung den Zugriff erleichtern ohne daß durch 

das schlechtere Updateverhalten die Performanz sinkt? 

IS ADD


Diese Fragestellungen sehen nur auf den ersten Blick sehr maschinennah aus. In Wirklichkeit kann aber gerade 

durch eine Strukturierung bereits ein besseres Verhalten erreicht werden. Damit werden aber zumindest das konzeptionelle 

Modell, mitunter sogar die eine oder andere Sicht einer Veränderung unterworfen. Im allgemeinen ist die 

Auswahl des besten Zugriffspfades ein trickreiches Verfahren. Dazu müssen auch nicht nur die Plattform oder das 

DBMS, sondern auch die Version und Konfiguration des Systemes berücksichtigt werden. Es gibt jedoch einige allgemeine 

Prinzipien, die direkt aus der Anwendung ableitbar sind, auch wenn durch eine relationale Transformation 

bereits aufgrund von Forderungen wie 1. Normalform vorhandenes Wissen nicht direkt dargestellt wird. 

In diesem Schritt wird eine interne Repräsentationsstruktur abgeleitet bzw. es werden Strukturen entsprechend 

dem Verhalten restrukturiert. Zuerst werden dabei Zugriffsmethoden betrachtet (Speicherorganisation, Indexiserungsmethoden). 

In nächsten Schritt werden wir die Forderung nach Redundanzarmut aufweichen entsprechend den Verhaltensanforderungen. 

Damit wird die Struktur in den Sichten und des konzeptionellen Schemas nochmals verändert. 

Oft unterstützen Werkzeuge das Abschätzen der Performanz einer Anwendung. Solche Werkzeuge verlangen 

jedoch ebenfalls eine Abschätzung der CPU-Zeit, der I/O-Zeit, der Durchmusterungszeit und -rate, sowie weitere 

Parameter. Es gibt bereits eine kommerzielle Animationswerkzeuge, mit deren Hilfe die Performanz durchgespielt 

werden kann. 

Hinzufügen von Indexierungsmechanismen 

Indizes können zu jeder Klasse hinzugefügt werden für jeden Identifikationsmechanismus. Da ein Index bei einer 

Modifikation gepflegt werden muß, wählt man nur einige Identifikationsmechanismen aus, für die ein Index angelegt 

und gepflegt wird. 

Wir unterscheiden Gruppierungsindizes, die das Durchmustern unterstützen und auf einer Gruppierung basieren, 

und geordnete Indizes, die auf einer Ordnung der Wertebereiche basieren. 

Außerdem werden Indizes zur Unterstützung der Operationen angelegt. Somit impliziert die entworfene Funktionalität 

auch das Anlegen entsprechender Indizes für die verschiedenen Typen. 

1. Durchmusterungsprozesse 

Für welche Typen ist ein Durchmustern noch ausreichend effizient, für welche nicht? Damit kann für die 

letzteren Typen nach anderen Zugriffsmechanismen gesucht werden. Die Effizienz wird durch die Häufigkeit 

der Modifikationen, durch die Durchmusterungsrate für Anfragen entsprechend den Dialogobjekten, durch die 

Größe der Klassen und das Anwendungsszenario bestimmt. 

Durch Gruppierung, Projektion und Partitionierung kann Durchmustern noch effizienter werden. Deshalb ist 

für die interne Darstellung eine vertikale oder horizontale Dekomposition, eine Verfeinerung der Teiltypenhierarchie 

oder eine Gruppierung sinnvoll. Dabei sind jedoch alle Prozesse im Komplex zu betrachten. Diese 

interne Repräsentation kann den jeweiligen Typen zugeordnet werden. Die konzeptionelle Darstellung wird 

dadurch jedoch nicht verändert. 

Dagegen sollten Klassen mit gleicher Struktur nicht den gleichen Speicherraum zugeordnet werden, weil dadurch 

Durchmustern ineffizienter wird. 

Pragmatik: 

Sequentiell Durchmustern kann heute jedes System. Es ist z.B. bei relationalen Plattformen der Defaultsuchmechanismus. 

Damit muß nur verstanden werden, wann Durchmustern effizient und wann es ineffizient ist. 

Durchmustern ist für kleine Klassen, die nicht zu komplex strukturiert sind (z.B. nicht mehr als 6 physische 

Blöcke für die Daten ihrer Objekte benötigen), für Klassen, für die Anfragen oft einen größeren Teil (mindestens 

ein Fünftel, je nach Plattform) der gesamten Klasse liefern, und für Klassen, über denen nur Anfragen 

einer niedrigen Priorität berechnet werden, eine Alternative. Damit wird die Pflege eines Index nicht mehr 

notwendig. Klassen dieser Form mit häufigen Modifikationen sind deshalb noch effizienter. 

IS ADD


Viele Plattformen unterstützen eine Segmentierung. Damit kann eine horizontale Dekomposition, die mit der 

Struktur der Antworten auf Anfragen korrespondiert, Durchmustern zur effizienten Suchmethode werden lassen. 

Analog kann durch eine Führung von Tupelidentifikatoren und eine Partitionierung bzw. Projektion das Durchmustern 

effizienter werden. Klassen, deren Anfragen nicht zusammenhängen, die aber gleiche Speicherräume 

benutzen, lassen Durchmustern ineffizient werden. Der Verbund von Klassen kann jedoch durch Durchmustern 

unter gewissen Umständen auch effizient werden. 

Die Effizienz von Durchmustern hängt auch von der Plattform ab. Wird z.B. paralleles Durchmustern unterstützt, 

werden Hochgeschwindigkeitsmedien und Techniken wie das Puffern oder andere Ressourcen verwandt, 

dann ist Durchmustern effizient sogar für größere Klassen. 

2. Möglichkeiten von Gruppierungen 

Typen, die häufig auf die gleiche Art durchmustert werden, deren Anfrageoperationen strukturiert (insbesondere 

durch analoge Selektionskriterien) sind und analoge Durchmusterungsreihenfolgen erfordern, können, 

insbesondere falls Modifikationen durch die generischen Operationen eine Gruppierung nicht verändern, entsprechend 

den Operationen gruppiert werden. Neben der Gruppierung kann auch eine Sortierung (Darstellung 

durch eine Liste) die Performanz steigern. 

Bei einer Gruppierung sind die Auswirkungen auf parallele Anfragen mit zu betrachten. Lock-Techniken 

können dadurch vereinfacht werden oder komplexer werden. Wird das Verhalten verschlechtert, dann ist eine 

Gruppierung nicht angebracht. 

Eine Gruppierung ist für Relationshiptypen oft eine geeignete Methode zur Vereinfachung der Operationen 

über solchen Typen. Eine Gruppierung der Komponententypen nach ihren auf den Relationshiptypen vererbten 

Identifikationsmechanismus ist dann sinnvoll, wenn keine verschiedenenartigen Identifikationsmechanismen 

für verschiedene Relationshiptypen erforderlich sind. 

Pragmatik: 

Eine allgemeine universelle Optimierungsmethode existiert nicht. Man muß deshalb Gruppierungen und Ordnungen 

gegen die Komplexitiät der Operationen abwägen. Wird eine Klasse häufig modifiziert und ist die Modifikation 

durch die Gruppierung oder die Sortierung so erschwert, daß sich das Gesamtverhalten verschlechtert, 

dann wird man von einer Veränderung Abstand nehmen. Weiterhin wird bei manchen Plattformen eine Modifikation 

auch das Verschieben ganzer Teilklassen oder eine Neusegmentierung erfordern. Solche Plattformen 

sollten nur mit einfachen Strukturen benutzt werden. 

Kleine Klassen erfordern keine Gruppierung. Für solche ist ein Durchmustern stets effizienter. 

In relationalen Systemen wird die Gruppierung durch ORDER BY, GROUP BY, UNION, DISTINCT, verschiedene 

Arten von Verbunden und Selektionen unterstützt. Damit kann eine entsprechende Repräsentationsstruktur 

angegeben werden. 

Die Gruppierung der Identifikationsmechanismen ist eine einfache und effiziente Methode, solange nicht zu 

viele verschiedene Identifikationsmechanismen für den gleichen Typ geführt werden müssen. Sind Modifikationen 

nicht so häufig, die Trefferquoten für Anfragen relativ niedrig, dann kann eine Indexierung günstiger sein. 

Gruppierungen können auch durch Werkzeuge einiger DBMS für den Optimierer generiert werden. Solche 

Werkzeuge können auch benutzt werden, um freien Speicherplatz für zukünftige Modifikationen zuzuweisen. 

Diese Vorgehensweise liegt jedoch außerhalb unseres Zuganges zur Modellierung von Datenbanken. 

Die Komplexität der Sortierung ist abhängig von der gewählten Plattform. 

In unserem Beispiel kann z.B. ein Reiseverlauf dargestellt werden durch einen Typ, der Abfahrtsort und -zeit, 

sowie Ankunftsort und -zeit darstellt. Eine alternative Form ist die Verwendung einer Liste mit Listenelementen, 

die den Ort und die Zeit darstellen. Mit der letzten Form werden Konsitenzüberprüfungen zum Reiseverlauf 

einfacher. 

IS ADD


3. Möglichkeiten von Hashmechanismen 

Da der Hashzugriff besonders schnell ist, sollte für Abfragen in großen Klassen, die einen Zugriff auf Objekte 

in zufälliger Ordnung benötigen und relativ wenig Modifikationen erfahren, ein Hash-‘Schlüssel’ benutzt 

werden können. Hashzugriffe können insbesondere für Komponenten vorgesehen werden, die vielen Anfragen 

gemeinsam sind. Kann eine Hashfunktion benutzt werden, dann ist die Verteilung der Daten zu spezifizieren, 

sowie eine Strategie für Konfliktfälle, in denen der Zugriff auf mehrere Objekte erfolgt, die dann weiterselektiert 

werden. 

Pragmatik: 

Mit einer Angabe der Verteilung der Daten der Objekte in einer Klasse kann meist auch eine Hash-Funktion 

automatisch generiert werden. Da Hash-Funktionen Objekte nicht eindeutig identifizieren müssen, ist vorzusorgen 

für diese Nichteindeutigkeit. Konflikte von Hashwerten, d.h. eine Hash-Funktion generiert gleiche Werte 

für verschiedene Objekte, sollten beschränkt bleiben. Hashing ist nicht anzustreben, wenn die Wertebereiche 

nicht ausreichend genau spezifiziert sind, wenn die Werte nicht gleichverteilt vorkommen, wenn die verwendeten 

Komponenten nicht einfach zu einem Schlüssel ergänzt werden können, wenn die Selektionskriterien 

von Anfragen den Hash-‘Schlüssel’ nicht enthalten oder der Zugriff selbst nicht zufällig erfolgen kann. Hash- 

Techniken sind als Ergänzung zu anderen Zugriffstechniken anzusehen. Hash-Techniken können in verteilten 

DBMS meist nur für einen Ort angewandt werden. 

Häufig benutzte Kombinationen von Komponenten in Selektionskriterien eignen sich besonders dann für Hashfunktionen, 

wenn diese Komponenten nicht zu häufig modifiziert werden. Werden jedoch Teilmengen von den 

Hashfunktionen zugrundegelegten Komponenten in Selektionskriterien benutzt, dann können diese Hashfunktionen 

nicht benutzt werden. 

Die Auswahl einer geeigneten Hashfunktionen ist keine Aufgabe des Entwurfes. Sie wird für einige DBMS 

durch Werkzeuge unterstützt, in einigen DBMS werdenn Hashfunktionen sogar automatisch generiert. 

4. Auswahl von Schlüsseln 

Indizes werden für große Klassen angelegt, für die Anfragen eine relativ kleine Teilmenge auswählen und für 

die Anfragen über relativ wenige Komponenten reichen. Schlüssel bzw. Identifikationsmechanismen mit diesen 

Eigenschaften werden gekennzeichnet mit entsprechenden Indizes. 

Es ist bei der Auszeichnung eines Schlüssels für einen Index die Verschlechterung der Performanz möglich. 

Deshalb muß das Anlegen von Indizes abgewogen werden. 

Pragmatik: 

Beim Anlegen von Indizes können Gruppierungsindizes oder geordnete Indizes angelegt werden. Für die meisten 

Plattformen sind Gruppierungsindizierungsmechanismen vorhanden. Kann man eine Ordnung angeben, 

die mit der Ordnung einer Anwendung oder einer Reihe von Anfragen korrespondiert, dann ist ein geordneter 

Index mit der Angabe der Ordnung besser. 

Können verschiedene Klassen im gleichen Speicher abgelegt werden, dann können Indizes benutzt werden, um 

diese Klassen voneinander zu trennen. Damit kann ein Mehrklassendurchmustern vermieden werden. 

Das Anlegen und die Pflege von Indizes erfordern zusätzliche Funktionen. Deshalb ist eine Betrachtung der 

Performanz notwendig. Dazu werden Speicherplatzabschätzungen, der Einfluß der generischen Operationen 

insert, delete und update, die Folgen für das Laden der Datenbank, die Reorganisationserfordernisse, die 

Wiederanlaufs- bzw. Rücksetzungszeit und die Sicherungsmechanismen betrachtet. Indizes über kleinen Klassen 

bringen keine Verbesserung der Performanz. 

Indizes über häufig modifizierten Komponenten bringen eine Verschlechterung der Performanz. Diese sind nur 

in Ausnahmesitutationen (keine andere Möglichkeit) zu benutzen. 

Falls die Daten von zu indizierenden Komponenten nicht in regelmäßiger Form verteilt sind, dann ist entweder 

die Verteilung in die Definition mit einzubeziehen oder ein anderer Zugriffsmechanismus zu wählen. Die erste 

IS ADD


Möglichkeit wird nur von wenigen DBMS unterstützt. 

Kürzeste Schlüssel, d.h. solche die sich unter der Menge der minimalen Schlüssel durch die kleinste Speicherdarstellung 

bzw. die die kleinste Anzahl von Attributen besitzen, sind oft effizienter als andere minimale 

Schlüssel. 

Das dynamische Verändern von Indizes kann vor Perioden von intensiven Modifikationen vermieden werden, 

indem der Index vorher entfernt wird und danach wieder neu aufgebaut wird. Indizes, die zur Integritätspflege 

erforderlich sind, können nicht entfernt werden. 

Die Namen der Typen und ihrer Indizes sollten aufeinander auf der Grundlage eines Namensstandards abgeglichen 

sein. 

5. Unterstützung von Operationen 

Operationen, insbesondere Anfragen, die häufiger ausgeführt werden, können durch Indizes unterstützt werden. 

Selektionskriterien, Verbunde von Klassen, Ordnungen (GROUP BY, ORDER BY) und Mengenoperationen wie 

z.B. Vereinigungen (UNION, DISTINCT) können durch Indizes unterstützt werden. 

Schlüssel oder Identifikationsmechanismen, die für Komponenten in Relationshiptypen verwendet werden, 

sollten durch Indizes unterstützt werden. 

Werden Indizes verwendet, dann kann eine Blockierung anderer Zugriffsmechanismen sinnvoll werden, sobald 

diese weniger effizient sind als die Indizierung. 

Pragmatik: 

Werden Indizes zur Unterstützung von Operationen angelegt, dann sollten diese effizienter sein als das Durchmustern. 

Deshalb sollte die Trefferquote niedrig sein. 

Built-in-Funktionen, inbesondere Aggregationsfunktionen, die häufig in Anfragen benutzt werden, sollten durch 

entsprechende Indizes gestützt werden. 

Kann ein geordneter Index mit mehreren Komponenten benutzt werden, dann ist die Reihenfolge der Komponenten 

so zu entwerfen, daß der Zugriff im Mittel schnell erfolgt. Mitunter ist es günstiger mehrere Indizes in 

parallel für jede einzelne Komponente zu benutzen und nicht einen Index, der alle Komponenten erfaßt. 

6. Adaption an die Plattform 

In diesem Schritt können wir verschiedene Implementationsbeschränkungen in den Entwurf einbeziehen. Da 

sich diese nicht direkt auf den konzeptionellen Entwurf auswirken und nur für die Transformation notwendig 

sind, verwenden wir diese Beschränkungen hier nicht für die Entwicklung von Tuningmechanismen. 

Pragmatik: 

Plattformen unterstützen Operationen auf verschiedene Weise. Z.T. werden für bestimmte Operationen auch 

Indizes automatisch angelegt. Die Performanz hängt in diesem Fall auch von den Sortieralgorithmen ab. 

Eine Blockierung anderer Zugriffsmechanismen wird nicht von jeder Plattform unterstützt. Dazu muß auch der 

Optimierer des DBMS angepaßt sein. 

Eine Plattform kann die Verfügbarkeit von Indizes einschränken. Deshalb sollte in diesem Fall bereits eine 

Spezifikation auf Realisierbarkeit insbesondere für parallele Zugriffe geprüft werden. 

Erlaubt eine Plattform eine Verteilung von Klassen und Indizes auf verschiedene Speichermedien, dann sollte 

diese Verteilung aus Zugriffsgründen angestrebt werden. Eine Indexblockierung kann aufgrund der Klassengröße 

eintreten. Deshalb sind die maximalen Klassengrößen mit einzubeziehen. 

Werden durch die Plattform verschiedene Arten von Indizes (eindeutig, nicht-eindeutig; gruppiert, ungruppiert; 

partitioniert, unpartitioniert; verschiedene Speicherstrukturen (B-Bäume etc.)) unterstützt, dann ist eine 

feinere Unterscheidung auch für konzeptionelle Entwürfe sinnvoll. Da die meisten DBMS keine umfangreichen 

Möglichkeiten besitzen, verzichten wir hier auf eine Untersetzung. 

IS ADD


HERM-Compiler 7. Einführung gesteuerter Redundanz. 

Gesteuerte Redundanz 

Unser Ziel ist eine Verbesserung des Verhaltens. Dabei versuchen wir, die Sichten beizubehalten und höchstens 

das konzeptionelle Schema zu verändern. Durch Operationen kann jedoch auch eine Veränderung des konzeptionellen 

Schemas notwendig werden. Ein Performanzengpaß ist z.B. der Zugriff auf mehrere Klassen, die durch Dekomposition 

entstanden sind. Oft wird deshalb eine strenge Denormalisierung empfohlen. Besser ist eine gesteuerte Denormalisierung. 

Diese orientiert sich an den Prozeßanforderungen und den unterstützenden Algorithmen. Operationen 

des DBMS wie Verbund, Vereinigung und äußerer Verbund verursachen oft diese Ineffizienz. Eine andere Ursache 

sind Hierarchien, die eine gemeinsame Bearbeitung verschiedener Klassen erfordern. 

Redundante Abspeicherung sollte jedoch erst dann vorgesehen werden, wenn andere Tuningmechanismen nicht weiterführen. 

Eine redundante Datenbank erfordert zusätzliche Mechanismen zur Integritätspflege. Oft werden diese 

jedoch durch DBMS nicht mit angeboten. 

Vor einer Einführung von redundanten Strukturen sind deshalb 

· alternative Schemata zu untersuchen, inwieweit dadurch entstehende Probleme besser bewältigt werden können, 

· alternative Programmiermethoden oder Algorithmen Probleme besser lösen oder 

· eine Revision des Schemas weiterhilft. 

1. Einführung von Komponentenkopien 

Werden durch Operationen verschiedene durch Normalisierung entstandene Typen wieder verbunden, dann 

kann durch eine Kopie der Komponenten bereits ein Verbesserung der Performanz erreicht werden. Insbesondere 

kann auch eine Kopie von Nichtschlüsselattributen für einen Teiltyp einen Verbund von Supertyp und 

Teiltyp unnötig machen. Analog kann in Generalisierungshierarchien vorgegangen werden. 

Relationshiptypen können eingeführt worden sein, um eine Eigenschaft einer Klasse darzustellen. Durch explizites 

redundantens Mitführen dieser Eigenschaft kann der Relationshiptyp für die Berechnung von Operationen 

unnötig werden. 

Pragmatik: 

Werden Komponenten und insbesondere Attribute in anderen Typen kopiert, dann ist durch eine entsprechende 

Namenskonvention eine Ableitung anzeigbar. 

Jede Einführung von redundanten Komponenten erfordert entsprechende Pflegemechanismen. Deshalb sollte 

eine Einführung auf konzeptionellen Niveau auch mit einer Spezifikation der Pflegemechanismen verbunden 

werden. Außerdem ist der zusätzliche Speicherbedarf mit ins Kalkül zu ziehen. 

Die Wertebereiche und die Semantik der kopierten Komponenten muß im neuen Schema mit dargestellt werden. 

2. Einführung abgeleiteter Daten 

Abgeleitete Daten können die Effizienz von verschiedenen Operationen, insbesondere der kritischen oder häufigen 

Operationen, die einen Verbund von mehreren Klassen erfordern, verbessern. 

Pragmatik: 

Werden abgeleitete Daten mitgeführt, dann ist analog zu abgeleiteten Attributen ein Pflegemechanismus für die 

generischen Operationen auf dem Ursprungstyp mitzuführen. 

Erlaubt die Plattform Dämonen, dann kann auch mit einer verzögerten Anpassung der Daten eine Verbesserung 

erreicht werden. 

Spezielle Namenskonventionen erleichtern das Rekapitulieren der Einführung redundanter, abgeleiteter Daten. 

Synonyme sind damit entsprechend einzuführen. 

Durch ein Vermeiden oder Blockieren von Modifikationen auf den abgeleiteten Komponenten kann eine Inkonsistenz 

zusätzlich vermieden werden. 

IS ADD


Da die abgeleiteten Daten nicht wieder zur Ableitung verwendet werden, ist in diesem Fall der Triggermechanismus 

sicher. Deshalb können über Trigger diese Daten nachgeführt werden. 

3. Einführung von Wiederholgruppen 

Durch Operationen mit hoher Priorität oder mit hoher Frequenz können Gruppenberechnungen erforderlich 

sein. Überwiegen diese Operationen, dann kann eine Einführung einer Wiederholgruppe unter Umständen eine 

Verbesserung der Performanz bringen. 

Durch eine mehrwertige Abhängigkeit kann eine vertikale Dekomposition erforderlich werden. Ist jedoch die 

Wiederholrate begrenzbar, dann kann eine redundate Abspeicherung eine bessere Option sein. 

Ist eine Kardinalität für eine wiederholte Darstellung der Daten abzuschätzen, dann kann durch eine nochmalige 

Einführung der gleichen Komponenten (mit Kennzeichnung der Kopienummer) eine Wiederholgruppe 

simuliert werden. Weiterhin können die Konstruktoren zu einer Verbesserung der Struktur benutzt werden. 

Pragmatik: 

Mehrwertige Abhängigkeiten können auch Ausnahmen der Gültigkeit von funktionalen Abhängigkeiten spezifizieren. 

Dann sind wiederholende Werte eher eine Ausnahme. In diesem Fall ist eine redundante Abspeicherung 

auch begrenzbar. 

Eine andere Begrenzung der Wiederholrate kann man durch Betrachtungen für den mittleren Fall gewinnen. 

Werden Komponenten mehrmals geführt, dann muß eine Verwaltung von Nullwerten explizit geführt werden 

können. 

Im Beispiel kann z.B., falls Dienstreisen von nicht mehr als zwei Antragstellern, meist sogar von zwei durchgeführt 

wird, eine Reise im Relationshiptyp beantragt mit zwei Komponenten Antragsteller1 und Antragsteller2 

geführt werden, wobei die letztere evt. noch optional sein kann. Diese Einführung entspricht der Einführung 

eines Mengenkonstruktors im allgemeinen Fall für die Komponente Antragsteller im Typ beantragt. 

4. Einführung von Abstrakta 

Abstrakta haben keine Bedeutung für die Anwendung. Sie können bei langen Schlüsseln, die relativ viel Speicher 

erfordern, eingeführt werden, falls eine Zugriffsmethode für diese Abstrakta existiert. 

Abstrakta können auch durch eine Vielzahl von Beziehungen erforderlich werden. Damit sind dann z.B. gleichzeitig 

benutzte Objekte (shared objects) in Beziehungen besser aufzufinden. 

Vor der Einführung von Abstrakta sind alle Schlüssel zu untersuchen. Ist ein Schlüssel einfacher, dann kann 

dieser Schlüssel anstatt des ursprünglichen benutzt werden. 

Pragmatik: 

Die Einführung von Abstrakta entspricht der Einführung von Objektidentifikatoren. Diese kann durch die plattform 

bereits vorgegeben sein oder durch den Entwerfer explizit eingeführt werden. Verschiedene relationale 

Plattformen erlauben die Benutzung von Tupelidentifikatoren. Diese Alternative ist äquivalent zur Einführung 

von Abstrakta. 

5. Einführung von Objektkopien 

Es können Objekte direkt kopiert werden oder Objekte aus Objekten abgeleitet oder zusammengesetzt werden. 

Eine Einführung einer Objektkopie erfordert entsprechende Pflegemechanismen. 

Pragmatik: 

Kopien des gleichen Objektes in der gleichen Klasse sind nicht erlaubt. Analog sollten abgeleitete Objekte in 

der gleichen Klasse vermieden werden, weil damit die Identifikationseigenschaft zerstört wird. 

IS ADD


6. Einführung von äußeren Verbunden 

Durch den äußeren Verbund werden auch nicht über den Verbundkomponenten übereinstimmende Objekte 

gewonnen. Damit kann eine Vereinigung von Klassen gewonnen werden. Damit sind Operationen auch auf 

andere Weise darstellbar. Man kann diese Darstellung wählen, wenn dieser Verbund unterstützt wird und die 

Performanz verbessert wird. 

Pragmatik: 

HERM-Compiler 8. Redefinition und Revision von Typen. 

Eine Restrukturierung kann auf logischen oder konzeptionellen Niveau ohne Probleme für die Benutzer durchgeführt 

werden. Damit kann oft eine effizientere Datenbank entworfen werden, ohne daß ein Benutzer die Restrukturierung 

nachvollziehen muß. Wir haben bereits entsprechende Optimierungsschritte auf den Sichten in früheren Schritten 

durchgeführt. Sollte trotzdem in diesem Schritt eine Restrukturierung der Sicht notwendig werden, dann liegt ein 

Modellierungsfehler vor. 

1. Bewertung speicherintensiver Komponenten 

Lange Textfelder und andere komplexe Wertebereiche sind für Schlüssel und den Zugriff nicht geeignet. Deshalb 

sehen wir im konzeptionellen Schema abstrakte Komponenten vor, die die Daten der Komponentenobjekte 

in verkürzter Darstellung verwenden. Kommen komplexe Daten mehrfach vor, dann werden spezifische Typen 

neu definiert. 

Pragmatik: 

Speicherintensive Komponenten ziehen meist auch komplexere (Text-)Verarbeitungsfunktionen nach sich. Deshalb 

sollten auch diese Funktionen bei der Revision mit verwendet werden. 

2. Schrittweise Revision von Komponentenschlüsseln 

Alle Komponenten werden anhand der Dialogobjekte nochmals auf ihre vererbten Identifikationsmechanismen 

überprüft. 

Pragmatik: 

Oft werden die Primäridentifikationsmechanismen für die Definition von Komponenten in Relationshiptypen 

herangezogen, obwohl durch die Anwendung andere Identifikationsmechanismen benötigt werden. Deshalb 

kann selbst in der entsprechenden Sicht eine Modifikation notwendig werden. Dabei muß die Semantik auch 

weiterhin pflegbar sein. 

3. Elimination von Typen 

Typen, die keine neue Information hinzufügen, und Typen, die durch keine Anwendungsoperation benötigt 

werden, können entfernt werden. Vor einer Entfernung ist die Gültigkeit der Entfernungsbedingung zu prüfen. 

Analog können Komponenten, die in keinem Dialogobjekt benutzt werden, entfernt werden, falls sie für die 

Anwendung keine Bedeutung besitzen. 

Pragmatik: 

Redundante Typen existieren auch in Hierarchien, in denen Supertypen nur eine Vereinigung der Subtypen sind 

ohne eigenständige, außerhalb der Identifizierung exisitierende Komponenten zu besitzen. 

Analog kann die Kontraktion von Typen genutzt werden. 

IS ADD


Im Beispiel kann das Teilschema 

Antragsteller = ... 

Fahrkarte = ( { Firma, Preis }, { Firma, Preis } ) 

bestellt = ( Antragsteller, Fahrkarte, { Zeitraum } ) 

Route = ( { Name } , { Name } ) 

möglichT = ( Fahrkarte, Route, ∅ ) 

aufgrund der Gültigkeit von Komplexitätsbedingungen 

comp(bestellt, Fahrkarte) = (1, 1), comp(bestellt, Antragsteller) = (0, n) 

comp(möglichT, Fahrkarte = (1, n) , comp(möglichT, Route) = (1, 1) 

kontrahiert werden zu den Typen 

Antragsteller = ... 

RoutenFahrkarte = ( { Firma, Preis, Route.Name }, { Firma, Preis, Route.Name } ) 

benutzt = ( Antragsteller, RoutenFahrkarte, { Zeitraum } ) , 

ohne Verlust von Semantik. 

4. Hinzufügen von Duplikattypen 

Aufgrund häufiger Anfragen kann auch ein abgeleiteter Typ aus einem Typ durch Projektion, Selektion und 

andere Operationen der Algebra hergeleitet und explizit zur Erleichterung dieser Operationen benutzt werden. 

Pragmatik: 

Auch ad-hoc-Anfragen können durch Duplikattypen erleichtert werden. Analoges gilt für Aggregationsanfragen, 

die kritisch sind. Mit einer Duplizierung ist eine Pflege der Integrität notwendig. 

5. Segmentierung von Typen 

Pragmatik: 

Durch vertikale oder horizontale Dekomposition kann das Verhalten der Datenbank verbessert werden, insbesondere 

dann wenn die Operationen Datenmengen erfordern, die nicht im Hauptspeicher gehalten werden 

können aber durch Dekomposition geladen werden können. 

6. Kombination von Typen 

Pragmatik: 

1:1-Relationshiptypen können durch Einlagerung nicht nur kompakter dargestellt werden, sondern auch zu 

einer Verbesserung der Performanz führen. Verbinden die kritischen Operationen mehrere Typen, sind diese 

Typen weniger separat in Operationen von Interesse, dann kann auch ein kombinierter Typ anstelle dieser Typen 

zu einer Verbesserung der Performanz führen. Auch in Hierarchien kann eine zusätzliche Generalisierung 

oder eine Zusammenführung von Super- und Subtyp Operationen besser unterstützen. 

Analoges gilt für 1:n-Relationshiptypen und n-äre Relationshiptypen. 

7. Kombination durch äußeren Verbund 

IS ADD


Pragmatik: 

HERM-Compiler 9. Betrachtungen für sehr große Datenbanken. 

Große Datenbanken sind heute keine Seltenheit mehr. Insbesondere in klassischen Anwendungen wie der Versicherungsbranche, 

bei Banken, bei Telefongesellschaften und Vermarkungsgesellschaften sind bereits Datenbestände im 

Terabytebereich zu verwalten. 

In neueren Anwendungen zur Erderkundung, in der Molekularbiologie und der Kartographie werden von Anfang 

an sehr große Datenmengen anfallen. Für diese Datenmengen ist eine sehr sorgfältige Planung der Performanz 

erforderlich. 

Schritte 

1. Performanz der Retrieval 

Das Retrieval von Daten kann durch lange Durchmusterungsprozesse und Sortieroperationen z.T. stark verlangsamt 

werden. Deshalb ist bei der Implementation durch verschiedene Tuningschritte die Performanz des 

Retrieval zu verbessern. 

Auswahl von Zugriffsmechanismen; 

Implementation von Beispieltabellen zur Erprobung; 

Implementation von Auswertungsrelationen auf der Grundlage von Beispieltabellen. 

Pragmatik: 

2. Durchlaßfähigkeit 

Hohe Transaktionsraten stellen nach wie vor ein Problem für DBMS dar. Deshalb sollte für große Datenbanken 

die Durchlaßfähigkeit zusätzlich gesondert optimiert, da die Größe der Datenbank und die Anzahl der Transaktionen 

eine doppelte Herausforderung darstellen. Typische Beispiele dieser Art sind Bankenanwendungen, 

in denen die Anzahl der Kunden und der Datenumfang eine größere Anzahl von Transaktionen hervorruft. 

Deshalb wird die Durchlaßfähigkeit gesondert nach folgenden Kriterien optimiert: 

Auswahl der Locking-Mechanismen: Kleine Locking-Granularität erhöht die Parallelisierungsmöglichkeiten. 

Andererseits kann Locking auf Tabellenniveau, insbesondere bei read-only-Locks, die zusätzliche Verarbeitungskapazität, 

die durch Locking-Mechanismen erforderlich sind, minimieren. Deshalb ist für große 

Tabellen ein anderer Abgleich erforderlich. Eventuell sind für diese Lösung zusätzlich ‘dummy’-Tupel 

notwendig. 

Gruppierung: Günstig sind Transaktionen, die Gruppen von Daten erfordern. In diesem Fall kann durch eine 

Gruppierung die Transaktionsrate verbessert werden. 

Partitionierung und Segmentierung: Eine noch günstige Optimierungsmethode ist die Partitionierung und 

die Segmentierung der Daten in Abhängigkeit von den Transaktionen. Damit kann die Abhäsion der 

Daten mit in die Optimierung einbezogen werden. 

Commit-Processing: Durch ein spätes Commit wird die zusätzliche Kapazität, die die Verarbeitung von Commits 

erfordert, minimiert. Sind jedoch die Tabellen sehr groß, dann ist mit einem Abort jedoch ein höherer 

Berechnungsaufwand erforderlich. Deshalb sind für sehr große Relationen frühe Commits günstiger. 

Segmentierung der Updates: Werden die Manipulationsoperationen für größere Datenströme angewandt, dann 

verursachen die seitenweise Verarbeitung, das Identifikationsmanagement etc. einen Performanzverlust. 

Günstiger ist dagegen, die Partitionierung und Segmentierung der Datenströme. 

IS ADD


Pragmatik: 

3. Insert-/Delete-Prozesse 

Die Insert- und Deleteoperationen können für größere Datenmengen einen erhöhten Aufwand durch Logging, 

Locking, Commit-Processing, Indexveränderungen etc. erfordern. Deshalb sollte die Insertoperation optimiert 

werden durch Nutzung folgender Systemroutinen: 

Ladewerkzeuge: Gewöhnlich wird die Insertoperation als eine Ein-Tupeloperation behandelt. Einige Systeme 

erlauben jedoch auch ein ‘Refresh’ oder ‘Replace’ von Tabellen. Außerdem wird oft ein Insert durch 

Anfügen an eine Tabelle implementiert. Günstiger ist - wie in den großen Systemen unterstützt - eine 

vorhergehende Suche nach freiem Speicherplatz in entsprechenden Seiten. 

Temporäres Aufheben des Loggings: Für größere Datenströme kann ein Logging zu aufwendig sein. Kann 

man die Insertoperation wiederholen bzw. die Fehlerbehandlung verzögern, dann ist ein zeitweiliges Unterbrechen 

des Loggings laufzeitgünstiger. 

Temporäres Verändern der Indizes: Da das Verändern von Indizes aufwendig sein kann, ist für große Datenströme 

eine Neuberechnung von Indizes bzw. eine Berechnung eines Inputindexes mit anschließendem 

Mischen günstiger. 

Analog kann ein Massendelete durch Partitionierung und Segmentierung besser unterstützt werden. In unserem 

Beispiel kann z.B. durch eine Partitionierung auf Dienstreisejahre ein Delete vermeiden, das dann einem 

Streichen einer ganzen Relation entspricht. 

Pragmatik: 

4. Checkpoints und Wiederanlauf 

Für große Datenbanken wirkt sich die Benutzung von Sicherungspunkten performanzverschlechternd aus. Dies 

trifft insbesondere auf lange Transaktionen zu. Deshalb ist diesen Transaktionen besondere Aufmerksamkeit zu 

widmen. Sind Transaktionen zerlegbar in Folgen kürzerer Transaktionen, dann sollte eine Zerlegung angestrebt 

werden, falls die zusätzliche Zeit, die für die Verbindung der einzelnen Teile erforderlich ist, nicht zu stark ins 

Gewicht fällt. 

Pragmatik: 

5. Adminstration, Scheduling und Werkzeuge 

erfordert meist einen zusätzlichen Aufwand. Ist dieser nur linear vom Umfang der Daten abhängig, dann ist 

eine Benutzung der Tools eher sinnvoll als bei höherer Komplexität. Im letzteren Falle kann Abhilfe durch 

folgende Lösungen geschaffen werden: 

Ausnutzung der Parallelisierung: Bei nichtlinearer Komplexität von Werkzeugen kann durch eine zielgerichtete 

Parallelisierung eine Verbesserung erreichen. 

Benutzung von partiellen Funktionen anstelle von totalen: Ein Beispiel sind Backupfunktionen. Werden Backups 

regelmäßig durchgeführt, dann kann auch ein partielles Backup für die Änderungen seit dem letzten 

Backup effizienter sein. 

Geringere Benutzung der statistischen Funktionen: Sind die Änderungen minimal verglichen mit der Größe 

der Relationen, dann kann auch auf Statistiken, die die Verwaltung der Datenbank vergleichen, verzichtet 

werden. 

IS ADD


Betrachtung der Fehlerbehandlungszeit: Für große Datenbanken kann die Fehlerbehandlung auch zu groß 

werden. Durch unterschiedliche Fehlerbehandlungskonzepte kann die Zeit minimiert werden. 

Pragmatik: 

HERM-Compiler 10. Vorbereitung für Veränderungen der Datenbanksysteme. 

Datenbanken sind für viele Anwendungen auch in der Struktur nicht statisch. Sowohl die Struktur als auch die Semantik 

und insbesondere die Funktionalität unterliegen einer häufigen Veränderung. Viele Veränderungen können 

durch relationale DBMS aufgefangen werden. Einige Veränderungen wirken sich jedoch stark auf vorhandene Funktionen 

aus. In der relationalen Technologie wird zwischen der Delete- und der Dropoperation unterschieden. Letztere 

Operation erlaubt neben dem Streichen eines Objektes auch das Streichen der zugehörigen Struktur. Analoge Auswirkungen 

kann die Insertoperation haben. 

Syntax: 

Pragmatik: Eine Modifikation, das Streichen und das Hinzufügen von Tabellen kann die Arbeit der Datenbank in 

wesentlichen Teilen stark verändern. Deshalb ist es sinnvoll, den gesamten Modifikationsprozeß in die Datenbankentwurfsgeschichte 

einzuarbeiten. 

Vor Veränderungen der Datenbank ist es sinnvoll, ein Veränderungsszenario zu entwickeln. Dieses Szenario 

schließt auch eine Betrachtung der Risiken von Veränderungen mit ein. 


Schritte 

1. Streichen von Schema-Objekten 

Veränderungen in der Datenbankstruktur können in einigen Systemen nur durch ein vollständiges Entfernen 

der Tabellen und anschließenden Neuaufbau bewerkstelligt werden. Dazu gehören Änderungen des Datentypen, 

das Verbot von Nullwerten, das Streichen einer Spalte, die Änderung von Defaultwerten, Partitionierung, 

Segmentierung und Kombination von Tabellen, Änderungen des Hashmechanismus, Änderungen in der 

Gruppierung und Veränderungen der Abspeicherung. Einige Systeme blockieren während der Dropoperationen 

andere Benutzer. Sind mit den Relationen, die verändert werden zusätzlich noch andere Relationen, z.B. 

durch Trigger verbunden, dann kann die Dropoperation weitreichende Auswirkungen in der Datenbank haben. 

Das Streichen einer Sicht zieht auch das Streichen aller darauf basierenden Sichten, insbesondere auch 

der Sicherheitssichten, nach sich. Sicherer sind deshalb eingeschränkte Dropoperationen, die nur ein Streichen 

erlauben, wenn keine anderen abhängigen Relationen existieren. Dann sind jedoch Veränderungen in der Datenbankstruktur 

nur schwer möglich. 

Moderne Systeme generieren deshalb als Antwort auf eine Dropinformation eine Reihe von Warnungen über 

die Implikationen der Dropoperation. Erst bei Bestätigung der Auswirkungen als gewünschte Auswirkungen 

wird dann die Dropoperation ausgeführt. 

Deshalb sollte vor dem Streichen von Relationen der Effekt dieser Operation auf alle Objekte der Datenbank 

untersucht werden. Dabei sind alle expliziten und impliziten Integritätsbedingungen besonders zu untersuchen. 

Wird eine Streichoperation ausgeführt, dann ist es sinnvoll alle Benutzer von dieser Veränderung zu informieren. 

IS ADD


In Systemen, in denen eine Dropoperation automatisch kaskadiert wird, sollten extra Mechanismen vor den 

unerwünschten Effekten dieser Operation warnen oder durch eine Rückführung der implizierten Reaktionen 

auf eine Dropoperation die Wiederherstellung des korrekten Zustandes ermöglichen. 

Pragmatik: 

2. Hinzufügen von Schema-Objekten 

Das Hinzufügen ist im allgemeinen eine einfache Operation. Implizite Annahmen der Datenbank können jedoch 

auch davon beeinflußt werden. Dazu gehören Namenskonventionen, Sicherungsmechanismen, Sicherheitsmechanismen 

und die Authorisierung. Außerdem können die Speichermechanismen davon betroffen sein. 

Wird eine Relation hinzugefügt, dann ist auch die Integrität gesondert zu betrachten. Dazu gehören auch Integritätsbedingungen 

und Erzwingungsregeln. 

Pragmatik: 

3. Modifikation von Schema-Objekten 

Die Modifikation von Relationen kann um ein Vielfaches komplizierter sein als das Hinzufügen. Es kann 

sowohl die physische als auch die logische Struktur geändert werden. Änderungen in der physischen Struktur 

sind z.B. Veränderungen der Speicherzuordnung, von Indexierungen, von Locking- und Pufferstrategien. 

Veränderungen in der logischen Struktur sind meist Veränderungen, die sich in der konzeptionellen Struktur 

auch wiederspiegeln. Die Modifikation sollte die normale Arbeit mit der Datenbank so wenig wie möglich 

beeinflussen. Deshalb erfordert eine Modifikation oft auch die Betrachtung der gesamten Entwurfsgeschichte. 

Auswirkungen der Modifikation der Struktur können oft durch entsprechende Sichten verbessert werden. Eine 

andere Methode basiert auf der Einführung von Synonymen. Damit wird zwar auch die Performanz der Datenbank 

beeinflußt, nicht aber die Weiterverwendbarkeit. Dabei ist jedoch auf die Identifizierbarkeit über diese 

Sichten zu achten, um eine Modifikation von Daten über Sichten zu erlauben. 

Das RENAME und das ALTER Kommando von SQL sollte mit entsprechender Vorsicht angewandt werden. 

Werden z.B. Spalten angefügt, die keine Nullwerte oder Defaultwerte enthalten können, dann ist die exisiterende 

Relation zu modifizieren. Prozesse, die auf einem SELECT * basieren sind in diesem Fall ebenso 

zu modifizieren. Weiterhin sind auch entsprechende Performanzbetrachtungen und Speicherstrategien in die 

Modifikation einzubeziehen. 

Portierbarkeit, Änderungen der Plattform. 

Da DBMS bereits sehr komplexe Softwaresysteme sind und sich trotz der Standardisierung von SQL in ihrer Funktionalität 

stark unterscheiden können ist eine Weiterentwicklung von Systemen kaum vorauszusehen. Einige Schwachpunkte 

von existierenden Systemen werden in den nächsten Jahren behoben werden. 

Datenbanksysteme erfahren eine Erweiterung hin zur Integration objekt-relationaler Technologie. Damit werden 

komplexere Typensysteme direkt unterstützt. Mit einer Veränderung der Technologie ist oft eine Veränderung großer 

Teile der Implementation erforderlich. Deshalb sollten auch solche Informationen im Entwurf berücksichtigt werden, 

die z.Z. noch nicht implementiert werden können. Damit kann eine Verbesserung der Funktionalität von DBMS direkt 

aufgenommen werden. 

Typische Änderungen sind z.B.: 

• Die Integritätsbedingungen werden von Version zu Version immer besser unterstützt. 

IS ADD


• Die Optimierer werden mit umfangreicheren Möglichkeiten zur Berücksichtung von Erkenntnissen des konzeptionellen 

Entwurfs ausgerüstet sein. 

• Einschränkungen von Funktionen werden verschwinden. 

• Durch Verbesserung der Hardware und der Software wie verbesserte Ein- und Ausgabe wird auch die Funktionalität 

von DBMS erweitert werden können. 

• Die Datenwörterbücher können mehr semantische und funktionelle Information aufnehmen und verarbeiten. 

• Es werden verteilte Systeme, offene Systeme und föderierte Systeme geschaffen werden. 

Syntax: 

Pragmatik: 


Schritte 

1. Neue semantische Regeln 

Pragmatik: 

2. Neue Operationen 

Pragmatik: 

3. Höhere Performanz 

Pragmatik: 

HERM-Compiler 11. 

Diensteverwaltungssystem. 

HERM-Compiler 12. 

Erzeugung des Schemas in der Zielsprache. 

2.8.6 Besonderheiten der Abbildung auf UML-Strukturen bzw. XML-Strukturen 

Entfaltung durch Objekt-Schalen, ggf. mit kontrollierter Schalen-Redundanz 

Basis-Schale meist genutzt zur direkten Identifikation 

Objekt-Schale mit Objektentfaltung, optionalen Komponenten, Default-Ergänzungen 

Sharing-Modell zur gemeinsamen, redundanten Benutzung gemeinsamer Komponenten ggf. mit Vertragsmodell, 

Injektionsmodell, Modifikationsstrategie, Notifikationsdienst bei Veränderung 

IS ADD


Inductive and Abstraction Layered Typed Modelling Constructs. 

Typically, a model is defined in a certain language. A model language L for a model uses some signature S and 

a set of constructors C that allows to build a set of all possible expressions in this language. Typically constructors 

are defined by structural recursion [Tha00]. The set of constructors may allow to build expressions that do not fulfill 

certain quality or more generally integrity conditions. Therefore we introduce a set Σ S,C well-formedness conditions. 

Well-formedness conditions separate ‘normal’ expressions from ‘abnormal’ ones. The later can be separated into 

construction abnormality and semantic abnormality. We may allow such abnormalities that are corrigible to normal 

expressions. The avoidance of abnormality is still research in progress. Kinds of abnormality that should be handled 

within a theory of conceptual modelling are pleonasm (e.g., redundancy), semantic clashes (e.g., contradictions), 

Zeugma (e.g., overloading of constructs, combining separable semantic units into one concept), and improbability 

(e.g., almost empty classes). 

Well-formedness restrictions influence the modelling style [Kle07]. 

• The Strong Venetian style rigidly separates basic constructs and builds a fully compositional structuring. ER 

schemata and UML class diagrams are typically based on this style. 

• The Weak Venetian style separates constructs to same degree but not more than it is necessary. Performancetuned 

physical relational schemata are typically based on this style. 

• The Strong Russian Doll style is based on a full expansion of objects, i.e. objects in a database are potentially 

expandable through navigational sub-structures. 

• The Weak Russian Doll style uses a layered representation similar to tree languages. 

ER modelling is typically based on the Salami slice style whereas XML modelling typically uses the strong Russian 

doll (DTD style) or the weak Venetian or weak Russian doll (XML schema) style. The weak Venetian blind style is 

also the basis for component-based development of models since amalgams constructs as small models of coexisting 

and co-evolving facets of objects. 

2.8.7 Das regelbasierte Verfahren nach D.W. Embley und O. Sörensen 

2.9 Spezielle Modellierungsmethoden für Spezialanwendungen 

2.9.1 Besonderheiten verteilter Informationssysteme 

Syntax: 

Pragmatik: Da die Modellierung der Verteilung eine orthogonale Aufgabe ist, bedarf die Verflechtung der Modellierung 

von Verteilung und der anderen Modellierungsaufgaben einiger Tricks: 

• 

• 

Schwierigkeiten und Fallen : in der Modellierung bereiten insbesondere folgende Probleme: 

Schritte 

1. Die Replikation, die Partitionierung und die Allokation beruhen in diesem Entwurfsstadium meist auf 

Schätzungen. Damit sind auch die Resultate in diesem Schritt eher als Näherungen zu betrachten. 

Eine Optimalität kann auf diese Art und Weise kaum erreicht werden. 

2. Oft wird eine gleichmäßige Auslastung der Rechnerknoten angestrebt. Damit können zwar lokale 

Engpässe gut umgangen werden. Aber auch dieser Parameter beruht auf Schätzungen. 

IS ADD


1. Analyse der Anforderungen 

Es werden Qualitätsparameter wie Datenumfang, Rechtzeitigkeit, einfacher Zugriff, Datenort, Datenzuverlässigkeit, 

Erreichbarkeit der Daten, bevorzugte Lokalisierung und einfache Pflege der Integrität der Daten analysiert. 

Auf der Grundlage dieser Daten kann entschieden werden über die folgenden technischen Strategien: 

Qualitätsparameter 

Datenumfang 

Rechtzeitigkeit 

einfacher Zugriff 

Datenort 

Datenzuverlässigkeit 

Erreichbarkeit 

Pflege der Daten 

Information für Entwurfsschritt 

Auswahl der Technologie 

Replikationsstrategien 

Strukturen 

Eigentümer-/Besitzer-/Nutzerstrategien 

Eigentümer-/Besitzer-/Nutzerstrategien 

Datenermittlung 

Backup-/Wiederanlaufprozesse 

Unterstützungstrategien 

Pflegestrategien 

Eigentümer-/Nutzerstrategien 

Pragmatik: 

Die verschiedenen Qualitätsparameter können benutzt werden, um Entwurfsentscheidungen eventuell einer Revision 

zu unterziehen. Meist begrenzen diese Parameter jedoch die Wahl der Plattform. 

Eine pragmatische und zugleich praktikable Methode zur Beherrschung der Verteilung ist eine Trennung von 

Benutzern und Besitzern von Daten. Damit kann Benutzern ein read-only-Zugriff auf einfache Art ermöglicht 

werden. Sind mehrere Benutzer Besitzer von Daten und können sie die Daten simultan ändern, dann ist diese 

Möglichkeit explizit vorzusehen. Im weiteren ordnen wir den Daten die Besitzer und die Benutzer zu. 

Ist der Umfang der Daten zu hoch und werden keine Forderungen nach einer zentralen Verarbeitung erhoben, 

dann kann aus der Größe der Datenbank bereits eine minimale Serverkonfiguration abgeleitet werden. 

Die Aktualität der Daten beeinflußt direkt die Replikationsfunktionen. Wird eine hohe Aktualität gefordert, dann 

kann nur mit einer komplexen Updatefunktion die Aktualität gesichert werden. 

Für viele Anwendungen ist ein einfacher und schneller Zugriff für einen Teil der Daten benutzerabhängig unbedingt 

erforderlich. Deshalb sind die kritischen Anwendungen direkt zu erfassen. Ein Zugriff wird insbesondere 

auch durch Namenskonventionen für die Sichten erleichtert. Tuningstrategien sollten sich auf die Anwendungen 

der einzelnen Knoten beschränken und weniger auf das allgemeine konzeptionelle Schema der gesamten 

Anwendung über alle Knoten hinweg. Müssen allen Benutzern alle Daten zur Verfügung stehen, dann wird 

dadurch die Sharingstrategie und die Replikationsstrategie beeinflußt. 

Da die gleichen Zugriffe nicht an verschiedenen Standorten zur gleichen Zeit parallel ausgeführt werden sollen, 

werden durch die erwartete Funktionalität der Knoten auch die Datenermittlung, die Anfrageverarbeitung 

und die Modifikationsprozeduren beeinflußt. Je mehr Funktionen an allen Standorten zur gleichen Zeit benötigt 

werden, umso sorgfältiger muß die Verteilung entworfen werden. 

Um einen Wiederanlauf und eine Backup-Funktionalität zu unterstützen, werden diese Funktionen beim Entwurf 

der Knoten mit berücksichtigt. Treten Zuverlässigkeitskonflikte auf, dann sind sowohl der Besitzer als 

auch die Benutzer zu informieren. 

Die Verfügbarkeit von Daten auf verschiedenen Knoten kann durch häufige Anforderungen von anderen Knoten 

mit beeinflußt werden. Deshalb kann auch eine Veränderung der Netzarchitektur notwendig werden. 

Die Integrität von Daten ist einfacher zu pflegen, wenn nur ein Knoten über Modifikationsrechte verfügt. Um 

die Integrität zu pflegen, können Trigger, stored procedures und die referentielle Integrität auf logischem Niveau 

entworfen werden. Dabei ist jedoch zu sichern, daß keine Zyklen auftreten können. Diese Information liegt bereits 

für das konzeptionelle Schema vor. Eine Betrachtung des logischen Schemas ist deshalb nicht notwendig. 

Die vorliegende Information ist deshalb zu nutzen, um einen einfachen Mechanismus zur Pflege der Integrität 

abzuleiten. Um unnötige Modifikationen zu vermeiden, sobald Daten nicht mehr auf einem Knoten benötigt 

werden, ist eine explizite Operation zum Entfernen aller Daten sinnvoll. 

IS ADD


2. Analyse der Architektur des Netzes 

In diesem Schritt werden die Funktionen der einzelnen Knoten analysiert. Dazu werden die einzelnen Dialogobjekte, 

Sichten und Funktionen der Knoten auf ihre Realisierbarkeit untersucht. In Abhängigkeit von diesen 

Funktionen ist das Schema zu optimieren. Bei der Optimierung werden sowohl die Anforderungen der Benutzer 

für die jeweiligen Knoten analysiert, als auch die Möglichkeiten zur Bereitstellung von aktuellen Informationen 

für die jeweiligen Knoten. 

Jedem Benutzer werden seine Knoten zugeordnet. Dabei werden sowohl die funktionalen Anforderungen als 

auch die Anforderungen an die Sichten berücksichtigt. 

In diesem Schritt wird auch eine allgemeine Replikationsstrategie entwickelt. Falls eine Pflege der Replikate 

durch ein paralleles Verschicken aller Modifikationstransaktionen erfolgt, dann wird jede Modifikation nachgezogen. 

Es kann auch ein Schnappschuß der modifizierten Daten an die Replikate versandt werden, deren Daten 

in den Knoten modifiziert werden. Ist eine Charakterisierung der durch das Replikat benötigten Daten möglich, 

dann kann die versandte Menge weiter eingeschränkt werden. Kann man für Klassen deduktive Normalformen 

einführen, dann kann die Menge der versandten Objekte weiter eingeschränkt werden. 

Für die einzelnen Knoten sind entsprechende load, unload und send Funktionen zu entwickeln. 

In analoger Form ist eine cancel Funktion zu entwickeln. 

Pragmatik: 

Bei der Analyse der Anforderungen in den einzelnen Knoten kann nach folgendem Schema für jede einzelne 

Klasse vorgegangen werden: 

(a) Es wird die Granularität für das Datensharing analysiert. Dabei werden auch die beizubehaltenden Daten 

(ankernde Daten) und die Beziehungen der Daten (Identifikationsbeziehungen etc.) analysiert. 

(b) Es wird das Verhalten der Benutzergruppe modelliert, die für die Modifikation und die Bereitstellung 

der Daten verantwortlich ist. Dabei werden die entsprechenden Prozesse bzw. Funktionen dieser Benutzergruppe 

zugeordnet. Falls eine bereits normalisierte Klasse unterschiedlichen Benutzern aus dieser 

Gruppe zugeordnet wird, dann ist das gemeinsame Benutzen der Daten zu spezifizieren. Gegebenenfalls 

ist eine horizontale Dekomposition die Lösung. Die Benutzergruppe ist den einzelnen Knoten zuzuordnen. 

Falls verschiedene Benutzer unterschiedliche Daten einbringen, dann kann ebenfalls durch horizontale 

Dekomposition eine einfachere Pflege möglich sein. 

(c) Es wird das Verhalten der Benutzergruppe analysiert, die die Daten im Wesentlichen für Anfragen benutzt. 

Dazu werden deren Prozesse, Funktionen, Sichten und Dialogobjekte betrachtet sowie die Knotenzuordnung. 

Außerdem wird für jede Klasse analysiert, inwieweit ein Benutzer die gesamte Klasse benötigt. 

3. Entwicklung einer Architektur (Partitionierung , Replikation der Daten) 

Auf der Grundlage der nun bekannten Information können nun die Operationen für die Entwicklung einer 

Verteilung herangezogen werden. Für jede Operation wird die Knotenmenge berechnet, die für diese Operation 

herangezogen werden muß. Es werden die horizontalen, vertikalen und gemischten Partitionierungen für die 

verschiedenen Anwendungen betrachtet. 

Vertikale vs. horizontale vs. gemischte 

Partitionierung 

Pragmatik: 

Sowohl für die horizontale, als die vertikale oder gemischte Partitionierung können verschiedene Operationen 

herangezogen werden. Zu jeder Operation werden die benötigten Klassen und deren Verbindungen (z. B. 

über Relationshiptypen) explizit dargestellt. Darauf aufbauend kann für eine Klasse die Teilmenge bestimmt 

IS ADD


werden, die für eine statistisch homogene Auslastung der Teilmengen innerhalb der betrachteten Operationen 

und für die Existenz unterschiedlicher Anwendungen für mindestens zwei verschiedene Partitionen sorgen. Eine 

Klasse wird so in Teilmengen zerlegt, daß jede von ihnen ausreichend für eine entsprechende Operation 

ist. Damit ist eine horizontale Partitionierung ableitbar. Oft ist dies nur bei Anwendung der 80/20%-Regel 

möglich. Um eine feinere Granularität zu erreichen, können auch die Klassen- bzw. Teilmengengröße, die Zugriffshäufigkeit 

und die mittlere Trefferrate mit einbezogen werden. Damit kann auch eine Betrachtung der 

Relevanz einer Klasse für einen Knoten erfolgen. Die Relevanz ist definiert über die Proportion der Trefferquote 

zur ‘Nicht’trefferquote. 

Analog kann für den Fall der abgeleiteten horizontalen Partitionierung vorgegangen werden. Da der Equi- 

Verbund für eine Darstellung von Hierarchien günstig ist, kann in diesem Falle auch eine Hierarchie unterstützt 

werden. 

Sind mehrere horizontale Partitionierungen gleich günstig, dann wird man die Partitionierung mit den wenigstens 

Verbunden bzw. die für eine größere Anzahl von Anwendungen benötigte wählen. Der Verbundgraph kann 

in diesem Fall herangezogen werden. 

Die vertikalen Partitionierung erfordert eine genaue Betrachtung der Integritätsbedingungen. Die Vielfalt ist 

wesentlich höher. Durch Gruppierung und Splittung kann die kombinatorische Vielfalt etwas eingedämmt werden. 

Für eine vertikale Dekomposition wird die Affinität der Komponenten betrachtet. Für Komponenten, die 

nicht zur (primären) Identifikation benötigt werden, wird eine Bewertung der diese Komponenten verwendenden 

Operationen vorgenommen (Benutzungswert). Analog wird berechnet, inwieweit für Paare von Komponenten 

entsprechende Operationen existieren (Affinität). Darauf aufbauend kann eine Affinitätsmatrix entwickelt 

werden. Diese Matrix wird auf separierbare Teile untersucht. Kann eine Gruppierung in der Matrix vorgenommen 

werden, dann kann auch das Schema in dieser Form gruppiert werden. Gruppierungen können nach 

verschiedenen Algorithmen (bond-Algorithmus; Algorithmen, die die Masse von Komponenten einbeziehen) 

abgeleitet werden. Auf dieser Grundlage wird ein allgemeines Affinitätsmaß entwickelt. Mit jeder Modifikation 

der Datenbank ist dann ein entsprechender Netzbeitrag zur Komplexität abschätzbar. Auf dieser Grundlage 

werden Typen separiert. 

Analog kann im Falle der vermischten Partitionierung vorgegangen werden. 

Die abgeleiteten Partitionierung werden auf ihre Korrektheit geprüft (Vollständigkeit, Rekonstruierbarkeit, Disjunktheit). 

4. Allokation der Daten und Prozesse 

Für eine Menge von Partitionen F = {F 1 , ..., F n }, ein Netz mit den Knoten S = {S 1 , ..., S m } und eine Menge 

von Anwendungen Q = {q 1 , ..., q q } wird nun eine optimale Verteilung von F auf S gesucht. 

Die optimale Verteilung wird bestimmt durch 

(a) die minimalen Kosten und 

(b) die Performanz. 

Dabei werden die Kosten bestimmt aus 

Speicherkosten für das Speichern von F i auf S j , 

Anfragekosten für das Berechnen einer Anfrage über F i auf S j , 

Modifikationskosten für die Modifikation von F i auf allen Knoten und 

Kommunikationskosten. 

Es gibt bislang kein allgemeines Kostenmodell. Ein einfaches Modell kann wie folgt entwickelt werden für 

eine Partition Q 1 und Q 2 von Q nach retrieval-only-Anfragen und Modifikationsanfragen: 

Für ein Partition F k betrachten wir die folgenden Kosten 

retrieval-only-Verkehr für die Knoten T k = {t 1 , ..., t m } , 

IS ADD


update-Verkehr für die Knoten U k = {u 1 , ..., u m }, 

Kommunikationsosten für retrieval C(T k ) = {c 12 , c 13 , ..., c 1m , ..., c m−1,m } 

Kommunikationsosten für update C ′ (U k ) = {c ′ 12 , c′ 13 , ..., c′ 1m , ..., c′ m−1,m } 

Speicherkosten für die Partition D = {d 1 , ..., d m } 

unter der Voraussetzung, daß keine weiteren Kapazitätsbeschränkungen gelten. 

Dann kann für die Booleschen Plazierungsvariablen x j mit 

{ 1 falls Fk in S 

x j = 

j 

0 falls F k nicht in S j 

optimiert werden nach der folgenden Formel für Teilmengen I von S, in denen F k gespeichert wird: 

⎡ ⎛ 

⎞ 

⎤ 

m∑ 

min ⎣ ⎝ ∑ 

x j u j c ′ ij + t j min ⎠ + ∑ 

x j d j 

⎦ . 

i=1 

j|S j ∈I 

j|S j ∈I c ij 

j|S j ∈I 

Diese Optimierung ist trotz der starken Vereinfachung NP-vollständig. Sie stellt nur ein Näherung dar, weil 

Partitionen stärker strukturiert sind, der Zugriff zu einfach dargestellt wird, die Kosten für die Erzwingung der 

Integrität nicht erfaßt wurden und die Kosten für parallele Zugriffe nicht berücksichtigt sind. Deshalb wählen 

wir im weiteren ein Modell, das auf folgenden Informationen zur Anwendung und zur Modellierung beruht: 

Datenbankinformationen: Selektivität sel i (F j ) einer Partition F j für eine einzelne Anfrage q i und 

die approximative Größe der Partition size(F j ) ; 

Anwendungsinformation: Anzahl der Lesezugriffe RR ij für Anfragen q i über einer Partition F j 

Anzahl der Updatezugriffe UR ij für Anfragen q i über einem Partition F j 

{ 1 falls Anfrage qi modifiziert F 

u ij = 

k 

0 falls Anfrage q i modifiziert F k nicht 

R ij = 

{ 1 falls Anfrage qi liest F k 

0 falls Anfrage q i liest F k nicht 

O = {o 1 , ..., o q } 

für jede Anfrage eine maximal tolerierbare Antwortszeit 

o i Ausgangspunkt von q i 

Knoteninformation: Speicher- USC k und Berechnungskapazität LP C k 

Netzinformationen: Kommunikationskosten g ij pro Kommunikationseinheit 

Kanalkapazität, Abstände zwischen den Knoten, Protokolloverhead usw. 

Auf dieser Grundlage kann ein allgemeines Kostenmodell unter Berücksichtigung der Beschränkungen für die 

Antwortzeit, die Speicherzeit und die Berechnungszeiten erstellt werden. 

Pragmatik: 

Das allgemeine Kostenmodell kann oft zu komplex sein. Deshalb kann man für den Grobentwurf der Verteilung 

auch auf die folgende Art vorgehen. 

• Es wird für die Daten nach einer ‘Server/Client’-Verteilung der Daten - wie bereits oben mit dem Besitzer/Benutzer- 

Modell eingeführt - anhand der Lokalisierung der Besitzer und Benutzer eine optimale Topologie ermittelt, 

die untersucht, welche der folgenden Varianten günstiger ist: 

• Zentralisierung der Daten, 

• Verteilung der Daten nach Besitzern, 

• Verteilung der Daten nach Benutzern, 

• Verteilung der Daten nach Besitzern und Benutzern, 

IS ADD


• Abwägen der Vor- und Nachteile eines zentralen Managements. 

• Es werden technische Strategien abgeleitet, mit deren Hilfe den Anforderungen der Anwendung in hinreichend 

kurzer Zeit genügt werden kann und die die entwickelte Partitionierung und Replikation hinreichend 

gut unterstützen. 

• Darauf aufbauend wird ein Pflichtenheft für den Netzentwickler abgeleitet. 

Bewertung der Resultate. 

Mit dieser einfachen Methodik kann die Verteilung einer Datenbank für diese Phase des konzeptionellen 

Entwurfes hinreichend genau spezifiziert werden. Genauere Anpassungen müssen vorgenommen werden, sobald die 

Plattformen hinreichend genau bekannt sind. Dazu können entsprechende Werkzeuge benutzt werden. 

2.9.2 Modellierung von Datenbank-Farmen 

Datenbank- und Informationssysteme sind meist in einer integrierten Form verfügbar. In unserer Universitätsanwendung 

kann z.B. neben dem Informationssystem zur Stundenplanung auch ein Informationssystem zur Verwaltung von 

Studentendaten geführt werden. Ein Bestandteil eines solchen Informationssystemes ist z.B. die Erfassung zu Daten 

zu erworbenen Scheinen und zur erfolgreichen Teilnahme an Lehrveranstaltungen. Deshalb wird eine Archivierungssicht 

auf das Informationssystem zu den Lehrverantaltungen benutzt, um diese Daten in die Studenten-Datenbank 

einzupflegen. Diese Archivsicht ist in Bild ?? dargestellt. 

Eine Datenbank-Farm verwendet die Architektur in Bild 66. 

Play-In- 

System 

Play-Out- 

System 

Datenbank- 

Warenhaus- 

System 

Speicher- 

Maschine 

Abbildung 66: Die Architektur von Systemen von Datenbank-Farmen als verallgemeinertes Datenbank-Warenhaus 

2.9.3 Besonderheiten bei der Modellierung von inkrementellen Datenbanksystemen 

Bereits für die Entwicklung der Funktionalität haben wir die induktive Definition von Relationship-Typen genutzt. 

Für Relationship-Typen sind über eine versteckte Annahme für das Verändern und Einfügen von Komponenten Modifikationsoperationen 

nur in eingeschränkter Form definiert. Analoge Annahmen können wir in der Sichtenkooperation 

von Datenbank-Farmen machen. Es wird ein System oder eine Sicht entweder Zentral-System, in dem alle Operationen 

uneingeschränkt definiert sind, oder abhängiges System, das einen Teil seiner Daten aus einem anderen 

System bezieht und deshalb diese Daten nur in Zusammenarbeit mit dem anderen System ändern kann. 

Incremental evolution is thus supported by star and snowflake sub-schemata by: 

Injection forms enable to inject data into another database. The forms are supported by views and view cooperation 

approaches. Data injected into another database cannot be changed by the importing database system. The 

IS ADD


auxiliary 

database 

auxiliary 

database 

auxiliary 

database 

auxiliary 

database 

❄ injected 

DBS 

(S p , Σ S p, O p , Σ O p) 

❄ injected 

DBS 

(S c , Σ S c, O c , Σ O c) 

❄ injected 

DBS 

(S r , Σ S r , O r , Σ O r ) 

❄ injected 

DBS 

(S m , Σ S m, O m , Σ O m) 

insert 

inject 

modifiable 

injected 

✲ 

✲ 

insert 

inject 

modifiable 

injected 

✲ 

✲ 

insert 

inject 

modifiable 

✲ 

✲ 

injected 

planning 

phase DBS 

construction 

phase DBS 

realization 

phase DBS 

maintenance 

phase DBS 

Abbildung 67: The General Architecture of Incremental Evolution of Database Systems 

structuring (S inject , Σ S ) of the views of the exporting database system is entirely embedded into the structuring 

(S ′ , Σ S ′) of the importing database system. The functionality (O inject , Σ O ) of the views of the exporting 

database system is partially embedded into the functionality (O ′ , Σ O ′) of the importing database system by 

removing all modification operations on the injected data. These data can only be used for retrieval purposes. 

Insertion forms enable in insertion data from the exporting database into the importing database. These data can 

be modified. The structuring (S insert , Σ S ) and the functionality (O insert , Σ O ) of the views of the exporting 

database system are entirely embedded into the structuring (S ′ , Σ S ′) and the functionality (O ′ , Σ O ′) of the 

importing database system. 

2.9.4 Besonderheiten der Entwicklung von Datenbank-Warenhäusern 

Units generator 

Unit, applet, 

data provider 

Purger 

Storage 

Workspace 

Gate 


Payment 

manager 

Active acquisition 

Data suites 

Access, history 

manager 

OLTP 

data 

Foreign 

Data 

Legacy 

Data 

✲ 

Micro-data 

✲ import 

export 

✲ tools 

✲ 

Content 

management 

system 

OLAP/DW System 

✲ 

Macro-data 

extractors 

database 

mining 

✲Anonymous 

user 

✲ 

✲ 

Business 

unit user 

EIS/DSS 

user 

Abbildung 68: Data Warehouse Architecture of the DaMiT System 

Typisches Beispiel: Document systems should be supported by a specific data warehouse architecture: 

IS ADD


Play-out servers present, store and protect released content. The play-out of documents depends on their usage. 

Typical widely used documents are documents used in logistics: 

• Bills have their own numbering and their own format. They serve also as an contract of carriage between 

shipper and carrier. 

• Certificate on the content and the origin of the contents are used for statistical research, and for accessing 

duties, particularly under trade agreements. 

• Invoices declare against which payment is made. They are used for clearing documents. 

• Dock receipts are issued by the forwarder on experter’s behalf. They include shipment description, physical 

details, and shipping information. 

• Bills of lading are used as contracts between carrier and shipper, spell out legal responsibilities and liability 

limits for all parties to the shipment. 

• Packing lists provide details on the packing procedure of the container. 

• Sight, time drafts instruct the buyer’s bank to collect payment. 

Production servers have controlled access to documents and host dockets. 

Specific docket servers manage trusted content exchange between the servers. 

Generic docket servers communicate and encapsulate value-adding services. 

Für die drei Komponenten ergibt sich bei der Entwicklung das folgende Aufgabenspektrum: 

Akquisition Speicher Zugriff 

Lösungsentwicklung 

Datenidentifikation 

Daten-Sourcing 

Daten-Sourcing 

Validierung der Integration 

Validierung der Integrität 

Synchronisation 

Synchronisation 

Entwicklung f. Rückkoppl. 

Speicherarchitektur Speicherarchitektur 

Transform.-abbildungen Transform.-abbildungen Transform.-abbildungen 

Qualitätsprüf. Qualitätsprüfung Qualitätsprüfung 

DB-Modellierung 

DB-Entwurf 

Dabei können wir anhand der bislang betrachteten Entwurfsmethode folgende Regeln beim Entwurf betrachten: 

1. Akquisition, Speicherung und Zugriff bilden eine Einheit. 

2. Aufgrund der Komplexität ist die Dekomposition von Geschäftsprozessen notwendig. 

3. Die Anwendungen sollten voneinander separiert werden. 

4. Autonome Anwendungen können auch parallel entwickelt werden. 

Damit kann auch das Aufgabenspektrum während der einzelnen Entwicklungsschritte für die unterschiedlichen Gruppen, 

die im Entwicklungsprozeß teilnehmen, abgeleitet werden: 

IS ADD


Schritt Exporteure Benutzer Programmierer 

1. Lösungsentwicklung - stark mittel 

2. Datenidentifikation - mittel stark 

3. Daten-Sourcing stark leicht mittel 

4. Validierung der Integrität leicht mittel stark 

5. Synchronisation leicht - stark 

6. Entwicklung f. Rückkopplung stark - stark 

7. Speicherarchitektur - - stark 

8. Transformationsabbildungen - - stark 

9. Qualitätsprüfung leicht leicht stark 

10. DB-Modellierung - leicht stark 

11. DB-Entwurf - - stark 

In analoger Form können die Komponenten, auf die sich die Entwicklungsschritte konzentrieren, herausgestellt werden: 

Schritt Akquisition Speicher Zugriff 

1. Lösungsentwicklung - - stark 

2. Datenidentifikation - - stark 

3. Daten-Sourcing stark - leicht 

4. Validierung der Integrität stark - leicht 

5. Synchronisation stark leicht - 

6. Entwicklung f. Rückkopplung stark - - 

7. Speicherarchitektur - stark mittel 

8. Transformationsabbildungen stark stark stark 

9. Qualitätsprüfung stark stark stark 

10. DB-Modellierung - stark - 

11. DB-Entwurf - stark - 

Mit diesen Aufgaben ergeben sich im Einzelnen für die Schritte die folgenden Aufgaben: 

1. Lösungsentwicklung: Es wird eine software-technologische Analyse durchgeführt, die zu einer Spezifikation 

der Anforderungen im Rahmen eines Pflichtenhefts führt und die klärt, inwieweit durch eine Warenhausanwendung 

die derzeitige Situation verbessert wird. 

2. Datenidentifikation: Es werden die benötigten Daten und darauf aufbauend die benötigten Datenbestände identifiziert. 

3. Daten-Sourcing: Es werden die Charakteristika der benötigten Datenbestände erfaßt und mit den Anforderungen 

verglichen. 

4. Validierung der Integrität: Es wird die Semantik der ausgewählten Datenbestände erfaßt (Identifikation, Population 

(Formate, Vollständigkeit, ...), Verletzungen, Pflegeroutinen, etc.). 

5. Synchronisation: Die Datenbestände müssen für das Warenhaus im Rahmen einer Synchronisationsphase vereinheitlicht 

oder integriert werden oder zumindest in ihren Beziehungen beschrieben werden. Es werden referentielle 

Integrität (Benutzungsabhängigkeiten, Standardisierung der Population, Standardisierung der Beziehungen 

der Datenbanken untereinander) erfaßt, Zeitbeschränkungen (Zeit der Gewinnung der Daten, letzte 

schreibende Transaktionen auf den Daten, Erfrischungen der Daten), Zugänge zur Korrektur der Verletzungen 

der Integrität und Routinen, die zur Benutzung der Datenbestände erforderlich sind. Außerdem werden die 

Identifikation auf Redundanz geprüft, entsprechende Hierarchien entwickelt, etc. 

6. Entwicklung f. Rückkopplung: Für die Entwicklung von Durchgriffsmöglichkeiten stehen eine Reihe von Mechanismen 

aus der Technologie reaktiver Systeme zur Verfügung. 

IS ADD


7. Speicherarchitektur: Es existieren eine Reihe von unterschiedlichen Herangehensweisen für die Speicherarchitektur 

wie: 

• Tabellen der relationalen Technologie, 

• Verweistabellen auf die Quellensysteme, 

• kodierte Tabellen, 

• assoziative Verbundtabellen (bridge/cross-reference table), 

• gemischte Tabellen, 

• Teilmengen-Tabellen, 

• aggregierte Tabellen (summarization roll-up tables) und 

• historische Tabellen. 

Dabei muß für eine effiziente Hauptspeicherverwaltung eine Lösung wie im Falle großer Datenbanken gefunden 

werden. 

8. Transformationsabbildungen: Nun kann die eigentliche Integrationsaufgabe in Angriff genommen werden. Die 

Datenstrukturen werden analysiert und die Transformationsabbildungen werden entwickelt. 

• Wie im Datenbankentwurf werden zuerst die Identifikationsprobleme gelöst. 

• Es wird ein Abhängigkeitsgraph der Sourcedaten und ihrer Funktionen erstellt. 

• Es wird eine Liste der Transformations- und Reinigungsschritte erstellt. 

• Darauf aufbauend werden die Transformationsprogramme entwickelt, die auch eine Reinigung der Daten, 

ein Mischen der Daten, ein Restrukturieren der Daten je nach Bedarf mit einschließen. 

• Es wird schrittweise ein Datenwörterbuch erstellt, das auch Synonyme, Homonyme und Namenskonzepte 

mit erfaßt. Darauf aufbauend wird ein Speicherplan erstellt. 

• Für die Transformationen wird ein Diagramm erstellt. 

9. Qualitätsprüfung: Dazu sind eine Reihe von Daten zu erfassen. 

• Benutzungsschätzungen: Es werden Schätzungen 

für die Anzahl der Benutzer, 

für die Häufigkeit und Art ihrer Zugriffe, 

für den Arbeitsraum, den die Benutzer benötigen, 

für die Plattformen der Benutzer und 

für die Performanzanforderungen entwickelt. 

• Umfang der Daten: Umfangreiche Datenbanken sind ein Gewinn für das Warenhaus, können aber aufgrund 

ihrer Performanzanforderungen die Rechenpotenzen von Superrechnern erfordern. Es kann notwendig 

werden, leistungstarke symmetrische Multiprozessorsysteme (SMP) oder massiv-parallele Systeme 

(MPP) einzusetzen. Sowohl zur Aufbereitung der Sourcedaten als auch zur Bearbeitung von Anforderungen 

kann bereits eine solche Datenmenge anfallen, die SMP oder MPP benötigt. 

• Zugriffsraten und Prozeßabschätzungen: Darauf basierend werden die Prozeßanforderungen abgeleitet. 

Auf der Grundlage dieser Daten kann analog zu Methoden des Benchmarkings eine Bewertung der Qualität 

erfolgen. 

Abschließend sollte ein Vergleich mit den Möglichkeiten anderer Systemlösungen erfolgen. 

10. DB-Modellierung: Der Datenbank-Modellierungsprozeß entspricht dem Vorgehen für ‘normale’ Datenbanken. 

• Es werden alle Datenstrukturen der Sourcedaten und der Warenhausdaten erfaßt. 

IS ADD


• Es werden die Prozesse zur Transformation und die Prozesse für die Auswertung der Daten erfaßt. 

• Es werden die Drehbücher für die Benutzung erstellt. 

• Es werden die Sichten der Benutzer und die Prozesse mit den Dialogen abgeglichen. 

Damit entsteht ein komplexes Vorschema der Daten, Prozesse, Handlungen und Sichten auf das Warenhaus. 

11. DB-Entwurf: Nunmehr kann auch der konzeptionelle, logische und physische Entwurf angeschlossen werden. 

Das Datenbank-Warenhaus verwendet auch die Lösung eines alten Integrationsproblemes: Anstatt für eine Anwendung 

( n 

2) 

verschiedene Schnittstellen zwischen den Anwendungen zu entwickeln, wird eine lose Integration - in unserem Fall 

eine Reduktion und anschließende Integration - vorgenommen. 

2.10 Modellierung von Sicherheitsmechanismen 

2.10.1 Design-By-Units und lokale komponentenbasierte Sicherung 

Im Design-by-units-Zugang unterscheiden wir zwischen dem Retrieval und Manipulationsanforderungen. 

die folgende Skizze schematisiert den Zugang. 

Informationseinheiten 

Container 

Manipulationsanforderungen 

Im erweiterten ER-Modell können spezifische Sicherheitsarchitekturen ebenso spezifiziert werden: 

Autorisierte Operation ( 

< Akteur > 

< Sicht > 

< zugelassene Operationen > 

< Korrektheitsbedingung > ) 

Diese Form ist relativ einfach als Sicherheitkonzept sowohl durch Sichten als auch durch Funktionalität unterstützbar. 

2.10.2 Sicherheitsarchitekturen 

Sichten zur Unterstützung von Sicherheit. 

Im allgemeinen wird oft eine dreistufige Architektur bevorzugt: 

Basisrelationen 

Sicherheitssichten Sicherheitssichten für Retrieval 

Sicherheitssichten für Manipulationsanforderungen 

Arbeitsssichten Arbeitssichten für das Retrieval 

Arbbeitssichtensichten für Manipulationsanforderungen 

Benutzergruppen-orientierte Sichten sind die direkten Arbeitssichten der Benutzer. 

Retrieval-Sichten 

Sichten für Manipulationsanforderungen 

IS ADD


Nutzung der Daten-Warenhaus-Architektur als Sicherheitskonzept. 

LEHRBRIEF 

Modellierung und Konzipierung von Sicherheitskonzepten. 

Syntax: 

Pragmatik: 


Schritte 

1. Abschottung durch Sichten 

Mit diesem Hintergrund können wir folgende Schritte entwerfen: 

Zugriff erfolgt nur über die Sichten: Die gesamte Dialogstruktur sollte nur auf Sichten aufsetzen. Ein direkter 

Zugriff auf die Datenstrukturen sollte vermieden werden. Deshalb werden die Sichten direkt mit den 

einzelnen Dialogschritten gekoppelt. 

Da Sichten auch zur Herstellung der Unabhängigkeit von Daten dienen, sollte die gesamte Oberfläche auf 

Sichten abgestellt werden. Damit werden die folgenden Ziele verwirklicht: 

Vereinfachter Zugriff für den Endbenutzer. Durch Sichten können auch komplexere Manipulations- bzw. 

Zugriffsoperationen modularisiert dargestellt werden. Damit wird für den Endbenutzer die Arbeit mit 

der Datenbank erleichtert. 

Verbesserung der Produktivität für den Benutzer und den Programmierer. Durch die Einführung von 

Sichten werden auch von verschiedenen Dialogen benötigte Proozesse im Rahmen einer Lokalisierungsabstraktion 

miteinander wiederbenutzbar verwoben. 

Benutzung von Synonymen für Typen und abgeleitete Daten. Synonyme können die Transparenz der 

unterlegten Datenbankstrukturen und die Anwendungsbezogenheit von Namen verbessern. 

Zugriffs- und Authorisierungsbeschränkungen. Der Zugriff und die Authorisierung wird an die spezifische 

Sicht angepaßt und erlaubt wie bei abstrakten Datentypen nur den Zugriff auf diese Sichten, 

nicht aber auf die anderen Sichten. 

Integration bzw. Kombination über zentrale Sichten: Durch zentrale Sichten kann die Behandlung der unterschiedlichen 

Aspekte der Anwendung, deren Behandlung die Sichten dienen, vereinheitlicht und mit 

einem einfacheren Prozeßmanagement versehen werden. Damit entsteht eine Abbildungsstruktur zwischen 

verschiedenen Sichten wie im Bild 87. 

Da die zentralen Sichten auch an das integrierte Schema angepaßt werden können, haben diese Sichten 

keine update-Beschränkungen. Sie sind damit für die Programmierung einfacher zu handhaben. 

Zugriffssichten für den read-only-Zugriff: Sichten können eine komplexe Syntax, die eine Vielzahl von 

Fällen wiederspiegeln muß, vermeiden. Solche Sichten können auch benutzt werden, um den Zugriff 

einzuschränken. 

Integritätspflege über zentrale Sichten: Statt die Integritätspflge nur über das zentrale Schema zu definieren, 

können die zentralen Sichten aufgrund der Nichtbeschänkung des Zugriffs und der update-Operationen 

eher für die Pflegeoperationen benutzt werden. 

IS ADD


Beantragungssicht 

Genehmigungssicht1 


Abrechnungssicht 


Verbuchungssicht1 


... 

Verrechnungssicht1 


❘ ❄ ✠ 

Zentrale 


❘ ❄ ✠ 

Zentrale 

Verbuchungssicht 

3 ❯ 

❄ 

Integriertes Datenbankschema zum Dienstreiseantrag 

❘ ❄ ✠ 

Zentrale 

Verrechnungssicht 

✙ 

Abbildung 69: Sichtenintegration in unserer Anwendung 

Einbettung der Sichten in die Dokumentation: Zur Sichtendefinition gehört neben der Strukturdefinition, 

der Verbindung zu den Dialogen und der Definition der Beziehung zu Prozessen auch eine Information 

über den Entwerfer bzw. Besitzer, Synonymen, zum Status (wie z.B. Test, Version, Kopie), zur Verbindung 

mit den zentralen Sichten, zur Pflege und Monitoring. 

Definition von Sicherungsmechanismen über zentrale Sichten: Sichten sind günstig, um den Zugriff zu 

beschränken, aber sie sind nicht ausreichend, um die Datensicherheit zu gewährleisten. Meist kann man 

die Sicherheit auch durch die zentralen Sichten pflegen. Oft ist dies aber nicht ausreichend. Deshalb kann 

man den zentralen Sichten auch Sicherheitssichten zur Gewährleistung der Sicherheit beiordnen. Damit 

ergibt sich eine Hierarchie in den Sichten wie in Bild 88. 

Benutzersichten 

zur Vereinfachung 

des Zugriffs 




... 

Sicherheitssichten 

zur Kontrolle 

des Zugriffs 

❄ ❄ ❄ 

Zugriffsbeschrbeschr. 

Zu- 

Zugriffsgriffsbeschr. 

Geneh- 


Genehmigungssichtmigungssicht2 

... 

Zentrale 

Sichten 

zur Darstellung 

der Unabhängigkeit 

❘ ❄ ✠ 

Zentrale 


... 

Integriertes 

Schema 


der Speicherung 

3 


Abbildung 70: Ausschnitt aus der Sichtenarchitektur mit Sicherheitssichten 

Damit sind die Sichten der Blätter nach wie vor sichtbar für jedermann. Zugleich wird damit aber der 

weitere unbefugte Einblick verwehrt. 

Damit kann für die Sicherheitssichten die Anbindung an die Aktoren und deren rollen erfolgen. Nach 

außen ist aber durch ein 

GRANT ALL ON benutzersichten TO PUBLIC 

die Sicht einheitlich frei. 

Definition einer Authorisierungstabelle zur Kontrolle des Zugriffs: Die Authorisierungstabelle stellt den 

IS ADD


Zusammenhang zwischen den Sichten, einzelnen Dialogschritten und den Aktoren her. Aktoren können 

ihre Rechte bedingt oder bedingungslos weitergeben. 

Bevorzugung der Standardprozeduren zur Integritätspflege: Die durch ein DBMS vorgegebenen update- 

Kommandos schließen eine Pflege der Integrität nicht ein. Deshalb sollten diese Kommandos zugunsten 

der bereits entworfenen Routinen zur Integritätspflege verboten werden. Die Routinen zur Integritätspflege 

können jedoch der Definition der Sicherheitsanforderungen zuwider laufen. Deshalb ist die Konsistenz 

dieser beiden unterschiedlichen Anforderungen zu überprüfen. 

Unterbindung des Zugriffs auf physische Strukturen: Die Veränderung der Standardprozeduren zur Integritätspflege 

sollte den Systemadminstratoren vorbehalten bleiben. Haben Benutzer eigene Mechanismen 

entwickelt, dann sollten die neuen Pflegemechanismen diesen Benutzer vorbehalten bleiben. Einige 

DBMS erlauben nicht die Beschränkung der Rechte auf einen Zugriff von der Beschränkung der Rechte 

auf Spaltennamen zu unterscheiden. Damit ist auch einem Benutzer die Veränderung der Tabellenstruktur 

möglich. Diese Rechte sollten speziell eingeschränkt werden. 

Pragmatik: 

Zugriff erfolgt nur über die Sichten: Durch eine Vielzahl von Sichten, unterschiedliche Zugriffsmechanismen 

etc. können jedoch auch eine Reihe von Problemen entstehen. Insbesondere ist die Vielfalt der Sichten 

zu verwalten, wodurch ein overhead entsteht. 

Wildwuchs von Sichten: Werden insbesondere Dialoge verfeinert, die Rechte und Rollen der Benutzer 

verändert, dann entstehen oft weitere Sichten, die einer Verwaltung durch das System bedürfen. 

Wildwuchs von Namen: Durch eine Vielfalt von Namen kann auch der semantische Zusammenhang 

zwischen diesen Namen verloren gehen. Dies kann durch die Benutzung von guidelines und Synonymwörterbüchern 

vermieden werden. 

Wildwuchs von Programmen: Der Zusammenhang zwischen den Sichten muß sich auch in einem Zusammenhang 

zwischen den Sichten wiederspiegeln. Die einfachste Methode, Wildwuchs zu vermeiden, 

ist ein Verbot der Benutzung kombinierter Sichten. 

Funktionelle Beschränkungen im Zusammenhang mit speziellen Sichten: Da insbesondere Updates über 

Sichten kritisch sind, werden verschiedene Operationen über den Sichten nicht erlaubt sein. Dieser 

Umstand kann für die einzelnen Benutzer nicht mehr nachvollziehbar sein. 

Integration bzw. Kombination über zentrale Sichten: Die Kombinationsregeln und die Integrationsregeln 

sollten im Rahmen der Entwurfsdokumentation explizit niedergelegt werden. 

Zugriffssichten für den read-only-Zugriff: Durch ein striktes ‘hiding’ wird evt. auch zuviel an Information 

dem Benutzer vorenthalten. Deshalb ist auch in diesem Schritt die Dialogmenge mit in die Betrachtung 

einzubeziehen. 

Integritätspflege über zentrale Sichten: Durch eine sichtenorientierte Integritätspflege können die Pflegemechanismen 

auch in modularer Form entwickelt werden. Damit sind Überschneidungen, die auch Zyklen 

hervorrufen können, eher zu vermeiden. 

Einbettung der Sichten in die Beschreibung: Bezeichner sollten für den Benutzer einfach mit dem Inhalt 

verknüpfbar sein. Zentrale Sichten können im Namen bereits auch einen Hinweis auf den Integrationsmechanismus 

geben. Im integrierten Schema kann die Wahl der Bezeichner bereits anhand der gewünschten 

Transformation in das logische Modell erfolgen. 

Definition von Sicherungsmechanismen über zentralen Sichten: Die Trennung von Zugriff und Sicherung 

bringt einen overhead mit sich, denn man in die operationale Optimierung mit einbeziehen muß. 

In unserem Beispiel soollten jedoch unbefugten Personen, die nicht im Genehmigungsprozeß bzw. Verbuchungsprozeß 

einbezogen und nicht Besitzer des entsprechenden Dokumentes sind, der Zugriff verwehrt 

bleiben. 

IS ADD


Definition einer Authorisierungstabelle zur Kontrolle des Zugriffs: Oft wird empfohlen, jedem Aktor für 

jede seiner Rollen eine spezifische Sicht zuzuordnen. Damit wird der Entwurf übermäßig komplex. Die 

Programme sind dann meist nicht mehr zu pflegen. Aus diesem Grund ist eine Authorisierungstabelle meist 

der sinnvollere Ausweg. Dann kann durch einen Verbund der Authorisierungstabelle mit den zentralen 

Sichten die jeweilige Arbeitssicht direkt gewonnen werden. 

Wird diese Darstellung zu komplex, dann kann man durch Techniken der Denormalisierung einfachere 

Sichten gewinnen, wobei in diesem Fall die Redundanz erplizit gepflegt werden muß. 

Ist eine direkte Compilierung der Sicherheitsroutinen in die Programme möglich, dann kann auch dieser 

Weg gewählt werden. 

Damit erhalten wir die folgenden Pragmatiken. 

Sicherheitsanforderungen Benutzung von Sichten GRANT Kommandos 

Read-Zugriff auf alle Objekte Zentrale Sichten GRANT Read-Zugriff ON Sicht 

und Komponenten 

TO alle Benutzer bzw. Gruppen 

Read-Zugriff auf alle Objekte Sicherheitssichten GRANT Read-Zugriff ON Sicht 

und einige Komponenten 


Read-Zugriff auf einige Objekte Sicherheitsichten GRANT Read-Zugriff ON Sicht 

und alle Komponenten 


Read-Zugriff auf einige Objekte 

und einige Komponenten 

oder 

Zentrale Sichten mit 

Authorisierungstabelle mit 

Authorisierungssicht über 

Verbund und SELECT 

WHERE Attr = USER 

bzw. 

Authorisierungssicht über 

Subquery und SELECT 

WHERE Attr = USER 

bzw. 

Duplikatspalten in einer 

Tabelle mit Authorisier.-sicht 

SELECT WHERE Attr = USER 

bzw. 

Authorisierungsprogramm mit 

Inhalt SELECT WHERE ... 

Kombination der vorherigen 

Zugänge 

GRANT Read-Zugriff ON Authorisierungssicht 

TO PUBLIC 

oder 

GRANT execution ON Authorisierungsprogramm 

TO PUBLIC 

Bevorzugung der Standardprozeduren zur Integritätspflege: Die Integritätspflege kann auch durch benutzer 

umgangen werden. Dies trifft insbesondere auf Makros, die zur Pflege der Integrität entwickelt 

wurden, zu. Anstelle dieser kann man durch entsprechende ‘exit’s oder entsprechenden Programmkode 

die Umgehung verhindern. 

Ein pragmatischer Zugang wird in der folgenden Tabelle vorgestellt. 

IS ADD


Sicherh.-anford. Benutzung von Normale Update-Operationen GRANT Kommandos 

Sichten 

versus Standard-Prozeduren 

Update-Zugriff auf Zentrale Sichten mit DML-Kommandos GRANT updates 

alle Objekte und 

ON Sicht 

alle Komponenten 

TO alle Ben./Gruppen 

mit Standard-Pflege-Prozeduren Verbot der DML-updates 

über Sichten 

GRANT execution 

ON Maintenance-Routinen 


Update-Zugriff auf Zentrale Sichten über Standard-Pflege-Prozed. Verbot der DML-updates 

alle Objekte und (erforderlich hier) über Sichten 

einige Komponenten 




Sicherheitssichten mit DML-Kommandos GRANT execution 



über Standard-Pflege-Prozed. 

bei Separierung der Routinen für Verbot der DML-Kommandos 

jede Sicht (eine Routine; verschie- GRANT execution 

dene kompilierte Versionen für ON Maintenance-Routinen 

jede Sicht oder dynamische Bindung TO alle Ben./Gruppen 

der Routinen an die Sichten) 

Update-Zugriff auf Zentrale Sichten mit Standard-Pflege-Prozeduren Verbot der DML-Kommandos 

einige Objekte und (erforderlich hier) GRANT execution 

alle Komponenten 



Sicherheitssichten mit DML-Kommandos GRANT execution 



mit Standard-Pflege-Programmen GRANT execution 



Zentrale Sichten, mit DML-Kommandos 

zentrale Authori- 


sierungssichten, 


Authorisierungssicht zur 


Verbindung dieser mit Standard-Pflege-Programmen Verbot der DML-Kommandos 




Zentrale Sichten, mit Standard-Pflege-Programmen 

zentrale Authori- , (erforderlich hier), die 

sierungssichten, (erforderlich hier), die Verbot der DML-Kommandos 

aber DBMS erlaubt keine Zugriffsauthorisierung über GRANT execution 

updates über join/sub- SELECT WHERE ON Maintenance-Routinen 

query-Sichten beider Attr = USER verfizieren TO alle Ben./Gruppen 

Update-Zugriff auf 

einige Objekte und Kombination der beiden 

einige Komponenten obigen Verfahren 

Unterbindung des Zugriffs auf physische Strukturen: Eine einfache Methode zur Kontrolle der Modifikationsmöglichkeiten 

der Benutzer ist die zentrale Kontrolle der Aufgaben, die eine größere Sicherheitsrelevanz 

oder auch größere Auswirkungen auf die Arbeit der Datenbanken haben (Neudefinition von 

Datenbanken, Speicheroptionen, konkurrierender Zugriff zu Tabellen vieler Benutzer). Andere Aufgaben 

können einem breiteren Benutzerkreis geöffnet sein. Damit sind Benutzer auch für ihre eigene Sicherheit 

selbst verantwortlich. 

2.11 Design by schema pattern 

nach den beiden Modellierungsfibeln 

People and organization 

Products 

Ordering products 

IS ADD


Order delivery and invoicing 

Work effort 

Accounting and budgeting 

Human resources 

siehe 2000 und 2001 Preprints zu Pattern und Stars 

IS ADD


2.12 Ein Beispiel 

2.12.1 Ein HERM-Beispiel 

2.12.2 Die relationale Transformation des Beispieles 

Annahmen für die Transformation im Vorlesungsbeispiel: 

• volle ID-Entfaltung 

• rigides Nullwerte-Management 

• Separation von Schemadefintion und Integritätsbedingungen 

• minimale Indexunterstützung (nur Schl¨ssel (Primär- und Fremd-)) 

• minimale Menge von Wertebereichen 

• vollständige Verflachung 

• Auflösung aller Cluster-Typen 

• Event-Nonseparation mit Surrogat-Auflösung 

• Einbettung von (0,1)-*-Beziehungen 

• Namensgenerierung mit Präfixerweiterung und vorgegebener Präfixmenge, Trennung durch 

als Delimiter 

-- Database Section 

-- ________________ 

create database DB1_Vorlesungsbeipiel; 

-- DBSpace Section 

-- _______________ 

-- Table Section 

-- _____________ 

create table Studiengang ( 

ID_Stu char(10) not null, 

SName char(1) not null, 

Betreuer char(1) not null, 

Pruefungsamt char(6) not null, 

ID_Ins char(10) not null, 

primary key (ID_Stu)); 

create table Kurs ( 

ID_Kur char(10) not null, 

KursNr char(7) not null, 

Bezeichnung char(20) not null, 

primary key (ID_Kur)); 

create table Raum ( 

ID_Rau char(10) not null, 

Gebaeude char(4) not null, 

Raumnr numeric(5) not null, 

primary key (ID_Rau)); 



Name(First,Fam,{Title}) 

Person 

Adr(Zip,Town,Street(Name,Nr)) 

❃ 

❑ 

■ 

Person’s number 

Supervisor 

Since 

StudNr 

✙ 

Student 

❖ 

✠ 

■ 

Major 

Minor 

Department 

✸ 

Phones{Phone} 

Director 

✛ 

DName 

In 

✲ 

❃ 

❥ 


✻ 

Primary 

Investigator 

Speciality 

Member 

Result 

Time(Day,Hour) 

Enroll ✲ Lecture Has 

⊕ 

✾ 

✰ 

❄ 

Semester 

Year Season 

Nr 

Room 

Building 

✻ 

Course 

✻ 

CNu 

CName 

❄ 

Project 

Prerequis 

Begin 

Num 

End 

PName 

Abbildung 71: HERM-Diagram of the University Database 



create table Institut ( 


RaumSekret char(8) not null, 

Kostenstelle char(12), 

Telefon numeric(4) not null, 

IName char(1) not null, 

Sprecher char(15) not null, 

Fakultaet char(1) not null, 

primary key (ID_Ins)); 

create table Semester ( 

ID_Sem char(10) not null, 

Jahreszeit char(2) not null, 

Jahr numeric(4) not null, 

primary key (ID_Sem)); 

create table Projekt ( 

ID_Pro char(10) not null, 

Projektnr char(8) not null, 

Beschreibung varchar(90) not null, 

Bezeichnung char(20) not null, 

primary key (ID_Pro)); 

create table Student ( 


ID_Per char(10) not null, 

MatrNr char(7) not null, 

primary key (ID_Stu), 

unique (ID_Per)); 

create table Professor ( 



Spezialisierung char(1) not null, 

primary key (ID_Pro), 

unique (ID_Per)); 

create table Person ( 


Geburtsort char(15) not null, 

Adresse char(40) not null, 

Personenname char(25) not null, 

Geburtsdatum date not null, 

primary key (ID_Per)); 

create table Betreuer ( 



von date not null, 

bis date, 

Thema varchar(30) not null, 

primary key (ID_Pro, ID_Stu)); 

create table eingeschrieben in ( 

E_S_ID_Stu char(10) not null, 



bis date not null, 

primary key (ID_Stu, E_S_ID_Stu)); 



create table hoert ( 


ID_Vor char(10) not null, 

Resultat char(10) not null, 

Note char(2), 

primary key (ID_Vor, ID_Stu)); 

create table Projektmitarbeiter ( 



P_P_ID_Pro char(10) not null, 

primary key (ID_Pro), 

unique (ID_Stu), 

unique (P_P_ID_Pro)); 

create table Vorlesung ( 

ID_Vor char(10) not null, 

Wochentag char(2) not null, 

Block char(2) not null, 

Nummer char(9) not null, 


ID_Sem char(10) not null, 

ID_Rau char(10) not null, 

ID_Kur char(10) not null, 

primary key (ID_Vor)); 

create table In ( 


Seit char(1) not null, 


primary key (ID_Pro)); 

create table wirkt mit ( 

W_P_ID_Pro char(10) not null, 


bis date not null, 

Kontraktnr char(6) not null, 


primary key (ID_Pro, W_P_ID_Pro)); 

-- Constraints Section 

-- ___________________ 

alter table Studiengang add constraint FKverantwortlich fuer 

foreign key (ID_Ins) 

references Institut; 

--alter table Student add constraint 

-- check(exists(select * from eingeschrieben in 

-- where eingeschrieben in.E_S_ID_Stu = ID_Stu)); 

alter table Student add constraint FKPer_Stu 

foreign key (ID_Per) 

references Person; 

--alter table Professor add constraint 

-- check(exists(select * from In 

-- where In.ID_Pro = ID_Pro)); 



alter table Professor add constraint FKPer_Pro 

foreign key (ID_Per) 

references Person; 

alter table Betreuer add constraint FKBet_Stu 

foreign key (ID_Stu) 

references Student; 

alter table Betreuer add constraint FKBet_Pro 

foreign key (ID_Pro) 

references Professor; 

alter table eingeschrieben in add constraint FKein_Stu_1 


references Studiengang; 

alter table eingeschrieben in add constraint FKein_Stu 

foreign key (E_S_ID_Stu) 


alter table hoert add constraint FKhoer_Vor 

foreign key (ID_Vor) 

references Vorlesung; 

alter table hoert add constraint FKhoer_Stu 



alter table Projektmitarbeiter add constraint FKStu_Pro 



alter table Projektmitarbeiter add constraint FKPro_Pro 

foreign key (P_P_ID_Pro) 


alter table Vorlesung add constraint FKliest 



alter table Vorlesung add constraint FKim 

foreign key (ID_Sem) 

references Semester; 

alter table Vorlesung add constraint FKveranstaltet 

foreign key (ID_Rau) 

references Raum; 

alter table Vorlesung add constraint FKzu 

foreign key (ID_Kur) 

references Kurs; 

alter table In add constraint FKIn_Pro 



alter table In add constraint FKIn_Ins 

foreign key (ID_Ins) 

references Institut; 



alter table wirkt mit add constraint FKwir_Pro_1 


references Projektmitarbeiter; 

alter table wirkt mit add constraint FKwir_Pro 

foreign key (W_P_ID_Pro) 

references Projekt; 

-- Index Section 

-- _____________ 

create unique index ID 

on Studiengang (ID_Stu); 

create index FKverantwortlich fuer 

on Studiengang (ID_Ins); 


on Kurs (ID_Kur); 


on Raum (ID_Rau); 


on Institut (ID_Ins); 


on Semester (ID_Sem); 


on Projekt (ID_Pro); 


on Student (ID_Stu); 

create unique index FKPer_Stu 

on Student (ID_Per); 


on Professor (ID_Pro); 

create unique index FKPer_Pro 

on Professor (ID_Per); 


on Person (ID_Per); 

create unique index IDBetreuer 

on Betreuer (ID_Pro, ID_Stu); 

create index FKBet_Stu 

on Betreuer (ID_Stu); 

create index FKBet_Pro 

on Betreuer (ID_Pro); 

create unique index IDeingeschrieben in 

on eingeschrieben in (ID_Stu, E_S_ID_Stu); 



create index FKein_Stu_1 

on eingeschrieben in (ID_Stu); 

create index FKein_Stu 

on eingeschrieben in (E_S_ID_Stu); 

create unique index IDhoert 

on hoert (ID_Vor, ID_Stu); 

create index FKhoer_Vor 

on hoert (ID_Vor); 

create index FKhoer_Stu 

on hoert (ID_Stu); 


on Projektmitarbeiter (ID_Pro); 

create unique index FKStu_Pro 

on Projektmitarbeiter (ID_Stu); 

create unique index FKPro_Pro 

on Projektmitarbeiter (P_P_ID_Pro); 


on Vorlesung (ID_Vor); 

create index FKliest 

on Vorlesung (ID_Pro); 

create index FKim 

on Vorlesung (ID_Sem); 

create index FKveranstaltet 

on Vorlesung (ID_Rau); 

create index FKzu 

on Vorlesung (ID_Kur); 

create unique index FKIn_Pro 

on In (ID_Pro); 

create index FKIn_Ins 

on In (ID_Ins); 

create unique index IDwirkt mit 

on wirkt mit (ID_Pro, W_P_ID_Pro); 

create index FKwir_Pro_1 

on wirkt mit (ID_Pro); 

create index FKwir_Pro 

on wirkt mit (W_P_ID_Pro); 



2.13 Schrittweise Modellierung im Co-Design an einem Beispiel 

Angaben 

zur Reise 

Reisedaten 

Reiseablaufdaten 

Kostenüberweisung 

Finanzdaten 

Kostenabrechnungsdaten 

Reisekostenanerkennung 

Abbildung 72: Die Grobstruktur der Anwendung 

Storyschritt 

Vertreter 

✻ 

❄ 

❄ 

Akteur 

✛ 

Rolle 

✲ 

Sicht 

Abbildung 73: Das Akteurmodell für die Geschäftsprozeßschicht


Verbuchung 

✻ 

(1,1) 

Überweisung 

Genehmigung 

Abrechnung 

abgerechnet durch 

(1,n) (1,1) 

Antragsteller ✛ beantragt ✲ 

❄ 

(1,n) 

Dienstreise 

Genehmigung 

Reiseverlauf 

Abbildung 74: Grobdarstellung der Struktur der Anwendung 



Sicht für allgemeine Verbuchung 

Abbildung 75: Sichtenskizze für unsere Anwendung 

Beantragung ✲ Ausfüllen ✲ Befürwortung ✲ Genehmigung 

❄ 

Abrechnung 

❄ 

Verbuchung ✲ Genehmigung 

der Abrechnung 

✲ 

Kontrolle der 

Abrechnung, 

Berechnung 

der Kostensätze 

✲ 

Genehmigung der 

Verbuchung 

❄ 

Verrechnung ✲ Zuordnung zum 

Abrechnungsmodus 

✯ 

✲ 

❥ 

Überweisung 

Kassenbereitstellung 

Rückforderung 

Abbildung 76: Szenarien für Behandlung des Dienstreiseantrages (Normalverfahren)


Antragsteller Vorges. des Antragst. Dekan 


❄ Antragsteller 

Abrechnung 

❄ 

Dekan 



✲ 

Sachbearb. X 

Kontrolle der 

Abrechnung, 

Berechnung 


✲ 

Sachbearb. Y 


Verbuchung 

❄ 

Sachbearb. X 

Verrechnung ✲ Zuordnung zum 


✯ 

✲ 

❥ 

Sachbearb. X 

Überweisung 

Kassenbereitstellung Kassiererin 

RückforderungSachbearb. X 

Abbildung 77: Themen und Akteuren für Behandlung des Dienstreiseantrages (Normalverfahren) 

Akteur 

✛ 

Rolle 

✲ Dialogschritte ✛ 

zugeordnete 

✲Sichtenelemente 

✻ 

✻ 

❄ Vertreter ❄ 

❄ 

Rechte 

berechnet 

durch 

Abbildung 

❄ 

Handlungsschritte ✛ 

In 

❄ 

✲ Skelettelement 

Abbildung 78: Das Akteurmodell für die Aktionsschicht


Beantragungssicht Genehmigungssicht 1 Genehmigungssicht 2 


❄Abrechnungssicht 

Abrechnung 

❄ 

Genehmigungssicht 3 



✲ 

Verbuchungssicht 1 

Kontrolle der 

Abrechnung, 

Berechnung 


✲ 

Genehmigungssicht 4 


Verbuchung 

❄ 

Verrechnungssicht 1 Verrechnungssicht 2 

✯ Überweisung 

Verrechnung ✲ Zuordnung zum ✲ 

Verrechnungssicht 3 

Kassenbereitstellung 


❥ 

Verrechnungssicht 4 

Rückforderung 

Abbildung 79: Skelett für den Dienstreiseantrag (Normalverfahren) 

Antragsteller 

≈ (1, 10) 

200 (1, n) 

500 ✛ 

2000 

≈ (1, 2) 

(1, 30) 

Reise 

beantragt 

❄ 

1000 

5000 

30000 

≈ (1, 1) 

(0, 1) 

✛ 

wird 

abgerechnet 

(Vorschlag) 

(1, 50) 

❄ 

Verbuchung 100 

200 

300 

Abbildung 80: Erster Entwurf für die Beantragungssicht 

System Historie Optionen Fenster 

Antragstellerdaten Reisedaten Verbuchungsdaten 

Name 

Vorname 

Institut 

Lehrstuhl 

Wohnort 

Dienstort 

Datum 

Unterschrift 

Vergüt.-stufe 

Reisek.-stufe 

f 1 (name,vorname) 

f 2 (name,vorname) 

Abbildung 81: Dialogobjekt zur Darstellung von Antragstellerdaten für Lehrstuhlanträge


System Historie Optionen Fenster 

Antragstellerdaten Reisedaten Verbuchungsdaten 

Name 

Vorname 

Institut 

Lehrstuhl 

Ziel 

Dauer - von 

Dauer - bis 

Zweck 

Weitere 

Teilnehmer 

Zus.hang zu 

Privatreise 

Beförd.-mittel 

Poliz. Kennz. 

bei Privat PkW 

Abbildung 82: Dialogobjekt zur Darstellung von Reisedaten für Anträge aus Lehrstuhl 

Auto 

0 

30 

3000 

≈ (1,1) 

(1,2) 

≈ (1,1) 

(0,4) 

≈ (1,200) 

(1,n) 

✻ 

Benutzt 

≈ (1,1) 

(0,4) 

Wohnort 

✻ Privatzweck 

Dienstort 

AHatV 

PolKZ 

Art 

1 

3 

4 

≈ (1,1) 

(1,4) 

≈ (1,10) 

(1,n) 

Ort 

zugeordnet 

zu 

Von Bis Zweck 

beantragt 

Land 

Reisekostenstufe 

≈ (1,2) 

(1,30) 

✛≈ (0,1) 

(0,2) 

AntrDatum 

0 

1000 

∞ 

✛ 

≈ (1,1) 

(1,3) 

✲ 

≈ (20,80) 

(0,n) 

Name 

Lehrstuhl 

≈ (10,40) 

(0,n) 

✻ 

Kostenstelle 

Beförderungsmittel 

Verbuchung 

100 

200 

300 

Titel 

 

Mögliche 

Reise 

20 

90 ✛ 

150 

≈ (1,1) 

(1,2) 

Vorschuß(Höhe,Auszahlart) 

≈ (0,n) 

(0,n) 

✲ 

In 

❄ 

Vergütungsgruppe 

Name Vorname 

❄ ✢ 

Antragsteller 

200 

500 ✛ 

2000 

Reiseziele 

Art 

1 

3 

8 

≈ (2,5) 

(0,n) 

✲ 

Fakultät 

Nr 

1 

5 

5 

Abbildung 83: Beantragung einer Dienstreise mit Verbuchung über den Lehrstuhl


Auto 

0 

30 

3000 

≈ (1,1) 

(1,2) 

≈ (1,1) 

(0,4) 

≈ (1,200) 

(1,n) 

✻ 

Benutzt 

≈ (1,1) 

(0,4) 

Wohnort 


Dienstort 

AHatV 

PolKZ 

Art 

1 

3 

4 

≈ (1,1) 

(1,4) 

≈ (1,10) 

(1,n) 

Ort 

zugeordnet 

zu 

Von Bis Zweck 

beantragt 

❄ 


Name Vorname 

❄ ✢ 

Antragsteller 

200 

500 ✛ 

2000 

Reiseziele 



≈ (1,2) 

(1,30) 

✛≈ (0,1) 

(0,2) 

AntrDatum 

0 

1000 

∞ 

✛ 

≈ (1,1) 

(1,3) 

✲ 

≈ (20,80) 

(0,n) 

Name 

Lehrstuhl 

≈ (10,40) 

(0,n) 

✻ 

Kostenstelle 


Verbuchung 

100 

200 

300 

Titel 

20 

90 ✛ 

150 

≈ (1,1) 

(1,2) 

Vorschuß(Höhe,Auszahlart) 

≈ (0,n) 

(0,n) 

✲ 

In 

 

Mögliche 


Art 

1 

3 

8 

≈ (2,5) 

(0,n) 

✲ 

Fakultät 

Nr 

1 

5 

5 

Abbildung 84: Beantragung einer Dienstreise mit Verbuchung über den Lehrstuhl


Auto 

0 

30 

3000 

≈ (1,1) 

(1,2) 

≈ (1,1) 

(0,4) 

≈ (1,200) 

(1,n) 

✻ 

Benutzt 

≈ (1,1) 

(0,4) 

Wohnort 


Dienstort 

AHatV 

PolKZ 

Art 

1 

3 

4 

≈ (1,1) 

(1,4) 

≈ (1,10) 

(1,n) 

Ort 

zugeordnet 

zu 

Von Bis Zweck 

beantragt 

❄ 


Name Vorname 

❄ ✢ 

Antragsteller 

200 

500 ✛ 

2000 

Reiseziele 



≈ (1,2) 

(1,30) 

✛ 

AntrDatum 

0 

1000 

∞ 

✛ 

≈ (1,1) 

(1,3) 

✲ 

≈ (20,80) 

(0,n) 

Name 

Verbuchung 

Lehrstuhl 

20 

90 ✛ 

150 

≈ (1,1) 

(1,2) 

Kostenstelle 

≈ (0,1) 

(0,2) 

≈ (0,n) 

(0,n) 

✲ 

In 

Vorschuß 

(Höhe,Auszahlart) 

Art 

1 

3 

8 

≈ (2,5) 

(0,n) 

✲ 

Fakultät 

≈ (10,40) 

(0,n) 

✻ 

Nr 

 

Mögliche 



100 

200 

300 

Titel 

1 

5 

5 

Abbildung 85: Beantragung einer Dienstreise mit Verbuchung über die Fakultät


DekanBestät 

✲ LehrstGenehm 

DekGenehm 

Person ✛ Antragsteller✛ 

beantragt ✛ 

2 

❄ 

LVerbuch 

❄ 

LBefürw 

✻ 

✻ 

✻ 

❄ 

❄ 

❄ 

ArbeitetAn 

Reise 

LehrstFonds 

✯ 

FVerbuch 

leitet 

✲ 

❄ 

Lehrstuhl 

✛ 

LHatFond 

✻ 

DekanVonF 

FakVonL 

✲ 

✲ 

Fakultät 

✛ 

FakHatFond 

✲ 

❄ 

FakFonds 

Abbildung 86: Genehmigungen und Bestätigungen der Anträge durch Lehrstuhl bzw. Dekanat - erste Sichten 






Verbuchungssicht1 


... 



❘ ❄ ✠ 

Zentrale 


❘ ❄ ✠ 

Zentrale 

Verbuchungssicht 

3 ❯ 

❄ 


❘ ❄ ✠ 

Zentrale 

Verrechnungssicht 

✙ 

Abbildung 87: Sichtenintegration in unserer Anwendung


Benutzersichten 

zur Vereinfachung 

des Zugriffs 




... 

Sicherheitssichten 

zur Kontrolle 

des Zugriffs 

❄ ❄ ❄ 

Zugriffsbeschr. 






... 

Zentrale 

Sichten 


der Unabhängigkeit 

❘ ❄ ✠ 

Zentrale 


... 

Integriertes 

Schema 


der Speicherung 

3 


Abbildung 88: Ausschnitt aus der Sichtenarchitektur mit Sicherheitssichten 

2.13.1 HERM und OLAP bzw. Data Warehouses 

siehe Bild 92, 93


V 1 

V 2 

Reisen{(Ort, Land, Zweck, Von, Bis) } 

Reisezeitraum (Von, Bis) 

Reisende{ (Name, Vorname) } 

Dienstreisender 

Dienstreisen 

Name Vorname 

Ort Land Zweck 

✛ 

V 3 

Von 

führt 

durch 

Bis 

✲ 

Dienstreisender 

Dienstreise 

Name Vorname Ort Land Zweck 

Abbildung 89: Zwei verschiedene Sichten auf eine Dienstreise und eine integrierte Sicht 

Auto 


✻ 

✻ 

Benutzt 

AHatV 

DekanBestät 

✲ LehrstGenehm 

DekGenehm 

❄ 

❥ 

Person ✛ Antragsteller 

✛ 

beantragt 

✛ 

2 

❄ 

LVerbuch 

❄ 

LBefürw 

✻ 

✻ 

✻ 

leitet 

✲ 

ArbeitetAn 

❄ 

Lehrstuhl 

✻ 

✛ 

❄ 

Mögliche 

Reise 

LHatFond 

✯ 

❘ 

❫ 

❄ 

LehrstFonds 

Reiseziele 


❄ 

FVerbuch 

DekanVonF 

FakVonL 

✲ 

✲ 

Fakultät 

✛ 

FakHatFond 

✲ 

❄ 

FakFonds 

Abbildung 90: Integration der Beantragungs- und Genehmigungssichten bei Verbuchung über den Lehrstuhl bzw. die 

Fakultät


Hauptmenü 

✲ Beantragungsmenü 

3 ... 

❥ ... 

✯ 

✿ 

✲ 

3 

❥ 

Antragsteller 

Reisedaten 

Verbuchungsvorschlag 

Befürwortung 

Genehmigung 

Abbildung 91: Die Organisation der Menüs für die Beantragung 

Person 

OtherData 

Person 

Postal 

Person 

POBox 

 

✶ 

❄ 

Person 

Basic 

Data 

✻ 

✮ 

✐ 

Person 

EmailURL 

Person 

SMTP 

Person 

PhoneFax 

Abbildung 92: HERM Representation of the Star Type Person 

CUBE A: PARTICIPANTS PER LECTURE AND DAY 

CUBE B: USAGE OF ROOMS PER DAY 

Lectures 

✛ 

HeldOn 

✲ 

Day 

Room 

✛ 

Usage 

✲ 

Day 

#Participants 

#TotalUsage 

Room# 

SCHEDULING SCHEMA ON UNIVERSITY AND EVENING LECTURES 

University 

Lecture 

✛ 

Room 

✻ 

Room# 

University 

Lectures 

✛ 

HeldOn 

#Participants 

✲ 

Working 

Day 

✻ 

✲ 

IsA Room ✛ ❄ 

IsA 

General 

Purpose 

Room 

✻ 

Room# 

Title 

IsA ✲ Day ✛ 

Organized 

On 

✲ 

Evening 

Lectures 

#Participants 

Abbildung 93: Scheduling Views on Lectures Given in a University


2.14 Beispiele aus dem HERM-Buch 

.


Literatur 

[AFT92] S. S. Al-Fedaghi and B. Thalheim. The key concept in database models. Unpublished manuscript, 1992. 

[AHV95] S. Abiteboul, R. Hull, and V. Vianu. Foundations of databases. Addison-Wesley, Reading, MA, 1995. 

[All84] J.F. Allen. Towards a general theory of action and time. Artificial intelligence, (6):123–154, 1984. 

[Bis95] 

[BM97] 

[BS00] 

[BS03] 


E. Börger, , and L. Mearelli. Integrating ASM into the software development life cycle. J. Universal 

Computer Science, 3(5):603–665, 1997. 

E. Börger and W. Schulte. Architecture Design and Validation Methods, chapter Modular design for the 

Java virtual machine architecture, pages 297–357. Springer, Berlin, 2000. 

E. Börger and R. Stärk. Abstract state machines - A method for high-level system design and analysis. 


[BT92] C. Beeri and B. Thalheim. Identification is well-founded in object-oriented databases. Manuscript, 1992. 

[BT95] C. Beeri and B. Thalheim. Can I see your identification, please? - Identification is well-founded in 

object-oriented databases. Manuscript, Cottbus/Jerusalem, 1995. 

[BT99] 

[Cad76] 

[DMT04] 

[DMT07] 

[EWH85] 

[Fownn] 

[Gog94] 

C. Beeri and B. Thalheim. Identification as a primitive of database models. In Proc. FoMLaDO’98, pages 

19–36. Kluwer, London, 1999. 

J.-M. Cadiou. On semantic issues in the relational model of data. In A. W. Mazurkiewicz, editor, Proc. 5th 

Symp. on Mathematical Foundations of Computer Science - MFCS’76, LNCS 45, pages 23–38, Gdańsk, 

1976. Springer, Berlin. 

J. Demetrovics, A. Molnar, and B. Thalheim. Graphical and spreadsheet reasoning for sets of functional 

dependencies. In ER’2004, LNCS 3255, pages 54–66, 2004. 

J. Demetrovics, A. Molnar, and B. Thalheim. Graphical axiomatisation of sets of functional dependencies 

in relational databases. In Alkalmazott Matematikai Lapok, volume 24, pages 223–264. 2007. 

R. Elmasri, J. Weeldreyer, and A. Hevner. The category concept: An extension to the entity-relationship 

model. DKE, 1(1):75–116, 1985. 

M. Fowler. Analysemuster. Addison-Wesley, 1999, Bonn. 

M. Gogolla. An extended entity-relationship model - fundamentals and pragmatics. LNCS 767. Springer, 

Berlin, 1994. 

[Gol06] R. Goldblatt. Topoi: The Categorial Analysis of Logic. Dover Books on Mathematics, 2006. 

[HL07] 

[Hoh93] 

[KL02] 

S. Hartmann and S. Link. English sentence structures and eer modeling. In APCCM, volume 67 of 

CRPIT, pages 27–35. Australian Computer Society, 2007. 

U. Hohenstein. Formale Semantik eines erweiterten Entity-Relationship-Modells. Teubner, Stuttgart, 

1993. 

Carsten Kleiner and Udo W. Lipeck. Automatische Erzeugung von XML DTDs aus konzeptuellen Datenbankschemata. 

Datenbankspektrum, 1(2):14–22, 2002. 



[Kle07] 

[KR97] 

M. Klettke. Modellierung, Bewertung und Evolution von XML-Dokumentkollektionen. Advanced PhD 

(Habilitation Thesis), Rostock University, Faculty for Computer Science and Electronics, 2007. 

H.-J. Klein and J. Rasch. Value based identification and functional dependencies for object databases. 

In Proc. 3rd Basque Int. Workshop on Information Technology, pages 22–34. IEEE Computer Science 

Press, New York, 1997. 

[Lei60] G.W. Leibniz. Fragmente zur Logik. Berlin, 1960. 

[Leo92] M. Leonard. Database design theory. MacMillan, Houndsmills, 1992. 

[PBGG89] J. Paredaens, P. De Bra, M. Gyssens, and D. Van Gucht. The structure of the relational database model. 


[RK02] 

[Sch94] 

[ST93] 

[ST98] 

J. Rasch and H.-J. Klein. Database Integrity: Challenges and Solutions, chapter Functional Dependencies 

for Value Based Identification in Object-Oriented Databases, pages 250–292. Idea Group Publishing, 

2002. 

K.-D. Schewe. The specification of data-intensive application systems. Advanced PhD (Habilitation 

Thesis), Brandenburg University of Technology at Cottbus, Faculty of Mathematics, Natural Sciences 

and Computer Science, 1994. 

K.-D. Schewe and B. Thalheim. Fundamental concepts of object oriented databases. Acta Cybernetica, 

11(4):49–81, 1993. 

K.-D. Schewe and B. Thalheim. Readings in object-oriented databases. Reprint, BTU-Cottbus, accessible 

through http://www.is.informatik.uni-kiel.de/∼thalheim, Collection of papers by C. Beeri, K.-D. Schewe, 

J.-W. Schmidt, D. Stemple, B. Thalheim, I. Wetzel, 1998. 

[Tha91a] B. Thalheim. Dependencies in relational databases. Teubner, Leipzig, 1991. 

[Tha91b] B. Thalheim. Reconsidering key and identifier definitions in database models. Technical Report CS - 08 

- 91, Rostock University, Computer Science Department, 1991. 

[Tha00] B. Thalheim. Entity-relationship modeling – Foundations of database technology. Springer, Berlin, 2000. 

[Wan98] 

G. Wanner. Entwurf eines objektorientierten Datenbankmodells für relationale Datenbanksysteme. DIS- 

BIS 46. infix-Verlag, 1998. 

[Wit58] L. Wittgenstein. Philosophical Investigations. Basil Blackwell, Oxford, 1958. 

[Yan86] C.-C. Yang. Relational Databases. Prentice-Hall, Englewood Cliffs, 1986. 







D - 24098 Kiel 

 





3. Funktionalität von IS ab SS 2012 


Forschung 



3 Funktionalität von Informationssystemen 

Ein Mann, der recht zu wirken denkt, 

Muß auf das beste Werkzeug halten. 

Bedenkt, Ihr habt weiches Holz zu spalten, 

Und seht nur hin, für wen Ihr schreibt. 

Goethe, Faust, Vorspiel auf dem Theater, Direktor 

Funktionalität = Algebra + Anfragen + dynamische Integritätsbedingungen 

+ Erzwingung der statischen Integritätsbedingungen + .... 

Paradigmen 

formale Sprache \ Theorie Abstraktion Entwurf 

erfinden 

• 

verwirklichen • ⋄ 

benutzen 

• 

Einheit von statischen Gesichtspunkten (grundlegende Seiende und Beziehungen) und dynamischen Gesichtspunkten 

Veränderungen im Wissen müssen stets zu einer statischen Gesichtspunkten genügenden Aufzählung führen 

somit müssen Handlungen stets statisch abbildbar sein 

Seiendes - etwas, das wirklich existiert; kann seine Existenz unabhängig von anderen beginnen und beenden; 

damit formale Handlungen des Existenzbeginns und Ende als grundlegend 

Komplexität ⇒ leicht ausführbare Änderung 

Einfügen muß allein der Eindeutigkeitsbedingung genügen 

Löschen soll nicht Löschen von Werten anderer Seinender nachziehen

CAU zu Kiel, IfI, ISE, β 3. Funktionalität von IS ab SS 2012 312 

3.0 Vorbemerkungen zur Spezifikation der Funktionalität 

Gute Zusatzliteratur: 

R. J. Wieringa, Design methods for reactive systems. Morgan-Kaufmann, Amsterdam, 2003 

D. Dori, Object-process methdology. Springer, Berlin 2002 

3.0.1 Dynamik von Daten und die Reflexion durch Modellierung 

Entwicklung als eines der vier Prinzipien der Informatik. 

Transformation is a generalization of consumption (destruction), change (effect), generation (construction) 

of one or more objects. A ‘process’ is a pattern of transformation. So, a transformation may be modeled 

through a modification of the state, i.e. through delete, update, and insert. 

There are two perspectives from which a system can be contemplated. One perspective is the instantaneous, snapshotlike, 

structural one, which views the world as it is in any particular moment of time. This perspective has no time 

dimension. It represents the objects in the world and the time-independent relationships that may exist among them. 

A second perspective is one that does include time and represents the time relationships among the things in the 

world. From this viewpoint, the existence of an object is persistent - the object ‘statically sits there’, waiting to be 

transformed by a process. As long as no process acts on the object, it remains in its current state. 

A process, on the other hand, is typically ‘transient’. It is a thing what “happens” or “occurs” to an object rather than 

something that “exists” in its own rights. (D. Dori,59) 

Time relationships: cause and effect. 

We distinguish between 

Real-time state change depending on support we may provide for different validity modes 

real world validity 

transaction time validity or 

storage time validity 

Sequential or parallel execution models: Transformations may be applied sequentially based on a certain ordering 

or partially parallel. 

Time may be represented by a time model, e.g. by timelines based on a sequence of consecutive time intervals of 

identical duration. These intervals are termed chronons 1 . 

Functionality modeling criteria: 

Object dependability: For a change to occur, it must rely on at least one object for it to occur. 

Object transformation: A change must transform at least one of the objects in the preprocess object set. 

Association with time: A change must represent some happening, occurrence, action, procedure, routine, 

execution, operation, or activity that takes place along the timeline. 

Association with a verb: A change must be associated with a verb. 

A change of an object is an alteration in the state of that object. The effect of a transformation on an object is the 

change in the object’s state that the transformation causes, i.e. the transformation from the object’s input state to the 

object’s output state. 

Parties considered in the modeling of functionality: 

Enabler of a transformation: Object that must be present in order to form for that transformation to occur. 

Agent of the transformation: Intelligent enabler which can control the transformation it enables by exercising 

common sense or goal-oriented considerations. 

1 Chronon, used also in quantum mechanics, is like a ’time atom’, a non-decomposable time interval of some fixed, minimal duration.


Instrument of a transformation: Non-human physical or informatical enabler. 

Transformee of a transformation: Object that is transformed by the occurrence of that transformation. 

Affectee of a transformation: Transformee that was affected by the occurrence of the transformation. 

Consumee of a transformation: Transformee that is consumed and eliminated as a result of the transformation. 

Resultee of a transformation: Transformee that is constructed as a result of the occurrence of the transformation. 

Invocation of a transformation: 

3.0.2 Herangehensweise zur Spezifikation der Funktionalität 

Eine Spezifikation wird unterlegt durch 

Anforderungen und 

Constraints mit denen die Systementwicklung unterlegt wird. 

Die Eigenschaften können untergliedert werden in 

funktionale Eigenschaften wie Dienste, Verhalten, Kommunikation und 

Qualitätseigenschaften wie Effizienz, Benutzbarkeit, Zuverlässigkeit.... 

Jede Eigenschaft sollte durch die folgenden Elemente unterlegt werden: 

Angestrebte Eigenschaft 

Annahmen für die Betrachtung, Erzwingung, ... der Eigenschaft und 

Angaben für den Verletzungsfall mit entsprechenden Lösungen. 

Object Roles with Respect to a Transformation 

Involved object suite: Suite of objects that are transformed by the transformation or enable it. 

Pre-transformation object suite: Suite of objects that is required for the transformation to start its execution, enablers 

as well as transformees. 

Post-transformation object suite: Suite of objects that is generated or affected by the execution of for the transformation. 

Context-object suite: The suite of objects that stimulates and supports the transformation.


3.0.3 Unterschiedliche Herangehensweisen und Aufgaben 

Wir gehen von einer Einheit von statischen Gesichtspunkten (grundlegende Seiende und Beziehungen) und dynamischen 

Gesichtspunkten aus. 

Dynamische Gesichtspunkte der Anwendung lassen sich spezifizieren durch 

Operationen bzw. Handlungen zur Darstellung des dynamischen Verhaltens wie 

Änderungsoperationen zur Veränderung der Daten in der Datenbank, 

Retrievaloperationen zur Erschließung des Wissens aus der Datenbank ohne Veränderung der Datenbank, 

einer Sprache zur Generierung von Programmen und 

Rollenveränderungen von dargestellten Objekten. 

dynamische Semantik auf der Grundlage von dynamischen Integritätsbedingungen zur Darstellung von zugelassenen, 

erwarteten und verbotenen Handlungsfolgen und 

Verpflichtungen innerhalb einer Rolle beschreiben, welches Wissen zugänglich ist (Sichten) und welche Handlungsfolgen 

ausgeführt werden müssen (evt. unter Berücksichtung von Ursachen (aktive Elemente)) bzw. dürfen 

(evt. unter Berücksichtung von Voraussetzungen) sowie 

Mitteilungen an einen oder den anderen Empfänger, die sie ihrerseits verstehen und verarbeiten können. 

Veränderungen im Wissen müssen stets zu einer statischen Gesichtspunkten genügenden Aufzählung führen. Somit 

müssen Handlungen stets statisch abbildbar sein. Das Seiende ist etwas, das wirklich existiert. Es kann seine Existenz 

unabhängig von anderen beginnen und beenden. Damit werden formale Handlungen des Existenzbeginns und -endes 

grundlegend zur Umsetzung von Handlungen innerhalb der Datenbank. 

Wir unterscheiden bei der Beschreibung der Funktionalität in der Modellierung zwischen 

Produktfunktionen des Lastenheftes, die in allgemeiner Form die Hauptfunktionen mit den Einschränkungen der 

Anwendung darstellen, 

Arbeitsschritten des Pflichtenheftes, die die Funktionalität auf dem Niveau der Geschäftprozesse und Geschäftsvorfälle 

in ihrem Ablauf unter Berücksichtigung der Organisationsstruktur darstellen, 

Aktionen der Nutzer-Maschine zur vollständigen Beschreibung aller Handlungen von Benutzern aus deren Sicht, 

Prozessen der Workflow-Maschine zur vollständigen konzeptionellen Spezifikation der Funktionalität der Anwendung 

und 

Programmen der Datenbank-Maschine auf dem Niveau der logischen Maschine bis hin zur Codierung von Stored 

Procedures, Triggern etc., die in Modulen zusammengefaßt werden. 

Die Abstraktionsschichten werden in Bild 1 illustriert. 

Es existieren viele Modelle zur Darstellung der Prozesse und wenige Modelle zur Darstellung der dynamischen 

Semantik. 

Formular-orientierte Sprachen erlauben die Modellierung von Folgen von zusammenhängenden Aktivitäten. Mit 

Ablaufmodellen kann der Lebenszyklus eines (Datenbank-)Objektes dargestellt werden. In einer Form Definition 

Component werden die Objekte selbst beschrieben. Mit der Document Flow Component wird der Datenfluß 

beschrieben. Die Document Transformation Component erlaubt die programmiersprachliche Beschreibung der 

Aktivitäten. Aktivitäten können selbst zu Gruppen zusammengefaßt werden. Verschiedene parallele Berechnungen 

sind möglich. 

Fluß-orientierte Sprachen modellieren formale Handlungen als Flüsse von Objekten und Mitteilungen. Aktivitätengraphen 

bzw. Vorgangskettendiagramme, Prozeßmodelle und Beschreibungen von Lebenszyklen erlauben 

die Beschreibung von komplexem Verhalten.


Anforderungsschicht 


Vorstudie 

Skizzierung 

Produktfunktionalität 

Produktfunktion 

Lastenheft: Funktionen 

Feinstudie 

Verfeinerung 

Geschäftprozesse 

Arbeitsschritt 

Pflichtenheft: Funktion 


Entwurf 

Entwicklung 


Aktionen 

Nutzer-Maschine 


Schicht 



Workflow 

Prozesse 

Workflow-Maschine 


Module 

Datenbank-Maschine 

Programme 

Transaktionen 

Stored Procedures 

Abbildung 1: Die Arbeitsprodukte im Abstraktionsschichtenmodell für die Funktionalität


(a) Spezifikation der “Mission” aus der Anwendung heraus 

Typisches Beispiel einer fluß- bzw. tätigkeitsorientierten Darstellungsform: IDEF0-Modelle wie in Bild 2. 

❄ 

Absprachen 

mit anderen Bereichen ✲ 

... 

Anforderungen 

✲ 

✲ 

Lehrplan 

UnivIS 

Absprachen 

des Institutes 

❄ 

Erstellung eines 

Lehrangebotes 

✻ 

AG- 

Planer 

✻ 

❄ 

Regularien 

für LV 

Vorgeschlagene 

Veranstaltungen ✲ 

Neben-bedingungen 

Abbildung 2: Der Tätigkeitskasten von IDEF0 

Tätigkeiten werden stets mit Verben assoziiert und beschrieben. Das IDEF0-Modell benutzt ein Quadrupel- 

Modell: (Input, Control, Mechanism, Output). Betriebmittel (Mechanism) sind Systeme, die zur Ausführung des 

Prozesses benötigt werden. Durch Vorgaben (Control) werden Einschränkungen zur Ausführung von Prozessen spezifiziert. 

Pfeile können verzweigen (AND-Semantik) und zusammengeführt werden (AND- oder UNION-Semantik). Damit 

entstehen Pipeline-Pfeile. Sie können außerdem getunnelt werden. 

Ein fünfter Pfeiltyp (Reference) wird i.a. nicht benutzt. Mit diesem Pfeiltyp kann eine Beziehung zu anderen 

Schemata hergestellt werden. Es werden damit auch gemeinsame Funktionen beschreibbar. 

(b) Funktionsbäume, Funktionskarten und ihre Verfeinerung 

Erstellung eines 

Lehrangebotes 

Entwicklung eines 

Lehrprofiles 

Prüfung durch Leiter 

Zusammenstellung 

Abgleich des 

Lehrangebotes 

Neuerstellung Erweiterung 

Abbildung 3: Der Funktionsbaum zur komplexen Tätigkeit 

Der Funktionsbaum wie z.B. in Bild 3 wird benutzt, um den Aufbau von Tätigkeiten mit einer Verfeinerung zu 

unterlegen. Die Verfeinerung sollte eine 1-n-Verfeinerung sein.


(c) Dienstebeschreibung 

Ein Dienst wird durch die folgenden Elemente angegeben: 

Name 

Auslösende Ereignisse (externe, interne, temporal) 

Effekte der Dienstanwendung 

Annahmen für den Dienst 

(d) Zustandstransitionslisten und -tabellen 

Ereignislisten beschreiben Ereignisse und ihre Auswirkungen (effects). 

Sie sind durch entsprechende ASM-Regeln beschreibbar. 

Ein Türöffner wird beschrieben durch 

seinen Namen 

das auslösende Ereignis, z.B. ein Passagier betritt oder verläßt den Raum und 

den bereitgestellten Dienst, z.B. wenn ein Sensor eine Zustandsänderung bemerkt, dann werden die Türen 

geöffnet und per default für 10 Sekunden offen gelassen. 

if PassDoors(c) AND Door(c) = opened then c.state := geöffnet 

if PassDoors(c) AND Door(c) = closing then openDoor(c) AND c.state := geöffnet 

if ChangeState(c.state := opened, t) and ElapsedTime(t+10) and Door(c) = opened 

then closeDoor(c) and c.state := closing 

Zustandsüberführungstabelle zur Darstellung des Quadrupels 

(StimulierendesEreignis, AktuellerZustand, Aktion, Neuer Zustand) 

durch Angabe von NF2-Tabellen z.B. geordnet nach Ereignissen oder aktuellen Zuständen 

Stimulus Aktueller Zustand Aktion Neuer Zustand 

... .... ... ... 

Manchmal sind diese Tabellen zu komplex, z.B. falls keine Zustandsüberführungen stattfinden. Dann lassen wir 

die letzte Spalte weg. (Oft wird dies dann durch Entscheidungstabellen bzw. -bäume dargestellt. 

SSA: Spezifikation des zustandslosen Paternosters 

(e) Zustandstransitionsdiagramme 

nach Harel 

mit Zuständen und Transitionen der Form 

Ereignis-Ausdruck [Wächterausdruck] / Aktion-Ausdruck 

Ereignisse sind: 

benannte Ereignisse, 

Ereignisse, die durch Veränderung von Parametern aktiviert werden 

temporale Ereignisse 

Zustände können auch hierarchisch geschachtelt sein, parallel ablaufen, eine Geschichte darstellen, als intiale 

Zustände gekennzeichnet werden


StateCharts sind spezielle ASM mit benannten Zuständen 

können auch dargestellt werden durch Petri-Netz-ASM: 

if Cond(prePlaces) then Updates(postPlaces) 

where Updates(postPlaces) = a set of function updates 

ECA-Spezifikationen (Trigger) sind spezielle Überführungsfunktionen und werden angewandt zur 

Pflege der Integrität 

Bereitstellung von Handlungen 

Monitoring 

Pflege von Hilfsdaten,insbesondere im Cache 

Vereinfachung der Anwendungsentwicklung 

Trigger besitzen einen Definitionsrahmen 

Aktivierungsbedingung 

Aktivierungszeit: immediate oder deferred 

Aktivierungserzwingung: mit before oder per default im after 

Granularität: auf Tupelniveau oder auf Anweisungsniveau 

Konfliklösung zwischen Triggern: durch Auflösung für eine Gruppe von Triggern oder durch Erzeugung 

eines Ausführungsplanes zur geordneten Konfliklösung 

Auswirkungen aufgrund von Integritätsbedingungen: no action, restrict, cascade, set null 

set default 

The four basic event triggering types: 

Timing 

Beginning 

End 

Point of concern State State entrance event State exit event 

Transformation Transformation start event Transformation end event 

(f) Verhaltenssemantik 

Spezielle Annahmen: 

Atomare Zustände: die Zwischenzustände einer Transition werden nicht berücksichtigt 

Erreichbarkeit: jede Transition kann unter gewissen Umständen benutzbar sein 

Isolation: unabhängig von anderen ablaufenden Zustandsveränderungen 

Dauerhaftigkeit: 

Spezielle Zustände 

Wartezustand 

Aktiver Zustand zur Ausführung 

(*) mit deferred response Semantik oder 

(*) mit forced termination Semantik wobei


global forced termination Semantik 

oder 

local termination Semantik Optionen sind. 

Unterschiedliche Semantiken bei Triggering: 

Logische Unmöglichkeit 

Physische Unmöglichkeit 

Ignorierung von Kombinationen 

Gehemmte Kombination 

Unbekannte Effekte 

Bei parallelen Auftreten des gleichen Ereignisses für einen Zustand: Unterscheidung in 

Schritt-Semantik: alle ausführbaren Transitionen feuern 

Einfache-Transitions-Semantik: es wird eine ausführbare Transition ausgewählt 

Bei Verarbeitung von Listen von Aktionen 

Schritt-Semantik meist default 

Parallele Ausführung 

Aktionen, die als Ereignis im nächsten Schritt auftreten erlauben eine Zusammenführung in einem Superschritt. 

Es kann sowohl eine 

ereignisgesteuerte Abarbeitung als auch eine 

zeitpunktgesteuerte Abarbeitung erfolgen. 

(g) Erweiterungen 

Wieringa Part VI 

Postmodern Structured Analysis 

Statemate 

UML 

Not Yet Another Method (NYAM)


3.1 Die Algebra des erweiterten Entity-Relationship-Modelles 

3.1.1 Spezifikationsrahmen für die Algebra 

Alle Funktionen basieren auf einer entsprechenden Algebra, die zum einem Elementar-Operationen bereitstellt und 

zum anderen die Konstruktion von komplexeren Operationen auf der Grundlage vorhandener Operationen ermöglicht. 

Wir erlauben eine komplexere Strukturierung von Typen. Deshalb verallgemeinern wir für die Definition von 

Operationen Teilstrukturen und Vergleiche: 

Teilstrukturen von Strukturen und Typen sind mit folgenden Operationen definiert: 

Die Definition von Teilstrukturen basiert auf der Ordnung ≼, die als kleinste binäre Relation über der 

Menge S aller Strukturen definiert mit folgenden Eigenschaften: 

• λ ≼ X für jedes X ∈ S; 

• A(A 1 , ...., A n ) ≼ B(B 1 , ..., B n ) falls für alle i , 1 ≤ i ≤ n A i ≼ B i gilt; 

• A{A 1 } ≼ A{B 1 } falls A 1 ≼ B 1 gilt. 

Die Vereinigung Y ⊔ X Z , der Durchschnitt Y ⊓ X Z und die Differenz Y \ X Z sind dann für 

Strukturen X und deren Teilstrukturen Y, Z wie folgt induktiv definiert: 

• falls Y ≼ Z gilt auch Y ⊔ X Z = Z , sowie Y ⊓ X Z = Y , Z \ X λ = Z und Z \ X Y = λ; 

• falls X = A{B}ß, , Y = A{C}, Z = A{D} dann gilt auch Y ◦ X Z = A{C ◦ B D} für 

◦ ∈ {⊔, ⊓}; 

• falls X = A{B} , Y = A{C} , Z = A{D} , Z ⋠ Y dann gilt auch Z \ X Y = A{D ◦ B X} ; 

• falls X = (A(A 1 , ..., A n ) , Y = A(B 1 , ..., B n ) , Z = (C 1 , ..., C n ) dann gilt auch 

A(B 1 ◦ A1 C 1 , ..., B n ◦ An C n ) für ◦ ∈ {⊓, ⊔, \}. 

Die Struktur X wird als Kontext für die Operationen benötigt. 

Prädikate: Gegeben sei ein Typ X. Ein Basisprädikat α vom Typ X ist ein Ausdruck der Form YΘa oder der Form 

Y ◦ C für Y ≼ X , a ∈ dom(Y) , ◦ ∈ {∈, ∉} , C ⊆ dom(Y) und alle Vergleichsprädikate Θ, die über Y 

definiert sind (Für viele Typen sind dies {=, ≠, , ≤, ≥}.). 

Ein Objekt o vom Typ X erfüllt YΘa, falls aΘo| Y für die Einschränkung von o auf Y gilt. 

Ein Objekt o vom Typ X erfüllt Y ◦ C, falls o| Y ◦ C für die Einschränkung von o auf Y gilt. 

Prädikate sind induktiv definiert: 

Basisprädikate sind Prädikate. 

Sind α and β Prädikate, dann sind es auch α ∧ β, α ∨ β und ¬α . 

Ein Objekt o erfüllt das Prädikat α, falls dies entsprechend der Definition von α gilt. Damit definieren wir 

ι({o}) = 

{ {o} falls o das Prädikat α erfüllt 

∅ 

andernfalls 

Erfüllt ein Objekt o das Prädikat α, dann 

Ersetzungsfamilie: Eine Ersetzungsfamilie γ = {(o, R Co )} vom Typ R ist eine Menge bestehend aus einem Paar 

von Objekten und Klassen vom Typ R. Eine Ersetzungsfamilie beschreibt für Objekte vom Typ R jeweils eine 

Klasse von Objekten, durch die dieses Objekt ersetzt wird. 

Definitionsrahmen der strukturellen Rekursion: Durch strukturelle Rekursion wird ein allgemeiner Rahmen zur 

Definition von Funktionen bereitgestellt. 

Gegeben seien Typen T, T ′ , Kollektionen T C vom Typ T, die Funktionen ∪ T (verallgemeinerte Vereinigung), 

∩ T (verallgemeinerter Durchschnitt) und die leere Kollektion ∅ T von T. 

Weiterhin seien für einen Typ T ′ ein Wert h 0 ∈ dom(T ′ ) und Funktionen 

h 1 : T → T ′ h 2 : T ′ × T ′ → T ′ gegeben. Dann definieren wir 

srec h0 ,h 1 ,h 2 

(∅ T ) = h 0 

Mod IS


srec h0 ,h 1 ,h 2 

(|{|s|}|) = h 1 (s) für einelementige Kollektionen |{|s|}| 

srec h0 ,h 1 ,h 2 

(T C 1 

∪ T T C 2 

) = h 2 (srec h0 ,h 1 ,h 2 

(T C 1 

), srec h0 ,h 1 ,h 2 

(T C 2 

)) 

falls T C 1 

∩ T T C 2 

= ∅ T . 

Gewöhnlich wird eine solche mathematische Definition weggelassen. Wir sind jedoch an einer Datenbankentwicklung 

mit nachvollziehbaren Eigenschaften interessiert. 

3.1.2 Die HERM-Algebra als Verallgemeineurng der relationalen Algebra (mengenbasierte Form) 

Die Referenzsemantik für HERM-Strukturen führt auf eine verallgemeinerte Codasyl-Algebra. Dazu existieren 

allerdings nur sehr wenige Arbeiten aus den 80er Jahren. 

Die Algebra des erweiterten ER-Modelles ist eine Verallgemeinerung und Erweiterung der relationalen Algebra. 

Demzufolge sind die Elementaroperationen auf die gleiche Art formulierbar: 

Typ-erhaltende Operationen führen zu Klassen vom gleichen Typ. 

Mengen-Operationen: Es seien R C 1 

und R C 2 

Klassen vom Typ R. Dann können wir folgende Operationen 

definieren: 

Vereinigung: R C 1 

∪ R C 2 

= {o | o ∈ R C 1 

∨ o ∈ R C 2 

} 

(z.B. mit srec h0 ,h 1 ,h 2 

und h 0 ((∅, ∅)) = ∅, 

h 1 (({o}, {o})) = {o} und h 2 (M 1 , M 2 ) = M 1 ∪ M 2 

d.h. srec h0 ,h 1 ,h 2 

((C 11 , C 21 ) ⊔ pair (C 12 , C 22 )) = 

srec h0 ,h 1 ,h 2 

((C 11 , C 21 )) ∪ srec h0 ,h 1 ,h 2 

((C 12 , C 22 )) 

wobei (C 11 , C 21 ) ⊓ pair (C 11 , C 21 ) = ∅ pair genau dann gilt, wenn 

C 11 ∩ C 12 = ∅ und C 21 ∩ C 22 = ∅ gelten 2 . 

Durchschnitt: R C 1 

∩ R C 2 

= {o | o ∈ R C 1 

∧ o ∈ R C 2 

} 

SSA: Wie müßte man diese Operation über strukturelle Rekursion definieren? 

Differenz: R C 1 

\ R C 2 

= {o | o ∈ R C 1 

∧ o ∉ R C 2 

} 

SSA: Wie müßte man diese Operation über strukturelle Rekursion definieren? 

Auswahl von Objekten aus einer Klasse: Gegeben sei ein Prädikat α über R. 

Die Selektion σ α (R C ) wird induktiv eingeführt durch strukturelle Rekursion mit ∅ T , ⊔ R , ⊓ R und 

σ α (R C ) = srec ∅,ι,⊔R (R C ) bzw. in der aufgelösten Form: 

• σ α (∅) = ∅ 

• σ α ({o}) = ι({o}) 

• σ α (R C 1 

⊔ R R C 2 

) = σ α (R C 1 

) ⊔ R σ α (R C 2 

) falls R C 1 

⊓ R R C 2 

= ∅ gilt. 

Wir nutzen eine andere Einführung als die viel verwendete doppelte Induktion wegen der komplexeren 

Teilstrukturierung der Typen. Die beiden Definitionen sind jedoch äquivalent. 

Abgeleitete Elementaroperationen sind die Modifikationsoperationen der Datenbanksysteme: 

Einfügen von Elementen: Die insert-Operation Insert(R C , o) ist durch die Vereinigung R C ∪ {o} 

von Mengen für Klassen R C und Objekte o vom gleichen Typ R beschreibbar. 

Streichen von Elementen: Die delete-Operation Delete(R C , o) ist durch die Differenz R C \{o} von 

Mengen für Klassen R C und Objekte o vom gleichen Typ R definierbar. Analog kann man auch das 

Streichen von Mengen delete(R C , R C′ ) einführen. 

Update von Elementen: Die Modifikation Update(R C , α, γ) von Klassen R C ist für Prädikate α und 

Ersetzungsfamilien γ = {(o, R C o 

)} ist definiert durch die Menge 

2 Diese Bedingungen sind die strengsten. Sie nicht nicht notwendigerweise zu fordern, weil ∪ für beliebige Mengen bereits zur Elimination 

von Doppelungen von Elementen führt 

Mod IS


R C \ σ α (R C ) ∪ 

⋃ 

o∈σ α (R C ) 

R C o 

. 

Eine oft verwendete Definition basiert auf dem Ausdruck R C \ σ α (R C ) ∪ R C′ . Damit wird jedoch ein 

anderer Effekt erzielt. Gilt z.B. σ α (R C ) = ∅ und R C′ ≠ ∅, dann wird die ursprüngliche Intention 

verloren. Dieser Einführung liegt jedoch die oft praktizierte Ersetzung von Update(R C , o, {o ′ }) 

durch die Folge Delete(R C , o); InsertUpdate(R C , o ′ ) zugrunde. 

Typ-bildende Operationen erzeugen neue Klassen und Typen. Gegeben seien die Typen R und S und entsprechende 

Klassen R C und S C . 

Kartesisches Produkt: Die Klasse R C × S C = {(o, o ′ ) | o ∈ R C , o ′ ∈ S C } ist definiert über dem Typ 

(R, S). 

Das Kartesische Produkt kann auch in entfalteter Form über eine Konkatenation der Objekte gebildet 

werden. 

srec ∅,×,∪ 

Projektion: Es sei R 1 ein Teiltyp von R. Die Projektion Π R1 (R C ) von R C auf R 1 durch eine Reduktion aller 

Objekte von R C auf den Typ R 1 . 

Mitunter wird auch die Notation R C [R 1 ] anstelle von Π R1 (R C ) verwendet. 

srec ∅,πX ,∪ 

Schachtelung: Es sei R ′ ein Element von R. Dann wird die Schachtelung ν R ′(R C ) von R C entlang von R ′ 

definiert als Klasse über dem Typ T = (R \ R ′ ) ⊔ R {R ′ } mit der Menge von Objekten 

{ o ∈ Dom(T) | ∃o ′ ∈ R C : o[R \ R R ′ ] = o ′ [R \ R R ′ ] 

∧ o(R ′ ) = { o ′′ [R ′ ] | o ′′ ∈ R C ∧ o ′ [R \ R X] = t ′′ [R \ R R ′ ]}}. 

Entschachtelung: Es sei R ′ ein Mengenelement von R. Die Entschachtelung µ ′ R (RC ) einer Klasse definiert 

einen neuen Typen T = (R \ R {R ′ }) ◦ R ′ für die Konkatenation ◦ und die neue Klasse 

{ o ∈ Dom(T) | ∃o ′ ∈ R C : o[R \ R {R ′ }] = o ′ [R \ R {R ′ }] ∧ o[X] ∈ o ′ (X)}. 

Potenzmenge: Die Potenzmenge P(R C ) = {M|M ⊆ R C } ist eine geschachtelte Klasse über dem Typ {R} . 

Umbenennung: Gegeben sei ein Typ R. Es sei φ eine bijektive Abbildung auf der Markierungsmenge L mit 

der Einschränkung, daß für Namen A, B in R mit φ(A) = B auch dom(A) = dom(B) gelten muß. Die 

Umbenennung von R mit φ bildet die Klasse R C auf eine Klasse ρ φ (R C ) = φ(R C ) über φ(R) ab. 

Verbund: Der Verbund R C 1 

S C 2 

ist definiert durch den Ausdruck Π R⊔S (σ R⊓S∈ΠR⊓S (S C 2) (RC 1 

) × S C 2 

. 

Der Verbund ist mit srec ∅,,∪ gegeben wobei der elementweise Verbund definiert ist für X Y durch 

X Y ({o 1 }, {o 2 }) = 

{ 

o1 X Y o 2 falls π X (o 1 ) = π Y (o 2 ) 

λ 


Omega-Operation: Entfaltung von Relationship-Typen (als bereits definierte Operation durch die Teilstrukturbildung 

mit der Projektion) 

Ω ID (R) = R × ID(R 1 ) × .... × ID(R n ) für die Komponenten von R 

Aggregationsoperationen werden in OLAP-Anwendungen vielfältig angewandt. Eine Aggregationsoperation 

ist definiert als Familie F = {f 0 , ...., f k , ..., f ω } mit Funktionen f k : Bag k → Num , die Multimengen 

mit k Elementen vom Typ T auf einen numerischen Datentyp Num abbilden. Wir lassen nur solche Typen 

zu, die ein minimales und ein maximales Element in dom(T) besitzen. Es müssen zwei Eigenschaften 

bezüglich der Ordnung auf dom(T) erfüllt sein: 

• Es gelten die Gleichungen f k (min, ...., min) = min und f k (max, ..., max) = max für die minimalen 

und maximalen Elemente in dom(T). 

• Die Funktionen sind monoton bzgl. der Ordnung von dom(T). 

Mod IS


Da Nullwerte explizit zugelassen sind, benutzen wir zwei Hilfsfunktionen für die strukturelle Rekursion: 

{ 

h 0 0 falls s = NULL 

f (s) = 

f (s) falls s ≠ NULL 

{ 

h undef 

undef falls s = NULL 

f (s) = 

f (s) falls s ≠ NULL . 

Wir können nun die folgenden üblichen Aggregationsfunktionen einführen: 

Summierung in unterschiedlichen Varianten abhängig von der Behandlung von Nullwerten: 

• Summierung für Klassen ohne Nullwerte: 

sum = srec 0,Id,+ ; 

• Summierung für Klassen mit Nullwerten, die durch die 0 ersetzt werden: 

sum null 

0 = srec 0,h 0 

Id ,+ ; 

• Summierung für Klassen mit Nullwerten, die durch die undef ersetzt werden: 

sum null 

undef = srec 0,h undef 

Id ,+ . 

Üblich ist die Anwendung der zweiten Option. 

Zählen der Objekte je nach Behandlung der Nullwerte: 

• Für Klassen ohne Nullwerte: count = srec 0,1,+ ; 

• Für Klassen mit Nullwerten: count null 

1 = srec 0,h 0 

1 ,+ ; 

• Alternativ für Klassen mit Nullwerten: count null 

undef = 

srec 0,h undef 

1 ,+ . 

Genutzt wird oft die zweite Option. 

Bildung der maximalen bzw. minimalen Werte in Abhängigkeit von den Ordnungen für NULL: 

• Die leere Menge erlaubt keine Bestimmung von minimalen bzw. maximalen Werten: 

• max NULL = srec NULL,Id,max bzw. min NULL = srec NULL,Id,min 

• max undef = srec undef,Id,max bzw. min undef = srec undef,Id,min 

Diese Funktionen hängen davon ab, wie die Nullwerte in dom(T) eingeordnet werden. 

Bildung des Durchschnittes: Die Durchschnittsbildung ist eine komplexere Funktion. Es gibt dafür 

eine Reihe von Möglichkeiten: 

(++) 

sum 

count 

(SQL!?) sumnull 0 

count 

(??) 

(+!) 

sum 

count null 

1 

sum null 

0 

count null 

1 

(??) 

(??) 

sum 

count null 

undef 

sum null 

0 

count null 

undef 

(+?!) sumnull undef 

(??) sumnull undef 

sum null 

undef 

count count null (++) 

1 

count null 

undef 

SQL benutzt eine Variante, die nicht die intuitivste ist. Wir präferieren in der HERM-Algebra die 

mit “+” annotierten Varianten für den Fall von Klassen mit Nullwerten. Die Funktionen avg null 

0,1 und 

avg null 

undef werden dabei der SQL-Form avgnull vorgezogen. 

Die algebraischen Operationen können zur Bildung von komplexeren Ausdrücken benutzt werden. Eine HERM- 

Anfrage ist ein (komplexer) Ausdruck in der HERM-Algebra. 

Anmerkung: Definition der update-Operation bei Kandzia/Klein anders formuliert (dort als Modifikationsoperation) 

Theorem 1 Die HERM-Algebra ist eine definitorische Erweiterung der relationalen Algebra. 

Corollary 1 Die HERM-Algebra ist relational vollständig. 

Damit kann mit einer HERM-Algebra alles ausgedrückt werden, was mit einer relationalen Algebra dargestellt werden 

kann. 

Mod IS


3.1.3 Erweiterte HERM-Spezifikation von Operationen 

Wir erweitern die HERM-Algebra um die Spezifikation einer Umgebung (Sicht), Ausführungsbedingungen als Vorbedingung 

und Nachbedingung und Nachfolgeoperationen. In diesem Fall erhalten wir einen allgemeinen Definitionsrahmen 

der Form: 

Operation ϕ 

[Sicht: < Sichten Name> ] 

[Vorbedingung: < Aktivierungs Bedingung >] 

[Aktivierte Operation: < Spezifikation >] 

[Nachbedingung: < Akzeptanz Bedingung >] 

[Erzwingene Operation: < Operation, Bedingung>] 

3.1.4 Spezifikation von Programmen 

Beachtung zweier Besonderheiten: 

Parallelverarbeitung von Programmen 

dazu erforderlich 

Semantik paralleler Ausführung 

Verwaltung von Konsistenzanforderungen bei der Parallelverarbeitung 

Modell zur Bewältigung von Konflikten 

Abstraktion von Programmteilen, z.B. durch Blockstruktur 

i.a. als Transaktionssemantik (spezielle Form der Konsistenzverwaltung) 

do temporary(TA 1 , db); 

if TA 1 (db) |= Σ then do permanently(TA 1 , db) else undo(TA 1 , db); 

mit vielen Erweiterungsmechanismen 

Multilevel TA-Modelle gestatten eine Verschachtelung von Transaktionen mit Teiltransaktionen, die wiederum 

der Transaktionsemantik genügen. 

TA 1 supplemented by TA 2 : 

do temporary(TA 1 , db); 

if TA 1 (db) |= Σ then do permanently(TA 1 , db) else 

begin do temporary(TA 2 , TA 1 (db)); 

if TA 2 (TA 1 (db)) |= Σ then do permanently((TA 1 ; TA 2 ), db) 

else undo((TA 1 ; TA 2 ), db); 

end; 

Diese Form kann auch für die Kompensation von Effekten einer Transaktion genutzt werden, z.B. im Falle 

einer Reisebuchung mit Bestandteilen wie einer Flugbuchung und einer Hotelreservierung zur Rücknahme 

eines Teiles, falls der andere Teil nicht erfolgreich war oder auch zur Ergänzung einer Buchung um 

weitere Elemente falls dies erforderlich ist. 

TA 1 substituted by TA 2 : 

do temporary(TA 1 ); 

if TA 1 (db) |= Σ then do permanently(TA 1 , db) else 

begin undo(TA 1 , db); do temporary(TA 2 , db); 

if TA 2 (db) |= Σ then do permanently(TA 2 , db) else undo(TA 2 , db) 

end; 

Diese Form kann auch für die Kompensation von Effekten einer Transaktion genutzt werden, z.B. im Falle 

einer Reisebuchung mit Bestandteilen wie einer Flugbuchung und einer Hotelreservierung zum Auslösen 

einer Ersatzbuchung. 

Mod IS


Savepoints innerhalb einer Transaktion 

sp1 := create safepoint(); 

sowie zurückfahren bis zu safepoint rollback(sp1) 

Chained Transactions: mit commit-Punkten commit(); innerhalb der Transaktion 

ggf. auch mit recoverable queries der Teiltransaktionen 

Sagas: als eine Kombination von chained transactions und compensations 

ST 1 , CT 1 , ..., ST i , CT i , ..., ST n , CT n 

mit der Semantik: Falls Transaktion ST i zu fehlerhaften Zustand führt, dann wird die Folge 

CT i ,CT i−1 , ..., CT 2 , CT 1 ausgeführt. 

Erweiterte Transaktionsmodelle sind i.a. nicht parallel ausführbar. 

Corollary 2 Alle Programme, die in der HERM-Algebra formuliert sind, können durch Interpretation direkt in relationale 

Programme überführt werden. 

3.1.5 Transformation von HERM-Algebra-Ausdrücken in relationale Algebra 

3.1.6 Die Funktionalität von relationalen Datenbank-Maschinen 

3.1.7 Die Funktionalität von XML-Datenbank-Maschinen 

Mod IS


3.1.8 Visual SQL 

siehe extra tutorial


3.2 Workflow-Spezifikation 

Die Arbeitsvorgänge werden in Einzelschritte zerlegt. Die Einzelschritte werden durch Prozesse verfeinert. Der Zusammenhang 

der Arbeitsvorgänge wird durch verallgemeinerte Transaktionsmodelle dargestellt. In der Datenbank 

verändern Prozesse die Zustände. Deshalb werden die Zustandsveränderungen modelliert. Die Prozesse veranlassen 

legale Transitionen von Zuständen. Darauf aufbauend können die Integritätsbedingungen durch Bedingungen zur 

Ausführung und durch Nachbedingungen für Prozesse dargestellt werden. Integritätsbedingungen, die durch Transitionsbedingungen 

nicht darstellbar sind, werden für Pflegeroutinen aufbereitet. Mit der Prozeßdefinition kann die 

Definition der Semantik abgeleitet werden. Je nach Prozeßmodell wird eine axiomatische, parallele, kausale etc. 

Semantik benutzt. Wir benutzen ein Zustandstransitionsdiagramm zur Darstellung. 

Die Aufgaben- und Prozeßkoordination folgt den Zusammenhängen in den Geschäftprozessen. 

Wir unterscheiden für die Prozesse Retrievaldaten, die als Input für die Prozesse aus der Datenbank dienen, Inputdaten 

der Akteure, Outputdaten zum Zurückschreiben in die Datenbank, Displaydaten zur Darstellung in den Dialogen 

und Begleitdaten, die aus vorhergehenden Prozessen stammen und zur Darstellung der Informationen während 

der Dialogschritte dienen. Damit können Prozesse auch einander beeinflussen und sind nicht nebenwirkungsfrei. 

Damit werden für die Prozesse auch Interaktionsdiagramme und Kohäsionsbeziehungen entwickelt. 

Damit erhalten wir ein allgemeines Workflow-Modell: 

Die drei R’s von Workflow-Modellen sind 

Routen (Szenario) durch einen Ablaufgraph, 

Regeln zur Darstellung der verarbeiteten Information und 

Rollen mit einer Zuordnung zu den handelnden Personen (Akteuren). 

Die drei P’s von Workflow-Modellen sind 

Prozesse als das Kernstück der Spezifikation, 

Politiken und Anwendungsstrategien und 

Praktiken der Anwendung, die spezifische Seiten zum Ausdruck bringen. 

3.2.1 Das Eder-Modell der Aspekte von Workflow-Spezifikationen


3.2.2 Business Process Modelling Notation - BPMN 

BPMI.org. Business Process Modeling Notation Specification. 

dtc/2006-02-01 

http://www.omg.org/technology/documents/spec catalog.htm, 2006. 

meanwhile: BPMN 1.1, BPMN 2.0 

Neben dem Handbook (Eder- und Börger-Artikel) sind die folgenden Arbeiten von Interesse: 

[Wes07]: M. Weske, Business Process Management: 

Concept, language, architecture. Springer, 2007. 

[KST09]: Case study (Conference paper submission and reviewing system) 

Theoretische Grundlagen zu BPMN: [BT08a], [BST09], [BT08b] 

BPMN in Detail 

Business Process Modelling & Notation. 

Yet an Example of a Workflow Diagram. 

A BPMN diagram taken from literature with many problems 

IS ADD


Fallstudie Otto.de: Navigation, Use Cases, Customer Support 

c○T. Hille, Modellierung eines Webshops - Otto. HPI 

IS ADD


IS ADD


IS ADD


IS ADD


IS ADD


c○T. Hille, Modellierung eines Webshops - Otto. HPI 

IS ADD


BPMN Assumptions. 

separation of the specification into workflow process and workflow process instance 

singleton isolatable process instance bound to its token 

inter-process collaboaration only through messages and events 

hidden resource dependences 

swimlanes for different roles of users 

pools for views on process sets 

separation of nodes 

Node = Activity ∪ Event ∪ Gateway 

separation of events 

Event = StartEvent ∪ IntermEvent ∪ EndEvent 

tasks comprehend only some of possible executions 

TaskType = {Service, User, Receive, Send, Script, Manual, Reference, None} 

rigid localisation 

context-sensitiv functions, 

none-incremental semantics, 

goto jumps, token progression may become “arbitrary” 

Resulting Orchestration Problems 

avalanches of side constraints 

exemplification of the Sapir/Whorf syndrome 

B.L. Whorf, Lost generation theories of mind, language, and religion. 

Ann Arbor, Mich., Popular Culture Association, 

University Microfilms International, 1980. 

D. Sapire, General causation, Synthése, 1991, 86, 3, 321–347 

“Principle of linguistic relativity”: actors skilled in a language may not have a (deep) understanding of some concepts of other languages 

The design and development quality depends on main success factors: 

structuring of the process itself, 

culture of people involved, 

skills of actors, and 

process capabilities 

Communication through explicit specification of protocols and services: interprocess communication exclusively 

by messages and links 

Coordination only implicitly by message protocols or links 

typical coordination problems: 

opportunities, obligations, permissions and forbids must intentionally be taken into consideration by the 

modeller 

contracts among parties 

exceptional cases, timeouts 

Cooperation between processes only through messages 

typical cooperation problems: 

Zachman enactment: who, what, when, where, how, why 

rights, obligations and roles 

Data dependencies among processes become a sideway task for the modeller 

IS ADD


Implicit BPMN Assumptions 

Petri net illustration for token flow results in messy problems 

limitations of Petri nets 

negative token with runtime overwriting of semantics of constructs 

token colouring 

token with history transfer for sub-processes 

Process instance duplication for each call of a process with optimisation by elimination of dead paths 

Incorporation of other standards in rather fuzzy way: interchange of messages, SOAP, UDDI, web services, web 

transaction, XML (XPath, XPDL, XSchema, ..), ... 

Concentration on workflow processes leaving out control among process instance and data flow among them 

Partial BPEL transformation with reference to BPEL meaning 

Abbildung von Workflows auf Petri-Netze 

BPMN - Case Study 

Ex.: Paper Submission Review System. 

IS ADD


Pitfalls of the Petri Net Interpretation 

Complexity of formalisation 

IS ADD


BPMN gateway 

Insufficiency of Petri net languages 

e.g. error handling 

Wrong abstraction level 

The Token Problem in the BPMN Standard 

IS ADD


For each uncontrolled Sequence Flow a “Token” will flow from the source object to the target object. 

To facilitate this discussion, we will employ the concept of a “Token” that will traverse the Sequence Flow and pass through 

the Flow Objects in the Process. The behavior of the Process can be described by tracking the path(s) of the Token through the 

Process. A Token will have a unique identity, called a TokenId set, that can be used to distinguish multiple Tokens that may exist 

because of concurrent Process instances or the dividing of the Token for parallel processing within a single Process instance. 

The parallel dividing of a Token creates a lower level of the TokenId set. The set of all levels of TokenId will identify a Token. 

A Start Event generates a Token that must eventually be consumed at an End Event (which may be implicit if not graphically 

displayed). The path of Tokens should be traceable through the network of Sequence Flow, Gateways, and activities within a 

Process. 

If an upstream Inclusive OR produces two out of a possible three Tokens, then a downstream Inclusive OR will synchronize 

those two Tokens and not wait for another Token, even though there are three incoming Sequence Flow (see Figure 9.25). 

Email from a colleague: The most interesting and, in my opinion, advanced paper 

on that is the paper of Frank Pullman and Matthias Weske from BPM’2005 where the 

authors used lambda calculi to derive workflow pattern semantics. The only problem 

they had then was related to OR-JOIN operator (gateway) while it was not possible to 

express memory of the generated tokens. 

Comparing to what you propose I see that Pullman and Weske had problem with 

defining semantics of tokens and this was crucial for the overall workflow patterns 

semantics. 

Therefore I would expect that you in a clear and unambiguous way define semantics of 

tokens and that, in my opinion, would be a real step forward in defining semantics 

of BPMN. 

The Token Problem: Acyclic Case 

The BPMN Standard 1.0: 

All the Tokens that were generated within the Process must be consumed by an End Event before the Process has been completed. 

The Process will be in a running state until all Tokens are consumed. 

When the Inclusive Gateway is used as a Merge, it will wait for (synchronize) all Tokens that have been produced upstream. It 

does not require that all incoming Sequence Flow produce a Token (as the Parallel Gateway does). It requires that all Sequence 

Flow that were actually produced by an upstream (by an Inclusive OR situation, for example). If an upstream Inclusive OR 

produces two out of a possible three Tokens, then a downstream Inclusive OR will synchronize those two Tokens and not wait 

for another Token, even though there are three incoming Sequence Flow (see Figure 9.25). 

The Token Problem: Cyclic Case 

Be careful: Underspecified, confusing and difficult 

The BPMN Standard 1.0: Incoming Sequence Flow that have a source that is a downstream activity (that is, is part of a loop) will be 

treated differently than those that have an upstream source. 

IS ADD


Mapping of BPMN to Conceptual Constructs 

Processes to programs of transactions 

Activities to generalised transactions 

Events to observer/controller in the data intensive approach instead of active event 

Gateways to program constructs 

Exceptions 

Pools, swimlanes 

Supporting structures 

• Collaboration, orchestration 

• Data consumption 

• Data production 

3.2.3 Die Formalisierung von BPMN 

Diese Ausarbeitungen sind Teil eine Kooperationsprojektes mit 

Egon Börger Università di Pisa, Dipartimento di Informatica, I-56125 Pisa, Italy 

im Rahmen eines Projektes, das durch die 

Diese Projekt wurde fortgeführt von 

Humboldt-Stiftung 

mit dem Humboldt-Forschungspreis, 

der 2007 an Egon Börger verliehen wurde, 

gefördert wird. 

Egon Börger und Ove Sörensen zur Formalisierung von BPMN 2.0. 

Erstaunlicherweise war die gefundene BPMN 1.0 -Formalisierung ausreichend, um auch BPMN 2.0 zu formalisieren. 

Die BPMN 2.0 Formalisierung wurde im Handbook in Kapitel 8 dargestellt. 

The Pisa-Kiel BPMN-ASM Project 

ASM semantics: extensible semantical framework for business process modelling notations 

Guiding understanding of BPMN constructs based on ASM 

Proposals for 

improvement of BPMN 

rigid semantics of all BPMN concepts 

IS ADD


treatment of all underspecified, overspecified, ... concepts 

Systematic framework based on separate behavior from scheduling issues 

Description of behavior directly in business process terms 

Case study for complex business processes 

e.g., conference paper submission and reviewing system, 

conference management 

(muComs ∪ BYU ⊇ EasyChair ∪ ....) 

Principles. 

Separation of concern: data space, computation space, collaboration space, control space, user space, ... 

e.g., scheduler, abstract machine 

Abstraction and refinement: level of detail (general principles, constructs, schema, execution, instance) depending 

on current scope 

Hierarchies and inheritance: within type system, machines, ... 

Components and architectures: compositionality, application architecture, SW/HW architecture 

State and evolution: schemata based on a language, runs based on state evolution rules 

Reuse and genericity: pattern, generation, parametrisation 

Principles: Nice to Have. 

Local restriction of computation to sub-state and rule subset 

Stepwise computation e.g. based on computation pattern with general semantics 

Concurrent computation without deadlocks and explicit collaboration 

Collaborating machines with their own computation space, explicit exchange, restricted dependence of internal 

computation from outside world 

Explicit assumptions with understanding of the impact 

Orthogonality of concepts for easy construction and separation of concern as a basis for the principle of compositionality 

Foundations of BPMN Semantics. 

Operational semantics by reduction rules for execution of the language 

opportunity: constructing an interpreter 

☼ 

Axiomatic semantics by correctness assertions that describe how to draw conclusions about the input/output interface 

of a program 

opportunity: verifying a program 

☹ 

IS ADD


Denotational semantics by a valuation function that maps a program into a mathematical object which is considered 

as its meaning 

opportunity: reasoning about its properties 

☹ 

Transformational semantics based on mappings and semantics of the target machine 

requires thorough knowledge 

on mappings, their dependencies and interactions, and 

on target machine 

 

Specifics of the ASM Approach. 

State model based on static and dynamic functions 

function/relation/location 

basic 

derived 

static 

non-updatable 

by any agent 

controlled shared 

in (monitored) 

non-updatable 

by agent 

controlled 

updatable 

by agent 

dynamic 

shared (interaction) 

updatable 

by agent 

out 

updatable 

by agent 

indirectly 

monitored controlled indirectly indirectly 

shared 

Abbildung 4: The Kinds of Internal Functions for Agent ASMs 

All rules fire in parallel if they are enabled 

parallel and continuous execution 

Conflicting updates are resolved by disabling some of rules that can be fired 

Locations as an abstraction of storage 

Turing/Church hypothesis with scaling abstraction 

Fireable workflow transition. 

at node for its execution: 

WORKFLOWTRANSITIONINTERPRETER = 

let node = select Node ({n | n ∈ Node and Enabled(n)}) 

let rule = select WorkflowTransition ({r | 

r ∈ WorkflowTransition and Fireable(r, node)}) 

rule 

Separation of behaviour from scheduling 

Execution of all firable instance nodes 

IS ADD


WORKFLOWTRANSITION(node) = 

if EventCond(node) and CtlCond(node) 

and DataCond(node) and ResourceCond(node) then 

DATAOP(node) 

CTLOP(node) 

EVENTOP(node) 

RESOURCEOP(node) 

AND-Split Gateway (Fork) 

in : ✲t 

CtlCond 

If (Data|Event)Cond . 

❄ ✲ 

. . . 

CONSUME 

+ 

ASSIGNOP 

PRODUCE 

ALL 

out j : ✲t j 

OutCond j 

. . . 

✲ 

ANDSPLITGATETRANSITION(node) = WORKFLOWTRANSITION(node) 

where 

CtlCond(node) = Enabled(in) 

CTLOP(node) = 

let t = firingToken(in) 

CONSUME(t, in) 

PRODUCEALL({(andSplitToken(t, o), o) | o ∈ outArc(node)}) 

DATAOP(node) = //performed for each selected gate 

forall o ∈ outArc(node) forall i ∈ assignments(o) ASSIGN(to i , from i ) 

Thus: Separation of rule schemes from concrete rules 

AND-Join Gateway 


✲❄ 

. . . 

in i : ✲t i 

CtlCond i 

. . . 

CONSUME 

ALL 

+ 

PRODUCE 

ASSIGNOP 

✲ 

out : ✲t 

OutCond 

ANDJOINGATETRANSITION(node) = WORKFLOWTRANSITION(node) 

where 

CtlCond(node) = forall in ∈ inArc(node) Enabled(in) 

CTLOP(node) = 

let [in 1 , . . . , in n ] = inArc(node) 

IS ADD


let [t 1 , . . . , t n ] = firingToken(inArc(node)) 

CONSUMEALL({(t j , in j )) | 1 ≤ j ≤ n}) 

PRODUCE(andJoinToken({t 1 , . . . , t n }), out) 

DATAOP(node) = forall i ∈ assignments(out) ASSIGN(to i , from i ) 

Be careful: BPMN assumes strict local consideration! 

Our solution to the token problem 

Controller structures based on the concept of the program counter 

new(token) of process instance, derivable owner 

token at location of control flow, i.e. arc 

multiset of token at location 

returnProcess(token) 

frames of execution handling: 

• (ASM BPMN) rule 

• consumed token, 

• produced token, 

• conditions applicable, 

• methods applied, 

• locals 

invoke or scheduler frames 

supporting infrastructure for retransmission of potential enactment 

Control Flow Models. 

Implicit (defined by the language) or explicit (e.g. goto) control: based on structuring (and the 

corresponding compositional semantics), exchange interfaces (statements, messages, data, events) 

and subroutines 

Control of subroutines: call/return structures, recursive?, call rules, completion of subroutines, eager/lazy 

execution, transfer of control, uniqueness of control, current instruction and environment 

pointer (CIP, CEP); 

implicit data control by indirect transfer, binding, naming, association and reference environments, 

aliases, sharing conceptions; static/dynamic visibility and lifespan conceptions; block structures ... 

TA’s; 

local variables and environments, parameters, stack/heap support structures 

shared/monitored/controlled/out parameters, (direct) call by name/reference/value/result/value 

result/constant value 

Control of collaboration cases: only by orchestration 

control flow on parallelism: control dependence analysis, executing multiple flows of control simultaneously, 

and speculative execution 

BPMN Normal Forms. 

Splits only at the gates 

Entry and leave for a process only at start and end events 

Activities can be separated into 

IS ADD


Activity = Task ∪ SubProcess ∪ IterProc 

IterProc = Loop ∪ MultiInstance ∪ AdHoc 

Standard looping only 

Tracking of token 

catch environment for local control token 

Prenex normal form 

also for ad-hoc processes 

Communication normal form: explicit communication only by links and messages 

Exception normal form (????) 

ASM BPMN Assumptions. 

Token are assigned to arcs in the process diagrams 

token : Arc → Multiset(Token) 

token are identifiable 

Execution of workflow steps is reflected at nodes 

Enabled(in, t) = (| token(in, t) |≥ qty(in, t)) 

token enabled execution 

Support and auxiliary functions 

CONSUME(t, in) = DELETE(t, inQty(in), token(in)) 

PRODUCE(t, out) = INSERT(t, outQty(out), token(out)) 

CONSUMEALL(X) = forall x ∈ X CONSUME(x) 

PRODUCEALL(Y) = forall y ∈ Y PRODUCE(y) 

Context-sensitive dynamic functions 

ASM Rules. 

PRODUCESYNC(t, in) = INSERT(t, syncToken(in)) 

CONSUMESYNC(t, in) = DELETE(t, syncToken(in)) 

PRODUCESYNCALL(Y) = forall y ∈ Y PRODUCESYNC(y) 

CONSUMESYNCALL(X) = forall x ∈ X CONSUMESYNC(x) 

Split gate transition rules 

PRODUCESYNCALL({(t.o, i) | i ∈ AllJoinArc(o), o ∈ O}) 

CONSUMESYNCALL({(t, i) | i ∈ AllJoinArc(o) forsome o ∈ O}) 

Join gate transition rules 

PRODUCESYNCALL({(joinToken(t 1 , . . . , t n ), in) | in ∈ AllJoinArc(out)}) 

CONSUMESYNCALL({(t i , in) | in ∈ AllJoinArc(out)}) 

Synchronization counterpart 

CtlCondSync(node, I) = 

forall i ∈ I syncToken(i) ≠ ∅ and 

forall i ∈ inArc(node) \ I syncToken(i) = ∅ 

IS ADD


Separation of Concern. 

The Concern Space of BPMN: Control space, abstraction, dimensions, user 

“Concern space” of systems: what concerns are present, how they relate, and how they can be used for modularization. 

http://researchweb.watson.ibm.com/hyperspace/ConcernSpaces.htm 

Encapsulation of all kinds of concerns in a 

software system, simultaneously. 

Overlapping and interacting concerns. 

On-demand remodularization. 

Multiple, arbitrary kinds (dimensions) of concerns. 

Separation according to these concerns simultaneously. 

Overlapping or interacting concerns. 

Connection of concerns. 

Separation of Different Concerns. 

For design and analysis of business processes it turned out to be crucial that the ASM method supports to first 

explicitly separate and then smoothly combine the realization of different concerns, based upon appropriate abstractions 

supporting this form of modularization. We list some of the main separation principles, which we have used with 

advantage for the definition of the execution semantics for BPMN by ASMs. 

*. 

Separation Principle 1. This principle is about the separation of behavior from scheduling. 

*. 

Separation Principle 2. The second principle is about the separation of orthogonal constructs. 

*. 

Separation Principle 3. The third principle is the separation of different model dimensions like control, events, data 

and resources. S 

*. 

Separation Principle 4. The fourth principle, whose adoption helps to reduce the description size of abstract models, 

IS ADD


is the separation of rule schemes and concrete rules, where the concrete rules may also be specialized rule schemes. 

*. 

Separation Principle 5. The fifth example is about the separation of design, experimental validation and mathematical 

verification of models and their properties. 

The Concern Space of BPMN 

Separation of behavior from scheduling based on explicit schedulers 

Separation of orthogonal constructs beyond of what BPMN envisioned 

TaskType = {Service, User, Receive, Send, Script, Manual, Reference, None} 

Separation of different model dimensions like control, events, data and resources 

Separation of design, experimental validation and mathematical verification 

see coming demo 

Separation of rule schemes and concrete rules e.g. by generalising rule schemes to generic ones or patterns 

GATETRANSITIONPATTERN(node) = 

let I = select Consume (node) 

let O = select Produce (node) in 

where 

WORKFLOWTRANSITION(node, I, O) 

CtlCond(node, I) = (I ≠ ∅ and forall in ∈ I Enabled(in)) 

CTLOP(node, I, O) = 

PRODUCEALL({(patternToken(firingToken(I), o), o) | o ∈ O}) 

CONSUMEALL({(t i , in i ) | 1 ≤ i ≤ n}) where 

[t 1 , . . . , t n ] = firingToken(I) 

[in 1 , . . . , in n ] = I 

ASSIGNOP(node, O) = forall o ∈ O forall a ∈ assignments(o) ASSIGN(to a , from a ) 

Separation of responsibilities, rights and roles of users 

Illustration of the Separation Principle: OR-Gateways 

Separation of send-collect for OR-gates as either global conception or (better) local subscribing OR-joins of runtime 

behaviour of publishing OR-splits 

Clustering of cycles as a good practice 

Tokenisation of cycle counters through Tokensets as a facility to model associated token 

separation of pathes according to their effect 

IS ADD


Abbildung 5: Cyclic OR splits and joins with separation of cycle and remaining process 

Abbildung 6: Necessity of delayed semantics for splits and joins 

IS ADD


Completion of semantics for meaning of synchronisation, cycles as a graph extension with specific stratification or 

encapsulation structures 

Fitch Structures for Diagrams 

Separation of send-collect for OR-gates as either global conception or (better) local subscribing OR-joins of 

runtime behaviour of publishing OR-splits 

Abbildung 7: Fitch Structures: Cyclic OR splits and joins with separation of cycle and remaining process 

The ‘vicious cycle’ example: explicit treatment of cycles, tokensets as an association tool, encapsulation of cycle 

pathes, separation of send-collect synchronisation from cycle synchronisation 

The Token Problem: Cyclic Case 

IS ADD


IS ADD




The Token Problem: Vicious Cycle 



Lessons for Cyclic Diagrams: Level of support depends on diagram 

Acyclic diagrams without OR-splits and joins: local execution with local rules 

Acyclic diagrams with OR-splits and joins: local execution with send-collect information enrichment at join nodes 

Cyclic diagrams with XOR-entry/leave: separation of inside cycle flow and outside cycle flow 

Stratified cyclic diagrams with OR/AND-entry/leave: explicit extension of diagrams and completion of underspecified 

semantics 

Non-stratified cyclic diagrams led to many problems, e.g., deadlocks 

Orthogonal Concerns: Co-design, coexistence and co-evolution of specifications 

Database support: computation in collaboration, shared resources, modification-in-place ∨ -in-private 

Transactional systems: short-term, long-term, collaboration transactions 

Security: integrity, availability, confidentiality 

also privacy 

History: runtime, log, revival (recovery, restart, session), 

Context: concurrency, infrastructure, architecture, 

QoS, SLA: quality of use, external/internal quality 

Collaboration: communication, cooperation, coordination 

or simply orchestration, syndication 

Actors, users: shared usage beyond message exchange 

ASM: Power of Modelling. 

Abstract description of behaviour of processes through general ASM rules 

Nodes in BPMN diagrams defined by their ASM rules 

Control state transformation by control state ASM functions and control state rules 

Separation of concern as lean ASM model 

Orthogonal design of scheduler, rule, separatable conceptions, process-subprocess history and management 

Schematic design by ASM workflow transitions 

IS ADD


Lazy choice of most appropriate implementation strategy, i.e., overlay structure 

ASM enrichment of semantics with explicit choices for versions, e.g., synchonisation level 

Control-flow oriented execution based on specific supporting data structures (token set) 

Treatment of errors. 

be aware and develop mechanisms 

Systemic errors e.g. based on data exploration, data re-usage, data merging, falsifications, biases, wrong models 

Systematic errors e.g. due to abstractions, restrictions in accessible data, dirty data, approximations, computations 

Stochastic errors e.g. based on assumptions for occurrence of errors, their distribution functions and their contribution 

within the model and to the variables 

Handling by 

error prevention with direct correction, duplicate extraction and elaboration, validation, and verification 

(probabilistic) error models with maximal error, error spreading and multiplication, confidence intervals, means, 

outlier detection, time series abstractions 

error cleansing algorithms with(out) data recovery 

Gateways. 

in i : ✲t i 

CtlCond i 

. . . 

OR-Join Gateway 


✲❄ 

. . . 

CONSUME 

SOME 

O 

PRODUCE 

ASSIGNOP 

✲ 

out : ✲t 

OutCond 

ORJOINGATETRANSITION(node) = 

let I = select Consume (node) in WORKFLOWTRANSITION(node, I) 

where 

CtlCond(node, I) = (I ≠ ∅ and forall i ∈ I Enabled(i)) 

CTLOP(node, I) = 

PRODUCE(orJoinToken(firingToken(I)), out) 



[in 1 , . . . , in n ] = I 

ASSIGNOP(node) = forall i ∈ assignments(out) ASSIGN(to i , from i ) 

IS ADD


in : ✲t 

CtlCond 

OR-Split Gateways 


❄ ✲ 

. . . 

CONSUME 

O 

ASSIGNOP 

PRODUCE 

SOME 


OutCond j 

. . . 

✲ 

ORSPLITGATETRANSITION(node) = 

let O = select Produce (node) in WORKFLOWTRANSITION(node, O) 

where 

CtlCond(node) = Enabled(in) 

CTLOP(node, O) = 



PRODUCEALL({(orSplitToken(t, o), o) | o ∈ O}) 


Complex Gateways 


✲❄ 

✲ 

. . . 

. . . 

in i : ✲t i 

CtlCond i 

. . . 

CONSUME 

SOME 

× + 

ASSIGNOP 

✲ 

PRODUCE 

SOME 


OutCond j 

. . . 

✲ 

GATETRANSITIONPATTERN(node) = 

let I = select Consume (node) 

let O = select Produce (node) in 

WORKFLOWTRANSITION(node, I, O) 

where 

CtlCond(node, I) = (I ≠ ∅ and forall in ∈ I Enabled(in)) 

CTLOP(node, I, O) = 

PRODUCEALL({(patternToken(firingToken(I), o), o) | o ∈ O}) 



[in 1 , . . . , in n ] = I 


Events. 

Start events STARTEVENTTRANSITION(node) = 

choose e ∈ trigger(node) STARTEVENTTRANSITION(node, e) 

alternativ: 

IS ADD


STARTEVENTTRANSITION(node, e) = 

if Triggered(e) then PRODUCE(startToken(e), out) 

CONSUMEVENT(e) 

if type(e) = Link then 

Triggered(e) = Enabled(link) 

CONSUMEVENT(link) = CONSUME(linkToken(link), link) 

multiple start events: 

MULTIPLESTARTEVENTTRANSITION(node) = 

choose E ⊆ CorrelatedEvent(node) 

MULTIPLESTARTEVENTTRANSITION(node, E) 

MULTIPLESTARTEVENTTRANSITION(node, E) = 

if forall e ∈ E Triggered(e) then 

PRODUCE(startToken(e), out) 

forall e ∈ E CONSUMEVENT(e) 

End events ENDEVENTTRANSITION(node) = 

if Enabled(in) then 

CONSUME(firingToken(in), in) 

EMITRESULT(firingToken(in), res(node), node) 

EMITRESULT(result, t, node) = 

if type(result) = Message then SEND(mssg(node, t)) 

if type(result) ∈ {Error, Cancel, Compensation} then 

Triggered(targetIntermEv(result, node)) := true // trigger an intermediate event 

INSERT(exc(t), excType(targetIntermEvNode(result, node)))) 

if type(result) = Cancel then CALLBACK(mssg(cancel, exc(t), node), listener(cancel, node)) 

if type(result) = Link then PRODUCE(result, linkToken(result)) 

if type(result) = Terminate then DELETEALLTOKENS(process(p)) 

if type(result) = None and IsSubprocessEnd(node) then 

PRODUCE(returnToken(targetArc(node), t), targetArc(node)) 

if type(result) = Multiple then forall r ∈ MultipleResult(node) EMITRESULT(r, t, node) 

where 

CALLBACK(m, L) = forall l ∈ L SEND(m, l) 

DELETEALLTOKENS(p) = forall act ∈ Activity(p) 

forall a ∈ inArc(act) forall t ∈ TokenSet(p) EMPTY(token(a, t)) 

Intermediate Events INTERMEVENTTRANSITION(node) = 

choose e ∈ trigger(node) INTERMEVENTTRANSITION(node, e) 

IS ADD


INTERMEVENTTRANSITION(node, e) = 

if Triggered(e) then let t = firingToken(in) 

if not BoundaryEv(e) then 

if Enabled(in) then 



if type(e) = Link then PRODUCE(linkToken(link), link) 

if type(e) = None then PRODUCE(t, out) 

if type(e) = Message then 

if NormalFlowCont(mssg(node), process(t)) 

then PRODUCE(t, out) 

else THROW(exc(mssg(node)), targetIntermEv(node)) 

if type(e) = Timer then PRODUCE(timerToken(t), out) 

if type(e) ∈ {Error, Compensation, Rule} then THROW(e, targetIntermEv(e)) 

if BoundaryEv(e) then 

if active(targetAct(e)) then 


if type(e) = Timer then INSERT(timerEv(e), excType(node)) 

if type(e) = Rule then INSERT(ruleEv(e), excType(node)) 

if type(e) = Message then INSERT(mssgEv(e), excType(node)) 

if type(e) = Cancel then choose exc ∈ excType(node) in 

if Completed(Cancellation(e, exc)) then PRODUCE(excToken(e, exc), out) 

else TRYTOCATCH(e, node) 

where 

TRYTOCATCH(ev, node) = 

if ExcMatch(ev) then PRODUCE(out(ev)) 

else TRYTOCATCH(ev, targetIntermEv(node, ev)) 

Completed(Cancellation(e)) = 

RolledBack(targetAct(e)) and Completed(Compensation(targetAct(e))) 

Tasks. 

TASKTRANSITION(task) = [if Enabled(in) then] 

if ReadyForExec(task) then let t = firingToken(in) 

[CONSUME(t, in)] 

let i = select InputSets (SomeAvail(inputSets(task))) 

EXEC(task, inputs(i)) 

currInput(task) := i 

[seq 

IS ADD


if Completed(task, t) then 

[PRODUCEOUTPUT(outputSets(task), currInput(task))] 

[PRODUCE(taskToken(task, t), out)]] 

where 

PRODUCEOUTPUT(outputSets(t), i) = 

choose o ∈ outputSets(t) with Defined(outputs(o)) and IORules(t)(o, i) = true 

EMIT(outputs(o)) 

ReadyForExec(t) 

⎧ 

= 

⎨ SomeAvail(inputSets(t)) 

Arrived(mssg(t)) [and Instantiate(t)] 

⎩ 

true 

if type(t) ∈ {Service, User} 

if type(t) = Receive 

if type(t) ∈ {Send, Script, Manual, Reference} 

EXEC(t, 

⎧ 

i) = 

SEND(inMssg(t)) 

RECEIVE(mssg(t)) 

⎪⎨ 

SEND(mssg(t)) 

CALL(performer(action(t, i)), action(t, i)) 

EXEC(taskRef (t), i) 

⎪⎩ 

skip 



if type(t) ∈ {Send} 

if type(t) ∈ {Script, Manual} 

if type(t) = Reference 

if type(t) = None 

Completed(t, 

⎧ 

ttype) = 

Arrived(outMssg(t, ttype)) 

⎪⎨ Received(mssg(task, ttype)) 

Sent(mssg(task, ttype)) 

Completed(action(t, inputs(currInput(t))), ttype) 

⎪⎩ 

Completed(taskRef (t), ttype) 



if type(t) = Send 

if type(t) ∈ {Script, Manual} 

if type(t) = Reference 

Iterative Activity Nodes. 

LOOPTRANSITION(node) = [if Enabled(in) then] 


LOOPENTRY(node, t) 

seq 

if testTime(node) = before then 

while loopCond(node, t) LOOPBODY(node, t) 

if testTime(node) = after then 

until loopCond(node, t) LOOPBODY(node, t) 

[seq LOOPEXIT(node, t)] 

where 

LOOPBODY(n, t) = 

loopCounter(node, t) := loopCounter(node, t) + 1 

iterBody(node, loopToken(t, loopCounter(node, t) + 1)[, inputs(currInput(node))]) 

LOOPENTRY(n, t) = 

loopCounter(n, t) := 0 


[currInput(n) := select InputSets (SomeAvail(inputSets(n)))] 

LOOPEXIT(n, t) = 

IS ADD


if Completed(n, t) then 

[PRODUCEOUTPUT(outputSets(n), currInput(n))] 

[PRODUCE(loopExitToken(t, loopCounter(n, t)), out)] 

Completed(n, t) = LoopCompleted(n, t) if n ∈ Loop(t) 

Multi-Instance Loops. 

MULTIINSTTRANSITION(node) = [if Enabled(in) then] 


LOOPENTRY(node, t) 

seq 

if miOrdering(node) = Sequential then 

foreach i ≤ miNumber(node) 

loopCounter(node, t) := loopCounter(node, t) + 1 

iterBody(node, miToken(t, i)[, inputs(currInput(node))]) 

seq LOOPEXIT(node, t) 

if miOrdering(node) = Parallel then 

forall i ≤ miNumber(node) 

START(iterBody(node, miToken(t, i)[, inputs(currInput(node))])) 

seq 

if miFlowCond = All then LOOPEXIT(node, t) 

if miFlowCond = None then EVERYMULTINSTEXIT(node, t) 

if miFlowCond = One then ONEMULTINSTEXIT(node, t) 

if miFlowCond = Complex then COMPLMULTINSTEXIT(node, t) 

where 

Completed(n, t) = forall i ≤ miNumber(n) 

Completed(iterBody(n, miToken(t, i)[. . .])) 

COMPLMULTINSTEXIT(n, t) = // for miOrdering(n) = Parallel 

AlreadyCompleted := ∅ // initially no instance is completed 

seq 

while AlreadyCompleted ≠ {i | i ≤ miNumber(n)} do 

if NewCompleted(n, t) ≠ ∅ then 

if | AlreadyCompleted |< tokenNo(complexMiFlowCond) 

then 

if TokenTime(complexMiFlowCond) then 

let i 0 = select NewCompleted in 

PRODUCE(miExitToken(t, i 0 ), out) 

INSERT(i 0 , AlreadyCompleted) 

[PRODUCEOUTPUT(outputSets(n), currInput(n))] 

else forall i ∈ NewCompleted(n, t) INSERT(i, AlreadyCompleted) 

where 

NewCompleted(n, t) = 

{i ≤ miNumber(n) | Completed(iterBody(n, miToken(t, i)[. . .])) and i ∉ AlreadyCompleted} 

EVERYMULTINSTEXIT(n, t) = COMPLMULTINSTEXIT(n, t) 

where 

tokenNo(complexMiFlowCond) =| {i | i ≤ miNumber(n)} | 

TokenTime(complexMiFlowCond) = true 

IS ADD


ONEMULTINSTEXIT(n, t) = COMPLMULTINSTEXIT(n, t) 

where 

tokenNo(complexMiFlowCond) = 1 

TokenTime(complexMiFlowCond) = true 

AdHoc Processes. 

ADHOCTRANSITION(node) = [if Enabled(in) then] 



[let i = select InputSets (SomeAvail(inputSets(node))) 

currInput(node) := i] 

while not AdHocCompletionCond(node, t) 

if adHocOrder(node) = Parallel then forall a ∈ innerAct(node) do a[inputs(i)] 

if adHocOrder(node) = Sequential then let< a 0 , . . . , a n >= innerAct(node) 

foreach j < n do a j [inputs(i)] 


where Completed(node, t) = AdHocCompletionCond(node, t) 

UNCONSTRAINEDADHOCTRANSITION(node) = [if Enabled(in, tokenType(in)) then] 



[let i = select InputSets (SomeAvail(inputSets(node))) 

currInput(node) := i] 

while not AdHocCompletionCond(node, t) 

choose A ⊆ multi innerAct(node) 

forall a ∈ A do a[inputs(i)] 


where Completed(node, t) = AdHocCompletionCond(node, t) 

An alternative Token Model. 

Token with clan memory 

start token T of process instance 

And T.1 

And T.2 And T.3 

Or T.1.1 

Or T.1.2 

Xor T.2 

Multi T.1.1. 1 Multi T.1.1. 2 Multi T.1.1. 3 Multi T.1.1. 4 

And T.2.1 And T.2.2 

each token has complete knowledge on its siblings and parents 

splits generate new children 

joins return parent of complete join otherwise more complex model 

special model for structures of splits and joins that do not have an equivalent Fitch structure 

IS ADD


Business process modelling notation: Mapping to BPEL 

Business process modelling notation: Derivation from SiteLang 

Beispiel: Conference Paper Submission and Reviewing System 

Beispiel: Edutainment Website für Lernunterstützung von Kindern 

Beispiel: Edutainment Plattform 

3.2.4 Workflow als konzeptionelle Wiederspiegelung 

Klassen von Operationen. 

Retrievaloperationen zur Gewinnung von Daten 

Modifikationsoperationen zur Veränderung der Daten 

Pflegeoperationen zur Pflege der Datenbank, zur Bereitstellung von temporären Daten, zur Pflege der Hilfsstrukturen 

wie Indices etc. 

IS ADD


Prozesse als Grundkonstrukt. 

Anmerkung β: Prozeßalgebra wird noch eingeführt 

Prozeß: 

Einfache Transaktionen wie bereits oben 

Komplexe Transaktion wie bereits oben 

System-Prozeß der Zustand des DBS-Inputs, DBS-Outputs oder des DBMS ändert 

Für die Verhaltensmodellierung ergeben sich neue Modellierungsforderungen 3 : 

Erweiterte und abgeschwächte Transaktionsmodelle können verwendet werden. Dazu stehen als Alternativen 

Konzepte des Transaktionsbaumes, genesteter Transaktionen, offene genestete Transaktionen und kompensierende 

Teiltransaktionen zur Verfügung. 

Das erweiterte ER-Modell verfügt über diese Mechanismen. 

Es wird eine Transaktion allgemein mit einem Definitionsrahmen der Form 

transaction identifier (parameter list) 

o 1 ; o 2 ; ...; o m 

end; 

angegeben. Die Operationen o i sind HERM-Operationen. Sie können parametrisiert sein. 

Weiterhin sind geschachtelte Transaktionen P 1 ; P 2 ; ...P n zugelassen, die ihrerseits wiederum aus Folgen von 

(Komponenten-)Transaktionen bestehen. Die Semantik der geschachtelten Transaktionen basiert auf einem 

schrittweisen Abschluß der Komponenten-Transaktionen. Führt eine der Komponenten-Transaktionen zu einem 

Fehler, dann wird die gesamte geschachtelte Transaktionen abgebrochen. 

Außerdem sind zugelassen 

• kompensierende Transaktionen 

P 1 compensated by P 2 , 

bei denen bei einem Auftreten eines Fehlers die Transaktion zu einer Kompensation des Fehlers benutzt 

wird und die Transaktion erst dann abgebrochen wird, wenn auch die kompensierende Transaktion nicht 

zum Erfolg führt, sowie 

• Ersatztransaktionen 

P 1 contingented by P 2 , 

bei denen bei Auftreten eines Fehlers der Transaktion P 1 die Transaktion P 1 auf den Beginn zurückgeführt 

wird und anschließend P 2 ausgeführt wird, so daß die Gesamttransaktion nur dann abgebrochen wird, 

wenn sowohl P 1 als auch P 2 nicht zum Erfolg führen. 

Eine (einfache) Transaktion ist eine Folge P = o 1 ; o 2 ; o 3 ; ...; o m von Basismodifikations- und Retrieval-Operationen 

über dem Datenbankschema ER = ({T i |1 ≤ i ≤ m}, Σ ER ) mit T i = (U TI , Σ Ti ) für 1 ≤ i ≤ m. 

Transaktionen können auf einen Datenbank-Zustand ER C sequentiell angewandt werden und führen zu einer 

Transition o m (...(o 2 (o 1 (ER C )))). 

Der Effekt der Anwendung einer Transaktion P auf ER C ist definiert als Transformation, die die Integritätsbedingungen 

erhält, d.h. 

{ 

P(ER C om (...(o 

) = 

2 (o 1 (ER C )))) falls o m (...(o 2 (o 1 (ER C )))) |= Σ ER ∪ ⋃ m 

i=1 Σ T i 

ER C 


Damit kann eine Transaktion als integritätsinvariante oder konsistenzerhaltende Zustandstransformation verstanden 

werden. 

Sie stellen daher eine besondere Form von Programmen dar. 

Wir nutzen als Ausführungsmodell das Zustandsmodell in Bild 8. Eine Transaktion ist entweder inaktiv oder 

3 siehe Extraabschnitt Verhaltensmodellierung.


✲ 

Inaktiv 

✛ 

Zurückgewiesen 

✻ 

✠ 

BOT 

IC falsch 

EOT 

✻ 

Beendigung 

✛ 

❥ Aktiv 

IC wahr 

✛ 

❥ 

✻ 

Bereit zum Abschluß 

Abbildung 8: Die Zustände einer Transaktion 

aktiviert oder beendet (EOT). Eine aktivierte Transaktion ist beim Bereitstellen aller benötigten Ressourcen 

(BOT) oder in der Bearbeitung oder bereit zum Abschluß (Commit), wobei dann die Gültigkeit der statischen 

und dynamischen Integritätsbedingungen geprüft werden muß oder beim Zurückfahren zum inaktiven Zustand, 

falls die Prüfung der Konsistenz eine Inkonsistenz ergeben hat, oder beim Abschluß, wobei dann alle Ressourcen 

wieder freigegeben werden. 

Zur Implementation von Transaktionssystemen steht eine Reihe von Update-Optionen, wie Update-in-place 

(auf der Platte), Update-in-private (mit einem Transaktionspuffer) oder Update-im-Schattenspeicher zur Verfügung. 

Das klassische Transaktionsmodell definiert Transaktionen über das ACID-Konzept. Transaktionen sind atomar 

(werden ganz oder gar nicht wirksam), konsistenzerhaltend, werden isoliert ausgeführt und führen zu dauerhaften 

Veränderungen. Diese Auffassung postuliert die Existenz einer implementierenden Maschine. Auf der 

konzeptionellen Schicht können wir sie deshalb nicht verwenden. Die beiden ersten Bedingungen sind in unsere 

Definition eingeflossen. Die letzte Bedingung ist eine Forderung an Informationssysteme im allgemeinen. 

Die Isoliertheit wird gewöhnlich über die Serialisierbarkeit definiert. Da dies jedoch auch ein Implementationskonzept 

ist, verwenden wir einen anderen Zugang. 

Die Read-Write-Mengen read − write(P) = (read(P), write(P)) einer Transaktion sind alle elementaren Leseund 

Schreiboperationen der Transaktion P. Eine read-Operation ist eine objekt-basierte Operation, ebenso wie 

eine write-Operation. 

Zwei Transaktion P 1 und P 2 sind Konkurrenten falls read(P 1 )∩write(P 2 ) ≠ ∅ oder read(P 2 )∩write(P 1 ) ≠ 

∅ oder write(P 2 ) ∩ write(P 1 ) ≠ ∅ . 

Parallele Ausführung von Transaktionen ist immer möglich, wenn diese keine Konkurrenten sind. In diesem 

Fall ist der Effekt der parallelen Ausführung äquivalent zu P 1 (P 2 (ER C )) oder zu P 2 (P 1 (ER C )) für die Datenbank 

ER C . 

Sind Transaktionen Konkurrenten, dann kann ein Steuerprogramm die Korrektheit der parallelen Ausführung 

gewährleisten. 

Neben diesen Modellen können wir auch erweiterte Konzepte aus der Literatur verwenden: 

• Sagas basieren auf einer Menge von ACID Subtransaktionen mit vordefinierter Ausführungsordnung und 

einer Menge dazu assoziierter kompensierender Teiltransaktionen. 

• Split-and-join-Transaktionen wurden für den Ressourcentransfer zu parallel verlaufenden Transaktionen 

entwickelt. 

• Flexible Transaktionen sind Polytransaktionen, deren Konsistenzforderungen durch Kollektion von Datenabhängigkeitsdeskriptoren 

(D 3 ) realisiert werden. 

• Transaktionen können mit dem ACTA Metamodell erweitert werden. 

Für unsere Belange erscheinen jedoch diese HERM-TA-Formen ausreichend. 

Es wurden unterschiedliche Modelle zur Ausführung und Steuerung von Geschäftsprozessen, Handlungen 

und Workflows entwickelt. Das einfachste Modell ist das Modell der Job Control Language (JCL). 

Dieses Modell wurde für Skriptsprachen erweitert. Eine Transaktion kann ebenso wie ein Modul als abstraktes


Programm mit einem Namen und formalen Parametern für den Input, Output und Reporten zum Programmdurchlauf 

aufgefaßt werden. 

Jedem abstrakten Programm sind Parameter-Werte-Paare zugeordnet, die entweder zur Aufrufspezifikation 

oder zur Steuerungsspezifikation herangezogen werden. Diese Parameter sind entweder ereignisbasiert oder 

wertebasiert. Wir verwenden solche Ereignisse oder Werteparameter in der konzeptionellen Schicht, um einen 

allgemeinen Rahmen für die Implementationsschicht schaffen zu können. Zu solchen Parametern gehören 

• allgemeine Aufrufparameter onLoad, onSelect, onSubmit, onUnload, onWait, onUnWait, 

getData, instantiateSession, presentationMode, presentationStyle, 

typeGlobeSelect, onBlur, onCancel, 

• allgemeine Priorisierungsparameter wie onFocus, changePriority, unFocus, 

emphasisMode, 

• allgemeine Steuerparameter wie onReset, onRecovery, onChange, onUserReaction, 

changeToSlave, changeToMaster, waitUntil, securityLevel, changeStatus, 

openSatelliteWindow, closeSatelliteWindow, hookOnProcess, separateFromProcess, 

defaultSet, onScroll, deliveryRestriction, deliveryMode, securityLevel, 

garbageCollector, hideMode, 

• Fehlerparameter wie onAbort, onError, unloadErrorLog, useErrorLog notifyMode und 

• allgemeine Weitergabeparameter wie onSend, onReceive, forUser, toNode, fromNode, 

onTime, validUntil, onLoad, onEventTransfer, onMouseCapture, whoCausedEvent 

und returnValue. 

Die Parameterliste kann beliebig verkleinert oder vergrößert werden. Im letzteren Fall müssen adäquate Formen 

für die Umsetzung in die Implementation gefunden werden. 

Außerdem unterscheiden wir verschiedene Variablentypen: 

• Statische Variablen sind analog zu den globalen Variablen von Pascal oder den Klassenvariablen von Java 

mit einer an das Programm gekoppelten Lebenszeit ausgestattet. Statische Variablen können global oder 

lokal. Per Default sind sie lokal. 

• Kellervariable besitzen ebenso wie lokale Variablen oder Parametervariablen nur eine Lebenszeit während 

der Ausführung einer Funktion. 

• Explizite Speichervariablen nutzen einen temporär zugeordneten Speicher. 

• Implizite Speichervariablen werden erst mit einem Speicherplatz verbunden, wenn ihnen ein Wert zugewiesen 

wird. 

In analoger Form können der Gültigkeitsbereich und die Bindung an Namen, Stellen und Werte (zur Entwurfszeit, 

Implementationszeit, Übersetzungszeit, Linkzeit, Ladezeit oder Laufzeit) von Variablen und Parametern 

behandelt werden. 

Wir verwenden diese Konzepte zur Spezifikation des Aufrufes einer Transaktion und der Steuerung der Ausführung. 

Aufrufsspezifikation: Ein Aufruf eines abstrakten Programmes wird über den Namen des Programmes, durch 

eine Instantiierung der formalen Parameter durch aktuelle Parameter und durch die Angabe des Nutzers 

und der Steuerungsumgebung angegeben. Die Angabe des Nutzers, der ein anderes Programm oder ein 

Benutzer sein kann, erfolgt nicht nur für Abrechnungs- sondern auch für Benachrichtigungszwecke. Die 

Steuerungsumgebung erlaubt eine detaillierte Angabe der Steuerung, der Priorisierung, der Ausführung 

auf anderen Knoten. 

Zur Angabe kann außerdem eine Spezifikation der Ausnahmenbehandlung gehören wie z.B. für den Fall 

eine konkurrierenden Abarbeitung. 

• undefinedness 

• processing context 

• inapplicable 

• null 

• IC violation


siehe auch Struktur-Ausnahmen (Preprint CAU IfI, Berztiss) 

Steuerungsspezifikation: Zur Steuerungsspezifikation unterscheiden wir drei Räume: 

• Im Nachrichtenraum werden sowohl die Benutzernachrichten als auch die Systemnachrichten verwaltet. 

Im ersteren Falle sind Informationen zur Sichtbarkeit, Notifikation und zum Datenstrom des 

Benutzers, im letzteren zur Übertragung, Signoff- und Signon-Nachrichten gesetzt. 

• Im Parameterraum werden alle aktuellen Parameterzuweisungen wie Status, Priorisierung, Ausführungsmodi 

(stand alone, eingebettet, remote, applet, servlet), Bindungen und Einschränkungen 

verwaltet. Außerdem erfolgt hier die Speicherung des Benutzerportfolios und des aktuellen Benutzerprofils. 

• Im Ressourcenraum wird die Allokation von Daten, Routen, Knoten etc. zu den aktuellen Prozessen 

dargestellt. 

Weitere Modelle sind möglich: 

• ConTracts sind komplexere Modelle und geeignet für die Gruppierung von Transaktionen in eine Multitransaktionsaktivität 

(Menge von ACID Aktionen (Schritte) mit explizit spezifiziertem Ausführungsplan 

(Skript)), wobei die Ausführung Vorwärts-Recoverable sein muß (abgeschwächte atomicity)). 

• Langlebige Aktivitäten (Long running activities) basieren auf einem erweiterten ECA Modell. Sie verwenden 

eine Menge von Ausführungsschritten, die (rekursiv) andere Transaktionen enthalten, und Kontrollund 

Datenfluß-Skripte. Es wird eine explizite Kompensation für Transaktionen vorgegeben. Das Konzept 

wird durch eine Kommunikation zwischen den Ausführungsschritten unterstützt. Es werden außerdem 

die Abfrage des Status einer Aktivität und explizite Ausnahmebehandlung unterstützt. Es können 

Korrektheits- und Koordinierungsbedingungen angegeben werden. Daraus werden Aufgabenflußmodelle 

für Multiaktivitäten abgeleitet. 

Damit umfaßt die Spezifikation eines Workflows 

die Aufgaben- bzw. Prozeßspezifikation als spezifische Art eines Prozesses bei Spezifikation der Struktur, wobei 

die Menge von extern sichtbaren Ausführungszuständen, 

die Menge von legalen Transitionen dieser Zustände und 

Bedingungen, die die Ausführung der Transitionen erlauben, 

für die Darstellung durch Zustandstransitionsdiagramme benutzt werden. Jeder Prozeß hat eine interne 

Struktur und ist damit abhängig vom Input und dem Zustand des lokalen Systemes. Er ändert den Zustand 

und produziert einen Output abhängig von verschiedenen Systemcharakteristika, abhängig von Eigenschaften 

der Operationen (z.B. analoge Ausführung, serielle Ordnung, Idempotenz von Operationen (günstig für Kompensation 

(z.B. setze x to c))), 

die Aufgaben- bzw. Prozeßkoordination durch verschiedene Scheduling-(Pre-)Conditions 

statisch durch Definition des Zustandes vor Start des Prozesses (Ausführungszustände anderer Prozesse, Output- 

Werte anderer Prozesse, Werte externer Variable) oder 

dynamisch durch Spezifikation der Abhängigkeiten während der Prozeßausführung, 

die Korrektheitsbedingungen für Ausführung und Versagen mit 

Failure-atomicity Bedingungen (Bei Ausführungsproblemen kann anstatt des vorgegebenen Prozesses ein 

anderer ausgeführt werden, um einen akzeptablen Endzustand zu erreichen.) oder 

Execution-atomicity Bedingungen (zur Darstellung der Zerlegbarkeit von Transaktionen bei Serialisierung). 

Die Ausführung eines Workflows hängt von verschiedenen Interprozeß-Abhängigkeiten ab. Damit spezifizieren 

wir zwei Bestandteile: 

den Scheduler zur Ausführung der Prozesse durch Planung der nächsten Schritte mit einem Monitoring der verschiedenen 

Ereignisse und zur Berechnung der Interprozeß-Abhängigkeiten und


den Prozeß-Agenten zur Ausführungskontrolle eines Prozesses. 

Programme der Workflow-Maschine. 

Elementarprogramme sind alle zugelassenen Ausdrücke der HERM-Algebra. Wir unterlegen dabei eine Semantik 

der Abstract-State-Machines. Sie wird im folgenden kurz eingeführt. In diesem Buch werden wir die Semantik nur 

anwenden, so daß wir auf eine detaillierte Erklärung verzichten können. Für die graphische Darstellung schließen wir 

uns den üblichen Darstellungsformen für sequentielle Programme an, wobei wir eine Verwechslung mit Konstrukten 

des ER-Modelles vermeiden wollen. Deshalb sind ovale Boxen sowohl Programmschritten als auch dem Test 

vorbehalten. Wir können damit induktiv komplexere Programme konstruieren: 

Sequentielle Ausführung von Programmen DO P 1 ; P 2 

Ein Programmschritt kann auf einen anderen Programmschritt 

folgen. 

DO P 1 ✲ DO P 2 

✲ 

Verzweigung mit einer logischen Bedingung: if α then P 1 else P 2 ; 

Ein Programmschritt kann verzweigen unter einer Bedingung. 

IF α 

true ✲ 

✲ 

false 

DO P 1 

DO P 2 

✲ 

Wiederholte Ausführung mit einer logischen Bedingung: 

Der Bequemlichkeit halber führen wir auch eine Programmschleife 

ein. Diese ist auch durch andere Konstrukte abstrakter 

Maschinen ausdrückbar. 

DO P 1 LOOP α 

✻ ✲ DO P 1 

LOOP α ✛ ✲ 

Parallele Ausführung mehrerer Programme ohne Einschränkung: 

DO P 1 PAR ... PAR DO P k 

Programme können parallel ausgeführt werden. Die parallele 

Ausführung ist beendet, wenn alle Programme beendet sind. Alle 

Programme beginnen mit dem gleichen Zustandsraum. 

Eine parallele Ausführung ist erfolgreich durchgeführt, wenn 

keine konkurrierenden Veränderungen der Datenbank mit unterschiedlichen 

Werten für die gleichen Datenbankobjekte erfolgen. 

✲ DO P 1 

DO P 2 

✲ 

DO ... 

✲ DO P k 

Ausführung nach Zuweisung von Werten zu Variablen: 

Es können Werte den Parametern in einem Programm P zugewiesen 

werden. Diese Zuweisung gilt nur lokal. 

Ausführung nach Auswahl eines Wertes : 

Es wird ein x-Wert unter einer Bedingung gewählt. Damit 

wird das Programm ausgeführt. 

LET x = t IN P DO P 

LET x = t IN P ✲ DO P ✲ 

CHOOSE x WITH φ DO P 

CHOOSE x WITH φ ✲ DO P ✲


Ausführung für alle zutreffenden Werte: 

Alle Werte für einen Parameter, die zutreffen, werden 

gewählt. Es wird dafür das Programm P parallel ausgeführt. 

SKIP-Programmschritt zur Darstellung des leeren Programmschrittes: 

Konzeptionell kann auch der Programmschritt ohne Auswirkungen 

auf den Zustand benötigt werden. 

FOR ALL x WITH φ DO P 

FOR ALL x WITH φ ✲ DO P ✲ 

SKIP 

DO SKIP ✲ 

Modifikationsschritt zur Durchführung einer Modifikation der Datenbank: 

Es wird ein paralleler Update für eine Datenbank-Klasse ausgeführt 

mit den Parametern s 1 , ..., s n . 

DO f (s 1 , ..., s n ) := t 

DO f (s 1 , ..., s n ) := t 

✲ 

Aufruf eines Programmes aus der Programmbibliothek: DO r(t 1 , ..., t n ) 

Es kann ein Programm aus der Programmbibliothek aufgerufen 

werden. 

DO r(t 1 , ..., t n ) 

✲ 

Mit diesen allgemeinen Transitionen können wir auch komplexere Programme zusammenstellen. Diese Programme 

basieren auf einer parallelen Ausführung. Das folgende Beispiel stellt die Alternativen zur Eingabe der Hauptdaten zu 

einem Lehrveranstaltungsangebot vor. Danach können alle erforderlichen sonstigen Daten bereitgestellt werden, wie 

z.B. Raumforderungen oder auch optionale Informationen, wie z.B. Angaben zu Übungen und Praktika. Raumdaten, 

Studiengangsdaten, Angaben zu Nebenbedingungen und die Klassifikation der Lehrveranstaltung werden nicht neu 

erstellt, sondern aus der Datenbank abgefragt und zugeordnet. 

✲ 

DO Vorlesung(Klassifikation) := chooseKl 

DO Vorlesung(Studiengang) := chooseSG 

DO Vorlesung(Hauptdaten) := inputHD 

true ✲ 

✲ IF Praktika 

✲ 

DO Vorlesung(Praktika) := inputPr 

✲ DO Skip 

false 

✲ 

true ✲ DO Vorlesung(Übung) := inputÜb 

IF Übung 

✲ DO Skip 

false 

DO Vorlesung(Nebenbedingung) := chooseNB 

✲ DO Vorlesung(Raumforderung) := chooseRF 

Abstrakte Semantik von Datenbank-Transitionen. 

Das Datenbank-Schema definiert die Strukturierung der Datenbank. Ein Zustand der Datenbank kann durch eine 

Modifikation partiell geändert werden. Änderungsoperationen T(s 1 , ..., s n ) := t vom Teiltyp T ′ von T basieren auf 

Anfragen. Sie sind auf einem Objekt einer Klasse T C definiert, falls 

| σ T ′ =(s 1 ,...,s n )(T C ) | ≤ 1 gilt. 

Eine Menge U = {T i (s i,1 , ..., s i,ni ) := o i | 1 ≤ i ≤ m} von objekt-basierten Änderungsoperationen ist konsistent, 

falls aus T i (s i,1 , ..., s i,ni ) = T j (s j,1 , ..., s j,nj ) für 1 ≤ i < j ≤ m die Gleichheit o i = o j folgt.


Das Resultat der Ausführung einer konsistenten Menge U von Änderungsoperationen führt zu einer Zustandsänderung 

der Datenbank ER C zu ER C + U 

(ER C + U)(o) = 

{ Update(Ti , s i,1 , ..., s i,ni , o i ) falls T i (s i,1 , ..., s i,ni ) := o i ∈ U 

ER C (o) 


für Objekte o of ER C . 

Ein parametrisiertes Programm r(x 1 , ..., x n ) = P der Stelligkeit n besteht aus einem Programmnamen r, 

einer Transitionsregel P und einer Menge {x 1 , ..., x n } von freien Variablen von P. 

Eine Datenbank ER C ist ein Modell von φ (kurz bezeichnet als ER C |= φ ) falls [[φ]] ERC 

ζ 

= true für alle 

Variablenbelegungen ζ für die freien Variablen von φ. 

Eine Workflow-Maschine W = (ER, ER C 0 

, P, Σ) basiert auf einem Datenbank-Schema ER, einer initialen 

Datenbank ER C 0 

, einer Menge von parametrisierten Programmen und einem ausgezeichneten Programm, das 

Hauptprogramm genannt wird, sowie den dynamischen Integritätsbedingungen. 

Eine Transitionsregel P führt zu einer Menge U von Änderungsoperationen in einem Zustand ER C , falls dieser 

konsistent ist. Sie verändert den Zustand der Datenbank mit einer Variablenbelegung ζ zu yields(P, ER C , ζ, U). 

Die Semantik einer Transitionsregel wird durch einen Kalkül mit Regeln der Form 

Voraussetzung 1 , ..., Voraussetzung n 

Folgerung 

Bedingung 

definiert. 

Wir verzichten hier auf die vollständige Angabe der Semantik und verweisen auf die Literatur. Als Beispiel führen 

wir die folgenden Regeln an, ohne auf den Beweis dieser Regeln einzugehen: 

yields(P, ER C , ζ, U) , yields(Q, ER C , ζ, V) 

yields(DO P PAR Q, ER C , ζ, U ∪ V) 

U ∪ V 

konsistent 

Die Konsistenzbedingung kann weggelassen werden, wenn man die Theorie der partiell-geordneten Durchläufe für 

ASM anwendet. Wir wollen jedoch hier nicht im Detail auf die Theorie eingehen. 

yields(P, ER C , ζ[x ↦→ a], U) 

yields(LET x = t IN P DO P , ER C , ζ, U) 

wobei 

a = [[t ] ERC 

ζ 

∀ a ∈ I : yields(P, ER C , ζ[x ↦→ a], U a ) 

yields(FOR ALL x WITH φ DO P , ER C , ζ, ⋃ a∈I U a) 

wobei I = range(x, φ, ER C , ζ) 

Der Wertebereich range(x, φ, ER C , ζ)) ist definiert durch die Menge {o ∈ ER C | [φ] ERC 

ζ[x↦→a] = true} . 

yields(P, ER C , ζ[x ↦→ a], U) 

yields(CHOOSE x WITH φ DO P , ER C , ζ, U) 

wobei a ∈ range(x, φ, ER C , ζ) 

yields(CHOOSE x WITH φ DO P , ER C falls range(x, φ, ER C , ζ) = ∅ 

, ζ, ∅) 

yields(P, ER C , ζ, U) , yields(Q, ER C + U, ζ, V) 

yields(DO P ; Q , ER C falls U konsistent ist 

, ζ, U ⊕ V) 

yields(P, ER C , ζ, U) 

yields(DO P ; Q , ER C falls U inkonsistent ist 

, ζ, U) 

yields(SKIP , ER C , ζ, ∅) 

yields(f (s 1 , ..., s n ) = t , ER C , ζ, (Update(l, v)) 

wobei 

l = f ([[s 1 ]] ERC 

ζ , ..., [s n ]] ERC 

ζ ) und v = [[t]] ERC 

ζ


yields(P, ER C , ζ, U) 

yields(IF φ THENP ELSE Q , ER C , ζ, U) 

falls 

[[φ]] ERC 

ζ 

= true 

yields(Q, ER C , ζ, V) 

yields(IF φ THENP ELSE Q , ER C , ζ, V) 

falls 

[[φ]] ERC 

ζ 

= false 

yields(P t 1,...,t n 

x 1 ,...,x n 

, ER C , ζ, U) 

yields(r(t 1 , ..., t N ) , ER C , ζ, U) 

mit 

r(t 1 , ..., t n ) = P 

Die angegebene Workflow-Maschine erlaubt eine allgemeine Spezifikation des Verhaltens des Datenbanksystems. 

Mit dieser Grundlage können wir eine pragmatischere Spezifikationssprache im weiteren verwenden. 

CSP-Operatoren. 

Prozesse können in CSP (Communicating sequential processes) als parallele Prozesse dargestellt werden. Wir verwenden 

dazu eine kausale Semantik. 

CSP-Prozeß : Ereignis + Bedingung + auslösende Aktion Communicating sequential processes als parallele Prozesse kausale 

Semantik 

Sequentielle Ausführung: ; 

Parallele Ausführung: ‖ 

p 1 ‖p 2 ist erst dann beendet, wenn sowohl p 1 als auch p 2 beendet wurde. Werden diese Prozesse sequentiell ausgeführt, dann ist jede 

Reihenfolge erlaubt. 

Nichtdeterministische Ausführung: [] 

Der Prozeß ist beendet, sobald einer der Teilprozesse beendet ist. 

Es kann zusätzlich angenommen werden, daß alle anwendbaren Teilprozesse, mindestens aber einer beendet werden ([] × ). 

Iterative Ausführung: ∗ 

Bedingte Anweisung: α → p 

Wenn α gilt, dann wird auch p ausgeführt. 

Semantik wie für Schleifen 

auch guarded commands 

Mögliche Anweisung: {} 

Der Prozeß wird ausgeführt oder kann auch übergangen werden. 

Weitere Anweisungen: skip, abort, Ein- und Ausgabeanweisungen, ... 

Hilfsanweisungen: 

Anweisungen mit einem Bezeichner sowie geklammert 

Alternative klassische Kompositionstheorie von Prozessen in Workflows: 

siehe gesondertes Kapitel am Ende 

Workflows als Konstrukt. 

Workflows: model of complex, long-running enterprise process generally performed in a highly distributed and 

heterogeneous environment. It is structured as a set of processes that are executed in a specified partial order. A 

process in a workflow needs not to be a transaction. 

Each process in a workflow is performed by an agent, which can be program, a hardware device, or a human. For 

keeping track of the inventory, the agent might be a software system. 

Each process has a physical status such as executing, committed, or aborted. The completion of a process might 

generate some logical status information indicating success or failure. The processes in a workflow have to be coordinated. 

The workflow management system consists of a scheduler and a process agent manager. 

The scheduler


initiates, cancels, interrupts, retries, compensates, ... the execution of a set of workflows, 

uses recoverable queues as a mechanism for storing information about the processes of active workflows and 

for process sequencing, and 

maintains the state of the workflow execution including recovery for the case of crashes. 

The process agent manager 

assigns processes to agents, reassigns or stops the execution of processes, 

keeps track on the status of execution and activation or deactivation of agents, and 

manages the input/output for the communication with the agents (If reformatting becomes necessary then the 

PAM provide filters for this purpose.). 

The PAM is specified by constructs of JCL. 

An agent 

has a name and a number of assigned roles it can assume, 

receives a worklist, and 

has a status. 

The agent reports to the process agent manager 

the status of the execution of processes and additional logical information, 

the results of the execution of processes, and 

Module auf der Implementationssschicht 

Programme, Transaktionen, stored procedures als Grundkonstrukt. 

Abbildung auf UML-Strukturen und Workflow-Prozesse 

Grundlagen durch Abbildung auf ASM-Maschinen 

Abbildung auf BPML etc. Sprachen 

Life-sequence charts (Harel) (Play-in-Play-out-Separation von life sequence charts)


3.3 Dynamische Integritätsbedingungen 

Dynamische Integritätsbedingungen werden in der Literatur meist aufgrund ihrer Kompliziertheit weggelassen. Sie 

sind jedoch für die Datenbank-Entwicklung nicht minder wichtig. Deshalb führen wir auch einige Klassen explizit 

ein. 

Wir betrachten dazu temporale Klassen vom Typ R: 

Jedem potentiellen Objekt o von dom(R) kann eine Lebenszeit l R (o) ⊆ IN in der Datenbank zugeordnet werden. 

Damit können wir 

temporale Klassen (R C , l R ) und 

ihre Schnappschüsse S(i, R C , l R ) = {o ∈ dom(R)|i ∈ l R (o)} 

einführen. 

Gegeben seien eine Formel α über R, eine temporale Klasse (R C , l R ) über R, und Schnappschüsse 

S(0, R C , l R ), ...,S(i, R C , l R ), ... S(maxT, R C , l R ). 

Wir können nun eine Erfüllbarkeit von Formeln analog zur Modallogik definieren. 

Ein Zeitrahmen ZR besteht aus einem Paar (TS, W) von Intervallen von IN und einer binären Relation W über TS. 

Wir bezeichnen mit maxTS den maximalen Zeitpunkt von TS und mit minTS den minimalen Zeitpunkt. Der einfachste 

Zeitrahmen ist das Intervall TS = [0, maxTS] betrachtet. Die binäre Relation W stellt eine Erreichbarkeit von 

Intervallen untereinander her. Wir sind damit in der Lage, Zeiträume zu betrachten und ggf. auch voneinander zu 

separieren. 

Die Gültigkeit von α in einem Schnappschuß S(i, R C , l R ) ist induktiv wie für statische Integritätsbedingungen 

definiert und wird mit (R C , l R , i) |= α notiert. 

Die Formel α is notwendig gültig in (R C , l R ), zu einem Zeitpunkt i ∈ I, I ∈ TS und für einen Zeitrahmen ZR 

falls (R C , l R , i ′ ) |= α für alle Intervalle I, I ′ mit (I, I ′ ) ∈ W und alle Zeitpunkte i ′ ∈ I ∪ I ′ . 

Wir notieren dies mit (R C , l R , i, ZR) |= □α bzw. (R C , l R , I, ZR) |= □α 

Die Formel ist gültig in jedem Zeitpunkt des Intervalls I, dem i angehört, und in jedem Zeitpunkt, der durch W 

aus I erreicht werden kann. In der Modallogik wird zwischen der Gültigkeit von α in I und zu jedem Nachfolgeintervall 

unterschieden. Wir benötigen diese strikte Unterscheidung nicht. Wir können mit (R C , l R , I, ZR) |= 

□α die Gültigkeit ab einer Phase I für alle Folgephasen I ′ modellieren. 

Eine Formel α ist notwendig gültig in (R C , l R ) und ZR ab I 1 bis zu I 2 für I 1 , I 2 ∈ TS 

falls (R C , l R , i) |= α für alle Intervalle I ′ mit (I 1 , I ′ ) ∈ W bzw. (I ′ , I 2 ) ∈ W und i ∈ I 1 ∪ I 2 ∪ I ′ . 

Wir bezeichnen die zeitweilige volle Gültigkeit mit (R C , l R , [I 1 , I 2 ], ZR) |= □α . 

Wir können damit die Gültigkeit zwischen Phasen definieren. 

Die Formel α ist gültig in (R C , l R ) und ZR falls (R C , l R , i) |= α für jeden Zeitpunkt i jedes Intervalls I 

des Zeitrahmens (bezeichnet mit (R C , l R , ZR) |= α ). 

In diesem Fall ist α eine statische Integritätsbedingung, falls ⋃ I∈TS 

I = [minTS, maxTS]. 

Die Formel α ist möglich gültig in (R C , l R ) und ZR falls für ein i ∈ ⋃ I∈TS I (RC , l R , i) |= α (bezeichnet 

mit (R C , l R , ZR) |= ♦α ). 

Besitzt ein Zeitrahmen ZR Unterbrechungen, dann wird für die Formel α keine Forderung erhoben. 

Ein Zeitrahmen wird für die Implementationsschicht direkt durch Phasen repräsentiert. Damit kann die Gültigkeit 

von Formeln und die Zulässigkeit von Prozessen zu gewissen Zeitpunkten direkt modelliert werden. 

Wir können damit auch unterschiedliche Klassen von dynamischen Integritätsbedingungen einführen. Dafür werden 

der Zeitrahmen ZR Schritt = ( { {i} |i ∈ IN } , { ({i}, {(i + 1)}) |i ∈ IN }) und 

ZR Punkt = ( { {i} |i ∈ IN } , ∅) , sowie ZR Voll = ( IN , IN × IN) eingeführt. 

Transitionsbedingung: Eine Formel α heißt Transitionsbedingung, falls α notwendig gültig in allen Intervalle von 

ZR Schritt ist. 

Wir notieren Transitionsbedingungen auch durch α −→ next α . 

Allgemeine Vor- und Nachbedingung: Ein Paar von Formeln α und β heißt Vor- und Nachbedingungen falls aus 

(R C , l R , i, ZR Punkt ) |= □α die Gültigkeit von (R C , l R , i + 1, ZR Punkt ) |= □β folgt. 

IS ADD


Wir notieren allgemeine Vor- und Nachbedingungen auch durch α −→ next β . 

Wird der Zeitrahmen durch die Anwendung eines Prozesses P oder Programmes P definiert, dann schreiben 

wir α −→ P β . 

Temporale Formeln sind mit (R C , l R , i, ZR Voll ) |= □β bzw. (R C , l R , i, ZR Voll ) |= ♦β im Sinne der Modallogik 

notwendig oder möglich gültig. 

In analoger Form können damit auch allgemeine Gültigkeiten temporaler Formeln eingeführt werden: 

∀ f : immer (in der Zukunft) 

∀ p : immer (in der Vergangenheit) 

∃ f : einmal (in der Zukunft) 

∃ p : einmal (in der Vergangenheit). 

U(α, β) : 

α ist gültig bis β gültig wird. 

Weiche (deontische) Integritätsbedingungen werden für ZR Schrit eingeführt: 

Obligation: Eine Obligation Oα ist durch die Gültigkeit von (R C , l R , 1, ZR Schritt ) |= □α definiert. 

Erlaubnis: Eine Erlaubnis Pα ist durch die Gültigkeit von (R C , l R , 1, ZR Schritt ) |= ♦α definiert. 

Verbot: Ein Verbot Fα ist durch die Gültigkeit von (R C , l R , 1, ZR Schritt ) |= □¬α definiert. 

Wir können daraus direkt einige Ableitungsregeln ableiten: 

KD0 : Jede Formel der HERM-Logik ist eine deontische Formel. 

KD1 : O(α → β) → (Oα → Oβ) 

KD2 : Oα → Pα 

KD3 : Pα ↔ ¬O¬α 

KD4 : Fα ↔ ¬Pα 

Obligationen umfassen Erlaubnisse. 

Die Erlaubnis ist dual zur Obligation. 

Verboten heißt “nicht erlaubt”. 

Weitere allgemeingültige Formeln der deontischen Logik sind z.B.: 

Oα ↔ ¬P¬α 

O(α ∧ β) ↔ Oα ∧ Oβ 

¬(Oα ∧ O¬α) 

P(α ∨ β) ↔ Pα ∨ Pβ 

(Oα ∨ Oβ) → O(α ∨ β) 

Oα → O(α ∨ β) 

P(α ∧ β) → Pα ∧ Pβ 

Fα → F(α ∧ β) 

(Oα ∧ Pβ) → P(α ∧ β) 

(Oα ∧ O(α → β)) → Oβ 

(Pα ∧ O(α → β)) → Pβ 

(Fβ ∧ O(α → β)) → Fα 

Fβ ∧ Fr ∧ O(α → (β ∨ γ)) → Fα 

¬(O(α ∨ β) ∧ Fα ∧ Fβ) 

(Oα ∧ O((α ∧ β) → γ)) → O(β → γ) 

O(¬α → α) → Oα 

IS ADD


Oβ → O(α → β) 

Fα → O(α → β) 

O¬α → O(α → β) 

¬α → (α → Oβ) 

¬O(α ∧ ¬α) 

(Oα ∧ O(α → β) ∧ (¬α → O¬β) ∧ ¬α) ↔ false 

α → β / Oα → Oβ 

Wir werden uns jedoch im weiteren auf Transitionsbedingungen und Vor- und Nachbedingungen konzentrieren, 

sowie auf weiche Integritätsbedingungen der deontischen Logik. 

Treatment of Integrity Constraint Management by Separation into Levels 

Our framework for integrity constraint mangement is based on a separation of concerns. The Encyclopedia Britannica 

[SYea03] defines a framework as a basic conceptual structure (as of ideas) or a skeletal, openwork, or structural frame. 

It is thus based on a structure, usually rigid, serving to hold the parts of something together or to support something 

constructed or stretched over or around it. It combines structuring in the sense to make up something of more or less 

interdependent elements and having a definite organizational pattern composition based on the anatomy and skeleton 

of the system, and integration or arrangement of all aspects during construction. 

A framework thus provides a comprehensive set of constructs and rules for their application that serve as the 

background for constructing applications. A IC-driven framework is the result of applying a integrity constraint 

management approach during database development. We may systematically separate a number of concerns according 

to the classical project management frame: 

◦ ‘what’ (level 1) provides a specification; 

◦ ‘how’ (level 2) defines the way the framework is going to work; 

◦ ‘do’ (level 3) prescribes the application of the assessment; 

◦ ‘plan’ (level 4) provides the methodology for the application; 

◦ ‘manage’ (level 5) allows the governance of the integrity constraint framework; 

◦ ‘coordinate’ (level 6) integrates the framework into the entire development process; 

◦ ‘optimize’ (level 7) revises the constraint management. 

Classical constraint management is based on a separation of concern into 

1. conceptual specification of the integrity constraint (what), 

2. logical enhancement of constraints by enforcement strategies such as on delete cascade, assertions, 

triggers, or stored procedures (how), and 

3. DBMS extensions for control and scheduling of constraint enforcement. 

We claim that this kind of constraint enforcement is far too restricted and is not properly understood by the application 

programmer. Therefore we need to introduce another explicit framework for constraint enforcement. 

Our framework is currently based on a four-level model: 

1. The specification level is used for a description of integrity constraint . The description consists of a specification 

of the integrity constraint property, the measurement, and the policies for evaluation. It can be extended by 

specific policies for various development methods such as agile development, by transformations of integrity 

constraint properties into others, and by associations among integrity constraint properties. Finally, we may 

derive constraints for the application of the integrity constraint property. 

IS ADD


2. The control or technical level deals with the application of the integrity constraint model. It provides guidance 

for the control procedures such as setting the control management, deriving the scope of control, definition of 

the control tasks and its actors. The application of the integrity constraint framework is based on a integrity 

constraint property portfolio. The portfolio has been formally described in [ST07] and consists of tasks and the 

necessary supporting instruments. They generalize portfolio known in project management. We have developed 

techniques and methods for applying integrity constraint checks and deriving a integrity constraint evaluation 

plan. 

3. The application or technology level handles the management of integrity constraint evaluation within the database 

system. 

4. The establishment or organizational level is based on a methodology and may be supported by a integrity 

constraint maintenance system. 

This four-level framework for integrity constraint management can be extended by level five that provides facilities for 

handling satisfaction of integrity constraint properties and for predicting changes in satisfaction whenever databases 

evolves. Level six integrates integrity constraint management into the optimisation of the database system. Level 

seven uses experiences gained for evolution of databases. 

Modes of Integrity Constraint Handling 

Master-Slave Enforcement. 

Handshaking Enforcement. 

Conveyer-Based Integrity Enforcement. 

Overlay Graphs for Integrity Constraints 

Extended ER Models. 

Overlay Graphs Defined by Cutouts of EER Schemata. 

IS ADD


3.4 Verhaltensmodellierung 

Ein Informationssystem besteht aus verschiedenen Teilen. In DBS meist nur struktureller Teil korrekt modelliert. Es 

lassen sich verschiedene Sichten auf ein IS unterscheiden: 

Vermarktungssicht kein Teil eines Verhaltensmodells im Gegensatz zu den weiteren Teilen 

Problemdefinition 

Verkaufsdokumente 

Vermarktungsplanung 

Operationale Sicht Systemausrichtung 

Kontextdiagramme 

Ereignisdiagramme 

Datensicht Datenwörterbuch 

ER-Definition 

Architektursicht Diagramme der Szenarios 

Spezifikation der Szenarios 

Zustandsdiagramme 

Verhaltenssicht Verhaltensdiagramme 

Verhaltensspezifikation 

Prozeßsicht Datenflußdiagramme 

Steuerflußdiagramme 

Prozeßspezifikationen 

Darstellungsmethoden 

Datenflußdiagramme i.a. als Mehrebenendarstellung für unterschiedliche Abstraktionsebenen 

Kontextdiagramme zur Darstellung der Input/Output-Datenströme ohne Aufzeigen der Struktur 

Dialogflußdiagramme zur Darstellung des interaktiven Verhaltens 

Datenflußmodellierung zur Darstellung der Hauptprozesse; 

Zurückführung auf primitive Funktionen 

mit Gruppierung der Daten und Prozesse 

Schichtung und Herstellung der Konsistenz in Diagrammen in verschiedener Detailiertheit 

Erweiterungen zu Real-Time-Systeme mit einer expliziten Modellierung der Steuerung (Steuerprozesse, 

Zielprozesse) und des Steuerflußes 

Datendefiniton wie bereits oben 

Prozeßspezifikation zur Modellierung der Datentransformation und Datenverarbeitungspolitik in verschiedenen 

Darstellungssprachen 

Struktogramme, Programmlogik Verzweigung, Schleifen, Verkettung mit Blockbildung 

Strukturierte natürliche Sprache bzw. Pseudocode mit Verben, die imperativ sind, Wörtern, die durch ein 

Wörterbuch begrenzt sind, und einigen logischen Konstrukten zur Darstellung der Entscheidung in Verzweigungen, 

der Wiederholung, der Gruppierung, sowie der Input/Output-Darstellung und der Fileverarbeitung


Allgemeine Aufrufe zur Verarbeitung 

Suspendierung, Termination, Kommentare 

Entscheidungsbäume und -tabellen mit Entscheidungsregeln 

Charts und Graphen zur Darstellung der Abhängigkeit 

Damit allgemeines Verhaltensmodell: 

Motive Ereignisse Szenarios Verhaltensmuster 

zu jeweils einem Motiv zu jeweils einem Ereignis zu jeweils einem Szenario 

Geschäftsprozeß Handlungen Prozesse 

Motivations- Geschäftsprozeß- Aktions- konzeptionelle 

schicht schicht schicht Schicht 

Installation Petrinetze Interfaces Modellierung 

Pflege über Sichten Constraints von Programmen 

Adminstrier. Beziehungen Automatendiagr. 

Benutzung Aggregationen Aktionsdiagr. 

Operationale Integr. Unabhängigk. 

Datenintegrität temp. Sichten 

Operationale Sicht Architektursicht Verhaltenssicht 

Es fehlt hier im Schema jedoch die Implementationsschicht. 

Programme als Verfeinerung der Prozesse. 

Operationale Sicht eines Systems als ‘Customersicht’, wie der Benutzer System sehen möchte; darauf aufbauend, 

warum der Benutzer eine bestimmte Funktion erwartet 

Operationen und Motive (Grund für ein Ereignis und erwartetes Resultat) 

7 verschiedene Erwartungen: Installation, Pflege, Administrierung, Benutzeroperationen, Garantierung 

der Integrität, Fortführung der Funktionalität (operationale Integrität), Benutzerinterface 

Dynamische Integritätsbedingungen, Transitionsbedingungen, Anforderungen über Operationsbedingungen 

(externe Faktoren, die System und Operationen begrenzen), Operationsbegrenzungen (Kapazität, Leistungsparameter, 

Zuverlässigkeit, Sicherheit, Zeitbegrenzungen, Interface) 

Spezifikation der Operationsumgebung (Zugriff woher), Kosten (die der Benutzer bereit ist zu zahlen), 

Lieferintervall (wie lange ist der Benutzer bereit zu warten) und Kapazität (TA’s/sec, Kommunikationsaufwand, 

Speicheraufwand,...) 

Systemanforderungen deklarative: 

Leistungsanforderungen der Benutzer 

Zuverlässigkeitsanforderungen der Benutzer für durchgängigen Betrieb (Ein-Prozessor, Dual-Prozessoren 

(einer als stand-by), Prozessorendopplung) 

Sicherheitsanforderungen für Systemzugriff, ... 

Zeitbeziehungen zwischen Operationen des Systemes, wait-Schleifen 

Externe Schnittstellen mit Help etc. 

Andere Anforderungen 

Ereignis - Änderung im System oder Umgebung, die eine Aktivität auslöst oder durch System auslöst 

Externe Ereignisse System reagiert auf externe Ereignisse mit Input (stimulus) und generiert Output (response); 

haben Motiv



Motive, Ideen, 

Aufgaben, Workflow 

Operationale Sicht - Geschäftsprozeßschicht 

Datensicht 

HERM-Diagramme 

Geschäftsprozesse 

Verhaltensdiagramm 

Systemnutzen 

Kontextdiagramm 

Ereignisdiagramm 

Grobentwurf 

Grobes 

HERM-Schema 

Für jedes Ereignis 

... 

Architektursicht - Aktionsschicht 

✮ 

✙ 

Handlungen❄ 

... 

Szenariospezifikat. 

Szenariodiagramm 





Vorentwurf 

Skelett- 

HERM-Schema 

Verhaltenssicht - Konzept. Schicht 

✮ 

✙ 

Für jeden Prozeß 

... 

... 

Prozesse 

❄ 

Verhaltensspezifikat. 





Konzeptionelles 

Schema 

HERM-Schema 

Für jedes Programm 

... 


✮ 

✙ 

... 

Programme❄ 

Programmspezifikat. 

Programmdarstellung 





Phys./Log. 

Datensicht 

DBMS 

Data 

Dictionary 

Abbildung 9: Das Prozeß-Struktur-Codesign-Modell mit Abstraktionsschichten


Temporale Ereignisse bedingen Systemaktivität (Trigger etc.) aufgrund Auslösungsmechanismus (Zeit etc.) (interne 

Motive) 

Interne (anormale) Ereignisse , die durch System erkannt werden (interne Organisation zur Herstellung der Leistung, 

...) 

Motive und Ereignisse als Benutzersicht des Systems ⇒ 5 Motive 

Installationsmotive Installation, Update, Setzen von Systemparametern, Initialisierung von Datenbeständen, 

etc. 

Berücksichtigung im Installationsdialog 

Pflegemotive bei neuen releases, Datenbackup, Recovery ... 

Administrative Motive : neuer Benutzer, Systembenutzung (-mißnutzung), Datensicherheit, temporale Ereignisse 

hinzufügen 

Benutzungsmotive , die zur Notwendigkeit des Systems führen 

Integritätspflege 

Beziehungen zwischen Ereignissen zur Behandlung der Komplexität der Benutzererwartungen 

Entities und Ereignisse Behandlung durch Ereignisdiagramme in Petrinetzdarstellung (Ereignisse und Sichten) 

mit Input/Output in Eventknoten 

Knoten = Ereignisse ∪ Sichten 

Kanten = Ereignisse × Sichten 

Output von Ereignissen, Input von Sichten 

Sichten × Ereignisse 

Output auf requests an 

andere Ereignisse 

Sichten werden aufgefaßt als Input/Output-Generator 

Mehrfachinput kann in ‘and’-Form für Ereignisse aufgefaßt werden 

Mehrfachinput an Sichten ist eine ‘or’-Form zum Anstoßen 

Unabhängigkeit von Ereignissen zur sauberen Modellierung 

falls Daten zwischen Ereignissen ausgetauscht werden müssen, dann über temporale Sichten 

Adminstrative Beziehungen zwischen Ereignissen können über temporale Sichten ebenso modelliert werden 

(als shared Zwischenspeicherung) 

Aggregationen von Ereignissen zur Darstellung der Auslösung mehrerer Zwischenereignisse 

Direktive Beziehungen von Ereignissen zur Darstellung der Auslösung eines Ereignissen durch Steuerfluß 

oder Datenfluß eines anderen Ereignisses 

Als generellen Überbau: Benutzerschnittstellen werden analog spezifiziert. 

Außerdem werden Sichten für die Ereignisse abgeleitet. 

3.5 Alternative Konzepte zur Verhaltensspezifikation und zu Workflows 

3.5.1 Ereignisgesteuerte Prozeßketten 

Graphische Darstellungstechnik zur Darstellung von Geschäftsprozessen und Arbeitsabläufen 

Knoten beschreiben 

Funktionen (als abgerundete Rechtecke dargestellt) 

Ereignisse (als Sechsecke) [gemeint sind eigentlich Zustände] 

Verknüpfungsoperationen (dargestllt mit Kreisen)


Kanten von Funktion zu Ereignis bzw. Ereignis zu Funktion 

wobei Funktionen 

von einem Zustand oder mehreren Zuständen ausgelöst werden und 

ein Zustand einen oder mehrere Zustände erzeugt 

Ein Zustand kann 

von einer Funktion oder mehreren Funktionen ausgel¨st werden und 

eine Funktion oder mehrere Funktionen auslösen. 

Verknüpfungsoperationen als logische Verknüpfungen 

UND (in der Bedeutung “sowohl als auch”), 

XOR (in der Bedeutung “entweder oder”) 

OR 

(nicht für die konzeptionelle Modellierung geeignet) 

geeignet für Darstellung während der Anforderungsanalyse 

Antrag zur 

Bearbeitung 

liegt vor 

✲ 

XOR 

✛ 

❄ 

AND 

❄ 

❄ 

Antrag 

prüfen 

Nebenbedingungen 

prüfen 

❄ 

❄ 

❄ 

XOR 

❄ 

❄ 

XOR 

❄ 

Unterlagen 

unvollständig 

Unterlagen 

vollständig 


erfüllt 


nicht erfüllt 

❄ 

Weitere 

Unterlagen 

beschaffen 

❄ 

Weitere 

Unterlagen 

liegen vor 

✲ 

AND 

❄ 

Vertrag 

genehmigen 

❄ 

✛ 

Antrag 

genehmigen 

❄ 

Vertrag nicht 

genehmigen 

❄ 

Antrag 

abgelehnt


Probleme der EPK- und der Petri-Netz-Spezifikation. 

Aufblähung der Spezifikation durch alternierende Darstellung von Funktionen und Zuständen 

Blockdiagramme zur Darstellung der Funktionen 

Fehlende Abstraktion und damit Forderung nach feingranalarer Darstellung 

Fehlende Hierarchien und damit nichtsichtbare Schichtung 

Funktionsbäume als Alternative 

Fehlende zeitliche Schichtung bei Abhängigkeiten der Ereignisse vom Zeitverlauf 

Balkendiagramme (Gantt charts) zur 2D-Darstellung von Ereignis und Zeit(intervall) 

Fehlende Integration mit Organisationsstruktur 

Rasterdiagramme (Ereignisfolgendiagramme) zur Darstellung der Vorgangsbearbeitung als Tabellendarstellung 

von Organisationsstrukturen und Aktionen mit Beziehungsgraphen der Zellen 

Überwindung dieser Nachteile durch Anreicherung 

Akteur 

(Stelle, Rolle) 

✲ 

Funktionerweiterung 

✛ 

✲ 

Output-Daten 

Input-Daten 

Hauptproblem: Bruch in den Paradigmen 

3.5.2 Zustandsbasierte Spezifikation des Verhaltens 

Anforderungen an Spezifikation des Verhaltens 

Visualisierung des Verhaltens 

Verfeinerung und Kompositionalität mit induktivem Aufbau 

Rigide Semantik zur eindeutigen Interpretation 

Interoperabilität mit anderen Spezifikationen insbesondere zum Austausch 

Akzeptanz und breite Verwendung 

statecharts (David Harel) 

in Verallgemeinerung des deterministischen endlichen Automaten 

Zustandübergang 

Transition 

zwei Zustände 

auslösendes Ereignis, 

für Transition notwendige Bedingung, 

durch die Transition ausgelöste, meist externe Bedingung


Vor- und Nachteile 

+ einfache graphische Notation 

+ einfache intuitiv verständliche Semantik 

+ theoretisch sauber 

- alle Zustände atomar (Verfeinerung ?, Hierarchisierung ?) 

- keine Unterstützung der Zerlegung 

- Zustandsexplosion 

✛ 

Transition 

✻ 

H 

❄ 

❘ 


Ereignisse [Bedingungen] 

/Aktionen zu Transition 

✲ 

Transition 

Abbildung 10: 


Abstraktion durch Einführung eines Superzustandes, der einige Zustände zusammenfaßt 

enthält Zustandsdiagramm bzw. andere Superzustände 

erlaubt die Vereinfachung mehrfacher Transitionen zu einem Zielzustand durch 

Einführung eines zusammenfassenden Zustandes und Substitution aller Transitionen von Zuständen zum 

Zielzustand durch Transition vom Superzustand zum Zielzustand 

diese Zusammenfassung entspricht dem XOR 

Argumente/Parameter mit zustandsabhängiger Instantiierung 

Transition zur Zustandsüberführung 

Repräsentation einer Zustandsänderung eines Objekts 

i.a. getriggert (gefeuert) durch ein Ereignis 

Konvention: Ereignisse ohne Trigger (?-Transitionen) feuern sofort 

feuern sofort 

von exakt einem Zustand zu einem anderen (oder sich selbst (self-transition)) können nicht unterbrochen 

werden


Wächter (guards) 

Ereignisse (events) 

logische Bedingung 

guarded transition feuert, wenn dies die Bedingung erlaubt 

i.a. kann nur eine Transition feuern; deshalb sind Wächter paarweise exklusiv 

Ereignisse können auch Wächter besitzen 

gekoppelt an einen Zeitpunkt 

Zeitlogik i.a. diskret, mit oder ohne Grenzen, 

geordnet (irreflexiv, transitiv, antisymmetrisch), 

linear (oder verzweigend) 

Punktstruktur mit Präzedenzrelation ( ? , < ) 

Beispiele: 

ein Signal von einem Objekt an ein anderes (delived) 

eine Nachricht, empfangen von einem Objekt (check item) 

zu einer bestimmten Zeit (nach 10 Sekunden (in einem Zustand), 7.12.2004, 18.45 (Chanukkah) 

Ereignisse können Argumente benutzen (deliver to (receiver:Kunde) 

Ereignisse setzen auf dem Schema auf (über Attributen insb.) 

Parallelität von Teil-Statechart 

durch gestrichelte Linie gekennzeichnet 

Gleichzeitigkeit in Zustandsdiagrammen 

ein Objekt kann Verhalten haben, das separierbar ist in unabhängige Komponenten 

anzeigen der Separation durch ‘Gabeln‘ (Fork) (Doppelungssemantik) oder gleichzeitigem (konkurrierendem) 

Superzustand 

History-Funktion 

Operationale Semantik von Statecharts. 

Execution state of statechart (S, T, V): 

subset states ⊆ S of currently active states s.t. 

root of S is in states 

if s in states and type of s is AND then all children of s are in states 

if s in states and type of s is XOR then exactly one child of s is in states 

Execution context of statechart (S, T, V): 

current values of variables defined by val : V → Dom 

Configuration of statechart (S, T, V) : (states, val) 

Initial configuration 

Evaluation of expression in configuration: 

eval(expr, conf ) defined inductively 

Effect of action on context: 

modification of variable values in val 

fire(conf) = set of transitions 

t = (source, target, [cond]/action) with source(t) in states for which eval(cond, conf ) = true


for transition t: 

when t fires: 

a = lca(source(t), target(t)) 

src(t) = child of a in subtree of source(t) 

tgt(t) = child of a in subtree of target(t) 

set of left states source ∗ (t): 

• src(t) is in source ∗ (t) 

• if s in source ∗ (t) then all children of s are in source ∗ (t) 

set of entered states target ∗ (t): 

• tgt(t) and target(t) are in target ∗ (t) 

• if s in target ∗ (t) and type of s is AND then all children of s are in target ∗ (t) 

• if s in target∗(t) and type of s is XOR then exactly one child of s with initial transition is in target∗(t) 

For a given configuration conf = (states, val) a successor configuration conf ′ = (states ′ , val ′ ) is derived by selecting 

one transition t from fire(conf ) with the effect: states ′ = states–source ∗ (t) ∪ target ∗ (t) val ′ captures the 

effect of action(t) and equals val otherwise 

Theorem 2 The operational semantics of a statechart (S, V, T) is the set of all possible executions along configurations 

conf 0 , conf 1 , conf 2 , ... with initial configuration conf 0 and conf i+1 being a successor configuration of conf i . 

Verfeinerung von Statecharts. 

Das Zustandsdiagramm in Bild 11 

completed 

login 

✛ 

login 

request 

disabled 

login 

✛ 

❄ 

enabled 

login 

offer 

✲ 

offered 

lecture 

completed 


✛ 

commit 

❄ 

validated 


Abbildung 11: Abstrakter Statechart zur Vorlesungsplanung 

wird durch das Zustandsdiagramm in Bild 12 verfeinert. 

Vor- und Nachteile. 

Wann sollte man Zustandsdiagramme nutzen? Von Nutzen bei Beschreibung des Verhaltens von Objekten über 

mehrere Anwendungfälle hinweg. sowie bei Klassen, deren Verhalten noch nicht wohlverstanden ist.


reset 

state 

✻ 

❄ 

disabled 

login 

✕ 

❘ 

completed 

login 

❄ 

unknown 

user 

send name 

❄ 

name 

known 

send password 

❄ 

known name, 

password 

✛ 

✲ 

renew 

login 

✻(count ≠ 0) 

(count 

counter =0) ✲ reject 

check 

login 

✻(false) 

login (true) ✲ 

validated 

✻{count:=3} 

login 

unclear 

✛ 

H 

✻ 

correct 

login 

enabled login 

✻ 

login 

accepted 

✲ 

✛ 

correct 

login 

✠ 

roles, rights 

unclear 

{ role, right 

generation ❄ } 

roles, rights 

assigned 

✛ 

Abbildung 12: Verfeinerung des Statechart für das Login


Wann sollte man Zustandsdiagramme nicht nutzen? Beschreibung des Verhaltens von mehreren Objekten, die 

innerhalb eines Anwendungsfalles auftreten (dann Interaktionsdiagramme) 

Beschreibung der Verhaltens mehrerer Anwendungsfälle und mehrerer Objekte (dann Aktivitätendiagramme) 

Beschreibung des Verhaltens von kooperierenden Objekten 

3.5.3 Top-down-Beschreibung 

Szenarien, Architektur und Zustände. 

Nun Modellierung der Erwartungen für jedes Ereignis. 

Alle möglichen Szenarios können nicht entworfen werden. 

In Datenbanksystemen werden Szenarios durch Transaktionen (siehe spezielles Kapitel) dargestellt (evt. mit Teiltransaktionen, 

aber ohne Wiederholungen, expliziter Parallelität). 

Architektursicht der Daten- und Prozeßorganisation 

alle Ereignisse werden durch Prozessoren unterlegt 

Prozessorschnittstellen Kommunikationsschnittstellen (keyboard, display) und Schnittstellen mit dem Informationssystem, 

sowie externen Benutzer 

Technologische Beschränkungen und Bedingungen der Kommunikationskanäle, der Input/Output-Geräte, 

der Prozessoren, der Speicher, der Geschwindigkeit, ... 

Spezifikation der Architekturanforderungen Prozessoren, Zuverlässigkeit, Prioritäten, Leistung, Kapazität, 

Zeitbeziehungen, Interface, Sicherheit, fail-safety, safety, ... 

dokumentiert in Szenario-Spezifikation, Szenariodiagramm 

Szenario - Menge von I/O-Datenströmen, Steuerströmen, Verhalten eines Ereignisses 

Endliche Automatten als Darstellungsmittel als spezifische Darstellungsform 

Zustand eines Informationssystemes 

Zustandsüberführungsdiagramme mit I/O-Kanten 

Zustandsüberführungstabellen in klassischer Form 

Statecharts als State-Transition-Diagramme mit concurrency, Hierarchisierung und Kommunikation 

D. Harel, Statecharts: A visual formalism for complex systems. North-Holland, New York, 1987 

Aktionsdiagramme in Szenarios oder Struktogramme zur Spezifikation der Programmabläufe in Szenarios (mit 

Erweiterung für parallele Handlungen) 

Verhaltensmuster (Skripte). 

als Programme auf der Grundlage expliziter atomarer Operationen 

Verhaltenssicht eines Systemes zur Modellierung der Benutzererwartungen und der Prozesse 

Benutzererwartungen Dekomposition in kleine (möglichst atomare) Programme 

Audio/Visuelle Aktione, Send/Receive-Signale, Accept/Transmit Daten, Store/Retrieve Daten, Berechnungsresultate, 

logische Resultate 

Prozeßbeschränkungen technologische Beschränkungen, Beschränkungen der Technik, Beschränkungen 

der Kommunikation


Verhaltensanforderungen Prozeßanforderungen, Prioritäten, Leistungsanforderungen, Zeit, fail-safety, safety, 

negotiale Anforderungen (was sollte keinesfalls passieren), ... 

Verhalten als Basisaktivitäten des Systems; komplexes Verhalten als Teilsysteme; 

Definition von Verhalten über Programme über Aktivitäten 

Benennung von Verhalten z.B. input, output, verify, activate, calculate, terminate, logische Ableitung 

Erweiterungen Luxus am Anfang 

Flexible Systeme 

Kontrolle der Erwartungen, Einbettungen 

Aktionsdiagramme definieren Verhaltensmuster 

Systemerweiterungen inkrementelle 

CRC Cards. 

CRC = Class - Responsibility - Collaboration 

innerhalb einer Geschäftsprozeßschicht: keine Interface-Spez. 

Operationen: prinzipielle Verantwortlichkeiten einer Klasse 

Verantwortlichkeit 

high-level Beschreibung des Zieles der Klasse keine Orientierung auf Daten, Prozesse 

Darstellung des Zieles, Motivation 

Kollaboration ( (in Zusammenarbeit mit) Verantwortlichkeiten mit anderen Klassen 

Verbindungen mit anderen Klassen 

Trick: auf Karteikarten kann nur begrenzte Information. 

Günstig für Beschreibung der Schnittstellen der Klassen, insbesondere deren Verhalten, sowie bei Teamentwicklung. 

Anwendungsfall durch ein oder mehrere Karten 

Kooperationen zwischen Objekten 

Objekt kann Verantwortlichkeit selbst erfüllen vs. benötigt Fähigkeiten anderer Objekte (–¿ Kooperation) 

Kooperationen modellieren die Interaktion zwischen Objekten (Daten- und Kontrollfluß) 

Rolle der Objekte (Anbieter / Kunde) bezüglich der Kooperation wird bestimmt 

(abgeschlossene) Teilsysteme können identifiziert werden 

Kooperationen finden 

1. Für jede Verantwortlichkeit einer Klasse überlegen: 

kann die Klasse die Verantwortlichkeit selbst erfüllen ? 

falls nicht: welche Informationen /Fähigkeiten werden benötigt und welche andere Klasse stellt diese bereit ? 

2. Für jede Klasse bestimmen: 

was tut oder weiß diese Klasse ? 

welche anderen Klassen benötigen diese Fähigkeiten ? 

stimmt die Rolle (Anbieter / Kunde) der Klasse ? (z.B. phys. Geräte sind typischerweise Anbieter) 

kooperiert die Klasse mit mindestens einer anderen Klasse ? (falls nicht, ist die Klasse offenbar überflüssig !) 

3. weitere Beziehungen zwischen den Klassen analysieren 

besteht-aus (Aggregation) 

Komposition 

Behälter-Klassen (z.B. Array, geordnete Menge) 

kennt (Assoziation)


Benutzung 

“hole Information von” Kooperationen 

hängt-ab-von 

gibt Hinweise auf Kooperationsketten 

3.5.4 Spezifikation auf unterschiedlichen Abstraktionsschichten 

Ablauf eines Spezifikationsschrittes: 

Spezifikationsmakro 

Geschäftsproblem und Analyse 

Beschreibung des Geschäftsprozesses 

Beschreibung der Lösung für den Geschäftsprozeß 

Verfeinerungsmakro 

Ableitung des Entwicklungproblemes 

Beschreibung des Software-Problemes 

Beschreibung der Softwareanforderungen mit anschließendem Makroschritt zu Verfeinerung 

Dekompositionsmakro 

Ableitung des Dekompositionsproblemes 

Beschreibung des Dekompositionsproblemes 

Lösung des Dekompositionsproblemes 

Geschäftsprozesse auf der Strategieschicht 

Konzepte als Grundkonstrukt. 

Name Intention Bestandteil Verantwortlichkeit Ausschlußregeln 

Ersteintrag Bereitsstellung schrittweiser Eintrag von Unterstützung von Einträgen, 

keine Planung, keine 

erster Angaben 

Daten 

Wiederbenutzung Konsistenzkontrolle, keine 

zu neuen 

vorhandener Daten Synchronisation 

Vorlesungen 

... ... ... ... ... 

Spezifikation analog zu CRC-Karten 

Beschreibung der allgemeinen Ziele. 

Geschäftsprozesse auf der Anforderungsschicht 

Zusammenhänge von Geschäftsprozessen 

Geschäftsprozeß 

Geschäftsfalldaten 

Geschäftsdialoge 

Sichten auf diese Daten Obligationen zur Pflege


Arbeitsschritte als Grundkonstrukt. 

Spezifikationsrahmen für Arbeitsschritte 

Name Auslöser org. Einheit Tätigkeit Hilfsmittel, 

Zusatzinformationen 

Ablage / 

Adressat 

... ... ... ... ... ... 

Wir wählen hier einen ereignis-orientierten Zugang. Der Zusammenhang von Entities und Ereignissen wird 

durch Ereignisdiagramme in Petri-Netz-Darstellung (Ereignisse und Sichten) mit Input/Output in Eventknoten dargestellt. 

Knoten sind Ereignisse oder Sichten bzw. in einfachen Fällen Teilschemata. Kanten verlaufen von Ereignissen 

nach Sichten bzw. von Sichten nach Ereignissen. Sichten werden aufgefaßt als Input/Output-Generatoren. Ein Mehrfachinput 

kann in ‘and’-Form für Ereignisse aufgefaßt werden. Ein Mehrfachinput an Sichten ist eine ‘or’-Form zum 

Anstoßen. Damit ergibt sich eine Petri-Netz-Darstellung wie in Bild 13. 

als 

Sender 

gedeutete 

Sichten: 

Mitteilung 

ermittelt 


als Erstellung 

und Übertragung von 

Mitteilungen 

gedeutete Transition 

als 

Empfänger 

gedeutete 

Sichten 

eingehende 

Mitteilungen 

Auslösung 

von 

anschließenden 


✲ 

✯ 

✲ 

... and 

❥ 

✯ 

Transition 

... 

✲ 

❥ 

✲ 

Abbildung 13: Petri-Netz-Darstellung von formalen Handlungen 

Auf der Grundlage der Darstellung in Bild 13 können wir ein Aufgabenmodell entwickeln. Wir werden dieses 

Aufgabenmodell noch für die Spezifikation der Interaktivität durch Arbeitsvorgänge, Aktivitäten und Aktivitätenfolgendiagramme 

erweitern. Ein Arbeitsvorgang besitzt eine allgemeine Struktur, ein Resultat und semantische Rahmenbedingungen. 

Ein Arbeitsvorgang im Rahmen eines Geschäftsprozesses wird durch 

einen Namen, 

einen Auslöser, der die Ausführung der im Arbeitsvorgang genannten Tätigkeiten auslöst (Zeitpunkte, 

eingehende Daten, Unterlagen, ...), 

eine organisatorische Einheit, die eine Aufgabe durchführt, 

eine Tätigkeit der Benutzer bzw. einen Ablauf von Tätigkeiten der Benutzer, 

verwendete Hilfsmittel und Zusatzinformationen, die diese Tätigkeiten unterstützen, und 

einer Ablage und einem Adressaten, 

beschrieben. 

in die oder an den Ausgaben erfolgen,


Als Beispiel einer Aufgabe können wir die Erstellung eines Vorlesungsangebotes in unserem Hauptbeispiel betrachten. 

Ein Beauftragter eines Lehrstuhles erhält eine Aufforderung zur Erstellung von Angeboten zu einer Vorlesung. 

Die organisatorische Einheit ist der Lehrstuhl einer Universität. Hilfsinformation und Zusatzinformation sind 

die Angaben zu den angeforderten Kursen oder zu den neu angebotenen Kursen. Damit kann der Geschäftsvorfall so 

wie in Bild 14 dargestellt werden. 

Aufforderung 

Eintrag 

Kontrolle 

Abschluß 

✲ zum 

✲ der Daten zur ✲ der Daten zur ✲ der Angabe zur ✲ 

Eintrag 

Lehrveranstaltunanstaltung 

Lehrver- 

Lehrveranstaltung 

Abbildung 14: Geschäftsvorfall: Erstellung eines Angebotes für eine Lehrveranstaltung 

Diese Graphik kann auch durch weitere Einzelschritte untersetzt werden. Anstelle der graphischen Darstellung 

kann auch eine tabellarische Darstellung gewählt werden: 

Geschäftsvorfall: Eintrag einer Lehrveranstaltung nach Aufforderung 

Auslöser Organisatorische Einheit Hilfs- und Zusatzinformation 

Aufforderung für Beauftragten Lehrstuhl Kurse, Studiengänge, Räume 

Tätigkeiten 

für: 

1. Eintrag Beauftragter des Lehrstuhles 

Hauptinformation angeben ; 

(Klassifizieren || Einordnen || sonstige Angaben erfassen || Nebenbedingungen eingeben); 

2. Kontrolle Beauftragter und Mitglieder des Lehrstuhles 

Informationsvergleich von Anforderungen, Angaben und weiteren Daten 

3. Beendigung Beauftragter des Lehrstuhles 

Ablegen am Lehrstuhl ; Absenden an auffordernde Einrichtung 

In analoger Form kann das Verhalten für Einzelobjekte durch eine Lebenszyklusspezifikation mit einem verallgemeinerten 

Petri-Netz-Modell (Prädikaten-Transitionsnetz) oder einem Automatengraphen beschrieben werden: 

Menge von Zuständen: S o für jedes Objekt in der Datenbank; 

Menge von Aktivitäten: T o für jedes Objekt in der Datenbank; 

Diagramm: D ⊆ S o × T o ∪ T o × S o ; 

Vor- und Nachbedingungen zu Aktivitäten: V o (s, t) für (s, t) ∈ S o × T o als Vorbedingung für eine Aktivität und 

N o (t, s) für (t, s) ∈ S o × T o als Nachbedingung für eine Aktivität. Damit kann eine Darstellung durch eine 

Hoare-Logik VtN verwendet werden. 

Spezifikation eines Lebenszyklus: (S o , T o , F o , V o , N o ) . 

Nachteilig ist, daß dieser Zugang nur für Einzelobjekte geeignet ist. Durch komplexe Bedingungen kann auch Verknüpfung 

von Lebenszyklen beschrieben werden. Mitunter kann das Zusammenwirken von Objekten eine Komposition 

des Verhaltens verschiedener Objekte erfordern. Der Moment eines Lebenszyklus sind alle Eigenschaften des 

Objektes im Zustand s. 

Beispiel: Personen werden Studenten etc. 

Die Vor- und Nachbedingungen sind nicht in der Zeichnung dargestellt. So gilt z.B., daß für die Exmatrikulation 

sämtliche Beziehungen gelöst werden. 

Die Vertragsgestaltung erbt das Objekt Student vom Objekt Person. Personen sind über Verträge Mitarbeiter von 

Projekten. Bei dieser Vererbung wird auch die Bezeichnung Mitarbeiter überschrieben.


Exmatrikulation 

✲ 

Absolvent 

✒ 

Person ✲ Immatrikulation ✲ Student 

✲ 

Betreuersuche 

✲ 

Student mit 

Betreuer 

Belegt 

Vorlesung 

✠ 

❄ 

Abschluß 

Vertrag 

❘ 

Auswahl 

Nebenfach 

❄ 

Auswahl des 

Themas 

❄ 

❄ 

❄ 

❄ 

Student 

mit Resultat 

HiWi 

Student 

mit Nebenfach 


Abbildung 15: Lebenszyklus eines Studenten in der Datenbank 

Man kann die und-oder Graphen auch weiter verfeinern. (siehe Modellierungskapitel) 

Die Sichtbarkeitsregeln folgen der Sichtendefinition. 

Außerdem kann der Graph auch zyklisch sein. 

Kanten können mehrwertig sein (Z.B. für die Auswahl des Nebenfaches). 

Darstellung von gemeinsamen Verhalten mehrerer Objekte. 

Unterscheidung in aktive Objekte, aktivierte Objekte und passive Objekte 

Entwicklung von Kooperationsverträgen zwischen den Objekten 

Prozesse können sich auch gegenseitig 

bedingen, 

blockieren, 

abweisen, 

starten 

Kopplung. 

Verschiedene Arten von Kopplungsmechanismen: 

Interaktionskopplung 

rufen dieselben Daten ab; rufen sich gegenseitig auf 

dabei verschiedene Kopplungsmechanismen 

• interne Kopplung 

• globale Kopplung 

• externe Kopplung 

• Kontrollflußkopplung


• Wanderdatenkopplung 

• Parameterkopplung 

• keine Kopplung 

Komponentenkopplung 

verschiedene Grade 

• versteckte Kopplung 

• verstreute Kopplung 

• spezifizierte Kopplung 


Vererbungskopplung 

verschiedene Arten 

Kohäsion. 

• Änderungskopplung 

• Signaturänderungskopplung 

• Implementationsänderungskopplung 

• Verfeinerungskopplung 

• Signaturverfeinerungskopplung 

• Implementationsverfeinerungskopplung 

• Erweiterungskopplung 


(Bindung zwischen den einzelnen kooperierenden Objekten) 

verschiedene Arten 

Operationskohäsion 

• zufällige Kohäsion 

• logische Kohäsion 

• temporale Kohäsion 

• prozedurale Kohäsion 

• Kommunikationskohäsion 

• sequentielle Kohäsion 

• funktionale Kohäsion 

Typkohäsion 

• zerlegbare Kohäsion 

• mehrschichtige Kohäsion 

• nicht delegierte Kohäsion 

• verborgene Kohäsion 

Vererbungskohäsion 

Handlungen auf der Benutzungsschicht 

Aktionen als Grundkonstrukt. 

Handlungsabläufe zur Komposition.


Die einzelnen Geschäftsprozesse werden nun mit ihrem Verlauf im Detail dargestellt. Sie können durch Ablaufdiagramme 

dargestellt werden. Handlungen sollen zu einer Veränderung der Datenbank führen oder dem Informationsgewinn 

der Akteure dienen. Akteure sind Abstraktionen von Benutzergruppen, wie z.B. der Beauftragten 

des Lehrstuhls. Wir entwickeln damit allgemeine Änderungsoperationen, Retrievaloperationen und Operationen zur 

Veränderung von Rollen von Objekten mit entsprechenden dynamischen Integritätsbedingungen. Es werden zugelassene, 

erwünschte, verbotene und erzwungene Handlungen dargestellt. Für die einzelnen Akteure gibt es Verpflichtungen. 

Handlungen werden Arbeitsvorgängen bzw. Tätigkeiten zugeordnet. Ein Arbeitsvorgang ist - wie bereits dargestellt 

- durch einen Akteur oder eine Gruppe von Akteuren als Auslöser mit Rollen und Rechten, eine organisatorische 

Einheit, einer Beschreibung der Aktionen in ihrer Abfolge, eine Ordnung und ihren Beziehungen, die verwendeten 

Hilfsmittel und Informationen und die Ablage der Resultate charakterisiert. 

Aus der Beschreibung der Koordination der Handlungen werden dynamische Integritätsbedingungen abgeleitet. 

Spezielle dynamische Integritätsbedingungen sind Methodenregeln, die Aussagen darüber festhalten, wie bestimmte 

Aktionen ausgeführt werden und welche Umgebung (Daten, Akteure, Dialoge) zu ihrer Ausführung notwendig 

ist. Durch Zeitregeln, Ausführungshäufigkeiten und Ausführungspriorisierungen werden die Zeitparameter festgelegt. 

Entscheidungsregeln spezifizieren im weiteren, welche Tätigkeit zu welchem Resultat führen muß, kann bzw. sollte. 

Wir können dazu Entscheidungstabellen benutzen. Es werden aus den Geschäftsfalldaten, d.h. den Daten, die während 

eines Geschäftsprozesses anfallen, und den Geschäftsdialogen entsprechende Entwurfsobligationen für andere Entwurfsschritte 

abgeleitet. Jeder Aktion können aktionsspezifische Integritätsbedingungen zugeordnet sein. Unter den 

Aktionen kann eine Ordnung existieren, die als kausale Abhängigkeit für parallelisierte Aktionen dargestellt wird. 

Weiterhin werden den Handlungen verschiedene Varianten von Aktionen zugeordnet. 

Wir verwenden dazu eine Erweiterung der tabellarischen Darstellung der Tabelle zu Geschäftsvorfällen von Seite 

387. Eine graphische Darstellung wird in den Schritten zur Feinstudie aufgezeigt. Die tabellarische Darstellung stellt 

ein Kollaborationsdiagramm dar und beinhaltet die folgenden Angaben: 

Handlungen des Akteurs 


... ... ... 


obligatorisch erlaubt verboten 

... ... ... 

Methodenregeln 

Ausführung Umgebung Zeitparameter 

... ... ... 

Aktionen des Akteurs 

i. Handlung Akteur 

Rechte Pflichten Rolle 

... ... ... 

i.j. Aktion 

Integritätsbedingung 

... 

Im Detail stellt sich die Entfaltung der Tabelle von Seite 387 wie folgt dar: 

für:


Handlungen des Akteurs: Eintrag einer Lehrveranstaltung nach Aufforderung 


... ... ... 


obligatorisch erlaubt verboten 

Beendigung Bis Termin Entfernung von Angebot Parallelangebot zu anderem Lehrstuhl 

Methodenregeln 

Ausführung Umgebung Zeitparameter 

Mit Unterbrechung, Erinnerungsskripte, 

temporäre Ansicht, Gruppenarbeit, 

Erfolgsmeldung 

Aktionen des Akteurs 

Sitzungsobjekt, Online Interface, 

konfigurierbare Oberfläche 

Temporäre Ablage, wiederholter 

Aufruf, niedrige Priorität 

1. Eintrag von Angeboten zu Lehrveranstaltungen Beauftragter des Lehrstuhles 

Rechte Pflichten Rolle 

Eintrag/Abschluß, Einsicht in vollständige Abarbeitung der Liste 

Datenbereitstellung 

Lehrstuhlangaben, Einsicht in 

Anforderungsliste, Eintragen, 

Streichen und Modifikation von 

Angeboten 

1.1. Entgegennahme der Einzelaufgaben 

1.1.1. Auswahl aus der Aufgabenliste DO UNTIL END Of LIST 

1.1.1.1. Lehrveranstaltungsidentifikation bestätigen 

1.1.1.2. Auswahl der Lehrveranstaltungsart 

1.1.1.3. Bestätigung oder Modifikation der Bezeichnung der Lehrveranstaltung 

1.1.1.4. Bestätigung oder Modifikation der Inhaltsbeschreibung der Lehrveranstaltung 

1.1.1.5. Zuordnung der Lehrenden zur Lehrveranstaltung 

... 

1.1.2. Angaben zur Art der Lehrveranstaltung parallel zu 1.1.3 ... 1.1.6 

1.1.2.1. Angaben zur Art der Durchführung 

.... 

1.1.3. Bestätigung oder Modifikation der Zielgruppe für die Lehrveranstaltung 

1.1.3.1. Bestätigung oder Modifikation des Studienganges 

... 

1.1.6. Angaben zur Nebenbedingungen der Lehrveranstaltung optional 

1.1.6.1. Angaben zu Terminwünschen 

1.1.6.2. Angaben von Parallelveranstaltungen 

.... 

1.3. Zusatzangaben zum Lehrbericht optional 

Diese Tabelle kann als eine Auffaltung oder Verfeinerung der Tabelle von Seite 387 betrachtet werden. Damit 

sind wir in der Lage, die Konsistenz der Entwicklungsschritte direkt zu betrachten. 

Hier kann eine Konformitätsbedingung greifen: Die natürlichsprachige Repräsentation und die formale 

Spezifikation entsprechen sich 1:1. Analoges sollte für die graphische Repräsentation zutreffen. 

Weiteres Hilfsmittel: Dialogspezifikation der Exkurstheorie; Montague’s Syntaxdiagramme 

für:


3.5.5 Verhaltensoptimierung


3.6 Unterscheidung von Funktionalität und Interaktivität 

In klassischen Ansätzen werden Handlungsabläufe zur Spezifikation der Funktionalität und zur Spezifikation der 

Interaktivität auf gleiche Art und Weise durch Workflows dargestellt. Diese Darstellung ist aufgrund einer ganzen 

Reihe von Gründen irreführend und führt zu einem Workflow-Impedance-Mismatch: 

Workflows zur Spezifikation der Funktionalität umfassen auch Prozesse der Systeme, die auf dem Niveau der 

Interaktivität keine Rolle spielen. Deshalb sind Workflows überladen. 

Handlungsabläufe der Realität müssen sich nicht zwingend im Workflow widerspiegeln. Demzufolge werden 

Workflows funktional unvollständig. 

Handlungsabläufe auf Systemniveau und auf Interaktionsniveau unterscheiden sich im Abstraktionsniveau. 

Deshalb besitzen sie eine unterschiedliche Granularität. 

Handlungsabläufe auf Interaktionsniveau stellen auch die Zusammenarbeit von Akteuren dar, die sich nicht 

zwingend im System widerspiegeln muß. Demzufolge sind Workflows organisatorisch unvollständig. 

Workflows zur Spezifikation der Funktionalität sollten den konkreten Handlungsablauf nicht in Beziehung zum 

Kontext setzen. In klassischen Herangehensweisen werden aber die unterschiedlichsten Varianten des gleichen 

Workflows je nach Kontext als eigenständiger Workflow dargestellt. Es entsteht eine Workflow-Lawine, deren 

Beherrschung und Überschaubarkeit nicht mehr gegeben ist. 

Wir bevorzugen dagegen eine Trennung von dynamischen Gesichtspunkten in 

Stories zur Darstellung der Handlungsabläufe auf Interaktionsniveau und 

Workflows zur Darstellung der Handlungsabläufe auf Systemniveau. 

Web IS


3.7 Spezifische Funktionalität 

3.7.1 Workflow-Klassen, Workflows und Workflow-Felder 

Die Beschreibung der Handlungsabläufe lehnen wir dabei an die Formenlehre an. In der Morphologie kann ein Wort 

in allen seinen Variationen dargestellt werden durch 

eine Stammform zur Parametrisierung der unterschiedlichen Dimensionen, wie z.B. Zeitdimension und Akteurdimension, 

die Wortbildung, d.h. durch Regeln zur Assoziation von Wörtern zu komplexeren Ausdrücken wie z.B. Ableitung, 

Zusammensetzung und Abkürzung, und 

die Flexion zur Ableitung von Varianten und zur Erfassung von Ausnahmen. 

Ein morphologisches Merkmal erlaubt die Kennzeichnung der Ableitungsdimensionen eines Begriffes je nach 

seiner Kategorie (Verb, Nomen, Artikel/Pronomen, Adjektiv, Partikel) durch 

Deklination der drei Merkmale 

Kasus, mit dem eine Assoziierung der Worte zu thematischen Rollen und der Art der Assoziierung (Nominativ 

(‘wer’, ‘was’), Akkusativ (‘wen’, ‘wohin’, ‘wie lange’), Genitiv (‘wessen’), Dativ (‘wem’, ‘für 

wen’), Ablativ (‘wodurch’, ‘womit’, ‘von wem’, ‘weswegen’, ‘wann’) und Vokativ (zur direkten Anrede)) 

determiniert wird, 

Genus, mit dem eine Kategorisierung z.B. zum Geschlecht (Maskulinum, Femininum, Neutrum) vorgenommen 

wird, und 

Numerus, mit dem eine Einzelbehandlung oder eine Gruppenbehandlung ermöglicht wird, 

Konjugation zur Instantiierung von n-wertigen (-valenten) Beziehungen mit 

oder 

Numerus zur Assoziierung mit Kardinalität (Singular (card(R,E) = (0,1)), Dual (card(R,E) = (0,2)) bzw. 

Plural (card(R,E) = (0,n))) , 

Personalformen zur Ausrichtung der Beziehung (‘ich’ = →, ‘er’ = , ‘wir’ = ↔), 

Tempus zur zeitlichen Relativierung (Präsenz, Perfekt, Plusquamperfekt, etc.), 

Modus zur Bewertung der Modalität (Indikativ (als Feststellung z.B. durch Teilklasse), Imperativ ((1,1) 

bzw. (1,n)), Konjunktiv I (zur Darstellung der allgemeinen Möglichkeit bzw. Wunsches), Konjunktiv II 

(zur Abgrenzung einer spekulativen Möglichkeit)) und 

Genus verbi zur Darstellung der Beziehungsform (aktiv bzw. passiv) 

Komparation zur Darstellung von Steigerungsformen 

Positiv bzw. einfach positiv, 

Komparativ bzw. Vergleichstufe bzw. Höherstufe und 

Superlativ als Höchststufe sowie 

Elativ als absoluter Superlativ 

und Ausprägungen des Wortes. 

Da wir die Theorie der Wortfelder [Kun92] zu Konzeptfeldern [DT04] bzw. Konzeptrahmen erweitern, wird für 

ein Konzeptfeld eine Kontextualisierung (oder Konjugation) durch Instantiierung der Parameter 

Akteursprofile und -portfolio, 

Wiederholungsprofil, 

Zeitprofil,


deontischer Modus mit imperativen, konjunktiven und indikativen Ausprägungen und 

Aktionsform und Handlungsrichtung zur Darstellung der Beziehung zwischen Akteur und Handlungsablauf 

erreicht. Damit werden insbesondere die Parameter der Stammform des Konzeptfeldes durch entsprechende Werte 

angepaßt. Ein Konzeptfeld ist ein generisches Konzept, aus dem ein Konzept durch Instantiierung einer Reihe von 

Merkmalen abgeleitet wird. Dieser Zugang entspricht in der Theorie der Wortfelder der Komponentenanalyse. Wir 

verwenden diese Ableitungsbeziehung analog zu den Erkenntnissen der Sprachwissenschaft. Wir können z.B. aus 

dem Konzeptfeld Lebewesen wie folgt Konzepte ableiten: 

Lebewesen Belebtheit Kategorie=Mensch Geschlecht=weiblich Lebensalter=Erwachsen ... 

Mann + + - + ... 

Mädchen + + + - ... 

Rüde + - - + ... 

Welpe + - +/- - ... 

Analog kann auch eine generelle Klasse eingeführt werden. 

Diese Beobachtung führte V.J. Propps [Pro72] zu seiner Spezifikation der Märchen. Er stellte z.B. für das Märchen 

Die wilden Schwäne den Ausdruck 

ib 1 a 1 c 1 A 1 B 4 C ↗ {Sch 1 H 1 ¬Z 1 ¬‖sch 7 H 7 Z 9 }W 4 L 1 ↘ V 1 [Sch 1 H 1 Z 9 ≡ R 4 ] × 3 

auf. Die Buchstaben werden jeweils für eine Konzeptfeld verwandt, z.B. I für das Eröffnungsfeld, a für Ortsbewegungen, 

b für Verbote, c für Verletzungen der Verbote, A für Schädigungen, C für eine einsetzende Gegenhandlung, 

↗ und ↘ für Ortsveränderungen, Sch für Schenkungen, H für Reaktionen des Helden, Z für den Empfang eines 

Zaubermittels, ‖ für eine Parallelhandlung, W für eine Wegweisung, L für die Aufhebung des Unglücks, V für die 

Verfolgung und R für die Rettung. Die einzelnen Schritte können durch Annotation auch verfeinert oder negiert werden. 

Außerdem kann eine Wiederholung angezeigt werden, z.B. die dreimalige Wiederholung durch 3. 

Wir unterschieden in Anlehnung an die Theorie der Konzeptfelder zwischen 

Workflow-Klassen, in denen Workflows als Einzelelemente enthalten sind, 

einem Workflow als Objekt einer Workflow-Klasse und 

Workflow-Feldern, mit denen ein Rahmen der Workflow-Klasse angegeben werden kann. 

Ein Typ einer Workflow-Klasse kann aus einer oder mehreren Stammformen bestehen. 

Ein Workflow-Feld besteht aus 

einer Menge von Stammformen, 

einer Menge von dynamischen Integritätsbedingungen denen die Workflows eines Feldes genügen müssen, 

einer Menge von Bildungsformen zur Assoziation mit anderen Workflow-Feldern und 

einer Menge von Flexionen zur Ableitung von Workflows aus dem Workflow-Feld. 

Wir nehmen oft vereinfachend an, daß ein Workflow-Feld nur eine einzige Stammform besitzt. und daß eine Workflow- 

Klasse nur Workflows eines Workflow-Feldes enthält. Sie muß nicht alle möglichen Workflows dieses Feldes enthalten, 

sondern kann auch nur einige (aktuelle) Workflows enthalten. 

Diese Unterscheidung wurde in unserer Arbeit erstmals für eine e-Learning-Site konzipiert. Diese Site erlaubt 

eine Entfaltung einer Lerneinheit je nach Meta-Information, Handlungs-, Akteurs- und Datenkontexten sowie der 

Handlungsvorgeschichte. Damit kann ein Lernfeld als allgemeine Lerneinheit angesehen werden, bei der


die Stammform als Ausdruck über Lernelementen gegeben ist, 

die durch Ableitungsregeln zu einem komplexen Lernmodul erweitert wird, so dass ein Lernender auch seine entsprechenden 

Lernelemente angeboten bekommt, und 

durch Flexion 

die Variantenvielfalt sowie die Ausnahmen auffaltbar sind. Flexionsregeln erlauben eine Erweiterung 

mit dem Akteursprofil und -portfolio, 

mit dem Wiederholungsprofil, 

mit dem Zeitprofil, 

mit dem deontischen Modus und 

mit den Aktionsformen und der Handlungsrichtung. 

Diese Erweiterung wurde bereits in einigen Arbeiten, die Workflow-Spezifikationen aus der Sicht der Praxis 

kritisierten, gefordert. Es wurde insbesondere beobachtet, 

daß ein Arbeitsablauf hoch-parallel ist, 

daß ein Arbeitsablauf eine Rückkopplung mit Wartezeiten erfordert und 

daß die Organisation der Arbeit oft fremdgesteuert ist. 

Wir verallgemeinern diese Formenlehre von Handlungssträngen und führen dazu allgemeine Workflow-Felder 

ein: 

Das Eröffnungsfeld ist gekennzeichnet durch 

die Darstellung des Kontextes, der bei Assoziation des Workflow-Feldes mit anderen Feldern den Kontext 

dieser Felder dominiert, 

die Darstellung der Akteure, 

die Darstellung der Situation und 

die Assoziation mit Sichtentypen sowohl für die Input- als auch die Retrieval- als auch die Outputdaten. 

Das Ausgangsfeld dient zur Meta-Spezifikation und erlaubt außerdem noch eine Einbettung der räumlichen und 

zeitlichen Rahmenbedingungen sowie auch der Motivation und der Ursachen. 

Das Handlungsschrittfeld wird spezifiziert durch 

die Angabe der Verbindungsparameter, 

die Angabe der Begleitelemente und Kontextbedingungen, 

der Rollen der Akteure und 

Sichtentypen. 

Das Übergabefeld erlaubt den Übergang von Objekten einer Sicht eines Akteurs auf Objekte einer Sicht eines 

anderen Akteurs. Zusätzlich kann der Kontext und auch der Vertrag des Überganges spezifiziert werden. 

Das Arbeitsfeld erlaubt die Bearbeitung von Daten über den Sichtentypen und deren Versand an andere Akteure 

bzw. deren Einbringen in das System. 

Neben diesen Basisfeldern können wir auch Konstruktionsfelder spezifizieren, mit denen Felder kombiniert werden 

können: 

Das Verzweigungsfeld unterstützt eine Verzweigung von Workflows in synchronisierte Workflows, die parallel 

unter Einhaltung der Synchronisationsbedingungen ablaufen können. 

Das Wiederholungsfeld stellt den Rahmen für eine wiederholte Ausführung eines Workflows. 

Das Bulk-Feld ist an Parameter gebunden, für die das Workflow-Feld insgesamt abgearbeitet wird. 

Wir haben diese Theorie der Workflow-Felder mit den Kompositionsoperationen für Workflows harmonisiert, damit 

wird eine entsprechende Entfaltung der komplexen Workflow-Felder vornehmen können.


3.7.2 Generische Modellierung, generische und entfaltbare Workflows 

Combining the Abstraction Layer Model with Chomsky’s Government and Binding Theory. 

Noam Chomsky’s GB theory of government and binding [Cho82] is a linguistic theory of syntax that continues on 

from his earlier transformational grammar. GB tries to explain a universal grammar theory (UG), which describes all 

languages through principles and parameters. Chomsky proposes and evaluates various general principles that limit 

and constrain the types of rules that are possible, and the ways they interact and function. In particular, he proposes 

that rule systems are in fact highly restricted in variety: only a finite number of grammars are attainable in principle, 

and these fall into a limited set of types. 

Another consequence of this shift in focus is the change of emphasis from derivations to representations. The 

major topic in the study of syntactic representations is the analysis of empty categories. General properties of 

empty categories, the functional determination of empty categories, parasitic gaps, and binding theory and the typology 

of empty categories are substantial part of this theory. The major frame of the GB theory is the triple 

that expresses the structural relation between a “governor” (a head or maximal projection) 

and a governee. 

The GB theory has later been extended to a theory of thematic roles, aspect and themes, aspectual event classes, 

and the actor/undergoer division. We observe that this theory may be considered as a three-level specification: 

Principles are meta-specifications that support the description of intentions and goals of websites. 

Parameters support adaptation of website specification to the specific context parameters similarly to the context 

treatment in [Kas03]. 

The layout and the playout of web pages depending on the current implementation, utilization, users and context. 

We may use the GB theory for the development of a generic workflow theory. The main construct of GBfunctionality 

specification is the generic function 

As mentioned above we distinguish three main constituents of a transformation: 

Enabler of a transformation: Agent of the transformation and instrument of a transformation. 

Transformee of a transformation: Affectee of a transformation, consumee of a transformation, and resultee of a 

transformation. 

Invocation of a transformation 

Object suites involved can be separated into: 

Involved object suite which is specialized to the pre-transformation object suite and the context object suite. 

Post-transformation object suite 

So, the generic function is given by 

f generic : P(Pre) × P(Context) → P(Post) 

Generic functions may be specialized. For instance, the function approve 4 specializes the function accept 5 

Other examples 

4 “Approve” means here either to have or express a favorable opinion of (couldn’t approve such conduct) or to accept as satisfactory or to 

give formal or official sanction to ratify a proposal. 

5 “Accept” means either to receive willingly (to be able or designed to take or hold (something applied or added) ) or to give admittance 

or approval to, or to endure without protest or reaction (to regard as proper, normal, or inevitable; to recognize as true believe) or to make a 

favorable response to (to agree to undertake (a responsibility)) or to assume an obligation to pay (also: to take in payment), or to receive (a 

data suite) officially.


Search: (kind, media type suite, answer concept) 

to look into or over carefully or thoroughly in an effort to find or discover something 

to examine in seeking something 

to look through or explore by inspecting possible places of concealment or investigating suspicious circumstances 

to read thoroughly ; check; especially : to examine a public record or register for information about 

to examine for articles concealed on the person 

to look at as if to discover or penetrate intention or nature 

to uncover, find, or come to know by inquiry or scrutiny- usually used with out intransitive senses 

to look or inquire carefully 

to make painstaking investigation or examination 

also seek as to make a search or inquiry or to be sought while lacking 

to resort to : go to 

to go in search of : look forb : to try to discover 

to ask for (as a request) 

to try to acquire or gain (aiming at) 

to make an attempt (as trial used with to and an infinitive 

Get concept: focused retrieval, one-view-selection, sub-view for display 

Is associated with: focused, one-view for selection, associated view for display, depending on cooperation 

Is aggregated of: focused, one view, aggregation view for display 

Is composed of: focused, two views, intermediate view between two boundary queries and a schema between 

them as the connecting view (Randwertaufgabe) 

Is specialization of: 

Is generalization of: extend to more general view 

Unfold: return all depending on browsing function, star view on view 

Unfocused but identifiable: browsing based on the identifier 

Unfocused and not identifiable: list or multilist of results 

Further reading: WI’05, 1630 

Browse: as a special consumption function 

to consume as browse (graze) 

to look over casually (skim) intransitive senses 

to feed on or as if on browse (graze) 

to skim through a book reading passages that catch the eye (to look over or through an aggregate of things 

casually especially in search of something of interest) 

Generische Workflows und entfaltbare Workflows. 

Workflow-Felder erlauben oft eine einfache Darstellung durch entsprechende Ausdrücke. Können Workflow- 

Felder durch eine Stammform spezifiziert werden, dann nennen wir diese Stammform generischer Workflow. Generische 

Workflows stellen ein Analogon zu generischen Operationen wie insert, delete und update dar, bei denen 

eine Instantiierung durch Angabe der Strukturen der Typen erfolgt, für deren Klassen sie angewandt werden. Ebenso 

wie generische Operationen können generische Workflows durch Instantiierung in konkrete Workflows überführt 

werden. Die Parameter können auch abhängig voneinander sein. Wir unterscheiden hierbei die folgenden speziellen 

Typen:


Entfaltbare Workflows sind generische Workflows mit einem generischem Laufzeit-Workflow, bei denen die instantiierbaren 

Parameter keine Nebenbedingungen auf andere Parameter besitzen. Sie können zur Laufzeit voll 

entfaltet werden. Typische entfaltbare Workflows sind Workflows für Gruppenarbeitsplätze, die jedem Mitglied 

die gleiche Arbeitsplattform bieten. 

Parallelisierte Workflows sind generische Workflows, bei denen ein Zwischenstand und To-Do-Listen mitgeführt 

werden und zur Laufzeit mit entsprechenden Werten belegt werden können, die zu anderen Workflows Beziehungen 

besitzen z.B. durch Ressourcen-Sharing und gemeinsam mit diesen ausgeführt werden können. 

Multiple-choice Workflows sind generische Workflows, die Varianten für Rollen, für die freie Auswahl von Daten 

und die Bündelung mit anderen Workflows bereitstellen. 

Transaktions-basierte Meta-Workflows sind generische Workflows, deren Ausführungsmodell eine Ressourcenund 

Rollenverwaltung einschließt, die auch über Rücknahme- oder Kompensationsteilfelder verfügen und deshalb 

einer Transaktionssemantik unterliegen. 

Ein entfalteter Workflow ist ein vollständig instantiierter Workflow. Alle Parameter eines entfaltbaren Workflow 

sind mit entsprechenden Werten belegt. In Bild 16 wird die Beziehung zwischen einem generischen Workflow und 

einem entfalteten Workflow dargestellt. Ein entfalteter Workflow ist demzufolge ein Durchlauf oder eine spezielle 

Instanz eines generischen Workflows. 

✲ 

✯ 

✿ 

3 

❥ 

✲ 

✿ 

Abbildung 16: Generische und entfaltete Workflows 

3.7.3 Komposition von Workflow-Feldern zu Programmen 

Auf Seite ?? wurde bereits die Workflow-Maschine eingeführt. Oft erscheint es einfacher, eine algebraische Notation 

mit abgeleiteten Operationen zu verwenden. Obwohl die Workflow-Maschine zur Komposition der Workflow-Felder 

ausreicht, wollen wir im Abschluß noch eine algebraische Sprache anführen. Diese Sprache harmonisiert mit der 

Algebra, die wir SiteLang verwenden: 

Ein atomares Workflow-Programm ist ein Workflow-Feld. 

Einfache Steueranweisungen sind 

die sequentielle Ausführung ; , bei der Workflow-Programme sequentiell nacheinander ausgeführt werden, 

wobei die Semantik des ersten Programmes die Semantik des zweiten Programmes ergänzt und das leere 

Programm entsteht, wenn die Vereinigung der Semantik zum Widerspruch führt, 

parallele Verzweigung | ∧ | , bei der Programme parallel ausgeführt werden können und das terminiert, wenn 

beide Programme terminieren, 

exklusive Auswahl | ∨ | , bei der genau ein Programm zur Ausführung nichtdetermistisch ausgewählt werden 

kann, 

Synchronisation | sync | , die eine parallele Ausführung mit einer Synchronisationsbedingung zuläßt, und 

einfaches Mischen + , bei dem zwei alternative Programme verbunden werden können. 

Erweiterte Verzweigungs- und Synchronisationsanweisungen sind


mehrfache Auswahl , bei der verschiedene Ausführungspfade gewählt werden können, 

mehrfaches Mischen , bei dem verschiedene Ausführungspfade gemischt werden können, 

Diskriminator, bei dem verschiedene Ausführungspfade ohne Synchronisation gemischt werden können, wobei 

Teilprogramme nur einmal ausgeführt werden, 

n-out-of-m.Verbund , bei dem verschiedene Ausführungspfade mit partieller Synchronisation gemischt werden 

können, wobei Teilprogramme nur einmal ausgeführt werden, und 

synchronisierter Verbund, bei dem verschiedene Ausführungspfade mit vollständiger Synchronisation gemischt 

werden können, wobei Teilprogramme nur einmal ausgeführt werden. 

Strukturelle Steueranweisungen sind 

Wiederholung ∗ , bei der Programme beliebig oft ausgeführt werden können und 

implizite Termination↓ , die eine Beendigung des Programmes hervorruft. 

Datenabhängige Steueranweisungen sind 

statische Steueranweisungen , deren Steuerung mit Bedingungen erfolgt, die bereits zur Compilezeit geprüft 

werden können, 

statische Steueranweisungen, deren Steuerung mit Bedingungen erfolgt, die erst zur Laufzeit geprüft werden 

können, 

Steueranweisungen mit A-priori-Laufzeitannahmen erlauben eine Voreinstellung durch Erzeugung von 

einer beschränkten Menge von Wiederholungen und 

Steueranweisungen mit Synchronisationsbedingen, bei denen beliebig viele Alternativen parallel ausgeführt 

werden können und eine Synchronisation bei Abschluß erfolgt. 

Zustandsbasierte Steueranweisungen sind 

die verzögerte Auswahl, bei der alle Alternativen ausgeführt werden und eine Auswahl der Alternative erst 

nach Ausführung erfolgt, 

die verbundene parallele Ausführung, bei der die Alternativen in zufälliger Reihenfolge sequentiell ausgeführt 

werden, und 

die meilenstein-basierte Steuerung, bei der eine Aktivität ausgeführt wird, bis ein Meilenstein erreicht ist. 

Abbruchanweisungen sind 

Abbruchaktion , bei der eine Aktion abgebrochen wird, und 

Fallabbruch , bei der ein Fall abgebrochen wird. 

Diese Algebra kann durch die Algebra der Workflow-Maschine ausgedrückt werden. Wir verstehen sie deshalb eher 

als “syntaktischen Zucker”, der die Spezifikation von Workflow-Programmen vereinfacht. 

Mit dieser Algebra führen wir eine rigide Klammerung ein. Damit sind nicht mehr alle Ausdrücke darstellbar 

die in der Workflow-Literatur breit diskutiert werden. Typischer Unsinn dieser Literatur ist die Auseinandersetzung 

mit kondensierten und überlagerten Programmen wie in Bild 17 dargestellt. Da die Programmierung von einer klaren 

Semantik profitiert, erlauben wir diese Art von Konfusion nicht bei der Spezifikation. 

Dieses Programm vermischt Ausführung, Sequentialität und Nebenbedingungen zur Entscheidung. Die Alternativen 

sind vereinfachbar, wenn sicher ist, daß z.B. WF 2 vor WF 1 terminiert und mit den Resultaten von WF 1 

übereinstimmt, dann kann WF 5 ohne Berücksichtigung von WF 2 nur auf WF 1 aufbauen. 

Das Programm in Bild 17 besitzt gleichzeitig auch die klassische AND-OR-Falle. Analog kann auch die OR- 

AND-Falle spezifiziert werden. Beide “Fallen” sind in Bild 18 illustriert.


❄ 

WF 1 

❄ 

WF 2 

❄ 

WF 3 

❄ 

WF 4 

❘ 

❄ 

WF 5 

∨ 

❄ 

✠ 

❄ ∧ 

❄☛ 

❯ 

∧ 

☛ 

❄ ∧ 

❄ ✙ 

❘ 

∨ 

✌ 

❄ 

❄ 

Abbildung 17: Ein überlagertes und verwirrendes Workflow-Programm 

WF 1 

✯ 

WF 3 

WF 3 

✯ 

∨ ∧ WF 4 WF 1 ∧ 

❥ 

❥ WF 2 

✯ 

❥ WF 2 

❥ 

∨ 

✯ 

WF 4 

Abbildung 18: Ein OR-AND- und ein AND-OR-Workflow-Programm 

Diese Fallen sind relativ leicht aufzulösen, wenn man die Resultatssemantik betrachtet. In diesem Falle sind beide 

Programme durch AND-AND-Programme repräsentiert. Betrachtet man dagegen die Ausführungssemantik, dann 

klaffen die beiden Programme auseinander. 

Noch schwieriger sind Workflow-Semantiken, bei denen eine Synchronisation sowohl am Ende als auch zu Beginn 

einer Verzweigung erfolgen kann. In diesem Fall erhält auch die Verzweigung eine andere Semantik. 

Aus diesen Gründen bevorzugen wir die etwas rigidere Semantik der Workflow-Maschine mit der Semantik 

der abstract state machine. Sie hat zugleich auch den Vorteil, eine Verfeinerung zuzulassen und auch Konflikte auf 

Datenebene durch Zurücknahme auflösen zu können. 

3.7.4 Unterstützung von Werteerfassung, - speicherung, -modifikation: Beispiel Beobachtungen 

Observations are typically also made in a process. They cause additional observations. So, the observation process is 

typically a complex process that can be triggered by the concepts at the knowledge level. We also use therefore the 

knowledge level for the creation of control. Figure 19 visualises a simple generated business process for observations. 

This results in the classical observation cycle displayed in Figure 21. 

If we use associated functions then the picture becomes more complex. Then the recursion is controlled by 

the associated concepts for observations. If we distinguish between projection, hypotheses and active observations 

then the process become split into the general observation cycle displayed in Figure 21 and into additional parallel 

processes: 

a process that generates the proposed interventions and enforces tracking for those interventions (projection) 

a process that tries to find the contradicting observations and that rejects those observations that are not true 

(thus generating a resulting observation) (for active observations) 

and a skip process (for the case of hypotheses)


❄ 

observe 

analyse 

✲related concepts of 

observation 

✲ 

propose next 

observation 

✻ 

observation 

control 

KB 

❘ 

Abbildung 19: Unfolding business processes conducted from the knowledge level 

✻ 

✲ 

Business 


✛ 

✲ 

Data 


Knowledge 

discovery 

evolution 

cycle 

✻ 

Evaluation 

Deployment 

✯ 

✛ 

❄ 

Data 

preparation 

✻ 

❄ 

Modeling 

✛ 

Abbildung 20: The observation knowledge discovery cycle 

❄


We notice that measurements are typically not one-dimensional but many-dimensional depending on the properties 

of things under observation. Therefore, we must support the many-dimensionality by Tilak 6 or Kiviat diagrams. 

✻ 

Supplier 

■ 

Price 

Product 

✠ 

Focus 

event 

✒ 

Customer 

Region 

❘ 

Abbildung 21: Tilak diagrams and Kiviat graphs 

Depending on the schema layering we may directly extract those business processes that nicely support the schema 

without requiring additional integrity constraint maintenance. 

✲ 

find 

arguments 

✲ 

evaluate 

by formula 

✲ instantiate 

new 

measurement 

✲ 

Abbildung 22: Measurement process 

Each of the activities uses specific data. For instance, the find arguments activity is based on the detection of the 

type of the phenomenon, the type of the state, the objects under consideration. The final event results in an integration 

of the measurement into the database, i.e. integration of the list of measurements, protocols etc. Measurements may be 

done in parallel. So we enhance the measurement activity either by parallel sub-processes (Figure 23) or by multiple 

instance activities. 

❃ 

✲ ∧ 

7 

find 

arguments 

find 

arguments 

✲ 

✲ 

evaluate 

by formula 

evaluate 

by formula 


new 

measurement 


new 

measurement 

7 

compare 

∧ 

❃ 

✲ 

Abbildung 23: Measurement process 

The schema in Figure ?? can be shuffled with a schema that represents the different facets of dimensions: 

6 Tilak diagrams are useful if the number of dimensions is not higher than 6.


combinations of dimensions are typically complex data types; 

causal dimensions represent causal relationships; 

comparison dimensions are used for comparing dimensional results with others. 

In this case we use the model-view-control pattern for extraction of the applicable kind of dimension. 

The same separation of concern might also be applied to methods of measurement: 

evaluated measurement protocol are based on the evaluation through formulas; 

source measurement protocol directly result in quantities or qualities.


3.8 Schrittweise Modellierung der Funktionalität 

siehe DBSII.4


3.9 Theoretische Grundlagen 

3.9.1 Semantik von Transaktionen 

siehe Prinz/Thalheim 

Transactions are one of the fundamental frameworks in the information systems area. It is necessary to define the 

notion of “transaction” that is robust according to the following requirements: 

Logical semantics must coincide with operational semantics for transactions. 

Parallel execution of transactions must be definable inside the operational semantics used for transactions. 

One refinement of the transaction model is the implementation of transaction execution by a DBMS. 

Arbitrary order of execution: Transactions can be executed in any order as long as they are not competing for 

resources. 

Rigid punch: Transaction execution leaves traces in the database whenever the effect of the transaction does 

not contradict the database. 

3.9.2 Variety of Definitions 

“Definitions are a matter of luck” is a humorous statement often made by A.N. Kolmogoroff and H. Thiele. The 

transaction definition made in a variety of books and papers seems to be a good example of this claim: 

TA as obligation [Emb98]: “A transaction is a program unit that accesses the database; it retrieves and may update 

data. A database system has the responsibility of executing a transaction so that it is both atomic and correct. 

... A transaction is a program unit that preserves correctness and atomicity.” 

TA as an agent [GMUW00]: “A transaction, like any program, executes a number of steps in sequence; often several 

of these steps will modify the database. Each transaction has a state, which represents what has happened 

so far in the transaction. The state includes the current place in the transaction’s code being executed and the 

values of any local variables of the transaction that will be needed later on.” 

TA as special program [Cod91]: “A transaction is a collection of activities involving changes to the database, all 

of which must be executed successfully if the changes are to be committed to the database, and none of which 

may be committed if any one or more of the activities fail. Normally, such a collection of activities is represented 

by a sequence of relational commands. The beginning of the sequence is signaled by a command such as BEGIN 

or BEGIN TRANSACTION. Its termination is signaled by a command such as END or COMMIT - or, if it is 

necessary to abort the transaction, ABORT.” 

Two views on TA’s [HK97]: “An end user communicates with a database through a mechanism called a transaction. 

A transaction can be defined from the user viewpoint and from the system viewpoint. The end user (the 

operator, the system administrator, etc.) sees a transaction as a request/reply unit expressed in the form of a 

source program. The system sees a transaction as a sequence of operations (reads, writes, etc.) on the data 

elements. The user conveys a change to the DBMS via a transaction and awaits a reply from the system. The 

DBMS then implements the set of operations (defined in the transaction) on a subset of data elements by executing 

the transaction under a set of the changes through a “successful” execution of the transaction. The DBMS 

guarantees the incorporation of the changes through a “successful” execution of the transaction. We will refer 

to such execution of a transaction as “commit”. 

A transaction T must possess a set of well-defined properties to be able to correctly reflect in the database the 

changes to the part of the real world. In executing a transaction, the system guarantees that all the changes 

proposed in the transaction, not only a part of them, are incorporated correctly in the database. ” 

TA as concurrent operation [?]: “The execution of a program that accesses or changes the contents of the database 

is called a transaction. The transaction submitted by various users may execute concurrently and may access


and update the same database records. If this concurrency is uncontrolled, it may lead to problems such as an 

inconsistent database.” 

TA as specific application programs [aBK02]: “ A transaction is a program that can perform the following functions: 

1. It can update a database to reflect the occurrence of a real-world event that effects the state of the enterprise 

the database is modeling. An example ... 

2. It can ensure that one or more real-world events occur. ... 

3. It can return information derived from the database. ” 

The situations of the variety becomes worse if in the same source a variety of definitions is used. Beside the definition 

of [HK97] in [KH97] another definition [HR97] is used which is repeated by most of the books in the database 

area [Vos91]: 

The concept of a transaction, which includes all database interactions between BeginOfTransaction and EndOfTransaction 

in the preceding example, requires that all of its actions be executed indivisibility: Either all actions are 

properly reflected in the database or nothing has happened. No changes are reflected in the database if at any point 

in time before reaching the CT, the user enters the ERROR clause containing the RestoreTransaction. To achieve this 

kind of indivisibility, a transaction must have four properties: 

Atomicity. It must be of all-or-nothing type described before, and the user must, whatever happens, know which state 

he or she is in. 

Consistency. A transaction reaching its normal end (EOT, end of transaction), thereby committing its results, preserves 

the consistency of the database. In other words, each successful transaction by definition commits only 

legal results. This condition is necessary for the fourth property, durability. 

Isolation. Events within a transaction must be hidden from other transactions running concurrently. If this were not 

the case, a transaction could not be reset to its beginning for the reasons sketched earlier. The techniques that 

achieve isolation are known as synchronization, and since Gray et al. .. there have been numerous contributions 

to this topic of database research .. 

Durability. Once a transaction has been completed and has committed its results to the database, the system must 

guarantee that these results survive any subsequent malfunctions. Since there is no sphere of control constituting 

a set of transactions, the database management system (DBMS) has no control beyond transaction 

boundaries. Therefore, the user must guarantee that things the system says have happened have actually happened. 

Since, by definition, each transaction is correct, the effects of an inevitable incorrect transaction (i.e., 

the transaction containing faulty data) can only be removed using countertransactions. 

Another requirement used is the serializability requirement: 

Running two transactions in parallel should have the same effect as running them one after the other. 

Transaction order is important for the effect. Consider one transaction changing the value for x to 2x and another 

transaction changing x to x − 2. Therefore, order of execution matters. Execution of the second after the first gives 

2x − 2. Execution of the first after the second gives 2x − 4. Therefore, serializability means that running a number of 

transactions in parallel should have the same effect as running them sequentially in a certain order. 

These definitions are taught in database courses. Therefore, the database community defined in brief that a transaction 

is nothing else as a sequence of database operations that preserve the ACID properties. 

3.9.3 State Models Used in Transaction Definitions 

There are very few papers and books proposing a state model of transaction execution. Let us summarize and extend 

the models proposed so far. We notice that the description below is not explicitly proposed in the literature but can be 

extracted on the basis of the intentional, narrative descriptions.


State model: The transaction engine has five states [GR94]: 

BeginOfTransaction (BOT): The transactions marked by ‘not finalized’ are in the BOT state and wait for execution. 

Run: The transaction engine runs the transaction and executes read, write and compute statements. 

Abort: The transaction is in an abort state. The resources occupied are freed. After completion the transaction 

returns to the BOT state. 

Commit: The transaction engine has completed the statements of the transaction and checks now the correctness 

of the integrity constraints. If the constraints are valid the next state is the EOT state. Otherwise, the 

engine directs the transaction to the abort state. 

EndOfTransaction (EOT): The transaction engine completes the execution of the transaction and marks the 

transaction by ‘finalized’. 

This state model is displayed in Figure 24. 

BOT ✛ 

❥ Run 

✯ 

Abort 

✻ 

❥ 

Commit 

✲ 

EOT 

Abbildung 24: The States of a Transaction in the State Chart Approach 

The model is often used in the literature in the form displayed in Figure 25. However, transactions are rerun if 

they fail or abort. 

BOT 

❥ 

Run 

✯ 

Abort 

✻ 

❥ 

Commit 

✲ 

EOT 

Abbildung 25: The States of a Transaction in the State Chart Approach Without Return to BOT 

Event model: The event model [?] is based on the events the recovery manager may use. 

BeginOfTransaction: The label BOT marks the beginning of a transaction. 

Read or Write: The transaction engine executes elementary operations for the given transaction. 

EndOfTransaction: The read/write sequence has ended. Now integrity is to be checked. 

CommitTransaction: The CommitTransaction event signals the successful completion of the transaction. 

Additionally, the recovery manager uses events: 

Rollback: The transaction has not been successful. Effects to the database must be undone. 

Redo: The redo event causes the manager to repeat the operation. 

Undo: The undo event forces the manager to repair the effects of applying a singleton operation to the database. 

The ovals used in Figure 26 show system activities, i.e., state transitions: 

Active: The transaction sequence is currently executed.


Partially committed: The sequence has been executed and the concurrency controller checks whether there is 

an interference with other transactions. Furthermore, integrity constraints are checked by the transaction 

engine. 

Committed: The transaction has been successfully completed. The auxiliary logs are removed. 

Failed: The effects of the transaction on the database are compensated. 

Terminated: The transaction has been successfully completed or has failed. In the case that the transaction 

failed no effect on the database can be observed. 

The event model state transition diagram is pictured in Figure 26. 

Read 

Write 

BeginOf 

EndOf 

Transaction 

Transaction 

✲❄ 

Active 

✲ Partially 

Committed 

Commit 

✲ 

Committed 

❥ 

❄ 

❄ 

Failed ✲ Terminated 

Abbildung 26: The Event Model of Transactions 

Statechart model: The transaction engine starts [WV02] at the Begin state. After calling the transaction the transaction 

state is changed to Active. The transaction is either running or blocked by the engine due to the database 

state or the state of other transactions. An active transaction is either committed or aborted. 

The statechart of transactions is displayed in Figure 27. 

Begin 

✲ 

✍ 

✻ 

Restart 

Aborted ✛ 

Reject 

❄ 

Running 

✗ 

Active 

Resume 

Block 

Blocked 

✻ 

✲ 

Commit 

Committed 

Abbildung 27: The Statechart Model of Transactions 

The three models use a transaction engine (or scheduler or recovery engine) for the explanation what is considered 

to be a transaction. It seems, however, that transactions should be defined without referring to an engine or an 

implementation. 

3.9.4 General Definition of Transactions 

Basic Definitions. 

Transactions are defined over databases schemata. Let (S, Σ) be a database schema and O BS the set of basic modification 

and retrieval operations defined on S. 

Typically, the elementary modification operation is the write operation defined on locations loc = (R, o) of 

an object o in a class R C defined on R. The elementary retrieval operation is the read operation defined on locations 

(R, o) of an object o in a class R C defined on R.


Basic modification operations are the insertion, deletion and the updating operations defined for an object o in 

a class R C defined on R or a group of objects. These operations are typically bound by an identification predicate 

for the object or the group of objects. In object-relational databases we assume that the identification predicate is 

value-based. 

Basic retrieval operations are the select expressions defined by structural recursion on the structuring S. Classical 

SQL expressions are expressions of the form 

map(filter(join(...), ψ), S) 

where the filter predicate is again an expression, the target structure for the mapping (or construction) is S. 

The static constraints in the schema (S, Σ) can be transformed to transition constraints [Tha00]. A transition 

constraint (Ψ pre , Ψ post ) defines the preconditions and postconditions for state transitions of databases defined over S. 

Given a transition τ converting the database S C 1 

to the database S C 2 

= τ(S C 1 

). The transition constraint (Ψ pre , Ψ post ) 

is valid for the transition (S C 1 

, τ(S C 1 

)) if S C 1 

|= Ψ pre entails S C 2 

|= Ψ post . 

Static constraints Σ are therefore converted to a transition constraint (Σ, Σ). 

We follow the approach of [HK97] and distinguish between: 

Syntax of Transactions. 

Transactions are defined on the basis of elementary operations. Following [LL99], we define a transaction T over 

(S, Σ) as a finite sequence o 1 ; o 2 ; o 3 ; ...; o m of basic modification and retrieval operations over (S, Σ). 

Transactions may be applied to the database state S C sequentially and form a transition 

T(S C ) = o m (...(o 2 (o 1 (S C )))). 

Functional semantics of transactions. 

Logical semantics is based on the validity of transition constraints. The transaction is considered to be a singleton 

transition. Given a transaction T over (S, Σ) and a database S C . 

The result of applying the transaction T to S C is the database T(S C ). 

The effect of application of T to S C is defined as a transition constraint preserving transformation 

T(S C ) = 

{ T(S C ) if T(S C ) |= Σ 

S C if T(S C ) ̸|= Σ 

The transaction can be thus understood as an invariant state transition. 

Transactions T 1 and T 2 are competing if read(T 1 ) ∩ write(T 2 ) ≠ ∅ or read(T 2 ) ∩ write(T 1 ) ≠ ∅ or 

write(T 2 ) ∩ write(T 1 ) ≠ ∅ . The sets read(T i ) and write(T i ) consists of the locations of objects which are read or 

written by the transaction T i . 

Parallel execution of transactions T 1 ‖ T 2 is correct if either the transactions are not competing or the effect 

of T 1 ‖T 2 (S C ) is equivalent to T 1 (T 2 (S C )) or to T 2 (T 1 (S C )) for any database S C . If parallel execution is correct 

transaction execution can be scheduled in parallel. 

Logical semantics of transactions is defined by 

consistency (each transaction preserves transition constraints) and 

parallelization (transaction can be executed in parallel). 

We observe that atomicity is not considered. Atomicity is declared by granularity of transitions. Furthermore, we are 

not concerned with durability. Durability is not a logical property but rather a property of storage. 

Operational semantics of transactions. 

Instead of using an abstract interpretation and a set of models, an abstract Moore-automaton M = (Z, f , I, Z final ) 

is used with the set Z of states, its subset Z final of final states, the state transition function f , and the initialization 

function I which assigns a starting state I(p, d) = z p,d ∈ Z to each program p and each input d. The interpretation 

of the program p and the input d is the sequence of states z p,d = z 0 , z 1 , ..., z i , ... with z i = f (z i−1 ) for i ≥ 1. If the 

sequence is finite for n p,d and z np,d ∈ Z final then the program p is correct for d. If f (z i ) is undefined for some i and


z i ∉ Z final then the program does not have a meaning for d. If the sequence is infinite with z i ∉ Z final for all i ∈ N 

then the program is not terminating for d. 

A variety of approaches has been developed for definition of operational semantics: 

Scheduling, access and recovery models: Transactions are executed in parallel and independent from each other. 

In order to support this requirement, access, scheduling and recovery models are developed [Bis95]. 

Given a set of transactions T 1 , ..., T n . A schedule S(T 1 , ..., T n ) of T i = o i,1 , ..., o i,ni , 1 ≤ i ≤ n is assignment 

of moments S(o i,j ) of time to the operations of the transactions which preserves the order of operations within 

each transaction. Now an access plan can be specified for the objects to be used in transactions. An access plan 

is roughly called conflict-free if no transaction reads a value which is under change by another transaction. 

This approach has the advantage that the transaction machine is constructed. The disadvantage is the complexity 

of the constructive approach. Any change in transaction policy or constraint enforcement policy imposes a 

severe number of changes in the definitions. 

Abstract automata models are widely used for programming languages. Such abstract models have the advantage 

that refinement of requirements is reflected by refinement of abstract automata. For this reason, this approach 

is preferable if we are able to to define such abstract automata. 

Operational semantics for transactions must be based on parallel execution of processes. Therefore, we need a 

machine that allows to model parallel execution. 

3.9.5 Defining Operational Semantics Through Abstract State Machines (ASM)


3.10 Eine BPMN-Studie 

Nach [KST09]. 

Conference organisation is a typical example of processes which are highly distributed, involve a number of users 

with different roles, and are collaborating. These processes are either session-based or are relatively short-term processes. 

Collaboration is based on messages among the processes. Processes can be separated into independent ones. 

Therefore, conference paper submission and review systems are an ideal application for demonstration of workflow 

specification languages. 

Conference organisation also includes organisation of paper submission, of paper review, and conference assembly 

of proceedings. These tasks are typically supported by paper submission and review systems. WE may find several 

dozen of suvh systems. We base our case study on the knowledge about the systens BYU, EasyChair, OpenConf, 

MyReview and MuCoMS and mainly on the first one and the last one[Kir08]. The first system as been developed at 

Brighton Young University and has been extended in an international collaborations where the Cottbus team of the 

second author has been participating and was responsible for a part of the documentation including storyboarding. 

The system has been extensively used for more than three dozen conference series including ASM, ER, and FoIKS. 

Figure 28 provides a screenshot of this system. 

Abbildung 28: The entry page of the BYU paper submission and review system for PC members


Requirements Survey 

Conference Paper Submission and Review Systems (PSR) are typically web-based content management systems that 

handle complex workflows of academic conferences. PSR systems aim to minimise the workload of the Conference 

Committee, provide intelligent services to program committee members for their reviewing and other activities, and 

provide basic services to authors of papers. Features like automatic paper assignment, event driven notification, multitrack 

management, user editable templates and mass emailing are provided to reduce the workload of managing the 

conference to the minimal amount. Members of the program committee act as reviewers, as observer of the work, as 

discusser of review results, and as resolver of conflicts among reviews. Authors are supported by features like initial 

paper or abstract submission, updating of information they provided, and observing the outcome of reviewing of their 

papers. 

Users of the PSR system act in different roles. Typical user roles are administrator of the system, program committee 

officers such as (co-)chairs or track chairs, authors of papers, program committee (PC) members and additional 

external reviewers. The separation of roles of users is based on the orthogonality of activities of different users of the 

system and the concurrent execution of tasks by users. The orthogonality is restricted by a number of exclusion rules, 

e.g. the program committee members cannot participate in the review of their own paper. 

The user in the general role of an unregistered user may obtain various public information at the conference 

website. This includes due dates, conference theme, tracks, topics, and accepted papers, etc. An unregistered user can 

follow the call for papers link from the conference website to access the PSR system, to register, and to become an 

author. 

These roles can either be integrated for a certain user or can be separated. We choose for the case study separation 

of roles of users. 

The PSR system is typically supporting a number of conferences at the same time. The installation of the system 

may either be a stand-alone that is used to support a singleton conferences or a conference application provider 

installation that supports a number of conferences at the same time. The conference management can be based on a 

number of phases. 

Phase 0 is used for the preparation of the infrastructure. The PSR system is installed and initialised. A number 

of data are gathered, e.g. program committee names and e-mail addresses, topics of interest, profile and portfolio of 

the conference, deadlines such as due-date of abstracts and initial and final paper, PC meeting, notification data. The 

system installation results in generation of accounts and passwords and the notification of all involved people about 

their rights and obligations. Phase I involves PC members after notification of their user names and passwords. PC 

members log on and edit their profile, and choose their own password. Phase II is devoted to paper submission and 

reviewing. Phase III is typically handling the post-PC organization. Sub-phases may partially run in parallel. Some 

sub-phases require however the completion of others. For instance, reviewing is based on assignment. Assignment is 

typically based on completion of the bidding phase and does not require that all PC members have made their bids. 

We shall concentrate for this case study on phase II. The phase of paper submission and reviewing uses a number 

of sub-phases that can be modelled by separate BPMN diagrams. Typical BPMN processes at this phase are the 

following ones: 

1. Open system for abstract and paper submission; 

2. Ask PC to indicate their interest levels and conflicts of interest; 

3. Email confirmation notice or reminder to authors of submitted abstracts; 

4. Close paper submissions, remove papers with abstract but no paper body; 

5. Email confirmation to authors; 

6. Double-check conflict-of-interest settings - enter any conflicts you find that aren’t already listed; 

7. Close interest-setting ability; 

8. Assign reviewers to papers; 

9. Email assignment notification to PC members; 

10. Each week, send review status report; 

11. Monitor review status; 

12. Open anonymous review report capability;


13. Close review revision capability and hold the program committee meeting; 

14. Accept papers, notify authors. 

Basic Workflows of Program Committee Members 

PC members are responsible for writing reviews to papers that they are assigned to. Before paper assignment, PC 

Members can to go through a bidding process where they specify expertise in topics and interest in papers. After 

review submission, PC members may participate in group and global discussions where reviews from different 

members do not agree. Conflicts among reviews can be resolved by a PC members who acts as an arbiter. 

PC members can invite external reviewers and delegate papers to them. The delegation process may result in 

new responsibilities and rights for other users. Typically the external referee act on their inviters’ behalf in the paper 

review process. External reviewers can participate in group discussions. This diagram represents the workflows that 

are used within the BYU and the OpenConf PSR systems. 

The diagram in Figure 30 displays more details for the reviewing activity. The reviewer must provide a rating and 

his/her level of expertise for each paper. The review should contain a detailed opinion about the paper. Reviewers 

typically decide whether all or some sections of the review template are going to be filled. These sections can also be 

selected more than once. Finally the reviewer may decide whether the review contains also information not shown to 

the authors. After completion of the review the PC member may decide whether or not an email copy is wanted and 

whether or not the review is completed and thus deleted from the tasks agenda of the reviewer. Finally the review is 

completed. 

PC members are typically also supported by context-sensitive help features. The reviewer may obtain general 

conference information, may survey the assignments made to him, and may get help during the review process, e.g. 

for downloading papers and abstracts, updating and surveying own reviews, and for printing the work done so far. 

This help feature is often implemented as a sub-process that is enabled after the reviewer has logged into the system 

and closed after the reviewer has been logged out. The BYU PSR system uses for closing the process a message send 

from the main process to the help process. The OpenConf and the MuCoMS PSR systems use a separate help facility 

similar to the help feature for authors displayed in Figure 33. 

Basic Workflows of Authors 

An user becomes an author after being registered as an author. The registration includes an agreement on the rules 

for submission of papers, e.g. originality. After successful registration the author receives a message with the 

identification details. 

We may distinguish a number of phases for authors. Authors are considered as perspective authors, authors with 

submission, authors with reviews for their papers, and authors of accepted papers. Any user and therefore also authors 

become a potential attendee of the conference. The diagram in Figure 31 displays the general process for the authors. 

The PSR system is collaborating with the conference management system. An author can view all the papers of which 

he/she is a co-author. He/she can submit multiple papers and once after the submission, the author typically becomes 

the contact author of the paper. The update feature for submissions and receival of notifications is restricted to contact 

authors. The author may also extend the right for submission or notifications to the corresponding co-authors. Authors 

may also specify conflicts before paper assignment. Authors need to register with the system before they can make 

any submissions. The registration may be conference-specific or may be general. If they have already been registered 

in the MuCoMS or the EasyChair system for another conference then the account creation is skipped. 

The complex activity of initial submission of a paper is displayed in Figure 32. After opening the PSR system 

the author is requested to provide basic data and to agree with the compliance of the conference. The PSR system 

will generate a new paper id and provide login information to the author. The author can now open the submission 

page and submit paper data. The author may either provide data for the abstract or submit the paper or do both. If the 

paper has an incorrect format an exception is raised. This exception allows the author to resubmit the paper. Finally 

the author should provide some additional data on the paper and can view the current result. If the current result is 

not ok then the author may iterate with paper and abstract submission.


The OpenConf, EasyChair and the MuCoMS PSR systems use the help facility in Figure 33. The general help 

facility allows the author to select which help is wanted at the moment: conference guidelines, submission help or 

account management. The submission help provides guidelines for submission and for the various submission steps. 

The author may initiate another sub-process for account management displayed in Figure 36. 

The sub-process depicted in Figure 34 defines a control flow for the submission of the final version of a paper. 

The author must upload the full version, sign the copyright and register to the conference. 

Processes may also be independent processes. The information and contact process in Figure 35 satisfy the information 

need of authors. Depending on whether the reviews are ready the author may either view the status or view 

reviews or both. The communication process involves a number of users, e.g. the PC (co-)chair or the reviewer. The 

reviewer may choose whether a direct response is used or the response to redirected to the PC co-chairs. 

Crosscutting Workflows 

The users of the PSR system may share common behaviour. A typical example of common processes is displayed in 

Figure 36. This process may be generalised to a general process for account management. The change of the profile 

may include the change of users data such as general person data or contact data. 

Another cross-cutting sub-process is the information provision feature. Any user of the PSR system might be 

interested in the current status of conference work. For instance, authors can view the status by the process in Figure 

35. Other users such as the PC (co-)chairs are supported by processes that provide statistics about submission and 

reviewing, by processes that survey the submission status, and by processes that survey activities of PC members. 

Any user of the PSR system can enhance his/her work space by a watch list for activities the user wants to be aware 

of. The watch list is compiled from the desires and from the rights the user has. 

PC members and the PC co-chairs may found their discussion groups on specific topics of interest. These discussion 

groups are based on processes for collaborative work such as publishing, chairing, organising, responding 

etc. 

The PSR system is typically enhanced by a web information system on the conference, e.g. for general conference 

information, on current calls for papers, on data, on travel, and on registration. 

Supporting Infrastructure 

The PSR system supports all PC processes and must be based on a database. The entity-relationship schema in Figure 

37 displays the structure of the supporting database system. This system provides a number of views for each of the 

phases. For instance, the sub-phases of phase II supporting the PC are: Edit the profile by the PC member, browsing 

abstracts and making a bid for assignment of reviews, reviewing, viewing reviews made by other PC members on 

papers assigned to the PC member or on other papers, and session of the PC. 

The database schema is the basis for the specification of a number of views. Typical PC (co-)chair views are 

lists of all papers, abstracts, activities of authors and PC members. There are special views for paper assignment, 

for de-block of data, and for stages of PC decisions. The PC member can see abstracts of submitted papers before 

assignments, own reviews during the reviewing sub-phase, concurrent reviews and conflicts with concurrent reviews 

or discrepancies before PC session and after completing all reviews assigned to this PC member, and anonymous 

survey reviews during PC session. These views are the basis for tasks the PC member may perform. 

Authors enter the system through the personal author login. They may provide and update their own data. They 

may submit an abstract or the paper before the deadline. They may obtain anonymous reviews and may submit the 

final version after the PC decisions have been made. 

The administrator uses a number of admin tools and has direct direct access to some data or encrypted access to 

other data. Adminstration tools provide a service for maintenance of software code, of the database, and for password 

update.


Examples for the main text 

Example 1 (OR gateways: OR-merge and -decision) The BPMN diagram in Figure 29 allows a reviewer to select 

a number of options for the work. For instance, a PC member may update his profile under recommendation of the 

guidelines and may notify the conference officers about the changes. At the same time he may download a paper 

and survey the abstract. The session is completed after all selections have been completed. The diagram in Figure 30 

allows that reviewers choose whether they want provide additional information to the PC, whether there are proposals 

for assignment of the paper to sessions, and whether additional reviewers have been supporting the review. The PC 

member may also decide that the current review is already in its final stage and whether an email copy of the review is 

requested. The OR gateway in Figure 35 has an enabled gate for viewing reviews only after the review and discussion 

processes have been completed. 

Example 2 (Exclusive gateways: Exclusive decision and merge) The BPMN workflow in Figure 31 also shows a 

case in which an exclusive decision does not have an associated merge gateway. Authors of accepted papers may not 

obtain their funding. Their papers are cancelled in this case. 

Example 3 (Complex gateways: Complex decision and merge) The diagram in Figure 30 uses a complex gateway 

for the selection of a reviewer which tasks are going to be completed for the current review. We may allow that some 

of these tasks are made several times. 

Example 4 (AND gateways: Parallel fork and join) The diagram in Figure 34 shows that for final paper submission 

the copyright agreement, the final version, and the registration must be submitted by one of the authors of an 

accepted paper. 

Example 5 (Start, end, and intermediate events) Start event initiate another process instance. They can be initiated 

by various kinds of events such as arriving messages, links etc. End event are used to complete a process. If the 

process is a sub-process of another process then the control flow is ruled back to the parent process, e.g. by a link 

in the diagram in Figure 33. The diagram in Figure 32 uses an intermediate event for exception control flow. If the 

paper submitted by the author does not have the correct format then an exception is raised. After resubmission of the 

paper the control flow is directed back to the normal submission process. 

Example 6 (Error, cancel, and compensation events) The BPMN diagram in Figure 32 uses an intermediate event 

that may cause specific handling for errors. Error treatment is typically a cross-cutting concern and may be added 

to any task, event or activity. In the diagram we use a well-defined error handling that results in a control flow that 

joins again the original workflow. 

Example 7 (Tasks and activities) Activities may be complex. The diagram in Figure 30 shows details of the complex 

online reviewing activities of PC members. 

Example 8 (Multi-instance loops) The diagram in Figure 30 allows a reviewer to select several reviews for papers 

assigned to the PC member at the same time. These reviews can be independently completed. The logout is only called 

after completing all reviews selected or after closing the review task without completion. The diagram in Figure 32 

uses an explicit loop for iteration if the initial paper submission is not satisfying. 

Example 9 (Sub-processes) The BPMN diagram in Figure 31 transfers control of author handling to the conference 

participants systems after an author of an accepted paper has obtained the funding and submitted the final version. 

These two systems may collaborate. For instance, some conferences require that at least one author per accepted 

paper is registered prior to collection of the proceedings. 

Activities can rather be complex sub-processes. The diagram in Figure 34 displays the activities of 

Example 10 (Loops) Loops may be explicit or element of activities. The diagram in Figure 31 uses an explicit loop 

for the reminder of people who might be interested in a conference. The reviewing activity in Figure 29 is can be split 

into a number of parallel reviewing sub-activities that can be made in parallel.


Example 11 (Messages) The PSR system must support a message exchange among multiple processes. These messages 

may start a new process instance and may support work of the committee, of authors, or of the administration. 

Typical messages are the following: 

Notify program committee of the Web site, their user ID, and their password to log on. 

Notify authors that their paper has been received and is being reviewed. 

Notify program committee of review assignments. 

Notify program committee of discrepancies between their review and those of other referees. 

Remind program committee of reviews that still need to be submitted. 

Thank program committee for their reviews. 

Notify authors of accepted papers, send them their anonymous referee comments. 

Notify authors of rejected papers, send them their anonymous referee comments. 

Remind authors of camera-ready paper due date. 

These messages are typically send tasks in the source process and receive tasks or start or intermediate events in the 

target process. 

The BPMN diagram in Figure 35 explicitly displays some of the messages of authors. These messages trigger 

other processes of other users. 

Example 12 (Pools and message exchange) The diagram in Figure 35 shows how processes may recursively trigger 

other processes. An author may respond to the reviews after those are made available. This response can be directed 

to the reviewer who may ask the PC co-chair to interact. The direct response may also be possible after applying 

anonymisation procedures. 

Example 13 (Swimlanes) The diagram in Figure 31 uses swimlanes for the separation of the different phases of 

processes of authors. 

3.10.1 The MuCoMS Database Structure 

c○Markus Kirchberg. The database structure of the Multiple Conference Management System MuCoMS. Singapore 

2008. [Kir08]


3.10.2 MuCoMS in Service 

c○Markus Kirchberg. The database structure of the Multiple Conference Management System MuCoMS. Singapore 

2008. [Kir08]

CAU zu Kiel, IfI, ISE, β 3. Funktionalität von IS ab SS 2012 419


3.11 Beispiele von Funktionen 



3.12 Übung: 

- EER-Modelle 

- Prozesse 

- Algebra 

- dynam. Integritätsb. 

Further reading: Wieringa: Part II, IV 



Literatur 

[aBK02] 

[Bis95] 

[BST09] 

[BT08a] 

[BT08b] 

[Cho82] 

[Cod91] 

[DT04] 

[Emb98] 

P. M. Lewis andA. Bernstein and M. Kifer. Databases and transaction processing: An applicationoriented 

approach. Addison-Wesley, 2002. 


E. Börger, O. Sörensen, and B. Thalheim. On defining the behavior of or-joins in business process 

models. Journal of Universal Computer Science, 15(1):3–32, 2009. 

E. Börger and B. Thalheim. A method for verifiable and validatable business process modeling. In 

Software Engineering, volume 5316 of Lecture Notes in Computer Science, pages 59 – 115. Springer, 

2008. 

E. Börger and B. Thalheim. Modeling workflows, interaction patterns, web services and business processes: 

The ASM-based approach. In ABZ, volume 5238 of Lecture Notes in Computer Science, pages 

24–38. Springer, 2008. 

Noam Chomsky. Some Concepts and Consequences of the Theory of Government and Binding. Linguistic 

Inquiry Monographs. MIT Press, 1982. 

E. F. Codd. The relational model for database management (version 2). Addison-Wesley, Reading, 

MA, 1991. 

A. Düsterhöft and B. Thalheim. Linguistic based search facilities in snowflake-like database schemes. 

Data & Knowledge Engineering, 48(1):177–198, 2004. 

D. W. Embley. Object database development: Concepts and principles. Addison-Wesley, Reading, 

Mass., 1998. 

[GMUW00] H. Garcia-Molina, J. D. Ullman, and J. Widom. Database systems implementation. Prentice-Hall, 2000. 

[GR94] 

[HK97] 

[HR97] 

[Kas03] 

J. Gray and A. Reuter. Transaction processing: Concepts and techniques. Morgan Kaufmann, San 

Mateo, 1994. 

M. Hsu and V. Kumar. Introduction to database recovery. In V. Kumar and M. Hsu, editors, Recovery 

mechanisms in database systems, pages 6–15. Prentice-Hall, 1997. 

T. Härder and A. Reuter. Principles of transaction-oriented database recovery. In V. Kumar and M. Hsu, 

editors, Recovery mechanisms in database systems, pages 16–55. Prentice-Hall, 1997. 

R. Kaschek. Konzeptionelle Modellierung. PhD thesis, University Klagenfurt, 2003. Habilitationsschrift. 

[KH97] V. Kumar and M. Hsu, editors. Recovery mechanisms in database systems. Prentice-Hall, 1997. 

[Kir08] 

M. Kirchberg. Preliminary documentation for the mucoms cms. Private communication, January-March 

2008, 2008. 

[KST09] M. Kirchberg, O. Sörensen, and B. Thalheim. A BPMN case study: Paper review and submission 

system. In GI Jahrestagung, volume 154 of LNI, pages 4067–4081. GI, 2009. 

[Kun92] 

J. Kunze. Generating verb fields. In Proc. KONVENS, Informatik Aktuell, pages 268–277. Springer, 

1992. in German. 

[LL99] M. Levene and G. Loizou. A guided tour of relational databases and beyond. Springer, Berlin, 1999. 



[Pro72] V.J. Propp. Morphologie des Märchens. Carl Hanser Verlag, München, 1972. 

[ST07] K.-D. Schewe and B. Thalheim. Pragmatics of storyboarding for web information systems: Usage 

analysis. Int. Journal Web and Grid Services, 3(2):128–169, 2007. 

[SYea03] J.E. Safra, I. Yeshua, and et. al. Encyclopædia Britannica. Merriam-Webster, 2003. 

[Tha00] 

[Vos91] 

B. Thalheim. Entity-relationship modeling – Foundations of database technology. Springer, Berlin, 

2000. 

G. Vossen. Data Models, database languages and database management systems. Addison-Wesley, 

Wokingham, England, 1991. 

[Wes07] M. Weske. Business Process Management: Concept, language, architecture. Springer, 2007. 

[WV02] 

G. Weikum and G. Vossen. Transactional information systems: Theory, algorithms, and the practice of 

concurrency control and recovery. Morgan-Kaufman, 2002. 



Abbildung 29: The general diagram for the session-based view of the processes for PC members (incomplete) 



Abbildung 30: The detailed diagram for the session-based view of processes for PC members 



Abbildung 31: The BPMN diagram with explicit representation of roles of authors 



Abbildung 32: The initial paper submission process with error handling for wrong paper format 



Abbildung 33: The help process for authors 

Abbildung 34: The sub-process for authors final paper submission 



Abbildung 35: The information and contact process of authors 

Abbildung 36: The account management subprocess for authors 



PCPhases: CMEditProfile; CMBrowseAbstr; ReviewsDue; CMViewOther; Session 

AuPhases: ASubmAbstr; ANotifAbstr; ASubmPaper; ANotifPap; Decision; FinalPDue 

PCOrgPhases: AbstractCheck; PaperCheck; ReviewsContr; Assignment; #Reviews 

Rewriting 

Expertise 

Overall 

Originality 

Significance 

Quality 

Relevance 

Presentation 

Submitted 

Confid 

Review 

Name Type Fax 

MemberID 

✛ 

Password 

Committee 

Email 

UserID 

Member 

Address 

Phone 

✛ 

✻ 

Rights 

▼ 

Of 

Contributions 

✛ 

Positive 

Negative 

Further 

Submitted 

ID 

AddReviewer 

for 

❄ 

Assigned 

Review 

Member 

Interest 

Level 

Submitted 

Title 

Paper 

Body 

Body 

✲❄ 

✲ 

PaperID 

Paper 

Authors 

✻ 

Paper 

Topic 

✲ 

ID 

Email 

Abstract 

AcceptCode 

✛ 

Password 

Submitted 

Template 

Email 

Template 

Paper 

Format 

Description 

Format 

Description 

Extension 

MimeType 

CatList 

VIEWS: 

EmailList (virt) 

AbstrNotif(mat) 

PaperNotif(mat) ... 

❄ 

Paper 

Category 

Type 

❄ 

Member 

Type 

Description 

Member 

Topic 

✲ 

❄ 

Research 

Topic 

Topic 

Description 

Category 

Description 

Abbildung 37: The database schema of the PSR system 







D - 24098 Kiel 

 





4. Sichten und Medientypen ab SS 2012 


Forschung 



4 Sichten und Medientypen 

Zwei Seelen wohnen, ach! in meiner Brust. 

Die eine will sich von der andern trennen; 

Die eine hält mit derber Liebeslust 

Sich an die Welt mit klammernden Organen; 

Die andre hebt gewaltsam sich von Dust 

Zu den Gefilden hoher Ahnen. 

Goethe, Faust, Erster Teil, Vor dem Thor, Faust 

4.1 Sichten als Hilfskonstruktion 

Die Sichtenspezifikation kann analog zur Spezifikation der Strukturierung vorgenommen werden. Sie basiert außerdem 

auf den Informationen über die Dialoge. Wir unterscheiden drei Arten von Sichten: 

Arbeitssichten, mit denen eine Bearbeitung von Daten, das Retrieval von Daten und die Ein- und Ausgabe von Daten 

auf dem Datenbankschema aufsetzend ermöglicht wird, 

Sichten zur Interaktion von Systemen, die zur Unterstützung von verteilten, föderierten oder interoperablen Systemen 

erstellt werden, und 

Sicherungssichten, mit denen die Zugriffs- und Modifikationssicherung für die Datenbank erfolgen kann. 

Sicherungssichten werden während der Spezifikation von Sicherheitsanforderungen eingeführt und interessieren uns 

hier nicht vordergründig. DBMS-Interaktionssichten werden in der konzeptionellen und der Implementationsschicht 

auf der Grundlage von Verteilungskonzepten entwickelt. Sie werden dort mit betrachtet. 

Die Spezifikation der Sichten kann auch in die Spezifikation der Schemata mit eingebettet werden. Da für die 

Akteure Daten nur im Rahmen der Dialoge von Interesse sind und diese Dialoge auch spezifisch aufbereitete Daten 

erfordern, ist eine explizite Modellierung der Sichten angebracht.

CAU zu Kiel, IfI, ISE, β 4. Sichten und Medientypen ab SS 2012 432 

Wir wollen außerdem eine Spezifikation der Anwendung auf der Grundlage eines sichtenorientierten Zuganges 

unterstützen. Deshalb benötigen wir explizite Konzepte zur Darstellung des Zusammenhanges von Sichten. Dieses 

Konzept der Sichtenkooperation wird deshalb in diesem Abschnitt ebenfalls eingeführt. Der sichtenorientierte Entwurf 

konzentriert sich stärker auf die Spezifikation der Aspekte der Anwendung, die mehr den Anwender betreffen. 

Es wird angenommen, daß eine Integration der einzelnen Sichten - so wie dies für die Anwendung eigentlich der 

Fall ist - eine lösbare Aufgabe ist. Das steht im Widerspruch zu theoretischen Resultaten. Die Sichtenintegration 

ist eine algorithmisch unlösbare Aufgabe. Es existiert kein Algorithmus, der entscheidet, ob zwei Sichten integriert 

werden können. Das Sichtenintegrationsproblem ist auch nicht semientscheidbar, d.h. es existiert auch kein Algorithmus, 

der für Sichten, die integriert werden können, die integrierende Sicht berechnet. Aus diesen Resultaten kann 

man schließen, daß ein sichtenorientierter Entwurf nicht möglich ist. Wird aber eine konkrete Anwendung betrachtet, 

dann erscheint auch in vielen Fällen eine Kombinierbarkeit der unterschiedlichen Aspekte der Anwendung gegeben. 

Wir pflegen deshalb das Wissen um die Integration der Daten direkt im Sichtenintegrationsschema. 



4.1.1 Sichten in SQL 

Relationale Sicht wird definiert durch Relationenschema V der Sicht (meist wird außerdem angenommen Σ V = ∅) 

und einer Anfrage über einem relationalen Datenbankschema 

Relationale Sichtensuite wird definiert durch ein Datenbankschema mit relationalen Sichten 

Probleme: 

Modifikation der Grunddatenbank durch Sichten (Sichten-Update-Problem) [Bei Nichtidentifizierbarkeit von Objekten 

der Grunddatenbank durch eine Sicht, ist ein Modifikation der Datenbank verboten. Dieses Problem 

kann gelöst werden durch separate Modifikationssichten neben den Retrievalsichten, die durch Hilfssichten 

miteinander und mit der Grunddatenbank gekoppelt werden.] 

Virtualisierung oder Materialisierung von Sichten ohne oder mit Kollaborationsvertrag 

Sichtendefinition in SQL über Anfragesprache 

als VIRTUELLE Tabelle 

CREATE VIEW SUPERSTUDIOSI (Name, Fach, Lehrer) 

AS SELECT x.Name, y.Kurs, z.Name 

FROM PERSON x, TEILNAHME y, PERSON z, STUDENT, PROFESSOR 

WHERE STUDENT.PNum = x.PNum AND y.SNum = STUDENT.SNum 

AND y.LesenderPNum = PROFESSOR.PNum AND PROFESSOR.PNum = z.PNum 

AND y.Note = 1.0 

GROUP BY x.Name 

DROP VIEW SUPERSTUDIOSI 

Vorsicht mit updates über Sichten 

siehe Vorlesung Datenbank-Programmierung 

Ableitbarkeit von Aspekten durch Sichten 

Unterstützung von Sichten Gegeben sei eine Sicht S V über V mit einer Menge von Integritätsbedingungen Σ V , 

die in S V gelten sollen. Dann wird gefordert, daß diese Sicht berechnet werden kann. 

∀V ⊆ U(∧Σ V = Σ + | V )∃Q∀R t UnivRrel(R t [V ]) ⊆ Q(R) 

Sichere Unterstützung von Sichten wenn = 

Sichtenanfrage-Unterstützung ∀Q ∈ Query(V, R)∃P ∈ Query(U, R) : Q(V t ) = P (R t ) 

Sichtenbehandlung: 

Sichtenanfrage-Unterstützung gdw. Unterstützung von Sichten 

im positiven Fall sogar effizient 

sichere Unterstützung von Sichten gdw. ( ⋃ F i ) + ⊇ F und (U 1 , ..., U m ) ∈ Σ +


4.1.2 Views in the Enhanced Entity-Relationship Models 

Classically, (simple) views are defined as singleton types which data is collected from the database by some query. 

create view NAME (PROJECTION VARIABLES) as 

select PROJECTION EXPRESSION 

from DATABASE SUB-SCHEMA 

where SELECTION CONDITION 

group by EXPRESSION FOR GROUPING 

having SELECTION AMONG GROUPS 

order by ORDER WITHIN THE VIEW; 

Since we may have decided to use the class-wise representation simple views are not the most appropriate structure 

for exchange specification. The EER schema allows to directly specify a view schema by 

• a schema V = {S 1 , ..., S m }, an auxiliary schema A and 

• a query q : D × A → V defined on D and V. 

Given a database D C and the auxiliary database A C . The view is defined by q(D C × A C ). 

Additionally, views should support services. Views provide their own data and functionality. This object-orientation 

is a useful approach whenever data should be used without direct or remote connection to the database engine. 

We generalize the view schema by the frame: 

generate MAPPING : VARS → OUTPUT STRUCTURE 

from DATABASE TYPES 

where SELECTION CONDITION 

represent using GENERAL PRESENTATION STYLE 

& ABSTRACTION (GRANULARITY, MEASURE, PRECISION) 

& ORDERS WITHIN THE PRESENTATION & POINTS OF VIEW 

& HIERARCHICAL REPRESENTATIONS & SEPARATION 

browsing definition CONDITION & NAVIGATION 

functions SEARCH FUNCTIONS & EXPORT FUNCTIONS & INPUT FUNCTIONS 

& SESSION FUNCTIONS 

& MARKING FUNCTIONS 

The extension of views by functions seems to be superficial during database design. Since we extensively use 

views in distributed environments we save efforts of parallel and repetitive development due to the development of 

the entire view suite instead of developing each view by its own. 

XML as the display medium 

XML specifications can be automatically generated out of this view 

Algebraic expressions for views 

Views for internet presentation as Read-Only-View 

Archive view 

Be careful: changing set of integrity constraints! 

Insert view for new course proposals: als Read-Write-View with identifiable sub-views and side conditions 

with optional and mandatory components 

Media object schema as containers based on views with container functionality and attached functions 

representation bound by order, adhesion, cohesion of types 

tailored by user profile, user environment, history, channel capacity 

are associated with dialogue scenes 

Views may be used for distributed or collaborating databases. They can be enhanced by functions. Exchange frames 

are defined by 

• an exchange architecture usually provided a system architecture integrating the information systems through 

communication systems, 

• a collaboration style specifying the supporting programs, the style of cooperation and the coordination facilities, 

and 

Mod IS


required 

Course 

retrieve 

❑ 

(1,1) 

❄ 

Course 

retrieve, select, input 

❦ 

Program 

retrieve, select 

+ 

❦ 

{} 

✛ 

Description = “SS01/02” 

 

Proposal 

Semester 

retrieve 

✲ 

✻ 

Chair 

retrieve 

✻ 


✲ 

Person 


retrieve 

insertedBy 

✒ = “SecrKK” 

Teacher 

Responsible4Course = “β” 

proposed 

Wish 

Course 

input 

Time(Proposal, 

SideConditions) 

default = Profβ 

ShortDescr = “DBIS” 

✲ 

✯ 

Room 


✶ 

✰ 

Kind 


Abbildung 1: HERM View: Insertion view for new course proposals 

• collaboration pattern specifying the data integrity responsibilities, the potential changes within one view and 

the protocols for exchange of changes within one view. 

4.1.3 Advanced HERM Views and OLAP Cubes 

The extended entity-relationship model can be used to define an advanced data warehouse model. Classically, the 

data warehouse model is introduced in a intuitive form by declaring an association or relationship among components 

of the cube (called dimensions), by declaring attributes (called fact types) together with aggregation functions. Components 

may be hierarchically structured. In this case, the cube schema can be represented by a star schema. Components 

may be interrelated with each other. In this case the cube schema is represented by a snowflake schema. 

Star and snowflake schemata can be used for computing views on the schemata. View constructors are functions like 

drill-down, roll-up, slice, dice, and rotate. We demonstrate the power of the extended entity-relationship model by a 

novel, formal and compact definition of the OLAP cube schema and the corresponding operations. 

The data warehouse model is based on hierarchical data types. Given an extended base type B = (Dom(B), Op(B), P red 

we may define a number of equivalence relations eq on Dom(B). Each of these equivalence relations defines a partition 

Π eq of the domain into equivalence classes. These equivalence classes c may be named by n c . Let us denote 

named partitions by Π ∗ . The trivial named partition that only relates elements to themselves is denoted by ⊥ ∗ . We 

denote the named partition that consists of {Dom(B)} and a name by ⊤ ∗ . 

Equivalence relations and partitions may be ordered. The canonical order of partitions on DOM(B) relates two 

partitions Π ∗ , Π ′∗ . We define Π ∗ ≼ Π ′∗ iff for all (c, n c ) from Π ∗ there exists one and only one element (c ′ , n c ′) ∈ Π ′∗ 

such that c ⊆ c ′ . 

We also may consider non-classical orderings such as the majority order ≼ choice 

m 

for all (c, n c ) from Π ∗ there exists one and only one element (c ′ , n c ′) ∈ Π ′∗ such that 

either |c ∩ c ′ | > max{|c ∩ c ′′ | | (c ′′ , n c ′′) ∈ Π ′∗ , c ′′ ≠ c ′ } 

or (c ′ , n c ′) ∈ Π ′∗ is determined by a (deterministic) choice operator among 

{c + ∈ Π ′∗ | |c ∩ c + | = max{|c ∩ c ′′ | | (c ′′ , n c ′′) ∈ Π ′∗ }}. 

that relates two named partitions iff 

If the last case does not appear then we omit the choice operator in ≼ choice 

m . 

The DateT ime type is a typical basic data type. Typical equivalence relations are eq hour and eq day that relate 

values from Dom(DateT ime) that belong to the same hour or day. The partitions ⊥ ∗ , Days, W eeks, Months, 

Quarters, Y ears, and ⊤ ∗ denote the named partitions of highest granularity, the named partitions of DateT ime 

by days, by weeks, by months, by quarters, by years, and the trivial no-granularity named partition, correspondingly. 

We observe ⊥ ∗ ≼ Π ∗ and Π ∗ ≼ ⊤ ∗ for any named partition in this list. We notice too that Days ≼ Months ≼ 

Quarters ≼ Y ears. 

Mod IS


W eeks ≼ m Months is a difficult ordering that causes a lot of confusion. 

This notion of hierarchical data types can be extended to complex attribute types, entity types, cluster types 

and relationship types. These extended types are also called hierarchical types. Aggregation functions are defined for 

extension based data types. The cube definition uses the association between attribute types and aggregation functions 

The grounding schema of a cube is given by a (cube) relationship type 

R = (R 1 , ...., R n , {(A 1 , q 1 , f 1 , ), ..., (A m , q m , f m )}) with 

• hierarchical types R 1 , ...., R n which form component (or dimension) types, 

• (“fact”) attributes A 1 , ..., A m which are defined over extension based data types and instantiated by singletonvalue 

queries q 1 , ..., q m and 

• aggregation functions f 1 , ..., f m defined over A 1 , ..., A m . 

The grounding schema is typically defined by a view over a database schema. 

Given a grounding schema R = (R 1 , ...., R n , {(A 1 , q 1 , f 1 , ), ..., (A m , q m , f m )}), a class R C , and partitions Π i 

on DOM(R i ) for any component R 1 , ..., R n . A cell of R C is a non-empty set σ R1 ∈c 1 ,...E n ∈c n 

(R C ) for c i ∈ Π i and 

for the selection operation σ α . Given now partitions Π 1 , ..., Π n for all component types, a cube cube Π∗ 1 ,...,Π∗ n (R C ) on 

R C and on Π ∗ i , 1 ≤ i ≤ n consists of the set 

{σ R1 ∈c 1 ,...R n ∈c n 

(R C ) ≠ ∅ | c 1 ∈ Π 1 , ..., c n ∈ Π n } 

of all cells of R C for the named partitions Π ∗ i , 1 ≤ i ≤ n. If Π∗ i = ⊤∗ then we may omit the partition Π ∗ i . 

Therefore, a cube is a special view. We may materialize the view. The view may be used for computations. Then 

each cell is recorded with its corresponding aggregations for the attributes. For instance, sum(π PriceOfGood (σ SellingDate∈W eekx ( 

computes the total turnover in week x. 

Spreadsheet cubes are defined for sequences Π ∗ 1 ≼ ... ≼ Π∗ n of partitions for one or more dimensional components. 

For instance, the partitions Days, Months, Quarters, Y ears define a spreadsheet cube for components 

defined over DateT ime. 

The cube can use another representation: instead of using cells as sets we may use the names defining the cells as 

the cell dimension value. This representation is called named cube. 

This definition of the cube can be now easily used for a precise mathematical definition of the main operations 

for cubes and extended cubes. For instance, given a cube with a partitions Π ∗ , Π ′∗ for one dimensional component 

with Π ∗ ≼ Π ′∗ , the drill-down operation transfers a cube defined on Π ′∗ to a cube defined on Π ∗ . Roll-up 

transfers a cube defined on Π to a cube defined on Π ′∗ . The slice operation is nothing else then the objectrelational 

selection operation. The dice operation can be defined in two ways: either using the object-relational 

projection operation or using ⊤ partitions for all dimensional components that are out of scope. More formally, the 

following basic OLAP query functions are introduced for a cube cube Π∗ 1 ,...,Π∗ n (R C ) defined on the cube schema 

R = (R 1 , ...., R n , {(A 1 , q 1 , f 1 , ), ..., (A m , q m , f m )}) , a dimension i, and partitions Π ∗ i ≼ Π′∗ i ≼ ⊤ ∗ i : 

Basic drill-down functions map the cube cube Π∗ 1 ,...,Π′∗ i ,...,Π∗ n (R C ) to the cube 

cube Π∗ 1 ,...,Π∗ i ,...,Π∗ n (R C ). 

Basic roll-up functions map the cube cube Π∗ 1 ,...,Π∗ i ,...,Π∗ n (R C ) to the cube 

cube Π∗ 1 ,...,Π′∗ i ,...,Π∗ n (R C ). 

Roll-up functions are the inverse of drill-down functions. 

Basic slice functions are similar to selection of tuples within a set. The cube 

cube Π∗ 1 ,...,Π∗ n (R C ) is mapped to the cube σ α (cube Π∗ 1 ,...,Π∗ n (R C )). 

The slice function can also be defined through cells. Let dimension(α) the set of all dimensions that are 

restricted by α. Let further 

σ ⊓ α(c i ) = 

{ ∅ if Ri ∈ dimension(α) ∧ σ α (c i ) ≠ c i 

c i 

otherwise 

Mod IS


Close slice functions restrict the cube cells to those that entirely fulfill the selection criterion α, i.e., {σ R1 ∈σ ⊓ α(c 1 ),...R n ∈σ ⊓ α( 

∅ | c 1 ∈ Π 1 , ..., c n ∈ Π n }. 

Liberal slice functions restrict the cells to those that partially fulfill the selection criterion α, i.e. to cells 

{σ R1 ∈σ α(c 1 ),...R n∈σ α(c n)(R C ) ≠ ∅ | c 1 ∈ Π 1 , ..., c n ∈ Π n }. 

Lazy and eager slice functions apply the selection functions directly to values in the cells. 

Basic dice functions are similar to projection in the first-order query algebra. They map the cube cube Π∗ 1 ,...,Π∗ i ,...,Π∗ n (R C ) 

to the cube cube Π∗ 1 ,...,⊤∗ i ,...,Π∗ n (R C ). 

Basic dice functions are defined as special roll-up functions. We also may omit the dimension i. In this case we 

loose the information on this dimension. 

Generalizing the first-order query algebra, [Tha00] defines additional OLAP operations such as 

join functions for mergers of cubes, 

union functions for union of two or more cubes of identical type, 

rotation or pivoting functions for rearrangement of the order of dimensions, and 

rename functions for renaming of dimensions. 

Our new definition of the cube allows to generalize a large body of knowledge obtained for object-relational databases 

to cubes. The integration of cubes can be defined in a similar form [Mol07]. 

OLAP and the paradoxes. 

siehe auch Data mining course 

Content Management Teil 3 

Modelling the Warehouse. 

We start with a more detailed discussion of structural aspects but keep the presentation rather informal. Throughout 

this section we use a simplified version of the grocery store example from Kimball [?] to illustrate our ideas. 

We shall first see how to model the application star schema using the entity-relationship model. We demonstrate that 

ER is well-suited for warehouse modelling contradicting statements made in some warehouse publications [?]. Then 

we show how to obtain the star schema as a view in the case of a single operative database. The more realistic case 

of several operative databases appears as a simple generalisation. Finally, we handle the case of a snowflake schema 

using dimension hierarchies. 

Efficient algorithms for the translation of HERM views into bundles of relational views exist [Tha00] and can 

then be used for a realisation of those views. 

The Grocery Store Example. 

An OLAP application. Suppose we want to analyse the development of sales in a grocery chain. We might, e.g., 

want to know how many items of certain products have been sold in certain stores or regions over some period of 

time, what the corresponding sale was and how much profit we made. So the facts we are interested in are Quantity, 

Money sales and Profit. The dimensions are TIME, PRODUCT, CUSTOMER and SHOP. 

Then the facts Quantity, Money sales and Profit appear as attributes of the relationship type PURCHASE. In 

addition, we may have attributes PID, Description, Category for the entity type PRODUCT, attributes SID, Town, 

Region, State, etc. for the entity type SHOP, attributes TID, Weekday, Month, Quarter, etc. for the entity type 

TIME and attributes Name, Address, Category, etc. for the entity type CUSTOMER. 

Note that a relational transformation usually will turn key attributes of the dimension types (xID) into foreign 

keys for a fact table. Figure 2 shows the corresponding (simplified) ER schema in HERM notation [Tha00]. 

Mod IS


TID TIME . . . 

✻ 

Address(Addr1,Addr2,Addr3,Town,State,Zip) 

Money sales Profit 

Name(CID) 

Name(Category) 

CUSTOMER ✛ PURCHASE 

Quantity 

Name(First,Surname) 

❄ 

Description PRODUCT 

Name Town State 

✲ SHOP 

Region Phone SID 

PID Category 

Abbildung 2: Grocery Example: Star Schema on PURCHASES 

Kind Description 

. . . 

Date Price 

PID PART ✛ PRICE ✲ STORE 

2 

Cost 

✻ 

Category CID 

Name(First,Surname) 

PERSON 

✛ 

BUYS 

Address(Addr1,Addr2,Addr3,Town,State,Zip) 

Quantity Time 

Abbildung 3: Grocery Store: Operative Sales Schema 

The operational database. The data to be stored in instances of the warehouse schema mostly stems from operative 

databases. So assume that each purchase in a store will be registered together with the date and the number of items 

sold. In addition we keep a price relation also depending on the date. For the moment we leave aside any further 

decomposition for products and stores. The date can be assumed to be composed of day, month and year. This is 

usually sufficient for operative purposes. In order to relate a date to the more complex data needed in the entity type 

TIME in the star schema, we may assume a general pre-determined time table containing all the time attributes needed 

there. Of course, (day, month, year) will appear as a composed key. 

Figure 3 shows an ER schema for such a simple sales database (omitting some attributes). Note that this schema 

is not yet normalised, but for the sake of simplicity we abstain from further decomposition. 

External Views. 

The central claim made in the introduction is that the star schema occurs as an external view on the operative sales 

schema (enriched by the assumed time table). In general, a view is nothing but a stored query, hence consisting of 

an input schema S in , an output schema S out and a database transformation V mapping instances of S in to instances 

of S out . Additionally, representation, formation and wrapping rules [?] can be added to the view depending on the 

dialogue object. 

In our example S in is the (enriched) sales schema (Figure 3) and S out is the star schema (Figure 2). Since ER 

schemata—even higher-order schemata—are basically hierarchical in the sense that relationship types are based on 

entity types, it is sufficient to employ sequences of SELECT-FROM-WHERE statements to define the mapping V . 

Different views can be defined for the application sketched above. The view displayed in Figure 2 is a star schema 

based on a relationship type. This star schema can be obtained via the following view definition: 

Mod IS


SELLING 

PERIOD 

✻ 

PROMOTION 

PERIOD 

✻ 

CUSTOMER 

CATEGORY 

IN 

✲ 

TIME 

✛ 

DURING 

REGION 

✻ 

OF 

✲ 

CUSTOMER 

✛ 

✻ 

PURCHASE 

✲ 

❄ 

SHOP 

✛ 

✻ 

SINREG 

PRODUCTION 

✛ 

POFP 

✲ 

❄ 

PRODUCT ✛ ✲ 

PINC 

CATEGORY 

Abbildung 4: Grocery Store: Snowflake Schema on Purchases 

create view StarSchema as 

Product : select PID : p.PID , Category : p.Kind , 

Description : p.Description 

from Part p , 

Time : select Time 

from Buys 

Customer : select Name : c.Name, CID : c.CID, 

Address : c.Address, Category : c.Category 

from Person c 

where ... Category ... 

Shop : select ... 

from Store s 

Purchase : select Customer(CID) : ..., Product(PID) : ..., 

Time(TID) : ..., ..., Shop(SID) : ..., 

Money sales : ..., Quantity : ..., Profit : ... 

from Buys(Part, Person, Store), Price pr 

where ... ; 

In the same fashion the snowflake schema displayed in Figure 4 (partially without attributes) can be generated on 

the schema discussed in Section 4.1.3. 

Dimension Hierarchies. 

In many cases it is desirable to consider more complex warehouse schemata than the flat star schema. This 

situation usually occurs if dimensions are organised hierarchically. E.g., products can be grouped into BRAND and 

shops into REGION. Using the higher-order ER model, BRAND and REGION will now occur as entity types and the 

original types will be turned into unary relationship types. For the case of our grocery store example, this situation is 

illustrated by the snowflake schema in Figure 5, omitting all attributes. 

In a number of OLAP applications similar hierarchies for the presentation of time, products, people, organisations, 

addresses, etc. are used. We can define ER schemata for hierarchies. The corresponding databases may be instantiated 

automatically. The schemata can be used for the generation of hierarchic view sets. 

OLAP schemata are then views defined on the basis of the application ER schema and on ER schemata for 

hierarchies. In this case, the snowflake schema displayed in Figure 4 is generated on the basis of the application 

discussed in Section 4.1.3 and on view types which are defined on hierarchy schemata for time, addresses, customer 

categories and product categories. 

Mod IS


BRAND TIME REGION 

✻ 

✻ 

✻ 

PRODUCT ✛ 

PURCHASE 

✲ 

SHOP 

Abbildung 5: Grocery Store: Snowflake Schema with Dimension Hierarchies 

Time 

... 

WeekInQuarter 

Week 

DayInQuarter 

DayInYear 

Weekday 

MonthDay 

Day 

Holiday 

FinancialYear 

FinancialMonth 

FinancialWeekOfYear 

FinancialWeekOfQuarter 

FinancialWeek 

FinancialDay 

... 

FinancialDayOfYear 

No 

No 

Year ✛(4,4) Quarter ✛(3,3) 

Month 

✶ 

No Kind (13,14) ✻ 

WeekInM 

✻(28,31) 

Name 

☛ 

No 

Week ✛(7,7) (1,1) 

Weekday ✲ Day ✛(0,1) 

Holiday 

No 

Name 

Abbildung 6: Extended HERM Schema and OLAP Representation of Time 

Time is modelled in OLAP applications on the basis of universal relation assumptions. The representation of 

time defined for the higher-order ER model uses several relationship types. The OLAP representation in Figure 6 

is based on the universal relation approach. The OLAP type has 25 attributes. Additionally, an identifier attribute 

may be introduced. A large number of integrity constraints must be considered. The time dimension is necessary in 

OLAP applications because it facilitates slicing of data by workdays, holidays, fiscal periods, seasons and by major 

events. The time dimension is guaranteed to be present in every warehouse application, because virtually every data 

warehouse depends on a time series. Time is usually the first dimension for sorting. 

The representation of time (where some information can be derived but is still explicitly contained) shows that 

OLAP schemata are redundant. Denormalisation is common in OLAP schemata. Understanding OLAP schemata as 

views with redundant representation and denormalisation does not create any problem. 

Based on the roll-up and drill-down functions discussed below it is possible to display data in different granularity. 

This approach can be simulated by families of views. The family is generated in dependence of a given generalisation 

hierarchy. For instance, given the hierarchies 

Product ≼ Brand ≼ Manufacturer and Shop ≼ Area ≼ Region, 

we can create a query on shops and products. This query can be contracted according to the hierarchies to queries on 

brands, regions, etc. 

With regard to being defined as views on operative database schemata, snowflake schemata do not add additional 

complexity since they simply correspond to some kind of normalisation along functional or multi-valued dependencies. 

The same normalisation can be expected in the underlying operative databases. 

Modelling OLAP Applications. 

Now we turn to the problem of how to realise OLAP functionality in management support systems. Since OLAP 

Mod IS


applications constitute particular dialogue oriented information systems we should preserve the technology developed 

for such information systems [?, ?, ?, Tha96] as much as possible. 

We start looking at the presentation of facts in sections of the data warehouse followed by an investigation of 

typical actions involved in such presentations. This will lead us to a short discussion of dialogue objects and their suitability 

for OLAP. Finally, we discuss the tuning of presentation granularity which will constitute further operations. 

Presentation of Facts. 

The typical OLAP scenario assumes a manager to query the warehouse. Since familiarity with sophisticated query 

languages cannot be presumed, such a query should be expressible in terms understandable to the user, i.e.: 

• The manager selects the facts (s)he wants to consider. E.g., in our grocery store example (s)he may choose to 

look only at money sales perhaps with a percentage-based comparison to an earlier period. 

• The manager selects the dimensions and their granularity along which the selected facts should be presented. 

In our grocery store example this can be time, e.g., on the basis of last year’s quarters, individual products and 

regions. 

• In addition to the dimensions a specification of their relevant descriptive attributes is needed. E.g., it may be 

sufficient to get the product name and the grammalogues for the region and quarter. 

• The manager states additional selection criteria to restrict the data to be presented. E.g., only stores that belong 

to a certain category (cheap or expensive equipment, etc.) or products offered in the most recent promotion 

campaign should be considered. 

• Criteria for the grouping and ordering of the facts and dimension attributes should be given. 

• Finally, the presentation of the result should be specified. E.g., tabular or graphical presentations such as scroll 

lists, beam or tart diagrams should be available. 

The data to be presented constitute a view on the warehouse. Since we argued that the warehouse itself can be realised 

as a view on the operative multi-database, each data selection in an OLAP application constitutes also a view on the 

operative databases. Whether the intermediate warehouse level and maybe also other views are materialised or not 

depends on technical aspects. The manager need not be aware of any connection to the underlying operative databases. 

(S)he may not even be aware of snowflake schemata if these have been designed, since the star schema is also 

a view on the snowflake schema. Finally, whether the star schema is presented to managers directly by the entityrelationship 

schema or simply by the list of available facts, dimensions, larger dimensions and dimension attributes, 

can be left to the manager’s preferences. 

Since the queries underlying the views are conjunctive a simple QBE like entry form will be sufficient. Thus, it 

is recommended to couple the view with actions to select facts, dimensions, dimension attributes, to add restricting 

conditions and to choose presentation preferences. We may therefore consider the presented data together with the 

actions on them as describing an object, namely a dialogue object (d-object). 

More formally, a dialog object (d-object) consists of a unique abstract identifier, a set of values v 1 , . . . , v n in 

associated fields F 1 , . . . , F n which correspond to describing values of d-objects, a set of references to other d-objects 

in order to allow quick navigational access, a set of actions to change the data and to control the dialogue, and a state 

with the possible values ‘active’ and ‘inactive’. This means that d-objects only exist as long as they are visible on the 

screen. If a window is closed the corresponding d-object ist deleted. 

The identifier serves the purpose of administrating d-objects. It is not known to and cannot be used by the user 

and is not visible. Only the active d-object allows manipulations of the represented data and only its actions can be 

invoked. 

Users invoke actions to change selection criteria, to navigate to another (possibly new) dialogue object or to a 

modified presentation of the same dialogue object. This kind of system usage constitutes the basic object-actionprinciple 

in dialogue systems. Users enter or select values on the screen and invoke actions—usually grouped in 

menus—on them. The dialogue system reacts by offering other data or by activating and deactivating entries in 

selection lists or possible actions in the action bar. In graphical user interfaces data are normally presented in a 

window. 

Mod IS


REGION 

Region 

✛ 

SALES PER 

REGION 

✲ 

TIME 

✻ 

Year 

Quarter 

SID 

Town 

SHOP 

✛ 

SALES PER 

SHOP 

Money sales 

Abbildung 7: Grocery Store: Schema underlying a D-Type 

Once we know that the data in a d-object may be used in the next dialogue step, it may be helpful to provide also 

hidden data. Their presence may quicken the access to the database or the navigation to other d-objects. Depending 

on selections or entries made in a d-object only some of the possible actions may be allowed. The processing of an 

action may require further preconditions depending on the state of the dialogue system especially on other users’ 

d-objects. 

Note that the selection of grouping, ordering and screen presentations does not affect the dialogue object itself. 

Thus, presentational aspects can be treated separately from the core of data processing. 

Dialogue Types. 

Conceptually, we are not interested in individual d-objects but want to classify them into types. We shall, therefore, 

talk about dialogue types (d-type). Dialogue types unify structural, behavioural and presentational aspects of an 

application by combining view definitions, action specifications and rules for presenting an dialogue object’s contents 

to the user [?]. 

Structural aspects. At the heart of such a d-type we provide a view consisting of a (higher-order) ER schema and 

a defining query. The schema is the output schema S out mentioned in the previous section; the defining query is 

the sequence V of query language statements which create instances of S out . The input schema S in can be omitted. 

It is generally assumed that the warehouse schema—star or snowflake schema—is taken for this purpose. The view 

definition may be parameterised. Parameters are either specified as defaults in the d-type definition or can be modified 

by the user during interaction. 

In addition, as indicated above, we may choose a subset of the query result as the data to be actually presented 

while keeping the rest for fast support of operation. This constitutes the visual schema VS out as a subschema of S out . 

The view definition of the visual schema may again be parameterised. Visibility functions determine the respective 

parameters on the basis of default definitions, actions invoked by the user and/or explicit user specifications. 

Building upon the grocery store warehouse from Figure 2 the d-type may, e.g., involve money sales per shop 

and region, but only the money sales per region will be presented to the user. Then the output schema S out could 

be as presented in Figure 7 and the visual schema VS out would be the subschema in which the relationship type 

SALES PER SHOP and the entity type SHOP have been omitted (cf. Figure 7). We abstain from a detailed description 

of the defining query which would use the star schema in Figure 2 as the input schema S in . 

Behavioural aspects. Attached to the view we provide a collection of operations such as those discussed in Section 

4.1.3. Such actions allow the user to navigate within the view (e.g., to formerly hidden parts), to navigate between 

views and to switch between different presentations of data. In addition to typical OLAP actions as described below, 

help functions can be made available, too. 

Similar to the structural part that contains both visible and hidden data, dialogue actions are not necessarily 

accessible at all times. Availability of actions is controlled by action access functions which determine availability on 

the basis of the user’s access rights, etc. For instance, based on the example in Figure 7, adding the fact Money sales 

Mod IS


from the entity type SALES PER SHOP might only be possible for managers on a high enough level of the enterprise’s 

hierarchy. Similar restrictions could exist for drill-down operations in certain dimensions. 

To guarantee stable performance of the application exceptions are defined for the case that the use of a dialogue 

object causes problems. 

Presentational aspects. Both data and actions—as long as they are not hidden—must be made available to the user. 

Presentation rules are generally defined globally for the overall application—independently from individual dialogue 

types. Such rules determine, e.g., graphical widgets to be used for visualisation (buttons or menus for actions, text 

fields for textual data, etc.). Furthermore, they can control the layout of visualisations based, e.g., on the space 

available on the screen and on the information to be conveyed. 

D-types will, however, provide parameters for such presentation rules. Parameters are, e.g., labels that are to be 

used for visualising dialogue objects (title bar) and individual data or actions. Other parameters are diverse semantical 

properties of data such as emphasis, priority, adhesion, etc. [?]. If statistical anomalies are discovered during the 

execution of a dialogue object (a shop whose sales significantly exceed the average) local presentation rules can, e.g., 

characterise such anomalies as important. Global presentation rules will then use the parameter important to choose 

red colour, flashing font, etc. 

Conceptually, presentation design of d-types is therefore concerned with a description of the data and actions 

involved and/or with the specification of rules that automatically compute such descriptions, rather than with an 

explicit assignment of presentations. We specify labels, semantical properties, adhesions between data items, rules, 

etc. but no concrete widgets, colours or fonts. 

At the implementational level, presentation rules use these descriptions to create physical presentations of dialogue 

objects. There can be several presentation rules available for one concept which can, e.g., create a graphical or 

a forms-based presentation for the same d-type. Presentation rules are selected at system run-time in dependence of 

the user’s preferences or actions invoked. 

OLAP Actions. 

In OLAP applications, roll-up operations and drill-down operations are used for generalisation and specialisation 

of fact tables. Aggregation of detailed data to create summary data is called roll-up. Usually, roll-up is based on two 

operations: grouping of data according to some characteristics (e.g., total sales by city and product) and navigation 

through an attribute hierarchy (e.g., from sales by city towards sales by state and sales by country). Navigation to 

detailed data from summaries is called drill-down. It provides the data set that was aggregated (e.g., displaying the 

‘base’ data for total sales figure for the state CA). Selection which is called slicing in OLAP applications defines 

a subdatabase (e.g., sales where city=“Berkeley” or reducing the relationship dimensions by specifying coordinates 

of remaining dimensions). The last observation shows that minimum and maximum functions yield the same result 

after application of roll-up operations or drill-down operations. The same property is valid for pull, pivoting and push 

operations [AGS97b]. These functions can be generalised to reordering or rearrangement functions. OLAP operations 

can be completely based on operations defined for ER models [Tha00]. 

• Classical database operations are also applicable to views. For this reason, the following functions are defined 

for views: 

• Selection on relationship types is the ER expression for dice. 

• The slice operation is expressed by projection on relationship types. 

• The set-theoretic operations union, intersection, cartesian product and difference and component renaming 

are elements of the ER algebra. 

• Calculations within one component type or across component types are expressed by algebraic functions. Ranking 

functions are based on the computation of sets, ordering and creating supporting views. Extensions such 

as tertile, quartiles, ratio to report, cume, moving average, moving sum are expressible in ER-SQL [Tha00]. 

• Visualisation functions do not produce another view. They are used for reordering the schema. Functions such 

as nest and rotate can be represented by ER operations. Ranking functions are expressed by order by con- 

Mod IS


structs. Dynamic breakpoints are used to start a new view for computation. They require the utilisation of 

dynamic SQL. Extending ER-SQL to dynamic ER-SQL can be performed in the fashion known for SQL. 

• Aggregation can be expressed by view definition in database languages. 

• The roll-up function (also called drill-up) is used for dimension reduction on the basis of aggregation 

functions. Navigation through an attribute hierarchy can be expressed by escorting queries. The complex 

cube operation is a set of roll-up operations and expressible in ER-SQL. 

• The drill-down function is just the inverse operation of roll-up. 

• The aggregation functions min, max, sum, avg, count can be expressed by summarisation. This function 

generalises the aggregation functions. 

• Schema restructuring has been generalised by Gyssens and Lakshmanan [GL97]. Classification, fold and unfold 

can also be generalised in the ER algebra. 

Unfold defines a new view on a relationship type and a set of components of the relationship type by introducing 

a new type on the set and a new relationship type with the remaining components of the first type 

and the set component. Unfold generalises the unnest operation. 

Fold restructures a schema to a new schema for a component of a choosen relationship type. Fold generalises 

the nesting operation. 

Classification is a specific grouping operation. 

Schema restructuring operations are operations which can be expressed by graph grammar rules. 

• OLAP applications are also based on analytical functions which are defined on the basis of mathematical 

models. Since OLAP data can be understood as derived data which can be materialised, analytical functions 

can also be defined for databases. 

¿From the user’s point of view typical actions invoked—besides choosing a completely new view in the sense 

presented above—are devoted to achieve finer or coarser tuning of the presented information: 

• A user may choose to extend or restrict the fact list. In the example sketched in Section 4.1.3, the facts Quantity 

and Profit may be added. Note that the evaluation of the corresponding query may exploit data already presented 

as an intermediate result. 

• A user may choose to add or remove a dimension. For example, a manager looking at the data selection 

indicated above may remove the product dimension and simply look at Money sales in different regions. 

Again, query evaluation is simplified by the existing data contents of the dialogue object. 

• A user may add or remove dimension attributes. The required processing is analogous to changes in the fact 

list. 

• The user may change dimension granularity. Such drill-down or roll-up operations switch to a smaller or larger 

dimension. For example, the user may replace REGION by SHOP or PRODUCT by BRAND walking along the 

hierarchies in the snowflake schema. 

• The selection criteria may be weakened or strengthened leading to a larger or smaller result. Here again, the 

reuse of the existing query result may help to fasten query processing. 

• The user may mark a section of the presented data and invoke an aggregate function on them such as summation, 

average computation, normalising at a given index 100, etc. In our grocery store example the money sales per 

shop could be considered. 

• Grouping, ordering and presentation style may be changed. As already stated above, this does not lead to a 

new query and only affects general presentational issues. It is possible to achieve this functionality by using 

different presentation rules. 

Mod IS


4.1.4 Pragmas und Direktiven für Sichten 

Unterschiedliche Behandlung von Sichten: 

Virtuelle Sichten als spezielle vorbereitete Anfrageausdrücke 

Anfrageexpansion 

Sicherungssichten zur Kontrolle des Zugriffes 

Zugriffssichten 

Materialisierte Sichten als vorbereitete Datenmengen unter Berücksichtigung von 

Erzeugung der Sichten im deferred oder immediate Modus 

Erfrischungsmodus im on commit oder on demand Modus 

Erfrischungsmethode mit complete Refresh oder fast Refresh, sowie als Kompromiß mit force (erst 

fast, falls nicht möglich dann complete) 

Anfrage-Rewriting 

4.1.5 Sichtenorientierte Entwicklung von Informationssystemen 

Wir unterscheiden Sichten für strukturelle Aspekte und Sichten für funktionale Aspekte. Diese unterschiedlichen Begriffe 

wollen wir im weiteren auseinanderhalten. 

Ein sichtenorientierter struktureller Entwurf ist am einfachsten in der Top-Down-Strategie integrierbar. In diesem 

Fall wird zur Darstellung der strukturellen Zusammenhänge ein Skelett benutzt. Es dient zur expliziten Spezifikation 

der Abbildungen von einzelnen Konstrukten der Sichten untereinander. Jeder neue Entwurfsschritt, 

der sich auf eine andere Sicht aufgrund dieses Skeletts auswirken kann, zieht eine Entwurfsobligation nach 

sich. Entwurfsobligationen können sofort nach einem Schritt betrachtet werden oder im deferred-Modus auch 

zu einem späteren Zeitpunkt bearbeitet werden. Der späteste praktikable Zeitpunkt ist das Entstehen weiterer 

Obligationen aus diesen Obligationen. In diesem Fall treten typische Probleme der Sichtenintegration wie die 

im folgenden behandelten Probleme nicht auf. 

Ein sichtenzentrierter funktionaler Entwurf orientiert sich an den Hauptprozessen und den Dialogen. Es wird für 

jeden Prozeß bzw. Dialog eine entsprechende Sicht erzeugt, die die Verarbeitung der Daten ermöglicht. Daten 

können unterschieden werden in Retrievaldaten, die mit einer Retrievalanweisung anhand der Datenbank gewonnen 

werden, in Inputdaten, die ein Benutzer in eine Datenbank einfügt, Outputdaten, die einem anderen 

Prozeß (z.B. einem Outputprozeß) übermittelt werden, und Begleitdaten, die in einem Prozeß als Zusatzinformation 

dienen bzw. von anderen Prozessen stammen. Diese Daten können zusätzlich Displaydaten sein. 

Für die Entwicklung von Informationssystemen konzentrieren wir uns auf eine Datenbanklösung. Deshalb hat der 

strukturelle Entwurf einen höheren Stellenwert als der funktionale Entwurf. Die Unterscheidung der Daten aus dem 

funktionalen Entwurf behalten wir jedoch bei. 

4.1.6 Spezifikation auf unterschiedlichen Abstraktionsschichten 

Produktdatenskizzen auf der strategischen Schicht 

Produktdaten als Grundkonstrukt. 

Sichten auf der Anforderungsschicht 

Ontologische Einheiten als Grundkonstrukt.


Sichten auf der Benutzungsschicht 

Kerntypen als Grundkonstrukt. 

Sichten als konzeptionelle Wiederspegelung 

Sichtentypen als Grundkonstrukt. 

HERM-Sichten als kombinierte Sichten 

Sichten auf der Implementationssschicht 

Charakterisierung und Klassifikation von Sichten (je nach Prozeßzustand) 

Sichten im Abstraktionsschichtenmodell. 

Wir können, wie in Bild 8 dargestellt, auch für die Sichtenspezifikation das Abstraktionsschichtenmodell verwenden. 

Da die Sichten aber eine Hilfskonstruktion sind und in engem Zusammenhang zum Schema und zu den Dialogen 

stehen, ist eine isolierte Modellierung der Sichten nicht sinnvoll. Im einzelnen verwenden wir die folgenden Schritte: 

Sichten des Lastenhefts: Mit der strategischen Informationsanalyse erhalten wir Informationen zu den unterschiedlichen 

Ansichten der Akteure zur Datenbank. Diese Ansichten können im Nachgang zum Struktur-, Funktionsund 

Dialogentwurf zur Entwicklung einer Vorstellung zu den einzelnen Sichten genutzt werden. Es wird eine 

Produktdatenskizze mit einer Grobstrukturierung der Produktdaten entwickelt. Diese Produktdatenskizze 

ist mit der Konzeptlandkarte, dem Diskurs und der Produktfunktionalität abzugleichen. Zur Darstellung der 

Produktdaten wird ein allgemeines HERM-Diagramm mit den Haupttypen entwickelt. 

Sichten des Pflichtenhefts: Es wird eine Sichtenskizze entwickelt. Jede dieser Sichtenskizzen basiert auf Begriffen 

der Anwendung. Wir nennen die Darstellung dieser Begriffe ontologische Einheit. Ontologien dienen bereits in 

breitem Maße zur Darstellung der Realität. Für die Sichtenskizzen und die ontologischen Einheiten werden entsprechende 

Integritätsbedingungen angegeben. Die Verfeinerung des Lastenheftes findet durch Spezialisierung 

der Typen, Dekomposition, strukturelle Erweiterung, semantische Einschränkung, Separation von Aspekten 

und durch Instantiierung statt. Zusätzlich werden weitere Typen eingeführt. 

Die Sichtenskizze enthält die Spezifikation der Darstellung der wichtigen Typen und eine grobe Vorstellung 

über die Art der Benutzung der Sichten. Es wird wiederum der Zusammenhang zur Darstellung der Strukturierung 

und der Funktionalität im Pflichtenheft hergestellt. Alle Ereignisse des Handlungsrahmens werden durch 

entsprechende Teile der Sichtenskizze unterstützt. 

Auf der Grundlage des Zusammenhangs zu verschiedenen Elementen der Story werden auch Zusammenhänge 

zwischen den einzelnen Sichten erkannt. Wir spezifizieren die Zusammenhänge in einem Integrationsschema 

der Sichten. Die Kohäsion zwischen den Sichten ist ein wichtiger Hinweis für eine spätere Sichtenintegration. 

Damit wird eine Bereinigung von Integrationskonflikten später vereinfacht und algorithmisch beherrschbar. 

Aktionssichten-Suite: Eine Suite besteht aus einer Menge von Elementen, einem Integrations- bzw. Zusammenhangsschema 

zur Pflege des Zusammenhanges und Obligationen. Die Aktionssichten stellen die Strukturierung 

der Daten in einer Form dar, wie sie der Benutzer sehen wird. Dazu werden die Kerntypen dargestellt. Aus den 

Kerntypen können wir alle Sichtenskelette zusammenstellen. Damit werden durch die Sichtenskelette alle Typen 

repräsentiert, die für den Anwender eine Bedeutung haben. Die Typen stellen eine Verfeinerung der Typen 

des Pflichtenhefts dar oder sind neu eingeführt. Die Aktionssichten-Suite besteht aus den Sichtenskeletten mit 

den Kerntypen und aus dem weiterentwickelten Integrationsschema. 

Die Sichtenskelette werden in Übereinstimmung mit dem Storyboard und dem Anwendungsschema entwickelt. 

Eine Spezifikation der einzelnen Sicht kann eine vollständige Erfassung aller wesentlichen Typen mit einschließen, 

so daß dieser Entwurfsschritt analog zur Spezifikation des Anwendungsschemas geführt werden kann.


Falls ein Anwendungsschema vorliegt, dann sollte jede Sicht auch als Anfrage über dem Anwendungsschema 

formuliert werden. 

Durch die Informationen aus dem Storyboard und den Zusammenhangs der Sichten können Obligationen für 

den Entwurfsprozeß abgeleitet werden. Eine Bereinigung von Integrationskonflikten kann auf der Grundlage 

des Sichtenintegrationsschemas erfolgen. Deshalb wird dieses Schema weiter parallel verfeinert. 

Sichten-Suite: Die Sichten-Suite stellt auf der konzeptionellen Schicht eine Menge integrierter Sichtenschemata 

dar, die auch durch entsprechende Strukturen des ER-Schemas und durch Anfragemengen unterstützt wird. 

Die einzelnen Sichten werden nun im Detail entworfen. Für jeden Typ einer Sicht wird angegeben, ob dieser 

Typ aus der Sicht der Datenbank ein Inputtyp, ein Outputtyp oder ein Modifikationstyp ist. 

Auf der konzeptionellen Schicht werden die Typen für die Strukturierung durch ein detailliertes HERM- 

Diagramm angegeben. Diese Typen stellen eine Verfeinerung der Typen des Anwendungsschemas dar. Die 

Verfeinerungsbeziehung wird direkt zur Erzeugung der Sichten-Suite genutzt. Der Entwurf der Sichten kann 

nach den Entwurfsmethodiken des konzeptionellen Schemas angestrebt werden. 

Bei Bereinigung von Integrationskonflikten kann nun auch eine Sichtenintegration angestrebt werden. Da uns 

das Integrationsschema bekannt ist und dieses fortgeschrieben wurde, kann eine Integration durch Generalisierung, 

durch Verschmelzung und Kombination oder im Extremfall durch Kooperation der Sichten angestrebt 

werden. 

Die Sichten werden am Ende des konzeptionellen Entwurfes vollständig in das konzeptionelle ER-Schema und 

das Drehbuch eingebettet sein. 

Zusätzlich zu den entwickelten Sichten werden die Sicherungssichten und die DBMS-Interaktionssichten entwickelt. 

Logische Sichten-Suite: Die Sichten-Suite wird je nach gewählten Transformationsmodus für die Abbildung des 

ER-Schemas auf das logische Schema im Anschluß an die Transformation des ER-Schemas auf Sichtenkonzepte 

des DBMS bzw. der Plattform abgebildet. Dazu werden entsprechende Operationen, Programme oder 

Module der Datenbank-Maschine verwendet. 

Die Sichtenkonzepte werden je nach Funktionalität des DBMS als externe Sichten oder materialisierte Sichten 

in die Beschreibung der Struktur der Datenbank eingebettet. Aus den konzeptionellen Sichten kann durch 

Transformation die jeweilige logische bzw. bei einer Materialisierung die physische Sicht erzeugt werden. 

Relationale DBMS unterstützen oft nur typ-basierte Sichten. In diesem Fall wird für jeden Typ einer Sicht eine 

Sichtentypanfrage angegeben. Der Zusammenhang der Sichten wird mit einer integrierten Sichtenanfragemenge 

in der logischen Sichten-Suite gewährleistet. Werden semi-strukturierte Datenbank-Maschinen verwendet, 

dann kann auch eine Sicht z.B. durch eine DTD angegeben werden. Der Zusammenhang innerhalb einer Sicht 

wird dann durch XML-Dokumente direkt dargestellt. Unterschiedliche Sichtweisen auf ein XML-Dokument 

können durch entsprechende XSL-Regeln unterstützt werden. 

Wir können die einzelnen Schritte wie in Bild 8 darstellen.



Vorstudie 

Skizzierung 

Produktdatenskizze 

Lastenheft: Sichten 

Produktdaten 


Feinstudie 

Darstellung 

Sichtenskizze 

ontologische 

Einheit 



Entwurf 

Sichtenentwurf 

Sichtenskelette 

Pflichtenheft: Sichten 

Kerntyp 


Schicht 



Sichtenschemata 

Aktionssichten-Suite 

Typ 

Sichtentypanfrage 

Sichten-Suite 

Sichtenanfragemenge 

logische Sichten-Suite 

Abbildung 8: Die Arbeitsprodukte im Abstraktionsschichtenmodell für die Sichtenentwicklung


4.2 Von Sichten zu Content-Typen 

Sichten werden klassischerweise durch Anfragen über Datenbank-Schemata definiert. In diesem Fall benutzen wir 

als Rahmen: 

select Projektionsausdruck 

from Datenbank-Struktur 

where Auswahl-Bedingung 

group by Zusammenfassungsausdruck zu Gruppe 

having Auswahl unter den Gruppen 

order by Lexikographische Ordnung unter Teilstruktur 

Dieser Rahmen erlaubt die Definition einfacher Sichten, die auf einem Typ definiert sind. Damit ist jedoch eine 

konzeptionelle Darstellung zusammengehörender Objekte für die Ausgabe nicht möglich. Wir nutzen diesen Rahmen 

für die Definition der logischen Sichten. 

Im allgemeinen benötigen wir jedoch in Anwendungen komplexere Unterstützung: 

Spezifkation einer Sichten-Suite: Zur Begleitung der unterschiedlichen Arbeitsschritte sind auch unterschiedliche 

zusammenhängende Sichten zu definieren. 

Spezifikation einer Funktionalität für die Sichten-Suite: Es sollte möglich sein, eine Anwendung soweit wie möglich 

durch entsprechende Funktionen und Prozesse zu unterstützen. Dazu benötigt ein Benutzer eine Reihe von 

Funktionen. 

Spezifikation der Anpassung an den aktuellen oder potentiellen Benutzer: Jeder Akteur oder jeder aktuelle 

Benutzer sollte ggf. auch mit seiner Oberfläche arbeiten können, ggf. seine Daten auch für sich selbst modifizieren 

können und auch durch eine explizite Beschreibung der Präsentationsart eine Anpassung vornehmen 

können. 

Die aktuell verfügbare Datenbank-Technologie unterstützt diese Forderungen bereits in breitem Maße, wenn Sichten- 

Suite-Modifikation über stored procedures abefangen wird. Sichten-Suiten können auch durch (logische) Sichtenanfragemengen 

unterstützt werden. Die Funktionen sind mit einem allgemeinen Funktionsrahmen allgemein darstellbar 

und dann an die konkrete Sichten-Suite anpaßbar. Die XML-Technologie eignet sich besonders für unterschiedliche 

Arten des “Ausspielens”. Außerdem kann einem Benutzer auch ein Sitzungsobjekt zugeordnet werden, so daß entsprechende 

Einstellungen automatisch weitergeführt werden können. Sitzungsobjekte können direkt realisiert werden 

oder mit einem Verpackungsumschlag in das verpackte Content-Objekt integriert werden. Funktionen wie Markierungsfunktionen 

sind durch Sichten, die über materialisierten Sichten entstehen, darstellbar. Deshalb ist keine Neuentwicklung 

notwendig, sondern nur ein Spezifikationsrahmen zur Verfügung zu stellen. 

Der SQL-Rahmen kann aufgefaßt werden als: 

generate STRUKTUR 

from DATENBANK-STRUKTUR 

where AUSWAHLBEDINGUNG 

group by TEILSTRUKTUR 

having BEDINGUNG 

order by TEILSTRUKTUR 

Dieser Rahmen kann zu folgendem Rahmen verallgemeinert werden (wie bereits oben erläutert): 

IS ADD


generate MAPPING : VARS → AUSGABESTRUKTUR 

from DATENBANKTYPEN 

where AUSWAHLBEDINGUNG 

represent using ALLGEMEINER PRÄSENTATIONSSTIL 

& ABSTRAKTION (GRANULARITÄT, MASSEINHEIT, PRÄZISION) 

& ORDNUNGEN DER PRÄSENTATION 

& HIERARCHISCHE DARSTELLUNGEN 

& SICHTWEISEN 

& SEPARATION 

browsing definition BEDINGUNG 

& NAVIGATION 

functions SUCHFUNKTIONEN 

& EXPORTFUNKTIONEN 

& EINGABEFUNKTIONEN 

& SITZUNGSVERWALTUNG 

& MARKIERUNGSFUNKTIONEN 

Damit können wir für die Sichten-Suite in einem Vierschritt-Verfahren die Spezifikation erstellen. Das Resultat 

dieses Spezifikationsprozesses nennen wir Content-Typ. Eine Instanz eines Content-Typs nennen wir Content- 

Objekt. Eine Content-Klasse enthält demzufolge Content-Objekte des gleichen Content-Typs. Die Spezifikation 

eines Content-Typs erfolgt durch schrittweise Erweiterung. 

Wir unterscheiden drei Gesichtspunkte: 

Content-Objekte werden den Akteuren zur Verfügung gestellt. Sie enthalten die Spezifikation der Strukturierung 

der dem Akteur zur Verfügung gestellten Daten und die Darstellung der Funktionalität. 

Damit wird folgendes dargestellt: 

Daten innerhalb von Content-Objekten sind in eine Reihe von Kategorien klassifizierbar: 

Retrievaldaten, die aus einer Datenbank gewonnen werden und als Inputdaten für den ablaufenden Prozeß 

bzw. Dialogschritt dienen, 

Inputdaten des Akteurs, die ggf. auch als Insert- oder Update-Daten in Dialogschritten fungieren, 

Outputdaten, die in die Datenbank zurückgeschrieben werden, 

Displaydaten, die als Output während des Dialoges dargestellt werden, und 

Begleitdaten, die aus vorherigen Prozessen stammen und der Darstellung der Informationen während 

des Dialogschrittes dienen. 

Bei Prozessen, mit denen ein Akteur Handlungen und Aktionen mit dem Informationssystem ausführen 

kann, unterscheiden wir: 

Unterstützende Prozesse für die Aktionen und 

Manipulationsanforderungen an das Informationssystem, die zur Veränderung der Daten führen können. 

Wir fassen die Daten in Klassen zusammen. Ein Content-Typ spezifiziert eine solche Klasse und basiert auf 

einem Sichtenschema, das auch um die erforderliche Funktionalität angereichert wurde. 

Container werden benutzt, um die Sichten den Akteuren bereitzustellen. Sie umfassen auch Parameter zur Beschreibung 

des Benutzungskontextes, so daß mit einer Auslieferung des Containers an den aktuellen Benutzer eine 

Adaption erfolgen kann. 

Für die Beschreibung von Containern unterscheiden wir zwischen 

allgemeiner Containerfunktionalität mit der Beschreibung allgemeiner Container-Funktionen zur Ent- und 

Beladung und 

spezifischer Containerfunktionalität, die durch die Content-Objekte, mit denen ein Container beladen wurde, 

geprägt wird. 

IS ADD


Ein Beispiel eines Content-Typen. 

Als Beispiel für ein Content-Objekt betrachten wir einen Archivierungstyp. Dieser Typ soll in unserem Hauptbeispiel 

benutzt werden, um aus der Datenbank zur Stundenplanung heraus eine Datenbank zur Ablage der relevanten 

Informationen zu gehaltenen Vorlesungen integriert mit entstehen zu lassen. Diese Datenbank dient der Verwaltung 

von Studentendaten, insbesondere für Informationen zu den erworbenen Scheinen. Die Funktionalität dieser Sicht ist 

stark eingeschränkt. Es können unterschiedliche Präsentationstil-Optionen zur Laufzeit gewählt werden. 

Dieses Content-Objekt ist als Sicht über der Struktur in Bild ?? darstellbar. Die Archivsicht ist ein Ausschnitt 

der Daten. Die Daten, die nur für die Planung im laufenden oder kommenden Semester von Bedeutung sind, werden 

nicht archiviert. 

Mithilfe der archivierten Daten können zu einem späteren Zeitpunkt die Daten zu Lehrveranstaltungen eingesehen 

werden, die stattfanden und in denen Studenten entsprechende Leistungen erreicht haben. Lehrveranstaltungen, die 

stattfanden, in denen aber Studenten keine Abschlüsse erreichten, werden ebenfalls gespeichert. Sie sind jedoch für 

die Archivsicht nicht mehr von Interesse. 

Die Archivsicht wird über dem Schema in Bild ?? als allgemeiner, parametrischer Ausdruck 

Archiv(@SemesterBezeichnung) 

mit obigem Rahmen spezifiziert. Sie wird instantiiert mit 

Archiv(“SS01/02”) . 

Der erste Teil der Sichtendefinition lautet somit: 

generate t Person ↦→ Person , t Kurs ↦→ Kurs , t gehalteneLV ↦→ gehalteneLehrveranstaltung , 

t Studiengang ↦→ Studiengang , t Typus ↦→ Typus, t Professor ↦→ Professor 

from t Kurs := gehalteneLV [Kurs], 

t Person := gehalteneLV[geplanteLV[angeboteneLV[Verantwortlicher4LV:Person]]]), 

t Studiengang := ..., t Typus := ...,, t Professor := ..., 

t gehalteneLV := gehalteneLV[geplanteLV[ 

angeboteneLV[ Kurs, Studiengang, 

Dozent:Professor, 

Verantwortlicher4LV:Person], 

Typus]]) 

where Bezeichnung = @SemesterBezeichnung ; 

Sie ist mit einem Parameter Semester als materialisierte Read-Only-Sicht in Bild 9 dargestellt. Mit dieser Sicht 

ist eine Modifikation der Daten nicht mehr erlaubt. Sie kann nur als Anfragesicht verwendet werden. 

Bezeichnung = “SS01/02” 

Kurs 

retrieve 

❦ 

Semester 

Person 

slice/sort 

✻ 

✸ 

Verantwortlicher4LV 

retrieve 

✻ 

Studiengang 

retrieve 

{} 

✛ 

gehaltene 

Lehrveranstaltung 

retrieve 

Dozent 

✲ 


retrieve 

❄ 

Typus 

retrieve 

Abbildung 9: Content-Typen zur Archivsicht auf gehaltene Lehrveranstaltungen 

IS ADD


Darstellung von Sichtenschemata. 

Wir erweitern die Darstellung von ER-Schemata wie bereits z.T. in Bild 9 verwendet: 

Optionale Komponenten sind für Relationship-Typen von Sichten zugelassen. Sie werden mit einer gestrichelten 

Linie angegeben. 

Versteckte Komponenten sind in einer Sicht in der Definition vorhanden, werden aber nicht angezeigt. Sie werden 

mit einem gestrichelten Typ mit dem Auswahlprädikat dargestellt. 

Default-Werte werden für eine Sicht für die Generierung der Sicht benutzt. Sie können jedoch im Dialog durch 

andere Werte ersetzt werden. Es wird für einen Typ der Default-Wert mit der Identifikation des Typs angezeigt. 

Wir merken an, daß sich mit einer Sichtendefinition auch die Integritätsbedingungen für die Typen einer Sicht ändern 

können. 

Wir verwenden das Sichtenschema, um die Funktionalität der einzelnen Typen mit anzugeben. Damit wird ein 

schnellerer Überblick gegeben. 

4.2.1 Sichten-Suiten 

Es werden die Sichten als konzeptionelle Sichten in ihrem Zusammenhang, mit einer Erweiterung um ggf. andere 

Datenbestände, sowie um andere Datentypen wie z.B. den Basis-Datentyp URL, money und MAIL dargestellt. 

Ein Sichtenschema wird als ER-Schema dargestellt, in dem jedem Typ eine Anfrage über dem ER-Schema und 

den Typenerweiterungen zugeordnet wird. 

Ein Sichtenschema kann auch materialisiert abgelegt werden. Dazu ist anzugeben, auf welche Art eine Modifikation 

in der Datenbank sich auf die Sicht auswirkt. Diese Materialisierung nutzt dann das folgende Schema: 

extend Sichtenschema 

by MODIFIKATIONSMODUS 

store ABLAGE-SCHEMA 

Wir werden im weiteren diesen Spezifikationsrahmen erweitern um eine Steuerbedingung 

accept on ABSCHLUSSBEDINGUNG 

mit der eine Kontrolle der Integrität dynamisch erfolgen kann. Eine derartige Kontrolle verbessert die Übersichtlichkeit, 

erfordert aber eine rigidere Behandlung der Konsistenz aller Integritätsbedingungen. 

Für den Modifikationsmodus erstellen wir uns parametrische aktive Datenbank-Trigger. Diese parametrischen 

Trigger besitzen einen Namen, sind für Modifikationsoperationen über der Datenbank spezifiziert, können bei Gültigkeit 

einer Bedingung aktiviert werden und führen Aktionen zur Veränderung einer materialisierten Sicht aus. 

Der Modifikationsmodus besteht aus einem Modifikationsschema und einem Zeitschema. Das Modifikationsschema 

kann durch entsprechende Triggeroperationen in der logischen Sichten-Suite unterlegt werden in der Form 

on Modify on Datenbank-Schema-Typ 

if Sichten des Sichtenschemas XY betroffen 

do Modify XY 

Modify steht für Insert, Delete bzw. Update. 

Das Zeitschema diktiert, wann eine Modifikation der Sichten erfolgt. Default-Wert kann z.B. Immediate sein. 

Mitunter ist auch Aktionen DeferUntilNoUserActive sinnvoll. 

Das Ablage-Schema kann sowohl eine einzelne URL bzw. URI als auch eine Menge zulassen, falls eine redundante 

Speicherung erforderlich ist. 

Für die Archivsicht erhalten wir mit Darstellung durch den deontischen Operator F (Verboten): 

extend Archivsicht 

by MODIFIKATION = { F Insert, F Delete, F Update } 

store ARCHIVSICHT 

IS ADD


Weiterhin wird ein Sichtenschema durch die Angabe aufbereitet, ob die Objekte dieser Sicht nur Daten sind, die 

dem Benutzer zu Ansicht zur Verfügung (Retrievaldaten) stehen oder auch zur Modifikation (Modifikationsdaten) 

benutzbar sind. 

Objekte einer Bearbeitung mit Sichten enthalten in der obigen Klassifikation demzufolge: 

• Input-Daten, die dem Benutzer in den einzelnen Arbeitsschritten zur Verfügung gestellt werden, 

• Output-Daten, mit denen der Benutzer auch Daten wieder in das System zurückschreiben oder einschreiben 

kann, und 

• Begleit-Daten, die der Benutzer einsehen, aber nicht modifizieren kann. 

Außerdem können Objekte einer Sicht sichtbar sein (Displaydaten) oder auch nicht dem Akteur sichtbar gemacht 

werden. Insbesondere wollen wir damit die direkte Modifikation der Objekte der Datenbank unterstützen, ohne dem 

Benutzer auch die Identifikation der Daten bekannt zu machen. 

Damit ist das Sichtenschema um die Angabe 

type 

.... for modification 

for retrieval 

used for input 

for output 

for escort only 

displayed with subtype 

erweitert. 

Um die Identifizierbarkeit zu gewährleisten, verwenden wir dabei evt. auch Typen, die dem Benutzer nicht angegeben 

werden. Weiterhin können diese allgemeineren Typen auch für die Spezifikation der Funktionen verwendet werden. 

4.2.2 Anreicherung der Sichtenschemata um Funktionen 

Eine Funktion ist allgemein mit einem Definitionsrahmen der folgenden Form spezifiziert: 

Signatur der Funktion: Name, Input-Parameter, Output-Parameter 

Basiert auf Sichtenschema 

Deklaration der Funktion 

Dieser Definitionsrahmen kann für jede Art von Funktionsdefinition verwendet werden. In vereinfachter Form kann 

auch der folgende Definitionsrahmen verwendet werden: 

extend Sichtenname 

by functions KATEGORIE DER FUNKTIONEN 

Name der Funktion (Input-Parameter, Output-Parameter) 

Deklaration der Funktion 

In diesem Fall wird die Erweiterung der Sichtendefinition hinzugefügt. 

Wir benötigen in internet-basierten Anwendungen eine ganze Reihe unterschiedlicher Funktionen, die wir wie 

folgt klassifizieren können: 

Durchmusterungsfunktionen erlauben die Erschließung von größeren Datenmengen ohne Verlust der Orientierung. 

Dazu gehören: 

Suchfunktionen, mit denen die Sichten und deren Objekte durchsucht werden können, 

Generalisierungs- und Spezialisierungsfunktionen (zooming-out, zooming-in), mit denen eine Menge von 

Objekten zu einer abstrakten Menge zusammengefaßt sowie diese Zusammenfassungen wieder aufgehoben 


Umordnungsfunktionen, mit denen eine Menge von Objekten auch in einer anderen Ordnung dargestellt 

werden kann, 

IS ADD


Navigationsfunktionen, (browsing, zapping, n-by-n, object-by-object) mit denen Objektmengen schrittweise, 

bündelweise, im Schnelldurchgang oder auch mit einem Browser durchmustert werden können, 

Kontexterschließungsfunktionen, mit denen die assoziierten Objekte zu einer Objektmenge erfaßt und dann 

mit den Objekten der Objektmenge verbunden werden können, 

Überblicksfunktionen, die anhand von Klassifikationskriterien die Erstellung einer ‘Datenlandkarte’ unterstützen, 

und 

Assoziationsfunktionen, mit denen Objekte aufgrund von Assoziationsbeziehungen schrittweise zu komplexeren 

Objekten umgeformt werden können. 

In der Archivsicht können wir folgende Funktionen einführen: 


by functions SUCHFUNKTIONEN 

Lehrveranstaltungsübersicht ((Von, Bis, Kurs.Name), 

(Verantwortliche, Semester.Bezeichnung) ) 

stored procedure := ... 

Lehrveranstaltungen der Architektur ((), (Kurs.Name) ) 

stored procedure := ... 

by functions NAVIGATIONSFUNKTIONEN 

Semesterübersicht ((Semester.Bezeichnung), ) 

browse by Studiengang, Typus 

by functions ASSOZIATIONSFUNKTIONEN 

Vorlesungsprofil ((Professor.Name),(LV-Übersicht) ) 

view defined as ... 

Die Suchfunktionen sollen eine vereinfachte Suche unterstützen. Die Navigationsfunktionen werden für eine 

begleitende Navigation für die Oberflächen der Benutzer erstellt. Die Assoziationsfunktion erlaubt die Erstellung 

eines Profils mit einer neuen Sicht. 

Bearbeitungsfunktionen ermöglichen die Bearbeitung von Daten aus der Datenbank, von Sichtendaten und von 

persönlichen Daten der Benutzer. 

Datenbank-Modifikationsoperationen erlauben dem Akteur, seine Daten in die Datenbank einzubringen, in 

der Datenbank Informationen zum Arbeitsverlauf vorzuhalten und Daten aus Sichten nach ihrer Bearbeitung 

durch den Benutzer in die Datenbank zurückzuspeichern. 

Sichten-Objekt-Modifikationsoperationen ermöglichen eine (temporäre) Veränderung der Daten in den Sichten. 

Diese Daten können materialisiert oder mit dem Erlöschen der Sicht auch gelöscht werden. 

Bearbeitungsfunktionen für den eigenen Arbeitsplatz unterstützen die Bearbeitung von Containern zu Sitzungen, 

die temporäre Haltung von Daten, das Einlagern, Modifizieren und Streichen von eigenen Daten. 

Integrationsfunktionen erlauben dem Benutzer, aus dem Dialogverlauf heraus für sich Daten zu entnehmen bzw. 

einzubringen. 

Exportfunktionen sollen eine ganze Reihe von Funktionen unterstützen: 

Ausgabe in Druck-Dokumente: Eine Druckausgabefunktion erlaubt die Ausgabe in vorgegebener Form z.B. 

als Formatting Object. Damit wird einem Benutzer nicht nur der Inhalt seiner Sitzung oder seiner Arbeitssichten 

bereitgestellt, sondern es werden auch die Daten des Content-Objektes für eine Ausgabe 

aufbereitet. 

Integration in andere Dokumente: Mitunter sind die Auswahl von Daten, die erarbeiteten Daten oder Sichten 

auf das Content-Objekt auch in andere Objekte integrierbar. In unserem Hauptbeispiel sollte z.B. die 

Übernahme von Kursbeschreibungen möglich sein. 

IS ADD


Integration in den eigenen Arbeitsraum: Es können Sichten auf das Content-Objekt und die Sitzung in den 

eigenen Arbeitsraum des Benutzers eingelagert werden. 

Weitergabe von bearbeiteten Objekten an andere Akteure: Eine Weitergabefunktion von Arbeitsresultaten 

kann in analoger Form wie die Druckfunktion realisiert sein. 

In analoger Form können auch Importfunktionen bereitgestellt werden. Sie unterstützen den Akteur in den 

entsprechenden Dialogschritten und basieren auf folgenden Funktionen: 

Übernahme von Objekten in die Datenbank: Eine Eingabe sollte nicht nur textuell erfolgen, sondern durch 

Funktionen zur Übernahme von Dokumenten oder Mengen von Objekten unterstützt werden. Dazu werden 

Techniken der Sichten-Kooperation genutzt. 

Integration in das Content-Objekt: Das Content-Objekt kann Parameter haben, die durch eine Eingabe von 

Daten oder Objekten instantiiert werden können. Damit ist auch eine Erweiterung des aktuellen Content- 

Objektes der aktuellen Sitzung möglich. 

Integration in den eigenen Arbeitsraum: Es können in vorher vereinbarten Formaten durch entsprechende 

Importfunktionen auch entsprechende Content-Objekte des Benutzers benutzt und in den Arbeitsraum 

eingebracht werden. 

Integration in die Arbeitssichten: Den Parametern aktueller Arbeitssichten können auch entsprechende Content- 

Objekte zugewiesen werden, so daß mit einer Importfunktion auch das aktuelle Content-Objekt verändert 

wird. 

Sowohl Import- als auch Exportfunktionen können auf der sogenannten Wrapper-Technologie aufsetzen. Wir 

verwenden zur einfacheren Integration die unten dargestellten Mechanismen der Sichtenkooperation. 

In unserer Anwendung kann z.B. die Archivsicht um Funktionen zum Druck wie folgt erweitert werden: 


by functions EXPORTFUNKTIONEN 

ProfilübersichtPDF ((Professor.Name), (Dokument)) 

... Vorlesungsprofil ((Professor.Name),(LV-Übersicht) ) ... 

Markierungsfunktionen erlauben dem Benutzer mit den dargestellten Daten so umzugehen wie mit Daten auf seinem 

Schreibtisch. Es kann dem Akteur eine sehr breite Palette zur Verfügung gestellt werden. Oft verwendet 

werden Funktionen wie 

Kopierfunktionen zum Kopieren von Daten in den eigenen Arbeitsraum, 

Färbungsfunktionen zum Markieren von Daten mit unterschiedlichen Beschriftungen wie z.B. Farben, 

Beschriftungsfunktionen zur Annotation, zum Einbringen von Kommentaren und zum Anbringen von Variationen. 

Markierungsfunktionen können durch einen benutzereigenen Container unterstützt werden. Container werden 

auf Seite 463 eingeführt. 

Funktionen zur Sitzungsverwaltung erlauben einem Benutzer auch die Wiederaufnahme der Arbeit an der entsprechenden 

Stelle. Jedem Benutzer wird in seinem Arbeitsraum auch ein Sitzung-Container zur Verfügung 

gestellt. In diesem Container werden die Sitzungen mitprotokolliert. Damit ist dann auch eine Weiterführung 

eines bereits partiell durchlaufenen Workflows möglich. Funktionen der Sitzungsverwaltung sind insbesondere: 

Funktionen zum Öffnen, Protokollieren und Schließen von Sitzungen, mit denen ein Arbeitsstand gespeichert 

werden kann, die Erhaltung persönlicher Daten gewährleistet wird, mit denen Nebensitzungen und 

Gruppensitzungen unterstützt werden, 

Absicherungsfunktionen zur Absicherung der Sitzungsinformation und der Workspace-Information vor unberechtigtem 

Zugriff oder unberechtigter Modifikation, 

IS ADD


Weitergabefunktionen, mit denen Sitzungsinformationen an andere Benutzer oder Funktionen weitergegeben 

bzw. andere Benutzer kontaktiert werden können, und 

Löschfunktionen, mit denen ältere Sitzungen gelöscht werden können. 

Eine einfache Form der Sitzungsverwaltung stellen Cookies dar. 

Neben diesen Funktionen können auch Funktionen für Gruppensitzungen zur Verfügung gestellt werden. Diese 

Funktionen unterstützen eine effiziente Arbeit von Gruppen wie z.B. Gremien, Versammlungen, Veranstaltungen, 

etc. durch eine Reihe von Funktionen wie: 

Funktionen zur Darstellung der Arbeit der Gruppen mit variabler Sichtbarkeit der Tagesordnungen, Dokumente 

und Nachrichten je nach Freigabe, 

Funktionen zur Veröffentlichung von Materialien und Dokumenten mit unterschiedlicher Sichtbarkeit und 

unterschiedlichem Recht auf Einsicht, 

Funktionen zur Unterstützung der Zusammenarbeit von Mitgliedern der Gruppe untereinander bzw. mit 

den interessierten Akteuren und 

Funktionen zur Archivierung der Materialien mit unterschiedlicher Einsicht in die Dokumente je nach Rechten 

und je nach Freigabestatus. 

Diese Funktionsmenge ist bereits in einer Reihe von Anwendungen in generischer Form entwickelt worden. So kann 

z.B. Das CPAN-Verzeichnis zu Perl-Anwendungen auch zur schnellen Entwicklung der erforderlichen Funktionalität 

für Sichten-Suiten herangezogen werden. 

IS ADD


4.2.3 Parametrisierte Anpassung an den Akteur 

Um Benutzern in ihren Rollen entgegenzukommen, sollen Content-Objekte in gewissem Maße an folgende Dinge 

adaptierbar sein: 

• an den Benutzer, insbesondere an das Benutzerprofil, die Sprache, seine Kenntnisse und Fertigkeiten, seine 

Präferenzen, 

• an das Benutzungsportfolio, d.h. die Arbeitsaufgaben des Benutzers, 

• an die Arbeitsumgebung des Benutzers, insbesondere die technische Infrastruktur wie Hard- und Software der 

Arbeitsplatzrechner, die Kommunikationsinfrastruktur und 

• die Benutzungsgeschichte. 

Eine solche Anpassung ist nicht im allgemeinen Maße möglich. Ein Sichtenschema ist jedoch parametrisierbar und 

im Rahmen dieser Parametrisierung an den konkreten Kontext adaptierbar. 

Dazu erweitern wir die Spezifikation der Content-Typen: 

Anwendbare Abstraktionen innerhalb des Sichtenschemas: Zur Unterstützung der Suche und der Navigation 

innerhalb des Content-Objektes kann man das Wissen zu den verwendeten Datentypen einbringen. Jeder Basis- 

Datentyp kann auch in vergröberter Form dargestellt werden. Diese Vergröberung vererbt sich über das Konstruktionsschema 

bis hin zum Sichtenschema. Damit sind wir in der Lage, 

• die Granularität, 

• die verwendeten Maßeinheiten und 

• die Präzision der Darstellung 

anzupassen. Diese Anpassung wird in Spreadsheet-Zugängen bereits breit praktiziert und ist relativ einfach mit 

dem Content-Typ verbindbar. 

Präsentationsstil: Der Datentyp des Sichtenschemas ist durch die verwendeten Datentypen gegeben. Wir können 

damit für einen allgemeinen Datentyp eine Menge von Präsentationsformaten entwickeln und mit dem Content- 

Objekt verknüpfen. 

Allgemeiner Repräsentationsstil: Im Rahmen der Entwicklungen zu Benutzungsschnittstellen sind allgemeine 

Gestaltungsraster für die Präsentation entwickelt worden. Dazu gehört das Screen-Layout, die 

Typographie, die Integration von Metaphern in die Gestaltung nach allgemeinen Prinzipien: 

• Das Prinzip der visuellen Wahrnehmung orientiert sich an Ordnungsbeziehungen innerhalb des Content- 

Typen, an Wirkungen der Darstellung und Hilfsmitteln zur Visualisierung. 

• Das Prinzip der visuellen Kommunikation orientiert auf eine klare, konsistente Struktur mit einer 

minimalen Menge von Hilfsmitteln unter Berücksichtigung der Aufnahmefähigkeit des Akteurs. 

Es werden dabei die Gestaltungsgesetze das Bildschirms und der visuellen Gestaltung auf die Darstellung 

der Content-Typen erweitert. 

Der allgemeine Repräsentationsstil wird durch style sheets unterstützt. Darin werden nicht nur die Typographie 

und Farbkodierung festgelegt, sondern auch die genutzten Metaphern und Darstellungselemente. 

Diese können parametrisiert werden. Damit kann zur Laufzeit eine Adaption an den Benutzer erfolgen. 

Inhaltsbasierter Repräsentationsstil: Durch die Konstruktion des Sichtenschemas können wir auch die Sichtendefinition 

und die Funktionalität des DBMS direkt nutzen, um unterschiedliche Darstellungsformen 

des gleichen Content-Objektes zu ermöglichen. Wir unterscheiden eine Reihe von Zugängen: 

Zuordnung einer Menge von Sichten zum Content-Typ: Jedes Objekt kann auf unterschiedliche Art 

und Weise betrachtet werden. Die unterschiedlichen Gesichtspunkte auf das gleiche Objekt erlauben 

auch einen schnelleren und situationsbezogenen Überblick über das gleiche Content-Objekt. Das 

Web IS


gleiche Objekt wird aus unterschiedlichen Sichtweisen dargestellt. Diese Sichtweisen werden durch 

Sichten, d.h. Ausdrücke der HERM-Algebra dargestellt. 

Dieser Zugang wird in XML-Ausspielsystemen bereits praktiziert durch die Angabe von XSL-Regeln, 

die dann ein variables Darstellen des gleichen XML-Dokumentes erlauben. 

Hierarchische Strukturierung als Darstellungshilfsmittel: Eine besondere Präsentationsform ist die 

hierarchische Darstellungsform. Wir können hierarchische Darstellungsformen einführen 

• durch Verallgemeinerung von Zugängen, die für OLAP-Systeme entwickelt worden, 

• durch Nutzung der Hierarchien, die bereits mit einer Assoziierung, wie z.B. Verweisen gegeben 

ist und 

• durch Auflösung geschachtelter Strukturen. 

Die Auflösung geschachtelter Strukturen ist bereits für die HERM-Algebra eingeführt worden. 

Einführung von parametrischen Ordnungen: Bereits für die Durchmusterung und die Suche in größeren 

Content-Objekten ist eine Unterstützung durch entsprechende Funktionen entwickelt worden. 

Wir können diese Funktionen nutzen, um eine Ordnungserweiterung des Content-Typen vorzunehmen: 

• Es werden die Ordnungsrelationen ord ≤ , die für Listen und Mengen bekannt sind, genutzt. 

• Es werden Mengen durch Listen ersetzt und damit einfach sequentiell durchmusterbar. 

Die Ordnungsrelationen sind von unterschiedlicher Gewichtung. Einige Eigenschaften charakterisieren 

ein Objekt stärker als andere. Deshalb können wir die Gewichtung auch für die Ordnung der 

Eigenschaften nutzen. 

Das Ordnungsschema erlaubt eine Parametrisierung. Diese Parameter können zur Laufzeit durch 

entsprechende Ordnungen ersetzt werden. Dabei können auch bestimmte Ordnungen per Default 

zur Anwendung kommen. In unserer Vorlesungsanwendung können z.B. Lehrveranstaltungen nach 

Vorlesungssemestern, Studiengängen und Studienabschniten in dieser Reihenfolge geordnet werden. 

Angabe von Dekompositionen bzw. Separationen des Content-Typen: Wir können den inneren Zusammenhang 

eines Content-Typen, der durch sein Sichtenschema gegeben ist, direkt verwenden. Ein 

Sichtenschema erlaubt eine Reihe von Sichtweisen auf die Daten. Diese Sichtweisen können als Sichten 

dem Sichtenschema zugeordnet werden. Welche Sichtweise auf das Content-Objekt durch den 

Benutzer gewählt wird, kann dann sogar zur Laufzeit entschieden werden. Da nicht alle Typen des 

Sichtenschemas in der gleichen Form miteinander assoziiert sind, kann die Stärke der Assoziierung 

direkt mit den Typen verbunden werden. 

Wir nutzen dafür eine Adhäsionsmatrix, die zwischen den Typen des Sichtenschemas definiert ist. 

• Es sei types(S) die Menge aller Typen des Sichtenschemas S. Eine Adhäsionsmatrix AM ordnet 

jedem Paar von Typen T, T ′ ∈ S eine natürliche Zahl oder 0 zur Darstellung des Abstandes 

zwischen den Typen in S zu. 

Die Adhäsion ist umso niedriger, um so enger die Typen zusammengehören. Wir nehmen an, 

daß AM(T, T ) = 0 für jeden Typen T von types(S) gilt. 

• Die Zuordnung muß nicht vollständig für Teiltypen eines Typen T angegeben sein. Ist AM(T 1 , T 2 ) 

nicht definiert, dann nehmen wir als Adhäsion den Abstand in der Typendefinition der Typen des 

Schemas an. Ist ein Schema nicht zusammenhängend und ist keine Adhäsion unter den Elementen 

der nicht zusammenhängenden Teilschemata definiert, dann nehmen wir AM(T 1 , T 2 ) = ∞ 

an. 

• Eine Adhäsionsmatrix ist konservativ, falls AM(T 1 , T 2 ) ≤ M(T ′ 1 , T ′ 2 ) für Typen T 1, T 2 von 

types(S) und Teiltypen T ′ 1 , T ′ 2 von jeweils T 1, T 2 . 

• Eine Adhäsionsmatrix muß nicht symmetrisch sein. Teiltypen T 1 , T 2 eines Typen T können dem 

Typen T unterschiedlich nahe stehen. 

Durch eine Adhäsionsmatrix können wir für jeden Typen T von types(S) Schalen definieren durch 

Shell(T, types(S), i) = { T ′ ∈ types(S) | AM(T, T ′ ) ≤ i } 

Web IS


Die Schalen erlauben eine automatische Separation, insbesondere im Falle eines nicht ausreichenden 

Darstellungsraumes auf dem Bildschirm. Mit der Adhäsionsmatrix wird dargestellt, welche Typen 

und Teiltypen gemeinsam auf dem Bildschirm erscheinen müssen und welche nicht unbedingt im 

Zusammenhang mit einem Typ dargestellt werden müssen. 

Wir können die Schalen und deren Beziehungen als Hypergraphen wie in Bild 10 darstellen. Ein 

Hypergraph besteht aus Knoten V und Hyperkanten H ⊆ 2 V . In unserem Modell sind die 

Hyperkanten hierarchisch. Es existiert eine lexikographische Nummerierung E 1,i1 ,...,i k 

der Kanten 

in H, so daß E i 

⊆ E j 

genau dann gilt, wenn i der Beginn von j ist. Die Wurzel ist der Knoten E 1 . 

Eine andere Darstellung kann auch analog zu Bild ?? mit dem erweiterten ER-Modell angegeben 

werden, indem die Rauten als Relationship-Typen-Folge an der jeweils darunterliegenden Schale angehängt 

werden. In diesem Fall wird ein Stern-Schema erzeugt. Meist wird jedoch eine vollständige 

hierarchische Strukturierung nicht möglich sein. Dann erhalten wir ein Schneeflocken-Schema. 

Ein Beispiel einer Adhäsionsmatrix für das Schema in Bild 9 ist mit folgender Matrix gegeben: 

Archivsicht T 1 T 2 T 3 T 4 T 5 T 6 T 7 T 8 

T 1 = Verantwortlicher 0 2 0 4 4 2 5 11 

T 2 = Professor 1 0 1 4 6 4 4 7 

T 3 = gehaltene Lehrveranstaltung 2 1 0 2 4 1 3 5 

T 4 = Semester 5 4 2 0 1 3 6 9 

T 5 = Bezeichnung 6 6 4 1 0 4 7 10 

T 6 = Kurs 4 3 0 3 3 0 2 5 

T 7 = Studiengang 5 3 2 5 7 2 0 11 

T 8 = Typus 6 2 1 7 9 1 3 0 

Eine Adhäsionsmatrix kann auch per Default besetzt werden. Wir verwenden dazu den Abstand in 

der Typen-Definition. Die Beispielmatrix erlaubt z.B. eine Separation der Typen in Bild 9 für den 

Typ Kurs in die Schalen 

Kurs, gehaltene Lehrveranstaltung 

Kurs, gehaltene Lehrveranstaltung, Studiengang 

Kurs, gehaltene Lehrveranstaltung, Studiengang, Professor 

Kurs, gehaltene Lehrveranstaltung, Studiengang, Professor, Semester, Bezeichnung, Verantwortlicher und 

die gesamte Sicht. 

Die Schalen können auch noch gegenseitig durch die Adhäsion der hinzukommenden Typen der 

nächsten Schale separiert werden. Dadurch können wir sogar eine hierarchische Charakterisierung 

vornehmen. In den seltensten Fällen wird jedoch eine solche Detailliertheit benötigt. Im Beispiel in 

Bild 10 kann die vierte Schale z.B. in die Personenangaben, die Angabe der Verantwortlichkeit und 

die Semesterangaben separiert werden. 

Verantwortlicher 

Semester 

Bezeichnung 

Kurs, 

gehaltene 

Lehrver 

anstaltung 

Studiengang 


Typus 

Abbildung 10: Hierarchische Schalen des Typen Kurs in der Archivsicht 

Bsp. eLearning: Adaptivität in vier Dimensionen. 

Vielfalt bei gut aufbereiteten Inhalten 

• Adaptivität an den Lernstil 

• Welcher Informationstyp wird durch den Lerner bevorzugt 

• formaler Typ (konkret, praxis-motiviert, Fakten, Algorithmen) 

consumption logistics 

Web IS


• intuitiver Typ (konzeptionell, innovativ, Theorien und Bedeutung) 

• Welche Informationsaufnahme hat der Lerner 

• visueller Typ (multimedial gestützt, Diagramme, Bilder) 

• verbaler Typ (geschrieben oder gesprochen) 

• Welche Informationsorganisation erscheint sinnvoll 

• induktiver Lerner (vom speziellen zum generellen) 

· Beispielorientierter Typ (erst am Beispiel) 

• deduktiver Lerner (vom allgemeinen zum speziellen) 

• Wie wird durch eine Informationsmenge gegangen 

• aktiver Typ (im Selbstversuch, in Kooperation) 

• reflektiver Typ (durchdenken, möglichst allein) 

• Wie wird gelernt und verstanden 

• sequentieller Lerner (liniear geordnet, in kleinen inkrementellen Schritten) 

• globaler Lerner (erst das allgemeine Bild, als System, Lernen in Makroschritten) 

Cottbuser Seminar-Experiment: 

Drei Kapitel aus dem Buch Computational Learning“ 

• Tina Kunterbunt: intuitiv, visuell, beispiel-orientiert, aktiv, global 

• Alf Naseweis: formal, verbal, deduktiv, passiv, sequentiell 

• Joe Hacker: intuitiv, verbal, induktiv, aktiv, sequentiell 

Bsp. eLearning: Generierung und Adaption. 

• Lerneinheit: e 1 ; ((e 2,1 ||e 2,2 ) |×| e 2,3 ) ; e 3 ; (e 5,1 || (e 5,2 ; e 5,3 )) 

• Voraussetzung: e 1 ; ((e 2,1 ||e 2,2 ) |×| e 2,3 ) ; e 9 ; e 3 ; (e 10 ||e 11 ) ; (e 5,1 || (e 5,2 ; e 5,3 )) 

• förderndes Vorwissen: e 16 ; [ e 17 ; ] e 1 ; ((e 2,1 ||e 2,2 ) |× 

| e 2,3 ) ; e 9 ; e 3 ; (e 10 ||e 11 ) ; (e 5,1 || (e 5,2 ; e 5,3 )) 

• Link-Verbindungen: e 16 ; [ e 17 ; ] e 1 ; ((e 2,1 ||e 2,2 ) |×| e 2,3 ) ; 

[(↗ e 17 ; e 18 ↘; )] e 9 ; e 3 ; (e 10 ||e 11 ) ; (e 5,1 || (e 5,2 ; e 5,3 )) 

• verfügbare Lernelemente: e 16 ; [ e 17 ; ] e 1 ; ((e 2,1 ||( SB 

e 2,2 || CB 

e 2,2 )) |×| e 2,3 ) ; 

[(↗ e 17 ; e 18 ↘; )] e 9 ; e 3 ; (e 10 ||e 11 ) ; (e 5,1 || (e 5,2 ; e 5,3 )) 

• Lernerprofil: e 16 ; [ e 17 ; ] e 1 ; ((e 2,1 ||( SB 

e 2,2 || CB 

e 2,2 )) |×| e 2,3 ) ; 

[(↗ e 17 ; e 18 ↘; )] e 9 ; Gr e 3,1 ; An e 3,2 ; Inf e 3,3 ; F orm e 3 ; (e 10 ||e 11 ) ; (e 5,1 || (e 5,2 ; e 5,3 )) 

• Payment-Profil: e 16 ; [ e 17 ; ] e 1 ; (⊗ SB 

e 2,2 ⊗ |×| e 2,3 ) ; 

[(↗ e 17 ; e 18 ↘; )] e 9 ; Gr e 3,1 ; An e 3,2 ; Inf e 3,3 ; F orm e 3 ; (e 10 ||e 11 ) ; (⊗ e 5,2 ; e 5,3 ) 

• Lernhistorie - erledigte Elemente und Repetitor: 

; )] e Repe 

9 ; Gr e 3,1 ; An e 3,2 ; Inf e 3,3 ; F orm e 3 ; (e 10 ||e 11 ) ; (e 5,2 ; e 5,3 ) 

e Repe 

1 ; [(↗ e 17 ; e 18 ↘ 

• Lernhistorie - Zusatzübung: 

e Repe 

1 ; e 25 ; [(↗ e 17 ; e 18 ↘; )] 

e Repe 

9 ; Gr e 3,1 ; An e 3,2 ; Inf e 3,3 ; F orm e 3 ; (e 10 ||e 11 ) ; (e 5,2 ; e 5,3 ) 

• Lernhistorie - Praktikum: 

1 ; e 25 ; [(↗ e 17 ; e 18 ↘; )] 

e Repe 

9 ; Gr e 3,1 ; An e 3,2 ; Inf e 3,3 ; F orm e 3 ; (e 10 ||e 11 ) ; (e 5,2 ; e P 5,2 rak ; e 5,3 ) 

Aufbereitung / Vorbereitung von Inhalten. 

Grunddaten nur einmal - Benutzungsdaten in aller Vielfalt 

Multi-Ebenen-Zugang: Grunddaten, Sichtentürme über den Grunddaten mit Assoziation der Sichten zu den Rollen 

der Benutzer 

e Repe 

Versionierung: Inhalte in unterschiedlichen Versionen zur Rückverfolgbarkeit von Historie 

Adaption von Inhalten: Adaption an den Benutzer, seine Arbeitsumgebung, an die Vernetzung der Inhalte und an 

die derzeitige Arbeitslast der Systeme 

Web IS


Farmen von Inhalten: Zulassen von heterogenen Inhalten in heterogener Qualität 

Meta-Daten von Inhalten (ggf. auch in der Erstellungsphase automatisch hinzugefügt) 

Wissenskarten u.a. Orientierungshilfe für die schnelle Erschließung des Datenbestandes 

Ausspiel. 

Jedem seine Information je nach Bedarf, Vorhandensein, Umgebung und Art 

• Weg vom “pull content” hin zu intelligenter Inhaltepräsentation je nach speziellem Profil und Portfolio des 

Benutzers 

• Aufbereitete Inhalte für unterschiedliche Arten der Benutzung 

• Portfolio: Aufgaben deren Dringlichkeit und Ordnung, 

Umfang und Qualität der Antworten 

• Profile von Benutzern in den drei Facetten: Ausbildung, Arbeit, Persönlichkeit 

damit auch allgemeines Verhalten, allgemeine Erwartung und Fähigkeit der Benutzer eingrenzbar 

• Wellenfrontartige Freischaltung, elementarwellenartige Ergänzung von Inhalten je nach Rollen der Benutzer 

• Qualitäts- und Meta-Information zusammen mit den Inhalten 

4.2.4 Container-Objekte für Web-Informationssysteme 

Abstrakte und Verpackungsumschläge von Content-Objekten. 

Content-Objekte sind Objekte eines Content-Typs, die an den Akteur ausgeliefert werden und ihm zur Verfügung 

stehen. Ein Content-Objekt kann relativ groß werden. Deshalb kann ein Content-Objekt mit einer Beschreibung versehen 

werden, die über den Inhalt Auskunft gibt. Diese Beschreibung wird mit einer Extraktionsfunktion gewonnen. 

Abstrakte dienen als verallgemeinerte Indizes und erlauben eine Vorausschau auf das Content-Objekt. Der Name 

des Content-Objektes wird um den Abstrakt erweitert. Abstrakte umfassen: 

die Titel-Information nach einem Benennungsschema, mit einer Kurz-Identifikation, 

eine Kurzbeschreibung des Inhaltes des Content-Objektes, 

die Zusammenfassung des Inhaltes des Content-Objektes, die durch Anwendung entsprechender Extraktionsfunktionen 

des Content-Typen aus dem Content-Objekt gewonnen werden können, 

allgemeine Beschreibungen des Inhaltes und der Strukturierung der Content-Objekte, einschließlich der Variablen, 

weitere Informationen z.B. zu den Autoren und zu Klassifikation für das Content-Objekte, 

Angaben zur Funktionalität des Content-Objektes, d.h. 

• zu Durchmusterungsfunktionen, 

• zu Integrationsfunktionen, 

• zu Markierungsfunktionen und 

• zu Funktionen zur Sitzungsverwaltung, 

Prozeduren und Programmme zur Anpassung des Content-Objektes an den aktuellen Benutzer, d.h. 

• zur Anwendung von Abstraktionen, 

Web IS


• zur Anpassung des allgemeinen Repräsentationsstils und 

• zur Anpassung an den inhaltsbasierten Repräsentationsstil. 

Ein Content-Objekt wird 

• ggf. von einem Akteur mehrfach benutzt, 

• ggf. von einem Akteur mit entsprechenden Anmerkungen unter Benutzung der Markierungsfunktionen versehen 

und 

• erfordert eine Aufzeichnung der Benutzungsgeschichte. 

Diese Aufzeichnung wird mit einem Anhänger dem Content-Objekt zugeordnet. Verpackungsumschläge (Kuvert) 

(envelops, docket) dienen als Anhänger. Sie enthalten: 

1. eine allgemeine Inhalts-Information, in der 

• die Sourcen, der Provider, die Autoren und die Benutzungsinformation mitgeführt werden, 

• der Inhalt und die unterstützten Aufgaben, die Eignung und die Art der Erzeugung dargestellt werden und 

• die Qualitätsbewertungen für das Content-Objekt angegeben werden, 

2. eine Anwendungsanleitung für das Content-Objekt, die auch Anmerkungen zu folgenden Dingen umfaßt: 

• Vertrauenswürdigkeit, dem Umfang der bereitgestellten Information, der Benutzungsrechte, Sicherheitskriterien 

und den Geschäftsbedingungen, 

• assoziierten Content-Objekten für unterschiedliche Benutzergruppen und 

• Annotationen, Anmerkungen zu Zugriffsmodellen, spezifischen Annotationen, zum Ressourcentypen und 

-formaten, sowie zur verwendeten Sprache, 

3. die Benutzungsgeschichte des Content-Objektes, die mit Parametern erfaßt und angepaßt werden kann, die 

schrittweise zu einer Erweiterung des Umschlags führen, 

4. allgemeine Zeitinformation, insbesondere 

• zu Versionen, Ausgaben und Benutzungsprofilen, 

• zu Erneuerungsstrategien, anwendbaren Verbindungsprofilen zur Erneuerung und die Art der Verbindung 

und 

• Signaturen, Beglaubigungshinweisen und Angaben zur wiederholten Benutzung. 

Wir fügen diesen Verpackungsinformationen dem Content-Objekt hinzu, indem durch Variable-Werte-Paare eine 

erweiterbare Attribut-Information mitgeführt wird. 

Container für die Auslieferung von Content-Objekten. 

Content-Objekte sollen dem Benutzer zur Verfügung stehen. Dabei wollen wir eine möglichst große Unabhängigkeit 

von der aktuellen Web-Technologie erreichen. Eine Auslieferung von Content-Objekten kann sowohl über der 

Internet als auch das Extranet oder Intranet erfolgen. Weiterhin kann ein Benutzer die Daten mit einem komfortablen 

System, wie z.B. einem Browser, einem weniger komfortablen System, wie z.B. einen text-basierten Browser, einem 

eingeschränktem Medium, wie z.B. einem Wap-Handy oder auch mit einem interaktionsbeschränkten Medium, wie 

z.B. Tele-Text, entgegennehmen und bearbeiten können. Deshalb muß ein Auslieferungsmedium eine hohe Allgemeinheit 

und eine sehr hohe Anpaßbarkeit besitzen. Wir führen dazu den Begriff des Containers ein. Ein Container 

soll beladen, an den Benutzer versandt und von ihm benutzt werden können. Durch die enthaltenen Content-Objekte 

wird einem Benutzer die erforderliche Datenmengen und Funktionalität bereitgestellt. 

Aufgrund dieser Anforderungen bedienen wir uns der Zugänge von Skriptsprachen. Dadurch kann auch eine 

Realisierung von Containern mit den Mitteln von Skriptsprachen erfolgen. 

Ein Container wird durch eine abstrakte Zustandsmaschine beschrieben: 

C = (I, M, O, ops C , Σ C ) 

mit 

Web IS


einem Namen C zur Bezeichnung des Containers, 

Zustandsräumen (Input-Raum, Content-Raum, Output-Raum) zur Aufnahme von Content-Objekten, die wir dem 

Benutzer zur Verfügung stellen wollen. Wir unterscheiden dabei drei verschiedene Räume: 

Input-Raum I: Zur Beladung der Container mit Inhalten wird ein Input-Raum zur Verfügung gestellt. 

Output-Raum O: Aus dem Container wird auf Anforderung des Benutzers ein passendes Content-Objekt 

ausgewählt und ihm zur Verfügung gestellt. 

Content-Raum M: In einem Container befinden sich verpackte Content-Objekte. Diese haben die folgende 

Struktur: 

Das Content-Objekt stellt die Daten und die Funktionalität, wie in diesem Abschnitt dargestellt, zur 

Verfügung. 

Abstrakte zu Content-Objekten sind zusammenfassende Beschreibungen des Inhaltes. Sie können auch 

leer sein. 

Kuverts erlauben die Führung von Begleit- und Benutzungsinformation zu Content-Objekten. 

Operationen ops C sollen die Verwaltung der drei Zustandsräume unterstützen. Deshalb unterscheiden wir: 

Auswertungsfunktionen zur Einlagerung von Content-Objekten in den Container, 

Operationen zum Verändern des Zustandes des Containers, 

Operationen zum Anfordern von Content-Objekten aus dem Container. 

Beschränkungen Σ C zum Container selbst sollen insbesondere darstellen 

das Vergleichsvermögen des Containers auf der Grundlage von Vergleichsmustern, 

die Beladungskapazität eines Containers und 

die Entladungsbeschränkungen für den Benutzungskontext. 

Die Räume des Containers realisieren einen Tupel-Raum. Jedes Element hat die Form 

(Variable, Wert) . 

Die Räume enthalten Multimengen von Elementen, d.h. 

I = {| t |} 

M = {| t |} 

O = {| t |} 

Eine Unterscheidung von Elementen erfolgt durch eine Mustererkennung der Variablen. 

Sind Elemente mehrfach in einem Container enthalten, dann muß eine intelligente Mustererkennung eine Separation 

erlauben. 

Variable sind Worte eines Alphabetes Alph. 

Variable können auch die Kuverts und Abstrakte aufnehmen. 

Werte sind Content-Objekte. 

Ein Container ist konsistent beladen, falls seine Tupel-Variablen eindeutig sind. Wir fordern jedoch keine Konsistenz 

a priori. 

Ein Container verfügt über eine Muster-Vergleichsfunktion ≈ C , mit der Elemente verglichen werden können. Der 

Mustervergleich hängt von den Mustern M ab, die ein Container vergleichen kann. Dieser Mustervergleich wird 

benutzt, um die Annahme von Content-Objekten zu verweigern oder auch dem Benutzer für seine Spezifikation ein 

passendes Content-Objekt auszugeben. 

Ein Vergleich von Elementen eines Containers nutzt ein Muster m unter Einbeziehung eines der Muster des 

Containers, wobei dann der Durchschnitt der beiden Muster zur Erkennung genutzt werden kann, und wird gültig für 

Elemente, falls keine Ungleichheit erkannt werden kann. 

{ 

(v, w) ≈ C,m (v ′ , w ′ true falls ∃m 

) = 

′ ∈ M : v, v ′ ≼ m ′ ⊓ m ∧ ( w = w ′ ∨ w =⊥ ∨w ′ =⊥) 

false andernfalls . 

Mit diesem allgemeinen Vergleich kann ein Container sowohl alle Elemente als nicht unterscheidbar betrachten 

(M = ∅) als auch alle Elemente genau unterscheiden (M = Alph + ). 

Web IS


Wir können nun die Operationen des Containers als parallel ablaufende Operationen zur Zustandveränderung 

behandeln. Diese Funktionen basieren auf folgenden Elementaroperationen des Containers: 

• eval(t) ist eine Auswertungsfunktion des Containers mit folgenden Eigenschaften: 

• eval(t) kann ggf. die Aufnahme von Content-Objekten blockieren. In diesem Fall ist das Resultat eine 

leere Multimenge. 

• Die Auswertung eines Content-Objektes kann auch zur Dekomposition dieses Content-Objektes führen, 

weil die Beladungskapazität des Containers für Einzelelemente ggf. beschränkt ist. 

• Die Auswertungsfunktion kann entsprechende Zeit erfordern. Mit einem Prädikat 

success(eval(t)) wird der Erfolg gemeldet. 

• inspect(C, m, t) = {| t ′ | t ≈ C,m t ′ |} 

• choose(M) wählt ein Element aus einer Multimenge aus. 

Wir benötigen nur vier Zustandsveränderungsfunktionen zur Veränderung von Z = (I, M, O) mit Elementen t ∈ 

T upel C und Mustern Muster : 

Schnelle Beladung: Die Funktion load : Z × T upel C → Z mit 

load((I, M, O), t) = (I, M ⊔ {| eval(t) |} , O) 

erlaubt eine sofortige Beladung von Containern. 

Langsame Beladung: Die Funktion lazzyload : Z × T upel C → Z mit 

lazzyload((I, M, O), t) = success(eval(t)) ⇒ (I, M ⊔ {| eval(t) |} , O) 

unterstützt eine verzögerte Beladung ohne auf die Beendigung der Berechnung von eval zu warten. 

Lesen im Containers: Die Funktion read : Z × Muster × T upel C → O mit 

read((I, M, O), m, t) = choose(inspect((I, M, O), m, t)) 

generiert ein Resultat auf die Anfrage t mit dem Muster m. 

Lesen und Löschen im Container: Die Funktion read : Z × Muster × T upel C → O × M mit 

read((I, M, O), m, t) = let x := choose(inspect((I, M, O), m, t)) : (x, M \ {| x |} ) 

generiert ein Resultat auf die Anfrage t mit dem Muster m und löscht dieses Resultat aus dem Content-Raum 

des Containers. 

Wir haben die Definition des Containers und seiner Operationen so allgemein gehalten, damit wir Container sowohl 

mit CORBA oder anderen Middleware-Systemen als auch mit JavaBeans oder auch direkt mit Perl, PHP bzw. anderen 

Skriptsprachen realisieren können. 

Diese Definition des Containers wird auch bei der Entwicklung von benutzereigenen Arbeitsräumen verwendet. 

Container können verfeinert werden 

• durch Instantiierung oder Adaption der Parameter 

• Vergrößerung und Verkleinerung der Kapazität, 

• Hinzufügen von Integritätsbedingungen und 

• Verfeinerung folgender Operationen: 

• der Vergleichsfunktion bzw. der Mustermenge, 

• der Auswertungsfunktion eval , 

• der Inspektionsfunktion inspect und 

• der Auswahlfunktionen, 

• sowie durch Verbesserung der Darstellung von 

• Abstrakten als Zusammenfassungen des Inhaltes der Content-Objekte und 

• Erweiterung der Kuverts, die wir im folgenden betrachten. 

Die Verfeinerung führt aufgrund des generischen Charakters der Funktionen zu einer Veränderung des Verhaltens der 

vier Hauptfunktionen, nicht aber zur Veränderung der Funktionen. 

Web IS


4.2.5 Der Content-Typ Benutzer-Arbeitsplatz 

Ein Informationssystem soll einen Benutzer effizient und effektiv in seiner Arbeit unterstützen. Das Portfolio, hauptsächlich 

bestehend aus dem Aufgabenmodell und dem Rollen- und Rechtemodellen des Akteurs, und das Benutzerprofil werden 

zur Generierung des Playout und des Layout der Content-Typen herangezogen. Portfolio und Profile behandeln 

wir im Abschnitt ?? ausführlich. 

Weiterhin muß eine Unterstützung für die Zusammenarbeit in Arbeitsgruppen erfolgen. Damit soll ein Content- 

Typ “Arbeitsplatz” auch die Zusammenarbeit in Arbeitsgruppen und die Publikation der Resultate der Zusammenarbeit 

gewährleistet werden. Wir unterscheiden aktive Content-Objekte, aktivierte Content-Objekte und passive Content- 

Objekte und entwickeln Kooperationsverträge zwischen den Objekten. Prozesse und Dialoge der Content-Objekte 

können sich auch gegenseitig bedingen, blockieren, abweisen und starten. 

Wir unterscheiden verschiedene Arten von Kopplungsmechanismen, die auch im Kombination verwendet werden 

können. 

• Bei einer Kopplung im Story-Raum werden die gleichen Daten interaktiv verwendet. Die Operationen sind 

durch Interaktion gekoppelt. Dazu existieren verschiedene Kopplungsmethoden: interne Kopplung, globale 

Kopplung, externe Kopplung, Kontrollflußkopplung, Wanderdatenkopplung und Parameterkopplung. 

• Die Container-Kopplung erlaubt nur ein Zusammenspiel der Content-Objekte unterschiedlicher Container. Es 

können verschiedene Grade der Kopplung unterschieden werden: versteckte Kopplung, verstreute Kopplung 

und spezifizierte Kopplung. 

• Die Kopplung durch Kooperation der Content-Objekte im Sinne der Sichtenkooperation folgt der hierarchischen 

Struktur der Typen des Schemas. Je nach Erzwingungsmechanismus unterscheiden wir Änderungskopplung 

(Signaturänderungskopplung bzw. Implementationsänderungskopplung), Verfeinerungskopplung (Signaturverfeinerungskopplung, 

Implementationsverfeinerungskopplung) und Erweiterungskopplung. 

Durch die Kohäsion wird die Bindung zwischen den einzelnen kooperierenden Objekten beschrieben. Aufgrund der 

Modellierung existieren verschiedene Arten. Die Funktions-Kohäsion (zufällige Kohäsion, logische Kohäsion, temporale 

Kohäsion, prozedurale Kohäsion, Kommunikationskohäsion, sequentielle Kohäsion und funktionale Kohäsion) 

geht von einer Bindung durch Operationen aus. Die Typ-Kohäsion (zerlegbare Kohäsion, mehrschichtige Kohäsion, 

nicht delegierte Kohäsion und verborgene Kohäsion) bewertet die Bindung der Objekte innerhalb einer Klasse. Die 

Vererbungskohäsion folgt der Definition der Hierarchien unter den Typen und Klassen. 

Im Rahmen der Forschungen zur Gruppenarbeit (CSCW Computer supported cooperative work) wurden Dialage 

nach unterschiedlichen Eigenschaften charakterisiert. 

Charakterisierung nach Raum und Zeit: Je nach Ort und Zeit sind unterschiedliche Dialoge möglich: 

Gleicher Ort 

Anderer Ort 

Gleiche Zeitpunkte Elektronische Besprechung Videokonferenz 

Elektronisches Brett 

Konversationsunterstützung 

Gemeinsamer Bildschirm Kooperatives Design 

Brainstorming 

Gruppeneditoren 

Zuhörerreaktion 

Verschiedene Zeitpunkte Gemeinsam genutzte Dateien Strukturierter Arbeitsfluß 

Designwerkzeuge 

Elektrononische Post 

Nachrichtenbrett 

Charakterisierung nach Interaktionsart: Die wichtigste Arten sind die folgenden: 

Durch den Sprechakt wird die Interaktionsform beschrieben. 

Im illokutionären Akt wird die kommunikative Funktion der menschlichen Kommunikation nachgebildet 

(z.B. präpositionaler Akt). Typische Darstellungsformen sind Assertion, Direktive, Kommissive, 

Deklarative und Expressive. 

Für den perlokutionären Akt wird die Wirkung auf den Zuhörer bewertet. 

Web IS


Die Konversation ist eine Kombination einer Reihe von Sprechakten. Wir unterscheiden dabei die 

die Konversation zur Handlung (Aufforderung zu einer Handlung), 

die Konversation zur Klärung (als Interaktion), 

die Konversation zur Entscheidung über Möglichkeiten (über einen Handlungsverlauf) und 

die Konversation zur Orientierung (zur klareren Darstellung der Umgebung). 

Die Charakterisierung nach Aktivitäten dient der Einbettung des Dialoges in die Spezifikation der Funktionalität. 

Ein Content-Typ Benutzer-Arbeitsplatz sollte die eine oder die andere Form unterstützen. Wir wählen dazu einen 

Ansatz, der sich relativ einfach realisieren läßt, sich gleichzeitig harmonisch mit den bisherigen Ansätzen verbindet 

und in Bild 11 skizziert ist: 

Kern-Typen des Content-Typs Benutzer-Arbeitsplatz sind die Typen Person, Arbeitsgruppe und Arbeitsplatz. Diesen 

Kern-Typen werden unterschiedliche Typen auf der Grundlage folgender Annahmen zugeordnet: 

Gruppierung von Personen in Akteure: Personen werden je nach ihrem Portfolio (Aufgaben, Stelle, Rolle, 

Umstände und Ziele) gruppiert. Diese Abstraktion wird durch die Einführung von Akteuren unterstützt. 

Arbeitgruppen: Eine Zusammenarbeit findet in Arbeitsgruppen und zwischen Arbeitsgruppen statt. Diese 

Interaktionsformen werden unterschieden. Die Mitarbeit von Personen in einer Arbeitsgruppe und das 

Treffen von Arbeitsgruppen sind durch unterschiedliche Typen realisiert. 

Zuordnung der Rechte zu Akteuren: Akteure erhalten Rechte z.B. zur Veröffentlichung der Resultate. Die 

Rechte an der Bearbeitung von Content-Objekten können analog erfaßt werden. 

Portfolio: Personen werden bei der Erledigung von Aufgaben unterstützt. Jede Person erhält dazu ihr spezifisches 

Portfolio, das in die Zusammenarbeit der Arbeitsgruppen einfließt. 

Organisationsmodell: Es wird ein einfaches Organisationsmodell benutzt, bei dem einer Person Rollen zugeordnet 

werden, die in der Firma üblich sind. 

Content-Objekte und Container stehen den Benutzern zur Verfügung. Sie befinden sich zu unterschiedlichen Zeitpunkten 

auf unterschiedlichen Arbeitsplätzen. 

Mit einem Content-Typ Arbeitsplatz können sowohl Arbeitsgruppen, als auch Benutzer auf einfache Art in ihren 

Kooperationsbeziehungen unterstützt werden. 

• Je nach Art der Arbeitsaufgabe, 

• je nach Portfolio oder Person, 

• je nach Einwahl und Ausweis als Akteur, 

• je nach Gruppenzugehörigkeit, 

• je nach Content-Objekt-Menge bzw. Container 

wird einem Benutzer ein anderer Arbeitsplatz zur Verfügung stehen. Damit besitzt eine Person unterschiedliche Rechte. 

Akteure sind dann z.B. der Administrator, der Leiter einer Arbeitsgruppe und der Besitzer von Content-Objekten 

oder Containern. 

Die Außendarstellung für den anonymen Benutzer wird über das Nachrichtenbrett realisiert. 

Auf dem Content-Typ Arbeitsplatz kann zur Laufzeit ein Sitzungsobjekt aufgesetzt werden. Damit dies in allgemeiner 

Form möglich ist, führen wir Sichten über dem Content-Typ ein, die wir Sitzungs-Schema S Arbeitsplatz (Parameter) 

nennen. 

Ein Sitzung-Objekt SO Arbeitsplatz (a, b, ...) stellt eine Instantiierung des Sitzungs-Schemas und eine Einbettung 

in den Kontext dar. 

Web IS


Nutzeraccount 

Nachrichtenbrett 

✛ 

✻ 

⊕ 

Spezifische 

Rechte 

❄ 

Akteur 

✻ 

gruppiert 

zu 

Person 

hat Profil 

✲ 

✲ 

✻ 

nutzt 

plaziert 

auf 

❄ 

Mitarbeitportfolio 

❄ 

Person 

✻ 

Berechtigung 

zu 

Rolle 

✲ 

Rolle 

✻ 

✠ 

Mitarbeit 

in 

❄ 

Veröffentlichungsorgan 

❄ 

❄ 

Firma ✛ freigegebene ✲ 

Rolle 

Memo ✛ 

✯ 

✻ 

⊕ 

✛ 

✲ 

✲ 

Rolle 

freigegebene 

Funktion 

nutzt 

gehört 

zu 

✛ 

❄ 

Container ✛ 

✲ 

✲ 

Weitergabeart 

✻ 

Content- 

Typ 

✻ 

von 

❄ 

Arbeitsplatz 

✻ 

❄ ✢ 

✲ Content- ✛ 

Objekt 

befindet 

sich auf 

Memokategorie 

Portfolioart 

✙ 

Arbeitsgruppe 

Arbeitsnachrichten 

✲ Treffen ✛ 

Aufgaben 

mit ✲ 

Ziele 

✻ 

Verantwortungstyp 

✛ Verantwortung ✲ 

Teilnehmer 

✲ 

Ausleihmodus 

✻ 

befindet 

sich in 

klassifiziert 

in 

✠ 

✲ 

nutzt 

Kategorie 

Raum 

Abbildung 11: Teil des Schemas für den Content-Typ Arbeitsplatz (ohne Attribute und Beschränkungen) 

Web IS


Ein Sitzungs-Schema ist eine parametrisierte Sicht auf den Content-Typ Arbeitsplatz. Parameter eines Sitzungs- 

Schemas sind dann Auswahl-Objekte, mit denen die Daten und Funktionen für eine Sitzung freigeschaltet werden 

können. 

Im Beispiel von Bild 11 ist dies ein Parameter 

Aufruf = choose Person (Name, Login, Paßwort) 

or Mitglied (Name, Login, Paßwort, Arbeitsgruppe) 

or Akteur (Name, Login, Paßwort, Rolle) 

or Anonymität 

Damit werden die entsprechenden Sichten und Funktionen freigeschaltet. Gleichzeitig wird die Konsistenz in der 

Benutzung entsprechend der gewählten Kooperationsbeziehungen gewahrt. Damit wird ein Benutzer auf unterschiedliche 

Art unterstützt: 

Person als zentraler Einwahlpunkt in den Arbeitsplatz: In diesem Fall werden unter Berücksichtigung der Rollen, 

Rechte und des Portfolios der Arbeitslatz mit den Containern und Content-Objekten aufgebaut. 

Mitglied einer Arbeitsgruppe mit einer Einwahl in die Arbeitsgruppe, den für die Arbeitsgruppe freigegebenen Arbeitsplätzen, 

den entsprechenden Containern und den aktuellen Arbeitstreffen. 

Akteur mit einer Einwahl über die Person und die Rolle, dem Freischalten von entsprechenden Teilen des Content- 

Objektes zur Bearbeitung von Daten etc. 

Anonyme Benutzung der freigegebenen Nachrichten, Content-Objekte und allgemeinen Übersichten. 

Das Content-Objekt SO Arbeitsplatz (Akteur(BernhardThalheim, thalheim, ∗ ∗ ∗∗, Arbeitsgruppenleiter)) generiert 

dann z.B. die Content-Objekte, Container und Schreibtische, die der Autor auf seinen Arbeitsplatz als Arbeitsgruppenleiter 

besitzt. 

Auf analoge Art können der Content-Typ Persönlicher Arbeitsraum und der Sitzungs-Typ 

S PersönlicherArbeitsraum (Parameter) realisiert werden. 

Damit steht eine allgemeine Technologie zur Realisierung beliebig komplexer Szenario zur Verfügung. Diese 

Technologie erlaubt auch die Generierung entsprechender Begleitinformation, das Aktualisieren der entsprechenden 

Datenbestände und kann durch Integration entsprechender allgemeiner und inhaltsbasierter Repräsentationsstile, 

einschließlich entsprechender Metaphern eine automatische Generierung von Arbeitsoberflächen unterstützen. 

Web IS


4.3 Sichtenkooperation und Integrationsschema 

Das Problem der Sichtenintegration ist ein unentscheidbares Problem. Eine vollständige Sichtenintegration ist jedoch 

in der Praxis weder erforderlich noch erwünscht. Oft sollen Datenbestände auch lose gekoppelt bleiben. Die 

Theorieeinsicht, daß eine Sichtenintegration unentscheidbar ist, steht der Praxisbeobachtung gegenüber, bei der Daten 

in unterschiedlichen Anwendungen relativ einfach miteinander in Beziehung stehen können. Die Anwendungen 

verwenden allerdings in der Praxis ein explizites oder implizites Integrationsschema. Wir wollen diese Idee weiterverfolgen. 

Eine Integration von Daten ist aus einer Vielzahl von Gründen nicht möglich. Die Sichtenintegration wird durch 

verschiedene Vereinbarkeitsprobleme und Konflikte erschwert: 

Strukturelle Konflikte: Die Strukturen entsprechen einander nicht. 

Unterschiede in Schlüsseln: Es existieren nur verschiedene, nicht integrierbare Schlüssel. 

Abstraktionsgranularität: Die Abstraktion der verschiedenen Typen ist unterschiedlich. Zum Beispiel sind 

Vorlesung und Kurs in unserem Beispiel nicht auf gleichem Abstraktionsniveau. 

Verschiedene Zeitmaße und Wertebereiche: Die Repräsentation und die Wertemengen von Attribut-Typen 

können einander entsprechen, ohne daß dies direkt ersichtlich ist. 

Fehlende Typen: Da Sichten eine eingeschränkte Welt repräsentieren, sind sie unvollständig. 

Semantische Unterschiede: Die Bedeutung bzw. Semantik der Konzepte ist unterschiedlich. 

Unterschiede im Gültigkeitsbereich: Es gelten weder Inklusions- noch Exklusions-, noch die negierten Inklusions- 

, noch die negierten Exklusionsabhängigkeiten. 

Wertesemantik: Die Bedeutung der Werte umfaßt zusätzliche Werte, wie z.B. die Matrikelnummer, die das 

Immatrikulationsjahr mit einschließt. 

Verschiedene Konstruktoren bei Synonymen: Verschiedene Konstruktoren für äquivalente Mengen führen 

zu relativ komplexen Integritätsbedingungen, die in den Sichten fehlen. 

Verschiedene Operationen: Auf den Typen sind unterschiedliche Operationen definiert, die nicht integrierbar sind. 

Verschiedene Wertebereiche: Synonyme Typen besitzen verschiedene Wertebereiche. 

Wir können jedoch mit dem ER-Modell Mechanismen bereitstellen, die eine Kooperation von Sichten unterstützen. 

Gegeben seien die Sichtenschemata S 1 und S 2 und entsprechende Datenbanken S C 1 und SC 2 . 

Ein partieller Schema-Morphismus von S 1 und S 2 wird 

• als Paar (f 12 , f12 C ) von Funktionen definiert, so daß 

• f 12 eine partielle Einbettungsfunktion von Typen von S 1 in Typen von S 2 mit dem Definitionsbereich def(f 12 ) = 

S 12 ist, 

• f C 12 ist die korrespondierende Einbettung von Klassen von SC 1 in die von SC 2 , d.h. 

• f 12 : S 1 −→o S 2 und 

• f C 12 : SC 1 −→o S C 2 

• mit der Eigenschaft f C 12 (SC 1 ) |= T S 2 | f12 (T ) falls f 12 definiert ist für den Typen T , d.h. die Abbildung 

f 12 erhält die Semantik von S 2 . 

Damit kommutiert das linke Diagramm in Bild 12 . 

Die Partialität von (f 12 , f12 C ) definiert ein Sichtenschema S 11 in S 1 und eine Sicht f 12 (S 11 ) in S 2 . 

Es sei außerdem ein partieller Schema-Morphismus (f 21 , f21 C ) von S 1 und S 2 gegeben. 

Die Schema-Morphismen (f 12 , f12 C ) und (f 21, f21 C ) definieren eine Sichtenkooperation falls


S 1 

f 12 

✲ 

S 2 

|= |= 

S C 1 S C 2 

f12 

C 

S C ✲ 

1 S C 2 

S 2 

f 21 

✲ 

|= |= 

S 1 

S C 11 

f12 C (SC 11 

f ✲ ) 

12 

C 

f21 C (SC 21 ) ✛ f21 

C 

S C 21 

f C 21 

S C ✲ 

2 S C 1 

Abbildung 12: Partielle Schema-Morphismen zur Sichtenkooperation 

• für jeden Typ T 1 ∈ S 11 ∩ f 21 (S 21 ) und jedem Typ T 2 ∈ S 21 ∩ f 12 (S 11 ), 

• für jedes Paar der entsprechenden Klassen T C 1 ∈ S C 1 , T C 2 ∈ S C 2 

• die Funktionen f C 12 (T C 1 ), f C 21 (f C 12 (T C 1 )), f C 21 (T C 2 ), f C 12 (f C 21 (T C 2 

)) definiert sind und 

• die kommutierenden Gleichungen f C 21 (f C 12 (T C 1 )) = T C 1 , f C 12 (f C 21 (T C 2 )) = T C 2 gelten. 

Durch die Sichtenkooperation wird ein Input eines Schemas mit dem Output eines anderen Schemas verknüpft. 

Diese Verknüpfung erlaubt eine Verbindung von Sichten, wie in Bild 12 bei Angabe der Funktionen f 12 und f 21 . 

Sind die Typen der Sichten entweder über Schema-Morphismen total verbunden oder paarweise verschieden, 

dann sprechen wir von der Sichtenintegration. Eine Sichtenintegration können wir damit formal definieren. Meist 

wird eine Sichtenintegration nur pauschal und informal in der Literatur eingeführt. Mit dem Schema-Morphismus 

können wir die Sichtenintegration auch formal fassen. In diesem Fall gelten: 

• f 12 (S 11 ) = S 21 und 

• f 21 (S 21 ) = S 11 . 

Sind zwei Typen total verbunden, wird einer der Typen der Schemata zur Weiterführung im integrierten Schema 

ausgewählt und der nicht verwendete Typ über eine Sichtendefinition an den verbleibenden Typen gebunden. 

Die Assoziierbarkeit von Typen der Schemata wird durch die Wertebereiche der Typen der Sichtenschemat begrenzt: 

Typen T 1 in S 1 und T 2 in S 2 sind wertebereichsverträglich, falls dom(T 1 ) = dom(T 2 ) gilt. 

Es ist anzumerken, daß die Wertebereichsverträglichkeit nicht auf eine Teiltypen-Eigenschaft S 11 ∩ f 21 (S 21 ) 

und in S 21 ∩ f 12 (S 12 ) für die Morphismen der Sichtenkooperation reduzierbar ist. 

Die beiden Schema-Morphismen (f 12 , f12 C ) und (f 21, f21 C ) definieren eine Gleichungstheorie E. Wir können vereinfachend 

annehmen, daß alle Typen-Namen in den Schemata S 1 und S 2 verschieden sind. Damit können wir für 

alle Typen T 1 in S 1 die Gleichung T 1 = f 12 (T 1 ) und für alle Typen T 2 in O2 V die Gleichung T 2 = f 21 (T 2 ) 

zur Gleichungstheorie E hinzufügen. 

Falls wir an einer vollständigen Integration interessiert sind, dann können die Gleichungen durch Term-Ersetzungsregeln 

der Form T ❀ f ij (T ) oder f ij (T ) ❀ T ersetzt werden. Diese Ersetzungsregeln müssen auch dem induktiven 

Aufbau der Typen folgen. Deshalb wird auch ein Ableitungssystem benötigt. Wir nutzen dazu die folgenden Inferenzregeln: 

E ∪ {T (T 1 , ...., T m ) = S(S 1 , ..., S m )} 

E ∪ {T 1 = S 1 , ..., T m = S m } 

E ∪ {T = T } 

E 

E ∪ {T = S} 

E ∪ {S = T } 

E ∪ {T = S} 

ϑ T ❀S (E) ∪ {T = S} 

für Substitution von ϑ T ❀S in E. 

Zwei Sichtenschemata sind integrierbar, wenn Schema-Morphismen existieren, die alle Typen der Schemata paarweise 

miteinander assoziieren.


Wir können die Sichtenintegration auch durch Definition entsprechender Anfragemengen definieren. Diese Definition 

ist der obigen äquivalent.


4.4 Medientypen 

4.4.1 Grundlagen für die Technologie der Medientypen 

The Join Operation. 

In order to obtain also a generalised join it is a natural idea to exploit subtyping on the type system. This is a 

preorder ≤ on the types. 

Suppose, our collection of base types contains at least the type 1l. BOOL may be identified with {1l}. Then 

subtyping can be defined in the standard way as the smallest preorder such that the following holds: 

• For any type t we have t ≤ 1l. 

• For set types (or list types, respectively) we have {t} ≤ {t ′ } (or [t] ≤ [t ′ ], respectively) iff t ≤ t ′ holds. 

• For tuple types we have t 1 × · · · × t m ≤ t ′ 1 × · · · × t′ n iff t σ(i) ≤ t ′ i holds for some injective σ : {1, . . . , n} → 

{1, . . . , m}. 

Then each subtype relation t ≤ t ′ defines an associated subtype function π t ′ : t → t ′ . Note that the projections in 

relational algebra are just such subtype functions. Indeed, t is the least common supertype of t 1 and t 2 ; t 1 ⊲⊳ t t 2 is a 

common subtype. 

The following theorem is central for the definition of the general join [Sch01]. 

Theorem 1 Consider a type system with the trivial type 1l as one of its base types and with constructors among 

the tuple, set and list constructors. If t is a common supertype of t 1 and t 2 with associated subtype functions πt i : 

t i → t, then there exists a common subtype t 1 ⊲⊳ t t 2 together with subtype functions π ti : t 1 ⊲⊳ t t 2 → t i such that 

πt 1 ◦ π t1 = πt 2 ◦ π t2 holds. Furthermore, for any other common subtype t ′ with subtype functions π t ′ i 

: t ′ → t i with 

πt 1 ◦ π t ′ 1 

= πt 2 ◦ π t ′ 2 

there is a unique subtype function π : t ′ → t 1 ⊲⊳ t t 2 with π ti ◦ π = π t ′ i 

. 

For t = 1l we obtain t 1 ⊲⊳ t t 2 simply as the product t 1 × t 2 . With the existence of the join types t 1 ⊲⊳ t t 2 the join 

over t can be defined as in the relational case. For this let C 1 and C 2 be classes. We define 

C 1 ⊲⊳ t C 2 = {z : T C1 ⊲⊳ t T C2 | ∃z 1 ∈ C 1 .∃z 2 ∈ C 2 .π t1 (z) = z 1 ∧ π t2 (z) = z 2 } . 

Example 1 Consider t 1 = {b 1 × {b 2 × b 3 } × b 4 } and t 2 = {b 1 × {b 5 × b 3 } × b 6 } with the common supertype 

t = {b 1 × {b 3 }}. Then we obtain the join type 

t 1 ⊲⊳ t t 2 = {b 1 × {b 2 × b 5 × b 3 } × b 4 × b 6 } . 

Handling URLs. 

The structures allowed by the definition of databases in the previous section are all finite. In fact, values can be 

represented as finite trees. A slight generalization would be to allow infinite trees, but of course only such infinite 

trees that can be represented in a finite way. For this we introduce labels l. We extend any given type system in such 

a way allowing types to be adorned with labels and labels themselves to be treated in the same way as base types. 

Thus, our type system extends to 

t = b | l | t 1 × · · · × t n | {t} | [t] | l : t. 

Furthermore, we have to restrict ourselves to well-defined types. For this we require that for each label l occurring 

within a type t—in a place, where we could have a base type instead—some decorated type l : t ′ must occur in t, too. 

Values of such types with labels can be written as an infinite tree. Figure 13 a) shows such a tree. We call a tree 

rational iff the number of different subtrees is finite. Then only rational trees will be allowed as values of well-defined 

types with labels. For our example, this means to restrict to values of the form 

(n 1 , a 1 , (n 2 , a 2 , (. . . , (n k , a k , (. . . )))), 

IS ADD


⊗ 

n 1 

n 2 

n 3 

a 1 

a 2 

a 3 

⊗ 

⊗ ✐ 

⊗ 

⊗ 

n 1 

n 2 

a 1 

a 2 

. 

a) Abbildung 13: Rational Tree b) 

representation with ✛ ✲representation with 

links 

rational trees 

query operation Q ′ 

❄ 

representation with ✛ 

links 

query operation Q 

❄ 

✲representation with 

rational trees 

Abbildung 14: Handling URLs in queries 

such that n i = n j and a i = a j holds for some i and j. In addition, we would like to add a constraint and require 

i = 1, j = 3, but this constraint must be added explicitely; it is not captured by the type system. Figure 13 b) 

illustrates such a rational tree. 

Since we restrict ourselves to well-defined types with labels, which can be written as rational trees, and allow 

only rational trees as values, we shall talk of rational tree types. 

One important feature of rational tree types is that the query algebra outlined in the previous subsections extends 

naturally to rational tree types. Furthermore, as the representation with URLs can be regarded as a means to finitely 

represent rational trees, it can also be shown that we can replace the rational trees by the URLs, iff the query language 

is extended in such a way that it can create URLs and links. This can be done as follows: 

• create urls transforms a set {v 1 , . . . , v m } of values into a set {(u 1 , v 1 ), . . . , (u m , v m )} of pairs with new 

created URLs u i of type URL; 

• It also transforms a list [v 1 , . . . , v m ] of values into a list [(u 1 , v 1 ), . . . , (u m , v m )] of pairs with new created 

URLs u i of type URL; 

• The operation create url transforms a value v of any type into a pair (u, v) with a new URL u. 

Theorem 2 Let S be a database schema, where the types of classes are rational tree types and let S ′ be an equivalent 

schema that uses the type URL, but no rational tree types. Then the result of an algebra query on S ′ with URL and 

link creation is the URL-based representation of the result of the same query applied to S and vice versa. 

Figure 14 illustrates the relationship between querying with URL creation and querying with rational trees. 

Example 2 Consider the scene home loan in Example ??. For this scene the information consumption is the description 

of a particular loan type. So we get 

cont(home loan) = (type : STRING, conditions : STRING, 

interest : { (amount : CARD, rate : FLOAT) }) . 

In this case the defining query is simply q home loan = create urls(LOAN TYPE). 

IS ADD


4.4.2 Operations on Interaction Types 

Conceptual abstraction of database behaviour is achieved via operations associated with database types. These operations 

can be described in a way known from programming languages. Here we adopt an imperative style. Then, in 

order to model the required functionality we also add operations to interaction types. This is completely analogous to 

the d-operations on dialogue types [SS00]. 

Definition 1 An operation on a database type C consists of a signature and a body. The signature consists of an 

operation name O, a set of input-parameter/type pairs ι i :: T i and a set of output-parameter/type pairs o j :: T j ′. The 

body is recursively built of the following constructs: 

• assignment x E := exp, where x is a variable representing the content of the type E itself or a local variable 

(including the output-parameters), and exp is an expression of the same type as x E , 

• local variable declaration Let x : t, 

• skip and fail, 

• sequencing S 1 ; S 2 and branching IF P THEN S 1 ELSE S 2 ENDIF , 

• operation call E ′ :- O ′ (in : exp ′ 1 , . . . , exp′ j , out : x′ 1 , . . . , x′ i ), where O′ is an operation on the type E ′ with 

compatible signature, and 

• non-deterministic selection of values New.f(x), where f is a selector on E. 

An operation on an interaction type M consists of an operation signature, i.e., name, input-parameters and 

output-parameters, a selection type which is a supertype of cont(M), and a body which is defined via operations 

accessing the underlying database. 

There exist several standard operations that are of particular interest in web information systems: 

• Generalization functions are used for generation of aggregated data. They are useful especially in the case 

of insufficient space or for the display of complementary, generalized information after terminating a task. 

Hierarchy rules are used for the specification of applicability of generalization functions. The roll-up function 

in [AGS97a], slicing, and grouping are special generalization functions. 

• Specialization functions are used for querying the database in order to obtain more details for aggregated data. 

The user can obtain more specific information after he has seen the aggregated data. Hierarchy rules are used for 

the specification of applicability of specialization functions. The drill-down function used in the data warehouse 

approach is a typical example. 

• Reordering functions are used for the rearrangement of units. The pivoting, dimension destroying, pull and 

push functions [AGS97a] and the rotate function are special reordering functions. 

• Browsing functions are useful in the case that information containers are too small for the presentation of the 

complete information. 

• Sequentialization functions are used for the decomposition of sets or sequences of information. 

• Linking functions are useful whenever the user is required to imagine the context or link structure of interaction 

types. 

• Survey functions can be used for the graphical visualization of the contents of the interaction type. 

• Searching functions can be attached to interaction types in order to enable the user for computation of add-hoc 

aggregates. 

• Join functions are used for the construction of more complex interaction types on the basis of the given metaschema. 

IS ADD


4.5 Modelling Contextual Information 

Within the framework of media types the problem of contextual information is not yet well supported. In [FKST00] 

it has been emphasised that “escort information” is required in each scene. The problem is to provide in a condensed 

form the information the user has already seen since entering the WIS. This means to place each scene of the story 

space into a context. The work in [FKST00] claims that introducing a subtyping mechanism between media types 

is useful for modelling escort information, thus contexts. However, subtyping is a static concept, which is useful for 

tree-like navigation structures, whereas in some cases the more complex navigation and story structures will require 

a dynamic solution. We therefore ask, whether the work on contextual information bases (CIBs) [AST02, TACS98, 

TACS99] can be exploited for enhancing our methodology. We generalise and tailor the CIB-approach in order to 

integrate it with the theory of media types. This provides the formal conceptual means for context modelling. 

According to the theory of CIBs a context is a set of objects, each having several names, and each of these names 

may be coupled with a reference to another context. There may be names for objects that are not referencing to other 

contexts. Here, the term “object” is used in the sense of “object identifier”, i.e. a unique abstract handle to identify 

objects. 

More formally, a context C is a finite set of triples (o i , n i , r i ), where o i is an object identifier, i.e. a value of some 

base type ID, n i is a name, i.e. a value of type STRING, and r i is either a reference → C ′ to a context C ′ or nil, the 

latter one indicating that there is no such reference. 

We write C = {n 1 : o 1 → C 1 , . . . , n l : o l → C l }. If there is no reference for the i’th name, i.e. we have 

(o i , n i , nil) we simply omit → C i and write n i : o i . 

The idea of working with contextual information bases is that a user queries them and thus retrieves objects. In 

order to describe these objects in more details she or he accesses the context(s) of the object, which will lead — by 

following the references — to other objects. In addition, a particular information encoded by the name is associated 

with each of these references. The work in [TACS99] describes a path query language for contextual information 

bases. Most important for our problem are the following macros of this language: 

• The macro look-up(C, n) takes two input parameters. The first one is the name of a context C. The second 

one is a name n, i.e., a value of type STRING. The macro returns name paths n i = n 0 i , . . . , nk i 

i 

starting from 

context C and ending in n, i.e. n k i 

i 

= n. 

• The macro cross-ref(p, C) also takes two input parameters. Here the first one is a name path p = p 0 , . . . , p l . 

The second one is the name of a context C. The macro returns name paths n i = n 0 i , . . . , nk i 

i 

starting from context 

C and ending in the name specified by p, i.e., p l = n k i 

i . 

Let us now bring together media types and contextual information bases. The obvious questions are: 

• What are the objects that are required in contextual information bases, if we are given media types? 

• What are the references that are required in contextual information bases? 

• Is it sufficient to have names for describing objects in a context or should these be replaced by something else? 

The natural idea for generalising the notion of object in contexts is to choose the media objects. Concentrate on the 

raw media objects first. Evaluating the defining query for a raw media type M leads to a set {(u 1 , v 1 ), . . . , (u n , v n )} 

of raw media objects. Recall that the u i are values of type URL, whereas the v i are values of the representing type t M . 

As these URL-values are unique, they identify the raw media objects, and thus can be used as surrogates for them in 

the notion of context. 

This answers our first question. The objects are the media objects. The object identifiers needed in the contexts 

are the (abstract) URLs of these media objects. 

As we want to have access to path information, we may want to reference back to the various media objects 

that we have encountered so far. These media objects are placed in several contexts, one of which is the right one 

corresponding to our path. However, we may also have different references, which lead to different contexts. So, the 

contexts we asked for in the second questions are just the contexts for the media objects. 

Web IS


As to the third question, we definitely want to have more information than just a name. Fortunately, the theory of 

media types is already based on the assumption of an underlying type system. Thus, we simply have to replace the 

names by values of any type allowed by the type system. Having defined such extended contexts, the query macros 

such as look-up and cross-ref would allow to traverse back a path in the story board and to explore alternative 

access paths, respectively. 

However, one important aspect of media types is the use of classification abstraction. Conceptually, we do not define 

a set of media objects, but we generate them via queries defined on some underlying database schema. Therefore, 

we also need a conceptual abstraction for contexts. 

In order to obtain this conceptual abstraction, we assume another base type Context, the values of which are 

context names. Instead of this, we could take the type URL, but in order to avoid confusion we use a new type. 

A context consists of a name C, i.e. a value of type content, a type t C and a defining query q C , which must be 

defined on the media schema, i.e., the set of media types, such that 

({(object : URL, value :t C , reference : Context)}, q C ) 

defines a view. Thus, executing the query q C will result in a set of triples (u i , v i , r i ), where u i is the URL of a 

media type, v i is a value of type t C , and r i is the name of a context. If this context is undefined, this is interpreted as 

no reference for this object in this context. Note that in particular this definition of context leads to views over views. 

Let us finally reconsider the “old” definition of media types in [FKST00], which included supertypes. In this 

case, all the supertypes are media types, thus depend on defining queries. They could be treated as queries defining a 

context. Thus, a media object of type M would be in as many contexts as there are supertypes of M. However, there 

are two important differences: 

• In contextual information bases we want to select one context to obtain the information about the path, whereas 

the supertyping assumes that the combination of all supertypes defines the required context. 

• If the supertypes are treated as if they are defining contexts, then there will be no references from their objects 

to other contexts. This omits the possibility of navigating through contexts. 

Alternatively, we could take all the defining queries of supertypes of M together to define a context. Then each 

media object would belong to exactly one context, and as before there would not be any references to other contexts. 

Thus, supertyping turns out to be a simplified, static version of context modelling. 

Web IS


4.6 Abbildung auf objekt-relationale Strukturen 

4.6.1 Management von virtuellen und materialisierten Sichten 

4.6.2 Versionierung 

Warum dann HERM anstatt von UML. 

IS ADD


4.7 Modellierung von Sichten 

Übung: 

.


Literatur 

[AGS97a] R. Agrawal, A. Gupta, and S. Sarawagi. Modeling multidimensional database. In Proc. Data Engineering 

Conference, Birmingham, pages 232–243, 1997. 

[AGS97b] R. Agrawal, A. Gupta, and S. Sarawagi. Modeling multidimensional databases. In A. Gray and P.-Å. 

Larson, editors, Proc. 13th Int. Conf. on Data Engineering - ICDE’97, pages 232–243, Birmingham, 

1997. IEEE Computer Society Press. 

[AST02] 

M. Akaishi, N. Spyratos, and Y. Tanaka. A component-based application framework for context-driven 

information access. In Hannu Kangassalo, editor, Information Modelling and Knowledge Bases, volume 

XIII, pages 254–265. IOS Press, Amsterdam, 2002. 

[FKST00] T. Feyer, O. Kao, K.-D. Schewe, and B. Thalheim. Design of data-intensive web-based information 

services. In Qing Li, Z. Meral Ozsuyoglu, Roland Wagner, Yahiko Kambayashi, and Yanchun Zhang, 

editors, Proceedings of the 1st International Conference on Web Information Systems Engineering (WISE 

2000), pages 462–467. IEEE Computer Society, 2000. 

[GL97] M. Gyssens and L. V. S. Lakshmanan. A foundation for multidimensional databases. In M. Jarke, M. J. 

Carey, K. R. Dittrich, F. H. Lochovsky, P. Loucopoulos, and M. A. Jeusfeld, editors, Proc. 23rd Int. Conf. 

on Very Large Databases - VLDB’97, pages 106–115, Athens, 1997. Morgan Kaufmann, San Francisco. 

[Mol07] 

[Sch01] 

[SS00] 

A. Molnar. A general partition data model and a contribution to the theory of functional dependencies. 

PhD thesis, Eötvös Loránd University, Faculty of Informatics, Budapest, 2007. 

K.-D. Schewe. Querying web information systems. In Hideko S. Kunii, Sushil Jajodia, and Arne Sølvberg, 

editors, Conceptual Modeling – ER 2001, volume 2224 of LNCS, pages 571–584. Springer-Verlag, 2001. 

K.-D. Schewe and B. Schewe. Integrating database and dialogue design. Knowledge and Information 

Systems, 2(1):1–32, 2000. 

[TACS98] M. Teodorakis, A. Analyti, P. Constantopoulos, and N. Spyratos. Context in information bases. In Proceedings 

CoopIS ’98, pages 260–270, 1998. 

[TACS99] M. Teodorakis, A. Analyti, P. Constantopoulos, and N. Spyratos. Querying contextualized information 

bases. In Proceedings ICT & P ’99, 1999. 

[Tha96] B. Thalheim, editor. Proc. 15th Int. ER Conf., Conceptual Modeling - ER’96, LNCS 1157, Cottbus, 

Germany, Oct. 7 - 10, 1996, 1996. Springer, Berlin. 








D - 24098 Kiel 

 





5. DI-Management ab SS 2012 

Farben der Seiten im Skript. 


Modellierung von Informationssystemen 

Web-Informationssysteme 

Forschung 



5 Daten- und Informationsmanagement 

O glücklich, wer noch hoffen kann, 

Aus diesem Meer des Irrtums aufzutauchen! 

Was man nicht weiß, das eben brauchte man, 

Und was man weiß, kann man nicht brauchen. 

Goethe, Faust, Erster Teil, Vor dem Thor, Faust 

Data, information and knowledge management is often neglected. All organizations, research projects, the information 

society depend on data, and good data management practices are critical to many technology-based organizational 

initiatives, including business intelligence, customer relationship management, and data warehousing. Bad, 

incomplete, or inaccurate information has been the downfall of projects, departments, and even entire organizations. 

Data, information and knowledge management involves both process and policy. Tasks range from strategic data 

planning to the creation of data element standards to database design, implementation, and maintenance. 

• It has a technical component: interfacing with and facilitating interaction between software and hardware. 

• It has a specific focus: creating and maintaining data to provide useful information. 

• It includes management of metadata artifacts that addresses the data’s form as well as its content. 

In addition, everyone in a research project should understand the importance of effective data management to their 

organization. Without that understanding, there is little chance data management strategies can be successfully implemented.

CAU zu Kiel, IfI, ISE, β 5. DI-Management ab SS 2012 481 

Ziele dieses Teilkapitels 

Information, Wissen, Daten 

als Grundmittel 

Semiotik (als Basis) durch Syntax, Semantik, Pragmatik; Unterschied zu Pragmatismus 

Aspekte bei WI-Systemen: Rhetorik-Rahmen von Hermagoras von Temnos erweitert (Thalheim W ∗ H-Rahmen)statt 

Zachman; 

daraus Orientierung auf Strukturierung + Berechnung + Steuerung als drei Systemkomponenten 

Information in den 4 Definitionen mit Vor- und Nachteilen: 

• syntaktisch (Entropie), 

• semantisch (Ableitung), 

• pragmatisch (antroposophisch), 

• ökonomisch (Nutzen)(wie in WI meist genutzt) 

Wissen nach den Definitionen von Thalheim; 

eine der Dimensionen im dreidimensionalen Raum (Nutzen für CoP (pragmatisch+ökonomisch)(Information) 

, Validierung (Wissen), Daten); 

Unterscheidung Information, Desinformation, Mißinformation, Fakten, Regeln 

Abstraktion als Struktur-, Verhaltens- und Kontextabstraktion mit den drei Unterfacetten jeweils 

Abstraktionsschichtenmodell im Überblick; Unterscheidung von description - prescription - specification 

Strategische-(taktisch-)administratives-operationelle Aspekte 

Rollen und ‘Spiel’ der Benutzer, Benutzergruppen (community of practice) 

Zentrale Literaturquellen (hier nicht eingearbeitet, sondern für das Selbststudium) 

• Heinrich, L. J.: Informationsmanagement - Planung, Überwachung und Steuerung der Informationsinfrastruktur. 

11. A., München/Wien 2011, sowie auch frühere Auflagen. 

Das zentrale Buch in diesem Gebiet; aufgabenbezogene Auflösung (strategisches, adminstratives, operatives 

Niveau) 

• Krcmar, H.: Informationsmangement. Springer 2010, sowie auch spätere und frühere Auflagen. 

Als Überblicksbuch und zur Motivation. 

• Resch 

• Websites als Ergänzung: 

www.dama.org, www.ogc.gov.uk/guidance itil.asp oder www.isaca.org/cobit 

3-Ebenen-Modell 

• Management der Informationswirtschaft (Angebot, Nachfrage, Verwendung (allgemeine story-Rahmen, Rechte, 

Bedarf, Relevanz))[Bsp. Informationsströme bei DB: TA, Produkt, Kunde; Analyse z.B. Umsatz einzelner 

Segmente; Erfolge strategischer Geschäftseinheiten](anhand Informationsbedarf und Informationsaufkommen) 

• IS Management (Daten, Prozesse, Anwendungslebenszyklus; scenario und stories; application case; eingesetzte 

und einsetzbare Systeme) 

• Management der Inf.- und Kommunikationstechnik (IT-Infrastruktur, Netze, Kommunikationssysteme; System- 

Landschaft; Speicherung, Verarbeitung, Kommunikation, Technikbündel) 

IS ADD


Sichten auf das Informationsmangement. 

Gestaltungsobjekte des IM: IT Strategie, IS, Anwendungen, IT-Infrastruktur Sichten: 

• Führung (Leitungshandeln: Strategisch, taktisch - admininistrativ[besser], operativ; dazu auch IT Governance, 

Geschäftsproz./Daten-/Life cylce management; ), 

• Inf als Produktionsfaktor (Inf. resources management), 

• Inf. als Produkt (ITIL, IT-Produktportfolio,...), 

• persönliches IM (Ziele der Person am Arbeitsplatz, invidueller Umgang mit Information, IS,Anwendungen) 

• IS-Managment (Information engineering)(Info.-modellier., Architekturentwurf, Systems Landscape, Vorgehensmodelle, 

ARIS, ...) 

• IT-Management (IT service management, IT service portfolio) 

Ansätze. 

• problemorientiert (Applegate, Benson/Parker), 

• ebenenorientiert (Wollnick, 88: Einsatzebene, IK-Systeme, Infrastruktur; Anforderung und Unterstützungsleistung), 

• aufgabenorientiert (Heinrich, 2002; strategische, administrative, operative; Aufgaben - Methoden), 

• prozeßorientiert, produktorientiert (Zarnekow, 2004; IT-Leistungserstellung als Leistungserbringung (source,make, 

deliver) in der Wertschöpfungskette), 

• architekturorientiert (Zachman, Scheer, Krcmar) 

5.1 Daten ≠ Information ≠ Wissen ≠ Daten 

5.1.1 Was ist Information? 

Was ist wirklich Information?. 

There are many definitions for information. [?] uses seven different meanings: 

1. Knowledge derived from study, experience, or instruction. 

2. Knowledge of specific events or situations that has been gathered or received by communication; intelligence 

or news. 

3. A collection of facts or data: statistical information. 

4. The act of informing or the condition of being informed; communication of knowledge. 

5. Computer Science: Processed, stored, or transmitted data. 

6. A numerical measure of the uncertainty of an experimental outcome. 

7. Law: A formal accusation of a crime made by a public officer rather than by grand jury indictment. 

1003 Spanierinnen hat Don Giovanni (Mozart) verführt 

beeindruckende Liste: fast 10.000 Frauen verführt, d.h. wenn täglich, dann schon 27 Jahre im Dienst 

IS ADD


1003 Vogel Story: die Kunst des Zählens 

H. Jaak (Estland): jemand beobachtet viele, viele (≈ 1000) Vögel, danach auch noch 3 Vögel, damit also 1003 

Vögel 

Cern: 1 Petabyte täglich 

1750 Exabyte an digitalen Daten schätzt International Data Corporation (IDC) research für 2011 

Google weiß alles ☺ 

bei 11.5 % Überdeckung ☻ 

Google sagt alles, was Google weiß oder vielleicht nicht? 

im 5-Computer-Test an CAU ☹ 

Wir sind bereits in Informationen ertränkt! Wir brauchen stattdessen: 


zur rechten Zeit, 

der richtigen Sorte, in der richtigen Dosis, in der richtigen Form, 

in vollem Umfang und 

zu akzeptablen Kosten 

für alle Benutzer (bzw. Anwendungen) 

Vergiß nicht den Unterschied zwischen Information und Daten: 

Kiteigorodski’s These zu Veröffentlichungen. 

Auswahl des fehlenden Wissens im Ozean von Daten 

Generieren ist leichter als Qualitätspflege. 

T. S. Eliot (1888-1965), The 

rock, 1934: 

Where is the wisdom we have lost in knowledge? 

Where is the knowledge we have lost in information? 

β 1998: 

Where is the information we have lost in news? 

Where is the information we have lost in data? 

M. Burgin [Bur10]: Information hat Vermögen, den internen Zustand eines Systems zu ändern, und ist Verursacher 

dieser. 

Information: nicht einfach ‘Mikro’-Wissen oder eine Menge von Daten 

Datum: Folge von Symbolen 

Nachricht: übermittelte Daten, oft mißbraucht, vorinterpretiert, manipuliert 

Wissen: validierbare, nachhaltige Daten im begründeten Consensus der Gemeinschaft 

zusammengefaßte, kondensierte, dynamische Fakten (Daten) und Regeln 

Information ≈ gedeutete 

Nachrichten ∨ Daten ∨ Mitteilungen 

als dritter Stoff neben Materie und Energie 

Daten 

Empfänger 

Auswahl 

Kontext 

Verarbeitung 

Integration 

IS ADD


Syntactic, semantic, pragmatic and anthopomorphic definition of information. 

We can categorize the definitions given above into three groups: 

• The first syntactic category of these definitions is based on the mathematical notion of entropy. This notion is 

independent of the user and thus inappropriate in our context. 

• The second semantic category of information definitions bases information on the data a user has currently in 

his data space and on the computational and reasoning abilities of the user. Information is any data that cannot 

be derived by the user. This definition is handy but has a very bad drawback. Reasoning and computation cannot 

be properly characterised. Therefore, the definition becomes fuzzy. 

• The third speech-act-oriented pragmatic category is based on the general language understanding of information 

[SYea03]. 

Information is either the communication or reception of knowledge or intelligence. 

Information can also defined as 

• knowledge obtained from investigation, study, or instruction, or 

• intelligence, news or 

• facts and data. 

Information can also be the act of informing against a person. 

Finally information is a formal accusation of a crime made by a prosecuting officer as distinguished from an 

indictment presented by a grand jury. 

All these definitions are too broad. 

We are thus interested in a definition that is more appropriate for data, information and knowledge management. 

The general notion of information. 

“In—for—ma—ti—on die; -en über spätlateinisch informatio ‘Bildung durch Unterricht, Belehrung’ aus lateinisch informatio 

‘Vorstellung, Erläuterung’ [...]: 

1.a) Nachricht, Auskunft; das Informieren; Unterrichtung über eine bestimmte Sache; 

b) [auf Anfrage erteilte] über alles Wissenswerte in Kenntnis setzende, offizielle, detaillierte Mitteilung über jemanden, etwas; 

c) (meist Plural) Äußerung oder Hinweis, mit dem jemand von einer [wichtigen politischen] Sache in Kenntnis gesetzt wird; 

d) Kurzform für Informationsstand, -stelle. 

2. (Plural selten) 

a) [Maß für den] Informationsgehalt einer Nachricht; 

b) als räumliche oder zeitliche Folge physikalischer Signale, die mit bestimmten Wahrscheinlichkeiten auftreten, sich zusammensetzende 

Mitteilung, die beim Empfänger ein bestimmtes [Denk]verhalten bewirkt (Informatik) [...]” (nach Fremdwörterbuch) 

“Information (vom Lateinischen informatio, d.h. Deutung, Erläuterung) bedeutet im Sinne der Umgangssprache Wissen 

(Kenntnisse) über Sachverhalte oder Vorgänge. Elemente zur Darstellung von Informationen heißen Zeichen. Der Zeichenvorrat 

wird durch die Menge der vereinbarten Elemente gebildet. Ein linear geordneter Zeichenvorrat wird als Alphabet bezeichnet. 

Die Kombination von Buchstaben ergibt Text, die von Ziffern ergibt Zahlen. Aus Zeichen gebildete Informationen zum Zweck: 

* der Verarbeitung heißen Daten 

* der Weitergabe heißen Nachrichten.” 

http://www.businessdictionary.com/definition/information.html 

There are many different definitions of the concept of information. We distinguish between data, information, 

knowledge, and messages. In our context it is common to think of information as consisting of data. 

IS ADD


Rohdaten 

(wohlgeformte) 

Daten 

kontextbehaftete 

Daten 

semantische 

Daten 

(Inhalt) 

storybezogene 

Daten 

z.B. instruktionelle 

wahre und 

bedeutungsvolle 

Daten 


Faktendaten 

falsche oder 

bedeutungsarme 

Daten 

In general, information is 

• raw data and 

• well-formed data 

• that 

intentional 

falsche 

Daten 

Desinformation 

unintentional 

falsche 

Daten 

Mißinformation 

(1) has been verified to be accurate and timely relative to its context, 

(2) is specific and organized for a purpose, 

sinnfreie 

Daten 

Rauschen 

(3) is presented within a context that gives it meaning and relevance, and which 

(4) leads to increase in understanding and decrease in uncertainty. 

This notion extends the GDI notion (General Definition of Information) [?]. “Well-formed” means that the raw data 

are clustered together correctly, according to the rules (syntax) that govern the chosen system, code or language 

being analysed. Syntax is understood broadly, as what determines the form, construction, composition or structuring 

of something. “Meaningful” means that the data must comply with the meanings (semantics) of the chosen system, 

code or language in question. We refer to [35] for different kinds of semantics. However, let us not forget that semantic 

information is not necessarily linguistic. For example, in the case of the manual of the car, the illustrations are such 

as to be visually meaningful to the reader. 

Information situations. 

This information definition covers a broad variety of informational situations. Typical such situations are the 

following: 

Business information systems: Information is data that have been shaped into a form that is meaningful and useful 

for human beings. These data satisfy an information demand and can be understood by this group. Typical data 

represent information about significant people, places, and things within an organisation or in the environment 

surrounding it. 

Speech act: see Searle 

Conception development: see Bolzano Auffassung 

IS ADD


The value of information lies solely in its ability to affect a behavior, decision, or outcome. A piece of information 

is considered valueless if, after receiving it, things remain unchanged. For the technical meaning of information we 

consider the notion used in information theory. 

Therefore, information is directed towards pragmatics, whereas content may be considered to highlight the syntactical 

dimension. If content is enhanced by concepts and topics, then users are able to capture the meaning and the 

utilisation of the data they receive. In order to ease perception we use metaphors. Metaphors may be separated into 

those that support perception of information and into those that support usage or functionality. 

The information theory notion of information 

Entropie der eingegebenen Nachricht Information as a message 

‘Information’ - vielseitig belegt 

Ereignisse untereinander in Beziehung gesetzt unter Gesichtspunkt inwieweit Unsicherheit verringert wird 

Absteckung des Möglichen 

Kybernetische System- und Modelltheorie: Information ist neues Wissen über ein Ereignis, einen Tatbestand oder 

einen Sachverhalt, Information ist Beseitigung von Ungewissheit. [...] Information ist jede Folge oder Anordnung von 

Zeichen (Signalen), die mit bestimmten Häufigkeiten auftreten, denen eine Bedeutung beigemessen werden kann, und 

die einen Adressaten zu einem bestimmten Verhalten veranlassen können. 

Mit dem Satz “Information is information nor matter or energy” führt Norbert Wiener die Information als 3. 

Grundgröße neben Materie und Energie ein. 

Wahrscheinlichkeitstheoretische Sicht von Informationen 

Gegeben ist eine Zufallsvariable a = (a 1 , ..., a n ) p(a i ) Wahrscheinlichkeiten des Eintreffens von a i 

a - Ausschnitt aus Menge der möglichen Ereignisse 

Informationsgehalt des Wertes a i der Zufallsvariablen a : 

Unsicherheit, die durch das tatsächliche Eintreffen von a i beseitigt wird 

Nichtereignis versus Ereignis 

Formalisierung durch Maß I(a i ) mit folgenden Anford. 

• I(a i ) = f(p(a i )) 

• f ist stetig in [0,1] 

• f ist antiton (wahrscheinlichere Ereignisse enthalten weniger Information) 

• Informationsgehalt ist additiv: f(p 1 ∗ p 2 ) = f(p 1 ) + f(p 2 ) 

⇒ dadurch ist I bis auf Konstante eindeutig festgelegt 

Informationsgehalt von einem einzelnen Wert a i 

falls p(a i ) = 1 , dann keine Unsicherheit beseitigt 

1 

I(a i ) = −ld(p(a i )) = ld( 

p(a i ) ) falls p(a i) ≠ 0 

wird nun der gesamte Informationsgehalt der Zeichen von a betrachtet, d.h. 

H(a) = 

n∑ 

n∑ 

p(a i )I(a i ) = − p(a i ) ld(p(a i )) 

i=1 

i=1 

ist der mittlere Informationsgehalt von a (Entropie) 

IS ADD


durch weitere Ausnutzung der WMS-Grundlagen 

angewandt auf Übertragung von Signalen 

Sender Kanal −→ 

Empfänger 

bedingte Wahrscheinlichkeiten, unabhängige Zufallsgrößen, ... 

z.B. H vor (x|y) und H nach (x|y) Unsicherheiten von x unter y vor und nach Ausführung 

D(x, y) := H vor (x|y) − H nach (x|y) übertragene Information 

Eingegebener Text : blabla blublu blibli bleble blable blabli blablu 

Textlänge : 50 

mittlerer Informationsgehalt : 2.6840558737174 

http://abenteuer.hpfsc.de/entropie.php 

Eingegebener Text : blabla 

Textlänge : 9 

mittlerer Informationsgehalt : 2.5032583347756 

Beispiel Nachrichten: 

Nummer Nachricht Entropie der Nachricht 

1. To be or not to be! 2.9000516989995 

2. Sein oder nicht sein! 3.4866245652238 

3. Etre ou ne pas etre! 3.4841837197792 

4. A aaab b cbde def! 2.9749375012019 

Obwohl die Nachrichten 1 bis 3 alle den gleichen Inhalt haben, ist der Informationsgehalt unterschiedlich. Auch 

der völlig sinnlose Nachricht 4 soll den gleichen Informationsgehalt haben, wie das Shakespeare Zitat. 

An diesem kleinen Beispiel sieht man, daß die Entropie einer Nachricht keine Aussage über die Menge an Information 

trifft. Es ist lediglich eine Aussage über die Häufigkeit einzelner Zeichen in der Nachricht. 

The infological definition of information 

Modelltheoretische Sicht von Informationen 

Klasse K von Strukturen gegeben (M = (D, r 1 , ..., r n ), r i τ i -stellige Relationen) 

“Ereignisse” werden durch FOPL-Formeln dargestellt 

Aussage entweder wahr oder falsch in M (falls wahr, dann M Modell von α) 

d.h. Mod K (α) = {M ∈ K | M |= α} ⊆ K 

bzw. Mod K (Φ) = ∩Mod K (α) 

falls Φ bekannt, dann unsicher, welches Modell vorliegt 

sicher, fall ||Mod K (Φ)|| = 1 ; 

höchst unsicher, falls Mod K (Φ) = K 

Beispiel: S := if x ≥ 8 then y := 1 else y := 0 

nach Ausführung der Anweisung und bei Beobachtung von y verringert sich Unsicherheit über x 

w(eakest) p(recondition) {S} Φ 

x - Sender; y - Empfänger 

damit verändert der Informationsfluß von x nach y unsere Kenntnis über die Modellklasse 

mitunter ist auch Information redundant 

The business engineering and computer science definitions of information 

• Betriebswirtschaftslehre: Information (vom Lateinischen informatio, d.h. Deutung, Erläuterung) bedeutet im Sinne der 

Betriebswirtschaftslehre zweckorientiertes bzw. zielgerichtetes Wissen. 

IS ADD


• Informatik-Handbuch: Information ist handlungsbestimmendes Wissen über vergangene, gegenwärtige und zukünftige Zustände 

der Wirklichkeit und Ereignisse in der Wirklichkeit (d.h. in Organisationen in Wirtschaft und Verwaltung). 

• Lehrbuch Informatik: Information ist die Bedeutung, die durch eine Nachricht übermittelt wird. Klarerweise ist Information in 

diesem Sinne subjektiv. 

• Taschenbuch der Informatik: Information ist neues Wissen über ein Ereignis, einen Tatbestand oder einen Sachverhalt, 

Information ist Beseitigung von Ungewißheit. 

• Das geistige Umfeld der Informationstechnik: Information ist, was das Wort Information ausdrückt. Der Kern ist 

die Form, aber die Vorsilbe “in” weist auf den Inhalt der Form hin, auf die Bedeutung der Form. Information ist Form als Bedeutungsträger. 

Erziehung und Ausbildung (französisch: la formation) sind systematische Formierung; in diesem Sinn wurde das Wort 

Information verstanden, ehe die Technik davon Besitz ergriff. Man sollte an dieser Bedeutung schon festhalten, man sollte sie betonen 

und kultivieren, denn wer etwas mitteilt, auch wenn er dies über den Computer tut, hat mit Formierung und daher mit Ausbildung zu 

tun. Tatsächlich prägt der Computer mit seiner Information den Menschen, der sie erhält, und das bedeutet eine Verantwortung des 

Informatikers, die er nicht aus dem Blick verlieren darf. 

• Kybernetische System- und Modelltheorie: Information ist jede Folge oder Anordnung von Zeichen (Signale), die mit 

bestimmten Häufigkeiten auftreten, denen eine Bedeutung beigemessen werden kann, und die einen Adressaten zu einem bestimmten 

Verhalten veranlassen können. 

Information als zweckorientiertes Wissen (Heinrich: Informationsmangement) 

Resultierende Eigenschaften von Information: 

• immaterielles Gut, das sich auch bei mehrfacher Nutzung nicht verbraucht; 

• stiftet dem Benutzer Nutzen, z.B. bei Umsetzung in Handeln; 

• kein freies Gut; kann kostenadäquaten Wert haben; 

• Wert in Abhängigkeit von der kontextspezifischen und zeitlichen Verwendung; 

• Wert durch Modifikation (insert, ...) veränderbar; 

• kann erweitert und verdichtet werden; 

• unterschiedliche Qualitätsmaßstäbe (Genauigkeit, Vollständigkeit, ...); 

• kann mit Lichtgeschwindigkeit übertragen werden; 

• Käufer erhalten nur Kopien; exklusive Rechte sind schwierig; 

• kann kodiert übertragen werden. 

The anthroposophic notion of information 

Information as processed by humans, 

• is carried by data 

• that is perceived or noticed, selected and organized by its receiver, 

• because of his subjective human interests, originating from his instincts, feelings, experience, intuition, common 

sense, values, beliefs, personal knowledge, or wisdom, 

• simultaneously processed by his cognitive and mental processes, and 

• seamlessly integrated in his recallable knowledge. 

The general tasks of information management. 

We may summarise the different versions in the following table: 

Dimensions 

Characteristics 

Semiotics syntax semantics pragmatics 

Carrier independent human-based 

Novelty subjective objective 

Faithfulness dependent on truth independent from truth 

Timeliness static procedural 

IS ADD


[?] 

Dimensions of Information Quality. 

actuality 

value 

creation 

accessible 

processable 

system supported 

high 

reputation 

free from 

errors 

complete 

purpose 

dependent 

IQ 

inherent 

appropriate 

size 

relevance 

presentation dependent 

surveyable 

standardised 

understandability presentation 

definite 

interpretation 

objective 

faithful 

Abbildung 1: The 15 dimensions of information quality within the 4 categories 

The user dimension of information management. 

Users are reflected by actors that are abstractions of groups of users. Pragmatics and syntactics share data and functions. 

The functionality is provided through functions and their representations. The web utilisation space depends on 

the technical environment of the user. It is specified through the layout and the playout. Layout places content on the 

basis of a data representation and in dependence of the technical environment. Playout is based on functionality and 

function representations, and depends on the technical environment. 

sender 

content 

presentation 

receiver 

appeal to 

message 

s-r-relationship 

receiver 

Abbildung 2: Dimensions of understanding messages 

The information transfer from a user A to a user B depends on the users A and B, their abilities to send and to 

receive the data, to observe the data, and to interpret the data. Let us formalise this process. Let s X denote the function 

user by a user X for data extraction, transformation, and sending of data. Let r X denote the corresponding function for 

data receival and transformation, and let o X denote the filtering or observation function. The data currently considered 

by X is denoted by D X . Finally, data filtered or observed must be interpreted by the user X and integrated into the 

knowledge K X a user X has. Let us denote by i X the binary function from data and knowledge to knowledge. By 

default, we extend the function i X by the time t iX of the execution of the function. 

Thus, the data transfer and information reception (or briefly information transfer) is formally expressed it by 

I B = i B (o B (r B (s A (D A ))), K B , t iX ) . 

In addition, time of sending, receiving, observing, and interpreting can be taken into consideration. In this case 

we extend the above functions by a time argument. The function s X is executed at moment t sX , r X at t rX , and o X at 

t oX . We assume t sA ≤ t rB ≤ t oB ≤ t iB for the time of sending data from A to B. The time of a computation f or 

IS ADD


data consideration D is denoted by t f or t D , respectively. In this extended case the information transfer is formally 

expressed it by 

I B = i B (o B (r B (s A (D A , t sA ), t rB ), t oB ), K B , t iB ) . 

The notion of information extends the dimensions of understanding of message displayed in Figure 2 to a web 

communication act that considers senders, receivers, their knowledge and experience. Figure 3 displays the multilayering 

of communication, the influence of explicit knowledge and experience on the interpretation. 

The communication act is specified by 

• the communication message with the content or content chunk, the characterisation of the relationship between 

sender and receiver, the data that are transferred and may lead to information or misinformation, and the 

presentation, 

• the sender, the explicit knowledge the sender may use, and the experience the sender has, and 

• the receiver, the explicit knowledge the receiver may use, and the experience the receiver has. 

experience 

✲ 

data 

✲ 

experience 

explicit 

knowledge 

sender 

✲ 

data 

(information, misinformation) 

form 

appearance, 

gestalt 

presentation 

communication 

act 

sender-receiver relationship 

✲ 

appeal to 

receiver 

explicit 

knowledge 

receiver 

Abbildung 3: Dimensions of the communication act 

We approach the analysis of knowledge system usage as the first important part of storyboarding pragmatics. 

Knowledge system usage analysis consists of three parts: 

1. Life cases capture observations of user behaviour in reality. They can be used in a pragmatic way to specify the 

story space. The work on life cases was reported in a previous publication [33]. 

2. User models complement life cases by specifying user and actor profiles, and actor portfolios. The actor portfolios 

are used to get a better understanding of the tasks associated with the knowledge system. The work on 

user models was reported in a previous publication [34]. 

3. Contexts complement life cases and user models by characterising the situation in which a user finds him/herself 

at a certain time in a particular location. We classify various aspects of contexts related to actors, storyboard, 

system and time, which make up the context space, then analyse each of these aspects in detail. This is formally 

support by lifting relations. 

User modelling is based on the specification of user profiles that address the characterisation of the users, and the 

specification of user portfolios that describe the users’ tasks and their involvement and collaboration on the basis of 

the mission of the knowledge system [30]. 

To characterize the users of a knowledge system we distinguish between education, work and personality profiles. 

The education profile contains properties users can obtain by education or training. Capabilities and application 

knowledge as a result of educational activities are also suitable for this profile. Properties will assigned to the work 

profile, if they can be associated with task solving knowledge and skills in the application area, i.e. task expertise 

and experience as well as system experience. Another part of a work profile is the interaction profile of a user, which 

is determined by his frequency, intensity and style of utilization of the knowledge system. The personality profile 

IS ADD


characterises the general properties and preferences of a user. General properties are the status in the enterprise, 

community, etc., and the psychological and sensory properties like hearing, motoric control, information processing 

and anxiety. 

A portfolio is determined by responsibilities and is based on a number of targets. Therefore, the actor portfolio 

(referring to actors as groups of users with similar behaviour) within an application is based on a set of tasks assigned 

to or intended by an actor and for which s/he has the authority and control, and a description of involvement within 

the task solution [32]. A task as a piece of work is characterized by a problem statement, initial and target states, 

collaboration and presupposed profiles, auxiliary conditions and means for task completion. Tasks may consists of 

subtasks. Moreover, the task execution model defines what, when, how, by whom and with which data a task can 

be accomplished. The result of executing a task should present the final state as well as the satisfaction of target 

conditions. 

For task completion users need the right kind of data, at the right time, in the right granularity and format, 

unabridged and within the frame agreed upon in advance. Moreover, users are bound by their ability to verbalise 

and digest data, and their habits, practices, and cultural environment. To avoid intellectual overburdening of users 

we observe real applications before the system development leading to life cases [33]. Life cases help closing the 

pragmatic gap between intentions and storyboarding. They are used to specify the concrete life situation of the user 

and characterise thus a bundle of tasks the user should solve. Syntax and semantics of life cases have already been 

well explored in [30]. 

In addition, each user has an information portfolio, which specifies the information needs as well as the information 

entered into the system. We do not model the information portfolio as part of a user, but instead of this we will 

model the information “consumed” and “produced” with each more detailed specification of a user request. 

Other notions of Information. 

Tom Stonier proposed [Sto90], that information is a part of the physical universe the same way as matter and 

energy. Degree of organization of a system is a measure of its information. 

This idea has been exploited by Creationists, who claim that similarly to energy and mass conservation laws 

there is a law of conservation of information - information cannot be created by either natural processes or chance 

[Dem99, DI09]. Creationists use this proposed by them law to claim that Darwinian Evolution could not create the 

myriads of Biological Information, Darwinian selection often significantly outperforms blind search, so it has to use 

some outside information supplied by some Creator. 

But new information is created all the time in increasing temp. The International Data Corporation (IDC) research 

reported already in 2008 that the total amount of digital information in 2007 reached 281 billion gigabytes or 281 exabytes; 

the estimate for the end of 2011 is already 1750 exabytes [Cuk10]. CERN experiments generate one petabyte 

of data every second [Hena]. Therefore the claims of Creationists and their apologete Dembski looks rather dubious: 

“Dembski’s work is riddled with inconsistencies, equivocation and flawed use of mathematics... [ES03, Wal05]. 

K Haefner postulated [Hef92], that all natural systems are Information Processing Systems (IPS); each IPS can 

receive, store, process and transmit information; information processing is an essential internal feature of all systems; 

the whole universe may be viewed as a gigantic IPS. Information is a system variable and we should distinguish 

between system’s internal information which is an essential component of every natural system and external information, 

which is communicated between systems and measured by some external measuring system. Physics and 

biology are interested (mainly) in internal information; Information Technology (IT) - in external information, which 

is communicated using structured signals. This distinction is rather arbitrary, e.g. genes communicate organism’s 

internal structural information between generations using sequence of nucleotides. 

The claim of omnipresence of information is close to the ideas expressed by Konrad Zuse already in 1969. Zuse 

proposed, that the whole universe is being computed by some automaton, everything is just a computation [Zus69]. 

Nobody has yet shown any flaws in Zuse’s argumentation; on the contrary, distinguished physicist and information 

theorist John Wheeler, who introduced the term ’black hole’ explained his another phrase ‘It from bit’ with “things 

physical are information-theoretic in origin” [WZ90]. 

IT specialists often claim that all essential concepts of Information Theory were presented already by C. Shannon 

in his groundbreaking paper “The Mathematical Theory of Communication” [Sha48], e.g. Bell’s laboratory homepage 

claims: “Claude Shannon, the father of Information Theory...” [Henb]. But (as already the title of the Shannon’s paper 

IS ADD


shows) Shannon was speaking about communication, where are used signals with pre-known characteristics, which 

are known both to sender and receiver. Such a system of signals can carry information, but here semantic aspects of 

communication are irrelevant, considered is only the engineering aspect - syntax of signals. Signals have structure 

and preservation of this structure may be interpreted as “information”, but for this both sender and receiver interpret 

signals according to their semantic models of the subject area. Thus this is only a very limited aspect of the concept 

“information”. When Wiener made his statement he was aware of Shannon’s work; Shannon himself explained much 

later very carefully: “It is hardly to be expected that a single concept of information would satisfactorily account for 

the numerous possible applications of this general field”[Sha93]. 

M. Burgin defines information as a “phenomenon that exists in nature, society, mentality of people, virtual reality 

and in artificial world of machines and mechanisms created by people; information for a system is a capacity to cause 

changes in the system” [Bur10]. This is rather broad and vague definition - hit with axe also causes changes in hit’s 

target, but (usually) we do not consider physical contact as transfer of information. Another contradicting example: 

all physical objects radiate electromagnetic waves; living creatures (e.g. humans) can perceive (a very restricted) 

range of this radiation as a visual image which definitely gives them information about the object; cameras (both the 

classical film-based and modern digital) also record images, but we do not claim, that they received information. 

The difference between living things and photographic camera is in change of their behavior. Living things use 

received information (images) in their future acts, they learn something from images; cameras act in the future exactly 

the same way as they did before. Living things and learning robots use information in order to modify their conceptual 

model of the environment. This observation gives the ground for defining information (stored in a message) as the 

(probabilistic) measure of change what the message can cause in the conceptual structure of receiver. The free-energy 

principle, which possibly can explain the major mechanisms of brain [Fri10] introduces the idea that information can 

be considered as a form of energy and life can be viewed as highly condensed form of information [JI]. 

Understanding information as an active agent which changes perceiving system’s (systems, capable to learn) 

state makes clear, that all perceptions: images, sounds/music, tactile perceptions etc carry information. But in our 

digital age all information is digitized and handled on network, what makes handling many times cheaper. Therefore 

it is inevitable, that structures which are based on physical encodings, e.g. the publishing and music industries are 

doomed. For music this turn to digitized distribution has been active for more than ten years already and in 2010 

Amazon was selling far more digitized texts than paper and hardback books combined [Henc]. 

With overall digitalization, many concepts are more and more considered and handled as a special kind of information. 

One example is money. Money is a specific type of information: information about value, which is created/assigned 

by human society. Monetary values are expressed numerically and the classical encoding for them is 

physical - coins and banknotes. Specialized institutions to deal with this information - banks - eliminated need for 

face-to-face encounters of sides of a deal - you went to bank to pay a bill. In Internet age you can do this from your 

computer at home - most of banks nowadays provide customers with Internet banking software. Digital encoding 

of money is simpler and cheaper and many banks are already implementing a purely digital, cashless systems and 

refusing to deal with banknotes and coins; there have also appeared internet-only banks, which do not have physical 

offices. The need for home computers with banking software is also disappearing, all kind of information exchange 

including monetary is more and more done using mobile phones. In Estonia mobile payments have been possible for 

over ten years - first for services with fixed praises (parking, cinema thickets etc), but from 2002 also for all banking 

activities - a mobile phone (with special SIM card) can be used the same way as your bankcard. There are rapidly 

appearing mobile phone applications enabling mobile payments and money transfer, e.g. The Ericsson Money [Hend] 

makes money transfer around the world as easy as sending a SMS; DaoPay [Hene] ] enables real-time mobile payments 

from more than 200 countries etc. In longer perspective it is quite probable, that future of the banking system 

will be similar to the (current) future of music and publishing industry - its significance will be greatly reduced, the 

(mobile) network will be the big bank. 

5.1.2 Was ist Wissen? 

Knowledge for the Knowledge Web. 

The Knowledge Web goes beyond Web 1.0, Web 2.0 and Web 3.0. Nowadays, large amounts of Web contents 

IS ADD


are being distributed on the Internet. Conventional search engines are not useful for analyzing the relations between 

related knowledge since a number of Web contents may indicate a similar concept by different words. Users search 

Web pages for different purposes, such as for education, for accessing information on current affairs, or for gaining 

knowledge.We believe that the next-generation Web connects each page with not only conventional hyper links but 

also knowledge links. The knowledge link has to be created by novel knowledge processing technologies. The technologies 

consist of knowledge gathering, storage, and delivery technologies. An approach to knowledge modelling, 

knowledge management, knowledge distribution, and analysis technologies has been proposed on [TKKJ11]. This 

approach is oriented towards building the next-generation Web, named Knowledge Web. 

Knowledge web provides knowledge to the user at the right moment of time, in the right format thus allowing 

the user to understand the knowledge given, in a form the user requested, the right size and structuring, and under 

consideration of the user’s information demand. The central notion is the notion of knowledge. According to 

[TKKJ11, KZK + 10] we distinguish different kinds of to know 

1. The state or fact of knowing. 

2. Familiarity, awareness, or understanding gained through experience or study. 

3. The sum or range of what has been perceived, discovered, or learned. 

4. Learning; erudition: teachers of great knowledge. 

5. Specific information about something. 

6. Carnal knowledge. 

This distinction allows to consider two sides of knowledge: 1 is one of overused terms. It can be considered as knowledge in 

general defined by a noun and the knowledge by a user expressed by the verb ‘to know’. 

Knowledge as sustainable, evolving, potentially durable and verifiable grounded consensus: The required data 

chunk can be qualified as knowledge, if it 

1. is consensus within a world and a community, 

2. is based on postulates or principles that create the fundament for the knowledge, 

3. is true according to a certain notion of ’truth’, 

4. it is potentially evolving within an ordered evolution/aging process, 

5. is reusable in a rule system for new information, 

6. is has a longer lifespan and exists with persistent validness, 

7. has an effect and is sustaining within a society, community or world, and 

8. is not equivalent to other information that can be generated with the aid of facts or preliminary information 

in the particular inventory of knowledge by a rule system. 

1 The definition provided by the Encyclopedia Britannica [SYea03] considers two ‘Janus’ meanings beside the obsolete ‘cognizance’ and 

the archaic ‘sexual intercourse’: 

(I) as the fact of knowing something: 

(Ia1) the fact or condition of knowing something with familiarity gained through experience or association; 

(Ia2) acquaintance with or understanding of a science, art, or technique; 

(Ib1) the fact or condition of being aware of something; 

(Ib2) the range of one’s information or understanding; 

(Ic) the circumstance or condition of apprehending truth or fact through reasoning or cognition; 

(Id) the fact or condition of having information or of being learned; 

(II) the body of things known about or in science: 

(IIa) the sum of what is known: the body of truth, information, and principles acquired by mankind; 

(IIb) a branch of learning (synonyms of knowledge: learning, erudition, scholarship) meaning what is or can be known by an individual or by 

We prefer this approach over the approach taken by the Wikipedia community who distinguishes between communicating knowledge, 

situated knowledge, partial knowledge, scientific knowledge and know-how or know-what or know-why or know-who knowledge. 

IS ADD


Knowledge as the state of information of a user: Different kinds of ‘to know’ are for a human: 

1. The state or fact of knowing. 

2. Familiarity, awareness, or understanding gained through experience or study. 

3. The sum or range of what has been perceived, discovered or learned. 

4. Learning; erudition: teachers of great knowledge. 

5. Specific information about something. 

6. Carnal knowledge. 

The Quality Characteristics of Knowledge. 

It is surprising that the literature treat knowledge as a 100 % quality criterion. We can however distinguish between 

validated knowledge that satisfiable within a scope of axioms and derivation rules (application domain), within a 

certain generality and has validity and timelineness, 

verified and correct knowledge based on axioms and rules within a proof system that can be verified within a finite 

time, obey a correctness criteria (depending on profiles) and has some known interaction with other knowledge, 

and finally 

sustainable and enduring knowledge that has a lifespan beyond volatile data and is torpid for a certain lifespan, 

quality knowledge defined by the quality of use (understandability, learnability, operability, attractiveness, appropriatedness), 

by the external quality (privacy, ubiquity, pervasiveness, analysability, changeability, stability, testability), 

and by the internal quality (accuracy, suitability, interoperability, robustness, self-contained/independence). 

We additionally may consider the user dimension. In this case the following requirements are added: 

Potentially useful knowledge depends on a user, group or community or a culture and satisfies a number of quality 

criteria in dependence in the knowledge demand of these users. 

Ultimately understandable knowledge depends on the cognitive abilities of users, groups or communities. 

These quality characteristics result is differences of the value of knowledge for the user. 

Quality is thus characterised by certain main characteristics. These characteristics can be ordered within the 

following tree: 

Knowledge 

Quality 

Probable 

Validatable 

Correctness Testability 

Provability 

Conditions of validity 

Generality 

Range of validity 

Power for reasoning 

Usefulness Relevance 

Realisability 

Simplicity 

Coherence 

Comprehensibility 

Clarity 

Parsimony 

Not deductable 

Novelty Unexpected 

Previously unknown 

We may also observe that these quality characteristics are of different value and importance depending on the needs 

of the user. We may differentiate knowledge depending on 

IS ADD


• the role of the user such as learner, teacher, scientist, writer, etc., 

• the application area such as sciences, engineering, daily life, 

• the timeliness of the information depending on the needs, 

• the background necessary for transferring the data to the users information space, the users recognition and 

perception abilities, the users attention and interest, the users processing abilities, and the users abilities to 

integrate the data into his or her information space. 

For instance the quality characteristics of of very different importance. Compare for instance the following two 

opposite evaluations 

Economist: 

Scientist: 

Knowledge 

quality 

Correctness 

Generality 

Usefulness 


Novelty 

Probable 

Validatable 

Testability 

Provability 




Relevance 

Realisability 


Unexpected 


Simplicity 

Coherence 

Clarity 

Parsimony 

Knowledge Systems Environments. 

Knowledge 

quality 

Correctness 

Generality 

Usefulness 


Novelty 

Probable 

Validatable 

Testability 

Provability 




Relevance 

Realisability 

Simplicity 

Coherence 

Clarity 

Parsimony 


Unexpected 


Knowledge infrastructures are a hot research and technology concern nowadays. A good number of research 

issues are still open. The panel discussion at EJC 2011 highlighted some of them. 

• Knowledge infrastructures rely on novel system architectures. These systems must be developed under incorporation 

of new software systems engineering approaches that include a continuous quality management for 

the knowledge chunks after they have been developed. This kind of continuous assessment is novel. 

At the same time we can contribute to such infrastructures with a sophisticated incorporation of technologies 

that have been developed within the web and database communities. 

• The integration of data acquisition, data processing and data publication within any communication tool 

is backed by classical database technology and benefits from novel technologies that have been proposed 

for Web x.0 application. 

• Knowledge system environments are provisioning knowledge from different sciences and thus are dependent 

on the specific form of the knowledge within these areas. This separation is however supported by 

domain-specific software development for knowledge societies. 

• Knowledge systems will not be monolithic and are based on a network of collaborating computers. This 

trend is supported techniques such as modularisation and parallelisation. 

• The internet does not provide a 7-24-60-60 access mode to all its resources. Some of the resources might 

reachable at certain time points. Therefore, knowledge systems environments must also provide tools that 

increase security and dependability of knowledge sources with awareness of web insecurity. 

• Knowledge might be general knowledge that is available to everybody or knowledge that is under development 

or knowledge of a certain community. The last two cases require that knowledge systems 

environments must also support knowledge privacy. 

• Semantic technologies from the social web, semantic web, future internet offer a lot of opportunities for a 

knowledge society. The internet has sometimes considered to be a large database of content. This database is 

however neither well-structured nor well-edited. There are sources that have been copied from other sources 

IS ADD


which got their own evolution. There are sources of any kind of quality. There is doubtful, completely speculative, 

outdated or incomplete content. If a society relies on such sources then quality management becomes a 

critical issue. 

We may separate concerns for coherent and well-supported knowledge management in a form that is displayed 

in Figure 4. This separation is based on the quality characteristics for knowledge. 

accessible 

processable 

actuality 

value 

creation 

complete 

appropriate 

size 

purpose 

dependent 

system supported 

knowledge 

quality 

presentation dependent 

relevance 

surveyable 

standardised 

understandability presentation 

inherent 

definite 

interpretation 

high 

reputation 

free from 

errors 

objective 

faithful 

Abbildung 4: The 15 dimensions of knowledge quality within four categories 

• Knowledge management can be based on principles. The following eight principles can be considered to be 

the central ones: 

• Principle 1: Ensure the knowledge we collect meets business needs and priorities. Management only 

collects knowledge that has a clear purpose. Given our finite resources we will prioritise investment to 

areas that best support the projects’s strategic directions and key operational requirements. 

• Principle 2: Minimise the cost and burden of knowledge capture. Management reduces the cost of collection 

and the burden on clients and providers by capturing knowledge once and once only, using the best 

available tools and technologies. 

• Principle 3: Get the best value from knowledge. Management enhances the value of its investment in 

knowledge by sharing knowledge, making it accessible, using it productively and managing it efficiently. 

• Principle 4: Produce quality knowledge. The knowledge are of a quality which makes it fit for purpose. 

This encompasses issues of: relevance, completeness, accuracy, timeliness and accessibility. 

• Principle 5: Provide knowledge integration. Knowledge are typically kept in a distributed form based on 

different formats, abstraction, granularity, quality and maintenance. Architectures, application of abstractions, 

common access and usage orientation are means for providing a holistic view on the knowledge 

massive. 

• Principle 6: Protect and preserve knowledge. Knowledge is managed with due care and diligence throughout 

the knowledge life cycle to ensure that it is protected and preserved in accordance with legislative 

and policy requirements, such as the Information Privacy Act and Victorian Electronic Records Strategy. 

• Principle 7: Enable good practices - Competencies Management staff members have the necessary skills, 

knowledge and experience to perform their knowledge management responsibilities. 

• Principle 8: Enable good practices - Governance. Clear accountabilities, controls and coordinating mechanisms 

are in place and observed to ensure that knowledge is managed efficiently and effectively. 

Knowledge Web - Do We Have a Need for That?. 

IS ADD


Human often meet a situation in which additional information, knowledge or at least fact are urgently demanded. 

This knowledge on demand is however not uniquely determined. It depends on the user, the current user situation, the 

data on hand, the background, the policies of data providers, etc. 

Example (knowledge demand): Let us consider the large variety for knowledge demand of people after the Iceland 

EyJafjallajokull Glacier volcano eruption on March 20, 2010: 

• How long this situation will influence travel in Europe? Remember that the last Eyjafjallajokull eruption lasted 

for two years, and it is possible that this one will do the same. How weather conditions such as the anti-cyclone 

situation influence on ash spread? 

• What are the contents of ash? Could particles of rock, glass and sand clog up aircraft engines? What are the 

fears of the effect of volcanic ash on plane engines? Are there other components on aircraft that are equally 

sensitive to particles? Is driving more dangerous than flying through ash? As flights resume, how dangerous is 

it to fly through a volcanic ash cloud? Are the airlines right with their requirement to resume flights on manual 

control by pilots depending on visibility? Which safety tests showed that the engines could cope in areas of 

low-density ash? 

• Why mathematical simulations have been used for decision making? Why mathematics has partially failed in 

making predictions? 

• How the weather changes can be explained after the volcano eruption? Why scientist were incorrect in their 

prediction for the weather impact? (The European summer in 2010 was far colder than any prediction could 

foresee. This summer seems to be a counterexample for the climate change discussion. Watching the enormous 

plumes of dust and ash rising from Eyjafjallajokull, it is hard to imagine that this almost week-long eruption 

would not have any effect on weather and climate. But scientist expected that there is no change.) 

• What is the economical impact of such eruptions in general and of this eruption in special? What is the impact 

of the eruption for North Sea fishery, for industry, for tourism, etc.? 

• What are the passengers rights for stranded passengers or cancellations? What are the best sources of advice? 

How I can cope with my personal situation? E.g., who gets priority on seats now flights are running again? 

• Why icelanders enjoy their volcanos? 

• How clouds depends on volcanos and flights? Jet contrails are effectively acting as cirrus clouds, reflecting 

solar energy in the day, acting as a blanket by night. 

• Is there any correlation to other climate change drivers such as sun activity? What are the implications of 

ionospheric plasma bubbles? To what extent are sunspot activities related to economic cycles? 

This small list can be extended in many directions and illustrates the variety of knowledge that is necessary to satisfy 

the demand of people. 

Another examples (knowledge demand): 

Finance crisis: background, theories, causes, drivers 

Why economy science failed completely? 

deficiencies, state-of-the-art 

Why politicians applied the wrong approach? 

background, bindings 

Is bonus treatment the golden shot? 

prediction, restrictions 

Who is really ruling society and banks? 

science and reality 

Insiders on the crash and lessons learned. 

learned at all 

How the crisis unfolded and how stocks were hit? 

history beside news 

Has the economic recovery really started as yet? 

analysis 

‘The next crisis will make this one look like a warm-up.’ 

spending tax payers money 

How your money was spent on the bail-out? 

$ 11 trillion bailing out failing banks 

Find out how debt has soared in the crisis? 

cost of the financial meltdown 

How Fannie and Freddie sank the US housing market? 

complete picture 

A year of crisis 

history, state-of-the-art, consequences 

see for instance: 

http://news.bbc.co.uk/2/hi/in depth/business/2007/creditcrunch/default.stm 

IS ADD


Climate crisis: reasons for the climate change; scientific theories that explain parts and pieces; open issues 

Educated voter: tendency in Germany not to vote due to indistinguishability of parties; parties out of voters control; corruption 

in parties; no knowledge about real work of politicians and parliamentarians 

... and ... and ... and ... 

The example shows that we need different data, concepts, explanations, theories, and information. In general, 

knowledge system environments must support the following kinds: 

• state-of-the art, -affairs, -knowledge, -science; 

• deficiencies, missing or withhold facts; 

• background, scientific explanations, science, potential theories, analysis; 

• cross links, bindings; 

• associations; 

• facts with quality properties, full or partial picture; 

• predictions, possible tactics and strategies for the future; 

• restrictions, generalisation; 

• analogies; 

• history beside news; 

• ways to cope with and the outcome for the future; 

• consequences; 

• links with headlines and quality assessment. 

This list of knowledge pieces or chunks that must be provided can be categorized by the utility that the knowledge 

provides as follows: 

Orientation knowledge allows to cope with the situation, to explain, and to survey the history, the scenario, the 

facts, the summarisation or generalisation and the overall view. 

Tacit or action knowledge is based on practices, technics, methods, and strategies. It provides rules, procedures, 

check lists, principles, strategies, law, regulations, comments to regulations in order to manage situations. 

Explanation knowledge gives reasons, arguments for explanation of claims or arguments or assertions or recommendations 

(what, why,, ...). 

Sources knowledge links to knowledge on data sources (meta knowledge) such as knowledge on archives, references 

to communication, or cross links. 

Activity knowledge supports working, adaptation or processing, operating on analogies, and coping with errors. 

The Knowledge Delivery Task for Web 3.0 Knowledge Systems Environments. 

The knowledge delivery task of the Knowledge-Centered Web is defined as: 

Deliver the knowledge the user really needs through (1) concepts at the educational level level of the user that 

are illustrated and extended by (2) content which is quality content depending on the external and internal 

quality of the aggregated data (media object suite) and that are depicted by (3) topics in the language, in the 

culture and in the application portfolio of the user. 

Therefore, knowledge delivery and acquaintance for the user is user-oriented and life-case-based content, concepts 

and topics. 

IS ADD


Context Dimension Characterisation and Adaptation of Knowledge Delivery by Context. 

Taking the commonly accepted meaning a context [15] characterises the situation in which a user finds him/herself 

at a certain time in a particular location. In this sense context is usually defined only statically referring to the content 

of a database. Only very few attempts have been made so far to consider context of scenarios or stories. 

More generally, we consider context as everything that surrounds a utilisation situation of a knowledge system 

by a user and can throw light on its meaning. Therefore, context is characterised by interrelated conditions for the 

existence and occurrence of the utilisation situation such as the external environment, the internal state, location, 

time, history, etc. For knowledge systems we need to handle the mental context that is based on the profile of the 

actor or user, the storyboard context that is based on the story leading to a situation, the data context that is based on 

the available data, the stakeholder context, and the collaboration context. These different kinds of contexts have an 

influence on the development of the storyboard and must thus be considered for the development of the knowledge 

system. 

We distinguish the following facets of context [34, 33, 30]: 

Actor context: The knowledge system is used by actors for a number of tasks in a variety of involvements and well 

understood collaboration. These actors impose their quality requirements on the knowledge system usage as 

described by their security and privacy profiles. They need additional auxiliary data and auxiliary functions. 

The variability of use is restricted by the actor’s context, which covers the actor’s specific tasks and specific 

data and function demand, and by chosen involvement, while the profile of actors imposes exceptions. The 

involvement and collaboration of actors is based on assumptions of social behaviour and restrictions due to 

organisational decisions. These assumptions and restrictions are components of the actor’s context. 

Storyboard context: The meaning of content and functionality to users depends on the stories, which are based on 

scenarios that reflect life cases and the portfolios of users or actors. According to the profile of these users a 

number of quality requirements such as privacy, security and availability must be satisfied. The actor’s scenario 

context describes what the actor needs to understand in order to efficiently and effectively solve his/her tasks 

in the actual portfolio. The actor’s determine the policy for following particular stories. 

System context: The knowledge system is developed to support a number of intentions. The purposes and intents 

lead to a number of decisions on the knowledge system architecture, the technical environment, and the implementation. 

The knowledge system architecture has an impact on its utilisation, which often is only implicit 

and thus leads to not understandable systems behaviour. The technical environment restricts the user due to 

restrictions imposed by server, channel and client properties. Adaptation to the current environment is defined 

as context adaptation to the current channel, to the client infrastructure and to the server load. At the same 

time a number of legal decisions based on regulations, laws and business rules have been incorporated into the 

knowledge system. 

Temporal context: The utilisation of a scene by an actor depends on his/her history of utilisation. Actors may 

interrupt and resume their activities at any moment of time. As they may not be interested in repeating all 

previous actions they have already successfully completed, the temporal context must be taken into account. 

Due to availability of content and functionality the current utilisation may lead to a different story within the 

same scenario. 

Provider context: Providers are characterised by their mission, intentions, and specific policies. Additionally, terms 

of business may be added. Vendors need to understand how to run the knowledge system economically. Typical 

parts of this context are intentions of the provider, themes of the website, mission or corporate identity of 

the site, and occasion and purpose of the visits of actors. Thus, providers may require additional content and 

functionality due to their mission and policy. They may apply their terms of business and may require a specific 

layout and playout. 

Based on this information, the knowledge system is extended by provider-specific content and functionality. 

The storyboard may be altered according to the intentions of the provider, and life cases may be extended or


partially supported. Provider-based changes to portfolios are typical for knowledge systems in e-government 

and e-business applications. 

Developer context: The knowledge system implementation depends on the capability of the developer. Typically 

we need to take into account the potential environment, e.g. hard- and software, communication channels, 

the information systems that are to be incorporated, especially the associated databases, and the programming 

environment developers use. 

Organisational and social context: The organisation of task solutions is often already predetermined by the application 

domain. It follows organisational structures within the institutions involved. We captured a part of 

these structures already on the basis of the portfolio and modelled it by collaboration. The other pars form the 

organisational context. Collaboration of partners consists of communication, coordination, and cooperation. 

Cooperation is based on cooperativity, i.e. the disposition to act in a way that is best helpful for the collaboration 

partners, taking their intentions, tasks, interests and abilities into account. At the same time, collaboration 

is established in order to achieve a common goal. Actors choose their actions and organise them such that 

their chances of success are optimised with respect to the portfolio they are engaged in. Additionally, the social 

context may be taken into account, which consists of interactive and reactive pressures. Typical social 

enhancements are socially indicated situations such as welcome greetings, thanking, apologising, and farewell 

greetings. 

Most systems today do not support adaptivity and user orientation. Information as processed by humans is perceived 

in a very subjective way. As for a knowledge system, the determining factor whether the user can derive advantage 

from the content delivered is the user’s individual situation, i.e. the life case, user model and context. The same 

category of information can cause various needs in different life cases. 

Not any user can deal with any kind of content. For the casual user or the novice other content has to be delivered 

than for experts. The common knowledge system doesn’t reflect the user’s situation and neglects the user’s specific 

needs. As a result, the user is spammed with information which is predominantly out of focus. The abundance of 

information also makes it impossible to separate useful from for the user useless content. Any by the absence of meta 

data unspecified information reduces the usability of World Wide Web on the whole. 

Furthermore, users are limited 

• in their abilities for verbalisation, 

• in their abilities for digestion of data and 

• by their habits, practices and cultural environment. 

These limitations may cause intellectual overburdening of users. Most systems that require sophisticated learning 

courses for their exploration and utilization did not consider these limitations and did not cope with real life situations. 

The approach we use for avoiding overload is based on observation of real applications before developing the 

knowledge system. 

User typically request or need various content depending on their situation, on material available, on the actual 

information demand, on data already currently available and on technical equipment and channels on hand. Therefore, 

we need a facility for content adaptation depending on the context of the user. Content matching and adaptation may 

be thus considered as one of the ‘grand’ challenges of modern internet. 

To meet this challenge, the information has to be matched against the particular needs of the user [34, 33, 30]. 

Since the thinkable combinations of user life cases, user models and context [15] are indefinitely, the definition of 

life cases [33] has to be determined for the content and matched against the users situation. For a knowledge system, 

there should be not only concrete definitions of which content is applicable for which life case. To avoid making 

useful content useless by presenting it in an inappropriate way to the user, knowledge systems have also to consider 

the user’s specific profile and context. By processing this data, the knowledge system should provide different views 

of information and the appropriate media types for presenting their knowledge to various audiences. 

The implicit goals of content management and content delivery are: 

• to meet all the information (contextual) requirements of the entire spectrum of users in a given application area;


• to provide a “natural” and easy-to-understand structuring of the information content; 

• to preserve the designers entire semantic information for a later redesign; 

• to achieve all the processing requirements and also a high degree of efficiency in processing; 

• to achieve logical independence of query and transaction formulation on this level; 

• to provide a simple and easily to comprehend user interface family. 

Knowledge Management Systems. 

Knowledge management aims in supporting the spread of knowledge of individuals or groups across interested in 

it communities in ways that directly affect performance. Knowledge management envisions getting the right data (or 

information) within the right context to the right person at the right time for the right business purpose. Knowledge 

management systems allow to manage knowledge in communities of practice or interest, supporting creation, capture, 

and storage and sharing of expertise in the form of information in dependence on the user. Knowledge management 

systems use the entire variety of architecture solution known for intranet, internet or extranet systems. We observe 

two main architecture lines: 

1. The task/profile/portfolio-based approach focuses on the use of knowledge by collaborators depending on their 

tasks and interest. This approach is based on the data or information and knowledge needs of the communities, 

where they are located, and who needs them. The KMS is designed to capture knowledge and to make knowledge 

available when needed to whom needs it. These systems may be described by storyboards [18, 31] that 

describe the life situations or life cases of the knowledge demanders or user, the context of knowledge use and 

the user profiles which specify the education, personality and practice profile. 

2. The infrastructure/generic system based approach focuses on building a knowledge base system to capture 

and distribute knowledge for use throughout the communities of practice. It concern of the technical details 

needed to provide good mnemonic functions associated with the identification, retrieval, and use of knowledge. 

The approach focuses on network capacity, database structure and organization, and knowledge information 

classification. 

Semantification of Web 3.0. 

The “Semantic Web” is mainly based on syntax and partially uses micro-semantics of wordings. Semantics is 

used in the sense of rudimentary lexical semantics. Rudimentary lexical semantics must be enhanced by explicit 

definitions of symbols or words used. These definitions can be combined with the name spaces that provide a source 

for the lexical units used in a web document. The semantification project [6] of the group headed by J. Pokorny 

and P. Vojtas at Charles University Prague aims in enhancing the ontology based annotation in XML documents or 

RDFa-annotated HTML files by a semantic repository, by user profiles and by portfolio management. 

Web documents should be enhanced by context [15] or meta-data similar to the OpenCyc project. Lexical units 

may be characterised by time(absolut, type), place(absolut, type), culture, sophistification/security, topic/usage, granularity, 

modality/disposition/epistemology, argument preferences, justification, and lets [Len02]. 

The vocabulary of name spaces or of ontologies is not just a collection of words scattered at random throughout 

web documents. It is at least partially structured, and at various levels. There are various modes and ways of 

structuring, e.g., by branching, taxonomic or meronymic hierarchies or by linear bipole, monopolar or sequenced 

structures. 

Ontologies are often considered to be the silver bullet for web integration. They are sometimes considered to be 

an explicit specification of conceptualisation or to be a shard understanding of some domain of interest that can be 

communicated across people and computers. We should however distinguish a variety of ontologies such as generic, 

semiotic, intention/extension, language, UoD, representational, context and abstraction ontologies. 

Technical Environments for Knowledge on Demand.


In this paper we discussed three approaches to technical environments to knowledge systems: cloud services, 

database-backed systems and knowledge processing for universal communities. Technical environments for knowledge 

delivery system includes pull and push technology, notification technology, knowledge discovery technology, 

knowledge documentation, knowledge quality and productivity, and human computer interface technology. These 

systems be developed by using eight layers, which includes storyboard layer as a top level one in order to allow to 

provide knowledge on demand and on context, and followed by seven interwoven technology layers that facilitate 

the community to work together to share, re-use and generate knowledge among them: interface layer, access layer, 

collaborative layer, application logic layer, transport layer, integration layer, and repositories layer. 

Digital Science (Science 2.0). 

[aIU11] defines the focus and the purpose of digital science as follows: “Digital science focuses on creating an 

intuitively usable cyber-infrastructure with tremendous capabilities for supporting collaboration and computation. 

Easy-to-use, human-centered interfaces to cyber-infrastructure created by the digital science will enable the many 

thousands of researchers in the public and private sectors to use the capabilities of cyber-infrastructure and accelerate 

innovation and discovery”. 

Modern science and especially digital science is backed by networks of computing resources, by tools for knowledge 

management, by ready-to-use and adaptable knowledge. People are at the basis of the future scientific environment. 

Digital science combines concepts and technologies to make this possible. First emerged in the natural 

sciences, digital science can be transferred to all disciplines and benefit from their integration, including the arts and 

humanities. The adoption of digital science has only just begun; technologies, organisational structures and culture 

progress alternately towards the digital science vision. 

[Mac11, Ber11] define digital science through their backgrounding technology, especially within an yet-anotheredutainment 

(or -e-learning) platform: “Digital science will focus on providing world-class software tools and services 

to scientists, managers and funders with the ultimate aim of making research more productive through the use 

of technology.” This technology supports the delivery 

• of information to my community within the current context, 

• of lectures together with settled material, and 

• of competencies gained by each of the partners. 

Digital science (sometimes called e-science or science 2.0) is characterised by 

1. collaboration (or crowd) stories for development of science within a community (how), 

2. profiles, level of engagement and interest of collaborators (who), 

3. content that is either private or shared based a number of sharing pattern (what), 

4. coherent presentation of content depending on the profile of the user and on progress of work within a community, 

5. rights, roles and plays of contributors within the story assigned (which rights portfolio), and 

6. constraints for the participation and contribution (which conditions). 

Services for Digital Science. 

Digital science relies on high availability of content at any time for convenience (when), at any place of the 

collaborator (where in the ‘cloud’), and within any context that is agreed in advance. Digital science is based on 

the classical science behaviour, classical science standards, classical editing of scientific results and classical quality 

norms and assurance (communalism, universalism, disinterestedness, originality, and skepticism) within a scientific 

community. 

Digital science is science that extensively uses digital (or IT) services. These services might be


• services for collaboration within a group or community of scientists, 

• data, information or knowledge services for collection, creating, delivering, maintenance and cleansing of 

content within a scientific community, 

• computational, exchange and control services for the portfolio of tasks a scientist has been assigned, 

• network services for hooking into the network at any time independently of the current location and environment 

of the scientist, and 

• protection services for privacy and security of scientific communities. 

Services for digital science require a more sophisticated description for services beyond WSDL. We use the following 

frame for the specification of digital science services: 

End (wherefore) of the services; 

Sources (whereof) used for the service; 

Supporting means (wherewith) the service is relying on; 

Surplus value (worthiness) the service might give to the users; 

Purpose (why, whereto, when, for-which-reason) of the service; 

Activities (how) supported by the service for collaboration stories based on data consumption (what-in) and resulting 

in data production (what-out); 

Parties such as suppliers (by-whom), consumers (to-whom), and producers (whichever); 

Application domain describing the application area (wherein), application cases (wherefrom), the problems (forwhat), 

the organizational unit (where), triggering events (whence), and IT data, control, computation (what, 

how) 

Context for the service such as the system context (whereat), the story context (where-about), the coexistence context 

(whither), and the time context (when). 

Digital science takes its cue from the technologies of Web 2.0, Web 3.0 and Knowledge Web. It creates conversations 

between researchers, lets them discuss the data and connect it with other data that might be relevant. 

The most important property of digital science is its constant collaboration among scientists. Collaboration of 

partners consists of communication, coordination, and cooperation. Cooperation is based on cooperativity, i.e. the 

disposition to act in a way that is best helpful for the collaboration partners, taking their intentions, tasks, interests 

and abilities into account. At the same time, collaboration is established in order to achieve a common goal. Actors 

choose their actions and organise them such that their chances of success are optimised with respect to the portfolio 

they are engaged in. Additionally, the social context may be taken into account, which consists of interactive and 

reactive pressures. Typical social enhancements are socially indicated situations such as welcome greetings, thanking, 

apologising, and farewell greetings. 

Digital science services support a scientific community. This community is backed by a common library of this 

community. The essential results of such communities are knowledge chunks compiled. Communities collaborate. 

Therefore, exchange services are an essential element of the knowledge infrastructure. The collaboration within the 

community must be supported corresponding services. We thus may separate services that support the infrastructure 

of digital science as given in Figure 5. 

Information Infrastructure Services for Digital Science. 

Information infrastructure services support collaborative work of scientists independent from their location at 

different periods of time. The collaboration is based on roles, rights and group membership of scientists. These


Knowledge delivery service: 

Services for 

partners 

Knowledge community: 

Community 

of my collaborators 

Infrastructure 

for digital science 

Virtual knowledge library: 

Knowledge chunks, 

adapters 

Compiled knowledge: 

Commonly 

agreed and shared notions 

Abbildung 5: The dimensions of infrastructures for digital science 

services must support the entire research process - starting from brainstorming, detection, discussion continuing 

through issuing project and should not terminate after a project has been closed. Data that are bundled with research 

results must be accessible together with publication of results. 

Virtual research environment services thus provide an access to real science resources (e.g., data analysis and 

computation tools, data). They thus support the scientific work of generation Z. Young people are nowadays used to 

the facilities of the internet, to the richness of data sources, to the variety of beliefs and opinions displayed at pleads 

of webpages, to the constant change in the web and to the incompleteness and misinformation of opinion pools and 

blogs. The generation Z has however not yet found a way to discover the real information, to dig to grounded data, 

to follow links to the consensus that has led to the data in the web, and select correct and consistent data within the 

world of data in the web. Therefore, a number of tasks must be solved for digital science: 

Digital archives beyond the classical hosting and archive technology must be backed by stabile and dependable 

access services, simple but powerful search facilities, and high-performance data delivery. They ensure the 

long-term availability of digital media and contents that have been acquired from around the world and their 

integration in the digital research environment. Digital archives must be backed by subject-specific standards 

and methods of data curation and archiving. 

Archives are either [Bea10] 

• light archives that can be accessed by many authorised users, 

• dark archives that cannot be accessed by any current users but may be accessible at future dates subject 

to the occurrence of specific pre-defined events either of type 1, i.e., providing a form of escrow or “bit 

preservation” of content, or of type 2, i.e., providing the bit preservation of the content plus some degree 

of associated services for future access, and 

• dim archives that provide bit preservation for the content plus digital preservation planning and actions 

for long-term perpetual access, and also limited current access. 

Library 2.0 tools guarantee the broadest possible access to digital publications, primary research data, to virtual 

research and communications environments, and other material without unexpected costs and other barriers. 

They ensure the systematic backup, archiving and provisioning of scientific data for subsequent (re-)use by third 

parties. Perpetual access guarantees to the right of the subscriber and their users to have ongoing permanent 

access to electronic materials which have already been leased and paid for by the subscriber from a publisher. 

Search and access tools are currently based on database techniques for ad-hoc query formulation and computation. 

Instead knowledge infrastructures must be backed by support for access in dependence on meta-data about 

the users, their profile and portfolio, and especially their information demand. The same set of requirements 

is valid for search tools. Search can be categorised into seven categories [DT04]. This categorisation allows a 

development of standardised methods for access to to information massives.


Collaboration tools for collaborative research within continuously changing communities would allow broad cooperation 

of scientists, would support concentration of competencies and resources and would improve coordination 

of current and future activities. Collaboration services can be build based on the 3C framework [ST07b] that 

separates supporting services into communication services, coordination services, and cooperation services. 

These services can be supported by current database technology [FRT05]. 

Since science data are heterogeneous in their nature a common data policy must be promoted. This policy is 

based on a data management plan for all collaborating partners. This plan includes maintenance procedures, 

clearing procedures, control of access and data consumption, data update procedures for all partners, and data 

delete procedures for all partners. Such policies must be the basis for data collaboration contracts. At the same 

time, science data must be bundled with the publication of results drawn from them. 

both the need for action and to demonstrate the usefulness of primary data infrastructures for scientists and 

scholars. 

Distribution tools ideal conditions for delivery, distribution, and reception of most recent research results 

Integration tools support the constant change of the world of knowledge which is continuously extended, modified 

and documented in scientific publications 

SWOT Analysis of the Current State-Of-The-Art. 

Knowledge management is a long-standing research issue, was probably the hottest topic in management in the 

1990s and has partially failed. We may learn the lessons for the development of infrastructures that support digital 

science. Despite massive investments and a lot of highly motivated people, the best knowledge management systems 

succeeded at capturing and institutionalizing the knowledge of a company. The real value of knowledge management 

is in creating new knowledge, rather than simply “managing” existing knowledge. 

What we really need are new approaches to creating knowledge, ones that take advantage of the existing software 

systems and incorporate new digital infrastructures for intensive collaboration and for mobilisation of benefits of 

interacting and collaborating communities. Digital science is going to heavily rely on shared network platforms, 

provides tools and forums for knowledge creation while at the same time capturing the discussion, analysis, and 

actions in ways that make it easier to share across a broader range of participants. Blogs and wikis have great benefits 

for a community and any member of such. 

At the same time ‘knowledge management’ was really a misnomer. Most companies called knowledge management 

was was actually information management. They captured tacit information held by the employees and thus 

made it explicit. Collaboration was not yet a target. Employees did not see added value to their workflow by providing 

information to the company without any really effective enhancement to the workflow. They will participate when 

there are direct benefits. People want knowledge in exchange for their information. Current tools successfully collect 

information but are very poor at yielding knowledge. 

Digital science services focus on providing immediate value to scientist in terms of helping them tackle difficult 

performance challenges while at the same time reducing the effort required to capture and disseminate the knowledge 

created. They bring into play network effects in the generation of new knowledge. They leverage the social aspect in 

worthwhile ways. 

Currently, many systems are available for digital science due to the large number of projects such as the AstroGrid, 

Avian Flu HSN1, Comb-e-Chem, DiscoveryNet, the European DataGrid (EDG), the gSLM, the GriPhyN, Indonesian 

Earthquake, WISDOM projects and the EGI, GEANT, Large Hadron Collider (LHC) at CERN, NERC DataGrid, 

myGrid, PRACE, and RealityGrid grids. Based on the experience gained different e-Business, e-Government, and e- 

Services have been developed. e-Science project can benefit from experience and analyses and can share the services 

that have been. 

We may use SWOT analysis techniques for a characterisation of the current state of the art: 

Strengths and goodies: Basic technologies are on hand. They are mainly based on well-known techniques of “programming 

in the small”. They use partially “programming in the large”.


Weaknesses and missing IT: collaboration tools for crowdworking Techniques for “programming in the world” are 

chaotically introduced and must be matured and systematised. 

Opportunities of current technology: The world-wide collaboration on the fly allows to use human and technical 

resources wherever they are, whenever they are developed, whoever can provide the correct data at the best 

point of time, in the agreed format and quality for the right user with the at the right location and context. 

Threats of current technology and restrictions: The chaotic development uses a wide variety of techniques, does 

not yet have a basement and is thus difficult to evolve. Instead we need flexible frameworks and a thoughtful 

integration of technical knowledge that has been obtained in the past. Data (sometimes called information) are 

typically delivered without quality meta-information or facilities for information management. The search is 

still address-based and looks alike the Computer Stone Age. Programming in the world is a common practice, 

however mainly in a quick and dirty fashion. 

Web x.0 Evolution and the Knowledge Web. 

For almost two decades the internet was a linkage of networked servers, which was entirely used as a worldwide 

source for researches. It resulted in an aggregate of billions of static web sites, which was accessed via hyperlinks. 

Websites have mainly been author-driven. They have been aiming to support users depending on their information 

need and demand, so the focus was chiefly on the mutual trust between user and provider. The utilisation of these sites 

can be modelled by story spaces. The story space specification results in storyboards that are schemes for utilisation 

by a large variety of users. Web 1.0 is author driven and uses as stories 

• at the provider side publish/provide story/support or 

advertise/wait/attract/react/retain and 

• at the user side inform/subscribe/obtain/answer/come back. 

Web 1.0 has mainly be oriented towards content provision, which basically meant to deliver content together with a 

rudimentary functionality. These main functionalities can be: 

• navigation facilities for inside site or page navigation; 

• acquisition possibilities of information for users from simple content that is based on text, media data such as 

pictures, audio and video data; 

• linking facilities; 

• search and browse facilities providing to users. 

Websites are mainly oriented towards content delivery, provide some functionality and are using a large variety of 

presentation facilities. 

Web 1.0 has made author-driven static content available to numerous users. Users could access exclusively the 

web pages for researches and personal investigations. The control and management from the ’top’ didn’t provide any 

scope or client-side opportunities for development. This has changed with the evolution of Web 2.0, the so-called 

social web, as a development process powered by collaborative brainstorming, in which the collective cooperation is 

to the fore. Meanwhile there are no bounds set to the today’s web. With the establishment of user communities, users 

obtain an abundance of information by high-tech sophisticated services, interchange experiences and benefits by the 

mass collaboration every single day, because data acquisition and data diffusion are basically accomplished by user 

interactions inside the whole web story space. 

While Web 2.0 integrates collaboration, Web 3.0 provides annotation techniques. These annotation techniques 

are typically based on linguistic semantics of words used for a reference of data chunks to user semantics. These 

techniques provide a very good background for sophisticated search and representation techniques. Fully-developed 

Web 3.0 is characterised by the formula (4C + P + VS) where 

• 4C means content, commerce, community and context


• P is used for personalization and 

• VS denotes vertical search. 

But what is missed in the future of web, is quality. We want to reach this level of quality with the aid of semantics and 

pragmatics in respect of the user profile and life cases. We are convinced that lexical semantics composes the base 

frame of the Next Generation Knowledge Web. 

Figures 6 illustrates the general facets of websites. We distinguish six different facets: presentation (layout and 

playout) of pages within a website, (aggregated and prepared) data and functionality provided by the systems that 

support the website, stories and context behind the application logic of the website, and the user space that is based 

on a description of the intentions. Web 1.0 was mainly based on presentation systems with supporting systems for 

aggregated data (called content) and functionality. Web 2.0 allows context injection and is user-centered and storycentered. 

Web 3.0 extends the data content by annotation that are meaningful to users, i.e. provides content together 

with topical data. The knowledge web extends this dimension by explicit support for concepts beside annotations. It 

additionally allows an adaptation to the user and the context thus providing information the user really needs. 

Goal, application area 

User and intention profile, 

information demand 

Context 

Technics 

organisation 

Data 

Content, 

objects, 

knowledge 

Website 

development 

space 

Storyboard 

Stories 

tasks 

Functionality 

Navigation, 

search, 

work 

Presentation 

Interfaces 

depending on the environment 

Abbildung 6: Separation of concern for development of Web x.0 websites 

5.1.3 Towards Knowledge Management based on Knowledge Chunks 

Knowledge can be characterised through (1) its content, (2) its concepts, (3) its annotations or topics, and (4) its 

understanding by the user. Knowledge pieces cannot be considered in an isolated form. For this reason we imagine to 

use knowledge chunks as a suite of knowledge pieces consisting of content, concepts, topics and information. These 

dimensions are interdependent from each other. Figure 7 displays the knowledge space. 

Topics 

ontology 

Annotation, linking 

culture, context 

Databases 

utilisation 

Content space 

Media types 

functionality, adaptation 

Topic space 

Knowledge 

space 

Concept space 


user portfolio 

Information space 

Memes 

cultural units 

Semantic theories 

ontology 

Pragmatics 

general culture 

Abbildung 7: The four dimensions of the knowledge space: Data dimension through content, foundation dimension 

through concepts, language dimension through topics, user dimension through information


Content and Media Types: The Data Dimension. 

Content is complex and ready-to-use data. Content is typically provided with functions for its use. Content can 

be defined n the basis of media types. Content management systems are information systems that support extraction, 

storage and delivery of complex data. 

Content in its actual definition is any kind of information that is shared within a community or organization. In 

difference to data in classical database systems content usually refers to aggregated macro data which is complex 

structured. Structuring of content can be distinguished: 

• The structure of the aggregated micro data is preserved but micro data was combined to build larger chunks of 

information. Examples are scientific data sets such as time series of certain measurements. There is a common 

(or even individual) structuring and meaning for each sampling vector but the compound of all sampling vectors 

adds additional semantics. 

• The structure of content is only partially known. A typical example is the content of Web pages: structuring is 

known up to a certain level of detail which may also be varying within one instance. 

• Content may be subsymbolic, such as pictures, videos, music or other multimedia content. 

Aggregation of content usually takes place by combining reusable fragments provided by different sources in 

different formats such as texts, pictures, video streams or structured data from databases. Content is subject to a 

content life cycle which implies a persistent change process to the content available in a content management system 

(CMS). 

The more generic ones agree in a major paradigm: the separation of data management and presentation management. 

Data management reflects the process of supporting content creation, content structuring, content versioning, 

and content distribution while presentation management grabs the data for delivering it to the user in various ways. 

Only content which is generated following this separation can be easily shared, distributed, and reused. 

Following new trends and developments in Web technologies, e.g., in the context of Web 2.0 or the Semantic Web 

the automated processing of content becomes more and more important. Because content represents valuable assets 

it may be reused in different contexts (content syndication) or has to remain accessible for a long time. 

The semistructured or even unstructured nature of content requires annotations to enable search facilities for 

content. Expressing semantics in a machine interpretable way has been under investigation since the early days of 

artificial intelligence, see e.g., [36] for a survey of knowledge representation techniques such as logical theories, rulebased 

systems, frames or semantic nets. Today systems handle semantical descriptions as metadata describing certain 

content instances. There are different ways for associating data and metadata: 

• A conceptual, logical, or physical schema is defined and instances are created according to this schema. This is 

the usual way for classical databases. The modelling language strongly restricts the capabilities of this description 

facility. Common languages such as Entity-Relationship Modelling or UML focus on structural properties 

with support of selected integrity constraints. 

• Defining a schema is not applicable (or only in a restricted way) to semistructured or unstructured content. For 

that reason content instances are annotated. An annotation is a triple (S, P, O) where S denotes the subject to be 

annotated, P a predicate denoting the role or purpose of this annotation, and O the object (or resource) which is 

associated with S. The vocabulary for annotations is organized in ontologies and thesauri. A typical language 

for expressing annotations in the context of the Semantic Web is the Resource Description Framework (RDF, 

[39]) while the Web Ontology Language OWL ([38]) may be used to express semantic relationships between 

the concepts and resources used for annotation. There exist myriads of ontologies and parameter definitions for 

different application domains such as the Dublin Core parameters [5]) for editorial content. 

Concepts and Theories: The Foundation Dimension.


Concepts are the basis for knowledge representation. They specify our knowledge what things are there and what 

properties things have. Concepts are used in everyday life as a communication vehicle and as a reasoning chunk. 

Concepts can be based on definitions of different kinds. Therefore our goal for the development of knowledge web 

can only be achieved if the content definition covers any kind of content description and goes beyond the simple 

textual or narrative form. 

A general description of concepts is considered to be one of the most difficult tasks. We analysed the definition 

pattern used for concept introduction in mathematics, chemistry, computer science, and economics. This analysis 

resulted in a number of discoveries: 

• Any concept can be defined in a variety of ways. Sometimes some definitions are preferred over others, are 

time-dependent, have a level of rigidity, are usage-dependent, have levels of validity, and can only be used 

within certain restrictions. 

• The typical definition frame we observed is based on definition items. These items can also be classified by 

the kind of definition. The main part of the definition is a tree-structured structural expression of the following 

form 

SpecOrderedTree(StructuralTreeExpression 

(DefinitionItem, Modality(Sufficiency, Necessity), 

Fuzziness, Importance, Rigidity, 

Relevance, GraduationWithinExpression, Category))) . 

• Concepts typically also depend on the application context, i.e. the application area and the application schema. 

The association itself must be characterised by the kind of association. 

Concepts are typically hierarchically ordered and can thus be layered. We assume that this ordering is strictly hierarchical 

and the concept space can be depicted by a set of concept trees. A concept is also dependent on the community 

that prefers this concept. A concept is also typically given through an embedding into the knowledge space. The 

schema in Figure 8 displays the general structure for content definition. This schema also covers all aspects discussed 

in [19]. 

Community 

✛ 

AcceptanceLevel 

Community 

Context 

UsageProfile 

✲ 

Concept 

✻ 

(0,n) 

(0,1) 

Descriptor 

Spec 

Ordered 

Tree 

✲ 

Structural 

Expression 

✛ 

Preference 

Defined Time 

Through Usage 

Restriction 

Validity 

❄ 

Definition 

Item 

✛ 

Definition 

Kind 

✲ 

Kind 

of Definition 

Term 

Language 

Abbildung 8: The main schema for Concept Definition and Formation 

Concept gathering can be understood as a technique which combines concept representation [7, 19, 37] and 

algorithmic learning approaches. 

A concept gathering system is based on 

a set of concepts and available experience C, 

a set of domain knowledge D, 

a set of representable meta knowledge M,


a set of learning goals G, and 

a set of representable hypotheses H. 

The set of representable knowledge and concepts is denoted by R = C ∪ D ∪ M ∪ G ∪ H. 

The concept gathering system (γ, λ, ν, C, R) consists of 

a concept generator γ : C × R → C, 

a learning function 

λ : C × R → H, and 

an evaluator ν : C × R → Q where Q denotes set of quality characteristics. 

A run of the concept gathering system results in 

a concept detection sequence C 1 , C 2 , ..., C f with C i ∈ C and 

a learning sequence R 0 , R 1 , R 2 , ..., R f 

with R i ∈ R where R 0 denotes the initial knowledge and R f denotes the final knowledge. 

The run is typically recorded and is dependent on the concepts gathered so far. For instance, in data mining processes 

we can switch from cluster detection to cluster explanation, decision tree modelling and finally to association rule 

derivation. 

Additionally, the concept gathering system records 

the background knowledge of the learner B ⊆ D ∪ M ∪ G and 

the actual available knowledge B ∪ H ′ . 

Topics and Ontologies: The Language Dimension. 

Content and concepts may be enhanced by topics that specify the pragmatic understanding of users. 

Semantic annotation in current content management systems is usually restricted to preselected ontologies and 

parameter sets. Rich conceptual data models are only available in more sophisticated systems. Because most generic 

CMS are focused on Web content management semantic annotation is usually restricted to editorial parameters. 

Specialized content management systems which are adapted to certain application domains incorporate preselected 

and tailored ontologies. Especially for XML-based content there exist several annotation platforms which incorporate 

semantical annotation either manually or semi-automatically; see [25] for a survey on available platforms. 

Automated processing of semantical metadata is usually restricted to search facilities, e.g., searching for the 

author of an article. Because ontologies are preselected for most systems a full-featured reasoning support is usually 

not available. Especially for OWL ontologies there are reasoning tools based on description logics such as Racer 

([10]) or FaCT which enable T-box (but also A-box) reasoning about semantic relationships between annotation 

concepts. 

Applying generic semantical annotation and classical reasoning facilities to content management suffers from 

several drawbacks: 

• Content as aggregated macro data is only partially analysable. The purpose of metadata is the description of 

properties which cannot be concluded from the data itself. The very simple annotation frame of (S, P, O) 

triples does not allow one to express complex properties. For that reason this information has to be kept in 

the underlying ontology by defining appropriate concepts. The support of user-specific concepts increases the 

size of the ontology significantly and makes reasoning support even harder. Ad hoc definitions of user-specific 

concepts is not supported in this annotation model. 

• Annotation with respect to arbitrary ontologies implies general purpose reasoning support by the system. Reasoning 

for even simple languages suffers from its high computational complexity (e.g., NEXPTIME for the 

restricted OWL-DL dialect, [13].) Dealing with high worst-case complexities implies a small size of input data 

but this is a contradiction to expressible ontologies and the definition of content as complex structured macro 

data. Especially the size of content instances is a crucial factor because A-box reasoning is a critical point for 

automated content processing ([11].)


But there are advantages, too: 

• Usually, it is possible to distinguish between different points of view on content instances. Not every property 

is important while looking from every point of view. The macro data may encapsulate and hide properties from 

its aggregated micro data. Reasoning about the properties of the compound can be separated from the properties 

of the elements as well as the properties of interconnections between content instances. 

• Typical application scenarios determine important properties and suggest evaluation strategies. So ontologies 

may be decomposed to enable a contextualized reasoning, e.g., on the basis of Local Model Semantics ([9]). 

Local reasoning may rely on a language that is just as expressive as needed in this context. Contexts relying 

on less expressive languages may support automated reasoning while contexts relying on more expressive 

languages may be used for manually interpreted information. Soundness and completeness of the reasoning 

process are not of primary interest as long as the reasoning result is acceptable in the application domain. 

• The separation between annotations relying on common knowledge, user-specific annotations and (especially) 

usage-specific annotations reduces the size of incorporated ontologies significantly. 

• If semantic annotations themselves are given a more sophisticated internal structure reasoning can be adapted 

to the requirements of the application domain. 

The major disadvantage of current semantic description in content management is the treatment of knowledge 

over content instances as metadata on a secondary level in a strongly restricted language. In the following sections we 

will introduce a data model for content which handles the semantic part on the same level as the content itself and gives 

additional structure to the semantic description. Content chunks are semantically enriched content instances. They 

are based on the notion of a schema for content chunks to incorporate typical functionality of content management 

systems such as content generation, content delivery, or content exchange. 

Information and Memes: The User Dimension. 

There are several definitions for information. 

• The first category of these definitions is based on the mathematical notion of entropy. This notion is independent 

of the user and thus inappropriate in our project context. 

• The second category of information definitions bases information on the data a user has currently in his data 

space and on the computational and reasoning abilities of the user. Information is any data that cannot be 

derived by the user. This definition is handy but has a very bad drawback. Reasoning and computation cannot 

be properly characterised. Therefore, the definition becomes fuzzy. 

• The third category is based on the general language understanding of information [SYea03]. 

Information is either the communication or reception of knowledge or intelligence. 

Information can also defined as 

• knowledge obtained from investigation, study, or instruction, or 

• intelligence, news or 

• facts and data. 

Information can also be the act of informing against a person. 

Finally information is a formal accusation of a crime made by a prosecuting officer as distinguished from an 

indictment presented by a grand jury. 

All these definitions are too broad. 

We are thus interested in the anthropomorphic definition that is more appropriate for the internet age.


5.1.4 Data Management 

The general notion of data. 

Standford Philosophy: In our context, information cannot be dataless but, in the simplest case, it can consist of a 

single datum. A datum is a putative fact regarding some difference or lack of uniformity within some context. 

Depending on philosophical inclinations, DDD can be applied at three levels: 

1. data as diaphora de re, that is, as lacks of uniformity in the real world out there. There is no specific name for such “data in the wild”. A 

possible suggestion is to refer to them as dedomena (“data” in Greek; note that our word “data” comes from the Latin translation of a work 

by Euclid entitled Dedomena). Dedomena are not to be confused with environmental data. They are pure data or proto-epistemic data, that 

is, data before they are epistemically interpreted. As “fractures in the fabric of being” they can only be posited as an external anchor of our 

information, for dedomena are never accessed or elaborated independently of a level of abstraction. They can be reconstructed as ontological 

requirements, like Kant’s noumena or Locke’s substance: they are not epistemically experienced but their presence is empirically inferred from 

(and required by) experience. Of course, no example can be provided, but dedomena are whatever lack of uniformity in the world is the source 

of (what looks to information systems like us as) as data, e.g., a red light against a dark background. Note that the point here is not to argue 

for the existence of such pure data in the wild, but to provide a distinction that will help to clarify why some philosophers have been able 

to accept the thesis that there can be no information without data representation while rejecting the thesis that information requires physical 

implementation; 

2. data as diaphora de signo, that is, lacks of uniformity between (the perception of) at least two physical states, such as a higher or lower 

charge in a battery, a variable electrical signal in a telephone conversation, or the dot and the line in the Morse alphabet; and 

3. data as diaphora de dicto, that is, lacks of uniformity between two symbols, for example the letters A and B in the Latin alphabet. 

Depending on one’s position with respect to the thesis of ontological neutrality (section 1.6) and the nature of environmental information 

dedomena in 

(1) may be either identical with, or what makes possible signals in (2), and signals in (2) are what make possible the coding of symbols in (3). 

The dependence of information on the occurrence of syntactically well-formed data, and of data on the occurrence 

of differences variously implementable physically, explain why information can so easily be decoupled from its 

support. The actual format, medium and language in which semantic information is encoded is often irrelevant and 

hence disregardable. In particular, the same semantic information may be analog or digital, printed on paper or 

viewed on a screen, in English or in some other language, expressed in words or pictures. Interpretations of this 

support-independence can vary quite radically. The definition of the notion of a datum leaves underdetermined [?] 

• the classification of the relata (taxonomic neutrality) that defines a datum as a relational entity; 

• the logical type to which the relata belong (typological neutrality), for instance, primary, secondary or operational 

data or metadata or derived data; 

• the kind of support required for the implementation of their inequality (ontological neutrality) since there can 

be no information without data representation ; and 

• the dependence of their semantics on a producer (genetic neutrality) that request that data can have a semantics 

independently of any informee. 

The general tasks of data management. 

Data management is a group of activities relating to the planning, development, implementation and administration 

of systems for the acquisition, storage, security, retrieval, dissemination, archiving and disposal of data. Such 

systems are commonly digital, but the term equally applies to paper-based systems where the term records management 

is commonly used. The term embraces all forms of data, whether these data sets are simple paper forms, 

the contents of relational databases, multi-media data sets such as images, or scientific data such as environmental 

data records collected in isolated or collaborating research projects. The management of scientific data is in many 

ways no different to the management of other types of data. However, it is important to recognise that there may be 

science-branch-specific issues that need careful thought as part of data management activities; for example, ensuring 

that any spatial and temporal identifiers used are appropriate and resilient. 

Key data management activities include: 

• Data policy development, 

IS ADD


• Data ownership, 

• Metadata compilation, 

• Data lifecycle control, 

• Data quality, and 

• Data access and dissemination. 

Aufgaben des Datenmanagers in Forschungsprojekten. 

Mit dem Datenmanagement soll als Hauptziel die Entwicklung einer funktionalen Arbeitsplattform für die 

Vorbereitung der Datenerhebung, für die Datenerhebung, für die Vorbereitung der Auswertung, für die Speicherung 

erhobener und in Auswertungen genutzter Daten und für die Bereitstellung von Daten an Arbeitgruppen 

und Dritte für ein Forschungsprojekt vorangetrieben werden. 

Datenaustausch zwischen den Arbeitsgruppen und Projekten. 

Die Kollaboration von Arbeitsgruppen wird oft nur bei gleichgestaltenen Datenbeständen unterstützt. Eine breitere 

Kollaboration erfordert auch die Entwicklung entsprechender Kollaborationswerkzeuge, so daß für die flexible 

und adäquate Bereitstellung von Daten an Partner einfache Unterstützung gegeben werden kann. Dies betrifft sowohl 

den Export von Daten als auch den Import von Daten sowie auch die Integration von Neudaten in bereits existierende 

Datenbestände. 

Exportschnittstellen auf der Grundlage generischer Schnittstellen können zu den wesentlichen Zentren und auch 

zu neu integrierten Zentren die Arbeit der Wissenschaftler wesentlich erleichtern. Diese Exportschnittstellen können 

als neue Schicht über der Datenverwaltung konzipiert werden. Mit einer Entwicklung eines XML-Austauschformates 

können auch Suiten von Exportschnittstellen und entsprechende Schemata bereit gestellt werden. Es kann dabei vorgesehen 

werden, daß der Austausch dokumentenbasiert, aber quellenunabhängig vorgenommen wird. Eine Erweiterung 

um entsprechende Annotationen kann damit auch automatisch erfolgen. 

Importschnittstellen erleichtern die Integration von Neudaten und Fremddaten in bereits bestehende Datenbestände. 

Mit Formulartechniken und einer Suite von Input-Formen kann der Datenaustausch wesentlich erleichtert werden. 

Zur Verbesserung des Datenaustauschens sollen schrittweise Formulare und Schnittstellen für den Import und 

den Export von Daten entwicklet werden. Diese Schnittstellen können zunehmend generisch angelegt werden, damit 

nicht mit jeder neuen Anforderung, Arbeitsaufgabe oder jedem neuen Format eine neue Schnittstelle entwickelt 

werden muß. 

In analoger Form kann eine Aufbereitung von Fremddaten unterstützt werden. Dazu gehören insbesondere Techniken 

zur automatischen Ergänzung von Fremddaten um die zugehörigen Metadaten, um die entsprechenden Grunddaten 

im Falle von aggregierten Daten und entsprechende georefernzielle und temporale Annotationen. 

Der Datenaustausch zwischen den Arbeitsgruppen und Projekten kann schrittweise um ein Qualitätsmanagement 

von Fremddaten und eigenen Daten ergänzt werden. Es würde damit eine Mitführung der Charakterisierung von 

Qualitätscharakteristiken mit den Daten unterstützt, so daß eine spätere Wieder- und Weiterverwendung bei Berücksichtigung 

der Datenqualität ermöglicht wird. 

Mit einem Wachsen des Datenbestandes wird die Konsistenz und die partielle Vollständigkeit zu einem immer 

größeren Problem. Deshalb sollen mit den Techniken des Datenaustausches auch parallel Techniken zur Pflege der 

Konsistenz und der Vollständigkeit von Daten entstehen und erprobt werden. 

Eine gemeinsame Benutzung von Daten setzt zum einem die Nachvollziehbarkeit einer Weiternutzung durch 

andere Benutzer voraus. Erfolgt eine Weiter- oder Wiederverwendung von Daten anderer Benutzer, dann muß diese 

Benutzung auch sowohl bei den neuen Benutzern als auch bei den Originaldaten mitgeführt werden. Außerdem 

können die Originaldatenbestandes durch die besitzenden Benutzer auch modifiziert und verändert werden. Deshalb 

sollte eine Mitführung von Veränderungen des Originaldatenbestandes bei einer Weiter- oder Wiederbenutzung auch 

bei den verwendeten Daten anzeigbar sein. Deshalb ist vorgesehen, daß mit einem Export von Daten eine Kopplung 

von Datenbeständen je nach Verpflichtungen im Exportvertrag erfolgen kann. 

IS ADD


Der Export an Datenzentren ist für alle Daten, die einer Auswertung zugeführt werden und bei Veröffentlichungen 

herangezogen werden eine wesentliche Aufgabe. Es ist mit den Exportkonvertierungen schrittweise ein generisches 

Exportkonzept erarbeitbar, mit dem weitere Exporte automatisiert werden können. Ziel ist die Entwicklung einer 

Exportschnittstellen-Suite. 

Die Erarbeitung dieser Suite von Exportschnittstellen kann auch zur Ausarbeitung einer Suite von Importschnittstellen 

herangezogen werden. Insbesondere bei der automatischen Ergänzung importierter Daten um Annotationen 

kann damit eine Verbesserung und Anreicherung der Daten, die im Exzellenzcluster für Analysen von Relevanz sind, 

erfolgen. 

Effiziente und effektive Zugangskontrolle und Zugangssteuerung. 

Daten stellen eine wertvolle Ressource dar, die vor unberechtigtem Zugriff und unberechtigter Weitergabe zu 

schützen ist. Ein Eigentümer von Daten muß jederzeit in der Lage sein, die Besitzer seiner Daten zu ermitteln, einen 

Besitz ggf. auszuschließen oder zu verhindern und weitere Besitzverhältnisse zu genehmigen. Moderne DBMS erlauben 

eine umfangreiche Sicherung von Daten gegen Fremdbenutzung und eine Absicherung gegen unberechtigte Benutzer. 

Diese Sicherungsmechanismen können für Projekte erschlossen werden. Mit einem Datenmanagement kann 

deshalb eine effiziente und effektive Zugangskontrolle für alle Datenbestände erfolgen und eine nicht genehmigte 

Fremdbenutzung der Daten ausgeschlossen werden. 

Es können unterschiedliche Rollen und Graduierungen der Sicherung von Daten installiert werden. Es können 

Daten damit entweder nur für den Eigentümer oder die Mitglieder einer Arbeits- oder Projektgruppe oder die Kooperationspartner 

oder andere nationale oder internationale Partner freigegeben werden. Dazu werden für die Benutzung 

von Daten entsprechende Rollenkonzepte entwickelt, mit denen eine Benutzung explizit erlaubt oder auch blockiert 

werden kann. Benutzer, die über keine der Rollen verfügen, werden von der Benutzung der Daten ebenso ausgeschlossen 

wie auch von einer Information über die Existenz der Daten, über die verwendeten Datenformate oder den 

Datenumfang. 

Es kann neben der Absicherung der Daten gegen nicht erlaubte Fremdbenutzung auch eine automatische ‘Credit’- 

Erzeugung bei Weiterbenutzung, Ablage und Entgegennahme von Originaldaten im Besitzvertrag erreicht werden. 

Solche Besitzverträge können durch entsprechende Freigabemechanismen für weiterbenutzte Daten auch zur Erzeugung 

von entsprechenden Annotationen bei den weiter verwendeten Daten und zum Mitschreiben der Weiterverwendung 

bei den Originaldaten herangezogen werden. 

Eigentümern und zugelassenen Benutzern soll dagegen ein leichter Zugang zu den Daten ermöglicht werden. 

Dieser Zugang wird mit den Exportschnittstellen-Suiten unterstützt. Der Zugang kann über entsprechende Internet- 

Browser realisiert werden, so daß autorisierte Benutzer auch relativ geräte- und umgebungsunabhängig die Daten 

benutzen können. 

Da Daten auch in das Datenmangement eingebracht werden sollen, wird eine Importschnittstellen-Suite vorgesehen. 

Mit diesen Importschnittstellen können entsprechende Mechanismen zur Einlagerung von Daten vorgesehen 

werden. Die Daten werden mit der Einlagerung automatisch mit einer Annotation und mit einem Eigentümerschutz 

versehen. Der Eigentümer kann die Daten jederzeit verwalten, verändern, gegen unberechtigte Benutzung sperren, 

freigeben und auch löschen. 

Die Import- und Exportschnittstellen unterstützen einen einfachen komfortablen Zugriff auf die Daten für alle 

autorisierten Benutzer. Benutzer sollen dabei auch einen Export in entsprechende Arbeitsumgebungen z.B. auf 

Windows-Grundlage vornehmen können ohne dabei komplexe Anfragen über die übliche DBMS-Schnittstellen wie 

z.B. SQL-Anfragen formulieren zu müssen. 

Die Zugangskontrolle soll aufgrund der Stufung der unterschiedlichen Rollenkonzepte auch schrittweise mehrstufige 

Zugangsmöglichkeiten anbieten, mit denen je nach Berechtigung ein Zugang erfolgen kann. 

Für die Zugangskontrolle und Zugangsabsicherung kann schrittweise eine Anwendungsumgebung mit der Entwicklung 

der Werkzeuge entstehen. Diese Anwendungsumgebung wird in der ersten Ausbauphase die Effizienz der 

Arbeit des Datenmanagers verbessern. Sie wird in der zweiten Phase ausgebaut zu einem Werkzeug der Eigentümer 

von Daten. 

Die Zugangskontrolle und -steuerung soll einen einfachen und komfortablen Zugriff auf entweder Daten und 

Metadaten oder Daten allein oder Metadaten allein ermöglichen. Es kann schrittweise zur Zugangssteuerung ein 

Zugangsprofil für Benutzer und ein Zugangsportfolio für die Benutzung entwickelt werden. Das Zugangsprofil be- 

IS ADD


schreibt die Rechte, Pflichten und Verbote für die Benutzer. Das Zugangsprofil beschreibt die Benutzung der Daten. 

Da mit einer schrittweisen Benutzung der Daten auch eine Erschließung vorenthaltener Daten möglich ist, muß das 

Zugangsportfolio auch das Tracking der wiederholten Benutzung von Daten erlauben. 

Werden Daten weiterverwendet,dann muß auch mit den Originaldaten die Weiterbenutzung mitgeführt und dem 

Eigentümer der Originaldaten die Weiterverwendung bekannt gegeben werden. Deshalb sollte im Exzellenzcluster 

auch eine entsprechende Tracking Software schrittweise entwickelt werden, mit der das Tracking für das Nachvollziehen 

der Benutzung von Daten durch Dritte erfolgt. Es können dazu moderne Ansätze der Dortmunder Sicherheitsarbeitsgruppe 

angewandt werden. 

Mit der Installation einer effizienten Zugangskontrolle kann auch ein data discovery service mitinstalliert werden, 

mit der Benutzer für freigegebene Daten die Mitbenutzung initiieren und vertraglich absichern können. Ein Benutzer, 

der Daten benötigt, kann durch entsprechende Suchanfragen nach benötigten Daten fragen, die Benutzungsbedingungen 

einsehen und die Mitbenutzung je nach Freigabestatus erwirken. Mit einer Mitbenutzung wird ein ‘privacy 

contract’ abgeschlossen, der die automatische Kopplung der exportierten Daten mit den Originaldaten auslöst. 

Intelligente Integration neuer und älterer Daten in existierende Datenbestände. 

Ältere Daten eines Projektes sind oft noch in Dateiform erstellt und abgespeichert worden. Diese Dateien sind 

mit Erfassungs- und Aufzeichnungswerkzeugen entstanden, die z.T. eigene proprietäre Datenformate verwenden bzw. 

auch durch neuere Werkzeuge ersetzt worden. Deshalb geht mit einer Datenverwaltung auch eine Umformatierung 

der Daten einher. Die Umformatierung kann durch entsprechende Import-Werkzeuge der existierenden Datenbank- 

Management-Systeme z.T. unterstützt werden. Mit der Umformatierung kann auch die Ergänzung der Daten um 

entsprechende vorhandene oder erzeugbare Metadaten erfolgen. 

Diese älteren Dateien erfordern auch bei einer Weiter- und Wiederverwendung vorhandener Daten eine neue 

Anpassung der Dateien an die Anforderungen der Weiter- und Wiederverwendung. Da die Werkzeuge ebenfalls durch 

neuere Werkzeuge ersetzt werden, ist diese Umsetzung auch für die bereits vorhandenen Daten erforderlich. 

Das Problem der Migration von älteren Datenbeständen auf neuere Verwaltungsmechanismen entsteht auch in 

analoger Form bei der Integration von Fremddaten. Es exisiteren z.T. bereits Werkzeuge zum Import von Fremddaten. 

Die Vielfalt der Fremddatenquellen erfordert allerdings eine gute Unterstützung dieser Importe. Es gibt zu 

bestimmten Datenbeständen bis zu 2.000 verschiedene Formate und Profile. Deshalb ist eine Automatisierung beim 

Import erforderlich. 

Die Integration von Fremddaten in eigene Datenbestände ist ebenfalls mit einer Reformatierung verbunden. 

Gleichzeitig sollten Fremddaten um entsprechende Metadaten angereichert werden. Zu diesen Metadaten gehören 

nicht nur geo-referenzierte oder temporale Daten, sondern auch Daten über die Qualität der Fremddaten, über die 

Bedingungen der Benutzung, über Eigentumsverhältnisse und die bereits erfolgte Verwendung dieser Daten. Da die 

gleichen Fremddaten nicht nur von einer Quelle bezogen werden, ist eine entsprechende Zurückverfolgung auf die 

Ursprungsdaten angeraten, damit eine wiederholte Verwendung der gleichen Daten sichtbar werden sollte. 

Deshalb ist es sinnvoll, die beiden Probleme als zu einem Komplex zusammenzuführen. Mit der Entwicklung 

eines Datenmangement kann deshalb auch eine Technologie zur intelligenten Integration von Datenbeständen in 

vorhandene Datenbestände und zur Migration von Altdaten gleichzeitig entwickelt werden. 

Im Verlaufe der Entwicklung der Konzepte des Datenmanagement können moderne Konzepte des Datenmanagement 

und des Software-Engineering erschlossen werden. Es ist vorgesehen einen generischen Import auf der 

Grundlage von Zugängen der Programmierung im Großen zu konzipieren, zu erproben und in adäquater Form bereitzustellen. 

Parallel zur Entwicklung einer intelligenten Integration neuer und älterer Daten in existierende Datenbestände 

kann eine Aufarbeitungssoftware für intelligente Annotation der Neudaten konzipiert und erprobt werden. Die Annotation 

ist gewöhnlich eine arbeitsintensive Aufgabe, der sich Benutzer nur ungern stellen. Wird dagegen nur der Teil 

der Annotation abgefordert, der nicht generiert werden kann, dann wird diese Aufgabe aufgrund des entstehenden 

Mehrwertes sehr schnell akzeptiert. 

Anforderungen an das Datenmanagement. 

Das Datenmanagement sollte zu einem Projektdatenmanagement ausgebaut werden. Es begleitet das interne 

IS ADD


Daten-Handling, die Auslieferung und den Export an Datenzentren. Durch die Vielzahl der Formate ist mit dem 

Datenmanagement die Entwicklung eines Export-Generators verbunden, der sowohl den täglichen Export, als auch 

die endgültige Datenablage sowie auch die adäquate Dokumentation durch entsprechende Metadaten erlaubt. 

Das Projektdatenmanagement kann für die dritte Entwicklungsetappe vorgesehen werden. Es sollte auf entsprechenden 

Rahmenwerken basieren, die eine Kollaboration unterstützen. Solche Rahmenwerke existieren partiell bereits, 

wie z.B. das MesoCosm Experiment. 

Ein zentrales Management des Exports ist dabei weniger anzustreben. Stattdessen sollte eine Beratungsmöglichkeit 

existieren. Die Entwicklung eines Compilationswerkzeuges für den Export von eigenen Daten bei gleichzeitigem 

Ausweis der mitverwendeten Daten Dritter erlaubt den Arbeitsgruppen einen automatischen Export von Daten je nach 

Kollaborationsabkommen mit den Datenzentren und den Partnern. 

Die gleichen Mechanismen werden auch für den Import benötigt. Dazu sind die entsprechenden Formate der 

einzelnen Datenzentren aufzunehmen, zu verallgemeinern, mit den Formaten der Daten im Exzellenzcluster zu harmonisieren 

und durch entsprechende Integrations- und Abbildungsalgorithmen zu unterstützen. 

Nach Ausbau des Projektdatenmanagement kann auch ein Projekt zum Qualitätsmanagement für die eigenen 

Daten der einzelnen Arbeitsgruppen des Exzellenzclusters angestoßen werden. Dieses Qualitätsmanagement sollte 

auch erlauben, die Daten je nach Granularität und Abstraktion miteinander zu verbinden, so daß auch bei aggregierten 

Daten eine Qualitätsaussage auf der Grundlage der Qualität der Grunddaten abgeleitet werden kann. 

Die Erfassung der Daten muß möglichst mit einer automatischen Erfassung der Metadaten gekoppelt werden. 

Die erhobenen Daten müssen sicher archiviert werden. Diese beiden Aufgaben sollen zudem mit möglichst geringem 

Aufwand bewältigt werden. 

Durch ein zentrales Datenmanagement sollen mit möglichst geringem Aufwand die Aufwendungen für das Datenmanagement 

in den einzelnen Arbeitsgruppen und durch die einzelnen Wissenschaftler minimiert werden. Es 

sollen die Arbeitsgruppen eine Unterstützung bei der (Meta-)Datenerfassung durch automatische Erfassung der operativen 

Daten und durch Integration vorhandener Systeme erhalten. Weiterhin sollen schon vorhandene Teillösungen 

integriert und damit auch für andere Arbeitsgruppen erschlossen werden. 

Mit einem zentralen Datenmanagement kann auch eine Menge von Schnittstellen für den Export an und den 

Import von vorhandene/n Daten-Server bzw. Datenzentren erleichtert werden. 

Angestrebt wird eine praktikablere Lösung als die derzeitige. Es wird eine schnelle Realisierung erwartet. Außerdem 

kann damit eine dauerhafte Pflege mit realisiert werden. Den Arbeitsgruppen kann ein kontinuierlicher Support 

gegeben werden. 

Zu einem späteren Zeitpunkt kann auch die Datenassimilation, mit den dynamischen Verläufen verbunden werden 

können, in Angriff genommen werden. Es wird damit möglich, Daten mit dynamischen Abläufen zu integrieren und je 

nach Interessantheit zu präsentieren. Damit kann dann auch mit einer extrapolatorischen Simulation eine Abschätzung 

der Entwicklung von Variablen vorgenommen werden. 

IS ADD


5.2 Necessity of Data, Information and Knowledge Management 

5.2.1 Problems of Data Management 

Typical Pitfalls of Data Management and Their Solution. 

Data are the main source for information and knowledge in research projects. They are used for deduction and 

exploration of hypotheses, for validation of hypotheses, for support of theories, and for illustration of behaviour or 

prediction of future behaviour. Their quality properties have been neglected for a long time. At the same time, modern 

data management allows to handle these problems. We compare the critical findings in the sequel with resolution 

techniques that can be applied to overcome the crucial pitfalls of data management in environmental sciences. 

Problems observed 

Neglection of evolution: Data(base) models and 

databases can be versioned, shared, and reused. 

Each phase can lead to refining previous decisions, 

understandings, and changes due to external 

influences. 

Invisible or missing models: Data that deliver project 

value must be accessible, understandable, and 

sharable. Models need to be available in an easily 

searchable manner. 

Missing exchange of understanding: Data and data 

models developed within one team are not communicated 

to other teams. These teams have an 

unclear and inconsistent view on the data. They 

use however these data within their understanding. 

Thinking that models are only about data structuring: 

Data(base) models are restricted to the 

conceptual or logical schemata. The additional 

DBMS information is not well kept. 

Throwing data structures ‘over the wall’: Data 

structures are seen as early decisions without continuous 

change and deployment management. Data 

used at a later stage are kept prone to errors. 

Forgetting about the sizzle: Data should be clear 

and understandable in a collaboration. Often, they 

are not accompanied with information that allow 

to follow the intent and meaning of the data. 

Thinking of data sets as “your” set: Data sets are 

treated as if the researcher personally owns them. 

They are not presented as belonging to the cluster 

business and tended to by the researcher. 

Integration without insight into the meta-data: Data 

are commonly used in different projects, partially 

changed in some of them for purging or adaptation, 

differently associated to metadata and 

restructured or partially selected or aggregated. 

Their integration leads to data sets with high redundancy 

and data conflicts. 

Problems of Data Management Observed in Research Projects. 

Their handling and resolution 

Database tools are designed to facilitate refinement and traceability. 

They support roundtrip modelling, comparison and merging, 

versioning, universal naming, and denormalisation mapping. 

Database modelling can help a project team ensure that appropriate 

data are available. Typical solutions on the basis of models 

are data reporting, repository management, and common dictionary. 

Interactive ‘intranets’ based on common repository management 

support structured collaboration based on guidance and documentation, 

explicit communication of goals, benefits and deficiencies, 

and maintenance of metadata. 

Data management includes metadata import and export, traces 

of data evolution, tools for usage tracking, export and import 

integration, macros for development of reports and scripts, and 

attachment generation. 

Data management generates and modifies data massives and ensures 

that there is a consistent link between the data and their 

history. It also includes changes within the structure and ensures 

that changes stay true to the original intent of the first structuring 

decisions. 

Data management can assist the data provider for presenting the 

data in the right form, the right format, the right size and structuring, 

at the right moment and under consideration of the user’s 

information demand. The macro features extend and customise 

data delivery to meet the demand. 

Data set should be seen as corporate assets to be managed by a 

partnership within collaborating groups. Support can be generically 

provided for open sharing, for access to those who want 

it, offering metadata on how to understand the data and making 

every effort to deploy them clear and understandable. 

Entity resolution, record matching and data cleansing techniques 

support integration of data based on common sources. History 

tracking for data sets allows to trace back the data to their origin. 

Data sets can be extended by profiles. Computed data can be 

marked as such. Aggregation of data must be recorded as well as 

other data generating computations. 

We have analysed data management problems in research clusters. This analysis led to a list of problems. This list 

is not comprehensive. In Section 5.2.3 we analyse these problems systematically and show pathes for their solution.


Data not recorded properly. This occurs in research programs when the data are not recorded in accordance with 

the accepted standards of the particular academic field. This is a very serious matter. Should another researcher 

wish to replicate the research, improper recording of the original research would make any attempt to 

replicate the work questionable at best. Also, should an allegation of misconduct arise concerning the research, 

having the data improperly recorded will greatly increase the likelihood that a finding of misconduct will be 

substantiated. 

Data management not supervised by PI. In this situation the principal investigator might inappropriately delegate 

his/her oversight responsibilities to someone in his/her lab that is insufficiently trained. Another situation might 

arise if the principal investigator simply does not dedicate the appropriate time and effort to fulfill responsibilities 

related to proper data management. 

Data not maintained at the institution. This situation could occur in a collaboration in which all data is maintained 

by one collaborator. It would be particularly problematical if each collaborator is working under a sponsored 

project in which their institutions are responsible for data management. In other cases, researchers might maintain 

data in their homes, and this can also present problems of access. 

Data not stored properly. This could occur with research, financial, and administrative data. Careless storage of the 

data that could permit its being destroyed or made unusable is a significant matter. In such case, the institution 

and/or researcher have acted negligently, have not fulfilled their stewardship duties, and have violated sponsor 

policies as well as the terms of the sponsored agreement. 

Data not held in accordance with retention requirements. As noted previously, it is absolutely essential that those 

involved with sponsored projects know how long different kinds of data must be retained to satisfy all compliance 

requirements as well as to offer appropriate support in the event of lawsuits or disputes over intellectual 

property. 

Lack of data validation. Projects that are centered on data can be challenging to test. For a research project to be 

truly successful, a solid data validation plan is required both during the utilisation of data and also as part 

of an ongoing data analysis process. If data management only validates the inputs and outputs of the data 

gathering, it will become susceptible to downstream issues. Therefore, it’s imperative that thorough end-to-end 

data validation testing is anticipated and completed. 

Data not retained by the institution. This is a major problem that would occur if a researcher leaves the institution 

and takes the original research data and does not leave a copy at the institution. In the event access is needed, it 

places the institution in an untenable position since it has not fulfilled its fiduciary responsibility to the sponsor. 

Lack of appropriate master data management. MDM represents the crucial reference data that defines the dimensions 

of a research project and how its associates should report information. It’s common for a single project 

to embark on an MDM implementation focusing solely on how they define their data elements and entities. 

Trouble arises when this activity detracts from a research cluster standard or produces information inconsistent 

with the viewpoint of research cluster leadership. For an MDM implementation to be successful, PIs must see 

the value of the initiative and act in an enforcement role to ensure accountability amongst various projects. This 

is especially true when process re-engineering and data governance initiatives come into play. 

Not focusing on data exploration and analysis processes. It’s common to think that technology automation can act 

as an acceptable alternative to a defunct operational process. This couldn’t be farther from the truth and may 

in fact be the main contributor to failed MDM implementations. In order to create a single view of a reporting 

entity, for example, ocean surface temperature, a project must include ample time for process optimization and 

re-engineering. At each stage of the data chain, from point of origin and data entry through data consolidation 

and reporting, clear business processes are necessary to support the flow of data and, ultimately, the integrity of 

that data. This is where executive buy-in plays an important role, since it is common for business units to resist 

change and potentially surrender control. PIs must be prepared for difficult discussions around standardized 

processes and the role of data stewardship.


Lack of data governance. At the core of data management are the business rules, decision rights and PIs that ensure 

a data management solution is not just a project with a specific end date, but an ongoing program and core 

competency for the organization. As part of the data governance component of an data management, many 

areas need to be addressed, including data terminology and taxonomies, data stewardship, decision rights, 

accountability, corporate policies and standards. Components for predeployment and postdeployment stages 

are must also be addressed. 

Starting big, ending small in data management projects. Many implementers think a data management initiative 

must start with a clean slate, break down all of the silos and rebuild Rome. Trying to redefine how data are 

managed in cluster units is going to be a multiyear initiative with a project scope that becomes a moving target. 

Any “big bang” program is dangerous on many levels, but mainly because we live in a world of uncertainty. 

Unplanned data gathering. Data gathering is usually done at one of the following extremes: Either too much irrelevant 

data or too little relevant data. In the data-gathering phase, project teams usually gather so much data that 

no one uses it or so little data that everyone involved in the planning process does not feel comfortable making 

a decision based on limited information, so they use their experience and opinion. We find too often that data 

is too old. The data is out of date before it is used. 

Typical Pitfalls Restricting Data Exchange in Collaborations. 

siehe workshop 

Problems observed 

Neglection 


1001 input formats 

1001 export formats 

Typical Mistakes of Data Management Caused by Immature Workflows. 

Data management processes need a proper support and thus are also reflected within the schemata that are used 

for storing data. The Co-Design approach supports an integrated view on structuring, functionality, distribution, and 

interactivity 

Mistake #1: Failing to ensure multiple business objects can be managed within a single co-design management 

platform. When you select and deploy an co-design management platform make sure it is capable of managing 

multiple business objects such as measurements, records, and aggregations all within the same software 

platform. By doing so, system maintenance is simplified and more cost effective which results in lower total 

cost of ownership. A less favorable alternative is to deploy and manage separate master data solutions that each 

manages a different business data entity. However, this approach would result in additional system maintenance 

and integration efforts and a higher total cost of ownership. Another advantage of an co-design management 

platform which can handle multiple data types is that implementation can begin with a single business object 

like measurement, and can later be extended to accommodate other business object types — resulting in rapid 

return on investment. 

Mistake #2: Ignoring data governance needs at the project- or enterprise-level. Data governance is unique to each 

and every collaborating community since it is based on the research cluster’s business processes, culture, and 

IT environment. However, research clusters typically select a simple data management platform without much 

thought to their enterprise data governance needs. It is critical that the underlying management platform is 

able to support the data governance policies and processes defined by the cluster. In contrast, data governance 

design could be compromised and forced to adapt to the limitations of some co-design management software


platforms with fixed or rigid data models and functionality. Controls and auditing capabilities are also important 

data governance components. In order to properly support this functionality, requirement prescription should 

be based on a co-design management platform to integrate with your security and reporting tools to provide 

fine-grained access to data and reliable data quality metrics. 

Mistake #3: Failing to ensure the co-design management platform can work with your standard workflow tool. 

Workflow is an important component of both co-design management and data governance, as it can be used 

to approve the creation of a master object definition and to determine, in real-time, which conflicting objects 

survive. Workflow can also be used to automatically alert the data steward of any data quality issues. So in 

preparing a proper master data management, it is important to raise the question of how the co-design management 

platform will integrate with the standard workflow tool that you have selected. Some data management 

vendors bundle their own workflow tool and may not offer integration with your standard workflow tool. None 

of them is however supporting a co-design integration. 

Mistake #4: Failing to ensure the solution supports complex relationships and hierarchies. With a single master 

object hub, such as measurement, hierarchies and relationships are relatively straightforward. For example, 

organizational relationships are depicted as legal hierarchies of parent and child organizations, while measurement 

relationships are those belonging to a common household. On the other hand, hierarchies among multiple 

objects can be highly complex. Make sure your data management is based on a solution that includes modelling 

complex business-to-business (B2B) and business-to-consumer (B2C) hierarchies, along with the definitions 

of those master data entities within the same data management platform. 

Mistake #5: Relying on fixed Service Oriented Architecture (SOA) services. Reliable data is a prerequisite to supporting 

SOA applications—applications that automate business processes by coordinating enterprise SOA services. 

Since co-design management is the foundation technology that provides reliable data, any changes made 

to the co-design management environment will ultimately result in changes to the dependent SOA services, 

and consequently to the SOA applications. IT professionals need to ensure the co-design management platform 

can automatically generate changes to the SOA services whenever its data model is updated with new attributes, 

entities, or sources. This key requirement will protect the higher-level SOA applications from any changes 

made to the underlying co-design management system. In comparison, co-design management solutions with 

fixed SOA services that are built on a fixed data model will require custom coding in order to accommodate 

any underlying changes to the data model. 

Mistake #6: Cleansing data outside of the data management platform. Data cleansing includes name corrections, 

address standardizations, and data transformations. Objects can be efficiently cleansed at the source using 

commonly available data quality tools. In contrast, the number of sources for a cluster-wide master data management 

deployment spans multiple research groups and typically comprises tens or hundreds of systems. In this 

scenario, cleansing the data at the source systems is not viable. Rather, data cleansing needs to be centralized 

within the data management system. If the application has already standardized on a cleansing tool, then it is 

important to ensure the co-design management solution provides out-of-the-box integration with the cleansing 

tool in order to leverage your existing investments. 

Mistake #7: Thinking probabilistic matching is adequate. There are several types of matching techniques commonly 

in use—deterministic, probabilistic, heuristic, phonetic, linguistic, empirical, etc. The fact is, no single technique 

is capable of compensating for all of the possible classes of data errors and variations in the master data. In 

order to achieve the most reliable and consolidated view of master data, the master data management platform 

should support a combination of these matching techniques with each able to address a particular class of data 

matching. A single technique, such as probabilistic, will not likely be able to find all valid match candidates, or 

worse may generate false matches. 

Mistake #8: Underestimating the importance of creating a golden record. For co-design management to be successful 

within an organization, it is not enough to simply link identical data with a registry style because this 

will not resolve inconsistencies among the data. Rather, master data from different sources need to be reconciled 

and centrally stored within a master data hub. Given the potential number of sources across the organization


and the volume of master data, it is important that the master data management system is able to automatically 

create a golden record for any master data type such as measurement, project, tools, etc. In addition, the master 

data management system should provide a robust unmerge functionality in order to rollback any manual errors 

or exceptions—a typical activity in large organization where several data stewards are involved with managing 

master data. 

Mistake #9: Overlooking the need for history and lineage to support regulatory compliance. Today, database users 

in research groups not only demand reliable data, but they also require validation that the data is in fact reliable. 

This is a challenging and daunting undertaking considering that data sets are continually changing with updates 

from source systems taking place in real-time as research and data gathering is being transacted, and while the 

data set is merged with other similar data within the data hub. The history of all changes to master data and the 

lineage of how the data has changed needs to be captured as metadata. In fact, metadata forms the foundation 

for auditing and is a critical part of data governance and regulatory compliance reporting initiatives. As a 

result, and because metadata is such an essential component of co-design management, it is important that data 

management incorporates the need for history and lineage. 

Mistake #10: Implementing co-design management for only a single mode of operation: analytical or operational. 

A cluster-wide data management platform needs to synchronize master data with both operational and analytical 

applications in order to adequately support real-time business processes and compliance reporting across 

multiple research groups. In contrast, data analysis solutions are most often implemented at the research team 

level with the objective of solving a single analysis task. These deployments will typically only synchronize 

data back to either operational or analytical applications but not both. Without the ability to synchronize master 

data with both operational and analytical applications, your ability to extend the data management management 

platform across the organization will be limited. 

Examples of Data, Information and Knowledge Management. 

Archeoinformatics enorme Entwicklung der Datenmenge, auch aufgrund naturwissenschaftlicher Erkenntnisse 

enorme Entwicklung der Komplexität der Daten, vielschichtige Modelle z.B. Karten mit Legenden, Maßstäbe und 

beschriftungen superimposed information data provenenace Einschluß des Raumbezuges von Informatione (absolut, 

relativ z.B. Assoziation oder Nähe, Kontext), Aspekte von Geodaten (Geometrie, Topologie, Sachdaten (Semantik, 

Thematik), Dynamik) Veränderbarkeit des Geobezuges welches Geometriemodell Integration von amtlichen Daten 

(Kataster, Bodendenkmalspflege, Forschungsprimärdaten), INSPIRE Initiative (availability, quality, organisation, accessibility, 

sharing among parties) local storage and maintenance, integratable on demand, interoperability services: 

geoportal, search, representation, download, coordinate transformation data specification for protected sites - guidelines 

Initiative digitale Information (auch z.B. Humboldt, allianzinitiative ADeX Kommission Archäologie und Informationssysteme 

Denkmaldaten, Digicult Initiative OpenContext, ArcheoInf Open Geospatial Consortium www.opengeospatial 

also standards for data exchange basiert auf SOA (Besser Dahanayake/THalheim CMS 2011) Web Mapping Service, 

Simple feature Access, Web Coverage Service, Web Feature Service Web Catalogue Service, Web Processing Service 

Choreography of services 

eine gute Lösung: Standardisierung und Datenhygiene 

Maintenance of Cultural Heritage Broman case 

Überführung textueller Inhalte in elektronische mit Einschluß der Semantik dieser Daten, sowei auch Pragamatik 

5.2.2 Probleme des Datenmanagement in Forschungsprojekten 

Erhebung und Bereinigung der Daten.


In Forschungsprojekten fallen nicht nur riesige Datenmengen an, die effizient und effektiv verwaltet werden 

müssen, sondern insbesondere Daten in unterschiedlicher Granularität, Präzision, in unterschiedlichen Formaten und 

unterschiedlichen Gültigkeiten an. Von besonderer Schwierigkeit sind dabei noch Sensordaten, deren Qualität je nach 

Erhebungsbedingungen, je nach Erhebungsauftrag, je nach Ablagemöglichkeit und je nach sofortiger Weiterverarbeitung 

zu unterschiedlichen und nicht vorhersehbaren Verfälschungen führt, was sich auf die Qualität der Auswertung 

nachhaltig auswirkt. 

Daten fallen im allgemeinen mit Metadaten an. Neben georeferziellen und temporalen Daten sind z.B. auch die 

Daten zur Charakterisierung der Erhebung wichtig. Die Sensordaten können z.B. zusammen mit den Kalibirierungsdaten 

gespeichert werden. Damit ist eine nachträgliche Bereinigung der Daten möglich, falls eine Kalibirierung zu 

lange zurückliegt. Es werden mit einer nachträglichen korrektiven Umrechnung Daten von höherer Qualität erhalten. 

Die Qualität der Daten kann besser beurteilt werden, wenn die Kalibrierung beurteilbar bleibt. 

Hinzu kommt, daß die marin-geowissenschaftliche Datenerfassung unter schwierigen Bedingungen stattfindet 

und damit Fehler nicht zu vermeiden sind. Selbst die technische Installation zur Datenerfassung ist bereits schwierig. 

Damit ist auch die Erhebung von Qualitätsdaten eine schwierige Aufgabe in Forschungsprojekten. 

Die erhobenen Daten sind zumeist einzigartig, nicht einfach wiederholbar oder wiederbeschaffbar. Eine nachträgliche 

Ergänzung und Erweiterung selbst um Metadaten ist oft nicht möglich. Eine Wiederbeschaffung der Daten 

scheitert auch an den sich ständig verändernden Verhältnissen. Daten, die nicht wiederbeschaffbar sind, sind für 

Auswertungen nicht zugänglich und verfälschen durch ihre Nichtexistenz die Auswertungen. Damit wird auch die 

Glaubwürdigkeit der Ergebnisse eines Forschungsprojektes negativ beeinflußt. 

Damit sind selbst innerhalb einer Gruppe diese Daten nur dann konsistent und vollständig in den Projekten verwendbar, 

wenn diese Daten einer Integration, einer Aufbereitung, einer Reinigung und einer sinnvollen Zusammenfassung 

zugeführt werden. 

Die Erhebung und Bereinigung der Daten erfolgt derzeit noch in jeder Arbeitsgruppe eines Forschungsprojektes. 

Es stehen weder Werkzeuge für die gleichzeitige Erhebung und Aufbereitung, noch für die Integration von Datenbeständen 

anderer zur Verfügung. 

Die Zuordnung und die Werte der Metadaten kann auch während einer Fahrt divergieren. So kann z.B. der Stationsbezeichnung 

von Gruppen unterschiedlich gehandhabt werden. Deshalb sind entsprechende Alias-Techniken 

besonders hilfreich zur Wiederherstellbarkeit der realen Übereinstimmung der Stationsdaten. 

Ablage der erhobenen, bereinigten und aufbereiteten Daten. 

Durch zentrale Anlaufstellen im Forschungsprojekt wird oft als Service die Entgegennahme und Abspeicherung 

der Daten in dem Format gewährleistet, in dem die Daten geliefert wurden. Dieser Service ist das Maximale, das z.Z. 

geleistet werden kann. Notwendig wäre dagegen eine sichere (Langzeit-) Archivierung. 

Zusätzlich sollte jederzeit ein leichter Zugang zu den Daten für authorisierte Benutzer möglich sein. Dieser Zugang 

sollte auch im Remote-Betrieb von jedem Rechner und jedem Standort aus erfolgen können. Dazu bedarf es 

allerdings einer Aufarbeitung der Daten. Diese Aufarbeitung wird entweder vom Wissenschaftler, der die Daten 

einlagern läßt manuell zum Einlagerungszeitpunkt erledigt oder wird auf einen späteren Zeitpunkt verschoben und 

damit meist nicht mehr ausgeführt. Deshalb könnte eine Software, die eine automatische Ergänzung vornimmt, sehr 

hilfreich sein. 

Mit der Einlagerung sollten auch Mechanismen zur Benutzung der Daten in breiterem Maße bereitgestellt werden. 

Bei der Benutzung ist allerdings erforderlich, daß eine Nachvollziehbarkeit der Benutzung durch Dritte gewährleistet 

wird. Deshalb muß mit der Herausgabe der Daten auch eine Protokollierung der Weiterverwendung erfolgen. 

Es kann der guten wissenschaftlichen Praxis überlassen werden, ob ein gebührender “Credit” bei der Benutzung 

erfolgt. Günstiger wäre allerdings eine automatische Annotation bei einer weiteren Einstellung von Fremddaten- 

Bestandteilen in den eigenen Publikationen. 

Die Daten müssen mit entsprechenden Metadaten abgelegt werden. Zu den Metadaten gehören neben den Daten 

zur Erhebung, zu den verwendeten Verfahren auch die geographischen und die temporalen Daten. Diese Metadaten 

können durch eine Erweiterung der Graphical Markup Language (GML) zu einer Oceanography Markup Language 

(OML) einheitlich erfaßt werden. Dazu kann die OML als eigenständige Entwicklung im Rahmen eines Meeres- 

Forschungsprojektes als Projektaufgabe konzipiert werden. 

Jeder Benutzer und jeder Erheber von Daten hat seinen eigenen Arbeitsstil und seine eigene Herangehensweise


an die Arbeit mit Daten. Benutzer bearbeiten und verändern Daten anhand der konkreten aktuellen Aufgabenstellung. 

Eine spätere Dokumentation des Verwendungszweckes, der getätigten Zusammenfassungen, der Korrekturen 

etc. ist nicht nur aufwendig, sondern oft auch nicht mehr möglich. Damit können auch Daten verwendet werden, 

die unerkannterweise Duplikate sind, von denen man nicht mehr die Assoziation zum Original herstellen kann und 

die damit aufgrund des Vorhandenseins, aufgrund der Art der Aggregation und aufgrund der Nachbearbeitung zu 

Verfälschungen in Analysen führen können. 

Befähigung der Arbeitsgruppen zur Zusammenarbeit auf der Grundlage von Daten. 

Benutzer von Daten verfügen selten über eine tiefgründige Informatikausbildung, sondern erwarten eher einen 

einfachen und komfortablen Zugriff auf alle vorhandenen Daten und die Meta-Daten. Dies sollte durch entsprechende 

Schnittstellen ermöglicht werden. Benutzer erwarten darüber hinaus auch mehrstufige Zugriffsmöglichkeiten, je 

nachdem Mikro-, Meso- oder Makrodaten 2 benötigt werden. Außerdem wird auch ein mehrstufiger Zugriff auf bereinigte 

und prozessierte Daten benötigt. 

Die Benutzung der Daten muß auch so einfach sein, daß Daten innerhalb der Anwendungsumgebung des Benutzers 

auf einfache Art integriert werden können. Dies spricht für die Entwicklung eines Datenaustauschformates auf 

XML-Basis innerhalb des gesamten Forschungsprojektes. 

Der Datenaustausch innerhalb und zwischen den Arbeitsgruppen basiert derzeit z.T. noch auf Formaten der 

Office-Suite wie z.B. unterschiedlich formatierten und damit paarweise inkompatiblen Excel-Spreadsheets. Diese 

Daten werden außerdem oft noch per Email ausgetauscht. Mit Werkzeugen zum Projektdatenmanagement, die zum 

einem nur den authorisierten Benutzern den Zugriff und die Modifikation der Daten gestatten, auf die spezifische 

Arbeitsweise der Projekte konfigurierbar sind und die einen automatisierten Import der Daten in das zentrale Datenbanksystem 

des Forschungsprojektes vornehmen, kann der problematische Datenaustausch innerhalb und zwischen 

den Arbeitsgruppen überwunden werden. 

Die Benutzer sehen sich derzeit größeren Schwierigkeiten gegenüber, wenn Daten durch die Benutzer analysiert 

werden sollen. Günstig wäre ein “data discovery service”, mit dem die Hypothesenerarbeitung und -überprüfung 

interaktiv erfolgen könnte. Dann kann ein Wissenschaftler mit seinen eigenen Daten experimentieren. Derzeit hängt 

dies vom Geschick der Benutzer und von der richtigen Auswahl und Installation entsprechender Werkzeuge innerhalb 

der eigenen Rechnerumgebung ab. 

Es gibt bereits eine ganze Reihe von Visualisierungstools, mit denen eine Illustration von Resultaten auf sehr 

einfache kognitive Weise möglich wird. Die Installation und Pflege dieser Tools ist jedoch relativ aufwendig, so daß 

diese Werkzeuge nur selten angewandt werden. Durch eine zentrale Installation und Pflege kann dieser Mangel jedoch 

behoben werden. 

Da die Daten relativ isoliert erhoben, isoliert in den Arbeitsgruppen verwaltet und analysiert werden, ist eine 

mehrfache Benutzung der Daten durch mehrere Arbeitsgruppen im Forschungsprojekt derzeit nur selten gegeben. 

Damit erheben nicht nur Arbeitsgruppen Daten, die andere Arbeitsgruppen bereits besitzen und direkt verwendet 

werden könnten, nochmals, sondern können Daten, die mit den eigenen Daten zu hohem gemeinsamen Nutzen 

kombiniert werden können, nicht in die Analysen mit einbeziehen. Damit wird auch die Konkurrenzfähigkeit des 

Forschungsprojektes geschwächt. 

Daten werden ggf. auch zum Vergleich, zum Verstehen von Verläufen bewußt mehrfach an gleichen Orten erhoben. 

Für diese Daten ist eine einfache und bequeme Assoziation mit den bereits vorhandenen Daten eine Voraussetzung 

für die Analyse. 

Bereitstellung der aufbereiteten Daten an Dritte. 

2 Daten können neben den direkten Erhebungsdaten auch aufbereitete und aggregierte Daten sein. Typische Daten unterschiedlicher Aggregation 

sind Monatsmittelwerte, Jahresmittelwerte, Tiefenprofile und Oberflächenwerte. Die Monatsmittelwerte können z.B. als Mesodaten 

nicht einfach aufgrund der unterschiedlichen Monatslängen zu Jahresmittelwerten zusammengefaßt werden. Auswertungen beruhen auf 

Makrodaten, die allerdings zu den Meso- und Mikrodaten führen müssen. Die Initiativen zur Mitführung von Basisdaten neben den Makrodaten 

bei Publikationen, bei Auswertungen und bei Analysen zeigen hier einen Weg. In der Vergangenheit hat die Nichtassoziierbarkeit 

von Auswertungs- und Publikationsdaten mit den Grunddaten, die Nichtnachvollziehbarkeit der Auswahl der Daten (“Verschnitt”) zu einem 

Glaubwürdigkeitsverlust geführt.


Daten werden nicht nur für das Forschungsprojekt erhoben, sondern sind anderen Benutzern wie z.B. entsprechenden 

Datenzentren aufgrund von Verträgen, als Bestandteil einer “guten Praxis”, zur Begleitung von Publikationen, zur 

Erhöhung der Sichtbarkeit und der Reputation, für weitere Publikationen und für die Wieder- und Weiterverwendung 

der Daten zur Verfügung zu stellen. Dieser Export von Daten beansprucht einen erheblichen Teil der Arbeitszeit der 

beteiligten Wissenschaftler und ist bei fast allen Gruppen des Forschungsprojektes in analoger Form zu bewältigen. 

Da die Daten auch mehreren Datenzentren zur Verfügung gestellt werden und auch weiter verwendet werden, 

entsteht mit der unzureichenden Annotation über den Ursprung und die Qualität von Daten außerdem noch das 

Problem der Vervielfältigung von gleichen Daten ohne diese auf den Ursprung zurückführen zu können. Deshalb 

ist es oft für einen Wissenschaftler schwierig oder auch unmöglich, verläßliche Analysen auf wiederholenden Daten 

auszuführen. Oft werden Zusatzdaten wie z.B. Georeferenzierungen oder Zeitdaten in widersprüchlicher Form diesen 

Daten hinzugefügt. 

Das Forschungsprojekt benötigt zum einem automatisierte Verfahren zum Export von Daten an die verschiedenen 

Datenzentren und zum anderen automatisierte Verfahren zur Anreicherung der Daten um Metadaten wie Zeitdaten 

und Georeferenzierungen. Diese Verfahren würden die Auswertungs- und Weitergabearbeit der Arbeitsgruppen eines 

Forschungsprojektes wesentlich erleichtern und eine ständige Neueinarbeitung neuer Mitarbeiter in diffizile Datenformate 

der Datenzentren vermeiden. 

In Forschungsprojekten werden Daten in großem Umfang erhoben. Diese Daten müssen den entsprechenden 

Zentren zur Verfügung gestellt werden. Diese Aufgabe erfordert eine kluge Automatisierung. 

Wenn eine Suite von Exportschnittstellen existieren würde, dann könnte auch in analoger Weise eine Suite von Exportschnittstellen 

zu Auswertungswerkzeugen wie z.B. MathLab, Statisitk-Systemen und Data-Mining-Werkzeugen 

in analoger Form die Arbeit der Wissenschaftler erleichtern. Damit würde zugleich auch die Arbeitsfähigkeit der 

Arbeitsgruppen verbessert. 

Daten müssen ebenfalls oft gezielt neben einer Ergänzung einer Bereinigung zugeführt werden. Sensordaten sind 

selbst bei modernster Technik fehlerbehaftet und deshalb oft nicht in der ursprünglichen oder nur in bereinigter Form 

weiter zu verwenden. Die Reinigung bzw. die Mitführung von Fehlern und Bereinigungsinformationen ist deshalb 

eine Aufgabe für die Automatisierung. 

Auswertungsmethoden werden aufgrund neuer Erkenntnisse oder aufgrund von Erfahrungen auch durch andere 

Auswertungsmethoden ersetzt, die dann zu anderen Ergebnissen über dem gleichen Datenbestand führen können. 

Deshalb ist auch zusammen mit der Aggregation und der Anwendung von Auswertungsmethoden sowohl die verwendete 

Methode als auch die spezifischen Aufgabenportfolio und Benutzungsprofile mit den aggregierten Daten 

zu speichern. Bei einer Verwendung von Basisdaten durch Dritte ist ggf. auch die Benutzung dieser Daten bei den 

Basisdaten mitzuführen. 

5.2.3 SWOT Analysis of Problems of Data Management in Research Projects 

SWOT analysis is a strategic planning method used to evaluate the Strengths, Weaknesses, Opportunities, and Threats 

of a project. A SWOT analysis usually starts by defining an end state or objective. The aim of any SWOT analysis 

is to identify the key internal and external factors that influence the achievements of this objective. SWOT analysis 

thereby groups key pieces of information into categories: 

• Internal factors: The internal strengths and weaknesses of the proposed project. 

• External factors: The opportunities and threats presented by the external environment to the project. 

The internal factors may be viewed as strengths or weaknesses depending upon their impact on data management 

objectives. What may represent strengths with respect to one objective may be weaknesses for another objective. 

The external factors may include market opportunities and threats, technological change, legislation, and political


considerations. 

Data Quality Problems. 

Integration of Temporal and Spatial (Meta)Data. 

Extraction and Purging of Data. 

Auch in Forschungsprojekten fallen nicht nur riesige Datenmengen an, die effizient und effektiv verwaltet werden 

müssen, sondern insbesondere Daten in unterschiedlicher Granularität, Präzision, in unterschiedlichen Formaten und 

unterschiedlichen Gültigkeiten an. Von besonderer Schwierigkeit sind dabei noch Sensordaten, deren Qualität je nach 

Erhebungsbedingungen, je nach Erhebungsauftrag, je nach Ablagemöglichkeit und je nach sofortiger Weiterverarbeitung 

zu unterschiedlichen und nicht vorhersehbaren Verfälschungen führt, was sich auf die Qualität der Auswertung 

nachhaltig auswirkt. 

Daten fallen im allgemeinen mit Metadaten an. Neben georeferziellen und temporalen Daten sind z.B. auch die 

Daten zur Charakterisierung der Erhebung wichtig. Die Sensordaten können z.B. zusammen mit den Kalibirierungsdaten 

gespeichert werden. Damit ist eine nachträgliche Bereinigung der Daten möglich, falls eine Kalibirierung zu 

lange zurückliegt. Es werden mit einer nachträglichen korrektiven Umrechnung Daten von höherer Qualität erhalten. 

Die Qualität der Daten kann besser beurteilt werden, wenn die Kalibrierung beurteilbar bleibt. 

Hinzu kommt, daß die marin-geowissenschaftliche Datenerfassung unter schwierigen Bedingungen stattfindet 

und damit Fehler nicht zu vermeiden sind. Selbst die technische Installation zur Datenerfassung ist bereits schwierig. 

Damit ist auch die Erhebung von Qualitätsdaten eine schwierige Aufgabe für Forschungsprojektcluster. 

Die erhobenen Daten sind zumeist einzigartig, nicht einfach wiederholbar oder wiederbeschaffbar. Eine nachträgliche 

Ergänzung und Erweiterung selbst um Metadaten ist oft nicht möglich. Eine Wiederbeschaffung der Daten 

scheitert auch an den sich ständig verändernden Verhältnissen. Daten, die nicht wiederbeschaffbar sind, sind für 

Auswertungen nicht zugänglich und verfälschen durch ihre Nichtexistenz die Auswertungen. Damit wird auch die 

Glaubwürdigkeit der Ergebnisse eines Forschungsprojektclusters negativ beeinflußt. 

Damit sind selbst innerhalb einer Gruppe diese Daten nur dann konsistent und vollständig in den Projekten verwendbar, 

wenn diese Daten einer Integration, einer Aufbereitung, einer Reinigung und einer sinnvollen Zusammenfassung 

zugeführt werden. 

Die Erhebung und Bereinigung der Daten erfolgt derzeit noch in jeder Arbeitsgruppe eines Forschungsprojektclusters. 

Es stehen weder Werkzeuge für die gleichzeitige Erhebung und Aufbereitung, noch für die Integration von 

Datenbeständen anderer zur Verfügung. 

Die Zuordnung und die Werte der Metadaten kann auch während einer Fahrt divergieren. So kann z.B. der Stationsbezeichnung 

von Gruppen unterschiedlich gehandhabt werden. Deshalb sind entsprechende Alias-Techniken 

besonders hilfreich zur Wiederherstellbarkeit der realen Übereinstimmung der Stationsdaten. 

Inadequate Namespaces and Inadequate Naming. 

Non-appropriate names: Names from the namespace are used for identification and recognition of data.Names are 

however sometimes casual, not in accord with prescribed form, unofficial, or simply inappropriate for the 

intended use. Namesspace must provide a means to select names in a formal, structured, nomencladure and 

taxonomic manner. 

Problems: Typical problems that we have observed for research projects as well in industrial settings are the 


Names without meaning: Attribute names like Name carry too many meanings such as in a customer 

table the organisation, a person, a contact person, the supervisors etc. names. 

Non-unique names without resolution convention: The symbols used for names can be reused in different 

types as long there is a resolution strategy for extension of names by their corresponding type 

name and there is a unique name assumption for entity, cluster and relationship types. If however the


two assumption are not valid then there is no resolution uniqueness for names. Otherwise we have to 

use synonym and homonym constraints. 

Structureless naming: Name components are put together without any systematics by picking some 

words together. 

Incorrect names: Names are sometimes used without any intention or later changed to other meaning 

without changing the text string. 

Most overused attribute names are Comment and Explanation without have the intention to 

comment or explain something. 

Incorrect abbreviations Especially after transformation data from Excel spreadsheets many abbreviations 

occur without having a chance to understand their real meaning. Often abbreviations are not 

applied consistently. 

Unnamed data resource components such as version or source are not explicitly given. The context information 

is later lost. 

Observed repercussion of these problems: Naming without a namespace and a naming convention is a good 

source of misunderstandings and misuse of notions in programming, search, and deployment. 

Limiting identification of names for deployment: Inappropriate names require from the user to learn the 

right meaning. Therefore users cannot identify the facts they would like to identify. 

Perpetuated disparity: Users are not aware of existence of data. Therefore, additional redundant data are 

created. 

Lower productivity is caused by the need to locate the proper data, by trying to remember the meaning, 

and by trying to gain an initial understanding of the content of the database. 

Incomprehensive data definitions do not allow to fully explain the content of the database and the meaning of the 

data in business terms. Typically the problem is observed for data that come from XML environments. These 

data are then vague since they do not allow to thoroughly explain, in simple understandable terms, the real 

content and meaning of the data with respect to the business. 

Problems encountered Vague data definitions inhibit data understanding that inhibits business understanding. 

Non-existent data definitions provide no data understanding. Typical examples are coded data without 

reference to the code used. 

Unavailable data definitions limit the deployment of data by those who need to understand the data. 

Short data definitions use truncated phrases, incomplete sentences and provide little meaning. Sometimes, 

the meaning given is only the long form of the attribute name, e.g. Pro Nu for The number 

of the probe. 

Meaningless data definitions are coming into play when people use some randomly chosen, grammatical 

illiterately sentence form and force users to imagine or guess what could be the meaning. 

Outdated data definitions are for instance observed after database evolution without changing the meaning 

of attributes or after migration or integration projects. 

Incorrect data definitions cause considerable uncertainty. For instance, the applicable unit of measure 

cannot be guessed. 

Unrelated definitions: The definition is useful in another context but not in the current context. 

Functionality overload such as data entry instructions are coded into the name of the data. 

Biasing deployment by detailed descriptions: Exhaustive descriptions condition users that all situations 

and meanings are covered. Other uses cannot be easily identified. 

Explicit coding of the source should be given by the metadata but not within a definition of the data. 

Observed repercussion of these problems: Vague data definitions lead to inappropriate use, incomplete use, 

and poor understandability. 

Inhibiting data understanding: The data in the database are not thoroughly understood. There are assumptions 

of data collection, data quality etc. that cannot be guessed. for instance, a collection on 

species collected from the hunter community does not cover all species.


Inappropriate data use: Data are used for analysis, for data warehouse injection and for archives without 

knowing the restrictions for their deployment. 

Perpetuated data disparity: Data are misinterpreted, misunderstood, and extended by individual connotations. 

Low productivity: Conclusions drawn from the data set cannot be believed, e.g., Simpsions Paradoxon. 

Imprecise data integrity rules Typical problems that we have observed for research projects as well in industrial 

settings are the following ones: 

Problems encountered 

Observed repercussion of these problems: 

Typical problems that we have observed for research projects as well in industrial settings are the following ones: 


Informal naming 

Inadequate Database Schemata. 

Improper database schemata: Typical problems that we have observed for research projects as well in industrial 

settings are the following ones: 

Problems encountered: 

Observed repercussion of these problems:


Limited data view Typical problems that we have observed for research projects as well in industrial settings are the 



Observed repercussion of these problems 

Bad orientation Typical problems that we have observed for research projects as well in industrial settings are the 



Observed repercussion of these problems 

Partially Documented Schemata. 

Insufficient Data Management. 

Inflexible Data Schemata. 

5.2.4 Data Computation Problems 

(Temporary) Storage of Obtained, Purged and Processed Data. 

Durch ein Rechenzentrum eines Forschungsprojektclusters wird derzeit als Service die Entgegennahme und Abspeicherung 

der Daten in dem Format gewährleistet, in dem die Daten geliefert wurden. Dieser Service ist das Maximale, 

das z.Z. geleistet werden kann. Notwendig wäre dagegen eine sichere (Langzeit-) Archivierung. 

Zusätzlich sollte jederzeit ein leichter Zugang zu den Daten für authorisierte Benutzer möglich sein. Dieser Zugang 

sollte auch im Remote-Betrieb von jedem Rechner und jedem Standort aus erfolgen können. Dazu bedarf es 

allerdings einer Aufarbeitung der Daten. Diese Aufarbeitung wird entweder vom Wissenschaftler, der die Daten 

einlagern läßt manuell zum Einlagerungszeitpunkt erledigt oder wird auf einen späteren Zeitpunkt verschoben und 

damit meist nicht mehr ausgeführt. Deshalb könnte eine Software, die eine automatische Ergänzung vornimmt, sehr 

hilfreich sein.


Mit der Einlagerung sollten auch Mechanismen zur Benutzung der Daten in breiterem Maße bereitgestellt werden. 

Bei der Benutzung ist allerdings erforderlich, daß eine Nachvollziehbarkeit der Benutzung durch Dritte gewährleistet 

wird. Deshalb muß mit der Herausgabe der Daten auch eine Protokollierung der Weiterverwendung erfolgen. 

Es kann der guten wissenschaftlichen Praxis überlassen werden, ob ein gebührender “Credit” bei der Benutzung 

erfolgt. Günstiger wäre allerdings eine automatische Annotation bei einer weiteren Einstellung von Fremddaten- 

Bestandteilen in den eigenen Publikationen. 

Die Daten müssen mit entsprechenden Metadaten abgelegt werden. Zu den Metadaten gehören neben den Daten 

zur Erhebung, zu den verwendeten Verfahren auch die geographischen und die temporalen Daten. Diese Metadaten 

können durch eine Erweiterung der Graphical Markup Language (GML) zu einer Oceanography Markup Language 

(OML) einheitlich erfaßt werden. Dazu kann die OML als eigenständige Entwicklung im Rahmen eines Forschungsprojektclusters 

als Projektaufgabe konzipiert werden. 

Jeder Benutzer und jeder Erheber von Daten hat seinen eigenen Arbeitsstil und seine eigene Herangehensweise 

an die Arbeit mit Daten. Benutzer bearbeiten und verändern Daten anhand der konkreten aktuellen Aufgabenstellung. 

Eine spätere Dokumentation des Verwendungszweckes, der getätigten Zusammenfassungen, der Korrekturen 

etc. ist nicht nur aufwendig, sondern oft auch nicht mehr möglich. Damit können auch Daten verwendet werden, 

die unerkannterweise Duplikate sind, von denen man nicht mehr die Assoziation zum Original herstellen kann und 

die damit aufgrund des Vorhandenseins, aufgrund der Art der Aggregation und aufgrund der Nachbearbeitung zu 

Verfälschungen in Analysen führen können. 

Data Layering Problems. 

5.2.5 Typical Data Analysis Problems 

Algorithms are typically used for the solution of data mining and analysis tasks. An algorithms also has an application 

area, application restrictions, data requirements, results at certain granularity and precision. These problems must be 

systematically tackled if we want to rely on the results of mining and analysis. Otherwise analysis may become 

misleading, biased, or not possible. Therefore, we explicitly treat properties of mining and analysis. 

Problems observed [PPJ06] 

A large variety of competing algorithms and tools have 

been developed. Their advantages and specific application 

areas are not yet made explicit. 


The development of an advisory system that supports selection 

and that help for the most appropriate selection 

might resolve this difficulty. The analysis of algorithms 

is necessary in advance. 

Each of the algorithms has its specific data quality requirements. 

the algorithm or only with special care. 

We either improve the data quality or advice not to use 

The interpretation of results obtained by analysis is crucial 

for understanding analysis. 

what was not achievable. 

The user must be informed what has been achieved and 

The formation of best fitting hypotheses and concepts is The user is supported by explicit modelling of the triad of 

still rather art than science. 

concepts, hypotheses, and data spaces. 

The detection of new hypotheses and the selection of appropriate 

data is very difficult. 

spaces and during drilling down into the data . 

The user can be supported for orientation in the triad 

Visualisation of results is still rather difficult due to the Representation theory has developed approaches transformation 

of spaces to forms, e.g., abstract algebraic 

specifics of the visualisation method and of the structure 

of the visualisation space. 

structures are represented using geometry. 

The results of mining and analysis are open for misinterpretation 

and drawing wrong conclusions as long as the with the results obtained by these algorithms. 

The main properties of algorithms must provided together 

analysis properties of algorithms are not well understood. 

Data are the main source for information in data mining and analysis. Their quality properties have been neglected 

for a long time. At the same time, modern data management allows to handle these problems. We compare the critical 

findings of [PPJ06] with resolution techniques that can be applied to overcome the crucial pitfalls of data mining in 

environmental sciences reported there.


Problems observed [PPJ06] 

Data in analysis tasks are often missing, 

(partially) duplicated, partially wrong, partially 

(mis)corrected, and/or biased. Therefore, nobody 

can entirely rely on them. 

Data are provided with wrong formats, wrong or 

mixed granularity, are isolated or are given only 

by partially integrated data massives. 

Data massives are partially dense and huge at the 

same when mainly sparse data are used. This imbalance 

results in strange behaviour of algorithms. 

Data massives are often unrelated to each other, 

not annotated, and have missing (geo & time) references. 

Data are of varying granularity and of various levels 

of detail. Micro-, meso- and macro-data are 

related to each other with an explicit association 

schema. 

Data sets have their own hidden dependencies 

among dimensions of the data. Additionally turbulences 

and non-linear dependencies within the 

data are observed. 


Classical extrapolation, cleansing, control techniques developed 

for analysis, handling of complex functions and statistics can be 

applied if properties of data are known. Data identification techniques 

resolve redundancy of data. 

Data modelling provides solutions for migration of legacy data 

into new data massives, for integration of data from heterogeneous 

resources, for extraction of data of interest by views and 

for abstractions of data. 

Modern database modelling provides a number of techniques for 

extrapolation of data and for abstraction of data to other data sets. 

At the same time web information systems technology provides 

techniques for gardening of data. 

Metadata injection, data modelling techniques and database integration 

techniques resolve these problems and provide additional 

information for new analysis tasks. 

Integrated model suites with explicit association schemata 

among the different levels of detail and corresponding metadata 

for translation of data and semantics allow consistent handling 

of data of various levels of detail. 

Data abstraction techniques support reduction to essential substructures 

and abstraction from substructures that are dependent 

from the main structures. Synergetics allows to separate dimensions 

into control and order dimensions.


5.2.6 Quality Data for Data Mining and Analysis 

Data quality is an old issue for business information systems. Typical requirements of business applications result in 

the following list for data quality: 

• The data is accurate. 

• The data is stored according to data types. 

• The data has integrity. 

• The data is consistent. 

• The databases are well designed. 

• The data is not redundant. 

• The data follows business rules. 

• The data corresponds to established domains. 

• The data is timely 

• The data is well understood. 

• The data is integrated. 

• The data satisfies the needs of the business. 

• The user is satisfied with the quality of the data and the information derived from that data. 

• The data is complete. 

• There are no duplicate records. 

• There are no data anomalies. 

This list is also applicable to data mining and analysis. We need tools for data cleansing, data integration, data 

accreditation, and generic data input that maintains or improves quality of data. 

5.2.7 Benefits of Good Data Management 

Data management policies and procedures ensure that data on all media are treated as a valued resource. Implementing 

such policies and procedures will give many benefits: 

Benefits to Data Suppliers 

• An increased confidence and trust that their data will be used according to their agreed conditions of use, 

without risk to confidentiality, copyright or IPR, and in compliance with all statutory and non-statutory 

obligations. 

• Providing a clear understanding of the use of their data, formally documented in a Memorandum of 

Agreement signed by both supplier and user. 

• A fair return for the use of the data they have supplied. 

Benefits to Data Brokers/Intermediaries 

• Better quality, harmonized and coherent data from the use of common definitions, including geographic 

references, formats, validation processes and standard procedures. 

• Better care of the data holdings through the use of effective data policies and best practice guidance. 

• Better control over the data by the clear definition and use of the procedures for the care of data. 

• Improved knowledge and understanding of data holdings, their availability, interpretation and use, with 

subsequent reduction of the risk of duplication or loss, through better cataloguing, metadata and, in time, 

better access to data via an integrated data environment. 

• Improved business processes, including better and more efficient use and re-use of data, and the standardization 

of datasets that are frequently used by different parts of an organization.


• Increased confidence that the organization complies with statutory and non-statutory obligations, by the 

regular use of centrally coordinated, frequently updated guidance, codes of practice and training on legal, 

contractual and other obligations. 

• Better control over access to data, both for internal and bona fide external customers, resulting from 

better data organization and maintenance following defined policies on release, disclosure control and 

data security. 

• More sensible and consistent data charges and conditions of use, resulting from clear pricing and dissemination 

policies that recognize the need for free access by appropriate customers whilst recovering the 

appropriate income from customers who seek to make commercial gain. 

• An increasing confidence by the customer in the quality of the data managed and in the reliability of 

outputs that are produced. 

Benefits to users and customers 

• Improved awareness and understanding of what data are available for current and future use, resulting 

from better cataloguing and data archiving. 

• Improved access to data, free from unnecessary obstacles, safeguarded from disclosure of personal information 

or infringement of legal and contractual obligations. 

• Better quality and more timely information i.e. access to the right information at the right time, resulting 

from quicker identification of customer needs and the avoidance of wrong or conflicting information, 

through the use of effective metadata. 

• Better value for money, resulting from clear, fair and consistent data charges and conditions of use, which 

recognize the need for free access by the appropriate customers. 

• Better exploitation of data generally, enabled by easier data exchange and integration with other harmonized 

data. 

• Efficiency gains across government and its agencies resulting from the use of better quality data.


5.3 Principles and Guidelines of Information Management 

Information management is an umbrella term that encompasses all the systems and processes within an organisation 

for the creation and use of corporate information. 

In terms of technology, information management encompasses systems such as: 

• web content management (CM), 

• document management (DM), 

• records management (RM), 

• digital asset management (DAM), 

• learning management systems (LM), 

• learning content management systems (LCM), 

• collaboration, 

• enterprise search, 

• and many more ... 

Information management is, however, much more than just technology. Equally importantly, it is about the business 

processes and practices that underpin the creation and use of information. 

It is also about the information itself, including the structure of information (‘information architecture’), metadata, 

content quality, and more. 

Information management therefore encompasses: 

• people, 

• process, 

• technology, and 

• content. 

Each of these must be addressed if information management projects are to succeed. 

Information Management Challenges 

Organisations are confronted with many information management problems and issues. In many ways, the growth of 

electronic information (rather than paper) has only worsened these issues over the last decade or two. 

Common information management problems include: 

• Large number of disparate information management systems. 

• Little integration or coordination between information systems. 

• Range of legacy systems requiring upgrading or replacement. 

• Direct competition between information management systems. 

• No clear strategic direction for the overall technology environment. 

• Limited and patchy adoption of existing information systems by staff. 

• Poor quality of information, including lack of consistency, duplication, and out-of-date information. 

IS ADD


• Little recognition and support of information management by senior management. 

• Limited resources for deploying, managing or improving information systems. 

• Lack of enterprise-wide definitions for information types and values (no corporate-wide taxonomy). 

• Large number of diverse business needs and issues to be addressed. 

• Lack of clarity around broader organisational strategies and directions. 

• Difficulties in changing working practices and processes of staff. 

• Internal politics impacting on the ability to coordinate activities enterprise-wide. 

Towards Principles of Information Management 

The information management principles 3 provide simple statements that support staff in making strategic, tactical 

and operational decisions. 

5.3.1 Eight Principles of Information Management 

Principle 1: Ensure the information we collect meets business needs and priorities. 

Information management only collects information that has a clear purpose. Given our finite resources we will prioritise 

investment in information to areas that best support the projects’s strategic directions and key operational requirements. 

Principle 2: Minimise the cost and burden of information capture. 

Information management reduces the cost of collection and the burden on clients and providers by capturing information 

once and once only, using the best available tools and technologies. 

Principle 3: Get the best value from information. 

Information management enhances the value of its investment in information by sharing information, making it 

accessible, using it productively and managing it efficiently. 

Principle 4: Produce quality information. 

The cluster’s information is of a quality which makes it fit for purpose. This encompasses issues of: relevance, 

completeness, accuracy, timeliness and accessibility. 

Principle 5: Provide information integration. 

Information is typically kept in a distributed form based on different formats, abstraction, granularity, quality and 

maintenance. Information architectures, application of abstractions, common access and usage orientation are means 

for providing a holistic view on the information massive. 

Principle 6: Protect and preserve information. 

Information is managed with due care and diligence throughout the information life cycle to ensure that it is protected 

and preserved in accordance with legislative and policy requirements, such as the Information Privacy Act and 

Victorian Electronic Records Strategy. 

3 The definition provided by the Encyclopedia Britannica [SYea03] defines four different usages of the term ‘principle’. The first understanding 

defines a principle to be (1) either a comprehensive and fundamental law, doctrine, or assumption (2) or a rule (3) or a code of conduct. 

Synonyms are axiom, fundamental, law, principium, and theorem. Related words are basis, foundation, ground; canon, precept, rule; convention, 

form, usage. 

IS ADD


Principle 7: Enable good practices - Competencies 

Information management staff members have the necessary skills, knowledge and experience to perform their information 

management responsibilities. 

Principle 8: Enable good practices - Governance. 

Clear accountabilities, controls and coordinating mechanisms are in place and observed to ensure that information is 

managed efficiently and effectively. 

Applying the principles across the information life cycle 

The importance of each principle varies with the stage of the life cycle. For example, relevance is critical to determining 

information requirements. Once this is done, the design and capture of information is strongly guided by 

the principle of minimising cost and burden. Effective distribution and use of information are how we get the best 

value from our information. An awareness of quality issues is particularly important during design and capture, while 

safeguards need to be in place to control access to and use of information. 

Stages Determine Design and Distribute Use Retain and 

of the life cycle requirements capture dispose 

Relevance ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ 

Cost/burden ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ 

Value ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ 

Quality ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ 

Integration ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ 

Protection ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ 

Competencies ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ 

Governance ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ 

Relationship between principle and lifecycle stage: Critical (⋆ ⋆ ⋆ ), High (⋆ ⋆), moderate (⋆). 

5.3.2 Ten Resulting Guidelines of Information Management 

We introduce ten key guidelines to ensure that information management activities are effective and successful: 

1. recognise (and manage) complexity; 

2. focus on adoption; 

3. deliver tangible & visible benefits; 

4. prioritise according to business needs; 

5. take a journey of a thousand steps; 

6. provide strong leadership; 

7. mitigate risks; 

8. communicate extensively; 

9. aim to deliver a seamless user experience; 

10. choose the first project very carefully. 

Implementing information technology solutions in a complex and ever-changing organisational environment is never 

easy. The challenges inherent in information management projects mean that new approaches need to be taken, if 

they are to succeed. 

IS ADD


Guideline 1: Recognise (and manage) complexity. 

Organisations are very complex environments in which to deliver concrete solutions. There are many challenges that 

need to be overcome when planning and implementing information management projects. 

When confronted with this complexity, project teams often fall back upon approaches such as: 

• Focusing on deploying just one technology in isolation. 

• Purchasing a very large suite of applications from a single vendor, in the hope that this can be used to solve all 

information management problems at once. 

• Rolling out rigid, standardised solutions across a whole organisation, even though individual business areas 

may have different needs. 

• Forcing the use of a single technology system in all cases, regardless of whether it is an appropriate solution. 

• Purchasing a product ‘for life’, even though business requirements will change over time. 

• Fully centralising information management activities, to ensure that every activity is tightly controlled. 

All of these approaches will fail, as they are attempting to convert a complex set of needs and problems into simple 

(even simplistic) solutions. The hope is that the complexity can be limited or avoided when planning and deploying 

solutions. 

In practice, however, there is no way of avoiding the inherent complexities within organisations. New approaches 

to information management must therefore be found that recognise (and manage) this complexity. 

Organisations are often looking for simple approaches and sometime believe vendors when they offer ‘silver 

bullet’ technology solutions. Instead, successful information management is underpinned by strong leadership that 

defines a clear direction. Many small activities should then be planned to address in parallel the many needs and 

issues. Risks must then be identified and mitigated throughout the information system deployment, to ensure that 

organisational complexities do not prevent the delivery of effective solutions. 

Guideline 2: Focus on adoption. 

Information management systems are only successful if they are actually used by staff, and it is not sufficient to 

simply focus on installing the software centrally. In practice, most information management systems need the active 

participation of staff throughout the organisation. For example: 

• Staff must save all key files into the document/records management system. 

• Decentralised authors must use the content management system to regularly update the intranet. 

• Lecturers must use the learning content management system to deliver e-learning packages to their students. 

• Front-line staff must capture call details in the customer relationship management system. 

In all these cases, the challenge is to gain sufficient adoption to ensure that required information is captured in the 

system. Without a critical mass of usage, corporate repositories will not contain enough information to be useful. This 

presents a considerable change management challenge for information management projects. In practice, it means that 

projects must be carefully designed from the outset to ensure that sufficient adoption is gained. This may include: 

• Identifying the ‘what’s in it for me’ factors for end users of the system. 

• Communicating clearly to all staff the purpose and benefits of the IS project. 

• Carefully targeting initial projects to build momentum for the project. 

• Conducting extensive change management and cultural change activities throughout the project. 

• Ensuring that the systems that are deployed are useful and usable for staff. 

IS ADD


Guideline 3: Deliver tangible & visible benefits. 

It is not enough to simply improve the management of information ‘behind the scenes’. While this will deliver real 

benefits, it will not drive the required cultural changes, or assist with gaining adoption by IS staff. In many cases, 

information management projects initially focus on improving the productivity of publishers or information managers. 

While these are valuable IS projects, they are invisible to the rest of the organisation. When challenged, it can be hard 

to demonstrate the return on investment of these projects, and they do little to assist project teams to gain further 

funding. 

Instead, information management projects must always be designed so that they deliver tangible and visible 

benefits. Delivering tangible benefits involves identifying concrete business needs that must be met. This allows 

meaningful measurement of the impact of the projects on the operation of the organisation. The projects should also 

target issues or needs that are very visible within the organisation. When solutions are delivered, the improvement 

should be obvious, and widely promoted throughout the organisation. 

For example, improving the information available to call centre staff can have a very visible and tangible impact 

on customer service. In contrast, creating a standard taxonomy for classifying information across systems is hard to 

quantify and rarely visible to general staff. This is not to say that ‘behind the scenes’ improvements are not required, 

but rather that they should always be partnered with changes that deliver more visible benefits. This also has a major 

impact on the choice of the initial activities conducted. 

Guideline 4: Prioritise according to business needs. 

It can be difficult to know where to start when planning information management projects. While some organisations 

attempt to prioritise projects according to the ‘simplicity’ of the technology to be deployed, this is not a meaningful 

approach. In particular, this often doesn’t deliver short-term benefits that are tangible and visible. Instead of this 

technology-driven approach, the planning process should be turned around entirely, to drive projects based on their 

ability to address business needs. 

In this way, information management projects are targeted at the most urgent business needs or issues. These in 

turn are derived from the overall business strategy and direction for the organisation as a whole. For example, the rate 

of errors in home loan applications might be identified as a strategic issue for the organisation. A new system might 

therefore be put in place (along with other activities) to better manage the information that supports the processing of 

these applications. Alternatively, a new call centre might be in the process of being planned. Information management 

activities can be put in place to support the establishment of the new call centre, and the training of new staff. 

Guideline 5: Avoid ‘silver bullet’ solutions that promise to fix everything; Take a journey of a thousand steps. 

There is no single application or project that will address and resolve all the information management problems of an 

organisation. Where organisations look for such solutions, large and costly strategic plans are developed. Assuming 

the results of this strategic planning are actually delivered (which they often aren’t), they usually describe a longterm 

vision but give few clear directions for immediate actions. In practice, anyone looking to design the complete 

information management solution will be trapped by ‘analysis paralysis’: the inability to escape the planning process. 

Organisations are simply too complex to consider all the factors when developing strategies or planning activities. 

The answer is to let go of the desire for a perfectly planned approach. Instead, project teams should take a ‘journey 

of a thousand steps’. This approach recognises that there are hundreds (or thousands) of often small changes that 

are needed to improve the information management practices across an organisation. These changes will often be 

implemented in parallel. While some of these changes are organisation-wide, most are actually implemented at business 

unit (or even team) level. When added up over time, these numerous small changes have a major impact on the 

organisation. 

This is a very different approach to that typically taken in organisations, and it replaces a single large (centralised) 

project with many individual initiatives conducted by multiple teams. While this can be challenging to coordinate and 

manage, this ‘thousand steps’ approach recognises the inherent complexity of organisations and is a very effective 

way of mitigating risks. It also ensures that ‘quick wins’ can be delivered early on, and allows solutions to be targeted 

to individual business needs). 

IS ADD


Guideline 6: Successful projects require strong leadership. 

Successful information management is about organisational and cultural change, and this can only be achieved 

through strong leadership. The starting point is to create a clear vision of the desired outcomes of the information 

management strategy. This will describe how the organisation will operate, more than just describing how the 

information systems themselves will work. 

Effort must then be put into generating a sufficient sense of urgency to drive the deployment and adoption of new 

systems and processes. Stakeholders must also be engaged and involved in the project, to ensure that there is support 

at all levels in the organisation. 

This focus on leadership then underpins a range of communications activities that ensure that the organisation 

has a clear understanding of the projects and the benefits they will deliver. When projects are solely driven by the 

acquisition and deployment of new technology solutions, this leadership is often lacking. Without the engagement 

and support of key stakeholder outside the IT area, these projects often have little impact. 

Guideline 7: Apply good risk management to ensure success. 

Due to the inherent complexity of the environment within organisations, there are many risks in implementing information 

management solutions. These risks include: 

• selecting an inappropriate technology solution, 

• time and budget overruns, 

• changing business requirements, 

• technical issues, particularly relating to integrating systems, and 

• failure to gain adoption by staff. 

At the outset of planning an information management strategy, the risks should be clearly identified. An approach 

must then be identified for each risk, either avoiding or mitigating the risk. Risk management approaches should then 

be used to plan all aspects of the project, including the activities conducted and the budget spent. For example, a 

simple but effective way of mitigating risks is to spend less money. This might involve conducting pilot projects to 

identifying issues and potential solutions, rather than starting with enterprise-wide deployments. 

Guideline 8: Communicate extensively. 

Extensive communication from the project team (and project sponsors) is critical for a successful information management 

initiative. This communication ensures that staff have a clear understanding of the project, and the benefits it 

will deliver. This is a pre-requisite for achieving the required level of adoption. 

With many projects happening simultaneously, coordination becomes paramount. All project teams should devote 

time to work closely with each other, to ensure that activities and outcomes are aligned. In a complex environment, it 

is not possible to enforce a strict command-and-control approach to management. Instead, a clear end point (‘vision’) 

must be created for the information management project, and communicated widely. This allows each project team 

to align themselves to the eventual goal, and to make informed decisions about the best approaches. 

For all these reasons, the first step in an information management project should be to develop a clear communications 

‘message’. This should then be supported by a communications plan that describes target audiences, and 

methods of communication. Project teams should also consider establishing a ‘project site’ on the intranet as the 

outset, to provide a location for planning documents, news releases, and other updates. 

Guideline 9: Staff do not understand the distinction between systems; Therefore aim to deliver a seamless user 

experience. 

Users don’t understand systems. When presented with six different information systems, each containing one-sixth 

of what they want, they generally rely on a piece of paper instead (or ask the person next to them). Educating staff in 

IS ADD


the purpose and use of a disparate set of information systems is difficult, and generally fruitless. The underlying goal 

should therefore be to deliver a seamless user experience, one that hides the systems that the information is coming 

from. 

There will always be a need to have multiple information systems, but the information contained within them 

should be presented in a human-friendly way. In practice, this means: 

• Delivering a single intranet (or equivalent) that gives access to all information and tools. 

• Ensuring a consistent look-and-feel across all applications, including standard navigation and page layouts. 

• Providing ‘single sign-on’ to all applications. 

Ultimately, it also means breaking down the distinctions between applications, and delivering tools and information 

along task and subject lines. For example, many organisations store HR procedures on the intranet, but require staff 

to log a separate ‘HR self-service’ application that provides a completely different menu structure and appearance. 

Improving on this, leave details should be located alongside the leave form itself. In this model, the HR application 

becomes a background system, invisible to the user. 

Care should also be taken, however, when looking to a silver-bullet solution for providing a seamless user experience. 

Despite the promises, portal applications do not automatically deliver this. Instead, a better approach may be 

to leverage the inherent benefits of the web platform. As long as the applications all look the same, the user will be 

unaware that they are accessing multiple systems and servers behind the scenes. Of course, achieving a truly seamless 

user experience is not a short-term goal. Plan to incrementally move towards this goal, delivering one improvement 

at a time. 

Guideline 10: The first project must build momentum for further work; Therefore choose the first project very 

carefully. 

The choice of the first project conducted as part of a broader information management strategy is critical. This project 

must be selected carefully, to ensure that it: 

• demonstrates the value of the information management strategy, 

• builds momentum for future activities, 

• generates interest and enthusiasm from both end-users and stakeholders, 

• delivers tangible and visible benefits, 

• addresses an important or urgent business need, 

• can be clearly communicated to staff and stakeholders, and 

• assists the project team in gaining further resources and support. 

Actions speak louder than words. The first project is the single best (and perhaps only) opportunity to set the organisation 

on the right path towards better information management practices and technologies. The first project must 

therefore be chosen according to its ability to act as a ‘catalyst’ for further organisational and cultural changes. In 

practice, this often involves starting with one problem or one area of the business that the organisation as a whole 

would be interested in, and cares about. For example, starting by restructuring the corporate policies and procedures 

will generate little interest or enthusiasm. In contrast, delivering a system that greatly assists salespeople in the field 

would be something that could be widely promoted throughout the organisation. 

5.3.3 Goals and the Rationale of Information Management 

Rationale 1: Corporate importance 

Information is a strategic resource, and will be managed appropriately. In general, cluster-wide information will be 

centrally managed. Information needs and how information is managed should be identified as an integral part of 

strategic and project planning. A governance framework ensures that this occurs. 

IS ADD


Rationale 2: Information sources 

Cluster-created information may be made available from a core source or a derived source. The core source for any 

item of cluster-created information must be identifiable and accessible. Any derived sources of information must 

be identified as such. In general, changes should only be made to the core source. Each core source should have 

an identified custodian, an identified access community and an identified set of maintenance responsibilities. Where 

possible, different manifestations of information expressions should be derived from a single source. As with core 

and derived sources, changes should ideally be made to this single source and the derived manifestations should be 

automatically regenerated. 

Rationale 3: User-centredness 

Information systems and services should be designed (or re-designed) to operate in a way that is user-centred and 

task-centred. This should inform all aspects of system or service design. 

Rationale 4: Availability 

Information should ideally be accessible (subject to security and acceptable use guidelines) to 

(1) anybody who needs it, (2) at anytime, (3) anywhere, (4) and anyhow 

in order to ensure that it delivers the greatest value to the users of data. 

Rationale 5: Information user community development 

The research cluster needs to provide an adequate, relevant and ongoing development programme to enable all team 

members to create, access, manage and disseminate information resources effectively. 

Rationale 6: Productivity and efficiency 

Information, and the way it is managed, should contribute to the productivity of members of the the research cluster 

community. 

Rationale 7: Statutory requirements 

Information must be managed in accordance with external statutory and regulatory requirements. Information must 

be stored in such a way as to allow a timely response to freedom of information and local requests, as well as legallymandated 

controlled discovery. For instance, information arising from research involving human subjects must be 

dealt with in accordance with the Human Ethics Committee requirements. 

Rationale 8: Trustworthy information and systems 

Information provided by the research cluster should be, and be perceived to be, trustworthy (that is, relevant, accurate 

and timely) to the maximum extent possible. Where the information is sourced from outside the research cluster (as 

with, for example, library holdings), all reasonable care should be taken to ensure its trustworthiness. Any activity that 

creates, modifies or transmits critical research cluster information should be trustworthy. This means that it should 

be: 

• logged (to ensure an audit trail) 

• non-repudiable (to ensure that the creator/changer can not later deny their action, and that there is proof that 

the action took place). 

IS ADD


Rationale 9: Retention and disposal 

Essential information must be retained while required and then appropriately disposed of in accordance with the 

research cluster standards and external obligations. A proportion of all information will be retained in the research 

cluster archives, constituting the cluster’s captured corporate memory. While it is retained, it must be managed in 

such a way as to be recoverable in the event of loss on a timescale consistent with university requirements. 

Rationale 10: Information and technology 

ICT Principles are derived from information management principles. ICT supports and enable the implementation of 

the the principles, as well as determine the deployment of ICT systems and services. 

5.3.4 Resulting Criteria for Information Management Derived from Principles 

Commitment and leadership: Information is a strategic asset and information management must be a key component 

of every environmental data and information program. This ethic must be reflected in a corporate culture, 

embraced throughout the organization, that recognizes data as a corporate resource. 

Stewardship: People who take observations or produce data and information are stewards of these data, not owners. 

These data must be collected, produced, documented, transmitted and maintained with the accuracy, timeliness 

and reliability needed to meet the needs of all users. 

Long-term preservation: Irreplaceable observations, data products of lasting value, and associated metadata must 

be preserved. This information must be well-documented and maintained so that it is available to and independently 

understandable by users, now and in the future. 

Requirements-driven: It is essential that providers and users of data and products play an active role in defining the 

constantly evolving requirements that drive the development and evolution of data management systems. 

Discovery and access: Freedom of access, mechanisms that facilitate discovery, timely delivery, use and interpretation 

of data and products (directories, browse capabilities, metadata, mapping, visualization, etc.) are essential, 

recognizing relevant policies and regulations. 

Standards and practices: Appropriate use of information technologies, widely shared standards, and integration 

approaches are vital to facilitate collection, management, discovery, dissemination, and access services for 

environmental data and products. This will ensure interoperability among providers, systems, and users. Effective 

application of standards and best practices contribute to the development of systems that are interoperable, 

efficient, reliable, scalable, and adaptable. 

Quality: Data, products and information should be of quality sufficient to meet the requirements of society and to 

support sound decision making. 

Cooperation and coordination: Environmental and scientific data management is a task of global scope – a whole 

that should be much bigger than the sum of its parts. It is only by participating in a global community of 

integrated data management that each organization can realize the potential of its data to the betterment of 

humankind. 

Security: Data, information, and products must be preserved and protected from unintended or malicious modification, 

unauthorized use, or inadvertent disclosure. 

5.3.5 Towards Holistic Tactics for Information Management 

We conclude that common information management problems must be resolved for information mangement: 

• Large number of disparate information management systems. 

IS ADD


• Little integration or coordination between information systems. 

• Range of legacy systems requiring upgrading or replacement. 

• Direct competition between information management systems. 

• No clear strategic direction for the overall technology environment. 

• Limited and patchy adoption of existing information systems by staff. 

• Poor quality of information, including lack of consistency, duplication, and out-of-date information. 

• Little recognition and support of information management by senior management. 

• Limited resources for deploying, managing or improving information systems. 

• Lack of enterprise-wide definitions for information types and values (no corporate-wide taxonomy). 

• Large number of diverse business needs and issues to be addressed. 

• Lack of clarity around broader organisational strategies and directions. 

• Difficulties in changing working practices and processes of staff. 

• Internal politics impacting on the ability to coordinate activities enterprise-wide. 

Tactics Concern 1: Recognise (and Manage) Complexity 

Information management issues can be overwhelming. Application might inherently complex. Often applications have 

been developed while not avoiding typical pitfalls: project team members focus on one technology in isolation; 

purchasing a universal solution from one vendor without knowledge of the limitations; rolling out a rigid and somehow 

standardising solution without consideration of the needs of individuals; being trapping due to the focus on a 

single technology without knowledge whether this is appropriate; purchasing a product for life without explicit plans 

for changes; using fully centralising information management while assuming the centralisation support full control. 

Tactics Concern 2: Focus on Adoption 

Information systems need an active partnership by those who are going to use the system. Adoption means to consider 

the entire context of the application. Individuals use the data for different purposes in different application cases in 

different environments in different time in different format and with different responsibilities and roles. 

Systems must become useful and usable by the staff at any point of time. Therefore, we need flexible playout 

facilities in the sense of [HM03b]. Adoption must also be explicit. Information systems are only successful if they are 

used. They must however satisfy concrete business needs. Information management projects must always be designed 

so that they deliver tangible and visible benefits. 

Tactics Concern 3: Deliver Tangible and Visible Benefits 

It is not enough to deliver ‘behind the scenes’ fixes. Information management first starts with satisfaction of information 

demands issued by the managers. The information management is invisible to the rest of the enterprise. It results 

in unclear return of investment. 

Tactics Concern 4: Prioritise According to Business Needs 

The most urgent business needs first must be tackled first. Often, the simplest and easiest supported by technology 

tasks are tackled first since they deliver direct success stories, e.g., during agile development. Instead of this 

technology-driven approach, information management projects are targeted at the most urgent business needs or 

issues. These in turn are derived from the overall business strategy and direction for the organisation as a whole. 

IS ADD


Tactics Concern 5: Chicken Little Approaches take a Journey of Thousand Steps 

Anything in the worlds has its price. Information management must avoid ‘silver bullet’ solutions that promise to fix 

everything. Universal worlds formulas does not exist; the same is valid for universal information systems solutions. 

Complete information management solution will be trapped by ‘analysis paralysis’: the‘inability to escape the planning 

process. Instead it is better to develop information management based on hundreds (or thousands) of often small 

changes that are needed to improve the information management practices across an enterprise. 

Tactics Concern 6: Provide Strong Leadership 

Successful projects require strong leadership since information systems are social-technological systems. They thus 

change organisations and cultures. The starting point is to create a clear vision of the desired outcomes of the information 

management strategy. This will describe how the organisation will operate, more than just describing how the 

information systems themselves will work. 

Tactics Concern 7: Mitigate Risks 

Good risk management ensures better success. Since difficulties are also caused by information technology, by time 

and budget issues, by changing business requirements, by tiny technical issues and by failure to gain adoption by the 

staff, an explicit risk management strategy and tactics must be developed. Risk management approaches should then 

be used to plan all aspects of the project, including the activities conducted and the budget spent. 

Tactics Concern 8: Communicate Extensively 

One reason for the initial success of agile software development approaches is the intensive communication with 

the potential customer and community of practice. Intensive communication ensures that individuals and potential 

users have a clear understanding of the project, and the benefits it will deliver. This is a pre-requisite for achieving 

the required level of adoption. Nowadays, the strict command-and-control approach to management is not accepted 

anymore. 

Tactics Concern 9: Aim to Deliver a Seamless User Experience 

Business users do not want to entirely understand the distinction between different potential systems. They do not 

want either to go through whole-week tutorials. Educating individuals in an enterprise in the purpose and use of a 

disparate set of information systems is difficult, and generally fruitless. Instead, we need to deliver a seamless and 

transparent user experience, one that hides the systems that the information is coming from. 

Tactics Concern 10: Choose the First Information Management Sub-Project Very Carefully 

The first sub-project must build momentum for further work and is thus critical. It demonstrates the value of the 

information management, builds a momentum for future activities, generates interest and enthusiasm within the community 

of practice, delivers tangible and visible benefits, addresses an important or urgent business need , can be 

clearly communicated to the community of practice, and assists the project team in gaining further resources and support. 

The first project must therefore be chosen according to its ability to act as a ‘catalyst’ for further sub-projects. 

IS ADD


5.4 Principles and Guidelines for Data Management 

5.4.1 Ten Principles of Data Management 

Principle 1: Data is an Asset 

Data is a core business asset that has value to a scientific research team or enterprise data owner in general (data set 

user group, DUG) and is managed accordingly. 

Rationale: 

Data is a valuable corporate resource; it has real, measurable value. This is especially so in the case of multi-million 

Euro contracts under PPP and PFI frameworks for running infrastructure services. In simple terms, the purpose of 

data is to aid decision-making. Accurate, timely data is critical to accurate, timely decisions. Most corporate assets 

are carefully managed, and as up to 80% of an organisation’s value rests in its data assets, data can be no exception. 

Data is the foundation of our decision-making, so we must also carefully manage data to ensure that we know what 

we’ve got, where it is, can rely upon its accuracy, and can obtain it when and where we need it. 

Implications: 

This is one of three closely-related principles regarding data: data is an asset; data is shared; and data is easily accessible. 

The implication is that there is an education task to ensure that all departments within scientific research team or 

enterprise data owner in general understand the relationship between value of data, sharing of data, and accessibility 

to data. 

Data used in DUG must be classified into high-level groupings to which final accountability for quality can be assigned. 

If any employee has responsibility for upkeep of data in any form, this must be clearly stated in their job description 

and identified as a measure in their Performance Review process. In practice this will apply to all office-based employees 

to varying degrees. 

All employees with any kind of data responsibility must have the authority and means to manage the data for which 

they are accountable. 

Procedures must be developed and used to prevent and correct errors in information and to improve those processes 

that produce flawed information. Data quality will need to be measured and steps taken to improve data quality - it is 

probable that policy and procedures will need to be developed for this as well. 

A forum with comprehensive enterprise-wide representation should decide on process changes suggested by data 

stewards (or role with similar term implying custodianship or trusteeship). 

Since data is an asset of value to the entire enterprise, data stewards accountable for creation, quality and retention/disposal 

of data must be assigned at a suitably senior level. 

Principle 2: Data is Shared 

Users have access to the data necessary to perform their duties; therefore data is shared across enterprise functions 

and departments. 

Rationale: 

Timely access to accurate data is essential to improving the quality and efficiency of enterprise decision-making. It is 

less costly to maintain timely, accurate data in a single application, and then share it, than it is to maintain duplicative 

data in multiple applications. DUG holds a wealth of data, but it is stored in hundreds of incompatible stovepipe 

databases and file-servers. The speed of data collection, creation, transfer, and assimilation is driven by the ability of 

the departments to efficiently share these islands of data across DUG. 

Shared data will result in improved decisions since we will rely on fewer sources of more accurate and timely managed 

data for all of our decision-making. Electronically shared data will result in increased efficiency when existing 

data entities can be re-used. 

Additionally, barriers to the outside world must come down too. We work with more and more external business 

partners, and efficient sharing of information assets is essential for this to work. It is more effective to de-protect. 

IS ADD


Legacy departmental culture tends to be over-protectionist. In fact, all the evidence is that more value can be derived 

from sharing more. 

Implications: 


The implication is that there is an education task to ensure that all departments within DUG understand the 

relationship between value of data, sharing of data, and accessibility to data. 

To enable data sharing we must develop and abide by a common set of policies, procedures, and standards governing 

data management and access for both the short and the long term. 

For the short term, to preserve our significant investment in legacy systems, we may have to invest in software capable 

of migrating legacy system data into a shared data environment. 

We will also need to develop standard data models, data elements, and other metadata that defines this shared environment 

and develop a repository system for storing this metadata to make it accessible. 

For the long term, as legacy systems are replaced, we must adopt and enforce common data access policies and 

guidelines for new application developers to ensure that data in new applications remains available to the shared 

environment and that data in the shared environment can continue to be used by the new applications. 

For both the short term and the long term we must adopt common methods and tools for creating, maintaining, and 

accessing the data shared across DUG. 

Data sharing will require a significant cultural change. 

This principle of data sharing will continually “bump up against” the principle of data security. Under no circumstances 

will the data sharing principle cause confidential data to be compromised. Data made available for sharing will 

have to be relied upon by all users to execute their respective tasks. This will ensure that only the most accurate and 

timely data is relied upon for decision-making. Shared data will become a DUG-wide “virtual single source” of data. 

Principle 3: Data is Accessible 

Data is accessible for users to perform their functions. 

Rationale: 

Wide access to data leads to efficiency and effectiveness in decision-making, and affords timely response to information 

requests and service delivery. Using information must be considered from an enterprise perspective to allow 

access by a wide variety of users. Staff time is saved and consistency of data is improved. 

Implications: 


The implication is that there is an education task to ensure that all departments within DUG understand the 

relationship between value of data, sharing of data, and accessibility to data. 

Accessibility involves the ease with which users obtain information. 

The way information is accessed and displayed must be sufficiently adaptable to meet a wide range of enterprise users 

and their corresponding methods of access. 

Access to data does not constitute understanding of the data. Personnel should take caution not to misinterpret information. 

Principle 4: Data Quality is Fit for Purpose 

Data quality is acceptable and meets the business need for which it is intended. 

Rationale: 

Data produced and reported must be fit for purpose. That is, of sufficient accuracy and integrity proportional to its 

use and cost of collection and maintenance. 

Data is used in all areas of decision-making, operations, planning and performance management in order that DUG 

achieves its objectives. It is increasingly being used externally by citizens and customers to inform their personal 

IS ADD


decisions, and by stakeholders to assess the aggregate performance of DUG. This reinforces the need to ensure that 

the quality of data held is sufficient to meet diverse needs. 

Significant human and system resource is consumed in the collection, manipulation and dissemination of data whether 

of high quality or not, so it is essential that the most effective use of public funds is achieved through appropriately 

directed attention to data quality and the procedures to realise quality. 

Implications: 

Data should be sufficiently accurate for its intended purpose, representing clearly and in sufficient detail the activity 

which it represents. 

Disciplines and standards will need to be put in place and monitored so that accuracy and integrity of data is assured. 

Collection and manipulation of data should be reliable and should reflect consistent processes where needed between 

departments, to allow for meaningful comparison where appropriate. 

Data collected should be complete and captured once ‘right first time’ such that it can be aggregated, analysed and 

manipulated for decision making purposes. 

Data should be timely, so that its usefulness for decision making can be maximised. 

Principle 5: Data is Compliant with Law and Regulations 

DUG’s information management processes comply with all relevant laws, policies, and regulations. 

Rationale: 

There are a number of legal requirements that govern the use of data in the course of DUG business. As a public 

authority with a clear ethical imperative and world class reputation to maintain, compliance is an essential business 

driver. 

Implications: 

DUG must be mindful to comply with laws, regulations, and external policies regarding the collection, retention, and 

management of data. 

Education and access to the rules, efficiency, need, and common sense are not the only drivers. Changes in the law 

and changes in regulations may drive changes in our processes or applications. 

Principle 6: Data is Secure 

Data is trustworthy and is safeguarded from unauthorized access, whether malicious, fraudulent or erroneous. 

Rationale: 

Open sharing of information and the release of information via relevant legislation must be balanced against the need 

to restrict the availability of classified, proprietary, and sensitive information. 

Existing laws and regulations require the safeguarding of national security and the privacy of data, while permitting 

free and open access. Pre-decisional (work-in-progress, not yet authorized for release) information must be protected 

to avoid unwarranted speculation, misinterpretation, and inappropriate use. Integrity, confidentiality and availability 

are maintained as long as information is needed. 

Implications: 

DUG’s technology infrastructure should move towards a single directory-based system that provides authentication 

services to each and every application, database, file-server and collaboration environment. Each of the latter should 

then manage access control appropriate to the business needs of each user identity. 

Data security safeguards can be put in place to restrict access to “view only”, “know only of its existence” or “not 

know of existence”. Sensitivity labelling for information access will be based on uncustomised government-standard 

‘Protect’ flag and protective marking schemes. 

Security must be designed into data elements from the beginning; it cannot be added later. Systems, data, and technologies 

must be protected from unauthorized access and manipulation. Information must be safeguarded against 

IS ADD


inadvertent or unauthorized alteration, sabotage, disaster, or disclosure. 

Principle 7: There is a Common Vocabulary and Data Definition 

Data is defined consistently throughout DUG, and the definitions are understandable and available to all users. 

Rationale: 

Both unstructured and structured data must have a common definition throughout DUG to enable sharing of data. A 

common vocabulary will facilitate communications, enable dialogue to be effective and facilitate interoperability of 

systems. 

Implications: 

DUG must establish a common vocabulary for the business. The definitions will be used uniformly throughout DUG. 

Whenever a new data definition is required, the definition effort will be co-ordinated and reconciled with the corporate 

“glossary” of data descriptions. The DUG Group IM Data Authority will govern this co-ordination. 

Ambiguities resulting from multiple parochial definitions of data must at worst be mapped as ‘non-preferred terms’ 

to a ‘preferred term’, and at best give way to accepted enterprise-wide definitions and understanding. 

Multiple data standardization initiatives need to be co-ordinated. 

Functional data administration responsibilities must be assigned. 

Principle 8: Data is Not Duplicated 

Development of information services (such as business applications, data warehouses, directory services etc) available 

across DUG is preferred over the development of information silos which are only provided to a particular department 

or group of departments. 

Rationale: 

Duplicative capability is expensive and propagates conflicting data. It also militates against a policy of sustainability 

in the use of infrastructure resources such as servers and data centre air conditioning. 

Implications: 

Departments will not be allowed to develop capabilities for their own use which are similar/duplicative of enterprisewide 

capabilities. In this way, expenditures of scarce resources to develop essentially the same capability in marginally 

different ways will be reduced. 

Departments which depend on a capability which does not serve the entire enterprise must change over to the replacement 

enterprise-wide capability as soon as practically possible, if it is available. The design of business service 

capabilities to replace silo applications will be driven directly by the business processes they are designed to support. 

Principle 9: Data Management is Everybody’s Business 

All departments in DUG participate in information management decisions needed to accomplish business objectives. 

Rationale: 

Information users are the key stakeholders in the application of technology to address a business need. In order to 

ensure information management is aligned with the business, all departments in DUG must be involved in all aspects 

of the information environment. The business experts from across DUG and the technical staff responsible for developing 

and sustaining the information environment need to come together as a team to jointly define the goals and 

objectives of IT. 

Implications: 

To operate as a team, every stakeholder will need to accept responsibility for developing the information environment. 

Commitment of resources in business departments will be required to implement this principle. 

IS ADD


Principle 10: Decisions Maximise the Benefit of Data to DUG 

A spirit and culture of collaboration and the sharing of data, information and knowledge for the greater corporate 

good shall pervade all decision-making, especially relating to the selection and prioritisation of programmes, projects 

and their approval points. 

Rationale: 

This principle embodies “service above self”. Decisions made from an enterprise-wide perspective have greater longterm 

value than decisions made from any particular departmental perspective. Maximum return on investment requires 

information management decisions to adhere to enterprise-wide drivers and priorities. No minority group will detract 

from the benefit of the whole. However, this principle will not preclude any minority group from getting its job done. 

Implications: 

Achieving maximum enterprise-wide benefit will require changes in the way we plan and manage information. Technology 

alone will not bring about this change. 

Some departments may have to concede their own preferences for the greater benefit of the entire enterprise. 

Application development priorities should be established by the entire enterprise for the entire enterprise. 

Application components should be shared across departmental boundaries. 

As needs arise, priorities must be adjusted. A forum with comprehensive enterprise representation should make these 

decisions. 

5.4.2 Goals and the Rationale of Data Management 

5.4.3 Resulting Steps for Practical Data Management Derived from Principles and Tactics 

There is a need for coordinated data management of observational data sets from the large scientific experiments and 

data collected within user groups (DUGs). The broader modelling community will use coordinated ground, atmospheric, 

oceanic and satellite measurements of the type taken during these experiments to test such formulations as 

prognostic cloud schemes and the representativeness of related interactions being implemented in their global models. 

This process can be made much more efficient if these data sets are gathered into a uniform database easily accessible 

by the various modelling centers represented across the DUGs. A DUG must be established to investigate the 

research plans of the DUGs to determine the strategies being developed for gathering the different observational data 

sets, including those generated during their intensive observation periods, into coordinated databases. The intent of 

data management is to leverage software and related resources by encouraging standardization (compatibility) of the 

DUG data system hardware and software schemes, to highlight opportunities for collaborative efforts in assembling 

data sets (e.g., global), and to foster co-operation and scientific outreach between DUGs by facilitating the exchange 

of data. 

To achieve the objectives of GHP, careful attention has to be placed on data management. Many aspects need to 

be considered, as outlined below in regards to “groundwork” considerations for the coordination of data management 

issues among the various data-intensive explorations. 

(1) Develop Data Management Plan 

A data management plan should be drafted for each project that defines various aspects of the data policy, so that 

project researchers, the scientific community, and involved data centers are aware of procedures and technical aspects 

of the database. The database may contain value added data sets pertinent to the project and it is important to define 

these in advance, since many might be generated in real-time or require specialized products. The plan should also 

contain the specific information as described below. A data manager should be identified early in this process to 

coordinate all these data management issues. 

TIMELINE - 3 months prior to data gathering start to publish data management plan. 

IS ADD


(2) Data Types 

All data types whether they be operational, research (or experimental), and interdisciplinary should be inventoried and 

defined. This can be done in the form of a survey sent out to the data sources, data centers, and Principal Investigators 

(PIs). Also all data sources should be identified and any arrangements required to obtain the data made (e.g. International 

or Interagency agreements). Considerations regarding whether episodic or longer term data are required will 

impact these arrangements (particularly if cost is a factor). Historical or climatological data may be needed to define 

scientific objectives early on in the planning process. However, these data should also be included in the database. 

TIMELINE - Begin working 6 to 8 months prior to start of data gathering. 

(3) Data Formats and Volumes 

This information should be obtained at the time of the survey or inventory of data types. Issues to consider are the 

investigator’s needs (i.e. resolution, frequency) and requirements for data storage (volume of each data set) . Some 

data sets may be required to be converted from native format depending upon the use or analysis tools to be used. 

This conversion might be easiest done in real-time as data are received. In any event, conversion software must be 

obtained or written and data formats in the final archive must be compatible and easy to use by the researcher. All 

this information should be obtained at the time of the survey. 

TIMELINE - Begin working 6-8 months prior to start of data gathering. 

(4) Data Collection 

Data collection should commence at least 2 weeks prior to experiment start to allow enough time to ensure proper 

data ingest and archive procedures. If the data are required for real-time decision making, any visualization software 

should also be checked at this time. Metadata (or information about the data) MUST accompany the data. Metadata 

should contain information regarding instrumentation, calibration, site location, exposure, etc. Experience shows this 

information is extremely difficult to obtain especially after the fact, and is critical for determining the validity during 

any in-field intercomparisons or quality assurance process. 

TIMELINE - At least 2 weeks prior to start of data gathering. 

(5) Real-time Data Requirements 

This issue is usually addressed in the experiment design or operations plan documents. Real-time data needs are 

usually determined from operational requirements or the need to perform calibrations and intercomparisons in the 

field. It is strongly recommended to perform calibrations and intercomparisons to verify instrument performance and 

identify problems early before the entire data set may be bad. All this information can be archived in an on-line 

real-time catalog or standard report form documentation. 

TIMELINE - During field operations (preparation for these data discussed in previous items). 

(6) Data Quality Control 

This is an issue that requires the most attention and will assure a credible database in the final archive. Generally it 

should be the PI’s responsibility to perform the Quality Control (QC) on their own data since they are most knowledgeable 

regarding the data, instrumentation, and calibrations. In the case of operational data, the preparation of 

“composite” data sets combining data from various networks and/or instruments will show any bias from a spatial 

and temporal analysis. The utilization and development of analysis tools (including software exchange) will increase 

the efficiency of quality control. In any case, all quality control changes to the data set (i.e. flagging or estimation) 

must be thoroughly documented. Changing actual data is not recommended unless fully documented. 

TIMELINE - variable, but generally QC should be completed 6 to 12 months following the field deployment. 

IS ADD


(7) Data Archival 

The biggest archival decision is determining a centralized vs. a de-centralized data base. The advantage of a centralized 

database is all data are located in one location and access is usually better coordinated and quicker. The 

disadvantage is usually large storage is required and in many cases data sets will be duplicated from another data 

center. With the increase in Internet access, electronic links are making de-centralized databases more practical. 

Consideration should be provided to coordinate with other data centers that might archive complementary data sets 

(particularly when pertinent co-located measurements are made through another program). Another issue is what 

data to keep on-line vs. off-line. Generally the smaller data sets (i.e. in-situ) conform better to on-line retrieval and 

larger data sets such as satellite and radar are stored on tapes. Again, the amount of data kept on-line depends on 

the data volume,amount of available storage, project requirements/priorities and available staff to process more data 

sets. Finally, the concept of data integration should be considered when scientific objectives require the merger and 

“overlaying” of various data sets or creation of special data “composites”. This becomes a far more complex issue because 

additional planning must provide for spatial and temporal observations must be compatible. Also, standardized 

formats must be implemented. Special data products are usually the benefit of an integrated database. 

TIMELINE - 6 to 12 months depending when data sets are available. 

(8) Data Distribution 

The large barrel theory (and black hole corollary) states that “It is a lot easier to archive data than to disseminate 

it”! Many issues must be considered. First, the policy of restricted vs. open data access is dependent on logistics 

such as funding, staff support, agreements between PIs, quality of the data (preliminary versus final) and varying 

policies of numerous data centers in the case of a de-centralized database. In some cases this will be determined 

on a data set by data set basis. In any event, ease of data access must be strongly encouraged. The data should be 

disseminated with all available metadata and inventories. In some cases the distribution of “browse” products such 

as radar reflectivity composites, makes data selection and case study identification easier particularly for voluminous 

data sets. The production and distribution of customized data requests must be seriously considered due to the typical 

large impact on staff time and computer resources. 

TIMELINE - 6 to 12 months depending when data sets are available. 

(9) Coordination with Other Programs 

This issue is usually associated with a de-centralized database or collaboration among projects with compatible 

scientific objectives such as the research project cluster we analysed. The consideration of data and analysis tool 

exchange implies good coordination and interoperability between data centers. In the case of collaborative research 

the issue of standardized data formats becomes more critical. The benefit of such coordination is the efficient cost 

shared resources of database development in this age of budget shortfalls. 

5.4.4 Principles of Good Data Management 

Good data management is essential for the effective use of the information resources of public bodies in all their 

forms. Section 2, above, identified a range of key data management activities; these are discussed below. 

Avoid re-collecting data. 

The largest potential for waste in Data Management is reacquiring an existing dataset. This has been done frequently 

by public and private sector organizations and must be avoided. In the USA, Executive Order 1290612 

requires government agencies to put internal procedures in place to ensure that they check whether other agencies 

have already collected information they plan to acquire. Whereas no equivalent instruction exists in countries such as 

the UK, it should be regarded as best practice to use the gigateway13 Data Locator to search for existing geospatial 

datasets before new ones are created. 

Data lifecycle control. 

IS ADD


Good Data Management requires that the whole life cycle of datasets be managed carefully. This includes: 

• Business justification, to ensure that thought has been given to why new data are required rather than existing 

data amended or used in new ways, how data can be specified for maximum use including the potential to meet 

other possible requirements, and why the costs of handling, storing and maintaining these data are acceptable 

and recoverable. 

• Data specification and modelling, processing, database maintenance and security, to ensure that data will be fit 

for purpose and held securely in their own databases. 

• Ongoing data audit, to monitor the use and continued effectiveness of the data. 

• Archiving and final destruction, to ensure that data are archived and maintained effectively until they are no 

longer needed or are uneconomical to retain. 

Data policy. 

The fundamental step for any organization wishing to implement good Data Management procedures is to define 

a Data Policy. The document may have different names in different public bodies but in each it should be a set of 

broad, high-level principles that form the guiding framework within which Data Management can operate. This is the 

document that is approved at senior levels in the public body, and the senior executive who owns the policy (Data 

Management Champion) manages the resources for its implementation. 

Data ownership. 

One key aspect of good Data Management is the clear identification of the owner of the data. Normally this is the 

organization or group of organizations that originally commissioned the data acquisition or compilation and retains 

managerial and financial control of the data. The Data Owner has legal rights over the dataset, the IPR and the 

Copyright. Data ownership implies the right to exploit the data, and if continued maintenance becomes unnecessary or 

uneconomical, the right to destroy them, subject to the provisions of the Public Records and Freedom of Information 

acts. Ownership can relate to a data item, a dataset or a value-added dataset. IPR can be owned at different levels. 

For example, a merged or value-added dataset can be owned by one organization, even though other organizations 

own the constituent data. If the legal ownership is unclear, there are risks that the data can be wrongly exploited, used 

without payment of royalty to the owner, neglected or lost. It is therefore important for Data Owners to take action to 

establish and document: 

• The ownership, IPR and Copyright of their data so that these can be safeguarded. 

• The statutory and non-statutory obligations relevant to their business to ensure that the data are compliant. 

• The departmental policies for data security, disclosure control, release, pricing and dissemination. 

• The agreement reached with users and customers on the conditions of use in a signed Memorandum of Agreement, 

before data are released. 

Metadata. 

All datasets must have appropriate metadata compiled for them. At the simplest level metadata are “data about 

data”. Metadata provide a summary of the characteristics of a dataset. A good metadata record enables the user of a 

dataset or other information resource to understand the content of what they are reviewing, its potential value and its 

limitations. There are many metadata standards, but the ones that are most appropriate to GI are: 

• ISO 19115:200314 (Geographic Information – Metadata); and 

IS ADD


• UK GEMINI – (Geo-spatial Metadata Interoperability Initiative) The profile is the result of a collaboration 

between the AGI15 and the e-Government Unit16. A profile is a subset of one or several information standards 

that adopts elements, structures or rules for different user communities. Adherence to the UK GEMINI profile, 

which will replace the gigateway Discovery Metadata Specifications (the NGDF Standard) as the UK’s national 

geospatial metadata profile, allows for the creation of discovery metadata with both ISO 19115 (Geographic 

Information – Metadata) and the national e-Government Metadata Standard (eGMS), ensuring compliance with 

both. 

Comprehensive advice on the compilation of metadata can be found in the IGGI booklet entitled “The Principles of 

Good Metadata Management17”, the second edition of which was published in May 2004. 

Meta-Data Support for Content Chunks. 

Meta-data must be meaningful: appropriateness adequateness 

David Marco: “Meta data is all physical data (contained in software and other media) and knowledge (contained in employees and 

various media) from inside and outside an organization, including information about the physical data, technical and business processes, 

rules and constraints of the data, and structures of the data used by a corporation.” 

Meta-data should be mature: time integrity 

e.g. for dynamic or active meta-data 

Meta-data should be manageable: Storage media and capacity, concurrent and secured access, ease of use 

Meta-data should be maintainable: manage and automate the processes, open interfaces, versioning, simple algorithm 

for deriving dynamic meta-data, maintenance 

Meta-data should be migrateable: share-ability, interoperability, portability 

Data Quality. 

Good Data Management also ensures that datasets are capable of meeting current needs successfully and are 

suitable for further exploitation. The ability to integrate data with other datasets is likely to add value, encourage 

ongoing use of the data and recover the costs of collecting the data. The creation, maintenance and development of 

quality data require a clear and well-specified management regime. 

Data Steward. 

All datasets need to be managed by a named individual referred to here as the Data Steward; also known as dataset 

manager and data custodian. A Data Steward should be given formal responsibility for the stewardship of each major 

dataset. They should be accountable for the management and care of the data holdings assigned to them, in line with 

the defined data policy. Section 6 provides a list of the responsibilities of the Data Steward. Data Management 

Plan. 

The Data Steward is responsible for the development of a Data Management Plan for each dataset under their responsibility. 

The objective of the Data Management Plan is to ensure: 

• That the dataset is fit for the purpose for which it is required. 

• That the long-term management of the dataset is considered for potential re-use. 

The individual management plans should be compliant with the local data policy and include: 

• Scope of the plan 

• Link to metadata 

IS ADD


• Responsibilities 

• IPR and Copyright 

• Quality objectives 

• Standards (International, National and local) adopted during compilation of the data 

• Staff resources required to manage the dataset 

• Physical resources required to manage the dataset 

• Long term management of the dataset 

Data Management procedures. 

Individual datasets may require compilation of specific Data Management procedures. These may be needed where 

specific datasets require detailed operational procedures to ensure their quality; examples of this include scientific 

and statistical datasets. Data access and dissemination. 

Although this aspect will depend upon the business and the financial policy of the organization, the following guidance 

should be followed. 

• Public access to data should be provided in line with The Freedom of Information Act, The Data Protection 

Act and The Human Rights Act. 

• IPR and Copyright of datasets owned by public bodies must be protected, as data should be regarded as an 

asset. 

• IPR and Copyright of third-party data must be respected. 

• The potential for commercial re-use and exploitation of the dataset should be considered. 

• The right to use or provide access to data can be passed to a third party, subject to agreed pricing and dissemination 

policies. 

• Consideration should be given to the impact of European developments such as the Public Sector Information 

Directive and INSPIRE. 

Data audit. 

Data Management audits are recommended to ensure that the management environment for given datasets are 

being maintained. Their purpose is to provide assurance to the Data Management Champion that the resources expended 

are being used appropriately. Audits of major datasets should be commissioned to ascertain the level of 

compliance with data policies and the Data Management plans and procedures that have been prepared. 

5.4.5 Establishing a Data Policy 

IGGI has prepared the following model Data Policy Statement, which Government departments/agencies may wish 

to use or adapt to meet their own Data Management needs. 

Data acquisition. 

• All projects and other activities that give rise to substantial datasets will establish at the outset whether suitable 

data already exist in a potentially usable form, or whether new data need to be acquired. 

IS ADD


• Before projects are approved, they must establish how the data acquired will be exploited to the full, who will 

be responsible for full exploitation of the data, and how the benefits will be maximized and shared. 

• Subsequent data handling and storage needs will be considered, and plans put in place to ensure that databases 

are maintained in such a way that maximum use can subsequently be made of them. 

Data care – Stewardship. 

• Databases will be managed closely, with clear responsibility for stewardship established and individuals made 

accountable for ensuring Data Management procedures are followed. 

• Data will be held securely within their own database, and adequate provision made for their long-term care. All 

data will be validated and quality assured before being used or archived. 

• Easy access will be given to data holdings, both for staff and bona fide ‘customers’. 

• Data that are not legally required to be retained will not be destroyed or put at risk without first exploring 

all other possibilities and then demonstrating clearly that the costs of retaining them cannot be justified by 

potential benefits, or that the replacement cost is less than the storage costs. 

Data use and exchange. 

• Memoranda of Agreement will be drawn up with Users and Customers who receive data, with respect to the 

subsequent use of such data. These will include confidentiality declarations and conditions of use. 

• Intellectual Property Rights will be protected in relation to any development of information, by specifying 

formally any restrictions on the use of the data in formal licensing arrangements. 

• Adequate provision will be made for the widest possible public access to data and associated metadata. 

• Costs will be recovered for the handling of data and information, in line with departmental policies, which will 

be made readily available. 

• The appropriate return will be charged when data are passed on to other parties seeking to make commercial 

gain. 

Review. 

The Data Policy will be monitored regularly and will be modified in the light of developments (e.g. technology 

and legislation) and experience. Information handling practices will be audited so that duplication can be minimized. 

5.4.6 Resolving Problems by Master Data Management Strategies 

The first element of an information management strategy is the development of master data management. This approach 

allows to resolve a number of pitfalls and errors we have been observing in the research projects analysed. 

• One of the most common pitfalls I’ve seen is when research clusters try to identify and standardize all their 

master data elements in a single initiative. This “big bang” approach usually doesn’t work for any IT project, 

MDM initiatives included. It often simply causes confusion and makes master data problems seem intractable. 

Instead of trying to resolve all your master data issues at once, begin small with a pilot project on a single master 

data element. I recommend beginning with the “customer” master data element. This is the most pervasive data 

element in many companies, and it is linked to most other master data elements. Thus, it is likely that once the 

IS ADD


customer data element is standardized, we’ll have a leg up on standardizing other master data elements such 

as raw data, sensor data, measurement data, aggregated data, materials, vendor, georeferential data, etc. Also, 

once we’ve gotten your feet wet and better understand how the standardization process works, it should be 

easier to tackle more than one data element at a time. 

• Another pitfall to avoid is scope creep. When we begin with a single master data element, such as experiment, 

there will usually be someone who says something like, “Well, we can’t understand ’trip chemistry data’ until 

we define ’trip’ or ’chemical substance.”’ 

That’s simply untrue. Data elements are discrete entities; they can stand alone. They can be defined and standardized 

regardless of any other entities they’re related to. If they can’t, then perhaps they’re not really data 

elements themselves but rather attributes of a data element. At any rate, it’s extremely important - especially 

with regard to a pilot MDM project - that the scope of the project is clearly defined before we begin and adhere 

to that scope as much as practicably possible. 

• A third common issue I’ve encountered is confusion over who actually “owns” master data elements and who 

has responsibility for managing the company’s master data. You can help avoid this confusion by developing 

and implementing a data governance plan that clearly delineates data ownership and accountability structures 

before you begin an MDM initiative - even the pilot initiative. 

A well-developed data governance program should employ a model that clearly defines roles and responsibilities 

as well as hierarchies and accountability structures. Common components of a data governance model 

include: 

• A data management review board to provide strong leadership and oversight for the governance program, 

to set governance policies and to resolve critical issues; 

• An enterprise data governance team responsible for the day-to-day coordination of data governance activities 

and maintenance of the corporate metadata repository; and 

• A management and execution function that includes compliance and change officers, modelling resources 

and cross-functional representation from the company to execute compliance requirements and manage 

change. 

• Finally, perhaps the most critical pitfall to avoid is the failure to show the value of the MDM initiative to the 

research project cluster. If PI’s think the MDM initiative is simply another IT project, they might not embrace 

it - and you may even encounter resistance to the project. 

One way to avoid this pitfall is to form collaboration between the research cluster and IT leaders of the MDM 

initiative to show the value of the project to the PIs within the research cluster. The collaboration should strive 

to show how cluster-wide standardized master data can help provide better access to accurate, consistent data 

that knowledge workers and decision-makers need to do their jobs. The collaboration should also stress the 

value of standardized master data in sustaining regulatory compliance and improving business performance. 

Each MDM initiative is different because every project cluster is different. The project cluster may encounter 

issues that are far different from these that we’ve outlined. However, to begin small, we can stick to the project 

proposal, put an appropriate data governance plan in place and strive to continually show the value of the MDM 

initiative to the research cluster, thus having a good grounding to help identify and overcome issues that might arise. 

5.4.7 Towards Holistic Tactics for Data Management 

IS ADD


5.5 Techniques for Information Management 

5.5.1 The Right Needle from the Right Haystack 

Among the technological generations of World Wide Web, content of any kind and for any audience grew and grew. 

Meanwhile the user is overwhelmed by a flood of information offered to him indiscriminately by the World Wide 

Web, which leads to an significantly decreasing usability. Search engines have not (yet) improved this picture. They 

introduce their own policies and biases. They filter out useful information and direct the searcher in a specific way. 

Search is moreover still bound to addresses which may be known or unknown to the searcher. 

The user is typically not able to determine the quality of data obtained. He or she can 

• neither judge of accuracy, actuality, approporiateness, completeness, correctness, independence, learnability, 

maturity, reliability, stability, suitability, or understandability, 

• nor decide whether data obtained are at the right moment of time, of the right kind, in the right dose, of the 

right form, in the complete extent, and within the restrictions agreed upon in advance. 

The is no authority for quality. The business model for the World Wide Web is based on freedom of content to certain 

extend. This freedom may be nicely used or may be misused. Wikipedia is a typical example of partially very useful 

and partially completely confusing information 4 . 

5.5.2 Missing Adaptivity and User Orientation 

Information as processed by humans is perceived in a very subjective way. As for a web information system, the 

determining factor whether the user can derive advantage from the content delivered is the user’s individual situation 

[Kob05], i.e. the life case, user model and context. The same category of information can cause various needs in 

different life cases. For instance, a divorcee has a completely different need for information in fatherhood than a 

prospective father, although both of them reside in the same category. 

Not any user can deal with any kind of content. For the casual user or the novice other content has to be delivered 

than for experts. The common web information system doesn’t reflect the user’s situation and neglects the user’s 

specific needs. As a result, the user is spammed with information which is predominantly out of focus. The abundance 

of information also makes it impossible to separate useful from for the user useless content. Any by the absence of 

meta data unspecified information reduces the usability of World Wide Web on the whole. 

Whether the content obtained from the web may be classified as information depends on the user. There is no 

commonly agreed definition of information. We may define information as follows within the five layer model of 

[MST05, 28]: 

Information, as processed by human users of web sites, is 

• data 

• perceived or noticed, selected and organized by its receiver, 

• because of his subjective human interests, originating from his instincts, feelings, experience, intuition, common 

sense, values, beliefs, personal knowledge, or wisdom, 

• simultaneously processed by his cognitive and mental processes, and 

• seamlessly integrated in his recallable knowledge. 

Therefore, web site modelling must include description of the information need of actors. The information need can 

be specified as 

• conceptual incongruity in which a person’s cognitive structure is not adequate to a task, 

• when a person recognizes that something wrong in their state of knowledge and desires to resolve the anomaly, 

• when the current state of possessed knowledge is less than is needed, 

4 See, for instance, the English entry “Dresden” for the German city Dresden. Everybody knows something about Dresden and may add 

also wrong information. We found more than 40 errors for this entry in May 2008. 

IS ADD


• when internal sense runs out, and 

• when there is insufficient knowledge too cope with voids, uncertainty or conflict in a knowledge area. 

Moreover, users are limited 

• in their abilities for verbalisation, 

• in their abilities for digestion of data, and 

• by their habits, practices, and cultural environment. 

These limitations may cause intellectual overburdening of users. Most systems that require sophisticated learning 

courses for their exploration and utilization did not consider these limitations and did not cope with real life situations. 

The approach we use for avoiding overload is based on observation of real applications before developing the web 

information system. 

5.5.3 Profiles and Portfolio of the User 



the mission of the WIS [31]. 

To characterize the users of a WIS we distinguish between education, work and personality profiles. The education 

profile contains properties users can obtain by education or training. Capabilities and application knowledge as a result 

of educational activities are also suitable for this profile. Properties will assigned to the work profile, if they can be 

associated with task solving knowledge and skills in the application area, i.e. task expertise and experience as well 

as system experience. Another part of a work profile is the interaction profile of a user, which is determined by his 

frequency, intensity and style of utilization of the WIS. The personality profile characterises the general properties 

and preferences of a user. General properties are the status in the enterprise, community, etc., and the psychological 

and sensory properties like hearing, motoric control, information processing and anxiety. 








conditions. 

5.5.4 Users Life Cases 

For task completion users need the right kind of data, at the right time, in the right granularity and format, unabridged 

and within the frame agreed upon in advance. Moreover, users are bound by their ability to verbalise and digest data, 

and their habits, practices, and cultural environment. To avoid intellectual overburdening of users we observe real 

applications before the system development leading to life cases [ST07c]. Life cases help closing the pragmatic gap 

between intentions and storyboarding. They are used to specify the concrete life situation of the user and characterise 

thus a bundle of tasks the user should solve. Syntax and semantics of life cases have already been well explored in 

[31]. 




IS ADD


5.5.5 Information Portfolios 

A WIS portfolio consists of an information portfolio and a utilisation portfolio. They are mapped to content and 

functionality specifications, respectively. in doing so we distinguish between content provided by the WIS and information, 

which is related to an actor or user. 

Consumption and Production of Information. 

Following [ST05] on a high level of abstraction we may think of a WIS as a set of abstract locations, which 

abstract from actual pages. A user navigates between these locations, and on this navigation path s/he executes a 

number of actions. We regard a location together with local actions, i.e. actions that do not change the location, as a 

unit called scene. 

Then a WIS can be described by an edge-labelled directed multi-graph, in which the vertices represent the scenes, 

and the edges represent transitions between scenes. Each such transition may be labelled by an action executed by the 

user. If such a label is missing, the transition is due to a simple navigation link. The whole multi-graph is then called 

the story space. 

A story is a path in the story space. It tells what a user of a particular type might do with the system. The 

combination of different stories to a subgraph of the story space can be used to describe a “typical” use of the WIS 

for a particular task. Therefore, we call such a subgraph a scenario. Usually storyboarding starts with modelling 

scenarios instead of stories, coupled by the integration of scenarios to the story space. 

Each WIS user who enters the system with a particular goal has information needs that have to be satisfied by 

the system. In addition, an active WIS will also request information from its users. We use the term information 

consumption for the information provided by the system to its users, and information production for the information 

entered by a user into the system. 

When a user enters the WIS, the information needs are usually not known in advance. Part of the needed information 

may depend on other parts, on decisions made while navigating through the WIS, and even on the information 

provided by the actor him/herself. That is, the information consumption and production depends on the path through 

the WIS, i.e. in our terminology on the story. Therefore, information consumption and production is associated with 

each scene of the story space. Assuming that there is a database for the data content of the WIS with database schema 

S, information consumption on a scene s definitely accounts for a view V s over S. That is, we have another schema 

S V and a computable transformation from databases over S to databases over S V . Such a transformation is usually 

expressed by a query q V . 

• With each scene s we associate a view V s = (S V , q V ) called information consumption view. Elements of 

q V (db) for some database db represent the information consumption of an actor. 

• With each action α we associate a data type t α called information production type. Values of type t α represent 

the information production by an actor. 

Information consumption and information production of an actor for all scenes together define the information 

portfolio of the actor. 

Information Need and Demand. 

We distinguish between the information need and the information demand. The former one refers to a perceived 

lack of something desirable or useful, while the latter one results from an act of demanding or asking. 

The information need is generally related to objectives such as becoming informed. It is based on the intuitive 

insight that the current information and knowledge is insufficient for the task under consideration, or the necessary 

information cannot be easily derived from data that is currently available, or the uncertainty, indefiniteness, fuzziness, 

and contradictions do not permit drawing conclusions. 

The information need can be considered to be subjective, but at the same time it can be the reason for a certain user 

visiting a website without an intention that is related to a life case. The information need is based on the conceptual 

incongruity in which a user’s cognitive structure is not adequate to a task, e.g. when a user recognizes that something 

wrong in their state of knowledge and desires to resolve the anomaly, when the current state of knowledge is less than 

IS ADD


what is needed, when internal sense runs out, or when there is insufficient knowledge to cope with gaps, uncertainties 

or conflicts in a knowledge area. Therefore, as the behaviour of actors is mainly related to life cases and the portfolio, 

we have to distinguish between information provided for support of life cases and auxiliary consumed information 

that is provided to visitors as a service. 

The information demand is related to the portfolio under consideration and to the intents. We may distinguish 

between information that is necessary, desirable, or feasible. The information demand is mapped to the views defining 

information consumption and production for each scene of the story space as defined above. The information demand 

is characterised by information that is missing, unknown, necessary for task completion, and directly requested. 

We can distinguish between the information demand of an actor and the information demand of a user. As actors 

represent groups of users, the information demand of a user contains the information demand of an actor. While 

the information demand of actors is determined by the portfolio, the additional information demand of a user is 

determined by the user profile. 

The Concept of Persona. 

The information demand is used to derive the information consumption of each user. This is related to the definition 

and meaning of information for the user based on received / requested data, which has to be organized, interpreted, 

understood, and integrated into his/her knowledge. In general, this would require to model the user, the specific request 

of the user, the ability to understand the data, and the skills, which is infeasible. However, as the information 

demand of actors is a subset of the one of users represented by the actor, we can use prototypes of individuals called 

personae to determine the information demand. In addition, we model a task-oriented life case of these individuals, 

and derive the information demand, data requirement, and the specific utilisation requirements. 

A persona is characterized by an expressive name, profession, intents, technical equipment, behaviour, skills and 

profile, disabilities, and specific properties such as hobbies and habits. A persona is a typical individual created to 

describe the typical user based on the life cases, the context, the portfolio, and the profile. User models characterize 

profiles for education, work, and personality. This characterization can be extended by 

• identity with name, pictures, etc., 

• personal characteristics such as age, gender, location, and socio-economic status, 

• characterization of reaction to possible users error, 

• specific observed behaviour including skill sets, behavioural pattern, expertise and background, and 

• specific relationships, requirements, and expectations. 

For the persona the following specification template can be used: 

Persona: 

〈persona name〉 

Identity: 

〈first and last name, photo〉 

Demography of persona: 〈age, gender, location, status〉 

Robustness of WIS usage: 〈criticality of errors〉 

Kind of user: 

〈general description〉 

Specific behaviour: 〈general description〉 

Specific interactivity: 〈general description〉 

Based On User Profile: 〈name〉 

Refined education profile: 


Refined work profile: 〈general description〉 

Refined personality profile: 


Based On Portfolio: 〈name〉 

Refined task: 


Refined involvement: 〈general description〉 

Refined collaboration: 〈general description〉 

IS ADD


Refined restrictions: 〈general description〉 

Based On Life Case: 〈name〉 

Refined characterisation: 

〈outcome description〉 

Refined life case flow: 〈general graphical description〉 

Refined figures: 〈actors list〉 

Refined context: 〈general context description〉 

Refined representation: 〈general behavior〉 

Based On Context: 

〈name〉 

Refined persona context: 


Refined storyboard context: 


Refined WIS context: 〈general description〉 

Refined temporal context: 


The explicit specification of personae has several benefits. They provide communication means within the development 

team, focus on a specific target set of actors, and help to make assumptions about the target audience. Thus, 

personae may augment the WIS portfolio specification, but should not be overused. 

5.5.6 The Six-Step Transformation of a Question to Queries 

This part of the lecture is based on the paper [BDT12]. 

Intentionally, a search request to a database system consists of a search request and a result concept. Therefore, 

query forms and answer forms are used to accommodate the search request and the result concept. 

Syntactical and conceptual quality criteria in query formulations are: 

Restriction of ambiguity: Search request are usually formulated ambiguously and using the context of the speaker, 

e.g., on the basis of ellipses. 

Computability: Queries must be expressed in a form that is computable by a computer. 

Effective computability: queries must be computable in a time frame restricted by the user and depending on the size 

of the database. 

Transformation to the query language: Queries must be expressible within the query language. 

Direct SQL query formulation is already a difficult task. The difficulty is caused by SQL itself, by the complexity 

of the database schema and supporting (view) schemata, by the inherent complexity of the question, by the set of 

potential variations and variants of the same question, and by assessment of the correctness of the query. The most 

difficult part is the derivation of the query and the form of the potential answer for a given question. It is thus not 

surprising that this problem is very seldom tackled in literature so far. Based on our model of search, the properties 

of SQL, and the theory, we can, however, develop a general procedure to query formulation. 

Query Formulation Step 1: Extension of the Search Question. 

Questions have their own context, use ambiguities, are condensed to ellipses, and are bound by a scope and issuers. 

There are many linguistic techniques that can be used for question reformulation: resolution of ambiguities, categorisation 

and flexibilisation, synonym or homonym or hypernym or meronym or holonym association, explicit extraction 

of internal bracket structures, decontextualisation, and unfolding of ellipses. 

We may also use question completion and injection of metadata and common sense. Aggregation requests within 

a query need sharpening. 

IS ADD


Questions can be categorised either to be open-world questions or closed-world questions. This drives the interpretation 

of logical connectives. Objects in a database may have a fixed property over the entire lifespan or may use 

volatile values. Therefore, the pointer to these objects must be flexible. 

Each question is based on some namespace that defines semantical or pragmatical meaning of words in a sentence. 

The result of this step is a question with its environment. 

Query Formulation Step 2: Orthonormalisation and Extension of the Search Question and Mapping 

to Query Forms and Answer Forms. 

We can categorise questions according to their structuring and their orientation within the essential part of the 

W 7 (+W 4 +W 17 H) frame. Each orientation has its canonical form for question verbalisation. This form can be used 

for question orthonormalisation. 

Questions use concepts which are common in the application and useful in the current situation. We thus extend 

a question by direct integration of the matter. Questions may use abbreviations and thus use words which have their 

own definition. This definition is used to derive auxiliary query forms which can be used for query formulation, e.g., 

by folding. A typical abbreviation are aggregates. 

Now, we can use the orthonormalised question and derive a query form graph. This graph consists of nodes which 

are labelled by the main words and edges that represent associations among the nodes. 

Questions are stated by users. Their (rough) profile and portfolio can be used to derive the information demand of 

the user. This information demand is an orthogonal and implicit dimension of the question. Therefore, the question is 

extended by the information demand. 

Proper names and values in the question are used for the instantiation of parameters in the query form (and answer 

form). 

Answer forms use answer form patterns in dependence on the expectation (i.e., information demand) of the 

question issuer. 

The instantiated query and answer forms are results of this step. 

Query Formulation Step 3: Rephrasing of the Question into an Existential Form. 

SQL and other database languages request a specific form of the query. Queries are typically given in an existential 

form with a strictly defined semantics. Therefore, we first map all connectives and quantifiers within the query form 

to strict ones. Negation and logical connectives must often be rephrased according to open-world or closed-world 

assumptions. Boolean formulas are transformed into a normal form expression. Inner quantifiers in a query form are 

transformed to prefix quantifiers based on predicate calculus. 

Set requests are represented by a canonical set query. Special attention is required for optional values or values 

which might be represented by null values. 

Rephrasing a question also results in the transformation of the query form and correspondingly of the answer 

form. 

The result of this step are normalised question and answer forms. 

Query Formulation Step 4: Mapping of the Query Form to Database Schema Notions. 

Now we can use the database schema for injection of schema notions into the query form. If we use an extended 

ER schema S then we can directly embed G Q into the database schema. This embedding extends the query graph 

with schema notions and paths from S. We might choose one or combine these paths based on preference rules 

or pragmatic information. Schema semantics is used for semantic extension of the query form. Typical constraints 

(referential integrity constraints, null or default values, key constraints) are used for derivation of a semantical query 

form. Integrity constraints such as referential integrity constraints can be used for query shortening. Embedding G Q 

into S can be based on graph homomorphisms. 

Query form mapping is based on identifying matchings, selection of the context from the schema, pruning the 

mapping to minimal context, selection of appropriate paths, removal of duplicates, decomposition of the query form 

to sub-forms and composition of components. 

IS ADD


The auxiliary forms are used for view or temporary table formulation. 

Additionally, schema definitions can be incorporated into the query form. 

Query Formulation Step 5: Derivation of the Extended Answer Form.. 

The mapping of the query form can be used for refinement, context extension and instantiation of answer forms. The 

answer form pattern is then refined for the answer representation. Result parameters are identified. 

Answer forms may be extended by features for their extension. These features are similar to cube functions or 

stream functions. 

Query Formulation Step 6: Derivation of the Database Query. 

Now we can use the extended query form and the extended answer form for derivation of a query or of queries and 

views. 

A Small Example 

Let us consider a simple university schema [Tha00] that allows to record the enrollment of courses by students. Given 

now the following question: 

Which students do anything together ? 

This question can be translated based on the first query formulation step to 

Which students enroll all university lectures together ? 

We can derive from this question 

Give me all students which enroll all lectures together and only together? 

Let us abstract from lectures and only consider course at the first glance. 

The background of the question are the sets of lectures that a student a and another student b enrols. These two 

sets must be equal. 

The Visual SQL Representation. 

VisualSQL 5 allows a visual verbalisation of queries. 

Let us assume that in step 1 we realised that we are not interested in those courses which one of the students 

dropped. We are only interested in common trials of student pairs in the same time. One of them might get a grade 

fail and the other one a grade very good. Thus would mean that we have to take into account the semesters as well. 

Let us thus assume that we are not interested in course but in lectures, i.e., in those students which enrol a course in 

the same semester. 

This difference in question interpretation must be detected in the first step. 

The result is the query in figure 9 which displays the set correspondence of successfully enrolled course by 

different students. 

The Mathematical Transformation. 

We may now use the logical correspondence 

¬∃v((¬Enrol(a, v) ∨ ¬Enrol(b, v)) ∧ (Enrol(a, v) ∨ Enrol(b, v))) 

= 

∀v((Enrol(a, v) ∧ Enrol(b, v)) ∨ (¬Enrol(a, v) ∧ ¬Enrol(b, v))) 

Step 3 will result in a dense and not simply to comprehend query. The query form is rather simple in this case. If 

follows the SQL frame. The corresponding answer form is now based on the information demand. 

Now we can associate the question with schema notions and get the following query: 

5 See: http://www.informatik.uni-kiel.de/en/information-systems-engineering/miscellaneous/visualsql/ 

IS ADD


Person P1 

√ Name 

DateOfBirth 

... 

= 

= 

Student S1 

StudNo 

Name 

DateOfBirth 

... 

= 

Enrol 

StudNo 

Semester 

CourseNo 

Grade 

... 

IS NOT NULL 

< 

== 

Person P2 

√ Name 

DateOfBirth 

... 

= 

= 

Student S2 

StudNo 

Name 

DateOfBirth 

... 

= 

Enrol 

StudNo 

Semester 

CourseNo 

Grade 

... 

IS NOT NULL 

Abbildung 9: The correlated subqueries: VisualSQL queries are simpler to formulate than SQL queries 

SELECT S1.StudNo, S2.StudNo 

FROM Student AS S1, Student AS S2 

WHERE S1.StudNo < S2.StudNo AND 

NOT EXISTS ( 

SELECT * FROM Course AS V 

WHERE V.CourseNo IN 

(SELECT B.CourseNo FROM Enrol AS B 

WHERE S1.StudNo = B.StudNo 

OR S2.StudNo = B.StudNo) 

AND 

NOT EXISTS ( 

( SELECT * FROM Enrol AS B1 

WHERE S1.StudNo = B1.StudNo 

AND B1.CourseNo = V.CourseNo ) 

UNION 

( SELECT * FROM Enrol AS B2 

WHERE S2.StudNo = B2.StudNo 

AND B2.CourseNo = V.CourseNo ) 

) 

); 

We claim that this query is not developed by ordinary students. Empirical tests have shown that this query is not easily 

to comprehend. 

The Transformation from Visual SQL. 

The VisualSQL tool 6 generates based on a translation style for sets the following query which is different from 

the first one. Since the translation style is an option, we could also use another option and thus obtain a query that is 

similar to the first query. 

SELECT P1.Name, P2.Name 

FROM Person P1, Person P2, Student S1, Student S2, Enrol H1, Enrol H2 

WHERE P1.Name = S1.Name AND P1.DateOfBirth = S1.DateOfBirth AND 

S1.StudNo = H1.StudNo AND H1.Grade IS NOT NULL AND 

P2.Name = S2.Name AND P2.DateOfBirth = S2.DateOfBirth AND 

S2.StudNo = H2.StudNo AND H2.Grade IS NOT NULL 


(SELECT * 

FROM Enrol H3 

WHERE H3.Grade IS NOT NULL AND 

H3.StudNo NOT IN 

6 It is currently available on our website in a Java and in a .Net implementation and is freeware. 

IS ADD


(SELECT H4.StudNo 

FROM Enrol H4 

WHERE H4.StudNo = H2.StudNo 

AND H4.Grade IS NOT NULL) 

AND H1.StudNo = H3.StudNo) 


(SELECT * 

FROM Enrol H5 

WHERE H5.Grade IS NOT NULL AND 

H5.StudNo NOT IN 

(SELECT H6.StudNo 

FROM Enrol H6 

WHERE H6.StudNo = H1.StudNo 

AND H4.Grade IS NOT NULL) 

AND H2.StudNo = H5.StudNo) 

AND S1.StudNo < S2.StudNo 

GROUP BY P1.Name, P2.Name; 

We claim that this query is already a challenge for advanced computer engineering students. 

IS ADD


5.6 Techniques for Data Management 

5.6.1 Modelling Language Selection Matters 

The Sapir-Whorf Hypothesis 

Languages may however also restrict modelling. This restriction may either be compensated by over-development of 

language components or by multi-models 7 . The relational database modelling language uses integrity constraint as 

compensation component for the inadequate expressibility of the language 8 . 

The Sapir-Whorf hypothesis [Who80] results in the following principle: 

Principle of linguistic relativity: Actors skilled in a language may not have a (deep) understanding of some concepts 

of other languages. This restriction leads to problematic or inadequate models or limits the representation of 

things and is not well understood. 

The principle of linguistic relativity is not well understood. In [Tha10] we demonstrated via a crossroad example 

that Petri nets are often not the right tool for representation of behaviour. A similar observation on UML is made by 

Krogstie [Kro05]. 

The Cognitive Insufficiency of the Entity-Relationship Modelling Language 

Lakoff [Lak87] introduces six basic schemata of cognitive semantics without stating that this list of schemata is 

complete. 

• The container schema define the distinction between in and out. They have an interior, a boundary and an 

exterior. 

• The part-whole schema define an internal structuring and uses whole, part and configuration as construction 

units. 

• The link schema connects thing of interest. It uses various kinds of links for associating or un-associating 

things. 

• The center-periphery schema is based on some notion of a center. Peripherical elements are not as important 

than those in the center. 

• The source-path-goal schema uses source (or starting point), destination, path, and direction. It allows also to 

discuss main and side tracks. 

• Typical ordering schemata are the up-down, front-back and the linear ordering schema. They use spatial and 

temporal associations. 

We call a modelling language cognition-complete if these six schemata can be represented. 

The classical ER modelling language suffers from a number of restrictions. It uses the container and the link 

schemata. It allows to mimic the part-whole schema via special links (called IsA). This work-around is however badly 

misunderstood. In order to become cognition-complete integrity constraints must be used. Their cognitive complexity 

is however beyond surveyability of humans. A typical flaw of the classical ER model is the use of monster types that 

integrate stabile - almost not changing - properties and transient - often changing - properties. Objects are then taken 

as a whole. Unary relationship types easily resolve this problem if higher-order types are permitted. 

Extended ER modelling languages are however also not cognitive complete. The center-periphery schema can 

only be emulated. The source-path-goal schema can be represented by higher-order relationship types. The partwhole 

schema is supported by the specialisation via unary relationship types and by generalisation via cluster types. 

Ordering schemata can be defined using the order types and bulk types. 

7 Over-development of language components has been observed within the theory of integrity constraints in the relational model of data. 

More than 95 different and necessary classes of integrity constraints have been developed. Multi-modelling is extensively used for UML. 

8 We have discussed in [Tha10] how language may restrict our ability to represent things from the universe of discourse and to solve 

problems for the application. We used an example from [Jac07] who explained the impossibility to find an appropriate representation of street 

cross behaviour based on Petri net language. Abstract state machine (ASM) representation gives however a very simple representation and 

supports problem solution. The reason for the failure was the chosen modelling approach. In [Jac07] the modelling-in-the-local approach has 

been used. ASM modelling supports however also modelling-in-the-global. 

IS ADD


5.6.2 Master Data Management 

German notion: Stammdaten-Verwaltung 

Most software systems have lists of data that are shared and used by several of the applications that make up 

the system. For example, a typical ERP system as a minimum will have a Customer Master, an Item Master, and an 

Account Master. This master data is often one of the key assets of a company. It’s not unusual for a company to be 

acquired primarily for access to its Customer Master data. Rudimentary Definitions 

There are some very well-understood and easily identified master-data items, such as “customer” and “product”. 

In fact, many define master data by simply reciting a commonly agreed upon master-data item list, such as: customer, 

product, location, employee, and asset. But how you identify elements of data that should be managed by a masterdata 

management system is much more complex and defies such rudimentary definitions. In fact, there is a lot of 

confusion around what master data is and how it is qualified, necessitating a more comprehensive treatment. 

There are essentially five types of data in corporations: 

Unstructured: This is data found in e-mail, white papers like this, magazine articles, corporate intranet portals, product 

specifications, marketing collateral, and PDF files. 

Transactional: This is data related to sales, deliveries, invoices, trouble tickets, claims, and other monetary and nonmonetary 

interactions. 

Metadata: This is data about other data and may reside in a formal repository or in various other forms such as XML 

documents, report definitions, column descriptions in a database, log files, connections, and configuration files. 

Hierarchical: Hierarchical data stores the relationships between other data. It may be stored as part of an accounting 

system or separately as descriptions of real-world relationships, such as company organizational structures 

or product lines. Hierarchical data is sometimes considered a super MDM domain, because it is critical to 

understanding and sometimes discovering the relationships between master data. 

Master: Master data are the critical nouns of a business and fall generally into four groupings: people, things, places, 

and concepts. Further categorizations within those groupings are called subject areas, domain areas, or entity 

types. 

• For example, within people, there are customer, employee, and salesperson. 

• Within things, there are product, part, store, and asset. 

• Within concepts, there are things like contract, warrantee, and licenses. 

• Finally, within places, there are office locations and geographic divisions. 

Some of these domain areas may be further divided. Customer may be further segmented, based on incentives 

and history. A company may have normal customers, as well as premiere and executive customers. Product 

may be further segmented by sector and industry. The requirements, life cycle, and CRUD cycle for a product 

in the Consumer Packaged Goods (CPG) sector is likely very different from those of the clothing industry. The 

granularity of domains is essentially determined by the magnitude of differences between the attributes of the 

entities within them. 

While identifying master data entities is pretty straightforward, not all data that fits the definition for master data 

should necessarily be managed as such. 

We narrow the definition of master data to the following criteria, all of which should be considered together when 

deciding if a given entity should be treated as master data. 

Behavior: Master data can be described by the way that it interacts with other data. 

For example, in transaction systems, master data is almost always involved with transactional data. A customer 

buys a product. A vendor sells a part, and a partner delivers a crate of materials to a location. An employee is 

IS ADD


hierarchically related to their manager, who reports up through a manager (another employee). A product may 

be a part of multiple hierarchies describing their placement within a store. 

This relationship between master data and transactional data may be fundamentally viewed as a noun/verb 

relationship. Transactional data capture the verbs, such as sale, delivery, purchase, email, and revocation; master 

data are the nouns. This is the same relationship data-warehouse facts and dimensions share. 

Life cycle: Master data can be described by the way that it is created, read, updated, deleted, and searched. This life 

cycle is called the CRUD cycle and is different for different master-data element types and companies. 

Create 

For example, how a customer is created depends largely upon a company’s business rules, industry segment, 

and data systems. One company may have multiple customer-creation vectors, such as through the internet, 

directly through account representatives, or through outlet stores. Another company may only allow customers 

to be created through direct contact over the phone with its call center. Further, how a customer element is 

created is certainly different from how a vendor element is created. The following table illustrates the differing 

CRUD cycles for four common master-data subject areas. 

Customer Product Asset Employee 

Customer visit, such as Product purchased or Unit acquired by opening HR hires, numerous 

to Web site or facility; manufactured; SCM involvement 

a PO; approval process forms, orientation, be- 

account created 

necessary 

nefits selection, asset 

allocations, office assignments 

Read Contextualized views 

based on credentials of 

viewer 

Update Address, discounts, 

phone number, preferences, 

credit accounts 

Destroy Death, bankruptcy, liquidation, 

do-not-call. 

Search CRM system, callcenter 

system, contactmanagement 

system 

Periodic inventory catalogues 

Packaging changes, 

raw materials changes 

Canceled, replaced, no 

longer available 

ERP system, ordersprocessing 

system 

Periodic reporting purposes, 

figuring depreciation, 

verification 

Transfers, maintenance, 

accident reports 

Obsolete, sold, destroyed, 

stolen, scrapped 

GL tracking, asset DB 

management 

Office access, reviews, 

insurance-claims, immigration 

Immigration status, marriage 

status, level increase, 

raises, transfers 

Termination, death 

HR LOB system 

Cardinality: As cardinality (the number of elements in a set) decreases, the likelihood of an element being treated as 

a master-data element - even a commonly accepted subject area, such as customer - decreases. 

For example, if a company has only three customers, most likely they would not consider those customers 

master data - at least, not in the context of supporting them with a master-data management solution, simply 

because there is no benefit to managing those customers with a master-data infrastructure. Yet, a company with 

thousands of customers would consider customer an important subject area, because of the concomitant issues 

and benefits around managing such a large set of entities. The customer value to each of these companies is the 

same. Both rely upon their customers for business. One needs a customer master-data solution; the other does 

not. Cardinality does not change the classification of a given entity type; however, the importance of having a 

solution for managing an entity type increases as the cardinality of the entity type increases. 

Lifetime: Master data tends to be less volatile than transactional data. As it becomes more volatile, it typically is 

considered more transactional. 

For example, some might consider “contract” a master-data element. Others might consider it a transaction. 

Depending on the lifespan of a contract, it can go either way. An agency promoting professional athletes might 

consider their contracts as master data. 

Each is different from the other and typically has a lifetime of greater than a year. It may be tempting to 

simply have one master-data item called “athlete”. However, athletes tend to have more than one contract at 

any given time: one with their teams and others with companies for endorsing products. The agency would 

need to manage all those contracts over time, as elements of the contract are renegotiated or athletes traded. 

Other contracts - for example, contracts for detailing cars or painting a house - are more like a transaction. They 

IS ADD


are one-time, short-lived agreements to provide services for payment and are typically fulfilled and destroyed 

within hours. 

Complexity: Simple entities, even valuable entities, are rarely a challenge to manage and are rarely considered 

master-data elements. The less complex an element, the less likely the need to manage change for that element. 

Typically, such assets are simply collected and tallied. 

For example, Fort Knox likely would not track information on each individual gold bar stored there, but rather 

only keep a count of them. The value of each gold bar is substantial, the cardinality high, and the lifespan long; 

yet, the complexity is low. 

Value: The more valuable the data element is to the company, the more likely it will be considered a master data 

element. Value and complexity work together. 

Volatility: While master data is typically less volatile than transactional data, entities with attributes that do not 

change at all typically do not require a master-data solution. 

For example, rare coins would seem to meet many of the criteria for a master-data treatment. A rare-coin 

collector would likely have many rare coins. So, cardinality is high. They are valuable. They are also complex. 

For example, rare coins have a history and description. There are attributes, such as condition of obverse, 

reverse, legend, inscription, rim, and field. There are other attributes, such as designer initials, edge design, 

layers, and portrait. Yet, rare coins do not need to be managed as a master-data item, because they don’t change 

over time—or, at least, they don’t change enough. There may need to be more information added, as the history 

of a particular coin is revealed or if certain attributes must be corrected. But, generally speaking, rare coins 

would not be managed through a master-data management system, because they are not volatile enough to 

warrant a solution. 

Reuse: One of the primary drivers of master-data management is reuse. 

For example, in a simple world, the CRM system would manage everything about a customer and never need 

to share any information about the customer with other systems. However, in today’s complex environments, 

customer information needs to be shared across multiple applications. That’s where the trouble begins. Because—for 

a number of reasons—access to a master datum is not always available, people start storing master 

data in various locations, such as spreadsheets and application private stores. There are still reasons, such as 

data-quality degradation and decay, to manage master data that is not reused across the enterprise. However, if 

a master-data entity is reused in multiple systems, it’s a sure bet that it should be managed with a master-data 

management system. 

To summarize, while it is simple to enumerate the various master-data entity types, it is sometimes more challenging 

to decide which data items in a company should be treated as master data. Often, data that does not normally comply 

with the definition for master data may need to be managed as such, and data that does comply with the definition 

may not. Ultimately, when deciding on what entity types should be treated as master data, it is better to categorize 

them in terms of their behavior and attributes within the context of the business needs than to rely on simple lists of 

entity types. 

There are several reasons why master data management is crucial. The most important is the following one: 

Because master data is used by multiple applications, an error in master data can cause errors in all the applications 

that use it. For example, an incorrect address in the customer master might mean orders, bills, and marketing literature 

are all sent to the wrong address. 

Even if the master data has no errors, few organizations have just one set of master data. Many companies grow 

through mergers and acquisitions. Each company you acquire comes with its own customer master, item master, 

and so forth. This would not be bad if you could just Union the new master data with your current master data, 

but unless the company you acquire is in a completely different business in a faraway country, there’s a very good 

chance that some customers and products will appear in both sets of master data—usually, with different formats 

and different database keys. If both companies use the Social Security number as the customer identifier, discovering 

which customer records are for the same customer is a straightforward issue; but that seldom happens. In most cases, 

IS ADD


customer numbers and part numbers are assigned by the software that creates the master records, so the chances of 

the same customer or the same product having the same identifier in both databases is pretty remote. Item masters can 

be even harder to reconcile, if equivalent parts are purchased from different vendors with different vendor numbers. 

Merging master lists together can be very difficult. The same customer may have different names, customer 

numbers, addresses, and phone numbers in different databases. Normal database joins and searches will not be able 

to resolve these differences. A very sophisticated tool that understands nicknames, alternate spellings, and typing 

errors will be required. The tool will probably also have to recognize that different name variations can be resolved, if 

they all live at the same address or have the same phone number. While creating a clean master list can be a daunting 

challenge, there are many positive benefits to your bottom line from a common master list: 

• A single, consolidated bill saves money and improves customer satisfaction. 

• Sending the same marketing literature to a customer from multiple customer lists wastes money and irritates 

the customer. 

• Before you turn a customer account over to a collection agency, it would be good to know if they owe other 

parts of your company money or, more importantly, that they are another division’s biggest customer. 

• Stocking the same item under different part numbers is not only a waste of money and shelf space, but can 

potentially lead to artificial shortages. 

The recent movements toward SOA and SaaS make Master Data Management a critical issue. For example, if you 

create a single customer service that communicates through well-defined XML messages, you may think you have 

defined a single view of your customers. But if the same customer is stored in five databases with three different 

addresses and four different phone numbers, what will your customer service return? Similarly, if you decide to 

subscribe to a CRM service provided through SaaS, the service provider will need a list of customers for their 

database. Which one will you send them? 

For all these reasons, maintaining a high-quality, consistent set of master data for your organization is rapidly 

becoming a necessity. The systems and processes required to maintain this data are known as Master Data Management. 

Master Data Management (MDM) consists of the technology, tools, and processes required to create and maintain 

consistent and accurate lists of master data. 

There are a couple things worth noting in this definition. 

One is that MDM is not just a technological problem. In many cases, fundamental changes to business 

process will be required to maintain clean master data, and some of the most difficult MDM issues are 

more political than technical. 

The second thing to note is that MDM includes both creating and maintaining master data. Investing a 

lot of time, money, and effort in creating a clean, consistent set of master data is a wasted effort unless 

the solution includes tools and processes to keep the master data clean and consistent as it is updated and 

expanded. 

While MDM is most effective when applied to all the master data in an organization, in many cases the risk and 

expense of an enterprise-wide effort are difficult to justify. It may be easier to start with a few key sources of Master 

Data and expand the effort, once success has been demonstrated and lessons have been learned. If you do start small, 

you should include an analysis of all the master data that you might eventually want to include, so you do not make 

design decisions or tool choices that will force you to start over when you try to incorporate a new data source. 

An MDM project plan will be influenced by requirements, priorities, resource availability, time frame, and the 

size of the problem. Most MDM projects include at least these phases: 

1. Identify sources of master data. 

This step is usually a very revealing exercise. Some companies find they have dozens of databases containing 

customer data that the IT department did not know existed. 

IS ADD


2. Identify the producers and consumers of the master data. 

Which applications produce the master data identified in the first step, and—generally more difficult to determine—which 

applications use the master data. Depending on the approach you use for maintaining the master 

data, this step might not be necessary. For example, if all changes are detected and handled at the database 

level, it probably does not matter where the changes come from. 

3. Collect and analyze metadata about for your master data. 

For all the sources identified in step one, what are the entities and attributes of the data, and what do they mean? 

This should include attribute name, data type, allowed values, constraints, default values, dependencies, and 

who owns the definition and maintenance of the data. The owner is the most important and often the hardest to 

determine. If you have a repository loaded with all your metadata, this step is an easy one. If you have to start 

from database tables and source code, this could be a significant effort. 

4. Appoint data stewards. 

These should be the people with the knowledge of the current source data and the ability to determine how to 

transform the source into the master-data format. In general, stewards should be appointed from the owners of 

each master-data source, the architects responsible for the MDM systems, and representatives from the business 

users of the master data. 

5. Implement a data-governance program and data-governance council. 

This group must have the knowledge and authority to make decisions on how the master data is maintained, 

what it contains, how long it is kept, and how changes are authorized and audited. Hundreds of decisions must 

be made in the course of a master-data project, and if there is not a well-defined decision-making body and 

process, the project can fail, because the politics prevent effective decision making. 

6. Develop the master-data model. 

Decide what the master records look like: what attributes are included, what size and datatype they are, what 

values are allowed, and so forth. This step should also include the mapping between the master-data model 

and the current data sources. This is normally both the most important and most difficult step in the process. If 

you try to make everybody happy by including all the source attributes in the master entity, you often end up 

with master data that is too complex and cumbersome to be useful. For example, if you cannot decide whether 

weight should be in pounds or kilograms, one approach would be to include both (WeightLb and WeightKg). 

While this might make people happy, you are wasting megabytes of storage for numbers that can be calculated 

in microseconds, as well as running the risk of creating inconsistent data (WeightLb = 5 and WeightKg = 

5). While this is a pretty trivial example, a bigger issue would be maintaining multiple part numbers for the 

same part. As in any committee effort, there will be fights and deals resulting in sub-optimal decisions. It’s 

important to work out the decision process, priorities, and final decision maker in advance, to make sure things 

run smoothly. 

7. Choose a toolset. 

You will need to buy or build tools to create the master lists by cleaning, transforming, and merging the source 

data. You will also need an infrastructure to use and maintain the master list. 

The two main categories of tools are Customer Data Integration (CDI) tools for creating the customer master 

and Product Information Management (PIM) tools for creating the product master. Some tools will do both, 

but generally they are better at one or the other. 

The toolset should also have support for finding and fixing data-quality issues and maintaining versions and 

hierarchies. Versioning is a critical feature, because understanding the history of a master-data record is vital 

to maintaining its quality and accuracy over time. 

8. Design the infrastructure. 

IS ADD


Once you have clean, consistent master data, you will need to expose it to your applications and provide 

processes to manage and maintain it. When this infrastructure is implemented, you will have a number of 

applications that will depend on it being available, so reliability and scalability are important considerations to 

include in your design. In most cases, you will have to implement significant parts of the infrastructure yourself, 

because it will be designed to fit into your current infrastructure, platforms, and applications. 

9. Generate and test the master data. 

This step is where you use the tools you have developed or purchased to merge your source data into your 

master-data list. This is often an iterative process requiring tinkering with rules and settings to get the matching 

right. This process also requires a lot of manual inspection to ensure that the results are correct and meet 

the requirements established for the project. No tool will get the matching done correctly 100 percent of the 

time, so you will have to weigh the consequences of false matches versus missed matches to determine how 

to configure the matching tools. False matches can lead to customer dissatisfaction, if bills are inaccurate or 

the wrong person is arrested. Too many missed matches make the master data less useful, because you are not 

getting the benefits you invested in MDM to get. 

10. Modify the producing and consuming systems. 

Depending on how your MDM implementation is designed, you might have to change the systems that produce, 

maintain, or consume master data to work with the new source of master data. If the master data is used in a 

system separate from the source systems—a data warehouse, for example - the source systems might not have 

to change. If the source systems are going to use the master data, however, there will likely be changes required. 

Either the source systems will have to access the new master data or the master data will have to be synchronized 

with the source systems, so that the source systems have a copy of the cleaned-up master data to use. If it’s not 

possible to change one or more of the source systems, either that source system might not be able to use the 

master data or the master data will have to be integrated with the source system’s database through external 

processes, such as triggers and SQL commands. 

The source systems generating new records should be changed to look up existing master record sets before 

creating new records or updating existing master records. This ensures that the quality of data being generated 

upstream is good, so that the MDM can function more efficiently and the application itself manages data quality. 

MDM should be leveraged not only as a system of record, but also as an application that promotes cleaner and 

more efficient handling of data across all applications in the enterprise. As part of MDM strategy, all three 

pillars of data management need to be looked into: data origination, data management, and data consumption. 

It is not possible to have a robust enterprise-level MDM strategy if any one of these aspects is ignored. 

11. Implement the maintenance processes. 

As we stated earlier, any MDM implementation must incorporate tools, processes, and people to maintain the 

quality of the data. All data must have a data steward who is responsible for ensuring the quality of the master 

data. The data steward is normally a business person who has knowledge of the data, can recognize incorrect 

data, and has the knowledge and authority to correct the issues. The MDM infrastructure should include tools 

that help the data steward recognize issues and simplify corrections. A good data-stewardship tool should point 

out questionable matches that were made—customers with different names and customer numbers that live at 

the same address, for example. The steward might also want to review items that were added as new, because 

the match criteria were close but below the threshold. It is important for the data steward to see the history 

of changes made to the data by the MDM systems, to isolate the source of errors and undo incorrect changes. 

Maintenance also includes the processes to pull changes and additions into the MDM system, and to distribute 

the cleansed data to the required places. 

There are two basic steps to creating master data: (1) clean and standardize the data, and (2) match data from all the 

sources to consolidate duplicates. 

Before you can start cleaning and normalizing your data, you must understand the data model for the master data. 

As part of the modeling process, the contents of each attribute were defined, and a mapping was defined from each 

IS ADD


source system to the master-data model. This information is used to define the transformations necessary to clean 

your source data. 

Cleaning the data and transforming it into the master data model is very similar to the Extract, Transform, and 

Load (ETL) processes used to populate a data warehouse. Here are some typical data-cleansing functions: 

• Normalize data formats. 

Make all the phone numbers look the same, transform addresses (and so on) to a common format. 

• Replace missing values. 

Insert defaults, look up ZIP codes from the address, look up the standardised number. 

• Standardize values. 

Convert all measurements to metric, convert prices to a common currency, change part numbers to an industry 

standard. 

• Map attributes. 

Parse the first name and last name out of a contact-name field, move Part# and partno to the PartNumber field. 

Matching master-data records to eliminate duplicates is both the hardest and most important step in creating 

master data. False matches can actually lose data and missed matches reduce the value of maintaining a common 

list. Some matches are pretty trivial to do. If you have Social Security numbers for all your customers, or if all 

your products use a common numbering scheme, a database JOIN will find most of the matches. This hardly ever 

happens in the real world, however, so matching algorithms are normally very complex and sophisticated. The more 

attribute matches and the closer the match, the higher degree of confidence the MDM system has in the match. 

This confidence factor is computed for each match, and if it surpasses a threshold, the records match. The threshold 

is normally adjusted depending on the consequences of a false match. For example, you might specify that if the 

confidence level is over 95 percent, the records are merged automatically, and if the confidence is between 80 percent 

and 95 percent, a data steward should approve the match before they are merged. 

Another factor to consider when merging your source data into the master list is privacy. When customers become 

part of the customer master, their information might be visible to any of the applications that have access to the customer 

master. If the customer data was obtained under a privacy policy that limited its use to a particular application, 

you might not be able to merge it into the customer master. 

There are many different tools and techniques for managing and using master data. We will cover three of the 

more common scenarios here: 

• Single copy approach: 

In this approach, there is only one master copy of the master data. All additions and changes are made directly 

to the master data. All applications that use master data are rewritten to use the new data instead of their current 

data. This approach guarantees consistency of the master data, but in most cases it’s not practical. Modifying all 

your applications to use a new data source with a different schema and different data is, at least, very expensive; 

if some of your applications are purchased, it might even be impossible. 

• Multiple copies, single maintenance: 

In this approach, master data is added or changed in the single master copy of the data, but changes are sent out 

to the source systems in which copies are stored locally. Each application can update the parts of the data that 

are not part of the master data, but they cannot change or add master data. For example, the inventory system 

might be able to change quantities and locations of parts, but new parts cannot be added, and the attributes that 

are included in the product master cannot be changed. This reduces the number of application changes that will 

be required, but the applications will minimally have to disable functions that add or update master data. Users 

will have to learn new applications to add or modify master data, and some of the things they normally do will 

not work anymore. 

IS ADD


• Continuous merge: 

In this approach, applications are allowed to change their copy of the master data. Changes made to the source 

data are sent to the master, where they are merged into the master list. The changes to the master are then sent to 

the source systems and applied to the local copies. This approach requires few changes to the source systems; 

if necessary, the change propagation can be handled in the database, so no application code is changed. On the 

surface, this seems like the ideal solution. Application changes are minimized, and no retraining is required. 

Everybody keeps doing what they are doing, but with higher-quality, more complete data. This approach does 

have several issues: 

• Update conflicts are possible and difficult to reconcile. What happens if two of the source systems change 

a customer’s address to different values? There’s no way for the MDM system to decide which one to 

keep, so intervention by the data steward is required; in the meantime, the customer has two different 

addresses. This must be addressed by creating data-governance rules and standard operating procedures, 

to ensure that update conflicts are reduced or eliminated. 

• Additions must be remerged. When a customer is added, there is a chance that another system has already 

added the customer. To deal with this situation, all data additions must go through the matching process 

again to prevent new duplicates in the master. 

• Maintaining consistent values is more difficult. If the weight of a product is converted from pounds to 

kilograms and then back to pounds, rounding can change the original weight. This can be disconcerting 

to a user who enters a value and then sees it change a few seconds later. 

Data stewardship and compliance requirements will often include a way to determine who made each change and 

when it was made. To support these requirements, an MDM system should include a facility for auditing changes 

to the master data. In addition to keeping an audit log, the MDM system should include a simple way to find the 

particular change you are looking for. An MDM system can audit thousands of changes a day, so search and reporting 

facilities for the audit log are important. 

In addition to the master data itself, the MDM system must maintain data hierarchies. It’s important for the MDM 

system to capture these hierarchies, but it’s also useful for an MDM system to be able to modify the hierarchies 

independently of the underlying systems. If the MDM system manages hierarchies, a change to the hierarchy in 

a single place can propagate the change to all the underlying systems. There might also be reasons to maintain 

hierarchies in the MDM system that do not exist in the source systems. Planning and forecasting might also require 

temporary hierarchies to calculate “what if” numbers for proposed organizational changes. Historical hierarchies are 

also required in many cases to roll up financial information into structures that existed in the past, but not in the 

current structure. For these reasons, a powerful, flexible hierarchy-management feature is an important part of an 

MDM system. 

5.6.3 Dockets and Metadata 

Dockets as Overlay Infoldable Add-On-Data. 

Dockets[SS99] of data massives are specific overlay structures. They provide information 

• on the content (abstracts or summaries), 

• on the delivery instruction, 

• on the parameters of functions for opening the document (opening with(out) zooming, breath, size, activation 

modus for multimedia components etc.) 

• on the tight association to other documents (versions, releases etc.), 

• on the meta-information such as resources, restriction, copyright, roles, distribution policy etc. 

IS ADD


presentation engine 

container engine 

media object engine 

view handler 

DBS 

DBMS 

XML scene onion 

container onion 

media object onion 

XML suite 

... 

virtual ∨ materialized views 

update views 

survey, landmark, indexing, I/O, 

navigation, integration etc. functions 

services packages, wrapping functions, 

dialogue scene and scenario functions 

actor profiles, profile adaptation, equipment adaptation, 

channel adaptation, decomposer, style extension 

Abbildung 10: The Onion Approach to Stepwise Generation of XML-Based Sites 

• on the content providers, content reviewers and review evaluators with quality control policies, 

• on applicable workflows and the current status of completion, and 

• on the receipt of the document which enable in tracing the document life cycle. 

The overlay structuring of data sets is supported by the onion approach [TD01]. Onion generation is based on 

layering that used for generation of website functionality and content. On the outer layer, the presentation facilities 

may be introduced. Typical functions are style and context functions. Containers are used to ship the information 

and the functionality provided by the web engine. Their functionality is described in [FST98]. Containers contain 

information units which in general are views enriched by functions for operating on the views. Views may be provide 

information to the dialogue or may be used for updating the database. Further, views may be materialized. If they are 

materialized then the view handler provides an automatic refreshment support. Thus, we can use the onion system 

architecture displayed in Figure 10. 

The onion approach nicely fits with the translational approach. It is our aim to generate consistent sets of associated 

XML documents. Let X be the set of all XML documents under consideration. Further given a generation 

algorithm G applicable to XML documents that allows to generate new XML documents on the basis of the given 

ones. Let us denote by [X ] G the transitive closure of the generation algorithm applied to X . A set X of XML documents 

is called consistent according to G if all inner references in X belong to [X ] G , i.e., no dangling inner references 

are in the set X . In this case X is called XML suite. 

The general translation algorithm applied here is based on the conceptual specification of websites. We first develop 

the database specification. Using the database specification HERM views are specified using the algebra provided 

by HERM. These HERM views are the basis for media object and media types. Containers are obtained by adding 

further functionality for adaptation and unloading functions. Scene object are specialisations of containers by adaptation 

the container to the user (profile), the environment and the history. 

Data sets should be supported by a specific data warehouse architecture: 

Play-out servers present, store and protect released content. The play-out of documents depends on their usage. 

Typical widely used documents are documents used in logistics: 

• Bills have their own numbering and their own format. They serve also as an contract of carriage between 

shipper and carrier. 

IS ADD


• Certificate on the content and the origin of the contents are used for statistical research, and for accessing 

duties, particularly under trade agreements. 

• Invoices declare against which payment is made. They are used for clearing documents. 

• Dock receipts are issued by the forwarder on experter’s behalf. They include shipment description, physical 

details, and shipping information. 

• Bills of lading are used as contracts between carrier and shipper, spell out legal responsibilities and liability 

limits for all parties to the shipment. 

• Packing lists provide details on the packing procedure of the container. 

• Sight, time drafts instruct the buyer’s bank to collect payment. 

Production servers have controlled access to documents and host dockets. 

Specific docket servers manage trusted content exchange between the servers. 

Generic docket servers communicate and encapsulate value-adding services. 

Metadata for Characterisation of Data Sets. 

All datasets must have appropriate metadata compiled for them. At the simplest level metadata are “data about 

data”. Metadata provide a summary of the characteristics of a dataset. A good metadata record enables the user of a 

dataset or other information resource to understand the content of what they are reviewing, its potential value and its 

limitations. There are many metadata standards, but the ones that are most appropriate to GI are: 

• ISO 19115:200314 (Geographic Information – Metadata); and 

• UK GEMINI – (Geo-spatial Metadata Interoperability Initiative) The profile is the result of a collaboration 

between the AGI15 and the e-Government Unit16. A profile is a subset of one or several information standards 

that adopts elements, structures or rules for different user communities. Adherence to the UK GEMINI profile, 

which will replace the gigateway Discovery Metadata Specifications (the NGDF Standard) as the UK’s national 

geospatial metadata profile, allows for the creation of discovery metadata with both ISO 19115 (Geographic 

Information – Metadata) and the national e-Government Metadata Standard (eGMS), ensuring compliance with 

both. 

Comprehensive advice on the compilation of metadata can be found in the IGGI booklet entitled “The Principles of 

Good Metadata Management17”, the second edition of which was published in May 2004. 

The Meta-Characterization is used to represent properties of the data itself. Classically, data are considered of 

high quality. However, estimations on real data show that data quality is rather low 9,10 . 

The Quality Metadata can be used for characterization of the quality of data. Intrinsic data quality parameters applied 

to data are accuracy (consistency, measures), objectivity (consistency, author, update policy, evolution), 

believability (source, design, processes) and reputation (credibility). Contextual data quality is based on properties 

such as relevancy, value-added, timelineness (age, source currency, non-volatility), completeness, and 

amount of information. We can distinguish representational quality parameters such as interpretability (design, 

models and languages, query processing, data and processes), ease of understanding (interpretability, aliases), 

concise representation, consistent representation, and ease of manipulation. 

9 Companies engaged in cleaning databases estimate that, for instance, about 15 % of the objects stored in the telephone directory of the 

German Telekom have wrong data. 

10 DATRAS GmbH detected and corrected structural, semantic and content errors in the phone directories which have been scanned and 

sold by other companies with the advertisement that Chinese students have typed those. After discovery of the systematic nature of errors they 

could show that systematic errors are typical scanner errors. The non-systematic errors in those directories are errors which also appeared in 

the Telecom directory. 

IS ADD


The Temporality Metadata allows to maintain temporality of data. We are often interested in historical information. 

According to [Sno00] we distinguish three orthogonal concepts of time: temporal data types such as instants, 

intervals or periods, kinds of time, and temporal statements such as current (now), sequenced (at each instant 

of time) and nonsequenced (ignoring time). 

The Source Metadata 

and reliability. 

allows to maintain information on the acquisition of data. Sources can be different quality 

Terms and Regulations Metadata are used in various ways. There is usually a large variety of laws to be considered. 

There are laws and regulations for payment, for contacting, for requesting a party, for responding to another 

party etc. The simplest way to represent such pattern is to model the association explicitly in the schema by 

introducing types such as TermType and association types such as OrderTerm. 

Typical specific regulations are adjustments. We can model such regulations and rules by introducing types 

such as AdjustmentType and association types to the types which need an adjustment, e.g. Adjustment. This 

specific modeling approach is based on the consideration of star meta-structures 11 . 

Log Metadata are used for recording the actions of people in business process. A typical log schema is displayed 

in Figure 11. People are involved in activities in various roles, e.g., many people are involved in taking orders while 

giving the order, processing the order, approving the order, or fulfilling the order. All these actions need to be recorded. 

This log recording can be based on four or more relationship types associating orders with the person involved in the 

specific activity. We prefer, however, to model the activity by the role type. Thus, the schema is simpler and easier to 

maintain. 

A person may act in the same role several times. Thus, the relationship type uses the attribute FromDate for 

additional identification of the activity of the person. The key of OrderRole is thus Person.Identif, Order.Identif, 

OrderRoleType.Code and FromDate. 

Person 

[OtherProperties] 

FromDate [ThruDate] 

✛ Activity ✲ 

Role 

Role 

Type 

Identif 

Identif 

❄ 

Log 

Type 

Code 

Description 

Person 

[PercentContribution] 

[ThruDate] 

FromDate 

✛ 

Order 

Role 

✲ 

Order 

Role 

Type 

Identif 

Date 

Identif 

❄ 

Order 

Code Description 

[EntryDate] 

[ShippingInstructions] 

Abbildung 11: Log of Actions, e.g., Association of Person to Ordering 

11 We prefer the introduction of separate types for terms, laws, regulations and rules due to the simplification of the treatment and management 

especially constraint enforcement. It is often proposed to extend corresponding types by such additional characteristics. The classical 

normalization approach would lead to the same result since in the last step all dependencies with the same left side are grouped into one cluster. 

Instead of that for groups of dependencies with the same left side, we prefer [Tha00] the ‘star’ clustering into associated right types by using an 

adhesion and cohesion weight. Thus, we create sub-groups within a group of dependencies and form relation types based on those sub-groups 

thus forming a star type. 

IS ADD


5.6.4 Search and Systematic Querying 


From Traditional Querying Towards Linguistic Querying 

Based on [DT04] we distinguish two approaches to DBMS querying as shown in Figure ??. The first approach is 

typically provided by DBMS. The second approach is proposed in this paper. 

Traditional database querying is based on sending a query sequence to the DBMS query interface. The query is 

processed by the DBMS and an SQL answer set is generated and provided to the DBMS answer representation 

system. 

input : (DBMS query form , database schema) ↦→ SQL query 

process : SQL query ↦→ SQL answer set 

output : SQL answer set ↦→ DBMS answer representation 

Some DBMS do not provide a query interface. In this case, users must directly send their SQL expression to 

the DBMS. Small DBMS do not have an output function either. 

Linguistic search facilities extend the traditional approach by providing concepts instead of concentrating on SQL 

querying. The concepts are mapped into query forms or answer forms. They provide a general form to which 

any database schema may be applied. The generation of query forms on the basis of concepts has been tested in 

a prototypical implementation in [VT02]. The generation of answer forms uses a similar generation approach. 

The query form is compiled to an SQL query [TK01]. The output function uses the representation form 

provided by the answer form and instantiates the form by the SQL query answer set. 

map : search concept ↦→ query form 

compile : (query form , database schema) ↦→ SQL query 

map : result concept ↦→ answer form 

process : SQL query ↦→ SQL answer set 

output : (SQL answer set , answer form) ↦→ answer to search 

The concept of the output function using an answer form is not novel. It is widely applied in web scripting. 

Perl templates are typical examples of such scripting language expressions. Handles are an early concept 

supporting a stepwise generation (allocation of environment variables, instantiation of database variables, instantiation 

of database connection, instantiation of database requests, processing of database requests, binding 

of result sets, release of variables and disconnection). 

Seven Different Kinds of Search 

Search is one of the most common facilities in information-intensive systems. It requires 

• to examine the data and information on hand and 

• to carefully look at or through or into the data and the information. 

There is a large variety of information search such as: 

1. querying data sets (by providing query expressions in the informed search approach), 

2. seeking for information on data (by browsing, understanding and compiling), 

3. questing data formally (by providing appropriate search terms during step-wise refinement), 

IS ADD


4. ferreting out necessary data (by discovering the information requested by searching out or browsing through 

the data), 

5. searching by associations and drilling down (by appropriate refinement of the search terms), 

6. casting about and digging into the data (with a transformation of the query and the data to a common form), 


7. zapping through data sets (by jumping through provided data, e.g., by partially uninformed search). 

This variety of search approaches is applied almost everywhere in daily life. Information systems must support all 

these different kinds of search. The first and the second kinds of search (direct querying) are supported by text 

retrieval systems and do seldom lead to satisfactory results. The database query language SQL provides a nice support 

for skilled and trained users in case that the meaning of data and the semantics of the database schema are entirely 

known. 

The third kind of search (questing) is supportable by systems which use the information provided by the database 

schema and by word analysis. In [TK01, VT02] an approach has been developed which generates an SQL query for 

natural language utterances by extending the results of sentence parsing and analysis 

• by the meaning and associations of words using WordNet [Fel90] information, 

• by the hierarchy of application terms or topics [Ont12] ordered in an ontology [Gua97, OS04, WM02], and 

• by associating the terms to database schema information [Tha00]. 

The fourth kind of search (ferreting out) is currently not supported at all. It may be, however, partially supported 

if the information and associations on hand are properly used. In this case, context of terms, special context provided 

by applications and the search profile of the user can be used for generating a general context of the search utterance. 

The fifth kind of search (association-based search or browsing) can partially be supported by techniques of artificial 

intelligence, VisualSQL[Vis12, JT03, Tha03], and by careful analysis of the meta-information provided by the 

information system. 

The sixth kind of search (investigating and casting) requires a powerful transformer of search terms, of metainformation 

provided by the database schema and of general context. The support of this kind of search is not yet 

visible for information systems. The support of the last kind of search (zapping) is far more difficult. 

Therefore, search is property-based which requires verbalisation help for fuzzy or precise matching, associationoriented 

with dwelling into data context, cube exploration with the cube operations (dice, slice, drill-down, roll-up), 

metadata- or context-backed, or embedded into the story context. Search is thus ruled by content, context, user and 

his/her intentions, its embedding into a story and by support facilities and functions such as: guidance, surveillance, 

hyperspace exploration, landscaping, browsing, zapping, memoriser, digging and hunting. 

Towards NoSQL Questioning Within the W 7 (+W 4 +W 17 H) Question Frame 

Questioning can be based on the classical rhetorical frame introduced by Hermagoras of Temnos 12 (Quis, quid, 

quando, ubi, cur, quem ad modum, quibus adminiculis (W 7 : Who, what, when, where, why, in what way, by what 

means)). We extend this frame now. The primary context of a question is characterised by W 4 : wherefore (purpose), 

whereof (origin), wherewith (carrier, e.g., language), and worthiness ((surplus) value). The secondary context characterisation 

W 17 H is given by characterising user or stakeholder (by whom, to whom, whichever), the application 

domain (wherein, where, for what, wherefrom, whence, what), the solution somebody is seeking (how, why, whereto, 

when, for which reason) and the additional context (whereat, whereabout, whither, when). 

12 The work of Hermagoras of Temnos is almost lost. He has had a great influence on orality due to his proposals. For instance, Cicero 

has intensively discussed his proposals and made them thus available. The Zachman framework is nothing but a partial reinvention of this 

framework. 

IS ADD


Navigation Support 

At the same time information systems respond to search requests by informing the requester on the information on 

hand and answering the search request. Informing and answering is a task which is as difficult as searching. Informing 

has also a number of facets such as: 

• returning the data that matches to search terms to the user in some format, 

• replying by giving an answer to the request with inclusion of other helpful information 

• respond by reacting on the search request and providing some information, and 

• retort by answering back quickly and cleverly. 

Generic Functionality: Search 

Input Information 

(1: Dockets) 

(2: Media Object Suite) 

Kind of Search Functions:Traverse 

Context Enrichment 

(1: Portfolio) 

(2: Profile) 

(3: Environment) 

(4: Policy) 

Shuffling into Storyboard 

Traverse Object: Storyboard Spanning Tree 

Navigation is mainly based on traversal. Let us consider as an example the various facets of traversals. 

Traverse uni-directional associations: n-ary associations which (n-1) components uniquely determine the other 

component can be used for traversal. 

Traverse qualified association: The association is traversed in dependence of the qualification and returns the object(s) 

that correspond to the qualifier value. 

Traverse generalizations/specializations: The generalization/specialization hierarchy is used for capturing information 

that has been factored out during modeling. 

Upwards traversal: The specialization hierarchy is traversed from the subclass to the superclass. 

Downwards traversal The specialization hierarchy is used for traversal down a generalization/specialization 

hierarchy from the superclass to the subclass if the corresponding objects exist for the subtypes. 

Obtain the XML object: The specialization hierarchy is used for generating the object with all its tightly 

coupled elements. 

Traverse from link to object: All objects related to the link and the corresponding role are captured. 

Traverse from object to link: The links of the object are collected and prepared for traversal. 

Link collection: The links of the specified object(s) are collected. The association names are necessary whenever 

an ambiguity may occur. 

Traversal by roles: The search is carried out based on the link(s) which are denoted for the role of the object(s). 

Filter objects: The objects in a set are restricted by a Boolean expression. 

IS ADD


Filter links: The links in a set are restricted using a Boolean expression. 

Traverse from object to value: The operation returns the attribute value(s) for the specified set of objects. 

Traverse from link to value: The operation returns the attribute value(s) for the specified set of links. 

The search pattern can be combined, e.g., traverse from object set to attribute values reachable through links. 

5.6.5 Query and Answer Forms 


The W 7 (+W 4 +W 17 H) question frame drives the path to general question support. We might first concentrate on 

the main ingredients of a question and delay the treatment of the other ingredients to future research. Questions to a 

system are given by the nested quadruple 

(question content, matter (concepts, situation), user(profile, portfolio), carrier). 

Answers to be expected from a system are given by the nested triple 

(answer content, solution (characteristics, context, value)). 

A question has a matter (what, concepts, in what way) and a situational context (when, where, in what means). 

A user has a profile (who) and a portfolio (wherefore, wherein, where, for what, wherefrom, whence, what). He/she 

uses a carrier language (wherewith) within a certain namespace (whereto, by what means). The answer expected can 

be characterised by the solution characteristics (how, why, whereto, when, for which reason), the solution context 

embedding (whereat, whereabout, whither, when) and the expected surplus value (worthiness) of the answer. 

The structuring of queries and answers can be defined through folding [MST09] of superimposed schemata 

[BDM02] where each schema represents a specific facet of the query or answer. We can use the representation 

through m-object schemata [NuBT11]. In the sequel we do not go into the details of this folding. We concentrate on 

the notions of query forms and answer forms. We observe, however, that queries and answers have multi-structured 

schemata and can be represented within the extended ER modelling language [Tha00]. 

Query Forms as Query Pattern 

Query formulation in database systems is based on a known relational database schema. The query interface of a 

DBMS supports the syntactical correctness of an SQL-92 query. Syntactical completeness is usually not supported. 

Users often make claims on the DBMS non-suitability for query construction. Query formulation is thus error-prone 

and does not provide any help against the flaws. In [TK01] another approach has been proposed: users can formulate 

queries in natural language and the system translates the natural language utterance to candidates of queries. This 

approach has been used for query interfaces of web sites. 

This approach can be combined with the approach considered in [VT02]. Instead of using natural language utterances 

concepts are defined. These concepts are associated with query forms [Tha00]. A query form is a parametric 

view expression expr(T 1 , ..., T n , x 1 , ...x m ) defined over an Visual SQL schema similar to those defined for extended 

entity-relationship schemata: 

• The language of the extended entity-relationship model is defined by 

· 

ER → B | L : ER | (ER, ..., ER) | {ER} | ∪ (ER, ..., ER) 

for a set L of labels or names, a set B of base type names and the constructors (..., ..., ...) (product or tuple), 

{...} (set), and ∪ · 

(..., ..., ...) (disjoint union). Additionally, constructors for bags and lists may be used. The set 

of labels may also contain the empty label λ. The set of labels is used for distinction of components. 

• The view expression uses parameters x 1 , ..., x m and database types T 1 , ..., T n . The schema consisting of 

T 1 , ...., T n x 1 , ...., x m is closed, i.e. if a type T ∈ {T 1 , ..., T n } has components then these components belong 

to {T 1 , ...., T n x 1 , ...., x m }. 

An answer form is a parametrised media type [ST01] associating the output parameters of the query form with the 

parameters of the answer form. Answer forms often use patterns for the structuring of the question solution such as 

list pattern, table pattern, view schema pattern, cube pattern or reporting form pattern. 

IS ADD


We picture the differences in the approach in Figure 12. The query is assembled on the basis of the Visual SQL 

schema. 

Visual SQL 

schema 

✻ 

❄ 

query 

form 

✲ 

SQL 

query 

✛ 

SQL database 

schema 

✻ 

❄ 

DBMS query 

interface 

answer 

form 

❄ 

SQL answer 

set 

❄ 

answer 

to search 

✮ 

 

DBMS answer 

representation 

Abbildung 12: Visual SQL Query Processing Instead Of Direct SQL Querying 

Query forms Q and answer forms A can be represented by labelled directed graphs G Q and G A similar to semantic 

networks. Nodes are concepts used in the question. Edges are associations in the question. Verbs are typically mapped 

to associations. One might better represent multi-valent verbs by hypernodes and hyperedges. These can however also 

be represented by an extended graph. Parameters in a query form are defined as hooks or anchors. 

Associating Questions With Concepts 

Questions use notions from the application domain. Therefore, we may associate items in the question with concepts. 

This association can be based on the separation of concern into content, concepts and topics [Tha06]. Concepts are 

kernel elements in the application knowledge. They can thus be used to better understand the meaning of a question. 

The topic theory is based on Kauppi’s concept maps [Kau67]. 

Using The ER Translation Profile For Generation Of SQL Queries 

Classically, queries are formulated on the basis of the relational schema. In this case, the relational schema is the 

main source for query formulation. This approach is appropriate as long as the query is not very complex and as long 

as the number of relational types to be used in the query is rather small. If the relational schema is large and the query 

is rather complex, users are lost in the schema space and query formulation becomes error-prone. 

We use the six-step procedure for query formulation and use the translation profile of the ER schema for derivation 

of the query. The translation profile corresponds to the stepwise translation procedure for extended ER schemata 

proposed and discussed in detail in [Tha00]. 

5.6.6 Separating Data Storage from Data Utilisation 

This part of the lecture is based on the paper [JRTF11]. 

Generic Database Schemata for Simple and Sophisticated Storage. 

The Data Deployment Engine. 

Data Warehouses, Data Marts and Data Mining Machines as Specific Approaches. 

IS ADD


5.6.7 View Towers and Eager Collectors 

This part of the lecture is based on the paper [KT12]. 

5.6.8 Geschichtete Datenbanksysteme für Anwendungsfälle 

In Projekten fallen neben feingranularen Sensordaten auch Auswertungsdaten, Georeferenzierungsdaten, Fremddaten, 

aggregierte Daten und ergänzte Daten an. Die Daten sind nicht nur von unterschiedlicher Qualität und von 

unterschiedlichem Umfang. 

Eine entsprechende Technologie wurde für die integrierte Bereitstellung von Datenbeständen, für das Verweben 

von Datenbeständen mit zugehörigen Auswertungsdatenbeständen und für die Besonderheiten innerhalb dieser Datenbestände 

durch eine Technologie der Sichten entwickelt. Im Exzellenzcluster kann diese Technologie benutzt werden, 

um Daten je nach Benutzungsfall (z.B. Bereitstellung von Daten für eine Publikation oder in Datenbestände)je 

nach erforderlicher Detailiertheit, je nach Auswertungsart etc. vorzuhalten. 

Gleichzeitig kann durch eine Vereinheitlichung der Abspeicherung auch eine einfache Schnittstelle für die Anwendung 

von Analyseverfahren, von Algorithmen des Data mining und von statistischen Verfahren bereitgestellt 

werden. 

5.6.9 Austausch von Datenbeständen auf XML-Basis 

Daten sollten vor allem von vielen Arbeitsgruppen auf der Grundlage von abgestimmten Kollaborationen benutzt 

werden. Sie haben außerdem eine relativ lange “Lebenszeit”, so daß sie auch relativ lange in entsprechenden Archiven 

vorgehalten werden müssen. Sie sind weiterhin kontext-sensitiv und bedürfen einer Ergänzung durch entsprechende 

Metadaten. Sie erfordern deshalb einer komplexen Mehrschrittauswertung. 

Deshalb ist eine Entwicklung eines skalierbaren, flexiblen und hinreichend universellen Austauschformates auch 

für Projekte notwendig. Ein solches Austauschformat kann auf existierenden XML-Standards aufgesetzt werden. 

5.6.10 Werkzeuge für das Datenmanagement 

Generische Workflows zum Datenmanagement 

Die Datenerfassungs-, -ablage- und -auswertungsverfahren gleichen sich in den allgemeinen Abläufen und in der 

allgemeinen Sichtweise auf die Daten. Zugleich sind sie jedoch in Spezifika so unterschiedlich, daß derzeit jeder 

dieser Prozesse in einer eigenen Unterstützungsform läuft. Damit werden nicht nur Ressourcen gebunden, sondern 

auch Integrationsmöglichkeiten verschenkt. Bei einem Datenmanagement lohnt es sich jedoch, diese Abläufe zusammenzufassen, 

zu verallgemeinern und zu harmonisieren. Diese Bündelung gleichartiger Aktivitäten erlaubt auch eine 

effektivere Unterstützung. 

Am Lehrstuhl für Technologie der Informationssysteme wurde eine Theorie und Technologie generischer Workflows 

bzw. Arbeitsprozesse entwickelt und in Projekten erprobt. Generische Workflows fassen Workflows, die einen 

analogen Verlauf, analoge Mechanismen der Verarbeitung und Benutzung von Daten und analoge Benutzungsformen 

besitzen, zu einem verallgemeinerten Workflow zusammen. Dieser verallgemeinerte Workflow kann mit einer Compilertechnologie 

zu den ursprünglichen Workflows entfaltet werden. Zugleich kann damit ein allgemeiner Ablauf, zu 

dem potentiell sehr viele analoge Abläufe existieren, mit einem einzigen Programm unterstützt werden. Damit entfällt 

die Notwendigkeit, für jeden einzelnen Anwendungsfall ein neues Programm zu erstellen, zu testen, zu erproben und 

den Benutzern nahezubringen. 

Das Konzept der generischen Workflows. 

Generische Workflows sind konfigurierbare, adaptierbare und abstrakte Workflows, aus denen der aktuelle Workflow 

(entfalteter Workflow) abgeleitet werden kann. Dieser aktuelle Workflow berücksichtigt die aktuelle Situation, 

die aktuellen Anforderungen und die aktuelle Datenlage. 

IS ADD


✲ 

✯ 

✿ 

3 

❥ 

✲ 

✿ 

Abbildung 13: Generische und entfaltete Workflows 

In Abbildung 13 ist ein generischer Workflow dargestellt, aus dem ein aktueller Workflow abgeleitet werden 

kann. Dieser aktuelle Workflow verläuft im Rahmen des generischen Workflows und wird demzufolge auch mit allen 

Serviceleistungen des generischen Workflows ausgestattet. 

Ein generischer Workflow wird dabei aus generischen Funktionen schrittweise zu einem komplexen Workflow 

zusammengesetzt. Aus einem generischen Workflow wird mit Adaptoren spätestens zur Laufzeit ein spezifischer, 

aktueller, entfalteter Workflow abgeleitet. 

Mit diesem Konzept wird eine größere Flexibiltät erreicht. 

Generische Workflows, Workflows und Workflow-Felder. 

Wir unterscheiden in Anlehnung an die Theorie der Konzeptfelder (siehe unten im Abschnitt ??) zwischen 

generischen Workflows, aus denen (aktuelle) Workflows abgeleitet werden können 

einem Workflow als entfalteten Workflow innerhalb einer Anwendungssituation und 

Workflow-Feldern, mit denen ein Rahmen der generischen Workflows angegeben werden kann. 

Ein generischer Workflow kann aus einer oder mehreren Stammformen bestehen. 

Ein Workflow-Feld besteht aus 

einer Menge von Stammformen, 

einer Menge von dynamischen Integritätsbedingungen denen die Workflows eines Feldes genügen müssen, 

einer Menge von Bildungsformen zur Assoziation mit anderen Workflow-Feldern und 

einer Menge von Flexionen zur Ableitung von Workflows aus dem Workflow-Feld. 

Wir nehmen oft vereinfachend an, daß ein Workflow-Feld nur eine einzige Stammform besitzt. und daß ein generischer 

Workflow nur Workflows eines Workflow-Feldes enthält. Sie muß nicht alle möglichen Workflows dieses 

Feldes enthalten, sondern kann auch nur einige (aktuelle) Workflows enthalten. 

Diese Unterscheidung wurde in unseren Arbeiten erstmals für eine e-Learning-Websites konzipiert. Diese Site 

erlaubt eine Entfaltung einer Lerneinheit je nach Meta-Information, Handlungs-, Akteurs- und Datenkontexten sowie 

der Handlungsvorgeschichte. Damit kann ein Lernfeld als allgemeine Lerneinheit angesehen werden, bei der 

die Stammform als Ausdruck über Lernelementen gegeben ist, 

die durch Ableitungsregeln zu einem komplexen Lernmodul erweitert wird, so daß ein Lernender auch seine entsprechenden 

Lernelemente angeboten bekommt, und 

durch Flexion die Variantenvielfalt sowie die Ausnahmen auffaltbar sind. Flexionsregeln erlauben eine Erweiterung 

mit dem Akteursprofil und -portfolio, 

mit dem Wiederholungsprofil, 

mit dem Zeitprofil, 

mit dem deontischen Modus und 

IS ADD


mit den Aktionsformen und der Handlungsrichtung. 

Diese Erweiterung entspricht den Anforderungen in diesem Projekt. Katastrophensituationen besitzen Spezifika, 

die über übliche Software-Anwendungen hinausgehen. Sie sind gekennzeichnet durch 

• hochgradig parallele Arbeitsabläufe und damit Problemen der adäquaten Bewältigung der entstehenden Komplexität, 

• Arbeitsabläufe, die eine Rückkopplung mit Wartezeiten erfordern, und 

• eine Organisation, die oft fremdgesteuert ist. 

Wir verallgemeinern die Formenlehre von Handlungssträngen und führen dazu allgemeine Workflow-Felder ein: 

Das Eröffnungsfeld ist gekennzeichnet durch 

• die Darstellung des Kontextes, der bei Assoziation des Workflow-Feldes mit anderen Feldern den Kontext 

dieser Felder dominiert, 

• die Darstellung der Akteure, 

• die Darstellung der Situation und 

• die Assoziation mit Sichtentypen sowohl für die Input- als auch die Retrieval- als auch die Outputdaten. 

Das Ausgangsfeld dient zur Meta-Spezifikation und erlaubt außerdem noch eine Einbettung der räumlichen und 

zeitlichen Rahmenbedingungen sowie auch der Motivation und der Ursachen. 

Das Handlungsschrittfeld wird spezifiziert durch 

• die Angabe der Verbindungsparameter, 

• die Angabe der Begleitelemente und Kontextbedingungen, 

• der Rollen der Akteure und 

• Sichtentypen. 

Das Übergabefeld erlaubt den Übergang von Objekten einer Sicht eines Akteurs auf Objekte einer Sicht eines anderen 

Akteurs. Zusätzlich kann der Kontext und auch der Vertrag des Überganges spezifiziert werden. 

Das Arbeitsfeld erlaubt die Bearbeitung von Daten über den Sichtentypen und deren Versand an andere Akteure 

bzw. deren Einbringen in das System. 

Neben diesen Basisfeldern können wir auch Konstruktionsfelder spezifizieren, mit denen Felder kombiniert werden 

können: 

Das Verzweigungsfeld unterstützt eine Verzweigung von Workflows in synchronisierte Workflows, die parallel unter 

Einhaltung der Synchronisationsbedingungen ablaufen können. 

Das Wiederholungsfeld stellt den Rahmen für eine wiederholte Ausführung eines Workflows. 

Das Bulk-Feld ist an Parameter gebunden, für die das Workflow-Feld insgesamt abgearbeitet wird. 

Wir haben diese Theorie der Workflow-Felder mit den Kompositionsoperationen für Workflows harmonisiert, damit 

wird eine entsprechende Entfaltung der komplexen Workflow-Felder vornehmen können. 

Workflow-Felder erlauben oft eine einfache Darstellung durch entsprechende Ausdrücke. Können Workflow- 

Felder durch eine Stammform spezifiziert werden, d.h. durch einen generischen Workflow. 

Generische Workflows stellen ein Analogon zu generischen Operationen wie insert, delete und update dar, bei 

denen eine Instantiierung durch Angabe der Strukturen der Typen erfolgt, für deren Klassen sie angewandt werden. 

Ebenso wie generische Operationen können generische Workflows durch Instantiierung in konkrete Workflows 

überführt werden. Die Parameter können auch abhängig voneinander sein. Wir unterscheiden hierbei die folgenden 

speziellen Typen: 

IS ADD


Entfaltbare Workflows sind generische Workflows mit einem generischem Laufzeit-Workflow, bei denen die instantiierbaren 

Parameter keine Nebenbedingungen auf andere Parameter besitzen. Sie können zur Laufzeit voll 

entfaltet werden. Typische entfaltbare Workflows sind Workflows für Gruppenarbeitsplätze, die jedem Mitglied 

die gleiche Arbeitsplattform bieten. 

Parallelisierte Workflows sind generische Workflows, bei denen ein Zwischenstand und To-Do-Listen mitgeführt 

werden und zur Laufzeit mit entsprechenden Werten belegt werden können, die zu anderen Workflows Beziehungen 

besitzen z.B. durch Ressourcen-Sharing und gemeinsam mit diesen ausgeführt werden können. 

Multiple-choice Workflows sind generische Workflows, die Varianten für Rollen, für die freie Auswahl von Daten 

und die Bündelung mit anderen Workflows bereitstellen. 

Transaktions-basierte Meta-Workflows sind generische Workflows, deren Ausführungsmodell eine Ressourcen- und 

Rollenverwaltung einschließt, die auch über Rücknahme- oder Kompensationsteilfelder verfügen und deshalb 

einer Transaktionssemantik unterliegen. 

Ein entfalteter Workflow ist ein vollständig instantiierter Workflow. Alle Parameter eines entfaltbaren Workflow sind 

mit entsprechenden Werten belegt. In Bild 13 wird die Beziehung zwischen einem generischen Workflow und einem 

entfalteten Workflow dargestellt. Ein entfalteter Workflow ist demzufolge ein Durchlauf oder eine spezielle Instanz 

eines generischen Workflows. 

Kohärenz und innerer Zusammenhang in generischen Workflows. 

Workflow-Entwicklung ist anerkanntermaßen ein sehr komplexer Prozeß. Die Geschäftsprozesse sollen sowohl 

einer Vielfalt von Anforderungen der Anwendungen genügen als auch effizient mit den Ressourcen Zeit und Speicher 

umgehen. Die Komplexität der Anwendungen selbst bedingt oft eine sehr komplexe Software. Meist ist auch 

zum Entwicklungsbeginn nicht einmal klar, welche Aufgaben das Produkt lösen soll. Oft haben die Besteller nur 

ungefähre Vorstellungen über den Funktionsumfang. Hinzu kommt, daß sich sogar schon im Verlaufe der Entwicklung 

der Software die Anforderungen ändern. Da Workflows oft über einen längerem Zeitraum die Anwendungen 

unterstützen, erfähren sie dabei vielfältige Modifikationen und überdauern selbst auch Generationen von verschiedener 

Hardware und Grundsoftware. Damit entstehen oft Systeme, die in ihrer Komplexität und ihrer Verwobenheit den 

manieristischen Kathedralen nicht nachstehen. Ein extremes Beispiel eines solchen Systemes sind Anwendungen, 

die SAP R/3 als Grundsystem einsetzen. Dieses System ist in der Lage, fast alle Informations- bzw. Datenaufgaben 

der betrieblichen Praxis zu begleiten, ist aber mittlerweile so komplex, daß für den täglichen Betrieb des Systemes 

im Betrieb ein Team von Mitarbeitern notwendig ist und daß jede Modifikation der Anwendung, jede neue - auch 

einfache - Aufgabe eine Systemmodifikation mit umfangreicher und langandauernder externer Beratung erfordert. 

In der Workflow-Entwicklung werden Modelle als Mittler eingesetzt. Sie sollen zum einem Abbild der relevanten 

Aspekte der Anwendung sein und zum anderen als Vorbild für das zu entwickelnde System dienen. Es sollen deshalb 

alle Aufgaben der Anwendungen hinreichend gut im Modell darstellbar und diese Darstellung auch ausreichend exakt 

für die Entwicklung des Produktes Software sein. Das Modell soll auch dem Entwicklerteam der Software erlauben, 

das zu entwickelnde Produkt zu verstehen, seine Facetten in integrierter Form zu unterstützen und die Qualität des 

Produktes zu dokumentieren. Modelle sind deshalb ein zentraler Bestandteil der Softwareentwicklung. 

Die Workflows soll unterschiedlichste Aspekte einer Anwendung hinreichend gut berücksichtigen. Damit kann 

versucht werden, entweder mit einem Geschäftsprozeßmodell alle Aspekte der Anwendung zu beschreiben oder mit 

einer Menge aufeinander abgestimmter Modelle diese Aspekte zu erfassen. In den frühen Jahren der Informatik wurde 

der Ein-Workflow-Zugang versucht. Mit dem Scheitern dieses Zugangs wurde eine Multi-Modell-Beschreibung 

präferiert. 

Diese schwach zusammenhängenden Spezifikationen werden in Modell-Ensembles zusammengefaßt. Das Ensemble 

kann für jedes Modell eine Weiterentwicklung erfahren, wobei die Beherrschung der Auswirkungen der 

Modifikationen dem Entwickler zugemutet wird. Da Software-Entwicklungen oft im Team erfolgen, kann von den 

Entwicklern die Beherrschung der Zusammenhänge nicht abverlangt werden. Die Dissertationsschrift erweitert diesen 

Zugang hin zu einer abgestimmten Entwicklung von Modellen. Diese Abstimmung basiert auf einer Reihe von 

IS ADD


Integritätsbedingungen, denen ein Modell-Ensemble genügen sollte. Dies führt zum Begriff der am Lehrstuhl entwickelten 

Modell-Suite, bei der in analoger Form wie in der Architektur der Zusammenhang zwischen den Elementen 

explizit spezifiziert ist und deshalb dann auch in der Entwicklung unterstützt werden kann. 

Die unterschiedlichen Modelle reflektieren meist auch die unterschiedlichen Abstraktionsebenen, die während 

eines Entwicklungsprozesses auftreten. Einige Modelle dienen der Kommunikation mit dem Anwender, andere der 

Dokumentation der entstehenden Produkte. 

Ausgangspunkt für die im Projekt angewandten Forschungsergebnisse ist deshalb das Koharärenzproblem: 

• Es soll eine Charakterisierung von Kohärenz in einer Modell-Suite der Workflow- oder auch Informationssystem-Entwicklung 

gefunden werden, mit dem auch unterschiedliche Grade von Kohärenz je nach Entwicklungsstand 

abgebildet werden können. 

• Es werden Kriterien zur Bewertung von semantischer Kohärenz benötigt, die flexibel auch für unvollständige 

Modelle angewandt werden können. 

• Es werden Methoden benötigt, mit denen die Kohärenz innerhalb einer Modell-Suite hergestellt und gepflegt 

werden kann. 

• Die Methoden sollen in Werkzeugumgebungen der realen Workflow-Entwicklung integrierbar sein. 

Adaption generischer Workflows für konkrete Anwendungssituationen. 

Die entwickelte Theorie und Technologie generischer Workflows erlaubt eine Verwendung von regelbasierten 

Transformationsverfahren. Derartige Verfahren sind aus dem Term Rewriting der Computer-Analysis und Computer- 

Algebra bekannt. Es werden dazu mit entsprechenden Regeln die Workflows zu spezifischen Workflows verfeinert. 

Derartige Verfahren wurden bereits für die logistische Bereitstellung von Lerninhalten für e-Learning Websites erfolgreich 

eingesetzt. Es war damit möglich, für Inhalte eine Adaption an bereits erfolgreich absolvierte Lernschritte, 

an die Verfügbarkeit von Inhalten, an die Lernhistorie, an das Profil des Lernenden und an die Fehler des Lernenden, 

sowie eine Ergänzung um assoziierte Inhalte, Übungs- und Praktikumsaufgaben und Vorwissen vorzunehmen, damit 

je nach aktueller Lernsituation der am besten geeignete Lerninhalt zur Verfügung gestellt wird. 

Die Verfeinerung wird anhand der Eigenschaften von Anwendungssituationen ausgelöst. Damit wird z.B. der 

Anwendungskontext injiziert. 

Da eine einzelne Verfeinerung eine andere Verfeinerung ausschließen kann muß, die Koheränz von Regeln zur 

Verfeinerung geprüft werden. Eine allgemeine Lösung existiert nachgewiesenermaßen nicht. Wir können für das 

Projekt jedoch eine Ableitung von Testszenarien wie in Abschnitt 5.6.10 dargestellt nutzen. Damit kann zur Spezifikationszeit 

geprüft werden, ob Konflikte bei der Ausführung von Regeln vorliegen. Bestehen solche Konflikte, dann 

müssen die entsprechenden Workflow überprüft und verbessert werden. 

Generische Funktionen. 

Die Beschreibung der Funktionalität einer Anwendung wurde in den ersten Jahrzehnten der Entwicklung von 

Informationssystemen zurückgestellt, weil die bereitgestellten Mechanismen zur Ad-Hoc-Spezifikation von Anfragen 

für die meisten Anwendungen vollständig ausreichend war. Der Erfolg bei der Unterstützung von Anwendungen 

durch Informationssysteme führte sehr schnell dazu, daß auch Informationssysteme in Bereichen angewandt wurden, 

deren Funktionalität im Voraus schon weitgehend abgesteckt war. Damit wurde auch eine Spezifikation der Funktionalität 

im Voraus und im Zusammenhang mit der Spezifikation der Strukturierung erforderlich. Es entstanden einen 

Reihe von Sprachen wie z.B. EPK und Workflow-Sprachen, mit denen zumindest eine konzeptionelle Beschreibung 

der intendierten Funktionalität unterstützt wurde. Meist blieb es jedoch dabei. Eine Schichtung der Funktionalität 

nach Sichtweise der Benutzer, Sichtweise der Konzeptionalisierung und Sichtweise der Programmierung wie eine 

Drei-Ebenen-Architektur, bei der die Sichtweisen durch externe Sichten auf das konzeptionelle Schema und durch 

eine Verfeinerung der konzeptionellen Spezifikation hin zu einer programmtechnischen Umsetzung unterstützt werden, 

wurde nicht entwickelt. 

Moderne Informationssystem-Anwendungen sind mit Herausforderungen verbunden, die durch eine Entwicklung 

einer Theorie, Technik und Pragmatik generischer Funktionen bewältigt werden können: 

IS ADD


Drei-Ebenen-Spezifikation von Funktionalität: Die Funktionalität muß sowohl für einzelnen Sichtweisen der Anwendung 

als auch konzeptionelle sowie auch für die Implementation effektiv und integriert beschrieben werden. 

Abstrakte Beschreibung von Funktionalität von Geschäftsprozessen und Anwendungen: Funktionen müssen 

sowohl für den Anwender als auch den Entwickler die gleiche Semantik besitzen oder in einer Semantik- 

Mannigfaltigkeit verwendet werden, die eine gleichartige Verwendung unabhängig von der gewählten Abstraktion 

erlaubt. 

Abbildung von abstrakten Spezifikationen auf konzeptionelle und prozedurale: Um eine vollständige Unterstützung 

der unterschiedlichen Abstraktionsstufen zu unterstützen bedarf es eines Verfeinerungsbegriffes, der auch eine 

Verfeinerung der Funktionalität einer Gesamtanwendung in unterschiedlichen Fertigungsständen erlauben 

muß. Dieser Verfeinerungsbegriff muß durch explizite Abbildungsmechanismen unterstützt werden. 

Flexibilisierung der Spezifikation von Funktionalität: Funktionen können je nach Anwendung, je nach Benutzer, 

je nach Benutzungshistorie, je nach Systemumgebung unterschiedlich realisiert sein. Deshalb ist es sinnvoll 

auch die Spezifikation der Funktionalität in dieser Allgemeinheit und mit einer derartig hohen Flexibilisierung 

vorzunehmen. 

Entwicklung von Adaptionsmechanismen für Funktionalität: Last but not least, all diese Facetten, Sichtweisen, 

Abstraktionsstufen, Verfeinerungen und Adaptionen müssen auch automatisch unterstützt werden. Deshalb 

müssen auch entsprechende Adaptionsmechanismen ausgearbeitet werden und zumindest mit einem Prototypen 

implementiert werden. 

Das Konzept der generischen Funktionen wurde erstmalig 2006 13 auf der Entity-Relationship-Konferenz vorgestellt 

und diente der Dissertationsschrift von A. Bienemann 14 als zentrales Konzept. Die dabei entstandene Software 

kann als Erfahrungsvorlage für den Prototypen in diesem Projekt dienen. Es setzt auf dem Konzept des Government 

and binding von N. Chomsky 15 auf. N. Chomsky schlug mit diesem Zugang eine universelle Theorie natürlicher 

Sprachen vor. Sie fußt auf der Beobachtung beim multi-sprachlichen Sprechakt. Dieser findet in zwei Etappen statt. 

Eine universelle Grammatik kann nach Chomsky einem Zwei-Schritt-Verfahren folgen: In einem ersten Schritt 

werden für den Sprachakt notwendige Konzepte aus einer D-Struktur herausgefiltert. Dazu werden α-Regeln verwendet. 

Danach wird der Ausdruck mit β-Regeln zu S(entence)-Strukturen geformt. S-Strukturen hängen vom konkreten 

Ziel in einem Sprechakt sein und können sowohl auf schriftliche oder auch mündliche Formen orientieren. Die allgemeine 

Umformung ist in Abbildung 14 gegeben. 

Lexikon der Basiskonzepte ✲ D-Struktur 

❄ α Regeln 

Stil und phonetische Regeln 

✾ 

Phonetische Form 

S-Struktur 

β Regeln 

3 

Logische Form 

Abbildung 14: Das schrittweise Erzeugen eines Ausdrucks in der Government-and-Bindung-Theorie 

Dieses Konzept kann auch für die schrittweise Erzeugung von Funktionen in Systemen genutzt werden. Im ersten 

Schritt findet mit α-Regeln eine Umformung eines generischen Konzeptes in eine Funktionsklasse mit einem 

Transformer wie in Abbildung 15 statt. Dazu wird die verfügbare Information und eine Menge von Steuerregeln 

genutzt. 

Im zweiten Schritt werden β-Regeln angewandt, um aus der Lösungsklasse der Funktionen die spezifischen Funktionen 

zu entfalten. In Abbildung 16 wird darstellt, wie in einem zweiten Schritt anhand vorhandener Information mit 

13 Es wurde zuvor bei der Entwicklung von Web-Informationssystemen z.B. für die Entwicklung von Städteportalen erfolgreich eingesetzt. 

14 A. Bienemann. A generative approach to functionality of interactive information systems. PhD thesis, CAU Kiel, Dept. of Computer 

Science, 2007. 

15 N. Chomsky. Some concepts and consequences of the theory of government and binding. MIT Press, 1982. 

IS ADD


Generic function 


✲ 

Inject 

❄ 

Transformer @ 

Functionalisation 1 

✛Control 

rules 

compile(source lang,target lang) 

variable type := type expression 

apply restriction 

❄ 

Function class 

Abbildung 15: Die Umformung generischer Konzepte in spezifisch angepaßte Konzepte 

einer spezifischen Menge von Steuerungsregeln aus einer Funktionsklasse eine adäquate Funktion ausgewählt werden 

kann. 

Function class 


✲ 

Inject 

❄ 

Transformer @ 

Functionalisation2 

✛Control 

rules 

connection := database 

database := .... 

view consumed := .... 

view produced := ... 

view communicated := ... 

apply restriction 

❄ 

Specific function 

Abbildung 16: Die Umformung von spezifischen Funktionen zu spezifischen Funktionen 

Generische Funktionen sind Funktionen F = (Dom, φ, F, ψ, Rng) mit freien Konfigurationsparametern, mit 

Prädikaten (φ, ψ) für den Bildbereich Rng und den den Urbildbereich Dom. Eine abgeleitete Funktion wird aus 

F = θ(F 1 , ..., F m ) durch eine Ausprägung und Instantiierung dieser Parameter und eine Instantiierung der Prädikate 

erhalten. 

Eine typische generische Funktion ist die Suche. Sie kombiniert sieben verschiedene Arten von Suchen: Stellen 

einer wohlformulierten Anfrage mit Kenntnis der Strukturierung und Erreichbarkeit, Suche in bekannten Datenbestand, 

Anfrageformen (Masken,...) mit Suchtermen, Aufspüren und Herausstöbern, Suche nach Assoziationen 

und Hineintauchen, Umherlavieren und Nachgraben und Umherspringen (zapping). Diese Formen hängen außerdem 

noch vom Kontext, den Unterstützungsfunktionen und den Benutzern ab. Zum Kontext gehören sowohl das 

vorhandene Datenmaterial, die Zusammenhänge innerhalb dieser Daten, die Unterstützung für eigene Suchablagen 

und die bisherige Suchhistorie. Typische Unterstützungsfunktionen sind Funktionen zur Führung, für den Überblick, 

zur Zurückführung z.B. zur Vermeidung von Hänsel & Gretel Suche, zum Hineinstechen, zum browsing, zum zapping, 

für Erinnerungshilfen, für Veränderungsinformation, für den eigenen Schreibtisch und den Arbeitsraum, zur 

Unterstützung bei Formulierung (z.B. durch Vorschläge zur Formulierung, Vorschläge anhand erreichbarer Daten, 

Verfeinerung und Auswahl, Transformation je nach Daten, linguistische Hilfen (Synonyme, Troponyme, ...)). Vorlieben 

des Suchenden determinieren die Ausprägung. 

Eine Funktionalisierung (S, F, Σ, s 0 ) einer generischen Funktion F kann durch drei Dimensionen wie in Abbildung 

17 gekennzeichnet werden: 

1. Das Instantiieren der Parameter, die Einbettung in die entsprechende Datenräume und deren Strukturierung S, 

eine Reihe von dynamischen Konsistenzbedingungen Σ und eine Anfangspunkt s 0 in einem Raum. 

2. Die Anreicherung um Kontext der konkreten Anwendung, der vorhandenen Daten, der nutzbaren Unterstützung 

durch Systeme, der Community of Practice und der Benutzungshistorie. 

IS ADD


3. Die Verfeinerung der Funktionen hin zu spezifischeren Funktionen mit einem Verfeinerungsbegriff aus der 

Theoretischen Informatik. 

✻ 

Refinement 

(S 1 , F 1 , Σ 1 , s 1 0) 

✿ ... 

❥ 

(S 2 , F 2 , Σ 2 , s 2 0) 

✲ 

Context 

embedding 

✠ 

Instantiation 

Abbildung 17: Ausprägungsdimensionen für generische Funktionen 

Wortfelder und generische Funktionen. 

Sowohl die Spezifikation der Strukturierung als auch die Spezifikation der Funktionalität lebt von der lexikalischen 

Semantik der verwendeten Wort oder Konzepte. Mit einem Wort wie Produkt oder Person ist bereits eine 

rudimentäre semantische Erklärung für den Datenbanktypen, seine wesentlichen Eigenschaften (bzw. Attribute) und 

Verarbeitungmechanismen gegeben. Diese Wortsemantik wird im Spezifikationsprozeß schrittweise verfeinert zur 

Spezifikation von Typen mit einer Ausformulierung der Strukturierung, der Sichtweisen auf Daten diesen Typs und 

ihrer Verwendung und Speicherung. Diese Herangehensweise hat sich nicht nur als sehr mächtig erwiesen, sondern 

wurde allgemein akzeptiert und intuitiv in allen Anwendungen eingesetzt. Für Informationssysteme kann man deshalb 

eine Abstraktionsschichtung in eine Anwendungsschicht, eine Geschäftsprozeßschicht, eine Konzeptionalisierung 

und eine Implementation vornehmen. Es ist allerdings verwunderlich, daß eine Spezifikation der Funktionalität 

in dieser Form bislang nur rudimentär unterstützt wird. 

Die Lexika natürlicher Sprachen lassen sich durch Wortfelder charakterisieren. Ein Wortfeld stellt i.a. sowohl 

syntaktisch als auch semantisch und pragmatisch Worte in Wortklassen zusammen 

Ein typisches einfaches Wortfeld ist das sagen-sprechen-reden-Wortfeld, das eine Form der Kommunikation umfaßt. 

Es umfaßt dabei sechs Facetten mitteilen (als feststellen, bekanntgeben, rufen, schreien, flüstern, schwätzen), 

erwähnen, fragen (sich erkundigen, erfragen, nachfragen), auffordern (bitten, befehlen, vorschlagen), antworten (erwidern, 

ausweichen) und wiederholen). 

Wortfelder kombinieren dabei Phonetik, Morphologie, Syntax und Semantik sowie auch Pragmatik wie in Abbildung 

18. Diese Struktur erweitert den Rahmen für Wortfelder, der in der Linguistik benutzt wird, um Aspekte, die für 

Informatikanwendungen ebenfalls erfaßt werden müssen. 

Die Beschreibung der Handlungsabläufe lehnen wir dabei an die Formenlehre an. Die Theorie der Wortfelder 

kann zu Konzeptfeldern bzw. Konzeptrahmen erweitert werden, durch eine Kontextualisierung (oder Konjugation) 

und durch Instantiierung der Parameter 

Akteursprofile und -portfolio, 

Wiederholungsprofil, 

Zeitprofil, 

deontischer Modus mit imperativen, konjunktiven und indikativen Ausprägungen und 

IS ADD


Semantische Fälle 

Morphologische 

Gestalt 

Referentielle 

denotationale 

Semantik 

Charakteristiken 

Akteurskategorie 

Prozeßkategorie 

Bedingungen 

Parameter 

Anwendungsgebiet 

Konzepte 

Syntax 

Grammatisches Muster 

Basisform Bedingungen 

Wortmenge 

Parametermuster 

Objekt 

Subjekt 

Optionalität 

* 

Wortfeld 

Varianten der 

Parameter 

Sender 

Empfänger 

Inhalt 

Inhalt 

Historie 

Nutzung 

Kernsemantik 

Bedeutung 

Semantische Invarianten 

Dialogschritte 

Verteilung 

Akteur 

Szenen 

Stammsemantik 

Valenz 

Zeit 

Umstände 

Anwendungsmuster 

Abbildung 18: Die Struktur eines Wortfeldes 

Aktionsform und Handlungsrichtung zur Darstellung der Beziehung zwischen Akteur und Handlungsablauf. 

Ein Konzeptfeld ist ein generisches Konzept, aus dem ein Konzept durch Instantiierung einer Reihe von Merkmalen 

abgeleitet wird. 

Konstruktion generischer Workflows. 

Generische Funktionen können als atomare Aktivitäten innerhalb von generischen Workflows verwendet werden. 

Eine Spezifikation kann an Workflow-Spezifikationssprachen wie BPMN angelehnt werden, wobei dann allerdings 

eine Verbesserung der entsprechenden Standards hin zu wohldefinierten Sprachen vorher entwickelt werden muß 16 . 

Die Konstruktion generischer Workflows kann dabei wie folgt erfolgen: 

Ein atomarer generischer Workflow ist eine generische Funktion. 

Einfache Steueranweisungen sind 

die sequentielle Ausführung ; , bei der generischer Workflows sequentiell nacheinander ausgeführt werden, 

wobei die Semantik des ersten generischen Workflows die Semantik des zweiten generischen Workflows 

ergänzt und der leere generische Workflow entsteht, wenn die Vereinigung der Semantik zum Widerspruch 

führt, 

parallele Verzweigung | ∧ | , bei der generische Workflows parallel ausgeführt werden können und das terminiert, 

wenn beide generischen Workflows terminieren, 

exklusive Auswahl | ∨ | , bei der genau ein generischer Workflow zur Ausführung nichtdetermistisch ausgewählt 

werden kann, 

Synchronisation | sync | , die eine parallele Ausführung mit einer Synchronisationsbedingung zuläßt, und 

einfaches Mischen + , bei dem zwei alternative generische Workflow verbunden werden können. 

16 E. Börger and B. Thalheim. A method for verifiable and validatable business process modeling. In Software Engineering, Lecture Notes 

in Computer Science 5316, 59 – 115. Springer, 2008. 

IS ADD


Erweiterte Verzweigungs- und Synchronisationsanweisungen sind 

mehrfache Auswahl, bei der verschiedene Ausführungspfade gewählt werden können, 

mehrfaches Mischen , bei dem verschiedene Ausführungspfade gemischt werden können, 

Diskriminator, bei dem verschiedene Ausführungspfade ohne Synchronisation gemischt werden können, wobei 

Teile von generischen Workflow nur einmal ausgeführt werden, 

n-out-of-m.Verbund, bei dem verschiedene Ausführungspfade mit partieller Synchronisation gemischt werden 

können, wobei Teile von generischen Workflows nur einmal ausgeführt werden, und 

synchronisierter Verbund, bei dem verschiedene Ausführungspfade mit vollständiger Synchronisation gemischt 

werden können, wobei Teile von generischen Workflows nur einmal ausgeführt werden. 

Strukturelle Steueranweisungen sind 

Wiederholung ∗ , bei der generische Workflows beliebig oft ausgeführt werden können und 

implizite Termination ↓ , die eine Beendigung des generischen Workflows hervorruft. 

Datenabhängige Steueranweisungen sind 

statische Steueranweisungen , deren Steuerung mit Bedingungen erfolgt, die bereits zur Compilezeit geprüft 


statische Steueranweisungen, deren Steuerung mit Bedingungen erfolgt, die erst zur Laufzeit geprüft werden 

können, 

Steueranweisungen mit A-priori-Laufzeitannahmen erlauben eine Voreinstellung durch Erzeugung von einer 

beschränkten Menge von Wiederholungen und 

Steueranweisungen mit Synchronisationsbedingen, bei denen beliebig viele Alternativen parallel ausgeführt 

werden können und eine Synchronisation bei Abschluß erfolgt. 

Zustandsbasierte Steueranweisungen sind 

die verzögerte Auswahl, bei der alle Alternativen ausgeführt werden und eine Auswahl der Alternative erst 

nach Ausführung erfolgt, 

die verbundene parallele Ausführung, bei der die Alternativen in zufälliger Reihenfolge sequentiell ausgeführt 

werden, und 

die meilenstein-basierte Steuerung, bei der eine Aktivität ausgeführt wird, bis ein Meilenstein erreicht ist. 

Abbruchanweisungen sind 

Abbruchaktion , bei der eine generische Funktion abgebrochen wird, und 

Fallabbruch , bei der ein Fall abgebrochen wird. 

Diese Algebra kann genutzt werden, um generische Workflows zu konstruieren. Mit dieser Algebra führen wir eine 

strikte Klammerung ein. Damit sind nicht mehr alle Ausdrücke darstellbar, die in der Workflow-Literatur breit 

diskutiert werden. 

Wir sind damit in der Lage, klassische Fallen der Workflow-Sprachen für generische Workflows zu vermeiden. 

Diese Fallen sind relativ leicht aufzulösen, wenn man die Resultatssemantik betrachtet. In diesem Falle sind beide 

Programme durch AND-AND-Programme repräsentiert. Betrachtet man dagegen die Ausführungssemantik, dann 

klaffen die beiden Programme auseinander. Noch schwieriger sind Workflow-Semantiken, bei denen eine Synchronisation 

sowohl am Ende als auch zu Beginn einer Verzweigung erfolgen kann. In diesem Fall erhält auch die Verzweigung 

eine andere Semantik. 

Aus diesen Gründen bevorzugen wir die etwas striktere Semantik der generischen Workflows. Sie hat zugleich 

auch den Vorteil, eine Verfeinerung zuzulassen und auch Konflikte auf Datenebene durch Zurücknahme auflösen zu 

können. 

IS ADD


Für einen Workflow können wir einen Ablauf durch Verlaufsschichten darstellen. Jeder Schritt in einem Workflow 

kann mit einer natürlichen Zahl assoziiert werden, wobei in Zyklen sowohl die natürliche Zahl für den Zyklus als 

auch die Verlaufszahl im Zyklus verwendet wird. Diese Nummerierung ist möglich, weil unsere Workflow-Definition 

nur wohl-geklammerte Strukturen (Fitch-Strukturen) zuläßt. Diese Nummerierung kann auch dicht gewählt werden, 

so daß zu jeder Verlaufszahl n auch der Vorgänger n−1 (für n > 1) und der Nachfolger n+1 (für n < max) als Verlaufszahl 

existiert. Ein Verlaufsschicht ist durch ihre Verlaufszahl definiert. Verlaufsschichten stellen die schrittweise 

und ggf. parallele Ausführung eines Workflows dar. 

Techniken der Verfeinerung. 

Die Verfeinerung von Prozessen und Berechnungen ist in der Informatik ein stets aktuelle und schwierige Aufgabe. 

Hinzu kommt die Aufgabe, zur Laufzeit auch den Bearbeitungskontext zu berücksichtigen. Wir können zur 

Verfeinerung von Workflows den Ansatz der Abstract-State-Machines nutzen. Mit einer Verfeinerung eines Workflows 

soll sich das Verhalten des allgemeineren Workflows zumindest für den Betrachter nicht ändern. 

Damit kann man den Verfeinerungsmechanismus über der Menge der beobachteten Zustände und der beobachteten 

Ereignisse definieren. Ein Workflow verfeinert einen abstrakteren Workflow, wenn zum einem das Verhalten 

für die beobachteten Zustände und die beobachteten Ereignisse sich durch eine Vergröberung auf den abstrakteren 

Workflow in der gleichen Form darstellt und zum anderen alle Abläufe auf dem abstrakteren Workflow sich auch in 

dem verfeinerten beobachten lassen. 

Diese Form der Verfeinerung kann genutzt werden, um mit einer Y -Verfeinerungstechnik zu arbeiten. Es wird 

zum einem der generische Workflow und zum anderen der konkrete Workflow im Kontext betrachtet. Für diese 

beiden Workflows wird eine gemeinsame Verfeinerung betrachtet, so daß sowohl der Kontext als auch der eigentliche 

Workflow sich im gemeinsamen verfeinerten Workflow wiederspiegeln lassen. 

Da sich die Prozesse über generischen Funktionen definieren lassen, haben wir es bei der Y -Verfeinerung entweder 

mit einer Verfeinerung der generischen Funktionen oder mit einer Verfeinerung der Workflows an sich zu tun. 

Die erste Form entspricht der Kontext-Injektion für generische Funktionen. Die zweite Form ist i.a. komplexer. Eine 

allgemeine Lösung ist dafür nachgewiesenermaßen nicht zu finden. 

Es kann jedoch eine konservative Verfeinerung entwickelt werden. Wir gehen dazu von der Struktur des Workflows 

aus und schränken die Verfeinerungsoptionen wie folgt ein. 

Einfache Steueranweisungen wie die sequentielle Ausführung, die parallele Verzweigung, die exklusive Auswahl, 

die Synchronisation werden verfeinert durch Ersetzen einer Aktivität im Workflow durch eine vollständige 

Workflow im Falle einer sequentiellen Ausführung, durch eine exklusive Ausweitung der Fälle für parallele 

Verzweigung und durch eine Erweiterung für das einfache Mischen. 

Erweiterte Verzweigungs- und Synchronisationsanweisungen werden nicht verfeinert. 

Strukturelle Steueranweisungen können nicht verfeinert werden. 

Datenabhängige Steueranweisungen können verfeinert werden durch die Unterlegung verfeinerter Datenstrukturen, 

aus denen die allgemeineren über Sichtenkonzepte dargestellt werden können. 

Zustandsbasierte Steueranweisungenn können nicht verfeinert werden. 

Abbruchanweisungen können nicht verfeinert werden. 

Diese Verfeinerung wird mit den oben beschriebenen Government-and-Binding-Techniken unterstützt, so daß damit 

eine programmtechnische Unterstützung entwickelt werden kann. 

Injektion von Kontext. 

Der Kontext für Workflows ergibt sich aus der konkreten Anwendung, den vorhandenen Daten, der nutzbaren 

Unterstützung durch Systeme, der Community of Practice und der Benutzungshistorie. Der Kontext für den konkreten 

Workflow wird außerdem durch die Historie des Workflows mit dargestellt. Damit kann der Kontext schrittweise mit 

IS ADD


der Reihenfolge der Ausführung der generischen Funktionen auch in den Workflow injiziert werden, wobei ein einmal 

genutzter Kontext nicht überschrieben werden darf für eine spätere Verlaufsschicht. 

Entfaltung aktueller Workflows aus generischen Workflows. 

Wir nutzen für die Entfaltung aktueller Workflows aus generischen Workflows sowohl die oben dargestellten 

Verfeinerungstechniken als auch die Definition der generischen Funktionen sowie eine Technik der schrittweisen 

konservativen Ausweitung des Kontextes und der Instantiierung. Eine Entfaltung ist vollständig, wenn alle Parameter 

mit Werten gebunden sind. 

Entfaltung durch Verfeinerung: Es wird der Workflow konservativ verfeinert. 

Entfaltung durch Entfaltung generischer Funktionen: Die generischen Funktionen werden in der Reihenfolge entfaltet, 

in der sie im Workflow vorkommen, d.h. entsprechend der Verlaufsschichten. Zusammenhänge bei den 

Parametern, bei der Instantiierung und beim Kontext werden dabei mit Techniken attributierter Grammatiken 

fortgeschrieben. 

Entfaltung durch Ausweitung des Kontextes: Der Kontext wird ebenfalls schrittweise entsprechend der Verlaufsschichten 

in die generischen Funktionen und die Steuerung injiziert. 

Entfaltung durch Instantiierung: Alle generischen Funktionen werden entsprechend den Verlaufsschichten schrittweise 

instantiiert. Zusammenhänge bei der Instantiierung werden mit Techniken attributierter Grammatiken 

fortgeschrieben. 

Diese Entfaltung kann auch bereits zur Spezifikationszeit für alle wesentlichen Szenarien auf Konsistenz getestet 

werden. Es werden dazu Szenarien mit einem Storyboarding-Ansatz 17 erhoben. Diese Szenarien werden genutzt, 

um daraus Testfälle für Abläufe von Workflows abzuleiten. Diese Testfälle werden dann gegen eine vollständige 

Entfaltung der Workflows getestet. Dieser Test wird zur Spezifikationszeit durchgeführt, so daß damit Abläufe zur 

Laufzeit nicht durch Tests behindert werden. 

Ist ein generischer Workflow gegenüber den Szenarien konsistent, dann kann mit den Entfaltungsmethoden zur 

Laufzeit aus einem generischen Workflow ein aktueller Workflow schrittweise entfaltet werden. Diese Entfaltung ist 

damit konservativ. 

Extract-Load-Transform-Prozesse 

In der Informatik gibt es einige universelle Verarbeitungsmuster. Eines der universellsten für den Bereich der Datenbankund 

Informationssysteme ist das Extraktion-Transformation-Laden-Muster (ETL). Es wird in der Informationsverarbeitung 

breit angewandt und wurde als universelles Austauschverfahren insbesondere im Bereich des Data-Warehousing 

genutzt. ETL-Verfahren nutzen in starkem Maße die Sichtenbildung bzw. auch den Sichten-Update-Mechanismus, 

den die großen DBMS bereitstellen. Dies unterliegt aber dem Plattform-Paradigma der einzelnen Systeme und ist 

deshalb nicht universell. So kann man nur von relationalen Systemen eine Unterstützung erwarten. Heterogene Systeme 

unterstützen deshalb einen solchen Mechanismus nicht. 

Extraktion, Transformation und Integration von Daten. 

Für Datenwarenhaus-Systeme stellt sich der ETL-Prozeß nach Kimball wie in Bild 19 dar. 

Noch begrenzter wird der ETL-Mechanismus durch eine fehlende Durchleuchtung und damit durch eine rudimentäre 

Unterstützung der Transformationsverfahren. Damit werden dem ETL-Muster Grenzen gesetzt, die nur 

durch die Unzulänglichkeit der Systeme verursacht werden nicht aber am ETL-Verfahren selbst liegen. 

Der ETL-Prozeß. 

17 Dieser Ansatz hat sich für die Entwicklung von großen Websites in mehr als einem Schock Projekten bewährt und wurde erstmals eingeführt 

in A. Düsterhöft and B. Thalheim: Conceptual modeling of internet sites. In Proc. ER’01, LNCS 2224, pages 179–192. Springer, 

2001. 

IS ADD


Abbildung 19: Architektur des klassischen ETL-Prozesses nach Kimball (2004) 

Der Extraktionsprozeß gründet sich auf der Kenntnis der Datenstrukturierung und der Metadaten zu einer Datenbank. 

Er wird derzeit als Sichtenkonzept aufgesetzt. In Web-Informationssystem-Anwendungen des Lehrstuhles 

Technologie der Informationssysteme und seiner Vorgänger wurde dieser Zugang um den Apparat der Medientypen 

erweitert. Diese Typen verfügen über eine stereotypische und außerdem eine spezifische erweiternde Funktionalität, 

damit mit den Daten auch direkte Berechnungsprozesse möglich sind. Dieser Apparat erweitert die klassischen 

Zugänge der Objektorientierung, die derzeit den Standard der Programmierung stellen. 

Der Transformationsprozeß ist im Rahmen des Compiler-Zuganges heute tiefgründig ausgearbeitet. Es werden 

z.B. mit einem Vier-Paß-Compiler Programme in einer Source-Sprache analysiert, semantisch aufbereitet, transformiert 

in eine Ziel-Sprache und nachfolgend anhand des Performanzprofils des Zielsystemes optimiert. Außerhalb 

von Compilern wurde der Zugang jedoch selten angewandt. Am Lehrstuhl Technologie der Informationssysteme und 

seiner Vorgänger wurde im Rahmen des Co-Design-Zugangs für Datenbankanwendungen dieser Zugang genutzt, um 

auch eine automatische Transformation von Daten vorzunehmen, wobei die Transformation sowohl vom Namensraums 

bzw. der Signatur als von der verwendeten Deklaration der formalsprachlichen Ausdrücke sowie auch von den 

verwendeten Datenbankschemata her betrieben werden kann. 

Der Integrationsprozeß bzw. der Ladeprozeß von Daten in Datenbanken wird gewöhnlich über updatefähige Sichten 

unterstützt. Aufgrund des Update-Problems für Sichten sind in industriellen Anwendungen auch andere Zugänge 

entwickelt worden. Einer der am Lehrstuhl erprobten Zugänge ist die Ableitung einer Update-Infrastruktur, in der 

solche Daten vorgehalten werden, die zur eindeutigen Identifizierung von zu modifizierenden Daten notwendig sind. 

Dieser Zugang zu ETL erlaubt auch eine Pflege der Integritätsbedingungen, so daß auch ein Qualitäts-Update 

erfolgen kann. Dazu wird das Portfolio der Integritätsbedingungen neben der Deklaration vorgehalten. Es kann damit 

auch erreicht werden, daß Verletzungen der Bedingungen nicht zum Abbruch führen, sondern eine Reihe von 

Zusatzprogrammen zur separaten Behandlung der Problem anstoßen. 

Erweiterte ETL-Techniken. 

Da Daten nicht immer auf dem gleichen Detaillisierungsgrad benötigt werden, ist es oft erforderlich, auch 

Aggregations- und Zusammenfassungstechniken zu integrieren. Dies wird durch die existierende Datenbanktechnologie 

gut unterstützt. Man wendet dabei erfolgreich auch Techniken der Computerlinguistik an. Es wird dabei 

der Eingangsdatenstrom analysiert. Dazu wird auch Kontextinformation eingemischt. Danach wird eine Kondensation 

und Zusammenfassung vorgenommen. Im Anschluß wird der Datenstrom annotiert. Es wird insbesondere auch 

dem Datenstrom die Strukturierungsinformations beigegegeben. Derartige Techniken werden – wenn auch in sehr 

einfacher Form – bei XML-basiertem Datenaustausch verwendet. 

Dieser Zugang erlaubt auch die Anreicherung um Funktionalität wie für die Medientypen. Dazu wird eine Erweiterung 

um Durchmusterungs-, Annotations- und Exportfunktionen vorgenommen. Damit kann ein Importsystem die 

Daten in einfacherer Form flexibel verarbeiten, weil die erforderliche Scheaminformation und auch die erforderliche 

Funktionalität vorhanden ist. 

ETL-Werkzeuge. 

IS ADD


ETL-Werkzeuge sind in vielfältiger Form sowohl als Stand-alone-Produkt als auch als integriertes oder eingebettetes 

Produkt vorhanden. Sie haben ausgearbeitete graphische Oberflächen, die auch eine einfache Verarbeitung 

und Durchmusterung sowie auch Visualisierung gestatten. Damit wird auch die Pflege von Daten unterstützt. Hinzu 

kommen Programme, um die Performanz der Be- und Verarbeitung zu skalieren. 

Diese Werkzeuge sollen jedoch keine Universalwerkzeuge sein. Sie sind für eine Verknüpfung von Systemen 

entworfen und erfordern auch eine handwerkliche Spezifikation der Extraktion, der Transformation und der Integration 

der Daten. Dies beschränkt auch die breite Nutzung. Es ist insbesondere derzeit nur eine statische ETL- 

Prozeßunterstützung vorhanden. Dynamische Adaption ist noch nicht vorgesehen. 

Schemata des exportierenden Datenbank und der importierenden Datenbank, deren unterlegte Paradigmen und 

Spezifikationstile und deren Transformation müssen im Detail bekannt sein. ETL-Werkzeuge sind auch nicht in der 

Lage, die Qualität der Daten zu analysieren und die Korrektheit der Transformation nachzuvollziehen. Dies schränkt 

die derzeit verfügbare Technik ein, so daß im Rahmen des Projektes eigene Zusatzprogramme entwickelt werden 

müssen. 

Anwendung der verallgemeinerten ETL-Prozesse für das Data Mining. 

Im Rahmen der beiden Exzellenzcluster-Projekte der CAU zu Kiel “Future Ocean” und “Inflammation at Interfaces” 

sowie der Graduiertenschule “Human Development in Landscapes” sind viele Arbeitsgruppen mit Data- 

Mining-Teilprojekten beschäftigt. Damit ist ein hoher Beratungsbedarf zur Auswahl der Verfahren, zur Qualität und 

Geeignetheit von Daten, zur Beurteilung der erreichten Resultate und zur Weiterbearbeitung mit weiteren Verfahren 

entstanden. Am Lehrstuhl Technologie der Informationssysteme ist deshalb ein Zugang zum systematischen Data- 

Mining entstanden (Data Mining Design). Dieser Zugang erlaubt eine systematische Auswahl von Verfahren, eine 

Workflow-Begleitung des Data Mining und eine Integration von ETL-Prozessen nach dem folgenden Muster: Modelle 

von Source- und Zieldatenstrukturen werden dargestellt durch entsprechende erweiterte Extraktionsmodelle für 

das Source-Modell (insbesondere um Ourput-Sichten M s,t,outp,i für M s ), um entsprechende erweiterte Lademodelle 

(insbesondere um Input-Sichten M t,s,inp,j für M t ). Daraus werden Abbildungen über ETL-Prozesse gewonnen. 

extract e s,t,i ✲ transform t s,t,i,j 

M s M ✲ load l s,t,j 

s,t,outp,i M ✲ 

t,s,inp,j M t 

Die Transformation und das nachfolgende Informations-Management werden um Techniken für Rekombination, 

Refactoring und ggf. Pflege der Daten erweitert. Für das Laden wird eine Datenumgebung aus dem Zielsystem 

abgeleitet, so daß Daten aus dem Source-System eindeutig integriert werden können. 

Die gleichen Techniken wurden auch verwendet im Unesco-Projekt zur Katastrophennachsorge mit dem N.I.C.T., 

Keihanna, Kyoto, Japan. Es wurde auch hier eine systematische integrierte Datenanalyse mit ETL-Techniken angereichert. 

Werkzeuge für das Datenmanagement 

Ein integriertes Datenmanagement wird nicht nur zu entsprechenden Werkzeugen zur Abspeicherung und zur Ablage 

von Daten führen, sondern auch mit Werkzeugen zur intelligenten Integration und zum intelligenten Import von Daten 

und mit Werkzeugen zu einer aufgabenbezogenen Auswertung von Daten je nach Freischaltung und Freigabe führen. 

Wir können deshalb ein System, dessen Komponenten in Bild 20 dargestellt werden, als Ziel des Datenmanagement 

im Exzellenzcluster uns vorstellen. 

Die Realisierung kann in zwei Phasen erfolgen: 

Phase 1: Entwicklung von Werkzeugen zur Datenanalyse, zur Datenerfassung und zur Integration von Daten; 

Phase 2: Entwicklung einer Kollaborationsplattform für die Arbeitsgruppen am IFM GEOMAR. 

Diese Phasen werden durch eine Entwicklung einer Reihe von Werkzeugen begleitet: 

1. Werkzeuge der Phase 1 zum Import, zum Export und zur Verwaltung von Daten: 

IS ADD


Content gardening 

Data accreditation 

Analysis portfolio 

Workspace 

Data cleansing 


Generator for 

analysis 

Acquisition forms 

Storage&integration 


forms 

Active preparation 

Data cluster 

Access 

management 

Census 

data 

Foreign 

data 

Legacy 

data 

✲ 

Tools for 

data 

✲ import 

export 

✲ 

Data sluice 

✲ 

Content 

management 

system 

micro/macro data, 

content, concepts 

✲ 

Analysis and exploration system 

Database 

extractors 

database 

mining 

user group 

firewall 

✲ Working team 

members 

✲ 

✲ 

Anonymous 

users 

Cooperating 

users 

Abbildung 20: Das intelligente System zur Datenaufbereitung und -auswertung 

Werkzeuge für den Import von Daten mit Funktionen zur Extraktion von Daten, zur Bereinigung und Aufbereitung 

von Daten und zur Integration von Daten mit bereits existierenden Daten; 

Werkzeuge zur Vorbereitung der Datenerhebung auf der Grundlage von Erhebungsformen und -formularen, 

von Formularen zur Integration von Fremd- und eigenen Daten in bereits existierende Datenbestände und 

für eine Integration von Altdaten-Beständen; 

Werkzeuge zur Begleitung von Benutzern während der Vorbereitung zur Erhebung, während der Hypothesenfindung, 

während der Konzeptualisierung und während der Integration von Datenbeständen; 

Content-Management-Systeme für die Verwaltung von Daten in unterschiedlicher Granularität, Annotation, 

unterschiedlicher Benutzung und Freigabe zur Benutzung und zum Export in andere Datenbestände; 

Zugriffsverwaltung für den Zugriff auf Daten je nach Freigabe, Benutzungsrechten, Protokollierung der Benutzung. 

2. Werkzeuge der Phase 2 zur Unterstützung der Kollaboration zwischen den Gruppen des Exzellenzclusters, mit 

nationalen und internationalen Kollaborationspartnern: 

Datenschleusen zur automatischen oder gesteuerten Integration von Daten mit entsprechenden Integrationsfunktionen, 

Funktionen zur Steuerung der Aufbereitung 

Kollaborationswerkzeuge für die schnelle Ad-Hoc- und die systematische Zusammenarbeit von Arbeitsgruppen 

mit entsprechenden Partnern während der Analyse, der Integration und der Diskussion von Datenbeständen; 

Content-Management-Werkzeuge zum Umgang mit Mikrodaten wie z.B. Sensordaten, mit aggregierten Makrodaten, 

mit Auswertungs- und Illustrationsdaten und zur Entwicklung von Konzepten, die mit diesen 

Daten erklärt und belegt werden können; 

Werkzeuge zur Erstellung und Verwaltung von Benutzungsportfolio und Benutzerprofilen mit denen für 

Benutzer und Benutzungsgruppen auch eine zeitweilige Mitbenutzung von Daten und eine Vervollständigung 

von Daten unterstützt werden und mit denen eine Anpassung des Präsentationsformates an die 

Benutzung und an die Benutzer je nach Anforderung, nach Portfolio oder Profil erfolgen kann; 

Werkzeuge zur Content-Pflege bei Weiterentwicklung des Datenbestandes, bei Integration neuer Datenbestände 

und beim (zeitweiligen) Außerkraftsetzen von (ungültigen) Datenbeständen. 

5.6.11 Intelligente Monitore und Situationsbeobachter 

Bislang sind aus der Literatur nur statische Monitoring-Konzepte bekannt, bei denen ein Monitor als abgeschlossene 

Komponente zur Anwendungszeit keine Veränderung mehr erfährt. Solche Monitoren müssen damit mit einer 

IS ADD


Vielzahl von Funktionen ausgerüstet werden, die oft den Entwicklungsrahmen sprengen und deshalb nur rudimentär 

vorgehalten werden. 

Intelligente Systeme sind seit der Entwicklung der Künstlichen Intelligenz ein Ziel für Software-Systeme gewesen. 

Das Gesamtprogramm der KI ist nicht erfolgreich gewesen aufgrund des Anspruchs einer Universallösung. 

Erprobte Mechanismen der KI können jedoch für ein selbstadaptives Verhalten von Systemen genutzt werden. Derartige 

Mechanismen sind z.B. schon bei Web-Informationsystem-Anwendungen integriert worden. Sie finden auch 

Anwendung bei der Rechnernetz-Organisation, bei Produktionsplanungs- und -steuerungssystemen, bei Warenwirtschaftssystemen 

und in Telekommunikationsanwendungen. Alle diese Anwendungen basieren auf Regeln, mit denen 

Parameter von Systemen automatisch verändert werden. 

In vielen Anwendungen der Datenanalyse wird derzeit dagegen ein Data-Warehouse-Zugang präferiert. Es werden 

die Mikrodaten zu Mesodaten verdichtet. Diese Mesodaten werden in Datenbanksystemen verwaltet und sollen 

redundanzarm sein. Die Mesodaten dienen der Erzeugung von Makrodaten für eine Data Warehouse. Dieses nutzt 

gewöhnlich hochredundante Daten. Mit der Erhöhung der Redundanz und der Bereitstellung der Daten in vielen Varianten 

wird zugleich die Retrieval- und Analyse-Performanz gesteigert. Dadurch sind Makrodatenmengen oft riesig 

(‘big data’) und relativ schwer zu durchmustern, wenn eine direkte Funktionsunterstützung nicht vorhanden ist. 

Es kann jedoch ein Zugang genutzt werden, der in Altsystemen mit deren geringer Performanz (Datendurchsatz, 

Speicherung) in den 70-igern genutzt wurde. Es werden die direkt interessierenden Daten in speziellen Monitoren 

erfaßt. Diese Monitore sammeln die Daten sofort nach Anfallen. Sie haben ein Dateninteressenprofil und können 

deshalb dediziert die richtigen Daten interpretieren. Dieser Zugang wurde im Militärbereich bei Projekten des ‘Intelligent 

Dust’ wieder entdeckt. Er ist jedoch dort nicht publiziert worden. 

Das Konzept des automatischen Situationsbeobachters. 

Automatische Situationsbeobachter sind Stand-der-Technik bei Automotive-Anwendungen. Sie werden jedoch 

nicht durch Software realisiert, sondern sind Teil der elektronischen Hardware. In einem Projekt mit VW Research 

hat sich die Arbeitsgruppe Technologie der Informationssysteme mit deren Integration in Software-Systeme für ein 

Intelligentes Cockpit in Autos der Premium-Klasse auseinander gesetzt. Es konnte dort mit einer spezifischen Exportund 

zum anderen einer spezifischen Injektionstechnik eine bessere Verbindung solcher Beobachter mit Auswertungssoftware 

erreicht werden. 

In der Software-Technologie sind derartige Beobachtungswerkzeuge bislang nicht untersucht. Sie werden jedoch 

auch in modernen Software-Produkten als interne Komponente verwendet. Da derartige Teilsysteme für die Software 

ein Konkurrenzvorteil ist, gibt es dazu eine Vielfalt an Patenten mit einer sehr spezifischen Ausrichtung auf die 

jeweiligen Software-Produkte aber keine wissenschaftlichen oder auch technischen Veröffentlichungen. Ein typisches 

Beispiel sind Monitore für die automatische Ableitung von effizienten Anfragebäumen in Datenbank-Management- 

Systemen. In einem Projekt zum Speicher-Management von Sybase haben wir diese Monitore kennengelernt. 

Die Situationsbeobachter können in verschiedenen Modi laufen je nach Relevanz der aktuellen Situationen. Sie 

können für zentrale Daten eine einfache Beobachtung vornehmen. Ändert sich der Zustand hin zu einem potentiell 

kritischen Zustand, dann wird eine Ausweitung der Beobachtung vorgenommen, mit der dann auch detaillierte Analysen 

vorgenommen werden können. Dieser Dimmer-Modus ist zugleich eine daten- und kommunikationsarme Form 

der Beobachtung. 

Das Konzept des agilen und aktiven Situationsbeobachters. 

Agile und aktive Situationsbeobachter sind derzeit in keinem Software-Produkt vorhanden. Sie müssen anhand 

der Analyse einer Situation in der Lage sein, andere Komponenten des Systems zu veranlassen, das Verhalten und 

damit auch die Programme zu ändern. In Elektroniksystemen sind derartige Funktionen in gewissem Maße bereits 

integriert. Ihre breite Anwendung ist für moderne Automotive- und Aero-Anwendungen derzeit in Vorbereitung. Dies 

wird durch eine ausgefeilte Standardisierung der einzelnen Elemente unterstützt. 

Agile und aktive Situationsbeobachter sind eine Notwendigkeit für viele Realtime-Anwendungen. Sie erfordern 

aber einen ganzheitlichen Steuerungsmechanismus und eine fundierte Kollaboration von Komponenten. Diese Kollaboration 

kann mit einem 3K-Modell 18 unterstützt werden, bei dem die Kommunikation den Austausch von Daten 

18 3C steht für Kommunikation + Kooperation + Koordination. 

IS ADD


und Nachrichten garantiert, die Kooperation die sichtbaren Prozesse der einzelnen zusammenarbeitenden Elemente 

darstellt und die Koordination die Einhaltung der Zusicherungen für die Kollaboration garantiert. 

Am Lehrstuhl TIS sind in einer Reihe von Projekten 3K-Kollaborationen unterstützt worden. Dabei wurde die Koordination 

auf einem rely-guarantee-tolerate-Mechanismus zur Unterstützung der Verträge aufgesetzt. Mit guarantee- 

Bedingungen wird eine Zusicherung dem Partnerprogramm für die zu generierenden Daten dargestellt. Mit rely- 

Bedingungen wird dagegen die Zusicherung der Partnerprogramme deklariert. Mit tolerate-Bedingungen wird die 

explizite Abweichung von Normen und die Reaktion darauf dargestellt. Der rely-guarantee-tolerate-Mechanismus ist 

weitaus besser geeignet als die Programmierung auf Grundlage von Ausnahmen. 

Agile Situationsbeobachter nutzen die Kollaboration mit anderen Software-Komponenten, um aus diesen Daten 

Schlüsse über den Zustand des beobachteten Systemes zu ziehen. Sie besitzen einfache Schlußregeln, mit denen der 

beobachtete Zustand kategorisiert werden kann. 

Aktive Situationsbeobachter steuern bei Erreichen von Schwellwerten andere Teilprogramme. Diese Teilprogramme 

werden mit einem zentralen Controller auf eine Rekonfiguration vorbereitet und dann in einem anderen Modus 

gefahren. Das Konzept der aktiven Situationsbeobachter verallgemeinert den ECA-Zugang 19 für Trigger und den 

Greatest-Consistent-Specialisation-Zugang für die Erzwingung der Gültigkeit von Integritätsbedingungen in Datenbanksystemen. 

5.6.12 Ten Resulting Guidelines of Data Modelling 

We may now use the guidelines developed in books and papers of practitioners, e.g. those within the DAMA community 

[Dre95, LTN07, Pas00, SW05, Sim07]. These guidelines can directly be used for development of tactics in the 

sense of [Boe06]. 

(1) Careful What you Wish For: Data Types and Complexity 

Computer Science has developed the notion of a data type. It is given by a name, by a domain, by operations and 

predicates, and by type constraints. 

Complex data types are specified through application of constructors. These constructors also provide selectors, 

initialisation and destruction operations. Those operations are the basis for an algebra that inherits the operations of 

the components used for construction. 

Moreover, data types have a number of representations and storage alternatives. The actual representation should 

be invisible to the user in order to maintain data independence, i.e. it is transparent. Database textbooks often do not 

differentiate between a data type and its representation and its storage. So people often think that a type has a unique 

representation and a unique storage. DBMS are however far more powerful and at the same time far more rigid. User 

get data in a form that is based on a declared representation. 

Finally, SQL nowadays supports user-defined types. The problem is however that the corresponding functions and 

predicates must be programmed. 

Modern data management must thus support data type atomicity. Values are atomic no matter how complex the 

representation is. 

There are also design concerns. We should distinguish whether a complex value is used for an attribute or broken 

into its constituents and thus being used for a sequence of attributes. A rule of the thumb could be whether this value 

represent a property of an object or whether we need to separate this property with in the application. One operational 

separation is the deployment of the value for links and references. 

A good data model defines the following three properties: 

Atomicity is defined by the smallest unit of information. 

Selectivity is based on sensible combinations of units. 

Addressability provides alternatives for logical addressing schemata. 

19 ECA: Bei Vorliegen eines Ereignisses (E) wird bei Gültigkeit einer Bedingung (C) das System zu zusätzlichen Aktionen (A) veranlaßt. 

IS ADD


(2) The Rules of the Rules: Integrity 

Integrity constraints are one of the main and most difficult components in conceptual and logical schemata. Most 

database conceptualisation approaches are however forgetful. They do not consider the meaning of these constraints 

in the given application. 

Business rules specify the rules within the application. They are conceptually represented by integrity constraints. 

The conceptual representation is however often not related anymore to the business rules. Whenever business rules 

change the change of integrity constraints becomes a nightmare. 

Integrity constraints specify the data correctness and thus provide the criterion for database modification acceptability. 

They constitute whether the proposed modification is in fact valid (or at least plausible). 

Integrity constraints must be consistent with the business rules they effect and define which data are physically 

correct. They act thus as a mediator between application and implementation. 

One neglected concern during database development is the inner consistency of all database notions. The 

conceptual schema is only one source of such notions. Support schemata and especially derived schemata are another 

source for such notions. 

Finally, data management must be based on complete description of integrity enforcement, i.e. on declaration 

of constraints, on enforcement policies, on enforcement operationalisation and on tolerance tactics and violation 

response. For this reason, data management also includes full specification for constraints. The classical way to 

map integrity constraints to procedures or triggers is an implementation decision. It burdens the user with DBMS 

internal representations, imposes specific procedures of integrity enforcement and might limit implementations (e.g., 

the optimiser from selecting better alternatives), and uses a specific solution that might not be available with other 

systems. Integrity should be enforced with application code if, not unless there is a penchant for walking close to this 

edge. 

(3) The Matter of Identity: Keys 

Identity of objects functionally relates objects to real world things. It is somehow a functional dependency between 

object attributes (or components) and things from the universe of discourse. We need to separate which things must 

be identifiable in a database from those for which we do not need any identification. Identifiable things may however 

later be counted based on their representation by objects in the database. Those things which must be identifiable have 

properties that provide their identification. This identification is then classically specified through keys. Key provide 

a simple addressing schema that guarantees logical access to the objects and the values for attributes of the object, 

e.g. by class name + (components or) attributes + values for those attributes. 

One of the supporting conceptions for DBMS is key inheritance. This key inheritance can be used for construction 

of more complex objects which interrelate objects. For simplicity of management we additionally require irreducibility 

of identification which leads to the concept of the minimal key. 

Good keys are natural (used in reality prior to database representation), stable (changing relatively seldom), 

and simple (for handling objects). If identification is an aim and not representable surrogate keys are used. They 

do not have a meaning (like EMP#); they just allow to distinguish objects. Surrogate keys also allow to resolve the 

competition among several minimal keys for a type. 

For instance, an entity type may specify several minimal keys at the same time. These keys must be used in an 

appropriate form. Which key is the most appropriate for linking objects is governed by the application and should not 

be limited by the DBMS. A formal criterion to prefer one minimal key over the other is the potential use for referring 

to objects. 

Often it is claimed that we must use an artificial key like the Object ID (OID) at the conceptual level. This 

OID does not have any meaning at this level and is thus completely senseless for the business process. It is an 

implementation concept 20 . The OID is a throwback to pointers and should not be confused with surrogate keys. 

20 Sometimes conceptual modelling languages like the entity-relationship modelling language are defined based on approaches from functional 

programming. Each object is then defined as a function. Whether an object is represented by a function is an implementation decision. It 

does not have any sense at the conceptual level. Moreover functional programming is one out of six styles of programming (procedural, functional, 

logical, parallel, object-oriented, set-based). It is sometimes appropriate, especially in the case of complete and rigid context-freeness. 

The proponents of functional programming overlook that the world is interrelated, intertwined and interdependent, i.e. far from being free of 

IS ADD


(4) Don’t Get Duped by Dupes: Duplicate Objects 

(5) The Key, the Whole Key and Nothing but the Key: Normalisation 

(6) Neither Distinct nor the Same: Entity Supertypes and Subtypes 

(7) Climbing Trees in SQL: Data Hierarchies 

(8) Not Worth Repeating: Redundancy 

(9) Will SQL Come to Order: Quota queries 

(10) What You Don’t Can hurtYou: Missing Data and Information 

5.6.13 Improving the Culture of Modelling 

Proper Namespaces 

formal data names. 

comprehensive data definitions. 

precise data integrity rules. 

Adequate Database Schemata 

Proper data structure. 

reasonable data orientation. 

Reasonable Data Orientation. 

Completely Documented Schemata 

robust data documentation. 

Proper Data Management 

acceptable data availability. 

adequate data responsibility. 

appropriate data recognition. 

5.6.14 Workflows for Data Management 

5.6.15 Workflows for Information Management 

5.6.16 Data Provenance for Coherent Data Deployment 

context. Functions are sometimes a nice vehicle for mathematical proofs. Objects may have at the beginning or even during implementation 

no properties and must use the object identifier. Then the nightmare starts (see, for instance, our first papers [BT92, BT95, SSW92, ST93] or 

the continuation [BT99, KR97, Sch94] of these investigations. 

IS ADD


5.7 Techniques for Knowledge Management


5.8 Theoretical Foundations of Data, Information and Knowledge Management 

5.8.1 Extract, Transform and Load Functionalisations based on Generic Functions 

5.8.2 Integration, Evolution and Migration of Data, Information and Knowledge 

5.8.3 Model Suites Supporting Scoping, Abstraction and Coexistence 

5.8.4 Generic Schemata, Functions, and Workflows


5.9 Technology for Information, Data and Knowledge Management 

5.9.1 Data Management Systems Support 

5.9.2 Master Data Management 

Master data is data that is shared across systems and used to classify transactional data. Managing master data is one 

of the most difficult, time consuming and expensive challenges facing IT professionals in enterprises today. Furthermore, 

based on what our customers tell us, there are few good solutions to the problem. Master data management is 

not a new problem. Enterprises have been struggling with it for some time. However, new global regulations such as 

Sarbanes-Oxley in the United States and Basel II in Europe and increasing interest in performance management have 

given it a new urgency. Why? Compliance and performance management both require consistent master data across 

an enterprise. In fact, master data management has become such a high priority that the Tower Group estimates that 

80 percent of enterprises have plans to centralize it. 

Without data integrity, transaction data cannot be analyzed or reported in a meaningful way. 

5.9.3 View Towers 

5.9.4 Content, Concept and Topic Management 

5.9.5 User Management 

IS ADD


5.10 Implementation of Data Management in Research Projects 

5.10.1 Establishment of Data Management 

Key Roles. 

To be successful, Data Management best practice must be implemented across the whole organization, under the 

guidance of a member of the Executive Board, i.e. the Data Management Champion. Other key roles are the Data 

Manager and the Data Stewards assigned to each key dataset. 

The following list of responsibilities may help organizations to establish these key roles and implement good Data 

Management policies and procedures. 

Data Preparation. 

At the same time, typical data mining and analysis application do not have data at the same level of granularity, at the 

same level of abstraction, within the same measuring environment, and within the same context such time or season 

context, weather context, spatial context and measurement context. 

The first category of problems can be resolved by suites of models. Many-layered models are successfully used 

in different areas of science and have led to very sophisticated exploration and reasoning techniques, e.g., the fivelayered 

model of the human heart [HLMN06]. 

The second category of problems can be resolved by data enhancement methods. The measurement, the context, 

the meta-data are explicitly modelled and extracted. These data are shuffled with the data massives that are used for 

data mining and analysis. 

5.10.2 Data Import and Export Forms 

5.10.3 Query and Answer Forms 


5.10.4 Pattern-Based Realisation of Data Management 

5.11 Implementation of Information Management in Research Projects 

5.11.1 User Life Cases and their Reflection in Data and Information Consumption 

5.11.2 User Profiling 

5.11.3 User (Task) Portfolio and Information Demand 

5.11.4 Information Procurement 

5.11.5 Information Delivery and Production 

5.12 Data Gardening and Management for Data Analysis 

5.12.1 Data Mining Approaches 

5.12.2 Data Mining Pattern 

5.12.3 Data Mining Facilitation 

IS ADD


5.13 Towards Knowledge Management in a Knowledge Web 

5.13.1 The Content Space, Topic Space and the Concept Space for Knowledge Management 

We apply the separation of the knowledge space for the user into the content space, the concept space and the topic 

space. We furthermore assume that the information space can be defined on top of the three spaces. In this case we 

can use the content management system approach that has already been used in our research group for a number of 

applications. Using this separation we define a knowledge chunk as data that represent content, topics, and concepts. 

This triptych has already been used for advanced content management. 

We generalise the approach of [7, 19, 37] an may now describe the knowledge chunk database through its rough 

database schema. The schema in Figure 21 displays the general structure. The main part of the schema is the triptych 

of concepts, content, and topics. 

Meta ✛ 


Term 

Auxiliary 

Schema 

Specified 

By 

Media 

❄ 

Object ✛ 

Suite 

Spec 

Ordered 

Tree 

❄ 

Definition 

Item 

❨ 

AcceptanceLevel 

✛ Community 

Context 

UsageProfile 

✛ 

✲ 

Language 

 

Specified 

OnTop 

❄ 

Media 

Type 

GivenBy 

Characterised 

Through 

✲ Structural ✛ 

Expression 

Definition 

Kind 

✯ Database Schema 

✲Content ✛ 

✲ 

✲ 

✻ 

Extension/ 

Foundation 

Typicality 

❄ 

✲ Kind 

of Definition 

Community 

Community 

Annotated 

Through 

Explains/ 

Depicted 

Concept 

✻ 

Shared 

Within 

❄ 

Ontology 

(0,n) 

(0,1) 

✻ Descriptor ✻ 

Preference 

Defined Time 

Through Usage Application 

Validity 

Restriction Context 

❄ 

KindOf 

Association 

✻ 

Used 

In 

Language 

✒ 

✲ 

❥ ❄ ✙ 

✛ 

Topic ✛ 

✯ 

Application✛ 

✻ 

Schema 

Context 

❄ 

✲Application 

Schema 

In 

Topic Map 

/ Space 

✒ 

Associated 

To 

✲ 

✒ 

Culture 

Association 

Type 

Application 

❘ Area 

✒ 

Abbildung 21: Main Schema for Content, Concept and Topic Databases representing Knowledge Chunks 

Used 

For 

5.13.2 Profiles and Portfolio of the User 



the mission of the WIS [30]. 

To characterize the users of a WIS we distinguish between education, work and personality profiles. The education 

profile contains properties users can obtain by education or training. Capabilities and application knowledge as a result 

of educational activities are also suitable for this profile. Properties will assigned to the work profile, if they can be 

associated with task solving knowledge and skills in the application area, i.e. task expertise and experience as well 

as system experience. Another part of a work profile is the interaction profile of a user, which is determined by his 

frequency, intensity and style of utilization of the WIS. The personality profile characterises the general properties 

and preferences of a user. General properties are the status in the enterprise, community, etc., and the psychological 

and sensory properties like hearing, motoric control, information processing and anxiety. 


IS ADD








conditions. 

5.13.3 Users Life Cases 

For task completion users need the right kind of data, at the right time, in the right granularity and format, unabridged 

and within the frame agreed upon in advance. Moreover, users are bound by their ability to verbalise and digest 

data, and their habits, practices, and cultural environment. To avoid intellectual overburdening of users we observe 

real applications before the system development leading to life cases [33]. Life cases help closing the pragmatic gap 

between intentions and storyboarding. They are used to specify the concrete life situation of the user and characterise 

thus a bundle of tasks the user should solve. Syntax and semantics of life cases have already been well explored in 

[30]. 




5.13.4 Requirements Issued by the User to Knowledge Web 

We may now summarise the knowledge delivery task of the Knowledge Web based on user-oriented and life-casebased 

content, concepts and topics as follows: 

Deliver the knowledge the user really needs through (1) concepts at the educational level level of the user 

that are illustrated and extended by (2) content which is quality content depending on the external and internal 

quality of the aggregated data (media object suite) and that are depicted by (3) topics in the language, in the 

culture and in the application portfolio of the user. 

The question is therefore whether such system is achievable and whether there is a chance to build it. We are 

going to sketch now a system proposal of [?] in the next chapter, refer for a proof of achievability based on generic 

generators to [?], and finally illustrate usefulness by a prototypical example in the last chapter. 

IS ADD


Literatur 

[aIU11] The Digital Science Center at Indiana University. http://pti.iu.edu/dsc, Accessed June 4, 2011. 

[BDM02] 

[BDT12] 

[Bea10] 

S. Browers, L. Delcambre, and D. Maier. Superimposed schematics: Introducing E-R structure for in-situ information selections. 

In S. Spaccapietra, S.T. March, and Y. Kambayashi, editors, Proc. ER’02, volume LNCS 2503, pages 90–104, Berlin, 2002. 

Springer. 

M. Berg, A. Düsterhöft, and B. Thalheim. Query and answer forms for sophisticated database interfaces. In Proc. EJC 2012, page 

..., Prague, 2012. 

Charles Beagrie. Ensuring perpetual access. 

http://www.allianzinitiative.de/fileadmin/hosting studie e.pdf, February 2010. 

[Ber11] Digital science community. http://www.digital-science.com/, Accessed June 4, 2011. 

[Boe06] B. Boehm. A view of 20th and 21st century software engineering. In Proc. ICSE’06, pages 12–29, ACM Press, 2006. 

[BT92] C. Beeri and B. Thalheim. Identification is well-founded in object-oriented databases. Manuscript, 1992. 

[BT95] 

[BT99] 

C. Beeri and B. Thalheim. Can I see your identification, please? - Identification is well-founded in object-oriented databases. 

Manuscript, Cottbus/Jerusalem, 1995. 

C. Beeri and B. Thalheim. Identification as a primitive of database models. In Proc. FoMLaDO’98, pages 19–36. Kluwer, London, 

1999. 

[Bur10] M. Burgin. Theory of Information. Fundamentality, Diversity and Unification. World Scientific Publishing Co, 2010. 

[Cuk10] K. Cukier. Data, data everywhere. The Economist, Feb 25th 2010. 

[Dem99] W.A. Dembski. Intelligent Design: The bridge between science and theology. Downers Grove, Ill.: InterVarsity Press, 1999. 

[DHT + 08] M. Duží, A. Heimburger, T. Tokuda, P. Vojtas, and N. Yoshida. Multi-agent knowledge modelling. In H. Jaakkola and Y. Kiyoki, 

editors, EJC’2008, Information Modeling and Knowledge Bases XVI. IOS Press, 2008. Panel summary, EJC 2008. 

[DI09] 

W.A. Dembski and R. J. Marks II. Life’s conservation law: Why darwinian evolution cannot create biological information. In 

B. Gordon and W. Dembski, editors, THE NATURE OF NATURE. Wilmington, Del.: ISI Books, 2009. 

[Dre95] H. Dreßler. Datenstrukturentwurf - Vom Faktenchaos zur Anwenderdatenbank. Oldenbourg-Verlag, München, 1995. 

[DT04] 

A. Düsterhöft and B. Thalheim. Linguistic based search facilities in snowflake-like database schemes. Data and Knowledge 

Engineering, 48:177–198, 2004. 

[Dub07] Dublin Core Metadata Initiative. Dublin Core. http://dublincore.org/, June 2007. 

[ES03] 

W. Elsberry and J. Shallit. Information theory, evolutionary computation, and dembski’s “complex specified information”? Synthese, 

178(2):237–270, 2003. 

[Fel90] C. Fellbaum. The english verb lexicon as a semantic net. International Journal of Lexicography, 3:278–301, 1990. 

[Fri10] K. Friston. The free-energy principle: a rough guide to the brain? Nature Reviews Neuroscience, 11:127–138, February 2010. 

http://www.nature.com/nrn/journal/v11/n2/abs/nrn2787.html. 

[FRT05] 

[FST98] 

[FT09] 

G. Fiedler, T. Raak, and B. Thalheim. Database collaboration instead of integration. In APCCM’05, volume 43 of CRPIT, pages 

49–58. Australian Computer Society, 2005. 

T. Feyer, K.-D. Schewe, and B. Thalheim. Conceptual design and development of information services. In Proc. ER’98, LNCS 

1507, Springer, 1998, pages 7–20. Springer, Berlin, 1998. 

G. Fiedler and B. Thalheim. Towards semantic wikis: Modelling intensions, topics, and origin in content management systems. 

Information Modelling and Knowledge Bases, XX:1–21, 2009. 

[GG00] C. Ghidini and F. Giunchiglia. Local models semantics, or contextual reasoning = Locality + compatibility. 

http://citeseer.ist.psu.edu/481285.html, April 2000. 

[Gua97] 

N. Guarino. Unterstanding, building and using ontologies: A commentary to “Using explicit ontologies in kbs development”, by 

van Heijst, Schreiber, and Wielinga. Int. Journal of Human and Computer Studies, 46:293–310, 1997. 

[Hef92] K. Hefner, editor. Evolution of Information Processing Systems. Springer, 1992. 

[Hena] 

[Henb] 

[Henc] 

[Hend] 

[Hene] 

http://www.v3.co.uk/v3-uk/news/2081263/cern-experiments-generating-petabyte. 

http://www.bell-labs.com/news/2006/october/shannon.html. 

www.nytimes.com/2010/07/20/technology/20kindle.html. 

https://www.ericssonmoney.com/content/GB/en.html. 

http://www.daopay.com/. 

[HLMN06] P. J. Hunter, W. W. Li, A. D. McCulloch, and D. Noble. Multiscale modeling: Physiome project standards, tools, and databases. 

IEEE Computer, 39(11):48–54, 2006. 

IS ADD


[HM03a] 

V. Haarslev and R. Möller. Racer: An OWL reasoning agent for the semantic web. In Proceedings of the International Workshop 

on Applications, Products and Services of Web-based Support Systems, in conjunction with the 2003 IEEE/WIC International 

Conference on Web Intelligence,? Halifax, Canada, October 13, pages 91–95, 2003. 

[HM03b] D. Harel and R. Marelly. Come, Let’s play: Scenario-based programming using LSCs and the play-engine. Springer, Berlin, 2003. 

[HMW05] V. Haarslev, R. Möller, and M. Wessel. Description Logic inference technology: Lessions learned in the trenches. In I. Horrocks, 

U. Sattler, and F. Wolter, editors, Proc. International Workshop on Description Logics, 2005. 

[HPSvH03] Ian Horrocks, Peter F. Patel-Schneider, and Frank van Harmelen. From SHIQ and RDF to OWL: The making of a web ontology 

language. Journal of Web Semantics, 1(1):7–26, 2003. 

[Jac07] M. Jackson. Problem Frames: Analysing and structuring software development problems. Pearson Education, Harlowe, 2007. 

[JI] Sungchul JI. Semiotics of life: Unified theory of molecular machines, cells, the mind, peircean 

signs, and the universe based on the principle of information-energy complementarity. 

http://grammars.grlmc.com/GRLMC/reports/SOLManuscriptsubmitted final.doc. 

[JRTF11] 

K. Jannaschk, C. A. Rathje, B. Thalheim, and F. Förster. A generic database schema for cidoc-crm data management. In ADBIS 

(2), volume 789 of CEUR Workshop Proceedings, pages 127–136. CEUR-WS.org, 2011. 

[JT03] H. Jaakkola and B. Thalheim. Visual SQL - high-quality er-based query treatment. In IWCMQ’2003, LNCS 2814, pages 129–139. 

Springer, 2003. 

[Kau67] 

R. Kauppi. Einführung in die Theorie der Begriffssysteme. Acta Universitatis Tamperensis, Ser. A, Vol. 15, Tampereen yliopisto, 

Tampere, 1967. 

[Kob05] A. Kobsa. User modeling and user-adapted interaction. User Modeling and User-Adapted Interaction, 15(1-2):185–190, 2005. 

[KR97] 

H.-J. Klein and J. Rasch. Value based identification and functional dependencies for object databases. In Proc. 3rd Basque Int. 

Workshop on Information Technology, pages 22–34. IEEE Computer Science Press, New York, 1997. 

[Kro05] J. Krogstie. Quality of uml. In Encyclopedia of Information Science and Technology (IV), pages 2387–2391. 2005. 

[KSTZ03] R. Kaschek, K.-D. Schewe, B. Thalheim, and Lei Zhang. Integrating context in conceptual modelling for web information systems, 

web services, e-business, and the semantic web. In WES 2003, LNCS 3095, pages 77–88. Springer, 2003. 

[KT12] 

Y. Kiyoki and B. Thalheim. Analysis-driven data collection, integration and preparation for visualisation. In Proc. EJC 2012, page 

..., Prague, 2012. 

[KZK + 10] Y. Kidawara, K. Zettsu, Y. Kiyoki, K. Jannaschk, B. Thalheim, P. Linna, H. Jaakkola, and M. Duzí. Knowledge modeling, 

management and utilization towards next generation web. In Information Modelling and Knowledge Bases XXI, volume 206, 

pages 387–402. IOS Press, 2010. 

[Lak87] 

G. Lakoff. Women, fire, and dangerous things - What categories reveal about the mind. The University of Chicago Press, Chicago, 

1987. 

[Len02] D. Lenat. The dimensions of the context space. www.cyc.com/context-space.pdf, 2002. 

[LTN07] S. Lightstone, T. Teorey, and T. Nadeau. Physical database design. Morgan Kaufmann, 2007. 

[Mac11] 

MacMillan. Digital science. 

http://international.macmillan.com/MediaArticle.aspx?id=2598, Accessed June 4, 2011. 

[MST05] T. Moritz, K.-D. Schewe, and B. Thalheim. Strategic modeling of web information systems and its impact on visual design 

patterns. In F. Frasincar, G.-J. Houben, and R. Vdovjak, editors, WISM’05, pages 5–13, Sydney, 2005. 

[MST09] 

Hui Ma, K.-D. Schewe, and B. Thalheim. Modelling and maintenance of very large database schemata using meta-structures. In 

UNISCON, volume 20 of Lecture Notes in Business Information Processing, pages 17–28. Springer, 2009. 

[Mur01] G. L. Murphy. The big book of concepts. MIT Press, 2001. 

[NuBT11] B. Neumayr and M. Schrefl und B. Thalheim. Modeling techniques for multi-level abstraction. In The Evolution of Conceptual 

Modeling, volume 6520 of Lecture Notes in Computer Science, pages 68–92, Berlin, 2011. Springer. 

[Ont12] Introductions to topic maps. http://www.ontopia.net/section.jsp?id=tm-intro, April 20, 2012. 

[OS04] 

D. Oberle and P. Spyns. The knowledge portal öntoweb“. In Handbook on Ontologies, International Handbooks on Information 

Systems, pages 499–516. Springer, 2004. 

[Pas00] F. Pascal. Practical Issues in Database Management: A Reference for the Thinking Practitioner. Addison-Wesley, 2000. 

[PPJ06] 

[RH05] 

[Sch94] 

Orrin H. Pilkey and Linda Pilkey-Jarvis. Useless Arithmetic: Why Environmental Scientists Cant’t Predict the Future. Columbia 

University Press, New York, 2006. 

Lawrence Reeve and Hyoil Han. Survey of semantic annotation platforms. In SAC ’05, pages 1634–1638, New York, NY, USA, 

2005. ACM Press. 

K.-D. Schewe. The specification of data-intensive application systems. Advanced PhD (Habilitation Thesis), Brandenburg University 

of Technology at Cottbus, Faculty of Mathematics, Natural Sciences and Computer Science, 1994. 

[Sha48] C. E. Shannon. A mathematical theory of communication. Bell System Technical Journal, 27:379–423, 623–656, 1948. 

IS ADD


[Sha93] C. E. Shannon. Collected Papers. IEEE press, 1993. 

[Sim07] G. Simsion. Data modeling - Theory and practice. Technics Publications, LLC, New Jersey, 2007. 

[Sno00] R. T. Snodgrass. Developing time-oriented database applications in SQL. Morgan Kaufmann, San Francisco, 2000. 

[Sow00] 

[SS99] 

John F. Sowa. Knowledge Representation, Logical, Philosophical, and Computational Foundations. Brooks/Cole, a division of 

Thomson Learning, Pacific Grove, California, 2000. 

J. W. Schmidt and H.-W. Schering. Dockets: a model for adding vaulue to content. In Proc. ER’99, volume 1728 of LNCS, pages 

248–262, 1999. 

[SSW92] K.-D. Schewe, J. W. Schmidt, and I. Wetzel. Identification, genericity and consistency in object-oriented databases. LNCS 646, 

pages 341–356, Berlin, Germany, Oct. 14 - 16, 1992, 1992. Springer, Berlin. 

[ST93] K.-D. Schewe and B. Thalheim. Fundamental concepts of object oriented databases. Acta Cybernetica, 11(4):49–81, 1993. 

[ST01] 

K.-D. Schewe and B. Thalheim. Modeling interaction and media objects. In M. Bouzeghoub, Z. Kedad, and E. Métais, editors, 

NLDB. Natural Language Processing and Information Systems, 5th Int. Conf. on Applications of Natural Language to Information 

Systems, NLDB 2000, Versailles, France, Jun 28-30, 2000, Revised Papers, volume 1959 of LNCS, pages 313–324. Springer, 2001. 

[ST04] K.-D. Schewe and B. Thalheim. Reasoning about web information systems using story algebra. In ADBIS’2004, LNCS 3255, 

pages 54–66, 2004. 

[ST05] K.-D. Schewe and B. Thalheim. Conceptual modelling of web information systems. Data and Knowledge Engineering, 54:147– 

188, 2005. 

[ST06a] 

[ST06b] 

[ST07a] 

[ST07b] 

[ST07c] 

K.-D. Schewe and B. Thalheim. Usage-based storyboarding for web information systems. Technical Report 2006-13, Christian 

Albrechts University Kiel, Institute of Computer Science and Applied Mathematics, Kiel, 2006. 

Klaus-Dieter Schewe and Bernhard Thalheim. User models: A contribution to pragmatics of web information systems design. In 

K. Aberer, Z. Peng, and E. Rundensteiner, editors, Web Information Systems – Proceedings WISE 2006, volume 4255 of LNCS, 

pages 512–523. Springer-Verlag, 2006. 

K.-D. Schewe and B. Thalheim. Development of collaboration frameworks for web information systems. In 20th Int. Joint Conf. 

on Artifical Intelligence, Section EMC07 (Evolutionary models of collaboration), pages 27–32, Hyderabad, 2007. 

K.-D. Schewe and B. Thalheim. Development of collaboration frameworks for web information systems. In IJCAI’07 (20th Int. 

Joint Conf on Artificial Intelligence, Section EMC’07 (Evolutionary models of collaboration), pages 27–32, Hyderabad, 2007. 

K.-D. Schewe and B. Thalheim. Life cases: An approach to address pragmatics in the design of web information systems. In 

J. Filipe, J. Cordeiro, B. Encarnacao, and V. Pedrosa, editors, Proc. WebIST, volume II (WIA), pages 5–12, 2007. 

[ST08] K.-D. Schewe and B. Thalheim. Semantics in data and knowledge bases. In SDKB 2008, LNCS 4925, pages 1–25, Berlin, 2008. 

Springer. 

[Sto90] T. Stonier. Information and the Internal Structure of the Universe. Springer, 1990. 

[SW05] G. Simsion and G.C. Witt. Data modeling essentials. Morgan Kaufmann, San Francisco, 2005. 

[SYea03] J.E. Safra, I. Yeshua, and et. al. Encyclopædia Britannica. Merriam-Webster, 2003. 

[TD01] 

B. Thalheim and A. Düsterhöft. Sitelang: Conceptual modeling of internet sites. In H. S. Kunii, S. Jajodia, and A. Sølvberg, 

editors, ER, volume 2224 of LNCS, pages 179–192. Springer, 2001. 


[Tha03] 

B. Thalheim. Visual SQL - An ER-based introduction to database programming. Technical Report Preprint I-8/2003, Institut für 

Informatik, BTU Cottbus, 2003. 

[Tha06] B. Thalheim. The conceptual framework to user-oriented content management. In EJC’06, Trojanovice, May 2006. 

[Tha07] B. Thalheim. The conceptual framework to user-oriented content management. Series Frontiers in Arificial Intelligence, 154, 

Information Modelling and Knowledge Bases, XVII:30–49, 2007. 

[Tha10] B. Thalheim. Towards a theory of conceptual modelling. Journal of Universal Computer Science, 16(20):3102–3137, 2010. 

http://www.jucs.org/jucs_16_20/towards_a_theory_of. 

[TK01] 

[TKKJ11] 

[Vis12] 

[VT02] 

B. Thalheim and T. Kobienia. Generating db queries for web nl requests using schema information and db content. volume 3 of 

LNI, pages 205–209. GI, 2001. 

B. Thalheim, Y. Kitawara, E. Karttunen, and H. Jaakkola. Future directions of knowledge systems environments for web 3.0. In 

Information Modelling and Knowledge Bases, volume XXII, pages 413–446. IOS Press, 2011. 

Visualsql: A tool for graphical query formulation; download website. http://www.informatik.uni-kiel.de/en/information-systemsengineering/miscellaneous/visualsql/, 

April 20, 2012. 

V. Vestenický and B. Thalheim. Flexible association of varieties of ontologies with varieties of databases. In Information Modelling 

and Knowledge Bases XIV, volume 94 of Fronties in Artificial Intelligence and Applications, pages 135–141. ISO Press, 2002. 

Proc. 12th European-Japanese Conf. on Information Modelling and Knowledge Bases, Krippen, Germany, May 2002. 

[W3C04a] W3C. Web Ontology Language Overview. http://www.w3.org/TR/owl-features/, Feb 2004. 

IS ADD


[W3C04b] W3C RDF Core Working Group. Resource Description Framework (RDF). http://www.w3.org/RDF/, 2004. 

[Wal05] C. Wallis. The evolution wars. Time Magazine, page 32, 15 Aug 2005. 

[Who80] B.L. Whorf. Lost generation theories of mind, language, and religion. Popular Culture Association, University Microfilms 

International, Ann Arbor, Mich., 1980. 

[WM02] R. Widhalm and T. Mück. Topic Maps: Semantische Suche im Internet. Springer, 2002. 

[WZ90] 

[Zus69] 

J.A. Wheeler and W. Zurek, editors. Information, physics, quantum: The search for links. Complexity, Entropy, and the Physics 

of Information. Addison-Wesley, Redwood City, CA, 1990. 

K. Zuse. Rechnender Raum. Friedrich Vieweg & Sohn, MIT Technical translation AZT-70-164-GEMIT, Massachusetts Institute 

of Technology (project MAC), Cambridge, Mass. 02139 edition, 1969. 

IS ADD


Weiterer Lesestoff 

Literatur 

[1] S. Akamine, Y. Kato, D. Kawahara, K. Inui, S. Kurohashi, and Y Kidawara. Development of a Large-scale Web Crawler and Search 

Engine Infrastructure. Proceedings of the 3rd International Universal Communication Symposium (IUCS2009), 126-131, 2009 

[2] M. Armbrust, A. Fox, R. Griffith, A. Joseph, R. Katz, A. Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoica, and M. Zaharia, Above The 

Clouds: A Berkeley View of Cloud Computing. Technical Report No. UCB/EECS-2009-28. EECS Department. University of California, 

Berkeley. 2009. 

[3] R.Buyya, C. Shin Yeo, and S. Venugopal, 2008. Market-Oriented Cloud Computing: Vision, Hype and Reality for Delivering IT Services 

as Computing Utilities. Proceedings of the 10th IEEE International Conference on High Performance Computing and Communications 

(HPCC-08, IEEE CS Press, Los Alamitos, CA, USA), Sept. 25-27, 2008, Dalian, China. 9p. 2008. 

[4] A. Dey, B. Kokinov, D. Leake, and R. Turner (Eds.). Modeling and using context. 5th International and Interdisciplinary Conference 

CONTEXT 2005. Springer. Berlin, 2005. 

[5] Dublin Core Metadata Initiative. Dublin Core. http://dublincore.org/, June 2007. 

[6] M. Duží, A. Heimburger, T. Tokuda, P. Vojtas, and N. Yoshida. Multi-agent knowledge modelling. In H. Jaakkola and Y. Kiyoki, editors, 

EJC’2008, Information Modeling and Knowledge Bases XVI. IOS Press, 2008. Panel summary, EJC 2008. 

[7] G. Fiedler and B. Thalheim. Towards semantic wikis: Modelling intensions, topics, and origin in content management systems. Information 

Modelling and Knowledge Bases, XX:1–21, 2009. 

[8] X. Fu, T. Bultan, and J. Su. Analysis of Interacting BPEL Web Services. Proce. of the 13th international conference on World Wide Web, 

pp. 621–630, 2004. 

[9] C. Ghidini and F. Giunchiglia. Local models semantics, or contextual reasoning = Locality + compatibility. 

http://citeseer.ist.psu.edu/481285.html, April 2000. 

[10] V. Haarslev and R. Möller. Racer: An OWL reasoning agent for the semantic web. In Proceedings of the International Workshop on 

Applications, Products and Services of Web-based Support Systems, in conjunction with the 2003 IEEE/WIC International Conference on 

Web Intelligence,Ê Halifax, Canada, October 13, pages 91–95, 2003. 

[11] V. Haarslev, R. Möller, and M. Wessel. Description Logic inference technology: Lessions learned in the trenches. In I. Horrocks, 

U. Sattler, and F. Wolter, editors, Proc. International Workshop on Description Logics, 2005. 

[12] T. Hey, S. Tansley, and K. Tolle. The Fourth Paradigm: Data-Intensive Scientific Discovery, Microsoft Research (2009). 

[13] Ian Horrocks, Peter F. Patel-Schneider, and Frank van Harmelen. From SHIQ and RDF to OWL: The making of a web ontology language. 

Journal of Web Semantics, 1(1):7–26, 2003. 

[14] H. Jaakkola, A. Heimbürger, and P. Linna. Knowledge-oriented software engineering process in a multi-cultural context. Software 

Quality Control. Vol 18 (2). pp. 299-319, 2010. 

[15] R. Kaschek, K.-D. Schewe, B. Thalheim, and Lei Zhang. Integrating context in conceptual modelling for web information systems, web 

services, e-business, and the semantic web. In WES 2003, LNCS 3095, pages 77–88. Springer, 2003. 

[Len02] D. Lenat. The dimensions of the context space. www.cyc.com/context-space.pdf, 2002. 

[16] J. Lewerenz, K.-D. Schewe, and B. Thalheim. Modeling data warehouses and OLAP applications by means of dialogue objects. In Proc. 

ER’99, LNCS 1728, pages 354–368. Springer, Berlin, 1999. 

[17] R. Lewis. The Cultural Imperative. Global Trends in the 21st Century. Intercultural Press. Brealey. Printed in Finland. 338p., 2007. 

[18] T. Moritz, K.-D. Schewe, and B. Thalheim. Strategic modelling of web information systems. International Journal on Web Information 

Systems, 1(4):77–94, 2005. 

[19] G. L. Murphy. The big book of concepts. MIT Press, 2001. 

[20] T. Nakanishi, H. Homma, K.-S. Kim, K. Zettsu K., Y. Kidawara, and Y. Kiyoki. A Three-layered Architecture for Event-centric Interconnections 

among Heterogeneous Data Repositories and its Application to Space Weather. Proc. of the 20th European Japanese 

Conference on Information Modelling and Knowledge Bases, EJC 2010, Jyväskylla, Finland, pp. 29–44, 2010. 

[21] T. Nakanishi, K. Zettsu, , Y. Kidawara, and Y. Kiyoki. A Context Dependent Dynamic Interconnection Method of Heterogeneous Knowledge 

Bases by Interrelation Management Function, In Proc. of the 19th European-Japanese conference on information modelling and 

knowledge bases, EJC 2009, pp. 210-227, 2009. 

[22] , T. Nakagawa, K. Inui, and S. Kurohashi. Dependency Tree-based Sentiment Classification using CRFs with Hidden Variables. Proc. 

of Human Language Technologies: The 11th Annual Conference of the North American Chapter of the Association for Computational 

Linguistics (HLT-NAACL 2010), 2010 

[23] NGG: Next Generation Grids Expert Group. Future of European Grids: Grids and Service- Oriented Knowledge Utilities. Report 3, 2006. 

[24] M.P. Papazoglou, and D. Georgakopoulos. Service-Oriented Computing. Communications of the ACM Vol. 46, No. 10, pp. 24–28, 2003. 

[25] L. Reeve and H. Han. Survey of semantic annotation platforms. In SAC ’05, pages 1634–1638, New York, NY, USA, 2005. ACM Press.


[26] M. Rönkkö, J. Ylitalo, J. Peltonen, N. Koivisto, O. Mutanen, J. Autere, A. Valtakoski, and Pentikäinen, National Software Industry 

Survey 2009. Helsinki University of Technology. Helsinki. 128 p., 2009 

[27] J.E. Safra, I. Yeshua, and et. al. Encyclopædia Britannica. Merriam-Webster, 2007. 

[28] K.-D. Schewe and B. Thalheim. Reasoning about web information systems using story algebra. In ADBIS’2004, LNCS 3255, pages 

54–66, 2004. 

[29] K.-D. Schewe and B. Thalheim. The co-design approach to web information systems development. International Journal of Web 

Information Systems, 1(1):5–14, March 2005. 

[30] K.-D. Schewe and B. Thalheim. Usage-based storyboarding for web information systems. Technical Report 2006-13, Christian Albrechts 

University Kiel, Institute of Computer Science and Applied Mathematics, Kiel, 2006. 

[31] K.-D. Schewe and B. Thalheim. Usage-based storyboarding for web information systems. Technical Report 2006-13, Christian Albrechts 

University Kiel, Institute of Computer Science and Applied Mathematics, Kiel, 2006. 

[32] K.-D. Schewe and B. Thalheim. Development of collaboration frameworks for web information systems. In 20th Int. Joint Conf. on 

Artifical Intelligence, Section EMC07 (Evolutionary models of collaboration), pages 27–32, Hyderabad, 2007. 

[33] K.-D. Schewe and B. Thalheim. Life cases: A kernel element for web information systems engineering. In Web Information Systems and 

Technologies, volume Volume 8. Lecture Notes in Business Information Processing, Springer Berlin Heidelberg, 2008. 

[34] K.-D. Schewe and B. Thalheim. User models: A contribution to pragmatics of web information systems design. In K. Aberer, Z. Peng, and 

E. Rundensteiner, editors, Web Information Systems – Proceedings WISE 2006, volume 4255 of LNCS, pages 512–523. Springer-Verlag, 

2006. 

[35] K.-D. Schewe and B. Thalheim. Semantics in data and knowledge bases. In SDKB 2008, LNCS 4925, pages 1–25, Berlin, 2008. Springer. 

[36] John F. Sowa. Knowledge Representation, Logical, Philosophical, and Computational Foundations. Brooks/Cole, a division of Thomson 

Learning, Pacific Grove, California, 2000. 

[37] B. Thalheim. The conceptual framework to user-oriented content management. Information Modelling and Knowledge Bases, XVII:30– 

49, 2007. 

[38] W3C. Web Ontology Language Overview. http://www.w3.org/TR/owl-features/, Feb 2004. 

[39] W3C RDF Core Working Group. Resource Description Framework (RDF). http://www.w3.org/RDF/, 2004. 

[40] L. Youseff, M. Butrico, and D. Da Silva. Toward a Unified Ontology of Cloud Computing. Grid Computing Environments Workshop, 

GCE ’08, pp.1-10, 2008. 

Youseff, L.; Butrico, M.; Da Silva, D.; , Toward a Unified Ontology of Cloud Computing. Grid Computing Environments Workshop, 2008. 

GCE ’08 , vol., no., pp.1-10, 12-16 Nov. 2008 

[41] S. Xu and W. Zhang. Knowledge as a Service and Knowledge Breaching. Proceedings of the 2005 IEEE International Conference on 

Services Computing. Vol 01. pp. 87-94, 2005. 

[42] K. Zettsu, T. Nakanishi, M. Iwazume, Y. Kidawara, and Y. Kiyoki. Knowledge Cluster Systems for Knowledge Sharing, Analysis and 

Delivery among Remote Sites. Information Modeling and Knowledge Bases, Vol. XIX, IOS Press, pp.282–289 (2008). 

[43] K. Zettsu, Y. Kidawara, and Y. Kiyoki. Developing Next Generation Web as Collaboration Media. Infocommunications Journal, Vol. 

LXV., No. 2010/I, pp.15–19, Scientific Association for Infocommunications, Hungary, 2010.






D - 24098 Kiel 

 





6. Interaktivität ab SS 2012 


Forschung 



6 Spezifikation der Interaktivität 

Greift nur hinein ins volle Menschenleben! 

Ein jeder lebts, nicht vielen ists bekannt, 

Und wo Ihrs packt, da ists interessant. 

In bunten Bildern wenig Klarheit: 

So wird der beste Trunk gebraut, 

Der alle Welt erquickt und auferbaut. 

Goethe, Faust, Erster Teil, Vorspiel auf dem Theater, Lustige 

Person 

6.1 Story Spaces 

KDS 3.1 

außerdem einarbeiten: WebIS.ESFworkshop260911talkSCCH 

6.1.1 Der Story-Raum, Szenen, Dialogschritte und Szenario 

Wir unterscheiden zwischen dem Teil eines Systemes, der für den Benutzer sichtbar ist, und dem internen Teil eines 

Systemes, der für den Benutzer nicht sichtbar gemacht werden muß. Nach Wegner’s Theorie der interaktiven Maschinen 

werden damit unterschiedliche Aspekte erfaßt. Interaktive Maschinen stellen die Interaktion eines Benutzers 

dar. Sie unterliegen anderen Paradigmen als klassische Berechnungssysteme: 

Input-Output-Ströme: Ein Benutzer reagiert auf den Output eines Systemes mit seiner Antwort. 

Beobachtungen, Glauben, Bedürfnisse, Intentionen und Aufgaben eines Akteurs bestimmen die Interpretation 

des beobachteten Output des Systemes mit. 

• Damit besitzt die Antwort des Akteurs auf den beobachteten Output eine intensionale Logik.

CAU zu Kiel, IfI, ISE, β 6. Interaktivität ab SS 2012 628 

• Ein Akteur stellt die Beobachtung zu den Aufgaben in Beziehung, die er gerade lösen möchte. 

• Der Output wird mit einer Umgebung bzw. einen Kontext im allgemeinen in Beziehung gesetzt. 

Damit wird durch den Akteur eine andere Beziehung eingegangen als dies bei der Modellierung von algorithmischen 

Systemen üblich ist. Mensch-Maschinen-Schnittstellen erfordern deshalb eine explizite Berücksichtigung folgender 

Parameter: 

Beobachtetes Verhalten: Die Beobachtungen bestimmen die Sicht des Akteurs auf das System. 

Interpretiertes Verhalten: Ein Akteur interpretiert das Verhalten des Systemes. 

✛ 

IO- 

Interface 

Anwend.- 

system 

❄ 

✛ 

✙ ❥✙ 

Benutzer A 

Anwend.- 

IO- ✲ ✲ 

system ❥✛ ✛ Interface 

Benutzer A 

❄ ✲ ✲ 

✲ 

Algorithmische 

Berechnung 

Benutzer A 

✲ 

Nichtalgorithmisches Verhalten des Akteurs: Das Verhalten eines Akteurs ist meist nicht algorithmisch beschreibbar. 

Sequentielle 

Interaktion 

✛ ✛ 

Benutzer A 

❄ ✲ ✲ 

7✛ 

Anwend.- 

IO- 

✙system 

Interface 

✲ ✲ 

❥✙ 

Benutzer B 

❥✛ ✛ 

❄ 

Mehrstrom- 

(konkurrierende) 

Interaktion 

Benutzer A 

✲ ✲ 

Abbildung 1: Algorithmisches Verhalten versus Mensch-Maschine-Verhaltes eines oder mehrerer Akteure 

In Bild 1 vergleichen wir das algorithmische Verhalten eines Systemes in der klassischen Vorstellung mit der 

sequentiellen Interaktion, bei der auch das System ohne Benutzerinteraktion seinen Zustand ändert, wobei diese 

Änderung ggf. auch für einen Benutzer nicht mehr verstehbar oder nachvollziehbar ist. Das Verhalten wird noch 

weniger einsichtig, wenn das System seinen Zustand aufgrund einer Interaktion mehrerer Benutzer ändert. In letzteren 

Fall kann dadurch das Verhalten eines Systemes für den Einzelbenutzer zufällig oder chaotisch aussehen, obwohl das 

System selbst deterministisch ist. 

Wir unterscheiden deshalb in Bild 2 zwischen 

dem Systemraum, der das Systemverhalten widerspiegelt und für den wir das erweiterte ER-Modell zur Spezifikation 

verwenden, und 

dem Interaktionsraum, der den Content des Benutzers enthält, auf einer Begriffs-, Konzept- oder Content-Algebra 

aufsetzt, aber einer anderen Logik unterliegt. 

Der Interaktionsraum setzt in unserem Verständnis auf dem Systemraum auf, erweitert diesen jedoch um Benutzeraspekte. 

Wir fassen diesen Spezifikationsansatz in der Sprache SiteLang zur Entwicklung von Storyboards zusammen. 

Wir führen dazu weitere Begriffe ein: 

Der Story-Raum widerspiegelt die Menge aller Stories. Der Story-Raum besteht aus Szenen und markierten Transitionen 

zwischen diesen Szenen. 

Eine Story stellt einen Handlungsstrom mit allen seinen Varianten dar. 

Ein Szenarium ist ein Durchlauf durch eine Story, d.h. ein “Objekt” einer Story, wenn wir die Story als Klasse 

auffassen. 

Web IS



Systemraum 

i.a. 

(Zeit-, Raum-) beschränkt 

Berechenbare Funktion 

Systemraum: 

(H)ERM-Strukturierung 

(H)ERM-Funktionalität 

(H)ERM-Logik 

Interaktionsraum: 

Content 

Content-Algebra 

Deontischer Situationskalkül 

Abbildung 2: Der Interaktionsraum verglichen mit dem Systemraum 

Szenario stellen ein Bündel oder einen Pfad von Durchläufen dar. Szenario können zu einer Story zusammengefaßt 

werden. Innerhalb eines Story-Raumes können viele Stories realisiert werden. Neben den Stories können auch 

Nebenstories und Hauptstories spezifiziert werden. 

Eine Story besteht aus Szenen, in denen Akteuren ihre Content-Suite in ihrem Repräsentationstil und in Abhängigkeit 

von ihrem Kontext dargestellt wird. 

Der Akteur stellt eine Gruppe von Benutzern in abstrakter Form dar. 

Eine Szene besteht aus Dialogschritten, in denen die zugelassenen Akteure bestimmte Aktionen unternehmen. 

Die Markierung von Szenen wird beschrieben durch Ereignisse oder Aktivitäten für den Übergang von einer 

Szene zur nächsten, durch die involvierten Akteuere, durch Vor- und Nachbedingungen für die Nutzung der 

Szene, durch die Priorität der Transition, durch die Häufigkeit und durch die Anzahl der Wiederholungen. 

Dialogschritte sind beschrieben durch die Sichten auf die Content-Objekte, die Manipulationsanforderungen, die 

zugelassenen Operationen, die Vorbedingung, eine Abschlußbedingung und die Ereignisse, die zum Schritt 

führen, sowie die agierenden Akteure der Szene. 

Formal können wir diese Begriffe von SiteLang wie folgt einführen: 

Der Story-Raum ist ein gerichteter, bewerteter Graph bestehend aus Szenen und den Transitionen zwischen den 

Szenen, d.h. 

Story-Raum = ({ Szene }, E, λ, κ) 

E ⊆ { Szene } × { Szene } 

λ : { Szene } → SzeneBeschreibung 

κ : E → TransitionBeschreibung 

TransitionBeschreibung ⊆ 

(Ereignisse ∪ Aktivitäten) × Akteure × Vorbedingung × Nachbedingung × 

Priorität × Häufigkeit × Wiederholrate 

Eine Szene besteht aus Dialogausdrücken, dem Content, einer Darstellung der Akteure, einer Repräsentation und 

dem Kontext, d.h. 

Szene = ( SzeneID , 

DialogueSchrittAusdruck , 

Content-Suite, 

Akteure ( 

AkteurID, 

Rechte, 

Aufgaben( 

Web IS


Zuordnung, 

Rolle ) ), 

Repräsentation (Stil, Defaultwerte, Betonung, ...), 

Kontext (Hardware, Software, Kanal, Intention)) 

Web IS


6.1.2 Datenbank-Unterstützung für den Story-Raum 

Es sind verschiedene Repräsentationen für Szenen und Dialogschritte möglich. Für komplexere Anwendungen ist 

eine Datenbankablage der Elemente von SiteLang wünschenswert. Dies kann durch eine Struktur wie in Bild 3 

erfolgen. Damit sind dann auch in einfacher Form einzelne Schritte eines Szenario abwandelbar, ohne im Detail alle 

Strukturen, Oberflächen und Prozesse durchmustern zu müssen. 

((aktiv.ElementVon.Dialogausdruck)✶basiertAuf)[Szene] ⊆ aktiv.involviert[Szene] 

Story ✛ ✲ 

fußtAuf 

Repräsentationsstil 

Aktivitätenfolge 

✻ 

Event 

Condition 

Do 

AcceptCondition 

✻ 

Element 

von 

❄ 

✛ 

✛ 

Plattform 

basiertAuf 

aktiv 

❄ 

Kontext 

(1,1) 

Umstände 

Kanal 

✲ 

✲ 

ID 

❄ 

Szene 

✻ 

involviert 

❄ 

Akteur 

❄ 

✛ 

(1,1) 

∨(1,n) 

Benutzung 

Emphasis 

✿ 

nutzt 

Rechte 

Default 

Rollenkategorie 

✲ 

Aufgabenzuordnung 

❄ 

Aufgabe 

Obligation 

✲ 

✿ 

✲ 

✲ 

Rechtekategorie 

Content- 

Objekt 

Dialogschrittausdruck 

Dialogschritt 

ID 

Ausrüstung 

Gruppe 

Profil 

Abbildung 3: Repräsentation der Elemente von SiteLang 

Der Vorteil dieser Abbildung des Story-Raumes liegt auf der Hand: Es können Änderungen jederzeit in einfacher 

Form eingebracht werden, ohne sich direkt auf die gesamte Prozeßwelt auszuzwirken. 

Das Ausspiel der Oberfläche wird durch entsprechende XML-Architekturen besonders unterstützt. In diesem Fall 

kann mit einer Architektur nach dem Zwiebelprinzip in Bild 4 vorgegangen werden. Mit dieser Generierung erreicht 

man nicht nur eine höhere Flexibilität, sondern auch eine Vereinfachung der gesamten Anwendung.


Präsentationsmaschine 

Container-Generator 

Content-Objekt-Generator 

Sichten-Generator 

Datenbanksystem 

DBMS 

... 

virtuelle/materialisierte Retrievalund 

Modifikationssichten 

Funktionen für Überblick, Indexierung, Ein-/Ausgabe, 

Navigation, Integration in andere Komponenten 

Service-Pakete, Verpackungsfunktionen , 

Funktionen für Dialogszenen und Szenario 

Adaption an Akteure, Ausrüstung, Kanal etc.; 

Erweiterung um Dekomposition, Historie und Stil 

Abbildung 4: Der Zwiebelzugang zur Generierung der Oberflächen von Anwendungen 

6.1.3 Direktdarstellung des Story-Raumes 

Eine Datenbank-Unterstützung ist nicht in jedem Fall für den Story-Raum notwendig. Wir können auch anstelle einer 

vollständigen Datenbank direkt die folgenden OLAP-Elemente betrachtet werden, die z.T. allerdings redundante 

Informationen enthalten: 

Dialogszene: In einer Dialogszene werden die involvierten Akteure, das genutzte Content-Objekt und die Dialogschritte 

beschrieben. 

Dialogschritt: Ein Dialogschritt ist die kleinste Story-Einheit. Sie erlaubt die Darstellung der Retrieval-Sichten, 

der bereitgestellten Funktionen, einer Einschränkung der involvierten Akteure auf aktive Akteure und einer 

Steuerspezifikation mit 

Ereignissen, die zum Aufsuchen dieses Dialogschritts führen, 

Bedingungen, unter denen der Dialogschritt ausgeführt werden kann, und 

Beendigungsbedingungen, mit denen eine explizite Kontrolle realisiert werden kann, so daß ein Dialogschritt 

erst beendet werden kann, wenn eine bestimmte Konsistenz erreicht ist. 

Szenario: Der Story-Raum erlaubt eine Vielzahl von Durchläufen. Da in einer Anwendung nur einige Durchläufe 

von Interesse sind, spezifizieren wir die Hauptdurchläufe durch Szenario. Szenario sind i.a adaptierbar an 

die Benutzung, an die direkten Benutzer, deren Anwendungskontext und deren Benutzungshistorie. Dies wird 

durch eine Parametrisierung erreicht. 

Szenarium: Jedes Szenario enthält aufgrund der Parametrisierung eine Vielzahl von Durchläufen. Ein konkreter 

Durchlauf wird durch eine Wertezuweisung an alle Parameter zu einem Szenarium. 

Diese Direktspezifikation wird insbesondere für Informationssysteme angewandt, deren Präsentationssystem nicht 

generiert werden soll. Mit einer redundanten Entwicklung von Elementen ist die Einführung von Identifikatoren für 

die Elemente sinnvoll. 

Dialogschritte können spezifiziert werden durch Tabellen der folgenden Form: 

Web IS


Dialogschrittname 

on event Vorbedingung Content-Objekt zugelassene 

Operationen 

Akteur 

.... .... ... .... .... .... .... .... 

Es sind auch graphische Repräsentationen wie in Bild 5 sinnvoll. 

zugelassene Manipulationsoperationen 

Dialogschritt 

Dialogszene 

Steuerung(Ereignis,Vorbedingung,Akzeptanzbedingung) 

❄ 

Content-Objektsicht ✲ 

nächster 

Dialogschritt 

Manipulations- 

✲ 

zugelassene 

Operation ✿ 

operation 

✻ 

zugelassener Akteur 

Transition nach 

❯ Dialogsschrittausdruck 

accept on 

✻ 

✻ ✻ ✻ ✻ 

Akteure (Rechte, 

Aufgaben (Zuordnung, 

Rolle)) 

Szenenabfolge 

Transition 

Content- 

Object 

Repräsentationsstil 

Kontext, 

Aufgabe 

Abbildung 5: Sichtenstern für eine Dialogszene mit entsprechenden SiteLang-Elementen 

6.1.4 Der Spezifikationsrahmen für Dialogschritte 

Die Spezifikation der einzelnen Dialogschritte wird in sechs Dimensionen aufgefächert: 

Die Intentionen der einzelnen Dialogschritte folgen der allgemeinen Mission der Anwendung und werden durch 

entsprechende Metaphorik gut unterstützt. 

Der Story-Raum wird durch die Handlungsverläufe der Anwendung bestimmt. Er zerfällt in Szenen, die wiederum 

in Dialogschritte zerlegt werden. 

Die Spezifikation der Benutzung basiert auf einer Darstellung der Akteure, ihrer Rollen, Rechte und Verantwortlichkeiten, 

sowie der Präsentation. 

Der Content der einzelnen Dialogschritte wird durch eine Content-Objekt-Suite bestimmt. 

Die unterstützende Funktionalität für die einzelnen Dialogschritte wird auf der Funktionalität der Content-Typen 

aufgesetzt. 

Der Kontext der einzelnen Dialogschritte wird durch den Kontextraum determiniert. 

Diese sechs Dimensionen können in Zusammenhag mit dem Zachman-Spezifikationsrahmen gestellt werden. Wir 

unterschieden vier Hauptdimensionen für jeden Dialogschritt: 

die zugelassenen Akteure des Dialogschrittes, 

die Einbettung in den Story-Raum, 

die bereitgestellten Content-Objekte und 

Web IS


der Zeitrahmen für die Absolvierung des Dialogschrittes. 

Diese Hauptdimensionen sind in Bild 6 graphisch mit ihren Assoziationen skizziert. 

Intention 

Aufgaben 

Rollen, Verantwortlichkeiten 

Zeitbeschränkungen, Ablauf 

Dialogschritt 

Akteur 

Gemeinsame 

Öffentliche 

Private 

Zeitrahmen 

Content-Objekte 

Art 

Existenz, Gültigkeit 


Content 

Räume 

Arbeitsresultate 

Abbildung 6: Der Spezifikationsrahmen für Dialogschritte 

Die Assoziationen werden gleichzeitig mit dem Rahmen dargestellt. So sind z.B. Content-Objekte mit Akteuren 

assoziiert. Sie können öffentlich sein, von Akteuren gemeinsam benutzt werden oder auch privat sein. Akteure 

beteiligen sich in Dialogschritten in unterschiedlichen Rollen und Verantwortlichkeiten. Die Content-Objekte werden 

als Content-Suite mit einer entsprechenden Funktionalität bereitgestellt. Für Arbeitsgruppen sind Dokumente 

und Arbeitsräume typische Content-Objekte. Die Content-Objekte sind ggf. nicht dauerhaft gültig und können erzeugt, 

modifiziert und gelöscht werden. Die Dialogschritte werden zur Bewältigung von Aufgaben mit bestimmten 

Intentionen benutzt. 

Als typisches Beispiel kann die Untersetzung des Spezifikationsrahmens für Dialogschritte von Arbeitsgruppen- 

Sites wie in Bild 7 angesehen werden: 

Die Akteure sind Arbeitsgruppenmitglieder, Arbeitsgruppenleiter und -verantwortliche, insbesondere Administratoren. 

Der Story-Raum besteht aus einer Reihe von Dialogschritten wie z.B. dem Zusammenarbeitsschritt. 

Die Content-Objekte, z.B. die Gruppendokumente, können auch spezielle Dokumente wie Tagesordnungen, allgemeine 

Nachrichten oder persönliche Mitteilungen sein. Öffentliche Dokumente werden in Wandzeitungen etc. 

veröffentlicht. Dokumente können verpackt und entpackt, editiert oder auch nur gelesen werden. Es werden 

den Mitgliedern eigene Arbeitsräume, z.B. Schreibtische und persönliche Speicher, zur Verfügung gestellt. 

Der Zeitrahmen wird durch die Zusammenarbeit der Arbeitsgruppe vorgegeben. 

Der Spezifikationsrahmen für einen Beitrag eines Arbeitsgruppenmitgliedes wird in Bild 8 vorgestellt: 

Die Akteure sind diesmal Mitglieder einer Redaktionskommission. Sie erstellen, kommentieren und lesen gemeinsame 

Beiträge. 

Der Story-Raum umfaßt z.B. den Dialogschritt einer Beitragserstellung. 

Die Content-Objekte sind Beiträge. Sie werden mit der üblichen Funktionalität wie bei Texteditiersystemen unterstützt. 

Die Beiträge können abgelegt, zwischengespeichert oder auch gelöscht werden. 

Der Zeitrahmen wird durch den Aufgabenbereich der Redaktionsgruppe diktiert. Dokumente, die keine Endfassung 

darstellen, werden nach der Redaktionsperiode gelöscht oder ggf. archiviert. 

Der Spezifikationsrahmen ist eine Verallgemeinerung der Theorie der Wortfelder. 

Web IS


Leiter 

Kooperation Vollständiges Dokument 

Intention Aufgaben 

Mitglied 

Deadline 

Rollen, Verantwortlichkeit 

Zeitbeschränkung, Ablauf 

Moderator 

Phase 

Arbeitet mit 

Arbeitsgruppenmitglied 

Zeitintervall 

Gemeinsame 

Wandzeitung Öffentliche 

Gruppendokumente 

Art 

Existenz, Lebensspanne 

Schreibtisch Privat 

Persönlicher Speicher Funktionalität Content 

Editieren 

Durchmustern 

Meinung 

Ent-/Verpacken 

Antwort 

Räume Arbeitsresultate 

Klub Archiv Report Programm 

Protokoll 

Diskussionsraum 

Abbildung 7: Der Spezifikationsrahmen für Arbeitsgruppen-Sites 

Unterstützung der Arbeitsgruppe Einreichen 

Intention 

Aufgabe 

Mitglied 

Deadline 

Rollen, Verantwortlichkeiten 

Zeitbeschränkungen, Ablauf 

Einreichen eines Beitrages 

Phase 

Erstelle Beitrag 

Redaktionskommissionsmitglied 

Redaktionsperiode 

Gemeinsame 

Beiträge anderer 

Beitrag 

Art 

Existenz, Gültigkeit 

Beiträge zum Durchmustern 

Arbeitsraum Private 

Persönlicher Speicher Funktionalität Content 

Schreiben 

Einreichen 

Revidieren 

Download der letzten Version Raum Arbeitsresultate 

Diskussion der Beiträge 

Durchmustern vorhandener Beiträge Diskussionsraum 

Beitrag 

Abbildung 8: Der Spezifikationsrahmen für Beiträge von Arbeitsgruppenmitgliedern 

Web IS


6.1.5 Die detaillierte Spezifikation der Dialogschritte und Dialogszenen 

Eine vollständige Beschreibung der Dialogschritte kann mit dem Arbeitsblatt erstellt werden. 

Dialogschritt 

header 

Name 

Titel 

Container 

Inhalt 

Text 

multimedia object 


Anpassungsstil 

Einordnung in Hierarchien 

Adhäsion 

Adaptation 

Interaktionsstil 

Steuerungstil 

involvierte Akteure 

Layout 

Graphik 

Bild 

Video 

Audio 

Operationen 

algorithmisches Objekt 

Oft wird eine vollständige Beschreibung schwierig. Deshalb können wir eine Beschreibung gliedern in 

obligatorische Bestandteile, deren Spezifikation unbedingt erforderlich ist, 

weitere sinnvoll Bestandteile, (good practice) deren Spezifikation der weiteren Bearbeitung zugute kommt und die 

in einer Spezifikation nicht fehlen sollten, 

optionale Bestandteile, die eine Beschreibung sinnvoll ergänzen, aber die nicht für den Abschluß der Spezifikation 

erforderlich sind, und 

nützliche Bestandteile, die eine Einordnung und eine Beschreibung des Kontextes erlauben. 

Diese Untergliederung erscheint auf dem ersten Blick als überfrachtet. Da in der Praxis Entwicklungsgruppen sehr 

häufig innerhalb kurzer Zeiträume wechseln bzw. je nach Projektetappe nur für eine kurze Zeit existieren, ist eine 

gute, alle Aspekte umfassende Dokumentation erforderlich. 

Eine Beschreibung der Dialogszenen, in denen diese Untergliederung vorgenommen ist, wird im folgenden Arbeitsblatt 

angegeben: 

Web IS


Szene 

header 

Inhalt Name Entwickler copyright 

Problemgebiet Motivation Source 

Lösung Intention auch bekannt als siehe auch 

Variante 


Anwendung 

Anwendbarkeit 

Konsequenzen der Anwendung 

Beispieleinsatz 

angewandt in Anwendungen 

Benutzbarkeitsprofil Erfahrunsberichte DBMS 

Beschreibung 

Strukturierung: Funktionalität: Interaktivität: Kontext: 

Struktur, statische IC Operationen, dynamische 

IC, Erzwingungsstrategien 

Story-Raum, Akteure, 

Content-Objekte, Repräsentation 


Implementation Programmkode assoziierte Szenario 

assoziierte Szenen Kollaboration Integrationsstrategie 

obligatorisch good practice optional nützlich 

Aufgaben, Intention, Geschichte, 

Umgebung, Ziele 

Ein Szenario ist z.B. in Bild 9 beschrieben. 

Haupt-Story (z.B. als Folge von Szenen) 

Szenario (Ausschnitt des Story-Raumes ) mit/ohne Seitenpfade 

✲ ✲ 

Seitenpfad mit 

✻ 

partieller Veränderung des Szenariums 

❄ 

2 ✾ 

sc 1 ✲ sc 2 ✲ sc 3 ✲ sc 4 ✲ sc 5 ✲ ... 

Abbildung 9: Szenario in einem Story-Raum 

Ein Szenario ist durch eine Zuweisung von Werten an die Parameter konkretisiert. Damit wird das Szenario für 

einen Benutzer zu einem Szenarium, das dieser durchläuft. Mit der Zuordnung eines konkretisierten Szenario zu 

einem Benutzer wird damit auch der Akteur personalisiert. 

Die Adaption der Elemente des Story-Raumes an einen konkreten Durchlauf kann durch den Aufbau von Sitzungsobjekten 

in der folgenden Form erfolgen. Sitzungsobjekte selbst verfügen wiederum über eine Historie und 

erlauben damit eine Aufzeichnung der Historie der Benutzung durch einen Akteur. 

Ein Beispiel einer Lernszene wird in Bild 10 dargestellt. Ein Lehrstuhl erarbeitet das Lehrveranstaltungsangebot 

gemeinsam. Dabei existieren zwei Einwahlstränge, die parallel ablaufen: die Planung von Vorlesungen mit den 

Übungen etc. und die Erarbeitung eines Seminarvorschlages. Bei der Planung von Vorlesungen kann man auswählen, 

ob eine Anforderung bearbeitet wird oder ob ein neuer Kurs erarbeitet wird. 

Bei der Eingabe von Daten kann man auch auf alte, historische Daten zurückgreifen. Analog kann auch ein Mitarbeiter 

eines Lehrstuhles seine Arbeitsaufgaben diskutieren. Am Ende werden die Daten durch den Lehrstuhlleiter 

eingereicht. 

Eine analoge Szene können wir auch generisch entwickeln. Eine Suchszene in einer Webseite muß unterschiedliche 

Facetten der Suche darstellen: 

• Die eigenschaftsbasierte Suche orientiert sich auf Haupteigenschaften, die auch als solche für den Content 

spezifiziert sein müssen z.B. durch Angabe von Schalen eines Sterntyps. Die eigenschaftsbasierte Suche muß 

robust sein. Wir wenden deshalb dafür SoundEx-Algorithmen an. 

Web IS


Szene zur kollaborativen Semesterplanung 

❨ 

Einreichung 

der Daten durch den 

Lehrstuhlleiter 

✿ 

Akzeptierung einer 

Kursanforderung 

✿ 

Bestätigung 

❑ 

❯ 

❥ Zuweisung 

von Kursen 

an Mitarbeiter 

Login 

durch den 

Lehrstuhl 

❑ 

❥ 

Generierung 

neuer Kurse 

als Vorschläge 

❥ Anpassung 

der Daten 

für einen Kurs 

❯ 

❥ Eingabe der 

erforderlichen 

Daten 

✿ 2 

❑ 

❯ 

Bestätigung 

der Kurszuweisungen 

durch Mitarbeiter 

3 

Darstellung 

der Vorschläge 

für Kurse 

❥ 

Auswahl 

von Daten für 

das Kurse 

❯ 

Alte, gespeicherte 

Daten vergangener 

Semester 

❯ 

Formulierung 

von Nebenbedingungen 

Abbildung 10: Szene zur kollaborativen Planung eines Lehrveranstaltungsangebotes eines Lehrstuhles 

• Die assoziative Suche geht dagegen von assoziierten Begriffen aus. So kann z.B. eine Hotelsuche mit einer 

Suche nach Hotels in der Nähe von einer Sehenswürdigkeit oder eines Transportmittels beginnen, wobei die 

Nähe selbst durch Fuzzy-Funktionen unterstützt wird. 

• Eine Suche kann auch für Schnäppchensucher von Sonderangeboten angeboten werden. 

Die Suche ist ein hochgradig iterativer Prozeß mit einer schrittweisen Verfeinerung. Abschließend kann eine Buchung 

erfolgen. Die Suchszene kann zu jeder Zeit ohne weitere Schritte verlassen werden. In Bild 11 wird eine Suchszene 

dargestellt, die diese Aspekte umfaßt. Diese Gestaltung der Suchszene hat sich bei der Gestaltung von Websites 

bewährt. Mit dieser Gestaltung verwenden wir Techniken der aspekt-orientierten und generativen Programmierung. 

Gleichzeitig kann dieser Zugang als eine Variante der subjekt-orientierten Programmierung verstehen. 

Suchszene 

für Veranstaltungen 

kartenbasierte 

Suche 

❑ 

❥ 

❯ ✾ 

❥ Resultat & 

Verfeinerungsschritt 

Sehenswürdigkeiten 

❑ 

individuelle 

Anfrage 

❨ 

3❯ 

❥ zielgerichtete 

Suche 

❑ 

✾ 

eigenschaftsbasierte 

Suche 

3 

Anfangsschritt 

❯ 

❥ Buchungsschritt 

Abbildung 11: Dialogschritte innerhalb eines Suchszene 

Neben den hier dargestellten Suchschritten gibt es noch weitere Varianten für Dialogschritte zur Suche: 

• Die antonymbasierte Suche beginnt mit einem Begriff, den man nicht sucht, der aber relativ gut das Gegenteil 

umschreibt. 

Web IS


• Das “Zappen” erlaubt den Beginn an einer beliebigen Stelle und eine spezifische Form des “Drill-down”. 

• Das “Roll-up” beginnt mit einem speziellen Begriff und hangelt sich über die Gattung oder Kategorisierung zu 

den gewünschten Begriffen. 

• Das Umschauen oder Kramen ist eine Suche mit einer Drill-down-Funktion zur Verfeinerung. 

• Die Formulierung eines vollständigen Suchausdruckes z.B. mit einer SQL-Anweisung ist eher die Ausnahme. 

• Die Suche mit intelligenten, sich “durchfragenden” Agenten ist eine Form des Auslegens von Fallen oder der 

Beauftragung von Suchhelfern. 

In analoger Form kann auch die Navigation oder auch der Export/Import in generischer Form dargestellt und mit 

konkreten Datenstrukturen unterlegt werden. 

Login Scene With Adaptation of System Facilities to Learner 

Adaptation for 

interactive 

learning 2 

Join 

supervised 

program 

❑ 

Adapt for 

experiments 

✿with data 

Change 

payment or 

profile ❨ 

❥ 

✿ 

Learner 

login 

❥ 

Join 

cooperating 

group 

Enter 

Login 

❑ 

❯ 

Module 

selection 

2 

❑ 

❥ Programm 

selection 

❥ 

Unit 

selection 

3 

Anonymous 

login 

❥ 

Extend 

by adding 

payment 

Abbildung 12: Example of a Scene: Login scene to learning site 

Web IS


EVALUATOR 

close 

group 

check 

answers 

❑ 

❨ 

❯ 

3 

collect 

wikis 

define 

new 

wikis 

❑ 

H 

group 

❯ communi- 

❯ 

develop new 

wikis 

cation 

content 

chunk 

space 

wiki 

delivery 

box 

H 

❯ 

new 

wiki 

wiki 

sheet 

quit 

group 

WIKI TEAM 

MEMBER 

✾ 

2 

✾ 

❥ discussion 

& evaluation 

❯ 

revised 

wiki 

next 

wiki 

❑ 

group 

help 

hints 

& 

tricks 

room 

SUPPORTING 

EXPERT 

pending 

wikis 

❯ 

confirmed 

wikis 

❑ 

❯ 

outdated 

wikis 

Abbildung 13: Wiki Storyboards 

Algorithms Using Data 

selection 

of necessary 

data sets 

❑ 

❥ 

collection 

of data sets 

owned 

by learner 

illustration of 

algorithm 

chosen 

❨ 

3 

❥ reminding 

background & 

configuration 

✿ 

❑ 

3❯ 

❥ execution 

of chosen 

algorithm 

quick 

tutorial ❨ 

selection 

of another 

algorithm 

❨ 

❯ 

explanation 

of results 

obtained 

Abbildung 14: Storyboard with Side Pathes 

Web IS


6.1.6 Storyboards are Different from Workflows 

Supervised Solution of Exercises 

SUPERVISOR 

close 

group 

check 

answers 

❑ 

❨ 

❯ 

collect 

answers 

❑ 

3 

define 

new 

assignments 

H 

group 

communication 

❯ 

❯ 

develop new workplace 

new 

assignments 

assignments 

assignment 

& 

answer 

delivery 

box 

H 

❯ ✾ 

answering 

sheet 

2 

quit 

group 

✾ 

EXERCISE TEAM 

MEMBER 

revised 

assignment 

❑ 

❥ discussion 

& evaluation 

❯ 

next 

assignment 

group 

help 

hints 

& 

tricks 

room 

SO- 

CRATE 

new 

pending 

tricks 

❯ 

hints 

& tricks 

❑ 

❯ 

outdated 

hints 

& tricks 

Abbildung 15: Storyboard with [1,1]-[n≫ 1,m] Workflow 

v 1 

✲ 

insert T Info 

sessionInfo ✲ 

confirm 

Login Scene 

Wait 

Choose Submission 

❄ 

SubmitPaperData Scene 

❯ 

α 

submit 

PaperData 

scene 

A ✻ ❄ 

δ 

submit 

Permit 

A ✻ ❄ 

✲ ✲ ✲ 

update T Info update 

✲ 

confirmed 

✲ ✲ 

login 

✛ ✛ 

login correct 

✲ ✲ 

obtain 

✲ ✲ 

confirm 

✛ ✛ 

upload correct 

✲ 

Paper Submission System Workflow 

To 

initialize✲ generate 

To 

session media object 

❄ 

To 

deliver 

container 

❄ 

Received 

update 

data ❦ 

For ❄ Is 

Check ✲required 

data data 

consistency change ✶ 

❄ 

Received 

paper ✲ close 

To 

data session 

❄ 

To 

prepare ✲ close 

To 

acknowledgement session 

Abbildung 16: Storyboard with [1,1]-[n≫ 1,m] Workflow: Paper submission 

Web IS


Sequenced Competitive Solution Scene 

❑ 

Selection 

of problem 

typ ❨ 

❑ 

❥ 


of learners 

selection 

❑ 

Selection 

of appropriate 

data 2 

❑ 

❥Consideration 

on missing 

data 

Evaluation 


competition 

results 

❑ 

Task 

delivery 

step 

❑ 

❯ 

Selection 


algorithm 

Code 

upload & 

installation 

❑ 

❯ 

Finding 

a solution for 

missing data 

Inspection 

of sample 

solution 

❑ 

❯ Selection 


attributes ❨ 

❥ 

Selection 

of target 

attribute 

❯ 

Computation 

of associations 

through mining 

❥Submission 

of solution 

for competition 

Abbildung 17: Dialogue Scene for Sequenced Training With Competitive Exercises 

Competitive Solution Scene 

❨ 

Submission 

of competitive 

✿solution 

Delivery 

of prepared 

✿ data 

Computation 

of associations 

through mining 

❑ 

❯ 

❥ Evaluation 

of submitted 

solution 

Task 

delivery 

step 

❑ 

❥ 

Collection 


data 

❥Preparation 


data 

❯ 

❥Formulation 


✿hypotheses2 

❑ 

❯ 

Inspection of 

sample solution 

& comparison 

3 


on applicable 

algorithms 

❥ 

Code 

upload & 

installation 

❯ Reminder 

of learning element 

on hypotheses 

❯ 

Repetition 

of solution 

for competition 

Abbildung 18: Dialogue Scene for Training With Competitive Exercises 

Web IS


6.2 Actor Modeling 

KDS 3.2 

6.2.1 Benutzer- und Akteursmodelle 

Wie bereits dargestellt, unterscheiden wir zwischen einem Benutzer und einem Akteur. Ein Benutzer 1 ist eine Repräsentation 

der aktuell agierenden Person z.B. durch die Login-Daten und die persönlichen Daten sowie die Benutzungsgeschichte. 

Benutzer werden im allgemeinen kategorisiert oder gruppiert. 

Benutzer können nach ihren Eigenschaften gruppiert und mit einem Typkonzept dargestellt werden. Ein Akteur 

ist ein abstrakter Benutzer-Typ, der eine Gruppe von Benutzern abstrakt darstellt. Damit werden die allgemeinen 

Charakteristiken von Benutzern beschrieben. In der konzeptionellen Modellierung sind wir mehr an einer Darstellung 

von Akteuren orientiert. 

Akteure sind den einzelnen Dialogschritten und damit den Szenen mit entsprechenden Rechten und Rollen zugeordnet. 

Diese Rollen erlauben einem Akteur das Agieren mit dem Informationssystem. Eine direkte Interaktion 

mit entsprechenden Funktionen über entsprechende Sichten oder das Schema direkt ist nach wie vor auch möglich. 

In diesem Fall wird jedoch nicht eine entsprechende Oberflächenmodellierung vorgenommen. Da solche Interaktionen 

in ihrer Vielfalt kaum zu behandeln sind, modellieren wir sie nicht gesondert, sondern benutzen die Dienste der 

logischen Schicht. 

Dieses Akteurmodell verallgemeinert das Use-Case-Modell. Wir streben eine möglichst abstrakte Beschreibung 

am Anfang an und gehen erst dann ins Detail, wenn der Endanwender nicht mehr involviert ist. Beziehungen zwischen 

den Akteuren werden nur durch entsprechende Dialoge aufgebaut. Die Beziehung zwischen Akteur und System 

findet hier jedoch nur durch entsprechende Dialoge statt. Ein Akteur aktiviert einen Dialog und erhält Daten aus dem 

Dialog, modifiziert Daten im Dialog oder stellt dem System Daten im Dialog zur Verfügung. Damit ist das hier angewandte 

Modell viel allgemeiner und zugleich praktikabler als das Use-Case-Modell. 

Einem Akteur wird ein Profil zugeordnet. Es umfaßt 

das Ausbildungsprofil mit einer allgemeinen Darstellung der erforderlichen Kenntnisse, Fähigkeiten und Fertigkeiten, 

das Arbeitsprofil mit einer Darstellung der Spezifika der Akteure und in Ergänzung zum Ausbildungsprofil und 

das Persönlichkeitsprofil zur Darstellung der Eigenschaften von Gruppen. 

Das Ausbildungsprofil stellt für eine Gruppe von Benutzern das gesamte Spektrum der Ausbildung, die die Benutzer 

• benötigen, 

• mitbringen und ggf. auch 

• nicht besitzen 

sollen, dar. Die letzte Kategorie dient auch der Charakterisierung von Wissens-, Fertigkeiten- und Fähigkeitslücken. 

Diese Kategorie erlaubt auch eine Ableitung von Content, der für die Bewältigung der Arbeitsaufgabe durch das 

Informationssystem bereitgestellt werden muß. 

Die erste Kategorie dient der Darstellung des Bildungsweges, der auch in grober Form dargestellt werden kann. 

Die Darstellung des Bildungsweges wird meist in analoger Form wie in Stellenanzeigen oder Stellenprofilen eines 

Arbeitsplatzes erfolgen. Wir benötigen diese Kategorie zur Ableitung der pragmatischen Annahmen, die eine Vereinfachung 

des Systemes bedingen. 

Die zweite Kategorie kennzeichnet das Bildungsspektrum der Benutzer. Wird das Spektrum nicht berücksichtigt, 

dann verleitet ein System relativ schnell zum Mißbrauch oder wird abgelehnt, obwohl es gerade zur Bewältigung der 

Arbeitsaufgabe adäquat erscheint. 

Das Arbeitsprofil ist analog zur KADS-Charakterisierung [LFe93] auf eine Klassifikation der Akteure nach Eigenschaften 

ausgerichtet: 

1 Wie bereits betont, benutzen wir ‘Benutzer’ neutral und nicht geschlechtsspezifisch. 

Web IS


• Fähigkeiten, die Akteure zur Bewältigung der Arbeitsaufgaben besitzen sollen, 

• Fertigkeiten, die zur Benutzung des Systemes erforderlich sind, 

• Wissen, das zum Verständnis der Benutzung des Systemes erforderlich ist, 

• Arbeitsumgebung, die durch die Akteure toleriert bzw. akzeptiert wird, und 

• Systeme, mit denen die Akteure bereits Arbeitsaufgaben bewältigt haben. 

Das Persönlichkeitsprofil umfaßt auch das Polaritätenprofil. Typische Polaritätenprofile sind nach Anmutungscharakteren 

sachlich-romantisch, konventionell-originell, klassisch-modisch, traditionell-avantgardistisch, tough-tender, 

rustikal-artifiziell und einfach-wertvoll. Im Einzelnen können wir dazu Differenzierungen nach Notenskalen für die 

Antonyme vornehmen. 

sachlich - romantisch konventionell - originell 

nüchtern - gefühlvoll üblich - ausgeflippt 

rational - sensitiv bedeckt - frisch 

überlegt - sinnlich seriös - ungewöhnlich 

bürgerlich - bohemehaft 

klassisch - modisch traditionell - avantgardistisch 

dezent - laut alt - jung 

zeitlos - modern uni - bunt 

ruhig - unruhig ruhig - erregend 

zurückhaltend - aufdringlich vertraut - vertraut 

gewohnt - poppig 

tough - tender rustikal - artifiziell 

herb - süßlich natürlich - künstlich 

geometrisch - blumig verspielt - streng 

hart - weich einfach - komplex 

robust - zart schwer - leicht 

eckig - rund grob - grazil 

Daraus kann die Charakterisierung von Benutzergruppen abgeleitet werden. 

Bekannt ist z.B. nach [KT95] das Fremdbild wie in Bild 19. 

stabil 

✻ 

wild stark 

hart 

introvertiert 

✛ 

triebhaft 

✲ 

aggressiv 

gesellig 

extravertiert 

❄ 

labil 

Abbildung 19: Das Fremdbild des Bayern 

Ähnliche Profile sind auch für andere Gruppen bekannt. Mit diesen Profilen können Portfolios für die einzelnen 

Benutzergruppen erstellt werden. Hinzu kommen dabei auch noch Morphologien. Ein Oberflächen-Portfolio setzt 

sich dabei aus mehreren ebenen Profilen zusammen wie Funktion-Semantik, Prägnanz-Expressivität. 

Zum Persönlichkeitsprofil gehört auch das subjektive Informationsbedürfnis, das wiederum abhängig von der (intuitiven) 

Erkenntnis ist, daß die vorhandene Information zur Lösung einer Aufgabe nicht ausreicht, daß das Wissen 

zu gering ist, daß die Information aus vorhandenen Wissen und Informationen nicht oder nicht so schnell generiert 

werden kann, daß die Unsicherheit, Unbestimmtheit, Unschärfe oder die Widersprüche nicht anders aufgelöst werden 

können. Wir unterscheiden den Informationsbedarf vom Informationsbedürfnis. Das Informationsbedürfnis ist 

abstrakt ein Wunsch nach besserer Information. Der Informationsbedarf wird für das Portfolio benötigt. 

Web IS


Bei der Entwicklung von Informationssystemen sind unterschiedliche Informationsbedürfnisse entsprechend dem 

Profil zu beachten. Damit kann ein Informationssystem nur dann von Bestand sein, wenn es ein Bündel von Informationsdiensten 

aus den folgenden Kategorien bereitstellt. 

Informationsdienste im allgemeinen Interesse orientieren sich insbesondere analog zu Zeitungen auf die Bereitstellung 

von Informationen des täglichen Alltags. Beispiele sind Wetterdienste, Veranstaltungskalender, Regionalinformationen, 

Sportinformationen und Nachrichtendienste. 

Informationsdienste zur Gestaltung der Freizeit orientieren sich z.Z. noch am Computerspielmarkt, werden aber 

auch immer stärker Aufgaben der Kommunikation (wie auch Email) übernehmen und sich zunehmend in eine 

stärkere Konkurrenz mit Printmedien wie Nachschlagewerke, Verzeichnisse wie Adreßbücher begeben. 

Informationsdienste zur Erfüllung von Arbeitsaufgaben werden zuerst als allgemeine Betriebsinformationssysteme 

(wie z.B. als Campusinformationssystem) erfolgreich sein. Die Achillesferse der heute vorrangig entwickelten 

Wirtschaftsinformationsdienste ist die Aktualität der angebotenen Information 2 . 

Jede Gruppe von Benutzern besitzt auch Spezifika. Diese ergänzen das allgemeine Profil um folgende Informationen: 

positive Arbeitserfahrungen für die Anwendung wie praktizierte Kenntnisse, Lösungsstrategien und Fertigkeiten 

bei der Anwendung des eigenen Wissens, 

negative Arbeitserfahrungen (i.a. Fehlersuche, Fehlerbeseitigung, Arbeitsplanung, Arbeitsschrittentscheidungen, 

Bewertung des Arbeitsfortschrittes, Konstruktion der Lösungen, Umgang mit Abstraktionstechniken, Effektivität, 

Erweiterung für bereits gefundene Teillösungen und Kooperationsfähigkeit) und 

spezielle Kenntnisse (wie (Wissens-)Repäsentationstechniken, (Wissens-)Akquisition und andere). 

Die Profile von Akteuren können kategorisiert und damit einer Skalierung unterzogen werden. Wir können z.B. 

mit der folgenden Kategorisierung die Profile der Akteure zum Erstellen eines Lehrveranstaltungsvorschlages eines 

Lehrstuhles vornehmen: 

Ausbildungsprofil Arbeitsprofil Persönlichkeitsprofil Folgerung 

erforderlichan- 

vor- 

nicht Fähigkeitekeiteumgebuntenprofil 

Fertig- 

Wissen Arbeits- 

System Polaritä- 

... für Umgebunden 

vorh. 

Java, 

C++ 

Unix 

Informatik 

Informatik 

Organisationserfahrung 

Programmierung 

Informatik 

Workstation 

rigide ... Kommandosprache, 

ohne Sicherung 

Büro- 

Kauffrau/ 

-mann 

PH- 

Studium 

Informatik 

Organisator 

kollaborativ 

allg. PC-Platz minimal moderat ... Fehlertoleranz, 

Übersichtlichkeit 

... ... ... ... ... ... ... ... ... ... ... 

Andere ableitbare Eigenschaften sind z.B. die erforderlich Hilfe, die Art des Systemerlernens, die Adaptivität 

der Interfaces, die Erweiterbarkeit, exploratives Handeln, selbst gesteuerte Nutzung, Merkhilfen, Aufgabenorientierung, 

Routinetoleranz, Technikerwartungen, Zusatzaufwandtoleranz, EDV-Terminologie-Toleranz, Aufgabenbezug, 

Benutzerführung, Beispiele, Einführung und Voreinstellungen. 

Aus dem Profil können wir die Art und die Form der Informationspräsentation und das Informationsbeschaffungsverhalten 

der Akteure ableiten. Weiterhin kann man Benutzungspräferenzen der Akteure skizzieren. 

2 Die Erfahrung im Projekt FuEline deutete auf eine Halbwertszeit von weniger als 3 Monaten hin, wodurch der Verfall eines wie perfekt 

auch immer gestalteten Informationsbestandes innerhalb kurzer Zeit vollständig ist, wenn nicht ein effizienter Updateservice auf der Grundlage 

einer guten Updatestrategie möglich ist. 

Web IS


Akteure können mit anderen Akteuren zusammenwirken. Im Zusammenwirken spielen Ziele eine Rolle. Ein 

Modell zur Darstellung der Ziele stellen wir in Bild 20 kurz zusammen. 

Akteur 

✻ 

6 

✛ 

✛ 

Mit 

Zusammenarbeit 

Von 

✲ Art der 

Zusammenarbeit 

unscharfes 

Ziel 

❨ 

Ziel 

✻ 

✲ 

Erfüllungskriterium 

❄ 

❂ 

⊕ 

Welt 

erreicht 

Medien-Typ 

✻ 

❄ 

Aufgabe 

✛ 

Lösung 

Abbildung 20: Die Zusammenarbeit von Akteuren zum Erreichen von Zielen 

Im Zielmodell unterscheiden wir zwischen unscharfen oder “weichen” Zielen und “harten” Zielen. Weiche Ziele 

besitzen kein genau darstellbares Erfüllungskriterium. Harte Ziele sind dagegen durch ein Erfüllungskriterium 

charakterisiert. Zum Erreichen von Zielen können Akteure zusammenarbeiten. 

Einem Akteur kann ein Sicherheitsprofil zugeordnet werden. Wir verwenden dazu eine Datenstruktur wie in Bild 

21. 

Das Sicherheitsprofil eines Akteurs wird durch Sicherheitsoptionen, mit denen die gesamte Sicherung des Systemes 

dargestellt werden kann, charakterisiert. Zur Durchführung von Aufgaben im Rahmen des Story-Raumes 

werden entsprechende Medien-Typen bereitgestellt. Da diese den Aufgaben zugeordnet sind, werden Sicherheitsoptionen 

mit vier Parametern spezifiziert. 

Akteure werden mit entsprechenden Sicherheitsoptionen zur Erfüllung von Aufgaben ausgestattet. 

Aufgaben determinieren die erlaubten Aktionen, erfordern Aktionen oder determinieren spezifische Sicherheitsprofile. 

Rollen von Akteuren entsprechen den bereits besprochenen Rollen im Story-Raum. Für Sicherheitsprofile sind außerdem 

Rollen von Interesse, die einer Gruppe von Akteuren zugeordnet werden. 

Eine Sicherheitsoption basiert entweder auf erlaubten Aktionen oder expliziten Verboten. 

Ein Benutzer wird einem Akteur zugeordnet. Er kann gleichzeitig einer Reihe von Akteuren zugeordnet werden. 

6.2.2 Die Darstellung des Arbeitsrahmens und Benutzer- und Akteurportfolio 

Das Portfolio des Akteurs wird beschrieben durch: 

• die Beschreibung des Inhaltes der Aufgabe, 

• die Spezifikation der Rechte des Akteurs im entsprechenden Dialogschritt, 

• die Beschreibung der Rolle des Akteurs und 

Web IS


Rechte 

✲ 

Erlaubte 

Aktion 

✻ 

✯ 

Verbote 

... 

✛ 

Benutzerprofil 

Aufgabe 

✛ 

⊕ 

Sicherheitsoption 

✲ 

Akteur ✛ Zuordnung ✲ 

❄ 

Benutzer 

✻ 

✒ 

Gruppenrolle 

✲ 

❄ 

Rolle 

Log 

Abbildung 21: Das Sicherheitsprofil von Akteuren 

• die Ausführungsmodelle für das Agieren mit Angaben zur Zeitdauer (minimal, maximal, normal), sowie zu 

den Ausführungsprioritäten. 

Eine Aufgabe ist eine Vorgabe für zielorientiertes Handeln und wird durch die folgenden Aspekte beschrieben: 

• Die Darstellung der Aufgaben geht von einer Zielstruktur aus. Diese Zielstruktur kann im zustandsorientierten 

Zugang zur Modellierung durch Angabe des Zielzustandes erfaßt werden. 

• Durch eine Wissensprofil werden die Details des Aufgabenwissens erfaßt. 

• Die Beschreibung der Arbeitsmittel basiert auf der Darstellung des Content und der erforderlichen Funktionalität. 

• Die Erfüllung einer Aufgabe erfolgt in Arbeitsabläufen, die in einzelne Arbeitsvorgänge strukturiert sind. 

• Es kann ein allgemeines Abarbeitungsmodell für die Wege zum Zielzustand vorgegeben sein. In stark strukturierten 

Arbeitsfeldern wird gerade auf die genaue und detaillierte Darstellung dieses Abarbeitungsmodelles 

viel Wert gelegt. 

Eine Spezifikation der Arbeitsvorgänge umfaßt folgende Bestandteile: 

Die allgemeine Struktur wird beschrieben durch 

• einen Auslöser, 

• eine organisatorische Einheit, 

• eine Tätigkeit des Benutzers, 

• verwendete Hilfsmittel und 

• eine Ablage und einen Adressaten. 

Das Resultat der Ausführung führt zu einem 

• einem Ergebnis, 

• das unter bestimmten Bedingungen akzeptiert wird. 

Die semantischen Rahmenbedingungen sind definiert durch 

• Bedingungen, unter denen der Arbeitsvorgang ausgeführt werden kann, und 

Web IS


• organisatorische Randbedingungen. 

Arbeitsabläufe werden durch Aktivitätenfolgendiagramme beschrieben. Sie bestehen aus 

einem Aktivitätstyp zur Kategorisierung von gleichartigen Aktivitäten, 

einer Transition von Input/Outputdaten durch die Aktivität und 

der Steuerung des Beginns, der Verzweigung etc. und der Beendigung einer Aktivität. 

Mit dieser Spezifikation können wir Aktivitätenfolgendiagramme mit Workflow-Programmen assoziieren. Aktivitätenfolgendiagramme 

können sowohl zustandsorientiert durch Zustandsaktivitätendiagramme als auch ereignisorientiert 

durch Ereignisfolgendiagramme dargestellt werden. 

Rechte eines Akteurs werden durch Zuordnung von Funktionen des Content-Objekt-Suite dargestellt, die ein 

Akteur zur Erfüllung der Arbeitsaufgabe erhält. Mit der expliziten Zuordnung wird ggf. der Spezifikationsaufwand 

höher. Wir können jedoch diese Zuordnung auch durch entsprechende Rechtetypen darstellen. Damit wird für die 

Spezifikation der Rechte nur eine Zuordnung zum Typ erforderlich. 

Die Rolle eines Akteurs baut auf einer Kategorisierung der Erfüllung der Arbeitsaufgabe und auf dem Organisationsmodell 

auf. 

Das Ausführungsmodell besteht aus 

einem Aufgabenaufruf, mit dem die Ausführung initiiert werden kann, 

einem Datenaustausch, mit der benötigte Daten für die Ausführung bereitgestellt und wieder in das Informationssystem 

eingepflegt werden können, 

einer Aufgabenablaufsteuerung, mit der sequentielle und nebenläufige Abläufe dargestellt werden 

einem Arbeitsbereich, auf dem mehrere unterschiedliche Aufgaben abgelegt werden können, und 

einem Synchronisationsmodell, zum Abgleich der Ausführung von Aufgaben, die sich im Arbeitsbereich befinden. 

5ergänzt werden. 

Aus der Darstellung der Aufgaben können wir den Informationsbedarf ableiten. Der Informationsbedarf ist nach 

einer genauen Analyse des augenblicklichen Wissensstandes und der Ziele der Wissensvermittlung ableitbar und 

sogar in Geschäftsprozesse abbildbar. Die Qualität der Aufbereitung von Informationen wird durch den augenblicklichen 

Informationsbedarf mit determiniert. 

Das Portfolio wird mit den Arbeitsgestaltungsdimensionen für die Gestaltung humaner Arbeit erweitert: 

Der Entscheidungsspielraum kennzeichnet das Ausmaß, in dem ein Benutzer seinen Arbeitsprozeß selbst gestalten 

kann. 

Die arbeitsbezogene Kollaboration dient der Abstimmung von Teilen der Arbeitsaufgabe mit anderen Akteuren. 

Einschränkungen durch psychische Belastungen können durch entsprechende Hilfsmittel minimiert werden. 

Der Zeitrahmen kennzeichnet die Möglichkeit, den Arbeitsablauf zeitlich selbständig durch den Akteur zu gestalten. 

Die Variabilität ist bestimmt durch den Zusammenhang der Arbeitsvorgänge und der Vorgehensweise zur Aufgabenerfüllung. 

Die Wahrnehmungen des Benutzers unterstützen die schnellere Erfassung der anstehenden Aufgaben. 

Die körperliche Aktivität unterstützt die Erfüllung der Aufgaben. 

Die Strukturierbarkeit des Arbeitsbereiches erlaubt eine Anpassung an die Arbeitsweise und Arbeitsmethodik des 

Benutzers. 

Web IS


Zur Spezifikation der Arbeitsgestaltungsdimension verwenden wir ein Gestaltungspolaritätenprofil mit entsprechenden 

antonymen Charakterisierungen wie z.B. für den Arbeitsvorgang zum Erstellen der Vorschläge eines Lehrstuhles 

für Lehrveranstaltungen: 

Spielraum Kollaboration Belastung Zeitrahmen Variabilität Wahrnehmung Aktivität Strukturierbarkeit 

vollkommen 

Abstimmung nebenläufi- 

Ablieferungs- 

hoch, mit wohl- 

Direkt- 

Aufgabenblatt 

im Lehrstuhl ge Tätigkeit zeitpunkt Sitzung, strukturiert, eingabe, mit Ord- 

eigenständiterstützung 

volle Un- 

ohne Maus Übernahme nung nach 

vorhandener 

Daten 

Erfüllungsstand 

Durch Interaktionsdiagramme werden die Story, die Szenario und das Drehbuch unterlegt. Interaktionsdiagramme 

sind gerichtete Graphen, deren Knoten Zustände des Systemes und deren Kanten Transitionen darstellen, 

die durch einen Akteur ausgelöst werden können. Es kann ein Akteur in seinen Rollen, mit seinen Rechten bei der 

Aufgabenlösung dargestellt werden. Das Akteurmodel faßt folgende Eigenschaften zusammen: 

Profil des Akteurs, 

Arbeitsziele des Akteurs, 

Sicherheitsprofil des Akteurs und 

Portfolio des Akteurs. 

Wir trennen davon jedoch im Gegensatz zu Use-Case die Beziehungen der Dialoge zu den Daten und zu den 

Funktionen. Diese Trennung entspricht der klassischen Vorgehensweise und verhindert ein Überladen der Konstrukte. 

Damit sind außerdem auch die dort geforderten Ressourcenmodelle, Organigramme, Firmenstrategiemodelle, etc. 

nicht mehr notwendig. Mit der Verbindung zu den Sichten erhalten wir eine Seiteninhaltsbeschreibung. 

Web IS


6.3 Task Modeling 

KDS 3.3


6.4 Räume zur Speyifikation der Interaktivität 

6.4.1 Der Interaktionsraum zur Darstellung der Interaktivität 

Die Interaktivität kann unter zwei Gesichtspunkten dargestellt werden: 

Der System-Gesichtspunkt umfaßt alle Input-, Output- und Speicherprozesse und baut auf der Strukturierung der 

Daten, auf den Sichten zur zusammenhängenden Darstellung der Daten, sowie auf dem technischen Workflow, 

der wiederum auf Systemprozessen basiert, auf. 

Der Benutzer-Gesichtspunkt basiert auf den Rollen und Aufgaben von Benutzergruppen, deren Sichtweisen auf 

die dargestellten Daten und die ablaufenden Prozesse. Diese Sichtweisen sind auch durch die Pragmatik der 

Benutzergruppen geprägt. 

Ein Informationssystem basiert auf einer Schichten-Architektur, die die klassische ANSI-Sparc-Architektur verallgemeinert. 

Im folgenden vertiefen wir diesen Zugang. Die Architektur ist in Bild 22 (b) skizziert. Mit dieser Architektur 

wird nicht nur die klassische Seeheim-Architektur in Bild 22 (a) verbessert, sondern auch eine ganzheitliche 

Betrachtung von Anwendungen ermöglicht. Die Oberflächenmodellierung wurde auch für Datenbanken im wesentlichen 

auf der Grundlage des Seeheim-Modelles nach Bild 22 (a) (ohne Dialogmanagementsystem und Sichtengenerator) 

vorgenommen. Das klassische Seeheim-Modell trennt wie in Client/Server-Architekturen die Präsentation 

vom Anwendungssystem. Diese Trennung hat sich für eine Vielzahl von Anwendungen durchgesetzt. Die Funktionalität 

der Anwendungssysteme kann sich dabei weiter in die Clients verlagern. Für Datenbanksysteme hat sich diese 

Architektur sogar mit einer Verallgemeinerung zur Arch-Architektur noch nicht durchgesetzt. Vorstellbar ist nach 

[Sch96] auch eine Erweiterung der Präsentationskomponente zu einem Dialogmanagementsystem. Die Arbeiten der 

DBIS-Arbeitsgruppe haben zu der hier verwendeten verallgemeinerten Architektur geführt. 

Das verallgemeinerte Seeheim-Modell 

Das DBIS-Modell für Informationssysteme 

Informationssystem 

✻ 

❄ 

Anwendungskomponente 


Prozesse 

Dynamische 


(Pragmatik) 

Präsentationskomponente 

Graphikbasissystem 

Sichtengenerator 

Dialogmanagementsystem 

Prozeßgenerator 

DBMS 

Story-Raum 

Stories 

Szenario 

Content-Typen-Raum 

Struktur 


Struktur 

Statische 


(Pragmatik) 

Container 

Akteure 

Kontext 


(a) 

Abbildung 22: Spezifikation von Informationssystemen 

(b) 

Die Trennung zwischen Client und Server ist eine der möglichen Separation innerhalb einer Anwendung. Vorstellbar 

sind weitere Trennungen, wie z.B. die Trennung für verteilte Informationssysteme, die Trennung für Web- 

Informationssysteme mit relativ einfachen Client oder auch Applet-basierte Clients. Das DBIS-Modell ist auf keine 

der Trennlinien angewiesen und erlaubt eine spätere Entscheidung für eine Plattform. 

Typische weitere Trennungen sind meist als Multi-Tier-Architekturen, z.B. als 3-Tier-Architekturen spezifiziert. 

Die Spezifikation des Interaktionsraumes wird in folgenden Entwurfsdokumenten niedergelegt: 

Drehbuch: Der Ablauf der Interaktion, die Akteure, die Stories der Anwendung werden im Drehbuch zusammengefaßt.


Content-Typen: Das Systeminterface wird als Container-Objekt bereitgestellt, mit dem ein Akteur sowohl die aktuellen 

und spezifischen Sichtweisen auf die Datenbank erhält, als auch die entsprechende Funktionalität zum 

Agieren mit dem Informationssystem. 

Der Interaktionsraum wird um “Soft”-Bestandteile erweitert: 

Kollaborationsrahmen: Die Interaktion basiert auf der Existenz mehrerer Parteien, die in unterschiedlichen Rollen 

agieren, kollaborieren und unterschiedliche Interessen verfolgen. 

Gestaltungsrahmen: Bei der Gestaltung von Benutzungsschnittstellen ist es angebracht, einem einheitlichen Schema 

zu folgen. Wir fassen den “Style Guide” zur Gestaltung von Interfaces, die Metaphorik und die allgemeinen 

Gestaltungsrichtlinien im Gestaltungsrahmen zusammen. 

Arbeitsrahmen: Informationssysteme sollen bei der Bewältigung von Arbeitsaufgaben eingesetzt werden. Deshalb 

müssen auch das Portfolio, das Aufgabenspektrum der einzelnen Benutzer und die Lösungsschritte für die 

Arbeitsaufgaben angemessen bei der Gestaltung berücksichtigt werden. 

6.4.2 Der Kontext-Raum 

Die Laufzeit-Präsentation wird durch Instantiierung des Kontextes (technische Umgebung, Aufgabe, Geschichte, 

Umstände) und durch Adaption an den Benutzer (Profil, Portfolio) erzeugt. Diese Information muß deshalb im 

Entwurf mit erarbeitet werden. 

Wir betrachten unterschiedliche Spielarten von Kontext. Diese Spielarten können mit dem Zwiebelprinzip zum 

Ausspielen in die XML-Dokumente eingebracht werden. 

Allgemeiner Kontext dient zur Beschreibung des Kontextraumes. 

Umstände allgemeiner Art kennzeichnen insbesondere Beschränkungen der Benutzung, Einspielen von Hilfsmitteln 

etc. 

Das Benutzungsmodell der Akteure hängt von einer Reihe von Parametern ab wie 

die Bezahlung, 

das Organisationsmodell zur Benutzung, 

die daraus resultierenden Rechte und 

die darauf aufbauenden Rollen. 

Das Portfolio der Akteure wird bestimmt 

durch die Aufgaben, 

durch die spezifischen Rechte, 

durch die spezifischen Rollen, 

durch die Umstände der Benutzung und 

durch die Ziele. 

Technische Einschränkungen allgemeiner Art erweitern oder schränken die Benutzung ein. Sie sind gegeben 

durch 

die Umgebung der Benutzung wie z.B. Hardware, Server-Software, Client-Software und den Kanal, 

sowie durch 

die Verteilung auf unterschiedliche Knoten. 

Der konkrete Benutzungskontext basiert auf einer Beschreibung der Assoziationen, wobei auch eine entsprechende 

Bindung, Umordnung zur sequentiellen Repräsentation berücksichtigt wird, und der Ort und die Zeit der 

Benutzung zu Veränderungen führen kann. Der Benutzungskontext ist determiniert durch 

die Einbettung in den Story-Raum insbesondere unter Berücksichtigung 

des benutzten Content je nach angeforderter


Version, 

Navigation u.a. Funktionalität, sowie dem 

Sicherheitsprofil, 

die Anpassung an den Benutzer, wobei auch 

Ort, 

Zeit und 

Benutzungsgeschichte variieren können, 

die Auslieferung von Content in Containern, deren Typ variieren kann und die auch an die 

verpackten Content-Objekte 

anpaßbar sein müssen, 

durch das aktuelle Szenarium und die unterstützenden Session-Objekte, 

das konkrete Benutzungsmodell, 

die aktuelle Umgebung wie z.B. 

den Kanal mit seiner aktuellen Übertragungskapazität und seiner Sicherheit, sowie die 

aktuell gewählte Verschlüsselung. 

Die Spielarten von Kontext können einer Abhängigkeitsstruktur unterliegen. Wenn wir z.B. voraussetzen, 

• daß der syntaktische Kontext, der durch den Content bestimmt ist, und der Zusatzkontext, der durch die Hilfsmittel 

bestimmt ist, unabhängig voneinander sind und 

• daß sich die Spielarten schichten lassen aufgrund der Abhängigkeitsbeziehung, 

dann kann ein Ausspiel des Content in der Form erfolgen wie in Bild 23. 

Pragmatischer Kontext (Situation, physische Umgebung, Sozial-, Strategie-, Zeit) 

Website-Kontext (Provider, SW/HW Lieferant) 

Expliziter Kontext (Story-Raum) 

Syntaktischer 

verbaler Kontext 

Extra-syntaktischer 

Zusatzkontext 

Content-Suite, 

Akteure, Profile, 

Meta-Information 

Bezahlung, ... 

Potentielle Umgebung, Informationssystem, Szenen, Aufgaben, Rollen 

Intention, Themen, Umstände, Mission, Anliegen 

Aktuelles Szenario, Historie, aktuelle Umgebung, Benutzer, Ziel, Umstände, Kultur 

Abbildung 23: Das Zwiebelprinzip zum Einbringen von Kontext


6.5 Spezifikation auf unterschiedlichen Abstraktionsschichten 

Wie bereits in den vorhergehenden Teilen diskutiert, unterscheiden wir zwischen dem Diskurs, den Handlungsrahmen, 

dem Storyboard, dem Drehbuch und der Inszenierung der Dialoge. In unterschiedlichen Entwurfsetappen werden 

die Dialoge im Abstraktionsschichtenmodell spezifiziert. Informationssysteme sind meist auf unterschiedliche 

Benutzergruppen ausgerichtet, die unterschiedliche Anforderungen an die Benutzung, an das intuitive Verständnis 

der einzelnen Schritte, an die Funktionalität und die Gestaltung der Oberflächen haben. Da eine zusammenhängende 

Darstellung nach unserer Kenntnis nicht existiert, stellen wir unsere Methodik ausführlicher vor. 

Das Finden der Motive und Ideen und die Darstellung des Diskurses kann auf den Informationen, die wir bereits 

in der Anwendungsanalyse erhalten haben, aufsetzen. Wir entwickeln erste grobe und bruchstückhafte Ideen. 

Später können wir aus diesen Ideen eine Auswahl treffen. In dieser Etappe ist eher eine Methode wie das 

mind mapping angebracht. Damit ist ein Entwerfer voll gefordert. Oft ist nicht die objektivste Auswahl von 

Ideen die beste, sondern eine subjektive Auswahl. Dabei zeigt sich, daß das Ideenmaterial eigene Prinzipien 

hat und auch widersprüchlich sein kann. Es wird in diesem Schritt das Anwendungsgebiet mit den einzelnen 

Anwendungsschritten skizziert. Das Ergebnis ist die Darstellung des Diskurses im Lastenheft. 

Die Entwicklung des Handlungsrahmens kann nun zu einer groben Darstellung der Aktionen der Akteure führen. 

Wir modellieren deshalb die Akteure in dieser Etappe mit ihren Rollen, Rechten, Aufgaben und Zielen im 

Groben. Der Handlungsrahmen ist mit der Darstellung der Motive und Ziele im vorigen Schritt bereits skizziert. 

Noch ehe ein Drehbuch erstellt wird, muß zumindest für den Dialogteil ein Entwickler wissen, worin die 

Geschichte besteht. In der Geschichte werden die Hauptdialoge mit ihren Zielen und Absichten dargestellt. 

Nicht alle Einzelszenen müssen enthalten sein. 

Es existiert eine Vielfalt von möglichen Stories. Trotzdem gibt es Regeln zur Beschreibung von Geschichten. 

Jede Geschichte wird durch Motive, Absichten und Ziele geprägt. Damit ist auch ein Skelett der Handlung 

gegeben. Auf der Grundlage dieses Skeletts kann die Geschichte eine Struktur erhalten. Sie sollte frei von 

Widersprüchen und nur beschränkt rekursiv sein. 

Ein System wird nur dann akzeptiert, wenn es einen intuitiv erkennbaren Nutzen bringt und echte Bedürfnisse 

von Akteuren in einfacher Form befriedigt. Ein System ist damit auch vom Zeitgeist abhängig, sollte sich 

diesem aber nicht vordergründig verpflichtet fühlen. Jede Szene ist klar und deutlich zu entwerfen und muß 

mit einem entsprechenden Inhalt an der richtigen Stelle, mit der richtigen Hintergrundinformation und mit 

adäquaten Aufgaben komponiert werden. Außerdem sind für jede Szene die Informationen den Akteuren in 

der richtigen Sorte, in der richtigen Dosis, in der richtigen Form, in vollem Umfang und zu akzeptablen Kosten 

zur Verfügung zu stellen. Allen Akteuren ist klar und deutlich darzustellen, worin der nächste Arbeitsschritt 

besteht, in welcher Szene der Story er sich befindet und welche Probleme nun gelöst werden sollen und können. 

Eine Anwendung kann auf eine Fülle von Zielgruppen oder auf einige wenige Akteure orientiert werden. 

Anstatt eine Story ‘drauflos zu entwickeln’, bevorzugen wir eine methodische Entwicklung. Wir arbeiten uns 

von der Idee zur Grobstruktur und weiter über verschiedene Zwischenstadien bis zur Endfassung vor. Die drei 

wichtigsten Entwicklungsstadien sind Expose, Treatment und die ausgearbeite Story. Ein solches schrittweises 

Vorgehen bringt beträchtliche Vorteile durch die schrittweise Beseitigung von Unsicherheitsfaktoren und das 

Hinzufügen von zusätzlichem Material mit sich. Jede Szene kann damit ihren richtigen Platz in der Story 

erhalten. Sprünge werden vermieden. Der langsame Aufbau gewährleistet auch Detailtreue. 

Eine Story baut auf Ereignissen auf, in denen Akteure in Arbeitsschritten ontologische Einheiten benutzen. 

Deshalb wird hier auch eine enge Integration der Dialogentwicklung mit der Entwicklung der Sichten und der 

Funktionen vorgenommen. 

Das Resultat dieses Schrittes ist als Handlungsrahmen Bestandteil des Pflichtenheftes. 

Die Spezifikation des Storyboards wird auf der Grundlage der entwickelten Story durch Auswahl von möglichen 

Ausprägungen und Verfeinerung entwickelt. Die Story besteht aus Szenen, die nun in einer Form ausgeprägt 

werden, die dem tatsächlichen Ablauf der Handlung entspricht. Wir nutzen dazu eine Aufnahme der möglichen 

Szenario. Ein Szenario ist ein genereller Ablauf aus der Sicht der Akteure. Dieser Auflauf oder Durchlauf soll 

dem aktuellen Geschehen in der Anwendung entsprechen.




Vorstudie 

Story-Entwurf 


Anwendungsschritt 

Lastenheft: Diskurs 


Feinstudie 

Szenenentwicklung 

Stories 

Ereignis 

Pflichtenheft: Handlungsrahmen 


Plot 

Entwurf 

Szenenbeschreibung 

Thema 

Storyboard 


Schicht 

Szenenraum 


Szenenausschmückung 

Dialogschritt 

Drehbuch 

Arbeitsoberfläche 

Präsentationsraum 

Inszenierung 

Abbildung 24: Die Arbeitsprodukte im Abstraktionsschichtenmodell für den Story-Raum (Dialogaspekte)


Die einzelnen Szenario können wir schrittweise miteinander verknüpfen und diese integrieren. Mit einer derartigen 

Integration entsteht eine Verfeinerung der Story. Die einzelnen Szenen werden nun durch entsprechende 

Dialogschritte untersetzt, in denen die Akteure entsprechende Handlungen und Aktionen vornehmen und dazu 

Daten vom Format der Aktionssichten-Suite verwenden. 

Zwischen Story und Szenarien existiert ein Unterschied. Die Geschichte ist das eigentliche Geschehen. Die 

Szenario bestimmen die Auswahl von Szenen und Szenenfolgen. Jede einzelne Szene stellt ein Thema der 

Anwendung dar. Im Falle unserer Beispielanwendung sind Themen Angabe von Vorschlägen zu Lehrveranstaltungen, 

Zusammenstellung eines Stundenplanes, Übersicht über ein Institutsprofil. 

Die Szenario stellen einen verfeinerten Ablauf einer einzelnen Story dar. Dabei wird es oft vorkommen, daß 

nicht eine einzelne Story zur Darstellung aller möglichen Szenario ausreicht, sondern eine Menge von Stories, 

die die Abläufe in der Anwendung beschreibt. In diesen Fall entwickeln wir den Raum der Stories, den Story- 

Raum. Dieser Story-Raum kann auch auf andere Art durchlaufen werden als in den angegebenen Szenario. In 

diesem Fall entdecken wir Lücken in der Darstellung der Anwendung. Die Stories werden durch einen Plot 

in diesem Entwurfsschritt verfeinert. Das Plot ist eine Anordnung der Ereignisse des Story-Raumes. In der 

Dramaturgie (Film, Drama, Erzählung, Musik) wird oft nur eine einzelne Story zur Grundlage genommen. In 

der Architektur sind Plots nichtlinear. Plots umfassen 

• die Raumplanung und die Raumordnung für die Stories, d.h. die Planung und den Ablauf der Szenen, 

• den allgemeinen Ablauf der Themen, 

• Prinzipien zur Szenographie und zum Aktionsraum, 

• die Aktionen der Darsteller und Akteure, 

• Prinzipien der Komposition und des Klangbildes, die als Qualitätsparameter dargestellt werden können, 

und 

• Prinzipien der Akzeptanz und Aufnahme (in der Dramaturgie der Musik: Melodie und Rhythmus). 

Es ist offensichtlich, daß nicht alle Plots in der gleichen Form dargestellt werden können. Die Plots werden für 

die Ausarbeitung der Szenario aufbereitet. Das vorhandene Material wird auf eine einfache und klare Handlungsfolge 

reduziert. Die Story wird damit konkretisiert bzw. verfeinert. In der Story sind keine detailliert 

ausgearbeiteten Szenen enthalten, dies trifft auch für das Szenario zu. Es enthält die Szenenabfolge und alle 

Dialoge. In das Szenario fließt bereits die gesamte Informationsfülle ein. Sobald wir uns für eine bestimmte 

Auswahl entschieden haben, kommen neue Informationen hinzu. Sie ergeben sich aus dem bisher Betrachteten. 

Damit ‘entwickelt sich das Szenario selbst’. Es werden auch Unzulänglichkeiten und Fehler sichtbar. 

Die einzelnen Szenen kann man sich durch überlappende Blöcke darstellen. Da eine Information und eine 

Aktion noch nachwirken kann bzw. antizipiert wird, sind die Szenen nicht vollständig trennbar. 

Mit der Szenenentwicklung betten wir auch die Dialoge in die Handlungen und die Daten ein. Handlungen sind 

Folgen von Aktionen. Aktionen benötigen Daten als benutztes Wissen, für die Ein- und Ausgabe. Eine Sicht 

entspricht dann einer oder mehreren Aktionen. Damit wird für die Szenarien auch die Darstellung von Motiv, 

Absicht und Ziel weiter verfeinert. 

Ein Motiv kann zu einer Absicht führen. Einer Absicht liegt gewöhnlich ein Wunsch zugrunde, ein bestimmtes 

Ziel zu erreichen. Jede Aktion führt zu einem (meist erwünschten) Ergebnis. Hinter jeder Absicht steckt ein 

Ziel. Keine Aktion erfolgt ohne Grund. Das Motiv ist die Ursache der Aktion. Zwischen Ursache und Wirkung 

besteht eine direkte Verbindung. 

Absichten haben verschiedene Eigenschaften, sind direkt, indirekt, bewußt, unbewußt, freiwillig, unfreiwillig, 

offensichtlich oder versteckt. Kann eine Absicht nicht verwirklicht werden, entsteht ein Konflikt oder evt. auch 

nur ein Gegensatz. 

Das Ziel orientiert auf ein in der Zukunft liegendes Ereignis, das durch eine Absicht herbeigeführt werden soll. 

Beide Kategorien können beliebig weit auseinander liegen. 

Zwischen den Aktionen gibt es Verknüpfungspunkte. Absichten können auch von einer Gruppe von Akteuren 

bzw. von Akteuren mit verschiedenen Rollen gleichzeitig getragen werden.


Ein Szenario muß auch akzeptabel sein. Damit werden Benutzerbedürfnisse anhand der Spezifikation des Szenarios 

geprüft. Dabei konzentrieren wir uns auf folgende Probleme: 

Verständlichkeit: Jedes Szenario und jede Szene muß verstanden werden. Deshalb ist Klarheit und Verständlichkeit 

oberstes Gebot, wobei die Inhalte für alle Anwender (ggf. auch weltweit) die gleiche Semantik 

besitzen müssen. Der Benutzer kann nur entsprechend seinen Erfahrungen fehlende Teile antizipieren. 

Er soll vom Motiv auf die Absicht und von der Absicht auf das Ziel schließen können. Sind wesentliche 

Teile unverständlich, dann kann er keine Schlußfolgerungen ziehen. Der Benutzer will Informationen, 

die er noch nicht kennt, d.h. es werden neue Informationen geliefert, die sich anhand des Allgemeinwissens 

einordnen lassen. Bei der Vermittlung von z.T. komplexen und tiefgründigen Inhalten ist besondere 

Sorgfalt bei der Ausschöpfung aller Darstellungsmöglichkeiten notwendig. 

Plausibilität: Ein Szenario muß plausibel sein und sollte sich an die gewohnten Arbeitsweisen anlehnen. 

Der Stellenwert der Plausibilität und des Realismus ist dabei umgekehrt proportional zum Auffassungsvermögen 

und Ausbildungsgrad. 

Identifikation: Mit einem Szenario muß auch das Interesse der Akteure geweckt und wach gehalten werden. 

Für die Akteure muß eine enge Verflechtung zwischen dem Inhalt, den Prozessen und den Dialogen 

einerseits und der Arbeitsweise anderseits erreicht werden. Ein Benutzer soll sich mit ‘seinem’ System 

identifizieren können. Die Identifikation hat eine ganze Reihe von erwünschten Auswirkungen und ist ein 

wesentlicher Grund für die Akzeptanz eines Systemes. 

Für das Szenario bewerten wir abschließend seine Qualität. 

Vollständigkeit: Alle Szenen sind vollständig und bis ins Detail ausgestaltet. 

Bedürfnisgerecht: Die Aktionen, Informationen und Dialoge entsprechen den Bedürfnissen der Akteure. 

Didaktisch aufbereitete Granulierung: Informationen können in der Granulierung auch einen Akteur überfordern, 

was häufig bei einer direkten Übertragung von Darstellungen mit Printmedien vorkommt. 

Inhaltliche Konsistenz: Jede Aktion, jede Information, jeder Dialog besitzt einen lokalen und einen globalen 

Kontext. In beiden sollten Widersprüche vermieden werden. 

Resultat dieses Schrittes ist ein Storyboard mit einer detaillierten Beschreibung der Szenen. Es werden die 

Stories aus dem Pflichtenheft mit den Ereignissen durch Plots und Themen verfeinert. Diese Szenen wiederum 

werden schrittweise untersetzt durch einzelne Aktionen der Akteure. Das Storyboard zeigt die Anwendung aus 

der Sicht des Benutzers. Oft werden dazu auch graphische Repräsentationen benutzt. Eine solche Repräsentation 

wird bei Website-Entwicklungen Mockup genannt. Ein Mockup stellt eine Folge oder allgemein partiell 

geordnete Menge von Themen dar unter Einbezug der Gestaltungsmittel der visuellen Gestaltung. 

Für das Drehbuch werden die Szenen des Storyboards weiterentwickelt. Durch das Drehbuch wird die Art und Weise, 

in der die Geschichte realisiert werden soll, spezifiziert. Ein Drehbuch spezifiziert eine Story bzw. den 

gesamten Story-Raum im Detail. Das Drehbuch ist eine konzeptionelle Repräsentation des Handlungsablaufes 

aller Facetten der Anwendung. 

Das Drehbuch basiert auf Szenen, die miteinander durch explizite Übergänge verbunden sind. Die Szenen 

selbst realisieren entsprechende Aktionen von Akteuren, die durch Dialogschritte dargestellt werden. Diese 

Aktionen können durch kurze prägnante Beschreibungen charakterisiert werden. Wir streben dazu auch eine 

Kurzcharakterisierung an. Dazu benutzen wir Verben oder auch Substantive. Diese Worte werden als Wortfelder 

dargestellt. 

Eine Szene ist dann ein algebraischer Ausdruck von Dialogschritten. Die Algebra muß dazu auch die Parallelität 

von Schritten berücksichtigen. Einer Szene sind Akteure mit entsprechenden Rollen und Aufgaben 

zugeordnet. Eine Szene nutzt ein Medien-Objekt. Ein Dialogschritt wird unter Beteiligung einiger Akteure, die 

in die Szene involviert sind, ausgeführt. Dabei werden die Akteure einem Kontext zugeordnet. Dieser Kontext 

stellt insbesondere die technischen Rahmenbedingungen der Benutzung dar. 

Wir berücksichtigen für das Drehbuch auch Eigenschaften und Wirkungen auf den Benutzer. Damit wird das 

Drehbuch im wesentlichen von drei Faktoren bestimmt: von der Form, den Aktionen der Story und den Besonderheiten 

der Arbeitsweise der Endbenutzer. Wir können damit im einzelnen Folgearbeitspakete herausstellen:


Kategorisierung der Endbenutzer: Aktionen und Dialoge existieren nicht unabhängig von den Akteuren. Es 

können die Akteure kategorisiert und mit Charakteristika versehen werden. Dabei interessieren nur solche 

Details, die für den Verlauf der Dialoge von Bedeutung sind, d.h. wir erfassen einige Charakteristika 

und charakterisieren nicht etwa den Endanwender. In diesem Zusammenhang werden auch die Beziehungen 

der Endbenutzer soweit wie notwendig mit erfaßt. Die Kategorisierung sollte sich durch eine relative 

Beständigkeit auszeichnen. 

Aktionsphasen: So wie ein Verb Aktion bzw. Handlung verdeutlicht, kann auch Aktion in den drei Zeitdimensionen 

dargestellt werden, die untrennbar miteinander verbunden sind. Eine für die Zukunft geplante 

Aktion weist auf ein bevorstehendes Ereignis. Ihr geht eine Absicht und damit ein Motiv voraus, die sich 

einem allgemeinen Plan des Szenarios unterordnet. Ereignisse, die in der Vergangenheit stattfanden, sind 

in ihrem Zeitbezug auch darzustellen. 

Aktive und inaktive Zustände: Szenen können, aber müssen nicht zu einer Aktivierung führen. Deshalb kann 

auch ein Szenario vorsehen, daß einzelne Aktionen ‘schlummern’. Wir können diese Verzögerung durch 

lang andauernde Transaktionen darstellen. Die Implementierung wird damit jedoch komplexer. Bei inaktiven 

Zuständen fehlt ein Motiv für eine Aktion oder es liegt eine Störung vor. Zur Spezifikation ziehen 

wir deshalb auch die Kategorisierung der Endbenutzer mit heran. Wenden Benutzer Aktionen an, ohne 

agieren zu können, dann liegt ein Konflikt vor. Ein Beispiel dafür ist das exklusive Schreiben von Daten 

für höchstens einen Benutzer. Dazu benötigen wir eine Konfliktlösungsstrategie je nach Intensität der Absicht 

und unterscheiden Hindernisse von Komplikationen und diese von Gegenabsichten. Unkritisch sind 

dagegen inaktive Zustände, die nach Erreichen eines Zieles erreicht wurden. 

Hauptabsichten und Teilabsichten: Gewöhnlich ist ein Geschäftsprozeß bzw. ein Szenario keine Kette von 

Ereignissen. Wir finden ein Netzwerk von Motiven, Absichten und Zielen vor. Die Absichten können 

in Teilabsichten, die den Hauptabsichten dienen, und Hauptabsichten kategorisiert werden. Damit ergibt 

sich auch eine zeitliche Ordnung und eine Variation in der Reihenfolge. Dabei können die Absichten 

gemeinsam dargestellt werden, die sich einem gemeinsamen Zweck unterwerfen (Gesetz von der Einheit 

des Zwecks). Teilabsichten sind Änderungen unterworfen, Hauptabsichten dagegen nicht. Teilabsichten 

sollten stets beendbar sein. Sie besitzen auch Hilfsziele. 

Wirkungen auf den Benutzer: Die Art und Weise, wie verschiedene Kategorien von Benutzern in ihren Rollen 

auf Ereignisse reagieren, wird in die Gestaltung des Drehbuches mit einbezogen. Wir untersuchen dazu 

für die Benutzergruppen auch die Antizipationsfähigkeit, den Erfahrungsschatz und die Fähigkeiten zur 

Bewältigung von Schwierigkeiten und benutzen für die Gestaltung der Szenen diese Informationen. Eine 

kluge und durchdachte Ereignisstruktur ist Voraussetzung für eine Akzeptanz der Dialoge. Der Benutzer 

soll in der Lage sein, die Distanz zum Erreichen des Ziels abzuschätzen, wozu auch eine Umstellung der 

Szenen beitragen kann. 

Eigenschaften der Darstellungsmedien: Der Entwickler kann sich vieler Medien bedienen, um alle Bestandteile 

einer Szene dem Akteur mitzuteilen. Es müssen Dialoge, Geräusche, Handlungen, Dekorationen, 

Darstellungsobjekte und Musik in konsistenter Form eingesetzt werden. 

Damit ist das Verfassen ebenso wie alle anderen Schritte der Entwurfsschicht nicht nur zu eine schöpferischen 

Tätigkeit, sondern ist vor allem auch ein Handwerk, das sich an Regeln der Handwerkskunst orientiert. Am 

Ende entsteht auf der Grundlage des Szenarios, der Story und der Ideen ein ausgereiftes Drehbuch. 

Die Szenenfolge wird anschließend auf Variation, Veränderung und Kontrast untersucht. Für die einzelnen 

Szenen sind die Verbindungen explizit zu modellieren. Deshalb werden evt. zusätzliche Verbindungselemente 

aufgenommen. Nicht alle Szenen sind miteinander gleich eng verbunden. Es lassen sich Szenenblöcke (Akte) 

mit besonders starken Verbindungselementen bilden. 

Nach der Fertigstellung des Drehbuches sollte man den Entwicklungsprozeß umkehren und eine Zusammenfassung 

des vorliegenden Drehbuches schreiben. Diese Zusammenfassung ist dann mit dem Storyboard, dem 

Story-Raum und den Ideen und Motiven zu vergleichen. 

Für das Drehbuch bewerten wir abschließend seine Qualität, d.h. insbesondere die folgenden Qualitätskriterien:


Benutzerführung: Die Akteure benötigen neben einer angepaßten Hilfe auch eine Führung durch komplexe 

Prozesse. 

Differenzierung: Es werden die unterschiedlichen Kategorien von Akteuren unterstützt. 

Medienmix: Die Medienauswahl erfolgt an den Inhalt angepaßt. 

Hypermediale Struktur: Es werden die Aktionen, Informationen und Dialoge in einer benutzergerechten Form 

geboten, die ein Verlieren im ‘Cyberspace’ verhindert. 

Verbindung von Arbeit und Vergnügen: Da eine multimediale Darstellung auch eine ‘Emotionalisierung’ der 

Darstellung erlaubt, ist der Einsatz dieser Mittel zu konzipieren. 

Konsistenz: Jede Szene muß an sich und auch in ihrem Kontext konsistent sein. 

Erwartungskonformität: Die Erwartungen der Akteure sind für unterschiedliche Szenen verschieden. Dabei 

sind auch verschiedene Kategorien von Akteuren zu beachten. 

Für die Inszenierung wird die Form der Dialoge und damit der Präsentationsraum bestimmt. Wir entwickeln in 

dieser Schicht die Arbeitsoberflächen für jeden Dialogschritt im einzelnen. Ebenso wie das Storyboard den 

Handlungsrahmen nicht verändert, wird durch die Inszenierung das Drehbuch nicht verändert. Es werden die 

einzelnen Szenen und Dialogschritte des Szenenraumes ausgeschmückt. 

Die Spezifikation der Dialogschritte im Drehbuch basiert bereits auf einem Rahmen. Wir können diesen Rahmen 

als Start für die Spezifikation eines Gestaltungsrahmens oder zumindest eines Gestaltungsrasters für die 

Gestaltung der Oberflächen benutzen. Es stehen neben Rahmen für Fenstersysteme auch Rahmen für beliebig 

formatierbare Dokumente zur Verfügung. Ein solcher Rahmen wird in Analogie zu den üblichen Beziehungen 

Anwendungsgebiet Element allgemeine Struktur 

Datenbanksysteme Tupel Relationen-Typ 

XML-Technologie XML-Dokument XSchema-Suite oder DTD-Suite 

Benutzer-Schnittstellen-Technologie Fenster Stil-Regeln 

XML-Generatoren XSL-Regel ??? 

Kommunikationssysteme ??? ??? 

entwickelt. 

Diese Rahmen sind etwas komplexer als die Stil-Regeln für Benutzer-Schnittstellen, weil wir auch die Anwendergruppe, 

deren Profile und deren Portfolio mit berücksichtigen wollen. Zur Gestaltung entwickeln wir 

Gestaltungsrahmen, die die Art der Gestaltung, die allgemeinen Prinzipien und den Umgang mit multimedialen 

Elementen darstellen. Mit dem Gestaltungsrahmen wird vorgegeben, wie die Oberflächen gestaltet werden. 

Außerdem sollen die Arbeitsoberflächen das Arbeiten mit dem System vereinfachen. Dazu erscheint es günstig, 

auch die Art des Zusammenwirkens, die Beziehungen der unterschiedlichen Akteure und die Darstellung des 

Zusammenwirkens durch den Arbeitsplatz zu kanonisieren. Dafür werden entsprechende Kommunikationsrahmen 

entwickelt. Die Art der Kollaboration bzw. Kooperation, die Art des Zusammenwirkens und der Arbeitsplatz 

werden mit berücksichtigt. 

Wir berücksichtigen neben den bereits diskutierten Eigenschaften von Oberflächen die folgenden Gestaltungsmöglichkeiten. 

Multimediale Darstellung: Einziger Zweck der Oberfläche ist es, etwas mitzuteilen. Sie ist niemals Selbstzweck, 

sondern steht im Dienste der Arbeit mit den Informationen. Durch die Einengung auf den Bildschirm 

wird die ‘Vermittlung einer Botschaft’ auch eingeschränkt. Eine Folge von Bildschirmen soll 

weder ermüden noch von der eigentlichen Arbeit ablenken. 

Zugleich kann eine Oberfläche mehr Informationen vermitteln als ein einfaches Foto. Es werden Aktionen 

und Objekte in der Wechselwirkung sichtbar. Die ‘Dekoration’ ist jede Art von Hintergrund. Die Requisite 

kann entweder zur Dekoration oder zum Akteur gehören. Lichtwechsel und das Aussehen von Requisiten 

dienen der Gestaltung von Oberflächen. 

Eine multimediale Arbeitsumgebung schließt die Verwendung von Tönen ein. Töne sind ebenso eine 

Informationsquelle. Die wichtigste Funktion des Tones liegt im Dialog mit dem Akteur. Er ist die bei 

weitem einfachste Form der Faktenübermittlung. Er sollte jedoch nur dann angewandt werden, wenn


andere Ausdrucksmöglichkeiten voll ausgeschöpft sind. Demgegenüber kann jede Aktion von bestimmten 

Geräuschen begleitet sein. Hintergrundmusik ist ein Bestandteil der Tonebene, jedoch i.a. nicht der 

Geschichte. Es können damit auch Informationen vermittelt werden. 

Informationsquellen: Jede Oberfläche, jeder Dialogschritt vermittelt Informationen. Damit wird eine Oberfläche 

zur Informationsquelle. Die Vielfalt der Informationen kann auch durch die Kombination verstärkt, 

abgeschwächt oder auch beigeordnet werden. Durch eine neue Information kann auch eine Veränderung 

implizit angezeigt werden. Wird die Information komplexer, dann ist die Wiederholung ein nützliches 

und angebrachtes Mittel. Verdopplung kann verwendet werden, um Daten, die benötigt aber evt. vergessen 

werden, wieder in Erinnerung zu bringen. Typische Verdopplungsfunktionen sind Statusleisten. Sie 

sind jedoch mit Vorsicht zum richtigen Zeitpunkt mit der richtigen Information anzuwenden. Die Vielfalt 

an zu vermittelnder Information ist in geschickter Anordnung (Arrangement, Koordination) dem Akteur 

zu vermitteln. Dabei ist auch die semantische Konsistenz zu beachten. Widersprüche deuten auf Fehler 

hin. 

Informationsquellen dürfen nicht mit Symbolismus verwechselt werden, der eher eine ungeeignete Art 

der Bildkonzeption ist. 

Bildauswertung und Bildkomposition: Jede Szene in der Inszenierung und jede Oberfläche besteht aus kleinen 

Einheiten, die wiederum aus kleinen Einheiten zusammengefügt sein können. Sie setzen sich zu einer 

Einstellung zusammen, die sich auch je nach Betrachtungspunkt verändern kann. Das Blickfeld selbst ist 

begrenzt. Es wird nur ein relevanter bzw. wichtiger Ausschnitt gezeigt, d.h. die informationsträchtigen 

Elemente, die zur gleichen Aktion gehören, werden als Elemente einer Einstellung zusammengefaßt. Eine 

gute Einstellung hält mit den Aktionen und ihren Zielen Schritt. Mitunter ist die Reaktion wichtiger als 

die Aktion. Wir unterscheiden dabei verschiedene Einstellungstypen (Groß-, Nah-, halbtotale etc. Einstellung). 

Jede Einstellung kann auf unterschiedliche Weise informationsvermittelnden Fakten entsprechen. 

Eine Einstellung kann auch dynamisch sein und trägt damit u.a. der Verlagerung des Interesses Rechnung. 

Ein Einstellungswechsel darf nicht zu kraß sein. Die Szenarien sollen durch eine nahtlose Verbindung 

von Einstellungen zusammenhängen. Mittel der Abgrenzung wie Auf- und Abblende sind deshalb in den 

Entwurf mit einzubinden. 

Einzelszenen: Die Einzelszenen können auch aus mehreren Einstellungen bestehen. In diesem Fall sind auch 

mehrere Sichten auf die Datenbank zu integrieren. Ereignisse sind in den Szenen selbst enthalten. Einzelszenen 

sind durch ihren Ort, ihre Zeit (Zeitpunkt, Laufzeit, Länge) mitbestimmt. Eine kunstvolle Zusammenstellung 

von Elementen verbessert nicht unbedingt die Qualität der Inszenierung, es kann dadurch 

die Aufmerksamkeit der Arbeit entzogen werden. Damit wird die Exposition von Ort und Zeit zum Entwurfsproblem. 

Auswahl der Informationen: Ein Szenario wird durch den Akteur als eine Folge von Einzelinformationen 

beobachtet. Alle Informationen beruhen in der Inszenierung auf Selektion. Es werden bestimmte Szenen 

herausgehoben oder auch nur angedeutet. Jede Information zieht auch weitere Informationen nach sich. 

Voraussetzung für die richtige Informationsauswahl ist daher die Kenntnis aller Fakten über den Dialogablauf 

und die zugrundegelegten Funktionen und Daten. Es können zu wenig, zu viel oder die korrekte 

Anzahl von wichtigen Fakten in den Entwurf eingehen. Dies trifft insbesondere auch auf die Darstellung 

der Begleitinformation zu. Zugleich werden die Vorkenntnisse der Benutzer mitberücksichtigt. 

Der Informationspflicht am Anfang eines Szenarios muß in stärkerem Maß nachgekommen werden. Man 

kann auch Informationen, die später benötigt werden, vorher ‘säen’. 

Die Verteilung der Informationen unterliegt ebenso wie die Verteilung von Wissen und Nichtwissen komplizierten 

Gesetzmäßigkeiten und verstärkt die Wichtigkeit der Informationsvermittlung. Durch eine ungeschickte 

Verteilung können auch Mißverständnisse hervorgerufen werden. 

Die Inszenierung bietet mit einer multimedialen Ausgestaltung des Drehbuches eine Vielfalt von Möglichkeiten, 

die, gerade weil sie existieren, danach verlangen, genutzt zu werden. Damit werden jedoch neue Hindernisse 

aufgetürmt, die die erfolgreiche Nutzung erschweren. Es ist nicht möglich, das gesamte Hintergrundwissen 

und den ‘common-sense’ in die Ausgestaltung zu integrieren. Obwohl wir viele Ereignisse präsentieren


können, ist es schwierig, sie klar und verständlich zu präsentieren, weil i.a. keine beschreibenden und erklärenden 

Manual-Kurzgeschichten hinzugenommen werden sollten. 

Abschließend bewerten wir die Qualität der Inszenierung. 

Zieltechnik: Die Zieltechnik beeinflußt in sehr starkem Maße die Qualität und auch die Implementierbarkeit 

von einzelnen Szenen. 

Einheitlichkeit: Neben Standardinteraktionen besitzen wir auch aus dem Inhalt abgeleitete Interaktionen. Eine 

Vereinheitlichung ist dabei angebracht. 

Professionelles Design: Ein System soll einen Akteur nicht unterfordern, nicht überfluten und auch ein einfaches 

Wiedereinsteigen ermöglichen. Damit sind auch die Dialoge professionell zu gestalten. 

Fehlerrobustheit: Eine Fehlbedienung darf weder zum ‘core dump’ noch zu unkontrollierbaren Zuständen 

führen. Ein Akteur muß selbst aus einer Fehlersituation wieder herausfinden. 

Hierarchie der einzelnen Szenen: Da die Szenen geordnet werden, ist auch dem Akteur eine wiederholte Anwahl 

von einzelnen Szenen zu gestatten, so daß auch ein konsistentes, nach- und rückverfolgbares Szenenmanagement 

einen Benutzer unterstützen muß. 

Farbauswahl: Wie jedes andere Darstellungsmittel sind auch die Farben mit einer semantischen Bedeutung 

zu versehen. 

Darstellungsskalierung: Je nach Akteur, je nach vorhandenem Client oder Darstellungsmedium sind unterschiedliche 

Interaktionsmöglichkeiten vorzusehen. 

Offene Systeme: Ein Informationssystem wird in immer stärkerem Maße mit anderen Systemen in integrierter 

Form verwendet. Deshalb ist der Output für einige Standards mit aufzubereiten. 

Erweiterbarkeit: Ein Informationssystem beginnt aufgrund der Änderungen in der Anwendung selbst, in den 

Profilen der Akteure und durch Hinzunahme von Funktionalität bald nach der Erstellung ‘zu leben’. Die 

möglichen Erweiterungen sollten antizipiert werden. 

Auswahl der multimedialen Medien: Ein Akteur sollte entsprechend seinem Benutzerprofil die Interaktion 

und die benutzten multimedialen Formen selbst und evt. auch dynamisch auswählen können.


6.6 Der Kollaborationsrahmen 

Wir unterscheiden zwischen Kooperation, Koordination und Kommunikation. Diese drei Formen der Kollaboration 

werden im nächsten Abschnitt im Detail behandelt. Kollaboration zwischen Akteuren wird im Rahmen der Spezifikation 

des Story-Raumes und im Rahmen der Spezifikation der Verteilung dargestellt. Es werden unterschiedliche 

Aspekte für den Story-Raum dargestellt. Hier sind die allgemeinen Aspekte von Bedeutung. Für die Spezifikation der 

Verteilung werden diese Aspekte verfeinert und im Detail angegeben. 

Der Kooperationsrahmen soll bei der Inszenierung eine automatische Generierung der Oberflächen für die einzelnen 

Dialogschritte unterstützen. Im einzelnen ist der Kooperationsrahmen spezifiziert durch Angaben zu: 

Koordination bzw. Kooperation: Wir unterscheiden zwischen Koordination und Kooperation. 

Charakterisierung nach Koordinationsformen: Eine Koordination von Akteuren erfolgt für die Bewältigung 

von Arbeitsaufgaben. Diese Aufgaben werden mit einer Reihen von Koordinationstypen verbunden. 

Typische Koordinationstypen sind z.B. die Broker- bzw. Trader-Customer-Koordination, die Client- 

Dispatcher-Koordination oder die Publisher-Subscriber-Koordination. Sie stellen allgemeine entfaltbare 

Workflows dar, bei denen der Ablauf der Koordination durch entsprechende verfeinerbare Dialogschritte 

gekennzeichnet wird. Diese Koordinationstypen werden im weiteren zum Austauschrahmen zur Spezifikation 

der Verteilung erweitert. Der Austauschrahmen umfaßt die gesamte Kollaboration. 

Charakterisierung nach Kooperationsformen: Kooperation zwischen Akteuren basiert auf einer Darstellung 

des Arbeitsprozesses, einer Angabe des Organisationsmodelles und einer Darstellung des Arbeitsplatzes 

bzw. Arbeitsraumes. 

Die Kooperationsformen zum Erreichen der Ziele werden im Rahmen der Kooperation der Benutzer 

abgeglichen. Es sind sowohl spezifische Formen der Interaktion als auch des Reviewing und der Kontrolle 

zu vereinbaren. 

Die Rollen bei der Kooperation werden für die einzelnen Benutzer im Detail festgelegt. 

Charakterisierung der Formierung: Wir unterscheiden unterschiedliche Arten der Formierung von Gruppen 

in 

inhaltsbezogene Formierung, bei der der Kooperationsrahmen durch Ziel und Portfolio determiniert 

wird, 

arbeitsweise-orientierte Formierung, die eine Anpassung der Content-Objekte an die z.Z. präferierte 

bzw. im nächsten Schritt erwartete Arbeitsweise ermöglicht, und 

Formierung durch Selbstorganisation der Gruppe, die eigenständig die Inhalte, den Zeitpunkt und 

den Arbeitsraum bestimmt. 

Charakterisierung nach Raum und Zeit: Wie bereits dargestellt, können wir bei einer Zusammenarbeit unterschiedliche 

Content-Objekt-Zuordnungen und Zeiträume darstellen. 

Gleiches Content-Objekt und synchrone Zusammenarbeit: Ein typische Form dieser Zusammenarbeit 

sind Brainstorming-Sitzungen. 

Gleiches Content-Objekt und asynchrone Zusammenarbeit: Ein typische Form dieser Zusammenarbeit 

kann man in Videokonferenzen beobachten. 

Verschiedene Content-Objekte und synchrone Zusammenarbeit: CASE-Werkzeuge realisieren diese 

Art der Zusammenarbeit. 

Verschiedene Content-Objekte und asynchrone Zusammenarbeit: Diese Zusammenarbeit ist z.B. 

für elektronische Post typisch. 

Charakterisierung nach Kooperationsvertrag: Der Kooperationsvertrag dient dem Abgleich der Interessen 

der kooperierenden Benutzer. Es werden sowohl Absprachen zu den Inhalten als auch zu den zu wählenden 

Szenario sowie die Einordnung in Arbeitsräume und Zeiträume getroffen. 

Art des Zusammenwirkens: Kollaboration basiert auf einer expliziten oder impliziten Kommunikation, auf Regeln 

des Zusammenwirkens und einer Dramaturgie des Zusammenwirkens. Die Art des Zusammenwirkens wird oft


in kanonischer Form vorgegeben. In diesem Fall wird das Zusammenwirken durch kleine Szenario bestimmt, 

die miteinander kombiniert werden können. 

Die Art des Zusammenwirkens wird oft mit einem Vertrag der Kollaboration gekoppelt. Bestandteile des Vertrages 

sind die klassischen juristischen Fallfragen: 

“Wer” 

arbeitet zusammen (“wie”) 

“mit wem” 

zu welchem Gegenstand (“was” ) 

auf welcher Anspruchsgrundlage (“woraus”). 

Diese Fallfragen verallgemeinern wir zu Spezifikationsrahmen für die Art des Zusammenwirkens: 

Die Beziehungen der Anwender und die Beziehungen des Benutzers mit dem System können durch Beziehungsstrukturen 

dargestellt werden. Diese Beziehungsstrukturen können Ethikregeln unterliegen oder 

explizit formuliert sein. Wir können wie im Falle der aspekt-orientierten Programmierung auch auf allgemeine 

Beziehungsstrukturen zurückgreifen oder explizit die Einhaltung der allgemeinen Geschäftsbedingungen 

postulieren. 

Arten der Aktivität werden durch Verbgruppen mit Verben der Handlungen wie kaufen, lernen und informieren, 

ergative Verben wie fliehen, Prozeßverben wie einschlafen (ingressive Prozesse) und verblühen 

(egressive Prozesse) und Verben zur Beschreibung eines Zustandes wie schlafen oder haben relativ gut 

charakterisiert. Wir sind für Informationssysteme an der ersten und der letzten Verbgruppen stärker interessiert. 

In diesen beiden Gruppen unterscheiden wir 

• Verben des Geschehens, 

• Verben des Zunehmens, 

• Verben der Übereinstimmung/Verschiedenheit, 

• Verben des Mitteilung, 

• Verben des Argumentation, 

• Verben der Zustimmung, 

• Verben der Leitung, 

• Verben des Zusammentreffens, 

• Verben der sinnlichen Wahrnehmung, 

• Verben der Nahrungsaufnahme und 

• Verben des Reinigens. 

Die ersten acht Gruppen sind für Informationssysteme relevant und können zu speziellen Kooperationsrahmen 

verwendet werden. 

Diskurstypen in der Zusammenarbeit können nach der Konversationstheorie unterschieden werden in: 

Handlungen: Es wird der Partner zu einer Handlung aufgefordert. 

Klärung: Es erfolgt mit dem Partner eine Klärung. 

Entscheidung: Es wird mit dem Partner eine Entscheidung getroffen. 

Orientierung: Es wird dem Partner eine Orientierung für dessen Tätigkeiten gegeben. 

Wir können mit dieser Klassifikation der Arten des Zusammenwirkens in Erweiterung der Klassifikation Wer- 

2-Wem (2 steht für “to” (mit)) mit einem Muster der Form 

Provider Art des Inhaltes Art der Aktivität 

2 Kunde 

charakterisieren. Daraus ergibt sich für die Gestaltung von Websites eine Klassifikation in: 

E-Business-Sites: B(usiness) P(rodukt) 2V(erwaltung) kaufen , B P 2B kaufen , B P 2K(unde) kaufen , 

V I(nformation) 2K kaufen , K P 2 K kaufen ( bzw. C(ustomer) P 2 C kaufen ) 

Lern-Sites: B W(issen) 2K lernen , K W 2 K lernen 

Information-Sites: B I(nformation) 2G(ast) informieren , V I 2G informieren , K I 2G informieren


Arbeitsgruppen-Sites: A(rbeitsgruppe)2A agieren , A2Ginformieren, agieren 

Corporate-Identity-Sites: P(rovider) I 2G anschauen 

Unterhaltungs-Sites: B U(nterhaltung) 2G agieren , G U 2G agieren 

Arbeitsplatz: Der Content-Typ Arbeitsplatz soll die Kollaboration unterstützen. Er muß deshalb auch die Aspekte 

der Kollaboration berücksichtigen. Zur Darstellung benutzen und verfeinern wir die Kern-Typen des Content- 

Typs Arbeitsplatz: 

Akteure werden mit ihren Kollaborationsbeziehungen dargestellt. Sie umfassen 

Kooperationsbeziehungen, 

Koordinationsbeziehungen und 

Kommunikationsbeziehungen, sowie das 

Organisationsmodell. 

Gruppen verfügen über spezifische Formen der Kollaboration. Diese Kollaboration basiert oft auf relativ 

festgeschriebenen und demzufolge abzubildenden Beziehungsstrukturen. 

Rechte werden mit der expliziten Darstellung der Kollaboration in Rechte zu Kooperation, Koordination und 

zur Kommunikation untersetzt. 

Portfolio werden den Einzelaufgaben zugeordnet, wobei die Art des Zusammenwirkens auch die Art der 

Abarbeitung des Portfolios determiniert. 

Die Organisation wird durch die Darstellung der Dramaturgie der Kollaboration verfeinert. 

Der Kollaborationsrahmen wird noch einmal bei der Spezifikation der Verteilung betrachtet, dort allerdings mit 

einer Konzentration auf die technische Unterstützung. Zu Spezifikation der Kollaboration können wir die folgende 

Tabelle oder auch ein Arbeitsblatt wie bereits bei der Spezifikation der Szenen und der Dialogschritte verwenden: 


Kollaboration Art des Zusammenwirkens Arbeitsplatz 

Form Rollen Formierung 

Raum 

/ Zeit 

Vertrag 

Beziehungen 

Arten Diskurstyp 

Akteure 

Gruppe Rechte Portfolio 

... ... ... ... ... ... ... ... ... ... ... ... ... 

Organisation 

Wir unterscheiden die Kopplungsmechanismen nach Seite ?? in Interaktionskopplung (Kopplung im Story-Raum) 

Komponentenkopplung (Container-Kopplung) und Vererbungskopplung. Sie können auch im Kombination verwendet 

werden. 

Die Kohäsion kann analog zur Kohäsion auf Seite ?? durch die Bindung zwischen den einzelnen kooperierenden 

Objekten beschrieben werden.


6.7 Der Gestaltungsrahmen 

Durch die Spezifikation eines Gestaltungsrahmens kann in allgemeiner Form die Darstellung der gesamten Arbeitsoberflächen-Suite 

und des Präsentationsraumes in einheitlicher Form und auch mit der XML-Technologie erfolgen. 

Zur Gestaltung von Software und insbesondere von Dialogen nach ergonomischen Kriterien stellt die DIN-Norm 

66234, Teil 8 folgende Kriterien auf: 

Erwartungskonformität: Ein Dialog ist erwartungskonform, wenn sich die Erwartungen, Erfahrungen und bisherigen 

Handlungen der Benutzer im Dialog widerspiegeln. 

Steuerbarkeit: Ein Dialog ist steuerbar, wenn er sich dem augenblicklichen Arbeitsstil, der Geschwindigkeit und 

der Wahl der Arbeitsmittel anpassen läßt. 

Aufgabenangemessenheit: Ein Dialog ist aufgabenangemessen, wenn er die Erledigung der Arbeitsaufgaben unterstützt, 

ohne zusätzlich zu belasten. 

Selbstbeschreibungsfähigkeit: Ein Dialog ist selbstbeschreibungsfähig, wenn er entweder direkt oder indirekt 

(z.B. über adäquate Hilfen) verständlich ist. 

Fehlerrobustheit: Ein Dialog ist fehlerrobust, wenn trotz erkennbarer Fehler ein richtiges Resultat erzeugt wird. 

Bei der Bewertung von Benutzungsoberflächen können eine Reihe von Parametern betrachtet werden: 

Robustheit: Ein System darf durch eine falsche Handlung nicht in seinen wesentlichen Parametern (Benutzbarkeit, 

Durchlauf etc.) beeinflußt werden. 

Benutzbarkeit: Die Benutzbarkeit bzw. Brauchbarkeit kann durch verschiedene Parameter bewertet werden. 

Analytische Meßmethoden werden z.B. beim Vollständigkeitstest herangezogen. Damit kann ermittelt werden, 

ob alle benötigten Informationen auch dargestellt werden. 

Leistungsparameter sind z.B. die benötigte Arbeitszeit, die Fehlerrobustheit und die Zeitersparnis. 

Die kognitive Beanspruchung stellt die geistige Anstrengung des Benutzers dar. Stimmen das mentale Modell 

des Benutzers und die Reaktionen am Bildschirm überein, dann ist sie gewöhnlich gering. 

Die Benutzerzufriedenheit berücksichtigt die Nützlichkeit des Systemes für den Anwendungsbereich und auch 

den Lernaufwand zur Bedienung des Systemes. 

Die Modellierung von Benutzungsoberflächen umfaßt die Spezifikation verschiedener Bereiche: 

Dialogmethoden erfüllen unterschiedliche Zwecke. Wir können verschiedene Zugänge in realen Systemen finden: 

Eingabemasken entsprechen Formularen. Damit ist auch die Arbeitsweise determiniert. 

Befehle und Aufforderungen an den Benutzer werden zum Abruf von Daten benutzt. Dabei kann die Struktur 

durch meist deterministische Ablaufdiagramme dargestellt werden. 

Menüs können mehrere Optionen oder Funktionen, aus denen der Benutzer auswählen kann, darstellen. Menüs 

können auch als Popup- oder Klappmenüs gestaltet werden. 

Schaltflächen dienen zum Auslösen von Funktionen. 

Die Eingabemaske eignet sich am besten zur Eingabe von Informationen über eine semantische Einheit. Sie 

sind weniger für die Modifikation von Daten geeignet. Dazu ist eine Menüstruktur eher geeignet. 

Arbeitssicht: Eine Arbeitssicht (auch Arbeitsbereich in der Literatur) definiert alle Informationen, die für eine bestimmte 

Aufgabe benötigt werden. 

Layout: Durch das Layout wird die Darstellung der Informationen der einzelnen Arbeitsschritte beschrieben. 

Prozeßsicht: Durch die Prozeßsicht wird der Arbeitsablauf bzw. der Geschäftsprozeß der Anwendung spezifiziert.


Diese ergonomischen Prinzipien, die allgemein für Softwareprodukte entwickelt wurden, können zu Gestaltungsprinzipien 

weiterentwickelt werden bzw. von produktspezifischen Forderungen kann abgesehen werden. Wir führen als 

allgemeines Rahmenwerk Gestaltungsrahmen ein. 

Die Gestaltung von Schnittstellen besitzt eine Reihe von Analoga mit der Gestaltung von Werbematerial. Aus 

Optimierungsgründen sind jedoch kaum dessen gestalterische Möglichkeiten ausschöpfbar. Insbesondere sind die 

Effizienz und die Übersichtlichkeit zu beachten. Hinzu kommen aber auch zusätzliche Möglichkeiten. Werkzeuge, 

die z.Z. im Entstehen sind, werden auch Sprache, Gestik, intelligente Agenten und integrierte Multimedia (Panmedia 

ist ein besserer Begriff) einschließen. 

Graphiken von Web-Oberflächen werden immer noch mit Blick auf unbegrenzte Ressourcen entworfen. Mit 

dem Internet II aber auch schon bei einer Vermittlung von Informationen über Modems sollte man sich bei der 

graphischen Gestaltung auf die Informationsvermittlung besinnen und auf graphische Arabesken und Manierismen 

sowie intergalaktische Multimedia-Effekte verzichten. 

Oberflächen sollten im allgemeinen der Anwendungsphilosophie, der Anwendungslogik und dem Anwendungszweck 

folgen. Deshalb sollte eine Anwendung immer als Ganzes entworfen werden. Die Organisation der Oberflächen 

und die visuelle Struktur der einzelnen Oberfläche folgen der Anwendungslogik. Sind die Oberflächen zur 

Präsentation bestimmt, dann ist auch die Firmenstrategie mit einzubeziehen. Das Corporate Design - von der Werbung 

bei der Beratung teuer als das Entwurfswissen eingebracht - ist nicht von der Darstellung zu trennen. Bestimmte 

Bedienelemente wie z.B. die rechte Maustaste können für spezielle Effekte in einer ganzheitlichen Gestaltung reserviert 

werden. 

Die Informationsdarstellung, die Darstellung des Arbeitsprozesses und die davon abhängige Darstellung der 

Suchmechanismen sollte zum einem integriert erfolgen, zum anderen durch die Architektur in separaten Einheiten 

gehalten werden. Insbesondere sollten der Suchmechanismus und die verschiedenen Verknüpfungsnetze nicht mit 

der Information gemeinsam dargestellt sein. Eine Integration bedeutet keinesfalls die weitestgehende Unabhängigkeit 

der einzelnen Oberflächen voneinander aufzugeben. Verbindungen zwischen den einzelnen Oberflächen sind explizit 

darzustellen bzw. durch globale Techniken wie Zwischenablagen und dynamischen Datenaustausch zu unterstützen. 

Kontextsensitive Oberflächen, insbesondere solche, die von mehreren anderen abhängen, sollten vermieden werden 

oder nur mit einer hierarchischen Strukturierung angewandt werden. 

Eine Darstellung von Informationen sollte so einfach 3 sein, wie es die Informationsfülle zuläßt. Die Information 

ist übersichtlich zu gestalten. Durch geschickte Vernetzung von Oberflächen kann eine Übersichtlichkeit geschaffen 

werden, die weit über die Möglichkeiten von Printmedien hinausgeht. Durch verschiedene übergreifende Verzeichnisse 

kann eine Transparenz geschaffen werden, die eine umfassende und aktuelle Recherche in einfacher Form 

ermöglicht. Einfachheit impliziert auch Eleganz. Der Stil ordnet sich hier unter. Die Repräsentation und das Aussehen 

folgen auf dieser Grundlage. 

Einfache Oberflächen bedeuten auch minimale Wege sowohl für die Bedienung als auch für das Auge. Mengen 

von Oberflächen werden umso eher angenommen, umso mehr sie einer einheitlichen Strukturierung unterliegen. 

Die Verteilung der Funktionalität sollte einheitlich sein. Die Eingabeoberflächen benötigen eine einfache und übersichtliche 

Gestaltung. Sind aufgrund einer Informationsvielfalt mehrere Oberflächen notwendig, dann ist auch der 

Zusammenhang explizit darzustellen. 

Die Informationsdarstellung muß klar, einfach und intuitiv verständlich sein. Negative Information und negative 

Anfragen erfordern vom Benutzer ein genaues Verständnis der unterlegten Logik. Besser ist es, diese Information in 

positiver Logik zu formulieren. Farben können Information tragen. Sie sollten aber stets der Informationsdarstellung 

untergeordnet werden. In verteilten Anwendungen sollte man mit Farben sparsam umgehen und den Schwarz-Weiß- 

Test nicht auslassen. Warnhinweise sollten auch als solche unmißverständlich zu erkennen sein. Fehlermeldungen 

sollten kontextsensitiv, minimal und auch für den Normalbenutzer intuitiv verständlich sein. Die Darstellung von wesentlichen 

Informationen sollte plattformunabhängig erfolgen. Die Statusleiste kann auch eine Kurzhilfeinformation 

mit einbeziehen. Skalierung, Kontrast und Größenverhältnisse sind der Informationsdarstellung zu unterwerfen. 

Oberflächen sollten an die Fertigkeiten und Fähigkeiten der Benutzer angepaßt sein. Die Benutzer können nach 

den Kriterien von [Alt96] charakterisiert werden: positive Erfahrungen (wie z.B. Arbeitssprache), negative Erfahrungen 

(z.B. Fehler, Entscheidungen, Wortwahl) und Fertigkeiten bzw. Fähigkeiten (z.B. Wissen, motorische, visuelle 

Fertigkeiten, Abstraktions- und Formulierungsfähigkeiten etc.). Damit hat auch die Orientierung auf den Benutzer 

3 Vielleicht sollte man eher das “Small is beautiful” in den Mittelpunkt stellen.


Vorrang vor dem Testen von nichtstandardisierten Werkzeugen. Obwohl die Maus in vielen Anwendungen zum normalen 

Arbeitsinstrument geworden ist, sollte stets auch die Tastatur unterstützt werden. Sie ist meist schneller und 

bei sinnvoller Anordnung der einzelnen Arbeitsschritte kann sogar der Tabulator für das Beenden eines Teilschrittes 

und den Beginn des nächsten Teilschrittes benutzt werden. Sind unterschiedliche Gruppen von Benutzern zu berücksichtigen, 

dann sollte auch ein unterschiedliches Bedienniveau implementiert werden. Die Bediensprache ist dem 

Benutzer und seinem Anwendungsgebiet mit anzupassen. Jede Art von Benutzung führt zu einem Feedback durch 

das System. Damit wird einem Benutzer der nächste Schritt erleichtert. 

Weiterhin determinieren die Fähigkeiten der Benutzer und ihren Bedürfnissen, ob ein black-box-Zugang, der dem 

Benutzer Details der Implementation vollständig vorenthält, ein glass-box-Zugang, der dem Benutzer auch gestattet, 

die Arbeitsweise des Systems, insbesondere das input-output-Verhalten, zu verstehen und sein Verhalten dementsprechend 

zu verändern, oder ein Mix dieser beiden Zugänge anzustreben ist. 

Da eine Vielzahl von Oberflächen in einer Anwendung zu entwickeln sind, ist auch bei der Gestaltung die Wirtschaftlichkeit 

zu beachten. Die Oberflächen sollten generisch bzw. parametrisch sein oder zumindest einem Standard 

folgen, der mit der Anwendung korreliert. Die Wiederverwendung von existierenden Oberflächen erleichtert ebenso 

wie die Standardisierung das Erlernen der Benutzung. 

Die Effizienz und Aspekte der Sicherheit sollten durch das Dialogmangementsystem (oder falls kein System 

existiert, dann sind diese Probleme beim Entwurf der Oberflächen mit zu betrachten) optimierbar sein. 

Die Gestaltung von Oberflächen erfordert die Einbeziehung so unterschiedlicher Disziplinen wie Wahrnehmungspsychologie, 

Ergonomie, Soziologie, Informatik, Grafikdesign und Marketing in die Datenbankprogrammierung. In 

der ersten Näherung können die Gestaltungselemente (Typographie, Symbole und Piktogramme, Farbe sowie Proportion 

und Aufbau des Bildschirms) betrachtet werden.Hinzu kommen die Betrachtung der Eleganz und der Einfachheit, 

der Organisation und visuellen Struktur, der Anordnung und Bedienung, der Bilder und der Repräsentation und Stil- 

Zuordnung von Widget-Typen 

⋄ Sichten-Suite 

⋄ Funktionalität 

⋄ Strukturierung 

⋄ Fenster 

⋄ Menü, Operationsauswahl,... 

⋄ Konstantenfeld, Datenfeld, Gruppe 

Einfach-, Mehrfachauswahl, Liste, Tabelle,... 

Parameterfestlegung 

⋄ Strukturierung (Schemata), 

Name, Typ, Wertebereich, 

Vorbelegungen 

⋄ Standardwerte, Benutzerpräferenzen, 

Umgebungsbeschreibung, Stileigenschaften 

⋄ Wechselwirkung zwischen 

Arbeitsplätzen innerhalb einer Gruppe, 

gruppenübergreifend, 

Position, Ausrichtung 

✛ 

Standardwerte 

❄ 

⋄ Repräsentationstypen 

Fenster, Menü, Gruppe, 

Konstantenfelder, Datenfelder, 

Operationsauswahl, Liste, Tabelle 

⋄ Abb. abstrakter Content-Typen 

auf Zielsystem 

⋄ globale Festlegungen 

⋄ Geometrie 

⋄ Konfiguration der Generierung 

❄ 

Anordnung - Layout 

⋄ innerhalb einer Gruppe 

⋄ gruppenübergreifend 

⋄ Priorität 

⋄ Anwendungssemantik 

⋄ Gestaltungsgesetze 

❄ 

Abbildung 25: Die Vorgehensweise zur Zusammenstellung von Benutzungsoberflächen 

fragen. Auf dieser Architektur kann auch die Vorgehensweise zur Generierung von Benutzungsschnittstellen wie in 

Bild 25 aufgesetzt werden.


Der Gestaltungsrahmen soll uns eine allgemeine Beschreibung der Gestaltung erlauben und auch eine automatische 

Adaptierung oder Adaption an die Eigenarten der Benutzer, an die technische Umgebung und den Kontext 

im allgemeinen gestatten. Es sind bereits eine Vielzahl von Regeln zur Gestaltung von Graphischen Benutzungsoberflächen 

bekannt. Diese Regeln werden jedoch selten im Zusammenhang betrachtet. Mit der Spezifikation des 

Gestaltungsrahmens wollen wir jedoch auch den Zusammenhang in der Gestaltung betonen und zugleich auch eine 

Einheitlichkeit bei der Gestaltung realisieren. 

Der Gestaltungsrahmen erlaubt auch eine allgemeine Kategorisierung der Gestaltung und zugleich auch eine 

Assoziation mit Metaphern, die als gesamtheitliche Metaphern der gesamten Gestaltung unterlegt werden können. 

Wir kommen auf diese Anwendung am Ende des Abschnitt noch einmal zurück. 

Zuerst stellen wir unseren Zugang zum Gestaltungsrahmen vor. Der Gestaltungsrahmen ist durch 

Playout mit Werkzeugen, 

Layout, 

Metaphern, 

Akteure und 

Qualitätsanforderungen 

spezifiziert. 

Die unterschiedlichen Layoutentscheidungen werden in Monographien zu graphischen Benutzungsschnittstellen ausführlich 

behandelt. Für die Spezifikation des Gestaltungsrahmen wollen wir uns allerdings auf generelle Typen von Layoutentscheidungen 

konzentrieren. Deshalb wird nicht im Detail diskutiert werden, ob grün oder pastellgrün passende 

Farben sind. Die Charakterisierung der Akteure haben wir bereits bei der Spezifikation des Story-Raumes vorgenommen. 

Diese Spezifikation wird nun mit den Profilen und den Portfolios kombiniert. Die Qualitätsanforderungen 

haben wir bereits im Detail eingeführt. Wir werden sie jedoch im weiteren zu Qualitätsvorgaben für die Interfaces 

verfeinern. 

Die einzelnen Komponenten des Gestaltungsrahmens sind die folgenden: 

Werkzeuge zur Gestaltung der Benutzungsoberflächen in den 90er Jahren sind in einer Vielfalt entwickelt worden, 

daß eine Übersicht schwerfällt. Zugleich fällt ins Auge, daß fast alle diese Werkzeuge keine große Verbreitung 

gefunden haben. Eine Ursache ist sicherlich auch der Hang zur ‘featuritis’. 

Die Werkzeugentscheidung sollte sich an einer Klasse von Interfacewerkzeugen orientieren. Mit der Angabe 

von Gestaltungsrahmen werden sich auch stärker Typen von Interfacewerkzeugen herausschälen, wenn sich 

durch XML allgemeine Standards wie z.B. SVG zur Graphikdarstellung durchsetzen. 

Der Typ von Interfacewerkzeugen wird durch eine Darstellung folgender Parameter spezifiziert: 

Funktion: Die Werkzeuge können 

• einfache Funktionen zur Verfügung stellen z.B. wie HTML mit einer Reihe von Umgebungen, 

• komplexe Funktionen bereitstellen, mit denen z.B. auch ein Playout von Simulationen, analoge und 

digitale Video- und Audio-Dateien oder Kodierung, Fehlerbehandlung etc. unterstützt werden, 

• Kommunikations-, Kooperations- und Koordinationsfunktionen sowie Austauschformate unterstützen, 

• Bindungsfunktionen, mit denen Informationen und Content-Suiten eingebunden werden können, besitzen 

und 

• Verwaltungsfunktionen zur Verwaltung und Weiterführung von Sitzungen und Arbeitsräumen anbieten. 

Aufgabenklasse: Durch die Werkzeuge werden bestimmte Aufgaben unterstützt und ggf. auch nicht unterstützt. 

Es sind die Aufgabenklassen zu charakterisieren, die durch die Werkzeuge unterstützt werden. 

Paradigma der Darstellung: Die einzelnen Funktionen der Werkzeuge erlauben unterschiedliche Darstellungen 

wie z.B. ereignisorientierte, objektorientierte oder zustandsorientierte Darstellung der Funktionsabarbeitung.


Kollaboration: Die Funktionalität der Werkzeuge kann ggf. auch einem Benutzer seinen Schreibtisch, einer 

Gruppe einen Arbeitsraum, eine Kollaborationsunterstützung oder auch Arbeitsspeicher bereitstellen. Die 

Kollaborationsunterstützung basiert auf einer Architektur zur Unterstützung der Kollaboration. Die Kollaboration 

erfordert ggf. auch langlebige Transaktionen und auch das Anlegen von temporären Klassen 

sowohl beim Benutzer als auch beim Server. Die Kollaboration kann über unterschiedliche Kanäle erfolgen. 

Leistung: Werkzeuge stellen Funktionalität in einer bestimmten Qualität und mit einer bestimmten Kompetenz 

zur Verfügung. Die Spezifikation der minimalen Qualitätsanforderungen wie Allgegenwart und 

Sicherheit ist mit dem Gestaltungsrahmen vorzugeben. 

Layout: Das Benutzungsinterface soll dem Akteur ein einfaches Agieren zur Bewältigung seiner Aufgaben gestatten. 

Es kann in allgemeiner Form die Art des Benutzerinterfaces durch einen Layout-Guide vorgegeben werden. 

Layout-Guides können sich an die ‘corporate identity’ des Betriebes anlehnen, können unterschiedlichen 

Gestaltungsrichtlinien folgen und auch durch entsprechende Regelwerke an den Kontext und die Benutzung 

adaptiert werden. 

Die Gestaltung von Schnittstellen sollte den oben dargestellten Prinzipien der Ergonomie und der Psychologie 

folgen. Dazu gehören auch Prinzipien der visuellen Gestaltung. 

Das Layout wird durch eine Spezifikation folgender Parameter vorgegeben: 

Metapher: Ein System soll sich dem Benutzer in einer einheitlichen Form präsentieren, wobei die allgemeine 

Arbeitsumgebung ebenso wie eine bevorzugte Form der Darstellung mit einbezogen wird. In unserem 

Beispiel kann z.B. die Raumplanung mit einer Reiter-Darstellung, die Vorlesungsübersicht durch hierarchische 

Strukturen unterstützt werden, die dem Studienplan und der Lehrstuhlübersicht folgen, unterstützt 

werden. 

Screen-Layout für Funktion und Interaktion: Funktionen und insbesondere Interaktionsfunktionen sind als 

besondere Gestaltungselemente durch eine entsprechende Typisierung einheitlich und schnell erkennbar 

gestaltet. 

Umsetzung der Prinzipien der (visuellen) Wahrnehmung: Schnittstellen sollen einfach , leicht zu überschauen 

und auch so zu bedienen sein, daß die Übersicht nicht verloren geht. Dazu sind Parameter der 

visuellen Wahrnehmung wie Ordnung und insbesondere Hierarchie, Wirkung auf bestimmte Akteure und 

auch der Schrittfolge durch eine entsprechende Struktur zu unterstützen. Daraus kann sowohl die vertikale 

als auch funktionale Navigation abgeleitet werden. 

Da auch multimediale Elemente eingebracht werden können spielt neben der visuellen Kommunikation 

auch die audio-basierte Kommunikation sowie auch andere Arten eine Rolle. Insbesondere für barrierefreie 

Systeme wird auf die anderen Kommunikationsmöglichkeiten zurückgegriffen. 

Umsetzung der Prinzipien der (visuellen) Kollaboration: Die unterschiedlichen Facetten der Kollaboration 

werden durch einen generellen Rahmen der Szenen, durch eine Abfolge der Szenen und durch didaktische 

Regeln bei der Erschließung des Story-Raumes allgemein dargestellt. Didaktische Regeln fassen 

sowohl die Redundanz der Kollaboration als auch die Erwartungskonformität. 

Ebenso wie für die Realisierung von Barrierefreiheit eine Unterstützung durch nicht-visuelle Kommunikation 

erforderlich. 

Berücksichtigung der Gestaltungsgesetze des Bildschirmes: Ein Bildschirm ist eine zweidimensionale 

Oberfläche, mit dem evt. auch dreidimensionale Effekte erzielt werden können. Die Gestaltung der Bildschirmoberfläche 

muß Gestaltungsprinzipien wie 

• dem Prinzip der visuellen Kollaboration in Abhängigkeit von den Arbeitsaufgaben, der Story und 

der Einfachkeit der Vermittlung, 

• dem Prinzip der visuellen Wahrnehmung basierend auf einer Abstimmung von Anordnung, Wirkung 

und Gliederung und 

• dem Prinzip der visuellen Gestaltung unter Berücksichtigung der Optik, der Ähnlichkeit, der Geschlossenheit, 

der Symmetrie, der Prägnanz und des Aufnahmeflusses 

angemessen berücksichtigen.


Akteure sind Gruppen von Benutzern. Die generelle Spezifikation der Akteure wurde bereits in diesem Kapitel 

dargestellt. Für den Gestaltungsrahmen nehmen wir eine Kategorisierung der Akteure vor nach 

Einordnung in Zielgruppen, 

Polaritäten-Profil, insbesondere das psychographischen Profil und nach 

Adaption an 

Profil, 

Portfolio und 

Benutzungsgeschichte etc. vor. 

Es werden außerdem die Erwartungshaltung, die allgemeinen Gruppeneigenschaften, der Bildungs- und 

Arbeitshintergrund klassifiziert. 

Qualitätsvorgaben: Informationssysteme sollen sich durch eine hohe Benutzbarkeit auszeichnen. Benutzbarkeit 

kann man auf Qualitätsanforderungen abbilden: 

Verständlichkeit: Es sind alle Funktionen, die Navigation und Aufforderungen unmißverständlich für einen 

Benutzer. 

Einfachheit Das System ist einfach gehalten. Das System lenkt nicht von der Lösung von Aufgaben ab. 

Erlernbarkeit: Es soll einem Benutzer, der das System das erste Mal benutzt, und einem Benutzer, der das 

System nach längerer Pause wieder benutzt, ein einfacher Einstieg in die Benutzung des Systemes ohne 

hohen Lernaufwand möglich sein. 

Diese Anforderungen kann man auf Merkmale des Systemes abbilden: 

Erscheinungsform des Interfaces: Das Interface ist einfach, nicht überladen, besitzt ein ansprechendes Layout 

und eine akteurbezogene Inhaltsgestaltung. 

Durchschaubarkeit des Story-Raumes: Der Story-Raum wird so optimiert, daß ein Benutzer seine Aufgaben 

mit dem einfachsten Szenarium bewältigen kann. Hilfreich ist hierbei eine angemessene Navigation 

im Story-Raum. 

Les- und Browsbarkeit des Content: Der Content soll in einer Form präsentiert werden, die sowohl das Lesen, 

als auch das schnelle Durchmustern erlaubt, die keine Sprachbarrieren aufbaut (weder fremdsprachig 

noch von der Umgangssprache her) und die sprachlich einfach ist. 

Vertrautheit und Nutzbarkeit: Ein Benutzer soll die Form der Benutzung und insbesondere die Szenario 

nicht erst erlernen, sondern sollte aufgrund seiner Erfahrungen das System einfach handhaben, einfach 

erlernen und schnell die Arbeit an beliebiger Unterbrechungsstelle wieder aufnehmen können. 

Diese Merkmale können mit entsprechenden Metriken unterlegt werden. 

Diese Forderungen wurden in der Cottbuser Arbeitsgruppe unter dem Begriff “omasicher” zusammengefaßt. 

• Ein Informationssystem sollte ohne zusätzliche Ausbildung, in einfacher Art, aufgrund von offensichtlichen 

Optionen, für jedermann, innerhalb des Erwartungshorizontes des Benutzers, mit kontextsensitiver 

Hilfe, mit entsprechender Wortwahl, mit einfachen Dialogen und Teilaufgaben benutzt werden können. 

• Es sollte stets der aktuelle, von Benutzer auch real angeforderte Inhalt in dem Moment präsentiert werden, 

in dem ihn der Benutzer auch benötigt. 

• Es sollten dem Benutzer keine nicht nachvollziehbaren Wartezeiten zugemutet werden. 

• Das System sollte einfach benutzbar sein, Fehler des Benutzers tolerieren, solange diese aufgelöst werden 

können und von hoher Benutzbarkeit sein. 

Wir fassen diese vier Forderungen unter dem Stichwort HOME zusammen: 

High quality content, 

Often updated, 

Minimal download time und 

Ease of use.


6.7.1 Die Dimensionen des Gestaltungsrahmens 

Wir können den Gestaltungsrahmen um weitere Perspektiven erweitern und zugleich die obigen Betrachtungen systematisieren. 

Der Gestaltungsrahmen kann mit sechs Dimensionen separiert werden: 


Story 

Metaphern 

zur Informationsdarstellung 

◆ 

Content 

❖ 

✒ 

✯ 

❯ 

Daten 

❨ 

❥ 

❥ ✙ 

Repräsentation 

der Daten 

✕ 

Benutzer 

✻ 

❄ 

✙ 

❥ ✙ 

Repräsentation 

der Prozesse 

Technische Umgebung des Benutzers 

✯ 

❨ 

☛ 

Prozesse 

✯ 

❨ 

❑ 

❨ 

✌ 


✗ 

Metaphern 

zur Story- 

Darstellung 

und Funktionalitätsunterstützung 

Layout 

Nutzungsraum 

Playout 

Abbildung 26: Dimensionen des Gestaltungsrahmens 

In der Dimension des Benutzers wird der Benutzer entweder als Akteur charakterisiert oder mit seinem Profil und 

Portfolio angegeben. Einbezogen wird das Polaritätenprofil. Ableitbar ist dann die Zielgruppe und die erforderliche 

Anpassung. 

In der Dimension der Daten werden die erforderlichen Sichten betrachtet. 

In der Dimension der Datenrepräsentation werden Parameter zur Gestaltung der Oberflächen wirksam wie 

• Form und Farbe, 

• Kontrast und Rhythmus und 

• Struktur und Komposition 

eingesetzt. 

In der Dimension der Prozesse werden die Abläufe der Story betrachtet. 

In der Dimension des Prozeßrepräsentation werden die entsprechenden Implementationen der Stories dargestellt. 

In der Dimension der technischen Umgebung des Benutzers werden die Potentiale der Verbindung, der Technik 

des Benutzers und der Server-Technik dargestellt. Diese Potentiale erlauben Effekte oder schränken diese stark 

ein. 

Diese Gestaltungsdimensionen können auch in kombinierter Art und Weise zur Gestaltung herangezogen werden: 

In den kombinierten Dimensionen Benutzer-Daten-Datenrepräsentation werden Metaphern zur Informationsdarstellung, 

mit denen ein Bezug auf die Benutzerwelten und die das Verständnis der Daten auf die Benutzer 

darstellen, eingesetzt. 

In den kombinierten Dimensionen der Benutzer-Prozeß-Repräsentation werden Metaphern der Bewegung wirksam.


In der kombinierten Dimension der Daten-Benutzer-Welt wird der Informationsgehalt, der Wert der Information 

und die Benutzbarkeit der Information dargestellt. 

In der kombinierten Dimension der Daten-Datenrepräsentation spielt die Bereitstellung der Daten als Content 

eine Rolle. 

In der kombinierten Dimension der Prozesse-Prozeßrepräsentation wird aus der erforderlichen Funktionalität 

abgeleitet, welche gestalterischen Mittel erforderlich werden. 

In der kombinierten Dimension der Prozeßrepräsentation-Umgebung wird das Playout abgeleitet. Es orientiert 

sich an 

• dem Anliegen der Darstellung und setzt Anforderungen der Darstellung der Prozesse um, 

• der Story selbst und 

• den technischen Möglichkeiten, die durch die Umgebung gegeben sind. 

In der kombinierten Dimension der Datenrepräsentation-Umgebung wird aus den zur Verfügung stehenden Informationen 

das Layout abgeleitet. Es orientiert sich an 

• der Art des Content, 

• dem Inhalt des Content und 

• dem Anliegen der Benutzung 

• sowie den technischen Möglichkeiten der Umgebung. 

In der kombinierten Dimension der Benutzer-Prozesse wird die Story benutzt, um die Layout- und die Playout- 

Gestaltung abzuleiten. 

Parallel zu den Dimensionen kann der Grad der Ausprägung bestimmt werden, mit dem Kategorien wie 

• kraftvolle Gestaltung, 

• angereicherte (wertebasierte) Gestaltung, 

• erweiterte Gestaltung um Aspekte von 

• Verspieltheit (Romantik, Leidenschaft), 

• Kreativität mit einer Neuheit und überraschenden Effekten, 

• erfrischende Gestaltung mit Momenten einer Leichtigkeit und Transparenz, 

• Beruhigung durch Momente der Harmonie und der Ausgegleichenheit und 

• Anregung durch exotische und magische Elemente, 

• natürliche Gestaltung mit einem Bezug auf das Umfeld des Benutzers und 

• dynamische Gestaltung mit einer internen Bewegung und Spannung 

benutzt werden, um eine Verstärkung oder Abschwächung zu erreichen. 

Der Gestaltungsrahmen orientiert sich deshalb zentral auf 

das Layout der Daten unter Berücksichtigung der technischen Möglichkeiten, 

das Playout der Prozesse unter Berücksichtigung der technischen Umgebung des Benutzers, 

Metaphern zur Informationsdarstellung und 

Metaphern zur Story-Darstellung und Funktionsunterstützung


und mittelbar auf 

die Repräsentation der Daten und 

die Repräsentation der Prozesse wie z.B. die Orientierung im Nutzungsraum auf der Grundlage von 

Feedback, 

mentalen Modellen, 

Metaphern zur Orientierung und 

Gestaltungsrastern 

und der Nutzungsdramaturgie der Interaktivität 

durch Verfeinerung der Repräsentationen, d.h. durch Unterlegung der Repräsentation mit gestalterischen Mitteln. 

Layout und Playout können zum Nutzungsraum zusammengefaßt werden. 

Die Spezifikation des Gestaltungsrahmens wird somit durch folgende Spezifikation unterstützt: 

• Beschreibung der Benutzer, der Akteure, der Benutzergruppen, 

• Spezifikation der Story, 

• Spezifikation der Prozesse, 

• Spezifikation des Content, 

• Spezifikation der Repräsentation der Daten, 

• Spezifikation der Repräsentation der Prozesse und 

• Angaben zur technischen Umgebung des Benutzers. 

Der Gestaltungsrahmen legt die Gestaltungsgrundlagen fest. Dabei werden 

• Prinzipien der visuellen Kollaboration, 

• Prinzipien der visuellen Wahrnehmung und 

• Prinzipien der visuellen Gestaltung 

für die konkrete Aufgabe verfeinert. 

Dazu werden Gestaltungslemente und Gestaltungsmittel eingesetzt. 

6.7.2 Die Umsetzung des Gestaltungsrahmens 

Wir erhalten eine Charakterisierung des Gestaltungsrahmens in tabellarischer Form: 

Aufgabe 

Playout Layout Metapher Akteure Qualität 

Dar- 

Kol- 

Funktionenehmunischirgruppritätion 

Wahr- 

Kom- 

Bild- 

Ziel- 

Pola- 

Adapstellunratiomunlabokation 

Funktion 

der 


der 


... ... ... ... ... ... ... ... ... ... ... ... ... ... 

In dieser Tabelle führen wir die Information zum Akteur zur direkten Assoziation mit. Sie dient eher der direkten 

Bezugnahme und bestimmt nicht den Gestaltungsrahmen. Die Qualitätsparameter dienen der Kontrolle.


Dieser Gestaltungsrahmen kann dann den Arbeitsoberflächen im speziellen oder dem Präsentationsraum im allgemeinen 

zugeordnet werden. 

Wie bereits betont, kann dieser Gestaltungsrahmen verwendet werden, um Metaphern zu gewinnen. Die Spezifikation 

von Metaphern kann mit folgenden Metaphorikrahmen erfolgen: 

Name der Metapher; 

Die Darstellung der Eigenschaften assoziiert Eigenschaften der Metapher mit dem Anwendungsgebiet. Die Intensität 

und die Dominanz der Eigenschaften kann mit erfaßt werden. 

Klasse der Metapher (personalisierte, allegorische, symbolische). 

Bedeutung für unterschiedliche Benutzergruppen in unterschiedlichen kulturellen Kontexten. 

Repräsentation der Metapher durch entsprechende Formen und Farben, Kontrast und Rhythmus, Struktur und 

Komposition. 

Die Zuordnung von Metaphern zum Gestaltungsrahmen und zu den Content-Suiten sowie zur Funktionalität erfolgt 

explizit 

durch Angabe der Suiten (Content-Suiten, Funktionen, Container, Akteure), 

durch Angabe der Metapher-Einbettung mit den Parametern für 

die Funktion der Metapher in der Suite, 

die Anwendbarkeit der Metapher im Gestaltungsrahmen z.B. als Vollseiten-, Teilseiten-, Beiwerk-Metapher, 

das Ursprungsgebiet der Metapher, 

die Abstraktionsrichtung 

(Generalisierung/Spezialisierung), 

die Richtung (vom Lebewesen zum Gegenstand, vom Gegenstand zum Lebewesen), 

dem beabsichtigten Effekt (prädikativ oder überzeugend; attributiv, genitiv, kompositional, Apposition) und 

die Repräsentationsform als Auswahl unter den verschiedenen möglichen Repräsentationsformen der Metapher, 

sowie 

durch Angabe der Intention der Metapher mit Parametern für 

den Kontext (Intention für Akteur, Erwartungen des Akteurs, Co-Notationen (soziale und emotionale)), 

der Funktion (intern, prädikativ, heuristisch, emotional, sozial, rhetorisch, ästhetisch) und 

dem Typus der Metapher (konventionell, kreativ, Ex-Metapher, Re-Metapher). 

Wir können wiederum anstelle einer Tabelle Arbeitsblätter zur Darstellung der Metaphern verwenden. 

Der Gestaltungsrahmen wird außerdem durch eine Spezifikation der 

Betonung, 

Dominanz, 

Transparenz und der 

Kontrastierung 

ergänzt. Mit dieser Darstellung können wir auch die Akzeptanz, die Wahrnehmung, die Aufnahme des Inhaltes, seine 

Verarbeitung und die Stimmung beeinflussen. 

Diese Spezifikation kann auch als Interface-Polaritätenprofil mit einer ordinalen Bewertungsskala zur Darstellung 

der Ausgeprägtheit der Eigenschaften erstellt werden.


6.8 Perspektiven der Mensch-Computer-Interaktion 

Traditionell werden vier verschiedene Perspektiven der Interaktion unterschieden: 

Maschinenperspektive: Der Computer wird bei den Betrachtungen in den Mittelpunkt gestellt. Der Mensch wird als 

Maschinenbediener wahrgenommen. 

Systemperspektive: Mensch und Computer werden als gleichberechtigte Partner eines Systemes aufgefaßt. 

Kommunikationsperspektive: Programme und Benutzer unterhalten sich gleichberechtigt in einer Dialogsprache. 

Werkzeugperspektive: Der Computer unterstützt den Benutzer bei der Erfüllung seiner Aufgaben. 

Auf der Grundlage dieser Perspektiven können wir vier Methoden zur Entwicklung von Oberflächen ableiten: 

Die empirische Methode orientiert sich an den aktuellen Herangehensweisen, verallgemeinert diese und gestattet 

die Entwicklung in einem trial-and-error-Prozeß. 

Die kognitive Methode untersucht zuerst das Verhalten des Menschen, ergründet sein mentales Modell und nutzt 

diese Erkenntnisse zur Entwicklung von benutzungsfreundlichen und intuitiv verständlichen Oberflächen. 

Die prediktive (funktionsorientierte) Methode leitet aus den Zielen der Anwendung, den Aufgaben und den technischen 

Möglichkeiten eine Lösung für die Gestaltung des Arbeitsprozesses und der entsprechenden Oberflächen 

ab. 

Die anthropomorphe Methode bildet die Kommunikation von Mensch und Maschine in Form von Dialogen, Dialogobjekten 

und Oberflächen nach. 

Meist wird eine Kombination dieser Methoden gewählt. Eine bevorzugte Variante ist die Kombination der prediktiven 

und der anthropomorphen Methoden. 

Aus diesen Perspektiven sind zwei grundsätzliche Zugänge zur Gestaltung von Oberflächen ableitbar: 

Der konstruktive Ingenieurzugang orientiert sich an den Entwicklern und den vorhandenen technischen Möglichkeiten 

und damit an der Maschinenperspektive. Systeme dieser Bauart können einfach und elegant, einfacher 

auch durch den Benutzer zu pflegen und für den eingearbeiteten Benutzer auch durchschaubar sein. 

Der Benutzer-Aufgaben-Zugang beruht auf eine Kombination der Werkzeug-, Kommunikations- und der Systemperspektive. 

Ausgehend von einem Aufgabenmodell und einem Interaktionsmodell wird der Computer zum 

Partner bei der Lösung einer Arbeitsaufgabe. Die einzelnen Arbeitsschritte werden in Oberflächen nachgebildet. 

Der Vorteil dieses Zugangs ist die leichte Erlernbarkeit. Von Nachteil ist die Fixierung auf den aktuellen 

Zustand des Arbeitsprozesses, der u.U. auch von bislang benutzten, nicht adäquaten Werkzeugen und deren 

Funktionalität geprägt ist. 

Web IS


6.9 Stories auf der Benutzungsschicht 

6.9.1 Szene als Grundkonstrukt 

6.9.2 Pragmatics of Storyboarding 

• Usage analysis: 

• Life Cases: How the stories match the users’ intentions and expectations 

• User Models: Which user/actor profiles and portfolios have to be considered 

• Contexts: Everything that surrounds and thus impacts on a utilisation situation 

• WIS portfolio: 

• content and utilisation chunks 

• Starting point: Analysis of intentions 

• Intentions are coarsely formulated as part of a strategic WIS model (mission, purpose, goals) 

• Utilisation scenarios are developed on the basis of intentions 

• Therefore, address the description of intentions: 

• Clear understanding of aims and targets of the WIS 

• This includes long-range and short-term targets, expected visitors, characteristics of this audience, 

tasks performed by the users, necessary and nice-to-have content, restrictions of usage, etc. 

Capturing Intention through Life Cases. 

• Analysis of intentions structures the WIS: actors and tasks become apparent 

• Life cases shed more light into the tasks and the way they are to be executed 

• Life cases give rise to the development of task scenarios 

• Life cases focus on observations in real life situations, thus takes a user-centered approach that goes beyond 

task analysis 

• This will help identifying and resolving conflicting or competing intentions, before abstracting and mapping 

life cases to scenarios 

Characterisation of Life Cases. 

• Observations: 

• collect and assess behaviour relating to the specific application 

• include a background check that relates usage to intentions, goals or tasks 

• Processes: 

• arrange all the actions observed in an application into a main logical and coherent pattern 

• this may involve exceptions through exceptions and parallel execution of independent actions 

• Assessment: 

• reconstruct the sequence of actions and specific behaviour of users 

Web IS


• understand the role each individual has within the story 

• develop the user profile 

• Individual profiles: 

• clarify background including physical, and behavioural characteristics of individuals 

• Interpersonal coherence: 

• a variation in the activity will relate to variations of other life cases 

• Significance of time and place: 

• choices depend on mobility, surrounding, and schedules of events of interest 

• Experience and skills: 

• individuals may show different behavioural patterns of service employment 

Capturing Intention through Life Cases. 

Modelling of normal succeeding behaviour 

Search by analogy 

❥ 

Disselection 

on options 

❑ 

No 

further 

options 

❥Knowledge about 

problems 

❯ 

Survey 

on choices 

❑ 

❨ 

❥ 

Sample 

cases 

2❨ 

❑ 

❥ 

Similar 

cases 

3 

Background 

knowledge 

✿ 

❯ 3 ✾ 

Succesfull 

Approaches 

cases 

Abbildung 27: One of the scenes for active learning in the DaMiT system 

Mapping users behaviour with all possible options 

Intelligent support by knowledge structures 

Adaptation to users profile and portfolio 

Logistics for content 

Integration of the Description of the Application Domain. 

Life and application cases 

Mapping Life Cases to Business Use Cases. 


• is characterised by the life case that characterises typical application situations for groups of users (actors) 

within a context, 

• can be used to derive business use cases depending on the task portfolio and on the story under consideration, 


• is described through narrative descriptions based on word fields. 

Web IS


from 

proof of moving out 

address 

to 

proof of moving in 

citzen office 

town clerk`s office 

issuer 

passport 

factory inspectorate 

public authorities 

civil servant 

contracters 

documentation agency 

agencies 

basic changes 

associated documents 

income tax card 

special names 

pseudonyms 

fratemity 

TV/radio 

ministery 

tax office 

statistics agenca 

police 

aliens department 

automated contracting 

directory companies 

data protection official 

official bodies 

companies 

special support 

recipients 

actors 

necessary documents 

passport 


certificaters 

proofs 

birth certificate 

degrees 

certificate of authority 

special documents 

for authorizing others 

pension approval certificate 

employment documents 

schools 

religious organizations 

parties 

support of organization 

relocation 

citizenship 

marriage certificate 

driving licence 

child identification card 

tax 

partners 

potential changes 

address 

housing benefit 

house owner benefit 

housing allowance 

housing programme 

social support 

children 

potential changes 

address 

school 

housing eligibility 

associated parties 

pets 

pet tax 

pets registration 

insurance agencies 

health insurance 

tv/radio 

house number 

special parking permission 

move life case 

forwarding period 

forwarding mail 

forwarding address 

insurance 

bank 

contracting 

collect charges 

house registration application for registration 

associated life cases 

ownership 

car 

housing 

supply 

employment 

vehicle documents 

parking card 

special 

special contracts 

energy,gas 

water,sewage 

phone 

employer 

employment office 

documents from handicaped 

private people 

parties, organisation 

registration 

directory 

accepted restrictions 

overruled restrictions 

obligation of secrecy 

disclosure 

provided reasons 

restrictions 

special/exceptional 

foreign resident 

foreign temporary 

second home additional taxation rent level 

Life cases 

Actor ✲ ✛ Environment 

✙ 

❥ 

Persona 

Platform 

✾ 

❄ 

3 

Stories ✛ ✲ Business ✛ ✲ 

use cases 

Portfolio 

Bundling in 

❄ 

Narrations 

Actions 

Content 

❄✾ 

Substantive 

word fields 

Content 

Tasks 

3❄ 

Verb 

word fields 

Abbildung 28: The natural language representation of application domain elements 

Web IS


Stories Business use cases Portfolio 

Requirements 

prescription 

✾❄ 

Storyboard 

3❄✾ 

3❄ 

Non-functional 

requirements 

Functional 

requirements 

Abbildung 29: The use of application domain information for requirements elicitation and analysis 

Mapping the Business Use Cases to Requirements. 

The application domain description can be used to deduct 

the requirements prescription 

• through functional requirement, 

• through non-functional requirements, and additionally 

• through the storyboard of the application. 

Web IS


6.10 Szenenraum als konzeptionelle Wiederspegelung 

6.10.1 Dialogschritt als Grundkonstrukt 

6.10.2 Screenography 

intention 

context 

The description of the kind 

or the specification 

of the general 

grid or pattern 

storyboard 

content 

functionality 

Abbildung 30: The screenography pentagon for associations to other WIS dimensions 

Web IS


6.11 Präsentationsraum auf der Implementationssschicht 

Arbeitsoberfläche als Grundkonstrukt. 

Interaktionsraum mit SiteLang 

Benutzer- und Akteursmodelle, -portfolio und -profile 

Kontextraum, Kollaborationsrahmen 

Gestaltungsrahmen, Gestaltungsmuster 

6.12 Richtlinien für gute SiteLang-Spezifikationen 

• The structure of the sentences and to describe use cases in a textual form should be simple. 

• Always make clear which actors are involved in an action. 

• Only include conditions (with alternative branches) if it really necessary. 

• For exceptional cases, always make clear the condition under which the exceptional case occur. 

• All use cases should be written in such a way that the user can understand them. 

• Use strong verbs in use case names. 

• Try to write scenarios, not requirements. 

• Don’t write too tersely. 

• Don’t write in a passive voice. 

• Avoid synonyms and homonyms. 

• You should mention your assumption explicitly when some action is carried out under certain conditions. 

• You should mention the condition for stopping repeated actions explicitly. 

• You should mention the co-occurrence of several actions explicitly. 

• Avoid the use of negations, adverbs, and modal verbs in the description of an action. 

Richtlinien für Qualitätsmanagement von SiteLang-Spezifikationen. 

Richtlinien für Prozeßmanagement von SiteLang-Spezifikationen. 

Richtlinien für Darstellung von SiteLang-Spezifikationen. 

Web IS


6.13 Darstellung durch UML-Konstrukte 

Use-Case-Diagramme. 

Akteure 

Use Case mit include- und extend-Hierarchien 

Activity-Diagramme. 

als Verallgemeinerung von Ereignis-Diagrammen, SDL, Zustandsmodellierungstechniken und Petri-Netzen 

mit Synchronisationspunkten in AND-AND-Semantik 

mit Knoten zur Darstellung von Aktivitäten 

mit Bedingungen an Überführungskanten 

Statechart-Diagramme in der UML-Interpreation. 

Warum dann SiteLang anstatt von UML. 

Lifelines sind eine andere Sicht auf Durchläufe, parallele Ausführung wird implizit dargestellt 

Beispiel Fujaba: join of adapted UML class diagrams, UML activity diagrams and collaboration diagrams 

• Damit Abbildungsprobleme statt wie bei SiteLang nur Overlay-Formen 

• Stets nur Sichtweise dargestellt, Integration erfolgt implizit über Namen 

• Zu stark an Java orientiert (THIS) 

Web IS


6.14 Ein Beispiel: Zielgruppenorientierte Portalseiten 

c○Thomas Voigt, BTU Cottbus 

1. Zielsetzung. 

Der Online-Auftritt der BTU Cottbus soll um drei zielgruppenorientierte Portalseiten ergänzt werden. Auf diesen Portalseiten sind stets aktuelle 

Informationen abrufbar. Es wird zwischen Meldungen, Terminen und Veranstaltungen nach Art ihrer Darstellung unterschieden. Auf 

nachgeordneten Seiten finden sich ein Veranstaltungskalender und ein durchsuchbares Archiv. Alle Informationen sollen in einer zentralen 

Datenbank bereitgehalten werden. 

2. Produkteinsatz. 

2.1. Anwendungsbereiche. 

Das System soll auf den Webservern der BTU Cottbus (Rechenzentrum) eingesetzt werden. Die Beiträge sollen von verschiedenen Stellen aus 

erstellt, jedoch zentral gehalten werden. 2.2. Zielgruppen. 

Ein erstes Portal soll externe Besucher und Studieninteressenten mit aktuellen Informationen und einer angepaßten Navigation versorgen. Ein 

zweites Portal soll auf die Interessen der Cottbuser Studenten zugeschnitten werden. Ein drittes Portal, speziell für Mitarbeiter der Universität, 

soll nur intern erreichbar sein. Die Betreuung der Beiträge soll hierarchisch organisiert sein. Zugelassene Redakteure schreiben Beiträge, die 

von den zuständigen Rubrikbetreuern freigegeben werden müssen. Die Portalbetreuer entscheiden anschließend, welche der Beiträge bereits 

auf einer Portalseite verlinkt werden. 

3. Anwendungsfälle. 

3.1. Rollen und Akteure. 

WWW-extern. 

WWW-extern umfaßt alle Nutzer, die sich nicht am System angemeldet haben und deren Anfrage nicht aus dem Netz der Universität stammt. 

WWW-extern hat die geringsten Rechte: Er kann nur Beiträge lesen, die für die externe Nutzung freigegeben wurden. WWW-intern. 

Alle Nutzer, deren Anfragen aus dem Adreßbereich der BTU stammen (Mitarbeiter der Universität). WWW-intern muß sich nicht anmelden 

und hat alle Rechte von WWW-extern, darf aber zusätzlich Beiträge einsehen, die nur für die interne Verwertung freigegeben wurden. 

Redakteur. 

Redakteure können selbst Beiträge erstellen und eigene Beiträge bearbeiten. Dazu müssen sie sich am System mit ihrem Namen und einem Paßwort 

anmelden. Ein neuer Beitrag muß vom zugehörigen Rubrikbetreuer bestätigt werden, bevor er öffentlich einsehbar ist. Rubrikbetreuer. 

Rubrikbetreuer haben alle Rechte eines Redakteurs und verwalten jeweils eine oder mehrere Rubriken. Sie entscheiden, ob ein Beitrag eines 

Redakteurs in ihrer Rubrik für die Öffentlichkeit freigegeben wird. Freigegebene Beiträge sind danach sofort auf den Webseiten abrufbar. 

Rubrikbetreuer dürfen zusätzlich zu ihren eigenen alle fremden Beiträge in ihrer Rubrik bearbeiten (kürzen, abändern usw.). In nicht von ihnen 

betreuten Rubriken werden sie wie Redakteure behandelt. Einige (vom Portalbetreuer zugelassene) Rubrikbetreuer dürfen auch selbst neue 

Web IS


Redakteure bestimmen. Portalbetreuer. 

Der Portalbetreuer ist die höchste Instanz des Systems. Er erbt alle Rechte des Rubrikbetreuers, darf neue Rubriken anlegen und die zugehörigen 

Rubrikbetreuer bestimmen. Der Portalbetreuer entscheidet über das Erscheinungsbild der Portal-Seiten (welche der freigegebenen Beiträge 

wann auch auf der ersten Seite erscheinen und welcher Beitrag zum Aufmacher wird). 

3.2. Szenen. 

Anmelden. 

Vor jeglicher aktiver Benutzung des Systems müssen sich privilegierte Anwender mit Namen und Paßwort anmelden. Eine erfolgreiche Anmeldung 

bleibt für einen bestimmten Zeitraum aktiv (Sitzung). 

Beteiligte Akteure: Protalbetreuer, Rubrikbetreuer, Redakteur 

Vorbedingungen: keine 

Nachbedingungen: Dem Benutzer wird eine Rolle mit zugehörigen Privilegien zugewiesen. Eine Sitzung (Session) wird angelegt. Solange die 

Sitzung gültig ist muß der Anwender sich nicht bei jeder Aktion erneut anmelden. Der Anwender wird auf eine seiner Rolle entsprechende 

Seite weitergeleitet. 

Ausnahmefälle: Bei fehlgeschlagender Anmeldung wird dem Nutzer automatisch die Rolle WWWextern bzw. WWW-intern zugeordnet (ohne 

Sitzung). 

Externe Beiträge lesen. 

Beiträge (Meldungen, Termine, Veranstaltungen, Veranstaltungskalender) auf einer der Portalseiten (oder nachgeschaltete) werden von einem 

Anwender gelesen. 

Beteiligte Akteure: alle 


Nachbedingungen: keine 

Ausnahmefälle: Es liegen keine aktuellen Beiträge vor. In diesem Fall gibt das System eine entsprechende Meldung aus. Interne Beiträge 

lesen. 

Anwender aus dem lokalen Netz der BTU (Mitarbeiter) sehen Beiträge ein, die als “intern” eingestuft wurden. 

Beteiligte Akteure: WWW-Intern (Mitarbeiter der BTU) 

Vorbedingungen: Anhand der IP-Adresse wurde der Anwender als lokaler Benutzer eingestuft (z.B. vom Webserver per .htaccess). 

Nachbedingungen: Zusätzlich zu den ” 

externen“ Beiträgen, werden auch die ” 

internen“ aufgelistet. Beitrag freigeben 

Ein vom Redakteur geschriebener (interner oder externer) Beitrag bedarf der Genehmigung durch einen Rubrikbetreuer, bevor er unter dieser 

Rubrik online gehen darf. 

Beteiligte Akteure: Rubrikbetreuer 

Vorbedingungen: Ein Redakteur verfaßt einen Beitrag, weist ihm eine Rubrik zu und legt ihn dem Rubrikbearbeiter vor. 

Nachbedingungen: Der Beitrag bekommt ein aktualisiertes Veröffentlichungsdatum und kann auf den entsprechenden Seiten abgerufen werden. 

Er findet sich dann auch in der Admin-Liste der Beiträge wieder, die für die Veröffentlichung auf den Portalseiten in Frage kommen. 

Web IS


Ausnahmefälle: Der Beitrag erfüllt nicht die erforderlichen Kriterien für eine Veröffentlichung. In diesem Fall wird der Beitrag abgelehnt, 

der Redakteur erhält hierüber eine Nachricht und legt den Beitrag ggf. nach Bearbeitung erneut vor. Der Rubrikbetreuer kann den Inhalt des 

Beitrages aber auch den Erfordernissen anpassen (z.B. ihn einer anderen Rubrik zuweisen). Auch hierüber erhält der Redakteur des Beitrages 

eine Nachricht. 

Hauptseite freigeben. 

Auf den Portalseiten wird auf einige Beiträge in Kurzform verwiesen. Der Platz dafür ist knapp bemessen, es können eventuell nicht alle 

Beiträge auf den ersten Seiten erscheinen. Es muß also eine Auswahl getroffen werden. Alle weiteren Beiträge sind über nachgeordnete Seiten 

erreichbar. Weiterhin wird ein Beitrag mit Bild zum “Aufmacher” bestimmt, der einen größeren Platz auf der Portalseite eingeräumt bekommt. 

Beteiligte Akteure: Portalbetreuer 

Vorbedingungen: Eine Liste der von den Rubrikbetreuern freigegebenen Beiträge liegt vor. Nachbedingungen: Die ausgewählten Beiträge 

erscheinen auf den Portalseiten. 

Ausnahmefälle: Trifft der Portalbetreuer keine Auswahl bzw. bleiben Plätze unbelegt, werden Beiträge vom System ausgewählt (z.B. nach 

Veröffentlichungsdatum). Findet sich für einen infrage kommenden Aufmacher kein passendes Bild, kann der Portalbetreuer den Verfasser 

benachrichtigen oder den Beitrag selbst anpassen. 

Termin schreiben. 

Ein Termin ist ein Beitrag, der an eine bestimmte Zeit gebunden ist (z.B. Beginn der Rückmeldefrist für Studenten). Termine werden an 

bestimmten, dafür vorgesehenen Stellen präsentiert (daher die Notwendigkeit der Unterscheidung). Der Anwendungsfall umfaßt das Verfassen, 

Bearbeiten und Entfernen eines Termins. 

Beteiligte Akteure: Redakteur 

Vorbedingungen: Die benötigten Pflichtdaten sind eingegeben worden. 

Nachbedingungen: Der neu erstellte/bearbeitete Termin liegt dem zuständigen Rubrikbetreuer zur Freigabe vor. 

Ausnahmefälle: Wurde ein bestehender Termin bearbeitet/gelöscht, der bereits eine Freigabe erhalten hatte, werden die Änderungen erst nach 

erneuter Bestätigung durch den Rubrikbetreuer aktiv. Meldung schreiben. 

Eine Meldung ist ein Beitrag, der an einen bestimmten Zeitraum gebunden ist (z.B. Pressemeldungen). Meldungen werden an bestimmten, 

dafür vorgesehenen Stellen präsentiert (daher die Notwendigkeit der Unterscheidung). Der Anwendungsfall umfaßt das Verfassen, Bearbeiten 

und Entfernen einer Meldung. Meldungen können zum Aufmacher der Portalseite werden, wenn sie ein Bild enthalten. 


Vorbedingungen: Die benötigten Pflichtdaten sind eingegeben worden. 

Nachbedingungen: Die neu erstellte/bearbeitete Meldung liegt dem zuständigen Rubrikbetreuer zur Freigabe vor. 

Ausnahmefälle: Wurde eine bestehende Meldung bearbeitet/gelöscht, der bereits eine Freigabe erhalten hatte, werden die Änderungen erst 

nach erneuter Bestätigung durch den Rubrikbetreuer aktiv. 

Veranstaltung schreiben. 

Web IS


Web IS


Eine Veranstaltung ist ein Beitrag, der an eine bestimmte Zeit und einen Veranstaltungsort gebunden ist (z.B. ” 

BTU tanzt“). Veranstaltungen 

werden an bestimmten, dafür vorgesehenen Stellen präsentiert und in den Veranstaltungskalender aufgenommen (daher die Notwendigkeit der 

Unterscheidung). Veranstaltungen können zum Aufmacher einer Portalseite werden, wenn sie ein bild enthalten. Der Anwendungsfall umfaßt 

das Verfassen, Bearbeiten und Entfernen einer Veranstaltung. 


Vorbedingungen: Die benötigten Pflichtdaten (insbesondere Veranstalter und Veranstaltungsort) sind eingegeben worden. 

Nachbedingungen: Die neu erstellte/bearbeitete Veranstaltung liegt dem zuständigen Rubrikbetreuer zur Freigabe vor. 

Ausnahmefälle: Wurde eine bestehende Veranstaltung bearbeitet/gelöscht, die bereits eine Freigabe erhalten hatte, werden die Änderungen erst 

nach erneuter Bestätigung durch den Rubrikbetreuer aktiv. 

Inhalt zufügen. 

Umfaßt die Eingabe aller Pflichtdaten sowie weiterer Angaben eines Beitrages. 


Vorbedingungen: Der Redakteur hat sich am System angemeldet und einen neuen Beitrag begonnen oder einen bestehenden Beitrag zur 

Bearbeitung ausgewählt. 

Nachbedingungen: Der Beitrag enthält alle notwendigen Angaben und kann dem Rubrikbetreuer vorgelegt werden. 

Ausnahmefälle: Sind die Pflichtangaben nicht vollständig, wird der Redakteur zur Korrektur aufgefordert. 

Zeitraum wählen. 

Die drei Beitragstypen unterscheiden sich unter anderem in der Zeitdauer ihrer Aktualität. Der Redakteur legt einen oder mehrere Tage fest, an 

denen der Beitrag (nach erfolgter Freigabe) online stehen soll; eine weitreichende Vorplanung ist mittels Kalenderfunktion möglich. An diesen 

Tagen findet sich der Beitrag auch in der Liste des Portalbetreuers. Nach Ablauf des letzten Tages wird der Beitrag archiviert. 


Vorbedingungen: Redakteur hat sich am System angemeldet und einen neuen Beitrag begonnen oder einen bestehenden Beitrag zur Bearbeitung 

ausgewählt. 

Nachbedingungen: Der Beitrag wird mit einer Menge von Tagen verknüpft, an denen er online stehen soll. 

Rubrik wählen. 

Jeder Beitrag ist einer oder mehreren Rubriken zuzuordnen. Je nach gewählter Rubrik liegt er dem (oder den) Rubrikbetreuer(n) zur Freigabe 

vor. 



ausgewählt. 

Nachbedingungen: Dem Beitrag ist mindestens eine Rubrik zugeordnet. 

Ort wählen. 

Veranstaltungen finden oft an den gleichen Orten statt. Zudem gehört zu jedem Ort ein Informationssatz (Anschrift, Betreiber usw.), später 

soll eine Kopplung mit anderen lokalen Informationssystemen (elektr. Lageplan) möglich sein. Um das Eintragen von Veranstaltungen zu 

erleichtern, hält das System eine (von jedem Redakteur erweiterbare) Menge von Orten vor, aus denen komfortabel, schnell und fehlerarm ein 

spezieller Veranstaltungsort gewählt werden kann. 


Vorbedingungen: Redakteur hat sich am System angemeldet und schreibt eine neue Veranstaltung oder bearbeitet eine bestehende Veranstaltung. 

Nachbedingungen: Die Veranstaltung ist mit einem Ort verknüpft und kann zur Freigabe weitergeleitet werden. 

Ausnahmefälle: Der Veranstaltungsort ist noch nicht in der Datenbank aufgeführt. Der Redakteur fügt die Daten des Ortes der Datenbank zu 

(Anwendungsfall Orte verwalten) und wiederholt den Vorgang. 

Bild zufügen. 

Der Aufmacher (Meldung oder Veranstaltung) einer Portalseite sollte ein Bild enthalten. Dazu wählt der Redakteur beim Erstellen des Beitrages 

ein Bild (in einem unterstützten Grafikformat) und eine Bildunterschrift aus. Auf dem Server wird das Bild in ein webgerechtes Format 

gebracht (z.B. mit GD verkleinert und in JPEG oder PNG konvertiert). 



ausgewählt. Ein gescanntes Foto bzw. eine Grafik für den Beitrag stehen zur Verfügung. 

Nachbedingungen: Der Beitrag enthält ein Bild in einem definierten Format. Ein Beitrag mit Bild kommt als Aufmacher einer Portalseite in 

Frage (und wird dem Portaladministrator an entsprechender Stelle zur Auswahl gestellt). 

Ausnahmefälle: Das Dateiformat des Bildes ist nicht unterstützt (z.B. vom GD-Paket). 

Rubriken verwalten. 

Alle Beiträge gehören einer oder mehrerer Rubriken an. Die Rubrik soll die Suche im Archiv erleichtern und bestimmt, an welcher Stelle der 

Beitrag später online zu finden ist. Nur der Portalbetreuer als höchste Instanz des Systems darf Rubriken zufügen, verändern oder entfernen. 



Nachbedingungen: Der neuen Rubrik können Betreuer zugeordnet werden (eine abgeänderte Rubrik behält ihre bisherigen Betreuer bei). 

Ausnahmefälle: Eine Rubrik mit diesem Namen besteht bereits, der Portalbetreuer wird aufgefordert, eine andere Bezeichnung zu wählen. 

Web IS


Rubrikbetreuer zuordnen. 

Bevor in eine neue Rubrik Beiträge gestellt werden können, muß ein Rubrikbetreuer bestimmt werden, der die eingegangenen Beiträge bewertet 

und freigibt. Der Portalbetreuer wählt dazu einen oder mehrere Redakteure aus. Diese Auswahl kann jederzeit geändert werden. Der 

Portaladministrator legt damit auch fest, daß der Rubrikbetreuer seinerseits neue Redakteure bestimmen darf. 


Vorbedingungen: Es sind Redakteure vorhanden, die die Rubrikbetreuung übernehmen können. Nachbedingungen: Ein Redakteur wurde zum 

Rubrikbetreuer “befördert” (oder die Rechte eines bestehenden Rubrikbetreuers werden auf eine weitere Rubrik ausgeweitet). Hat eine Rubrik 

mindestens einen Betreuer, so steht die Rubrik für neue Beiträge zur Verfügung. 

Ausnahmefälle: Wird der letzte Betreuer einer Rubrik entfernt, können ab sofort keine Beiträge mehr in diese Rubrik eingestellt werden. 

Redakteure verwalten. 

Die Rubrikbetreuer haben das Recht, selbst Redakteure zu bestimmen; dadurch soll der Portaladministrator entlastet werden. Diese Rubrikbetreuer 

haben auch die Möglichkeit, einen bestehenden Redakteur zu sperren, so daß ihm in Zukunft der Login verwehrt bleibt. 


Vorbedingungen: Der Portalbetreuer darf neue Redakteure anlegen. 

Nachbedingungen: Ein weiterer Redakteur kann sich anmelden (bzw. kann dies nicht mehr tun, wenn er gesperrt wurde). 

Orte verwalten. 

Die Redakteure pflegen eine Liste von Veranstaltungsorten. Zu jedem Ort werden Angaben (Betreiber, Kontaktadresse, Lagebeschreibung usw.) 

gespeichert, die anschließend für Veranstaltungs-Beiträge genutzt werden können. Jeder Redakteur darf das Verzeichnis der Veranstaltungsorte 

bearbeiten oder neue Orte zufügen (das System vermerkt den anlegenden Redakteur und die letzte Änderung). 


Vorbedingungen: Alle Pflichtangaben zum Veranstaltungsort sind vorhanden. 

Nachbedingungen: Ein neuer/geänderter Datensatz steht allen Redakteuren für Veranstaltungen zur Verfügung. 

Ausnahmefälle: Doppelte Einträge werden nicht angenommen. 

Veranstalter verwalten. 

Die Redakteure pflegen eine Liste von Veranstaltern (Personen, Institutionen, Vereine, die eine Veranstaltung durchführen). Zu jedem Veranstalter 

werden Angaben (Name, Kontaktadresse usw.) gespeichert, die anschließend für Veranstaltungs-Beiträge und den Veranstaltungskalender 

genutzt werden können. Jeder Redakteur darf das Verzeichnis der Veranstalter bearbeiten oder neue Veranstalter zufügen (das System 

vermerkt den anlegenden Redakteur und die letzte Änderung). 


Vorbedingungen: Alle Pflichtangaben zum Veranstalter sind vorhanden. 

Nachbedingungen: Ein neuer/geänderter Datensatz steht allen Redakteuren für Veranstaltungen zur Verfügung. 

Ausnahmefälle: Doppelte Einträge werden nicht angenommen. 

Web IS


Übung: 

Mensch-Maschine-Interaktion 

EER-Modelle Interaktion Akteuere Objekte I-Sicht O-Sicht Enabled processes 

Web IS


Literatur 

[Alt96] 

[KT95] 

M. Altus. A modular design strategy for a flexible graphical database design environment: An experimental 

study. LNCS 1157, pages 146–162, Cottbus, Germany, Oct. 7 - 10, 1996, 1996. Springer, Berlin. 

E. Küthe and M. Thun. Marketing mit Bildern: Management mit Trend-Tableaus, Mood-Charts, Storyboards, 

Fotomontagen und Collagen. DuMont, Köln, 1995. 

[LFe93] C. Löckenhoff, D. Fensel, and R. Studer (eds.). CommonKADS, Proc. 3rd KADS meeting. München, 1993. 

[Sch96] B. Schewe. Kooperative Softwareentwicklung - Ein objektorientierter Ansatz. Deutscher Universitäts- 

Verlag, Wiesbaden, 1996. 

Web IS






D - 24098 Kiel 

 





7. Grundlagen WS 2011/12 


Forschung 



7 Grundlagen 

Was du ererbt von deinen Vätern hast, 

Erwirb es, um es zu besitzen. 

Was man nicht nützt, ist eine schwere Last; 

Nur was der Augenblick erschafft, das kann man nützen. 

Goethe, Faust, Erster Teil, Nacht, Faust 

7.1 Normalisierung 

7.1.1 Gründe zur Normalisierung 

Probleme der Modellierung. 

Die Datenbankspezifikation ist gezeichnet von 

Modellierungsbeschränkungen durch die 

gewählte Spezifikationssprache, in der ggf. die Anwendung nur mit komplexen Spezifikationen und verwickelten 

Schemata unterstützt wird, 

gewählte Spezifikationsmethodik, die ggf. zu falschen Spezifikationsurteilen führt, den Kontext der Modellierung 

und die gewählte Referenzmodellierung 

unterlegte Spezifikationstheorie mit Modalität, Gewißheit und Schärfe der Modellierungsurteile, sowie die 

Urteilsart und 

Wahl des Ausschnittes der Realität, der modelliert wird 

Implementationsbeschränkungen z.B. aufgrund der Verarbeitung im DBMS. Typische Beschränkungen sind: 

Beschränkungen des SQL-Dialektes

CAU zu Kiel, IfI, ISE, β 7. Grundlagen WS 2011/12 692 

Beschränkungen der Integritätspflege z.B. durch Zulassung von wenigen Integritätsbedingungen wie 

Wertebereichsbeschränkungen 

Schlüsselbeschränkungen und 

referentielle Integritätsbedingungen 

Beschränkungen des DBMS insbesondere Speicherverwaltung und Transaktionsverarbeitung 

Verhalten von semantisch sinnvollen Einheiten, das (nicht) berücksichtigt wird und durch Dekomposition ggf. erschwert 

wird. 

Optimierungserfordernisse. 

Probleme bei der Optimierung von Datenbankanwendungen sind: 

(A) Redundanzprobleme durch schwierige oder ggf. auch Nichtunterstützung kontrollierter Redundanz 

(B) Informationsblockierung aufgrund der Informationskapazität des Schemas 

Insert-Anomalie durch rigide Erzwingung von einfügebeschränkenden Integritätsbedingungen 

(C) Informationsverluste von DB-Modifikation z.B. 

Delete-Anomalie: Es werden Teil-Informationen in Objekten, die eine eigenständige Bedeutung haben vernichtet 

(D) Evolutionsempfindlichkeit und Instabilität bei Veränderungen (Evolutionsresistenz bzw. Evolutionsrobustheit 

erfordert eine vollständig andere Architektur von Schemata. Dazu existiert bis auf die TIS@CAU-Ansätze kein 

Lösungsvorschlag.) 

(E) Unterschiedliche Abstraktionen in partieller Koexistenz z.B. auch Sichten 

(F)Performanzprobleme durch Spezifika der Anwendung, durch falsche Strukturierung (ggf. auch bei Wahl der 

falschen Normalisierung), komplexe oder verwobene Datenstrukturen. 

Verhaltensveränderungen von Operationen, insbesondere Komplexität von Operationen durch Umgebungseinbeziehung, 

z.B. 

Update-Anomalie, bei der eine Einobjektoperation zu einer Bulkoperation wird, z.B. ein table scan erfordert, 

damit die Architektur von DBMS schon aufgrund der beschränkt vorhandenen Ressourcen 

im Puffer- und Cache-Bereich grausam überfordert 

Anfragefehlverhalten aufgrund von der Berechnungskomplexität priorisierter Anfragen 

Wird aufgehoben durch Zusammenführung von Strukturen (Denormalisierung): 

Vorteile der Denormalisierung: 

Erhöhung der Berechnungsgeschwindigkeit im Retrieval 

Blockierung der Separation semantisch sinnvoller Einheiten und damit Vermeidung von zusätzlichen 

Verbunden und Reduktion von Fremdschlüsseln 

Vorausberechnung und Mitführung abhängiger Daten mit redundanten Attributen und abgeleitete Daten 

Reduktion von notwendigen Indizes 

Reduktion der Anzahl von Tabellen 

Einführung von Surrogatattributen zur Vereinfachung der Identifikation und von Fremdschlüsseln 

Nachteile der Denormalisierung 

Update slow down und DBMS-internes slow down


hohe Abhängikeit von der Anwendung und Inflexibilität bei Evolution 

hohe Redundanz ohne einfache Pflegemechanismen 

(G) Schwierige Pflege und Modifizierbarkeit von Daten 

Ansatz zur Messung der Qualität von Schemata. 

Gegeben sei eine Menge M aller möglichen Typen einer Anwendung. Diese Menge kann von einer minimalen Menge 

erzeugt werden. Es können nun Teilmengen von M betrachtet werden. 

Vollständige Teilmengen erlauben die Ableitung aller anderen Typen in M. 

Korrekte Teilmengen besitzen keine Typen, die mit anderen Typen im Widerspruch stehen. 

Unter den vollständigen und korrekten Teilmengen F ULL(P(M)) können wir die optimalen Schemata OP T IMAL(P(M)) 

herausschälen. Es kann nun das gefundene Schema S dagegen bewertet werden. Dazu werden die minimalen Abstände 

gemessen: 

NumbOfConcept(S) − NumbOfErr(S, S ′ ) 

correctness OP T (S) = max S ′ ∈OP T IMAL(P(M)) 

Concept(S ′ ) 

NumbOfConcept(S) − NumbOfDifferences(S, S ′ ) 

completeness OP T (S) = max S ′ ∈OP T IMAL(P(M)) 

Concept(S ′ ) 

Diese beiden Maße können kombiniert werden zu: 

mit 

SQ = (β2 + 1.0) × completeness OP T (S) × correctness OP T (S) 

β 2 × completeness OP T (S) + correctness OP T (S) 

β = 1: Korrektheit und Vollständigkeit gleichwertig 

β = 0: nur Korrektheit bewertet 

β = ∞: nur Vollständigkeit bewertet 

Diese Maße stehen in Korrelation zu Maßen aus dem Information Retrieval 

Präzision zum Messen der Korrektheit (F: gefunden; R: relevant) 

|F(q, D 1 )) ∩ R Q S 1 ,S 2 

(q, D 1 )| 

|F(q, D 1 ))| 

Recall zum Messen der Vollständigkeit 

|F(q, D 1 )) ∩ R Q S 1 ,S 2 

(q, D 1 )| 

|R Q S 1 ,S 2 

(q, D 1 )| 

Fallout zum Messen der Inkorrekheit einer Funktion 

|F(q, D 1 )) \ R Q S 1 ,S 2 

(q, D 1 )| 

|ALL \ R Q S 1 ,S 2 

(q, D 1 )|


7.1.2 Allgemeines Herangehen 

Zerlegung der Datenbankanwendung in Komponenten. 

Dieser Ansatz stellt eine Eigenentwicklung der TIS@CAU-Gruppe dar, basiert auf dem Herausschälen von Komponenten 

und einer Entwicklung einer Kollaborationsarchitektur zwischen den Komponenten. 

Herausfinden von verbotenen Teilstrukturen. 

2. Normalform Teilschlüssel implizieren nicht Nicht-Schlüsselattribute 

3. Normalform jedes Nicht-Schlüssel-Attribut darf nur direkt von einem Schlüssel abhängen (kein transitiver Schluß) 

Boyce-Codd-Normalform jede nicht-triviale funktionale Abhängigkeit ist eine Schlüsselabhängigkeit 

4. Normalform jede geltende mehrwertige Abhängigkeit ist ableitbar aus den geltenden Schlüsselabhängigkeiten 

5. Normalform jede geltende Verbundabhängigkeit ist ableitbar aus den geltenden Schlüsselabhängigkeiten 

Einfüge-, Lösch- und Update-Anomalien treten genau dann nicht auf, wenn nur funktionale Abhängigkeiten gelten 

und Schema in BCNF ist 

Separation von verschiedenen Gesichtspunkten. 

Schema Datenbank Anfragen Anfrageergebnisse 

zeitunabhängige Beschreibung 

zeitabhängige Beschreibung 

Entwurf durch Modularisierung und Separation von Aspekten 

Redundanzarmut und günstiges Verhalten (z.B. keine Anomalien (insert, delete, update erfordern Nacharbeit)) durch 

Verbot von Teilstrukturen und Trennung von Gesichtspunkten 

R = (R 1 , ..., R m , Σ 0 ) , R i = (U i , Σ i ), Σ = ⋃ m 

i=1 Σ i ∪ Σ 0 verbotene Teilstrukturen 

durch Normalisierung 

als adäquate Dekomposition T und Wiederherstellungsoperation f 

T (R i , Σ i ) = (R i,1 , ..., R i,k , Σ T i ) 

R j i = (U i,j, Σ i,j ) 

2 Eigenschaften 

• verlustfrei: gleiche Daten repräsentiert 

R t i = f(T (Rt i )) 

weder Datenverlust noch Datenerzeugung 

• Erhalt der Integritätsbedingungen: Σ i |= ⋃ k 

j=1 Σ i,j ∪ Σ T i 

• Unabhängige Pflege der Teilstrukturen 

⋃ k 

j=1 Σ i,j ∪ Σ T i 

|= Σ i 

Damit erhalten wir 4 Teilaufgaben: 

1. Semantische Eigenschaften = syntaktische Eigenschaften 

2. Beweis der obigen = 

3. Algorithmen zur Gewinnung


4. geringe Kosten 

Formalisierung von Heuristiken 

Separation Einheitliches Verhalten Ableit. von Gesichtspunkten 

Aufgabe 1 : Aufgabe 1: 

( keine verbotenen Teilstrukturen) (semantische Forderungen) 

- 3NF - Verbundpfade eindeut. - sichere Sichteninstanzunterstütz. 

- BCNF -sichere Sichtenanfrageunterst. 

- 4NF 

- 5NF (syntaktische Forderungen) - für FD’s : join support 

- referent. NF - γ-azyklisch (X 1 , ..., X n ) ∈ Σ + 

- unique-key NF - α-azyklisch ∪F i ) + ⊇ F 

Beziehungen 

- BCNF & Verbundunterstützung sind compatibel (Dekomp.) 

- 3NF und sichere Verbundunterstützung sind compatibel (Synthese) 

γ-azyklisch gdw. Verbundpfade sind wesentlich eindeutig 

Optimierung zur Entwurfszeit 

Aufgabe 4: Syntaktische Eigenschaften garantieren geringe Kosten 

Speicherung Anfragen update 

-Normalformen γ-Azykliz. ohne Referenzen 

- Verbundbäume monoton 1 Schlüssel 

- Projektion über Überdeck. BCNF 

von Verbunden 

α-Azykliz. 

- Existenz von 

monotonen Verbundbäumen 

7.1.3 FD-basierte Normalformen für das relationale Modell 

Üblicher Zugang: 

T ist definiert durch eine Verbundabhängigkeit und Projektion und f ist der entsprechende Verbund 

möglich ist ebenso: Horizontale Dekompositionsabhängigkeit, Partition und Vereinigung 

Verbotene Teilstrukturen definiert durch verschiedene Normalformen : 

3NF verboten ist folgende Eigenschaft in Σ i : 

Z → {A} ∈ Σ + i , A ∉ Z, A Nichtschlüsselattribut (d.h. in keinem Schlüssel von R i), Z → U i ∉ Σ + i 

Nachteil: entscheidbar in NP 

Boyce-Codd-Normalform verboten ist folgende Eigenschaft in Σ i : 

Z → {A} ∈ Σ + i , A ∉ Z, Z → U i ∉ Σ + i 

Vorteil: entscheidbar in P 


Z →→ X ∈ Σ + i , X ⊈ Z, Z → U i ∉ Σ + i


Strenge Project-Join-NF verboten ist folgende Eigenschaft in Σ i : 

(Y 1 , ..., Y k ) ∈ Σ + i 

, {X → U i ∈ Σ + i } ̸|= (Y 1, ..., Y k ) 


(Y 1 , ..., Y k ) ∈ Σ + i 

, ∃j : Y j → U i ∉ Σ + i 

Project-Join-NF verboten ist folgende Eigenschaft in Σ i : 

(Y 1 , ..., Y k ) ∈ Σ + i 

, {X → U i ∈ Σ + i } ̸|= (Y 1, ..., Y k ) 

Überstrenge Project-Join-NF verboten ist folgende Eigenschaft in Σ i : 

(Y 1 , ..., Y k ) ∈ Σ + i 

, ∀X → U i ∈ Σ + i 

: {X → U i } ̸|= (Y 1 , ..., Y k ) 

InklusionsNF verboten ist folgende Eigenschaft in Σ i : 

R i [X] ⊆ R j [Y ] ∈ Σ + und Y → U j ∉ Σ + 

Referentielle Normalform 

genau ein Schlüssel verboten ist folgende Eigenschaft in Σ i : 

es existieren zwei verschiedene mininale Schlüssel 

Vorteil: entscheidbar in P 

Domain-Schlüssel-Abhängigkeit (DKNF) verboten ist die folgende Teilstruktur für die Menge Σ i,K der Schlüsselund 

Domainabhängigkeiten von Σ + i 

: 

α ∈ Σ + i 

, nichttrivial und Σ i,K ̸|= α 

Achtung: Verschiedene Bücher verwenden davon abweichende Notationen. 

Afunktionale und min-max-Abhängigkeiten 

afunktionale Abhängigkeit: R t |= X −→‖ Y falls für alle ν ∈ R t existiert µ ∈ R t mit ν = X µ und ν ≠ Y µ 

zur horizontalen Dekomposition von Relationen 

R t = R t 1 ∪ Rt 2 mit 

• ∅ = R t 1 ∩ Rt 2 

• R t 1 |= X → Y 

• R2 t |= X −→‖ Y 

min-max-Abhängigkeiten geben Wiederholfaktor an und gleichzeitig Begrenzung für Redundanz 

Nichtnull-Abhängigkeiten 

Ableitbarkeit von Aspekten 

Semantische Forderungen der relationalen Praxis


Unterstützung von Sichten Gegeben sei eine Sicht S V über V mit einer Menge von Integritätsbedingungen 

Σ V , die in S V gelten sollen. Dann wird gefordert, daß diese Sicht berechnet werden kann. 

∀V ⊆ U(∧Σ V = Σ + | V )∃Q∀R t UnivRrel(R t [V ]) ⊆ Q(R) 

Sichere Unterstützung von Sichten wenn = 

Sichtenanfrage-Unterstützung ∀Q ∈ Query(V, R)∃P ∈ Query(U, R) : Q(V t ) = P (R t ) 

Charakterisierung der semantischen Forderungen 

Sichtenbehandlung Sichtenanfrage-Unterstützung gdw. Unterstützung von Sichten 

im positiven Fall sogar effizient 

sichere Unterstützung von Sichten gdw. ( ⋃ F i ) + ⊇ F und (U 1 , ..., U m ) ∈ Σ + 

Unique-Key Hat ein Relationenschema genau einen minimalen Schlüssel, dann ist es genau dann in BCNF, 

wenn es in 3NF ist. 

DKNF - Anomalien Ein Relationenschema hat genau dann keine Insert und Delete anomalien, wenn es in 

DKNF ist. 

NF-Beziehungen Überstrenge PJNF ⇒ strenge PJNF 

strenge PJNF ⇒ PJNF 

PJNF ⇒ 4NF 

4NF ⇒ BCNF 

BCNF ⇒ 3NF 

||dom(A)|| ≥ 2 : DKNF ⇒ 4NF 

Alle domain-Abhängigkeiten lassen mindestens k Werte zu für k = max.-Komponenten-Anzahl in JD von 

Σ, die eine Überdeckung der Dekomposition darstellen. Dann DKNF ⇒ PJNF 

Eigenschaften von Integritätsbedingungen: 

Entscheidbarkeit der Implikationseigenschaft 

• entscheidbar für tupelerzeugende und gleichungserzeugende Abhängigkeiten 

• nicht entscheidbar für eingebettete JD’s 

• nicht entscheidbar für eingebettete MVD’s 

• nicht entscheidbar FD’s und ID’s 

Axiomatisierbarkeit von Klassen von Integritätsbedingungen 

• axiomatisierbar FD’s ∪ MVD’s 

• nicht axiomatisierbar für FD’s und Inklusionsabh. 

• axiomatisierbar für tupel- und gleichungserzeugende Abhängigkeiten 

• nicht axiomatisierbar für JD’s 

Komplexität des Implikationsproblemes 

• 3NF ist NP-complete 

• ‘Ist A Schlüsselattribut’ ist NP-vollständig 

• BCNF ist polynomial 

• Ein-Schlüssel-Problem ist polynomial 

{A ∈ U i |U i \ {A} ∉ Σ i } −→ U i ∈ Σ i 

Algorithmen Normalisierung in 2 verschiedenen Herangehensweisen


Analyse allgemeines Herangehen: wenn Schema nicht redundanzfrei, dann zerlege das Schema in 2 (oder 

mehrere) Teilschemata 

Beispiel: 

R = ({SSN, Stadt, Land, Staat, Alter, Sex}, {SSN → Stadt, Stadt → Land, Land → Staat, SSN → 

Alter, SSN → Sex}) 

R 1 = ({SSN, Stadt, Land, Alter, Sex}, {SSN → Stadt, Stadt → Land, Land → Staat, SSN → 


R 1,1 = ({SSN, Stadt, Alter, Sex}, {SSN → Stadt, SSN → Alter, SSN → Sex}) 

R 1,2 = ({Stadt, Land}, {Stadt → Land}) 

R 2 = ({Land, Staat}, {Land → Staat}) 

Nachteile: Erhaltung der IC’s ist meist schwierig zu kontrollieren 

Weiteres Beispiel: 

Ort, Bundesland, Ministerpräsident, Einwohneranzahl 

Regierung: Bundesland 

Städte: Ort, Bundesland, Einwohneranzahl 

Hintergrund: Dekomposition nach Blattabhängigkeiten 

Synthese allgemeines Herangehen: Generierung einer minimalen Überdeckung aller IC’s und Synthese nach 

dieser minimalen Überdeckung von Schemata 

Beispiel: 

R wie oben 

minimale Überdeckung aller Abhängigkeiten : {SSN → Stadt, Stadt → Land, Land → Staat, SSN → 


Gruppenbildung: {SSN, Stadt, Alter, Sex} , {Stadt, Land}, {Land, Staat} 

Hinzufügen eines Schlüsselschemas 

R 1 = ({SSN, Stadt, Alter, Sex}, {SSN → Stadt, SSN → Alter, SSN → Sex}) 

R 2 = ({Stadt, Land}, {Stadt → Land}) 

R 3 = ({Land, Staat}, {Land → Staat}) 

3NF-Algorithmus 

Input: Menge von funktionalen Abhängigkeiten für einen Typ 

Output: ein normalisiertes Schema 

Bestimmung einer kanonischen Überdeckung einer Menge von funktionalen Abhängigkeiten 

Σ c heist kanonische Uberdeckung von ΣF, wenn die folgenden drei Kriterien erfüllt sind: 

• Σ + c = Σ + c 

• . In Σ c existieren keine FDs , die überflüßige Attribute enthalten. D.h. es muß folgendes gelten: 

• ∀A ∈ X ∧ X → Y ∈ Σ c : Σ c \ {X → Y } ∪ {X \ {A} → Y } ̸|= Σ c 

• ∀B ∈ Y ∧ X → Y ∈ Σ c : Σ c \ {X → Y } ∪ {X → Y \ {B}} ̸|= Σ c 

• Jede linke Seite einer funktionalen Abhängigkeit in Σ c ist einzigartig. Dies kann durch sukzessive 

Anwendung der Vereinigungsregel auf FDs der Art X → Y, X → Y ′ erzielt werden, so 

dass die beiden FDs durch X → Y ∪ Y ′ ersetzt werden. 

Berechnung der kanonischen Überdeckung 

• Führe fur jede FD X → Y ∈ Σ c die Linksreduktion durch, d.h.: 

Überprüfe fur alle A , ob A überflüssig in X → Y ist, d.h. ob A ∈ X + Sigma c 

, X \ {A} gilt. Falls 

dies der Fall ist, ersetze X \ {A} → Y . 

• Führe für jede (verbliebene) FD die Rechtsreduktion durch. 

Überprüfe fur alle B, ob B überflüssig ist, d.h. ob 

∀B ∈ Y ∧ X → Y ∈ Σ c : Σ c \ {X → Y } ∪ {X → Y \ {B}} |= Σ c gilt. Falls dies der Fall ist, 

ist B auf der rechten Seite überflüssig und kann eliminiert werden. 

• Entferne die FDs der Form X → ∅, die im 2. Schritt möglicherweise entstanden sind.


• Fasse mittels der Vereinigungsregel FDs der Form X → Y 1 ... X → Y m zu X → Y 1 ∪ Y m . 

Konstruktion einer Dekomposition bestehend aus 2 (ggf. leeren) Teilen 

• Für jede funktionale Abhängigkeit von Σ c wird ein Schema angelegt. 

• Ist kein X mit X → Y m zu X → Y 1 ∪ Y m ∈ Σ c ein Schlüssel von R, dann wird ein Schema mit 

einem Schlüssel hinzugefügt. 

Reduktion des Schemas: Ist ein Schema entstanden, in dem die Komponenten eines Teilschemas in 

einem anderen Teilschema echt enthalten sind, dann kann das erste Teilschema entfernt werden. 

Eigenschaft des Algorithmus: (SSA) 

Proposition 1 Es werden alle Abhängigkeiten erhalten. 

Proposition 2 Das Resultat ist ein Schema, in dem alle Relationenschemata in dritter Normalform sind. 

Überblick über Normalisierungsalgorithmen 

Author Strategie NF IC Relships Komplex. 

Bernstein Synthese 3NF FD CR polyn. 

Fagin Analyse 4NF FD+MVD LD exp. 

Biskup/D/B Synthese 3NF FD LD+CR polyn. 

Ullman Analyse 4NF FD+MVD LD exp. 

Tsou/Fischer Analyse 4NF FD+MVD LD polyn. 

Zaniolo/Melkanoff Analyse 3NF FD+MVD LD+CR expon. 

LD = lossless decomposition ; CR = constraint representation 

Theorem 1 Die Zerlegung π X∪Y (R C ) und π X∪Z (R C ) ist verlustlos für disjunkte Mengen X, Y, Z falls π X∪Y ∪Z (R C ) = 

π X∪Y (R C ) ✶ π X∪Y (R C ) gilt. 

Proposition 3 Gilt die funktionale Abhängigkeit X → Y in R C , dann ist die Zerlegung π X∪Y \X (R C ) und 

π X∪U\(X∪Y ) (R C ) verlustlos. 

∀(U, F )∃(X 1 , ..., X m ) : (U, F ) unterstützt (X i , F i ) mit Verbund für Anfragen und alle (X i , F i ) sind in BCNF 

∀(U, F )∃(X 1 , ..., X m ) : (U, F ) unterstützt sicher (X i , F i ) mit Verbund für Anfragen und alle (X i , F i ) sind in 

3NF 

Leider werden BCNF nicht durch einen Synthesealgorithmus erzeugt. Es existiert jedoch die Beobachtung 

1. 

Ursache von Nicht-BCNF-fähigen Schemata: Überladung von Attributen (Makowsky) 

Behebung: Aufspleißen des Attributes 

Ort, PLZ, Straße 

{ Ort, Straße } → {P LZ} 

{P LZ} → {Ort} 

Überladenes Attribut, das zerlegt werden kann 

PLZ Ortsbereich, PLZ Zustellbezirk 

{ Ort, Straße } → {P LZ Zustellbezirk} 

{P LZ Ortsbereich} ↔ {Ort} 

Speicherkosten Ein Schema S ist in xNF gdw. jede Dekomposition T von S hat für jede DB S t komplexere Darstellung, 

d.h. 

size(S t ) ≤ size(T (S t ))


Update-Kosten ∀R ∀X ⊆ U i (X → U i ∈ Σ + )∀(R1 t , ..., Rt m) ∀{t} ∈ SAT (R i ) 

SAT (R) 

gdw. R i referenziert nicht, hat genau einen Schlüssel und ist in BCNF 

(R t 1 , ..., Rt i−1 , Rt i ∪{t}, Rt i+1 , ..., Rt m) ∈ 

Konsistenz von Schemata Verbundabhängigkeit heißt m-zyklisch, wenn äquivalent zu einer Menge von Verbundabhängigkeiten 

mit höchstens m Komponenten jeweils. 

2-zyklisch = azyklisch 

Implikationsproblem von FD’s und m-zyklischen Verbundabhängigkeiten ist polynomial; das normale Problem ist NPhart 

Azyklizität ist mit Graham-Algorithmus testbar: 

Termersetzungssystem: Regel 1: (Y 1 , ..., Y m ) ⇒ (many(Y 1 ), .., many(Y m )) 

Regel 2: falls Y i ⊆ Y j , i ≠ j : (Y 1 , ..., Y m ) ⇒ (Y 1 , .., Y i−1 , Y i+1 , ..., Y m ) 

(Y 1 , ..., Y m ) ⇒ ∗ λ gdw. azyklisch 

Schema R heißt k-konsistent, wenn für beliebige j 1 , ..., j k ∈ {1, ..., m} und i ∈ {j 1 , ..., j k } gilt: (R j1 ✶ ... ✶ 

R jk )[R i ] = R i 

R ist konsistent, wenn m-konsistent 

R ist k-konsistent gdw. (U 1 , ..., U m ) k-zyklisch ist 

ein Schema ist paarweise konsistent, genau dann wenn für alle i,j R i [U i ∩ U j ] ⊆ R j [U i ∩ U j ] 

Hypergraphen 

zur Darstellung der Join-Verbindung von Attributen in Schemata 

damit kann für Attribute auch eindeutiges Verständnis von Gesichtspunkten ausgedrückt werden 

Universalrelationen-Annahme (universal relation schema assumption) : Jedes Attribut ist bzgl. seiner Bedeutung 

eindeutig unabhängig vom Schema definiert. 

Wenn erfüllt, dann kann gesamte Datenbank als eine Universalrelation (evt. aufgefüllt mit Nullwerten - schwache 

Universalrelation) aufgefaßt werden. 

Basiszusammenhang-Annahme (basic connection assumption): Jede Attributteilmenge X ⊆ U hat genau eine 

Bedeutung im Schema. 

damit Anfragebedeutung durch Attributmenge eindeutig bestimmt 

Ein-Geschmack-Annahme (unique flavour assumption): für jeden Benutzer und jede Attributmenge in einem relationalen 

Ausdruck und jede Datenbank R t ist jedem Tupel unabhängig von der Art seiner Erzeugung eine 

Bedeutung zugeordnet 

Arten von Zyklen in Hypergraphen 

Pfade im Hypergraphen deuten auf die Komplexität der Berechnung von Anfragen hin 

je einfacher der Pfad ist, umso einfacher wird die Berücksichtigung von Nebenbedingungen 

purer Zyklus Folge Y 1 , ..., Y k mit Y i ∩ Y i+1modk ≠ ∅ 1 ≤ i ≤ k und Y i ∩ Y j ∩ Y l = ∅ für verschiedene i,j,l 

für Attribute gibt es mindestens zwei verschiedene verbindende Pfade 

z.B. ({A, B}, {B, C}, {C, D}, {D, E}, {E, A}) 

damit zwischen A, C zwei verbindende Pfade, die auch verschiedene Zusammenhänge formalisieren können 

γ-Zyklus Y 1 , Y 2 Y 3 mit Y 1 ∩ Y 2 ∩ Y 3 ≠ ∅ , (Y 1 ∩ Y 2 ) \ Y 3 ≠ ∅ , (Y 2 ∩ Y 3 ) \ Y 1 ≠ ∅ 

dann existieren für Attribute in (Y 2 ∩ Y 3 ) \ Y 1 ≠ ∅ und (Y 1 ∩ Y 2 ) \ Y 3 ≠ ∅ wieder 2 verbindende Pfade 

Beispiel: ({A, C, H}, {B, C, K}, {A, B, C, L}) 

zwei verschiedene Pfade zwischen A, B, die evt. verschiedene Zusammenhänge formalisieren


Damit ist Schema 

γ-azyklisch falls weder purer noch γ-Zyklus existiert 

α-azyklisch wenn obiger Reduktionsalgorithmus von Graham λ liefert 

Ein Schema ist gd. γ-azyklisch, wenn Join monoton ist, bzw. wenn verlustlose Projektionen (join und project sind 

vertauschbar) existieren bzw. gdw. eindeutige Verbindungen existieren . 

d.h. Verbundabhängigkeit des Schemas impliziert alle eingebetteten Verbundabhängigkeiten 

α-azyklisch gdw. ∃ monotoner Verbundbaum gdw. keine hängenden Tupel gdw. R t i = Rt [U i ] gdw. alle mehrwertigen 

Abhängigkeiten implizieren Verbund 

Klassische Dekompositionstheorie ergibt bereits eine Reihe von Schemazerlegungen, z.B. das Schema in Bild 1 kann 

in eines der Schemata in Bild 2 zerlegt werden. 

C 

✻ 

A 

✛ 

R 

✲ 

B 

Abbildung 1: Ein Beispielschema 

A 

✛ 

R2 

R2 

✲ 

C 

✛ 

R3 

C 

✛ 

❄ 

R1 ✲ 

Schema 2 

B 

❄ 

A 

✛ R1 ✲ 

Schema 3 

❄ 

B 

C 

C 

✛ 

✛ 

R1 ✲ A ✛ R2 ✲ 

Schema 1’ 

R1 ✲ A ✛ R2 ✲ 

Schema 1 

C 

C 

Abbildung 2: Die Zerlegung des Beispielschemas 

Die Zerlegung hängt von der Gültigkeit von Integritätsbedingungen ab. Der Fall ‘funktionale Abhängigkeiten’ ist 

in der folgenden Tabelle dargestellt. 

Funktionale Abhängigkeiten Schema nach Dekomposition 

{A} → {B} Schema 1 

{A} → {B} → {C} Schema 1’ 

{A} → {B, C} Schema 1 

{A} ↔ {B} → {C} Schema 1, Schema 1’ 

{A} ↔ {B, C} Schema 2 

{A} ↔ {B} ↔ {C} Schema 3 

{A} → {B} ← {C} Schema 3 

{A, B} → {C} 

kein neues Schema 

{A} ↔ {B} Schema 1, Schema 1’


Eine analoge Tabelle läßt sich auch für mehrwertige Abhängigkeit angeben. 

Vorsicht vor anderen Zerlegungen der Proponenten des binären Entity-Relationship-Modelles. 

7.1.4 ER-Entwurfstheorie 

Verschiedene Gründe für die Normalisierung: 

+ Speicherminimierung: Redundante Daten erfordern zusätzlichen Speicherplatz. 

+ Minimierung des Risikos inkonsistenter Datenbanken: Die Kontrolle der Konsistenz von Datenbanken 

erfordert zusätzliche Operationen. Da damit die Integritätspflege die Performanz eines Systemes negativ beeinflußt, 

sollte die Konsistenzpflege minimiert werden. 

+ Anomalien: Sind in einer Datenbank Werte redundant gespeichert, dann ist bei jeder Operation über solchen 

Werten entweder diese Operation auch auf redundante Werte angewandt werden oder eine extra Spezifikation 

der Integritätspflege vorgenommen werden. 

+ Schemastabilität bei Änderungen: Durch Normalformen ziehen Änderungen des Datenschemas weniger 

Änderung der Datenbestände nach sich. 

Traditionelle Normalisierungstheorie 

Lokale Normalisierung: Jede Relation separat. 

Eingeschränkte IC-Zielmenge: Es werden i.a. nur Schlüsselbedingungen unterstützt. 

Besser: 

Globale Normalisierung mit eingeschränkten Zielen (Lokalisierung der zu normalisierenden Teile, ...). 

Einfache IC-Mengen: Abbildung von (S, Σ) auf (S ′ , Σ ′ ) mit Σ ′ ⊆ GoodConstraints. 

Beispiel bereits in Ansätzen in der relationalen Theorie: DK/NF (domain-key-NF), domain dependencies, key 

dependencies 

Normalisierungszugänge sind meist auf die Struktur einer Datenbank ausgerichtet und berücksichtigen kaum, ob semantisch 

sinnvolle Einheiten zerlegt werden oder sogar die Performanz dadurch sinkt. Damit wird nicht die akurate 

Modellierung bewertet, sondern eher die strukturelle Korrektheit. Deshalb wird hier auf Normalisierung nicht in vollem 

Umfange Wert gelegt. Wir unterscheiden zwischen relationaler, hierarchischer und Netzwerk-Normalisierung. 

Da auch bei der Modellierung bereits die Art der Plattform mit berücksichtigt werden kann, sollte man in diesem 

Schritt auch die Art der Normalisierung mit berücksichtigen. Im weiteren wird die relationale Normalisierung bevorzugt. 

Ziel ist ein Schema, das sich in ein Normalform-Schema des logischen Zielmodelles übersetzen läßt ohne daß eine 

zusätzliche Normalformbetrachtung erforderlich wird. Im Vorgriff definieren wir deshalb eine HERM-Normalform 

relationaler Schemata. Darauf aufbauend wird eine Normalform für HERM-Schemata definiert. 

Für ein relationales Schema R = (R, F, I) mit der Attributmenge R, den funktionalen Abhängigkeiten F und den 

Inklusionsabhängigkeiten I wird anhand der Inklusionsbeziehungen ein Graph mit den Knoten R definiert. Für jeden 

Typ R werden die ID’s R[X 1 ] ⊆ S 1 [Y 1 ], ..., R[X n ] ⊆ S n [Y n ] zusammengestellt (verlassende ID’s). Z R = ∪ n i=1 X i 

Relationshiptyp 0-ter Ordnung: Typ, der keine unpaaren verlassenden ID’s hat (d.h. T [Z] ⊆ R[X] ⇒ R[X] ⊆ 

T [Z]).


Relationshiptyp i-ter Ordnung: Im Graphen gelten folgende Eigenschaften: 

1. Keine unpaaren verlassenden ID’s. 

2. Mindestens ein Typ S j ist (i − 1)-ter Ordnung. Die maximale Ordnung der Typen S j ist i − 1. 

3. Alle linken Seiten der verlassenden ID’s sind paarweise disjunkt. 

4. Alle linken Seiten Z R bilden eine Schlüssel von R. 

Schwacher Typ i-ter Ordnung: Folgende Bedingungen gelten: 

1. n ≥ 1 

2. Für jeden minimalen Schlüssel W von R existiert eine Zerlegung W 1 , W 2 so daß W 1 ∩ X i = ∅ oder 

W 1 ∩ X i = X i gilt und W 2 ∩ Z = ∅. 

Ein relationales Schema ist in HERM-Normalform, falls 

1. die ID-Menge azyklisch und nicht redundant ist, 

2. alle ID’s schlüsselbasiert sind (d.h. R[X] ⊆ S[Y ] ⇒ Y Teil eines Schlüssels von S oder selbst Schlüssel von 

S ist), 

3. alle Typen in BCNF bzgl. F ∪ I sind und 

4. R zerlegt werden kann in Relationshiptypen entsprechender Ordnung bzw. schwache Typen entsprechender 

Ordnung. 

Ein HERM-Schema ist in Normalform, wenn jeder Typ in BCNF ist, alle Inklusionsabhängigkeiten schlüsselbasiert 

sind und wenn Relationshiptypen durch ihre Komponenten identifizierbar sind. 

Es gilt: Ein HERM-Schema ist in ein relationales Schema in HERM-Normalform genau dann durch einfache 

Transformation ohne Einbettung transformierbar, wenn es in HERM-Normalform ist. 

(d.h.: Jedem Typen wird ein relationaler Typ zugeordnet. Komponenten in Relationshiptypen werden durch einen 

minimalen Schlüssel mit entsprechenden Erweiterungen des Namen dargestellt.) 

Analog kann eine Transformation mit Einbettung über comp(R, R ′ ) = (1, 1) definiert werden. Es sei V = R \ Z. 

Relationshiptyp 0-ter Ordnung mit Fremdschlüsseln Es gibt nur solche unpaare verlassende ID’s R[X] ⊆ S[Y ] 

mit X ∩ K = ∅ für einen Schlüssel K von R. 

Relationshiptyp i-ter Ordnung mit Fremdschlüsseln wie oben 

Schwacher Typ i-ter Ordnung mit Fremdschlüsseln 

2. wie oben 

1. wie oben 

3. mindestens eine verlassende ID R[X] ⊆ S[Y ], wobei X ein Teil eines minimalen Schlüssels ist. 

Ein relationales Schema ist in schwacher HERM-Normalform, falls 

1. die ID-Menge azyklisch und nicht redundant ist, 

2. alle ID’s schlüsselbasiert sind (d.h. R[X] ⊆ S[Y ] ⇒ Y Teil eines Schlüssels von S oder selbst Schlüssel von 

S ist), 

3. alle Typen in BCNF bzgl. F ∪ I sind und


4. R zerlegt werden kann in Relationshiptypen mit Fremdschlüsseln entsprechender Ordnung bzw. schwache Typen 

mit Fremdschlüsseln entsprechender Ordnung. 

Beispiel: 

Institut = (Name, Gebäude) 

Angestellter = (Name, ArbeitetIn.Institut.Name, Gehalt) 

Angestellter[ArbeitetIn.Institut.Name] ⊆ Institut[Name] 

Dieses relationale Schema kann nach obigen Regeln zur Überführung in ein HERM-Schema überführt werden. Wir 

erhalten die Typen 

Institut’ = ( { Name, Gebäude }, { Name } ) 

Angestellter’ = ( { Name, Gehalt }, { Name } ) . 

Das relationale Schema Angestellter enthält einen Fremdschlüssel. Außerdem gilt die Inklusionsabhängigkeit. Bei 

Einführung eines Relationshiptypen 

ArbeitetIn = ( Angestellter’, Institut’, ∅ ) 

mit den Komplexitätsbeschränkungen 

comp(ArbeitetIn, Angestellter ≽ (0,1) , comp(ArbeitetIn, Angestellter) ≽ (1,n) , 

die sich aus der Schlüsselabhängigkeit von Angestellter undder Inklusionsabhängigkeit ableiten. Das HERM-Diagramm 

ist in Bild 4 dargestellt. Die Einlagerung kann mitunter besser sein aus operationalen Gesichtspunkten. 

Name 

Gehalt 

Name 

Gebäude 

Angestellter’ ✛ 

(1,1) 

ArbeitetIn 

✲ 

Institut’ 

Abbildung 3: Beispiel für ein HERM-Schema, das in eine schwache HERM-NF überführt wird 

Damit ist ein anderes Herangehen möglich als in der Literatur empfohlen: 

* Schrittweise Transformation von HERM-Schemata in normalisierte HERM-Schemata; gegebenenfalls mit Unterstützung 

des Benutzers 

* Festlegen des für den Benutzer noch tolerierbaren veränderten Schemas; 

Hat ein anderes Schema ein besseres operationales Verhalten, ist aber für den Benutzer nicht ausreichend 

einsichtig, dann kann das Transformationsverfahren als Regelwerk abgelegt werden. 

* Automatische Überführung des normalisierten HERM-Schemas in ein normalisiertes relationales Schema. 

Der Benutzer kann im weiteren auf dem HERM-Schema arbeiten und ist nicht auf ein Verständnis der Normalisierung 

angewiesen. 

Es gibt eine Reihe von Verhaltensproblemen in Datenbanken, die auf schlechte Strukturierung zurückführbar sind: 

Schlüsselbasierte update-Anomalien: Durch eine update-Operation kann eine, die Primär- oder alle Schlüsselbeziehungen 

außer Kraft gesetzt werden. Die beiden ersten Fälle werden bei 4NF bzw. BCNF vermieden. 

Schlüsselbasierte insert-Anomalien: Obwohl nach einer insert-Operation alle Schlüsselbeziehungen gelten, kann 

eine andere Integritätsbedingung, die vorher galt, nicht mehr gelten. Schemata in vierter Normalform sind frei 

von diesen Anomalien. 

Schlüsselbasierte delete-Anomalien: Obwohl nach einer delete-Operation alle Schlüsselbeziehungen gelten, kann 

eine andere Integritätsbedingung, die vorher galt, nicht mehr gelten. Schemata in vierter Normalform sind frei 

von diesen Anomalien.


Nichtdeterministische Operationen: Die Verfeinerung der Operation führt zu einer Operation, die je nach Fall 

verschiedene Eingabeinformationen erfordert. Man kann unterscheiden in Identifikationsinformationen und 

Objektinformationen, die auf das betroffene Objekt abzielen. Ist ein Typ in BCNF bzw. in 4NF, dann ist ein 

solches Verhalten ausgeschlossen für die Verfeinerung der einfachen Operationen. 

Objektbasierte update-Anomalien: Obwohl das Einfügen des modifizierten Objekten wieder zu einem konsistenten 

Zustand führt, ist die direkte Modifikation nicht konsistent. 

Redundante Informationsmengen: Eine Information kann ohne Benutzung dieser aus bereits in der Datenbank 

vorhandenen Informationen abgeleitet werden. 

7.1.5 ER-basierte Behandlung von mehrwertigen Abhängigkeiten 

Mehrwertige Abhängigkeiten sind genuine ER-Abhängigkeiten wie wir im weiteren zeigen werden. 

Wir betrachten zuerst einige einfache Beispiele: 

Name 

Gehalt 

Name 

Gebäude 

Angestellter’ ✛ 

(1,1) 

ArbeitetIn 

✲ 

Institut’ 

Abbildung 4: Beispiel für ein HERM-Schema, das in eine schwache HERM-NF überführt wird 

Student ✛ 

✻ 

❨ 

Belegt 

✲ 

Vorles 

InDept 

Von 

❄ 

Dept 

❥ 

Leiter 

Abbildung 5: Ungünstige Zerlegung des komplexen Typen 

Student ✛ 

Belegt 

✲ 

Vorles 

✻ 

InDept 

❄ 

Dept 

✛ 

Leitet 

✲ 

Leiter 

Abbildung 6: Bessere Zerlegung des komplexen Typen 

Die unterschiedlichen Definitionen von mehrwertigen Abhängikeiten am Beispiel. 

Beispiel: Mitarbeiter, Mitversichert, Projekt, Lieferant, Produkt


{ Name } → { Abteilung, Mitversichert }|{ Projekt, Produkt, Lieferant } 

{ Name } → { Mitversichert }|{ Abteilung, Projekt, Produkt, Lieferant } 

{ Projekt } → { Name, Abteilung, Mitversichert }|{ Produkt, Lieferant } 

{ Produkt } → { Abteilung, Name, Mitversichert, Projekt }|{ Lieferant } 

Ein Mitarbeiter determiniert die Abteilung und seine Mitversicherte unabhängig von den Projekten und benutzten 

Produkten, sowie deren Lieferanten. 

... 

In einem Projekt wird mit Produkten von Lieferanten unabhängig von den Mitarbeitern, deren Mitversicherten und 

deren Abteilungen gearbeitet. 

Ein Produkt wird von einem Lieferanten geliefert, unabhängig wer in welchem Projekt damit arbeitet. 

Gegeben: relationales Schema R = (U R , Σ R ), Relation R C über R 

Teilmengen X, Y ⊆ U R und Z = U R \ (Y ∪ X) 

(1) Klassische Definition: R C |= X → Y |Z 

falls für alle t, t ′ ∈ R C mit t = X t ′ ein Element t ′′ ∈ R C 

existiert mit t ′′ = X∪Y t und t ′′ = X∪Y t ′ 

(2) Dekompositionsdefinition: R C |= X → Y |Z 

falls R C = R C [X ∪ Y ] ✶ R C [X ∪ Z] 

(3) Unabhängigkeitsdefinition: R C |= X → Y |Z 

falls (σ X=x (R C ))[Y ] = (σ (X=x)∧(Z=z) (R C ))[Y ] 

für alle X-Werte x ∈ R C [X] und alle Z-Werte z ∈ R C [Z] 

Äquivalenzbeweis: (1) ⇒ (2) ⇒ (3) ⇒ (1) 

Z.B. für (1) ⇒ (2) ist Ziel: R C ⊇ R C [X ∪ Y ] ✶ R C [X ∪ Z] 

Gegeben seien t 1 ∈ R C [X ∪ Y ] und t 2 ∈ R C [X ∪ Z] mit t 1 = X t 2 

⇒ {t 1 } ✶ {t 2 } ⊆ R C wegen R C |= X → Y |Z 

Diese Definitionen im Beispiel: 

Name Abteilung Project Produkt ... 

Bodo DB-Adm Migration DB2 ... 

Bodo DB-Adm Integration Sybase ... 

Bodo DB-Prog Migration DB2 ... 

Bodo DB-Prog Integration Sybase ... 

Hans DB-Adm Ablösung MS SQL ... 

Hans Middlew Ablösung MS SQL ... 

Karl DB-Prog Migration DB2 ... 

Karl DB-Prog Portal Sybase ... 

... ... ... ... ... 

• Ableitung von Tupeln aus existierenden: 

Name Abteilung Project Produkt ... 

Bodo DB-Adm Migration DB2 ... 

Bodo DB-Prog Integration Sybase ... 

Bodo DB-Adm Integration Sybase ... 

• Dekomposition in { Name, Abteilung } und { Name, Project, Produkt,...}


Name Abteilung Name Project Produkt ... 

Bodo DB-Adm Bodo Migration DB2 ... 

Bodo DB-Prog Bodo Integration Sybase ... 

Hans DB-Adm Hans Ablösung MS SQL ... 

Hans Middlew Karl Migration DB2 ... 

Karl DB-Prog Karl Portal Sybase ... 

... ... ... ... ... 

Zwei weitere Definitionen sind die folgenden: 

(4) Konstruktordefinition: R C |= X → Y |Z 

falls für alle x ∈ R C [X] mit (σ X=x (R C ))[Y ∪ Z] = (σ X=x (R C ))[Y ] × (σ X=x (R C ))[Z] 

d.h. ν Z (ν Y \X (ν X (R C ))) = ν Y \X (ν Z (ν X (R C ))) 

(5) Strukturierungsdefinition: R C |= X → Y |Z 

R C {X} {Y } {Z} 

A 1 ... A k A k+1 ... A m A m+1 ... A n 

... ... ... ... ... ... ... ... ... 

X = {A 1 , ..., A k }, Y = {A k+1 , ...., A m }, Z = {A m+1 , ..., A n } 

als verschachtelte Relation 

Weiterführung der Beispiele 

• Verschachtelte Relation: (Name, {Abteilung }, { Project, Produkt,...} ) 

Name { Abteilung } { (Project, Produkt, ...) } 

Bodo { DB-Adm, DB-Prog } { (Migration, DB2, ...) 

(Integration, Sybase,...) } 

Hans { DB-Adm, Middlew } { (Ablösung, MS SQL, ... )} 

Karl { DB-Prog } { (Migration, DB2, ...) 

(Portal, Sybase, ...) } 

... ... ... 

Die ER-Behandlung von MVD’s. 

Gegeben: relationales Schema R = (U R , Σ R ), Relation R C über R 

Teilmengen X, Y ⊆ U R und Z = U R \ (Y ∪ X) 

(6) Trennung von Gesichtspunkten: R C |= X → Y |Z 

Y ✛ XY ✲ X ✛ XZ ✲ 

Z 

oder als Schneeflockenschema mit Relationship-Typen 

✛ 

XY ✲ X ✛ XZ ✲ 

oder als Sternschema mit schwachen Relationship-Typen 

Y(X) 

✲ X ✛ (X)Z 

(1,n) (1,n)


(Abteilung) 

DB-Adm 

DB-Prog 

Middleware 

✲ Mitarb. ✛ 

Bodo 

Hans 

Karl 

(Project, Produkt,...) 

(Migration, DB2, ...) 

(Integration, Sybase,...) 

(Ablösung, MS SQL, ... ) 

(Portal, Sybase, ...) 

Das Beispielschema und die behandelte MVD wird dann durch das folgende ER-Diagramm repräsentiert: 


Ein adäquate Behandlung von MVD ist nur mit vollständiger rechter Seite sinnvoll. 

Die Axiomatisierung von mehrwertigen Abhängigkeiten in der ER Welt. 

Ableitungsregeln in der klassischen relationalen Notation: 

Gegeben seien: 

X, X ′ , X ′′ , Y, Y ′ , Z, Z ′ , V, W ⊆ U 

alle Mengen einer Abhängigkeit bilden Überdeckung von U 

Axiom: (1 M ) X → ∅|Z 

Regeln 

(23 M ) 

(27 M ) 

(21 M ) 

X → X ′ ∪ Y |X ′′ ∪ Z 

X ∪ X ′ ∪ X ′′ → Z|Y 

X ∪ V → Y |Z , X → Y ∪ Z|V 

X → Y |Z ∪ V 

(Abschwächung) 

(Wurzelreduktion) 

X → Y ∪ Y ′ |Z ∪ Z ′ , X → Y ∪ Z|Y ′ ∪ Z ′ (Baumrestrukturierung) 

X → Y |Z ∪ Z ′ ∪ Y ′ 

Theorem 2 (1) (1 M ), (21 M ) und (23 M ) sind vollständig für mehrwertige Abhängigkeiten 

(2) (1 M ), (21 M ), (23 M ) und (27 M ) sind korrekt 

Ableitungsregeln (Strukturell): 

Axiom 

Wurzelreduktion 

X ∪ Z 

✲ 

X 

Y (X) 

✲ X ∪ V ✛ (X)Z Y ∪ Z(X) 

✲ X ✛ (X)V 

Y (X) 

✲ 

X 

✛ (X)Z ∪ V 

Baumrestrukturierung 

Abschwächung 

Y ∪ Y ′ (X) 

(X)Y ′ ∪ Z ′ 

X ′ ∪ Y (X) 

✲ 

X 

✛ (X)X ′′ ∪ Z 

❄ 

X 

✛ (X)Z ∪ Z ′ 

Y ∪ Z(X) 

✲ 

❄ 

X 

Y 

(X ∪ X ′ 

∪X ′′ ) 

✲ 

X 

∪X ′ 

∪X ′′ 

✛ 

Z 

(X ∪ X ′ 

∪X ′′ ) 

✲ Y (X) 

✛ (X)Z ∪ Z ′ ∪ Y ′ 

X 

Ableitungsregeln für MVD und FD


X, X ′ , X ′′ , Y, Y ′ , Z, Z ′ , V, W ⊆ U 

alle Mengen einer mehrwertigen Abhängigkeit bilden Überdeckung von U 

Axiom: (1 F ) X ∪ Y −→ Y (1 M ) X → ∅|Z 

X −→ Y 

Regeln (21 F ) 

(FD − MVD − Reduktion) 

X → Y 

X −→ Y , Y −→ Z 

(22 F ) 

(FD − Transitivität) 

X ∪ V ∪ W −→ V ∪ Z 

(23 M ) 

(3 F,M ) 

(21 M ) 

X → X ′ ∪ Y |X ′′ ∪ Z 

X ∪ X ′ ∪ X ′′ → Z|Y 

X ∪ V → Y |Z , X → Y ∪ Z|V 

X → Y |Z ∪ V 

X ∩ Y 

→ Y \ X|X \ Y , X −→ Z 

X ∩ Y −→ Y ∩ Z 

(MVD − Abschwächung) 

(MVD − Wurzelreduktion) 

(FD − Rückkopplung) 

Theorem 3 (1 F ), (1 M ), (21 F ), (22 F ), (23 M ), (3 F,M ) sind vollständig und korrekt für funktionale und mehrwertige 

Abhängigkeiten. 

Beweis: siehe B. Thalheim - HERM-Buch 

Hierarchische Abhängigkeit X 

→ Y 1 |Y 2 |...|Y m als Verallgemeinerung der mehrwertigen Abhängikeiten 

Y 2 (X) ... 

Y 1 (X) 

❄ 

✲ 

X ✛ 

(X)Y m 

Ableitungsregel: 

(27 H ) 

X → Y ∪ Y ′ |Z ∪ Z ′ , X → Y ∪ Z|Y ′ ∪ Z ′ (Baumentfaltung) 

X → Y |Y ′ |Z|Z ′ 

✲ 

Y ∪ Y ′ (X) 

✛ (X)Z ∪ Z ′ 

X 

✲ 

Y ∪ Z(X) 

✛ (X)Y ′ ∪ Z ′ 

X 

Y (X) 

Y ′ (X) 

❄ 

✲ 

Z(X)... 

❄ 

X ✛ 

(X)Z ′ ✲ 

Abhängigkeitsbasis 

Gegeben Menge funktionaler und mehrwertiger Abhängigkeiten Σ 

X + = { A ∈ U | Σ |= X −→ {A} } 

Dep M (X, Σ) = { Y i | Σ |= X → Y i , Y i ∩ X + = ∅, 

̸ ∃Y i ′ ⊂ Y i(Y i ′ ≠ Y i ∧ Σ |= X → Y i ′) 

} 

Dep M,F (X, Σ) = Dep M (X, Σ) ∪ { X + \ X }


Abhängigkeitsbasis 

X 

X + \ X 

✠ 

(X)Y 1 

✛ 

(X)Y 2 

❪ ... 

(X)Y m 

als Stern-Schema 

Unterschiedliche Sichtweisen 

über Schalen des Sterns 

Verallgemeinerung 

zu Schneeflocken-Schema 

Berechnung über Axiomatisierung mit hierarchischen Abhängigkeiten 

analoge Theorie zu Graph-Abhängigkeiten 

Erwünscht: Konkurrenzfreie (konfliktfreie) Abhängigkeitsbasis 

Ausblick zur Abhängigkeitsbasis 

• Es existiert ein O(|R| · |Σ| p )-Algorithmus zur Bestimmung der Abhängigkeitsbasis einer Menge X ⊆ U. 

• Konkurrierende Abhängigkeitsbasis besitzt 

• Wurzelschnitt: es existiert für X → Y |Z ∈ Σ ∗ eine spleißende Abhängigkeit S → T |V ∈ Σ ∗ , 

d.h. es gilt sowohl X ∩ T ≠ ∅ als auch X ∩ V ≠ ∅ , 

oder 

• Schnittanomalie: aus Σ |= X → Z|V, Y → Z|W folgt nicht Σ |= (X ∩ Y ) → Z. 

• Konkurrierende Abhängigkeitsbasis führt zu unterschiedlichen 

Schema-Varianten je nach Sichtweise 

Vereinheitlichung durch Vergröberung oder 

Ergänzung der Abhängigkeiten 

Reduzierte Abhängigkeitshülle: 

Σ ∗ = { X → Y |Z | Σ |= X → Y |Z , X ∩ Y = X ∩ Z = Y ∩ Z = ∅ , Y ≠ ∅ , Z ≠ ∅ } 

Sichtweisen durch Abhängigkeitsbasis 

Mitarbeitsichtweise 

DepBasis(Name,Σ) \{ Name} = 

{{ Abteilung }, { Mitversichert }, { Project, Produkt, Lieferant }} 

(Project, Produkt, Lieferant) 

❄ 

Abteilung ✲ Name ✛ Mitversichert


Projektsichtweise 

DepBasis(Projekt,Σ) \{ Projekt} = 

{{ Produkt }, { Lieferant }, { Name, Abteilung, Mitversichert }} 

(Name, Abteilung, Mitversichert) 

❄ 

Produkt ✲ Projekt ✛ Lieferant 

Sichtweisen durch Abhängigkeitsbasis 

Dekomposition des Relationship-Typen zu einem Teilschema 

nur im Fall konkurrenzfreier mehrwertiger Abhängigkeiten 

ansonsten Wahl einer Sichtweise 

oder Wahl einer Abschwächung 

oder wiederholte Betrachtung der Abhängigkeiten 

z.B. kann Lieferant ggf. falsch angebunden sein (zu schwach spezifiziert) 


Unterschiedliche Sichtweisen sind ggf. je nach Aspekt der Anwendung interessant und können ggf. auch konkurrierend 

benutzt werden. 


Eine kombinierte Sichtweise kann, muß aber nicht existieren. 

Kombinierte Sichtweise 

DepBasis(Name,Σ) \{ Name} = 

{{ Abteilung }, { Mitversichert }, { Project, Produkt, Lieferant }} 

DepBasis(Projekt,Σ) \{ Projekt} = 

{{ Produkt }, { Lieferant }, { Name, Abteilung, Mitversichert }} 

Abteilung 

✛ 

arbeitet ✲ Name ✛ Mitversichert 

❄ 

Produkt ✲ Projekt ✛ Lieferant 


• Mehrwertige Abhängigkeiten spezifizieren eine interne Strukturierung. 

• Mehrwertige Abhängigkeiten sind axiomatisierbar. 

(auch gemeinsam mit funktionalen Abhängigkeiten


nicht aber gemeinsam mit Inklusionsabhängigkeiten 

(Verwaschung der Arten)) 

• Die Abhängigkeitsbasis erlaubt eine vollständige Entfaltung zu stärkster hierarchischer Abhängigkeit. 

Die ER-Repräsentation führt zu einem verständlichem Schema. 

• Es können konkurrierende Schemata existieren. 

Literatur






D - 24098 Kiel 

 





8. Verteilung ab SS 2011/12 


Forschung 



8 Spezifikation der Verteilung bzw. der Kollaboration 

Entzwei’ und gebiete! Tüchtig Wort; 

Verein’ und leite! Bessrer Hort. 

Goethe, Sprichwörtlich 

auch Wieringa Part V 

Zusätzliche Literatur: [?, ?, Sch96, ?, ?, ?] 

8.1 Grundlagen verteilter Datenbanksysteme 

Bestandteil der Grundvorlesung 

In den 60er und 70er Jahren beobachteten wir einen Übergang von Datei- zu Datenbanksystemen. Damit wurden die Datenunabhängigkeit 

der Anwendungsprogramme erhöht, eine transaktionsorientierte Verarbeitung und ein Mehrnutzerbetrieb ermöglicht sowie eine hohe Ausfallsicherheit 

im Parallelbetrieb erreicht, insbesondere durch Integration von Recovery-Funktionen wie Crash-Recovery, Media-Recovery. Da 

Hardware teuer war, wurden die teuren Hardware-Ressourcen effizient genutzt durch eine starke Zentralisierung von Rechentechnik. Damit 

standen kleine Adreßräume zur Verfügung und die Software war limitiert. Damit mußten auch eine redundanzarme bzw. -freie Speicherung 

von Daten und eine minimale Anzahl von Relationen erzwungen werden. Diese Situation änderte sich danach vollständig. Hardware wurde zunehmend 

kostengünstiger. Man konnte schrittweise zu ‘online’-Anwendungen übergehen. Damit versagte allerdings auch die Datenintegration 

via Job-Control-Sprache. Es wurde außerdem ein ‘online’-Update erforderlich. Dies bedingte das Zusammenführen von bislang getrennten 

Anwendungen und Datenbeständen. Außerdem mußte die Integration verteilter Informationssysteme angestrebt werden. 

In den 80er Jahren wurden mit der Weiterentwicklung der Datenbanktechnologie verstärkt verteilte Systeme eingesetzt. Dafür gibt es 

verschiedene Ursachen: 

• Daten werden zunehmend teurer und stellen Kapital dar, dessen Pflege meist nur einer Einrichtung zugeordnet werden darf. Daten 

werden wieder direkt ‘vor Ort’ verarbeitet wie vor Einführung der Rechenzentren. 

• Das Geschäftsleben und der Wettbewerb werden globalisiert. Die Benutzeranforderungen und der Markt favorisieren deshalb eine 

dezentralisierte Verwaltung bei der Forderung nach einer vollständigen Benutzbarkeit aller Daten. 

• Eine immer größere Anzahl von verschiedenartigen Lösungen und verschiedenartigen Datenbanken erforderte zugleich die Investitionen 

durch Datensharing beizubehalten. 

• Mit dem Trend zu autonomen Betriebseinheiten (‘lean management’, ‘profit center’) wurden ‘überintegrierte’ Informationssysteme 

aufgesplittet und eine Dezentralisierung der Datenverarbeitung angestrebt.

CAU zu Kiel, IfI, ISE, β 8. Verteilung ab SS 2011/12 714 

Diese Forderungen konnten zunehmend durch die Hardware (und die Software) befriedigt werden. LAN’s wurden auch aufgrund steigender 

Kosten bei Mainframe-Lösungen immer populärer. 

Damit wurden mit einer Verbesserung der Produktionsorganisation und dem Trend zur ‘schlanken Produktion’ auch eine schnelle Reaktion, 

intelligente Operationen Datenbanksystemanforderungen wie schneller ad-hoc-Zugriff und verteilter Zugriff bzw. verteilte Speicherung neu 

aufgewertet. Verteilte Datenbanksysteme haben gegenüber zentralisierten Datenbanksystemen die Vorteile einer höheren Performanz (insbesondere 

bei entsprechenden Entfernungen und einer Vielzahl von Benutzern), geringerer Kosten (insbesondere für die Pflege) und einer 

höheren Zuverlässigkeit und Verfügbarkeit (insbesondere bei partiellen Systemfehlern). Damit können zugleich Daten entsprechend Anforderungsprofilen 

an verschiedenen Stellen abgelegt werden, auf Daten schneller zugegriffen werden, Daten schneller verarbeitet werden, Erweiterungen 

(insbesondere von weiteren Teilnehmern) einfacher vorgenommen werden, die Kommunikation verbessert, geringere CPU-Kosten, 

benutzerfreundliche und spezialisierte Schnittstellen erzeugt werden, die Anwendungen gegenüber von Ausfällen eines Knotens besser abgesichert 

werden und die Prozessoren voneinander unabhängig operieren. Diesen Vorteilen stehen allerdings Nachteile wie komplexere Verwaltung 

und Steuerung, schwierigeres Sicherheitsmanagement und das Fehlen von Standards gegenüber. 

Eine verteilte Datenbank ist eine inhaltlich zusammenhängende Datenbank, die auf mehreren physisch unabhängigen Knoten (Rechner, 

Speichermedien) verteilt wird. Die auf den Knoten abgelegten Partitionen der Datenbank können dabei auch nicht separiert voneinander sein 

(Datensharing). Ein verteiltes System ist gekennzeichnet durch 

• eine Anwendungsschnittstelle für verschiedene Endbenutzer, 

• eine Validierungsfunktion zur Analyse der Datenanforderungen, 

• eine Transformationskomponente zur Berechnung der Anforderungen an die Komponenten, 

• eine Anfrageoptimierung, die die Verteilung berücksichtigt, 

• ein Input/Output-Interface für die Daten, 

• eine Formatierungsfunktion zur Anpassung der generierten Daten an die Benutzeranforderungen, 

• ein Sicherheitsmanagement, um Datensicherheit zu gewährleisten, 

• Backup- und Wiederanlauffunktionen, 

• eine Datenbankadministration, 

• eine Steuerung für den konkurrierenden Zugriff über das Netz und 

• eine Transaktionsverwaltung. 

Damit besteht ein verteiltes DBMS aus Rechnern, die Knoten zugeordnet sind, einem Kommunikationsnetzwerk zur Verbindung der Knoten, 

aus einem Netzwerk-Hard- und Software, aus Transaktionsprozessoren (TP) und aus Datenprozessoren (DP). 

TP 

DP 

Lokales DBMS 

✛ 

✲ Kommunikationsnetzwerk 

✛ 

✲ 

TP 

DP 

Lokales DBMS 

Abbildung 1: Grundsätzliche Architektur verteilter DBMS 

Die verteilte Datenbank präsentiert sich gegenüber den Endbenutzern bzw. Anwendungsprogrammen wie eine zentrale Datenbank. Dieses 

Ziel erfordert das Verstecken aller ‘störenden’ Aspekte. Die Lösung besteht in der Realisierung eines (‘integrierenden’ und ‘homogenisierenden’) 

globalen Schemas. Deshalb sind die Verteilung der Daten, inklusive der Kopienhaltung (d. h. der Partitionierung 1 und Allokation), ebenso 

wie die strukturellen und semantischen Heterogenitäten (mittels Schematransformation bzw. -integration) zu verstecken. Aus Performanz- und 

Sicherheitsgründen werden dabei dieselben Daten an verschiedenen Knoten redundant gespeichert (redundante Allokation). Informationen des 

gleichen Typs werden ggf. an verschiedenen Knoten verschieden dargestellt, z. B. anders strukturiert (strukturelle Heterogenität) bzw. mit 

anderen Bedeutungsinhalten (semantische Heterogenität). Eine andere Lösung ist die Partitionierung globaler Relationen, indem logisch an 

sich zusammengehörende Daten in homogener Form an verschiedenen Knoten gespeichert werden. 

Mit dieser Funktionalität kann ein verteiltes DBMS 

• eine Anfrage entgegennehmen, 

• diese analysieren, prüfen und zerlegen, 

• diese Teile den einzelnen Komponenten zuordnen, 

• auf verschiedene I/O-Operationen zurückführen, 

• die entsprechenden Daten suchen, lokalisieren, lesen und validieren, 

• auf dieser Grundlage die Konsistenz, Sicherheit und Integrität prüfen, 

• die Daten entsprechend der ursprünglichen Dekomposition validieren und 

1 Wir verwenden hier den Begriff ‘Partition’. In der Literatur wird neben dem Begriff ‘Partition’ der Begriff ‘Fragment’ benutzt. Da wir 

jedoch auf eine disjunkte Überdeckung des Datenbankinhaltes orientieren, ist das Wort ‘Partition’ eher geeignet.


• am Ende die gewonnenen Daten entsprechend der Anfrage dem Benutzer zur Verfügung zu stellen. 

Diese Aktivitäten sind aber für dem Benutzer nicht sichtbar. Wir unterscheiden dabei verschiedene Arten von Sichtbarkeit. 

Je nach Verteilung der einzelnen Komponenten unterscheiden wir 

Einfachknoten-Berechnung und Einfachknoten-Datenhaltung, 

Einfachknoten-Berechnung und Mehrfachknoten-Datenhaltung, 

Mehrfachknoten-Berechnung und Einfachknoten-Datenhaltung und 

Mehrfachknoten-Berechnung und Mehrfachknoten-Datenhaltung. 

Die Mehrfachknoten-Berechnung und Einfachknoten-Datenhaltung entspricht im Wesentlichen der Client/Server-Architektur der Workstationbasierten 

DBMS. 

Wir können auf verschiedene Rechner bei Vorhandensein eines Netzes verschiedene Ressourcen verteilen: 

Daten: Daten können auf verschiedenen Rechnern abgelegt und auf Anfrage bzw. Abforderung anderen Rechnern zugänglich gemacht werden. 

Prozesse: Prozesse können auf verschiedenen Rechnern ausgeführt und über ein Netz zusammengeführt werden. 

Steuerung: Die Bearbeitung kann durch verteilte Steuerung der einzelnen Prozesse und des Datenaustausches erleichtert werden. 

Dabei kann die Organisation der Verteilung unterschieden werden nach Prozeßcharakteristika und Prozeßwissen: 

Umfang des Sharing: In verteilten Datenbanken kann sowohl kein Sharing an Informationen stattfinden als auch Sharing in verschiedenen 

Stufen. Je größer der Sharing-Anteil, umso kritischer wird die Pflege und umso besser wird die Zugriffszeit auf Fremddaten. 

Verhalten von Zugriffsmustern: Die Zugriffsmuster über das Netz können statisch oder auch dynamisch sein. Statische Zugriffsmuster, die 

sich nicht verändern, sind relativ selten. Dynamische Zugriffsmuster bedingen dagegen einen ständigen Anpassungsprozeß. 

Umfang des Wissens über den verteilten Zugriff: Die Information über das Zugriffsverhalten kann vollständig, wird jedoch meist nur 

partiell sein. Je weniger Wissen vorhanden ist, umso schlechter kann die verteilte Datenbank an die Anforderungen angepaßt werden. 

Grundsätzlich sollen in einer verteilten Datenbank die Benutzer nicht mit der Verteilung direkt konfrontiert sein. Die Verteilung wird 

deshalb unsichtbar bleiben: 

Nichtsichtbarkeit der Verteilung: Die Benutzer wissen nicht, welche Daten auf welche Knoten verteilt wurden. 

Wir unterscheiden dabei verschiedene Niveaus von Nichtsichtbarkeit: 

Nichtsichtbarkeit der Partitionierung : Der Benutzer kennt weder die Partitionierung noch die Knoten, sondern kann das System 

benutzen wie eine zentralisierte Datenbank. 

Nichtsichtbarkeit der Lokalisierung bei sichtbarer Partitionierung : Der Benutzer muß die Partition angeben, nicht aber die Lokalisierung. 

Sichtbarkeit der Lokalisierung und Partitionierung : Der Benutzer muß sowohl die Lokalisierung als auch die Partitionierung angeben. 

Nichtsichtbarkeit der Transaktionen: Die Benutzer kennen die Verteilung von Transaktionen nicht. 

Durch remote-Anforderungen können Daten auch von anderen Knoten, z.T. auch unabhängig und parallel, geholt werden. Es wird durch 

einige Systeme auch eine verteilte Steuerung ermöglicht. Mit einem Zweiphasen-Commit-Protokoll wird der Abschluß der Transaktion 

auch über verschiedene Knoten kontrolliert. 

Nichtsichtbarkeit des Ausfalls einzelner Komponenten: Solange ein Ausfall nicht das Funktionieren beeinflußt, erfahren die Benutzer 

nichts vom Ausfall einzelner Komponenten. 

Nichtsichtbarkeit des Funktionierens: Das System hat nach außen das gleiche Verhalten wie ein zentralisiertes System. 

Nichtsichtbarkeit der Heterogenität: Das System ist in der Lage, die verschiedenen heterogenen Bestandteile dem Benutzer wie ein einheitliches, 

auf einem globalen konzeptionellen Schema beruhendes System erscheinen zu lassen. 

8.1.1 Verteilungskonzepte 

Mit einer Partitionierung sind Einschränkungen der Performanz verbunden. 

Daten können auf verschiedene Art partitioniert werden wie in Bild 44: 

Horizontale Partitionierung: Daten werden horizontal zerlegt (d. h. eine Tabelle oder Relation wird tupelweise zerlegt in verschiedene Teilrelationen) 

und verschiedenen Medien zugeordnet. In Bild 44 wird die Relation R durch Anwendung von Selektionsoperationen in drei 

Teilrelationen zerlegt, wobei gefordert wird, daß sich die Relation R aus den Teilrelationen wiederherstellen läßt durch Vereinigung 

dieser Teilrelationen. Damit müssen die Bedingungen α, β und γ als Disjunktion den Wahrheitswert true ergeben. Neben Selektionsoperationen 

können auch andere Operationen der relationalen Algebra verwendet werden. Es wird jedoch im Kontext verteilter DBS 

exklusiv die Selektion verwendet.


Vertikale Partitionierung: Daten werden vertikal zerlegt (d. h. eine Relation oder Tabelle wird attributweise dekomponiert) und auf verschiedene 

Medien verteilt. In Bild 44 wurde die Relation R durch Projektion in zwei Teilrelationen zerlegt. Der natürliche Verbund dieser 

beiden Teilrelationen muß wiederum die ursprüngliche relation R ergeben. 

Gemischte Partitionierung: Daten werden sowohl horizontal als auch vertikal zerlegt und auf verschiedene Knoten aufgeteilt. Es werden 

schrittweise zur Partitionierung Selektion und Projektion angewandt. 

A 1 A 2 A 3 A 4 

A 1 A 2 A 3 A 4 

Relation R 2 

A 1 A 2 A 3 A 4 

= σ β (R) 

Relation R 1 

= σ α (R) 

Relation R 3 

= σ γ (R) 

horizontale Partitionierung 

⇑ ↓ 

(Dekompostion durch Selektion) 

A 1 A 2 A 3 A 4 

Rekonstruktion 

R := R 1 ∪ R 2 ∪ R 3 

Relation R 

vertikale Partionierung 

(Dekomposition durch Projektion) 

⇓ 

↑ 


R := R[{A 1 , A 2 , A 3 }] ✶ R[{A 1 , A 4 }] 

A 1 A 2 A 3 

A 1 A 4 

Relation 

R[{A 1 , A 2 , A 3 }] 

Relation 

R[{A 1 , A 4 }] 

Abbildung 2: Partitionierungskonzepte 

Die Partitionierungstiefe kann bei einer Partitionierung von keine Partitionierung bis zu einer Partitionierung auf Attribut- bzw. Objektniveau 

reichen. 

Für die Partitionierung sind einige Korrektheitsregeln in verschiedenen Abstufungen einzuhalten: 

Vollständigkeit: In Analogie zur Eigenschaft der verlustlosen Dekomposition bei der Normalisierung können Klassen in mehrere Teilklassen 

oder anhand von Teilstrukturen in Partitionen zerlegt werden. Eine Eigenschaft eines Objektes kann dabei einmalig oder mehrmalig 

repräsentiert sein. 

Rekonstruierbarkeit: 

Je nach Zerlegung bzw. Partitionierung existiert eine Funktion ∇ zur Wiederherstellung der ursprünglichen Klassen. 

Disjunktheit: Die Partitionen sind entweder disjunkt oder es existiert ein Algorithmus, mit dessen Hilfe gleiche Eigenschaften eines Objektes 

in verschiedenen Partitionen gepflegt werden können. Meist kann ein solcher Algorithmus über Identifikationsmechanismen definiert 

werden. 

Sobald eine Datenbank partitioniert ist, muß eine Allokation der verschiedenen Partitionen zu den Knoten des Netzes erfolgen. Die 

Partitionierung und Allokation werden ebenso wie im Falle zentraler DBS in einem Datenbank-Katalog (data dictionary (DD)) verwaltet. Ein 

zugeordnetes Datum kann dabei repliziert oder einmalig einem Knoten zugeordnet sein. Es können Prozesse für Daten in zwei Extremen 

unterstützt werden:


Read-only-Zugriff für Replikate: Die Zuverlässigkeit und Effizienz (insbesondere für parallele Zugriffe) ist bei Read-only-Zugriffen auf 

Replikaten höher. Zugleich entsteht aber ein update-Problem. 

Read-and-write-Rechte für Replikate: Die Zuverlässgkeit und unter gewissen Umständen die Effizienz sinken. Ein update wird analog zu 

Triggermechanismen vorgenommen. 

Je nach Umfang der Replikation können verschiedene Probleme entstehen. Damit ist für jede Anwendung abzuwägen, inwieweit eine 

Replikationsstrategie günstig ist. 

Art der Replikation: volle teilweise keine 

Anfrageberechnung 

einfach 

gleiche Komplexit .ȧt 

←→ 

gleiche Komplexit .ȧt 

←→ 

DD-Verwaltung einfach oder 

nicht existent 

Steuerung der mittel hoch einfach 

Parallelität 

Zuverlässigkeit sehr hoch hoch niedrig 

Realistisches mögliche realistische mögliche 

Anwendungsszenario Anwendung Anwendung Anwendung 

Komplexität der Operationen bzw. Eigenschaften der Operationen 

Die Analogie zu Diensteplattformen ergibt hier einen der versprechenden Implementationsansätze. 

Common Facilities 

Object Request Broker 

Object Services 

Betriebssystem, Transportdienste 

Abbildung 3: CORBA auf IDL Grundlage 

Durch die Object Management Group (OMG) wurde die in Bild 3 und Bild 4 dargestellte Object Management Architecture (OMA) 

verabschiedet. Sie gestattet eine höhere Interoperabilität durch standardisierte Zugriffsschnittstellen. Die Schnittstellenbeschreibung erfolgt 

durch IDL (Interface Definition Language). Der Object Request Broker ist der Vermittler in der Client-/Server-Kooperation zwischen Objekten. 

Ein Aufruf besteht aus dem Tripel (Operationsname, Zielobjekt, Parameter). Damit wird eine Ortstransparenz realisiert. Die Objektdienste 

(Object Services) realisieren Basisfunktionen für die Erzeugung und Verwaltung von Klassen und Objekten, zur Namensverwaltung und für 

die Persistenz von Datenbank-Objekten. Mit den Common Facilities werden allgemeine Hilfsfunktionen (Klassenbibliotheken) zur Verfügung 

gestellt. 

Anwendungsobjekte 

Common 

Facilities 


Objektdienste 

Abbildung 4: OMG - Architektur 

In der Realisierung von OMA in der Common Object Request Broker Architecture (CORBA) in Bild 5 sind statische und dynamische 

Methodenaktivierungen (Aufrufschnittstellen) realisiert. Die ORB-Schnittstelle ermöglicht einen Zugriff auf Infrastrukturfunktionen, z. B. 

für die Verwaltung globaler OIDs und die Registrierung von Objekten. Die Kommunikation zwischen ORBs wird über das IIOP (Internet 

Inter-ORB-Protokoll) realisiert.


Client 

Objekt Implementation 

IDL 

Stubs 

❄ ❯ ✠ ❄ ❘ 

ORB 

Schnittstellen 

IDL 

Skelett 

ORB Kern 

Object 

Adapter 

Interface 

Repository 


Repository 

Abbildung 5: CORBA - Architektur 

8.1.2 Architektur verteilter Datenbanksysteme 

In konventionell realisierten verteilten Datenbanksystemen wird die Verteilung in den Anwendungen selbst realisiert. Die Anwendungsprogramme 

können miteinander kommunizieren. Dadurch werden an den Entwurf der Schnittstellen dieser Programme hohe Anforderungen 

gestellt. In verteilten Datenbanksystemen wird die Verteilung über das verteilte Datenbankmanagementsystem übernommen. Die Verteilung 

der Daten ist für das einzelne Anwendungsprogramm nicht mehr sichtbar. 

Allen verteilten Datenbanksystemen ist die Verteilung der Daten auf verschiedene Knoten und die lokale Verarbeitung von Anfragen 

durch die lokalen Komponenten gemeinsam. Mitunter werden auch verteilte Dateisysteme als verteilte Datenbanksysteme bezeichnet. Obwohl 

Dateisysteme als Datenbanksysteme der ersten Generation aufgefaßt werden können, haben sie wenig gemeinsam mit Datenbanksystemen. 

Die Funktionalität von verteilten Datenbanksystemen kann nach der folgenden Tabelle unterschieden werden: 

Merkmale verteilter Homogene Interope- Föde- Offene 

Datenbanksysteme eng integr. rable rierte Multi-DB 

Physische Verteilung der Daten + + + + 

Logische Sicht als eine Datenbank + +/- +/- - 

Nichtsichtbarkeit der Verteilung + - +/- - 

Gemischter DB-Zugang (glob./lok.) - - + - 

Zerlegung glob. Anfragen durch DBMS + - + - 

Lokale Ausführung von Teilanfragen + + + + 

Globales Transaktionskonzept + - + - 

Lokale Autonomie wird erhalten - + - + 

Homogene, eng integrierte verteilte Datenbanksysteme 

Das verteilte System ist von außen als ein homogenes System sichtbar. Es besitzt ein integriertes Schema. Die lokalen Systeme sind nicht 

autonom. Das Transaktionskonzept ist global. 

Damit werden Leistungsanforderungen wie im Falle zentraler Datenbanksysteme anwendbar. Daraus resultiert auch die Anwendungsbreite: 

• Hochleistungsdatenbanksysteme durch Nutzung der Parallelverarbeitung; 

• Fehlertolerante Datenbanksysteme durch Nutzung der kontrollierten Redundanz; 

• Dezentralisierte Datenbanksysteme zur Reduktion des Kommunikationsaufkommens und der Abhängigkeit vom Netz. 

Mehrrechnerdatenbanksysteme sind eine typische Realisierungsform von homogenen integrierten Datenbanksystemen. Es sind im Wesentlichen 

drei Realisierungsvarianten entwickelt worden: 

• In der Shared-Everything-Architektur sind sowohl Systempuffer als auch Sperrtabelle global. 

• In der Shared-Disk-Architektur wird wie in der vorhergehenden Variante die Platten-Peripherie über eine Variante von Bussystemen 

gemeinsam genutzt. Die einzelnen Anfragen werden lokal durch eigene Rechner mit eigenem Hauptspeicher verarbeitet. 

• In der Shared-Nothing-Architektur wird ein vollständig verteiltes System aufgebaut, dessen einzelne Systeme durch schnelle Kommunikationverbindungen 

miteinander verbunden sind. 

Architektur föderativer Datenbanken 

Föderative Datenbanken folgen dem Besitzer/Benutzer-Prinzip, wobei zusätzlich noch einem Benutzer Leserechte durch den Besitzer verweigert 

werden können. Sie wirken aufgrund einer Spezifikation der Kooperation zusammen. Bei Kopplungen muß auch die lokale Effizienz


gewahrt bleiben. Wir unterscheiden dabei 

• singuläre Föderationen, bei denen die lokalen DBMS heterogen sein können, die jedoch auf einem globalen Schema basieren und 

dieses für die Berechnungen benutzen, und 

• multiple Föderationen, bei denen die einzelnen Systeme auch eigene, anderen nicht zugänglich gemachte Daten besitzen, die nicht 

mehr auf einem globalen Schema beruhen und die über Exportschemata miteinander zusammenarbeiten. 

Eine Weiterentwicklung von multiplen Föderationen sind sprachlich gekoppelte Multi-DBMS. Dazu wird jedoch erst geforscht, so daß hier für 

den Entwurf nur föderative DBMS betrachtet werden. 

Der Entwurf einer föderativen Datenbank kann dabei von folgender Referenzarchitektur ausgehen: 

Lokale Schemata sind die Schemata der einzelnen Netzknoten. 

Komponentenschemata sind die lokalen Schemata in einer für die Koordinierung aufbereiteten Form. Das Datenbankmodell kann verschieden 

vom Datenbankmodell des lokalen Schemas sein. 

Exportschemata beschreiben die netzweit zugänglichen Daten, die den Teilnehmern einer Föderation zugänglich gemacht werden müssen. 

Föderative Schemata fassen die Exportschemata analog zur Sichtenintegration wie oben beschrieben zu einem allgemeinen Schema zusammen. 

Weiterhin werden Ansätze zur Auflösung von Modellierungskonflikten, statische Daten zur Optimierung, zur Verteilung 

(Partitionierung, Replikation etc.) erfaßt. 

Transformationsprozessoren erlauben eine Abbildung der lokalen Schemata auf die Komponentenschemata. 

Filterprozessoren filtern aus den Komponentenschemata die Daten für die Exportschemata heraus. 

Konstruktionsprozessoren dienen zur Einbindung der Exportschemata in die oder das föderative Schema. 

✻ 

Exportschema 

❄ 

Filterprozessor 

✻ 

Interface zum föderativen Schema 

❄ 

Konstruktionsprozessor 

✻ 

Komponentenschema 

❄ 

Transformationsprozessor 

✻ 

Lokales DB-Schema 

❄ 

Lokales 

DBMS 

Abbildung 6: Die Architektur von föderativen Datenbanksystemen 

Der nächste Schritt sind interoperable föderative Informationssysteme. Deren Dienste können wie in Bild 46 dargestellt werden. 

Diese Entwicklungslinie läßt sich für interoperable, föderative Systeme fortsetzen. 

Verteilung \ DBMS Zentrale Verteilte Interoperable Föderative 

Datenbankmodell A A B B 

Plattform A A A B 

Replikation/Partitionierung A B B B 

Insgesamt ergibt sich damit die folgende in Bild 47 dargestellte Architektur.


Anwendungs-Service 

Abstrakter Service 

Konkreter Service 

System Service 

Abbildung 7: Eine Schichten-Architektur für interoperable Umgebungen 

Lokaler Benutzer A 

Lokaler Benutzer B 

Benutzer- 

Interface 

System A 

Globaler Benutzer 

System B 

Benutzer- 

Interface 

Lokale 

Anwendungen 

Lokales 

DBMS 

Föderationssystem 

Benutzer- 

Interface 

Globales 

Kommunikationsund 

Verknüpfungs- 

System 


Lokale 

Anwendungen 

Lokales 

DBMS 

Abbildung 8: Interoperable föderierende Informationssysteme


Offene Multidatenbanksysteme 

In einem offenen, sehr losen Verbund werden offene Multidatenbankensysteme realisiert. Typische Anwendungsbeispiele sind autonome Systeme, 

die ihre Funktionalität ‘befreundeten’ Systemen öffnen wie z. B. Reservierungssysteme, Recherchedatenbanken und Informationsdienste. 

Die Integration findet nur in den anwendungsnahen Schichten statt und kann von lokaler Komponente zu lokaler Komponente variieren. Damit 

wird ein hoher Grad an Autonomie erreicht. Zugleich sind diese Systeme eher für den lesenden Zugriff geeignet. Eine globale Transaktionskomponente 

kann nicht existieren. Die Modifikation der Daten wird dann nicht wie mit einem Two-Phase-Commit unterstützt, sondern durch 

entsprechende Kompensationsoperationen vorgenommen. Eine Transaktion wird z. B. in einem Buchungssystem durch eine Stornierungsbuchung 

aufgehoben. Ein Rollback existiert nur lokal. 

Übungsaufgaben. 

Die folgenden Übungsaufgaben dienen der Kontrolle des allgemeinen Verständnisses. Es sollen noch einmal kurz Verteilungskonzepte, grundlegende 

Architekturen und die grundlegenden Definitionen geprüft werden. 

1. Anwendungsszenarien. Entwickeln Sie realistische Anwendungsszenarien, in denen eine Berechnung bzw. eine Datenhaltung auf jeweils 

Einfach- bzw. Mehrfachknoten eine sinnvolle Lösung ist! 

2. Zugriffsmuster. Entwickeln Sie für eine Anwendung Zugriffsmuster, die eine verteilte Datenhaltung günstig erscheinen lassen bzw. sehr 

aufwendig werden lassen. 

3. Abgrenzung zu verteilten Dateisystemen. Ein verteiltes Dateisystem suggeriert der benutzenden Anwendung, daß alle Dateien lokal 

verfügbar sind. Skizzieren Sie die Funktionsaufrufe, die notwendig sind, wenn eine Anwendung auf einen Datenblock über einen 

Knoten A zugreift, der zu einer Datei gehört, die jedoch auf einem Knoten B gespeichert ist! Ist damit eine lokale Anfragebearbeitung 

möglich? 

8.1.3 Mehrrechner-Datenbanksysteme 

In diesem Kapitel werden Mehrrechner-Datenbanksysteme eingeführt. Es werden Anforderungen vorgestellt, die zur Entwicklung von Mehrrechnersystemen 

führten. Im Überblick behandeln wir darauf aufbauende Architekturen. Diese Systeme werden in der Praxis breit angewandt. 

Sie erlauben eine einfachere Verwaltung als verteilte DBS, sind jedoch redundanter und kostenintensiver. 

Die in diesem Kapitel behandelten Konzepte werden vertiefend in [?, Rah94, ?] behandelt, sowie in der Vielzahl von Zeitschriften- und 

Konferenzveröffentlichungen (genannt seien dazu Konferenzserien wie ACM SIGMOD, ADBIS, BTW, DEXA, ER, FOIKS, ICDT, VLDB). 

Wir unterscheiden zwischen verteilten und parallelen Systemen. 

Ein verteiltes System besteht aus autonomen Subsystemen, die oft (weit) entfernt voneinander angeordnet sind, aber koordiniert zusammenarbeiten, 

um eine gemeinsame Aufgabe zu erfüllen. Das für verteilte Systeme charakteristische Kernproblem ist der Mangel an 

globalem (zentralisiertem) Wissen. 

Ein paralleles System besteht aus einer Vielzahl gleichartiger Subsysteme (Komponenten), die lokal zueinander angeordnet sind und nur 

einen geringen Grad an Autonomie aufweisen. Charakteristisch ist eine enge und hochgradig parallele Bearbeitung eines Benutzerauftrags. 

Anforderungen an Mehrrechner-Datenbanksysteme. 

Mehrrechner-Datenbanksysteme bedingen den Einsatz mehrerer Rechner bzw. DBMS zur koordinierten Verarbeitung von Datenbankoperationen. 

Anforderungen an solche Systeme sind: 

• Hohe Leistung: hohe Transaktionsraten bei kurzen Antwortzeiten 

• Hohe Verfügbarkeit/Fehlertransparenz 

• Modulare Erweiterungsfähigkeit 

• Verteiltransparenz für DB-Benutzer (für Anwendungsprogramme bzw. Endbenutzer) 

• Koordinierter Zugriff auf heterogene Datenbanken 

• Unterstützung geographisch verteilter Datenbanken (Wahrung einer hohen Knotenautonomie) 

• Hohe Kosteneffektivität 

• Einfache Handhabbarkeit/Administrierbarkeit. 

Typische Anwendungen verteilter Systeme entwickeln sich insbesondere im Internetkontext. Die in Bild 9 dargestellte Anwendung kann 

sowohl eine klassische Datenbankanwendung (wie z. B. eine Anwendung im Bankwesen oder im Versicherungsbereich) sein als auch eine 

Internetanwendung. Ein typisches Beispiel könnte z. B. ein Auskunftssystem ’Veranstaltungskalender Deutschland’ sein. Nur durch eine 

lokale Pflege und ggf. vor Ort kann die Konsistenz und die Aktualität der Daten gesichert werden. In diesem Fall wird eine Anfrage, die 

eine andere Site betrifft, an das lokale Anwendungssystem dieser Site übergeben. Dieses verarbeitet die Anfrage und stellt dem anfragenden 

System die Antwort zur Verfügung. Eine derartige Architektur erfordert jedoch eine abgestimmte Vorbereitung. In diesem Fall kooperieren 

die Anwendungssysteme. Es wird keine vollständige Integration angestrebt. In Bild 9 wird die Entwicklungslinie von zentralisierten Systemen 

hin zu verteilten und spezialisierten Systemen aufgezeigt, die gerade im Internetbereich die Zukunft bestimmen werden. Im Internetbereich 

bestimmen die obigen Anforderungen die Anwendungen. 

Verteilte DBMS können zu parallelen DBMS weiterentwickelt werden. Damit werden die Beschränkungen der sequentiellen Verarbeitung 

überwunden. Typische Leistungsmerkmale bei sequentieller Verarbeitung sind:


Zentralisiertes System 

Site A Site B Site C 

Kooperierende verteilte Anwendungen 

HTTP 

Server 

DBMS 

DB 

⇒ 

Site A Site B Site C 

✻ ✻ ✻ 

Netzwerk 

❄ ❄ ❄ 

Lok. Anw. Lok. Anw. Lok. Anw. 

✻ ✻ ✻ 

Netzwerk 

❄ ❄ ❄ 

Zentalisiertes 

Anwendungssystem 

Anwendungsserver 

Anw.- 

server 

DBMS 

DB 

✛✲ 

Anw.- 

server 

DBMS 

DB 

✛✲ 

Anw.- 

server 

DBMS 

DB 

Abbildung 9: Von zentralisierten Internet-Systemen zu verteilten 

• Zugriffsraten zur Platte mit 5 MB/s, 

• Suchen z. B. mittels Relationen-Scan mit einer Geschwindigkeit von 1 MB/s, 

• Sortieren mit einer Geschwindigkeit von 0.1 MB/s und 

• relativ langsamer Verbund. 

Größere Datenbanken können damit nicht mehr unterstützt werden. Durch den Einsatz von Parallelität innerhalb von Transaktionen (Intra- 

Transaktionsparallelität) können dagegen erreicht werden: 

• kurze Antwortzeiten für daten- und/oder berechnungsintensive DB-Anfragen 

• zeitgünstige Operationen auf großen Relationen z. B. Scan, Join-Berechnung, Sortierung, Indexgenerierung, 

• Volltextsuche in Literaturdatenbanken und 

• effiziente Multimedia-Anwendungen. 

Mit einer hohen InterTransaktionsparallelität werden hohe Transaktionsraten für OLTP und lineares Durchsatzwachstum erreicht. 

Parallele Datenbanksysteme sind ein spezieller Typ von Mehrrechner-DBS mit den Hauptzielen: hohe Leistung, Verfügbarkeit, Skalierbarkeit 

und Kosteneffektivität. Ihre Architektur kann wie in Bild 10 dargestellt werden durch: 

• Parallelrechner mit hoher Anzahl von Mikroprozessoren, 

• lokale Verteilung (Cluster), 

• skalierbares Hochgeschwindigkeitsnetzwerk und 

• I/O-Parallelität. 

Parallele Systeme genügen Anforderungen wie hohen Transaktionsraten mit einem Durchsatz von weit mehr als 1000 Transaktionen pro 

Sekunde (TPS) (vom Typ ’Kontenbuchung’), realisieren kurze Antwortzeiten trotz höheren Durchsatzes und Kommunikationsverzögerungen 

auf der Grundlage von Parallelisierung komplexer Anfragen und sind demzufolge von hoher Akzeptanz für den Dialogbetrieb. Sie genügen 

deshalb ständig steigenden Leistungsanforderungen durch wachsende Zahl von Benutzern/Terminals, Einführung neuer Anwendungen und 

neuer Transaktionstypen, durch ständiges Wachstum der Datenbanken, durch Bearbeitung komplexerer Vorgänge und Integritätsbedingungen, 

insbesondere auch bei Benutzung höherer Programmiersprachen und für komfortablere Benutzerschnittstellen. 

Beispiele für hohe Leistungsanforderungen sind Bankanwendungen und Reservierungssysteme, in denen Kontenbuchungen oder Platzreservierungen 

mit einem Durchsatz von mehreren 1000 TPS und einer Antwortzeit von weniger als 2 Sekunden (sec) bearbeitet werden 

sollen, Telefonvermittlungssysteme, die auf einem Benutzerprofil basieren und Abrechnungssätze generieren, wodurch in Zeiten hohen Verkehrsaufkommens 

mehr als 15.000 solcher Transaktionen pro Sekunde entstehen und deren Antwortzeiten kleiner als 0.2 sec sein sollten, 

ManagementInformationssysteme, in denen auf z. B. einer 500 GB großen Datenbank komplexe Ad-Hoc-Anfragen ablaufen, die mitunter 

einen vollständigen Scan der Datenbank erfordern, und Web-Server und E-Commerce-Anwendungen. 

Klassifikation von Mehrrechner-Datenbanksystemen. 

Mehrrechner-Datenbanksysteme können nach folgenden Parametern klassifiziert werden: Klassifikationsmerkmale:


PE PE PE PE PE 

DBS DBS DBS DBS DBS 


... ... 

... ... ... 

Hochgeschwindigkeitsnetz 


... ... 

... ... ... 


Prozessorfeld 


Paralles I/O-System 

Abbildung 10: Parallele Datenbanksysteme 

Rechnerkopplung (enge, lose oder nahe Kopplung) 

Räumliche Verteilung (ortsverteilt oder lokal) 

Externspeicheranbindung (gemeinsam (’shared’) oder partitioniert) 

Integrierte vs. föderative MehrrechnerDBS 

Homogene vs. heterogene DBS 

Funktionale Spezialisierung vs. funktionale Gleichstellung der Prozessoren. 

Die enge Rechnerkopplung (tightly coupled) in Bild 11 ist ein weit verbreiteter Ansatz. Sie ist gekennzeichnet durch folgende Eigenschaften: 

• gemeinsamer Hauptspeicher für alle Prozessoren; 

• jeweils eine Kopie von Software-Komponenten (Betriebssystem, Datenbanksystem, Anwendungssystem etc.); 

• jeder Prozessor besitzt einen Hardware-Cache. 

Vorteile dieser Architektur sind insbesondere: 

• einfache Realisierung, 

• wenig neue DB-Probleme, 

• effiziente Kommunikation über Hauptspeicher, 

• Lastbalancierung durch Betriebssystem und 

• Single System Image Verwaltung. 

Es ergeben sich jedoch die folgenden Nachteile: 

• mangelnde Fehlerisolation durch gemeinsam benutzte Speicher und Software; 

• begrenzte Erweiterbarkeit und Skalierbarkeit (N < 30, meist N < 10) und 

• Cache-Kohärenz. 

Die lose Rechnerkopplung (loosely coupled) in Bild 12 verwendet N autonome Rechner mit separatem Hauptspeicher pro Knoten und 

eigenen Software-Kopien. Die Kommunikation wird durch Nachrichtenaustausch realisiert. 

Vorteile dieser Architektur sind insbesondere: 

• höhere Fehlerisolation und Verfügbarkeit und 

• bessere Erweiterbarkeit. 

Sie besitzt jedoch auch Nachteile: 

• Der Nachrichtenaustausch ist aufwendig und führt zum Kommunikations-Overhead. 

• Es wird kein ‘single system image’ verwendet und damit die Redundanz vergrößert. 

Die nahe Rechnerkopplung (closely coupled) in Bild 13 ist ein Kompromiß zwischen enger und loser Kopplung mit dem Ziel einer 

effizienteren Kommunikation verglichen mit loser Kopplung unter Beibehaltung einer ausreichenden Fehlerisolation und Erweiterbarkeit. N 

autonome Rechnerknoten kommunizieren zum Teil über gemeinsame Halbleiter-Speicherbereiche. Voraussetzung dazu ist eine lokale Rechneranordnung. 

Der gemeinsame Speicher muß einen schnellen Zugriff im Mikrosekundenbereich zur Umgehung von Prozeßwechseln für einen synchronen 

Zugriff besitzen. Er hat i. Allg. keine Instruktionsadressierbarkeit, ist ggf. nicht flüchtig und führt Speicherinhalte ggf. doppelt. Eine weitere 

Einsatzform einer nahen Kopplung beruht auf der Verwendung von Spezialprozessoren, z. B. einer ’lock engine’ zur globalen Synchronisation. 

Bei der topologischen bzw. räumlichen Verteilung können verschiedene Zuordnungen angewandt werden:


Privater 

Cache 

Privater 

Cache 

Prozessor 

Prozessor 

Hauptspeicher 

Abbildung 11: Enge Kopplung von Rechnern 

Privater 

Cache 

Privater 

Cache 

Prozessor 

✛ 

✲ 

Prozessor 

Hauptspeicher 

Hauptspeicher 

Abbildung 12: Lose Kopplung von Rechnern 

Privater 

Cache 

Privater 

Cache 

Prozessor 

✛ 

✲ 

Prozessor 

Hauptspeicher 

Hauptspeicher 

■ 

❘ ✠ 

✒ 

Gemeinsamer 

Speicher 

Abbildung 13: Nahe Kopplung von Rechnern


lokale Zuordnung: Mit einer lokalen Verteilung ist eine schnelle Rechnerkopplung möglich. Komponenten wie Speicher und Hochgeschwindigkeitsbus 

werden ggf. gemeinsam benutzt. Der Nachrichtenaustausch ist effizienter und robuster als in Weitverkehrsnetzen. 

Es werden einfachere Kommunikationsprotokolle z. B. im Broadcast- bzw. Multicast-Verfahren verwendet. Damit kann eine effektive 

dynamische Lastverteilung erreicht werden. Sie ist eine bessere Voraussetzung für Intra-Transaktionsparallelität und erlaubt eine 

einfachere Administration. 

ortsverteilte Zuordnung: Damit werden dezentrale Organisationsstrukturen unterstützt. Sie ist Voraussetzung für schnelle Katastrophen- 

Recovery, da sich replizierte Datenbanken an entfernten Knoten befinden. 

Die Verteilung wird stark durch die Kommunikationskosten mitbestimmt. Die Kosten zum Senden und Empfangen einer Nachricht setzen 

sich aus den folgenden Komponenten zusammen: 

• CPU-Kosten für Kommunikationsprotokoll; 

• Signallaufzeiten für Übertragung des ersten Bits (i. Allg. angenommen: Lichtgeschwindigkeit); 

• Übertragungsdauer für die gesamte Nachricht aufgrund der vorhandenen Bandbreite des Kommunikationsmediums. 

Der Kommunikationsaufwand wird durch die technischen Möglichkeiten stark determiniert. Sie sind einer Veränderung unterworfen, die 

jedoch nicht mit den wachsenden Anforderungen des Internetzeitalters schritthalten, wie die folgende Tabelle zeigt: 

Shared Memory LAN WAN 

typische Entfernung < 10 m 1 km 10.000 km 

CPU-Kosten pro SEND/RECEIVE 250 Instr. 2500 Instr. 25.000 Instr. 

Signallaufzeit 0,1 µs 10 µs 100.000 µs 

Bandbreite 1990 1 Gbps 10 Mbps 50 Kbps 

Bandbreite 2000 1 Gbps 1 Gbps 100 Mbps 

Weiterhin unterscheiden sich verteilte Systeme durch ihre Externspeicheranbindung: 

gemeinsamer Externspeicher: Der Externspeicher wird gemeinsam in einer lokale Rechneranordnung genutzt. Damit bieten sich lose oder 

nahe Kopplung mit Shared-Disk bzw. Datenbank-Sharing an oder auch die enge Kopplung. 

Von Vorteil ist, daß jeder Prozessor alle Daten direkt erreichen und damit eine Lastbalancierung vornehmen kann. Es ist außerdem 

keine Partitionierung der Datenbank erforderlich. 

Nachteilig wirken sich neue Datenbank-Probleme z. B. bzgl. Synchronisation, Pufferverwaltung, Logging/Recovery aus. 

partitionierter (Shared-Nothing; DB-Distribution) Es kann eine lokale oder ortsverteilte Rechneranordnung verwendet werden. Im Allgemeinen 

bietet sich eine lose Rechnerkopplung an. Die (statische) Replikation der Daten ist möglich. Dieser Zugang ermöglicht eine 

verteilte Transaktionsausführung beim Zugriff auf entfernte Daten. 

Zusammenfassend kann man die verwendeten Zugänge wie in Bild 14 unterscheiden. 

Mehrrechnersysteme 

Rechnerkopplung 

Externspeicherzuordnung 

gemeinsam 

partitioniert 

Topologische 

Verteilung 

lokal lokal ortsverteilt 

eng nahe lose (nahe) lose lose 

Shared 

everything Shared disk Shared nothing 

Abbildung 14: Zugänge für Mehrrechnersysteme 

Parallele Datenbanksysteme können in analoger Art und Weise unterschieden werden in: 

Shared-everything-Architektur: Mit einem Hochgeschwindigkeitsnetzwerk sind sowohl die Prozessoren als auch die Speicher und die Datenbanken 

miteinander verbunden. Damit kann eine hohe Universalität durch symmetrisches Multiprocessing erreicht werden. Zugleich 

sind diese Systeme sehr komplex, schlecht erweiterbar und wenig robust. 

Shared-disk-Architektur: Durch ein Hochgeschwindigkeitsnetzwerk werden die Datenbanken und die Einzelrechner miteinander verbunden. 

Die Einzelrechner benutzen gemeinsam die Datenbanken, sind aber in ihrer Steuerung und Berechnung isoliert.


Shared-nothing-Architektur: Die Rechner verfügen über ihre lokalen Datenbanken, Prozessoren etc. Sie sind über ein Hochgeschwindigkeitsnetz 

miteinander verbunden. 

Die beiden letzten Architekturen haben eine Reihe von Vor- und Nachteilen: 

Kriterium Shared-nothing Shared-disk 

Leistungsfähigkeit 

- statische Datenpartitionierung be stimmt 

Ausführungsort von DB-Operationen 

- lokale Erreichbarkeit aller Daten wodurch 

größere Möglichkeiten zur Lastba- 

Erweiterbarkeit 

Verfügbarkeit 

Technische 

Probleme 

- geringe Möglichkeiten zur Lastbalancierung 

oder Einsparung von Kommunikationsvorgängen 

- besonders problematisch: ‘dominie rende’ 

Transaktionstypen und DB-Bereiche 

- neuer Rechner erfordert physische Neu 

aufteilung der Datenbank (N → N+1) 

- besonders problematisch für nichtrelationale 

DBS 

lancierung entstehen 

- Kommunikation für Synchronisation und 

Kohärenzkontrolle 

- nahe Kopplung kann zur Leistungssteigerung 

eingesetzt werden; trotzdem höhere 

Flexibilität zur Parallelisierung 

- keine physische (Neu-)Aufteilung der 

DB 

- direkte Plattenanbindung kann Rechneranzahl 

begrenzen (‘nachrichtenbasierte’ 

I/O-Schnittstelle) 

- gesamte DB bleibt nach Rechnerausfall 

erreichbar 

- komplexe Crash-Recovery 

- Partition eines ausgefallenen Rechners 

zunächst nicht mehr erreichbar 

- Übernahme/Recovery der betroffenen 

Partition durch anderen Rechner vorzusehen 

(ggf. Überlastungsgefahr) 

- ortsverteilte Replikation ermöglicht - Erstellung einer globalen Log-Datei 

schnelle Katastrophen-Recovery 

- Bestimmung der physischen DB- - Synchronisation 

Partitionierung 

- verteilte Anfrageverarbeitung - globale Deadlock-Behandlung 

- parallele Anfrageverarbeitung - Kohärenzkontrolle 

- Behandlung replizierter Datenbanken - Logging 

- verteiltes Commit-Protokoll - Recovery 

- globale Deadlock-Behandlung - Lastverteilung, -balancierung 

- Lastverteilung, -balancierung - parallele Anfrageverarbeitung 

- Administration - Administration 

- besondere Probleme in ortsverteilten Systemen 

(Netzwerkpartitionierungen, Knotenautonomie, 

...) 

Oft wird eine vollständige Integration von verteilten Systemen angestrebt. Da das Integrationsproblem algorithmisch unentscheidbar 

ist, kann kein Integrationsalgorithmus existieren. Integrierte Systeme haben ein gemeinsames konzeptionelles DB-Schema. Der DB-Zugriff 

erfolgt wie im zentralen Fall, womit auch Verteilungstransparenz gewährleistet ist. Damit besitzen die beteiligten DBMS eine eingeschränkte 

Autonomie. Die einfachste Verwirklichung geht von identischen DBS-Instanzen aus, wodurch ein homogenes verteiltes System entsteht. 

Beispiele solcher Systeme sind verteilte DBS und Shared-disk-DBS. 

Andererseits ist eine vollständige Integration auch nicht das Ziel. Meist ist eine Föderation oder eine Kooperation von Systemen ausreichend. 

Damit können auch weitgehend unabhängige DBMS mit privaten konzeptionellen DB-Schemata verwaltet werden. Es wird eine 

partielle Exportierung von Schemainformationen für externe Zugriffe modelliert. Eine Heterogenität ist sowohl bei Datenmodellen als auch 

bei der Transaktionsverwaltung möglich. Damit entstehen allerdings Probleme mit der semantischen Heterogenität. Eine Verteilungstransparenz 

ist i. Allg. nur bedingt erreichbar. 

Die Prozessorfunktionalität gestattet eine weitere Unterscheidung verteilter und Mehrrechner-DBS: 

Funktionale Gleichstellung: Jeder Knoten besitzt die gleiche Funktionalität bzgl. DB-Verarbeitung. I. Allg. werden vollständige DBMS in 

jedem Knoten verwendet. Die Funktionen werden repliziert. 

Funktionale Spezialisierung: Die Funktionen werden partitioniert, separiert oder auch spezialisiert. Typische Beispiele sind DB-Maschinen 

mit Spezialprozessoren für bestimmte DB-Funktionen z. B. für den Verbund, das Sortieren oder auch Kommunikationsfunktionen. 

Ein spezielles Beipiel sind Workstation/Server-DBS. Sie werden besonders bei Non-Standard-Anwendungen verwendet. Damit kann 

eine DB-gestützte Verarbeitung großer, komplex-strukturierter Datenmengen in der Workstation unterstützt werden, insbesondere bei 

hoher Rereferenz-Wahrscheinlichkeit bei den Daten und bei langen Transaktionen. 

Sowohl die Workstations als auch der Server verarbeiten Daten, besitzen eine Steuerfunktionalität und verarbeitende Funktionen. 

Durch den Workstation-Objektpuffer können Kommunikationsvorgänge eingespart werden. Anfragen und Methoden werden ggf. lokal 

ausgeführt. Auf dem Server werden globale Aufgaben ausgeführt: Logging, Synchronisation, Externspeicherverwaltung etc.


Die Spezialisierung erschwert Lastbalancierung, Erweiterbarkeit und Fehlertoleranz. Deshalb werden Mischformen aus horizontaler/vertikaler 

Verteilung verwendet. 

Zusammenfassend können wir die Eigenschaften von Mehrrechnersystemen wie folgt vergleichen: 

Parallele DBS Verteilte DBS Föderative 

DBS 

Workst./Server- 

DBS 

Hohe Transaktionsraten ++ ◦/+ ◦ ◦ 

IntraTAParallelität ++ ◦/+ -/ ◦ ◦/+ 

Erweiterbarkeit + ◦/+ ◦ ◦ 

Verfügbarkeit + + - ◦ 

Verteilungstransparenz ++ + ◦ ++ 

geographische Verteilung - + + ◦ 

Knotenautonomie - ◦ + - 

DBSHeterogenität - - + -/ ◦ 

Administration ◦ - -/– ◦ 


Die folgenden Übungsaufgaben sollen das Verständnis der obigen Ausführungen testen. Sie sind deshalb so angelegt, daß bereits eine kurze 

Antwort genügt. Die letzte Übungsaufgabe dient der Erweiterung des Horizonts. Sie ist optional. 

1. Katalogverwaltung. Welche Alternativen eignen sich zur Katalogverwaltung in lokal verteilten Shared-Nothing-Systemen, bei denen keine 

Knotenautonomie zu unterstützen ist? 

2. Namensauflösung in R ∗ . In R ∗ wurde folgende vierteilige Struktur globaler Objektnamen realisiert: 

[@].][@] . 

Damit kann sowohl eine global eindeutige Bezeichnung für Benutzer als auch für Objekte erzeugt werden. Bei der Namensauflösung 

werden nicht angegebene Knotennamen mit aktuellen Knoten ersetzt. 

Welche Vorteile ergeben sich durch die Hinzunahme von ? 

Eine Relation Thalheim@L.Adresse@F soll von verschiedenen Benutzern an verschiedenen Orten referenziert werden. Wie sieht der 

jeweils kürzeste Name aus, der (ohne Synonyme) korrekt zum vollständigen Namen expandiert werden kann 

◦ für den Benutzer Thalheim, 

◦ für sonstige Benutzer, 

◦ am Knoten L, am Knoten B und am Knoten F ? 

3. Veränderung der Knotentopologie. Ein Knoten eines verteilten DBS soll dauerhaft aus dem System genommen werden. Kann dies mit 

der obigen Struktur globaler Namen unterstützt werden? 

4. Synonyme. Welche Probleme ergeben sich bei der Verwendung von Synonymen zur Unterstützung von Verteilungstransparenz ? 

5∗. Nutzung standardisierter Dienste. Die Katalog- und Namensverwaltung in verteilten Systemen ist ein generelles Problem. Inwieweit 

könnten standardisierte Directory-Dienste wie z. B. X.500 zur Lokalisierung von Datenbank-Objekten genutzt werden? 

8.1.4 Verteilte Datenbanksysteme 

In diesem Abschnitt untersuchen wir Konzepte verteilter Datenbanksysteme und verteilter DBMS. Sie basieren auf einer Verteilung der Datenbanken 

an sich und verlangen deshalb eine Unterstützung bei der Pflege und Wartung. Sie sind demzufolge komplexer, haben allerdings 

aufgrund geringerer Redundanz den Vorteil einer schnelleren Anfrageverarbeitung. 

Die in diesem Kapitel behandelten Konzepte können vertiefend in den Literaturquellen [?, ?, Dad96, KE96, ?] nachgelesen werden, sowie 

in der Vielzahl von Zeitschriften- und Konferenzveröffentlichungen (genannt seien dazu Konferenzserien wie ACM SIGMOD, ADBIS, BTW, 

DEXA, ER, FOIKS, ICDT, VLDB). 

Die meisten kommerziellen DBS unterstützen eine Teilfunktionalität von verteilten DBS. Beispiele kommerzieller Systeme sind Tandem 

NonStop SQL, CA Ingres/Star; CA-DB:STAR, Oracle, Informix/Star, Sybase Replication Server, IBM DRDA (DB2, DB2/2, DB2/6000, 

SQL/DS, ...), Cincom Supra, Empress, UDS-D und Sesam-DCN. Frühe Prototypen sind z. B. die Systeme R* (IBM), SDD-1 (CCA), Distributed 

Ingres, VDN, POREL, DDM, DDTS, Sirius-Delta und Polypheme. 

Fundamentales Prinzip der verteilten DBS ist: 

Für den Benutzer sollen alle Aspekte der Verteilung verborgen bleiben (Verteilungstransparenz). 

C. J. Date stellte 12 ‘Regeln’ für verteilte DBS auf: 

1. Größtmögliche lokale Autonomie und lokale Verwaltung von lokalen Daten; 

2. Keine Abhängigkeit vom zentralen Knoten; 

3. Permanenter Betrieb; 

4. Ortsunabhängigkeit (Ortstransparenz), d. h. die physische Lokation von Daten muß verborgen bleiben und Datenumverteilungen dürfen 

keine Auswirkungen auf Programme haben; 

5. Partitionierungsunabhängigkeit;


6. Replikationsunabhängigkeit; 

7. Verteilte Anfrage-Bearbeitung, die für den Zugriff auf externe Daten und die Optimierung verteilter Anfragen erforderlich ist; 

8. Verteilte Transaktionsverwaltung, einschließlich Synchronisation, Recovery (verteiltes Commit-Protokoll); 

9. Hardware-Unabhängigkeit; 

10. Betriebssystemunabhängigkeit; 

11. Netzwerkunabhängigkeit; 

12. DBMS-Unabhängigkeit. 

Nicht jedes dieser Kriterien wird durch die kommerziellen Systeme befriedigt, z. B. ist das Kriterium 10 bei einigen Firmen im Interesse der 

Firmenpolitik nie unterstützt worden. Die meisten dieser Regeln führen direkt zu heterogenen DBMS. 

Heterogene Datenbanken. 

Heterogene Datenbanken verwalten inhaltlich verwandte Informationen einer Institution, eines Unternehmens, etc. Die Informationen sind 

in der Praxis häufig über mehrere heterogene Datenbanken verstreut, die unabhängig voneinander entworfen wurden und betrieben werden. 

Heterogenität tritt auf bezüglich: 

• Hardware (Rechner, Peripherie, Kommunikationssystem, ...), 

• Betriebssystemen (Windows, Linux, Unix, MS/DOS, MVS, VMS, BS2000 ...), 

• Kommunikationsprotokollen (SNA, TCP/IP, Transdata, OSI ...), 

• DBMS (Hersteller, Version), 

• Datenmodellen (relational, objekt-orientiert, CODASYL, hierarchisch), 

• Anfragesprache (SQL-Dialekt, DL/1, ...), 

• Transaktionsverwaltung (Synchronisation, Logging, Recovery) und 

• Repräsentation der Daten, die wieder zu einer größeren semantischen Heterogenität führt. 

Semantische Heterogenität ist oft durch Entwurfsautonomie verursacht. Eine mögliche Behandlung kann durch Schemaintegration analog zu 

Zugängen föderativer DBS erfolgen. Es sind in diesem 

Zusammenhang Namenskonflikte (Synonyme, Homonyme) zu lösen. Es werden unterschiedliche Namen für dieselben Attribute/Relationen 

verwendet bzw. die gleichen Bezeichner für unterschiedliche Attribute/Relationen. Damit muß eine Umbenennung erfolgen. Bei der Modellierung 

werden unterschiedliche Formate verwendet (unterschiedliche Datentypen, Genauigkeit, etc. ). Dies erfordert den Einsatz von Konversionsfunktionen. 

Es treten strukturelle Unterschiede z. B. bei der Repräsentation von Information durch Attribute bzw. eigene Relation(en), bei 

unterschiedlichen Beziehungstypen (1:N, M:N, ...), durch unterschiedliche Integritätsbedingungen (Eindeutigkeit, referentielle Integrität, Nullwertbehandlung, 

Defaultwerte, Wertebereiche, etc.) auf. Außerdem können Daten fehlen oder widersprüchlich sein, z. B. durch Eingabefehler 

und unterschiedlichen Änderungsstand. Das folgende Beispiel zeigt diese Konflikte bereits auf: 

Datenbank 1 (UNIBIB): 

PUBLIKATION (Pubnr, Titel, Typcode) 

BUCHPUB (Pubnr, Verlag, Ejahr, #Exemplare, ISBN) 

VERFASSER (Pubnr, Vname) 

SCHLAGWORT (Pubnr, Sname) 

Datenbank 2 (STADTBIB): 

BUCH (ISBN, Titel, Autoren, Vnr, Jahr, Preis, Standort) 

VERLAG (Vnr, Vname, Adresse) 

Für heterogene Datenbanken ergeben sich die folgenden Anforderungen: 

• Zugriff auf mehrere Datenbanken innerhalb einer Transaktion bei Wahrung der ACID-Eigenschaften; 

• Einheitliche Zugriffsschnittstelle trotz Heterogenität bei den beteiligten DBS; 

• Wahrung einer hohen Unabhängigkeit der einzelnen DBS (Knotenautonomie); 

• Mächtige Zugriffsschnittstelle (In einer DBMS-Operation sollten Daten aus verschiedenen Datenbanken verknüpft werden können 

durch Verbund-Bildung, etc.) und 

• Möglichst hohe Verteilungstransparenz. 

Verschärfend wirkt sich dabei die Knotenautonomie aus: 

• Es wird oft von einer Entwurfsautonomie ausgegangen (logischer DB-Entwurf, physischer DB-Entwurf, Wahl des lokalen DBS). 

• Abstrahierend wird in Programmen von der Ausführungsautonomie ausgegangen. 

• Mit einer Kooperationsautonomie wird dem lokalen System die Verantwortung für die Kooperation übertragen. 

• Hauptursache für Heterogenität ist jedoch die Entwurfsautonomie.


Aufruf von 

Transaktionsprogrammen Ad-Hoc-Anfragen 

❄ 

TP- 

Monitor 

Anwendungsprogramme 

Server 

DC-System 

❄ 

DBMS 

❄ 

Datenbanken 

Abbildung 15: Grobaufbau eines zentralisierten DBMS 

Alternativen zur Bearbeitung heterogener Datenbanken/Datenquellen sind die Vorabintegration der Datenquellen durch Verlagern in separate 

Datenbanken wie z. B. im Data-Warehouse-Ansatz und die Beibehaltung selbständiger Datenbanken bei Bereitstellung gemeinsamer Zugriffsmöglichkeiten. 

Zentralisierte Transaktionssysteme erlauben eine Aktivierung durch Ad-Hoc-Queries. Sie besitzen außerdem, wie in Bild 15 dargestellt, 

ein Datenkommunikationssystem (DC), das den Aufruf von Transaktionsprogrammen gestattet. Verteilte Systeme wie in Bild 9 erlauben eine 

Verteilung unter Kontrolle des Datenkommunikationssystemes bzw. der Transaktionsverarbeitungsmonitore (TP-Monitor). Diese Teilsysteme 

verbergen weitgehend die Heterogenität bezüglich Kommunikationsprotokollen, Netzwerken, Betriebssystem und Hardware. Die Datenbanksysteme 

können dabei entweder homogenisiert werden oder auch autonom bleiben. Eine Homogenisierung bedingt auch eine Schemaintegration 

der Einzelsysteme. Da die Schemaintegration algorithmisch nicht entscheidbar ist, kann eine Homogenisierung nur in Ausnahmefällen 

angestrebt werden. 

Heterogene Datenbanken kann man mit einem Ansatz der kontrollierten Autonomie zusammenführen. Wir können für heterogene Datenbanken 

folgende Ansätze unterscheiden: 

A) Homogener und integrierter Ansatz: Durch Verteilung einer logischen Datenbank unter mehrere Rechnern wird eine enge Kooperation 

zwischen DBS zur Gewährleistung von voller Verteilungstransparenz erforderlich. Demzufolge ist dieser Ansatz - obwohl mitunter 

praktiziert - ungeeignet zur Unterstützung heterogener Datenbanken. Ein homogener und integrierter Ansatz wird jedoch bei homogenen 

Datenbanken den anderen Ansätzen vorgezogen. 

Die Schemaintegration kann in einem Vierschrittverfahren erfolgen: 

• Vorintegration: Es werden eine Integrationsstrategie (binär, n-stellig) ausgewählt, die Integrationsreihenfolge unter den Schemata 

festgelegt, Schlüsselkandidaten bestimmt und äquivalente Wertebereiche sowie Konversionsfunktionen zwischen ihnen 

definiert. 

• Erkennung von Namens- und strukturellen Konflikten: Es werden Synonym- und Homonymbeziehungen zwischen den 

Typen der einzelnen Schemata bestimmt. Sind Typen weder synonym noch homonym, stehen aber in einer ontologischen Beziehung, 

dann werden allgemeinere Begriffe für die Integration herausgebildet. Gegebenenfalls erfolgt außerdem eine Ableitung 

von Kooperationsbeziehungen zwischen den Typen. Mit den Kooperations- und Synonymbeziehungen können Typen der Schemata 

zusammengeführt werden. 

• Die Auflösung struktureller Konflikte ist oft schwierig. Durch Schematransformationen, z. B. Umwandlung von Attributen in 

eigenständige Relationen, kann eine Vereinheitlichung herbeigeführt werden. 

• Das Mischen und die Restrukturierung sind nicht automatisierbar. Es kann aber versucht werden, zuerst zu mischen und danach 

zur Reduzierung von Redundanz zu restrukturieren. Oft kann man Transformationsfunktionen für Datenkonflikte ableiten. 

B) Autonome DBS: Mit einer expliziten Integration bei weiterer Selbständigkeit der Systeme ergeben sich die in Bild 16 dargestellten Alternativen. 

B.1) Programmierte Verteilung: Der DB-Zugriff erfolgt über den Aufruf vordefinierter Programmfragmente bzw. von Prozeduren/Methoden. 

Typische Realisierungsformen sind verteilte Transaktionssysteme auf der Basis von TP-Monitoren und verteilten 

OO-Systemen z. B. mittels CORBA. 

Ein Beispiel zur programmierten Verteilung ist die in Bild 17 angegebene Transaktion, die erst dann wirksam wird, wenn 

beide Teiltransaktionen wirksam geworden sind. Durch ein verteiltes Commit, das durch den TP-Monitor koordiniert wird, 

kann die ACID-Eigenschaft der Transaktion gewahrt werden. Die Einzelsysteme sind indirekt beteiligt. Sie müssen Datenbank- 

Operationen von nicht-lokalen Transaktionen akzeptieren. Außerdem müssen sie am verteilten Commit-Protokoll teilnehmen,


Programmierte 

Verteilung 

A(nw.-)P(rogr.) 

AP 

DBS 

Präsentation 

AP 

DBS 

Verteilung von 

DB-Operationen 

DBS 

Präsentation 

AP 

DBS 

Föderative Systeme 

Präsentation 

AP 

Föderatives DBS 

DBS DBS 

Abbildung 16: Alternativen für autonome DBS 

Transaktionsprozeß: Überweisung 

Eingaben (K1, K2, S) 

BEGIN TRANSACTION 

CALL ABHEBUNG (Bank1, S, K1, ...) 

CALL EINZAHLUNG (Bank2, S, K2,...) 

COMMIT TRANSACTION 

Ausgabemitteilung 

TP-Monitor 1 

Überweisung 

Transaktionsprozeß: Abhebung 

TP-Monitor 2 TP-Monitor 3 

Transaktionsprozeß: Einzahlung 

Parameter übernehmen 

... 

EXEC SQL UPDATE account 

SET balance = balence - :S 

WHERE acctno = :K1 

... 

Erfolg melden 

Abhebung 

Bank 1 

DBS 

Einzahlung 

Bank 1 

DBS 

Parameter übernehmen 

... 

EXEC SQL UPDATE girokonto 

SET kstand = kstand + :S 

WHERE knummer = :K2 

... 

Erfolg melden 

Abbildung 17: Programmierte Verteilung in einer Bank-Transaktion


um verteilte Änderungstransaktionen wie in Bild 17 zu ermöglichen. Ein verbreiteter Ansatz ist ein Zwei-Phasen-Commit mit 

zentralem Koordinator. In der ersten Phase wird eine Abstimmung über ein Commit bzw. einen Abbruch mit jedem Rechner 

durchgeführt, an dem die Transaktion aktiv war. In der zweiten Phase wird allen beteiligten Rechnern das Ergebnis des globalen 

Commits mitgeteilt. Die Koordination wird auf einem ‘sicheren’ Rechner (Server) durchgeführt. Ein Commit-Protokoll 

gewährleistet nur die Eigenschaften A und D von ACID. Die Isolation erfordert globale Serialisierbarkeit, die gewährleistet ist, 

falls jedes DBS ein striktes Zweiphasen-Sperrprotokoll (lange Lese- und Schreibsperren) zur Synchronisation verwendet. Die 

Auflösung globaler Deadlocks erfolgt über Timeout. 

Die Verbindung zu den einzelnen Systemen findet im Beispiel über Embedded-SQL-Schnittstellen statt. Eine andere Alternative 

ist das Call-Level-Interface der einzelnen DBS. 

B.2) Verteilung von DB-Operationen: Verschiedene DBS übernehmen die Ausführung von Anfragen. Aufrufgranulat ist dabei die 

einzelne Datenbank-Operation, z. B. die SQL-Anweisung. Der Aufbau der Datenbanken muß bekannt sein. Ein Client-DBS 

kann die Anwendungsprogramm-Rolle übernehmen. 

Verteilte Transaktionsverarbeitung kann nach X/Open (Distributed Transaction Processing, DTP) erfolgen. Es werden ein allgemeines 

Modell sowie Schnittstellen zur verteilten Transaktionsverarbeitung in heterogenen Systemen definiert. Ein Schnittstelle 

zur Transaktionsverwaltung (TM), die die Transaktionsverwaltung koordiniert, nutzt BEGIN, COMMIT, ROLLBACK von 

Transaktionen. Wie in Bild 18 dargestellt, erlaubt eine Verbindungskontrolle zwischen Anwendungsprogramm und der Trans- 

Schnittstelle zur 

Transaktionsverwaltung 

Anwendung 

✯ 

❥ 

Transaction 

Manager 

❄ 

Resource 

Manager 

Integrationsschnittstelle 

zwischen TA-Manager 

und DBS 

Abbildung 18: Verteilte Transaktionsverarbeitung von X/Open 

aktionsverwaltung die Durchführung des 2-Phasen-Commit-Protokolls (2PC). Außerdem erlauben XA-kompatible DBS eine 

Commit-Initiierung von ‘außen’. Die Einzelsysteme können abstrahierend als Ressourcen-Manager (RM) verstanden werden. 

Beispiel sind neben DBS auch Dateisysteme, Mail-Systeme, Window-Manager. Sie müssen über eine eigene Synchronisation, 

ein Logging und Recovery verfügen. Die Schnittstelle zur Transaktionsverwaltung wird dabei durch die folgenden Kommandos 

unterstützt: 

tx open 

Öffnen der dem TM bekannten RM 

tx close 

Beenden der Verbindung zwischen AP und TM 

tx begin 

Starten einer globalen Transaktion 

tx commit erfolgreiches Beenden einer globalen Transaktion 

tx rollback Rücksetzen einer globalen Transaktion 

tx info 

Informationen über aktuelle Transaktion anfordern 

tx set TA control ‘chained’ Transaktions-Modus ein- /ausschalten 

tx set TA timeout Zeit für automatisches Rollback setzen 

tx commit return Fortsetzen des AP schon nach Phase 1 des 2PC-Protokolls 

Analoge Kommandos kann man für die Integrationsschnittstelle benutzen: 

ax reg Registrieren eines RM beim TM 

ax unreg Abmelden eines RM beim TM 

xa open Initialisierung RM für AP 

xa close RM-Nutzung beenden für AP 

xa start RM nimmt an neuer Transaktion teil 

xa end RM beendet Arbeit an Transaktion 

xa prepare Aufforderung zur Commit-Vorbereitung 

xa commit Commit-Aufforderung 

xa rollback Rollback-Aufforderung 

xa complete Nachfrage, ob xa-Aufruf beendet 

xa forget RM kann Information über heuristisch beendete Transaktion 

xa recover Anforderung von IDs zu Transaktionen, die im RM im Zustand 

vergessen 

xa recover Anforderung von IDs zu Transaktionen, die im RM im Zustand 

‘prepared’ bzw. heuristisch beendet sind


Die Kommunikation wird über den Communication-Resource-Manager realisiert, der eine standardisierte Kommunikation über 

RPC oder Peer-to-Peer ermöglicht. Eine Verteilungstransparenz wird nicht erreicht. OSI TP kann als verteiltes Commit-Protokoll 

zwischen den TM benutzt werden. 

Eine andere Architektur wird durch die Open DataBase Connectivity (ODBC) wie in Bild 19 realisiert. ODBC basiert auf 

einer API-Definition von Microsoft für einen einheitlichen Zugriff auf SQL-Datenbanken. Es ist ein Call-Level-Interface auf 

der Grundlage von dynamischem SQL. Die Verteilung wird durch das Verschicken von DB-Befehlen realisiert. Pro SQL-Server 

existiert ein eigener ‘ODBC-Treiber’ auf der Client-Seite. Transaktionen bleiben damit auf einen Server beschränkt. 

Anwendung 

z. B. Access 

Anwendung 

z. B. Excel 

Anwendung 

z. B. Explorer 

Client (PC) 

ODBC-Treiber-Manager 

ODBC-Treiber ODBC-Treiber 

Netzwerk-Software Netzwerk-Software 

Netzwerk 

Server A 

Netzwerk-Software 

DBS (z. B. Oracle) 

Netzwerk-Software 

DBS (z. B. Sybase) 

Server B 

Abbildung 19: Open DataBase Connectivity (ODBC) 

Für ODBC wurden unterschiedliche Treiber entwickelt. Die Kernfunktionen und -Datentypen sind nach X/Open CLI bestimmt. 

Erweiterungen (Level 1 oder Level 2) dazu sind Date, Time, ScrollCursor, asynchrone Befehlsausführung etc. Damit kann eine 

einstufige oder mehrstufige Verarbeitung von DB-Operationen realisiert werden. Einstufige Treiber (one-tier driver) erlauben 

einen direkten Datenzugriff (lokal oder entfernt). Der Treiber verarbeitet SQL-Anweisungen für Nicht-SQL-Systeme. Typisches 

Beispiel sind Zugriffe auf Xbase-Dateien. Bei mehrstufigem Treibereinsatz werden die SQL-Anweisungen an das Server-DBS 

weitergegeben. Der Zugriff erfolgt auch für Nicht-SQL-DBS über eine SQL-Unterstützung auf Client- oder Server-Seite, ggf. 

über einen DB-Gateway im dreistufigem Ansatz. 

Der ODBC-Ansatz wurde auch in analoger Form für Java-Umgebungen (JDBC) eingesetzt. Neben diesen Standardisierungansätzen 

sind auch die Multivendor Integration Architecture (MIA), Standards über Remote Database Access (RDA) und SQL 

Access, sowie die IBM Distributed Relational Database Architecture (DRDA) weiter verbreitet. 

B.3) Föderative DBS: Das föderative System kann eine vereinheitlichte Datenbank-Sicht unterstützen. Damit kann auch eine verteilte 

Ausführung einer Datenbank-Operation ermöglicht werden. Wie bereits dargestellt in Bild 45, 46 und 47 erlauben föderative 

verteilte DBS die Bildung von Föderationen zwischen existierenden, unabhängigen DBS zum Datenaustausch. Es wird eine 

begrenzte Kooperation zwischen den DBS bei Wahrung einer möglichst hohen Knotenautonomie angestrebt. Dabei können 

heterogene DBS unterstützt werden. 

Föderative verteilte DBS haben eine weitergehende Funktionalität verglichen mit verteilten Transaktionssystemen. Sie erlauben 

DBS-übergreifende Operationen, eine höhere Verteilungstransparenz, eine weitgehend einheitliche Anfragesprache, eine 

Unterstützung bezüglich Heterogenität bei Datenmodellen und bei der Transaktionsverwaltung, eine Unterstützung bezüglich 

semantischer Heterogenität. Föderative Systeme besitzen eine Zusatzebenen-Architektur wie in Bild 47 dargestellt. Mit dem 

globalen Kommunikations- und Verknüpfungssystem können sowohl globale Anfragen und Transaktionen unterstützt werden 

als auch lokale Anfragen und Transaktionen weitergegeben werden. 

Globale Transaktionen werden zu lokalen Subtransaktionen wie in Bild 20 zerlegt. Die Transaktionsverwaltung wird zweischichtig. 

Die lokale Transaktionen verbleiben lokal. Systemübergreifende Transaktionen werden in globale Subtransaktionen durch 

das föderative System zerlegt. Die lokale Autonomie bedingt das Verbergen von Steuerinformation des lokalen DBS (für die 

Synchronisation und das Recovery). Dabei kann das lokale DBS nicht zwischen lokalen und globalen Transaktionen unterscheiden, 

weil die globalen Subtransaktionen wie lokale Transaktionen mit dem ACID-Prinzip behandelt werden. Die lokalen DBS 

entscheiden unabhängig über das Commit lokal ausgeführter Transaktionen. Bereits existierende lokale Programme werden nach 

der Integration weiterbenutzt. Die Transaktionsverwaltung ist damit heterogen lokal. 

Das föderative System kann nur die globalen Transaktionen synchronisieren. Es wird angenommen, daß alle Objekte, auf die 

zugegriffen wird, durch das föderative DBS identifiziert werden können. Damit wird nur eine Erkennung von direkten Konflikten 

zwischen globalen Transaktionen möglich. Es ergeben sich allerdings Probleme durch transitive Abhängigkeiten mit lokalen 

Transaktionen. 

Damit ergeben sich bei föderativen Systemen Einschränkungen bezüglich der Funktionalität (z. B. begrenzte Unterstützung 

globaler Änderungstransaktionen, der lokalen Autonomie (ggf. mit Erweiterungen der lokalen Transaktionsverwaltung), der


Glob.TA 1 Glob.TA 2 Glob.TA 3 

Lok.TA 1 

❄ ❄ ❄ 

Globale föderative Transaktionsverwaltung 

GTA 1.1 GTA 2 

GTA 3.2 

Lok.TA 2 

GTA 1.2 

GTA 3.1 

Lok.TA 3 

❄ ❄ ✠ ❘ ❄ ✠ ❘ ❄ 

Lokales DBS 1 Lokales DBS 2 Lokales DBS n 

Abbildung 20: Zweischichtige Transaktionsverwaltung in föderativen Systemen 

Heterogenität (z. B. Verwendung identischer Synchronisations- und Commit-Protokolle in den lokalen DBS), bei den ACID- 

Zusicherungen (z. B. Verzicht auf eine globale Serialisierbarkeit)). 

Ein einfacher ‘Ansatz’ ist die Beschränkung globaler Transaktionen auf höchstens eine ändernde Subtransaktion. Der X/Open- 

Ansatz verwendet dagegen ein standardisiertes Commit-Protokoll (XA-Schnittstelle), ein striktes 2PL in jedem lokalem DBS 

und ein Timeout zur globalen Deadlock-Behandlung. In der Forschung gibt es zahlreiche Vorschläge zur Synchronisation mit 

dem Ziel eines höheren Grades an Autonomie und Heterogenität als beim X/Open-Ansatz, wobei die Annahmen sehr einschneidend 

sein können und ggf. eine weitgehende Serialisierung globaler Transaktionen erfordern. 

Damit ergibt sich bezüglich Kooperationsumfang und Verteilungstransparenz aufsteigend eine Systemhierarchie in: 

◦ isolierte Datenbanksysteme, 

◦ verteilte Transaktionssysteme (Transaction routing bzw. programmierte Verteilung), 

◦ Verteilung von Datenbank-Operationen , 

◦ föderative Datenbanksysteme (lose gekoppelte föderative Systeme (Multi-DBS) 

bzw. die komplexeren eng gekoppelten föderativen Systeme), 

◦ verteilte Datenbanksysteme, 

◦ parallele Datenbanksysteme. 

Diese Hierarchie staffelt absteigend in der Komplexität Knotenautonomie bzw. Heterogenität bzw. Verteilungsgranulat. 

Für verteilte DBS sind jedoch aus folgenden Gründen weitergehende Standards notwendig. 

Portabilität: Durch standardisierte API’s werden Funktionen für den DB-Zugriff, die Transaktionsverwaltung und die Kommunikation zur 

Verfügung gestellt. Eine Teil-Standardisierung erfolgt durch das X/OPEN-Konsortium. Die Kommunikation kann auf der Microsoft 

Open Database Connectivity (ODBC) oder auch der Sun Java Database Connectivity (JDBC) aufsetzen. Datenbank-Anfragesprachen 

sind in diesem Fall ISO SQL bzw. normierte SQL-Subsets. 

Interoperabilität: Mit einer standardisierten Kommunikation kann eine weitgehende Interoperabilität von Datenbank-Anwendungen errecht 

werden. Die Nachrichtenformate und Protokolle werden festgelegt, z. B. ISO OSI, RDA (Remote Database Access), TP, CCR, ROSE, 

TCP/IP und LU6.2. 

Damit kann eine Architektur wie in Bild 21 unterstützt werden. 

Anwendung 

Anwendung 

API’s (application program interfaces) 

Middleware 

Plattform-Schnittstellen 

Plattform 1 

- Betriebssystem 

- Hardware 

Plattform n 

- Betriebssystem 

- Hardware 

Abbildung 21: Standardschnittstellen in Middleware-Architektur


Ein allgemeiner Standard hat sich bislang nicht durchgesetzt. Deshalb verwenden viele größere Systeme Datenbank-Gateways als eigenständige 

Schnittstelle. Selbst bei SQL-Datenbanksystemen bestehen erhebliche Unterschiede im Sprachumfang, der Syntax, den Datentypen, 

den Fehlercodes, etc. Gateways führen Transformationen zwischen Client und ServerSQL durch. Dabei entsteht ein hoher Aufwand zur 

Unterstützung zahlreicher Gateways. Die Definition einer gemeinsamen SQL-Teilmenge und einheitlicher Fehlercodes reduziert jedoch die 

Gateway-Anzahl. Die Gateway-Architektur ist in Bild 22 dargestellt. 

Client 

(AP, tools) 

Client-SQL 

Eingabedaten 

✛ 

✲ 

Daten/Fehlercodes 

im Client-Format 

Gateway 

Server-SQL 

Server-Formate 

✛ 

✲ 

Ausgabedaten, 

Fehlercodes im 

Server-Format 

Server 

(DBS) 

Abbildung 22: Einsatz von Gateways 

Die weiterführende Architektur in Bild 23 wird durch Wrapper (Adapter, Verkappseler, Paketierer) und Mediatoren (Vermittler, Broker) 

verfolgt. Mediatoren stellen eine gemeinsame Zugriffsschnittstelle auf heterogene Datenquellen zur Verfügung, zerlegen Anfragen und 

bündeln die Teilergebnisse für die Clients. Sie greifen ggf. auf Metadaten zurück und erlauben u. U. auch die dynamische Bestimmung relevanter 

Informationsquellen. Wrapper stellen den Mediatoren eine einheitliche Zugriffsschnittstelle auf die lokalen Systeme zur Verfügung. 

Sie haben eine Funktionalität, die der von Gateways zur Anpassung der Syntax, zum Ausgleich von Funktionsdefiziten etc. ähnelt. Sie binden 

unterschiedliche DBS, Dateisysteme, Spezialsyteme etc. ein. 

Client 1 Client 2 Client m 

Mediator 1 Mediator 2 

Metadaten 

Wrapper 1 Wrapper 2 Wrapper n 

Info-Quelle 1 

(DBS 1) 

Info-Quelle 2 

(DBS 2) 

Info-Quelle n 

(DBS n) 

Abbildung 23: Einsatz von Wrappern und Mediatoren 

Das bereits in Bild 4 und Bild 5 dargestellte CORBA-Framework erlaubt eine Middleware-Unterstützung für die Kooperation verteilter 

Systeme. Mit CORBA ist ein standardisierter Aufruf von Methoden (Anwendungsprogrammen) über den Object Request Broker realisiert 

(Bild 24). Der Zugriff auf nicht-objektorientierte DBS kann über bereitzustellende Anwendungsprogramme (Server-Objekte) bzw. Wrapper 

Anwendung 

(‘Client-Objekte’) 


OODBS 

Wrapper 1 

RDBMS 1 

Wrapper 2 

RDBMS 2 

Object 

Transaction 

Service 

Concurrency 

Control 

Service 

Query 

Service 

Abbildung 24: CORBA als Middleware-Konzept 

erfolgen. Der Object Transaction Service (OTS) umfaßt die Unterstützung für verteilte Transaktionen (2PC) und geschachtelte Transaktionen.


Mit einem Concurrency Control Service (CCS) werden auch global nutzbare Synchronisationsdienste realisiert. Ein Query Service ermöglicht 

Anfragen auf OODBS und SQLDBS. 

Ein typisches Beispiel für diesen Ansatz ist die Distributed Relational Database Architecture (DRDA) von IBM. Damit wird die Interoperabilität 

zwischen SQL-DBS von IBM (DB2/MVS, DB2/6000, DB2/2, DB2/400) sowie DRDA-kompatible Fremd-DBS unterstützt. Als 

Ausführungsart kann RUW (Remote Unit of Work) (bei der jede SQL-Operation einer Transaktion durch das DBMS verarbeitet wird), DUW 

(Distributed Unit of Work) (bei der einzelne SQL-Operationen einer Transaktion durch verschiedene DBMS verarbeitet werden) und DR (Distrubuted 

Request) (bei dem eine SQL-Anweisung einer Transaktion verschiedenen DBMS übergeben werden kann) gewählt werden. Beispiel 

einer RUW ist die folgende Sequenz: 

CONNECT TO L.DB2 ... ; 

SELECT ... FROM PERS1 ... ; 

COMMIT WORK; 

CONNECT TO F.DB2 ... ; 

SELECT ... FROM PERS2 ... ; 

UPDATE PERS2 SET ... ; 

COMMIT WORK; 

DISCONNECT ... 

In der Ablaufumgebung definiert die DRDA die Nachrichtenformate und -protokolle, die Abbildung von SQL auf DRDA-Nachrichten über 

Application Requester/Server und die verteilte Transaktionsverarbeitung. 

DRDA ist ein typisches Beispiel für einen Firmenstandard. Andere Firmenstandards sind Microsoft OLE DB, Microsoft Universal Data 

Access und der IBM DB2 Data Joiner. So wird in dem auf ActiveX basierenden Common Object Model (COM) mit dem Object-Linking-and- 

Embedding-Ansatz (OLE) der Zugriff auf heterogene Datenquellen über festgelegte COM-Schnittstellen wie in Bild 25 realisiert. Beteiligte 

Anwendungen / Werkzeuge 

OLE DB 

Query 

processor 

Tabular 

data 

File 

systems 

and. COM- 

Kompon. 

Spreadsheets 

OLE DB/ODBC 

Treiber-Manager 

ODBC 

Treiber 

ODBC 

Treiber 

DBS 1 DBS 2 

Abbildung 25: Microsoft OLE DB 

Komponenten dabei sind 

◦ als Data Provider SQL-DBS (Zugriff über ODBC), Dateien, Spreadsheets, 

EMailArchive, etc. 

◦ als Data Consumers die Anwendungen und Werkzeuge und 

◦ als Data Service Providers die Anfrage-Systeme etc. 

Voraussetzung der Anwendbarkeit sind allerdings tabellarische Daten. Sieben Objekttypen (mit insgesamt 55 Schnittstellen) (DataSources, 

DBSessions Commands, Rowsets, Indexes, Errors, Transactions) können verwendet werden. Damit wird die Interoperabilität zwischen mehreren 

Datenquellen (verteilte Anfragen) unterstützt. Verteilte Transaktionen sollen über Microsofts TP-Monitor unterstützt werden. Unterschiede 

gegenüber ODBC sind dabei die komponenten-basierte Architektur, die Verwendung von COM-API statt C-API und die Berücksichtigung von 

Nicht-SQL-Systemen. Angekündigt ist eine Unterstützung für verteilte Anfragen und Transaktionen. 

Dagegen ist der IBM DB2 Data Joiner eine föderative DBS-Lösung für den einheitlichen Zugriff (DB2 SQL) auf zahlreiche SQL-DBS. 

Es werden zahlreiche Client- und Server-Plattformen unterstützt. Der Data Joiner besitzt eine hohe Funktionalität. Verteilte und globale Anfragen 

(Joins) mit umfassender Anfrage-Optimierung werden ermöglicht. Es werden objekt-relationalen Eigenschaften (UDTs, UDFs, LOBs, 

rekursive Anfragen), verteilte Transaktionen (XA-Unterstützung) und replizierte Datenhaltung unterstützt. Eine Ortstransparenz wird über 

Nicknames realisiert: 

CREATE NICKNAME D_KUNDE FOR DB2.J15USER3.CUSTOMER 

CREATE NICKNAME O_LIEFERUNGEN FOR ORACLE..J15USER3.ORDER_HISTORY 

SELECT D.CUSTNAME 

FROM D_KUNDE D, O_LIEFERUNGEN O 

WHERE D.CUSTNO = O.CUSTNO AND O.SHIPDATE = 19990401 

Schemata verteilter DBS. 

Obwohl die vollständige Schemaintegration algorithmisch nicht lösbar ist, kann man die Entwicklung eines integrierten Schemas in verteilten 

Anwendungen anstreben. Eine Schemaarchitektur kann man dabei an die föderativen Systeme wie in Bild 48 anlegen. Dabei wird angestrebt,


ein gemeinsames konzeptionelles und internes Schema für alle Knoten anzulegen. Von Vorteil ist, daß ein globales konzeptionelles Schema 

Verteilungstransparenz unterstützt. Es wird jedoch keine Knotenautonomie unterstützt. Deshalb ist ein globales Schema, dem das Verteilungsschema 

unterlegt wurde, ungeeignet. Es ist außerdem für geographisch verteilte Systeme ungeeignet. Mit der in Bild 48 angegebenen 

Lokales 

externes 

Schema 1 

Lokales 

externes 

Schema 2 

Lokales 

externes 

Schema m 

Globales konzeptionelles Schema 

Globales Verteilungsschema 

Lokales 

konzept. 

Schema 1 

Lokales 

konzept. 

Schema 2 

Lokales 

konzept. 

Schema n 

Lokales 

internes 

Schema 1 

Lokales 

internes 

Schema 2 

Lokales 

internes 

Schema n 

Lokales 

DBS 1 

Lokales 

DBS 2 

Lokales 

DBS n 

Abbildung 26: Verallgemeinerung der Dreiebenen-Schema-Architektur 

Architektur wird die Verteilungstransparenz durch das globale konzeptionelle Schema und die Knotenautonomie durch die lokalen konzeptionellen 

und internen Schemata unterstützt. Ein Katalog führt die Metadaten für die DB-Verarbeitung. Im Katalog werden die Namen und 

Adressen externer Knoten und der DBS, Angaben zur Datenverteilung und Angaben zu Relationen, Sichten, Attribute, Integritätsbedingungen, 

Benutzern, Zugriffsrechten, Indexstrukturen, Statistiken etc . geführt. Jeder Knoten führt für die lokalen Objekte die Katalogdaten. 

Alternativen für die Realisierung eines globalen Kataloges (Verteilungsinformationen, Angaben zu nicht-lokalen Objekten und Benutzern) 

sind: 

◦ zentralisierter Katalog; 

◦ vollständig replizierter Katalog; 

◦ Mehrfachkataloge: Kombination aus den beiden ersten Ansätzen und 

◦ partitionierter Katalog 

Ein weitere Variante ist die Verwendung eines partitionierten Kataloges und die Pufferung (Caching) von entfernten Katalogdaten. 

Die beiden Wesentlichen Alternativen zur Behandlung veralteter Katalogangaben sind 

- entweder eine Verlinkung der Daten, so daß sich der Besitzerknoten vermerkt, wo Katalogdaten gepuffert sind 

und invalidiert diese bei einer Änderung, oder 

- die Verwendung von Zeitstempeln, so daß bei der Ausführung einer Operation festgestellt wird, ob veraltete 

Katalogdaten verwendet wurden, und ggf. eine Neuübersetzung und -ausführung mit aktualisierten Daten (wie z. 

B. im System R*) vorgenommen wird. 

Anforderungen an die Namensvergabe sind damit 

◦ eindeutige Bezeichner für globale Objekte: Relationen, Sichten, Indexe usw.; 

◦ Stabilität gegenüber Datenumverteilungen (Migration); 

◦ Unterstützung von Verteilungstransparenz; 

◦ lokale Namensvergabe. 

Die Struktur des Namensraums kann entweder global unter Einsatz von Namensservern oder Namenskonventionen konzipiert sein, woduch 

allerdings ein weiteres Zuverlässigkeitsproblem entsteht, oder hierarchisch sein, wodurch die Knotenautonomie gewährleistet wird, die 

Netzwerk-Partitionierung toleriert wird und eine Anpassung an das Wachstum einfach ist. 

Zur Namensvergabe kann eine dreiteilige Objektbezeichnung 

[ [.].] 

gewählt werden. Damit wird eine lokale Namenswahl durch Benutzer wie in zentralisierten Systemen unterstützt. Verschiedene Benutzer 

können die gleichen Objektnamen verwenden. Die Referenzierung lokaler Objekte erfolgt wie im zentralen Fall. Diese Lösung erfordert 

jedoch die Verwendung von für externe Objekte. Damit wird die Ortstransparenz verletzt. Eine Änderung der Datenallokation 

erfordert auch Programmänderungen.


Abhilfemöglichkeiten existieren eine Reihe. Durch die Verwaltung von Synonymen (Aliases) für jeden Benutzer, wobei die automatische 

Abbildung auf vollen Objektnamen durch das DBS erfolgt, kann die Allokation mitgeführt werden. Damit wird bei Datenmigration nur eine 

Anpassung der Synonymtabellen notwendig oder im ursprünglichem Knoten wird ein Vorwärtsverweis auf die neue Datenlokation gespeichert. 

Ein Beispiel eine solchen Lösung ist das System R ∗ . Es verwendet als Syntax 

:: =[ [@].] [@birth_node] . 

Darauf werden Expansionsregeln für systemweite Namen aufgesetzt: 

• ein fehlender wird ersetzt durch die aktuelle USERID; 

• ein fehlender wird ersetzt durch die aktuelle KNOTENID; 

• ein fehlender wird ersetzt durch die aktuelle KNOTENID 

Vorteile dieses Zuganges sind Knotenautonomie und die Auswirkungsfreiheit auf Namen und damit bestehende Programme bei Migration 

eines Objektes. Erkauft werden diese Vorteile mit einer umständlicheren Adressierung, falls das Objekt nicht an Benutzerknoten gespeichert 

wird, weil mindestens ein Knotenname angegeben werden muß. Durch Synonyme kann hier Abhilfe geschaffen werden. 

Das verteilte System wird um eine Routine zur Namensauflösung wie in Bild 27 erweitert. Beteiligte Rechner sind Geburtsknoten (‘birth 

site’, meist im globalen Namen enthalten), Katalogknoten (‘catalog site’) und Speicherknoten (‘store site’). Es wird die Replikation (mehrere 

Speicherknoten) damit unterstützt. Die Trennung von Geburts- und Speicherknoten erlaubt eine Stabilität gegenüber Datenumverteilungen. 

Der Katalogknoten kann mit dem Geburts- oder Speicherknoten übereinstimmen, wodurch die Kommunikation verringert wird. 

✲ 

globaler Name 

Geburtsknoten 

Birth site 

❄ 

Katalogknoten 

Catalog site 

Speicherknoten 

Store site 

✮ ❄ 


 

Store site 


Store site 

Abbildung 27: Namensauflösung 

In analoger Form findet die Namensauflösung über Synonyme statt. Wie in Bild 28 illustriert, werden Synonyme (Alias-Namen) durch 

eine Abbildung benutzerspezifischer logischer Namen in vollqualifizierte globale Namen umgewandelt. Die Verwaltung von Synonymtabellen 

wird durch DBS im lokalen Katalog vorgenommen. Dieser Ansatz findet Verwendung in vielen kommerziellen Systemen wie z. B. Tandem 

NonStop SQL, DB2, Oracle, etc. 

lokale 

Synonymtabelle 

globale 

Katalogdaten 

✾ 

logischer Objektname 

3 ❄ 

globaler Objektname 

3 ❄ 

physische Objektadresse 

Abbildung 28: Namensauflösung über Synonyme 

Die in Bild 48 dargestellte Architektur für verteilte Datenbanksysteme ist nur eine der möglichen Alternativen. Ziele einer Schema- 

Architektur sind: 

• Bereitstellung eines globalen Schemas, um auch im weiteren mit globalen Relationen zumindest aus Benutzersicht arbeiten zu können; 

• Bereitstellen von externen Sichten (views) auf das globale Schema um verschiedenen Anwendungs- und Benutzeraspekten Rechnung 

tragen zu können; 

• Nichtsichtbarkeit von Heterogenitäten in den lokalen Schemata und Datenmodellen, der Partitionierung der globalen Relationen, der 

Allokation von Partitionen und von redundanten Speicherungen der Partitionen; 

• Bereitstellung von Informationen für die Anfrage-Prozessoren und den Datenbank-Administrator über die Partitionierung der globalen 

Relationen, die physischen Speicherungsorte von Partitionen, evt. redundant gespeicherte Partitionen und die anzuwendende Kopien- 

Update-Strategie.


Es existieren neben der dargestellten Architektur eines homogenen, prä-integrierten verteilten DBMS weitere Architekturen: 

Homogene, prä-integrierte DBS: Von den vorgegebenen globalen Relationen werden die Partitionen und Allokationen abgeleitet. Dadurch 

entsteht keine Heterogenität in den lokalen Schemata. Sie sind strukturell und semantisch homogen und verwenden das gleiche Datenbankmodell. 

Sie sind meist von vornherein als verteiltes System ausgelegt. 

Heterogene, prä-integrierte DBS besitzen kein gemeinsames Datenbankmodell. Dadurch wird auf Implementationsebene die Heterogenität 

voll sichtbar und wirksam. Durch das Anwendungssystem muß deshalb die Heterogenität verborgen werden. Beispiele sind CADoder 

auch Web-Systeme, die meist mit komplexen Datentypen operieren müssen. Eine echte Integration kann nur selten erreicht werden. 

Meist wird nur eine Hybrid-Lösung erreicht. Damit entstehen aber auch interne Verarbeitungsprobleme, z. B. ein unterschiedliches 

Recovery-Verhalten im Fehlerfall. Trotzdem wird diese Entwicklungslinie in Zukunft viel stärker sein, weil Spezial-DBS als ‘embedded 

system’ entstehen und weil Spezialaufgaben auch Spezial-DBS erfordern. Wünschenswert wäre jedoch ein Verhalten wie ein 

monolithisches DBMS, wobei sowohl Integrationsprobleme für die Schemata gelöst werden müssen als auch aufeinander abgestimmte 

Basis-Funktionalitäten (Synchronisation, Recovery, Transaktionsvewaltung etc.) in allen Systemen verfügbar sein müssen. 

Post-integrierte Systeme werden auf der Basis bereits existierender DBS entwickelt. Die lokalen Systeme müssen weiterhin voll verfügbar 

bleiben. Tolerierbar sind ggf. Neuübersetzungen, nicht aber Eingriffe in den Quellcode. Damit muß das alte System als Sicht des neuen 

Systems erhalten bleiben. 

Eine Integrationsphase wird nachträglich ausgelöst. Die Integration von Datenbankschemata kann nach dem Wiederverwendungszyklus 

erfolgen: Prä-Inegration, Vergleich und Abgleich insbesondere bei der Konfliktlösung und der Auflösung von Ambiguitäten, 

Vereinheitlichungsphase, Einbettungs-, Restrukturierungs- und Zusammenfassungsphase. 

Schwierig gestalten sich Datenbank-Updates bei post-integrierten Systemen. Solange Daten disjunkt sind, ist eine Modifikation einfach. 

Schwieriger wird die Beherrschung der Redundanz. 

Wie bereits für prä-integrierte Systeme unterscheiden wir: 

Homogene, post-integrierte Systeme: Ist eine Integration erreicht worden, dann kann man die Systeme wie homogene, prä-integrierte 

Systeme fahren. Es wird durch eine Sichten-Architektur das jeweilige lokale System unterstützt. Die Sichten lassen auch einen 

Update zu. Damit wird eine mächtige Abbildungspsrache eingesetzt, die eine Transformation lokaler und globaler Daten auf 

lokale Daten gestattet. 

Heterogene, post-integrierte Systeme: Wird ein einheitliches Datenbank-Modell (z. B. das relationale) angewnadt, dann kann 

auf einer einheitlichen Sprachschnittstelle aufgesetzt werden. Damit können entsprechende Transformationen auf einheitlicher 

Sprachgrundlage definiert werden. Im allgemeinen Fall kann oft eine homogenisierende Schicht mit einem Ansatz analog zu 

föderativen Systemen eingesetzt werden, der dann auch gestattet die Operationen der lokalen Systeme aufeinander abzubilden. 

Günstig ist es, diese Operationen bereits zur Compile-Zeit bereitzustellen. Dynamisch erzeugte Operationen erfordern eine umfangreiche 

Implementierung und bringen Performanzprobleme. Eine Alternative ist oft die Verwendung eines reich strukturierten 

Datenbankmodelles wie z. B. des erweiterten ER-Modelles, in dem die lokalen Schemata spezifizierbar sind. 

Der globale Katalog von verteilten DBS erleichtert die Verwaltung erheblich. Er umfaßt neben der Schemainformation auch statistische 

Angaben, Angaben zur Authorisierung und Abbildungsvorschriften (Sichten etc.). Er kann sowohl den einzelnen Wrappern zur Verfügung 

gestellt werden als auch global, nicht-redundant verwaltet werden. 

Datenverteilung, Allokation und Partitionierung. 

Mit der Dreiebenen-Schema-Architektur in Bild 48 erscheint eine Trennung zwischen der Verteilung von Daten auf 

logischer Ebene mit einer prädikativen Beschreibung der Verteilung insbesondere zur (horizontalen, vertikalen, gemischten) Partitionierung 

globaler Relationen und auf 

physischer Ebene mit einer Festlegung des Speicherungsortes mit einer redundanten oder nicht-redundanten Allokation von Partitionen 

wie in Bild 49 sinnvoll. Einheiten der Datenverteilung sind die Partitionen. Wünschenswert ist eine Zerlegung von Relationen mit der Selektionsoperation 

oder mit der Projektionsoperation (horizontale und vertikale Partitionierung). Oft wird auch die Partitionierung redundant 

sein. Eine replizierte Speicherung von Partitionen bietet höhere Freiheitsgrade bei der Query-Optimierung, bedingt aber auch einen höheren 

Änderungsaufwand. Gründe für eine horizontale bzw. vertikale Partitionierung sind Lastbalancierung, Nutzung von Lokalität, Reduzierung 

des Verarbeitungsumfangs und Unterstützung von Parallelverarbeitung. 

Anschließend werden Teile der Partitionen Knoten zugeordnet (allokiert). Die Zuordnung ist bestimmt weitgehend Ausführungsort von 

DB-Operationen. Damit erhalten wir widersprechende Teilziele. Zum einem orientieren wir uns auf eine Minimierung der Kommunikationskosten, 

zum anderen jedoch auch auf eine Lastbalancierung. 

Die Partitionierung und Allokation sollte den folgenden Anforderungen genügen: 

Vollständigkeit: : Jedes Datum muß in wenigstens einer Partition enthalten sein. 

Rekonstruierbarkeit: Die Zerlegung sollte verlustfrei sein. 

(Weitestgehende) Disjunktheit: Um durch die Redundanz in den Partitionen nicht einen zu hohen Pflegeaufwand in Kauf nehmen zu 

müssen, sollten die Partitionen disjunkt sein oder es sollten im Falle der Nichtdisjunktheit der Partitionen einfache Pflegemechanismen 

implementierbar sein. Da die Redundanz ggf. auch auf physischem Niveau noch beibehalten wird, kann man auch für die logische 

Aufteilung vereinfachend von einer redundanzfeien Partition ausgehen. 

Für die weitere Diskussion betrachten wir das ER-Schema in Bild 30. Nach [?] wird aufgrund der Kardinalitätsbeschränkungen dieses 

Schema in die folgenden Relationen übersetzt:


Globale 

Relation 

R 1 

✰✛ 

Partition 

von R 1 

✸ 

✲ 

P 11 

P 12 

✛ 

✛ 

❨ 

Allokation der 

Partitionen P 1j 

✲ 

✲ 

✸ 

A 111 

A 121 

A 131 

Knoten 

A 

✛ 

✐ 

❦ 

✲ P 13 

✰ ❥A 122 

♦ 

✶A 141 

✮ 

A 151 

P 14 

✼ 

❦ 

✇A 132 

A 142 

P 15 

✴✛ 

✲A 152 

Knoten 

B 

Knoten 

A 

Benutzersicht 

logische 

Aufteilung 

physische 

Speicherung 

Abbildung 29: Partitionierung und Allokation globaler Relationen 

arbeitet 

(1,1) 

Nr ❄ 

Name Angest 

Gehalt 

Anschrift 

✛ 

Name 

✲ Abteilung Bereich 

Budget 

✻ 

(1,1) Nr 

Manager 

Teil ✛ liefert ✲ Lieferant 

(1,1) 

Nr Preis 

Nr Name Stadt 

Abbildung 30: Das ER-Schema der Beispieldatenbank


ANGEST (PersNr, AngName, Gehalt, AbtNr, Anschrift) 

ABTEILUNG (AbtNr, AbtName, Bereich, MgrPersNr, Budget) 

TEILE (TeileNr, LiefNr, Preis) 

LIEFERANT (LiefNr, LiefName, Stadt) 

Eine horizontale Partitionierung wird durch 

Selektionsprädikate R i := σ Pi (R) (1 ≤ i ≤ n) bestimmt. 

Die Forderung auch Vollständigkeit impliziert, daß jedes Tupel einer Partition zugeordent sein muß, d. h. ∪ n i=1R i = R. Damit ist eine 

horizontale Zerlegung verlustfrei, falls die Partitionen mit einem Selektionsprädikat definiert sind. 

Die horizontale Partitionierung ist disjunkt, falls R i ∩ R j = ∅ für 1 ≤ i < j ≤ n gilt. 

Für unser Beispiel können wir z. B. eine horizontale Partitionierung von LIEFERANT erhalten mit: 

LIEFERANTORT1 := σ Stadt=‘Berlin ′(LIEFERANT) 

LIEFERANTORT2 := σ Stadt=‘Cottbus ′(LIEFERANT) 

LIEFERANTORT3 := σ Stadt≠‘Berlin ′ ∧ Stadt≠‘Cottbus ′(LIEFERANT) 

Die Partionierung muß nicht notwendig über einen Schlüssel definiert sein wie das Beispiel illustriert. 

Eine Partionierung kann ggf. auch im Schema weiter fortgesetzt werden. So definieren z. B. Fremdschlüssel-Primärschlüssel-Beziehungen 

Abhängigkeiten zwischen Relationen. Eine abgeleitete Partitionierung wird durch die referenzierte Relation und deren Partitionierung bestimmt. 

Im Beispiel erhalten wir 

TEILE1 := TEILE ✄< LIEFERANTORT1 



für den natürlichen Semi-Verbund ✄< . 

Vorteil einer abgeleiteten Partitionierung ist die lokale Berechenbarkeit des Verbundes. Abgeleitete horizontale Partitionierungen lassen sich 

sehr einfach anhand des zugehörigen ER-Schemas nachzeichnen. Die (abgeleitete) horizontale Partitionierung ist über σ, ∪ definiert. Analog 

können auch andere Operationen der Relationenalgebra verwendet werden. In der verwendeten Form ist die Partitionierung auch in SQL 

nachvollziehbar: 

select * 

from R 

where Selektionsbedingung . 

Die vertikale Partitionierung ist definiert durch das Paar Projektion und Verbund (π, ✶), d. h. 

R i := π X(R) (1 ≤ i ≤ n), R =✶ n i=1 R i . 

Wie auch in der Normalisierung kann eine Verlustfreiheit nur erreicht werden bei Zerlegung nach einer mehrwertigen oder funktionalen 

Abhängigkeit. Oft wird gefordert, daß der Primärschlüssel in alle Partitionen übernommen wird. Damit gilt die Verlustfreiheit in jedem Fall. 

Der Vorteil dieser rigiden Forderung ist die vereinfachte Pflege der Integrität. Die Vollständigkeit wird erreicht, wenn jedes Attribut in wenigstens 

einer Partition enthalten ist. 

In unserem Beispiel können wir die folgende vertikale Partitionierung anstreben: 

ANGEST Adresse := π P ersNr,AngName,Anschrift (ANGEST) 

ANGEST Abt := π P ersNr,AbtNr (ANGEST) 

ANGEST Gehalt := π P ersNr,AngName,Gehalt (ANGEST) 

Die Relation ANGEST wird aus dem Verbund : 

ANGEST Adresse ✶ ANGEST Abt ✶ ANGEST Gehalt 

erhalten. 

Die vertikale Partitionierung kann ebenfalls durch einen SQL-Projektionsausdruck definiert werden. Vertikale Partitionierung wird z. Z. 

von verteilten DBMS nur rudimentär unterstützt. 

Vertikale und horizontale Partitionierung können auch kombiniert werden, wodurch komplexere Partitionen entstehen. Gemischte (hybride) 

Partitionen bestehen aus Bäumen von Partitionen wie in Bild 50. 

R 21 

R 1 R 22 

R 23 

Zerlegung 

der Relation R 

R 

V 

✠ ❘ 

V 

R 2 

H H H 

✠ ❄❘ 

R 21 R 22 R 23 

Partitionierungsbaum 

Abbildung 31: Gemischte Partitionierung 

R 1 

✶ 

✒■ 

∪ 

✒✻■ 

R 21 R 22 R 23 

Rekonstruktionsbaum 

Ein Beispiel für eine Partitionierung wie in Bild 50 ist die Partitionierung von ABTEILUNG in die folgenden Relationen, die eine 

Partitionierung nach Leitungsgesichtspunkten und nach Arbeitsbereichen der Abteilungen vornimmt:


ABTEILLeiter := π AbrNR,MgrP ersNr,Budget (ABTEILUNG) 

ABTEILUNG-SW := σ Bereich=‘Software ′(π AbrNr,AbtName,Bereich (ABTEILUNG)) 

ABTEILUNG-HW := σ Bereich=‘Hardware ′(π AbrNr,AbtName,Bereich (ABTEILUNG)) 

ABTEILUNGSonst := 

σ Bereich≠‘Software ′ ∧Bereich≠‘Hardware ′(π AbrNr,AbtName,Bereich(ABTEILUNG)) 

Eine Partitionierung kann nach unterschiedlichen Transparenzstufen erfolgen. Es kann sichtbar oder unsichtbar sein, welchem Knoten 

eine Partition zugeordnet wird. Es kann sichtbar oder unsichtbar sein, inwieweit eine Replikation bei der Allokation vorgenommen wird. 

Partitionstransparenz: Die Partitionierung ist dem Benutzer nicht sichtbar. Er benutzt nur die globalen Namen. Liegt keine Partitionstransparenz 

vor, dann kann der Benutzer auch den Partitionsnamen für den Zugriff benutzen. 

Replikationstransparenz: Ein Benutzer kann nicht für Tupel unterscheiden, ob diese Tupel mehrfach in Partitionen vorkommen. Liegt keine 

Replikationstransparenz vor, dann kann der Benutzer Tupel je nach Partition auswählen. 

Ortstransparenz: Die Zuordnung zu Knoten ist unbekannt. Liegt dagegen keine Ortstransparenz vor, dann kann der Benutzer den Knotennamen 

als Zugriffspfad benutzen. 

Die Bestimmung geeigneter Partitionierungen kann oft mit einem intuitiven Ansatz erfolgen. In vielen Anwendungen reicht es bereits 

aus, die Partitionierung nach lokalen Zugriffsanforderungen vorzunehmen. Bei komplexeren Anwendungen gibt es eine Vielzahl von Einflußgrößen. 

Dann ist eine systematische Vorgehensweise erforderlich. Dazu werden die Anwendungen analysiert nach einer Reihe von Parametern: 

• Art des Zugriffs (lesend oder schreibend); 

• Häufigkeit der Operationen; 

• Auswahlbedingungen der Anfragen; 

• betroffene Relationen und innerhalb dieser Gruppen von Attributen; 

• zu übertragende Datenmengen. 

Auf der Grundlage dieser Entwurfsinformationen wird untersucht, ob eine Partitionierung sinnvoll wird, z. B. durch eine geringere Anzahl von 

Zugriffen. Wird die Zugriffshäufigkeit durch Selektionsprädikate geringer oder die Zugriffsbreite (Arität der Tupel) geringer durch vertikale 

Partitionierung, dann führt eine Partitionierung zu einem Performanzgewinn. 

Die Bestimmung horizontaler und vertikaler Partitionen kann mit einem Rückgriff auf die Booleschen Funktionen berechnet werden. Wir 

deuten dieses Verfahren hier kurz an. Es ist den Verfahren zur Optimierung Boolescher Schaltkreise entlehnt. 

Wir betrachten dazu zuerst die horizontale Partitionierung. Jeder Selektionsausdruck, der zur horizontalen Partitionierung verwendet wird, 

hat eine induktive Struktur, die auf der Grundlage von Elementartermen der Form Aωa mit a ∈ dom(A) und ω ∈ {, ≤, ≥, =, ≠} definiert 

sind. Die Menge der Elementarterme α 1 , ..., α k kann zur Darstellung der Selektionsausdrücke in disjunktiver Normalform benutzt werden. Die 

Elementarausdrücke werden mit der Aufrufhäufigkeit und der Selektivität gewichtet. Mit diesen Angaben kann eine Partitionierung bestimmt 

werden, bei der eine Partition nicht in unterschiedlicher Weise von zwei (oder mehr) der unterstellten Anfragetypen referenziert wird und sich 

für die Tupel einer Partition in etwa die gleiche Zugriffshäufigkeit ergibt. Mit den verwendeten Selektionsausdrücke können nun die Monome 

herausgefiltert werden, die nun ihrerseits als Komponenten der Selektionsausdrücke benutzt werden. 

Abgeleitete horizontale Partitionen werden analog zu obigen Verfahren in die Partitionierung einbezogen. Es wird am einfachsten dazu 

das ER-Schema herangezogen. Damit läßt sich der Effekt einer Partitionierung auf andere Relationen relativ einfach bestimmen. Daraus 

können über die Fremdschlüssel-Beziehungen Partitionierungen abgeleitet werden für die referenzierenden Relationen. Diese werden wiederum 

so behandelt wie bereits zuvor die Relationen für den Fall der horizontalen Partitionierung. Eine Zusammenführung mit den referenzierten 

Relationen erfolgt dabei über den Semi-Verbund. 

Die vertikale Partitionierung ist ein relativ komplexes Optimierungsproblem. Es werden oft statt einer exakten Lösung dafür heuristische 

Verfahren verwandt, die z. B. die Zugriffshäufigkeiten auf Attributgruppen benutzen, um eine Attributgruppierung abzuleiten. 

Nachdem eine Partionierung bestimmt wurde, können die einzelnen Partitionen Knoten des Netzes zuordnet werden. Die Allokation erfordert 

eine Optimierungstrategie. Optimierungsziele dabei sind u.a. die Unterstützung kurzer Antwortzeiten bzw. eines hohen Durchsatzes, 

die Minimierung des Kommunikationsbedarfs und die Lastbalancierung. Das Optimierungsmodell basiert demzufolge auf einer Minimierung 

einer Kostenfunktion unter Einhaltung von Randbedingungen. Hauptkomponenten der Kostenfunktion sind demzufolge als negativer Faktor 

die Kommunikationskosten, als positiver Faktor der Umfang der lokalen Verarbeitung und als Nebenbedingung Das Nichtüberschreiten von 

Grenzwerten zur Auslastung einzelner Rechner. Plazierungsaspekte sind zum einem die Effizienz, d. h. insbesondere die Minimierung der 

Remote-Zugriff-Kosten und die Vermeidung von Engpässen in der Kommunikation und bei den lokalen Rechnern, und zum anderen die Datensicherheit 

z. B. durch Auswahl von Knoten unter Verläßlichkeitsaspekten und durch redundante Speicherung von Daten. Bei der Plazierung 

können zwei Hauptansätze verfolgt werden: 

• nicht-redundante Allokation (Plazierung) mit einem ggf. höheren Kommunikationsaufwand und 

• redundante Allokation (Platzierung) mit einem ggf. höheren Pflegeaufwand. 

Das mathematische Modell für die nicht-redundante Allokation benutzt die folgenden Parameter: 

• K : Anzahl der Knoten im Netz; 

• P : Anzahl von zu allokierenden Partitionen der globalen Relationen; 

• T : Anzahl der Typen von Lese- und Änderungsoperationen auf den globalen Relationen; 

• M i : maximale Speicherkapazität in den Dateneinheiten am Knoten i (1 ≤ i ≤ K);


• S i : Speicherkosten pro Dateneinheit am Knoten i (1 ≤ i ≤ K); 

• U ij : Übertragungskosten pro Dateneinheit vom Knoten i nach Knoten j (1 ≤ i, j ≤ K, i ≠ j); 

• G p : Größe in Dateneinheiten der Partition p (1 ≤ p ≤ P ); 

• O tp : Größe in Dateneinheiten einer Teiloperation (d. h. einer Anfragezeichenkette) vom Typ t gegen die Partition p (1 ≤ p ≤ P , 

1 ≤ t ≤ T ); 

• R tp : Größe in Dateneinheiten des Resultats einer Teiloperation (d. h. einer Anfragezeichenkette) vom Typ t gegen die Partition p 

(1 ≤ p ≤ P , 1 ≤ t ≤ T ); 

• H it : Häufigkeit, mit der Operationen vom Typ t am Knoten i gestellt werden (1 ≤ i ≤ K, 1 ≤ t ≤ T ); 

• V pi : charakteristische Funktion der Verteilung der Partition auf die Knoten, wobei V pi = 1 gilt , falls die Partition p am Knoten i 

allokiert ist und V pi = 0 sonst für (1 ≤ p ≤ P , 1 ≤ i ≤ K). 

Bei Leseoperationen gilt typischerweise R tp >> O tp. Damit kann u. U. auch der Faktor O tp vernachlässigt werden. Bei Änderungsoperationen 

kann dagegen O tp relativ groß werden, während R tp lediglich eine Bestätigung für die Durchführung der Operation beschreibt. 

Damit entstehenden die folgenden Kostenbestandteile: 

Speicherkosten: Σ S = ∑ P 

∑ K 

p=1 Gp i=1 VpiSi 

Übertragungskosten: Σ U = 

∑ P 

∑ K 

∑ K 

∑ T 

p=1 i=1 j=1 t=1 H itO tp V pj U ij + ∑ P 

∑ K 

∑ K 

∑ T 

p=1 i=1 j=1 t=1 H itR tp V pj U ji 

∑ 

Nebenbedingung für die nicht-redundante Speicherung: K 

i=1 V pi = 1 für alle p (1 ≤ p ≤ P ) 

∑ 

Nebenbedingung für maximale Speicherkapazitäten: P 

p=1 G pV pi ≤ M i für alle i (1 ≤ i ≤ K) 

Damit ist das Optimierungsproblem für die nicht-redundante Allokation als Minimierungsaufgabe gegeben, bei der die Funktion 

d. h. die Funktion 

P∑ 

p=1 

unten den Nebenbedingungen 

G p 

K 

∑ 

i=1 

V pi S i + 

p=1 i=1 j=1 t=1 

Σ S + Σ U , 

P∑ K∑ K∑ T∑ 

P∑ K∑ K∑ T∑ 

H it O tp V pj U ij + 

H it R tp V pj U ji 

p=1 i=1 j=1 t=1 

(i) ∑ K 

i=1 

Vpi = 1 für alle p (1 ≤ p ≤ P ) und 

(ii) ∑ P 


minimiert wird. 

Bei hinreichend guten Abschätzungen für die einzelnen Parameter kann das Optimierungsproblem durch Optimierungswerkzeuge gelöst 

werden, wobei durch die Komplexität der Kostenfunktion mit erheblichen Rechenaufwand zu rechnen ist. Es kann sowohl die Knotentopologie 

als auch die Partitionierung als dynamischer Parameter in das Optimierungsproblem einfließen. Neuere Algorithmen der Genetischen 

Programmierung und der Heuristik versprechen hier Abhilfe. 

Das Kostenmodell für die redundante Allokation ist bezüglich der Speicherkosten und der Nebenbedingung für die maximale Speicherkapazitäten 

gleich. Ändern müssen sich jedoch die beiden anderen Größen: 

Übertragungskosten: Wir unterscheiden hier nach den Operationen. Es gibt T L Leseoperationen auf den globalen Relationen und T S 

Änderungsoperationen auf den globalen Relationen, wobei T = T L + T S gilt. 

Eine Leseoperation gegen die Partition p wird an denjenigen Knoten i gesandt, von dem das Resultat mit den geringsten Kosten 

erhalten werden kann. Damit erhalten wir 

Σ L U = ∑ P 

∑ K 

∑ T 

L 

p=1 i=1 t=1 H it min K j=1, V pj =1(O tp U ij + R tp U ji ) 

Eine Änderungsoperation gegen die Partition p wird an alle Knoten gesandt, an denen die Partition p allokiert ist. Damit erhalten 

wir 

Σ S U = ∑ P 

∑ K 

∑ T 

S 

p=1 i=1 t=1 H ∑ K 

it j=1, V pj =1 (O tpU ij + R tp U ji ) 

∑ 

Nebenbedingung für die nicht-redundante Speicherung: K 

i=1 

Vpi ≥ 1 für alle p (1 ≤ p ≤ P ), weil jede Partition an mindestens einem 

Knoten allokiert sein muß. 

Damit ist das Optimierungsproblem für die redundante Allokation als Minimierungsaufgabe gegeben, bei der die Funktion 


(i) ∑ K 

i=1 

Vpi ≥ 1 für alle p (1 ≤ p ≤ P ) und 

(ii) ∑ P 



Σ S + Σ L U + Σ S U


Man ist damit von Ansatz her in der Lage, eine optimale Lösung exakt zu berechnen, falls alle Parameterwerte hinreichend genau bestimmt 

werden können. Man kann in der Verfeinerung noch Transaktionen und die interne Anfrageoptimierung der lokalen Rechner berücksichtigen, 

womit die Optimierungsaufgabe jedoch wesentlich komplexer wird und das Allokationsproblem nicht mehr dynamisch behandelt werden kann. 

Deshalb werden meist heuristische Verfahren in der Praxis angewandt, die im Wesentlichen an den obigen Optimierungsverfahren angelehnt 

sind, jedoch die Lastverteilung an der Zugriffsfrequenz optimieren. Es wird zunächst die Partition mit der höchsten Zugriffsfrequenz betrachtet. 

Danach werden die lokalen Zugriffsfrequenzen berechnet. Eine Allokation wird nach dem Zugriffsgewicht zugeordnet. 


Die folgenden Übungsaufgaben dienen der Kontrolle des Verständnisses der in diesem Kapitel behandelten Teilkomplexe. Sie sollen ohne 

zusätzliche Hilfsmittel bewältigt werden. 

1. Korrektheit der abgeleiteten horizontalen Partitionierung: Die bislang behandelte horizontale Partitionierung und die abgeleitete horizontale 

Partitionierung sind nur dann korrekt, falls in der abhängignen Relation keine Nullwerte als Fremdschlüssel vorkommen dürfen. 

Wie ist die Partionierung zu erweitern, falls diese Voraussetzung nicht mehr zutrifft? Welche Auswirkungen ergeben sich hinsichtlich 

des Semi-Verbundes? 

2. Bestimmung von Partitionen: Ein Unternehmen bestehe aus Werken, denen jeweils die Abteilungsnummern 100-120, 130-180, 181-190 

sowie alle anderen zugeordnet sind. Außerdem soll die Relation ANGEST partitioniert werden in Manager und Angestellte, die keine 

Manager sind. Die Angestelltendaten sollen außerdem zur Sicherheit in vertrauliche Daten (Gehalt) und öffentliche Daten separiert 

werden. 

Man bestimme die horizontalen, vertikalen und die abgeleiteten horizontalen Relationen von ABTEILUNG und ANGEST. 

3. Bestimmung horizontaler Partitionen: Ein Unternehmen hat die Bereiche ‘Software’, ‘Hardware’ und ‘Service’. die Abteilungen seine 

jeweils primär einem Bereich zugeordnet (Software: 1-25, Hardware: 36-42 und Service: 26-35, 43-50). Die Analyse der Anwendungen 

ergebe folgende Zugriffsbereiche bzgl. der Relation ABTEILUNG: 

A 1 : Zugriff auf alle Tupel mit dem Bereich = ‘Software’; 

A 2 : Zugriff auf alle Tupel mit dem Bereich = ‘Hardware’; 

A 3 : Zugriff auf alle Tupel mit dem Bereich = ‘Service’; 

A 4 : Zugriff auf alle Tupel mit der Abteilungsnummer ∈ {1, ..., 20}; 

A 5 : Zugriff auf alle Tupel mit der Abteilungsnummer ∈ {21, ..., 37}; 

A 6 : Zugriff auf alle Tupel mit der Abteilungsnummer ∈ {37, ..., 50}. 

Die Relation ABTEILUNG sei geeignet (horizontal) zu partitionieren. Ermitteln Sie außerdem Ansätze für heuristische Gewichte unter 

der Annahme einer Gleichverteilung der Anwendungen. 

4. Integration von verteilten Systemen: Gegeben seien die folgenden Schemata A und B: 

TEIL_A(TeilNr, Bezeichnung, PreisDM, Lagerort) 

LIEF_A(TeilNr, LieferNr) 

TEIL_B(TeilNr, TeilBez, LiefNr) 

PREIS_B(TeilNr, PreisEuro) 

LAGERORT_B(TeilNr, Lagerort) 

Formulieren Sie die Abbildungen in das Schema 

TEIL(TeilNr, TeilBez, LiefNr, PreisEuro, Lagerort) 

und für einige ausgewählte Anfragen die Transformation. 

8.1.5 Verteilte Anfrage- und Transaktionsverarbeitung 

In diesem Kapitel behandeln wir die Auswirkungen der gewählten Verteilung auf die Funktionalität des Datenbanksystemes. Zuerst wird 

anhand der Anfrageberechnung aufgezeigt, mit welchen Mechanismen eine effiziente Berechnung von Anfragen in einem verteilten System 

erfolgen kann. Danach werden die Auswirkungen der Verteilung auf das Transaktionskonzept untersucht. 

Verteilte Anfragenbearbeitung. 

Zur optimalen verteilte Anfragebearbeitung wird eine Ausführungsplan in Abhängigkeit von der Datenverteilung bestimmt. Kostenfaktoren 

sind Übertragungskosten (Nachrichtenanzahl, Nachrichtenumfang), I/O-Kosten, die Geschwindigkeit insbesondere Antwortzeiten und 

ggf. CPU-Bedarf und Hauptspeicherbedarf. Zur Auswahl der optimalen Strategie sind eine Reihe von Entscheidungen zu treffen: 

◦ Anfrage-Zerlegung in lokal ausführbare Teilanfragen; 

◦ Ausführungsreihenfolge für Selektion, Projektion und Join; 

◦ Nutzung von Indexstrukturen; 

◦ Parallelisierung von Teilanfragen; 

◦ Auswahl der globalen und lokalen Join-Strategie (Nested-Loop, Sort-Merge, 

Hash-Join); 

◦ Rechnerauswahl, z. B. zur Join-Berechnung; 

◦ Auswahl der Replikate. 

Diese Entscheidungen können schrittweise getroffen werden, so daß ein Phasenmodell zur Berechnung nach Bild 51 realisiert werden kann. 

Das Phasenmodell mündet in folgende Schrittfolge: 

1. Prüfung der Anfrage auf syntaktische und semantische Korrektheit;


globale Anfrage 

Dialekt der DB-Sprache 

globales Schema 

Verteilungsschema 

globale Statistiken 

lokales Schema 

✲ 

✲ 

✲ 

✲ 

✲ 

❄ 

Anfrage-Parsing 

validierte globale 

❄ 

Anfrage 

Anfragetransformation 

algebraischer 

❄ Ausdruck 

Daten-Lokalisierung 

Partition- 

❄ 

Ausdruck 

globale Optmierung 

global optimierter 

❄Partition-Ausdruck 

lokale Optimierung 

❄ 

optimierte lokale Anfrage 

Abbildung 32: Phasen der verteilten Anfragebearbeitung 

2. Transformation globaler Anfragen in lokal ausführbare Anfragen mit algebraischen Termersetzungstechniken; 

3. Lokalisierung der Daten in den einzelnen Knoten; 

4. Vereinfachung der Anfrageausdrücke mit Methoden der algebraischen Optimierung, z. B. Vereinfachung von Algebra-Ausdrücken und 

Elimination redundanter Teilausdrücke; 

5. Bestimmung der Berechnungsverfahren für Operationen, insbesondere des Verbundes; 

6. Bewertung und Auswahl von Ausführungsstrategien mit den Kostenparametern, ggf. Abschätzung von Zwischenergebnisgrößen und 

einem Abwägen zwischen Funktionsexport und Datenexport. 

Wünschenswert - aber nicht immer realistisch - ist dabei auch eine Berücksichtigung des aktuellen Systemzustandes zur Laufzeit. 

In der Phase der Anfragetransformation wird 

• eine Interndarstellung für die Anfrage (z. B. in der Relationenalgebra) erzeugt, 

• eine Namensauflösung anhand des globalen Schemas ausgelöst, 

• die Anfrage semantisch analysiert, 

• die Anfrage normalisiert und 

• algebraisch vereinfacht unter Benutzung der Äquivalenzregeln der Operationenalgebra. 

Da die Anfragen in SQL oder einer anderen DBMS-Sprache formuliert sind, müssen sie zuerst aufbereitet werden. Es wird dazu eine 

Transformation in die interne Sprache vorgenommen. In relationalen Systemen ist dies eine Variante der relationalen Algebra. 

In der Namensauflösung werden die logischen Objektnamen internen Bezeichnern zugeordnet. Im verteilten Fall werden ggf. Synonymtabellen 

und die Katalogdaten verwendet. 

Mit einer semantischen Analyse wird geprüft, ob die verwendeten Relationen und Attribute im globalen Schema definiert sind. Sind die 

Operationen auf Sichten spezifiziert, dann wird eine Anfrageexpansion durchgeführt, um die Anfrage auf die Basisrelationen zurückzuführen. 

Außerdem erfolgt die Überprüfung von Integritätsbedingungen. 

In der Normalisierungsphase wird die Anfrageklausel in eine konjunktive Normalform überführt. Dazu werden die Gleichungen der 

Booleschen Algebra benutzt. 

Meist können die entstandenen Ausdrücke vereinfacht werden. Dazu werden die Äquivalenzregeln der relationalen Algebra in der Anfrageoptimierung 

angewandt. Typische Regeln sind z. B. die folgenden: 

• Der Verbund ist kommutativ, assoziativ, 

monoton, d. h. R ⊆ S ⇒ R ✶ T ⊆ S ✶ T , 

absorbtiv, d. h. R ⊆ R ′ ⇒ R ✶ R ′ = R und 

idempotent, d. h. R ✶ ∅ = ∅ , 

R ✶ S = R × S falls R ∩ S = ∅ und 

R ✶ S = R ∪ S falls R = S.


• Verbund und Selektion können miteinander vertauscht werden: 

⎧ 

⎨ σ A=c (R) ✶ S 

σ A=c(R ✶ S) = σ A=c(R) ✶ σ A=c(S) 

⎩ 

R ✶ σ A=c (S) 

falls A ∈ R \ S 

falls A ∈ R ∩ S 

falls A ∈ S \ R 

• Alle Tupel einer Relation können wiederhergestellt werden durch Verbund einer vertikal zerlegten Relation, d. h. 

für ∪ k i=1X i = R 

• Tupel in der Projektion des Verbundes sind in der Komponente des Verbundes enthalten: π Xj (✶ k i=1 R i) ⊆ R j. 

• Gilt für eine Relation R =✶ k i=1 π Xi (R) , dann gilt die Verbundabhängigkeit (X 1 , ...X k ) in R . 

• Projektion und Verbund können vertauscht werden, wenn die gemeinsamen Attribute in der Projektion verwendet werden: 

S) = π X(R) ✶ π X(S) falls R ∩ S ⊆ X. 

• Selektion und Verbund können vertauscht werden: π X(σ A=c(R)) = σ A=c(π X(R)) falls A ∈ X ∩ R. 

• Projektionen können zusammengefaßt werden: 

π X(π Y (R)) = π X∩Y (R). 

• Die verallgemeinerte Vereinigung ist kommutativ, idempotent, monoton, assoziativ, distributiv mit Verbund. 

• Die Selektionen σ A=c, σ A≠c definieren eine Partition. 

• Selektionen können einzeln bearbeitet und zusammengefaßt werden: 

σ X=Y (R) = σ A1 =B 1 

(σ A2 =B 2 

(...σ Am=B m (R)...)) für X = A 1 , ...A m , Y = B 1 , ..., B m . 

• Der Quotient zweier Relationen genügt der Gleichung 

R/S = π R\S (R) \ π R\S ((π R\S (R) ✶ π R∩S(S)) \ R). 

Außerdem gilt für den Quotienten (R ✶ S)/S = R falls R ∩ S = ∅ . 

R ⊆✶ k i=1 π Xi (R) 

π X (R ✶ 

Diese Regeln können als Termersetzungsregeln benutzt werden. Analog kann man den Operatorenbaum wie in Bild 50 umwandeln. Meist 

werden auch Heuristiken angewandt wie z. B. 

frühzeitige Ausführung von Selektionsoperationen; 

frühzeitige Durchführung von Projektionen (ohne Duplikateliminierung); 

Zusammenfassung mehrerer Selektionen und Projektionen auf demselben Objekt; 

Bestimmung gemeinsamer Teilausdrücke. 

So wird z. B. die Anfrage ‘Gesucht sind die Teilenummern aller Teile aller Lieferanten, deren Namen mit A beginnt, und deren Preis 

zwischen 10 und 20 Einheiten liegt!’ durch die SQL-Anfrage 

select TeileNr 

from TEILE, LIEFERANT 

where TEILE.LiefNr = LIEFERANT.LiefNr 

Preis < 20 and Preis > 10 and 

LiefName like ’A%’ 


angedrückt, die in den algebraischen Ausdruck 

π T eileNr (σ P reis>10∧P reis10∧P reis


Horizontale Partitionierung: Durch Verbund-Berechnung bei horizontaler Partitionierung wird ein reduzierter Kommunikations- und Verarbeitungsumfang 

für Joins auf Partitionierungsattribut erreicht. Parallele Verbund-Berechnungen ersparen aufwendige Transfers. 

Gegeben sei z. B. eine Partititionierung von R und S in R 1 , R 2 , R 3 und S 1 , S 2 . Dann kann ein Verbund R ✶ S berechnet werden 

durch (R 1 ∪ R 2 ∪ R 3 ) ✶ (S 1 ∪ S 2 ) . Durch Ausmultiplizieren erhalten wir den Ausdruck 

(R 1 ✶ S 1) ∪ (R 1 ✶ S 2) ∪ (R 2 ✶ S 1) ∪ (R 2 ✶ S 2) ∪ (R 3 ✶ S 1) ∪ (R 3 ✶ S 2). 

Dieser Ausdruck erscheint auf den ersten Blick komplexer, erfordert jedoch weniger Kommunikation zu seiner Berechnung. 

Sind die Partitionen auf unterschiedliche Knoten disjunkt verteilt, dann wird dieser Ausdruck wesentlich einfacher. Sind z. B. die 

Objekte in R i, S j nach gleichen Selektionsprädikaten partitioniert, z. B. R 1 = σ α(R), R 2 = σ β1 (R), R 3 = σ β2 (R) und S 1 = 

σ α (S), S 2 = σ β1 ∨β 2 

(S), dann kann der obige Ausdruck vereinfacht werden zu 

(R 1 ✶ S 1) ∪ (R 2 ✶ S 2) ∪ (R 3 ✶ S 2). 

In analoger Art können auch die anderen Operationen der relationalen Algebra den Partitionen zugeordnet werden. 

Abgeleitete horizontale Partitionierung: In ähnlicher Form kann eine noch weitergehende Optimierung für die abgeleitete horizontale Partitionierung 

ereicht werden, indem die Partitionierung der referenzierten Relation zu einer Partitionierung der referenzierenden Relation 

führt. In diesem Fall wird der algebraische Ausdruck ebenso vereinfachbar sein wie im Falle der horizontalen Partitionierung. 

Vertikale Partitionierung: Die Partitionen sind durch Projektionsausdrücke definiert. Damit können Äquivalenzen, die für die Projektion 

gelten in analoger Form benutzt werden, um lokal ausführbare Ausdrücke aus den Anfrageausdrücken zu berechnen. 

Ein Parallelausführung kommt nur in sehr eingeschränktem Umfang zum Zuge. Durch eine geschickte Transformation ist allerdings 

oft eine Reduktion der Zwischenergebnisgrößen möglich und damit eine einfachere Berechnung. 

Nach einer Berechnung der lokal ausführbaren Ausdrücke kann auch ein Reduktionsschritt initiiert werden, bei dem überflüssige Teilausdrücke 

entfernt werden. Außerdem können überdeckte Ausdrücke entfernt werden. Dabei werden im Falle der horizontalen Partitionierung die 

Zerlegungsprädikate mitbetrachtet. Es wird dann für die lokalen Ausdrücke berechnet, ob diese Ausdrücke ggf. in der Partition zu einer leeren 

Menge führen. 

Problematisch sind Aggregationsfunktionen. Sind die Partitionen nicht disjunkt, dann kann sowohl bei der Summierung als auch bei der 

Ermittlung der Tupelanzahl durch Duplikate ein Fehler auftreten. Damit sind nur die Minimum-Funktion und die Maximum-Funktion lokal 

berechenbar. I. Allg. sind die Summe, die Tupelanzahl und die Average-Funktion nicht lokal berechnbar, wenn keine echte Partition vorliegt. 

Falls eine Duplikat-Eliminierung notwendig ist, dann muß i. Allg. das Resultat global ermittelt werden. 

Im obigen Beispiel nehmen wir an, daß die Datenbank partitioniert wurd nach Lieferantenorten. Demzufolge kann diese Anfrage nur 

berechnet werden durch eine Vereinigung aller Partitionen. Wir nehmen außerdem an, daß damit eine Partitionierung von TEILE impliziert ist. 

Damit wird der Ausdruck 

π T eileNr (σ P reis>10∧P reis10∧P reis10∧P reis10∧P reis


Kostenfunktionen können wesentlich genauer durch das Einbeziehen von Statistiken spezifiziert werden. Die obigen Eingangsgrößen 

bestimmen im Wesentlichen den Kommunikationsaufwand. Damit ist die Selektivität eine wesentliche Eingangsgröße. Die Seleketivität Sel 

eines algebraischen Ausdrucks E der über einer Relation R definiert ist (Verbund, Selektion, Projektion, komplexe Ausdrücke), ist bestimmt 

durch 

Sel(E) = |E(R)| 

|R| 

Da diese Größe stark von der augenblicklichen Größe der Relation abhängt, werden Schätzungen verwendet, die eine ungefähre Kenntnis der 

Verteilung der Werte in dom(A) für die Attribute A voraussetzen. Setzt man z. B. eine Gleichverteilung der Werte und die Unabhängigkeit 

der Attributwerte innerhalb eines Tupels voraus, dann gelten 

Sel(σ A>a) ≈ 

Sel(σ A


Filterstrategien: (hash-filter join) Der Ansatz ist dem vorhergehenden Ansatz sehr ähnlich. Es wird auch hier eine verteilte Berechnung 

erfolgen. Der Datentransfer ist damit reduziert. Im Unterschied allerdings wird nicht die komplete Verbundrelation gesandt, sondern 

nur ein Bitvektor, der anzeigt, welche der möglichen Werte in dom(A) in den Relationen auftreten. Der Bitvektor kann noch kleiner 

gehalten werden, wenn er mittels einer Hashfunktion erzeugt wird. Existiert ein Wert nicht in der Relation, dann tritt er auch nicht unter 

den Hashwerten auf. Aufgrund der Doppeltbelegung kann aber ggf. auch die Existenz eines Wertes in der Relation angezeigt werden, 

für den ein entsprechender Wert mit dem gleichen Hashwert in der Relation existiert. 

Wird z. B. h(x) = xmod7 über dem Wertebereich {0, ..., 13} gewählt, dann zeigt der Bitvektor (0101011) für die Werte (6, 5, 4, 3, 2, 1, 0) 

an ,daß 5 oder 12, 3 oder 10, 1 oder 8 und 0 oder 7 in der Relation auftreten. Erhält der Knoten K S einen Bitvektor vom Knoten K R , 

dann kann er mit dem eigenen Bitvektor nicht verbindbare Tupel aussortieren und nur die Tupel an K R senden, für die möglicherweise 

ein Tupel in R existiert. 

In einem abschließenden fünften Schritt wird die lokale Optimierung durchgeführt. Diese wird nach den Optmierungsprinzipien durchgeführt, 

die auch für zentrale DBS gelten. Wir verweisen auf die Optmierungsverfahren in den anderen Lektionen. 

Verteilte Transaktionsverwaltung. 

Auch im Falle verteilter DBS sollten die ACID-Eigenschaften von Transaktionen gewahrt sein: 

• Atomarität (atomicity): Es wird die Transaktion entweder volständig wirksam oder gar nicht. Die Atomarität wird durch Commit- 

Protokolle unterstützt. 

• Konsistenz (consistency): Startet die Transaktion in einem Zustand, in dem alle Integritätsbedingungen gelten, dann sollen diese auch 

nach Abschuß der Transaktion gelten. Mit verteilten DBS kann auch eine verteilte Überwachung von Integritätsbedingungen z. B. 

bei partitionierten Relationen realisiert werden. Die Integritätssicherung erfordert außerdem auch ggf. eine Ausführung verzögerter 

Integritätsbedingugnen im Rahmen eines erweiterten Commit-Protokolles. 

• Isolierte Zurücksetzbarkeit (isolation): Wird eine Transaktion ausgeführt oder auch zurückgesetzt, dann sind davon die anderen 

Transaktionen nicht betroffen. Die Isolation von Transaktionen wird durch eine Synchronisation der Ausführung von Transaktionen 

gewährleistet. Dabei entstehen auch rechnerübergreifende Abhängigkeiten und spezifische Blockierungen (deadlocks). 

• Dauerhaftigkeit (durability): Das Ergebnis einer Transaktion wird dauerhaft in die Datenbank eingebracht, sobal sie akzeptiert ist. 

Durch Logging und Recovery wird eine Robustheit gegenüber partiellen Fehlern, insbesondere Kommunikationsfehlern (z. B. Netzwerkpartitionen) 

gewährleistet. Im Kontext verteilter DBS wird dabei als Neuerung das globale Commit-Protokoll eingeführt. Commit-Protokolle 

sollen die Atomarität verteilter Transaktionen durch rechnerübergreifenden Mehr-Phasen-Abgleich sicherstellen. An ein Commit-Protokoll 

stellen wir deshalb Anforderungen wie 

◦ Korrektheit, 

◦ geringer zusätzlicher Aufwand (Nachrichten, I/O), 

◦ geringe Antwortzeitverlängerung, 

◦ Robustheit gegenüber von Rechnerausfällen und Kommunikationsfehlern und 

◦ weitgehende lokale Autonomie. 

Jeder an einer verteilten Transaktionsausführung beteiligte Rechner soll möglichst lange das Recht auf einseitigen Transaktionsabbruch haben. 

Wir werden unten als wesentliche Alternativen drei Commit-Protokolle behandeln. 

Wir unterscheiden im weiteren zwischen ‘lokalen’ Transaktionen und ‘globalen’ Transaktionen. Globale Transaktionen bestehen i.d.R. 

aus mehreren Teiltransaktionen, die bestimmte Teilaufgaben übernehmen. Erzeugt eine Teiltransaktion T eine weitere Teiltransaktion T ′ , 

dann wird T ′ auch als Subtransaktion bezeichnet. Meist übernimmt die Teiltransaktion des ‘Startknotens’ die Steuerung des Ablaufs der globalen 

Transaktion. Sie hat damit die Aufgabe, Subtransaktionen zu initiieren, die Ergebnisse zu sammeln, Fehlernachrichten auszuwerten, 

eine Commit-Behandlung (z. B. mit einem Zwi-Phasen-Commit-Protokoll) durchzuführen und ggf. auch Recovery-Maßnahmen einzuleiten. 

Existiert eine derartige Steuertransaktion, dann wird diese auch als Primärtransaktion (primary transaction, master transaction) und der Startknoten 

als Primärknoten (primary site, master site) bezeichnet. In zukünftigen Systemen werden auch geschachtelte Transaktionen unterstützt. 

Damit kann auch ein isoliertes Rücksetzen von Subtransaktionen erfolgen, eine transaktionsinterne Synchronisation zwischen den Teiltransaktionen 

und eine Parallelausführung von Teil- und Subtransaktionen. Geschachtelte Transaktionen können durch einen Transaktionsbaum, der 

die Aufrufbeziehungen darstellt, visualisiert werden. 

Wir können im Wesentlichen vier Formen der Ausführung von Transaktionen unterscheiden: 

Entfernter Programmaufruf: Im Anwendugnsprogrmm wird ein anderer Knoten explizit spezifiziert. Das DB-Programm wird auf dem anderen 

Knoten ausgeführt. Der Aufruf wird dabei komplet abgeschlossen. Es gibt keine systemseitige Fortpflanzung des Aufrufs an 

andere Knoten. 

Entfernte Ausführung einer Transaktion: Die komplette Transaktion wird auf einen anderen Knoten ausgeführt. Die entfernte Transaktion 

wird jeweils komplett abgeschlossen. Es gibt keine systemseitige Fortpflanzung der entfernten Transaktion. Voraussetzung für dieses 

Konzept ist, daß der andere Knoten das Transaktionskonzept unterstützt. Dieser Knoten wird im Anwendungsprogramm explizit 

angegeben. Das Konzept wird in Bild 34 illustriert. 

Entfernt ausgeführte Teil-Transaktionen: Die globale Transaktion wird in Teil-Transaktionen zerlegt. diese werden dann auf den anderen 

Knoten ausgeführt. Die Ausführung einer Teil-Transaktion ist bedingt. Es erfolgt keine Fortpflanzung der Teiltransaktionen auf andere 

Knoten, d. h. es existieren keine Sub-Transaktionen. Für den lesenden Zugriff ist diese Vorgehensweise kein Problem. Anders ist 

dies dagegen für Änderungen. Es kann zu Konflikten kommen. z. B. wird mit dem partiellen Commit der Teil-Transaktionen kein 

Commit der gesamten Transaktion erzwungen. Damit können bei einem Systemfehler oder Transaktionsabbruch beim Primärknoten


Anwendungsprogramm 

BeginOfTransaction 

execute 

3 

3 

✾ 

ok 

execute 

3 

✾ 

ok 

commit 

3 

❄ 

✾ 

ok 

Zeit Knoten A Knoten B 

Abbildung 34: Entfernte Ausführung einer Transaktion 

Konflikte entstehen, die es mit einem zusätzlichen Nachrichtenaustausch zu beheben gilt. Es werden Nachrichten ‘prepare-to-commit’ 

und ‘ready-to-commit’ zwischen den Rechnern ausgetauscht. Das in Bild 35 dargestellte Protokoll erlaubt mit einer zusätzlichen 

Kommunikation eine korrekte Ausführung. 


BeginOfTransaction ✲ 

execute ✲ 

✛ ok 

prepare to commit ✲ 

✛ready to commit 

✲ 

✛ 

✛ 

BeginOfTransakction 

execute ✲ 

ok 

prepare to commit ✲ 

ready to commit 

❄ 

commit 

✲ 

commit 

✲ 

Zeit Knoten A Knoten B Knoten C 

Abbildung 35: Ausführung eines Zwei-Phasen-Commit-Protokolls durch Anwendungsprogramm 

Verteilte globale Transaktionen: Verteilte Transaktionen verhalten sich gegenüber den Anwnedungsprogrammen wie eine gewöhnliche 

Transaktion. Die Transaktion wird DBMS-seitig zerlegt in Teil-Transaktionen. Das Anwendungsprogramm kennt diese Zerlegung 

nicht. Die Teil-Transaktionen werden entfernt ausgeführt. Sie sind transparent für das Anwendungsprogramm. Die Teil-Transaktionen 

können ggf. fortgepflanzt werden auf andere Knoten. auch dies bleibt unsichtbar für das Anwendungsprogramm. Die Durchführung 

dieses Protokolls wird in Bild 36 dargestellt. Ein Commit-Protokoll kann in unterschiedlicher Form verwaltet werden. 

• In einer zentralisierte Commit-Struktur verwaltet die Primärtransaktion die Abstimmung mit allen anderen Teil- und Sub- 

Transaktionen. 

• In einer hierarchischen Commit-Struktur wird die Verwaltung der Sub-Transaktionen den Teil-Transaktionen überlassen.



BeginOfTransaction T 

BeginOfTransaction✲ 

T1 

execute ✲ 

execute ✲ 

BeginOfTransaktion T2 ✲ 

execute ✲ 

execute ✲ 

prepare to commit T1 ✲ 

prepare to commit T2 ✲ 

✛ready to commit 

✛ 

ready to commit 

commit T1 ✲ 

commit T2 ✲ 

CommitTransaction T 

❄ 

Zeit Knoten A Knoten B Knoten C 

Abbildung 36: Ausführung eines Zwei-Phasen-Commit-Protokolls durch verteiltes DBMS 

• In einer linearen Commit-Struktur wird die Verwaltung jeweils den Teil-Transaktioß-nen weitergegeben, so daß eine Kette von 

Teil-Transaktionen entsteht. 

Die Commit-Struktur hängt im Wesentlichen von der Bekanntheit der Allokation und Partitionierung ab. Ist diese Information vollständig 

vorhanden, dann ist eher ein flacher Transaktionsgraph sinnvoll. Ist die Information über die Partitionierung und die Allokation dagegen 

nicht vollständig, dann empfehlen sich eher tief geschachtelte Commit-Strukturen, meist hierarchisch jedoch. 

Die Abort-Nachrichten gehen nur an die Teil-Transaktionen, die nicht mit Failed gestimmt haben. Ein Problem beim Zwei-Phasen- 

Commit-Protokoll ist die relative lange Blockieurng im Falle eines Primärknotenausfalls. 

Die Knoten haben unterschiedliche Zustände. Am Primärknoten, ebenso wie an den koordinierenden Teilknoten werden die folgenden 

Zustände angenommen: 

• initial (als Beginn-Zustand der Transaktion mit dem Nachfolgezustand ‘wait’), 

• wait (als Warte-Zustand auf die Nachrichten der Teil-Transaktionen mit den Nachfolgezuständen ‘aborting’ und ‘committing’), 

• aborting (falls ein Failed oder TimeOut empfangen wurde mit dem Nachfolgezustand ‘terminated’), 

• committing (falls von allen Teil-Transaktionen ein ‘ready’ empfangen wurde mit dem Nachfolgezustand ‘terminated’) und 

• terminated (als Endzustand). 

Die Teilknoten realisieren dagegen die Zustände 

• wait (auf einen Eröffnungsdialog mit den Nachfolgezuständen ‘prepared’ und ‘abort’), 

• prepared (falls eine Prepare-Nachricht vom Vater empfangen wurde, auf das mit Ready geantwortet wird, mit ‘aborted’ oder 

‘committed’ als Nachfolgeknoten) 

• aborting (falls ein Abort oder TimeOut empfangen wurde mit einem Aussenden eines Failed an den Vaterknoten) und 

• committing (falls Commit empfangen wurde mit einer Antwort als Bestätigung des Zustanddes an den Vaterknoten). 

Das hier vorgestellte Zwei-Phasen-Commit-Protokoll bedarf noch weiterer Verfeinerungen, einer speziellen Log-Datei und entsprechender 

TimeOut-Verwaltung. 

Werden mehrere Transaktionen konkurrierend auf den gleichen Ressourcen ausgeführt, dann muß auch für verteilte DBS eine Unterstützung 

für die Konsistenzpflege realisiert werden. Wie auch im Falle zentraler DBS können inkonsistentes Lesen, verlorengegangene Änderungen 

und Verletzungen der Konsistenz der Daten auftreten. Aus diesem Grund muß eine konsistenzbewahrende Änderung des Datenbankzustandes 

unterstützt werden. 

Bei Transaktionen, die auf mehreren Rechnern verteilt sind reicht es nicht aus, wenn die Transaktionen jeweils lokal serialisierbar sind. 

Die Transaktionen in Bild 37 sind lokal serialisierbar, nicht aber global. Die lokalen Abhängigkeitsgraphen der Transaktionen (Knoten A: 

T 1 → T 2 und Knoten B: T 2 → T 1) ergeben den globalen Serialisierungsgraphen 

T 1 

→ ← T 2 . 

Es ist zyklisch, damit ist eine Ausführung mit dem Plan von Bild 37 nicht sinnvoll. 

Eine Lösung ist die Serialisierung paralleler globaler Transaktionen mit einer erweiterten Verwaltung von Sperren, insbesondere für die 

lokalen DBS. Globale und lokale Transaktionen können Änderungen anderer globaler Transaktionen erst dann ‘sehen’, wenn diese das globale 

Commit abgeschlossen haben. Findet das globale Commit einer Transaktion T zeitlich vor dem globalen Commit einer anderen Transaktion 

T ′ statt, dann müßte in einer äquivalenten seriellen Ausführungsreihenfolge T 1 vor T 2 ausfgeführt werden.


Knoten A 

Schritt T 1 

1. r(A) 

2. 

T 2 

w(A) 

Knoten B 

Schritt 

3. 

4. 

T 1 

r(A) 

T 2 

w(A) 

Abbildung 37: Lokal serialisierbare Transaktionen 

Das strenge Zwei-Phasen-Sperrprotokoll ist eine Verallgemeinerung des klassischen zentralen Sperrprotokolls. Eine Transaktion erwirbt 

global Sperren, die bis zum End-Of-Transaction gehalten und ‘auf einen Schlag’ global freigegeben werden. 

Die Sperrverwaltung kann lokal erfolgen z. B. für die Daten, die dem Knoten durch die Partition zugeordnet sind, oder global im System. 

Obwohl die Erkennung von Verklemmungen (deadlocks) einfacher im zweiten Fall ist, wird aus Performanzproblemen und aufgrund der 

Eingriffe in die lokale Autonomie der Knoten bei den Systemen die lokale Sperrverwaltung gewählt. Eine Transaktion, die am Knoten A 

ausgeführt wird, muß für die Daten, die auf dem Knoten B liegen, eine Sperre vom Knoten B erwerden. Verträglichkeiten der neuen Sperre 

mit bereits vorliegenden Sperren können lokal entschieden werden. 

Verklemmungen sind lokal nicht zu erkennen, wenn gleichzeitig Transaktionen nicht nur lokale Berechnungen erfordern. Ein Beispiel 

wird in Bild 38 dargestellt. Es können exklusive Sperren (lockX) oder Lesesperren (lockS; shared) angefordert werden. Exklusive Sperren 

Schritt 

Knoten A 

T 1 

T 2 

Schritt 

Knoten B 

T 1 

T 2 

0. 

1. 

2. 

6. 

BOT 

lockS(A) 

r(A) 

lockX(A) 

≀ ≀ ≀ 

3. 

4. 

5. 

7. 

BOT 

lockX(B) 

w(B) 

lockS(B) 

≀ ≀ ≀ 

Abbildung 38: Verteilte Verklemmung 

erlauben eine Modifikation der Daten. Lesesperren können durch mehrere Transaktionen gemeinsam benutzt werden. Wird eine Sperre angefordert 

obwohl das Objekt von einer anderen Transaktion bereits gesperrt ist, dann muß die Transaktion warten (≀ ≀ ≀). Im Beispiel setzen zwar 

die Transaktionen Sperren auf unterschiedlichen Objekten, aber am Knoten A wartet T 2 auf eine Freigabe durch T 1 . Am Knoten B ist dies 

umgekehrt. Wiederum erhalten wir die gegenseitige globale Abhängigkeit der beiden Transaktionen 

T 1 

→ ← T 2 . 

Die Sperren können in der Vorausschau berechnet werden. Dazu existieren drei Verfahren zur Erkennung von Verklemmungen: 

Zeitmarken: Nach Verstreichen von festgelegten Zeitintervallen werden Transaktionen, die in diesen Zeitintervallen keine weiteren Aktionen 

ausgelöst haben, zurückgesetzt. Zeitmarken müssen optimal bestimmt werden. Sind die Zeitmarken zu niedrig gesetzt, dann werden 

Transaktionen zu schnell zurückgefahren. Sind sie zu hoch, dann dann wird die Performanz der Anwendung durch lange Wartezeiten 

verringert. 

Zentrale Erkennung von Verklemmungen: Ein neutraler Knoten verwaltet die Wartebeziehungen der Transaktionen. Von Vorteil ist die 

einfache Berechnung der Wartegraphen. Nachteilig ist das hohe Nachrichtenaufkommen sowie die Entstehung von Phantom-Verklemmungen, 

die durch Laufzeiten von Nachrichten im System entstehen. 

Dezentrale (verteilte) Erkennung von Verklemmungen: Lokale Knoten führen ihre eigenen Wartegraphen, die um einen Knoten external 

erweitert werden. Es wird lokal eine Kante von external zu T i in den Wartegraphen eingefügt, falls eine Transaktion durch einen anderen 

Knoten auf diesen Knoten initiiert wurde (z. B. in Bild 38 die Kante external → T 2 für den Knoten A). Es wird eine Kante von 

T i zu external in den Wartegraphen eingefügt, falls die Transaktion auf einen anderen Knoten durch eine Sub- oder Teiltransaktionen 

weitergeführt wird (z. B. in Bild 38 die Kante T 1 → external für den Knoten A). Lokal kann nun in den Wartegraphen nach Zyklen gesucht 

werden. Existiert ein Zyklus, der external einschließt, dann wird der Wartegraph aus den externen Wartegraphen der assoziierten 

Knoten ergänzt indem dessen Wartegraph in den aktuellen aufgenommen wird. Damit erhalten wir im Beispiel für den Knoten B 

external → ← T1 → ← T2 → ← external . 

Damit liegt ein Zyklus vor, der ohne den Knoten external auskommt. Dieser Zyklus signalisiert eine Verklemmung. Deshalb können 

die Transaktionen T 1 und T 2 nicht parallel verarbeitet werden.


Die Erkennung von Verklemmungen kann eine sehr komplexe Aufgabe werden. Deshalb hat die Vermeidung von Verklemmungen in 

verteilten Systemen eine größere Bedeutung als in zentralen. Zur Vermeidung von Verklemmungen werden im Wesentlichen die folgenden 

vier Verfahren angewandt: 

Optimistische Mehrbenutzersynchronisation: Nach Abschluß der Bearbeitung einer Transaktion wird eine Validierungsphase angeschlossen. 

Stellt sich an Ende der Bearbeitung heraus, daß die Konflikte mit anderen Transaktionen entstanden sind, dann werden die Konflikte 

gelöst, indem alle beteiligten Transaktionen zurückgesetzt werden. Es ist mit mehr Rücksetzungen zu rechnen. Dafür entstehen 

allerdiings keine Verklemmungen. Optimistische Verfahren gehen davon aus, daß Konflikte selten auftreten. 

Zeitstempel-basierte Synchronisation: Jedem Objekt O der Datenbank wird ein Lese- und ein Schreibzeitstempel rts(O), wts(O) zugeordent. 

Die Zeitstempel werden mit jeder Transaktion, die eine Lese- bzw. Schreiboperation durchführt, geändert. Anhand dieser 

Zeitstempel kann entschieden werden, ob die beabsichtigte Operation noch durchgeführt werden kann, ohne die Serialisierbarkeit zu 

veletzen. Falls dies nicht möglich ist, wird die Transaktion abgebrochen. Transaktionen selbst erhalten ebenfalls Zeitstempel ts(T ). Gilt 

ts(T ) < wts(O), dann ist ein Lesezugriff einer Transaktion T auf das Objekt O nicht zulässig. Ein Schreibzugriff einer Transaktion 

T ist unzulässig auf ein Objekt O, falls ts(T ) < max(wts(O), sts(O)) gilt. 

Wound/Wait: Die jüngeren Transaktionen warten auf die älteren. Fordert eine ältere Transaktion eine Sperre auf ein Objekt an, für das bereits 

eine jüngere Transaktion eine Sperre besitzt, dann wird die jüngere Transaktion abgebrochen. Damit entstehen keine Wartegraphen, 

sondern es wird ein Abbruch forciert. 

Wait/Die: Die älteren Transaktionen warten auf die jüngeren. Falls eine jüngere Transaktion eine Sperre auf ein Objekt anfordert, für das 

bereits eine Sperre durch eine ältere Transaktion existiert, dann wird die jüngere Transaktion abgebrochen. 

Dies Verfahren setzen eine eindeutige globale Identifikation der Transaktionen voraus. Um einfach Zeitpunkte von Transaktionen vergleichen 

zu können, wird eine Kodierung der Form lokale Zeit ⊕ KnotenID zur Identifikation von Transaktionen gewählt. Diese Identifikation setzt 

jedoch voraus, daß die Uhren der lokalen Systeme sehr gut aufeinander abgestimmt sind. 

In diesem Abschnitt haben wir Partitionen betrachtet. Im Falle von Replikaten wird die Lesegeschwindigkeit erhöht, die Änderungsgeschwindigkeit 

jedoch aufgrund der Konsistenzforderungen verlangsamt. Im Falle von Änderungen sind auch Schreibsperren auf allen Kopien 

zu setzen, wodurch ein Verfügbarkeitsproblem entsteht, weil bei Ausfall eines Knoten alle entsprechenden Transaktionen warten müssen. Dies 

kann behoben werden durch entsprechende unschärfere Verfahren wie z. B. das Quorum-Consensus-Verfahren. Eine Transaktion muß bereits 

zum Lesen ein Minimum an Sperren anfordern von den Systemen. Analog werden auch Schreibsperren mit einer Mindestzahl belegt. Damit 

kann eine Ausfallsicherheit je nach Höhe des Quorum gewährleistet werden. 

Zusammenfassend erhalten wir damit Synchronisationsverfahren wie in Bild 39 visualisiert. 

Synchronisationsverfahren in verteilten DBS 

zentral 

verteilt 

Sperrverfahren 

optimistisch 

optimistisch 

Sperrverfahren 

Zeitmarken 

zentrale Verklemmungserkennung 

Vermeidung von 

Verklemmungen 

Wait/Die 

Wound/Wait 

zentral 

Erkennung von 

Verklemmungen 

verteilt 

Abbildung 39: Übersicht zu Synchronisationsverfahren 


Die folgenden Übungsaufgaben sollen die hier vorgestellten Konzepte anwenden. Es wird damit kontrolliert, inwieweit diese Konzepte verstanden 

worden sind. Diese Aufgaben sind vollständig zu lösen und stellen den Kern der Übungsaufgaben dar. 

1. Profile von Relationen: Gegeben seinen die globalen Relationen TEILE und LIEFERANT mit der zuvor verwendeten Partitionierung. 

Anstellen Sie gleichverteilte Attributwerte. Wählen Sie entsprechende Ausführungsstrategien für die Berechnung folgender Relationen 

aus: 

• R 1 := σ P reis=200 T EILE 

• R 2 := T EILE ✶ LIEF ERANT 

Beziehen Sie in die Begründung auch Schätzungen für die einzelnen Parameter mit ein.


2. Analogie des Zwei-Phasen-Commit-Protokolls: J. Gray - einer der geistigen Väter des Transaktionskonzeptes - hat die Analogie zwischen 

dem Zwei-Phasen-Commit-Protokoll und dem Ablauf einer Eheschließung herausgestellt. Bei der Eheschließung spielt der 

Standesbeamte bzw. Priester die Rolle des Primärknotens, und Braut und Bräutigam die Rolle der Sekundärknoten. Beschreiben Sie 

im Detail diese Analogie. 

3. Unsicherheit des Zwei-Phasen-Commit-Protokolls: Das Zwei-Phasen-Commit-Protokoll ist nicht sicher für beliebige Knotentopologien. 

Zeigen Sie, daß es sicher für lineare Commit-Strukturen ist. 

4. Zeitstempelverfahren: Man begründe die Unzulässigkeit von Lese- bzw. Schreibzugriffen von Transaktionen auf Objekte. Warum erlaubt 

das oben beschiebene Verfahren einen korrekten Ablauf der Transaktionen?


8.2 Vom 3K-Modell und anderen Modellen hin zu DistLang 

Wir werden uns hier auf eine spezifische Form der Kollaboration konzentrieren: das 3K-Modell in Bild 40. 

Koordination 

Kommunikation 

Kooperation 

Abbildung 40: Das 3K-Dreieck der Kollaboration 

Nach [?] 

Kommunikation: Unter Kommunikation versteht man einen verläßlichen und hinreichend schnellen Austausch von 

Informationsobjekten. 

Koordination: Koordination erfordert noch kein gemeinsames Ziel, jedoch gemeinsame Interessen und/oder organisatorische 

Zusammengehörigkeit. 

Kooperation: Kooperation bedingt eine starke Übereinstimmung von Zielen; die Gruppe ist als Ganzes für das 

Ergebnis verantwortlich. 

Begriffsbestimmungen (nach British Encyclopedia [SYea03]) 

Collaboration: Late Latin collaboratus, past participle of collaborare to labor together, from Latin com- + laborare 

to labor 

• to work jointly with others or together especially in an intellectual endeavor 

• to cooperate with or willingly assist an enemy of one’s country and especially an occupying force 

• to cooperate with an agency or instrumentality with which one is not immediately connected 

Communication: in a variety of facets 

• an act or instance of transmitting 

• information communicated or a verbal or written message 

• a process by which information is exchanged between individuals through a common system of symbols, 

signs, or behavior; 

also : exchange of information 

personal rapport 

• a technique for expressing ideas effectively (as in speech) 

the technology of the transmission of information (as by print or telecommunication) 

Coordination: Late Latin coordination-, coordinatio, from Latin co- + ordination-, ordinatio arrangement, from 

ordinare to arrange- more at ordain 

Cooperation: 

• the act or action of coordinating 

• the harmonious functioning of parts for effective results 

• the action of cooperating : common effort 

• association of persons for common benefit


Deutsche Begriffe dagegen: (Bibliographisches Institut & F. A. Brockhaus AG, 2003) 

Zusammenwirken: (Kollaboration is leider falsch belegt) 

gemeinschaftlich an der Lösung bestimmter Aufgaben arbeiten 

gutes, abgestimmtes, harmonisches Zusammenwirken 

collaboration hat drei Bedeutungen im Deutschen: mit-/zusammenarbeiten, behilflich sein, mit dem Feind kollaborieren 

Kommunikation: der Prozess des Zeichenaustausches zwischen Menschen (Humankommunikation), Tieren (animalische 

Kommunikation), innerhalb lebender Organismen (Biokommunikation) wie auch innerhalb oder zwischen 

technischen Systemen (technische Kommunikation, Maschinenkommunikation) beziehungsweise zwischen 

Mensch und technischem System (Mensch-Maschine-Kommunikation). Bei menschlicher Kommunikation handelt 

es sich um einen wechselseitigen Prozess der Bedeutungsvermittlung, um Interaktion. Als intentional gesteuerter 

Übertragungsvorgang erfolgt Kommunikation zwischen Personen oder Personengruppen (interpersonale 

Kommunikation), zwischen Mitgliedern von Organisationen, Institutionen und Verbänden (Gruppenkommunikation) 

oder durch die Zwischenschaltung eines technischen Verbreitungsmittels (mediengebundene 

Kommunikation, Massenkommunikation) bezeichnet. Elemente des Kommunikationsaktes sind Sender (Kommunikator, 

Quelle der Information), Empfänger (Adressat, Rezipient), Code (Sprache, Druck, Bild, Ton; Zeichenvorrat, 

Sprachschicht), Kanal (physischer Übertragungsweg, z.B. Sprache, Schallwellen, Schrift), Kontext 

(situationale Bestimmungsmomente) und Inhalt (Gegenstand der Kommunikation). Zum Kommunikationsprozess 

gehören Verschlüsselung (Encodierung), Übermittlung (Signalisierung) und Entschlüsselung (Decodierung, 

Interpretation). 

Koordination: Zuordnung, Beiordnung 

Kooperation: Zusammenarbeit 

Das 3K-Modell kann man zu einem Schichtenmodell verdichten: 

Cooperation 

Layer 

Cooperation space / workspace: workspace control, 

awareness, notifications, 

security over user functions 

Media object unit 

manager 

Coordination 

Layer 

Coordination space: operation management, 

session management 

shared resources management, users management 

Coordination and 

contracting system 

Communication 

Layer 

Communication space: (a)synchronous, 

multicast/broadcast, 

protocols, standard 

Communication 

support system 

Abbildung 41: Layers of a Typical Collaboration System 

Nach [?] 

Systemklasse Kommunikation: Kommunikationssysteme sind Systeme, deren Aufgabe darin besteht, den expliziten 

Informationsaustausch zwischen verschiedenen Kommunikationspartnern zu ermöglichen. Dabei werden in 

erster Linie Raum- und Zeitdifferenzen überbrückt. Typische Beispiele sind elektronische Post-Systeme und 

Videokonferenzen. Auch Bulletin Board Systeme können zu dieser Klasse gezählt werden, wenn geschlossene 

Gruppen adressiert werden. 

Systemklasse gemeinsame Informationsräume: Diese Klasse stellt gemeinsame Informationsräume für eine Gruppe 

zur Verfügung, in denen Informationen längere Zeit in geeigneter Form mit Hilfe geeigneter Zugriffsmechanismen 

gespeichert werden. Der Informationsaustausch ist implizit. In diese Klasse fallen verteilte Hyptertext


Systeme und spezielle Datenbanken, deren Informationen gleichzeitig von verschiedenen Benutzern abgefragt 

werden können. Bulletin Board Systeme können ebenfalls zu dieser Klasse gezählt werden. 

Systemklasse Workflow-Management: Ein Workflow ist eine endliche Folge von Aktivitäten, wobei die Folge von 

Ereignissen ausgelöst und beendet wird. Im allgemeinen sind Workflows organisationsweite, arbeitsteilige Prozesse, 

in die eine große Anzahl von Akteuren einbezogen sind. Workflow-Management umfasst alle Aufgaben, 

die bei der Modellierung , der Simulation sowie bei der Ausführung und Steuerung von Workflows erfüllt werden 

müssen. Workflow-Management-Werkzeuge unterstützen die Aufgaben des Workflow-Management durch 

die Ausführung von Software. Deren Unterstützungsfunktion besteht primär darin, Workflows auszuführen und 

zu koordinieren. Dazu werden unter anderem Techniken aus dem Bereich elektronischer Post-Systeme und spezielle 

Datenbanksysteme eingesetzt. 

Systemklasse Workgroup-Computing: Workgroup-Computing-Systeme unterstützen die Kooperation von Personen, 

die in Gruppen oder Teams arbeiten und Aufgaben mit mittleren bis geringen Strukturierungsgraden 

und Wiederholungsfrequenzen zu lösen haben. Die Koordinationsfunktion bezieht sich hier auf die für die 

Problemstellung notwendigen Kooperationsbeziehungen innerhalb der Gruppe. In diese Klasse gehören Planungssysteme 

wie Terminverwaltungs- und -vereinbarungssysteme, Gruppeneditoren und Entscheidungs- und 

Sitzungsunterstützungssysteme. 

8.2.1 Raum-Zeit-Matrix 

Die Raum-Zeit-Matrix geht auf Robert Johansen zurück und ist eine zweidimensionale Betrachtung von CSCW- 

Systemen: Einerseits wird davon ausgegangen, daß die Gruppenmitglieder, die ein Groupware-System einsetzen, 

räumlich verteilt arbeiten. Das heißt, es kommt darauf an, ob sie benachbart oder entfernt arbeiten; das kann vom 

gleichen Büro, über die gleiche Etage in einem Gebäude bis zu verschiedenen Kontinenten reichen. 

Andererseits spielt auch die zeitliche Verteilung eine Rolle: Arbeiten die Benutzer eines CSCW-Systems zur 

gleichen Zeit, oder zu verschiedenen Zeiten? 

In die Raum-Zeit-Matrix aus obiger Abbildung werden die CSCW-Systeme eingeordnet, was zunächst eine gewisse 

Übersichtlichkeit schafft. Bei genauerer Betrachtung stellt man jedoch schnell fest, daß einige Systemkategorien 

nicht eindeutig in eines der vier Felder eingeordnet werden können. Ein Beispiel hierfür sind die Gruppeneditoren, 

die es mit synchroner Funktionalität gibt, so genannte Realzeiteditoren, und auch in asynchroner Form, also Editoren 

mit Benachrichtigung. Darüber hinaus ist auch die räumliche Verteilung bei Gruppeneditoren nicht eindeutig, Gruppeneditoren 

stehen in der Regel geographisch benachbarten und entfernten Benutzern gleichermaßen zur Verfügung. 

Diese Klassifizierung darf nicht im Sinne einer Eingrenzung und Abgrenzung angesehen werden. Die einzelnen Kategorien 

können bestenfalls Systemkomponenten aufnehmen, da ein umfassendes CSCW-System den Anforderungen 

aller vier Quadranten genügen muß‘. 

Jonathan Grudin, heute Mitarbeiter bei Microsoft, erweiterte die Vier-Felder-Matrix von Johansen zu einer Neun- 

Felder-Matrix, indem er den zusätzlichen Parameter “Vorhersehbarkeit” einführte. Daraus ergibt sich für die geographische 

Komponente folgende Aufteilung: “Gleicher Ort”, “verschiedener Ort vorhersehbar” und “verschiedener Ort 

nicht vorhersehbar”. Bei der zeitlichen Komponente unterschied er analog nach “synchron”, “asynchron vorhersehbar” 

und “asynchron nicht vorhersehbar”. Damit ergibt sich folgende erweiterte Raum-Zeit-Matrix: 

Raum/Zeit gleiche Zeit (synchron) verschiedene Zeit (asynchron) 

vorhersehbar 

nicht vorhersehbar 

gleicher Ort face-to-face-Sitzung Schichtarbeit “schwarzes Brett” 

verschiedener Ort Videokonferenz E-Mail kollaboratives Verfassen 

vorhersehbar 

von Dokumenten 

verschiedener Ort Mobilfunkkonferenz Nicht-Realzeit- Vorgangsbearbeitung 

nicht vorhersehbar 

Konferenz 

Tabelle: Erweiterte Raum-Zeit-Matrix nach Grudin 

verschiedener Ort Video- E-Mail kollaboratives vorhersehbar konferenz Verfassen von Dokumenten verschiedener 

Ort Mobilfunk- Nicht-Realzeit- Vorgangs- nicht vorhersehbar konferenz Rechnerkonferenz bearbeitung


Die in obiger Tabelle dargestellte erweiterte Raum-Zeit-Matrix ist zwar auch übersichtlich, die angesprochenen 

Probleme, die Johansens Ansatz hat, sind aber auch hier zu sehen. Es gibt Groupware-Systeme, die sich in mehr 

als eine Kategorie einordnen lassen. Also ist auch die Grudin-Erweiterung nicht als Eingrenzung und Abgrenzung 

zu verstehen. Trotzdem ist die Raum-Zeit-Matrix das am häufigsten gebrauchte Klassifikationsschema, wenn an 

Universitäten Vorlesungen über rechnergestützte Gruppenarbeit gehalten werden. 

8.3 Anwendungsorientierte Funktionsklassen 

Einen anderen Ansatz als die Raum-Zeit-Matrix verfolgen die so genannten anwendungsorientierten Funktionsklassen. 

Diese Art der Klassifizierung ist auch für die vorliegende Arbeit interessant, denn ihr Hauptmerkmal ist, wie 

der Name bereits verrät, die Anwendungsorientierung. Deshalb passen die Funktionsklassen gut in das pragmatische 

Konzept, das diese Arbeit verfolgen soll. In [1] ist nachzulesen, daß Ellis et al. Anfang der 90er Jahre folgende 

Funktionsklassen unterschieden haben: Nachrichtensysteme, Gruppeneditoren, elektronische Sitzungsräume, Konferenzsysteme, 

gemeinsame Informationsräume, Agentensysteme und Koordinationssysteme. Diese Einteilung bildet 

die oberste Hierarchie und wird durch Unterkategorien konkretisiert. Etwa unterscheidet man bei den Konferenzsystemen 

folgende vier Unter-Arten: 

Nachrichtensysteme: Nachrichtensysteme sind für den asynchronen Nachrichtenaustausch zwischen Gruppenmitgliedern 

verantwortlich. Das sind meist Textnachrichten, aber auch Grafiken, Töne und Videos können bei 

einigen Systemen zwischen Sender und Empfänger ausgetauscht werden. Die Verwaltung von Nachrichten 

wird durch Strukturinformationen geregelt, etwa mittels einer Betreffzeile beim E-Mail-Versand. Die Erweiterung 

der Funktionalität eines Nachrichtensystems kann empfängerspezifisch oder absenderspezifisch erfolgen. 

Empfängerspezifisch bedeutet, daß der Empfänger bestimmte Regeln definiert, etwa eine Filterung nach Absenderadresse. 

Absenderspezifisch bedeutet, daß der Sender etwas spezifiziert und mit der Nachricht verschickt, 

man spricht dabei von so genannten Skripten. Nachdem der Empfänger die Nachricht erhalten hat, wird das 

Skript ausgeführt. Das könnte etwa eine Bestätigung über den Erhalt der Nachricht für den Absender sein, die 

automatisch nach Öffnen der Mitteilung zurückgeschickt wird. 

Gruppeneditoren: Gruppeneditoren werden dann eingesetzt, wenn mehrere Bearbeiter an einem gemeinsamen Dokument 

arbeiten. Auch für die gemeinsame Entwicklung eines Software-Systems sind Gruppeneditoren nötig. 

Dabei ist der Editor in der Lage, durch Benachrichtigungen die Benutzer auf dem aktuellen Stand der Bearbeitung 

zu halten. Die Benutzer werden also nicht voneinander isoliert. Bei den Realzeiteditoren arbeiten aktuell 

mehrere Benutzer am selben Dokument, dabei hat meist nur einer Schreibrechte, alle anderen Leserechte. Die 

asynchronen Editoren, oder auch Editoren mit Benachrichtigung genannt, verfügen über einen eingebauten 

Benachrichtigungsmechanismus, der über Änderungen informiert. 

Elektronische Sitzungsräume: Elektronische Sitzungsräume sind Sitzungsräume für so genannte face-to-face-Sitzungen, 

die mit Rechnern ausgestattet sind. Die Rechner werden dabei als Group Support Systems (GSS) eingesetzt, 

das bedeutet, sie helfen bei der Findung von Gruppenentscheidungen. Ein GSS faßt Meinungen, Zweifel und 

Einschätzungen zusammen und befragt die ganze Gruppe dazu. So kommt es iterativ zu einer gemeinsamen 

Entscheidung. 

Konferenzsysteme: Konferenzsysteme gibt es in vielen verschiedenen Ausprägungen, man unterscheidet Nicht- 

Realzeitrechnerkonferenz, Realzeitrechner-Konferenz, Telekonferenz und Desktopkonferenz. Bei der Nicht- 

Realzeitkonferenz erfolgt eine asynchrone Kommunikation. Oftmals wird dafür E-Mail verwendet. Das Konferenzsystem 

bereitet dann die Nachrichten entsprechend auf. Eine synchrone Rechnerkonferenz oder auch Realzeitrechnerkonferenz 

genannt, bietet die Möglichkeit des synchronen Datenaustausches, es besteht jedoch keine 

Audio- oder Video-Verbindung. Dies ist erst bei der Telekonferenz der Fall, wobei diese die Einschränkung 

hat, daß eine gemeinsame Bearbeitung von Daten nicht vorgesehen ist. Erst die so genannte Desktopkonferenz 

schafft die Verschmelzung von Realzeitrechnerkonferenz und Telekonferenz. 

Gemeinsame Informationsräume: Gemeinsame Informationsräume haben die Aufgabe, den Informationsschatz der 

Gruppe zu speichern und zu verwalten. Es gibt vier Kooperationsmodi, die bei der Bearbeitung gemeinsamer


Informationen unterschieden werden: Jedes Mitglied bearbeitet einen Teil unabhängig von den anderen (getrennte 

Verantwortlichkeit); zu einem Zeitpunkt hat immer nur genau ein Gruppenmitglied Vollzugriff (wechselseitig 

ausschließlicher Zugriff); jedes Mitglied entwickelt seine eigene Version der Dokumente (alternative 

Versionen); die Mitglieder können gleichzeitig arbeiten und es stehen geeignete Mechanismen zur konsistenten 

Datenhaltung zur Verfügung (synchroner Zugriff). 

Agentensysteme: Ein Software-Agent ist ein Programm oder Programm-Modul, das im Auftrag eines Benutzers bestimmte 

Aufgaben selbständig ausführen kann. In Bezug auf Groupware sind Agenten Software-Komponenten, 

die als Teilnehmer menschliche Gruppenmitglieder ersetzen. Sie übernehmen dabei bestimmte Rollen, etwa die 

Protokollierung einer Sitzung. Agenten agieren dabei normalerweise autonom, das heißt sie können auch ohne 

direkte Kontrolle durch einen menschlichen Benutzer agieren und kontrollieren ihren inneren Zustand selbst. 

Sie können außerdem mit anderen Agenten oder auch Benutzern kommunizieren. 

Koordinationssysteme: Koordinationssysteme oder auch Workflow-Management-Systeme werden zur Koordinierung 

von Arbeitsabläufen eingesetzt, dabei unterscheidet man vier Arten, abhängig von der modellierten Information: 

formularorientierte Systeme, prozedurorientierte Systeme, konversationsorierntierte Systeme und 

kommunikationsorientierte Systeme. 

8.3.1 DistLang 

• Formularorientierte Systeme lehnen sich an den guten alten Umlaufzettel an, der mit dem Dokument von 

Bearbeitungsstelle zu Bearbeitungsstelle wandert. Nach Ausführen von bestimmten Tätigkeiten wird auf 

einem Formular unterschrieben und das Dokument weitergegeben. Die Reihenfolge der Bearbeiter legt 

ein Ablaufplan fest. 

• Prozedurorientierte Systeme umfassen mehrere Schritte, die zum Ziel führen. Die kooperativen Tätigkeiten 

von Gruppenmitgliedern werden in einer Prozedurbeschreibung vorherbestimmt. 

• Konversationsorientierte Systeme modellieren die Interaktionen zwischen Gruppenmitgliedern. Die Kooperation 

basiert auf dem Austausch sprachlicher Äußerungen, die auf elektronische Nachrichten abgebildet 

werden. 

• Kommunikationsorientierte Systeme modellieren komplexe Kommunikationsstrukturen innerhalb einer 

Organisation. Diese Struktur drückt die Organisationsstruktur aus und beinhaltet Rollen. 

besteht aus 2 zentralen Komponenten 

Media-Objekt-Einheit: 

Austauschrahmen: 

8.4 Die Media-Objekt-Einheit 

Als Tripel 

(Media type, Unit Manager, Competence, Characteristics), i.e. 

S = (M, Man, C, F). 

analog zum Sharepoint-Konzept (MS) bzw. Konzepte von Workplace (IBM) 

Media types offer their own functions including statistical packages, functions proposed for data warehouses, or 

data mining algorithms. 

The unit manager Man supports functionality and quality of units and manages containers, their play-out and 

their delivery to the client. It is referred to as a units provider. 

The competence of a unit manifests itself in the set of tasks T that may be performed and the guarantees for 

their quality.


Raw 

media 

type 

Course 

insertion 

view 

Course 

negotiation 

view 

Extensions 

(unit/ 

order) 

Chair 

priority 

order 

Assistant 

order 

Media types Units manager Competence 

Co- 

/Adhesion 

Hierarchy 

Term 

order 

Coursecentered 

Workload 

order 

Cooperation 

Coursecentered 

Mac- 

XSL5 

Mozi- 

XSL5 

Daily 

refresh 

Weekly 

refresh 

Deliver 

only 

Exchange 

Playout Kind Communication 

Coordination 

Task 

None None Input 

main 

course 

data 

View 

others 

Unit characteristics F is based on properties that may be ordered on abstraction layers: 

QoS 

Select 

or insert 

Accept 

or reject 

Unit quality at business user layer are based on unit level agreements and the media types at this layer. 

Unit characteristics at conceptual layer describe properties the unit must provide in order to meet the unit level 

agreements. Further, functions available to the client at specified by their interfaces and semantic effects. 

Unit characteristics at implementation layer specify the syntactical interfaces of functions, the data sets provided 

and their behavior and constraints to the information system and to the client. 

Other 

assistants 

Assignment 

Characteristics 

Range 

of variation 

Responsible 

person 

Assistant 

at chair, 

assigned 

(course) 

Party Organization Context 

Inform, 

provide 

Insert 

new, 

select 

Own 

plan 

Dependent 

(chair) 

Linux, 

PC, 

browser 

Linux 

Negotiate 

Cooperate, 

ApproveBy 

(chair) 

Time 

slot 

[request, 

deadline] 

[request, 

meeting] 

Media 

types 

none none none Last 3 

terms 

lectures 

none 

colleagues 

∃!! 

assignment 

for 

chair 

Chair 

schedule 

Quality of unit Σ S is characterized depending on the abstraction layers: 

Roles Rights Relations 

Hierarchy 

Synchronization 

Coordination 

Environment 

Full 

History, 

profile, 

adaptation 

Quality parameters at business user layer may include ubiquity ( access unrestricted in time and space) and security 

(against failures, attacks, errors; trustworthy). 

Quality parameters at conceptual layer subsume interpretability (formal framework for interpretation) and consistency 

(of data and functions). 

Quality parameters at implementation layer include durability (access to the entire information unless it is explicitly 

overwritten), robustness (based on a failure model for resilience, conflicts, and persistency), performance 

(depending on the cost model, response time and throughput), and scalability (to changes in units, number of 

clients and servers). 

8.5 Austauschrahmen 

The different aspects of collaborating systems may be represented similar to Figure 41 and managed by data structures 

displayed in Figure 42. The external components, such as the work sessions and the session manager, belong to 

the coordination layer. They show how one coordination component can be linked to the components of the communication 

layer. The communication infrastructure interacts with the user interface and background processes through 

the event handler. The user buffer provides temporary storage of messages and is used for synchronization of data 

exchange. A number of basic features are provided for the channel management: 

Correct message delivery and receipt:


Agenda ✛ ✲ 

Scheduled in 

Item 

✛ 

Contribution 

✻ 

❄ 

Channel 

status 

Session 

manager 

✛ 

Work/meeting 

session 

✲ 

✒ 

User 

Channel 

buffer 

❫ 

✲ 

Channel 

✻ 

✠ 

✛ 

Event 

handler 

✲ 

Event 

handler 

kind 

❄ 

Message 

✛ 

Log 

File 

❄ 

Process 

✛ 

User 

interface 

Abbildung 42: The database diagram for communication/coordination infrastructure 

Message storage: 

Message distribution: 

Message persistence: 

A number of communication infrastructure pattern may be applied: 

Proxy pattern: 

Broker pattern: 

Client-dispatcher pattern: 

Forwarder-receiver pattern: 

Serializer pattern: 

Reactor pattern: 

Naming pattern: 

8.5.1 Allgemeine Architekturen kollaborativer Systeme 

Architektur Preprint S. 30 

Komponenten von Systemen können zum einem im Rahmen der Systemarchitektur zusammengestellt werden, wobei 

diese aus drei separierbaren Teilen bestehen kann: 

der Anwendungsarchitektur mit der Strukturierung des Systems aus der Sicht der Anwendung, 

der Technikarchitektur mit einer Beschreibung der Komponenten des Systems, die von der Anwendung unabhängig 

sind (Zugriffsschicht, GUI-Rahmen, Fehlerbehandlung, ...), 

Architektur der technischen Infrastruktur wie physische Geräte (Rechner, Netze, Peripherie,...), installierte 

Systemsoftware und das Zusammenspiel von HW und SW, Programmiersprachen


Standard-Anwendungsarchitekturen können insbesondere das Weiterentwickeln von Systemen extrem erleichtern. 

Standard-TI-Architekturen wie .NET, EJB mit Swing bzw. JSP (als Basis der GUI-Programmierung) 

Anwendungsarchitektur zur Spezifikation der funktionalen Komponenten der Anwendung 

• mit einer Übersicht über die Komponenten, deren Leistungsumfang, deren Daten (mit Anwendugnsfällen, 

Datenmodell, Nachbarsystemen) 

• mit einer Außensicht, in der die Schnittstellen auf der Ebene der Operationen beschrieben werden 

• mit einer Innensicht, die die konkrete Klassenstruktur, ... darstellt 

Technikarchitektur die auch der Anwendungsarchitektur folgen kann 

Techische-Infrastruktur-Architektur mit einer Darstellung der technischen Komponenten und deren Kommunikationsmodell 

(z.B. RMI, HTTP, CORBA) 

Komponenten erlauben ggf. auch Ausnahmezustände 

Jedes Komponentenobjekt besitzt Zustand und einen Konsistenzbegriff. 

Schnittstellen: mit der Spezifikation von 

• Angabe der Sichten zum Import/Export (oder bei anderen Ansätzen: Angabe der bereitgestellten Methoden) 

• Spezifikation der konkurrierenden Benutzung 

• ACID-Koordination 

• Abkommen zum wiederholten Lesen: 

• restricted repeatable read 

• unrestricted repeatable read 

• non-repeatable read 

• Invarianten 

• Vor- und Nachbedingungen 

• Testfälle 

• Fehler 

• Konstanzangaben 

• Kopplungsmodellen wie loose Kopplung, enge Kopplung, objektorientierte Kopplung oder diensteorientierte 

Kopplung 

Außerdem werden Schittstellen ggf. verfeinert, erweitert 

Verbindungen mit einem Kanalkonzept, ggf. Kanaleigenschaften 

Sichtweisen sind 

Konzeptionelle Sicht mit einer Grobarchitektur des Systems, seinen Komponenten 

Modul-Sicht 

Ausführungssicht 

Programmsicht 

Eine Architektur ist ausgeglichen, wenn alle unterschiedlichen Sichtweisen auf das System als Overlay- 

Schema über dem Grundschema dargestellt werden können 

Andere Sichtweisen sind: model driven architecture, model driven components


8.5.2 Architecture Description Language (ADL) 

Components that perform computation 

Connectors that express relationships (typically communication) between the components 

ADL 

Architecture Modeling Features 

Components 

Interface 

Types 

Semantics 

Constraints 

Evolution 


Connectors 

Interface 

Types 

Semantics 

Constraints 

Evolution 


Architectural Configurations 

Understandability 

Compositionality 

Refinement and traceability 

Heterogeneity 

Scalability 

Evolution 

Dynamism 

Constraints 


Tool Support 

Active Specification 

Multiple Views 


Refinement 

Implementation Generation 

Dynamism 

8.5.3 Kollaborationsraum 

Entwurf verteilter Informationssysteme 

Plug in and play 

Abeck/Lockemann/Schiller 

Übung:


8.5.4 Kollaborationsrahmen 



ggf. in der Spezifikation 

• Kommunikationsrahmen Preprint S. 154u 

• Koordinationsramhen Preprint S. 155u 

• Kooperationsrahmen Preprint S. 155m 

Kollaborationsstil Preprint S. 30 

8.6 Kommunikation auf der Grundlage von Sessions und Kontext 

Allgemeines Modell der concurrency 

Chu space: two-dimensional matrix whose rows indices represent events and the columns represent states 

A = (A, r, X) over the alphabet Σ, the carrier set A, the co-carrier set X and the function r : A × X → Σ 

constituting the interaction matrix 

Chu spaces are more general than Petri nets which yields a synchronization of two atomic actions rather than 

their concurrent execution 

Sitzungen zwischen Client und Server 

Kontext durch den Zustand der Kommunikation darstellbar 

8.6.1 Communication handles for representation of sessions 

similar to the treatment in Embedded SQL, O(pen) D(ata)b(ase) C(onnectivity), J(ava) D(ata)b(ase) C(onnectivity) 

Host embedding procedure: consisting of 

Blocks distinguishable by a precompiler (EXEC SQL 

Association rules for associating client namespaces to servers namespace (e.g. in Embedded SQL: declaration 

of host variables) and overcoming type mismatches (e.g., sets via cursor treatment) 

DECLARE cursor-name [INSENSITIVE] [SCROLL] CURSOR FOR table-expression 

[ORDER BY order-item-comma-list] 

[FOR {READ ONLY | UPDATE [OF column-list] } ] 

und Abbildungs- und Wertezuweisungsfunktionen, sowie Durchmusterungsfunktionen 

Executables that run through the application 

Status processing having 

Computation space for sessions in private, in shared or logged memory 

Diagnostics area 

Input space 

Output space 

Sessions, connections and transactions as a generalization of existing technology


Establish connection CONNECT TO { DEFAULT | db-name-string } 

[ AS connection-name-string ] [ USER user-id-string ] 

possibly with some default rules 

SET CONNECTION TO { DEFAULT | connection-name-string } 

Terminate connection DISCONNECT { DEFAULT | db-name-string } 

Execution environment for parallel execution of requests for instance with an isolation level 

8.6.2 Context for communication sessions 

Communicating entities maintains context information through a context block 

• sequence numbers of the messages transmitted in each direction (for reliably transmitting messages) 

• addressing information 

• encryption keys 

• current direction of communication 

8.6.3 Context for client/server sessions 

Context may be stored 

• either locally at the server 

• or globally in the context database 

• or locally at the client 

Typical concept: context handle 

e.g. cookie 

8.6.4 Guaranteed properties 

Typical properties: 

• Global atomicity and isolation 

• Load balancing and routing 

• Recoverable queues 

• Security properties 

• Threading 

• Supporting servers 

• Nested transactions 

z.B. mit Transaction processing monitors 

oder auch durch Web application servers J2EE mit session beans, entity beans, message-driven beans, die durch 

EJB container gestützt werden


8.6.5 Communication Diagrams and Channels 

nach Wieringa, S. 202ff. 

Data transformations are stateless transformations whose output is a mathematical function of the input. 

Data stores are containers for data that offers a transactional interface. 

Subsystems are components with state and behavior. 

Objects 

Object classes is a type of a component. 

We distinguish channels 

Event channels connect two components so that one of them cause the other to deliver a service. 

Data channels connect two components so that one of them can get information about the other. 

8.7 Verträge zur Kollaboration 

8.7.1 Vertrag 

(nach Eiffel) 

• Wer: Aktiver Partner 

• Wie: Szenario 

• Mit Wem: Subjekt-Partner 

• Was: Gegenstand 

• Woraus: Anspruchsgrundlage 

Vertragsstufen 

1. Syntaktische Stufe: IDL-Beschreibung, ggf. auch auf Niveau normaler Programmiersprache 

2. Verhaltensstufe: Vor- und Nachbedingungen, ggf. mit UML/OCL 

3. Synchronisationsstufe: Service object synchronization, Pfadausdruck, Synchronization counter 

4. Quality of services level 

Beispiele von Verträgen: 

Obligationen 

Passagier 15 Minuten vor Abflug, mit 

akzeptieren Gepäck, bezahltes 

Ticket 

Fluggesellschaft 

Tranport des Kunden zum Ziel 

Verpflichtung 

Erreicht Ziel 

Keine Verpflichtung späte Passagiere 

aufzunehmen, bei zuviel 

Gepäck, bei nichtbezahltem 

Ticket 

Geschichte: Hoare (69) - Tripel; 

Dijkstra (1975) - guarded commandss, weakest liberal precondition 

Spezifikation: 

Vorbedingung: als logischen Ausdruck über den vorgefundenen Zustand


Invariante: als logischen Ausdruck, statische Integritätsbedingung 

Nachbedingung: als logischen Ausdruck über den erreichten Zustand ggf. mit 

Defaultinterpretation: Zurückweisen, falls nicht erfüllt 

Accept On Interpretation: Handlung kann wiederholt werden bis Zustand erreicht ist 

Kompensationsdefinition: mit Kompensationsanweisung 

• durch alternative Anweisung (Pfad) oder 

• explizite Reparaturanweisung z.B. Trigger 

• Anweisung für den Fehlerfall 

Kontextregel für den Vertrag z.B. 

• Synchronisationsbedingungen zur Abstimmung, bei Ressourcenkonflikten 

• Lokalisationsabstraktion, scope 

Geschäftsregel, auf deren Grundlage der Vertrag geschlossen wird 

Korrektheit von Verträgen durch Hoare-Tripel 

• Vorbedingung und Invariante sind erfüllt 

• Nachbedingung und Invariante sind erfüllt 

• Kontextbedingung gilt 

Apparat zur Kontrolle der Korrektheit von Verträgen: 

Compile-Zeit-Kontrolle 

Laufzeitkontrolle 

8.7.2 Theorie zur Kontrolle der Verträge 

Theorie des Subtyping 

Schwache Korrektheit für eine Klasse C und Superklasse C Super 

• Vorbedingungen erfüllen für öffentliche Methoden: 

pre f (x) ∨ ∀C Super (C Super .pre f (x)) 

• Nachbedingungen erfüllen für öffentliche Methoden: 

post f (x) ∧ ∀C Super (C Super .post f (x)) Jede öffentliche Methode erfüllt 

• Invarianten erfüllen 

INV ∧ ∀C Super (C Super .INV ) 

Starke Korrektheit als implikative Beschränkung: 

• Vorbedingungen erfüllen für öffentliche Methoden: 

pre f (x) ⇒ ∀C Super (C Super .pre f (x)) 

• Nachbedingungen erfüllen für öffentliche Methoden: 

post f (x) ⇒ ∀C Super (C Super .post f (x)) Jede öffentliche Methode erfüllt 

• Invarianten erfüllen 

INV ⇒ ∀C Super (C Super .INV ) 

Sprachen, die einen solchen Zugang folgen: Eiffel, Biscotti, Java Assertion Facility, ContractJava, iContract, Jass, 

Design by Cotnract for C++, Hanshake, jContractor, Jcontract


8.7.3 Einbettung in UML 

beachten 

• OCL ist eine ausdrucksbasierte Sprache, damit seiteneffektfrei 

• OCL ist keine Programmiersprache 

• OCL ist typisiert 

Ausweg: Hinzufügen des Vertragsrahmens 

z.Z. wird allerdings ein Meta-Modell für OCL erarbeitet, damit dann auch integrierbar 

Daumenregeln 

• Separation von Manipulationsoperationen und Anfrageoperationen 

• Vermeidung komplexer Navigationsoperationen 

• Vermeidung komplexer Assertionen 

• Einbeziehen von Entwurfspattern 

• Genaue Kontrolle der Vorbedingungen 

• Abgeleitete Anfragen sollen explizit durch Basisanfragen ausdrückbar sein 

• Seiteneffekte von Manipulationsoperationen auf Anfrageoperationen explizit darstellen 

• Seiteneffektfreie Anfrageoperationen 

• Kontrolle der Erzeugung von Objekten 

8.7.4 Dienstvertrag 


Vertrag: ein Rechtsgeschäft, das durch übereinstimmende Willenserklärungen, das heißt durch Angebot und Annahme, 

zustande kommt. 

Man unterscheidet öffentlich-rechtliche Verträge (Staatsverträge, Konkordate) und privatrechtliche Verträge, unter 

Letzteren schuldrechtliche (obligatorische, z.B. Kauf, Miete), dingliche (Auflassung), familienrechtliche (Ehevertrag) 

und erbrechtliche (Erbvertrag), ferner entgeltliche und unentgeltliche, je nachdem, ob für die Leistung des einen Teils 

eine Gegenleistung des andern vereinbart ist oder nicht. Unter einem Vertrag zugunsten Dritter versteht man das vertragliche 

Versprechen der Leistung an einen Dritten, nicht am Vertragsabschluss Beteiligten (§§ 328 folgende BGB). 

Ein Vertragsangebot kann nur innerhalb der gesetzten Frist angenommen werden, ein unter Anwesenden oder telefonisch 

gemachtes Vertragsangebot kann nur sofort, der einem Abwesenden gemachte Antrag nur bis zu dem Zeitpunkt 

angenommen werden, in dem der Antragende den Eingang der Antwort unter regelmäßigen Umständen erwarten 

darf (§147 BGB). Verspätete Annahme gilt als neuer Antrag. Verträge können formlos (auch mündlich oder durch 

schlüssige Handlungen) abgeschlossen werden, soweit keine gesetzlichen Formvorschriften bestehen. Die auf Verschulden 

beruhende Verletzung eines Vertrags (Vertragsverletzung) verpflichtet zu Schadensersatz. (elektronischer 

Geschäftsverkehr). 2 

eng in Beziehung dazu: 

Formvorschriften: die Bindung eines Rechtsgeschäfts an vorgeschriebene Erklärungsmittel. 

Bei privaten Rechtsgeschäften gilt der Grundsatz der Formfreiheit, nur ausnahmsweise ist öffentliche Beglaubigung 

(die Echtheit der Unterschrift des Erklärenden unter seiner schriftlichen Erklärung wird vom Notar oder einer 

anderen, landesrechtlich dafür vorgesehenen Stelle beglaubigt) erforderlich. Hiervon zu unterscheiden ist die amtliche 

Beglaubigung (besonders durch die Gemeindebehörde), deren Beweiskraft sich auf Zwecke der Verwaltung 

2 (c) Bibliographisches Institut & F. A. Brockhaus AG, 2003


beschränkt. Weiter gibt es die notarielle Beurkundung (Aufnahme einer Niederschrift durch den Notar, die vor den 

Beteiligten verlesen, von ihnen genehmigt und unterschrieben wird, z.B. bei Grundstücksgeschäften) oder die Schriftform 

(Niederschrift der Erklärung mit eigenhändiger Unterschrift des Erklärenden). Die gesetzliche Schriftform kann 

seit 1.8. 2001 durch die elektronische Form ersetzt werden, wenn sich aus dem Gesetz nichts anderes ergibt (§126 

BGB). Der Aussteller muss der Erklärung gemäß §126a BGB seinen Namen hinzufügen und das elektronische Dokument 

mit einer qualifizierten elektronischen Signatur(erteilen Zertifizierungsstellen, die bei der Regulierungsbehörde 

Telekommunikation und Post akkreditiert sind) nach dem Signaturgesetz versehen. Ausgeschlossen ist die elektronische 

Form z.B. für Arbeitszeugnisse und Bürgschaftserklärungen. Die Textform (§126b BGB) macht die eigenhändige 

Unterschrift einer Person in bestimmten Fällen entbehrlich. Soweit das Gesetz die Textform vorschreibt, muss die 

Erklärung in einer lesbaren Form abgegeben (Brief, Faxkopie, Computerfax, E-Mail), die Person des Erklärenden 

genannt und das Ende der Erklärung durch Nachbildung der Namensunterschrift oder anders erkennbar gemacht 

werden. Vorgesehen ist die Textform z.B. für Mieterhöhungen bis zur ortsüblichen Vergleichsmiete (§558a BGB, in 

Kraft ab 1.9. 2001). Da Formvorschriften eine Schutzfunktion für die Beteiligten bezwecken, macht die Nichtbeachtung 

der gehörigen Form in der Regel ein Rechtsgeschäft unwirksam 3 

elektronischer Geschäftsverkehr: auf die Lieferung von Waren oder Dienstleistungen gerichtete Verträge, die durch 

den Einsatz von Fernkommunikationstechniken, besonders das Internet, zustande kommen. 

Auf diese Weise abgeschlossene Verträge sind nach allgemeinem Vertragsrecht gültig, wobei sich das anzuwendende 

Recht nach dem internationalen Privatrecht bestimmt. V.a. bei Verbraucherverträgen ist dies regelmäßig das inländische 

Recht (Artikel 2729 Einführungsgesetz zum BGB). Verbraucherschützende Sonderregeln ergeben sich aus der 

europäischen Fernabsatzrichtlinie von 1997 (durch Gesetz vom 27.6. 2000 in deutsches Recht umgesetzt: v.a. Informationspflichten, 

§§312b ff. BGB), ein zweiwöchiges Widerrufsrecht nach §355 BGB) und aus der Richtlinie über 

rechtliche Aspekte des elektronischen Geschäftsverkehrs im Binnenmarkt von 2000 (durch Gesetz vom 14.12. 2001 

umgesetzt: bestätigt die Rechtsgültigkeit elektronischer Verträge; legt fest, dass für den Diensteanbieter das Recht 

des Mitgliedsstaates gilt, in dem er seine Niederlassung hat, nicht das des Standortes seines Servers). 4 

contract 

• either: a binding agreement between two or more persons or parties; especially : one legally enforceable 

or: a business arrangement for the supply of goods or services at a fixed price 

or: the act of marriage or an agreement to marry 

• a document describing the terms of a contract 

• the final bid to win a specified number of tricks in bridge 

• an order or arrangement for a hired assassin to kill someone 

to contract 

intransitive senses in the meaning 

• to make a contract 

• to draw together so as to become diminished in size; also : to become less in compass, duration, or length 

transitive senses in the meaning 

• either: to bring on oneself especially inadvertently 

or: to become affected with 

• either: to establish or undertake by contract 

or: betroth; also : to establish (a marriage) formally 

or: to hire by contract, to purchase (as goods or services) on a contract basis- often used with out 

3 (c) Bibliographisches Institut & F. A. Brockhaus AG, 2003 

4 (c) Bibliographisches Institut & F. A. Brockhaus AG, 2003


• either: limit, restrict 

or: knit, wrinkle 

or: to draw together : concentrate 

• to reduce to smaller size by or as if by squeezing or forcing together 

• to shorten (as a word) by omitting one or more sounds or letters 

Synonyms: shrink, condense, compress, constrict, deflate mean to decrease in bulk or volume. 

Contract applies to a drawing together of surfaces or particles or a reduction of area or length. Shrink implies a 

contracting or a loss of material and stresses a falling short of original dimensions. Condense implies a reducing of 

something homogeneous to greater compactness without significant loss of content. Compress implies a pressing into 

a small compass and definite shape usually against resistance. Constrict implies a tightening that reduces diameter. 

Deflate implies a contracting by reducing the internal pressure of contained air or gas. 

Spezifikation: Preprint S. 151u-153o 

Vertragmodell mit den Komponenten 

Dienstmodell 

Kollaborationsvertrag z.B. Kollaborationsmodell Preprint S. 28 

Qualitätsmodell 

Zeitmodell 

Kontextmodell 

Akteursmodell 

Fehlermodell Preprint S. 28, Preprint S. 152 

Sicherheitsmodell Preprint S. 28, Preprint S. 152 

8.7.5 Alternative Spezifikation von Contracts mit Eiffel-Frames nach Plösch 

8.8 Spezifikation der Koordination 

8.9 Spezifikation der Kooperation 

8.10 Specification of virtual communities 

A virtual community is a group in which individuals come together based on an obligation to each another or as 

a group in which individuals come together for a purpose. We distinguish between the notion of the community 

(Gemeinschaft) and the notion of the society. The first kind may be separated into 

• communities by kinship, 

• communities of locality, and 

• communities of mind (based on shared interest, expertise, and passion). 

Organizational communities are specified by 

their sustained social interaction 

their community standards 

membership rules 

Communities meet four types of customer needs:


• interest which are formed by individuals with a shared interest, expertise and passion. 

• relationship building with a well-developed social and personal element 

• transaction which focus on the exchange of information to facilitate economic exchanges and 

• fantasy which provide people the ooprtunity to explore new identities in an imaginary world of fantasy. 

8.11 Spezifikation auf unterschiedlichen Abstraktionsschichten 

auf der Anforderungsschicht 

8.11.1 als Grundkonstrukt 

auf der Benutzungsschicht 


als konzeptionelle Wiederspegelung 


auf der Implementationssschicht 


Spezifikation auf unterschiedlichen Abstraktionsschichten 

8.11.5 weiteres: 

8.11.6 Warum dann DistrLang anstatt von UML 

EER-Modelle 

Verteilung 

Sichten 

Replikation 

8.12 Verteilte Informationssysteme 

8.12.1 Konzepte verteilter Datenbanksysteme 

In den 60er und 70er Jahren beobachteten wir einen Übergang von Datei- zu Datenbanksystemen. Damit wurden die 

Datenunabhängigkeit der Anwendungsprogramme erhöht, eine transaktionsorientierte Verarbeitung und ein Mehrnutzerbetrieb 

ermöglicht sowie eine hohe Ausfallsicherheit im Parallelbetrieb erreicht, insbesondere durch Integration 

von Recovery-Funktionen wie Crash-Recovery, Media-Recovery. Da Hardware teuer war, wurden die teuren 

Hardware-Ressourcen effizient genutzt durch eine starke Zentralisierung von Rechentechnik. Damit standen kleine 

Adreßräume zur Verfügung und die Software war limitiert. Damit mußten auch eine redundanzarme bzw. -freie Speicherung 

von Daten und eine minimale Anzahl von Relationen erzwungen werden. Diese Situation änderte sich danach 

vollständig. Hardware wurde zunehmend kostengünstiger. Man konnte schrittweise zu ‘online’-Anwendungen 

übergehen. Damit versagte allerdings auch die Datenintegration via Job-Control-Sprache. Es wurde außerdem ein 

‘online’-Update erforderlich. Dies bedingte das Zusammenführen von bislang getrennten Anwendungen und Datenbeständen. 

Außerdem mußte die Integration verteilter Informationssysteme angestrebt werden. 

In den 80er Jahren wurden mit der Weiterentwicklung der Datenbanktechnologie verstärkt verteilte Systeme 

eingesetzt. Dafür gibt es verschiedene Ursachen: 

• Daten werden zunehmend teurer und stellen Kapital dar, dessen Pflege meist nur einer Einrichtung zugeordnet 

werden darf. Daten werden wieder direkt ‘vor Ort’ verarbeitet wie vor Einführung der Rechenzentren.


• Das Geschäftsleben und der Wettbewerb werden globalisiert. Die Benutzeranforderungen und der Markt favorisieren 

deshalb eine dezentralisierte Verwaltung bei der Forderung nach einer vollständigen Benutzbarkeit 

aller Daten. 

• Eine immer größere Anzahl von verschiedenartigen Lösungen und verschiedenartigen Datenbanken erforderte 

zugleich die Investitionen durch Datensharing beizubehalten. 

• Mit dem Trend zu autonomen Betriebseinheiten (‘lean management’, ‘profit center’) wurden ‘überintegrierte’ 

Informationssysteme aufgesplittet und eine Dezentralisierung der Datenverarbeitung angestrebt. 

Diese Forderungen konnten zunehmend durch die Hardware (und die Software) befriedigt werden. LAN’s wurden 

auch aufgrund steigender Kosten bei Mainframe-Lösungen immer populärer. 

Damit wurden mit einer Verbesserung der Produktionsorganisation und dem Trend zur ‘schlanken Produktion’ auch 

eine schnelle Reaktion, intelligente Operationen Datenbanksystemanforderungen wie schneller ad-hoc-Zugriff und 

verteilter Zugriff bzw. verteilte Speicherung neu aufgewertet. Verteilte Datenbanksysteme haben gegenüber zentralisierten 

Datenbanksystemen die Vorteile einer höheren Performanz (insbesondere bei entsprechenden Entfernungen 

und einer Vielzahl von Benutzern), geringerer Kosten (insbesondere für die Pflege) und einer höheren Zuverlässigkeit 

und Verfügbarkeit (insbesondere bei partiellen Systemfehlern). Damit können zugleich Daten entsprechend Anforderungsprofilen 

an verschiedenen Stellen abgelegt werden, auf Daten schneller zugegriffen werden, Daten schneller 

verarbeitet werden, Erweiterungen (insbesondere von weiteren Teilnehmern) einfacher vorgenommen werden, 

die Kommunikation verbessert, geringere CPU-Kosten, benutzerfreundliche und spezialisierte Schnittstellen erzeugt 

werden, die Anwendungen gegenüber von Ausfällen eines Knotens besser abgesichert werden und die Prozessoren 

voneinander unabhängig operieren. Diesen Vorteilen stehen allerdings Nachteile wie komplexere Verwaltung und 

Steuerung, schwierigeres Sicherheitsmanagement und das Fehlen von Standards gegenüber. 

Eine verteilte Datenbank ist eine inhaltlich zusammenhängende Datenbank, die auf mehreren physisch unabhängigen 

Knoten (Rechner, Speichermedien) verteilt wird. Die auf den Knoten abgelegten Partitionen der Datenbank 

können dabei auch nicht separiert voneinander sein (Datensharing). Ein verteiltes System ist gekennzeichnet 

durch 

• eine Anwendungsschnittstelle für verschiedene Endbenutzer, 

• eine Validierungsfunktion zur Analyse der Datenanforderungen, 

• eine Transformationskomponente zur Berechnung der Anforderungen an die Komponenten, 

• eine Anfrageoptimierung, die die Verteilung berücksichtigt, 

• ein Input/Output-Interface für die Daten, 

• eine Formatierungsfunktion zur Anpassung der generierten Daten an die Benutzeranforderungen, 

• ein Sicherheitsmanagement, um Datensicherheit zu gewährleisten, 

• Backup- und Wiederanlauffunktionen, 

• eine Datenbankadministration, 

• eine Steuerung für den konkurrierenden Zugriff über das Netz und 

• eine Transaktionsverwaltung. 

Damit besteht ein verteiltes DBMS aus Rechnern, die Knoten zugeordnet sind, einem Kommunikationsnetzwerk zur 

Verbindung der Knoten, aus einem Netzwerk-Hard- und Software, aus Transaktionsprozessoren (TP) und aus Datenprozessoren 

(DP).


TP 

DP 

Lokales DBMS 

✛ 

✲ Kommunikationsnetzwerk 

✛ 

✲ 

TP 

DP 

Lokales DBMS 

Abbildung 43: Grundsätzliche Architektur verteilter DBMS 

Die verteilte Datenbank präsentiert sich gegenüber den Endbenutzern bzw. Anwendungsprogrammen wie eine 

zentrale Datenbank. Dieses Ziel erfordert das Verstecken aller ‘störenden’ Aspekte. Die Lösung besteht in der Realisierung 

eines (‘integrierenden’ und ‘homogenisierenden’) globalen Schemas. Deshalb sind die Verteilung der Daten, 

inklusive der Kopienhaltung (d. h. der Partitionierung 5 und Allokation), ebenso wie die strukturellen und semantischen 

Heterogenitäten (mittels Schematransformation bzw. -integration) zu verstecken. Aus Performanz- und Sicherheitsgründen 

werden dabei dieselben Daten an verschiedenen Knoten redundant gespeichert (redundante Allokation). 

Informationen des gleichen Typs werden ggf. an verschiedenen Knoten verschieden dargestellt, z. B. anders strukturiert 

(strukturelle Heterogenität) bzw. mit anderen Bedeutungsinhalten (semantische Heterogenität). Eine andere 

Lösung ist die Partitionierung globaler Relationen, indem logisch an sich zusammengehörende Daten in homogener 

Form an verschiedenen Knoten gespeichert werden. 

Mit dieser Funktionalität kann ein verteiltes DBMS 

• eine Anfrage entgegennehmen, 

• diese analysieren, prüfen und zerlegen, 

• diese Teile den einzelnen Komponenten zuordnen, 

• auf verschiedene I/O-Operationen zurückführen, 

• die entsprechenden Daten suchen, lokalisieren, lesen und validieren, 

• auf dieser Grundlage die Konsistenz, Sicherheit und Integrität prüfen, 

• die Daten entsprechend der ursprünglichen Dekomposition validieren und 

• am Ende die gewonnenen Daten entsprechend der Anfrage dem Benutzer zur Verfügung zu stellen. 

Diese Aktivitäten sind aber für dem Benutzer nicht sichtbar. Wir unterscheiden dabei verschiedene Arten von Sichtbarkeit. 

Je nach Verteilung der einzelnen Komponenten unterscheiden wir 

Einfachknoten-Berechnung und Einfachknoten-Datenhaltung, 

Einfachknoten-Berechnung und Mehrfachknoten-Datenhaltung, 

Mehrfachknoten-Berechnung und Einfachknoten-Datenhaltung und 

Mehrfachknoten-Berechnung und Mehrfachknoten-Datenhaltung. 

Die Mehrfachknoten-Berechnung und Einfachknoten-Datenhaltung entspricht im Wesentlichen der Client/Server- 

Architektur der Workstation-basierten DBMS. 

Wir können auf verschiedene Rechner bei Vorhandensein eines Netzes verschiedene Ressourcen verteilen: 

Daten: Daten können auf verschiedenen Rechnern abgelegt und auf Anfrage bzw. Abforderung anderen Rechnern 

zugänglich gemacht werden. 

5 Wir verwenden hier den Begriff ‘Partition’. In der Literatur wird neben dem Begriff ‘Partition’ der Begriff ‘Fragment’ benutzt. Da wir 

jedoch auf eine disjunkte Überdeckung des Datenbankinhaltes orientieren, ist das Wort ‘Partition’ eher geeignet.


Prozesse: Prozesse können auf verschiedenen Rechnern ausgeführt und über ein Netz zusammengeführt werden. 

Steuerung: Die Bearbeitung kann durch verteilte Steuerung der einzelnen Prozesse und des Datenaustausches erleichtert 

werden. 

Dabei kann die Organisation der Verteilung unterschieden werden nach Prozeßcharakteristika und Prozeßwissen: 

Umfang des Sharing: In verteilten Datenbanken kann sowohl kein Sharing an Informationen stattfinden als auch 

Sharing in verschiedenen Stufen. Je größer der Sharing-Anteil, umso kritischer wird die Pflege und umso besser 

wird die Zugriffszeit auf Fremddaten. 

Verhalten von Zugriffsmustern: Die Zugriffsmuster über das Netz können statisch oder auch dynamisch sein. Statische 

Zugriffsmuster, die sich nicht verändern, sind relativ selten. Dynamische Zugriffsmuster bedingen dagegen 

einen ständigen Anpassungsprozeß. 

Umfang des Wissens über den verteilten Zugriff: Die Information über das Zugriffsverhalten kann vollständig, 

wird jedoch meist nur partiell sein. Je weniger Wissen vorhanden ist, umso schlechter kann die verteilte Datenbank 

an die Anforderungen angepaßt werden. 

Grundsätzlich sollen in einer verteilten Datenbank die Benutzer nicht mit der Verteilung direkt konfrontiert sein. 

Die Verteilung wird deshalb unsichtbar bleiben: 

Nichtsichtbarkeit der Verteilung: Die Benutzer wissen nicht, welche Daten auf welche Knoten verteilt wurden. 

Wir unterscheiden dabei verschiedene Niveaus von Nichtsichtbarkeit: 

Nichtsichtbarkeit der Partitionierung : Der Benutzer kennt weder die Partitionierung noch die Knoten, sondern 

kann das System benutzen wie eine zentralisierte Datenbank. 

Nichtsichtbarkeit der Lokalisierung bei sichtbarer Partitionierung : Der Benutzer muß die Partition angeben, 

nicht aber die Lokalisierung. 

Sichtbarkeit der Lokalisierung und Partitionierung : Der Benutzer muß sowohl die Lokalisierung als auch 

die Partitionierung angeben. 

Nichtsichtbarkeit der Transaktionen: Die Benutzer kennen die Verteilung von Transaktionen nicht. 

Durch remote-Anforderungen können Daten auch von anderen Knoten, z.T. auch unabhängig und parallel, 

geholt werden. Es wird durch einige Systeme auch eine verteilte Steuerung ermöglicht. Mit einem Zweiphasen- 

Commit-Protokoll wird der Abschluß der Transaktion auch über verschiedene Knoten kontrolliert. 

Nichtsichtbarkeit des Ausfalls einzelner Komponenten: Solange ein Ausfall nicht das Funktionieren beeinflußt, 

erfahren die Benutzer nichts vom Ausfall einzelner Komponenten. 

Nichtsichtbarkeit des Funktionierens: Das System hat nach außen das gleiche Verhalten wie ein zentralisiertes 

System. 

Nichtsichtbarkeit der Heterogenität: Das System ist in der Lage, die verschiedenen heterogenen Bestandteile dem 

Benutzer wie ein einheitliches, auf einem globalen konzeptionellen Schema beruhendes System erscheinen zu 

lassen. 

8.12.2 Verteilungskonzepte 

Mit einer Partitionierung sind Einschränkungen der Performanz verbunden. 

Daten können auf verschiedene Art partitioniert werden wie in Bild 44: 

Horizontale Partitionierung: Daten werden horizontal zerlegt (d. h. eine Tabelle oder Relation wird tupelweise zerlegt 

in verschiedene Teilrelationen) und verschiedenen Medien zugeordnet. In Bild 44 wird die Relation R 

durch Anwendung von Selektionsoperationen in drei Teilrelationen zerlegt, wobei gefordert wird, daß sich die 

Relation R aus den Teilrelationen wiederherstellen läßt durch Vereinigung dieser Teilrelationen. Damit müssen


A 1 A 2 A 3 A 4 

A 1 A 2 A 3 A 4 

Relation R 2 

A 1 A 2 A 3 A 4 

= σ β (R) 

Relation R 1 

= σ α (R) 

Relation R 3 

= σ γ (R) 

horizontale Partitionierung 

⇑ ↓ 

(Dekompostion durch Selektion) 

A 1 A 2 A 3 A 4 


R := R 1 ∪ R 2 ∪ R 3 

Relation R 

vertikale Partionierung 

(Dekomposition durch Projektion) 

⇓ 

↑ 


R := R[{A 1 , A 2 , A 3 }] ✶ R[{A 1 , A 4 }] 

A 1 A 2 A 3 

A 1 A 4 

Relation 

R[{A 1 , A 2 , A 3 }] 

Relation 

R[{A 1 , A 4 }] 

Abbildung 44: Partitionierungskonzepte


die Bedingungen α, β und γ als Disjunktion den Wahrheitswert true ergeben. Neben Selektionsoperationen 

können auch andere Operationen der relationalen Algebra verwendet werden. Es wird jedoch im Kontext verteilter 

DBS exklusiv die Selektion verwendet. 

Vertikale Partitionierung: Daten werden vertikal zerlegt (d. h. eine Relation oder Tabelle wird attributweise dekomponiert) 

und auf verschiedene Medien verteilt. In Bild 44 wurde die Relation R durch Projektion in zwei 

Teilrelationen zerlegt. Der natürliche Verbund dieser beiden Teilrelationen muß wiederum die ursprüngliche 

relation R ergeben. 

Gemischte Partitionierung: Daten werden sowohl horizontal als auch vertikal zerlegt und auf verschiedene Knoten 

aufgeteilt. Es werden schrittweise zur Partitionierung Selektion und Projektion angewandt. 

Die Partitionierungstiefe kann bei einer Partitionierung von keine Partitionierung bis zu einer Partitionierung 

auf Attribut- bzw. Objektniveau reichen. 

Für die Partitionierung sind einige Korrektheitsregeln in verschiedenen Abstufungen einzuhalten: 

Vollständigkeit: In Analogie zur Eigenschaft der verlustlosen Dekomposition bei der Normalisierung können Klassen 

in mehrere Teilklassen oder anhand von Teilstrukturen in Partitionen zerlegt werden. Eine Eigenschaft 

eines Objektes kann dabei einmalig oder mehrmalig repräsentiert sein. 

Rekonstruierbarkeit: Je nach Zerlegung bzw. Partitionierung existiert eine Funktion ∇ zur Wiederherstellung der 

ursprünglichen Klassen. 

Disjunktheit: Die Partitionen sind entweder disjunkt oder es existiert ein Algorithmus, mit dessen Hilfe gleiche 

Eigenschaften eines Objektes in verschiedenen Partitionen gepflegt werden können. Meist kann ein solcher 

Algorithmus über Identifikationsmechanismen definiert werden. 

Sobald eine Datenbank partitioniert ist, muß eine Allokation der verschiedenen Partitionen zu den Knoten des 

Netzes erfolgen. Die Partitionierung und Allokation werden ebenso wie im Falle zentraler DBS in einem Datenbank- 

Katalog (data dictionary (DD)) verwaltet. Ein zugeordnetes Datum kann dabei repliziert oder einmalig einem Knoten 

zugeordnet sein. Es können Prozesse für Daten in zwei Extremen unterstützt werden: 

Read-only-Zugriff für Replikate: Die Zuverlässigkeit und Effizienz (insbesondere für parallele Zugriffe) ist bei 

Read-only-Zugriffen auf Replikaten höher. Zugleich entsteht aber ein update-Problem. 

Read-and-write-Rechte für Replikate: Die Zuverlässgkeit und unter gewissen Umständen die Effizienz sinken. Ein 

update wird analog zu Triggermechanismen vorgenommen. 

Je nach Umfang der Replikation können verschiedene Probleme entstehen. Damit ist für jede Anwendung abzuwägen, 

inwieweit eine Replikationsstrategie günstig ist. 

Art der Replikation: volle teilweise keine 

Anfrageberechnung 

einfach 

gleiche Komplexit .. at 

←→ 

gleiche Komplexit .. at 

←→ 

DD-Verwaltung einfach oder 

nicht existent 

Steuerung der mittel hoch einfach 

Parallelität 

Zuverlässigkeit sehr hoch hoch niedrig 

Realistisches mögliche realistische mögliche 

Anwendungsszenario Anwendung Anwendung Anwendung 

Komplexität der Operationen bzw. Eigenschaften der Operationen


8.12.3 Architektur verteilter Datenbanksysteme 

In konventionell realisierten verteilten Datenbanksystemen wird die Verteilung in den Anwendungen selbst realisiert. 

Die Anwendungsprogramme können miteinander kommunizieren. Dadurch werden an den Entwurf der Schnittstellen 

dieser Programme hohe Anforderungen gestellt. In verteilten Datenbanksystemen wird die Verteilung über das 

verteilte Datenbankmanagementsystem übernommen. Die Verteilung der Daten ist für das einzelne Anwendungsprogramm 

nicht mehr sichtbar. 

Allen verteilten Datenbanksystemen ist die Verteilung der Daten auf verschiedene Knoten und die lokale Verarbeitung 

von Anfragen durch die lokalen Komponenten gemeinsam. Mitunter werden auch verteilte Dateisysteme als 

verteilte Datenbanksysteme bezeichnet. Obwohl Dateisysteme als Datenbanksysteme der ersten Generation aufgefaßt 

werden können, haben sie wenig gemeinsam mit Datenbanksystemen. Die Funktionalität von verteilten Datenbanksystemen 

kann nach der folgenden Tabelle unterschieden werden: 

Merkmale verteilter Homogene Interope- Föde- Offene 

Datenbanksysteme eng integr. rable rierte Multi-DB 

Physische Verteilung der Daten + + + + 

Logische Sicht als eine Datenbank + +/- +/- - 

Nichtsichtbarkeit der Verteilung + - +/- - 

Gemischter DB-Zugang (glob./lok.) - - + - 

Zerlegung glob. Anfragen durch DBMS + - + - 

Lokale Ausführung von Teilanfragen + + + + 

Globales Transaktionskonzept + - + - 

Lokale Autonomie wird erhalten - + - + 

8.12.4 Homogene, eng integrierte verteilte Datenbanksysteme 

Das verteilte System ist von außen als ein homogenes System sichtbar. Es besitzt ein integriertes Schema. Die lokalen 

Systeme sind nicht autonom. Das Transaktionskonzept ist global. 

Damit werden Leistungsanforderungen wie im Falle zentraler Datenbanksysteme anwendbar. Daraus resultiert 

auch die Anwendungsbreite: 

• Hochleistungsdatenbanksysteme durch Nutzung der Parallelverarbeitung; 

• Fehlertolerante Datenbanksysteme durch Nutzung der kontrollierten Redundanz; 

• Dezentralisierte Datenbanksysteme zur Reduktion des Kommunikationsaufkommens und der Abhängigkeit 

vom Netz. 

Mehrrechnerdatenbanksysteme sind eine typische Realisierungsform von homogenen integrierten Datenbanksystemen. 

Es sind im Wesentlichen drei Realisierungsvarianten entwickelt worden: 

• In der Shared-Everything-Architektur sind sowohl Systempuffer als auch Sperrtabelle global. 

• In der Shared-Disk-Architektur wird wie in der vorhergehenden Variante die Platten-Peripherie über eine Variante 

von Bussystemen gemeinsam genutzt. Die einzelnen Anfragen werden lokal durch eigene Rechner mit 

eigenem Hauptspeicher verarbeitet. 

• In der Shared-Nothing-Architektur wird ein vollständig verteiltes System aufgebaut, dessen einzelne Systeme 

durch schnelle Kommunikationverbindungen miteinander verbunden sind. 

8.12.5 Architektur föderativer Datenbanken 

Föderative Datenbanken folgen dem Besitzer/Benutzer-Prinzip, wobei zusätzlich noch einem Benutzer Leserechte 

durch den Besitzer verweigert werden können. Sie wirken aufgrund einer Spezifikation der Kooperation zusammen. 

Bei Kopplungen muß auch die lokale Effizienz gewahrt bleiben. Wir unterscheiden dabei


• singuläre Föderationen, bei denen die lokalen DBMS heterogen sein können, die jedoch auf einem globalen 

Schema basieren und dieses für die Berechnungen benutzen, und 

• multiple Föderationen, bei denen die einzelnen Systeme auch eigene, anderen nicht zugänglich gemachte Daten 

besitzen, die nicht mehr auf einem globalen Schema beruhen und die über Exportschemata miteinander 

zusammenarbeiten. 

Eine Weiterentwicklung von multiplen Föderationen sind sprachlich gekoppelte Multi-DBMS. Dazu wird jedoch erst 

geforscht, so daß hier für den Entwurf nur föderative DBMS betrachtet werden. 

Der Entwurf einer föderativen Datenbank kann dabei von folgender Referenzarchitektur ausgehen: 

Lokale Schemata sind die Schemata der einzelnen Netzknoten. 

Komponentenschemata sind die lokalen Schemata in einer für die Koordinierung aufbereiteten Form. Das Datenbankmodell 

kann verschieden vom Datenbankmodell des lokalen Schemas sein. 

Exportschemata beschreiben die netzweit zugänglichen Daten, die den Teilnehmern einer Föderation zugänglich 

gemacht werden müssen. 

Föderative Schemata fassen die Exportschemata analog zur Sichtenintegration wie oben beschrieben zu einem allgemeinen 

Schema zusammen. Weiterhin werden Ansätze zur Auflösung von Modellierungskonflikten, statische 

Daten zur Optimierung, zur Verteilung (Partitionierung, Replikation etc.) erfaßt. 

Transformationsprozessoren erlauben eine Abbildung der lokalen Schemata auf die Komponentenschemata. 

Filterprozessoren filtern aus den Komponentenschemata die Daten für die Exportschemata heraus. 

Konstruktionsprozessoren dienen zur Einbindung der Exportschemata in die oder das föderative Schema. 

✻ 

Exportschema 

❄ 

Filterprozessor 

✻ 

Interface zum föderativen Schema 

❄ 

Konstruktionsprozessor 

✻ 

Komponentenschema 

❄ 

Transformationsprozessor 

✻ 

Lokales DB-Schema 

❄ 

Lokales 

DBMS 

Abbildung 45: Die Architektur von föderativen Datenbanksystemen


Anwendungs-Service 

Abstrakter Service 

Konkreter Service 

System Service 

Abbildung 46: Eine Schichten-Architektur für interoperable Umgebungen 

Der nächste Schritt sind interoperable föderative Informationssysteme. Deren Dienste können wie in Bild 46 

dargestellt werden. 

Diese Entwicklungslinie läßt sich für interoperable, föderative Systeme fortsetzen. 

Verteilung \ DBMS Zentrale Verteilte Interoperable Föderative 

Datenbankmodell A A B B 

Plattform A A A B 

Replikation/Partitionierung A B B B 

Insgesamt ergibt sich damit die folgende in Bild 47 dargestellte Architektur. 

Lokaler Benutzer A 

Lokaler Benutzer B 

Benutzer- 

Interface 

System A 

Globaler Benutzer 

System B 

Benutzer- 

Interface 

Lokale 

Anwendungen 

Lokales 

DBMS 


Benutzer- 

Interface 

Globales 

Kommunikationsund 

Verknüpfungs- 

System 


Lokale 

Anwendungen 

Lokales 

DBMS 

Abbildung 47: Interoperable föderierende Informationssysteme 

8.12.6 Offene Multidatenbanksysteme 

In einem offenen, sehr losen Verbund werden offene Multidatenbankensysteme realisiert. Typische Anwendungsbeispiele 

sind autonome Systeme, die ihre Funktionalität ‘befreundeten’ Systemen öffnen wie z. B. Reservierungssysteme, 

Recherchedatenbanken und Informationsdienste. Die Integration findet nur in den anwendungsnahen Schichten 

statt und kann von lokaler Komponente zu lokaler Komponente variieren. Damit wird ein hoher Grad an Autonomie 

erreicht. Zugleich sind diese Systeme eher für den lesenden Zugriff geeignet. Eine globale Transaktionskomponente 

kann nicht existieren. Die Modifikation der Daten wird dann nicht wie mit einem Two-Phase-Commit unterstützt, 

sondern durch entsprechende Kompensationsoperationen vorgenommen. Eine Transaktion wird z. B. in einem Buchungssystem 

durch eine Stornierungsbuchung aufgehoben. Ein Rollback existiert nur lokal.


8.12.7 Heterogene Datenbanken 

Heterogene Datenbanken verwalten inhaltlich verwandte Informationen einer Institution, eines Unternehmens, etc. 

Die Informationen sind in der Praxis häufig über mehrere heterogene Datenbanken verstreut, die unabhängig voneinander 

entworfen wurden und betrieben werden. Heterogenität tritt auf bezüglich: 

• Hardware (Rechner, Peripherie, Kommunikationssystem, ...), 

• Betriebssystemen (Windows, Linux, Unix, MS/DOS, MVS, VMS, BS2000 ...), 

• Kommunikationsprotokollen (SNA, TCP/IP, Transdata, OSI ...), 

• DBMS (Hersteller, Version), 

• Datenmodellen (relational, objekt-orientiert, CODASYL, hierarchisch), 

• Anfragesprache (SQL-Dialekt, DL/1, ...), 

• Transaktionsverwaltung (Synchronisation, Logging, Recovery) und 

• Repräsentation der Daten, die wieder zu einer größeren semantischen Heterogenität führt. 

Semantische Heterogenität ist oft durch Entwurfsautonomie verursacht. Eine mögliche Behandlung kann durch Schemaintegration 

analog zu Zugängen föderativer DBS erfolgen. Es sind in diesem 

Zusammenhang Namenskonflikte (Synonyme, Homonyme) zu lösen. Es werden unterschiedliche Namen für dieselben 

Attribute/Relationen verwendet bzw. die gleichen Bezeichner für unterschiedliche Attribute/Relationen. Damit 

muß eine Umbenennung erfolgen. Bei der Modellierung werden unterschiedliche Formate verwendet (unterschiedliche 

Datentypen, Genauigkeit, etc. ). Dies erfordert den Einsatz von Konversionsfunktionen. Es treten strukturelle 

Unterschiede z. B. bei der Repräsentation von Information durch Attribute bzw. eigene Relation(en), bei unterschiedlichen 

Beziehungstypen (1:N, M:N, ...), durch unterschiedliche Integritätsbedingungen (Eindeutigkeit, referentielle 

Integrität, Nullwertbehandlung, Defaultwerte, Wertebereiche, etc.) auf. Außerdem können Daten fehlen oder widersprüchlich 

sein, z. B. durch Eingabefehler und unterschiedlichen Änderungsstand. 

8.12.8 Schemata verteilter DBS 

Obwohl die vollständige Schemaintegration algorithmisch nicht lösbar ist, kann man die Entwicklung eines integrierten 

Schemas in verteilten Anwendungen anstreben. Eine Schemaarchitektur kann man dabei an die föderativen 

Systeme wie in Bild 48 anlegen. Dabei wird angestrebt, ein gemeinsames konzeptionelles und internes Schema für 

alle Knoten anzulegen. Von Vorteil ist, daß ein globales konzeptionelles Schema Verteilungstransparenz unterstützt. 

Es wird jedoch keine Knotenautonomie unterstützt. Deshalb ist ein globales Schema, dem das Verteilungsschema 

unterlegt wurde, ungeeignet. Es ist außerdem für geographisch verteilte Systeme ungeeignet. Mit der in Bild 48 

angegebenen Architektur wird die Verteilungstransparenz durch das globale konzeptionelle Schema und die Knotenautonomie 

durch die lokalen konzeptionellen und internen Schemata unterstützt. Ein Katalog führt die Metadaten 

für die DB-Verarbeitung. Im Katalog werden die Namen und Adressen externer Knoten und der DBS, Angaben zur 

Datenverteilung und Angaben zu Relationen, Sichten, Attribute, Integritätsbedingungen, Benutzern, Zugriffsrechten, 

Indexstrukturen, Statistiken etc . geführt. Jeder Knoten führt für die lokalen Objekte die Katalogdaten. 

8.12.9 Datenverteilung, Allokation und Partitionierung 

Mit der Dreiebenen-Schema-Architektur in Bild 48 erscheint eine Trennung zwischen der Verteilung von Daten auf 

logischer Ebene mit einer prädikativen Beschreibung der Verteilung insbesondere zur (horizontalen, vertikalen, 

gemischten) Partitionierung globaler Relationen und auf 

physischer Ebene mit einer Festlegung des Speicherungsortes mit einer redundanten oder nicht-redundanten Allokation 

von Partitionen


Lokales 

externes 

Schema 1 

Lokales 

externes 

Schema 2 

Lokales 

externes 

Schema m 

Globales konzeptionelles Schema 

Globales Verteilungsschema 

Lokales 

konzept. 

Schema 1 

Lokales 

konzept. 

Schema 2 

Lokales 

konzept. 

Schema n 

Lokales 

internes 

Schema 1 

Lokales 

internes 

Schema 2 

Lokales 

internes 

Schema n 

Lokales 

DBS 1 

Lokales 

DBS 2 

Lokales 

DBS n 

Abbildung 48: Verallgemeinerung der Dreiebenen-Schema-Architektur 

Globale 

Relation 

R 1 

✰✛ 

Partition 

von R 1 

✸ 

✲ 

P 11 

P 12 

✛ 

✛ 

❨ 

Allokation der 

Partitionen P 1j 

✲ 

✲ 

✸ 

A 111 

A 121 

A 131 

Knoten 

A 

✛ 

✐ 

❦ 

✲ P 13 

✰ ❥A 122 

♦ 

✶A 141 

✮ 

A 151 

P 14 

✼ 

❦ 

✇A 132 

A 142 

P 15 

✴✛ 

✲A 152 

Knoten 

B 

Knoten 

A 

Benutzersicht 

logische 

Aufteilung 

physische 

Speicherung 

Abbildung 49: Partitionierung und Allokation globaler Relationen


wie in Bild 49 sinnvoll. Einheiten der Datenverteilung sind die Partitionen. Wünschenswert ist eine Zerlegung von 

Relationen mit der Selektionsoperation oder mit der Projektionsoperation (horizontale und vertikale Partitionierung). 

Oft wird auch die Partitionierung redundant sein. Eine replizierte Speicherung von Partitionen bietet höhere Freiheitsgrade 

bei der Query-Optimierung, bedingt aber auch einen höheren Änderungsaufwand. Gründe für eine horizontale 

bzw. vertikale Partitionierung sind Lastbalancierung, Nutzung von Lokalität, Reduzierung des Verarbeitungsumfangs 

und Unterstützung von Parallelverarbeitung. 

Anschließend werden Teile der Partitionen Knoten zugeordnet (allokiert). Die Zuordnung ist bestimmt weitgehend 

Ausführungsort von DB-Operationen. Damit erhalten wir widersprechende Teilziele. Zum einem orientieren 

wir uns auf eine Minimierung der Kommunikationskosten, zum anderen jedoch auch auf eine Lastbalancierung. 

Die Partitionierung und Allokation sollte den folgenden Anforderungen genügen: 

Vollständigkeit: : Jedes Datum muß in wenigstens einer Partition enthalten sein. 

Rekonstruierbarkeit: Die Zerlegung sollte verlustfrei sein. 

(Weitestgehende) Disjunktheit: Um durch die Redundanz in den Partitionen nicht einen zu hohen Pflegeaufwand 

in Kauf nehmen zu müssen, sollten die Partitionen disjunkt sein oder es sollten im Falle der Nichtdisjunktheit 

der Partitionen einfache Pflegemechanismen implementierbar sein. Da die Redundanz ggf. auch auf physischem 

Niveau noch beibehalten wird, kann man auch für die logische Aufteilung vereinfachend von einer 

redundanzfeien Partition ausgehen. 

Eine horizontale Partitionierung wird durch Selektionsprädikate R i := σ Pi (R) (1 ≤ i ≤ n) bestimmt. 

Die Forderung nach Vollständigkeit impliziert, daß jedes Tupel einer Partition zugeordnet sein muß, d. h. ∪ n i=1 R i = 

R. Damit ist eine horizontale Zerlegung verlustfrei, falls die Partitionen mit einem Selektionsprädikat definiert sind. 

Die horizontale Partitionierung ist disjunkt, falls R i ∩ R j = ∅ für 1 ≤ i < j ≤ n gilt. 

Die vertikale Partitionierung ist definiert durch das Paar Projektion und Verbund (π, ✶), d. h. 

R i := π X (R) (1 ≤ i ≤ n), R =✶ n i=1 R i . 

Wie auch in der Normalisierung kann eine Verlustfreiheit nur erreicht werden bei Zerlegung nach einer mehrwertigen 

oder funktionalen Abhängigkeit. Oft wird gefordert, daß der Primärschlüssel in alle Partitionen übernommen wird. 

Damit gilt die Verlustfreiheit in jedem Fall. Der Vorteil dieser rigiden Forderung ist die vereinfachte Pflege der 

Integrität. Die Vollständigkeit wird erreicht, wenn jedes Attribut in wenigstens einer Partition enthalten ist. 

Die vertikale Partitionierung kann ebenfalls durch einen SQL-Projektionsausdruck definiert werden. Vertikale 

Partitionierung wird z. Z. von verteilten DBMS nur rudimentär unterstützt. 

Vertikale und horizontale Partitionierung können auch kombiniert werden, wodurch komplexere Partitionen entstehen. 

Gemischte (hybride) Partitionen bestehen aus Bäumen von Partitionen wie in Bild 50. 

R 21 

R 1 R 22 

R 23 

Zerlegung 

der Relation R 

R 

V 

✠ ❘ 

V 

R 2 

H H H 

✠ ❄❘ 

R 21 R 22 R 23 

Partitionierungsbaum 

Abbildung 50: Gemischte Partitionierung 

R 1 

✶ 

✒■ 

∪ 

✒✻■ 

R 21 R 22 R 23 

Rekonstruktionsbaum 

Die Bestimmung geeigneter Partitionierungen kann oft mit einem intuitiven Ansatz erfolgen. In vielen Anwendungen 

reicht es bereits aus, die Partitionierung nach lokalen Zugriffsanforderungen vorzunehmen. Bei komplexeren 

Anwendungen gibt es eine Vielzahl von Einflußgrößen. Dann ist eine systematische Vorgehensweise erforderlich. 

Dazu werden die Anwendungen analysiert nach einer Reihe von Parametern: 

• Art des Zugriffs (lesend oder schreibend);


• Häufigkeit der Operationen; 

• Auswahlbedingungen der Anfragen; 

• betroffene Relationen und innerhalb dieser Gruppen von Attributen; 

• zu übertragende Datenmengen. 

Auf der Grundlage dieser Entwurfsinformationen wird untersucht, ob eine Partitionierung sinnvoll wird, z. B. durch 

eine geringere Anzahl von Zugriffen. Wird die Zugriffshäufigkeit durch Selektionsprädikate geringer oder die Zugriffsbreite 

(Arität der Tupel) geringer durch vertikale Partitionierung, dann führt eine Partitionierung zu einem Performanzgewinn. 

Die Bestimmung horizontaler und vertikaler Partitionen kann mit einem Rückgriff auf die Booleschen Funktionen 

berechnet werden. Wir deuten dieses Verfahren hier kurz an. Es ist den Verfahren zur Optimierung Boolescher 

Schaltkreise entlehnt. 

Wir betrachten dazu zuerst die horizontale Partitionierung. Jeder Selektionsausdruck, der zur horizontalen Partitionierung 

verwendet wird, hat eine induktive Struktur, die auf der Grundlage von Elementartermen der Form Aωa 

mit a ∈ dom(A) und ω ∈ {, ≤, ≥, =, ≠} definiert sind. Die Menge der Elementarterme α 1 , ..., α k kann zur 

Darstellung der Selektionsausdrücke in disjunktiver Normalform benutzt werden. Die Elementarausdrücke werden 

mit der Aufrufhäufigkeit und der Selektivität gewichtet. Mit diesen Angaben kann eine Partitionierung bestimmt 

werden, bei der eine Partition nicht in unterschiedlicher Weise von zwei (oder mehr) der unterstellten Anfragetypen 

referenziert wird und sich für die Tupel einer Partition in etwa die gleiche Zugriffshäufigkeit ergibt. Mit den verwendeten 

Selektionsausdrücke können nun die Monome herausgefiltert werden, die nun ihrerseits als Komponenten der 

Selektionsausdrücke benutzt werden. 

Abgeleitete horizontale Partitionen werden analog zu obigen Verfahren in die Partitionierung einbezogen. Es wird 

am einfachsten dazu das ER-Schema herangezogen. Damit läßt sich der Effekt einer Partitionierung auf andere Relationen 

relativ einfach bestimmen. Daraus können über die Fremdschlüssel-Beziehungen Partitionierungen abgeleitet 

werden für die referenzierenden Relationen. Diese werden wiederum so behandelt wie bereits zuvor die Relationen 

für den Fall der horizontalen Partitionierung. Eine Zusammenführung mit den referenzierten Relationen erfolgt dabei 

über den Semi-Verbund. 

Die vertikale Partitionierung ist ein relativ komplexes Optimierungsproblem. Es werden oft statt einer exakten 

Lösung dafür heuristische Verfahren verwandt, die z. B. die Zugriffshäufigkeiten auf Attributgruppen benutzen, um 

eine Attributgruppierung abzuleiten. 

Nachdem eine Partionierung bestimmt wurde, können die einzelnen Partitionen Knoten des Netzes zuordnet werden. 

Die Allokation erfordert eine Optimierungstrategie. Optimierungsziele dabei sind u.a. die Unterstützung kurzer 

Antwortzeiten bzw. eines hohen Durchsatzes, die Minimierung des Kommunikationsbedarfs und die Lastbalancierung. 

Das Optimierungsmodell basiert demzufolge auf einer Minimierung einer Kostenfunktion unter Einhaltung von 

Randbedingungen. Hauptkomponenten der Kostenfunktion sind demzufolge als negativer Faktor die Kommunikationskosten, 

als positiver Faktor der Umfang der lokalen Verarbeitung und als Nebenbedingung Das Nichtüberschreiten 

von Grenzwerten zur Auslastung einzelner Rechner. Plazierungsaspekte sind zum einem die Effizienz, d. h. insbesondere 

die Minimierung der Remote-Zugriff-Kosten und die Vermeidung von Engpässen in der Kommunikation und 

bei den lokalen Rechnern, und zum anderen die Datensicherheit z. B. durch Auswahl von Knoten unter Verläßlichkeitsaspekten 

und durch redundante Speicherung von Daten. Bei der Plazierung können zwei Hauptansätze verfolgt 

werden: 

• nicht-redundante Allokation (Plazierung) mit einem ggf. höheren Kommunikationsaufwand und 

• redundante Allokation (Platzierung) mit einem ggf. höheren Pflegeaufwand. 

Das mathematische Modell für die nicht-redundante Allokation benutzt die folgenden Parameter: 

• K : Anzahl der Knoten im Netz; 

• P : Anzahl von zu allokierenden Partitionen der globalen Relationen;


• T : Anzahl der Typen von Lese- und Änderungsoperationen auf den globalen Relationen; 

• M i : maximale Speicherkapazität in den Dateneinheiten am Knoten i (1 ≤ i ≤ K); 

• S i : Speicherkosten pro Dateneinheit am Knoten i (1 ≤ i ≤ K); 

• U ij : Übertragungskosten pro Dateneinheit vom Knoten i nach Knoten j (1 ≤ i, j ≤ K, i ≠ j); 

• G p : Größe in Dateneinheiten der Partition p (1 ≤ p ≤ P ); 

• O tp : Größe in Dateneinheiten einer Teiloperation (d. h. einer Anfragezeichenkette) vom Typ t gegen die 

Partition p (1 ≤ p ≤ P , 1 ≤ t ≤ T ); 

• R tp : Größe in Dateneinheiten des Resultats einer Teiloperation (d. h. einer Anfragezeichenkette) vom Typ t 

gegen die Partition p (1 ≤ p ≤ P , 1 ≤ t ≤ T ); 

• H it : Häufigkeit, mit der Operationen vom Typ t am Knoten i gestellt werden (1 ≤ i ≤ K, 1 ≤ t ≤ T ); 

• V pi : charakteristische Funktion der Verteilung der Partition auf die Knoten, wobei V pi = 1 gilt , falls die 

Partition p am Knoten i allokiert ist und V pi = 0 sonst für (1 ≤ p ≤ P , 1 ≤ i ≤ K). 

Bei Leseoperationen gilt typischerweise R tp >> O tp . Damit kann u. U. auch der Faktor O tp vernachlässigt werden. 

Bei Änderungsoperationen kann dagegen O tp relativ groß werden, während R tp lediglich eine Bestätigung für die 

Durchführung der Operation beschreibt. 

Damit entstehenden die folgenden Kostenbestandteile: 

Speicherkosten: Σ S = ∑ P 

p=1 G p 

∑ K 

i=1 V piS i 

Übertragungskosten: Σ U = 

∑ P ∑ K ∑ K ∑ T 

p=1 i=1 j=1 t=1 H itO tp V pj U ij + ∑ P ∑ K ∑ K ∑ T 

p=1 i=1 j=1 t=1 H itR tp V pj U ji 

Nebenbedingung für die nicht-redundante Speicherung: ∑ K 

i=1 V pi = 1 für alle p (1 ≤ p ≤ P ) 

Nebenbedingung für maximale Speicherkapazitäten: ∑ P 


Damit ist das Optimierungsproblem für die nicht-redundante Allokation als Minimierungsaufgabe gegeben, bei der 

die Funktion 

Σ S + Σ U , 

d. h. die Funktion 

P∑ 

∑ 

K 

G p 

p=1 i=1 

V pi S i + 

P∑ 

K∑ 

K∑ 

p=1 i=1 j=1 t=1 

T∑ 

H it O tp V pj U ij + 

P∑ 

K∑ 

K∑ 

p=1 i=1 j=1 t=1 

T∑ 

H it R tp V pj U ji 


(i) ∑ K 

i=1 V pi = 1 für alle p (1 ≤ p ≤ P ) und 

(ii) ∑ P 



Bei hinreichend guten Abschätzungen für die einzelnen Parameter kann das Optimierungsproblem durch Optimierungswerkzeuge 

gelöst werden, wobei durch die Komplexität der Kostenfunktion mit erheblichen Rechenaufwand 

zu rechnen ist. Es kann sowohl die Knotentopologie als auch die Partitionierung als dynamischer Parameter in das 

Optimierungsproblem einfließen. Neuere Algorithmen der Genetischen Programmierung und der Heuristik versprechen 

hier Abhilfe. 

Das Kostenmodell für die redundante Allokation ist bezüglich der Speicherkosten und der Nebenbedingung für 

die maximale Speicherkapazitäten gleich. Ändern müssen sich jedoch die beiden anderen Größen:


Übertragungskosten: Wir unterscheiden hier nach den Operationen. Es gibt T L Leseoperationen auf den globalen 

Relationen und T S Änderungsoperationen auf den globalen Relationen, wobei T = T L + T S gilt. 

Eine Leseoperation gegen die Partition p wird an denjenigen Knoten i gesandt, von dem das Resultat mit den 

geringsten Kosten erhalten werden kann. Damit erhalten wir 

Σ L U = ∑ P ∑ K ∑ T L 

p=1 i=1 t=1 H it min K j=1, V pj =1 (O tpU ij + R tp U ji ) 

Eine Änderungsoperation gegen die Partition p wird an alle Knoten gesandt, an denen die Partition p allokiert 

ist. Damit erhalten wir 

Σ S U = ∑ P ∑ K ∑ T S 

p=1 i=1 t=1 H ∑ K 

it j=1, V pj =1 (O tpU ij + R tp U ji ) 

Nebenbedingung für die nicht-redundante Speicherung: ∑ K 

i=1 V pi ≥ 1 für alle p (1 ≤ p ≤ P ), weil jede 

Partition an mindestens einem Knoten allokiert sein muß. 

Damit ist das Optimierungsproblem für die redundante Allokation als Minimierungsaufgabe gegeben, bei der die 

Funktion 

Σ S + Σ L U + Σ S U 


(i) ∑ K 

i=1 V pi ≥ 1 für alle p (1 ≤ p ≤ P ) und 

(ii) ∑ P 



Man ist damit von Ansatz her in der Lage, eine optimale Lösung exakt zu berechnen, falls alle Parameterwerte 

hinreichend genau bestimmt werden können. Man kann in der Verfeinerung noch Transaktionen und die interne 

Anfrageoptimierung der lokalen Rechner berücksichtigen, womit die Optimierungsaufgabe jedoch wesentlich komplexer 

wird und das Allokationsproblem nicht mehr dynamisch behandelt werden kann. Deshalb werden meist heuristische 

Verfahren in der Praxis angewandt, die im Wesentlichen an den obigen Optimierungsverfahren angelehnt 

sind, jedoch die Lastverteilung an der Zugriffsfrequenz optimieren. Es wird zunächst die Partition mit der höchsten 

Zugriffsfrequenz betrachtet. Danach werden die lokalen Zugriffsfrequenzen berechnet. Eine Allokation wird nach 

dem Zugriffsgewicht zugeordnet. 

8.12.10 Verteilte Anfragenbearbeitung 

Zur optimalen verteilte Anfragebearbeitung wird eine Ausführungsplan in Abhängigkeit von der Datenverteilung 

bestimmt. Kostenfaktoren sind Übertragungskosten (Nachrichtenanzahl, Nachrichtenumfang), I/O-Kosten, die Geschwindigkeit 

insbesondere Antwortzeiten und ggf. CPU-Bedarf und Hauptspeicherbedarf. Zur Auswahl der optimalen 

Strategie sind eine Reihe von Entscheidungen zu treffen: 

◦ Anfrage-Zerlegung in lokal ausführbare Teilanfragen; 

◦ Ausführungsreihenfolge für Selektion, Projektion und Join; 

◦ Nutzung von Indexstrukturen; 

◦ Parallelisierung von Teilanfragen; 

◦ Auswahl der globalen und lokalen Join-Strategie (Nested-Loop, Sort-Merge, 

Hash-Join); 

◦ Rechnerauswahl, z. B. zur Join-Berechnung; 

◦ Auswahl der Replikate. 

Diese Entscheidungen können schrittweise getroffen werden, so daß ein Phasenmodell zur Berechnung nach Bild 51 

realisiert werden kann. Das Phasenmodell mündet in folgende Schrittfolge: 

1. Prüfung der Anfrage auf syntaktische und semantische Korrektheit; 

2. Transformation globaler Anfragen in lokal ausführbare Anfragen mit algebraischen Termersetzungstechniken;


globale Anfrage 

Dialekt der DB-Sprache 

globales Schema 

Verteilungsschema 

globale Statistiken 

lokales Schema 

✲ 

✲ 

✲ 

✲ 

✲ 

❄ 

Anfrage-Parsing 

validierte globale 

❄ 

Anfrage 

Anfragetransformation 

algebraischer 

❄ Ausdruck 

Daten-Lokalisierung 

Partition- 

❄ 

Ausdruck 

globale Optmierung 

global optimierter 

❄Partition-Ausdruck 

lokale Optimierung 

❄ 

optimierte lokale Anfrage 

Abbildung 51: Phasen der verteilten Anfragebearbeitung 

3. Lokalisierung der Daten in den einzelnen Knoten; 

4. Vereinfachung der Anfrageausdrücke mit Methoden der algebraischen Optimierung, z. B. Vereinfachung von 

Algebra-Ausdrücken und Elimination redundanter Teilausdrücke; 

5. Bestimmung der Berechnungsverfahren für Operationen, insbesondere des Verbundes; 

6. Bewertung und Auswahl von Ausführungsstrategien mit den Kostenparametern, ggf. Abschätzung von Zwischenergebnisgrößen 

und einem Abwägen zwischen Funktionsexport und Datenexport. 

Wünschenswert - aber nicht immer realistisch - ist dabei auch eine Berücksichtigung des aktuellen Systemzustandes 

zur Laufzeit. 

In der Phase der Anfragetransformation wird 

• eine Interndarstellung für die Anfrage (z. B. in der Relationenalgebra) erzeugt, 

• eine Namensauflösung anhand des globalen Schemas ausgelöst, 

• die Anfrage semantisch analysiert, 

• die Anfrage normalisiert und 

• algebraisch vereinfacht unter Benutzung der Äquivalenzregeln der Operationenalgebra. 

Literatur 

[Dad96] P. Dadam. Verteilte Datenbanken und Client/ServerSysteme. Springer, Berlin, 1996. 

[KE96] A. Kemper and A. Eikler. Datenbanksysteme. Oldenbourg-Verlag, München, 1996. 

[Rah94] 

E. Rahm. Mehrrechner-Datenbanksysteme: Grundlagen der verteilten und parallelen Datenbankverarbeitung. 

Addison-Wesley, Bonn, 1994.


[Sch96] Alexander Schill. Rechnergestützte Gruppenarbeit in verteilten Systemen. Prentice Hall, München, 1996. 

[SYea03] J.E. Safra, I. Yeshua, and et. al. Encyclopædia Britannica. Merriam-Webster, 2003.






D - 24098 Kiel 

 





9. Methodik ab SS 2012 


Forschung 



9 Systematische Entwicklung von Informationssystemen 

Nicht Kunst und Wissenschaft allein, 

Geduld will bei dem Werke sein. 

Goethe, Faust, Erster Teil, Hexenküche, Mephistopheles 

Literatur

Analysis, Design and Development of Information Systems ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?