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_adresse*           {PK: s_id} 
                                             {UNIQUE: h_name, h_adresse}
ware:     w_id, w_typ, w_bezeichnung         {PK: w_id}

                                             {UNIQUE: w_typ, w_bezeichung}  
liefert:  h_id, w_id, l_preis, l_lieferzeit* {PK: s_id, w_id}  

                                             {FK: h_id -> haendler: h_id}
                                             {FK: w_id -> ware: w_id}
                                             {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)
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                       {PK: t_id}
                                             {UNIQUE: t_name}

haendler: h_id, h_name, h_adresse*           {PK: s_id} 
                                             {UNIQUE: h_name, h_adresse}

ware:     w_id, t_id, w_bezeichnung          {PK: w_id} 
                                             {FK: t_id -> typ: t_id}
                                             {UNIQUE: w_typ, w_bezeichung} 
 
liefert:  h_id, w_id, l_preis, l_lieferzeit* {PK: s_id, w_id}  
                                             {FK: h_id -> haendler: h_id}
                                             {FK: w_id -> ware: w_id}
                                             {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 weden 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.

Modifiziertes Händler-DB-Datenmodell

Die zuvor defi­ner­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)