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

9. Einführung in Datenbanken

9. Einführung in Datenbanken 9. Einführung in Datenbanken 9.1 Motivation und einführendes Beispiel 9.2 Modellierungskonzepte der realen Welt 9.3 Anfragesprachen (Query Languages) 9.1 Motivation und einführendes Beispiel Datenbanken

Mehr

Unified Modeling Language (UML)

Unified Modeling Language (UML) Kirsten Berkenkötter Was ist ein Modell? Warum Modellieren? Warum UML? Viele, viele Diagramme UML am Beispiel Was ist ein Modell? Ein Modell: ist eine abstrakte Repräsentation eines Systems, bzw. ist eine

Mehr

Views in SQL. 2 Anlegen und Verwenden von Views 2

Views in SQL. 2 Anlegen und Verwenden von Views 2 Views in SQL Holger Jakobs bibjah@bg.bib.de, holger@jakobs.com 2010-07-15 Inhaltsverzeichnis 1 Wozu dienen Views? 1 2 Anlegen und Verwenden von Views 2 3 Schreibfähigkeit von Views 3 3.1 Views schreibfähig

Mehr

Datenbankentwurf. 4.2 Logischer Entwurf. Kapitel 4. ER-Modell. Umsetzung. Entwurfsdokumentation. relationales Modell. Verbesserung

Datenbankentwurf. 4.2 Logischer Entwurf. Kapitel 4. ER-Modell. Umsetzung. Entwurfsdokumentation. relationales Modell. Verbesserung 4.2 Logischer Entwurf Datenbankentwurf 4.2 Logischer Entwurf 2002 Prof. Dr. Rainer Manthey Informationssysteme Logischer Entwurf: Einordnung Entwurfsdokumentation logische Strukturen "auf dem Papier" konzeptueller

Mehr

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung

Mehr

Einleitung Projektion Selektion Join Mengenop. Vollst.keit. Einleitung Projektion. Selektion Join. Vollst.keit. Einleitung Projektion Selektion Join

Einleitung Projektion Selektion Join Mengenop. Vollst.keit. Einleitung Projektion. Selektion Join. Vollst.keit. Einleitung Projektion Selektion Join Parsen der Anfrage (SQL) Transformation in eine Standardform (Relationenalgebra) Logische Optimierung Transformation in alternative Zugriffspläne, Physische Optimierung Ausführung des gewählten Zugriffsplans

Mehr

Innovator 11 excellence. DDL importieren. Data-Definition-Language-Dateien in Datenbankschema importieren. HowTo. www.mid.de

Innovator 11 excellence. DDL importieren. Data-Definition-Language-Dateien in Datenbankschema importieren. HowTo. www.mid.de Innovator 11 excellence DDL importieren Data-Definition-Language-Dateien in Datenbankschema importieren HowTo www.mid.de Zweck In Innovator Data excellence können Sie mit dem DDL-Import Ihr physisches

Mehr

Vorlesung Informatik II

Vorlesung Informatik II Vorlesung Informatik II Universität Augsburg Wintersemester 2011/2012 Prof. Dr. Bernhard Bauer Folien von: Prof. Dr. Robert Lorenz Lehrprofessur für Informatik 08. Exkurs: Datenbanken 1 Motivation Datenbanksysteme

Mehr

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2 EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0 EDV Kurs 13/2 Inhaltsverzeichnis 1 Objekte... 1 2 Klassen... 3 2.1 Beziehungen zwischen Klassen... 4 2.1.1 Vererbung... 4 2.1.2

Mehr

Kapitel DB:II. II. Datenbankentwurf und Datenbankmodelle. Entwurfsprozess Datenbankmodelle

Kapitel DB:II. II. Datenbankentwurf und Datenbankmodelle. Entwurfsprozess Datenbankmodelle Kapitel DB:II II. Datenbankentwurf und Datenbankmodelle Entwurfsprozess Datenbankmodelle DB:II-1 DB Design and Models STEIN 2004-2015 Entwurfsprozess ANSI/SPARC-Schema-Architektur externe Ebene externes

Mehr

Curriculum des Wahlfaches Informatik für das Gymnasium Dialog

Curriculum des Wahlfaches Informatik für das Gymnasium Dialog 10.Klasse: Themenschwerpunkt I: Datenbanken Datenbanken o Einsatzbereiche von Datenbanken o Verwaltung von großen Datenmengen o Probleme aus dem Alltag in Datenbanken abbilden o Relationale Datenbanksysteme

Mehr

Raumbezogene Datenbanken (Spatial Databases)

Raumbezogene Datenbanken (Spatial Databases) Raumbezogene Datenbanken (Spatial Databases) Ein Vortrag von Dominik Trinter Alexander Christian 1 Inhalte Was ist ein raumbezogenes DBMS? Modellierung Abfragen Werkzeuge zur Implementierung Systemarchitektur

Mehr

4 Grundlagen der Datenbankentwicklung

4 Grundlagen der Datenbankentwicklung 4 Grundlagen der Datenbankentwicklung In diesem Kapitel werden wir die Grundlagen der Konzeption von relationalen Datenbanken beschreiben. Dazu werden Sie die einzelnen Entwicklungsschritte von der Problemanalyse

Mehr

Relationales Modell: SQL-DDL. SQL als Definitionssprache. 7. Datenbankdefinitionssprachen. Anforderungen an eine relationale DDL

Relationales Modell: SQL-DDL. SQL als Definitionssprache. 7. Datenbankdefinitionssprachen. Anforderungen an eine relationale DDL Relationales Modell: SQLDDL SQL als Definitionssprache SQLDDL umfaßt alle Klauseln von SQL, die mit Definition von Typen Wertebereichen Relationenschemata Integritätsbedingungen zu tun haben Externe Ebene

Mehr

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 Kapitel 33 Der xml-datentyp In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 995 996 Kapitel 33: Der xml-datentyp Eine der wichtigsten

Mehr

Objektrelationale und erweiterbare Datenbanksysteme

Objektrelationale und erweiterbare Datenbanksysteme Objektrelationale und erweiterbare Datenbanksysteme Erweiterbarkeit SQL:1999 (Objekt-relationale Modellierung) In der Vorlesung werden nur die Folien 1-12 behandelt. Kapitel 14 1 Konzepte objekt-relationaler

Mehr

Kapitel 3: Datenbanksysteme

Kapitel 3: Datenbanksysteme LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS Skript zur Vorlesung: Einführung in die Informatik: Systeme und Anwendungen Sommersemester 2015 Kapitel 3: Datenbanksysteme Vorlesung:

Mehr

Grundlagen von Datenbanksystemen

Grundlagen von Datenbanksystemen Ramez Elmasri Shamkant B. Navathe Grundlagen von Datenbanksystemen 3., überarbeitete Auflage ein Imprint der Pearson Education Deutschland GmbH Inhaltsverzeichnis Vorwort 9 Über die Autoren 13 Teil 1 Grundkonzepte

Mehr

Einteilung von Datenbanken

Einteilung von Datenbanken Datenbanksysteme (c) A.Kaiser; WU-Wien 1 Einteilung von Datenbanken 1. formatierte Datenbanken 2. unformatierte Datenbanken Information Retrieval Systeme 2 Wozu Datenbanken? Speicherung und Verwaltung

Mehr

Die Grundbegriffe Die Daten Die Informationen

Die Grundbegriffe Die Daten Die Informationen Die Grundbegriffe Die Daten sind diejenigen Elemente, die vom Computer verarbeitet werden. Die Informationen sind Wissenselemente, welche durch die Analyse von Daten erhalten werden können. Die Daten haben

Mehr

6. Sichten, Integrität und Zugriffskontrolle. Vorlesung "Informa=onssysteme" Sommersemester 2015

6. Sichten, Integrität und Zugriffskontrolle. Vorlesung Informa=onssysteme Sommersemester 2015 6. Sichten, Integrität und Zugriffskontrolle Vorlesung "Informa=onssysteme" Sommersemester 2015 Überblick Sichten Integritätsbedingungen Zugriffsrechte SQL- Schema und SQL- Katalog Das Informa=onsschema

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung Kapitel 6 Vererbung Vererbung 1 Ziele Das Vererbungsprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen

Mehr

Software-Engineering und Datenbanken

Software-Engineering und Datenbanken Software-Engineering und Datenbanken Datenbankentwurf Prof. Dr. Bernhard Schiefer 5-1 Datenbankentwurf: Phasenmodell Anforderungsanalyse Konzeptioneller Entwurf Verteilungsentwurf Logischer Entwurf Datendefinition

Mehr

Knasmüller.book Seite vii Mittwoch, 28. März 2001 11:11 11. vii. Inhaltsverzeichnis

Knasmüller.book Seite vii Mittwoch, 28. März 2001 11:11 11. vii. Inhaltsverzeichnis Knasmüller.book Seite vii Mittwoch, 28. März 2001 11:11 11 vii 1 Einführung 1 1.1 Motivation.................................... 1 1.2 Vorteile der neuen Techniken...................... 3 1.3 Aufbau des

Mehr

Objektorientierter Entwurf (OOD) Übersicht

Objektorientierter Entwurf (OOD) Übersicht Übersicht Das Ziel des OO-Designs (OOD) ist es, die endgültige Architektur festzulegen durch Teil 1: Anbindung der Fachklassen an weitere Systeme: Benutzeroberfläche (mit MVC) Datenhaltung (Datenbank-Lösung

Mehr

Entwurf von Datenbanken

Entwurf von Datenbanken Bisher: was sind Datenbanken? Wie funktionieren sie? Im Folgenden: wie entwickle ich eine Datenbank? Was ist eine gute Datenbank? Der Datenbankentwurfsprozess Das Entity Relationship (ER) Modell Abbildung

Mehr

Andreas Heuer Gunter Saake Kai-Uwe Sattler. Datenbanken. kompakt

Andreas Heuer Gunter Saake Kai-Uwe Sattler. Datenbanken. kompakt Andreas Heuer Gunter Saake Kai-Uwe Sattler Datenbanken kompakt Inhaltsverzeichnis Vorwort v 1 Was sind Datenbanken 1 1.1 Warum Datenbanken 1 1.2 Datenbanksysteme 4 1.3 Anforderungen: Die Codd'schen Regeln

Mehr

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert Maika Büschenfeldt Datenbanken: Skript 1 1. Was ist eine relationale Datenbank? In Datenbanken können umfangreiche Datenbestände strukturiert abgelegt werden. Das Konzept relationaler Datenbanken soll

Mehr

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse?

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Ein Beispiel Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Dipl.-Kfm. Claus Häberle WS 2015 /16 # 42 XML (vereinfacht) visa

Mehr

Kapitel DB:III. III. Konzeptueller Datenbankentwurf

Kapitel DB:III. III. Konzeptueller Datenbankentwurf Kapitel DB:III III. Konzeptueller Datenbankentwurf Einführung in das Entity-Relationship-Modell ER-Konzepte und ihre Semantik Charakterisierung von Beziehungstypen Existenzabhängige Entity-Typen Abstraktionskonzepte

Mehr

Carl-Christian Kanne. Einführung in Datenbanken p.1/513

Carl-Christian Kanne. Einführung in Datenbanken p.1/513 Einführung in Datenbanken Carl-Christian Kanne Einführung in Datenbanken p.1/513 Kapitel 1 Einführung Einführung in Datenbanken p.2/513 Einführung Was ist ein Datenbanksystem (DBS)? Ein System zum Speichern

Mehr

Nachtrag: Farben. Farbblindheit. (Light und Bartlein 2004)

Nachtrag: Farben. Farbblindheit. (Light und Bartlein 2004) Nachtrag: Farben Farbblindheit (Light und Bartlein 2004) 1 Vorgeschlagene Farbskalen (Light and Bartlein 2004) Farbkodierung metrisch skalierter Daten Unterscheide: 1. Sequential Data (ohne Betonung der

Mehr

Programmieren in Java

Programmieren in Java FG TECHNISCHE INFORMATIK V JV A00 00 TH 0 Programmieren in Java Anhang A A. Modellierung von OOP-Programmen A.. Klassenkategorien A.2. Klassembeziehungen A.3. Klassendiagramm und Sequenzdiagramm der UML

Mehr

Redundanz: Dieselben Informationen werden doppelt gespeichert.

Redundanz: Dieselben Informationen werden doppelt gespeichert. Kapitel 1 Einführung 1.1 Definition Ein Datenbanksystem (auch Datenbankverwaltungssystem, abgekürzt DBMS = data base management system) ist ein computergestütztes System, bestehend aus einer Datenbasis

Mehr

Einführung. Kapitel 1 2 / 508

Einführung. Kapitel 1 2 / 508 Kapitel 1 Einführung 2 / 508 Einführung Was ist ein Datenbanksystem (DBS)? Ein System zum Speichern und Verwalten von Daten. Warum kein herkömmliches Dateisystem verwenden? Ausfallsicherheit und Skalierbarkeit

Mehr

Datenbanken: Architektur & Komponenten 3-Ebenen-Architektur

Datenbanken: Architektur & Komponenten 3-Ebenen-Architektur Datenbanken: Architektur & Komponenten 3-Ebenen-Architektur Moderne Datenbanksysteme sind nach der 3-Ebenen-Architektur gebaut: Anwendung 1 Web-Anwendung Anwendung 2 Java-Programm... Anwendung n Applikation

Mehr

ANALYTICS, RISK MANAGEMENT & FINANCE ARCHITECTURE. NoSQL Datenbanksysteme Übersicht, Abgrenzung & Charakteristik

ANALYTICS, RISK MANAGEMENT & FINANCE ARCHITECTURE. NoSQL Datenbanksysteme Übersicht, Abgrenzung & Charakteristik ARFA ANALYTICS, RISK MANAGEMENT & FINANCE ARCHITECTURE NoSQL Datenbanksysteme Übersicht, Abgrenzung & Charakteristik Ralf Leipner Domain Architect Analytics, Risk Management & Finance 33. Berner Architekten

Mehr

Vorwort zur 5. Auflage... 15 Über den Autor... 16

Vorwort zur 5. Auflage... 15 Über den Autor... 16 Vorwort zur 5. Auflage...................................... 15 Über den Autor............................................ 16 Teil I Grundlagen.............................................. 17 1 Einführung

Mehr

Relationales Datenbanksystem Oracle

Relationales Datenbanksystem Oracle Relationales Datenbanksystem Oracle 1 Relationales Modell Im relationalen Modell wird ein relationales Datenbankschema wie folgt beschrieben: RS = R 1 X 1 SC 1... R n X n SC n SC a a : i=1...n X i B Information

Mehr

Einführung. Informationssystem als Abbild der realen Welt

Einführung. Informationssystem als Abbild der realen Welt Was ist ein Datenbanksystem? Anwendungsgrundsätze Betrieb von Datenbanksystemen Entwicklung von Datenbanksystemen Seite 1 Informationssystem als Abbild der realen Welt Modellierung (Abstraktion) Sachverhalte

Mehr

Klassendiagramm. Kurzer Überblick über UML - Stand 2006. BlaBla

Klassendiagramm. Kurzer Überblick über UML - Stand 2006. BlaBla BlaBla Diese Kennzeichnungen sind nur Erläuterungen und nicht Bestandteil des Diagramms Quelle: P.Grässle, H.Baumann, P.Baumann, UML projektorientiert, Galileo Verlag, 2003 21 Primäre Begriffe Kapselung

Mehr

Terminologie. Kapitel 15 Verteilte Datenbanken. Verteiltes Datenbanksystem. Kommunikationsmedien

Terminologie. Kapitel 15 Verteilte Datenbanken. Verteiltes Datenbanksystem. Kommunikationsmedien Kapitel Verteilte Datenbanken Terminologie Motivation: geographisch verteilte Organisationsform einer Bank mit ihren Filialen Filialen sollen Daten lokaler Kunden bearbeiten können Zentrale soll Zugriff

Mehr

UML (Unified Modelling Language) von Christian Bartl

UML (Unified Modelling Language) von Christian Bartl UML (Unified Modelling Language) von Inhaltsverzeichnis Inhaltsverzeichnis... 2 1 UML Unified Modelling Language... 3 2 Diagrammtypen... 3 2.1 Aktivitätsdiagramm... 3 2.1.1 Notation... 4 2.1.2 Beispieldiagramm...

Mehr

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

Programmiersprache 2 (C++) Prof. Dr. Stefan Enderle NTA Isny

Programmiersprache 2 (C++) Prof. Dr. Stefan Enderle NTA Isny Programmiersprache 2 (C++) Prof. Dr. Stefan Enderle NTA Isny 3. UML Klassendiagramm Nachtrag 3.1 Einführung UML UML ist eine standardisierte Sprache zur Modellierung von Systemen. In UML werden graphische

Mehr

Aufgaben zur fachwissenschaftlichen Prüfung Modul 3 Daten erfassen, ordnen, verarbeiten und austauschen: Schwerpunkt Datenbanken

Aufgaben zur fachwissenschaftlichen Prüfung Modul 3 Daten erfassen, ordnen, verarbeiten und austauschen: Schwerpunkt Datenbanken Aufgaben zur fachwissenschaftlichen Prüfung Modul 3 Daten erfassen, ordnen, verarbeiten und austauschen: Schwerpunkt Datenbanken 30 Wozu dient ein Primärschlüssel? Mit dem Primärschlüssel wird ein Datenfeld

Mehr

3. Das Relationale Datenmodell

3. Das Relationale Datenmodell 3. Das Relationale Datenmodell Das Relationale Datenmodell geht zurück auf Codd (1970): E. F. Codd: A Relational Model of Data for Large Shared Data Banks. Comm. of the ACM 13(6): 377-387(1970) DBMS wie

Mehr

Schulinternes Curriculum im Fach Informatik

Schulinternes Curriculum im Fach Informatik Schulinternes Curriculum im Fach Informatik Unterricht in EF : 1. Geschichte der elektronischen Datenverarbeitung (3 Stunden) 2. Einführung in die Nutzung von Informatiksystemen und in grundlegende Begriffe

Mehr

Klassenbeziehungen & Vererbung

Klassenbeziehungen & Vererbung Klassenbeziehungen & Vererbung VL Objektorientierte Programmierung Raimund Kirner teilweise nach Folien von Franz Puntigam, TU Wien Überblick Arten von Klassenbeziehungen Untertypen versus Vererbung in

Mehr

Modellbasierte Softwareentwicklung mit EMF

Modellbasierte Softwareentwicklung mit EMF Softwaretechnik I, WS 2009/10 Modellbasierte Softwareentwicklung mit EMF Übungsblatt 5 13. November 2009 Organisatorisches Zur Bearbeitung der Übungsaufgabe stehen Ihnen die folgenden 3 Wochen (Kalenderwochen

Mehr

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6.

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6. 6. Modellierung von Informationssystemen Spezialseminar Matr. FS 2000 1/10 Volker Dobrowolny FIN- ITI Quellen: Oscar Pastor, Jaime Gomez, Emilio Insfran, Vicente Pelechano The OO-Method approach for information

Mehr

Einführung in die Informationsverarbeitung Teil Thaller. Stunde VII: Planen und Realisieren

Einführung in die Informationsverarbeitung Teil Thaller. Stunde VII: Planen und Realisieren Einführung in die Informationsverarbeitung Teil Thaller Stunde VII: Planen und Realisieren Manfred Thaller, Universität zu Köln Köln 18. Dezember 2014 Rekapitulation Der Gang der Argumentation 1. Der Rohstoff:

Mehr

Gliederung Datenbanksysteme

Gliederung Datenbanksysteme Gliederung Datenbanksysteme 5. Datenbanksprachen 1. Datendefinitionsbefehle 2. Datenmanipulationsbefehle 3. Grundlagen zu SQL 6. Metadatenverwaltung 7. DB-Architekturen 1. 3-Schema-Modell 2. Verteilte

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Datenbanken I - Einführung

Datenbanken I - Einführung - Einführung April, 2011 1 von 30 Outline 1 Organisatorisches 2 Vorlesungsinhalt 3 Begrisklärung 4 Motivation 5 Abstraktion 6 Datenmodelle 7 Literaturangabe 2 von 30 Scheinkriterien Belegübung Regelmäÿige

Mehr

Persistenz. Workplace Solutions. Persistenz. ÿ RDBMS und OO ÿ Strukturkonflikt ÿ Object-RDBMS-Mapping. Abbildung Objekte auf RDBMS

Persistenz. Workplace Solutions. Persistenz. ÿ RDBMS und OO ÿ Strukturkonflikt ÿ Object-RDBMS-Mapping. Abbildung Objekte auf RDBMS Persistenz ÿ RDBMS und OO ÿ Strukturkonflikt ÿ Object-RDBMS-Mapping APCON Abbildung Objekte auf RDBMS Der Strukturkonflikt Basisklassen und Domänen Klassen zur Kapselung der relationalen Datenbank Abbildung

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

Software Engineering Analyse und Analysemuster

Software Engineering Analyse und Analysemuster Software Engineering Analyse und Analysemuster Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassendiagramme in der Analyse Im Rahmen der Anforderungsanalyse

Mehr

Software Engineering Klassendiagramme Einführung

Software Engineering Klassendiagramme Einführung Software Engineering Klassendiagramme Einführung Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Aufgabe Erstellen Sie eine Klasse Person in Java. Jede Person verfügt

Mehr

OM Datenbanken. OM Datenbanken. 8.1 Was ist ein Datenbanksystem? Motivation

OM Datenbanken. OM Datenbanken. 8.1 Was ist ein Datenbanksystem? Motivation 1 Inhalt: Relationale Datenbanken 8.1 Was ist ein Datenbanksystem? 8.2 Relationale Datenbanksysteme 8.3 Abbildung des objektorientierten Modells auf Tabellen 2 8.1 Was ist ein Datenbanksystem? Motivation

Mehr

Profilbezogene informatische Bildung in den Klassenstufen 9 und 10. Schwerpunktthema Daten und Datenbanken

Profilbezogene informatische Bildung in den Klassenstufen 9 und 10. Schwerpunktthema Daten und Datenbanken Profilbezogene informatische Bildung in den Klassenstufen 9 und 10 Schwerpunktthema Robby Buttke Fachberater für Informatik RSA Chemnitz Fachliche Einordnung Phasen relationaler Modellierung Fachlichkeit

Mehr

Objektorientierte Modellierung (1)

Objektorientierte Modellierung (1) Objektorientierte Modellierung (1) Die objektorientierte Modellierung verwendet: Klassen und deren Objekte Beziehungen zwischen Objekten bzw. Klassen Klassen und Objekte Definition Klasse Eine Klasse ist

Mehr

In diesem Abschnitt wollen wir uns mit der Architektur von Datenbank Managements Systemen beschäftigen.

In diesem Abschnitt wollen wir uns mit der Architektur von Datenbank Managements Systemen beschäftigen. 1 In diesem Abschnitt wollen wir uns mit der Architektur von Datenbank Managements Systemen beschäftigen. Zunächst stellt sich die Frage: Warum soll ich mich mit der Architektur eines DBMS beschäftigen?

Mehr

Wirtschaftsinformatik 2. Tutorium im WS 11/12

Wirtschaftsinformatik 2. Tutorium im WS 11/12 Wirtschaftsinformatik 2. Tutorium im WS 11/12 Entity/Relationship-Modell SQL Statements Tutorium Wirtschaftsinformatik WS 11/12 2.1 Datenmodellierung mit ERM (1) Datenmodellierung zur Erarbeitung des konzeptionellen

Mehr

Kapitel 14 Verteilte DBMS

Kapitel 14 Verteilte DBMS Kapitel 14 Verteilte DBMS 14 Verteilte DBMS 14 Verteilte DBMS...1 14.1 Begriff, Architektur und Ziele verteilter Datenbanksysteme...2 14.2 Verteilungsarten...5 14.2.1 Verteilung der Daten...5 14.2.2 Verteilung

Mehr

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben

Mehr

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER INHALTSVERZEICHNIS 1. Datenbanken 2. SQL 1.1 Sinn und Zweck 1.2 Definition 1.3 Modelle 1.4 Relationales Datenbankmodell 2.1 Definition 2.2 Befehle 3.

Mehr

Objektorientierte Programmiersprachen

Objektorientierte Programmiersprachen Objektorientierte Programmiersprachen 1960 Algol 1970 Simula Pascal 1980 Smalltalk C Ada 1990 C++ Eiffel Eine ovale Box symbolisiert eine objektorientierte Programmiersprache. Eine rechteckige Box steht

Mehr

Ministerium für Kultus, Jugend und Sport Baden-Württemberg

Ministerium für Kultus, Jugend und Sport Baden-Württemberg Anlage zu 45-6512-2420/31 Ministerium für Kultus, Jugend und Sport Baden-Württemberg Schulversuch 51-6624.20/100 (früher: /84) vom 26. August 2003 Lehrpläne für das berufliche Gymnasium der sechs- und

Mehr

Softwaretechnik (Allgemeine Informatik) Überblick

Softwaretechnik (Allgemeine Informatik) Überblick Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6

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

Integration verteilter Datenquellen in GIS-Datenbanken

Integration verteilter Datenquellen in GIS-Datenbanken Integration verteilter Datenquellen in GIS-Datenbanken Seminar Verteilung und Integration von Verkehrsdaten Am IPD Lehrstuhl für Systeme der Informationsverwaltung Sommersemester 2004 Christian Hennings

Mehr

Aufgabe 1: [Logische Modellierung]

Aufgabe 1: [Logische Modellierung] Aufgabe 1: [Logische Modellierung] a) Entwerfen Sie für das von Ihnen entworfene Modell aus Aufgabe 2 des 1. Übungsblattes ein Star-Schema. b) Entwerfen Sie für das vorangegangene Modell einen Teil eines

Mehr

Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 11.09.2009

Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 11.09.2009 Hochschule Darmstadt DATENBANKEN Fachbereich Informatik Praktikum 3 Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 11.09.2009 PL/SQL Programmierung Anwendung des Cursor Konzepts und Stored Procedures Und Trigger

Mehr

Klausur zur Vorlesung Datenbanksysteme I

Klausur zur Vorlesung Datenbanksysteme I Prof. Dr. W. Kießling 30.01.2002 Lehrstuhl für Datenbanken und Informationssysteme Universität Augsburg Klausur zur Vorlesung Datenbanksysteme I Wintersemester 2001/2002 Name Vorname Matrikelnummer Aufgabe

Mehr

Themenblock: Erstellung eines Cube

Themenblock: Erstellung eines Cube Themenblock: Erstellung eines Cube Praktikum: Data Warehousing und Data Mining Einführung relationale Datenbanken Problem Verwaltung großer Mengen von Daten Idee Speicherung der Daten in Form von Tabellen

Mehr

Datenbanktechnologie für Data-Warehouse-Systeme

Datenbanktechnologie für Data-Warehouse-Systeme Wolfgang Lehner Datenbanktechnologie für Data-Warehouse-Systeme Konzepte und Methoden dpunkt.verlag 1 1.1 1.2 1.3 1.4 1. 5 2 2.1 2.2 2.3 Einleitung 1 Betriebswirtschaftlicher Ursprung des Data Warehousing...

Mehr

Einführung relationale Datenbanken. Themenblock: Erstellung eines Cube. Schlüssel. Relationenmodell Relationenname Attribut. Problem.

Einführung relationale Datenbanken. Themenblock: Erstellung eines Cube. Schlüssel. Relationenmodell Relationenname Attribut. Problem. Themenblock: Erstellung eines Cube Einführung relationale Datenbanken Problem Verwaltung großer Mengen von Daten Praktikum: Data Warehousing und Data Mining Idee Speicherung der Daten in Form von Tabellen

Mehr

Informationsintegration

Informationsintegration Informationsintegration Grundlegende Architekturen Ulf Leser Inhalt diese Vorlesung Klassifikation verteilter, autonomer, heterogener Systeme Weitere Klassifikationskriterien Schichtenaufbau integrierter

Mehr

30. Juni 2006 - Technische Universität Kaiserslautern. Paul R. Schilling

30. Juni 2006 - Technische Universität Kaiserslautern. Paul R. Schilling 30. Juni 2006 - Technische Universität Kaiserslautern Paul R. Schilling ! " #$% & '( ( ) *+, - '. / 0 1 2("$ DATEN SIND ALLGEGENWÄRTIG Bill Inmon, father of data warehousing Unternehmen In einer vollkommenen

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

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

cs241: Datenbanken mit Übungen HS 2011

cs241: Datenbanken mit Übungen HS 2011 UNIVERSITÄT BASEL Prof. Dr. Heiko Schuldt MSc. Nenad Stojnić BSc. Ivan Giangreco BSc. Florian Lindörfer cs241: Datenbanken mit Übungen HS 2011 Übung 5 Abgabe bis: 4.11.2011 Hinweise: Modalitäten der Abgabe:

Mehr

Objektrelationale Datenbanken

Objektrelationale Datenbanken Vorlesung Datenbanksysteme vom 26.11.2008 Objektrelationale Datenbanken Konzepte objektrelationaler DBs SQL:1999 OO vs. OR Konzepte objektrelationaler Datenbanken Große Objekte (LOBs: Large Objects) Mengenwertige

Mehr

Abschnitt 9: Schnittstellen: Interfaces

Abschnitt 9: Schnittstellen: Interfaces Abschnitt 9: Schnittstellen: Interfaces 9. Schnittstellen: Interfaces 9.1 Die Idee der Schnittstellen 9.2 Schnittstellen in Java 9.3 Marker-Interfaces 9.4 Interfaces und Hilfsklassen 9.5 Zusammenfassung

Mehr

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Wesentliche Inhalte Begriff DBS Datenbankmodelle Datenbankentwurf konzeptionell, logisch und relational

Mehr

J.2 Objektorientiertes Modellieren mit UML

J.2 Objektorientiertes Modellieren mit UML Modellieren mit UML Objektorientiertes Modellieren mit UML 2002 Prof. Dr. Rainer Manthey Informatik II 1 UML: Übersicht in den 1980er Jahren: Entstehen einer Vielzahl objektorientierter Entwurfsmethoden

Mehr

SQL SQL. SQL = Structured Query Language (SEQUEL) IBM San Jose Research Laboratory SYSTEM R. Grundlagen der Datenbanksysteme I

SQL SQL. SQL = Structured Query Language (SEQUEL) IBM San Jose Research Laboratory SYSTEM R. Grundlagen der Datenbanksysteme I SQL SQL = Structured Query Language (SEQUEL) IBM San Jose Research Laboratory SYSTEM R VII-1 Beispielrelationen Filiale ( Name Leiter Stadt Einlagen ) Konto ( KontoNr KundenNr FilialName Saldo ) Kredit

Mehr

Bibliografische Informationen digitalisiert durch http://d-nb.info/995021198

Bibliografische Informationen digitalisiert durch http://d-nb.info/995021198 Auf einen Blick 1 Einleitung 15 2 Datenbankentwurf 23 3 Datenbankdefinition 43 4 Datensätze einfügen (INSERT INTO) 95 5 Daten abfragen (SELECT) 99 6 Daten aus mehreren Tabellen abfragen (JOIN) 143 7 Unterabfragen

Mehr

Inhalt der Vorlesung. 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell. 3 Relationenalgebra. 4 Datenbanksprache (SQL)

Inhalt der Vorlesung. 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell. 3 Relationenalgebra. 4 Datenbanksprache (SQL) Inhalt der Vorlesung 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell 3 Relationenalgebra 4 Datenbanksprache (SQL) 5 Normalisierung 6 Vom ERM zum Datenbankschema 7 Routinen und

Mehr

24 Transformation der Anforderungsspezifikation

24 Transformation der Anforderungsspezifikation 271 24 Transformation der Anforderungsspezifikation 24.1 Einleitung Bei der Softwarespezifizierung wird die Anforderungsspezifikation überarbeitet, weiter strukturiert und präzisiert, um eine Basis für

Mehr

Oracle-Statistiken im Data Warehouse effizient nutzen

Oracle-Statistiken im Data Warehouse effizient nutzen Oracle-Statistiken im Data Warehouse effizient nutzen Reinhard Mense ARETO Consulting Köln Schlüsselworte: DWH, Data Warehouse, Statistiken, Optimizer, Performance, Laufzeiten Einleitung Für die performante

Mehr

IT-Kompaktkurs. Datenbanken Skript zur Folge 5. Prof. Dr. Georg Herde Fachhochschule Deggendorf

IT-Kompaktkurs. Datenbanken Skript zur Folge 5. Prof. Dr. Georg Herde Fachhochschule Deggendorf IT-Kompaktkurs Skript zur Folge 5 Prof. Dr. Georg Herde Fachhochschule Deggendorf Semantisches Datenmodell, Entity-Relationship, Normalformen Bei der Entwicklung einer Datenbank wird das Ziel angestrebt,

Mehr

Speicherung von XML in (objekt-)relationalen Datenbanken. Burkhard Schäfer

Speicherung von XML in (objekt-)relationalen Datenbanken. Burkhard Schäfer Speicherung von XML in (objekt-)relationalen Datenbanken Burkhard Schäfer Übersicht Motivation Anforderungen Ansätze modellorientiert strukturorientiert Zusammenfassung Motivation Warum XML in Datenbanken

Mehr

Informatik II Datenorganisation Datenbanken

Informatik II Datenorganisation Datenbanken Informatik II Datenorganisation Datenbanken Studiengang Wirtschaftsingenieurwesen (2. Semester) Prof. Dr. Sabine Kühn Tel. (0351) 462 2490 Fachbereich Informatik/Mathematik skuehn@informatik.htw-dresden.de

Mehr

Mengenvergleiche: Alle Konten außer das, mit dem größten Saldo.

Mengenvergleiche: Alle Konten außer das, mit dem größten Saldo. Mengenvergleiche: Mehr Möglichkeiten als der in-operator bietet der θany und der θall-operator, also der Vergleich mit irgendeinem oder jedem Tupel der Unteranfrage. Alle Konten außer das, mit dem größten

Mehr

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel. EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG

Mehr

Fundamentals of Software Engineering 1

Fundamentals of Software Engineering 1 Folie a: Name Fundamentals of Software Engineering 1 Grundlagen der Programmentwurfstechnik 1 Sommersemester 2012 Dr.-Ing. Stefan Werner Fakultät für Ingenieurwissenschaften Folie 1 Inhaltsverzeichnis

Mehr

Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung

Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung 6. Datenintegrität Motivation Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung nur sinnvolle Attributwerte (z.b. keine negativen Semester) Abhängigkeiten

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr