Vorkommen von bestimmten Abrechnungsziffern zusammenzählen

[m.m.g]

Hallo liebe Community,

ihr habt mir schon sehr viel geholfen. Leider wird es sicher noch eine Weile dauern, bis ich auch etwas zurückgeben kann.

Aktuell stehe ich vor einem Problem, dass ich wohl ohne Hilfe nicht lösen kann.
Folgendes habe ich:

Ich benötige nun das Gesamtvorkommen für die Ziffern 19411, 19421, 19424, 19451, 19452 und 19453
Für die markierte Zeile hätte ich also gerne:
000925 19451 15 19452 5 19453 19
Wobei sich das Ergebnis für 19453 natürlich aus den zweimaligen Vorkommen, also 17+2, zusammensetzt.

Ich hoffe, ich habe mich verständlich ausgedrückt. Könnt ihr mir dabei helfen?

Viele Grüße
Marc

 

[dabadepdu]

Da braucht man etwas mehr Infos. Was ist mit den Feldern bzw. Spaltennamen, ist das schon ein Abfrageergebnis? Sind die dargestellten Spalten fix oder variabel, z.B. Ergebnis eines PIVOT?
Man könnte ein UNPIVOT machen, verrechnen und wieder pivotisieren.
Oder man lässt es bei der Verrechnung, ohne die Daten erneut in ein Format zu bringen, für das RDBMS nicht gemacht sind.

 

[m.m.g]

Hallo,
vielen Dank für die schnelle Antwort.
Ja, es handelt sich schon um ein Abfrageergebnis. Die dargestellten Spalten sind fix.
UNPIVOT hatte ich mir schon angeschaut, sehe aber den Einsatz bei meinem Problem nicht.
Allerdings habe ich es nicht so mit Pivot. Nicht mal in Excel.

 

[dabadepdu]

Ok, wenn es das Ergebnis einer Abfrage ist, solltest Du mit den Ausgangsdaten arbeiten, nicht mit dem Abfrageergebnis.
In der Abfrage, die die obigen Daten ausgibt, taucht wahrscheinlich schon ein PIVOT auf, oder ein CASE WHEN.

Nahezu immer, wenn man PIVOT einsetzt, sollte das als "Endergebnis" betrachtet werden, als Report sozusagen.
Um im Bild zu bleiben, Du würdest wahrscheinlich auch nicht in Excel mit den Ergebnissen einer Pivottabelle weiterarbeiten und da neue Formeln dran hängen..

Allerdings habe ich es nicht so mit Pivot. Nicht mal in Excel.

Und was bedeutet das? Wir sind fertig?

 

[dabadepdu]

Hier ist ein deutsches Beispiel, was das Prinzip zeigt.

Datenintegration mit SQL - Teil 1 PIVOT und UNPIVOT

Datenintegration mit SQL - Teil 1 dieser Artikelserie stellt die Operatoren PIVOT und UNPIVOT vor und zeigt, wie sich damit Datenintegration realisieren lässt.

blog.viadee.de

 

[Georg V.]

@m.m.g Wie gesagt, man formuliert besser die Originalabfrage für diese Ergebnistabelle um, um die Daten wieder in der Tabellenform DBCNUMMER, DBCP_GO, DBNP_ANZ, DBDEINDAT zu bekommen.
Aber falls Du unbedingt die gezeigte Tabelle als Quelle und den nicht Standardbefehl UNPIVOT() vermeiden willst (was ich -nebenbei gesagt- persönlich ebenfalls bevorzuge), dann wird das notwendige Statement eben etwas länger.
Step 1

select DBCNUMMER, DBCP_GO1 as DBCP_GO, DBNP_ANZ1 as DBNP_ANZ, DBDEINDAT from tA

Step 2

kopiere Statement von Schritt Step1 noch ein mal, ändere die eins in zwei und schreibe zwischen den beide Statements ein UNION ALL.

select DBCNUMMER, DBCP_GO1 as DBCP_GO, DBNP_ANZ1 as DBNP_ANZ, DBDEINDAT from tA
UNION ALL
select DBCNUMMER, DBCP_GO2 as DBCP_GO, DBNP_ANZ2 as DBNP_ANZ, DBDEINDAT from tA

Step 3
wiederhole Schritt Step 2 solange bis Du auch die zwölfte Spalte in den Daten hast.

Step 4
erstelle eine GROUP BY bezüglich DBCNUMMER, DBCP_GO, DBDEINDAT und summiere DBNP_ANZ

Wo Du die Filterung der Ziffern vornimmst, ist eher eine Frage vom Datenmodell und Datenmenge. Performance sagt vorne in Schritt Step 1, Codesauberheit sagt nur an einer Stelle, falls die Werte geändert werden müssen. Dann wäre Schritt Step 4 der korrekte Ansatz. Meine bevorzugte Lösung bei dieser Variante wäre eher Datenmodell basiert (die Nummern gehören doch bestimmt einer besonderen Gruppe von DBCNUMMER an?). Mein Standard wäre selbst als Verfechter von auf einander aufbauenden SQL Statements allerdings einen Schritt zurück und die Originaltabelle /-abfrage als Grundlage zu nehmen.

 

[m.m.g]

Vielen Dank für die konstruktiveb Antworten.
Dem Ansatz von Georg werde ich mal als erstes Nachgehen, weil ohne Pivot
Wenn ich es hinbekomme, melde ich mich noch mal.

 

[m.m.g]

Hallo Georg,
toller Tip. Nach ein bisschen Probieren habe ich alles so weit hinbekommen. Vielen Dank.

Jetzt habe ich nur ein neuen Problem mit folgendem Code:

Select
DBCPRAEFIX,
DBCNUMMER,
DBCP_GO,
Sum(DBNP_ANZ) As S_DBNP_ANZ,
DBDEINDAT
From
( mein ganzen inneren Selects aus schritt 3 )
Where
DBCP_GO Like '19451' And
S_DBNP_ANZ > 15
Group By
DBCPRAEFIX, DBCNUMMER, DBCP_GO, DBDEINDAT

S_DBNP_ANZ führt zu oracle -00904: "S_DBNP_ANZ": ungültiger Bezeichner
In meiner Verzweiflung habe ich SUM_DBNP_ANZ schon umbenannt, weil ich gelesen hatte, dass in einem Alias keine schlüsselworte vorkommen dürfen. Gebracht hat es leider nichts.

Hast Du auch dazu eine Idee?

 

[Georg V.]

Problem ist, dass ein Spaltenalias erst außerhalb des SELECT bekannt sind. Es gibt drei Varianten der Lösung, die auch bei nicht so großen Datenmengen wohl gleich schnell sein dürften.

Version 1
Select
DBCPRAEFIX,
DBCNUMMER,
DBCP_GO,
Sum(DBNP_ANZ) As S_DBNP_ANZ,
DBDEINDAT
From
( mein ganzen inneren Selects aus schritt 3 )
Where
DBCP_GO Like '19451' And
Sum (DBNP_ANZ) > 15
Group By
DBCPRAEFIX, DBCNUMMER, DBCP_GO, DBDEINDAT

Version 2
Select *
From (
DBCPRAEFIX,
DBCNUMMER,
DBCP_GO,
Sum(DBNP_ANZ) As S_DBNP_ANZ,
DBDEINDAT
From
( mein ganzen inneren Selects aus schritt 3 )
Where
DBCP_GO Like '19451')
q1
Where S_DBNP_ANZ > 15
Group By
DBCPRAEFIX, DBCNUMMER, DBCP_GO, DBDEINDAT

Version 3
Select
DBCPRAEFIX,
DBCNUMMER,
DBCP_GO,
Sum(DBNP_ANZ) As S_DBNP_ANZ,
DBDEINDAT
From
( mein ganzen inneren Selects aus schritt 3 )
Where
DBCP_GO Like '19451'
Having
SUM (DBNP_ANZ > 15)
Group By
DBCPRAEFIX, DBCNUMMER, DBCP_GO, DBDEINDAT

 

[m.m.g]

Es ist vollbracht
Version 3 ist es geworden. Mit ein paar kleinen Änderungen macht sie genau das, was ich brauche.
Vielen Dank noch mal, Georg.
Der Vollständigkeit halber hier der entgültige Code:

Select
DBCPRAEFIX,
DBCNUMMER,
DBCP_GO,
Sum(DBNP_ANZ) As S_DBNP_ANZ,
DBDEINDAT
From
( mein ganzen inneren Selects aus Schritt 3 )
Group By
DBCPRAEFIX, DBCNUMMER, DBCP_GO, DBDEINDAT
Having
DBCP_GO = 19451 And
Sum(DBNP_ANZ) > 15

 

[Georg V.]

Danke für die Rückmeldung! Die WHERE Bedingung DBCP_GO = 19451 in die HAVING Klausel zu übernehmen ist technisch möglich und wird bei den wahrscheinlich vorhandenen Datensatz Anzahl zu keinen Geschwindigkeitsverlusten führen.