Florians Übung

Aus ProgrammingWiki
Wiki-Quelltext dieser Seite.
<language>SQL</language>
=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.

=ERM=
[[Bild:Flo_Bu_ERM.png |1000px]]
===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.

=RM=
==Variante 1 in Tabellenform==
[[Bild:Flo Bu_RM.jpg |1000px]]

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==
<br>
'''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.

<br><br>

=Datenbank=

<code id="698307c1cd1e6">

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 VARCHAR(10),
    primary key (Kunden_ID)
);
DROP TABLE IF EXISTS Kauft;
CREATE TABLE Kauft (
    Bestellnummer INT,
    Kunden_ID INT,
    Fisch_ID INT,
    Kaufdatum VARCHAR(30),
    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, '50', '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);


</code>

=Abfragen=

<run id="698307c1cd27c">
select Name, Bestand
from Fischart
where Bestand > 0;
</run>

=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.
=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/]
Florians Übung

Suche
