28 NESMA 识别内部逻辑文件

NESMA 识别内部逻辑文件

英文原文

Problem description

A municipal tax administration system has a collection module in which payments are recorded. These payments relate to real-estate tax, waste tax, sewage charges and tourist taxes. The payments received are stored in four tables whose structure is documented below.

PAYMENT_REAL-ESTATE-TAX	PAYMENT_WASTE-TAX	PAYMENT_SEWAGE-CHARGES	PAYMENT_TOURIST-TAX
PaymentNumber	PaymentNumber	PaymentNumber	PaymentNumber
Amount	Amount	Amount	Amount
FiscalYear	FiscalYear	FiscalYear	FiscalYear
SocialSecurityNumber	SocialSecurityNumber	SocialSecurityNumber
ChamberOfCommerceNr			ChamberOfCommerceNr
PaymentDate	PaymentDate	PaymentDate	PaymentDate
AssessmentNumber
	TaxationNumber	TaxationNumber
			ClaimNumber
AccountNumber	AccountNumber	AccountNumber	AccountNumber
PeriodSerialNumber	PeriodSerialNumber	PeriodSerialNumber	PeriodSerialNumber
PaymentReference	PaymentReference	PaymentReference	PaymentReference
IndicationCollectionPayment	IndicationCollectionPayment	IndicationCollectionPayment

All cases are about bank transfer payments. There is no essential difference between the assessment number, taxation number and claim number; these are sheer fiscally-legal designations. The system determines, based on the payment reference of a payment received (in which an indication of the tax category is included) in which of the four entities the concerned payment is booked. The procedure for all payments received is the same: the entries are collected daily in an output file for the general ledger system. The collection module provides the same functionality to monitor the status of payments for all types of payments.How many ILF should be identified in this situation?

Discussion

The definition of an ILF is:
An internal logical file is a logical group of permanent data seen from the perspective of the user that meets each of the following criteria:

• It is used by the application to be counted
• It is maintained by the application to be counted

The aforementioned entities meet the listed criteria: they are both used and maintained by the information system to be counted. However, the phrase, “from the perspective of the user” is crucial. The guideline states the following on this subject:

“… a group of data that an experienced user considers as a significant and useful unit or object. An equivalent to this kind of logical group of data is an object type in data modeling.”

For users, the four different types of taxes are also four different things. Taxes and the accompanying regulations are indeed mutually substantively totally different. The designer of the above model has wanted to connect to the different taxes and opted to accommodate four types of payments in four separate tables; these are largely similar in structure. Logically, however, they all concern one object type PAYMENT, of which one of the data element types could be: TaxType. For the valuation of the logical file the additional data element type will be counted and no additional record types are distinguished.

In a situation like this it is recommended to adjust the functional design in order to avoid discrepancy between the count and the design.

Solution

Count one ILF with 1 RET and 14 DET’s.

翻译

问题描述

市政税务管理系统有一个收款模块在其中记录付款。这些款项涉及房地产税、垃圾税、排污费和旅游税。收到的付款存储在四个表中，其结构记录如下。

支付不动产税	支付垃圾税	支付排污费	支付旅游税
付款编号	付款编号	付款编号	付款编号
数量	数量	数量	数量
会计年度	会计年度	会计年度	会计年度
社会保险号	社会保险号	社会保险号
商会编号			商会编号
付款日期	付款日期	付款日期	付款日期
评税编号
	税收编号	TaxationNumber
			索赔编号
帐号	帐号	帐号	帐号
周期序列号	周期序列号	周期序列号	周期序列号
付款参考	付款参考	付款参考	付款参考
托收付款标志	托收付款标志	托收付款标志

所有案例都与银行转移支付有关。评估编号、纳税编号和索赔编号之间没有本质区别；这些都是纯粹合法的财政名称。系统根据收到的付款的付款参考（其中包括税务类别的指示）确定相关付款记录在四个实体中的哪一个。收到的所有付款的程序相同：每天在总账系统的输出文件中收集分录。收款模块提供相同的功能来监控所有类型付款的付款状态。在这种情况下，应该识别多少ILF？

讨论

LF的定义是：
内部逻辑文件是从用户的角度来看，满足以下每个标准的永久数据的逻辑组：
-应用程序使用它进行计数
-它由要计数的应用程序维护

上述实体符合所列标准：它们均由待统计的信息系统使用和维护。然而，短语“从用户的角度”是至关重要的。该指南就此主题阐述了以下内容：

“……有经验的用户认为是重要和有用的单元或对象的一组数据。与这种逻辑数据组等效的是数据建模中的对象类型。”

对于用户来说，这四种不同类型的税也是四种不同的东西。税收和相关规定在本质上确实是完全不同的。上述模型的设计者希望连接到不同的税收，并选择在四个单独的表中容纳四种类型的付款；它们在结构上基本相似。然而，从逻辑上讲，它们都涉及一种对象类型，其中一种数据元素类型可以是：TaxType。对于逻辑文件的评估，将计算额外的数据元素类型，并且不会区分额外的记录类型。

在这种情况下，建议调整功能设计，以避免计数和设计之间的差异。

解决方案

总共计数为1个ILF，1个RET（记录类型）和14个DET（数据元素类型）。