A Discipline of Software Engineering

B. Walraet

• Publisher: North Holland
• Year: 2014
• Print ISBN: 9780444891310
• eBook ISBN: 9781483294216
• Topic: Computer Science
• Subtopic: Programming
• Index: Computer Science

This comprehensive approach to the creation of software systems charts a road through system modelling techniques, allowing software engineers to create software meeting two very basic requirements:• that the software system represent a narrow emulation of the organization system that served as its model; • and that the software system display life attributes identical to those of the organization system that it automatizes.The result is a quantum leap increase in software application quality. Such benefit is achieved by the introduction of a fundamental paradigm: the office-floor metaphor which incorporates such well-balanced basic ideas as the functional normalization of tasks and information (in sharp contrast to the classic data normalization) and the principle of tenant-ownership.

ENTITY 1: INFORMATION

Outline

INTRODUCTION TO ENTITY 1: INFORMATION

Chapter 2: The Semantics of Data

Chapter 3: The Fine Art Of Data Modeling

Chapter 4: The Makings of a Logical Data Model

INTRODUCTION TO ENTITY 1: INFORMATION

WARNING

The subjects covered in this part of the text are about information modeling and its obligatory sequel: data modeling.

The reader is assumed to have a fair knowledge of the relational data representation, even though this is not used here as the fundamental model. A brief introduction to this model is included in the text, but space constraints prevent me from giving a full criticism.

A fair portion of the text is devoted to semantic modeling, where understanding the information is of the essence, whereas the remainder of the text deals with the actual modeling of the data structures, achieving the (almost) zero-redundancy objective.

The modeling techniques presented are those that -based on personal experience over years- have given me the best basis for achieving quality in the resulting models.

The associate subject of information architecture modeling is covered in another part of the text (it is inculded in enterprise modeling)

CHAPTER 2

The Semantics of Data

Publisher Summary

That data has a structure is an accepted fact. All forms of list structures are conceivable for representing data. However, such structures offer too much freedom. Thus, the pragmatic world took another avenue. A relation is composed of discrete attributes. The relation has a name that allows programmers to perform operations against it. For the attributes, nesting is not allowed, in other words, fields cannot be group-fields: a column should not have a finer structure. An attribute is atomic. It might have a binary structure: the value in the column might be absent or present; an absent value is a null value, and this can be allowed or disallowed in any given column. In the pure scientific definition, the relation is the set of its tuples, like a file is not the layout of a record, but the set of all occurrences of a given record layout.

Preamble: Codd’s relational model

That Data has a structure is an accepted fact. Clearly, all forms of list structures are conceivable for representing data. However, such structures offer too much freedom. Thus, the pragmatic world took another avenue. An avenue first explored by Ted Codd, leading to the famous relational model. What Codd stated, as an axiom, was the existence of a group of data fields, i.e. the list of related fields. Fields are called attributes (and sometimes columns). Such a list was given the name relation (sometimes also table). Thus, a relation is composed of discrete attributes. The relation has a name which allows programmers to perform operations against it. For the attributes nesting is not allowed, in other words fields cannot be group-fields: a column should not have a finer structure. One says that an attribute is atomic. It may, however, have a binary structure: the value in the column may be absent or present; an absent value is a null value, and this can be allowed or disallowed in any given column. An example: a relation holding employees has a column for the name of the spouse. Bachelors will have a null value in this column.

Codd also defined the tuple (sometimes also called row): one significant value of all fields of the relation, such that the aggregation of these values constitutes a significant occurrence in the usage of the relation. In more pragmatic terms, a tuple is an occurrence of the relation.

In the pure scientific definition, the relation is the set of its tuples (just like a file is not the layout of a record, but the set of all occurrences of a given record layout). Therefore, if we draw it up on a sheet of paper, a relation looks a lot like a table, with named columns and filled with rows (these are the tuples). Obviously, this is a rather attractive way of viewing data, isn’t it? It corresponds to what data usually is in a non-automated environment. So much so that I will use the term table with columns as a synonym of relation with attributes (this has become daily habit in programming circles; strict relationalists do not accept it, however). In fact, a relation is none other than a new name for an old object: the file! The associate discipline is not that of files, however, as we will see presently.

In a way, Codd followed the Pascal philosophy: each column (or field or attribute) is defined over a domain, another way of saying that it was of a given (strong) type (strong typing refers to the fact that a program using a field cannot assign a value to it that is not allowed by the domain of the field, nor can the field be assigned to a field with another domain; manufacturers tend to be rather lenient and vague in supporting this kind of discipline; many of them allow some kind of conversion or coercion between domains). This aspect of typing is called domain integrity.

Codd did more: he stipulated that identical rows in a tuple were to be banished, as they would be totally indistinguishable and would therefore be unusable. But, if duplicate rows are to be avoided, that means that rows are somehow distinguishable. How? By the fact that any pair of rows differ in the value of at least one field. And, noticed Codd, quite often this is the same field for all rows of the table. So, a table may contain a column that has something special about it: it can be used (or, better, its values can) to identify the rows of the table. This means that the column actually identifies all the other attribute (values) of the row. Such a column is a primary key. Of course, a primary key can be made up of two or more columns taken together. The important rule is that a table must have a primary key, even if it is ...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Dedication
• Inside Front Cover
• PREFACE
• AUDIENCE
• ACKNOWLEDGMENTS
• TABLE OF INSERT BOXES
• OVERTURE
• ENTITY 1: INFORMATION
• RELATIONSHIP BETWEEN ENTITY 1 AND ENTITY 2: ORGANIZATION
• ENTITY 2: ACTIONS
• APPENDICES