Also da das ganze nun so komplex wurde, steht das Konzept eindeutig im Vordergrund und nicht unbedingt ein Prototyp.
im thema Software, werde ich einen kriterienkatalog bearbeiten mit allen Infos die ich bekomme...
Zum Thema Datenbankenkonzept:
Es ist wichtig, dass die Datenbank an den Geschäfts-Workflow des Schätzungsprozesses gebunden ist.
Das heißt an bestimmten Schritten im Prozess hat eine bestimmte Person ein bestimmtes Recht etwas bestimmtes zu machen. Entweder die Person muss es oder darf es. Kopfdaten des Programms können zum Beispiel immer bearbeitet werden.
Ich habe mir jetzt die Prozess-Dokumentation angeschaut und geschaut an welcher Stelle welche Person was machen muss und denke mir dafür verschiedene FORMULARE aus und versuchezu verstehen, wie die Abfragen zur Datenbank aussehen können. Zum einen muss irgendwann mitten im prozess, bevor es weiter geht, eine elektronische Signierung stattfinden, wo die Datenbankstruktur ganz anders aussieht. Dazu habe ich einen anderen Thread. Später kommt an die stelle des Dokuments, eben vielleicht der Gesamtreport dieser Datenbank hier und die Datenbank muss dann auch blockiert sein, also alle Formulare, solange nicht alle "unterzeichnet" haben.
Es gibt einige entitäten in diesem Prozess. Die Hauptentität jedoch ist das "Program".
Bei einem "Program" (aus dem Projektmanagement) handelt es sich um ein Bündel aus Entwicklungsprojekten oder nur einem Projekt.
Das "Program" ist einem Kunden zugeordnet und ein Kunde kann mehreren "Programmen" zugeordnet sein. Ein Program hat 1 oder mehrere Geschäftsszenarien. 1 Geschäftsszenario kann für mehrere Programme genutzt werden. 1 oder mehrere Kostenstellen sind den Entwicklungsprojekten zugeordnet und ein Entwicklungsprojekt kann 1 oder mehrere Kostenstellen haben.
Ein Program "bearbeitet" ein bestimmtes Produkt. Ein bestimmtes Produkt kann mehreren Programmen zugeordnet sein.
Dann gibt es noch Platform und Produktilinie. Die (m:1) zum programm stehen.
Das wichtigste ist dann die Entität Costs&Resources, in die der Hauptinput (Arbeitsstunden, Kosten) fließen soll.
Die Person (Projektleiter) die diese Zahlen eingibt, gibt sie für Kostenstellen ein. Er soll immer alle Zahlen sehen können und diese erhöhen oder senken können (für alle Kostenstellen).
Im Anhang befindet sich mein vorläufiges ER-Diagram.
Was haltet ihr davon?
Das wichtigste der Features die einer meiner Reports können muss ist die Darstellung der Aufwände zugeordnet zu Projekten, Kostenstellen, Szenarios und (Abteilungen).
Ich habe mich bei den Beziehungen, wie man im ER-Diagramm sehen kann, auf das minimalste Beschränkt. Dabei Frage ich mich aber wie ich beispielsweise für Szenario 'ABC' Kosten ermittle. Falls eine Beziehung zwischen Scenarios und Cost&Resources bestehen würde, wäre es einfach:
Select Costs
From Cost&Resources
Where FK_Scenario =
(Select Scenario_ID
From Scenarios
Where Scenario_Name = 'ABC')
Ohne diese Beziehung ist die Abfrage sehr viel länger und bestimmt auch ineffizienter. Wie gehe ich also am besten vor bei einer Konzeption?
Eigentlich sind nämlich auch Produktlinie, Produkt, Platform und Kunde voneinander abhängig. So könnte man später die Pulldown-Menüs verkleinern, weil beispielsweise bei einer bestimmten Produktlinie schon 3/4 der gesamten Produkte rausfallen würden und man könnte nichts falsches wählen. Aber dann ist das Diagramm später voll von Verbindungen und komplett unübersichtlich.
Mach ich mehr Verbindungen oder müssen es so wenige es geht sein? (Redundanz)
Viele Grüße
Säsch
