Selecting an identifying attribute for each entity

For each entity, you must specify an identifier that serves to uniquely recognize instances of the entity. An identifier can be a single attribute or a combination of several attributes (in this case, the identifying attribute is a composite attribute), the set of values of which is unique, i.e. the values of the identifying attribute are in one-to-one correspondence with entity instances.

In data processing systems, an attribute or some set of attributes whose values uniquely identify each object in a set of objects is called a key.

Data processing systems use the hypothesis that each object in a set of objects is distinguishable (i.e., its description differs from the description of other objects). According to this hypothesis, each set of objects has a key. However, if a set of attributes that do not contain a key is chosen to describe a set of objects, then a special attribute is introduced into the composition of the attributes, which acts as a key. In many cases, this is some sequential number (for example, in the SBERKASSA ACS, the attribute Account number is entered as a key for identifying an account, which is the next free serial number in the register of savings bank accounts).

The same set of objects can have multiple keys. One of them is assigned as the primary key of a set of objects and subsequently serves as the key of the file corresponding to this set (it is also called the record key, tuple). All other keys in the set are called candidate keys in this case.

Key selection is an important consideration in designing data models. This is due to the fact that, on the one hand, the key must fulfill its main task – the task of unique identification, and on the other hand, it must include the minimum number of attributes required (to complete the identification task). At the final stages of database design for some applications, it may be possible to refine the second task: from the set of possible keys, the one that requires less computer memory is chosen as the primary one.

In addition to the concepts of “key”, “primary key”, “possible key”, there is also the concept of “composite key” – to denote a key consisting of two or more attributes.

Descriptive Attribute Entity Assignment

Selected entities are assigned descriptive attributes in addition to identifying attributes that describe the properties of the entities of interest to applications.

For example, an Employee entity might have descriptive attributes such as Date of Birth, Education, Home Address.

The specification of attributes must end with an indication, for each attribute, of the set of values, or domain, that the attribute can take. If this set is infinite, then it is specified by specifying the type of accepted values – alphanumeric, integer, real, etc. – and range of values for numeric values, or number of characters to represent alphanumeric values.

In data processing systems, the concept of “secondary key” is used – this is an attribute or a set of attributes that identify not a unique object in a set, but all objects that have certain values of these attributes, i.e. the secondary key allows, if necessary, to select from the set those objects that have the properties of interest to us. The secondary key is also called the lookup key. Restrictions on the composition of secondary keys are determined only by the query logic. Any attribute or any set of attributes that describe a set of objects can act as a secondary key.

Link specification

The local view reveals dependencies between two (or more) entities. It is established which links are important and which are redundant. For the identified relationships, their characteristics are determined, each type of relationship “entity-entity” is named.

In addition to the specification of relations of the “entity-entity” type, the specification of relations of the “entity-attribute” type is carried out (that is, the attribute and the entity for which it is used are indicated), as well as the specification of relations of the “attribute-attribute” type.

An attribute-to-attribute relationship is a relationship between attributes that refer to the same entity or to the same entity-to-entity relationship.

Example. In the local view, the following attributes were assigned to the Employee entity: Personnel number, Last name, first name, patronymic, Date of birth, University name, University address, Specialty, Child’s name, Date of birth of the child, Date of admission, Date of dismissal.

There are certain relationships between attributes. First, since all these attributes describe the same Employee entity, which has an identifying attribute Personnel number, therefore, all attributes of this entity have a dependency on the identifying attribute, i.e. when describing specific instances of the Employee entity, descriptive attributes cannot take arbitrary values. Their values depend on the values of the identifying attribute. In addition to this dependency among the attributes in the example under consideration, there are a number of other dependencies between descriptive attributes: the value of the Address of the university attribute is determined by the value of the Name of the university attribute, the value of the Child’s date of birth attribute is determined by the value of the Child’s name attribute.

Rice. 3.5. Diagram of binary relationships between entities

It is advisable to present this information in the form of a separate diagram of binary relationships between attributes. On fig. 3.5 links are represented by directed arcs.

An analysis of the diagram of relationships between the attributes of an entity allows one to judge how well the choice of the main constructions of the model (in this case, the entity and the attribute) was made in terms of the simplicity of representing the semantic relationships between the constructions used when presenting a specific piece of information.

It is advisable to strive for the case when only dependencies of descriptive attributes on the identifying one are observed and there are no other dependencies, i.e. the “attribute-attribute” dependency for an entity has the form shown in fig. 3.6.

From this point of view, in our example, it is advisable to represent the entity Employee with the help of the following structures, represented by a graphical diagram (Fig. 3.7). In this case, the original diagram of binary relationships of the “attribute-attribute” type is divided into three diagrams:

for the entity Employee (Fig. 3.8).

for the entity University (Fig. 3.9).

for the entity Child (Fig. 3.10).

Rice. 3.6. Attribute-Attribute Dependency

Rice. 3.7. Local View Graphing Example

Rice. 3.8. Entity Attribute Relationship Diagram Employee

Rice. 3.9. Relationship diagram of the attributes of the University entity

Rice. 3.10. Relationship diagram of child entity attributes

There are cases when entity instances are distinguished not by attributes, but by their relationships with entity instances of another type. For example, an AS is being created for a certain production association, which includes several enterprises. Each enterprise has its own independent system for assigning personnel numbers to employees, and the structure of personnel numbers in all enterprises is the same, for example, five decimal places. In this case, the personnel number has lost its uniqueness in the database that stores information about the personnel of the association (there may be several identical values of personnel numbers for different employees). In order to uniquely identify the description of a particular employee in the database, in addition to his personnel number, you will also have to use the company code, i.e. use the relationship between the entities Employee and Enterprise. When specifying such relationships, it is indicated that they are used to identify entities and which ones.

The modeling of the local representation ends with the graphic design of all identified entities, the relationships between them and attributes, and the compilation of all the above specifications.

Be First to Comment

Leave a Reply

Your email address will not be published.