Anforderungen an die Clientarchitektur für die Analysis Services-Entwicklung
Gilt für:
SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium
Microsoft SQL Server SQL Server Analysis Services unterstützt eine Thin-Client-Architektur. Die SQL Server Analysis Services Berechnungs-Engine ist vollständig serverbasiert, sodass alle Abfragen auf dem Server aufgelöst werden. Daher ist für jede Abfrage nur ein Roundtrip zwischen dem Client und dem Server erforderlich, was zu skalierbarer Leistung führt, wenn die Komplexität der Abfragen zunimmt.
Das native Protokoll für SQL Server Analysis Services ist XML for Analysis (XML/A). SQL Server Analysis Services bietet mehrere Datenzugriffsschnittstellen für Clientanwendungen, aber alle diese Komponenten kommunizieren mit einer instance von SQL Server Analysis Services mithilfe von XML for Analysis.
Mehrere verschiedene Anbieter werden mit SQL Server Analysis Services zur Unterstützung verschiedener Programmiersprachen bereitgestellt. Ein Anbieter kommuniziert mit einem SQL Server Analysis Services Server, indem er XML für die Analyse in SOAP-Paketen über TCP/IP oder über HTTP über Internetinformationsdienste (IIS) sendet und empfängt. Eine HTTP-Verbindung verwendet ein von IIS instanziiertes COM-Objekt, das als Datenpumpe bezeichnet wird und als Leitung für SQL Server Analysis Services Daten fungiert. Die im HTTP-Datenstrom enthaltenen zugrunde liegenden Daten werden von der Datapump nicht untersucht, und auch die zugrunde liegenden Datenstrukturen stehen für Code in der Datenbibliothek selbst nicht zur Verfügung.
Win32-Clientanwendungen können mithilfe von OLE DB für OLAP-Schnittstellen oder dem ADO-Objektmodell (Microsoft® ActiveX® Data Objects) für COM-Automatisierungssprachen (Component Object Model) eine Verbindung mit einem SQL Server Analysis Services Server herstellen, z. B. Microsoft Visual Basic®. Anwendungen, die mit .NET-Sprachen codiert sind, können mithilfe von ADOMD.NET eine Verbindung mit einem SQL Server Analysis Services Server herstellen.
Vorhandene Anwendungen können ohne Änderungen mit SQL Server Analysis Services kommunizieren, indem sie einfach einen der SQL Server Analysis Services Anbieter verwenden.
| Programmiersprache | Datenzugriffsschnittstelle |
|---|---|
| C++ | OLE DB für OLAP (OLE DB for OLAP) |
| Visual Basic 6 | ADO MD |
| .NET-Sprachen | ADO MD.NET |
| Alle Sprachen, die SOAP unterstützen | XML für Analysis |
SQL Server Analysis Services verfügt über eine Webarchitektur mit einer vollständig skalierbaren mittleren Ebene für die Bereitstellung durch kleine und große Organisationen. SQL Server Analysis Services bietet umfassende Unterstützung der mittleren Ebene für Webdienste. ASP-Anwendungen werden von OLE DB für OLAP und ADO MD unterstützt, ASP.NET-Anwendungen werden von ADOMD.NET unterstützt. Die mittlere Ebene ist für viele gleichzeitige Benutzern skalierbar, wie die folgende Abbildung veranschaulicht.
Sowohl Clientanwendungen als auch Anwendungen der mittleren Ebene können direkt mit SQL Server Analysis Services kommunizieren, ohne einen Anbieter zu verwenden. Clientanwendungen und Anwendungen der mittleren Ebene können XMLA in SOAP-Paketen über TCP/IP, HTTP oder HTTPS senden. Der Client kann mithilfe jeder Sprache codiert werden, die SOAP unterstützt. In diesem Fall kann die Kommunikation am einfachsten mithilfe von HTTP über Internetinformationsdienste verwaltet werden, obwohl eine direkte Verbindung zum Server mithilfe von TCP/IP ebenfalls codiert werden kann. Dies ist die schlankeste Clientlösung für SQL Server Analysis Services.
Analysis Services im tabellarischen oder SharePoint-Modus
In SQL Server 2017 kann der Server im VertiPaq-In-Memory-Analysemodul -Modus (VertiPaq) für tabellarische Datenbanken und Power Pivot-Arbeitsmappen gestartet werden, die auf einer SharePoint-Website veröffentlicht wurden.
Power Pivot für Excel und SQL Server Data Tools sind die einzigen Clientumgebungen, die zum Erstellen und Abfragen von In-Memory-Datenbanken unterstützt werden, die den SharePoint- bzw. tabellarischen Modus verwenden. Die eingebettete Power Pivot-Datenbank, die Sie mit den Excel- und Power Pivot-Tools erstellen, ist in der Excel-Arbeitsmappe enthalten und wird als Teil der Excel-.xlsx-Datei gespeichert.
Eine Power Pivot-Arbeitsmappe kann jedoch Daten verwenden, die in einem herkömmlichen Cube gespeichert sind, wenn Sie die Cubedaten in die Arbeitsmappe importieren. Sie können auch Daten aus einer anderen Power Pivot-Arbeitsmappe importieren, wenn sie auf einer SharePoint-Website veröffentlicht wurden.
Hinweis
Wenn Sie einen Cube als Datenquelle für eine Power Pivot-Arbeitsmappe verwenden, werden die Daten, die Sie aus dem Cube erhalten, als MDX-Abfrage definiert. die Daten werden jedoch als vereinfachte Momentaufnahme importiert. Sie können mit den Daten nicht interaktiv arbeiten oder die Daten vom Cube aktualisieren.
Schnittstellen für Den Power Pivot-Client
Power Pivot interagiert mit der Speicher-Engine für die In-Memory-Analyse-Engine von VertiPaq innerhalb der Arbeitsmappe, indem die für Analysis Services etablierten Schnittstellen und Sprachen verwendet werden: AMO und ADOMD.NET sowie MDX und XMLA. Innerhalb des Add-Ins werden Measures durch eine Formelsprache wie Excel, Data Analysis Expressions (DAX), ähnlich definiert. DAX-Ausdrücke werden innerhalb der XMLA-Meldungen eingebettet, die an den prozessinternen Server gesendet werden.
Anbieter
Für die Kommunikation zwischen Power Pivot und Excel wird der MSOLAP OLEDB-Anbieter (Version 11.0) verwendet. Innerhalb des MSOLAP-Anbieters gibt es vier verschiedene Module oder Transporte, das zum Senden von Meldungen zwischen Client und Server verwendet werden können.
TCP/IP Wird für normale Client-Server-Verbindungen verwendet.
HTTP Wird für HTTP-Verbindungen über den SSAS-Datenpumpendienst oder durch einen Aufruf der Komponente SharePoint Power Pivot Web Service (WS) verwendet.
INPROC Wird für Verbindungen mit der Prozess-Engine verwendet.
KANAL Reserviert für die Kommunikation mit dem Power Pivot-Systemdienst in der SharePoint-Farm.