MySQL - Datenbank Normalisierung - HILFE!

Hallo zusammen,

bin ein Neuling der verzweifelt versucht fuer ein Uniprojekt eine Datenbank zu erstellen (in MySQL) und diese zu normalisieren so dass keine ueberfluessigen Datensaetze entstehen koennen.
Ich hoffe ihr koennt mir da helfen - obwohl es nur ein paar Felder sind, scheint mein Gehirn entweder zu weit nach vorne zu springen oder bringt alles durcheinander. Auf jeden Fall komm ich nicht mal zur 1NormalForm...

Hier die Problembeschreibung:

Ich muss eine Datenbank entwerfen fuer unsere Software CDs die wir bei der Arbeit rumfliegen haben.

Ich habe bereits folgende Felder zusammengestellt und evtl. auch bereits normalisiert aber ich bin mir nicht sicher!

Also hier die Felder:

Produkt
Version
Datum
Betriebssystem
Sprache
BenutztVon
Ordner
OrdnerSeite
Beschreibung
Kommentare

So das war der Ausgang des ganzen.
Die Regeln sind wie folgt:

Es gibt mehrere Produkte (softwares).
Jedes Produkt hat mehrere Versionen, mehrere Datum(s?), mehrere Betriebssysteme, mehrere Sprachen. Natuerlich auch mehrere Benutzer, mehrere Ordner und mehrere Ordnerseiten.

Ich habe bisher es so eingeteilt

Tabelle: PRODUKT
Felder: ProdID, ProdName

Tabelle: VERSION
Felder: VerID, Version

Tabelle: DATUM
Felder: DatumID, Datum

Tabelle: BETRIEBSSYSTEM
Felder: BSID, Bestriebssystem

Tabelle: SPRACHE
Felder: SprachID, Sprache

Tabelle: DATENSATZ
Felder: ProdID, VerID, DatumID, BSID, SprachID (die zusammen machen den Hauptschluessel) dann noch BenutztVon, Ordner, OrdnerSeite, Beschreibung, Kommentare


Haltet ihr das fuer richtig? Oder uebersehe ich da etwas?
Ist es ratsam einen Hauptschluessel zu nehmen der aus 5 Felder besteht? Irgendwie kommt mir das Ganze komisch vor.

Wie dem auch sei - vielen Dank allein schon mal fuers Lesen dieses Eintrags.
Freu mich schon auf Antworten!

Gruss,
Christina
 
Kannst Du noch etwas genauer werden?
Was ist das für ein Datum, was zum Produkt gehört?
Gehört die Beschreibung und ggf. auch die Kommentare nicht unabhängig von der Version zum Produkt?
Was meinst Du mit Ordner und OrdnerSeite?

Mir fehlt auf den ersten Blick eine Tabelle Benutzer und eine Tabelle BenutzerNutztProdukt (n:m-Beziehung).

Mein grober Ansatz (wie gesagt, so ganz steige ich noch nicht hinter das Problem) wäre:

Tabelle `Produkt`
  • ID, int PK AI
  • Name, char
  • Beschreibung text

Tabelle `Benutzer`
  • ID, int PK AI
  • Name, char
  • etc.

Tabelle `Betriebssystem`
  • ID, int PK AI
  • system, char

Tabelle `Version`
  • ID, int PK AI
  • ProduktID, int FK
  • BetriebssystemID, int FK
  • version, char

Tabelle `Sprache`
  • ID, int PK AI
  • sprache, char

Tabelle `VersionBietetSprache`
  • VersionID, int PK
  • SpracheID, int PK

Tabelle `BenutzerNutztVersion`
  • BenutzerID, int PK
  • VersionID, int PK

Tabelle `Kommentare`
  • ID, in PK AI
  • VersionID, int FK
  • BenutzerID, int FK
  • Kommentar, text

Unberücksicht bleibt bisher das Datum und die Sache mit den Ordnern.

Vielleicht hilft es Dir ja als Idee zum weitermachen.

Gruß hpvw
 
Hi hpvw,

vielen Dank fuer die schnelle Antwort! :) Ich weiss das wirklich zu schaetzen!

Zu deinen Fragen:

Das Datum gehoert zu einer CD. Also wird bestimmt durch Produkt, Version, Sprache und Betriebssystem. Selbiges gilt fuer die Beschreibung und die Kommentare.
Es geht darum eine solche CD einzufuegen und zu dieser spezifischen CD die Beschreibung einzugeben und evtl. Kommentare dazu zu erfassen.

Und was die Ordner angeht - das ist der Physikalische Ort an dem sich diese CDs befinden. In jedem Ordner gibt es Ordnerseiten mit CD Taschen - in jeder Seite passen 2CDs.

Heisst das dann dass ich noch eine Tabelle brauche die eine Datumstabelle mit, z.B. der Versionstabelle verbindet? Und dann dasselbe mit der Ordnertabelle und der Seitentabelle (also untereinander verbinden, mein ich)?

Mich aergert dass ich diesen ganzen Normalisierungsmist letztes Jahr halbwegs verstanden hatte aber ich weiss nicht mehr was es war was mir ploetzlich eingeleuchtet hatte... :(


Christina
 
Ich habe noch mal einen Vorschlag im Anhang.
Da das Datum offensichtlich abhängig von der CD ist, gibt es hierfür keine eigene Tabelle (DATE gilt als atomarer Datentyp, 1. NF).
Ich bin jetzt von Folgendem ausgegangen:
  • Zu einem Produkt gibt es mehrere Versionen (1:n-Beziehung, zwei Tabellen, Produkt und Version).
  • Eine Version ist für ein bestimmtes Betriebssystem geschrieben (1:n-Beziehung zwischen Version und Betriebssystem).
  • Eine Version kann eine oder mehr Sprachen bieten (n:m-Beziehung, drei Tabellen, Version, Sprache, Verknüfungstabelle VersionBietetSprache).
  • Eine Seite gehört zu einem Ordner (1:n-Beziehung, zwei Tabellen, Seite und Ordner). Seite kennzeichnet somit den Ablageort.
  • Eine CD beinhaltet eine bestimmte Version eines Produkts, verschiedene CDs können dieselbe Version enthalten (1:n-Beziehung zwischen CD und Version).
  • Eine CD ist auf einer bestimmten Seite abgelegt, mehrere CDs können auf einer Seite abgelegt werden (1:n-Beziehung zwischen CD und Seite).
  • Zu einer CD gehört ein Datum ( -> Attribut).
  • Zu einer CD gehört eine Beschreibung (-> Attribut).
  • Viele Benutzer können die Version einer CD nutzen. Ein Benutzer kann mehrere CDs nutzen (n:m-Beziehung, drei Tabellen, Benutzer, CD, Verknüpfungstabelle BenutzerNutztCD).
  • Alle Benutzer können Kommentare zu allen CDs abgeben (n:m-Beziehung, drei Tabellen, CD, Benutzer, Verknüpfungstabelle Kommentar). Dass die Kommentartabelle eine eigene ID hat, ermöglicht, dass ein User auch mehrere Kommentare zu einer CD abgeben kann. Sollten nur Nutzer einer CD auch einen Kommentar zu dieser abgeben können, so kann das Attribut Kommentar auch in der Tabelle BenutzerNutztCD aufgenommen werden.
Gegebenfalls läßt sich noch in weiteren Tabellen ein Datum einführen, z.B. bei den Kommentaren, damit man weiß, wann dieser abgegeben wurde.

Wie Du siehst, gehe ich etwas anders vor, als zumindest ich es im Lehrbuch/Unterricht gelernt habe. Da lief es immer so, wie es Deine Aufgabenstellung auch andeutet, dass die Attribute vorgegeben wurden und dann Schritt für Schritt von einer Normalform zur nächsten normalisiert wurde. Mein Vorgehen oben lässt erkennen, dass ich mir die Entitäten aufschreibe und die Beziehungen zwischen ihnen ermittel. Wenn man sich dann noch an die Grundregeln, 1:1-Beziehungen als Attribut, 1:n-Beziehungen mit einem Fremdschlüssel und n:m-Beziehungen mit einer Verknüpfungstabelle abzubilden, hält, genügt eine (relativ leichte) Kontrolle auf die Abhängigkeiten bezüglich der Normalformen und die Datenbankstruktur ist normalisiert.

In der Abbildung sind die Primarschlüssel blau hervorgehoben. Alle Primärschlüssel, die nur ID heißen, sind "AUTO INCREMENT". Alle Attribute, die an den Beziehungslinien stehen und nicht ID heißen sind Fremdschlüssel.

Gruß hpvw
 

Anhänge

  • CDDB.gif
    CDDB.gif
    6,7 KB · Aufrufe: 152
WOW! Ich bin absolut sprachlos
Vielen, MEGALIEBEN Dank fuer die Muehe die du dir gemacht hast!
Ich versteh jetzt auch eher was da passiert. Ich glaube ich war solang in der "Materie" drin dass ich den Wald vor lauter Baeumen nicht mehr gesehen habe! :)

Jetzt macht das ganze Sinn und du hast mir sogar mit deiner Denkweise einen Punkt gezeigt den ich nicht bedacht hatte (mehrere User koennen mehrere Kommentare abgeben!).

Ganz ehrlich, ich kann dir nicht genug danken - nach zweieinhalb Tagen "rumnormalisieren" (per Buch, wie unser Prof das unzureichend erklaert hat) war ich nah am Verzweifeln :) Jetzt ist alles wieder gut...

Ich verbeuge mich voll Hochachtung...
Christina
 

Anhänge

  • 2.gif
    2.gif
    265 Bytes · Aufrufe: 318
ROFL! Das mit der stud. Hilfskraft klingt SEHR logisch und wuerde zumindest den Zustand in meiner Uni erklaeren! ;)

Ich studiere in England, da haben wir ein Buch von Connolly/Begg oder so durchgenommen. Leider bin ich kein "Buechermensch" sonder eher eine "learning by doing" Person. Das passt mit der akademischen Sichtweise der meisten Unis/Profs nicht so sehr LOL

Ich schau mir nochmal deine Linkvorschlaege an - und da du mit einem einfachen Danke zufrieden bist hier nochmals: danke :)
 
Wenn es Database Systems ist, hoffe ich mal für Dich, dass Du nicht alles lernen mußt. 1300 Seiten sind ja eine ganze Menge. Das Buch macht nach den Rezensionen einen sehr guten Eindruck. Naja, bei dem Preis, muss es das wohl auch.

Ich lerne eigentlich auch lieber an praktischen Beipielen, allerdings muss ich auch sagen, dass Datenbankdesign eins der ganz wenigen Gebiete ist, bei dem mir die zu Grunde liegende Theorie (sprich: relationale Algebra) sehr für das Verständnis in der Praxis geholfen hat. Das durfte ich zum Glück schon in der Schule bei einem Lehrer ohne irgendwelche Titel lernen.

Gruß hpvw
 
Zurück