• Kurzinfo
• Erläuterung
• Fazit
• Literatur
• Autor & Copyright

Kurzinfo Ein Schema (Muster, Entwurf) dient der modellhaften Beschreibung realer Sachverhalte. Mit Hilfe solcher Modelle kann der Mensch in seiner täglichen Arbeit unterstützt werden. So gibt es z.B. Datenbankschemata zur Beschreibung von Daten und deren Beziehung untereinander und Workflow-Schemata zur Modellierung von Arbeitsprozessen (engl. workflow).

Erläuterung

Ein Workflow-Schema legt unter anderem fest, welche Aktivitäten in welcher Reihenfolge zur Ausführung kommen.

Dadurch ist für Workflow-Instanzen, die ausgehend von diesem Workflow-Schema erzeugt und ausgeführt werden, klar, ob sie parallele oder alternative Ausführungspfade aufweisen und welche externen Programme ggf. mit einer bestimmten Aktivität verknüpft sind. Durch das Workflow-Schema sind also bereits zur Modellierungszeit alle zur Laufzeit möglichen Ausführungsvarianten bestimmt.

Sowohl Datenbank- als auch Workflow-Schemata beschreiben in der Regel Sachverhalte aus der realen Welt. Wenn sich diese Sachverhalte andern oder neue Aspekte hinzukommen, müssen unter Umständen auch die Schemata angepasst werden. Bei der Evolution von Datenbank-Schemata geht es dabei fast ausschließlich darum, die Datentypen, Datenstrukturen und Integritatsbedingungen des „alten" Datenbank-Schemas (möglichst)semantikerhaltend auf die entsprechenden Datentypen, Datenstrukturen und Integritätsbedingungen des „neuen" Datenbank--Schemas abzubilden.

Dagegen bedeutet im einfachsten Fall (!)eine Workflow-Schema-Änderung, dass es für eine gewisse Zeit Workflow-Instanzen geben wird, die noch nach dem alten Schema, und solche, die (weil nach der Schemaänderung gestartet)nach dem neuen Schema abgewickelt werden. In vielen Fallen reicht dieses einfache Koexistenzmodell jedoch nicht aus, sei es, weil sich z.B. gesetzliche Rahmenbedingungen geändert haben oder weil das alte Workflow-Schema gravierende Mangel aufweist.

Soll eine Schemaänderung also auch auf die bereits laufenden Instanzen angewendet werden, spricht man von Workflow-Schemaevolution [1, 6].

Um zu verstehen, was bei einer Workflow-Schemaevolution zu leisten ist, stellt man sich eine Workflow-Instanz am besten als ein in Ausführung befindliches Programm vor, das aus einer Folge von Prozeduren besteht. Diese werden entweder nacheinander gerufen (sequenzielle Ausführung)oder treten in einer If-then-else-Bedingung auf (alternative Verzweigung) oder können auch parallel zur Ausführung kommen. Bei einer Workflow-Schemaevolution wird nun versucht, in einem solchen Programm ein oder mehrere neue Prozeduren einzufügen, zu löschen, zu verschieben, Verzweigungsbedingungen zu ändern, parallele Pfade hinzuzufügen oder zu löschen; und zwar so, dass eine zuvor korrekte Parameterversorgung aller Prozeduren unter allen Ausführungsalternativen auch nach der Änderung gewährleistet ist. Hierbei ist zu beachten, dass diese Instanzen alle unterschiedlich weit in ihrer Ausführung sind und dass die Anwendbarkeit einer Schemaevolution auf eine bestimmte Workflow-Instanz davon abhängt, wie weit deren Ausführung bereits fortgeschritten ist [6, 7].So macht z.B. die Einfügung des Schrittes „Sendung kontrollieren" in Abb.1 gemäß des neuen Workflow-Schemas nur für solche Workflow-Instanzen Sinn, bei denen der Schritt „Ware versenden" noch nicht ausgeführt worden ist.

Den oben beschriebenen Sachverhalt (Propagation von Schemaänderungen bezeichnet man in der Literatur auch als dynamischen Fall [3]. Grundlegende Herausforderungen sind hier, zu jedem Zeitpunkt Korrektheit und Konsistenz zu gewährleisten und die Migrationen -besonders bei einer großen Anzahl von Workflow-Instanzen - automatisch und effizient durchzuführen [6]. Betrachtet man dagegen nur die erforderlichen Strukturtransformationen ohne Berücksichtigung des Zustands, spricht man vom statischen Fall.

In der Forschung befasst man sich schon seit einiger Zeit mit Workflow-Systemen, die es erlauben, im Einzelfall ad hoc vom geplanten Ablauf abzuweichen [2, 4, 5]. Nur mit einer Funktionalität dieser Art werden Workflow-Management-Systeme wirklich breit einsetzbar werden. Die große Herausforderung besteht darin, eine Schemaevolution der oben beschriebenen Art zukünftig auch auf Instanzen anwendbar zu machen, deren „Instanz"-Schema durch Ad-hoc-Änderungen inzwischen vom Originalschema des Workflow-Typs abweicht. Die spannende Frage hier ist, welche Propagationen man noch zulassen soll und welche nicht mehr.

Wenn eine Ad-hoc-Änderung die Schemaänderung beispielsweise bereits vorweggenommen hat, dann sollte die Schemaänderung natürlich nicht mehr auf diese Instanz angewendet werden. Betreffen Schemaänderung und Ad-hoc-Änderung dagegen unterschiedliche Bereiche einer Workflow-Instanz, sollte eine Propagation sehr wohl - wenn sonst nichts dagegen spricht - erfolgen können.

Fazit

Zusammenfassend kann gesagt werden, dass Schemaevolution in Workflow-Management-Systemen aufgrund des dynamischen Charakters von Prozessen neuartige und interessante Fragestellungen aufwirft. Diese zu lösen, wird für zukünftige prozessorientierte Informationssysteme essenziell sein, damit die realisierten Anwendungen rasch und kostengünstig an neue Gegebenheiten angepasst werden können.

                   Artikelanfang  Seitenanfang

Literatur

1. van der Aalst, W. M.P., Basten, T.: Inheritance of workflows: an approach to tackling problems related to change. Theoretical Computer Science, 2002
2. van der Aalst, W. M.P., Jablonski, S.: Dealing with workflow change: Identification of issues and solutions. Int. J. Computer Syst., Science and Engineering 15(5), 267–276 (2000)
3. Casati, F., Ceri, S., Pernici, B., Pozzi, G.: Workflow evolution. Data and Knowledge Engineering 24(3), 211–238 (1998)
4. Müller, R., Rahm, E.: Dealing with logical failures for collaborating workflows. Proc. Int. 5th Conf. on Coop. Inf. Syst., Eilat, 2000, pp. 210–223
5. Reichert, M., Dadam, P.: ADEPT flex – Supporting dynamic changes of workflows with-out losing control. J. Intelligent Inf. Syst. 10(2), 93–129 (1998)
6. Rinderle, S., Reichert, M., Dadam, P.: Effiziente Verträglichkeitsprüfung und automati-sche Migration von Workflow-Instanzen bei der Evolution von Workflow-Schemata. Informatik – Forschung und Entwicklung 17(4), 177–197 (2002)
7. Sadiq S., Marjanovic O., Orlowska M.: Managing change and time in dynamic workflow processes. The Int. Journal of Coop. Inf. Syst. 9(1, 2) (2000)

                   Artikelanfang  Seitenanfang

Autor & Copyright

Stefanie Rinderle rinderle@informatik.uni-ulm.de
Peter Dadam dadam@informatik.uni-ulm.de
Abt. Datenbanken und Informationssysteme,
Universität Ulm

© 2003 Informatik Spektrum, Springer-Verlag Berlin Heidelberg

                   Artikelanfang  Seitenanfang

Security Patterns

• Kurzinfo
• Erläuterung
• Diskussion
• Literatur
• Autor & Copyright

Kurzinfo Obwohl Sicherheit heute eine obligatorische Eigenschaft moderner, verteilter Anwendungen sein sollte, können wir beobachten, dass wir von einem adäquaten Sicherheitsniveau weit entfernt sind: Die gleichen Fehler treten immer wieder auf, wie beispielsweise Buffer Overflows in Anwendungen oder Standardpasswörter in IT-Systemen.

Erläuterung

Während Kodierungsfehler grundsätzlich automatisch erkannt werden können, ist es eher schwierig, Sicherheit auf der Entwurfsebene - richtig - zu machen. Gründe dafür sind u.a. in dem menschlichen Verhalten beim Problemlösen zu suchen [2]. So werden Probleme oftmals ad hoc gelöst, ohne dass Nebenwirkungen berücksichtigt werden. Problematisch ist auch die Einstellung, Fehler bewusst in Kauf zu nehmen und erst zu beheben, wenn sie (oft zufällig) entdeckt werden. Wir glauben daher, dass nur erfahrene Experten Sicherheitsanforderungen analysieren, zuverlässig Sicherheitslücken aufdecken und IT-Systeme mit - guter - Sicherheit entwerfen und betreiben können [5].

Patterns, die bisher hauptsächlich beim objektorientierten Softwareentwurf eingesetzt wurden, stellen eine Möglichkeit dar, dieses Problem zu lösen. Sie sind ein Konzept, um immer wieder auftretende Probleme sowie bewährte Lösungen schriftlich zu dokumentieren. In strukturierter Form wird festgehalten, in welchem Kontext das Problem auftritt, welche Anforderungen (engl. forces) zu beachten sind und welche Lösungen sich dafür anbieten.

Da Patterns von Experten geschrieben und diskutiert werden, können Laien von deren Wissen und Expertise profitieren. Daher bietet es sich an, diesen Ansatz systematisch auf den Problembereich Sicherheit zu übertragen und bestehende Werkzeuge und Prozesse auf diese Weise sinnvoll zu ergänzen.

Grundlagen von Security Patterns

Security Patterns weisen eine Struktur auf, die mit herkömmlichen (Design) Patterns vergleichbar sind. Die Bedeutung der Elemente im Hinblick auf den Sicherheitsaspekt wird im Folgenden kurz vorgestellt.

Kontext Der Kontext eines Security Patterns kann mit einem Beispielszenario illustriert werden. Mit Hilfe einer Aufzählung der Annahmen können Aspekte der Umgebung, in der das IT-System benutzt werden soll, beschrieben werden. Oftmals müssen IT-Systeme bestimmten Sicherheitsvorgaben entsprechen. Eine optionale Beschreibung solcher Aussagen erleichtert daher die eindeutige Bestimmung der Schutzziele.

Problem Der Kern von Sicherheitsproblemen bilden Bedrohungen, da ein IT-System grundsätzlich nur dann als sicher gelten kann, wenn Maßnahmen gegen alle bekannten Bedrohungen getroffen werden. Optional können ebenfalls Schutzziele, die ein komplementärer Begriff zu den Bedrohungen sind, formuliert werden. Nur wenn ein bestimmtes Schutzziel gilt, wird eine Bedrohung auch als Gefahr betrachtet.

Anforderungen Verschiedene Anforderungen beeinflussen unmittelbar die Lösung. Dazu gehören Sicherheitsanforderungen sowie andere Anforderungen, die durch die Forderung nach Sicherheit beeinflusst werden, wie z.B. Benutzbarkeit oder Performanz.

Lösung Entsprechend der Anforderungen werden Maßnahmen aufgeführt, die das Problem im jeweiligen Kontext lösen, d.h. die Risiken auf ein Minimum reduzieren. Dabei sollte es mindestens eine Maßnahme für jede Bedrohung bzw. jeden Angriff geben. An dieser Stelle bietet es sich auch an, Vor- und Nachteile der Anwendung eines Security Patterns zu diskutieren.

Verwandte Patterns Da Maßnahmen einerseits den Kontext ändern und andererseits zu neuen Problemen führen können, sind in diesem Fall Abhängigkeiten zu weiteren Security Patterns anzugeben. Da Patterns bewährte Sicherheitslösungen beschreiben, werden sie nicht erfunden, sondern gefunden. Sicherheitsstandards wie etwa der British Standard 7799 oder das IT-Grundschutzhandbuch sind daher wertvolle Orientierungshilfen bei der Dokumentation von Security Patterns. Weitere Ressourcen sind Informationsquellen wie z.B. einschlägige Web-Seiten und Mailing-Listen sowie relevante Artikel oder Bücher. Interne Informationsquellen sind die Mitarbeiter eines Unternehmens, die am besten wissen, - wie es schon immer gemacht worden ist - und dies auch begründen können.

Security Patterns können - im Gegensatz zu den meisten objektorientierten Design Patterns - in verschiedenen Phasen des Lebenszyklus eines IT-Systems angewendet werden. So gibt es neben Security Patterns, die Lösungen für sicherheitsrelevante Programmierprobleme beschreiben (z.B. Zugriffskontrolle auf Objektebene), auch Security Patterns, die als Lösung Konfigurationen oder Betriebskonzepte vorhandener IT-Systeme oder Anwendungen beschreiben.

Beispiel: Handhabung von Cookies

Kontext Serveranwendungen verwenden Cookies, um Informationen über Klienten abzuspeichern und abzufragen. Ein Server verwendet den HTTP-Header, um ein Cookie dauerhaft bei dem Klienten zu platzieren und so Informationen wie beispielsweise eine eindeutige Benutzerkennung zu hinterlegen. Fragt der Klient eine weitere Seite von dem Server an, wird das Cookie automatisch mit der HTTP-Anfrage versendet.

Problem Zum Schutz der Benutzer wurde vereinbart, dass ein Cookie nur von dem Server gelesen werden kann, der es erzeugt hat. Weiterhin dürfen nur Informationen, die entweder vom Klient oder vom Server erzeugt worden sind, ausgetauscht werden. Diese Konventionen genügen jedoch nicht, um die Privatsphäre des Anwenders zu schützen.

Folgende Bedrohungen können identifiziert werden:

• Dienstanbieter können die Aktivitäten eines Benutzers verfolgen und somit Profile erstellen.
• Benutzerdaten von verschiedenen Anbietern können zusammengeführt werden. Dies geschieht z.B. bei weltweit operierenden Werbungsfirmen wie AdDoubleclick.
• Mit Hilfe von HTML-basierten E-Mail-Nachrichten können Cookies ohne Wissen des Benutzers personalisiert werden.

Anforderungen Folgende Anforderungen müssen berücksichtigt werden:

• Anonymität: Dienstanbietern und andere Benutzern soll es nicht möglich sein, die Identität eines Benutzers aus einer HTTP-Anfrage abzuleiten. Ein Dienst darf weiterhin nicht den richtigen Benutzernamen offen legen.
• Unverknüpfbarkeit: Ein Benutzer sollte mehrere HTTP-Anfragen stellen können, ohne dass diese miteinander in Verbindung gebracht werden.
• Benutzbarkeit: Viele Angebote sind nicht benutzbar, wenn Cookies nicht akzeptiert werden. Außerdem möchten Benutzer oft keine zusätzliche Software kaufen und installieren bzw. Änderungen in der Konfiguration vornehmen.

Lösung Die Verwendung von Cookies muss aufseiten des Benutzers eingeschränkt werden. Nahezu alle Web-Browser erlauben es, Cookies von Fall zu Fall zu aktivieren. Der Benutzer muss dann immer entscheiden, ob er einem Anbieter vertraut oder nicht. Cookies können auch periodisch gelöscht werden, so dass die Erstellung von Profilen nicht mehr möglich ist. Diese Variante wird z.B. von Programmen wie Opera oder Junkbuster unterstützt. Maximaler Schutz ergibt sich, wenn Cookies grundsätzlich deaktiviert werden.

Der Schutz der Privatsphäre ist immer mit Kompromissen verbunden. Je stärker die Verwendung von Cookies eingeschränkt wird, desto stärker wird die Benutzbarkeit eines auf Cookies basierenden WWW-Angebotes beeinträchtigt.

Beispiel: Patternsystem für sichere Anwendungen

Security Patterns existieren nicht isoliert voneinander. Mehrere zusammenhängende Security Patterns, die gemeinsam ein größeres Problem lösen, werden auch als Security-Pattern-System bezeichnet. Die Patterns des Security-Pattern-Systems von Yoder und Barcalow [6], bei denen es um Sicherheit in Anwendungen geht, werden im Folgenden kurz einzeln vorgestellt (s. auch Abb. 1).

Einzelner Zugangsweg Es ist schwierig, ein Anwendung abzusichern, die prinzipiell beliebig viele Zugangspunkte hat. Als Lösung hat sich daher die Beschränkung auf einen einzelnen Zugangsweg bewährt.

Prüfstelle Verschiedene Anwender haben unterschiedliche Sicherheitsanforderungen. Nun tritt das Problem auf, wie diese unabhängig von dem Entwurf der Anwendung realisiert werden können. Als Lösung wird die Kapselung eines entsprechenden Verfahrens, das die Sicherheitsanforderungen eines Unternehmens umsetzt, vorgeschlagen.

Rollen Die Verwaltung von Benutzern, die jeweils unterschiedliche Rechte haben, ist ab einer gewissen Menge nicht mehr handhabbar. Mit Hilfe von Rollen wird daher eine Gruppierung von Benutzern mit vergleichbaren Rechten vorgenommen.

Sitzungen Verschiedene Module einer Anwendung benötigen Zugriff auf sicherheitsrelevante Informationen, wie z.B. die Benutzeridentität. Es hat sich bewährt, solche Informationen global mit Hilfe eines Sitzungskonzeptes zu kapseln und abhängig von den Rechten eines Benutzers lokal zugreifbar zu machen.

Volle Ansicht mit Fehlermeldungen Benutzer dürfen Operationen nur dann aufrufen, wenn sie die entsprechenden Rechte besitzen. Abhängig von diesen Rechten können daher Fehlermeldungen angezeigt werden, sobald versucht wird, - illegale - Operationen aufzurufen.

Limitierte Ansicht Eine alternative Lösung ist es, dem Benutzer entsprechend seiner Rechte lediglich die Operationen anzubieten, die er durchführen darf.

Sichere Zugangsschicht Anwendungen können nur so sicher sein wie ihre Umgebung. Auf Basis von externen Sicherheitsmechanismen - etwa auf Ebene von Betriebssystem, Netzwerk oder Datenbanken - sollte daher eine sichere Zugangsschicht aufgebaut werden, um die Nachrichten von und zu der Anwendung zu schützen.

Ein Vorteil eines solchen Pattern-Systems ist beispielsweise, dass aus der Anwendung eines Patterns umgehend ersichtlich ist, welche weiteren Patterns noch berücksichtigt werden müssen. Ein anderer Vorteil ist, dass erkannt werden kann, welche Auswirkungen ein Fehler in der Implementierung eines Security Patterns haben kann.

Diskussion

Bei den vorangegangenen Beispielen wird dem Leser zunächst verdeutlicht, welche Probleme überhaupt auftreten können. Es wird auch gezeigt, welche Auswirkungen die unterschiedlichen Lösungsvarianten haben. Solche Security Patterns sind ein Hilfsmittel, um Sicherheitsprobleme effizient identifizieren, benennen und diskutieren zu können.

Selbst Laien sollte es so grundsätzlich möglich sein, Probleme strukturiert zu lösen sowie entsprechende Abhängigkeiten und Konsequenzen zu berücksichtigen.

Dem Thema Security Patterns wird von Forschern und Praktikern ein zunehmendes Interesse entgegengebracht (siehe z.B. [3]). Seit dem ersten Beitrag zum Thema Security Patterns im Jahr 1997 wurden immer wieder Publikationen zu dem Thema veröffentlicht. Heute ist eine ganze Reihe von einzelnen Security Patterns und Pattern-Systemen bekannt (siehe z.B. [1] und [4]). Dennoch bleiben einige Fragen offen, insbesondere um die Verwaltung und Anwendung von Security Patterns verbessern zu können:

• Welche weiteren Eigenschaften zeichnen ein Security Pattern aus? Wo sind die Unterschiede zu herkömmlichen Entwurfsmustern?
• Welche Attribute können zur Klassifizierung von Security Patterns herangezogen werden?
• Um die Integration einzelner Security Patterns zu einem umfangreichen Katalog zu erleichtern, muss die Diskussion über eine einheitliche Struktur fortgeführt werden.
• Es müssen viele weitere Security Patterns identifiziert und dokumentiert werden.

Wenn es einmal eine hinreichend große Menge von Security Patterns gibt, könnte sich solch ein Katalog von Problemen und bewährten Lösungen als nützliches Hilfsmittel erweisen, um die Lücke zwischen theoretischen Sicherheitskonzepten und dem Tagesgeschäft in Unternehmen zu schließen.

                   Artikelanfang  Seitenanfang

Literatur

1. Security Patterns Community: Security Patterns Homepage.
   http://www.security-patterns.de (2002)
2. Dörner, D.: Die Logistik des Mißlinges – Stragtegisches Denken in komplexen Situa-tion. Reinbek: Rowohlt Tachenbuch Verlag 1999
3. Fernandez, E. B.: Patterns for Secure System Design.
   http://www.cse.fau.edu/~ed/SecPatterns.pdf (2001)
4. The Open Group: Guide to Security Patterns.
   http://www.opengroup.org/secu-rity/gsp.htm (2002)
5. Schumacher, M., Rödig, U.: Security Engineering with Patterns. 8th Conference on Pat-tern Language of Programs (PLoP), Monticello/IL, 2001
6. Yoder, J., Barcalow, J.: Architectural Patterns for Enabling Application Security. 4th Conference on Patterns Languages of Programs (PLoP), Monticello/IL, 1997

Hinweis: Die URLs entsprechen dem Stand bei der Veröffentlichung des Artikels und werden nicht aktualisiert.

                   Artikelanfang  Seitenanfang

Autor & Copyright
Markus Schumacher
Technische Universität Darmstadt
Fachbereich Informatik (ITO)
ms@ito.tu-darmstadt.de

© 2002 Informatik Spektrum, Springer-Verlag Berlin Heidelberg

                   Artikelanfang  Seitenanfang

Semistrukturierte Daten

• Kurzinfo
• Erläuterung
• Literatur
• Autor & Copyright

Kurzinfo Wie die meisten Forschungsgebiete der Informatik wurde die Datenbankforschung zuerst vorwiegend vom Paradigma einer zentralen Verwaltung geprägt.

Erläuterung

Diese Sicht wurde zunehmend in Frage gestellt. Der Ansatz der semistrukturierten Daten seit Mitte der 90 er Jahre ist ein weiterer Schritt in diese Richtung. Ausgangspunkt war die Verwaltung von Inhalten im dezentralen WWW und die Datenmodellierungssprache XML [8]. In den Ansatz „semistrukturierte Daten" führt das Buch von Abiteboul et al. [5] ein.

Ein traditionelles Datenbanksystem setzt voraus, dass die gespeicherten Daten gemäß einem im Voraus festgelegten Datenschema strukturiert sind. Schemata erleichtern die Datenspeicherung und dienen der Anfrageauswertung. Im dezentral verwalteten WWW sind Schemata oft zu restriktiv. In vielen Bereichen wie in der Bioinformatik werden Daten in heterogenen Formaten zwischen Datenbanken oder sonstigen Anwendungen ausgetauscht, denen kein einheitliches Schema zugrunde liegt, weswegen solche Daten zunächst „unstrukturiert", danach „semistrukturiert" genannt wurden [4].

Oft haben zudem die Daten eine Struktur, die mit den flachen Tupeln des relationalen Datenmodells nur unzutreffend wiedergegeben werden kann. Auch das Objektmodell ist oft ungeeignet: Zwar kann man damit auch „tiefe" Strukturen repräsentieren, allerdings keine unregelmäßige Strukturen mit fehlenden oder wiederholten Komponenten. Fehlt das Schema, so muss zudem die Bedeutung der Struktur in den Datensätzen selbst wiedergegeben werden. Man spricht von „strukturtragenden" oder von „selbsterklärenden" Daten.

Ausgangspunkt XML

Die Datenmodellierungssprache XML [8] eignet sich für die oben genannten Fälle: Mit XML können beliebig komplexe Datensätze spezifiziert werden; XML lässt Ausnahmen zu (in XML können alternative Strukturen spezifiziert werden und die spezifizierte Struktur darf sogar missachtet werden); XML-Datensätze, im XML-Jargon Dokumente genannt, sind strukturtragend.

Zum Beispiel kann eine Adresskartei wie folgt in XML spezifiziert werden:

< Adresskartei >
   < Adresse >
        < Name > Bartl Bastscho < /Name >
        < Einrichtung > Universität München
            < /Einrichtung >
        < EMail > bartl@bastscho.net < /EMail >
    < /Adresse >
    < Adresse >
        < Name > Susi Schlau < /Name >
        < Einrichtung > Universität München
            < /Einrichtung >
        < Abteilung > Fakultät für Mathematik und
            Informatik < /Abteilung >
        < Kontakt >
            < EMail > susi@bastscho.net < /EMail >
            < Url > http://www.bastscho. net/freunde/susi
                 < /Url >
        < /Kontakt >
    < /Adresse >
< /Adresskartei >

Der zweite Datensatz hat eine reichere Struktur als der erste; in den beiden Datensätzen befindet sich die E-Mail-Adresse nicht auf derselben Tiefe.

In einer Anfrage an eine solche Adresskartei sollen nicht nur die Texte, Zahlen oder sonstige Daten ermittelt werden, die als Inhalte der innersten Elemente vorkommen, sondern auch die Elementnamen, wie „Name", „Einrichtung" oder „Kontakt". Schema- und Objektdaten sollen also in Anfragen nicht wie in traditionellen Anfragesprachen wie SQL unterschiedlich behandelt werden.

Wird in einer solchen Adresskartei nach einer E-Mail-Adresse für eine bestimmte Person gesucht, dann kann der Elementname „EMail" (oder irgendein Synonym dieses Elementnamens, welches eine sog. Ontologie liefern könnte) an beliebiger Tiefe gesucht werden. Eine Anfragesprache muss also über Sprachkonstrukte verfügen, die es ermöglichen, eine unbekannte Struktur oder eine unbestimmte Tiefe auszudrücken.

Datenmodelle für semistrukturierte Daten

Für semistrukturierte Daten wurden einige Modelle vorgeschlagen, die nur unwesentlich voneinander abweichen.

Im Object Exchange Model [5], kurz OEM, werden Datensätze Objekte genannt. Wie Objekte von Objektdatenbanken kann (muss aber nicht) ein OEM-Objekt eine sog. Objektidentität besitzen, so dass zwei OEM-Objekte, die denselben Wert haben, unterschiedlich sein können. Der Wert eines atomaren OEM-Objekts hat einen Typ wie etwa „integer", „string" oder „image". Ein zusammengesetztes OEM-Objekt besteht aus Attributen, die Werte besitzen, die wiederum OEM-Objekte sind. Die Attribute eines zusammengesetzten OEM-Objekts bilden entweder eine Menge oder eine Sequenz. OEM bietet eine weitreichende Typanpassung, um Unregelmäßigkeiten Rechnung zu tragen.

Ein OEM-Objekt kann als ein gerichteter Multigraph angesehen werden, dessen Knoten eindeutige Objektbezeichner sind und dessen Kanten die Attribute darstellen. Ein OEM-Objekt besitzt eine Wurzel, d.h. einen ausgezeichneten Knoten, von dem aus alle Knoten des OEM-Objektes erreichbar sind.

Der erste Adresskarteieintrag kann also wie folgt dargestellt werden, wobei „& n" Objektbezeichner sind:

Die Kanten stellen sowohl die Beziehung eines Elements zu einem Kindelement als auch etwaige Verweise wie (Hypertext- oder Nichthypertext-) Links dar. Ein OEM-Objekt entspricht nicht notwendigerweise einem Baum, d.h., OEM lässt zyklische Objekte zu. OEM-Objekte können HTML-Links oder einfache XML-Links darstellen, jedoch nicht die erweiterten XML-Links von XLink [8].

Das Datenmodell, das der Anfragesprache UnQL [5] zugrunde liegt, ist OEM ähnlich. Er ist aber „wertbasiert", d.h., dass es keine Objektidentität kennt. Mit diesem Datenmodell ist die Verwendung der „Bisimulation" für semistrukturierte Daten eingeführt worden [5], die sich für die Anfrageauswertung als wichtig erwiesen hat. Eine Simulation eines Multigraphen G1 in einen Multigraphen G2 ist eine binäre Relation S zwischen den Knoten von G1 und G2 , die die Kanten von G1 auf Kanten von G2 abbildet. Eine Simulation S von G1 in G2 ist eine Bisimulation, falls S –1 eine Simulation von G2 in G1 ist. Für UnQL sind zwei semistrukturierte Objekte identisch, wenn sie bisimilar sind.

Das Datenmodell YAT [5] bietet neben ähnlichen Merkmalen wie OEM und dem Datenmodell der Anfragesprache UnQL die „Modellinstanziierung". Damit können unter gewissen Umständen die Typen einer Datenmodellierung den Typen einer anderen Datenmodellierung angepasst werden. So können unterschiedliche Modellierungen von Anwendungen verglichen und Ergebnisse von Anfragen strukturiert werden.

Vergleich mit den relationalen und Objektmodellen

Eine Relation oder Tabelle kann als ein semistrukturiertes Objekt dargestellt werden, dessen Attribute die Tupel sind. Ein Tupel kann ebenfalls als ein semistrukturiertes Objekt dargestellt werden, dessen Attribute die Attributswerte des Tupels sind.

Diese Darstellung einer Relation ist ziemlich natürlich. Sie ist aber auch etwas trügerisch. Zum einen kann eine Relation auf viele andere Weisen als semistrukturiertes Objekt dargestellt werden. Zum anderen kann bei einer solchen Repräsentation ein Teil der Semantik verloren gehen, weil im Gegensatz zu einer relationalen Anfragesprache wie SQL die Anfragesprachen für semistrukturierte Daten alle Knoten gleich behandeln. So muss der Benutzer einer Anfragesprache für semistrukturierte Daten die Bedeutung der Verknüpfungen beachten.

Ein Datenmodell für semistrukturierte Daten kann als Vereinfachung eines Objektmodells angesehen werden, weil es in der Regel weder Klassen noch Vererbung anbietet. Der Verzicht auf Klassen und Vererbung ist jedoch fraglich. Die Modellinstanziierung von YAT [5] entspricht der Vererbung.

Schemaextraktion

Traditionell stützen sich Anfrageauswertung und -optimierung auf Schemata. Um Anfragen über semistrukturierten Daten auszuwerten, bietet es sich also an, zuerst aus den vorhandenen Daten ein Schema zu extrahieren.

Viele WWW-Informationsserver liefern HTML-Seiten, die dynamisch aus einer Datenbank erzeugt werden. Es sind Methoden entwickelt worden, um aus solchen Seiten ein Schema zu erkennen, das evtl. nicht identisch mit dem Datenbankschema ist. Man spricht von „web site wrapping" und von „Schemaextraktion". Das extrahierte Schema wird manchmal „data guide" genannt. Eine Schemaextraktion ist eine Art Klassifikation von vorhandenen Datensätzen nach ihren Strukturen. Die meisten Methoden sind halbautomatisch und interaktiv und stützen sich auf Heuristiken.

Von Nestorov et al. [6] wird ein auf Deduktion und Datalog beruhender Ansatz zur Schemaextraktion dargestellt, der zulässt, dass derselbe Datensatz mehreren Klassen zugeordnet wird und Approximationsschemata, denen nicht alle Datensätze entsprechen, liefert. Eine Metrik wird vorgeschlagen, womit die Qualität eines Approximationsschemas gemessen werden kann.

Anfragesprachen

Eine Anfragesprache ist wünschenswert zur Erstellung von dynamischen WWW-Seiten, die Inhalte teilen statt kopieren, um Sichten („views") zu erzeugen und um die Suche nach Inhalten zu erleichtern. Wünschenswerte Eigenschaften von Anfragesprachen für semistrukturierte Daten wurden von Maier [7] ausgearbeitet.

Viele Anfragesprachen für semistrukturierte Daten oder „für das WWW" sind entwickelt worden – u.a. Lorel [5] und XQuery [8]. Einige sind von SQL und OQL inspiriert, andere sind im Zusammenhang mit XML entstanden. Vergleiche bieten Bonifati [1, 2] und Fernandez et al. [3] an.

Die meisten Anfragesprachen verwenden Variablen, um Knoten – einige sowohl für Elementinhalte als auch für Elementnamen – zu bezeichnen. Reguläre Ausdrücke werden von vielen Anfragesprachen verwendet, um die Navigation im befragten Datensatz auszudrücken.

Mit dem Sternoperator kann z.B. ein Element an beliebiger Tiefe gefunden werden, mit dem Optionsoperator können Unregelmäßigkeiten der Datensatzstruktur berücksichtigt werden. Mit einer „Wildcard" kann eine Navigation entlang von unvollständig spezifizierten Pfaden definiert werden.

Zum Beispiel können im Stil von XML-QL wie folgt E-Mail-Adressen an beliebiger Tiefe (ausgedrückt durch die Wildcard $ gefolgt vom Sternoperator) gefunden werden, wobei $name und $email Variablen sind:

where < $* >
        < Nachname > $name < /Nachname >
        < EMail > $email < /EMail >
      < />
in „www.yellowpages.net/ adresses.xml"
construct < Antwort >
            < Person >
               < Name > $name < /Name >
               < Mail > $email < /Mail >
            < /Person >
          < /Antwort >

Die meisten Anfragesprachen ermöglichen, die Antwort beliebig zu strukturieren.

Einige Prototypen von Systemen zur „Verwaltung von Websites", d.h. zur Verwaltung von Inhalten, sind entwickelt worden, womit die ersten Anfragesprachen für semistrukturierte Daten entwickelt und getestet worden sind.

                   Artikelanfang  Seitenanfang

Literatur

1. Bonifati, A., Ceri, S.: Comparative Analysis of Five XML Query Languages. Proc. ACM SIGMOD, Int. Conf. on Management of Data (2000)
2. Bonifati, A., Lee, D.: Technical Survey of XML Schema and Query Languages. Proc. Int. Conf. on Very Large Databases (2001)
3. Fernandez, M., et al.: XML Query Languages: Experiences and Exemplars. http:// cm.bell-labs.com/cm/cs/who/wadler/topics/xml.html
4. Buneman, P., et al.: Programming Constructs for Unstructered Data. Proc. Int. Workshop on Database Programming Languages (DBPL) (1995)
5. Abiteboul, S., et al.: Data on the Web – From Relations to Semistructured Data and XML. Hove: Morgan Kaufmann 2000
6. Nestorov, S., et al.: Extracting Schema from Semistructured Data. Proc. ACM SIGMOD, Int. Conf. on Management of Data (1998)
7. Maier, D.: Database Desiderata for an XML Query Language. Query Languages Workshop (1998);
   www.w3.org/TandS/QL/QL98/pp/maier.html
8. XML und XML-bezogene Formalismen: http://www.w3.org

                   Artikelanfang  Seitenanfang

Autor & Copyright
François Bry, Michael Kraus, Dan Olteanu, Sebastian Schaffert
Institut für Informatik,
Universität München,
Oettingenstraße 67,
D-80538 München;
www.pms.informatik.uni-muenchen.de

© 2001 Informatik Spektrum, Springer-Verlag Berlin Heidelberg

                   Artikelanfang  Seitenanfang

• Kurzinfo
• Erläuterung
• Literatur
• Autor & Copyright

Kurzinfo Die erste internationale Konferenz zum Thema Softwarevisualierung fand diesen Sommer im kalifornischen San Diego statt (für Details zu ACM SOFTVIS 2003 siehe http://www.softvis.org). Grund genug einmal zu betrachten, worum es in diesem zunehmend an Bedeutung gewinnenden neuen alten Forschungsgebiet geht.

Erläuterung

Softwarevisualisierung entwickelt und untersucht Methoden und Einsatz von computergrafischen Darstellungen unterschiedlicher Aspekte von Software wie z.B.

• ihrer statischen Struktur,
• ihrer konkreten oder abstrakten Ausführung,
• ihrer Evolution.

Im Gegensatz zur visuellen Programmierung und Diagrammtechniken zum Softwareentwurf liegt dabei die Zielsetzung nicht in der Konstruktion, sondern in der Analyse von Programmen und deren Entstehungsprozess.

Die Softwarevisualisierung kombiniert Techniken aus den Gebieten Softwaretechnik, Programmiersprachen, Data Mining, Computergrafik, Informationsvisualisierung und Mensch-Maschine-Kommunikation.

Visualisierung heißt Daten bzw. Information sichtbar zu machen. Schon Aristoteles sagte 350 v. Chr., dass „Denken ohne Bilder unmöglich sei", Emanuel Kant meinte 1781:

„Der Verstand vermag nichts anzuschauen und die Sinne nichts zu denken. Nur daraus, dass sie sich vereinigen, kann Erkenntnis entspringen."

Und René Descartes stellte 1637 fest:

„Imagination oder Visualisierung und besonders die Benutzung von Diagrammen haben einen entscheidenden Anteil an der wissenschaftlichen Forschung."

In der heutigen Zeit bedient man sich gerne des Mediums Computer, um abstrakte Zusammenhänge bildlich darzustellen. Für Frederick Brooks gehört Visualisierung zu den Schlüsseltechnologien, die „Intelligence Amplification "ermöglichen. Der Computer soll dem Menschen also nicht das Denken abnehmen, sondern menschliche Intelligenzleistungen verstärken.

Visualisierungen werden im Maschinenbau, in der Chemie, Physik und Medizin verstärkt eingesetzt. Informatiker haben anspruchsvolle Systeme entwickelt, um für diese Disziplinen Visualisierungen zu erzeugen. Erstaunlicherweise machen Informatiker aber nur wenig Gebrauch von Visualisierungswerkzeugen, wenn es um Entwurf, Implementierung oder Wartung von Software geht.

Theoretiker schätzen häufig Visualisierung gering, dabei stammt das Wort „Theorie " vom griechischen Verb theorein ,also „schauen ".Die frühen Pythagoräer stützten ihre Theoreme nicht auf Beweise, sondern die Anschauung. Und die Praktiker, insbesondere die Programmierer, scheinen sich dem Darstellungsniveau des Computers anzupassen, anstatt dieses ihrer eigenen Wahrnehmung.

Dennoch ist die Begriffswelt der Informatik voller Metaphern. So reden wir beispielsweise von Maschinen, Automaten, Bändern, Knoten und Kanten, Archiven, Ordnern oder Fenstern. Eine Turingmaschine z.B. ist ein mathematisches Modell, das aus Mengen, Funktionen und Relationen besteht. Die Analogie zu Maschinen lässt uns Aspekte aus der physikalischen auf die mathematische Welt übertragen.

Das Ziel der Softwarevisualisierung besteht nicht darin, schöne, bunte Grafiken zu erzeugen, sondern solche, die mentale Bilder auslösen und so das Verstehen von Software erleichtern. (Allerdings sind die psychologischen Indizien für die Existenz und das Wesen mentaler Bilder zugegebenermaßen widersprüchlich.) Dazu müssen geeignete, visuelle Metaphern gefunden werden. Solche Metaphern verbessern nicht nur die Visualisierung, sondern auch die Art und Weise, wie wir über Softwaresysteme reden.

Beispiele

Im Folgenden wollen wir einen Einblick in die Forschungsgebiete der Softwarevisualisierung anhand von Beispielen zu jedem der am Anfang genannten Aspekte von Software geben.

Statische Struktur

Mit dem in Saarbrücken entwickelten aiCall (s. Abb.1) lassen sich Kontrollflussgraphen von Programmen samt den zugehörigen Analyseergebnissen grafisch darstellen und interaktiv durchmustern (Evstiougov-Babaev in [2]).So kann der Entwickler sehen, wie viel Stackzellen ein Programm an einem beistimmten Programmpunkt benötigt, um so Stack-Overflows frühzeitig zu erkennen und zu beseitigen. Visualisierungen auf höherer Ebene werden benutzt, um die Architektur von Softwaresystemen darzustellen. Geons (geometric icons)zeigen ähnlich einem UML-Diagramm Abhängigkeiten von Objekten [5].Diese werden als vereinfachte symbolhafte dreidimensionale Objekte dargestellt. Insbesondere bei der Aggregation werden die aggregierten Objekte zusätzlich verkleinert innerhalb des aggregierenden Objekts dargestellt. Ziel ist die bessere Strukturierung und die damit verbundene verbesserte Lesbarkeit des Diagramms, was Zeit sparen und Fehler vermeiden helfen soll.

Der Aufwand des wiederholten Dekodierens der Zeichenfolgen von Bezeichnungen entfällt also, die Objekte sind grafisch dargestellt und können so schneller erfasst und wiedererkannt werden. Diese Vorteile werden auch durch Studien belegt.

Konkrete und abstrakte Ausführung

Lange Zeit stand die Visualisierung und insbesondere Animation von Algorithmen im Mittelpunkt der Softwarevisualisierung. Mit klassischen Algo-rithmenanimationssystemen lassen sich beispielsweise Animationen von Suchgraphen, Listen, dem n-Damen-Problem, Binpacking oder Sortieralgorithmen erstellen. Es ist möglich, gleichzeitig mehrere Sichten auf den Zustand des Algorithmus zu benutzen, etwa ein Balkendiagramm und einen Baum zur Darstellung der zu sortierenden Daten bei HeapSort. Abbildung 2 zeigt einen Screenshot der Animation des HeapSort-Algorithmus, die mit einem aktuelleren System namens GANIMAL erstellt wurde [3].

Neuere Arbeiten beschäftigen sich auch mit der visuellen Ausführung von Algorithmen mit abstrakten Eingabedaten wie abstrakten Shapegraphen oder Baumfragmenten (Wihlem et al.in [2].

Evolution von Software

SeeSoft ist ein Programm zur Quellcodeverwaltung. Es stellt die einzelnen Zeilen einer Datei als Pixel in einer Box dar, die die dazugehörige Datei repräsentiert. Man kann hereinzoomen, sodass eine Quellcodezeile als eine Linie dargestellt wird bis hin zu der tatsächlichen Textzeile. Die dargestellten Textzeilen können unterschiedlich eingefärbt werden.

Man kann verschiedene Metriken mit dem Farbspektrum assoziieren, etwa den Zeitpunkt der letzten Änderung einer Programmzeile. So kann man direkt sehen, an welcher Stelle in einer Datei erst kürzlich gearbeitet wurde (rot)und welche schon lange unverändert geblieben sind (blau), s. Abb.3.

SeeSoft kann nicht nur eine Vielzahl von Dateien gleichzeitig darstellen, sondern mit Hilfe eines Schiebereglers kann der Betrachter zwischen Dateiversionen wechseln und sozusagen eine Zeitreise durch die Entwicklungsgeschichte des Systems machen. In Tarantula [6] wurde der Ansatz erweitert, um Textzeilen hervorzuheben, die vermutlich fehlerhaft sind. Hierzu werden dynamische Slices, d.h. Mengen von tatsächlich ausgeführten Programmpunkten, von erfolgreichen und fehlerhaften Testläufen analysiert.

Zunehmende Bedeutung der Softwarevisualisierung

Die zunehmende Bedeutung, die Softwarevisualisierung im Software-Engineering und insbesondere im Reengineering spielt, wird durch zwei aktuelle Studien belegt. Bassil und Keller [1] untersuchten in einer Umfrage, was sich Entwickler in der Industrie von Softwarevisualisierung versprechen oder wünschen. Als Vorteile wurden aufgezählt: Einsparung von Zeit und Geld, besseres Verständnis der Software, Erhöhung der Produktivität und Qualität, Management der Komplexität sowie verbesserte Fehlersuche. Vor allem wünschten sich die Befragten die Integration von SV-Werkzeugen in andere Werkzeuge (third party) und besseren Import und Export von Daten und Visualisierungen. Laut Koschkes Studie (in [2])glauben 40% der über 100 befragten Forscher auf den Gebieten Software Maintenance, Reverse Engineering und Reengineering, dass Softwarevisualisierung absolut notwendig ist, weitere 42% halten sie für wichtig, aber nicht kritisch.

Ausblick

Leider muss man feststellen, dass es nur wenige Forscher gibt, die konsequent den Einsatz von Softwarevisualisierung in verschiedenen Bereichen untersuchen. Erwähnenswerte Ausnahme ist hier insbesondere John Stasko vom Georgia Institute of Technology. Viele wenden vorhandene Visualisierungstechniken mal eben schnell an und sind dann häufig enttäuscht über die erzielten Ergebnisse.

Die Erzeugung der grafischen Ausgabe ist nur der letzte Schritt in der „Visualisierungspipeline": Datenerfassung, Analyse und Visualisierung. Im Bereich wissenschaftlicher Visualisierung (scientific visualization) werden alle drei Phasen heftigst erforscht. In der Softwarevisualisierung wurden Analysemethoden mit dem Ziel, die Visualisierung (semi-)automatisch auf das Wesentliche zu fokussieren, bisher wenig untersucht, obwohl im Bereich der Programmanalyse theoretisch fundierte und praktisch relevante Theorien exisitieren. Erste Ergebnisse, diese für die Visualisierung von Programmmen zu verwenden, entstanden erst in jüngster Zeit (Wilhelm et al.in [2]).

Eine Studie (Diehl in [2]) über die veröffentlichten Arbeiten zeigt, dass die Visualisierung der statischen Struktur und der konkreten Ausführung von Programmen vielfach untersucht wurde, während die Visualisierung der abstrakten Ausführung von Programmen oder der Evolution von Programmen und Systemen fast vollkommen unerforscht ist.

Zu den Herausforderungen der nächsten Jahre zählen der Aufbau von umfassenden Web-Datenbanken mit fertigen oder konfigurierbaren Algorithmenanimationen für die Lehre, die Entwicklung und Integration skalierbarer, visueller Werkzeuge für Softwaretechnik und insbesondere Reengineering, die Visualisierung der Evolution von Softwaresystemen sowie in allen Bereichen die Entwicklung neuer grafischer Metaphern und die empirische Evaluation existierender und neuer Verfahren.

Einen Überblick zum Thema „Softwarevisualisierung" und insbesondere zu Systemen zur Programm- und Algorithmenanimation geben drei Sammelbände aus den Jahren 1996,1998 und 2002 [2, 4, 7]. Aktuelle Informationen bieten zudem die Webpages http://www.softvis.org und http://www.softwarevisualisierung.de. Letztere enthält Links zu im Bereich Softwarevisualisierung aktiven Forschungsgruppen in Deutschland.

                   Artikelanfang  Seitenanfang

Literatur

1. Bassil, S., Keller, R. K.: Software visualization tools: survey and analysis. In: Proceedings of the Ninth International Workshop on Program Comprehension (IWPC2001), Toronto, Ontario, Canada, 2001
2. Diehl, S. (ed.): Software visualization. LNCS, vol. 2269. Berlin Heidelberg New York: Springer 2002
3. Diehl, S., Kerren, A.: Generierung interaktiver Visualisierungen von Berechnungsmodellen. Informatik-Forschung und Entwicklung, 2001
4. Eades, P., Zhang, K. (eds.): Software visualization. Singapore: World Scientific Pub. 1996
5. Irani, P. P., Ware, C., Tingley, M.: Using perceptual syntax to enhance semantic content in diagrams. IEEE Computer Graphics & Applications 21(5), 2001
6. Jones, J. A., Harrold, M. J., Stasko, J.: Visualization of test information to assist fault localization. In: Proceedings of the 24th International Conference on Software Engineering ICSE02, Buenos Aires, 2002
7. Stasko, J. T., Domingue, J., Brown, M. H., Price, B. A.: Software visualization. Cambridge/ MA: MIT Press 1998

Hinweis: Die URLs entsprechen dem Stand bei der Veröffentlichung des Artikels und werden nicht aktualisiert.

                   Artikelanfang  Seitenanfang

Autor & Copyright
Dr. S. Diehl
FR 6.2 Informatik,
Universität des Saarlandes,
Postfach 151150,
66041 Saarbrücken
diehl@cs.uni-sb.de

DOI 10.1007/s00287-003-0314-4
© 2003 Informatik Spektrum, Springer-Verlag Berlin Heidelberg

                   Artikelanfang  Seitenanfang

SQL2-Norm und SQL3-Projekt

• Erläuterung
• Literatur
• Autor & Copyright
   

Erläuterung

Im Markt für Datenbanken haben sich mittlerweile die relationalen Systeme etabliert und gewinnen zunehmend an Bedeutung. Zur Datenabfrage und -manipulation dient in den meisten relationalen Datenbanken die Structured Query Language (SQL), die in der ISO-Norm 9075 (International Organization for Standardization) spezifiziert ist.

Den bisherigen Fassungen der SQL-Norm, erschienen 1987 [1] und 1989 [2], fehlten wichtige Features zur Unterstützung relationaler Systeme, wie sie von Codd, dem Erfinder des Relationsmodells, definiert wurden. Proprietäre Lösungen der Datenbankhersteller füllten diese Lücken, was die Portabilität darauf beruhender Datenbankanwendungen erheblich erschwert.

Im letzten Jahr wurde eine wesentlich erweiterte Fassung dieser Norm von ISO veröffentlicht - ISO 9075: 1992 [3] (einen detaillierten Überblick gibt [8]). An den Entwicklungsarbeiten beteiligten sich u.a. Vertreter aus Deutschland, Frankreich, Großbritannien und den USA. In dieser Revision, bekannt unter der Bezeichnung „SQL2", wurden viele Kritikpunkte berücksichtigt (u.a. von Codd [4] und Date [5, 6, 7]). Wesentliche Fortschritte wurden erzielt durch:

• umfangreiche Erweiterung der relationalen Ausdrucksmöglichkeiten, u.a. durch Generalisierung und Orthogonalisierung existierender Operationen;
• neue Datentypen und -operationen, Domänenkonzept
• Internationalisierung und benutzerdefinerte Zeichensätze
• dynamisches SQL
• die Möglichkeit, Tabellenstrukturen im laufenden Betrieb zu ändern
• umfangreiche Diagnosemöglichkeiten
• Möglichkeit des Zugriffs auf entfernte Datenbanken.

Durch die Mächtigkeit von SQL2 sind Anwender relationaler Datenbanken in Zukunft wesentlich unabhängiger von proprietären Datenbankschnittstellen und damit von einer bestimmten Basissoftware. Der Portabilitätsgewinn bringt außerdem Vorteile für Produkte, die Datenbanksysteme als intelligenten Datenserver verwenden.

Die Arbeiten der SQL Access Group (veröffentlicht von X/Open [9, 10]), einer Vereinigung führender amerikanischer Hersteller, zeigen, daß über SQL und den für 1993 erwarteten RDA-Standard (Remote Database Access) Datenbankprodukte verschiedener Hersteller gekoppelt werden können: Front-End-Anwendungen eines Herstellers können unabhängig von den jeweiligen Hardware Plattformen auf Back-End-Produkte anderer Hersteller zugreifen. Die Spezifikationen dieser Gruppe, auf denen u.a. auch die ODBC-Spezifikationen (Open Database Connectivity) von Microsoft basieren, wurden inzwischen bei ISO als Erweiterung von SQL vorgeschlagen.

Bereits seit längerer Zeit wird bei ISO - parallel zu SQL2 - am Projekt „SQL3" gearbeitet. SQL3 soll weitgehend aufwärtskompatibel zu SQL2 sein. Zur Zeit werden u.a. folgende Erweiterungen gegenüber SQL2 diskutiert:

• Unterstützung komplexer Datenstrukturen, z.B. Stücklisten
• Sprachmittel für Datenbankprozeduren („Stored Procedures")
• ereignisgesteuerte Datenmanipulation („Trigger")
• objektorientierte Konzepte, z.B. abstrakte Datentypen
• Unterstützung verteilter Datenbanken.

Aus heutiger Sicht wird der gesamte im SQL3-Projekt diskutierte Sprachumfang erst in einigen Jahren als Norm verabschiedet sein. Daher sind bei ISO Bestrebungen im Gange, kleinere „Nachtragspakete zu SQL2" (SQL2-Addenda) zu schnüren, die relativ schnell verabschiedet werden können - z.B. die o.a. Spezifikation der SQL Access Group sowie die Sprachmittel für Definition und Aufruf von Datenbankprozeduren.

                   Artikelanfang  Seitenanfang

Literatur

1. ISO 9075: 1987, Database Language SQL, 1987
2. ISO 9075: 1989, Database Language SQL with Integrity Enhancement, 1989
3. ISO 9075: 1992, Database Language SQL, 1992
4. Codd E.F.: Fatal Flaws in SQL. Datamation. Part 1 and 2, August/September 1988
5. Date C.J.: A Critique of the SQL Database Language. ACM SIGMOD Rec. 14, Number 3 (1984)
6. Date C.J.: Some Principles of Good Language Design. ACM Sigmod Rec. 14, Number 3 (1984)
7. Date C.J.: Where SQL Falls Short. Datamation, May 1987
8. Shaw, P.: Database Language Standards: Past, Present and Future, in: A. Blaser (ed.): Database Systems of the 90s, Lecture Notes in Computer Science Vol.466, S.55-80. Berlin: Springer 1990
9. X/Open C201, Structured Query Language (SQL), X/Open CAE Specification, August 1992
10. X/Open S203, SQL Call Level Inferface (CLI). X/Open Snapshot, September 199

                   Artikelanfang  Seitenanfang

Autor & Copyright
Reinhold Weber
Siemens Nixdorf Informationssysteme AG,
Datenbanksysteme
Otto-Hahn-Ring 6,
W-8000 München 83

© 1993 Informatik Spektrum, Springer-Verlag Berlin Heidelberg

                   Artikelanfang  Seitenanfang

Sozionik

• Erläuterung
• Literatur
• Autor & Copyright
   

Erläuterung

Sozionik ist ein interdisziplinäres Forschungsfeld zwischen Soziologie und Künstlicher Intelligenz (KI). Dabei geht es um die Frage, ob und wie es möglich ist, kommunikations- und kooperationsfähige Computerprogramme zu entwickeln, die sich am Vorbild der menschlichen Gesellschaft orientieren. Ähnlich wie man sich in der Bionik biologische Körperfunktionen zum Vorbild für technische Konstruktionen nimmt, stellt man sich in der Sozionik die Aufgabe, soziale Abläufe und Strukturen als Anregung für die Gestaltung verteilter Computersysteme zu nutzen. Das paßt zum „Zeitgeist", denn wir können seit einigen Jahren einen tiefgreifenden Wandel im technologischen Leitbild von Entwicklern und Anwendern beobachten: Es ist nicht mehr das elektronische „Gehirn" des einsamen Superrechners, sondern es ist die Vision einer elektronischen „Gesellschaft" weltweit vernetzter Rechnersysteme,die einer neuen Generation von Computertechnologien ihren Stempel aufprägen wird.

Auch wenn die Bezeichnung „Sozionik" neu ist [4, 5], lassen sich ihre Ursprünge bis in die 70er Jahre zurückverfolgen. Damals formulierte Carl Hewitt am MIT in seinem berühmten Aufsatz über „message passing" [2] das sogenannte Unentscheidbarkeitsproblem der verteilten KI: Was geschieht, wenn zwei in sich geschlossene „Mikrotheorien" mit Bezug auf ein und dieselbe Aufgabe zu widersprüchlichen Lösungen kommen,die beide gleichermaßen logisch sind? Dieser Widerspruch ist logisch unentscheidbar und läßt sich wie im Zusammenleben realer Menschen nicht durch Kalkül, sondern nur durch Verhandlung auflösen. Dafür werden soziale Fähigkeiten benötigt. Um eine gemeinsam getragenen Entscheidung zu erreichen,muß man miteinander reden,abwägen,verhandeln und Kompromisse schließen. Das erklärt auch, warum „Verhandlung" [1] die erste Sozialmetapher war, die in den Arbeiten der verteilten KI eine wichtige Rolle spielen konnte. Seitdem haben weitere soziologische Konzepte wie Rollenerwartung, pluralistische Gemeinschaft, Kommunikation, Macht und Vertrauen in die Forschungsarbeiten der verteilten KI Eingang gefunden. Heute spricht man sogar von „Artificial Social Systems" oder „Artificial Societies" und meint damit Computerprogramme,die sich die Robustheit, Anpassungsfähigkeit und Kreativität wirklicher sozialer Systeme zu eigen machen.

Als noch junges interdisziplinäres Unternehmen von Informatikern und Soziologen steht die Sozionik vor drei Aufgaben, wobei sie sich an drei entsprechenden „Referenzkriterien" bewähren muß:

(1) „Anwendungsreferenz"

Die erste Aufgabe besteht darin, praktische Anwendungssysteme wie „soziale Agenten", „intelligente Assistenten" oder „Multiagentensysteme" (MAS) auf den Markt zu bringen. Mit dem Siegeszug des Internet wird es zu einem Nachfrageschub für sozionische Produkte kommen. Zu denken ist beispielsweise an einen elektronischen „Agenten", der sich im Auftrag seiner Firma im Internet auf die Suche nach potentiellen Kooperationspartnern für ein bestimmtes Projekt macht und durch „Vorgespräche" mit Agentensystemen anderer Firmen eine Vorauswahl trifft. Die endgültige Entscheidung wird dann allerdings den menschlichen Unternehmern vorbehalten bleiben. Der praktische Erfolg solcher Anwendungsprogramme hängt in hohem Maße von der gelungenen „soziotechnischen" Systemgestaltung ab, und deshalb ist es unabdingbar, daß hier beide Disziplinen eng zusammenarbeiten.

(2) „Soziologiereferenz"

Die zweite Aufgabe heißt „social simulation". Sie verfolgt das Ziel, künstliche Sozialsysteme und soziologische Simulationsprogramme zu entwickeln, um gesellschaftliche Phänomene wie das Problem der sozialen Strukturbildung oder die Dynamik des sozialen Wandels besser verstehen zu lernen. Diese Simulatoren müssen aber so gebaut sein, daß sie soziologisch angemessen, also weder naiv noch überabstrakt sind, und das geht nur, wenn die entsprechenden Forschungs- und Entwicklungsarbeiten auf „Augenhöhe" mit der soziologischen Theoriediskussion vorangetrieben werden. Hier kommt der Informatik die Aufgabe zu, die entsprechenden technologischen Ressourcen bereitzustellen.

(3) „Informatikreferenz"

Die dritte Aufgabe ist, soziale Phänomene und soziologische Konzepte technologisch zu exploitieren und sie in neuartige informatische Konzepte und Modelle umzusetzen. Es geht dann nicht um die soziologische Angemessenheit sozionischer Produkte, sondern ausschließlich um ihre computerwissenschaftliche Angemessenheit. Rechenzeit und Tempogewinn, Speicherbedarf und -optimierung, algorithmische Effizienz und Eleganz sowie Wartbarkeit von Sprachen und Programmen sind die hier gültigen Kriterien, an denen sich die innovativen Leistungen der Sozionik messen lassen müssen. Die Soziologie kann sich hier als Ideengeber für die Informatik betätigen,um neue Mechanismen der Komplexitätsbewältigung, der Robustheit, der Adaptionsdynamik oder der Selbstorganisation zu entwerfen. Das soziologische „Übergangsproblem" („micro-macro-link") von Mikrogemeinschaften persönlich bekannter Gruppenangehöriger zu anonymen und hochkomplexen Makrogesellschaften dürfte hier ein ganz besonders interessantes Lösungspotential bieten, um das informatische Problem der Konstruktion von „largescale open sytems" [3] zu bewältigen.

                   Artikelanfang  Seitenanfang

Literatur

1. Davis, R.; Smith, R.G. (1983): Negotiation as a Metaphor for distributed problem solving, in: Artificial Intelligence 20 (1/83), S. 63-109.
2. Hewitt, C. (1977): Viewing Control Structures As Patterns of Passing Messages. Artificial Intelligence 8(3), 323-364
3. Hewitt, C. (1991): Open Information Systems Semantics for Distributed Artificial Intelligence, in: Artificial Intelligence 47 (1991), 79-106
4. Malsch, Th.; Florian, M.; Jonas, M.; Schulz-Schaeffer, I. (1996): Sozionik: Expeditionen ins Grenzgebiet zwischen Soziologie und Künstlicher Intelligenz, in: KI 2/1996, 6-1
5. Malsch, TH (1997), Die Provokation der „Artificial Societies", Ein programmatischer Versuch über die Frage, warum die Soziologie sich mit den Sozialmetaphern der Verteilten Künstlichen Intelligenz beschäftigen sollte, Zeitschrift für Soziologie 1/1997

                   Artikelanfang  Seitenanfang

Autor & Copyright
Thomas Malsch
Technische Universität Hamburg Harburg,
Arbeitsbereich Technikbewertung und Technikgestaltung,
Schloßmühlendamm 32,
D-21073 Hamburg

© 1997 Informatik Spektrum, Springer-Verlag Berlin Heidelberg

                   Artikelanfang  Seitenanfang