Hallo,

gibt es eine schöne Möglichkeit, eine Auswertung nach Schichtzeitraum zu machen.

Ich habe eine Tabelle mit Produktionsdaten, immer eine Zeile mit Datum/Uhrzeit und gefertigtem Typ.

Daraus sollte eine Übersicht extrahiert werden, die mir dann sagt:
Tag 1 Schicht 1 (8:00-14:00) 100 Stück
Tag 1 Schicht 2 (14:00-22:00) 125 Stück
Tag 1 Schicht 3 (22:00-6:00) xxx Stück
Tag 2 Schicht 1 ......

Ich könnte natürlich eine Spalte mit der Schichtnummer einführen und der Uhrzeit entsprechend füllen, aber vielleicht gibt es ja auch eine Möglichkeit der SQL-Abfrage

Gruß Rainer

Vorab: beginnt die erste Schicht wirklich um 8:00 und nicht um 6:00?

Als Besonderheit ist zu berücksichtigen, daß die Stückzahlen zwischen 0:00 und 6:00 der dritten Schicht des Vortages zugerechnet werden. Mit einer einfachen Spalte Schichtnummer ist es also nicht getan. Man müsste also ein Schichtdatum und eine Schichtnummer zuordnen.

Nebenbei muss auch noch der Vollständigkeit halber geklärt werden, was an den Schichtgrenzen passieren soll.

Wenn du das wirklich nur für diese Auswertung brauchst, dann geht das so

markieren

Code:

CREATE TABLE PROD (
    ID      BIGINT NOT NULL,
    TXT     VARCHAR(80),
    ANZAHL  INTEGER,
    ZEIT    TIMESTAMP);

select
cast(prod.zeit-.25 as date) schichtdatum,
CASE
  WHEN (EXTRACT(HOUR FROM prod.ZEIT) BETWEEN 8 and 13) then 1
  WHEN (EXTRACT(HOUR FROM prod.ZEIT) BETWEEN 14 and 21) then 2
  else 3
end schicht,
sum(prod.anzahl)
from prod
group by 1,2

In Firebird kann das aber auch als berechnetes Feld erstellt werden, welches du
dann sogar via Expression Index indizieren kannst (War Thema bei der Schulung
in Wardenburg an den Tagen wo du nicht da warst , ist aber in Köln auch
wieder Thema). Berechnete Felder belegen keinen eigenen Speicherplatz (abgesehen
vom Eintrag in rdb$relation_fields) und können wie jedes andere Feld auch
in anderen SQLs benutzt werden.

Wenn deine Schicht bis 6:00 Uhr geht kann du das Tagesdatum der Schicht immer aus
"Zeit - 0.25" berechnen (Mittags um 12 ist 0.5, Nachmittags 18:00 Uhr ist 0.75 usw.)

Beispiel DDL

markieren

Code:

/******************************************************************************/
/****              Generated by IBExpert 02.06.2013 08:55:48               ****/
/******************************************************************************/

CREATE TABLE PROD (
    ID      BIGINT NOT NULL,
    TXT     VARCHAR(80),
    ANZAHL  INTEGER,
    ZEIT    TIMESTAMP,
    SCHICHTDATUM COMPUTED BY (CAST (ZEIT-0.25 as date)),
    SCHICHT COMPUTED BY (CASE
  WHEN (EXTRACT(HOUR FROM ZEIT) BETWEEN 8 and 13) then 1
  WHEN (EXTRACT(HOUR FROM ZEIT) BETWEEN 14 and 21) then 2
  else 3
end)
);

ALTER TABLE PROD ADD PRIMARY KEY (ID);

CREATE INDEX PROD_IDX1 ON PROD COMPUTED BY (SCHICHT);

Da die Auswertung nach Schichten nach meiner Erfahrung ein zentraler Bestandteil der Reports ist, sollte man sich Mühe geben, es richtig zu machen.

Ich hatte oft den Fall, das sich das Arbeitsmodell bezüglich der Schichten verändert hat: von 2 auf 3, dann auf 4 Schichten. Am Freitag ist Betriebsversammlung, da geht die Schicht nur bis 13:30, dafür machen wir ab nächster Woche Wochenendschichten von 06:00-12:00 usw. Und richtig lustig wird es, wenn die Abteilung nebenan nicht mitmacht-

Also benötige ich eigentlich im Datensatz des einzelnen Werkstücks neben der Zeit- auch die Schichtangabe. D.h. immer wenn ich einen Zeitstempel in meiner Tabelle eintrage ('Werkstück fertiggestellt um XX:YY von PP auf Maschine MM'), gebe ich die zu diesem Zeitpunkt gültige Schichtnummer mit an.

Dann können sich Schichtmodelle ändern, ein Sonderfall eintreten, die Abteilung nebenan eine Sonderlocke fahren, egal was. Meine Daten und Reports sind immer korrekt. Auch rückwirkend.

Das geht mit den hier beschrieben einfachen Vorschlägen nicht.

Zitat von Furtbichler:

... Das geht mit den hier beschrieben einfachen Vorschlägen nicht.

Das war aber auch gar nicht Rainers Ausgangslage ...

"Ich habe eine Tabelle mit Produktionsdaten, immer eine Zeile mit Datum/Uhrzeit und gefertigtem Typ."

Warum soll er für Probleme, die er wahrscheinlich gar nicht hat, das komplette Datenmodell
in Frage stellen ....

Der Ansatz eines variablen Werkskalenders ist aber nicht schlecht, aber ein komplettes Thema für sich
und statisch kann man zu jedem Datensatz natürlich alles möglich speichern, bis hin zum Namen des
Mitarbeiters, der das gefertigt hat und welche Werkzeuge er benutzt hat ...