33 NESMA 具有多对多关系的FPA表

最新推荐文章于 2024-02-23 14:14:04 发布

不知之知

最新推荐文章于 2024-02-23 14:14:04 发布

阅读量461

点赞数

分类专栏： NESMA 文章标签：软件工程

NESMA 专栏收录该内容

44 篇文章 7 订阅

订阅专栏

33 FPA-TABLE WITH N:M-RELATION（具有多对多关系的FPA表）

问题描述

在应用程序中，有一个具有FPA表特征的部门实体，该表与另一个员工实体具有N:M关系。在部门员工关系表“键-键实体”中，这种关系符合第三范式。如果删除员工，则从部门员工关系表中删除所有链接的部门。

在这里插入图片描述

这种情况应该识别多少个内部逻辑文件

讨论

描述了以下非规范化规则（见第4.21.2节）：

确定数据模型中的哪些实体类型是FPA表。FPA表以特定方式进行估值。参见第4.20节和指南5.2.k和6.2.g。
确定哪些实体类型是没有其他属性的“键-键实体”。这些表示规范化数据模型中的n:m关系，根本没有值。引用属性（外键）被标识为该键-键实体连接的两个逻辑文件的数据元素类型。
确定哪些实体类型是具有其他属性的“键-键实体”。请注意，结果可能出现两种情况：
1. 附加属性本质上是技术性的（不是用户要求的；例如，日期/时间戳），没有被标识为数据元素类型。如果它们是唯一的数据元素类型，则应按照上述步骤2所示处理实体类型。
2. 附加属性本质上是功能性的（用户需要），在这种情况下，应按步骤4所示处理。
检查其余实体类型，以确定它们是否是单独的逻辑文件，或者是否与一个或多个相关实体类型一起构成逻辑文件。决定因素包括：
- 与其他实体类型（基数和可选性）的关系的性质
- 实体类型存在的依赖性或独立性
这两种观点将在下文中进一步探讨。参见第4.21.3节和第4.2.4节。

确定关系的性质后，您可以使用第4.21.5节中的表评估应如何考虑涉及的实体类型。在此处所述的数据模型中，如果以不同的顺序执行，则两个非规范化规则与另一个结果结合在一起。

非规范化规则的步骤1描述了必须识别FPA表。在本例中，根据第4.20节的规则，实体部门是FPA表。

非规范化规则的第2步描述了在没有其他属性的情况下确定“键-键实体”。这些根本没有价值。引用属性（外键）被计算为该键-键实体连接的两个逻辑文件的数据元素类型。

在本例中，部门员工关系表实体是一个没有附加属性的键-键实体。属性部门代码将作为实体员工的参考属性添加，属性员工ID将作为实体部门的参考属性。通过添加此属性，实体部门不符合FPA表的标准。

但是，如果逻辑文件是基于第三标准格式数据模型确定的，则必须按照所述的准确顺序应用非规范化规则（第4.21.2节）。

尽管有手册中的所有其他规则，第4.21.2节仅适用于第三种标准形式的实体。在本示例中，这意味着在第一步中，实体部门被指定为FPA表。因此，只有实体“每个部门的员工”和“员工”才能完成下一步。

对于这两个实体（部门员工关系表和员工），步骤2和3不相关。步骤4很重要。检查两个实体是否都是独立的逻辑文件。关系的性质（第4.21.3节）和依赖性（第4.21.4节）是确定的关键。第4.21.5节中提到了所有可能性。

答案

将实体部门计算为FPA表。它将成为FPA表内部逻辑中的记录类型。

将员工实体和部门员工关系表实体一起计算为一个内部逻辑文件（ILF）。存在实体依赖性，因为每个部门的员工和员工在同一操作中被删除。

Problem description

Within an application there is an entity Department with the characteristics of a FPA-table with an N:M-relation with another entity Employee. This relation is in the third normalform in a ‘key-key-entity’ Employee per Department. If an Employee is deleted, then all the linked departments are deleted from Employee per Department.

在这里插入图片描述

How many ILFs should be identified in this situation?

Discussion

The following denormalization rules are described (see section 4.21.2):

Determine which entity types in the data model are FPA tables. FPA tables are valued in a specific way. See section 4.20 and guidelines 5.2.k and 6.2.g.
Determine which entity types are a “key-key entity” without other attributes. These represent an n:m relationship in the normalized data model and are not valued at all. The referring attribute (foreign key) is identified as a data element type for both logical files connected by this key-key entity.
Determine which entity types are a “key-key entity” with other attributes. Note that two situations can arise here as a result:
1. The additional attributes are technical by nature (not requested by the user; e.g., a date/time stamp) are not identified as data element types. If they are the only data element types, then the entity type should be dealt with as indicated in step 2 above.
2. The additional attributes are functional in nature (required by the user), in which case, they should be treated as indicated in step 4.
Examine the remaining entity types as to whether they are a logical file on their own or whether together, with one or more related entity types, they make up a logical file. Determining factors are:
- The nature of the relationship(s) with another entity type (cardinality and optionality)
- The dependence or independence of the entity type’s existence

Both of these ideas are examined further below. See sections 4.21.3 and 4.21.4.

After the nature of the relationship(s) has been determined, you can assess how the entity types involved should be considered using the table in section 4.21.5. In a data model as described here two denormalization rules come together with another outcome if carried out in a different order.

Step 1 of the denormalization rules describes that the FPA-tables must be identified. In this example the entity Department is a FPA-table, according to the rules of section 4.20.

Step 2 of the denormalization rules describes the determination of the ‘key-key-entities’ without other attributes. These are not valued at all. The referring attribute (foreign key) is counted as a data-element-type for both logical files connected by this key-key entity.

In this example the entity Employee per Department is a key-key entity without additional attributes. The attribute Department-Code is to be added as a reference attribute to the entity Employee and the attribute ID-Employee is to be added as a reference attribute to the entity Department. By addition of this attribute the entity Department does not meet the criteria of a FPA table.

However if the logical files are determined based on a third normal form data model, the denormalization rules (section 4.21.2) must be applied in the exact order as described.

Notwithstanding all the other rules in the manual section 4.21.2 is only applied to an entity in third-normal form. In this example it means that in the first step the entity Department is earmarked as a FPA-table. And therefore only the entities Employee per department and Employee go through the next steps.

For both the entities (Employee per department and Employee) the steps 2 and 3 are not relevant. Step 4 is important. Examine if both the entities are separate logical files. The nature of the relationship (section 4.21.3) and the dependence (section 4.21.4) are key for this determination. All possibilities are mentioned in section 4.21.5.

Solution

Count the entity Department as a FPA-table. It will become a RET within the FPA-tables-ILF.

Count the entities Employee and Employee per department together as one Internal Logical file (ILF). There is entity dependence because Employee per department and Employee are deleted in the same action.