BI_Einrichtung und Anpassung
Werbung
Business Intelligence (BI) Inhalt 1. Architekturschichten ....................................................................................................................... 3 1.1. Quellsystem ............................................................................................................................. 3 1.2. ETL- Komponenten (Extract / Transform / Load) .................................................................... 3 1.2.1. Staging (TXP_BI_Staging) ................................................................................................. 3 1.2.2. Cleansing (TXP_BI_Cleansing) ......................................................................................... 4 1.2.3. Metdata (TXP_BI_Metadata)........................................................................................... 5 1.3. Datawarehouse ....................................................................................................................... 5 1.3.1. TXP_BI_Core .................................................................................................................... 5 1.3.2. TXP_BI_DM_SSAS ............................................................................................................ 5 1.4. Zugriffs-Schicht ........................................................................................................................ 5 2. Voraussetzungen ............................................................................................................................. 6 3. Erste Installation BI/DWH in Zielumgebung .................................................................................... 7 4. 3.1. Dateien aus Repository laden.................................................................................................. 7 3.2. Linked Server auf Zielumgebung einrichten ............................................................................ 7 3.3. SQL Skript der ETL - Schicht generieren und ausführen .......................................................... 7 3.4. Datamart Datenbank, Tabellen und Views anlegen .............................................................. 10 3.5. Berechtigungen auf neue DB vergeben................................................................................. 11 3.6. Job zum Befüllen und Aktualisieren der BI- Tabellen erstellen und ausführen .................... 11 3.7. Fehler in der Job- Ausführung ............................................................................................... 12 Neue Entität hinzufügen / Entität bearbeiten............................................................................... 13 4.1. 4.1.1. Staging ........................................................................................................................... 13 4.1.2. Entscheidung: Entität oder Transaktion? ...................................................................... 14 4.1.3. Entity.............................................................................................................................. 14 4.1.4. Relations (Entity) ........................................................................................................... 15 4.1.5. EntityTransformations ................................................................................................... 15 4.1.6. Transaction .................................................................................................................... 16 4.1.7. TransactionTransformations ......................................................................................... 16 4.1.8. SQL Skript generieren und ausführen ........................................................................... 17 4.1.9. Berechtigungen auf neuen DB vergeben ...................................................................... 17 4.2. 5. Skripte für Extracting, Transforming und Loading (ETL) anpassen........................................ 13 SSIS Paket anpassen .............................................................................................................. 17 4.2.1. Tasks für das Staging hinzufügen .................................................................................. 18 4.2.2. Task für Transforming und Loading hinzufügen ............................................................ 19 4.3. BI Datamart Skripte anpassen und generieren ..................................................................... 20 4.4. DB Job ausführen................................................................................................................... 21 4.5. OLAP Cube erstellen / anpassen ........................................................................................... 21 Fehlerbehandlung / FAQ ............................................................................................................... 22 5.1. DB Job läuft nicht durch ........................................................................................................ 22 5.1.1. Keine Berechtigung auf TXP Datenbank ........................................................................ 22 5.1.2. SsasMaintain.exe konnte nicht ausgeführt werden ...................................................... 22 6. Durchgeführte Änderungen .......................................................................................................... 23 7. Verbesserungsmöglichkeiten / Ideen ............................................................................................ 25 1. Architekturschichten 1.1. Quellsystem Die Datenbanken des TicketXperts bilden das Quellsystem. 1.2. ETL- Komponenten (Extract / Transform / Load) 1.2.1. 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 TransformingProzess herangezogen werden: 1.2.2. Cleansing (TXP_BI_Cleansing) Aufgabe des Cleansing-Bereichs ist - Transformation der Daten aus den Staging- Tabellen und Speicherung in den CleansingTabellen, 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. 1.2.3. Metdata (TXP_BI_Metadata) Speicherung von Meta-Daten wie z.B. Logeinträge des DB Jobs, Letzte Ausführungszeitpunkt, usw. 1.3. Datawarehouse 1.3.1. 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_<Entität>: Alle Datensätze der Entität, inkl. Gültigkeitsinformation - Current_All_<Entity>: Alle aktuell gültigen Datensätze der Entität - Current_<Entity>: Alle nicht gelöschten, aktuelle gültigen Datensätze der Entität 1.3.2. 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<Entity>) und die Fact-Views (Dim<Entity>) 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. 1.4. Zugriffs-Schicht Erstellte OLAP-Cubes und Datamarts zur weiteren Verwendung in verschiedenen Frontend-Tools wie z.B. Excel 2. 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) 3. Erste Installation BI/DWH in Zielumgebung 3.1. Dateien aus Repository laden Repository: http://hg.isonet.ch/BIDWH/ 3.2. 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. 3.3. 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 TXPQuelldatenbanken enthält. Voraussetzung: - T4 Toolbox Extension müssen installiert sein Falls noch nicht vorhanden: o Visual Studio > Tools > Extensions and Updates o o 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: 3.4. 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 3.5. 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. 3.6. 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: - 3.7. 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. 4. Neue Entität hinzufügen / Entität bearbeiten 4.1. Skripte 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. 4.1.1. 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_StagingDatenbank 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. 4.1.2. 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 4.1.3. 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: name Name des Attributs dbType Datentyp in der Datenbank scdType Slowly 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. description Beschreibung des Attributs singletonValue Wert dieser Entität für den Singleton-Eintrag 4.1.4. 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: <Präfix>_<Zielentität>_BK Attributbeschreibung: originEntity targetEntity prefix scdType description Ausgangs Entität Referenzierte Entität, so wie sie im Entity-Tag benannt wurde Präfix, um den Namen bei mehreren Relationen zu der gleichen Entität zu steuern Typ der Historisierung / Slowly Changing Dimension, SCD1 oder SCD2 Beschreibung der Relation 4.1.5. 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_<SOURCE>_<Entity> 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 (<Relationpräfix>_<Zielentität>_BK) 4.1.6. 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: 4.1.7. 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 4.1.8. 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. 4.1.9. 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. 4.2. 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 4.2.1. 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_<Source>_<Entity plural>” 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. 4.2.2. 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_<Entity>” z.B. EXEC Load_Project 4.3. 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. 4.4. 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. 4.5. 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 5. Fehlerbehandlung / FAQ 5.1. DB Job läuft nicht durch 5.1.1. Keine 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. 5.1.2. 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?! 6. 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 7. 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
