Datentypänderung mit Systemtabellen

Wenn sich Daten­ty­pen im Vor­sys­tem, aus wel­chem Daten in Tabel­len einer SQL-Ser­ver-Daten­bank impor­tiert wer­den, ändern, ist oft gro­ßer manu­el­ler Auf­wand not­wen­dig um alle betrof­fe­nen Tabel­len und Spal­ten zu iden­ti­fi­zie­ren und anzu­pas­sen. In die­sem Bei­trag wird eine Lösung mit­hil­fe von Sys­tem­ta­bel­len vor­ge­schla­gen, die es ermög­licht, die Daten­ty­pän­de­rung auto­ma­ti­sch per Pro­ze­dur vor­zu­neh­men. 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…

Daten von vorgestern

Die­ser Bei­trag zeigt, wie dem Delta­Master-Anwen­der eine Mög­lich­keit zur Über­wa­chung der Daten­ak­tua­li­tät mit an die Hand gege­ben wer­den kann. Dabei wird in jeder Mea­su­re­group pro Wert­art der maxi­ma­le Datums­wert gesucht.

Es wird dar­ge­stellt, wie die­se Infor­ma­tio­nen über eine SQL-Pro­ze­dur ermit­telt, ans Daten­mo­dell ange­bun­den und anschlie­ßend vom Anwen­der genutzt wer­den kön­nen. Hin­sicht­li­ch der Nut­zung wer­den Anwen­dungs­fäl­le für das Delta­Master Ticker­por­tal, Delta­Master Ord­ner­ka­cheln und für Gra­fi­sche Tabel­len gezeigt. wei­ter­le­sen…

Preise mit Gültigkeitsdatum

Prei­se wer­den häu­fig zur Berech­nung ande­rer Kenn­zah­len wie zum Bei­spiel dem Umsatz (Preis * Men­ge) ver­wen­det. Dabei wer­den die Prei­se oft in einer sepa­ra­ten Tabel­le abge­legt, in der neben dem Preis und dem Arti­kel­be­zug auch das Datum, ab dem der Preis gül­tig ist, gespei­chert wird. Ändert sich ein Preis, wird ein neu­er Daten­satz mit einem neu­en Start­da­tum in die Tabel­le geschrie­ben. Um bei einer Abfra­ge des Prei­ses für eine belie­bi­ge Peri­ode den kor­rek­ten Preis aus der Tabel­le gelie­fert zu bekom­men, kann nicht ein­fach auf das gewünsch­te Datum gefil­tert wer­den, da in der Preista­bel­le kei­ne ech­te“ Peri­oden­in­for­ma­ti­on vor­han­den ist. Wel­che Schrit­te not­wen­dig sind, um den­no­ch den rich­ti­gen Preis zu fin­den, soll der fol­gen­de Bei­trag zei­gen. 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…

Quartal, Tertial, egal…

Bei der Model­lie­rung eines OLAP-Wür­fels spielt die Zeit eine gro­ße Rol­le. Übli­cher­wei­se struk­tu­rie­ren wir die­se Infor­ma­ti­on in einer Hier­ar­chie nach den Ebe­nen Jahr, Quar­tal, Monat und Tag. Auch die Ein­tei­lung in Kalen­der­wo­chen ist nicht unüb­li­ch. Hier und da kommt es aber vor, dass man Ter­tia­le abbil­den muss. Unser Model­lie­rungs­tool Delta­Master Mode­ler bringt zwei Drit­tel der oben genann­ten Mög­lich­kei­ten schon mit. Für die Ter­tia­le aller­dings benö­tigt es noch ein wenig Hand­ar­beit. wei­ter­le­sen…

Ein Ansatz zur Lösung des LNE-Dilemmas

Als Dilem­ma“ bezeich­ne­te kürz­li­ch ein Kun­de ein häu­fig auf­tre­ten­des Pro­blem beim Aggre­ga­ti­ons­typ Last­Non­Em­pty (LNE), der oft zur Abbil­dung von Bestands­lo­gi­ken ein­ge­setzt wird. Aus­weg­los, wie das Wort Dilem­ma nahe legt, ist die Pro­ble­ma­tik jedoch nicht, wie die­ser Bei­trag zei­gen wird. wei­ter­le­sen…

Relationale Eingabeanwendung als Alternative zur Custom App

Häu­fig müs­sen Daten in bestehen­den Model­len ange­passt oder ergänzt wer­den. Um neue Daten rela­tio­nal zu über­neh­men oder Hin­ter­grund­pro­zes­se zu star­ten, ken­nen wir schon die Funk­tio­na­li­tät der Cust­om App mit zusätz­li­chen Menü­punk­ten in Delta­Master.

Eine wei­te­re Mög­lich­keit, den Delta­Master-Benut­zern den manu­el­len Start von Pro­ze­du­ren kom­for­ta­bel über das Front­End ein­zu­rich­ten, bie­tet die rela­tio­na­le Ein­ga­be­an­wen­dung. wei­ter­le­sen…

Aufbau einer Bestandslogik

Mein Lieb­lings­per­so­nal­dienst­leis­ter möch­te sei­ne Bewer­ber aus­wer­ten. Bewer­ber kön­nen sich auf eine offe­ne Stel­le oder initia­tiv in einem Por­tal regis­trie­ren, wer­den dann von den Nie­der­las­sun­gen über­prüft – und bald mit Delta­Master von Mar­ke­ting, der Per­so­nal­ab­tei­lung, dem Ver­trieb und den Nie­der­las­sungs­lei­tern aus­ge­wer­tet. Aller­dings lie­fert das Vor­sys­tem täg­li­ch nur den heu­ti­gen Stand eines Bewer­bers, ohne dass ersicht­li­ch ist, ob ges­tern ein Wech­sel sei­ner Eigen­schaf­ten statt­ge­fun­den hat. Um Zeit­pe­ri­oden­ver­glei­che oder einen his­to­ri­schen Bestand aus­wer­ten zu kön­nen, müs­sen die Daten also erst­mal his­to­ri­siert wer­den. Wie ich das gemacht habe, beschrei­be ich in die­sem Bei­trag. 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. Typi­sch 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­li­ch 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­li­ch 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­li­ch 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…