... Musik...

Herzlich willkommen zur Vorlesung Konzeptionelle Modellierung.

Wir hatten noch einen klitzekleinen Rückstand aus dem Kapitel XML,

hier waren nur noch ein paar Folien übrig,

paar Bemerkungen zu der Bedeutung von XML.

Mit XML haben wir jetzt eine Syntax, die es uns ermöglicht,

beliebige Textdokumente, semi-strukturierte Textdokumente mit Metadaten zu annotieren.

Und um Metadaten geht es ja bei uns in der Vorlesung.

Unser ganzer Modellierungsprozess ist letztlich darauf ausgerichtet, Metadaten zu erzeugen,

die wir zum Beispiel in einem Datenbanksystem benutzen können und Datenbankanfragen zu stellen.

Und jetzt haben wir hier semi-strukturierte Dokumente, wo wir die zugehörigen Metadaten direkt im Dokument drin stehen haben.

Wir haben außerdem die Möglichkeit, XML-Dokumente zusammenzusetzen aus externen Entities.

Ohne diese Entities selber noch mal wiederholen zu müssen, replizieren zu müssen im Dokument selber.

Dadurch haben wir dann die Möglichkeit, Dokumente zu reduzieren, insgesamt das Datenvolumen zu reduzieren

und wir haben auch Mittel und Wege, Redundanz zu vermeiden. Redundante Informationen zu vermeiden.

Ist noch zu viel gemurmel. Okay.

Dann haben wir auch gegenüber dem, was wir bisher gekannt haben, in relationalen Datenbanken,

hatten wir Möglichkeiten, Objekte, sage ich jetzt mal, zu referenzieren, mithilfe von Fremdschlüsseln.

Da konnten wir auf eine Zeile in einer Tabelle verweisen. Hier haben wir viel mächtigere Verweismechanismen.

Wir haben die Möglichkeit, symmetrische Links zu erzeugen, sodass also zwei XML-Artefakte sich wechselseitig referenzieren können.

Wir haben einen Fremdschlüssel, der geht immer nur in eine Richtung.

Wir haben die Möglichkeit, mehr Wege Links zu spezifizieren, Verweise, die auf mehrere Ziele zeigen.

Und wir haben die Möglichkeit, expandierende Links zu definieren, das heißt, auf externe Entities zu verweisen,

die sozusagen in das Dokument zu integrieren sind.

Also eine ganze Menge von Möglichkeiten haben wir da. So liegt es irgendwie nahe, zu sagen, wunderbar,

warum legen wir denn nicht gleich alle unsere Daten in diesem Format direkt in der Datenbank ab?

Jetzt gucken wir uns mal hier so ein Beispiel an, wie das denn aussehen könnte.

Beispiel angelehnt an das, was wir schon früher diskutiert haben, wir wollen Informationen zu Mitarbeitern hinterlegen.

Hier in diesem Fall haben wir einen Mitarbeiter, der hat eine Personalnummer, der hat einen Namen,

der Name besteht aus einem Vornamen oder einem Nachnamen. Und was ist das für ein Mitarbeiter?

Das ist ein Verkäufer und dieser Verkäufer, der hat eine Menge von Aufträgen, die sind hier auch direkt in diesem Dokument mit abgebildet.

So, wenn wir uns das jetzt genau anschauen, wie wir jetzt hier die Informationen abgebildet haben, hat das zunächst mal schon einen Vorteil.

Die Metadaten stehen hier direkt im Dokument mit drin, das heißt, wir können es lesen.

Wenn wir eine Tabelle sehen und nicht wissen, was die Spalten bedeuten, dann ist das sehr schwer zu lesen.

Hier können wir es lesen. Aber, warum nicht gleich die Daten so ablegen, aber hier treten jetzt auch die gleichen Phänomene auf,

wie die, die wir bei Relationalen Datenbanken hatten. Wenn wir da nicht drauf geachtet haben, sorgfältig darauf geachtet haben,

Redundanz zu vermeiden. Das haben wir gemacht, indem wir Tabellen normalisiert haben. Wir haben funktionale Abhängigkeiten analysiert usw.

Im Prinzip können hier genau die gleichen Anomalien auftreten. Wenn wir hier innerhalb eines Dokuments Informationen zu unterschiedlichen Entitytypen ablegen,

dann treten die gleichen Anomalien auf, wie in Relationalen Datenbanken. Hier haben wir Informationen zum Mitarbeiter und integriert haben wir hier die Aufträge des Mitarbeiters.

Das heißt, wenn der Mitarbeiter entlassen wird, wenn das Dokument zu diesem Mitarbeiter gelöscht wird, dann verschwindet auch die Information zu seinen Aufträgen.

Löschanomalie. Was können wir tun? Wir müssen im Prinzip genau das gleiche tun, was wir bisher getan haben. Wir müssen sorgfältig modellieren und entsprechend

Informationen, die eigentlich zu verschiedenen Entitytypen gehören, sorgfältig voneinander trennen. Das kann man auch machen in XML. Was ich damit sagen will, ist,

die Möglichkeit, redundanzfrei zu modellieren, heißt noch lange nicht, dass es auch passiert. Man hat zwar die Möglichkeit, externe Entities zu referenzieren,

aber es gibt nicht so wie im Relationenmodell jetzt auch einen systematischen Weg, wie komme ich zu redundanzfreien XML-Dokumenten.

Man könnte natürlich sagen, wir machen das gleiche, was wir bisher gemacht haben, wir modellieren im ER-Diagramm und untersuchen da funktionale Abhängigkeiten.

Aber im Prinzip sind wir hier in einer ähnlichen Situation, wie das, was wir bisher gemacht haben. Wir müssen explizit darauf achten, redundanz zu eliminieren.

Da steht es noch einmal und das als kleiner Nachtrag jetzt noch zu XML. Letzte Woche hat dann der Herr Lauterwald dankenswerterweise mich vertreten und hat Ihnen was zu multidimensionalen Datenbanken erzählt,

zum multidimensionalen Datenmodell. Das wiederholen wir hier auch nur ganz kurz nochmal. Worum ging es da? Im Prinzip ging es darum, Daten, wie modelliere ich Daten für bestimmte Zwecke?

Bisher haben wir gar nicht darüber nachgedacht, welchen Zweck eigentlich unsere Daten erfüllen sollten. Wir wollten ein Datenmodell haben, das Relationale Datenmodell, das für beliebige Anwendungen gleichermaßen gut geeignet ist.

Typischerweise unterscheidet man zwei Klassen von Anwendungen, nämlich sogenannte OLTP-Anwendungen, Online Transaction Processing Anwendungen und sogenannte OLAP-Anwendungen, Online Analytical Processing.