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­hilfe 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­tion 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­male Datums­wert gesucht.

Es wird dar­ge­stellt, wie diese 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­lich der Nut­zung wer­den Anwen­dungs­fälle 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

Preise wer­den häu­fig zur Berech­nung ande­rer Kenn­zah­len wie zum Bei­spiel dem Umsatz (Preis * Menge) ver­wen­det. Dabei wer­den die Preise oft in einer sepa­ra­ten Tabelle 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 neuer Daten­satz mit einem neuen Start­da­tum in die Tabelle geschrie­ben. Um bei einer Abfrage des Prei­ses für eine belie­bige Peri­ode den kor­rek­ten Preis aus der Tabelle gelie­fert zu bekom­men, kann nicht ein­fach auf das gewünschte Datum gefil­tert wer­den, da in der Preista­belle keine echte“ Peri­oden­in­for­ma­tion vor­han­den ist. Wel­che Schritte not­wen­dig sind, um den­noch den rich­ti­gen Preis zu fin­den, soll der fol­gende 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 Hilfe von SQL Ser­ver DDL-Trig­gern, deren Funk­ti­ons­weise 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­stellte 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 Rolle. Übli­cher­weise struk­tu­rie­ren wir diese Infor­ma­tion 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­lich. Hier und da kommt es aber vor, dass man Ter­tiale 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­tiale aller­dings benö­tigt es noch ein wenig Hand­ar­beit. wei­ter­le­sen…

Ein Ansatz zur Lösung des LNE-Dilemmas

Als Dilemma“ bezeich­nete kürz­lich ein Kunde 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 Dilemma 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­zesse zu star­ten, ken­nen wir schon die Funk­tio­na­li­tät der Custom App mit zusätz­li­chen Menü­punk­ten in Delta­Master.

Eine wei­tere 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­nale Ein­ga­be­an­wen­dung. wei­ter­le­sen…

Aufbau einer Bestandslogik

Mein Lieb­lings­per­so­nal­dienst­leis­ter möchte seine Bewer­ber aus­wer­ten. Bewer­ber kön­nen sich auf eine offene Stelle 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­lich nur den heu­ti­gen Stand eines Bewer­bers, ohne dass ersicht­lich 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, beschreibe ich in die­sem Bei­trag. wei­ter­le­sen…

Repräsentative Daten

Die meis­ten Anwen­dungs­sys­teme – und somit auch unsere 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­lich noch ein Test­sys­tem (QS) für unter­schied­li­che Benut­zer­grup­pen und Test­sze­na­rien 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­dige und gewünschte Ä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­tive Test­ergeb­nisse bereits wäh­rend der Ent­wick­lung gewähr­leis­ten zu kön­nen. wei­ter­le­sen…