如何自动区分主数据库的变化?

如何自动区分主数据库的变化?

我遇到了一个无法解决的问题。我想你们中可能有人有过类似的经历/问题,能够帮助社区中的其他人或分享一些有用的经验。

所以问题如下:我有一个主数据库1,我不能直接修改它,但我需要添加一些额外的数据,这些数据对于以合理的方式完成工作是必要的,唯一的解决方案是将其导出到.xlsx 文件,添加剩余的表和所需的信息2,这是可能的,但有一些重要的事情需要考虑:

-“主数据库”中的数据经常被重新排列,例如:如果某人的序数是 1,那么下次更新时,序数可能是 5

-“主数据库”中的数据可能会发生变化,例如:可以添加一些内容,可以删除一些内容

-主数据库中的数据可以修改,例如:值可能会改变

所以现在的问题是:如何将其导出到 .xlsx,添加我自己的表和数据,然后设法在每次主数据库更改时“区分?”,而不会丢失添加的数据或添加的数据与其他行不匹配?

有人成功做到了吗?

带表格的图像

答案1

您的比较实际上是两个表格(或 Excel 术语中的数据列表)的比较。一个表格是“主数据库”的最新版本,另一个表格是您之前处理过的版本(通过添加列等)。

接下来是对开发合适解决方案所涉及的过程的相当冗长和通用的描述。鉴于问题的普遍性,这是不可避免的。如果有任何不清楚的地方,请在评论中提问。

第一个任务是确定要使用哪一列或哪几列来比较两个表。您需要确定数据库术语中所谓的表的“键”。这是列(或列的组合),其值对于每行都是唯一的。例如,如果您的主数据库主要与项目有关,那么 可能是键(对于表的每一行都是唯一的)。或者,如果主数据库主要与人员有关,那么和Item Serial Number的组合可能是键。UsernameUser Lastname

了解主数据库的创建方式和创建原因可能有助于识别提供密钥的列。您可能还想向 IT 团队或负责“主数据库”技术管理的其他小组询问其密钥。由于它们在识别行方面非常重要,数据库设计人员通常不允许在表的行内修改充当密钥的列的值。

一旦确定了关键列,就会根据这些列中保存的值对两个表进行比较。调用“主数据库”的新版本表_新和之前的 .xlsx 版本上一个表比较两个表的过程涉及匹配行。两行匹配当一个表中匹配行的键列中的值与另一个表中匹配行的(相同)键列中的值相同时。

需要进行以下三类详细比较:

  1. 对于每一行表_新确定是否存在匹配的行上一个表. 不匹配的行表_新表示“主数据库”中新添加的行。
  2. 逆转这个过程,对于上一个表确定是否存在匹配的行表_新. 不匹配的行上一个表是已从“主数据库”中删除的行。
  3. 对于匹配的每一行表_新上一个表,比较每个公共非键列表_新上一个表。如果两个表之间的所有值对都相同,则表_新尚未改变。否则,已改变。

(请注意,如果由于某种原因并且与所做的假设相反,关键列中的值确实发生了更改,这将表现为从“主数据库”中删除一行并添加新行。添加和删除的行将被视为不相关的,而不是已更改的单个行。发生这种情况的原因是表_新将不再匹配其前一个匹配项上一个表,因此将被归类为新行;类似地,上一个表将不再匹配相应(但已更改)的行表_新,因此将被归类为已删除的行。)

3 次比较导致两个表中的每一行有 4 种可能的结果

  • 表_新与任何行都不匹配上一个表。结果是,在“主数据库”中添加了新行
  • 上一个表与任何行都不匹配表_新。这个结果是从“主数据库”中删除了一行。
  • 行匹配于表_新上一个表但两个表之间的非键列中的某些值不同:此结果是“主数据库”中的行已更改。
  • 行匹配于表_新上一个表两个表中非键列中的所有值都相同。结果是该行在“主数据库”中保持不变。

对于这 4 种结果,你需要指定要采取的行动。假设你想要创建一个新版本的上一个表来反映比较的结果。

这些操作应该是什么在很大程度上取决于您要满足的业务需求。例如,如果“主数据库”基于活动项目列表(例如仓库中的库存线、当前员工或正在进行的工作项目),则您可能希望在项目不再活动后保留历史记录(因此保留有关过时库存线、前员工和已完成/放弃的项目的信息)。

对您的业务需求的任何猜测都是推测性的,因此暂时对此事划一条线。

相反,注意力转向上面 1、2 和 3 中提到的比较。

首先要注意的是,在 Excel 中,识别单个值是否在列表中比识别两个或多个值是否都包含在单独的列表中更容易。因此,如果您有多个关键列,可以考虑的一个技巧是使用串联(或类似方法)创建一个新的人工列,该列可以单独充当键。例如"User Name"&" "& "User LastName"

只有一个键意味着该MATCH函数可用于测试一个表中的一行是否与另一个表中的一行匹配(在上面定义的意义上)。要使用的短语是

=MATCH(key_from_row_in_one_table, column_of_keys_in_other_table,0)

other_table如果找到匹配项,则返回行在中的位置,否则返回。如有必要,可以使用诸如 之类的函数或诸如 之类的短语#N/A来捕获错误。IFERROR=IF(ISNA(find_matched_row),one_thing,something_else)

为了组织比较,采用 3 个工作表的方法可能比较合适:

  • Sheet1:最新“主数据库”(Table_New)的导入但未处理的版本
  • Sheet2:主数据库的先前(.xlsx 版本)处理版本,包含添加的列等(Table_Previous)
  • Sheet3:更新后的版本上一个表源自 Sheet1 和 Sheet2 的比较。

如果需要,可以首先向 Sheet1 和 Sheet2 添加单个关键列(通过连接(或以其他方式组合)实际关键列形成)。此外,还可以向每个表添加列匹配已更改。 这匹配每个工作表中的列将基于MATCH前面概述的函数,并将包含另一个工作表中匹配行的位置,或者#N/A如果没有匹配项。对于匹配的行,已更改列可用于识别两个匹配的行是否共享所有相同的非键值。这可能很简单,就像一个公式传递TRUEFALSE更广泛的东西,用于识别哪些列已被更改。(这里实际做什么应该由业务需求决定。)

Sheet3 应该从 Sheet1 派生(如果业务需求主要集中在最新的“主数据库”中的内容)或者 Sheet1 和 Sheet2 派生(如果业务需求以“主数据库”为中心以及它随着时间的推移如何变化)。

在前一种情况下,显示为与 Sheet2 中的行匹配的行的添加列将使用 Sheet2 的值添加到 Sheet3。或者,如果这些添加的列是根据“主数据库”中存在的列计算得出的,则在以下情况下重新计算:已更改Sheet1 上的列表示已进行更改。INDEX如果使用公式来实现这一点,则可能会大量使用该函数。如果需要,Sheet3 中的结果可以包含地位列用于标识结果中的哪些行已添加到最新的“主数据库”中以及哪些行已更改。可以组织此列以保存与此最新“主数据库”相关的版本号和/或日期。

在后一种情况下,Sheet3 将主要基于 Sheet2,但会添加一些 Sheet1 中的行。新行将是 Sheet1 中被标识为不匹配的行,并且可以使用 Sheet3 中的公式来添加这些行。(这里的技巧是找到一种方法来“索引”Sheet 1 中这些不匹配的行,并为其分配索引号 1、2、3……,然后在 Sheet3 中匹配这些索引号(MATCH再次使用函数),并使用INDEX/MATCH构造将这些不匹配的行“拉”到 Sheet3 中。这些新行最容易添加到 Sheet3 中数据列表的末尾(但添加后可以重新排序)。需要添加/计算这些新行的附加列值。地位列现在还可用于识别从“主数据库”中删除的行。

一旦确信 Sheet3 包含正确的值,并且作为有效版本管理的一部分,通过选择性复制/粘贴来“修复”其上的值可能是明智的。此外,如果对行有所需的排序,也可以在完成之前进行。

当处理“主数据库”的后续版本时,Sheet2 将通过用 Sheet3 上的内容替换其内容来更新。Sheet1 将使用新版本的“主数据库”进行更新,Sheet3 将使用更新后的 Sheet1 和更新后的 Sheet2 之间的比较结果进行更新。

相关内容