#005 Wie wichtig sind Namenskonventionen in Business Intelligence Projekten?

00:00:24 Marcus 

So Andreas. Wir sind live mit einer ganz, ganz neuen Folge. Folge 5! Ich bin schon wirklich begeistert, weil das ist ja so von unserem Meilenstein, die wir erreichen wollten, schon mal so die Hälfte. Wir haben ja uns mal vorgenommen 10 Folgen machen wir auf alle Fälle und wir sind jetzt schon bei Folge 5 und heute mit einem ganz besonderen Thema, nämlich Namenskonventionen und das ist ja eines deiner Lieblingsthemen. 

00:00:52 Andreas 

Marcus! Es freut mich, wieder mit dir zu sprechen und ich muss ganz ehrlich sagen ich habe mich total gefreut auf diese Folge und ich freue mich noch allerdings habe ich auch einfach Angst vor dieser Folge, dass die Leute tatsächlich denken, kommt da jetzt ein Diktator oder gibt es hier wirklich regeln, die alle befolgen können? 

00:01:12 Marcus 

Ja, ich habs auch überlegt, weil wir sind wieder an dem Thema Regeln dran. Ich habe schon überlegt, ob man es anders nennen kann. Vorlagen irgendwie Vereinfachung, weil ich bin es persönlich so gewohnt, dass wenn ich so ne gewisse Struktur habe, macht es mir eigentlich die Arbeit leichter, weil ich mir nicht immer wieder das Rad neu erfinden muss, sondern kennen so diesen Bauplan und das ist gerade bei den Namenskonventionen, weil wie soll ich das Kind nennen? Und Ich hab sie ja auch schon mal erzählt. Einer der wichtigsten bewegt Punkte war ein Video von Markus Raatz Ich hab geguckt, hier gibt es auch noch bei LinkedIn Learning, ich werde es mal in die schon aus reinpacken und da geht es um den User Friendly Name und das ist eben in der multidimensionalen Modellierung. Er zeigt da die Daten Ansicht und sagt an der Stelle können wir jetzt die technischen Namen auf einem benutzerfreundlichen Namen für den Business Anwender überführen und können uns eben dieser Präfixe wie Dim und Fakt entledigen. Jetzt sehe ich es aber immer wieder irgendwo auf Twitter auf in LinkedIn Post, dass ich ein Daten Modell sehe in Power BI und da sind diese Präfixe wie Dim und Fakt wieder mitgeführt und ich frag mich. Mach das Sinn? Was ist denn deine Einschätzung dazu? 

00:02:31 Andreas 

Marcus Das ist ein ganz heikles Thema Ich versuche, das mal ganz vorsichtig anzufassen, um es auf den Blickwinkel Power BI zu sehen. Sag ich dir sogar ja, da macht es Sinn, weil und zwar für mich ist Power BI ein tolles Self Service Tool es hat. Nur eine Stärke und gleichzeitig auch Schwäche erst lässt viele Dinge weg und nimmt die einst gegeben hin und es fängt schon mit Strukturen. Dann Versuch doch mal dir zu überlegen, wie deine Konvention heißen sollst du benutzt wieder Strukturen oder Dimensionen, also deine Strukturdaten. Bevor du zu den Bewegungsdaten kommst und wenn du dort das Dim einfach weg bist, was wir ja eine Dimension nennen, die ja auch Attribute beinhaltet und ähnliches, wenn du das Weglässt. Wie willst du denn im Nachgang wissen, was du dir eigentlich gerade anschaust, weil dieses Dim kannst du nicht durch andere machen das durch Sprachattribute oder eben diesen User Friendly Namen wieder weg. Das ist in Power BI einfach nicht mehr gegeben, also ich fang dann immer an zu überlegen macht es Sinn oder nicht? Und ich finde es eigentlich wissen wir, dass die Dimensionen gemeint ist, wenn dort steht Produkte sind ja nicht die Produkt Umsätze drin und dann kommen wir zum zweiten. Ich habs jetzt bewusst Produkte genannt Marcus. Jetzt habe ich eine Dimension. Meine allererste Frage war früher immer und ich bin jetzt schon etwas, ich habe graue Haare, sagt meine Friseurin immer, wir können die färben. Aber bei Dimensionen ist es so ist die Einzahl oder die Mehrzahl? Wie nennst du sie nennst du das Produkt oder Produkte? Die darüber könnte man allein schon ein Buch schreiben. Ich hab das immer ganz toll beschrieben Marcus ich hab den Kunden gesagt. Es heißt Produkt, weil Produkte sind drin. Das war für mich immer so eine Art. Ein- oder Überleitungsregel, um Ihnen das zu klarzumachen, weil du nennst es ja auch nicht. Wie nennst du denn Datum? So, jetzt bist du dran. 

00:04:28 Marcus 

Ja, interessanter Fall. Also tatsächlich bin ich anderer Meinung ich bin wirklich der bei dem User Friendly Name und lass die Dim und Fact weg und bin auch der Meinung also in einem multidimensionalen Punkt hatten wir es ja so, dass da wo die Measures drin sind, diese Faktentabelle wurde dann irgendwann zur Measure Group, also als Gruppe der Measures diese Tabelle und die anderen Dimensionstabellen waren daneben die Dimensionen und auch innerhalb von Power BI. Wenn ich es wirklich sauber ausführe und mache nur explizite Measures in eine Tabelle rein, in einer Fakten Tabelle, dann wird sie mit einem Taschenrechnersymbol versehen und wird ganz am Anfang nach oben geschoben, genauso wie früher im in Excel Pivot oben, die Measuretabelle, ich sag sogar früher ist ja heute auch noch so wenn du mit Excel auf dem Power BI Modell drauf zugreifst, angezeigt und diese Trennung gibt es für mich dann her, mit der Einzahl und Mehrzahl ist auch etwas, was mich beschäftigt hat und ja, aus meiner aus meiner Vergangenheit raus, wenn ich so die Beispiel Datenmodelle gesehen habe, war ich auch immer bei der Dimension Einzahl. Es war immer die Customer oder die Kunden Dimension und was mit mir dann aufgefallen ist ich verwende eigentlich in den Fakten Tabellen immer die Mehrzahl also ich habe meine Abrechnungsposten oder ich habe die Rechnungszeilen. Ich habe also es ist immer die Mehrzahl und das bringt mich zu einem anderen Punkt, zum Beispiel, wenn ich jetzt eine Kennzahl haben möchte, zum Beispiel meinen Kundenbestand oder mein Kunde. Ich habe eine Dimension Kunde, das ist klar, aber wo packe ich jetzt vielleicht diese Zählung meiner Kunden rein? Und da finde ich es immer schon hilfreich, wenn ich dann meinetwegen eine Fakten Tabelle Kunden aufbauen, wo ich dann auch mir im Vorfeld Gedanken mache, welche zusätzlichen Dimensionen können denn da rein, um zum Beispiel einen Zeitbezug reinzubringen, damit ich meine Kennzahl Kunde auch über den Zeitstrahl eben abbilden kann und das sind so kleine Hilfsmittel. Ich merke immer wieder, wenn auch in meinem näheren Umkreis jemand plötzlich angefangen ist und es hat einfach nur die Anzahl Elementen in der Kunde Dimension gezählt das läuft irgendwann auf ein Problem heraus und ich weiß ganz einfach ja, weil diese Kennzahl ist eine Kennzeichnung gehört in eine Faktentabelle und eben nicht in einer Dimensionstabelle rein. 

00:06:56 Andreas 

Da bin ich total bei dir und jetzt kommen wir zu dem spannendsten Teil finde ich. Ich hab schon gemerkt und das war mir klar, weil wir vorher auch schon drüber gesprochen haben. Da hat ja jeder unterschiedliche Ansätze, wo, wie er sie benennt, Einzahl Mehrzahl, aber bei den Fakten Informationen bin ich dabei, dass wir sie immer wenn du so willst Faktentabelle überführen. Ich hab am Ende eigentlich nur noch eine Tabelle wo alle Fakten drin sind und die Ordner Struktur ermöglicht es mir so ein bisschen zu gruppieren, ob das jetzt was aus meiner Dimensionsdenke ist oder aus meiner Kundenkontakt, wie auch immer ich es mache, worauf ich aber hinwill, ist und da sind wir wieder bei den Regeln für Regeln. Wenn wir es alle immer so machen, dass wir es immer wieder gleichartig machen, dass du also auch am mein beliebter Montagmorgen nach einer tollen Feier weißt. Mensch, das war noch so und du hast eigentlich ein Vorgehen, was du versuchst, immer gleichartig zu machen. Ich weiß, das ändert sich im Laufe der Zeit. Man sammelt Erfahrungen, die Produkte ändern sich, aber wenn man es versucht, dass man für sich ein Regelkorsett hat und das mit Kollegen und Kolleginnen, gerade wenn man mit mehreren arbeitet, durchzusetzen. Gleiches ist für mich so machst du mit Leerzeichen? Machst und mit Unterstrich? Machst du’s ohne? Machst du Camel-Case? Schreibst du alles klein? Schreibst du alles groß? Ich wünsche mir, dass alle meine Modelle, wenn ich sie sehe, das auch befolgen. Meistens ist es aber so der eine schreibt es mal klein, der andere groß, mal mit Leerzeichen. Also wünsch dir doch einfach mal etwas und dann würde ich sagen aus meiner Sicht und das wäre mein Wunsch lasst uns etwas aufstellen, wo wir sagen das ist unser Rule Book, das machen alle so. Wir hatten das früher da sein Kollege im Consulting gesagt so es gibt hier Spielregeln. Spielregeln gelten auch für ein Datenmodell. Genauso wie sie es fürs Autofahren, fürs über die Straße gehen, für alles. Es gibt regeln, Signale und ähnliches, die dich darauf hinweisen. Richtig, oder hier denkt nochmal drüber nach muss nicht falsch sein, aber ich wünsche mir klare Strukturen und so nervig das manchmal sein kann spätestens, wenn du jetzt sagst, nehmen wir unsere tolle Plattform Power BI dazu jetzt kommt noch zu Themen wie andere Berichts Plattform, der eine nimmt Excel, der nächsten nimmt das, dann gibt es noch Drittanbieter Werkzeuge, dann kommen solche Themen zu wie, jetzt ärgern wir unsere lieben Hörer mal Measure Gruppen und Granularitäten und was sind Measures? Und dann sag ich nur hä? Bin ich noch auf dem richtigen Weg? Und dann noch, geht weiter. Datenmodellierung, Composite, Hybrid, Live oder Direkt oder was auch immer. Marcus es kommen, obwohl das Thema eigentlich ganz klar ist, noch so viele Themen hinzu. Ich bin dafür versuchen wir doch einen Regelkorsett, wo wir sagen jeder weiß sofort wohl ist, dass man auch so mit Präfix Suffix arbeitet, dass man sich sofort wohlfühlt und glücklich und ich weiß, dass mit Unterstrich und Bindestrich diesen spätestens, wenn man in die Cloud geht. Dann weißt du, beim Data Lake darfst du es so machen, beim anderen so, der eine mag das mit Leerzeichen, der andere mit Bindestrich. Bei dem ist es nicht erlaubt. Das kommen so viele Plattformen hinzu, wo jede so ihre Besonderheiten hat. Lass uns versuchen, was möglichst Gemeinsames zu finden. 

00:10:09 Marcus 

Ja ja also sehr wichtig, weil ich hab es auch schon immer wieder gemerkt, wenn man so ein Regelwerk hat, auf das sich jeder verlassen kann, dann weiß er auch wo er schauen muss. Also man sieht vielleicht auch, wenn man mal schlampig gearbeitet hat oder ein Kollege schlampig gearbeitet hat, da muss man halt drüber reden, aber solange das Team an sich, sich auf ein gleiches Regelwerk committed hat, findet man sich auch immer wieder und dieses Regelwerk lässt sich auch leichter kommunizieren, das heißt auch der Endanwender, der vielleicht bei der Entwicklung nicht beteiligt war, wenn man ihm das Grundprinzip beschreibt, nachdem man diese Entscheidung getroffen hat, dann lässt sich das Ganze einfach viel einfacher transportieren und man braucht es vielleicht auch gar nicht in ellenlangen Dokus zu beschreiben, sondern man kriegt es wirklich über ein paar Regeln beschrieben, aber dann lass uns doch nochmal ein bisschen mit am technischen Part dranbleiben, was man denn so einsetzt oder was wir vielleicht so einsetzen an Namenskonventionen und mal kucken, wie wir damit umgehen. Also bei mir ist es so ein häufiges Problem ist ich habe eine Spalte in meinem Daten Modell. Die in Prinzip schon den Mausurenamen trägt, ist aber in dem Moment ja ein implizites Measure und jetzt möchte ich gerne das Ganze als explizites Measure draufsetzen, etwas, was sich aus der allgemeinen Entwicklung habe und was ich da mir zunutze gemacht habe, ist, dass ich einfach ein unterstrich vor den Spaltenbezeichnung setze, weil in der Programmierung macht man meistens die private Variablen oder so, die man eben nicht nach außen für andere Klassen zur Verfügung stellt, gibt man eben auch so ein, Unterstrich vor und gebe damit förmlich diesen Namen wieder frei, dass ich den wieder mit einer expliziten Measure belegen kann. Hast du noch so einen, ein oder anderen Trick, den du machst, umso Namenskonventionsregeln einzuhalten. 

00:12:11 Andreas 

Ja, ich muss gestehen gerade dieser Trick der macht es total spannend, weil ich habe einen Kollegen, der ist aus der mathematischen Welt und er benutzt diese unter Striche, die du so gerne benutzt, für das Thema implizit explizit benutzte er eigentlich eher für so Zwischenvariablen oder für irgendwie Tests. Das heißt seine ganzen Variablen, die er eigentlich danach wieder löscht und wenn du sie alle löschen würdest, wäre toll, aber im Prinzip sind die im Modell, das heißt. Der macht es grundsätzlich so, dass dann der Unterstrich für ihn bedeutet das kann später weg ist ja nur ein Test, also das ist immer superschwierig, aber ich weiß zumindest sofort, wer das war und das finde ich auch persönlich total gut. Das es da eine klare Logik, gibt ich versuche, das aber gerade, wo du sagst, implizit explizit ich gehe davon aus, dass unsere Zuhörer wissen, was damit gemeint ist. 

00:12:58 Marcus 

Ja sonst, erklärt doch mal. 

00:13:03 Andreas 

Nein, auf keinen Fall, das überlasse ich dir. Ich kenne das noch aus einem anderen Produkt heraus aus meiner Vergangenheit, die wir ja beide gemeinsam haben und da war sowas wie implizit explizit auch immer total spannend, gerade auch was Zuordnung zu Spalten von anderen Tabellen also sprich am Ende des Verknüpfen des Modells war ja auch immer ein Thema und ich finde es total spannend, ich habe immer versucht, es zu vermeiden, mit diesen unterstrichen zu arbeiten, weil ich das einfach für denjenigen, der es danach weiterführen darf, schwieriger fand, und wir haben das dann eher so gemacht und jetzt wird das jetzt wird es kompliziert vielleicht hast du eine bessere Lösung, auch da ist es eine schwierige ich habe halt der Measure meist noch etwas dazugegeben, sei es ein Präfix oder Suffix damit ich weiß, ich habe jetzt hier eine explizite Summe gebildet und habe ihr noch gesagt, was wir gemacht haben. Ich hab einen Kunden, der hat dann immer sowas wie Sum oder Count noch dazu gegeben und hat dann in der sprach Variante also dem Displayname wieder eigentlich die benutzt die er benutzen kann. Also dann hieß sie wieder so wie die implizite Measure. Auch verrückt. 

00:14:05 Marcus 

Ja also. 

00:14:06 Andreas 

Jetzt haben wir alle abgehängt, nehme ich an. 

00:14:08 Marcus 

Ne, wir fangen nochmal an, also für die implizit explizit Thematik ist es ja so, dass Power BI in der Lage ist, wenn ich eine Spalte habe, die einen Zahl Form hat, die Aggregationsform für das Visual implizit reinzugeben. In standardmäßig meistens SUM, aber ich kann es eben auch über ein Kontextmenü abändern und kann sagen ich möchte es eben zählen. Ich möchte das Maximum haben. Ich möchte das Minimum haben. Ich möchte den Average habe. Wenn ich das aber in einem DAX Ausdruck in einem DAX Measure definiere, muss ich innerhalb des DAX Ausdrucks explizit die Aggregationsform vorgeben und damit habe ich einmal ein explizites Measure bildet, was einfach nur immer die Summe ausgibt oder eben die Anzahl oder den Average und genau das was du beschreibst ist ja auch das andere, was man häufiger sieht und wo so irgendwie dieser Umbruch kommt. Dieses SUM hat sich so als Standard eingebürgert, man gibt es meistens gar nicht mehr somit vor, also man kennt häufig, dass man sieht ein Measure, das heißt Umsatz man sagt nicht SUM Umsatz oder Sum of Umsatz, der andere Part ist dann aber häufig hat man sobald man anfängt zu zählen macht man sowas wie Anzahl oder Count davor. Da macht man es dann doch schon irgendwo, weil man plötzlich sich aus diesem SUM Bereich irgendwie rausbeweg. Ja , es ist speziell dein Kollegen kann ich immer wieder gut verstehen, weil im Prinzip hat er eine Sache sich nämlich zu eigen gemacht, die ich ja auch sage Unterstrich heißt im Prinzip versteckt hin fürs System eigentlich nicht für den Endanwender sichtbar und nutzbar und dann beim Löschen. Also kann gelöscht werden muss man dann halt vorsichtig sein, wenn das wirklich verwendet wird, um eine DAX Berechnung zu machen und eben nicht nur zur Hilfe da ist da wäre dann der Unterschied. Ein Thema, was ich auch noch ganz gerne immer mal wieder mit Reinnehme ist wir haben so eine Art Dreiklang. Häufig sitzt man da und wir entwickeln Templates, das heißt, wir wissen häufig auch nicht die Anforderungen, wie der Kunde seinen Bericht darstellen will und wenn ich mir jetzt zum Beispiel einen Kunden vorstelle, dann hat so ein Kunde eine Kundennummer und ein Kunde hat einen Kundennamen und meistens oder häufiger gibt es dann die Leute, die möchten auch gerne beides zusammen anzeigen, also Kundennummer und Name und ich glaube, es wäre das ein oder andere im Power BI schonmal gemacht hat und mal nur das Feld Kundennummer und den Feld Kundennamen in eine Matrix reingezogen hat, sieht, dass das so unschön aufklappbar wird, also ist es bei uns so, dass wir tatsächlich ein zusammengesetztes Feld hinzufügen und wir genau diesen Dreiklang berücksichtigen, das heißt der Kunde ist die Kombination aus Nummer & Name Feld die Kundennummer, ist die Kundennummer und der Kundename ist der Kundenname. Hast du sowas auch schon genutzt? 

00:17:24 Andreas 

Marcus, das war doch Absicht von dir natürlich habe ich sowas schon benutzt und jetzt finde ich etwas total Spannendes. Jetzt stell dir wieder vor du hast den Kunden, du hast vielleicht Konten oder ähnliches und du hast natürlich neben dieser einfachen Struktur. Ich habe nur die Kontonummer, den Kontoname und Kontoname und Bezeichnung das sind nur 3 Felder. Jetzt aber die Kostenstruktur und du weißt ja, gerade in Bilanzen und G und V und alles, was es dazu noch gibt, was diesen Finanzbereich abdeckt, gibt es selten nur eine Ebene also nicht nur den Umsatz, sondern du hast natürlich noch Erlöse, Kosten willst eine G und V abbilden, eine Bilanz und wir haben eine aktuell ein Modell, was wir aus unserem Planungskontext heraus generieren, das kann bis zu 14 Ebenen haben und dann hast du 14 mal Nummer, Name und Nummer und Name. Also 14 * 3 muss ich dir nicht vorrechnen ist nicht unbedingt wenig und jetzt wieder das tolle, das ist total super geht doch alles, versteht auch jeder. Jetzt kommt noch hinzu jetzt willst du das natürlich auch als Hierarchie gleich zur Verfügung stellen, damit der Kunde es leichter hat, also hast du auch noch 3 Hierarchien, je nachdem was man macht. Früher kannte ich Werkzeuge, die haben das quasi in der Oberfläche gemacht, haben dann ein etwas komischen Code nachträglich generiert, der ist auch nicht leichter macht aber die haben das quasi in der Oberfläche abgebildet. Heute musst du das dem Anwender zur Verfügung stellen. Also ich finde wenn man da wieder das Thema mit seinem Namenskonvention durchhält, dann ist es auch klar und deutlich und verständlich und trotz der vielen Objekte, es ist ja nicht nur eine Dimension. Ich hab wieder diesen Fall aus meinem Planungsmodell, wir haben glaube ich 10 Dimensionen und jetzt überleg mal in jeder Struktur hast du 3 * 14 und das zehnmal. Ich finde spätestens dann sollte jedem klar sein, wenn man hier keine klare Linie hat und das nicht überall ähnlich strukturiert ist, möchte ich keinen Report bauen, also kann man da doch schon also für mich ganz klar sein also lass uns sowas nicht nur abhaken, sondern das sollte jeder so machen und ich glaube alle, die da in dem Feld unterwegs sind, tun das und dieser Dreiklang, der ist auch notwendig. Ich finde den auch wirklich gut, weil ich möchte ja in meinem Modell aufklappen und ich will sehen, welche Erlöskonten auf dieser Umsatzerlösposition sind ist toll. Genauso will ich sehen wenn ich Deutschland als Region aufklappe, was gehört denn da drunter. Welche Kunden sind denn da oder sind es sogar die Stores? Also jetzt kommt ja was für mich total spannendes, jetzt hast du die Struktur. Land oder Region. Die kann ja nicht nur beim Kunden sein, sondern vielleicht auch beim Lieferanten. Auch da wie machst du denn sowas? Also heißt denn die Dimension, das Dimensionsattribut in jeder Dimension anders oder heißt das überall Land oder Country bei dir? Wie machst du sowas? 

00:20:29 Marcus 

Tatsächlich ist es so, dass es da dann durchaus gleich heißt, ich habe es mir abgewöhnt, es wirklich lang zu strecken und noch mal auf das andere zu sprechen kommen zu kurz. Nee, ich bin ja immer an dem Punkt, wo man sage Regeln bewusst wählen, dann kann man sie auch bewusst brechen bedeutet, wenn ich jetzt diesen Dreiklang nicht durchführen möchte, sollte ich mir aber wenigstens im Klaren sein, wenn ich nur den Code verwende, oder nur die Nummer verwendet, dann sollte ich auch diesen Namenskonvention für Kundennummer verwenden und Kundenname und Kunde erstmal weglassen und freibelegt damit, falls sich das nachträglich nachbessern möchte, eben diese Felder noch frei habe und ich weiß ja dann im Prinzip irgendwelche Richtungen das geht. Bei uns im Datenmodell, weil du es angesprochen hast mit der Kontodimension haben wir es genauso. Wir haben bis zu 10 Ebenen reingezogen als Max und haben das auch vorbereitet, weil es ist einmal Arbeit, aber dann als Template kann es eben mehrere Benutzer nutzen. Weiter geht es bei uns, dass der Kunde im Business Central Umfeld Verkauf an Debitor heißt und es gibt genauso einen Rechnung an Debitor. Und wenn ich dann anfange, das ganze nochmal wieder zu paaren mit Land, oder Debitorbuchungsgruppe, dann ist eine Verkauf an Debitor Debitorbuchungsgruppe ein ziemlich ziemlich langer Name, den man in der Feldliste nicht mehr wirklich sehen kann, nur um den gegen die Rechnung an Debitor Debitorbuchungsgruppe abzugrenzen. Ja, und dann fängt man vielleicht an irgendwelche Debitor Bezeichnung im Namen einzukürzen oder kurz Schreibweisen auszudenken. Ne ist dann auch für mich dann an dem Punkt wo der Quatsch zu quetschich wird. Dann lieber den Berichtsdesigner überlassen, ob diese Informationen wirklich ja in dem Bericht rein muss, als Anzeigename oder eben da ne sinnvolle Bezeichnung zu finden, aber am Datenmodell kann man hier relativ einfach sehen, dass dieses Länderattribut unter dem Rechnung an Debitor gepflegt wurde und auch wenn ich es in meinen Visual reingezogen habe und gehe mit dem Mouseover drüber, kriege ich auch den langen Namen angezeigt. Also einmal die Dimensionstabelle, plus die Spalte, die verwendet wurde, wo ich dann eben rauslesen kann, woher es wirklich kommt, und dann ist es nur noch eine Frage der Optik. In einem Bericht und da kann es natürlich auch sein, dass man das sehr, sehr stark runter kürzt, weil man eben die Spalte möglichst schmal halten will oder eben die Legende innerhalb des Visuals. 

00:23:15 Andreas 

Finde ich Wahnsinn, wie leicht es gehen kann, dass man das doch wieder als komplex betrachten muss und die Bezeichnung können dann doch echt übernehmen also ich wundere mich immer wieder und freue mich eigentlich auch, dass es vielen so ähnlich geht. Bei all den Regeln gibt es ja immer wieder leichte Dinge, die diese Regel durchbrechen, wie du es ja schon ansprichst, so dieses lieber eine Regel brechen aber ich habe eine Regel. Ja, das muss natürlich auch zu dem Ganzen passen und gerade, wenn ich mir das so anschaue wie die andere damit umgehen, finde ich, hat da jeder so sein sWerkzeugset, wie er es immer wieder vorbereitet, also auch wir machen das tatsächlich so, dass wir diese Ganzen in Ebenen eigentlich schon haben, also unser Template ist auch vorbereitet. Du kannst es nutzen musst du es ja nicht und Vorteil ist du kannst es auch erstmal ausblenden, dann tut es keinem weh und wenn du es brauchst, kannst du es ja aktivieren also sichtbar machen insofern ist die Arbeit einmal gemacht. Aber wenn du es für jeden Kunden immer komplett neu oder umstrukturiert ist, ja der Aufwand viel größer insofern für mich passt das total super. Spannend finde ich halt, dass da jeder so seine gewissen Hilfsmittel und Hilfskonstrukte hat, die es uns beiden ja extrem leicht machen, dass man das Modell besser versteht und das ist mir ja eigentlich geht. Und ich weiß, gerade wenn man so mit technischen Werkzeugen arbeitet, gibt es ganz viele, die natürlich auch solche Themen haben wie ich habe jetzt hier ganz viele Dimensionesattribute, also alles was du diese Merkmale in meiner Dimension sind wie machst du es denn da in deinen Projekten, wenn du sagst, ich hab jetzt hier 40 Attribute drin, aber der Kunde nutzt davon ich sag mal 10. Was machst du mit den restlichen Attributen lässt du sie drin, blendest du sie aus oder löscht du sie? Ich weiß, wie Werkzeuge das machen und wir empfehlen würden die Frage ist natürlich immer wie macht man es eigentlich wirklich im Businessleben? 

00:25:05 Marcus 

Ja, muss ich auch echt überlegen, weil bei uns ja die also bei uns ist diese Trennung zwischen Self-Service-Berichtsersteller und Bereitstellen des Datenmodells gegebenenfalls viel grösser also wir gehen ja sogar in den Self-Service-Bereich in dem Punkt rein, dass wir die Kunden anlernen und unterstützen, das Datenmodell selbst weiterzuentwickeln. Das heißt, ich hab, nehme gar nicht mehr so viel Einfluss darauf. Die eine menschliche Thematik läuft meistens dahin, was ich habe, das hab ich mal also dieses Wegschmeißen machen die wenigsten in unserem Datenmodell, wenn wir über eine gewisse Anzahl Attribut nicht, kannst du noch nicht mal in einer Zahl fassen kommen fangen wir an das in Ordner zu strukturieren und es damit eben schon mal ein bisschen zu gliedern. Wir haben so ein typisches Beispiel wir nennen es Artikel/Ressource bei uns bedeutet auf einer Verkaufsrechnung können verschiedenste Elemente drauf sein ne Artikel kann drauf gebucht sein, ne Ressource kann drauf gebucht sein, ein Sachkonto kann drauf gebucht sein, aber es ist immer eben eine Verkaufsrechnungszeile und dementsprechend haben wir uns eine Dimension geschaffen, die wir eben nach den beiden Hauptelementen genannt haben. Artikel und Ressource das ist nicht nur eine Artikel Dimension weil da ist eben mehr drin und gerade bei diesen Attributen, indem wir Überschneidungen haben, die fallen dann eben in Artikel Ressourcen Bereich rein und ansonsten gibt es einen Ordner da sind die Artikel das sind die Artikel spezifischen Attribute drin und dann gibt es den Ordner Ressource, da sind die Ressourcen spezifischen Informationen drin und wenn es bei Sachkonten geht, dann gibt es eine auch einen Ordner, wo dann eben die Sachkonten spezifischen Informationen drin sind. Aber das Ausblenden, wird eigentlich sehr, sehr wenig gemacht als zumindest auch in innerhalb von Power BI, weil wenn du den nächsten Schritt gehst und sagst ich habe mein. Jetzt sage ich als Golden Data Set also ein zentrales Data Set, mit dem ich von außen nur noch drauf zugreife und ein Power BI Bericht öffne. Der Bericht Designer hat keine Möglichkeit für sich, dann nochmal die ausgeblendeten Informationen anzuzeigen. Was hingegen, wenn ich dies Daten, Modell und den Bericht in einer Datei habe, kann ich sagen ausgeblendete Elemente anzeigen, dann werden die Daten oder die Spalten etwas leicht gräulich angezeigt und ich kann sie dann trotzdem in meinem Bericht benutzen. Also dieser Aufwand, das Ganze wieder zu aktivieren, falls sie es noch nutzen möchte ist grösser und das andere, was wir ja auch immer wieder förmlich besprechen oder denken, ist ja, wir wollen ja dieses Daten Modell, was das Business abbildet und wenn der, wenn das Business sagt, ja und irgendeiner Stelle brauche ich dieses Attribut oder diese Information, dann sollte es einfach vorhanden sein und von den Businessuser flexibel einsetzbar sein. Wie machst du es? 

00:28:08 Andreas 

Tatsächlich ähnlich also meine Regel hätte jetzt eigentlich gesagt und das macht es auch zum Beispiel der der Tabular Editor wenn du sagst, ich möchte damit regeln arbeiten, alles was du im Modell nicht wirklich benutzt, würde er dir wegnehmen wollen, am liebsten das Problem ist natürlich wie immer. Ich möchte ja eigentlich danach sagen können du bist ja flexibel, du könntest das ändern. Ich fange dann eher immer anzusagen. Okay, die tun ja nicht weh, weil du sie ja irgendwann doch brauchst, wenn sie wirklich nicht brauchst, dann müssen sie vielleicht entfernt werden, aber wenn du sie wirklich benötigst, fangen wir dann auch an, so wie es andere machen, wahrscheinlich eher das zu gewissermaßen zu strukturieren so wenn du so willst heiße Attribute, kalte oder ein bisschen strukturieren nach Themen, sodass du sie in der großen Flut der Attribute wiederfindest ja aber so dass du sagst ich hab hier so meine wichtigen Attribute, die sind in meiner Kernstruktur und alles was so selten genutzte oder wirklich ganz, ganz selten benutzte. Die landen dann quasi eher in einem Ordner, wo ich sagen würde, ist wohl doch nicht so oft genutzt, aber auf alle Fälle ist es schwierig, das immer gleich zu löschen, also ich weiß, das sollte man tun, weil das Modell natürlich auch dadurch nicht kleiner wird, wenn man das alles mitnimmt, aber wenn man sich an so die Grundregeln hält und das versucht, so ein bisschen weg zu parken, dann schaffen man das auf alle Fälle. Die Frage ist natürlich immer, ob man sich überlegen sollte, und ich weiß nicht, wie das so in anderen Projekten ist aber so gerade das Thema Glossar hört man immer wieder. Ich erlebe aber bei 1 von 20 Kunden, das ist mal wirklich einer drüber nachdenkt und anfängt. Und von diesen 1 von 20 ist vielleicht jeder zweite der überhaupt gewillt, das zu tun, weil das ein Riesenaufwand ist, das vorzuhalten. Insofern bin ich wieder bei meinem Lieblingsthema halt dich ein bisschen an deine Regeln darf sie auch brechen. Dann ist es auch leicht, und dann sparst du dir vielleicht auch, dass viele nach dokumentieren, weil du es ja nicht brauchst. Ist ja so fast schon erklärend das Ganze. Insofern wir wissen ja beide Dokumentationen, wer liebt die schon? Sollten wir immer versuchen, so diese Regeln mitzunehmen. Ja, das wäre schon, wenn es für mich jetzt gilt, würde ich sagen, das wäre schon ein Punkt für den Weg nach Hause sozusagen. Ich hätte als allererstes gesagt Versuche dich an die Regeln zu halten. Jede Regel, die du befolgst, spart es dir das hinterher noch ausführlicher dokumentieren zu müssen, damit es jeder versteht, der nach dir kommt, wär so mein Punkt, hast du da vielleicht noch einen Punkt, den du unseren Hörern mit auf den Weg geben möchtest? 

00:30:39 Marcus 

Boah, das ist heute echt schwer? Also aus meiner Sicht wäre es so, das Datenmodell ist ja eigentlich für den Businessanwender gedacht, also versuche, den Tech Talk wegzulassen und mach etwas, was die Businessanwender auch verstehen können und das ist eigentlich das Hauptziel, also ein verständliches Datenmodell zu erzeugen. 

00:31:07 Andreas 

Finde ich einen guten Ansatz, dann gebe ich dir als letzten quasi aus meiner Sicht noch mit ich versuche natürlich so lange wie möglich auf der gesamten Strecke bis zum Businessanwender mein Tech Talk durchzuhalten, aber auf den letzten Schritt muss es so einfach wie möglich für dich als Reportersteller oder Nutzer sein, das Modell zu verstehen also die letzte, die letzte Instanz ist dann verständlich will ich mal vorsichtig sagen. Heißt nicht, dass die vorher nicht verständlich war, aber sie war einfach zu technisch. Also insofern, zum Schluss muss es irgendwann auch mal einfach werden. Lösen wir uns von diesem vielen Tech Themen ich möchte einen Report erstellen und muss wissen Ah, das ist die Kunden Struktur, da gibt es folgende Merkmale und da gibt es auch ein Land, was auch immer noch ist, ergibt und wäre schon schön, wenn es einfach ist. 

00:32:00 Marcus 

Gut, dann haben wir es wohl für heute und ich glaube, du hast schon das neue Thema angeteasert, weil ich finde es nämlich sehr, sehr spannend, wo du es beschrieben hast mit dem Glossar. Measures beschreiben, Strukturen beschreiben, Data Catalog. Ich glaube, da werden wir uns das nächste Mal mal mit beschäftigen, wie man denn wohl am besten diese Informationen weitergibt. 

00:32:24 Andreas 

Finde ich einen tollen Hinweis von dir Marcus und lass es uns versuchen. Vielleicht schaffen wir es tatsächlich, das Thema mit aufzunehmen. Beim nächsten Mal.  

00:32:32 Marcus 

Bis dahin, Ciao 

00:32:34 Andreas 

In diesem Sinne schöne Woche.