Objektrelationale Datenbanken

Größe: px
Ab Seite anzeigen:

Download "Objektrelationale Datenbanken"

Transkript

1 Schriftliche Ausarbeitung zum Thema: Objektrelationale Datenbanken im Rahmen des Proseminars Objektorientierte Datenbanken, an der GH-Siegen, WS 1999/2000 von Tobias Fries, Hery L. Ramanoarisoa, Thouraya Ben Kali, Markus Paltian

2 Übersicht 1. Motivation des objektrelationalen Datenbankkonzeptes Allgemeine Anforderungen an Datenbanksysteme Nachteile relationaler und objektorientierter Datenbanksysteme Nachteile relationaler Datenbanksysteme Nachteile objektorientierter Datenbanksysteme Resultierende Anforderungen für objektrelationale Datenbanksysteme Merkmale objektrelationaler Datenbanksysteme Erweiterung relationaler Datenbanksysteme um abstrakte Typen Objektorientierte Erweiterungen Beispiele Strukturen und Mengen Hierarchien und Erbungsmechanismen Der neue Standard für objektrelationale Datenbanken SQL: Vergleich unterschiedlicher Produkte Informix Universal Server Oracle IBM DB Fazit Literatur

3 1. Motivation des objektrelationalen Datenbankkonzeptes Obwohl mit den relationalen Datenbanken ausgereifte, leistungsfähige und theoretisch untermauerte Systeme vorliegen, ist der alleinige Einsatz des relationalen Datenbankkonzeptes in vielen Anwendungsfällen nicht befriedigend, da die Existenz von nur einfachen Datentypen Modellierungen komplexer Aufgabenstellungen nicht unterstützt. Objektorientierte Datenbanken sind zwar genau hierzu zu in der Lage, können aber nicht ohne weiteres Datenbestände aus den älteren relationalen Systemen übernehmen. Außerdem stellen objektorientierte Datenbanken keinen vollständigen Ersatz für relationale Datenbanken dar, da sie in den klassischen Anwendung für relationale Systeme, also Verwaltung großer, einfach strukturierte Datenbestände, gegenüber diesen Systemen konzeptionell im Nachteil sind. Objektrelationale Datenbanksysteme wurden entwickelt um die Vorteile des objektorientierten und des relationalen Konzeptes zu vereinen und dabei deren jeweilige Nachteile auszuschalten Allgemeine Anforderungen an Datenbanksysteme Datenbanken dienen zur strukturierten und effizienten Speicherung und Verwaltung von Daten in Anwendungsfällen, bei denen das einfache Speichern von Daten über ein Dateisystem nicht mehr ausreichend ist. Die in einer Datenbank zu speichernden Daten werden durch ein Datenmodell definiert, indem deren Struktur, Operationen auf diesen Daten und Konsistenzregeln festgelegt werden. Die Daten in der Datenbank können nur über das Datenbank-Management-System (DBMS) eingefügt, gelesen, geändert oder gelöscht werden. Das DBMS ist ein Softwaresystem, dass die einheitliche Beschreibung und sichere Bearbeitung einer Datenbank ermöglicht. Es erfüllt unter anderem die folgenden Anforderungen: Das DBMS sorgt für Physische Datentunabhängigkeit: Änderungen an den hardwaremäßigen Speicherstrukturen und Zugriffspfaden sind für Anwenderprogramme und Queries unsichtbar, verändern also weder die logische, noch die externen Sichten Das DBMS sorgt für Logische Datentunabhängigkeit: Änderungen an der logischen Sicht (an den Typendefinitionen, Datenbankschemata) sind für Applikationen und Queries unsichtbar, diese arbeiten nur mit externen Sichten Das DBMS garantiert Korrektheit der Daten (Einhaltung der definierten Konsistenzregeln) Das DBMS garantiert Datensicherheit, d.h. Korrektheit bei fehlerhaftem Ablauf einzelner Anwendungen und Systemabsturz 3

4 Das DBMS garantiert Korrektheit im Mehrbenutzerbetrieb (concurrency control) Das DBMS bietet feinkörnige Zugriffskontrolle. Das DBMS sorgt für Redundanzvermeidung bzw. minimierung: Gleiche Daten werden möglichst nicht mehrfach abgespeichert. Dadurch wird nicht nur Einsparung von Speicherplatz erreicht, sondern auch die Aktualisierung der Daten wesentlich vereinfacht Das DBMS unterstützt spontane Anfragestellung (ad-hoc Queries). Anfragen werden vom System optimiert 1.2. Nachteile relationaler und objektorientierter Datenbanksysteme Die im letzten Abschnitt erwähnten Anforderungen an Datenbanksysteme werden, mit Ausnahme des fehlenden Sichtenkonzeptes bei objektorientierten Systemen, grundsätzlich von relationalen sowie objektorientierte Implementierungen erfüllt. Nichtsdestotrotz hat jeder Datenbanktyp, abhängig von der Beschaffenheit der Datenbankanwendung, seine individuelle Vor- und Nachteile. Allgemeingültig, also für beliebige Aufgabenstellungen gleichermaßen, kann keines der beiden Konzepte empfohlen werden. Vielmehr muss abhängig von der Datenbankanwendung entschieden werden, welchem der Beiden im speziellen Falle der Vorzug zu geben ist. Um diesen Umstand zu verdeutlichen, findet sich im folgenden eine Zusammenstellung der wichtigsten und schwerwiegensten Nachteile der jeweiligen Konzept Nachteile relationaler Datenbanksysteme Die grundlegende Einschränkung relationaler Datenbanken ist Tatsache, dass diese von Hause aus nur einfache Datentypen anbieten und darüber hinaus nicht die Neudefinition von benutzerdefinierten Datentypen gestatten. Allein die Fähigkeit zum Umgang mit komplexen Datentypen würde den Datenbankentwurf in viele Fällen vereinfachen. Für komplexe Aufgabenstellung hat sich die objektorientierte Modellierung durchgesetzt. Objektorientierte Konzepte werden aber von relationalen Datenbanken in keiner Weise unterstützt, wodurch der Datenbankentwurf in solch einem Fall extrem umständlich wird. Ist ein solches komplexes, objektorientiertes Modell einmal in das Relationenschema umgesetzt worden, so können selten alle Attribute eines Objektes aus dem Ausgangmodell in einer Tabelle untergebracht werden. Vielmehr ist es notwendig ein Objekt auf mehrere Tabellen aufzuteilen. Sollen in solch einem Fall durch eine Anfrage alle Attribute dieses Objektes ermittelt werden, so sind hierzu explizite Join-Operationen notwendig. Für komplexe Aufgabenstellungen bei denen objektorientierte Modellierung angebracht ist wird also nicht nur der Datenbankentwurf kompli- 4

5 zierter, sondern in vielen Fällen müssen auch die späteren Anfragen an die Datenbank umständlicher formuliert werden. Relationale Datenbanken kennen keine Objektidentität. Dieses Merkmal objektorientierter Datenbanken und Programmiersprachen erlaubt die Identifizierung eines Objektes selbst dann, wenn all seine Attribute in ihrem ursprünglichen Wert verändert worden sind. Wird ein Objekt in einem Tupel einer relationalen Tabelle gespeichert, so verliert es seine Identität, also die Möglichkeit es von außen eindeutig zu identifizieren sobald sein Primärschlüssel geändert wird. Von einer rein relationalen Datenbank wird auch Persistenz durch Erreichbarkeit nicht unterstützt. Bei diesem Persistenzkonzept werden alle Objekte in die Datenbank aufgenommen, die von einem bereits gespeicherten Objekt referenziert werden. Da auf diese Weise das Persistenzmerkmal von Objekt zu Objekt weitergegeben wird, ist z.b. das Abspeichern oder Löschen einer kompletten Listen mit nur einer Operation auf dem Listenkopf möglich. Bei relationalen Datenbanken muss man hierzu explizit jedes Element Speichern oder Löschen. Ein weiteres Manko ist die geringe Mächtigkeit von SQL, der Datenbankprogrammiersprache relationaler Systeme. Anspruchsvolle Berechnungen lassen sich besser oder ausschließlich in einer externe Programmiersprache verwirklichen. Auch ist es nicht möglich benutzerdefinierte Prozeduren oder Funktionen in SQL zu erstellen. Muss im Anwendungsfall auf eine externe Programmiersprache ausgewichen werden, so kommt es beim Datenaustausch zwischen Datenbank und externer Programmiersprache zum sogenannten Impedance Mismatch. Dieser Begriff beschreibt den Umstand das die Typsysteme von Datenbank und Programmiersprache sich unterscheiden. So muss das externes Programm dafür sorgen, dass die von der Datenbank gelieferten Daten in das Typsystem der Programmiersprache umgesetzt werden. Umgekehrt müssen die, in die Datenbank zu transferierenden, Daten zuvor in einen Datenbankkonformen Typen konvertiert werden. Dieser zusätzliche Programmieraufwand ist nicht nur zeitraubend, sondern zudem eine unerwünschte mögliche Fehlerquelle. Abschließend nochmals eine Auflistungen der größten Schwächen relationaler Systeme: keine komplexen Typen keine Objektorientierung keine Objektidentität, Primärschlüssel müssen durch Programmierer geeignet gewählt werden keine Persistenz durch Erreichbarkeit SQL als Programmiersprache nicht mächtig genug, keine benutzerdefinierbaren Prozeduren Impedance Mismatch: Typen von SQL und externen Programmiersprachen passen nicht zueinander und müssen ineinander konvertiert werden 5

6 Nachteile objektorientierter Datenbanksysteme Trotz der im letzten Abschnitt beschriebenen Nachteile stellen relationale Datenbanksysteme derzeit die weit verbreitetste Technologie dar. Für die Datenbestände, die hier gepflegt werden, ist es für den Fall, dass die relationale Technologie nicht mehr als ausreichend erachtet wird, wünschenswert, dass sie mit möglichst geringem Aufwand auf das neue Datenbanksystem zu portieren sind. Aufgrund der grundlegenden Unterschiede zwischen relationalen und objektorientierten Systemen ist die Migration von Erstem zu Zweitem keineswegs ohne weiteres zu erledigen. Bei Anwendungsfällen, in denen sich die relationale Datenbanktechnologie bewährt hat, also vor allem beim Verwalten großer, einfach aufgebauter Daten, ist zwar prinzipiell der Einsatz von objektorientierten Systemen möglich, allerdings nicht sonderlich empfehlenswert. In diesen Fällen nämlich, sind objektorientierte Datenbanksysteme in der Regel erhebliche langsamer. Ein Grund hiefür ist die gesteigerte Komplexität objektorientierter Datenbankprogrammiersprachen, die eine datenbankinterne Optimierungen von Lese- und Schreibzugriffen erschwert. Ein weiterer Nachteil, der mit der Komplexität und Leistungsfähigkeit objektorientierter Datenbankprogrammiersprachen zusammenhängt, ist die erhöhte Fehleranfälligkeit die diese Komplexität mit sich bringt. Je einfacher und überschaubarer eine Programmiersprache desto geringer ist nämlich auch die Wahrscheinlichkeit von Programmierfehlern, welche den Datenbestand einer Datenbank eventuell verfälschen könnten. Den objektorientierten Datenbanken fehlt das theoretische Fundament ihrer relationalen Verwandten, welche mathematisch mit Hilfe der Relationenalgebra eindeutig beschrieben werden können. Auch sind relationale Datenbankprodukte in der Regel ausgereifter, schließlich existieren diese Produkte seit Beginn der achtziger Jahre, während objektorientierte Datenbanken erst in den Neunzigern, einhergehend mit der Etablierung objektorientierter Entwurfs und Programmiermethoden, entstanden sind. Ein Rollenkonzept ist bei objektorientierten Datenbanken zwar vorhanden, allerdings in bestimmten Fällen recht aufwendig nur durch Mehrfacherbung zu realisieren. Im Detail wird dieser Punkt in Kapitel 3 mit einem Beispiel veranschaulicht. Allgemein kann gesagt werden, dass je mehr Rollen ein Objekt annehmen kann, desto umständlicher ist das objektorientierte Rollenkonzept. In Kapitel 1.1. wurde als grundlegende Anforderung an Datenbanksysteme die Datenunabhängigkeit genannt. Objektorientierte Datenbanksysteme besitzen allerdings weder ein Sichtenkonzept, welches logische Datenunabhängigkeit ermöglichen würde, noch implementieren sie externe Datenunabhängigkeit. Vielmehr wird die konzeptuelle Ebene, die Objektstrukturen, nahezu eins zu eins auf die verwendeten Massenspeichermedien ausgelagert. Das Fehlen von Datenunabhängikeit äußert sich bei nachträglichen Änderungen an konzeptueller oder physischer Ebene, und führt in diesen Fällen zu einem Mehraufwand, beispielsweise zum Anpassen bereits bestehender Applikationen an neue Datentypen, der bei bestehender Datenunabhängigkeit nicht erbracht werden muss. 6

7 Zusammenfassen weist ein objektorientiertes Datenbanksystem also folgende Schwachpunkt auf: Migration relationaler Datenbestände in objektorientierte Datenbanken nicht ohne weiteres möglich Performanznachteil bei großen, einfach strukturierten Datenbeständen Höhere Anfälligkeit für Programmierfehler, da Datenbanksprache komplexer keine theoretische Untermauerung, nicht so ausgereift wie relationale Systeme Rollenkonzept in bestimmten Fällen umständlich Keine Datenunabhängigkeit, da kein Drei-Ebenen Konzept 1.3. Resultierende Anforderungen für objektrelationale Datenbanksysteme Relationale Datenbanksysteme stellen heute eine etablierten Technologie dar, die in vielen Bereichen der Datenverarbeitung erfolgreich eingesetzt wird. Ein Großteil aller Geschäfts- und Prozessdaten ist in relationalen Datenbanken abgelegt. Die von den Systemen angebotenen Datentypen und Anfragesprachen sind für die typischen Standard-Datenbankanwendungen ausreichend. Nicht-Standard-Datenbankanwendungen stellen neue Anforderungen an Datenbanksysteme wie den Umgang mit komplex strukturierten Multimedia Daten. In einem Städteinformationssystem müssen beispielsweise Anfahrtspläne, Photographien und mit Bildern angereicherte Dokumente ebenso wie Audiodaten und Videos verwaltet werden. Aufgrund der anwendungsspezifischen Anforderungen an neue Datentypen, wäre eine herstellerseitige Ergänzung der vordefinierten Datentypen um neue Typen unzureichend. Es sollte vielmehr jedem Entwickler möglich sein, das Datenbanksystem seinen Bedürfnissen entsprechend mit neuen Datentypen und Funktionen zu erweitern. Somit werden die Anforderungen an ein neues Datenbankkonzept offenbar: Es sollte, um problemlose Übernahme vorhandener Datenbestände zu ermöglichen, auf der konventionellen relationalen Technologie aufsetzen und diese durch objektorientierte Erweiterungen ergänzen. Hierfür wäre eine objektorientierte Erweiterung des SQL-Standards wünschenswert, der erlaubt das Datenbanksystem mit neuen Typen, Funktionen und Regeln zu erweitern, ohne allerdings die Komplexität der Sprache ausufern zulassen. Genau dieser Gedanke wird von objektrelationalen Datenbanksystemen verfolgt. Ausgangspunkte für die aktuellen objektrelationalen Datenbankprodukte sind die etablierten relationalen Systemen, die die Hersteller nun um objektorientierte Konzepte erweitern, um die erwähnten Einschränkungen relationaler Systeme auszuschalten. Da mit SQL:1999 erst seit kurzem ein wohldefinierter Standard für objektrelationale Funktionalität besteht, ist die Implementierung objektrelationeller Merkmale in den verschiedenen Produkten auch unterschiedlich weit fortgeschritten. Welche Merkmale dies im einzelnen sind und welchen Funktionsumfang eine Datenbank mitbringen muss, um sich objektrelational nennen zu dürfen, soll im folgenden Kapitel behandelt werden. 7

8 2. Merkmale objektrelationaler Datenbanksysteme Das objektrelationale Konzept ist relativ neu, es ist durch Integration bekannter Ansätze und durch logische Weiterentwicklung entstanden. Seit vielen Jahren hat man immer wieder versucht das relationale Datenbankmodell zu erweitern, weil die Umstellung relationaler Datenbestände auf das strikte objektorientierte Konzept sehr umständlich bleibt. Bevor man aber auf das objektrelationale Modell gekommen ist, sind schon viele Neuerungen und Forschungen gemacht worden. Daraus sind neue Konzepte entstanden. Alle Konzepte sind unter dem Begriff Postrelationales Datenbanksystem zu verstehen. Der Name Postrelational soll an die unternommene Erweiterung des relationalen Modells erinnern. Zu den am häufigsten realisierten Konzepten zählen: Erweiterte, vordefinierte und benutzerdefinierte Datentypen Funktionen und Methoden Typkonstruktkoren Objektidentität Referenzen Die Basis für diese Systeme ist jeweils das Relationenmodell. Unterscheiden kann man Systeme dieser Entwicklungsrichtung wieder nach: Relationalen Datenbanksystemen mit strukturellen Erweiterungen Relationalen Datenbanksystemen mit Verhaltensmäßigen Erweiterungen Relationalen Datenbanksystemen mit einem ADT-Konzept, wobei die ADTs gleichermaßen Struktur und Verhalten definieren Relationalen Datenbanksystemen, die innerhalb des Relationenmodells relativ weitgehend ein objektorientiertes Datenbankmodell verwirklichen Wann ist ein System aber nun objektrelational? Um diese Frage zu beantworten betrachten wir zunächst die Klassifikationsmatrix von Stonebraker wie sie in [2] wiedergegeben wird: Demnach ist das Unterscheidungsmerkmal zwischen relationalen und objektrelationalen Datenbanken allein die Unterstützung komplexer Datentypen. In der Praxis müsste man aber dadurch viele postrelationale Systeme, die die Objektorientierung nicht verwirklichen als objektrelational bezeichnen. Zwischen objektrelationalen und objektorientierten Datenbanken trennt man nach 8

9 Stonebraker anhand der Existenz von Abfragesprachen. Aber auch reine objektorientierte Produkte, in [2] werden POET und O2 angegeben, besitzen mittlerweile Anfragesprachen. Mit Stonebraker muss man diese also ebenfalls als objektrelational bezeichnen, obwohl sie keine relationalen Anteile haben. Demnach ist der Ansatz von Stonebraker nicht mehr anwendbar und es müssen andere Kriterien verwendet werden um über die Objektrelationalität eines Systems zu entscheiden. Heuer verwendet hierfür in [2] eine geeigneteren Weg der spezifischere Eigenschaften von Datenbanken berücksichtigt. Objektrelational soll hier zuerst einmal heißen, daß das relationale Modell vollständig unterstützt wird. Begriffe wie Entitätstypen, Attribute, Tupel, Primärschlüssel und Fremdschlüssel, Projektion, Selektion und Verbindung von Tabellen gehören hier nach wie vor zum Grundvokabular. Das objektrelationale Model versucht darüber hinaus ein Datenbankmodell zu erschaffen das mit einige OO-Konzepten in der Form einer Tabelle" charakterisiert werden kann. Persistente Daten werden schon längst mit einer Tabelle verarbeitet, hinzugekommen ist nun die Fähigkeit, das Felder der Tabelle strukturierte Daten bzw. abstrakte Datentypen einnehmen können sollen. Außerdem sollen aus dem objektorientierten Konzept Merkmale wie Vererbungsprinzipen und Methodenüberschreibung (Overriding) integriert sein. Die folgende Tabelle veranschaulicht die Kriterien zur Klassifikation von Datenbanken nach Heuer, wobei die zu Beginn des Kapitel angesprochene Klasse von postrelationalen Datenbaken hier in zwei Kategorien eingeteilt wird: Demzufolge stellen Datenbanken die nur den Kriterien der linke Tabelle erfüllen, lediglich eine Erweiterung des relationalen Modells um abstrakte Datentypen dar, ohne objektorientierte Konzepte zu implementieren. Daher können sie auch nur als erweitert relational bezeichnet werden. Damit eine Datenbank als objektrelational eingestuft werden kann, müssen die Kriterien in der rechts stehenden Tabelle erfüllt sein. Hauptkriterium für Objektrelationalität ist also hiernach das Vorhandensein von Vererbungsmechanismen zur Methoden- und Strukturvererbung. Nachdem somit festgelegt ist, was unter objektrelationalen Datenbanken zu verstehen ist, erfolgt in den zwei nächsten Unterkapiteln nun eine Erläuterung der hier zur Unterscheidung aufgeführten Merkmale. 9

10 2.1. Erweiterung relationaler Datenbanksysteme um abstrakte Datentypen Damit relationale Datenbanksysteme mit abstrakten Datentypen umgehen können benötigen sie die folgenden Erweiterungen: komplexe, benutzerdefinierbare Datentypen Funktionen, Methoden Typenkonstruktoren Unter komplexen Datentypen versteht man Typen wie Struktur und Menge. Benutzerdefinierbare Datentypen resultieren aus der Kombination der internen Datentypen der Datenbank. Funktionen konnten bisher in Standard-SQL nicht erzeugt werden. Dieses, in herkömmlichen Programmiersprachen schon lange bekannte Konzept zur Programmstrukturierung und Wiederverwendung von Quellcode, kann somit auch in Datenbanken Verwendung finden. Angewandt wird es z. B. für benutzerdefinierbare Operationen in Anfragen. Hauptelement der Erweiterung um abstrakte Datentypen ist die Einführung von Methoden. Dabei handelt es sich um mit bestimmet Datentypen assoziierte Funktionen. In der Praxis werden Methoden verwand um zu Typen dazugehörigen Zugriffs- und Verarbeitungsfunktionen zu definieren. Neben den klassischen einfachen Typen wie Integer mit den Funktionen Addition und Subtraktion kann man nun auch neue Datentypen wie beispielsweise Bild mit den Funktionen Bildanzeigen definieren. Jeder benutzerdefinierte Typ besitzt einen Konstruktor gleichen Namens, mit dem Objekte bzw. Instanzen dieses Typs erzeugt werden können. Durch Aufruf eines Konstruktors wird jedoch nicht nur eine Instanz eines Typen erzeugt, sondern der Konstruktor kann darüber hinaus als benutzerdefinierbare Methode angesehen werden, die bei jeder Erzeugung einer Instanz des Typen aufgerufen wird. Aufgrund dieser Eigenschaft werden Konstruktoren z. B. für die Zuweisung von Initialwerten verwendet. Mit den hier erläuterten Merkmalen erweiterter relationaler Datenbanken ist es also möglich abstrakt Datentypen zu implementieren. Die Unterstützung abstrakter Datentypen ist attraktiv, weil Methoden als Operationen assoziiert mit diesen neuen Datentypen benutzt werden können um Datenmengen z. B. zu indexieren, zu speichern und Anfragen, die auf diese Datentypen basieren, zu realisieren Objektorientierte Erweiterungen Wie bereits erwähnt ist das wichtigste Merkmal von objektrelationalen Datenbanken die Vererbung. Hierbei handelt es sich um ein grundlegendes objektorientierten Konzeptes, welches vor allem dann von Vorteil ist, wenn aus Entity-Relationship-Modellen, Datenbankschemata entwickelt werden sollen. Mit herkömmlichen relationalen Datenbanken kann so etwas nämlich nicht direkt implementiert werden. Mit Vererbung kann man aus einem gebildeten Basistyp wie Per- 10

11 son verschiedene Typen beispielweise Techniker, Manager oder Mitarbeiter ableiten. Die abgeleiteten Typen erben alle Eigenschaften von Person, können aber auch erweiterte spezifische Attribute zugewiesen bekommen, die nur für den Untertyp gelten. Diese Form von Vererbung, also das Vererben von Attributen von Basisklassen an Unterklassen, wird auch Strukturvererbung genannt. Eine Unterklasse erbt aber auch alle Methoden von der darüber liegenden Klasse. Soll eine Methode in einer Unterklasse aber nachträglich gegenüber einer geerbten Methode aus einer Basisklasse verändert werden, so wird dieser Vorgang als Overriding oder Überschreiben bezeichnet. Im objektorientierten Konzept exsistiert lediglich Vererbung auf der Ebene von Typen, die dort Klassen genannt werden. Eine auf Basis dieser Vererbung erzeugte Hierarchie wird Typenhierarchie genannt. Objektrelationale Systeme kennen weitergehend auch Vererbung auf Tabellenebene, bei der eine Tabelle erstellt werden kann, indem sie Attribute einer bereits bestehenden Tabelle übernimmt. Eine solche Tabellenhierarchie wird auch als Relationenhierarchie bezeichnet. Eine weiteres nützliches Merkmal, dass die objektrelationalen von den objektorientierten Datenbanken übernommen haben ist die Objektidentität. Zu jedem Objekt wird automatisch ein systemweit eindeutiger Identifikator erzeugt (OID), der z.b. zur Modellierung von Beziehungen durch Referenzen herangezogen werden kann. Dieser Identifikator bleibt während der Lebenszeit des Objekts unverändert. Wie bereits angedeutet können mit dem OID Referenzen erzeugt werden. Eine Referenz gleicht dem Speichern eines Fremdschlüssels in einer Tabelle und dient dazu auf ein Objekt oder auf ein Tupel in einer Tabelle zu zeigen. Beziehungen können durch Referenzen aber natürlicher dargestellt werden, als durch künstlich eingeführte Fremdschlüsselattribute. Sobald Referenzen vorhanden sind kann zwischen verschiedenen Objekten bzw. Tupeln direkt navigiert werden. Somit werden komplexe Abfragen, die im relationalen Modell Joins über mehrere Tabellen erfordern, u.u. erheblich vereinfacht, wenn die Beziehung durch Referenzen modelliert wird (weniger Tabellen in der from-klausel, besser lesbare Anfragebedingungen). 11

12 3. Beispiele Um ein Eindruck davon zu bekommen wie sich die geschilderten Eigenschaften objektrelationaler Datenbanken letztlich in der Praxis auswirken betrachten wir in diesem Kapitel einige Beispiele die aus [3] mit leichten Abwandlungen entnommen wurden. Der in den Beispielprogrammen verwendete Code entspricht dem Vorschlag eines erweiterten SQL wie er in [3] verwendet wird Strukturen und Mengen Die grundlegendste Erweiterung über die objkektreltionale Datenbanken im Gegensatz zu den relationalen Datenbanken verfügen, ist die Möglichkeit Tabellen mit Attributen zu erstellen, die nicht von einem atomaren Typ wie Ganzzahl (integer) oder ASCII-Zeichen (char) sind. Statt dessen können die Attribute einer Tabelle komplexe Typen wie Menge eines bestimmten Typs (setof) haben oder strukturiert sein, also aus anderen Typen zusammengesetzt sein. Durch diese Eigenschaft ist es sehr viel einfacher von einer gegebene mittels Datenbank zu erfassenden Situation zu einer korrespondierenden Tabelle zu kommen. Ein mögliches Beispiel ist ein einfache Datenbankanwendung für die Verwaltung von Büchern. In einer Tabelle sollen Titel, Autor (bei mehreren Verfassern alle Autoren), Datum (unterteilt in Tag, Monat, Jahr) und eine Stichwortliste gespeichert werden. Dank komplexer Attribute ist das Ganze kein Problem: man kann den intuitiven Ansatz wählen welcher wohl bei den Meisten folgendermaßen aussehen würde: Titel Autoren Datum Stichwortliste Reich und Schön {Crawford, Schiffer} 12, Februar, 2000 {schminken, lächeln} Dick und Doof {Laurel, Hardy} 1, April, 1930 {boing, peng} Hierbei trennen die Kommata in der Spalte Datum die einzelnen Untertypen von einander ab (also ist das Attribut Datum strukturiert) und die geschweiften Klammern symbolisieren Mengen (daraus folgt Autoren und Stichwortliste sind Mengen von Zeichenketten). In objektrelationalem SQL wird diese Tabelle dann so erstellt: create type MyString char varying create type MyDate ( Tag integer, Monat char(10), Jahr integer ) create type Buch ( Titel MyString, Autoren setof(mystring), Datum MyDate, Stichworte setof(mystring) ) create table Buchverwaltung of type Buch 12

13 Mit der ersten Anweisung wird der Typ MyString als eine Zeichenkette mit unbestimmter Länge definiert. Mit der zweiten Anweisung wird der Typ MyDate definiert, und zwar als Struktur mit den Elementen Tag(vom Typ Integer), Monat (Zeichenkette aus maximal 10 Zeichen) und Jahr(ebenfalls Integer). Mit der dritten Anweisung wird letztlich der Typ der Tabelle, also im Sprachgebrauch relationaler Datenbanken das Schema, festgelegt. In der letzten Anweisung wird eine Tabelle des Typs Buch in der Datenbank angelegt. Die Hiermit erstellten Datentypen werden im Metaschema der Datenbank gespeichert und stehen damit allen weiteren auf dieser Datenbank aufsetzenden Applikationen zur Verfügung. Wollte man die zugrundeliegende Aufgabenstellung mittels einer herkömmlichen relationalen Datenbank lösen, so könnte man versucht sein die obigen Daten ebenfalls in einer einzigen Tabelle anzulegen. Dies würde allerdings zu folgendem schaurigen Ergebnis führen: Titel Autoren Tag Monat Jahr Stichworte Reich und Schön Crawford 12 Februar 2000 schminken Reich und Schön Crawford 12 Februar 2000 lächeln Reich und Schön Schiffer 12 Februar 2000 schminken Reich und Schön Schiffer 12 Februar 2000 lächeln Dick und Doof Laurel 1 April 1930 boing Dick und Doof Laurel 1 April 1930 peng Dick und Doof Hardy 1 April 1930 boing Dick und Doof Hardy 1 April 1930 peng Da in einer relationalen Datenbank ein Attribut kein Mengentyp seien kann, kann in den Spalten Autoren und Stichworte nur ein Datenelement gespeichert werden. Somit müssen neue Zeilen erzeugt werden um alle möglichen Kombinationen von Autoren und Stichworte zu speichern. Außerdem wird die Anzahl der Spalten dadurch erhöht, daß keine strukturierten Typen erlaubt sind also für jedes Element von Datum eine eigene Spalte notwendig wird. Die hier auftretenden Redundanzen können dadurch vermieden werden das man die Daten in mehrere Tabellen speichert: Titel Autoren Reich und Schön Crawford Reich und Schön Schiffer Dick und Doof Laurel Dick und Doof Hardy Titel Stichworte Reich und Schön schminken Reich und Schön lächeln Dick und Doof boing Dick und Doof peng Titel Tag Monat Jahr Reich und Schön 12 Februar 2000 Dick und Doof 1 April

14 Der Nachteil dieser Lösung ist ebenfalls offensichtlich: Der Entwurf der Datenbankschemata ist komplizierter geworden und die direkte Beziehung von Objekt (Buch) zum sie beschreibenden Tupel in der Tabelle der Datenbank ist verloren gegangen. Für jedes Buch existieren mehrere Tupel die es beschreiben Hierarchien und Erbungsmechanismen Die grundlegenden Vorteile Objektorientierter Programmiersprachen und Datenbanken sind die Unterstützung von Wiederverwendung bereits erstellten Quellcodes und die Vereinfachung der Modellbildung. Letzteres äußert sich z. B. darin, daß ein zur Objektmodellierung erzeugtes E-R Diagramm ohne weiteres als Datentyp in einer objektorientierten (Datenbank-) Programmiersprache erzeugt werden kann. Eine notwendige Voraussetzung für diese Erleichterung der Objektmodellierung ist die Existenz von Erbungsmechanismen bei der Erzeugung benutzerdefinierter Datentypen. Im Zusammenhang mit der Objektorientierung wird ein Datentyp oder Attribut auch als Klasse bezeichnet. Durch Erben entsteht aus einer Oberklasse eine Unterklasse. Die Unterklasse besitzt alle Eigenschaften der Oberklasse, und kann um weitere Eigenschaften ergänzt werden. Durch Erbungsmechanismen entstehen also Klassenhierarchien. Objektrelationale Datenbanken unterstützen das Erben auf zweierlei Weise. Die klassische Variante funktioniert folgendermaßen: create type Person ( Name MyString, GeburtsDatum MyDate ) create type Fotomodell ( Gehalt integer, Haarfarbe MyString ) under Person create type Schauspieler ( Gehalt integer, Oscars integer ) under Person create type Sportler ( Gehalt integer, ZigarettenProTag integer ) under Person create table BayernMuenchen of type Sportler In diesem Beispiel werden wie aus objektorientierten Programmiersprachen bekannt aus der O- berklasse Person die Unterklassen Fotomodell, Schauspieler und Sportler abgeleitet. In der letzten Anweisung wird in der Datenbank eine Tabelle vom Typ Sportler angelegt. Ein Beispiel für eine solche Tabelle wäre dann: Name GeburtsDatum Gehalt ZigaretteProTag Oliver Kahn 4, April, Mario Basler 5, April,

15 Bei dem Versuch eine Klassenhierarchie in einer erweiterten relationalen Datenbank (eine Datenbank sie zwar erweiterte Typen wie Menge und Struktur kennt aber keine Erbung anbietet) zu speichern, ist man dagegen genötigt zwei Tabellen anzulegen und diese dann mittels Primärschlüssel zu verketten: Name GeburtsDatum Oliver Kahn 4, April, 1969 Mario Basler 5, April, 1969 Name Gehalt ZigaretteProTag Oliver Kahn Mario Basler Neben dem höheren Modellierungsaufwand und dem Verlust der eindeutigen Beziehung zwischen realem Objekt und Tupel in der, die Objektklasse modellierenden, Tabelle, muss man sich bei einer solchen Lösung auch selber um die Wahrung von Datenkonsistenzen bemühen. Durch löschen des Tupels ( Mario Basler, (5, April, 1969) ) in der 1.Tabelle des vorangegangenen Beispiels muss auch, und zwar durch die Datenbankanwendung, sichergestellt werden, daß das Tupel (Mario Basler, , 126) aus der 2.Tabelle gelöscht wird. Eine weitergehende Beschreibung der Probleme, die sich beim Abbilden objektorientierter Daten auf ein rein relationale System ergeben, ist in [4] zu finden. Die bereits angekündigte zweite Art und Weise in der objektrelationale Datenbanken das Erben unterstützen, ist das Erben auf Relationen- oder Tabellenebene. Hierbei wird nicht aus einem bereits bestehenden Datentyp, bzw. objektorientiert gesprochen, aus einer bestehende Klasse ein Unterklasse erzeugt, sondern es wird eine exsistierende Tabelle als Vorlage für eine neue Tabelle benutzt. Wie beim Erben auf Klassenebene besitzt die neu entstandene Tabelle alle Eigenschaften der Vorlagentabelle. Dieses Merkmal objektrelationaler Datenbanken ist ein Vorteil gegenüber objektorientierten Systemen, da hierdurch Mehrfacherbung vermieden und Klassenhierarchien vereinacht werden können. In einem objektorientierten System würde man aufsetzend auf die bereits definierten Klassen Fotomodell, Schauspieler, Sportler eine Klasse für Personen die Schauspieler und Fotomodell sind eine gesonderte Klasse FotomodellSchauspieler erstellen die durch Mehrfacherbung aus Schauspieler und Fotomodell entstanden wäre. Exsistierten darüber hinaus Personen die sowohl Sportler als auch Schauspieler oder Sportler und Fotomodell oder Sportler, Fotomodel und Schauspieler sind, so müsste man die Klassen SportlerFotomodell, SportlerSchauspieler, SportlerFotomodellSchauspieler erstellen. In einer objektrelationalen Datenbank löst man solch eine Konstellation dagegen durch das Erben auf Tabellenebene. Die sich durch Erbung auf dieser Ebene ergebenden Hierarchien sind die in Kapitel 2 angesprochenen Relationen- oder Tabellenhierarchien. In objektrelationalem SQL drückt man Erben auf Tabellenebene dadurch aus, dass man nach der create table Konstruktion keinen Typ, sondern eine bereits bestehende Tabelle mittels des Schlüsselwortes under, als Basistabelle angibt. Bei Verwendung dieser Variante des Erbens sieht das vorangegangene Beispiel folgendermaßen aus: 15

16 create type Person ( Name MyString, GeburtsDatum MyDate ) create table Taugenichtse of type Person create table Fotomodelle ( Gehalt integer, Haarfarbe MyString ) under Taugenichtse create table Schauspieler ( Gehalt integer, Oscars integer ) under Taugenichtse create table Sportler ( Gehalt integer, ZigarettenProTag integer ) under Taugenichtse Statt der vorher notwendigen sieben Tabellen, werden nun nur noch vier benötigt. Eine Person die zugleich Sportler, Schauspieler und Fotomodell ist wird nun in allen vier Tabelle geführt. Damit in den Tabellen Fotomodelle, Schauspieler und Sportler nicht redundant die Attribute der Tabelle Taugenichtse aufführen, werden datenbankintern in den durch Erbung entstandenen Tabellen nur die Primärschlüssel der vererbenden Tabelle gespeichert. Bei Bedarf werden durch eine internen Join die anderen Attribute ermittelt. Für den Fall das Mehrfacherbung ausdrücklich erwünscht ist, wird angestrebt diese in objektrelationalen Systemen ebenfalls zu ermöglichen. Der derzeitige Standard:SQL1999 sieht Mehrfacherbung zwar nicht vor, doch ist dies Gegenstand der derzeitigen Entwicklung: Für den angestrebten zukünftigen Standard SQL:2000 ist Mehrfacherbung eingeplant. 16

17 4. Der neue Standard für objektrelationale Datenbanken SQL:1999 Der lange Zeit unter dem Namen SQL3 entwickelte Standard für objektrelationale Datenbanksprachen ist in 1999 unter dem Namen SQL:1999 verabschiedet worden. Wie im vorangegangenen Kapitel erwähnt, fehlt diesem vor allem noch die Möglichkeit zur Mehrfacherbung, welche erst mit SQL:2000 angestrebt wird. Der Aufbau des SQL:1999-Standards besteht wie folgt aus 9 Teilen: 1. Framework: Dieser Teil beschreibt den Aufbau des Standards 2. Foundation: Die Foundation ist der eigentliche Kern des Standards 3. SQL / CLI: Das Call Level Interface des SQL:1999 Standards 4. SQL / PSM: Dies sind die sog. Persistent Storage Modules 5. SQL / Bindings 6. SQL / Transaction 7. SQL / Temporal 8. SQL / MED: Das Management externer Daten 9. SQL / OLB: Das Object Language Binding, was auch dem SQLJ entspricht Die Neuerungen gegenüber den alten SQL Standards beziehen sich unter anderem auf die neuen vordefinierten Datentypen. Es existieren jetzt u. a. : ein Boolean Typ Large Objects wie Binary Large Objects (BLOB) und Character Large Objects (CLOB), mit denen man nun auch Bild- oder sogar ganze Textdateien im DBS und nicht wie vorher in separaten Dateien verwalten kann Ebenso wurde das Typsystem um die Möglichkeit, der Definition von User-Defined-Types (UDT) unter Verwendung von vordefinierten Typen, konstruierten Typen und vorher definierten User-Defined-Types erweitert. Dieses Erweiterbare Typsystem stellt eine signifikante Verbesserung der Modellierungsfähigkeiten dar. 17

18 Es wurden zahlreiche weitere Fähigkeiten hinzugefügt, wie z.b.: Trigger Rekursion (Rekursive Anfragen) Verbesserte Möglichkeiten, Daten über Sichten (Joins) zu verändern Sprachkonstrukte (Blöcke, Schleifen, Verzweigungen usw.) Verweise über Referenzdatentypen Tabellen-Hierarchien Schema-Evolution bei UDT's und UDF's Komplexe Tabellenstrukturen (Spalten für satz- und arrayartige Werte) Anbindung der neuartigen Datenobjekte an Wirtssprachen (z.b. an Java) Ebenfalls umfasst SQL:1999 eine Erweiterung der Standardbibliotheken um : Typen und Routinen für die Volltextsuche Typen und Routinen für geographische Informationssysteme (GIS) 18

19 5. Vergleich unterschiedlicher Produkte In diesem Kapitel werden unterschiedliche Datenbankprodukte von verschiedenen Herstellern unter die Lupe genommen. Es findet ein Vergleich der Produkte statt und weiterhin wird versucht die Produkte hinsichtlich ihrer objektrelationalen Eigenschaften zu klassifizieren Informix Universal Server Als erstes soll nun der Informix Universal Server genauer betrachtet werden. Der Informix Universal Server stellt ein Beispiel für eine objektrelationale Datenbank dar, die aus Teilen von dem aus dem Postgres weiterentwickeltem Illustra besteht (früher: Miro, Mirage bzw. UniSQL). Informix Universal Server gehört zu der Gruppe der erweiterbaren oder offenen Datenbanksysteme, wie z.b. auch DB2 und Oracle 8. Diese erlauben es neue Datentypen mit ihren Funktionen unter Bewahrung der Kapselung zu definieren und diese auf der internen Ebene zu verankern. Diese Technik wird bei Illustra bzw. Informix Universal Server Data Blades, bei DB2 Database Extenders und bei Oracle 8 Data Cartridges genannt. Die Datenbanksysteme DB2 V2 und Oracle werden zwar aus werbungstechnischen Gründen als objektrelationale Datenbankmanagementsysteme bezeichnet, sind eigentlich jedoch nur eine Vorstufe. Sie zählen zu den objektrelationalen Datenbankmanagementsystemen mit abstrakten Datentypen, da ihnen das Vorhandensein einer Typhierarchie und die Möglichkeiten zur Vererbung von Strukturen und Methoden fehlt, im Gegensatz zu Informix Universal Server, der die Vererbung und die Typhierarchie beherrscht. Da der aktuelle SQL:1999 Standard in 1999 verabschiedet wurde sind bei den Heute verfügbaren objektrelationalen Datenbankmanagementsystemen noch diverse Abweichungen zu erkennen. Das sogenannte CALL-Statement von Informix Universal Server ist im Gegensatz zu dem von DB2/MVS 4.1, DB2/ und DB2 Common Server 2.1 eingesetzten CALL-Statements noch nicht SQL:1999 konform. Bei dem Informix Universal Server umschließt die Erweiterbarkeit über Data Blades (welche von Illustra übernommen wurden) folgende Punkte: benutzerdefinierte Datentypen benutzerdefinierte Routinen benutzerdefinierte Zugriffspfade (Indexstrukturen) 19

20 Weiterhin enthält der Informix Universal Server die bisherigen insgesamt ca. 30 Data Blade Modules, z.b.: Time Series Web Image Text 2D/3D Spatial... Viele SQL:1999-Features wurden bereits integriert, die Kollektionstypen sind umfassender als in SQL:1999 vorgeschrieben und es existieren schon explizite ROW-Typen Oracle 8 Bei Oracle 8 wird die Erweiterbarkeit über Data Cartridges, die jedoch weniger eng integriert wurden als die von Informix Universal Server bekannten Data Blades, unterstützt. Die Erweiterbarkeit umschließt folgende Punkte: benutzerdefinierte Typen benutzerdefinierte Arrays (einfach) geschachtelte Tabellen, die auf typisierte Tabellen (Objekt-Tabellen) und maximal eine Schachtelungsstufe beschränkt sind. Der Zugriff erfolgt über den THE-Operator (flattened subquery). In Oracle 8 ist jedoch noch keine Vererbung möglich und auch keine Typhierarchie IBM DB2 IBM's DB2 bietet eine Mischung aus relationalen und objektorientierten Eigenschaften, bleibt im Kern jedoch relational. Durch diese nach außen hin als Zwitter erscheinende Datenbank ist es möglich, sowohl die auf dem alten relationalen Datenbankmodell basierenden Anwendungen, wie auch die neuen mit objektorientierten Features ausgestatteten Applikationen zu benutzen. 20

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

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

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen Lennart Leist Inhaltsverzeichnis 1 Einführung 2 1.1 Aufgaben einer Datenbank...................... 2 1.2 Geschichtliche Entwicklung

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

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

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

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

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

Themen. M. Duffner: Datenbanksysteme

Themen. M. Duffner: Datenbanksysteme Datenbanksysteme Themen Theorie Einführung Datenbank, Datenbankmanagementsystem (DBMS), Aufgaben eines DBMS Relationale Datenbanken Daten als Tabellen Datenbankentwurf im Entity-Relationship-Modell Abfragesprache

Mehr

Whitepaper Externe Speicherung von Binary Large Objects (BLOBs) mit SharePoint 2007 sowie SQL Server 2005 / 2008

Whitepaper Externe Speicherung von Binary Large Objects (BLOBs) mit SharePoint 2007 sowie SQL Server 2005 / 2008 Externe Speicherung von Binary Large Objects (BLOBs) mit SharePoint 2007 sowie SQL Andreas Glaser, 23. September 2008 Teufenerstrasse 19 CH 9001 St.Gallen t [+41] 71 228 67 77 f [+41] 71 228 67 88 info@namics.com

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

Relationale Datenbanken in der Praxis

Relationale Datenbanken in der Praxis Seite 1 Relationale Datenbanken in der Praxis Inhaltsverzeichnis 1 Datenbank-Design...2 1.1 Entwurf...2 1.2 Beschreibung der Realität...2 1.3 Enitiy-Relationship-Modell (ERM)...3 1.4 Schlüssel...4 1.5

Mehr

Objektrelationale, erweiterbare Datenbanken

Objektrelationale, erweiterbare Datenbanken Objektrelationale, erweiterbare Datenbanken Wintersemester 2003/2004 Vorlesung: Mittwoch, 15:15-17:00 Uhr IFW A32 Übung: Mittwoch, 17:15-18:00 Uhr IFW A32 Dozent: Dr. Can Türker IFW C47.2 Email: WWW: tuerker@inf.ethz.ch

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

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

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

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

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

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

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

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

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

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

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

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

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

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

Einführung in SQL Datenbanken bearbeiten

Einführung in SQL Datenbanken bearbeiten Einführung in SQL Datenbanken bearbeiten Jürgen Thomas Entstanden als Wiki-Buch Bibliografische Information Diese Publikation ist bei der Deutschen Nationalbibliothek registriert. Detaillierte Angaben

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

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

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

4 Vererbung, Polymorphie

4 Vererbung, Polymorphie 4 Vererbung, Polymorphie Jörn Loviscach Versionsstand: 21. März 2014, 22:57 Die nummerierten Felder sind absichtlich leer, zum Ausfüllen beim Ansehen der Videos: http://www.j3l7h.de/videos.html This work

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

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

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

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2 Seminar Cloud Data Management WS09/10 Tabelle1 Tabelle2 1 Einführung DBMS in der Cloud Vergleich verschiedener DBMS Beispiele Microsoft Azure Amazon RDS Amazon EC2 Relational Databases AMIs Was gibt es

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

Carl-Engler-Schule Karlsruhe Datenbank 1 (5)

Carl-Engler-Schule Karlsruhe Datenbank 1 (5) Carl-Engler-Schule Karlsruhe Datenbank 1 (5) Informationen zur Datenbank 1. Definition 1.1 Datenbank-Basis Eine Datenbank-Basis ist eine Sammlung von Informationen über Objekte (z.b Musikstücke, Einwohner,

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

Sructred Query Language

Sructred Query Language Sructred Query Language Michael Dienert 11. November 2010 Inhaltsverzeichnis 1 Ein kurzer Versionsüberblick 1 2 SQL-1 mit einigen Erweiterungen aus SQL-92 2 3 Eine Sprache zur Beschreibung anderer Sprachen

Mehr

Datenbank - Grundlagen

Datenbank - Grundlagen Datenbank - Grundlagen H.-G. Hopf Georg-Simon-Ohm Fachhochschule Nürnberg Datenbank-Grundlagen / 1 Η. G.Hopf / 05.10.2005 Motivation Aufgabe: Ablage und Verwaltung von Informationen in Zusammenhang mit

Mehr

Vorlesung Datenbankmanagementsysteme. Vorlesung Datenbankmanagementsysteme Überblick M. Lange, S. Weise Folie #0-1

Vorlesung Datenbankmanagementsysteme. Vorlesung Datenbankmanagementsysteme Überblick M. Lange, S. Weise Folie #0-1 Vorlesung Datenbankmanagementsysteme Vorlesung Datenbankmanagementsysteme Überblick M. Lange, S. Weise Folie #0-1 Vorlesung Datenbankmanagementsysteme Überblick M. Lange, S. Weise Folie #0-2 Bioinformatik:

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

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

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Definition Informationssystem

Definition Informationssystem Definition Informationssystem Informationssysteme (IS) sind soziotechnische Systeme, die menschliche und maschinelle Komponenten umfassen. Sie unterstützen die Sammlung, Verarbeitung, Bereitstellung, Kommunikation

Mehr

2 7 Erweiterungen. 7.1 Prozess-Kommunikation mit Datenbanken

2 7 Erweiterungen. 7.1 Prozess-Kommunikation mit Datenbanken 2 7 Erweiterungen 7 Erweiterungen 7.1 Prozess-Kommunikation mit Datenbanken Im Buch Einstieg in das Programmieren mit MATLAB wird im Abschnitt 4.8 das Thema Prozess-Kommunikation am Beispiel von MS-Excel

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

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

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

Datenbanken / Datenbankmanagementsystem

Datenbanken / Datenbankmanagementsystem Datenbanken / Datenbankmanagementsystem 1.Einführung Daten, Informationen; Datenbank, Datenbanksystem; Relationale Datenbanksysteme; Beispiel Access 2.Aufbau von Datenbanken Datenanalyse; Entitäten-Beziehungsmodell;

Mehr

Prüfungszeuch im Fach Objektorientierte Programmierung WS 2000

Prüfungszeuch im Fach Objektorientierte Programmierung WS 2000 Prüfungszeuch im Fach Objektorientierte Programmierung WS 2000 A. Beschreibung der Projektarbeit. Welche Aufgabe haben Sie im Rahmen der Projektarbeit gelöst? 2. Mit welchen Tools bzw. Programmen (Anwendung,

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

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

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

SQL-DDL und SQL-Anfragen. CREATE TABLE Kategorie (Bezeichnung VARCHAR(15) NOT NULL PRIMARY KEY, Klassifikationskriterium VARCHAR(100) NOT NULL )

SQL-DDL und SQL-Anfragen. CREATE TABLE Kategorie (Bezeichnung VARCHAR(15) NOT NULL PRIMARY KEY, Klassifikationskriterium VARCHAR(100) NOT NULL ) Technische Universität München WS 2003/04, Fakultät für Informatik Datenbanksysteme I Prof. R. Bayer, Ph.D. Lösungsblatt 6 Dipl.-Inform. Michael Bauer Dr. Gabi Höfling 1.12.2003 SQL-DDL und SQL-Anfragen

Mehr

Java für Computerlinguisten

Java für Computerlinguisten Java für Computerlinguisten 2. Objektorientierte Programmierung Christian Scheible Institut für Maschinelle Sprachverarbeitung 28. Juli 2009 Christian Scheible Java für Computerlinguisten 28. Juli 2009

Mehr

Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015

Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015 Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015 CODESYS a trademark of 3S-Smart Software Solutions GmbH Agenda 1 Warum

Mehr

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

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2008/2009 PIWIN I Kap. 8 Objektorientierte Programmierung - Vererbung 1 PIWIN I Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I Vorlesung 3 SWS WS 2008/2009 FB Informatik

Mehr

Dr. Angelika Reiser Lehrstuhl für Informatik III: Datenbanksysteme TU München / Garching. reiser@in.tum.de

Dr. Angelika Reiser Lehrstuhl für Informatik III: Datenbanksysteme TU München / Garching. reiser@in.tum.de Einführung Dr. Angelika Reiser Lehrstuhl für Informatik III: Datenbanksysteme TU München / Garching reiser@in.tum.de Vorlesung bzw. Vorlesung + Übung Vorlesungswebsite siehe TUMonline-Eintrag http://www-db.in.tum.de/teaching/ws1415/dbsandere/

Mehr

Objektorientiertes Programmieren für Ingenieure

Objektorientiertes Programmieren für Ingenieure Uwe Probst Objektorientiertes Programmieren für Ingenieure Anwendungen und Beispiele in C++ 18 2 Von C zu C++ 2.2.2 Referenzen und Funktionen Referenzen als Funktionsparameter Liefert eine Funktion einen

Mehr

Grundlagen relationaler Datenbanken... 2. Access 2010 - Grundlagenseminar... 3. Access 2010 - Aufbauseminar... 4. Von Excel 2010 zu Access 2010...

Grundlagen relationaler Datenbanken... 2. Access 2010 - Grundlagenseminar... 3. Access 2010 - Aufbauseminar... 4. Von Excel 2010 zu Access 2010... Inhalt Grundlagen relationaler Datenbanken... 2 Access 2010 - Grundlagenseminar... 3 Access 2010 - Aufbauseminar... 4 Von Excel 2010 zu Access 2010... 5 Access 2010 - Programmierung Teil 1... 6 Access

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

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

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

Programmierkurs: Delphi: Einstieg

Programmierkurs: Delphi: Einstieg Seite 1 von 6 Programmierkurs: Delphi: Einstieg Aus Wikibooks Inhaltsverzeichnis 1 Einstieg Einstieg Was ist Delphi Borland Delphi ist eine RAD-Programmierumgebung von Borland. Sie basiert auf der Programmiersprache

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

15 Bilder und Dateien im SQL Server

15 Bilder und Dateien im SQL Server Leseprobe aus Access und SQL Server http://www.acciu.de/asqllesen 15 Bilder und Dateien im SQL Server Eines der großen Probleme von Access-Datenbanken ist der vergleichsweise geringe Speicher platz. Sicher,

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

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

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

Normfall 7.2. Whitepaper. Erstellen eines Normfall Projektspeichers auf Basis einer vorhandenen Installation von:

Normfall 7.2. Whitepaper. Erstellen eines Normfall Projektspeichers auf Basis einer vorhandenen Installation von: Normfall 7.2 Whitepaper Erstellen eines Normfall Projektspeichers auf Basis einer vorhandenen Installation von: Microsoft SQL Server 2008 R2/2012/2014 2014 Normfall GmbH Alle Rechte vorbehalten. Vorbemerkungen

Mehr

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet Ralph Lehmann. Computerservice und IT-Beratung. Kochstraße 34. 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Kochstraße 34 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Tel.:

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

Aufbau einer Oracle Datenbank Tablespace, Arten von Dateien

Aufbau einer Oracle Datenbank Tablespace, Arten von Dateien Aufbau einer Oracle Datenbank Tablespace, Arten von Dateien Boris Meißner 05-INDT Fachbereich Informatik, Mathematik und Naturwissenschaften HTWK-Leipzig 05. Juni 2008 Boris Meißner (Fb IMN - HTWK-Leipzig)

Mehr

Proseminar Website-Management-Systeme ZOPE/CMF. Andreas M. Weiner

Proseminar Website-Management-Systeme ZOPE/CMF. Andreas M. Weiner Proseminar Website-Management-Systeme ZOPE/CMF Andreas M. Weiner Technische Universität Kaiserslautern Fachbereich Informatik Arbeitsgruppe Softwaretechnik Betreuer: Dipl. Inf. Christian Stenzel Überblick

Mehr

Informationsintegration

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

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

Objektrelationale, erweiterbare Datenbanken WS 04/05

Objektrelationale, erweiterbare Datenbanken WS 04/05 Eidgenössische Technische Hochschule Zürich Swiss Federal Institute of Technology Zurich Institut für Informationssysteme Dr.C.Türker Objektrelationale, erweiterbare Datenbanken WS 0405 Übung 8 Aufgabe

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

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

Datenbanken 1. Einführung. Nikolaus Augsten. Sommersemester 2014. nikolaus.augsten@sbg.ac.at. FB Computerwissenschaften Universität Salzburg

Datenbanken 1. Einführung. Nikolaus Augsten. Sommersemester 2014. nikolaus.augsten@sbg.ac.at. FB Computerwissenschaften Universität Salzburg Datenbanken 1 Einführung Nikolaus Augsten nikolaus.augsten@sbg.ac.at FB Computerwissenschaften Universität Salzburg Sommersemester 2014 Augsten (Univ. Salzburg) Datenbanken 1 / Einführung Sommersemester

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

Inhaltsverzeichnis VII

Inhaltsverzeichnis VII Inhaltsverzeichnis 1 Erste Schritte...1 1.1 Einführung...1 1.2 Systemvoraussetzungen...2 1.3 Installation...2 1.3.1 Buch online lesen...3 1.3.2 Installation von Caché...3 1.3.3 Die Buch-Beispiele...4 1.4

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

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

Datenbankstammtisch. Replikation in heterogenen Datenbankumgebungen am Beispiel des Sybase Replication Servers. 1. Februar 2006

Datenbankstammtisch. Replikation in heterogenen Datenbankumgebungen am Beispiel des Sybase Replication Servers. 1. Februar 2006 Datenbankstammtisch Replikation in heterogenen Datenbankumgebungen am Beispiel des Sybase Replication Servers 1. Februar 2006 Autoren: Andreas Reis, Sebastian Mehl Dipl.-Phys. Thomas Richter Gliederung

Mehr

Dokumenten-Modelle im CMS CoreMedia

Dokumenten-Modelle im CMS CoreMedia Dokumenten-Modelle im CMS CoreMedia Einleitung Das Content Management System CoreMedia ist ein innovatives Produkt der Hamburger Firma CoreMedia, das hauptsächlich im Unternehmensbereich und für komplexe

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

2 Was ist VB.NET? 2.1 Unterschiede zu Visual Basic 6

2 Was ist VB.NET? 2.1 Unterschiede zu Visual Basic 6 2 Was ist VB.NET? VB.NET ist eine Programmiersprache basierend auf dem Microsoft.NET- Framework. Das Framework verbindet verschiedene Programmiersprachen. Programme werden zwar in den jeweiligen Programmierspachen

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 2009 Kapitel 3: Datenbanksysteme Vorlesung:

Mehr

Einsatz von UML und C++ am Beispiel einer Satelliten-Lageregelungssoftware

Einsatz von UML und C++ am Beispiel einer Satelliten-Lageregelungssoftware Einsatz von UML und C++ am Beispiel einer Satelliten-Lageregelungssoftware Dipl. Inform. Olaf Maibaum DLR, Abt. Simulations- und Softwaretechnik DLR, Abt. Simulations- und Softwaretechnik 1 Übersicht Bird-Satellit

Mehr

Einführung in das Fach Datenbanken

Einführung in das Fach Datenbanken Einführung in das Fach Datenbanken Holger Jakobs bibjah@bg.bib.de, holger@jakobs.com 2008-03-25 Inhaltsverzeichnis 1 Warum werden Datenbanken eingesetzt? 1 2 Was wird in einer Datenbank gespeichert? 3

Mehr

Probabilistische Datenbanken

Probabilistische Datenbanken Probabilistische Datenbanken Seminar Intelligente Datenbanken AG Intelligente Datenbanken Prof. Dr. Rainer Manthey 26.04.05 Maarten van Hoek - 1 - Inhaltsverzeichnis 1.0 Einleitung...3 2.0 Modell probabilistischer

Mehr

Java Einführung Methoden in Klassen

Java Einführung Methoden in Klassen Java Einführung Methoden in Klassen Lehrziel der Einheit Methoden Signatur (=Deklaration) einer Methode Zugriff/Sichtbarkeit Rückgabewerte Parameter Aufruf von Methoden (Nachrichten) Information Hiding

Mehr

Selbstbestimmtes Lernen. Proinformatik III Objektorientierte Programmierung. Format. Inhalt. Buzzwords

Selbstbestimmtes Lernen. Proinformatik III Objektorientierte Programmierung. Format. Inhalt. Buzzwords 4.0 Proinformatik III Objektorientierte Programmierung Michael Kölling University of Kent Canterbury, UK Selbstbestimmtes Lernen Vorlesung Tutorium Übungen Buch Web-Seite Üben, üben, üben! Format Vorlesung:

Mehr

Configuration Management mit Verbosy 17.04.2013 OSDC 2013. Eric Lippmann www.netways.de

Configuration Management mit Verbosy 17.04.2013 OSDC 2013. Eric Lippmann www.netways.de Configuration Management mit Verbosy 17.04.2013 OSDC 2013 Eric Lippmann Kurzvorstellung NETWAYS Expertise OPEN SOURCE SYSTEMS MANAGEMENT OPEN SOURCE DATA CENTER Monitoring & Reporting Configuration Management

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

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 2013 Kapitel 3: Datenbanksysteme Vorlesung:

Mehr

Datenbanken: Backup und Recovery

Datenbanken: Backup und Recovery Der Prozess der Wiederherstellung der Daten einer Datenbank nach einem Fehler im laufenden Betrieb in einen konsistenten, möglichst verlustfreien Zustand heißt Recovery. Beteiligt an diesem Recovery sind

Mehr