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

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

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

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

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

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

Informationsintegration

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

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

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

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

Einführung in die Informatik II

Einführung in die Informatik II Einführung in die Informatik II Die Structured Query Language SQL Prof. Dr. Nikolaus Wulff SQL Das E/R-Modell lässt sich eins zu eins auf ein Tabellenschema abbilden. Benötigt wird eine Syntax, um Tabellen

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

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

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

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

PostgreSQL im praktischen Einsatz. Stefan Schumacher

PostgreSQL im praktischen Einsatz. Stefan Schumacher PostgreSQL im praktischen Einsatz 2. Brandenburger Linux Infotag 2005 Stefan Schumacher , PGP Key http:/// $Header: /home/daten/cvs/postgresql/folien.tex,v 1.11 2005/04/25

Mehr

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

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr Raum: LF 230 Bearbeitung: 9.-11. Mai 2005 Datum Gruppe Vorbereitung Präsenz Aktuelle Informationen unter: http://www.is.informatik.uni-duisburg.de/courses/dbp_ss03/ Tabellen in IBM DB2 Tabellen Eine relationale

Mehr

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. DB Einleitung / Entity-Relationship

Mehr

SQL Tutorial. SQL - Tutorial SS 06. Hubert Baumgartner. INSO - Industrial Software

SQL Tutorial. SQL - Tutorial SS 06. Hubert Baumgartner. INSO - Industrial Software SQL Tutorial SQL - Tutorial SS 06 Hubert Baumgartner INSO - Industrial Software Institut für Rechnergestützte Automation Fakultät für Informatik Technische Universität Wien Inhalt des Tutorials 1 2 3 4

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

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

Einführung in die Programmierung mit Java. Hörsaalübung

Einführung in die Programmierung mit Java. Hörsaalübung Einführung in die Programmierung mit Java Hörsaalübung Folie 1 Grundlagen der Objektorientierung Seit Anfang der Neunzigerjahre Standardmethode der Softwareentwicklung. Die OOP Objektorientierte Programmierung

Mehr

Software-Engineering Einführung

Software-Engineering Einführung Software-Engineering Einführung 7. Übung (04.12.2014) Dr. Gergely Varró, gergely.varro@es.tu-darmstadt.de Erhan Leblebici, erhan.leblebici@es.tu-darmstadt.de Tel.+49 6151 16 4388 ES Real-Time Systems Lab

Mehr

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1.

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1. Inhalt der Vorlesung Literatur 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell 3 Relationenalgebra 4 Datenbanksprache (SQL) 5 Normalisierung 6 Vom ERM zum Datenbankschema 7 Routinen

Mehr

LISE MEITNER GYMNASIUM NEUENHAUS UELSEN

LISE MEITNER GYMNASIUM NEUENHAUS UELSEN Entwurf eines schulinternen Curriculums im Fach Informatik für die Qualifikationsphase (Jahrgang 11 und 12) Für die Gestaltung des Informatikunterrichts in der Qualifikationsphase sind für das schulinterne

Mehr

Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme. 11. November 2014

Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme. 11. November 2014 Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme 11. November 2014 Überblick Was ist die Unified Modeling Language (UML)? die Standardmodellierungssprache für Softwaresysteme

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

3. Spezielle ER-Modelle und Tabellenableitung. Transformation von ER-Diagrammen in Relationen

3. Spezielle ER-Modelle und Tabellenableitung. Transformation von ER-Diagrammen in Relationen 3. Spezielle ER-Modelle und Tabellenableitung Spezialfälle von ER-Modellen Grundlage, was sind Relationen Transformation von ER-Diagrammen in Relationen 56 Lesebeispiel Access (Realisierungmodell!) 57

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

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten Einführung in SQL Die Sprache SQL (Structured Query Language) ist eine Programmiersprache für relationale Datenbanksysteme, die auf dem ANSI-SQL-Standard beruht. SQL wird heute von fast jedem Datenbanksystem

Mehr

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008 PIWIN I Kap. 7 Objektorientierte Programmierung - Einführung 1 PIWIN I Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I Vorlesung 3 SWS WS 2007/2008 FB Informatik

Mehr

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22 Kapitel 19 Vererbung, UML Seite 1 von 22 Vererbung - Neben der Datenabstraktion und der Datenkapselung ist die Vererbung ein weiteres Merkmal der OOP. - Durch Vererbung werden die Methoden und die Eigenschaften

Mehr

Steuerungsverfahren und ihre Datenstrukturen 02 - Datenmanagement

Steuerungsverfahren und ihre Datenstrukturen 02 - Datenmanagement Steuerungsverfahren und ihre Datenstrukturen 02 - Datenmanagement 1 Übersicht - Datenmanagement 1 Übersicht - Datenmanagement...1 2 Übersicht: Datenbanken - Datawarehouse...2 3 Übersicht: Data Mining...11

Mehr

Programmieren in Java

Programmieren in Java Programmieren in Java objektorientierte Programmierung 2 2 Zusammenhang Klasse-Datei In jeder *.java Datei kann es genau eine public-klasse geben wobei Klassen- und Dateiname übereinstimmen. Es können

Mehr

Objektorientierte Programmierung mit Python Polymorphismus und Vererbung. Eltern

Objektorientierte Programmierung mit Python Polymorphismus und Vererbung. Eltern Objektorientierte Programmierung mit Python Polymorphismus und Vererbung Eltern Kind Kind Kind Kind Prinzipien der objektorientierten Programmierung Vererbung Strukturierung von Klassen. Oberbegriffe beschreiben

Mehr

Prinzipien Objektorientierter Programmierung

Prinzipien Objektorientierter Programmierung Prinzipien Objektorientierter Programmierung Valerian Wintner Inhaltsverzeichnis 1 Vorwort 1 2 Kapselung 1 3 Polymorphie 2 3.1 Dynamische Polymorphie...................... 2 3.2 Statische Polymorphie........................

Mehr

Objektorientierte Programmierung. Kapitel 12: Interfaces

Objektorientierte Programmierung. Kapitel 12: Interfaces 12. Interfaces 1/14 Objektorientierte Programmierung Kapitel 12: Interfaces Stefan Brass Martin-Luther-Universität Halle-Wittenberg Wintersemester 2012/13 http://www.informatik.uni-halle.de/ brass/oop12/

Mehr

1 Objektorientierte Software-Entwicklung

1 Objektorientierte Software-Entwicklung 1 Objektmodellierung 1 Objektorientierte Software-Entwicklung Prof. Dr. Heide Balzert Fachbereich Informatik Fachhochschule Dortmund Heide Balzert 2000 2 Lernziele Wissen, was unter objektorientierter

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

DB2 SQL, der Systemkatalog & Aktive Datenbanken

DB2 SQL, der Systemkatalog & Aktive Datenbanken DB2 SQL, der Systemkatalog & Aktive Datenbanken Lehr- und Forschungseinheit Datenbanken und Informationssysteme 1 Ziele Auf DB2 Datenbanken zugreifen DB2 Datenbanken benutzen Abfragen ausführen Den Systemkatalog

Mehr

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

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr Raum: LF 230 Bearbeitung: 25.-29. April 2005 Datum Gruppe Vorbereitung Präsenz Aktuelle Informationen unter: http://www.is.informatik.uni-duisburg.de/courses/dbp_ss03/index.html Datenbankentwurf Der Entwurf

Mehr

Relationale Datenbanken Datenbankgrundlagen

Relationale Datenbanken Datenbankgrundlagen Datenbanksystem Ein Datenbanksystem (DBS) 1 ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern

Mehr

SQL für Trolle. mag.e. Dienstag, 10.2.2009. Qt-Seminar

SQL für Trolle. mag.e. Dienstag, 10.2.2009. Qt-Seminar Qt-Seminar Dienstag, 10.2.2009 SQL ist......die Abkürzung für Structured Query Language (früher sequel für Structured English Query Language )...ein ISO und ANSI Standard (aktuell SQL:2008)...eine Befehls-

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr

SQL (Structured Query Language) Schemata Datentypen

SQL (Structured Query Language) Schemata Datentypen 2 SQL Sprachelemente Grundlegende Sprachelemente von SQL. 2.1 Übersicht Themen des Kapitels SQL Sprachelemente Themen des Kapitels SQL (Structured Query Language) Schemata Datentypen Im Kapitel SQL Sprachelemente

Mehr

Software-Entwicklung: Konzepte der Objektorientierung

Software-Entwicklung: Konzepte der Objektorientierung Software-Entwicklung: Konzepte der Objektorientierung 1 Übersicht Objektorientierte Softwareentwicklung Klasse und Objekt Attribut und Operation Schnittstelle Taxonomie und Vererbung Weitere Begriffe 2

Mehr

Einführung in die Programmierung für NF

Einführung in die Programmierung für NF Einführung in die Programmierung für NF UML Valerie Holmeyer Michael Kirsch Direct Feedback Eure Mitarbeit ist mir wichbg Quiz nach den jeweiligen AbschniGen Jeder kann mitmachen App socra&ve auf Smartphone

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Data Mining-Modelle und -Algorithmen

Data Mining-Modelle und -Algorithmen Data Mining-Modelle und -Algorithmen Data Mining-Modelle und -Algorithmen Data Mining ist ein Prozess, bei dem mehrere Komponenten i n- teragieren. Sie greifen auf Datenquellen, um diese zum Training,

Mehr

Diplomarbeit. Die Entwicklung eines webbasierten Warenwirtschaftssystems mit dem postrelationalen Datenbanksystem Caché der Firma Intersystems

Diplomarbeit. Die Entwicklung eines webbasierten Warenwirtschaftssystems mit dem postrelationalen Datenbanksystem Caché der Firma Intersystems Diplomarbeit an der Private Fernfachhochschule Darmstadt Fachbereich Informatik Die Entwicklung eines webbasierten Warenwirtschaftssystems mit dem postrelationalen Datenbanksystem Caché der Firma Intersystems

Mehr

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML) Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design Softwaretechnik (Medieninformatik) Überblick: 6.1 Einleitung 6.2 Verfeinerung des Klassenmodells 6.3 Sequenzdiagramme 6.4 Umsetzung der Analysekonstrukte in das Design 6.5 Fallstudie 6.6 Software Kontrakte

Mehr

SQL structured query language

SQL structured query language Umfangreiche Datenmengen werden üblicherweise in relationalen Datenbank-Systemen (RDBMS) gespeichert Logische Struktur der Datenbank wird mittels Entity/Realtionship-Diagrammen dargestellt structured query

Mehr

Softwaretool Data Delivery Designer

Softwaretool Data Delivery Designer Softwaretool Data Delivery Designer 1. Einführung 1.1 Ausgangslage In Unternehmen existieren verschiedene und häufig sehr heterogene Informationssysteme die durch unterschiedliche Softwarelösungen verwaltet

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 9 17. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

Inhalt. Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle. Daten und Tabellen - ein Beispiel. Daten und Tabellen - Normalisierung

Inhalt. Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle. Daten und Tabellen - ein Beispiel. Daten und Tabellen - Normalisierung Inhalt Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle Daten und Tabellen Normalisierung, Beziehungen, Datenmodell SQL - Structured Query Language Anlegen von Tabellen Datentypen (Spalten,

Mehr

Verhindert, dass eine Methode überschrieben wird. public final int holekontostand() {...} public final class Girokonto extends Konto {...

Verhindert, dass eine Methode überschrieben wird. public final int holekontostand() {...} public final class Girokonto extends Konto {... PIWIN I Kap. 8 Objektorientierte Programmierung - Vererbung 31 Schlüsselwort: final Verhindert, dass eine Methode überschrieben wird public final int holekontostand() {... Erben von einer Klasse verbieten:

Mehr

DB-Entwurf im ER-Modell

DB-Entwurf im ER-Modell DB-Entwurf im 1 Datenbankentwurf 2 Datenbankmodell 3 4 Erweiterungen des s 5 Weiteres Vorgehen beim Entwurf Sattler / Saake Datenbanksysteme Wintersemester 2006/7 4 1 Datenbankentwurf Entwurfsaufgabe Datenhaltung

Mehr

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle 1 Das Entity-Relationship-Modell Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle Prof. Dr.

Mehr

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

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

Mehr

MaxDB-Schulungsthemen

MaxDB-Schulungsthemen MaxDB-Schulungsthemen Ein Überblick über unser Angebot Allgemeine Hinweise zu unseren Schulungen Die Schulungen finden in der Regel als Inhouse Schulungen bei den interessierten Unternehmen statt. Die

Mehr

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen:

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen: 1 Einführung in Datenbanksysteme Fast jeder kennt Excel und hat damit in seinem Leben schon einmal gearbeitet. In Excel gibt es Arbeitsblätter, die aus vielen Zellen bestehen, in die man verschiedene Werte

Mehr

IV. Datenbankmanagement

IV. Datenbankmanagement Wirtschaftsinformatik 2 (PWIN) IV. Datenbankmanagement Kapitel 2: Datenmanipulationssprache SQL Wirtschaftsinformatik 2 (PWIN) SS 2009, Professur für Mobile Business & Multilateral Security 1 Agenda 1.

Mehr

ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen

ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen C3: Structured Query Language Lernziele: Nach der Bearbeitung dieser Lektion haben Sie folgende Kenntnisse erworben: Sie können elementaren

Mehr

LDAP. Lightweight Directory. Desanka Bogicevic 1121621 Michael Wenig 1220567 Rupert Eisl 1220225

LDAP. Lightweight Directory. Desanka Bogicevic 1121621 Michael Wenig 1220567 Rupert Eisl 1220225 LDAP Lightweight Directory Access Protokoll Desanka Bogicevic 1121621 Michael Wenig 1220567 Rupert Eisl 1220225 LDAP Was ist LDAP? Was sind Verzeichnisdienste? Was ist ein Verzeichnis? Geschichte http://directory.apache.org/apacheds/basic-ug/1.2-some-background.html

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

Kapitel 2: Der Software-Entwicklungsprozess Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken

Mehr

Software-Engineering und Datenbanken

Software-Engineering und Datenbanken Software-Engineering und Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Prof. Dr. Bernhard Schiefer 1-1 Wesentliche Inhalte Begriff DBS Datenbankmodelle

Mehr

bersicht Datenbanken und Datawarehouses Datenbank Datenbanksysteme Niels Schršter

bersicht Datenbanken und Datawarehouses Datenbank Datenbanksysteme Niels Schršter bersicht Niels Schršter EinfŸhrung GROUP BY Roll UpÔs Kreuztabellen Cubes Datenbank Ansammlung von Tabellen, die einen ãausschnitt der WeltÒ fÿr eine Benutzergruppe beschreiben. Sie beschreiben die funktionalen

Mehr

Informatik 12 Datenbanken SQL-Einführung

Informatik 12 Datenbanken SQL-Einführung Informatik 12 Datenbanken SQL-Einführung Gierhardt Vorbemerkungen Bisher haben wir Datenbanken nur über einzelne Tabellen kennen gelernt. Stehen mehrere Tabellen in gewissen Beziehungen zur Beschreibung

Mehr

C++ - Einführung in die Programmiersprache Polymorphismus und Vererbung. Eltern

C++ - Einführung in die Programmiersprache Polymorphismus und Vererbung. Eltern C++ - Einführung in die Programmiersprache Polymorphismus und Vererbung Eltern Kind Kind Vererbung Definition von Klassen auf Basis von bestehenden Klassen. Implementierung von ist ein. bildet ein hierarchisches

Mehr

Erste Schritte, um selber ConfigMgr Reports zu erstellen

Erste Schritte, um selber ConfigMgr Reports zu erstellen Thomas Kurth CONSULTANT/ MCSE Netree AG thomas.kurth@netree.ch netecm.ch/blog @ ThomasKurth_CH Erste Schritte, um selber ConfigMgr Reports zu erstellen Configuration Manager Ziel Jeder soll nach dieser

Mehr

Business Intelligence Praktikum 1

Business Intelligence Praktikum 1 Hochschule Darmstadt Business Intelligence SS 2014 Fachbereich Informatik Praktikumsversuch 1 Prof. Dr. C. Wentzel Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 07.05.2014 Business Intelligence Praktikum

Mehr

Gliederung und Einordnung

Gliederung und Einordnung Gliederung und Einordnung 1. Objektorientierte Programmierung mit Object Pascal (5. Studienbrief, Kapitel 5) 9.4. + 16.4. 2. Software-Bausteine am Beispiel der Delphi-Komponenten (5. Studienbrief, Kapitel

Mehr

Objektorientierte Datenmodelle und - verwaltung

Objektorientierte Datenmodelle und - verwaltung Schlagworte der 90er: Objektorientiertes GIS OpenGIS Case-Tool Geoökologe Legt Problemstellung fest (Art, Anzahl, Dimension, Skalierung) Wählt Koordinatensystem Wählt Fachattribute OOUI (object-oriented

Mehr

Sicherheitsaspekte. Szenarien. Angriffsarten. Discretionary Access Control. Sicherheit im DBMS. Identifikation und Authentisierung

Sicherheitsaspekte. Szenarien. Angriffsarten. Discretionary Access Control. Sicherheit im DBMS. Identifikation und Authentisierung Sicherheitsaspekte Sicherheit im DBMS Identifikation und Authentisierun Autorisierun und Zuriffskontrolle Auditin Szenarien Literaturdatenbank in der Hochschule: erines Sicherheitsbedürfnis ERP-Datenbank

Mehr

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. Einleitung / Entity-Relationship

Mehr

Grundlagen der Informatik. Prof. Dr. Stefan Enderle NTA Isny

Grundlagen der Informatik. Prof. Dr. Stefan Enderle NTA Isny Grundlagen der Informatik Prof. Dr. Stefan Enderle NTA Isny 2 Datenstrukturen 2.1 Einführung Syntax: Definition einer formalen Grammatik, um Regeln einer formalen Sprache (Programmiersprache) festzulegen.

Mehr

5 Schemadefinition in objektrelationalen Datenbanksystemen

5 Schemadefinition in objektrelationalen Datenbanksystemen 75 5 Schemadefinition in objektrelationalen Datenbanksystemen In diesem Kapitel wird die Definition objektrelationaler Schemata am Beispiel von DB2 konkretisiert. Zu diesem Zweck wird zunächst das DBMS

Mehr

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de Vorlesung Grundlagen betrieblicher Informationssysteme Prof. Dr. Hans Czap Email: Hans.Czap@uni-trier.de - II - 1 - Inhalt Kap. 1 Ziele der Datenbanktheorie Kap. 2 Datenmodellierung und Datenbankentwurf

Mehr

Angewandte Mathematik und Programmierung

Angewandte Mathematik und Programmierung Angewandte Mathematik und Programmierung Einführung in das Konzept der objektorientierten Anwendungen zu mathematischen Rechnens WS 2013/14 Die Vererbung ermöglicht es, neue Klassen auf der Basis von schon

Mehr

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Suche schlecht beschriftete Bilder mit Eigenen Abfragen Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

Datenbanken: ER-Modell

Datenbanken: ER-Modell Beispiel: Lastenheft: Für eine Hochschule soll eine Verwaltungssoftware geschrieben werden, die alle relevanten Daten in einem relationalen Datenbanksystem speichert. Zu diesen Daten zählen die Stamm-

Mehr

Einführung in das Entity-Relationship-Modell

Einführung in das Entity-Relationship-Modell Einführung in das Entity-Relationship-Modell Historie Entity-Relationship-Modell kurz: ER-Modell bzw. ERM 1976 von Peter Chen vorgeschlagen Standardmodell für frühe Entwurfsphasen in der Datenbankentwicklung

Mehr

1. Java ist... 2. Stammbaum der Programmiersprachen 3. Die "Softwarekrise"

1. Java ist... 2. Stammbaum der Programmiersprachen 3. Die Softwarekrise im Überblick im Überblick Inhalt 1. Java ist... 2. Stammbaum der Programmiersprachen 3. Die Softwarekrise 1. Merkmale von Software 2. Fortlaufende Veränderungen 3. Erschwerte Rahmenbedingungen bei der

Mehr

Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell

Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell Aufgabe 3. Assoziation

Mehr

Praktikum Software Engineering

Praktikum Software Engineering Praktikum Software Engineering Verwendung von Enterprise Architect Pascal Weber, David Kulicke KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft

Mehr

Objektorientierte Programmierung. Objektorientierte Programmierung. Klasse. Objekt. Beispiel: Sportfest1. Methode. Eine Einführung mit BlueJ

Objektorientierte Programmierung. Objektorientierte Programmierung. Klasse. Objekt. Beispiel: Sportfest1. Methode. Eine Einführung mit BlueJ Objektorientierte Programmierung Objektorientierte Programmierung Eine Einführung mit BlueJ stellt die Daten, ihre Struktur und ihre Beziehungen zueinander in den Vordergrund. Weniger im Blickpunkt: die

Mehr

Cassandra Query Language (CQL)

Cassandra Query Language (CQL) Cassandra Query Language (CQL) Seminar: NoSQL Wintersemester 2013/2014 Cassandra Zwischenpräsentation 1 Gliederung Basic facts Datentypen DDL/DML ähnlich zu SQL Besonderheiten Basic facts CQL kurz für

Mehr

Agenda. Themenblock: Data Warehousing (I) Referenzarchitektur. Eigenschaften eines Data Warehouse. Einführung Data Warehouse Data Access mit SQL

Agenda. Themenblock: Data Warehousing (I) Referenzarchitektur. Eigenschaften eines Data Warehouse. Einführung Data Warehouse Data Access mit SQL Themenblock: Data Warehousing (I) Praktikum: Data Warehousing und Data Mining 2 Eigenschaften eines Data Warehouse Referenzarchitektur Integrierte Sicht auf beliebige Daten aus verschieden Datenbanken

Mehr

Orientierte Modellierung mit der Unified Modeling Language

Orientierte Modellierung mit der Unified Modeling Language UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language Michael Hahsler Ziel dieses Seminars Verständnis von Objekt-Orientierung Was sind Klassen? Was ist Vererbung?

Mehr

WHERE Klausel Generierung mit.net und Oracle. Aus unserer Projekterfahrung und Architektur-Kurs

WHERE Klausel Generierung mit.net und Oracle. Aus unserer Projekterfahrung und Architektur-Kurs Betrifft Art der Info Quelle WHERE Klausel Generierung mit.net und Oracle Technical Info Aus unserer Projekterfahrung und Architektur-Kurs Where ist the WHERE? Der Artikel untersucht die Möglichkeiten,

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Name: Matrikelnummer: Note: Prüfungstag: 21.09.2012 Prüfungsdauer:

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Musterlösung Name: Matrikelnummer: Note: Prüfungstag:

Mehr

adcubum ACADEMY. Die Vertiefung von Hochstehendem. SQL-Datenbankkurse

adcubum ACADEMY. Die Vertiefung von Hochstehendem. SQL-Datenbankkurse adcubum ACADEMY. Die Vertiefung von Hochstehendem. SQL-Datenbankkurse Rubrik: Datenbanken Einleitung adcubum SYRIUS legt alle Bewegungsdaten in der Datenbank ab. Als Consultant, Parametrierer, Kundendienstmitarbeitender,

Mehr

1 Grundbegriffe...1. 2 Datenbanksysteme...7. 3 Entwicklung von Datenbanksystemen...15. Inhaltsverzeichnis. 1.1 Information und Daten...

1 Grundbegriffe...1. 2 Datenbanksysteme...7. 3 Entwicklung von Datenbanksystemen...15. Inhaltsverzeichnis. 1.1 Information und Daten... Inhaltsverzeichnis 1 Grundbegriffe...1 1.1 Information und Daten...2 1.2 Datenorganisation...3 1.3 Dateikonzept...5 1.4 Kontroll- und Vertiefungsfragen...6 2 Datenbanksysteme...7 2.1 Datenintegration...7

Mehr

Objekt-relationales Mapping und Performance-Tuning

Objekt-relationales Mapping und Performance-Tuning Objekt-relationales Mapping und Performance-Tuning Thomas Krüger tkrueger@vanatec.com Agenda Wege um Daten zu lesen Wege um Daten zu modellieren Wege um Datenbanken effizient zu nutzen 2 2 Wege, Daten

Mehr

LINQ to SQL. Proseminar Objektorientiertes Programmieren mit.net und C# Christoph Knüttel. Institut für Informatik Software & Systems Engineering

LINQ to SQL. Proseminar Objektorientiertes Programmieren mit.net und C# Christoph Knüttel. Institut für Informatik Software & Systems Engineering LINQ to SQL Proseminar Objektorientiertes Programmieren mit.net und C# Christoph Knüttel Institut für Informatik Software & Systems Engineering Agenda 1. LINQ allgemein Vorteile Bausteine und Varianten

Mehr

Einführung in die Unified Modeling Language (UML)

Einführung in die Unified Modeling Language (UML) Einführung in die Unified Modeling Language (UML) Hausarbeit zum Proseminar Datenbanken Wintersemester 2002/03 Seminarleitung: Dr. Christoph Draxler Verfasserin: Michaela Geierhos Centrum für Informations-

Mehr

Einführung in die Software-Umgebung

Einführung in die Software-Umgebung Ortsbezogene Anwendungen und Dienste WS2011/2012 Einführung in die Software-Umgebung Die Software-Umgebung Zentrale Postgres-Datenbank mit Geodaten von OpenStreetMap: Deutschland: 13 mio. Datensätze Topologie-Informationen

Mehr