Erstellen einer Tabelle mit festen Spalten im Vergleich zu Schlüsselwerten von Metadatenpaaren?

Question

Ich wurde gebeten, eine Tabelle zu erstellen, um bezahlte Stunden Daten von mehreren Anwesenheitssystemen aus mehreren Regionen von mehreren Untergesellschaften zu speichern. Diese Tabelle würde für die Berichterstattung auf hoher Ebene verwendet werden, so dass im Grunde genommen die Schritte zum Erstellen von Tabellen für jedes System (die möglicherweise existieren) übersprungen wird und direkt zum endgültigen Produkt übergegangen wird.

Die Anforderung war eine Dimension für jede Art von Stunden zu haben, oder wie diese:

date  | employee_id | type   | hours | amount 
2016-04-22  abc123  regular   80  3500 
2016-04-22  abc123  overtime   6  200 
2016-04-22  abc123  adjustment  1  13 
2016-04-22  abc123  paid time off  24  100 
2016-04-22  abc123  commission     600 
2016-04-22  abc123  gross total    4413 

Es gibt mehrere Zeilen pro Mitarbeiter, aber das obwohl Prozess ist, dass diese uns neue Dimensionen erfassen lassen, wenn sie sind hinzugefügt.

Die Daten stammen aus verschiedenen Quellen, und mir wurde gesagt, dass ich mir keine Gedanken über die ETL machen sollte, sondern einfach die ultimative Tabelle entwerfen und sie für jedes System funktionieren lassen sollte. Wir können dieses Format zu anderen Menschen zur Verfügung stellen für sie füllen

Ich habe nur die Rohdaten von einem System und es so gesehen.

date | employee_id | gross_total_amount | regular_hours | regular_amount | OT_hours | OT_amount | classification | amount | hours 

es ziemlich chaotisch ist. Mehrere Zeilen für Mitarbeiter und Werte wie Brutto_gesamt wiederholen jede Zeile. Es gibt eine Klassifizierungsspalte, die Elemente wie PTO (bezahlte Auszeit), Anpassungen, Leerwerte, Provision usw. enthält. Aufgrund wiederholter Werte ist es unmöglich, die Daten einfach einfach zu summieren, um sie gleich der Bruttototalmenge zu machen.

Wie auch immer, ich würde irgendwie lieber einen spaltenbasierten Ansatz machen, wo jede Zeile die bezahlten Stunden für einen Cutoff beschreibt. Ein Problem ist, dass ich nicht alle möglichen Arten von Stunden wissen, die möglich sind, so kann ich nicht unbedingt einen Tisch machen wie:

date | employee_id | gross_total_amount | commission_amount | regular_hours | regular_amount | overtime_hours | overtime_amount | paid_time_off_hours | paid_time_off_amount | holiday_hours | holiday_amount 

Ich bin mehr an Daten formatiert, die Art und Weise though. Das Problem besteht darin, dass Sie möglicherweise nicht alle erforderlichen Spalten erfassen oder etwas Neues hinzugefügt wird. (Zum Beispiel weiß ich, dass es Mutterschaftsurlaub, Vaterschaftsurlaub, Trauerurlaub, in anderen Regionen gibt es Arbeitsgesetze über die Arbeit in der Nacht, etc.)

Haben Sie eine Beratung? Ist der Tisch, der mir von meinem Vorgesetzten vorgeschlagen wurde, eine praktikable Lösung?

Answer 1

Lassen Sie mich rekapitulieren, was ich als die grundlegende Aufgabe verstehe.

Sie erhalten Daten aus verschiedenen Quellen mit unterschiedlichen Strukturen. Ihre Aufgabe ist es, sie in einer einzigen Datenbank zu konsolidieren, um Fragen zu all diesen Daten beantworten zu können. Ich verstehe den Hinweis darauf, "sich nicht um die ETL zu kümmern, sondern nur die ultimative Tabelle zu entwerfen", so dass Ihre konsolidierte Datenbank nicht alle Detailinformationen enthalten muss, die in den Originaldaten vorhanden sein könnten, sondern nur genügend Informationen erfüllen die spezifischen Anforderungen an die konsolidierte Datenbank.

Dies klingt sinnvoll, solange Ihr Vorgesetzter über diese Anforderungen sicher genug ist. In diesem Fall reduzieren Sie die Informationen aus den einzelnen Quellen auf die konsolidierte Struktur.

In jedem Fall müssen Sie die Domänensemantik der Daten erfassen, die von jeder Quelle kommen. Da Ihnen die Domain-Semantik nicht zur Verfügung steht, kann ich Ihnen nicht die Unordnung von Werten erklären. Wenn z. B. Detaildatensätze und Bruttosummensätze vorhanden sind, wie in Ihrem Beispiel, wäre es falsch, die Stunden aller Datensätze hinzuzufügen, da dies immer die doppelte Anzahl der tatsächlich gearbeiteten Stunden ergeben würde.Also muss jemand sich Gedanken über ETL machen, nämlich jede Datensatzgruppe zu interpretieren, die wahrscheinlich aus allen Einträgen für einen Mitarbeiter und einen Arbeitstag besteht, herauszufinden, was sie bedeuten, und in die konsolidierte Struktur umwandeln.

Ich verstehe einen anderen Teil der Frage über die Verwendung von Metadaten zu sein. Sie können verschiedene Spalten für Begriffe wie Urlaub und Mutterschutz haben, oder Sie haben eine Metadatentabelle mit diesen Begriffen als Schlüssel/Wert-Paar und beziehen sich auf den Schlüssel aus Ihrer Haupttabelle. Die Metadatenweise wird manchmal als flexibler gelobt, da Sie einen neuen Typ (wie Vaterschaftsurlaub) einführen können, ohne Ihre Datenbank neu zu gestalten. Allerdings müssen Sie die Software neu füllen und wahrscheinlich auch Ihre Tabellen abfragen, um den neuen Typ zu verwenden. Sie müssen also ohnehin eine neue Softwareversion entwickeln und bereitstellen, und das Hinzufügen von ein paar Spalten zu einer Tabelle ist nur ein Teil dieser Entwicklungsbemühungen.

Es gibt einen großen Unterschied zwischen einer breiten Tabelle, die alle Begriffe als Attribute enthält, und dem Metadatenansatz. Wenn Sie sicherstellen möchten, dass für einen Zeitraum entweder alle oder keine der Werte vorhanden sind, ist das mit der breiten Tabelle einfach: Machen Sie einfach alle Attribute "nicht null" und Sie sind fertig. Dies für die Metadaten-Lösung zu gewährleisten, würde eine ziemlich komplizierte Einschränkung bedeuten, die je nach dem von Ihnen verwendeten Datenbanksystem verfügbar ist oder nicht.

Wenn das keine Hauptanforderung ist, würde ich einen pragmatischen Weg gehen und andere Spalten verwenden, wenn ich nur eine Handvoll dieser Typen erwarte, und ansonsten eine separate Schlüsselwerttabelle.

Alle diese Überlegungen beruhen auf der Behauptung Ihres Vorgesetzten (wie ich es verstehe), dass Ihre konsolidierte Tabelle nur die heute bekannten Anforderungen erfüllen muss, so dass Sie die Original-Detailinformationen wegwerfen können, wenn sie aufgrund dieser Anforderungen nicht benötigt werden . Ich bin vorsichtig mit dieser Art von Behauptung. Angenommen, einige Ihrer Informationsquellen liefern zusätzliche Informationen. Dann ist es sehr wahrscheinlich, dass jemand eines Tages um einen Bericht bittet, der diese Informationen enthält, sofern vorhanden. Dies ist nicht möglich, wenn Ihre Datenstruktur nur das enthält, was heute benötigt wird.

Es gibt zwei Möglichkeiten, dies zu handhaben, d. H. Um zukünftige Anforderungen zu erfüllen. Sie können, nachdem Sie die Daten von jeder zusätzlichen Quelle kennen, Ihre konsolidierte Datenbank so erweitern, dass sie alle Datenstrukturen abdeckt, die von dort kommen. Dies erfordert einige Anstrengungen, da verschiedene Quellen dasselbe Konzept mit unterschiedlichen Daten ausdrücken können und Sie diese konsolidieren müssen, um die Daten vergleichbar zu machen. Es gibt auch eine gewisse Wahrscheinlichkeit, dass nicht all Ihre Bemühungen die Mühe wert sind, da nicht alle Detailinformationen, die Sie erhalten, für Ihre konsolidierte Datenbank benötigt werden. Ein anderer eleganterer Weg wäre daher, die Originaldaten beizubehalten, die Sie für jede Quelle importieren, und nur im Falle einer konkreten neuen Anforderung, erweitern Sie Ihre Datenbank und importieren Sie die Daten aus den Quellen neu, um die zusätzlichen Details abzudecken. Da die Lagerhaltungspreise niedrig sind, könnte dies ein optimales Kosten-Nutzen-Verhältnis ergeben.

Answer 2

TAM macht viele gute Punkte, und ich habe nur zwei zusätzliche Vorschläge.

Zuerst würde ich einige gefälschte Daten in der Tabelle wie oben beschrieben generieren und sehen, ob es die erforderlichen Berichte generieren kann. Zeigen Sie Ihrem Manager alle Berichte basierend auf den gefälschten Daten, um zu überprüfen, ob sie in Ordnung sind. (Es scheint, dass die Berichte das ultimative Ziel sind, also arbeite von dort weiter.)

Zweitens würde ich vorschlagen, dass Sie Beispieldaten von so vielen Eingabesystemen erhalten, wie Sie können. Dies dient dazu, zu überprüfen, dass das, was Sie tun müssen, für alle Systeme möglich ist. Es ist nicht so, dass Sie die ETL entwerfen oder neue Anforderungen erfassen können, indem Sie alles auf dem Papier testen (tun Sie das ETL in Ihrem Kopf). Verwenden Sie dies, um die gefälschten Daten zu aktualisieren und neue gefälschte Berichte zu generieren, und überprüfen Sie die Berichte erneut.