38 NESMA 维护多对多关系案例_维护ilf有哪些-CSDN博客

38 MAINTAINING AN N:M-RELATION（维护多对多关系）

问题描述

在企业管理系统中，可以维护员工和部门数据。还可以将部门链接到员工，并将员工链接到部门。为此，添加了一个关系实体（位置），该实体仅包含两个实体的键，从而形成一个N:M关系。在该企业管理系统的数据模型中，存在以下实体：

在这里插入图片描述

可以将一个或多个部门链接到一名员工，或断开此链接，如下图左侧所示。将一个或多个员工链接到一个部门或断开此链接的可能性如下图所示。

在这里插入图片描述

该功能的工作原理如下：左侧列表显示未链接到所选员工的部门名称，右侧列表显示链接到该员工的部门。用户可以使用列表之间的按钮（“>”、“<”），将部门名称从一个列表移动到另一个列表，反之亦然。可以使用“保存”按钮将这些移动保存在关系实体中。

顺便说一下，这只是该功能实现的一个示例。

这里的问题是，是否应确定外部输入？如果是，有多少。

此处不详细说明显示部门和员工列表以及相关逻辑文件的功能。本示例的讨论仅限于链接的功能。

讨论

每个员工维护部门的用户故事可以是：
“作为一名人力资源工作者，我希望能够将一个部门链接到一名员工，并打破这种链接，这样我就可以为每个员工显示他们正在为哪个部门工作。”对于维护每个部门的员工，将存在类似的用户故事。

事实上，此功能用于向关系实体中添加引用和从关系实体中删除引用。

Nesma计数指南中有一节关于非规范化（4.21.2第2点），指出关系实体根本没有价值。

在本节之后，上一页中显示的数据模型将产生两个ILF（部门和员工）。每个实体都获得一个额外的数据元素类型（DET）来实现N:M关系。

第7.1节定义了外部输入功能。总结如下：唯一、用户识别、从应用程序外部输入的数据、基本数据以及在一个或多个ILF中添加、更改或删除数据。

合并这两个部分（4.21.2第2点和7.1点）不包括识别一个或多个EIF以保持关系实体位置，因为这不是有效的ILF。

实体部门和员工是有效的ILF。根据第4.21.2节第2点，这些是职能维护部门为每位员工维护的ILF。
非规范化后，我们得到了ILF：

Department (Department-ID, (Employee-ID_1, Employee-ID_n), Name,Location, cost center number, etc.)
Employee (Employee-ID, (Department-ID_1, Department-ID_n), Last name,Prefixes, Initials,

在斜体中，两种方式都添加了属性。这些是重复组。如果没有它们所属的ILF，它们就没有意义。对于FPA，重复组是记录元素类型（RET）。这样的RET可以为空（不包含任何元素）。

将部门链接到员工时，这两个事件将同时发生添加员工RET（引用部门）和部门RET（引用员工）。

当断开这样一个链接时，相反的情况发生，必须删除两个事件（每个实体中的一个RET）。

因此，这是两个不同的EIs，总是在两个ILF中发生变化。对于员工与部门之间的联系/脱钩，也同样适用。

答案

每个屏幕的计数为2个EIs（链接和脱链接），因此总共4个EIs。

Problem description

In a business administration system employee and department data can be maintained.It is also possible to link departments to an employee and link employees to a department. For this purpose, a relationship entity (Placement) has been added, which contains only the keys of the two entities, resulting in an N:M relationship. In the data model of this business administration system the following entities are present:

在这里插入图片描述

The possibility to link one or more departments to an employee or break this link is shown in the image below, left. The possibility to link one or more employees to a department or break this link is shown in the image below, right.

在这里插入图片描述

The function works as follows: The left list shows the names of departments not linked to the selected employee, the right list shows those that are linked to this employee. The user can move department names from one list to the other and vice versa, using the buttons (“>”, “<”) between the lists. These movements can be persisted in the relationship entity using the Save button.

By the way, this is only one example of an implementation of this function.

The question at hand here is, whether external inputs should be identified? And, if so, how many.

The functionality of displaying the lists of departments and employees and the logical files concerned, are not elaborated here. The discussion of this example is limited to the functionality of the linking.

Discussion

A user story for Maintaining Departments per Employee could be:
“As an HR worker I want to be able to link a department to an employee and to break such a link, so I can show for every employee the department(s) they are working for.”A similar user story will exist for Maintaining Employees per Department.

In fact this function adds occurrences to and removes occurrences from the relationship entity Placement.

In the Nesma counting guideline is a section about denormalization (4.21.2 point 2), stating that a relationship entity is not valued at all.

Following this section the data model shown on the previous page results in two ILFs (Department and Employee). Every entity gets an extra data element type (DET) to implement the N:M relation.

Section 7.1 defines an External Input Function. Summarized this is: unique, user recognized, data entered from outside the application, elementary and add, change or delete data in or from one or more ILFs.

Combining these two sections (4.21.2 point 2 and 7.1) excludes identifying one or more EIFs to maintain the relationship entity Placement as this is not a valid ILF.

The entities Department and Employee are valid ILFs. According to section 4.21.2 point 2 these are the ILFs maintained by the function Maintain Departments per Employee.

After denormalization we have the ILFs:

Department (Department-ID, (Employee-ID_1, Employee-ID_n), Name,Location, cost center number, etc.)

Employee (Employee-ID, (Department-ID_1, Department-ID_n), Last name,Prefixes, Initials, etc.)

In italics the both ways added attributes. These are repeating groups. They don’t have a meaning without the ILF they are part of. For FPA a repeating group is a record element type (RET). Such a RET can be empty (holds no elements).

When linking a department to an employee both an occurrence in the RET in Employee (reference to the department) and the RET in Department (reference to the employee) have to be added.

When breaking such a link the opposite goes and two occurrences (one from the RET of every entity) have to be removed.

So these are two different EIs that always change occurrences in both ILFs.For linking/delinking of an employee to/from a department, the same reasoning applies.