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 key of 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:
- Stable: A primary key must not change during the lifetime of an object.
- Immediate assignment: A primary key must be assigned immediately, as soon as an object is created.
- Short and simple: A primary key should be relatively short for quick data entry.
- 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 key of 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 The Crow’s-Foot Notation and the Common Entity-Oriented Notation
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.
20.3.7b The Reidentification Key and the Object-Oriented Notation
Intended learning outcomes: Explain the Representation of associations in an object-oriented form, as well as the concept of the reidentification key.
20.3.8 Breaking Up a Reflexive n-to-n Association, Step 1: Duplicate, and Step 2: Breakdown
Intended learning outcomes: Explain Breaking up a reflexive n-to-n association, step 1: Duplicate the class to create its two subclasses, and step 2: Classical breakdown of the n-to-n association.
20.3.8b Breaking Up a Reflexive n-to-n Association, Step 3: Merge
Intended learning outcomes: Explain Breaking up a reflexive n-to-n association, step 3: Merge the generating classes.
20.3.9 Using the Hierarchical Constructs Based on Basic Object Classes: The Company-Wide Generic Object Model
Intended learning outcomes: Explain the basic object classes and possible subclasses (specializations) of an industrial company. Describe the concept of a company-wide data model, or generic model.
