Aus ProgrammingWiki

Inhaltsverzeichnis 1 Datenbank-Beleg Adrian Scheibe 1.1 Überlegung 1.2 ERM 1.3 Relationen-Modell 1.4 Umsetzung in SQL 1.4.1 Umsetzung der Tabellen in SQL 1.4.2 Einfügen von Daten 1.4.3 Ausgabe aller Werte 1.4.4 Beispiel 1 1.4.5 Beispiel 2 1.4.6 Beispiel 3 1.4.7 Beispiel 4 1.4.8 Beispiel 5 1.4.9 Beispiel 6 1.5 Kritische Reflexion 1.5.1 Kardinalitäten 1.5.2 Redundanz 1.5.3 Normalform 1.5.4 IDs 1.5.5 Modellierung des Sachverhalts 1.5.6 Einheiten 1.5.7 Lernpotential 1.6 Quellen 1.6.1 Tools 1.6.2 Wissen

Datenbank-Beleg Adrian Scheibe

Überlegung

Die Datenbank soll mögliche Aufträge in der Raumfahrtindustrie verwalten, anzeigen und speichern können. Das Ziel dabei ist, dass das Modell mithilfe eines ERM verschiedene Aspekte eines solchen Auftrags anzeigt und alle Faktoren übersichtlich sichtbar macht. Die SQL-Datenbank soll währenddessen eine praktische Umsetzung dieses Konzeptes sein, welches auch praktisch verwendet werden könnte. Natürlich wird der Sachverhalt dafür vereinfacht (siehe Reflexion).

ERM

Mögliches ERM zur Verwaltung von Aufträgen in der Raumfahrt. Mit ERDPlus erstellt

Relationen-Modell

Die Entities / Attribute / Relationships aus dem ERM werden in Tabellen gefasst um sie auf die Umsetzung in einer Datenbank (mit SQL) vorzubereiten. Die Vererbung der Foreign-Keys wird schon vorgenommen. Eine vierte Tabelle wird erstellt um die Ansprüche einer n:m-Beziehung zu entsprechen.

Mögliches RM zur Verwaltung von Aufträgen in der Raumfahrt. Mit ERDPlus erstellt

Das Modell bezieht sich auf den prinzipiellen Aufbau des ERM. Den IDs wurden einzigartige Namen zugeteilt, um sie in einer gemeinsamen Tabelle unterscheiden zu können. Die Tabelle Mission wurde angelegt, um eine n:m-Beziehung zu gewährleisten.

Umsetzung in SQL

Umsetzung der Tabellen in SQL

CREATE TABLE Auftrag ( A_ID CHAR(6) PRIMARY KEY, Auftraggeber VARCHAR(30), Laufzeit INT, Budget money ); CREATE TABLE Nutzlast ( N_ID CHAR(6) PRIMARY KEY, Art TINYINT, Masse FLOAT(3), Kosten money, Laufzeit INT, Startfenster DATE, R_ID CHAR(6), FOREIGN KEY (R_ID) REFERENCES Rakete(R_ID) ); CREATE TABLE Rakete ( R_ID CHAR(6) PRIMARY KEY, Treibstoff TINYINT, Startmasse FLOAT(3), Max_nutzlast FLOAT(3), Preis money ); CREATE TABLE Mission ( A_ID CHAR(6), N_ID CHAR(6), FOREIGN KEY (A_ID) REFERENCES Auftrag(A_ID), FOREIGN KEY (N_ID) REFERENCES Nutzlast(N_ID) );

Einfügen von Daten

INSERT INTO Auftrag (A_ID, Auftraggeber, Laufzeit, Budget) VALUES ("b166e2", "EVIL INC. (TM)", 1825, "99,999,999.99"); INSERT INTO Auftrag (A_ID, Auftraggeber, Laufzeit, Budget) VALUES ("52e00c", "Hallsonde Research", 365, "20,000,000.00"); INSERT INTO Nutzlast (N_ID, Art, Masse, Kosten, Laufzeit, Startfenster, R_ID) VALUES ("1a5c47", 12, 12937.059, "11,000,000.00", 1460, "2024-06-08", "9ef35e"); INSERT INTO Nutzlast (N_ID, Art, Masse, Kosten, Laufzeit, Startfenster, R_ID) VALUES ("a4eea2", 2, 3000.000, "876,543.21", 100, "2025-12-12", "9ef35e"); INSERT INTO Nutzlast (N_ID, Art, Masse, Kosten, Laufzeit, Startfenster, R_ID) VALUES ("9baaf1", 2, 256.000, "123,456.78", 69, "2024-08-24", "58f95e"); INSERT INTO Nutzlast (N_ID, Art, Masse, Kosten, Laufzeit, Startfenster, R_ID) VALUES ("1c916c", 5, 3.141, "200,000.00", 420, "2024-08-24", "58f95e"); INSERT INTO Nutzlast (N_ID, Art, Masse, Kosten, Laufzeit, Startfenster, R_ID) VALUES ("d1686e", 1, 9000.000, "18990.00", 1, "2024-05-01", "a73000"); --Preis für 9t Blei INSERT INTO Rakete (R_ID, Treibstoff, Startmasse, Max_nutzlast, Preis) VALUES ("9ef35e", 2, 549000.000, 22800.000, "27,000,000.00"); --Werte für SpaceX Falcon 9 INSERT INTO Rakete (R_ID, Treibstoff, Startmasse, Max_nutzlast, Preis) VALUES ("58f95e", 1, 13000.000, 300.000, "7,500,000.00"); --Werte für RocketLab Electron INSERT INTO Rakete (R_ID, Treibstoff, Startmasse, Max_nutzlast, Preis) VALUES ("a73000", 1, 510000.000, 9100.000, "66,000,000.00"); --Werte für Saturn I INSERT INTO Mission (A_ID, N_ID) VALUES ("b166e2", "1a5c47"); INSERT INTO Mission (A_ID, N_ID) VALUES ("b166e2", "a4eea2"); INSERT INTO Mission (A_ID, N_ID) VALUES ("52e00c", "1a5c47"); INSERT INTO Mission (A_ID, N_ID) VALUES ("52e00c", "9baaf1"); INSERT INTO Mission (A_ID, N_ID) VALUES ("52e00c", "1c916c"); INSERT INTO Mission (A_ID, N_ID) VALUES ("52e00c", "d1686e");

Ausgabe aller Werte

SELECT * FROM Auftrag; --wählt alle Einträge von 'Auftrag' aus SELECT * FROM Nutzlast; SELECT * FROM Rakete; SELECT * FROM Mission;

ausführen

Beispiel 1

--wählt R_ID und dazugehörige Nutzlast aus der Tabelle Rakete aus SELECT Rakete.R_ID, Rakete.Max_nutzlast FROM Rakete;

ausführen

Beispiel 2

--wählt die Auftrag-IDs und Budgets von allen Aufträgen aus, die eine Laufzeit von genau 1825 Tagen haben SELECT Auftrag.A_ID, Auftrag.Budget FROM Auftrag WHERE Auftrag.Laufzeit = 1825;

ausführen

Beispiel 3

--wählt einzigartige Rakten-IDs und die dazugehörige Nutzlast von Raketen aus, die eine Startmasse von genau oder mehr als 549t haben SELECT DISTINCT Nutzlast.R_ID, Rakete.Max_nutzlast FROM Rakete, Nutzlast WHERE Rakete.R_ID = Nutzlast.R_ID AND Startmasse >= 549000;

ausführen

Beispiel 4

--wählt Auftrag-ID und das dazugehörige Budget von Auftraggebern aus, die die Nutzlast mit der ID '1a5c47' beinhalten und einzigartig sind SELECT Auftrag.A_ID, Auftrag.Budget FROM Auftrag, Mission WHERE Auftrag.A_ID = Mission.A_ID AND Mission.N_ID = "1a5c47";

ausführen

Beispiel 5

--erstellt neue Spalte in Tabelle 'Auftrag' ALTER TABLE Auftrag ADD COLUMN Budget_Tag money; --fügt in neue Spalte 'Budget_Tag' das verfügbare Buget pro Tag der Laufzeit ein (Budget : Laufzeit) UPDATE Auftrag SET Budget_Tag = ((replace((SELECT Auftrag.Budget FROM Auftrag),',','')) / (SELECT Auftrag.Laufzeit FROM Auftrag)); SELECT * FROM Auftrag WHERE A_ID = "b166e2";

ausführen

Beispiel 6

--erstellt neue Spalte in Tabelle 'Auftrag' ALTER TABLE Auftrag ADD COLUMN Anzahl_Nutzlast INT; --fügt in neue Spalte 'Anzahl_Nutzlast' in 'Auftrag' die Anzahl die jeweiligen Nutzlasten ein UPDATE Auftrag SET Anzahl_Nutzlast = (SELECT COUNT(*) FROM Mission WHERE Auftrag.A_ID = Mission.A_ID); --wählt Auftrag-IDs und Anzahl_Nutzlast von Aufträgen aus, die mehr als einen Eintrag in Mission haben (entspricht mehr als 1 Nutzlast) SELECT Auftrag.A_ID, Auftrag.Anzahl_Nutzlast FROM Auftrag WHERE (SELECT COUNT(*) FROM Mission WHERE Auftrag.A_ID = Mission.A_ID) > 1;

ausführen

Kritische Reflexion

Kardinalitäten

Die Kardinalität gibt in einer Datenbank die Art der Verknüpfung der Tabellen an. Bei einer 1:1 Beziehung existiert für eine Tabelle immer nur eine entsprechende andere Tabelle. 1:n bedeutet dagegen, dass für eine Tabelle beliebig viele andere Tabellen existieren können. Eine n:m Beziehung beinhaltet beliebig viele Tabellen, welche mit beliebig vielen anderen Tabellen verknüpft werden. Für letztere Art ist aufgrund der Komplexität eine dritte "Mittlertabelle" nötig um die Beziehung der Tabellen zu erfassen.

Im Beispiel der Datenbank bedeutet das folgendes: Eine Rakete kann mehrere Nutzlasten tragen, also ist es eine 1:n-Beziehung. Währenddessen können mehrere Aufträge mehrere, sich auch überschneidende Nutzlasten verlangen, also ist es eine n:m-Beziehung. Aus diesem Grund existiert auch eine vierte Tabelle "Mission".

Redundanz

Um Redundanzen in den Datensätzen zu vermeiden und damit das Befüllen der Tabellen reibungsfrei verlaufen kann, beinhaltet die Tabelle keine redundanten Informationen. Zwar kommen die ID-Werte der einzelnen Einträge mehrere Male vor, doch ist dies erwartet, da diese foreign Keys in anderen Tabellen sind und daher für die Verknüpfung dieser Tabellen sorgen.

Normalform

Im besten Fall ist eine Datenbank atomar, das heisst in die Tabelle eingetragene Werte liegen in einem Datentyp vor, der nicht weiter aufgeteilt werden kann. Somit werden einzelne Datensätze voneinander abgeschottet und unnötige Misverständnisse vermieden. Bsp. sind Laufzeit und Startfenster nicht als 2 Daten in einer Spalte zusammengefasst, sondern liegen getrennt vor. Das Datum für das Startfenster könnte mit dem Format YYYY-MM-DD theoretisch noch in diese einzelnen Einheiten aufgeteilt werden, doch ist dies nicht sinnvoll, da sonst bspw. nur der Tag und nicht der Monat oder Jahr bei einem neuen Eintrag gegeben sein könnte, was ungünstig ist. Eine solche Datenbank entspricht der 1. Normalform.

In der 2. Normalform werden die daten weiterhin in logisch voneinander getrennte Tabellen / Abschnitte getrennt um die logische Übersichtlichkeit der Datenbank zu erhöhen. Das geschieht in dieser Datenbank bspw. dadurch, dass ein Auftrag und dazugehörige Nutzlast sowie die Rakete, die diese transportiert getrennt vorliegen. Verknüpft werden die Tebellen mit einzigartigen IDs, die in für den Sachverhalt günstigen Kardinalitäten vorliegen. Somit erfüllt die DB auch die Anforderungen der 2. NF.

Um die Voraussetzungen für die 3. NF zu erfüllen müsste eine solche DB unnötige Abhängigkeiten der gegebenen Werte vermeiden, indem diese ebenfalls getrennt vorliegen. Das ist allerdings in dieser DB nicht gegeben, da z.B. eine neue Tabelle für die Treibstoffarten der Rakete oder der Auftraggeber angelegt werden könnte. Aus diesem Grund erfüllt die DB "nur" die Anforderungen der 2. NF, was allerdings trotzdem für eine relativ simple DB ausreichen sollte, welche diese ist. Daher ist es nicht immer notwendig die Integrität einer DB in das höchste Maß darzustellen, wenn diese nur demonstrativen Zwecken dient und in keinem kritischen (Produktions-) Umfeld eingesetzt wird.

IDs

Alle Entities haben eine einzigartige ID um sie im System voneinander unterscheiden zu können. Diese werden mit 6-stelligen Hex-Werten befüllt, da es so viele Kombinationsmöglichkeiten gibt und zudem alle IDs die selbe Anzahl an Zahlen besitzen, was die Umsetzung erleichtern kann.

Modellierung des Sachverhalts

Die Raumfahrt ist nicht ohne Grund bekannt dafür, schwer zu sein. Das trifft natürlich auch auf das Umfeld solcher Missionen zu. Um den Sachverhalt dennoch in eine Datenbank von mäßigem Umfang darstellen zu können, sind vereinfachungen notwendig. So werden bspw. nicht verschiedene Unteraufträge berücksichtigt, die im Budget berücksichtigt werden müssten zudem beinhaltet die DB keine kompletten Aufzeichnungen von z.B. Raketen oder Aufträgen, da diese den Umfang zum einen Sprengen würden und zum anderen oft vertraulicher Natur sind. Die DB soll somit nur ein Beispiel für die Umsetzung eines solchen Sachverhaltes auf vereinfachte Weise sein.

Einheiten

Das wohl größte Problem der DB ist, dass die in den Tabellen eingetragenen Einheiten nicht sofort ersichtlich sind. Zwar wurde die Tabelle zum großen Teil mit Standardeinheiten befüllt, doch könnte es zu Problemen kommen falls z.B. ein Budget in Euro und die Kosten für eine Rakete in USD angegeben werden.

Lernpotential

Zusammenfassend lässt sich sagen, dass selbst das Erstellen einer relativ simplen und nicht für den Produktiveinsatz geigneten DB durchaus ein großes Lernpotenzial birgt. Zum einen bringt das Denken in Kardinalitäten und das Anpassen der DB mithilfe der Normalformen ein besseres Verständnis über die Funktionsweise und die Überlegungen einer DB. Und zum anderen ist es oft einfach nur interessant, sich mit Sachverhalten unter dem Gesichtspunkt einer strukturierten DB auseinanderzusetzen und Probleme auch so anzugehen.

Quellen

Tools

- ERDPlus

- Programming Wiki

Wissen

- W3Schools

- Datenbanken Verstehen