nicht angemeldet
Hi nochmal,
ein paar Kommentare zu Dingen, die mir auf den ersten Blick aufgefallen sind.
- Was sind deine "Bereiche"? Logische Funktionseinheiten deiner Anwendung?
Du kennst also den Begriff Bereich nicht im Zusammenhang mit Datenmodellierung?
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.
- 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.
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.
Versuche dich selbst erstmal wieder von der Platformabhängigen Modellierung (OO-Abstraktion, FK und Tabellen und so) zu distanzieren und nochmal von vorn mit den reinen Entitäten (Was ist eine Massnahme, was ist eine Situation, was hängen welche Entitäten zusammen).
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.
Hast du für dein Projekt auch eine praktische Anwendung (Auftrag, Muster-Nachentwicklung)?
Ja, viele. Un die braeuchtest Du auch um die Modelliergung zu verstehen.
Das führt an dieser Stelle zu weit.
Cheers, Frank