Entwicklung eines Datenbanksystems

[Säsch]

könnte das nicht so funktionieren, wie tom das vorgeschlagen hat?

Eine tabelle die als attribut listenfelder hat, in der alle fremdschlüssel aller entitäten liegen:
id | tab_a_id | tab_a_projekt_spalte | tab_a_verantwortlich_spalte | tab_b_id | tab_b_kunde_spalte | ...
Sobald der Prozessschritt Business Awarded beispielsweise erreicht wurde, werden alle IDs in diese Tabelle geladen und unter Version Version_Business_Awarded abgespeichert und eingefroren.
Das selbe auch bei den nächsten wichtigen Prozessschritten.

Ich glaube das es ausreicht zumindest auf alle Reports dieses Zeitpunkts zugreifen zu können, nicht diesen ganzen Datenbankstatus zu übernehmen. Ich muss das mal klären oder argumentieren warum es kein sinn macht. Meine betreuer haben keine Ahnung von Datenbanken. Das ist nur ein Punkt der sich bei der Anforderungsanalyse herausgestellt hat. Wenn ich aber sage, das macht in SQL kein sinn sondern ein einfacher Zugriff auf Statusreports macht mehr sinn, dann ist das auch okay. Möchte eben was sinnvolles schreiben. Versionierung ist nur ein Teilthema. Ich muss eben alle Anforderungen aufrollen udn analysieren.

 

[Tom.S]

Aber ich glaube es soll eine Version der kompletten Tabellen-Struktur gemacht werden. Weil die ganze Tabellenstruktur aus Teilen der Aufwandsabschätzung besteht: Schätzungsmodelle, Projekte, die Produkte, Kunde etc. Wenn ich eine Version bei Änderungen für nur einzele Tabellen erzeuge, kann ich nur Versionen für einzelne Entitäten finden. Ich weiß nicht so genau was mir das bringen soll, weil alle anderen Tabellen eine ganz unterschiedliche Anzahl an Versionen haben. Wie greife ich daruf logisch zu? Z.B. wenn ich mir die Schätzungszusammenfassung von dem Zeitpunkt ansehen will, an dem der Kunde den Vertrag unterschrieben hat mit ALLEN Tabelleninfos.

Besser wäre es, wenn bei einer Änderung egal wo ein komplette Versions-Snapshot der ganzen Datenbank gemacht wird, weil nur dann kann man Schätzung Version 1, Schätzung Version 2, 3 ,4 etc finden oder liege ich falsch?

Ich habe Dir Deine Frage eigentlich schon beantwortet:
Entwicklung eines Datenbanksystems | Seite 3 | Datenbank-Forum
Dort findest Du die drei mir bekannten Möglichkeiten, das mit SQL umzusetzen.

könnte das nicht so funktionieren, wie tom das vorgeschlagen hat?

Eine tabelle die als attribut listenfelder hat, in der alle fremdschlüssel aller entitäten liegen:
id | tab_a_id | tab_a_projekt_spalte | tab_a_verantwortlich_spalte | tab_b_id | tab_b_kunde_spalte | ...
Sobald der Prozessschritt Business Awarded beispielsweise erreicht wurde, werden alle IDs in diese Tabelle geladen und unter Version Version_Business_Awarded abgespeichert und eingefroren.
Das selbe auch bei den nächsten wichtigen Prozessschritten.

Das funktioniert aber nur wirklich gut, wenn Du die Versionierung in das Datenschema einbaust (Variante 2), also Daten generell nicht mehr editierst oder löschst. Es würde zwar trotzdem funktionieren, weil Du ja auch die tatsächlichen Werte der Datenfelder speicherst, es gäbe aber keine Verknüpfung mit den Daten mehr. Du könntest dann auch einfach PDF-Reports erstellen.

 

[Säsch]

Guten Tag,

könnte ihr mir bei einer wohl "einfachen" Abfrage helfen. Im Anhang befindet sich das ER-Diagramm, um das es geht, das relationale Diagram erstelle ich erst nächste Woche, wenn das riesige Eingabemasken "Storyboard" beendet ist.

In einemEntwicklungs-Programm werden bestimmte Produkte entwickelt (Scenarios), von bestimmten Entwicklungs-Projekten (Projects), denen bestimmte Kostenstellen (Cost Centers) zugeordnet sind. Zur Übersichtlichkeit dachte ich mir gibt es eine Input-Tabelle (Cost&Resources) die sämtlichen Input speichert und den jeweiligen Kostenstellen zuordnet.

Man muss sich das so vorstellen, dass man vor der Schätzung im Front End das Entwicklungsprogram wählt, das Scenario, das Projekt und die Kostenstelle und dann den Input tätigt. Die Kostenstelle ist der Hauptträger des Inputs, weil in den Kostenstellentabellen Stundensätze und Rollen als Attribute abgespeichert sind.

Wie genau frage ich nun die Gesamtkosten eines bestimmten Scenarios S ab? Mir fällt nur ein ewig lange Schlauch and SELECT-WHERE-Kombinationen ein. Und ich weiß nicht wie ich auf "ALLE" Projekte des Programs mit "ALLEN" Kostenstellen referenziere, weil ich ja die Summe aus allen Werten der Kostenstellen brauche?

Könnt ihr mir einen SELECT geben oder zumindest einen Gedankenstoß?

Und warum ist es in der Theorie nicht erlaubt, zwecks Inkonsitenz einfach weitere Beziehungen, wie zum Beispiel Scnearios: Projects; Scenarios: Cost Centers und Scenarios: Cost&Resources zu speichern? Kann das nicht praktisch alles von der Front End Logik geregelt werden, sodass man überhaup keine Inkonsistenz erzeugen kann?

Danke und schönes Wochenende!

 

[Distrilec]

Front End Logik geregelt werden, sodass man überhaup keine Inkonsistenz erzeugen kann?

Und dann hast du bei einem Feld eine If-Bedingung vergessen... oder Statt '>=' nur '>' geschrieben und schon sind die Daten inkonsistent... Und Sie werden es wahrscheinlich auch immer bleiben

Bezüglich deines Modells... Ich sehe da grade nicht das Problem? Ein Statement mit 4 Joins ist jetzt nichts wirklich ungewöhnliches...

Edit:
Mal als Pseudo-Code...

Select Sum(cr.costs) as "Gesamtsumme"
From ClarityProgram CP

Left Join Projects P
On ...

Left  Join CostCenters CC
On ...

Left Join CostResources CR
On ...

Where CP.scenario = 'S'

Auch wenn ich aus deiner Hierarchie noch nicht so ganz schlau werde... Aber das hat bestimmt seinen Sinn

 

[Säsch]

Danke erst mal für eure Hilfe. Ohne euch wäre die BA sehr viel härter

Ja also die Hierarchie ist so gedacht:
Das Program ist das, um das es geht. Das muss man suchen und finden können. die blauen Entitäten die oben zu sehen sind (kunde, platform, etc) dienen zur Identifizierung des Programms und werden dann praktisch dauerhaft als Basisinformation im Front End angezeigt und dann müssen sie nicht mehr referenziert werden.

die anderen beiden zweige zu den grünen Entitäten beziehen sich einmal auf die Produkte und der andere auf die beteiligten "Abteilungen", die die Produkte entwickeln.

Zwecks "Traceability" gibt es noch die Entität Scenarios, die aus historischen Gründen im ERM zu finden ist, das alle verstehen um was es da geht. Eigentlich ist das Scenario das Produkt, also das Enditem. Enditem ist ebenfalls ein historischer begriff

Das Enditem besteht aus einem Standardprodukt, das im Baukasten-Prinzip im Frontend zusammengebaut werden soll + einer Erweiterung. Es geht ja um kostenschätzung von "neuen" Produkten.

Dennoch basieren diese "neuen" Produkte zu ~80% aus Standardprodukten die mit einem "Zusatz" angepasst werden.