Relationale und Objekt-relationale Datenbanken Daten- und Informationsmodellierung Relationales Datenmodell SQL Objekt-relationale Datenbanken Vorlesung

Relationale und Objekt-relationale Datenbanken

• Daten- und Informationsmodellierung • Relationales Datenmodell

• SQL• Objekt-relationale Datenbanken

Vorlesung “Grundlagen der Datenbanken” von Prof. Dr. Staab und Dr. Sizov

Grundlagen der Datenbanken, WS 08/09 Kapitel 2: Daten- und Informationsmodellierung 1

Prof. Dr. Steffen StaabDr. Dr. Sergej Sizov

ISWeb – Information Systems & Semantic Web

Kapitel 2

Daten- und Informationsmodellierung


Informationsmodellierung

Darstellungselemente + Regeln:- Objekte und Beziehungen (Relationships)- Klassen von Objekten / Beziehungen- Eigenschaften (Attribute)

Informationen über Objekte und Beziehungen nur wenn:- relevant- unterscheidbar und identifizierbar, selektiv beschreibbar

Zusammenhänge

Sachverhalte Gegenstände

Informationen

PersonenTatsachen

Formalisierung

Objekte

Beziehungen

Attribute

Vorgänge, Veränderungen..

" Miniwelt "


Abstraktionskonzepte

Informations- und Datenmodelle basieren auf drei grundlegenden Abstraktionskonzepten:

Klassifikation: fasst Objekte (Entities, Instanzen) mit gemeinsamen Eigenschaften zu einem neuen (Mengen-) Objekt (Entity-Menge, Klasse, Objekttyp) zusammen.– Instanzen/Objekten einer Klasse unterliegen gleicher Struktur (Attribute),

gleichen Integritätsbedingungen, gleichen Operationen– mathematisch: Mengenbildung

Aggregation: Zusammenfassung potentiell unterschiedlicher Teilobjekte (Komponenten) zu neuem Objekt

– mathematisch: Bildung von kartesischen Produkten

Generalisierung: Teilmengenbeziehungen zwischen Elementen verschiedener Klassen– mathematisch: Bildung von Potenzmengen (bzw. Teilmengen)– wesentlich: Vererbung von Eigenschaften an Teilmengen


Entity/Relationship-Modellierung (ERM)

Konzepte:• Entity-Mengen• Beziehungsmengen

(Relationship-Mengen)• Attribute• Wertebereiche• Primärschlüssel• unterstützt die Abstraktionskonzepte

der Klassifikation und Aggregation• graphische Darstellung durch

Diagramme• zahlreiche Erweiterungsvorschläge

entwickelt von P. P. Chen (ACM Transactions on Database Systems 1976)

Studenten

Vorlesungen

hören

VorlNr Titel SWS

MatrNr Name Semester

Hörer

Lehrveranstaltung


Schlüssel

Minimale Menge von identifizierenden Attributen {Matrikelnummer} {Vorname, Nachname, Geburtsdatum, Geburtsort}

Oft künstlicher Schlüssel bestehend aus einem Attribut (Vorlesungsnummer, Kundennummer, Personalausweißnummer,…)

Mehrere Schlüssel möglich; dann Auswahl eines Primärschlüssel

Prof. Dr. Steffen StaabDr. Dr. Sergej Sizov

ISWeb – Information Systems & Semantic Web

Kapitel 3

Grundlagen des relationalen Datenmodells


Relationales Datenmodell

Seien D1, D2, ..., Dn Domänen (~ Wertebereiche)

Relation: R D1 x ... x Dn

Beispiel: Telefonbuch string x string x integer

Tupel: t R

Beispiel: t = („Mickey Mouse“, „Main Street“, 4711)

Schema: legt die Struktur der gespeicherten Daten fest

Beispiel:

Telefonbuch: {[Name: string, Adresse: string, Telefon#:integer]}

Darstellungsmöglichkeit für R: n-spaltige Tabelle(Grad der Relation: n)


TelefonbuchName Straße Telefon#

Mickey Mouse Main Street 4711Minnie Mouse Broadway 94725Donald Duck Broadway 95672

Ausprägung: der aktuelle Zustand der DatenbasisKardinalität: Anzahl der Sätze (Tupel) in der Datenbasis

Schlüssel: minimale Menge von Attributen, deren Werte ein Tupel eindeutig identifizieren

Primärschlüssel: wird unterstrichen

Einer der Schlüsselkandidaten wird als Primärschlüssel ausgewählt

Hat eine besondere Bedeutung bei der Referenzierung von Tupeln


RM: Grundregeln

• Jede Zeile (Tupel) ist eindeutig und beschreibt ein Objekt (Entity) der Miniwelt

• Die Ordnung der Zeilen ist ohne Bedeutung

• Die Ordnung der Spalten ist ohne Bedeutung, da sie eindeutigen Namen (Attributnamen) tragen

• Jeder Datenwert innerhalb einer Relation ist ein atomares Datenelement

• Alle für Benutzer relevanten Informationen sind ausschließlich durch Datenwerte ausgedrückt

Grundlagen der Datenbanken, WS 08/09 Kapitel 3: Grundlagen des Relationalen Modells 11

Assoziationen N:1

1. Verwendung von drei RelationenProfessoren ( PersNr, Name, Rang, Raum )Vorlesungen ( VorlNr, Titel, SWS )lesen ( VorlNr, PersNr )

2. Besser: Verwendung von zwei RelationenProfessoren ( PersNr, Name, Rang, Raum ) Vorlesungen ( VorlNr, Titel, SWS, PersNr )

Regel: Bei n:1 Assoziationen können Relationen mit gleichem Schlüsselzusammengefasst werden - aber nur diese und keine anderen!

lesenProfessoren Vorlesungen

1 *PersNrNameRangRaum

VorlNrTitelSWS


Ausprägung von Professoren und Vorlesungen

Professoren

PersNr Name Rang Raum

2125 Sokrates C4 226

2126 Russel C4 232

2127 Kopernikus C3 310

2133 Popper C3 52

2134 Augustinus C3 309

2136 Curie C4 36

2137 Kant C4 7

Vorlesungen

VorlNr Titel SWS Gelesen Von

5001 Grundzüge 4 2137

5041 Ethik 4 2125

5043 Erkenntnistheorie 3 2126

5049 Mäeutik 2 2125

4052 Logik 4 2125

5052 Wissenschaftstheorie

3 2126

5216 Bioethik 2 2126

5259 Der Wiener Kreis 2 2133

5022 Glaube und Wissen 2 2134

4630 Die 3 Kritiken 4 2137lesen

Professoren Vorlesungen1 *


Vorsicht: So geht es NICHT

Professoren

PersNr Name Rang Raum liest

2125 Sokrates C4 226 5041

2125 Sokrates C4 226 5049

2125 Sokrates C4 226 4052

... ... ... ... ...

2134 Augustinus C3 309 5022

2136 Curie C4 36 ??

Vorlesungen

VorlNr Titel SWS

5001 Grundzüge 4

5041 Ethik 4

5043 Erkenntnistheorie 3

5049 Mäeutik 2

4052 Logik 4

5052 Wissenschaftstheorie

3

5216 Bioethik 2

5259 Der Wiener Kreis 2

5022 Glaube und Wissen 2

4630 Die 3 Kritiken 4

lesenProfessoren Vorlesungen

1 *


Vorsicht: So geht es NICHT: FolgenAnomalien

Update-Anomalie: Was passiert wenn Sokrates umziehtLösch-Anomalie: Was passiert wenn „Glaube und Wissen“ wegfälltEinfügeanomalie: Curie ist neu und liest noch keine Vorlesungen

Professoren

PersNr Name Rang Raum liest

2125 Sokrates C4 226 5041

2125 Sokrates C4 226 5049

2125 Sokrates C4 226 4052

... ... ... ... ...

2134 Augustinus C3 309 5022

2136 Curie C4 36 ??

VorlesungenVorlNr Titel SWS5001 Grundzüge 45041 Ethik 45043 Erkenntnistheorie 35049 Mäeutik 24052 Logik 45052 Wissenschaftstheori

e3

5216 Bioethik 25259 Der Wiener Kreis 25022 Glaube und Wissen 24630 Die 3 Kritiken 4


N:M Assoziationen

Verwendung von drei RelationenStudenten ( MatrNr, Name, Semester )Vorlesungen ( VorlNr, Titel, SWS )hören ( VorlNr, MatrNr )

Regel: Eine n:m-Assoziation muss durch eine eigene Relation dargestellt

werden. Die Primärschlüssel der zugehörigen Klassen treten als Fremdschlüssel auf.

hörenStudenten Vorlesungen

* *MatrNrName

Semester

VorlNrTitelSWS


Ausprägung der Beziehung hören

Studenten

MatrNr ...

26120 ...

27550 ...

... ...

hören

MatrNr VorlNr26120 500127550 500127550 405228106 504128106 505228106 5216

Vorlesungen

VorlNr ...

5001 ...

4052 ...

... ...

hörenStudenten Vorlesungen

* *MatrNrName

Semester

VorlNrTitelSWS


Eine Klasse mit N:M Assoziation

Darstellungsmöglichkeit:

Vorlesung (VorlNr, Titel, SWS)Voraussetzungen (NeueVorlNr, AlteVorlNr, obligatorisch)

Regel: Die n:m-Assoziation muss auch hier durch eine eigene Relation

dargestellt werden. Primärschlüssel der zugehörigen Klasse soll auch als Fremdschlüssel auftreten.

VorlesungVoraussetzungen *

*

obligatorisch VorlNrTitelSWS


Eine Klasse mit 1:1 Assoziation

Darstellungsmöglichkeit:

Person (PNr, Name, Geburtsdatum)Ehe (PNr, Gatte, Seit)

Verwendung von einer Relation:

Person (PNr_Ehemann, Name_Ehemann, GD_Ehemann, PNr_Ehefrau, Name_Ehefrau, GD_Ehefrau, Seit)

Alternative (wie bei N:1 Relationen):

Person (PNr, Name, Geburtsdatum, PNr_Gatte, Seit)

PersonEhe 1

1

Seit PNrName

Geburtsdatum


N-stellige Assoziationen

Professoren ( PersNr, Name, Rang, Raum )Studenten ( MatrNr, Name, Semester )Seminarthemen ( Titel )Belegung ( MatrNr, PersNr, Titel, Vortragsdatum, Raum )

.. weitere Alternativen möglich

Studenten Professoren

Seminarthemen

0..110..*

BelegungVortragsdatum

Raum

MatrNrName

Semester

PersNrNameRangRaum

Titel


Schwache Entitymengen

Schwache Entitäten sind Entitäten, die von einer anderen, übergeordneten Entität abhängig sind.

Sie sind oft nur in Kombination mit dem Schlüssel der übergeordneten Entität eindeutig identifizierbar.

Beziehung zwischen "starkem" und schwachem Typ ist immer 1:* (oder 1:1 in seltenen Fällen)

Warum kann das keine * : * Beziehung sein?

RaumNr ist nur innerhalb eines Gebäudes eindeutigSchlüssel ist: GebNr und RaumNr

Gebäude

GebNrHöhe

Räume

RaumNrGröße


Generalisierung

RM sieht keine Unterstützung der Abstraktionskonzepte vor keine Maßnahmen zur Vererbung

(von Struktur, Integritätsbedingungen, Operationen) „Simulation“ der Generalisierung und Aggregation eingeschränkt möglich

Generalisierungsbeispiel:

Wiss. Mitarbeiter

TV-L Gruppe

Techniker

Beamte

IDName

DiplomSpezialgebiet

Erfahrung

Angestellte

Uni-Angehörige


Generalisierung in RA

Lösungsmöglichkeit 1: vertikale Partitionierung jede Instanz wird entsprechend der Klassenattribute in der IS-A-

Hierarchie zerlegt und in Teilen in den zugehörigen Klassen (Relationen) gespeichert.

nur das ID-Attribut wird dupliziert

Uni-Angehörige (ID, Name)Angestellte (ID, TV_L_Gruppe)Techniker (ID, Erfahrung)WissMA (ID, Diplom, Spezialgebiet)Beamte (ID, … )

Eigenschaften geringfügig erhöhte Speicherungskosten,

aber hohe Aufsuch- und Aktualisierungkosten Integritätsbedingungen: TECHNIKER.ID ANGESTELLTE.ID, usw. Instanzenzugriff erfordert implizite oder explizite Verbundoperationen :: Problembeispiel: Finde alle TECHNIKER-Daten


Generalisierung in RA (1)

Lösungsmöglichkeit 2: horizontale Partitionierung jede Instanz ist genau einmal und vollständig

in ihrer „Hausklasse“ gespeichert. keinerlei Redundanz

Uni-Angehörige (ID, Name)Angestellte (ID, Name, BAT)Techniker (ID, Erfahrung, Name, BAT)WissMA (ID, Diplom, Spezialgebiet, Name, BAT)Beamte (ID, … )

Eigenschaften niedrige Speicherungskosten und keine Änderungsanomalien Eindeutigkeit von ID zwischen Relationen aufwendiger zu überwachen Retrieval kann rekursives Suchen in Unterklassen erfordern. :: Problembeispiel: Finde alle ANGESTELLTE


Generalisierung in RA (3)

Lösungsmöglichkeit 3: volle Redundanz eine Instanz wird wiederholt in jeder Klasse, zu der sie gehört,

gespeichert. sie besitzt dabei die Werte der Attribute, die sie geerbt hat, zusammen

mit den Werten der Attribute der Klasse

Uni-Angehörige (ID, Name)Angestellte (ID, Name, BAT)Techniker (ID, Erfahrung, Name, BAT)WissMA (ID, Diplom, Spezialgebiet, Name, BAT)Beamte (ID, … )

Eigenschaften höherer Speicherplatzbedarf und Auftreten von Änderungsanomalien. einfaches Retrieval, da nur die Zielklasse (z. B. ANGESTELLTE)

aufgesucht werden muss

25

Folgendes Buch liegt der Vorlesung zugrunde:

Alfons Kemper und Andre EicklerOldenbourg Verlag, München, 20066. aktualisierte und erweiterte Auflage

Die Folien wurden weitgehend von den Autoren übernommen.

(Siehe auch http://www.db.fmi.uni-passau.de/publications/books/DBMSeinf )

26

LiteraturA. Kemper , A. Eickler

Datenbanksysteme – Eine Einführung, 6. aktualisierte und erweiterte Auflage. Oldenbourg Verlag, 2006. http://www.db.fmi.uni-passau.de/publications/books/DBMSeinf

A. Silberschatz, H. F. Korth und S. SudarshanDatabase System Concepts, 3. Auflage, McGraw-Hill Book Co., 1997.

R. Elmasri, S.B. Navathe: Fundamentals of Database Systems, Benjamin Cummings, Redwool City, Ca, USA, 2. Auflage, 1994

G. Vossen : Datenmodelle, Datenbanksprachen und Datenbank-Management-Systeme.Addison Wesley, 1994.

http://www.db.fmi.uni-passau.de/publications/books/DBMSeinf/

27

D. Maier: The Theory of Relational Databases. Computer Science Press. 1983.

S. M. Lang, P.C. Lockemann: Datenbankeinsatz. Springer Verlage, 1995.

C. Batini, S. Ceri, S.B. Navathe: Conceptual Database Design, Benjamin Cummings, Redwood City, Ca, USA, 1992.

C. J. Date: An Introduction to Database Systems. McGraw-Hill, 6. Aufl., 1997.

J.D. Ullmann, J. Widom: A First Course in Database Systems, McGraw Hill, 1997.

28

A. Kemper, G. Moerkotte: Object-Oriented Database Management: Applications in Engineering and Computer Science, Prentice Hall, 1994

E. Rahm: Mehrrechner-Datenbanksysteme. Addison-Wesley, 1994.

P. Dadam: Verteilte Datenbanken und Client/Server Systeme. Springer Verlag, 1996



Schwache, existenzabhängige Entities

• Schwache Entitäten sind Entitäten, die von einer anderen, übergeordneten Entität abhängig sind.

• Sie sind oft nur in Kombination mit dem Schlüssel der übergeordneten Entität eindeutig identifizierbar.

Gebäude liegt_in Räume

Höhe GebNr

Größe

RaumNr

1 N


Schwache, existenzabhängige Entities

•Beziehung zwischen "starken" und schwachem Typ ist immer 1:N (oder 1:1 in seltenen Fällen)

•Warum kann das keine N:M-Beziehung sein?

•RaumNr ist nur innerhalb eines Gebäudes eindeutig

•Schlüssel ist: GebNr und RaumNr

Gebäude liegt_in Räume

Höhe GebNr

Größe

RaumNr

1 N


Relationale Modellierung schwacher Entitytypen

Studenten ablegen Prüfungen1 N Note

PrüfTeil

MatrNr

Vorlesungen

umfassen

VorlNr

abhalten

Professoren

PersNr

N N

M M

Prüfungen: {[MatrNr: integer, PrüfTeil: string, Note: integer]}

umfassen: {[MatrNr: integer, PrüfTeil: string, VorlNr: integer]}

abhalten: {[MatrNr: integer, PrüfTeil: string, PersNr: integer]}


Man beachte, dass in diesem Fall der (global eindeutige) Schlüssel der Relation Prüfung nämlich MatrNr und PrüfTeil als Fremdschlüssel in die Relationen umfassen und abhalten übernommen werden muß.

Fremdschlüssel auf ein schwaches Entity


Relationale Modellierung der Generalisierung

Fachgebiet

Assistenten

Professoren

Raum Rang

is_a Angestellte

PersNr Name

Angestellte: {[PersNr, Name]}

Professoren: {[PersNr, Rang, Raum]}

Assistenten: {[PersNr, Fachgebiet]}

Documents

Relationale und Objekt-relationale Datenbanken Daten- und Informationsmodellierung Relationales Datenmodell SQL Objekt-relationale Datenbanken Vorlesung