Liebe Datenanalysten,
sicher haben Sie solche Dateien auch schon per E-Mail erhalten oder auf dem Server gefunden: Dateien, denen die verfrühte Hoffnung des Erstellers, sich bald etwas anderem widmen zu können, schon am Dateinamen anzusehen ist – an Zusätzen wie „final v2“ und Ähnlichem. So praktisch es ist, Arbeitsergebnisse in handlichen Dateien verpacken zu können: Dateien neigen dazu, sich unkoordiniert zu vervielfältigen und zu verändern. Dies lässt sich durchaus organisatorisch im Zaum halten. Wenn aber der Kreis derer, die damit arbeiten sollen, wächst, setzen viele DeltaMaster-Kunden auf eine technische Alternative: Anstatt Berichte in Form von Dateien zu verteilen, stellen sie diese mithilfe einer zentralen Datenbank zur Verfügung, dem sogenannten Repository. Darin existiert jede Anwendung nur einmal und es lässt sich genau steuern, wer wie damit arbeiten kann. Das macht das Repository zum Fundament der Informationsversorgung mit DeltaMaster, vor allem für größere, sogar unternehmensweite Lösungen. Eine Einführung haben wir in diesen clicks! für Sie zusammengestellt – und eine „v2“ davon wird es nicht geben.
Herzliche Grüße
Ihr Team von Bissantz & Company
Die Arbeitsergebnisse von DeltaMaster können auf zweierlei Weise gespeichert und den Anwendern zur Verfügung gestellt werden: in Dateien oder in Datenbanken.
Das ältere Speicherkonzept sind Dateien. Die meisten DeltaMaster-Anwender dürften schon einmal mit ihnen zu tun gehabt haben – den DAS-Dateien, in denen die Berichtsmappe mit ihren Berichten und Analysen gespeichert ist, mit allen Definitionen, Bezeichnungen, Einstellungen und vielem mehr.
Als Alternative zu Dateien können all diese Dinge in eine Datenbank gespeichert bzw. aus einer Datenbank geöffnet werden, dem sogenannten Repository. Das hat Vorteile vor allem dann, wenn eine größere Anzahl von Anwendern mit zentral bereitgestellten Anwendungen und Berichten versorgt werden soll.
Im Folgenden geben wir eine kleine Einführung in das Arbeiten mit dem Repository, besonders aus dem Blickwinkel der Berichtsempfänger, und wir vergleichen das Konzept mit der Speicherung in Dateien. Für die IT gehen wir kurz auf Systemvoraussetzungen und die Installation ein. Details sind einer separaten, ausführlichen Dokumentation zu entnehmen.
Begrifflichkeiten
Das Repository ist die zentrale Komponente zur datenbankgestützten Bereitstellung und Verwaltung von DeltaMaster-Anwendungen. Zugleich ist das Repository die Basis für die DeltaMaster-Weboption, das Add-in für Office sowie für DeltaMaster Gate. Die Bezeichnung „Repository“ stammt aus dem Jargon der Informatik. Gemeint ist damit eine „spezielle Datenbank zur systematischen Ablage von Modellen und deren Bestandteilen“, wie es Gablers Wirtschaftslexikon beschreibt. Es handelt sich also um eine eigenständige Verwaltungsdatenbank, unabhängig von jenen, in denen die Analysedaten gespeichert sind. Statt betriebswirtschaftlicher Merkmale und Kennzahlen speichert das Repository DeltaMaster-Anwendungen – die gleichen Informationen, die auch in einer DAS-Datei stecken, nur eben in einer Datenbank. Zusätzlich sind im Repository Informationen zur Organisation desselben hinterlegt, zum Beispiel Berechtigungen.
Genau genommen, besteht das Repository aus zwei Komponenten: einer relationalen Datenbank, in der die Anwendungen, Berechtigungen, Rollen usw. gespeichert werden, sowie einem Windows-Dienst („DeltaMaster Service“), über den DeltaMaster auf die Repository-Datenbank zugreift. Für die Ausführungen in diesen clicks! kommt es darauf nicht weiter an; mit „Repository“ meinen wir hier Dienst und Datenbank gemeinsam. Zum interaktiven Verwalten der Objekte im Repository ist eine weitere Komponente vorgesehen, das „Repository-GUI“.
Die zu speichernden Arbeitsergebnisse nennen wir in DeltaMaster 5 „Analysesitzung“, deren Abbild in einer Datei „Analysedatei“ (die bekannten DAS- oder DM2GO-Dateien), das Pendant in der Datenbank „Anwendung“. In DeltaMaster 6 haben wir die Begriffe vereinheitlicht: Wir sprechen immer von einer „Anwendung“, unabhängig davon, ob diese als Datei oder in einem Repository gespeichert ist.
Anwendungen öffnen und nutzen
Das Öffnen von Anwendungen aus einem Repository ist einfach: Im Portal von DeltaMaster werden alle bekannten Repositories in einem eigenen Abschnitt aufgeführt (siehe Abbildung auf der vorigen Seite), jeweils mit einer Liste der zugehörigen Anwendungen. Falls im Portal der Abschnitt mit den Anwendungen im Repository nicht angezeigt wird, ist für diese DeltaMaster-Installation bzw. für den aktuellen Benutzer der Zugriff aufs Repository noch nicht eingerichtet (mehr zur Einrichtung: siehe unten).
Die Liste der Anwendungen ruft DeltaMaster vom jeweiligen Repository ab, wo sie zentral von den Berichtsredakteuren gepflegt wird. Dabei wird stets berücksichtigt, welcher Benutzer am System angemeldet ist: Im Portal sind nur diejenigen Anwendungen zu sehen, auf die der Benutzer Zugriff hat. Im Kontextmenü eines Repository lässt sich die Liste der Anwendungen aktualisieren. Das ist etwa dann praktisch, wenn während der Arbeit mit DeltaMaster weitere Anwendungen freigeschaltet wurden: Diese erscheinen dann im Portal, ohne DeltaMaster neu zu starten.
Diese Art, auf Anwendungen zuzugreifen, ist für alle Beteiligten eine große Erleichterung im Vergleich zur Arbeit mit Dateien: Berichtsempfängern bleibt das Suchen nach Dateien (und das Rätseln, welche Version die richtige ist) erspart. Stattdessen wählen sie aus einem zentral gepflegten Verzeichnis unter den genau vordefinierten Anwendungen aus. Berichtsredakteure müssen sich nicht mehr um die Verteilung von Anwendungen kümmern – im Repository stehen diese unmittelbar allen befugten Anwendern in derselben Version zur Verfügung. Damit sind auch Änderungen an Berichten sofort für alle Anwender wirksam und Berichte lassen sich sogar ganz aus dem Verkehr ziehen.
Einmal geöffnet, sieht die Anwendung so aus und verhält sich so, wie man es von Analysesitzungen aus Dateien kennt. Der Umgang mit Berichten und Analysen, die Funktionen und Optionen usw. sind unabhängig davon, woher man die Anwendung geöffnet hat. Lediglich beim Speichern gibt es Unterschiede: Laufwerke, Ordner und Dateinamen gibt es im Repository nicht; umgekehrt verfügt das Repository über Mechanismen, die es für Dateien nicht gibt, etwa Regeln und Rechte, um zu steuern, wer welche Objekte speichern darf.
Anwendungen ändern und speichern
Als Berichtsempfänger öffnet man eine Anwendung in aller Regel nur zum Lesen – unabhängig davon, ob man den Modus Reader, Viewer, Pivotizer, Analyzer oder Miner nutzt. Von diesen Modi hängt ab, welche Interaktions- und Veränderungsmöglichkeiten es innerhalb der Anwendung gibt. Ob man jedoch ins Repository speichern kann, hängt davon ab, ob die Anwendung zum Lesen oder auch zum Schreiben geöffnet wurde.
Um Änderungen speichern zu können, muss die Anwendung per Optionsdialog geöffnet werden (Kontextmenü der Anwendung im Portal).
Im Optionsdialog wählen Sie aus, dass Sie die Anwendung für exklusiven Schreibzugriff öffnen möchten. Diese Option dient dem Schutz der Anwendungen im Repository: Sie koordiniert die Bearbeitung, indem sie verhindert, dass mehrere berechtigte Anwender parallel an denselben Objekten arbeiten und ihre Ergebnisse gegenseitig überschreiben.
Daher wird der Schreibzugriff immer nur einem Anwender gewährt. Währenddessen können andere Anwender ohne Weiteres auf die Anwendung zugreifen, aber nur lesend. Der exklusive Schreibzugriff ist beim Öffnen der Anwendung anzumelden und kann nicht nachträglich reklamiert werden.
Die Befehle zum Speichern ins Repository sind wie jene für Dateien im Menü Datei eingeordnet. Anwendungen, die bereits aus dem Repository geöffnet wurden, können Sie mit der gewohnten Tastenkombination Strg+S dorthin zurückspeichern – hier ist praktisch kein Unterschied zu Dateien zu spüren.
Wenn Sie eine Anwendung zum ersten Mal ins Repository speichern (zum Beispiel, weil es sich um eine ganz neue Anwendung handelt oder weil Sie eine bestehende Analysedatei über das Repository veröffentlichen möchten), fragt DeltaMaster nach einigen dazu nötigen Angaben. Ganz oben im Dialog ist auszuwählen, in welches Repository die Anwendung geschrieben werden soll (siehe auch DeltaMaster deltas! 5.6.0, Punkt 6). Davon leiten sich die Verbindungseinstellungen ab. Die FileID wird als eindeutige Kennung der Anwendung verwendet; bei einer neuen Anwendung lassen Sie sie am besten automatisch bestimmen. Weitere Hinweise zur ID finden Sie im Handbuch der DeltaMaster-Weboption. Der Name der Anwendung wird überall dort angezeigt, wo man auf Repositories zugreifen kann. Mit dem Repository-GUI kann er jederzeit geändert und um eine Beschreibung ergänzt werden.
Berechtigungen verwalten
Eine besonders interessante Funktion des Repository ist, dass Berechtigungen für Anwendungen und sogar für einzelne Berichte und Ordner der Berichtsmappe vergeben werden können. Dadurch ist es möglich, bestimmten Benutzern bzw. den Rollen, in denen sie zusammengefasst sind, Zugriff auf ausgewählte Berichte und Ordner zu gewähren oder zu verweigern. Somit kann ein und dieselbe Anwendung mal mehr, mal weniger umfangreich erscheinen, je nachdem, mit welchen Rechten man sie öffnet.
Die Verwaltung der Berechtigungen ist auf zwei Komponenten verteilt und berücksichtigt damit die vorherrschende Aufgabenteilung zwischen der IT und der Fachabteilung.
Mit dem Repository-GUI stellt man ein, welche Benutzer auf welche Anwendungen überhaupt zugreifen dürfen. Auch die Zusammenfassung von Benutzern zu Rollen ist hier zu definieren.
Direkt in DeltaMaster wird gepflegt, auf welche Ordner und Berichte die Benutzer in einer Rolle innerhalb einer Anwendung zugreifen dürfen (Ordnerberechtigungen bzw. Berichtsberechtigungen in den entsprechenden Kontextmenüs in der Berichtsmappe). Darüber hinaus lassen sich auch Sitzungsberechtigungen (Menü Datei) sowie Berichtsmappenberechtigungen (Kontextmenü oder Menü Ich möchte in der Berichtsmappe) einstellen.
Ausführliche Hinweise zur Verwaltung von Anwendungen und Rollen mit dem Repository-GUI finden Sie im Handbuch zur DeltaMaster-Weboption, zu Berichts- und Ordnerberechtigungen in den DeltaMaster deltas! 5.4.9, Punkt 20.
Zugriff aufs Repository einrichten
Damit DeltaMaster auf ein oder mehrere Repositories zugreifen kann, werden deren „Koordinaten“ benötigt – im Wesentlichen: die Namen oder IP-Adressen der Server, die einen Repository-Dienst anbieten. Diese Angaben entnimmt DeltaMaster der Windows-Registrierung. Dorthin können sie auf zweierlei Weise gelangen: Zum einen lassen sie sich automatisch von zentraler Stelle einspielen, zum Beispiel von Systemadministratoren bzw. der IT. Auf diese Weise können Arbeitsplatzrechner so vorbereitet werden, dass alle Repositories bereits bekannt sind und ohne Zutun der Anwender zur Auswahl stehen.
Zum anderen sind die Anwender in der Lage, Repositories selbst einzutragen. Die dazu nötigen Angaben erfasst man mit einem DeltaMaster-Dialog, der in den Optionen (Menü Extras) über die Registerkarte Portal zu erreichen ist. Im oberen Teil des Dialogs sind die Repositories aufgeführt, die von der Systemadministration hinterlegt wurden. Diese können im Dialog weder geändert noch entfernt werden. Im unteren Teil lassen sich individuell weitere Repositories erfassen. Jedes Repository wacht darüber, dass einem Benutzer genau diejenigen Anwendungen angeboten werden, für die er Berechtigungen besitzt. Ein Repository in den Optionen einzutragen, bedeutet also noch nicht, dass man alle dort vorgehaltenen Anwendungen nutzen kann – diese müssen zuerst für den jeweiligen Benutzer freigeschaltet werden. Einzelheiten sind in den DeltaMaster deltas! 5.6.0, Punkt 8 beschrieben.
Repository und Berichtsserver
Anwendungen im Repository können als Quelle von Jobs im Berichtsserver verwendet werden. Außerdem ist es möglich, mit dem Berichtsserver Anwendungen automatisiert im Repository zu veröffentlichen. Dadurch können die Aktualisierungs- und Iterationsmöglichkeiten des Berichtsservers genutzt werden, um beispielsweise automatisiert eine Vielzahl von individualisierten Berichtsmappen vorzubereiten und über das Repository bereitzustellen.
Konzeptvergleich
DeltaMaster-Lösungen können nach beiden Varianten aufgebaut werden: dateibasiert oder datenbankgestützt mit dem Repository, und auch ein gemischter Betrieb ist möglich. Außerdem können Analysedateien jederzeit ins Repository überspielt sowie umgekehrt Anwendungen aus dem Repository jederzeit in Analysedateien gespeichert werden. Das lässt DeltaMaster-Nutzern die Freiheit, selbst zu entscheiden, ob sie eine neue Lösung von Anfang an auf dem Repository aufbauen wollen oder ob man erst umstellt, wenn die Anwenderzahlen steigen, die Berichtsnutzung stärker reglementiert und die Anwendungsverteilung rationalisiert werden müssen.
In der folgenden Tabelle haben wir die datei- und die datenbankgestützte Anwendungsbereitstellung in einigen Merkmalen gegenübergestellt.
| Analysedateien (DAS, DM2GO) | Repository | |
| Haupteinsatzgebiet | kleinere Lösungen mit überschaubarer Anzahl an Anwendern; individuelle, spontane Analysen; häufige Offline-Nutzung; Entwicklungsarbeitsplätze | größere Lösungen mit vielen Anwendern; Schwerpunkt: automatisierte Bereitstellung standardisierter Anwendungen für Analyse, Planung und Reporting; anwendungsspezifische Berechtigungskonzepte |
| Berichte zentral bereitstellen/verteilen | möglich | möglich |
| Berichte automatisiert mit dem Berichtsserver individualisieren | möglich | möglich |
| Berichte zentral ändern | möglich – Aktualität muss organisatorisch unterstützt werden (zum Beispiel durch Vereinbarung, dass nur mit bestimmten Dateien und nicht mit lokalen Kopien gearbeitet wird) | möglich – Aktualität ist technisch sichergestellt, lokale Kopien lassen sich unterbinden bzw. sind in der Voreinstellung erst gar nicht möglich |
| Berichte aus dem Verkehr ziehen | nicht möglich – wer eine Datei hat, kann enthaltene Berichte prinzipiell öffnen (es gelten aber stets die Berechtigungen der Analysedatenbanken) | möglich – löscht oder sperrt man Anwendungen oder Berichte, können sie ab sofort nicht mehr genutzt werden |
| Berichte offline nutzen (ohne Verbindung zur Analysedatenbank) | möglich – im Modus Reader mit Offline-DAS-Dateien, in allen Modi mit DM2GO-Dateien | möglich – Anwendungen können wie eine Offline-DAS-Datei im Repository gespeichert werden. Ohne Verbindung zum Repository: eingeschränkt möglich – lokale Kopien können als Datei gespeichert und automatisch mit dem Repository abgeglichen werden; diese Kopien verhalten sich dann wie normale Analysedateien, ohne die erweiterten Möglichkeiten des Repository. |
| Gleichzeitige Nutzung durch mehrere Anwender | möglich – unkritisch bei rein lesender Nutzung derselben Datei, beim parallelen Ändern und Speichern sind Konflikte nicht ausgeschlossen | möglich – Repository überwacht Schreibzugriffe und stellt sicher, dass es nicht zu Konflikten kommt |
| Berechtigungen | Fileserver: auf Datenbankebene sowie im Dateisystem; lokale Kopien: auf Datenbankebene | auf Datenbankebene; zusätzlich für Anwendungen, Ordner und Berichte steuerbar, getrennt nach Lesen, Ändern (Speichern) und Verwalten, Vererbungsregeln, eigene Benutzergruppen/Rollen; lokale Kopien lassen sich unterbinden |
| Nutzungsstatistiken | nicht möglich | möglich (DeltaMaster-Logbook), zum Beispiel, um Akzeptanz von Berichten zu prüfen oder Verwendungsnachweis von sensiblen Daten zu führen; Detaillierungsgrad der Protokollierung einstellbar |
| Parallele Nutzung durch Desktop-Client, Web-Client usw. | nicht möglich | möglich – Desktop-Client, Web-Client, Berichtsserver, Add-in für Office und DeltaMaster Gate können dieselben Anwendungen nutzen |
| Ad-hoc-Analyse lokaler Datenbestände, zum Beispiel in Microsoft Access oder Excel | möglich | nicht sinnvoll |
| Planungsanwendungen | möglich | möglich |
| Zusätzliche Systemkomponenten | keine – DeltaMaster-Installation auf dem Arbeitsplatzrechner genügt | Repository muss installiert und eingerichtet und dem Client bekanntgegeben werden |
| Lizenzierung | keine speziellen Lizenzen erforderlich | Repository muss lizenziert werden |
Unterm Strich ist festzuhalten: Beide Varianten haben ihre Vorzüge und man kann nicht sagen, dass die eine der anderen generell überlegen wäre. Vielmehr hängt es, wie so oft, von der jeweiligen Aufgabe ab, welches Konzept sich besser eignet.
Was die IT wissen muss
Installation und Ersteinrichtung des Repository sind typischerweise Aufgaben für die IT – nicht so sehr deshalb, weil diese Arbeiten besonders kompliziert wären, sondern vor allem, weil dafür besondere Berechtigungen erforderlich sind. Die Systemvoraussetzungen sind ausführlich in einer Anleitung zur Installation und Einrichtung dokumentiert. In Kurzform: Benötigt werden
- Microsoft SQL Server (Datenbankmodul) für die Repository-Datenbank und das
- Microsoft .NET 4 Framework für den Repository-Dienst.
Zur Installation benötigt man administrative Berechtigungen
- auf Betriebssystem-Ebene, um den Dienst zu installieren, sowie
- auf Datenbank-Ebene, um die Repository-Datenbank anzulegen und deren Berechtigungen einzurichten und um die Rechte an den Datenbanken mit den Anwendungsdaten anzupassen.
Sind die Systemvoraussetzungen erfüllt und alle Berechtigungen gegeben, gehen Installation und Ersteinrichtung schnell von der Hand – erfahrene Administratoren oder Anwendungsbetreuer sollten kaum länger als eine halbe Stunde dafür benötigen. Ein Setup-Programm (MSI) steht bereit (siehe DeltaMaster deltas! 5.6.0, Punkt 8). Ergänzend ist eine ausführliche Installationsanleitung in deutscher und englischer Sprache verfügbar; diese erläutert auch die Installation ohne Setup-Programm.
Die Repository-Datenbank und der zugehörige Dienst können auf demselben Server betrieben oder auf unterschiedliche Server verteilt werden. Zum Ausprobieren genügt schon ein normaler Arbeitsplatz-PC oder ein Laptop, auf dem auch DeltaMaster selbst (der Desktop-Client) betrieben werden kann. Die Anwendungen im Repository können in gleicher Form von allen DeltaMaster-Modulen mit Repository-Unterstützung parallel genutzt werden (Desktop-Client, Berichtsserver, Web-Client, Add-in für Office, DeltaMaster Gate). In Verbindung mit dem Desktop-Client liegt die Hauptrechenlast für die Berechnung und Anzeige der Berichte beim Desktop-Client, wie bei dateibasierter Nutzung.
Meist wird man auch eine zentrale Einstellung auf den Arbeitsplatzrechnern vornehmen, von denen aus die Anwender auf ein oder mehrere Repositories zugreifen sollen: Den Client-Installationen von DeltaMaster müssen die „Koordinaten“ der Repositories bekanntgegeben werden. Diese sucht DeltaMaster in der Windows-Registrierung (siehe DeltaMaster deltas! 5.6.0, Punkt 8), sodass sie sich über die üblichen Mechanismen leicht auf den Rechnern der Anwender einspielen lassen. Zusätzlich können benutzerspezifische Repositories mithilfe eines Dialogs in DeltaMaster eingetragen werden.
