nicht angemeldet
Hi,
ich verstehe deine Frage nicht.
Je weiter dieser Thread fortschreitet, desto mehr verschwimmt deine Problematik (vorallem aufgrund deiner Antworten). Deshalb noch mal ein Recap auf Basis deiner letzten Antworten.
Bereiche sind Mengen von Tabellen die in einem engen thematischen
Bezug zueinander stehen. ( z.B "Benutzer" beinhaltet Tabellen wie Personen, Adressen, Kontakte etc.. )
Schau Dir dazu vielleicht nochmal meine Auflistung in meinem Ausgangsposting an.
Okay, aber das hat nichts mit deinem OO-in-RDBMS-Modellierungsproblem zu tun. Auch wenn ich mir das noch 100 mal anschaue, es ändert nix. Aber dank deiner Antwort haben wir jetzt dieselbe Vorstellung von "Bereich".
- Tabelle Interne Massnahmen (I) - beziehen sich 1:n auf S
- Tabelle Externe Massnahmen (E) - beziehen sich 1:n auf S
- warum nicht 1 Tabelle, mit einem Attribut für I und E zur Unterscheidung?
Die Tabellen werden jeweils von grossen Mengen M1, M2 weiterer Tabellen jeweils 1:n referenziert.
Die beiden Mengen M1, M2 sind nahezu disjunkt.
Ja und? Wo ist der Zusammenhang zwischen Menge M1, M2, deren potentieller Schnittmenge und der Relation zu "Massnahmen"? Oder sind M1 die internen Massnahmen und M2 die externen? Ich dachte, die heissen I und E. Und interessant wäre, wieviel Gemeinsamkeiten I und E haben.
Diese deine Antwort war ein sehr gutes Beispiel dafür, wie du die Problematik noch weiter verwirren und verschwimmen lässt.
Leider fehlt mir etwas die Vertrautheit mit deiner Materie um schnell mal ein mögliches ERM aus meiner Sicht vorschlagen zu können.
Das ist auch nicht notwendig. Das ist meine Aufgabe.
Aber du brauchst/suchst/willst Hilfe, oder doch nicht?
Danke, aber erstens weiss ich wie man Software entwickelt ;-), zwitens haben wir bereits einen Evolutionszyklus samt Refactoring mit dem Modell durchlaufen und drittens wird das nichts bringen.
Diese Tabellen ( und Klassen ) braucht das Modell ganz einfach.
Aber du brauchst/suchst/willst Hilfe, oder doch nicht?
Und Ignoranz ist übrigens keine Tugend.
Ja, viele. Un die braeuchtest Du auch um die Modelliergung zu verstehen.
Das führt an dieser Stelle zu weit.
Aber das, was du lieferst an Problembeschreibung, macht es nicht gerade leicht, dir Hilfe bei der Modellierung zu bieten. Du kennst das Sprichwort "Wie man in den Wald hineinruft, so schallt es heraus."?
In diesem Thread hast du schon mehrere rein technische Ansätze (Check Constraints, Tabellenschemata) gesehen. Ich bleibe jedoch bei meiner Meinung, dass ihr/du mindestens eine grundsätzliche konzeptionelle Schwäche / Fehler im Modell habt und mein Rat: Back to field 1!
Hast du jetzt eigentlich noch konkrete Fragen?
So long, Frank