Data Warehouse

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
19.484
Reaktionen
662
Sagen wir mal hypothetisch meine Firma würde eins aufbauen wollen und hat bisher keins.
Die Daten liegen in vielen operativen Quellen und wir konzentrieren uns erstmal auf die Quellen die bereits in Datenbanken liegen.
Die Quellen gehören unterschiedlichen Teams, die auch noch in unterschiedlichen Abteilungen hängen.

Was sollten wir auf keinen / jeden Fall machen?

Wie sollte der Prozess aussehen?

Ich stell mir laienhaft vor, dass die Owner der Quellen eigenständig entscheiden können was sie ins Warehouse schicken und damit auch im Warehouse ihre Tabellen definieren. Eventuell gibt es einzelnen Tabellen wo man das Schema vorgibt. Die Owner entscheiden dann auch über die Zugriffsrechte auf die Daten.
 

parats'

Tippspielmeister 2012, Tippspielmeister 2019
Mitglied seit
21.05.2003
Beiträge
19.300
Reaktionen
1.329
Ort
Hamburg
Vom Gefühl würde ich sagen, dass Du eher ein Data Lake suchst und kein Data Warehouse.
Wenn man ein Data Warehouse richtig aufzieht, darf es keinen Datenzugriff auf dritte Quellen geben, wenn es um das Reporting geht, alles andere torpediert die Grundidee dahinter.
Das widerspricht deinem letzten Absatz so ziemlich, denn die Entscheidung trifft dann nicht der Owner, sondern die Entscheidung wird übergeordnet getroffen. Dazu gehört dann eine Bestandsaufnahme und Konsolidierung der Systeme, so dass Quellsysteme nur noch Daten an einen zentralen Punkt liefern (oder bereitstellen) und die Endanwender auf der anderen Seite des Knotens sitzen.

Unabhängig davon ein paar lessons learned die ich so aus 15 Jahren mitgenommen habe - definitiv unvollständig und nur so aus der Hüfte geschossen.
- Zuerst ein Konzept / Richtlinien wenn man auf einer grünen Wiese startet um die Nachhaltigkeit zu sichern
- Review-Prozesse definieren und vor allem einhalten
- Bei der Wahl des tech stacks auch zukünftige externe Ressourcen und Neuanstellungen im Auge behalten - Wenn Du keine Mitarbeiter mit entsprechenden Fähigkeiten hast oder findest, dann musst Du capex einsetzen und Consultingbuden anheuern.
- Vorher Gedanken um Datenmanagement (im speziellen Stammdatenverwaltung) machen -> Data Governance
- ausreichend Zeit für POCs nehmen und durchaus verschiedene Konstellationen ins Auge fassen
- Architektur-Ebene einziehen um den Überblick zu behalten und Synergien zu schaffen

Vieles davon haben wir erst seit der letzten Migration vor 6-7 Jahren umgesetzt, da wir auch nochmal auf der grünen Wiese angefangen haben. Nichts davon ist zwingend, aber ein Data Warehouse wächst (logischerweise) mit der Zeit und anfänglich begangene Fehler lassen sich im Nachhinein nicht so einfach korrigieren.

In Jedem Fall ist ein richtiges Datawarehouse relativ teuer und oftmals kann man mit Insellösungen (datensilos) und Data Lakes ähnliche Erfolge erzielen, wenn der Bedarf nach der internen Datenkrake noch nicht gegeben oder zu schwierig umzusetzen ist.
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
19.484
Reaktionen
662
Vom Gefühl würde ich sagen, dass Du eher ein Data Lake suchst und kein Data Warehouse.

Darüber kann man streiten. Ziel ist es schon übergeordnete Analysen zu erstellen und irgendwann auch zu veröffentlichen bzw. die Daten zur Verfügung zu stellen. Das könnte wahrscheinlich auch über ein anderes System passieren, dass auf den Data Lake zugreift. So ganz klar ist mir der Unterschied auch nicht. Passt das Bild?

1668427480804.png

Glaub structured wäre bei uns alles. Ich sehe bei uns nicht, dass jemand zentral vorgibt wie die schema alles aussehen (on write), sondern dass das jedes Team machen müsste. Das spricht dann eher für den Data Lake. Ins Warehouse sollten wohl eher Aggregationen und Teilmengen als Select * from *

Wenn man ein Data Warehouse richtig aufzieht, darf es keinen Datenzugriff auf dritte Quellen geben, wenn es um das Reporting geht, alles andere torpediert die Grundidee dahinter.Das widerspricht deinem letzten Absatz so ziemlich, denn die Entscheidung trifft dann nicht der Owner, sondern die Entscheidung wird übergeordnet getroffen. Dazu gehört dann eine Bestandsaufnahme und Konsolidierung der Systeme, so dass Quellsysteme nur noch Daten an einen zentralen Punkt liefern (oder bereitstellen) und die Endanwender auf der anderen Seite des Knotens sitzen.

Mein letzter Absatz soll Bedenken abfangen, dass es z.B. Daten aus Abteilung X gibt, die von Abteilung Y genutzt werden dürfen aber nicht von Abteilung Z for whatever reason. Darf ich kein Rechtemangement im Warehouse haben?
Es gibt bestimmt Bedenkenträger, wenn erstmal alle user des warehouses auf alles Zugriff haben.

Unabhängig davon ein paar lessons learned die ich so aus 15 Jahren mitgenommen habe - definitiv unvollständig und nur so aus der Hüfte geschossen.
- Zuerst ein Konzept / Richtlinien wenn man auf einer grünen Wiese startet um die Nachhaltigkeit zu sichern
- Review-Prozesse definieren und vor allem einhalten
- Bei der Wahl des tech stacks auch zukünftige externe Ressourcen und Neuanstellungen im Auge behalten - Wenn Du keine Mitarbeiter mit entsprechenden Fähigkeiten hast oder findest, dann musst Du capex einsetzen und Consultingbuden anheuern.
- Vorher Gedanken um Datenmanagement (im speziellen Stammdatenverwaltung) machen -> Data Governance
- ausreichend Zeit für POCs nehmen und durchaus verschiedene Konstellationen ins Auge fassen
- Architektur-Ebene einziehen um den Überblick zu behalten und Synergien zu schaffen

Vieles davon haben wir erst seit der letzten Migration vor 6-7 Jahren umgesetzt, da wir auch nochmal auf der grünen Wiese angefangen haben. Nichts davon ist zwingend, aber ein Data Warehouse wächst (logischerweise) mit der Zeit und anfänglich begangene Fehler lassen sich im Nachhinein nicht so einfach korrigieren.

In Jedem Fall ist ein richtiges Datawarehouse relativ teuer und oftmals kann man mit Insellösungen (datensilos) und Data Lakes ähnliche Erfolge erzielen, wenn der Bedarf nach der internen Datenkrake noch nicht gegeben oder zu schwierig umzusetzen ist.

Stammdatenverwaltung ist bei uns ein mega cluster fuck und wird auch dadurch erschwert, dass an drölf Stellen neue Stammdaten erhoben werden.

Laufen bei Euch personenbezogene Daten ins Data Warehouse?

Mich interessiert mehr der Prozess, wenn eine Quelle ihr Schema ändert oder sie dazukommt. Wird der Prozess dann von der IT bzw. dem Team des Warehouses angepasst oder vom Team der Datenquelle. Und wie sieht der Prozess aus?
 

parats'

Tippspielmeister 2012, Tippspielmeister 2019
Mitglied seit
21.05.2003
Beiträge
19.300
Reaktionen
1.329
Ort
Hamburg
Darüber kann man streiten. Ziel ist es schon übergeordnete Analysen zu erstellen und irgendwann auch zu veröffentlichen bzw. die Daten zur Verfügung zu stellen. Das könnte wahrscheinlich auch über ein anderes System passieren, dass auf den Data Lake zugreift. So ganz klar ist mir der Unterschied auch nicht. Passt das Bild?
So im groben ja. Der wesentliche Punkt ist das Processing, denn bei on write ist die Struktur bekannt und die Quelle wird entsprechend zurecht gebaut mittels ETL Prozessen. Bei on read bist du halt flexibel, was ich so aus deinem letzten Absatz herausgelesen hatte mit "dass die Owner der Quellen eigenständig entscheiden können was sie ins Warehouse schicken und damit auch im Warehouse ihre Tabellen definieren" - kann ich aber auch falsch verstanden haben, wie deine kommenden Absätze zeigen. ;)
Mein letzter Absatz soll Bedenken abfangen, dass es z.B. Daten aus Abteilung X gibt, die von Abteilung Y genutzt werden dürfen aber nicht von Abteilung Z for whatever reason. Darf ich kein Rechtemangement im Warehouse haben?
Es gibt bestimmt Bedenkenträger, wenn erstmal alle user des warehouses auf alles Zugriff haben.
Doch klar. Wir haben eine selbstentwickelte Rechteverwaltung ab der multidimensionalen Ebene die AD gestützt entsprechende Filterungen zulässt. Relational haben ohnehin nur Entwickler und der Betrieb Zugriff, damit muss man sich über eine Rechtekonstrukt auf der Ebene keine Gedanken machen und kann das entsprechend der Umgebung (Produktion / Entwicklung) justieren.
Worum es mir dabei ging ist, dass es keine Abteilung geben darf, die sich der Herausgabe verwehrt und stattdessen ein eigenständiges reporting betreibt. Ich komme bekanntermaßen aus der Logistik und wir haben relativ "häufig" mit dem Zoll oder Europol zu tun. Es gibt eine eigene Abteilung, die sich nur um Anfragen staatlicher Vollzugsbehörden kümmert und die sensiblen Daten haben wir selbstverständlich vorliegen. Vor allem reichern wir die Daten noch um deutlich mehr Informationen an, als die ursprünglichen operativen Systeme es je könnten. Damit haben wir jegliche Diskussion von Anfang erstickt, weil der Mehrwert zur Bearbeitung derartiger Anfragen dem ganzen Konzern hilft.
Was man immer vermeiden will, ist eine Art Schattensystem und zwei Quellen die eine Richtigkeit für sich beanspruchen, vor allem wenn das Ergebnis divergiert.
Stammdatenverwaltung ist bei uns ein mega cluster fuck und wird auch dadurch erschwert, dass an drölf Stellen neue Stammdaten erhoben werden.
Ist hier nicht anders und das ist eines der lessons learned oben - Data Governance frühzeitig betreiben. Bei uns ist das Kind schon in den Brunnen gefallen und seit mittlerweile 4 Jahren versuchen wir im Konzern das zu ändern. Ist mühselig, wenn sowas mehrere Jahrzehnte gewachsen ist, aber es wird.
Laufen bei Euch personenbezogene Daten ins Data Warehouse?
Ja, mit ganz wenigen Ausnahmen. Allerdings geht nicht alles raus an die Endanwender.
Mich interessiert mehr der Prozess, wenn eine Quelle ihr Schema ändert oder sie dazukommt. Wird der Prozess dann von der IT bzw. dem Team des Warehouses angepasst oder vom Team der Datenquelle. Und wie sieht der Prozess aus?
In der Kurzfassung läuft es meistens so, dass der Fachbereich ein Projekt hat und dafür einen PM stellt. Dieser meldet sich bei unseren PMs mit der Anforderung und bekommt entsprechend Aufwände mitgeteilt. Wenn dafür eine Anpassung in einem der Quellsysteme nötig ist, dann wird ein PM der entsprechenden Abteilung benannt und die Umstellung erfolgt dann in Absprache zwischen Quelle/Ziel.
Die Koordination geschieht natürlich übergeordnet und wird mehr oder minder vom steering vorgegeben.
Bei uns ändert keine Quelle einfach so ihr Schema und wenn doch, dann passiert sowas idR. einmal und nie wieder. Die Person wird zwar nicht entlassen, aber es wird deutlich gemacht, dass man in einem Konzern nicht einfach wyld an Datenquellen rumpfuschen kann.
Systeme beliefern sich oftmals gegenseitig mit Informationen und sowas betrifft dann idR. nicht nur uns alleine, sondern auch andere Systeme. Bei uns wäre das mit einem Ausfall von 1-2 Tagen auch nicht so schlimm, BI Systeme sind nicht kritisch. Wenn man aber damit ein operatives System lahmlegt, kann man schnell einen beachtlichen Schaden verursachen.
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
19.484
Reaktionen
662
Mal wieder die Frage an parats :) oder sonst noch jemand.

Wir hatten schon über den Horror von Stammdatenverwaltung geredet. Nutz ihr innerhalb der Stammdaten einen Global Unique Identifier (GUID) für die Unternehmen / Unternehmensdaten, wenn ihr sie ins Data Warehouse schiebt?
Gilt die GUID als personenbezogene Daten?

Theoretisch könnte ich mir vorstellen, dass ich Daten aus verschiedenen Quellen über die GUID verbinde und ins Warehouse schreibe und Sie danach vergesse. Dann kann ich aber schwer zurückverfolgen. Würde die GUID eigentlich gerne behalten, aber der Datenschutz.... ?

Die EU Komm sagt folgendes

Da ist z.B. "a company registration number" als Ausnahme genannt. Wäre denn eine GUID aus den Stammdaten was anders?
Von da kann ich auch immer zu den personenbezogenen Daten kommen.

Auf der anderen Seite heißt es auch
‘personal data’ means any information relating to an identified or identifiable natural person. an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person
Das gilt dann ja für jede FK Kombination die mich am Ende zu den eigentlichen persönlichen Daten bringt.
 
Zuletzt bearbeitet:

parats'

Tippspielmeister 2012, Tippspielmeister 2019
Mitglied seit
21.05.2003
Beiträge
19.300
Reaktionen
1.329
Ort
Hamburg
Ich bin mir gerade nicht ganz sicher was dein Plan ist. Wie und in welcher Form soll denn ein GUID verwendet werden?

Du hattest doch hier doch mal ein Modell mit Firmen/Branchen/Befragungen (?) Gepostet, oder nicht? Wenn es dir um sowas geht, dann kann ich mir nicht vorstellen, dass der Datenschutz Probleme machen sollte. Allerdings liegt der Fehler im Detail und ich sitze gerne auf der Seite, die alles in einem Datensatz haben will. ;)
Ich weiß, dass wir hier relativ sensibel mit den Leistungsdaten von Mitarbeitern umgehen bzw. diese nicht so herausgeben, dass gezielte Rückschlüsse gezogen werden können.
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
19.484
Reaktionen
662
Ich bin mir gerade nicht ganz sicher was dein Plan ist. Wie und in welcher Form soll denn ein GUID verwendet werden?

Du hattest doch hier doch mal ein Modell mit Firmen/Branchen/Befragungen (?) Gepostet, oder nicht? Wenn es dir um sowas geht, dann kann ich mir nicht vorstellen, dass der Datenschutz Probleme machen sollte. Allerdings liegt der Fehler im Detail und ich sitze gerne auf der Seite, die alles in einem Datensatz haben will. ;)
Ich weiß, dass wir hier relativ sensibel mit den Leistungsdaten von Mitarbeitern umgehen bzw. diese nicht so herausgeben, dass gezielte Rückschlüsse gezogen werden können.

Nehmen wir an ich hab eine zentrale Stammdatenverwaltung die Unternehmen unter einer GUID führt und Ansprechpartner etc. in Verbindung dazu speichert. In den einzelnen Datenquellen werden die Unternehmen mit anderen IDs oder unique identifieren gespeichert, weil Sie bisher noch nicht in dem zentralen System drin waren. Wenn ich jetzt Daten zweier Quellen irgendwo verbinden möchte, würde ich über die GUID der zentralen Stammdatenverwaltung gehen.

Danach hab ich dann eine Tabelle mit den Daten der unterschiedlichen Quelle pro Unternehmen mit der GUID. Datenschutz scheint der Meinung das die GUID auch personenbezogene Daten wären.
 

parats'

Tippspielmeister 2012, Tippspielmeister 2019
Mitglied seit
21.05.2003
Beiträge
19.300
Reaktionen
1.329
Ort
Hamburg
Mh, also theoretisch "stimmt" es ja auch. Die Frage ist halt aus welcher Grundhaltung die Daten verwendet/gespeichert werden. Wenn es bspw. um Kontaktdaten im Kontext der Unternehmen geht, dann sehe ich da keine Probleme. Aber ich bin nur Laie und rolle eher mit den Augen.
Mal ein Gegengedanke: kennst Du Firmen wie Northdata? Die machen prinzipiell doch etwas ähnliches und nehmen als Basis das Handelsregister.

Wie ich die Referenzen dann darstelle wäre ohnehin unerheblich. Sehe da keinen Grund für Einwände, aber ich bin wie gesagt auch nur Laie.
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
19.484
Reaktionen
662
Naja ein Problem könnte noch sein, dass unter der GUID teilweise auch Einzelpersonen gespeichert werden, wenn sie "Kunden" sind. Dann gäbs einen direkten Link zu den personenbezogenen Daten.

ChatGPT sagt auf die Frage "Is a global unique identifier peronsal data under the GDPR" folgendes
A global unique identifier (GUID) is not considered personal data under the General Data Protection Regulation (GDPR) because it does not directly identify an individual. Instead, a GUID is a randomly generated number that is used to identify an object or record in a database.

However, the GDPR does consider certain types of information that can be linked to a GUID to be personal data. For example, if a GUID is used to identify a record that contains an individual's name, address, or other personal information, then that GUID would be considered personal data under the GDPR.

In summary, a GUID is not considered personal data under the GDPR on its own, but it can be considered personal data if it is used to identify personal information about an individual
 

parats'

Tippspielmeister 2012, Tippspielmeister 2019
Mitglied seit
21.05.2003
Beiträge
19.300
Reaktionen
1.329
Ort
Hamburg
Jo, aber wenn die Firma bspw. eine Einzelperson ist oder in anderer Weise im Kontext der Firma öffentlich in Erscheinung tritt, dann sehe ich da wenig Probleme.
Gibt es denn ein konkretes veto?
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
19.484
Reaktionen
662
Wir haben auch einfach Kontakt zu Einzelpersonen als Privatmensch. Ein konkretes Veto gibt es noch nicht, aber Bedenken wurden angemeldet.

Wie gesagt könnte ich die GUID auch nur zum schreibens ins Warehouse nutzen, aber dann komme ich nicht mehr zurück. Das erscheint mir doof.
 

parats'

Tippspielmeister 2012, Tippspielmeister 2019
Mitglied seit
21.05.2003
Beiträge
19.300
Reaktionen
1.329
Ort
Hamburg
Ja, vor allem hast du direkt erstmal keinen großen Mehrwert.
Bedenken sind halt das eine, fraglich ist ob es wirklich Probleme mit dem Datenschutz geben kann und das kann wahrscheinlich nur ein Fachmann wirklich beantworten.
Aber in der Tat ist es interessante Frage, die ich so auch noch nicht hatte. Wir laden halt generell immer alles und die Herausgabe von sensiblen Daten lassen wir uns entweder genehmigen oder es gibt ne Art general Vollmacht für bspw. für den Zoll oder Kripo.
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
19.484
Reaktionen
662
Naja einspielen könnte ich dann einmalig schon, oder? Je nachdem dann halt immer von scratch an, falls sich die Daten in der Quelle ändern.
Ohne die GUID ist halt doof wenn ich später unterschiedliche Tabellen im Warehouse oder Lake wieder verbinden möchte. Das geht dann schwerlich ohne die, oder ich hab wieder ne Zwischenübersetungstabelle...

Bei uns gehts ja nicht mal ums herausgeben, sondern erstmal nur im die interne Zentralisierung
 

parats'

Tippspielmeister 2012, Tippspielmeister 2019
Mitglied seit
21.05.2003
Beiträge
19.300
Reaktionen
1.329
Ort
Hamburg
Vor allem würde das nachträgliche einsetzen von Relationen ja das gleiche Ergebnis nur mit mehr Aufwand liefern. Aber es zeigt halt auch, dass man sowas vorab planen muss uns die Leute abholt, bevor das Kind in den Brunnen gefallen ist. ;)
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
19.484
Reaktionen
662
Ich hab heute gelernt, das die IDs personenbezogene Daten sind, wenn im Unternehmensnamen der Namen einer noch lebender Person vorkommt...
 

parats'

Tippspielmeister 2012, Tippspielmeister 2019
Mitglied seit
21.05.2003
Beiträge
19.300
Reaktionen
1.329
Ort
Hamburg
Unternehmensnamen der Namen einer noch lebender Person vorkommt...
"A. Schulz & Sohn Co. KG" ist demnach "okay", wenn A. Schulz verstorben ist und sein Sohn entweder B. Schulz oder A. Scholz heißt. Korrekt?
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
19.484
Reaktionen
662
Also hier wird z.B. folgendes erklärt

„Wenn der Name der juristischen Person eine oder mehrere natürliche Personen bestimmt“, können sich auch juristische Personen auf den durch die Art. 7 und 8 der GrCH verliehenen Schutz berufen (vgl. EuGH, Urteil vom 9.11.2010, C-92/09, C-93/09). Gemeint sind neben Unternehmen, die unter dem Namen der zumindest auch haftenden Eigentümerin firmieren, u.a. auch Ich-AGs, eingetragene Kaufleute, usw. (nur exemplarisch: VG Wiesbaden, Urteil vom 7.12.2007 – 6 E 928/07).
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
19.484
Reaktionen
662
Daran halten sich also alle?

Andere Frage
Habt ihr dann eine Art Datenkatalog oder Domänen Übersicht der Daten?

Der Artikel ist wohl kein Fan mehr.
 

parats'

Tippspielmeister 2012, Tippspielmeister 2019
Mitglied seit
21.05.2003
Beiträge
19.300
Reaktionen
1.329
Ort
Hamburg
Nur indirekt in Form von technischen Dokumentationen, die aber eher für den internen Gebrauch sind. Eine Teilfunktion erfüllen die Fachbereiche durch die key user sogar selbst. Davon ab ist durch eine relativ enge Rechtestruktur eh nur das sichtbar, was sichtbar sein soll.
 
Mitglied seit
21.08.2010
Beiträge
7.572
Reaktionen
828
Nein. Nur indirekt in der Form von Domänenexperten die wissen wo welche Daten liegen.
Gruseliger Zustand in dem es einen Haufen Gatekeeper gibt weil man sich an zig Stellen am Ende selbst durch lange vergessene DB-Schemata und Prozesse wühlen muss. Meine Skills in Oracle-PL/SQL sind deswegen sehr viel besser als mir lieb ist :8[:
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
19.484
Reaktionen
662
Und wie würdest du das verhindern wenn du heute von vorne anfangen könntest
 
Mitglied seit
21.08.2010
Beiträge
7.572
Reaktionen
828
Quasi unmöglich ohne Management buy-in.
Aber mal realistisch:
Von vornherein alle SQL-Schemata schön kommentieren.
Generell versuchen eine single source of truth zu haben.
Eindeutige Verantwortlichkeiten und Aufgaben.
Klare Datenstrategie die definiert welche Daten für welche Zwecke genutzt und erhoben werden und wie lange.
Ein Dashboard oder Report über den ganzen Scheiß, welches sich auf Grundlage der Datenbanken regelmäßig aktualisiert und den Kram loggt.
Möglichst sämtliche ETL-Prozesse und Schemata in git-Repositories.


Im Endeffekt alles was man sich so an Best Practice denken kann wenn man mal eine Stunde drüber nachdenkt.
Ich vermute, dass mein AG da nicht die einzige Firma ist bei der so Kram wild ins Kraut schießt weil durch Fluktuation und Management-Hü-Hott nie so richtig mal diese undankbare aber wichtige Aufgabe von vorne bis hinten durchgezogen wurde.

Was einem eine saubere Infrastruktur bringt lässt sich halt leider nur extrem schwer beziffern, genau wie die Kosten eines Saustalls. Es ist halt "überall dauert alles etwas länger, und überall sind die Ergebnisse beschissener als sie sein müssten. Außerdem sind manche Dinge nicht möglich … und was nicht möglich ist kann man nur schlecht bewerten."
Leider ein Eldorado für "Praktiker" die lieber schnelle Quickwins forcieren, die die Situation langfristig nur verschlimmern, denn der "Value Add" einer schnellen dreckigen Lösung ist meistens recht gut zu beziffern wenn man die langfristigen Kosten ausklammert.
 

parats'

Tippspielmeister 2012, Tippspielmeister 2019
Mitglied seit
21.05.2003
Beiträge
19.300
Reaktionen
1.329
Ort
Hamburg
Das Problem ist und bleibt das commitment auf auf den höheren Ebenen.
Sobald man anfängt Kleinigkeiten "mal nebenbei" einzubauen, ohne das in alle Informationsschichten durchzugeben hat man verloren. Sowas fängt man nicht mehr ein, bzw. nur mit wirklich viel Aufwand.

dicke # an den letzten Absatz @Bootdiskette.
Wir betreuen hier mit 20 Leuten ein Datawarehouse mit knapp 2000 ETL Prozessen und rund 2500 Entitäten verteilt auf ~0,9 petabyte.
Als wir vor gut 8 Jahren nochmal auf der grünen Wiese angefangen haben, gab es die volle Rückendeckung von den oberen Ebenen und das ist glückerweise bis heute so geblieben. Ohne die Rückendeckung wäre das alles schon längst auseinander gefallen. Alleine das nächtliche Zeitfenster von 6h ist teils ein Hürde und nur mit viel Disziplin haltbar.
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
19.484
Reaktionen
662
Kann denn jemand eine konkrete Software für einen Datenkatalog empfehlen? Anscheinend sollte mit DCAT-ap Metadatenstandard wichtig sein. Ich würde halt gerne mit dem katalogisieren anfangen es aber gleich "richtiger" machen und nicht blöde Excel Umfragen oder ähnliches machen.
 
Oben