Textprobe: Kapitel 3.5.3 Engines: Durch den Engine-Ansatz können Beladeprozesse auf Basis standardisierter, übergeordneter und revisionssicherer Strukturen durch den Fachbereich oder die IT-Abteilung verändert werden. Die Änderungen erfolgen dabei über revisionssicher abgelegte Steuerungsschnittstellen. Um den zentralen Entwicklungsprozess nicht zu beeinflussen, werden keine Änderungen am eigentlichen ETL-Code oder am Prozesssteuerungssystem vorgenommen. Wenn für die Entwicklung der Engine produktive Daten benötigt werden, dann erfolgt die Entwicklung innerhalb einer Sandbox. Andernfalls kann die Entwicklung der Engine auch in einer normalen Testumgebung erfolgen. Sandbox, Engine und Bypass sind zentrale Architekturkomponenten, die von der IT oder dem BICC bereitgestellt werden, wodurch ein Einsatz dieser Komponenten in einem dezentralen Ansatz nicht umsetzbar ist. 3.5.4 Bypässe In der Medizin werden operative Überbrückungen von Passage-Hindernissen als Bypass bezeichnet. Im Bereich der BI wird darunter eine kurzfristige Behebung eines Engpasses bei der Datenbereitstellung unter Überbrückung einer oder mehrerer Datenhaltungsebenen verstanden. Bypässe werden im Bereich der BI eingesetzt, um Daten zeitnah über einen modularen ETL-Prozess in das vollständig integrierte DWH zur Verfügung zu stellen, ohne dabei die bestehenden Infrastruktur zu beachten. Die Integration der Daten in die bestehende Infrastruktur kann dann rückwirkend in dem nächsten Release erfolgen. 3.5.5 In-Memory Nicht nur die Menge an Daten steigt, sondern auch die Anzahl der Nutzer, die auf diese Daten zugreifen. Somit steigen die Anzahl und die Dauer von Zugriffen auf die benötigten Daten. Die relationalen Datenbanken können die Anforderungen der Nutzer ab einer bestimmten Datenmenge nicht mehr zufriedenstellend erfüllen. Die In-Memory Datenbanken (IMDB) stellen eine Alternative zu den weit verbreiteten relationalen Datenbanken dar. Somit soll durch In-Memory-Technologien eine schnelle Verarbeitung von großen Datenmengen ermöglicht werden. Bisher gängige Lösungen bezüglich der Architektur und Herangehensweise erreichen allmählich ab einer bestimmten Menge von Daten ihre Grenzen, da es innerhalb dieser immer schwieriger wird, einen performanten Zugriff auf die Daten zu ermöglichen. Dieser Herausforderung, die durch In-Memory Computing gelöst werden sollen, kommen die sinkenden Preise für Hauptspeicher und die wachsende Anzahl an CPU-Kernen pro CPU sehr entgegen. Denn durch die sinkenden Preise für RAM werden diese Speicherbereiche immer größer. Bei den In-Memory Datenbanken werden die operativen Daten über Skripte direkt in den Hauptspeicher und nicht in ein zentrales DWH repliziert. Durch diese Art der Datenspeicherung sollen, auf Grund der höheren Zugriffsgeschwindigkeit und den effizienteren Zugriffsalgorithmen, schnellere Zugriffszeiten auf die Daten ermöglicht werden. Die Abfragewerte liegen bei RAM im Nanosekunden-Bereich, während diese bei herkömmlichen festplattenbasierten Datenbanken im Millisekunden-Bereich liegen. Durch die In-Memory-Technologie könnten somit die aufwändigen Modellierungen von Daten in Star- und Snowflake-Schemata überflüssig gemacht werden. Außerdem soll durch die performante Speicherung, Verarbeitung und Abfrage von großen Datenmengen durch den Einsatz von der In-Memory-Technologie viel Zeit und Aufwand eingespart werden, welche für die physikalische Modellierung der Daten benötigt werden würde. Durch diesen Zeitgewinn könnten sich die Anwender wieder fokussierter dem Business zuwenden. Grundsätzlich ist die effektive Nutzung der wachsenden Datenflut im gesellschaftlichen und wirtschaftlichen Umfeld wettbewerbsentscheidend. Die In-Memory-Technologie soll einen Ansatz zur Integration der Daten für die Beherrschung der großen Datenflut im Sinne von analytischen Möglichkeiten bieten. Die Einsatzmöglichkeiten von In-Memory-Computing sind sehr umfangreich. Im Bereich der B