Data Warehouse: Absatz und Produktionssteuerung - Datensätze duplizieren / berechnen?

J

J.Roca

Benutzer
Beiträge
7
Hallo,

ich beschäftige mich mit der Entwicklung eines Planungssystems zur Absatz- und Produktionssteuerung.

Einmal pro Monat findet die Planung der künftigen Absatzmengen auf täglicher Basis für alle Produkte und Filialen für die nächsten 18 Moante statt.
Dabei fallen ca. 20 Mio Datensätze an. Die Absatzplanung wird in eine (Fakten)tabelle mit dem Namen Absatz importiert.


Mein Problem:
Wie kommen die Daten von der Absatztabelle in die Lagertabelle (Dort sollen die Absatzmengen um die Mindestreserve angepasst werden und die zu produzierenden Mengen berechnet werden)

Die Auswertung erfolgt mit OLAP. Über einen Filter kann hier ein beliebiger Zeitraum ausgewählt werden - Die einzelnen Datensätze werden aggregiert und in einem Report angezeigt.

Meine Fragen:
1. Müssen für eine OLAP-Auswertung (roll-up) Datensätze in einer eigenen Tabelle (z.B. Produktionstabelle) gespeichert sein oder können die Werte über Formeln berechnet werden?
2. Wie muss die Architektur des Data Warehouse aussehen, um den beschriebenen Sachverhalt abbilden zu können?
3. Wie verschiebe/berechne ich die Datensätze zwischen den Faktentabellen (Absatz/Lager/Produktion)?

Verwendete Software: SQL-Server 2012 (Data Warehouse), PowerPivot (OLAP), Dynamics NAV (Quellsystem)

Bin für jede Hilfe dankbar!
Viele Grüße
Jörg
 
Werbung:
Also ich finde die Aufgabe schreit nach eine Triggerlösung. Wenn ich dich richtig verstehe hast du Datensatz A der in Tabelle A durch bestehende Software geschrieben. Dieser enthält Planwerte. In deiner Tabelle B müssen einzelne Felder davon abhängig angepasst werden.

Mit einem Trigger würdest du bei jedem Datensatz der in Tabelle A geschrieben wird prüfen, ob und welche Änderungen sich dafür in deiner Tabelle B ergeben und diese dann ggf. vornehmen.

Nachteil ist das du alles sehr genau in SQL abbilden musst damit keine Fehler passieren und das der Trigger natürlich jedesmal ausgeführt wird, also ggf. 20 Mio mal. Alternativ kann man das auch nachträglich in einem Script durchführen, das hat Vor- aber auch Nachteile.
 
Hallo Ukulele,

vielen Dank für Deine Antwort. Das war auch mein erster Gedanke und Versuch.
Dazu musste ich dem Trigger einen Cursor verpassen, damit bei gleichzeiter Eingabe mehrerer Datensätze die Datensätze nacheinander verarbeitet werden können. Da ich nicht weiß, in welcher Reihenfolge die Datensätze eingegeben werden, besteht der Primärschlüssel aus mehreren Feldern und wird über eine IF-clause identifiziert.
Dieser Trigger benötigte 10 Minuten für 1000 Datensätze. Wenn man das auf 20 Mio Datensätze prognostiziert....

Wenn ich mit Triggern oder Prozeduren arbeite, werde ich mir eine Lösung einfallen lassen müssen, um die Datensätze mit einem Unique-Key identifizieren zu können. Dann wäre eine beliebige Eingabereihenfolge der Plandaten nicht mehr möglich. (Denkbar wäre auch ein Datenimport über Integration Services nach Abschluss der Planung)

Gibt es eine Architektur, die ohne Trigger auskommt? Evtl. über eine DAX Formel in PowerPivot?
VG
 
Also ein Trigger wird immer nur einmal ausgeführt. Das heißt wenn ein INSERT Statement mehrere Datensätze umfasst wird nur der erste den Trigger auslösen und dieser kann auch nicht erkennen, welche anderen Werte betroffen sind. Vieleicht bietet sich hier tatsächlich ein Script an, das nachträglich ausgeführt wird. Dieses Script kann auch Datensatz für Datensatz auswerten oder mehrere auf einmal. Größter Nachteil ist in meinen Augen nicht die Laufzeit sondern das verhalten bei Fehlern.

Kannst du der Ausgangstabelle eine Spalte spendieren die nur du füllst? Dann kannst du jeden verarbeiteten Datensatz markieren. Eventuell kannst du aber auch, je nachdem welche Daten wohin geschrieben werden einen einzigen Update Befehl nutzen. Dazu kann ich aber nur mehr sagen, wenn ich die Spalten und Informationen kenne, die in Tabelle A und B betroffen sind.
 
ukulele schrieb:
Also ein Trigger wird immer nur einmal ausgeführt. Das heißt wenn ein INSERT Statement mehrere Datensätze umfasst wird nur der erste den Trigger auslösen und dieser kann auch nicht erkennen, welche anderen Werte betroffen sind.
Zum Vergrößern anklicken....

Ähm, vielleicht versteh ich grad was falsch, aber TRIGGER können per Statement oder per ROW auslösen - zumindest kenn ich das so bei PG. Ein per-ROW - TRIGGER sieht sehr wohl alle Datensätze. Oder ist das bei M$SQL anders?

Andreas
 
ukulele schrieb:
In der Tat, bei MS SQL gibt es nur per Statement. Ich kenne keinen anderen Weg.
Zum Vergrößern anklicken....

Echt?

Row-Trigger sind aber schon praktisch...

Code: 
test=# create table foo (i int);
CREATE TABLE
test=*# create or replace function foo_row() returns trigger as $$begin raise notice 'row level trigger';return new; end;$$language plpgsql;
CREATE FUNCTION
test=*# create or replace function foo_stm() returns trigger as $$begin raise notice 'statement level trigger';return new; end;$$language plpgsql;
CREATE FUNCTION
test=*# create trigger trg_row before insert on foo for each row execute procedure foo_row();
CREATE TRIGGER
test=*# create trigger trg_stm before insert on foo for each statement execute procedure foo_stm();
CREATE TRIGGER
test=*# insert into foo select * from generate_series(1,5) s;
NOTICE:  statement level trigger
NOTICE:  row level trigger
NOTICE:  row level trigger
NOTICE:  row level trigger
NOTICE:  row level trigger
NOTICE:  row level trigger
INSERT 0 5
test=*#

So geht es bei PG. Row-Level - Trigger können dabei auf NEW und OLD zugreifen, diese Arrays beinhalten die Werte der Datenzeile.

das mal so zur demo ...


Andreas
 
Werbung:
Hallo Ukulele,

danke für Deinen Tip mit den Spalten! Ja, ich kann der Ausgangstabelle Spalten hinzufügen. Im Quellsystem sind alle benötigten Mengenangaben für dieses Vorhaben in einer Tabelle "ValueEntry" gespeichert und über eine Dimensionsspalte (1,2,3) als Verkauf, Bestand, Produktion definiert.

In PowerPivot kann ich "zu berechnende Spalten" via DAX hinzufügen und etwa die benötigten Absatzmengen mit der Mindestreserve ableichen und dann die benötigte Produktionsmenge ermitteln. So arbeite ich bei den Planwerten mit nur einem Datensatz und kann an dieser Stelle auf die Trigger verzichten.

Nun muss ich mich nur noch in DAX einarbeiten ;)

@Akretschmer: Vielen Dank für den Row-Trigger. Beim nächsten Triggereinsatz werde ich überlegen, ob es ein Pendant bei SQL-Server gibt.

Viele Grüße
Jörg

mehrereSpalten.png
 
Zurück
Oben