PMG2224 1/DB Beleg/Ella

Wiki-Quelltext dieser Seite.

<language>SQL</language>
<center> 
'''''Vom ERM über das Relationshipmodell zur Datenbank'''''

'''Verbildlichung am Aufbau eines Reitvereins''' 
<br>

</center>


=='''Welche Vorlage bietet ein Reitverein für eine Datenbank?'''== 

Ein größerer Reitverein setzt sich aus vielen verschiedenen Komponenten zusammen. Er ist also zum einen sehr vielfältig aber vor allem ist auch jeder Verein für sich einmalig. Diese Komplexität und Individualität bietet sich perfekt dafür an, um den Sachverhalt in ein strukturiertes ERM, RM und später in eine Datenbank zu transformieren. <br> 
> Was nutzt eine Datenbank einem Reitverein? <br>
Das Erstellen einer solchen Datenbank kann auch durchaus für einen bestehenden Verein interessant und nützlich sein. Wie bereits angedeutet, könnten große Datenmengen übersichtlich dargestellt werden. So kann der Vorstand schnell darauf zurückgreifen. Eine effiziente, dauerhafte und fehlerfreie Speicherung von Daten kann gewährleistet werden. Hat man alle Informationen an einem Ort können somit auch Veränderungen, wenn z.B. ein Mitglied den Verein verlassen hat, leicht notiert werden. Eine bedarfsgerechte Bereitstellung von spezifischen Daten ist also durchaus von Nutzen.
<br>
<br>

=='''Modellierung in einem ERM'''==

[[Bild:EllaH_1.03._fertig.PNG]]
<br>

=='''Erläuterung aller vorhandenen Strukturen'''==

Mein Entity-Relationship-Modell setzt sich aus mehreren Grundstrukturen zusammen. Zum einen gibt es die Entitäten Vorstand, Trainer und Vereinsmitglieder. Sie werden ergänzt durch variierende Attribute wie Vorname, Geburtsjahr oder Vereinszugehörigkeit. Zwischen den Entitäten herrscht eine 1:n Kardinalität. (= Ein Vorstand bildet mehrere Trainer aus. Ein Trainer wird von einem Vorstand ausgebildet. Und: Ein Trainer unterrichtet mehrere Vereinsmitglieder. Ein Vereinsmitglied wird von einem Trainer unterrichtet.) <br>
Die drei Normalformen wurden folgender Maßnahmen gewährleistet: <br>
1. Normalform: Jedes Attribut muss in atomarer Form vorliegen. Hierfür nutzte ich z.B. die expliziten Attribute ‚Vor- und Nachname‘ statt der Verallgemeinerung ‚Name‘.  <br>
2. Normalform: Es muss ein Schlüsselattribut geben. Diese Bedingung wird durch die speziellen Attribute ‚Vorstandsnummer‘, ‚Trainernummer‘ und ‚Vereinsmitgliedsnummer‘ garantiert, wobei sich jede Nummer immer eindeutig einer Person zuordnen lässt. <br>
3. Normalform: Jedes andere Attribut des Objektes muss vom Schlüsselattribut abhängig sein. Z.B.: Verändert sich die Trainernummer, dann verändern sich auch die Attribute, da eine andere Person betrachtet wird.
<br>

=='''Transformation in ein Relationenmodell'''==

[[Bild:EllaH_08.03..PNG]]
<br>

=='''Erstellen der Datenbank'''==

<code id="65bc9f20a0b3e">
CREATE TABLE Vorstand(
V_Vorname varchar(30),
V_Nachname varchar(30),
V_Geburtsjahr int(4),
V_Nummer int(10),
PRIMARY KEY (V_Nummer)
);

CREATE TABEL Trainer(
T_Spitzname varchar(30),
T_Nachname varchar(30),
T_Vereinszugehörigkeit int(4),
T_Geburtsjahr int(4),
T_Nummer int(10),
PRIMARY KEY (T_Nummer),
FOREIGN KEY (V_Nummer) REFERENCES Vorstand(V_Nummer)
);

CREATE TABLE Vereinsmitglied(
VM_Vorname varchar(30),
VM_Nachname varchar(30),
VM_Geburtsjahr int(4),
VM_Lieblingspferd varchar(30),
VM_Nummer int(60),
PRIMARY KEY (VM_Nummer),
FOREIGN KEY (T_Nummer) REFERENCES Trainer(T_Nummer)
);

INSERT INTO Vorstand VALUES ('Jürgen', 'Jürgenson', '1989', 1111111111);
INSERT INTO Vorstand VALUES ('Sonja', 'Soße'; '1940', 1111111112);

INSERT INTO Trainer VALUES ('Siggi', 'Siegbert', '2000', '1982', 2222222222, 1111111111);
INSERT INTO Trainer VALUES ('Louis', 'Lunte', '1991', '1961', 2222222223, 1111111111);
INSERT INTO Trainer VALUES ('Cani', 'Camembert', '2020', '2000', 2222222224, 1111111112);
INSERT INTO Trainer VALUES ('Cloedia', 'von Rungs', '2015', '1989', 2222222225, 1111111112);

INSERT INTO Vereinsmitglied VALUES ('Hanne', 'Hannelise', '2010', 'PandaPoo', 0000000000, 2222222222);
INSERT INTO Vereinsmitglied VALUES ('Annika', 'Anabell', '2007', 'Rüdiger Ross', 0000000001, 2222222222);
INSERT INTO Vereinsmitglied VALUES ('Johanna', 'Johannisbeere', '2009', 'PandaPoo', 0000000002, 2222222223);
INSERT INTO Vereinsmitglied VALUES ('Ursula', 'Ufo', '2009', 'PandaPoo', 0000000003, 2222222225);
INSERT INTO Vereinsmitglied VALUES ('Dieter', 'Dung', 2008', 'Böhnchen', 0000000004, 2222222224);
INSERT INTO Vereinsmitglied VALUES ('Lara', 'Luftpumpe', '2005', 'Rüdiger Ross', 0000000005,2222222224);
INSERT INTO Vereinsmitglied VALUES ('Fiona, 'Luftpumpe', '2005', 'Rüdiger Ross', 0000000006, 2222222224);

</code>
<br>
=='''Erstellen von Abfragen'''==

Alle Vereinsmitglieder anzeigen lassen
<run id="65bc9f20a0b83">
SELECT VM_Vorname, VM_Nachname FROM Vereinsmitglied;
</run>
<br>
Alle Trainer beim Vorstand Sonja anzeigen lassen
<run id="65bc9f20a0b83">
SELECT * FROM Trainer,Vorstand WHERE Trainer.V_Nummer = Vorstand.V_Nummer and V_Vorname = 'Sonja';
</run>
<br>
Alle Vereinsmitglieder mit dem Lieblingspferd PandaPoo anzeigen lassen
<run id="65bc9f20a0b83">
SELECT * FROM Vereinsmitglied WHERE VM_Lieblingspferd = 'PandaPoo';
</run>
<br>

=='''Kritische Reflexion'''==

Welche Probleme könnten in Zukunft mit dem Code auftreten? <br>
Die ersten Probleme entstehen, wenn sich die Beziehung zwischen dem Vorstand und den Trainern oder den Trainern und den Vereinsmitgliedern ändert. Wenn also aus den 1 zu n Beziehungen n zu m Beziehungen werden. Sprich, wenn ein Trainer weiterhin mehrere Vereinsmitglieder trainiert, aber die Vereinsmitglieder nun auch mehrere Trainer haben, welche sie unterrichten. Dann fehlt eine jeweils dritte Tabelle, die die Verbindungen herstellt, wodurch ein solcher Sachverhalt nicht abgefragt werden könnte. Wenn man nur die Abfragen betrachtet, dann könnte es außerdem problematisch werden, wenn es z.B. zwei 'Vorständler' gibt die Sonja heißen. Es wird dann kompliziert, wenn man alle Trainer ausgegeben bekommen möchte, die Sonja als Vorstand haben, von welcher es zwei gibt. Man müsste die gesuchte Sonja dann direkt mit ihrer Vorstandsnummer suchen. 

=='''Quellen'''==

https://erdplus.com/