Business Intelligence (BI)

Inhalt1.Architekturschichten31.1.Quellsystem31.2.ETL- Komponenten (Extract / Transform / Load)31.2.1.Staging (TXP_BI_Staging)31.2.2.Cleansing (TXP_BI_Cleansing)51.2.3.Metdata (TXP_BI_Metadata)51.3.Datawarehouse51.3.1.TXP_BI_Core51.3.2.TXP_BI_DM_SSAS51.4.Zugriffs-Schicht62.Voraussetzungen73.Erste Installation BI/DWH in Zielumgebung83.1.Dateien aus Repository laden83.2.Linked Server auf Zielumgebung einrichten83.3.SQL Skript der ETL - Schicht generieren und ausführen83.4.Datamart Datenbank, Tabellen und Views anlegen113.5.Berechtigungen auf neue DB vergeben123.6.Job zum Befüllen und Aktualisieren der BI- Tabellen erstellen und ausführen123.7.Fehler in der Job- Ausführung134.Neue Entität hinzufügen / Entität bearbeiten144.1.Skripte für Extracting, Transforming und Loading (ETL) anpassen144.1.1.Staging144.1.2.Entscheidung: Entität oder Transaktion?154.1.3.Entity154.1.4.Relations (Entity)164.1.5.EntityTransformations164.1.6.Transaction174.1.7.TransactionTransformations174.1.8.SQL Skript generieren und ausführen184.1.9.Berechtigungen auf neuen DB vergeben184.2.SSIS Paket anpassen184.2.1.Tasks für das Staging hinzufügen194.2.2.Task für Transforming und Loading hinzufügen204.3.BI Datamart Skripte anpassen und generieren214.4.DB Job ausführen224.5.OLAP Cube erstellen / anpassen225.Fehlerbehandlung / FAQ235.1.DB Job läuft nicht durch235.1.1.Keine Berechtigung auf TXP Datenbank235.1.2.SsasMaintain.exe konnte nicht ausgeführt werden236.Durchgeführte Änderungen247.Verbesserungsmöglichkeiten / Ideen25

Architekturschichten

Quellsystem

Die Datenbanken des TicketXperts bilden das Quellsystem.

ETL- Komponenten (Extract / Transform / Load)

Staging (TXP_BI_Staging)

Erstellung von Snapshot-Tabellen aus dem Quellsystem

· Kleinere Tabellen werden komplett übernommen z.B. Ticketstatus, …

· Bei größere Tabellen wird die Differenz seit letzten Aufbereitung ermittelt z.B. TicketStatusChanges

Die Staging- Tabellen halten eine Kopie der TXP-Daten bereit. Auf Basis dieser Datensätze erfolgt später dann die Transformation und Aufbereitung

Über Stored Procedures werden die Datensätze aus dem Quellsystem (TXP) in die Staging- Tabellen geladen. Für jede Entität gibt es eine eigene SP.

Ebenfalls in der Staging Datenbank befinden sich Tabellenwertfunktionen, die für den Transforming-Prozess herangezogen werden:

Cleansing (TXP_BI_Cleansing)

Aufgabe des Cleansing-Bereichs ist

· Transformation der Daten aus den Staging- Tabellen und Speicherung in den Cleansing-Tabellen, unter Verwendung der Tabellenwertfunktionen aus dem Staging Bereich

· Prüfung der Datensätze aus den Cleansing-Tabellen auf z.B. Doppelte Einträge. Der Zugriff auf die bereinigten Datensätze erfolgt über die „Valid Views“

· Hinzufügen des Singleton-Datensatzes und Speicherung als „Singleton Views“

· Auflösen der Fremdschlüssel (Surrogate key vs. Business key) auf Basis der „Singleton Views“ und Speicherung in „Lookup Views“

· Basierend auf den Lookup Views wird in den „Merge-Views“ unterschieden bzw. gekennzeichnet, ob der Datensatz hinzugefügt oder geupdated wird.

· Laden der Datensätze aus den MergeViews in die TXP_BI_Core- Datenbank. Hierbei wird bereits der jeweils definierte „Slowly Changing Dimension“ Typ angewandt und die vorhandenen Datensätze entsprechend geupdated und historisiert.

Metdata (TXP_BI_Metadata)

Speicherung von Meta-Daten wie z.B. Logeinträge des DB Jobs, Letzte Ausführungszeitpunkt, usw.

Datawarehouse TXP_BI_Core

Diese Datenbank enthält die transformierten, bereinigten und aufbereiteten Daten. Für jede Entität existiert eine Tabelle die Datensätze der jeweiligen Entität beinhaltet und eine Histo- Tabelle, die kennzeichnet wann welcher Datensatz gültig ist bzw. war.

Zusätzlich gibt es pro Entität 3 Views:

· All_: Alle Datensätze der Entität, inkl. Gültigkeitsinformation

· Current_All_: Alle aktuell gültigen Datensätze der Entität

· Current_:Alle nicht gelöschten, aktuelle gültigen Datensätze der Entität

TXP_BI_DM_SSAS

Die TXP_BI_DM_SSAS- Datenbank enthält selbst kaum Datensätze, sondern bedient sich über Views der TXP_BI_Core Datenbank. Im Prinzip gibt es zwei Arten von Views: Dimension- Views (Dim) und die Fact-Views (Dim)

Dimension-Views beinhalten alle nicht aggregierbaren Informationen wie z.B. der Name, Die Gültigkeit und die Beschreibung eines Projektes. Die Fact- View hingehen enthält die aggregierbaren Werte und sämtliche Fremdschlüssel.

Auf Basis dieser Views werden letztendlich die OLAP-Cubes erstellt.

Zugriffs-Schicht

Erstellte OLAP-Cubes und Datamarts zur weiteren Verwendung in verschiedenen Frontend-Tools wie z.B. Excel

Voraussetzungen

Visual Studio 2013 (Projektfiles sind auf 2013 erstellt)

· Extension T4Toolbox installieren

· Microsoft SQL Server Data Tools

SQL Server 2008 R2 (nicht höher, da wir rückwärtskompatibel entwickeln müssen)

· Database Engine

· Analysis Services

· Integration Services

· Development Tools (insbesondere Business Intelligence Development Studio)

Erste Installation BI/DWH in ZielumgebungDateien aus Repository laden

Repository: http://hg.isonet.ch/BIDWH/

Linked Server auf Zielumgebung einrichten

Um Zugriff auf die Quelldatenbanken zu haben wird auf dem SQL Server des Zielsystems ein Linked Server erstellt:

Dieser wird auch erstellt, wenn Quellsystem und Zielsystem auf dem gleicher Server liegen. Somit muss in den Generierten Skripten der DB-Server nicht geändert werden.

SQL Skript der ETL - Schicht generieren und ausführen

Das SQL Script der ETL- Schicht wird mit einem Tool generiert und sorgt dafür, dass die benötigten Daten aus den Quellsystem geladen und für die weitere Verwendung aufbereitet werden.

Das „Tool“ wurde mit dem T4 (https://t4toolbox.codeplex.com) Code Generator geschrieben (*.tt) und enthält eine Model.xml, die sämtliche Informationen über die zu verwenden TXP-Quelldatenbanken enthält.

Voraussetzung:

· T4 Toolbox Extension müssen installiert sein

· Falls noch nicht vorhanden:

· Visual Studio > Tools > Extensions and Updates

· Z.B. nach T4 suchen und installieren

· Neustart Visual Studio ist ggf. erforderlich

Anpassen der Model.xml:

1) TXP DWH Solution öffnen: \BIDWH\Source\TXP DWH\TXP DWH.sln

2) Speicherort für Data- und Logfile der neu zu erstellenden BI-Datenbanken anpassen

· Tag “Database” für TXP_BI_Metadata, TXP_BI_Core, TXP_BI_Cleansing, TXP_BI_Staging

· Attribute dataFilesDirectory und logFilesDirectory

3) Datenbankname der Quelldatenbanken für TXP, SM, (LVER)

· Tag „Source“

· Attribute „database“

Generieren des SQLs:

1. Main.tt aus dem Root öffnen und speichern, dadurch wird das SQL generiert

2. SQL-Datei ist unterhalb der Main.tt zu finden

Ausführen:

1. Inhalt der Main.sql in SQL Management Studio auf dem Zielsystem kopieren

2. direkt auf der Master-DB ausführen

Ergebnis:

Datamart Datenbank, Tabellen und Views anlegen

Die Datamart Datenbank wird später die Dim- und Fact- Tabellen (bzw. Sichten) beinhalten. Auf diesen Tabellen und Views wird letztendlich der OLAP-Cube aufgesetzt.

Im SQL Server des Zielsystems muss eine neue DB mit dem Namen „TXP_BI_DM_SSAS“ erstellt werden.

Anschließend die „TXP DM SSAS“ Solution öffnen (\BIDWH\Source\TXP DM SSAS\TXP DM SSAS.sln) und das Skript zum befüllen der Datenbank generieren/publishen:

· Rechtsklick auf das „TXP_BI_DM_SSAS“- Projekt Publish

· Edit „Target Database connection“ Auswählen der angelegten Datenbank als Target

· Zurück im „Publish Database“ Dialog auf „Load Values“ klicken, um die SQLCMD Variablen zu setzen

· Abschließend auf „Generate Script“ klicken, das SQL Skript wird generiert und öffnet sich.

· Im SQL Management Studio das Skript auf der neu erstellten DB im SQLCMD Mode ausführen

Berechtigungen auf neue DB vergeben

Damit später die Datenbanken durch einen Job befüllt werden kann, benötigt der NT SERVICE\SQLSERVERAGENT - Login folgende Berechtigungen:

a) Leserechte (db_datareader)auf die TXP-Datenbanken

b) Schreibrechte (db_owner) auf die neuen BI-Datenbanken

Laufen die SQL Server-, SQL Server Agent- und SQL Server Analysis Dienste unter verschiedenen Benutzern, dann müssen diese ggf. zusätzlich berechtigt werden.

Job zum Befüllen und Aktualisieren der BI- Tabellen erstellen und ausführen

Aufgaben

Der „TXP_BI_LOAD_DWH“ Datenbank Job hat zwei Aufgaben

a) Befüllen / Bereinigen / Aufbereiten der BI-Datenbanken aus dem Quellsystem

b) Deployment und Processing der OLAP-Cubes

c) Anlegen von Rollen, die die Ticketschema-Zugriffsrechte regeln (\Source\ TXP SSAS Maintain)

DB Job erstellen

Die Solution „TXP SSIS 2008R2“ öffnen (BIDWH\Source\TXP SSIS 2008R2\ TXP SSIS 2008R2.sln) und builden, damit im Bin-Verzeichnis des Projekts die „LoadDWH.dtsx“ erstellt wird.

· SQL Skript im SQL Management Studio öffnen (\BIDWH\Scripts\Setup\Create Job.sql)

· Variablen prüfen, ggf. anpassen

a. DTSX_Path

b. Domain

c. DB_Server_Name

d. OLAP_Server_Name

· SQL Skript im SQLCMD-Mode ausführen

DB Job ausführen

Durch Rechtsklick > Start Job at Step… kann der Job gestartet werden:

Laufen die SQL Server-, SQL Server Agent- und SQL Server Analysis Dienste unter verschiedenen Benutzern, dann müssen diese ggf. zusätzlich berechtigt und ggf. in die Rolle „Processing“ der TXP Datenbank auf dem Analysis Server aufgenommen werden:

·

Fehler in der Job- Ausführung

Schlägt der Job fehl, dann kann per Rechtsklick > „View History“ die Fehlermeldung eingesehen werden. Die häufigsten Fehlerquellen sind entweder falsche Berechtigungen oder inkonsistente Daten, die ein Processing des OLAP-Cubes verhindern.

Bei letzterem erscheint folgende Fehlermeldung:

Description: Server: Der aktuelle Vorgang wurde aufgrund eines Fehlers in einem anderen Vorgang in der Transaktion abgebrochen.

In diesem Fall konnten die OLAP-Cubes nicht korrekt verarbeitet werden. Da die eigentliche Ursache an dieser Stelle nicht erkennbar ist, müssen die OLAP-Cubes manuell deployed/processed werden:

· „\BIDWH\Source\TXP SSAS\TXP SSAS.sln” Solution öffnen

· Rechtsklick auf “TXP SSAS” und Deployment- Einstellungen anpassen

· Rechtsklick auf “TXP SSAS” und „Process“

Im Processing Progress kann die tatsächliche Fehlermeldung eingesehen werden. Oft enthalten die aufbereiteten BI-Tabellen Duplikate.

Um diesen Fehler zu müssen die Skripte zum Aufbereiten der Daten so angepasst werden, dass keine doppelten Datensätze mehr vorkommen oder die Daten selbst müssen bereinigt werden.

Neue Entität hinzufügen / Entität bearbeitenSkripte für Extracting, Transforming und Loading (ETL) anpassen

Die Skripte für ETL- Schicht müssen angepasst werden, um die neue bzw. die geänderte Entität korrekt zu laden und zu transformieren. Die Skripte werden mit einem Generator erzeugt der als Grundlage die Model.xml verwendet. Hier sind sämtliche Entitäten mit den dazugehörigen Tabellen, Spalten und Fremdschlüsseln definiert.

Um eine neue Entität zu erstellen oder anzupassen, muss Sie in der Model.xml definiert werden.

Dazu wird die Solution \BIDWH\Source\TXP DWH\TXP DWH.sln geöffnet.

Staging

Befindet sich die neue Entität in einer bisher noch nicht im BI-Modul verwendeten Datenbank, so muss zunächst ein neues Source– Tag der XML hinzugefügt werden, wie im Folgenden am Beispiel der LVER- Datenbank

Innerhalb des Source-Tags werden die sogenannten Staging-Bereiche definiert, aus denen letztendlich die Skripte zum Erstellen der Tabellen, Views und Funktion in der TXP_BI_Staging-Datenbank generiert werden.

Die Staging-Tabellen sind ein Abbild / Snapshot der eigentlichen TXP-Tabelle. In der Model.xml können sie auf zwei verschiedene Arten definiert werden:

a) Komplette Tabelle – ohne Angabe eines SQL z.B.:

b) Nur definierte Spalten / ggf. bereits gefiltert, wenn große Tabellen inkrementell geladen werden:

Die Lokalisierungen von Entitäten bilden hier einen Sonderfall. Aktuell, wird die Tabelle LokalizedProperties (TXP) oder LokalizedTexts (LVER) als eigene Entität betrachtet und alle deutschen und englischen Werte als eigene Spalte ausgegeben. Später werden diese dann beim Transforming der eigentlichen Entität durch JOINEN der jeweiligen Tabellen zugeordnet.

Entscheidung: Entität oder Transaktion?

Sehr große Tabellen mit sehr vielen Datensätzen wie z.B. TicketStatusChanges werden als Transaktionen in der Model.xml definiert und nicht als Entität.

Eine Transaktion ist es immer dann, wenn eine einzelne Betrachtung der Datensätze keinen Sinn ergibt, wie z.B. TicketStatusChanges. Die Betrachtung eines einzelnen Datensatzes ohne die Ticket oder Status Entität würde keinen Sinn ergeben.

Eine Verarbeitung als Entität wäre zwar möglich, allerdings bietet die Transaktion ein paar Möglichkeiten um Speicherplatz zu sparen.

Als Faustregel gilt: „Buchungen“ oder „Protokolle“ können als Transaktionen definiert werden.

Anzupassende Xml-Tags bei

a) Transaktionen

a. Transactions

b. TransactionTransformationen

b) Entitäten

c. Entities

d. Relations

e. EntityTransformations

Entity

Innerhalb des Model-Tags werden die Entitäten definiert:

Eine Entität enthält immer folgende Attribute:

name:Der Name der Entität

description:Beschreibung der Entität

skDbType:Typ des Surrogate Key (Ersatz key)

Der surrogate key ist der neue Primärschlüssel der Entität

bkDbType:Typ des Business Keys

Der Businesskey ist der eigentliche Primärschlüssel der Entität, so wie er auf dem Quellsystem vorkommt

singletonBkValue:Der Businesskey, der zum Singelton-Eintrag dieser Entität führt. Der Singleton-Eintrag ist eine Art Fallback. Falls eine Referenz auf diese Entität nicht mehr korrekt ist und somit nicht gefunden wird, wird der Singelton Eintrag anhand diesen Keys ermittelt. Der Singelton-einträge sind Einträge wie z.B. „Unbekannt“, „Unknown“ usw.

Innerhalb jeder Entität werden die einzelnen Attribute definiert, die sie mit sich bringt. Die Attribute müssen in den Staging-Tabellen als Spalten enthalten sein.

Die Entität-Attribute müssen folgende XML-Attribute beinhalten:

nameName des Attributs

dbTypeDatentyp in der Datenbank

scdTypeSlowly Changing Dimension Typ, beschreibt das Verhalten der Historisierung von Datensätzen. Erlaubte Werte sind hier "SCD1" oder "SCD2".

SCD1 Auf eine Historisierung wird verzichtet. Über den Primärschlüssel wird in der Dimensionstabelle nachgeschlagen, ob der PK des neuen Datensatzes bereits vorhanden ist. Ist dies der Fall, wird der entsprechende Satz mit den neuen Daten überschrieben. Ansonsten wird ein neuer Datensatz angefügt.

SCD2 Dimensionstabellen oder einzelne Attribute werden historisiert, wenn sie schon vorhanden sind.

descriptionBeschreibung des Attributs

singletonValueWert dieser Entität für den Singleton-Eintrag

Relations (Entity)

Relationen zwischen Entitäten werden im Relations- Tag definiert, indem die Quell-Entität und die Ziel-Entität angegeben werden. Über ein Präfix kann z.B. bei mehreren Relationen zu der gleichen Entität der Name gesteuert werden. Dieser Name muss später auch bei den Abfragen in den Transformations so verwendet werden: __BK

Attributbeschreibung:

originEntityAusgangs Entität

targetEntityReferenzierte Entität, so wie sie im Entity-Tag benannt wurde

prefixPräfix, um den Namen bei mehreren Relationen zu der gleichen Entität zu steuern

scdTypeTyp der Historisierung / Slowly Changing Dimension, SCD1 oder SCD2

descriptionBeschreibung der Relation

EntityTransformations

Hier werden die Skripte für die Transformationen für die jeweilige Ladestrategie (Komplett/Inkrementell/festes Zeitfenster) definiert. Die hier angegebenen Abfragen basieren auf den Staging-Tabellen z.B. die im Staging-Bereich definiert wurden. Der Name der Staging-Tabellen setzt sich folgendermaßen zusammen:

Stg__ Stg_LVER_Costcentres

Primarykeys werden in den Abfragen mit Entitätsname + „_BK“ (Businesskey) benannt.

Zusätzlich gibt es noch die 2 Systemspalten “ValidFrom_Overrride“ und „ValidTo_Override“. Bei der Inkrementellen Ladestrategie sind diese immer NULL, bei der Kompletten-Ladestrategie wird das ValidFrom-Datum auf das Minimum gesetzt. Fremdschlüssel müssen in den Abfragen den gleichen Namen bekommen, wie die vorher definierten Relationen z.B. ExecutorUser_Principal_BK (__BK)

Transaction

Die Transaktionen werden ähnlich definiert wie die Entitäten. Einziger Unterschied hier ist, dass man die Relationen innerhalb des Transaction-Tag angibt im Tag Granularity:

TransactionTransformations

Die Transformationen für Transaktionen funktionieren weitestgehend analog zu den Transformationen für Entitäten. Einzige Unterschiede sind:

· Primärschlüssel und Businesskeys (Fremdschlüssel, Relationen) werden in der Abfrage zuerst definiert.

· Es gibt nur eine Systemspalte: TxTimestamp, anhand dieser wird berechnet, ab welchen Zeitpunkt die Datensätze geladen werden müssen

SQL Skript generieren und ausführen

Nachdem die Model.xml erfolgreich angepasst wurde, wird das SQL Skript durch Speichern der Main.tt generiert und anschließend im SQL Management Studio ausgeführt.

Frage: wie behandeln wir Änderung an bereits laufenden BI-Lösungen z.B. wenn neue DB-Spalten hinzukommen? Das Skript bietet nur Möglichkeiten zum Initialen anlegen der Staging Objekte

Können diese einfach komplett gelöscht und wieder angelegt werden? Eigentlich schon, da dies ja nur Kopien der TXP-Datenbanken sind, oder?! Der Aufwand ist nur sehr große, wenn nur eine Spalte geändert werden muss.

Modulweise wäre evtl. besser.

Berechtigungen auf neuen DB vergeben

Damit später die Datenbanken durch einen Job befüllt werden kann, benötigt der NT SERVICE\SQLSERVERAGENT - Login folgende Berechtigungen:

a) Leserechte (db_datareader)auf die TXP-Datenbanken

b) Schreibrechte (db_owner) auf die neuen BI-Datenbanken

Laufen die SQL Server-, SQL Server Agent- und SQL Server Analysis Dienste unter verschiedenen Benutzern, dann müssen diese ggf. zusätzlich berechtigt werden.

SSIS Paket anpassen

Das SSIS Paket wird durch den DB Job periodisch ausgeführt und dient dazu, die Daten von TXP in die Staging- Tabellen zu laden, zu Transformieren und entsprechend für den OLAP Cube aufzubereiten.

Dazu werden die zuvor angelegt Functions und Views verwendet, die über den Generator erstellt wurden.

Damit die Datensätze unserer neuen Entität ebenfalls geladen und aufbereitet werden, muss das SSIS Paket angepasst werden: Solution \BIDWH\Source\TXP SSIS 2008R2\TXP SSIS 2008R2.sln öffnen

Tasks für das Staging hinzufügen

In der Staging- Sequenz des SSIS-Pakets, muss die neue Entität hinzugefügt werden:

· Toolbox > „Execute SQL Task“ auswählen und in die Sequenz ziehen

· Rechtsklick Edit

a. Name vergeben „Stage „ + Entität, plural z.B. „Stage Projects“

b. Connection: BI_Staging

c. SQL Statement: „EXEC Stage__”

z.B. EXEC Stage_LVER_Projects

Das Staging für sämtliche Entitäten kann parallel ausgeführten werden, da hier keine Abhängigkeiten berücksichtigt werden müssen. Die Daten werden hier lediglich aus den Quelldatenbanken gelesen.

Task für Transforming und Loading hinzufügen

Nachdem die Stagingtabellen befüllt wurden, müssen die Datensätze aufbereitet (Transfom) und bereitgestellt (Load) werden. Dazu muss pro Entität jeweils ein neuer „Execute SQL Task“ für das Transforming und für das Loading in die entsprechende Sequenz hinzugefügt werden:

Zu beachten ist, dass der Task für das Loading erst nach dem Transforming ausgeführt. Ebenfalls beachten muss man Relationen zu anderen Entitäten. Während das Transforming noch parallel verlaufen kann, darf das Loading einer Entität erst ausgeführt werden, wenn auch alle Verknüpften Entitäten erfolgreich geladen wurden. Z.B. Können Kostenstellen erst geladen werden, wenn zuvor die Projekte geladen worden sind

· Toolbox > „Execute SQL Task“ auswählen und in die Sequenz ziehen

· Rechtsklick Edit

a. Name vergeben „Load „ + Entität, plural z.B. „Load Projects“

b. Connection: BI_Cleansing

c. SQL Statement: „EXEC Load_” z.B. EXEC Load_Project

BI Datamart Skripte anpassen und generieren

Die TXP_BI_DM_SSAS- Datenbank beinhaltet über Views, die auf die TXP_BI_Core- Datenbank der ETL Schicht zugreifen, die aufbereiteten Daten (Dimensions und Facts). Diese werden letztendlich im OLAP-Cube verwendet.

Wenn eine Entität hinzugefügt oder geändert werden soll, dann müssen die Entsprechenden Views hier angepasst werden:

· Solution \BIDWH\Source\TXP DM SSAS\TXP DM SSAS.sln öffnen

· Entsprechende Views auswählen und ändern

· Platzhalter für die BI_CORE_DB verwenden

Bei komplett neuen Entitäten oder wenn sich die Datenstrukturen in der TXP_BI_Core- Datenbank geändert haben, dann müssen zunächst die Datenbank-Objekte (Tables, Views, StoredProcedure) in der Solution hinzugefügt bzw. aktualisiert werden.

Dazu kann man die „Schema Compare“ – Funktion verwenden, mit der man die Objekte in der Solution mit den tatsächlichen DB Objekten vergleichen und anschließend aktualisieren kann:

· Rechtsklick auf das TXP_BI_CORE Projekt (obere Projekt)

· Schema Compare

· Source und Target tauschen (Button in der Mitte), sodass TXP_BI_Core aus der Solution das Target wird

· Als Source die TXP_BI_Core aus dem SQL Server auswählen

· Vergleichen über „Compare“ Schaltfläche

· Projekt updaten über „Update“

Nachdem die Objekte aktualisiert und die Änderungen vorgenommen wurden, kann das SQL Skript publiziert/generiert werden:

· Rechtsklick TXP_BI_DM_SSAS (unteres Projekt)

· Publish…

· Target database connection editieren

· SQL CMDD variablen Laden

· Generate Script und anschließend im SQL Management Studio auf der TXP_BI_DM_SSAS Datenbank ausführen

Das generierte Skript enthält nur Änderungen, die noch nicht in der TXP_BI_DM_SSAS Datenbank vorgenommen wurden.

DB Job ausführen

Nachdem alle Skripte generiert und ausgeführt wurden und auch das SSIS Pakte aktualisiert wurde, muss nun der DB Job ausgeführt werden, der letztendlich dafür sorgt, dass die Datensätze geladen und Transformiert werden.

OLAP Cube erstellen / anpassen

Solution \BIDWH\Source\TXP SSAS\TXP SSAS.sln öffnen, um die Cubes zu bearbeiten

1. Data Source Views aktualisieren

a. Doppelklick auf DSV_DWH.dsv

b. Im neuen Fenster, oben links den Refresh-Button klicken

c. alle neuen Objekte werden geladen

2. Neue Objekte / Tabellen der Data Source View hinzufügen

d. In data source view „Add/Remove“ Tables

e. Hinzuzufügende Tabellen und Sichten auswählen und hinzufügen

3. Die gewünschten Änderungen am Cube vornehmen bzw. einen neuen Cube erstellen

Fehlerbehandlung / FAQDB Job läuft nicht durchKeine Berechtigung auf TXP Datenbank

Ursache: Dienste des SQL Servers, SQL Server Agent und Analysis Server werden unter verschiedenen Benutzern ausgeführt. Spezielle Rechtevergabe.

Lösung: Benutzer sollten db_owner der BI-Datenbanken sein und in der Rolle „Processing“ des Analysis Server aufgenommen werden.

SsasMaintain.exe konnte nicht ausgeführt werden

Ursache:

Der NT SERVICE\SQLSERVERAGENT hatte keine Berechtigung folgende Datei auszuführen: \BIDWH\Source\TXP SSIS 2008R2\SsasMaintain\SsasMaintain.exe

Lösung:

Berechtigungen auf Dateiebene?!

Durchgeführte Änderungen

SQLServerAgent automatisch als db_owner hinzugefügt

Processing – Rolle im SSAS automatisch angelegt

Fehler behoben: Doppelte Einträge in Tabelle TXP_BI_DM_SSAS.BaseDate, bei erneutem Ausführen der Skripte / Update der Tabellenstruktur (z.B. neue Spalten, Entitäten,…)

Fehler behoben: Fehler beim Processing wegen Duplikaten bei den ContractPriorityNames

Lsg: Keycolumn ist ObjectGuid der Priority, nicht der Name

Verbesserungsmöglichkeiten / Ideen

TXP_BI_DM_SSAS per Skript anlegen – siehe (3.4.)

Anpassen Model.xml über Tool / UI, ansonsten sehr hohe Fehlerquelle, schwierig zu beseitigen