2.4 Semantische Modelle

2.4.1 Semantischer Ansatz Basiselemente Semantischer Datenmodelle:

2.4.1 Der semantische Ansatz

• Entity - unterscheidbares Real World“ Objekt

”

Ebenen des Datenbankentwurfs (Wdh.):

• Property - Eigenschaft, die ein Objekt beschreibt

• konzeptionelle Ebene I logische Gesamtsicht des Anwenders auf die Daten I unabh¨ angig vom eingesetzten DBS-Typ

• Relationship - Zusammenhang zwischen Entities

Semantische Modelle unterschieden sich

• Implementierungsebene I konzeptionelle Datenstrukturen im Rahmen des eingesetzten DBS I bei relationalem DBS z.B. Tabellen • physische Ebene I konkrete Implementierung der Strukturen im Rahmen des eingesetzten DBS I betrachtete Strukturen: Datenbl¨ ocke, Zeiger, Indexstrukturen

• in der Art der unterst¨ utzten Relationships und

den Abstraktionsmechanismen f¨ ur Relationships (z.B. Abh¨angigkeit, Aggregation, Vererbung) • in der Darstellung der Basiselemente und insbesondere

der Relationships, z.B. durch I

I

Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -1-

spezielle Diagrammsymbole und Linien (Entity-Relationship Modell) Darstellung als Funktionen (Funktionales Datenmodell)

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.1 Semantischer Ansatz

Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -3-

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.1 Semantischer Ansatz Auch Relationales Modell hat diese Basiselemente: • Entity: Relation

Semantisches Modell

Hierarchisches Modell

Relationales Modell

konzeptionelle Ebene

• Property: Attribut, Primary Key Constraint

Implementierungsebene

• Relationship: Foreign Key Constraint

Objektrelato− nales Modell

Semantik ist aber unzureichend dargestellt: Schema 1

Semantisches Datenmodell

kunde kdnr# name adresse

• versucht mehr von Daten-Bedeutung (Semantik) zu erfassen modelliert auf konzeptioneller Ebene • unabh¨angig vom eingesetzten Datenbank-System kann in verschiedene DBS-Typen implementiert werden

Hochschule Niederrhein University of Applied Sciences

kd_ansp kdnr# apnr# name telefon

kunde kdnr# name adresse

kd_ansp kdnr apnr# name telefon

• Tabelle kd ansp ist abh¨angig von kunde,

¨ • bei Ubergang zu Implementierungsebene geht Information verloren ⇒ Designschritt nicht reversibel Dalitz: Datenbanksysteme Kap2.4. -2-

Schema 2

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

d.h. repr¨ asentiert eigentlich eine Eigenschaft von Kunde

• Zusammenhang in Schema 1 nur implizit repr¨asentiert (Wodurch?) • diese Bedeutung ist in Schema 2 gar nicht repr¨asentiert Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -4-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.1 Semantischer Ansatz

2.4.2 ER Modell

Vorteile semantischer Modelle

Entity

• intuitiver verst¨andlich (auch f¨ur Nichtexperten!) • leichtere Modellierung durch gr¨oßere N¨ahe zur realen Welt“

• strong (regular) Entity

” Designer wird von Details der DBS entlastet (CASE-Tools)

eigenst¨andiges Objekt; kann unabh¨angig von anderen Objekten existieren

• grafische Notation (Diagramme) anschaulich und (wenn grob vereinfacht) pflichtenhefttauglich“ ”

• weak Entity

abh¨angiges Objekt; kann nur existieren wenn ein Objekt aus anderer Entity existiert

Nachteile semantischer Modelle • Diagramme bei gr¨oßeren Modellen nicht mehr praktikabel • Schritt zu SQL-DDL ist irreversibel ⇒ kein Reverse Engineering“ m¨ oglich ¨ ” ⇒ Anderungen an implementiertem Modell schwierig

strong Entity

• geringe Unterst¨utzung f¨ur Constraints und Tuning-Parameter • Unterscheidung Entity/Relationship oft k¨unstlich

weak Entity

⇒ direkte relationale Modellierung manchmal intuitiver Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -5-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.2 ER Modell

Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -7-

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.2 ER Modell Beispiel

Entity-Relationship (ER) Modell verbreitetstes semantisches Modell

Kunde

• 1976 von Chen vorgeschlagen

angestellt bei

Ansprech− partner

• beinhaltet bestimmte Diagrammnotation (ER Diagramm) • Ansprechpartner ist kein unabh¨angiges Objekt • existiert nur, wenn entsprechender Kunde auch existiert

• ist sp¨ater erweitert worden um Varianten der Vererbung (Spezialisierung, Generalisierung, Kategorien) • Einige Autoren (z.B. Elmasri, Navathe) unterscheiden zwischen der originalen Formulierung von Chen und den Erweiterungen (”extended ER“ bzw. EER”) ”

Bemerkungen: • Es ist oft nicht offensichtlich, ob eine Entity weak“ ist ” z.B. kann im Hersteller/Produkt Beispiel die Entity produkt sowohl als strong, als auch als weak aufgefasst werden (Warum?)

• Erweiterung des ER Modells auf allgemeine Softwareentwicklung (nicht nur DB-Design) in Form von OMT und UML UML (Unified Modelling Language”) benutzt aber andere ” Diagrammsymbole und Begriffe Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -6-

University of Applied Sciences

• ob weak oder strong h¨angt von logischer Sicht auf die Daten ab ⇒ Semantik der Entities wird modelliert Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -8-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.2 ER Modell

2.4.2 ER Modell

Property (Attribut)

Relationship

• atomar, zusammengesetzt

• stellt Zusammenhang zwischen Entities her

Attribute werden durch Blasen dargestellt, zusammengesetzte Attribute (Strukturen) durch Zerlegung in weitere Blasen

• Darstellung durch Raute mit Linien zu beteiligten Entities • Anzahl beteiligter Entities heißt Grad der Relationship

• Schl¨ ussel

Schl¨ usselattribute werden unterstrichen

E3

• mehrwertig (mengenwertig)

mehrwertige Attribute erhalten doppelten Rand E1 Feld1

Attribut

Key

R2

E2

(Grad 3)

Feld2

Struktur

mehrw. Attribut

R1 (Grad 2)

E4

Feld3

Entity

Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -9-

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.2 ER Modell

Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -11-

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.2 ER Modell

Beispiel strasse

name

Relationship kann auch reflexiv sein, d.h. Objekte derselben Entity miteinander verkn¨ upfen:

ort

adresse Mitarbeiter

hnr

branche

Vorgesetzter von

hersteller

Relationship zwischen strong und weak Entity durch doppelten Rahmen gekennzeichnet:

Bemerkungen: • zusammengesetzte und mehrwertige Attribute sind eigentlich u ussig (siehe Diskussion zum Thema 1NF) ¨berfl¨

Kunde

• mehrwertige Attribute machen aber Semantik klarer

angestellt bei

Ansprechpartner

• bei großer Zahl Attribute sind Blasen nicht mehr darstellbar ⇒ als Spaltenvektor darstellen (vgl. UML Klassendiagramm) Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -10-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -12-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.2 ER Modell

2.4.2 ER Modell

Kardinalit¨at einer Relationship

Relationships k¨ onnen auch Attribute haben

• gibt an wieviele Elemente derselben Entity an

Relationship beteiligt sein k¨onnen

Produkt

Lieferant

m

n

• durch Zahlen an Verbindungslinien angegeben

beliefert

Beispiel: Rabatt

Hersteller

1

n

stellt her

k

Produkt

Kunde • 1:n Beziehung zwischen Hersteller:Produkt

Verwischt Grenze zwischen Entity und Relationship Chen spricht von Relationship Relation“ ”

• ein Hersteller stellt mehrere (n) Produkte her • ein Produkt hat einen (1) Hersteller Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -13-

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.2 ER Modell

Hochschule Niederrhein

Faculty of Electrical Engineering and Computer Science

Komplettes Beispiel:

• 1:1 (One-to-One), 1:n (One-to-Many), nr

branche

name

Lieferant

n:m (Many-to-Many). Werte f¨ ur n,m > 0 • Wenn auch kein Element zul¨ assig, explizit Null mit

angeben, z.B. 0,1:1 oder 1:0,n n

1

stellt her

nr

strasse

n

plz

preis Rabatt

nr name

Kunde 1 name

strasse adresse plz

Lieferung

University of Applied Sciences

name

k

0,m

Hochschule Niederrhein

Produkt

beliefert

ort

ausge− liefert

m

n

adresse

Produkt

telefon

Dalitz: Datenbanksysteme Kap2.4. -14-

Elektrotechnik und Informatik

2.4.2 ER Modell

Kardinalit¨atstypen

Hersteller

University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -15-

nr

Ansprechpartner

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

0,n

ange− stellt

ort

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -16-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.3 ER → Relational

2.4.2 ER Modell Zusammenfassung ER-Notationen:

Strong Entities zusammengesetzte und mehrwertige Attribute k¨onnen schon auf der ER-Ebene nach dem Muster der Normalisierung (siehe erste Normalform) umgeformt werden

strong Entity

weak Entity

Relationship

Zuordnung strong/weak Entity

hnr

name

hnr

name ort

Attribut

partieller Schlüssel einer weak Entity

mehrwertiges Attribut

branche

E1 0,n

Schlüssel− attribut

hersteller

E2

1

R

hersteller

0,n hst− branche

adresse

Relationship mit Kardinalitäten

ort

0,m

strasse

branche

Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -17-

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.3 ER → Relational

strasse

nr name

Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -19-

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.3 ER → Relational Weak Entities (1)

Umwandlung ER in Relationales Schema

• eigene Relation • Primary Key = eigene Key Attribute + PK strong Entity ODER eigener k¨ unstlicher Schl¨ ussel (nicht empfohlen (Warum?)) wenn zusammengesetzte Keys unerw¨ unscht sind

Allgemeines Vorgehen • jede Entity wird Relation

Attribute und Primary Key (PK) werden u ¨bernommen • jede Relationship wird Relation Primary Key = alle PK’s beteiligter Entities

name nr

strasse Kunde

ort

1

Feinheiten

ange− stellt

• mehrwertige und zusammengesetzte Attribute • Behandlung von weak Entities

0,n

• nicht alle Relationships brauchen eigene Relation

Ansprechpartner

⇒ abh¨angig von Kardinalit¨at der Relationship nr

• Art der Foreign Key Constraints Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -18-

University of Applied Sciences

name

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

telefon

kunde nr# name strasse ort

ansprechpartner kundenr# nr# name telefon

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -20-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.3 ER → Relational

2.4.3 ER → Relational

Weak Entities (2)

One-To-Many Relationship (1) • 1:n Relationship kann wie n:m Relationship umgesetzt werden

abh¨angige Entity ist an andere strong Entity gebunden ⇒ bei Foreign Key Constraint folgende Optionen n¨otig:

• Unterschied: PK der Entity am 1-Ende“ nicht in PK der

” Relationship-Relation“ mit aufnehmen (Warum?) ”

ON DELETE CASCADE ON UPDATE CASCADE CREATE TABLE kunde ( nr INT8, name VARCHAR(30), strasse VARCHAR(30), ort VARCHAR(30), PRIMARY KEY (nr) );

CREATE TABLE ansprechpartner ( kundenr INT8 REFERENCES kunde(nr) ON DELETE CASCADE ON UPDATE CASCADE, nr INT, name VARCHAR(30), telefon VARCHAR(30), PRIMARY KEY (kundenr, nr) );

nr

name nr# name hersteller Hersteller 1 stellt her n Produkt

• on delete cascade bewirkt L¨ oschung von Ansprechpartner wenn referenzierter Kunde gel¨ oscht wird

nr# name produkt nr

• on update cascade ¨andert Fremdschl¨ ussel in Ansprechpartner mit bei Schl¨ ussel¨anderung des referenzierten Kunden Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -21-

hersteller_produkt herstellernr produktnr#

name

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.3 ER → Relational

Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -23-

Faculty of Electrical Engineering and Computer Science

2.4.3 ER → Relational

Many-To-Many Relationship

One-To-Many Relationship (2)

• n:m Relationships werden eine eigene Relation

• Beobachtung: separate Relation hersteller produkt unn¨ otig

• Primary Key = PK’s aller beteiligten Entities

• Zusammenlegung mit produkt ergibt:

nr

Elektrotechnik und Informatik

nr# name hersteller

name

nr# name hersteller

nr# name kunde Kunde n

...

bezieht

hersteller_produkt herstellernr produktnr#

kunde_produkt kundenr# produktnr# ...

m nr# name produkt

• weniger Relationen • klarere Semantik: Hersteller Eigenschaft von Produkt • Aber: wenn oft kein Hersteller bekannt, vermeidet linke L¨osung NULL-Werte in Foreign Key Feld

name

• Foreign Key Constraints mit on update cascade Option Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -22-

nr# name herstellernr produkt

Vorteile:

Produkt nr

nr# name produkt

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -24-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.3 ER → Relational

2.4.3 ER → Relational

One-To-One Relationship

Zusammenfassung

• auch bei 1:1 Relationship keine eigene Relation n¨ otig • PK einer Entity als Foreign Key in andere Entity aufnehmen nr

name Personal 1

ER Modell Entity

Relation

nr# name personal

einfaches Attribut zusammengesetztes Attribut

Attribut mehrere Attribute

nr# name chefnr abteilung

Schl¨ usselattribut

Primary Key

mehrwertiges Attribut

Relation mit Fremdschl¨ ussel

1:1 oder 1:N Relationship

Fremdschl¨ ussel in Relation auf Seite der h¨ oheren Kardinalit¨at (Alternative: separate Relation)

N:M Relationship

Relation mit zwei Fremdschl¨ usseln

Relationship n-ten Grades

Relation mit n Fremdschl¨ usseln

Chef von 0,1

nr# name chefvon personal

Abteilung nr

nr# name abteilung

name

• obere L¨ osung ist besser (Warum?) • Regel: erweitere Tabelle am 0-Ende“

”

Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -25-

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.3 ER → Relational

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -27-

a

vollst¨andig

• PK beteiligter Relationen als Foreign Keys

b

minimal bzw. redundanzfrei

• PK = PK’s beteiligter Relationen mit Kardinalit¨ at > 1

c

einfach und verst¨andlich

lieferant

beliefert

• Namenskonventionen belieferung lfnr# pdnr# kdnr# rabatt

Rabatt

• Mehrwert (?) von ER versus Relational

kunde

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -26-

• Auswahl des Elements (Entity, Attribut, Relationship) • allgemeines Vorgehen (Top-Down, Bottom-Up)

k Kunde

Faculty of Electrical Engineering and Computer Science

Damit zusammenh¨angende Aspekte

produkt

m

n

Elektrotechnik und Informatik

Anforderungen an Datenmodell

• eigene Relation

Produkt

University of Applied Sciences

2.4.4 Entwurfsfragen

Relationship h¨oheren Grades

Lieferant

Relationales Modell

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -28-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.4 Entwurfsfragen

2.4.4 Entwurfsfragen

Namenskonvention

Wahl des Basiselements

• Namen von Objekten des Modells sollen Bedeutung

Oft gibt es mehrere M¨ oglichkeiten, einen Sachverhalt zu repr¨asentieren

entsprechen ⇒ leichter verst¨andlich • Konventionen erleichtern Verwendung

(leichter merkbar, Fremdschl¨ ussel erkennbar)

a

Attribut versus Entity und Relationship

b

Relationship versus Entity

Alternative a) ist echte Designfrage mit Auswirkungen auf Dateneingabe und Datenkonsistenz.

Beipielkonventionen (1) • Enit¨ aten konsistent im Singular oder Plural.

Alternative b) ist k¨ unstliches Problem im ER Modell

Beides sinnvoll: select * from kunden; select kunde.nr,kunde.name from kunde ...;

u ¨bliche Konvention: Singular • Name von Key und Bedeutung einheitlich, z.B. nr und name Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -29-

• im Relationalen Modell kein Unterschied • ER Modell unterst¨ utzt Foreign Keys nur implizit durch Relationships und weak Entities • neuere Modelle und CASE-Tools erweitern ER um relationale Konzepte ⇒ Unterscheidung Entity/Relationship aufgehoben

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.4 Entwurfsfragen

Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -31-

Faculty of Electrical Engineering and Computer Science

2.4.4 Entwurfsfragen

Beispielkonventionen (2)

Attribut versus Entity + Relationship (1)

• Name Fremdschl¨ usselattribut = referenzierte Tabelle + PK

Betrachte Eigenschaft Branche“ eines Herstellers ” L¨osung 1:

hersteller nr# name branchenr

Elektrotechnik und Informatik

branche nr# name

name nr

branche hersteller

hersteller nr# name

hst_branche hstnr# branche#

• Name Relationship-Relation zusammengesetzt aus Namen der ER Modell

beteiligten Entities; ebenso bei weak Entities Branche n m Anspr.

n

1

Kunde

branche

• Branche als mehrwertiges Attribut modelliert

branche_kunde

• freie Text-Eingabe f¨ ur Branche m¨ oglich

⇒ leichte Eingabe (keine Referenzdatenpflege) ⇒ Auswertung u ¨ber Branche schwierig (z.B. Tippfehler)

kunde kunde_ansp

• Branchen nicht separat pflegbar sondern abh¨ angig von Hersteller

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -30-

Relationales Modell

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -32-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.4 Entwurfsfragen

2.4.4 Entwurfsfragen

Attribut versus Entity + Relationship (2)

Entity versus Relationship (1)

L¨ osung 2:

Betrachte Modellierung eines Schachturniers nr

hersteller

Relationa− les Modell

nr#

name

hersteller

spieler nr# name elozahl

herstellernr# branchenr# hst_branche

nr name

• Relationales Modell ist offensichtlich

name

ER Modell

branche

nr#

name

partie runde# weissnr# schwarznr# ergebnis

branche

• ER Modell ist weniger offensichtlich • Branche als eigene, Hersteller-unabh¨ angige Entity modelliert

I

• keine freie Eingabe m¨ oglich, sondern Auswahlliste

I

⇒ Pflege separater Referenztabelle branche n¨otig ⇒ Auswertungen u ussel m¨oglich ¨ber Branchenschl¨ Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -33-

Ursache: Foreign Keys kennt das ER Modell nicht tauchen nur implizit auf bei Relationship oder weak Entity ⇒ zwei Modellierungsalternativen

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.4 Entwurfsfragen

Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -35-

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.4 Entwurfsfragen

Attribut versus Entity + Relationship (3)

Entity versus Relationship (2)

Alternative besteht nicht nur bei mehrwertigen Attributen, sondern bei allen Attributen

L¨osung 1: nr

n

• Verwende Referenztabelle, wenn Attributwerte nicht beliebig

sind, sondern aus (konfigurierbarer!) Werteliste kommen sollen • Unterschied zu Domain-Constraint (Check-Constraint):

name elozahl

runde trifft auf

Spieler m

ergebnis

Werteliste ¨anderbar ohne Schema¨anderung klausel art Versicherung nr

zahlweise

zahlweise kann über Constraint modelliert werden: Werte 1,2,4,6,12 sind fest Werte tragen Bedeutung für Berechnungen

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -34-

• Partien modelliert als Relationship zwischen zwei Spielern • Probleme: I selbe Begegnung mehrmals m¨ oglich (gel¨ ost u ussel runde) ¨ber zus¨atzlichen Teilschl¨ I Wer hat Weiß, wer Schwarz? (w¨are allerdings bei anderer Sportart egal) I Eigentlich interessierendes Objekt Partie“ taucht gar nicht auf! ”

art und klausel müssen über Referenztabelle modelliert werden

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -36-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.4 Entwurfsfragen

2.4.4 Entwurfsfragen

Entity versus Relationship (3)

allgemeines Vorgehen

L¨ osung 2:

• Top-Down weiß

nr name

n

1 Spieler

elozahl

Partie 1

I

starte mit grobem Entwurf, der zunehmend verfeinert wird (z.B. durch Einf¨ uhrung von Referenztabellen)

I

Erleichtert Verst¨andnis des Systems, da zun¨achst aus der Vogelperspektive“ modelliert wird ”

runde

ergebnis

n schwarz

• Bottom-Up • Partien modelliert als weak Entity, die von

zwei strong Entities abh¨angt (⇒ FK’s gehen in PK ein) • trotz dieses kuriosen Konstrukts angemessener: I Information weiss/schwarz“ dargestellt ” I Partie“ als Hauptgegenstand der Anforderung taucht explizit auf ” Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -37-

arbeite Details aus und f¨ uge sie zu Gesamtsystem zusammen

I

Gesamtverst¨andnis des Systems ist so schwerer zu gewinnen, Gefahr des Verlierens im Detail wegen K¨aferperspektive“ ”

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.4 Entwurfsfragen

Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -39-

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.4 Entwurfsfragen

Entity versus Relationship (4)

In Praxis liefert Anforderungsanalyse meist vor allem Detailwissen ⇒ zun¨achst Bottom-Up Analyse n¨ otig vor Top-Down Design

Interessanterweise f¨ uhren beide ER-L¨osungen zu demselben Relationalen Modell spieler nr# name elozahl

I

Gesamt− überblick

partie runde# spieler1nr# spieler2nr# ergebnis

Top−Down Design

Bottom−Up Analyse

Folgerungen: ¨ • Ubergang ER → Relational ist irreversibel: aus Relationalen Schema l¨asst sich nicht mehr rekonstruieren, aus welchem ER Schema es erzeugt wurde

Datenmodell

Anforderungs− analyse

• Semantik von L¨ osung 1 (beide Spieler gleichwertig)

Abgleich Ergebnis

geht im Relationalen Modell verloren Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -38-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -40-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.4 Entwurfsfragen

2.4.5 Vererbung

M¨ ogliches Top-Down Vorgehen:

Beispiel Fahrzeug

• Modellieren der wesentlichen Entities und Relationships

¨ (zwecks besseren Uberblicks noch keine Attribute) is−a • Erg¨ anzen der Schl¨ usselattribute

PKW

• Modellieren aller Entity-Eigenschaften als (ggf. mehrwertige)

LKW

Motorrad

Attribute • ein Objekt der Entity PKW geh¨ ort auch zur Entity Fahrzeug

• wo Auswahlliste f¨ ur Attributwerte gew¨ unscht, Attribute

• ein Objekt der Entity Fahrzeug kann zugleich zu einer oder

durch Relationships mit Referenztabellen ersetzen

(nicht hier, aber im allg.) auch zu mehreren Subklassen geh¨ oren • wenn ein Attribut von mehreren Entities verwendet wird,

• da IS-A Relationship sich auf genau ein Objekt bezieht, ist es

ebenfalls durch Referenzen auf neue Entity ersetzen (Warum?)

immer eine 1:1 Beziehung ⇒ Kardinalit¨atsangabe unn¨ otig • Subklassen k¨ onnen weitere spezifische Attribute haben

Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -41-

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.5 Vererbung

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -43-

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.5 Vererbung

Oft enth¨alt Entity A Objekte mit speziellen Eigenschaften, die nicht f¨ ur alle Objekte aus A relevant sind. ⇒ definiere special-case Entity B f¨ ur diese Objekte

Vergleich mit Vererbung in C++ ¨ • Ubereinstimmung

• B heißt Subklasse der Superklasse A

I

abgeleitete Klasse erbt alle Eigenschaften der Oberklasse, d.h. Subklasse = Superklasse + spezielle Eigenschaften

I

Objekt der Subklasse kann als Objekt der Superklasse behandelt werden

• Superklasse wird auch Generalisierung genannt,

Subklasse auch Spezialisierung • zwischen B und A besteht IS-A“ Relationship.

” grafische Darstellung dieser Relationship durch Dreieck

• Unterschied

• im allgemeinen mehrere Subklassen zu einer Superklasse

B A

University of Applied Sciences

I

in C++ hat Objekt einen bestimmten Datentyp, d.h. geh¨ort zu genau einer Klasse

I

im ER Modell kann ein Objekt zu einer ganzen Hierarchie von Entites geh¨oren

I

allerdings: in C++ Typumwandlung m¨oglich mittels dynamic cast

is−a C Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -42-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -44-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.5 Vererbung

2.4.5 Vererbung

Spezialisierung einer Superklasse in mehrere Subklassen hat zwei verschiedene Eigenschaften:

Umwandlung in Relationales Modell Betrachte Spezialisierung der Superklasse A(k, a1 , . . . , an ) (k ist der Schl¨ ussel von A) mit m Subklassen B1 , . . . , Bm

• disjunkt oder u ¨berlappend kann ein Element der Superklasse in h¨ochstens einer Subklasse sein, ist die Spezialisierung disjunkt

a1

• total oder partiell muss ein Element der Superklasse in mindestens einer Subklasse sein, ist die Spezialisierung total

...

k

an

A

Da beide Eignschaften voneinander unabh¨angig sind, ergeben sich vier verschiedene Kombinationen

B1

Bm

...

Es gibt vier verschiedene Umwandlungsoptionen Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -45-

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.5 Vererbung

Elektrotechnik und Informatik

Hochschule Niederrhein University of Applied Sciences

Dalitz: Datenbanksysteme Kap2.4. -47-

Faculty of Electrical Engineering and Computer Science

2.4.5 Vererbung Option 1: Fahrzeug

Mensch disjunkt total

Erstelle f¨ ur A die Relation A(k#, a1 , . . . , an ) und f¨ ur jede Subklasse Bi eine Relation mit den Attributen {k#} ∪ {Attribute von Bi }.

disjunkt partiell

k#

Mann

Frau

PKW

a1

...

an

A

LKW B1 k#

Gitarre

b11

... b1k1

Bm

...

Lebewesen überlappend total

überlappend partiell

k# bm1

... bmkm

• erzeugt viele Relationen • geeignet f¨ ur disjunkt und u ¨berlappend

akustisch

elektrisch

Tier

Mensch

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -46-

University of Applied Sciences

• geeignet f¨ ur total und partiell

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -48-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.5 Vererbung

2.4.5 Vererbung

Option 2:

Option 4:

Erstelle f¨ ur jede Subklasse Bi eine Relation mit den Attributen {k#, a1 , . . . , an } ∪ {Attribute von Bi }.

Erstelle eine Relation A mit den Attributen von A, den Attributen aller Subklassen und m boolschen Attributen t1 , . . . , tm , die Flags f¨ ur Subklassenzugeh¨ origkeiten sind.

a1

an

...

b11

... b1k1

B1

A k# a1

...

k#

k#

...

a1

an

bm1

... bmkm

Hochschule Niederrhein University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

2.4.5 Vererbung Option 3: Erstelle eine Relation A mit den Attributen von A, den Attributen aller Subklassen und einem Typ-Attribut t, das die Subklassenzugeh¨origkeit angibt. an

t

b11

... b1k1

...

bm1

... bmkm

A

Typ−Attribut

• erzeugt nur eine einzige Relation • nur geeignet f¨ ur disjunkte Spezialisierung (Warum?) • erzeugt ggf. zahlreiche Nullwerte (Welche?)

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -50-

...

bm1

... bmkm

• wie bei Option 3 ggf. zahlreiche Nullwerte

nicht total ⇒ Objekte nicht in Subklasse nicht speicherbar nicht disjunkt ⇒ Redundanz durch Mehrfachspeicherung

...

... t m b11 ... b1k1

• geeignet f¨ ur u ¨berlappende Spezialisierung

• nur geeignet f¨ ur disjunkte und totale Spezialisierung:

a1

t1

• erzeugt nur eine einzige Relation

• erzeugt eine Relation weniger (die Superklasse)

k#

an

Flags für Subklassenzugehörigkeit

Bm

Dalitz: Datenbanksysteme Kap2.4. -49-

...

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science

Hochschule Niederrhein

Dalitz: Datenbanksysteme Kap2.4. -51-

University of Applied Sciences

Elektrotechnik und Informatik Faculty of Electrical Engineering and Computer Science