PMG2224 1/DB Beleg/Camillo

Wiki-Quelltext dieser Seite.

<language>SQL</language>
= DBMS zum Veranstaltungsmanagement =

== Ziel der Datenbank ==

Das Ziel dieses Datenbankmanagementsystems für ein Veranstaltungsmanagementsystem ist es, eine effiziente und organisierte Methode zur Verwaltung von Veranstaltungen zu bieten. Es ermöglicht die Speicherung und Abfrage von Daten zu Veranstaltungen, Veranstaltern, Teilnehmern, Tickets und Sponsoren. Mit diesem System können Benutzer Informationen über verschiedene Veranstaltungen abrufen, die Details der Teilnehmer verwalten, Tickets für Veranstaltungen ausstellen und die Beiträge von Sponsoren verfolgen. Es erleichtert auch die Verknüpfung von Veranstaltungen mit ihren jeweiligen Veranstaltern und Sponsoren.

== Modellierung in einem ERM ==

[[Bild:Camillo_Image.png]]

== Transformation in das Relationenmodell ==

 Veranstalter(<u>VeranstalterID</u>, Name, Adresse, Telefonnummer)
 Veranstaltungen(<u>VeranstaltungsID</u>, Name, Datum, Ort, VeranstalterID)
 Teilnehmer(<u>TeilnehmerID</u>, Name, Email)
 Tickets(<u>TicketID</u>, VeranstaltungsID, TeilnehmerID, Preis)
 Sponsoren(<u>SponsorID</u>, Name, Betrag)
 Veranstaltung_Sponsor(<u>VeranstaltungsID</u>, SponsorID)

Ein Veranstalter organisiert mehrere Veranstaltungen (1:n).
Ein Sponsor sponsort mehrere Veranstaltungen (1:n).
Ein Ticket gewährt Zutritt zu einer Veranstaltung (1:1).
Ein Teilnehmer erwirbt ein Ticket (1:1).

== Erstellen der DB (Struktur/notwendige Datensätze) ==

<code id="65eac36b775b8">
CREATE TABLE Veranstalter (
    VeranstalterID INT PRIMARY KEY,
    Name VARCHAR(100),
    Anschrift VARCHAR(255),
    Ort VARCHAR(255),
    Telefonnummer VARCHAR(15)
);

CREATE TABLE Veranstaltungen (
    VeranstaltungsID INT PRIMARY KEY,
    Name VARCHAR(100),
    Datum DATE,
    Ort VARCHAR(255),
    VeranstalterID INT,
    FOREIGN KEY (VeranstalterID) REFERENCES Veranstalter(VeranstalterID)
);

CREATE TABLE Teilnehmer (
    TeilnehmerID INT PRIMARY KEY,
    Name VARCHAR(100),
    Email VARCHAR(255)
);

CREATE TABLE Tickets (
    TicketID INT PRIMARY KEY,
    VeranstaltungsID INT,
    TeilnehmerID INT,
    Preis DECIMAL(5,2),
    FOREIGN KEY (VeranstaltungsID) REFERENCES Veranstaltungen(VeranstaltungsID),
    FOREIGN KEY (TeilnehmerID) REFERENCES Teilnehmer(TeilnehmerID)
);

CREATE TABLE Sponsoren (
    SponsorID INT PRIMARY KEY,
    Name VARCHAR(100),
    Betrag DECIMAL(7,2)
);

CREATE TABLE Veranstaltung_Sponsor (
    VeranstaltungsID INT,
    SponsorID INT,
    FOREIGN KEY (VeranstaltungsID) REFERENCES Veranstaltungen(VeranstaltungsID),
    FOREIGN KEY (SponsorID) REFERENCES Sponsoren(SponsorID),
    PRIMARY KEY (VeranstaltungsID, SponsorID)
);
</code>


----

<code id="65eac25f8311c">
INSERT INTO Veranstaltungen VALUES (1, 'Freiluftkonzert', '22-02-24', 'Dresden', 1);
INSERT INTO Veranstaltungen VALUES (2, 'Szenische Lesung', '28-02-24', 'Kamenz', 2);
INSERT INTO Veranstaltungen VALUES (3, 'Freiluftkonzert', '01-03-24', 'Dresden', 1);

INSERT INTO Veranstalter VALUES (1, 'Dresdner Philharmonie', 'Schlossstraße 2', 'Dresden', 12345678);
INSERT INTO Veranstalter VALUES (2, 'Leseclub Kamenz', 'Hauptstraße 12', 'Kamenz', 87654321);
INSERT INTO Veranstalter VALUES (3, 'Deutsch-sorbisches Volkstheather Bautzen', 'Theaterplatz 1', 'Bautzen', 18273645);

INSERT INTO Teilnehmer VALUES (1, 'Ad Rian', 'rianad@jan.is');
INSERT INTO Teilnehmer VALUES (2, 'Wol Tär', 'woltaer123@pmg-bautzen.lernsax.de');
INSERT INTO Teilnehmer VALUES (3, 'Deez Who', 'illegal@gmail.com');

INSERT INTO Tickets VALUES (1, 1, 1, 90.00);
INSERT INTO Tickets VALUES (2, 2, 2, 00.00);
INSERT INTO Tickets VALUES (3, 3, 2, 40.00);

INSERT INTO Sponsoren VALUES (1, 'Hallsonde Gesellschaft', 800.00);
INSERT INTO Sponsoren VALUES (2, 'Kompression INC.', 1200.00);
INSERT INTO Sponsoren VALUES (3, 'DOS GmbH', 2.00);

INSERT INTO Veranstaltung_Sponsor VALUES (1, 1);
INSERT INTO Veranstaltung_Sponsor VALUES (2, 2);
INSERT INTO Veranstaltung_Sponsor VALUES (3, 1);
INSERT INTO Veranstaltung_Sponsor VALUES (3, 3);
</code>

== Erstellen von verschiedenen Abfragen ==

'''Alle Teilnehmer ausgeben'''
<run id="65e184b911c93">
SELECT * FROM Teilnehmer;
</run>

----

'''Alle Veranstaltungen am 22.02.2024 ausgeben'''
<run id="65e184b911ce4">
SELECT * FROM Veranstaltungen WHERE Datum='22-02-24'; 
</run>

----

'''Email aller Teilnehmer, die ein Ticket im Wert von über 50 € besitzen, ausgeben'''
<run id="65e184b911d30">
SELECT Teilnehmer.Email FROM Teilnehmer, Tickets WHERE Teilnehmer.TeilnehmerID = Tickets.TeilnehmerID AND Tickets.Preis > 50;
</run>

----
'''Alle Sponsoren mit einem Spendenwert zwischen 700 € und 1000 € ausgeben'''
<run id="65eab73b1a15a">
SELECT Name FROM Sponsoren WHERE 700 < Betrag AND Betrag < 1000;
</run>

----

'''Alle Veranstaltungen mit mehr als einem Sponsor ausgeben'''
<run id="65eab16fe3982">
SELECT V.Name, V.Datum FROM Veranstaltungen V WHERE (SELECT COUNT(*) FROM Veranstaltung_Sponsor VS WHERE V.VeranstaltungsID = VS.VeranstaltungsID) > 1;
</run>

== Kritische Reflexion zu Modellierung und Umsetzung ==

Das DBMS stellt eine realistische und praktische Anwendung von SQL dar, die es ermöglicht, Datenbank-Konzepte umzusetzen. Das DBMS ist komplex genug, um eine Vielzahl von SQL-Konzepten und -Techniken zu demonstrieren, einschließlich Tabellenerstellung, Beziehungen, Primär- und Fremdschlüssel und komplexe Abfragen. Darüber hinaus stellt das DBMS eine Reihe von Problemen dar, die gelöst werden müssen, wie z.B. das Verwalten von Beziehungen zwischen Tabellen und das Durchführen komplexer Abfragen.

Allerdings hat dieses DBMS auch seine Grenzen. Es ist ein vereinfachtes Modell und erfüllt nicht alle Anforderungen eines realen Veranstaltungsmanagementsystems. Beispielsweise fehlen Funktionen zur Verwaltung von Mitarbeiterdaten, zur Verfolgung von Veranstaltungskosten oder zur Durchführung von Marketingaktivitäten. 

=== Normalform ===

Die Tabellen sind weitgehend in dritter Normalform: Die Bestandteile sind atomar (Ausnahme Straße - Hausnummer), es gibt nur einen einteiligen Primärschlüssel, weshalb die Prüfung auf die 2. NF entfällt und hängen nicht voneinander ab. Eine Ausnahme bilden die Tabellen, in denen Veranstalter und Ort vorkommen, die voneinander abhängen. Diese Tabellen befinden sich also in 2. NF.

=== Kardinalität ===

Das Modell hat m:n Beziehungen vermieden, was komplizierte Relationen verhindert. In einer ausführlicheren Variante hätte die Beziehung Teilnehmer - Ticket auch (1:n) lauten können, oder kombinierte Tickets, die Zutritt zu mehreren Veranstaltungen gewähren implementiert werden können.

== Verwendete Tools ==

* ERDplus