Datenbank-Sichten und Daten- Repräsentation

Größe: px
Ab Seite anzeigen:

Download "Datenbank-Sichten und Daten- Repräsentation"

Transkript

1 Universität Paderborn Fachbereich 17 - Mathematik/Informatik Arbeitsgruppe Softwaretechnik Prof. Dr. W. Schäfer Warburger Str Paderborn Datenbank-Sichten und Daten- Repräsentation Seminarausarbeitung im Rahmen der Projektgruppe Entwicklung eines verteilten multimedia Systems mit Hilfe von Design Pattern im Projekt von Carsten Reckord Bergstraße Verl Paderborn, Juni 2001

2 ii

3 i. Inhaltsverzeichnis KAPITEL 1 EINFÜHRUNG IN SICHTEN SICHTEN IN RELATIONALEN DATENBANKEN SICHTEN IN OBJEKTORIENTIERTEN DATENBANKEN Sichten in ODMG Ein Sichtenmodell für O Sichten in Coocoon WEITERE ANWENDUNGEN FÜR SICHTEN... 8 KAPITEL 2 SICHTEN IN VERTEILTEN DATENBANKEN FRAGMENTIERUNG DURCH SICHTEN SCHEMA-INTEGRATION DURCH SICHTEN MATERIALISIERTE SICHTEN KAPITEL 3 DATENBANKMODELLIERUNG MIT UML MODELLIERUNG IN UML MODELL-INTEGRATION IN UML ABBILDUNG AUF RELATIONALE DATENBANKEN SICHTEN IN UML KAPITEL 4 ZUSAMMENFASSUNG ANHANG A ARBEITEN MIT RELATIONALEN SICHTEN A.1 SICHTENDEKLARATION IN SQL A.1.1 Sichten-Typen A.2 ANFRAGEN AUF SICHTEN A.2.1 Sichtenauflösung (view resolution): A.2.2 Sichten-Materialisierung (View Materialization) A.2.3 Einschränkungen für die Sichtendefinition A.3 UPDATEOPERATIONEN AUF SICHTEN A.3.1 Änderbare Sichten nach ISO-Standard A.3.2 Das View Update Problem jenseits des ISO Standards A.4 ERGÄNZUNGEN ZUM RELATIONALEN SICHTENMODELL iii

4 A.4.1 Virtuelle Attribute in SQL A.4.2 Objektrelationale Datenbanken und Objektsichten ANHANG B LITERATURVERZEICHNIS ANHANG C ABBILDUNGSVERZEICHNIS iv

5 KAPITEL 1 Einführung in Sichten Die meisten modernen Datenbank-Systeme besitzen eine Drei-Schichten-Architektur, die dem ANSI/SPARC Datenbank-Modell[BG92] entspricht. Die in diesem Modell definierten Schichten beschreiben unterschiedliche Abstraktionsebenen für die Daten einer Datenbank. Dies sind im einzelnen das interne Schema, daskonzeptionelle Schema und das externe Schema. externes Schema n externe Schicht Benutzersichten konzeptionelles Schema konzeptionelle Schicht internes Schema interne Schicht physische Schicht Abbildung 1: Die Drei-Schicht-Architektur des ANSI/SPARC-Modells Das interne Schema dient der Abbildung der Datenbank auf interne Datenstrukturen des Datenbank-Systems und auf das Dateisystem des unterliegenden Betriebssystems. Das konzeptionelle Schema beschreibt die logische Struktur der Daten in der Datenbank, also die Art und Menge der gespeicherten Daten, sowie ihre Abhängigkeiten untereinander und Integritätsbedingungen für die Datenbank. Diese logische Struktur wird in der Regel von dem jeweiligen Datenbank- Administrator angelegt und verwaltet. Beim Entwurf des konzeptionellen Schemas ist eine Reihe von Rahmenbedingungen zu beachten, die eine effektive und redundanzfreie Speicherung von Daten in der Datenbank sicherstellen sollen, wie zum Beispiel die Normalisierung von relationalen Datenbanken. Das hat zur Folge, daß in der konzeptionellen Sicht auf eine Datenbank die Daten häufig nicht so strukturiert sind, wie es den Anforderungen der Benutzer entspricht. Zudem haben unterschiedliche Benutzer häufig unterschiedliche Anforderungen an die Strukturierung dieser Daten und in der Regel benötigen einzelne Benutzer jeweils nur Zugriff auf einen Teil der Daten in der Datenbank. Das externe Schema des Drei-Schichten-Modells erlaubt daher die Definition sogenannter Benutzersichten auf die Datenbank, um diesen Anforderungen gerecht zu werden. Eine Benutzersicht (oder einfach Sicht, engl. view) ist eine Darstellung der Daten des unterliegenden konzeptionellen Schemas, die an die Anforderungen individueller Benutzer oder 1

6 1.1 Sichten in relationalen Datenbanken Anwendungsfälle angepaßt ist. Sie erlaubt eine Restrukturierung der Daten in eine Form, die den individuellen Anforderungen gerecht wird und erlaubt eine Fokussierung auf die in dem jeweiligen Kontext relevanten Informationen durch Ausblendung unwichtiger Daten. Eine Sicht wird beschrieben durch Anfragen an die Datenbank und reflektiert zu jeder Zeit das Ergebnis dieser Anfragen. Ein Benutzer kennt lediglich die für ihn vorgesehene Sicht. Er kann sie abfragen und verändern, wie eine eigenständige Datenbank, ohne sich mit dem unterliegenden konzeptionellen Schema auseinandersetzen zu müssen. Durch dieses Konzept bleibt dem Benutzer die konzeptionelle Komplexität der eigentlichen Datenbank verborgen, wodurch eine signifikante Vereinfachung im Umgang mit der Datenbank erreicht wird. Zudem wird hierdurch eine weitgehende logische Unabhängigkeit von dem unterliegenden Schema erreicht. Denn bei Änderungen an dem konzeptionellen Schema, etwa durch das Einfügen neuer Attribute oder strukturelle Änderungen, können die Sichten meist konstant gehalten werden. Hierzu sind unter Umständen lediglich die Sichtendefinitionen entsprechend anzupassen. Desweiteren bieten Sichten einen sehr flexiblen und komplexen Mechanismus zur Zugriffsbeschränkung auf sensible Informationen. So können diese Informationen in einzelnen Sichten vor dem Benutzer verborgen werden, während sie in anderen Sichten verfügbar sind. Schließlich wird durch Sichten die Vereinfachung von Anfragen an die Datenbank ermöglicht, indem häufig auftretende Teilanfragen als Sichten definiert werden. Diese ersetzen dann in der Formulierung der Anfrage die entsprechende Teilanfrage. Da das Sichtenmodell von Datenbanken dazu geeignet ist - und meistens dazu verwendet wird - logische Zusammenhänge zwischen den Informationen in einer Datenbank geeignet zu repräsentieren, kann man solche Sichten als logische Sichten bezeichnen. In den folgenden Abschnitten werden die Sichtenmodelle für die zwei bedeutendsten Klassen von Datenbank-Systemen vorgestellt: relationale und objekt-orientierte Datenbanken. 1.1 Sichten in relationalen Datenbanken Eine relationale Datenbank besteht aus einer Menge von Tabellen, den sogenannten Relationen. Jede Relation besitzt einen eindeutigen Namen und ist eine Ausprägung eines Relationen-Schemas. Ein solches Relationen-Schema besteht aus einer Liste von Attributen und deren zugehörigen Wertebereichen und zusätzlichen Integritätsbedingungen. Jedes Attribut definiert eine Spalte der Relation. Die Gesamtheit der Relationen-Schemata aller in einer Datenbank enthaltenen Relationen bildet das konzeptionelle Schema der Datenbank, das häufig auch als Datenbankschema bezeichnet wird [EN94]. Im relationalen Modell hat der Begriff der Sicht eine etwas andere Bedeutung, als die bisher verwendete. Wie dargestellt, bezeichnet der Begriff der Sicht im Allgemeinen die Gesamtheit des externen Modells eines Benutzers. Im relationalen Modell jedoch bezeichnet eine Sicht eine virtuelle Relation. Im Gegensatz zu einer Basis-Relation, die Teil des konzeptionellen Schemas 2 KAPITEL 1

7 1.2 Sichten in objektorientierten Datenbanken ist und deren Tupel physisch in der Datenbank gespeichert sind, erscheint eine Sicht dem Benutzer zwar ebenfalls wie eine gewöhnliche Relation, die er genauso benutzen kann, wie eine Basis-Relation (mit Einschränkungen bezüglich Updateoperationen, siehe Anhang A). Ihr Inhalt ist jedoch nicht statisch festgelegt und wird auch (mit Ausnahmen, siehe Anhang A) nicht physisch gespeichert. Stattdessen wird er dynamisch aus einer Datenbank-Anfrage berechnet, die bei der Definition der Sicht angegeben wird. Bei dieser Anfrage handelt es sich um eine normale Datenbank-Anfrage, die mit Hilfe der relationalen Algebra[EN94] - oder einer darauf basierenden Anfragesprache, wie SQL[EN94] - auf Basis-Relationen und bestehenden Sichten formuliert werden kann. Eine Sicht reflektiert zu jeder Zeit das Ergebnis der sie definierenden Anfrage. Änderungen an den in der Anfrage verwendeten Relationen werden - im Gegensatz zu einem Snapshot, der stets das Ergebnis der Anfrage zum Definitionszeitpunkt darstellt - unmittelbar in der Sicht reflektiert. Umgekehrt werden Updateoperationen auf einer Sicht (so sie erlaubt sind, siehe Anhang A) direkt auf die unterliegenden Relationen umgesetzt. Die Syntax zur Definition relationaler Sichten, sowie die Erörterung von Problemen bei Updateoperationen auf relationalen Sichten und Lösungsansätzen hierfür kann Anhang A entnommen werden. 1.2 Sichten in objektorientierten Datenbanken Objektorientierte Datenbanksysteme (oodbms) wenden das objektorientierte Modell, das aus vielen aktuellen Programmiersprachen bekannt ist, auf konventionelle Datenbanken an. Objekte der realen Welt werden hierbei auf Datenbank-Objekte abgebildet, die Instanzen von Klassen sind. Eine Klasse definiert Attribute, die Eigenschaften eines Objektes beschreiben und so deninternen Zustanddes Objektes darstellen, zusammen mitnachrichten und Methoden zur Abfrage und Veränderung dieses Zustandes. Ein Objekt reagiert auf eine Nachricht durch die Ausführung der dieser Nachricht zugeordneten Methode. Eine Nachricht definiert also lediglich eine Schnittstelle für den Aufruf einer Methode, die diese Nachricht implementiert. So ist es möglich, Methoden außerhalb der Datenbank mit Hilfe von herkömmlichen objektorientierten Sprachen zu implementieren. Jedes Objekt hat eine eindeutige Objekt-ID zur Identifikation, die konstant und unabhängig von dem inneren Zustand des Objektes ist. Ferner erlauben die meisten objektorientieretn Datenbanken die Angabe eines Extents für jede Klasse. Ein Extent ist ein benannter Container, der alle persitenten Instanzen dieser Klasse enthält (Diese werden, im Gegensatz zu transienten Instanzen, in der Datenbank gespeichert). Da die Umsetzung dieses Grundkonzeptes in unterschiedlichen objektorientierten Datenkanksystemen stark variiert und es eine Fülle unterschiedlicher Sichtenmodelle für OO-Datenbanken gibt, sollen hier beispielhaft lediglich das Sichtenmodell des ODMG3.0-Standards und zwei weitere, etwas komplexere Modelle beschrieben werden. Einführung in Sichten 3

8 1.2 Sichten in objektorientierten Datenbanken Sichten in ODMG 3.0 Der ODMG 3.0-Standard der Object Data Management Group enthält nur eine sehr rudimentäre Unterstützung für Sichten. Die Abfragesprache OQL (Object Query Language) von ODMG erlaubt lediglich die Definition von benannten Abfragen mit folgender Syntax: define <name>[(<parameter>[,...])] as <query> wobei <query> eine Standard-OQL-Anfrage bezeichnet, die analog zu SQL die Struktur select... from... where... hat. Zusätzlich können optionale Parameter angegeben werden, die in der Anfrage verwendet werden können. Obwohl dies eine Gruppierung von Instanzen mit bestimmten durch die Anfrage bestimmten Eigenschaften erlaubt, ist eine echte Restrukturierung des konzeptionellen Schemas der Datenbank nicht möglich. So können etwa keine Attribute von Klassen versteckt werden, ohne die Objektstruktur der Instanzen zu verlieren und stattdessen lediglich einfache Tupel von Attributdaten zu erhalten. Auch eine Erweiterung und Umstrukturierung der Klassenstruktur des konzeptionellen Schemas durch virtuelle Klassen analog zu virtuellen Relationen des relationalen Modells ist nicht möglich. Daher kann mit diesem Konzept kein externes Schema als Abstraktion von dem konzeptionellen Schema der Datenbank erzeugt werden. Da häufig angeführt wird, daß objektorientierte Datenbanken eine Erweiterung der Idee herkömmlicher (relationaler) Datenbanken darstellen sollen und als solche mindestens deren Funktionalität und Mächtigkeit zur Verfügung stellen sollten, werden im Folgenden zwei weitere Sichtenmodelle vorgestellt, die in ihrer Mächtigkeit den Sichten relationaler Datenbanken ähneln Ein Sichtenmodell für O2 Das im Folgenden vorgestellte Sichtenmodell aus [AB91] setzt auf dem objektorientierten Datenbanksystem O2 auf und erweitert dieses um eine flexible Sichtenstruktur. Ziel dieses Sichtenmodelles ist ein flexibler Mechanismus zur Restrukturierung der Datenbank und zur Modifikation des Verhaltens und der Struktur von Objekten. Dazu führen die Autoren in ihrem Sichtenmodell virtuelle Attribute und virtuelle Klassen ein. Eine Sicht besteht in diesem Modell aus importierten Klassen von einer oder mehreren Datenbanken, Sichtbarkeitsregeln für die Attribute dieser Klassen, sowie zusätzlichen virtuellen Klassen und virtuellen Attributen. Eine Sichtendefinition hat folgende Form: create view <name> {import/hide specifications} {class/attribute definitions} Import-Spezifikationen haben die Form 4 KAPITEL 1

9 1.2 Sichten in objektorientierten Datenbanken import {class <name> all classes} from database <db> In relationalen Datenbanken hat es ausgereicht, die Attribute einer virtuellen Relation explizit in der definierenden Anfrage aufzulisten. In objektorientierten Systemen ist so ein Vorgehen problematisch, da hierdurch auch alle Attribute, die in Unterklassen definiert sind, verborgen würden. Daher erlaubt dieses Modell explizit das Verstecken von Attributen mit folgender Syntax: hide attribute <name> in class <class> wobei <class> eine beliebige (virtuelle oder importierte) Klasse in der Sicht sein kann. Virtuelle Attribute Virtuelle Attribute sind Attribute, deren Wert nicht explizit definiert ist, sondern aus dem aktuellen Objektzustand errechnet werden. Hierdurch können zum Beispiel mehrere Attribute einer Klasse zu einem komplexen Attribut zusammengefaßt werden, wie folgendes Beispiel zeigt: Eine Klasse Person sei gegeben durch die Attribute name, city, street und zipcode. Dann können letztere drei Attribute zu einem komplexen Attribut address zusammengefaßt werden: attribute address in class Person has value [city: self.city, street: self.street, zipcode: self.zipcode] Die Syntax zur Definition eines Attributes lautet attribute <name>[(<parameter>,[...])] [of type <type>] in class <class> [has value <value>] Wird die Option has value angegeben, so handelt es sich um ein virtuelles Attribut, ansonsten um ein normales. Die Angabe von Parametern ist nur für virtuelle Attribute gestattet. Diese Definition erlaubt außerdem die Behandlung von Methoden als virtuelle Attribute mit Parameter, deren Wert durch den Methodenrumpf berechnet wird. Virtuelle Klassen Die Klassenhierarchie der importierten Klassen kann um virtuelle Klassen erweitert werden. Dazu ist für jede virtuelle Klasse eine Population mit bestehenden oder neuen Objekten, die Position in der Klassenhierarchie und das Verhalten - also die Menge der unterstützten Nachrichten - zu definieren. In dem Modell ist lediglich die Population explizit anzugeben. Position und Verhalten werden daraus anhand der enthaltenen Objekte automatisch abgeleitet. Für die Population virtueller Klassen gibt es mehrere Möglichkeiten: Spezialisierung: Die virtuelle Klasse enthält alle Instanzen einer Klasse, die einer bestimmten Bedingung genügen. Diese wird in Form einer Datenbank-Anfrage ausgedrückt. Einführung in Sichten 5

10 1.2 Sichten in objektorientierten Datenbanken Generalisierung: Die virtuelle Klasse enthält alle Instanzen einer Menge von Unterklassen Verhaltensabhängige Generalisierung: Die virtuelle Klasse enthält alle Klassen, die Attribute oder Methoden bestimmten Namens und bestimmter Signatur haben. Imaginäre Objekte: Imaginäre Objekte sind neu erzeugte Objekte, deren Attributwerte aus den Attributwerten bestehender Objekte berechnet werden. Insgesamt sieht die Definition einer (virtuellen) Klasse wie folgt aus: class <name> [(<parameter>[,...])] [includes {<classname> like <classname> [imaginary] (<query>)}[,...]] Mit der Option like <classname> werden dabei alle Objekte eingebunden, deren Klassen mindestens die Attribute und Methoden von <classname> haben. Die optionalen Parameter können wie bei virtuellen Attributen als Argumente der Datenbankanfrage verwendet werden. Das Schlüsselwort imaginary muß angegeben werden, wenn das Ergebnis der Anfrage eine Liste von Attributwerten ist, aus denen ein neues, imaginäres Objekt erzeugt werden soll. Ansonsten darf in der select-klausel der Anfrage nur ein einzelnes Objekt angegeben sein. Hier zwei Beispiele: class Supported (maxincome) includes Senior, Student, (select a in Adult where a.income<maxincome) class Family includes imaginary (select [husband:h, wife:h.partner] from Person H where H.sex= male ) Nach der Definition einer virtuellen Klasse und ihrer Population können neue virtuelle Attribute (und damit auch Methoden) für die Klasse definiert werden. Zum Beispiel attribute supportamount in Supported has value amount(self) wobei amount eine dem System bekannte Funktion zur Berechnung der Unterstützungshöhe ist. Virtuelle Klassenhierarchie Die Klassenhierarchie der Sicht mit allen importierten Klassen und den darauf definierten virtuellen Klassen kann mittels Typinferenz automatisch hergeleitet werden. Sei hierzu C eine virtuelle Klasse, die die Klassen C 1...C k und Instanzen der Klassen C k+1...c n enthält. Es gilt: Ist D eine Oberklasse aller C k, so ist D eine Oberklasse von C C i ist Unterklasse von C für alle i [,] 1 k 6 KAPITEL 1

11 1.2 Sichten in objektorientierten Datenbanken Updateoperationen auf Sichten Die Sichten, die mit diesem Modell erzeugt werden können, sind hinsichtlich der meisten Operationen updatefähig. Einzige Bedingungen sind, daß bei Mehrfachvererbung Attributnamen eindeutig aufgelöst werden können (ansonsten entsteht Schizophrenie[AB91]) und alle Updatemethoden auf imaginären Objekten redefiniert sind, um die entsprechenden Änderungen an den ursprünglichen Objekten vorzunehmen. Die zweite Bedingung entspricht damit der Idee aus Anhang A, Updates auf relationale Sichten zu ermöglichen durch abstrakte Datentypen mit entsprechenden Updateoperationen Sichten in Coocoon Einen anderen Ansatz verfolgt das COCOON-System [LST91]. Anstatt die Syntax des Datenbanksystems um zusätzliche Konstrukte zu erweitern, wie dies im vorangegangenen System der Fall ist, wird eine Sicht ähnlich zu SQL durch einen Ausdruck der Form define view <name> as <query> definiert. Anders als in SQL oder dem vorangegangenen Beispiel wird in diesem System jedoch durch eine besondere Eigenschaft der Anfragesprache COOL die Update-Fähigkeit de Sichten sichergestellt: Objekt-erhaltende Operatorsemantik. Im Gegensatz zur OQL, die relationale Semantik hat, also Tupel von Werten zurückliefert, liefert COOL existierende Objekte zurück. Hierfür existieren Operationen zur Selektion, Projektion und Erweiterung von Objekten um neue Methoden: select [<query>](<source>) project[<attr>[,...]](<source>) extend[<function-name>:=<expr>[,...]](<source>) wobei <source> einen Klassennamen oder einen mengenwertigen Ausdruck bezeichnet. Zusätzlich existieren die Mengenoperationen union, intersect und difference. Ein mengenwertiger Ausdruck ist ein Klassenname, über den alle Instanzen der Klasse referenziert werden, eine der oben angegebenen Operationen sowie jede Kombination hieraus mit Hilfe von Mengenoperationen. Der Unterschied zur relationalen Semantik von OQL soll anhand eines Beispiels dargestellt werden: Sei Person eine Klasse mit den Attributen name, sex, age und income. In OQL liefert die Projektion»select p.name, p.sex from Person p«eine Menge von zweidimensionalen Tupeln mit den Werten der Attribute name und sex der Instanzen von Person.Dieselbe Projektion in COOL, gegeben durch»project[name, sex](person)«, liefert alle Instanzen von Person zurück, blendet jedoch alle Attribute außer name und sex aus, so daß darauf nicht zugegriffen werden kann. Wie gesagt ist durch die Semantik der Abfragesprache sichergestellt, daß alle in COOL möglichen Anfragen zur Definition update-fähiger Sichten genutzt werden können. Denn alle Operationen werden durch die objekterhaltende Semantik direkt auf den realen Objekten ausgeführt. Einführung in Sichten 7

12 1.3 Weitere Anwendungen für Sichten Jede Sicht ist in diesem Modell eine neue Klasse, für die mittels der extend-operation auch neue Methoden definiert werden können. Ferner wird in [Tre91] gezeigt, daß auch eine verhaltensabhängige Generalisierung analog zu Abschnitt möglich ist. Damit bietet auch dieses Sichtenmodell die Möglichkeit zur flexiblen Restrukturierung des konzeptionellen Schemas. Im Gegensatz zu dem Sichtenmodell aus Abschnitt definiert dieses Modell jedoch Sichten vollständig mit Hilfe der Anfragesprache und ist somit wesentlich einfacher aufgebaut als das O2-Modell. 1.3 Weitere Anwendungen für Sichten In der Einleitung ist dargestellt worden, daß ein externes Schema für eine Datenbank sinnvoll ist, um logische Unabhängigkeit vom konzeptionellen Schema zu erhalten und um die Struktur der Datenbank an die individuellen Anforderungen einzelner Benutzer anpassen zu können. Darüber hinaus gibt es aber eine Vielzahl weiterer interessanter Anwendungsgebiete für Sichten: Schema-Entwurf durch Sichtenintegration: Eine Möglichkeit, das konzeptionelle Schema einer Datenbank bottom up zu entwickeln. Die Anforderungen an die Datenbank werden für alle Benutzergruppen getrennt als Sichten entwickelt. Durch Zusammenfügen dieser Sichten und Eliminierung möglicher Konflikte zwischen ihnen kann dann das Gesamtschema hergeleitet werden. Datenbank-Integration: Daten können aus einer Datenbank in eine andere exportiert werden, indem die unterschiedlichen Schemata der beteiligten Datenbanken mit Hilfe von Sichten auf ein gemeinsames (Teil-)Schema abgebildet werden, über das dann die Daten ausgetauscht werden können Anpassung des Datenmodells: Sichten können genutzt werden, um auf eine Datenbank mit einem anderen Datenmodell zuzugreifen. So können etwa Objekt-Sichten auf relationale Datenbanken[BKSW91] (was grob gesagt das Prinzip objektrelationaler Datenbanken ist) oder relationale Sichten auf objektorientierte Datenbanken definiert werden. Visualisierungssysteme: Bei der Visualisierung von Daten einer Datenbank tritt dasselbe Problem auf, wie bei materialisierten Sichten. Ein Visualisierungssystem sollte stets den aktuellen Datenstand repräsentieren. Daher muß es bei Änderungen an den Daten entsprechend aktualisiert werden. Dies entspricht dem View Maintenance Problem, das in Anhang A vorgestellt wird. Einige Visualisierungssysteme bauen daher auf einer Model-View-Controller-Architektur auf, die materialisierte Sichten für das Modell und die zugehörigen Maintenancealgorithmen für den Controller verwenden.[lee] Weitere Anwendungsmöglichkeiten werden in Kapitel 2 im Zusammenhang mit verteilten Datenbanken erläutert. 8 KAPITEL 1

13 KAPITEL 2 Sichten in verteilten Datenbanken 1 globale n Benutzersichten globales Schema 1 globale n Benutzersichten globales Schema Verteilte Datenbanken können aufgefaßt werden als logisch integrierte Datenmengen, die physikalisch über ein Netzwerk verteilt sind. Verteilte Datenbanksysteme sind damit Softwaresysteme zur Verwaltung einer verteilten Datenbank, so daß die Verteilung für den Benutzer transparent ist. Die meisten verteilten Datenbanksysteme erreichen diese Transparenz durch eine Architektur, die dem ANSI/SPARC Modell entspricht. Die verschiedenen Klassen von verteilten Datenbanksystemen lassen sich grob unterteilen in (homogene) verteilte Datenbanksysteme, (heterogene) Multi-Datenbanksysteme und föderierte Datenbanksysteme. Sie unterscheiden sich in der Art der lokalen Datenbanken, auf denen sie aufbauen, und deren Integration in das SPARC-Modell. Abbildung 2 zeigt die Architekturen dieser drei Klassen[BG92]. Fragmentierungs- Schema Hilfsschema globale 1 n Benutzersichten Allokations- Schema Hilfsschema Hilfsschema lokale konzeptionelle 1 Schemata... n lokale 1 interne Schemata n 1... n lokale Benutzersichten lokale konzeptionelle 1 Schemata... n lokale 1 interne Schemata n 1... n lokale Benutzersichten 1... n lokale konzeptionelle 1 Schemata... n lokale 1 interne Schemata n 1... n lokale DB lokale DB lokale DB a) verteiltes Datenbank-System b) Multidatenbank-System c) Föderiertes Datenbank-System Abbildung 2: Verteilte Datenbankarchitekturen 9

14 Architekturen verteilter Datenbanken (Homogene) Verteilte Datenbanken bestehen aus mehreren gleichartigen lokalen Datenbanken, auf die die Daten eines globalen Schemas aufgeteilt sind. Das Fragmentierungsschema definiert, wie die Daten des globalen Schemas auf die lokalen Datenbanken aufgeteilt werden und das Allokierungsschema definiert, in welchen lokalen Datenbanken diese Fragmente abgelegt sind. Der Zugriff auf die Daten erfolgt ausschließlich über die verteilte Datenbank. (Heterogene) Multi-Datenbanksysteme bestehen hingegen aus verschiedenartigen Datenbanksystemen mit eventuell unterschiedlichen Datenmodellen. So kann zum Beispiel eine lokale Datenbank ein hierarchisches Datenmodell verwenden, während eine andere ein relationales Modell verwendet. Multi-Datenbanksysteme haben häufig ein Hilfsschema, um zum Beispiel die Umrechnung von Maßeinheiten in verschiedenen lokalen Datenbanken zu ermöglichen. Einige Systeme haben auch ein Fragmentierungsschema. Multi-Datenbanksysteme werden meist dort eingesetzt, wo auf bestehende Datenbanken aufgesetzt werden soll. Sie erlauben daher insbesondere die normale Weiterverwendung der lokalen Systeme durch Benutzer. Föderierte Datenbanksysteme sind spezielle Multi-Datenbanksysteme, die lediglich die Daten, die sie mit anderen Datenbanken teilen sollen, in einem Export-Schema definieren. An einem föderierten System beteiligte Datenbanken können das System jederzeit verlassen oder ihm beitreten. Den lokalen Systemen ist es selbst überlassen, mit Hilfe der zur Verfügung stehenden Exportschemata ein eigenes globales Schema zu definieren. Sichten auf verteilte Datenbanken Wie bereits erwähnt verhält sich eine verteilte Datenbank hinsichtlich Datenbankoperationen völlig transparent und die Verteilung ist für den Benutzer nicht erkennbar. Anfragen und Updateoperationen auf der verteilten Datenbank werden vom Datenbanksystem in entsprechende Operationen auf den lokalen Datenbanken umgesetzt. Daher ist auch die Definition von Sichten mittels Anfragen auf der Datenbank für den Benutzer transparent. Analog zu zentralisierten (nicht-verteilten) Datenbanken wird die definierende Anfrage einer Sicht gespeichert und bei Bedarf durch Sichtenauflösung oder Materialisierung (siehe Anhang A) für Operationen zur Verfügung gestellt. Somit gelten für Sichten auf verteilte Datenbanken ebenfalls alle in Kapitel 1 dargestellten Eigenschaften. In diesem Kapitel soll daher lediglich auf drei spezielle Anwendungsmöglichkeiten von Sichten in verteilten Datenbanksystemen eingegangen werden: die Verwendung von Sichten zur Beschreibung von Fragmentierung und zur Schema-Integration, sowie die Optimierung der Zugriffszeit durch materialisierte Sichten. Im weiteren Verlauf dieses Kapitels wird zur einfacheren Darstellung für die Datenbanken ein relationales Datenmodell angenommen. Alle Ausführungen lassen sich jedoch auch auf andere Datenmodelle mit entsprechend mächtigen Sichtenmodellen übertragen. 10 KAPITEL 2

15 2.1 Fragmentierung durch Sichten 2.1 Fragmentierung durch Sichten In verteilten Datenbanken werden alle Daten auf die unterliegenden lokalen Datenbanken aufgeteilt. Dies wird als Fragmentierung bezeichnet. Hierbei ist es möglich, lediglich die Relationen des globalen Schemas auf die lokalen Datenbanken aufzuteilen. Häufig werden jedoch auch einzelne Relationen auf mehrere lokale Datenbanken aufgeteilt. Hierzu können etwa vollständige Tupel einer Relation auf unterschiedliche lokale Datenbanken verteilt werden, was als horizontale Fragmentierung bezeichnet wird. Alternativ kann eine Relation entlang ihrer Attribute aufgetrennt werden, was als vertikale Fragmentierung bezeichnet wird. Eine Kombination beider Techniken wird als hybride Fragmentierung bezeichnet. Die Aufteilung einer Relation entlang ihrer Tupel beziehungsweise ihrer Attribute wird auch in Anhang A beschrieben. Dort erfolgt diese Aufteilung durch die Definition von horizontalen beziehungsweise vertikalen Sichten. Es liegt daher nahe, dasselbe Vorgehen für die Definition des Fragmentierungsschemata anzuwenden. Bei der vertikalen Fragmentierung ist lediglich darauf zu achten, daß alle Fragmente mindestens den Primärschlüssel oder einen vollständigen Sekundärschlüssel enthalten müssen, damit die Fragmente wieder korrekt zusammengesetzt (materialisiert) werden können. Die Definition des Fragmentierungsschemas mit Hilfe von Sichten hat den Vorteil, daß eine geschlossene Darstellung der verschiedenen Abstraktionsebenen des Datenbanksystems existiert. Von einem zentralen globalen Schema wird sowohl das externe Schema als auch das Fragmentierungsschema auf dieselbe Weise abgeleitet. Dies erlaubt zudem die Auffassung des Datenbanksystems als eine einheitliche hierarchische Struktur mit den Fragmenten als Blätter, von denen Relationen und Sichten abgeleitet werden können[cbs97]. 2.2 Schema-Integration durch Sichten In Abschnitt 1.3 ist bereits erwähnt worden, daß Sichten zur Entwicklung eines komplexeren Schemas genutzt werden können, ebenso wie zur Integration unterschiedlicher Datenbanken in ein gemeinsames Schema. Dies entspricht genau dem Problem der Schema-Integration für Multi-Datenbank-Systeme. Die Schemata unterschiedlicher existierender Datenbanken müssen in ein einheitliches und konsistentes globales Schema integriert werden. Die Tatsache, daß einzelne lokale Datenbanken eventuell unterschiedliche Datenmodelle verwenden, kann hier vernachlässigt werden, da das Multi-Datenbank-System auf jeden Fall sein eigenes Datenmodell auf die lokalen Datenmodelle abbilden können muß und umgekehrt. Der Vorgang der Schema-Integration wird in [BG92] als Serie von Abstraktionsschritten auf den Daten der lokalen Schemata beschrieben. Da das globale Schema höchstens die Summe der Daten der lokalen Schemata enthalten kann, in der Regel jedoch weniger, werden in diesen Abstraktionsschritten sukzessive Details der lokalen Schemata ausgeblendet oder transformiert. Diese Abstraktionsschritte lassen sich in verschiedene Kategorien unterteilen: SichteninverteiltenDatenbanken 11

16 2.3 Materialisierte Sichten Aggregationen: Beziehungen zwischen Objekten der lokalen Schemata werden durch ein abstrakteres Objekt ausgedrückt. Eine Aggregation zwischen Kunde und Händler kann etwa durch ein Objekt Vertrag repräsentiert werden. Generalisierung: Mehrere Relationen mit einer gemeinsamen Teilmenge an Attributen werden in eine Relation mit dieser Attributteilmenge umgesetzt. Selektion: Für das globale Modell ist nur ein Teil der Objekte eines Typs interessant. Dieser Abstraktionsschritt kann analog zur Generalisierung auch als Spezialisierung verstanden werden. Weitere Transformationen zur syntaktischen Anpassung der Schemata, etwa zur Einheitenkonvertierung oder um unterschiedliche Tabellenstrukturen einander anzupassen. Weitere Transformationen zur semantischen Anpassung, etwa um immanente Informationen lokaler Schemata als explizite Attribute in das globale Schema aufzunehmen. So kann etwa eine Relation mit Transportrouten in den lokalen Schemata jeweils nur die Zielorte beinhalten, während als Startort immanent der Standort der lokalen Datenbank angenommen wird. Haben die lokalen Datenbanken unterschiedliche Standorte, so müssen diese in der globalen Relation berücksichtigt werden. Diese Transformationen lassen sich in der Regel durch Operationen des globalen Datenmodells ausdrücken und können damit in Form von Sichten definiert werden. Aggregationen können im relationalen Modell etwa durch Join und Projektion ausgedrückt werden, Generalisierungen durch Vereinigung und Spezialisierungen durch Selektionsbedingungen. Damit läßt sich ähnlich zu den Ausführungen in Abschnitt 2.1 die Definition des Multi-Datenbank-Systems in einem geschlossenen Modell beschreiben. 2.3 Materialisierte Sichten Wie auch in Anhang A erläutert wird, ist eine dynamische Berechnung des Inhaltes einer Sicht bei jeder Anfrage durch Sichtenauflösung nicht immer erstrebenswert. Dies ist insbesondere in verteilten Datenbanken der Fall, da die definierende Anfrage einer Sicht in der Regel eine verteilte Anfrage auf mehrere Datenbanken ist. Besonders für häufig benutzte Sichten bedeutet dies einen hohen zeitlichen Aufwand und eine signifikante Zunahme des Kommunikationsvolumens im Netzwerk. Dies ist unter Umständen nicht akzeptabel. Daher werden in verteilten Datenbanken häufig materialisierte Sichten als Alternative zur Sichtenauflösung eingesetzt (siehe Anhang A). Dadurch werden Netzwerkzugriffe bei Anfragen an eine Sicht eliminiert. Lediglich bei der Aktualisierung einer Sicht aufgrund von Änderungen an den Basisrelationen entsteht Netzwerkverkehr und Systemlast. Durch Incremental View Maintenance (siehe Anhang A) kann beides weiter reduziert werden. View Maintenance-Algorithmen lassen sich anhand der Informationen klassifizieren, auf die sie zur Aktualisierung einer materialisierten Sicht zurückgreifen müssen. Im einfachsten Fall haben die Algorithmen Zugriff auf alle an der Sicht beteiligten Relationen. Ein Beispiel für einen solchen Algorithmus ist der counting-algorithmus[gm95]. Hierbei wird für jedes Tupel der Sicht 12 KAPITEL 2

17 2.3 Materialisierte Sichten dessen Multiplizität mitgespeichert. Änderungen an Tupeln werden durch Änderungen an diesem Zähler ausgedrückt. Einfügen eines neuen Tupels in eine Basisrelation erhöht den Zähler um eins, Löschen verringert ihn. Änderungen an einem Tupel werden auf Einfüge- und Löschoperationen abgebildet. Ein Tupel mit einer Multiplizität von Null wird aus der Sicht gelöscht. Algorithmen, die nur einen Teil der an einer Sicht beteiligten Relationen benötigen, sind für verteilte Datenbanken meist besser geeignet, da weniger Informationen zwischen den Netzwerkknoten ausgetauscht werden muß. Eine spezielle Unterklasse dieser Algorithmen erlaubt die Aktualisierung einer materialisierten Sicht nur unter Verwendung der Sicht selbst. Sichten, die durch einen solchen Algorithmus aktualisiert werden können, werden als self-maintainable views bezeichnet. Solche Sichten sind in verteilten Datenbanken besonders effizient zu aktualisieren, da sie nur eine Liste der Aktualisierungsoperationen auf ihren Basisrelationen benötigen, um aktualisiert zu werden. Häufig lassen sich View Maintenance-Algorithmen zudem mit Algorithmen für das sogenannte irrelevant update-problem kombinieren. Diese Algorithmen erlauben bereits im Vorfeld die Erkennung von Update-Operationen auf den Basisrelationen, die keinen Einfluß auf die Sicht haben. Eine große Klasse von Sichten sind die sogenannten SPJ-Sichten (Select-Project-Join). Ihre definierenden Anfragen sind von der Form select t i1.a j1,...,t in.a jn from R 1 t 1,...,R m t m where <cond 1 > and... and <cond k > wobei <cond i > entweder eine Join-Bedingung von der Form t.a=s.b oder eine Selektionsbedingung in Form eines Vergleiches mit einer Konstanten ist. Für die hierdurch definierte Klasse von Sichten kann gezeigt werden, daß es sich fast immer um self-maintainable SichteninBezug auf Lösch- und Update-Operationen handelt[gm95]. Anfrage-Optimierung durch materialisierte Sichten Die Verringerung der Antwortzeiten von Anfragen auf Sichten durch die Verwendung von materialisierten Sichten und effizienten Aktualisierungsalgorithmen kann aber darüber hinaus auch für zusätzliche Optimierungen weiterverwendet werden. In [GL01] wird ein Optimierer für Datenbankanfragen mit Hilfe von materialisierten Sichten vorgestellt. Hierzu werden automatisch eine große Zahl geeigneter SPJ-Sichten erzeugt, so daß viele Datenbank-Anfragen in Anfragen transformiert werden können, die ausschließlich auf materialisierte Sichten zugreifen. Durch geeignete Index-Strukturen, sogenannte Filter-Bäume, über die definierenden Anfragen dieser Sichten ist dieses view matching effizient zu realisieren. Es wird gezeigt, daß durch einen derartigen Optimierer immense Performance-Steigerungen möglich sind, da etwa % aller Anfragen durch Anfragen auf materialisierte Sichten ausgedrückt werden können. SichteninverteiltenDatenbanken 13

18 2.3 Materialisierte Sichten 14 KAPITEL 2

19 KAPITEL 3 Datenbankmodellierung mit UML Wie in Abschnitt und Abschnitt 2.2 zu erkennen ist, ist ein zentrales Problem des Datenbankentwurfs die Schema-Integration, also die Zusammenführung unterschiedlicher Benutzersichten zu einem zentralen Schema. Der Entwurf einer Datenbank erfolgt meist mit Hilfe von speziellen Entwurfsdiagrammen für den jeweiligen Datenbank-Typ, etwa Entity-Relationship- (ER-) Diagrammen für relationale Datenbanken oder erweiterten ER-Diagrammen (EER-Diagrammen) für objektrelationale oder objektorientierte Datenbanken. Häufig erfolgt der Entwurf einer Datenbank jedoch nicht isoliert, sondern eingebettet in den Entwurf einer oder mehrerer Applikationen, die auf die Datenbank zugreifen sollen. Diese Applikationen werden in der Regel mit Hilfe von objektorientierten Modellierungssprachen entworfen und in einer objektorientierten Programmiersprache wie C++ oder Java implementiert. Hieraus ergibt sich ein Problem im Zusammenhang mit herkömmlichen Entwurfsmethoden für Datenbanken. Denn die unterschiedlichen Modellierungssprachen für Datenbank und Applikationslogik erlauben keine geschlossene Modellierung des Systems. Vielmehr müssen Teile des Applikationsmodelles, die ebenfalls Bestandteil der Datenbank sind, dort entsprechend der eingesetzten Datenbank-Entwurfsdiagramme neu modelliert werden. Dieses Vorgehen hat nicht nur eine Erschwerung von Entwurfsänderungen durch die Umsetzung in zwei unterschiedlichen Modellen zur Folge. Auch eine Portierung auf eine andere, neuere Datenbanktechnologie, wie etwa von relationalen auf objektorientierte Datenbanken gestaltet sich sehr schwierig. Derartige Probleme können vermieden werden, wenn der Entwurf der Applikationslogik und der Datenbank in einem einzigen Modell mit Hilfe einer einheitlichen Modellierungssprache erfolgen kann. Diese sollte außerdem eine Abbildung des Modelles auf eine möglichst große Zahl von Datenbank-Typen erlauben. Wie gesagt wird die Applikationslogik meist objektorientiert entworfen. auch ER- und EER-Diagramme können leicht auf objektorientierte Modelle abgebildet werden. Auch Verfahren zur Lösung vieler traditioneller Probleme des Datenbankentwurfes, wie der Schema-Integration (siehe Abschnitt und Abschnitt 2.2), zeigen objektorientierte Ansätze. Daher liegt es nahe, die Datenbank zusammen mit der Applikationslogik mit einer objektorientierten Modellierungsprache zu entwerfen. Die Unified Modelling Language [UML] von Grady Booch, James Rumbaugh und Ivar Jacobson ist eine objektorientierte, grafische Modellierungssprache zur Beschreibung statischer und dynamischer Eigenschaften eines Softwaresystems. Sie ist aus einer Zusammenführung der Sprachen OMT [Rum94] von Rumbaugh, OOSE [Jac95] von Jacobson und Booch-Diagrammen [Boo94] von Grady Booch entstanden und wurde 1997 erstmals vorgestellt. 15

20 3.1 Modellierung in UML In den folgenden Absätzen soll der Entwurf von Datenbankschemata mit Hilfe der UML erläutert werden. Für eine genauere Darstellung der hier vorgestellten Methoden und der sich ergebenden Probleme siehe [Mul99]. 3.1 Modellierung in UML Die Modellierung eines Datenbank-Systems in UML erfolgt grundsätzlich genauso, wie die Modellierung eines herkömmlichen Software-Systems. Im Gegensatz zu herkömmlichen Modellierungsmethoden für Datenbanken wird nicht zwischen Datenbank- und Applikationsmodellierung unterschieden. In einem ersten Schritt werden die Anforderungen an das System in Form von Use-Case-Diagrammen modelliert. Hierbei werden Benutzer - dies können Anwender des Systems oder auch andere Systemkomponenten sein - als Aktoren in Form von Strichmännchen dargestellt. Alle Aktionen, die das System diesen Aktoren zur Verfügung stellen soll, werden als Use-Cases in Form von Ovalen dargestellt. Abbildung 3 zeigt ein solches Use-Case-Diagramm. Online shop add Customer customer support remove Customer process Order «uses» remove Order packager add Order identify customer Abbildung 3: Use-Case-Diagramm Für jeden Use-Case können in einem nächsten Schritt mit Hilfe von Kollaborationsdiagrammen diebeteiligten Objekte, ihre Beziehungen untereinander und die Operationen auf diesen Objekten identifiziert und modelliert werden. Abbildung 4 zeigt dies beispielhaft. 1:getOrder Customer OrderSystem address Packager 1.1:partsInStock recipient 3.2:removeOrder 1.1.1:inStock 2:getParts Order 3:ship parts Part Abbildung 4: Kollaborationsdiagramm»process Order«16 KAPITEL 3

21 3.1 Modellierung in UML Sind alle Objekte identifiziert, sokannhierauseineklassenhierarchie abgeleitet werden, indem gleichartige Objekte zu Klassen zusammengefaßt und Klassen spezieller Objekte als Unterklassen allgemeinerer Klassen modelliert werden. Attribute und Methoden der Klassen ergeben sich aus den Eigenschaften der Objekte in den Kollaborationsdiagrammen und den Kollaborationsnachrichten zwischen den Objekten. In Abbildung 5 ist ein Klassendiagramm zu dem Kollaborationsdiagramm aus Abbildung 4 und dem Use-Case-Diagramm aus Abbildung 3 dargestellt. Address +town:string +Street:String livesat Person OrderSystem name:string orders Customer 0..1 n Employee +custid:string recipient Order +id:integer +login:string 1 n +partsinstock():bool +identify():void +ship():void Packager 0..1 Part parts +instock():bool n Abbildung 5: Klassendiagramm Ist so schließlich das gesamte System modelliert, müssen die für die Datenbank relevanten Teile des Modelles identifiziert werden. Hierzu ist zunächst zwischen persistenten Klassen, deren Instanzen in der Datenbank gespeichert werden sollen, und transienten Klassen, die lediglich in der Applikationslogik verwendet werden, zu unterscheiden. So sind etwa in einem MVC- Modell nur die Modell-Klassen persistent, während die Instanzen der View- und Controller- Klassen ausschließlich in der Applikationslogik benötigt werden. Persistente Klassen werden in UML durch den Stereotyp «persistent» gekennzeichnet. Desweiteren muß entschieden werden, ob das dynamische Verhalten einer Klasse, also ihre Methoden und Signale, in der Datenbank oder in der Applikation realisiert werden soll. Für die Realisierung in der Applikation spricht hierbei bessere Portabilität des Verhaltens, einfachere Wartbarkeit und der meist wesentlich größere Funktionsumfang der verwendeten Programmiersprache. Für eine Implementierung in der Datenbank in Form von stored Procedures und Triggern spricht die höhere Performance bei Operationen auf großen Datenmengen und einem hohen Aufkommen an Transaktionen. Methoden, die auf transienten Daten arbeiten, sollten immer in der Applikation realisiert werden. Da die Umsetzung des so entstandenen Datenmodells auf eine objektorientierte Datenbank direkt erfolgen kann, soll hier nicht näher darauf eingegangen werden. Stattdessen wird in Abschnitt 3.3 die etwas problematischere Umsetzung in ein relationales Schema skizziert. Für eine genaue Beschreibung der Umsetzung in Schemata für unterschiedliche Datenbank-Typen siehe [Mul99]. Datenbankmodellierung mit UML 17

22 3.2 Modell-Integration in UML 3.2 Modell-Integration in UML Häufig soll eine Datenbank von mehreren Applikationen oder unterschiedlichen Komponenten eines großen Software-Systems verwendet werden. Hier bietet es sich an, analog zum Vorgehen der Sichtenintegration aus Abschnitt 1.3 diese Komponenten und ihre Anforderungen an die Datenbank nach dem dargestellten Verfahren zunächst einzeln zu modellieren. Für jede Komponente ergeben sich eine Anzahl von Use-Cases und aus jedem Use-Case kann ein Datenmodell entwickelt werden, das einer Sicht auf das Gesamtmodell (sowohl der Datenbank als auch der Applikationslogik) entspricht. Diese Modelle müssen anschließend zu einem einheitlichen Gesamtmodell zusammengefügt werden. Dies entspricht dem in Abschnitt 2.2 erläuterten Problem der Schema-Integration für verteilte Datenbanken. Auch hier kann die Integration mit Hilfe objektorientierter Techniken in einigen Schritten erfolgen[mul99]: 1. Identifikation von strukturellen Ähnlichkeiten in den einzelnen Modellen: Namensähnlichkeiten, ähnliche Beziehungen etc. 2. Mit Hilfe der so gewonnenen Informationen Identifikation von semantischen Gemeinsamkeiten: Unterschiedliche Klassen mit Gemeinsamkeiten in den enthaltenen Informationen, etc. 3. Integration der gefundenen Ähnlichkeiten in ein Modell: Beseitigung von Namenskonflikten, Umsetzung semantischer Gemeinsamkeiten der Klassen: Gemeinsame Daten in unterschiedlichen Klassen können mit Hilfe von Assoziationen ausgedrückt werden (siehe Abbildung 6) Ähnliche Klassen können durch Vererbung modelliert werden, wobei gemeinsame Attribute in einer Oberklasse modelliert werden und die unterschiedlichen Details in den entsprechenden Unterklassen (siehe Abbildung 6) 4. Beseitigung verbleibender Inkonsistenzen in den Modellen. Hier muß von Fall zu Fall eine geeignete Lösung gefunden werden. Eventuell sind auch die einzelnen Modelle entsprechend abzuwandeln. Ein Beispiel für ein solches Problem sind etwa nicht miteinander vereinbare Integritätsbedingungen. Person +name:string +sex:string +age:integer 0..1 livesat + Contact +name:string 0..1 contactmethods Person +name:string +sex:string +age:integer 0..1 contactmethods n Address +town:string +Street:String n ContactMethod n ContactMethod Abbildung 6: Integration von Klassendiagrammen Address +town:string +Street:String 18 KAPITEL 3

23 3.3 Abbildung auf relationale Datenbanken Das hier beschriebene Verfahren, die Komponenten eines Systems zunächst einzeln zu modellieren, hat zahlreiche Vorteile gegenüber einer geschlossenen Modellierung des gesamten Systems. Die kleineren Modelle sind zumeist übersichtlicher und einfacher zu erstellen. Durch die Aufteilung in mehrere Modelle können auch nach der Integration die Komponenten des Gesamtsystems leichter für eine modulare Entwicklung gruppiert werden. Und aus den einzelnen Modellen sind direkt die unterschiedlichen Benutzersichten für das externe Schema der Datenbank ableitbar. 3.3 Abbildung auf relationale Datenbanken Sobald das vollständige Modell einer Applikation und der zugehörigen Datenbank erstellt und der für die Datenbank relevante Teil, das Datenmodell, festgelegt ist, kann dieses Datenmodell in ein entsprechendes Datenbank-Schema umgesetzt werden. Während in objektorientierten Modellen Operationen auf individuellen Objekten ausgeführt werden und Navigation mit Hilfe von Assoziationen zwischen Objekten erfolgt, arbeiten relationale Datenbanken jedoch mengenbasiert. Operationen werden auf Datenmengen ausgeführt und Navigation erfolgt innerhalb oder zwischen Mengen von Daten. Aus diesem als impedance mismatch bekannten Problem ergeben sich zahlreiche Schwierigkeiten bei der Umsetzung eines objektorientierten Modells in ein relationales Datenbankschema. Im Folgenden soll skizziert werden, wie trotzdem eine recht einfache Umsetzung eines Teils des Modells möglich ist und welche objektorientierten Modellaspekte nicht oder nur schwer umzusetzen sind. Klassen und Vererbung Das objektorientierte Modell besteht aus Klassen und deren Instanzen, den Objekten. Im relationalen Modell werden Informationen dagegen in Form von Relationen, die Tupel von Daten enthalten, verwaltet. Es liegt nahe, Klassen auf Relationen abzubilden und deren Instanzen als Tupel ihrer Attributwerte in den Relationen abzulegen. Für jede Klasse kann so eine Relation in das Datenbankschema aufgenommen werden, die dieselben Attribute hat, wie die darzustellende Klasse. Vererbung kann bei diesem Vorgehen auf unterschiedliche Weisen umgesetzt werden: Jede Vererbungshierarchie wird durch eine Relation dargestellt. Die Relation enthält alle Attribute der beteiligten Klassen und für Instanzen einzelner Klassen werden nicht definierte Attribute durch null-werte repräsentiert. Die Hierarchie wird hierdurch geebnet. Jede Klasse wird durch eine Relation dargestellt, die alle Attribute der Klasse enthält. Für jede Instanz einer Klasse existieren Einträge in der zu der Klasse gehörenden Relation und den Relationen aller Oberklassen. Jede Klasse wird durch eine Relation dargestellt, die alle Attribute enthält, die in der Klasse neu definiert sind, sowie durch eine foreign key-beziehung zu der Relation der Vaterklasse. Die Attribute eines Objektes werden entsprechend auf die Relationen für Klasse und Oberklassen aufgeteilt. Datenbankmodellierung mit UML 19

24 3.3 Abbildung auf relationale Datenbanken Die erste Alternative erlaubt einfache Updates und Abfragen. Jedoch ist die Identifikation der zugehörigen Klasse für ein Tupel der Relation kompliziert und eventuell nicht eindeutig möglich. Dies erschwert die Implementierung von Integritätsbedingungen des OO-Modells. Außerdem wird die Erweiterung der Klassenhierarchie um neue Klassen oder Attribute von Klassen erschwert. Die letzte Alternative ermöglicht hingegen eine flexible und leicht erweiterbare Umsetzung der Klassenhierarchie. Jedoch ist das Auslesen der Attribute eines Objektes schwierig, da dies Joins über die Relationen aller Oberklassen des Objektes beinhaltet. Die zweite Alternative ist ein Kompromiß zwischen den beiden anderen Möglichkeiten. Sie erlaubt eine etwas flexiblere Umsetzung als Alternative 1 und eliminiert die in Alternative 3 benötigten Joins. Dafür führt sie aber beträchtliche Datenredundanzen ein, zusammen mit den daraus resultierenden Update-Problemen. Mehrfachvererbung ist in relationalen Datenbanken nur schwer zu simulieren und sollte nach Möglichkeit vermieden werden (siehe [Mul99]). Attribute Attribute des OO-Modells werden wie gesagt auf Attribute der Relationen abgebildet, die die Klassen repräsentieren. Im Gegensatz zu UML erlauben relationale Datenbanken nicht die Definition unterschiedlicher Sichtbarkeiten, so daß Attribute hier grundsätzlich immer als public umgesetzt werden. Spezielle Wertebereiche oder diskrete Wertemengen können auf Integritätsbedingungen oder auf Fremdschlüsselbeziehungen zu Wertetabellen abgebildet werden. Diese können entweder eine Abbildung zwischen Programmiersprachen- und Datenbank- Typen enthalten, oder direkt die (diskrete) Menge der gültigen Werte eines Attributes definieren. So kann eine solche Wertetabelle etwa den Java-Datentyp String auf den Datenbank-Typ varchar abbilden oder die Buchstaben T und F als erlaubte Werte zur Repräsentation des boolean-datentyps von Java in der Datenbank definieren[mul99]. Objekt-Identität Im objektorientierten Modell sind Objekte implizit und unabhängig von ihrem internen Zustand eindeutig identifizierbar. Um dies auf Tupel in einer relationalen Datenbank abbilden zu können, muß für jede Relation, die eine Klasse repräsentieren soll, ein geeigneter Primärschlüssel (Objekt Identität, OID) definiert werden. Sind im OO-Modell bereits Attribute für eine Klasse vorhanden, die Instanzen dieser Klasse eindeutig voneinander unterscheiden, so können diese verwendet werden. Ansonsten ist ein geeignetes zusätzliches Attribut (etwa eine Spalte mit eindeutigen Integer-Werten) einzuführen. In der Regel ist die Verwendung eines zusätzlichen Attributes die bessere Alternative, da dies die Änderung aller Attribute eines Objektes erlaubt, die in dessen Klasse definiert sind. Ein Attribut der Klasse, das als Schlüssel definiert ist, kann hingegen nicht geändert werden. Bei Klassenhierarchien ist zu berücksichtigen, daß alle Klassen der Hierarchie dieselben Attribute für ihre OID benutzen sollten und jede OID innerhalb der Klassenhierarchie eindeutig vergeben sein sollte. 20 KAPITEL 3

Inhaltsverzeichnis Vorwort zur vierten Auflage Vorwort zur dritten Auflage Vorwort zur zweiten Auflage Vorwort zur ersten Auflage Hinweise zur CD

Inhaltsverzeichnis Vorwort zur vierten Auflage Vorwort zur dritten Auflage Vorwort zur zweiten Auflage Vorwort zur ersten Auflage Hinweise zur CD Vorwort zur vierten Auflage 11 Vorwort zur dritten Auflage 13 Vorwort zur zweiten Auflage 15 Vorwort zur ersten Auflage 17 Hinweise zur CD 19 1 Datenbanken und Datenbanksysteme 21 1.1 Zentralisierung der

Mehr

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich WS 02/03 Warum muss ein Objekt wissen, zu welcher Klasse es gehört? Damit die Klassenzugehörigkeit

Mehr

10. Datenbank Design 1

10. Datenbank Design 1 1 Die Hauptaufgabe einer Datenbank besteht darin, Daten so lange zu speichern bis diese explizit überschrieben oder gelöscht werden. Also auch über das Ende (ev. sogar der Lebenszeit) einer Applikation

Mehr

Einführung in die Programmierung

Einführung in die Programmierung Skript zur Vorlesung: Einführung in die Programmierung WiSe 2009 / 2010 Skript 2009 Christian Böhm, Peer Kröger, Arthur Zimek Prof. Dr. Christian Böhm Annahita Oswald Bianca Wackersreuther Ludwig-Maximilians-Universität

Mehr

Vgl. Oestereich Kap 2.4 Seiten

Vgl. Oestereich Kap 2.4 Seiten Vgl. Oestereich Kap 2.4 Seiten 99-110 1 Vgl. Oestereich Kap 2.41 Seiten 99ff 2 Wie das Klassendiagramm ist auch das Objektdiagramm ebenfalls ein Strukturdiagramm. Da die Anzahl der Attribute sehr groß

Mehr

Datenbanken Unit 4: Das Relationale Modell & Datenintegrität

Datenbanken Unit 4: Das Relationale Modell & Datenintegrität Datenbanken Unit 4: Das Relationale Modell & Datenintegrität 15. III. 2016 Outline 1 Organisatorisches 2 SQL 3 Relationale Algebra Notation 4 Datenintegrität Organisatorisches Erster Zwischentest: nach

Mehr

Analyse und Modellierung von Informationssystemen

Analyse und Modellierung von Informationssystemen Analyse und Modellierung von Informationssystemen Dr. Klaus Höppner Hochschule Darmstadt Sommersemester 2013 1 / 18 UML Einführung Klassendiagramme in der UML Relationen zwischen Klassen 2 / 18 UML: Grundsätzliches

Mehr

Grundlagen von Datenbanken

Grundlagen von Datenbanken Agenda: Grundlagen von Datenbanken SS 2010 3. Relationale Algebra Prof. Dr. Stefan Böttcher Universität Paderborn mit Material von Prof. Dr. Gregor Engels Grundlagen von Datenbanken - SS 2010 - Prof. Dr.

Mehr

Abstraktionsschichten. Das Relationale Datenmodell

Abstraktionsschichten. Das Relationale Datenmodell Abstraktionsschichten. Das Relationale Datenmodell Verschiedene Abstraktionsebene Data in Beziehung zur Application Data in Beziehung zur Datenmodell Data in Beziehung zur physischen Darstellung Datenunabhängigkeit

Mehr

Konzeptueller Entwurf

Konzeptueller Entwurf Konzeptueller Entwurf UML Klassendiagrame UML Assoziationen Entspricht Beziehungen Optional: Assoziationsnamen Leserichtung ( oder ), sonst bidirektional Rollennamen Kardinalitätsrestriktionen UML Kardinalitätsrestriktionen

Mehr

Jason T. Roff UML. IT Tutorial. Übersetzung aus dem Amerikanischen von Reinhard Engel

Jason T. Roff UML. IT Tutorial. Übersetzung aus dem Amerikanischen von Reinhard Engel Jason T. Roff UML IT Tutorial Übersetzung aus dem Amerikanischen von Reinhard Engel Inhaltsverzeichnis Inhaltsverzeichnis Einführung 11 Grundlagen der UML 15 Warum wir Software modellieren 16 Analyse,

Mehr

Inhalt. Unland, Rainer Datenbanken im Einsatz digitalisiert durch: IDS Basel Bern

Inhalt. Unland, Rainer Datenbanken im Einsatz digitalisiert durch: IDS Basel Bern Inhalt 1 Einleitung und Übersicht 1 1.1 Anforderungserhebung und -analyse 6 1.2 Konzeptuelle Modellbildung 7 1.3 Logischer Entwurf 9 1.4 Implementationsphase 9 1.5 Allgemeine Datenbankbegriffe 10 1.6 Zusammenfassung

Mehr

7. Datenbankdefinitionssprachen

7. Datenbankdefinitionssprachen 7. Datenbankdefinitionssprachen SQL-DDL Teil der Standardsprache für relationale Datenbanksysteme: SQL ODL (Object Definition Language) für objektorientierte Datenbanksysteme nach dem ODMG-Standard VL

Mehr

SQL. SQL: Structured Query Language. Früherer Name: SEQUEL. Standardisierte Anfragesprache für relationale DBMS: SQL-89, SQL-92, SQL-99

SQL. SQL: Structured Query Language. Früherer Name: SEQUEL. Standardisierte Anfragesprache für relationale DBMS: SQL-89, SQL-92, SQL-99 SQL Früherer Name: SEQUEL SQL: Structured Query Language Standardisierte Anfragesprache für relationale DBMS: SQL-89, SQL-92, SQL-99 SQL ist eine deklarative Anfragesprache Teile von SQL Vier große Teile:

Mehr

Kapitel DB:IV (Fortsetzung)

Kapitel DB:IV (Fortsetzung) Kapitel DB:IV (Fortsetzung) IV. Logischer Datenbankentwurf mit dem relationalen Modell Das relationale Modell Integritätsbedingungen Umsetzung ER-Schema in relationales Schema DB:IV-45 Relational Design

Mehr

Datenbanken und SQL. Springer Vieweg. Eine praxisorientierte Einführung mit Anwendungen in Oracle, SQL Server und MySQL.

Datenbanken und SQL. Springer Vieweg. Eine praxisorientierte Einführung mit Anwendungen in Oracle, SQL Server und MySQL. Edwin Schicker Datenbanken und SQL Eine praxisorientierte Einführung mit Anwendungen in Oracle, SQL Server und MySQL 4., überarbeitete Auflage Springer Vieweg Inhaltsverzeichnis 1 Übersicht über Datenbanken

Mehr

Beispiel: Zwischen der Oberklasse und der abgeleiteten Klasse besteht eine ist ein Beziehung. Eine abgeleitete Klasse stellt eine Spezialisierung der

Beispiel: Zwischen der Oberklasse und der abgeleiteten Klasse besteht eine ist ein Beziehung. Eine abgeleitete Klasse stellt eine Spezialisierung der Vererbung Vererbung ist ein Konzept der objektorientierten Programmierung,, die es ermöglicht neue Klassen von bereits vorhandenen Klassen abzuleiten. In einer abgeleiteten Klasse (subclass) muss nur spezifiziert

Mehr

Rückblick: Datenbankentwurf

Rückblick: Datenbankentwurf Rückblick: Datenbankentwurf Entity-Relationship-Modell für konzeptuellen Entwurf Entitytypen (entity types) (z.b. Studenten) Beziehungstypen (relationships) (z.b. hören) Attribute beschreiben Gegenstände

Mehr

Präsentation Interfaces

Präsentation Interfaces Einführung in Java Präsentation Interfaces Nozar Delassaei Marvi Inhalt 1. Erinnerung Klasse Objekte Beispiel Klasse Abstrakte Klasse Beispiel Abstrakte Klasse Mehrfachvererbung-1 Mehrfachvererbung-2 2.

Mehr

Einführung in die Programmierung

Einführung in die Programmierung Skript zur Vorlesung: Einführung in die Programmierung WiSe 2009 / 2010 Skript 2009 Christian Böhm, Peer Kröger, Arthur Zimek Prof. Dr. Christian Böhm Annahita Oswald Bianca Wackersreuther Ludwig-Maximilians-Universität

Mehr

Kapitel 9: Klassen und höhere Datentypen. Klassen und höhere. Objekte, Felder, Methoden. Küchlin/Weber: Einführung in die Informatik

Kapitel 9: Klassen und höhere Datentypen. Klassen und höhere. Objekte, Felder, Methoden. Küchlin/Weber: Einführung in die Informatik Klassen und höhere Datentypen Objekte, Felder, Methoden Küchlin/Weber: Einführung in die Informatik Klassen Klasse (class) stellt einen (i.a. benutzerdefinierten) Verbund-Datentyp dar Objekte sind Instanzen

Mehr

Gregor Kuhlmann Friedrich Müllmerstadt. MySQL. Der Schlüssel zu Datenbanken-Design und -Programmierung. c 3 E. i- O Rowohlt Taschenbuch Verlag

Gregor Kuhlmann Friedrich Müllmerstadt. MySQL. Der Schlüssel zu Datenbanken-Design und -Programmierung. c 3 E. i- O Rowohlt Taschenbuch Verlag Gregor Kuhlmann Friedrich Müllmerstadt MySQL Der Schlüssel zu Datenbanken-Design und -Programmierung r?: X c 3 E i- O uu Rowohlt Taschenbuch Verlag Inhalt Editorial 11 Einleitung 12 1 Einführung in das

Mehr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr Raum: LF 230 Nächste Sitzung: 19./22. Januar 2004 Die Dokumentation zu DB2 steht online zur Verfügung. Eine lokale Installation der Dokumentation findet sich unter der Adresse http://salz.is.informatik.uni-duisburg.de/db2doc/de_de/index.htm.

Mehr

Universität Karlsruhe (TH)

Universität Karlsruhe (TH) Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Kapitel 2 Die Definitionsphase Prof. Walter F. Tichy Wo sind wir gerade? Planung Lastenheft (funktionales Modell) Definition (Analyse) Pflichtenheft

Mehr

4. Datenbanksprache SQL

4. Datenbanksprache SQL 4. Datenbanksprache SQL Standard-Sprache für das Arbeiten mit relationalen Datenbanken: Structured Query Language Datendefinition: Anlegen, Ändern und Löschen von Datenbankstrukturen Datenmanipulation:

Mehr

Die folgende Tabelle stellt die Grundbegriffe der objektorientierten und der relationalen Welt gegenüber:

Die folgende Tabelle stellt die Grundbegriffe der objektorientierten und der relationalen Welt gegenüber: 1.Einleitung: Bei der Arbeit mit objektorientierten Programmiersprachen stellt sich häufig die Frage wie Objekte persistiert werden können. Da vor allem relationale Datenbanken sich großer Beliebtheit

Mehr

Matthias Schubert. Datenbanken. Theorie, Entwurf und Programmierung relationaler Datenbanken. 2., überarbeitete Auflage. Teubner

Matthias Schubert. Datenbanken. Theorie, Entwurf und Programmierung relationaler Datenbanken. 2., überarbeitete Auflage. Teubner Matthias Schubert Datenbanken Theorie, Entwurf und Programmierung relationaler Datenbanken 2., überarbeitete Auflage m Teubner Inhalt Wichtiger Hinweis 12 Vorwort 13 Wer sollte dieses Buch lesen? 13 Noch

Mehr

Zusammenfassung. Offene Probleme

Zusammenfassung. Offene Probleme Einführung Das relationale Datenbank-Modell Die relationale Abfragesprache SQL Relationale Algebra Datenbank-Entwurf: Entity-Relationship-Modell (ERM) Abhängigkeiten und Normalisierung Vom ERM zum relationalen

Mehr

Informatik Fokussierte Informationsadaption am Beispiel. Astrid Lubinski Universität Rostock

Informatik Fokussierte Informationsadaption am Beispiel. Astrid Lubinski Universität Rostock Informatik 2002 Fokussierte Informationsadaption am Beispiel Astrid Lubinski lubinski@informatik.uni-rostock.de Inhalt Einleitung Fokusbestimmung Informationszuschnitt Fokussierter Informationszuschnitt

Mehr

Theorie zur Übung 8 Datenbanken

Theorie zur Übung 8 Datenbanken Theorie zur Übung 8 Datenbanken Relationale Datenbanksysteme Ein relationales Datenbanksystem (RDBS) liegt vor, wenn dem DBS ein relationales Datenmodell zugrunde liegt. RDBS speichern Daten in Tabellenform:

Mehr

Enterprise JavaBeans Überblick

Enterprise JavaBeans Überblick Enterprise JavaBeans Überblick 1. Überblick Java EE 5 und Komponententechnologien 3. Enterprise JavaBeans Architektur 4. Ressourcen Management und Primäre Services 5. Java Persistence: Entity Manager 6.

Mehr

Das Relationale Modell

Das Relationale Modell Kapitel 3 Das Relationale Modell 1 / 50 Generelle Anmerkungen Wurde in den Siebzigern von E.F.Codd entwickelt (er bekam den Turing Award dafür) Im Moment das am weitesten verbreitete Datenmodell Hat die

Mehr

Datenbanksysteme Kapitel 5: SQL Data Manipulation Language

Datenbanksysteme Kapitel 5: SQL Data Manipulation Language Datenbanksysteme Kapitel 5: SQL Data Manipulation Language Prof. Dr. Peter Chamoni Mercator School of Management Lehrstuhl für Wirtschaftsinformatik, insb. Business Intelligence Prof. Dr. Peter Chamoni

Mehr

Einführung in die linearen Funktionen. Autor: Benedikt Menne

Einführung in die linearen Funktionen. Autor: Benedikt Menne Einführung in die linearen Funktionen Autor: Benedikt Menne Inhaltsverzeichnis Vorwort... 3 Allgemeine Definition... 3 3 Bestimmung der Steigung einer linearen Funktion... 4 3. Bestimmung der Steigung

Mehr

Kapitel 7: Referentielle Integrität

Kapitel 7: Referentielle Integrität Kapitel 7: Referentielle Integrität Im Allgemeinen sind nur solche Instanzen einer Datenbank erlaubt, deren Relationen die der Datenbank bekannten Integritätsbedingungen (IB) erfüllen. Integritätsbedingungen

Mehr

Grundlagen von Datenbanken SS 2010

Grundlagen von Datenbanken SS 2010 Grundlagen von Datenbanken SS 2010 2. Formalisierung des relationalen Datenmodells Agenda: Prof. Dr. Stefan Böttcher Universität Paderborn mit Material von Prof. Dr. Gregor Engels Das Relationenmodell

Mehr

NULL-WERTE IN GEOMEDIA- SACHDATEN TIPPS & TRICKS

NULL-WERTE IN GEOMEDIA- SACHDATEN TIPPS & TRICKS NULL-WERTE IN GEOMEDIA- SACHDATEN TIPPS & TRICKS 22.02.2016 INHALT NULL-Werte in GeoMedia-Sachdaten... 3 Grundlage... 3 Die Beispiel-Daten... 3 NULL-Werte sind grundsätzlich sinnvoll... 4 Fallbeispiele...

Mehr

DBMS für spezielle Anwendungen XML als Mittel der Datenbank-Interoperabilität

DBMS für spezielle Anwendungen XML als Mittel der Datenbank-Interoperabilität DBMS für spezielle Anwendungen XML als Mittel der Datenbank-Interoperabilität Seminarvortrag von D. Zimmermann 26-Februar-2004 Gliederung Datenbanken und Interoperabilität Begriffe Bedarf Ansätze XML als

Mehr

MCSA: SQL 2016 Database Development

MCSA: SQL 2016 Database Development MCSA: SQL 2016 Database Development Querying Data with Transact-SQL & Developing SQL Databases Seminarziel In diesem 6-tägigen Kurs werden die Teilnehmer von Grund auf in die Entwicklung

Mehr

Vorwort 11. Eine neue Datenbank erstellen 79;

Vorwort 11. Eine neue Datenbank erstellen 79; Vorwort 11 Der SQL Server 2012 stellt sich vor 15] 1.1 SQL Server - wer ist das? 15 1.1.1 Der SQL Server im Konzert der Datenbanksysteme 16 1.1.2 Entscheidungsszenarien für Datenbanksysteme 17 1.1.3 Komponenten

Mehr

Algorithmen und Programmierung II

Algorithmen und Programmierung II Algorithmen und Programmierung II Vererbung Prof. Dr. Margarita Esponda SS 2012 1 Imperative Grundbestandteile Parameterübergabe String-Klasse Array-Klasse Konzepte objektorientierter Programmierung Vererbung

Mehr

Entwurf und Verarbeitung relationaler Datenbanken

Entwurf und Verarbeitung relationaler Datenbanken Entwurf und Verarbeitung relationaler Datenbanken Eine durchgängige und praxisorientierte Vorgehens weise von Prof. Dr. Nikolai Preiß Berufsakademie Stuttgart R. Oldenbourg Verlag München Wien Inhalt Abbildungsverzeichnis

Mehr

Vorlesung Datenbanken I Endklausur

Vorlesung Datenbanken I Endklausur Prof. Dr. Stefan Brass 6. Februar 2004 Institut für Informatik MLU Halle-Wittenberg Vorlesung Datenbanken I Endklausur Name: Matrikelnummer: Studiengang: Aufgabe Punkte Max. Punkte Zeit 1 (SQL) 9 30 min

Mehr

Dynamisches Huffman-Verfahren

Dynamisches Huffman-Verfahren Dynamisches Huffman-Verfahren - Adaptive Huffman Coding - von Michael Brückner 1. Einleitung 2. Der Huffman-Algorithmus 3. Übergang zu einem dynamischen Verfahren 4. Der FGK-Algorithmus 5. Überblick über

Mehr

Probeklausur Datenbanktechnologie

Probeklausur Datenbanktechnologie Probeklausur Datenbanktechnologie Prof. Dr. Ingo Claßen Name: Vorname: MatrNr: Bewertung 1 25 2 15 3 10 4 10 Übung 40 Σ = 100 Punkte Punkte: Note: Notenspiegel 100 95 1,0 94 90 1,3 89 85 1,7 84 80 2,0

Mehr

UML Eine kurze Einführung

UML Eine kurze Einführung UML Eine kurze Einführung Programmiermethodik Eva Zangerle Universität Innsbruck Modell und Diagramm Ein Modell stellt Abstraktion eines Realitätsausschnitts dar. Um Informationen verständlicher darzustellen

Mehr

Datenbanksysteme I Aufgabenblatt 4: SQL

Datenbanksysteme I Aufgabenblatt 4: SQL Hinweise: Datenbanksysteme I Aufgabenblatt 4: SQL Abgabetermin: Montag, 08.01.07, 13:30 (vor der Vorlesung) Format: Auf Papier im Fach Datenbanksysteme I im Foyer oder per E-Mail an dbs1@hpi.uni-potsdam.de

Mehr

4.5 Anfragen mit Mengenoperatoren

4.5 Anfragen mit Mengenoperatoren 4. Der SQL-Standard 4.5. Anfragen mit Mengenoperatoren 4.5 Anfragen mit Mengenoperatoren UNION,INTERSECT und. Die beteiligten Tabellen müssen zueinander kompatible Spaltentypen haben. Die Resultatspalte

Mehr

Java Vererbung. Inhalt

Java Vererbung. Inhalt Java Vererbung Inhalt 1 Zielsetzung... 2 1.1 Bewertung... 2 2 Grundlagen der Vererbung... 2 2.1 Super und Subklassen... 2 3 Überladen von Methoden... 4 3.1 Unterschiedliche Parameter... 4 3.2 Gleiche Parameter

Mehr

Entwicklung eines E-Learning Topic-Map Rahmenwerks

Entwicklung eines E-Learning Topic-Map Rahmenwerks Institut für Betriebssysteme und Rechnerverbund der TU Braunschweig Verteilte Systeme, Prof. Dr. Fischer Entwicklung eines Topic-Map Rahmenwerks Betreuer: Martin Gutbrod Bearbeitet von: Yichen Yu Gliederung

Mehr

Dieser Foliensatz darf frei verwendet werden unter der Bedingung, dass diese Titelfolie nicht entfernt wird.

Dieser Foliensatz darf frei verwendet werden unter der Bedingung, dass diese Titelfolie nicht entfernt wird. Thomas Studer Relationale Datenbanken: Von den theoretischen Grundlagen zu Anwendungen mit PostgreSQL Springer, 2016 ISBN 978-3-662-46570-7 Dieser Foliensatz darf frei verwendet werden unter der Bedingung,

Mehr

Teil II Relationale Datenbanken Daten als Tabellen

Teil II Relationale Datenbanken Daten als Tabellen Teil II Relationale Datenbanken Daten als Tabellen Relationale Datenbanken Daten als Tabellen 1 Relationen für tabellarische Daten 2 SQL-Datendefinition 3 Grundoperationen: Die Relationenalgebra 4 SQL

Mehr

Die SQL-Schnittstelle

Die SQL-Schnittstelle Die SQL-Schnittstelle Merlin 16 Version 16.0 vom 09.10.2012 Inhalt Die SQL-Export-Schnittstelle... 4 Der Menüpunkt Abfrage durchführen... 4 Beschreibung Fenster Abfrage durchführen... 4 Schaltflächen Fenster

Mehr

Wie kann man die Korrektheit reaktiver Systeme gewährleisten?

Wie kann man die Korrektheit reaktiver Systeme gewährleisten? Korrektheit durch modulare Konstruktion Wie kann man die Korrektheit reaktiver Systeme gewährleisten? Ansatz: Durch systematische Konstruktion (Schlagwort: strukturierte Programmierung für parallele Programmiersprachen)

Mehr

TEIL I: OBJEKTORIENTIERUNG UND GRUNDKURS JAVA GRUNDLAGEN DER PROGRAMMIERUNG... 4

TEIL I: OBJEKTORIENTIERUNG UND GRUNDKURS JAVA GRUNDLAGEN DER PROGRAMMIERUNG... 4 Inhaltsverzeichnis TEIL I: OBJEKTORIENTIERUNG UND GRUNDKURS JAVA... 1 1 GRUNDLAGEN DER PROGRAMMIERUNG... 4 1.1 Das erste Java-Programm... 4 1.2 Programme und ihre Abläufe... 6 1.3 Entwurf mit Nassi-Shneiderman-Diagrammen...

Mehr

Babeș-Bolyai Universität Cluj Napoca Fakultät für Mathematik und Informatik Grundlagen der Programmierung MLG5005. Design Richtlinien

Babeș-Bolyai Universität Cluj Napoca Fakultät für Mathematik und Informatik Grundlagen der Programmierung MLG5005. Design Richtlinien Babeș-Bolyai Universität Cluj Napoca Fakultät für Mathematik und Informatik Grundlagen der Programmierung MLG5005 Design Richtlinien UML GRASP Drei-Schichten-Architektur Entwurfsziel: die Trennung von

Mehr

Programmieren I. Kapitel 8. Vererbung

Programmieren I. Kapitel 8. Vererbung Programmieren I Kapitel 8. Vererbung Kapitel 8: Vererbung Ziel: Wesentliches objektorientiertes Konzept kennenlernen Subtypen Idee Probleme und Varianten Vererbung in Java dynamische Bindung abstrakte

Mehr

Die Menüleisten sollen fix sein und über den dargestellten Inhalt scrollen.

Die Menüleisten sollen fix sein und über den dargestellten Inhalt scrollen. 1. Allgemein Anforderungen 1.1. Geschäftsobjekte mit Icons Die Geschäftsobjekte sollen in der Darstellung (Navigation, Basket, Suchergebnisse) um Icons erweitert werden um ihren Type (Environment, Test,

Mehr

Anfragen & Transformation

Anfragen & Transformation Anfragen & Transformation mit XQuery XML Proseminar Le Huan Stefan Tran I 21.06.2010 Reales Beispiel Alle Weltmeister und ihre Finalgegner worldchampions.xml 2006 italy

Mehr

Telefonbuchdaten. Leitungsdaten Antennendaten Mitarbeiterdaten Immobiliendaten Telefon-Verbindungsdaten Internet-Verbindungsdaten

Telefonbuchdaten. Leitungsdaten Antennendaten Mitarbeiterdaten Immobiliendaten Telefon-Verbindungsdaten Internet-Verbindungsdaten Datenbanken? Datenbanken! Vertragsdaten Kundendaten Rechnungsdaten Telefonbuchdaten Marketingdaten Leitungsdaten Antennendaten Mitarbeiterdaten Immobiliendaten Telefon-Verbindungsdaten Internet-Verbindungsdaten

Mehr

Erweiterte Entity-Relationship- und UML-Modellierung. Copyright 2004 Shamkant Ramez Elmasri B. Navathe and Shamkant Navathe.

Erweiterte Entity-Relationship- und UML-Modellierung. Copyright 2004 Shamkant Ramez Elmasri B. Navathe and Shamkant Navathe. Erweiterte Entity-Relationship- und UML-Modellierung Copyright 2004 Shamkant Ramez Elmasri B. Navathe and Shamkant Navathe. CC 1 Erweitertes-ER (EER) Modellkonzept Beinhaltet alle Aspekte des Basis-ER-Modellkonzeptes

Mehr

Datenbank- und Informationssysteme - Übungsblatt 6 -

Datenbank- und Informationssysteme - Übungsblatt 6 - Datenbank- und Informationssysteme - Übungsblatt 6 - Prof. Dr. Klaus Küspert Dipl.-Inf. Andreas Göbel Friedrich-Schiller-Universität Jena Lehrstuhl für Datenbanken und Informationssysteme 0) Vorbereitung

Mehr

Entwicklung einer DB-Anwendung vergleichbar mit gewöhnlicher Anwendungsprogrammierung:

Entwicklung einer DB-Anwendung vergleichbar mit gewöhnlicher Anwendungsprogrammierung: Entwicklung einer DB-Anwendung vergleichbar mit gewöhnlicher Anwendungsprogrammierung: 1. Problemanalyse (Datenmodellierung, konzeptionelles Schema) 2. Lösungsentwurf (logisches Schema) 3. Implementierung

Mehr

Einführung Grundbegriffe

Einführung Grundbegriffe Einführung Grundbegriffe 1.1 Der Modellbegriff Broy: Informatik 1, Springer 1998 (2) Die Modellbildung der Informatik zielt auf die Darstellung der unter dem Gesichtspunkt einer gegebenen Aufgabenstellung

Mehr

(a) Wie unterscheiden sich synchrone und asynchrone Unterbrechungen? (b) In welchen drei Schritten wird auf Unterbrechungen reagiert?

(a) Wie unterscheiden sich synchrone und asynchrone Unterbrechungen? (b) In welchen drei Schritten wird auf Unterbrechungen reagiert? SoSe 2014 Konzepte und Methoden der Systemsoftware Universität Paderborn Fachgebiet Rechnernetze Präsenzübung 2 2014-04-28 bis 2014-05-02 Aufgabe 1: Unterbrechungen (a) Wie unterscheiden sich synchrone

Mehr

Ausarbeitung zum Modulabschluss. Graphentheorie. spannende Bäume, bewertete Graphen, optimale Bäume, Verbindungsprobleme

Ausarbeitung zum Modulabschluss. Graphentheorie. spannende Bäume, bewertete Graphen, optimale Bäume, Verbindungsprobleme Universität Hamburg Fachbereich Mathematik Seminar: Proseminar Graphentheorie Dozentin: Haibo Ruan Sommersemester 2011 Ausarbeitung zum Modulabschluss Graphentheorie spannende Bäume, bewertete Graphen,

Mehr

Arbeitsplan III. Schlüssel und Transformation. Name: Tenbusch Klasse: Datum: Blatt Nr.: 1 / 7 lfd. Nr.:

Arbeitsplan III. Schlüssel und Transformation. Name: Tenbusch Klasse: Datum: Blatt Nr.: 1 / 7 lfd. Nr.: Name: Tenbusch Klasse: Datum: Blatt Nr.: 1 / 7 lfd. Nr.: Inhaltsverzeichnis Aufgabe 1...2 Aufgabe 2...3 2-Schichten-Architektur...3 3- Schichten-Architektur...3 Zusammenhang...4 Aufgabe 4...4 Aufgabe 4.1,

Mehr

UML 2.0 als Architekturbeschreibungssprache? Seminar: Architekturbeschreibungssprachen Manuel Wickert

UML 2.0 als Architekturbeschreibungssprache? Seminar: Architekturbeschreibungssprachen Manuel Wickert UML 2.0 als Architekturbeschreibungssprache? Seminar: Architekturbeschreibungssprachen Manuel Wickert Motivation UML 2.0 nicht als ADL im Sinne von Taylor/Medvidovic entworfen. Warum UML als ADL? weit

Mehr

Informatik II Übung 6 Gruppe 7

Informatik II Übung 6 Gruppe 7 Informatik II Übung 6 Gruppe 7 Leyna Sadamori leyna.sadamori@inf.ethz.ch DEBRIEFING Übung 5 2 U5A1-4 Im Prinzip alles richtig. Falls am Ende noch Zeit, dann Einsicht in die Best Of s 3 THEORIE Java Vererbung,

Mehr

R-Wörterbuch Ein Anfang... ein Klick auf einen Begriff führt, sofern vorhanden, zu dessen Erklärung.

R-Wörterbuch Ein Anfang... ein Klick auf einen Begriff führt, sofern vorhanden, zu dessen Erklärung. R-Wörterbuch Ein Anfang... ein Klick auf einen Begriff führt, sofern vorhanden, zu dessen Erklärung. Carsten Szardenings c.sz@wwu.de 7. Mai 2015 A 2 B 3 C 4 D 5 F 6 R 16 S 17 V 18 W 19 Z 20 H 7 I 8 K 9

Mehr

Javakurs für Anfänger

Javakurs für Anfänger Javakurs für Anfänger Einheit 03: Wiederholung und Nutzereingaben Lorenz Schauer Lehrstuhl für Mobile und Verteilte Systeme Heutige Agenda 1. Teil: Wiederholung Klassen, Objekte, Attribute und Methoden

Mehr

Bei for-schleifen muss man nur immer bedenken, dass die letzte Anweisung immer erst nach der Ausführung der restlichen Anweisungen der Schleife

Bei for-schleifen muss man nur immer bedenken, dass die letzte Anweisung immer erst nach der Ausführung der restlichen Anweisungen der Schleife 303 Bei for-schleifen muss man nur immer bedenken, dass die letzte Anweisung immer erst nach der Ausführung der restlichen Anweisungen der Schleife durchgeführt wird. 304 305 for-schleifen sind in Aktivitätsdiagrammen

Mehr

VU Objektorientierte Modellierung Übung 1

VU Objektorientierte Modellierung Übung 1 VU Objektorientierte Modellierung Übung Übungsgruppen: 3..2008-7..2008 Aufgabe : Strukturmodellierung mittels Klassendiagramm Theoriefragen Wiederholen Sie das Kapitel aus der Vorlesung, das sich mit dem

Mehr

Grundlagen von MOF. Alexander Gepting 1

Grundlagen von MOF. Alexander Gepting 1 Grundlagen von MOF Alexander Gepting 1 Kurzfassung Meta-Object Facility (MOF) ist ein Standard der OMG der im Rahmen der Standardisierung von Modellierungstechniken für verteilte Architekturen und Softwaresysteme

Mehr

MySQL. MySQL ist ein Datenbanksystem. Es besteht aus einem zentralen Server und aus (mehreren) Clients. Es benutzt einen Dialekt der Sprache SQL.

MySQL. MySQL ist ein Datenbanksystem. Es besteht aus einem zentralen Server und aus (mehreren) Clients. Es benutzt einen Dialekt der Sprache SQL. MySQL Was bieten Datenbanken? Zentralisation von Daten Maschinenunterstützte Weiterverarbeitung Daten werden vielen Benutzern gleichzeitig zur Verfügung gestellt Ausschalten von konkurrierenden Zugriffen

Mehr

Grundlagen der Informatik III ERM-Modell Thema: Grundlagen der Datenbanken

Grundlagen der Informatik III ERM-Modell Thema: Grundlagen der Datenbanken Hochschule Harz FB Automatisierung und Informatik Versuch: Grundlagen der Informatik III ERM-Modell Thema: Grundlagen der Datenbanken Versuchsziele Vertiefung in der ERM-Modellierung. Benutzen eines Designers.

Mehr

Zugriff auf Matrizen. Anhängen von Elementen. Punktweise Operatoren. Vektoren und Matrizen in MATLAB II

Zugriff auf Matrizen. Anhängen von Elementen. Punktweise Operatoren. Vektoren und Matrizen in MATLAB II Zugriff auf Matrizen. Anhängen von Elementen. Punktweise Operatoren. Vektoren und Matrizen in MATLAB II Matrixzugriff Wir wollen nun unsere Einführung in die Arbeit mit Vektoren und Matrizen in MATLAB

Mehr

Stufen der Entwicklung einer Datenbank. ER-Modell. Datenbank-Entwurf (1) Datenbank-Entwurf (2) 1. Datenbank - Entwurf ( ER - Diagramm)

Stufen der Entwicklung einer Datenbank. ER-Modell. Datenbank-Entwurf (1) Datenbank-Entwurf (2) 1. Datenbank - Entwurf ( ER - Diagramm) 9. Einführung in das Entity-Relationship-Modell 9-1 9. Einführung in das Entity-Relationship-Modell 9-2 ER-Modell Stufen der Entwicklung einer Datenbank 1. Überblick über den Datenbank-Entwurf 2. Grundlegende

Mehr

Lösungsvorschlag zu 1. Übung

Lösungsvorschlag zu 1. Übung Prof. Frederik Armknecht Sascha Müller Daniel Mäurer Grundlagen der Informatik 3 Wintersemester 09/10 Lösungsvorschlag zu 1. Übung 1 Präsenzübungen 1.1 Schnelltest a) Welche der Aussagen treffen auf jeden

Mehr

Assoziation und Aggregation

Assoziation und Aggregation Assoziation und Aggregation Prof. Dr. Christian Böhm in Zusammenarbeit mit Michael Eckert und Gefei Zhang http://www.dbs.ifi.lmu.de/lehre/nfinfows WS 07/08 2 Ziele Verstehen der Begriffe Assoziation und

Mehr

Grundlagen der Informatik für Ingenieure I

Grundlagen der Informatik für Ingenieure I 18. Programmieren und Programmiersprachen 18.2 Java vs. C++.1 18 Programmieren und Programmiersprachen 18 Programmieren und Programmiersprachen Sicher werden Sie oft in Ihrem Leben danach gefragt werden,

Mehr

XML und Datenmodellierung

XML und Datenmodellierung Rainer Eckstein Silke Eckstein XML und Datenmodellierung XML-Schema und RDF zur Modellierung von Daten und Metadaten einsetzen dpunkt.verlag VII Inhaltsverzeichnis Vorwort v 1 Einleitung 1 1.1 Aufbau 2

Mehr

Wie definieren wir das Relationen-

Wie definieren wir das Relationen- Wie definieren wir das Relationen- schema für eine Datenbank? Professoren PersNr Name Rang Raum 2125 Sokrates C4 226 2126 Russel C4 232 2127 Kopernikus C3 310 2133 Popper C3 52 2134 Augustinus C3 309 2136

Mehr

Programmieren in Java

Programmieren in Java Programmieren in Java Einführung in die objektorientierte Programmierung Teil 2 2 Übersicht der heutigen Inhalte Vererbung Abstrakte Klassen Erweitern von Klassen Überladen von Methoden Überschreiben von

Mehr

Oracle Fusion Middleware Überwachung mit Oracle BAM

Oracle Fusion Middleware Überwachung mit Oracle BAM Oracle Fusion Middleware Überwachung mit Oracle BAM Schlüsselworte Monitoring, BAM, Fusion Middleware Einleitung Markus Lohn esentri AG Ettlingen Oracle BAM wird vor allem für das fachliche Überwachen

Mehr

Grundlagen zur Verwendung von Datenbankmanagementsystemen

Grundlagen zur Verwendung von Datenbankmanagementsystemen Grundlagen zur Verwendung von Datenbankmanagementsystemen Vorlesung im Wintersemester 2007/08 (Abschnitt Datenmodelle) Prof. Dr. Andreas Schmietendorf 1 Übersicht Datenmodelle Prof. Dr. Andreas Schmietendorf

Mehr

Funktionale Programmiersprachen

Funktionale Programmiersprachen Funktionale Programmiersprachen An den Beispielen Haskell und Erlang Übersicht Programmiersprachen λ-kalkül Syntax, Definitionen Besonderheiten von funktionalen Programmiersprache, bzw. Haskell Objektorientierte

Mehr

Beziehungen zwischen Objekten

Beziehungen zwischen Objekten 1/19 Beziehungen zwischen Objekten Florian Adamsky, B. Sc. (PhD cand.) florian.adamsky@iem.thm.de http://florian.adamsky.it/ cbd Softwareentwicklung im WS 2014/15 2/19 Outline 1 Vererbung (Wiederholung)

Mehr

Hochschule Augsburg, Fakultät für Informatik Name:... Prüfung "Programmieren 1", IN1bac, WS 10/11 Seite 1 von 6

Hochschule Augsburg, Fakultät für Informatik Name:... Prüfung Programmieren 1, IN1bac, WS 10/11 Seite 1 von 6 Prüfung "Programmieren 1", IN1bac, WS 10/11 Seite 1 von 6 Datum, Uhrzeit: 24. 01. 2011, 10.30 Uhr Semester: IN1 Note:... Prüfer: Prof. Meixner Dauer: 60 Min. Hilfsmittel: keine Punkte:... Diese Prüfung

Mehr

Musterlösung zur Finalklausur Datenbanksysteme am

Musterlösung zur Finalklausur Datenbanksysteme am Musterlösung zur Finalklausur Datenbanksysteme am 5.2.2003 Aufgabe 1 a) Anfragen: (20 Punkte) i.suchen Sie die Stücke (Titel), die Komponist Lennon erstellt hat und von der Musikfirma EMI veröffentlicht

Mehr

Muster in der Software Technik. Grundlegende Konzepte der Software Entwicklung und Objekt Orientierung

Muster in der Software Technik. Grundlegende Konzepte der Software Entwicklung und Objekt Orientierung Muster in der Software Technik Grundlegende Konzepte der Software Entwicklung und Objekt Orientierung Grundlagen für die weitere Vorlesung: Aktivitäten und Prozesse der Software Entwicklung Objektorientierte

Mehr

Beuth Hochschule Zahlensysteme SS16, S. 1

Beuth Hochschule Zahlensysteme SS16, S. 1 Beuth Hochschule Zahlensysteme SS16, S. 1 Zahlensysteme Eine natürliche Zahl (wie z.b. drei oder siebzehn etc.) kann man auf verschiedene Weisen darstellen, etwa als römische Zahl (z.b. XVII) oder durch

Mehr

Michael Seemann. Native XML-Datenbanken im Praxiseinsatz

Michael Seemann. Native XML-Datenbanken im Praxiseinsatz Michael Seemann Native XML-Datenbanken im Praxiseinsatz Software & Support Verlag GmbH Frankfurt 2003 Inhaltsverzeichnis VORWORT 13 1 XML IN DATENBANKEN 15 1.1 DATEN ODER DOKUMENTE 15 1.2 SEMISTRUKTURIERTE

Mehr

Logischer Entwurf von Datenbanken

Logischer Entwurf von Datenbanken Logischer Entwurf von Datenbanken Relationales Datenbankschema Wintersemester 16/17 DBIS 1 Typischer Datenbankentwurf Anforderungsanalyse und -spezifikation Miniwelt Konzeptioneller Entwurf E/R-Diagramm

Mehr

Blöcke Strukturelemente. Dr. Beatrice Amrhein

Blöcke Strukturelemente. Dr. Beatrice Amrhein Blöcke Strukturelemente Block Definitionsdiagramm Dr. Beatrice Amrhein Definition Ein Block Definitionsdiagramm (oder Blockdiagramm) o zeigt die statische Struktur des Systems, o beschreibt, welche Systembausteine

Mehr

Kombinatorik von Zahlenfolgen

Kombinatorik von Zahlenfolgen 6. April 2006 Vorlesung in der Orientierungswoche 1 Kombinatorik von Zahlenfolgen Einige Beispiele Jeder kennt die Fragen aus Intelligenztests, in denen man Zahlenfolgen fortsetzen soll. Zum Beispiel könnten

Mehr

Datenbanksysteme I, SS 2004

Datenbanksysteme I, SS 2004 Universität Mannheim Lehrstuhl für Praktische Informatik III Norman May D7 27, Raum 410 68131 Mannheim Telefon: (0621) 181-2586 Email: norman@pi3.informatik.uni-mannheim.de Datenbanksysteme I, SS 2004

Mehr

Elementare Beweismethoden

Elementare Beweismethoden Elementare Beweismethoden Christian Hensel 404015 Inhaltsverzeichnis Vortrag zum Thema Elementare Beweismethoden im Rahmen des Proseminars Mathematisches Problemlösen 1 Einführung und wichtige Begriffe

Mehr

OOAD in UML. Seminar Software-Entwurf B. Sc. Sascha Tönnies

OOAD in UML. Seminar Software-Entwurf B. Sc. Sascha Tönnies OOAD in UML Seminar Software-Entwurf B. Sc. Sascha Tönnies Agenda 1. Einordnung des Themas im Seminar 2. UML kompakt 3. UML detailliert 4. Werkzeugunterstützung 2 Einordnung des Themas UML Hilfsmittel

Mehr

Übungspaket 23 Mehrdimensionale Arrays

Übungspaket 23 Mehrdimensionale Arrays Übungspaket 23 Mehrdimensionale Arrays Übungsziele: Skript: Deklaration und Verwendung mehrdimensionaler Arrays Kapitel: 49 Semester: Wintersemester 2016/17 Betreuer: Kevin, Matthias, Thomas und Ralf Synopsis:

Mehr