Visualisierung objektrelationaler Datenbanken

Präsentation zum Thema: "Visualisierung objektrelationaler Datenbanken"—  Präsentation transkript:

1 Visualisierung objektrelationaler Datenbanken
Seminar: Visualisierung von Softwareprozessen Ich halte ein Vortrag über die Visualisierung objektrelationaler Datenbanken.

2 Inhalt Das objektrelationale Datenmodell Visualisierung von ORDBMS
Die statische Sicht Die dynamische Sicht Die Informationssicht Das Zusammenspiel der Sichten Dazu werde ich zuerst darauf eingehen was objektrelationale DB sind und danach eine Möglichkeit vorstellen sie zu visualisieren

3 Konzepte von ORDBMS Mischung aus relationalen und objektorientierten DBMS Neue einfache Datentypen(BLOB, CLOB, BFILE, REF) Komplexe selbstdefinierte Datentypen möglich Definition von Objekttypen mit Attributen und Methoden Speicherung in Tabellen Sie sind eine Mischung aus relationalen und objektorientierten DBMS In relationalen Systemen werden die Daten in Tabellen gespeichert. Die Beziehungen zwischen den Tabellen heissen Relationen. Sie sind für einfach strukturierte Daten mit einfachen, standardisierten Zugriffsoperationen und mengenorientierten Zugriffen bestens geeignet. Können mit selbst definierten Datenstrukturen nur schwer umgehen. Objektorientierte DBMS speichern die Daten in Objekten. Enstanden aus der Philosophie, für eine objektorientierte Programmiersprache die permanente bzw. persistente Speicherung von Objekten zu ermöglichen. Da diese Systeme sehr nahe an den Programmiersprachen liegen müssen Anfragen und Updates prozedural formuliert werden. Dadurch sind sie sehr anfällig gegenüber Änderungen in der Objektstruktur. Nach der Entwicklung der OODBMS musste man im Umfeld der relationalen Datenbanksysteme konkurrenzfähig bleiben. Das SQL3-Standardisierungsgremium hat sich zusammengesetzt und versucht SQL um OO-Funktionalität zu erweitern. Nach und nach haben dann auch die Hersteller von DBMS, wie ORACLE, ihre Systeme um OO-Funktionalität erweitert. Dabei rausgekommen sind die objektrelationalen DBMS. Sie beinhalten die Vorteile von relationalen DBMS und können zusätzlich mit komplexen Daten und selbst definierten Datenstrukturen umgehen. Diese Strukturen werden wie auch bei den relationalen DBMS in Tabellen gespeichert die auch Beziehungen unter einander haben können. Man kam zu dem Schluss, dass eine größere Unabhängigkeit von den Programmiersprachen vorteilhafter ist. Somit können deskriptive Anfragen mit komplexen Datenstrukturen gestellt werden. Für den leichteren Umgang werden einige vorgefertigte Konstrukte bereitgestellt. Einerseits neue einfache Datentypen wie BLOB, CLOB, BFILE, REF. In einem BLOB kann man binäre Objekte bis zu einer Größe von 4GB in eine Datenbank ablegen. Ein CLOB speichert single-byte character Daten. BFILE ist ein Filepointer. REF benutzt man anstelle von Fremdschlüsseln und kann damit Beziehungen realisieren. Andereseits gibt es Konstrukte zum Definieren von komplexen Datentypen. Dazu gibt es Varying Arrays. Sie entsprechen den bekannten ARRAYS. Dann gibt es noch Records und nested Tables.

4 Objekttypen in ORDBMS Definition von Attributen und Methoden in der Typspezifikation Implementierung der Methoden im Type Body Eigenschaften: Identität, Vererbung, Polymorphismus Benutzung ähnlich wie in OO-Programmiersprachen Eine der wichtigsten Neuheiten ist aber die Möglichkeit Objekttypen zu definieren.Sie ähneln dem Klassenkonzept der objektorientierten Programmiersprachen. In der Typspezifikation werden die Attribute und Methodenrümpfe festgelegt und im Type Body werden die Methoden mit Funktionalität gefüllt. In den Methoden können Methoden anderer Objekte aufgerufen und auch Instanzen der Objekttypen erzeugt werden. Diese können dann in sogenannten Objekttabellen abgelegt werden, in denen jede Zeile einer Instanz entsprechen.

5 Inhalt Das objektrelationale Datenmodell Visualisierung von ORDBMS
Die statische Sicht Die dynamische Sicht Die Informationssicht Das Zusammenspiel der Sichten Als nächstes möchte ich eine Möglichkeit vorstellen Objektrelationale Datenbanksysteme zu visualisieren. Dazu muss erstmal die Notwendingkeit solch einer Methode geklärt werden. Man kann sich in einer Universität ein DBS vorstellen welches Lehrveranstaltungen speichert und ihnen Studenten und Dozenten zuweist. Im Laufe der Jahre wurde diese Datenbank erweitert. Neue Tabellen wurden hinzugefügt und Beziehungen zwischen den Tabellen geändert. Da einige Entwickler der Datenbank nicht mehr zur Verfügung stehen, ist eine Migration der Datenbank auf ein neues System nur noch schwer durchführbar. Kaum jemand ist noch in der Lage solch eine gewachsene Datenbank zu überblicken bzw. zu verstehen. Ein Weg zur Lösung des Problems ist es, diese Datenbank mit allen Beziehungen graphisch darzustellen. Damit erhält man einen Überblick über alle Beziehungen der Tabellen untereinander. Inkonsistente Zustände können aufgedeckt werden. Die Darstellung ermöglicht es, die Datenbank zu optimieren und zu verbessern. Weitere Anwendungsgebiete sind der Entwurf einer Datenbank sowie die Präsentation und Darstellung für die Entwickler oder Kunden eines Datenbanksystems. Relationale Datenbanken kann man ausreichend mit einem ER-Diagramm visualisieren. Bei der Visualisierung von Objektrelationalen Systemen wird auf dieses Konzept zurückgegriffen, um die statischen Elemente darzustellen. Der größte Unterschied zu den relationalen Datenbanken besteht darin, dass in objektrelationale Datenbanken Objekttypen definiert werden können, welche unter anderem Methoden beinhalten. Es gibt einfache Methoden die nur Berechnungen durchführen und es gibt komplexere Methoden die andere Objekte benutzen oder auch erzeugen können. Dadurch bekommt die Datenbank eine gewisse Eigendynamik. Um diese Vorgänge darstellen zu können benötigt man eine weitere Sicht, die ich hier die dynamische Sicht genannt habe. Wie Sie später sehen werden, wird auch noch eine dritte Sicht notwendig in der Rechte vergeben werden. Im Folgenden möchte ich nun die einzelnen Sichten vorstellen.

6 Die statische Sicht Beschreibt zur Laufzeit nicht änderbare Eigenschaften Statisch Elemente und ihre Beziehungen Entities und Relationships werden im ER-Diagramm dargestellt Abbildung der Objekttypen und ihrer Beziehungen im UML-Klassendiagramm Die statische Sicht beschreibt die festen, zur Laufzeit nicht änderbaren, Eigenschaften des Systems. In ihr werden die einzelnen statischen Elemente des Systems und ihre Beziehungen untereinander dargestellt. Es gibt drei Arten von statischen Elementen in einer objektrelationalen Datenbank die Relationships die Entities die Objekttypen Die Relationships und Entities sind bereits aus den relationalen Datenbanken bekannt. Sie werden mit Hilfe eines ER-Diagramms visualisiert. Auf die Erstellung dieser Diagramme möchte ich hier nicht weiter eingehen. Gleich sage ich noch etwas zu den Besonderheiten bei objektrelationalen DBS. Die dritte Art von elementen sind die Objekttypen. Sie ähneln den Klassen aus der objektorientierten Programmierung. Daher ist es möglich das Konzept zur Darstellung der Klassen, das UML-Klassendiagramm zu übernehmen. Damit können dann die Attribute und Methoden der einzelnen Objekttypen und ihre Beziehungen untereinander dargestellt werden. Auch darauf möchte ich nicht weiter eingehen, da dieses Konzept bereits vorgestellt wurde.

7 ER-Diagramm - Beispiel
Hier ist ein Beispiel für ein ER-Diagramm. Dieses Diagramm stellt das Universitätsbeispiel dar. Im Unterschied zum relationalen Modell können die Attribute komplexe Datentypen oder auch Objekttypen sein. Das Attribut Anschrift bei Student ist zum Beispiel ein benutzerdefinierter Objekttype. Als Attribute hat er den Namen, die Straße und Hausnummer, die PLZ und den Ort. Eine weitere Neuheit sind sogenannte Objekttabellen. Die Tabelle Lehrveranstaltung ist so eine Objekttabelle. Die Tabelle stellt den Objekttyp dar. Die Spalten sind die Attribute wobei es noch eine Spalte für den internen Objektidentifier gibt. Die Zeilen stellen die einzelnen Instanzen des Typs dar.

8 Inhalt Das objektrelationale Datenmodell Visualisierung von ORDBMS
Die statische Sicht Die dynamische Sicht Die Informationssicht Das Zusammenspiel der Sichten Als nächstes möchte ich die dynamische Sicht vorstellen.

9 Die dynamische Sicht Blick auf die Dynamik der Datenbank
Gibt an welche Objekte, wie oft miteinander interagieren Darstellbar durch: Lifecyclediagramme Operationsmodelle Sequenzdiagramme u.v.m Die Kontrolle über die Objekterzeugung und die Methodenaufrufe liegt nicht mehr beim Benutzer, sondern bei den Objekten. Man kann daher nur noch schwer nachvollziehen welche Vorgänge in der Datenbank geschehen. Wenn man ein Abbild der Datenbank macht, stellt man sie die Frage wie es zu so einer Objektverteilung kommen kann. Dabei blickt man auf die Methoden der Objekttypen. Man untersucht inwiefern sie Methoden anderer Objekte aufrufen bzw. inwiefern sie andere Objekte erzeugen. Dabei können verschiedene Scenarios durchgespielt werden und jedes führt zu einer anderen Objektverteilung. Man blickt also auf die Dynamik der Datenbank. Um dies darstellen zu können müssen neue Methoden gefunden werden. Man benötigt eine Methode die es erlaubt, nicht nur anzuzeigen welche Objekttypen potentiell mit welchen interagieren können, sondern welche es auch tun und wie oft sie es tun. Da die Programmierung der Objekttypen sehr der objektorientierten Programmierung ähnelt, kann man sich wieder der UML bedienen. Es ist möglich Lifecycle-Diagramme zu erstellen, Operationsmodelle zu entwickeln, und Sequenzdiagramme zu benutzen. Diese Techniken wurden bereits vorgestellt und ich möchte nicht weiter darauf eingehen.

10 Sequenzdiagramm - Beispiel
Hier ist ein Beispiel für ein Sequenzdiagramm aus dem Universitätsbeispiel. Die Mitarbeiter eines Studiengebiets beschließen, dass sie eine neue Lehrveranstaltung anbieten möchten. Da nur der Dekan neue Lehrveranstaltungen anbieten kann, wird er damit beauftragt. In diesem Szenario wird dann auch gleich ein neuer Dozent eingestellt der diese Lehrveranstaltung hält, und es wird eine neue Adresse für den Dozenten erzeugt. Kennt man alle Szenarien und hat die zugehörigen Diagramme, dann ist es nicht mehr schwer nachzuvollziehen, was in der Datenbank abgelaufen ist, um zu einer bestimmten Objektverteilung zu kommen.

11 Inhalt Das objektrelationale Datenmodell Visualisierung von ORDBMS
Die statische Sicht Die dynamische Sicht Die Informationssicht Das Zusammenspiel der Sichten Ich stelle jetzt die dritte Sicht vor und erkläre ihre Notwendigkeit.

12 Die Informationssicht
Nutzer hat keine direkte Kontrolle über die Datenbank  Festlegungen was passieren darf Festlegungen über Objekterzeugung, Methodenaufrufe und Änderungen an Objekten z.B. als Constraints in DB gespeichert Ich möchte jetzt an einem Beispiel die Notwendigkeit einer zusätzlichen Sicht der Informationssicht erläutern. Wie ich bereits gesagt habe, liegt die Kontrolle über die Objekterzeugung und somit auch deren Häufigkeit in der Datenbank bei den Objekten. Der Nutzer kann nur noch schwer in das Geschehen eingreifen. Der Nutzer macht von der Datenbank ein Abbild und kommt auf diese Objektverteilung. Man stellt fest, dass viel zu viele Lehrveranstaltungen und Dozenten existieren, gegenüber der Anzahl an Studenten. Die Uni hat so zwar eine hohe Kapazität aber wünschenswert ist so eine Objektverteilung natürlich nicht, das würde viel zuviel Geld kosten. Mit Hilfe des dynamischen Modells ist der Nutzer in der Lage herauszufinden, welche Szenarien sich abgespielt haben könnten. Das genügt aber nicht. Der Nutzer, zum Beispiel die Universitätsverwaltung, will verhindern, dass so ein Überschuss an Lehrveranstaltungen und Dozenten existiert. Wie ist es aber möglich die Objekterzeugung einzuschränken? Dazu wird eine dritte Sicht auf die Datenbank eingeführt, die Informationssicht. Hier kann festgelegt werden, welche Objekte andere Objekte erzeugen dürfen und wieviel. Zum Beispiel kann festgelegt werden, dass der Dekan nur eine bestimmte Anzahl von Lehrveranstaltungen in einem Studiengebiet anbieten darf, und dass er nicht beliebig viele Dozenten einstellen kann. Diese Festlegungen können in der Datenbank als Constraints gespeichert werden. In der Informationssicht kann aber auch festgelegt werden, welche Objekte, die Objekte eines bestimmten Objekttyps ändern dürfen. Es sollten nur kontrollierte und erwünschte und vor allem konsistente Änderungen durchgeführt werden können. Nicht jedes Objekt kann quer durch die Datenbank einfach Objekte ändern. Ein Student, der sich für eine Lehrveranstaltung angemeldet hat, möchte diese unbedingt belegen. Es sind aber nicht genügend Studenten für diese Lehrveranstaltung angemeldet, so dass die erforderliche Mindestanzahl an Studenten nicht erreicht wird. Der Student darf nun nicht in der Lage sein, die Mindestteilnehmerzahl herunterzusetzen, damit seinem Wunsch genüge getan wird. Dies sollte verboten bleiben, nur der Dekan ist in der Lage die Mindestteilnehmerzahl einer Lehrveranstaltung festzulegen.

13 Inhalt Das objektrelationale Datenmodell Visualisierung von ORDBMS
Die statische Sicht Die dynamische Sicht Die Informationssicht Das Zusammenspiel der Sichten Als letztes möchte ich noch kurz erklären wie die drei Sichten zusammengehören.

14 Zusammenspiel der Sichten
Festlegung von Berührungspunkten (z.B. Namen) Änderung in einer Sicht führen meistens zu Änderungen in den anderen Sichten Die Gesamtheit der Datenbank wird von allen drei Sichten insgesamt dargestellt. Sie sind einzeln jedoch nur eine Abstraktion des Ganzen. Jede Sicht ist eine ganz bestimmte Sichtweise unter Auslassung bestimmter Aspekte, um andere hervorzuheben. Die einzelnen Sichten können jedoch unabhängig voneinander entwickelt werden, insbesondere auch von verschiedenen Entwicklern. Sie müssen daher Berührungspunkte haben, an denen der Benutzer erkennt, wie sie zusammengehören und welche gemeinsame Aussage sie haben. Diese Berührungspunkte müssen klar definiert sein. Eine Möglichkeit ist es, die Objekttypnamen als invariant festzulegen. Die Modellentwickler müssen sich auf bestimmte Namen einigen, die dann konsistent während der ganzen Entwicklung beibehalten werden. Auch Methodennamen sollten gewissen Konventionen unterliegen, um die Übersicht zu behalten. In allen drei Modellen werden dann die gleichen Namen verwendet und der Benutzer ist in der Lage, das Zusammenspiel der einzelnen Komponenten zu erfassen. Die Sichten und deren Modelle existieren jedoch nicht völlig unabhängig voneinander. Entwickelt man die Sichten nacheinander, kann es passieren, dass man bei der Entwicklung des Sequenzdiagramms feststellt, dass man noch eine Methode braucht, deren Notwendigkeit bei der Entwicklung der statischen Sicht noch nicht ersichtlich war. Diese Methode darf dann aber nicht einfach von der Entwicklung der dynamischen Sicht an existieren, sie muss auch in die statische Sicht aufgenommen werden. Es kann aber auch passieren, dass erst beim Entwickeln der Informationssicht die Notwendigkeit einer Klasse sichtbar wird. Daraufhin müssen die bereits entwickelten Modelle mit großer Wahrscheinlichkeit geändert werden. Die Zusammenhänge zwischen den einzelnen Sichten sind nicht trivial. Bei der Entwicklung muss stets darauf geachtet werden, dass immer das gleiche System dargestellt wird, nur unter anderen Gesichtspunkten. Wird das nicht eingehalten, kann der Benutzer sehr schnell den Überblick verlieren. Dann hat die Visualisierung der Datenbank ihren Zweck, dem Benutzer die Übersicht über die Datenbank zu geben, und eine komplexe Datenstruktur erfassbar zu machen, nicht erfüllt.

15 Quellen PL/SQL User's Guide and Reference Release 8.1.5
 Oracle8i Supplied Packages Reference Release 8.1.5 Autor. "Datenbanken und Objekte: objektrelationale Datenbanksysteme".   Autor. "SQL-99: Der objektrelationale Datenbankstandard". Autor. "Objektrelationale Datenmodell- und Spracherweiterungen kommerzieller Datenbanksysteme".  Ich denke die vorgestellte Methode ist ein guter Weg die Komplexität eines objektrelationalen DBS darzustellen. Es werden Techniken verwendet, die weit verbreitet sind und oft angewendet werden. Wie zum Beispiel das UML-Klassendiagramm und das ER-Modell. Man muss also nicht erst komplizierte Methoden erlernen um objektrelationale DBS visualisieren zu können. Danke.