Lana: m:n bei mehreren Tabellen

Hi :-)

ich habe 3 Tabellen bei denen ich eine Spalte notiz hinzufügen möchte. Ein Datensatz soll mehrere Notizen haben können, also m:n.

Muss ich für jede der 3 Tabellen eine Tabelle notiz_tabelleN anlegen und dann die m:n Tabelle?
Oder reicht es, wenn man die Tabelle notiz nur einmal anlegt und dann darauf irgendwie verweist? Wie müssten dann die m:n Tabellen aussehen?

als Datenbank kommt MySQL 5.0.77 zum Einsatz

Lana

  1. Hi :-)

    ich habe 3 Tabellen bei denen ich eine Spalte notiz hinzufügen möchte. Ein Datensatz soll mehrere Notizen haben können, also m:n.

    Muss ich für jede der 3 Tabellen eine Tabelle notiz_tabelleN anlegen und dann die m:n Tabelle?
    Oder reicht es, wenn man die Tabelle notiz nur einmal anlegt und dann darauf irgendwie verweist? Wie müssten dann die m:n Tabellen aussehen?

    als Datenbank kommt MySQL 5.0.77 zum Einsatz

    Eine Notiz soll auf ein Datensatz begrenzt sein, soll heißen, dass die selbe Notiz (Notiz-ID) nicht einen anderen Datensatz zugeordnet werden kann.
    Das sollte doch per Trigger lösbar sein, oder?

    Lana

    1. moin,

      »» ich habe 3 Tabellen bei denen ich eine Spalte notiz hinzufügen möchte. Ein Datensatz soll mehrere Notizen haben können, also m:n.

      »» Muss ich für jede der 3 Tabellen eine Tabelle notiz_tabelleN anlegen und dann die m:n Tabelle?

      Eine Notiz soll auf ein Datensatz begrenzt sein, soll heißen, dass die selbe Notiz (Notiz-ID) nicht einen anderen Datensatz zugeordnet werden kann.
      Das sollte doch per Trigger lösbar sein, oder?

      es wäre sehr hilfreich, wenn du uns mehr über dein daten-design erzählen würdest, bzw. noch besser über deine fachlichkeit, die du abbilden willst. mit diesen spärlichen informationen ist es nicht möglich, dir zu helfen.

      Ilja

      1. Hi ilja!

        »» »» ich habe 3 Tabellen bei denen ich eine Spalte notiz hinzufügen möchte. Ein Datensatz soll mehrere Notizen haben können, also m:n.

        »» »» Muss ich für jede der 3 Tabellen eine Tabelle notiz_tabelleN anlegen und dann die m:n Tabelle?

        »» Eine Notiz soll auf ein Datensatz begrenzt sein, soll heißen, dass die selbe Notiz (Notiz-ID) nicht einen anderen Datensatz zugeordnet werden kann.
        »» Das sollte doch per Trigger lösbar sein, oder?

        es wäre sehr hilfreich, wenn du uns mehr über dein daten-design erzählen würdest, bzw. noch besser über deine fachlichkeit, die du abbilden willst.

        ich habe z.B. folgende 3 Tabellen.

        Ich möchte nun z.B. eine oder mehrere Notiz(en) für den Kunden, das Geschäft und den Raum ablegen können.

        +------------+   +-------------+   +--------------+
        | kunde      |   | geschaeft   |   | raum         |
        +------------+   +-------------+   +--------------+
        |            |   |             |   | id           |
        +------------+   +-------------+   +--------------+
        |            |   | id          |---| geschaeft_id |
        +------------+   +-------------+   +--------------+
        | id         |---| kunde_id    |   |              |
        +------------+   +-------------+   +--------------+

        kann/muss ich das wie folgt lösen?

        +------------+   +-------------+   +--------------+
        | k_notiz    |   | g_notiz     |   | r_notiz      |
        +------------+   +-------------+   +--------------+
        | id         |   | id          |   | id           |
        +------------+   +-------------+   +--------------+
               |                |                  |
        +------------+   +-------------+   +--------------+
        | kunde      |   | geschaeft   |   | raum         |
        +------------+   +-------------+   +--------------+
        |            |   |             |   | id           |
        +------------+   +-------------+   +--------------+
        |            |   | id          |---| geschaeft_id |
        +------------+   +-------------+   +--------------+
        | id         |---| kunde_id    |   |              |
        +------------+   +-------------+   +--------------+
        | k_notiz_id |   | g_notiz_id  |   | r_notiz_id   |
        +------------+   +-------------+   +--------------+

        Ich hoffe, dass es jetzt etwas besser zu verstehen ist.

        meine Frage ist, ob das auch mit nur einer notiz-Tabelle lösbar ist; falls ja, wie müssten dann die Beziehungen gesetzt werden?

        Als Datenbank kommt MySQL 5.0.77 zum Einsatz und als Storage-Engine verwende ich InnoDB.

        Lana

        1. yo,

          meine Frage ist, ob das auch mit nur einer notiz-Tabelle lösbar ist; falls ja, wie müssten dann die Beziehungen gesetzt werden?

          wenn ich den design richgit interpretiere, dann ist es so nicht möglich, dass ein kunde (für geschäfte und räume ist es analog) mehrere notizen haben kann, da du den fremdschlüssel in die tabelle kunde gepackt hast. es müsste eigentlich genau umgekehrt sein, dass der fremdschlüssel der kunden in der tabelle notizen erzeugt wird. das wäre dann eine 1:n beziehung zwischen den kunden und den Notizen. in deinem vorherigen beiträgen sprichst du sogar eine n:m beziehung an. aber ich kann in deinem falle nicht sehen, warum du das brauchen solltest. letztlich willst du ja, dass ein und dieselbe notiz nicht mehreren kunden gehört, sondern nur zu genau einen. oder habe ich das falsch aufgefasst ?

          was deine andere frage betrifft, ob man nicht eine notiz-tabelle für alle drei entitäten kunde/geschäft/raum machen kann, das geht ein wenig in die objektorientierung rein. gibt dazu schon etliche versuche, das mit rdbms zu kombinieren. ich persönlich halte davon nicht allzuviel, aber das ist ansichtssache. man könnte natürlich eine tabelle draus machen und alle drei fremdschlüssel darin abbilden. je nachdem um welchen notiz es sich handelt, wird eben einer der drei fremdschlüssel besetzt. aber ich halte das für nicht optimal.

          mein leitsatz zu dem thema daten-design ist, was gleich aussieht, muss nicht gleich sein. auch wenn die drei notiztabellen sehr gleich aufgebaut sind, musst du dir überlegen, ob du sie auf irgendeine weise miteinander verbinden willst. das würde bedeuten, willst du eine veränderung für die notizen der kunden vornehmen, dann musst du es für alle drei machen, zum beispiel wenn du eine zusätzliche spalte brauchst. also der ansatz mit den drei notiztabellen ist schon ok.

          Ilja

          1. Hi!

            »» meine Frage ist, ob das auch mit nur einer notiz-Tabelle lösbar ist; falls ja, wie müssten dann die Beziehungen gesetzt werden?

            wenn ich den design richgit interpretiere, dann ist es so nicht möglich, dass ein kunde (für geschäfte und räume ist es analog) mehrere notizen haben kann, da du den fremdschlüssel in die tabelle kunde gepackt hast. es müsste eigentlich genau umgekehrt sein, dass der fremdschlüssel der kunden in der tabelle notizen erzeugt wird. das wäre dann eine 1:n beziehung zwischen den kunden und den Notizen.

            mir ist da beim Schreiben/Zeichnen ein Fehler passiert.

            so sollte es jetzt richtig sein
            +------------+   +--------------+   +--------------+
            | k_notiz    |   | g_notiz      |   | r_notiz      |
            +------------+   +--------------+   +--------------+
            | id         |   | id           |   | id           |
            +------------+   +--------------+   +--------------+
            | kunde_id   |   | geschaeft_id |   | raum_id      |
            +------------+   +--------------+   +--------------+
                   |                |                  |
            +------------+   +--------------+   +--------------+
            | kunde      |   | geschaeft    |   | raum         |
            +------------+   +--------------+   +--------------+
            |            |   |              |   | id           |
            +------------+   +--------------+   +--------------+
            |            |   | id           |---| geschaeft_id |
            +------------+   +--------------+   +--------------+
            | id         |---| kunde_id     |   |              |
            +------------+   +--------------+   +--------------+

            in deinem vorherigen beiträgen sprichst du sogar eine n:m beziehung an. aber ich kann in deinem falle nicht sehen, warum du das brauchen solltest. letztlich willst du ja, dass ein und dieselbe notiz nicht mehreren kunden gehört, sondern nur zu genau einen. oder habe ich das falsch aufgefasst ?

            ja, eine Notiz soll nur für ein Kunden/etc. zulässig sein, ich schaffe mit dadurch evtl. Redundanzen, das sollte aber vertretbar sein, oder?

            was deine andere frage betrifft, ob man nicht eine notiz-tabelle für alle drei entitäten kunde/geschäft/raum machen kann, das geht ein wenig in die objektorientierung rein. gibt dazu schon etliche versuche, das mit rdbms zu kombinieren. ich persönlich halte davon nicht allzuviel, aber das ist ansichtssache. man könnte natürlich eine tabelle draus machen und alle drei fremdschlüssel darin abbilden. je nachdem um welchen notiz es sich handelt, wird eben einer der drei fremdschlüssel besetzt. aber ich halte das für nicht optimal.

            mein leitsatz zu dem thema daten-design ist, was gleich aussieht, muss nicht gleich sein. auch wenn die drei notiztabellen sehr gleich aufgebaut sind, musst du dir überlegen, ob du sie auf irgendeine weise miteinander verbinden willst. das würde bedeuten, willst du eine veränderung für die notizen der kunden vornehmen, dann musst du es für alle drei machen, zum beispiel wenn du eine zusätzliche spalte brauchst. also der ansatz mit den drei notiztabellen ist schon ok.

            Wie müßte man die Beziehungen bei der Datenbank erstellen? Die Spalte, die die Fremd-ID aufnehmen würde, würde ja die ID entweder aus Tabelle 1, Tabelle 2 oder Tabelle 3 speichern.

            PostgreSQL soll ja ein objektrelationales Datenbankmanagementsystem (ORDBMS) sein.
            Wie ist das zu verstehen? Kann man dort in ein Schemata eine Tabelle um bestimmte Zeilen erweitern?

            Lana

            1. yo,

              ja, eine Notiz soll nur für ein Kunden/etc. zulässig sein, ich schaffe mit dadurch evtl. Redundanzen, das sollte aber vertretbar sein, oder?

              redundanzen sind grundsätzlich nichts negatives. es hat sich leider die these eingebürgert, dass man z.b. durch normaliserungsprozesse versucht alle redundanzen aus einem daten-design zu entfernen. dem ist aber nicht so, letztlich geht es nur darum, redudanzen zu kontrollieren. welche redundanzen du genau meinst, ist mir in deinem falle nicht ganz klar. meinst du etwa, dass ein kunde und ein geschaeft die gleiche notiz haben können oder wie ist das zu verstehen ?

              Wie müßte man die Beziehungen bei der Datenbank erstellen? Die Spalte, die die Fremd-ID aufnehmen würde, würde ja die ID entweder aus Tabelle 1, Tabelle 2 oder Tabelle 3 speichern.

              hmm, also davon würde ich grundsätzlich abraten. das kann man machen, wenn man "eineindeutige" schlüsel verwendet, sprich primärschlüssel die nicht nur in der tabelle, sondern über die ganze datenbank hinweg eindeutig sind. geschickter wäre es, in einer tabelle drei spalten zu erstellen, die entsprechend auf eine der drei tabellen referenziert/verzweigt. aber auch davon würde ich abraten, was spricht den gegen die drei notiztabellen, dann hast du enie saubere trennung der unterschiedlichen arten von notizen.

              PostgreSQL soll ja ein objektrelationales Datenbankmanagementsystem (ORDBMS) sein.
              Wie ist das zu verstehen? Kann man dort in ein Schemata eine Tabelle um bestimmte Zeilen erweitern?

              ich kann dazu leider nichts sagen, habe bezüglich objekt-relationalen datenbanksysteme zu wenig wissen und wohl auch eine abneigung. du weisst ja, was der bauer nicht kennt, das isst er nicht....

              Ilja

              1. Hi!

                »» ja, eine Notiz soll nur für ein Kunden/etc. zulässig sein, ich schaffe mit dadurch evtl. Redundanzen, das sollte aber vertretbar sein, oder?

                redundanzen sind grundsätzlich nichts negatives. es hat sich leider die these eingebürgert, dass man z.b. durch normaliserungsprozesse versucht alle redundanzen aus einem daten-design zu entfernen. dem ist aber nicht so, letztlich geht es nur darum, redudanzen zu kontrollieren. welche redundanzen du genau meinst, ist mir in deinem falle nicht ganz klar. meinst du etwa, dass ein kunde und ein geschaeft die gleiche notiz haben können oder wie ist das zu verstehen ?

                es kann passieren, das z.B. in der k_notiz Tabelle 2 mal die selbe Notiz aber für unterschiedliche Kunden gespeichert ist. Das für ein Kunde nicht 2mal die selbe Notiz gespeichert wird, sollte sich mit ein Trigger abfangen lassen

                »» Wie müßte man die Beziehungen bei der Datenbank erstellen? Die Spalte, die die Fremd-ID aufnehmen würde, würde ja die ID entweder aus Tabelle 1, Tabelle 2 oder Tabelle 3 speichern.

                hmm, also davon würde ich grundsätzlich abraten. das kann man machen, wenn man "eineindeutige" schlüsel verwendet, sprich primärschlüssel die nicht nur in der tabelle, sondern über die ganze datenbank hinweg eindeutig sind. geschickter wäre es, in einer tabelle drei spalten zu erstellen, die entsprechend auf eine der drei tabellen referenziert/verzweigt. aber auch davon würde ich abraten, was spricht den gegen die drei notiztabellen, dann hast du enie saubere trennung der unterschiedlichen arten von notizen.

                das war eher eine theoretische Frage - mir war bzw. ist nicht ganz klar, wie man soetwas am besten lösen würde.

                Zwecks eindeutige Schlüssel - das sollte in PostgreSQL mit einer Sequenz lösbar sein. Ob MySQL Sequenzen unterstützt, weiß ich jetzt jedoch nicht.

                »» PostgreSQL soll ja ein objektrelationales Datenbankmanagementsystem (ORDBMS) sein.
                »» Wie ist das zu verstehen? Kann man dort in ein Schemata eine Tabelle um bestimmte Zeilen erweitern?

                ich kann dazu leider nichts sagen, habe bezüglich objekt-relationalen datenbanksysteme zu wenig wissen und wohl auch eine abneigung. du weisst ja, was der bauer nicht kennt, das isst er nicht....

                hehe... das kommt mir bekannt vor :-)

                Lana

                1. yo,

                  es kann passieren, das z.B. in der k_notiz Tabelle 2 mal die selbe Notiz aber für unterschiedliche Kunden gespeichert ist. Das für ein Kunde nicht 2mal die selbe Notiz gespeichert wird, sollte sich mit ein Trigger abfangen lassen

                  hmm, da wären wir dann aber wieder bei einer n:m beziehung zwischen den notizen und den kunden, sprich du brauchst eine weitere beziehungstabelle, wo der fremdschlüssel des kunden und der notizen hinterlegt wird. und dann brauchst du auch keinen trigger, sondern legst über diese beiden fremdschlüssel einfach einen unique constraint und gut ist.

                  das war eher eine theoretische Frage - mir war bzw. ist nicht ganz klar, wie man soetwas am besten lösen würde.

                  naja, meiner meinmung nach am besten eben mit verschiedenen tabellen. wenn man nur eine erstellen will, dann eben mit drei verschiedenen spalten und wenn man auch noch nur eine spalte benutzen will, dann braucht man einen enieindeutigen schlüssel.

                  Zwecks eindeutige Schlüssel - das sollte in PostgreSQL mit einer Sequenz lösbar sein. Ob MySQL Sequenzen unterstützt, weiß ich jetzt jedoch nicht.

                  oracle verwendet auch sequenzen, mysql kennt meiner meinung nach diese objekte nicht, sondern benutzt autoincrementwerte in den jeweiligen tabellen. aber kann mich bezüglich mysql auch irren.

                  Ilja

                  1. Hi!

                    »» es kann passieren, das z.B. in der k_notiz Tabelle 2 mal die selbe Notiz aber für unterschiedliche Kunden gespeichert ist. Das für ein Kunde nicht 2mal die selbe Notiz gespeichert wird, sollte sich mit ein Trigger abfangen lassen

                    hmm, da wären wir dann aber wieder bei einer n:m beziehung zwischen den notizen und den kunden, sprich du brauchst eine weitere beziehungstabelle, wo der fremdschlüssel des kunden und der notizen hinterlegt wird. und dann brauchst du auch keinen trigger, sondern legst über diese beiden fremdschlüssel einfach einen unique constraint und gut ist.

                    wenn ich eine m:n Beziehung erstelle, ist ja die Möglichkeit vorhanden, dass ich bei 2 Kunden auf die selbe Notiz zeige. Wenn die Notiz für Kunde 1 geändert wird, wäre die Notiz bei Kunde 2 auch automatisch geändert - das will ich eigentlich verhindern.

                    Lana

                    1. yo,

                      wenn ich eine m:n Beziehung erstelle, ist ja die Möglichkeit vorhanden, dass ich bei 2 Kunden auf die selbe Notiz zeige. Wenn die Notiz für Kunde 1 geändert wird, wäre die Notiz bei Kunde 2 auch automatisch geändert - das will ich eigentlich verhindern.

                      hmm, entweder reden wir von verschiedenen dingen und ich habe deine fachlichkeit nicht richtig verstanden oder aber du bringst da was durcheinander. aber das können wir schnell klären. die frage ist:

                      willst es möglich machen, dass in bestimmten fällen, eine und dieselbe notiz mehreren kunden zugeordnet werden kann oder soll dieser fall -> nie <- vorkommen ?

                      je nachdem wie deine antwort ausfällt, hast du eine n:m beziehung oder eine 1:n. auch muss man sich vor augen halten, dass ein gutes daten-design einem vor vielen schwierigkeiten bewahrt. es kann aber auf keinen fall die vollständige integrität der daten garantieren. jedes noch so gute design wird es ermöglichen, das man daten falsch eingibt. und dies bezieht sich nicht nur auf dateninhalte, sondern auch was die beziehungen betrifft.

                      Ilja

                      1. Hi!

                        »» wenn ich eine m:n Beziehung erstelle, ist ja die Möglichkeit vorhanden, dass ich bei 2 Kunden auf die selbe Notiz zeige. Wenn die Notiz für Kunde 1 geändert wird, wäre die Notiz bei Kunde 2 auch automatisch geändert - das will ich eigentlich verhindern.

                        hmm, entweder reden wir von verschiedenen dingen und ich habe deine fachlichkeit nicht richtig verstanden oder aber du bringst da was durcheinander. aber das können wir schnell klären. die frage ist:

                        willst es möglich machen, dass in bestimmten fällen, eine und dieselbe notiz mehreren kunden zugeordnet werden kann oder soll dieser fall -> nie <- vorkommen ?

                        je nachdem wie deine antwort ausfällt, hast du eine n:m beziehung oder eine 1:n. auch muss man sich vor augen halten, dass ein gutes daten-design einem vor vielen schwierigkeiten bewahrt. es kann aber auf keinen fall die vollständige integrität der daten garantieren. jedes noch so gute design wird es ermöglichen, das man daten falsch eingibt. und dies bezieht sich nicht nur auf dateninhalte, sondern auch was die beziehungen betrifft.

                        ich möchte bei ein Kunden N-Notizen hinzufügen (diese sollten noch sortierbar sein). Es kann vorkommen, dass bei ein anderen Kunden genau die selbe Notiz hinterlegt wird. Wenn ich die Notiz vom 2. Kunden andere, darf die des 1. Kunden nicht geändert werden.
                        Ich denke mal, dass das nur mit einer 1:n Beziehung realisiert werden kann, oder?

                        Lana

                        1. yo,

                          Es kann vorkommen, dass bei ein anderen Kunden genau die selbe Notiz hinterlegt wird. Wenn ich die Notiz vom 2. Kunden andere, darf die des 1. Kunden nicht geändert werden.

                          das ist ein denkfehler Lana. wenn ein und dieselbe notiz hinterlegt wird bei zwei oder mehreren kunden und sich die notiz ändert, dann muss sie sich zwangsläufig für alle ändern. ansonsten wäre es nicht dieselbe notiz. anderes sieht es aus, wenn die notizen genau gleich aussehen, aber trotzdem unterschiedliche notizen vond er abhängigkeit her sind. wie gesagt, mein leitspruch dazu ist immer, nicht alles, was gleich aussieht, muss auch gleich sein.

                          Ich denke mal, dass das nur mit einer 1:n Beziehung realisiert werden kann, oder?

                          deine aufgabe als designer ist es letztlich zu entscheiden, ob der fall vorkommen kann, das zwei kunden ein und dieselbe notiz haben können oder ob dieser fall nie vorkommt. und damit meine ich nicht, dass die notizen gleich aussehen, sondern dass es sich wirklich um eine notiz handelt. wenn das nie vorkommen kann, dann sicherlich 1:n ansonsten n:m

                          Ilja

                          1. Hi!

                            »» Es kann vorkommen, dass bei ein anderen Kunden genau die selbe Notiz hinterlegt wird. Wenn ich die Notiz vom 2. Kunden andere, darf die des 1. Kunden nicht geändert werden.

                            das ist ein denkfehler Lana. wenn ein und dieselbe notiz hinterlegt wird bei zwei oder mehreren kunden und sich die notiz ändert, dann muss sie sich zwangsläufig für alle ändern. ansonsten wäre es nicht dieselbe notiz. anderes sieht es aus, wenn die notizen genau gleich aussehen, aber trotzdem unterschiedliche notizen vond er abhängigkeit her sind. wie gesagt, mein leitspruch dazu ist immer, nicht alles, was gleich aussieht, muss auch gleich sein.

                            hm... das muss/sollte ich dann noch kären

                            Lana