Unter dem Video AnalyticsCreator 11 minutes short intro 26052020 ENG gibt es einen interessanten Kommentar:
At the point it's saying "Let's create a Macro" I stopped watching. If you call yourself DWH automation leader, it's not about creating code manually.
Und in einer späteren Antwort:
Lineage on column level as part of the design proccess is key to modern DW development. Here lineage is broken by using a peace of code. Sorry to say that this is coding automation not DWH automation. This is typical for many products in the market. 2-dimensional transformations on object level. Anyway the product looks good and contains also nice ideas. BR
Ich hatte mir nie besondere Gedanken über diesen Unterschied zwischen "Coding Automatisierung" und "DWH Automatisierung" gemacht. Warum ich den AC seit 2017 verwende, beschreibe ich hier: http://analyticscreator.aisberg.de/2020-04-26-warum-analyticscreator/
Im Hinblick auf "Automatisierung" war für mich entscheidend, wie der AC meine alltägliche Arbeit erleichtert, indem einige immer wieder nötige Prozesse vereinfacht werden. "AnalyticsCreator statt Junior-Consultant".
Oft kommt es vor, dass Zeichenketten-Spalten in Datenquellen länger werden und man dann diese Änderungen mühsam durch das DWH bringen muss. Auf die Historisierung von Datenquellen habe ich oft verzichtet, weil der manuelle Aufwand der Implementierung groß ist; mit dem AC sind das nur ein paar Mausklicks. Warum SSIS Pakete manuell erstellen, wenn der AC ein komplettes SSIS Projekt inklusive der Konfigurationsskripte erstellen kann, und zwar unter korrekter Berücksichtigung der notwendigen zeitlichen Abhängigkeiten?
Der entscheidende Grund, den AC einzusetzen, war allerdings nicht, dass diese Dinge automatisch passieren, sondern dass ich bestimmen konnte (und kann), wann und wie eine Automatisierung erfolgt und wann nicht. Dieses "wann nicht" fehlte mir in allen zuvor getesteten Werkzeugen in dem von mir gewünschten Ausmaß, und ich empfand mich dort zu sehr als Sklave der Software. Natürlich macht auch der AC Vorgaben: die erstellten SSIS Pakete folgen einem bestimmten Muster (und ich bitte seit Jahren vergeblich um die Implementierung von Projekt-Verbindungen), die Historisierung funktioniert, wie sie eben funktioniert (die 2-ms-Lücke kann man zumindest per Parameter abschalten). Doch es ist (fast) immer möglich, manuell einzugreifen, wenn etwas (noch) nicht automatisch oder standardisiert möglich ist oder die Automatisierung nicht meinen Vorstellungen entspricht. So waren anfangs UNION-Transformationen nur als manuelle Transformationen möglich.
Brenzlig wird es dann, wenn etwas technisch zwar mit dem SQL Server möglich ist, aber mit dem AC (noch) nicht realisiert werden kann. So aktuell die Unterstützung von m:n-Beziehungen in SSAS-Tabular Modellen, Graph-Datenbank Objekte, temporale Tabellen und einiges mehr, wofür ich schon diverse Feature Requests erstellt habe. Wenn das nicht implementiert wird und es keinen Work-around mit Post-Deployment-Skripten gibt, dann kann das auch dazu führen, dass ich einigen Projekten den AC nicht einsetzen werde. Wobei ich zuvor auf jeden Fall nachfragen würde, ob man es implementieren könnte, statt einfach auf den AC zu verzichten. Bisher gab es immer eine kurzfristige Lösung. Andererseits würde ich nie den AC für die Erstellung multidimensionaler SSAS Modelle verwenden, weil mir dabei die Automatisierung durch den AC zu unflexibel ist. Und der Aufwand, diese Flexibilität zu implementieren, stände in keinem sinnvollen Verhältnis zum Nutzen. Bei den SSAS Tabular Modellen war mir die Verwendung des AC anfangs ebenfalls zu aufwendig. Allerdings wurde vor ein paar Monaten eine Schwelle überschritten, in welcher für mich die Vorteile der Automatisierung über den Nachteilen überwiegen. Wenn allerdings nicht kurzfristig die m:n Beziehungen unterstützt werden, die es ab SQL Server 2019 gibt, dann wird es kritisch. Auch einige andere kleine Feature Requests werden bisher ignoriert, so benötige ich für einen sinnvollen Drillthrough in Excel die Spalten in einer geordneten Reihenfolge. Meiner Meinung nach eine Kleinigkeit, die Spalten im XMLA Skript nicht nach ID, sondern alphabetisch zu sortieren.
Es besteht also auch beim AC eine Gefahr der ungewollten Sklavenschaft, und ich würde mich sehr freuen, wenn von meinen mehreren Hunderten Feature-Requests im Bugtracker eine größere Anzahl implementiert würde, als das aktuell der Fall ist. Andererseits ist mir klar, dass die Ressourcen der Entwicklung begrenzt sind. Das war übrigens auch ein Grund, die Abstimmung als AnalyticsCreator Feedback zu implemtieren, damit es für die AC Entwicklung Rückmeldungen von mehreren Anwendern über die Wichtigkeit unterschiedlicher Features gibt.
Zusammenfassend ist der AC für mich gerade darum interessiert, weil er nicht zwingend alles automatisiert, sondern nur das, was ich will, dass er es automatisiert. Dass er Code-Automatisierung bietet, und weniger eine vollständige DWH-Automatisierung im Sinne der Erwartungen des Kommentars unter dem Video. Eine vollständige und nicht abschaltbare Automatisierung wäre für mich ein wichtiger Grund, den AnalyticsCreator nicht zu verwenden.
