Hallo. Ich möchte Base nutzen, um Kalkulationen zu erstellen.
Hierzu müssen einige Datenfelder miteinander mathem. verknüpft werden.
Wie macht man das ? Habe im Forum keine Informationen hierüber gefunden.
Gruß aus Soest
Berechnete Felder.
Moderator: Moderatoren
-
Fritz_Soest
- Beiträge: 8
- Registriert: So, 13.11.2005 18:54
- Wohnort: Soest
Re: Berechnete Felder.
Hallo Fritz,
ich bin genau wie Du Umsteiger von Access auf Base und probiere gerade verschiedenes aus.
Um ein berechnetes Feld in der Abfrage anzulegen gibst Du in die "Feld"-Zeile der Abfrage die Rechenformel ein, z.B.: "Tarifgehalt" + "Zulage", wenn die Inhalte der beiden Datenfelder "Tarifgehalt" und "Zulage" addiert werden sollen. Übrigens die "..." braucht man nicht einzugeben, die erscheinen automatisch!
Es ist mir allerdings noch nicht gelungen, die Spaltenüberschrift wie bei Access festzulegen - vielleicht geht das mit SQL.
Gruß Günter
ich bin genau wie Du Umsteiger von Access auf Base und probiere gerade verschiedenes aus.
Um ein berechnetes Feld in der Abfrage anzulegen gibst Du in die "Feld"-Zeile der Abfrage die Rechenformel ein, z.B.: "Tarifgehalt" + "Zulage", wenn die Inhalte der beiden Datenfelder "Tarifgehalt" und "Zulage" addiert werden sollen. Übrigens die "..." braucht man nicht einzugeben, die erscheinen automatisch!
Es ist mir allerdings noch nicht gelungen, die Spaltenüberschrift wie bei Access festzulegen - vielleicht geht das mit SQL.
Gruß Günter
-
Uli Böhmer
- Beiträge: 1
- Registriert: Mi, 14.12.2005 18:19
Mit berechneten Feldern weiterrechnen
Hallo zusammen
Ja, es ist tatsächlich einfach, berechnete Felder mit einem Alias-Namen zu erstellen.
Was mir indes noch fehlt ist Folgendes: Wenn ich ein berechnetes Feld erzeuge - z.B. mit dem Aliasname 'Bruttolohn' als Summe von "Tarifgehalt" + "Zulage" - und dann mit diesem Feld weiterrechnen möchte - z.B. "Bruttolohn"*Sozialabzug(%) - bekomme ich eine Fehlermeldung 'Die Dateninhalte konnten nicht geladen werden. Spalte nicht gefunden: Umsatz'.
Kann mir hier jemand weiterhelfen, wie man das macht?
Gruss
rso
Ja, es ist tatsächlich einfach, berechnete Felder mit einem Alias-Namen zu erstellen.
Was mir indes noch fehlt ist Folgendes: Wenn ich ein berechnetes Feld erzeuge - z.B. mit dem Aliasname 'Bruttolohn' als Summe von "Tarifgehalt" + "Zulage" - und dann mit diesem Feld weiterrechnen möchte - z.B. "Bruttolohn"*Sozialabzug(%) - bekomme ich eine Fehlermeldung 'Die Dateninhalte konnten nicht geladen werden. Spalte nicht gefunden: Umsatz'.
Kann mir hier jemand weiterhelfen, wie man das macht?
Gruss
rso
Hallo rso,
Bruttolohn kann nicht gefunden werden, da es eben keine Spalte in der Tabelle ist, sondern nur ein Alias für eine Berechnung, die mit Spalteninhalten durchgeführt wurde. Er setzt sich zusammen aus Tarifgehalt und Zulage. Möchtest Du dazu nun den Sozialabzug multiplizieren, dann benutze
( "Tarifgehalt" + "Zulage") * "Sozialabzug"
Gruß Barlee
Bruttolohn kann nicht gefunden werden, da es eben keine Spalte in der Tabelle ist, sondern nur ein Alias für eine Berechnung, die mit Spalteninhalten durchgeführt wurde. Er setzt sich zusammen aus Tarifgehalt und Zulage. Möchtest Du dazu nun den Sozialabzug multiplizieren, dann benutze
( "Tarifgehalt" + "Zulage") * "Sozialabzug"
Gruß Barlee
Hallo Barlee
So wie mein Beispiel konstruiert ist, ist Dein Lösungsvorschlag ok. Aber was machst Du, wenn sich 'Bruttolohn' nicht einfach aus einer Summe ergibt, sondern aus einer Bedingung, z.B.:
Bruttolohn=wenn(Tarifgehalt<=100'000;Tarifgehalt+Zulage1;Tarifgehalt+Zulage2)
Dann hast Du je nach dem, ob die Bedingung wahr oder falsch ist, eine andere Formel zur Ermittlung des Bruttolohnes. Genau ein solches Beispiel führt eben dazu, dass es nötig wird auf ein berechnetes Feld referenzieren zu können, weil nicht einfach eine einfache Formel wiederholt werden kann.
Weisst Du hierzu eine Lösung?
Gruss
rso
So wie mein Beispiel konstruiert ist, ist Dein Lösungsvorschlag ok. Aber was machst Du, wenn sich 'Bruttolohn' nicht einfach aus einer Summe ergibt, sondern aus einer Bedingung, z.B.:
Bruttolohn=wenn(Tarifgehalt<=100'000;Tarifgehalt+Zulage1;Tarifgehalt+Zulage2)
Dann hast Du je nach dem, ob die Bedingung wahr oder falsch ist, eine andere Formel zur Ermittlung des Bruttolohnes. Genau ein solches Beispiel führt eben dazu, dass es nötig wird auf ein berechnetes Feld referenzieren zu können, weil nicht einfach eine einfache Formel wiederholt werden kann.
Weisst Du hierzu eine Lösung?
Gruss
rso
Hallo rso,
das ließe sich doch evtl. so abprüfen:
...und weiter rechnen kannst Du damit auch
Um nochmal auf Dein vorheriges Beispiel zurückzukommen:
Gruß Barlee
das ließe sich doch evtl. so abprüfen:
Code: Alles auswählen
casewhen(Tarifgehalt<=100000,Tarifgehalt+Zulage1,Tarifgehalt+Zulage2) as BruttogehaltUm nochmal auf Dein vorheriges Beispiel zurückzukommen:
Code: Alles auswählen
casewhen(Tarifgehalt<=100000,Tarifgehalt+Zulage1,Tarifgehalt+Zulage2)*Sozialzuschlag as GehaltHallo Barlee
Ja, das könnte ich so machen; aber Du gibst mir recht, das ist nicht die "elegante" Methode. Bei diesem kleinen Beispiel macht es zwar tatsächlich keinen Unterschied, aber wenn die Bedingung umfangreicher ist, dann hat man aufgrund der Formelwiederholung eine rechte Menge redundanten Code, was sich nebst der Performance auch auf die Übersichtlichkeit (wegen Wartung und Weiterentwicklung) auswirkt.
Mein aufgeführtes Beispiel ist nämlich nur eine extrem vereinfachte Problemstellung zum Erlernen, wie man diese in SQL grundsätzlich lösen kann. Tatsächlich kommen diese Problemlösungen nachher in viel komplexeren Problemstellungen zum Tragen, wie sich aus nachfolgendem Formelbeispiel - dargestellt in der SQL-Syntax von MS Access - ableiten lässt:
Abfrage: 11 Position tracking
SELECT [10 Transactions].TransactionNo, [10 Transactions].Date, [10 Transactions].Operation, [10 Transactions].Quantity, [10 Transactions].Title, [10 Transactions].Currency, [10 Transactions].UnitPrice, IIf([10 Transactions]![Operation]="Buy",[10 Transactions]![Quantity]*[10 Transactions]![UnitPrice]*-1,[10 Transactions]![Quantity]*[10 Transactions]![UnitPrice]) AS [Market Value], [10 Transactions].Commission, IIf([10 Transactions]![Operation]="Dividend",[10 Transactions]![UnitPrice],[Market Value]+[10 Transactions]![Commission]) AS Total, [10 Transactions].ExchangeRate, IIf(IsNull([10 Transactions]![ExchangeRate]),[Total],[Total]*[10 Transactions]![ExchangeRate]) AS [Total CHF], IIf([10 Transactions]![Operation]="Buy",[Quantity],IIf([10 Transactions]![Operation]="Sale",[Quantity]*-1,0)) AS [Adjusted Quantity], CInt(DSum("[Adjusted Quantity]","11 Position tracking","[Date]*1<=" & [Date]*1)) AS [Total Units], IIf([10 Transactions]![Operation]="Buy",[Total CHF]*-1,IIf([10 Transactions]![Operation]="Sale",[Quantity]*DLast("[ø-Unit Cost]","11 Position tracking","[Date]*1<" & [Date]*1)*-1,0)) AS [Adjusted Total CHF], CCur(DSum("[Adjusted Total CHF]","11 Position tracking","[Date]*1<=" & [Date]*1)) AS [Total Cost], IIf([Total Units]=0,0,[Total Cost]/[Total Units]) AS [ø-Unit Cost], IIf([10 Transactions]![Operation]="Sale",[Total CHF]*-1+[Quantity]*DLast("[ø-Unit Cost]","11 Position tracking","[Date]*1<" & [Date]*1),0) AS [Real P/L], 0 AS [Unreal P/L], IIf([10 Transactions]![Operation]="Dividend",[Total CHF]*-1,0) AS Dividend FROM [10 Transactions] ORDER BY [10 Transactions].Date
Wenn in diesem Beispiel noch Formelwiederholungen zum Tragen kommen, dann befürchte ich, den Überblick zu verlieren.
Aus diesem Grund wäre ich sehr interessiert daran zu wissen, wie man in Base bzw. der dazugehörigen SQL-Syntax mit Bezug auf einen Alias weiterrechnen könnte. Möglicherweise geht das irgendwie mit der UPDATE-, INSERT- oder SET-Funktion oder mit einem Umweg über Tabellenansichten (auch View oder Sicht genannt), da man diese auch mit SQL definieren kann.
Mein einfaches Beispiel sähe dann so aus:
1) casewhen(Tarifgehalt<=100000,Tarifgehalt+Zulage1,Tarifgehalt+Zulage2) as Bruttogehalt
2) Bruttogehalt*Sozialzuschlag as Gehalt
In MS-Access ist das simpel zu realisieren, man gibt einfach in der gleichen Abfrage den Alias ein und schon wird das neue Feld berechnet.
Hast Du eine Idee, wie man das in Base machen könnte?
Danke und Gruss
rso
Ja, das könnte ich so machen; aber Du gibst mir recht, das ist nicht die "elegante" Methode. Bei diesem kleinen Beispiel macht es zwar tatsächlich keinen Unterschied, aber wenn die Bedingung umfangreicher ist, dann hat man aufgrund der Formelwiederholung eine rechte Menge redundanten Code, was sich nebst der Performance auch auf die Übersichtlichkeit (wegen Wartung und Weiterentwicklung) auswirkt.
Mein aufgeführtes Beispiel ist nämlich nur eine extrem vereinfachte Problemstellung zum Erlernen, wie man diese in SQL grundsätzlich lösen kann. Tatsächlich kommen diese Problemlösungen nachher in viel komplexeren Problemstellungen zum Tragen, wie sich aus nachfolgendem Formelbeispiel - dargestellt in der SQL-Syntax von MS Access - ableiten lässt:
Abfrage: 11 Position tracking
SELECT [10 Transactions].TransactionNo, [10 Transactions].Date, [10 Transactions].Operation, [10 Transactions].Quantity, [10 Transactions].Title, [10 Transactions].Currency, [10 Transactions].UnitPrice, IIf([10 Transactions]![Operation]="Buy",[10 Transactions]![Quantity]*[10 Transactions]![UnitPrice]*-1,[10 Transactions]![Quantity]*[10 Transactions]![UnitPrice]) AS [Market Value], [10 Transactions].Commission, IIf([10 Transactions]![Operation]="Dividend",[10 Transactions]![UnitPrice],[Market Value]+[10 Transactions]![Commission]) AS Total, [10 Transactions].ExchangeRate, IIf(IsNull([10 Transactions]![ExchangeRate]),[Total],[Total]*[10 Transactions]![ExchangeRate]) AS [Total CHF], IIf([10 Transactions]![Operation]="Buy",[Quantity],IIf([10 Transactions]![Operation]="Sale",[Quantity]*-1,0)) AS [Adjusted Quantity], CInt(DSum("[Adjusted Quantity]","11 Position tracking","[Date]*1<=" & [Date]*1)) AS [Total Units], IIf([10 Transactions]![Operation]="Buy",[Total CHF]*-1,IIf([10 Transactions]![Operation]="Sale",[Quantity]*DLast("[ø-Unit Cost]","11 Position tracking","[Date]*1<" & [Date]*1)*-1,0)) AS [Adjusted Total CHF], CCur(DSum("[Adjusted Total CHF]","11 Position tracking","[Date]*1<=" & [Date]*1)) AS [Total Cost], IIf([Total Units]=0,0,[Total Cost]/[Total Units]) AS [ø-Unit Cost], IIf([10 Transactions]![Operation]="Sale",[Total CHF]*-1+[Quantity]*DLast("[ø-Unit Cost]","11 Position tracking","[Date]*1<" & [Date]*1),0) AS [Real P/L], 0 AS [Unreal P/L], IIf([10 Transactions]![Operation]="Dividend",[Total CHF]*-1,0) AS Dividend FROM [10 Transactions] ORDER BY [10 Transactions].Date
Wenn in diesem Beispiel noch Formelwiederholungen zum Tragen kommen, dann befürchte ich, den Überblick zu verlieren.
Aus diesem Grund wäre ich sehr interessiert daran zu wissen, wie man in Base bzw. der dazugehörigen SQL-Syntax mit Bezug auf einen Alias weiterrechnen könnte. Möglicherweise geht das irgendwie mit der UPDATE-, INSERT- oder SET-Funktion oder mit einem Umweg über Tabellenansichten (auch View oder Sicht genannt), da man diese auch mit SQL definieren kann.
Mein einfaches Beispiel sähe dann so aus:
1) casewhen(Tarifgehalt<=100000,Tarifgehalt+Zulage1,Tarifgehalt+Zulage2) as Bruttogehalt
2) Bruttogehalt*Sozialzuschlag as Gehalt
In MS-Access ist das simpel zu realisieren, man gibt einfach in der gleichen Abfrage den Alias ein und schon wird das neue Feld berechnet.
Hast Du eine Idee, wie man das in Base machen könnte?
Danke und Gruss
rso
Hallo rso,
klar, ich gebe Dir Recht. Es ist schon galanter mit Aliasen zu rechnen anstatt die Berechnung wiederholt einzugeben.
Auch ist klar, daß dieses gerade bei umfangreichen Abfragen zu Lasten der Übersichtlichkeit geht.
Es mag sein, daß man hier mit Hilfe eines Views weiterkommt, in den Du das Konsrukt mit einbaust. Als Ergebnis hättest Du denn in Deiner virtuellen Tabelle eine Spalte namens 'Bruttogehalt', mit der Du beliebig weiterrechnen könntest. Es käme auf einen Versuch an...
Gruß Barlee
klar, ich gebe Dir Recht. Es ist schon galanter mit Aliasen zu rechnen anstatt die Berechnung wiederholt einzugeben.
Auch ist klar, daß dieses gerade bei umfangreichen Abfragen zu Lasten der Übersichtlichkeit geht.
Es mag sein, daß man hier mit Hilfe eines Views weiterkommt, in den Du das Konsrukt
Code: Alles auswählen
casewhen(Tarifgehalt<=100000,Tarifgehalt+Zulage1,Tarifgehalt+Zulage2)Gruß Barlee
Hallo BarleeBarlee hat geschrieben:Hallo rso,
Es mag sein, daß man hier mit Hilfe eines Views weiterkommt, in den Du das Konstruktmit einbaust. Als Ergebnis hättest Du denn in Deiner virtuellen Tabelle eine Spalte namens 'Bruttogehalt', mit der Du beliebig weiterrechnen könntest. Es käme auf einen Versuch an...Code: Alles auswählen
casewhen(Tarifgehalt<=100000,Tarifgehalt+Zulage1,Tarifgehalt+Zulage2)
Gruß Barlee
Ich habe es mit einer View probiert und es klappt tatsächlich. Die Erkenntnis ist also die, dass berechnete Datenfelder, mit denen man weiterrechnen will, auf diese Weise definiert werden müssen. Der Nachteil ist der, dass man die Formel in der View nicht angeben kann. Man sieht nur den Spaltennamen und die korrekte Berechnung, aber man sieht überhaupt nicht, wie die Berechnung zustande kommt. Wenn ich also diesen Weg gehe, heisst das, dass ich die Berechnungsformel in einem separaten File dokumentieren muss, und das finde ich schwerfällig. Mal sehen, ob ich doch noch einen direkten Weg - z.B. mit UPDATE, INSERT oder SET - über SQL finde.
Wenn Du dazu was finden solltest, würde mich dies freuen.
Gruss
rso