Florian

Aus ProgrammingWiki

Inhaltsverzeichnis

1 Aquariengeschäft – Datenbankprojekt

Aquariengeschäft – Datenbankprojekt

Ziel der Datenbank

Die Datenbank dient dazu, die Becken und Fische eines Aquariengeschäfts sowie die Käufe der Kunden zu verwalten. Dabei soll abgebildet werden, welche Fische in welchen Becken sind und welche Kunden welche Fische kaufen. Damit kann auch der Jahresumsatz und die Nachfrage ermittelt werden.

ER-Modell

Erläuterung des Modells

Das ER-Modell beschreibt die Daten eines Aquariengeschäfts mit den Entitäten Becken, Fischart und Kunde. Ein Becken kann mehrere Fischarten enthalten, daher besteht zwischen Becken und Fischart eine 1:n-Beziehung. Zwischen Kunde und Fischart liegt eine n:m-Beziehung, da ein Kunde mehrere Fischarten kaufen kann und eine Fischart von mehreren Kunden gekauft werden kann. Diese Beziehung wird durch kauft mit den Attributen Kaufdatum, Anzahl und Gesamtpreis ergänzt. Die Attribute "Namen" sind nicht eindeutig, da es "Max Müller" mehrmals geben könnte. Deshalb kommen die "ID's" ins Spiel für die Eindeutigkeit.

Relationales Modell

Variante 1 in Tabellenform

In diesem Modell liegt leider ein Fehler vor, da der Primärschlüssel Fisch_ID in der Beckentabelle als Fremdschlüssel auftaucht. Dies ist bei der 1:n Beziehung nicht richtig, aber mir ist es leider erst nachher aufgefallen.

Variante 2 in Zeilenform

Beckentabelle (Becken_ID; Wasserart; Volumen)

Fischarttabelle (Fisch_ID; Name; Preis; Bestand; Becken_ID)

Kundentabelle (Kunden_ID; Name; Straße; Hausnummer; Postleitzahl)

Kauftabelle (Bestellnummer; Kaufdatum; Anzahl; Gesamtpreis; Fisch_ID; Kunden_ID)

Erläuterung des Modells

Im relationalen Modell werden die Entitäten als Tabellen umgesetzt. Die 1:n-Beziehung wird durch einen Fremdschlüssel (Becken_ID) in der Tabelle Fischart dargestellt. Die n:m-Beziehung wird durch die Zwischentabelle Kauf realisiert, die die Fremdschlüssel Kunden_ID und Fisch_ID enthält. Zusätzlich sorgt eine Bestellnummer als Primärschlüssel für die eindeutige Identifikation jeder Bestellung, weil ein Kunde an einem tag die gleiche Bestellung mehrmals machen kann. Man könnte stattdessen auch eine Version ohne Primärschlüssel machen, wenn man eine Uhrzeit einfügt als Attribut. Diese kann ja an dem selben Tag nur schwer zwei mal vorkommen. Die Adresse wurde bei der Kundentabelle ausgeführt, damit die Attribute atomar (unteilbar) sind.

SQL-Implementierung

DROP TABLE IF EXISTS Becken;
CREATE TABLE Becken (
    Becken_ID INT,
    Wasserart VARCHAR(30),
    Volumen INT,
    primary key (Becken_ID)
);

DROP TABLE IF EXISTS Fischart;
CREATE TABLE Fischart (
    Fisch_ID INT,
    Name VARCHAR(50),
    Preis DECIMAL(5,2),
    Bestand INT,
    Becken_ID INT,
    primary key (Fisch_ID),
    foreign key (Becken_ID) references Becken(Becken_ID)
);

DROP TABLE IF EXISTS Kunde;
CREATE TABLE Kunde (
    Kunden_ID INT,
    Name VARCHAR(50),
    Strasse VARCHAR(50),
    Hausnummer VARCHAR(10),
    Postleitzahl INT(5),
    primary key (Kunden_ID)
);
DROP TABLE IF EXISTS Kauft;
CREATE TABLE Kauft (
    Bestellnummer INT,
    Kunden_ID INT,
    Fisch_ID INT,
    Kaufdatum DATE,
    Anzahl INT,
    Gesamtpreis DECIMAL(7,2),  
    primary key (Bestellnummer),  
    foreign key (Fisch_ID) references Fischart (Fisch_ID),
    foreign key (Kunden_ID) references Kunde (Kunden_ID)
);

INSERT INTO Becken VALUES (1, 'Süßwasser', 350);
INSERT INTO Becken VALUES (2, 'Süßwasser', 60);
INSERT INTO Becken VALUES (3, 'Meerwasser', 200);

INSERT INTO Fischart VALUES (1, 'Guppy', 2.50, 30, 1);
INSERT INTO Fischart VALUES (2, 'Neonsalmler', 1.80, 0, 1);
INSERT INTO Fischart VALUES (3, 'Kugelfisch', 15.00, 5, 2);
INSERT INTO Fischart VALUES (4, 'Clownfisch', 25.00, 8, 3);

INSERT INTO Kunde VALUES (1, 'Max Müller', 'Hauptstraße', '12', '12345');
INSERT INTO Kunde VALUES (2, 'Laura Schmidt', 'Bahnhofstraße', '7A', '54321');
INSERT INTO Kunde VALUES (3, 'Tim Wagner', 'Gartenweg', '3', '11111');

INSERT INTO Kauft VALUES (1, 1, 1, '2026-02-01', 5, 12.50);
INSERT INTO Kauft VALUES (2, 1, 2, '2026-02-01', 10, 18.00);
INSERT INTO Kauft VALUES (3, 2, 4, '2026-02-02', 2, 50.00);
INSERT INTO Kauft VALUES (4, 3, 3, '2026-02-02', 1, 15.00);

Beispielabfragen

select Name, Bestand
from Fischart
where Bestand > 0;

SELECT SUM(Gesamtpreis) AS Gesamtumsatz
FROM Kauft;

SELECT Bestellnummer,
       Anzahl,
       Preis,
       Anzahl * Preis AS Berechneter_Gesamtpreis
FROM Kauft
JOIN Fischart ON Kauft.Fisch_ID = Fischart.Fisch_ID;

SELECT 
    Kauft.Bestellnummer,

    Kunde.Name AS Kunde,
    Kunde.Strasse || ' ' || Kunde.Hausnummer AS Adresse,
    Kunde.Postleitzahl AS PLZ,

    Kauft.Kaufdatum,

    Fischart.Name AS Fischart,
    Fischart.Preis AS Einzelpreis,
    Kauft.Anzahl,

    (Fischart.Preis * Kauft.Anzahl) AS Zwischensumme,

    Kauft.Gesamtpreis AS Gespeicherter_Gesamtpreis

FROM Kauft

JOIN Kunde 
    ON Kauft.Kunden_ID = Kunde.Kunden_ID

JOIN Fischart 
    ON Kauft.Fisch_ID = Fischart.Fisch_ID

ORDER BY Kauft.Bestellnummer;

kritische Reflexion zu Modellierung und Umsetzung

Die Modellierung der Datenbank zeigt, dass die Abbildung von Beziehungen zwischen Becken, Fischarten und Kunden nicht immer trivial ist. Besonders die n:m-Beziehung zwischen Kunde und Fischart erfordert eine Zwischentabelle, um Käufe korrekt zu speichern, was die Komplexität erhöht. Auch die Entscheidung, die Adresse aufzuteilen und die Anzahl der Fische pro Kauf zu erfassen, verdeutlicht, dass praktische Anforderungen an die Datenbank zu Anpassungen im Modell führen. Kritisch ist, dass bestimmte Informationen, wie z. B. die genaue Anzahl einzelner Fische in verschiedenen Becken, nur schwer eindeutig dargestellt werden können. Dies zeigt, dass bei der Modellierung Abwägungen zwischen Genauigkeit, Übersichtlichkeit und Umsetzbarkeit notwendig sind. Schwierig war es beim SQL darauf zu achten, dass wenn man Zahlen als INT, Datum als DATE und Buchstaben als VARCHAR haben möchte, sehr stark auf die Einhaltung achten muss. Es bringt aber den Vorteil, dass zum Beispiel keine Namen in der Zeile Datum landet. Man könnte ebenfalls den Befehl "NOT NULL" hinter die jeweiligen Zeilen machen, damit die Datensätze nicht leer sind. Man hätte den Gesamtpreis auf der Rechnung außerdem nicht als Attribut verwenden sollen, sondern wie in Abfrage 3 aus Preis und Anzahl jeweils errechnen.

Quellen und Tools

ERDPlus https://erdplus.com– für die Erstellung des ER-Modells

Programming Wiki – für die Umsetzung in SQL und Tests der Tabellen

Learning View https://learningview.org/

ChatGPT - für die Erstellung der Datensätze, um Zeit zu sparen

Florian

Inhaltsverzeichnis

Aquariengeschäft – Datenbankprojekt

Ziel der Datenbank

ER-Modell

Erläuterung des Modells

Relationales Modell

Variante 1 in Tabellenform

Variante 2 in Zeilenform

Erläuterung des Modells

SQL-Implementierung

Beispielabfragen

kritische Reflexion zu Modellierung und Umsetzung

Quellen und Tools

Suche