Grohrock.consulting

Excel, Datenbanken und mehr

Seite 2 von 2

Power Query: Eine Einführung (Teil 2)

Quellen zusammenführen

Neben dem Import von Daten kann Power Query aber noch einiges mehr. In der Theorie haben wir natürlich das perfekte Data Warehouse, welches alle Daten in aufbereiteter Form zur Verfügung stellt, aber die Praxis zeigt doch immer wieder, dass Ad-Hoc-Berichte aus Bestandsdaten gemischt mit anderen Quellen erstellt werden müssen.

Wir erinnern uns an den externen Parter aus Teil 1, der uns die CSV-Dateien zugesandt hat. Wir wollen nun die Austausch-Kunden-ID durch die echte ersetzen. Letztere wird in unserem DWH zusammen mit anderen Informationen zum Kunden gespeichert und könnte nach einem ersten Import mit Power Query etwa folgendermaßen aussehen:

Power Query-Fenster 3

Verwenden wir nun die Funktion „zusammenführen“ um zwei Abfragen zu kombinieren. Im ersten Schritt müssen die Spalten ausgewählt werden, auf deren Basis ein Bezug hergestellt wird. In unserem Fall ist das die Übergangs-ID. Dann können wir uns entscheiden, ob alle Daten verwendet werden sollen oder nur Übereinstimmungen. Wir entscheiden uns hier für Option 2:

Power Query-Fenster 4

Was wir nun erhalten ist eine neue Abfrage, in der wir die zu übernehmenden Spalten aus der angefügten Tabelle selektieren können; im Beispiel hier waren das Name und Vorname. Das Ergebnis sieht dann so aus:

Power Query-Fenster 5

Mit Power Query haben wir also eine großartige Möglichkeit, Daten aus verschiedenen Quellen zusammenzuführen. Im Gegensatz zum SVERWEIS ist diese Möglichkeit auch wesentlich stabiler und flexibler.

Fazit

Power Query ist zwar nicht die perfekte Basis für eine unternehmensweite Strategie im Berichtswesen, aber es ist ein gutes Werkzeug, wenn schnell und auf unkomplizierte Weise Datenquellen importiert und verknüpft werden müssen.

In weiteren Beiträgen werde ich Schritt für Schritt zeigen, wie man Daten aus verschiedenen Quellen importieren, ändern und zusammenführen kann.

Fragen, Anregungen, Kritik, Wünsche? Hinterlasst mir einfach einen Kommentar und ich schaue, was ich tun kann.

Power Query: Eine Einführung (Teil 1)

Was ist Power Query?

Seit einiger Zeit bietet Microsoft für alle Besitzer von Office Professional Plus das Excel-Addon Power Query an. Beworben wird es als DIE Lösung für den Import und das Verschmelzen von Daten aus verschiedenen Quellen.

Die werksmäßig mitgelieferte Unterstützung von Datenimporten beschränkt sich bei Excel hauptsächlich auf Microsoft-Quellen und Textdateien. Power Query hingegen bietet die Möglichkeit, Daten aus verschiedenen Quellen zu importieren:

  • MySQL
  • Oracle
  • Sybase
  • Salesforce
  • Hadoop
  • etc.

Quellen bearbeiten

Einige Formate, wie z. B. CSV, können schon jetzt von Excel importiert werden. Die Anpassung muss dann aber in einem zweiten Schritt erfolgen. Mit Power Query können Anpassungen schon während des Imports vorgenommen werden, wodurch das Endprodukt schon sauber zur Verfügung steht.

Nehmen wir dazu ein einfaches Beispiel. Ein externer Partner verkauft Wartungsverträge an Bestandskunden. Jeden Tag erhalten wir eine CSV-Datei mit den folgenden Informationen:

  • Kunden-ID: ######## (int)
  • Verkaufsdatum: yyyymmdd (int)
  • Agenten-ID: ### (int)
  • ID des verkauften Vertrags: ###### (int)

Ein normaler Import würde den folgenden Datensatz produzieren:

Customer ID Date Agent ID Contract ID
52689425 20150228 23 653392
23485621 20150228 12 653392
13894651 20150228 15 653393
12346925 20150228 23 653392
96423678 20150228 16 653393
32649821 20150228 16 653392
36485196 20150229 23 653392
73915864 20150229 12 653392
67895126 20150301 15 653393

Auffällig ist zunächst das rein ID-basierte Datenformat. Zusätzlich nehmen wir jetzt an, dass wir unserem Partner aus Datenschutzgründen lediglich eine Austausch-Kunden-ID übermitteln. Glücklicherweise bietet PowerQuery hier genau die Möglichkeit, die wir brauchen. Ich möchte an dieser Stelle nur einen kurzen Überblick verschaffen, über die genauen Schritte werde ich in weiteren Artikeln eingehen. So in etwa könnten unsere Daten nach dem Import aussehen:

Power Query-Fenster 1

Ein paar Änderungen später bekommen wir dann folgendes heraus:

Power Query-Fenster 2

Im Prinzip ist das nichts, was man nicht auch mit Bordmitteln von Excel erreichen könnte, aber mit einem sehr klaren Vorteil. Nach einem Klick auf „Schließen & Laden“ werden die Daten direkt in das Datenmodell von Excel importiert und falls später neue Datensätze in der CSV-Datei hinzukommen, genügt eine einfache Aktualisierung, damit diese ebenfalls geladen werden; inklusive aller Veränderungen.

In Teil 2: Quellen zusammenführen werde ich auf die Möglichkeit eingehen, Daten mit Hilfe von PowerQuery zu verknüpfen.

Across: Terminologie verwalten (Teil 1)

Einleitung

Vermutlich unbestreitbar ist, dass es grundlegend für den Übersetzer ist, die Bedeutung von Wörtern in einer anderen Sprache zu kennen. Übersetzer werden kaum bestreiten, dass es ohne Kontext oft unmöglich ist, die Bedeutung eines Wortes in einer anderen Sprache zu kennen.

Es gibt dutzende von Beispielen, aber nehmen wir doch das deutsche Wort „Bremse“. Im Englischen kann es mit „brakes“ oder mit „horse-fly“ übersetzt werden; in der Tat ein nicht ganz kleiner Unterschied. Zugegeben, das Beispiel ist sehr einfach gewählt, aber kommen wir nun zu einem anderen. Das deutsche Wort „Tempomat“ wird meist für „cruise control“ verwendet, ist aber ein Warenzeichen von Mercedes-Benz. Es wäre also kaum ratsam, dieses Wort bei einem anderen Hersteller zu verwenden. Diese beiden Beispiele zeigen, dass der Kontext sich nur auf das Fachgebiet bezieht, sondern eine Vielzahl von Attributen eines Terms einschließen kann.

Kurz gesagt, je mehr Attribute man innerhalb eines Terms zur Verfügung stellt, desto einfacher fällt die Entscheidung, welche Übersetzung korrekt ist. Im ersten Teil dieser Reihe möchte ich anhand der obigen Beispiele zeigen, wie man mit crossTerm Attribute verwendet, um so einen Eintrag oder Term genauer zu bestimmen.

Terminologie in crossTerm

Die Standardeinstellungen von Across geben zwei Arten der Klassifizierung vor: Fachgebiet und Relation. Das Fachgebiet kann alles von „Mode“ bis „IT“ sein, wohingegen sich die Relation auf einen bestimmten Kunden oder ein Produkt beziehen kann. Da Theorie ziemlich langweilig sein kann, wollen wir doch direkt einmal in die Praxis einsteigen und aus den obigen Beispielen Einträge erstellen. Bevor wir diese Einträge erstellen können, benötigen wir die Fachgebiete „Biologie“ und „Technik“ (alternativ auch „Technik – KFZ“ als Untergebiet von „Technik“), sowie die Relation „Mercedes-Benz“ (zur Erstellung dieser Werte, siehe Across-Benutzerhandbuch).

Erster Satz Einträge: Bremse und die englischen Übersetzungen

Der erste Teil ist ziemlich einfach. Der erste Eintrag hat das Fachgebiet „Biologie“ und enthält den deutschen Term Bremse (Fachgebiet: Biologie) sowie den englischen Term horse-fly (Fachgebiet: Biologie). Der zweite Eintrag hat das Fachgebiet „Technik“ und enthält den deutschen Term Bremse (Fachgebiet: Technik) sowie den englischen Term brakes (Fachgebiet: Technik).

Beim Anlegen des zweiten Eintrags mit dem Term Bremse wird Across unter Umständen nachfragen, ob die beiden Einträge verschmolzen werden sollen. Das verneinen wir natürlich, da die Einträge semantisch nichts miteinander zu tun haben.

Zweiter Satz Einträge: cruise control und die deutschen Übersetzungen

An dieser Stelle wird es ein bisschen kniffliger, denn mehrere Szenarien müssen bedacht werden. Die gute Nachricht zuerst: wir benötigen natürlich nur einen Eintrag mit dem Fachgebiet „Technik“. Eine Relation wird an dieser Stelle nicht gesetzt, denn die Funktion „automatisch die Geschwindigkeit halten“ ist per se mit keinem Hersteller verknüpft. Zuerst werden wir den englischen Term cruise control (Fachgebiet: Technik) sowie die deutschen Termini Geschwindigkeitsregelanlage (Fachgebiet: Technik) und Tempomat (Fachgebiet: Technik; Relation: Mercedes-Benz) hinzufügen.

Möchte man es jetzt noch ein bisschen genauer machen, dann erstellt man einen weiteren deutschen Term Tempomat (Fachgebiet: Technik) und gibt diesem die Verwendung: Unwort. Falls nun jemand durch Einträge schaut ist völlig klar, dass Tempomat in der Relation Mercedes-Benz eine korrekte Übersetzung, ohne Relation aber ein Unwort ist.

Ein Ausblick auf Teil 2

In Teil 2 dieser Reihe werde ich erklären, wie man mit Hilfe von Attributen und der Filterfunktion die Vokabelsuche in crossDesk verbessern kann. Wie immer gilt natürlich, dass bei Fragen gerne die Kommentarfunktion genutzt werden kann. Ich werde dann versuchen, so schnell wie möglich zu antworten.

Across: creating HTML/XML templates

The first question you might ask when talking about templates in Across is: why should I invest my precious time in creating something that already exists? While it is true that Across comes with templates to segment HTML and XML, you should always keep in mind that those templates are for standard use and thus pretty generic. I for instance created my own for a knowledge system that uses basic HTML only. This means there will be no scripting and nearly no attributes that have to be translated. So for the sake of code safety it is much easier to simply hide everything the translators will never need. It makes work for them easier and it makes me sleep better.

The following text refers to HTML, but it is exactly the same for XML

So let us have a look into that special case of restricted HTML, because it shows which steps need to be taken to create a good template. First of all you need to determine which tags will be used in your documents. In my case that is:

  • br, hr
  • div, p, table, tbody, tr, td
  • span, a

As you can see, all forms of text formatting is done via the span tag, which reduces the amount of tags we need a lot. Now we can proceed to determining the attributes we will need to translate. Attributes are added based on tags, so in my case that is:

  • a: href, name

Everything else has attributes which should not be touched. Span for instance is used to allocate CSS styles. One could debate whether it is a good idea to translate href and name (for document internal links), but an author who doesn’t speak my language will find it incredibly hard to work with German anchor names.

Now to the practice part. In the menu bar, go to Tools > System settings and in the tree Document settings to the left, select Tagged HTML or Tagged XML, depending on what you need. There click New to create a new filter template.

Let’s start by adding a new HTML tag by clicking on Add. The name you see there is the tag, so let’s start with br. Content type will be empty, because there is nothing in between br tags. It’s the same for hr, by the way. Element type is set to external, because we won’t find br (or hr) in the middle of a sentence. This might of course be different in your setting, but external means that the tag will not be found inside a sentence. The consequence is that an external tag provokes a new segment.

We will keep the external setting to unconditional, but we will change it from normal to hidden. Hidden means that the tag will not appear for the translator, but it will be saved and later exported to the translated document. So why can we hide those tags? The reason is pretty simple. The position of these tags is defined by the end of the previous segment and the beginning of the next segment and there is nothing to translate in there. This reduces the overall chance to meddle with tags and cause damage.

Next we will move to div, p, etc. Those are external tags as well, because they all divide the document. They are also unconditional, but they are normal and not hidden. If you hide these tags, then Across will think that everything between <p> and </p> needs to be hidden, which is clearly not what we intend. After all the text between those tags needs to be translated. Will your text be full of useless tags? The answer is no. By making this tag external we told Across that this tag will not be found inside a sentence, which means it’s not relevant for translation. Therefore Across will automatically hide it from the translator.

The last set of tags is span and a. Both may appear inside a sentence, which is why they need to be set to internal and normal. Setting a tag to internal will make it visible in crossDesk, but the tag itself can still not be changed by the translator. All he can do is move the position around, which is useful because links and certain formats can appear at different places in a translation. Small hint: adding the tag to the target editor can be done by double clicking on the tag in the segment window.

Now to the next part, attributes. Attributes are parts of code found inside tags, but not all need to be translated. If you don’t need it translated, just don’t add it and Across will handle it by itself. In my case the href and the name attributes will need to be translated for the reasons mentioned earlier. All we need to do for that is select the a tag in the list and click Edit. Then we click the Attribute tab and Add. Now enter a name and click Save. You will now be able to select the attribute in the list and choose Translatable. This will mean that the attribute can be translated so if I have an anchor with name=“Anker“, Across will show that Anker can be translated.

The last settings can be found by clicking on Configure. In Splitting properties I activated splitting of paragraphs into sentences, because most of the time, the number of sentences will be equal in source and target text. Of course there will be exceptions, but it’s always possible to merge segments. Removing white spaces is a bit more tricky, though. When I tried that with my test documents, certain tags were not treated correctly and thus not the whole text was shown. If I ever find out why, I’ll update this document. In Advanced Settings you will a lot of – as the name suggests – advanced options. Script translation is not important in my case and charset and encoding should be set to never change. The target documents will be used in the same knowledge base as the source documents, so nothing needs to be changed. The standard element type is not important as well, because only a very restricted set of HTML will be used. Convert character entities is completely deactivated in my case, because the document encoding supports every special character used in the documents. What I activated in my case is Normalize white spaces, because contrary to removing white spaces in the Splitting properties, this doesn’t seem to affect tags.

So that’s it. We created a custom template that helps us filter custom HTML or XML documents. It makes translating easier because you don’t see every part of the code and it makes the code safer because things that should not be changed are simply locked.

Questions? Like? Hate? Feel free to comment and I will try to answer as soon as possible or edit my text.

Seite 2 von 2

Läuft mit WordPress & Theme erstellt von Anders Norén