Integral Logistics Management — Operations Management and Supply Chain Management Within and Across Companies

20.3.2 View and Primary and Secondary Keys

Intended learning outcomes: Produce an overview on the view on a class. Differentiate between primary key and secondary key. Describe characteristics for a “good” primary key. Explain the representation of a class in an object-oriented approach (with example) and the representation of an object.


View on a class is an excerpt of the table defined by entities and attributes, which includes only certain attributes and entities and for which the entities are presented in a certain order. 

The term view can be applied to a class in an object-oriented approach, with objects in the place of entities. In Figure 20.3.1.1, the view is complete regarding the attributes as well as the entities. The different entities are listed sequentially in ascending order sorted by the attribute customer ID

  • Another view could present the customers in descending order sorted by the attribute sales, present the attributes name and sales (in that order) and only for customers in certain locations.
  • A further view could present the entities in ascending order sorted by the attribute agent, showing only the attributes agent, name, and customer ID

In practical application, the view has become probably the most important construct in electronic data processing (EDP). And in fact, most information needs can be formulated as simple or complex views of certain data in a database. To express it pointedly, the main task of information systems for business processes consists in sorting and selecting objects. This is especially true in the case of IT-supported systems. To create views there are tools:

Structured Query Language (SQL) is the name of a well-known data manipulation language (DML). The clauses of an SQL query correspond in principle to the definition of a view. 

The SQL instructions for the two examples above are:

  • SELECT name, sales FROM client BY sales WHERE city ∊ {“Zurich,” “Basel”}
  • SELECT agent, name, customer ID FROM customer BY agent

Another important design element is the primary key of a class, also called ID key, or — simply — ID.

A primary key, or identification keyof a class (also called ID key or simply ID) is a minimal number of attributes that together as a set uniquely identify an object. More formally, a primary key is subset X of attributes of a class that always — that is, for each possible combination of entities — satisfies the following conditions:
—  X determines all attributes of the class, that is, for each value of X there exists an unambiguous value for the remaining attributes, or — and equivalently — all entities or objects that possess the same value for X also have the same value for the remaining attributes (that is, it is the same entity or same object that we are dealing with here);  
—  There is no subset Y of X, Y ≠ Ø, such that Y already determines the remaining attributes (minimality property, or irreducibility). 

In principle, it is not necessary to choose a primary key purely for storing the data. Nevertheless, the primary key has become an important design element. The main reason for this is that when modeling the real world, the semantics are considerably simpler for the user to understand.

A “good” primary key should have the following four characteristics:

  1. Stable: A primary key must not change during the lifetime of an object.
  2. Immediate assignment: A primary key must be assigned immediately, as soon as an object is created.
  3. Short and simple: A primary key should be relatively short for quick data entry.
  4. Meaningful: A primary key should consist of typical qualities of the object.

Unfortunately, the fourth requirement (meaningful) is often not consistent with the first, stability, and in part also the second and third. Examples of partly meaningful keys are the EAN number for product identification, the social insurance number (“AHV” number) previously used in Switzerland, and also in many countries the student ID number. In practice, stability has priority. This is because with a meaningful primary key, when the number of digits has been used up for meaningful description, the key has to be lengthened by one or more digits. Because of the existing stored data, this so costly and prone to errors that instead a new key is chosen and changed to “not meaningful.” This was the case, for instance, with the introduction of the new social insurance number in Switzerland. The same issue concerns the choice of a meaningful item ID.

A secondary keyof a class is a subset of attributes that sorts the objects for views.

A secondary key differs from a primary key in that it does not have to identify an object uniquely. But it defines a view of the class such that it determines the order of the objects.

In the object-oriented notation following UML (see [UML13]) as shown in Figure 20.3.2.1, the primary key attribute is underlined. Several attributes together can define a primary key. Several possible primary keys are distinguished by means of a list.

Fig. 20.3.2.1       Representation of a class in an object-oriented approach (with example) and representation of an object. 

A view is marked by means of a dotted line underlining the attributes according to which the view is sorted. In Figure 20.3.2.1, for example, a view is defined by the attribute agent.



Course section 20.3: Subsections and their intended learning outcomes

  • 20.3 Modeling Information Systems in the Data View and Object View

    Intended learning outcomes: Present terms such as object, attribute, object class, view, primary and secondary keys. Explain basic concepts such as association, association role and type. Describe the breaking up of an n-to-n association – in particular a reflexive one – and the association class. Disclose the use of the hierarchical constructs for developing a company-wide generic object model.

  • 20.3.1 Object, Attribute, and Object Class

    Intended learning outcomes: Differentiate between entity, object, and data record. Differentiate between attribute and data field. Differentiate between object class, file, and table. Explain the class customer as a table in the relational database model.

  • 20.3.2 View and Primary and Secondary Keys

    Intended learning outcomes: Produce an overview on the view on a class. Differentiate between primary key and secondary key. Describe characteristics for a “good” primary key. Explain the representation of a class in an object-oriented approach (with example) and the representation of an object.

  • 20.3.3 Association and (Association) Role

    Intended learning outcomes: Differentiate between binary association and reflexive association. Explain Abrial’s access function and the example of the association of the classes “book” and “customer” in library systems. Identify the (association) role.

  • 20.3.4 Single-Valued and Multivalued Roles, and Total and Partial Roles

    Intended learning outcomes: Differentiate between a single-valued role and a multivalued role. Differentiate between a total and a partial role, or access function.

  • 20.3.5 Association Types

    Intended learning outcomes: Differentiate between the 1-to-1 association, the 1-to-n association, the n-to-1 association, and the n-to-n association. Explain various examples of different binary associations.

  • 20.3.6 Breaking up an n-to-n Association; Association Class

    Intended learning outcomes: Explain the association class formed by breaking up an n-to-n association into a 1-to-n association and an n-to-1 association.

  • 20.3.7 Different Notations and the Reidentification Key

    Intended learning outcomes: Describe the commonly used crow’s-foot notation for depicting associations in the entity-oriented approach. Identify the common notation for associations in the entity-oriented approach. Explain the Representation of associations in an object-oriented form, as well as the concept of the reidentification key.

Print Top Down Previous Next