Die Händler-Datenbank (das Standard-Beispiel aus der Vorlesung)

Händler-DB: Modell (UML)UML-Klas­sen­dia­gramm

Händler-DB: Modell (ER)ER-Dia­gramm

Relationales Datenbankschema (ohne Domänen)

haendler: h_id, h_name, h_ortschaft*
{PRIMARY KEY (s_id)}
{UNIQUE (h_name, h_ortschaft)}

ware: w_id, w_typ, w_bezeichnung
{PRIMARY KEY (w_id)}
{UNIQUE (w_typ, w_bezeichung)}

liefert: h_id, w_id, l_preis, l_lieferzeit*
{PRIMARY KEY (s_id, w_id)}
{FOREIGN KEY (h_id) REFERENCES haendler (h_id)}
{FOREIGN KEY (w_id) REFERENCES ware (w_id)}
{CHECK (l_lieferzeit > 0)}

SQL-Beispiele

haendler-vorlesung.sql(CREATE-TABLE- und INSERT-Befeh­le)
haendler.sql(CREATE-TABLE- und INSERT-Befeh­le: Prak­ti­kums­ver­si­on, etwas mehr Daten)
query_aufgabe1.sql(die Fra­gen aus der ers­ten Prak­ti­kums­auf­ga­be)
query_00.sql(Lis­tet die Inhal­te der Tabel­len auf)
query_01-identitaet.sql(Bei­spie­le zum Iden­ti­täts-Ope­ra­tor)
query_02-projektion.sql(Bei­spie­le zum Pro­jek­ti­ons-Ope­ra­tor)
query_03-selektion.sql(Bei­spie­le zum Selek­ti­ons-Ope­ra­tor)
query_04-set.sql(Bei­spie­le zu den Men­gen-Ope­ra­tio­nen)
query_05-join.sql(Bei­spie­le zum Join-Ope­ra­tor)
query_06-aggregation.sql(Bei­spie­le für Aggref­ga­ti­on)
query_07-gruppierung.sql(Bei­spie­le für Aggre­ga­ti­on mit Grup­pie­rung)
query_08-subqueries.sql(Bei­spie­le für Sub­que­ries)
query_09-for-all.sql(Bei­spie­le zur „Für-alle”-Operation)
query_10-recursion.sql(Bei­spie­le zu rekur­si­ven Views)
update-01.sql(Bei­spie­le zur Update-Ope­ra­ti­on)
haendler_json.sql(Eine Händ­ler-Daten­bank mit Daten im JSON-For­mat)
query_json_01.sql(Ein paar zuge­hö­ri­ge Anfra­gen)

Verbessertes Händler-DB-Datenmodell

Händler-DB: Verbessertes Datenmodell (UML)UML-Klas­sen­dia­gramm

Händler-DB: Verbessertes Datenmodell (ER)ER-Dia­gramm

Relationales Datenbankschema (ohne Domänen)

typ: t_id, t_name
{PRIMARY KEY (t_id)}
{UNIQUE (t_name)}

haendler: h_id, h_name, h_ortschaft*
{PRIMARY KEY (s_id)}
{UNIQUE (h_name, h_ortschaft)}

ware: w_id, t_id, w_bezeichnung
{PRIMARY KEY (w_id)}
{FOREIGN KEY (t_id) RFERENCES typ (t_id)}
{UNIQUE (w_typ, w_bezeichung)}

liefert: h_id, w_id, l_preis, l_lieferzeit*
{PRIMARY KEY (s_id, w_id)}
{FOREIGN KEY (h_id) REFERENCES haendler (h_id)}
{FOREIGN KEY (w_id) REFERENCES ware (w_id)}
{CHECK (l_lieferzeit > 0)}

SQL-Beispiele

haendler2.sql(Ver­bes­ser­tes Daten­mo­dell: typ als eige­ne Tabel­le)

Die­ses Daten­mo­dell hat den Vor­teil, dass für eine Ware nicht belie­bi­ge Zei­chen­ket­ten als Waren­typ ange­ge­ben wer­den kön­nen. Einer Ware kön­nen nur die­je­ni­gen Typen zuge­ord­net wer­den, die in der (modi­fi­zier­ba­ren!) Tabel­le typ ent­hal­ten sind. Damit wer­den Tipp­feh­ler bei der Ein­ga­be unmög­lich gemacht. Außer­dem kann der Inhalt der Tabel­le typ zur Gene­rie­rung eines Drop-Down-Menüs ver­wen­det wer­den.

Händler-DB-Datenmodell mit Rekursion

Händler-DB: Datenmodell mit rekursiver Beziehung (UML)UML-Klas­sen­dia­gramm

Händler-DB: Datenmodell mit rekursiver Beziehung (ER)ER-Dia­gramm

Relationales Datenbankschema (ohne Domänen)

Gegen­über dem vor­he­ri­gen Modell hat sich nur die Tabel­le typ geän­dert.

typ: t_id, t_name, t_supertyp_id*
{PRIMARY KEY (t_id)}
{FOREIGN KEY (t_supertyp_id) REFERENCES typ (t_id)}
{UNIQUE (t_name)}

SQL-Beispiele

haendler2_rekursion.sql(Ver­bes­ser­tes Daten­mo­dell: typ mir Rekur­si­on)

In die Tabel­le typ wur­de ein rekur­si­ver Selbst­be­zug ein­ge­baut. Jeder Typ, wie bei­spiels­wei­se CPU oder RAM, kann einen Super­typ haben, wie bei­spiels­wei­se Computerzubehör. Super­ty­pen kön­nen ihrer­seits Super­su­per­ty­pen haben , wie bei­spiels­wei­se Hardware, etc. Auf die­se Wei­se kann ein gan­zer Typ­baum auf­ge­baut wer­den.

Modifiziertes Händler-DB-Datenmodell

Die zuvor defi­nier­te ver­bes­ser­te Ver­si­on des Händ­ler-DB-Daten­mo­dells hat einen ent­schei­den­den Nach­teil: Die Anfra­gen, die für das ers­te Daten­mo­dell geschrie­ben wur­den, funk­tio­nie­ren nur noch zu Teil für das ver­bes­ser­te Daten­mo­dell. Vie­le Anfra­gen müss­ten an das neue Daten­mo­dell ange­passt wer­den.

Die­ses Pro­blem kann gelöst wer­den, indem man zunächst alle Tabel­len anders benennt und dann die im ers­ten Modell defi­nier­ten Tabel­len als vir­tu­el­le Tabel­len (modi­fi­zier­ba­re Views) defi­niert. Tabel­len, die Enti­tä­ten (= Objek­te) beschrei­ben, erhal­ten den Prä­fix e_, Tabel­len, die Bezie­hun­gen (= Rela­ti­ons = Asso­zia­ti­ons) beschrbei­en, erhal­ten den Prä­fix r_ und Tabel­len, die dyna­misch ver­än­der­ba­ren Auf­zäh­lungs­ty­pen rea­li­sie­ren, erhal­ten den Prä­fix enum_.

Für das fol­gen­de Daten­mo­dell funk­tio­nie­ren alle zuvor defi­nier­ten Select-Anfra­gen sowie die meis­ten Modi­fi­ka­ti­ons­an­wei­sun­gen. Eine wich­ti­ge Aus­nah­me gibt es aller­dings: Es ist nicht mög­lich, einer Ware einen Waren­typ zuzu­ord­nen, der nicht zuvor in der Tabel­le enum_type defi­niert wur­de.

Händler-DB: Datenmodell mit Views (UML)UML-Klas­sen­dia­gramm

Händler-DB: Datenmodell mit Views (ER)ER-Dia­gramm

SQL-Beispiele

haendler3.sql(Ver­bes­ser­tes Daten­mo­dell: Urspüng­li­ches Daten­mo­dell als Views)