我被要求创建一个表来存储来自多个子公司的多个地区的多个考勤系统的付费小时数据。该表将用于高级报告,因此基本上它正在跳过为每个系统(可能存在)创建表并直接转到最终产品的步骤。
请求是为每种类型的小时设置维度或按此付费:
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
每位员工有多个行,但通过这个过程,这将允许我们在添加新维度时捕获它们。
数据来自多个来源,我被告知不要担心ETL,只是设计终极表并使其适用于任何系统。我们会将此格式提供给其他人填写。
我只看过一个系统的原始数据,就像这样:
date | employee_id | gross_total_amount | regular_hours | regular_amount | OT_hours | OT_amount | classification | amount | hours
这很混乱。员工的多行和像gross_total这样的值重复每一行。有一个分类栏,其中包含PTO(付费休假),调整,空值,佣金等项目。由于重复值,不可能简单地将数据加起来使其等于gross_total_amount。
无论如何,我更倾向于采用基于列的方法,其中每行描述员工支付的截止时间。一个问题是我不会知道所有可能的小时类型,所以我不一定能像下表那样:
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
我更习惯以这种方式格式化的数据。担心的是,您可能无法捕获所有必需的列或是否添加了新的内容。 (例如,我知道有产假,陪产假,丧假,在其他地区有关于晚上工作的劳动法等)
有什么建议吗?从我的上司向我建议的表是否可行?
答案 0 :(得分:2)
让我概括一下我所理解的基本任务。
您从不同来源获取数据,具有不同的结构。您的任务是将它们合并到一个数据库中,以便能够回答有关所有这些数据的问题。我理解“不要担心ETL,而只是设计最终表”的提示,因为统一数据库不需要包含原始数据中可能存在的所有详细信息,而只需要提供足够的信息。满足统一数据库的特定要求。
只要你的上司对这些要求足够肯定,这听起来都是明智的。在这种情况下,您将减少从每个来源到统一结构的信息。
无论如何,您必须捕获来自每个源的数据的域语义。由于缺乏对域语义的访问,我无法为您澄清重复值的混乱。例如,如果有详细记录和总记录,如在您的示例中,添加所有记录的小时数是错误的,因为这总是会产生实际工作小时数的两倍。因此,有人必须担心ETL,即解释每组记录,可能包括员工的所有条目和一个工作日,找出它们的含义,并将它们转换为合并的结构。
我理解问题的另一部分是关于元数据的使用。您可以为假期休假和产假等概念设置不同的列,或者您有一个包含这些概念的元数据表作为键值对,并参考主表中的键。元数据方式有时被称为更灵活,因为您可以引入新类型(如陪产假)而无需重新设计数据库。但是,您需要重新设计软件填充,并且可能还需要查询表以使用新类型。因此,您无论如何都必须开发和部署新的软件版本,并且在表格中添加几列只是开发工作的一部分。
包含所有概念作为属性的宽表与元数据方法之间存在一个主要区别。如果你想确保在一段时间内,无论是全部值还是没有值,那么宽泛的表就很容易:只需使所有属性“非空”,就完成了。确保元数据解决方案的这一点意味着一些相当复杂的约束,根据您使用的数据库系统,这些约束可能会也可能不会。
如果这不是主要要求,我会采用务实的方式并使用不同的列,如果我只期望少数这些类型,否则使用单独的键值表。
所有这些考虑依赖于您的上级断言(据我所知)您的整合表只需要满足当前已知的要求,因此如果由于这些要求而不需要,您可以自由地丢弃原始详细信息。我对那种断言很谨慎。我们假设您的一些信息来源提供了更多信息。那么很有可能有一天有人要求提供包含此信息的报告。如果您的数据结构仅包含当前所需的内容,则无法实现这一目标。
有两种方法可以解决这个问题,即提供未来的需求。在了解来自每个其他源的数据之后,您可以扩展统一数据库以涵盖来自那里的所有数据结构。这需要一些努力,因为不同的来源可能使用不同的数据表达相同的概念,并且您必须合并这些以使数据具有可比性。此外,有可能您的所有努力都不值得给您带来麻烦,因为您获得的统一数据库实际上并不需要您获得的所有详细信息。因此,另一种更优雅的方法是保留为每个源导入的原始数据,并且仅在具体的新要求的情况下,扩展数据库并从源重新导入数据以涵盖其他详细信息。如果存储价格低,这可能会产生最佳的成本效益比。
答案 1 :(得分:2)
TAM makes lots of good points, and I have only two additional suggestions.
First, I would generate some fake data in the table as described above, and see if it can generate the required reports. Show your manager each of the reports based on the fake data, to check that they're OK. (It appears that the reports are the ultimate objective, so work back from there.)
Second, I would suggest that you get sample data from as many of the input systems as you can. This is to double check that what you're being asked to do is possible for all systems. It's not so you can design the ETL, or gather new requirements, just testing it all out on paper (do the ETL in your head). Use this to update the fake data, and generate fresh fake reports, and check the reports again.