II.Datenbankentwurf und Datenbankmodelle · q 1976 von Peter Chen vorgeschlagen q Standardmodell für frühe Entwurfsphasen in der Datenbankentwicklung q mittlerweile existieren viele

Kapitel DB:II

II. Datenbankentwurf und Datenbankmodelleq Entwurfsprozessq Datenbankmodelle

DB:II-1 DB Design and Models © STEIN 2004-2018

EntwurfsprozessANSI/SPARC-Schema-Architektur

externe Ebene

interne Ebene

konzeptuelle Ebene konzeptuelles Schema

internes Schema

externesSchema 1

externesSchema n...

“Usually, a representational [= implementational, logical] data model isused to describe the conceptual schema when a database system isimplemented. This implementation conceptual schema is often basedon a conceptual schema design in a high-level data model.”

[p.30 Elmasri/Navathe 2010]


Bemerkungen zu [p.30 Elmasri/Navathe 2010]:

q Aussage 1: In einem Datenbanksystem wird das konzeptuelle Schema oft durch einimplementierungsnahes Datenmodell wie dem relationalen Datenmodell approximiert.

q Aussage 2: Im Entwurfsprozess entsteht dieses implementierungsnahe Datenmodell aufGrundlage eines semantisch reicheren Modells wie dem ER-Modell oder UML.

q Idealerweise sollte eine Datenbankbeschreibung jedoch direkt auf dem semantisch reicherenModell beruhen, ohne dass eine (manuelle) Transformation in ein implementierungsnahesDatenmodell erfolgen muss.


EntwurfsprozessANSI/SPARC-Schema-Architektur: Entwurfspraxis

konzeptuelles Schema(z.B. auf Basis von ERM)

Modellbildung

high-level data model(semantisch reichhaltig)

Ausschnitt derrealen Welt




Modellbildung



logisches Schema(z.B. Relationen)

representational data model(eher weniger Semantik)




Modellbildung





physisches Schema(Dateien, Indexstrukturen, ...)

Sicht 1 Sicht n...

typische implementierteSchema-Architektur

Praxis




Modellbildung





physisches Schema(Dateien, Indexstrukturen, ...)

Sicht 1 Sicht n...

typische implementierteSchema-Architektur

Praxis

konzeptuelles Schema

internes Schema

externesSchema 1

externesSchema n...

Schema-Architekturnach ANSI/SPARC

Theorie


Entwurfsprozess

Zentrale Anforderung an den Entwurfsprozess ist die Informationserhaltung:

Ü Erhaltung der Fakten

Ü Erhaltung der Beziehungen zwischen den Fakten

Weitere, zum Teil informelle Gütekriterien:

q Redundanzfreiheit

q Vollständigkeit bzgl. der Anforderungsanalyse

q Konsistenz der Beschreibung

q Ausdrucksstärke und Verständlichkeit des benutzten Formalismus

q formale Semantik

q Lesbarkeit der Dokumente

q Unterstützung von Erweiterbarkeit, Modularisierung, Wiederverwendbarkeit,Werkzeugeinsatz


Bemerkungen:

q Die Informationserhaltung bezieht sich auf die Transformation der Modelle ausgehend vonder Anforderungsanalyse hin zur Implementierung:

1. Die Erhaltung der Fakten fordert, dass alle gewünschten Eigenschaften der Objekte desWeltausschnitts auf jeder Abstraktionsstufe vorhanden sind.

2. Die Erhaltung der Beziehungen fordert, dass alle gewünschten Regeln undEinschränkungen (Constraints) des Weltausschnitts auf jeder Abstraktionsstufe abbildbarsind.


Entwurfsprozess


Phasenmodell des Datenbankentwurfs


Anforderungsanalyse(requirements analysis)

Informations-struktur-

anforderungen

Daten-verarbeitungs-anforderungen

konzeptuellerEntwurf

Implementations-bzw. logischer Entwurf

physischerEntwurf

Anforderungsspezifikation

Informationsstruktur

logische Datenbankstruktur

physische Datenbankstruktur

DBMS-Charakteristika

Hardware/BS-Charakteristika

ER-Schema


Bemerkungen:

q Verschiedene Phasen dieses Modells lassen sich weiter aufschlüsseln. Beispielsweisegliedern [Heuer/Saake 2013] den konzeptuellen Entwurf noch in einen Sichtenentwurf, eineSichtenanalyse und eine Sichtenintegration.

q Sollen die Daten auf mehreren Rechnern verteilt vorliegen, muss Art und Weise der verteiltenSpeicherung festgelegt werden. Dies geschieht im sogenannten Verteilungsentwurf, einerEntwurfsphase zwischen konzeptuellem und logischen Entwurf.


EntwurfsprozessPhasenmodell: Anforderungsanalyse

Ziel:

Sammlung des Informationsbedarfs in den verschiedenen Abteilungen bzw.Benutzergruppen.

Ergebnis:

q informelle Beschreibung des Problems bzw. der Aufgabenstellung(User Stories, Use-Cases, Texte, tabellarische Aufstellungen, Formblätter,Maskenentwürfe, etc.)

q Trennen der Informationen über Daten (Datenanalyse) von den Informationenüber Funktionen (Funktionsanalyse)


Bemerkungen:

q Im klassischen Datenbankentwurf wird nur die Datenanalyse einschließlich ihrer Folgeschrittebehandelt; die Funktionsanalyse wird weitgehend ignoriert. Mittelfristig wird sich eineintegrierte objektorientierte Betrachtung von Daten und Funktionen durchsetzen.


EntwurfsprozessPhasenmodell: konzeptueller Entwurf

Ziel:

Formale, semantisch reichhaltige Beschreibung der Aufgabenstellung (der zuspeichernden Daten) in einem abstrakten („high-level“) Datenmodell. Hierfür wirddas Entity-Relationship-Modell am häufigsten eingesetzt.

Vorgehensweise:

1. Modellierung von Sichten (z.B. einer Abteilung oder Benutzergruppe)

2. Analyse der vorliegenden Sichten hinsichtlich von Konflikten:q Namenskonflikt: Homonyme, Synonyme

q Typkonflikt: verschiedene Strukturen für das gleiche Konzept

q Wertebereichskonflikt: keine Vereinheitlichung möglich

q Bedingungskonflikt: verschiedene Sichten fordern eigene Integritätsbedingungen

q Modellierungskonflikt: gleicher Sachverhalt ist unterschiedlich modelliert

3. Integration der Sichten in ein Gesamtschema bzw. ER-Diagramm


Bemerkungen:

q Ein Homonym ist ein Begriff, der für mehrere Konzepte steht. Beispiel: Jaguar

q Synonyme sind verschiedene Begriffe für dasselbe Konzept. Beispiel: {Haus, Gebäude}

q Beispiel für einen Typkonflikt: ein Patient hat aus Sicht der Krankenkasse andereEigenschaften als aus Sicht des Arztes.

q Beispiele für einen Bedingungskonflikt: verschiedene Schlüssel wurden (von verschiedenenBenutzergruppen) für dieselbe Menge von Objekten vorgesehen.


EntwurfsprozessPhasenmodell: Verteilungsentwurf

Ziel:

Festlegung von Art und Weise einer verteilten Speicherung.

Beispiel:

Kunde(KdNr, Name, Adresse, PLZ, Kontostand)

q horizontale Verteilung:Kunde_1(KdNr, Name, Adresse, PLZ, Kontostand)

mit PLZ ≤ 50 000

Kunde_2(KdNr, Name, Adresse, PLZ, Kontostand)

mit PLZ > 50 000

q vertikale Verteilung:Kunde_adr(KdNr, Name, Adresse, PLZ)

Kunde_kto(KdNr, Kontostand)

Zusammenhang kann über das Attribut KdNr hergestellt werden.


EntwurfsprozessPhasenmodell: logischer Entwurf

Ziel:

Umsetzung des konzeptuellen Entwurfs in das Datenmodell des Realisierungs-DBMS, zur Zeit meist das relationale Modell.

Vorgehensweise:

1. teilweise automatische Transformation des konzeptuellen Schemas, z.B. desEntity-Relationship-Modells in das relationale Modell

2. Verbesserung des relationalen Schemas anhand von Gütekriterien durchentsprechende Normalisierungsalgorithmen. Stichwort: Normalformen

Ergebnis:

Ein logisches (relationales) Datenbankschema, das Datenredundanzen„weitgehend“ vermeidet und die Konsistenzbedingungen des Entity-Relationship-Modells „weitgehend“ erhält.


EntwurfsprozessPhasenmodell: physischer Entwurf

Ziel:

Effizienzsteigerung ohne die logische Struktur der Daten zu verändern.

Konzepte:

„Tuning“ der Abbildung der Relationen auf den Sekundärspeicher:

q Definition von Indexstrukturen, die direkten (assoziativen) Zugriff auf alleTupel einer Relation mit bestimmten Attributwerten erlauben.

q Clusteranalyse zur Gruppierung von Daten im Sekundärspeicher, so dasszusammen benötigte Daten auf denselben Seiten liegen. Typischinsbesondere bei objektorientierten DBMS.


Bemerkungen [Schuerr 2001]:

q Kritik an dieser Vorgehensweise aus Sicht der Softwaretechnik:

– es handelt sich um das überholte Wasserfallmodell der Softwaretechnik– Rückgriffe von einer Phase zu vorgehenden Phasen fehlen– Testaktivitäten sind nicht explizit aufgeführt– Wartung mit Aktivitäten aus allen Phasen ist unstrukturiert– inkrementelle bzw. schrittweise Realisierung eines DBS wird nicht unterstützt– Modellierung der Funktionen bleibt nahezu unberücksichtigt– Verzahnung mit Entwicklung sonstiger Teile eines Informationssystems fehlen

q Bessere Vorgehensweise:

– objektorientierter Entwurf für das gesamte Informationssystem– Abbildung von Klassendiagrammen (statt ER-Diagrammen) auf Relationen– Verwendung moderner(er) Vorgehensmodelle der Softwaretechnik


DatenbankmodelleDefinition 1 (Datenmodell)

Datenmodelle dienen zur Erfassung und Darstellung der Informationsstruktur füreine Anwendung oder einen Anwendungsbereich.


DatenbankmodelleDefinition 1 (Datenmodell)

Datenmodelle dienen zur Erfassung und Darstellung der Informationsstruktur füreine Anwendung oder einen Anwendungsbereich.

Beispiele:

q Typsysteme in Programmiersprachen

q Formalismen zur Wissensrepräsentation in Expertensystemen(Frames, Regeln, logische Formeln)

q Repräsentationsmodelle in Graphiksystemen (BRep, CSG)

q SPO-Tripel im Resource Description Framework des Semantic Web

q Datenbankmodelle in Datenbanksystemen(hierarchisches Modell, Relationenmodell, Entity-Relationship-Modell)

Datenmodell für Datenbanksysteme = Datenbankmodell


DatenbankmodelleDefinition 2 (Datenbankmodell, Datenbankschema [Heuer/Saake 2013])

Ein Datenbankmodell ist ein System von Konzepten zur Beschreibung vonDatenbanken. Es legt Syntax und Semantik von Datenbankbeschreibungen für einDatenbanksystem fest.

Eine konkrete Datenbankbeschreibung wird Datenbankschema genannt.


DatenbankmodelleDefinition 2 (Datenbankmodell, Datenbankschema [Heuer/Saake 2013])

Ein Datenbankmodell ist ein System von Konzepten zur Beschreibung vonDatenbanken. Es legt Syntax und Semantik von Datenbankbeschreibungen für einDatenbanksystem fest.

Eine konkrete Datenbankbeschreibung wird Datenbankschema genannt.

Gegenüberstellung zu Programmiersprachen:

Datenbank Programmiersprache

Datenbankmodell TypsystemRelation, Attribut, . . . class, int, String, . . .

Datenbankschema VariablendeklarationKunde(KdNr, Name, ...) class Kunde{int KdNr; String Name;}

Datenbank, DB Werte(2305, ”Meier”, ...) 2305, ”Meier”

Datenbankmanagementsystem DBMS Entwicklungs- und Laufzeitumgebung

Datenbanksystem DBS = DB + DBMS Programm zur Laufzeit


DatenbankmodelleHistorie

ab Mitte 1960

1970

1980

1990

2000

hierarchisches Modell

Netzwerkmodell

relationalesModell

objektorientiertesDatenmodell

objektrelationalesDatenmodell

objektorientierteEntwurfsmodelle

erweiterteER-Modelle

Entity-Relationship-Modell

NF2-Modell

[Heuer/Saake 2000]

implementierungsnah abstrakt


DatenbankmodelleDatenbankschema

Das Datenbankschema einer Datenbank definiert für eine Anwendung:

1. statische Eigenschaften

(a) identifizierbare Objekte (Basisdatentypen)(b) Beziehungen zwischen Objekten(c) Attribute von Objekten und Beziehungen

2. dynamische Eigenschaften

(a) Operationen auf Daten(b) Abfolge und Koordination von Operationen

3. Integritätsbedingungen

(a) an Objekte(b) an Operationen


Bemerkungen:

q Beispiel für eine statische Eigenschaft: Sportler haben eine Nationalität.

q Beispiel für eine dynamische Eigenschaft: Ein Auto muss zugelassen werden, bevor man esfahren darf.

q Beispiel für eine Integritätsbedingung für Objekte: Studierende haben unterschiedlicheMatrikelnummern. (Schlüsselbedingung)

q Beispiel für eine Integritätsbedingung für Operationen: Bei einer Gehaltsänderung darf dasGehalt nur steigen. (Übergangsbedingung)


DatenbankmodelleDatenbankzustand

Ein Datenbankzustand ist der zu einem Zeitpunkt t gültige bzw. gespeicherteZustand aller Objekte und ihren Beziehungen und muss den im Datenbankschemafestgelegten Strukturbeschreibungen gehorchen.

Buch

Inv_Nr Titel ISBN Autor

0110 Lesebuch 2-341... Popper4711 Glücksformel 2-679... Klein

Buch



Zeit

state1

state2

state0

Buch



7510 Heuristics 9-212... Pearl


Bemerkungen:

q Typischerweise ändert sich ein Datenbankschema selten; der Datenbankzustand istGegenstand laufender Modifikationen. Beispiel Flugbuchungssystem: Jede Reservierungentspricht einer Änderung des Datenbankzustands.

q Ein Datenbanksystem kann als kontinuierlich laufender Prozess aufgefasst werden, dessenjeweils aktueller Zustand state den Inhalt der Datenbank (Datenbasis) festlegt. Eine formaleDefinition der Semantik dieses Prozesses lässt sich durch eine lineare Folge von Zuständenmodellieren, wobei die Zustandsübergänge den Änderungen der Datenbankinhalteentsprechen.


Kapitel DB:III

III. Konzeptueller Datenbankentwurfq Einführung in das Entity-Relationship-Modellq ER-Konzepte und ihre Semantikq Charakterisierung von Beziehungstypenq Existenzabhängige Entity-Typenq Abstraktionskonzepteq Konsolidierung, Sichtenintegrationq Konzeptuelle Modellierung mit UML

DB:III-1 Conceptual Design © STEIN 2004-2018

Einführung in das Entity-Relationship-ModellHistorie:

q Entity-Relationship-Modell kurz: ER-Modell bzw. ERM

q 1976 von Peter Chen vorgeschlagen

q Standardmodell für frühe Entwurfsphasen in der Datenbankentwicklung

q mittlerweile existieren viele Varianten und Erweiterungen

q eingesetzt auch in anderen Bereichen der Informatik

Eigenschaften:

q unabhängig von einem bestimmten Datenbanksystem

q Grundkonzepte „Entity“ und „Relationship“ werden als natürlich und – trotzihrer Einfachheit – als ausreichend für viele Situationen empfunden

q unterstützt die drei wichtigsten Abstraktionsmechanismen:Klassifikation, Aggregation, Verallgemeinerung

q starre Informationsstruktur, d. h., Ausrichtung auf große Datenmengen

q Definition von statischen Eigenschaften und Integritätsbedingungen


Einführung in das Entity-Relationship-ModellElemente

1. Entity(-Instanz)Ein Objekt oder Ding (Entity) der realen oder einer virtuellen Welt, für dasInformationen zu speichern sind. Jedes Entity ist von einem bestimmtenEntity-Typ.

2. Beziehung(sinstanz)Ein n-Tupel mit Entities. Jede Beziehung (Relationship) ist von einembestimmten Beziehungstyp. Beziehungen zwischen Entities derselben Typengehören zu demselben Beziehungstyp.

3. AttributDefiniert eine Eigenschaft von Entity-Typen oder Beziehungstypen.

4. RolleDokumentiert die Rolle eines Entities in einer Beziehung.


Einführung in das Entity-Relationship-ModellDie Beschreibung der Informationsstruktur eines Anwendungsbereichs im Entity-Relationship-Modell heißt Entity-Relationship-Diagramm (ER-Diagramm) oderEntity-Relationship-Schema (ER-Schema).

" Ein Professor liest eine Vorlesung "




liest VorlesungProfessor





" Eine Vorlesung hat einen Zeitplan und einen Titel "






TitelZeitplan






TitelZeitplan

in einem Semester "






TitelZeitplan

in einem Semester "

Semester




TitelZeitplan

Semester

Buch

empfiehlt

Autor

Titel

ISBN

Name

Fach

Telefon


ER-Konzepte und ihre SemantikDatentypen

Datentypen, hier insbesondere Entity-, Beziehungs- und Attributtypen, dienen zurDefinition von Wertebereichen. Ein Datentyp X ist gekennzeichnet durch:

1. dom(X) Domain, Definitionsbereich.Die möglichen Werte, die ein Objekt vom Typ X annehmen kann.

2. Operationen, Funktionen, Prädikate, die für die Bearbeitung von Werten undfür Aussagen über Werte zur Verfügung stehen.

3. state(X) Zustand.Alle zu einem bestimmten Zeitpunkt bekannten Werte vom Typ X.


ER-Konzepte und ihre SemantikDatentypen

Datentypen, hier insbesondere Entity-, Beziehungs- und Attributtypen, dienen zurDefinition von Wertebereichen. Ein Datentyp X ist gekennzeichnet durch:

1. dom(X) Domain, Definitionsbereich.Die möglichen Werte, die ein Objekt vom Typ X annehmen kann.

2. Operationen, Funktionen, Prädikate, die für die Bearbeitung von Werten undfür Aussagen über Werte zur Verfügung stehen.

3. state(X) Zustand.Alle zu einem bestimmten Zeitpunkt bekannten Werte vom Typ X.

Beispiele:

q abstrakter Datentyp Integer.dom(Integer) = Z mit Operationen + − ∗ / < > =

q abstrakter Datentyp String.dom(String) = Σ∗ für ein Alphabet Σ mit Operationen + length


Bemerkungen:

q Die Operationen auf einem Datentyp sind hier nur informell genannt. Implementierungen vonDatenbanken verwenden hauptsächlich aus Programmiersprachen bekannte, primitiveDatentypen sowie Nicht-Standard-Datentypen wie Date und Time. Operationen über diesenDatentypen werden teilweise in der Anfragesprache, die ein DBMS unterstützt, zur Verfügunggestellt.

q Der Zustand eines Datentyps ist üblicherweise nicht Teil der Definition eines Datentyps. Erdient hier als Hilfsmittel, den Zustand einer Datenbank ermitteln zu können.


ER-Konzepte und ihre SemantikEntity-Typen

Ein Entity-Typ deklariert eine Menge von Objekten mit bestimmten Eigenschaften,die (in der Datenbank) repräsentiert werden sollen. Graphische Darstellung:

Entity-Typ

Bezeichner für Entity-Typen sind E,E1, E2, ... oder wie im Beispiel Professor,Vorlesung und Buch.

dom(E):

Menge der möglichen Entities (Objekte) vom Typ E. Diese Menge wird meist nichtexplizit festgelegt, sondern als genügend groß, z.B. isomorph zu N angenommen.Man kann dom(E) als die Menge der Namen der Entities auffassen.


ER-Konzepte und ihre SemantikEntity-Typen (Fortsetzung)

state(E):

Menge der aktuellen Entities vom Typ E im::::::::::::Zustand

:::::::::state

::::::der

:::::::::::::::::Datenbank. Durch

Operationen auf der Datenbank kann sich state(E) verändern. Insbesondere gilt:

q state(E) ⊆ dom(E)

q state(E) ist endlich

Die Anzahl der zum Typ E gespeicherten Entities kann beliebig sein, ist aberin jedem Zustand state endlich.

Beispiel:

q Entity-Typ Professor

q dom(Professor ) = Σ∗ mit Σ = {A, . . . , Z, a, . . . , z}

q state(Professor ) = {Froehlich,Lucks,Wuethrich}


https://webis.de/downloads/lecturenotes/databases/unit-de-design-and-models.pdf#db-sequence

ER-Konzepte und ihre SemantikBeziehungstypen

Ein Beziehungstyp deklariert eine Beziehung zwischen Entity-Typen. Es kann einebeliebige Anzahl n≥2 von Entity-Typen an einem Beziehungstyp teilhaben.Graphische Darstellung:

Beziehungstyp

E1 Ei En... ...

Bezeichner für Beziehungstypen sind R,R1, R2, . . ., oder wie im Beispiel empfiehltund liest.

dom(R):

Menge der möglichen Beziehungen (Entity-Tupel) vom Typ R zwischen Entities derTypen E1, . . . , En.

dom(R) = dom(E1)× . . .× dom(En)


ER-Konzepte und ihre SemantikBeziehungstypen (Fortsetzung)

state(R):

Menge der aktuellen Beziehungen vom Typ R im:::::::::::::Zustand

::::::::state

::::::der

::::::::::::::::::Datenbank.

Durch Operationen auf der Datenbank kann sich state(R) verändern.

state(R) ⊆ state(E1)× . . .× state(En)

Schreibweise:R(E1, . . . , En)

Beispiel:

q Beziehungstyp liest

q state(Professor ) = {Froehlich,Lucks,Wuethrich}

q state(Vorlesung) = {Algorithmen,Computergrafik,Kryptographie,HCI,DB}

q state(liest) = {(Wuethrich,Algorithmen), (Lucks,Kryptographie)}



ER-Konzepte und ihre SemantikBeziehungstypen (Fortsetzung)

Sind einzelne Entity-Typen mehrfach in einem Beziehungstyp eingebunden, legenRollenbezeichner die Rollen der beteiligten Objekte in der Beziehung fest. Mannennt solche Beziehungstypen reflexiv.

Beispiel:verheiratet(Frau : Person,Mann : Person)

verheiratet

Person

Frau

Mann


Bemerkungen:

q In der textuellen Notation sind Rollenbezeichner nicht erforderlich: die Rolle kann über diePosition im Argumentetupel (Signatur) festgelegt werden: verheiratet(Person,Person)

q In der graphischen Darstellung sind Rollenbezeichner erforderlich.

q In der Datenbankliteratur werden reflexive Beziehungstypen mitunter auch rekursiveBeziehungstypen genannt.


ER-Konzepte und ihre SemantikAttribute und Attributtypen

Ein Attribut definiert eine Eigenschaft für alle Instanzen eines Entity-Typs oderBeziehungstyps. Ein Attribut kann deshalb als Funktion verstanden werden, diejeder Instanz eine Eigenschaftsausprägung zuordnet. Graphische Darstellung:

A : T

E

A : T

R

Bezeichner für Attribute sind A,A1, A2, . . . oder wie im Beispiel Name, ISBN, Titeloder Semester.

Der Attributtyp T bezeichnet den Typ der Eigenschaft und ist üblicherweise einStandard-Datentyp wie Integer oder String.

dom(T ):

Menge der möglichen Werte des Attributtyps T .


Bemerkungen:

q Nicht-Standard-Datentypen für Attribute sind

– von DBMS zur Verfügung gestellte Datentypen wie Date, Time, Timestamp, Blob.

– Potenzmengen von Attributtypen für mehrwertige Attribute. Beispiel: Attribut Titel vomAttributtyp P(dom(T )) für dom(T ) = {Prof., Dr., MSc, BSc, Dipl.-Inform., . . .}.

– (hierarchische) Kompositionen von Standard-Datentypen. Beispiel: Attribut Adresse vomgleichnamigen Attributtyp Adresse, das Adressbestandteile vom Typ String undInteger zusammenfasst.


ER-Konzepte und ihre SemantikAttribute von Entity-Typen

dom(A):

Menge der möglichen Abbildungen von dom(E) nach dom(T ).

state(A):

Eine Abbildung state(E)→ dom(T ) im Zustand state der Datenbank, die jedemaktuellen Entity aus state(E) einen Wert aus dom(T ) zuordnet.

Schreibweise (Entity-Typ mit Attributen A1, . . . , An):

E(A1 : T1, . . . , An : Tn) bzw. E(A1, . . . , An)

Beispiel: ; TAFEL


Bemerkungen:

q Modellierungstechnisch gibt es zwei Blickwinkel, unter denen Attribute betrachtet werden.dom(A) und dom(T ) spiegeln diese Unterscheidung wider:

1. Aus Sicht des ER-Modells.Hier wird ein Attribut als eine Abbildung über dem Wertebereich eines Entity-Typs bzw.Beziehungstyps aufgefasst. dom(A) ist die Menge der möglichen Abbildungen.Diese Sichtweise ist durch die Operationen auf der Datenbank motiviert: Zu jedemZeitpunkt t ist der Zustand der Datenbank durch die Attribute (= den entsprechendenAbbildungen) festgelegt. [

::::::DB:II

::::::::::::::::::::Datenbankmodelle

::»:::::::::::::::::::::Datenbankzustand]

Beispiel: Zum Zeitpunkt t ordnet Attribut ISBN jedem Buch eine ganze Zahl zu.

2. Aus Sicht des relationalen Modells.Hier wird ein Attribut lediglich als Bezeichner des Datentyps einer Eigenschaftverstanden. dom(A) im relationalen Modell ist die Menge der möglichen Attributwerteund entspricht der Menge dom(T ) im ER-Modell. [

:::::::DB:IV

:::::Das

::::::::::::Relationale

::::::::Modell]

Beispiel: Das Attribut ISBN ist vom Typ „ganze Zahl“.



https://webis.de/downloads/lecturenotes/databases/unit-de-relational-design1.pdf#definition-relation-scheme

ER-Konzepte und ihre SemantikAttribute von Beziehungstypen

dom(A):

Menge der möglichen Abbildungen von dom(R) nach dom(T ).

state(A):

Eine Abbildung state(R)→ dom(T ) im Zustand state der Datenbank, die jederaktuellen Beziehung aus state(R) einen Wert des Datentyps T aus dom(T )

zuordnet.

Schreibweise:

R(E1, . . . , Em; A1 : T1, . . . , An : Tn) bzw. R(E1, . . . , Em; A1, . . . , An)


ER-Konzepte und ihre SemantikOptionale Attribute

Optionale Attribute müssen nicht für alle Entities einen definierten Wert annehmen.Graphische Darstellung:

A : T

E

A : T

R

Beispiel:

liest Vorlesung

SemesterTitel

Professor

Name

Fach

Telefon

Prüfung


Bemerkungen:

q Eine Kennzeichnung von A als optionales Attribut zeigt also an, dass es sich bei der Funktionstate(A) um eine partielle Funktion handelt.


ER-Konzepte und ihre SemantikSchlüssel

Definition 3 (Schlüssel im ER-Modell, Schlüsselattribut)

Sei {A1, . . . , An} die Menge der Attribute eines Entity-Typs E. Eine nichtverkleinerbare Menge von Attributen {Ai1, . . . , Aik} ⊆ {A1, . . . , An} nennt manSchlüssel, gdw. (↔) deren Werte das zugeordnete Entity eindeutig innerhalb allerEntities seines Typs identifiziert. Die {Ai1, . . . , Aik} heißen Schlüsselattribute.

Beispiele:

q Ein/e Student/in wird eindeutig durch eine Matrikelnummer identifiziert.q Ein Buch wird eindeutig durch eine ISBN identifiziert.


ER-Konzepte und ihre SemantikSchlüssel

Definition 3 (Schlüssel im ER-Modell, Schlüsselattribut)

Sei {A1, . . . , An} die Menge der Attribute eines Entity-Typs E. Eine nichtverkleinerbare Menge von Attributen {Ai1, . . . , Aik} ⊆ {A1, . . . , An} nennt manSchlüssel, gdw. (↔) deren Werte das zugeordnete Entity eindeutig innerhalb allerEntities seines Typs identifiziert. Die {Ai1, . . . , Aik} heißen Schlüsselattribute.

Beispiele:

q Ein/e Student/in wird eindeutig durch eine Matrikelnummer identifiziert.q Ein Buch wird eindeutig durch eine ISBN identifiziert.

Folgerung auf Basis von Definition 3 (beispielhaft):

Sei {A2} die Menge der Schlüsselattribute von Entity-Typ E(A1, A2, A3).

⇒

∀e1, e2 ∈ state(E) :

Gleiche Werte für A2 implizieren die Gleichheit von e1 und e2.DB:III-28 Conceptual Design © STEIN 2004-2018

Bemerkungen:

q Es handelt sich um eine Folgerung und keine Äquivalenzbeziehung, da aus der eindeutigenIdentifizierbarkeit in der Menge state(E) nicht auf die eindeutige Identifizierbarkeit in derMenge dom(E) geschlossen werden kann: state(E) ⊆ dom(E).

q Es kann mehrere Schlüsselkandidaten geben. Von ihnen ist einer auszuwählen und wird alsPrimärschlüssel bezeichnet.

q Verschiedene Schlüsselkandidaten können eine unterschiedliche Anzahl von Attributenbesitzen.


ER-Konzepte und ihre SemantikSchlüssel (Fortsetzung)

Graphische Darstellung:

A1 : T

EA2 : T

A3 : T

Schreibweise:E(A1, A2, A3)


ER-Konzepte und ihre SemantikDatenbankzustand

Für jeden::::::::::::Zustand

:::::::::state

::::::::einer

::::::::::::::::::Datenbank besitzt ein ER-Schema folgende

Zuordnungen:

E 7→ state(E) ⊆ dom(E)

R(E1, . . . , En) 7→ state(R) ⊆ state(E1)× . . .× state(En)

E(. . . , Ai : T, . . .) 7→ state(Ai) : state(E)→ dom(T )

R(. . . ; . . . , Aj : T, . . .) 7→ state(Aj) : state(R)→ dom(T )

Vorausgesetzt sind passende Interpretationen für dom(E) und dom(T ): Mengenmöglicher Entities für Entity-Typen und Wertebereiche für Datentypen.



Kapitel DB:III (Fortsetzung)

III. Konzeptueller Datenbankentwurfq Einführung in das Entity-Relationship-Modellq ER-Konzepte und ihre Semantikq Charakterisierung von Beziehungstypenq Existenzabhängige Entity-Typenq Abstraktionskonzepteq Konsolidierung, Sichtenintegrationq Konzeptuelle Modellierung mit UML


Charakterisierung von BeziehungstypenFunktionalitäten bei zweistelligen Beziehungen (Formalismus I für Kardinalitäten)

RE1 E2x y

Zweistellige Beziehungstypen und ihre Semantik:

q 1:1-BeziehungJedem Entity e1 ∈ state(E1) ist höchstens ein Entity e2 ∈ state(E2) zugeordnetund umgekehrt.

q 1:n-BeziehungJedem Entity e1 ∈ state(E1) sind beliebig viele (auch gar keine) Entities ausstate(E2) zugeordnet, und jedem Entity e2 ∈ state(E2) ist höchstens ein Entitye1 ∈ state(E1) zugeordnet.

q n:m-BeziehungKeine Restriktionen gelten; jedes Entity e1 ∈ state(E1) kann mit beliebig vielenEntities e2 ∈ state(E2) in Beziehung stehen und umgekehrt.



RE1 E2x y

Zweistellige Beziehungstypen und ihre Semantik:

q 1:1-BeziehungJedem Entity e1 ∈ state(E1) ist höchstens ein Entity e2 ∈ state(E2) zugeordnetund umgekehrt.

q 1:n-BeziehungJedem Entity e1 ∈ state(E1) sind beliebig viele (auch gar keine) Entities ausstate(E2) zugeordnet, und jedem Entity e2 ∈ state(E2) ist höchstens ein Entitye1 ∈ state(E1) zugeordnet.

q n:m-BeziehungKeine Restriktionen gelten; jedes Entity e1 ∈ state(E1) kann mit beliebig vielenEntities e2 ∈ state(E2) in Beziehung stehen und umgekehrt.


Bemerkungen:

q Mit dem Wort „Funktionalität“ wird hier eine Abhängigkeitsbeziehung zwischen Entity-Typenbzw. zwischen Entity-Typen und einem Beziehungstyp bezeichnet. Eine andere Bezeichnungfür Funktionalität ist Constraint.

q Die Semantik von n:1-Beziehungen ist analog zu der von 1:n-Beziehungen.

q Bei jeder Art von zweistelligen Beziehungen kann es Entities aus state(E1) (bzw. state(E2))geben, denen kein Element aus state(E2) (bzw. state(E1)) zugeordnet ist.



RE1 E2x y

Beispiele:

q 1:1-Beziehung. „verheiratet“-Relation zwischen Männern und Frauen nacheuropäischem Recht.

q 1:n-Beziehung. „beschäftigen“-Relation zwischen Firmen und Personen.

q n:m-Beziehung. „unterrichtet“-Relation zwischen Studierenden undProfessoren.


Bemerkungen:

q Funktionalitäten stellen Integritätsbedingungen dar, die in der zu modellierenden Welt immergelten müssen.

q Die binären 1:1, 1:n und n:1-Beziehungen stellen partielle Funktionen dar. Insbesondere istjede 1:1-Beziehung umkehrbar, und es existieren folgende Funktionen:R : E1 → E2

R−1 : E2 → E1

Beispiel:Ehemann: Frauen→ MännerEhefrau: Männer→ Frauen

q Bei einer 1:n-Beziehung ist die Richtung der Funktion zwingend, vom „n-Entity-Typ“ zum„1-Entity-Typ“.

Beispiel:beschäftigen: Personen→ Firmen



state(E1) state(E2)

1:1 1:n

state(E1) state(E2)

state(E1) state(E2)

n:1 n:m

state(E1) state(E2)



Alternative graphische Darstellungen für zweistellige funktionale Beziehungen:

RE1 E2n 1

RE1 E2

RE1 E21 1

≡


Charakterisierung von BeziehungstypenFunktionalitäten bei n-stelligen Beziehungen (Formalismus I für Kardinalitäten)

Sei R eine Beziehung zwischen den Entity-Typen E1, . . . , En, wobei dieFunktionalität bei Entity-Typ Ek, 1 ≤ k ≤ n, mit 1 spezifiziert ist. Dann wird durch R

folgende partielle Funktion vorgegeben:

R : E1 × . . .× Ek−1 × Ek+1 × . . .× En → Ek

[Kemper/Eickler 2011]

R

E1 Ek En... ...

n n1



Sei R eine Beziehung zwischen den Entity-Typen E1, . . . , En, wobei dieFunktionalität bei Entity-Typ Ek, 1 ≤ k ≤ n, mit 1 spezifiziert ist. Dann wird durch R

folgende partielle Funktion vorgegeben:

R : E1 × . . .× Ek−1 × Ek+1 × . . .× En → Ek

[Kemper/Eickler 2011]

R

E1 Ek En... ...

n n1

Urbildbereich Bildbereich


Bemerkungen:

q n-stellige (n-äre) Beziehungstypen spezifizieren genau die Menge der Funktionen, für derenSignatur gilt: die Bildmenge besteht aus einem Entity-Typ mit der Kardinalität 1; dieUrbildmenge ist das kartesische Produkt der restlichen n− 1 Entity-Typen.

q Diese Definition von n-stelligen Beziehungstypen erweitert die binären n:1-Beziehungen inkanonischer Weise. Dabei ist der 1-Entity-Typ der rechten Seite in der Rolle des rechten1-Entity-Typs der binären Funktionalität; die restlichen n− 1 Entity-Typen sind zusammen inder Rolle des linken n-Entity-Typs der binären Funktionalität.

q n-stellige Beziehungstypen sind in der Regel keine Kurzschreibweise von(n2

)binären

Beziehungstypen. Selbst eine ternäre 1:1:1-Relation R lässt sich nicht zwangsläufigverlustlos bzw. verbundtreu in binäre Beziehungstypen zerlegen.



Beispiel Prüfungsordnung (= Ausschnitt der realen Welt) :

(a) Ein Student darf bei demselben Professor nur ein Seminarthema machen.(b) Ein Student darf dasselbe Thema nur einmal bearbeiten und nicht zu einem anderen

Professor damit gehen.(c) Ein Professor kann dasselbe Thema an verschiedene Studenten vergeben.(d) Dasselbe Thema kann von verschiedenen Professoren vergeben werden.






Konzeptuelles Modell:

Student

Note

betreutn

1

1

Professor

Thema







Student

Note

betreutn

1

1

Professor

Thema

Analyse des konzeptuellen Modells:

zu (a) Abgebildet durch betreutf1 : Professor × Student → Themazu (b) Abgebildet durch betreutf2 : Thema × Student → Professorzu (c) Zugelassen durch betreutf1.zu (d) Zugelassen durch betreutf2.







Student

Note

betreutn

1

1

Professor

Thema









Student

Note

betreutn

1

1

Professor

Thema









Student

Note

betreutn

1

1

Professor

Thema




Charakterisierung von Beziehungstypen[min,max ]-Notation (Formalismus II für Kardinalitäten)

R

E1 En...

[min1, max1] [minn, maxn]

Schreibweise:

R(E1[min1,max1], . . . , Ei[mini,max i], . . . , En[minn,maxn])



R

E1 En...


Schreibweise:


Semantik der [min,max ]-Notation:

Die Anzahl der Beziehungsinstanzen vom Typ R mit Beteiligung der Instanz ei vomTyp Ei ist zwischen mini und max i:

∀i ∈ {1, . . . , n} ∀ei ∈ state(Ei) : mini ≤ |{t ∈ state(R) | t.Ei = ei}| ≤ max i

t.Ei bezeichne die Projektion der Beziehungsinstanz t auf den Entity-Typ Ei.



R

E1 En...


Schreibweise:


Semantik der [min,max ]-Notation:

Die Anzahl der Beziehungsinstanzen vom Typ R mit Beteiligung der Instanz ei vomTyp Ei ist zwischen mini und max i:

∀i ∈ {1, . . . , n} ∀ei ∈ state(Ei) : mini ≤ |{t ∈ state(R) | t.Ei = ei}| ≤ max i

t.Ei bezeichne die Projektion der Beziehungsinstanz t auf den Entity-Typ Ei.



Beispiele:

q arbeitet_in(Mitarbeiter[0,1], Raum[0,3])„Mitarbeitern ist ein oder kein Raum zugeordnet. Pro Raum gibt es höchstens dreiMitarbeiter.“

q verantwortlich_für (Mitarbeiter[0,*], Computer[1,1])„Es gibt Mitarbeiter, die für keinen Computer verantwortlich sind – aber auch Mitarbeiter, diefür mehrere Computer verantwortlich sind. Jedem Computer ist genau ein Mitarbeiterzugeordnet, der verantwortlich für diesen Computer ist.“



Beispiele:

q arbeitet_in(Mitarbeiter[0,1], Raum[0,3])„Mitarbeitern ist ein oder kein Raum zugeordnet. Pro Raum gibt es höchstens dreiMitarbeiter.“

q verantwortlich_für (Mitarbeiter[0,*], Computer[1,1])„Es gibt Mitarbeiter, die für keinen Computer verantwortlich sind – aber auch Mitarbeiter, diefür mehrere Computer verantwortlich sind. Jedem Computer ist genau ein Mitarbeiterzugeordnet, der verantwortlich für diesen Computer ist.“


Bemerkungen:

q Eine spezielle Wertangabe für max i ist ∗. Sie dient zum Anzeigen einer unbegrenztenAnzahl.

q [0, ∗] bedeutet keine Einschränkung und ist die Standardannahme, wenn keine Kardinalitätenangegeben sind.

q R(E1[0, 1], E2) entspricht einer partiellen funktionalen Beziehung R : E1 → E2.

q R(E1[1, 1], E2) entspricht einer totalen funktionalen Beziehung R : E1 → E2.

q Die Kardinalitätsangabe auf der rechten Seite verrät auch etwas über die Surjektivität derAbbildung: [0, ∗] bedeutet, dass nicht jedes Element in einer Beziehung stehen muss; [1, ∗]bedeutet, dass jedes Element erreicht wird, die Funktion also surjektiv ist.


Charakterisierung von BeziehungstypenFormalismus I versus Formalismus II

Unterschied in der Semantik:

q Die Semantik der Kardinalitäten bei Formalismus I bezieht sich auf Instanzenvon Entity-Typen.

q Die Semantik der Kardinalitäten bei Formalismus II ([min,max ]-Notation)bezieht sich auf Instanzen von Beziehungstypen.


Charakterisierung von BeziehungstypenFormalismus I versus Formalismus II

Unterschied in der Semantik:

q Die Semantik der Kardinalitäten bei Formalismus I bezieht sich auf Instanzenvon Entity-Typen.

q Die Semantik der Kardinalitäten bei Formalismus II ([min,max ]-Notation)bezieht sich auf Instanzen von Beziehungstypen.

q Somit kann eine partielle Funktion R : E1 → E2 graphisch u.a. auf folgendeArten dargestellt werden:

RE1 E2n 1

RE1 E2

RE1 E2[0,1] [0,*]


Charakterisierung von BeziehungstypenUmwandlung n-stelliger Beziehungen

Beispiel für die Umwandlung einer dreistelligen Beziehung in drei zweistelligeBeziehungen:

�Professor

Name

Fach

ISBN

Titel

Vorlesung

Buch

empfiehlt

empfiehlt-P-V

Professor

Name

Fach

ISBN

Titel

Vorlesung

Buch

empfiehlt-V-B

empfiehlt-P-B


Charakterisierung von BeziehungstypenUmwandlung n-stelliger Beziehungen (Fortsetzung)

�

empfiehlt

Professor Vorlesung Buch (ISBN)

Pearl Datenbanken 0-341...Pearl IT-Systeme 2-305...Graham Datenbanken 2-305...Graham IT-Systeme 2-305...

ursprünglicher Zustand:

Zustände der drei zweistelligen Beziehungen:

empfiehlt-P-V

Professor Vorlesung

Pearl DatenbankenPearl IT-SystemeGraham DatenbankenGraham IT-Systeme

empfiehlt-P-B

Professor Buch (ISBN)

Pearl 0-341...Pearl 2-305...Graham 2-305...

empfiehlt-V-B

Vorlesung Buch (ISBN)

Datenbanken 0-341...IT-Systeme 2-305...Datenbanken 2-305...



�

empfiehlt





empfiehlt-P-V

Professor Vorlesung


empfiehlt-P-B



empfiehlt-V-B



empfiehlt-P-V

Professor Vorlesung


empfiehlt-P-B



empfiehlt-V-B





�

empfiehlt





empfiehlt-P-V

Professor Vorlesung


empfiehlt-P-B



empfiehlt-V-B



empfiehlt-P-V

Professor Vorlesung


empfiehlt-P-B



empfiehlt-V-B



Pearl Datenbanken 2-305...

Problem 1�



�

empfiehlt





empfiehlt-P-V

Professor Vorlesung


empfiehlt-P-B



empfiehlt-V-B



empfiehlt-P-V

Professor Vorlesung


empfiehlt-P-B



empfiehlt-V-B



Pearl Datenbanken 2-305...

Problem 1�

Web-Services 1-100

?

Problem 2


Bemerkungen:

q Verschiedene Zustände der dreistelligen Relation (oben) bilden auf dieselben zweistelligenRelationen (unten) ab. Bei der Umkehrung dieser Zerlegung (von unten nach oben) könnenzusätzliche Tupel enstehen.

q Die illustrierte Problematik wird als die Eigenschaft der Verlustlosigkeit bzw. Verbundtreue inder Entwurfstheorie relationaler Datenbanken behandelt.

q Die im Beispiel durchgeführte Zerlegung ist nicht verlustlos: verloren gegangen ist dieInformation, dass Pearl das Buch 2-305 für IT-Systeme, aber nicht für Datenbankenempfiehlt. D.h., Anfragen auf der Datenbank mit dem zerlegten Schema können (ungewollterWeise) zu anderen Ergebnissen als auf der ursprünglichen Datenbank führen.

q Mit den drei zweistelligen Beziehungstypen können (ungewollter Weise) auchZusammenhänge abgebildet werden, die vorher in der dreistelligen Relation nicht möglichwaren: ein Buch (1-100) wird für eine Vorlesung (Web-Services) empfohlen, für die keineProfessorin angegeben ist.

q Manche Datenbanksysteme bieten für die Modellierung nur binäre Beziehungstypen an.


Existenzabhängige Entity-TypenBisher vorausgesetzt: Entities existieren autonom und sind innerhalb ihres Typsüber die Schlüsselattribute eindeutig identifizierbar.


Existenzabhängige Entity-TypenBisher vorausgesetzt: Entities existieren autonom und sind innerhalb ihres Typsüber die Schlüsselattribute eindeutig identifizierbar.

Aus Modellierungssicht sind auch Entity-Typen sinnvoll, die

1. von einem anderen, übergeordneten Entity-Typ abhängig sind, und

2. in Kombination mit dem Schlüssel des übergeordneten Entity-Typs eindeutigidentifizierbar sind.

Beispiel:

GebNr

1nGebäude

Größe

RaumNr

Straße

Raum liegt-in


Bemerkungen:

q Existenzabhängige Entity-Typen werden auch als schwache Entity-Typen bezeichnet.

q Existenzabhängige Entity-Typen werden durch doppelt umrandete Rechtecke, die Beziehungzu dem übergeordneten Entity-Typ durch eine doppelt umrandete Raute und die zugehörigeKante durch eine Doppellinie repräsentiert.

q Die Beziehung eines existenzabhängigen Entity-Typs zu dem übergeordneten Entity-Typ istmeist n:1, manchmal 1:1, aber nie n:m.

q Existenzabhängige Entity-Typen haben im Allgemeinen keinen Schlüssel, der alle Entitieseindeutig identifiziert. Statt dessen gibt es ein Attribut (bzw. eine Menge von Attributen), dasalle existenzabhängigen Entities, die einem übergeordneten Entity zugeordnet sind,voneinander unterscheidet. Diese Attribute werden im ER-Diagramm gestricheltunterstrichen.


AbstraktionskonzepteGeneralisierung / Spezialisierung

Die Generalisierung wird im konzeptuellen Entwurf eingesetzt, um eine bessere –im Sinne von „natürlichere“ – Strukturierung der Entity-Typen zu erzielen.


AbstraktionskonzepteGeneralisierung / Spezialisierung

Die Generalisierung wird im konzeptuellen Entwurf eingesetzt, um eine bessere –im Sinne von „natürlichere“ – Strukturierung der Entity-Typen zu erzielen.

Vorgehensweise:

q Die Eigenschaften ähnlicher Entity-Typen werden „faktorisiert“ und einemgemeinsamen Obertyp zugeordnet.

q Eigenschaften, die nicht faktorisierbar sind, verbleiben beim jeweiligenUntertyp, der somit eine Spezialisierung des Obertyps darstellt.

Beispiel:

Mitarbeiter

Institut

Prüfer

Fach PersNr

IST

Prüfer( Institut , PersNr︸︷︷︸geerbt von Mitarbeiter

,Fach)


Bemerkungen:

q Im Beispiel ist „Mitarbeiter“ der generellere Obertyp und „Prüfer“ der speziellere Untertyp.

q Ein wichtiges Prinzip der Generalisierung ist die Vererbung: ein Untertyp erbt alleEigenschaften des Obertyps.

q Bei der Übersetzung in das Relationenmodell werden Generalisierungsbeziehungenbesonders behandelt.


AbstraktionskonzepteGeneralisierung / Spezialisierung (Fortsetzung)

Die Entities eines Untertyps sind gleichzeitig Entities des Obertyps; es handelt sichalso um eine Teilmengenbeziehung: state(E1) ⊆ state(E2)

IST E2E1

Schreibweise: E1 IST E2

Hinsichtlich der Teilmengensicht sind zwei Fälle von besonderem Interesse:

1. Disjunkte SpezialisierungDie Mengen der Entity-Untertypen eines Entity-Obertyps sind paarweisedisjunkt.

2. Vollständige SpezialisierungDie Menge des Entity-Obertyps enthält keine unspezialisierten Elementesondern ergibt sich vollständig durch die Vereinigung der Mengen derEntity-Untertypen.



Die Entities eines Untertyps sind gleichzeitig Entities des Obertyps; es handelt sichalso um eine Teilmengenbeziehung: state(E1) ⊆ state(E2)

IST E2E1

Schreibweise: E1 IST E2

Hinsichtlich der Teilmengensicht sind zwei Fälle von besonderem Interesse:

1. Disjunkte SpezialisierungDie Mengen der Entity-Untertypen eines Entity-Obertyps sind paarweisedisjunkt.

2. Vollständige SpezialisierungDie Menge des Entity-Obertyps enthält keine unspezialisierten Elementesondern ergibt sich vollständig durch die Vereinigung der Mengen derEntity-Untertypen.



Graphische Notation als Standard-Beziehungstyp:

Mitarbeiter

Institut

Prüfer

Fach PersNr

IST

Alternative graphische Notation:

Mitarbeiter

Institut

Prüfer

Fach PersNr

is-a


Konsolidierung, Sichtenintegration



Konsolidierung, Sichtenintegration


Sicht 1

Sicht 2

Sicht 3Sicht 4

Sicht 5

Konsolidierung

globales Schema

� redundanzfrei

� widerspruchsfrei

� Synonyme bereinigt

� Homonyme bereinigt

� ...


Bemerkungen: [::::::DB:II

::::::::::::::::::Entwurfsprozess

::>

:::::::::::::::Konzeptueller

:::::::::Entwurf]

q Bei größeren Anwendungen ist es nicht praktikabel, den konzeptuellen Entwurf in einemGuss durchzuführen; sinnvoll ist die Aufteilung in verschiedene Anwendersichten.

q Konsolidierung bedeutet die Zusammenfassung einzelner Sichten zu einem globalenSchema, das u.a. redundanz- und widerspruchsfrei ist.

q Bei der Konsolidierung einer größeren Anwendung sollte man schrittweise vorgehen, so dassman jeweils nur zwei Teilschemata gleichzeitig betrachtet.

q Arten von Widersprüchen, die bei einer Konsolidierung aufzulösen sind:

– unterschiedliche Benennung gleicher Sachverhalte (Synonyme)– gleiche Benennung unterschiedlicher Sachverhalte (Homonyme)– Sachverhalt einmal als Entity-Typ und ein andermal als Beziehungstyp modelliert

(struktureller Widerspruch)– widersprüchliche Funktionalitätsangaben– widersprüchliche Datentypen, widersprüchliche Schlüsselattribute


https://webis.de/downloads/lecturenotes/databases/unit-de-design-and-models.pdf#design-process-phase-model-conceptual

Konsolidierung, SichtenintegrationBeispiel: drei Sichten einer Universitätsdatenbank

Buchempfehlungen

Bibliotheks-verwaltung

Erstellung vonDokumenten



Buchempfehlungen



Titel

Student

Titelbetreut

Masterarbeit

Assistent

Professor

erstellt

bewertet

verfasst Dissertation



Buchempfehlungen



Datum

FakultätSignatur

JahrAutor

Titel

Bibliothek

entleiht

Dokument

UniMitglied

besitzt

leitet



Buchempfehlungen



Jahr

Verlag

Vorlesung

empfiehlt Buch

Dozent

AutorTitel



Buchempfehlungen



Titel

Student

Titelbetreut

Masterarbeit

Assistent

Professor

erstellt

bewertet


Datum

FakultätSignatur

JahrAutor

Titel

Bibliothek

entleiht

Dokument

UniMitglied

besitzt

leitet

Jahr

Verlag

Vorlesung

empfiehlt Buch

Dozent

AutorTitel



Buchempfehlungen



Titel

Student

Titelbetreut

Masterarbeit

Assistent

Professor

erstellt

bewertet


Datum

FakultätSignatur

JahrAutor

Titel

Bibliothek

entleiht

Dokument

UniMitglied

besitzt

leitet

Jahr

Verlag

Vorlesung

empfiehlt Buch

Dozent

AutorTitel

synonym



Buchempfehlungen



Titel

Student

Titelbetreut

Masterarbeit

Assistent

Professor

erstellt

bewertet


Datum

FakultätSignatur

JahrAutor

Titel

Bibliothek

entleiht

Dokument

UniMitglied

besitzt

leitet

Jahr

Verlag

Vorlesung

empfiehlt Buch

Dozent

AutorTitel

generalisieren



Buchempfehlungen



Titel

Student

Titelbetreut

Masterarbeit

Assistent

Professor

erstellt

bewertet


Datum

FakultätSignatur

JahrAutor

Titel

Bibliothek

entleiht

Dokument

UniMitglied

besitzt

leitet

Jahr

Verlag

Vorlesung

empfiehlt Buch

Dozent

AutorTitel

?


Bemerkungen:

q Aufgabe ist die Konsolidierung dieser Sichten in ein Schema.

q Die Entity-Typen „Dozent“ und „Professor“ sind synonym verwendet worden.

q Der Entity-Typ „UniMitglied“ ist eine Generalisierung der Entity-Typen „Student“, „Professor“und „Assistent“.

q Fakultätsbibliotheken werden von Angestellten und nicht von Studierenden geleitet: derBeziehungstyp „leitet“ in Sicht 2 sollte revidiert werden.

q Die Entity-Typen „Dissertation“, „Masterarbeit“ und „Buch“ sind Spezialisierungen desEntity-Typs „Dokument“.

q Alle an der Universität erstellten Diplomarbeiten und Dissertationen werden in Bibliothekenverwaltet.

q Die Beziehungtypen „erstellt“ und „verfasst“ in Sicht 1 modellieren denselben Sachverhalt wiedas Attribut „Autor“ vom Entity-Typ „Dokument“ in Sicht 2.

q Alle in einer Bibliothek verwalteten Dokumente werden durch die Signatur identifiziert.


Documents

II.Datenbankentwurf und Datenbankmodelle · q 1976 von Peter Chen vorgeschlagen q Standardmodell für frühe Entwurfsphasen in der Datenbankentwicklung q mittlerweile existieren viele