数据库中国际数据集的规范化/验证?

解决此问题的方法可能是:

采用地址/电话号码/邮政编码等三种视图。

1. 第一种观点是把地址(比如说)看作多行文本。

2. 第二个视图是地址标签(下面将详细介绍)。

此方法所需的其他组件包括用于验证的通用过程(类/触发器)、用于打印的格式化例程、规则库以及用于更新验证规则的管理员机制。一个“catchall”规则表示这是一个有效的地址-它已被手动验证-即使它不符合规则库的任何规则。

组成部分: 1地址由多行组成,每行都有一个相关的序列号和多个标记(通常是一个)。也可以与地址行、规则集和验证它们的规则版本相关联,但这是一种改进,取决于更新/插入/计算速率。

3用特定领域语言编写的规则。这可以是正则表达式;一种特定于您的语言;您的常规开发语言(尽管这可能是最不有用的方法,因为编程语言可能会发现很难全面准确地表示我所说的那种规则)。代表性规则的一个例子可能是(处理您对美国邮政编码的描述)- 前五个字符必须是数字。

前五个字符表示“区号”。

规则将被分为组和集(如美国地址)规则必须能够引用其他规则以及地址数据。

1. 您的验证例程需要获取地址的行并对其应用规则(通常按集合)。它将返回一个布尔值有效或无效的地址,以及一组可选的验证规则。

2. 打印例程将再次对地址数据应用适当的规则集(可能与验证集不同),以提供格式化的地址。

我希望其他的组成部分从整体上看是显而易见的。

此方法旨在处理您的问题中发现的这些问题:

1. 电话代码的划分。

2. 可能使用的区号数量有限。

3. 为特定目的保留的电话号码块。

4. 数据标准化-数据标准化。然而,除了在数据仓库软件和包含大量实时传感器信息的数据库中,通常不使用这种标准化(反向索引)。在实现此解决方案时,您可能最终选择(可控地)复制数据。这不是解决方案的固有部分,但可能很方便。

5. 我强烈建议不要为每个变体添加类—这是不可伸缩的,也不可维护的。

6. 下面将详细介绍搜索。

8. 解决方案是可伸缩的—只需添加或修改规则即可。

并对相关问题进行了处理。

1. 即使您可以将验证规则应用于地址的国家格式,对于特定国家的标准也总会有例外。我自己的地址就是一个例子——我住在一条船上,需要额外的信息包括在我的地址中,超过邮局的标准地址。这类异常总是可能需要人工干预——因此人工干预可以接受的规则。

2. 不同的国家有不同的地址顺序——例如,中国的地址是这样写的:国家;邮政编码;城市;城市区域;街道名称;门牌号;人名。

3. 接受来自一个你没有规则的地区的第一个地址,并且这个国家的规则与你记录的任何规则都不同。

4. 想用不同于“他们”地址的地址(如办公室)的人。

5. 具体的个人解决问题-有人希望隐瞒他们的信件对他们最亲密的。

7. 对寻址规则的更改(例如为新开发添加新的邮政编码)可以方便快捷地进行。

1. 搜索会有点复杂-需要搜索所有行和地址的相关标签,而不是特定的地址字段

当我写我的回复时,我不知道BigTable。很快地看了一下,这似乎是一个非常相似的概念。至于在ACID开发中实现它,我认为这对于contact数据集和rule数据库是可能的。根据经验,我知道在这样的环境下,它很容易扩展到5*10^7套联系方式(尽管有背景,但不需要对联系方式进行时间限制验证)。

我不太清楚的是如何将验证和随后的标记合并到ACID/SQL事务中。似乎要使验证步骤成为ACID,可能需要根据规则集(首先测试最常见的情况,并在验证成功时停止)命令应用测试。另外,为了使事务成为ACID,可能有必要只对最常见的情况进行验证,而将其他情况标记为“needvalidation”,然后将其作为后台任务来完成。

验证的实际任务包括逐个检查整个规则库,直到找到一组验证所有输入行的规则。数据本身显然有潜在的指导原则——如果您记录了country,那么这既可以让您直接用country标记行,也可以为您必须测试的规则集提供一个过滤器。我很抱歉,但这是我到目前为止所能做的。

顺便说一句,这个草图模式只是朝着完全规范化的方向走了一段路。如图所示,每个地址都有自己的地址行序列,除了作为输入的单独行之外,没有数据的标准化(加上或减去您选择执行的任何预处理)。通过在地址和地址行M:N之间建立链接,并确保地址行表的行字段是它的主键,可以进一步采用这种方法。

当谈到这个概念的更详细的资源时,我有两个问题。

第一个(也是琐碎的)是,这个概念是我的原创作品,基于我作为方法顾问和IT战略顾问二十多年的经验,我对开发环境技术和开发方法有着特殊的兴趣。我的整个工作生涯都是在联系方式一直是一个主要问题的环境中度过的(出于财务和监管/立法方面的原因)。事实上,在我读完你的问题之前,我对你问题的最初回答在我的脑海里已经很完整了,尽管那时我花了大约四分之三个小时才把它打出来。

我的资料来源是:

2. 在一段时间内与Oracle技术人员进行的一系列讨论,讨论元数据;元数据;以及其他类似的概括。

4. 在一家大型金融机构工作,其联系方式系统的形状与我的建议非常相似,但源于非关系根源;在一个主要关注记忆、持久记忆和备份能力的时代,最初的技术动力是节省空间。

编辑:

我完成了上面的编辑,关上电脑,做了一些家务,上床睡觉,躺下,闭上眼睛,我有办法解决以前编辑中无法完成的部分。

Start read transaction
  Read set of address lines where one or more lines are "Needs Validation"
  Read all rule set names
  Read all rule lines which belong to the first rule set
  If read is not successful then abandon and start process again
End read transaction
Do while address not validated and not end of rule sets
  If set of address lines validates against first rule set then 
    prepare transaction by allocating the tags to be applied to each line of the 
    address and temporarily recording the rule set that has validated the address
    Start validation transaction
      Read same set of address lines and rule set (all fields)
      Is the address and the rule set identical to what was obtained in the read
      transaction?
      If identical then
        create appropriate set of Tag Usage records
        if successful then 
          commit validation transaction
          end overall process
        if not successful or 
        if not identical then
          rollback validation Tag and Tag Usage 
            ** This is the point where there might be problems if the rule set has 
            changed since reading it. The ordering may have changed due to amendment 
            deletion or creation of rule sets. This is the reason for the read of all 
            the read set names initially. However if there is such a change one can 
            afford to fail to validate and move on, aiming to come back to this address 
            later.
    End of validation transaction
    Start read transaction
      Read rule lines which belong to the next rule set
    End read transaction
End while loop
If end of rule sets reached and address not validated
  begin create Tag Usage transaction
    create tag usage pointing to Tag "Manual Intervention needed"
  end create Tag Usage transaction

所有三种类型的事务(地址、地址行更新、规则集、规则更新和标记、标记使用更新)都满足ACID条件。我坚信(但尚未证明)这三种类型的事务的任何交错、组合或交叉集也将满足ACID条件。

already answered 至少是电话号码。你可以对邮政编码做类似的处理。

如果您仍然需要在数据库中搜索特定的邮政编码,您可以为此编写正则表达式甚至函数。考虑到城市的名字,你可以把它们从地址线2中抹去,很有可能你最终得到了邮政编码。

我认为为每个国家编写验证文件肯定是一项巨大的工作,那就是200个国家。。。你怎么能确定你没有错过一些当地的会议?您可以编写一个函数eq,例如计算eq(“ABCDE-34”,“ABCDE.34”)==true。

虽然我不太明白写客户端的意义 和 服务器端验证。即使客户端是一个web浏览器,也可以通过AJAX使用服务器的验证。

最后,它取决于您使用的DBMS(是否支持Java存储过程?),客户端语言。。。以及数据是如何输入的(输入是否非常不准确?在网络浏览器中?)以及你想用它做什么。(您是否计划将数据库中的电话号码输入Skype,或者这些号码是否由在手机中键入号码的人读取?)你需要做一些特定的连接操作吗?当然,这取决于你能花多少工时来解决这个问题。。。