9 COUNTING LOGICAL FILES (DATA FUNCTIONS) NESMA案例翻译

9 COUNTING LOGICAL FILES (DATA FUNCTIONS)

翻译

问题描述

该数据模型是根据以下用户规范建立的。

实体类型【纳税人】包含纳税人识别号、姓名、出生日期以及有关纳税人的一些个人信息。

【纳税人】可以有多个【地址】。例如，除了家庭地址（必须提供的最小地址），还可以识别发票地址和/或邮政信箱号。

实体类型【标准信件】由唯一的信件编号和属于该信件的固定文本组成。

实体类型【税种】包含可以收取的不同种类的税。税种的组成如下：代码、说明和每月税额。（在这种特殊情况下，税收属于固定评估，对每个【纳税人】都是一样的。）

实体类型【应缴税款】记录了哪些【纳税人】必须支付哪些税款。除了外键，它还包含税务义务生效的日期和该义务结束的日期（到期日）。（后者通常不知道债务何时生效，但在以后记录。）

实体类型的【纳税评估】包含金额、最终付款日期和适用的纳税期限。评估总是包括一个固定的时间段：一年、半年、一个季度或一个月。

实体类型【已收款】包含收到的金额、收到付款的日期以及尚未分配给纳税评估的金额。

实体类型【分配付款】包含税务评估和已收付款的外键，但也包含已收款中已分配用于支付关联税务评估的部分。

实体类型【联系人】包含税务部门员工的姓名和一些补充数据，这些员工可以作为纳税人的联系人。只有当纳税人征求意见时，才会指定特定联系人。从那一刻起，纳税人总是和同一个人联系沟通。

原则上，【纳税人】只有在被要求缴纳一种或多种税款时才能进入系统。一旦【纳税人】不再登记某一税种（即，待支付税款的关联实体中的所有到期日均已过去，或者换句话说，纳税人不再有义务支付税款），且【已收款】不再与【纳税人】关联，则可以删除该纳税人。删除纳税人时，【邮件列表】中的链接事件将自动删除。在删除【纳税人】时，如果没有【纳税评估】仍然与之关联，将自动删除【应缴税款】记录。

【纳税评估】在全额支付一年后通过批处理功能存档。

创建的档案文件包含纳税人识别号、涉及的税款类型、纳税期限、税款金额、发送评估的日期以及全额支付评估的日期。当数据记录在档案中时，将立即删除【纳税评估】以及与其关联的【分配付款】。

只有全部分配且【分配付款】不再与【已收款】关了时，才能删除【已收款】记录。

最后，只有当某个【税种】没有任何与之链接的【应缴税款】时，才可以删除该【税种】。

这个规范化数据模型中有多少逻辑文件？有历史档案吗？

讨论

要分析此数据模型，您应该假设第4.21节中给出的非规范化规则。然后必须提出的第一个问题是是否存在FPA表。实体类型的描述表明，只有实体类型【标准信件】符合FPA表的标准。唯一状态不明确且可在这方面讨论的实体类型是【税种】，因为它除了包含代码和说明外，还包含金额。这意味着它包含不同类型的数据；例如，它不仅仅是为了翻译代码。

为了与非规范化规则保持一致，应该问的下一个问题是“哪些实体类型只包含 主键 数据”？根据指南，这些实体类型不计算在内；然而，在两个相关联的逻辑数据文件中，只包含主键的实体（ key-key entity）属性被计为数据元素类型。

乍一看，在这个数据模型中，它似乎只是邮件列表实体类型。然而，【纳税人】的主键应在【标准信件】上计数，因此实体类型的【标准信件】（称为FPA表）将失去FPA表的特征。事实上，【邮件列表】不再是一个主键实体（key-key entity），而是对【纳税人】中重复出现的属性进行规范化的结果。因此，得出的结论是，【邮件列表】不属于“主键实体（key-key entity）”的概念范围，仍然“简单”计算在内。

【分配支付】实体类型除了主键外，还包含支付给【税务评估】的金额，不符合要求。实体类型【应缴税款】也包含了比主键数据更多的数据。

其他九种实体类型必须检查它们代表了多少内部逻辑文件。这是在基数、可选性和实体独立性的基础上完成的。通过关联关系查看每对实体类型，以查看它们是否应包含在一个逻辑文件中。

【纳税人】和【地址】之间的关系是双边强制1:N关系。根据反规范化规则，这两种实体类型属于同一个内部逻辑文件。为了确定此内部逻辑文件中是否应包括任何其他实体类型，必须调查实体类型的其余关系。

实体类型【纳税人】和【邮件列表】之间的关系为1：（N）关系。问题描述显示，删除【纳税人】关联的【邮件列表】会自动删除。因此，【邮件列表】依赖于【纳税人】，因此包含在同一个内部逻辑文件中。

实体类型【纳税人】和【已收款】之间的关系是1：（N）关系，在这种关系中，只要【已收款】仍然链接到【纳税人】，就不能删除纳税人。这意味着【已收款】相对于【纳税人】而言是独立的实体，并且不属于与