Relationale Datenbanken und objekt-relationale Abbildung

(1)

8 Datenbanken

Relationale Datenbanken und objekt-relationale Abbildung

Prof. Dr. Heide Balzert Fachbereich Informatik Fachhochschule Dortmund

OM – Datenbanken

LE 14

2

Lernziele

▲

Wissen, was ein Datenbanksystem ist

▲

Unterschiede des relationalen und objektorientierten Modells kennen

▲

Erklären können, was ein relationales Datenbanksystem ist

▲

DDL und DML anwenden können

▲

Ein objektorientiertes Klassendiagramm systematisch auf Tabellen einer

relationalen Datenbank abbilden können

(2)

3

8.1 Was ist ein Datenbanksystem?

8.2 Relationale Datenbanksysteme

8.3 Abbildung des objektorientierten Modells auf Tabellen

LE 14

4

8.1 Was ist ein Datenbanksystem?

▲

Motivation

Verschiedene Programme in einer Organisation (Unternehmen, Behörden) benötigen gemeinsame Daten

Eigene Datenhaltung für jedes Programm bedeutet

Mehrfacherfassungen

Redundante Speicherung

Gefahr inkonsistenter Datenbestände

Datenbanksysteme ermöglichen die integrierte Verwaltung aller Daten in einer Organisation

(3)

5

▲

Architektur eines Datenbanksystems

DBMS (Datenbankmanagementsystem)

DB 1 (Daten- bank) DD

(Data Dictio- nary)

Programm 1 Programm 2 ...Programm n

DBS (Datenbanksystem)

DBn (Daten- bank)

LE 14

6

8.1 Was ist ein Datenbanksystem?

▲

Eigenschaften eines Datenbanksystems

Persistente Speicherung der Daten Zuverlässige Verwaltung der Daten Unabhängige Verwaltung der Daten Komfortable Verwendung der Daten Flexibler Zugang zu den Daten Datenschutz

Verwaltung großer Datenbestände Integrierte Datenbank

Mehrfachbenutzung der Datenbank

(4)

7

▲

Relational vs. objektorientiert

Relationales Datenbanksystem (RDBS)

Dem Datenbanksystem liegt ein relationales Datenmodell zugrunde

Heute das am meisten verwendete Datenmodell

Verwendung einer relationalen Datenbank in vielen objektorientierten Anwendungen

Objekt-relationale Abbildung (object relational mapping) Objektorientiertes Datenbanksystem (ODBS)

Objektorientiertes Datenmodell

Homogene objektorientierte Entwicklung möglich

Alle Objekte der Anwendung lassen sich direkt in der Datenbank speichern

LE 14

8

8.1 Was ist ein Datenbanksystem?

▲

Vergleich von relationalen und

objektorientierten Datenbanksystemen

Objekte der Anwendung

Objekt- relationale Abbildung

Relationale Datenbank

Objektorientierte Datenbank

(5)

9

▲

Tabelle

Relationale Datenbanken speichern Daten in Form von Tabellen (Relationen)

Jede Zeile der Tabelle (Tupel) repräsentiert ein Objekt der Klasse

Alle Tupel einer Tabelle müssen gleich lang sein

Die Reihenfolge der Attribute spielt keine Rolle

Artikel Nummer Bezeichnung Preis

Artikel

Schlüssel

Tupel

Attribut Nummer Bezeichnung Preis

LE 14

10

8.2 Relationale Datenbanken

▲

Schlüsselattribut

Identifizierung eines Tupels durch einen eindeutigen Schlüssel

Schlüssel (oder Primärschlüssel) kann aus einem oder mehreren Attributen bestehen Hinzufügen eines künstlichen

Schlüsselattributs, wenn kein fachliches Attribut als Schlüsselattribut verwendet werden kann

z.B. eine Nummer

Grafische Darstellung einer Tabelle

Schlüssel wird unterstrichen

(6)

11

▲

Schlüssel vs. Objektidentität

Schlüsselattribute ...

unterscheiden sich äußerlich nicht von anderen Attributen

müssen explizit verwaltet werden Objektidentität ...

gehört implizit zu jedem Objekt (object identifier, OID)

LE 14

12

8.2 Relationale Datenbanken

▲

Fremdschlüssel

Realisierung von Assoziationen durch Schlüssel-Fremdschlüssel-Beziehungen

Schlüssel Lieferant

Firma Ansprechpartner

1 *

Lieferant Nummer Firma Ansprechpartner

Artikel Nummer Bezeichnung Preis L-Nummer Fremdschlüssel

(7)

13

▲

Fundamentale Integritätsregeln

Entitäts-Integrität

Schlüsselattribute müssen immer einen Wert besitzen

Referentielle Integrität

Wenn in einer Tabelle ein Fremdschlüssel vorhanden ist, dann muß der

Fremdschlüsselwert auch als Primärschlüsselwert in der

korrespondierenden Tabelle vorkommen

LE 14

14

8.2 Relationale Datenbanken

▲

Normalformen

In der Theorie

5 Normalformen In der Praxis

Daten sind in der ersten, zweiten oder dritten Normalform

Notwendig: Abwägen, »wieviel Normalisierung«

sinnvoll ist

Erste Normalform: Datenredundanz

Dritte Normalform: Schlüsselredundanz

(8)

15

▲

Erste Normalform

Alle Attribute einer Tabelle dürfen keine Wiederholung von Werten (array) und keine internen Datenstrukturen (struct) enthalten Alle Attributwerte müssen von einem

elementaren Typ sein

▲

Im objektorientierten Modell

Normalisierung spielt keine Rolle Bildung von Attributtypen erfolgt

ausschließlich unter problemadäquaten Gesichtspunkten

LE 14

16

8.2 Relationale Datenbanken

▲

Logisches Schema

Menge aller Tabellen bildet die relationale Datenbank

Eintrag der Tabellenstrukturen im Data Dictionary Ablegen aller persistenten Daten in der Datenbank Realisierung der Funktionalität durch die

Anwendungsprogramme

Keine Kapselung von Daten und Funktionen Attribute des logischen Schemas sind für den

Benutzer und die Anwendungsprogramme sichtbar

(9)

17

▲

DDL

Formale Definition des logischen Schemas durch die Datendefinitionssprache (Data Definition Language, DDL)

Standard ist SQL (Structured Query Language) Erzeugung einer Tabelle in SQL durch den create

table-Befehl

Leere Datenbank wird durch Menge aller create table-Befehle erzeugt

Eintrag jeder definierten Tabelle in das Data Dictionary

Löschen einer Tabelle mit dem drop table- Befehl

LE 14

18

8.2 Relationale Datenbanken

Für jedes Attribut sind Name und Typ anzugeben Attributnamen müssen innerhalb einer Tabelle

eindeutig sein

Bezeichnung des Attributs bei

tabellenübergreifender Betrachtung durch Tabelle.Attribut

Schlüssel- und Fremdschlüsselattribute werden in SQL nicht speziell gekennzeichnet

Muß-Attribut

Kennzeichnung eines Attributs mit not null

Attribut muß bereits beim Erzeugen des Tupels einen Wert besitzen

Muß-Assoziation

Fremdschlüssel mitnot null kennzeichnen

(10)

19

▲

Beispiel

create table Lieferant

( Nummer number(5) not null, Firma char(30) not null, Ansprechpartner char(30));

create table Artikel

( Nummer number(5) not null, Bezeichnung char (30) not null, Preis number (8,2),

L_Nummer number (5) not null);

LE 14

20

8.2 Relationale Datenbanken

▲

DML

Füllen und Ändern der Datenbank mit Hilfe der Datenmanipulationssprache (Data Manipulation Language, DML)

Auch hier ist SQL Standard

DML enthält weder Kontrollstrukturen noch Prozedurkonzepte

Erstellung umfangreicher Programme ist problematisch

Sinnvoll ist Kombination der DML mit einer klassischen Programmiersprache (z.B. C++)

(11)

21

▲

Generische Operationen

Semantik ist nicht anwendungsspezifisch insert into Artikel values

(4711, 'Notizblock', null);

update Artikel

set Preis = 4.95 where Nummer = 4711;

delete from Artikel where Nummer = 4711;

LE 14

22

8.2 Relationale Datenbanken

▲

Select-Befehl für flexible Anfragen (queries)

Selektion

Wählt Tupel (Zeilen) aus einer Tabelle aus Projektion

Auswahl bestimmter Spalten einer Tabelle Häufig Kombination von Projektion und Selektion Natürlicher Verbund (natural join)

Verknüpfung von zwei oder mehrere Tabellen über gemeinsame Attribute

(12)

23

▲

Selektion

Ergebnis einer Selektion können alle Zeilen der Tabelle sein

Im allgemeinen werden Tupel nach einer Bedingung gefiltert

Abfragen von Werten oder Überprüfung des Vorhandenseins von Werten

select * from Artikel;

select * from Artikel where Preis >= 100;

select * from Artikel where Preis is null;

LE 14

24

8.2 Relationale Datenbanken

▲

Projektion

Angabe der gewüschten Attribute Angabe von distinct

Keine Erzeugung von Duplikaten von Datensätzen

select distinct Bezeichnung, Preis from Artikel;

select distinct Bezeichnung, Preis from Artikel

where Preis is not null;

(13)

25

▲

Natürlicher Verbund (natural join)

Join-Attribute werden in der Ergebnistabelle nur einmal aufgeführt

select Lieferant.Nummer, Firma,

Bezeichnung, Preis from Lieferant, Artikel

where Artikel.L_Nummer = Lieferant.Nummer;

select Lieferant.Nummer, Firma,

Bezeichnung, Preis from Lieferant, Artikel

where Artikel.L_Nummer =

Lieferant.Nummer and Artikel.Preis < 100;

LE 14

26

8.2 Relationale Datenbanken

▲

Externe Schemata bzw. Sichten (views)

Benutzergruppen oder Anwendungsprogramme sollen oft nur definierte Ausschnitte des logischen Schemas sehen

Ableitung von externen Schemata aus dem logischen Schema

Ablegen der externen Schemata im Data Dictionary Definition einer Sicht bedeutet kein mehrfaches

Ablegen der Daten in der Datenbank

Daten werden bei einer Abfrage neu aufgebaut

Sicherstellen, daß sich jede Sicht (view) stets auf die aktuellen Daten bezieht

(14)

27

▲

Erzeugen einer Sicht in SQL

Ableitung aus einer oder mehreren Basistabellen und vorhandenen Sichten

Löschen der Sichten mit dem drop view-Befehl

Befehl hat keinen Einfluß auf die Originaltabelle create view Billigartikel

as select * from Artikel

where Preis < 100;

create view ArtikelOhnePreis as select Nummer, Bezeichnung

from Artikel;

LE 14

28

8.2 Relationale Datenbanken

▲

Index

Verwendung

Zur Steigerung der Performance

Zur Sicherstellung der Eindeutigkeit von Schlüsselattributen

Datenbanksystem benutzt bei allen Anfragen den jeweiligen Index

Ohne Index durchsucht das DBS eine Tabelle von Anfang bis Ende, um gewünschte Tupel zu finden Daher

Anlegen von Indizes für alle Attribute, die häufig in where-Klauseln von select-Befehlen

auftreten

Anlegen von Indizes für Schlüsselattribute

(15)

29

▲

Beispiele

Index zur Sicherstellung der Eindeutigkeit von Schlüsselattributen

Jede Artikelnummerwird nur einmal vergeben

create unique index Artikelnummer on Artikel(Nummer);

Index zur Steigerung der Performance

Zugriff auf Attribut Firmaoptimieren create index Lieferantenfirmen

on Lieferant(Firma);

▲

Aufgabe 1

▲

Aufgabe 2

LE 14

30

8.3 Abbildung des OOA-Modells auf Tabellen

▲

Objekt-relationale Abbildung

1 Klasse →→→→1 Tabelle 1 Klasse →→→→n Tabellen n Klassen →→→→1 Tabelle

▲

Grafische Notation für Tabellen

Tabelle1 Schlüssel Attribut1 Attribut2

Tabelle2-Schlüssel

Tabelle2 Schlüssel Attribut1 Attribut2 Attribut3

(16)

31

▲

Abbildung einer Klasse auf eine Tabelle

Alle Attribute der Klasse sind vom elementaren Typ

Klasse erfüllt die erste Normalform

Abbildung auf eine einzige Tabelle

Artikel OID Nummer Bezeichnung Preis

Object Identifier

= Schlüssel

LE 14

32

8.3 Abbildung des OOA-Modells auf Tabellen

▲

OID-Attribut

Erweiterung jeder Tabelle um ein OID-Attribut, das die Rolle des Schlüsselattributs spielt OID-Attribute dürfen keinesfalls eine

semantische Bedeutung besitzen

Drei Stufen der Eindeutigkeit beim OID-Attribut

Eindeutigkeit innerhalb einer Tabelle

Eindeutigkeit innerhalb einer Vererbungshierarchie

Eindeutigkeit innerhalb der Datenbank

Bietet größte Flexibilität

Jedes Tupel einer jeden Tabelle in der Datenbank besitzt einen eindeutigen OID-Wert

(17)

33

▲

Realisierung des OID-Attributs

Durch eine sehr große ganze Zahl möglich Bei einige Datenbanken

Automatisches Generieren entsprechender OID-Attribute

Andere Datenbanken

Realisierung der OID-Verwaltung vom Anwendungsprogramm

Einfachster Fall (schlechteste Performance)

Verwendung einer OID-Tabelle, welche jeweils die zuletzt vergebene OID jeder Klasse enthält

Aktualisierung der Tabelle bei Vergabe einer neuen OID

LE 14

34

8.3 Abbildung des OOA-Modells auf Tabellen

▲

Realisierung des OID-Attributs

Steigerung der Performance

Blockweises Anfordern von OIDs durch die Anwendung

Weitere Verbesserung der Performance

high/low-Ansatz

OID besteht aus einem high-Wert und low-Wert

high-Wert: Wird beispielsweise aus einer OID- Tabelle entnommen

low-Wert:

Verwaltung durch die Anwendung Initialisierung mit Null

Inkrementierung, wenn eine neue OID benötigt wird

(18)

35

▲

Abbildung der Attribute

Vor der Abbildung

Überprüfung, welche Attribute einer Klasse persistent sein sollen

Abgeleitete Attribute werden meistens berechnet und sind nicht dauerhaft zu speichern

▲

Einfache Attribute

Attribut einer Klasse wird auf ein Attribut einer Tabelle abgebildet

▲

Strukurierte Attribute

Strukturierte Attribute müssen in Komponenten zerlegt werden, die vom einfachen Typ sind

LE 14

36

8.3 Abbildung des OOA-Modells auf Tabellen

▲

Abbildung einer Klasse mit strukturierten Attributen (elementaren Klassen) auf Tabellen

Kunde Nummer: String Name: NameT Adresse: AdresseT

NameT Vorname Nachname

AdresseT Strasse PLZ Ort

Kunde OID Nummer Vorname Nachname Adresse-OID

Adresse OID Strasse PLZ Ort

(19)

37

▲

Abbildung einer Klasse mit

Listenattributen (elementaren Klasse) auf Tabellen

Student Matrikelnr : String Nachname: String Noten: list of NoteT

NoteT Fach Wert

Student OID

Matrikelnr Nachname Fach 1 Wert 1 Fach 2 Wert 2 Fach 3 Wert 3

Student OID Matrikelnr Nachname

Note OID Fach Wert Student-OID ODER

LE 14

38

8.3 Abbildung des OOA-Modells auf Tabellen

▲

Klassenattribut

Speicherung nur einmal für alle Objekte einer Klasse

Daher

Keine Integration in »normale« Tupel einer Tabelle

Eintrag in eine separate Tabelle

(20)

39

▲

Abbildung einer Assoziation

1:1-Assoziation

Eintrag je nach benötigter Navigation in einer oder beiden Tabellen als Fremdschlüssel

not null – bei Muß-Verbindungen

A a1 a2

B b1 b2 unidirektionale 1:1-Assoziation

1 0..1

A OID a1 a2

B OID b1 b2 A-OID

A a1 a2

B b1 b2 bidirektionale 1:1-Assoziation

1 0..1

A OID a1 a2 B-OID

B OID b1 b2 A-OID

LE 14

40

8.3 Abbildung des OOA-Modells auf Tabellen

▲

Abbildung der 1:m-Assoziation

A a1 a2

B b1 b2

»Verschmelzen« der Assoziation

1

A OID a1 a2

B OID b1 b2 A-OID

A a1 a2

B b1 b2 Eigene Tabelle für Assoziation

1

A OID a1 a2

B OID b1 b2 A-OID

AB A-OID B-OID

*

(21)

41 Verschmelzen der Assoziation mit der Tabelle

Weniger Tabellen

Zugriff auf Objekte erfolgt schneller, weil weniger Tabellen durchlaufen werden Abbilden der Assoziation auf separate Tabelle

Das Wissen, welche Objekte einander kennen, ist nicht mit den Objekten selbst verwoben

Einfache Änderung, wenn aus der 1:m- Assoziation eine m:m-Assoziation wird Kombination aus beiden Möglichkeiten

Vorteil: Reduzierung der Anzahl der joins

Nachteil: Zusätzliche Konsistenzmaßnahmen

LE 14

42

8.3 Abbildung des OOA-Modells auf Tabellen

▲

m:m-Assoziation / Assoziative Klasse

A a1 a2

B b1 b2 1..* *

C c1 c2

B OID b1 b2 A

OID a1 a2

C OID c1 c2 A-OID B-OID

(22)

43

▲

m:m-Assoziation

Immer auf separate Tabelle abbilden

Primärschlüssel dieser Tabelle setzt sich aus den Schlüsseln der beteiligten Tabellen zusammen

Vorteilhaft ist eigenes OID-Attribut für diese Tabelle

Gleichbehandlung aller Tabellen

Vereinfachung der Implementierung

Bessere Laufzeit-Effizienz

Bei einigen Datenbanken können bei joins von Tabellen mit zusammengesetzten Schlüsseln Probleme auftreten

LE 14

44

8.3 Abbildung des OOA-Modells auf Tabellen

▲

Assoziative Klasse

Attribute der assoziativen Klasse werden ebenfalls in eine separate Tabelle eingetragen Auch bei einer 1:1- oder einer 1:m-

Assoziation sollten assoziative Klasse auf eine eigene Tabelle abgebildet werden

Sofern sie nicht nur aus einem oder zwei Attributen bestehen

(23)

45

▲

Abbildung der Komposition

Funktionalität des Ganzen wirkt sich auch auf seine Teile aus

Gleiches gilt für das Speichern und Löschen von Objekten in der Datenbank

Jedes Ganze muß seine Teile kennen Unterschied zwischen einer einfachen

Assoziation und einer Komposition aus Sicht einer Datenbank

Stärkere Kopplung zwischen den beteiligten Objekten bei Komposition

LE 14

46

8.3 Abbildung des OOA-Modells auf Tabellen Vererbungs-

strukturen

B A OID a1 a2 b1 b2 c1 c2

OID a1 a2 b1 b2

C OID a1 a2 c1 c2

A OID a1 a2

B OID b1 b2

C OID c1 c2 A

a1 a2

B b1 b2

C c1 c2

1

2

3

(24)

47

▲

Abbildung der Einfachvererbung

1. Eine Tabelle für gesamte Vererbungshierarchie

Attribute, die ein Tupel nicht annehmen kann, müssen auf nullgesetzt werden

Vorteile

Ad hoc-Anfragen sind einfach Keine joins notwendig

Nachteile

Erhöhung der Kopplung innerhalb der Hierarchie

★ Bei Erweiterung einer Klasse um ein neues Attribut sind alle Objekte davon betroffen Speicherplatzverschwendung

★ Tabelle enthält viele null-Werte

★ Vernachlässigbar bei kleinen Hierarchien

LE 14

48

8.3 Abbildung des OOA-Modells auf Tabellen

▲

Abbildung der Einfachvererbung

2. Eine Tabelle für jede konkrete Klasse

Vorteil

Ad hoc-Anfragen sind relativ einfach Nachteil

Attribute der abstrakten Oberklasse sind in mehreren Tabellen vorhanden

Bei Modifizierung der Attribute sind alle betroffenen Tabellen zu aktualisieren

(25)

49

▲

Abbildung der Einfachvererbung

3. Eine Tabelle für jede Klasse (auch für abstrakte)

Gemeinsames OID-Attributs stellt Identität eines Objekts in der Hierarchie sicher

Vorteile

Entspricht am besten dem objektorientierten Konzept Änderungen in der Oberklasse sind mit minimalem

Aufwand durchführbar

Neue Attribute können in allen Klassen einfach ergänzt werden

Nachteil

Viele Tabellen in der Datenbank

★ Viele joins (langsamer Zugriff)

★ Ad hoc-Anfragen sind schwieriger zu formulieren

LE 14

50

8.3 Abbildung des OOA-Modells auf Tabellen

▲

Vergleich von Abbildungsstrategien der Einfachvererbung

Betrachteter 1Tabelle für 1 Tabelle für 1 Tabelle für Faktor gesamte jede konkrete jede Klasse

Hierarchie Klasse Einfachheit der

Implementierung einfach mittel schwierig Einfachheit des

Datenzugriffs einfach einfach mittel/einfach

Kopplung sehr hoch hoch gering

Geschwindigkeit

des Datenzugriffs schnell schnell mittel/schnell Unterstützung des

Polymorphismus mittel gering hoch

(26)

51

▲

Aufgabe 3

▲

Aufgabe 4

▲

Aufgabe 5

▲

Danke!

▲

Diese Präsentation bzw. Teile dieser Präsentation enthalten Inhalte und Grafiken des Lehrbuchs der

Objektmodellierung von Heide Balzert, Spektrum Akademischer Verlag 1999

LE 14

52

Aufgabe 1 (5 – 10 min)

▲

Unterschiede des relationalen und objektorientierten Modells erkennen

a. Erläutern Sie den Unterschied zwischen dem

Schlüsselattribut einer relationalen Datenbank und der Objektidentität im objektorientierten Modell.

b. Erläutern Sie den Unterschied zwischen einer Assoziation und der Schlüssel-Fremdschlüssel- Beziehung.

c. Erläutern Sie, warum bei einem objektorientierten Modell die erste Normalform nicht eingehalten werden muß.

d. Was ist ein OID-Attribut und welche Vorteile ergeben sich durch dessen Verwendung bei einer relationalen Datenbank? Lösung

(27)

53

▲

Wichtige Begriffe von relationalen Datenbanksystemen kennen

a. logisches Schema b. externes Schema c. DDL

d. DML e. SQL

▲Lösung

LE 14

54

Aufgabe 3 (10 min)

▲

Objekt-relationale Abbildung durchführen

Bilden Sie die folgende Klasse Studentische Hilfskraftauf Tabellen ab

7-stellige Matrikelnummer

Name bestehend aus Vorname und Nachname

Adresse bestehend aus Straße, PLZ und Ort

Liste aller Arbeitsverträge, wobei für jeden Arbeitsvertrag Beginn, Ende und vereinbarte Stundenzahl gespeichert wird

Aktueller Stundenlohn, der für alle studentischen Hilfskräfte gleich ist (Klassenattribut)

Menge der Arbeitsverträge ist unbegrenzt

Stundenlohn wird nur einmal gespeichert Lösung

(28)

55

▲

Objekt-relationale Abbildung durchführen

Lösung

1 *

EK-Preis Lieferfrist

Lagerartikel Mindestmenge Bestand

Artikel Nummer Bezeichnung VK-Preis

Lieferant Name

Adresse:AdresseT Telefon

Lieferkondition *

*

Bestellung Nummer Datum

Position Anzahl

1 *

AdresseT Strasse PLZ Ort

1..*

1

LE 14

56

Aufgabe 5 (15 – 20 min)

▲

DDL und DML (SQL) anwenden können

a. Definieren Sie für die Aufgabe 4 das logische Schema. Gehen Sie davon aus, daß Bestell- und Artikelnummern jeweils eindeutig sind.

b. Erstellen Sie folgendes externe Schema:

Liste aller Artikel, auch der Lagerartikel, die in höchstens einer Woche geliefert werden können.

Das Schema soll enthalten: Artikelnummer,

Artikelbezeichnung, Lieferantenname und EK-Preis für diesen Lieferanten.

(29)

57

c. Formulieren Sie folgende Anfrage:

Benötigt wird eine Liste aller Lagerartikel, bei denen die Mindestmenge unterschritten ist. Die Liste soll enthalten: Nummer, Bezeichnung, Bestand, Mindestmenge.

d. Formulieren Sie folgende Anfrage:

Für jeden Lieferanten ist eine Liste der von ihm gelieferten Artikel mit EK-Preis und Lieferfrist zu erstellen. Die Liste soll folgende Angaben

enthalten: Lieferantenname, Artikelbezeichnung, EK-Preis und Lieferfrist.

▲

Lösung

LE 14

58

Lösung der Aufgabe 1

a. Schlüssel

In jedem Tupel explizit enthalten

Besteht aus einem oder mehreren Attributen Eindeutig innerhalb einer Tabelle

Objektidentität

In jedem Objekt implizit vorhanden

Innerhalb des gesamten Systems eindeutig Besitzt keine semantische Bedeutung b. Assoziation

Im Entwurf wahlweise bi- oder unidirektional Schlüssel-Fremdschlüssel-Beziehung

Fremdschlüssel ist ein Referenz-Attribut Unidirektional

(30)

59

c. Attribute problemadäquat beschrieben, d.h. ein Attribut kann von jedem beliebigen Typ – auch eine Liste variabler Länge – sein.

d. OID-Attribut ist künstliches Attribut, um das jede Tabelle bei der objekt-relationalen Abbildung erweitert wird.

Es besitzt alle Eigenschaften der Objektidentität, ist aber äußerlich von einem fachlichen Attribut nicht zu unterscheiden.

Häufig eine sehr große ganze Zahl, die keinerlei semantische Bedeutung besitzt.

Änderungen im Fachkonzept, z.B. Erweiterung von einer 4- zu einer 6-stelligen Artikelnummer, lassen sich dann problemloser durchführen.

LE 14

60

Lösung der Aufgabe 2

a. Logisches Schema Menge aller Tabellen

Wird im Data Dictionary eingetragen b. Externes Schema

Bestimmte Sicht (view) auf die Datenbank Enthält keine Daten

Unterstützt differenzierte Zugriffe c. DDL (Datendefinitionssprache)

Zur formalen Definition des logischen Schemas.

d. DML (Datenmanipulationssprache)

Stellt Befehle bereit, um die Datenbank mit Daten zu füllen und damit zu arbeiten e. SQL ist der Standard für DDL und DML

(31)

61

Student OID

Matrikelnummer Vorname Nachname Strasse PLZ Ort

StudentK-OID StudentK

OID Stundenlohn

Arbeitsvertrag OID

Beginn Ende Stundenzahl Student-OID

LE 14

62

Lösung der Aufgabe 4

Bestellung OID Nummer Datum Lieferant-OID Lieferant

OID Name Strasse PLZ Ort Telefon

Artikel OID Nummer Bezeichnung VK-Preis Mindestmenge Bestand

Lieferkondition OID

EK-Preis Lieferfrist Lieferant-OID Artikel-OID

Position OID Anzahl Bestellung-OID Artikel-OID

(32)

63

create table Artikel

( OID number(10)not null, Nummer number(7) not null, Bezeichnung char(50) not null, VKPreis number(8,2),

Mindestmenge integer,

Bestand integer );

create table Bestellung

( OID number(10) not null, Nummer number(7) not null,

Datum date,

Lieferant_OID number(10) not null );

LE 14

64

Lösung der Aufgabe 5a

create table Lieferant

( OID number(10) not null, Name char(30) not null, Strasse char(30),

PLZ char(5),

Ort char(50),

Telefon char(20) );

create table Lieferkondition

( OID number(10) not null, EKPreis number(8,2),

Lieferfrist integer,

Artikel_OID number(10) not null,

Lieferant_OID number(10) not null );

(33)

65

create table Position

( OID number(10) not null, Anzahl integer,

Bestellung_OID number(10) not null,

Artikel_OID number(10) not null );

create unique index Artikelnummer on Artikel(Nummer);

create unique index Bestellnummer on Bestellung(Nummer);

LE 14

66

Lösung der Aufgabe 5b

create view Artikelliste as

select Artikel.Nummer, Artikel.Bezeichnung, Lieferant.Name, Lieferkondition.EKPreis from Artikel, Lieferant, Lieferkondition where Lieferant.OID =

Lieferkondition.Lieferant_OID and

Lieferkondition.Artikel_OID = Artikel.OID and Lieferkondition.Lieferfrist <= 1;

(34)

67

c select Nummer, Bezeichnung,Bestand, Mindestmenge

from Artikel

where Bestand is not null and

Mindestmenge is not null and Bestand < Mindestmenge;

d select Lieferant.Name,Artikel.Bezeichnung, Lieferkondition.EKPreis,

Lieferkondition.Lieferfrist

from Artikel, Lieferkondition, Lieferant where

Artikel.OID=Lieferkondition.Artikel_OID and Lieferkondition.Lieferant_OID=Lieferant.OID;