How should data models be assessed when identifying logical files?

The most useful source of information for identifying logical files is a data model diagram. This diagram may be an Entity-Relationship diagram, a Third Normal Form Data Model, an Entity Class Model, a Network Diagram or other form of data representation.

In FPA, a logical file is a conceptual entity type. A conceptual entity type is made up of one or more entity types from a data model which, together, are considered one logical unit by a user.

The term "entity type" in this section refers to an entity type in a data model in third normal-form. This is the most common form of data model and serves as an example of the principles involved.

The first step in identifying logical files is to determine if a data group should be considered by FPA at all. This depends on data persistence among other things. Persistence of a data group is a characteristic describing how long the data group is retained. Three types of persistence are defined:

• . None: The data group does not survive the transaction using it.
• . Short: The data group survives the transaction using it, but does not survive when the software using it ceases to operate.
• . Indefinite: The data group survives even when the software using it ceases to operate.

Only data groups with a Short or Indefinite persistence are potential FPA logical files.

The following guidelines apply to data entities which have been modelled in third normal-form. The guidelines assist in correctly and repeatably identifying logical files from a data model. The principles involved can also be applied to data modelled using different techniques.

The following method to get from a data model in third normal-form to logical files is based on the method recomended by the Nethelands Software Metrics Association (NESMA) and published in their NESMA Function Point Counting Practices Manual. (For further information refer to http://www.nesma.nl) :

1. Determine which entity types in the data model are code tables, and are to be counted as such.
2. Determine which entity types are a key to key (intersecting) entity ie. they only have keys as their data elements and do not have any other non-key attributes. These represent an m:m relationship in the normalized data model and exist for data modelling purpose and not as the result of a user requirement therefore they are excluded from the count. Note, the referring attribute (foreign key) is counted as a data element type for both logical files connected by this key to key entity.

3. Determine which entity types are a "key to key entity" but include other attributes. Note that two situations can arise here as a result:

a. The additional attributes are a result of an implementation or design decision to satisfy a non-functional requirement. (not requested by the user; e.g., a date/time stamp for data recovery purposes) . If the entity only includes these non-functional attributes then they are not counted as data element types and the entity type should be dealt with as indicated in step 2 above.

b. The additional non-key attributes are necessary to satisfy the functional user requirements, in which case, they should be treated as indicated in step 4.

4. Examine the remaining entity types to determine whether they are an independent logical file or make up a logical file with one or more related entity types. 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 concepts are described further below.

After the nature of the relationship(s) has been determined, you can assess how the entity types involved should be considered using the Table 1.

Two entity types, Job and Employee for example, can be connected to each other via a relationship; e.g., "has".

The nature of the relationship determines how many employees can work on a job according to the data model (0, 1, or more) and how many jobs a single employee can work on (0, 1, or more).

Suppose the business rule is that several employees can be used for a job (but at least one), and that a single employee may only work on one job. In such a case we say that the relationship between Job and Employee is 1:N.

If the business rule was that not all employees have to work on a job, the "1-side" of the relationship would be optional, and we would denote the relationship between Job and Employee as (1):N

In other situations, the "N-side" could also be optional: 1:(N) or (1):(N).

If a relationship between two entity types (A and B) is bilaterally optional, it means that the entity types can exist independently. In such a case, FPA sees each entity type as entity independent in regard to each other. Entity types A and B each form a logical file and are included in the FPA count.

If a relationship between two entity types (A and B) is bilaterally mandatory, it means that each entity type cannot exist without its counterpart; i.e., they cannot exist independently of each other. In this case, FPA sees the entity types as entity dependent. Entity types A and B together form one logical file and are included in the FPA count.

If a relationship between two entity types (A and B) is optional, it means that an A may exist to which no Bs are linked; e.g., as in the 1:(N) relationship between Job and Employee.

In such a situation, the idea of entity independence for entity type B plays a role in FPA. What happens to the optional side of the relationship (in this case B) when we want to delete the non-optional side of the relationship (A) when Bs are still linked to it?

Two essentially different situations are distinguished here:

(1) The deletion of A is allowed and all Bs linked to it are deleted in the same action (possibly after a message requests confirmation in which it is stated that all Bs will be deleted automatically with the deletion of A)

(2) The deletion of A is not allowed as long as Bs are still linked to it

In situation (1), the Bs are apparently not significant to the business unless they are related to an A, whereas in situation (2) they are significant.

Before you are allowed to delete A in the latter case, you will first have to actively delete all the related Bs or link these Bs to another A.

In situation (1) we say that B is entity dependent on A and in situation (2) that B is entity independent of A.

Entity types A and B in the FPA count form one logical file in situation (1), whereas in situation (2) they are each a separate logical file.

In the example citing the relationship between Job and Employee, Employee is normally entity independent, because it is not desirable to have all employee data deleted if the data related to a particular job is deleted.

The concept of entity independence as it pertains to the relationship between A and B in a (1):N relationship can also be dealt with in a similar way. These kinds of relationships, however, seldom appear in practice. The question you now have to ask yourself is, "what happens to the optional side of the relationship (in this case, A) when we want to delete the final B (the non-optional side of the relationship) linked to A?"

Two essentially different situations are distinguished here as well:

(1) The deletion of a final B linked to A is allowed in which A is also deleted in the same action (possibly after a message requests confirmation in which it is stated that A will be deleted automatically with the deletion of B)

(2) The deletion of B is not allowed as long as A is still linked to B

In situation (1), A is apparently not significant to the business unless it is related to one or more Bs, whereas in situation 2 it is significant.

Before you are allowed to delete the final B in the latter case, you will first have to actively delete the related A, or you must link this A to one or more other Bs.

In situation (1) we say that A is entity dependent on B and in situation (2) A is entity independent of B.

Entity types A and B, in FPA, count as one logical file in situation (1), whereas in situation (2) they each count as a separate logical file.

In the following table, A and B are two entity types (not a code table and not a key-to-key entity from the normalized data model that are connected to each other via a relationship).

Legend: LF = Logical file (ILF or EIF)

RET = Record type

DET = Data element type

In some situations more than two entity types can also form a logical file. In such a case, count the total number of entity types as the number of record types. In the event of a bilateral mandatory (1:1) relationship, one logical file with one record type is usually the rule.