Obie metryki wyliczane s\u0105 na podstawie wolumen\u00f3w bankowych dla r\u00f3\u017cnych produkt\u00f3w (hipoteki, po\u017cyczki, karty kredytowe,..), symulacji st\u00f3p procentowych oraz specyficznego czynnika dyskontuj\u0105cego dobranego do charakterystyki produktu. Wszystkie obliczenia wykonywane by\u0142y na podstawie wzor\u00f3w finansowych dostarczonych prze klienta i wymaga\u0142y du\u017cej dok\u0142adno\u015bci wynik\u00f3w (do 13 miejsc po prawej stronie separatora dziesi\u0119tnego). W bazie przechowywali\u015bmy bardzo du\u017ce liczby oraz bardzo ma\u0142e z du\u017c\u0105 precyzj\u0105 (skal\u0105), wi\u0119c musieli\u015bmy okre\u015bli\u0107 sp\u00f3jny typ danych dla wszystkich warto\u015bci. Niestety nie wiedzieli\u015bmy jakich warto\u015bci mo\u017cemy si\u0119 dok\u0142adnie spodziewa\u0107 dla wybranych kolumn, wi\u0119c musieli\u015bmy wybra\u0107 uniwersalny typ numeryczny, kt\u00f3ry pozwoli przechowywa\u0107 w tej samej kolumnie bardzo ma\u0142\u0105 i du\u017c\u0105 liczb\u0119 (0.6738230988 lub 238947783.21). Pad\u0142o na typ decimal(25,13) dla procesu NPV i decimal(38,10) dla procesu EaR, \u017ceby pokry\u0107 wszystkie przypadki i by\u0107 sp\u00f3jnym z centraln\u0105 DWH klient zarz\u0105dzan\u0105 na Oracle.<\/p>\n\n\n\n
I tutaj zaczynaj\u0105 si\u0119 problemy, poniewa\u017c SQL Server (w tym przypadku wersja 2012) nie jest dobry w obliczeniach i trzeba by\u0107 bardzo \u015bwiadomym, jak operacje mno\u017cenia \/ dzielenia wykonywane s\u0105 przez silnik bazodanowy, \u017ceby uchroni\u0107 si\u0119 przed utrat\u0105 precyzji danych (skali), co w konsekwencji doprowadza do du\u017cych przek\u0142ama\u0144 w finalnych wynikach.<\/p>\n\n\n\n
Ca\u0142\u0105 logik\u0119 mo\u017cna znale\u017a\u0107 na stronie Microsoft i radz\u0119 ka\u017cdemu dobrze si\u0119 zapozna\u0107 z tym artyku\u0142em, je\u017celi w Waszym projekcie dok\u0142adno\u015b\u0107 oblicze\u0144 jest kluczowa! Zacznijmy od prostego przyk\u0142adu.<\/p>\n\n\n\n Dostajemy wynik 0.000003 zamiast warto\u015bci jak w poni\u017cszym przyk\u0142adzie Excel.<\/p>\n\n\n\n Dlaczego SQL Server nie u\u0142atwia nam zadania i nie zadba o prawid\u0142ow\u0105 precyzj\u0119, skal\u0119 wynik\u00f3w dla typu decimal? Niestety je\u017celi dodajesz, odejmujesz, a w szczeg\u00f3lno\u015bci mno\u017cysz i dzielisz liczby decimal, musisz liczy\u0107 si\u0119 z tym, \u017ce SQL Server zwr\u00f3ci zaokr\u0105glony wynik lub wynik z inna precyzj\u0105 (p) i skal\u0105 (s) ni\u017c mog\u0142oby to wynika\u0107 z danych wej\u015bciowych.<\/p>\n\n\n\n W powy\u017cszym przypadku SQL Server wykonuje nast\u0119puj\u0105ce operacje, \u017ceby wykona\u0107 proste dzielenie dw\u00f3ch liczb decimal(p,s):<\/p>\n\n\n\n 1. Wyznacza liczb\u0119 cyfr dla precyzji wed\u0142ug wzoru: p1-s1+s2+max(6,s1+p2+1). W naszym przypadku mamy punkt (c), czyli dostajemy wynik decimal(38,6), czyli 0.000003<\/p>\n\n\n\n \u017beby to naprawi\u0107 musimy zmieni\u0107 typ danych decimal na bardziej dok\u0142adny dla tych dw\u00f3ch warto\u015bci.<\/p>\n\n\n\n Dobieranie prawid\u0142owej precyzji, skali dla decimal mo\u017ce by\u0107 kluczowe dla poprawno\u015bci wykonywanych oblicze\u0144 i dok\u0142adno\u015bci wynik\u00f3w. Co je\u017celi nie wiemy jakich warto\u015bci mo\u017cemy si\u0119 spodziewa\u0107 w kolumnach? U\u017cywanie typ\u00f3w przybli\u017conych w SQL Server jak float mo\u017ce dawa\u0107 bardzo nieprecyzyjne wyniki i jest odradzane w aplikacjach finansowych (szczeg\u00f3lnie, \u017ce warto\u015b\u0107 0 mo\u017ce by\u0107 przybli\u017cone bardzo ma\u0142\u0105 warto\u015bci\u0105 ). Inna opcja to napisa\u0107 w\u0142asny CLR do wykonywania precyzyjnych oblicze\u0144.<\/p>\n\n\n\n Drugi przyk\u0142ad demonstruje krok po\u015bredni liczenia \u201eforward rate\u201d w logice symulacji st\u00f3p procentowych. Wynik powinien by\u0107 bardzo dok\u0142adny i spodziewamy si\u0119 13 miejsc po separatorze dziesi\u0119tnym po wykonaniu oblicze\u0144:<\/p>\n\n\n\n Niestety wynik znowu zosta\u0142 zaokr\u0105glony do 6 miejsc po separatorze dziesi\u0119tnym i trudno powiedzie\u0107 jak zmodyfikowa\u0107 dzia\u0142anie, \u017ceby otrzyma\u0107 lepsz\u0105 dok\u0142adno\u015b\u0107 wyniku bez zmiany typu danych dla parametr\u00f3w wej\u015bciowych.<\/p>\n\n\n\n Dzia\u0142anie sk\u0142ada si\u0119 z dw\u00f3ch kalkulacji: Je\u017celi teraz pomno\u017cymy decimal(38,6) *decimal(38,24) to faktycznie dostaniemy typu decimal(38,6) jako wynik tego dzia\u0142ania zgodnie z logik\u0105 opisan\u0105 przez Microsoft. Zak\u0142adamy, \u017ce dok\u0142adno\u015b\u0107 dw\u00f3ch wynik\u00f3w po\u015brednich jest zadowalaj\u0105ca i chcemy finalny wynik mno\u017cenia dosta\u0107 jako decimal(25,13). Co robimy? Ano kombinujemy.<\/p>\n\n\n\n Rzucamy pierwsz\u0105 operacj\u0119 na typ decimal(25,13), \u017ceby zredukowa\u0107 typ decimal(38,6)<\/p>\n\n\n\n Wynik wygl\u0105da lepiej, ale to jeszcze nie jest dok\u0142adno\u015b\u0107 wyniku, o jak\u0105 nam chodzi.<\/p>\n\n\n\n Rzucamy drug\u0105 operacj\u0119 na typ decimal(25,13), \u017ceby zredukowa\u0107 typ decimal(38,24)<\/p>\n\n\n\n Finalnie wynik wygl\u0105da poprawnie i jest to dok\u0142adno\u015b\u0107, jak\u0105 mo\u017cemy dosta\u0107 w Excel wykonuj\u0105c podobn\u0105 operacj\u0119 (finanse zawsze por\u00f3wnuj\u0105 si\u0119 do wynik\u00f3w z Excel).<\/p>\n\n\n\n Czyli wygl\u0105da, \u017ce w tym wypadku decimal(25,13)*decimal(25,13) daje nam decimal(25,13) poniewa\u017c: Na koniec zagadka do rozwi\u0105zania.<\/p>\n\n\n\n Dlaczego result1 != result2 mimo, \u017ce jedyna r\u00f3\u017cnica w dw\u00f3ch dzia\u0142aniach to kolejno\u015b\u0107 wykonywania mno\u017cenia, kt\u00f3re teoretycznie nie powinno zmieni\u0107 wyniku.<\/p>\n\n\n\n
https:\/\/docs.microsoft.com\/en-us\/sql\/t-sql\/data-types\/precision-scale-and-length-transact-sql<\/a><\/p>\n\n\n\n![\"Pierwsze](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2018\/04\/1.png\")
<\/a><\/figure><\/div>\n\n\n\n![\"Drugie](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2018\/04\/2.png\")
<\/a><\/figure><\/div>\n\n\n\n
W naszym przypadku p=87
2. Wyznacza liczb\u0119 cyfr dla skali wed\u0142ug wzoru: max(6,s1+p2+1).
W naszym przypadku s = 47
3. Nast\u0119pnie wyznacza cz\u0119\u015b\u0107 ca\u0142kowit\u0105 wed\u0142ug wzoru: p-s
W naszym przypadku jest to 40
4. Nast\u0119pnie sprawdzane s\u0105 nast\u0119puj\u0105ce warunki w celu finalnego wyznaczenia precyzji i skali (jak mocno SQL Server musi uci\u0105\u0107 dok\u0142adno\u015b\u0107 wynik\u00f3w po separatorze dziesi\u0119tnym):
a. Je\u017celi cz\u0119\u015b\u0107 ca\u0142kowita jest < 32 to s=min(s,38\u2013(p-s)). Wynik mo\u017ce zosta\u0107 zaokr\u0105glony.
b. Je\u017celi s <= 6 i p > 32 nic nie robimy ze skal\u0105. Mo\u017cemy dosta\u0107 b\u0142\u0105d \u201eArithmetic overflow error converting numeric to data type numeric\u201d je\u017celi wynik dzia\u0142ania nie pasuje do decimal(38,s)
c. Je\u017celi s > 6 i p > 32 to skala jest redukowana do 6 (zaokr\u0105glona do 6 miejsc po separatorze dziesi\u0119tnym). Mo\u017cemy dosta\u0107 b\u0142\u0105d \u201eArithmetic overflow error converting numeric to data type numeric\u201d je\u017celi cz\u0119\u015b\u0107 ca\u0142kowita jest wi\u0119ksza od 32 znak\u00f3w.<\/p>\n\n\n\n![\"Trzecie](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2018\/04\/3.png\")
<\/a><\/figure><\/div>\n\n\n\n![\"Czwarte](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2018\/04\/4-1024x418.png\")
<\/a><\/figure><\/div>\n\n\n\n
(@value3+((@iterator-13)\/@const)*(@value1-@value3)) \u2013 zwracany typ decimal(38,6)
power((1\/(1+@value2\/@const1)),@sumIterator-3) \u2013 zwracany typ decimal(38,24)<\/p>\n\n\n\n![\"Pi\u0105te](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2018\/04\/5-1024x98-1.png\")
<\/a><\/figure><\/div>\n\n\n\n![\"Sz\u00f3ste](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2018\/04\/6-1024x95.png\")
<\/a><\/figure><\/div>\n\n\n\n
P=51, S=26, P-S=25, P-S<32 wi\u0119c S=min(26, 38 \u2013 (51-26)) = 13<\/p>\n\n\n\n
![\"Si\u00f3dme](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2018\/04\/7.png\")
<\/a><\/figure><\/div>\n\n\n\n