Database Engineering Supporting the Data Evolution

Database Engineering Supporting the Data Evolution

Luiz Camolesi Júnior (State University of Campinas (UNICAMP), Brazil) and Marina Teresa Pires Vieira (Methodist University of Piracicaba – UNIMEP, Brazil)
DOI: 10.4018/978-1-60566-242-8.ch010
OnDemand PDF Download:
$37.50

Abstract

Researchers in several areas (sociology, philosophy and psychology), among them Herbert Spencer and Abraham Maslow, attribute human actions resulting in continual environmental changes to the search for the satisfaction of individual and collective needs. In other fields of science, this behavior represents a challenge in ethical researches on concepts, methodologies and technologies aimed at optimizing and qualifying the actions involved in these continual changes to obtain better results.
Chapter Preview
Top

Introduction

Researchers in several areas (sociology, philosophy and psychology), among them Herbert Spencer and Abraham Maslow, attribute human actions resulting in continual environmental changes to the search for the satisfaction of individual and collective needs. In other fields of science, this behavior represents a challenge in ethical researches on concepts, methodologies and technologies aimed at optimizing and qualifying the actions involved in these continual changes to obtain better results.

Specifically in computer science, software engineering is a critical sub-area for these researches and their application (Lehman & Stenning, 1997), since it involves the construction of models and orientation for their use in the development of resources, such as software, to support the user’s needs. Databases should be included in this context as a component for data storage (Figure 1).

Figure 1.

Laws of evolution (Lehman & Stenning, 1997)

Considering the premise of continuous changes (Table 1) and the human needs involved (Khan & Khang, 2004), the consequences for software and for the required database are obvious. In the field of computational science, these changes in the modern world are reflected in evolutionary features for software and databases, based on Database concepts, structures and processes that allow for rapid, albeit not traumatic, shifts to new industrial, commercial or scientific systems (Mcfadden et al., 1999) in new contexts (temporal scenarios) (Camolesi, 2004).

Table 1.
Type of changes
Evolution: actions for an (variant) element’s technological progress, improvement, modernization or correction.Revolution: alteration actions of an element can influence the element’s purpose in the context.
Involution: simplification actions of an element, regression in its conception or content.
Top

Background

Database models must comprise representation elements that are adaptable to the user’s varying and dynamic needs, and contain the taxonomy needed for their manipulation. Thus, traditional (generic) database models such as the Entity-Relationship (ERM) and Relational (RM) models (Siau, 2004) have been expanded with appropriate “profile” for specific applications and requirements. Considering their purpose of supporting changes, “Profile Models” can be easily referenced in scientific researches as:

Key Terms in this Chapter

Time and Interval (datatype): Fundamental datatypes to establish the temporal reference in a database. Time is symbolized by real numbers, based on a sequence of representative values to meet the application. Interval is an aggregation of two time moments intended to delimit and characterize the interval. The interval may represent continuous or discrete time.

Data Warehouse (DW): A subject-oriented, integrated, nonvolatile, time-variant collection of data in support of management’s decisions (Inmon, 2005).

Configuration: Collection of versions of different elements that make up a complex element. Versions in a configuration must be stable, i.e., they cannot be altered but can be changed by a new version of the same element. Configurations are abstractions representing semantic relationships among elements. Configurations serve to establish the scope of an application (temporal, spatial or user) (Sabin & Weigel, 1998). Revised Configurations consolidated by users can be defined as Releases. Versions of a release cannot be altered or changed by another version. Configurations defined as releases cannot be deleted because they are or were used. User identifiers, valid intervals for use and constraints are some important items of information associated with releases in databases.

Variant: Applied to many structural elements of a database (class, table, constraint etc), it is used to define mutable elements or elements whose modification is highly probable. An invariant is the opposite of a variant, i.e., an element not involved in the evolution of the database. Variants of database objects or object properties can be modified and can generate versions.

Database Constraints: Boolean functions associated with elements of a database being used to evaluate the integrity of actions or data that are inserted, removed or updated. A Database Constraint can be defined as a set of predicates P1 ?P2 ?... ?Pk, where each predicate possesses the form C1?C2, and where C1 is an attribute, ? is a comparison operator and C2 is either an attribute or a constant (Camolesi, 2004). The specification of a database constraint can be formalized using the Object Constraint Language – OCL (Object Management Group)

Temporal Scenario: Is a concept that adequately represents and includes the characteristics typical of evolution, and is used in adaptive, dynamic or flexible systems. The role of temporal scenarios is to represent situations in which the database requirements have been or will be modified (Camolesi, 2004). Every scenario reaches a moment in time when its existence begins (opening). Starting from this moment, the actors begin to perform (acting). Scenarios may reach a moment in time when they cease to exist (closing). Scenarios can open/close several times (recurrent scenarios). The definition of the opening and closing moments is obligatory for the specification of the temporal existence of temporary scenarios. The exceptions to this rule are the permanent scenarios, which do not close, and the ones that do not open.

Database Maintenance Policy: Policy can be defined as a plan or guide to constrain the actions executed by an individual or a group. The Database Maintenance Policy establishes rules for the action of database designers that are executed in response to intrinsic and constant maintenance-related alteration needs, based on the designers’ empirical knowledge and work capacity. The definition of goals, implementation phases, results and desired outcomes is information associated with every policy or subset of rules.

Influence: Type of dependency association to conceptually and logically represent interrelations among elements and to define their levels of involvement prior to a process of alteration of the data (Object Management Group). Influence modeling is based on impact specifications of modifications in database objects during the engineering process.

Version: An alternative of a database element, with variations in structure, function or behavior, used in the context of an application as a boundary of the work executed. A version can represent a state of an evolving element with variant and invariant properties (Conradi & Westfechtel, 1998). A collection of actions executed on a database element can generate an element version if it results in significant alterations of the element’s characteristics.

Business Rule: Expression or statement that represents a restriction of data or operations in a business domain. A collection of Business Rules is a behavioral guide to support the Business Policy (organizational strategy). Business Rules can be implemented as Database Constraints, depending on the form and complexity of the restriction (Date, 2000).

Complete Chapter List

Search this Book:
Reset