letavino
Goto Top

MySQL Datenbank richtig aufbauen

Ich fange gerade an, mich mit Datenbanken zu beschäftigen.
Nun benötige ich ein bisschen Hilfe beim sinnvollen Strukturieren der Bereiche.

Es soll eine Art Aufgabenverwaltung werden.
Dazu werden Aufgabennummer (ID), Aufgabe, und Arbeiter in der Datenbank gespeichert.
Aber wie verknüpfe ich diese richtig, wenn jeder Auftrag verschiedene Arbeiter haben kann und jeder Arbeiter verschiedene Aufträge?

Ist es bisher richtig, wenn ich in eine Tabelle "ID" "Auftrag" und "Arbeiter ID" zusammenführe und in eine weitere "Arbeiter ID" und "Name"?

Ich hoffe ihr könnt mir diese wahrscheinlich simple Frage schnell beantworten und mir meinen Einstieg in die Welt der Datenbanken vereinfachen ;)

Lg Florian

Content-Key: 152394

Url: https://administrator.de/contentid/152394

Ausgedruckt am: 28.03.2024 um 10:03 Uhr

Mitglied: godlie
godlie 05.10.2010 um 15:12:20 Uhr
Goto Top
Ein einfaches Hallo erstmal ...

Ich würde mich mal mit den sog. Normalformen beschäftigen dort wird dies sehr gut aufgeschlüsselt wie man so etwas angeht.
siehe Wikipedia Normalformen Datenbanken...
grüße
Mitglied: Letavino
Letavino 05.10.2010 um 15:19:55 Uhr
Goto Top
Hallo und vielen Dank für deine Antwort!
Ich werde mich da dann einmal einlesen.
lg Florian
Mitglied: Florian.Sauber
Florian.Sauber 05.10.2010 um 18:29:50 Uhr
Goto Top
Hallo Florian!

Schau doch einfach mal nach http://www.google.de/search?q=einf%FChrung+relationale+datenbanken+file ...
Ein ganz guter Einsteigerkurs für MySQL/PHP findest Du inklusive EntitiyRelationshipModell und Nomalisierung unter

Wenn Du es gerne etwas ausführlicher hättest, kann ich Dir auch noch die Skripte der FH-Deggendorf zu dem Thema anraten
oder die, der FH-Regensburg:
Oder oder oder

Viel Spass und Erfolg
LG Florian
Mitglied: Letavino
Letavino 05.10.2010 um 18:42:48 Uhr
Goto Top
Vielen Dank!
Da kann ich mich ja morgen mal so richtig gut einarbeiten ;)
Lg Florian
Mitglied: dog
dog 05.10.2010 um 22:11:54 Uhr
Goto Top
Aber wie verknüpfe ich diese richtig, wenn jeder Auftrag verschiedene Arbeiter haben kann und jeder Arbeiter verschiedene Aufträge?

Das bezeichnet man als eine n:n Beziehung.
So eine Beziehung lässt sich nur über eine Hilfs-Tabelle darstellen:

arbeiter
--------------
id
name
...

auftrag
--------------
id
beschreibung
...

auftrag_arbeiter
--------------
id_arbeiter
id_auftrag

Der Rest sollte offensichtlich sein...
Mitglied: Letavino
Letavino 05.10.2010 um 22:28:55 Uhr
Goto Top
Ok, auch dir nochmal vielen Dank! face-smile

Hier wird einem echt sehr gut geholfen!

Lg Florian
Mitglied: Florian.Sauber
Florian.Sauber 05.10.2010 um 22:59:30 Uhr
Goto Top
Hallo,

wobei aus seinemDeinem Bsp ja nicht klar ersichtlich ist ob er meint:
AUFGABE
*id_aufg
name_aufg

ARBEITER
*name_arb

AUFTRAG
id_aufg
name_arb

mit AUFGABE 1:n AUFTRAG n:1 ARBEITER

oder auch

AUFGABE
*name_aufg

ARBEITER
*name_arb

AUFTRAG
*id_auftrag
name_aufg
name_arb

(beides zugegbenermaßen wenig praxistauglich)

Da liegt also noch einiges im argen. Ich denke das beste wir sein sich erst mal das ERM (oder von mir auch ein Klassenmodell) anzuschauen. Das wird ihm/Dir helfen seine/Deine Anforderungen klar zu strukturieren. Atomar, transitiv und NF stellt sich dann mit etwas leseeifer ganz von selbst ein. Ist ja noch kein Meister vom Himmel gefallen und DB-Architektur ist ein echt spannendes Thema.

LG Florian
Mitglied: dog
dog 05.10.2010 um 23:16:09 Uhr
Goto Top
Ich denke das beste wir sein sich erst mal das ERM (oder von mir auch ein Klassenmodell) anzuschauen. Das wird ihm/Dir helfen seine/Deine Anforderungen klar zu strukturieren. Atomar, transitiv und NF stellt sich dann mit etwas leseeifer ganz von selbst ein

Heieiei, du musst doch nicht gleich am Anfang Alle abschrecken.

Mit dem Krams kann man sich beschäftigen wenn man mit Datenbanken sicher ist und das ganze theoretische Krams nicht mehr so viel kaputt machen kann face-wink

Die absolute Normalisierung und Atomisierung erweist sich nämlich in der Praxis oft als ziemlich untauglich, obwohl sie die Theoretiker sooooo gern haben face-wink

Zugegeben muss man Normalformen nicht mal lernen, jeder der mal 4 Wochen mit Datenbanken gearbeitet hat wird da von ganz alleine landen.
Mitglied: Florian.Sauber
Florian.Sauber 05.10.2010 um 23:39:12 Uhr
Goto Top
Zitat von @dog:
Mit dem Krams kann man sich beschäftigen wenn man mit Datenbanken sicher ist und das ganze theoretische Krams nicht mehr so viel kaputt machen kann face-wink

Die absolute Normalisierung und Atomisierung erweist sich nämlich in der Praxis oft als ziemlich untauglich, obwohl sie die Theoretiker sooooo gern haben face-wink

Zugegeben muss man Normalformen nicht mal lernen, jeder der mal 4 Wochen mit Datenbanken gearbeitet hat wird da von ganz alleine landen.

Jaa genau! So meinte ich das doch face-smile
Aber das ERM empfand ich damals als extrem praktisch, um mal ein wenig Ordnung in das "der gehört zu dem und will das von jenem"-Gedöns zu bringen. Ausserdem find ichs immer so hübsch face-wink(im Gegensatz zu manchen UML-Diags)
Und zum Thema Theorie und Praxis pfeif ich auch Dein Liedchen: Wenn ich bedenke was mein (sonst hochgeschätzter) Prof alles wollte bei seinen strangen Flughafenbeispielen. Das ist mir in der Praxis noch NIE über den Weg gelaufen

LG Florian