Toni

Aus ProgrammingWiki

Bearbeiten Sie ein Datenbank-Projekt zu einem Thema Ihrer Wahl.

Dazu gehören

   Ziel der Datenbank ("Begründung" der Themenwahl)
   Modellierung in einem ERM
   Transformation in das Relationenmodell
   Erstellen der DB (Struktur/notwendige Datensätze)
   Erstellen von verschiedenen Abfragen (unterschiedlicher „Schwierigkeit“)
   kritische Reflexion zu Modellierung und Umsetzung 

Wichtige Merkmale der Modelle (Kardinalität, Normalform, ...) sind zu erläutern. Das ERM ist als Bild (z.B. erzeugt mit dem Tool "Dia") einzufügen.

Vllt. noch den Text unten bearbeiten

Inhaltsverzeichnis 1 Themenwahl & Beschreibung des Modells 2 ERM und RM 3 Kardinalitäten: 4 Normalformen: 5 Die Datensätze... 6 kritische Reflexion zu Modellierung und Umsetzung 7 Quellen

Themenwahl & Beschreibung des Modells

Produktionsstruktur eines Unternehmens. Das fiktive Unternehmen fertigt bestimmte Teile, welche als "Auftragsnummer" an die Konstruktionsabteilung gegeben werden, die die Pläne für diese Teile erstellt. Hinter der Auftragsnummer steht der ganze Auftrag, würde man die Datenbank weiter ausführen, so könnte man dort die einzelnen Teile für den jew. Auftrag aufführen.

Ab hier übernimmt die Datenbank alle anfallenden Produktionsdaten. So gehören zum Unternehmen weiere Abteilungen : wie z.B. die Produktionsabteilung, welche neben der Konstruktionsabteilung, eigenständige Tätigkeiten übernimmt. Um ihre Arbeit auszuführen werden die Pläne übergeben. Diese enthalten z.B. Stücklisten oder Zeichnugen (für die Produktionsabteilung mit den Arbeitern wichtig-> um Teile zu lasern, schweißen, ... )*. Die benötigten Teile können dann von den Arbeitern/Abteilungen aus dem Lager geholt werden, bzw kann überprüft werden, ob genügend vorhanden sind, um den Auftrag auszuführen.

Die Firma besitzt mehrere Konstruktionsabteilungen, mehrere Produktionsabteilungen und ein Lager mit allen Produktionsmitteln. Wobei die Datenbank noch dazu die Arbeiter der Produktionsabteilungen aufführt.

Das Lager ist zuerst auf 1 begrenzt, sodass es auch final für alle "zugänglich" wird (1:n), doch sollte das fiktive Unternehmen wachsen so kann das Lager erweitert werden.

...* zusätzlich findet diese weitergabe in der Realität statt, was für die Datenbank hier nicht von Interesse ist, dennoch könnte man die CAD-Dateien auch in der Datenbank speichern und somit einen digitalen Überblick behalten -> ERP

Kommentar Ich hoffe, dass die Datenbank nicht "nur" zeigt, welche Datensätze das Unternehmen verarbeitet, sondern auch über den Fertigungsprozess informieren kann. Diese Umsetztung gestaltete sich offenbar schwieriger als zuvor gedacht, daher sind einige Entitäten weggelassen worden, obwohl sie in dem Text darüber genannt sind. -> Zeitgründe, Komplexität ... Mehr in der Auseinandersetzung ...

ERM und RM

---

Kardinalitäten:

...Sie beschreiben die Beziehungen von einzelnen Entitäten zueinander genauer, dabei diff. man in 1:1, 1:n und n:m. Auf die 1:1 Beziehungen verzichtete ich, daher sind in meiner DB nur 1:n bzw n:m Beziehungen zu finden.

Die 1:n Beziehung... ist die 1 zu viele Beziehung. Bei der Überführung vom ERM ins RM beduetet dies, dass der PS der 1er Entität als Fremdschlüssel der n-Entität aufgegührt wird. (Hier zw. Produktionsabteilung und Arbeiter). Dabei sind mehrere Arbeiter zugleich in einer Abteilung zusammengefasst, aber nie ein Arbeiter in mehreren Abteilungen.

Die n:m Beziehung... ist die viele zu viele Beziehung. Beider Überführung vom ERM ins RM bedeutet dies, dass die beiden FS der verknüpften Entitäten in einer extra Tabelle zusammegefassst werden. (siehe grünliche Tabellen oben). So können mehrere Konstruktionsabteilungen an den selben Plänen arbeiten, bzw. viele Pläne von einer Konstruktionsabteilung erstellt werden. Die Beziehung "enthält" zw. "Stücklisten" und "Plan" führt eigene Attribute an, diese werden in der Tabelle "enthält" aufgeführt, die durch die Überführung des ERM in RM entstand.

Normalformen:

Erste Normalform

"Ein Relationstyp (Tabelle) befindet sich in der ersten Normalform (1NF), wenn die Wertebereiche der Attribute des Relationstypen atomar sind."[1] Mein ERM hätte diese 1.NF verletzt, da ich das Attribut "Größe" verwendet habe, aber bei der Überführung in das RM habe ich die Normalformen beachtet und die Größe in "breite, länge, stärke/tiefe, radius" aufgeschlüsselt.

Zweite Normalform

"Ein Relationstyp (Tabelle) befindet sich genau dann in der zweiten Normalform (2NF), wenn er sich in der ersten Normalform (1NF) befindet und jedes Nichtschlüsselattribut von jedem Schlüsselkandidaten voll funktional abhängig ist." Dies wurde beim erstellen des ERM schon beachtet.[2]

Dritte Normalform

"Ein Relationstyp befindet sich genau dann in der dritten Normalform (3NF), wenn er sich in der zweiten Normalform (2NF) befindet und kein Nichtschlüsselattribut transitiv von einem Kandidatenschlüssel abhängt."[3] Alle Daten sind - abgesehen vom PS - untereinander funktional Abhängig. (Auch "Null" Felder sing gewollt, mehr unten in der Auseinandersetzung)

Funktionale Abhängigkeit... "Eine Funktionale Abhängigkeit zwischen Attribut Y und Attribut X liegt dann vor, wenn es zu jedem X genau ein Y gibt."[4]

Transitive Abhängigkeit... "Eine transitive Abhängigkeit liegt dann vor, wenn Y von X funktional abhängig und Z von Y, so ist Z von X funktional abhängig. Diese Abhängigkeit ist transitiv. Die transitive Abhängigkeit wird mit 3. Normalform (3NF) erreicht."[5]

Die Datensätze...

CREATE TABLE Konstruktionsabteilung(K_ID INTEGER, Auftragsnummer STRING,PRIMARY KEY( K_ID)); CREATE TABLE geplant(K_ID INTEGER,Zeichnungsnummer INTEGER); CREATE TABLE Plan(Zeichnungsnummer Integer, Produktionszeit Double,PRIMARY KEY(Zeichnungsnummer)); Create Table Stückliste(S_ID Integer, Teil_Name String,PRIMARY KEY( S_ID)); Create Table enthält(S_ID Integer, Zeichnungsnummer Integer, Anzahl Integer, breite double, länge double, stärke double, radius double); Create Table weitergeleitet(Zeichnungsnummer Integer, P_ID Integer); Create Table Produktionsabteilung(P_ID Integer, FS_L_ID String,Tätigkeit String, PRIMARY KEY( P_ID)); Create Table Lager(L_ID Integer,PRIMARY KEY(L_ID)); Create Table Teile(T_ID Integer, FS_L_ID String, Name String, Anzahl Integer, breite Double, länge Double, stärke Double, radius Double,PRIMARY KEY(T_ID)); Create Table Arbeiter(A_ID Integer, FS_P_ID Integer, Vorname String, Name String, Lebensalter Integer,PRIMARY KEY(A_ID)); INSERT INTO Plan VALUES (12,23); INSERT INTO Plan VALUES (21,12); INSERT INTO Plan VALUES (22,15); INSERT INTO Plan VALUES (33,20); INSERT INTO Plan VALUES (43,11); INSERT INTO Plan VALUES (54,13); INSERT INTO Plan VALUES (65,15); INSERT INTO Plan VALUES (86,18); Insert into Konstruktionsabteilung Values(1,002); Insert into Konstruktionsabteilung Values(2,001); Insert into Konstruktionsabteilung Values(3,002); Insert into geplant values (1,12); Insert into geplant values (2,21); Insert into geplant values (3,22); Insert into geplant values (1,43); Insert into geplant values (2,33); Insert into geplant values (3,54); Insert into geplant values (1,65); Insert into geplant values (3,86); Insert into Stückliste values(1,"Blech"); Insert into Stückliste values(2,"Mutter"); Insert into Stückliste values(3,"Bolzen"); Insert into Stückliste values(4,"Unterlegscheibe"); Insert into Stückliste values(5,"Kastenprofil"); Insert into Stückliste values(6,"Rohr"); Insert into Stückliste values(7,"Schraube"); Insert into enthält values(1,12,2,220,440,2, Null); Insert into enthält values(3,12,6,null,440,null, 4); Insert into enthält values(5,12,4,220,440,2, Null); Insert into enthält values(6,12,3,null,500,2, 40); Insert into enthält values(7,21,8,null,80,2, 3); Insert into enthält values(6,21,5,null,null,2, 20); Insert into enthält values(5,21,2,220,440,2, Null); Insert into enthält values(4,21,1,null,null,2, 10); Insert into enthält values(3,21,9,null,60,null, 3); Insert into enthält values(2,21,4,null,null,null, 20); Insert into enthält values(1,22,12,220,440,2, Null); Insert into enthält values(7,22,6,null,60,null, 3); Insert into enthält values(1,43,9,220,440,2, Null); Insert into enthält values(5,43,3,220,440,2, Null); Insert into enthält values(5,43,2,220,440,2, Null); Insert into enthält values(1,33,2,220,440,2, Null); Insert into enthält values(6,33,1,null,440,2, 25); Insert into enthält values(2,33,2,null,null,null, 5); Insert into enthält values(2,65,6,null,null,null, 5); Insert into enthält values(1,65,2,220,440,2, Null); Insert into enthält values(3,65,7,null,60,null, 5); Insert into enthält values(5,86,4,440,440,2, Null); Insert into enthält values(3,86,4,null,null,null, 6); Insert into enthält values(2,86,3,null,null,null, 30); Insert into enthält values(6,86,4,null,2000, 2,50); Insert into weitergeleitet values(43,1); Insert into weitergeleitet values(21,2); Insert into weitergeleitet values(22,5); Insert into weitergeleitet values(43,2); Insert into weitergeleitet values(12,5); Insert into weitergeleitet values(21,5); Insert into weitergeleitet values(12,3); Insert into weitergeleitet values(53,3); Insert into weitergeleitet values(65,4); Insert into weitergeleitet values(86,2); Insert into Produktionsabteilung values(1,1,"schweißen"); Insert into Produktionsabteilung values(2,1,"schweißen"); Insert into Produktionsabteilung values(3,1,"lasern"); Insert into Produktionsabteilung values(4,1,"lackieren"); Insert into Produktionsabteilung values(5,1,"montieren");

Insert into Lager values(1); Insert into Teile values(1,1,"Blech",50,1500,3000,2,Null); Insert into Teile values(2,1,"Mutter",100,null,null,3,15); Insert into Teile values(3,1,"Bolzen",100,null,50,Null,8); Insert into Teile values(4,1,"Unterlegscheibe",50,null,null,2,10); Insert into Teile values(5,1,"Kastenprofil",30,1500,3000,4,Null); Insert into Teile values(6,1,"Rohr",80,null,2000,2,40); Insert into Teile values(7,1,"Schraube",50,1500,3000,Null,4); Insert into Teile values(8,1,"HandschuhL",50,Null,Null,Null,Null); Insert into Teile values(9,1,"HandschuhM",30,Null,Null,Null,Null); Insert into Teile values(10,1,"Putzlappen",100,Null,Null,Null,Null); Insert into Teile values(11,1,"Gehörschatz",80,Null,Null,Null,Null); Insert into Arbeiter values(1, 1, "Jonas" ,"A", 46); Insert into Arbeiter values(2, 1, "Luca" ,"B", 30); Insert into Arbeiter values(3, 1, "Leon" ,"C", 45); Insert into Arbeiter values(4, 1, "Finn" ,"D", 19); Insert into Arbeiter values(5, 1, "Ben" ,"E", 34); Insert into Arbeiter values(6, 2, "Elias" ,"F", 39); Insert into Arbeiter values(7, 2, "Noah" ,"G", 23); Insert into Arbeiter values(8, 2, "Liam" ,"H", 33); Insert into Arbeiter values(9, 2, "Paul" ,"I", 24); Insert into Arbeiter values(10, 2, "Milan" ,"J", 32); Insert into Arbeiter values(11, 3, "Alexander" ,"K", 41); Insert into Arbeiter values(12, 3, "Max" ,"L", 36); Insert into Arbeiter values(13, 3, "Morris" ,"M", 19); Insert into Arbeiter values(14, 3, "Miran" ,"N", 33); Insert into Arbeiter values(15, 3, "Miro" ,"O", 43); Insert into Arbeiter values(16, 4, "Niklas" ,"P", 37); Insert into Arbeiter values(17, 4, "Nika" ,"Q", 24); Insert into Arbeiter values(18, 4, "Niko" ,"R", 36); Insert into Arbeiter values(19, 4, "Nabil" ,"S", 45); Insert into Arbeiter values(20, 4, "Noel" ,"T", 49); Insert into Arbeiter values(21, 5, "Nils" ,"U", 47); Insert into Arbeiter values(22, 5, "Nick" ,"V", 18); Insert into Arbeiter values(23, 5, "Neo" ,"W", 45); Insert into Arbeiter values(24, 5, "Günter" ,"X", 25); Insert into Arbeiter values(25, 5, "Georg" ,"Y", 34);

Hier die Abfragen...

Select * from Teile;

ausführen

Select * from Arbeiter where Vorname like "N%";

ausführen

Select distinct Vorname,Name from Arbeiter,Produktionsabteilung where Lebensalter between 30 and 55 and Tätigkeit="schweißen";

ausführen

Select * from Arbeiter,Produktionsabteilung where Arbeiter.FS_P_ID=Produktionsabteilung.P_ID and Arbeiter.Lebensalter between 30 and 60;

ausführen

Select Plan.Zeichnungsnummer,Konstruktionsabteilung.K_ID, Plan.Produktionszeit from Konstruktionsabteilung, geplant, Plan where Plan.Zeichnungsnummer=geplant.Zeichnungsnummer and geplant.K_ID=Konstruktionsabteilung.K_ID and Konstruktionsabteilung.K_ID=2;

ausführen

kritische Reflexion zu Modellierung und Umsetzung

...zu den weiteren Punkten die schon genannt wurden(->Themenwahl usw.)

Bei dem ersten Modellierungsversuch im ERM entdeckte ich viele Probleme, sodass ich mein Modell bzw. meine Idee einkürzen musste. Zuerst existierte noch die Entität "Einkaufsabteilung", deren Aufgabe es war, Lagerbestände mit den Aufträgen abzugleichen. Dies hätte aber zu einer komplexen Verbindung geführt, die man nicht hätte umsetzen können (In der vorgeb. Zeit).

Weiterhin änderte ich die Entität des "Plan" um, dieser enthielt vor der Umsetzung noch das Attribut "Stückliste", diese hätte aber die 1. und 2. NF verletzt, da die Stückliste selbst mehrere Attribute führen müsste, was die 1.NF verletzt, weiterhin wären die Stücklisten und dessen Attribute nicht direkt Abhängig vom Plan, sodass ich es beim Umsetzen vom ERM ins RM abänderte. Man hätte dies jetzt gut erkennen können (im Vgl. von ERM und RM), doch weitere "Fehler" bei der Überlegung führten dazu, dass ich auch das ERM komplett neu strukturiert habe. Ansonsten wäre das oben genannte im Modell zu erkennen gewesen.

Der nächste Punkt war die Entscheidung über die finalen Kardinalitäten. So hätte man sicher bei manchen n:m Beziehungen wie der der Konstruktion und des Planes eine 1:n Beziehung anbringen können, dennoch dachte ich mir, dass es in realen Unternehmen für viele Abteilungen zum Alltag gehört in Abteilungsübergreifenden Teams zu arbeiten und so auch viele Pläne von vielen versch. Konstruktionsabteilungen (eig. den Konstrukteuren) bearbeitet werden können.

Eine weitere Einkürzung betraf die Entität der Konstruktion selbst. Momentan sind deren Attribute nur die PS und die Auftragsnummer, dessen Datentyp im ER nicht angegeben wurde, da diese Nummern oftmals aus Buchstaben und Zahlenkombinationen entsprechen. Dennoch wählte ich gegen Ende "nur" Zahlen, da dies komfortabler war und die Abfragen übersichtlicher macht.

Hinter der Idee die Prod. Mittel über das Lager auszuführen stand der Gedanke, dass es möglicherweise Erweiterungen im Unternehmen gibt, was gerade diesen Bereich betrifft. So würden versch. Produktionsbateilungen Zugang zu anderen Lagern haben, wobei momentan alles in Lager 1 sitzt. Bei einer Erweiterung mit mehreren Lagern würden Natürlich aus der 1:n Beziehung aus Lager und Teile eine n:m Beziehung werden, sollte in den erweiterten Lagern gleiche Teile liegen. Wenn nicht und es getrennt wird nach beispielsweise: Arbeitsschutz-Lager und Produktionsmittel-Lager, können die bestehenden Beziehungen gleich bleiben.

Daneben könnte man die Arbeiter-Entität übergreifend für das gesamte Unternehmen modifizieren, sodass alle Abteilungen darunter aufgeführt wird. DOCH diese Idee kam mir erst gegen Ende der Modellierung und wurde nicht umgesetzt, da die Datenbank zeitgleich "nur" die Produktionsstruktur zeigen soll, während sie über Datensätze informiert. Dies hätte den zeitlichen Rahmen gesprengt.

Die oben genannten Punkte, welche die Erweiterung ansprechen, würden die Datenbank dann immer weiter in Richtung eines ERP Systems (bzw. der Datenbank dahinter) entwickeln. Solche Systeme kommen in Unternehmen für bestimmte Verwaltungsaufgaben zum Einsatz z.B. Kostenübersichten, Lagerdaten usw. ERP was?

Noch zu verbessernde Dinge: (-Die Größen der Teile aus Lager und Plan(Stückliste, enthält) könnte man in einer extra Tabelle zusammenfassen) Was nicht direkt notwendig ist in "enthält", da der Plan bestimmte Teile verlangt, mit festen immer versch. Größen. Höchstens das Lager mit Teile könnte man so modifizieren, dass die Größen nicht direkt Abhängig von der T_ID sind, sondern in einer extra angelegten Tabelle gespeichert werden.

Quellen

1. http://www.datenbanken-verstehen.de/datenmodellierung/normalisierung/