hawkmaster: Normalform, Tabellendesign?

Hallo zusammen,
Zwei Dinge bei denen ich mir nicht im klaren bin, ob es so gut ist wegen den Normalformen.

Folgendes.
Es gibt eine Tabelle "users" mit Spalten wie:

UserID, User, Email, Kostenstelle, Login,..
1, Klaus, kk@kk.de, 1234, klaus
2, Werner, ww@ww.de, 3456, werner
3, Gustav, gg@gg.de, 8899, gustav
....

Dann gibt es eine Tabelle "messages" mit Spalten

MessageID, UserID, SenderID, Message
1, 1,   2, "Hallo Klaus wie gehts"
2, 2,   1, "Hallo Werner, danke gut"
3, 3,   1, "Hallo Gustav, "

Ich speichere also die UserIDs von Tabelle "users" in den Spalten "UserID" und "SenderID" der Tabelle "messages".
Ist das vom Aufbau bzw. von der Normalform her gesehen ok so?
Wären dann die Spalten "UserID" und "SenderID" die "ForeignKeys" zur Tabelle "users"?

Wenn ich nun daraus mit einem Programm versuche ein Diagramm mit reverse Engineering zu machen, wird zwar die Relation "UserID"---> "UserID" erkannt, nicht jedoch "UserID"--->"SenderID".
Vermutlich deswegen weil die SPalte anders heisst?

Anderes Beispiel:

Es gibt die Tabelle "constraintselements"
---------------------------------------------------------------
ConElementID, Element
1,  Blau
2,  Rot
3,  Gelb
4,  Braun

Dann gibt es die Tabelle "constraints"
----------------------------------------------------------
ConID, ConElementID1, ConElementID2, GroupID
1,         1,            2,           3
2,         1,            4,           3
3,         3,            4,           1

Was ich hier nicht weiss. Es gibt die Beziehung zu "ConElementID" in den Spalten "ConElementID1" und "ConElementID2"
Ich habe mal gelesen dass man derartige Spaltennamen vermeiden soll.

Wäre es besser diese "constraints" Tabelle in zwei Tabellen aufzusplitten?

viele Grüße
hawk

  1. Hi,

    Ich speichere also die UserIDs von Tabelle "users" in den Spalten "UserID" und "SenderID" der Tabelle "messages".
    Ist das vom Aufbau bzw. von der Normalform her gesehen ok so?

    perfekt. Allerdings verstehe ich die Spaltennamen nicht vollständig: Referenziert UserID den User, der die Mail versendet hat, und SenderID den Sender der Mail? "Empfänger" heißt jedenfalls anders ...

    Wären dann die Spalten "UserID" und "SenderID" die "ForeignKeys" zur Tabelle "users"?

    Ja, so sollte es sein.

    Wenn ich nun daraus mit einem Programm versuche ein Diagramm mit reverse Engineering zu machen, wird zwar die Relation "UserID"---> "UserID" erkannt, nicht jedoch "UserID"--->"SenderID".
    Vermutlich deswegen weil die SPalte anders heisst?

    Ja, vermutlich. Wenn das Datenbankmodell keine FK-Beziehungen integriert hat, bleibt einem Analysetool auch nichts anderes übrig, als zu raten. Den Rest muss der User einstellen.

    Was ich hier nicht weiss. Es gibt die Beziehung zu "ConElementID" in den Spalten "ConElementID1" und "ConElementID2"
    Ich habe mal gelesen dass man derartige Spaltennamen vermeiden soll.

    Sie sagen wenig über das Wesen der Spalten aus, das ist richtig.

    Wäre es besser diese "constraints" Tabelle in zwei Tabellen aufzusplitten?

    Weil einem kein guter Name einfällt? Nein.

    Cheatah

    --
    X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
    X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes
    1. Hallo,

      Wenn ich nun daraus mit einem Programm versuche ein Diagramm mit reverse Engineering zu machen, wird zwar die Relation "UserID"---> "UserID" erkannt, nicht jedoch "UserID"--->"SenderID".
      Vermutlich deswegen weil die SPalte anders heisst?

      Ja, vermutlich. Wenn das Datenbankmodell keine FK-Beziehungen integriert hat, bleibt einem Analysetool auch nichts anderes übrig, als zu raten. Den Rest muss der User einstellen.

      weil ich's hier grade lese: Analysetool, Diagram erstellen... sowas suche ich für mysql: ein Programm, das mir anhand der vorliegenden Datenbank ein Diagramm über Tabellenstrukturen und Beziehungen auswirft (sowas wie es Access ansatzweise macht, nur leider für größere DBs nicht brauchbar). Könnt Ihr mir etwas empfehlen?

      Gruß aus Köln-Ehrenfeld,

      Elya

      --
      1. Hallo,
        oh da kann ich ein Lied davon singen.
        Ich habe letzter Zeit ca. 8 verschiedene Programme mit mehr oder weniger Erfolg getestet.
        Es ist immer schwierig so etwas im Nachhinein zu machen.

        Freeware und ganz gut ist der
        DBDesigner 4 von fabsoft , wird aber nicht mehr supportet
        Nachfolger aber noch sehr Beta ist der MySQL WorkBench, direkt von MySQL.
        Dann gibt es noch
        MICRO LAP Database Designer for MySQl (kostet aber )

        Dezign for Databases V4 (kostet auch)

        Von Xcase )xcase.com) gibt es auch was
        Das neue OpenOffice 2.x hat auch ein DB Design Tool als Schnittstelle

        Dann kannst du das ganze noch mit Visio machen. Habe damit aber keine so gute Erfahrungen gemacht.

        und noch viele mehr.

        Gruss
        hawk

        Hallo,

        Wenn ich nun daraus mit einem Programm versuche ein Diagramm mit reverse Engineering zu machen, wird zwar die Relation "UserID"---> "UserID" erkannt, nicht jedoch "UserID"--->"SenderID".
        Vermutlich deswegen weil die SPalte anders heisst?

        Ja, vermutlich. Wenn das Datenbankmodell keine FK-Beziehungen integriert hat, bleibt einem Analysetool auch nichts anderes übrig, als zu raten. Den Rest muss der User einstellen.

        weil ich's hier grade lese: Analysetool, Diagram erstellen... sowas suche ich für mysql: ein Programm, das mir anhand der vorliegenden Datenbank ein Diagramm über Tabellenstrukturen und Beziehungen auswirft (sowas wie es Access ansatzweise macht, nur leider für größere DBs nicht brauchbar). Könnt Ihr mir etwas empfehlen?

        Gruß aus Köln-Ehrenfeld,

        Elya

      2. Hi,

        Sparx Enterprise Architect bietet Forward- und Reverse Engineering für relationale Datenabnksysteme und sollte ODBC Kompatibel sein.

        Cheers
        Frank

  2. hi,

    MessageID, UserID, SenderID, Message
    1, 1,   2, "Hallo Klaus wie gehts"
    2, 2,   1, "Hallo Werner, danke gut"
    3, 3,   1, "Hallo Gustav, "

    Ich speichere also die UserIDs von Tabelle "users" in den Spalten "UserID" und "SenderID" der Tabelle "messages".
    Ist das vom Aufbau bzw. von der Normalform her gesehen ok so?

    Wenn es möglich sein soll, eine Message an mehrere User gleichzeitig zu senden, wäre eine weitere Aufteilung an dieser Stelle sinnvoll.

    gruß,
    wahsaga

    --
    /voodoo.css:
    #GeorgeWBush { position:absolute; bottom:-6ft; }
    1. Hallo,
      danke für eure Hilfe.

      Ja es kommt schon vor das die gleiche Nachricht an alle User geht.
      Dann wäre in der Spalte "SenderID" und "Message" in allen Zeilen der gleiche Inhalt.
      Ist das schlimm?
      Wie könnte man das dann aber sinnvoll aufsplitten?
      eine extra Tabelle nur mit "MessageTextID" und "MessageText" und dann die "MessageTextID" als Relation zur Tabelle "messages"??
      Aber dann steht halt anstatt des gleichen Textes immer die gleiche ID in allen Zeilen.

      Gruss
      hawk

      hi,

      MessageID, UserID, SenderID, Message
      1, 1,   2, "Hallo Klaus wie gehts"
      2, 2,   1, "Hallo Werner, danke gut"
      3, 3,   1, "Hallo Gustav, "

      Ich speichere also die UserIDs von Tabelle "users" in den Spalten "UserID" und "SenderID" der Tabelle "messages".
      Ist das vom Aufbau bzw. von der Normalform her gesehen ok so?

      Wenn es möglich sein soll, eine Message an mehrere User gleichzeitig zu senden, wäre eine weitere Aufteilung an dieser Stelle sinnvoll.

      gruß,
      wahsaga

      1. hi,

        Ja es kommt schon vor das die gleiche Nachricht an alle User geht.
        Dann wäre in der Spalte "SenderID" und "Message" in allen Zeilen der gleiche Inhalt.
        Ist das schlimm?

        Lass die Nachricht 1 KB Text umfassen, und an ein Dutzend Leute verschickt werden. Speicherst du lieber 12 mal 1 KB, oder ein mal 1 KB an Text?

        Wie könnte man das dann aber sinnvoll aufsplitten?
        eine extra Tabelle nur mit "MessageTextID" und "MessageText" und dann die "MessageTextID" als Relation zur Tabelle "messages"??
        Aber dann steht halt anstatt des gleichen Textes immer die gleiche ID in allen Zeilen.

        Eine ID ist kein KB groß, sondern wenige Bytes. 12 mal wenige Bytes << 12 mal 1 KB :-)

        gruß,
        wahsaga

        --
        /voodoo.css:
        #GeorgeWBush { position:absolute; bottom:-6ft; }