Hybride” Performancemessung

Der fol­gen­de Bei­trag beschreibt, wie mit der dar­ge­stell­ten Anwen­dung schnell und fle­xi­bel die Aus­füh­rungs­zei­ten von Berich­ten mit Hil­fe von Delta­Master erfasst und ana­ly­siert wer­den kön­nen. Im Fokus steht hier, die oft durch Anwen­der als gefühl­te Ver­schlech­te­rung der Per­for­mance“ beschrie­be­ne sub­jek­ti­ve Ein­schät­zung anhand von manu­el­len Mes­sun­gen mit Daten zu unter­füt­tern. Es wer­den all­ge­mei­ne Ein­fluss­fak­to­ren, das Mess­ver­fah­ren und die Ergeb­nis­dar­stel­lung beschrie­ben.

Zum Ende wird ein Aus­blick über den wei­te­ren Aus­bau der Anwen­dung und neue Anfor­de­run­gen hin­sicht­lich der Auto­ma­ti­sie­rung die­ses manu­el­len Ansat­zes dar­ge­stellt. wei­ter­le­sen…

Langzeitanalyse – Start

Die­ser Bei­trag zeigt einen Lösungs­an­satz, wie man schein­bar spo­ra­di­schem (Fehl-)Verhalten von MS SQL Ser­vern auf die Spur kom­men kann. Dazu wer­den SQL Ser­ver Daten­samm­ler beschrie­ben und deren tech­ni­sche Umset­zung sowie die Kon­fi­gu­ra­ti­on der Samm­lungs­um­ge­bung erläu­tert. Außer­dem wird der Ein­satz und der Nut­zen in Kun­den­pro­jek­ten auf­ge­zeigt. wei­ter­le­sen…

Disziplin – aber bitte automatisch

Wie kann unter Ver­wen­dung des Micro­soft SQL-Ser­vers ein kun­den­spe­zi­fi­sches Regel­werk zur Daten­bank­ent­wick­lung ein­ge­führt und auto­ma­ti­siert durch­ge­setzt wer­den? Die­ser Bei­trag zeigt einen Lösungs­an­satz mit Hil­fe von SQL Ser­ver DDL-Trig­gern, deren Funk­ti­ons­wei­se und tech­ni­sche Umset­zung anhand eines kon­kre­ten Pra­xis­bei­spiels. Es wer­den die Tech­nik, der Nut­zen und ein Code­bei­spiel dar­ge­stellt. Das dar­ge­stell­te Code­bei­spiel ist ein all­ge­mein­gül­ti­ger Vor­schlag, basie­rend auf der bis­her im Bis­santz Con­sul­ting geleb­ten Namens­ge­bung im Ent­wick­lungs­pro­zess von Kun­den­pro­jek­ten. wei­ter­le­sen…

Repräsentative Daten

Die meis­ten Anwen­dungs­sys­te­me – und somit auch unse­re Delta­Master-Welt – wer­den in einer Mehr­sys­tem­land­schaft betrie­ben. Typisch in aktu­el­len IT-Infra­struk­tu­ren sind 2- oder 3-Sys­tem­land­schaf­ten. In einer 2-Sys­tem­land­schaft spre­chen wir von einem Ent­wick­lungs­sys­tem (DEV) und einem Pro­duk­tiv­sys­tem (PROD). In einer 3-Sys­tem­land­schaft wird zusätz­lich noch ein Test­sys­tem (QS) für unter­schied­li­che Benut­zer­grup­pen und Test­sze­na­ri­en zwi­schen­ge­schal­tet. Grund­sätz­lich ist die Ver­wen­dung von sol­chen Mehr­sys­tem­land­schaf­ten drin­gend zu emp­feh­len. Nur so kön­nen not­wen­di­ge und gewünsch­te Ände­run­gen sepa­rat vom pro­duk­ti­ven Sys­tem ent­wi­ckelt, getes­tet und vom Kun­den fach­lich abge­nom­men wer­den.

Eine Mehr­sys­tem­land­schaft bedeu­tet aber auch einen Mehr­auf­wand wäh­rend der Ent­wick­lungs­zy­klen. Es muss ein Pro­zess defi­niert sein wie die Ent­wick­lun­gen von DEV zu PROD mög­lichst auto­ma­ti­siert über­tra­gen wer­den kön­nen. Außer­dem müs­sen in geeig­ne­ten Inter­val­len die pro­duk­ti­ven Daten vom PROD auf das DEV zurück­ge­spielt wer­den, um mög­lichst reprä­sen­ta­ti­ve Test­ergeb­nis­se bereits wäh­rend der Ent­wick­lung gewähr­leis­ten zu kön­nen. wei­ter­le­sen…

Back(upp)en mit Rezept

Ein regel­mä­ßi­ges Back­up der von uns bear­bei­te­ten Sys­te­me lässt einen meist ruhig schla­fen, kor­rekt? – Stimmt, wenn es denn ein Back­up gibt und man dar­auf ver­trau­en kann!

In den meis­ten Pro­jek­ten obliegt die Betriebs­be­reit­schaft von Ser­ver­sys­te­men der Ver­ant­wor­tung der IT-Abtei­lun­gen und das ist gut so. Es gibt regel­mä­ßi­ge War­tungs­plä­ne, gan­ze 19“-Racks voll mit Hard­ware sowie unter­schied­li­che Soft­ware­tools, um auto­ma­ti­siert und mög­lichst effi­zi­ent die wich­ti­gen und sen­si­blen Daten zu kopie­ren, auf Medi­en aus­zu­la­gern und damit vor Ver­lust zu schüt­zen.
Die ver­schie­de­nen Ver­fah­ren sind nicht Bestand­teil die­ses Bei­trags, es sei nur so viel gesagt: Je nach Schutz­be­darf und Daten­men­ge kann es kom­pli­ziert wer­den. Wei­ter­füh­ren­de Details und Hin­ter­grün­de fin­den sich zum Bei­spiel beim Bun­des­amt für Sicher­heit in der Infor­ma­ti­ons­tech­nik (kurz: BSI) unter Abschnitt B1.4 des IT-Grund­schutz­ka­ta­logs.

Was tun wir aber, wenn unser Busi­ness Intel­li­gence Pro­jekt von der Fach­ab­tei­lung an der IT vor­bei begon­nen und ein­ge­führt wird und unse­re Ser­ver eben nicht dem Luxus einer gere­gel­ten Daten­si­che­rung unter­lie­gen? Ein all­ge­mei­nes Rezept als Trumpf im Ärmel zu haben; das zei­ge ich auf den fol­gen­den Sei­ten. wei­ter­le­sen…

Sehen und gesehen werden

In die­sem Bei­trag möch­te ich mich einem Detail des oft behan­del­ten The­mas der OLAP-Berech­ti­gun­gen wid­men, der Berech­ti­gung von Kenn­zah­len.
Wir alle haben uns sicher­lich schon mit der Fra­ge beschäf­tigt, was sieht ein Benut­zer tat­säch­lich, nach­dem man sich bei der Rech­te­ver­ga­be auf der OLAP-Daten­bank aus­ge­tobt hat. Dazu stel­le ich einen klei­nen, aber fei­nen Trick vor.

Spricht man mit IT-Admi­nis­tra­to­ren, wei­se ich immer auf einen grund­le­gen­den Unter­schied zwi­schen Berech­ti­gun­gen von Micro­soft Ana­ly­sis Ser­vices (kurz: SSAS) und z. B. dem Datei­sys­tem einer Micro­soft Win­dows Sys­tem­um­ge­bung hin: die Berech­ti­gun­gen auf OLAP-Daten­ban­ken sind addi­tiv, nicht restrik­tiv!

Von Datei­en oder Ver­zeich­nis­sen ist man gewöhnt, dass wenn ein­mal einem Benut­zer ein belie­bi­ges Recht ent­zo­gen wur­de, dann bleibt die­se Restrik­ti­on erhal­ten, egal wor­über sonst einem viel­leicht ein höhe­res Recht ein­ge­räumt wird. Die­ser Grund­ge­dan­ke bie­tet einen recht guten Schutz gegen Fehl­kon­fi­gu­ra­ti­on und damit uner­wünsch­te Zugriffs­rech­te.

Bei Micro­soft Ana­ly­sis Ser­vices Daten­ban­ken gilt die­ser Grund­satz lei­der nicht, weder für nor­ma­le“ Dimen­si­ons­ele­men­te noch für die Berech­ti­gung von Kenn­zah­len. Ein­mal erlaubt = immer erlaubt; das ist die Devi­se!

Was es bei dem Ein­satz von Berech­ti­gun­gen auf Kenn­zah­len geson­dert zu beach­ten gilt, schau­en wir uns in der Demons­tra­ti­ons­da­ten­bank Chair“ an. wei­ter­le­sen…

Transparente Verschlüsselung

Als im Juni 2013 die ame­ri­ka­ni­sche Washing­ton Post und der bri­ti­sche Guar­di­an damit began­nen, gehei­me Doku­men­te eines ehe­ma­li­gen Mit­ar­bei­ters des ame­ri­ka­ni­schen Aus­lands­ge­heim­diens­tes NSA zu ver­öf­fent­li­chen, wur­de der Welt­öf­fent­lich­keit klar, wie trans­pa­rent schein­bar jeg­li­che Kom­mu­ni­ka­ti­on und damit auch die dadurch erho­be­nen Daten eines jeden von uns sind. Die dadurch neu­ent­fach­te Debat­te um den Daten­schutz schafft immer mehr Sen­si­bi­li­tät im Umgang mit unse­ren pri­va­ten Daten. Auch Unter­neh­men, allen vor­an das Finanz- und Ban­ken­we­sen, haben in den meis­ten Fäl­len fest­ge­schrie­be­ne Regeln, wie mit all­ge­mei­nen Geschäfts­da­ten umzu­ge­hen ist. In Deutsch­land wer­den die­se Regeln vom Bun­des­amt für Sicher­heit in der Infor­ma­ti­ons­tech­no­lo­gie (kurz: BSI) defi­niert und als soge­nann­ter IT-Grund­schutz ver­öf­fent­licht. Kern­zie­le sind dabei Ver­trau­lich­keit, Ver­füg­bar­keit, Inte­gri­tät und Iden­ti­tät sicher­zu­stel­len, um dadurch Gefah­ren und Risi­ken zu mini­mie­ren. Was bedeu­tet dies nun aber in Busi­ness-Intel­li­gence-Pro­jek­ten? Der fol­gen­de Arti­kel soll die poten­zi­el­len Gefah­ren­quel­len hin­sicht­lich der Ver­trau­lich­keit auf­zei­gen und im Detail die Mög­lich­keit zur Ver­schlüs­se­lung der rela­tio­na­len Daten­quel­le mit Hil­fe der soge­nann­ten trans­pa­ren­ten Daten­ver­schlüs­se­lung (kurz: TDE) des Micro­soft SQL Ser­vers auf­zei­gen. wei­ter­le­sen…

Hochrechnung²

Das The­ma Hoch­rech­nun­gen, ger­ne auch als Pro­gno­se bezeich­net, ist eine häu­fig gestell­te Anfor­de-rung an Unter­neh­mens­be­rich­te. Dabei ist die Defi­ni­ti­on der Pro­gno­se meist indi­vi­du­ell und stets den jewei­li­gen Gege­ben­hei­ten und Geschäfts­mo­del­len unter­wor­fen. Reicht es bei­spiels­wei­se aus, für den Rest des lau­fen­den Geschäfts­jah­res vor­han­de­ne Plan­wer­te als Ziel anzu­neh­men? Oder ist für die Betrach­tung eher der ent­spre­chen­de Vor­jah­res­wert von Inter­es­se und aus­sa­ge­kräf­ti­ger? Unter­liegt die Ent­wick­lung wie­der­keh­ren­den Sai­so­n­a­li­tä­ten? Das sind nur eini­ge Fra­ge­stel­lun­gen, die es bei der kun­den­in­di­vi­du­el­len Ent­wick­lung einer Hoch­rech­nung zu dis­ku­tie­ren und beach­ten gilt. Ein wei­te­res wich­ti­ges Detail ist die Fest­le­gung, ab wann sich der Berichts­emp­fän­ger daten­tech­nisch in der Ver­gan­gen­heit und wann in der Zukunft befin­det?

Einen ers­ten Ansatz lie­fern wir mit Delta­Master ab Ver­si­on 5.5.8 bereits aus, den Stan­dard­be­richt Way to Go“. Die­ser kann voll­stän­dig auto­ma­ti­siert mit Hil­fe des Start­as­sis­ten­ten auf (fast) jedem Daten­mo­dell erstellt wer­den, vor­han­de­ne Plan­wer­te vor­aus­ge­setzt. Aller­dings basiert die­se Form der Pro­gno­se auf der Fra­ge­stel­lung, was das Unter­neh­men im Ver­lauf des Jah­res errei­chen muss, um am Ende den Plan zu erfül­len.

Ich möch­te heu­te eini­ge Lösungs­an­sät­ze mit Hil­fe von Delta­Master und ein wenig MDX zei­gen, die es jedem Inter­es­sier­ten ermög­li­chen, die Aus­sa­ge der Hoch­rech­nung durch ein paar Stell­schrau­ben“ zu indi­vi­dua­li­sie­ren. Am Ende soll eine Hoch­rech­nung ent­ste­hen, die den Ent­schei­dern zu jeder Zeit sagt, wo das Unter­neh­men am Jah­res­en­de ste­hen wird. Viel Spaß beim Wei­ter­le­sen.
wei­ter­le­sen…

Hash & Co.

Heu­te möch­te ich mich ein­mal mit einer sehr nütz­li­chen T-SQL-Funk­ti­on namens CHECKSUM() beschäf­ti­gen. An einem Bei­spiel aus dem Daten­la­de­pro­zess soll gezeigt wer­den, wie die­ser durch die Ver­wen­dung von CHECKSUM() schnel­ler und ele­gan­ter gestal­tet wer­den kann.
Wir Model­lie­rer ken­nen aus unse­rer täg­li­chen Pra­xis eine häu­fig man­gel­haf­te Daten­qua­li­tät, egal in wel­cher Form die not­wen­di­gen Daten bereit­ge­stellt wer­den. Gera­de in Work­shop-Situa­tio­nen, in denen sehr schnell eine Viel­zahl an Kun­den­wün­schen imple­men­tiert wer­den muss, kön­nen wir nicht immer einen per­fek­ten ETL-Pro­zess erwar­ten. Geht es dann auch noch um The­men wie eine inkre­men­tel­le Daten­la­de-Logik bei gro­ßen Daten­vo­lu­mi­na, bei der die Roh­da­ten aber nicht per ein­deu­ti­gem Schlüs­sel gefun­den wer­den kön­nen, hilft man sich oft mit einer dif­fe­ren­zier­ten JOIN-Bedin­gung (X=X AND Y=Y AND Z=Z etc.). Das funk­tio­niert grund­sätz­lich auch sehr gut. Aller­dings kann dies die Abfra­ge­per­for­mance nega­tiv beein­flus­sen, und das gilt es zu ver­mei­den. wei­ter­le­sen…

Finde den Tag

In fast allen BI-Pro­jek­ten spielt die Zeit­di­men­si­on eine zen­tra­le und meist auch beson­de­re Rol­le. Man möch­te sein Unter­neh­men mit­tels ver­schie­dens­ter Zeit­ver­glei­che mes­sen, wie ist der aktu­el­le Stand, wo befin­det sich mein Geschäft im Ver­gleich zum Vor­jahr, wie war die Ent­wick­lung der letz­ten Mona­te? Dies sind nur eini­ge typi­sche Fra­gen, die ein Busi­ness Intel­li­gence (kurz: BI) Sys­tem beant­wor­ten kön­nen soll. Wir und Sie ken­nen das aus unse­rem täg­li­chen Geschäft zu genü­ge. Doch eini­ge Unter­neh­men leben“ sogar in einer eige­nen Zeit, meist begrün­det in einer ver­scho­be­nen“ Monats­ab­gren­zung aus dem Finanz­be­reich oder der Steue­rung des täg­li­chen Geschäfts. Typi­scher­wei­se bil­den wir so ein Raum-Zeit-Kon­ti­nu­um“ in einer eige­nen, kun­den­spe­zi­fi­schen Hier­ar­chie ab.
So gesche­hen in einem Pro­jekt, wel­ches mich zu die­sem Bei­trag bewo­gen hat. Da kam der Kun­de auf uns zu und sag­te, dass die Berich­te zur tages­ge­nau­en Umsatz­ana­ly­se nicht ganz kor­rekt sind, wir wür­den eine fal­sche Ver­gleichs­ba­sis für das Vor­jahr her­an­zie­hen. Natür­lich habe ich sofort wider­spro­chen, denn mit der Zeit ken­nen wir uns aus. Falsch“ ist in dem Zusam­men­hang auch nicht ganz kor­rekt, nicht gewünscht“ trifft es eher. Denn natür­lich hat das ent­spre­chen­de Zeit­ana­ly­seele­ment in der Hilfs­di­men­si­on Peri­oden­an­sicht“ das ein­ge­stell­te Datum ver­wen­det und genau die­ses im Vor­jahr gesucht und die Wer­te dar­ge­stellt. In der ech­ten“ Zeit völ­lig kor­rekt, aber gilt das auch betriebs­wirt­schaft­lich für das ope­ra­ti­ve Geschäft?
Ich stell­te mich der Fra­ge und kam schnell zu dem Ergeb­nis, der Kun­de hat Recht, ein rei­ner Ver­gleich des glei­chen Tages im Vor­jahr macht nicht wirk­lich Sinn, ich ver­glei­che einen Mon­tag mit dem Sonn­tag im Vor­jahr (kalen­da­risch das glei­che Datum im Vor­jahr). Nicht stim­mig, oder? wei­ter­le­sen…