Händler-Datenbank (SQL-Beispiel): Unterschied zwischen den Versionen

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
 
(22 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
{{Qualität
{{Qualität
|correctness        = 5
|correctness        = 4
|extent              = 5
|extent              = 5
|numberOfReferences  = 5
|numberOfReferences  = 5
Zeile 9: Zeile 9:
Daher wird dieses Beispiel auch in der Vorlesung [[Kowarschick, W.: Multimedia-Datenbanksysteme|Multimedia-Datenbanksysteme]] verwendet.
Daher wird dieses Beispiel auch in der Vorlesung [[Kowarschick, W.: Multimedia-Datenbanksysteme|Multimedia-Datenbanksysteme]] verwendet.


=Datenmodell/[[ER-Diagramm]] (in [[UML]]-Notation)=
==Datenmodell/[[ER-Diagramm]]==


[[Medium:Haendler_Modell.jpg]]
[[Datei:Haendler1_UML.png|thumb|none|600px|frame|Datenmodell in [[UML]]-Notation]]


Eine Händler, der durch die Händlernummer <code>hnr</code> eindeutig identifiziert werden kann und weitere Attribute, wie Name, Adresse etc. hat,
Ein Händler liefert bestimmte Waren.
liefert bestimmte Waren. Die zugehörigen [[Entity|Entities]] ([[Objekt]]e) werden durch den [[Entity-Typ]] (die Klasse) <code>haendler</code> definiert.
Er kann durch die Händler-ID <code>h_id</code> eindeutig identifiziert werden und besitzt weitere Attribute, wie Name, Ortschaft etc.
Die zugehörigen [[Entity|Entities]] ([[Objekt]]e) werden durch den [[Entity-Typ]] (die [[Klasse (OOP)|Klasse]]) <code>haendler</code> definiert.


Welche Waren es gibt, ist durch einen weiteren Entity-Typ festgelegt: <code>ware</code>. Eine Ware ist durch die Warennummer <code>wnr</code>
Welche Waren es gibt, ist durch einen weiteren Entity-Typ festgelegt: <code>ware</code>. Eine Ware ist durch die Waren-ID <code>w_id</code>
eindeutig festgelgt. Weitere Attribute, wie Typ (Gemüse, Fleisch, Wurst etc.) und genaue Bezeichnung (Kohlrabi, Rinderlende, Crevelat etc.),
eindeutig festgelgt. Weitere Attribute, wie Typ (Gemüse, Fleisch, Wurst etc.) und genaue Bezeichnung (Kohlrabi, Rinderlende, Cervelat etc.),
beschreiben die jeweilige Ware näher.
beschreiben die jeweilige Ware näher.


Zeile 23: Zeile 24:
legt fest, welcher Händler welche Ware zu welchen Konditionen liefert. Ein Lieferant liefert eine Ware normalerweise zu einem bestimmten  
legt fest, welcher Händler welche Ware zu welchen Konditionen liefert. Ein Lieferant liefert eine Ware normalerweise zu einem bestimmten  
Preis. Zusätzlich kann eine gewisse Lieferzeit (in Tagen) angegeben werden. Es ist auch erlaubt, dass ein Händler ein und dieselbe
Preis. Zusätzlich kann eine gewisse Lieferzeit (in Tagen) angegeben werden. Es ist auch erlaubt, dass ein Händler ein und dieselbe
Ware zu mit unterschiedlichen Preisen unterschiedlich schnell liefert. Um dies zu ermöglichen, muss das Attribut <code>preis</code>
Ware zu mit unterschiedlichen Preisen unterschiedlich schnell liefert. Um dies zu ermöglichen, muss das Attribut <code>l_preis</code>
zum orginären Primärschlüssel <code>(hnr, wnr)</code> der Beziehung <code>liefert</code> hinzugefügt werden.
zum orginären Primärschlüssel <code>(h_id, w_id)</code> der Beziehung <code>liefert</code> hinzugefügt werden.


=Datenbankschema=
[[Datei:Haendler1_ER.png|thumb|none|600px|frame|Datenmodell in [[ER-Diagramm|ER]]-Notation]]


[[Medium:Haendler_Schema.png]]
==Datenbankschema==


Dieses Schema wurde nach dem in [[Kowarschick (2012)]] beschriebenen Verfahren aus dem obigen ER-Diargramm erzeugt.
Aus dem obigen ER-Diargramm wird nach dem in [[Kowarschick (MMDB-Skript)]] beschriebenen Verfahren ein Datenbankschema erstellt.
Ein Stern (<code>*</code>) bedeutet dabei <code>NULLABLE</code>.


=Datenbankschema (SQL)=
<source lang="sql">haendler: h_id: INTEGER, h_name: VARCHAR(50), h_ortschaft*: VARCHAR(30)   
          {PK: s_id}
          {UNIQUE: h_name, h_ortschaft}
 
ware:    w_id: INTEGER, w_typ: VARCHAR(30), w_bezeichnung: VARCHAR(30)
          {PK: w_id}
          {UNIQUE: w_typ, w_bezeichung} 
 
liefert:  h_id: INTEGER, w_id: INTEGER, l_preis: NUMERIC(8,2), l_lieferzeit*: SMALINT
          {PK: s_id, w_id, l_preis} 
          {FK: h_id -> haendler: h_id}
          {FK: w_id -> ware: w_id}
          {l_lieferzeit > 0}
</source>
 
==Datenbankschema (SQL)==
 
Aus dem obigen Datenbankschema leitet sich folgende SQL-[[DDL]]-Befehle ab (Syntax getestet mit [[SQLite]] und [[PostgreSQL]]):


<source lang="sql">
<source lang="sql">
/***********************************************************************
/* Alte Tabellen (in der richtigen Reihenfolge) löschen: */
* Alte Tabellen (in der richtigen Reihenfolge) löschen  
***********************************************************************/


DROP TABLE IF EXISTS liefert CASCADE;
DROP TABLE IF EXISTS liefert;
DROP TABLE IF EXISTS ware     CASCADE;
DROP TABLE IF EXISTS ware;
DROP TABLE IF EXISTS haendler CASCADE;
DROP TABLE IF EXISTS haendler;


/***********************************************************************
/* Tabellen erstellen */
* Tabellen gemäß relationalem Schema erzeugen
***********************************************************************/


CREATE TABLE haendler
CREATE TABLE haendler
   (hnr      INTEGER    NOT NULL,
   (h_id        INTEGER    NOT NULL,
   name     VARCHAR(30) NOT NULL,
   h_name     VARCHAR(30) NOT NULL,
   adresse  VARCHAR(50),
   h_ortschaft VARCHAR(50),


   CONSTRAINT pk_haendler
   CONSTRAINT pk_haendler
     PRIMARY KEY (hnr),
     PRIMARY KEY (h_id),


   CONSTRAINT unique_name_adresse
   CONSTRAINT unique_haendler_name_ortschaft
     UNIQUE (name, adresse)
     UNIQUE (h_name, h_ortschaft)
   );
   );


CREATE TABLE ware
CREATE TABLE ware
   (wnr         INTEGER    NOT NULL,
   (w_id         INTEGER    NOT NULL,
   typ          VARCHAR(30) NOT NULL DEFAULT 'Sonstiges',
   w_typ        VARCHAR(30) NOT NULL DEFAULT 'Sonstiges',
   bezeichnung  VARCHAR(50) NOT NULL,
   w_bezeichnung VARCHAR(50) NOT NULL,


   CONSTRAINT pk_ware
   CONSTRAINT pk_ware
     PRIMARY KEY (wnr),
     PRIMARY KEY (w_id),


   CONSTRAINT unique_typ_bezeichnung
   CONSTRAINT unique_haendler_typ_bezeichnung
     UNIQUE (typ, bezeichnung)
     UNIQUE (w_typ, w_bezeichnung)
   );
   );
                  
                  
CREATE TABLE liefert
CREATE TABLE liefert
   (hnr         INTEGER      NOT NULL,
   (h_id         INTEGER      NOT NULL,
   wnr         INTEGER      NOT NULL,
   w_id         INTEGER      NOT NULL,
   preis      NUMERIC(8,2)  NOT NULL,
   l_preis      NUMERIC(8,2)  NOT NULL,
   lieferzeit  SMALLINT,    /* Tage */
   l_lieferzeit SMALLINT,    /* Tage */


   CONSTRAINT pk_liefert
   CONSTRAINT pk_liefert
     PRIMARY KEY (hnr,wnr,preis),
     PRIMARY KEY (h_id, w_id, l_preis),


   CONSTRAINT fk_liefert_haendler
   CONSTRAINT fk_liefert_haendler
     FOREIGN KEY (hnr) REFERENCES haendler (hnr),
     FOREIGN KEY (h_id) REFERENCES haendler (h_id),


   CONSTRAINT fk_liefert_ware
   CONSTRAINT fk_liefert_ware
     FOREIGN KEY (wnr) REFERENCES ware (wnr),
     FOREIGN KEY (w_id) REFERENCES ware (w_id),


   CONSTRAINT check_lieferzeit
   CONSTRAINT check_liefert_lieferzeit
     CHECK (lieferzeit >= 0)
     CHECK (l_lieferzeit > 0)
   );
   );
/***********************************************************************
* Dummy-Tabelle. Diese Tabelle kann für Abfragen eingesetzt
* werden, für deren Beantwortung eigentlich gar keine Tabelle
* benötigt wird. Laut SQL-Standard muss immer eine Tabelle
* in der FROM-Klausel einer SELECT-Anweisung angegeben werden.
*
* In einigen DBM, wie z.B. PostgreSQL, ist es auch möglich,
* SELECT-Anweisungen ohne FROM-Klausel anzugeben. Dies ist
* allerdings nicht standard-konform.
***********************************************************************/
CREATE TABLE dummy
(
id INTEGER NOT NULL,
CONSTRAINT p_dummy
  PRIMARY KEY (id)
);
</source>
</source>


=Beispiels-Daten=
==Beispielsdaten==


<source lang="sql">
<source lang="sql">
INSERT INTO haendler(hnr, name, adresse)
INSERT INTO haendler(h_id, h_name, h_ortschaft)
VALUES  
VALUES  
   (1, 'Maier',  'Königsbrunn'),
   (1, 'Maier',  'Königsbrunn'),
Zeile 122: Zeile 118:
;
;


INSERT INTO ware(wnr, typ, bezeichnung)
INSERT INTO ware(w_id, w_typ, w_bezeichnung)
VALUES
VALUES
   (1, 'CPU',      'Pentium IV 3,8'),
   (1, 'CPU',      'Pentium IV 3,8'),
Zeile 131: Zeile 127:
;
;


INSERT INTO liefert(hnr, wnr, preis, lieferzeit)
INSERT INTO liefert(h_id, w_id, l_preis, l_lieferzeit)
VALUES  
VALUES  
   (1, 1, 200.00, 1),
   (1, 1, 200.00, 1),
Zeile 139: Zeile 135:
   (1, 4,  10.00, 1),
   (1, 4,  10.00, 1),
   (1, 5,  5.00, 1),
   (1, 5,  5.00, 1),
   (2, 1, 190.00, NULL),
  (2, 1, 160.00, NULL),
   (2, 1, 190.00, 1),
  (2, 2, 180.00, NULL),
   (2, 3, 170.00, 4),
   (2, 3, 170.00, 4),
  (2, 1, 160.00, 1),
  (2, 2, 180.00, NULL),
   (3, 1, 195.00, 2),
   (3, 1, 195.00, 2),
   (3, 2, 190.00, 1),
   (3, 2, 190.00, 1),
Zeile 149: Zeile 145:
   (4, 3, 199.99, 1)
   (4, 3, 199.99, 1)
;
;
/***********************************************************************
* Die Dummy-Tabelle enthält stets genau ein Tupel.
***********************************************************************/
INSERT INTO dummy(id)
VALUES
(1);
</source>
</source>


=SQL-Beispiele=
==SQL-Beispiele==
* [[Händler-Datenbank (SQL-Beispiel)/Identität|Identität]]
* [[Händler-Datenbank (SQL-Beispiel)/Identität|Identität]]
* [[Händler-Datenbank (SQL-Beispiel)/Projektion|Projektion]]
* [[Händler-Datenbank (SQL-Beispiel)/Projektion|Projektion]]
Zeile 166: Zeile 154:
* [[Händler-Datenbank (SQL-Beispiel)/Unteranfragen|Unteranfragen]]
* [[Händler-Datenbank (SQL-Beispiel)/Unteranfragen|Unteranfragen]]


=Quellen=
==Quellen==


#{{Quelle|Kowarschick, W. (MMDB-Skript): Skriptum zur Vorlesung Multimedia-Datenbanksysteme}}
#{{Quelle|Kowarschick, W.: Multimedia-Datenbanksysteme}}
#{{Quelle|Kowarschick, W.: Multimedia-Datenbanksysteme}}
#{{Quelle|Kowarschick, W. (MMDB-Skript): Skriptum zur Vorlesung Multimedia-Datenbanksysteme}}
=Siehe auch=


==Siehe auch==
* [[Händler-Datenbank (SQL-Beispiel)/Identität]]
* [[Händler-Datenbank (SQL-Beispiel)/Projektion]]
* [[Händler-Datenbank (SQL-Beispiel)/Selektion]]
*{{Vgl|Händler2-Datenbank (SQL-Beispiel)}} (komplexere Version dieser Datenbank)
*{{Vgl|Händler2-Datenbank (SQL-Beispiel)}} (komplexere Version dieser Datenbank)


[[Kategorie:PostgreSQL-Beispiel]]
[[Kategorie:PostgreSQL-Beispiel]]
[[Kategorie:SQL-Beispiel]]
[[Kategorie:Praktikum:MMDB]]

Aktuelle Version vom 10. Oktober 2019, 16:23 Uhr

Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen:

Korrektheit: 4
(großteils überprüft)
Umfang: 5
(wesentliche Fakten vorhanden)
Quellenangaben: 5
(vollständig vorhanden)
Quellenarten: 5
(ausgezeichnet)
Konformität: 5
(ausgezeichnet)

Das Händler-liefert-Ware-Beispiel ist das klassische Beispiel, um viele Konzepte von Datenbanksystemen und SQL zu demonstieren. Daher wird dieses Beispiel auch in der Vorlesung Multimedia-Datenbanksysteme verwendet.

Datenmodell/ER-Diagramm

Datenmodell in UML-Notation

Ein Händler liefert bestimmte Waren. Er kann durch die Händler-ID h_id eindeutig identifiziert werden und besitzt weitere Attribute, wie Name, Ortschaft etc. Die zugehörigen Entities (Objekte) werden durch den Entity-Typ (die Klasse) haendler definiert.

Welche Waren es gibt, ist durch einen weiteren Entity-Typ festgelegt: ware. Eine Ware ist durch die Waren-ID w_id eindeutig festgelgt. Weitere Attribute, wie Typ (Gemüse, Fleisch, Wurst etc.) und genaue Bezeichnung (Kohlrabi, Rinderlende, Cervelat etc.), beschreiben die jeweilige Ware näher.

Zwischen den Entity-Typen haendler und ware besteht eine Beziehung: liefert. Diese legt fest, welcher Händler welche Ware zu welchen Konditionen liefert. Ein Lieferant liefert eine Ware normalerweise zu einem bestimmten Preis. Zusätzlich kann eine gewisse Lieferzeit (in Tagen) angegeben werden. Es ist auch erlaubt, dass ein Händler ein und dieselbe Ware zu mit unterschiedlichen Preisen unterschiedlich schnell liefert. Um dies zu ermöglichen, muss das Attribut l_preis zum orginären Primärschlüssel (h_id, w_id) der Beziehung liefert hinzugefügt werden.

Datenmodell in ER-Notation

Datenbankschema

Aus dem obigen ER-Diargramm wird nach dem in Kowarschick (MMDB-Skript) beschriebenen Verfahren ein Datenbankschema erstellt. Ein Stern (*) bedeutet dabei NULLABLE.

haendler: h_id: INTEGER, h_name: VARCHAR(50), h_ortschaft*: VARCHAR(30)     
          {PK: s_id} 
          {UNIQUE: h_name, h_ortschaft}

ware:     w_id: INTEGER, w_typ: VARCHAR(30), w_bezeichnung: VARCHAR(30)
          {PK: w_id}
          {UNIQUE: w_typ, w_bezeichung}  

liefert:  h_id: INTEGER, w_id: INTEGER, l_preis: NUMERIC(8,2), l_lieferzeit*: SMALINT 
          {PK: s_id, w_id, l_preis}  
          {FK: h_id -> haendler: h_id}
          {FK: w_id -> ware: w_id}
          {l_lieferzeit > 0}

Datenbankschema (SQL)

Aus dem obigen Datenbankschema leitet sich folgende SQL-DDL-Befehle ab (Syntax getestet mit SQLite und PostgreSQL):

/* Alte Tabellen (in der richtigen Reihenfolge) löschen: */

DROP TABLE IF EXISTS liefert;
DROP TABLE IF EXISTS ware;
DROP TABLE IF EXISTS haendler;

/* Tabellen erstellen */

CREATE TABLE haendler
  (h_id        INTEGER     NOT NULL,
   h_name      VARCHAR(30) NOT NULL,
   h_ortschaft VARCHAR(50),

   CONSTRAINT pk_haendler
     PRIMARY KEY (h_id),

   CONSTRAINT unique_haendler_name_ortschaft
     UNIQUE (h_name, h_ortschaft)
  );

CREATE TABLE ware
  (w_id          INTEGER     NOT NULL,
   w_typ         VARCHAR(30) NOT NULL DEFAULT 'Sonstiges',
   w_bezeichnung VARCHAR(50) NOT NULL,

   CONSTRAINT pk_ware
     PRIMARY KEY (w_id),

   CONSTRAINT unique_haendler_typ_bezeichnung
     UNIQUE (w_typ, w_bezeichnung)
  );
                
CREATE TABLE liefert
  (h_id         INTEGER       NOT NULL,
   w_id         INTEGER       NOT NULL,
   l_preis      NUMERIC(8,2)  NOT NULL,
   l_lieferzeit SMALLINT,     /* Tage */

   CONSTRAINT pk_liefert
     PRIMARY KEY (h_id, w_id, l_preis),

   CONSTRAINT fk_liefert_haendler
     FOREIGN KEY (h_id) REFERENCES haendler (h_id),

   CONSTRAINT fk_liefert_ware
     FOREIGN KEY (w_id) REFERENCES ware (w_id),

   CONSTRAINT check_liefert_lieferzeit
     CHECK (l_lieferzeit > 0)
  );

Beispielsdaten

INSERT INTO haendler(h_id, h_name, h_ortschaft)
VALUES 
  (1, 'Maier',   'Königsbrunn'),
  (2, 'Müller',  'Königsbrunn'),
  (3, 'Maier',   'Augsburg'),
  (4, 'Huber',   NULL),
  (5, 'Schmidt', 'Hamburg')
;

INSERT INTO ware(w_id, w_typ, w_bezeichnung)
VALUES
  (1, 'CPU',       'Pentium IV 3,8'),
  (2, 'CPU',       'Celeron 2,6'),
  (3, 'CPU',       'Athlon XP 3000+'),
  (4, 'RAM',       'SDRAM 1GB'),
  (5, 'Sonstiges', 'Eieruhr')
;

INSERT INTO liefert(h_id, w_id, l_preis, l_lieferzeit)
VALUES 
  (1, 1, 200.00, 1),
  (1, 1, 194.00, 6),
  (1, 2, 100.00, NULL),
  (1, 3, 150.00, 7),
  (1, 4,  10.00, 1),
  (1, 5,   5.00, 1),
  (2, 1, 160.00, NULL),
  (2, 1, 190.00, 1),
  (2, 2, 180.00, NULL),
  (2, 3, 170.00, 4),
  (3, 1, 195.00, 2),
  (3, 2, 190.00, 1),
  (4, 1, 150.00, 3),
  (4, 3, 180.00, 5),
  (4, 3, 199.99, 1)
;

SQL-Beispiele

Quellen

  1. Kowarschick (MMDB-Skript): Wolfgang Kowarschick; Vorlesung Multimedia-Datenbanksysteme – Sommersemester 2018; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2018; Quellengüte: 4 (Skript)
  2. Kowarschick (MMDB): Wolfgang Kowarschick; Vorlesung „Multimedia-Datenbanksysteme“; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2016; Quellengüte: 3 (Vorlesung)

Siehe auch